Trotz Doku x-te Frage zu Pools/Datasets/ZVOLs/Shares...

[knebb]

Moin,

kurze Frage zu einem besonderen Einsatzbereich von TrueNAS.

Kann ich zwei TrueNAS so miteinander verbinden, dass das System1 einen Dataset ständig und dauerhaft mit System2 synchroniesiert? Also eine Art RAID1 über's Netzwerk? Ich kenne DRBD, so etwas in der Art suche ich.

Es geht mir nicht um einen scheduled rsync-Lauf, das ist kein Thema. Tatsächlich ein Sync unterhalb der Dateisystemebene, um zB ein geteiltes Netzlaufwerk für eine Datenbank sauber synchron zu haben.

Wie kann ich das mit zwei TrueNAS anstellen?

Danke für Hinweise, Stichworte reichen, ich suche mir das dann irgendwie zurecht.

/KNEBB

 

[knebb]

Sorry, total falscher Titel- kann ich den irgendwie noch ändern?

 

[noexpand]

Ich würde an deiner Stelle nicht versuchen, so etwas selbst zu bauen, sondern stattdessen ein von vornherein verteiltes Filesystem zu verwenden. Hast du dir mal Ceph angesehen?

 

[knebb]

Puhh... ja, ich weiß was CEPH ist. Ich denke, das ist etwas Overkill.... zudem das zweite Hardware-Gerät ein QNAP-NAS ist. Da kriege ich eher kein CEPH drauf.

Kann ich iSCSI Volumes vom QNAP NAS in TrueNAS importieren? Und dann mit einer lokalen Platte als Mirror einrichten?

Ich will auch keine besondere Verfügbarkeit für die CLients, mir reicht da auch ein manuelles Umschalten...

 

[ChrisRJ]

Kann ich zwei TrueNAS so miteinander verbinden, dass das System1 einen Dataset ständig und dauerhaft mit System2 synchroniesiert? Also eine Art RAID1 über's Netzwerk?

Nein.

Was ist der Hintergrund? Ich habe eine Vermutung ;-), aber sicher ist sicher

 

[knebb]

Ich habe zwei Anwendungsfälle dafür:
1. Ich habe eine Backup-Lösung (BackupPC), deren Storage auf einem DRBD liegt. Fällt eine Kiste komplett aus, ist der Backup-Storage aber in der anderen Site vorhanden (ggf. nach FS-Check).
2. Habe ich ein System, das auf einer TrueNAS-Freigabe eine PostgreSQL Datenbank betreiben wird. Fällt TrueNAS (aus welchen Gründen auch immer) aus, so möchte ich gerne manuell auf das zweite Laufwerk zugreifen und von dort die PostgreSQL wieder starten (ggf. mit VErlust der letzten paar Transaktionen). Es fallen im Laufe eines Tages einige Datensätze an, die ich gerne mit möglichst geringem Versatz "festhalten" will. Also bitte nicht mehr als 20min der Daten verlieren. Abe ich kann nicht alle 20 Minuten eine vollständige Datensicherung machen.

Ideen dazu?

 

[ChrisRJ]

Ich habe zwei Anwendungsfälle dafür:
1. Ich habe eine Backup-Lösung (BackupPC), deren Storage auf einem DRBD liegt. Fällt eine Kiste komplett aus, ist der Backup-Storage aber in der anderen Site vorhanden (ggf. nach FS-Check).

Damit stellst Du Dich aus meiner Sicht schlechter als mit zwei Backup Jobs, die wechselseitig auf beide Zielsysteme gehen. Erstens ist es zusaetzliche Komplexitaet (v.a. bei einem Komplett-Restore) und zweitens werden logische bzw. Anwenderfehler auch gleich repliziert.

2. Habe ich ein System, das auf einer TrueNAS-Freigabe eine PostgreSQL Datenbank betreiben wird.

Freigabe bedeutet vermutlich SMB. Du weisst um die ganzen Risiken bei sowas?

Fällt TrueNAS (aus welchen Gründen auch immer) aus, so möchte ich gerne manuell auf das zweite Laufwerk zugreifen und von dort die PostgreSQL wieder starten (ggf. mit VErlust der letzten paar Transaktionen). Es fallen im Laufe eines Tages einige Datensätze an, die ich gerne mit möglichst geringem Versatz "festhalten" will. Also bitte nicht mehr als 20min der Daten verlieren. Abe ich kann nicht alle 20 Minuten eine vollständige Datensicherung machen.

Full Backup ist fuer sowas auch nicht noetig. Ich wuerde, wenn es wirklich so wichtig ist, alle paar Minuten einen Delta Export machen und das sichern.

Ideen dazu?

