[Exchange 2007] Mailboxen redundant met CCR, maar de rest?

[Jazzy]

Ik ben bezig met het opzetten en testen van een een redundante mailomgeving op basis van Exchange 2007. Het gaat om een kleine omgeving (<200 mailboxen) en in eerste instantie leek Cluster Continuous Replication mij ideaal om redundancy toe te voegen. Alleen is CCR alleen geschikt voor de Mailbox Role dus moet ik een extra server toevoegen voor de Hub Transport en Client Access Role.

Client Access Role can alleen met bijvoorbeeld NLB dus betekent nog eens twee extra machines, en dan houd ik de Hub Transport Role nog over! Vijf machines voor een kleine omgeving wordt echt wat al te gortig.

Wat denken jullie van dit scenario? Een zware machine toevoegen die de Hub Transprot Role gaat draaien. Daarnaast draait deze virtueel 2 maal de Client Access Role die redunant is door NLB. Eventueel kan 1 van deze VM's ook verhuizen naar een andere VMware Server die al aanwezig is.

Ben benieuwd naar jullie advies op het gebied van Exchange 2007.

Dit is geen enterprise situatie dus ik zoek naar een gezonde mix van slimme oplossingen, creativiteit en betrouwbaarheid. Helaas, ESX en een farm van blades zijn even niet aan de orde.

Met dank trouwens aan dit informatieve topic: [Exchange 2007] Hub Transport server redundancy

[Verwijderd]

ik weet niets van exchange 2007. Maar als je een hoge beschikbaarheid wilt hebben, kost dat simpelweg knaken. Dan zal je dus een afweging moeten maken of het allemaal zo moet of een iets mindere beschikbaarheid ook wel voldoet.

Virtualiseren zonder ESX helpt niet in je beschikbaarheid omhoog te brengen iig. Je krijgt met GSX zelfs 2 extra spofs...

Buiten dat, je hebt 0,0 support van microsoft als je op vmware draait. Dus als je software problemen hebt, zal je eerst het probleem moeten nabootsen op hardware, die wel gesupport wordt door MS.
Dit wordt nogal vaak vergeten bij virtualiseren...

[Jazzy]

Verwijderd schreef op dinsdag 31 juli 2007 @ 11:48:
ik weet niets van exchange 2007.

Okay.

Maar als je een hoge beschikbaarheid wilt hebben, kost dat simpelweg knaken. Dan zal je dus een afweging moeten maken of het allemaal zo moet of een iets mindere beschikbaarheid ook wel voldoet.

Virtualiseren zonder ESX helpt niet in je beschikbaarheid omhoog te brengen iig. Je krijgt met GSX zelfs 2 extra spofs...

GSX is zooooo 2004 , het heet tegenwoordig VMware Server. SPOFs zijn opgevangen met een slimme disaster recovery oplossing. Iedere server die in deze omgeving virtueel draait kan ik in no-time in de lucht bregen op de uitwijklocatie. Geen probleem en creatief opgelost met A-merk oplossingen die binnen het budget van de klant vallen. Geen ESX nodig, geen gemirrord SAN en FC infra.

Nogmaals, het gaat hier niet om een enterprise oplossing.

Buiten dat, je hebt 0,0 support van microsoft als je op vmware draait. Dus als je software problemen hebt, zal je eerst het probleem moeten nabootsen op hardware, die wel gesupport wordt door MS.
Dit wordt nogal vaak vergeten bij virtualiseren...

Niet door ons, dit is een gecalculeerd risico wat we samen met onze klant nemen. Daarnaast is iedere willekeurige machine binnen 1-3 uur te verhuizen naar een fysieke server. De procedure hiervoor wijkt per server af en staat keurig beschreven in een draaiboek, is bekend bij ons en bij de klant en bovendien: getest.

In dat kader moet je ook bovenstaande vraag zien. Hoe kun je nu op een slimme manier gebruik maken van Exchange 2007 clustering zonder een heel serverpark op te moeten tuigen. Microsoft doet al een aantal slimme stappen met LCR en CCR, nu de rest nog.

