Przewodnik Po SLA W Chmurze (Czyli Co Się Dzieje Poniżej 99,95%)

SLA (Service Level Agreement) jest bardzo trudnym tematem. Jeżeli wierzysz, że możesz zapomnieć o swoim dziale architektury i zdać się na niezawodność dostawcy, to czytaj dalej…
Dziś przedstawię Ci wszystko o czym musisz wiedzieć, aby nie popełnić błędu przenosząc swoje aplikacje do chmury publicznej.
Przyjrzymy się dostawcom, którzy publicznie umieszczają swoje informacje o SLA w Internecie.
Skupimy się na sześciu:

• Amazon Web Services
• Microsoft Azure
• Google Cloud
• IBM SoftLayer
• E24Cloud
• Oktawave

Miej proszę na uwadze, że umowy SLA ciągle się zmieniają. Artykuł został opublikowany 28.04.2015. Przeczytaj więc dokładnie własną umowę.
Zastrzeżenie: Nie jestem prawnikiem i opieram się wyłącznie na danych znalezionych w oficjalnych zapisach na stronach dostawców. Jeżeli zauważysz błędy w moim zrozumieniu (często bełkotliwych) zapisów, to daj mi znać. Poprawie informacje w tym artykule.

Czym Jest SLA

SLA (Service Level Agreement) jest to umowa o gwarantowanym poziomie świadczenia usług. Dziś, dla ułatwienia, piszę o usłudzie Infrastructure As A Service (IaaS).
Używając prostych słów: Ustalasz z dostawcą przez jaki okres czasu Twoja usługa będzie działał wg. określonych założeń.
U większości dostawców założenia ograniczają się do dostępności Twojego serwera. Jednak, jak przeczytasz później, nie zawsze jest to takie proste.
Pomiar SLA odbywa się zazwyczaj w procentach. SLA na poziomie 99,99% mówi, że usługodawca może (ale nie musi) być niedostępnym przez 4 minuty i 38 sekund miesięcznie. Ogólnie jest to zależność pomiędzy czasem trwania usługi, zaplanowanymi przerwami oraz nieplanowanymi niedostępnościami.

Nie jest to jednak takie proste. Przyjrzyjmy się szczegółom.

Pomiar SLA u 6 Dostawców Chmury

Niezależnie jakiego dostawcę chmury wybrałeś, warto zwrócić w pierwszym kroku uwagę na cztery parametry:

1. Gwarancja Czasu Pracy Bez Przestoju – Słynne dziewiątki, czyli dostępność wirtualnej maszyny w przeciągu miesiąca. Większość dostawców oferuje usługę z zakresu 99,9% – 99,99%. Ale zdarzają się też wyjątki.
2. Cykl Pomiaru – Okres czasu, po którym można wnioskować o niedostępność usługi. Jeżeli dostawca mierzy to w cyklach miesięcznych, to po określonym miesiącu, zwracamy się do dostawcy po zwrot należnych nam benefitów.
3. Zwrot Kosztów – Po przekroczeniu Gwarantowanego Czasu Pracy Bez Przestoju, należy Ci się hajs. Kwota ta jest wyliczana różnie u różnych operatorów. Im mniejszy dostawca, tym zwroty są większe. U czołowych dostawców jest to max. 25-30% (z dużymi zastrzeżeniami).
4. Forma Zwrotu – Hajs może być zwrócony w różnych formach. Czasami jest to zwrot na kartę kredytową, czasami zwrot w formie kredytów na usługi. Tu mali gracze są bardziej elastyczni.

Amazon Web Services – EC2

• Gwarancja Czasu Pracy Bez Przestojów: 99,95%
• Cykl Pomiaru: Miesięczny
• Zwrot Kosztów: 10%-30%
• Forma Zwrotu: Kredyty Na Usługi

Microsoft Azure

• Gwarancja Czasu Pracy Bez Przestojów: 99,95%
• Cykl Pomiaru: Miesięczny
• Zwrot Kosztów: 10%-25%
• Forma Zwrotu: Kredyty Na Usługi

Google Cloud Engine

• Gwarancja Czasu Pracy Bez Przestojów: 99,95%
• Cykl Pomiaru: Miesięczny
• Zwrot Kosztów: 10%-50%
• Forma Zwrotu: Kredyty Na Usługi

IBM SoftLayer

