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

[daft075]

Hi

Ein dummer Denkfehler.

Jetzt geht’s.

Danke

 

[Herbie]

Hallo an alle,

leider bekomme ich schon beim Versuch der Erstellung des HA-Clusters folgende Fehlermeldung:




Ich habe

2 exakte DS1815+ (gleicher Speicher, gleiche Platten)

Server 1:
Lan 1: feste IP und direkte Verbindung zum Server 2
Lan 2: feste IP

Server 2:
Lan 1: feste IP direkt mit Server 1 verbunden
Lan 2: feste Ip

übers Netzwerk verbunden sind beide über den gleichen Switch

in den Netzwerkeinstellungen wird auch angezeigt, dass alle belegten LAN-Ports verbunden sind.

ich kann beide Server über Webbrowser erreichen.


was mache ich falsch?


danke und Grüße


Herbie

 

[Matthieu]

Hi,
wie lauten denn die IP-Adressen der 4 Interfaces?

MfG Matthieu

 

[Herbie]

Hallo Matthieu.

Server 1
Lan 1: 10.10.10.200
Lan 2: 10.10.10.201

Server 2:
Lan 1: 10.10.10.202
Lan 2: 10.10.10.203

Lan1 jeweils direkt ohne Switch verbunden (auch schon verschiedene Kabel getestet) - im DSM wird auch verbunden angezeigt.

Lan2 jeweils über den gleichen Switch verbunden und auch erreichbar.


Ich habe ausserdem auch schon alles möglich andere getestet, alle Dienste an, Firewall aus, usw.

Ich komme einfach nicht drauf, was es sein könnte.

Danke und Grüße

Herbie

 

[Matthieu]

Die beiden direkt verbundenen Schnittstellen dürfen nicht im gleichen Subnetz sein wie die "normalen" Schnittstellen. Deine IP-Config ist also falsch.
Siehe auch: https://help.synology.com/dsm/?section=DSM&version=5.1&link=HAManager/wizard.html

MfG Matthieu

 

[Herbie]

Hallo Matthieu,

erstmal Danke für deine Geduld und deine Bemühungen.

Ich habe auch schon verschiedene Netzwerkeinstellungen versucht, zuletzt folgende


Server 01

sowie

Server 02

