Klaster VMware dla produkcji 24/7: 64 maszyny wirtualne bez zatrzymywania firmy
Klaster VMware dla produkcji 24/7: 64 maszyny wirtualne bez zatrzymywania firmy
Klaster VMware dla produkcji musi spełniać znacznie wyższe wymagania niż infrastruktura wykorzystywana wyłącznie do pracy biurowej. W zakładzie działającym przez całą dobę nawet krótka niedostępność serwerów może zatrzymać pracę aplikacji produkcyjnych, systemu ERP, magazynu, kontroli jakości lub obsługi wysyłek.
W środowisku naszego klienta działały trzy wydajne serwery fizyczne, macierz dyskowa podłączona przez Fibre Channel oraz 64 maszyny wirtualne. Naszym zadaniem było uporządkowanie rozbudowanej infrastruktury, sprawdzenie jej odporności na awarie i przygotowanie jej do bezpiecznego utrzymania bez zatrzymywania przedsiębiorstwa.
Klaster VMware dla produkcji – projekt w liczbach
Środowisko klienta obsługiwało systemy wykorzystywane zarówno przez administrację, jak i przez działy bezpośrednio związane z produkcją.
| Element infrastruktury | Parametry |
|---|---|
| Fizyczne serwery VMware | 3 hosty |
| Procesory | Intel Xeon Gold |
| Pamięć RAM | 3 × 512 GB |
| Łączna pamięć RAM | ponad 1,5 TB |
| Maszyny wirtualne | 64 |
| Pamięć masowa | macierz podłączona przez Fibre Channel |
| Tryb pracy firmy | 24 godziny na dobę, 7 dni w tygodniu |
Host to w tym przypadku fizyczny serwer, na którym uruchamiane są maszyny wirtualne. Każda z takich maszyn pełni funkcję osobnego serwera i może obsługiwać między innymi system ERP, bazę danych, pliki firmowe, aplikacje produkcyjne, usługi sieciowe lub system kopii zapasowych.
Wirtualizacja pozwala lepiej wykorzystać sprzęt i łatwiej przenosić systemy między serwerami. Nie oznacza jednak, że samo posiadanie trzech hostów automatycznie chroni firmę przed przestojem.
Największe wyzwanie: produkcji nie można po prostu wyłączyć
W wielu firmach większe prace przy serwerach można przeprowadzić wieczorem lub w weekend. W zakładzie działającym 24/7 takie okno serwisowe może być bardzo krótkie albo nie występować wcale.
Każda zmiana musi więc uwzględniać:
- systemy krytyczne dla ciągłości produkcji,
- zależności pomiędzy aplikacjami,
- dostępną rezerwę mocy obliczeniowej,
- kolejność uruchamiania usług po awarii,
- możliwość wycofania zmiany,
- wpływ prac na użytkowników i urządzenia produkcyjne.
Nie wystarczy odpowiedzieć na pytanie, czy wszystkie maszyny działają. Trzeba również wiedzieć, co stanie się po awarii jednego z hostów, utracie połączenia z macierzą albo konieczności wykonania aktualizacji.
Czy pozostałe serwery przejmą całe obciążenie?
W normalnych warunkach maszyny wirtualne mogą być rozłożone pomiędzy trzy hosty. Problem pojawia się wtedy, gdy jeden z fizycznych serwerów przestanie działać.
Pozostałe dwa hosty muszą dysponować wystarczającymi zasobami, aby przejąć najważniejsze systemy. Z tego powodu klastra nie należy planować tak, jakby wszystkie trzy serwery zawsze były dostępne.
Podczas analizy sprawdziliśmy między innymi:
- faktyczne wykorzystanie procesorów i pamięci RAM,
- rozłożenie maszyn pomiędzy hostami,
- ilość zasobów pozostających w rezerwie,
- liczbę procesorów wirtualnych przydzielonych poszczególnym maszynom,
- maszyny o największym znaczeniu dla działalności firmy,
- systemy, które w sytuacji awaryjnej mogą zostać czasowo wyłączone.
Dzięki temu możliwe było określenie, czy środowisko jest przygotowane na pracę po utracie jednego z hostów.
Mówiąc prościej: trzy serwery nie powinny być przez cały czas wykorzystane niemal w 100%. Część ich możliwości musi pozostać wolna właśnie na wypadek awarii lub planowanych prac.
Ustalenie, które systemy są naprawdę krytyczne
Nie wszystkie spośród 64 maszyn wirtualnych miały takie samo znaczenie. Innego podejścia wymaga serwer obsługujący produkcję, a innego środowisko testowe używane sporadycznie przez administratorów.
Dlatego maszyny zostały podzielone według znaczenia dla przedsiębiorstwa.
Systemy krytyczne
Do tej grupy zaliczane są zazwyczaj:
- systemy ERP i kluczowe bazy danych,
- aplikacje związane z planowaniem i rozliczaniem produkcji,
- systemy magazynowe,
- usługi uwierzytelniania użytkowników,
- systemy wymiany danych pomiędzy produkcją a administracją.
Powinny być uruchamiane w pierwszej kolejności.
Systemy ważne
To między innymi serwery plików, aplikacje raportowe, systemy integracyjne i pozostałe usługi potrzebne pracownikom do normalnego wykonywania obowiązków.
Krótka przerwa w ich działaniu może być odczuwalna, ale nie musi natychmiast zatrzymać produkcji.
Systemy pomocnicze i testowe
Środowiska szkoleniowe, testowe lub archiwalne mogą otrzymać niższy priorytet. W sytuacji awaryjnej nie powinny zajmować zasobów potrzebnych najważniejszym usługom.
Taka klasyfikacja ułatwia podejmowanie decyzji zarówno podczas awarii, jak i podczas codziennego utrzymania infrastruktury.
Wysoka dostępność, czyli co dzieje się po awarii hosta
Klaster wykorzystywał mechanizmy wysokiej dostępności VMware, określane skrótem HA. Ich zadaniem jest wykrycie awarii fizycznego serwera i ponowne uruchomienie jego maszyn wirtualnych na pozostałych hostach.
Mechanizm ten nie zastępuje jednak prawidłowego projektu. Jeżeli pozostałe serwery nie mają wystarczających zasobów, dostęp do danych jest niedostępny albo priorytety maszyn zostały źle określone, część usług może nie uruchomić się zgodnie z oczekiwaniami.
W ramach prac zweryfikowaliśmy:
- konfigurację klastra i mechanizmów HA,
- priorytety restartu maszyn,
- reguły rozmieszczenia kluczowych systemów,
- komunikację pomiędzy hostami,
- dostępność wspólnej pamięci masowej,
- alarmy i zdarzenia rejestrowane przez środowisko VMware.
Szczególną uwagę zwróciliśmy na systemy posiadające więcej niż jeden serwer. Dwa kontrolery domeny lub dwa elementy tej samej aplikacji nie powinny bez potrzeby pracować na jednym fizycznym hoście. Jego awaria mogłaby wtedy wyłączyć oba zabezpieczające się wzajemnie systemy.
Prace serwisowe bez wyłączania całej firmy
W klastrze VMware działające maszyny wirtualne mogą być przenoszone pomiędzy hostami. Pozwala to opróżnić jeden serwer, wykonać na nim zaplanowane prace, a następnie ponownie włączyć go do środowiska.
Dla użytkownika aplikacja nadal działa, mimo że obsługujący ją serwer wirtualny został przeniesiony na inne urządzenie fizyczne.
Takie podejście umożliwia między innymi:
- instalowanie aktualizacji,
- aktualizowanie oprogramowania sprzętowego,
- wymianę podzespołów,
- diagnostykę hosta,
- przeprowadzanie kontrolowanych testów,
- wykonywanie prac bez jednoczesnego zatrzymywania wszystkich maszyn.
Zmiany realizowaliśmy etapami. Po każdej operacji sprawdzaliśmy stan usług, obciążenie pozostałych hostów oraz dostępność systemów istotnych dla produkcji.
Macierz Fibre Channel – wspólne miejsce dla danych
Maszyny wirtualne korzystały z zewnętrznej macierzy dyskowej połączonej z hostami za pomocą Fibre Channel.
Fibre Channel to dedykowany sposób komunikacji pomiędzy serwerami a pamięcią masową. Zapewnia szybki i przewidywalny dostęp do danych, ale wymaga poprawnej konfiguracji całej ścieżki: od hosta, przez przełączniki, aż po kontrolery macierzy.
Weryfikacja objęła między innymi:
- dostęp hostów do zasobów macierzy,
- działanie wielu niezależnych ścieżek komunikacyjnych,
- wykorzystanie dostępnej przestrzeni,
- opóźnienia w dostępie do danych,
- stan połączeń i kontrolerów,
- ryzyko zapełnienia przestrzeni przeznaczonej dla maszyn wirtualnych.
To szczególnie ważne, ponieważ wspólna macierz obsługuje wszystkie hosty. Nawet dobrze skonfigurowany klaster serwerów nie zapewni ciągłości pracy, jeżeli dane staną się niedostępne.
Więcej o projektowaniu takich środowisk opisujemy na stronie serwery i macierze dla firm.
Porządkowanie 64 maszyn wirtualnych
Wraz z rozwojem przedsiębiorstwa liczba maszyn wirtualnych stopniowo rośnie. Pojawiają się nowe aplikacje, środowiska testowe i kolejne wersje istniejących systemów.
Bez regularnego przeglądu może to prowadzić do sytuacji, w której część zasobów jest przydzielona na zapas, stare maszyny pozostają uruchomione, a tymczasowe snapshoty zajmują miejsce przez wiele miesięcy.
W ramach porządkowania środowiska przeanalizowaliśmy:
- przydział procesorów i pamięci RAM,
- nieużywane lub zapomniane maszyny,
- pozostawione snapshoty,
- wersje systemów operacyjnych,
- narzędzia integracyjne VMware,
- opisy i nazewnictwo serwerów,
- właścicieli biznesowych poszczególnych aplikacji,
- zależności pomiędzy systemami.
Celem nie było ograniczanie zasobów za wszelką cenę. Chodziło o dopasowanie ich do rzeczywistych potrzeb i odzyskanie rezerwy niezbędnej na wypadek awarii.
Klaster nie zastępuje kopii zapasowych
Wysoka dostępność ogranicza skutki awarii fizycznego hosta, ale nie chroni przed każdym zagrożeniem.
Jeżeli dane zostaną przypadkowo usunięte, zaszyfrowane przez ransomware albo uszkodzone przez błąd aplikacji, klaster może jedynie uruchomić dalej tę samą uszkodzoną maszynę.
Dlatego niezależnie od mechanizmów VMware należy zadbać o:
- regularne kopie maszyn wirtualnych,
- przechowywanie kopii poza głównym środowiskiem,
- ochronę repozytorium backupowego przed modyfikacją,
- kontrolę poprawności wykonania zadań,
- regularne testy odtwarzania,
- ustaloną kolejność odzyskiwania systemów.
Samo pojawienie się komunikatu „backup zakończony” nie daje jeszcze pewności, że system da się odtworzyć. Dopiero test przywrócenia pokazuje, czy kopia rzeczywiście spełnia swoje zadanie.
Więcej informacji znajduje się w naszej usłudze backup danych dla firm.
Monitoring, który pozwala reagować wcześniej
Przy 64 maszynach wirtualnych ręczne sprawdzanie całego środowiska nie jest wystarczające. Administrator nie powinien dowiadywać się o problemie dopiero po zgłoszeniu z produkcji.
Monitoring został ukierunkowany na parametry, które mogą wcześniej wskazać zbliżającą się awarię lub brak zasobów:
- obciążenie hostów,
- wykorzystanie pamięci RAM,
- dostępność maszyn wirtualnych,
- zajętość przestrzeni dyskowej,
- opóźnienia macierzy,
- stan połączeń Fibre Channel,
- błędy sprzętowe,
- nieaktualne lub długo utrzymywane snapshoty,
- poprawność wykonywania kopii zapasowych.
Dobrze skonfigurowany monitoring nie powinien wysyłać setek nieistotnych komunikatów. Jego zadaniem jest przekazywanie informacji, na podstawie których można podjąć konkretne działanie.
Zakres takiego nadzoru opisujemy szerzej na stronie monitoring infrastruktury IT.
Dokumentacja zamiast wiedzy zapisanej w głowie administratora
Rozbudowane środowisko nie może być zależne wyłącznie od wiedzy jednej osoby. Awaria, urlop albo zmiana pracownika nie powinny powodować, że nikt nie wie, od czego zacząć diagnostykę.
Dokumentacja środowiska objęła najważniejsze informacje dotyczące:
- hostów VMware,
- maszyn wirtualnych,
- pamięci masowej,
- sieci i połączeń Fibre Channel,
- systemów krytycznych,
- kolejności uruchamiania usług,
- kontaktów serwisowych,
- procedur awaryjnych,
- planowanych prac utrzymaniowych.
Dokumentacja techniczna została uzupełniona o kontekst biznesowy. Samo oznaczenie serwera nazwą nie zawsze wyjaśnia, czy jego awaria zatrzyma produkcję, magazyn czy jedynie raportowanie.
Efekty uporządkowania środowiska VMware
Po zakończeniu prac klient otrzymał środowisko, którego stan i ograniczenia można było realnie ocenić.
Najważniejsze rezultaty projektu to:
- uporządkowanie 64 maszyn wirtualnych,
- określenie systemów krytycznych dla produkcji,
- sprawdzenie rezerwy potrzebnej po awarii hosta,
- weryfikacja ustawień wysokiej dostępności,
- kontrola połączeń z macierzą Fibre Channel,
- uporządkowanie przydziału zasobów,
- przygotowanie zasad prowadzenia prac serwisowych,
- rozszerzenie monitoringu infrastruktury,
- przygotowanie dokumentacji i procedur awaryjnych.
Najważniejszym efektem nie była jednak sama zmiana ustawień. Klient zyskał większą przewidywalność działania infrastruktury i wiedzę, jak środowisko zachowa się w sytuacji awaryjnej.
Czego mogą nauczyć się inne firmy produkcyjne?
Duża liczba serwerów i rozbudowana macierz nie gwarantują jeszcze ciągłości działania. O odporności infrastruktury decyduje sposób, w jaki wszystkie elementy współpracują ze sobą.
Firma wykorzystująca klaster VMware powinna regularnie odpowiadać na kilka podstawowych pytań:
- Czy po awarii jednego hosta pozostałe serwery mają wystarczające zasoby?
- Które aplikacje muszą zostać uruchomione jako pierwsze?
- Czy każdy host ma niezależny dostęp do danych?
- Czy kopie zapasowe są przechowywane poza głównym klastrem?
- Kiedy ostatnio wykonano test odtworzenia?
- Czy monitoring ostrzeże administratorów przed zapełnieniem macierzy?
- Czy istnieje aktualna dokumentacja i procedura działania po awarii?
Brak odpowiedzi nie oznacza, że awaria na pewno wystąpi. Oznacza jednak, że jej skutki i czas potrzebny na przywrócenie pracy są trudne do przewidzenia.
Dobrym punktem wyjścia może być audyt infrastruktury IT, obejmujący serwery, wirtualizację, macierze, sieć, backup oraz dokumentację.
Infrastruktura IT dla produkcji wymaga planu
Środowisko obsługujące produkcję 24/7 powinno być rozwijane i utrzymywane według ustalonego planu. Dotyczy to zarówno aktualizacji VMware, jak i wymiany sprzętu, rozbudowy zasobów, backupu oraz reagowania na alarmy.
W NodeIT pomagamy firmom produkcyjnym projektować, modernizować i utrzymywać środowiska serwerowe. Łączymy wiedzę techniczną z analizą wpływu infrastruktury na pracę przedsiębiorstwa.
Zobacz, jak wygląda nasza obsługa IT dla firm produkcyjnych oraz realizacja projektów i migracji IT.
Korzystasz z VMware, Hyper-V, Proxmox lub innej platformy wirtualizacyjnej? Nie masz pewności, czy środowisko poradzi sobie po awarii jednego z serwerów? Skontaktuj się z NodeIT i opisz swoją infrastrukturę. Pomożemy określić, od czego zacząć i które obszary wymagają sprawdzenia.
Najczęściej zadawane pytania
Co to jest klaster VMware?
Klaster VMware to grupa fizycznych serwerów zarządzanych jako jedno środowisko. Maszyny wirtualne mogą być rozkładane pomiędzy hostami, a w przypadku awarii jednego z nich najważniejsze systemy mogą zostać uruchomione na pozostałych serwerach.
Czy trzy hosty VMware zapewniają pełną odporność na awarie?
Nie automatycznie. Konieczna jest odpowiednia rezerwa procesora i pamięci RAM, prawidłowo skonfigurowana wysoka dostępność, niezależne połączenia sieciowe oraz dostęp do wspólnej pamięci masowej. Klaster należy także regularnie testować.
Czy można aktualizować hosty VMware bez zatrzymywania maszyn?
W odpowiednio skonfigurowanym środowisku maszyny wirtualne można przenosić pomiędzy kompatybilnymi hostami. Pozwala to opróżnić wybrany serwer i wykonać na nim prace serwisowe bez wyłączania wszystkich usług.
Czy wysoka dostępność VMware zastępuje backup?
Nie. Wysoka dostępność pomaga ograniczyć skutki awarii hosta, ale nie chroni przed usunięciem danych, ransomware, błędem aplikacji ani uszkodzeniem systemu. Kopie zapasowe muszą być niezależnym elementem ochrony.
Jak sprawdzić, czy klaster jest przygotowany na awarię?
Należy przeanalizować wykorzystanie zasobów, ustawienia wysokiej dostępności, dostęp do macierzy, konfigurację sieci, priorytety maszyn, backup, monitoring oraz procedury awaryjne. Najbezpieczniej uzupełnić analizę kontrolowanymi testami.
