Exchange 2007 | Rol verdeling

dinsdag 29 december 2009 17:41

BP_LOZ schreef op dinsdag 29 december 2009 @ 17:03:
[...]

Momenteel draaien alle rollen op 1 server, er is geen edge.
Het zijn zo'n 300 mailboxen met een mailbox grootte van 5GB. Storage loopt over iSCSI naar SAN.
De hoeveelheid mail heb ik niet zo'n kijk op, ik kan het moeilijk inschatten.

Bovenstaand plaatje is ook meer gebaseerd op de (nieuwe) security policy die gehanteerd moet gaan worden.
Daarom willen we een edge die in een DMZ komt, een CAS server voor de client connectivity en een mailbox/hub transport server voor interne mailafhandeling en mailboxen.
Dus:
Backend Mailbox & HUB
Frontend CAS
DMZ Edge

Klopt mijn laatste conclusie?

er is geen reden om met een klein aantal (ja 300 is klein) de mailbox rol te splitsen van de cas. verder is het gebruikelijk om indien er gesplitst wordt, de mailbox juist los te trekken van de cas\hub.

maak het jezelf niet moeilijk, je verstookt meer resources met het splitsen dan dat het je oplevert.

grove schatting kun je uitgaan van 1 backend server met mailbox\hub\cas. 4 cores, memory 4+(300X4)= 5 a 6 gb. daarmee kun je ruim uit de voeten. indien er ook forefront of een andere virusscanner op gaat draaien dien je er 1 a 2 gb memory bij te proppen
qua edge server kun je gewoon af met een dualcore met 2 gb geheugen, indien er veel mail voorbijkomt, of je gaat daar ook virusscannen dan 3 a 4 gb. dualcore is voldoende.

het splitsen van mailbox\hub\cas heeft in jouw situatie geen nut, ook qua veiligheid biedt het niets extras, het is dan een puur cosmetische scheiding. de cas server kan namelijk niet in een DMZ of iets dergelijks geplaatst worden aangezien deze een onbebelemerde toegang nodig heeft tot zowel de mailbox server als AD. dan kun je het beste met een reverse proxy werken, waar ISA\TMG het fijnste werkt voor je eindgebruikers.

verder loopt MAPI (outlook) in 2007 direct naar de mailbox, en niet via de CAS. pas bij exchange 2010 wordt Mapi on the Middle Tier geintroduceerd.

waarom eigenlijk geen ex2010 als je het nog moet opzetten?

[ Voor 3% gewijzigd door KorneelB op 29-12-2009 17:33 ]

60 TB can not be enough

Acties:

BP_LOZ

Topicstarter

freak1 schreef op dinsdag 29 december 2009 @ 17:32:
[...]

er is geen reden om met een klein aantal (ja 300 is klein) de mailbox rol te splitsen van de cas. verder is het gebruikelijk om indien er gesplitst wordt, de mailbox juist los te trekken van de cas\hub.

maak het jezelf niet moeilijk, je verstookt meer resources met het splitsen dan dat het je oplevert.

grove schatting kun je uitgaan van 1 backend server met mailbox\hub\cas. 4 cores, memory 4+(300X4)= 5 a 6 gb. daarmee kun je ruim uit de voeten. indien er ook forefront of een andere virusscanner op gaat draaien dien je er 1 a 2 gb memory bij te proppen
qua edge server kun je gewoon af met een dualcore met 2 gb geheugen, indien er veel mail voorbijkomt, of je gaat daar ook virusscannen dan 3 a 4 gb. dualcore is voldoende.

het splitsen van mailbox\hub\cas heeft in jouw situatie geen nut, ook qua veiligheid biedt het niets extras, het is dan een puur cosmetische scheiding. de cas server kan namelijk niet in een DMZ of iets dergelijks geplaatst worden aangezien deze een onbebelemerde toegang nodig heeft tot zowel de mailbox server als AD. dan kun je het beste met een reverse proxy werken, waar ISA\TMG het fijnste werkt voor je eindgebruikers.

verder loopt MAPI (outlook) in 2007 direct naar de mailbox, en niet via de CAS. pas bij exchange 2010 wordt Mapi on the Middle Tier geintroduceerd.

waarom eigenlijk geen ex2010 als je het nog moet opzetten?

Kijk dat is duidelijk. Hier kan ik wat mee. Bedankt voor de info!
Waarom geen Exchange 2010? Geen licenties, geen ervaring, geen permissie

dinsdag 29 december 2009 18:52

Acties:

Question Mark

Moderator SSC/WOS

F7 - Nee - Ja

