Exchange – Het voorkomen van ‘split brain’

Wat is split brain?

Als u gebruik maakt van de Exchange database High Availability en Distaster Recovery technieken zoals cluster-replicatie (Exchange 2007) of Database Availability Groups (Exchange 2010), kunt u uitstekend uw databases beveiligen door een of meerdere kopieën te maken op een of meerdere fysieke of virtuele servers.

Een server is de “eigenaar” van de database en verwerkt alle wijzigingen in de master-copy, terwijl een tweede server de mutaties ontvangt en deze verwerkt in de stand-by kopie.

Klik op het plaatje voor vergroting.

Het is van groot belang dat slechts één kopie van de gegevens actief is en gemuteerd wordt. De tweede server is altijd een exacte replica van de eerste en kan op worden teruggevallen als de eerste server niet langer beschikbaar is. Echter, wanneer beide kopieën, om wat voor reden dan ook, actief worden en naar beiden weggeschreven wordt, ontstaat een situatie die “split brain” wordt genoemd.

Split brain betekent dus dat er twee ongelijke kopieën van de gegevens (twee “hersenen”) zijn waarbij niet kan worden vastgesteld welke de juiste is. Aangezien Exchange geen mechanisme heeft om de wijzigingen tussen de twee exemplaren te vergelijken en samen te voegen, zijn de herstelopties vrij beperkt. Vaak is de enige mogelijkheid het probleem te accepteren door één kopie te kiezen als hoofdkopie en waarschijnlijk alle gemaakte wijzigingen in de tweede kopie te verliezen.

Voorzieningen in Exchange

Exchange heeft een aantal voorzieningen ingebouwd om “split brain” te voorkomen. De eerste heet “quorum” en is een functie van de onderliggende Windows Clustering-technologie. Quorum betekent dat de server, voordat een database kan worden geactiveerd, quorum (of “meerderheid”) moet behalen. Bij een cluster met shared storage kan dit een quorum-schijf zijn die gedeeld wordt door beide servers. Meer gebruikelijk bij Exchange 2010 Database Availability Groups of bij een geografisch verspreid cluster over twee locaties, is het hebben van “file-share witness”. Dit is een standaard Windows-server met een gedeelde map, die toegankelijk is voor beide database servers, waarin de huidige status van elke server en database wordt vastgelegd.

Klik op het plaatje voor vergroting.

Beide methoden werken in feite op dezelfde manier: “akkoord” gaan met één van de twee database servers dat die eigenaar van de gegevens is omdat die de meerderheid heeft, ofwel quorum. Bijvoorbeeld de file-share witness server en de database server geeft twee stemmen; tegenover de tweede database server met slechts een stem. Als de eerste database server down gaat, maar file-share witness niet, dan kan een nieuw quorum worden bereikt door samen te werken met de tweede database server. Deze heeft een kopie van de gegevens en staat de database toe te switchen naar die tweede server.

Klik op het plaatje voor vergroting.

Bij het scenario waar een heel datacenter down gaat, en dus zowel de witness server en de eerste database server niet bereikbaar zijn, kan een quorum niet meer worden bereikt. De tweede server moet dan handmatig worden “gedwongen” quorum te bereiken voordat is toegestaan een database te activeren.

Stelt u zich een scenario voor waar de eigenaar van de actieve database en de file-share witness in hetzelfde fysieke datacenter aanwezig zijn, waarbij de tweede kopie van een Exchange database gerepliceerd wordt naar een DR datacenter. Wanneer de WAN link tussen de twee datacenters down gaat, kan de tweede Exchange server er ten onrechte van uitgaan dat de eerste server gecrashed is en omdat deze niet langer te bereiken is, denkt hij daardoor een back-up van de database te moeten activeren. Als dat toegestaan wordt en de WAN link komt weer online dan zouden de beiden servers hun databases gelijktijdig actief hebben. Beiden kunnen mutaties uitvoeren op de data en dat is natuurlijk niet toegestaan. Gelukkig kon de tweede server niet bij de file-share witness toen de WAN link down ging. Hierdoor had het geen toestemming om een kopie van de database te activeren.

Quorum niet waterdicht

