1 análisis de requerimientos: pautas zlas pautas para el análisis de requerimientos son parte del...
TRANSCRIPT
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.