CAPITULO 12 METODOLOGIA DE DISEÑO DE REDES CORPORATIVAS

UNIVERSIDAD CATÓLICA “SAN PABLO” Unidad Académica Tarija INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES Materia: INF 342 Redes de Computadoras II Capítulo 12: Metodología de Diseño de Redes Corporativas Docente: Ing. Mauricio Aliaga Tarija, Noviembre 2012

Metodología

UCB TJA INF 342

Diseño de Redes Corporativas

a 1ra Parte

a Metodología a Pautas

2

UCB TJA INF 342

Características en el Diseño de Redes

a Diseños raramenterepetitivos a Algo de Arte a Combinación de Reglas a Evaluación y selecciónde tecnologías a Conocimiento: ` De la Tecnologías ` Servicios ` Sistemas 3

UCB TJA INF 342

Enfoques a TRADICIONAL ` Enfocado a la capacidad ` Ante problemas en la Red • Incrementar el ancho de banda

a NUEVASCONSIDERACIONES ` Tiempos de Transporte ` Fiabilidad ` Servicios a los usuarios 4

UCB TJA INF 342

Metodología para diseño de red de empresarial propuesta por James McCABE

UCB TJA INF 342

Proceso general Condiciones iniciales

Análisis de requerimientos

Análisis

Análisis de flujo Diseño lógico

Diseño

Diseño físico Direccionamiento y ruteo Introducción A&D de Redes

UCB TJA INF 342

Ejecución del diseño 7

Objetivo Diseñar y optimizar redes de comunicaciones (datos, voz y video) utilizando una metodología que proporcione una calidad de servicio controlada a las aplicaciones informáticas que utilicen la infraestructura planificada.

Características • Se hará énfasis en Diseño Descendente (Top-Down) • Es genérico (no es orientado a Cisco, aunque son inevitables las referencias al ser la mayor empresa del ramo) • Requiere de conocimientos generales previos sobre redes LAN, pila de protocolos TCP/IP, protocolos de conmutación, protocolos de enrutamiento, entre otros. Es un curso avanzado.

UCB TJA INF 342

Metodología General 1) Fase de análisis y fase de diseño 2) En la fase de análisis de requerimientos se establecen: Mapas de aplicaciones, Descripciones de flujos de datos, simples y Compuestos 3) En la fase de diseño hay dos niveles: diseño lógico y diseño físico

Metodología General Fase de Análisis 1. Recabar requerimientos ➔ Entrada: condiciones iniciales 2. Definir las aplicaciones que se ejecutarán en forma distribuida. ➔ Salida: mapa de aplicaciones 3. Caracterizar cómo usan los usuarios las aplicaciones ➔ Definir métricas para medir el desempeño ➔ Salida: modificadores de desempeño (por usuario/aplicación) 4.Distinguir entre requerimientos de servicio ➔ Entradas: grupos/tipos de aplicaciones y criterio general para distinguir entre servicios ➔ Salidas: requerimientos de tiempo real, requerimientos de tipo ``best effort´´ 5. Definir flujos, establecer las fronteras de flujo ➔ Entradas: mapa de aplicaciones (ver paso 2)

UCB TJA INF 342

Metodología General Fase de Diseño (lógico) 1. Establecer metas de diseño ➔ Entrada: especificación de flujos y especificación de requerimientos, en particular presupuesto 2. Desarrollar criterios para evaluación de tecnologías: costo, rapidez, confiabilidad, etc. 3. Realizar la selección de tecnologías ➔ Entradas: análisis de comportamiento de aplicaciones, con sus modificadores de desempeño (ver paso 3 de la Fase de Análisis) e información sobre tecnologías ofrecidas en el mercado 4. Integrar mecanismos de interconexión 5. Integrar aspectos de administración y seguridad al diseño ➔ Entrada: variables para administración de la red (ver paso 2 de la Fase de Análisis) 6. Incorporar análisis de riesgos y planificación de contingencias (Nota: aquí concluye el Diseño Lógico) UCB TJA INF 342

Metodología de Diseño Fase de Diseño (físico) 7. Evaluar opciones de diseño del cableado 8. Seleccionar la ubicación de los equipos 9. Realizar el diagrama físico de la red 10. Incorporar las estrategias de enrutamiento con base en los flujos ➔ Entrada: restricciones impuestas por los mecanismos de interconexión seleccionados en el paso 4 11.Optimizar flujos de enrutamiento 12.Desarrollar una estrategia de asignación de direcciones, asignar las direcciones 13.Desarrollar una estrategia detallada de enrutamiento ➔ Entrada: algoritmos de enrutamiento disponibles Con este paso concluye el Diseño Físico UCB TJA INF 342

Diseño Descendente de Redes

UCB TJA INF 342

Diseño Descendente de Redes • El diseño de redes debe ser un proceso completo, que asocie las necesidades del negocio a la tecnología disponible, para generar un sistema que maximice el éxito de una organización. – En el área de Redes Locales (LAN) es más que comprar unos pocos dispositivos – En Redes de Área Extendida (WAN) es más que llamar a la compañía telefónica UCB TJA INF 342

Comenzar por Arriba

• No comenzar conectando direcciones IP • Analizar las metas técnicas y de negocio primero • Explorar las estructuras de grupos y divisiones para encontrar a quiénes sirve la red y dónde residen • Determinar qué aplicaciones se ejecutarán y cómo se comportan esas aplicaciones en una red • Enfocarse primero en la capa 7 o más arriba UCB TJA INF 342

Capas del Modelo OSI Capa 7

Aplicación

Capa 6

Presentación

Capa 5

Sesión

Capa 4

Transporte

Capa 3

Red

Capa 2

Enlace

Capa 1

Física UCB TJA INF 342

Diseño Estructurado • Se enfoca en entender los flujos de datos, tipos de datos y procesos que acceden a los datos y los modifican. • Se enfoca en entender la ubicación y las necesidades de las comunidades de usuarios que acceden o cambian datos y procesos. • Pueden usarse varias técnicas y modelos para caracterizar el sistema existente, los nuevos requerimientos de los usuarios y una estructura para el sistema futuro. • Se desarrolla un modelo lógico antes del modelo físico. – El modelo lógico representa los elementos básicos, divididos por funciones y la estructura del sistema. – El modelo físico representa los dispositivos, las tecnologías específicas y la implementación. UCB TJA INF 342

Ciclo de Vida del Desarrollo de Sistemas • En inglés: SDLC. • ¡En este curso SDLC no significa Synchronous Data Link Control! • Los sistemas típicamente se desarrollan y continúan existiendo durante un cierto período de tiempo, llamado frecuentemente Ciclo de Vida del Desarrollo del Sistema UCB TJA INF 342

Pasos para el Diseño Descendente Analizar requerimientos

Monitorear y optimizar el rendimiento de la red

Desarrollar diseño lógico

Desarrollar diseño físico

Implementar y probar la red Probar, optimizar, y documentar el diseño UCB TJA INF 342

Fases del Diseño de Redes • Fase 1 – Analizar Requerimientos – Analizar metas de negocio y restricciones – Analizar metas técnicas, pros y contras – Caracterizar la red existente – Caracterizar el tráfico de la red

UCB TJA INF 342

Fases del Diseño de Redes • Fase 2 – Diseño Lógico de la Red – Diseñar una topología de la red – Diseñar modelos de direccionamiento y nombres – Seleccionar protocolos de conmutación (switching) y enrutamiento (routing) – Desarrollar estrategias de seguridad para la red – Desarrollar estrategias para el mantenimiento de la red UCB TJA INF 342

Fases del Diseño de Redes • Fase 3 – Diseño Físico de la Red – Seleccionar tecnologías y dispositivos para las redes de cada campus – Seleccionar tecnologías y dispositivos para la red corporativa (de la empresa u organización)

UCB TJA INF 342

Fases del Diseño de Redes • Fase 4 – Probar, Optimizar y Documentar el Diseño de la Red – Probar el diseño de la red – Optimizar el diseño de la red – Documentar el diseño de la red

UCB TJA INF 342

El Ciclo de Vida PDIOO de Redes Plan

Diseño Repetir Optimización

Implementación Operación

UCB TJA INF 342

Repaso • ¿Cuáles son las fases principales del diseño de redes, en una metodología descendente? • ¿Cuáles son las fases principales del diseño de redes en una metodología PDIOO (Planificación • Diseño • Implementación •Operación • Optimización)? • ¿Por qué es importante conocer el estilo de negocio del cliente? • Mencione algunas metas típicas de un negocio hoy en día. UCB TJA INF 342

Proceso general

UCB TJA INF 342

Proceso general Condiciones iniciales


Análisis


Diseño


UCB TJA INF 342


Condiciones Generales Condiciones iniciales


Análisis


Diseño

Diseño físico Direccionamiento y ruteo UCB TJA INF 342

Ejecución del diseño

UCB TJA INF 342

Análisis a Que es lo que quieren los usuarios a Objetivos del diseño ` Maximizar rendimiento ` Minimizar costos Pros y Contras Costo vs. Rendimiento Simplicidad vs. Funcionalidad Equilibrio entre Arquitectura y funcionalidad UCB TJA INF 342

Más de una solución

5

Determinar Condiciones Iniciales • Tipo de diseño del proyecto – Nuevo diseño – mejorar una red existente – contratar a un outsourcing

• Dimensionamiento – Tamaño de la red – Geográfico – Financiero UCB TJA INF 342

30

Condiciones Iniciales • Objetivos del diseño inicial (si está disponible) • Fuerzas externas/restricciones – Politico - Quien está a cargo? – Administrativo - Comité que toma decisiones?

• Evaluación de la situación existente – Porque estamos haciendo esto? Que tiene de errado la red del sistema existente? UCB TJA INF 342

31

Metas del Negocio Incrementar las ganancias: • Reducir costos de operación • Mejorar las comunicaciones • Acortar el ciclo de desarrollo de productos • Expandirse a mercados internacionales • Hacer asociaciones con otras compañías • Ofrecer mejor soporte al cliente o crear nuevos servicios UCB TJA INF 342

Nuevas Prioridades de Negocio

Mobilidad Seguridad Robustez (Tolerancia a fallas) Continuidad después de un desastre Los proyectos de red deben priorizarse con base en metas fiscales • Las redes deben ofrecer un retardo bajo, requerido para aplicaciones de tiempo real como VoIP • • • • •

UCB TJA INF 342

Restricciones de Negocio • • • •

Presupuesto Personal Agenda Políticas

UCB TJA INF 342

Recabar información antes de la primera reunión • Antes de reunirse con el cliente, sea éste interno o externo, recaba alguna información básica relacionada con el negocio • Información como: – Productos o servicios que se ofrecen – Viabilidad financiera – Clientes, suplidores, competencia – Ventajas competitivas UCB TJA INF 342

Reunión con el Cliente • Intenta obtener – Un resumen conciso de las metas del proyecto • ¿Qué problemas quieren resolver? • ¿Cómo puede ayudar la tecnología a hacer el negocio más exitoso? • ¿Qué debería pasar para que el proyecto tenga éxito?

UCB TJA INF 342

Reunión con el Cliente • ¿Qué pasaría si el proyecto falla? – ¿Tiene impacto sobre una función crítica del negocio? – ¿Este proyecto es visible para la alta gerencia? – ¿Quién está de tu lado?

UCB TJA INF 342

Reunión con el Cliente • Descubre cualquier sesgo – Por ejemplo • ¿Sólo usarán productos de ciertas compañías? • ¿Evitarán usar ciertas tecnologías? • ¿Existen diferencias entre la gente de informática y el resto de la organización?

– Habla con el personal técnico y gerencial UCB TJA INF 342

Reunión con el Cliente – Obtén una copia del organigrama • Nos mostrará la estructura general de la organización • Sabremos los usuarios que debemos tomar en cuenta • Sabremos las ubicaciones geográficas que debemos tomar en cuenta

UCB TJA INF 342

Reunión con el Cliente – Obtén una copia de la política de seguridad • ¿Cómo afectaría esta política un nuevo diseño? • ¿Cómo impactaría un nuevo diseño en la política? • ¿La política es tan estricta que impide al diseñador de la red hacer su trabajo?

