[Exchange 2003] Nieuwe omgeving, redundancy?

[Aetje]

Okee. In een eerder topic gaf ik al aan dat ik op het moment enkele Mercury servers beheer met pak m beet 2.500 users. We gaan van Novell op Active Directory overstappen, en Mercury gaat weg om plaats te maken voor Exchange 2003.

Om 2.500 users op 200MB per mailbox (limiet) te kunnen doen was initieel gekozen voor een enkele frontend server om RPCoHTTP, POP, IMAP, SMTP en OWA te draaien in de DMZ. Verder twee backend servers in een cluster om de mailboxen en alle outlook users op het netwerk te kunnen serveren.

Kort geleden een meetinkje met het consultancybedrijf dat nu ons plan in elkaar zet (een certified microsoft partner) gehad, wat betreft de plannen. Werd me vrolijk even verteld dat de backend servers dus niet een cluster worden, omdat de storage groups dan te groot zouden worden!
Nu heb ik ongeveer 0 verstand van exchange (ik wordt binnenkort op training gestuurd) maar ik vermoed dat dit dus geen goed idee is. Elk van die 2 servers gaat ongeveer de helft van de hele enterprise bedienen, en als er 1tje down gaat dus...

Wat is jullie mening hier? Wat is de least worst practise? De twee servers clusteren en toch maar grote storage groups? Of standalone met het risico van een critical failure die de hele zaak voor een paar uur plat legt? Zelf zat ik zelfs al aan virtualisatie te denken... Elke fysieke server draait 2 virtual servers, die ik dan kruislings koppel zodat er 2 clusters zijn. Als er dan 1tje plat gaat draaien beide exchange servers op de andere server. Ik weet niet eens of dat kan (of verstandig is)... Wat ik het liefst wil is gewoon 4 bakken om 2 clusters op te zetten natuurlijk maar ik vermoed dat daar de financien niet voor zijn... *zucht*

[Brahiewahiewa]

Als dat consultancy bedrijf daadwerkelijk beweert dat de storage groups te groot worden, moet je ze meteen naar huis sturen; storage groups kunnen niet te groot worden, alleen databases kunnen te groot worden.

In dit geval heb je 't over 2500 x 200 Meg = .5 TB. Da's 25 Gieg per database en dat klinkt als een redelijke hoeveelheid. Meestal is de beperkende factor in de omvang van je databases de backup/restore windows. Met 25 GB zou je een database in een half uur moeten kunnen restoren; lijkt mij niet onaanvaardbaar voor een SLA.

Als de backup windows niet aansluiten bij je SLA, dan moet je niet clustering laten vervallen, maar je backup mechanisme heroverwegen. In plaats van te gaan knoeien met tapes, kun je snapshots gaan gebruiken; kost meer disks maar in vergelijking met de manuren die je aan tape handling kwijt bent, ben je vrij snel voordeliger uit.

Alternatief kun je overwegen om een cluster met drie nodes neer te zetten; kost je 'n extra machientje ( 50 k€ ) maar dan heb je meteen 40 databases van elk 12.5 GB

[Verwijderd]

ik zou niet 2 exchange bakken op 1 machine gaan draaien met vmware oid. Als je dan toch redundantie wilt hebben van 2 losse machines, zet dan een derde in met vmware (esx natuurlijk) en draai daar de 2 passive nodes op. Dat scheelt je dus 1 machine, die eigenlijk toch niks staat te doen...

[Question Mark]

Brahiewahiewa schreef op vrijdag 19 mei 2006 @ 03:06:e
Alternatief kun je overwegen om een cluster met drie nodes neer te zetten; kost je 'n extra machientje ( 50 k€ ) maar dan heb je meteen 40 databases van elk 12.5 GB

'k Heb er nog nooit echt over nagedacht. maar ik kan toch ook met twee clusternodes, 3 virtuele Exchange servers aanmaken binnen mijn cluster administrator. Gevolg is natuurlijk wel dat 1 fysieke server 2 virtuele servers draait (en 3 tijdens uitval), maar ik heb wel het voordeel dat ik meerdere databases kan hosten op een fysieke server. Bovendien scheelt dit de aanschaf van een derde clusternode.

Ik leest trouwens net (op Exchange virtual servers) dat vanaf meer dan twee clusternodes, active/active configuraties niet mogelijk zijn.

