Beste werkwijzen voor Exchange Server DAG

Beste werkwijzen voor Exchange Server DAG

Als u een single-server installatie van Exchange Server gebruikt en er treedt een probleem op op de server, dan is de server niet beschikbaar. Een server- of servicestoring kan resulteren in business downtime en andere negatieve gevolgen. Om een hoge beschikbaarheid en betrouwbaarheid te garanderen, kunt u een database beschikbaarheidsgroep (DAG) opzetten. In deze configuratie hebt u twee of meer Exchange Server-servers.

Zodra een databasebeschikbaarheidsgroep (DAG) is geconfigureerd, werken de servers in het cluster samen om de postbusdatabases te repliceren, waarbij één database actief is en de andere servers een kopie van de database hosten die continu wordt gerepliceerd. Dit zorgt voor een automatische failover van data en services in het geval van een serverstoring.

Belangrijkste kenmerken van de Database Availability Group (DAG)

Hieronder vindt u enkele belangrijke kenmerken waarmee u rekening moet houden bij het plannen van een systeem met hoge beschikbaarheid om uw Exchange Server te beschermen.

Automatische failover: Als een van de servers uitvalt of als de actieve node uitvalt, neemt een andere server in de groep de services of data over.

Redundantie: De servers kopiëren de actieve database naar alle knooppunten op meerdere servers om de veerkracht van de data te vergroten. In het geval van een storing, dient een kopie van de database als de actieve kopie.

Quorumsysteem: De Database Availability Group (DAG) gebruikt een clustergebaseerd quorum met ten minste drie leden. Twee hiervan kunnen Exchange-servers zijn en de andere kan een harde schijf of een bestandsshare-getuige zijn. Dit bepaalt de actieve kopie met een meerderheid van stemmen en handhaaft de integriteit van het cluster om split-brain scenario’s te voorkomen waarbij twee nodes als actieve servers kunnen fungeren.

Best practices voor de Exchange Server database beschikbaarheidsgroep (DAG)

Laten we enkele best practices bespreken die u kunt volgen met een database beschikbaarheidsgroep (DAG).

Zorgvuldige planning en ontwerp

Wanneer u besluit te migreren van een configuratie met één server naar een DAG-configuratie, moeten de infrastructuur en servers goed worden gepland om maximale efficiëntie te garanderen en toekomstige problemen te voorkomen.

Overwegingen met betrekking tot het aantal servers en Active Directory

Als u een cluster gebruikt om quorum en stemmeerderheid te bereiken, moet u ervoor zorgen dat er ten minste drie nodes zijn met een oneven aantal servers. Dit betekent niet dat er drie Exchange-servers moeten zijn, aangezien een van de nodes een schijfcertificaat (op het SAN of de server) of een bestandsdeelcertificaat kan zijn. Afhankelijk van uw hardwareconfiguratie moet u hier rekening mee houden, aangezien u ervoor moet zorgen dat als één hele site uitvalt, de andere site onafhankelijk blijft werken.

Aangezien de volledige Exchange Server-configuratie, samen met de clusterconfiguratie, zich in het Active Directory-schema bevindt, moet u ervoor zorgen dat Active Directory fail-safe is. U kunt twee of meer ” ” in elke serverruimte of datacenter implementeren om de fail-safe veiligheid van Active Directory services te garanderen.

Hardware- en softwareconsistentie

Als u een cluster met een database beschikbaarheidsgroep (DAG) hebt, moet u ervoor zorgen dat de hardwareconfiguratie van de clusterknooppunten identiek is. Dit omvat de grootte van de stations en de stationsletters. Anders zullen er inconsistenties in de configuratie optreden tijdens geplande of ongeplande service- en gegevensfailover, wat kan leiden tot ongewenste uitval en beschadiging van data.

Het besturingssysteem moet op alle knooppunten identiek zijn. De besturingssysteemconfiguratie en updatestatus moeten ook identiek zijn. Dit zorgt voor een foutloos cluster en voorkomt problemen tijdens een failover.

Serveropslag

Bij het plannen van opslag op de knooppunten moet u rekening houden met mogelijke foutbronnen. Bij het plannen van opslag moet u niet vertrouwen op de harde schijf van de server. U kunt een RAID-systeem of een JBOD (Just a Bunch of Disks) implementeren. Dit biedt extra bescherming als een schijf op de server defect raakt.

Netwerkconfiguratie en failover

U hebt een solide en sterke netwerkbasis nodig om dataoverdracht en connectiviteit tussen servers te ondersteunen (via site-to-site VPN of glasvezelnetwerk) en om vertragingen in datareplicatie en split-brain scenario’s te voorkomen.

Meerdere netwerkkaarten

Een server moet meerdere netwerkkaarten hebben. Deze kunnen gecombineerd worden tot een team en functioneren als één kaart terwijl ze verbonden zijn met meerdere netwerkswitches. Als een netwerkswitch uitvalt of een poort defect is, zullen er geen verbindingsonderbrekingen zijn. U moet ook één team van netwerkkaarten instellen voor clientverbinding (MAPI-verkeer) en een ander team voor clusterservice en datareplicatie (protocoloverdracht).

