Onderwerp: SAN noden in een datacenter

@Wonko:
Ik lees dat de recovery tools pas eind 2009 gepland stonden/staan. (Ik heb verder nog geen ervaring met ZFS) maar zoals ik de specs lees is het erg "redundant" en "slim".
Maar de recovery tools zal niet zonder reden vraag naar zijn? :$

En hoe zou je dit als SAN setup kunnen gebruiken?
Ik lees dat je in principe ZFS via iSCSI kunt gebruiken (niet shared per LUN uiteraard)
Maar gebruik jij dit ook? Vind het wat grijs omdat het zowel blockdevice als filesystem in één lijkt te zijn

Oorspronkelijk geplaatst door Armand

@Wonko:
Ik lees dat de recovery tools pas eind 2009 gepland stonden/staan. (Ik heb verder nog geen ervaring met ZFS) maar zoals ik de specs lees is het erg "redundant" en "slim".
Maar de recovery tools zal niet zonder reden vraag naar zijn? :$

En hoe zou je dit als SAN setup kunnen gebruiken?
Ik lees dat je in principe ZFS via iSCSI kunt gebruiken (niet shared per LUN uiteraard)
Maar gebruik jij dit ook? Vind het wat grijs omdat het zowel blockdevice als filesystem in één lijkt te zijn

Recovery-tools heb ik nog niet nodig gehad. Near-live data backups zijn te bekomen met zfs send en receive, en met snapshots kom je ook al een heel eind. De opbouw van het filesysteem, en zijn intelligentie, zou corruptie moeten voorkomen, als je het gewoon gebruikt zoals het moet (zil bvb niet uitzetten!).

Het is idd een blockdevice en filesysteem in één. Het is het samensmelten van linux MD, LVM en een filesysteem in één product.

Je kan op je ZFS gewoon volumes maken, en deze via iSCSI exporteren als een block-device. En dan heb je een SAN. Shared is mogelijk, maar dan moet je een geclustered FS draaien op je initiators. Wij gebruiken het zo voor enkele opslagdozen.

@Wonko:
Ik ben weer bezig geweest, wellicht kan je me voorzien van wat additionele informatie, want door een belletje van een Promise dealer ben ik toch weer aan het twijfelen geslagen

Ik had mijn zinnen gezet op een ZFS Solaris opstelling als iSCSI target.
( Vooral de SSD cashe optie vind ik erg interessant! )
Wat ik wilde doen, en hier komt die:

2 Host machines. (Oude hardware die we hebben) voorzien van Solaris in een intern netwerk. Via een HBA beide Solaris machines koppelen aan de zelfde JBOD chassis.

Nu zit ik me helemaal het rambam te zoeken naar een SAS Expander voor de Jbod met 4 externe poorten, of een manier om 2 expanders binnen te kunnen crossen. (Wat ik begrijp uit de topologie van SAS moet dat kunnen.) Waardoor je als het ware 1 hosts kunt switche met de zelfde disk array.

Uiteraard wil je dit niet continu, amar op basis van HA vervolgens wel of niet de pci-e slot aanzetten op de Primary Host.

Klinkt het allemaal nog logisch wat ik zo zeg?
Soort DRBD HA maar dan maar met 1x een disk array er achter.

Nu gaat mijn eigen setup nog wel het één en ander kosten. (Exclusief de disks.)
En dat valt natuurlijk altijd tegen :-) (Zeker omdat je in je hoofd zo goedkoop mogelijk iets probeert te realiseren.)

Via een dealer van promise kreeg ik het aanbod om het instap 1820 model te nemen van Promise VessRaid. Deze heeft 8 disks en 2 voedingen, met slechts 1 controller en is voorzien van iSCSI met 4x 1Gbit.

Zijn er mensen met positieve en negatieve ervaringen met Promise i.c.m. Xen?
Ik lees over het algemeen goede verhalen als backup device, maar ook weer van die mensen die roepen: "ik zou het nooit in een productie omgeving gebruiken." Dus een hoop tegenstrijdigheden!