Exchange 2003 supports active/active clustering for two-node clusters. Clusters with more than two nodes must use active/passive clustering. In an active/active Exchange cluster, there are multiple Exchange Virtual Servers that can be moved, with certain restrictions, between the different nodes that belong to the cluster and can simultaneously run on one node

[ Voor 5% gewijzigd door Question Mark op 19-05-2006 11:03 ]

[Abom]

25gb...is nix. Onze storage group is 50gb, geen probleem met backup of restore tijden.

Ik vind alleen 1250 users per exchange server wat veel, maar niet onmogelijk. Wat ik nooit zou aanraden is deze omgeving op een two-way cluster draaien, waar de ene node, de fail-over is van de andere.
Ik zou eerder voor een 3- of liever 4-way cluster gaan, met een active/passive configuratie. Hierdoor draait je Exchange omgeving niet in verminderde status wanneer een node onderuit is gegaan. Met een 4-way zou ik het aantal mailboxen per VSI (totaal van 3) verkleinen zodat a ) groei mogelijkheden houd zonder meteen nieuwe hardware aan te moeten schaffen en b ) de impact van een failure beperkt.

Overigens vind ik het een beetje raar dat het management hier geen geld voor uit wil trekken, wanneer ik naar het aantal users kijk...zo duur is een cluster ook weer niet.

[ Voor 38% gewijzigd door Abom op 19-05-2006 13:18 ]

[Brahiewahiewa]

Abom schreef op vrijdag 19 mei 2006 @ 13:09:
25gb...is nix. Onze storage group is 50gb, geen probleem met backup of restore tijden.

Ik vind alleen 1250 users per exchange server wat veel, maar niet onmogelijk...

1250 users is nix. Mijn eigen (250 MB) mailbox staat op een cluster node samen met 5000 andere mailboxen.
Is een 8 proc machine, OK. Maar geen performance problemen

[Abom]

Het gaat ook niet zo zeer om de performance, maar meer om de impact die downtime zou hebben. E-mail is tegenwoordig een primary IT middel, je wil niet dat 50% van je gebruikers tijdelijk geen e-mail kunnen gebruiken.

[Verwijderd]

Volgens mij is je frontend hier ook een puntje van aandacht. Is dat niet in het design je single point of failure?

[Rolfie]

2500 mailboxen kan je op 1 cluster draaien. Zoals al eerder gemeld was zit je dan rond de 25Gb per mailbox store. Tussen de 25 en 35Gb zijn meestel onze databases. Hiermee kunnen we zonder problemen en ruim binnen onze SLA alles restoren. Dus met een Active/Pasive omgeving kan je ruim vooruit. We draaien zelf bij ons op een 4node cluster (A/A/A/P) 6000 mailboxen, Zonder enige problemen. We draaien ook 40000/45000 mailboxen op een Exchange server of 6. Dit zijn alleen geen clusters.


Offtopic
We kunnen wel zeggen dat je met 2 nodes of 3 nodes moet draaien, maar hoe hoe zwaar belast zijn je mailboxen? Hoeveel gebruikers heb je te geconnecit via Outlook/Webmail IMAP? hoeveel EMail ontvang je per dag? Heb je een Virusscanner op je cluster draaien?
Wat voor een SAN zit er precies achter? Zeker je storage is zeer belangrijk. Hoe snel is je SAN. Via IO/Sec dan je SAN aan? FC is krachter als ISCSI. Er zit ook verschil tussen een instap SAN (MSA1000) of een highend SAN (EVA4000/6000/8000). Ga in in iedergeval voor redudante HBA controllers als je met FC gaat werken.
Denk ook goed na over je Backup, hoe ga je dit doen?
Storange technisch kan je het met 2 Cluster nodes aan, maar of je dit ook met je storage het ook aan kan?

Kijk eens op de volgende websites:
Optimizing Storage for Exchange Server 2003
HP ActiveAnswers for Microsoft Exchange Server (Vul je omgeving in en krijg een Hardware advies van HP)

[Aetje]

Updateje. We hebben een tweede gesprek gehad waarik ik mn waarschuwing kon geven. Waarschijnlijk gaan de Exchange servers op virtual servers draaien zodat als er 1 uitvalt het eenvoudig is om het systeem weer up te krijgen. Storage unit recovery kunnen we in toom houden door de SUs <20GB te houden.