– Comienza catalogando los recursos de red que la política de seguridad debería proteger • Hardware, software, aplicaciones y datos • Menos obvio, pero quizás más importante, propiedad intelectual, secretos de negocio y cualquier información que pueda ser usada en contra de la reputación de la compañía UCB TJA INF 342

Alcance del Proyecto de Diseño

• ¿De corto alcance? – Por ejemplo, permitir que la gente de ventas puedan acceder vía una VPN • ¿De largo alcance? – Por ejemplo, un rediseño completo de la red de la empresa • Use el modelo OSI para aclarar el alcance – Por ejemplo: una nueva aplicación de reporte financiero vs un nuevo protocolo de enrutamiento vs nuevos enlaces de datos (digamos inalámbricos) • ¿El alcance está dentro del presupuesto, la capacidad del personal, la agenda de la empresa?

UCB TJA INF 342

Recabar información más detallada

• Aplicaciones

– Ahora y después de terminar el proyecto – Incluir aplicaciones de productividad y de gestión de sistemas

• • • • •

Comunidades de usuarios Almacenamiento de datos Protocolos Arquitecturas lógica y física actuales Rendimiento actual UCB TJA INF 342

Aplicaciones de Red Nombre de Tipo de la aplicación aplicación

¿Aplicación ¿Es crítica? nueva?

UCB TJA INF 342

Comentarios

Resumen • Método sistemático • Enfocarse primero en los requerimientos del negocio, las restricciones y las aplicaciones • Entender la estructura corporativa del cliente • Entender el estilo de negocio del cliente UCB TJA INF 342

Análisis de requerimientos Análisis de Condiciones iniciales requerimientos

Análisis


Diseño


UCB TJA INF 342


UCB TJA INF 342

Conceptos relevantes Sistemas • Componentes y relaciones del sistema Servicios

Solicita

Ofrece

Usuario

Usuario

Aplicación

Aplicación

Host

Host Red Introducción A&D de Redes

UCB TJA INF 342

47

Conceptos relevantes Servicios de red • Características – Demanda – Oferta

• Niveles

Usuario

Usuario

Aplicación

Aplicación

Host

Host Red

• Requerimientos de rendimiento

Métricas de servicio

– Confiabilidad – Capacidad – Retardo Introducción A&D de Redes

UCB TJA INF 342

48

Determinación de requerimientos

• Consiste en – Identificar, capturar y comprender los requerimientos del sistema y sus características – Desarrollar umbrales de rendimiento para distinguir entre servicios de bajo y alto rendimiento – Determinar servicios específicos

• Requerimientos de – – – – –

Usuarios Aplicaciones Hosts Red Financieros Introducción A&D de Redes

UCB TJA INF 342

49

Determinación de requerimientos 2

• Para obtener requerimientos desarrollar: – Perfiles de usuario – Entrevistas – Grupos de análisis, tests en laboratorio

• Decidir entre soluciones abiertas o propietarias

Introducción A&D de Redes

UCB TJA INF 342

50

Análisis de Requerimientos: PAUTAS • Las pautas para el análisis de requerimientos son parte del modelo del proceso. Este modelo, mostrado en la siguiente figura, muestra los pasos principales en la colección y análisis de requerimientos para su diseño de red.

UCB TJA INF 342

51

Análisis de Requerimientos: PAUTAS Condiciones Iniciales

Aplicación Tipos / Grupos

Obtención de Requerimientos

Desarrollo Mapa de Aplicaciones

Desarrollar Métricas de Servicio para Medir Rendimiento

Variables de Administración de Red

Caracterizando el Comportamiento

Modificadores de Rendimiento Usuarios/Aplicación

Determinar Umbrales de Rendimiento Distinción entre Requerimientos de Servicio

Pautas en distinguir Servicios

UCB TJA INF 342

52

Contexto en el proceso general Condiciones iniciales


Análisis


Diseño

Diseño físico Direccionamiento y ruteo A&D Determ. de Requerimientos

UCB TJA INF 342


Resultados • Los resultados de la etapa son: – Especificación de requerimientos • Hojas de trabajo

– Mapa de aplicaciones • Esquema que muestra – Ubicación física de edificios y estaciones que usan las aplicaciones en estudio – Ambito de las aplicaciones

A&D Determ. de Requerimientos

UCB TJA INF 342

54

Componentes • Componentes y relaciones del sistema Servicios

Solicita

Ofrece

Usuario

Usuario

Aplicación

Aplicación

Host

Host Red A&D Determ. de Requerimientos

UCB TJA INF 342

55

Naturaleza de los requerimientos

Aplicaciones

Hosts (PCs, servidores)

Usuarios finales

Redes existentes

Diseño nueva red A&D Determ. de Requerimientos

UCB TJA INF 342

56

Requerimientos de usuario

Usuario

Usuario

Aplicación

Aplicación

Host

Host Red

• • • • • • • • • •

Oportunidad Interactividad Confiabilidad Calidad Adaptabilidad Seguridad Factibilidad Número de usuarios Ubicación de los usuarios Crecimiento esperado


UCB TJA INF 342

57

Requerimientos de usuario/servicio

Usuario

Usuario

Aplicación

Aplicación

Host

Host Red

• • • • • • • • • •

Oportunidad Interactividad Confiabilidad Calidad Adaptabilidad Seguridad Factibilidad Número de usuarios Ubicación de los usuarios Crecimiento esperado


UCB TJA INF 342

Retardo

Confiabilidad

Capacidad

58

Requerimientos de aplicación

Usuario

Usuario

Aplicación

Aplicación

Host

Host Red


UCB TJA INF 342

• Grupo de aplicación al que pertenece • Tipo de aplicación • Características de rendimiento de la aplicación • Ubicaciones de la aplicación

59

Requerimientos de Host Usuario

Usuario

Aplicación

Aplicación

Host

Host

• Tipos de hosts y equipamiento • Información sobre ubicaciones • Características de rendimiento de host/equipo

Red


UCB TJA INF 342

60

Requerimientos de red Usuario

Usuario

Aplicación

Aplicación

Host

Host Redes existentes

Redes existentes

• Escalabilidad • Servicios de red • Servicios de soporte • Interoperabilidad • Ubicación • Características de rendimiento de red

Redes existentes A&D Determ. de Requerimientos

UCB TJA INF 342

61

Otros requerimientos • Financieros o presupuestarios • Integración con otros tipos de medios de comunicación – teléfono – fax – video – etc.


UCB TJA INF 342

62

Contexto en el proceso de análisis Condiciones iniciales

Captura de requerimientos

Mapas de aplicaciones

Desarrollar métricas de Servicio

Vars. de adm. de red

Caracterizar comportamiento

Modif. De rend. Usuario/Aplicación

Desarrollar umbrales de rendimiento Tipos de aplicaciones Distinguir entre requerim de servicio Guía para distinguir servicios Especif. de requerim. Modelos de flujo Distribución de flujo

Establecer límites de flujo Identificar flujos backbone y compuestos

Características del flujo Algoritmo de especificación

Desarrollar especificación de flujos Plan de capacidad

UCB TJA INF 342

Plan de servicio

Etapa: Capturar y listar requerimientos • Se desarrolla en base a las condiciones iniciales, con entradas desde los usuarios, clientes y personal de la red, y luego debe ser refinado. • Subetapas – Determinar condiciones iniciales. Estas incluyen: • Tipo de proyecto (nueva red, modificación, análisis, outsourcing) • Ambito del diseño (tamaño, distancia, número de sitios) • Objetivos iniciales • Fuerzas externas (políticas, administrativas, financieras) – Trabajar con los usuarios (durante todo el proceso)

– Listar requerimientos y construir mapa de aplicaciones A&D Determ. de Requerimientos

UCB TJA INF 342

64

Etapa: Desarrollar métricas de servicio • Propósito: medir rendimiento • Por ejemplo: – SNMP/CMIP -> Usado para medir pérdidas de paquetes – Ping -> Usado para monitorear retardos en la red. Otros. Tabla ejemplo Métricas de servicio

¿Dónde se medirán?


UCB TJA INF 342

Método de medición

65

Etapa: Caracterizar el rendimiento • Objetivo – Determinar, si se puede estimar, el rendimiento de la red mediante la comprensión de cómo los usuarios y sus aplicaciones funcionarán a través de la red

• Subetapas – Definir patrones de uso • Un patrón simple sería: – – – –

Número de usuarios para cada aplicación Frecuencia de uso esperada (nº de sesiones /usuario_día) Duración promedio de la sesión Estimación del nº de sesiones simultáneas por aplicación

• Escoger los usuarios “más relevantes” A&D Determ. de Requerimientos

UCB TJA INF 342

66

Etapa: Caracterizar el rendimiento 2 • Subetapas (continuación) – Determinar comportamiento de la aplicación • Idea: Ajustar el rendimiento para la aplicación analizada • Considere determinar: – – – –

Tamaño de los datos que la aplicación procesará Frecuencia y duración de la transferencia de los datos Dirección del flujo (cliente <--> servidor) Grado de multicasting (simple <--> muy complejo)

• Escoger las aplicaciones “más relevantes”


UCB TJA INF 342

67

Etapa: Desarrollar umbrales de rendimiento • Tales como: – Umbrales generales – Umbrales específicos a un ambiente – Límites y garantías específicas por servicio

• Subetapas – Desarrollar umbrales de Confiabilidad • Disponibilidad • Nivel de recuperación de fallas • Tasa de error o pérdida


UCB TJA INF 342

68

Etapa: Desarrollar umbrales de rendimiento 2 • Subetapas (continuación) – Desarrollar umbrales de Retardo • Existen – Retardo de interacción(INTD). Entre 10 a 30 ms – Retardo de tiempo de respuesta humano (HRT) ≈ 100 ms – Retardo de propagación de la red (extremo a extremo, de ida y vuelta -RTT- y del sistema). Se pueden medir usando Ping

• Lo anterior permite calcular: respuesta del sistema = HRT/TCT, cuando HRT/RTT >= 1 respuesta del sistema = HRT/(RTT*TCT), cuando HRT/RTT < 1 – Si respuesta del sistema es menor a 3 => aplicación tipo FTP TCT: tiempo para completar una tarea A&D Determ. de Requerimientos

UCB TJA INF 342

69

Etapa: Desarrollar umbrales de rendimiento 3 • Subetapas (continuación) – Desarrollar umbrales de Capacidad

• La idea es estimar tasa de datos • Estas tasas pueden ser – Peak – Promedio – Bajo

• Una forma de estimar tasas de datos (cuando se desconoce información) es usar: – TCT – Cantidad de datos que se piensa transmitir. A&D Determ. de Requerimientos

UCB TJA INF 342

70

Etapa: Desarrollar umbrales de rendimiento 4

• Separar tipos de servicios. Se puede usar la siguiente pauta:

– Determinar si alguna de las aplicaciones tiene requerimientos específicos de rendimiento (determinístico o garantizado) – Tipificar las aplicaciones • Misión crítica • Tiempo real • Tasa controlada A&D Determ. de Requerimientos

UCB TJA INF 342

71

Etapa: Desarrollar umbrales de rendimiento 5

• Separar tipos de servicios

(continuación)

– Agrupar las aplicaciones • • • • • • •

De telemetría/Comando y Control Visualización Computación distribuida Acceso, desarrollo y uso de Web Transporte de datos Teleservicio De operación y administración


UCB TJA INF 342

72

Objetivos: nivel de servicio Disponibilidad de la red Tiempo medio entre fallas de hw Tiempo medio entre fallas de sw Tiempo de respuesta promedio Tiempo de reparación promedio Tiempo máx. de reparación Rendimiento de la red Throughput promedio Tiempo medio restaurar disco Tiempo medio restaurar archivo

UCB TJA INF 342

99.8 a 100% 1 mes 1 mes 10 minutos 1 hora 24 horas 95%, t. Resp. < 2s 64 kbps 4 horas 1 hora

73

Velocidades de transferencia APLICACION

VELOCIDAD

Comunicaciones personales Correo electrónico Programas de control remoto Consultas a base de datos Audio digital Acceso a imágenes Video comprimido Transmisiones médicas Imágenes documentales Imágenes científicas Video sin comprimir

