Mit diesem Thread möchte ich mal vorgreifen in die Zeit, wenn man den PBS als Backupziel für die Client-Sicherung in Unternehmen nutzen kann. interessant wird dies ja erst, wenn auch Windows-Clients mit dem Proxmox-Backup-Client (PBC) gesichert werden können. Im nächsten Release kommt mit Sicherheit wenigstens die Unterstützung für die weiteren Linux-Distros.
Zur Aufgabenstellung: Häufig müssen Clients neu installiert werden wegen irgendwelcher Fehler, die nicht so zu beheben sind. Dazu gibt's bereits Paketmanager, wenn das Unternehmen clever ist, aber damit dauert die Installation auch lange. Schön wäre es, wenn man Vollsicherungen von Clients zurückspielen könnte. Die aktuellen Plattenpreise pro TB sind ja nun echt günstig, aber man hat ja als Admin eigentlich immer Plattenabfall rumliegen. Alte Platten, die noch in Ordnung sind und die man nutzlos lagert. Weil man viele verschiedene Größen hat, die Meisten nur SATA sind und sich für das Serverbackend nicht so richtig einsetzbar sind, hat man nur den Einsatzzweck als Cient-HDD-Ersatz. Für eine Clientsicherung wären diese aber allemal brauchbar, da ich diesen Storage dann auch mal verlieren kann und mir das nicht gleich weh tut, denn ich kann die Daten auch auf anderem Wege wieder herstellen. Es dauert nur länger. Nun möchte ich daraus einen PBS mit lokalem Storage bauen. Den gleichen PBS der Serversicherung zu nutzen, würde ich aus Sicherheitsgründen nicht empfehlen.
Wenn man Platten mit unterschiedlicher Größe als Datenspeicher verbinden möchte, dann denkt man vielleicht sofort an Snapraid. Snapraid ist geil, da man damit sogar Self-Healing hat. Problem ist aber, dass snapraid auf den Platten ein Dateisystem verlangt. Diese einzelnen Dateisysteme kann ich nur mit einem Overlay-Dateisystem wie unionfs oder mergefs verbinden. Diese reichen mir aber nur abwechselnd die einzelnen Dateisysteme durch, sodaß ich bei 2 Datenplatten à 10 GB nicht 20 sondern nur die 10 GB der einzelnen Platte sehe, auf die das overlay-FS gerade schreiben möchte. Das ist natürlich zum einen unübersichtlich zum anderen sind es ja trotzdem noch 2 Dateisysteme, d.h. der PBS könnte auf chunks der einen Platte nicht von der Andere verweisen.
Alternativ könnte man die einzelnen Blockgeräte ja mit btrfs single oder LVM verbinden. Dann sieht man ein großes Dateisystem. Leider wird aber hier immer nur auf ein Gerät geschrieben. Wenn ich eine größere Umgebung habe, wo ich vielleicht die Schreibvorgänge etwas splitten möchte, geht das nicht.
Welche weiteren Möglichkeiten habe ich also, um auch Performance zu bekommen, obwohl ich fast nur unterschiedliche Größen habe. Mir sind 3 Möglichkeiten eingefallen, die man zusammen mit PBS einsetzen könnte. Kurz und knapp:
1. ceph,
das seine OSDs auf dem lokalen Server hat.
2. HW-Raid-Controller + LVM + XFS
Wenn man einen rumliegen hat, der die Funktionalität mitbringt, sollte man den nutzen, da man doch erhebliche CPU-Last spart. Was muss der können?:
Ich bilde also Größengruppen aus meinem Plattenabfall, damit ich virtuelle LWe entweder aus Raid1 oder Raid5 etc. bauen kann. Dann verbinde ich die einzelne Raids/virt. LWe mit dem LVM (Volumen Group) zu einem großen logischen Laufwerk - also Raid1+Raid1+Raid5 zu VG "Raid-Vol".
Danach kreiere ich ein log. Volume als Blockgerät und formatiere es mit XFS +--reflink-Parameter und der passenden Blockgröße. Wenn ich weitere Platten hinzufügen möchte, dann erweitere ich die Raids oder konvertiere diese zu einem nächst möglichen Raid und erweitere die zugehörigen PVs und die darüber liegenden Schichten (VG+LV+XFS).
3.SW-Raid mit mdadm + LVM + XFS
Ich mache genau das gleich wie mit dem HW-Raid-Controller und lege einzelne Raid-Gruppen an. Diese verbinde ich mit LVM und dessen BLockdevice formatiere ich dann wieder mit XFS wie oben. Wenn ich eine GUI dafür benutzen möchte, empfehle ich webmin und nicht cockpit, da cockpit unter Debian noch zu instabil ist. Mdadm untersützt wie Raid-Controller verschiedene Raid-Migration.
Vergleich der Lösungen:
Wer hier jetzt zfs vermisst, dem sei gesagt, dass zfs leider bei der Raid-Migration nicht so flexibel ist und damit unbrauchbar für diesen Einsatzzweck. Bei den Raid Beispielen kann man natürlich auch Raid10 einsetzen.
Wer nicht warten kann und noch eine gute Lösung ohne PBS sucht, der kann mir 'ne pm schicken und ich empfehle dann was. In diesem Forum es zu erwähnen, würde nicht passen.
Meine Empfehlung ist die Variante ohne den HW-Controller zu nehmen, da die manchmal Fehlfunktionen bei Migrationen zeigen. mdadm ist für meinen Geschmack sehr durchsichtig und funktioniert - benötigt allerdings auch etwas CPU-Ressource. Also bei einem schwachen System dann den HW-Controller vorziehen.
Zur Aufgabenstellung: Häufig müssen Clients neu installiert werden wegen irgendwelcher Fehler, die nicht so zu beheben sind. Dazu gibt's bereits Paketmanager, wenn das Unternehmen clever ist, aber damit dauert die Installation auch lange. Schön wäre es, wenn man Vollsicherungen von Clients zurückspielen könnte. Die aktuellen Plattenpreise pro TB sind ja nun echt günstig, aber man hat ja als Admin eigentlich immer Plattenabfall rumliegen. Alte Platten, die noch in Ordnung sind und die man nutzlos lagert. Weil man viele verschiedene Größen hat, die Meisten nur SATA sind und sich für das Serverbackend nicht so richtig einsetzbar sind, hat man nur den Einsatzzweck als Cient-HDD-Ersatz. Für eine Clientsicherung wären diese aber allemal brauchbar, da ich diesen Storage dann auch mal verlieren kann und mir das nicht gleich weh tut, denn ich kann die Daten auch auf anderem Wege wieder herstellen. Es dauert nur länger. Nun möchte ich daraus einen PBS mit lokalem Storage bauen. Den gleichen PBS der Serversicherung zu nutzen, würde ich aus Sicherheitsgründen nicht empfehlen.
Wenn man Platten mit unterschiedlicher Größe als Datenspeicher verbinden möchte, dann denkt man vielleicht sofort an Snapraid. Snapraid ist geil, da man damit sogar Self-Healing hat. Problem ist aber, dass snapraid auf den Platten ein Dateisystem verlangt. Diese einzelnen Dateisysteme kann ich nur mit einem Overlay-Dateisystem wie unionfs oder mergefs verbinden. Diese reichen mir aber nur abwechselnd die einzelnen Dateisysteme durch, sodaß ich bei 2 Datenplatten à 10 GB nicht 20 sondern nur die 10 GB der einzelnen Platte sehe, auf die das overlay-FS gerade schreiben möchte. Das ist natürlich zum einen unübersichtlich zum anderen sind es ja trotzdem noch 2 Dateisysteme, d.h. der PBS könnte auf chunks der einen Platte nicht von der Andere verweisen.
Alternativ könnte man die einzelnen Blockgeräte ja mit btrfs single oder LVM verbinden. Dann sieht man ein großes Dateisystem. Leider wird aber hier immer nur auf ein Gerät geschrieben. Wenn ich eine größere Umgebung habe, wo ich vielleicht die Schreibvorgänge etwas splitten möchte, geht das nicht.
Welche weiteren Möglichkeiten habe ich also, um auch Performance zu bekommen, obwohl ich fast nur unterschiedliche Größen habe. Mir sind 3 Möglichkeiten eingefallen, die man zusammen mit PBS einsetzen könnte. Kurz und knapp:
1. ceph,
das seine OSDs auf dem lokalen Server hat.
2. HW-Raid-Controller + LVM + XFS
Wenn man einen rumliegen hat, der die Funktionalität mitbringt, sollte man den nutzen, da man doch erhebliche CPU-Last spart. Was muss der können?:
- Raid1, Raid5, Raid6
- Migration zwischen den Raids möglichst ohne Batterie (Raid1 zu Raid5 und dann Raid6)
Danach kreiere ich ein log. Volume als Blockgerät und formatiere es mit XFS +--reflink-Parameter und der passenden Blockgröße. Wenn ich weitere Platten hinzufügen möchte, dann erweitere ich die Raids oder konvertiere diese zu einem nächst möglichen Raid und erweitere die zugehörigen PVs und die darüber liegenden Schichten (VG+LV+XFS).
3.SW-Raid mit mdadm + LVM + XFS
Ich mache genau das gleich wie mit dem HW-Raid-Controller und lege einzelne Raid-Gruppen an. Diese verbinde ich mit LVM und dessen BLockdevice formatiere ich dann wieder mit XFS wie oben. Wenn ich eine GUI dafür benutzen möchte, empfehle ich webmin und nicht cockpit, da cockpit unter Debian noch zu instabil ist. Mdadm untersützt wie Raid-Controller verschiedene Raid-Migration.
Vergleich der Lösungen:
ceph | HW-Raid + LVM | SW-Raid mit mdadm | BTRFS - Singel Mode | |
| Komplexität | hoch | mittel | mittel | gering |
| GUI | nein | ja | ja | nein |
| Deduplizierung | ja, mit Blockdevice+XFS | ja,XFS | ja,XFS | ja |
| RAM usage | hoch | nur beim Dedupliziervorgang | nur beim Dedupliziervorgang | mittel |
| Self-Healing | ja | nein | nein | nein |
| Flexibilität | hoch | mittel | mittel | hoch |
| Verteiltes Schreiben | ja | ab Raid5 und 6 partiell | ab Raid5 und 6 partiell | nein |
| Clientanzahl | viele | mittelmäßig | mittelmäßig | wenige |
Wer hier jetzt zfs vermisst, dem sei gesagt, dass zfs leider bei der Raid-Migration nicht so flexibel ist und damit unbrauchbar für diesen Einsatzzweck. Bei den Raid Beispielen kann man natürlich auch Raid10 einsetzen.
Wer nicht warten kann und noch eine gute Lösung ohne PBS sucht, der kann mir 'ne pm schicken und ich empfehle dann was. In diesem Forum es zu erwähnen, würde nicht passen.
Meine Empfehlung ist die Variante ohne den HW-Controller zu nehmen, da die manchmal Fehlfunktionen bei Migrationen zeigen. mdadm ist für meinen Geschmack sehr durchsichtig und funktioniert - benötigt allerdings auch etwas CPU-Ressource. Also bei einem schwachen System dann den HW-Controller vorziehen.
Last edited:
