1 1 Análisis de Requerimientos: PAUTAS zLas 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 2 Análisis de Requerimientos: PAUTAS

3 3 Determinar Condiciones Iniciales zTipo de diseño del proyecto yNuevo diseño ymejorar una red existente ycontratar a un outsourcing zDimensionamiento yTamaño de la red yGeográfico yFinanciero

4 4 Condiciones Iniciales zObjetivos del diseño inicial (si está disponible) zFuerzas externas/restricciones yPolitico - Quien está a cargo? yAdministrativo - Comité que toma decisiones? zEvaluación de la situación existente yPorque estamos haciendo esto? Que tiene de errado la red del sistema existente?

5 5 Desarrollar Métricas de Servicio zMétricas para Confiabilidad yDisponibilidad yEstabilidad (MTBF,MTTR) yCaracterísticas de Transmisión xRazón de Error de bits xRazón de Pérdida de Celdas xRazón de Pérdida de Paquetes/frames

6 6 Métricas de Servicio zMétricas de Capacidad yRazón de Datos xRazón de datos peak xRazón de datos sostenido yTamaño de los datos xTamaño de ráfaga y duración xTamaño del paquete/frame promedio y Máximo xDistribución del tamaño de paquetes xTamaño de la Transacción

7 7 Métricas de Retardo zExtremo a Extremo / Ida y Vuelta zTiempo de respuesta del sistema host zVariación del Retardo zVariaciones con condiciones de cambio de red

8 8 Herramientas de Medición en Red zContadores SNMP en hubs/switches ycuenta el tránsito de los paquetes yPaquetes enviados yPaquetes eliminados yErrores zMonitores Externos yRemote MONitoring (RMON)

9 9 Herramientas de Medición en Red zHerramientas simples de Software yPing yNetperf zHerramientas de Análisis

10 zLocaliza cuellos de botella de rendimiento zProvee alta disponibilidad de la red zAdministración de Rendimiento Proactivo zAnálisis de Tendencia en Rendimiento zAnálisis de Rendimiento de redes mezcladas SNA/IP zAumenta el operador de productividad zRedundancia, seguridad, y verificación Monitor de Rendimiento entre redes CiscoWorks Blue Internetwork Performance Monitor 2

11 11 Localizar Cuellos de Botella en Rendimiento z Análisis de Rendimiento Salto a Salto a través de la red Usuario final IPM

12 12 Análisis de Rendencia de Rendimiento zChequea la red por períodos largos de tiempo zMuestra los tiempos máximos de respuestas zMuestra los tiempos mínimos de respuestas zMuestra tiempos de respuesta promedio zMuestra errores que podrían contribuir a tiempos de respuestas pobres

13 13 Redundancia, Seguridad y Verificación z Identifica trayectorias redundantes en la red z Estima la utilización de rutas redundantes

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

15 15 Tabla de métrica de Servicio

16 16 Caracterizar el Comportamiento zPatrones de uso xLos patrones del uso pueden incluir para cada aplicación el número total de usuarios para cada aplicación xLa frecuencia que se espera que un usuario use la aplicación (número de sesiones/día de uso) xCuánto tiempo promedio durará una sesión de la aplicación (normalmente en segundos) xUna estimación del número esperado de sesiones de usuario simultáneas para la aplicación

17 17 Patrones de uso

18 18 Caracterizar el Comportamiento zComportamiento de la aplicación xCaracterizando 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). xModelos simples y complejos.

19 19 Desarrollo de Umbrales de Rendimiento yDistinguiendo 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. x3Los servicios especificados tendrán límites o garantías limitadas.

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

21 21 Requerimientos de Confiabilidad zDisponibilidad xPara 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.

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

23 23 Disponibilidad medida selectivamente entre redes

24 24 Disponibilidad Testbeds Mayoría sistemas comerciales Sistemas de Misión Crítica Sistemas de Tiempo Real Systemas de muy alta disponibilidad

25 25 Tiempo de Reestablecimiento xMTBF/MTBSO y MTTR son tiempos promedios xMTBF 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). xMTTR 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.

26 26 Disponibilidad con MTBF/MTBSO y MTTR

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

28 28 Umbrales para la confiabilidad xEvalú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 xDetermine los umbrales de bajo-rendimiento/alto- rendimiento xEstime 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.

29 29 Umbrales de referencia general para Requerimientos de Usuario

