Innledning

Så langt i denne serien, har jeg vandret deg gjennom prosessen med å bygge en geografisk spredt klynge ved hjelp av Windows Server 2012. Selv om Klyngen er komplett og skal være funksjonell på dette punktet, er det en rekke av rene opp oppgaver som du kanskje ønsker å utføre på den nye klyngen. I denne artikkelen vil jeg konkludere serien ved å diskutere noen av disse rydde opp oppgaver.

Bli kvitt en advarsel

En rydde opp oppgave som jeg anbefaler sterkt innebærer å bli kvitt en advarsel meldingen som vises i Failover Cluster Manager. Den advarselen doesn ’ t faktisk vondt noe, men jeg personlig synes det å være litt forstyrrende, og det kan også vise seg å være forvirrende for andre administratorer som kanskje ikke er fullt så kjent med klyngen ’ s konfigurasjon
<. p> Som du kanskje husker fra tidligere artikler i denne serien, bygget vi en Windows Server 2012 basert geo klynge der ingen delt lagring ble brukt. Snarere enn å feste klyngenoder til en klynge delt volum, som kan være tilfelle for en på premisset klynge, bruker hver klyngenode Direct Attached Storage. Lagrings innholdet er replikert til hver klynge node slik at hver node i klyngen har samme syn på den underliggende lagrings

På grunn av denne konfigurasjonen, må vår klynge være klargjort med flere klase disker &ndash.; én klynge disk for hver lagring node. Problemet med denne konfigurasjonen er at Failover Cluster Manager vil bare gjenkjenne en enkelt klynge disk er tilkoblet. Klyngen disk som er knyttet til den aktive klyngenode vil bli oppført som å være online. Alle de andre klynge diskene vil bli vist med en frakoblet status. Videre vises det en melding i konsollen ’ s Information kolonne indikerer at “ cluster lagring er ikke koblet til noden ”.

Igjen, dette isn ’ t faktisk et problem. Tilstanden finnes av design. Selv så har jeg alltid tenkt at det er best å bli kvitt noen falske eller villedende feilmeldinger når det er mulig fordi de noen ganger kan ta oppmerksomheten bort fra reelle forhold som kan eksistere. Heldigvis, det er en enkel måte å fjerne denne meldingen.

For å bli kvitt meldingen, høyreklikk på den og velg Egenskaper kommando fra den resulterende hurtigmenyen. Når du gjør det, vil egenskapene arket for den valgte klyngen disk vises. På dette punktet, bør du gå til kategorien avhengigheter. Nå må du gå til kategorien ’ s Resource kolonnen og velger IP-adressen for den klyngenode som er tilknyttet klyngen disken som du har valgt. Dette er i utgangspunktet en måte å fortelle Windows at det er en sammenheng mellom den valgte klyngen noden og den valgte klyngen disken. Klikk OK for å lagre endringene.

Du må gjenta denne prosedyren for hver klynge disk som brukes av klyngen. Når du har gjort det, vil klyngen forstå når hver klynge disk bør og ikke bør være online. Du vant ’ t se Failover Cluster Manager-erkjenner endringene umiddelbart, men når den neste failover skjer (selv om det er en manuell failover), vil advarslene om klyngen lagring ikke blir koblet til noden gå bort
I tilfelle du lurer på hvorfor advarselen fortsetter å vises før etter neste failover, er det fordi Failover Cluster Manager er egentlig bare vise den siste statusmelding. Den eneste måten å fjerne meldingen er å gi en statusendring, og den enkleste måten å gjøre det på er å sette i gang en mislykkes over.

Sikring Cluster Communications

En oppgave som jeg anbefaler å utføre er at for å sikre kommunikasjonen mellom klyngenoder. Tro det eller ei, er intra klase kommunikasjon ikke er kryptert eller godkjent som standard. Dette kan ikke være et problem hvis klynge trafikken flyter over et dedikert nettverk ryggrad segmentet, men en multi-site klynge som den som vi har vært å bygge hele denne artikkelserien kan potensielt passere klynge trafikk gjennom et offentlig nettverk. Som sådan, er det en god idé å heve sikkerhetsnivået i klyngen.

Du kan enkelt gjøre dette via Windows Powershell. Kommandoen som brukes for å heve klyngen ’ s sikkerhetsnivået er:

Get-Cluster | Foreach-Object {$ _. Sikkerhetsnivå = 2}

Cluster Heartbeat Betraktninger

Et annet hensyn som du bør ta hensyn til din multi-site klyngen er nettverket ventetid mellom de to stedene. Grunnen til at dette er viktig er fordi Windows overvåker klyngen ’ s helse gjennom bruk av hjerteslag. For alle praktiske formål, er et hjerteslag en signale fyrtårn som cluster noder sende til hverandre som en måte å bevise at de ulike nodene er i live og responsive.

Som standard klyngen hjerteslag mekanisme kan fungere på nettverk med en rundtur ventetid på opp til 500 millisekunder. Videre Windows fullt forventer at det kan være situasjoner der høyere latens tider øyeblikk opplevd. Som sådan, vant Windows ’ t anta at en klyngenode er død rett og slett fordi et blunk har vært savnet. Faktisk vant Windows ’ t starte failover prosessen med mindre tre livstegn på rad gå mangler. Dette betyr at et nettverk kan i teorien oppleve en rundtur ventetid på i underkant av 1500 millisekunder uten en failover utløses.

I de fleste situasjoner standard hjerteslag frekvensen vil være helt tilstrekkelig. Men de som forsøker å drive en multi-site klynge over en ekstremt høy latency nettverk kan oppleve at de trenger å justere ventetid frekvens for å holde failover oppstår som følge av treg WAN ytelse.

Før jeg vise deg hvordan du justerer hjerteslag frekvens, jeg trenger å forklare at du bare skal justere hjerteslag frekvens hvis det er absolutt nødvendig. Grunnen til dette er at hvis du tillater for høyere latency så du også forlenge tiden som må gå etter en feil oppstår før en failover er igangsatt. Det er viktig å sørge for at verdien som du bruker plass nettverks ventetid, men uten å forårsake store forsinkelser i failover innvielse.

Det er to måter du kan justere klyngen å gjøre rede for høy latency nettverk. Ett alternativ er å øke antall hjerteslag som kan være savnet før en failover utløses. For eksempel hvis du ønsket å tillate 10 hjerteslag å bli savnet så kan du bruke følgende kommando:

$ klynge = Get-Cluster
$ Cluster.CrossSubnetThreshold = 10;

Det andre alternativet er å justere antall millisekunder som brukes for hjerteslag. For eksempel, hvis du ønsket å konfigurere klyngen å bruke en andre (1 000 millisekund) livstegn, kan du bruke denne kommandoen:

$ klynge = Get-Cluster
$ klynge. CrossSubnetDelay = tusen

Det er verdt å merke seg at disse endringene trer i kraft umiddelbart. Det er ikke nødvendig å starte klyngenoder. Windows replikerer også endringene i hele klyngen, slik at du don ’. T trenger å bekymre deg om å gjøre endringer i den enkelte klyngenode

Hvis du ønsker å sjekke verdiene av CrossSubnetDelay eller CrossSubnetThreshold variablene du kan gjøre så når som helst ved å bruke følgende kommando:

Get-Cluster | FL *

Konklusjon

I denne artikkelen har jeg forklart at det finnes en rekke spesielle hensyn som må tas i betraktning når du bygger et multi-site klynge. Som en generell regel er det best å unngå bruk av delt lagring i multi-site klynger, spesielt når områdene er atskilt med en langsom WAN-kobling. Anmeldelser