Anlisis de Requerimientos PAUTAS z Las pautas para

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

Análisis de Requerimientos: PAUTAS 2

Determinar Condiciones Iniciales z. Tipo de diseño del proyecto y. Nuevo diseño ymejorar una red existente ycontratar a un outsourcing z. Dimensionamiento y. Tamaño de la red y. Geográfico y. Financiero 3

Condiciones Iniciales z. Objetivos del diseño inicial (si está disponible) z. Fuerzas externas/restricciones y. Politico - Quien está a cargo? y. Administrativo - Comité que toma decisiones? z. Evaluación de la situación existente y. Porque estamos haciendo esto? Que tiene de errado la red del sistema existente? 4

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

Métricas de Servicio z. Métricas de Capacidad y. Razón de Datos x. Razón de datos peak x. Razón de datos sostenido y. Tamaño de los datos x. Tamaño de ráfaga y duración x. Tamaño del paquete/frame promedio y Máximo x. Distribución del tamaño de paquetes x. Tamaño de la Transacción 6

Métricas de Retardo z. Extremo a Extremo / Ida y Vuelta z. Tiempo de respuesta del sistema host z. Variación del Retardo z. Variaciones condiciones de cambio de red 7

Herramientas de Medición en Red z. Contadores SNMP en hubs/switches ycuenta el tránsito de los paquetes y. Paquetes enviados y. Paquetes eliminados y. Errores z. Monitores Externos y. Remote MONitoring (RMON) 8

Herramientas de Medición en Red z. Herramientas simples de Software y. Ping y. Netperf z. Herramientas de Análisis 9

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

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

Tabla de métrica de Servicio 15

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

Patrones de uso 17

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

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

Requerimientos de Confiabilidad z. 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? 20

Requerimientos de Confiabilidad z. Disponibilidad x. 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. 21

Medición de Disponibilidad z ¿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. 22

Disponibilidad medida selectivamente entre redes 23

Disponibilidad Anual Mensual 95% 438 hrs. 36. 5 hrs. 99. 5% 43. 8 hrs. 3. 7 hrs. 99. 95% 4. 38 hrs. 21. 9 mins. Mayoría sistemas comerciales 99. 98% 1. 75 hrs. 8. 75 mins. Sistemas de Misión Crítica 99. 99% 0. 88 hrs. 4. 4 mins. Sistemas de Tiempo Real 99. 999% 0. 09 hrs. . 4 mins. Systemas de muy alta disponibilidad Testbeds 24

Tiempo de Reestablecimiento x. MTBF/MTBSO y MTTR son tiempos promedios x. MTBF y MTBSO estiman la frecuencia de paros del sistema. Por ejemplo, un MTBF/MTBSO de 4400 horas (o 2. 64 E 5 minutos) establece que las fallas en el sistema son esperadas aproximadamente cada 6 meses (180 días). x. 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. 25

Disponibilidad con MTBF/MTBSO y MTTR 26

Umbrales para la confiabilidad x. 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 x. Determine los umbrales de bajo-rendimiento/altorendimiento x. Estime la disponibilidad basada en las rutas probables extremo-a-extremo que las aplicaciones usarán, y qué equipo y servicios existen o pueden estar en esas rutas. 28

Umbrales de referencia general para Requerimientos de Usuario 29

Requerimientos de Retardo Data H Aplicación Red Network Componentes • Retardo de Interacción • Tiempo de Respuesta Humano • Retardo de propagación de la red Host 33

Retardo de Interacción (INTD) zestima cuánto tiempo un usuario está deseoso esperar por una contestación del sistema durante una sesión interactiva. z. 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. 34

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

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

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

Estimación de retardos para requerimientos de usuarios 38

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

Tiempo de realización de Tarea (TCT) Esta conducta es consistente con aplicaciones que están procesando transacciones y cómputos distribuidos, o son cliente-servidor. 41

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

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

Variación de Retardo y 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. y 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. y 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 48

Requerimientos de capacidad z. Razón de Datos z. Tamaño de los datos 49

Ejemplos z 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. z 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. z 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. 50

Región de Rendimiento con Umbrales Genéricos 53

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

Pautas en la Distinción de Servicios z 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? z En ese caso, pueden tener requerimientos especificado de rendimiento, aun cuando ellos no se reconocieron en el primer paso. 75

Pautas en la Distinción de Servicios z 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. z Es probable que esas aplicaciones que no pueden ser descritas por Pasos l a través de 3 sean aplicaciones al mejor esfuerzo. 76