Instalacja klastra RHEV i hiperwizorów RHEL — część 5

W tej części omówimy kilka ważnych punktów związanych z naszą serią RHEV. W Części 2 tej serii omówiliśmy wdrożenia i instalacje RHEV Hypervisor. W tej części omówimy inne sposoby instalacji Hypervisora RHEV.

Pierwszy sposób został zrealizowany przy użyciu dedykowanego RHEVH, który został dostosowany przez samego RedHata bez żadnych modyfikacji lub zmian ze strony administratora. W drugą stronę użyjemy normalnego serwera RHEL [Minimalna instalacja], który będzie działał jako Hypervisor RHEV.

Krok 1: Dodaj hiperwizora RHEL do środowiska

1. Zainstaluj subskrybowany serwer RHEL6 [Instalacja minimalna]. Możesz powiększyć swoje środowisko wirtualne dodając dodatkowy subskrybowany serwer RHEL6. [Minimalna instalacja] pełni funkcję hypervisora.

Specyfikacja maszyny wirtualnej

OS: RHEL6.6 x86_64
Number of processors: 2
Number of cores : 1
Memory : 3G
Network : vmnet3
I/O Controller : LSI Logic SAS
Virtual Disk : SCSI
Disk Size : 20G
IP: 11.0.0.7
Hostname: rhel.mydomain.org

i upewnij się, że zaznaczyłeś opcję wirtualizacja w ustawieniach procesora vm.

Wskazówka: upewnij się, że Twój system subskrybuje kanały redhat i jest aktualny. Jeśli nie wiesz, jak subskrybować kanał subskrypcji redhat, możesz przeczytać artykuł Włącz kanał subskrypcji Red Hat.

Wskazówka: aby zaoszczędzić zasoby, możesz zamknąć jeden z aktualnie uruchomionych hypervisorów.

2. Aby zamienić swój serwer w hypervisor (użyj go jako hypervisora), może być konieczne zainstalowanie na nim agenta RHEVM.

yum install vdsm

Po zakończeniu instalacji pakietów przejdź do interfejsu internetowego RHEVM, aby go dodać.

3. W porównaniu z hiperwizorem RHEVH możesz dodać hiperwizora RHEL w jedną stronę z RHEM, używając danych uwierzytelniających root hiperwizora RHEL. Zatem z rhevm WUI przejdź do zakładki Hosty i kliknij nowy.

Następnie podaj informacje o hoście, jak pokazano.

Następnie zignoruj ostrzeżenie Power mgmt i zakończ, a następnie odczekaj kilka minut i sprawdź status nowo dodanego hosta.

Aby uzyskać więcej informacji na temat dodawania hosta opartego na RHEL, zapoznaj się z oficjalną dokumentacją RHEV firmy RedHat.

Krok 2: Zarządzanie klastrem RHEV

Klastrowanie w RHEV opisuje grupę hostów tego samego typu procesora, które korzystają z tej samej pamięci [np. przez sieć] i których używamy do wykonania określonego zadania [np. Wysoka dostępność ]

Klastrowanie ogólnie wiąże się z wieloma dodatkowymi zadaniami. Możesz zapoznać się z artykułem wyjaśniającym, czym jest klastrowanie oraz jakie są jego zalety i wady.

Główną zaletą klastrowania w RHEV jest umożliwienie i zarządzanie migracją maszyn wirtualnych pomiędzy hostami należącymi do tego samego klastra.

Jak zatem maszyny wirtualne migrują między hostami?

RHEV ma dwie strategie:

1. Migracja na żywo
2. Wysoka dostępność

1. Migracja na żywo

Migracja na żywo stosowana w sytuacjach niekrytycznych, co oznacza, że ogólnie wszystko działa dobrze, ale musisz wykonać pewne zadania związane z równoważeniem obciążenia (np. odkryłeś, że host jest ładowany przez maszynę wirtualną przez inną. Więc musisz może przeprowadzić migrację maszyny wirtualnej na żywo z hosta na inny, aby osiągnąć równoważenie obciążenia).

Uwaga: podczas migracji na żywo nie ma przerw w działaniu usług, aplikacji ani użytkowników działających w maszynie wirtualnej. Migracja na żywo zwana także ponowną alokacją zasobów.

Migracja na żywo może być przetwarzana ręcznie lub automatycznie, zgodnie z wcześniej określoną polityką:

Ręcznie: wymuś wybór hosta docelowego, a następnie przeprowadź do niego ręczną migrację maszyny wirtualnej za pomocą WUI.
Automatyczny: użycie jednej z zasad klastra do zarządzania migracją na żywo według użycia pamięci RAM, wykorzystania procesora itp.

Przejdź na kartę Klastry i wybierz Klaster 1 i kliknij edytuj.

Z kart okien przejdź na kartę Zasady klastrowe.

Wybierz zasadę równomiernie rozłożone. Ta zasada umożliwia skonfigurowanie maksymalnego progu wykorzystania procesora na hoście i dozwolonego czasu ładowania przed rozpoczęciem migracji na żywo.

