You are on page 1of 68

DISEÑO DE REDES

DISE Ñ O DE REDE S Maestría Ge stión d e Sist ema s d e

Maestría Gestión de Sistemas de Información

Universidad Católica Boliviana “ San Pablo”

Características en el Diseño de Redes

Características en el Diseño de Re des Diseños raramente repetitivos Algo de Arte Combinación de Reglas

Diseños raramente repetitivos Algo de Arte Combinación de Reglas Evaluación y selección de tecnologías Conocimiento:

De la Tecnologías Servicios Sistemas

Enfoques

Enf oques TRADICIONAL Enfocado a la capacidad A nte p roblemas en la Red • Incrementar

TRADICIONAL

Enfocado a la capacidad Ante problemas en la Red

Incrementar el ancho de banda

NUEVAS CONSIDERACIONES

Tiempos de Transporte Fiabilidad Servicios a los usuarios

Análisis

Análisis Que es lo que quieren los usuarios Objetivos del diseño Maximizar rendimiento M á s

Que es lo que quieren los usuarios Objetivos del diseño

Maximizar rendimiento Más de una

Minimizar costos

ProsPros yy ContrasContras Costo vs. Rendimiento Simplicidad vs. Funcionalidad Equilibrio entre Arquitectura y funcionalidad

Costo vs. Rendimiento Sim p licidad vs . Funcionalidad Equilibrio entre Arquitectura y funcionalidad so l

solucn

Caracterización de los servicios

Caracterización de los serv ici os Peticiones de servicio. Identificadas por el grado de predecibilidad del

Peticiones de servicio. Identificadas por el grado de predecibilidad del servicio

Mejor voluntad. Nin ún control sobre la red. Esta tratará de cumplir lo mejor posible la petición sin ninguna garantía.

Específico. Determinista o garantizado. Algún tipo de control sobre la red.

Los servicios deben operar dentro de unos márgenes

Necesidad de poder efectuar mediciones para comprobar si las características de la petición coinciden con las realmente proporcionadas por la red. Calidad de Servicio.

Contratos de servicio: Acuerdos de Nivel de Servicio: SLA

Análisis de Requerimientos:

PAUTAS

Análisis de Requerimientos: PAUTAS Obtención de Requerimientos Desarrollo Mapa de Aplicaciones Desarrollar Métricas
Obtención de Requerimientos Desarrollo Mapa de Aplicaciones Desarrollar Métricas de Servicio para Medir Rendimiento
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
Usuarios/Aplicación
Determinar Umbrales de
Rendimiento
Distinción entre
Requerimientos de Servicio
Rendimiento Distinción entre Requerimientos de Servicio Condiciones Iniciales Modificadores de Rendimiento
Rendimiento Distinción entre Requerimientos de Servicio Condiciones Iniciales Modificadores de Rendimiento

Condiciones

Iniciales

Modificadores de Rendimiento

Aplicación Tipos / Grupos

Pautas en

distinguir

Servicios

6

Condiciones Iniciales

C on diciones I niciales Tipo de diseño del proyecto Nuevo diseño me j orar una

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

Condiciones Iniciales

C on diciones I niciales Objetivos del diseño inicial (si está di spon ible) Fuerzas externas

Objetivos del diseño inicial (si está disponible) Fuerzas externas/restricciones

Político - 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?

Desarrollar Métricas de Servicio

Desarrollar Métricas de S erv icio ⌧ Métricas para Confiabilidad • Disponibilidad • Estabilidad (MTBF,MTTR) •

Métricas para Confiabilidad

Disponibilidad

Estabilidad (MTBF,MTTR)

Características de Transmisn Razón de Error de bits Razón de Pérdida de Celdas Razón de Pérdida de Paquetes/frames

Métricas de Servicio

Mét ri cas d e S ervicio Métricas de Capacidad Raz ó n de Datos ⌧

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

Métricas de Retardo

Mét ri cas d e R etardo Extremo a Extremo / Ida y Vuelta T iempo

