High Availability Cluster: Fragen, Anregungen, Know-How und Erfahrungsaustausch

[MichelS]

Ich kontaktiere den Support.
Btw, gibt es eine möglichkeit den HA zu deinstallieren(vielleicht Kommandozeile)? In älteren Versionen war es ja eine Art App.

 

[QBert]

SHA und USV?

Hi,

ich bin gerade in der Planungsphase eines HA-Clusters und grübele über die sinnvolle Konfiguration von USVen für die beiden Knoten (RS3614RPXS).
In meinem Fall werden beide Knoten im selben Gebäude stehen, zwar in getrennten Brandabschnitten aber eben grundsätzlich an derselben Stromversorgung.

Hat jemand Erfahrung, wie der HA-Cluster bzw. die einzelnen Knoten auf das Restkapazität-erreicht-Signal der USVen reagieren?
Wenn der Passiv-Knoten (Host-B) zuerst runterfährt ist das wohl relativ unkritisch; der Aktiv-Knoten sieht, dass er allein ist und fährt halt ohne Switchover runter.
Wenn aber die USV am Aktiv-Server (Host-A) zuerst "leer" ist und deshalb ein Switchover eingeleitet wurde (automatisch?) bzw. ein Failover, weil Host-A plötzlich "weg" ist, wass passiert wenn dann innerhalb der Switchover-Zeit auch die USV an Host-B einen Shutdown signalisiert?
Kann SHA damit umgehen oder bleibt als Absicherung nur, die USVen so zu dimensionieren und zu konfigurieren, dass sie sicher genug Kapazität haben, einen begonnenen Switchover zuende zu bringen?

Und wie stellt man sicher, dass der zuletzt aktive Knoten als erster wieder hochfährt, wenn der Strom wieder da ist? Oder ist das unkritisch, d.h. bleibt ein passiv heruntergefahrener Knoten auch nach dem Neustart erstmal passiv?

Danke für eure Tipps!

 

[lordbeule]

Hi QBert,

ich würde es an deiner Stelle gar nicht so weit kommen lassen, dass beide USV´s leerlaufen. Wenn es absehbar ist das die Stromversorgung deiner USV nicht reicht um den Stromausfall zu überbücken, würde ich den HA-Cluster gezielt runterfahren, dann kann auch nichts passieren. Ansonsten wäre mir das Risiko zu hoch das dein beschriebenes Szenario eintrifft. So ist normalerweise auch die Vorgehensweise bei einem Stromausfall.

 

[QBert]

Ja klar, wenn ich könnte, würde ich es auch nie soweit kommen lassen.
Die Geräte stehen allerdings eine Autostunde entfernt in einem Büro, das von technischen Laien bevölkert ist. Selbst mit telefonischer Anleitung könnte da keiner den Cluster herunterfahren, und wenn der Stromausfall ausserhalb der Geschäftszeiten auftritt ist das ja sowieso keine Option. Bei einem strassen- oder stadtteilweiten Stromausfall ist auch davon auszugehen, dass keine Fernwartung per Internet möglich ist.
Dazu kommt, dass man bei Stromausfällen üblicherweise nicht weiss, wie lange sie dauern, und genau deswegen können die Smart-UPS ja ihre verbleibende Kapazität an Server o.ä. signalisieren. Die Frage wäre halt, wie der SHA-Cluster mit diesen Signalen umgeht.

 

[dil88]

Ich habe keine Erfahrung mit SHA, aber in meinen Augen müsste das Signal der USV in jedem Fall den gesamten Cluster 'runterfahren. Nur das macht m.E. Sinn.

 

[benoga]

Ich habe keine Erfahrung mit SHA, aber in meinen Augen müsste das Signal der USV in jedem Fall den gesamten Cluster 'runterfahren. Nur das macht m.E. Sinn.

Ich habe es mit apcupsd (APC via USB auf Router/Firewall) realisiert, damit werden beide gleichzeitig heruntergefahren.

 

[QBert]

Ich habe es mit apcupsd (APC via USB auf Router/Firewall) realisiert, damit werden beide gleichzeitig heruntergefahren.

Weil das aus deinem Post nicht eindeutig hervorgeht: du hast das auch praktisch ausgetestet?
Und wie sieht das mit dem Wiederhochfahren aus, muss dabei etwas beachtet werden? U.U. ist ja nicht zweifelsfrei klar, welcher Knoten zuletzt der Aktive war.

Nachtrag:
Hast du auch tatsächlich zwei USVen im Einsatz? "USB am Router" hört sich ja eher nach einer an!?

Nachtrag 2:
Solange der Shutdown geordnet ablief ist das Hochfahren wohl unkritisch:
"Power on both servers within ten minutes of each other."
https://www.synology.com/en-global/knowledgebase/tutorials/585#t6

 

[benoga]

