Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Hallo liebe Leute und @wien.rocks User*innen!
Willkommen in der nächsten Ausgabe unserer Informationsreihe zu @wien.rocks!
Diesmal wollen wir die zukünftige Infrastruktur etwas detaillierter präsentieren. Der Plan ist ja, von der bestehenden Installation, die alle Komponenten, die zum Betrieb einer Mastodon-Instanz notwendig sind, monolithisch auf einem Server vereint, zu einer skalierenden Platform zu migrieren.
Der "Umzug" ist daher nicht so trivial, wie man denken möchte - es genügt nicht, die bestehende Installation einfach auf einen stärkeren Server zu "kopieren", weil Mastodon so nicht skaliert[1][2][3][4][5][6]. Das Hauptproblem ist hier die technologische Basis, auf der Mastodon basiert, nämlich Ruby bzw. die Ruby Virtual Machine, in der der ganze Applikationsstack läuft.
Stattdessen gilt es, alle zu skalierenden Komponenten zu isolieren und in einer Form zu betreiben, die sich horizontal skalieren lassen. Bei Mastodon sind das in erster Linie:
- Sidekiq Job Queues ("Middleware")
- Puma Web frontend worker ("Webserver")
Diese sind für die Präsentation der Webinhalte sowie der Abarbeitung von jeder Art von Nutzerinteraktion (Posten, Bildupload, etc.) zuständig.
Dankenswerterweise veröffentlichen die Programmierer von Mastodon sogenannte Applikationscontainer, die sich dann auf beliebigen Containerplattformen (cloud sowohl als on-premise) in Betrieb nehmen lassen. Wir haben uns hier für OpenShift (bzw. die frei verfügbare Variante OKD) entschieden, und dieses auf unserer neuen Infrastruktur in Betrieb genommen.
Infrastrukturlayout - Hardware
Als Basis dient ein sogenanntes "Bladechassis", das modular um Server erweitert werden kann, falls notwendig. Alle Komponenten wie z. B. Netzteile, Festplatten, Netzwerkmodule etc. sind hier redundant ausgeführt, um auch im Falle einer notwendigen Hardwarewartung einen unterbrechungsfreien Betrieb zu gewährleisten. Das Netzwerk ist zwischen allen Komponenten mit 10GbE-Komponenten verbunden, um Flaschenhälse bei der Bandbreite zu eliminieren.
Als Storage kommt ein ebenso redundant ausgelegtes Enterprise Storagesystem eines namhaften Anbieters zum Einsatz, das Datensicherheit und Verfügbarkeit garantiert.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Infrastrukturlayout - Software und vertikale Integration
Hier noch ein Überblick über die einzelnen Softwarekomponenten der Mastodon-Instanz @wien.rocks und deren Integration:
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Viele Grüße und bis demnächst,
@b2c
PS: Falls ihr Fragen dazu habt kontaktiert uns gerne auf @wien.rocks:
Zitate
- [1] https://github.com/hachyderm/community
- [2] https://medium.com/@kris-nova/hachyderm-infrastructure-74f518bc7472
- [3] https://leah.is/posts/scaling-the-mastodon/
- [4] https://hazelweakly.me/blog/scaling-mastodon/
- [5] https://github.com/mperham/sidekiq/wiki/Using-Redis#multiple-redis-instances
- [6] https://gist.github.com/Gargron/aa9341a49dc91d5a721019d9e0c9fd11