Skoro możesz, nie znaczy, że powinieneś...

Widzę, jak ta koncepcja pojawia się w dyskusjach dotyczących wirtualizacji przez cały czas. To szersze, bardziej ogólne zagadnienie, ale wirtualizacja jest “gorącą, nową technologią” stojącą przed wieloma organizacjami IT i wydaje się być przestrzenią, w której obecnie najczęściej obserwujemy problemy związane z zasadą “skoro możesz, nie znaczy, że powinieneś”, które podnoszą swoje brzydkie głowy. Jak ze wszystkim w IT, krytyczne jest umieszczenie wszystkich decyzji technicznych w kontekście biznesowym, abyśmy rozumieli, dlaczego wybieramy to, co wybieramy, i nie podejmowali decyzji w ciemno na podstawie popularnych metodologii wdrożeniowych lub, co gorsza, mitów.

Samą wirtualizację powinienem wskazać jako decyzję domyślną dla tych, którzy pracują w przestrzeni x64 z systemami wdrażanymi bez wirtualizacji tylko wtedy, gdy istnieje wyraźna i oczywista konieczność, na przykład specyficzne potrzeby sprzętowe, aplikacje wrażliwe na latencję itp. Pomijając konkretne potrzeby, wirtualizacja jest bezpłatna do wdrożenia u wielu dostawców i oferuje wiele korzyści zarówno dziś, jak i w zakresie zabezpieczenia środowiska na przyszłość.

Mając to na uwadze, to, co często widzę dziś, to firmy wdrażające wirtualizację nie jako najlepszą praktykę, ale jako panaceum na wszystkie postrzegane problemy IT. Z pewnością tak nie jest. Wirtualizacja jest bardzo ważnym narzędziem w zestawie narzędzi IT i jednym, po które będziemy sięgać bardzo często, ale nie rozwiązuje każdego problemu i powinna być traktowana jak każde inne narzędzie, które posiadamy, i używana tylko wtedy, gdy jest odpowiednia.

Widzę kilka rzeczy pojawiających się regularnie, gdy wirtualizacja staje się tematem dyskusji. Wiele firm przenosi się dziś ku wirtualizacji nie dlatego, że zidentyfikowały potrzebę biznesową, ale dlatego, że jest to aktualnie modny temat i ludzie czują, że jeśli nie wdrożą wirtualizacji, w jakiś sposób zostaną w tyle lub stracą dostęp do jakiejś mitycznej funkcjonalności. Generalnie jest to korzystne, ponieważ zwiększa adopcję wirtualizacji, ale jest złe, ponieważ pomijane są dobre procesy decyzyjne IT i biznesu. Co się często zdarza, to że w fali szumu wirtualizacyjnego działy IT czują, że muszą nie tylko wdrożyć samą wirtualizację, ale zrobić to w sposób, który może nie być odpowiedni dla ich firmy.

Są cztery rzeczy, które często widzę powiązane z wirtualizacją, często akceptowane jako wymagania wirtualizacji, niezależnie od tego, czy mają sens w danym środowisku biznesowym. Są to: konsolidacja serwerów, serwery blade, pamięć masowa SAN oraz wysoka dostępność lub live failover.

Konsolidacja jest tak często wychwalana jako korzyść wirtualizacji, że myślę, że większość działów IT zapomina, że istnieją inne ważne powody jej wdrażania. Jasne jest, że konsolidacja jest świetną korzyścią dla prawie wszystkich wdrożeń (wyniki mogą być różne, oczywiście) i prawie zawsze można ją osiągnąć po prostu poprzez lepsze wykorzystanie istniejących zasobów. Firma posiadająca więcej niż jeden serwer fizyczny, która nie może obciąć pewnych kosztów poprzez ograniczoną konsolidację, jest rzadkością i nierzadko zdarza się, że ślad datacenter jest znacznie redukowany w większych organizacjach.

W skrajnych przypadkach jednak nie jest konieczne porzucanie projektów wirtualizacji tylko dlatego, że konsolidacja okazuje się poza zasięgiem. Takie przypadki istnieją dla firm z systemami o wysokim wykorzystaniu i małym budżetem na prewencyjną inwestycję w konsolidację. Ale te firmy nadal mogą wirtualizować systemy “w miejscu” w stosunku jeden do jednego, aby uzyskać inne korzyści z wirtualizacji dziś i planować konsolidację, gdy sprzęt będzie wymagał wymiany jutro lub gdy większe, bardziej wydajne serwery staną się bardziej opłacalne w przyszłości. Ważne jest, aby nie wykluczać wirtualizacji tylko dlatego, że jej najbardziej chwalone zalety mogą nie mieć zastosowania w danym momencie w twoim środowisku.

Serwery blade są często postrzegane jako the wybór dla środowisk wirtualizacyjnych. Blade mogą lepiej sprawdzać się w standardowym środowisku wirtualizacyjnym niż przy bardziej tradycyjnych obciążeniach obliczeniowych, ale jest to zarówno bardzo dyskusyjne, jak i niekoniecznie istotne dane. To, że jest to dobry scenariusz dla samych blade, nie oznacza, że jest to dobry scenariusz dla biznesu. To, że blade działają lepiej niż normalnie w takim zastosowaniu, nie implikuje, że działają lepiej niż tradycyjne serwery – oznacza jedynie, że potencjalnie zmniejszyły dystans.

