setup virtualisatiecluser

[Ruben Portier]

Hallo allemaal,

Ik ben bezig met het uittekenen en uitdenken van de setup van een virtualisatiecluster. De servers en SAN ben ik op zich wel uit, maar nu blijf ik vooral even hangen op de switches.

Het cluster zal bestaan uit 6 - 10 nodes en een SAN, verbonden door zelf geschreven programmatuur op basis van open-iscsi etc. Allereerst heb ik dus een 48p switch nodig om het storage netwerk rond te krijgen. In principe wil ik dit compleet op gigabit basis doen, 8 gbit uplinks naar de san en iedere node 4 gigabit uplinks naar de switch. Aggregation / trunking is dus een vereiste. Eventueel zouden er ook 10gbit poorten op de switch kunnen zitten voor de SAN om deze nog wat meer bandwidth te geven, maar een volledige 10 gbit switch wordt waarschijnlijk te prijzig, dus een switch met 2 of 4 10gbit poorten zou ook kunnen.

Dan heb ik ook nog een gewone gbit access switch nodig, per cluster zijn er 2x gbit fiber uplinks. Stacking zou mooi meegenomen zijn maar niet vereist. Uiteraard managed.

Ik vroeg me af welke switches jullie zouden gebruiken voor een dergelijke setup, natuurlijk heb ik zelf al zitten kijken maar ik zou het graag eens van jullie horen. Ik wil zeker niet de goedkoopste rommel, maar het budget is ook weer niet al te ruim.

Alvast bedankt!
Ruben

[Pantsy]

Normaliter pas je de switching gear aan met je Vendor (hp met hp procurve/cisco, dell met powerconnect/cisco etc...), althans dat is vaak de beste oplossing omdat het op elkaar is afgestemd. Nu bouw jij zelf je SAN en is het al andere koek, wellicht dat hp procurve je kan helpen met wat wilt bereiken, deze switches zijn niet duur te noemen.

Misschien is het interessant om alles op 10gbit uit te rollen? 10gbit is naar mijn mening redelijk betaalbaar geworden.

Uit interesse, hoeveel vm's ga je draaien? Welke virtualisatie techniek? Waarom zoveel front-end nodes? Fail-over kan ik begrijpen maar je bent bezig met een HA setup, dan zou je ook met 3 uit de voeten kunnen, zeker in het begin.

[Ruben Portier]

Ik zat zelf inderdaad ook naar Dell en voornamelijk HP te turen, vendor is inderdaad niet echt van toepassing met de eigen programmatuur, waarschijnlijk worden het ook R415's i.c.m. een supermicro SAN dus dan gaat hardwarematig dezelfde fabrikant kopen ook al niet. 10gbit blijf ik altijd wat eng vinden klinken, maar dat is gewoon omdat ik er nooit mee gewerkt heb en vandaar ook niet echt weet wat er "extra" bij komt kijken dan bij een normale gbit setup. Ga ik me eens in verdiepen!


In principe zal de setup in eerste instantie gebruikt worden voor het draaien van 20 - 25 eigen niet al te grote virtuals, en het finetunen van de software die geschreven is. Als alles écht werkt zoals het hoort is het waarschijnlijk wel de bedoeling het ook verder commercieel te exploiteren in de vorm van het aanbieden van virtuele servers / IaaS. In het begin kan het inderdaad ook wel af met 3 - 4 nodes, maar om na een half jaar weer een nieuwe switch te kopen gaat hem ook niet worden, dus vandaar alvast rekenen met wat meer nodes in de toekomst. Virtualisatietechniek is KVM.

[Pantsy]

Hoe minder nodes, hoe beter... althans ik zal nu op genoeg teentjes trappen van anderen Stuk efficiënter en goedkoper, je fail over/HA behoud je even goed als de architectuur er achter goed is opgezet. Mijn advies is om nog eens een blik te werpen op je setup, immers is je setup pas echt HA als je ook de sans dubbel uitvoerd met replication. Leuk 6 nodes, doelloos met 1 san, begin dan met 2 nodes/1 san. Virtualisatie is ook gemaakt voor flexibiliteit, je kan on demand bij schalen of hardware weghalen.

Ik snap dat je een begin plaatje schets, maar als ik hoor dat je een 6-10 nodes wilt gaan gebruiken en een san voor circa 20-25 vm's in het begin, sja beetje zonde van het geld. De san investering begrijp ik, meerdere nodes nog niet, tenzij ook de san redundant (fysiek dubbel) word uitgevoerd.

