Wirtualne Jajka i Koszyki

W rozmowach ze specjalistami IT w małych firmach jednym z kluczowych czynników powodujących niechęć do wdrożenia wirtualizacji jest powiedzenie “nie wkładaj wszystkich jajek do jednego koszyka”.

Rozumiem, skąd bierze się ta obawa. Wirtualizacja pozwala na umieszczenie wielu gościnnych systemów operacyjnych w jednym fizycznym systemie, który w przypadku awarii sprzętu powoduje jednoczesną awarię wszystkich gościnnych systemów na nim rezydujących. Brzmi to groźnie, ale być może nie jest tak złe, jak mogłoby się na pierwszy rzut oka wydawać.

Idea powiedzenia o jajkach i koszykach polega na tym, że nie powinniśmy narażać wszystkich naszych zasobów jednocześnie na ryzyko. Zazwyczaj stosuje się ją do inwestowania, zachęcając inwestorów do dywersyfikacji i inwestowania w wiele różnych spółek i rodzajów papierów wartościowych, takich jak obligacje, akcje, fundusze i towary. W przypadku jajek (lub pieniędzy) mówimy o wymiennym towarze. Jedno jajko jest tak dobre jak drugie. Zestaw jajek jest z natury redundantny.

Jeśli mamy tuzin jajek i stłuczemy sześć, nadal możemy zrobić omlet – może mniejszy, ale nadal możemy zjeść. Jedzenie mniejszego omletu będzie prawdopodobnie niemal tak samo satysfakcjonujące jak większego – w żadnym przypadku nie zostaniemy głodni. Umieszczenie naszych i tak już redundantnych jajek w wielu koszykach pozwala nam zabezpieczyć się przed ryzykiem. Tak, niesienie dwóch koszyków oznacza, że mamy mniej czasu, by uważać na każdy z nich, więc zwiększa to ryzyko utratay niektórych jajek, ale zmniejsza szansę na utratę wszystkich jajek. W przypadku jajek – to mądra propozycja. Podobnie inteligentny sposób na przygotowanie się do emerytury.

Ta teoria, ponieważ jest powtarzana jako powiedzenie bez starannej analizy i właściwego zrozumienia, jest następnie stosowana do niepowiązanych obszarów, takich jak wirtualizacja serwerów. Serwery jednak nie są jak jajka. Serwery, szczególnie w mniejszych firmach, rzadko są wymiennymi towarami, gdzie posiadanie sześciu działających zamiast zwykłych dwunastu jest wystarczające. Zazwyczaj każdy serwer pełni unikalną rolę i wszystkie są stosunkowo krytyczne dla funkcjonowania firmy. Jeśli serwer nie jest krytyczny, to prawdopodobnie nie będzie w stanie uzasadnić kosztów nabycia i utrzymania, więc prawdopodobnie w ogóle by nie istniał. Gdy serwery są wymienne, na przykład w dużej, bezstanowej farmie webowej lub klastrze obliczeniowym, są one tak skonfigurowane jako środek rozszerzania pojemności poza granice jednego fizycznego pudełka i dlatego wykraczają poza zakres tej dyskusji.

Usługi IT w firmie są zazwyczaj, przynajmniej w pewnym stopniu, "zależnością łańcuchową". Tzn. są od siebie zależne i utrata jednej usługi może wpłynąć na inne usługi – albo dlatego, że są technicznie współzależne (np. aplikacja branżowa zależna od bazy danych), albo dlatego, że są zależne w ramach przepływu pracy (np. pracownik biurowy potrzebujący działającego serwera plików, aby udostępnić plik, który musi edytować z informacjami z e-maila, omawiając zmiany przez telefon lub komunikator). W takich przypadkach utrata jednej kluczowej usługi, takiej jak poczta e-mail, uwierzytelnianie sieciowe lub usługi plików, może spowodować nieproporcjonalnie duży spadek zdolności do pracy. Jeśli istnieje dziesięć kluczowych usług i jedna przestaje działać, wydajność firmy z perspektywy usług IT prawdopodobnie spada o znacznie więcej niż dziesięć procent, a w skrajnych przypadkach może zbliżać się do stu procent. Nie zawsze jest to prawdą – w niektórych wyjątkowych przypadkach pracownicy są w stanie skutecznie "obejść" brakującą usługę – ale jest to bardzo rzadkie. Nawet jeśli ludzie mogą kontynuować pracę, są prawdopodobnie znacznie mniej produktywni niż zwykle.

