Onderwerp: Welke NAS software? (Voor een VPS platform)

Draai op dit moment twee Nexenta servers als VPS storage oplossing.
Hebben SATA voor storage, SSD voor caching. Raidz3 voor 3 parity schijven.
Ik mag dus drie schijven verliezen voordat ik in de problemen kom.
Met een "redelijke" performance alhoewel ik de volgende opstelling met SAS schijven ga uitrusten....
SATA is toch wel de bottleneck.

Verder vind ik Nexenta een prima product! Alleen een HA opstelling realiseren is niet mogelijk met de gratis versie.
Payware is een oplossing maar dan moet je een dik gevulde knip hebben.
Alternatieven vind/vond ik te ranzig voor woorden om daar een stabiele omgeving op te kunnen realiseren.
Nu maar een risico met een "single point of failure".

Andere ervaring is de HP Lefthand oplossing... mijn ultieme droom...!

Oorspronkelijk geplaatst door crossplatform

Alternatieven vind/vond ik te ranzig voor woorden om daar een stabiele omgeving op te kunnen realiseren.
Nu maar een risico met een "single point of failure".

Hangt natuurlijk van je eisen af aan de uptime, maar als het systeem zelf al - zo ver dat mogelijk is - redundant is met raid controllers voedingen etc dan is de kans van uitval zoveel kleiner dat het acceptabel kan zijn. Goed daar betaal je dan ook weer voor.

Kijk ook eens naar MooseFS, met een distributed filesystem omzeil je single points of failure, als je het goed opzet tenminste want moosefs heeft standaard geen redundante master. Daarnaast vermeid je bottlenecks omdat je eenvoudig storage nodes kan bij plaatsen en zo spindles en dus IOPS kan toevoegen. De throughput is heel acceptable, de latency lijkt echter wel wat hoger op VPS'en die met de images op Moosefs draaien.

Oorspronkelijk geplaatst door crossplatform

Verder vind ik Nexenta een prima product! Alleen een HA opstelling realiseren is niet mogelijk met de gratis versie.

Een HA opstelling realiseren kan natuurlijk ook op een andere manier dan met de betaalde HA Cluster oplossing, wat overigens in het geval van NexentaStor een plugin is op basis van RSF-1 die door Nexenta weer ingekocht wordt bij HighAvailability.com.

Als je 2 Nexenta servers neemt met bijvoorbeeld een Silver licentie en je biedt vanaf die twee servers blokken storage aan naar je gevirtualiseerde servers dan kun je daar in de VM's natuurlijk prima een mirror overheen zetten. Als dan een van de twee Nexenta storage servers onbeschikbaar wordt draait je VM gewoon door.

Toegegeven, dat schaalt wat minder dan de HA Cluster oplossing, waarbij je twee zogenaamde Headnodes met shared disk arrays verbindt. Het scheelt wel aanzienlijk in de licentiekosten, maar beheersmatig is het misschien niet zo super.

En je performance stort totaal in wanneer node x weer online komt omdat alle mirrors vanuit de vm's gesync'd gaan worden.

Oorspronkelijk geplaatst door gjtje

En je performance stort totaal in wanneer node x weer online komt omdat alle mirrors vanuit de vm's gesync'd gaan worden.

Dat zou je inderdaad geneigd zijn om op het eerste zicht te zeggen en voor veel gevallen zal het inderdaad zo zijn dat er een aanzienlijke vermindering in performance zal zijn, maar 'het werkt nog wel'.
Ik denk dat met gedistribueerde setups zoals met MooseFS en Gluster die aanzienlijke performancevermindering ook het geval zal zijn bij een twee node-setup en idem voor een setup op basis van DRBD.

Met een beetje tunen aan de rebuild snelheid van je mirrors zou het nog wel eens goed mee kunnen vallen, je bent dan in ieder geval niet een arm en een been kwijt. Zoals ik al zei schaalt dit niet zo goed, met andere woorden werkt het eigenlijk alleen bij kleine getallen, ik zou zeggen minder dan 4TB required storage. Wat helpt is dat je zo'n NexentaStor appliance kunt voorzien van slog devices voor je ZIL en l2arc op basis van ssd drives.

Het probleem is natuurlijk dat je niet alles kunt willen. Het kan niet EN goedkoop EN schaalbaar EN performant EN redundant EN blijvende performance bij rebuilds.

