{"id":33523,"date":"2019-10-31T21:53:05","date_gmt":"2019-10-31T18:53:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/hranilishhe-linstor-i-ego-integratsiya-s-opennebula\/"},"modified":"2019-10-31T21:53:05","modified_gmt":"2019-10-31T18:53:05","slug":"hranilishhe-linstor-i-ego-integratsiya-s-opennebula","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/hranilishhe-linstor-i-ego-integratsiya-s-opennebula","title":{"rendered":"LINSTOR-Speicher und seine Integration mit OpenNebula","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"LINSTOR-Speicher<\/p>\n

<\/p>\n

Vor nicht allzu langer Zeit pr\u00e4sentierten die Jungs von LINBIT ihre neue SDS-L\u00f6sung \u2013 Linstor. Es handelt sich um einen vollst\u00e4ndig offenen Speicher, der auf bew\u00e4hrten Technologien basiert: DRBD, LVM, ZFS. Linstor vereint Einfachheit und eine gut durchdachte Architektur, die es erm\u00f6glicht, Stabilit\u00e4t und beeindruckende Ergebnisse zu erzielen.<\/p>\n

<\/p>\n

Heute m\u00f6chte ich ein wenig ausf\u00fchrlicher dar\u00fcber sprechen und zeigen, wie einfach es ist, es mit OpenNebula unter Verwendung von linstor_un zu integrieren \u2013 einem neuen Treiber, den ich speziell f\u00fcr diesen Zweck entwickelt habe.<\/p>\n

<\/p>\n

Linstor in Kombination mit OpenNebula erm\u00f6glicht den Aufbau einer schnellen und zuverl\u00e4ssigen Cloud, die problemlos auf der eigenen Infrastruktur bereitgestellt werden kann.<\/p>\n

<\/a><\/noindex><\/p>\n

Architektur von Linstor<\/h2>\n

<\/p>\n

Linstor ist selbst kein Dateisystem und kein Blockspeicher. Linstor ist ein Orchestrator, der eine Abstraktionsschicht bereitstellt, um die Erstellung von Volumes in LVM oder ZFS zu automatisieren und diese mit Hilfe von DRBD9 zu replizieren.<\/p>\n

<\/p>\n

Stereotype aufbrechen<\/h5>\n

<\/p>\n

Aber halt, DRBD? \u2013 Warum sollte man es automatisieren und wie kann das \u00fcberhaupt funktionieren?<\/p>\n

<\/p>\n

Erinnern wir uns an die Vergangenheit, als DRBD8 weit verbreitet war. Seine Standardnutzung sah vor, ein gro\u00dfes Blockger\u00e4t zu erstellen und es mit LVM in viele kleine St\u00fccke zu zerteilen. Eine Art mdadm RAID-1, aber mit Replikation \u00fcber das Netzwerk.<\/p>\n

<\/p>\n

Dieser Ansatz hat seine Nachteile, und daher haben sich mit der Einf\u00fchrung von DRBD9 die Prinzipien des Speichersystems ge\u00e4ndert; jetzt wird f\u00fcr jede virtuelle Maschine ein separates DRBD-Ger\u00e4t erstellt.<\/p>\n

<\/p>\n

Der Ansatz mit unabh\u00e4ngigen Blockger\u00e4ten erm\u00f6glicht eine bessere Raumausnutzung im Cluster und bietet auch eine Reihe zus\u00e4tzlicher M\u00f6glichkeiten. Zum Beispiel kann f\u00fcr jedes dieser Ger\u00e4te die Anzahl der Replikate, deren Standort und individuelle Einstellungen festgelegt werden. Sie lassen sich leicht erstellen\/l\u00f6schen, Snapshots machen, die Gr\u00f6\u00dfe \u00e4ndern, Verschl\u00fcsselung aktivieren und vieles mehr. Es ist erw\u00e4hnenswert, dass DRBD9 auch Quorum unterst\u00fctzt, um Split-Brain-Situationen zu vermeiden.<\/p>\n

<\/p>\n

Ressourcen und Backends<\/h5>\n

<\/p>\n

Beim Erstellen eines neuen Blockger\u00e4ts platziert Linstor die erforderliche Anzahl an Replikaten auf verschiedenen Knoten im Cluster. Jede dieser Replikate nennen wir DRBD-Ressource.<\/p>\n

<\/p>\n

Ressourcen gibt es in zwei Typen:<\/p>\n

<\/p>\n