1
Fujitsu Eternus SAN im Cluster: 1xSSD-SAN + 1xHDD-SAN möglich?
Guten Abend,
die Fujitsu Eternus SANs unterstützen den Clustermodus. Dabei werden die Daten zwischen den SANs in Echtzeit gespiegelt, um eine höhere Ausfallsicherheit zu erreichen (SANs in unterschiedlichen Brandabschnitten). Prinzipiell können dabei unterschiedliche Fujitsu-SANs gemischt werden (DX 200 S3/4/5, AF250, ...). Und prinzipiell können dabei auch SSD- und HDD-SANs gemischt werden.
Unklar ist mir dabei:
Könnte eine SSD-SAN als active-SAN definiert werden und eine langsamere (Backup-)HDD-SAN als passive-SAN? Und werden dann die Schreibvorgänge auf der langsameren HDD-SAN einfach nachgezogen, ohne Auswirkungen auf die Leistung der SSD-SAN? Oder wird die SSD-SAN ausgebremst, weil immer auf beide SANs zeitgleich geschrieben wird und immer auf die langsamere HDD-SAN gewartet wird, bis das "Schreibvorgang abgeschlossen" an den Client geschickt wird?
Auszüge aus dem Fujitsu-Whitepaper:
As long as the primary storage system is running, data is transferred from it to the secondary system via a synchronous replication function. The Storage Cluster Controller continuously checks the status of the primary storage. If a failure is detected, it runs the failover logic, and the primary storage information (e.g., LUN ID/WWN, or with iSCSI: IP addresses/port settings) is shifted over to the secondary storage in order to transparently identify the volume via the server I/O. Hence, operations run smoothly and ensure business continuity.
Storage Cluster configuration is based on remotely replicated TFOVs which can be freely configured and paired. Thus on one site both primary and secondary TFO groups and TFOVs can be configured – connected via linked-up (active) or passive (linked-down) CA ports, respectively.
Under normal conditions, VM1 and VM2 at site 1 and VM1 and VM2 at site 2 are connected to the respective ETERNUS AF/DX arrays located at the same site – this is called the active (primary) site. All data is synchronously replicated to the standby (secondary) site, while in this example ETERNUS B is secondary for VM1 and 2 and ETERNUS A is secondary for VM 3 and 4, respectively.
The ports on both sites have the same identity regarding WWPN. As the port on the primary site is in “link-up” status and the port on the secondary site is in “link-down” status, all server inputs/outputs are processed to the primary storage.
docs.ts.fujitsu.com/dl.aspx?id=241ef418-7d07-4d7a-bbe4-9f6773f0ea68
Hört sich so an, als könnte man frei einstellen, welcher Dateispeicher der aktive ist. Aber ob bei Schreibvorgängen immer gewartet wird, bis die Daten auf beiden SANs geschrieben wurden, kann ich aus dem Whitepaper leider nicht herauslesen.
Kennt sich jemand damit aus?
Mit freundlichen Grüße
Port5000
die Fujitsu Eternus SANs unterstützen den Clustermodus. Dabei werden die Daten zwischen den SANs in Echtzeit gespiegelt, um eine höhere Ausfallsicherheit zu erreichen (SANs in unterschiedlichen Brandabschnitten). Prinzipiell können dabei unterschiedliche Fujitsu-SANs gemischt werden (DX 200 S3/4/5, AF250, ...). Und prinzipiell können dabei auch SSD- und HDD-SANs gemischt werden.
Unklar ist mir dabei:
Könnte eine SSD-SAN als active-SAN definiert werden und eine langsamere (Backup-)HDD-SAN als passive-SAN? Und werden dann die Schreibvorgänge auf der langsameren HDD-SAN einfach nachgezogen, ohne Auswirkungen auf die Leistung der SSD-SAN? Oder wird die SSD-SAN ausgebremst, weil immer auf beide SANs zeitgleich geschrieben wird und immer auf die langsamere HDD-SAN gewartet wird, bis das "Schreibvorgang abgeschlossen" an den Client geschickt wird?
Auszüge aus dem Fujitsu-Whitepaper:
As long as the primary storage system is running, data is transferred from it to the secondary system via a synchronous replication function. The Storage Cluster Controller continuously checks the status of the primary storage. If a failure is detected, it runs the failover logic, and the primary storage information (e.g., LUN ID/WWN, or with iSCSI: IP addresses/port settings) is shifted over to the secondary storage in order to transparently identify the volume via the server I/O. Hence, operations run smoothly and ensure business continuity.
Storage Cluster configuration is based on remotely replicated TFOVs which can be freely configured and paired. Thus on one site both primary and secondary TFO groups and TFOVs can be configured – connected via linked-up (active) or passive (linked-down) CA ports, respectively.
Under normal conditions, VM1 and VM2 at site 1 and VM1 and VM2 at site 2 are connected to the respective ETERNUS AF/DX arrays located at the same site – this is called the active (primary) site. All data is synchronously replicated to the standby (secondary) site, while in this example ETERNUS B is secondary for VM1 and 2 and ETERNUS A is secondary for VM 3 and 4, respectively.
The ports on both sites have the same identity regarding WWPN. As the port on the primary site is in “link-up” status and the port on the secondary site is in “link-down” status, all server inputs/outputs are processed to the primary storage.
docs.ts.fujitsu.com/dl.aspx?id=241ef418-7d07-4d7a-bbe4-9f6773f0ea68
Hört sich so an, als könnte man frei einstellen, welcher Dateispeicher der aktive ist. Aber ob bei Schreibvorgängen immer gewartet wird, bis die Daten auf beiden SANs geschrieben wurden, kann ich aus dem Whitepaper leider nicht herauslesen.
Kennt sich jemand damit aus?
Mit freundlichen Grüße
Port5000
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1211737278
Url: https://administrator.de/forum/fujitsu-eternus-san-im-cluster-1xssd-san-1xhdd-san-moeglich-1211737278.html
Ausgedruckt am: 21.12.2024 um 12:12 Uhr
1 Kommentar
Mit Fujitsu kenne ich mich nicht aus, offensichtlich sonst auch nicht so viele. Wir haben 2 NetApp mit einer Spiegelung mit Interval, das wird hier vermutlich auch so sein. Nur auf das aktive Gerät wird geschrieben, nur hier gelesen, daher hat das bei uns einen SSD Cache. Das aktive Gerät ermittelt die geänderten Blöcke und nur die werden alle 10 Minuten synchronisiert, der Slave hat keinen Cache (wozu auch). Solange am Master keine Dauerlast anliegt die die Geschwindigkeit des Slaves übersteigt wird die Synchronisation immer irgendwann vollständig sein. Das sollte also auch mit SSD only als Master und HDD only als Slave gehen wenn auf dem Slave nicht über lange Zeit sehr schnell sehr viele Daten geschrieben werden so das der Slave das nicht mehr packt.
