Jak najlepiej wykorzystać odwróconą piramidę zagłady

Architektura 3-2-1, czyli Odwrócona Piramida Zagłady, stała się persona non grata w branży IT z wielu powodów. Niestety wiele firm dowiaduje się o zagrożeniach związanych z tym projektem dopiero po dostarczeniu komponentów i opróżnieniu kont bankowych.

Niektóre firmy mają szczęście i wychwytują ten błąd wystarczająco wcześnie, by móc zwrócić zakupy i zacząć od nowa z właściwym etapem projektowania i podejmowania decyzji przed nabyciem nowego sprzętu i oprogramowania. Jest to jednak sytuacja idealna i bardzo rzadka. W najlepszym razie możemy zwykle liczyć na opłaty za zwrot towaru, a znacznie częściej sprzętu w ogóle nie można zwrócić lub opłaty są na tyle wysokie, że cała operacja traci sens.

Większość firm staje przed koniecznością „jak najlepszego wykorzystania” zaistniałej sytuacji i pójścia naprzód. Jednym z największych problemów jest to, że zainteresowane strony – czy to finansowi interesariusze, którzy właśnie wydali dużo pieniędzy na nowy sprzęt, czy techniczni interesariusze, którym teraz jest wstyd za to, że dopuścili do zakupu tego sprzętu – mogą ulec emocjonalnej reakcji i poddać się błędowi utopionych kosztów. Kluczowe jest, aby tej emocjonalnej, nielogicznej reakcji nie pozwolić zapuścić korzeni, ponieważ podważy ona krytyczne podejmowanie decyzji.

Należy zrozumieć, że pieniądze wydane na odwróconą piramidę zagłady zostały już wydane i zniknęły. To, czy pieniądze zostały zmarnowane i ile zostało zmarnowanych, jest bez znaczenia dla podejmowania decyzji w tym momencie. Nieważne, czy system był prezentem, czy kosztował miliard dolarów – pieniądze przepadły i teraz musimy radzić sobie z tym, co mamy. Potencjalnym „trikiem” byłoby zaproszenie decydenta finansowego, takiego jak CFO, wyjaśnienie mu, że zaraz nastąpi emocjonalna reakcja na już wydane pieniądze, i omówienie błędu utopionych kosztów przed rozmową o właściwym problemie – aby wszyscy byli świadomi sytuacji i logicznie do niej podchodzili, a osoba przeszkolona (mamy nadzieję) do najlepszego radzenia sobie z tego rodzaju sytuacją była gotowa do opanowania emocji. Staranne zarządzanie potencjalnie emocjonalnie naładowaną reakcją jest ważne. To nie jest czas na próbę ukrycia zarówno finansowych, jak i technicznych potknięć – właśnie to tworzy emocjonalna reakcja. Wszystkie strony muszą komunikować się ze sobą i pozostawać zdystansowane oraz logiczne, aby zająć się potrzebami. Niektóre firmy radzą sobie z tym dobrze, wiele nie radzi sobie i utknęło, próbując brnąć naprzód ze złymi decyzjami, które już zostały podjęte, prawdopodobnie w nadziei, że nic złego się nie wydarzy i że nikt nie zapamięta ani nie zauważy. Walcz z tą reakcją. Każdy ją ma – to naturalna emocjonalna reakcja ciała migdałowatego „walcz lub uciekaj”.

Teraz, gdy jesteśmy gotowi walczyć z emocjonalnymi reakcjami na problem, możemy zacząć zastanawiać się nad tym, „gdzie idziemy dalej”. Dobra wiadomość jest taka, że nasza obecna pozycja to zazwyczaj posiadanie „za dużo” zamiast „za mało”. Mamy więc okazję do odrobiny kreatywności. Na szczęście istnieją zazwyczaj dobre opcje, które pozwalają nam ruszyć w kilku kierunkach.

