VMFS, CSV: iSCSI-Target mit mehreren Hosts verbinden

    Mehrere Hosts an einem iSCSI-TargetDienen LUNs auf einem iSCSI-Storage als Speicher für virtuelle Maschinen, dann kann etwa eine Live Migration den gleichzeitigen Zugriff auf ein Volume durch mehrere Hosts erfordern. Das iSCSI-Protokoll bietet aber keinen Schutz gegen Schreibkonflikte und daraus folgende Daten­verluste.

    Aus der Sicht der Clients stellen sich iSCSI-Volumes dar wie lokale Laufwerke. Im Unterschied zu internen Disks, wo der Controller über den Bus direkt mit den Speichermedien kommuniziert, verpackt das iSCSI-Protokoll die SCSI-Befehle in IP-Pakete. Anders als Netzfreigaben, die für Clients als Remote Volumes erkennbar sind, operiert iSCSI auf Blockebene.

    Kein File-Locking durch iSCSI

    Wie andere Transportprotokolle für Storage, also etwa Fibre Channel, weiß iSCSI nichts über Dateien und ist daher nicht in der Lage, diese gegen rivalisierte Zugriffe zu sperren. Daher ist es keine gute Idee, beliebige Clients ohne entsprechende Vorkehrungen mit dem gleichen iSCSI-Target zu verbinden. Datenverluste wären eine absehbare Folge.

    Aus diesem Grund können viele iSCSI-Systeme den Zugriff auf ein Target einschränken, so dass sich zu einem gegebenen Zeitpunkt nur eine Session aufbauen lässt. Synology-Geräte beispielsweise sind per Voreinstellung auf eine Sitzung pro Target limitiert.

    Failover-Cluster brauchen nur eine Session

    Möchte man diesen Zustand ändern, dann ruft man im DSM den Speicher-Manager auf und führt unter iSCSI Target den Befehl Bearbeiten aus. Anschließend kann man auf der Registerkarte Erweitert die Option Lassen Sie mehrere Sitzungen von einem oder mehreren iSCSI-Initiatoren zu aktivieren.

    Synology begrenzt sein iSCSI-Target standardmäßig auf eine Session. Das lässt sich im Speicher-Manager ändern.

    Von dieser Möglichkeit muss man nicht in jedem Fall Gebrauch machen, sobald mehrere Clients auf einem Target operieren sollen. So sorgen etwa Failover-Cluster von Windows Server selbst dafür, dass immer nur ein Knoten schreibend auf den Speicher zugreift und so keine Konflikte und korrupte Daten entstehen.

    Cluster Shared Volumes versus VMFS

    Anders verhält es sich in virtualisierten Umgebungen, wo mehrere Hosts unter Hyper-V oder ESXi parallel virtuelle Maschinen auf dem gleichen Target oder gar der gleichen LUN laufend aktualisieren. In diesem Fall ist der Einsatz eines entsprechenden Dateisystems notwendig.

    Microsoft bietet für diesen Zweck das Cluster Shared Volumes (CSV) an, VMware hingegen sein VMFS. Die Konzepte der beiden Technologien sind indes verschieden. Um Schreibkonflikte zwischen Hyper-V-Hosts zu vermeiden, müssen diese zu einem Cluster zusammengeschlossen sein, innerhalb dessen der Coordinator Node alleine für das Update der CSV-Metadaten zuständig ist.

    Cluster Shared Volumes eignen sich für mehrere Hosts, die zu einem Cluster verbunden sind.

    Dagegen verwaltet VMFS die Dateisperren durch entsprechende Einträge im Dateisystem, so dass eine Abstimmung zwischen den Hosts nicht erforderlich ist. Daher können unter vSphere 5.5 bis zu 128 einzelne ESXI-Server oder auch mehrere Cluster gleichzeitig ein iSCSI-Target nutzen.

    4 Kommentare

    Stefano De Niro sagt:
    17. Februar 2015 - 21:34

    Ich mag Ihre Artikel sehr Herr Sommergut. Allerdings sind sie mir manchmal gar kurz und gehen zu wenig in die Tiefe; allerdings ist es konträr wieder schön so kurz und prägnant zu sein.

    Konkret zu diesem Aritkel ist mir der gleichzeitige Zugriff der Clinets nicht ganz klar.

    Sehe ich es richtig, dass wenn ich ein Snyology DS habe, dass ich eben NICHT die Option 'mehrere Sitzung gleicheitig' aktivieren muss, falls ich Hyper-V mit CSV einsetze. Ich habe es mit dem Haken gemacht und bekomme immer Fehlermeldungen beim Cluster Validator.

    Mich würde noch ein Artikel über Hyper-V Host mit iSCSI mit 10GB NIC gemichst mit 1GB interessieren. Mir sind die Optimierungen bzw. Konzepte bei Microsoft oft nicht 100% klar (bsp. Jumbo Frame, Teaming Protolle, MIPIO etc.) Wohlvetstanden das ganze mit Server mit 4 oder mehreren NIC. Danke und Gruss aus Zürich.

    Bild von Wolfgang Sommergut
    18. Februar 2015 - 11:07

    Hallo Herr De Niro, danke für Ihr Feedback! Es ist nicht ganz einfach, eine Balance zu finden zwischen der Breite des Themenspektrums, dem Tiefgang einzelner Beiträge und den Erwartungen der verschiedenen Leser. Ich hoffe, dass der eine oder andere Beitrag trotzdem von Nutzen für Sie ist.

    Zu Ihrer Frage bezüglich Synology. Standardmäßig ist der Zugriff auf einen iSCSI-Initiator beschränkt. Bei einem Hyper-V-Cluster wird man normalerweise diese Beschränkung aufheben wollen, damit mehrere Hosts gleichzeitig Nutzdaten auf das Storage-System schreiben können. Die Verwaltung des Dateisystems obliegt bei Verwendung von CSV aber einzig dem Coordinator Node.

    Thomas Pfaff sagt:
    3. März 2015 - 22:19

    Also: Haben wir ein einfaches Cluster (2 Server physisch z.B.), greift ohnehin auf den Storage immer NUR EINER schreibend zu. Also ist das Freischalten von mehreren Sitzungen ungefährlich, da es eben keine parallelen Schreibzugriffe geben kann (Clustersoftware sorgt dafür)

    bei virtuellen Umgebungen schreiben aber VIRTUELLE Server (!) parallel auf den Storage, weil sie den Hyper-V-Host-Cluster "nicht sehen". Es mögen vielleicht Hyper-V-Hosts geclustert sein, was dann für deren Dateien ungefährlich wäre, weil deren Clustermanager das regelt. dafür wäre kein CSV-System nötig.
    Davon wissen aber die Virtuellen Server darauf nichts und schreiben fleißig parallel weiter. Also braucht man DAFÜR das CSV, um das Schlimmste zu verhindern!

    Thomas Pfaff sagt:
    3. März 2015 - 22:30

    zu Jumbo-Frames sei Folgendes gesagt: Das Storage-Netzwerk, der Switch und der Host müssen es unterstützen und auch aktiviert haben!
    Bei HP Procurve geht das im CLI auf einen eingerichteten VLAN 2 z.B.mit dem Befehl
    (config)#VLAN 2 JUMBO
    Das muss dann noch ge"saved" werden, damit der Switch sich das merkt. HÜP Procurves der aktuellen Version können dann MTUs bis 9220 verhackstücken. Wenn der Switch das NICHT unterstützt, muss es mindestens bei einem der anderen eteiligten deaktiviert werden. Lässt manden Switch quasi damit allein, führt das nach meiner Erfahrung zu einer instabilen Verbindung bis hin zum Abhängen der iSCSI-Verbindung. Das Storage ist dann einfach weg und kann nicht mehr verbunden werden. Das habe ich letzte Woche hinter mich gebracht..Große Schei...e!!Ansonsten ist das eine tolle Sache, es spart haufenweise Header-Overhead bei den TCP-Paketen.
    Teaming: Kann man machen, ist aber nicht Best Practise! Ich würde versuchen mit MPIO zu arbeiten. Das heißt bei Citrix und Dell "Multipathing". Falls Sie da mehr wissen möchten, scheiben Sie an meine Maildaresse trpfaff(at)yahoo.de Gruß T. Pfaff MSCA 2012 , MCITP 2008 Enterprise, Database Admin SQL-Server 2008