Stel je neemt de 2 Nexenta servers uit mijn voorbeeld met 8TB aan storage, dan ben je voor die twee servers al gauw meer dan 10K euro kwijt aan hardware en licenties. Als je daar een HA-CLuster op basis van Nexenta tegenover zet ben je voor dezelfde hoeveelheid storage al gauw meer dan het drievoudige kwijt. Als je dan meer capaciteit nodig hebt wordt komt het kantelpunt snel dichtbij, momenteel ligt dat op ongeveer 24TB. Boven de 24TB is het eenvoudig, dan is het goedkoper om voor een HA-Cluster met 2 heads en shared disk arrays te gaan.

Voor mijn suggestie ben ik uitgegaan van het budget en de mogelijkheden van crossplatform en heb ik aangegeven hoe je met zo'n budget toch redunancy kunt realiseren:

Oorspronkelijk geplaatst door crossplatform

Verder vind ik Nexenta een prima product! Alleen een HA opstelling realiseren is niet mogelijk met de gratis versie.
Payware is een oplossing maar dan moet je een dik gevulde knip hebben.
Alternatieven vind/vond ik te ranzig voor woorden om daar een stabiele omgeving op te kunnen realiseren.
Nu maar een risico met een "single point of failure".

Zolang je in termen van 1-2 storages denkt kun je ook even een eigen kernel bakken met isci (scst) of het gewoon in userspace laden (ietd). Dan 20 regels van heartbeat kopieeren, drbd ertussen met een 10gb link en replicatie speed beetje limiteren zodat je vm's geen overlast hebben. Middage prutsen, scheelt je al snel een paar k ten opzichte van een storage os. (Als je zo'n os uit elkaar trekt is het meestal toch niet meer dan een paar daemons zoals samba, nfs, iscsi en een dik n00bpr00f webschilletje)
En als je dan ook nog zfs wilt dan dan is dat ook met een paar regels gedaan, mits je os een leuke zfs versie ondersteund.

Oorspronkelijk geplaatst door systemdeveloper

Zolang je in termen van 1-2 storages denkt kun je ook even een eigen kernel bakken met isci (scst) of het gewoon in userspace laden (ietd). Dan 20 regels van heartbeat kopieeren, drbd ertussen met een 10gb link en replicatie speed beetje limiteren zodat je vm's geen overlast hebben. Middage prutsen, scheelt je al snel een paar k ten opzichte van een storage os. (Als je zo'n os uit elkaar trekt is het meestal toch niet meer dan een paar daemons zoals samba, nfs, iscsi en een dik n00bpr00f webschilletje)
En als je dan ook nog zfs wilt dan dan is dat ook met een paar regels gedaan, mits je os een leuke zfs versie ondersteund.

Er is natuurlijk niets mis met een drbd oplossing, maar DRBD en ZFS gaan niet zo goed samen, DRBD is strictly Linux en ZFS wil graag zelf controle over de blockdevices. Dan zou je dus een aantal DRBD devices moeten maken (een per fysieke drive) en dan daaroverheen een ZFS zetten. Dan heb je al gauw niet meer genoeg aan heartbeat, maar dan moet je aan de slag met corosync/pacemaker omdat je een hele stapel dependancies moet gaan opvangen. Bovendien weet ik niet hoe stabiel de enige ZFS-kernelspace implementatie van ZFS op dit moment is (iemand met ervaring misschien?). Op zich is dat nog wel een leuke uitdaging en een richting waarvoor ik voor het uitzoeken van de mogelijkheden en het maken van een Proof of Concept graag een HBO stagair zou willen opzadelen met een opdracht.

Overigens is DRBD, net zoals Nexenta een stuk software waarvan ook een betaalversie bestaat. Distributed Replicated Block Device wordt ontwikkeld en ondersteund door LinBit http://www.linbit.com/en/products-services/drbd/ en dan hoef je dus niet eens een eigen kernel te bakken en ook geen cluster-setup te verzinnen.

