Kazutaka Morita hob das Sheepdog-Projekt 2009 aus der Taufe, weil es keine Open Source-Implementierung einer Cloud-fähigen Storage-Lösung gab, die ähnlich funktionierte wie Amazons S3. Nach dem ursprünglichen Plan sollte Sheepdog [1] skalierbar, hochverfügbar und einfach zu verwalten sein. Das Setup von Ceph, das damals schon existierte, war Kazutaka zu kompliziert. GlusterFS wiederum war weitgehend unbekannt. Außerdem gilt für beide, dass sie damals eher auf den NAS-Markt zielten. Sheepdog war von Anfang an als Storage-Infrastruktur für KVM/Qemu vorgesehen (siehe auch Kasten “Virtuelle Abbilder mit Sheepdog”). Da Kazutaka bei der NTT (Nippon Telegraph and Telephone Corporation) arbeitet, finden sich entsprechende Copyright-Vermerke im Quelltext, der aber unter der GPLv2-Lizenz steht.
Grob gesagt besteht Sheepdog aus drei Komponenten: einer Clusterware, Storage-Servern und dem Netzwerk. Zum Thema Netzwerk gibt es nicht viel zu sagen. Die Software ist IP-basiert, und das impliziert für die meisten Umgebungen Ethernet als Transportmedium. Prinzipiell ist auch Infiniband nutzbar, solange der Stack eine IP-Adresse an Sheepdog weiterreicht.
Die Clusterware hat drei Funktionen. Sie protokolliert, welche Rechner gerade Teil des Verbundes sind, verteilt Nachrichten an die beteiligten Knoten und unterstützt das Locking von Storage-Objekten. Die entsprechende Software ist übrigens nicht Bestandteil des Projekts. Ihre Installation und Konfiguration muss der Admin erledigen, bevor Sheepdog an der Reihe ist. In der Standard-Konfiguration setzt Sheepdog dazu auf Corosync [2]. Alternativ kann der Anwender auch Zookeeper [3] verwenden. Beim Übersetzen der Software ist der -Aufruf dazu mit der Option zu versehen. Bei Zookeeper von Clusterware zu sprechen, ist eigentlich nicht ganz korrekt. Die Software stellt zwar die oben genannten Funktionen bereit, ist aber
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.