Gluster-Server haben identische UUIDs für /root

[Rüdiger Kupper]

Unsere vier Gluster-Server haben die selbe UUID für das /root-Dateisystem.
Das weist darauf hin, dass das Setup mechanisch kopiert wurde, ohne sich über die Filesysteme Gedanken zu machen.
UUID bedeutet „universally unique identifier“. Diese Bezeichnung soll es demnach in unserem Universum nur ein einziges Mal geben. Dass unsere vier Server die selbe UUID haben sollten, ist unwahrscheinlich.
Hier wurde gedankenlos ein Festplattenimage kopiert, ohne nachher die UUIDs zu ändern.

[Rüdiger Kupper]

Ganze Maschinen über ein dd-Image zu duplizieren ist nicht mehr zeitgemäß und bereitet in modernen Setups Probleme.
Wo möglich, sollten VM oder container verwendet werden, bei denen die Replikation für Randomisierung der UUIDs sorgt.
Wenn bare-metal-Installationen nötig sind, können Frameworks wie ​Puppet die Randomisierung übernehmen.

[bau]

Nette Wortwahl: gedankenlos.
Ich schlage für die nächsten Server vor, dass du die selbst aufsetzt.
Wäre mir durchaus lieber, ich habe ansonsten durchaus genug zu tun.

[bau]

Betroffen sind sda1 sda5 gluster1-vg/root und gluster1-vg/swap_1

/dev/sda1: UUID="f9dcf238-33c7-4114-aab4-354cd81f1137" TYPE="ext2" PARTUUID="0038d2c4-01"
/dev/sda5: UUID="57LxpN-rADL-d0eR-LBy4-0efF-XSOl-7eHwb8" TYPE="LVM2_member" PARTUUID="0038d2c4-05"
/dev/mapper/gluster1--vg-root: UUID="2eb26bd7-3f28-4b8c-923e-e878458955dd" TYPE="ext4"
/dev/mapper/gluster1--vg-swap_1: UUID="b2ea0e21-6dd0-41e6-ad5c-6d9251c51eed" TYPE="swap"

Das lässt sich mit tune2fs beheben, falls es stören sollte

  tune2fs -U random /dev/sdaX 

[bau]

Die Boot-Partition auf /dev/sda1 ist recht klein ausgefallen, hat ext2 als Filesystem und ist eigentlich unnötig.
Es ist zu überlegen, ob diese Partition entfallen kann und der GRUB2 so eingerichtet wird, dass er direkt vom LV glutser1-vg/root bootet.

[Rüdiger Kupper]

Replying to bau:

Das lässt sich mit tune2fs beheben, falls es stören sollte

  tune2fs -U random /dev/sdaX 

Ach stimmt, das sind ja ext-Dateisysteme. Sicher gibt es ein vergleichbares Tool für XFS, kenne ich aber (noch) nicht.

Unmittelbar stören tut es derzeit nicht, solange jeder Server "bei sich" bleibt. Meine Sorge ist eher, dass uns das gleiche Problem woanders wieder begegnet. Das Aufsetzen des Gluster-Pools ist ja erst mal daran gescheitert, dass alle vier Maschinen in /etc/hostname gluster1 stehen hatten.

Das Problem ist, dass nicht sicher ist, wo sowas überall passieren kann. Schlimmstenfalls könnte man Maschinen mit identischen Netzwerk-MACs produzieren oder so etwas.

Und Gluster verwendet intern ebenfalls UUIDS, um die verschiedenen Knoten und Filesysteme anzusprechen. Man könnte für die nächsten Server ja auf die Idee kommen, einfach einen der laufenden, aufgesetzten Knoten per dd zu klonen – spätestens dann wäre Gluster verwirrt, weil zwei Knoten die selbe UUID hätten. Da muss man also wissen, wo man nach dem klonen überall "nacharbeiten" muss. Zum Aufsetzen neuer LTSP-Server hatte ich damals ein Skript geschrieben, was das komplette System von einem laufenden Server per rsync herüberkopiert und dann genau diese Schritte durchgeführt hat (hostname ändern, UUIDS ändern, etc.) Doch ich war nie ganz sicher, ob ich alles "erwischt" hatte.

Mit dem Skript konnte ich dann immerhin in ein paar Stunden einen zusätzlichen LTSP-Server zum Laufen bringen. So was wäre für Gluster natürlich auch schön, es sind doch einige Schritte, bis die Dinger eingerichtet sind (siehe AdminGlusterAufsetzen). Die moderne Variante wäre, eine VM oder einen Container zu nutzen und den z.B. mit Proxmox wegzuspeichern. Beim Wiederherstellen auf einem neuen Host sorgt dann Proxmox für die ganzen nötogen Änderungen. Oder tatsächlich Puppet, das scheint genau für so etwas gemacht zu sein. Stephan hat damit wohl Erfahrung oder die haben es zumindest genutzt, um schnell neue Server hochzuziehen. – Wäre aber wieder ein neues Framework zum Einarbeiten ;-).

[Rüdiger Kupper]

Replying to bau:

Die Boot-Partition auf /dev/sda1 ist recht klein ausgefallen, hat ext2 als Filesystem und ist eigentlich unnötig.
Es ist zu überlegen, ob diese Partition entfallen kann und der GRUB2 so eingerichtet wird, dass er direkt vom LV glutser1-vg/root bootet.

Bevor ich mit dem Einrichten angefangen habe, habe ich erst mal ein "apt full-upgrade" gemacht und das ist direkt fehlgeschlagen, weil in der /boot-Partition zu wenig Platz war. Konnte ich dann zwar durch Entfernen älterer Kernel-Images beheben, im laufenden Betrieb sollte so was aber besser nicht passieren. Früher wurde tatsächlich immer empfohlen eine eigene Boot-Partition mit ext2 zu haben, die außerhalb von LVM/RAID läuft. Doch das dürfte inzwischen wirklich überflüssig sein.
Ich lasse das jetzt erst mal so, weil ich die Server möglichgst schnell in Einsatz bringen will. Wäre dann vielleicht was für die nächsten Ferien ;-).

[Rüdiger Kupper]

Ach, schau hier, es gibt sogar ein eigenes Puppet-Modul, um Gluster aufzusetzen:
​https://docs.gluster.org/en/latest/Administrator-Guide/Puppet/

Zitat: „This Puppet-Gluster module handles installation, configuration, and management of GlusterFS across all of the hosts in the cluster.“

Vielleicht doch wert, sich da einzulesen.