Przy fizycznych serwerach każdy serwer stanowi własny punkt awarii. Jeśli więc mamy dziesięć serwerów, mamy dziesięć razy większe prawdopodobieństwo awarii niż w przypadku jednego z tych samych serwerów. Każdy dodany serwer przynosi własne ryzyko. Jeśli każda awaria ma współczynnik przestoju 2,5 – tzn. finansowo wpływa na firmę na poziomie dwudziestu pięciu procent przychodów przez, powiedzmy, jeden dzień – to nasz łączny średni wpływ przez dekadę odpowiada dwóm i pół całkowitym przestojom całej witryny. Używam tu pojęcia współczynników i średnich, aby ułatwić zrozumienie; określenie długości lub wpływu przeciętnej awarii nie jest konieczne, ponieważ potrzebujemy jedynie określić relatywny wpływ w tym przypadku, aby porównać scenariusze. To tylko sposób na porównanie skumulowanego finansowego wpływu przestojów jednego rodzaju awarii z innymi, bez potrzeby posiadania konkretnych danych – nie pomoże Ci to określić, ile powinieneś wydać, tylko relatywną niezawodność.

Dzięki wirtualizacji mamy oczywistą możliwość konsolidacji. W tym przykładzie założymy, że możemy zredukować wszystkie te dziesięć istniejących serwerów do jednego serwera. Kiedy to robimy, często uruchamia się odpowiedź "wszystkie jajka w jednym koszyku". Ale jeśli przeprowadzimy analizę ryzyka, zobaczymy, że jest to zazwyczaj tylko strach i niepewność, a nie matematycznie uzasadnione ryzyko. Jeśli przyjmiemy to samo ryzyko co w powyższym przykładzie, nasz pojedynczy serwer będzie średnio ponosił tylko jeden całkowity przestój witryny raz na dekadę.

Porównajmy to z pierwszym przykładem, który spowodował szkody równoważne dwóm i pół całkowitym przestojom witryny – ryzyko zwirtualizowanego, skonsolidowanego rozwiązania stanowi tylko czterdzieści procent ryzyka tradycyjnego rozwiązania.

Pamiętajmy, że opiera się to na założeniu, że utrata niektórych usług oznacza stratę finansową większą niż ścisła wartość utraconej usługi, co prawie zawsze ma miejsce. Nawet jeśli utracona usługa jest nie więcej niż utratą indywidualnej usługi, jesteśmy co najwyżej na poziomie zrównania i nie musimy się martwić. W rzadkich przypadkach wpływ utraty jednego systemu może być mniejszy niż jego "udział w torcie", zazwyczaj dlatego, że ludzie są elastyczni i mogą obejść awarie systemu – na przykład jeśli komunikator przestaje działać i ludzie po prostu przechodzą na korzystanie z poczty e-mail, dopóki komunikator nie zostanie przywrócony – ale takie przypadki są rzadkie i zazwyczaj dotyczą kilku systemów spośród wielu, podczas gdy większość systemów, takich jak ERP, CRM i poczta e-mail, ma nieproporcjonalnie duże skutki w przypadku awarii.

Widzimy więc, że w normalnych okolicznościach przeniesienie dziesięciu usług z dziesięciu serwerów na dziesięć usług na jednym serwerze generalnie obniży nasze ryzyko, nie zwiększy go – w bezpośredniej sprzeczności z teorią "jajek w koszyku". I jest to czysto z perspektywy awarii sprzętu. Konsolidacja oferuje jednak kilka innych ważnych czynników niezawodności, które mogą mieć istotny wpływ na nasze studium przypadku.

Dzięki konsolidacji zmniejszamy ilość sprzętu, który musi być monitorowany i zarządzany przez dział IT. Mniejsza liczba serwerów oznacza, że więcej czasu i uwagi można poświęcić tym, które pozostają. Więcej uwagi oznacza większą szansę na wczesne wykrycie problemów i więcej możliwości, aby mieć pod ręką części zamienne. Lepszy monitoring i konserwacja prowadzą do lepszej niezawodności.

Prawdopodobnie najważniejszym czynnikiem jednak przy konsolidacji są znaczne oszczędności kosztowe i to, jeśli podejdziemy do tego prawidłowo, może zapewnić możliwości poprawy niezawodności. Przy dramatycznym zmniejszeniu całkowitego kosztu serwerów, może być kuszące utrzymanie napiętych budżetów i próba bezpośredniego wykorzystania oszczędności kosztowych. To zrozumiałe i dla niektórych firm może to być właściwe podejście. Ale nie jest to podejście, które bym polecał w walce z przekonaniem o jajkach i koszykach.