Aber egal was ich mache, ich bekomme einfach keine Netzwerkverbindung :-(

Es erscheint immer sofort der vorweg schon genannte Fehler.

Hast du vielleicht noch eine Idee?

Viele Grüße

Herbie

 

[Matthieu]

Stelle mal bitte beide LAN 1 (Direktverbindung) auf DHCP und nutze die Adressen für die HA-Einrichtung die dir dann angezeigt wird.

MfG Matthieu

 

[Herbie]

Hallo Matthieu,

das hat leider auch nicht funktioniert. Ich habe mittlerweile auch beide NAS auf die aktuelle DSM upgedated. Nachwievor das gleiche Problem :-( :-(

Der aktive Server kann sich nicht auf den passiven Server verbinden.

Ich bin ratlos...

Viele Grüße und schöen Feiertag


Herbie

 

[Herbie]

Hallo Matthieu,

nachdem ich den passiven Server komplett zurück gesetzt habe, bekam ich dann endlich die Verbindung, warum auch immer...


Jetzt läuft grad die Synchronisierung der beiden Server und ich hoffe, dass diese fehlerfrei durchläuft und danach der Cluster läuft.

Viele Grüße


Herbie

 

[Herbie]

Hallo Matthieu,

ich nochmal ;-)

Ich habe noch eine Verständnisfrage und bevor ich lange rumteste, frage ich mal dich (oder auch alle anderen Leser) hier:

Der HA-Cluster hat ja eine eigene IP und eigenen Namen. Was bedeutet dies nun für die Laufwerksverbindungen meiner Windows Laptops (2 Stk.)?

Oder anders gefragt:
Liege ich richtig mit der Annahme, dass, wenn ich nun die Laufwerksverbindungen auf den HA-Clustername ändere, sich an den Windows Laptops im Falle eines Ausfalles eines der beiden Cluster-Server eigentlich nichts ändern würde . Ich gehe davon aus, dass, wenn ein Server aus dem Cluster ausfallen würde, die Laufwerksverbindungen immer noch funktionieren würden. Sehe ich das richtig?


Viele Grüße

Herbie

 

[Matthieu]

Genau das sollte passieren. Die Umschaltzeit liegt dennoch im Sekundenbereich - laufende Dateitransfers könnten also abbrechen. Wichtig ist es eben, die Cluster-IP zu nutzen.

MfG Matthieu

 

[lordbeule]

Moin,
ich bin gerade auf diese Thread gestoßen, und bin doch sehr erfreut dass sich doch einige mit dem HA-Cluster beschäftigen. Ich würde auch gerne mal meine Erkenntnisse zum Besten geben und eventuell habt ihr einige Antworten für mich. Also ich betreibe zwei RS3614xs+ Synology´s (voll ausgebaut im Raid6 mit einer Hotspare Platte) im HA-Cluster als Storages für zwei ESXi Hosts, beide sind untereinander und im Netzwerk zu den ESXi Hosts (am Switch) mit 10GB angeschlossen. Plus das ich noch zwei weitere separate Netze an die Synology´s angeschlossen haben, jeweils mit 1GB (als Wartungs-Netz und externes Netzwerk). Das funktioniert auch alles wunderbar. Ich habe bloß das große Problem, und das wundert mich dass es hier noch keinem aufgefallen ist. Das wenn man ein Update auf der Synology einspielt, der HA-Cluster eigentlich gar kein HA-Cluster mehr ist. Wie komme ich zu der Aussage, es läuft folgendermaßen beim Update ab, erst bekommt der Passive das Update und wird neu gestartet dann bekommt der Aktive sein Update und wir neu gestartet, aber dazwischen sind beide für kurze Zeit offline (so ca. 40 Sekunden)um sich zu. Das heißt für mich das alle VM´s die ich auf dem Storages betreibe ihre Verbindung zum Storages (zur Synology) verlieren, und was das heißt könnt ihr euch danken. Ich finde das ist ein absolutes No-Go für einen HA-Cluster. Wenn einer von euch eine Möglichkeit kennt das zu umgehen, wäre ich dafür sehr dankbar. Von Seiten Synology habe ich nur erfahren, das müsse so sein das wäre das Design. Es gibt auch diverse Probleme beim Ausfall einer Platte im Passiven Server des Clusters, es springt zwar die Hostspare Platte ein, aber nach dem Austausch der Defekten Platte kann man diese nicht wieder als Hotspare einbinden, das geht laut Synology nur mit dem Aktiven Server, das würde heißen man muss einen Serverschwenk machen, und das geht halt nicht ohne das der Cluster mal für kurze Zeit nicht erreichbar ist. Auch ein SMART-Test von den Festplatten im Passiven Server ist nicht möglich. Da man keinen Zugriff auf diese Platten hat.
Gruß
Lordbeule

 

[Matthieu]

Updates - das betrifft in meinen Augen HA-Cluster genau so wie produktive Einzelmaschinen - sollten stets nur eingespielt werden, wenn keiner auf dem System arbeitet und eine Downtime akzeptabel ist.
Das Thema SMART ist dagegen nicht so toll.

MfG Matthieu

 

[iLion]

Nun ja, ein HA-Cluster wird vermutlich immer in Umgebungen eingesetzt, die einen hohen Verfügbarkeitsbedarf haben und damit "immer" in Verwendung sind. So zumindest ist es bei den von mir betreuten HA-Clustern. Was ich schwieriger finde, dass auch Updates, die auf Single-Systemen keinen Neustart erfordern, in HA-Clustern bisher immer den Neustart beider Systeme zur Folge hatten. Und damit ist dann die Cluster-IP für eine bestimmte Zeit halt nicht erreichbar. Der komplette Vorgang dauert auch viel länger als bei den Single-Systemen. Da bin ich bei den letzten DSM 5.1 Updates mit weniger als 1 Minute ausgekommen. Der Vorgang auf einem der HA-Cluster dauert dagegen regelmässig zwischen 10-20 Minuten.

 

[MichelS]

Nach dem Update auf 5.2 hat sich der HA verabschiedet. Ich habe jetzt zwei Standalone Geräte(3413xs+) die sich nicht verbinden lassen, obwohl per SSH die Heartbeat Adresse pingbar ist. Meldung:
"The passive server cannot be detected using this interface."
Ich habe Jumbo Frames de-/aktiviert. Die MTU auf 1500/9000 gestellt.

Log vom passivem Knoten:
May 27 17:35:07 PassivKnoten ha.cgi: ha.cc:2108 [HA-DBG] change mtu
May 27 17:35:07 PassivKnoten synonetd: net_route_table_edit.c:72 eth1 ip route del failed, instead of route
May 27 17:35:08 PassivKnoten [ 5298.179827] init: winbindd main process (18083) killed by TERM signal
May 27 17:35:08 PassivKnoten [ 5298.187451] init: smbd main process (18090) killed by TERM signal
May 27 17:35:11 PassivKnoten synonetd: net_route_table_edit.c:58 eth1 ip route del failed, instead of route
May 27 17:35:11 PassivKnoten synonetd: net_route_table_edit.c:64 eth1 ip route add failed, might be the same subnet, instead of route
May 27 17:36:07 PassivKnoten synoha: ha.cc:1096 [HA-DBG] restore mtu
May 27 17:36:08 PassivKnoten synonetd: net_route_table_edit.c:72 eth1 ip route del failed, instead of route
May 27 17:36:08 PassivKnoten ha.cgi: ha.cc:1096 [HA-DBG] restore mtu
May 27 17:36:08 PassivKnoten ha.cgi: ha.cc:1110 Can't read origin mtu
May 27 17:36:08 PassivKnoten ha.cgi: ha.cc:5391 Failed to restore attr
May 27 17:36:08 PassivKnoten ha.cgi: ha.cc:5406 Reset env script return error vaule:
May 27 17:36:08 PassivKnoten ha.cgi: ha_cmd.cc:327 Failed to reset check heartbeat env
May 27 17:36:09 PassivKnoten [ 5358.386562] init: winbindd main process (24004) killed by TERM signal
May 27 17:36:09 PassivKnoten [ 5358.393618] init: smbd main process (24120) killed by TERM signal
May 27 17:36:11 PassivKnoten synonetd: net_route_table_edit.c:58 eth1 ip route del failed, instead of route
May 27 17:36:11 PassivKnoten synonetd: net_route_table_edit.c:64 eth1 ip route add failed, might be the same subnet, instead of route


vom aktivem:
May 27 17:35:10 AktivKnoten ha.cgi: ha.cc:2108 [HA-DBG] change mtu
May 27 17:35:12 AktivKnoten [10501.662343] init: smbd main process (15338) killed by TERM signal
May 27 17:35:12 AktivKnoten [10501.669622] init: winbindd main process (15315) killed by TERM signal
May 27 17:35:14 AktivKnoten synonetd: net_route_table_edit.c:58 eth1 ip route del failed, instead of route
May 27 17:35:15 AktivKnoten [10504.972193] init: winbindd main process (21448) killed by TERM signal
May 27 17:36:11 AktivKnoten synoha: ha.cc:1096 [HA-DBG] restore mtu
May 27 17:36:11 AktivKnoten synoha: [HeartbeatCheck] /bin/ping 169.254.1.2 -s 9000 -I eth1 -c 3 -w 60
May 27 17:36:11 AktivKnoten ha.cgi: ha.cc:5557 Check script execute return: "2
May 27 17:36:11 AktivKnoten ha.cgi: ha.cc:5581 Curl executte failed(0) or response errori(0).
May 27 17:36:11 AktivKnoten ha.cgi: ha.cc:1096 [HA-DBG] restore mtu
May 27 17:36:11 AktivKnoten ha.cgi: ha.cc:5598 Script return error vaule:
May 27 17:36:12 AktivKnoten [10561.829687] init: winbindd main process (21700) killed by TERM signal
May 27 17:36:12 AktivKnoten [10561.838995] init: smbd main process (21976) killed by TERM signal
May 27 17:36:15 AktivKnoten synonetd: net_route_table_edit.c:58 eth1 ip route del failed, instead of route
May 27 17:36:15 AktivKnoten ha.cgi: ha_cmd.cc:349 Heartbeat link check failed with return code: 2
May 27 17:36:15 AktivKnoten ha.cgi: ha_cmd.cc:392 HeartbeatCheck failed: error_heartbeat_check_ping_failed.
May 27 17:36:16 AktivKnoten [10565.718547] init: winbindd main process (22968) killed by TERM signal

 

[Matthieu]

Hi,
verrate uns mal bitte ALLE (!) IPs an beiden DSen (sprich die von allen Interfaces). Laut Log scheint es Probleme mit den Subnetzen oder dergleichen zu geben.

MfG Matthieu

 

[MichelS]

So viel ist das nicht.
LAN1(Gigabit) irgendeine private Adresse, sagen wir 192.168.1.2 mit passendem subnet 255.255.255.0 und Gateway. Darüber läuft der Zugriff vom Firmennetz(win, Mac, FTP, Filestation etc.). Alles bestens, keien Probleme.

LAN2(Gigabit) für Heartbeat, Direktverbindung(FC über Mediaconverter). Hier war ursprünglich die Default Einstellung eine 169er Adresse mit Class B. Nach vielen Tests bin ich jetzt bei:
169.254.76.254
255.255.0.0

Keine Optionen aktiviert. MTU 1500. Ping klappt.

Ich habe schon die versch. Subnetze/IP Kombinationen probiert, MTU geändert, Jumbo aus/an, den passiven Knoten aufs Werkseinstellungen gesetzt und die Heartbeatverbindung mit nagelneuen Austauschkabeln über ein VLAN gelegt um die Mediaconverter als Fehlerquelle auszuschließen. Mein letzter versuch wäre noch den Passivknoten aus meinem Backup RZ zu holen und direkt anzuschließen.
Ein Firmwaredowngrade nach den üblichen Anleitungen(Version Datei bearbeiten) klappt nicht mehr. Das Downgrade startet zwar, bricht dann aber mit Error 21 ab.

Das war jetzt in zwei Jahren das vierte oder fünfte schwerwiegende Problem mit SHA. Wenn das so weiter geht gebe ich den Cluster auf und funktioniere den Passivknoten zum Ersatzteillager oder Backupserver um.

 

[Matthieu]

LAN2(Gigabit) für Heartbeat, Direktverbindung(FC über Mediaconverter). Hier war ursprünglich die Default Einstellung eine 169er Adresse mit Class B. Nach vielen Tests bin ich jetzt bei:
169.254.76.254
255.255.0.0

An den IP-Einstellungen der Heartbeat-Verbindung etwas zu ändern ist fatal. Deshalb steht in der Hilfe auch nirgendwo wie das geht. In den Logs siehst du einen ping-Befehl der auf eine IP verweist die jetzt wahrscheinlich nicht mehr verfügbar ist. Zur Neueinrichtung muss die Schnittstelle auf DHCP stehen!
Auch sehe ich oben keineswegs alle IPs. Ich klinke mich sonst an der Stelle aus. Ich will ja gern helfen ...

MfG Matthieu

 

[MichelS]

An den IP-Einstellungen der Heartbeat-Verbindung etwas zu ändern ist fatal. Deshalb steht in der Hilfe auch nirgendwo wie das geht. In den Logs siehst du einen ping-Befehl der auf eine IP verweist die jetzt wahrscheinlich nicht mehr verfügbar ist. Zur Neueinrichtung muss die Schnittstelle auf DHCP stehen!
Auch sehe ich oben keineswegs alle IPs. Ich klinke mich sonst an der Stelle aus. Ich will ja gern helfen ...

MfG Matthieu

No offending, war vielleicht schlecht rauszulesen:

Hier war ursprünglich die Default Einstellung eine 169er Adresse mit Class B

Soll heißen ich habe erst angefangen die Konfiguration zu ändern nachdem es nicht mehr geklappt hat. Ich hatte zwischendurch(und jetzt) auch mal wieder DHCP an. Die von dir angeschriebene IP ist mir auch aufgefallen. Diese war definitiv nie vorhanden.
Das ich keine weiteren IPs hinschreibe liegt daran daß die der Heartbeatstrecke schon zu oft gewechselt haben. LAN3 und 4 sind nicht aktiv.

Aktuell:
DHCP
Heartbeat aktiv:
inet addr:169.254.170.166 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9304 errors:0 dropped:0 overruns:0 frame:0
TX packets:8991 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7028479 (6.7 MiB) TX bytes:9201906 (8.7 MiB)
Interrupt:17 Memory:f7c00000-f7c20000

passiv:
inet addr:169.254.76.254 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6798 errors:0 dropped:0 overruns:0 frame:0
TX packets:8780 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3884621 (3.7 MiB) TX bytes:6617853 (6.3 MiB)
Interrupt:17 Memory:f7c00000-f7c20000

 

[Matthieu]

Versuchst du derzeit eine Neueinrichtung oder eine Wiederaufnahme der Verbindung? Ich könnte mir vorstellen dass für letzteres jetzt schon zu viel passiert ist um das sinnvoll wieder gerade zu biegen.

MfG Matthieu