¿Cómo se calcula el Acuerdo de Nivel de Servicio (SLA) compuesto para servicios en la nube?

Los servicios alojados en las nubes por Amazon Web Services , Azure , Google y la mayoría de los demás publican el S ervicio L evel A CUERDO , o SLA, para los servicios individuales que proporcionan. Los arquitectos, los ingenieros de plataforma y los desarrolladores son responsables de reunirlos para crear una arquitectura que proporcione el alojamiento para una aplicación.

Tomados de forma aislada, estos servicios generalmente proporcionan algo en el rango de tres a cuatro nueve de disponibilidad:

Azure Traffic Manager: 99.99% o 'cuatro nueves'.
SQL Azure: 99.99% o 'cuatro nueves'.
Servicio de aplicaciones de Azure: 99.95% o 'tres nueve cinco'.

Sin embargo, cuando se combinan en arquitecturas, existe la posibilidad de que cualquier componente pueda sufrir una interrupción que resulte en una disponibilidad general que no sea igual a la de los servicios del componente.

Disponibilidad de compuesto en serie

En este ejemplo, hay tres modos de falla posibles:

SQL Azure está caído
El servicio de aplicaciones está inactivo
Ambos están abajo

Por lo tanto, la disponibilidad general de este "sistema" debe ser inferior al 99.95%. Mi razonamiento para pensar esto es si el SLA para ambos servicios fue:

El servicio estará disponible a partir de las 24 horas.

Luego:

El Servicio de aplicaciones podría estar fuera entre las 0100 y las 0200
La base de datos salió entre las 05:00 y las 06:00.

Ambos componentes están dentro de su SLA pero el sistema total no estuvo disponible durante 2 horas de 24.

Disponibilidad en serie y paralela

En esta arquitectura hay una gran cantidad de modos de falla, sin embargo principalmente:

SQL Server en la Región A está inactivo
SQL Server en la Región B está inactivo
El servicio de aplicaciones en la Región A está inactivo
El servicio de aplicaciones en la Región B está inactivo
Traffic Manager está caído
Combinaciones de arriba

Debido a que Traffic Manager es un interruptor automático, es capaz de detectar una interrupción en cualquier región y enrutar el tráfico a la región de trabajo, sin embargo, todavía hay un solo punto de falla en la forma de Traffic Manager, por lo que la disponibilidad total del "sistema" no puede Ser superior al 99,99%.

¿Cómo se puede calcular y documentar la disponibilidad compuesta de los dos sistemas anteriores para la empresa, lo que posiblemente requiera una nueva arquitectura si la empresa desea un nivel de servicio superior al que la arquitectura es capaz de proporcionar?

Si desea anotar los diagramas, los he creado en Lucid Chart y he creado un enlace de usos múltiples, tenga en cuenta que cualquiera puede editar esto, por lo que es posible que desee crear una copia de las páginas para anotar.

— Richard Slater
fuente

¿El SLA más bajo de SPOF, suponiendo que su aplicación pueda hacer frente a la interrupción de la sesión?

— Tensibai

@Tensibai: no creo que pueda serlo, basándome en mi primer ejemplo, si el SLA para ambos servicios estuviera disponible en 23 horas de 24, el Servicio de aplicaciones podría estar fuera entre las 0100 y las 0200 y la Base de datos fuera entre 0500 y 0600, ambos componentes están dentro de su SLA pero el sistema total no estuvo disponible durante 2 horas de 24. ¿Tiene sentido?

— Richard Slater

Sí, tiene sentido, pero en este caso el resultado debería ser el producto de todo no?

— Tensibai

Me refiero a que la aplicación 99.95 x sql 99.95 debería ser la disponibilidad general del grupo

— Tensibai

Tenga en cuenta también que puede construir un sistema que sea más confiable que sus componentes, mediante reintentos o failovers o degradación en lugar de una falla total.

— Xiong Chiamiov

Respuestas:

Tomaría eso como un problema matemático con el SLA como la probabilidad de estar bien.

En este caso, podemos confiar en las reglas de probabilidad para obtener un resultado general.

Para su primer caso, la probabilidad de que el Servicio de aplicaciones (A) y el Servicio SQL (B) estén inactivos al mismo tiempo es el producto de su probabilidad:

P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025

La probabilidad de que uno de ellos esté abajo es la suma de su probabilidad:

P(A)+P(B) = 0.001

Cuando dos eventos son independientes, la fórmula resultante para tener en cuenta la probabilidad de que ambos caigan es:

P(A,B) = P(A) + P(B) - P(A)*P(B) = 0.001 - 0,00000025 = 0,00099975

Entonces, el SLA general sería el 1 - 0,00099975 = 0,99900025porcentaje99.900025 %

Una simplificación es el producto de la primera probabilidad: 0.9995 * 0.9995 = 0,99900025.

Aplicado a su interrupción de 1h / 24h (4,166666% de un día) esto da (los decimales se abrevian):

0.0416 + 0.0416 - (0.0416 * 0.0416) = 0,081597222

