RHEV Clustering og RHEL Hypervisors Installation - Del 5

I denne del skal vi diskutere nogle vigtige punkter relateret til vores RHEV-serie. I del 2 af denne serie har vi diskuteret implementering og installation af RHEV Hypervisor. I denne del vil vi diskutere andre måder at installere RHEV Hypervisor på.

Den første måde blev gjort ved at bruge dedikeret RHEVH, som blev tilpasset af RedHat selv uden ændringer eller ændringer fra admin side. På den anden måde bruger vi en normal RHEL-server [Minimal installation], der fungerer som en RHEV Hypervisor.

Trin 1: Tilføj RHEL Hypervisor til miljøet

1. Installer RHEL6-server, der abonnerer på [Minimal installation]. Du kan øge dit virtuelle miljø ved at tilføje yderligere abonneret RHEL6-server [Minimal installation] fungerer som hypervisor.

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

og sørg for, at du har markeret virtualiseringsmuligheden i vm-processorindstillinger.

Tip: Sørg for, at dit system abonnerer på redhat-kanaler og er opdateret. Hvis du ikke ved, hvordan du abonnerer på redhat-abonnementskanal, kan du læse artiklen Aktivér Red Hat-abonnementskanal.

Tip: For at gemme dine ressourcer kan du lukke ned for en af de i øjeblikket kørende hypervisorer.

2. For at gøre din server til hypervisor {brug den som hypervisor} skal du muligvis installere RHEVM-agenten på den.

# yum install vdsm

Når pakken er installeret, skal du gå til RHEVM-webgrænsefladen for at tilføje den.

3. I modsætning til RHEVH hypervisor kan du tilføje RHEL hypervisor fra en vej fra RHEM ved hjælp af rodlegitimationen til RHEL hypervisor. Så fra rhevm WUI skift til fanen Værter og klik på ny.

Angiv derefter dine værtsoplysninger som vist.

Dernæst skal du ignorere Power mgmt advarsel og afslut, vent derefter et par minutter og kontroller status for den nyligt tilføjede vært.

For flere detaljer om tilføjelse af RHEL-baseret vært, se RedHat officielle RHEV-dokumentation.

Trin 2: Administration af RHEV-klynger

Clustering i RHEV beskriver en gruppe af samme CPU-type værter, der deler den samme lagerplads [f.eks. via netværk] og bruger til at udføre specifikke opgaver [f.eks. Høj tilgængelighed ]

Klyngedannelse har generelt mange yderligere opgaver, du kan tjekke artiklen, der forklarer Hvad er klyngedannelse og fordele/ulemper ved det.

Den største fordel ved klyngedannelse i RHEV er at aktivere og administrere virtuelle maskiner migration mellem værter, der hører til den samme klynge.

RHEV har to strategier:

1. Live migration
2. Høj tilgængelighed

Live migrering brugt i ikke-kritisk situation, hvilket betyder, at alt fungerer fint generelt, men du skal udføre nogle belastningsbalanceringsopgaver (f.eks. At du fandt ud af, at der er vært, der indlæses af en virtuel maskine over en anden. Så du kan muligvis Live-migrere virtuel maskine fra værten til en anden for at opnå belastningsafbalancering).

Bemærk: Der er ingen afbrydelse af tjenester, applikationer eller brugere, der kører i VM under Live Migration. Live migration kaldes også som ressourcetildeling.

Live migration kan behandles manuelt eller automatisk i henhold til foruddefineret politik:

  1. Manuelt: Tving valg af destinationsværten, og migrer derefter VM til den manuelt ved hjælp af WUI.
  2. Automatisk: Brug af en af Cluster-politikker til at styre Live-migrering i henhold til RAM-brug, CPU-udnyttelse osv.

Skift til fanen Klynger, og vælg Klynge1, klik på rediger.

Fra vinduesfaner skal du skifte til Cluster Policy-fanen.

Vælg jævnt fordelt politik. Denne politik giver dig mulighed for at konfigurere den maksimale tærskel for CPU-udnyttelse på værten og den tilladte tid til belastningen, før du starter Live-migrering.