In mijn optiek:

Voordelen Promise:
- out of the box, plug &play.
- betaalbaar
- een merk / leverancier

Nadelen Promise:
- slechts 1 controller.
- helaas niet alleen positieve verhalen op internet.

Voordelen Zelfbouw:
- Tweakbaar naar eigen wensen
- Meer HA qua hardware controller
- Geen hardware raid maar cpu raid d.m.v. ZFS. <-- beter restorable?

Nadelen Zelfbouw:
- Kosten moeilijk in te schatten.
- Geen support.
- Software Raid via OS (ZFS). <-- performance?
- Kost een hoop tijd.

Nou moet ik zeggen dat tijd geen belemmering is, daar ik het ontzettend leuk vind om spelenderwijs dingen te leren en te kunnen handelen :-)

Maar goed, ieder die nog een nuttige toevoeging heeft, graag!

je vergelijkt appelen met peren: je zelfbouw maak je overloos complex en redundant, en de promise doos is enkele storage oplossing. Vergelijk je promise doos met een eenvoudige kist met een 6 tot 10-tal disks en OpenSolaris erop.

Wat is jouw definitie voor wanneer iets een SAN mag heten, of wanneer het een storage doos is? Want als wat LUN's kunnen exporteren via iSCSI kan je toch zowel VM's hosten als hier heen backuppen. (Mijninziens net welk labeltje je er aan hangt.)

Wellicht lijkt het overloos complex wat ik wil, maar ik probeer single point of failures zoveel mogelijk te voorkomen binnen mijn budget. Daarnaast is een DRBD HA setup wat mij betreft niet de meest energie zuinige en goedkope. (2x disk array online.)

Ik snap je punt dat je Promise niet 1 op 1 kunt vergelijken, maar zoals ik al vaker lees hier zijn er heel veel mensen die een SAN draaien puur op basis van de redundancy IN de SAN, en niet een hot-standby/spare hebben of iets dergelijks.

Ik ben dus benieuwd of je hier met een Promise op zou kunnen rekenen.
Voor een backup device is het niet erg als die even niet bereikbaar is, maar voor een SAN waarvan Virtuele machines draaien wordt het toch wat minder prettig.

Oorspronkelijk geplaatst door Armand

Ik snap je punt dat je Promise niet 1 op 1 kunt vergelijken, maar zoals ik al vaker lees hier zijn er heel veel mensen die een SAN draaien puur op basis van de redundancy IN de SAN, en niet een hot-standby/spare hebben of iets dergelijks.

Ik ben dus benieuwd of je hier met een Promise op zou kunnen rekenen.
Voor een backup device is het niet erg als die even niet bereikbaar is, maar voor een SAN waarvan Virtuele machines draaien wordt het toch wat minder prettig.

Ik zit ook met dat probleem en wil zelf in principe met een server met normale HW RAID gaan draaien en via drbd naar een spare SAN laten schrijven met heartbeat. En iscsi (zover het er nu uit ziet) zal verder gebruikt worden.

Ik heb vandaag eens met dat Nexenta storage lopen spelen. Best leuk! Voor 10k heb je de software voor 2 storage units en high availability (realtime, synchroon, active/active). Dan alleen nog hardware. Maar dan kun je voor 20k wel storage hebben over 2 locaties.

Heb je 1 locaties, dan koop je voor dat geld ook een Equallogic :P

Oorspronkelijk geplaatst door Yourwebhoster

Ik zit ook met dat probleem en wil zelf in principe met een server met normale HW RAID gaan draaien en via drbd naar een spare SAN laten schrijven met heartbeat. En iscsi (zover het er nu uit ziet) zal verder gebruikt worden.

Tja, ik heb dit doorgerekend deze week en als ik uit ga van het volgende:
- 3U Supermicro met 16x hotswap bays
- RAID kaart met BBU
- Intel quadport card
- Quadcore met 8GB geheugen
- 16 x 10.000 rpm 450GB SAS