Extremo a Extremo / Ida y Vuelta Tiempo de respuesta del sistema host Variación del Retardo - Jitter Variaciones con condiciones de cambio de red

Herramientas de Medición en Red

Herramientas de Medición en Red Contadores SNMP en hubs/switches Cuenta el trá nsito de los paquetes

Contadores SNMP en hubs/switches

Cuenta el tránsito de los paquetes Paquetes enviados Paquetes eliminados Errores

Monitores Externos

Remote MONitoring (RMON)

Herramientas de Medición en Red

Herramientas de Medición en Red Herramientas simples de Software Pin g Net p erf Herramientas de

Herramientas simples de Software

Ping Netperf

Herramientas de Análisis

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

de redes mezcladas SNA/IP Aumenta el operador de productividad Redundancia, se g uridad, y verificación 2

Localizar Cuellos de Botella en Rendimiento

IPM
IPM
Localizar Cuellos de Botella en R endi mi en to IPM Usuario final An ál isis

Usuario final

Cuellos de Botella en R endi mi en to IPM Usuario final An ál isis d

Análisis de Rendimiento Salto a Salto a través de la red

Análisis del Rendimiento

Análisis del Rendimiento Ch equea l a re d por períodos largos de tiem po Muestra

Chequea la red por períodos largos de tiempo Muestra los tiempos máximos de respuestas Muestra los tiempos mínimos de respuestas Muestra tiempos de respuesta promedio Muestra errores que podrían contribuir a tiempos de respuestas pobres

tiempos de respuesta promedio Muestra errores que podrían contribuir a tiem p os de res p
tiempos de respuesta promedio Muestra errores que podrían contribuir a tiem p os de res p
tiempos de respuesta promedio Muestra errores que podrían contribuir a tiem p os de res p
tiempos de respuesta promedio Muestra errores que podrían contribuir a tiem p os de res p

Redundancia, Seguridad y Verificacn

Redundancia, Seguridad y V erificac ió n Identifica tra y ectorias redundantes en la red Estima

Identifica trayectorias redundantes en la red Estima la utilización de rutas redundantes

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

y Pérdida de paquetes IP como medidas de Confiabilidad LAN LAN x x Red de Área
LAN LAN x x Red de Área Extendida SNMP/CMIP es usado para obtener pérdida de
LAN
LAN
x
x
Red de Área Extendida
SNMP/CMIP es usado para obtener
pérdida de paquetes de datos
E
Monitoreo de
s ac
t
n
d
e
Ping es usado entre varios interfaces
para monitorear el retardo en la red
Red

Caracterizar el Comportamiento

Caracterizar el C ompor tamiento Patrones de uso ⌧ Los patrones del uso pueden incl uir

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

Sesio nes de Ap licación

Grafica de Patrones de uso

Sesio nes de Ap licación G ra fi ca de Pat rones d e uso Sesión

Sesión 1

Sesión 2

Sesión 3

Sesión 4

mero de Sesiones Simultáneas

Frecuencia

3 Sesión 4 Nú mero de Sesiones Simultáneas Frecuencia Activo Activo Activo Activo Activo Activo
3 Sesión 4 Nú mero de Sesiones Simultáneas Frecuencia Activo Activo Activo Activo Activo Activo
3 Sesión 4 Nú mero de Sesiones Simultáneas Frecuencia Activo Activo Activo Activo Activo Activo
3 Sesión 4 Nú mero de Sesiones Simultáneas Frecuencia Activo Activo Activo Activo Activo Activo
Activo Activo Activo
Activo
Activo
Activo
Activo
Activo
Activo
Activo
Activo

Activo

Activo Activo Activo Duración Activo Activo Activo Activo A ctivo Activo     Activo Activo
Activo
Activo
Activo
Activo

Duración

Activo Activo Activo Duración Activo Activo Activo Activo A ctivo Activo     Activo Activo

Activo

Activo

Activo
Activo
Activo
Activo

Activo

Activo

