Ich habe das iscsi-Ziel mithilfe von TargetCLI so eingerichtet, dass es einige Festplatten (Blockgeräte) und eine „TPG-Authentifizierung“ (eine eindeutige Use-ID und ein eindeutiges Passwort für alle Initiatoren) hat.
Wenn ein Initiator die Erkennung und Anmeldung durchführt, kann er auf alle diese Geräte (sda, sdb, sdc) zugreifen und sie formatieren und mounten. Wenn der zweite Initiator die Erkennung und Anmeldung durchführt, kann er alle diese Geräte ebenfalls verwenden (formatieren und mounten).
Problem: Wenn ein Laufwerk (z. B. sda) von mehr als einem Initiator verwendet wird, kommt es zu Konflikten im Laufwerk. Ich habe auch den „Demomodus“ (keine Authentifizierung) und die „ACL-Authentifizierung“ (Authentifizierung pro Initiator) ausprobiert, aber keine davon deaktiviert den Zugriff des zweiten Initiators.
Was ich will, ist: Wenn ein Laufwerk oder ein iscsi-Ziel von einem Initiator aufgerufen wird, sollte es den Zugriff des zweiten Initiators verweigern. Und wie kann ich das mit targetcli erreichen?
Antwort1
Klingt, als ob Sie tatsächlich eine Form vonClusterungkonfiguriert mitE/A-Fencingum zu verhindern, dass Festplatten gleichzeitig auf mehr als einem Knoten gemountet werden. Wenn Sie in einem Aktiv-Passiv-Failover-Szenario Speicher zwischen Hosts gemeinsam nutzen möchten, ist dies die richtige Vorgehensweise.
Grundsätzlich werden Ihre Festplatten über die Clustersoftware überwacht. Sie können sie auf einem Knoten des Clusters importieren und mounten (und dies wird auf anderen Knoten verhindert).
Die Gefahrensituation ist„Was passiert, wenn meine Heartbeat-Verbindungen ausfallen?“-- das ist woE/A-Fencingins Spiel. Dabei handelt es sich um die Konfiguration von Zäunen mitQuorum-Datenträger(die jedem Knoten im Cluster präsentiert werden). Im Falle eines Verbindungsverlusts im Cluster konkurrieren die Knoten des Clusters um die Kontrolle über die Quorum-Festplatten. Wer gewinnt, darf die Festplatten importieren. Alle anderen Knoten geraten in einen Kernel-Panic-Zustand. SieheSchießen Sie dem anderen Knoten in den Kopffür weitere Informationen und warum es keine Überreaktion ist!
Wie dem auch sei, was praktische Ratschläge angeht - ich habe einen Blick darauf geworfendieser Leitfadenund es scheint gut genug zu beschreiben, was Sie tun möchten, wenn Sie eine Red Hat-basierte Distribution verwenden. Wenn Sie SLES verwenden, wird Symantec SFHA mit der vxfenLösung geliefert. Mir fallen spontan keine Lösungen für Debian/Ubuntu ein.