Jak działają narzędzia służące do doboru rozwiązań w chmurze publicznej?

[PiotrDrag]

Jak uniknąć problemów z niezawodnością takich systemów?

Jakiś czas temu ukazał się artykuł na temat zagrożeń związanych z przyjmowaniem pewnych rzeczy jako pewniki w przypadku wdrażania nowych technologii.

Tym razem chcę posłużyć się bardziej konkretnym przykładem zastosowania w przedsiębiorstwie, aby wyjaśnić, dlaczego klienci muszą być wyjątkowo ostrożni przy porównywaniu rozwiązań, zwłaszcza dla aplikacji kluczowych dla istnienia przedsiębiorstwa.

Czasami zbyt pobieżne analizowanie pewnych kwestii powoduje, że nie bierze się pod uwagę ryzyka wystąpienia pewnych mało prawdopodobnych problemów. Niewiedza nie jest błogosławieństwem... oznacza po prostu kłopotliwe niespodzianki.

Inaczej mówiąc: Unikaj chwytliwych ofert, które mogą Cię później zaskoczyć nieoczekiwanymi kosztami i problemami.

• Należy się upewnić, że wszystkie komponenty i funkcjonalności pozyskiwanego systemu odpowiadają Twoim potrzebom biznesowym.
• Im prostsza infrastruktura, tym bardziej niezawodna. Jeśli uzyskanie przyzwoitej wydajności wiąże się z koniecznością korzystania z bardzo dużej liczby zasobów (nawet w przypadku średniej wielkości rozwiązań), może to wskazywać na niedoskonałości takich rozwiązań.
• Należy zadbać o to, aby wszystkie elementy niezależnie od ceny były dostosowane do realizacji potrzeb kluczowych dla istnienia przedsiębiorstwa (mission critical). Na przykład, jaki poziom niezawodności gwarantują systemy do przechowywania danych, z których korzystasz? Czy jest to wystarczające w przypadku Twoich potrzeb?
• Upewnij się, że bierzesz pod uwagę odpowiednią liczbę środowisk (produkcyjnych i nieprodukcyjnych, pomnożoną przez liczbę aplikacji itp.). W przypadku niektórych aplikacji wartość ta może być naprawdę duża.

Rozwiązania SAP HANA

Rozwiązania SAP HANA można wykorzystywać na wiele sposobów. Kluczem jest łączenie certyfikowanych komponentów, które łącznie spełniają określone wymagania w zakresie wydajności (na przykład liczba węzłów HANA, jak przedstawiono w tym artykule) w ramach rozwiązania, zaspokajające potrzeby użytkownika końcowego dotyczące niezawodności i dostępności.

Możliwe jest więc połączenie certyfikowanego rozwiązania do przechowywania danych z wykorzystaniem podejścia TDI (Tailored Datacenter Integration, najbardziej elastyczne) lub postawienie na model oparty na urządzeniach, które obejmują dostarczenie kompletnego rozwiązania (najlepsze wyjście w przypadku naprawdę wysokich wymagań w zakresie wydajności). Z finansowego punktu widzenia oba rozwiązania można oczywiście zrealizować zarówno w formie zakupu inwestycyjnego (CAPEX), jaki i usługowego (OPEX).

Innym sposobem jest skorzystanie z oferty jednego z dostawców chmury publicznej, co wiąże się z wyborem jednej z certyfikowanych konfiguracji obliczeniowych (każda z nich oferuje inne możliwości łączenia procesorów/pamięci RAM), a następnie dołączenie do nich usług przechowujących dane.

Skoncentruję się na części dotyczącej przechowywania danych, ponieważ właśnie w tym obszarze widzę potrzebę zachowania nadzwyczajnej ostrożności.

Informacyjnie: Certyfikacja SAP HANA w zakresie wydajności

Podsystem przechowywania danych dostosowany do SAP HANA musi spełniać określone wskaźniki KPI (Key Performance Indicator)— na przykład opóźnienia w dostępie woluminów przechowujących dziennik zmian milisekundy oraz minimalna przepustowość na poziomie 400 MB/s dla wolumenu danych (co stanowi dość niską wartość w przypadku współczesnych systemów all-flash). Oczywiście, w zależności od ostatecznej specyfikacji rozwiązania, może być wymagany znacznie wyższy poziom wskaźników KPI (na przykład jeśli potrzebujesz dużych serwerów z 24 TB pamięci RAM, będziesz potrzebować znacznie wyższej przepustowości na jeden serwer, w przeciwnym razie uruchomienie bazy danych będzie trwało całą wieczność).

