Exchange invoer/uitvoer leesvoer


Een van de grotere uitdagingen bij het ontwerpen van een Exchange serverinstallatie is storage.
In Exchange 2007 luistert dit welliswaar een stuk minder zwaar, maar het is wel handig om wat meer te weten over hoe Exchange gebruik maakt van de beschikbare storage.


Voordat ik begin met de uitleg, wil ik even melden dat ik geen storage expert ben, en dat er misschien een schoonheidfoutje in mijn uitleg is geslopen. Ik stel het daarom ook zeer op prijs als iemand mij, waar nodig, verbeteringen toestuurt


More...
Zoals je al weet slaat Exchange alle mail op in een database. Het maakt gebruik van de Extensible Storage Engine (ook wel JET-Blue, een doorontwikkelde versie is van de aloude JET engine die Microsoft Access databases aanstuurt), wat hetzelfde database management systeem is als waar Active Directory op draait. De Exchange databases bestaan uit een aantal database bestanden en logfiles. ESE maakt gebruik van log recovery om te herstellen van corruptie in de database. Hierbij worden de logfiles replayed op de database om zo weer een consistente staat terug te keren. Om dit te bereiken wordt elke transactie eerst weggeschreven in een logfile alvorens het gecommit kan worden naar de database. Erg veel I/O dus. Zelfs zo veel dat een database al snel te traag zou worden, en niet meer werkzaam zou zijn als er geen maatregelen genomen zouden worden om de I/O footprint te beperken.
Om de performance op te schroeven, maakt ESE gebruik van een databasecache in het fysieke geheugen, dit is namelijk vele malen sneller dan disk (zoeksnelheid = nanoseconden ipv miliseconden). Via een slim algoritm wordt er geprobeerd de juiste data in het geheugen te houden, want uiteraard kan niet de hele database gecached worden. Dit is zeker het geval voor Exchange 200x, waar we te maken hebben met een limiet van 4GB aan geheugen wat een 32 bits platform kan addresseren. Hiervan is standaard 2GB in gebruik door het besturingssysteem. Via de /3GB en /USERVA switches kunnen we dit beperken tot 1GB, waardoor er 3GB overblijft voor applicaties. De cache was default beperkt tot 900MB, maar kon via het registry opgeschroeft worden naar maximaal 1,2GB. Dit in tegenstelling tot Exchange 2007 welke in principe terabytes kunnen cachen doordat het draait op een 64 bits platform. Aangezien elke transactie eerst veilig naar een logfile wordt geschreven kan er gemakkelijk gewerkt worden met een deel van de database in het geheugen; mocht er immers wat verkeerd gaan, hebben we altijd de logfiles nog. Microsoft adviseert om met Exchange 2007 extra rekening te houden met de cache en je voordeel eruit te trekken. Een simpel ezelsbruggetje voor het schalen van geheugen voor Exchange 2007 is dan ook: 2GB voor Exchange + 2-5MB cache per user. Een 3000 user server heeft dus tussen de 9 en 17GB geheugen nodig. Een ander principe wat hierdoor mogelijk is is 'Checkpoint Depth' wat inhoudt dat er een deel van de logfiles in geheugen gehouden wordt, en met een vertraging naar de database geschreven wordt. Meestal zijn het een aantal logfiles, wat de database achterloopt. Waar is dat nou goed voor zou je denken... nou het bespaart aanzienlijk wat I/O. Doordat Exchange een verzameling transacties in geheugen houdt alvorens het ze wegschrijft naar de database, kan het veelal voordeel halen uit het analyseren ervan. Zo kunnen bepaalde transacties elkaar opheffen en kunnen transacties dusdanig geordend worden dat ze op efficiente manier verwerkt kunnen worden.
...page...
Dus door gebruik te maken van cache en checkpoint depth, zorgt Exchange dat het aantal I/O's op de database beperkt blijft. De database I/O's zorgen altijd voor de meeste problemen, omdat deze willekeurig zijn. De schrijfkoppen op je disken zijn continu van de ene kant naar de andere kant aan het verplaatsen. Dit zorgt ervoor dat de gemiddelde seek time (positioneren van de schrijf/lees kop) per I/O vele malen hoger is dan bij logfiles, waar data sequentieel geschreven en gelezen wordt. Dit resulteert in een lager aantal I/O operaties per seconde (IOPS). Door dit verschil in type datatoegang is het raadzaam (ik zeg liever verplicht) om database partities en logpartities fysiek van elkaar te scheiden en dus te hosten op aparte LUNS (logical Units Numbers = diskdevice; hetzij een array, hetzij een drive). Het mixen van willekeurige en sequentiele datatoegang is dodelijk voor je prestaties.