[Verwijderd]

Jazzy schreef op dinsdag 31 juli 2007 @ 13:37:
[...]
Okay.
[...]
GSX is zooooo 2004 , het heet tegenwoordig VMware Server. SPOFs zijn opgevangen met een slimme disaster recovery oplossing. Iedere server die in deze omgeving virtueel draait kan ik in no-time in de lucht bregen op de uitwijklocatie. Geen probleem en creatief opgelost met A-merk oplossingen die binnen het budget van de klant vallen. Geen ESX nodig, geen gemirrord SAN en FC infra.

Nogmaals, het gaat hier niet om een enterprise oplossing.
[...]
Niet door ons, dit is een gecalculeerd risico wat we samen met onze klant nemen. Daarnaast is iedere willekeurige machine binnen 1-3 uur te verhuizen naar een fysieke server. De procedure hiervoor wijkt per server af en staat keurig beschreven in een draaiboek, is bekend bij ons en bij de klant en bovendien: getest.

In dat kader moet je ook bovenstaande vraag zien. Hoe kun je nu op een slimme manier gebruik maken van Exchange 2007 clustering zonder een heel serverpark op te moeten tuigen. Microsoft doet al een aantal slimme stappen met LCR en CCR, nu de rest nog.

lol ik zal hier maar niet op reageren. Je doet maar...

Maar wat ik iig niet snap is dat je redundant wilt zijn en vervolgens 2 nlb nodes op 1 fysieke bak wilt gaan draaien. hier win je totaal niets mee imho. Je gooit er nu 4 spofs bij (vmware server, onderliggende os, hardware, en nlb software), maar die heb je vast door een slimme disaster recovery procedure ondervangen

[Jazzy]

Verwijderd schreef op dinsdag 31 juli 2007 @ 18:56:
Maar wat ik iig niet snap is dat je redundant wilt zijn en vervolgens 2 nlb nodes op 1 fysieke bak wilt gaan draaien. hier win je totaal niets mee imho. Je gooit er nu 4 spofs bij (vmware server, onderliggende os, hardware, en nlb software), maar die heb je vast door een slimme disaster recovery procedure ondervangen

Bedankt, maar ik had al gezegd dat 1 van deze VM's ook naar een andere server toe kan.

Wat je opmerking betreft, ik weet dat dit geen ideale situatie is maar we praten hier nu eenmaal niet over een datacenter, bank of multinational. Ik begrijp eerlijk gezegd niet echt dat je mij gaat wijzen op de kosten en dat ik misschien een andere oplossing moet kiezen zonder dat je een bruikbaar alternatief biedt. Dat is nou net die creativiteit die ik bedoelde, die je nu eenmaal nodig hebt als je slimme oplossingen wilt bieden binnen een wat minder budget.

Laat ik het anders zeggen. Voor een omgeving met 200 mailboxen zoek ik een oplossing die volledige redundancy biedt en gebruik kan maken van 2 fysieke lokaties met een snelle verbinding er tussen.

[Verwijderd]

ik ben wel gewend in grote omgevingen te werken. Dat houdt ook in dat als er een hoge redundantie ge-eist wordt er een prijskaartje aangaat hangen. De creatieve oplossingen, zoals jij ze noemt, zou ik over het algemeen pruts oplossingen noemen

Mijn kennis van exchange 2007 is helaas niet van dat niveau (ik heb alleen de cd gezien, niet eens aangeraakt zeg maar ) dat ik je een alternatief kan bieden. Ik kan je dus alleen maar wijzen op "valse" redundancy.
Heeft CCR overigens geen shared disks nodig? wat ik begrijpen had was het een soort active-active cluster.

[Verwijderd]

Nee, CCR heeft geen shared disks nodig:

No requirement for shared storage Storage for a CCR configuration does not need to be shared between the servers that make up the cluster. This makes setup easier because storage does not need to be configured for the nodes in the cluster. You can select between direct attached storage, storage area network (SAN), iSCSI, or other supported storage.