Ich kann verstehen, wo Du herkommst. Aber aus meiner Sicht sind beide Ansaetze unter'm Strich nicht geeignet die Sicherheit zu erhoehen. Eher im Gegenteil, weil es relativ komplex ist. Im Ernstfall, und den habe ich gerade, bist Du dankbar, wenn die Dinge so einfach wie moeglich sind.

 

[knebb]

Damit stellst Du Dich aus meiner Sicht schlechter als mit zwei Backup Jobs, die wechselseitig auf beide Zielsysteme gehen. Erstens ist es zusaetzliche Komplexitaet (v.a. bei einem Komplett-Restore) und zweitens werden logische bzw. Anwenderfehler auch gleich repliziert.

Ja, das mag stimmen. Vielleicht sollte ich das besser so machen... aber das ist auch garnicht meine wichtigste Anwendung dafür.

Freigabe bedeutet vermutlich SMB. Du weisst um die ganzen Risiken bei sowas?

Du hast recht, das ist ein Problem das mir noch nicht bewußt war. Der Hersteller der Software sieht das so vor.... alternativ kann ich auch NFS nehmen. Der Client, auf dem die PostgreSQL läuft, ist ein MacOS. Der hat leider nur eine SSD. Da ist mir die Verwendung eines Shares (ggf. auch iSCSI, wenn ich das dem Mac beigebracht kriege) schon lieber.

Full Backup ist fuer sowas auch nicht noetig. Ich wuerde, wenn es wirklich so wichtig ist, alle paar Minuten einen Delta Export machen und das sichern.

Ich hatte jetzt schonmal gesucht, aber wie mache ist das mit dem Delta-Export bei PostgreSQL sinnvoll? Ohne, dass die DB im laufenden Betrieb runtergefahren werden muss?
Dann würde ich die Datenbank auf der lokalen SSD lassen, die anderen Dateien aber dann auf einem Share ablegen (oder via rsync im Minutentakt syncen). Und falls es knallt, einem anderen Mac das Share "unterschieben", die Datenbank restoren und weiter geht es.

 

[knebb]

Ich sehe gerade, dass es ein Comunity-Plugin namens "zrepl" gibt.

Erfahrungen damit? Das scheint genau das zu machen, was ich suche....

 

[Patrick M. Hausen]

Du hast recht, das ist ein Problem das mir noch nicht bewußt war. Der Hersteller der Software sieht das so vor.... alternativ kann ich auch NFS nehmen. Der Client, auf dem die PostgreSQL läuft, ist ein MacOS. Der hat leider nur eine SSD. Da ist mir die Verwendung eines Shares (ggf. auch iSCSI, wenn ich das dem Mac beigebracht kriege) schon lieber.

Weshalb nicht das Postgres auf einem ordentlichen System laufen lassen, z.B. in einem Jail auf CORE oder als App auf SCALE, und die Anwendung damit verknubbeln. Datenbanken sind im allgemeinen netzwerkfähig

 

[knebb]

Ja, genau das habe ich den Hersteller jetzt auch schon gefragt. Ob die Applikation nun localhost:5432" oder "pgsqlserver:5432" nimmt, sollte ihr ja egal sein. Dann läuft PostgreSQL in einer Debian-VM und alles ist gut.

Wäre nur noch die Frage, ob jemand Erfahrungen mit dem zrepl hat? DAs klingt eigentlich ziemlich gut.

 

[Patrick M. Hausen]

Warum in einer Debian-VM? Postgres läuft super-duper in einem Jail auf FreeBSD. Haben Dutzende von Kunde-Installationen damit.

zrepl - keine Ahnung. Fester Bestandteil von TrueNAS und über das UI konfigurierbar ist zettarepl. Das funktioniert tadellos.

 

[ChrisRJ]

Ja, genau das habe ich den Hersteller jetzt auch schon gefragt. Ob die Applikation nun localhost:5432" oder "pgsqlserver:5432" nimmt, sollte ihr ja egal sein. Dann läuft PostgreSQL in einer Debian-VM und alles ist gut.

Um was fuer eine Applikation geht es denn?

 

[knebb]

Alles klar, das klingt doch sehr gut. Zum paar-minütlichen Sync ZettaRepl, das reicht für meine Zweck.
Und (wenn ich auch kein Freund von Docker-ähnlichen Lösungen bin) ein Jail mit PostgreSQL, wenn der Hersteller dem zustimmt.

Es geht um eine Software für Arztpraxen (Tomedo). Die läuft nur auf MacOS.

Danke an alle!

 

[Patrick M. Hausen]

Jails sind aber sowas von anders als Docker Wird stabil laufen, keine Sorge. Hilfe bekommst du hier, gibt ein paar Ecken und Kanten speziell bei Postgres wegen des shared memory. Aber das muss man nur einmal konfigurieren und dann ist gut.