Wie viele vermutlich nicht wissen, liefert MNX Solutions alle acht Wochen ein neues Release für Triton aus - alle zwei Wochen kommt ein neues Release für SmartOS. Die Schritte, die für ein Update durchgeführt werden müssen, hatte ich schonmal unter triton-update-all dokumentiert. Ich führe diese Updates jeweils kurz nach erscheinen in den vorhandenen Triton-Setups durch.
Ein kritischer Punkt bei diesen Upgrades ist das automatische Aktualisieren des Manatee-Clusters, der quasi die "source of truth" für die gesamte Umgebung darstellt. Wenn dieser Cluster nicht verfügbar ist, ist es für Benutzer nicht mehr möglich, Instanzen zu starten und die Verwaltung der Triton-Umgebung ist auch schwieriger, weil verschiedene Tools sich darauf verlassen. Gleichzeitig kann man sich vorstellen, dass es keine triviale Aufgabe ist, so einen Dienst, der sich wiederum auf auf andere Dienste abstützt, verlässlich automatisch zu aktualisieren.
Es ist deshalb erforderlich, möglichst schnell zu erkennen was das Problem ist, wenn das Upgrade von Manatee scheitert. Zu den Situationen, die ich schon kannte, hat sich jetzt das "registrar Problem" hinzugesellt. In meinen Augen wird es durch "langsame" Plattenkonfigurationen hervorgerufen.
Um das Problem zu identifizieren, würde ich zunächst den Status des Manatee-Dienstes prüfen. Das macht man am Besten, in dem man sich in die manatee-Zone auf dem Headnode einloggt und dort den Status des Clusters abfragt. So sollte ein "gesunder" Manatee-Cluster aussehen:
[root@headnode (de-gt-2) ~]# sdc-login manatee0
[Connected to zone '6589d30f-5fe7-4e79-899e-c6b0f540b9c0' pts/11]
Last login: Tue Dec 17 21:08:42 on pts/11
= J O Y E N T =
sdc-postgres (release-20191205-20191205T011218Z-g339b449)
https://github.com/joyent/sdc-manatee.git
triton-origin-multiarch-15.4.1@1.0.1
[root@6589d30f-5fe7-4e79-899e-c6b0f540b9c0 (de-gt-2:manatee0) ~]# manatee-adm show -v
zookeeper: 10.65.68.9
cluster: sdc
generation: 39 (83/AE56B318)
mode: normal
freeze: not frozen
ROLE PEERNAME IP
primary 5e0a09bb-6f04-4ffe-aeb7-ac1cb23b93ed 10.65.68.51
sync a0ea1808-e141-4d40-9c43-a145e1e7aab6 10.65.68.52
async 6589d30f-5fe7-4e79-899e-c6b0f540b9c0 10.65.68.14
ROLE PEER PG REPL SENT FLUSH REPLAY LAG
primary 5e0a09bb ok sync 83/AF299168 83/AF299168 83/AF299168 -
sync a0ea1808 ok async 83/AF299168 83/AF299168 83/AF299168 0m13s
async 6589d30f ok - - - - 0m13s
[root@6589d30f-5fe7-4e79-899e-c6b0f540b9c0 (de-gt-2:manatee0) ~]#
Wenn wir das "registrar Problem" haben, ist die Wahrscheinlichkeit hoch, dass das Cluster "frozen" ist - was dann bei "freeze" abzulesen wäre (ansonsten sieht der Output aber aus wie oben - deswegen genau lesen!).
Eine Methode, um abgebrochene Upgrades wieder aufzunehmen ist: Einfach nochmal anstossen. Das klappt aber nicht, wenn wir das "registrar Problem haben":
[root@headnode (de-gt-2) ~]# sdcadm update --all -y --force-data-path
sdcadm update: error (InternalError): Precondition failed: no connection moray
[root@headnode (de-gt-2) ~]#
Der nächste logische Schritt ist also das Manatee-Cluster mit manatee-adm unfreeze aus dem Winterschlaf zu holen und die moray-Instanzen zu überprüfen. Zunächst mal sollten alle Zonen im Status running sein:
[root@headnode (de-gt-2) ~]# sdc-role list |grep -i moray
moray0 headnode 6b64bee0-7c14-4339-9131-3d53a1950894 8192 running moray 10.65.68.15
moray1 hh24-gts2-de28 81dcfe12-788f-4c97-bfae-1959e7e77e9e 8192 running moray 10.65.68.54
moray2 hh24-gts2-de27 0d8632c3-204e-4cd0-a03a-40918fbf1fc4 8192 running moray 10.65.68.55
Ausserdem sollten alle Dienste in diesen Zonen laufen:
[root@headnode (de-gt-2) ~]# sdc-login moray2
Password:
[Connected to zone '0d8632c3-204e-4cd0-a03a-40918fbf1fc4' pts/2]
Last login: Tue Dec 17 19:54:27 on pts/2
= J O Y E N T =
mantav2-moray (release-20191205-20191205T010104Z-gb691026)
https://github.com/joyent/moray.git
triton-origin-multiarch-15.4.1@1.0.1
[root@0d8632c3-204e-4cd0-a03a-40918fbf1fc4 (de-gt-2:moray2) ~]# svcs -x
[root@0d8632c3-204e-4cd0-a03a-40918fbf1fc4 (de-gt-2:moray2) ~]# svcs registrar
STATE STIME FMRI
online 19:46:08 svc:/manta/application/registrar:default
[root@0d8632c3-204e-4cd0-a03a-40918fbf1fc4 (de-gt-2:moray2) ~]#
Wichtig dabei: svcs -x sollte nichts ausgeben (demnach sollte kein Dienst enabled sein aber nicht laufen oder andere enabled Dienste davon abhalten zu laufen). Der nächste Schritt wäre, sicherzustellen, dass der registrar Dienst läuft (so wie oben zu sehen). Ist es nicht der Fall, muß der Dienst mit svcadm enable registrar wieder "eingeschaltet" werden. Ist dies auf allen moray-Instanzen geschehen, ist das "registrar Problem" behoben und man kann das Upgrade nochmal starten. Dies wird dann dort aufgenommen, wo es abgebrochen war.