Onderwerp: 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 overwogen, daarnaast ben ik door dit verhaal over ZFS (Leuke SAN) 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:


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.

Oorspronkelijk geplaatst door The-BosS

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.

Oorspronkelijk geplaatst door Yourwebhoster

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).

Oorspronkelijk geplaatst door The-BosS

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.

Oorspronkelijk geplaatst door Yourwebhoster

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?

Oorspronkelijk geplaatst door Piwi-Web

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, he
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.

Oorspronkelijk geplaatst door The-BosS

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.

Oorspronkelijk geplaatst door Armand

@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.

Oorspronkelijk geplaatst door Armand

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.

Oorspronkelijk geplaatst door Yourwebhoster

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.

Oorspronkelijk geplaatst door Armand

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.