Optimalisaties van het replicatienetwerk

Hoewel dit niet vereist is, zou het ideaal zijn om de routering tussen knooppunten te verbeteren. U kunt netwerksubnetten en VLAN’s splitsen. Dit zorgt ervoor dat alleen Exchange Server-verkeer wordt doorgelaten en voorkomt netwerkcongestie. U kunt ook een statische netwerkrouter implementeren om onnodig verkeer te vermijden en voor kortere communicatietijden te zorgen.

Als u een Exchange Server-service hebt (tenzij dit expliciet vereist is), moet u IPv6 uitschakelen op de DAG-netwerken om mogelijke verbindingsproblemen te voorkomen.

Automatische databasedistributie en activering

Als u een standaard Exchange Server-licentie hebt, hebt u recht op vijf databases. De Enterprise-licentie daarentegen biedt een onbeperkt aantal databases.

Voorkeur voor activering

U moet verschillende databases aan verschillende servers toewijzen en de prioriteit en activeringsvoorkeur instellen. Dit verdeelt de belasting en kent prioriteit toe aan de server in het geval van een storing.

Vertraagde databasekopieën

In het geval van data beschadiging kan gelijktijdige replicatie van alle databases resulteren in data beschadiging in de hele groep. Als u een server hebt die een kopie van de database host, kunt u vertraagde kopieën instellen die niet continu worden gerepliceerd, maar alleen volgens een ingesteld schema. Als een database beschadigd raakt, hebt u mogelijk een veilige kopie die vlak voor de beschadiging werd gemaakt.

Bewaking en onderhoud

Een failover-systeem is nutteloos als het niet wordt bewaakt. Het wordt aanbevolen om uw back-ups dagelijks te controleren en maandelijks terug te zetten. Het is ook belangrijk om de servers te controleren op opslagruimte, prestaties en fouten. U kunt een monitoringtool instellen die u waarschuwt als er iets gebeurt.

U moet de patchcyclus plannen en groepsleden één voor één bijwerken. Tests moeten voor en na het patchen worden uitgevoerd om ervoor te zorgen dat de functionaliteit of werking niet wordt beïnvloed.

Recovery na een storing

Er is sprake van een emergency als de server volledig crasht. Maar misconfiguraties, onverwachte problemen, patchproblemen en menselijke fouten kunnen data verknoeien of ervoor zorgen dat servers niet meer kunnen repliceren. Daarom moet u ervoor zorgen dat er back-ups zijn, dat er disaster recovery-tests worden uitgevoerd om te zorgen dat het failover-proces werkt en dat u over de juiste hulpmiddelen beschikt.

Als er een storing optreedt in data, moet u twee maatregelen nemen. Ten eerste moet u de data terugzetten vanaf de back-up en ten tweede moet u een speciaal hulpprogramma gebruiken om Exchange-databases te herstellen. Hoewel het terugzetten van de database werkt, moet u rekening houden met de benodigde tijd en middelen en het dataverlies tussen het moment dat de back-up werd gemaakt en de serverstoring. Gespecialiseerde Exchange hersteltools van derden kunnen daarentegen helpen de impact te minimaliseren, zorgen voor data recovery zonder terugzetten vanaf de back-up, en de hersteltijd verkorten.

Stellar Repair for Exchange is zo’n Exchange recovery-hulpprogramma dat elke versie van de Exchange Server-database gemakkelijk kan openen, ongeacht de grootte en staat ervan. Na een snelle of grondige scan van de database kunt u gebruikerspostvakken, gebruikersarchieven, openbare mappen, gedeelde postvakken en uitgeschakelde postvakken granulair exporteren naar PST en andere bestandsformaten. U kunt de data uit het EDB-bestand ook rechtstreeks naar een actieve Exchange Server-database exporteren, waarbij mailboxen automatisch in kaart worden gebracht en prioriteiten en parallelle export mogelijk zijn. Met de tool kunt u ook data exporteren naar een Microsoft 365-tenant.

Conclusie

Zoals u hierboven hebt gezien, hebben we enkele best practices besproken die u kunt volgen bij het opzetten van een database beschikbaarheidsgroep (DAG). Een succesvolle opstelling vereist echter een goede planning. Voortdurende bewaking en onderhoud van de servers en de opstelling is essentieel voor een storingsvrij cluster. Het is erg belangrijk om een fail-safe systeem te hebben om business continuïteit en data recovery te garanderen in het geval van een ramp. In het geval van een ramp moet u over de juiste hulpmiddelen beschikken om uw data te herstellen, terwijl de downtime en de impact op de business minimaal blijven.


Dit is een ingezonden bijdrage van Bharat Bhushan, Technical Marketer bij Stellar Data Recovery Inc. Klik hier voor meer informatie over de oplossingen van het bedrijf.