Análisis de Requerimientos: PAUTAS

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

2. Análisis de Requerimientos:PAUTAS

3. Determinar Condiciones Iniciales • Tipo de diseño del proyecto • Nuevo diseño • mejorar una red existente • contratar a un outsourcing • Dimensionamiento • Tamaño de la red • Geográfico • Financiero

4. 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?

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

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

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

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

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

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

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

12. Tabla de métrica de Servicio

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

14. Patrones de uso

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

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

17. 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?

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

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

20. Disponibilidad medida selectivamente entre redes

21. 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. 99.98% 1.75 hrs. 8.75 mins. 99.99% 0.88 hrs. 4.4 mins. 99.999% 0.09 hrs. .4 mins. Disponibilidad Testbeds Mayoría sistemas comerciales Sistemas de Misión Crítica Sistemas de Tiempo Real Systemas de muy alta disponibilidad

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

23. Disponibilidad con MTBF/MTBSO y MTTR

24. 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 rutas probables extremo-a-extremo que las aplicaciones usarán, y qué equipo y servicios existen o pueden estar en esas rutas.

25. Umbrales de referencia general para Requerimientos de Usuario

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

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

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

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

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

31. Estimación de retardos para requerimientos de usuarios

32. Distinción entre aplicaciones de Ráfaga y Volumen

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

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

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

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

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

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

39. Región de Rendimiento con Umbrales Genéricos

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

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

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