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.