freak1 schreef op dinsdag 29 december 2009 @ 17:32:
[...]
het splitsen van mailbox\hub\cas heeft in jouw situatie geen nut, ook qua veiligheid biedt het niets extras, het is dan een puur cosmetische scheiding. de cas server kan namelijk niet in een DMZ of iets dergelijks geplaatst worden aangezien deze een onbebelemerde toegang nodig heeft tot zowel de mailbox server als AD. dan kun je het beste met een reverse proxy werken, waar ISA\TMG het fijnste werkt voor je eindgebruikers.

Ik ben het helemaal eens met bovenstaande. Goede post

Maar, let wel even op een stukje beschikbaarheid. Ik kan niet uit de posts van TS halen welke versie van ESX deze gebruikt (en of hij dus gebruik kan maken van de HA opties van ESX). Klein aandachtspunt is dan wel dan mocht nu of in een later stadium er bepaalde zaken HA opgezet moeten gaan worden, dat je er dan niet aan ontkomt om wel bepaalde zaken uit elkaar te trekken.

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B

dinsdag 29 december 2009 20:39

Acties:

Moderator SSC/PB

Moooooh!

Question Mark schreef op dinsdag 29 december 2009 @ 18:52:
Maar, let wel even op een stukje beschikbaarheid. Ik kan niet uit de posts van TS halen welke versie van ESX deze gebruikt (en of hij dus gebruik kan maken van de HA opties van ESX).

Het is een misvatting dat HA van ESX een alternatief is voor HA van Exchange. Het één beschermt je tegen uitval van componenten op de hardware- of virtualisatielaag, het andere beschermt je tegen problemen op de applicatielaag. Wanneer een beheerder de installatie van een RU tussentijds afbreekt heb je niets aan ESX HA. Als er corruptie in een database optreedt dan heb je niets aan ESX HA. Als de server na een reboot een BSOD geeft dan heb je niets aan ESX HA.

Ze zijn dus hooguit aanvullend tov. elkaar. Als de TS volledige HA wil, dan zit hij gelijk vast aan minimaal 6 servers:
2 x CCR nodes voor de mailbox rol
2 x HT/CAS servers met NLB
2 x ET servers met NLB of meerdere MX records

woensdag 30 december 2009 08:39

Acties:

BP_LOZ

Topicstarter

Interessant Jazzy, maar om 6 bakken neer te zetten voor 300 mailboxen???
We hebben de mogelijkheid HA en Storage vMotion binnen de VMware omgeving en een recovery plan.

[ Voor 86% gewijzigd door BP_LOZ op 30-12-2009 08:40 ]

woensdag 30 december 2009 08:44

Acties:

Moderator SSC/PB

Moooooh!

BP_LOZ schreef op woensdag 30 december 2009 @ 08:39:
Interessant Jazzy, maar om 6 bakken neer te zetten voor 300 mailboxen???

Dat is precies mijn punt.

woensdag 30 december 2009 08:51

Acties:

Verwijderd

Jazzy schreef op dinsdag 29 december 2009 @ 20:39:
[...]
Het is een misvatting dat HA van ESX een alternatief is voor HA van Exchange. Het één beschermt je tegen uitval van componenten op de hardware- of virtualisatielaag, het andere beschermt je tegen problemen op de applicatielaag. Wanneer een beheerder de installatie van een RU tussentijds afbreekt heb je niets aan ESX HA. Als er corruptie in een database optreedt dan heb je niets aan ESX HA. Als de server na een reboot een BSOD geeft dan heb je niets aan ESX HA.

Ze zijn dus hooguit aanvullend tov. elkaar. Als de TS volledige HA wil, dan zit hij gelijk vast aan minimaal 6 servers:
2 x CCR nodes voor de mailbox rol
2 x HT/CAS servers met NLB
2 x ET servers met NLB of meerdere MX records

Als je exchange omgeving corrupt raakt dan repliceert ie dat ook lekker mee hoor, naar al je nodes in je cluster. dus je MBX rol via CCR verdelen over 2 machines bied dus eigenlijk ook alleen bescherming tegen hardware falen. hetzelfde als je met HA in ESX kan bereiken. hoewel je met CCR meestal gebruik maakt van 2 fysiek gescheiden lokaties, en met HA staan ze meestal in dezelfde kast/ruimte/gebouw.

woensdag 30 december 2009 09:24

Acties:

Moderator SSC/PB

Moooooh!

Verwijderd schreef op woensdag 30 december 2009 @ 08:51:
[...]

Als je exchange omgeving corrupt raakt dan repliceert ie dat ook lekker mee hoor, naar al je nodes in je cluster. dus je MBX rol via CCR verdelen over 2 machines bied dus eigenlijk ook alleen bescherming tegen hardware falen.

Nee hoor, dat klopt gelukkig niet. Als een logfile naar de passieve node gekopieerd is dan wordt hij eerst geinspecteerd en gecontroleerd op corruptie. Pas daarna wordt hij gereplayed in de passieve kopie van de database.

Hierdoor biedt CCR een goede bescherming tegen corruptie van de database, in tegenstelling tot ESX HA zoals je terecht noemt.