Trzeba to jeszcze pomnożyć przez liczbę potrzebnych węzłów.

Dostosowanie do przeznaczenia

W przypadku porównywania rozwiązań dla zastosowań produkcyjnych (zwłaszcza o kluczowym znaczeniu dla istnienia przedsiębiorstwa) oprócz wydajności należy uwzględnić kilka innych kwestii, które mogą mieć jeszcze większe znaczenie:

Bezprzestojowe działanie  i niezawodność (na przykład, odporność na uszkodzenia danych i awarie sprzętowe)

Rozwiązanie może posiadać certyfikat wydajności, niestety, certyfikacja nie uwzględnia zapewnienia niezawodności lub spójności danych. Są to kwestie, które klient końcowy musi szczegółowo przeanalizować we własnym zakresie, aby mieć pewność, że rozwiązanie spełni oczekiwania dla środowisku o kluczowym znaczeniu dla istnienia przedsiębiorstwa.

Porównanie skalowalności i złożoności w stosunku do ceny/wydajności

Co Twoim zdaniem jest prostsze i bardziej niezawodne:

1. Jeden niezwykle odporny wolumin osiągający bardzo wysokie poziomy wydajności bez większej złożoności lub
2. Wiele mniejszych woluminów, z których każdy cechuje się ograniczoną wydajnością i niższą niezawodnością, połączonych ze sobą za pomocą zarządzania przez woluminy logiczne (LVM stripping) w celu stworzenia większego systemu, który mimo wszystko w ostatecznym rozrachunku jest wolniejszy niż poprzedni przykład.

To jasne, że przykład nr 2 wiąże się z pewnymi problemami. Zarządzanie przez woluminy logiczne prowadzi do stworzenia mniej niezawodnego rozwiązania i zwiększa złożoność konfiguracji, utrudniając zarządzanie i utrzymanie.

Ryzyko w tym przypadku jest zwielokrotniane przez liczbę woluminów — jest to problem dotyczący każdej liczby woluminów, który sprowadza się do ograniczenia wydajności całej konfiguracji.

Wspominam o tym, ponieważ różne oferty wiążą się z poważnymi ograniczeniami między innymi w następujących obszarach:

• IOPS/GB
• Przepustowość na jeden wolumin
• Niezawodność woluminu
• Opóźnienie w dostępie do woluminu
• Bezprzestojowy czas pracy

Ograniczenia te mogą wywołać komplikacje i zwiększają ryzyko utrzymania ciągłości działania.

Przykład doboru rozwiązania w chmurze publicznej

Powiedzmy, że masz rozbudowane środowisko o kluczowym znaczeniu dla istnienia swojej firmy i musisz zapewnić dla niego przepustowość na poziomie 15 GB/s. Jednym z wymagań w zakresie przepustowości jest zapewnienie możliwości szybkiego uruchamiania dużych baz danych, a nie tylko zagwarantowanie normalnej wydajności podczas pracy. Duża baza danych bez wystarczającej przepustowości za każdym będzie się razem bardzo wolno uruchamiała.

• Bardziej przystępne cenowo oferty pewnych dostawców chmury publicznej wiążą się z maksymalnymi przepustowościami na poziomie kilkuset MB/s na wolumin, bezprzestojowy czas pracy na poziomie 3 dziewiątek, spójność danych na poziomie 3 dziewiątek(!) oraz czasy opóźnień w dostępie do danych przekraczające 1 ms. Aby osiągnąć docelowe wydajności, konieczne byłoby połączenie wielu takich urządzeń (co dodatkowo ograniczyłoby niezawodność), choć nadal nie dałoby się uzyskać przyzwoitych opóźnień w dostępie do danych lub spójności stosownej dla środowisk ”mission critical”.
• „Średnia” półka ich rozwiązań może być w stanie zapewnić przepustowość na poziomie około 1 GB/s na wolumin, jednak przy tak samo niskich wartościach opóźnień w dostępie do danych, bezprzestojowego czasu pracy i niezawodności, jak ich tańsze modele.
• Ich „wyszukane” rozwiązania mogą zapewnić przepustowość na poziomie 1 GB/s na wolumen, ponad 1 ms opóźnień, ale przynajmniej spójność danych plasuje się na poziomie 5 dziewiątek.
• Ich „najlepsza” oferta to najpewniej jedyne urządzenia osiągające opóźnienia poniżej milisekundy oraz przepustowość na poziomie ponad 1 GB/s na wolumin.