Meine beiden USV's sind via USB auf den Router verbunden, welcher dann die Shutdown Signale via Netzwerk weiter gibt. Der apcupsd Service auf dem Router läuft 2 mal (auf 2 verschiedenen Ports, für jede USV ein Port).
Auf dem Cluster läuft der apcupsd als Client und "überwacht" beide Ports. Wird eine der beiden Akkus in den USV's leer, werden beide heruntergefahren.

Bei DSM 5.0 war es dazumal so, dass nur der Aktive Server heruntergefahren wurde als der Akku der an dem Aktiven Server angeschlossenen USV leer wurde. Danach gab es einen Switchover und der passive wurde zum aktiven und wurde dann heruntergefahren, wenn dessen Akku leer war und das Signal zum Shutdown gab. Dies habe ich dazumal Synology gemeldet, bekam aber nie eine Lösung für das Problem, daher habe ich mich für die apcupsd Lösung entschieden. Wie es mit DSM 5.2 aussieht weiss ich nicht.

Hoffe ich konnte das jetzt bisschen klarer schreiben.

Welcher Knoten zuletzt aktiv war spielt ja somit keine Rolle, da beide den Shutdown gleichzeitig erhalten haben. (Alle Daten sind auf beiden aktuell).
Beim hochfahren entscheidet die Synology Software, welcher Aktiv und welcher Passiv ist. (Split Brain hatte ich noch nie).

 

[Fuppes78]

Hallo Zusammen,

ich hab vor einen HA Cluster in einer ähnlichen Umgebung aufzubauen wie lordbeule!
Ich hab hier 3x ESXi Hosts die auf 4 iSCSI Targets an einer DS1813+ zugreifen. Die hat 4x 4TB (Raid5) und 4x 1TB (Raid5). Eine baugleiche DS mit gleicher DSM Version und gleichen Platten steht bereit.
Jetzt habe ich eure super Erfahrungssammlung hier gelesen und mir kommen noch ein paar Fragen.

Wie lange sind die Targets auf der Aktiven DS nicht erreichbar? Wenn der Heart-Beat die Daten im Block Modus überträgt, schaffe der Cluster das an einem Wochenende?
Kann ich die VMs schon wieder auf die Targets loslassen, auch wenn der Cluster noch nicht fertig ist? Die täglichen Änderungen umfassen vielleicht 20GB - 50GB. Wenn der Sync immer wieder neu anfängt, wird der Cluster dann überhaupt fertig?
Ich hoffe ihr habt schon Erfahrungen in dieser Richtung und könnt mir helfen...

 

[frontliner]

Hi, auch ich plane einen Cluster aus 2 Rackstation 2414+.
Die Haupt-RS ist zur Zeit mit 3 Netzen verbunden.
LAN1: Abteilung1
LAN2: Abteilung2
LAN3: Backup-LAN

Wenn ich den Cluster nun konfiguriere, kann ich beim Einrichten gleich die Vorhanden IP von LAN1 (Abteilung1 ) nehmen?
Die anderen 2 LAN-Adressen kann ich sicher erst nach dem erstellen anpassen, es kann also vorkommen das die RS über LAN2(Abteilung2) und LAN3 (Backup-LAN) erst nach dem Sync erreichbar ist?
Oder kann ich das auch während der Dateisynchronisierung?
Kann einer sagen wie lang der Ausfall aus den einzelnen Netzen beim einrichten sein wird?


Danke

 

[Bratwurstbraeter]

Hallo,

ich habe mal eine Frage zum HA Status im Fall von z.B. Update des DSM.

Erst mal zur Konfiguration:

Wir haben zwei RS3614xs als Cluster konfiguriert.
Über die Cluster IP ist eine ISCSI Lun an die ESX Farm verbunden.

Ich habe heute ein DSM Update durchgeführt und bin davon ausgegangen dass zuerst der passive Server geupdatet wird, danach der Clusterschwenk erfolgt und dann der ehemals aktive Server sein Update erhält.
Leider hat das nicht funktioniert, so dass die LUN ca. 7 Minuten off war. Scheinbar wurde zuerst der aktive geupdatet, die Cluster IP war nicht mehr erreichbar.
Ist das ein normales verhalten von Synology HA Clustern?

Gruß

 

[frontliner]

Hallo,

ich habe mal eine Frage zum HA Status im Fall von z.B. Update des DSM.

Erst mal zur Konfiguration:

Wir haben zwei RS3614xs als Cluster konfiguriert.
Über die Cluster IP ist eine ISCSI Lun an die ESX Farm verbunden.

Ich habe heute ein DSM Update durchgeführt und bin davon ausgegangen dass zuerst der passive Server geupdatet wird, danach der Clusterschwenk erfolgt und dann der ehemals aktive Server sein Update erhält.
Leider hat das nicht funktioniert, so dass die LUN ca. 7 Minuten off war. Scheinbar wurde zuerst der aktive geupdatet, die Cluster IP war nicht mehr erreichbar.
Ist das ein normales verhalten von Synology HA Clustern?

