:strip_icc():strip_exif()/u/57319/BoFhphone.jpg?f=community)
dit is begonnen als een stuk storage en I/O performance design voor Exchange 2000
aangezien er toch een vraag was om dit uit te breiden om gewoon exchange 2000 design en planning te omvatten. en ik dit zelf ook wel een interessant onderwerk vind. heb ik aan Koffie gevraagd om de Titel van de Thread aan te passen.
zodat het ook duidelijk is waarover we hier discusieren
-------------------------------------------------------------------------------------
deze kan ook in opslag media en I/O controllers thuis horen. maar ik post hem hier omdat ik hoop dat er hier wat professioneler word meegedacht / gediscussieerd
even in het kort samengevat.
wat voor RAID levels ga ik gebruiken voor mijn Exchange server , OS+ swap , Logfiles, property store , en de streaming store. dit omdat microsoft zichzelf nog al eens tegenspreekt. en ik helaas niet in staat ben om alles te testen op dit moment
ik ben op dit moment bezig om een Exchange 2000 cluster te ontwerpen.
het moet een 2 node Active / Active cluster worden voor 1000 mailboxen totaal, Gemiddeld 100MB Max per mailbox
normaal verdeeld als 500 mailboxen per node. maar als er een node onderuitgaat en er vind failover plaats dan moet de overgebleven node de volledige 1000 mailboxen kunnen hebben. daarnaast is er nog een stuk overcapaciteit voor de toekomst
qua hardware hebben wij hier als standaard Compaq Proliant servers
op dit moment ben ik aan het kijken naar een Proliant ML530 Dual P4 Xeon 2.4GHZ server met 4GB Memory.en een Smart Array 5300 controller
( 64, 128 of 256 mb cache)
dit omdat de prijs prestatie verhouding van deze server gewoon goed is.
hij is 1000 euro duurder dan een ML370 met dual proc ( 1.4GHZ ) en
2000 euro duurder dan een DL380 met dual proc ( 1.4GHZ )
als deze voor de rest het zelfde geconfigureerd word
nu heb ik ondertussen al een doos A4 papier aan documenten doorgelezen van onder andere microsoft en compaq. en ook de resourse kit en MCSE boeken / Administration guides. zijn mij niet vreemd meer
de bedoeling is ook om dit op een SAN te gaan implementeren. nu loop ik tegen een aantal heel interessante vragen aan.
microsoft beveeld RAID 0+1 aan boven RAID 5. als we dit bekijken vanuit een performance / data redundancy oogpunt. RAID 1 word ook genoemd maar is "traag"
RAID 0 is niet veilig maar performd het beste
nu was ik voor de systeem drives van plan om 18.4GB 15K RPM UW3 schijven te gaan gebruiken.
ik stel de I/O performance van deze drives even gelijk aan 100 read /100 write voor het gemak van rekenen
als ik volgens het microsoft voorbeeld reken levert RAID 0+1 met 4x een 18.4Gb disk me 36.8GB aan bruikbare storage op
en aan I/O performance 4x100 = 400 read / 4x100/2= 200 write performance
(volgensde microsoft formule)
en voor RAID 5 met 4x een 18.4GB disk me 55.2GB aan Bruikbare storage op
en aan I/O performance 4x100 = 400 read / 4x100/4=100 write performance
(volgensde microsoft formule)
dus RAID 0+1 is 400 read / 200 write
dus RAID 5 is 400 read / 100 write
nu gaan we even van die nummers uit
nu beveeld microsoft het volgende aan (best practices)
een RAID array / partitie voor het OS
een RAID array / partitie voor de swapfile
een RAID array / partitie voor de Exchange logfiles
( sequential I/O , 4KB gemiddeld 50% read / 50% write)
een RAID array / partitie voor de property store
( Random I/O 50% read / 50% write)
een RAID array / partitie voor de streaming store
( Sequential I/O 100% read )
als dat je te overdreven word en je maakt niet veel gebruik van Internet protocolls ( POP3, IMAP4 enz met exchange) kan je het ook zo inrichten
een RAID array / partitie voor het OS + de Swap file
een RAID array / partitie voor de Exchange logfiles
een RAID array / partitie voor de property store + streaming store
dit lijkt mij dus ook direct de meest efficiente oplossing. omdat onze exchange server functioneerd als corporate Echange niet ISP Echange ( om maar weer eens met microsoft te gooien)
dus kom ik op het volgende uit.
om de server zelf maar rap te houden zit ik nu hevig in de richting van RAID 0+1 te denken voor de OS + Swapfile. ( Cache ingesteld op 50% read 50% write )
kost ongeveer 700 euro meer maar dan heb je ook wat. ( op papier tenminste )
nadeel is de Waste of space zogezegt . maar er kunnen 2 disks ( mits het over de beide mirrors verdeeld word ) stuk gaan in de ze opstelling
wat ook nog zou kunnen is 3of 4 disks RAID 5 en dan op de contoller de Write cache op 25% of 0% read en 75% of 100% write te zetten en dan hopen dat dit iets afvangt van de write performance
of gewoon 2 Disks RAID 1 en hopen dat de 15k disks snel genoeg zijn om het
"vlot te houden"
maar nu gaan we aankomen bij het stuk waarvan ik graag de mening zou willen horen van mensen die exchange al geimplementeerd hebben op een SAN.
ik ga hier uit van 1 Storage groep per server wat dus zou betekenen dat je
4 Arrays zou moeten creeeren in de SAN. 2x voor de logfiles 2x voor de database files om tot de maximale I/O performance te komen
en de Random van de Sequential accesses te scheiden
maar dit leverd mij een interessant probleem op.
ga ik voor het exchange gedeelte van de SAN kleinere schijven kopen om maar meer I/O performance te kweken. of ga ik de Schijven zo groot mogenlijk inkopen om de totale capaciteit van de SAN zo hoog mogenlijk te houden.
omdat je dan op hele vreemde dingen gaat uitkomen.
als ik de schijven zo groot mogenlijk maak dan kom je uit op
of 4x 3 schijven RAID 5 of 4x 4 schijven RAID 0+1
dus komt dus alletwee uit op effectief +/- 146GB per Array/partietie als je de 73 Gb fibrechannel disks gebruikt. iets wat zeker door de log files nooit gebruikt gaat worden. en mensen moeten wel hele grote email archieven gaan opbouwen om dat op te vullen
ik zou ook 18GB of 36GB disks kunnen gaan gebruiken ( of een combo daarvan)
zou ik zelf denken aan
Logfiles 4x 18Gb disk RAID 0+1 voor 36GB effectief per array
Databases 6x 36GB RAID 0+1 voor 108Gb effectief per Array
en dan 2x logfiles array/partitie en 2x database array / partitie
wat meer als genoeg moet zijn omdat dat de dubbele benodigde capaciteit is die nodig is per storage groep.
hou ik trouwens de Quorum Disk nog over dit zal denk ik RAID 1 worden omdat dit niet echt hoge I/O performance nodig heeft dus 2x 18GB disk RAID 1
ik vind dus vooral het SAN gedeelte heel moeilijk. omdat het gebruikvan klenere disks je SAN Capaciteit kleiner maakt. en je dus ook meer disk cabinets nodig zal hebben. wat ook weer een stuk investering is.
heeft er hier iemand al een vergelijkbare implementatie gedaan van Exchange 2000 op een SAN ? zo ja hoe zijn jullie er dan "tegenaangegaan" ?
en wat denken jullie er in zijn algemeenheid over
aangezien er ook ongeveer 700 tot 900 man op een dag actief gaan zijn op deze 2 servers lijkt de performance mij een belangrijk punt.
ik heb me trouwens even beperkt gehouden tot het Storage gedeelte omdat het anders helemaal een uitgebreid vraagstuk gaat worden.
------------------------------------------------------------------------------
Er was een verzoek om dit topic niet te beperken tot alleen maar de storage. en om ook andere design overwegingen mee te nemen
ik zal mijn gedachten over de storage groepen er ook maar eens bij typen.
later gaat nog meer volgen
oke, nu was ik aan het plannen voor een Exchange 2000 server cluster met 2 nodes Active/Active. voor 1000 Mapi clients. verdeeld als +/- 500 per server
de gemiddelde mailbox grote houd ik op het moment als 100MB max per user.
dus 50GB storage per server is minimaal nodig . maar aangezien ik ook rekening hou met groei in de toekomst (aantal users en Email volume) zal er extra ruimte zijn ik denk aan 100GB storage groep.
Elke server gaat 1 storage groep hebben. om mee te beginnen. later kan er per server nog 1 Storage groep bij komen voor een totaal van 2 per server.
dit omdat een enkele server maximaal 4 Storage groups kan hebben. en je wel wilt dat als er Failover plaats vind dat ook alle Stores weer online kunnen komen.
wij hebben intern ongeveer 15 hoofdafdelingen deze afdeling worden weer samengevoegd tot 5 diensten. medisch, administratief, enz enz dit worden dan de 5 Mailbox Databases daarnaast gaat er nog een extra Mail database zijn voor de services ( denk aan de mailbox voor de Administrator, en allerlij vergelijkbare accounts)
de diensten worden zo gecombineerd dat de spreiding van users die Last zou kunnen hebben van een Uitval van een database zo gespreid mogenlijk is.
daarnaast is het zo verdeeld dat we ongeveer uitkomen op 500 users per server
Er is doelbewust gekozen om het op dienst nivo te doen. omdat dit ook het makkelijkst te Managen is.
dus per storage groep komen er 3 mailbox databases. en 1 storage groep per server.
dit is ook gedaan vanuit het oogpunt van Backup en Restore.
op deze manier zijn er 6 kleinere databases. ipv 2 grote.
mocht er dus een database door wat voor reden dan ook corrupt raken. dan word er maar een relatief klein aantal users door getroffen en ook het terug zetten van een database zal sneller zijn omdat de database grote kleiner is.
heb je 175 man in onder 1 uur weer aan de email.
ipv dat er 500 man 3 uur zonder zit.
dit is natuurlijk ook afhankelijk van hoebelangrijk de functionaliteit van de Exchange server is binnen de organisatie. ( email , agenda , contactpersonen, public folders, enz enz)
------------------------------------------------------------------------------
nog een stukje over het geheugen van de Servers
er gaat 4GB aan geheugen in die servers omdat er zowieso 2 geheugen banken tegelijker tijd met geheugen gevuld moet worden
en Exchange toch niet meer dan 2.8 Gb aan virtueel geheugen kan addresseren
( dit volgens microsoft. ik heb het nog niet kunnen testen)
een ding wat wel zeker is. de /3GB switch zal gezet moeten worden in de Boot.ini.
omdat store.exe anders al na 1.5 GB memory in gebruik zal gaan zeggen dat er geen geheugen meer beschikbaar is. terwijl er nog zat vrij is. dit heb ik wel kunnen testen. zet gewoon 2GB geheugen in je server en vergeet de /3GB switch te zetten
het heeft dus ook totaal geen nut om meer geheugen in de servers te proppen.
aangezien er toch een vraag was om dit uit te breiden om gewoon exchange 2000 design en planning te omvatten. en ik dit zelf ook wel een interessant onderwerk vind. heb ik aan Koffie gevraagd om de Titel van de Thread aan te passen.
zodat het ook duidelijk is waarover we hier discusieren
-------------------------------------------------------------------------------------
deze kan ook in opslag media en I/O controllers thuis horen. maar ik post hem hier omdat ik hoop dat er hier wat professioneler word meegedacht / gediscussieerd
even in het kort samengevat.
wat voor RAID levels ga ik gebruiken voor mijn Exchange server , OS+ swap , Logfiles, property store , en de streaming store. dit omdat microsoft zichzelf nog al eens tegenspreekt. en ik helaas niet in staat ben om alles te testen op dit moment
ik ben op dit moment bezig om een Exchange 2000 cluster te ontwerpen.
het moet een 2 node Active / Active cluster worden voor 1000 mailboxen totaal, Gemiddeld 100MB Max per mailbox
normaal verdeeld als 500 mailboxen per node. maar als er een node onderuitgaat en er vind failover plaats dan moet de overgebleven node de volledige 1000 mailboxen kunnen hebben. daarnaast is er nog een stuk overcapaciteit voor de toekomst
qua hardware hebben wij hier als standaard Compaq Proliant servers
op dit moment ben ik aan het kijken naar een Proliant ML530 Dual P4 Xeon 2.4GHZ server met 4GB Memory.en een Smart Array 5300 controller
( 64, 128 of 256 mb cache)
dit omdat de prijs prestatie verhouding van deze server gewoon goed is.
hij is 1000 euro duurder dan een ML370 met dual proc ( 1.4GHZ ) en
2000 euro duurder dan een DL380 met dual proc ( 1.4GHZ )
als deze voor de rest het zelfde geconfigureerd word
nu heb ik ondertussen al een doos A4 papier aan documenten doorgelezen van onder andere microsoft en compaq. en ook de resourse kit en MCSE boeken / Administration guides. zijn mij niet vreemd meer
de bedoeling is ook om dit op een SAN te gaan implementeren. nu loop ik tegen een aantal heel interessante vragen aan.
microsoft beveeld RAID 0+1 aan boven RAID 5. als we dit bekijken vanuit een performance / data redundancy oogpunt. RAID 1 word ook genoemd maar is "traag"
RAID 0 is niet veilig maar performd het beste
nu was ik voor de systeem drives van plan om 18.4GB 15K RPM UW3 schijven te gaan gebruiken.
ik stel de I/O performance van deze drives even gelijk aan 100 read /100 write voor het gemak van rekenen
als ik volgens het microsoft voorbeeld reken levert RAID 0+1 met 4x een 18.4Gb disk me 36.8GB aan bruikbare storage op
en aan I/O performance 4x100 = 400 read / 4x100/2= 200 write performance
(volgensde microsoft formule)
en voor RAID 5 met 4x een 18.4GB disk me 55.2GB aan Bruikbare storage op
en aan I/O performance 4x100 = 400 read / 4x100/4=100 write performance
(volgensde microsoft formule)
dus RAID 0+1 is 400 read / 200 write
dus RAID 5 is 400 read / 100 write
nu gaan we even van die nummers uit
nu beveeld microsoft het volgende aan (best practices)
een RAID array / partitie voor het OS
een RAID array / partitie voor de swapfile
een RAID array / partitie voor de Exchange logfiles
( sequential I/O , 4KB gemiddeld 50% read / 50% write)
een RAID array / partitie voor de property store
( Random I/O 50% read / 50% write)
een RAID array / partitie voor de streaming store
( Sequential I/O 100% read )
als dat je te overdreven word en je maakt niet veel gebruik van Internet protocolls ( POP3, IMAP4 enz met exchange) kan je het ook zo inrichten
een RAID array / partitie voor het OS + de Swap file
een RAID array / partitie voor de Exchange logfiles
een RAID array / partitie voor de property store + streaming store
dit lijkt mij dus ook direct de meest efficiente oplossing. omdat onze exchange server functioneerd als corporate Echange niet ISP Echange ( om maar weer eens met microsoft te gooien)
dus kom ik op het volgende uit.
om de server zelf maar rap te houden zit ik nu hevig in de richting van RAID 0+1 te denken voor de OS + Swapfile. ( Cache ingesteld op 50% read 50% write )
kost ongeveer 700 euro meer maar dan heb je ook wat. ( op papier tenminste )
nadeel is de Waste of space zogezegt . maar er kunnen 2 disks ( mits het over de beide mirrors verdeeld word ) stuk gaan in de ze opstelling
wat ook nog zou kunnen is 3of 4 disks RAID 5 en dan op de contoller de Write cache op 25% of 0% read en 75% of 100% write te zetten en dan hopen dat dit iets afvangt van de write performance
of gewoon 2 Disks RAID 1 en hopen dat de 15k disks snel genoeg zijn om het
"vlot te houden"
maar nu gaan we aankomen bij het stuk waarvan ik graag de mening zou willen horen van mensen die exchange al geimplementeerd hebben op een SAN.
ik ga hier uit van 1 Storage groep per server wat dus zou betekenen dat je
4 Arrays zou moeten creeeren in de SAN. 2x voor de logfiles 2x voor de database files om tot de maximale I/O performance te komen
en de Random van de Sequential accesses te scheiden
maar dit leverd mij een interessant probleem op.
ga ik voor het exchange gedeelte van de SAN kleinere schijven kopen om maar meer I/O performance te kweken. of ga ik de Schijven zo groot mogenlijk inkopen om de totale capaciteit van de SAN zo hoog mogenlijk te houden.
omdat je dan op hele vreemde dingen gaat uitkomen.
als ik de schijven zo groot mogenlijk maak dan kom je uit op
of 4x 3 schijven RAID 5 of 4x 4 schijven RAID 0+1
dus komt dus alletwee uit op effectief +/- 146GB per Array/partietie als je de 73 Gb fibrechannel disks gebruikt. iets wat zeker door de log files nooit gebruikt gaat worden. en mensen moeten wel hele grote email archieven gaan opbouwen om dat op te vullen
ik zou ook 18GB of 36GB disks kunnen gaan gebruiken ( of een combo daarvan)
zou ik zelf denken aan
Logfiles 4x 18Gb disk RAID 0+1 voor 36GB effectief per array
Databases 6x 36GB RAID 0+1 voor 108Gb effectief per Array
en dan 2x logfiles array/partitie en 2x database array / partitie
wat meer als genoeg moet zijn omdat dat de dubbele benodigde capaciteit is die nodig is per storage groep.
hou ik trouwens de Quorum Disk nog over dit zal denk ik RAID 1 worden omdat dit niet echt hoge I/O performance nodig heeft dus 2x 18GB disk RAID 1
ik vind dus vooral het SAN gedeelte heel moeilijk. omdat het gebruikvan klenere disks je SAN Capaciteit kleiner maakt. en je dus ook meer disk cabinets nodig zal hebben. wat ook weer een stuk investering is.
heeft er hier iemand al een vergelijkbare implementatie gedaan van Exchange 2000 op een SAN ? zo ja hoe zijn jullie er dan "tegenaangegaan" ?
en wat denken jullie er in zijn algemeenheid over
aangezien er ook ongeveer 700 tot 900 man op een dag actief gaan zijn op deze 2 servers lijkt de performance mij een belangrijk punt.
ik heb me trouwens even beperkt gehouden tot het Storage gedeelte omdat het anders helemaal een uitgebreid vraagstuk gaat worden.
------------------------------------------------------------------------------
Er was een verzoek om dit topic niet te beperken tot alleen maar de storage. en om ook andere design overwegingen mee te nemen
ik zal mijn gedachten over de storage groepen er ook maar eens bij typen.
later gaat nog meer volgen
oke, nu was ik aan het plannen voor een Exchange 2000 server cluster met 2 nodes Active/Active. voor 1000 Mapi clients. verdeeld als +/- 500 per server
de gemiddelde mailbox grote houd ik op het moment als 100MB max per user.
dus 50GB storage per server is minimaal nodig . maar aangezien ik ook rekening hou met groei in de toekomst (aantal users en Email volume) zal er extra ruimte zijn ik denk aan 100GB storage groep.
Elke server gaat 1 storage groep hebben. om mee te beginnen. later kan er per server nog 1 Storage groep bij komen voor een totaal van 2 per server.
dit omdat een enkele server maximaal 4 Storage groups kan hebben. en je wel wilt dat als er Failover plaats vind dat ook alle Stores weer online kunnen komen.
wij hebben intern ongeveer 15 hoofdafdelingen deze afdeling worden weer samengevoegd tot 5 diensten. medisch, administratief, enz enz dit worden dan de 5 Mailbox Databases daarnaast gaat er nog een extra Mail database zijn voor de services ( denk aan de mailbox voor de Administrator, en allerlij vergelijkbare accounts)
de diensten worden zo gecombineerd dat de spreiding van users die Last zou kunnen hebben van een Uitval van een database zo gespreid mogenlijk is.
daarnaast is het zo verdeeld dat we ongeveer uitkomen op 500 users per server
Er is doelbewust gekozen om het op dienst nivo te doen. omdat dit ook het makkelijkst te Managen is.
dus per storage groep komen er 3 mailbox databases. en 1 storage groep per server.
dit is ook gedaan vanuit het oogpunt van Backup en Restore.
op deze manier zijn er 6 kleinere databases. ipv 2 grote.
mocht er dus een database door wat voor reden dan ook corrupt raken. dan word er maar een relatief klein aantal users door getroffen en ook het terug zetten van een database zal sneller zijn omdat de database grote kleiner is.
heb je 175 man in onder 1 uur weer aan de email.
ipv dat er 500 man 3 uur zonder zit.
dit is natuurlijk ook afhankelijk van hoebelangrijk de functionaliteit van de Exchange server is binnen de organisatie. ( email , agenda , contactpersonen, public folders, enz enz)
------------------------------------------------------------------------------
nog een stukje over het geheugen van de Servers
er gaat 4GB aan geheugen in die servers omdat er zowieso 2 geheugen banken tegelijker tijd met geheugen gevuld moet worden
en Exchange toch niet meer dan 2.8 Gb aan virtueel geheugen kan addresseren
( dit volgens microsoft. ik heb het nog niet kunnen testen)
een ding wat wel zeker is. de /3GB switch zal gezet moeten worden in de Boot.ini.
omdat store.exe anders al na 1.5 GB memory in gebruik zal gaan zeggen dat er geen geheugen meer beschikbaar is. terwijl er nog zat vrij is. dit heb ik wel kunnen testen. zet gewoon 2GB geheugen in je server en vergeet de /3GB switch te zetten
het heeft dus ook totaal geen nut om meer geheugen in de servers te proppen.
[ Voor 0% gewijzigd door Goshimaplonker298 op 11-08-2002 13:26 . Reden: Aanvulling ]
/u/9273/crop576bd2537abe7_cropped.png?f=community)
/u/38159/DirkJan.png?f=community)
:strip_icc():strip_exif()/u/10517/nwkoffie.jpg?f=community)
:strip_exif()/u/28405/scooby2.gif?f=community)
:strip_icc():strip_exif()/u/23964/smmup01.jpg?f=community)