HA Cluster - Failover dauert sehr lange

[sany76]

Hallo,

ich hoffe ich platziere jetzt meine Fage im richtigen Unterforum.

Wir haben einen HA Cluster mit unseren beiden RS4017xs+ Knoten erstellt. Es gibt 3 Bonds pro Cluster.


Zusatzinfo:

Es gibt 2 Speicherpools

Raid 10 SSDs

Raid 5 HDDs



Konfig Node A + Node B identisch


Bond 1 (Active Standby Modus)

Managemet (Cluster)

LAN1 und Lan2 (jeweils 1 GBit)


Bond 2 (Balance XOR)

Heartbeat Direkt Verbindung ohne Switch

LAN 5 + LAN 6 (jeweils 10 Gbit / durch Bond 20 Gbit)


Bond 3 (LACP 802.3ad Dynamic Link)

LAN 7 +LAN 8 + LAN 9 + LAN 10 (jeweils 10 Gbit / durch Bond 20 Gbit)


Wir haben 2 Brocade 6650 (10Gbit Switch SFP+) die im Multichassis Trunk laufen Active-Active. Auf diesen beiden Switchen wurden jeweils 2 dynamische Lags konfiguriert. Pro Lag - 2 Ports.


Auf Switch 1 - LAG 1 kommen von Node A - Bond 3 - LAN 7 + LAN 8

Auf Switch 2 - LAG 1 kommen von Node A - Bond 3 - LAN 9 + LAN 10


Auf Switch 1 - LAG 2 kommen von Node B - Bond 3 - LAN 7 + LAN 8

Auf Switch 2 - LAG 2 kommen von Node B - Bond 3 - LAN 9 + LAN 10


Beide Speicherpools wurden mit NFS 4.1 auf ESX Servern gemountet.


Wir haben 2 VMs auf den Store migriert. Beide geöffnet in der VMWare Konsole.

Auf beiden läuft ein IO-Meter Test, der auf die Speicherpool Platten schreibt.

HDD + SSD


Wir haben dann diverse Failover Test durchgeführt:


Switch 1

LAG 1 (NodeA) - abgesteckt

IO Meter läuft weiter

LAG 1 (NodeA) auf Switch 2 vorhanden

Kein Failover da Node A auf Switch 2 vorhanden


LAG 1 (NodeA) - auf Switch 1 abgesteckt

LAG 1 (NodeA) auf Switch 2 auch abgesteckt

Failover wird eingeleitet, da nur noch LAG 2 - Node B auf Switch 1 und 2 vorhanden.

Somit wird Node B, der passive ist, zum aktiven Node.


Jetzt zu dem Problem

Die Dauer der Failovers dauerte fast 3 Minuten.

Erst dann fingen die IO Meter tests wieder an zu schreiben auf den VMs.


Für ein Simples System ist das zu verkraften, aber für ein ERP System oder Exchange ist das nicht sehr optimal.
Wir wollten es für unsern Datacenter ESX Betrieb nutzen. VMware Store für die VMs.

Klar kann man jetzt sagen, wann passiert sowas schon mal. Aber Dinge passieren nun mal leider.
Der Support von Synology hat schon die Logfiles inspiziert. Die konnten keinen Fehler finden.

Was haben wir falsch gemacht bzw. übersehen? Hat jemand ähnliche Ergebnisse erzielt oder erfahrungen gesammelt?

Danke schon mal

VG

 

[blurrrr]

Najo, das können andere aber schlimmer - glaub HP war es mal mit einer HA-Lösung, die lag dann bei schlappen 7 Minuten für den Failover ? Aber stimmt schon, 3 Minuten sind halt auch 3 Minuten zuviel... Ich habe nur einen Cluster aus kleinen RS laufen, da dauert es definitiv nicht so lange, sondern geht schon ziemlich zügig. Ist allerdings auch in produktiver Nutzung (mit laufenden VMs), von daher würde ich grade nur ungern testen (ist dazu auch noch innerhalb der Geschäftszeiten ??). Also Bond für die Heartbeat-Schnittstelle habe ich bisher noch nicht gesehen, ich persönlich hätte da vermutlich einfach direkt 40+G genommen, ggf. einfach via DAC-Kabel. Wäre vielleicht auch mal einen Versuch wert, den Heartbeat-Bond temporär durch eine einfache Schnittstelle (ohne Bond) zu ersetzen... Wird aber halt auch offiziell supported (sagt zumindestens das Whitepaper). Würde das halt einfach nur mal testen, um zu sehen, ob sich dann am Verhalten was ändert (Vertrauen ist gut, Kontrolle ist halt immer besser ??).

Im Whitepaper (Seite 9) steht auch noch ein bisschen zur Funktionsweise beim Failover: https://global.download.synology.co...lability/All/enu/Synology_SHA_White_Paper.pdf vielleicht hilft das ja schon ein wenig weiter

 

[sany76]

Hallo, danke für Dein Feedback.

