Innledning

En av funksjonene i Windows Server 2012 som har forbedret det meste fra tidligere versjoner er failover clustering. Windows Server 2012 kan du bygge klynger som er mer skalerbar enn noen gang før, mens på samme tid å gi administratorer mye mer frihet til å velge en klynge design som er fornuftig for sin egen organisasjon, snarere enn å være helt låst inn i en rigid sett med krav .

Selv om det tidligere var mulig å bygge et multi-site failover cluster, gjør Windows Server 2012 geo clustering mye mer praktisk. Det er verdt å merke seg imidlertid at selv om Microsoft har gått langt for å gjøre bygge klynger enklere enn det noensinne har vært, god klynge design er viktig. En feil utformet multi-site klyngen vil trolig lider av ytelsesproblemer, og kan til slutt vise seg å være mindre enn pålitelig. Det å være tilfelle, bestemte jeg meg for å skrive denne artikkelserien som en måte å gi deg noen gode fremgangsmåter for å bygge multi-site klynger som er basert på Windows Server 2012.

Quorum Betraktninger

Jeg ønsker å starte med å snakke om en av de aspektene av multi-site clustering som tradisjonelt har vist seg å være den mest utfordrende. For at en klynge til funksjon, har det å opprettholde quorum. Dette er en fancy måte å si at et minimalt antall klase noder må være funksjonelt og tilgjengelig for at klyngen for å fungere.

Windows Server bruker vanligvis en Majority Node Set klynge. I et flertall Node Set Cluster et flertall av klase nodene må være funksjonelt for at klyngen å beholde quorum. Microsoft definerer de fleste som halvparten av klase noder, pluss en. Hvis for eksempel en Majority Node Set Cluster inneholdt fire klyngenoder deretter Windows ville definere en node flertall som tre klase noder (halvparten av klase noder pluss en ekstra node).

De fleste noden sett kravet kommer med et par implikasjoner. For det første betyr det at mindre klynger kan tolerere feil på færre noder samtidig beholde quorum. For eksempel kan en fire node cluster bare tolerere feil på en enkelt node. På den annen side kan en klynge med ti noder beholde beslutningsdyktig selv om opptil fire noder mislykkes.

Selv om klyngenode planlegging er egentlig bare et spørsmål om grunnleggende matematikk (i hvert fall i forhold til beregning av toleranse for nodefeil ), det blir litt mer interessant når du tar en flersteds arkitektur inn i bildet.

Tenk deg for eksempel at organisasjonen har en primær datasenter og en katastrofe gjenoppretting datasenter. Forestill deg nå at du bestemmer deg for å bygge en flersteds klynge for å håndtere en virksomhetskritiske applikasjon. Du ønsker å være i stand til å kjøre dette programmet i enten datasenteret, slik at du ønsker å sette nok av klase noder på hvert sted.

Som tidligere nevnt, kan et flertall Node Set klynge med ti klyngenoder overleve svikt på opp til fire noder. Med det i tankene, la ’ s late som at vi bestemte oss for å plassere fem noder i hver av de to datasentre. På den måten kan alle unntatt én av klyngenoder potensielt mislykkes i det ene av de datasentre og klyngen vil fortsatt beholde quorum.

Selv om denne arkitekturen kan ved første høres lovende ut, det er et stort problem. Tenk hva som ville skje i WAN-kobling (eller Internett-tilkobling, hvis det ’ s hva du bruker) mellom de to stedene mislyktes. I denne type situasjon, klyngenoder er ikke smart nok til å fortelle forskjellen mellom WAN-kobling svikt og en masse klyngenode fiasko.

I dette scenariet vil hver datasenter tolke WAN-kobling svikt som om alle av klyngenoder i motsatt datasenter hadde mislyktes. Med andre ord, mener hver datasenter at fem klyngenoder er nede. Husk at i en ti node cluster, seks klyngenoder må forbli på nettet for at klyngen å beholde quorum. Hvert datasenter kan bare bekrefte tilgjengeligheten av fem noder, så verken datasenter er i stand til å opprettholde quorum. Derav klynge søknaden mislykkes, selv om ikke en eneste klyngenode faktisk har mislyktes

I dette mareritt scenario, er linken WAN klyngen ’ s. Akilleshæl. Det er den som single point of failure som har potensial til å få ned hele klyngen. Spørsmålet er hvordan kan du beskytte klyngen mot denne typen ting?

Det er et par forskjellige skoler med tanke på å forebygge en WAN-kobling brudd fra å bringe ned klyngen. I det siste, har et populært alternativ vært å stable dekk i favør av en datasenteret eller det andre. For å vise deg hvordan dette fungerer, la ’ s. Gå tilbake til min tidligere eksempel på en ti node cluster som strekker seg over to datasentre

Hvis målet er å hindre en WAN-kobling svikt fra å bringe ned klyngen så ville du må plassere et ujevnt antall klase noder i hvert datasenter. En ti node cluster krever at seks noder forbli på nettet for at klyngen å beholde quorum. Derfor vil plassere seks noder i den primære datasenteret og fire noder i katastrofegjenoppretting datasenter isolere klyngen mot WAN-kobling svikt (forutsatt at alle nodene i den primære datasenteret er online på tidspunktet for svikt).

En annen skole med tanke om å beskytte en Majority Node Set klyngen mot WAN-kobling svikt er å gjøre bruk av et tredje sted. Denne arkitekturen fungerer ved å plassere halvparten av klyngenoder i organisasjonen ’ s primære datasenteret og halvparten av klase noder i et katastrofegjenoppretting datasenter. Den tredje sted doesn ’ t faktisk vert en klyngenode. I stedet, det vert en ikke-gruppert tjener som fungerer som en fildeling vitne.

En fil aksje vitne er en server som fungerer som en slags dommer i tilfelle av en WAN-kobling fiasko. For å vise deg hvordan dette fungerer, bør du vurdere vår tidligere eksempel der en organisasjon trenger for å bygge et multi-site klynge med ti klase noder. Nå la ’ s anta at vi bestemte oss for å sette fem klyngenoder i den primære datasenteret og fem klyngenoder i katastrofe datasenter

I denne ordningen alle de samme reglene gjelder.. Klyngen fortsatt krever seks noder å være tilgjengelig for at klyngen å beholde quorum. Nå antar at WAN-kobling feil oppstår. Verken datasenter har nok noder for klyngen å beholde quorum. Men alle klyngenoder vite om fildeling vitne. Derfor vil både datasentre forsøke å kontakte fildelings vitne server. Datasenteret med fungerende WAN-tilkobling skal kunne etablere kontakt, mens datasenteret med den mislykkede forbindelse bør ikke være i stand til. Når et datasenter gjør etablere kontakt med fildeling vitne, tar denne serveren i stedet for en sjette klyngenode. Ved å gjøre det, gjør det klyngen å beholde beslutningsdyktig på tross av WAN-kobling svikt.

Konklusjon

Selv cluster quorum er en svært viktig faktor for multi-site klynger, er det langt fra å være det eneste hensynet. Noen av de andre hensyn som må tas i betraktning er node lagring og tilgjengeligheten av klase ressurser. Jeg vil diskutere disse spørsmålene og mer som serien utvikler seg. Anmeldelser