• Gwarancja Czasu Pracy Bez Przestojów: 100%
• Cykl Pomiaru: 30 Minutowy
• Zwrot Kosztów: 5%
• Forma Zwrotu: Kredyty Na Usługi

e24cloud

• Gwarancja Czasu Pracy Bez Przestojów: 99,98%
• Cykl Pomiaru: Godzinowy
• Zwrot Kosztów: 200%
• Forma Zwrotu: Kredyty Na Usługi

Oktawave

• Gwarancja Czasu Pracy Bez Przestojów: 99,96%
• Cykl Pomiaru: Miesięczny
• Zwrot Kosztów: 100%
• Forma Zwrotu: Kredyty Na Usługi

Miej na uwadze, że musisz “udowodnić” dostawcy, że parametry SLA spadły poniżej umowy. Jest natomiast jeszcze kilka szczegółów, o czym za chwilę.

Jak Dostawcy Chmury Liczą SLA i Kiedy Dostaniesz Zwrot

Sposób liczenia SLA i forma wypłacania kredytów przy przekroczeniu SLA to skomplikowany temat i łatwo tu popełnić błąd.
Dostawcy używają standardowego wzoru do obliczenia dostępności usługi:

DOS – Dostępność
ROK – Rok Kalendarzowy
NIE – Nieplanowana niedostępność
TAK – Planowana niedostępność
Sprawdźmy jednak szczegóły, bo tu dopiero można znaleźć kilka ciekawych rzeczy.

Amazon Web Services – EC2

Amazon stosuje bardzo ciekawe zapisy SLA. Dostępność usług mierzona jest jako różnica pomiędzy 100% a procentem czasu w miesiącu, przez który REGION był niedostępny.
REGION składa się z więcej niż dwóch Availability Zones. Każda Availability Zone składa się z dwóch Data Centers. Tak więc, jeżeli posiadasz serwery rozrzucone po kilku Data Center w jednej Availability Zone i te Data Center wybuchną, dostępność z punktu widzenia zapisów SLA wynosi 100%.
Niedostępność określona jest wtedy, gdy instancja nie ma zewnętrznego połączenia (external connectivity). Dodatkowo warto zwrócić uwagę, że opłaty z góry nie są zwracane (użytkownicy instancji All Upfront Reserved są w trudniejszej sytuacji).
Należy się zgłosić z dowodami niedostępności do supportu. Po akceptacji otrzymasz zwrot za usługi, które nie były dostępne (10% lub 30% miesięcznego kosztu niedostępnych usług).
SLA jest określane dla maszyn mających dostęp do Internetu. Tu nie do końca jest wyjaśniona kwestia maszyn pracujących jako backend, bez potrzeby komunikacji z Internetem.
Warto też zwróić uwagę na wyłączenia, kiedy AWS nie ponosi odpowiedzialności. Z całej listy najciekawsze: Czynniki poza kontrolą AWS, błędy technologiczne firm trzecich oraz zaplanowane prace, o których poinformuje AWS.
Środowisko AWS jest budowane tak, że awaria jednej Availability Zone nie wpływała na drugą. Tak więc dopiero przy awarii całego regionu (mało opcji przy zapisach o czynnikach poza kontrolą AWS), możesz otrzymać max. 30% kosztów za swoje instancje EC2 i storage EBS.

Microsoft Azure

Jeden z bardziej przejrzystych dokumentów zagranicznych graczy (w tym po polsku). Do 60 dni od zakończenia miesiąca kalendarzowego należy się zgłosić do supportu z “dowodami”, które wskazuje Microsoft.
Microsoft (w porównaniu z konkurencją) dość rozsądnie określa wyłączenia z umowy, czyli sytuacje, które nie są brane pod uwagę przy liczeniu czasu niedostępność.
Microsoft (podobnie jak AWS) bardzo sprytnie używa sformułowania „Zestaw Dostępności”. Zestaw Dostępności oznacza co najmniej dwie Maszyny Wirtualne wdrożone w różnych Domenach Awaryjnych, aby uniknąć pojedynczego punktu, w którym może dojść do awarii. Posiadanie jednej lub więcej instancji wyłącznie w JEDNEJ Domenie Awaryjnej nie wpływa na zmianę czas Maksymalnie Dostępnych Minut, branych do wyliczenia czasu dostępności.
SLA jest określane dla maszyn mających dostęp do Internetu.

Google Cloud Engine

