Jak obliczyć złożoną umowę o gwarantowanym poziomie usług (SLA) dla usług w chmurze?

Usługi w chmurze w serwisie Amazon Web Services , Azure , Google i większość innych publikuje S erwis L Evel A greement lub SLA dla poszczególnych usług, które świadczą. Architekci, inżynierowie platform i programiści są następnie odpowiedzialni za połączenie ich w celu stworzenia architektury zapewniającej hosting aplikacji.

W oderwaniu, usługi te zazwyczaj zapewniają coś w zakresie od trzech do czterech dziewięciu dostępności:

• Azure Traffic Manager: 99,99% lub „cztery dziewiątki”.
• SQL Azure: 99,99% lub „cztery dziewiątki”.
• Usługa Azure App Service: 99,95% lub „trzy dziewięć pięć”.

Jednak w połączeniu ze sobą w architekturze istnieje możliwość, że dowolny komponent może ulec awarii, powodując ogólną dostępność, która nie jest równa usługom składowym.

Dostępność związku szeregowego

W tym przykładzie istnieją trzy możliwe tryby awarii:

• SQL Azure nie działa
• Usługa aplikacji jest wyłączona
• Oba są wyłączone

Dlatego ogólna dostępność tego „systemu” musi być niższa niż 99,95%. Moim uzasadnieniem dla takiego myślenia jest to, że umowa SLA dla obu usług była następująca:

Usługa będzie dostępna 23 godziny na dobę

Następnie:

• Usługa aplikacji może być niedostępna między 0100 a 0200
• Baza danych od 0500 do 0600

Obie części są objęte umową SLA, ale cały system był niedostępny przez 2 godziny z 24.

Dostępność szeregowa i równoległa

W tej architekturze istnieje wiele trybów awarii, ale przede wszystkim:

• Serwer SQL w regionie A jest wyłączony
• Serwer SQL w regionie B jest wyłączony
• Usługa aplikacji w regionie A nie działa
• Usługa aplikacji w regionie B nie działa
• Menedżer ruchu jest wyłączony
• Kombinacje powyżej

Ponieważ Traffic Manager jest wyłącznikiem, jest w stanie wykryć awarię w obu regionach i kierować ruch do regionu roboczego, jednak nadal występuje jeden punkt awarii w postaci Traffic Manager, więc całkowita dostępność „systemu” nie może być wyższy niż 99,99%.

W jaki sposób można obliczyć i udokumentować złożoną dostępność dwóch powyższych systemów dla firmy, potencjalnie wymagając ponownej analizy, jeśli firma chce wyższego poziomu usług niż jest w stanie zapewnić architektura?

Jeśli chcesz adnotować diagramy, wbudowałem je w Lucid Chart i stworzyłem link wielokrotnego użytku, pamiętaj, że każdy może to edytować, więc możesz utworzyć kopię stron do adnotacji.

Uznałbym to za problem matematyczny, ponieważ w umowie SLA istnieje prawdopodobieństwo, że wszystko będzie OK.

W takim przypadku możemy polegać na regułach prawdopodobieństwa, aby uzyskać wynik ogólny.

W pierwszym przypadku prawdopodobieństwo, że usługa App Service (A) i Sql Service (B) spadną w tym samym czasie, jest iloczynem ich prawdopodobieństwa:

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

Prawdopodobieństwo, że jeden z nich spadnie, jest sumą ich prawdopodobieństwa:

P(A)+P(B) = 0.001

Gdy dwa zdarzenia są niezależne, wynikowa formuła, która bierze pod uwagę prawdopodobieństwo, że oba będą wyłączone, jest następująca:

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

Tak więc ogólna umowa SLA byłaby 1 - 0,00099975 = 0,99900025procentowa99.900025 %

Uproszczenie jest produktem pierwszej prawdopodobieństwa: 0.9995 * 0.9995 = 0,99900025.

W przypadku przerwy 1h / 24h (4,166666% dziennie) daje to (miejsca dziesiętne są skracane):

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

Prawdopodobieństwo bycia OK jest więc wyrażone 1 - 0.0816 = 0.9184procentowo:91,84%

24 * 0.0816 = 1.95 h

To mniej niż najgorszy przypadek 2 godzin, ponieważ istnieje szansa, że ​​obie są jednocześnie.

Mając to na uwadze, możesz zauważyć dostępność każdego z nich, 95,84%a 0,958333333 * 0,958333333 = 0,918402778to jest nasze 91.84%z góry (przepraszam za pełne miejsca po przecinku tutaj, ale są one potrzebne do demonstracji)

Teraz w drugim przypadku zaczniemy korzystać z naszego złożonego prawdopodobieństwa dla każdego regionu (przepraszam, odrzuciłem zmianę SQL, aby zachować rozsądność), zakładając, że nie ma niezależnego prawdopodobieństwa dla samego regionu i że każdy region jest izolowany i jako taki awaria DB powoduje obniżenie tylko regionu.

Mamy prawdopodobieństwo OK menedżera ruchu P(T) = 0.9999i każda aplikacja + DB łączy się z prawdopodobieństwem OK P(G) = 0,99900025od

Ile regionu mamy do odegrania, ponieważ musimy zastosować iloczyn prawdopodobieństwa awarii tylko po to, aby uzyskać prawdopodobieństwo, że oba regiony spadną w tym samym czasie:
0,00099975 * 0,00099975 = 0,0000009995000625co oznacza ogólną dostępność co najmniej jednego regionu99,049375 %

Teraz mamy ogólną dostępność regionów, produkt z menedżerem ruchu daje nam ogólną dostępność systemu:

0.9999 * 0,9999990004999375 = 0,99989900059988750625

Ogólna dostępność wynosi 99.989900 %

Inne źródło jako wyjaśnienie jest dostępne w dokumentacji Azure (link dzięki uprzejmości Raj Rao )

Po przeczytaniu doskonałej odpowiedzi Tensibai zdałem sobie sprawę, że kiedyś mogłem to obliczyć dla celów analizy sieci. Wykopałem moją kopię High Availability Network Fundamentals autorstwa Chrisa Oggerino i miałem problem z wypracowaniem tego, nie całkiem pierwszymi zleceniodawcami.

Wzięcie mojego seryjnego przykładu bezpośrednio z odpowiedzi Tensibai jest po prostu pomnożeniem prawdopodobieństwa, że ​​każdy komponent będzie dostępny przez drugi:

Więc

99,95% * 99,95% = 99,9%

Obliczanie go równolegle jest nieco bardziej skomplikowane, ponieważ musimy zastanowić się, jaki będzie procent braku dostępności:

Obliczenia wykonuje się w następujący sposób:

1. Pomnóż dostępność un dwóch regionów razem.

   0,1% * 0,1% = 0,0001%

2. Przekształć to z powrotem w dostępność

   100% - 0,0001% = 99,9999%

3. Pomnóż dostępność Traffic Manager przez dostępność dwóch regionów.

   99,99% * 99,9999% = 99,9899%

4. Rezultatem jest dostępność całego systemu.

   99,9899% jest zbliżone do 99,99%

Skończyłem używać Excela do wykonywania obliczeń, oto wartości:

... i formuły ...