A ctivo Activo
A ctivo Activo
A ctivo Activo
A ctivo Activo
   
Activo
Activo

Activo

Activo Activo Activo Duración Activo Activo Activo Activo A ctivo Activo     Activo Activo
Duración Activo Activo Activo Activo A ctivo Activo     Activo Activo
Duración Activo Activo Activo Activo A ctivo Activo     Activo Activo
Duración Activo Activo Activo Activo A ctivo Activo     Activo Activo

20

Duración Activo Activo Activo Activo A ctivo Activo     Activo Activo 20

Caracterizar el Comportamiento

Caracterizar el C ompor tamiento Comportami ento d e l a ap licac ión ⌧ Caracterizando

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 al servidor); y el grado de multicasting en las comunicaciones (uno-a-uno, uno-a-muchos, muchos-a-muchos). Modelos simples y complejos.

Desarrollo de Umbrales de Rendimiento

Desarrollo de Umbrales de R en dimi en to Distinguir entre los servicios al mejor esfuerzo,
Distinguir entre los servicios al mejor esfuerzo, especificado, y servicios de alto/bajo rendimiento, usaremos el
Distinguir entre los servicios al mejor esfuerzo,
especificado, y servicios de alto/bajo
rendimiento, usaremos el criterio siguiente:
⌧1
Un umbral
eneral 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.

Requerimientos de Confiabilidad

Requerimientos de C on fi a bilid ad La medida más común de confiabilidad está en

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?

Requerimientos de Confiabilidad

Requerimientos de Confiabilidad Disponibilidad ⌧ Para un sistema q ue da servicio todo el día ,

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 de Cantidad de Tiempo fuera de Servicio Permitido (horas [h], minutos [m],
Disponibilidad
(%
Tiempo
de
Cantidad de Tiempo fuera de Servicio Permitido (horas [h], minutos [m], o
segundos [s] por periodo de tiempo)
Servicio)
Anual
Mensual
Semanal
Diario
95 %
438h
36,5h
8,4h
1,2h
99,5%
43,8 h
3,7h
50,5 m
7,2m
99,95%
4,38h
21,9m
5,05m
43,2s
99,98%
1,75h
8,75m
2,0m
17,3s
99,99%
0,88 h
4,4m
1,0m
8,7s
24

Medicn de Disponibilidad

Me di c ió n d e Di spon ibilid ad ¿Cómo puede medirse la 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.

Interfaces de Red x x Red de Área Extendida Ethernet LAN Monitores de Red 25
Interfaces de Red
x
x
Red de Área Extendida
Ethernet LAN
Monitores de Red
25
FDDILAN

Disponibilidad medida selectivamente entre redes

Disponibilidad medida se l ec ti vamen te ent re re des Usuarios LAN Usuarios LAN
Usuarios LAN Usuarios LAN Disponibilidad x Servidor de Lan Disponibilidad U suarios LAN Usuarios LAN
Usuarios LAN
Usuarios LAN
Disponibilidad
x
Servidor de Lan
Disponibilidad
U suarios LAN
Usuarios LAN

Disponibilidad

Di spon ibilid ad Disponibilidad Anual Mensual 95% 438 hrs. 36.5 hrs. 99.5% 43.8 hrs. 3.7

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 h

 

4

i

.

.

rs.

.

m ns.

Testbeds

Mayoría sistemas comerciales

Sistemas de Misión Crítica

Sistemas de Tiempo Real

Systemas de muy alta disponibilidad

Tiempo de Reestablecimiento

Tiempo de R ees tablecimi en to ⌧ MTBF/MTBSO y MTTR son tiempos promedios ⌧ MTBF

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.

28

Disponibilidad con MTBF/MTBSO y MTTR

99. 0 5 9 99. 8000 99. 99. 95 99. 98 MTTR 4000 4 horas
99.
0
5
9
99.
8000
99. 99.
95
99.
98
MTTR
4000
4
horas
2
horas
1hora
2000
1000
400
MTB F/MTBS O (Hora s)

Disponibilidad (% Tiempo de Conexión)

29

Razones de Error y rdida

R azones d e E rror y Pé rdida Las pérdidas pueden medirse en la capa

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

Razón de Pérdida de Paquetes

(

% d l t

e

r

áfi

t

t

o a

l d

e

l

a re

como

co

d)

Tiempo Total Máximo )

