Wirtualizacja nawet jednego serwera

Bardzo często spotykam się w rozmowach dotyczących wirtualizacji z tym, że konsolidacja – rozumiana w kontekście wirtualizacji serwerów jako umieszczenie wielu wcześniej fizycznych obciążeń na jednym fizycznym serwerze z separacją zapewnianą przez bariery maszyn wirtualnych – jest traktowana jako główna zasada i fundamentalna cecha wirtualizacji. Bez wątpienia konsolidacja obciążeń stanowi niesamowitą szansę w kontekście wirtualizacji, ale niezwykle ważne jest, aby wartości wirtualizacji i wartości konsolidacji nie mylić ze sobą. Zbyt często spotykam się z sytuacją, w której konsolidacja jest postrzegana jako kluczowa wartość wirtualizacji i jej podstawowe uzasadnienie, ale tak nie jest. Konsolidacja jest funkcją dodatkową, ale nigdy nie powinna być konieczna do uzasadnienia wirtualizacji. Wirtualizacja powinna być niemal oczywistym wyborem, podczas gdy konsolidacja musi być oceniana indywidualnie i wielokrotnie nie byłaby stosowana. To, że obciążenia nie mają być konsolidowane, nigdy nie powinno prowadzić do przekonania, że te obciążenia nie powinny być wirtualne. Chciałbym zbadać przestrzeń decyzyjną wirtualizacji, aby zobaczyć, jak powinniśmy na to patrzeć.

Wirtualizację należy rozumieć jako abstrakcję sprzętu, bo tym właśnie jest w praktycznym sensie. Wirtualizacja hermetyzuje sprzęt i prezentuje przewidywalny, nieskazitelny zestaw sprzętowy gościnnym systemom operacyjnym. Może to brzmieć jak dodawanie komplikacji, ale w rzeczywistości upraszcza wiele rzeczy – zarówno dla twórców systemów operacyjnych i sterowników, jak i dla specjalistów IT projektujących systemy. To właśnie dlatego, że komputery, peryferia komputerowe i systemy operacyjne są tak złożonymi bytami, ta dodatkowa warstwa w rzeczywistości usuwa złożoność z systemu, tworząc standardowe interfejsy. Ze standaryzacji rodzi się prostota.

Ta sama koncepcja prezentowania standardowej maszyny wirtualnej warstwie oprogramowania istnieje w innych obszarach informatyki, na przykład w sposobie implementacji wielu języków programowania. Jest to bardzo dojrzały i niezawodny model obliczeniowy.

Abstrakcja sprzętu i płynąca z niej stabilność same w sobie są wystarczającym powodem do standaryzacji wirtualizacji w całej infrastrukturze, ale praktyczna natura abstrakcji sprzętu, zaimplementowana przez wszystkie dostępne nam dziś enterprise produkty do wirtualizacji, przynosi nam jeszcze ważniejsze funkcje. Co prawda większość korzyści wirtualizacji można znaleźć w inny sposób, ale rzadko tak kompletnie, niezawodnie, prosto lub bezpłatnie jak w przypadku wirtualizacji.

Największy zestaw dodatkowych funkcji zazwyczaj pochodzi z abstrakcji storage i pamięci, umożliwiając robienie snapshotów storage lub nawet całego działającego stanu maszyny wirtualnej – czyli wykonanie obrazu działającego systemu i zapisanie go w pliku. Ta możliwość prowadzi do wielu bardzo ważnych funkcji, takich jak możliwość wykonania snapshota systemu przed instalacją nowego oprogramowania, zmianą konfiguracji lub patchowaniem, co pozwala na niezwykle szybkie cofanie zmian w razie problemów. Ta pozornie drobna funkcja może prowadzić do dużego spokoju ducha i ogólnej niezawodności systemu. Ułatwia też testowanie funkcji oraz cofanie lub wielokrotne testowanie w środowiskach nieprodukcyjnych.

Możliwość tworzenia snapshotów z warstwy abstrakcji prowadzi również do możliwości wykonywania “backupów opartych na obrazach”, czyli backupów wykonywanych za pomocą mechanizmu snapshotów na poziomie urządzenia blokowego, a nie z poziomu systemu plików systemu operacyjnego. Pozwala to na agnostyczne wobec systemu operacyjnego mechanizmy backupowania i backupy obejmujące cały pool storage systemu naraz. Backupy obrazów umożliwiają to, co tradycyjnie nazywano “przywracaniem na gołym metalu” – cały system może zostać przywrócony do pełnego stanu działającego bez dodatkowej interakcji – łatwo i bardzo szybko. Nie wszyscy producenci hypervisorów uwzględniają tę możliwość lub uwzględniają ją w równym stopniu, więc choć koncepcyjnie jest to główna funkcja, kluczowe jest, aby zakres, w jakim ta funkcja istnieje lub jest licencjonowana, był rozważany indywidualnie (w szczególności HyperV uwzględnia to w pełni, XenServer częściowo, a VMware vSphere tylko na poziomach licencji nieodpłatnych). Gdy jest dostępny, backup oparty na obrazach umożliwia niezwykle szybkie odtwarzanie w tempie nie do pomyślenia przy innych metodologiach backupu. Przywracanie systemów w ciągu minut jest możliwe – od katastrofy do odtworzenia!

