Disponibilidad de Servicios

Transcript

1. ¿Cómo definir la disponibilidad de un servicio? Uptime, SLA y otras curiosidades Sábado, 16 de mayo, 2015 en Bit Center Por: Gabriel Covarrubias Grupos de Usuarios de GNU/Linux de Tijuana
2. Introducción • Es un tema complejo, pero muy importante. • Son varias diapositivas, tratare de ir rápido. • Si tiene preguntas, en cualquier momento interrumpan para responder. • Trataré de mantenerme serio y no bromear como siempre lo hago, profesionalismo.
3. ¿Qué es disponibilidad? Disponibilidad se refiere al grado en que un sistema o equipo se encuentra en condiciones operables al ser llamado en un momento determinado.
4. En otras palabras... Se refiere a la proporción de tiempo en que un sistema se mantiene en funcionamiento. Estos nos ayuda a determinar la confiabilidad de un sistema TIP: El nivel de disponibilidad se mide en %
5. Uptime Es una medida de tiempo en el que un sistema o equipo está disponible Comandos en Linux • uptime • top & htop • w • cat /proc/uptime
6. Uptime TIP: El Uptime se mide en días, horas y minutos Creative Commons Attribution-Share Alike 3.0 Unported - Neo139
7. Ejemplo 0 En un mes, un servidor se comportó de la siguiente forma. 1. Cada semana se reiniciaba, con 5 minutos de downtime. (20 minutos) 2. Falló una memoria causando 2 horas de downtime. 3. Se reemplazó un procesador quemado causando 1 hora de downtime. 4. El disco duro falló y tuvo que restablecerse todo el sistema causando 4 horas de downtime.
8. Ejemplo 0 ¿Qué nivel de disponibilidad ofrece ? a.- 90% b.- 97% c.-98% d.- 99% ¿Utilizarías ese servicio?
9. ¡¡¡¡ Todos queremos 100% !!!!
10. "La utopía está en el horizonte. Camino dos pasos, ella se aleja dos pasos. Camino diez pasos y el horizonte se corre diez pasos más allá. Por mucho que camine nunca la alcanzaré. ¿Entonces para qué sirve la utopía? Para eso, sirve para caminar". Fernando Birri / Eduardo Galeano
11. 999 The number of the beastie % Downtime Anual Downtime Mensual 90% (Un nueve) 36.5 días 72 horas 95% 18.25 días 36 horas 97% 10.96 días 21.6 horas 98% 7.30 días 14.4 horas 99% (dos nueves) 3.65 días 7.20 horas 99.95% 1.83 días 3.60 horas 99.8% 17.52 horas 86.23 minutos 99.9 (tres nueves) 8.76 horas 43.8 minutos
12. 999 The number of the beastie % Downtime Anual Downtime Mensual 99.95% 4.38 horas 21.56 minutos 99.99% (cuatro nueves) 52.56 minutos 4.38 minutos 99.995% 26.28 minutos 2.16 minutos 99.999% (cinco nueves) 5.96 minutos 25.9 segundos 99.9999% (seis nueves) 31.5 segundos 2.59 segundos 99.99999% (siete nueves) 3.15 segundos 262.97 milisegundos 99.999999% (ocho nueves) 315.5 milisegundos 26.297 milisegundos 99.9999999% (nueves nueves) 31.555 milisegundos 2.6297 milisegundos
13. ¡¡¡¡ Entonces, todos queremos 99.9999999% !!!!
14. ¿Para qué? Attribution-NonCommercial 2.0 Generic scottmontreal Attribution-ShareAlike 2.0 Generic Trammell Hudson V.S. ¿Hay vidas en riesgo ? ¿ o solo es un server para tu LAN Party?
15. ¿Vale la pena? ¿Cuanto te cuesta el downtime? ¿Cuanto te cuesta incrementar tu grado de disponibilidad? VS
16. Ejemplo 1 La empresa Patito Inc. genera ventas por $10,200 USD diarios en una jornada de 12 horas laborales. $10,200 / 12 hr = 850 USD/hr Sus costos operativos son de $250 USD/hr 1 hr de Downtime cuesta aprox $1,100 USD
17. Ejemplo La infraestructura de Patito Inc. les permite un grado de disponibilidad de 99% (7.20 hrs) Pérdida potencial = $7,920 USD Para incrementar a 99.9% podría instalarse un servidor de respaldo por $3,000 USD y un proveedor de Internet redundante por $500 USD mensuales.
18. Ejemplo 1 ¿Vale la pena? ¡Claro que sí!
19. Ejemplo 2 La infraestructura de Patito Inc. ahora les permite un grado de disponibilidad de 99.9% (43.8 min) Pérdida potencial = $803 USD Para incrementar a 99.99% podría instalarse un generador eléctrico de respaldo con un costo de $8,000 USD.
20. Ejemplo 2 ¿Vale la pena? Depende, 99.9% representan 8.76 hrs de riesgo potencial equivalentes a una pérdida potencial de $9,636. El retorno de inversión del generador es menor a 12 meses.
21. Ejemplo 3 La infraestructura de Patito Inc. ahora les permite un grado de disponibilidad de 99.99% (4.38 min) Pérdida potencial = $80.3 USD Para incrementar a 99.999% necesita duplicar su infraestructura en una locación remota con un costo inicial de $25,000 USD y un mantenimiento mensual de $3000 USD
22. Ejemplo 3 ¿Vale la pena? ¡¡¡Claro que no!!!
23. Otros Conceptos
24. MTBF MTBF (Mean Time Before Failures) utiliza para estimar el tiempo promedio que pasará antes de que una pieza de hardware falle. El fabricante lo calcula en base a pruebas de estrés realizadas a diferentes equipos y se calcula un promedio.
25. Ejemplo de MTBF en discos duros
26. MTTR El MTTR (Mean Time To Recovery) es el tiempo que estimado para re-establecer un sistema o equipo de una falla. TIP: El MTTR te ayuda a determinar un sistema amerita incrementar su tolerancia a los fallos
27. Ejemplo 4 La empresa Tortuga Island Inc. busca un servidor para un servicio NO crítico en su corporativo. Una hora de Downtime le genera un costo indirecto de $10 USD Un servidor con una controladora RAID 1 con 2 discos online y un spare le cuesta $1,300 USD. Un servidor sin discos redundantes le cuesta $550 USD. Comprar un nuevo disco duro le cuesta $70 USD y causa un MTTR de 5 horas. ¿Vale la pena la redundancia extra?
28. Ejemplo 5 Tortuga Island Inc. busca un servidor para un servicio NO crítico en una locación remota. Una hora de Downtime genera un costo indirecto de $10 USD Un servidor con una controladora RAID 1 con 2 discos online y un spare le cuesta $1,300 USD. Un servidor sin discos redundantes le cuesta $550 USD. Comprar un nuevo disco duro le cuesta $70 USD y causa un MTTR de 5 días y un viaje en auto de 12 horas generado gastos por $1500 USD. ¿Vale la pena la redundancia extra?
29. Alta Disponibilidad Alta Disponibilidad = Tolerancia a fallas mediante redundancia automática transparente.
30. En otras palabras Un sistema con replicación automática y la capacidad de failover
31. Factores Críticos 1. Monitoreo. 2. Red Interna. 3. Servicios Externos. 4. Ubicación y Entorno. 5. Respaldo (Sistema y Procesos). 6. Arquitectura de Redundancia. 7. Factor Humano.
32. Contratos de Servicios
33. SLA El SLA (Service Level Agreement) es un contrato que especifica las políticas de disponibilidad y atención para un servicio determinado. Se debe definir el alcance del proyecto, calidad y responsabilidades como: Tiempos de respuesta, tiempos de resolución, organigrama de escalación, grado de disponibilidad y penalización.
34. SLA 1. Es importante ser claro y conciso sin utilizar vocabulario técnico y debe incluir un glosario. 2. Definir periodos de tiempo concretos. 3. Definir requerimientos. 4. Definir alcance y responsabilidades de lado del cliente y de lado del proveedor de servicios.
35. Revisar Ejemplo de SLA
36. ¿Preguntas?
37. ANUNCIOS !
38. Próximos Eventos 19 de Junio Feria del Libro - Cultura Digital 19 de Septiembre Confirmada fecha para SFD 2015
39. ¡Muchas gracias! Grupo de de Usuarios de GNU/Linux de Tijuana ¡¡ A LOS TACOS !!