Van http://technet.microsoft.com/en-us/library/aa997928.aspx

[Jazzy]

Verwijderd schreef op woensdag 01 augustus 2007 @ 18:48:
ik ben wel gewend in grote omgevingen te werken. Dat houdt ook in dat als er een hoge redundantie ge-eist wordt er een prijskaartje aangaat hangen. De creatieve oplossingen, zoals jij ze noemt, zou ik over het algemeen pruts oplossingen noemen

Dan moet je eens een tijdje in het MKB/MKB+ gaan werken. Daar werkt het gewoon anders, je moet wat creatiever zijn soms want als je de mooiste spullen uit gaat zoeken ga je ver boven het beschikbare budget.

Geprutst wordt er zeker in deze tak van sport, absoluut. Maar dat is niet mijn bedoeling, en geloof me, ik weet wat prutswerk is. Hoewel ik eerst even moest wennen vind ik het nu wel een leuke uitdaging om meerwaarde te leveren in omgevingen van 50 tot 250 werkplekken. Het vraagt een hele andere benadering dan de enterprise oplossingen en ook weer heel anders dan de SBS omgevingen (tot pakweg 50 gebruikers).

Mijn kennis van exchange 2007 is helaas niet van dat niveau (ik heb alleen de cd gezien, niet eens aangeraakt zeg maar ) dat ik je een alternatief kan bieden. Ik kan je dus alleen maar wijzen op "valse" redundancy.

Dat waardeer ik, alleen moet je daar wel een beetje realistisch in zijn. Neem bijvoorbeeld het support verhaal. Als je 4 lichte servers kunt combineren op 1 fysieke doos met behulp van VMware Server dan bespaar je veel geld. Samen met de klant ga je dan de voor- en nadelen op een rijtje zetten en daar wordt vervolgens een keuze gemaakt. Aangezien 95 van de 100 storingen in dit soort bedrijven nooit bij Microsoft worden aangemeld zal dit nadeel niet als een showstopper worden ervaren en kies je toch voor deze oplossing.

Is dit dan prutswerk? Volgens mij niet.

Heeft CCR overigens geen shared disks nodig? wat ik begrijpen had was het een soort active-active cluster.

Nee, Cluster Continuous Replication is een active-passive clusteroplossing waarbij geen shared storage meer nodig is. Bijde nodes hebben een exemplaar van de database lokaal staan en de actieve node verstuurt telkens zijn logfile naar de passieve node. Bij uitval ben je dus maximaal 1 MB aan transactielog kwijt. Dit kun je trouwens weer opvangen door de Hub Transport servers een kopie van de afgeleverde mail te laten bijhouden, de message dumpster. Wanneer er nu een probleem is en de Exchange server verhuis van node 1 naar node 2 kan de laatste mail opnieuw worden verwerkt, Exchange 2007 detecteert zelf of er sprake is van duplicaten.

CCR is net als Local Continuous Replication (lokaal een kopie van de database aanwezig, logfile wordt steeds doorgezet naar de tweede db) SCR (komt in SP1) een nieuw pad van Microsoft waarmee ze voorzien in de behoefte aan hogere beschikbaarheid in omgevingen waar geen SAN e.d. aanwezig is. Zie het maar als een gebaar richting ons soort klanten.

Mijn plan is nu als volgt:
- voeg een Exchange 2007 server toe, standaard installatie met Client Access, Hub Transport en Mailbo rollen.
- verplaats de mailboxen en verwijder de server 2003.
- voeg een CCR cluster toe en verplaats de mailboxen hier naar toe
- nu op biede lokaties een VMware server elke een Hub Transport server en een Client Access server
- verwijder de 1e Exchange 2007 server

Beide nodes van het CCR cluster komen elk op een fysieke lokatie en beide lokaties hebben elk een Hub Transport en Client Access server. Volgens mij ben ik nu redelijk klaar. .Nog SPOFs?