Wow 7 min ...das wäre schon sehr fatal...eher untragbar für den Produktiveinsatz.

Ich werde das mal testen... Komme erst die nächste Tage wieder ins Büro.

Melde mich sobald nich ne Info dazu habe.

Schönen Abend

VG

 

[Syno-OS]

da schaue mal ins White Paper:
Ist von der Volumegröße abhängig...seite 13...
https://global.download.synology.co...lability/All/enu/Synology_SHA_White_Paper.pdf
PS: ach die haben es in der neuen version auf dem WhitePaper genommen, naja, zumindest hast du es mal gehört

 

[blurrrr]

Wundert mich ein wenig was da angegeben ist (grade die Tabelle mit dem Switchover vs. Failover - Seite 14), denn beim Switchover wird vorher noch geprüft, ob alles im Sync ist (halt eine ordnungsgemäße Übergabe), was bei einem reinen Failover ja überhaupt nicht mehr möglich ist, wenn da einfach ein Host wegknallt... Meinem Verständnis nach sollte da eine "normale" Übergabe schon länger dauern als ein Failover....

@sany76 Auch wenn wir hier im Syno-Forum sind und manch einer das vielleicht nicht gerne liest, aber... vielleicht auch einfach auf's falsche Pferd gesetzt... Grade wenn es um RZ und HA geht.... wäre Synology jetzt nicht unbedingt meine erste Wahl... Ich hab den primären Storage rein mit GlusterFS laufen (distributed replicated), wäre vielleicht auch mal einen Blick wert (wobei die Syno-Lösung natürlich die einfache Klicki-Bunti-Lösung ist). Dann läuft noch ein "kleiner" Syno-Cluster, der macht aber nix wichtiges und ansonsten nur noch primär Backup-Nodes (dafür taugen die Dinger ja dann doch noch *hust*) ?

 

[Syno-OS]

Wundert mich ein wenig was da angegeben ist (grade die Tabelle mit dem Switchover vs. Failover - Seite 14), denn beim Switchover wird vorher noch geprüft, ob alles im Sync ist (halt eine ordnungsgemäße Übergabe), was bei einem reinen Failover ja überhaupt nicht mehr möglich ist, wenn da einfach ein Host wegknallt... Meinem Verständnis nach sollte da eine "normale" Übergabe schon länger dauern als ein Failover....

Hä, was soll geprüft werden, ob es gesynct ist? Da ist ein falsches Verständnis des Clusters.
Es ist gleichzeitig auf beiden Servern, daher die HA Verbindung, die beide Geräte immer gleichzeitig 'abgleicht'/ schreibt, wie beim RAID1 auch, spiegeln ist ein falsches Bild in euren Köpfen!!, dass muss ich auch immer meinen Schülern sagen.
Bei Switchover/Failover müssen nur die Dienste gestartet werden, die nicht auf dem passiven Server laufen, daher der Name 'passiv'. Nur auf dem 'aktiven' Server laufen die Dienste. Dies dauert dann die 30-120 Sekunden, es hängt von den Menge der Daten ab... beim switchover was länger, da die Dienste auch noch gestoppt werden...das ist der Unterschied zwischen Switchover (=dienste müssen gestoppt werden) / Failover (=dienst einfach nicht da)

 

[blurrrr]

the active server will halt services in the beginning and then verify that data on the storage space and system configuration are synced with the passive server. After this process, the passive server starts to boot up all services. As a result of the transferring process users will be unable to manage the cluster and services will stop functioning for a brief period of time (depending on the number of services and storage space).

Ist also auch nicht ganz richtig (von wegen einfach nur rüberschwenken ? aber halt auch nur, wenn es vom aktiven Server ausgeht, was dann wohl auch bei einem manuellen Wechsel der Fall wäre), nur hab ich mich wohl verlesen was das konkrete "wann" angeht - hat man vom reinen "überfliegen" ?

Nutze Failover-Geschichten sowieso nur in Active/Active-Verbünden, weil mir alles andere schlichtweg zu lange dauert und sowas dann nicht mehr praktikabel ist - beim Backupstorage mag sowas gehen, aber in Sachen Virtualisierung und Co. sind Downtimes schlichtweg nicht zu gebrauchen).

 

[Syno-OS]

mag zwar alles so sein, aber wir rede hier um ein System ab 600 Euro und nicht wie bei dir für 10000+

 

[blurrrr]

Tschulli, ich weiss nicht wovon Du grade sprichst @Syno-OS , aber ich rede hier von:

Wir haben einen HA Cluster mit unseren beiden RS4017xs+ Knoten erstellt. Es gibt 3 Bonds pro Cluster.


Zusatzinfo:

Es gibt 2 Speicherpools

Raid 10 SSDs

Raid 5 HDDs

Und das ist mit 2x RS4017xs+ (eine davon dürfte so um die 5k liegen - ohne Extras) sicherlich kein System für 600€ (wenn es so wäre, hätte ich es vermutlich auch schon mehrfach) ?

 

