Synology High-Availability Cluster erweitern

[Whistl0r]

Hallo!

Ich habe zwei Synology RS3617xs+ Systeme, die in einem High-Availability Cluster zusammengeschaltet sind.

Der aktuelle Storage-Pool ist ein RAID 5 bestehend aus 9 Festplatten.

Ich möchte in jede Node 3 weitere Festplatte installieren und das RAID 5 anschließend auf 12 Festplatten erweitern.

Ich habe allerdings die Sorge, dass es während der Erweiterung zum Ausfall einer oder gar mehrere Festplatten in einer Node kommen kann (die Nodes sind nun schon seit 4+ Jahren im Betrieb). Im schlimmsten Falle würde ich also eine Node komplett verlieren. Im Normalfall ist das kein Problem, weil es ja genau hierfür die zweite Node gibt. Aber wenn die Erweiterung parallel durchgeführt wird sehe ich die reale Chance, dass im Worstcase beide Nodes ausfallen und ich damit den gesamten Cluster verliere. Das wäre ein Problem.

Meine Idee ist nun, die derzeitige passive Node sauber aus dem Cluster zu entfernen. Die wird damit mein Backup.

Jetzt starte ich die Erweiterung auf der verbliebenen aktiven Node.

Scheitert die Erweiterung, kann ich jederzeit auf Basis der zuvor entfernte passive Node einen neuen Cluster bauen.

Wenn hingegen alles geklappt hat, füge ich die zuvor entfernte Node wieder hinzu. Nach meinem Kenntnisstand würde Synology den alten Storage-Pool auf dieser Node nun komplett platt machen um dann alles mit der Konfiguration der aktiven (Quell-)Node neu hochzuziehen (d.h. in der Folge ist auch ein kompletter Sync notwendig).

Kann mein Plan funktionieren oder scheitert er bereits daran, dass mich die Synology die aktive Node nicht erweitern lässt, während die passive Node entfernt ist (weil der Cluster bspw. als nicht "healthy" angesehen wird, da er nur aus einer Node besteht)?

Oder sind meine Überlegungen gar nicht notwendig, weil die Erweiterung eh "staged" (nacheinander) und nicht parallel erfolgt?

 

[maxblank]

HA-Cluster auflösen, Erweiterungen an beiden RS durchführen, HA-Cluster neu erstellen.

Unabhängig vom HA-Cluster hast du ein separates Backup?

 

[Whistl0r]

HA-Cluster auflösen, Erweiterungen an beiden RS durchführen, HA-Cluster neu erstellen.

Nur um hier kein Verständnisproblem aufkommen zu lassen: Du meinst wirklich beide Nodes in den Standalone-Modus zurückzuversetzen, wodurch die Cluster-IP "verloren" geht, ja? Du sprichst nicht davon wie ich derzeit überlege lediglich eine Node aus dem Cluster zu entfernen, wodurch die verbliebene Node aber im Cluster-Mode verbleibt und damit auch die Cluster-IP hochhält.

Diesen Schritt scheue ich bislang, weil das Storage von mehr als 50 anderen Systemen verwendet wird, an die man teilweise auch gar nicht so einfach herankommt. Wobei -- muss ich die Systeme überhaupt anfassen? In dem Moment wo der Cluster aufgelöst wird, verschwindet die Cluster-IP und damit verlieren die Clients die Verbindung. Aber ich könnte diese Cluster-IP dann ja einer ehemaligen Node die dann im Standalone-Modus läuft zuweisen, wodurch die Clients sich wieder automatisch verbinden sollten. Nicht?

Ist es wirklich notwendig die Erweiterung an beiden Systemen vorzunehmen, wenn die nicht mehr im Cluster-Mode sind? Kostet das nicht nur unnötig Zeit, weil Synology das als passive Node designierte Gerät bei der Cluster-Erstellung eh komplett platt machen wird?

Unabhängig vom HA-Cluster hast du ein separates Backup?

Von den ~120TB sind ca. 75TB noch zusätzlich gesichert. Die vollständige Wiederherstellung würde aber gute zwei Wochen dauern. Würde der Worstcase eintreten kann ich dir garantieren, dass man lieber vorher ~8000€ für ein neues NAS ausgegeben hätte, auf welchem man die Daten zwischengelagert hätte. Das sind Peanuts gegenüber dem wirtschaftlichen Schaden der eintritt, wenn alles für ~2 Wochen während die Wiederherstellung läuft, steht. Aktuell sind das aber erst einmal Ausgaben, wofür kein Budget da ist und wenn alles gut geht, hat man anschließend ein Storages was man nicht mehr braucht...

 

[maxblank]

Wenn du das in dem Umfang noch nie gemacht hast, es vorher auch keine Testmöglichkeit gibt, kein vollständiges Backup vorgehalten wird bzw. das Zurückspielen so lange dauert, dann hole dir in einer solch sensiblen Umgebung ein Systemhaus dazu, die darin entsprechende Erfahrungen haben.

 

[Whistl0r]

Wir sind ja hier in einem Forum um uns auszutauschen. Genau das versuche ich und frage, ob hier jemand ist der so etwas schon einmal gemacht und etwas dazu sagen kann.

 

[maxblank]

Ja, habe ich. Aber weder in einer produktiven, noch einer sensiblen Umgebung. Ich habe das im Rahmen meiner persönlichen Synology-Reihe getestet.

 

[Whistl0r]

Das klingt doch toll. Dann würde ich mich sehr freuen, wenn du mich an deiner gesammelten Erfahrung teilhaben lassen würdest. Genau darum geht es doch in einem Forum.

 

[maxblank]

Vorgehensweise ist oben beschrieben.
Welche Infos fehlen dir denn genau?

 

[Whistl0r]

Diesen Schritt scheue ich bislang, weil das Storage von mehr als 50 anderen Systemen verwendet wird, an die man teilweise auch gar nicht so einfach herankommt. Wobei -- muss ich die Systeme überhaupt anfassen? In dem Moment wo der Cluster aufgelöst wird, verschwindet die Cluster-IP und damit verlieren die Clients die Verbindung. Aber ich könnte diese Cluster-IP dann ja einer ehemaligen Node die dann im Standalone-Modus läuft zuweisen, wodurch die Clients sich wieder automatisch verbinden sollten. Nicht?

Siehst du hierbei Probleme oder klingt das nach einem Plan?

Ist es wirklich notwendig die Erweiterung an beiden Systemen vorzunehmen, wenn die nicht mehr im Cluster-Mode sind? Kostet das nicht nur unnötig Zeit, weil Synology das als passive Node designierte Gerät bei der Cluster-Erstellung eh komplett platt machen wird?

Nach meinem Kenntnisstand wird das System, von welchem man den Cluster aus erstellt, das primäre System. Das sekundäre, passive System wird hierbei grundsätzlich komplett gelöscht (nicht im Sinne der Datensicherheit; Nur im Sinne der Konfiguration). D.h. etwaige bestehende Storage Pools (in dem konkreten Falle also das RAID 5) werden gelöscht und im Anschluss werden die Storage-Pools wie sie auf der primären Node existieren auf der passiven Node neu erstellt.
Ich wundere mich daher über die Empfehlung, nachdem der Cluster aufgelöst wurde und das erste System erfolgreich erweitert wurde, auch das designierte Backup-System noch zu erweitern. Dieser Schritt sollte nicht notwendig sein, weil das temporäre Backup-System ja wieder als passive Node hinzugefügt wird und dabei sollte es eben komplett geplättet werden...

 

[maxblank]

Siehst du hierbei Probleme oder klingt das nach einem Plan?

Das klingt nach einen Plan und sollte funktionieren.

Dieser Schritt sollte nicht notwendig sein, weil das temporäre Backup-System ja wieder als passive Node hinzugefügt wird und dabei sollte es eben komplett geplättet werden...

Dann müsste auch das funktionieren. Ansonsten könntest du den passiven Node manuell plätten und dann nochmals ins Cluster aufnehmen, wenn es Probleme gibt.

 

[Whistl0r]

Danke Dir! Ich habe noch eine weitere Frage: Weißt du was passiert, wenn während der Erweiterung eine HDD ausfällt? Wird die Erweiterung unterbrochen, so dass man die Chance hat die defekte HDD zu ersetzen und die Ausfallsicherheit wiederherzustellen? Oder läuft der Prozess unaufhaltsam weiter und man kann nur die Daumen drücken, dass keine zweite Festplatte ausfällt?

 

[maxblank]

Bei einem degradiertem Speicherpool wird das Erstellen des HA-Clusters abbrechen und muss danach wieder von vorne begonnen werden.

 

[Whistl0r]

Ich wollte hier abschließend nur noch Vollzug melden:

Wir haben die Erweiterung erfolgreich in der vergangenen Woche abgeschlossen.

Die passive Node einfach nur zu entfernen hat nicht gereicht -- im degradierten Zustand kann man den Cluster der dann nur aus einer Node besteht nicht erweitern:

Entsprechend wurde der Cluster dann aufgelöst:

Achtung: Dabei verlässt das System die Domäne. D.h. man muss das Standalone-System anschließend wieder der Domäne hinzufügen, wenn man eine verwendet (Stichwort LDAP-Authentifizierung).

