Der Artikel wurde bereits am 19.07.2021 (an anderer Stelle verfaßt). Da ja "Mulit-Cloud" in aller Munde zu sein scheint und da es gerade geklappt hat, wollte ich kurz ein echtes "Multi-Cloud" Setup vorstellen. Wie schon geschrieben, brauchen Orchestrierungswerkzeuge, die "multi-cloud"-fähig sein…
Nur damit ich es nicht gleich wieder vergesse: Um Consul Cluster in verschiedenen Umgebungen miteinander zu "Föderieren" sind mehrere Schritte notwendig, die nicht alle an derselben Stelle der Dokumentation zu finden sind. Generell sollen sich zwei Consul Cluster, die in verschiedenen (OpenStack) Regionen installiert sind, "sehen"…
Wer meiner kleinen Reise in den Hasenbau aus Patroni, pg_auto_failover und Citus bis hierhin gefolgt ist, konnte sich ungefähr denken, was jetzt noch kommen muß: Benchmarking. Und auch dafür gibt es etwas im Citus Repository: Citus-Benchmark. Die Installation erfolgt einfach nach Readme z. B. in einer Ubuntu Focal…
Wie in "Citus auf SmartOS übersetzen" schon erwähnt, läßt sich Citus relativ einfach auf SmartOS "portieren". Das allein ist zwar schon ganz gut, aber wir wollen Citus natürlich zusammen mit Patroni ausrollen, um Citus Cluster möglichst einfach verwalten zu können. Ähnlich wie in "Patroni Cluster…
In Patroni Cluster im Container hatte ich ja schon mit Patroni in SmartOS Zonen experimentiert. Mit der Version 3.0 unterstützt Patroni ja jetzt auch Citus, was den Aufbau von Sharded Postgres Clustern deutlich vereinfachen sollte. Gerade war ja auch der Citus Con, auf dem Alexander Kukushkin einen schönen Vortrag…
Nachdem ich zufällig in das github Repo von Citusdata geraten war, weil ich in das github Repo von Jasper Siepkes gestolpert war, war mir pg_auto_failover aufgefallen. Natürlich hatte mich das interessiert, weil ich mich ja schon mit verschiedenen Optionen beschäftigt hatte, Patroni auszurollen. Mit der steigenden Popularität von…
Für manchen etwas gewöhnungsbedürftig gestaltet sich ja das Desaster Recovery von Compute Nodes bei Triton. Denn hier bildet quasi das ZFS die letzte Verteidigungslinie - solange alle Platten intakt sind, sollte man den Compute Node in einem anderen Chassis oder nach einem Tausch des Motherboards einfach wieder in Betrieb nehmen…
Wenn man mehrere availability zones pro Region und möglicherweise sogar mehrere Regionen eines Cloud-Service betreibt, sollen Kunden natürlich in allen Rechenzentren VMs und/oder Container ausrollen können. Um dies zu erreichen, müssen die Kundeninformationen (insbesondere die Credentials) natürlich in jedem Rechenzentrum verfügbar sein. Dazu wird für den ufds-Dienst von Triton…