Clusteren is ons door de Microsoft partner afgeraden... Schijnt dat Exchange clustering nogal brak is. De fallback wordt nu in geval van nood de 2 virtuele servers op dezelfde fysieke bak laten draaien. We hebben de specs voor de exchange servers breed uitgemeten... 4GB Ram, 2 dualcore CPUs. Zou moeten werken als crisisoplossing

De specs van de SAN heb ik niet, ik weet alleen dat het recent is. Ons netwerkteam beheert dat en daar ben ik geen member van . Ik weet iig dat het FC is.

De frontend is geen probleem. Er gaat een appliance voor zitten (hardware scanner & spam oplossing, barracuda waarschijnlijk) en die kan incoming mail cachen. De outbound mail kan dan lokaal bij de clients gecached worden (Outlook cached mode, waarschijnlijk gaat dat overal aangezet worden). Dan is alles alleen vertraagd

[ Voor 18% gewijzigd door Aetje op 25-05-2006 16:32 ]

[Question Mark]

Aetje schreef op donderdag 25 mei 2006 @ 16:21:
Clusteren is ons door de Microsoft partner afgeraden... Schijnt dat Exchange clustering nogal brak is. De fallback wordt nu in geval van nood de 2 virtuele servers op dezelfde fysieke bak laten draaien.

