Just do I(nformation)T(echnology) : Exchange 2000

DTS flowchart

mpriem — Tue, 06 Nov 2007 18:20:00 GMT

Er zijn dit jaar een aantal wijzigingen geweest in de weken dat de zomer en winter tijd begint in verschillende regio's. Zo was er eerder dit jaar een wijziging voor de Amerikaanse tijdzones en is er nu een wijziging voor de tijdzones van Australie en Nieuw Zeeland. Op de Exchange team blog kwam ik een leuke flow chart tegen die ik jullie niet wilde onthouden.

Public folders managen op 2007 (pre-sp1)

mpriem — Wed, 30 May 2007 12:50:00 GMT

Het moge duidelijk zijn. Public folders managen in Exchange 2007 zonder sp1 is ruk. Toch kan je het jezelf makkelijk maken door gewoon de system manager te gebruiken van Exchange 2003. Echter er is 1 probleem... Je kan geen verbinding maken met een public folder store op een 2007 server... The requested operation is forbidden

Of toch wel?

Ja dus...

Om verbinding te leggen met een public folder store op een 2007 server met de System Manager van 2003 moet je het vereiste voor 128bits ssl encryptie van de ExAdmin en Public virtual directories halen op je Exchange 2007 server in de IIS manager.

Exchange 200[0|3] Performance threshholds

mpriem — Wed, 30 May 2007 12:47:00 GMT

Exchange server performance troubleshooting is in Exchange 2000|3 perfect beschreven op technet.

Voor Exchange 2007 is er echter nog geen revisie op dit artikel. Voor het troubleshooten is dat echter geen ramp aangezien je hiervoor de Troubleshooting Assistent hebt. Dit is echter bedoelt om een systeem te bewerken welke al live is.

Voor het pre-deployment testen van Exchange met bijv. Jetstress heb je echter wat meer achterliggende info nodig. Iemand bij Microsoft is zo aardig geweest alvast wat performance counters vrij te geven.

Disk Sub-system Thresholds	Performancetest	Stresstest
Data Disk Read Latency (average)	20 ms	20 ms
Data Disk Read Latency (maximum)	50 ms	100 ms
Data Disk Write Latency (average)	20 ms	20 ms
Data Disk Write Latency (maximum)	50 ms	50 ms
Log Disk Read Latency (average)	5 ms	5 ms
Log Disk Read Latency (minimum)	50 ms	50 ms
Log Disk Write Latency (average)	10 ms	10 ms
Log Disk Write Latency (maximum)	50 ms	100 ms
System Thresholds	Performancetest	Stresstest
% Processor Time (maximum)	90%	90%
% Processor Time (average)	80%	80%
Available Memory Bytes (minimum)	50 MB	50 MB
Page Table Entries (minimum)	5000	5000
Transition Pages Repurposed/Sec (average)	100	100
Memory Pages Per Sec (average)	100	100
Pool Nonpaged Bytes (maximum)	75 MB	75 MB
Pool Paged Bytes (maximum)	180 MB	180 MB
Database Page Fault Stalls Per Sec (average)	1.0	1.0

SMTP Reply & Status codes

mpriem — Wed, 30 May 2007 12:46:00 GMT

Tijdens het troubleshooten van mailservers zijn SMTP reply codes en SMTP status codes vaak waardevolle bronnen van informatie. Je moet echter wel begrijpen wat deze codes inhouden. Vandaar dat ik hier een overzicht post met de meest voorkomende codes.

Veelal zie ik SMTP reply codes en SMTP status codes door elkaar gebruikt worden alsof ze hetzelfde zijn. Dit is echter niet zo. De status codes zijn gespecificeerd in verschillende RFC's en door de jaren heen zijn er verschillende uitbreidingen geweest. Ik zal niet ingaan op RFC nummers, maar het zit als volgt. Een SMTP server heeft een aantal standaard reply codes om aan te geven wat de return waarde is bij een bepaald commando wat meegeven wordt tijdens de SMTP sessie. Zo is 250 een code wat aangeeft dat het commando met een positief resultaat is uitgevoerd. Deze codes zijn redelijk beperkt en door de jaren heen zijn er extra RFC's geschreven voor wat uitgebreidere status meldingen. Deze zijn echter niet als SMTP reply code geimplementeert in het SMTP protocol, maar worden als 'message' of 'comment' teruggegeven in combinatie met een SMTP reply code.

Een voorbeeld is:

550 5.7.1 Client does not have permissions to send as this sender

550 is de SMTP reply code en 5.7.1 is de status code van het systeem