300 a 9600 bps o más 2400 a 9600 bps o más 9600 a 56000 bps Superior a 1 Mbps 1 a 2 Mbps 1 a 8 Mbps 2 a 10 Mbps Superior a 50 Mbps 10 a 100 Mbps Superior a 1 Gbps 1 a 2 Gbps

Fuente: Netware 4.1. Manual de referencia. 2ªed. Tom Sheldon McGraw Hill 1994 A&D Determ. de Requerimientos

UCB TJA INF 342

74

Desarrollar Métricas de Servicio • Métricas para Confiabilidad – Disponibilidad – Estabilidad (MTBF,MTTR) – Características de Transmisión • Razón de Error de bits • Razón de Pérdida de Celdas • Razón de Pérdida de Paquetes/frames

UCB TJA INF 342

75

Métricas de Servicio • Métricas de Capacidad – Razón de Datos • Razón de datos peak • Razón de datos sostenido

– Tamaño de los datos • • • •

Tamaño de ráfaga y duración Tamaño del paquete/frame promedio y Máximo Distribución del tamaño de paquetes Tamaño de la Transacción UCB TJA INF 342

76

Métricas de Retardo • • • •

Extremo a Extremo / Ida y Vuelta Tiempo de respuesta del sistema host Variación del Retardo Variaciones con condiciones de cambio de red

UCB TJA INF 342

77

Herramientas de Medición en Red • Contadores SNMP en hubs/switches – cuenta el tránsito de los paquetes – Paquetes enviados – Paquetes eliminados – Errores

• Monitores Externos – Remote MONitoring (RMON)

UCB TJA INF 342

78

Herramientas de Medición en Red • Herramientas simples de Software – Ping – Netperf

• Herramientas de Análisis

UCB TJA INF 342

79

Monitor de Rendimiento entre redes CiscoWorks Blue Internetwork Performance Monitor • Localiza cuellos de botella de rendimiento • Provee alta disponibilidad de la red • Administración de Rendimiento Proactivo • Análisis de Tendencia en Rendimiento • Análisis de Rendimiento de redes mezcladas SNA/IP • Aumenta el operador de productividad • Redundancia, seguridad, y verificación

UCB TJA INF 342

2

Localizar Cuellos de Botella en Rendimiento

Usuario final IPM

• Análisis de Rendimiento Salto a Salto a través de la red UCB TJA INF 342

81

Análisis de Rendencia de Rendimiento • Chequea la red por períodos largos de tiempo • Muestra los tiempos máximos de respuestas • Muestra los tiempos mínimos de respuestas • Muestra tiempos de respuesta promedio • Muestra errores que podrían contribuir a tiempos de respuestas pobres UCB TJA INF 342

82

Redundancia, Seguridad y Verificación

• Identifica trayectorias redundantes en la red • Estima la utilización de rutas redundantes UCB TJA INF 342

83

Usando Ping y Pérdida de paquetes IP como medidas de Confiabilidad LAN

LAN

x

Red de Área Extendida

x

SNMP/CMIP es usado para obtener pérdida de paquetes de datos

Estación de Monitoreo de Red

Ping es usado entre varios interfaces para monitorear el retardo en la red

UCB TJA INF 342

84

Tabla de métrica de Servicio Métrica de Servicio

Donde la métrica será medida en el Sistema

UCB TJA INF 342

Método usado para la medida

85

Caracterizar el Comportamiento • Patrones de uso • Los patrones del uso pueden incluir para cada aplicación el número total de usuarios para cada aplicación • La frecuencia que se espera que un usuario use la aplicación (número de sesiones/día de uso) • Cuánto tiempo promedio durará una sesión de la aplicación (normalmente en segundos) • Una estimación del número esperado de sesiones de usuario simultáneas para la aplicación

UCB TJA INF 342

86

Patrones de uso Número de Sesiones Simultáneas

Frecuencia

Sesiones de Aplicación

Duración Sesión 1 Sesión 2 Sesión 3 Sesión 4

Activo Activo Activo

Activo Activo Activo

Activo

Activo Activo

Activo

Activo

Activo

Activo

UCB TJA INF 342

Activo

87

Caracterizar el Comportamiento • Comportamiento de la aplicación • Caracterizando el comportamiento de la aplicación, deseará considerar los tamaños de los datos que la aplicación estará procesando; la frecuencia y duración de tiempo para los datos a ser transferidos por la red; las características de flujo de tráfico para la aplicación, particularmente las direcciones de flujo (p.ej., del cliente all servidor); y el grado de multicasting en las comunicaciones (uno-a-uno, uno-a-muchos, muchos-a-muchos). • Modelos simples y complejos. UCB TJA INF 342

88

Desarrollo de Umbrales de Rendimiento – Distinguiendo entre los servicios al mejor esfuerzo, especificado, y servicios de alto/bajo rendimiento, usaremos el criterio siguiente: •1 Un umbral general puede usarse para separar requerimientos de rendimiento de bajo rendimiento y alto rendimiento. •2 Un umbral de ambiente-específico puede usarse para separar requerimientos de rendimiento en bajo rendimiento y alto rendimiento. •3 Los servicios especificados tendrán límites o garantías limitadas. UCB TJA INF 342

89

Requerimientos de Confiabilidad • La medida más común de confiabilidad está en los términos de disponibilidad, como porcentaje de tiempo en servicio o porcentaje de tiempo fuera de servicio. ¿Por ejemplo, un requerimiento para la propuesta de un usuario/cliente potencial final puede establecer un tiempo de servicio garantizado de 99.99%, pero que realmente significa? UCB TJA INF 342

90

Requerimientos de Confiabilidad • Disponibilidad • Para un sistema que da servicio todo el día, siete días a la semana a sus clientes, la disponibilidad puede pensarse como el tiempo en servicio o fuera de servicio en porcentaje por semana, mes, o por año, basado en la cantidad total de tiempo por ese periodo. Disponibilidad Cantidad de Tiempo fuera de Servicio Permitido (horas [h], minutos [m], o (% Tiempo de segundos [s] por periodo de tiempo) Servicio) Anual Mensual Semanal Diario 95 % 438 h 36,5 h 8,4 h 1,2 h 99,5% 43,8 h 3,7 h 50,5 m 7,2 m 99,95% 4,38 h 21,9 m 5,05 m 43,2 s 99,98% 1,75 h 8,75 m 2,0 m 17,3 s 99,99% 0,88 h 4,4 m 1,0 m 8,7 s

UCB TJA INF 342

91

Medición de Disponibilidad • ¿Cómo puede medirse la disponibilidad? Esta pregunta puede hacerse por lo menos en dos partes: dónde debe medirse la disponibilidad, y qué métrica de servicio puede usarse para medirlo? Donde la disponibilidad debe medirse depende de que el diseñador o el administrador está tratando de lograr.

x

Red de Área Extendida

x

FDDILAN

Interfaces de Red

Ethernet LAN

Monitores de Red

UCB TJA INF 342

92

Disponibilidad medida selectivamente entre redes Disponibilidad

Servidor de Lan

Usuarios LAN

Usuarios LAN

x

Disponibilidad

Usuarios LAN

UCB TJA INF 342

Usuarios LAN 93

Disponibilidad Disponibilidad

Anual

Mensual

95%

438 hrs.

36.5 hrs.

99.5%

43.8 hrs.

3.7 hrs.

99.95%

4.38 hrs.

21.9 mins. Mayoría sistemas comerciales

99.98%

1.75 hrs.

8.75 mins. Sistemas de Misión Crítica

99.99%

0.88 hrs.

4.4 mins.

99.999%

0.09 hrs.

.4 mins.

Testbeds

Sistemas de Tiempo Real Systemas de muy alta disponibilidad

UCB TJA INF 342

94

Tiempo de Reestablecimiento • MTBF/MTBSO y MTTR son tiempos promedios • MTBF y MTBSO estiman la frecuencia de paros del sistema. Por ejemplo, un MTBF/MTBSO de 4400 horas (o 2.64E5 minutos) establece que las fallas en el sistema son esperadas aproximadamente cada 6 meses (180 días). • MTTR da una estimación de cuánto tiempo los paros del sistema pueden durar. Por ejemplo, un MTTR de 60 minutos puede ser esperado si existe experiencia disponible en sitio, un MTTR de 4 horas (240 minutos) puede esperarse si la ubicación es remota y el acceso de discado al sistema no está disponible.

UCB TJA INF 342

95

Disponibilidad con MTBF/MTBSO y MTTR MTBF/MTBSO (Horas)

8000

MTTR

4000

4 horas 2 horas 1hora

2000 1000 400 .0 99

.5 99

.9 99 .95 99 8 .9 99

Disponibilidad (% Tiempo de Conexión) UCB TJA INF 342

96

Razones de Error y Pérdida • Las pérdidas pueden medirse en la capa de enlace o de la red, y se informa como un porcentaje de tráfico disponible en la red. Así, nosotros podríamos establecer umbrales de pérdidas de celdas, frames, o paquetes y periodos de tiempo, como en la Tabla.

Razón de Pérdida de Paquetes (como % del tráfico total de la red) 25% a 100% 2% a 24% < 2%

Tiempo Total Máximo (por mes) Hasta 2 horas Hasta 3 horas Resto del mes

UCB TJA INF 342

97

Umbrales para la confiabilidad • Evalúe los requerimientos de disponibilidad de cada una de las aplicaciones que se usarán en su ambiente, de las discusiones con usuarios de las aplicaciones o de la documentación para cada aplicación • Determine los umbrales de bajorendimiento/alto-rendimiento • Estime la disponibilidad basada en las rutas probables extremo-a-extremo que las aplicaciones usarán, y qué equipo y servicios existen o pueden estar en esas rutas. UCB TJA INF 342

98

Umbrales de referencia general para Requerimientos de Usuario Alto - Rendimiento Bajo - Rendimiento Testbed

99.0

99.5

99.9 99.95 99.98 Disponibilidad (%)

UCB TJA INF 342

99

Para Disponibilidad: Las estimaciones del umbral general son:

• Confiabilidad de Testbed o Prototipo (disponibilidad): menos de 95% • Confiabilidad de bajo-rendimiento (disponibilidad): menos de 99.9% • Confiabilidad de alto-rendimiento (disponibilidad): mayor que o iguala a 99.9% • (Nota: Éstos umbrales de disponibilidad son medidos mensualmente.) UCB TJA INF 342

100

Para el Reestablecimiento, medido como MTBF/MTBSO y MTTR, las estimaciones de umbral general son:

– Confiabilidad de bajo-rendimiento (reestablecimiento): MTTR mayor que 2 horas o un MTBF/MTBSO menos de 8000 horas – Confiabilidad de alto rendimiento (reestablecimiento): MTTR menor de o igual a 2 horas y MTBF/MTBSO mayor que o iguala a 8000 horas – (Nota: Estos umbrales de reestabecimiento se escogen para proveer un MTTR razonable. Si un MTTR más pequeño es escogido, entonces el MTBF /MTBSO será correspondientemente más bajo.) UCB TJA INF 342

101

Razón de pérdida de información de extremo-aextremo ó razón de retransmisión

• Bajo-rendimiento (razón Pérdidas de paquete IP de

de

pérdida):

25% por < 2 horas/mes 10% < pérdida del paquete < 25% por < 2 horas/mes 1% < pérdida del paquete < 10% por < 5 horas/mes < 1% por el resto del mes

UCB TJA INF 342

102

Requerimientos de Retardo H

Data Aplicación

Red Network

Componentes • Retardo de Interacción • Tiempo de Respuesta Humano • Retardo de propagación de la red

Host UCB TJA INF 342

103

Retardo de Interacción (INTD) • estima cuánto tiempo un usuario está deseoso esperar por una contestación del sistema durante una sesión interactiva. • Los retardos de la interacción pueden ir de unos pocos segundos a un minuto o más. En general, un rango útil es 10 a 30 segundos. UCB TJA INF 342

104

Tiempo de Respuesta Humano (HRT) – estima el límite de tiempo cuando los usuarios empiezan a percibir retardo en el sistema. – Cuando el tiempo de respuesta del sistema está debajo del HRT, los usuarios generalmente no perciben retardo en el sistema. – Sobre el HRT, los usuarios notarán el retardo del sistema y puede llegar a frustrarse. – Una estimación buena del HRT es aproximadamente 100 ms. UCB TJA INF 342

