Konfiguration af Microsoft-klyngesæt på Dell PowerEdge

Klyngesæt, der introduceres i Windows Server 2019 (WS19), forbedrer SDDC-fleksibiliteten (softwaredefineret datacenter) og robusthed. Klyngesæt er en teknologi, der gør det muligt for administratorer at kombinere flere Windows 2019-klynger i en enkelt paraply af klynger.

Eksisterende failover-klynger kan rumme maksimalt 64 noder. Klyngesætteknologi kombinerer flere WS19-klynger i et enkelt domæne, hvor hver af disse klynger understøtter op til 64 WS19-noder. Sammenlignet med en failover-klynge har klyngesættet mere robust. En 4-node-failover-klynge kan f.eks. overleve en 2-node-fejl. Med den samme klynge med 4 noder, hvis vi opdeler i to 2-node-klynger og danner et klyngesæt ud af den, kan den overleve en klyngefejl plus en nodefejl fra den resterende klynge. Så den kan klare 3 nodefejl i alt.

Du kan se en oversigt over funktionen Klyngesæt i Server 2019 ved at se "Introduction-to-cluster-sets-in-windows-server-2019" og "Klyngesæt". Klyngesæt får sin fleksibilitet ved hjælp af en underliggende teknologi kaldet Infrastructure Scale-Out File Server. Dette letter også migreringen af VM'er på tværs af klynger i klyngesættet.

Lab-opsætning til implementering af klyngesæt på PowerEdge

Anvendte servere: To PowerEdge R730XD'er og to PowerEdge R740XD'er

Oprettede den første klynge ved hjælp af de to R730XD'er og navngivet S2D13G54 (kaldet Medlemsklynge 1).

Oprettede den anden klynge ved hjælp af de to R740XD'er og navngivet S2D14G54 (kaldet Medlemsklynge 2).

Der er oprettet to CSV-diskenheder på hver af de ovenfor oprettede klynger.

Oprettede en VM 'vm1' på Member Cluster 1 og en VM 'vm2' på Member Cluster 2. Derefter kombinerede jeg disse to VM'er for at oprette en administrationsklynge (navngivet mgClus54) for klyngesættet. No delt lager er påkrævet ved oprettelse af administrationsklyngen.

Har installeret rollen Filtjenester i hver af noderne i Medlemsklyng 1, Medlemsklyng 2 og Management Cluster:

Install-WindowsFeature File-Services -IncludeAllSubFeature –IncludeManagementTools –Restart

Oprettede en infrastrukturs SOFS-filserver på Member Cluster 1, Member Cluster 2 og Management Cluster:

Add-ClusterScaleOutFileServerRole -Navn på <infrastrukturens SOFS> -Infrastruktur

 

Der er oprettet et klyngesæt med navnet CLUSSET54:

New-ClusterSet -Name CLUSSET54 -NamespaceRoot <Management Cluster SOFS Name> -CimSession <CIM session to Management Cluster>

 

Føj derefter den oprettede S2D14G54 og S2D13G54 klynge til klyngen til ClusterSet:

Add-ClusterSetOf -ClusterName S2D14G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Name of SOFS created on S2D14G54 cluster>

 

Add-ClusterSetKlient -ClusterName S2D13G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Name of SOFS created on S2D13G54 cluster>

 

 

 

Derefter implementerer jeg to VM'er v213G og V214G på henholdsvis Member Cluster 1 og Member Cluster 2 og registrerer VM'erne på klyngesættet:

Get-ClusterSetDescriptor -ClusterName <Cluster Name> | Register-ClusterSetVM -VMName <VM Name>

 
For testing live migration på tværs af klynger, forsøgte jeg at migrere VM "V213G" til Member Cluster 2. Før du udfører migrering på tværs af klynger, skal vi overveje følgende punkter:

1. 1. VM-indstillinger, processorkompatibilitet skal være aktiveret.
   2. Konfigurere Kerberos-begrænset delegering (KCD) mellem alle par af crossklyngenoder
      1. Begrænset uddelegeringsvejledning fra Microsoft Hyper-V-produktteamet vil være nyttig ved opsætningen.
      2. Konfigurer den virtuelle maskines live migreringsgodkendelsestype på tværs af klynger til Kerberos på hver node i klyngesættet.

foreach($h i $hosts){Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -computernavn $h }

1. 1. 3. Føj administrationsklyngen til den lokale administratorgruppe på hver node i klyngesættet.

foreach($h i $hosts){ Invoke-Command -Computername $h -ScriptBlock {Net localgroup administrators /add <management_cluster_name>$} }

 

For at udføre enhver vedligeholdelsesaktivitet for en klynge i klyngesættet skal du migrere alle DE VM'er, der er en del af klyngen, til andre klynger i klyngesættet og derefter fjerne klyngen fra klyngesættet:

 

Remove-ClusterSet Påklyngenavn <ClusterName> -CimSession Session <oprettet for ClusterSet>

 

Når du har udført vedligeholdelsesaktiviteten, skal du føje klyngen til klyngesættet igen.

 

I tilfælde af uventet fejl i en medlemsklynge er klyngesættet ikke intelligent nok til at håndtere fail-over. Det er kun manuel flytning af ressourcer fra en klynge til en anden klynge, der understøttes i Windows Server 2019, selvom enmatic VM-failover fortsat fungerer inden for et klyngeomfang for et enkelt medlem.

 

 

 

 

 

 

 

 

 

 

 

Eksisterende failover-klynger kan rumme maksimalt 64 noder. Klyngesætteknologi kombinerer flere WS19-klynger i et enkelt domæne, hvor hver af disse klynger understøtter op til 64 WS19-noder. Sammenlignet med en failover-klynge har klyngesættet mere robust. En 4-node-failover-klynge kan f.eks. overleve en 2-node-fejl. Med den samme klynge med 4 noder, hvis vi opdeler i to 2-node-klynger og danner et klyngesæt ud af den, kan den overleve en klyngefejl plus en nodefejl fra den resterende klynge. Så den kan klare 3 nodefejl i alt.

Når du har udført vedligeholdelsesaktiviteten, skal du føje klyngen til klyngesættet igen.

 

I tilfælde af uventet fejl i en medlemsklynge er klyngesættet ikke intelligent nok til at håndtere fail-over. Kun manuel flytning af ressourcer fra en klynge til en anden klynge understøttes i Windows Server 2019. selvom automatisk VM-failover fortsat fungerer inden for et enkelt medlems klyngeomfang.