Zatem w tym przypadku z obciążeniem roboczym na poziomie 15 GB/s niezbędne byłoby wybranie „najlepszej” oferty, aby uzyskać właściwe poziomy opóźnień w dostępie do danych, niezawodności i przepustowości dla kluczowych obciążeń roboczych. Jakikolwiek inny wybór oznaczałby komplikacje, niskie osiągi i niższą niezawodność. Nadal niezbędne byłoby łączenie kilku „najlepszych” woluminów w wolumin logiczny, choć pewnie nie tak wielu, jak w przypadku innych opcji z ich oferty.

Jednak oczywiście rozwiązania z „najlepszej” oferty są zdecydowanie bardziej kosztowne, niż pozostałe... (jednocześnie pragnę podkreślić, że celowo nie podaję nazw ani odnośników do stron, aby zachować ogólny charakter opracowania. Dostrzegam te mankamenty w ofercie pewnego dużego dostawcy, jednak sama koncepcja i problemy dotyczą wszystkich firm dostarczających rozwiązania AaaS).

Porównanie ceny/wydajności/dopasowania do przeznaczenia rozwiązań HANA

W końcu dochodzimy do głównego powodu napisania tego artykułu.

Jak już wiemy w przypadku przepływów pracy o kluczowym znaczeniu dla funkcjonowania firmy wymagania spełnią jedynie najdroższe rozwiązania do przechowywania danych tego dostawcy chmury publicznej. Jest to fakt, który przyznają sami dostawcy, co zresztą jest uzasadnione i w pełni logiczne.

Oto haczyk:

Dostawcy chmury publicznej korzystają z narzędzi do wyceny w trybie online, które dostarczają jedynie przybliżony koszt.

Interesujące jest to, że w ich narzędziach do wyceny konfiguracji HANA instancje przygotowane dla potrzeb produkcyjnych domyślnie przypisywane są do kategorii najtańszych rozwiązań do przechowywania danych, co nie jest zalecane przez samego dostawcę chmury publicznej.

Nawet opcja „wyszukana” nie stanowiła oferty domyślnej (potrafię zrozumieć, że sensowne byłoby nie ustawiać oferty „najlepszej” jako domyślnej).

Zamiast tego narzędzie służące do doboru właściwego rozwiązania domyślnie podpowiadało najtańsze opcje, których zwykle używa się tak naprawdę tylko do celów testowych/rozwojowych.

Nie twierdzę, że dostawcy robią to celowo, aby wprowadzić kogoś w błąd, być może chodzi zwyczajnie o nieprawidłowe działanie narzędzia konfiguracyjnego, po prostu uważam, że trzeba przeprowadzić własną analizę i dokładnie sprawdzić zastosowane w konfiguracji rozwiązania komponenty, aby nie dać się omamić fałszywym poczuciem bezpieczeństwa.

W przeciwnym razie mogą zdarzyć się dwie rzeczy:

1. Nie uzyska się odpowiedniej wydajności lub niezawodności, co narazi Twoją firmę na ryzyko lub
2. Jakiś architekt wychwyci i skoryguje błąd, co znacznie zwiększy wycenę, być może prowadząc do znacznego przekroczenia budżetu. Zanim dojdzie do wychwycenia błędu, będzie już za późno na zmianę kursu.

Trzeba mieć pełną wiedzę o wszystkich opłatach (liczba systemów, opłaty za ruch wychodzący, zabezpieczanie danych)

Ilość systemów

Trzymając się przykładu SAP HANA, posiadanie wiedzy na temat odpowiedniej liczby wymaganych „wyszukanych” i „tańszych” systemów ma kluczowe znaczenie, ponieważ ma to olbrzymi wpływ na całkowity koszt. Aby uprościć to wszystko, gdy mówię o „systemach”, mam na myśli systemy HANA, ponieważ to właśnie one odpowiadają za wykorzystanie wielkich pojemności do przechowywania danych, mocy obliczeniowej i pamięci podręcznej. Potrzebne będą również serwery aplikacji.

Typowe wdrożenia SAP obejmują 2–3 aplikacje, takie jak BW, ECC, CRM, SCM itp.

Każda aplikacja SAP wymaga zwykle kilku systemów, obejmujących różne obszary:

• Produkcja
• Rozwój
• Zapewnienie jakości
• UA (w niektórych przypadkach traktowane łącznie z zapewnieniem jakości)
• DR (w niektórych przypadkach wykorzystuje się system UA/zapewnienia jakości w celu obniżenia kosztów)
• Piaskownica (sandbox)
• Szkolenie