105

Tiempo de Respuesta Humano (HRT) – HRT es importante para las aplicaciones muy interactivas, donde los tiempos de espera no pueden o no deberían ser percibidos por el usuario. – Éste normalmente es el caso cuando la aplicación apoya un ambiente interactivo para el usuario, como en visualización, realidad virtual, y las aplicaciones colaborativas, pero también puede aplicarse a las aplicaciones donde el retardo del sistema más allá de HRT produce pérdida de productividad.

UCB TJA INF 342

106

Retardo de propagación de red – Estima el retardo de la propagación de la señal en la red. – Esto proporciona un límite inferior a los retardos de extremo-a-extremo y de ida y vuelta de la red y del sistema. – El retardo de la propagación es dependiente en la distancia y tecnología. – Es útil como un límite inferior de retardo, porque nos dice cuando una aplicación no puede trabajar bien por la red, cuando sus requerimientos de retardos son más severos que el retardo de la propagación por la red. UCB TJA INF 342

107

Estimación de retardos para requerimientos de usuarios Tiempo de Respuesta Humano

Retardo de Interacción Retardo de Propagación de Red

0.01

0.1

1.0 10 Retardo (Segundos)

UCB TJA INF 342

100

108

Distinción entre aplicaciones de Ráfaga y Volumen Ráfaga Interactivo

0.01

Ráfaga/Volumen Interactivo

Volumen Interactivo

0.1 1.0 10 Retardo (Segundos) Tiempo de Respuesta Humano

100

Retardo Interactivo UCB TJA INF 342

109

Tiempo de realización de Tarea (TCT) – El uso de INTD y HRT posiblemente es la manera más directa de distinguir entre las aplicaciones de ráfaga interactivo y las aplicaciones de volumen interactivo, pero a veces se necesita un análisis más detallado. – Para aquellos tiempos, podemos definir un tiempo de realización de tarea (TCT) para la aplicación, donde una tarea es la cantidad de trabajo de tiempo que está siendo realizado por el sistema antes de requerir la interacción con el usuario. – TCT, medido en segundos, y el retardo de extremo-aextremo RTT medido en milisegundos.

UCB TJA INF 342

110

Tiempo de realización de Tarea (TCT) Tiempo Tarea Completada Retardo

Transferencia de Datos 3

Dato Recibido / Procesado

TCT Retardo


Retardo


Transferencia de Datos 2 Transferencia de Datos 1 Fuente

Destino

Esta conducta es consistente con aplicaciones que están procesando transacciones y cómputos distribuidos, o son cliente-servidor. UCB TJA INF 342

111

Razón HRT a RTT • La razón de HRT a RTT describe el grado de respuesta inherente en el sistema que es dependiente en la distancia que la aplicación está comunicando. • Un RTT pequeño (relativo al HRT) significa que la distancia es suficientemente pequeña que la respuesta del sistema estaría dentro del tiempo de HRT, mientras que un RTT grande significa que el retardo impactará la respuesta del sistema. UCB TJA INF 342

112

Tiempos de RTT, TCT y HRT • La respuesta del sistema también es en parte debida al TCT de la aplicación. La respuesta del sistema puede ser descrita por la razón de HRT, RTT, y TCT (donde HRT y RTT son medidos en milisegundos, y TCT es medido en segundos):

UCB TJA INF 342

113

Respuesta del Sistema • Respuesta del sistema = HRT/TCT, cuando HRT/RTT >= 1 • Respuesta del sistema = HRT/(RTT*TCT), cuando HRT/RTT < 1 • Respuesta del sistema < 3 (volumen interactivo) • Respuesta del sistema > 3 (ráfaga interactivo) UCB TJA INF 342

114

Ejemplo – una red que tiene un RTT (o tiempo de ping) de 100 milisegundos (un valor aproximado para una red que cruza los Estados Unidos continentales) y un TCT de 10 segundos tendría una respuesta del sistema de: HRT/RTT = 100ms/l00ms = 1 – Respuesta del sistema = 100ms/l0s = 10 – Entonces, aplicación es Ráfaga Interactivo.

UCB TJA INF 342

115

Burstiness • Otra manera de distinguir entre las aplicaciones ráfaga interactivo y las aplicaciones volumen interactivo es con las razones de los datos. • Burstiness se define como: • Burstiness = PDR/SDR donde PDR y SDR son razón de datos peak y sostenido respectivamente UCB TJA INF 342

116

Retardo de extremo-aextremo • está compuesto de muchas fuentes de retardo, tales como propagación, encolamiento, transmisión, I/O, conmutación, y procesamiento. • Verificar todas las rutas para encontrar los cuellos de botellas para hacer correr la aplicación.

UCB TJA INF 342

117

Variación de Retardo – La variación de retardo está acoplada con el retardo de alto rendimiento o especificado para dar un retardo global para aplicaciones que son sensible al tiempo de arrivo de la información. – Algunos ejemplos de tales aplicaciones son aquellos que producen o usan video, audio, y información de telemetría. Para variaciones de retardo acoplada con retardo, cuando ninguna información está disponible sobre la variación de retardo, una regla buena es aproximadamente 1% a 2% del retardo de extremo-a-extremo. – Por ejemplo, una estimación para la variación de retardo en la ausencia de cualquier otra información, cuando el retardo de extremo-a-extremo de una aplicación es 40 ms, es aproximadamente 400 a 800 microsegundos UCB TJA INF 342

118

Requerimientos de capacidad • Razón de Datos • Tamaño de los datos Aplicación

Cálculo Distribuido (Modo Batch) Transacciones tipo Web Consultas Base de Datos Ingresos de Pagos Teleconferencia (usando Multicast)

TCT Promedio (Segundos) 103

Tamaño de Datos Promedio (Bytes) 107

10 2- 5 10 103

104 103 102 3*105

UCB TJA INF 342

119

Ejemplos • Podemos preguntarles a varios usuarios qué tamaños de archivos ellos esperan transferir, y cuánto tiempo ellos están deseosos esperar por la transferencia. • Considere una aplicación de procesamiento de datos interactiva remota que se conecta a las tiendas de detalles y procesa información de los clientes, tal como entradas de tarjeta de crédito. • Podemos basar una tarea como el proceso de la información de tarjeta de crédito de un solo cliente. Entonces, el TCT necesita estar en el orden de INTD discutida anteriormente – aproximadamente de 30 segundos, aunque aquí puede esperarse que sea mucho más pequeño, digamos en el orden de 5 a 10 segundos, y los tamaños de los datos por cada tarea es bastante pequeño, en el orden de 100 a 1000 bytes. UCB TJA INF 342

120

Ejemplos • Otro ejemplo es un ambiente de computación donde múltiples hosts están compartiendo el procesamiento para una tarea. • En cada iteración de la tarea, los datos se transfieren entre los hosts. • Aquí podemos saber la frecuencia del traslado de los datos, el tamaño de cada transferencia (qué también puede ser constante), y cuánto tiempo se requiere para procesar los datos (qué indicará cuánto tiempo una transferncia puede tomar). • Un ambiente de computación multiprocesador compartido, se muestra en la siguiente figura. UCB TJA INF 342

121

Ejemplo de un ambiente de Cómputo con Multiprocesadores Servidor

Nodos de Cómputos

50 KB / iteración 25 iteraciones / segundo 4 ms Tiempo Procesamiento / iteración

1a Iteración

2a Iteración

Procesamiento Transf. Datos

3a Iteración

Procesamiento

Transf. Datos

4a Iteración

Procesamiento

Transf. Datos

UCB TJA INF 342

Procesamiento

Transf. Datos 122

Región de Rendimiento con Umbrales Genéricos Retardo (D)

Umbral del Retardo Genérico

Regiones de Alto Rendimiento

Región de Bajo Rendimiento Umbral de Capacidad Genérica

Umbral de Confiabilidad Genérica

Confiabilidad (R)

Capacidad (C)

UCB TJA INF 342

123

Umbrales de Servicio de ambiente específico • Los umbrales generales nos dan algunas estimaciones comúnes para las características de bajo y alto rendimiento. • Tales umbrales son útiles cuando hay una falta de información sobre los usuarios y aplicaciones para la red a diseñár, pero a menudo el ambiente indica que umbrales de rendimiento deberían ser. • Como con umbrales generales, la razón por desarrollar umbrales de ambiente específico es para determinar qué aplicaciones tienen características de alto rendimiento. • Es probable que estas aplicaciones de alto rendimiento son lo que nosotros diseñaremos, junto con esas aplicaciones que tienen características especificas.

UCB TJA INF 342

124

Comparando Características de la Aplicación • Cuando podemos agrupar características de la aplicación, entonces una comparación puede hacerse a menudo para determinar donde el umbral puede aplicarse. • Considere un gráfico de características de retardo para varias aplicaciones, A a través de M, para un ambiente particular, como se muestra en la figura 3-13. • En este diagrama, se agrupan características de retardo en dos áreas. • Podemos usar esta información para poner un umbral de ambiente específico a un retardo de aproximadamente X milisegundos. • Esas aplicaciones que tienen una característica de retardo de menos de X milisegundos son consideradas de alto rendimiento para este ambiente.

UCB TJA INF 342

125

Características de Retardo para una muestra de aplicaciones Bajo - Rendimiento

Aplicaciones (Denotadas por letras)

Alto - Rendimiento

K

J

E G

H

D

L

A C

B

X ms

M F

I

Retardo (ms)

UCB TJA INF 342

126

Caracterización de

los servicios

Peticiones de servicio. Identificadas por el grado de predecibilidad del servicio ` Mejor voluntad. Ningún control sobre la red. Esta tratará de

a

cumplir lo mejor posible la petición sin ninguna garantía. ⌧Servicio impredecible. Resultados variables desde el punto de vista del rendimiento ⌧El resto de componentes deberán adecuarse al estado de la red en un momento dado

` Específico. Determinista o garantizado. Algún tipo de control sobre la red.

a Los servicios deben operar dentro de unos márgenes ⌧Necesidad de poder efectuar mediciones para comprobar si las características de la petición coinciden con las realmente proporcionadas por la red. ⌧Contratos de servicio: Acuerdos de Nivel de Servicio: SLA UCB TJA INF 342

6

Servicios Deterministicos • Los servicios deterministicos tienen características de rendimiento más específicos que el servicio al mejor esfuerzo que hemos estado discutiendo. • En la mayoría de los casos, tendremos una buena estimación de éstos características de rendimiento, aunque no podremos garantizar rendimiento. • Usaremos límites para aproximar donde están los niveles de bajo y alto rendimiento, los cuales se usarán en el proceso del diseño mas tarde en este libro para planificar la capacidad y la especificación de flujo. UCB TJA INF 342

128

Servicios garantizados •

• •

•

Los servicios garantizados son un paso más allá de los servicios deterministicos, en que hay algún mecanismo para forzar al servicio a la aplicación o usuario. Así para desarrollar los requerimientos para los servicios garantizados, necesitamos tener características de rendimiento bien definidas. En la siguiente figura, el rendimiento de una aplicación se acerca al límite del servicio (garantizado). Ninguna acción se toma hasta que la aplicación excede su garantía, donde ocurre la vigilancia. Al elemento de la red donde ocurre la vigilancia, esto puede tomar la forma de marcar el paquete/frame/celda para que los elementos de red de flujo hacia abajo asuman alguna acción, o dejando caer el frame/paquete/celda en ese elemento de la red. Vigilar es a menudo útil para proteger el flujo de tráfico que fluye hacia abajo que excede su límite de servicio y intenta usar más recursos de la red que el contratado.

UCB TJA INF 342

129

Vigilancia de rendimiento de un flujo Servicio Límite / Garantía (p.ej., capacidad) Vigilancia No Acción tomada Garantía

Comportamiento de la Aplicación Time UCB TJA INF 342

130

