Transcript 00 pautasA

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.
1
Análisis de Requerimientos:
PAUTAS
Condiciones
Iniciales
Aplicación
Tipos / Grupos
Obtención de Requerimientos
Desarrollo
Mapa de Aplicaciones
Desarrollar Métricas de Servicio
para Medir Rendimiento
Variables de
Administración de Red
Caracterizando el
Comportamiento
Modificadores de Rendimiento
Usuarios/Aplicación
Determinar Umbrales de
Rendimiento
Distinción entre
Requerimientos de Servicio
Pautas en
distinguir
Servicios
2
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
3
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?
4
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
5
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
6
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
7
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)
8
Herramientas de Medición
en Red
Herramientas simples de Software
Ping
Netperf
Herramientas de Análisis
9
Monitor de Rendimiento
entre redes CiscoWorks Blue Internetwork
 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
Performance Monitor
2
Usando Ping y Pérdida de paquetes
IP como medidas de Confiabilidad
LAN
LAN
x
Red de Área Extendida
x
SNMP/CMIP es usado para obtener
pérdida de paquetes de datos
Estación de
Monitoreo de Red
Ping es usado entre varios interfaces
para monitorear el retardo en la red
14
Tabla de métrica de
Servicio
Métrica de Servicio
Donde la métrica será
medida en el Sistema
Método usado para la
medida
15
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
16
Patrones de uso
Número de Sesiones
Simultáneas
Frecuencia
Sesiones de Aplicación
Duración
Sesión 1
Sesión 2
Sesión 3
Sesión 4
Activo
Activo
Activo
Activo
Activo
Activo
Activo
Activo
Activo
Activo
Activo
Activo
Activo
Activo
17
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.
18
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.
19
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?
20
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
Cantidad de Tiempo fuera de Servicio Permitido (horas [h], minutos [m], o
(% Tiempo de segundos [s] por periodo de tiempo)
Servicio)
Anual
Mensual
Semanal
Diario
95 %
438 h
36,5 h
8,4 h
1,2 h
99,5%
43,8 h
3,7 h
50,5 m
7,2 m
99,95%
4,38 h
21,9 m
5,05 m
43,2 s
99,98%
1,75 h
8,75 m
2,0 m
17,3 s
21
99,99%
0,88 h
4,4 m
1,0 m
8,7 s
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
FDDILAN
Interfaces de Red
Ethernet LAN
Monitores de Red
22
Disponibilidad medida
selectivamente entre redes
Disponibilidad
Servidor de Lan
Usuarios LAN
Usuarios LAN
x
Disponibilidad
Usuarios LAN
Usuarios LAN
23
Disponibilidad
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.
99.999%
0.09 hrs.
.4 mins.
Testbeds
Sistemas de Tiempo Real
Systemas de muy alta
disponibilidad
24
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.
25
Disponibilidad con
MTBF/MTBSO y MTTR
MTBF/MTBSO (Horas)
8000
MTTR
4000
4 horas
2 horas
1hora
2000
1000
400
.0
99
.5
99
.9
99
.95
99 8
.9
99
Disponibilidad (% Tiempo de Conexión)
26
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/altorendimiento
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
Alto - Rendimiento
Bajo - Rendimiento
Testbed
99.0
99.5
99.9 99.95 99.98
Disponibilidad (%)
29
Requerimientos de Retardo
H
Data
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)
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.
34
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.
35
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.
36
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.
37
Estimación de retardos para
requerimientos de usuarios
Tiempo de Respuesta Humano
Retardo de Interacción
Retardo de Propagación de Red
0.01
0.1
1.0
10
Retardo (Segundos)
100
38
Distinción entre aplicaciones de
Ráfaga y Volumen
39
Tiempo de realización de
Tarea (TCT)
Tiempo
Tarea Completada
Retardo
Transferencia de Datos 3
Dato Recibido / Procesado
TCT
Retardo
Dato Recibido / Procesado
Retardo
Dato Recibido / Procesado
Transferencia de Datos 2
Transferencia de Datos 1
Fuente
Destino
Esta conducta es consistente con aplicaciones que están procesando
transacciones y cómputos distribuidos, o son cliente-servidor.
41
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
46
Retardo de extremo-aextremo
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.
47
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
48
Requerimientos de
capacidad
Razón de Datos
Tamaño de los datos
Aplicación
Cálculo Distribuido
(Modo Batch)
Transacciones tipo Web
Consultas Base de Datos
Ingresos de Pagos
Teleconferencia
(usando Multicast)
TCT
Promedio
(Segundos)
103
Tamaño de Datos Promedio
(Bytes)
10
2-5
10
103
104
103
102
3*105
107
49
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.
50
Región de Rendimiento
con Umbrales Genéricos
Retardo (D)
Umbral del
Retardo Genérico
Regiones de
Alto Rendimiento
Región de
Bajo Rendimiento
Umbral de
Capacidad
Genérica
Capacidad (C)
Umbral de
Confiabilidad
Genérica
Confiabilidad (R)
53
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.
74
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.
75
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.
76