Bij het berekenen van de storage vereisten voor Exchange servers wordt er maar al te graag gerekend in IOPS, en ik zal bij deze uitleg hier ook vanuit gaan. Hoeveel IOPS je nodig hebt is sterk afhankelijk van hoeveel gebruikers je gaat hosten en wat voor soort gebruikers dit zijn. Wanneer je uitgaat van een bestaande Exchange omgeving kan je dit berekenen door het aantal READS en WRITES te delen door het aantal gebruikers. Hierbij kan je gebruik maken van de 'PhysicalDisk\Disk Reads' en 'PhysicalDisk\Disk Writes' (Hierbij ga ik ervanuit dat een enkele LUN OF alleen gebruikt wordt voor Logs OF alleen gebruikt wordt voor Databases. Anders zal je met LogicalDisk counters moeten gaan werken, welke standaard uitgeschakeld zijn.) Een andere methode is door te kijken naar het aantal actieve gebruikers bij piekbelasting. Dit geeft een stuk nauwkeuriger beeld van het echte gebruik. Je kunt de actieve gebruikers zien in de System manager, wanneer je de database opzoekt en kijkt onder Logons. Ook kan je gebruik maken van de 'MSExchangIS\ Active Users' counter, echter deze counter vertekend heel erg als de server ook Public folders bevat, dus ik prefereer de eerste manier. Als je nu het aantal IOPS per user weet in de oude situatie en je vermenigvuldigd het met het aantal mailboxen waarop je de nieuwe databases wilt schalen, plus een extra 20% voor mogelijke groei, dan heb je een redelijk goed uitgangspunt voor de nieuwe situatie.