Entonces la probabilidad de estar bien es 1 - 0.0816 = 0.9184en porcentaje:91,84%

24 * 0.0816 = 1.95 h

Esto es menos que el peor de los casos de 2 horas porque existe la posibilidad de que ambos estén caídos al mismo tiempo.

Teniendo esto en cuenta, puede notar la disponibilidad para cada uno 95,84%y 0,958333333 * 0,958333333 = 0,918402778cuál es nuestro 91.84%desde arriba (perdón por los decimales completos aquí, pero son necesarios para la demostración)

Ahora, para su segundo caso, comenzaremos a ganar de nuestra probabilidad compuesta para cada región (lo siento, descarté el cambio para que SQL lo mantenga razonable), suponiendo que no haya una probabilidad independiente para la región en sí y que cada región esté aislada y como tal un fallo de la base de datos solo derriba su región.

Tenemos la probabilidad OK del administrador de tráfico P(T) = 0.9999y cada aplicación + DB se junta con una probabilidad OK P(G) = 0,99900025de

Cuánta región tenemos que desempeñar, ya que tenemos que aplicar el producto de la probabilidad de falla solo para obtener la probabilidad de que ambas regiones estén inactivas al mismo tiempo: lo
0,00099975 * 0,00099975 = 0,0000009995000625que significa una disponibilidad general de al menos una región de99,049375 %

Ahora tenemos la disponibilidad general de regiones, el producto con el administrador de tráfico nos da la disponibilidad general del sistema:

0.9999 * 0,9999990004999375 = 0,99989900059988750625

La disponibilidad general es 99.989900 %

Otra fuente como explicación está disponible en los documentos de Azure (enlace cortesía de Raj Rao )

— Tensibai
fuente

La disponibilidad general parece muy baja; de hecho, al agregar una región adicional y un administrador de tráfico, el SLA es un orden de magnitud menor que si se tratara de una sola región. Estoy tratando de investigar cómo solía hacer esto para las redes desde el fondo de mi cerebro.

— Richard Slater

¡Uf! Estaba seguro de que me estaba volviendo loco.

— Richard Slater

Matemáticas de @RichardSlater corregidas

— Tensibai

@BruceBecker probablemente sí, ya que ciertamente parece que el IEEE ha publicado una investigación sobre el tema, sospecho que sin embargo, dado el propósito de calcular estos números, se trata más de tener una "prueba" concreta de que necesita o no capacidades de alta disponibilidad agregado a un sistema, es decir, usamos estos números para impulsar decisiones de costo-beneficio basadas en el apetito de riesgo de las empresas. La construcción de un modelo bayesiano puede no representar el mejor uso de nuestro tiempo.

— Richard Slater

@BruceBecker Sí, parte del problema está vinculado (el mismo centro de datos se está desactivando y ambos servicios están dentro, lo que debe ser bajo), por lo demás, creo que podemos asumir con seguridad que los servicios de aplicaciones y los servicios sql se ejecutan en diferentes sistemas y es poco probable que fallar al mismo tiempo por la misma razón . Avanzar en las matemáticas requeriría una documentación precisa sobre cómo se realiza la arquitectura de Azure y, por lo tanto, solo puede ser respondida por alguien de Microsoft.

— Tensibai

Después de leer la excelente respuesta de Tensibai , me di cuenta de que solía poder calcular esto para fines de análisis de red. Saqué mi copia de los Fundamentos de la red de alta disponibilidad de Chris Oggerino y tuve problemas para resolver esto, no del todo los primeros directores.

Tomar mi ejemplo en serie directamente de la respuesta de Tensibai es simplemente un caso de multiplicar la probabilidad de que cada componente esté disponible por el otro:

Asi que

99.95% * 99.95% = 99.9%

Cálculo en paralelo es un poco más complicado como lo hacemos necesidad de considerar cuál es el porcentaje de la ONU será la disponibilidad:

El cálculo se realiza de la siguiente manera:

Multiplicar la ONU disponibilidad de las dos regiones juntas.

0.1% * 0.1% = 0.0001%
Convertir eso de nuevo a disponibilidad

100% - 0.0001% = 99.9999%
Multiplique la disponibilidad de Traffic Manager por la disponibilidad de las dos regiones.

99.99% * 99.9999% = 99.9899%
El resultado es la disponibilidad total del sistema.

99.9899% está cerca de 99.99%

Terminé usando Excel para realizar los cálculos, aquí están los valores:

... y las fórmulas ...

— Richard Slater
fuente

Eso es todo, de una manera más directa que la mía (sentí la necesidad de demostrar las matemáticas detrás :))

— Tensibai

De acuerdo, su respuesta es realmente buena para las matemáticas.

— Richard Slater

SQL Azure es 99.99% no 99.95%

— Jeffery Tang

@JefferyTang (probablemente) estaba en el momento de escribir preguntas / respuestas (no recuerdo exactamente) y el valor real no cambia la metodología para obtener la respuesta a "Cómo calcular el SLA compuesto de las partes individuales SLA" que Es la verdadera pregunta.

— Tensibai