Zwykle systemy produkcyjne, UA i zapewnienia jakości wymagają identycznej specyfikacji, dlatego potrzeba „wyszukanego” zaplecza pamięci masowej o znaczeniu „mission critical” dla przynajmniej 2 systemów (zakładając, że jeden wykorzystuje system trzyzadaniowy do zapewnienia jakości/UA/DR). Resztę rozwiązań może stanowić sprzęt o niższej specyfikacji, który jest tańszy.

Oznacza to, że na jedną aplikację potrzeba w przybliżeniu przynajmniej 3 systemów, z których przynajmniej 2 muszą być rozwiązaniami „wyszukanymi”. Teraz wystarczy pomnożyć to przez liczbę aplikacji, aby otrzymać całkiem niezłe oszacowanie potrzeb.

Jeśli chcemy zapewnienić odpowiedniej wydajności i osiągów, należy uwzględnić wszystkie te systemy.

Kopie zapasowe

Możliwość tworzenia kopii zapasowych to kolejny istotny czynnik. Przez ile miesięcy trzeba przechowywać kopie zapasowe? W jaki sposób się je przechowuje? Jak wydajne jest rozwiązanie do przechowywania? Jak szybko da się przywrócić działanie systemu? I ile to wszystko kosztuje?

Ruch wychodzący

Kilku dostawców chmury publicznej nalicza opłaty związane z kosztami ruchu wychodzącego danych (czyli ruch wychodzący danych z chmury publicznej do środowiska zewnętrznego jest związany z opłatą naliczaną za wykorzystanie).

Dalsze kroki i opcje do rozważenia

Jeśli wolisz korzystać z infrastruktury jako usługi, to super, ponieważ właśnie w tym kierunku zmierza cały przemysł.

Po prostu pamiętaj, aby dokładnie poznać możliwości wszystkich komponentów rozwiązania, z którego będziesz korzystać.

• Czy jest ono dostatecznie niezawodne?
• Czy jest ono dostatecznie odporne?
• Czy opóźnienia w dostępie do danych są odpowiednio niskie?
• Czy jego wydajność jest wystarczająca?
• Czy musisz dodatkowo zarządzać przez woluminy logiczne (LVM striping), co ogranicza prostotę i odporność całego rozwiązania?
• Co z tworzeniem kopii zapasowych?
• Co z opłatami za ruch wychodzący z sieci?

Na przykład oprócz całkowicie przygotowanych do pracy rozwiązań SAP firma HPE oferuje rozwiązanie GreenLake do blokowej pamięci masowej świadczonej jako usługa, które pozwala osiągnąć trwałą przepustowość (a nie chwilową na potrzeby prezentacji) na poziomie 55 GB/s w zaledwie 4U i które jest certyfikowane na utrzymanie nawet 120 węzłów SAP HANA, ze 100% gwarancją dostępności (bezprzestojowy czas pracy chmury publicznej jest zwykle gorszy od wartości 3 dziewiątek) oraz opóźnienia znacznie niższe niż 1 ms (w rzeczywistości 75% wszystkich operacji przesyłu danych jest realizowanych przy opóźnieniu poniżej 250 mikrosekund). Rozwiązanie idealnie dopasowane do środowisk o kluczowym znaczeniu dla istnienia firmy.

W rzeczywistości jedyne przypadki, w których zachodzi potrzeba zarządzania przez woluminy logiczne w takim rozwiązaniu, to konfiguracje urządzeń Leviathan HANA, które obejmują wykorzystanie różnych macierzy w celu osiągnięcia wręcz absurdalnych prędkości (na całym świecie wymaga tego zaledwie kilku klientów, jednak sama technologia jest już dostępna).

Ironia polega na tym, że oferta przechowywania danych o kluczowym znaczeniu dla istnienia firmy (mission critical) może okazać się znacznie tańsza niż wykorzystanie „najlepszych” rozwiązań dostawcy chmury publicznej, których przykład omówiliśmy wcześniej.

Nawet w przypadku mniejszych wdrożeń oferta rozwiązań HPE Business Critical zapewnia gwarancję dostępności do systemu na poziomie 6 „dziewiątek” i niesamowitą niezawodność (a przy tym możliwość bardzo dużych wdrożeń HANA obejmujących nawet 54 węzły w 4U).

Bez komplikacji związanych z zarzadzaniem przez woluminy logiczne (LVM striping) i z gwarancją łatwości wykorzystania oraz zarządzaniem z poziomu jednego panelu (lub interfejsów API, jeśli ktoś preferuje takie rozwiązanie).

UWAGA: sprawdź ten dokument, aby uzyskać najważniejsze informacje na temat HPE GreenLake dla rozwiązań SAP HANA.

Artykuł napisany na podstawie recoverymonkey.org: Beware of Cloud Sizing Tools and avoid Reliability Angst