Dappere uitspraak om simpel te stellen dat het clusteren van Exchange brak is (en da's nog voorzichtig uitgedrukt). Met dergelijke uitspraken ga ik twijfelen aan de kwaliteit van deze 'partner'. Kennelijk ben ik daar al niet de enige is.

Brahiewahiewa schreef op vrijdag 19 mei 2006 @ 03:06:
Als dat consultancy bedrijf daadwerkelijk beweert dat de storage groups te groot worden, moet je ze meteen naar huis sturen; storage groups kunnen niet te groot worden, alleen databases kunnen te groot worden.

[ Voor 35% gewijzigd door Question Mark op 25-05-2006 16:33 ]

[Aetje]

Question Mark schreef op donderdag 25 mei 2006 @ 16:31:
[...]
Dappere uitspraak om simpel te stellen dat het clusteren van Exchange brak is (en da's nog voorzichtig uitgedrukt).

Tja. Dat vertelt m'n netwerk admin en mn microsoft partner me. Zelf heb ik er 0 ervaring mee dus ik ga op de mening af van de mensen die er al mee gewerkt hebben...

En wat de storage groups betreft, de grootte is niet vanwege fysieke limitaties, maar vanwege de tijd die nodig is om in geval van corruptie of verlies van de SU de groep in een redelijke (<12 uur) tijd terug te zetten. Dat betekent teruglezen van tape en lsinteg draaien. Dan kan je geen enorme groups hebben...

[ Voor 30% gewijzigd door Aetje op 25-05-2006 16:36 ]

[Verwijderd]

Clusteren is ons door de Microsoft partner afgeraden... Schijnt dat Exchange clustering nogal brak is.

Hebben ze daar ook een onderbouwing voor gegeven? Zo brak is exchange clustering niet, zeker niet met SP2.

Dat betekent teruglezen van tape en lsinteg draaien.

Huh?

[ Voor 16% gewijzigd door Verwijderd op 25-05-2006 20:51 ]

[DaRealRenzel]

Ik zou echt voor de simpele aanpak gaan. Koop één 4-Dual-Core-CPU machine met plenty RAM en een leuk RAID-1 Boot Setje en draai daar de Active Exchange Node op. Kan makkelijk 2500 users aan. Zet daarbij een simpele 2-Dual-Core-CPU machine met Raid-1 Boot, en zet die in als Passive node. Als je Active Node weg valt is er qua performance wel een dipje, maar dat is te aanvaarden. Kost minder, en is net zo goed. Stores op SAN, Quorum op SAN en gaan met die banaan.

[Verwijderd]

Clusters met dissimilar hardware is niet echt een goed idee.....

[Koffie]

Ik moet me toch aansluiten bij de gemiddelde opmerkingen hier. Het niet willen aan MS Clustering wegens genoemde uitspraken zijn redelijk kul te noemen.
Ik ben eerder bang dat ze zelf niet genoeg ervaring met clustering hebben, maar dat niet uit willen spreken.

Om een klein beetje mee te gaan in het gooien van behaalde resultaten : wij hebben hier nog een afstervend cluster draaien : 2 quad Xeon machines (500Mhz that is ) welke samen Exchange en files serveren (meestal file op de ene node, exchange op de andere node). Clusters zijn nog NT4 en Exchange is 5.5 , totaal aantal mailboxen : ca 1400 (het hele zooitje gaat naar Exchange 2003 overigens).

Zo belachelijk zwaar is je mail omgeving niet, ik zie weinig risico om dit gewoon op een 2 node cluster te draaien waarbij je altijd naar een andere node om kunt hangen als er problemen zijn.

Ik zou iig nu zo snel mogelijk je twijfels jegens deze 'certified partner' naar het MT uitspreken.

[Rolfie]

Kort geleden een meetinkje met het consultancybedrijf dat nu ons plan in elkaar zet (een certified microsoft partner) gehad, wat betreft de plannen. Werd me vrolijk even verteld dat de backend servers dus niet een cluster worden, omdat de storage groups dan te groot zouden worden!

Clusteren is ons door de Microsoft partner afgeraden... Schijnt dat Exchange clustering nogal brak is. De fallback wordt nu in geval van nood de 2 virtuele servers op dezelfde fysieke bak laten draaien

Cool, Welke partner heb je dan, want als ze dit zeggen moeten ze misschien toch eens verder gaan testen.
Bij ons op het werk beheren we in ons team en de meeste andere microsoft teams, alleen maar Exchange als clusters. Het enige probleem wat we hebben gehad, was een onstabiele virusscanner. Deze veroorzaakte een hoop shit.
Voor de rest draaien de meeste Exchange clusters gewoon Windows 2003 Gold en Exchange SP1 of SP2. Zijn ook bezig met Geo clustering. Tot op heden geen problemen gehad.
Microsoft draaid trouwens zelf ook op een Cluster Exchange.

Zoals al door eerdere personen gemeld, we hebben ernstig onze twijfles over de MS partner. Misschien kunnen heb niet goed een Exchange Cluster stabiel krijgen. Maar Exchange op een Cluster is zeker stabiel. Zolang het maar goed geinstalleerd is op gecertificeerde hardware.

En wat de storage groups betreft, de grootte is niet vanwege fysieke limitaties, maar vanwege de tijd die nodig is om in geval van corruptie of verlies van de SU de groep in een redelijke (<12 uur) tijd terug te zetten. Dat betekent teruglezen van tape en lsinteg draaien. Dan kan je geen enorme groups hebben...

We hebben bij ons bijna altijd een SLA van 4 uur. Hierin redden we zonder moeite een restore 20-30Gb per Mailbox Store. Dit hebben we altijd binnen een uur gedaan. Voor het restoren van een mailbox doen we dit via de RSG. Dus dit wordt regelmatig getest.

Ik zou echt voor de simpele aanpak gaan. Koop één 4-Dual-Core-CPU machine met plenty RAM en een leuk RAID-1 Boot Setje en draai daar de Active Exchange Node op. Kan makkelijk 2500 users aan. Zet daarbij een simpele 2-Dual-Core-CPU machine met Raid-1 Boot, en zet die in als Passive node. Als je Active Node weg valt is er qua performance wel een dipje, maar dat is te aanvaarden. Kost minder, en is net zo goed. Stores op SAN, Quorum op SAN en gaan met die banaan.

Hmmm, zou ik nooit voor gaan. Verschillende hardware is vragen om problemen naar mijn gevoel. Je hoeft voor 2500 mailboxen ook meestal niet een 3node cluster te draaien. 2500Mailboxen kan meestal gemakkelijk op een 2node A/P cluster. Om de 2de server gelijk te maken aan de eerste maakt ook kosten technisch niet zoveel uit. Een DL380 met dual HBA, Dual NIC, 4GB kost rond de 6500 Euro. Of je 2de node nu 4500 of 6500 kost, maakt ook niet echt uit kosten technisch. Zeker niet op dit soort projecten.

[Aetje]

Rolfie schreef op donderdag 25 mei 2006 @ 22:40:
Cool, Welke partner heb je dan, want als ze dit zeggen moeten ze misschien toch eens verder gaan testen.
Bij ons op het werk beheren we in ons team en de meeste andere microsoft teams, alleen maar Exchange als clusters. Het enige probleem wat we hebben gehad, was een onstabiele virusscanner. Deze veroorzaakte een hoop shit.
Voor de rest draaien de meeste Exchange clusters gewoon Windows 2003 Gold en Exchange SP1 of SP2. Zijn ook bezig met Geo clustering. Tot op heden geen problemen gehad.
Microsoft draaid trouwens zelf ook op een Cluster Exchange.

Vanwege confidentiality kan ik weinig details melden, inclusief welk bedrijf.

Zoals al door eerdere personen gemeld, we hebben ernstig onze twijfles over de MS partner. Misschien kunnen heb niet goed een Exchange Cluster stabiel krijgen. Maar Exchange op een Cluster is zeker stabiel. Zolang het maar goed geinstalleerd is op gecertificeerde hardware.

Het zootje gaat op Dell Poweredges draaien. Welk type weet ik nog niet, maar iig met ruim voldoende specs voor de load (gebaseerd op stats van Microsoft zelf).

We hebben bij ons bijna altijd een SLA van 4 uur. Hierin redden we zonder moeite een restore 20-30Gb per Mailbox Store. Dit hebben we altijd binnen een uur gedaan. Voor het restoren van een mailbox doen we dit via de RSG. Dus dit wordt regelmatig getest.

Wat is RSG? En welk type backupmedium en welke software gebruik je (indien je dat mag vermelden?) Ik ga zodra deze zaak geinstalleerd is het een en ander benchmarken. En ik heb aangegeven dat ik de optie wil hebben om later toch nog naar een cluster over te gaan (dmv een extra 2 servers in te zetten en dan het cluster op te zetten).

Wat ik me toch afvraag is of dit mogelijk is om dit te doen op een later tijdstip, terwijl de servers al een behoorlijke hoeveelheid content hebben...

Hmmm, zou ik nooit voor gaan. Verschillende hardware is vragen om problemen naar mijn gevoel. Je hoeft voor 2500 mailboxen ook meestal niet een 3node cluster te draaien. 2500Mailboxen kan meestal gemakkelijk op een 2node A/P cluster. Om de 2de server gelijk te maken aan de eerste maakt ook kosten technisch niet zoveel uit. Een DL380 met dual HBA, Dual NIC, 4GB kost rond de 6500 Euro. Of je 2de node nu 4500 of 6500 kost, maakt ook niet echt uit kosten technisch. Zeker niet op dit soort projecten.

We gaan al twee van ongeveer die specs server kopen. Raid 1 partitie voor de logs, 2e raid 1 voor het OS en de exchange software, virusscanner enzo... En dan de storage groups op de SAN. Maar de beslissing lijkt op het moment al uit te vallen naar 2 standalone servers. *zucht* en omdat het niet mijn beslissing, maar uiteindelijk die van de klant is zal mijn gemekker op dovemansoren vallen. Naja, als de mailbox restores maar lekker lopen, dan zal het allemaal wel goed gaan. Zodra de hardware en software allemaal geinstalleerd is ga ik daar ns grondig op oefenen... (Storage group 38: Testing. )

[Rolfie]

Vanwege confidentiality kan ik weinig details melden, inclusief welk bedrijf.

Logisch.

Wat is RSG?

RSG staat voor Recovery Storage Group. Waar dit op neer komt is, je hoeft niet meer bricklevel backup te doen, om gemakkelijk 1 mailbox te restoren. Je kan gewoon een complete database restoren naar een RSG, en daarna de data van die mailbox er uit trekken.
Voor meer infomatie hier over:
MS Exchange BLOG: The Recovery Storage Group
Recover mailboxes with Exchange 2003 Recovery Storage Groups
Restoring the Mailbox Store from Backup.

En welk type backupmedium en welke software gebruik je

We gebruiken 2 producten (beheren verschillende klanten), Legato networker 7.X, en HP Dataprotector 5.5. Ik vind persoonlijk Legato beter en gemakkelijker werken. Maar HP doet zijn werk ook goed. We backupen serverless via FC direct naar de ESL omgeving van HP. Hierin zitten geloof ik LTO2 tapesteamers in.

En ik heb aangegeven dat ik de optie wil hebben om later toch nog naar een cluster over te gaan (dmv een extra 2 servers in te zetten en dan het cluster op te zetten).

Een hoop werk . Als je het nu kunt doen doe het dan. Anders kost het je een hoop geld. Je moet alles opnieuw opbouwen en testen (Backup, Virusscanner implementatie)
Je kan daarna je mailboxen moven per stuk, maar daardoor wordt je IS (Information Store) wel een stuk groter. Volgens mij zou je wel een full restore kunnen doen naar je cluster. Dit zou denk ik ook moeten werken. Maar zeker weet ik dit niet helemaal.
Hoe dan ook het kost je een hoop extra €€€€.

We gaan al twee van ongeveer die specs server kopen. Raid 1 partitie voor de logs, 2e raid 1 voor het OS en de exchange software, virusscanner enzo... En dan de storage groups op de SAN.

met de Logs bedoel je daarme de Exchange logs? Want die wil je echt op het SAN hebben staan. Hoe sneller hoe beter. Je Exchange omgeving is net zo snel als de log files verwerkt kunnen worden. Je logfiles bevatten ook al je transacties van tot de laatste backup van de IS. Als je databases dus uitvallen en je hebt de log files nog steeds. Dan restore je gewoon de Database van de dag er voor en laat de "Nieuwere" logfiles gewoon staan. Je hebt dan dus totaal geen dataverlies. Je Exchange logfiles zijn dus het meest belangrijkste van Exchange. (ik mag hopen dat het consultancybedrijf dit ook niet zo geadviseerd heeft, al zou ik er niet raar van staan te kijken).

[ Voor 39% gewijzigd door Rolfie op 28-05-2006 12:44 ]

[Aetje]

Rolfie schreef op zondag 28 mei 2006 @ 12:34:
RSG staat voor Recovery Storage Group. Waar dit op neer komt is, je hoeft niet meer bricklevel backup te doen, om gemakkelijk 1 mailbox te restoren. Je kan gewoon een complete database restoren naar een RSG, en daarna de data van die mailbox er uit trekken.
Voor meer infomatie hier over:
MS Exchange BLOG: The Recovery Storage Group
Recover mailboxes with Exchange 2003 Recovery Storage Groups
Restoring the Mailbox Store from Backup.

Dank, daar ga ik me eens in verdiepen

Een hoop werk . Als je het nu kunt doen doe het dan. Anders kost het je een hoop geld. Je moet alles opnieuw opbouwen en testen (Backup, Virusscanner implementatie)
Je kan daarna je mailboxen moven per stuk, maar daardoor wordt je IS (Information Store) wel een stuk groter. Volgens mij zou je wel een full restore kunnen doen naar je cluster. Dit zou denk ik ook moeten werken. Maar zeker weet ik dit niet helemaal.
Hoe dan ook het kost je een hoop extra €€€€.

Nu gaat het niet lukken. De klant wil er simpel niet de $ (niet E in my case) voor ophoesten, en ik vermoed tot het een paar keer goed mis gaat dat dat niet gaat gebeuren ook. Maar ik denk dat er maar 1 keer de 911 uit hoeft te vallen en dan gaat er extra $ voor uitgetrokken worden.

met de Logs bedoel je daarme de Exchange logs? Want die wil je echt op het SAN hebben staan. Hoe sneller hoe beter. Je Exchange omgeving is net zo snel als de log files verwerkt kunnen worden. Je logfiles bevatten ook al je transacties van tot de laatste backup van de IS. Als je databases dus uitvallen en je hebt de log files nog steeds. Dan restore je gewoon de Database van de dag er voor en laat de "Nieuwere" logfiles gewoon staan. Je hebt dan dus totaal geen dataverlies. Je Exchange logfiles zijn dus het meest belangrijkste van Exchange. (ik mag hopen dat het consultancybedrijf dit ook niet zo geadviseerd heeft, al zou ik er niet raar van staan te kijken).

Dit is inderdaad letterlijk het advies van het consultatie bedrijf. Logs lokaal op n Raid partitie per server. Jij adviseert deze ook op de SAN te poten?

[Rolfie]

Dit is inderdaad letterlijk het advies van het consultatie bedrijf. Logs lokaal op n Raid partitie per server. Jij adviseert deze ook op de SAN te poten?

Je SAN is stabieler en sneller dan je DAS (Direct Attatched Storage). Immers er zit een veel grotere Cache module in, bestaat uit meer schijven, wordt beter gemonitoord, Meer bandbreedte (320/2Gb), redudantie kanalen (indien meerdere HBA's).
Die DAS schijven gaan een keer kapot, er je zal niet de eerste zijn die daar door zijn server onderuit ziet gaan. Bij een SAN heb ik dat nog niet zien gebeuren.
Exchange is net zo snel als je transactie logs verwerkt kunnen worden. Alle transacties worden eerst in de logfiles weg geschreven. Als dat dus traag gaat dan is de rest van Exchange ook traag. Daarom is het advies van Microsoft om hier altijd een aparte mirror voor te nemen. Een apparte mirror is het snelste voor Exchange.

Ik zou het dus zeker op het SAN plaatsen.

PS. Zit er bij je server wel een Write Cache Array controller?

[richard_kraal]

Rolfie schreef op maandag 29 mei 2006 @ 08:24:
[...]
Meer bandbreedte (320/2Gb)

Scsi U320 320MB = 2,5Gbit

2gbit is dus NIET sneller dan DAS, of zie ik nu iets over het hoofd

blijf zelf op dit moment nog steeds hangen op DAS, waarom, dikke controller x een aantal kanalen (bv hp msa30 DP) dan haal je zo 1GB p/s

[ Voor 3% gewijzigd door richard_kraal op 29-05-2006 15:58 ]

[Rolfie]

richardkraal schreef op maandag 29 mei 2006 @ 15:57:
[...]


Scsi U320 320MB = 2,5Gbit

2gbit is dus NIET sneller dan DAS, of zie ik nu iets over het hoofd

blijf zelf op dit moment nog steeds hangen op DAS, waarom, dikke controller x een aantal kanalen (bv hp msa30 DP) dan haal je zo 1GB p/s

Als je puur op SCSI bandreedte kijkt, dan is SAN met FC2Gb iets trager. Daarin tegen je hebt FC ook al voor 4Gb . U320 is dan weer trager.

Je kan inderdaad een 6404 controller met 2 kanalen aansturen op een msa30 (eventueel nu al 4 kanalen). Als je dan echter verder kijkt, met HBA kan je load balancing doen over meerdere kanalen (met Securepath). Je kan dus in theorie 2 of nog meer kanalen bundelen naar 1 LUN.
Een EVA4000 heeft een maximum doorvoor snelheid 335, Een EVA8000 kan al 1500Mb aan. De XP noem ik maar niet.

Een SAN heeft ook al gauw meer cache (HP SA6400:254Mb512Mb, Instap HP SAN MS1000:512B, EVA:4Gb, XP12000:128Gb). Dat maakt wel een verschil. Dan gaan we maar nog niet naar de XP systemen toe. Dat is helemaal niet te vergelijken.

Ik zie een DAS systeem ook niet even 30,000 IOPs (MSA1000) 141,000 IOPs (EVA4000) of 1,900,000 (XP12000 disk, Mte de Cache red je 1,900,000 IOPs) doen. Hier draaid het uit eindelijk om. Hoeveel IOPs je schijven aan kunnen. Het is mooi om te zeggen dat je U320schijven er in hebt zitten, maar qua performance kan een U160schijf sneller zijn.

Je SAN verlicht ook je systeem, immers het hoeft minder rekenkracht te hebben. Er zit minder inteligentie op de server, en meer op het SAN. Op je SAN kan je gewoon zeggen ik moet 2000 IOPs aankunnen, op hoeveel schijven het SAN dit moet doen, wel dat rekend het SAN wel voor je uit. DIt is ook niet interesant voor jouw als Exchange beheerder. Jij wilt alleen maar die IOPs hebben.

Ik heb Exchange servers gezien die een 18Gb schijf aan het rebuilden was, en daar 24uur over deed (was niet leuk om te zien dat er 2 schijven defect waren). Een SAN zou daar vele vele malen korter over doen. Waarbij de server veel minder belast mee wordt. Immers de SA (Smart Array Controller) hoeft nu niet de berekening uit voeren.

Ik zeg niet dat DAS slechter is dan SAN. het hangt er al een vanaf wat wil je precies. Een SAN bied betere door groei mogelijkheden, performance is het veel veel sneller. Ik heb al diverse server een stuk sneller zien werken nadat we de DAS omgezet hadden naar een SAN. Zeker als je het over TB omgevingen gaat hebben, dan is een SAN gewoon beter. Je server laten booten van een DAS, en je data op het SAN zetten. Je moet er alleen wel de mogelijkheid voor hebben. Als je nog niets hebt liggen dan zijn de kosten zeer hoog. Daarom moet je kijken of een SAN of een DAS oplossing beter is. Heb je 1 of 5 server draaien dan moet je je afvragen of een SAN wel geschikt is voor je. Maar als je over bv 30server praat en over een 19Tb oplossing, dan wel je dit echt niet op DAS hebben draaien. Al kan een DAS systeem dit ook goed aan, maar ik zou het niet onder mijn beheer willen hebben.

Er zijn ook verschillende SAN mogelijkheiden, van instap (EVA1000) tot HighEnd (XP12000). Prijstechnisch zit hier een verschilletje in. Maar een EVA4000 is redelijk goed te betalen, en is ongeloofelijk snel.
We gaan nu bijvoorbeel een SAN (EVA4000) neer zetten bij een klant waar nu 2 fileservers met 1Tb aan data beschikbaar is. Het zijn performance technisch zeer goede machines met zware array controllers. Maar ze trekken het niet. Helemaal niet als er een schijf uit valt. Een SAN lacht hierom. Dit is geen belasting voor een SAN en 2TB aan opslag is ook om te lachen.


Maar om weer ontopic te komen, Plaats je logfiles lekker op het SAN. Hier ga je geen spijt van krijgen.

[Aetje]

Ik ga eens met het netwerkteam/serverbeheerders overleggen of we de logs ook ergens op de SAN kunnen plaatsen. Spaart een paar schijven en een controller op de server uit. En de SAN is op het moment ver underused...

Het enige risico dat je dan hebt is dat als ooit de SAN onderuit gaat je de transaction logs niet ergens anders vandaan kan halen. Maar wat de schaal betreft, ik herhaal: 4 domeinen, pak 'm beet 2.500 mailboxen totaal. Ik schat de load in op rond de 1750 users actief gebruik van outlook, waarbij als we het ze toe gaan laten er gegarandeerd enkele megabytes per mail rond gaan vliegen... Storage per mailbox gaat op 200MB gecapped worden, max per mail op 10MB. Dit alles gaat draaien op 2 backend servers, en 1 frontend. Deze servers gaan waarschijnlijk gevirtualiseerd worden om het geheel makkelijker terug te kunnen zetten in geval van disaster. (Nu ik het me bedenk, dan is de transaction logs op de SAN handiger, minder storage in de virtual server).
Eventueel gaan er later nog 2 extra domeinen bij komen op de servers, met vrij weinig users. Takken van de enterprise die momenteel hun eigen mail en server beheren... Dat of die gaan een eigen exchange server krijgen en door onze frontend heen. (Dan hebben we 4 backends dus totaal, waarvan ik er 2 beheren ga).

[Rolfie]

Het enige risico dat je dan hebt is dat als ooit de SAN onderuit gaat je de transaction logs niet ergens anders vandaan kan halen.

Ik heb 1 keer van me leven een SAN onderuit zien gaan. Maar wel meerdere keren DAS servers plat zien gaan, met data verlies. De kans dus dat het SAN plat zal gaan is zeer klein.

[Qwerty-273]

Ik heb al verschillende keren een SAN onderuit zien gaan, al was dat meer te wijten aan de beheerders dan aan de SAN zelf. Volgens de instuctie van HP kon on the fly een processor worden vervangen van de SAN (helaas weet ik het type niet meer) omdat er meerdere aanwezig waren enz. Alleen in de eerste firmware was deze functie nog niet compleet geactiveerd. Aangezien ze de firmware die avond pas gingen vervangen en ze wel in de productie tijd de processor hebben vervangen lag het complete systeem plat voor een half uur.
Maar jah dat is ook niet echt toe te wijzen aan de SAN

Jammer genoeg op huidige plek is er geen budget vrij voor een SAN. Of een deftige fall-back oplossing. Maar daar wordt druk aan gewerkt gelukkig in de overleggen. Dus eindelijk eind van dit jaar? hopen, hopen, hopen.

[Aetje]

Mja, SAN is iig betrouwbaarder dan DAS. Ik heb met de netwerk en serverbeheerders gesproken en waarschijnlijk gaan we die logjes dus lekker op de SAN plaatsen.

En als de SAN ooit dood gaat (enige wat ik me kan bedenken is als de rivier hier dichtbij flink buiten de oevers treedt, de serverroom is in de kelder hier) denk ik dat het verlies van emails niet de meest dringende zaak zal zijn