Natuurlijk ben ik het als leverancier van dergelijke oplossingen niet met je eens dat het 'niet meer is dan een paar daemons en een dik n00bpr00f webschilletje'. De toegevoegde waarde van de betaalversies van dergelijke pakketten ligt hem mijns inziens meestal niet in het toegevoegde-featureset van het product, maar in de uitwerking van gebruiksscenarios en in de ondersteuning van bepaalde configuraties. Voor die toegevoegde waarde moet je inderdaad al gauw 'een paar k' aan euro's neertellen en dat heeft natuurlijk alleen zin als je van die toegevoegde waarde ook gebruik kunt en gaat maken.

Dat er een grafisch beheerschilletje om zo'n oplossing heen zit voor het uitvoeren van taken die vaak of regelmatig uitgevoerd worden heeft ook een bepaalde toegevoegde waarde, maar soms is die toegevoegde waarde vooral dat je het makkelijker kunt verkopen omdat je aan de persoon die een handtekening gaat zetten voor het tientallen K-euro bedrag het product kunt laten 'zien en voelen', terwijl de uiteindelijke gebruikers (beheerder) van de oplossing zich voornamelijk tot de commanline interface of zelfs tot de API van de oplossing zullen beperken voor het gebruik ervan. Ik denk ook dat je met een beheerder zonder voldoende kennis en/of ervaring met de mogelijkheden van de software of oplossing (n00b blijf ik toch een beetje denigrerend klinken) met de GUI interface (of dat nou een webschilletje of een tk beheerpakketje is) meer stuk kunt maken dan je lief is met een paar klikken (are you sure you want to remove your zpool? yes/no).

Wat ik in de voorgestelde methode een beetje inconsequent vindt is het gebruik van de 10gb link, omdat twee van die 10gb kaartjes bij elkaar ook al gauw duizend euro kosten en wat kost bij jou 'een middagje prutsen'. Voor je het weet ben je 'een maand lang iedere dag een middagje aan het prutsen'. Als je daar voor gaat zou ik zeggen 'bespaar je de moeite, neem twee losse servers en doe de replicatie in je vm's zoals ik al voorstelde', dat is een KISS oplossing en ook nog eens een waar je de beperkingen makkelijk van kunt bepalen. Als het echt goedkoop moet kun je in plaats van Nexenta ook voor OpenIndiana gaan met ZFS en dan geef je de euro's die je uit zou geven aan de Nexenta software uit aan een paar leuke STEC ssd drives die je als L2ARC of ZIL inzet wat je nog een bak extra performance oplevert.

Oorspronkelijk geplaatst door koendejonge

Er is natuurlijk niets mis met een drbd oplossing, maar DRBD en ZFS gaan niet zo goed samen, DRBD is strictly Linux en ZFS wil graag zelf controle over de blockdevices. Dan zou je dus een aantal DRBD devices moeten maken (een per fysieke drive) en dan daaroverheen een ZFS zetten. Dan heb je al gauw niet meer genoeg aan heartbeat, maar dan moet je aan de slag met corosync/pacemaker omdat je een hele stapel dependancies moet gaan opvangen. Bovendien weet ik niet hoe stabiel de enige ZFS-kernelspace implementatie van ZFS op dit moment is (iemand met ervaring misschien?). Op zich is dat nog wel een leuke uitdaging en een richting waarvoor ik voor het uitzoeken van de mogelijkheden en het maken van een Proof of Concept graag een HBO stagair zou willen opzadelen met een opdracht.

Overigens is DRBD, net zoals Nexenta een stuk software waarvan ook een betaalversie bestaat. Distributed Replicated Block Device wordt ontwikkeld en ondersteund door LinBit http://www.linbit.com/en/products-services/drbd/ en dan hoef je dus niet eens een eigen kernel te bakken en ook geen cluster-setup te verzinnen.

Natuurlijk ben ik het als leverancier van dergelijke oplossingen niet met je eens dat het 'niet meer is dan een paar daemons en een dik n00bpr00f webschilletje'. De toegevoegde waarde van de betaalversies van dergelijke pakketten ligt hem mijns inziens meestal niet in het toegevoegde-featureset van het product, maar in de uitwerking van gebruiksscenarios en in de ondersteuning van bepaalde configuraties. Voor die toegevoegde waarde moet je inderdaad al gauw 'een paar k' aan euro's neertellen en dat heeft natuurlijk alleen zin als je van die toegevoegde waarde ook gebruik kunt en gaat maken.

