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

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


• 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


• 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


Proceso general


Análisis deflujo

Diseñológico

Diseño físico




Diseño

UCB TJA INF 342

UCB TJA INF 342

Condiciones Generales


Análisis deflujo

Diseñológico

Diseño físico




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


Análisis de requerimientos


Análisis deflujo

Diseñológico

Diseño físico




Diseño

UCB TJA INF 342

UCB TJA INF 342


Conceptos relevantesSistemas

• Componentes y relaciones del sistema

Solicita

Servicios

Ofrece Red

Aplicación

Host

Usuario

Aplicación

Host

Usuario

UCB TJA INF 342


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


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


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 deflujo

Diseñológico

Diseño físico




Diseño

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

UCB TJA INF 342


Componentes

• Componentes y relaciones del sistema

Solicita

Servicios

Ofrece Red

Aplicación

Host

Usuario

Aplicación

Host

Usuario

UCB TJA INF 342


Naturaleza de los requerimientos

Diseño nueva red

Usuarios finales

Aplicaciones Hosts(PCs, servidores)

Redes existentes

UCB TJA INF 342


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


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


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


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


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


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


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


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


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


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


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


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



• 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



• 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



• 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


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



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


• 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


• 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


• 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


Análisis de Flujo


Análisis deflujo

Diseñológico

Diseño físico




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

UCB TJA INF 342


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


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


Diseño lógico


Análisis deflujo

Diseñológico

Diseño físico




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


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


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


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

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


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


• 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


• Identificar las características clave de los switchesque se usan en redes jerárquicas

UCB TJA INF 342


• Identificar las características de los switches que se encuentran en cada nivel de una red jerárquica

UCB TJA INF 342


• 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 deflujo

Diseñológico

Diseño físico



Condicionesiniciales

Análisis

Diseño

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...)

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


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


• 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


• 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


• 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


• 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


Direccionamiento y ruteo –Ejecución del diseño


Análisis deflujo

Diseñológico

Diseño físico




Diseño

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


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


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


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


2º Direccionamiento IP

* Edificio A-- 22 ordenadoresLe asignamos una subred de 64 direcciones:


192.168.2.64 255.255.255.192 192.168.2.64/26

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


192.168.2.16 255.255.255.240 192.168.2.16/28

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


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


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


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 deflujo

Diseñológico

Diseño físico




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

CAPITULO 12 METODOLOGIA DE DISEÑO DE REDES CORPORATIVAS

Documents

Transcript of CAPITULO 12 METODOLOGIA DE DISEÑO DE REDES CORPORATIVAS