Wasserdichtes System für kleine Multi Teant Anwendung

[MarroniJohny]

Hoi

Im Moment wurstle ich im non-commerce Bereicht mit zwei ESXi rum. Die Server haben je einen durchgereichten HBA an napp-it (Solarish), da liegen die VMs und "Backups" drauf. Dazu 10 Gbit Anbindung, zwei 10 Gbit Firewalls mit je drei X540, 5 Switches, sowas. Grosssteil Uralthardware, die Firewalls sind Haswell, die ESXi Broadwell-E mit 256 GB Ram und 22 Core CPU, Backupserver Broadwell-E mit 128 GB und 16 Core CPU. Alles DC Hardware, inkl. dem Storage. Habe auch die meisten Teile auf Ersatz, falls was abraucht.

Nun bin ich eine Multi Teant Anwendung am bauen. Da habe ich mir eine Entwickler VM auf der WS aufgesetzt, da laufen drei lokale Server drauf (auf 3 verschiedenen Ports), auf dem ESXi eine VM für git, und drei "produktive" VM für mein Backend, Backend-Kunde und Webfrontend. Atm bin ich noch in einer frühen Entwicklungsphase. Aber bin ganz begeistert, was mir der gute Claude alles raus haut. Mein persönliches Backend ist eine Laravel Installation, das ist nur lokal erreichbar. Das Kunden-Backend ebenfalls Laravel based, das ist nur per VPN erreichbar, und da mache ich dann gelockte Tablets für die Kunden. Das Webfrontend ist ein Keyhelp Server, ebenfalls mit Laravel. Das Webfrontend hängt hinter einem Reverse Proxy auf der OPNsense, welche ACME Challange und sowas macht. Funktioniert schon erstaunlich gut für meine bescheidenen Verhältnisse.

Wenn ich die ersten Kunden darauf los lasse, wird das mal auf meinem persönlichen Rig laufen gelassen. Die Kunden werden informiert, dass ich zwar eine Semi Pro Ausrüstung habe, und nach bestem Wissen und Gewissen arbeite. Aber halt keine 100% Ausfallsicherheit gewährleistet werden kann.

Wenn man das dann aber richtig startet, dachte ich mir, suche ich mir einen Partner, der das vertreibt und das Geschäftliche regelt. Dann würde ich bei mir einen kleinen Proxmox Cluster hin stellen, und bei meinem Geschäftspartner ein zweites Standbein machen, wo alles hin gespiegelt werden soll. Die Anwendung selber frisst kein Heu. Die Kunden dürfen nur ganz kleine Bilder hochladen, denke pro VM reichen 100 GB, bzw. 300 fürs Webfrontend. Die beiden Cluster dann hinter Cloudflare. Fällt ein Standort aus, gehts am zweiten Standort weiter.

Würde das mit kleinen Rechnern zusammen bauen. Die sollten ECC, vPro oder gar IPMI haben, aber sonst müssen die nicht viel können. Aber wieviele Hosts der Cluster haben muss, ist noch unklar. Dachte mir, an beiden Standorten 2 kleine Rechner und ein NAS vielleicht. Würde den Grossteil gebraucht kaufen, und selber bisschen schrauben, paar Teile auf Halde legen auf Ersatz. Mit der Taktik bin ich bislang immer gut gefahren. Und darf halt nix kosten, wie immer.

Wie gesagt, das ist alles noch Zukunftsmusik. Wollte mal fragen, was ich da genau benötige, damit man sagen kann, er hat alles menschenmögliche getan, um jede Eventualität abzudecken, und einen reibungslosen Betrieb zu gewährleisten. Wie würdet ihr so einen Cluster aufbauen? Mit Proxmox habe ich bislang nur bisschen Erfahrung vom experimentieren, aber noch nie irgendwie Produktiv im Einsatz gehabt. Schon gar keinen Cluster...

Wie gesagt, das alles steht noch in den Sternen, und wird frühestens in 18 Monaten oder so ein Thema werden. Will nur mal die Lage sondieren, was da auf mich zukommt.

Gruss und danke

 

[Bu66as]

Das Wichtigste: bau da bitte keinen gestreckten Cluster über beide Standorte. Corosync will RTT unter 5ms und redundante Links, über eine normale Internetleitung flappt dir das Quorum und dann frieren dir Nodes ein. Sauberer sind zwei eigenständige Cluster, einer pro Standort, und die Redundanz machst du eine Ebene höher. Pro Standort 2 Nodes plus ein QDevice als Tie-Breaker (corosync-qnetd, läuft auf jedem Kleinstgerät, notfalls auf dem NAS), sonst hast du beim Ausfall eines Nodes kein Quorum und damit gar nichts mehr.

Für die Daten innerhalb eines Standorts ZFS-Replikation zwischen den beiden Nodes (pvesr, z.B. alle 15 min) plus HA, das deckt "ein Node raucht ab" ab. Zwischen den Standorten würde ich nicht VMs spiegeln sondern die Anwendung replizieren, also DB-Replikation und die Uploads per rsync/syncthing. Bei VM-Replikation über die Leitung bist du beim Failover immer 15 Minuten hinterher und beim Zurückschalten hast du Split-Brain. Dazu an beiden Standorten einen PBS und die Backups vom jeweils anderen ziehen lassen (Sync-Job, Pull statt Push, Token nur mit DatastoreBackup). Dann kann ein kompromittierter Standort die Kopie drüben nicht löschen. Prune und GC sind zwei getrennte Ebenen, wenn du nur am Backup-Job schraubst wächst der Datastore trotzdem weiter.