Dan kom ik per node al snel richting de 8 a 10k. Doe dat 2 keer en je zit op 16/20k. Vervolgens moet je er software op kopen of ontwikkelen en daarnaast onderhouden, updaten etc. Als ik in ons geval die uren ga doorrekenen dan is het prijsverschil met een proffesionele boxed oplossing zoals een equallogic gewoon te klein om het een goede oplossing te noemen. In mijn businesscase, waarin ik onze kostprijs uurtarieven doorreken kom ik zelfs duurder uit dan een soortgelijk Equallogic (op basis van offerte met flinke korting tov listprice).

Enige oplossing die in mijn berekening goedkoper uitkwam was EonStor, of een oplossing waarbij je kiest voor minder redunancy, maar dat was voor ons een harde eis.

Voordeel van Eonstor is dat je minder afhankelijk bent van EonStor voor het leveren van bijv hdd's, je kunt ze gewoon zelf erin zetten, wat hoop geld scheelt. Nadeel hiervan is dat je RMA van HDD's etc ook zelf moet regelen met betreffende leverancier ipv all-in support contract zoals bij Dell Equallogic. Ander puntje wat ik bij EonStor nog niet echt kon doorgronden was de support op de unit, voor zover ik dat heb kunnen achterhalen is de echte mission-critical support niet mogelijk vanuit de fabrikant, maar moet dit via de verkoopkanalen. Maar hier kan Randy wss wel wat meer over zeggen.

Kan je overigens mededelen dat wij voor een Equallogic zullen gaan, zijn nu de details aan het uitwerken en hopelijk in de loop van januari kunnen we met de unit aan de slag.

@Sander
het is maar wat je zelf wilt, voor mijn budget en wat ik er in ga stoppen (zeker geen 450Gb schijfjes, meer iets van 147 GB) is dat wel haalbaar. En de spare SAN kan in principe met normale (goedkope) schijven draaien omdat deze tijdelijk de andere SAN moet opvangen, natuurlijk moet de andere SAN zsm terug komen ivm prestatie problemen. In sommige gevallen zal dit niet voldoen, ik doe het zelf ook net een tikje anders (wel gewoon de zelfde schijven/configuratie) omdat ik kleinere schijven gebruik en dus minder kosten, ik heb die extra ruimte op dit moment niet nodig. Zoiets is dus echt situatie afhankelijk en afhankelijk van de eisen die je zelf stelt natuurlijk.

Oorspronkelijk geplaatst door Yourwebhoster

@Sander
het is maar wat je zelf wilt, voor mijn budget en wat ik er in ga stoppen (zeker geen 450Gb schijfjes, meer iets van 147 GB) is dat wel haalbaar. En de spare SAN kan in principe met normale (goedkope) schijven draaien omdat deze tijdelijk de andere SAN moet opvangen, natuurlijk moet de andere SAN zsm terug komen ivm prestatie problemen. In sommige gevallen zal dit niet voldoen, ik doe het zelf ook net een tikje anders (wel gewoon de zelfde schijven/configuratie) omdat ik kleinere schijven gebruik en dus minder kosten, ik heb die extra ruimte op dit moment niet nodig. Zoiets is dus echt situatie afhankelijk en afhankelijk van de eisen die je zelf stelt natuurlijk.

Tja, als je als 2e SAN een goedkopere configuratie neemt dan heb je wel het risico dat bij langdurige uitval je performance er flink onder gaat leiden. Daarnaast is het kwa disks ook kijken naar prijs/prestatie, je prijs per GB is bij 147GB disks misschien wel hoger dan bij 450 (dat was iig bij ons zo) omdat je netto minder over houdt maar wel zelfde stroomverbruik hebt van de 2 machines, dezelfde raid-kaart etc. Dat is even berekenen voor je eigen situatie, maar dat zijn wel dingen die veel uit kunnen maken. Daarnaast hangt het er ook vanaf wat je eigen uren kosten en of je dr tijd voor "over" hebt.

Neemt niet weg dat wij richting de toekomst dit soort dingen zeker weer zullen overwegen, het is natuurlijk ook wel fijn om vendor onafhaknelijk te kunnen zijn. En als dat net zo betrouwbaar en goedkoper is, tja waarom dan dief zijn van je eigen portemonnee ;-)