(

por mes

25% a 100%

 

Hasta 2 horas

2% a 24%

 

Hasta 3 horas

< 2%

 

Resto del mes

Umbrales para la confiabilidad

Umbrales para la con fi a bilid ad ⌧ Evalúe los requerimientos de disponibilidad de cada

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 .

Umbrales de referencia general para Requerimientos de Usuario

referencia general para R equerimi en tos d e U suario A lto - Rendimiento Bajo

Alto - Rendimiento

Bajo - Rendimiento

en tos d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0
en tos d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0
en tos d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0
en tos d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0

Testbed

d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5
d e U suario A lto - Rendimiento Bajo - Rendimiento Testbed 99 .0 99 .5

99.0

99.5

99.9

99.95 99.98

Disponibilidad (%)

Para Disponibilidad: Las estimaciones del umbral general son:

Dis p onibilidad: Las estimaciones del umbral general son: Confiabilidad de Testbed o Prototipo (disponibilidad):

Confiabilidad de Testbed o Prototipo (disponibilidad): menos de 95% Confiabilidad de bajo-rendimiento (disponibilidad): menos de 99.9% Confiabilidad de alto-rendimiento (disponibilidad): mayor que o iguala a 99.9%

(Nota: Éstos umbrales de disponibilidad son medidos mensualmente.)

Para el Reestablecimiento, medido como MTBF/MTBSO y MTTR, las estimaciones de umbral

general son:

y MTTR , las estimaciones de umbral general son: Confiabilidad de bajo-rendimiento (reestablecimiento): MTTR

Confiabilidad de bajo-rendimiento (reestablecimiento):

MTTR mayor que 2 horas o un MTBF/MTBSO menos de 8000 horas Confiabilidad de alto rendimiento (reestablecimiento): MTTR menor de o igual a 2 horas y MTBF/MTBSO mayor a 8000 horas (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.)

Razón de pérdida de información de extremo- a-extremo ó razón de retransmisión

de extremo- a-extremo ó razón de retransmisión Bajo-rendimiento (razón de pérdida): Pérdidas de paquete

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

Requerimientos de Retardo

R equer imi en tos d e R etardo H Data Network Red Componentes Aplicación •
H Data Network Red
H Data
Network
Red

Componentes

Aplicación

d e R etardo H Data Network Red Componentes Aplicación • Retardo de Interacción • Ti
d e R etardo H Data Network Red Componentes Aplicación • Retardo de Interacción • Ti

• Retardo de Interacción

• Tiempo de Respuesta Humano

• Retardo de propagación de la red

Host

36

Retardo de Interacción (INTD)

Retardo de Interacción (INTD) Estima cuánto tiempo un usuario está d eseoso esperar por una con

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.

Tiempo de Respuesta Humano (HRT)

Tiempo de Respuesta H umano (HRT) Estima el límite de tiempo cuando los usuarios empiezan a

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.

Tiempo de Respuesta Humano (HRT)

Tiempo de Respuesta H umano (HRT) HRT interactivas , donde los tiempos de espera no pueden

HRT

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.

es

importante

para

las

aplicaciones

muy

Retardo de propagación de red

Retardo de propagación de re d Es ti ma el ret ar do de l a

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.

Estimación de retardos para requerimientos de usuarios

de retardos para requer imi en tos de usuar i os Tiempo de Respuesta Humano Retardo

Tiempo de Respuesta Humano

requer imi en tos de usuar i os Tiempo de Respuesta Humano Retardo de Propagación de

Retardo de Propagación de Red

os Tiempo de Respuesta Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0
os Tiempo de Respuesta Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0

Retardo de Interacción

Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1
Humano Retardo de Propagación de Red Retardo de Interacción 0 . 0 1 0.1 1.0 1

0.01

0.1

1.0

10

100

Retardo (Segundos)

41

Distinción entre aplicaciones de Ráfaga y Volumen

Distinción entre aplicaciones de Ráfaga y Volumen Ráfaga Ráfaga/Volumen Volumen Interactivo Interactivo
Ráfaga Ráfaga/Volumen Volumen Interactivo Interactivo Interactivo 0.01 0.1 1.0 10 100 Retardo (Segundos)
Ráfaga
Ráfaga/Volumen
Volumen
Interactivo
Interactivo
Interactivo
0.01
0.1
1.0
10
100
Retardo (Segundos)
Tiempo de
Respuesta
Humano
Retardo
Interactivo

Tiempo de realización de Tarea (TCT)

Tiempo de realización de T area (TCT) El uso de INTD y HRT posiblemente es la

El 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. Para 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. TCT, medido en segundos, y el retardo de extremo-a- extremo RTT medido en milisegundos .

Tiempo de realización de Tarea (TCT)

Tiempo de realización de T area (TCT) Tarea Completada Transferencia de Datos 3 Transferencia de Datos

Tarea Completada

Transferencia de Datos 3

Transferencia de Datos 2

Transferencia de Datos 1

de Datos 3 Transferencia de Datos 2 Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo
de Datos 3 Transferencia de Datos 2 Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo

TCT

3 Transferencia de Datos 2 Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo Fuente Destino

Retardo

Retardo

Retardo

Datos 2 Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo Fuente Destino Dato Recibido /
Datos 2 Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo Fuente Destino Dato Recibido /

Tiempo

Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo Fuente Destino Dato Recibido / Procesado Dato
Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo Fuente Destino Dato Recibido / Procesado Dato
Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo Fuente Destino Dato Recibido / Procesado Dato
Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo Fuente Destino Dato Recibido / Procesado Dato
Transferencia de Datos 1 TCT Retardo Retardo Retardo Tiempo Fuente Destino Dato Recibido / Procesado Dato

Fuente

Destino

Dato Recibido / Procesado

Dato Recibido / Procesado

Dato Recibido / Procesado

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

Razón HRT a RTT

R az ón HRT a RTT La razón de HRT a RTT describe el grado de

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

Tiempos de RTT, TCT y HRT

Ti empos d e RTT , TCT y HRT La respuesta del sistema también es en

La 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):