30 30 Para Disponibilidad: Las estimaciones del umbral general son: zConfiabilidad de Testbed o Prototipo (disponibilidad): menos de 95% zConfiabilidad de bajo-rendimiento (disponibilidad): menos de 99.9% zConfiabilidad de alto-rendimiento (disponibilidad): mayor que o iguala a 99.9% z(Nota: Éstos umbrales de disponibilidad son medidos mensualmente.)

31 31 Para el Reestablecimiento, medido como MTBF/MTBSO y MTTR, las estimaciones de umbral general son: yConfiabilidad de bajo-rendimiento (reestablecimiento): MTTR mayor que 2 horas o un MTBF/MTBSO menos de 8000 horas yConfiabilidad de alto rendimiento (reestablecimiento): MTTR menor de o igual a 2 horas y MTBF/MTBSO mayor que o iguala a 8000 horas y(Nota: Estos umbrales de reestabecimiento se escogen para proveer un MTTR razonable. Si un MTTR más pequeño es escogido, entonces el MTBF /MTBSO será correspondientemente más bajo.)

32 32 Razón de pérdida de información de extremo- a-extremo ó razón de retransmisión zBajo-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

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

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

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

36 36 Tiempo de Respuesta Humano (HRT) yHRT 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.

37 37 Retardo de propagación de red yEstima el retardo de la propagación de la señal en la red. yEsto proporciona un límite inferior a los retardos de extremo-a-extremo y de ida y vuelta de la red y del sistema. yEl retardo de la propagación es dependiente en la distancia y tecnología. yEs ú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.

38 38 Estimación de retardos para requerimientos de usuarios

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

40 40 Tiempo de realización de Tarea (TCT) yEl 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. yPara 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. yTCT, medido en segundos, y el retardo de extremo-a- extremo RTT medido en milisegundos.

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

42 42 Razón HRT a RTT zLa 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. zUn 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.

43 43 Tiempos de RTT, TCT y HRT zLa 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):

44 44 Respuesta del Sistema zRespuesta del sistema = HRT/TCT, cuando HRT/RTT >= 1 zRespuesta del sistema = HRT/(RTT*TCT), cuando HRT/RTT < 1 zRespuesta del sistema < 3 (volumen interactivo) zRespuesta del sistema > 3 (ráfaga interactivo)

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

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

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

48 48 Variación de Retardo yLa 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. yAlgunos 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. yPor 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

49 49 Requerimientos de capacidad zRazón de Datos zTamaño de los datos

50 50 Ejemplos zPodemos preguntarles a varios usuarios qué tamaños de archivos ellos esperan transferir, y cuánto tiempo ellos están deseosos esperar por la transferencia. zConsidere 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.

51 51 Ejemplos zOtro ejemplo es un ambiente de computación donde múltiples hosts están compartiendo el procesamiento para una tarea. zEn cada iteración de la tarea, los datos se transfieren entre los hosts. zAquí 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). zUn ambiente de computación multiprocesador compartido, se muestra en la siguiente figura.

52 52 Ejemplo de un ambiente de Cómputo con Multiprocesadores

53 53 Región de Rendimiento con Umbrales Genéricos

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

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

56 56 Características de Retardo para una muestra de aplicaciones

57 57 Servicios Deterministicos zLos servicios deterministicos tienen características de rendimiento más específicos que el servicio al mejor esfuerzo que hemos estado discutiendo. zEn la mayoría de los casos, tendremos una buena estimación de éstos características de rendimiento, aunque no podremos garantizar rendimiento. zUsaremos 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.

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

59 59 Vigilancia de rendimiento de un flujo

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

61 61 zEn la figura siguiente, los umbrales de servicio, límites, y garantías son ahora todos aplicados al sobre de rendimiento de servicio. zEn 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.

62 62 Sobre de Rendimiento Completamente Desarrollado

63 63 Aplicación de Telemetría zPrimero consideremos un ambiente de aplicación de telemetría, como es mostrado en la figura.

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

65 65 Limites de Retardo para el ejemplo de Telemetría

66 66 Consolidando la Computación

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

68 68 Consolidando la Computación zAquí 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%). zEste 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. zSe muestran los límites en la confiabilidad para esta aplicación de asignación de recursos en la figura siguiente.

69 69 Límites de Confiabilidad para Aplicaciones de Asignación de Recursos

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

71 71 Sobre de Rendimiento con Servicio Especificado

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

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

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

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

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