woensdag 30 december 2009 10:00

Acties:

woensdag 30 december 2009 10:41

Jazzy schreef op woensdag 30 december 2009 @ 09:24:
[...]
Nee hoor, dat klopt gelukkig niet. Als een logfile naar de passieve node gekopieerd is dan wordt hij eerst geinspecteerd en gecontroleerd op corruptie. Pas daarna wordt hij gereplayed in de passieve kopie van de database.

Hierdoor biedt CCR een goede bescherming tegen corruptie van de database, in tegenstelling tot ESX HA zoals je terecht noemt.

nope.
dat is niet zo met exchange 2007.
er wordt inderdaad gebruik gemaakt van log replay om de cluster op te bouwen, maar wanneer er een dusdanige actie plaats vind welke corruptie in de store tot gevolgd vind, zal deze zelfde actie gereplayed worden in je ccr cluster. ook corruptie van mailboxen e.d. (specifiek corrupted items) worden lekker gerepliceerd.

dat is echt een van de grootste tekortkomingen van CCR. waar het wel hele goede bescherming tegen biedt is corruptie door disk errors, uitval van hardware, software problemen etc. etc. ook heb je er geen (dure) shared storage voor nodig.
maar dat het niet correct beschermd tegen corruptie is een van de grote minpunten aan CCR.

vandaar dat we ook DAG's hebben in Exhange 2010

verder is eht gewoon ranzig dat als je organisatie groeit en je toch HA cq Redudancy wilt hebben, je dan zo ongeveer je exchange omgeving opnieuw moet bouwen. ook dit is opgelost in de DAG's

60 TB can not be enough

Acties:

Moderator SSC/PB

Moooooh!

freak1 schreef op woensdag 30 december 2009 @ 10:00:
[...]

nope.
dat is niet zo met exchange 2007.
er wordt inderdaad gebruik gemaakt van log replay om de cluster op te bouwen, maar wanneer er een dusdanige actie plaats vind welke corruptie in de store tot gevolgd vind, zal deze zelfde actie gereplayed worden in je ccr cluster. ook corruptie van mailboxen e.d. (specifiek corrupted items) worden lekker gerepliceerd.

Sorry jongens, maar jullie zitten er echt naast. Voor meer informatie verwijs is je naar de Continuous Replication Deep Dive whitepaper. Lees dan vooral over de LogInspector en wat die doet. Ook wordt CCR in dat whitepaper nog een keer vergeleken met alternatieve vormen van replicatie.

Dus enerzijds:

Third-party replication solutions may maintain two copies that are not independent from each other. This means that corruption introduced in the many layers executing on the hardware (Exchange, the operating system, storage components, and so on) are replicated to the second copy, resulting in a very high Recovery Point Objective (RPO) because both copies end up with the corruption.

Tegen anderzijds CCR:

Uses copies that are independent copies, so types of corruption that are replicated by third-party solutions are not replicated by continuous replication. For example, if a -1018 occurs on the active database, the passive copy will not suffer from the same corruption (assuming independent storage solutions).

maar dat het niet correct beschermd tegen corruptie is een van de grote minpunten aan CCR.

Ik hoop dat nu duidelijk is dat CCR dat dus wel doet.

vandaar dat we ook DAG's hebben in Exhange 2010

Als het inderdaad waar was dat CCR geen bescherming zou bieden tegen corruptie, dan zou ook de DAG dat niet doen. DAG is namelijk net als CCR gebaseerd op Continuous Replication, zij het met een aantal verbeteringen als incremental reseeds en dergelijke.

woensdag 30 december 2009 11:00

Acties:

woensdag 30 december 2009 13:03

Jazzy schreef op woensdag 30 december 2009 @ 10:41:
[...]
Sorry jongens, maar jullie zitten er echt naast. Voor meer informatie verwijs is je naar de Continuous Replication Deep Dive whitepaper. Lees dan vooral over de LogInspector en wat die doet. Ook wordt CCR in dat whitepaper nog een keer vergeleken met alternatieve vormen van replicatie.

Dus enerzijds:
[...]
Tegen anderzijds CCR:
[...]

[...]
Ik hoop dat nu duidelijk is dat CCR dat dus wel doet.
[...]
Als het inderdaad waar was dat CCR geen bescherming zou bieden tegen corruptie, dan zou ook de DAG dat niet doen. DAG is namelijk net als CCR gebaseerd op Continuous Replication, zij het met een aantal verbeteringen als incremental reseeds en dergelijke.

volgens mij praten we langs elkaar heen terwijl we hetzelfde bedoelen;
ccr biedt inderdaad bescherming tegen corruptie op hardware niveau, dat geef ik ook aan.
ccr biedt geen bescherming tegen corruptie die in de logging voorkomt. als er een actie uitgevoerd wordt door de exchange server die corruptie veroorzaakt, wordt dit vrolijk door de 2e node gereplayed en komt ook daar de corruptie in voor.

