Waarom Exchange migreren zonder HA geen goed idee is…

Deze week is het volgende artikel verschenen op msexchange.org: How to migrate from Exchange 2007 CCR to Exchange 2010 DAG on existing hardware (Part 1) Dit artikel deed mijn wenkbrauwen fronsen, om te begrijpen waarom zal ik eerst kort uitleggen wat de strekking van het artikel is.

De auteur schetst het scenario van een bedrijf dat graag wil upgraden naar Exchange 2010 High Availability (DAG) en nu beschikt over een Exchange 2007 omgeving met daarin twee servers in een CCR opstelling. Het artikel beschrijft een methode om de hardware van het CCR cluster te kunnen hergebruiken voor Exchange 2010 en wel door de volgende stappen te nemen:

• Eén node van het Exchange 2007 CCR cluster afbreken
• De server opnieuw voorzien van een OS en Exchange 2010 installeren
• Het aanmaken van een DAG en de server lid maken van de DAG
• Mailboxen verhuizen naar de Exchange 2010 server
• De andere Exchange 2007 CCR clusternode afbreken
• De server opnieuw voorzien van een OS en Exchange 2010 installeren
• De server lid maken van de DAG en een replica van de database aanmaken

De afzonderlijke stappen in deze procedure zijn in principe goed beschreven en worden afzonderlijk volledig ondersteund door Microsoft. Waarom ik dan toch moeite heb met deze strategie? Dat is het risico wat je introduceert met deze werkwijze, dat zal ik in de volgende paragraven verder uitleggen.

Hoge beschikbaarheid

Het bedrijf heeft bij het ontwerpen van de Exchange 2007 omgeving gekozen voor hoge beschikbaarheid, namelijk door te investeren in CCR. Ik gebruik het woord investeren bewust, want CCR is een kostbare oplossing. Niet alleen stelt het eisen aan de hardware en kost het dure Exchange 2007 Server Enterprise Edition licenties, CCR brengt ook een behoorlijke complexiteit en dus beheerlast met zich mee.

Maar ook voor Exchange 2010 heeft klant weer gekozen voor hoge beschikbaarheid. Daar mag je toch uit afleiden dat de beschikbaarheid van de e-maildienst en –data van groot belang is voor deze onderneming. Hoe kan het dan dat de eerste stap in bovenstaand scenario het weghalen van hoge beschikbaarheid is? Zijn de eisen voorlopig even versoepeld? Is eventueel dataverlies nu even wat minder onacceptabel dan voor en na de migratie?

Kans op downtime

Uitval (of downtime) van de e-mail dienst komt zelden uit de lucht vallen. Natuurlijk kan er altijd compleet onverwacht een software bug optreden, maar de kans op downtime schiet toch wel omhoog wanneer er aan de omgeving gesleuteld moet worden. Installatie of deïnstallatie van componenten, DNS records, aanpassen van firewalls en proxyservers, een foutje is dan snel gemaakt. En laten dat nu juist de handelingen zijn die inherent zijn aan een upgrade naar Exchange 2010.

Tijdsdruk

De auteur verdedigt het vergroten van het risico en gemis aan hoge beschikbaarheid met het argument dat je het tijdsbestek zo kort mogelijk kunt houden. En dat brengt mij bij het volgende punt: tijdsdruk. Mijn ervaring uit de praktijk is dat een succesvolle migratie er eentje is waarbij je goed kon plannen, voorbereiden en alle stappen rustig en gecontroleerd kon laten verlopen. Dat betekent bij voorbeeld dat je na iedere ingrijpende stap even in de application logs kijkt om te zien of er problemen zijn opgetreden.

Maar een nieuwe versie van Exchange betekent ook dat je randzaken als backup en monitoring in moet regelen. Niet zelden valt dit samen met een update of zelfs upgrade van backupsoftware en soms issues met de eerste paar keren dat een backup of restore uitgevoerd wordt. Had ik anti-virus al genoemd? De mogelijkheid om met enkele gebruikers als eerste over te stappen? Herinnert iemand zich de onaangename verassingen met Outlook 2003 in combinatie met Exchange 2010 nog?

Conclusie

Concluderend kunnen we dus vaststellen dat we enerzijds ons vangnet weghalen en aan de andere kant de risico’s bewust groter maken. Het voordeel is dat je twee bestaande servers opnieuw in kunt zetten voor hun nieuwe taak. Wegen de nadelen op tegen de voordelen? Die keuze mag ieder voor zich maken. Maar zeg niet dat je niet gewaarschuwd bent.