Burstiness

B urs ti ness Otra manera de distinguir entre las aplicac i ones r áf ag

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 es la razón de datos peak

SDR es la razón de datos sostenido

Retardo de extremo-a- extremo

Retardo de extremo-a- ex tremo Está compuesto de muchas fuentes de re t ar d o,

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.

Variacn de Retardo

V ar i ac ió n d e R etardo La variación de retardo está acoplada

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 arribo de la información. Algunos ejemplos de tales aplicaciones son aquellos que producen o usan video, audio, informacn de telemetría etc. 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

Requerimientos de capacidad

Requerimientos de capac id ad Razón de Datos Tamaño de los datos Aplicación TCT Tamaño de

Razón de Datos Tamaño de los datos

Aplicación

TCT

Tamaño de Datos Promedio (Bytes)

Promedio

(Segundos)

 

CálculoDistribuido (Modo Batch)

3

10

7

10

Transaccionesti oWeb

p

10

4

10

Consultas Base de Datos

2-5

3

10

Ingresos de Pagos

10

2

10

Teleconferencia (usando Multicast)

3

10

3*10 5

Región de Rendimiento con Umbrales Genéricos

Región de Rendimiento con U mbral es G en éricos Umbral del Retardo Genérico Retardo (D)

Umbral del Retardo Genérico

Retardo (D)

es G en éricos Umbral del Retardo Genérico Retardo (D) Región de Bajo Rendimiento Regiones de
Región de Bajo Rendimiento
Región de
Bajo Rendimiento

Regiones de Alto Rendimiento

