Bekijk Volledige Versie : Jullie mening over mijn potentiele XEN HA Storage Setup.
Hallo allemaal,
Ik ben momenteel aan het testen om een zo'n goed mogelijke storage omgeving op te zetten om te gebruiken als SAN storage voor XEN.
Ik heb de DRBD optie van Wido (http://www.webhostingtalk.nl/nas-san/150541-san-voor-xenserver.html) overwogen, daarnaast ben ik door dit verhaal over ZFS (http://www.webhostingtalk.nl/nas-san/156318-leuke-san-2.html) hier ook helemaal enthousiast over geworden.
Nu ben ik aan het testen met Solaris en ZFS, en moet ik zeggen dat het management van ZFS pools echt heel leuk werkt!
Nu wil ik HA storage opzetten om een 12 tal fysieke servers om te zetten naar virtuele XEN servers.
Uiteraard ben ik als de dood dat wanneer de storage uitvalt al mijn servers ineens down zijn, dus zoek ik naar een HA oplossing.
Helaas heb ik geen budget van 10 duizenden euros.
Sterker nog: mijn budget haalt de 4000 euro vermoedelijk niet eens.
Het mooie van de linux DRBD opstelling is het feit dat je op storage niveau een mirror hebt van je data. Een nadeel vind ik alleen dat alle disks daarin eigenlijk niks doen. (Ze bieden geen IOPS aan je storage netwerk.)
Dit allemaal in oogschauw nemend wil ik de volgende setup met jullie overleggen:
http://www.quality-control-centre.net/xen_ha_storage.jpg
Nu heb ik een aantal prangende vragen!
Ik heb er een ander topic over gevonden,
maar daar vond ik niet een heel sterke reactie kunnen vinden met mensen die ervaring hebben.
1.
Op mijn Dom0 wil ik per VM LUN een RAID 1 mirror draaien tussen NAS1 & NAS2.
Nu begrijp ik dat dit bij writes een grotere capaciteit van je ip netwerk vereist, maar ht
voordeel in mijn optiek is een hoger aantal IOPS voor read's daar beide disk arrays aangesproken worden.
Wat is echter de consequentie van veel (10?) raid 1 mirrors over iSCSI voor de Dom0?
2. Heeft iemand ervaring met linux software raid over geexporteerde iSCSI ZFS blocks?
Ik vraag me af of ZFS niet zorgt dat de disks voor de software raid altijd out-of-sync lijken?
3. Weet iemand of de SSD cache ook effect heeft voor iSCSI exports?
Ik begrijp dat de ZIL (logging) er wel sneller van wordt, maar ik dacht te begrijpen
dat ZFS ook veel aangeroepde bestanden cachde om zo sneller te kunnen aanbieden.
Heeft deze cache ook effect op puur blockdevices?
4. Als al deze obstakels overwinbaar blijken, kom ik op de volgende afweging.
Is 500GB te hoog voor een mirrord SATA disk? Ik lees veel dat IOPS eerder het probleem zijn
dan diskspace, echter heb ik voor 500GB beschikbare data in deze setup 4 disks die de toevoer regelen.
( 2x SAN1 + 2x SAN2 ) Is het interssanter om in dit geval nog grotere disks te nemen?
5. Aansluitend op het vraagstuk hiervoor, kan ik nog snapshots maken als ik iSCSI lun's exporteer? Of heeft ZFS dan het ZFS filesystem nodig? (Dit heb ik nog niet kunnen testen.)
Al jullie feedback wordt uiteraard zeer gewaardeerd!
Ook m.b.t. systeemeisen voor een Solaris systeem;
ik denk zelf aan dual AMD met 4/8 GB geheugen.
Als het me lukt het live te krijgen ga ik uiteraard een mooie howto schrijven voor iedereen.
Ik wil op NAS1 en NAS2 ook een kleine NFS of cluster iscsi maken voor het management van de pool.
Dit om bij te houden welke Dom0 een DomU mag hosten.
Met vriendelijke groet,
Armand
Kwa netwerk zit je met een bottleneck, ofwel interpreteer ik je tekening verkeerd. Maar je sluit je nodes maar op 1x gbit per switch aan. Terwijl hier wel je VM netwerk + je iSCSI over gaat. Het zou dus verstandiger zijn om een quad nic in je nodes te steken en je iSCSI's hier met 2x (2x1Gbit Trunk) op aan te sluiten. Of in je NAS'en bvb 1 quad kaart en 1 dual nic te steken. Je 2 nassen verbind je via crosskabel op 4x 1Gbit trunk en je dual kaart gebruik je om je nodes via 2x 1 Gbit trunk aan te sluiten. Zo moet het verkeer ook niet allemaal over je switch wat weer een Point Of Failure minder is.
Yourwebhoster
07/01/10, 12:19
Kwa netwerk zit je met een bottleneck, ofwel interpreteer ik je tekening verkeerd. Maar je sluit je nodes maar op 1x gbit per switch aan. Terwijl hier wel je VM netwerk + je iSCSI over gaat. Het zou dus verstandiger zijn om een quad nic in je nodes te steken en je iSCSI's hier met 2x (2x1Gbit Trunk) op aan te sluiten. Of in je NAS'en bvb 1 quad kaart en 1 dual nic te steken. Je 2 nassen verbind je via crosskabel op 4x 1Gbit trunk en je dual kaart gebruik je om je nodes via 2x 1 Gbit trunk aan te sluiten. Zo moet het verkeer ook niet allemaal over je switch wat weer een Point Of Failure minder is.
Wat de snelheid heb je gelijk, maar zoals je in dit overzicht ziet wilt hij twee switches gebruiken. Als één switch uitvalt kan er overgeschakeld worden naar de andere switch, dit zit dus in principe wel goed.
Wat de snelheid heb je gelijk, maar zoals je in dit overzicht ziet wilt hij twee switches gebruiken. Als één switch uitvalt kan er overgeschakeld worden naar de andere switch, dit zit dus in principe wel goed.
En als je de NAS'en rechtstreeks aansluit heb je geen switch nodig, dus een Point Of Failure minder en snelheidswinst omdat je volledig gebruik maakt van je trunk. In het geval met de switches heb je 2 keer 2x 2Gbit trunk die je over 2 keer 2x Gbit zend (waar ook je VM traffic over moet).
Yourwebhoster
07/01/10, 12:48
En als je de NAS'en rechtstreeks aansluit heb je geen switch nodig, dus een Point Of Failure minder en snelheidswinst omdat je volledig gebruik maakt van je trunk. In het geval met de switches heb je 2 keer 2x 2Gbit trunk die je over 2 keer 2x Gbit zend (waar ook je VM traffic over moet).
Wat dat betreft heb je gelijk. Ik heb zelf ook zoiets ontworpen, alleen met het oog op uitbreidingen en meer clients, in dit geval is dit dus niet perse nodig.
Wat dat betreft heb je gelijk. Ik heb zelf ook zoiets ontworpen, alleen met het oog op uitbreidingen en meer clients, in dit geval is dit dus niet perse nodig.
Waarom meer SAN's? Aan 2 heb je er wel genoeg voor de eerste paar nodes. Ga je aan een tweede beginnen dan maak je daar toch een nieuwe cluster voor?
Yourwebhoster
07/01/10, 12:55
Waarom meer SAN's? Aan 2 heb je er wel genoeg voor de eerste paar nodes. Ga je aan een tweede beginnen dan maak je daar toch een nieuwe cluster voor?
Beetje topic kapen, heot:
Maar goed, ik heb rekening gehouden met uitbreiding en dan heb ik het niet persé over de SANs, maar de clients. Heb zo mijn redenen om het op die manier te doen, maar ik moet het e.e.a. nog uitwerken, het heeft verlopig niet zo'n haast.
@The-BosS: met deze setup heb ik (denk ik) niks aan cross tussen de twee NAS devices.
aangezien het mirroren moet gebeuren op basis van software Raid op Dom0, en ik denk dat je dan gewoon 2x zoveel schrijfpakketjes over je netwerk krijgt?
In theorie heeft iedere host 2x 1Gbit verbinding (over 2 switches) dat lijkt mij voldoende?
( Ik wil tenslotte niet dat 1 host er voor kan zorgen dat de complete toevoer tot de SAN digslipt. Nu heb ik altijd 2Gbit over voor andere hosts als er bijvoorbeeld met 2gbit/sec wordt weggeschreven. (zou ik al netjes vindena ls ik dat haal) )
@Yourwebhoster: ik verwacht eigenlijk niet de SAN uit te breiden, maar eerder de Hosts. Als ik meer IOPS nodig heb kan ik eerst nog switche naar 15k rpm SAS. Maar ook dit is afhankelijk van de impact van de SSD voor caching, waar ik eigenlijk eerst meer gegevens van moet hebben.
Iemand nog verder feedback op mijn "prangende" vragen?
Om even verwarring uit de weg te gaan, ik heb het over een cross-link tussen de 2 nas'en ipv over de switch. Dit kun je toch perfect doen met elk een extra quad kaart die je 4x Gbit trunkt naar elkaar. Dit lijkt me handig om data zo te dupliceren dan dit constant over de switch te pushen. En de nas'en zet je in heartbeat ipv mirror op de clients zelf. Want bij het rebuilden op de clients verlies je anders een hele hoop tijd.
En de nas'en zet je in heartbeat ipv mirror op de clients zelf. Want bij het rebuilden op de clients verlies je anders een hele hoop tijd.
Dit ben ik met je eens, maar hoe doe ik blocklevel replication op Solaris?
(Als ik ZFS wil gebruiken moet ik sent/receive gebruiken, iets wat niet echt realtime is.)
Daarnaast denk ik dat het positief is als je via software raid zorgt dat een host de load van zowel NAS1 als NAS2 "kan" halen. Bij een DRBD primary/secondary setup kan je geen IOPS ontleden aan de secondary.
Ik moet wel bekennen dat ik mij niet heb verdiept in een primary/primary setup.
Yourwebhoster
07/01/10, 13:06
@Yourwebhoster: ik verwacht eigenlijk niet de SAN uit te breiden, maar eerder de Hosts. Als ik meer IOPS nodig heb kan ik eerst nog switche naar 15k rpm SAS. Maar ook dit is afhankelijk van de impact van de SSD voor caching, waar ik eigenlijk eerst meer gegevens van moet hebben.
Iemand nog verder feedback op mijn "prangende" vragen?
Ik bedoel met uitbreiden de hosts en niet de SAN's;) Als dit je bedoeling is, dan kun je beter de opstelling houden zoals je nu hebt. Wat je wel kunt doen is zoals The-BosS zegt een paar poorten trunken, zodat je bijvb de hosts een 2Gbit verbinding hebben naar de switch en dit kan je ook doen bij de NASen.
Yourwebhoster
07/01/10, 13:07
Dit ben ik met je eens, maar hoe doe ik blocklevel replication op Solaris?
(Als ik ZFS wil gebruiken moet ik sent/receive gebruiken, iets wat niet echt realtime is.)
Daarnaast denk ik dat het positief is als je via software raid zorgt dat een host de load van zowel NAS1 als NAS2 "kan" halen. Bij een DRBD primary/secondary setup kan je geen IOPS ontleden aan de secondary.
Ik moet wel bekennen dat ik mij niet heb verdiept in een primary/primary setup.
Live replicatie bestaat niet bij ZFS, in dat andere topic wat je zelf aanhaalt was dit mij duidelijk geworden:)
Ik zou zeggen maak eens een kleine test opstelling (mag zelf alles virtueel) en doe dan eens een shutdown van 1 van je nas'en en bekijk het resultaat op je client-vm. En doe de test dan ook eens terwijl je want 100mb.bin of 1000mb.bin weg en weer copieert. Zet dan vervolgens de ene nas terug aan en kijk wat het resultaat is van je software-raid. Doet die wat je verwacht binnen de tijd dat je verwacht goed, doet die totaal niks en crashed de client-vm dan heb je direct antwoord op je storage probleem.
Live replicatie bestaat niet bij ZFS, in dat andere topic wat je zelf aanhaalt was dit mij duidelijk geworden:)
Ik heb het een en ander gelezen over AVS. ("Availability Suite")
Waarmee iets dergelijks wel weer moet kunnen.
al is het niet helemaal DRBD.
Yourwebhoster
07/01/10, 13:16
Ik heb het een en ander gelezen over AVS. ("Availability Suite")
Waarmee iets dergelijks wel weer moet kunnen.
al is het niet helemaal DRBD.
Ik heb het verder nog niet uitgetest en geen machines beschikbaar hiervoor, misschien later ooit eens maar tot nu toe is mijn conclusie dat hw RAID met drbd voldoet aan de eisen die ik stelde.
Je wilt je hosts de RAID1 laten verzorgen.
Dat betekend dat indien 1 van de storage servers uitvalt, en vervolgens weer in gebruik genomen worden, er terrabytes aan data van de ene storage servers, via de host (die doet het rebuilden), naar de andere storage server gestuurd moet worden.
Efficient is anders.
Bij replicatie software heb je dat probleem meestal niet, omdat er een lijstje bijgehouden wordt met blokjes die de afgelopen tijd gewijzigd zijn.
Als een storage server een dipje heeft, en even later weer in gebruik wordt genomen, hoeven alleen de gewijzigde gegevens over het netwerk.
Blijkbaar toch nog iemand die mijn mening deelt, daarom dat ik ook het advies gegeven heb aan de TS om even een test opstelling te maken en het uit te testen. Misschien is het geschikt voor zijn doeleinden misschien ook niet. Ik snap zijn bedoeling wel een beetje, maar raid is niet onfeilbaar en een rebuild kan soms heel lang duren.
Ik snap jullie scenario.
De reden dat ik het vroeg is ook omdat ik geen pratische kennis heb in een dergelijke setup.
Ik ga hem zeer binnenkort in de praktijk opzetten!
Het zal gaan om 40GB LUN's, maar ookal zijn het er 10, dan nog duurt het lang omdat iedere host tegelijk die data wil repliceren. Het scenario kan ik inderdaad wel voor me zien.
@maxnet: eer DRBD / sync setup tussen de 2 NAS servers betekend eigenlijk dat je meer een hot-standby hebt. Het "leek" mij heel mooi de disk capaciteit m.b.t. iops te kunnen benutten van beide nas devices.
Maar in de praktijk is die wens zeker een utopie te noemen?
Snelheid winst m.b.t. iops haal je niet uit een raid1 opstelling omdat hij tegelijk leest en schrijft op beide disks (mirror), winst haal je enkel uit raid0, 10, 5, 6, 50 en varianten omdat de read, writes hier verdeeld worden over de hd's. Wat je niet tegenhoud om je 2 nas'en in bvb raid 10 of 5 of ... te zetten en daar haal je dan wel weer winst uit.
Snelheid winst m.b.t. iops haal je niet uit een raid1 opstelling omdat hij tegelijk leest en schrijft op beide disks (mirror), winst haal je enkel uit raid0, 10, 5, 6, 50 en varianten omdat de read, writes hier verdeeld worden over de hd's. Wat je niet tegenhoud om je 2 nas'en in bvb raid 10 of 5 of ... te zetten en daar haal je dan wel weer winst uit.
Daar heb je gelijk in, echter vraag ik me af wat er gebeurd als een voeding van een van de nas-en het begeeft of een andere hardware failure, valt er dan niet een te groot gedeelte van de array weg waardoor de andere nas ook niet verder draait?
Daar heb je gelijk in, echter vraag ik me af wat er gebeurd als een voeding van een van de nas-en het begeeft of een andere hardware failure, valt er dan niet een te groot gedeelte van de array weg waardoor de andere nas ook niet verder draait?
Als je de 2 nas'en in failover zet dan gebruiken de nodes maar 1 nas, en dupliceren de 2 nas'en zichzelf. Valt er 1 nas weg dan pakt de failover het op, komt de nas terug dan beginnen ze onderling terug aan het dupliceren van data. Naar gelang je instellingen blijft dan bvb de secudaire nas gewoon master tot deze een failure geeft. Of je stelt in dat deze terug als slave gaat eens het dupliceren gedaan is.
Als je de 2 nas'en in failover zet dan gebruiken de nodes maar 1 nas, en dupliceren de 2 nas'en zichzelf. Valt er 1 nas weg dan pakt de failover het op, komt de nas terug dan beginnen ze onderling terug aan het dupliceren van data. Naar gelang je instellingen blijft dan bvb de secudaire nas gewoon master tot deze een failure geeft. Of je stelt in dat deze terug als slave gaat eens het dupliceren gedaan is.
Dat klopt, echter benut je zoals armand zegt dan niet beide IOPS van de nassen. Volgens mij wil hij dus een opstelling dat dit wel gebeurd.
Dat klopt, echter benut je zoals armand zegt dan niet beide IOPS van de nassen. Volgens mij wil hij dus een opstelling dat dit wel gebeurd.
Dan maak je een soort van cluster systeem en ben je afhankelijk van de werking van de 2 nas'en en heb je geen redundantie meer. Wil je meer iops neem je 15k rpm hd's op sas of ssd's ipv sata, dit is meer de afweging die je moet maken. Verder hangt het af van welke toepassingen je natuurlijk wil gebruiken.
hrodenburg
08/01/10, 13:33
Je wilt 2 active nas dozen, begrijpelijk. Ik denk alleen dat de opstelling met raid 1 over iscsi weer zoveel overhead (full resync bij korte failures/reboots), potentiele problemen en andere ongewenste effecten geven dat het voordeel al snel ver te zoeken is.
Ik heb totaal geen ervaring met dergelijke setups, maar ik zou het persoonlijk niet op deze manier gaan doen. Ik denk dat er te veel punten zijn waarop het mis kan gaan.
Duidelijk!
Dan nog mijn overige vragen (*zijn er Solaris sysadmins hier?)
M.B.T. ZFS snapshotting op basis van de blockdevices?
Het zal gaan om 40GB LUN's, maar ookal zijn het er 10, dan nog duurt het lang omdat iedere host tegelijk die data wil repliceren. Het scenario kan ik inderdaad wel voor me zien.
@maxnet: eer DRBD / sync setup tussen de 2 NAS servers betekend eigenlijk dat je meer een hot-standby hebt. Het "leek" mij heel mooi de disk capaciteit m.b.t. iops te kunnen benutten van beide nas devices.
Zou eerst eens uitzoeken of DRBD en AVS geen opties hebben om meerdere replicatie sessies tegelijk te draaien.
Dan kan je storage server 1 standaard master maken voor de eerste 5 LUNs, en storage server 2 master voor de andere 5 LUNs.
Dan gebruik je ook de IOPs van beide devices.
Zo had ik het nog niet bekeken, super tip maxnet!
Voor iedereen die niet bekend is met de Solaris AVS suite.
Hier zit een programma in genaamd SNDR, vergelijkbaar met het DRBD pakket.
Hier is een mooie tutorial op de opensolaris website:
http://hub.opensolaris.org/bin/view/Project+avs/AVS-ZFS-Demo-V1
( Waarschuwing, ze hebben Elmer Fud gecast om het verhaal aan elkaar te praten! )
Ik ben geen solaris sysadmin, maar het ziet er doodeenvoudig uit.
Heeft iemand hier deze ^ oplossing al eens in de praktijk gebruikt? Ook hebben interesse in meerdere ZFS nodes met replicatie, waarbij we het liefst natuurlijk de IOPS van beide (of meerdere) nodes gebruiken.
Heeft iemand hier deze ^ oplossing al eens in de praktijk gebruikt? Ook hebben interesse in meerdere ZFS nodes met replicatie, waarbij we het liefst natuurlijk de IOPS van beide (of meerdere) nodes gebruiken.
Als ik kijk naar de oplossingen die Sun zelf aanbiedt in de openstorage lijn dan denk ik niet dat dit al gaat werken. De oplossingen van Sun zelf gaan namelijk uit van 2 nodes met daarachter een jbod die op beide nodes is aangesloten. De nodes staan daarbij in active-passive configuratie. Misschien dat iemand met de mogelijkheden die setup eens kan testen?
@Sander: Deze setup is ook het slimste mits goed uitgevoerd.
Je wilt tenslotte niet al je spindels (disks) dubbel hebben draaien als je continu moet synchen tussen twee nodes. Dan liever de disk array als los (device)
Echter hardware technisch krijg je dan een hele nieuwe slag om HA te krijgen.
( Dubbele controllers in en naar de JBOD. )
Wat mij betreft geeft dit ook veel beren op de weg, en is de ZFS SNDR weg makkelijker.
( Vergelijkbaar met DRBD )
Voordat je uiteindelijk besluit hoe je raidsetup op gaat stellen wil ik je wijzen op een post van expert-exchange, iemand die wel goede uitleg met onderbouwing heeft:
Calculating IOPS
Single Disk IOPS = 1 / Average Latency, where
Average Latency = Rotational Latency + Average Seek Latency
Rotational Latency =
14.3 ms @ 4200 RPM
11.1 ms @ 5400 RPM
8.3 ms @ 7200 RPM
6.0 ms @ 10K RPM and
4.0 ms @ 15K RPM
Average Seek Latency = Varies with Manufacturer, typically
Notebook drives ~ 12+ ms
7.2K SATA drives ~ 8 to 10 ms
10K SATA drives ~ 4.5 to 5.0 ms
10/15K SAS drives ~ 3 to 4 ms
RAID Read IOPS = Sum of all Single Disk IOPS
RAID Write IOPS
RAID0 = Sum of all Single Disk IOPS
RAID1/10 = Half of the sum of all Single Disk IOPS
RAID5* = One-quarter the sum of all Single Disk IOPS
RAID6* = One-sixth the sum of all Single Disk IOPS
* Note while there is an XOR calculation involved with RAID5/6, it's usually inconsequential in modern hardware.
Real IOPS will be somewhere between your read and write IOPS, depending upon your read-write ratio. Transactional databases are generally considered to be 50:50, whereas operational databases are considered to eb about 90:10.
This represents PEAK IOPS that can be sustained with no regard to cache. It also requires that you have as many outstanding IO operations as there are spindles to reach this. For example, with eight spindles, you would need eight outstanding operations (i.e., queued) to reach full potential.
Cache is harder to determine. For an estimate, you need to know your data sample size versus your cache size. For example, you have a 200GB database, of which about 10% is routinely accessed in a day. That's about a 20GB data sample size, so a 2GB cache would have approximately a 10% cache-hit ratio.
The IOPS of Cache is HUGE, so the easiest way would be to take the remaning percentage, e.g., the cache-miss ratio, and divide your IOPS by that. For example, if you array sustains 1000 IOPS and you estimate a 90% cache-miss ratio, you could bump up your IOPS estimate to 1,111 IOPS. Obviously the more cache the better - but it can become very expensive to have huge amounts of cache. However, as you'll see below, even 4GB of cache can mean very little on large transactional databases.
Sun released a white paper a while back on the design of SANs and recommended 256MB for each 15K spindle, 512MB for each 10K spindle and 1GB for each 7.2K spindle. So an array of 32 SATA drives should have no less than 32GB of cache available to it.
Let's take a practical example, in reverse. You need 3000 IOPS. We'll assume RAID1 to begin with. This is a heavily transactional database type, so we'll assume a 50:50 read-write ratio.
A single 2.5" 15K SAS drive should be able to achieve about 250 IOPS. To achieve this without cache, you would then need sixteen spindles. That is, 16*250 = 4000 read IOPS and 2000 write IOPS; at 50:50 that's 3000 IOPS. So a single MD1120 enclosure would fit the bill nicely. This will, however, only give you about 584GB of space, which may or may not be enough (unless Dell has 15K 146GB drives now).
With RAID6 (I cannot recomment RAID5 for reliability reasons), you'd need a few more drives to hit 3000 IOPS - about 21. That is, 21*250 = 5250 read IOPS and 875 write IOPS; at 50:50 that's about 3060 IOPS.
Cache makes this more complex, however. Each drive has 8MB of cache, the controller usually has 256MB or more of cache, and if it's on a SAN, you'll have your controller cache, usually in the gigabyte range. Using Sun's figures, for sixteen spindles we should have 4GB of cache (at 256MB each spindle). Your dataset size is a little tougher to estimate without empiracal data, but assuming each user sends and receives about 30MB of emails a day with 2000 users, you'd have a data sample size of about 60GB. With only 4GB of cache, you're cache miss ratio is about 93.3%. This only improves your IOPS to about 3,200 IOPS.
Alternatively, with SATA drives, you can get a 1000GB spindle running at about 116 IOPS. To have enough performance with RAID10, we'd need about 34 spindles. That is 34*116 = 3944 read IOPS, 1972 write IOPS. With caching, we could probably get that down. Again, using Sun's recommendation, we'd need 34GB of cache in this example. Assuming 32GB, we'd have a cache-miss ratio of about 46.7% (much better), raising our IOPS to nearly 6400 IOPS.
Anyway, the sweet-spot here (I cheated and used MS Excel Goal-Seek function) is at 22x 1TB SATA spindles with 24GB of cache, giving 3,190 IOPS peak (RAID1) and 11TB of space. Probably talking two 3U trays and a heafty 2U controller. This gives you 11TB of space. If you're not going SAN, then add the cache requirement to your Exchange/Windows requirement. For example, if your'e doing this on a single box, get a system with 32GB of RAM - this gives 24GB for cache and 8GB for Windows and Exchange (more than enough - the Microsoft recommendation is 4GB).
Since you also need boot drives, etc. I would suggest 2x73GB 15K SAS drives (on the server) for the system volume, swap file, etc; 2x36GB 15K SAS drives (also on the server) for the Exchange binaries, temp files, etc; and 2x300GB 10/15K SAS drives for your logs (all RAID1).
Then, in two SAS enclosures, simply have 26x1TB using RAID60 for the data partition (stripe across the enclosures and/or controllers). This will give you 3,182 peak IOPS on the data array with about 24TB of available space. Alternatively, you could go with RAID10 by only installing 22 spindles for 11TB of space and 3,080 IOPS. This also gives you room to grow.
If space is not a concern, go with 15K SAS drives. You'd need about 15 SAS drives to reach 3000 IOPS at RAID10, or about 20 SAS drives to reach 3000 IOPS with RAID6. In either case, get as big a drive as you need - if you're only giving your 2000 users 2GB of space, then 4TB would be enough and could be done with 300GB drives using RAID6, or 400GB drives using RAID10. The big benefit here is that the system only needs about 6GB of cache to run optimally, saving in the RAM cost. While the drives might be more expensive, the cost savings on the number (15 versus 26, 1 eclosure vs 2, 6GB cache vs 24GB) may actually make this the less expensive option. Price them out, then decide - do you need more than 4TB of space for an Exchange server.
Hope that helps.
Verder kijk ook even naar een whitepaper van seageate over het mixxen van verschillende schijven tesamen: http://www.seagate.com/content/pdf/whitepaper/TP-543_SAS-15K.pdf
je kunt beter je goed inlezen dan dat je achteraf baalt van je gekozen setup :)
@Sander: Deze setup is ook het slimste mits goed uitgevoerd.
Je wilt tenslotte niet al je spindels (disks) dubbel hebben draaien als je continu moet synchen tussen twee nodes. Dan liever de disk array als los (device)
Echter hardware technisch krijg je dan een hele nieuwe slag om HA te krijgen.
( Dubbele controllers in en naar de JBOD. )
Wat mij betreft geeft dit ook veel beren op de weg, en is de ZFS SNDR weg makkelijker.
( Vergelijkbaar met DRBD )
Een aantal JBOD's van SUN ondersteunt ook meerdere poorten die active-active gebruikt kunnen worden voor dit soort doeleinden. Ook andere vendors hebben die in hun assortiment, dus op zich hoeft dat het probleem niet te zijn. Het is alleen even de vraag of dit voor kleine setups al rendabel is. Ga je groter dan een paar TB, dan kan het in mijn ogen geen kwaad om het een keer serieus uit te zoeken en door te rekeken.
Toch even meedelen voor Armand, maar sinds deze week heeft nexentaStor 2.2.1 gereleased. En hier zit nu de auto-sync functie in die ondermeer voor DR gebruikt kan worden, meer informatie is terug te vinden op http://www.nexenta.com/corp/nexentastor-faq-table/273-whats-new-in-auto-sync-replication. Waarschijnlijk is dit wat je zoekt, zfs met replicatie, de vraag is alleen wil je betalen als je boven de 4TB gebruikt. Of misschien kan je deze functie ook gebruiken in opensolaris zeker de moeite waard om het uit te zoeken.
Zvol replicatioin: auto-sync can now replicate zvols directly. Previously, auto-sync was required to have a folder (filesystem) as its source; today this restriction is removed.
De RAID-1 optie met ZFS zou ik niet doen :) Dit vanwege de bovenstaande punten.
Met DRBD kan je zeker wel meerdere resources draaien waardoor je beide machines kan activeren.
In de praktijk kan je performance hierdoor echter lager zijn doordat je disks met writes en reads aan het mixen bent, dat is mijn ervaring. Ook wordt het technisch met heartbeat lastiger, daarom gebruiken wij het live niet, KISS is ook belangrijk, de beheerder moet het ook begrijpen ;)
Wat SUN doet met hun JBOD is niet mijn idee, ik wil juist de disks gemirrored hebben, niet de toegangsdozen tot die NAS....
Heb nu wel ZFS op een enkele NFS server draaien, wat een verademing!
@Mickey: Bedankt, mooi stukje :-)
@The-Boss: zeker interessant, bedankt!
@Wido: Het grijze gebied tussen een NAS en een SAN is in mijn optiek dat een SAN (het netwerk is) waarmee je je NAS omgeving HA probeert aan te bieden.
ZFS heeft geweldige features om een (goedkope) NAS te zijn.
Nu komt wat mij betreft de slag om het toe te passen in een "goedkope, doch duurzame" SAN omgeving.
In mijn optiek is dat de disks, maar ook de toegang tot die disk, mirroren.
( of iedergeval recovery stand-by hebben. )
Performance impact als 1 van de 2 ZFS servers down gaat moet kunnen.
Dat is normaal in een HA omgeving. Zelfs raid5 rebuilds hebben een grote performance impact!
Dus als ik het goed begrijp uit deze en andere threads (en een aantal artikelen), zijn we beter af om ZFS de RAID te laten regelen per node. Dus geen ZFS op hardware raid? We gebruiken adaptec of areca kaarten.
@Stiller: Ik ben geen expert, dus mijn mening kan ik niet onderbouwen met eigen kennis, maar van wat ik lees: inderdaad ja.
Neemt niet weg dat wanneer je gebruik maakt van (duurdere) Raid Controllers in JBOD mode, je er wel profijt mee kan hebben met de controller cache (met BBU) via ZFS.
Neemt niet weg dat wanneer je gebruik maakt van (duurdere) Raid Controllers in JBOD mode, je er wel profijt mee kan hebben met de controller cache (met BBU) via ZFS.
Maar i.p.v. een controller met meer cache zou je ook meer geheugen op het moederbord zelf kunnen plaatsen, mits de server aan een UPS hangt.
De meeste besturingssystemen gebruiken geheugen dat over is immers als cache.
Kwa performance doet de on-board Intel 3420 controller van mijn testbak, niet onder aan een Adaptec 5405:
Adaptec 5405, HW RAID 5, ZFS:
Version 1.03d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
nex 32G 92357 94 92214 9 82031 15 84985 98 573223 30 10030 30
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ 26956 100 +++++ +++ +++++ +++
nex,32G,92357,94,92214,9,82031,15,84985,98,573223, 30,10029.8,30,16,+++++,+++,+++++,+++,+++++,+++,269 56,100,+++++,+++,+++++,+++
real 26m38.304s
Adaptec 5405, simple volume, software RAID-Z:
Version 1.03d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
nex 32G 92504 94 118628 12 100554 15 84695 98 806229 40 13560 24
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ 26687 100 +++++ +++ +++++ +++
nex,32G,92504,94,118628,12,100554,15,84695,98,8062 29,40,13560.3,24,16,+++++,+++,+++++,+++,+++++,+++, 26687,100,+++++,+++,+++++,+++
real 23m53.971s
On board controller, software RAID-Z:
Version 1.03d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
nex 32G 97098 98 190909 19 123846 18 83566 97 592345 29 13386 45
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ 25081 100 +++++ +++ +++++ +++
nex,32G,97098,98,190909,19,123846,18,83566,97,5923 45,29,13386.4,45,16,+++++,+++,+++++,+++,+++++,+++, 25081,100,+++++,+++,+++++,+++
real 20m58.499s
(systeem: HP DL120 G6, X3450, 16 GB RAM, 4x X25-M SSD)
Alleen bij lezen is de Adaptec sneller, maar daar heb je alleen wat aan als je SAN 10 gigabit netwerk heeft.
Maar i.p.v. een controller met meer cache zou je ook meer geheugen op het moederbord zelf kunnen plaatsen, mits de server aan een UPS hangt.
De meeste besturingssystemen gebruiken geheugen dat over is immers als cache.
Voor reads, niet voor writes, lijkt me. Anders zou een stroomstoring het FS in een wel erg slechte staat brengen. Nu hoor ik dat ZFS hier inderdaad gevoeliger voor is, net als voor hardware van mindere kwaliteit. Heeft iemand hier stabiliteitsproblemen ondervonden met ZFS door slechte hardware?
Voor reads, niet voor writes, lijkt me. Anders zou een stroomstoring het FS in een wel erg slechte staat brengen.
Zolang je server aan een UPS hangt, zie ik het probleem niet helemaal.
Weet niet hoeveel geheugen Opensolaris als write cache gebruikt.
Linux begint standaard pas met het wegschrijven van gegevens na 30 seconden, of nadat de write cache groter is geworden dan 10% van je geheugen.
Vermits ZFS checksums wegschrijft (en verifieert tijdens het lezen) is het minder gevoelig voor slechtere hardware.
Toch even meedelen voor Armand, maar sinds deze week heeft nexentaStor 2.2.1 gereleased. En hier zit nu de auto-sync functie in die ondermeer voor DR gebruikt kan worden, meer informatie is terug te vinden op http://www.nexenta.com/corp/nexentastor-faq-table/273-whats-new-in-auto-sync-replication. Waarschijnlijk is dit wat je zoekt, zfs met replicatie, de vraag is alleen wil je betalen als je boven de 4TB gebruikt. Of misschien kan je deze functie ook gebruiken in opensolaris zeker de moeite waard om het uit te zoeken.
Ondersteunt de developer license ook active-active replicatie? Dit klinkt als een goed voorbeeld om van te leren, voordat ik het met opensolaris probeer.
Om mijn eigen vraag te beantwoorden, het lijkt erop dat de nexenta dev installatie inderdaad alle features biedt. Dat maakt het een prima oplossing voor mij tot de het moment waarop opensolaris AVS beter ondersteunt.
Ik heb nog geen werkend voorbeeld gezien van de opensolaris guru's, dus ik waag me er nog even niet aan. AVS configuratie ziet er niet prettig uit, zeker niet op opensolaris.
@maxnet: UPS of niet, als je door een fysieke storing enkele gigabytes data kwijtraakt, is het niet geschikt voor HA. Dan ben je waarschijnlijk aangewezen op active/active replicatie.
Om mijn eigen vraag te beantwoorden, het lijkt erop dat de nexenta dev installatie inderdaad alle features biedt.
Meen dat de HA optie het alleen doet als je hem met een evaluatie key installeert.
@maxnet: UPS of niet, als je door een fysieke storing enkele gigabytes data kwijtraakt, is het niet geschikt voor HA. Dan ben je waarschijnlijk aangewezen op active/active replicatie.
Maar dat verschilt in dat opzicht niet van een intelligente RAID kaart met cache.
Die dingen kunnen ook stuk, zoals bijgevoegd plaatje laat zien.
Ik heb m'n ZFS backupdoos (500gb bootdisk en 7x1.5TB raidz) nu draaien, maar heb m'n SSD er toch maar uitgehaald. Een goede tip is om, als je SSD writecache wilt, twee SSD's te pakken. Als je SSD stuk gaat is je hele storage pool namelijk onherstelbaar stuk.
Bij twee SSD's vang je dat op en met geen enkele SSD heb je gewoon de betrouwbaarheid van je raidz.
Ik gebruik er ook een Areca voor, maar dan in JBOD mode.
Ik heb m'n ZFS backupdoos (500gb bootdisk en 7x1.5TB raidz) nu draaien, maar heb m'n SSD er toch maar uitgehaald. Een goede tip is om, als je SSD writecache wilt, twee SSD's te pakken. Als je SSD stuk gaat is je hele storage pool namelijk onherstelbaar stuk.
Bij twee SSD's vang je dat op en met geen enkele SSD heb je gewoon de betrouwbaarheid van je raidz.
Ik gebruik er ook een Areca voor, maar dan in JBOD mode.
Is dat bij het gebruik van een SSD als ZIL device? Ik had begrepen dat bij een defect ZFS teruggrijpt op de storage pool, dus dat die juist niet stuk gaat. Ik heb het nog niet getest.
Is dat bij het gebruik van een SSD als ZIL device? Ik had begrepen dat bij een defect ZFS teruggrijpt op de storage pool, dus dat die juist niet stuk gaat. Ik heb het nog niet getest.
Bij de L2ARC leescache spreekt hij de storage pool aan, op het moment dat de SSD stuk gaat, of de data (checksum) niet klopt.
Een apart ZIL device wordt gebruikt als snelle tijdelijke opslag, voor data die meteen weggeschreven dient te worden, en niet in een schrijfcache opgenomen mag worden.
Je hebt daar wat aan als je bijv. PostgreSQL gebruikt, die na elke transactie sync() aanroept om het wegschrijven te forceren.
Als dat stuk gaat heb je dus dataverlies, die data staat immers nog niet op je pool.
Wat je er op een backupdoos mee zou moeten is me niet duidelijk.
Is dat bij het gebruik van een SSD als ZIL device? Ik had begrepen dat bij een defect ZFS teruggrijpt op de storage pool, dus dat die juist niet stuk gaat. Ik heb het nog niet getest.
Yup, da's bij een ZIL device. Ik quote:
You can add an SSD to your storage pool as a separate log device. However, you can't currently remove a log device after it is added. With two SSDs, you can create a mirrored pair of log devices. In a mirrored log configuration, the second device could be detached.
In mijn backupserver leek 't inderdaad niet nuttig. Die is bovendien zonder SSD érg snel.
@Mickey: Bedankt, mooi stukje :-)
@The-Boss: zeker interessant, bedankt!
@Wido: Het grijze gebied tussen een NAS en een SAN is in mijn optiek dat een SAN (het netwerk is) waarmee je je NAS omgeving HA probeert aan te bieden.
ZFS heeft geweldige features om een (goedkope) NAS te zijn.
Nu komt wat mij betreft de slag om het toe te passen in een "goedkope, doch duurzame" SAN omgeving.
In mijn optiek is dat de disks, maar ook de toegang tot die disk, mirroren.
( of iedergeval recovery stand-by hebben. )
Hey Armand... je definitie van SAN en NAS is niet echt correct... SAN werkt op blocklevel en NAS op filelevel...dat is het verschil...
Denk overigens dat je met MD raid in de problemen gaat komen als er een rebuild situatie gaat plaatsvinden... meerdere aangesloten hosts gaan dan ineens op eigen houtje en zonder coordinatie onderling de boel resyncen... volgens mij moet dat fout gaan...
Voor wat betreft je IOPS...ik denk dat dat voor het grootste deel af gaat hangen van de hoeveelheid spindles en het type disken wat je gaat gebruiken... Twee systemen aktief kunnen gebruiken is op zich hardstikke mooi maar maakt het wel heel veel meer ingewikkeld en gevoeliger. Vergeet ook niet te denken aan wat er gebeurt met write back cache als er een systeem uitvalt... alles wat daarin zit komt niet meer op disk terecht en je hosts weten niet beter dan dat dat wel gebeurt is...