Servicios garantizados – Se desarrollan garantías de servicio en una forma similar para servir los límites, excepto que se declara la necesidad de pedir una garantía explícitamente. – En el ejemplo de asignación de recursos arriba, declaramos que la meta de confiabilidad era 99.99%, pero que debemos reunir una confiabilidad de por lo menos 99.97%. – Este límite más bajo para confiabilidad podría declararse como una garantía de servicio que significaría que después en el proceso del diseño lo consideraríamos como los mecanismos para proporcionar y vigilar ese servicio en el sistema. UCB TJA INF 342

131

• En la figura siguiente, los umbrales de servicio, límites, y garantías son ahora todos aplicados al sobre de rendimiento de servicio. • En esta figura, las regiones de bajo y alto rendimiento están separadas por los umbrales generales D, M, y X, mientras un retardo de ambiente-específico, C, existe dentro de la región de bajo-rendimiento. Se muestran límites de servicio y garantías aquí en la región alto rendimiento, en varias situaciones en el sobre.

UCB TJA INF 342

132

Sobre de Rendimiento Completamente Desarrollado Retardo (D) B ms A ms D ms C ms

X%

Z% Y%

M Mb/s

Confiabilidad (R)

L MB/s Capacidad (C)

A, B, Y -Servicios Garantizados D, M, X -Umbrales Genéricos C-Ambiente de umbrales específicos L, Z-Límites de Servicio

UCB TJA INF 342

133

Aplicación de Telemetría • Primero consideremos un ambiente de aplicación de telemetría, como es mostrado en la figura. Control Guiado Computador de Control de Guiado Telemetría

RED

Computador Visiualización de movimiento

UCB TJA INF 342

134

Aplicación de Telemetría – En un análisis de este ambiente, hemos determinado (de las discusiones con los usuarios finales y diseñadores de la aplicación) que para que esta aplicación sea útil, los datos deben ser recibidos por la computadora de comando guiado dentro de 20 ms después de ser generados del helicóptero. – También sabemos que el controlador actuará recíprocamente con el helicóptero basado en la entrada de flujo de telemetría, y que esto será ligado por el HRT para la aplicación (100 ms). De esta información, podemos limitar el retardo del flujo de telemetría, como es mostrado en la siguiente figura.

UCB TJA INF 342

135

Aplicaciones de Telemetría

Limites de Retardo para el ejemplo de Telemetría

20 ms

Retardo (ms) UCB TJA INF 342

100 ms (HRT) 136

Consolidando la Computación Figura 3-19 Antes de la Consolidación Chicago Usuarios Almacenamiento Mainframe

Red

WAN Denver

Red

Memphis Red

Chicago

Después de la Consolidación Asignador Recursos

Storage Farm Usuarios

Red

WAN Denver

Red

Asignador Recursos Red

Cluster de Cómputo Asignador Recursos

UCB TJA INF 342

Memphis

137

Consolidando la Computación – La aplicación primaria en este ambiente es un asignador de recursos de computación, una aplicación que chequea los recursos dentro del sistema y asigna trabajos de computo a cada uno de los servidores de computación, basada en los requerimientos del trabajo. – La asignación se hace rápidamente, en el orden de 250 ms, y el estado de cada servidor de computación está constantemente verificándose. – Antes de la consolidación, la confiabilidad de los servidores de computación a sus usuarios estaban sobre 99.97%, mientras la meta de fiabilidad era sólo de 99.95%. – Para el ambiente consolidado, ellos quieren esforzarse para un grado mejor de confiabilidad y esperan lograr 99.99%, pero aceptará un grado más bajo de confiabilidad, aunque no debajo de la confiabilidad real del sistema anterior (99.97%). UCB TJA INF 342

138

Consolidando la Computación • Aquí tenemos un límite de confiabilidad de alto rendimiento para diseñar hacia (99.99%), y un límite del bajo-rendimiento que debe ser mantenido (99.97%). • Este límite más bajo posiblemente debe ser considerado como una garantía de servicio, pero aquí nosotros lo trataremos como un límite deterministico. • Se muestran los límites en la confiabilidad para esta aplicación de asignación de recursos en la figura siguiente.

UCB TJA INF 342

139

Límites de Confiabilidad para Aplicaciones de Asignación de Recursos Mínimo

Meta

Después de Consolidación

Meta

Actual

99.95%

99.97%

Antes de Consolidación

99.99%

Confiabilidad (% Uptime)

UCB TJA INF 342

140

Sobre de Rendimiento de Aplicación de Servicios • Pueden aplicarse los límites deterministicos para todas las características de rendimiento a un sobre de rendimiento para la aplicación. • Por ejemplo, si nosotros tenemos una aplicación que requiere el siguiente rendimiento especificado: – la confiabilidad, 99.8%; – la capacidad, entre 14 y 20 Mb/s; – y retardo, no mayor que 80 ms, podemos aplicarlos como es mostrado en la siguiente figura. UCB TJA INF 342

141

Sobre de Rendimiento con Servicio Especificado R e ta rd o (D ) 80 m s

9 9 .8 % D is p o n ib ilid a d

C o n fia b ilid a d (R ) 1 4 M b /s 2 0 M b /s

C a p a cid a d (C )

UCB TJA INF 342

142

Distinguiendo entre los Niveles de Rendimiento de Servicio – tenemos las descripciones para varios niveles de servicio (rendimiento y función), como servicios al mejor esfuerzo, bajo rendimiento, alto rendimiento, y servicios especificados. – Hemos tocado aplicaciones como misión-crítica, tiempo real, y razón controlada para distinguirlos de los servicios específicos necesitados, y también hemos desarrollado umbrales generales y de ambiente específico para separar los requerimientos de rendimiento en bajo y alto rendimiento para su ambiente del diseño. – Ahora, examinaremos algunas pautas para ayudarle a usar estos conceptos juntos para distinguir entre los niveles de rendimiento de servicio para sus diseños.

UCB TJA INF 342

143

Pautas en la Distinción de Servicios • Usted debe usar estos pasos cuando usted quiere ver, en parte o en conjunto, modificando su secuencia para encajar mejor su metodología de análisis y ambiente de diseño. • Para que usted aplique estos pasos, usted necesita tener un listado de las aplicaciones que probablemente se usarán en esta red, junto con cualquiera información de rendimiento que usted puede recoger, derivar, o estimar. • Estos pasos van del requerimiento más específico con los requerimientos de aplicaciones a el más específico, de talmodo que el último paso sea el valor por defecto cuando ninguno de los otros pasos se aplican.

UCB TJA INF 342

144

Pautas en la Distinción de Servicios • 1. El primer paso es determinar si cualquiera de las aplicaciones tienen requerimientos obvios para especificar (deterministico o garantizado) el rendimiento del sistema. • Cuando una aplicación tiene requerimientos para el rendimiento especificado, la aplicación y sus requerimientos son nombrados como especificados.

UCB TJA INF 342

145

Pautas en la Distinción de Servicios • 2. El segundo paso es listar las aplicaciones. ¿Cuándo no se identifican aplicaciones que tengan requerimientos especificados, pueden identificarse como de misión-crítica, tiempo real, o razón controlada? • En ese caso, pueden tener requerimientos especificado de rendimiento, aun cuando ellos no se reconocieron en el primer paso.

UCB TJA INF 342

146

Pautas en la Distinción de Servicios • 3. El tercer paso es aplicar grupos de aplicaciones a las aplicaciones. Para esas aplicaciones que no tienen requerimientos especificados obvios, y no puede listarse como misión-crítica, tiempo real, o razón controlada, evaluar si ellos pueden agruparse como de comando/telemetría; visualización; computo distribuído; acceso de Web, desarrollo, y uso; transporte de datos de volumen; el teleservicios; o aplicaciones de OAM. • Es probable que esas aplicaciones que no pueden ser descritas por Pasos l a través de 3 sean aplicaciones al mejor esfuerzo.

UCB TJA INF 342

147

Análisis de Flujo Condiciones iniciales


Análisis


Diseño


UCB TJA INF 342


UCB TJA INF 342

Análisis de flujo • Un flujo – Es transmitido durante una sola sesión de una aplicación/host (end-to-end) – Es información sobre un conjunto de protocolos y aplicaciones que

• Tienen atributos comunes, tales como – – – –

Direcciones destino y fuente -> Fuente/Sumidero Tipo de información Ruteo, Información extremo a extremo

– Tiene requerimientos de servicio constante Introducción A&D de Redes

UCB TJA INF 342

150

Análisis de flujo 2 • Existen modelos de flujo – Peer-to-peer – Cliente/servidor Computación cooperativa – Computación distribuida. • Existen aquí: – Administrador de tareas

– Nodos de cómputo • Subtipos: – Agrupación de computación – Procesamiento paralelo


UCB TJA INF 342

151

Análisis de flujo 3 • Hay tres tipos de flujos – Individual – Compuesto – Backbone

• Los cuales se deben localizar y especificar


UCB TJA INF 342

152

Fronteras de datos, flujos compuestos y troncales fd/g

fc/e

fa f

C

A

b

CF1 CF2

80

fa f c/e f d/g

fd/g f b fa f c/e

fa f f c/e d/g ff

BB1

GW B

CF6

fa

ff

fa CF3 f fc/e d/g

CF4 f fd/gc/e CF5 fa BB2 fc/e f a 60 fd/g CPD

30 75

UCB TJA INF 342

Diseño lógico Condiciones iniciales


Análisis

Análisis de flujo

Diseño lógico

Diseño


UCB TJA INF 342


Piramide de Akapana – La Paz

Diseño Lógico Modelo de Redes Jerárquicas

Piramide de Akapana – La Paz

UCB TJA INF 342

Diseño lógico • Subetapas – – – –

Establecer objetivos de diseño Evaluar y seleccionar tecnología Desarrollar un plan de interconectividad Considerar Administración y seguridad de la red


UCB TJA INF 342

156

Objetivos • Introducir al lector en el diseño de las Redes LAN utilizando el modelo Jerárquico • Describir cómo una red jerárquica admite las necesidades de voz, video y datos de una pequeña y mediana empresa • Identificar las características que deben cumplir los switch´s utilizados con cada capa del modelo de red jerárquico UCB TJA INF 342

Modelo de Redes Jerárquicas

• Beneficios del modelo de red jerárquico

UCB TJA INF 342

Modelo Jerárquico

UCB TJA INF 342

Modelo Jerárquico (capa por capa) La capa de acceso hace interfaz con dispositivos finales como las PC, impresoras y teléfonos IP, para proveer acceso al resto de la red. Esta capa de acceso puede incluir routers, switches, puentes, hubs y puntos de acceso inalámbricos. El propósito principal de la capa de acceso es aportar un medio de conexión de los dispositivos a la red y controlar qué dispositivos pueden comunicarse en la red.

UCB TJA INF 342

Modelo Jerárquico (capa por capa) La capa de distribución agrega los datos recibidos de los switches de la capa de acceso antes de que se transmitan a la capa núcleo para el enrutamiento hacia su destino final. La capa de distribución controla el flujo de tráfico de la red con el uso de políticas y traza los dominios de broadcast al realizar el enrutamiento de las funciones entre las LAN virtuales (VLAN) definidas en la capa de acceso. Las VLAN permiten al usuario segmentar el tráfico sobre un switch en subredes separadas.

UCB TJA INF 342

Modelo Jerárquico (capa por capa) La capa núcleo del diseño jerárquico es la backbone de alta velocidad de la internetwork. La capa núcleo es esencial para la interconectividad entre los dispositivos de la capa de distribución, por lo tanto, es importante que el núcleo sea sumamente disponible y redundante. El área del núcleo también puede conectarse a los recursos de Internet. El núcleo agrega el tráfico de todos los dispositivos de la capa de distribución, por lo tanto debe poder reenviar grandes cantidades de datos rápidamente.

UCB TJA INF 342

Diseño Lógico y Diseño Físico

UCB TJA INF 342

Diseño Lógico y Diseño Físico

UCB TJA INF 342

Principios clave del diseño de red jerárquica Diámetro de la red •

UCB TJA INF 342

Al diseñar una topología de red jerárquica, lo primero que debe considerarse es el diámetro de la red. Con frecuencia, el diámetro es una medida de distancia pero en este caso se utiliza el término para medir el número de dispositivos. El diámetro de la red es el número de dispositivos que un paquete debe cruzar antes de alcanzar su destino. Mantener bajo el diámetro de la red asegura una latencia baja y predecible entre los dispositivos.