Gruß

Das scheint leider der Normalzustand bei einem Synology-Cluster zu sein.
Machen unserer Synology-Cluster leider auch.
Leider sehr nervig und meiner Meinung nach nicht so ganz im Sinne es eines Clusters.

 

[dil88]

Synology hat meiner Erinnerung nach die Downtime in den letzten Updates erheblich verkürzt, sie aber nicht komplett eleminiert. M.E. ist das ein Thema, das man an Synology herantragen sollte, die lesen hier nicht mit.

 

[bazzzer]

Hallo zusammen,

nachdem dieser Thread schon eine gewisse Lebenszeit auf dem Buckel hat wollte ich mal fragen, ob jemand der Mitstreiter hier praktische (aktuelle) Erfahrung im Betrieb eines Synology HA (z.B. mit 2x RS3617xs+ o.ä. mit 10GBit Richtung Server und 10GBit untereinander) in Verbindung mit VMWare ESX, XenServer o.ä. hat (iSCSI vs. NFS Datastores)?

Also Virtualisierung mit HA Storage Backend.

Läuft das bei jemandem? Wie ist die Gesamtperformance? Wie der Eindruck?

Danke!

 

[lordbeule]

Hallo bazzzer

Ich kann dir nur sagen lass die Finger davon. Ich bin gerade dabei die HA Cluster Lösung von Synology wieder aufzulösen. Wir haben das jetzt länger im Einsatz gehabt, aber letztendlich ist das HA-Cluster-System von Synology nicht ausgereift.

Folgende Punkte sind nicht ausgereift:

DSM Update: ist immer mit einer Downtime verbunden

Defekte Festplatte auf der Passiven Site: Auf der Passiven Site des Clusters kann meine keine Tests der Festplatten, oder neue Hotspare Platte einbinden, falls eine Festplatte Ausgetauscht werden muss. Dieses ist nur möglich wenn man ein Schwenk der Sites macht, was wiederum mit einer Downtime verbunden ist.

SMART-Test von Festplatten auf der Passiven Site ist nicht möglich.

Cluster-Site-Schwenk: egal ob geplant oder ungeplant, der Schwenk und die damit zusammenhängende Downtime dauert zu lange. Der geplant Schwenk dauert sogar länger als der ungeplante.

Zudem kommt es häufiger vor das der Ressourcen-Monitor Dienst abschmiert, um den wieder in Gang zu bringen, ist ein Neustart der Synology nötig, wieder mit einer Downtime verbunden.

All diese Dinge sprechen nicht für einen HA-Cluster von Synology, unter einen HA-Cluster verstehe ich etwas anderes. Darum lösen wir die Cluster gerade wieder auf, und setzten die Synologys jetzt wieder einzeln ein.

Noch als Info für dich, wir haben den Cluster (2x 2614xs+) als NFS-Storages für VMs von Vmware.
Das Storages ist per 10GB Verbindung an unsere ESX-Hosts angebunden
Die Heartbeatverbindung ist auch per 10GB angebunden.

Also NFS Datastores kann ich das nicht empfehlen. Solltest du das trotzdem einsetzten wollen. Und Vmware VMs darauf laufen lassen, nimm die „vmxnet3 Treiber“ uns setzte bei Linux Systemen den „disk timeout“ auf Minimum 10 Minuten, damit kannst du eventuell ein Schwenk überleben ohne das in den VMs alle Disks auf read only gesetzt werden.

 

[bazzzer]

Hallo lordbeule,

vielen, vielen Dank für die ausführlichen Antworten. Generell möchte ich beipflichten, dass der Begriff "HA Cluster" in diesem Zusammenhang offensichtlich fehlleitet, man müsste also Downtime einplanen. Ich weiß allerdings auch, was alternative Zero-Downtime SAN Lösungen kosten, da sind wir schnell bei dem zehn- bis zwanzigfachen.

In unserer Situation wäre eine Downtime kein generelles Problem (Softwareupdates, geplante Schwenks, etc.), wir fahren derzeit ca. 60 VMs, die nicht 100% up sein müssten.

Mir geht es primär eher darum, den Ausfall einer Hardware kompensieren zu können. Was werdet ihr da jetzt mit euren beiden Synos machen?

Wie ist denn generell die Performance in deinem Setup?

VG!

 

[lordbeule]

Hallo bazzzer

Na klar sind richtige Cluster Systeme teuer, nur finde ich wenn man damit wirbt, sollte man auch erwarten können das sich das System so verhält.