Zamiast tego, stosując bardziej umiarkowane podejście – zachowując znaczne oszczędności kosztowe, ale jednocześnie wydając relatywnie więcej na pojedynczy serwer – można nabyć serwer wyższej klasy (czytaj: bardziej niezawodny), użyć lepszych części, mieć na miejscu części zamienne itp. Oszczędności kosztowe wynikające z wirtualizacji można często bezpośrednio przekształcić w zwiększoną niezawodność, przesuwając równanie jeszcze bardziej na korzyść podejścia z jednym serwerem.

Jak wspomniałem w innym artykule, jeden murowany dom jest bardziej odporny na burzę niż jeden lub dwa słomiane domy. Posiadanie większej ilości czegoś niekoniecznie sprawia, że jest to bardziej niezawodny wybór.

Te korzyści wynikają czysto z aspektu konsolidacji wirtualizacji, a nie z samej wirtualizacji. Wirtualizacja zapewnia również osobne, rozszerzone funkcje ograniczania ryzyka. Tworzenie obrazów systemów i szybkie przywracanie, a także przywracanie do innego sprzętu, to główne zalety większości platform wirtualizacyjnych. Może to odgrywać ważną rolę w strategii odzyskiwania po awarii.

Oczywiście wszystkie te koncepcje służą wyłącznie do wykazania, że wirtualizacja na jednym urządzeniu i konsolidacja mogą pobić starsze podejście "jedna aplikacja na jeden serwer" i nadal zaoszczędzić pieniądze – pokazując, że przykład jajek i koszyków jest mylący i nie ma zastosowania w tym scenariuszu. Nie powinno być zatem oporów przed przejściem z tradycyjnego środowiska bezpośrednio do wirtualizowanego na podstawie tych czynników.

Należy zauważyć, że wirtualizacja może następnie rozszerzyć niezawodność tradycyjnego sprzętu towarowego, oferując funkcje failover podobne do mainframe'ów, które wykraczają poza to, co mogą zapewnić platformy bez wirtualizacji. Przybliża to sprzęt towarowy do większych, droższych platform RISC. Funkcje te mogą zapewnić ekstremalny poziom ochrony, ale często przekraczają to, co jest odpowiednie dla działów IT początkowo migrujących z niezwirtualizowanego, starszego środowiska serwerów sprzętowych. Wysoka dostępność to świetna funkcja, ale często jest kosztowna i bardzo często niepotrzebna, szczególnie gdy firmy przechodzą – jak widzieliśmy – ze stosunkowo zawodnych środowisk z przeszłości do bardziej niezawodnych środowisk dziś. Biorąc pod uwagę, że już zwiększyliśmy niezawodność ponad to, co uważano za konieczne w przeszłości, jest bardzo duże prawdopodobieństwo, że ekstremalny skok w niezawodności nie jest teraz potrzebny, ale ze względu na duży spadek kosztów wysokiej dostępności jest całkiem możliwe, że będzie to ekonomicznie uzasadnione tam, gdzie poprzednio nie mogło być.

W tym samym duchu, wirtualizacja jest często postrzegana z obawą, ponieważ jest uważana za nową, nieudowodnioną technologię. To z pewnością nieprawda, ale takie wrażenie istnieje w przestrzeni małych firm i serwerów towarowych. W rzeczywistości wirtualizacja została po raz pierwszy wprowadzona przez IBM w latach 60. i od tego czasu jest podstawą wysokiej klasy mainframe'ów i serwerów RISC – tych systemów wymagających najwyższej niezawodności. W przestrzeni serwerów towarowych wirtualizacja stanowiła większe wyzwanie techniczne i zajęło bardzo dużo czasu, zanim można było ją wdrożyć wystarczająco efektywnie, aby skutecznie używać jej w rzeczywistym świecie. Ale nawet w przestrzeni serwerów towarowych wirtualizacja jest dostępna od końca lat 90., więc ma dziś około piętnastu lat, co jest bardzo daleko od bycia rodzącą się technologią – w świecie IT jest wręcz czcigodna. Wirtualizacja platform towarowych to dojrzała dziedzina z kilkoma wysoce szanowanymi, niezwykle zaawansowanymi dostawcami i produktami. Używanie wirtualizacji jako standardu dla wszystkich lub niemal wszystkich zastosowań serwerowych jest od dawna ugruntowanym i akceptowanym "wzorcem korporacyjnym" i takim, który teraz można łatwo adoptować przez firmy dowolnej wielkości.

Wirtualizacja, być może wbrew intuicji, jest w rzeczywistości bardzo krytycznym składnikiem strategii niezawodności. Zamiast dodawać ryzyko, do wirtualizacji można podejść niemal jak do platformy ograniczania ryzyka – zestawu narzędzi do zwiększania niezawodności platform obliczeniowych poprzez wiele kanałów.