Principios clave del diseño de red jerárquica Agregado de Ancho de banda: • Cada capa en el modelo de redes jerárquicas es una candidata posible para el agregado de ancho de banda. El agregado de ancho de banda es la práctica de considerar los requisitos de ancho de banda específicos de cada parte de la jerarquía. • EtherChannel UCB TJA INF 342

Principios clave del diseño de red jerárquica • Redundancia: es una parte de la creación de una red altamente disponible. Se puede proveer redundancia de varias maneras. Por ejemplo, se pueden duplicar las conexiones de red entre los dispositivos o se pueden duplicar los propios dispositivos.

UCB TJA INF 342

Convergencia • La convergencia es el proceso de combinación de las comunicaciones con voz y video en una red de datos. • Las redes convergentes necesitaban una administración extensiva en relación con la Calidad de Servicio (QoS), porque era necesario que el tráfico de datos con voz y video se clasificara y priorizara en la red.

UCB TJA INF 342

Describir cómo una red jerárquica admite las necesidades de una pequeña y mediana empresa • Describir la función de una red convergente al admitir las necesidades de voz, video y datos de una pequeña y mediana empresa (PyME)

UCB TJA INF 342

Hacer coincidir el switch Cisco apropiado con cada capa del modelo de red jerárquico

• Identificar las consideraciones que se usan para seleccionar un switch para una red jerárquica

UCB TJA INF 342

Hacer coincidir el switch Cisco apropiado con cada capa del modelo de red jerárquico • Identificar las características clave de los switches que se usan en redes jerárquicas

UCB TJA INF 342

Hacer coincidir el switch Cisco apropiado con cada capa del modelo de red jerárquico • Identificar las características de los switches que se encuentran en cada nivel de una red jerárquica

UCB TJA INF 342

Hacer coincidir el switch Cisco apropiado con cada capa del modelo de red jerárquico

• Identificar los switches Cisco que se usan en aplicaciones de PyME Pequeña y mediana empresa

•

)

UCB TJA INF 342

Resumen • El modelo de diseño jerárquico ofrece rendimiento, escalabilidad, facilidad de mantenimiento y facilidad de administración. • El análisis de tráfico se usa para controlar el rendimiento de red. • El modelo de diseño jerárquico está compuesto por 3 capas: Acceso Distribución Núcleo • Los switches que se eligen para cada capa deben cumplir las necesidades de cada capa jerárquica y las de la empresa. UCB TJA INF 342

Diseño Físico

UCB TJA INF 342

Diseño Físico Condiciones iniciales


Análisis Análisis de flujo Diseño lógico

Diseño Diseño físico Direccionamiento y ruteo Diseño Físico

176

UCB TJA INF 342


Diseño físico • Subetapas – Evaluar opciones de diseño de cableado • Opciones – Centralizado – Distribuido

• Considerar componentes medioambientales

– Ubicar el equipo de la red • Existen reglas par asegurar las ubicaciones más adecuadas • Esquemas – Centralizado – Distribuido

– Construir diagramas físicos de la red (nro. puertas, dirs...) Introducción A&D de Redes

UCB TJA INF 342

177

Etapas del diseño físico Diseño lógico

Evaluar diseño del cableado Ubicar equipos de red Construir diagramas físicos Direccionamiento y ruteo Diseño físico

Diseño Físico

178

UCB TJA INF 342

Etapa: Evaluar diseño de cableado • Opciones: – Centralizado – Distribuido

• Componentes medio ambientales a considerar – Calor, ventilación – Dimensiones, espacio – Corriente, reguladores de voltaje, UPS

Diseño Físico

179

UCB TJA INF 342

Etapa: Ubicar equipos de red • Reglas – Elegir lugares que tengan suficiente soporte medioambiental – Elegir lugares físicamente seguros – Etiquetar cada equipo claramente • Desarrollar un esquema de códigos

• Esquemas – Centralizado – Distribuido • • • • Diseño Físico

Reduce tamaño de grupos(redes, subredes, broadcast) Crear jerarquías Acerca los equipos a los usuarios Dificult la administración 180

UCB TJA INF 342

Etapa: Ubicar equipos de red • Codificación – Considerar información como: Nombre del sitio o ID Categoría del sitio (considerar clases) Nombre y/o número del Campus/Edificio Número del piso Número de la pieza Número del rack Tipo del equipo Dirección IP (local y remota) Números de puerto Tipo de circuito, tecnología/servicio Capacidad, ancho de banda, velocidad del circuito, tecnología/servicio • Red, enlace de datos, y/o protocolos de ruteo usados • • • • • • • • • • •

Diseño Físico

181

UCB TJA INF 342

Etapa: Ubicar equipos de red • Ejemplo de Clases de sitios terminales en una LAN – Clase 1 (C1). LAN que no tiene conexiones externas (routers). El acceso está limitado a computadores conectados directamente – Clase 2 (C2). LAN conectada a otras LAN vía routers, pero que no tiene computadores conectados directamente – Clase 3 (C3). LAN que tiene tanto computadores conectados directamente como conexiones de routers a otras LANs Diseño Físico

182

UCB TJA INF 342

Etapa: Ubicar equipos de red • Codificación – Ejemplo Nombre sitio, ID dirección IP remota/Dirección IP local Puerto local-puerto remoto/velocidad/protocolo/clase/servicio MATRIX S.A., #151-2 199.99.99.1/199.99.99.1 541-542/E1/OSPF/C2/RDSI-BE – Esta información debería guardarse en una base de datos que describa todos los componentes de la red, y ser escrita en etiquetas a ser pegadas a cada componente. Diseño Físico

183

UCB TJA INF 342

Etapa: Ubicar equipos de red • Hub – Cerca de los usuarios (descentralizado) => más hubs – Lejos de los usuarios (centralizado) => más cables

• Router – Ubicar cerca de las líneas de demarcación hacia el exterior de la red (subred)

– Centralizado=> coincide con la ubicación central de la red – Descentralizado => distribuido

• Switch – Similar a los hubs

Diseño Físico

184

UCB TJA INF 342

Etapa: Construir diagramas de la red DISEÑO LOGICO

.3

.2

.2

199.200.50.0 .1

.3

199.200.51.0

.2

.3

199.200.52.0

.4

.1 .5

.1

.6 Diseño Físico

185

UCB TJA INF 342

Etapa: Construir diagramas de la red 2 Pieza 208

23

24

P1

P4

22

DISEÑO FÍSICO

21

P1

P2 P1

P3 E11 E13 Edificio A Pieza 104

P4 E12

P2 PP2/Ptrt3

PP1/Ptrt2

186

UCB TJA INF 342

2 3 4 5

PP1/Ptrt1

Edificio B Pieza 100

PP1/Ptrt2 : Patch Panel 1 / Puerta 2 Diseño Físico

P4

1

Direccionamiento y ruteo – Ejecución del diseño Condiciones iniciales


Análisis


Diseño

Diseño físico

Direccionamiento y ruteo Introducción A&D de Redes

UCB TJA INF 342


Direccionamiento y ruteo • Subetapas – – – –

Establecer flujos de ruteo Manipular flujos de ruteo Desarrollar una estrategia de direccionamiento Desarrollar una estrategia de ruteo

• Considerar construir, según situación – Subredes – Superredes


UCB TJA INF 342

188

Antes de la ejecución • Escribir un plan de implementación • Evaluar vendedores y productos • Desarrollar pruebas de aceptación de equipos y servicios • Determinar cómo ajustar la red instalada para optimizar el rendimiento


UCB TJA INF 342

189

Ejecución • Consta de: – – – – –

Instalación eléctrica Tendido de cables: rack, ductos, patch panel, etc Instalación de equipos Respaldar y restaurar en caso de equipos existentes Configuración • • • •

Protocolos Cuentas de usuario Aplicaciones Servicios, ...

– Pruebas y análisis de sensibilidad Introducción A&D de Redes

UCB TJA INF 342

190

Caso de Estudio 1 Actualización de la Red

UCB TJA INF 342

Introducción • Tenemos un colegio con 3 edificios, cada uno de ellos destinado a una función especifica. • Vamos a detallar el diseño actual de la red y a proponer una mejora de dicho diseño. UCB TJA INF 342

Diseño Actual de la Red • •

• •

•

Tenemos una red de clase C privada 192.168.2.0 De ésta forma podemos tener conectados hasta 254 ordenadores, (256 menos la dirección con el campo host todo a 0s: identifica a la propia red, y la dirección con el campo host todo a 1s: broadcast en toda la red). En total tenemos 36 ordenadores, con lo que tenemos suficiente con una red de éste tipo. En cuanto al tipo de Red tenemos una Fast Ethernet, que además de poder llegar hasta 100Mbits/seg. es totalmente compatible con el estándar Ethernet. Todos los ordenadores están conectados mediante hubs y cables de pares trenzados, cuya longitud máxima es de 100m. Únicamente tenemos un switch para conectar los edificios A y C que están separados, y un router que utilizaremos para la conexión a Internet.

UCB TJA INF 342

Diseño Actual de la Red Edificios A y B

UCB TJA INF 342

Diseño Actual de la Red Edificio C

UCB TJA INF 342

Tipos de Red Clasificación según su tamaño y extensión: Redes LAN: Redes de área local, su extensión varía entre 10m. y 1km. Redes pequeñas con velocidad de transmisión entre 10 y 100 Mbps Redes MAN: Redes de área metropolitana, suelen abarcar el tamaño de una ciudad. Longitud máxima de 10km. Redes WAN: Redes de área amplia. Son una colección de hosts o de redes LAN conectadas por una subred. Su tamaño varía entre 100 y 1000km.

Clasificación según la tecnología de transmisión: Redes Broadcast: Todas las máquinas de la red comparten el mismo canal de comunicación. Cada paquete enviado por cualquier máquina es recibido por todas las de la red. Redes Point to Point: En éstas redes los paquetes a veces tienen que pasar por hosts intermedios, por lo que es necesario el uso de un router para la creación de las rutas.

Clasificación según la transferencia de datos soportada: Redes de transmisión simple: Los datos únicamente viajan en un sentido. Redes Half-Duplex: Los datos pueden viajar en uno u otro sentido pero no simultáneamente, es decir solo puede haber transferencia en un sentido a la vez. Redes Full-Duplex: Los datos pueden viajar en ambos sentidos al mismo tiempo.

UCB TJA INF 342

Topología de la Red Topologías LAN más comunes: Token Ring: Topología de bus lógica y en estrella física o en estrella extendida. Es una implementación del estándar IEEE 802.5. Funcionamiento: En éste tipo de redes la información se envía en un Token que va pasando de una máquina a otra. Cuando una máquina quiere enviar información, debe esperar a que le llegue el Token vacío, y entonces utilizarlo para hacer dicho envío. Cuando el Token con la información llega a su destinatario, éste lo reenvía con el mensaje: Información recibida. Luego se libera el Token para poder volver a utilizarlo. Ya que la máquina necesita el Token para enviar los datos y únicamente hay uno, no se producen colisiones, el problema es el tiempo que debe esperar una máquina a que le llegue el Token vacío antes de poder enviar los datos.

UCB TJA INF 342

Topología de la Red Ethernet: Topología de anillo lógica y una topología física en estrella. Es una implementación del estándar 802.3. En las redes de éste tipo, solo puede haber un mensaje en tránsito en un determinado momento, con lo cual, debido a que hay muchos ordenadores intentando enviar información al mismo tiempo, se produce un alto porcentaje de colisiones al contrario que en las redes Token Ring. CSMA/CD (Carrier Sense Multiple Access with Collision Detecion): La máquina antes de enviar los datos escucha por el cable para saber si está libre, en el caso de que esté ocupado se espera escuchando, y cuando se libere el cable envía los datos. Problema: Ya que puede haber más de una máquina escuchando por el mismo cable, varias de ellas han podido escuchar que el cable estaba vacío y han decidido enviar la información. Con lo cual se produce una colisión, los ordenadores la detectan y deciden reenviar los datos. Fast Ethernet: Es un ampliación del estándar Ethernet, que llega hasta 100Mbp/seg., y es totalmente compatible con Ethernet.