Sander-,

Wat ik me afvraag of je met die 450Gb schijven niet teveel ruimte hebt ten opzichte van de performance die je uiteindelijk gaat halen.... We hebben 6,5TB staan voor vms maar als ik zie hoeveel er gebruikt wordt en hoeveel ruimte er nog is qua performance dan kun je beter wat kleinere nodes pakken ipv grote en uiteindelijk de ruimte niet gebruiken...

Oorspronkelijk geplaatst door Mikey

Sander-,

Wat ik me afvraag of je met die 450Gb schijven niet teveel ruimte hebt ten opzichte van de performance die je uiteindelijk gaat halen.... We hebben 6,5TB staan voor vms maar als ik zie hoeveel er gebruikt wordt en hoeveel ruimte er nog is qua performance dan kun je beter wat kleinere nodes pakken ipv grote en uiteindelijk de ruimte niet gebruiken...

Hangt er vanaf wat voor type klanten je hebt. Wij hebben een aantal klanten die graag ook hun data op snelle storage willen hebben. Dan praat je dus over webapplicaties met flinke hoeveelheden filestorage voor bijv een sloot foto's etc. Groot deel van die data wordt niet gebruikt, het zit achter slot en grendel voor de gewone bezoekers en is voor een hele kleine doelgroep interessant. Zelfde geld bijvoorbeeld voor PDF's met specs etc die snel een aantal mb per file in beslag nemen en waar je er enkele duizenden van hebt.

Op basis van een analyse van ons huidig gebruik met deels een SAN en deels local disk kwam ik nog niet halverwege de IO's die de Equallogic ruw kan leveren zonder caching. En dat is een gebruik van circa 2TB. Netto krijgen we met die Equallogic 4.7TB, dus als het soort belasting gelijk blijft voorzie ik geen problemen. En mocht het wel zo zijn, dan hebben we mooi stukje ruimte dat we aan onze backup omgeving kunnen uitlenen voor backups van de uitwijklocatie en lokale backups bij klanten. Dat gebeurd toch op moment dat de belasting van de virtualisatie machines minimaal is.

Kan me trouwens wel voorstellen dat je performance een bottleneck is als je 16 x 1TB S-ATA ofzo erin gooit.

Oorspronkelijk geplaatst door Sander-

Kan me trouwens wel voorstellen dat je performance een bottleneck is als je 16 x 1TB S-ATA ofzo erin gooit.

Nou daar doel ik dus op, iets wat je veel ziet, zoveel mogelijk storage in een bak schuiven. En uiteindelijk tot de conclusie komen dat er ontzettend veel ruimte niet eens nodig was.....

Oorspronkelijk geplaatst door Mikey

Nou daar doel ik dus op, iets wat je veel ziet, zoveel mogelijk storage in een bak schuiven. En uiteindelijk tot de conclusie komen dat er ontzettend veel ruimte niet eens nodig was.....

Tja, bij een SAN wordt vaak gedacht dat diskspace de belangrijkste factor is, maar eigenlijk is de belangrijkste berekening die je moet maken die van de iops. Helaas is dat nogal eens moeilijk, omdat al die apparaten (gelukkig) cachen, dus tja dan maar op basis van ruwe disks en alles wat over blijft is mooi meegenomen. Wij zijn in onze berekening uitgegaan van 130iops per 10k SAS disk, 14 disks actief in gebruik (2 spare), kom je op 1820iops ruwe capaciteit.

alles hangt af van je toestel en de noden. Ik ben zeer tevreden van de sun thumpers als storage arrays, 46 SATA disks, verdeeld over 6 LSI controllers... Maar elk zijn noden. Ik zo zelf niet het geld uitgeven aan SAS en grote SAS disks, steek er dan gewoon wat extra SATA disks in, en spreid je data en iops. In the end is het voornamelijk het aantal heads, platters en spindles die het aantal iops bepaald.