Het quorum principe is niet 100% waterdicht. Bijvoorbeeld wat gebeurt er als iemand de netwerkkabels loskoppelt van de eerste database server of als een switch-poort per ongeluk wordt uitgeschakeld? De witness-server draait nog steeds en ook de tweede Exchange server met de kopie. Beide servers kunnen de eerste Exchange server met de actieve database dan niet meer zien of bereiken en als zodanig veronderstellen dat de server down is. De witness server kan, samen met de tweede database server, een nieuw quorum vormen en de tweede server activeert zijn kopie van de database. Zodra de netwerkverbinding van de eerste server, die nooit echt down is geweest, weer online komt, ontstaat een mogelijke “split brain” situatie. Als u gescheiden datacenter- en client-netwerksegmenten heeft is het risico nog hoger, omdat clients nog steeds verbinding kunnen maken met en te werken op de eerste databasekopie. Tegelijkertijd kunnen de witness-server en de tweede database server denken dat de eerste databasekopie down is.

In een gevirtualiseerde omgeving nemen de risico’s drastisch toe. Een virtuele netwerkpoort op de eerste Exchange server kan worden uitgeschakeld en weer worden aangeschakeld nadat een fail-over heeft plaatsgevonden naar de tweede server.

Een ander recent praktijkvoorbeeld is dat een SAN werd herstart, terwijl de eerste Exchange-server nog actief was. De Exchange-server was gevirtualiseerd met VMware, en VMware besloot de virtual machine tijdelijk te “pauzeren” totdat de opslag weer online kwam. De file-share witness werd echter niet gepauzeerd en een fail-over naar de tweede server werd automatisch uitgevoerd. Nadat het SAN opnieuw was gestart en VMware constateerde dat het weer “gezond” was, werd automatisch de eerste Exchange server hervat. Deze server was echter niet op de hoogte van alles wat er sindsdien gebeurd was. De server dacht dat de tijd gestopt was en dat de database nog steeds voor hem actief was, terwijl deze tijdens een mutatie onderbroken werd. Dit resulteerde in een corrupte database te wijten aan “split-brain”.

Een ander scenario is een switch van een Exchange-omgeving naar een tweede datacenter als gevolg van een stroomstoring in de eerste. Wanneer de spanning terugkomt kan de Exchange server opgestart worden voordat de WAN-verbinding weer actief is. Aangezien deze zich in het primaire datacenter bevindt, die ook de witness-server host, ontvangt de Exchange server automatisch quorum. Omdat het de andere Exchange server niet kan zien denkt de sever vervolgens dat het veilig is om de database te activeren.

Oplossingen

Een aantal opties bestaat die dergelijke scenario’s kan voorkomen:

Microsoft heeft een DAC eigenschap (Database Activation Coordination) toegevoegd aan Exchange. Deze zegt Exchange om eerst een check uit te voeren met andere database servers voordat de database wordt geactiveerd, en niet alleen op quorum te vertrouwen. Aangezien DAC wordt gezet in het geheugen van de server wordt het automatisch gewist als de server opnieuw wordt gestart en dit forceert de server om elke keer een re-check te doen.

Een eenvoudige methode om “split brain” te voorkomen is de tweede Exchange database server te “vertellen” dat het nooit is toegestaan om databases te activeren. Dit kan worden gedaan met Power Shell. Dit voorkomt elke automatische fail-over totdat de tweede server “unblocked” is, terwijl replicatie tussen de twee servers nog steeds toegestaan is. DAC is dan nog steeds van belang om split-brain te voorkomen tijdens fail-back-activiteiten.

Een andere optie in een gevirtualiseerde omgeving, is het configureren van de hypervisor zodat een Exchange server niet pauzeert wanneer het detecteert dat zijn opslag niet langer beschikbaar is, maar “crashed”. Dit forceert een reboot, zodat eigenlijk het gedrag van een meer traditionele fysieke server geëmuleerd wordt. Als DAC wordt gebruikt, is dit gedrag extra belangrijk omdat een server “pauzeren” door de hypervisor niet de DAC-bit in het geheugen wist.

Er zijn nog meer mogelijkheden zoals het plaatsen van de witness-server in een derde datacenter of de configuratie van een alternatieve file-share witness in het tweede datacenter.

Conclusie

Geen enkele oplossing richt zich op alle scenario’s. De juiste oplossing is afhankelijk van de specifieke omstandigheden en configuratie.

“Split brain” is zeker een serieus risico die beschadiging of verlies van gegevens kan veroorzaken. Het kan vele, vele werkuren kosten om de database volledig te herstellen en moet daarom zeer serieus worden genomen. Als clustering of replicatie-technologieën van welke aard dan ook worden gebruikt, besteed dan altijd extra tijd om de risico’s en mogelijke gevolgen te onderzoeken of zoek hulp bij een expert met ervaring met dergelijke technologieën.