Bei der Hardware: ECC und echtes IPMI zusammen wird bei Mini-PCs schwierig, vPro ist kein Ersatz wenn die Kiste wirklich hängt. Gebrauchte 1HE-Kisten oder kleine Xeon-D-Boards mit ASPEED-BMC sind da meist die bessere Wahl. Und was mehr bringt als ein weiterer Node: den Failover regelmäßig üben, sonst merkst du erst im Ernstfall dass irgendwo ein DNS-TTL oder eine Firewall-Regel im Weg steht. Was ist denn dein Ziel bei RTO/RPO, also wieviel Ausfall und wieviel Datenverlust darf es im schlimmsten Fall sein? Daran hängt eigentlich das ganze Design.

 

[MarroniJohny]

Ja, danke. Muss ganz ehrlich sagen, dass ich nur die Hälfte verstanden habe. Das mit Quorum hat mir die KI eben auch erklärt, dann halt drei kleine Rechner pro Standort, das macht den Braten auch nicht mehr fett.

Glaube wenn ich wen habe, bei dem man einen zweiten Standort einrichten kann, habe ich höchstens einen Ping von 4 ms. 4 ms habe ich schon bei meinen Flugsimulatoren die ich hoste, zu meinem Kumpel, und der lebt auf der anderen Seite der Alpen. Und ich nutze (muss) noch VPN, brauche ich leider systembedingt für die STUN/TURN/Hole Punching Applikationen, weil mein jetztiger Provider ganz mieses Routing hat, und die Server hinter doppelt NAT hängen. Aber der Provider wird noch gewechselt, dann fahre ich direkt mit WAN in die Sense. Bzw. auf den Switch, der macht dann noch den Mediaconverter für WAN.

Ja dachte auch, dass ich da DB Replikation neben ZFS Storage Replikation oder so mache. Aber keine Ahnung wie. Und wenn mal ein Bildchen verloren geht, ist das nicht weiter tragisch. Das kann ja der Kunde dann nochmal neu hochladen. Bin da mehr ambitionierter Hobby Bastler als echter Profi, muss ich dazu sagen.

1 HE Maschinen kommen leider nicht in Fraage, zumindest an meinem Standort. Musste hier schon alles in (Gaming-) Tower rein schrauben, damit der Lärmpegel erträglich bleibt.

Aber jetzt ohne mal zu gross in die technischen Details zu gehen: kann ich da nicht irgendwelche OEM Büchsen mit vPro nehmen? Wenn so eine Kiste wirklich mal einfriert, muss man halt hin laufen, und den Power Schalter betätigen. Habe da nicht wirklich Lust, an beiden Standorten richtige Serverhardware mit IPMI hin zu stellen. Gerade wegen der Ausfallsicherheit habe ich ja mehrere Hosts pro Standort.

Und sind wir ehrlich. Geht um eine Lieferdienstsoftware für Restaurants. Die Anwendungen dürfen sich natürlich auf keinen Fall verschlucken. Bin auch am testen, was passiert, wenn eine der VM offline ist. Wenn z.B. das Kunden-Backend offline ist, kann man am Webfrontend keine Bestellungen mehr abschicken. Ich kann Kunden sperren wenn die nicht bezahlen. Die Website wird dann gesperrt, bis ich die wieder freischalte. Sowas bin ich bereits am implementieren. Da darf aber natürlich keine Bestellung verloren gehen. Habe z.T. auch Cron Jobs eingerichtet, welche die DBs syncen noch, falls ein Host nicht antwortet.

Aber wenn ich mir da gewisse Mitbewerber anschaue, dürfte mein System da schon bisschen mehr Redundanz bieten. Habe da diverse Websites angeschaut. Die nutzen zum schönen Teil Wordpress mit Plugins, das ist zu meinem System dann echt ein Murks...

 

[Bu66as]

Mit drei Nodes pro Standort bist du das QDevice-Thema los, das reicht fürs Quorum. Und ja, OEM-Geräte mit vPro sind völlig okay, wenn du eh drei Hosts hast. Der BMC ist hauptsächlich dafür da, dass du remote hart aus- und wieder einschalten kannst, und AMT kann das auch. Vergiss nicht, AMT ordentlich zu konfigurieren: eigenem Passwort, nur im Management-Netz, nicht am Internet. Das Ding ist ein vollwertiger Zugang, pass auf damit. ECC und vPro findest du am ehesten bei Workstation-Systemen mit Xeon oder W-Chipsatz, normale Business-Desktops haben meist kein ECC.

Bei 4 ms Latenz ist der durchschnittliche Ping gar nicht das Problem – eher Jitter und wenn die Leitung kurz weg ist. Corosync ist da empfindlich und braucht einen zweiten, physisch getrennten Ring, den du über eine WAN-Strecke nicht hin kriegst. Selbst wenn es liefe, hättest du beim Leitungsausfall trotzdem einen Standort ohne Quorum. Zwei getrennte Cluster sind einfach robuster.

Bei dir ist aber wichtiger als der ganze Cluster-Kram: "es darf keine Bestellung verloren gehen" löst dir kein Hypervisor. Wenn dir während einer Bestellung ein Node abraucht, startet HA die VM drüben neu, das dauert ein paar Minuten und alles was nicht in der DB war ist weg. Das muss die Anwendung abfangen, also Bestellung sofort persistent schreiben und Wiederholungen dürfen keine Doppelbestellung machen. Bei deinen Cron-Jobs, die die DBs syncen wenn ein Host nicht antwortet, würd ich aufpassen. Sobald beide Seiten schreiben dürfen, wirds konflikt-anfällig und hast du schwer wieder Ordnung rein. Besser, ein Standort ist primär, der andere nur lesend, und umschalten machst du manuell. Was läuft denn unter Laravel, MariaDB oder Postgres? Beide haben native Replikation, das ist verlässlicher als eigene Skripte.