Umbral de Confiabilidad Genérica

de Alto Rendimiento Umbral de Confiabilidad Genérica Umbral de Capacidad Genérica Confiabilidad (R) Capacidad

Umbral de Capacidad Genérica

Confiabilidad (R)

de Alto Rendimiento Umbral de Confiabilidad Genérica Umbral de Capacidad Genérica Confiabilidad (R) Capacidad (C) 51

Capacidad (C)

51

Umbrales de Servicio de ambiente específico

Umbrales de Servicio de ambien te espec ífico Los umbrales generales nos dan algunas estimaciones comúnes

Los umbrales generales nos dan algunas estimaciones comúnes para las características de bajo y alto rendimiento. Tales umbrales son útiles cuando hay una falta de información sobre los usuarios y aplicaciones para la red a diseñar, pero a menudo el ambiente indica que umbrales de rendimiento deberían ser. Como con umbrales generales?: La razón por desarrollar umbrales de ambiente específico es para determinar qué aplicaciones tienen características de alto rendimiento. Es probable que estas aplicaciones de alto rendimiento son lo que nosotros diseñaremos, junto con esas aplicaciones que tienen características especificas.

Comparando Características de la Aplicacn

Comparando Características de la A p li cac ió n Cuando podemos agrupar características de la

Cuando podemos agrupar características de la aplicación, entonces una comparación puede hacerse a menudo para determinar donde el umbral puede aplicarse. Considere 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 siguiente En este diagrama, se agrupan características de retardo en dos áreas. Podemos usar esta información para poner un umbral de ambiente específico a un retardo de aproximadamente X milisegundos. Esas aplicaciones que tienen una característica de retardo de menos de X milisegundos son consideradas de alto rendimiento

para este ambiente.

(Denot adas po r letras)

plicacion es

A

Características de Retardo para una muestra de aplicaciones

de Retardo para una muest ra d e ap li cac iones Alto - Rendimiento Bajo

Alto - Rendimiento

Bajo - Rendimiento

J

muest ra d e ap li cac iones Alto - Rendimiento Bajo - Rendimiento J K

K

E

M

H B
H
B

L

A C
A
C
F
F
muest ra d e ap li cac iones Alto - Rendimiento Bajo - Rendimiento J K

D

I

G

muest ra d e ap li cac iones Alto - Rendimiento Bajo - Rendimiento J K
muest ra d e ap li cac iones Alto - Rendimiento Bajo - Rendimiento J K
muest ra d e ap li cac iones Alto - Rendimiento Bajo - Rendimiento J K

X ms

Retardo (ms)

Servicios Determinísticos

S erv icios Det erm inís ti cos Los servicios deterministicos tienen características de rendimiento más

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

capacidad y la especificación de flujo.

Servicios garantizados

Servicios g arantizados Los servicios garantizados son un paso más allá de los servicios determinísticos, en

Los servicios garantizados son un paso más allá de los servicios determinísticos, 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.

En 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. Al 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. Vigilar es a menudo útil para proteger el flujo de tráfico que fluye

h

recursos de la red que el contratado.

i

ac a

b

d

exce e

m

it

e

a

ajo

que

su

d

e

i

i

serv c o

y

i

t

t

n en a

usar

á

m s

Vigilancia de rendimiento de un flujo

Vigilancia de rendimiento de un fl ujo Garantía Servicio Límite / Garantía (p.ej. capacidad) , Vigilancia

Garantía

Servicio Límite / Garantía (p.ej. capacidad) , Vigilancia N o A cc ió n oma
Servicio Límite / Garantía
(p.ej. capacidad)
,
Vigilancia
N
o
A
cc
n oma
t
d
a
Comportamiento de la Aplicación
Time

Servicios garantizados

S erv icios garan ti za dos Se desarrollan garantías de servicio en una forma similar

Se 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. En 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%. 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.

58

Servicios garantizados

Servicios garantizados En la figura siguiente, los umbrales de servicio, límites, y garantías son ahora todos

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

