„Ten paragraf dwudziesty drugi to jest coś" – przyznaje niemalże z podziwem kapitan John Yossarian, grzęznąc w samym środku wojskowej biurokracji. „Bezbłędna rzecz", zgodził się doktor Daneeka. Specjaliści IT na całym świecie mają swój własny „paragraf 22" – to zaplanowane przestoje sieci, które stanowią twardy orzech do zgryzienia dla wielu organizacji działających 24 godziny na dobę, 7 dni w tygodniu. Zobaczmy, jak towarzyszący im impas decyzyjny przełamują rozwiązania Extreme!
Termin „paragraf 22” został ukuty przez Josepha Hellera, który stworzył go na potrzeby swojej powieści pod tym samym tytułem z 1961 roku, zekranizowanej niedawno przez HBO w formie telewizyjnego mini-serialu (nawiasem mówiąc, warto zapoznać się zarówno z oryginałem, jak i adaptacją!). Historia ta w satyryczny sposób przedstawia absurdy wojny oraz życia w wojsku, obserwując je oczami kapitana Johna Yossariana, bombardiera sił powietrznych armii amerykańskiej w czasie II wojny światowej. Główny bohater próbuje zachować zdrowy rozsądek, spełniając jednocześnie wymogi służby, dzięki czemu będzie mógł wrócić do domu i uciec od horroru wojny.
Przeszkodą w tym okazuje się wspomniany „paragraf 22”, o którym wspomina doktor Daneeka. Jak wyjaśnia wojskowy psychiatra, chcąc uniknąć udziału w niebezpiecznych misjach, każdy żołnierz, może wnioskować o natychmiastowe zakończenie służby z uwagi na chorobę psychiczną. Z drugiej strony ktoś, kto w trosce o ratowanie własnego życia wnosi o zwolnienie ze służby, udowadnia, że jest psychicznie zdrowy, a tym samym nie może prosić o zwolnienie z powodu choroby psychicznej.
Tak więc... ten paragraf 22 to faktycznie coś, prawda? Sam termin wszedł do mowy potocznej, opisując zagwozdkę lub sytuację wymykającą się logice, z której nie ma wyjścia z powodu wzajemnie sprzecznych lub zależnych od siebie warunków i ograniczeń. A to sprowadza nas do wspomnianych wcześniej przestojów sieci.
Cena… bezczynności
Spójrzmy prawdzie w oczy – nikt nie lubi przestojów. Szczególnie, kiedy zarządzasz setkami czy tysiącami urządzeń w dużym, wielodostępowym środowisku. Dla wielu organizacji proces wprowadzania zmian oznacza problem, który wykracza poza zwykłą biurokrację. Bo tak naprawdę nie chodzi o samą zmianę czy aktualizację. Chodzi o niekiedy ogromny koszt (i to niekoniecznie finansowy!) bezczynności, która towarzyszy przestojowi.
Aby utrzymać poprawne funkcjonowanie i bezpieczeństwo systemu, potrzebujemy przestoju w celu wprowadzenia niezbędnych zmian. Ale na przestój niekiedy nie możemy sobie pozwolić, ze względu na wymagania biznesowe lub operacyjne – zwłaszcza, gdy dana firma czy organizacja funkcjonuje 24 godziny na dobę, przez 7 dni w tygodniu. Doskonałym przykładem może być sektor opieki zdrowotnej, szczególnie w tych wyjątkowo trudnych czasach, które wystawiają nasze systemy na próbę.
Znajdujemy się więc w sytuacji, w której korzyści z wprowadzenia aktualizacji nie rekompensują lub tylko nieznacznie przewyższają koszty prac utrzymaniowych. Aby urzeczywistnić ideę „zerowych przestojów", organizacje wdrażają systemy działające w trybie stałej gotowości i dublują wysiłki w zakresie sprzętu i infrastruktury pomocniczej tylko po to, aby uniknąć przejścia systemu w tryb offline. Niestety, nie każdy może sobie na to pozwolić. Niektórzy po prostu godzą się z uwzględnieniem przestoju jako utraty produktywności.
Ale nie musi tak być. Bo po deszczu zza chmur zawsze wychodzi słońce. A w tym konkretnym przypadku, chmura ma akurat bardzo duże znaczenie!
Poruszać się z prędkością chmury
Podczas opracowywania, rozwijania i wdrażania ExtremeCloud™ IQ, pierwszej prawdziwej platformy 4. generacji na świecie, poczyniliśmy znaczące kroki w kierunku wyeliminowania przestojów związanych z pracami utrzymaniowymi. W tym celu wprowadzono nową metodę aktualizacji produkcji, dzięki której nie trzeba nigdy przełączać aplikacji w tryb offline! Jak to dokładnie działa?
ExtremeCloud™ IQ wykorzystuje dwa główne rodzaje systemów zarządzania bazami danych. Wszystkie nieustrukturyzowane dane, takie jak statystyki monitorowania, zdarzenia, alarmy czy dane dotyczące sztucznej inteligencji/uczenia maszynowego są przechowywane za pomocą Elastycznego Wyszukiwania (Elastic Search). W ten sposób przechowujemy dane wewnątrz indeksów, które mogą być w każdej chwili rozszerzane o nowe pola. Aplikacja nie będzie się przejmować tym, co robimy z indeksami Elastycznego Wyszukiwania, o ile niczego nie usuniemy.
Jednak w przypadku wszystkich ustrukturyzowanych danych, obejmujących takie elementy jak obiekty konfiguracyjne, informacje uwierzytelniające czy listy zarządzanych urządzeń, platforma wykorzystuje stare, dobre rozwiązania oparte na SQL. A przy schematach baz danych SQL musimy zachować pewną ostrożność. Dlatego też wraz z nadejściem chmury 4. generacji, zdecydowaliśmy się na nieco inne podejście.
"Po pierwsze, w ramach naszego certyfikatu ISO 27001 zgromadziliśmy setki stron dokumentacji operacyjnej i procesów, które wymagają od programistów udokumentowania proponowanych przez nich zmian schematów. Każda proponowana zmiana schematu dla konkretnego wydania jest weryfikowana przez kilka osób, w tym inżyniera odpowiedzialnego za operacje w chmurze. Żadna zmiana w obrębie bazy danych nigdy nie jest dokonywana bez wyraźnej weryfikacji i zatwierdzenia", podkreśla Bill Lundgren, Dyrektor ds. Zarządzania Produktem w zakresie Operacji w Chmurze i Architektury w Extreme Networks.
"Po drugie, zaprojektowaliśmy ExtremeCloud™ IQ tak, aby zapewnić kompatybilność w przód i wstecz. To naprawdę jest nie lada osiągnięcie. Każda linijka kodu w aplikacji, która wchodzi w interakcję z bazą danych, musi przewidywać, że może wejść w interakcję z nowym schematem i musi go sprawnie przetworzyć. Ponadto rzeczone bazy danych muszą być kompatybilne wstecznie, tak aby podczas procesu aktualizacji dotychczasowe aplikacje mogły nadal funkcjonować", dodaje. Zdaniem Billa Lundgrena, „jest to elegancki taniec z udziałem kodu, przetwarzania warunkowego oraz procesów operacyjnych, które łączą się, aby stworzyć sytuację zerowego przestoju”.
Jak dokonać aktualizacji bez przestojów?
Jak widać na poniższym wykresie, zaczynamy od lewej strony z ExtremeCloud™ IQ, przy zachowaniu normalnej pracy pomocniczych baz danych. W pierwszym kroku nasz zespół ds. operacji w chmurze wykonuje w pełni sprawdzone i zatwierdzone aktualizacje schematów do aktywnych baz danych, tworząc wersję "N+1”. W międzyczasie, wykorzystując przednią kompatybilność, którą wprowadziliśmy do aplikacji, starsza wersja ExtremeCloud™ IQ nadal działa przy użyciu nowego schematu bazy danych. Kompatybilność wsteczna nowego schematu baz danych "N+1" pozwala na odbieranie i przetwarzanie nowych transakcji z dotychczasowego formatu aplikacji.
Następnie dokonujemy aktualizacji samej aplikacji ExtremeCloud™ IQ. W chmurze 4. generacji, aktualizacja ta obejmuje uruchomienie oraz wymianę nowych kontenerów, które są zorkiestrowane przy pomocy infrastruktury Kubernetes. Możemy dokonać tego w zgrabny sposób, zastępując część działających podów, a następnie zawieszając aktywne połączenia do tych zaktualizowanych instancji. Następnie aktualizujemy pozostałe pody, tworząc aplikację w wersji "N+1", która będzie podłączona do nowego schematu obsługi bazy danych.
Na koniec, stosujemy procedury czyszczenia i porządkowania baz danych, aby ustanowić nowy standard zarówno dla aplikacji, jak i bazy danych.
Wyrwać się ze szponów paragrafu 22
Platforma ExtremeCloud™ IQ , zaprojektowana z myślą o usprawnieniu każdego aspektu sieci, od wdrożenia po utrzymanie, została opracowana z uwzględnieniem czynnika ludzkiego, dzięki czemu pomaga organizacjom i ich działom IT skoncentrować się na tym, co jest dla nich naprawdę ważne, zamiast zajmować się podrzędnymi i czasochłonnymi zadaniami operacyjnymi.
Bądź więc jak kapitan Yossarian. Skieruj swoją organizację w kierunku chmur i wyrwij się ze szponów paragrafu 22, jakim są zaplanowane przestoje sieci!