De formule is dus: ((Gemiddelde Reads/sec + Writes/sec) / (#(actieve)users) * (#users in nieuwe ontwerp)) * 1.2

Stel dus als je de database LUN wilt schalen op 3000 mailboxen en je bestaande server genereert gemiddeld 1500 reads en 500 writes bij een piekbelasting van 1000 users dan kom je uit op: ((1500)/(1000) * 3000) * 1.2 = 4800 IOPS.

LET WEL: Dit geldt alleen als je een upgrade doet met dezelfde versie van Exchange. en upgrade van Exchange 2003 naar 2007 gaat hierbij niet op, omdat de I/O vereisten van Exchange 2007 veel lager zijn. Uit de eerste berekeningen levert het een besparing op van 70%. Bij een upgrade naar een nieuwe versie zul je uit moeten gaan van de cijfers van Microsoft die ik hieronder zal behandelen.
...page...
Een andere manier om het benodigde aantal IOPS uit te rekenen is om uit te gaan van de cijfers die beschikbaar zijn.
Hierbij wordt er uit gegaan van een 'Online User', gebruik makend van Outlook. De cijfers van Exchange 2007 zijn gebaseerd op een configuratie waar er per mailbox 5MB cache beschikbaar is.


De cijfers zijn als volgt:










Exchange mailbox IOPS

Gemiddelde IOPS/Gebruiker

Exchange 2K7
Exchange 2K3
Mailflow

Lichte
Gebruiker
0.07
0.18
10 uit
50 in

Standaard
Gebruiker
0.12
0.4
20 uit
100 in

Zware
Gebruiker
0.33
0.75
30 uit
150 in


We kunnen nu dezelfde formule gebruiken om aan het aantal benodigde IOPs te komen. Let wel, dit zijn cijfers voor gebuikers met een normale online Outlook client. Veel bedrijven gebruiken een scala aan andere interfaces voor hun mailbox, zoals Blackberry, Outlook Web Access en Active Sync. Dit levert hele andere I/O profielen op. Voor Blackberry en OWA moet je het verbruik van een normale Outlook client met resp. factor 4 en 2 vermenigvuldigen. Cached Mode Outlook clients en Active Sync leveren weer de helft besparing op. Hou hier dus wel rekening mee!


Nu we weten wat we nodig hebben, moeten we een storageoplossing kiezen die dit gaat bieden. Hierbij zijn eigenlijk twee dingen echt belangrijk. Dit is onafhankelijk van welk storageconcept je kiest:


  • Maximale bruikbare Disk Throughput
    Elk type disk heeft zo z'n eigen throughput

  • Transport latency
    Of je nu fiber gebruikt of DAS, ISCSI, elke controller en transportprotocol heeft een bepaald effect op de uiteindelijk read- en write times van je applicatie

  • De keuze voor het RAID level is mede bepalend welke hardware je aanschaft of voor welk concept je kiest. Het beperkt namelijk de maximale bruikbare throughput van je disken. Een formule om deze throughput te berekenen is de volgende van Nicolle Alen:



    Estimated maximum throughput = D * F * T
    D = Disk speed. The maximum rate of IOPS measured by the disk manufacturer.
    F = Fudge factor. This is necessary to plan for enough IO to handle occasional extremely high loads.
    T = RAID factor. This depends on the type of raid and the read/write ratio.


    Bij bovenstaande formule is de T denk ik de grote onbekende. De andere twee spreken voor zich. De T is de mate waarin het RAID Level de effectieve database IOPS beperkt. Bij RAID 5 bijvoorbeeld levert elke Write actie 4 IOPS op. 1 IOP voor het lezen van de parity, 1 voor het lezen van het te wijzigen block data (nodig voor parity berekening), 1 voor het overschrijven van de data, 1 voor het schrijven van de parity. Dit zijn dus 3 verloren IOPS. Bij RAID 10 zijn er twee IOPS per write. Hij schrijft het immers naar beide mirrors weg. De RAID factor is als volgt te berekenen.


    RAID10 : T = (R + W)/(R + 2W)
    RAID5 : T = (R + W)/(R + 4W)


    Als we dan even terugkomen op onze eerste meting, waar een server met 1000 users 1500 reads en 500 writes genereerde. Dan komen we met RAID10 op (1500 + 500)/(1500 + 1000) = 2000/2500 = 0.8. Bij RAID5 komen we op (1500 + 500)/(1500 + 2000) = 2000/3500 = 0.57
    ...page...
    Dit is heel leuk, als we bij dezelfde Exchange versie bleven. Het meten van reads en writes is - zoals we al eerder vermelden - natuurlijk niet representatief als we van Exchange versie gaan wisselen. In deze situatie kunnen we van het volgende uitgaan.


    Exchange 2003 heeft een read:write ratio van 2:1. Exchange 2007 zou, mits het goed geschaald is in termen van memory en cpu een ratio van 1:1 kunnen halen. Gebruik makend van deze ratio's kunnen we de formule als volgt aanpassen:


    Voor Exchange 2003 met een read:write ratio van 3:1 is de RAID factor:


    RAID5
    T = (Read + Write)/(Read+4*Write)
    T = (2+1)/(2+4*1) = 3/6 = 0.5
    RAID10
    T = (Read + Write)/(Read+2*Write)
    T = (2+1)/(2+2*1) = 3/4 = 0,75


    Voor Exchange 2007 met een read:write ratio van 1:1 is de RAID factor:
    RAID5
    T = (Read + Write)/(Read+4*Write)
    T = (1+1)/(1+4*1) = 2/5 = 0.4
    RAID10
    T = (Read + Write)/(Read+2*Write)
    T = (1+1)/(1+2*1) = 2/3 = 0.66


    Nu zal je meteen denken ... HUHHHHHHHHH ... Hoe kan in godsnaam de RAID factor bij Exchange 2007 lager uitvallen en dus de throughput van een disk negatief beinvloeden ten opzichte van Exchange 2003???!!!!?
    Nou... dat zit zo. We hebben het hier over de maximale BRUIKBARE throughput van je disken. In Exchange 2007 is het aantal writes ten opzichte van het aantal reads op de disken toegenomen, en zijn het aantal verloren IOPS dus gegroeid in opzichte van de Exchange reads en writes. Een disk kan voor Exchange 2007 dus minder bruikbare throughput genereren. Hier staat echter wel tegenover dat Exchange 2007 veel minder IOPS nodig heeft.


    Wanneer we nu de formule volgen krijgen komen we bij een disk met een maximale throughput van 150 IOPS dus op de volgende berekeningen:


    Estimated maximum throughput = D * F * T


    Exchange 2003 RAID5
    150 * 0,8 * 0.5 = 60
    Exchange 2003 RAID10
    150 * 0,8 * 0,75 = 90
    Exchange 2007 RAID5
    150 * 0,8 * 0.4 = 48
    Exchange 2007 RAID 10
    150 * 0,8 * 0.66 = 79,2
    ...page...
    Nu we weten wat het maximale aantal bruikbare IOPS we hebben bij een bepaald RAID level, kunnen we gaan berekenen hoeveel disken we nodig hebben. Stel we gaan uit van 1000 lichte, 1000 standaard en 1000 zware gebruikers op 1 server, dan hebben we:


    Exchange 2003
    Benodigde User IOPS = (1000*0,18) + (1000*0,4) + (1000*0,75) = 1130
    Benodigde RAID 5 disken = 1130/60 = 18,8
    Benodigde RAID 10 disken = 1130/90 = 12,5
    Exchange 2007
    Benodigde User IOPS = (1000*0,07) + (1000*0,12) + (1000*0,33) = 520
    Benodigde RAID 5 disken = 520/48= 10,8
    Benodigde RAID 10 disken = 520/79,2 = 6,6


    Zo zie je maar... Toch een aardig verschil, maar niet zo groot als het verschil in benodigde UserIOPS....
    Nu is deze vergelijking niet helemaal eerlijk. Het verschil in aantal disken gaat niet helemaal op. Er is namelijk een verschil in het gemiddelde aantal IOPS dat een disk kan genereren voor hetzij Exchange 2003, hetzij Exchange 2007. Dit heeft te maken met een aantal verbeteringen in Exchange 2007 die ervoor zorgen dat I/O requests beter gecombineerd kunnen worden in 1 IOP, wat betekent dat er efficienter omgegaan wordt met het readen en writen van data, wat een er dus voor zorgt dat de de I/O iets minder willekeurig wordt en er dus iets meer IOPS uit een disk gehaald kunnen worden. Dit scheelt echter geen tientallen IOPS, heb ik me laten vertellen. Het verschil met eenzelfde type disk, zal dus - in geval van Exchange - minimaal hoger uitvallen.


    We kunnen dit bij benadering berekenen. Er bestaat namelijk een Formule om het gemiddelde aantal IOPS voor een disk te berekenen. Deze is als volgt:


    IOPS = (1/((gemiddelde seektime ms) + (0,5 / (rotaties per seconden)) + (dataeenheid per IOP) / (dataeenheid per ms doorvoorsnelheid))*1000


    Twee 15K disken van HP hebben de volgende specificaties:























    # SAS 15K SCSI 15K
    Type HP SAS 72GB 2.5" 15K HP 72GB U320 15K
    Transfer Rate Synchronous (Maximum) 3 Gb/sec 320 MB/sec
    Seek Time avg 3.0 ms 3.8 ms
    Rotational Speed 15000 rpm / 2500 rps 15000 rpm / 2500 rps

    ...page...
    Als we daarbij weten dat Exchange 2007 met elke I/O tussen de 8KB en 1MB data verwerkt (8KB is 1 databasepage, wat de minimale werkeenheid is. 1MB is wat in het meest gunstige geval gecombineerd kan worden aan IO in 1 enkele operatie. Voor Exchange 2003 ligt het tussen de 4KB en 512KB), kunnen we de volgende berekening maken:























    # SAS 15K SCSI 15K
    Exchange 2007 max (1/(3.0ms + (0.5 / 0.25 rpms) + (8KB / 3072KB/ms))*1000 = 199 (1/(3.8ms + (0.5 / 0.25 rpms) + (8KB / 327KB/ms))*1000 = 171
    Exchang 2007 min (1/(3.0ms + (0.5 / 0.25 rpms) + (1MB / 3MB/ms))*1000 = 187 (1/(3.8ms + (0.5 / 0.25 rpms) + (1MB / 0.31MB/ms))*1000 = 112
    Exchange 2003 max (1/(3.0ms + (0.5 / 0.25 rpms) + (4KB / 3072KB/ms))*1000 = 200 (1/(3.8ms + (0.5 / 0.25 rpms) + (4KB / 327KB/ms))*1000 = 172
    Exchange 2003 min (1/(3.0ms + (0.5 / 0.25 rpms) + (512KB / 3072KB/ms))*1000 = 193 (1/(3.8ms + (0.5 / 0.25 rpms) + (512KB / 327KB/ms))*1000 = 135

    Zo hebben we bij benadering de maximale IOPS berekend van een disk (zonder rekening te houden met RAID en FUDGE factor). Heel interessant is het om te zien dat de hoge doorvoersnelheid van SAS het verlies tussen grote en kleine IO's drastisch vermindert ten opzichte van SCSI.


    Nu we weten hoeveel disken we nodig hebben voor ons ontwerp moet je ervoor zorgen dat de controller en het storageprotocol het wel aankan. Hiervoor geldt de volgende formule:


    IOPS = (1/((vertraging in ms) + ((dataeenheid per IOP) / (dataeenheid per ms doorvoorsnelheid))))*1000


    Bij deze formule moet je er alleen op letten dat je te maken hebt met meerdere doorvoersnelheden, namelijk de doorvoersnelheid van de controller met de disken, en de doorvoersnelheid van de controller naar de interne bussen van je systeem. Het ligt er een beetje aan welk type storageoplossing je kiest, om te weten wat de beperkende factor is. Je kunt ze eigenlijk het beste beiden berekenen, maar eigenlijk kan je er meestal wel vanuit gaan, dat als je throughput naar je disken voldoende is, de throughput naar de interne bussen ook wel in verhouding is. Je kunt ze tevens beiden in positieve zin beinvloeden door een grotere cache op de controller te nemen. Tevens hebben nagenoeg alle moderne IO controllers een eigen I/O processor.
    De vertraging in ms is meestal niet te vinden in specificaties van de leverancier, maar voor controllers gebruikt in DAS configuraties is dat meestal < 1ms. Voor het gemak neem ik 1ms.


    Als voorbeeld nemen we nu de HP Smart Array P600 controller, een veelgebruikte SAS controller van Hewlet Packard. Deze heeft 4 porten met elk 3GB/s doorvoersnelheid. Daarnaast is de doorvoersnelheid naar de PCI X bus van 1GB/s Wanneer we de berekening erop los laten komen we tot het volgende:























    # PCI X bus Storage
    Exchange 2007 max (1/(1.0ms + (8KB / 3072KB/ms))*1000 = 997 (1/(1.0ms + (8KB / 1048KB/ms))*1000 = 992
    Exchang 2007 min (1/(1.0ms + (1MB / 3.1MB/ms))*1000 = 756 (1/(1.0ms + (1MB / 1.024MB/ms))*1000 = 506
    Exchange 2003 max (1/(1.0ms + (4KB/ 3072KB/ms))*1000 = 998 (1/(1.0ms + (4KB / 1048KB/ms))*1000 = 996
    Exchange 2003 min (1/(1.0ms + (512KB/ 3072KB/ms))*1000 = 857 (1/(1.0ms + (512KB / 1048KB/ms))*1000 = 671

    ...page...
    Nu wel alle cijfers hebben, kunnen we bepalen of het aantal gebruikers wat we willen hosten kunnen servicen met de hardware die we gekozen hebben. Als we de eerder berekende cijfers er weer even bijpakken, zien we dat we met de SAS controller zeker een goede candidaat hebben. We hebben voor Exchange 2003 1130 IOPS nodig en voor Exchange 2007 520. Aangezien een aanzienlijk deel van de IOPS de PCI-X bus niet zal bereiken - dit omdat de hardwarematige controller een eigen I/O processor heeft - kunnen we met deze getallen redelijk zeker zijn dat deze controller voldoet aan de eisen. Elke port zou in principe tussen de 5 en de 7 disken kunnen aansturen, wat neerkomt op een totaal aantal disken van tussen de 20 en de 28. Voldoende dus want we hadden het volgende berekend:


    Exchange 2003
    Benodigde User IOPS = (1000*0,18) + (1000*0,4) + (1000*0,75) = 1130
    Benodigde RAID 5 disken = 1130/60 = 18,8
    Benodigde RAID 10 disken = 1130/90 = 12,5
    Exchange 2007
    Benodigde User IOPS = (1000*0,07) + (1000*0,12) + (1000*0,33) = 520
    Benodigde RAID 5 disken = 520/48= 10,8
    Benodigde RAID 10 disken = 520/79,2 = 6,6


    To zover een stukje uitleg over het berekenen van de I/O footprint en het bepalen van je gewenste throughput.....


    Voor Naslagwerken, kijk op:


    http://www.msexchange.org/tutorials/Art-Science-Sizing-Exchange2003-Part1.html


    http://technet.microsoft.com/en-us/library/6b3e1265-9d94-4fb4-bf4d-f037a0297871.aspx


    http://msexchangeteam.com/archive/2006/09/08/428860.aspx


    http://msexchangeteam.com/archive/2007/01/15/432199.aspx


    http://technet.microsoft.com/en-us/library/77045645-48f6-47ef-b32b-70f58d0392ab.aspx


    http://technet.microsoft.com/en-us/library/fa839f7d-f876-42c4-a335-338a1eb04d89.aspx


    http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032324207&Culture=en-US


    http://msexchangeteam.com/archive/2004/11/03/251743.aspx

    Comments (2)
    1. Anonymous says:

      Exchange invoer/uitvoer leesvoer Een van de grotere uitdagingen bij het ontwerpen van een Exchange serverinstallatie

    2. Anonymous says:

      Exchange invoer/uitvoer leesvoer Een van de grotere uitdagingen bij het ontwerpen van een Exchange serverinstallatie

    Comments are closed.

    Skip to main content