W ramach cyklu poświęconego automatyzacji w IT stawiamy sobie za cel przybliżenie różnych aspektów tego zagadnienia we wszystkich możliwych obszarach infrastruktury i nie tylko. Dzisiaj kolej na warstwę mocy obliczeniowej, czyli rozwiązań serwerowych.
Przyzwyczailiśmy się już na dobre, że serwery najczęściej występują w postaci wirtualnej, szczególnie jeśli rozważamy rodzinę x86. Natychmiast na myśl przychodzą maszyny typu blade oraz hypervisor oparty o rozwiązania np. VMware, Microsoft lub inny. Oczywiście są wyjątki, szczególnie te, gdzie zwyczajowo, często bez konkretnego, merytorycznego powodu lub wnikliwej analizy stosujemy bare metal, czyli instancje systemów bazodanowych lub klastry Hadoop. Ponadto można zapominać, że obecne środowiska aplikacyjne bardzo często są heterogeniczne, a co za tym idzie, w praktyce będziemy musieli wyjść poza świat x86 w kierunku chociażby maszyn IBM Power, czy rzadziej SPARC. Wtedy projekt automatyzacji będzie musiał również uwzględniać współpracę z takimi platformami, a to sprowadza się do tego, że nie unikniemy bezpośredniej integracji z warstwą fizyczną systemów serwerowych.
Niezależnie zatem, czy w sposób automatyczny będziemy kreowali środowisko fizyczne dla platformy wirtualnej, będzie to element środowiska heterogenicznego czy też może po prostu wydzielona wyspa sprzętowa dla analiz BigData, potrzebna będzie komunikacja ze sprzętem. Tę zaś najlepiej pomoże nam zorganizować jego producent poprzez odpowiednie wtyczki (plug-in’s). Ich celem jest zapewnienie możliwie szerokiej komunikacji między narzędziem zarządzającym takim jak np. VMware vRealize Automation, Microsoft System Center, HP Cloud Service Automation czy wielu, wielu innych a platformą sprzętową. Jest to komunikacja bezpośrednia, np. za pomocą specjalnego interfejsu, który został zaszyty w platformę sprzętową i posiada własny adres, API, a nawet SDK. Ale może to być też oprogramowanie dziedzinowe, takie jak Hitachi UCP Advisor, HPE Synergy Image Streamer czy UCS Manager.
Realizacja praktyczna komunikacji platformy ze sprzętem
Warto w tym momencie zwrócić uwagę na dwa szczególne obszary funkcjonalne komunikacji platformy ze sprzętem. Umownie, na cele tego cyklu możemy posłużyć się określeniami: realizacja i monitoring. W pierwszym obszarze rozpatrujemy wszelką komunikację platformy zarządzającej w kierunku sprzętu mającą na celu realizację konkretnych zadań, jak np. powołanie do życia serwera o zadanym profilu czy konfiguracja ilości pamięci. Oczywiście wymiana informacji nie może być jednokierunkowa. Musi istnieć sprzężenie zwrotne, które przekaże stosowne komunikaty czy wywołana przez automatykę akcja zakończyła się powodzeniem, a jeśli nie to jakie mogą być tego przyczyny. To właśnie ten element jest kluczowy w procesie automatyzacji.
To, co oczywiste w świecie wirtualnym nie musi takie być w świecie fizycznym. Innymi słowy nie dajmy się zwieźć przyzwyczajeniu, że platforma wirtualizacji przeniesie naszą usługę na inny serwer i sprawa jest rozwiązana. Jeśli chcemy zbudować prawdziwie automatyczne centrum danych taką samą akcję musimy równie skutecznie przeprowadzić dla środowisk heterogenicznych, a nawet wyłącznie ze środowiskiem fizycznym.
Gdyby nie było sprzężenia zwrotnego i platforma wywołująca poszczególne procesy automatyczne nie otrzymałaby informacji o błędzie nie mogłaby stosownie zareagować mechanizmami naprawczymi. Wówczas cały proces zakończyłby się w najlepszym wypadku interwencją ludzką. Podobnie może się zdarzyć, kiedy mamy do czynienia z błędem wykonania po stronie sprzętu, ale nie zostały przewidziane procedury postępowania w określonych przypadkach. Procedury, które pozwoliłby platformie IT jako całości właściwie zareagować, automatycznie rozwiązać problem i dalej kontynuować pracę. Jeśli więc nie zadbamy o głęboką integrację i komunikację warstwy automatyzacji z warstwą sprzętu, możemy równie dobrze napisać kilka statycznych skryptów, a wtedy czar automatyzacji pryska i wszystkich korzyści jakie płyną z jej stosowania możemy schować między bajki.
Monitoring czyli informacje o kondycji zautomatyzowanej infrastruktury
Drugi przypadek komunikacji – odwrotnie niż pierwszy – inicjowany jest przez sprzęt, a dokładniej przez mechanizmy monitorujące jego prace. Naszpikowane różnymi czujnikami platformy sprzętowe mogą, a w przypadku zautomatyzowanego centrum danych muszą, przekazywać jak najwięcej informacji o własnej kondycji do warstw zarządzających. Najbardziej klasycznym przypadkiem jest tutaj komunikacja o błędzie czy awarii. W takim przypadku odpowiednie automaty na różnych warstwach zarządzających platformą są w stanie zadbać o zastąpienie uszkodzonego elementu infrastruktury fizycznej innym, zapasowym. Przypomnijmy, że to, co oczywiste w świecie wirtualnym, nie musi takie być w świecie fizycznym. Innymi słowy, nie dajmy się zwieźć przyzwyczajeniu, że platforma wirtualizacji przeniesie naszą usługę na inny serwer i sprawa jest rozwiązana.
Jeśli chcemy zbudować prawdziwie automatyczne centrum danych, taką samą akcję musimy równie skutecznie przeprowadzić dla środowisk heterogenicznych, a nawet wyłącznie ze środowiskiem fizycznym. To jednak nie wszystko. Dzisiaj oczekuje się nie tylko szybkiego usunięcia skutków awarii, ale jej przewidywania i zapobiegania. Dlatego dane, jakie generują platformy fizyczne za pomocą czujników są krytyczne dla rozwiązań automatyzujących po to, aby na ich podstawie – z użyciem metod statystycznych – przewidzieć awarię konkretnego komponentu i zawczasu przenieść krytyczne usługi w inne obszary.
Świetnym przykładem może tutaj być VMware vSphere Proactive HA – mechanizm, który już dzisiaj dostarcza możliwość integracji z platformą fizyczną tak głęboką, że DRS, na podstawie zwiększonej temperatury konkretnych procesorów – spowodowanej awarią kilku wentylatorów – sam przeniesie potencjalne zagrożone maszyny wirtualne w inne miejsce. Tylko co w przypadku, kiedy zarządzane środowisko jest choć w części fizyczne? Wtedy to już nie wirtualizacja, ale automatyzacja wkracza do akcji. Może zaś to zrobić tak dobrze, jak dobrze jest poinformowana o sytuacji. Stąd zakres komunikacji – którą tutaj nazwaliśmy monitoringową – jest tak bardzo istotny dla budowy środowisk bezobsługowych.
Wtyczki, wtyczki, wtyczki…
Mając zatem na uwadze te dwa główne obszary komunikacji czas wreszcie przyjrzeć się, co możemy uzyskać za pomocą dostarczanych przez producenta wtyczek. Wtyczek, które pozwolą nam oddać sterowanie w ręce automatu. W oczywisty sposób rozszerzenie, które zainstalujemy w platformie automatyzacji powinno pokrywać wszystkie – a przynajmniej znakomitą większość – funkcjonalności sprzętu. Bez wątpienia powinny tu się znaleźć mechanizmy włączania, wyłączania, restartu, montowania nośnika, zdalnej konsoli KVM i wszystkie inne realizujące codzienne działania administracyjne. Nie może także zabraknąć zarządzania profilami poszczególnych serwerów.
Dzisiaj oczekuje się nie tylko szybkiego usunięcia skutków awarii, ale jej przewidywania i zapobiegania. Dlatego dane, jakie generują platformy fizyczne za pomocą czujników są krytyczne dla rozwiązań automatyzujących po to, aby na ich podstawie – z użyciem metod statystycznych – przewidzieć awarię konkretnego komponentu i zawczasu przenieść krytyczne usługi w inne obszary.
Niezależnie jak nazwie swoją technologię dany producent istotne jest to, aby usługi IT budować w oderwaniu od konkretnych egzemplarzy sprzętu. Zespół cech od konfiguracji, poprzez logiczne nazewnictwo, po numery seryjne musi być zawarty w wirtualnym obiekcie, który można przypisać do dowolnego egzemplarza serwera. Między innymi dzięki temu, będzie można szybko uruchomić nową maszynę z tym samym numerem seryjnym uzyskując możliwość użycia tej samej instancji np. SAP, która pracowała na poprzednim egzemplarzu serwera. Takie operacje powinny być dostępne jako akcje standardowe dla warstwy automatyzacji. Nawet, kiedy stosujemy wirtualizację powinniśmy zadbać o wyżej opisany aspekt, czego przykładem może być zastosowanie np. vSphere Auto-Deploy. Oczywiście producent tego mechanizmu zadbał o to, aby mechanizm ten działał z dowolnym sprzętem z dość długiej tablicy kompatybilności. Ale – jak pokazuje praktyka – wiele organizacji nie stosuje tego dobrodziejstwa, gdyż jego konfiguracja zwykle wymaga czegoś więcej niż zaklinania paska postępu zakończonego przyciskiem „done”.
Gdyby jednak producent sprzętu w zakresie swojego rozwiązania dostarczył i utrzymywał odpowiednie profile sprzętu, pliki konfiguracyjne – a jeszcze lepiej gotowy appliance – chętnych zapewne byłoby znacznie więcej. Decyzja na wdrożenie automatyzacji poniekąd przekształca chęci w konieczność. Trudno byłoby sobie wyobrazić, że wszystkie akcje wykonywane są automatycznie i niemal błyskawicznie a instalacja warstwy wirtualizacji musi być wykonana ręcznie czy też półautomatycznie. Na koniec warto uwzględnić, czy i jakie wtyczki są darmowe, lub wliczone w cenę a za które trzeba będzie dodatkowo zapłacić.
Automatyczna platforma a reszta naszej infrastruktury IT
Jak już zaplanujemy odpowiednie integracje warstwy sprzętu z platformą automatyzacji usług pozostaje nam osadzić zautomatyzowany proces w środowisku całej organizacji. Należy zatem zadbać, aby powoływane do życia komponenty – ale też ich modyfikacje czy likwidacja – zasilały systemy informacyjne i audytorskie takie, jak choćby baza danych CMDB lub system SIEM. Ta część również musi zostać zrealizowana bezobsługowo, bo w przeciwnym zaprzeczy wszystkim korzyściom automatyzacji. W zakresie infrastruktury serwerów o sukcesie w tej materii również będzie decydował zestaw obsługiwanych integracji i komunikatów narzędzia dostarczonego przez producenta sprzętu.
Warto zwrócić uwagę na dwa szczególne obszary funkcjonalne komunikacji platformy ze sprzętem. Umownie możemy posłużyć się określeniami: realizacja i monitoring. W pierwszym obszarze rozpatrujemy wszelką komunikację platformy zarządzającej w kierunku sprzętu mającą na celu realizację konkretnych zadań, jak np. powołanie do życia serwera o zadanym profilu czy konfiguracja ilości pamięci. Oczywiście wymiana informacji nie może być jednokierunkowa. Musi istnieć sprzężenie zwrotne, które przekaże stosowne komunikaty czy wywołana przez automatykę akcja zakończyła się powodzeniem, a jeśli nie to jakie mogą być tego przyczyny. To właśnie ten element jest kluczowy w procesie automatyzacji.
Jak jest API (Advanced Programming Interface) to można wszystko, chociaż nie wszystko da się łatwo przeprowadzić. Nie można dać się zwieść, że można zrobić wszystko, choć to prawda, szczególnie dziś, kiedy światem IT rządzą aplikacje. Należy jednak pamiętać, że projekt automatyzacja to nie tylko wdrożenie, ale również utrzymanie i rozwój. Zatem o ile API może nam szybko rozwiązać problem braku jakiejś konkretnej funkcjonalności, to jednak pamiętajmy, że ktoś, kto ją napisze niekoniecznie będzie po wszech czas pracował w naszej organizacji. Taki dopisany kod będzie trzeba normalnie utrzymywać, rozwijać, dbać o zgodność wersji w ramach procesu Release Management, wpisać do rejestru ryzyka i tym podobne. Nie znaczy to oczywiście, że powinniśmy całkowicie rezygnować z zastosowania rozszerzeń API, jednak warto stosować je bardzo świadomie i w konkretnie wybranym zakresie.
Podsumowując, wybierając rozwiązanie zapewniające moc obliczeniową – w skrócie, po prostu serwery – sprawdźmy jaki obszary integracji zapewnia nam ich producent. Czy potrafi współpracować z planowaną warstwą automatyzacji, wirtualizacji, szyną danych, a – jeśli trzeba – kończąc na bazie konfiguracji i monitoringu. Idea jest taka, aby człowiek zajmował się przygotowaniem architektury, standardów i polityk. Natomiast realizacja prozaicznych czynności konfiguracyjnych powinna się odbywać automatycznie.
Daniel Wasyliszyn
Krzysztof Waszkiewicz
Architekci IT
Cykl poświęcony automatyzacji w IT rozpoczęliśmy w numerze ITwiz 3/2017 – Jak przeprowadzić projekt automatyzacji zarządzania IT. W następnej części przyjrzymy się przygotowaniom na automatyzację obszarom sieci i pamięciom masowym.