Do 30 dni od zakończenia awarii należy się zgłosić do supportu z “dowodami”, które wskazuje Google.
Czas przestoju w Google jest określany jako brak zewnętrznego połączenia albo brak dostępu do zasobów dyskowych dla instancji, które (podobnie jak AWS i Azure) są hostowane w więcej niż jednej Availability Zone. Dochodzi natomiast wyjątek: problem występuje tylko wtedy, gdy nie możemy odpalić zastępczej instancji w dowolnej Availability Zones.
W momencie awarii np. dwóch zon, posiadając mozliwość uruchomienia instancji w trzeciej zonie, nie traktujemy tego jako przestój.
Dodatkowo każdy przestój poniżej 5 minut nie jest liczony. Wykluczenia są rozsądne.

IBM SoftLayer

Do 7 dni od wystąpienia awarii należy się zgłosić do supportu z “dowodami”, które wskazuje IBM. IBM porówna Twoje dane i dowody z własnym monitoringiem i podejmie decyzje o wypłacie zwróceniu kredytów.
IBM SoftLayer ma bardzo ciekawe podejście do tematu SLA. Po pierwsze SLA podawane jest na poziomie 100%. Jeżeli usługa nie będzie dostępna przez 30 minut, to SoftLayer zwróci 5% za daną usługę za “Measurement Period”. Mimo SLA na poziomie 100%, awarie poniżej 30 minut nie będą liczone.
Ciekawie jest natomiast określona Utrata Usług (Loss of Services). Występuje wtedy gdy nie możemy połączyć się z usługą LUB portalem SoftLayer w dowolnym Data Center na całym świecie. Wynika z tego fakt, że jeżeli jest dostęp do portalu, a nie ma dostępu do usług, wszystko jest ok i nie jest naliczany czas związany z “Loss of Services”.
Warto też zwróić uwagę na wyłączenia, kiedy IBM SoftLayer nie ponosi odpowiedzialności. Z całej listy najciekawsze są prace IBM lub firm trzecich ogłoszonych 2 dni przed pracami. Warto więc zaglądać dość często do zakładki “Scheduled Maintenance” oraz obserwować maile.

e24cloud

Kwestia otrzymywania zwrotu nie jest jasno opisana. Do 30 dni od dnia usunięcia awarii należy się zgłosić do supportu. Po akceptacji otrzymasz zwrot. Będzie to 200% Twoich godzinowych kosztów za każdą rozpoczęta godzinę niedostępności.
Nie jest jasno określone od kiedy zaczyna się liczyć każda godzina. Zakładam, że przy 99,98% SLA, niedostępność dzienna to 17.3s. Tak więc przy naliczaniu godzinnym mamy niedostępność = 0,72s. Wynika z tego, że po przekroczeniu niedostępności 0,72s, należy nam się zwrot 200% za każdą godzinę.
Brakuje jednak kilku zdań o nieplanowanej niedostępności infrastruktury i opcjach pomiarowych.

Oktawave

Umowa SLA jest bardzo dokładna. Do 30 dni od zakończenia miesiąca kalendarzowego należy się zgłosić do supportu (dział reklamacji). Oktawave mierzy ze swojej strony dostępność usługi minimum co 10 minut. Awaria usługi liczona jest wtedy, gdy usług jest niedostępna przez więcej niż 15 minut. Tu ciekawa informacja. Nie jestem prawnikiem, ale jeżli dobrze rozumiem, to Oktawave jest w stanie zwrócić 100% kosztów instancji za cały miesiąc, jeżeli parametry SLA nie zostały zachowane.
Należy jednak zwrócić uwagę, że dostępność usługi jest mierzona raz na 10 minut, a Awaria to przypadek, w którym Usługa jest niedostępna z winy Usługodawcy przez więcej niż 15 następujących po sobie minut. Jest więc duża szansa, że wystąpienie Awarii zostanie zauważone przez systemy Oktawave po trzecim pomiarze, czyli po 30 minutach. Dodam tylko, że przy SLA 99,96% mówimy o 17m 31.9s niedostępności miesięcznie. Tak więc w najgorszym przypadku możemy dojść do 47 minut (poniżej 99,9% z punktu wiedzenia klienta) niedostępności miesięcznie bez naruszenia umowy SLA.
Warto też zwrócić uwagę na wyłączenia, kiedy Oktawave nie ponosi odpowiedzialności. Z całej listy najciekawsze są:

