Rozmawiając o bezpieczeństwie systemów informatycznych najczęściej aspekt bezpieczeństwa fizycznego czy sprzętowego schodzi na plan dalszy. Całkiem niesłusznie – straty wywołane przez awarię zasilania – nawet gdy posiadamy plan odtwarzania po awarii mogą być znaczące.
Na liście najbardziej popularnych awarii w naszym kraju na pewno na jednym z czołowych miejsc (zwłaszcza poza obszarami wielkomiejskimi) plasuje się utrata zasilania. Teoretycznie, nie ma o czym dyskutować – oczywistym jest fakt, że każdy system zawierający cenne dane powinien być przed skutkami takiej awarii zabezpieczony. Jednak rzeczywistość jest (a jakże!) inna. Z własnych obserwacji wiem, że zasilanie awaryjne to ostatni element infrastruktury o jakim myślimy, i często jego zakup planowany jest w momencie, kiedy budżet jest już wydrenowany.
Tymczasem prawda jest taka, że zasilanie awaryjne powinno być filarem niezawodności naszej infrastruktury.
Zastanówmy się jakich cech powinniśmy oczekiwać od systemów zasilania bezprzerwowego, patrząc z perspektywy administratora lub wdrożeniowca. Zastanawiając się nad zestawem takich uniwersalnych właściwości doszedłem do następujących wniosków, że oprócz oczywistych parametrów związanych z jakością wykonania i gwarantowanymi parametrami pracy – od systemów zasilania bezprzerwowego oczekuję szerokich możliwości zarządzania i monitoringu. Zarówno dostępnych dla pojedynczego urządzenia, jak i w przypadku, gdy posiadamy bardziej rozbudowane środowisko, wyposażone w kilkanaście urządzeń UPS i wiele urządzeń przezeń zabezpieczanych.
Ważnym wyznacznikiem jakości nowoczesnych rozwiązań jest możliwość pracy zarówno w środowiskach zwirtualizowanych, jak i w środowiskach fizycznych. Oczywiście oczekiwałbym, że jedno i to samo urządzenie może zabezpieczać jednocześnie hosta wirtualnego, jak i serwer z niezwirtualizowanym systemem.
Oczekiwałbym również, że obydwa urządzenia będę mógł monitorować z pomocą jednej konsoli a wdrożenie tego rozwiązania nie będzie wymagało zanurzenia się na dwa tygodnie w dokumentacji.
Ideałem byłoby jeszcze gdyby system zarządzania który otrzymujemy od Producenta urządzeń umożliwiał zarządzanie zarówno najmniejszymi urządzeniami, których nie możemy wyposażyć w karty sieciowe, jak i tymi, które są w takie karty wyposażone.
Tak właśnie widzi zarządzenie swoimi produktami firma Cyber Power.
Na szczycie mamy PowerPanel Center – centralny system zbierania i prezentacji danych. System ten posiada możliwość zbierania danych i współpracy z różnymi urządzeniami związanymi z zasilaniem awaryjnym, takimi jak: UPSy, PDU, ATS oraz samymi końcówkami klienckimi, serwerami fizycznymi, hostami wirtualnymi i samymi maszynami wirtualnymi.
Następnym poziomem jest Power Panel Client. Power Panel Client komunikuje się z Agentami i stanowi w moim odczuciu najmocniejszy filar systemu. To dzięki niemu i jego możliwościom konfiguracyjnym możemy kształtować konfigurację zasilania awaryjnego w niemalże dowolny sposób.
Jak wspomniałem, Client komunikuje się i zarządza pracą Agentów. W roli agenta może występować zarządzana karta sieciowa UPS, samo urządzenie lub wirtualny appliance, który pełni rolę interfejsu dla urządzenia nie posiadającego karty sieciowej (na przykład UPS wyposażony jedynie w złącze USB).
Wspomniałem, że agent dostępny jest w postaci wirtualnego appliance. Oczywiście pozostałe elementy systemu również są dostępne w kilku postaciach.
Architektura systemu Power Panel
Klienta oraz agentów możemy wdrożyć jako maszynę wirtualną, działającą na hypervisorze – CyberPower dostarcza przygotowane templatki OVF zawierające malutką maszynę opartą na CentOS. Alternatywą jest zainstalowanie wersji dedykowanej dla konkretnego systemu, co możemy zrobić zarówno w systemach fizycznych, jak i zwirtualizowanych. Do wyboru mamy wersje dla Windows, Linux oraz Mac.
Maszynki są naprawdę malutkie i podczas „czuwania” konsumują niewielkie zasoby:
Zrzut ekranu pokazujący Zużycie zasobów przez PowerPanel Agent
We wsparciu środowisk wirtualnych można zauważyć brak wsparcia dla środowiska Xen. Nie oznacza to, że jest ono całkowicie niewspierane, a jedynie fakt, że chcąc monitorować takie środowisko zmuszeni jesteśmy przygotować sobie własne maszyny i zainstalować na nich stosowne oprogramowanie, właściwe dla klienckiego systemu operacyjnego.
Sam Xen Server w wersji 7 znajduje się na liście kompatybilności PowerPanel Business Edition Linux.
Przyjrzyjmy się trochę głębiej poszczególnym częściom systemu. Tym razem rozpoczniemy od Agenta. Agenta musimy stosować tam, gdzie chcemy zarządzać urządzeniem, które nie posiada możliwości pracy w sieci. Najprostszym przykładem niech będzie tutaj prosty UPS, chroniący stację roboczą. Zasilacz awaryjny połączony jest z komputerem za pomocą USB.
Malutki programik – agent działa w tle, na bieżąco komunikując się z UPSem. W przypadku, gdy UPS „zaraportuje” jedno ze zdefiniowanych zdarzeń, działający w tle agent podejmie zaprogramowaną akcję.
Ciekawostką jest, że w przypadku środowisk wirtualnych rozwiązanie CyberPower działa w ten sam sposób.
Rolę agenta w środowisku wirtualnym może pełnić albo karta sieciowa zasilacza awaryjnego, albo malutka maszyna wirtualna, która może komunikować się z UPS za pomocą… kabla USB, podłączonego do hosta fizycznego. Dla środowiska ESXi, CyberPower udostępnia przygotowaną do wdrożenia w postaci OVF malutką maszynkę wirtualną opartą o CentOS. Wymagania są naprawdę symboliczne:
Konfiguracja sprzętowa maszyny PowerPanel Agent
Instalacja jest łatwa, szybka i przyjemna. Sprowadza się do wdrożenia maszyny z poziomu vSphere Web Client (Opcja „Deploy a virtual machine from an OVF or OVA file) oraz do „przypięcia” naszej maszynie odpowiedniego urządzenia USB (czyli naszego UPSa), którego zawczasu podpięliśmy do naszego hosta.
W tym celu musimy wejść w edycję ustawień urządzeń sprzętowych wirtualnej maszyny z agentem i dodać nowe urządzenie USB (New USB Device). Z rozwijanej listy wybieramy nasz zasilacz awaryjny, zapisujemy i gotowe.
Przypięcie urządzenia USB do maszyny wirtualnej Agenta
Po instalacji przychodzi czas na konfigurację. Sprawdzamy adres IP Agenta – co można zrobić na przykład logując się na konsoli tekstowej linuxa maszyny wirtualnej (początkowe hasło admin/admin), albo sprawdzając adres IP maszyny wirtualnej w konsoli WebClienta VMware. Jak już znamy adres, możemy zalogować się do interfejsu webowego:
Ekran kreatora ustawień PowerPanel Agent
Po przeklikaniu kreatora, mamy dostęp do eleganckiej konsoli zarządzania urządzenia UPS.
Konsola PowerPanel Agent
I wydawać się mogło, że to wszystko – mamy zabezpieczonego hosta. Mamy zarządzalny UPS, potrafiący współpracować z ESXi. Ale tak naprawdę to dopiero początek.
Jak powiedział jeden z bohaterów w filmie „Miś”: „życie stawia przed nami szereg wyzwań” – tak jest w rzeczywistości. Zabezpieczyć środowisko składające się z jednego hosta i jednego zasilacza awaryjnego to łatwizna. Ale co wtedy, gdy mamy jeden UPS i kilka hostów? Przecież tylko jeden z nich możemy podłączyć do UPSa?
W tym miejscu właśnie należy się pochwała autorom opisywanej koncepcji, bo taki scenariusz nie będzie wyzwaniem. Jeden UPS, wyposażony tylko w jeden port USB może zabezpieczać i monitorować kilka hostów.
Rozmawiamy o takim scenariuszu:
Schemat scenariusza, w którym jeden host monitoruje dwa UPSy, do których podłączone są też inne hosty
Jeden z hostów połączony jest z UPS za pomocą USB. Na tym hoście uruchamiamy wirtualkę z Agentem, który będzie komunikował się z zasilaczem awaryjnym. Pozostałe hosty ESXi chronione przez ten sam UPS powinny posiadać uruchomione i skonfigurowane wirtualne maszyny z Klientem Power Panel (Power Panel Client –będę nazw używał zamiennie). Poziom klienta jest poziomem nadrzędnym dla poziomu Agenta. Ponadto Klient PowerPanel może zarządzać kilkoma Agentami lub na przykład agentem i UPS z kartą sieciową.
Za pomocą duetu aplikacji Agent – Klient możemy w Power Panel zaimplementować różne scenariusze, także takie, które wydają się nie do zrealizowania bez posiadania większego budżetu.
Wyobraźmy sobie następującą konfigurację: posiadamy dwa hosty fizyczne, na każdym z nich działa hypervisor, są maszyny wirtualne. Starając się zminimalizować istnienie jednego punktu awaryjnego podłączamy „krzyżowo” te dwa hosty do dwóch zasilaczy awaryjnych, tak aby w przypadku problemów z jednym źródłem zasilania nie odbiło się to na pracy naszych serwerów.
Idealnym urządzeniem, które powinniśmy zastosować jest ATS (Automatic Transfer Switch). Do ATS podłączamy dwa źródła zasilania. ATS jest zarządzalny, posiada kartę sieciową Remote Management i zadba o to żeby mówiąc kolokwialnie naszym maszynom nie zabrakło prądu. A jeżeli tego prądu zacznie nam brakować, przeprowadzi bezpieczny shutdown naszego środowiska nim wyczerpią się baterie zasilaczy awaryjnych. Generalnie ATS jest świetnym rozwiązaniem, które gorąco rekomenduję.
Schemat podłączenia z udziałem ATS
Jednakowoż, jak zwykle w naszej codzienności problemem może okazać się budżet. Jeżeli go nie mamy, a posiadamy sprzęt Cyber Power, możemy zbudować sobie „programowy” ATS. Nawet gdy do dyspozycji mamy najprostsze urządzenia, możemy budować całkiem interesujące konfiguracje. Spróbujmy wdrożyć najprostszy, najbardziej oczywisty scenariusz.
Jeden serwer fizyczny z dwoma zasilaczami, zainstalowanym ESXi, kilkoma maszynami wirtualnymi. Każdy z zasilaczy serwera podłączamy do jednego UPSa. Czyli mamy serwer z dwoma zasilaczami podłączony do dwóch niezależnych źródeł zasilania. Czyli powoli wchodzimy na odpowiedni poziom bezpieczeństwa energetycznego. Zasilacze awaryjne pracują jednak niezależnie od siebie, niejako nic o sobie wzajemnie nie wiedząc.
Co jednak w sytuacji, kiedy wyczerpie się bateria w UPS podłączonym do jednego z zasilaczy, a kilka minut później również drugie źródło zasilania zacznie szwankować?
Albo jeszcze trudniejszy scenariusz do obsłużenia. Mamy dwa zasilacze w serwerze, dwa UPSy podłączone do dwóch różnych obwodów zasilania. Jeden z obwodów zawiódł, ale na wejściu drugiego zasilania mamy prąd o odpowiednich parametrach, całość pracuje poprawnie.
Dzięki mnogości opcji konfiguracyjnych i takie scenariusze będą nam niestraszne. Wystarczy odpowiednio „poinformować” aplikację Klienta – o tym, że pracuje w konfiguracji redundantnej 1+1, potem ustawić akcje, tak aby awaria tylko jednego źródła zasilania nie powodowała rozpoczęcia procedury wyłączania serwera.
PowerPanel Client – kreator, etap przyporządkowania źródeł zasilania
Na powyższym ekranie widzimy ustawienia informujące aplikację Power Panel Client o tym, że host chroniony jest przez dwa zasilacze awaryjne, które są (w naszym przypadku) zarządzane przez aplikacje Agentów – o adresach IP 10.2.0.115 i 10.2.0.112 oraz o tym, do których gniazdek zasilania w UPSach podpięty jest host.
Nic nie stoi na przeszkodzie, żeby chronić za pomocą dwóch zasilaczy awaryjnych jeden serwer z wirtualizatorem. Wystarczy wówczas na serwerze zainstalować dwie instancje PowerPanel Agent – do każdej z nich w ustawieniach sprzętowych maszyny wirtualnej przypisać odpowiedni UPS (poprzez przypisanie urządzenia USB).
Potem tylko instalacja PowePanel Client, odpowiednie wskazanie agentów, ustawienia i mamy prosty odpowiednik urządzenia typu ATS, w atrakcyjnym budżecie, bowiem taki zestaw możemy sobie „skonstruować” nawet z tańszych urządzeń Cyberpower.
Taki zestaw zapewni nam stabilne i bezpieczne zasilanie – które możemy (niemal) dowolnie dostosowywać do własnych potrzeb, zmieniając ustawienia i programując odpowiednie wyzwalacze.
W opisywanej powyżej sytuacji – gdzie mamy dwa zasilacze awaryjne, na pewno chcielibyśmy uniknąć sytuacji, w której PowerPanel wyłączy nam środowisko gdy jeden z UPSów nie dostarcza energii – natomiast drugi pracuje normalnie.
Power Panel staje na wysokości zadania i jeśli komputer ma nadmiarowe zasilanie, zdarzenie „wyłączenie systemu” zostanie wywołane dopiero po utracie wszystkich nadmiarowych zasilaczy UPS, w momencie, gdy problem dotyczy „ostatniego” UPSa.
Wyzwolenie procesu zamykania systemu dla konfiguracji 1+1
Prawdę mówiąc nie obiecywałem sobie wiele rozpoczynając poszukiwania ciekawych rozwiązań w tej dziedzinie. Praktycznie wszyscy dostawcy sprzętu oferują zbliżone możliwościami urządzenia i oprogramowanie uzupełniające.
Standardem jest monitorowanie stanu UPS za pomocą zainstalowanej w nim karty sieciowej, a ewentualne działania w sytuacji awaryjnej są podejmowane na podstawie komunikacji sieciowej pomiędzy tą kartą a jakimś oprogramowaniem zainstalowanym po stronie wirtualizatora lub na fizycznym systemie.
Oczywiście CyberPower oferuje także takie rozwiązania. Ale największą wartością jest fakt, że nawet dysponując niższym budżetem, nie musimy rezygnować ze stosowania dobrych praktyk. Ba, łatwo możemy integrować ze sobą rozwiązania klasy enterprise z rozwiązaniami typu SOHO – które możemy zastosować np. w środowisku testowym.
[simple-author-box]