Het voordeel van switches zoals procurve/powerconnect/cisco is dat je deze kan stacken, dan heb je (meestal) 10+ gbit throughput onderling tussen de switches, iets wat je zeker nodig hebt als je veel iscsi verkeer denkt te gaan doen. 10 Gbit is niet eng, is een techniek die zich al jaren heeft bewezen en nu ook betaalbaar is. Overweeg zeker deze optie! Scheelt je ook veel cables, complexe network setups. Je hebt liever 1 of 2x 10gbit per node dan 4x 1gbit... anders word het zo'n oerwoud achter in je rack. Let wel op, je iscsi/san network valt en staat met een goede en juiste indeling. Met iscsi wil je immers de beste performance halen.

Ik zou beginnen met een basic setup, 2 nodes, 1 san + de nodige switching gear (hangt er dus vanaf hoe je networking eruit komt te zien). Als je een zak met geld hebt, dan is het simpel: 4 nodes, 2 sans + de nodige switching gear.

Misschien iets om bij stil te staan, sinds je san geen vendor heeft naar mijn mening (á la 24/7 ondersteuning/replacement service), is het toch interessant om naar een andere vendor te kijken voor een totaal oplossing. Je kan ook spare parts op voorraad nemen, maar uiteindelijk ligt het allemaal aan je budget.

[Ruben Portier]

Beginnen met wat minder nodes zullen we ook zeker gaan doen, het genoemde aantal was ook meer om op termijn uitbreiding van het cluster zonder teveel gedoe te realiseren. Twee SAN's met replication is wederom op termijn ook wel de bedoeling, in ieder geval voordat we virtuele servers ook aan anderen gaan aanbieden, maar in het begin wilde ik het toch gaan doen met een enkele SAN. Dit dus voornamelijk vanwege het budget, het kapitaal is geen probleem maar het weer terugverdienen wordt lastiger met een gering aantal virtuals. Het is ook zeker wel een optie om direct te beginnen met het aanbieden van virtuele servers, maar ook dan zal het toch een behoorlijke tijd duren voor de hardware behoorlijk gevuld is met klanten en het dus rendabel wordt, zeker gezien het feit dat ik wel wil dat er 2 SAN's draaien als er daadwerkelijk virtuele servers verkocht worden.


Ik heb zelf nog geen 24p/48p 10gbit switch onder de 5k gevonden, maar dan moet ik ook eerlijk bekennen dat ik me daar nog niet erg in verdiept heb of offertes heb aangevraagd. Misschien kun je me een eindje op weg helpen? Nu ik het zo bekijk is gbit inderdaad niet echt een optie voor het storage netwerk, of in ieder geval niet voor de connectie met de SAN. Is stacking niet wat overbodig met een 10gbit storage switch? Meer dan 10 - 12 nodes zul je er toch niet aanhangen lijkt me.

[eMiz0r]

Als je toch met 1 SAN wilt beginnen, is die Storage Bridge Bay server van Supermicro niks dan?

http://www.supermicro.nl/products/nfo/sbb.cfm

Niet 100% HA, maar wel meer dan gewoon 1 SAN.

[hrodenburg]

Leuk produkt van Supermicro, had het al eens eerder gezien. Maar wat ik mij toen ook al afvroeg: Welk storage OS/software ondersteund de mogelijkheden van een dergelijk systeem? Dus active/passive controllers op dezelfde disk array?

[oehTie]

heb je er over nagedacht dat je 10gbit ook kan crosslinken? Ons cluster hier draait (qua storage dan) volledig op 10 gbit. Gewoon vanaf de san 1 kabel naar iedere host. Iedere host heeft dus een kabel naar san1 en san2 en de san's onderling ook weer verbonden. Relatief goedkoop en een 10gbit switch kan er altijd nog wel tussen.

wellicht een idee?

Wij draaien nu op open-e in combinatie met VMware (vspp) Perfect voor failovers en HA

[koendejonge]

Leuk produkt van Supermicro, had het al eens eerder gezien. Maar wat ik mij toen ook al afvroeg: Welk storage OS/software ondersteund de mogelijkheden van een dergelijk systeem? Dus active/passive controllers op dezelfde disk array?

Die storage bridge bay SBB van supermicro lijkt een leuk product en je zou dat bijvoorbeeld kunnen gebruiken in combinatie met NexentaStor met een HA configuratie. Maar er zitten een aantal 'mindere kanten' aan.

Zo zitten er 'maar' 16 hot-swap drivebays in. Als je dan ieder van de 2 servers die in dit chassis zitten een mirror wilt geven om het OS op te zetten hou je nog maar (16-(2*2)=) 12 slots over om je data op te zetten. Dat is niet zo heel veel om ook nog performance uit te kunnen halen.

Stel je wilt daar 6 virtualisatienodes boven hangen die ieder 24 vm's draaien, dan heb je het over 144 vm's. Als je ieder van die vm's evenveel IOPS wilt kunnen garanderen als ware het fysieke servers met een gemirrorde SATA drive, dan heb je dus 85*144= 12240 IOPS (ongeveer 12K IOPS) nodig.