Die Performance ist bei uns generell gut, ist aber sehr stark von den eingebauten Festplatten Abhängig, und natürlich von den VMs die darauf laufen sollen. Es gibt halt Server die viel IO-Last erzeugen und andere halt nicht.

Aber auch hier habe ich einen kleinen Tipp. Wenn ihr VMs darauf laufen lassen wollt, so wie du es beschriebst wollt ihr das ja, last die Finger von SATA Platten plus SSDs als SSD-Cache.

Wir haben Testweise 6 x2TB SATA Festplatten im Raid 6 mit zwei zusätzlichen 500GB SSD im Raid 1 als SSD-Cache im Einsatz gehabt, und nur VMs darauf laufen lassen. Diese Szenario hat leider keinen Performance gewinn gebracht, eher im Gegen teil, wenn VMs Repliziert, oder geklont wurden, gab es Aussetzer auf dem Storages. Teilweise war es so schlimm dass die ESXi Hosts die Verbindung zum Storages verloren haben. Du kannst ja vorstellen dass das nicht so gut ist.

Also meine Empfehlung ist, wenn du die max. Performance herausholen möchtest, bestücke deinen Cluster nur mit SSDs, SSD-Cache ist bei Synology keine Option wenn du VMs darauf laufen lassen möchtest.

An welche Synos hatte ihr den eigentlich gedacht?

VG!

 

[bazzzer]

Hallo bazzzer

Na klar sind richtige Cluster Systeme teuer, nur finde ich wenn man damit wirbt, sollte man auch erwarten können das sich das System so verhält.

Die Performance ist bei uns generell gut, ist aber sehr stark von den eingebauten Festplatten Abhängig, und natürlich von den VMs die darauf laufen sollen. Es gibt halt Server die viel IO-Last erzeugen und andere halt nicht.

Aber auch hier habe ich einen kleinen Tipp. Wenn ihr VMs darauf laufen lassen wollt, so wie du es beschriebst wollt ihr das ja, last die Finger von SATA Platten plus SSDs als SSD-Cache.

Wir haben Testweise 6 x2TB SATA Festplatten im Raid 6 mit zwei zusätzlichen 500GB SSD im Raid 1 als SSD-Cache im Einsatz gehabt, und nur VMs darauf laufen lassen. Diese Szenario hat leider keinen Performance gewinn gebracht, eher im Gegen teil, wenn VMs Repliziert, oder geklont wurden, gab es Aussetzer auf dem Storages. Teilweise war es so schlimm dass die ESXi Hosts die Verbindung zum Storages verloren haben. Du kannst ja vorstellen dass das nicht so gut ist.

Also meine Empfehlung ist, wenn du die max. Performance herausholen möchtest, bestücke deinen Cluster nur mit SSDs, SSD-Cache ist bei Synology keine Option wenn du VMs darauf laufen lassen möchtest.

An welche Synos hatte ihr den eigentlich gedacht?

VG!

Hi!

Wir haben seit Jahren wirklich gute Erfahrungen mit Desktop-Class-SSDs auch in Servern und NAS-Systemen gemacht (Anfangs Intel 330, jetzt seit ein paar Jahren Samsung 8x0 Pro) und ich würde somit auch bei diesem Setup SSD-Only gehen (heißt: 850 Pro).

Angedacht waren Tests auf Basis auf Basis von 2x DS2015xs (u.a. da wir eines der Geräte bereits haben, an einem 10GB Switch), später - falls erfolgreich - dann vermutlich 2x RS3716xs+.

Aber Frage: wenn ihr jetzt euer HA-Setup auflöst, wie werdet ihr / wollt ihr einen Hardwareausfall eines Systems kompensieren? Wie spiegelt ihr eure Daten auf das zweite?

VG!

 

[dil88]

@bazzzer: Bitte im Sinne des Leseflusses auf Vollzitate verzichten - vor allem dann, wenn Du direkt antwortest. Danke!

 

[lordbeule]

Hallo bazzzer,

Wir haben verschiedene Tools im Einsatz um für unsere Ansprüche einen Ausfall zu kompensieren.
1) Es werden täglich Backups von allen VMs gemacht die wir im Einsatz haben
2) Es werden zudem täglich Replikationen von jeder VM erstellt, die bei Bedarf sofort eingeschaltet werden können
3) Außerdem sichern wir Stündlich innerhalb der VMs per „btrfs“ Snapshots die Daten.

Dafür haben wir insgesamt drei Synos im Einsatz, die zwei aus dem aufgelösten Cluster, die Synology ist für die Produktiven Vms und die zweite ist das Sicherung Ziel für die Replikationen. Die dritte Synology ist für die Backups. Die gab es aber auch schon vorher mit dem HA-Cluster.
Als Tool für die Replikationen und Backups setzten wir vRanger von Dell ein.

Ich hoffe ich konnte dir jetzt alle Fragen beantworten.

VG