[Syno-OS]

'ab' zwei DS220+ können aber schon im SHA laufen
das die RS4017 schon am Ende der Skala für Synology sind ist noch was anderes, aber für a-a Systeme immer noch absolute im Einstiegsbereich, SAS Ausrüstung gehört da ja zum guten Ton...10k+ ist da schnell verbraten

 

[blurrrr]

aber für a-a Systeme

Das ist aber kein Active-Active, sondern ein Active-Passive (daher auch der "passive" Teil) ? ?.

Passive Server: Under normal conditions, the passive server remains in standby mode and receives a steady stream of data replicated from the active server.

Ein besseres Beispiel für Active-Active wäre gg. ein SQL-Cluster (z.B. Galera). Fällt da ein Node aus (1/3), juckt das den Cluster überhaupt nicht (halt insgesamt dann etwas weniger performant) und man kann auch weiterhin auf die Datenbanken zugreifen

Das mit dem SAS... naja, auch nicht mehr so wie früher. Musste mal schauen, was sich so bei den SSDs (und den Formfaktoren so getan hat)... Ich sag einfach mal so:

1) https://echostreams.com/products/flachesan2n108m-un (in Bezug auf die Anzahl der Bays bei 2HE)
2) https://geizhals.de/kioxia-cm6-v-en...tb-kcm61vul6t40-a2321077.html?hloc=at&hloc=de (zwar nicht "passend", aber von den Werten her... Lesen 6900MB/s, Schreiben 4000MB/s, IOPS 4K lesen/schreiben 1400k/325k ... ich sag mal "ist schon ok", oder? Sowas wird auch nicht ewig so teuer bleiben...)

SAS-HDD? Als Cold-Storage vielleicht, oder halt wenn man auf "viel" Storage geht (Backup ?) Wobei die SAS-HDDs auch nie "billig" waren... wenn die SSDs da jetzt so langsam Fahrt aufnehmen, werden die HDDs eh nur noch durch "billig und langsam" trumpfen können. HDDs laufen bei mir auch nur noch in den Synos, bei den Backup-Geräten und auf einem kleinen Teststorage. Privat HDDs eh nur noch im NAS...

Von daher kann ich das Konzept des TO auch irgendwo nachvollziehen... Vermutlich SSDs für den eigentlich genutzten Storage und HDDs dann eben für die Snapshots, ggf. anderweitige Backups und "sonstiges" (oder einfach Dinge, die weniger Performance brauchen (wie bei meinem Teststorage)).

 

[sany76]

Guten Morgen,

ja das mit dem Klicki Bunti dachte ich mir auch, ähnlich wie Qnap halt. Es ist aber von der Grundidee gut. Das System mit Platten lag bei 30k. netto. Nackt hat eines 6250.- netto gekostet. Gekauft wurden zusätzlich 6 SSDs a 8 TB (Raid10) und 5 HDDs a 10 TB (Raid5), Garantieerweiterung und zusätzliche Netzwerkkarten.

Wir haben ein altes Open DSS System von Open-E. Das ist auch Active Passive, hat aber eine schnellere Reaktionszeit bei einem Failover. Hab gestern nochmal geschaut, das mit den 40 G wird so nicht klappen, sind ja "nur" 2 zusätzliche interfaces mit jeweils 10 Gbit.

 

[blurrrr]

6250€ netto für das nackte System (ohne RAM-Erweiterung, zusätzliche Netzwerkkarten und Rails)? Da hat dann jemand gut daran verdient... ?

Was den NIC-Platz angeht, hättest ja auch die Client-Bonds mit auf die onboard-NICs legen können, dann wäre noch Platz für eine Dualhead-10G-NIC und 1x 40G ? Aber sei's drum, is wie et is... Denke mal, einmal in die Nesseln gesetzt reicht dann auch... Vielleicht kann man ja schon wieder ein bisschen Budget ansammeln und dann läuft der Syno-Cluster irgendwann nur noch als Backup-Target (wie bei mir halt auch und das halt nicht ohne Grund ?).

Wie gesagt, GlusterFS könnte noch eine alternative sein (vor allem, wenn sowieso nur NFS benutzt wird), dann sollten die beiden Synos aber auch unabhängig von einander laufen. Schau es Dir ggf. einfach mal an, könnte auch noch ein Ausweg aus der aktuellen Situation sein. Die Synos einzeln auf die GlusterFS-Nodes mounten, über die GFS-Nodes dann die Bricks erstellen und verbinden (je nachdem, wie es sein sollt, ich nutze bevorzugt distributed+replicated) und dann ab dafür. Denke mal, dass ihr vermutlich noch irgendwo alte Server (oder rein zum testen auch alte Desktop-Rechner) rumliegen haben könntet, von daher - kleines Bastelprojekt für's Wochenende (Admins haben doch sowieso nix anderes zu tun, weiss doch jeder...) ??