Dat er een grafisch beheerschilletje om zo'n oplossing heen zit voor het uitvoeren van taken die vaak of regelmatig uitgevoerd worden heeft ook een bepaalde toegevoegde waarde, maar soms is die toegevoegde waarde vooral dat je het makkelijker kunt verkopen omdat je aan de persoon die een handtekening gaat zetten voor het tientallen K-euro bedrag het product kunt laten 'zien en voelen', terwijl de uiteindelijke gebruikers (beheerder) van de oplossing zich voornamelijk tot de commanline interface of zelfs tot de API van de oplossing zullen beperken voor het gebruik ervan. Ik denk ook dat je met een beheerder zonder voldoende kennis en/of ervaring met de mogelijkheden van de software of oplossing (n00b blijf ik toch een beetje denigrerend klinken) met de GUI interface (of dat nou een webschilletje of een tk beheerpakketje is) meer stuk kunt maken dan je lief is met een paar klikken (are you sure you want to remove your zpool? yes/no).

Wat ik in de voorgestelde methode een beetje inconsequent vindt is het gebruik van de 10gb link, omdat twee van die 10gb kaartjes bij elkaar ook al gauw duizend euro kosten en wat kost bij jou 'een middagje prutsen'. Voor je het weet ben je 'een maand lang iedere dag een middagje aan het prutsen'. Als je daar voor gaat zou ik zeggen 'bespaar je de moeite, neem twee losse servers en doe de replicatie in je vm's zoals ik al voorstelde', dat is een KISS oplossing en ook nog eens een waar je de beperkingen makkelijk van kunt bepalen. Als het echt goedkoop moet kun je in plaats van Nexenta ook voor OpenIndiana gaan met ZFS en dan geef je de euro's die je uit zou geven aan de Nexenta software uit aan een paar leuke STEC ssd drives die je als L2ARC of ZIL inzet wat je nog een bak extra performance oplevert.

Die eigen kernel bakken sloeg op het SCST iscsi deel. SCST op kernel basis is imho by far de snelste iscsi implementatie. DRBD kun je inderdaad gewoon als kernel laden.
ZFS gebruik ik al vanaf versie 13 op freebsd als ik me goed herinner. Ik heb dat jaren gedraaid op een raid50 van 12 satadisks zonder ssd en met amper 6gb ram. Liep als een trein en gewoon nooit een probleem mee gehad. Geen klagen over zfs van mijn kant dus. Over het dedub deel blijf ik mijn bedenkingen hebben overigens... leuk voor kleine setups maar met 500miljoen bestanden kun je het geheugen per vrachtwagen bestellen.

Wat je allemaal zegt klopt als een bus en ben ik het ook 95% met je eens. Maar ik heb ook genoeg situaties waarbij een kant en klare oplossing gewoon een pain in the ass is, niet schaalt, voor bepaalde situaties niet rendabel genoeg, instapkosten voor een klant gewoon te hoog zijn, etc.. dan moet je een beetje schipperen.
Ik ben trouwens zelf partner van een grote storage club en lever dat spul ook. Maar dat betekent niet dat ik een bepaald storage os als de heilige graal zie of altijd als de juiste oplossing.
Of ik door mijn 'rants' een licentie meer of minder verkoop, lig ik dan weer niet wakker van. Ik ben het niet per definitie ergens mee eens/oneens omdat ik toevallig ook een bepaald product verkoop.
Feit blijft natuurlijk wel, dat je met 2 commercieele licenties en 2 servertjes op een uurtje je ha storage in orde kunt hebben.

Oorspronkelijk geplaatst door systemdeveloper

Die eigen kernel bakken sloeg op het SCST iscsi deel. SCST op kernel basis is imho by far de snelste iscsi implementatie. DRBD kun je inderdaad gewoon als kernel laden.
ZFS gebruik ik al vanaf versie 13 op freebsd als ik me goed herinner. Ik heb dat jaren gedraaid op een raid50 van 12 satadisks zonder ssd en met amper 6gb ram. Liep als een trein en gewoon nooit een probleem mee gehad.

Jammer dat DRBD echt een linux only stukje software is. En jammer dat de ZFS implementaties op Linux nog niet zo super zijn, want dan zou je echt een kick-ass systeem kunnen bouwen.

Oorspronkelijk geplaatst door systemdeveloper

Geen klagen over zfs van mijn kant dus. Over het dedub deel blijf ik mijn bedenkingen hebben overigens... leuk voor kleine setups maar met 500miljoen bestanden kun je het geheugen per vrachtwagen bestellen.

