Bekijk Volledige Versie : Welke NAS software? (Voor een VPS platform)
Wij moeten het huidige platform uitbreiden/vervangen en zijn daarom gaan kijken naar verschillende opties. Na een aantal tests vraag ik me nog steeds af wat de beste optie is mbt de software voor een NAS. Naar een aantal opties heb ik gekeken, waaronder FreeNAS en Nexenta. Welke software zouden jullie in onderstaande situatie gebruiken en, indien van toepassing, met welke licenties/uitbreidingen/support contracten. Andere opties zijn natuurlijk ook interessant om te horen om te bestuderen.
Situatie #1:
2 servers (met elk 36 SATA schijven, 2.5", 500GB)
De servers staan in 1 datacentrum
Data redundant op beide servers (van 1 de stekker er uit trekken en alles blijft zonder problemen werken), ook als 1 hardeschijf uitvalt (willekeurig) moet alles blijven werken (RAID 10 is hier bijvoorbeeld gunstig voor lijkt mij).
iSCSI voor de koppeling naar de front end systemen (over gbit verbindingen)
Front-end bestaat uit een achttal blades waar de VPSen op draaien (dit kan verder toenemen)
Dagelijkse snapshots van alle volumes naar een losse backup server
Web interface voor het beheer (aanmaken/verwijderen LUNs is voldoende)
Situatie #2:
1 servers (met 36 SATA schijven, 2.5", 500GB)
Als 1 hardeschijf uitvalt moet alles blijven werken (RAID 10 is hier bijvoorbeeld gunstig voor lijkt mij).
iSCSI voor de koppeling naar de front end systemen (over gbit verbindingen)
Front-end bestaat uit een achttal blades waar de VPSen op draaien (dit kan verder toenemen)
Dagelijkse snapshots van alle volumes naar een losse backup server
Web interface voor het beheer (aanmaken/verwijderen LUNs is voldoende)
Het verschil tussen de situaties is met name het aantal machines en de redundancy/auto failover.
Ook andere tips om op te letten zijn welkom.
Een topic dat zich specifiek op een situatie als dit toespitst heb ik niet gevonden op het forum.
Ik zou geen sata maar (minimaal) 10k sas gebruiken voor vps'en. De performance van sata is, hier, niet voldoende voor een degelijke snelheid van een vps platform. Je kan wat trukendozen en oprekken met caches, uiteindelijk zullen de iops toch gewoon van de fysieke disks moeten komen.
Je hebt nas en san, dit is typisch een san scenario. Zoek dus ook software die als san is ontworpen, niet nas software die ook als san functioneert.
Het opzetten van een snelle en betrouwbare storage is meer dan alleen iets samenstellen op basis van gevoel of veel=beter en dat soort argumenten. Volledig afhankelijk per situatie (snelheid vs storage vs het type I/O etc), de gekozen hardware, de configuratie en tuning kan een NAS/SAN met 4 disks VEEL sneller en betrouwbaarder (en dus goedkoper) zijn dan een NAS/SAN met 36 disks. En niet alleen het type disks maar zelfs het merk disks (ook al zijn de specs hetzelfde) kunnen bij een NAS/SAN een enorm verschil maken. De gekozen software is hierbij zelfs het minst belangrijk.
Ik zou - als je hier geen ervaring mee hebt althans - je dus adviseren voor dit soort dingen een gespecailiseerd bedrijf te zoeken en niet zelf zoiets gaan opzetten zonder ervaring. Het zal wel werken maar de kans dat je de optimale performace en betrouwbaarheid gaat behalen is vrij klein. Waardoor je op zowel kort termijn als langer termijn veel duurder uit bent omdat je ongetwijfeld onnodig veel hardware aanschaft en daarmee ook nog eens tegen performance problemen etc gaat aanlopen.
Als je toch zelf nog wil proberen zou ik in ieder geval eens kijken naar Open-E. Hoewel ook de juiste software per situatie weer anders kan zijn.
mgielissen
17/06/11, 18:45
Leaseweb heeft net nieuwe 5700 HP ProLiant 120 G6 en HP ProLiant 180 G6 servers aangeschaft, is allemaal SATA spul. Kwestie van budget?
Read more: http://www.computable.nl/artikel/ict_topics/infrastructuur/3992128/2379248/leaseweb-schaft-5700-hp-proliant-servers-aan.html
Laat je niet teveel afschrikken door heel het SATA vs SAS verhaal - in the end ga je met meer spindles normaal meer datadoorvoer kunnen realiseren. Ga wel voor een SATA-schijf die wat kwaliteit is.
Qua software ga je ofwel voor een zelfgebouwd iets (als het één doos is, kan je bvb gewoon linux en ietd gebruiken, zeer stabiel), voor redundantie tussen meerdere machines zit je met een groot vraagstuk. Als je redundantie-over-netwerk implementeert zit je met een zeer grote latency-tradeoff, en ga je
Daar kijk je dan best naar ofwel oplossingen van vendors als een nexenta/open-e/freenas/... of ga je aan de slag moeten met experimentele zaken als GlusterFS, MooseFS of Ceph of iets dergelijks. Als je het werkend, out-of-the-box, zonder zorgen wil, ga je er wel wat centen voor moeten neertellen, je hardware zal het minst van je zorgen zijn.
avanmessen
18/06/11, 12:25
Heb net een 8-disk SuperMicro gekocht die als VPS storage zal dienen.
Ik heb me echter aan SATA disks gehouden (WD Black) onder ZFS met
een RAID10 setup. Zo kan ik maximaal 3 en minimaal 1 disks verliezen en
nog steeds Ok zijn.
Performance tests komen weldra, ik post deze hier wel.
Laat je niet teveel afschrikken door heel het SATA vs SAS verhaal - in the end ga je met meer spindles normaal meer datadoorvoer kunnen realiseren. Ga wel voor een SATA-schijf die wat kwaliteit is.
Zodra je écht veel disks in een enclosure stopt wil je wel SAS, anders ga je problemen krijgen op je kanalen krijgen :)
Maar voor veel mensen staat SAS gelijk aan minimaal 10k RPM, je kan ook prima 1TB SAS disken kopen op 7200RPM.
Ik snap je punt verder, maar als je voor echt veel spindles gaat, neem dan SAS.
Daar kijk je dan best naar ofwel oplossingen van vendors als een nexenta/open-e/freenas/... of ga je aan de slag moeten met experimentele zaken als GlusterFS, MooseFS of Ceph of iets dergelijks. Als je het werkend, out-of-the-box, zonder zorgen wil, ga je er wel wat centen voor moeten neertellen, je hardware zal het minst van je zorgen zijn.Oei, Ceph, dat is voor nu nog wel even een uitdaging ;) Wel leuk though!
Ik zou voor nu lekker een prachtig Nexenta platform opbouwen, daar ga je nu denk ik het meeste plezier van hebben. ZFS is gewoon tof.
Merk op dat er "experimenteel" staat. Te gebruiken naar eigen goeddunken... :-)
Merk op dat er "experimenteel" staat. Te gebruiken naar eigen goeddunken... :-)
Voordat iemand het gekke idee krijgt Ceph wel in productie te gebruiken, niet doen! Het is nu nog leuk om mee te testen, maar productie klaar is het zeker niet.
Mark zou je ons een beetje op de hoogte willen houden van het resultaat na aankoop, wat het uiteindelijk is geworden. Lijkt me zinvol voor de nodige partijen die hetzelfde groei pad kennen.
@Bart: de uitkomsten zal ik zeker melden.
@Wido: het huidige platform zat relatief snel aan zijn limiet (mbt schijfruimte, IOps schijnt ook redelijk tegen de limiet aan te zitten). Daarnaast is de huidige opzet niet prettig met het toevoegen van extra LUN's (niet even snel te doen ivm beperkte toegang).
De meeste opties die ik tot nu toe gezien heb lijken goed te werken voor optie #2, optie #1 is helaas veel minder informatie over beschikbaar. Deze optie heeft op zich de voorkeur mbt betrouwbaarheid, dat er een penalty mbt de performance zal zijn is bij mij bekend.
36 SATA schijven? Dat gaat niet lekker werken, je gaat dan met SAS expanders aan de slag moeten en dan ga je conflicten op je bus krijgen. SATA is nogal egoïstisch om het maar even zo te zeggen. Je SATA disken gaan de kanalen veel te veel bezet houden.
Bij zo veel disken (en gedeelde kanalen) moet je toch echt SAS gebruiken.
Solutionsource
09/08/11, 01:30
Over SATA / SAS is al een hoop gezegd. Ook mijn mening is, met zoveel disken geen SATA doen. SATA werkt prima zolang elke schijf zijn eigen kanaal heeft. Met multipliers wordt het al snel traag.
Wij hebben 2 machines met Ubuntu server erop als SANs. IETD als ISCSI target. DRBD voor blockreplicatie en linux-ha (heartbeat) voor failover. Dit werkt in de praktijk (na wel veel testen en goed configureren) zeer stabiel. Een reboot van een van de twee "sans" wordt nieteens opgemerkt door de Xenserver hosts. De failover gaat zo snel dat niemand er wat van merkt.
Uiteindelijk zijn we voor Ubuntu gegaan, omdat de versies van IETD en DRBD destijds veel nieuwer waren dan die in Debian Lenny. Zelf compilen was voor mij geen optie. Ik heb destijds ook gekeken naar Openfiler en Nexenta, maar vond het moeilijk om hiermee een goede HA setup te bouwen.
Op dit moment hebben wij 8 grote enterprise sata disken, RAID 10, snelle hardware-raid controllers en een hele sloot werkgeheugen per server. In de praktijk wordt alle veel-aangesproken data gewoon gecacht. De performance is dan ook prima.
systemdeveloper
09/08/11, 10:00
Ik ben momenteel overal sata aan het vervangen door SSD's en SAS behalve bij backup machines. Voor gewoon doorvoer op SATA haal ik met gemak 700MB/s (over 8 NICS), maar met random IO (wat in 99,9% van de gevallen gebruikt wordt) is sata gewoon bagger. Of je het nu via freenas, open-e, nexenta of met alleen ietd doet maakt weinig uit imho.
Rinse Kloek
11/08/11, 08:42
Zijn er hier veel mensen die een nexenta storage platform gebruiken voor webhosting of VPS ? Ik zit hier zelf ook naar te kijken, maar zoek een beetje naar user ervaringen.
Omdat we zelf 2 datacenters hebben zitten we ook te kijken naar een HA oplossing over 2 datacenters. Zijn er hier veel ervaringen mee met Nexenta ?
crossplatform
28/11/11, 16:05
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...!:thumbup:
Yourwebhoster
28/11/11, 16:14
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.
koendejonge
21/01/12, 19:04
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.
koendejonge
22/01/12, 16:23
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:
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".
systemdeveloper
22/01/12, 19:20
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.
koendejonge
24/01/12, 00:54
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.
systemdeveloper
24/01/12, 13:40
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.
koendejonge
25/01/12, 00:22
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.
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. :)
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.
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. :)
Yourwebhoster
25/01/12, 08:05
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.