Możliwość traktowania maszyn wirtualnych jak plików (przynajmniej gdy nie są aktywnie uruchomione) zapewnia dodatkowe korzyści związane z wymienionymi powyżej korzyściami backupu. Mianowicie możliwość szybkiej i łatwej migracji między fizycznymi hostami, a nawet przenoszenia między heterogenicznym sprzętem. Tradycyjnie modernizacje lub wymiana sprzętu oznaczały skomplikowany proces migracji pełen zagrożeń. Przy nowoczesnej wirtualizacji przejście z istniejącego sprzętu na nowy może być niezawodnym, niedestrukcyjnym procesem z bezpiecznymi opcjami powrotu i małymi, a może nawet zerowymi przestojami! Zadania, które były rzadkie, ale poprzednio bardzo ryzykowne, mogą często stać się trywialne.

Często jest to prawdziwa wartość wirtualizacji i mechanizmów abstrakcji. Nie chodzi koniecznie o poprawę codziennej eksploatacji systemu, ale o zmniejszenie ryzyka i zapewnienie elastyczności i opcji na przyszłość. Przygotowanie na nieznane, które są albo nieprzewidywalne, albo po prostu ignorowane w większości typowych sytuacji. Rzadko takie planowanie jest w ogóle prowadzone, ku utrapieniu działów IT pozostawionych z trudnymi i niebezpiecznymi modernizacjami, które można było łatwo złagodzić.

Istnieje wiele funkcji wirtualizacji mających zastosowanie tylko w specjalnych scenariuszach. Wiele produktów wirtualizacyjnych zawiera narzędzia do migracji na żywo do przenoszenia działających obciążeń między hostami, a może nawet między urządzeniami storage, bez przestojów. Opcje wysokiej dostępności i tolerancji błędów są często dostępne, pozwalając niektórym obciążeniom na szybkie lub nawet przezroczyste odtworzenie po awarii sprzętu systemowego – przeniesienie z wadliwego sprzętu na nadmiarowy bez interwencji użytkownika. Choć jest to bardziej niszowa korzyść i z pewnością nie powinna znaleźć się na liście powodów, dla których “niemal wszystkie obciążenia” powinny być wirtualne, warto ją wymienić jako główny przykład funkcji, które są często dostępne i mogą być dodane później, jeśli pojawi się taka potrzeba, pod warunkiem, że wirtualizacja jest stosowana od początku. W przeciwnym razie przed skorzystaniem z takich funkcji konieczna byłaby migracja do wirtualizacji.

Produkty wirtualizacyjne zazwyczaj zawierają rozbudowane dodatkowe funkcje istotne tylko w określonych przypadkach. Bardzo wiele z nich należy do dużej puli “na wypadek przyszłej potrzeby.” Prawdopodobnie największą ze wszystkich jest koncepcja konsolidacji, o której wspomniałem na początku tego artykułu. Podobnie jak inne zaawansowane funkcje, takie jak wysoka dostępność, konsolidacja nie jest podstawową wartością wirtualizacji, ale jest często z nią mylona. Obciążenia, które nie zamierzają korzystać z wysokiej dostępności lub konsolidacji, i tak powinny być wirtualizowane – bez wątpienia. Ale te funkcje są tak potencjalnie wartościowe jako przyszłe opcje, nawet w scenariuszach, w których nie będą dziś używane, że warto je wymienić niezależnie od tego.

Konsolidacja może być niezwykle wartościowa i łatwo zrozumieć, dlaczego tak wiele osób po prostu zakłada, że będzie stosowana, ponieważ jest tak często tak wartościowa. Dostępność tej możliwości po uruchomieniu infrastruktury jest kluczowym punktem elastyczności w obsłudze nieznanych przyszłych obciążeń. Nawet gdy konsolidacja jest dziś zupełnie niepotrzebna, istnieje bardzo duże prawdopodobieństwo, nawet w najmniejszych firmach, że będzie przydatna w jakimś nieznanym czasie w przyszłości. Wirtualizacja zapewnia nam zabezpieczenie przed nieznanym poprzez przygotowanie naszych systemów na maksymalną elastyczność. Jednym z najważniejszych aspektów każdej decyzji IT jest zarządzanie ryzykiem i jego redukcja. Wirtualizacja to umożliwia.