Resumen : Nuestra red la clasificaríamos como una LAN de tipo Fast Ethernet con una tecnología de transmisión Broadcast.

UCB TJA INF 342

Análisis del Diseño Actual. HUB vs. SWITCH •

HUB

Dispositivo de nivel 1.

VENTAJAS - Al ser un dispositivo muy simple su precio es muy bajo, y el retardo que añade a los mensajes es prácticamente nulo. INCONVENIENTES - Funciona a la velocidad del dispositivo más lento de la red. - Actúa como un repetidor enviando la información a todos los ordenadores que están conectados a él. Esto además de tráfico innecesario genera mayores probabilidades de colisión.

UCB TJA INF 342

Análisis del Diseño Actual. HUB vs. SWITCH •

SWITCH

Dispositivo de nivel 2 (capa de enlace). VENTAJAS - Un switch sabe en todo momento que ordenadores tiene conectados a cada uno de sus puertos, esto lo va aprendiendo a medida que circula información a través de él. Cuando un switch no sabe la dirección MAC de destino envía la trama por todos sus puertos (Inundación). Resumen: Si en nuestro diseño cambiáramos todos los hubs por switchs, obtendríamos todas las ventajas de los switchs a cambio de aumentar el coste.

UCB TJA INF 342

Actualización del Diseño Subredes Razones para el uso de subredes: 1.

A medida aumente la red, aumentará también el dominio de colisión, afectando al rendimiento de la red. Si tenemos la red dividida en segmentos, podemos limitar los dominios de colisión enviando las tramas únicamente al segmento donde se encuentre el host de destino.

2.

Conforme aumenta el número de hosts, aumenta también el número de transmisiones broadcast, debido a que los hosts envían de forma constante peticiones ARP, peticiones DNS, envíos RIP, etc. Por tanto puede llegar un momento en que éstas transmisiones congestionen toda la red al consumir un ancho de banda excesivo. Esto se soluciona igual que en el caso anterior con la división de la red en varios segmentos. 3. Por motivos de seguridad. De ésta forma cada departamento puede tener su propia red departamental.

Resumen: Una vez explicadas éstas razones, quedamos convencidos de las ventajas del uso de subredes. Por tanto nos disponemos a crear tres subredes en nuestra propia red, una para cada departamento.

UCB TJA INF 342

Actualización del Diseño Subredes con máscara de tamaño fijo Opción A Tenemos la red 192.168.2.0, le aplicamos la máscara 255.255.255.224. 3 bits para la subred 8 subredes. 5 bits de host 32 direcciones. Por tanto tenemos 8 subredes con 32 direcciones cada una de ellas. Si quitamos las direcciones con los valores todo a 0s y todo a 1s del campo host y del campo subred, nos quedan: 6 subredes de 30 direcciones cada una. Con 30 direcciones tenemos suficiente, aunque nos limita mucho el crecimiento de la red, ya que sólo en el edificio A tenemos 22 ordenadores. Si aplicamos subnet-zero, nos quedan 8 subredes con 30 direcciones, con lo que no hemos resuelto nada. Puesto que la restricción del campo host todo a 0s y todo a 1s se ha de cumplir siempre, seguimos teniendo 30 direcciones en cada subred, así que debemos buscar otra opción mejor.

UCB TJA INF 342

Actualización del Diseño Subredes con máscara de tamaño fijo Opción B A la red 192.168.2.0, le aplicamos la máscara 255.255.255.192. 2 bits de subred 4 subredes. 6 bits de host 64 direcciones. Tenemos entonces 4 subredes con 64 direcciones cada una de ellas. Quitando las direcciones reservadas, nos quedarían 2 subredes de 62 direcciones cada una. Evidentemente, si tenemos tres departamentos y queremos asignarle una subred a cada uno de ellos, con 2 subredes no tendríamos suficiente. Por otro lado, las 62 direcciones serían suficientes para cubrir los 36 ordenadores que tenemos. De ésta forma la solución es aplicar subnet-zero, y quedarnos con 4 subredes de 62 direcciones cada una.

Resumen: La opción B sería mucho más adecuada que la opción A, pudiendo llevarnos con el tiempo a una reestructuración de la red, pero no a tan corto plazo como la opción A.

UCB TJA INF 342

Actualización del Diseño Subredes con máscara de tamaño variable Con ésta técnica no es necesario dividir la red en subredes del mismo tamaño.

¿Por qué resulta interesante?: En nuestro caso particular tenemos 3 departamentos, cada uno de ellos con un número bastante diferente de ordenadores: A 22 B 4 C 10 Si utilizamos ésta técnica, cada subred tendrá un número de direcciones que se ajusta al número de ordenadores que tiene dicha subred. No necesariamente deberíamos asignar a todas las subredes el mismo número de direcciones. Dicho número vendrá dado por el departamento con mayor número de ordenadores. Es decir, en el ejemplo anterior (subredes con máscara de tamaño fijo), necesitamos como mínimo que las subredes sean de 22 direcciones, para poder cubrir las direcciones de los 22 ordenadores. De ésta forma las subredes asignadas a los departamentos B y C desperdician gran cantidad de direcciones.

Observación: Al tratarse de una red privada de clase C, no tenemos el problema de la utilización de direcciones, ya que toda la red al completo (las 256 direcciones) son para nuestro uso propio. De todas formas, la aplicación de éste método en nuestro ejemplo nos permite más opciones a la hora de diseñar el direccionamiento IP, y un mayor nivel de aprendizaje para futuros diseños.

UCB TJA INF 342

Actualización del Diseño Subredes con máscara de tamaño variable 1er. Direccionamiento IP * Edificio A-- 22 ordenadores Le asignamos una subred de 32 direcciones:

de máscara

Subred 192.168.2.32

Máscara 255.255.255.224

Subred/bits 192.168.2.32/27

*Edificio B-- 4 ordenadores Le asignamos una subred de 8 direcciones:

máscara

Subred 192.168.2.8

Máscara 255.255.255.248

Subred/bits de 192.168.2.8/29

*Edificio C-- 10 ordenadores Le asignamos una subred de 16 direcciones:

Subred 192.168.2.16

Máscara 255.255.255.240

Subred/bits de máscara 192.168.2.16/28

Cada departamento tiene ahora una red que se ajusta a sus necesidades, con lo cual no se desaprovechan direcciones. Problema: Son subredes de un tamaño muy ajustado al nº de hosts, cuando crezca la red, este diseño exigirá una reestructuración.

UCB TJA INF 342

Actualización del Diseño Subredes con máscara de tamaño variable 2º Direccionamiento IP * Edificio A-- 22 ordenadores Le asignamos una subred de 64 direcciones:

máscara

Subred 192.168.2.64

Máscara 255.255.255.192

Subred/bits de

192.168.2.64/26

* Edificio B-- 4 ordenadores Le asignamos una subred de 16 direcciones:

máscara

Subred 192.168.2.16

Máscara 255.255.255.240


* Edificio C-- 10 ordenadores Le asignamos una subred de 32 direcciones:

máscara

Subred 192.168.2.32

Máscara 255.255.255.224


Éste sería el mejor .direccionamiento que podemos hacer, aprovechando al máximo las direcciones IP, pero sin correr el riesgo de tener que reestructurar a muy corto plazo.

UCB TJA INF 342

Caso de Aplicación UCB TJA INF 342

Instituto de Investigación e Innovación Tecnológica (TDC) en Oakland, CA USA.

• Misión – Probar modelos y generar datos experimentales – Simular modelos y generar datos computables – Refinar modelos utilizando pruebas.

• Visión: Tener un crecimiento anual del 50% Doblando la producción actual. Utilizar adecuadamente la infraestructura de la Compañía.

UCB TJA INF 342

Actual Infraestructura • Simple Edificio con: – 5 Áreas de testeo • Plataforma de Testeo, equipo, Workstation y red local

– 2 Áreas de visualización de los diseños. • Workstation y red local

– 1 Sala de Computadoras • Cluster de Workstation gráficos de alta resolución y 10 TB de almacenamiento.

UCB TJA INF 342

Esquema lógico de la Empresa ( Actual)

UCB TJA INF 342

Problemática actual. • Elevados gastos de viajes de Ingenieros y técnicos de otras áreas de la empresa localizadas en USA para utilizar la red actual TDC. • Los Ingenieros de otras áreas de la empresa no tienen las facilidades de acceso para el uso de los equipos de TDC. • Debe estar en búsqueda de otras instalaciones similares para realizar los trabajos necesarios UCB TJA INF 342

Los principales objetivos • Incrementar el tamaño de TDC in Oakland • Habilitar las mismas funciones actuales en forma remota. • Incrementar el testeo y las funciones de evaluación a San Francisco. • Trasladar el Laboratorio modelo a San José • Completar con la expansión con un mínimo de molestias a los usuarios. UCB TJA INF 342

Esquema General del Proyecto de TDC

UCB TJA INF 342

Definición del Proyecto • Crear una Red MAN que interconecte los sitios remotos a: – La red actual existente en TDC • Cluster de Computadoras • Área de visualización y monitoreo • Áreas de Pruebas

• TDC actualmente cuenta de Tecnología Ethernet y Redes LAN conectada por routers a una red FDDI UCB TJA INF 342

Pasos del análisis de requerimientos • Determinar las condiciones iniciales, problemas, objetivos y metas. • Entrevista con los usuarios. – Lista de requerimientos para usuarios, aplicaciones, hosts y para la red.

• Desarrollar el mapa de aplicaciones • Identificar las características de performance de las aplicaciones • Desarrollar las métricas de servicio • Desarrollar los umbrales de performance UCB TJA INF 342

Condiciones Iniciales • Centro de pruebas A (simulación y test) con un uso local en un simple Edificio A en Oakland. • Diseñar una Red MAN para conectar a San José ( 1 edificio B) y en San Francisco ( 3 Edificios C). • Se quiere poder usar remotamente el Centro de pruebas A. • Diseñar una nueva Red LAN para conectar un 2do edificio en Oakland B • El número de usuarios actual son de 250 usuarios • El crecimiento previsto en un año es del 50% es decir (370 usuarios) UCB TJA INF 342

Caso estudio Requrimientos • Sede A Centro de pruebas, centro de computación y centro de visualización ( Monitoreo) • Sede B Centro de fabricación de prototipos • Sede C Centro de análisis

UCB TJA INF 342

: Caso Estudio

Localización de los edificios SEDE C Centro de Análisis

SEDE A Pruebas

GW

CPD

Pruebas

SEDE B Centro Fabricación

Pruebas

UCB TJA INF 342

Caso estudio (continuación) • Aplicaciones – Aplicación A. Pruebas. Almacenamiento de datos procedentes de computación y tests, y su recuperación en las áreas de visualización – Aplicación B. Base de datos distribuida. Contiene los resultados de los análisis y tests hechos en la sede A – Aplicaciones C y E. Control remoto de equipos de pruebas. Recibe audio, vídeo y telemedida del centro de pruebas y les envía información de control – Aplicaciones D y G. Colaboración entre los técnicos de los centros de visualización, pruebas y computación, en un entorno interactivo – Aplicación F. Acceso a base de datos de modelos de fabricación.

UCB TJA INF 342

Caso estudio (continuación) • Identificación de las Aplicaciones – Aplicación A. Aplicación de pruebas. Acceso a los ficheros de prueba – Aplicación B. Base de datos distribuida – Aplicaciones C y E. Control remoto de equipos de pruebas – Aplicaciones D y G. Interactivas – Aplicación F. Acceso a base de datos • ADAPTABILIDAD: Todas las aplicaciones y la Red en si misma debe ser adaptable a cambios, adiciones y eliminaciones.

UCB TJA INF 342

Caso Estudio Requerimientos del usuario Tipos de Requerimientos de usuarios

Descripción de Requerimientos

Localización y número de usuarios

Sede A: 75 usuarios Sede B: 30 usuarios Sede C: 80 usuarios Centro de computación y pruebas, sede A: 60 usuarios

Crecimiento esperado en 1 año

50 % incremento

Interactividad Fiabilidad