Wskazówka

Jak pokazano, skonfigurowałem maksymalny próg na 50% i czas trwania na 1 minutę.

Następnie OK i przejdź do karty VM.

Wybierz maszynę wirtualną Linux [Wcześniej utworzoną], a następnie kliknij edytuj i sprawdź te punkty.

1. Na karcie Host: zaznacz opcję Ręczna i Automatyczna. Migracja na żywo jest dozwolona dla tej maszyny wirtualnej.

2. Na karcie HA: sprawdź stopień Priorytetu swojej maszyny wirtualnej. W naszym przypadku nie jest to zbyt istotne, gdyż gramy tylko z jednym vm. Ale ważne będzie ustawienie priorytetów dla maszyn wirtualnych w dużym środowisku.

Następnie uruchom maszynę wirtualną z systemem Linux.

Najpierw użyjemy ręcznej migracji na żywo. Maszyna wirtualna z systemem Linux działa teraz na rhel.mydomain.org.

Przed rozpoczęciem migracji uruchommy następującą komendę w konsoli vm.

ls -lRZ /

Następnie wybierz Maszynę wirtualną z systemem Linux i kliknij Migraj.

Jeśli wybierzesz automatycznie, system sprawdzi najbardziej odpowiedzialny host jako docelowy zgodnie z polityką klastra. Przetestujemy to bez ingerencji administratora.

Zatem po ręcznym wybraniu i wybraniu miejsca docelowego kliknij OK, przejdź do konsoli i monitoruj uruchomione polecenie. Możesz także sprawdzić status maszyny wirtualnej.

Może być konieczne monitorowanie zdarzeń zadań.

Po kilku sekundach zobaczysz zmianę w nazwie hosta vm.

Twoja VM została ręcznie przeniesiona na żywo pomyślnie!!

Spróbujmy automatycznej migracji na żywo. Naszym celem jest przekroczenie obciążenia procesora na hoście rhevhn1 o 50%. Zrobimy to zwiększając obciążenie samego vm, zatem z konsoli napiszmy następującą komendę:

dd if=/dev/urandom of=/dev/null

i monitoruj obciążenie hosta.

Po kilku minutach obciążenie hosta przekroczy 50%.

Poczekaj jeszcze kilka minut, a migracja na żywo rozpocznie się automatycznie, jak pokazano.

Możesz także sprawdzić kartę zadań i po krótkim oczekiwaniu Twoja maszyna wirtualna zostanie automatycznie przeniesiona na żywo do hosta rhel.

Ważne: upewnij się, że jeden z Twoich hostów ma więcej zasobów niż drugi. Jeśli oba hosty mają identyczne zasoby. Maszyna wirtualna nie zostanie przeniesiona, ponieważ nie będzie żadnej różnicy !!

Wskazówka: przełączenie hosta w tryb konserwacji spowoduje automatyczną migrację na żywo i uruchomienie maszyn wirtualnych na innych hostach w tym samym klastrze.

Więcej informacji na temat migracji maszyn wirtualnych można znaleźć w artykule Migracja maszyn wirtualnych między hostami.

Wskazówka: migracja na żywo między różnymi klastrami nie jest oficjalnie obsługiwana. W jednym przypadku możesz to sprawdzić tutaj.

2. Wysoka dostępność

W przeciwieństwie do Migracji na żywo, HA służy do obsługi sytuacji krytycznych, a nie tylko do zadań równoważenia obciążenia. Wspólna sekcja dotycząca migracji Twojej maszyny wirtualnej na inny host, ale z przestojami podczas ponownego uruchamiania.

Jeśli w klastrze występuje awaria, nie działa lub nie odpowiada host, migracja na żywo nie może Ci pomóc. HA wyłączy maszynę wirtualną i uruchomi ją ponownie na innym działającym hoście w tym samym klastrze.

Aby włączyć HA w swoim środowisku, musisz mieć co najmniej jedno urządzenie do zarządzania energią [np. wyłącznik zasilania] w swoim otoczeniu.

Niestety nie jesteśmy w stanie tego zrobić w naszym środowisku wirtualnym. Więcej informacji na temat HA w RHEV znajdziesz w artykule Poprawa czasu pracy dzięki wysokiej dostępności maszyn wirtualnych.

Pamiętaj: migracja na żywo i wysoka dostępność działają z hostami w tym samym klastrze, z procesorem tego samego typu i podłączonymi do współdzielonej pamięci masowej.

Wniosek:

Osiągnęliśmy szczyt w naszej serii, gdy omówiliśmy jedną z ważnych funkcji klastrowania RHEV, tak jak ją opisaliśmy i jej znaczenie. Omówiliśmy także drugi typ [metody] wdrażania hiperwizorów RHEV opartych na RHEL [co najmniej 6.6 x86_64].

W następnym artykule będziemy mogli wykonywać pewne operacje na maszynach wirtualnych, takie jak migawki, uszczelnianie, klonowanie, eksportowanie i pule.