• Pożar
• Inne okoliczności zaburzające pracę Usługodawcy
• Opóźnienie w usługach świadczonych przez osoby trzecie
• Błędy oprogramowania dostarczanego przez osoby trzecie
• Ataki cybernetyczne

Niestety można pod to podciągnąć pod większość problemów występujących w Data Center.

Co Jeszcze?

Przenosząc swoje usługi do chmury, zwróć uwagę na kilka dodatkowych aspektów:

Pomiar Czasów Dostępności

Oprócz mechanizmów dostawcy warto:

• Obserwować wyniki CloudHarmony
• Podłączyć zewnętrzne narzędzie próbkujące, np. Pingdom
• Podłączyć wewnętrzny system monitoring, np. MRTG, PRTG
• Logować informacje z serwerów

SLA Usług Dodatkowych

Instancje to nie wszystko. Dostawcy oferujący przestrzeń dyskową, backup, firewall i inne usługi, określają SLA dla każdego z serwisów osobno. Sprawdzenie SLA dla dodatkowych usług jest konieczne.

Dostępność To Nie Wszystko

Jeżeli przechowujesz dane w chmurze, upewnij się jak dostawca pochodzi do tematu trwałości danych (durability). Cześć dostawców daje słynne jedenaście dziewiątek, część nie wspomina o tym w umowach SLA.

Dopasowanie SLA Do Wymagań W Twoim Przedsiębiorstwie

Nawet jeżeli dostawca oferuje SLA równe 99,95% na infrastrukturę, a wymogi w Twojej firmie na usługę biznesową to 99%, to nie spoczywaj na laurach.
Jak widać powyżej przy złej architekturze po Twojej stronie, część dostawców broni się przed karami. Dodatkowo miej na uwadze, że zwroty związane z przestojem pokrywają tylko małą część Twoich opłat za usługi IaaS. Jakby tego było mało, to pamiętaj, że po uruchomieniu maszyn musisz dodatkowo uruchomić aplikacje biznesowe. Jeżeli nie posiadasz systemów automatyzujących będziesz musiał ręcznie uruchamiać serwisy (a czas leci).

Negocjowanie SLA

Część mniejszych dostawców umożliwia negocjację warunków. Musisz odpowiedzieć na pytanie czy warto. Jeżeli tak, to zwróć uwagę na:

• Kto i jak mierzy czasy dostępności
• Kiedy i w jakiej formie zwracane są kary
• Po ilu minutach/godzinach niedostępność jest mierzona
• Czy jest dostęp do danych historycznych
• Czy dostawca potrafi wyjaśnić historyczne awarie
• Kiedy przewidziane są okna serwisowe
• Czy dostawca akceptuje pomiary dostępności z Twojej strony

Małpy W Data Center

Nie ma lepszej metody na zapewnienie SLA dla siebie, jak odpowiednia architektura odporna na awarie serwisu, serwera, całego Data Center. Jeżeli jesteś gotów, to wdróż Simian Army. Boisz się małp w Data Center, pomyśl jeszcze raz.

Podsumowanie

Plusy dla:

• Microsoft za zapis – “Microsoft powiadomi z 90-dniowym wyprzedzeniem o istotnych, niekorzystnych zmianach treści niniejszej Umowy SLA”. Pozostali dostawcy (część powiadamiając, część nie) może zmienić parametry SLA.
• e24cloud za 200% za rozpoczętą godzinę bez usługi i proste słowa
• Oktawave za 100% za miesiąc przy niedotrzymaniu SLA (są jednak ciężkie zapisy)

Chcąc zagwarantować sobie odpowiednie kary umowne, należy wybrać mniejszego dostawcę, który będzie w stanie negocjować zapisy SLA.
Im większy dostawca, tym możliwość otrzymania zwrotów za awarię jest mniejszy. To, że dostawca daje Ci SLA na poziomie 99%, 99,99%, 100% nie zmienia zbyt wiele dla Ciebie.
Należy projektować swoje rozwiązanie zakładając, że chmura (region) dostawcy może paść w dowolnym momencie. Takie architektury, wykorzystujące dwa regiony, dwie chmury lub rozwiązania hybrydowe w modelu active-active, działają w Polsce.
Tylko odpowiednia architektura jest w stanie zapewnić Ci odpowiednie czasy dostępności dla Twojego biznesu. Opieranie się na SLA dostawcy jest błędem. Warto to mieć na uwadze dobierając dostawcę chmury, a po zakupie usługi wziąć odpowiedzialność za dostępność na siebie.