Hieronder zal ik een tweetal overzichten posten:

Let wel... De response varieert van systeem tot systeem. Let vooral op de code en de daarbij horende uitleg. Het doel van een bepaalde code is vastgelegd in RFCs, en zal daardoor (bijna) altijd gelijk zijn

SMTP reply codes:

Code	Mogelijk response	Uitleg
200	(nonstandard success response, see rfc876)	Generieke succesvolle response
211	System status, or system help reply	Status of reactie op HELP
214	Help message	Comment of help bericht
220	Service ready	Service ready bericht, Je kan nu starten met invoeren van commando's
221	Service closing transmission channel	Exit bericht na succesvolle transmissie
250	Requested mail action okay, completed	Actie met success uitgevoerd
251	User not local; will forward to	Bericht wordt relayed
354	Start mail input; end with .	Je kan nu de content van het bericht invoeren
421	Service not available, closing transmission channel	Exit bericht na permissie probleem of andersoortig configuratie probleem
450	Requested mail action not taken: mailbox unavailable	Mailbox is niet beschikbaar melding
451	Requested action aborted: local error in processing	Interne fout
452	Requested action not taken: insufficient system storage	Storage of Memory probleem (voornamelijk het laatste)
500	Syntax error, command unrecognised	Commando bestaat niet
501	Syntax error in parameters or arguments	Syntax van commando klopt niet
502	Command not implemented	Commando wordt niet ondersteunt
503	Bad sequence of commands	Command kan op deze plaats niet uitgevoerd worden
504	Command parameter not implemented	Parameter wordt niet ondersteunt
521	does not accept mail (see rfc1846)	Het domein wordt hier niet gehost en relaying is niet toegestaan
530	Access denied	Permissie kwestie
550	Requested action not taken	Actie wordt niet uitgevoerd
551	User not local; please try	Mailbox bestaat niet, zend opnieuw met dit adres
552	Requested mail action aborted: exceeded storage allocation	Storage of Memory probleem (voornamelijk het laatste)
553	Requested action not taken: mailbox name not allowed	De zender mag niet zenden naar deze gebruiker
554	Transaction failed	Fout in de transactie

SMTP status codes:

