Ich stehe ja total auf diesen ganzen HA Kram in "good old standard" manier. Darunter zu finden ist dann auch Pacemaker als Tooling, welches man für seine Failover oder eben HA Cluster in größeren Dimensionen nutzen kann.
In diesem Beitrag beschreibe ich, wie man sich fix ein HA Setup bauen kann, bei dem N Knoten eine (virtuelle) IP-Adresse hin und her reichen. Nutzen kann man das zum Beispiel bei identisch eingerichteten Webserver, als klassisches Failover, oder - wie in meinem Fall - um damit einen Kubernetes Cluster anzusprechen und somit die Master verfügbar zu halten.
apt install --assume-yes pacemaker corosync pcs
systemctl start pcsd pacemaker corosync
systemctl enable pacemaker corosync pcsd
Mit diesem Benutzer wird das pairing versucht. Das bedeutet, das in den nächsten Schritten die Nodes versuchen werden sich mit diesem Benutzernamen und Kennwort gegenüber den anderen Teilnehmenden Knoten zu authentifizieren.
echo "d3fcCfcjumK3zPvnVFpp" | passwd hacluster --stdin
passwd hacluster
Jetzt geht es ans eingemachte: Wir setzen den Cluster auf. Wir beginnen nach einer frischen Installation damit, das wir zunächst
pcs cluster auth -u hacluster -p d3fcCfcjumK3zPvnVFpp
pcs host auth server1 server2 server3 -u hacluster
pcs cluster setup superdupercluster server1 server2 server3
pcs cluster start --all
pcs cluster enable --all
jetzt wo wir einen funktionieren Cluster haben, werden wir die gewünschte virtuelle IP-Adresse einrichten, damit wir unserem Ziel näher kommen.
pcs resource create cluster_ip ocf:heartbeat:IPaddr2 ip=111.222.333.444 cidr_netmask=24 op monitor interval=30s
Richtig cool ist eigentlich, das wir einen rudimentären Loadbalancer haben (können). Die nun vorhandene virtuelle IP-Adresse wird im Cluster geclont und auf mehreren Knoten bereitgestellt.
pcs resource clone cluster_ip clone-max=2 clone-node-max=2 globally-unique=true
pcs resource update cluster_ip clusterip_hash=sourceip
Zu guter letzt wollen wir natürlich wissen wie es unserem Cluster geht. Das erfahren wir durch
pcs status
Quellen und Links
Die Zeit ist wunderbar. Alles ist easy - alles ist einfach. Ein "klick" und schon läuft jegliche Anwendung. Rubust, stabil und ohne jegliche Ahnung von dem was man dafür machen müsste um es selbst zu installieren.
So zumindest erlebe ich die aktuelle Wahrnehmung dank der Angebote von Bezahldiensten wie AWS, Azure und Co.
Ich nutze ja auch gern die Abstraktionebenen - will aber wissen was da los ist. So wäre ich sonst vermutlich aufgeschmissen gewesen, als ich versuchte ein Graylog innerhalb von Rancher mit Hilfe der Helm-Cataloge zu installieren und die WebUI hinter dem nginx-Ingress zu verstecken.
Denn zunächst sieht es ja wunderbar einfach aus: Katalog auswählen, Graylog suchen, ein bisschen anpassen und deployen. Ging auch soweit. nur wollte die WebUI nicht so recht.
Zuerst hatte ich mixed content, dann "We are experiencing problems connecting to the Graylog server running on http://XXXXX". Das Internet sagt einem dann, das man irgendie den Port nach aussen öffnen müsste - was natürlich vollkommender quatsch ist. Zumal ich ja eine SSL-Terminierung haben will.
Lange Rede, kurzer Sinn: Das Graylog Helm-Chart ist kaputt. Dort steht nämlich geschrieben, das man einfach einen Wert für 'graylog.externalUri' setzen muss und schon ist alles super. Leider generiert das Chart nur quatsch, sodass man den Wert manuell überschreiben muss mit
graylog:
config: "http_external_uri = https://mein-super-duper.server/"
Damit wird der vom Chart generierte Wert in der Configmap überschrieben (weil einfach zuletzt angefügt) und schon klappt es mit dem ingress.
Komplett sieht das dann so aus:
---
graylog:
config: "http_external_uri = https://mein-super-duper.server/"
replicas: 2
rootUsername: admin
rootPassword: ABSOLUT-GEHEIMES-KENNWORT
input:
udp:
service:
type: ClusterIP
ports:
- name: syslog
port: 514
nodeSelector:
node-role.kubernetes.io/worker: "true"
persistence:
accessMode: "ReadWriteOnce"
enabled: "true"
size: "50"
storageClass: "longhorn"
ingress:
extraPaths[0]:
backend:
serviceName: ssl-redirect
servicePort: use-annotation
path: "/*"
enabled: true
hosts:
- mein-super-duper.server
Deshalb hab ich auch gern Ahnung von den Tools und klicke zu allerletzt auf irgendwelche Buttons... die Lösungen sind viel logischer.
Aus der bliebten Reihe: "wie werde ich zum Volltrottel und kann mir Stunden meines Lebens versauen" zeige ich heute, wie man sich retten kann, wenn man etwas zu voreilig seinen ZFS Pool optimiert und dann auch noch das Wiki von Proxmox dazu nutzt.
Dort steht zwar in einer Warnung
Warning: Do not set dnodesize on rpool because GRUB is not able to handle a different size. see Bug entry https://savannah.gnu.org/bugs/?func=detailitem&item_id=48885
wer aber ein echter Mann ist überliest das und activiert das Feature in dem er
zfs set xattr=sa dnodesize=auto rpool/$IRGENDEINDATASET
ausführt. Ausschlaggebend ist dnodesize mit einem anderen Wert als legacy. Das steht auch so in der ZFS manpage.
Nun ist das Kind in den Brunnen gefallen und ein
``bash zpool get all rpool | grep -i node rpool feature@large_dnode active local
bestätigt uns, das wir uns bis auf weiteres nichts mehr vornehmen sollen. Wenn hier nämlich **active** steht, dann ist das doof für uns und unser rpool wird mit hilfe von Grub nicht mehr booten.
Vorausgesetzt wir haben genug Platz auf unserem Server, so können wir aber alle Container herunterfahren und die Volumes/Datasets migrieren in ein Dataset, welches dnodesize=legacy gesetzt hat. Das will man natürlich so schnell und einfach wie möglich haben. Daher hab ich den Vorgang für mich wie folgt automatisiert:
```bash
zfs create rpool/$IRGENDEINDATASET-FUER-NEUE DATEN
zfs snapshot -r rpool/BISHERIGESDATASET@migrate
zfs send -Rv rpool/BISHERIGESDATASET@migrate | zfs receive -F rpool/$IRGENDEINDATASET-FUER-NEUE DATEN
zfs destroy -r rpool/BISHERIGESDATASET
zfs rename rpool/$IRGENDEINDATASET-FUER-NEUE DATEN rpool/BISHERIGESDATASET
Anschließend sollte unsere Kontrolle statt
zpool get all rpool | grep -i node
rpool feature@large_dnode **active** local
zpool get all rpool | grep -i node
rpool feature@large_dnode **enabled** local
auswerfen. Jetzt heisst es nur noch Container starten.
Leider habe ich feststellen müsse, das die obige Anleitung nicht immer (genauere Hintergründe unbekannt) funktioniert. Auch tut sich der eine oder andere Schwer mit der CLI. Dann kann man sich behelfen indem man ein weiteres Dataset anlegt und dieses in der Proxmox UI einbindet. Nun kann man einfach über die UI LXC Server stoppen, das Dataset migrieren und wieder starten. Geht soweit ganz gut... hätte man auch früher haben können :)