Serwery blade muszą być oceniane przy użyciu tych samych rygorystycznych kryteriów podczas wirtualizacji, jak i bez niej, i bardzo często nadal nie zapewniają długoterminowej wartości biznesowej potrzebnej do wybrania ich nad bardziej elastycznymi alternatywami. Blade nadal są dalekie od konieczności dla wirtualizacji i często, moim zdaniem, naprawdę złym wyborem.

Jednym z najczęstszych nieporozumień jest to, że przechodząc na wirtualizację, trzeba również przejść na pamięć masową dzieloną, taką jak SAN. Ten sposób myślenia jest oczywistą reakcją na chęć osiągnięcia innych korzyści z wirtualizacji, które, jeśli nie wymagają SAN, to znacznie na nim korzystają. Możliwość równoważenia obciążenia lub przełączania awaryjnego między systemami jest w dużej mierze ułatwiona przez posiadanie dzielonego backendu pamięci masowej. To mit, że jest to twarde wymaganie, ale replikowana pamięć lokalna ma swoje własne złożoności i ograniczenia.

Ale pamięć masowa dzielona jest daleka od konieczności samej wirtualizacji i, jak wszystko, musi być oceniana samodzielnie. Jeśli wirtualizacja ma sens dla twojego środowiska, ale nie potrzebujesz żadnych funkcji wymagających SAN, to zwirtualizuj bez pamięci masowej dzielonej. Istnieje wiele przypadków, gdy wirtualizacja oparta na pamięci lokalnej jest idealnym scenariuszem wdrożenia. Nie ma potrzeby odrzucać tego podejścia bez uprzedniego poważnego rozważenia.

Ostatnią ważną zakładaną konieczną funkcją wirtualizacji jest wysoka dostępność na poziomie systemu lub natychmiastowy failover dla systemu operacyjnego. Bez wątpienia wysoka dostępność na poziomie systemu jest fenomenalną korzyścią, którą wirtualizacja nam przynosi. Jednak niewiele firm potrzebowało wysokiej dostępności na tym poziomie przed wdrożeniem wirtualizacji, a cena niezbędnej infrastruktury i oprogramowania do jej realizacji z wirtualizacją jest często tak wysoka, że trudno ją uzasadnić.

Systemy o wysokiej dostępności są złożone i często nadmierne. Bardzo rzadkie są systemy biznesowe wymagające transparentnego przełączania awaryjnego nawet dla najbardziej krytycznych systemów, a firmy z takim wymaganiem prawie na pewno miałyby już procesy failover wdrożone. Widzę firmy dążące ku wysokiej dostępności przez cały czas, patrząc na wirtualizację, po prostu dlatego, że dostawca dostrzegł okazję do drastycznego przeszacowania pierwotnych wymagań. Koszt wysokiej dostępności jest rzadko uzasadniony potencjalną utratą przychodów z tytułu związanego zmniejszenia przestojów. Przy wirtualizacji bez wysokiej dostępności przestój spowodowany awarią urządzenia sprzętowego może być mierzony w minutach, jeśli kopie zapasowe są odpowiednio prowadzone. Oznacza to, że wysoka dostępność musi uzasadnić swój koszt poprzez potencjalne wyeliminowanie zaledwie kilku minut nieplanowanych przestojów rocznie, minus wszelkie dodatkowe ryzyko wynikające ze zwiększonej złożoności systemu. Nawet w największych organizacjach jest to rzadko uzasadnione na szeroką skalę, a w firmach o umiarkowanej wielkości jest to rzadkie zjawisko w ogóle. Ale dziś wiele małych firm wdraża systemy o wysokiej dostępności po ekstremalnych kosztach na systemach, które mogłyby z łatwością doświadczyć wielodniowych przestojów z minimalną stratą finansową, po prostu dlatego, że literatura marketingowa promowała tę koncepcję.

Jak wszystko, wirtualizacja i wszystkie związane z nią możliwości, które przynosi, muszą być oceniane indywidualnie w kontekście organizacji, która je rozważa. Jeśli indywidualna funkcja nie ma sensu dla twojego biznesu, nie zakładaj, że musisz ją kupić lub wdrożyć. Wiele organizacji wirtualizuje, ale korzysta tylko z kilku, jeśli w ogóle, z tych “zakładanych” funkcji. Nie patrz na wirtualizację jak na czarną skrzynkę, patrz na jej części i rozważaj je tak samo jak każdy inny projekt technologiczny.

To, co często zdarza się w efekcie kuli śnieżnej, to sytuacja, w której jedna funkcja, prawdopodobnie wysoka dostępność, jest zakładana za konieczną bez przeprowadzenia właściwej oceny biznesowej. Następnie dzielona pamięć masowa, często zakładana za wymaganą dla wysokiej dostępności, jest dodawana jako kolejny zakładany koszt. Nawet jeśli funkcje wysokiej dostępności nie zostaną zakupione, decyzja o użyciu SAN mogła już zostać podjęta i nie jest ponownie rozważana po dokonaniu zmian w planie. W mojej praktyce jest bardzo często spotykane, że w projektach tego rodzaju ponad pięćdziesiąt procent całkowitych wydatków na projekt jest przeznaczonych na produkty, których nabywca nie jest nawet w stanie opisać powodu zakupu.

Ta koncepcja nie ogranicza się do wirtualizacji. Rozciągnij ją na wszystko, co robisz. Zachowaj IT w perspektywie biznesu i nie zakładaj, że wybór jednej technologii automatycznie wymaga przyjęcia innych technologii, które są z nią popularnie kojarzone.