Sobre el Rendimiento Completamente Desarrollado

Sobre el Rendimiento C omp letamente D esarro ll ado Ret ar d o (D) B

Retardo (D)

B ms A ms D ms C ms X % Z % Y % M
B
ms
A
ms
D
ms
C
ms
X %
Z %
Y %
M Mb/s
L MB/s
Confiabilidad (R)
ABY -Servicios Garantizados

Capacidad (C)

, D, M, X -Umbrales Genéricos C-Ambiente de umbrales específicos L, Z-Límites de Servicio

,

60

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

de Confiabilidad A p licaciones de Asignación de Recursos Mínimo Meta Después de Consolidación Meta Actual
Mínimo Meta Después de Consolidación Meta Actual Antes de Consolidación 99.95% 99.97% 99.99%
Mínimo
Meta
Después de
Consolidación
Meta
Actual
Antes de
Consolidación
99.95%
99.97%
99.99%

Rendimiento de Aplicación de Servicios

Rendimiento de Aplicación de S erv ici os Pueden aplicarse los límites determinísticos para todas las

Pueden aplicarse los límites determinísticos para todas las características de rendimiento a un sobre de rendimiento para la aplicación. Por ejemplo, si nosotros tenemos una aplicacn que requiere el siguiente rendimiento especificado:

la confiabilidad, 99.8%; la capacidad, entre 14 y 20 Mb/s; y retardo, no mayor que 80 ms, podemos aplicarlos como es mostrado en la siguiente figura.

Rendimiento con Servicio Especificado

Rendimiento con Servicio E spec ifica do Retardo (D) 80 ms 99.8% Disponibilidad Confiabilidad (R) 14

Retardo (D)

Rendimiento con Servicio E spec ifica do Retardo (D) 80 ms 99.8% Disponibilidad Confiabilidad (R) 14
80 ms
80 ms

99.8% Disponibilidad

con Servicio E spec ifica do Retardo (D) 80 ms 99.8% Disponibilidad Confiabilidad (R) 14 Mb/s

Confiabilidad (R)

14 Mb/s

20 Mb/s

Capacidad (C)

63

Distinguiendo entre los Niveles de Rendimiento de Servicio

Distinguiendo entre los Niveles de Rendimiento de Servicio Tenemos las descripciones para varios niveles de servicio

Tenemos las descripciones para varios niveles de servicio (rendimiento y función), como servicios al mejor esfuerzo, bajo rendimiento, alto rendimiento, y servicios especificados. Hemos 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. Ahora, examinaremos algunas pautas para ayudarle a usar estos conceptos juntos para distinguir entre los niveles de rendimiento de servicio para sus diseños.

Pautas en la Distinción de Servicios

Pautas en la Distinción de S erv ici os Se debe usar estos pasos cuando se

Se debe usar estos pasos cuando se quiere ver, en parte o en conjunto, modificando su secuencia para encajar mejor su metodología de análisis y ambiente de diseño.

Para aplicar estos pasos, se necesita

aplicaciones que probablemente se usarán en esta red, junto con cualquiera información de rendimiento que se puede recoger, derivar, o estimar. Estos pasos van del requerimiento más específico con los requerimientos de aplicaciones al más general, de tal modo que el último paso sea el valor por defecto cuando ninguno de los otros

tener un

listado de las

pasos se aplican.

Pautas en la Distinción de Servicios

Pautas en la Distinción de S erv ici os 1. El p rimer p aso es

1. El primer paso es determinar si cualquiera de las aplicaciones tienen requerimientos obvios para especificar (determinístico 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.

Pautas en la Distinción de Servicios

Pautas en la Distinción de S erv ici os 2. El segundo paso es listar las

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.

Pautas en la Distinción de Servicios

Pautas en la Distinción de S erv ici os 3. El tercer paso, es conformar grupos

3. El tercer paso, es conformar grupos de 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 distribuido; acceso de Web, desarrollo, y uso; transporte de volumen de datos; en 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

f

mejor es uerzo.