Jedną z bardzo ważnych rzeczy do odnotowania jest to, że szukamy rozwiązań wyłącznie bardziej niezawodnych, a nie mniej niezawodnych, niż zamierzona architektura odwróconej piramidy zagłady, którą zastępujemy. IPOD to bardzo kruchy i niebezpieczny projekt i moglibyśmy poświęcić wiele czasu na demonstrowanie takich koncepcji jak analiza ryzyka, pojedyncze punkty awarii, błędy fałszowej redundancji, redundancja kontra niezawodność, łańcuchy zależności itp. – jednak tym, co jest absolutnie krytyczne dla wszystkich stron do zrozumienia, jest to, że pojedynczy serwer działający z lokalną pamięcią masową jest bardziej niezawodny niż cała infrastruktura IPOD. Jest to tak ważne, że trzeba to powtórzyć: jeśli pojedynczy serwer to „standardowa dostępność”, IPOD jest poniżej tego poziomu. Bardziej ryzykowny. Jeśli ktoś na tym etapie obawia się „braku redundancji” lub „braku złożoności” wynikowych rozwiązań, musimy wrócić do tego punktu – nic z tego, o czym będziemy rozmawiać, nie jest tak ryzykowne jak to, co zostało już zaprojektowane i zakupione. Jeśli istnieje jakiekolwiek obawy dotyczące ryzyka w przyszłości, obawy powinny być większe zanim poprawiliśmy niezawodność projektu. Tego nie można przecenić. IPOD-y sprzedają się, ponieważ łatwo mylą tych, którzy nie są przeszkoleni w analizie ryzyka, i wyglądają na niezawodne, gdy w rzeczywistości są zupełnym przeciwieństwem.

Zrozumienie powyższego i zastosowanie techniki „odczytywania wstecz” zaakceptowanej architektury IPOD mówi nam, że dana firma akceptowała brak wysokiej dostępności (a nawet standardowej dostępności) w momencie zakupu IPOD. Być może wierzyła, że ją otrzymuje, ale architektura nie mogła jej zapewnić – więc idąc dalej, mamy możliwość „radzenia sobie” z niczym więcej niż pojedynczym serwerem działającym z własną lokalną pamięcią masową. Jest to proste i łatwe rozwiązanie, które poprawia niemal każdy aspekt zamierzonego projektu IPOD. Kosztuje mniej w eksploatacji i utrzymaniu, jest często szybsze i znacznie mniej złożone, a przy tym jest nieco bardziej niezawodne.

Jednak samo zejście do pojedynczego serwera i znalezienie zastosowania dla reszty zakupionego sprzętu „gdzie indziej” prawdopodobnie nie będzie naszą najlepszą opcją. W sytuacjach, gdy IPOD miał być używany tylko dla jednego obciążenia lub zestawu obciążeń, a inne obszary firmy również potrzebują sprzętu, bardzo korzystne może być zastosowanie podejścia „pojed ynczego serwera” dla zamierzonego obciążenia IPOD i wykorzystanie pozostałego sprzętu gdzie indziej w firmie.

Najczęstszym podejściem do repurposingu stosu IPOD jest rekonfiguracja dwóch (lub więcej) węzłów obliczeniowych na węzły pełnego stosu zawierające własną pamięć masową. Ten krok może nie wymagać żadnych zakupów, w zależności od tego, jaka pamięć masowa została już zakupiona, przeniesienia dysków między systemami lub często stosunkowo niewielkiego zakupu dodatkowych dysków twardych w tym celu.

Te węzły można następnie skonfigurować w jeden z dwóch modeli wysokiej dostępności. W przeszłości popularnym wyborem projektowym, ze względów kosztowych, był model asynchronicznej replikacji (często znany jako podejście Veeam), który replikuje maszyny wirtualne między węzłami i pozwala na bardzo szybkie włączenie maszyn wirtualnych, umożliwiając czas przestoju od momentu awarii węzła obliczeniowego do odzyskania zaledwie kilku minut.

Dziś w pełni synchroniczna odporność na błędy jest dostępna tak powszechnie i bezpłatnie, że w praktyce zastąpiła model asynchroniczny w niemal wszystkich przypadkach. W tym modelu pamięć masowa jest replikowana w pełni w czasie rzeczywistym między węzłami obliczeniowymi, co umożliwia natychmiastowe przełączenie awaryjne zamiast kilkuminutowego opóźnienia, i to z zerową utratą danych zamiast małego okna utraty danych (np. RPO równe zero).

W tym miejscu wydaje się być powszechne, że ludzie reagują na replikację ze strachem przed utratą pojemności pamięci masowej spowodowaną replikacją. Oczywiście jest to prawda. Konieczne jest zrozumienie, że to właśnie ta replikacja, brakująca w oryginalnym projekcie IPOD, zapewnia solidny fundament wysokiej niezawodności. Jeśli ta replikacja zostanie pominięta, wysoka dostępność jest nieosiągalnym marzeniem, a poszczególne węzły obliczeniowe korzystające z lokalnej pamięci masowej w trybie „samodzielnym” są najbardziej niezawodną potencjalną opcją. Rozwiązania wysokiej dostępności polegają na replikacji i redundancji do budowania niezbędnej niezawodności wymaganej do zakwalifikowania się jako wysoka dostępność.