Wirtualizacja dotyczy stabilności, elastyczności, standaryzacji, zarządzalności i stosowania najlepszych praktyk. Żaden główny enterprise produkt do wirtualizacji nie jest dziś niedostępny, przynajmniej w jakiejś formie, bezpłatnie. Każdy zakup wymagałby oczywiście starannej analizy wartości w stosunku do wydatku. Jednak przy doskonałych opcjach enterprise dostępnych bezpłatnie od wszystkich czterech kluczowych linii produktów w tej przestrzeni (Xen, KVM, HyperV i VMware vSphere) nie musimy przeprowadzać takiej analizy. Musimy jedynie wykazać, że wdrożenie jest nieujemne.

To, co ułatwia podejmowanie decyzji, to fakt, że gdy rozważamy nominalny przypadek – absolutne minimum, które zapewnia cała enterprise wirtualizacja, czyli zerowy koszt, abstrakcję, hermetyzację i korzyści oparte na storage – stwierdzamy, że mamy małą korzyść praktycznie w każdym przypadku, brak mierzalnych wad i bardzo duży potencjalny zysk z obszarów elastyczności i zabezpieczenia przed przyszłymi potrzebami. Prowadzi to do wyraźnego zwycięstwa i prostej decyzji, że wirtualizacja, będąc bezpłatna i zasadniczo bez wad, powinna być stosowana we wszystkich przypadkach, w których jest to możliwe (co na tym etapie dotyczy niemal wszystkich obciążeń). Dodatkowe, niebazowe funkcje, takie jak konsolidacja i wysoka dostępność, powinny być oceniane oddzielnie i tylko po podjęciu decyzji o wirtualizacji. Brak potrzeby tych rozszerzonych funkcji w żaden sposób nie sugeruje, że wirtualizacja nie powinna być wybrana na podstawie własnych zalet.

Jest to po prostu wyjaśnienie istniejących branżowych najlepszych praktyk, którymi od wielu lat jest wirtualizacja wszystkich potencjalnych obciążeń. Nie jest to nic nowego ani zmiana kierunku. Sam fakt, że powszechna wirtualizacja jest branżową najlepszą praktyką od niemal dekady, pokazuje, jak sprawdzoną i akceptowaną metodologią ona jest. Zawsze będą istniały obciążenia, które z jednego lub drugiego powodu po prostu nie mogą być wirtualizowane, ale powinno ich być bardzo mało i powinny skłaniać do dogłębnego przeglądu, aby dowiedzieć się, dlaczego tak jest.

Przy podejmowaniu decyzji o wirtualizacji lub nie, podejście powinno zawsze zakładać, że wirtualizacja jest oczywistym wyborem i od tego należy odchodzić tylko wtedy, gdy solidny, uzasadniony techniczny powód sprawia, że jest to niemożliwe. Niemal wszystkie argumenty przeciwko wirtualizacji wynikają z pozycji niezrozumienia, z przekonaniem, że konsolidacja, wysoka dostępność, zewnętrzny storage, koszty licencji i inne luźno powiązane lub niepowiązane koncepcje są w jakiś sposób nieodłączne dla wirtualizacji. Nie są i nie powinny być uwzględniane w decyzji o wdrożeniu wirtualnym kontra fizycznym. Są to odrębne kwestie i powinny być oceniane jako odrębne opcje.

Warto zauważyć, że ponieważ konsolidacja nie jest częścią naszej macierzy decyzyjnej w tworzeniu podstawowej wartości wirtualizacji, wszystkie powody, których używamy, mają równe zastosowanie zarówno do wdrożeń jeden do jednego (czyli pojedynczej maszyny wirtualnej na pojedynczym urządzeniu fizycznym), jak i do skonsolidowanych obciążeń (czyli wielu maszyn wirtualnych na jednym urządzeniu fizycznym). Nie ma sytuacji, w której obciążenie jest “zbyt małe” do wirtualizacji. Jeśli cokolwiek, to wręcz odwrotnie – tylko największe obciążenia, zazwyczaj z ekstremalną wrażliwością na latencję, gdzie niszowy scenariusz braku wirtualizacji wciąż istnieje jako przypadek brzegowy – ale nawet te przypadki szybko znikają, ponieważ latencja w wirtualizacji i całkowite pojemności obciążeń są ulepszane. Przypadki te są tak rzadkie i tak szybko zanikają, że nawet wspominanie o nich jest prawdopodobnie niemądre, bo sugeruje, że wyjątki oparte na potrzebach pojemnościowych są na tyle powszechne, że warto je oceniać – a nie są, szczególnie nie na rynku SMB. Im mniejsze obciążenie, tym bardziej idealne do wirtualizacji, ale jest to jedynie potwierdzenie, że małe firmy z pojedynczymi obciążeniami są najbardziej idealnym przypadkiem do wszechstronnej wirtualizacji, a nie wyjątkiem od najlepszych praktyk, nie zaś sugestią, że większe firmy same powinny szukać wyjątków.