Um den Betrieb ohne Anpassung der Clients wieder aufnehmen zu können, haben wir dann einfach die frühere Cluster-IP temporär zusätzlich via Konsole aufgeschaltet:

ifconfig bond0:temp 192.168.0.123 netmask 255.255.255.0

Die anschließende RAID5-Erweiterung um 3 Festplatten (von 9x 16TB auf 12x 16TB) hat dann knapp 6 Tage gedauert. Durch das Anpassen diverser Kernel-Parameter wie

• /sys/block/md2/md/stripe_cache_size
• /sys/block/md2/queue/read_ahead_kb

konnte die Dauer des Vorgangs auf knapp 3 1/2 Tage reduziert werden (das ganze geschieht auf Kosten des Arbeitsspeicher-Verbrauchs -- wenn die Synology nur als Storage verwendet wird sicherlich kein Problem; Verwendet man die Synology auch als VM/Docker Host, kann das ein Problem sein).

Danach haben wir den Cluster neu erstellt. Hierbei muss man daran denken, sofern man die Cluster-IP zuvor manuell aufgeschaltet hatte, diese auch wieder manuell zu entfernen -- sonst gibt es Probleme bei der Cluster-Erstellung:

ifconfig bond0:temp down

Bei der Erstellung eines Clusters wird die designierte passive Node immer komplett plattgemacht.

Gut zu wissen:
Synology geht nicht hin und erstellt nun auf der designierten passive Node erst die mdraids, dann die Volumen um anschließend die Dateien herüber zu kopieren. So hatte ich bspw. Sorge, dass die RAID5-Initialisierung ja Tage dauern würde und da man nicht an die passive Node per Konsole herankommt, kann man dort auch keine Parameter tweaken um den Vorgang zu beschleunigen.
Stattdessen erstellt die Synology auf dem zweiten System lediglich die Block Devices und repliziert diese anschließend von der aktiven Node herüber. Das ganze geschieht Mittels Distributed Replicated Block Device (drbd). Den Status kann man via

cat /proc/drbd

nachverfolgen.

Leider dauert dieser Vorgang und ich habe keinen Weg gefunden, diesen zu beschleunigen. Schaut man sich bspw. die DRBD Konfiguration an, so stellt man fest, dass Werte wie rsync-rate, c-max-rate, c-min-rate and c-fill-target alle schon höher gesetzt sind als die Werte, die tatsächlich erreicht werden:

resource vg1-volume_19 {
    options {
    }
    net {
        timeout                 40; # 1/10 seconds
        max-epoch-size          8192;
        max-buffers             16384;
        connect-int             30; # seconds
        ping-int                5; # seconds
        sndbuf-size             2097152; # bytes
        rcvbuf-size             2097152; # bytes
        ko-count                105;
        cram-hmac-alg           "sha1";
        shared-secret           "907811650";
        after-sb-0pri           discard-zero-changes;
        after-sb-1pri           consensus;
        ping-timeout            50; # 1/10 seconds
    }
    _remote_host {
        address                 ipv4 169.254.1.2:7416;
    }
    _this_host {
        address                 ipv4 169.254.1.1:7416;
        volume 0 {
            device                      minor 16;
            disk                        "/dev/mapper/cachedev_16";
            meta-disk                   "/dev/loop.vg1-volume_19";
            disk {
                on-io-error             pass_on;
                fencing                 resource-only;
                disk-flushes            no;
                md-flushes              no;
                resync-rate             4096000k; # bytes/second
                c-plan-ahead            10; # 1/10 seconds
                c-fill-target           1024000s; # bytes
                c-max-rate              4096000k; # bytes/second
                c-min-rate              337920k; # bytes/second
            }
        }
    }
}

Zum Vergleich:

Das Storage schafft ~620MB/s:

cd /volumeX
/volumeX# dd if=/dev/zero bs=1M count=10000 oflag=dsync > test1.dat
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 17.0041 s, 617 MB/s

Die Replizierung via dediziertem 2x10GBit Bond lief trotzdem nur mit ~150MB/s.

Da wir mehrere Volumes haben konnte ich den Vorgang dadurch etwas beschleunigen, dass ich mehrere Volumen parallel synchronisieren hab lassen (Synology selbst würde nur sequentiell vorgehen):

drbdadm resume-sync vg1-volume_X

Bei mehr als 2-3 parallele Vorgänge brach die Leistung jedoch ein -- immerhin, dadurch konnte die Auslastung auf ~250MB/s gesteigert werden.


PS: Im Rahmen der Erweiterung kam es zu keinem weiteren Festplattenausfall. Alle verbliebenen Seagate ST16000NM001G-2KK103 Festplatten die nun gute 5 Jahre auf dem Buckel haben, haben durchgehalten!