Antydning

Som vist konfigurerede jeg den maksimale tærskel til at være 50% og varigheden til at være 1 min.

Derefter OK, og skift til VM-fanen.

Vælg Linux vm [Tidligere oprettet], klik derefter på rediger og kontroller disse punkter.

1. Fra fanen Host: Kontroller manuel og automatisk live-migrering er tilladt for denne VM.

2. Fra HA-fanen: Kontroller prioritetsgraden på din virtuelle maskine. I vores tilfælde er det ikke meget vigtigt, da vi kun spiller med en VM. Men det vil være vigtigt at indstille prioriteter for dine vms i store omgivelser.

Start derefter Linux VM.

Først bruger vi den manuelt levende migrering. Linux VM kører nu på rhel.mydomain.org.

Lad os køre følgende kommando over vm-konsol, før migrering startes.

# ls -lRZ /

Vælg derefter Linux VM, og klik på Migrate.

Hvis du vælger automatisk, vil systemet kontrollere den mest ansvarlige vært, der skal være destination under klyngepolitikken. Vi tester dette uden indblanding fra administratoren.

Så efter at have valgt manuelt og vælg destinationen, skal du klikke på OK og gå til konsol og overvåge den kørende kommando. Du kan også kontrollere vm-status.

Det kan være nødvendigt at overvåge opgavehændelser.

Efter et par sekunder finder du en ændring i han vm værtsnavn.

Din virtuelle computer overføres manuelt med succes !!

Lad os prøve automatisk Live Migration, vores mål er at gøre CPU-belastning på rhevhn1-værten overskredet 50%. Vi gør det ved at øge belastningen på selve vm'en, så skriv fra kommando denne kommando:

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

og overvåge belastningen på værten.

Efter få minutter vil belastningen på værten overstige 50%.

Vent bare et par minutter mere, så starter live migrering automatisk som vist.

Du kan også kontrollere fanen Opgaver, og efter lidt ventetid bliver din virtuelle maskine automatisk Live Migrated to rhel Host.

Vigtigt: Sørg for, at en af dine værter har ressourcer mere end den anden. Hvis de to værter har samme ressourcer. VM migreres ikke, fordi der ikke er nogen forskel !!

Tip: At sætte værten i vedligeholdelsestilstand vil automatisk live migrering køre VM'er til andre værter i samme klynge.

For yderligere oplysninger om VM-migreringer, læs Migrering af virtuelle maskiner mellem værter.

Tip: Live migrering mellem forskellige klynger understøttes ikke officielt, forvent et tilfælde, du kan tjekke det her.

I modsætning til Live Migration bruges HA til at dække kritisk situation ikke kun belastningsbalanceringsopgaver. Det almindelige afsnit, som din VM også migrerer til en anden vært, men med genstartstid.

Hvis du har fiasko, ikke-operationel eller ikke-responsiv vært i din klynge, kan Live Migration ikke hjælpe dig. HA slukker den virtuelle maskine og genstarter den på en anden igangværende vært i samme klynge.

For at aktivere HA i dit miljø skal du have mindst en strømstyringsenhed [f.eks. afbryder] i dit miljø.

Desværre er vi ikke i stand til at gøre det i vores virtuelle miljø. Så for mere om HA i RHEV, bedes du tjekke Forbedring af Uptime med VM høj tilgængelighed.

Husk: Live migration og høj tilgængelighed arbejder med værter i samme klynge med samme type CPU og forbundet til delt lager.

Konklusion:

Vi nåede højdepunktet i vores serie, da vi diskuterede et af de vigtige træk i RHEV Clustering, da vi beskrev det og dets betydning. Vi diskuterede også den anden type [metode] til implementering af RHEV-hypervisorer, der er baseret på RHEL [mindst 6,6 x86_64].

I næste artikel vil vi være i stand til at foretage nogle operationer på virtuelle maskiner såsom snapshots, forsegling, kloning, eksport og pools.