To rozwiązuje kwestię tego, co zrobić z naszymi węzłami obliczeniowymi, ale pozostawia nas z pytaniem, co możemy zrobić z naszym zewnętrznym współdzielonym urządzeniem pamięci masowej – pojedynczym punktem awarii lub „wierzchołkiem” projektu odwróconej piramidy. Aby odpowiedzieć na to pytanie, powinniśmy zacząć od przyjrzenia się, czym może być ta pamięć masowa.

Istnieją trzy powszechne typy urządzeń pamięci masowej, które byłyby używane w projekcie odwróconej piramidy: DAS, SAN i NAS. Możemy zgrupować DAS i SAN razem, ponieważ oba są dwoma różnymi aspektami blokowej pamięci masowej i mogą być używane zasadniczo zamiennie w naszej dyskusji – różnią się jedynie istnieniem przełączania, które można dodawać lub usuwać w razie potrzeby w naszych projektach. NAS różni się tym, że jest pamięcią masową plików, a nie bloków.

W obu przypadkach, zarówno blokowej (DAS lub SAN), jak i plikowej (NAS) pamięci masowej, jednym z najczęstszych zastosowań tego teraz zbędnego urządzenia jest użycie go jako celu kopii zapasowej dla naszej nowej infrastruktury wirtualizacji. W wielu przypadkach urządzenie może być przerostem formy nad treścią dla tego zadania – zazwyczaj z większą wydajnością i wieloma więcej funkcjami niż potrzeba dla prostego celu kopii zapasowej – ale dobra pamięć masowa do kopii zapasowych jest ważna dla każdej krytycznej infrastruktury biznesowej, a błąd w stronę nadmiaru nie jest koniecznie złą rzeczą. Firmy często próbują oszczędzać na swoich infrastrukturach kopii zapasowych i jest to okazja do zainwestowania w nie bez wydawania dodatkowych pieniędzy.

W podobnym duchu jak pamięć masowa kopii zapasowych, zewnętrzne urządzenie pamięci masowej mogłoby zostać repurposed jako archiwalna pamięć masowa lub inna „niższa warstwa” pamięci masowej, gdzie wysoka dostępność nie jest wymagana. Jest to mniej popularne podejście, generalnie dlatego, że każda firma potrzebuje dobrego systemu kopii zapasowych, ale tylko niektóre mają sposób na wykorzystanie archiwalnej warstwy pamięci masowej.

Poza tymi dwoma powszechnymi i uniwersalnymi modelami pamięci masowej, popularnym przypadkiem użycia dla zewnętrznych urządzeń pamięci masowej, szczególnie jeśli urządzenie jest NAS-em, jest jego użycie w natywnej roli serwera plików oddzielnego od infrastruktury wirtualizacji. Dla wielu firm obsługa plików nie jest tak krytyczna pod względem dostępności jak podstawowa infrastruktura wirtualizacji, a kopie zapasowe są znacznie łatwiejsze do utrzymania i zarządzania. Przenosząc obsługę plików na już zakupione urządzenie NAS, można zmniejszyć wymagania dotyczące obsługi plików z infrastruktury wirtualizacji zarówno przez zmniejszenie liczby maszyn wirtualnych, które muszą tam działać, jak i przez przeniesienie tego, co jest zwykle jednym z największych użytkowników pamięci masowej, na oddzielne urządzenie, co może obniżyć wymagania wydajnościowe infrastruktury wirtualizacji oraz jej wymagania dotyczące pojemności. Robiąc to, potencjalnie zmniejszamy koszt uzyskania niezbędnych dodatkowych dysków twardych dla lokalnej pamięci masowej w węzłach obliczeniowych, o czym powiedzieliśmy wcześniej – dlatego może to być bardzo popularną metodą dla wielu firm na zaspokojenie potrzeb repurposingu.

Każda firma jest wyjątkowa i potencjalnie istnieje wiele miejsc, gdzie zapasowy sprzęt do przechowywania danych mógłby być skutecznie wykorzystany – od laboratoriów po archiwa i wielowarstwową pamięć masową. Trochę kreatywności i myślenia poza schematami można wykorzystać do wzięcia unikalnego zestawu dostępnego sprzętu i unikalnego zestawu potrzeb i wymagań firmy oraz znalezienia najlepszego miejsca do użycia tego sprzętu, gdzie jest on odłączony od podstawowej, krytycznej infrastruktury wirtualizacji, ale nadal może przynosić wartość organizacji. Unikając odwróconej piramidy zagłady, możemy uzyskać maksymalną wartość ze sprzętu, w który już zainwestowaliśmy, zamiast wprowadzać nowy dług techniczny, z którym następnie musimy niepotrzebnie walczyć.