Ik geloof direct dat deduplicatie hardstikke goed werkt, zeker in een lab-situatie. Maar de business case om het aan te zetten op ZFS is niet zo heel snel te maken. Geheugen per vrachtwagen is op zich geen punt natuurlijk, maar in de meeste gevallen zal het al snel goedkoper zijn om SSD als opslagmedium per vrachtwagen te bestellen.

Oorspronkelijk geplaatst door systemdeveloper

Wat je allemaal zegt klopt als een bus en ben ik het ook 95% met je eens. Maar ik heb ook genoeg situaties waarbij een kant en klare oplossing gewoon een pain in the ass is, niet schaalt, voor bepaalde situaties niet rendabel genoeg, instapkosten voor een klant gewoon te hoog zijn, etc.. dan moet je een beetje schipperen.

Als een kant en klare oplossing een pain in the ass is dan is het meestal zo dat de eisen aan de kant van de klant te hoog zijn, of het budget te laag. HA kost nou eenmaal geld en als je dat niet hebt, of er niet voor over hebt dan wordt het moeilijk. Ik heb zelf vaak genoeg de fout gemaakt om dan met een halfbakken HA oplossing aan de slag te gaan, uiteindelijk kost dat meestal meer dan wanneer je direct voor de HA gegaan was.

Oorspronkelijk geplaatst door systemdeveloper

Ik ben trouwens zelf partner van een grote storage club en lever dat spul ook. Maar dat betekent niet dat ik een bepaald storage os als de heilige graal zie of altijd als de juiste oplossing.
Of ik door mijn 'rants' een licentie meer of minder verkoop, lig ik dan weer niet wakker van. Ik ben het niet per definitie ergens mee eens/oneens omdat ik toevallig ook een bepaald product verkoop.
Feit blijft natuurlijk wel, dat je met 2 commercieele licenties en 2 servertjes op een uurtje je ha storage in orde kunt hebben.

Je hoort mij natuurlijk niet zeggen dat er een heilige graal is, hoewel ik een lichte voorkeur heb voor een ZFS gebaseerde oplossing omdat daar een aantal zaken in zitten die gewoon rocken. En dan heb ik het met name over de end to end data-integriteit. Verder geef ik natuurlijk vooral de mogelijkheden aan, want ik verkoop geen licenties maar oplossingen. Maar nu moeten we wel een beetje gaan oppassen dat we het over het verkopen van hardware/software oplossingen gaan hebben want dat is off-topic.

On topic: als je weinig geld hebt, maar veel tijd en je kan zelf iets dan is een eigen oplossing vaak beter omdat je dan beter de beperkingen en mogelijkheden van je oplossing kent.

Oorspronkelijk geplaatst door koendejonge

Je hoort mij natuurlijk niet zeggen dat er een heilige graal is, hoewel ik een lichte voorkeur heb voor een ZFS gebaseerde oplossing omdat daar een aantal zaken in zitten die gewoon rocken. En dan heb ik het met name over de end to end data-integriteit. Verder geef ik natuurlijk vooral de mogelijkheden aan, want ik verkoop geen licenties maar oplossingen. Maar nu moeten we wel een beetje gaan oppassen dat we het over het verkopen van hardware/software oplossingen gaan hebben want dat is off-topic.

On topic: als je weinig geld hebt, maar veel tijd en je kan zelf iets dan is een eigen oplossing vaak beter omdat je dan beter de beperkingen en mogelijkheden van je oplossing kent.

Ik vind het wel interessant om mee te lezen en anderen wellicht ook, dus met informatie gooien kan best denk ik. Open-e en Nexenta zijn verschillende systemen maar je moet kijken wat per situatie beter is denk ik? Met Nexenta kan je leuk cachen (hoewel ik de werking niet ken) en met Open-e ook hoewel dat dan via een RAID controller moet. Ken de systemen inhoudelijk verder niet dus don't blame me als ik wat verkeerd zeg en snap best dat er verschillen in zal zitten. Wat in ieder geval wel zo is dat de ontwikkeling bij storage systemen niet stil staat.

Je hebt het over OpenIndiana, maar is die stabiel genoeg om in productie te draaien? Ik zie dat ze het zelf hebben over development releases.