Als je die 12K IOPS wilt halen uit 12 slots, dan onkom je er niet aan daar (in het geval Nexenta) een SLOG device voor de ZIL voor te zetten (in mirror uiteraard). Waarmee je nog maar 10 slots overhoudt voor je daadwerkelijke dataopslag. En dat zijn toch nog best weinig spindles. Om daar nog soort van echte performance uit te halen heb je dan 5 mirrored vdevs nodig wat je totaal (in het geval van bijvoorbeeld 7200rpm 1TB sas drives) 5*180= 900 write IOPS geeft vanaf de disks. Ik zou me zelfs afvragen of dat met 6 van die nodes uberhaupt gaan performen. Daar komt nog bij dat je maar 1 SAS-path vanaf je beide nodes hebt naar de disken.

Een ander nadeel van zo'n Storage Bridge Bay is dat het allemaal een kast is (dat is natuurlijk ook het voordeel). Als er echt iets aan stuk gaat moet je toch alles uit zetten. En kwa uitbreidbaarheid zijn je opties ook heel erg beperkt, in theorie kun je er een JBOD expantie achter hangen, maar ik ken niemand die dat daadwerkelijk gedaan heeft (iemand?) en ik heb zelfs horen zeggen dat de interlink kabel voor naar zo'n JBOD het helemaal niet doet.

Ik denk dat je voor een klein beetje meer geld een veel interessantere setup neer kunt zetten. Bijvoorbeeld 2 losse servers die met dubbele SAS-kabels aan een disk array van 24 disken geconnect zijn met dubbele interposers (echt multipath). Met 20 slots haal je al gauw 10*180=1800 write IOPS. Ik heb dat al een paar keer doorgerekend, het verschil is nog geen 5% van de prijs en de voordelen zijn heel erg groot volgens mij.

[eMiz0r]

Leuk produkt van Supermicro, had het al eens eerder gezien. Maar wat ik mij toen ook al afvroeg: Welk storage OS/software ondersteund de mogelijkheden van een dergelijk systeem? Dus active/passive controllers op dezelfde disk array?

Koen is me al voor zie ik, maar inderdaad NexentaStor ondersteunt een Active/Active config met HA Cluster. Voor doorsnee onderhoud hoeft de server niet uit -> er zitten 2 volledig zelfstandige moederborden in die hotswappable zijn. Je kunt er een mobochassis uit halen en de boel draait gewoon netjes door. Dat is het hele idee van het product.

[hrodenburg]

Als je goed gaat rekenen houd je inderdaad weinig ruimte voor disken. Dat viel mij ook al op. Daarom zul je er inderdaad in praktijk al snel een JBOD bay aan hangen. Wel vreemd/jammer dat daar dus problemen mee blijken te zijn.

[koendejonge]

Een nadeel wat ik vergeten was te noemen is dat er niet zo heel veel geheugen past in de servers die erin zitten. En laat veel geheugen nou net een groot performancevoordeel opleveren met Nexenta.

Er kan maximaal 48GB ram per bord in, en dan heb je wel 16GB ECC Reg dimm's nodig, goedkoop is anders.

Neem je bijvoorbeeld twee losse 2U servers dan kun je daar al gauw 12 dimms per server in kwijt. Als je die dan vult met 8GB dimms dan heb je 2 keer zoveel geheugen en dan heb je dus voor enkele honderden euri meer een systeem wat beter schaalt en beter performt.

Mijn conclusie is dat het idee van de SBB goed is, maar de uitvoering een beetje jammer.

Waarom geen 2U kast en 24 keer 2,5" drives? Waarom geen extra 1U hoogte en 24 keer 3,5" drives? Of nog beter een extra 1U hoogte en 48 keer 2,5" drives, dan kun je nog eens een leuke configuratie maken (40 keer 400GB ssd iemand?).

[Yourwebhoster]

Waarom geen 2U kast en 24 keer 2,5" drives? Waarom geen extra 1U hoogte en 24 keer 3,5" drives? Of nog beter een extra 1U hoogte en 48 keer 2,5" drives, dan kun je nog eens een leuke configuratie maken (40 keer 400GB ssd iemand?).

Jij ziet alweer een speeltuin voor je liggen haha. Het is maar net wat je wilt investeren en wat het doel is, overkill is leuk voor het idee maar als je gewoon storage nodig hebt die gewoon normaal meerdere VPSsen kan draaien met normale performance (minimaal van een traditionele schijf bijvb) dan vind ik het zonde.

Hoe zou jij het netwerk gaan uitvoeren als je 40 keer 400GB SSD's hebt Ook weer afhankelijk van het doel (access time of doorvoer snelheid).