M ismo funcionamiento en remoto que en local 100% en algunas aplicaciones

Seguridad

Pruebas independientes entre sí

UCB TJA INF 342

Identificación y características de las aplicaciones •

Aplicación A: (Mejor esfuerzo) – Tamaño promedio de los datos 100MB – Dos usuarios concurrentes – Tiempo de transferencia hasta 10 min. – Capacidad por calcular – Retardo y Disponibilidad sin identificar Aplicación B: ( Mejor esfuerzo) - Tamaño de la transacción 10MB - 40 Transacciones / minuto - Capacidad a definir - Retardo: 25ms para un TCT ( total completion time) - Disponibilidad no especificada.

UCB TJA INF 342

Identificación y características de las aplicaciones •

Aplicaciones C y E (Misión crítica) – Capacidad dada 1.69 Mbps – Retardo: 40ms RT – Disponibilidad: 100% Aplicaciones D y G( Tiempo Real) - Capacidad 5Mbps/ grupo y dos grupos concurrentes - Retardo. 80ms RT - Disponibilidad no especificada. Aplicación F (Mejor esfuerzo) - Capacidad dada 400kbps - Retardo y disponibilidad no especificada Valores por default (omisión) Disponibilidad 99.5% Retardo: 100 ms HRT UCB TJA INF 342

Requerimientos de las aplicaciones Categorización de Misión aplicaciones Crítica

Tiempo real

Aplicación A

Aplicación B Aplicación C y E

Aplicación D y G

Aplicación F

Mejor esfuerzo

Localización de las aplicaciones

Tamaño 100 MB Usuarios simultaneos: 2 TT hasta 10 min Cliente/servidor Tamaño 10 MB 40 trans/minuto

En todas localidades

TR=40ms 1,69 Mbps Disp:100% Sesiones Concurr. 4

Localidad C App.C: Loc A App.E:Loc C

TR=80ms 5 Mbps por grupo 2 grupos concurrentes Cliente/ Servidor

App.D:Loc A App G:Loc C

400 Kbps Cliente/servidor

UCB TJA INF 342

Localidad B

Requerimientos de Hosts Tipo de Host

Número y localización

Estaciones gráficas Servidor aplicación A

En todas las localidades CPD A

Servidor aplicaciones D y G

CPD A

Servidor aplicación F Servidor aplicación B Host central

Localidad B Localidad C CPD A

UCB TJA INF 342

Requerimientos de redes Redes Existentes

Localidades de la red

Ethernet 10T

Centro Proceso de datos

FDDI

Centro Proceso de datos

SEGURIDAD: La Compañía especifica que todos los datos deben ser protegidos Contra accesos externos. PRESUPUESTO: La compañía indica que dispone para la inversión correspondiente UCB TJA INF 342

Mapa de aplicaciones del caso C

A

Aplicación A

Aplicaciones C y D Aplicaciones E y G

Aplicación B

CPD

Aplicación F

Aplicaciones E y G B

UCB TJA INF 342

Comportamiento de aplicaciones (Capacidades) A: (100MBx 2 usuarios/10m)= 20MB/min = 2,7 Mbps B: 10MB*40 trans /min = 400 MB/min = 53 Mbps C y E: 1,69 Mbps D y G: 2 concurrent-grupos*5Mbps /grupo=10 Mbps F:

= 400Kbps

UCB TJA INF 342

Sumario de características de rendimiento de las aplicaciónes Categorización de aplicaciones

Tiempo de tránsito

Capacidad

Disponibilidad

Aplicación A

100 ms HRT (**)

2,7 Mbps (*)

99,5% (**)

Aplicación B Aplicación C y E

100ms HRT (**) RT=40ms

53 Mbps (*) 1,69 Mbps

99,5% (**) 100%

Aplicación D y G

RT=80ms

10 Mbps (*)

99,5% (**)

Aplicación F

HRT=100ms (**)

400Kbps

99,5% (**)

(*) Calculado (**) Asumido

UCB TJA INF 342

Diagrama de rendimiento Tiempo de tránsito 40ms 100 ms

99,5% 400 Kb/seg

100%

53Mb/seg Disponibilidad Capacidad

UCB TJA INF 342

Caso Estudio

UCB TJA INF 342

: Caso Estudio Fuentes y destinos de datos para Aplicación A C

A

GW

CPD

B

Representación

entrante

UCB TJA INF 342

saliente

: Caso Estudio Fuentes y destinos de datos para Aplicaciones D y G

C

A

GW B

UCB TJA INF 342

CPD

Caso Estudio Fuentes y destinos de datos para Aplicación F C

A

GW B

UCB TJA INF 342

CPD

Caso Estudio Fuentes y destinos de datos para Aplicación B C

A

GW B

UCB TJA INF 342

CPD

: Caso Estudio Fuentes y destinos de datos para Aplicación C y E C

A

GW B

UCB TJA INF 342

CPD

Fronteras de datos, flujos compuestos y troncales fd/g

fc/e

fa f

C

A

b

CF1 CF2

80

fa f c/e f d/g

fd/g f b fa f c/e

fa f f c/e d/g ff

BB1

GW B

CF6

fa

ff

fa CF3 f fc/e d/g

CF4 f fd/gc/e CF5 fa BB2 fc/e f a 60 fd/g CPD

30 75

UCB TJA INF 342

Modelos de Flujo y Distribución

• Modelos: – Peer to Peer – Cliente servidor – Computación cooperativa – Computación distribuida

Distribución del Flujo: - El Tradicional regla del 80/20 - 80% del trafico local y el 20% entrante y saliente de la red - 50/50 y 20/80 de acuerdo a las aplicaciones.

UCB TJA INF 342

Estimación de distribuciones de flujo Flujo

Modelo de Flujo

Fronteras de flujo

fa fb fc/e fd/g ff

Cliente/servidor

A, B, C

Distribución de flujo 20/80

Cliente/servidor

C

80/20

A la par

A, C

20/80

Cliente/servidor

A, C

20/80

Cliente/servidor

A, B

50/50

UCB TJA INF 342

Especificaciones de flujo Flujo

Fiabilidad

Capacidad

Tránsito

fa fb fc/e fd/g ff

99,5%

2,7Mbps

100ms

99,5%

53 Mbps

100 ms

100%

1,69 Mbps

40 ms

99,5%

10 Mbps

80 ms

99,5%

400 Kbps

100 ms

UCB TJA INF 342

Especificaciones de flujos compuestos Flujo

Fiabilidad

Capacidad

Tránsito

CF1

100%

67 Mbps

40 ms

CF2

100%

67 Mbps

40 ms

CF3

100%

14 Mbps

40 ms

CF4

100%

14 Mbps

40 ms

CF5

100%

14 Mbps

40 ms

CF6

99,5%

3,5 Mbps

100 ms

UCB TJA INF 342

Caso Estudio Especificaciones de flujos troncales

Flujo

Fiabilidad

Capacidad

Tránsito

BB1

100%

29 Mbps

40 ms

BB2

100%

33 Mbps

40 ms

UCB TJA INF 342

Ej. Capacidades Enlaces y la elección de tecnología

UCB TJA INF 342

Caso Estudio Ej. Capacidades Enlaces y la elección de tecnología

UCB TJA INF 342

Caso Estudio

UCB TJA INF 342

: Caso Estudio Diseño segmentado en campus y bloques Campus C

Campus A

GW Campus B

UCB TJA INF 342

CPD

Caso Estudio Tráficos BB1 y CF6 Campus C

Campus A

Caja Negra BB1 (R=100% C=29 Mbps TT=40ms) Caja Negra Campus B

Caja Negra

CF6 (R=99,5% C=3,5 Mbps TT=100ms) Suministrador de servicios para estos flujos •Opciones FR, ATM, RDSI, ADSL

UCB TJA INF 342

Caso Estudio Elección de tecnologías para caja negra A Ethernet conmutado 100 Mbps

Posibilidades ATM FDDI Ethernet 100 Mbps

Caja Negra

CF3:R=100%,C=14Mbps,TT=40ms Caja Negra

GW

CPD

Caja Negra

BB2:R=100%,C=33Mbps,TT=40ms Flujo más crítico Con más probabilidades de crecimiento Posibilidades Caja Negra ATM FDDI ATM 155 Mbps Ethernet 100 Mbps

UCB TJA INF 342

Caso Estudio Elección de tecnologías para Campus C Factor de crecimiento 50%. Posibilidad de crecer hasta 100 Mbps El mayor flujo es local (Fb=53 Mbps) Opciones Tecnológicas: ATM 155 Mbps, GigaEthernet CF1

R=100%,C=67 Mbps,TT=100 ms

B1

CF2

UCB TJA INF 342

Caja Negra

Caso Estudio Diseño lógico completo C

A

ATM 155 Mbps de un suministrador de servicios

GW

B Ethernet 10 Mbps

UCB TJA INF 342

CPD

Caso Estudio

Mezclas de conmutación con otras tecnologías LANE sobre ATM

Subred IP B

Subred IP A Subred IP C Classical IP ATM (RFC1577)

UCB TJA INF 342

Caso Estudio Ejemplo de problemas de mal diseño Subred IP A

Un flujo de datos local tiene que atravesar la WAN

Subred IP B

Localidad 1

Localidad 2

UCB TJA INF 342

Caso Estudio Tipos de conectividad con el exterior Redes externas

Redes internas Servidor de seguridad Servidor Web

Redes externas

Redes internas

Servidor de seguridad/NAT

Red de perímetro Zona desmilitarizada

Redes externas

Redes internas Servidor Web externo

UCB TJA INF 342

Servidor Web interno

Caso Estudio Mecanismos híbridos. NHRP Subred IP A

Los siguientes usan conmutación

El primer flujo hace uso del encaminamiento

Subred IP B

Localidad 1

Localidad 2

UCB TJA INF 342

Caso Estudio Jerarquías de conexión • Los puntos donde varias redes se encuentran son donde habrá mecanismos de interconexión • El grado de consolidación de flujos en un punto , denominado jerarquía, nos da idea de las características de interconexión necesitadas en ese punto Grado de Jerarquía

Concentración de flujos

Ninguno Bajo Medio Alto

1:1 2:1 3:1----5:1 Mayor o igual de 6:1

UCB TJA INF 342

Caso Estudio Caso estudio. Grado de jerarquías y redundancia Campus C 2:1

Caminos que necesitan disponibilidad entre media y alta

Campus A

3:1

5:1 GW Campus B

UCB TJA INF 342

CPD

Caso Estudio Diseño lógico con routers y conmutadores Campus C

Campus A RFC1577

RFC1577

RFC1577 ATM 155 Mbps de un suministrador de servicios

GW

Campus B

RFC1577

UCB TJA INF 342

CPD

RFC1577

TALLER INF 342

UCB TJA INF 342

Protocolo de Presentación 1. 2. 3. 4.

Introducción Objetivos Análisis Teórico (De su aporte para el Taller) Diseño Red de Computadoras Corporativa a) Condiciones Generales b) Análisis de Requerimientos c) Análisis de Flujos d) Diseño Lógico e) Diseño Físico f) Direccionamiento y ruteo g) Recomendaciones para la ejecución del proyecto 5. Simulación (configuración de equipos) 6. Costo aproximado del proyecto 7. Impacto y conciencia social del proyecto 8. Identificación de valores católicos 9. Conclusiones, recomendaciones y aportes 10. Bibliografía y Web grafía

UCB TJA INF 342

Condiciones iniciales


Análisis


Diseño

Diseño físico Direccionamiento y ruteo

UCB TJA INF 342


Fechas de entrega de documento y defensa del Taller Primera Presentación: 8 de Octubre hasta Análisis Teórico(enviar al email [email protected]). Puntos 1 - 3 del Protocolo de Presentación. Segunda Presentación y Final: 26 de Octubre, 1 copia y enviar al email [email protected]. Puntos 4-6 del Protocolo de presentación Defensa y última presentación: 20 de Noviembre con Jurado invitado. Cumplir todos los puntos del Protocolo de Presentación.

UCB TJA INF 342

FIN !!!!

UCB TJA INF 342

CAPITULO 12 METODOLOGIA DE DISEÑO DE REDES CORPORATIVAS

Recommend Documents