Code	Mogelijk response	Uitleg
4.2.2	The recipient has exceeded their mailbox limit	Mailbox is vol
4.3.1	Not enough disk space on the delivery server	Het mailsysteem heeft geen ruimte meer (veelal geheugen probleem)
4.3.2	Please try again later	Veelal administratieve acties of antispam response
4.4.1	The host is not responding	De server reageert niet om onduidelijke redenen.
4.4.2	Bad connection	De verbinding weerhoudt het systeem ervan een volledige smtp sessie te voltooiten
4.4.6	Too many hops. Most likely the message is looping	Een mailloop is gedetecteerd op basis van recieved headers of het maximaal aantal hops is overschreden (15 E2K en 30 E2K3)
4.4.7	Problem with a timeout	maximale verzendtijd overschreden
4.4.9	temporary routing error or bad routing configuration	Routes zijn niet juist geconfigureerd
4.5.0	Requested mail action not taken: mailbox unavailable	Mailbox is (tijdelijk) niet beschikbaar
4.5.1	Requested action aborted: local error in processing	Commando syntax klop wordt niet juist uitgevoerd
4.5.2	Requested action not taken: insufficient system storage	Het mailsysteem heeft geen ruimte (veelal geheugen probleem)
4.6.5	Multi-language situation. Your server does not have the correct language code page installed	MIME conversie fout m.b.t. taal
5.0.0	Other undefined Status	Alles wat niet in de andere generieke status codes past
5.1.0	Other address status	Een generieke fout betreffende het emailadres
5.1.1	Bad destination mailbox address	De mailbox (deel links van de @) klopt niet of bestaat niet.
5.1.2	Bad destination system address	Het domein (deel rechts van de @) klopt niet of het systeem verantwoordelijk voor het domein werkt (tijdelijk) niet
5.1.3	Bad destination mailbox address syntax	De syntax van het emailadres klopt niet
5.1.4	Destination mailbox address ambiguous	Address matched meerdere mailboxen. Systemen als Exchange kunnen hier niet mee om gaan, anderen weer wel
5.1.5	Destination address valid	Het emailadres is valide en geaccepteerd
5.1.6	Destination mailbox has moved;No forwarding address	De mailbox bestaat niet (meer) en er is geen forwarding address
5.1.7	Bad sender's mailbox address syntax	Het return adres klopt syntactisch niet
5.1.8	Bad sender's system address	Het domein van de verzender klopt niet
5.2.0	Other or undefined mailbox status	Een generieke fout betreffende de mailbox
5.2.1	Mailbox disabled;not accepting messages	De mailbox is disabled
5.2.3	Message length exceeds administrative limit	De mailbox specifieke maximum berichtgrootte is overschreden
5.2.4	Mailing list expansion problem	Een adreslijst kan niet uitgepakt worden
5.3.0	Other or undefined mail system status	Een generieke fout betreffende het mailsysteem
5.3.2	System not accepting network messages	Het mailsysteem accepteert geen berichten
5.3.3	System not capable of selected features	Geselecteerde verbs worden niet ondersteund
5.3.4	Message too big for system	De maximale berichtgrootte (of quota) van het systeem is overschreden.
5.3.5	System incorrectly configured	Het systeem houdt zich niet aan de smtp syntax of het systeem is verkeerd geconfigureerd
5.4.0	Other or undefined network or routing status	Een generieke netwerk fout
5.4.1	No answer from host	Het mailsysteem reageert niet
5.4.3	Directory server failure	Kan geen verbinding maken met een directory server (DNS of AD)
5.4.4	Unable to route	Kan geen route vinden
5.4.5	Mail system congestion	Het mailsysteem accepteert geen berichten meer door drukte (opstopping)
5.4.6	Routing loop detected	Een mailloop is gedetecteerd op basis van systeemconfiguratie
5.5.0	Other or undefined protocol status	Generieke protocol fout
5.5.1	Invalid command	Het protocol commando bestaat niet of wordt niet ondersteunt
5.5.2	Syntax error	De syntax van het commando klopt niet
5.5.3	Too many recipients	Het maximaal aantal ontvangers per email is overschreden
5.5.4	Invalid command arguments	Gebruik van verkeerde parameters of waardes
5.5.5	Wrong protocol version	De gebruikte protocollen tussen client en server komen niet overeen
5.6.0	Other or undefined media error	Een generieke fout met de inhoud van het bericht (body of attachment); veelal een MIME fout
5.6.1	Media not supported	De inhoud van het bericht wordt niet ondersteunt
5.6.2	Conversion required and prohibited	Het bericht moet geconverteerd worden en dat staat het systeem niet toe
5.6.3	Conversion required but not supported	Het bericht moet geconverteerd worden en daartoe is het systeem niet in staat
5.6.4	Conversion with loss performed	Het bericht is geconverteerd met dataloss
5.6.5	Conversion Failed	Het converteren is mislukt
5.7.0	Other or undefined security stats	Een generieke fout betreffende beveiliging
5.7.1	Delivery not authorized; message refused	Filtering staat niet toe dat de verzender een bericht af kan leveren bij de ontvanger
5.7.2	Mailing list expansion prohibited	Het uitpakken van adreslijsten is niet toegestaan
5.7.3	Security conversion required but not possible	De verandering van het ene security protocol naar het andere is vereist maar mislukt
5.7.4	Security features not supported	Bepaalde security features worden niet ondersteund.
5.7.5	Cryptographic failure	Er is een probleem opgetreden met cryptografische bewerken zoals bijv het decrypten van data via TLS
5.7.6	Cryptographic algorithm not supported	Een bepaalde encrypty algoritm wordt niet ondersteund.
5.7.7	Message integrity failure	De integriteit van het bericht is aangetast en daardoor wordt het niet geaccepteerd.

Exchange invoer/uitvoer leesvoer

mpriem — Sun, 29 Apr 2007 12:30:00 GMT

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

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.

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.

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

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

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

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

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

**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

Exchange shared hosting

mpriem — Fri, 27 Apr 2007 12:27:00 GMT

Een tijdje geleden zag ik een heel leuk artikel over Shared hosting van meerdere bedrijven in 1 Exchange organisatie. Ik wilde jullie dat niet onthouden..

Hierbij de links van deel 1 en 2

Veel plezier!

CDO & MAPI libs voor Exchange 2007

mpriem — Wed, 25 Apr 2007 12:25:00 GMT

Het is je misschien nog niet opgevallen, maar met een standaard Exchange 2007 installatie worden de CDO en MAPI bibliotheken niet mee geinstalleerd. Hierdoor zullen scripts en applicaties die hiervan afhankelijk zijn niet meer werken.
Microsoft heeft ze echter beschikbaar gestelt in een aparte download.

Deze is HIER te vinden.

#	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

#	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

#	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