Upload
mauricio-aliaga
View
287
Download
0
Embed Size (px)
Citation preview
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
UCB TJA INF 342
Metodología
Diseño de Redes Corporativas
a 1ra Parte
a Metodologíaa Pautas
2
UCB TJA INF 342
Características en el Diseño de Redes
a Diseños raramenterepetitivosa Algo de Artea Combinación de Reglasa Evaluación y seleccióna Conocimiento:
` De la Tecnologías` Servicios` Sistemas
de tecnologías
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
UCB TJA INF 342
Metodología para diseño de red de empresarial propuesta
por James McCABE
Introducción A&D de Redes 7
Proceso general
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales Análisis
Diseño
UCB TJA INF 342
UCB TJA INF 342
Diseñar y optimizar redes de comunicaciones (datos, voz yvideo) utilizando una metodología que proporcione unacalidad de servicio controlada a las aplicacionesinformáticas que utilicen la infraestructura planificada.
Objetivo
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ño2) En la fase de análisis de requerimientos se establecen: Mapas de aplicaciones, Descripciones de flujos de datos, simples y Compuestos3) En la fase de diseño hay dos niveles: diseño lógico y diseño físico
Metodología GeneralFase de Análisis
1. Recabar requerimientos➔ Entrada: condiciones iniciales2. Definir las aplicaciones que se ejecutarán en forma distribuida.➔ Salida: mapa de aplicaciones3. 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 GeneralFase de Diseño (lógico)
1. Establecer metas de diseño➔ Entrada: especificación de flujos y especificación de requerimientos, en particular presupuesto2. 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 mercado4. Integrar mecanismos de interconexión5. 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ñoFase de Diseño (físico)
7. Evaluar opciones de diseño del cableado8. Seleccionar la ubicación de los equipos9. Realizar el diagrama físico de la red10. Incorporar las estrategias de enrutamiento con base en los flujos➔ Entrada: restricciones impuestas por los mecanismos de interconexión seleccionados en el paso 411.Optimizar flujos de enrutamiento12.Desarrollar una estrategia de asignación de direcciones, asignar las direcciones13.Desarrollar una estrategia detallada de enrutamiento➔ Entrada: algoritmos de enrutamiento disponiblesCon este paso concluye el Diseño Físico
UCB TJA INF 342
Diseño Descendente de Redes
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 sirvela red y dónde residen
• Determinar qué aplicaciones se ejecutarán y cómo se comportan esasaplicaciones en una red
• Enfocarse primero en la capa 7 o másarriba
UCB TJA INF 342
Capas del Modelo OSIAplicación
Presentación
Sesión
Transporte
Red
Enlace
FísicaCapa 1
Capa 7
Capa 6
Capa 5
Capa 4
Capa 3
Capa 2
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 necesidadesde las comunidades de usuarios que acceden o cambiandatos y procesos.
• Pueden usarse varias técnicas y modelos paracaracterizar el sistema existente, los nuevosrequerimientos 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
Analizarrequerimientos
Desarrollar diseño lógico
Desarrollar diseño físico
Probar, optimizar, y
documentar el diseño
Monitorear y optimizar el
rendimiento de la red
Implementar y probar la
red
Pasos para el Diseño Descendente
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 redUCB 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
Implementación
Operación
OptimizaciónRepetir
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 negociohoy en día.
UCB TJA INF 342
UCB TJA INF 342
Proceso general
Introducción A&D de Redes 26
Proceso general
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales Análisis
Diseño
UCB TJA INF 342
UCB TJA INF 342
Condiciones Generales
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales Análisis
Diseño
UCB TJA INF 342
Análisis
a Que es lo que quieren losusuarios
a Objetivos del diseño` Maximizar rendimiento` Minimizar costosPros y ContrasCosto vs. Rendimiento
Simplicidad vs. FuncionalidadEquilibrio entre
Arquitectura y funcionalidad
Más de unasolución
5
UCB TJA INF 342
30
Determinar CondicionesIniciales
• 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
31
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
Metas del NegocioIncrementar 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 serviciosUCB 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 gerencialUCB 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 quedebemos 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 vsun 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 RedNombre de la aplicación
Tipo de aplicación
¿Aplicación nueva?
¿Es crítica? Comentarios
UCB TJA INF 342
Resumen• Método sistemático• Enfocarse primero en los
requerimientos del negocio, lasrestricciones y las aplicaciones
• Entender la estructura corporativadel cliente
• Entender el estilo de negocio delcliente
UCB TJA INF 342
Introducción A&D de Redes 45
Análisis de requerimientos
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales Análisis
Diseño
UCB TJA INF 342
UCB TJA INF 342
Introducción A&D de Redes 47
Conceptos relevantesSistemas
• Componentes y relaciones del sistema
Solicita
Servicios
Ofrece Red
Aplicación
Host
Usuario
Aplicación
Host
Usuario
UCB TJA INF 342
Introducción A&D de Redes 48
Conceptos relevantesServicios de red
• Características– Demanda– Oferta
• Niveles
• Requerimientos de rendimiento– Confiabilidad– Capacidad– Retardo
Métricas de servicio
Red
Host
Usuario
Aplicación
Host
Usuario
Aplicación
UCB TJA INF 342
Introducción A&D de Redes 49
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
UCB TJA INF 342
Introducción A&D de Redes 50
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
UCB TJA INF 342
51
Análisis de Requerimientos:PAUTAS
• Las pautas para el análisis derequerimientos son parte del modelo delproceso. Este modelo, mostrado en lasiguiente figura, muestra los pasosprincipales en la colección y análisis derequerimientos para su diseño de red.
UCB TJA INF 342
52
Análisis de Requerimientos:PAUTAS
Obtención de Requerimientos
Desarrollar Métricas de Serviciopara Medir Rendimiento
Caracterizando elComportamiento
Determinar Umbrales deRendimiento
Distinción entreRequerimientos de Servicio
DesarrolloMapa de Aplicaciones
Variables deAdministración de Red
Modificadores de RendimientoUsuarios/Aplicación
CondicionesIniciales
Pautas endistinguir Servicios
AplicaciónTipos / Grupos
UCB TJA INF 342
A&D Determ. de Requerimientos 53
Contexto en el proceso general
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales Análisis
Diseño
UCB TJA INF 342
A&D Determ. de Requerimientos 54
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
UCB TJA INF 342
A&D Determ. de Requerimientos 55
Componentes
• Componentes y relaciones del sistema
Solicita
Servicios
Ofrece Red
Aplicación
Host
Usuario
Aplicación
Host
Usuario
UCB TJA INF 342
A&D Determ. de Requerimientos 56
Naturaleza de los requerimientos
Diseño nueva red
Usuarios finales
Aplicaciones Hosts(PCs, servidores)
Redes existentes
UCB TJA INF 342
A&D Determ. de Requerimientos 57
Requerimientos de usuario
• Oportunidad• Interactividad• Confiabilidad• Calidad• Adaptabilidad• Seguridad• Factibilidad• Número de usuarios• Ubicación de los usuarios• Crecimiento esperado
Aplicación
Host
Aplicación
Host
Red
Usuario Usuario
UCB TJA INF 342
A&D Determ. de Requerimientos 58
Requerimientos de usuario/servicio
• Oportunidad• Interactividad• Confiabilidad• Calidad• Adaptabilidad• Seguridad• Factibilidad• Número de
usuarios• Ubicación de
los usuarios• Crecimiento
esperado
Retardo
Confiabilidad
Capacidad
Aplicación
Host
Aplicación
Host
Red
Usuario Usuario
UCB TJA INF 342
A&D Determ. de Requerimientos 59
Requerimientos de aplicación
• Grupo de aplicación al que pertenece
• Tipo de aplicación
• Características de rendimiento de la aplicación
• Ubicaciones de la aplicación
Aplicación
Host
Aplicación
Host
Red
Usuario Usuario
UCB TJA INF 342
A&D Determ. de Requerimientos 60
Requerimientos de Host
• Tipos de hosts y equipamiento
• Información sobre ubicaciones
• Características de rendimiento de host/equipo
Aplicación
Host
Aplicación
Host
Red
Usuario Usuario
UCB TJA INF 342
A&D Determ. de Requerimientos 61
Requerimientos de red
• Escalabilidad• Servicios de red• Servicios de
soporte• Interoperabilidad• Ubicación• Características de
rendimiento de redRedesexistentes
Redesexistentes
Redesexistentes
Aplicación
Host
Aplicación
Host
Usuario Usuario
UCB TJA INF 342
A&D Determ. de Requerimientos 62
Otros requerimientos
• Financieros o presupuestarios• Integración con otros tipos de medios
de comunicación– teléfono– fax– video– etc.
UCB TJA INF 342
Contexto en el proceso de análisisCaptura de requerimientosCondiciones
iniciales
Desarrollar métricas de Servicio
Caracterizar comportamiento
Desarrollar umbrales de rendimiento
Distinguir entre requerim de servicio
Establecer límites de flujo
Identificar flujos backbone y compuestos
Desarrollar especificación de flujos
Mapas de aplicaciones
Vars. de adm. de red
Modif. De rend.Usuario/Aplicación
Plan de capacidad Plan de servicio
Tipos de aplicaciones
Guía para distinguir servicios
Especif. de requerim.
Modelos de flujo
Distribución de flujo
Características del flujo
Algoritmo de especificación
UCB TJA INF 342
A&D Determ. de Requerimientos 64
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
UCB TJA INF 342
A&D Determ. de Requerimientos 65
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.
Métricas de servicio ¿Dónde se medirán? Método de medición
Tabla ejemplo
UCB TJA INF 342
A&D Determ. de Requerimientos 66
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”
UCB TJA INF 342
A&D Determ. de Requerimientos 67
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
A&D Determ. de Requerimientos 68
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
A&D Determ. de Requerimientos 69
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 >= 1respuesta 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
UCB TJA INF 342
A&D Determ. de Requerimientos 70
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.
UCB TJA INF 342
A&D Determ. de Requerimientos 71
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
UCB TJA INF 342
A&D Determ. de Requerimientos 72
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
73
Objetivos: nivel de servicioDisponibilidad de la red 99.8 a 100%Tiempo medio entre fallas de hw 1 mesTiempo medio entre fallas de sw 1 mesTiempo de respuesta promedio 10 minutosTiempo de reparación promedio 1 horaTiempo máx. de reparación 24 horasRendimiento de la red 95%, t. Resp. < 2sThroughput promedio 64 kbpsTiempo medio restaurar disco 4 horasTiempo medio restaurar archivo 1 hora
UCB TJA INF 342
A&D Determ. de Requerimientos 74
Velocidades de transferencia
APLICACION VELOCIDADComunicaciones personales 300 a 9600 bps o másCorreo electrónico 2400 a 9600 bps o másProgramas de control remoto 9600 a 56000 bpsConsultas a base de datos Superior a 1 MbpsAudio digital 1 a 2 MbpsAcceso a imágenes 1 a 8 MbpsVideo comprimido 2 a 10 MbpsTransmisiones médicas Superior a 50 MbpsImágenes documentales 10 a 100 MbpsImágenes científicas Superior a 1 GbpsVideo sin comprimir 1 a 2 Gbps
Fuente: Netware 4.1. Manual de referencia. 2ªed. Tom Sheldon McGraw Hill 1994
UCB TJA INF 342
75
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
76
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
77
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
78
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
79
Herramientas de Medición en Red
• Herramientas simples de Software– Ping– Netperf
• Herramientas de Análisis
UCB TJA INF 342
• 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
Monitor de Rendimiento entre redesCiscoWorks Blue Internetwork
Performance Monitor
2UCB TJA INF 342
81
Localizar Cuellos de Botella en Rendimiento
• Análisis de Rendimiento Salto a Salto a través de la red
Usuario finalIPM
UCB TJA INF 342
82
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
83
Redundancia, Seguridad y Verificación
• Identifica trayectorias redundantes en la red• Estima la utilización de rutas redundantes
UCB TJA INF 342
84
Usando Ping y Pérdida de paquetes IP como medidas de Confiabilidad
x Red de Área Extendida xSNMP/CMIP es usado para obtener
pérdida de paquetes de datos
Estación deMonitoreo de Red
Ping es usado entre varios interfacespara monitorear el retardo en la red
LANLAN
UCB TJA INF 342
85
Tabla de métrica de Servicio
Métrica de Servicio Donde la métrica serámedida en el Sistema
Método usado para lamedida
UCB TJA INF 342
86
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
87
Patrones de uso
Sesión 1
Sesión 2
Sesión 3
Sesión 4
Activo
Activo
Activo
Ses
ione
s de
Apl
icac
ión
Activo Activo Activo Activo Activo
Activo
Activo Activo
Activo
Activo Activo
FrecuenciaNúmero de Sesiones
Simultáneas
Duración
UCB TJA INF 342
88
Caracterizar el Comportamiento
• Comportamiento de la aplicación• Caracterizando el comportamiento de la
aplicación, deseará considerar los tamaños delos datos que la aplicación estará procesando; lafrecuencia y duración de tiempo para los datos aser transferidos por la red; las característicasde flujo de tráfico para la aplicación,particularmente las direcciones de flujo (p.ej.,del cliente all servidor); y el grado demulticasting en las comunicaciones (uno-a-uno,uno-a-muchos, muchos-a-muchos).
• Modelos simples y complejos.
UCB TJA INF 342
89
Desarrollo de Umbrales de Rendimiento
– Distinguiendo entre los servicios al mejoresfuerzo, especificado, y servicios de alto/bajorendimiento, usaremos el criterio siguiente:
• 1 Un umbral general puede usarse para separarrequerimientos de rendimiento de bajo rendimiento yalto rendimiento.
• 2 Un umbral de ambiente-específico puede usarsepara separar requerimientos de rendimiento en bajorendimiento y alto rendimiento.
• 3 Los servicios especificados tendrán límites ogarantías limitadas.
UCB TJA INF 342
90
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
91
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(% Tiempo deServicio)
Cantidad de Tiempo fuera de Servicio Permitido (horas [h], minutos [m], osegundos [s] por periodo de tiempo)
Anual Mensual Semanal Diario95 % 438 h 36,5 h 8,4 h 1,2 h99,5% 43,8 h 3,7 h 50,5 m 7,2 m99,95% 4,38 h 21,9 m 5,05 m 43,2 s99,98% 1,75 h 8,75 m 2,0 m 17,3 s99,99% 0,88 h 4,4 m 1,0 m 8,7 s
UCB TJA INF 342
92
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
Interfaces de Red
Monitores de Red
Ethernet LAN
FD
DIL
AN
UCB TJA INF 342
93
Disponibilidad medida selectivamente entre redes
Servidor de Lan x
Usuarios LAN
Disponibilidad
Usuarios LAN
Usuarios LAN
Usuarios LANDisponibilidad
UCB TJA INF 342
94
DisponibilidadDisponibilidad Anual Mensual
95% 438 hrs. 36.5 hrs.
99.5% 43.8 hrs. 3.7 hrs.
99.95% 4.38 hrs. 21.9 mins.
99.98% 1.75 hrs. 8.75 mins.
99.99% 0.88 hrs. 4.4 mins.
99.999% 0.09 hrs. .4 mins.
Testbeds
Mayoría sistemas comerciales
Sistemas de Misión Crítica
Sistemas de Tiempo Real
Systemas de muy alta disponibilidad
UCB TJA INF 342
95
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
96
Disponibilidad con MTBF/MTBSO y MTTR
MTTR
4 horas2 horas1hora
MT
BF
/MT
BS
O (
Hor
as)
8000
4000
2000
1000400
99.98
99.9
99.95
99.0
99.5
Disponibilidad (% Tiempo de Conexión)
UCB TJA INF 342
97
Razones de Error y Pérdida
• Las pérdidas pueden medirse en la capa de enlace o de lared, y se informa como un porcentaje de tráfico disponibleen la red. Así, nosotros podríamos establecer umbrales depérdidas de celdas, frames, o paquetes y periodos detiempo, como en la Tabla.
Razón de Pérdida de Paquetes(como % del tráfico total de la red)
Tiempo Total Máximo(por mes)
25% a 100% Hasta 2 horas2% a 24% Hasta 3 horas< 2% Resto del mes
UCB TJA INF 342
98
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 bajo-rendimiento/alto-rendimiento
• Estime la disponibilidad basada en las rutasprobables extremo-a-extremo que lasaplicaciones usarán, y qué equipo y serviciosexisten o pueden estar en esas rutas.
UCB TJA INF 342
99
Umbrales de referencia general para Requerimientos de Usuario
Bajo - Rendimiento
Testbed
Alto - Rendimiento
99.0 99.5 99.9 99.95 99.98
Disponibilidad (%)
UCB TJA INF 342
100
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
101
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 oun MTBF/MTBSO menos de 8000 horas
– Confiabilidad de alto rendimiento(reestablecimiento): MTTR menor de o igual a 2horas y MTBF/MTBSO mayor que o iguala a 8000horas
– (Nota: Estos umbrales de reestabecimiento seescogen para proveer un MTTR razonable. Si unMTTR más pequeño es escogido, entonces elMTBF /MTBSO será correspondientemente másbajo.)
UCB TJA INF 342
102
Razón de pérdida de información de extremo-a-extremo ó razón de retransmisión
• Bajo-rendimiento (razón de pérdida):Pérdidas de paquete IP de
�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
103
Requerimientos de Retardo
Network
Host
Aplicación
Componentes
• Retardo de Interacción• Tiempo de Respuesta Humano• Retardo de propagación de la red
Red
DataH
UCB TJA INF 342
104
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
105
Tiempo de Respuesta Humano (HRT)
– estima el límite de tiempo cuando los usuariosempiezan a percibir retardo en el sistema.
– Cuando el tiempo de respuesta del sistema estádebajo del HRT, los usuarios generalmente noperciben retardo en el sistema.
– Sobre el HRT, los usuarios notarán el retardo delsistema y puede llegar a frustrarse.
– Una estimación buena del HRT esaproximadamente 100 ms.
UCB TJA INF 342
106
Tiempo de Respuesta Humano (HRT)
– HRT es importante para las aplicaciones muyinteractivas, donde los tiempos de espera no puedeno no deberían ser percibidos por el usuario.
– Éste normalmente es el caso cuando la aplicaciónapoya un ambiente interactivo para el usuario, comoen visualización, realidad virtual, y las aplicacionescolaborativas, pero también puede aplicarse a lasaplicaciones donde el retardo del sistema más allá deHRT produce pérdida de productividad.
UCB TJA INF 342
107
Retardo de propagación de red
– Estima el retardo de la propagación de la señal enla red.
– Esto proporciona un límite inferior a los retardosde extremo-a-extremo y de ida y vuelta de la redy del sistema.
– El retardo de la propagación es dependiente en ladistancia y tecnología.
– Es útil como un límite inferior de retardo, porquenos dice cuando una aplicación no puede trabajarbien por la red, cuando sus requerimientos deretardos son más severos que el retardo de lapropagación por la red.
UCB TJA INF 342
108
Estimación de retardos para requerimientos de usuarios
Tiempo de Respuesta Humano
Retardo de Propagación de Red
Retardo de Interacción
0.01 0.1 1.0 10 100Retardo (Segundos)
UCB TJA INF 342
109
Distinción entre aplicaciones de Ráfaga y Volumen
0.01 0.1 1.0 10 100Retardo (Segundos)
Ráfaga/Volumen Interactivo
Tiempo deRespuestaHumano
VolumenInteractivo
RetardoInteractivo
Ráfaga Interactivo
UCB TJA INF 342
110
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-a-extremo RTT medido en milisegundos.
UCB TJA INF 342
111
Tiempo de realización de Tarea (TCT)
Retardo
Transferencia de Datos 2
Transferencia de Datos 1
Tarea Completada
Dato Recibido / Procesado
Dato Recibido / Procesado
Dato Recibido / Procesado
Retardo
Retardo
TCTTransferencia de Datos 3
Fuente Destino
Tiempo
Esta conducta es consistente con aplicaciones que están procesando transacciones y cómputos distribuidos, o son cliente-servidor.
UCB TJA INF 342
112
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
113
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
114
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 (volumeninteractivo)
• Respuesta del sistema > 3 (ráfagainteractivo)
UCB TJA INF 342
115
Ejemplo– una red que tiene un RTT (o tiempo de ping)
de 100 milisegundos (un valor aproximadopara una red que cruza los Estados Unidoscontinentales) y un TCT de 10 segundostendrí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
116
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
117
Retardo de extremo-a-extremo
• 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
118
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
119
Requerimientos de capacidad
• Razón de Datos• Tamaño de los datosAplicación TCT
Promedio(Segundos)
Tamaño de Datos Promedio(Bytes)
Cálculo Distribuido (Modo Batch)
103 107
Transacciones tipo Web 10 104
Consultas Base de Datos 2 - 5 103
Ingresos de Pagos 10 102
Teleconferencia(usando Multicast)
103 3*105
UCB TJA INF 342
120
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
121
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
122
Ejemplo de un ambiente de Cómputo con Multiprocesadores
Transf. Datos Transf. DatosTransf. Datos Transf. Datos
ProcesamientoProcesamiento ProcesamientoProcesamiento
2a Iteración1a Iteración 3a Iteración 4a Iteración
50 KB / iteración
25 iteraciones / segundo
4 ms Tiempo Procesamiento / iteración
Servidor
Nodos deCómputos
UCB TJA INF 342
123
Región de Rendimiento con Umbrales Genéricos
Regiones deAlto Rendimiento
Región deBajo Rendimiento
Capacidad (C)
Confiabilidad (R)
Umbral deConfiabilidad
Genérica
Umbral delRetardo Genérico
Retardo (D)
Umbral deCapacidadGenérica
UCB TJA INF 342
124
Umbrales de Servicio de ambiente específico
• Los umbrales generales nos dan algunas estimaciones comúnespara las características de bajo y alto rendimiento.
• Tales umbrales son útiles cuando hay una falta de informaciónsobre los usuarios y aplicaciones para la red a diseñár, pero amenudo el ambiente indica que umbrales de rendimiento deberíanser.
• Como con umbrales generales, la razón por desarrollar umbralesde ambiente específico es para determinar qué aplicacionestienen características de alto rendimiento.
• Es probable que estas aplicaciones de alto rendimiento son lo quenosotros diseñaremos, junto con esas aplicaciones que tienencaracterísticas especificas.
UCB TJA INF 342
125
Comparando Características de la Aplicación
• Cuando podemos agrupar características de la aplicación,entonces una comparación puede hacerse a menudo paradeterminar donde el umbral puede aplicarse.
• Considere un gráfico de características de retardo para variasaplicaciones, A a través de M, para un ambiente particular, comose 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 deambiente específico a un retardo de aproximadamente Xmilisegundos.
• Esas aplicaciones que tienen una característica de retardo demenos de X milisegundos son consideradas de alto rendimientopara este ambiente.
UCB TJA INF 342
126
Características de Retardo para una muestra de aplicaciones
Apl
icac
ione
s(D
enot
adas
por
letr
as)
KJ
EG
B
H LD
CF
A MI
Alto - Rendimiento Bajo - Rendimiento
X ms Retardo (ms)
UCB TJA INF 342
Caracterización de los serviciosPeticiones de servicio. Identificadas por el grado de
predecibilidad del servicio` Mejor voluntad. Ningún control sobre la red. Esta tratará de
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.
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
a
a
6
UCB TJA INF 342
128
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
129
Servicios garantizados
• Los servicios garantizados son un paso más allá de los serviciosdeterministicos, en que hay algún mecanismo para forzar al servicio a laaplicación o usuario. Así para desarrollar los requerimientos para losservicios garantizados, necesitamos tener características de rendimientobien definidas.
• En la siguiente figura, el rendimiento de una aplicación se acerca al límite delservicio (garantizado). Ninguna acción se toma hasta que la aplicación excedesu garantía, donde ocurre la vigilancia.
• Al elemento de la red donde ocurre la vigilancia, esto puede tomar la formade marcar el paquete/frame/celda para que los elementos de red de flujohacia abajo asuman alguna acción, o dejando caer el frame/paquete/celda enese elemento de la red.
• Vigilar es a menudo útil para proteger el flujo de tráfico que fluye haciaabajo que excede su límite de servicio y intenta usar más recursos de la redque el contratado.
UCB TJA INF 342
130
Vigilancia de rendimiento de un flujo
Garantía
VigilanciaNo Acción tomada
Comportamiento de la Aplicación
Time
Servicio Límite / Garantía(p.ej., capacidad)
UCB TJA INF 342
131
Servicios garantizados– Se desarrollan garantías de servicio en una forma
similar para servir los límites, excepto que se declara lanecesidad 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 lomenos 99.97%.
– Este límite más bajo para confiabilidad podríadeclararse como una garantía de servicio quesignificaría que después en el proceso del diseño loconsideraríamos como los mecanismos para proporcionary vigilar ese servicio en el sistema.
UCB TJA INF 342
132
• En la figura siguiente, los umbrales de servicio,límites, y garantías son ahora todos aplicados al sobrede 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
133
Sobre de Rendimiento Completamente Desarrollado
A, B, Y -Servicios GarantizadosD, M, X -Umbrales GenéricosC-Ambiente de umbrales específicosL, Z-Límites de Servicio
Retardo (D)
Capacidad (C)
Confiabilidad (R)
B ms
A ms
D ms
C msY %X % Z %
M Mb/s
L MB/s
UCB TJA INF 342
134
Aplicación de Telemetría• Primero consideremos un ambiente de aplicación de
telemetría, como es mostrado en la figura.
RED
Control Guiado
Telemetría
Computadorde Control de Guiado
ComputadorVisiualización de movimiento
UCB TJA INF 342
135
Aplicación de Telemetría– En un análisis de este ambiente, hemos determinado (de
las discusiones con los usuarios finales y diseñadores dela aplicación) que para que esta aplicación sea útil, losdatos deben ser recibidos por la computadora decomando guiado dentro de 20 ms después de sergenerados del helicóptero.
– También sabemos que el controlador actuarárecíprocamente con el helicóptero basado en la entradade flujo de telemetría, y que esto será ligado por elHRT 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
136
Apl
icac
ione
s de
Tel
emet
ría
20 ms Retardo (ms) 100 ms (HRT)
Limites de Retardo para el ejemplo de Telemetría
UCB TJA INF 342
137
Consolidando la ComputaciónFigura 3-19
Red
Red
Red
AsignadorRecursos
Red
AsignadorRecursos
Denver
Chicago
Chicago
Denver
WAN
WAN
Red
Usuarios
MainframeAlmacenamiento
Memphis
Red
AsignadorRecursos
Usuarios
Storage Farm
Memphis
Cluster deCómputo
Después de la Consolidación
Antes de la Consolidación
UCB TJA INF 342
138
Consolidando la Computación
– La aplicación primaria en este ambiente es un asignador de recursos decomputación, una aplicación que chequea los recursos dentro del sistemay asigna trabajos de computo a cada uno de los servidores decomputación, basada en los requerimientos del trabajo.
– La asignación se hace rápidamente, en el orden de 250 ms, y el estado decada servidor de computación está constantemente verificándose.
– Antes de la consolidación, la confiabilidad de los servidores decomputación a sus usuarios estaban sobre 99.97%, mientras la meta defiabilidad era sólo de 99.95%.
– Para el ambiente consolidado, ellos quieren esforzarse para un gradomejor de confiabilidad y esperan lograr 99.99%, pero aceptará un gradomás bajo de confiabilidad, aunque no debajo de la confiabilidad real delsistema anterior (99.97%).
UCB TJA INF 342
139
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
140
Límites de Confiabilidad para Aplicaciones de Asignación de Recursos
Después deConsolidación
99.95%
Mínimo
Confiabilidad (% Uptime)
99.99%99.97%
Meta
Meta Actual
Antes deConsolidación
UCB TJA INF 342
141
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
142
Sobre de Rendimiento con Servicio Especificado
C apacidad (C )
C onfiab ilidad (R )
R etardo (D )
14 M b/s
20 M b/s
99.8% D isponibilidad
80 m s
UCB TJA INF 342
143
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, bajorendimiento, alto rendimiento, y servicios especificados.
– Hemos tocado aplicaciones como misión-crítica, tiempo real, yrazón controlada para distinguirlos de los servicios específicosnecesitados, y también hemos desarrollado umbrales generalesy de ambiente específico para separar los requerimientos derendimiento en bajo y alto rendimiento para su ambiente deldiseño.
– Ahora, examinaremos algunas pautas para ayudarle a usarestos conceptos juntos para distinguir entre los niveles derendimiento de servicio para sus diseños.
UCB TJA INF 342
144
Pautas en la Distinción de Servicios
• Usted debe usar estos pasos cuando usted quiere ver, en parte oen conjunto, modificando su secuencia para encajar mejor sumetodología de análisis y ambiente de diseño.
• Para que usted aplique estos pasos, usted necesita tener unlistado de las aplicaciones que probablemente se usarán en estared, junto con cualquiera información de rendimiento que ustedpuede 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 talmodoque el último paso sea el valor por defecto cuando ninguno de los
otros pasos se aplican.
UCB TJA INF 342
145
Pautas en la Distinción de Servicios
• 1. El primer paso es determinar si cualquiera delas aplicaciones tienen requerimientos obviospara especificar (deterministico o garantizado)el rendimiento del sistema.
• Cuando una aplicación tiene requerimientos parael rendimiento especificado, la aplicación y susrequerimientos son nombrados comoespecificados.
UCB TJA INF 342
146
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
147
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
Introducción A&D de Redes 148
Análisis de Flujo
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales Análisis
Diseño
UCB TJA INF 342
UCB TJA INF 342
Introducción A&D de Redes 150
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
UCB TJA INF 342
Introducción A&D de Redes 151
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
Introducción A&D de Redes 152
Análisis de flujo 3• Hay tres tipos de flujos
– Individual– Compuesto– Backbone
• Los cuales se deben localizar y especificar
UCB TJA INF 342
Fronteras de datos, flujos compuestos y troncales
C
B
A
GW CPD
f a
f b
fd/g
fa f c/e f d/g fc/e fd/gf f
f ff a
fd/g
fc/e
fd/gf a
fc/e
fd/g
f afc/e
f a
f a
fc/e
f bfd/g
f a fc/e
CF1
CF2
CF6
CF3
CF4
CF5BB2
BB180
30
60
75
UCB TJA INF 342
Introducción A&D de Redes 154
Diseño lógico
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales Análisis
Diseño
UCB TJA INF 342
UCB TJA INF 342
Piramide de Akapana – La Paz
Piramide de Akapana – La Paz
Diseño LógicoModelo de Redes Jerárquicas
Introducción A&D de Redes 156
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
Objetivos• Introducir al lector en el diseño de las
Redes LAN utilizando el modeloJerárquico
• Describir cómo una red jerárquicaadmite las necesidades de voz, video ydatos de una pequeña y mediana empresa
• Identificar las características que debencumplir los switch´s utilizados con cadacapa 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. Estacapa de acceso puede incluir routers, switches, puentes, hubs y puntosde acceso inalámbricos. El propósito principal de la capa de acceso esaportar 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 deacceso antes de que se transmitan a la capa núcleo para el enrutamiento hacia sudestino final. La capa de distribución controla el flujo de tráfico de la red con eluso de políticas y traza los dominios de broadcast al realizar el enrutamiento delas funciones entre las LAN virtuales (VLAN) definidas en la capa de acceso. LasVLAN permiten al usuario segmentar el tráfico sobre un switch en subredesseparadas.
UCB TJA INF 342
Modelo Jerárquico (capa por capa)
La capa núcleo del diseño jerárquico es la backbone de alta velocidadde la internetwork. La capa núcleo es esencial para lainterconectividad entre los dispositivos de la capa de distribución, porlo tanto, es importante que el núcleo sea sumamente disponible yredundante. El área del núcleo también puede conectarse a losrecursos de Internet. El núcleo agrega el tráfico de todos losdispositivos de la capa de distribución, por lo tanto debe poderreenviar 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• Al diseñar una topología de
red jerárquica, lo primeroque debe considerarse esel diámetro de la red. Confrecuencia, el diámetro esuna medida de distanciapero en este caso se utilizael término para medir elnúmero de dispositivos. Eldiámetro de la red es elnúmero de dispositivos queun paquete debe cruzarantes de alcanzar sudestino. Mantener bajo eldiámetro de la red asegurauna latencia baja ypredecible entre losdispositivos.
UCB TJA INF 342
Principios clave del diseño de red jerárquica
Agregado de Ancho debanda:
• Cada capa en elmodelo de redesjerárquicas es unacandidata posible parael agregado de anchode banda. El agregadode ancho de banda esla práctica deconsiderar losrequisitos de ancho debanda específicos decada parte de lajerarquía.
• EtherChannel
UCB TJA INF 342
Principios clave del diseño de red jerárquica
• Redundancia: es unaparte de la creación deuna red altamentedisponible. Se puedeproveer redundancia devarias maneras. Porejemplo, se puedenduplicar las conexionesde red entre losdispositivos o se puedenduplicar los propiosdispositivos.
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 necesarioque el tráfico de datos con voz y video se clasificara y priorizaraen 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 switchesque 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:
AccesoDistribuciónNú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
UCB TJA INF 342
Diseño Físico
Diseño Físico 176
Diseño Físico
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales
Análisis
Diseño
UCB TJA INF 342
Introducción A&D de Redes 177
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...)
UCB TJA INF 342
Diseño Físico 178
Etapas del diseño físico
Evaluar diseño del cableado
Ubicar equiposde red
Construirdiagramas físicos
Diseño lógico
Diseño físico
Direccionamientoy ruteo
UCB TJA INF 342
Diseño Físico 179
Etapa:Evaluar diseño de cableado
• Opciones:– Centralizado– Distribuido
• Componentes medio ambientales a considerar– Calor, ventilación– Dimensiones, espacio– Corriente, reguladores de voltaje, UPS
UCB TJA INF 342
Diseño Físico 180
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
• Reduce tamaño de grupos(redes, subredes, broadcast)• Crear jerarquías• Acerca los equipos a los usuarios• Dificult la administración
UCB TJA INF 342
Diseño Físico 181
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
UCB TJA INF 342
Diseño Físico 182
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
UCB TJA INF 342
Diseño Físico 183
Etapa:Ubicar equipos de red
• Codificación– Ejemplo
– 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.
Nombre sitio, IDdirección IP remota/Dirección IP localPuerto local-puerto remoto/velocidad/protocolo/clase/servicio
MATRIX S.A., #151-2199.99.99.1/199.99.99.1541-542/E1/OSPF/C2/RDSI-BE
UCB TJA INF 342
Diseño Físico 184
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
UCB TJA INF 342
Diseño Físico 185
Etapa:Construir diagramas de la red
199.200.50.0 199.200.51.0
.3 .2 .2 .3 .2 .3
.1.1
.1
.4
.5
.6
DISEÑO LOGICO
199.200.52.0
UCB TJA INF 342
Diseño Físico 186
Etapa:Construir diagramas de la red 2
DISEÑO FÍSICO
P1 P4 P1 P2P1 P4
E11E12
E131
2 3 4 5
P4P3
2423 22 21
PP1/Ptrt2 PP2/Ptrt3 PP1/Ptrt1
PP1/Ptrt2 : Patch Panel 1 / Puerta 2
Edificio APieza 104
Pieza 208
Edificio BPieza 100
P2
UCB TJA INF 342
Introducción A&D de Redes 187
Direccionamiento y ruteo –Ejecución del diseño
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales Análisis
Diseño
UCB TJA INF 342
Introducción A&D de Redes 188
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
Introducción A&D de Redes 189
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
Introducción A&D de Redes 190
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
UCB TJA INF 342
UCB TJA INF 342
Caso de Estudio 1Actualización de la Red
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 RedEdificios A y B
UCB TJA INF 342
Diseño Actual de la RedEdificio C
UCB TJA INF 342
Tipos de RedClasificació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 MbpsRedes 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 hostsintermedios, 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 RedTopologí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ónllega 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 RedEthernet: 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ñoSubredes
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ñoSubredes 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ñoSubredes 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ñoSubredes 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 � 22B � 4C � 10Si 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ñoSubredes con máscara de tamaño variable
1er. Direccionamiento IP* Edificio A-- 22 ordenadores
Le asignamos una subred de 32 direcciones:Subred Máscara Subred/bits
de máscara192.168.2.32 255.255.255.224 192.168.2.32/27
*Edificio B-- 4 ordenadoresLe asignamos una subred de 8 direcciones:
Subred Máscara Subred/bits de máscara
192.168.2.8 255.255.255.248 192.168.2.8/29
*Edificio C-- 10 ordenadoresLe asignamos una subred de 16 direcciones:
Subred Máscara Subred/bits de máscara192.168.2.16 255.255.255.240 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ñoSubredes con máscara de tamaño variable
2º Direccionamiento IP
* Edificio A-- 22 ordenadoresLe asignamos una subred de 64 direcciones:
Subred Máscara Subred/bits de máscara
192.168.2.64 255.255.255.192 192.168.2.64/26
* Edificio B-- 4 ordenadoresLe asignamos una subred de 16 direcciones:
Subred Máscara Subred/bits de máscara
192.168.2.16 255.255.255.240 192.168.2.16/28
* Edificio C-- 10 ordenadoresLe asignamos una subred de 32 direcciones:
Subred Máscara Subred/bits de máscara
192.168.2.32 255.255.255.224 192.168.2.32/27
É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
UCB TJA INF 342
Caso de Aplicación
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 ACentro de pruebas, centro de computación y centro de
visualización ( Monitoreo)
• Sede BCentro de fabricación de prototipos
• Sede CCentro de análisis
UCB TJA INF 342
Localización de los edificios
SEDE CCentro de Análisis
SEDE BCentro Fabricación
SEDE A
GW CPD
Pruebas
Pruebas
Pruebas
: Caso Estudio
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
Requerimientos del usuarioTipos de Requerimientosde usuarios
Descripción deRequerimientos
Localización y número deusuarios
Sede A: 75 usuariosSede B: 30 usuariosSede C: 80 usuariosCentro de computacióny pruebas, sede A: 60 usuarios
Crecimiento esperado en 1 año50 % incremento
Interactividad Mismo funcionamiento enremoto que en local
Fiabilidad 100% en algunas aplicaciones
Seguridad Pruebas independientes entre sí
Caso Estudio
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 identificarAplicació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 aplicacionesCategorización deaplicaciones
MisiónCrítica
Tiempo real Mejor esfuerzo Localización delas aplicaciones
Aplicación A Tamaño 100 MBUsuarios simultaneos:2TT hasta 10 minCliente/servidor
En todaslocalidades
Aplicación B Tamaño 10 MB40 trans/minuto
Localidad C
Aplicación C y E TR=40ms1,69 MbpsDisp:100%SesionesConcurr. 4
App.C: Loc AApp.E:Loc C
Aplicación D y G TR=80ms5 Mbps por grupo2 gruposconcurrentesCliente/ Servidor
App.D:Loc AApp G:Loc C
Aplicación F 400 KbpsCliente/servidor
Localidad B
UCB TJA INF 342
Requerimientos de Hosts
Tipo de Host Número y localización
Estaciones gráficas En todas las localidadesServidor aplicación A CPD A
Servidor aplicaciones D y G CPD A
Servidor aplicación F Localidad B
Servidor aplicación B Localidad C
Host central CPD A
UCB TJA INF 342
Requerimientos de redesRedes 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 protegidosContra accesos externos.PRESUPUESTO: La compañía indica que dispone para la inversión correspondiente
UCB TJA INF 342
Mapa de aplicaciones del caso
CPD
Aplicación A
Aplicación F
Aplicaciones C y D
Aplicaciones E y G
A
B
C
Aplicación B Aplicaciones E y G
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 deaplicaciones
Tiempo detránsito
Capacidad Disponibilidad
Aplicación A 100 ms HRT(**)
2,7 Mbps(*)
99,5%(**)
Aplicación B 100ms HRT(**)
53 Mbps (*)
99,5%(**)
Aplicación C y E RT=40ms 1,69 Mbps 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
Capacidad
Tiempo de tránsito
40ms
53Mb/seg
Disponibilidad
100%400 Kb/seg
99,5%
100 ms
UCB TJA INF 342
Caso Estudio
UCB TJA INF 342
Fuentes y destinos de datos para Aplicación A
C
B
A
GW CPD
: Caso Estudio
Representación entrante saliente
UCB TJA INF 342
Fuentes y destinos de datos para Aplicaciones D y G
C
B
A
GW CPD
: Caso Estudio
UCB TJA INF 342
Fuentes y destinos de datos para Aplicación F
C
B
A
GW CPD
Caso Estudio
UCB TJA INF 342
Fuentes y destinos de datos para Aplicación B
C
B
A
GW CPD
Caso Estudio
UCB TJA INF 342
Fuentes y destinos de datos para Aplicación C y E
C
B
A
GW CPD
: Caso Estudio
UCB TJA INF 342
Fronteras de datos, flujos compuestos y troncales
C
B
A
GW CPD
f a
f b
fd/g
fa f c/e f d/g fc/e fd/gf f
f ff a
fd/g
fc/e
fd/gf a
fc/e
fd/g
f afc/e
f a
f a
fc/e
f bfd/g
f a fc/e
CF1
CF2
CF6
CF3
CF4
CF5BB2
BB180
30
60
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 Distribución deflujo
faCliente/servidor A, B, C 20/80
fbCliente/servidor C 80/20
fc/eA la par A, C 20/80
fd/gCliente/servidor A, C 20/80
f fCliente/servidor A, B 50/50
UCB TJA INF 342
Especificaciones de flujo
Flujo Fiabilidad Capacidad Tránsito
fa99,5% 2,7Mbps 100ms
fb99,5% 53 Mbps 100 ms
fc/e100% 1,69 Mbps 40 ms
fd/g99,5% 10 Mbps 80 ms
f f99,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
Especificaciones de flujos troncales
Flujo Fiabilidad Capacidad Tránsito
BB1 100% 29 Mbps 40 ms
BB2 100% 33 Mbps 40 ms
Caso Estudio
UCB TJA INF 342
Ej. Capacidades Enlaces y la elección de tecnología
UCB TJA INF 342
Ej. Capacidades Enlaces y la elección de tecnología
Caso Estudio
UCB TJA INF 342
Caso Estudio
UCB TJA INF 342
Diseño segmentado en campus y bloques
Campus C
Campus B
Campus A
GW CPD
: Caso Estudio
UCB TJA INF 342
Tráficos BB1 y CF6
Campus C
Campus B
Campus A
Caja Negra
Caja Negra
Caja Negra
CF6 (R=99,5% C=3,5 Mbps TT=100ms)
BB1 (R=100% C=29 Mbps TT=40ms)
Suministrador de servicios para estos flujos•Opciones FR, ATM, RDSI, ADSL
Caso Estudio
UCB TJA INF 342
Elección de tecnologías para caja negra A
Caja Negra Caja NegraGW CPD
Caja Negra
Caja Negra
CF3:R=100%,C=14Mbps,TT=40ms
BB2:R=100%,C=33Mbps,TT=40msFlujo más críticoCon más probabilidades de crecimientoPosibilidades
ATMFDDIEthernet 100 Mbps
ATM 155 Mbps
PosibilidadesATMFDDIEthernet 100 Mbps
Ethernet conmutado100 Mbps
Caso Estudio
UCB TJA INF 342
Elección de tecnologías para Campus C
Caja NegraB1R=100%,C=67 Mbps,TT=100 ms
CF1
CF2
Factor de crecimiento 50%. Posibilidad de crecer hasta 100 MbpsEl mayor flujo es local (Fb=53 Mbps)Opciones Tecnológicas: ATM 155 Mbps, GigaEthernet
Caso Estudio
UCB TJA INF 342
Diseño lógico completo
C
B
A
GW CPD
Ethernet 10 Mbps
ATM 155 Mbps de unsuministrador de servicios
Caso Estudio
UCB TJA INF 342
Mezclas de conmutación con otras tecnologías
LANE sobre ATM
Subred IP A
Subred IP B
Subred IP CClassical IP ATM
(RFC1577)
Caso Estudio
UCB TJA INF 342
Ejemplo de problemas de mal diseño
Subred IP A
Subred IP B
Localidad 1 Localidad 2
Un flujo de datos localtiene que atravesar la WAN
Caso Estudio
UCB TJA INF 342
Tipos de conectividad con el exterior
Redesexternas
Redesinternas
Redesexternas
Redesinternas
Redesexternas
Redesinternas
Servidor de seguridad
Red de perímetroZona desmilitarizada
Servidor de seguridad/NAT
Servidor Web
Servidor Webinterno
Servidor Webexterno
Caso Estudio
UCB TJA INF 342
Mecanismos híbridos. NHRP
Subred IP A
Subred IP B
Localidad 1 Localidad 2
El primer flujo hace usodel encaminamiento
Los siguientes usan conmutación
Caso Estudio
UCB TJA INF 342
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 1:1
Bajo 2:1
Medio 3:1----5:1
Alto Mayor o igual de 6:1
Caso Estudio
UCB TJA INF 342
Caso estudio. Grado de jerarquías y redundancia
Campus C
Campus B
Campus A
GW CPD
2:1
5:1 3:1
Caminos que necesitandisponibilidad entre media y alta
Caso Estudio
UCB TJA INF 342
Diseño lógico con routers y conmutadores
Campus C
Campus B
Campus A
GW CPDATM 155 Mbps de unsuministrador de servicios
RFC1577
RFC1577 RFC1577
RFC1577
RFC1577
Caso Estudio
UCB TJA INF 342
UCB TJA INF 342
TALLER INF 342
UCB TJA INF 342
Protocolo de Presentación
1. Introducción2. Objetivos3. Análisis Teórico (De su aporte para el Taller)4. Diseño Red de Computadoras Corporativa
a) Condiciones Generalesb) Análisis de Requerimientosc) Análisis de Flujosd) Diseño Lógicoe) Diseño Físicof) Direccionamiento y ruteog) Recomendaciones para la ejecución del proyecto
5. Simulación (configuración de equipos)6. Costo aproximado del proyecto7. Impacto y conciencia social del proyecto8. Identificación de valores católicos9. Conclusiones, recomendaciones y aportes10. Bibliografía y Web grafía
UCB TJA INF 342
Análisis derequerimientos
Análisis deflujo
Diseñológico
Diseño físico
Direccionamientoy ruteo
Ejecucióndel diseño
Condicionesiniciales Análisis
Diseño
UCB TJA INF 342
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ónDefensa y última presentación: 20 de Noviembre con Jurado invitado. Cumplir todos los puntos del Protocolo de Presentación.
Fechas de entrega de documento y defensa del Taller
FIN !!!!
UCB TJA INF 342