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

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

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 bitsRazón de Pérdida de CeldasRazón de Pérdida de Paquetes/frames

6

Métricas de Servicio

Métricas de Capacidad Razón de Datos

Razón de datos peakRazón de datos sostenido

Tamaño de los datosTamaño de ráfaga y duraciónTamaño del paquete/frame promedio y MáximoDistribución del tamaño de paquetesTamaño de la Transacción

7

Métricas de Retardo

Extremo a Extremo / Ida y VueltaTiempo de respuesta del sistema

hostVariación del RetardoVariaciones 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

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 redes CiscoWorks Blue Internetwork

Performance Monitor

2

14

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

15

Tabla de métrica de Servicio

Métrica de Servicio Donde la métrica serámedida en el Sistema

Método usado para lamedida

16

Caracterizar el Comportamiento

Patrones de usoLos 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

17

Patrones de uso

Sesión 1

Sesión 2

Sesión 3

Sesión 4

Activo

Activo

Activo

Ses

ion

es d

e A

pli

caci

ón

Activo Activo Activo Activo Activo

Activo

Activo Activo

Activo

Activo Activo

FrecuenciaNúmero de Sesiones

Simultáneas

Duración

18

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.

19

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.

20

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?

21

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

22

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

FDDIL

AN

23

Disponibilidad medida selectivamente entre redes

Servidor de Lan x

Usuarios LAN

Disponibilidad

Usuarios LAN

Usuarios LAN

Usuarios LANDisponibilidad

24

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

25

Tiempo de Reestablecimiento

MTBF/MTBSO y MTTR son tiempos promediosMTBF 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.

26

Disponibilidad con MTBF/MTBSO y MTTR

MTTR

4 horas2 horas1hora

MT

BF

/MT

BS

O (

Hor

as)

8000

4000

2000

1000400

Disponibilidad (% Tiempo de Conexión)

28

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.

29

Umbrales de referencia general para Requerimientos de Usuario

Bajo - Rendimiento

Testbed

Alto - Rendimiento

99.0 99.5 99.9 99.95 99.98

Disponibilidad (%)

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

DataH

34

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.

35

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.

36

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.

37

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.

38

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 100

Retardo (Segundos)

39

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

41

Tiempo de realización de Tarea (TCT)

Retardo

Transferencia de Datos 2

Transferencia de Datos 1

Tarea Completada

Dato Recibido / Procesado

Dato Recibido / Procesado

Dato Recibido / Procesado

Retardo

Retardo

TCTTransferencia de Datos 3

Fuente Destino

Tiempo

Esta conducta es consistente con aplicaciones que están procesando transacciones y cómputos distribuidos, o son cliente-servidor.

46

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

47

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.

48

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

49

Requerimientos de capacidad

Razón de DatosTamañ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

50

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.

53

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

74

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.

75

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.

76

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.