dit is overigens ook zo bij een DAG, grootste voordelen van een DAG is dat hij een mailbox database kan herstellen met nog eventueel goede versies op andere nodes, evenals rotte pages in de database en/of mailboxen.

we hebben het dus over hetzelfde ding

ik was misschien een beetje zwart/wit, en je hebt het zeker beter uitgelegd.

60 TB can not be enough

Acties:

Question Mark

Moderator SSC/WOS

F7 - Nee - Ja

Jazzy schreef op dinsdag 29 december 2009 @ 20:39:
[...]
Het is een misvatting dat HA van ESX een alternatief is voor HA van Exchange. Het één beschermt je tegen uitval van componenten op de hardware- of virtualisatielaag, het andere beschermt je tegen problemen op de applicatielaag.

Klopt inderdaad, maar mijn ervaring is dat de meeste klanten de HA opties van ESX al voldoende vinden. Zeker als je de meerprijs gaat noemen om Availability op de "Exchange manier" te regelen.

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B

woensdag 30 december 2009 13:28

Acties:

Moderator SSC/PB

Moooooh!

Question Mark schreef op woensdag 30 december 2009 @ 13:03:
[...]
Klopt inderdaad, maar mijn ervaring is dat de meeste klanten de HA opties van ESX al voldoende vinden. Zeker als je de meerprijs gaat noemen om Availability op de "Exchange manier" te regelen.

Sommigen wel, sommigen niet. Ik merk wel dat veel klanten weinig weten van wat welke oplossing ze nu uiteindelijk biedt. Vaak denken ze dat hun gebruikers altijd kunnen mailen omdat ze ESX HA gebruiken bijvoorbeeld. Dan moet ik eerst met ze door een aantal scenario's lopen om te ontdekken wat hun eisen exact zijn. Bij de meeste van mijn klanten volgt vervolgens dat ze kiezen voor HA op applicatienniveau, omdat ze anders niet de gewenste beschikbaarheid kunnen waarborgen.

Als klanten er toch voor kiezen om geen HA op applicatieniveau te gebruiken, dan is dat meestal omdat ze ontdekken dat de beschikbaarheid die ze vragen gewoon serieus geld kost. Vervolgens stellen ze simpelweg hun eisen een beetje bij waarna het ook prima kan met een enkelvoudige server en een slimme recovery methode.

Moet wel zeggen dat klanten die echt op het geld zitten meestal niet voor ons bedrijf kiezen, wij zitten toch wat meer in de high-end omgevingen. Dat zijn lang niet altijd grote omgevingen, maar wel omgevingen waarbij beschikbaarheid en flexibiliteit zo belangrijk zijn dat er niet op een paar licenties of VM's wordt gekeken.

Gek genoeg zie ik trouwens regelmatig dat klanten onderhoud of upgrades aan servers willen kunnen doen tijdens werktijd, in plaats van de server down te brengen tijdens een maintanence window. Gisteren nog een klant die RU9 voor Exchange 2007 SP1 gewoon overdag installeert op hun CCR cluster en dus 2 keer een switchover doet. Terwijl het gewoon een nationaal bedrijf is wat prima een maintanence window in zou kunnen lassen.

woensdag 30 december 2009 14:10

Acties:

DDX

Jazzy schreef op woensdag 30 december 2009 @ 10:41:
Als het inderdaad waar was dat CCR geen bescherming zou bieden tegen corruptie, dan zou ook de DAG dat niet doen. DAG is namelijk net als CCR gebaseerd op Continuous Replication, zij het met een aantal verbeteringen als incremental reseeds en dergelijke.

Je zou een log delay kunnen installen, maar dan is het weer handig om hier een 3e dag member voor te hebben.

Maar idd corruptie van je store (of inhoud) is een gevaar waar je ook rekening mee kan houden.
Al doet microsoft alsof je met exchange 2010 en 3 dag members (waarvan 1 op andere locatie) backup naar tape kan stopzetten.

https://www.strava.com/athletes/2323035

woensdag 30 december 2009 14:24

Acties:

Moderator SSC/PB

Moooooh!

freak1 schreef op woensdag 30 december 2009 @ 11:00:
[...]

ccr biedt geen bescherming tegen corruptie die in de logging voorkomt. als er een actie uitgevoerd wordt door de exchange server die corruptie veroorzaakt, wordt dit vrolijk door de 2e node gereplayed en komt ook daar de corruptie in voor.

Ik begrjip wat je bedoelt, maar daar ben ik dus niet helemaal zeker over. Kun je eens een voorbeeld geven van zo'n fout die meegerepliceerd zou worden?

woensdag 30 december 2009 18:14

Acties: