Wasserdichtes System für kleine Multi Teant Anwendung

MarroniJohny

Member
Feb 29, 2024
54
1
13
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
 
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.
 
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...
 
Last edited:
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.
 
Auf MariaDB läuft das. Bevor ich da einen Linux Cluster baue, werde ich das mal auf meinen ESXi rennen lassen für 10 Testkunden, so das erste Ziel. Da muss ich dann schauen, wie ich die DBs synchronisiere. Gehört also nicht direkt in das Forum hier.

Aber würdest Du das auf Anwendungsebene einbauen, oder reichen da externe Mechanismen?
 
Bei Datenbanken IMMER auf Datenbankebene und bei Anwendungen immer auf Anwendungsebene, soweit möglich. HA im Hypervisor sehe ich eher als Notlösung, da die nicht zwingend Konsistenz und Transaktionssicherheit garantiert, die der Datenbank sollte das dagegen schon. Und in der Anwendung integrierthat man das dann immer auf die Anwendung abgestimmt und nicht als Vendor-L9ckin beim Hypervisor.

Veeam-Opfer/-Kunden haben bei dem Ansatz allerdings das Problem, dass dieses "Enterprise-Backup" nur bei MS-SQL Sicherung von Clustern unterstützt. Da wäre mein Vorschlag sich doch bitte eine andere Backupsoftware zuzulegen ;)

Generell: Wenn du @Bu66as Erklärungen nur zur Hälfte verstehst, würde ich mir noch mal überlegen, ob du deine Infrastruktur nicht lieber durch jemand anderen, z.B. in der Cloud betreiben lässt. Ob das dann ein Dienstleister oder Admin ist, müsstest du dir überlegen. Schon die Idee mit mini-pcs ist abenteuerlich und das ist noch freundlich ausgedrückt.
 
Last edited:
Externe Mechanismen, ganz klar. MariaDB kann das selber, asynchrone Replikation mit GTID brauchst du in Laravel nicht einbauen. Auf dem Primary Binlog an (log_bin, gtid_strict_mode=1), auf der Replica read_only=1, dann kann keiner aus Versehen auf der Replica schreiben. Nach einer Leitungsunterbrechung holt die Replica per GTID automatisch nach, solange die Binlogs auf dem Primary noch da sind. Die Binlog-Retention sollte großzügig ausfallen (expire_logs_days), sonst musst du die Replica neu synchronisieren. Galera über WAN würd ich nicht machen, synchroner Multi-Master mag keinen Jitter und jeder Commit wird auf die Leitungslatenz gebremst.

Im Code musst du dich eigentlich nur um Idempotenz kümmern, dass eine Bestellung bei Retry nicht zweimal in der DB landet. Schreib eine eindeutige ID vom Client mit und leg einen Unique-Constraint drauf, das reicht. Für die IDs entweder UUIDs oder pro Standort verschiedene auto_increment_offset-Werte, sonst kollidiert dir das beim Umschalten. Laravel kann read/write in der database.php trennen, damit kannst du lesende Queries später auf die Replica verschieben, ohne im Code was zu ändern.
 
Danke für Eure Einschätzung.

Ja, sehe schon, habe da ein strukturelles Problem. Atm. liegen die DBs auf den Apllikations VMs. Claude meinte erst, ich solle die DBs bei den VMs lassen, aber auf ein eigenes ZFS Dataset nehmen, was von ZFS Snaps ausgenommen wird. Habe aber schlechte Erfahrungen mit mehreren VMDK pro VM gemacht, bei Storage Umbau, Distr Upgrades und so. Hatte mal eine Plesk VM, wo ich für Backups eine zweite Platte angehängt hatte. Das wurde mehrfach zum Problem. Bin dann dazu übergegangen, für die Plesk Backups einen kleinen Filer zu betreiben, und habe das dann per SMB gelöst.

Ich tendiere atm dazu, die drei DBs der Anwendungen auf einen separaten DB Server zu nehmen. Glaube das würde vieles vereinfachen. Was meint Ihr dazu?
 
Ich tendiere atm dazu, die drei DBs der Anwendungen auf einen separaten DB Server zu nehmen. Glaube das würde vieles vereinfachen. Was meint Ihr dazu?
Ich weiß es nicht, weil ich dafür keine ausreichende Erfahrung habe. Und Claude oder sonsteine KI ohne Hintergrundwissen zu fragen, wird nur auf "Garbage in/Garbage out" hinauslaufen, also lasse ich das. Dir würde ich das Gleiche raten.
 
Ja, jetzt mach mal halblang. Meinst Du, ich gebe die Anwendung jetzt auf, weil ich mir noch nicht im klaren bin, wie ich Anwendung von DB entkopple storagemässig? Schön, dass Du es dabei belässt, aber schliesse dabei nicht auf mich, danke. Und dass ich absolut kein Hintergrundwissen habe, interpretierst Du jetzt einfach mal rein, ohne meinen Background zu kennen.

Ist das Deine Art von Problemlösung? Habe keine Ahnung, Du auch nicht, also lass es mal besser? Genau mit solchen Anfeindungen kann man wunderbar einen Thread ins aus katapultieren. gz

Was meinst Du eigentlich, wieso ich hier frage, wie ich meine Anwendung wasserdicht mache? Um von Dir zu hören, lass es mal besser? Ja genau von solchen Antworten lebt ein Forum.
 
Last edited:
Ich will dir wirklich nicht zu nahe treten, aber für mich wirkt es halt so, als ob du irgendeine geschäftliche Anwendung auf suboptimaler Hardware ohne Vorkenntnisse mit KI-Hilfe zusammenfrickelst und alle auftretenen Fragen mit Forumshilfe lösen willst. Das kann man machen, wenn es Leute gibt, die das kaufen, why not? Aber ich würde nicht als Kunde so ein System nutzen wollen und auch nicht von anderen Leuten dafür Geld nehmen.

Wenn ich das falsch einschätze, tut mir das Leid, aber das ist halt der Eindruck, den ich habe und sowas möchte ich nicht unterstützen.
 
Ja, will es schon sauber aufziehen. Habe da mal paar meiner "Mitbewerber" angesehen. Denen würde ich ehrlicherweise auch näher legen, es besser zu lassen mit ihren WP Templates und Plugins. Und gibt da sicher auch noch bessere Systeme. Glaube schon, dass ich sowas - nach bestem Wissen und Gewissen - aufziehen kann. Wird den ersten 10 Kunden auch klar so mitgeteilt, dass ich semi Pro Hardware habe (siehe Post #1...), dass das als Testbetrieb zu verstehen ist, und sich das ganze im Aufbau befindet. Aber einen gewissen Anspruch an die Qualität der Anwendung habe ich halt doch, obwohl die zugegebenermassen KI Code ist. Lüppt verdächtig gut für meine Verhältnisse...

Sry, wenn das bisschen pampig rüber kam. Aber zähle mich da eher bei der Sorte Mensch, geht nicht, gibts nicht.

Werde auch in absehbarer Zeit mein ganzes Netzwerk umbauen, gibt neuen Provider mit /29 Subnet hoffe ich, da sind atm. 17 VLANs geplant und auch auf der Lab Sense schon implementiert. Läuft alles parallel, aber halt noch ohne den neuen Provider, da das Kleingeld immer bisschen knapp ist. Für die Bestellsoftware gibt es dann noch weitere Netze.

Mein Kumpel meinte nur, ja schalte doch mal die ersten Kunden auf, und schau, wie es läuft. Mache ich aber nicht, weil es beim Netzwerk- und Strom Neuaufbau wohl zwei Tage downtime geben wird, und ich da schon genug am Hals haben werde, und meine weitaus weniger wichtigen Sachen wieder zum laufen zu kriegen. Könnte das jetzt noch weiter ausführen, aber hat ja nichts mit dem Thema zu tun.

Und was soll an meiner Hardware suboptimal sein? Zumindest welche ich atm verwende? Beide Server overpowered Xeons mit RDIMM/LRDIMM, alles DC SSD und HDD, extra die super teuren neuen PSU verbaut? 10 Gbit Anbindung mit fixer IP, und so? Und alle Teile doppelt und dreifach auf Ersatz? Selbst die WS hat RDIMM... Habe ich im Post #1 ja angedeutet. Auch die Firewalls haben Xeons und ECC, auch Grossteil dreifach vorhanden. Also nach mir ist für die ersten 10 Kunden mein Rig ausreichend, durchaus. USV gibt es halt nicht, weil mir mal so ein Mistding gefackelt hat. Und die kann auch einfach mal so aussteigen.

Da würde sich so macher Handwerksbetrieb die Finger lecken nach so einer Infrastruktur. Zähle mich nicht zu der Sorte Hoster oder Betrieb, welche Ihre IT auf Consumer Hardware laufen lassen, und alles an der Fritzbox hängt, nach dem Motto, ja passt schon.

Vielleicht solltest Du also Deine Meinung revidieren, bevor Du mir damit kommst, lass es besser mal. Und wenn Du das nicht unterstützen möchtest ist das dein Ding, damit ist mir aber halt nicht weiter geholfen. Und wie gesagt, zieht halt meinen Thread runter.

Und wenn Du meinst, dass man sich im Forum (oder bei der bösen KI) keine Hilfe holen sollte, müsstest Du es vielleicht einfach besser lassen, hier zu posten. Wozu ist das Forum eigentlich da? Schon klar, Du wusstest das alles schon von Geburt an, Du brauchst keine Hilfe. Das gilt aber nicht für mich...

Hmm, habe mir jetzt nochmal Post #1 angesehen. Keine Ahnung, ob Du den im Hinterkopf hattest, bevor Du mich da anzündest von wegen "suboptimaler Hardware" und "keine Ahnung, lass es mal besser" und schlussendlich "Garbage in/Garbage out" "mich dünkt das so."

Und hatte bei den OEM mini Rechner noch nicht mal angesprochen, was ich da gedenke für Datenträger bzw. Storage zu verwenden, obwohl ich da total auf die DC Dinger mit PLP stehe. Anforderung war umrissen mit ECC und mindestens vPro. Aber schon klar, geht gar nicht...
 
Last edited:
Zur Frage aus #8: separater DB-Server, würd ich machen. Du hast die Replikation dann an einer Stelle statt in drei VMs, und Backup/Restore ist auch deutlich weniger Gefummel. Dein VMDK-Problem von damals ist damit auch weg.

Das Risiko ist ein single point of failure - steht die DB-VM, stehen auch alle Apps hin. Also die VM dann auch wirklich absichern, Replica am zweiten Standort mit read_only=1, und den Restore solltest du vorher einmal durchspielen.

Da gibt's zwei Fallstricke: Die Apps reden lokal über Unix-Socket, danach über TCP. Du brauchst dann die richtigen Grants auf den App-Hosts und in Laravel sollten die Timeouts passen, sonst hängt dir bei nem Netz-Hickser der ganze Request. Und leg das DB-Netz so, dass App und DB im selben Segment sind. Falls die DB hinter ner Firewall mit Inter-VLAN-Routing läuft, kostet das bei vielen Queries mehr als man denkt.
 
  • Like
Reactions: MarroniJohny
Ja, auch Dir danke für Deine Meinung und Deine unendliche Mühe hier im Thread. Bringst mich echt weiter, muss man Dir lassen. Hat da auch tatsächlich User hier die weiter helfen. Auf Deinen Senf hingegen kann ich gerne verzichten!

Habe jetzt eine Alfa Version, die funktioniert super. Heute mal Backups von allem gezogen, und mache mich jetzt daran, die ganze DB Geschichte (mit KI Hilfe, omg) auf eine separate VM auszulagern. Glaube das macht Sinn. Hatte tatsächlich vor, die Gäste in verschiedenen VLANs laufen zu lassen. Wusste nicht, dass das so zeitkritisch ist. Drum frag ich ja.

Also erst mal alle beteiligten Gäste gesichert, geklont, neue IPs zugewiesen und so. Weiter gehts. Hatte bislang vor allem mit Sonnet gearbeitet. Aber habe mir mal das Claude Max *5 Abo geholt, und lass da mal Opus und Fable drüber schauen.

Schon klar, gewisse Subjekte brauchen sowas nie im Leben. Die dürfen mir gerne fern bleiben mit ihrer rückständigen Art, und bitte meinen Thread nicht weiter vollspamen mit Sachen wie "Du hast Mut, Deine Hardware ist Scheisse, ich habe keine Ahnung, Du noch viel weniger und lass es bitte lieber". Bitte draussen bleiben, ihr stinkt! Habt wohl die Weisheit mit Löffeln gefressen, schon klar, sieht man ja an dem braindead Feedback. Also bitte bitte geht mir aus der Sonne!
 
VLANs kannst du ruhig machen, das war nicht kritisch gemeint. Mir ging's nur drum, dass jede Query zwischen App und DB dann durch die Sense läuft, und wenn ein Seitenaufruf ein paar hundert kleine Queries absetzt, summiert sich der Umweg. Bei nem Bestellsystem mit überschaubarem Traffic merkst du davon vermutlich gar nichts. Sauberer Kompromiss: App und DB ins selbe Segment, und die Trennung machst du nach außen bzw. zwischen den Mandanten-/Frontend-Netzen. Dann hast du die Segmentierung da wo sie was bringt, ohne den Routing-Hop im heißen Pfad.

Wenn du's genau wissen willst, schau dir beim Umbau einfach die Query-Zeiten in der Laravel Debugbar vorher/nachher an, dann siehst du direkt ob es überhaupt eine Rolle spielt. Und denk beim Umzug dran, dass localhost in der .env auf Unix-Socket geht, 127.0.0.1 auf TCP. Wenn du auf die neue DB-VM zeigst, musst du die Grants entsprechend auf den App-Host statt auf localhost setzen, sonst rennst du in Auth-Fehler die erstmal komisch aussehen.
 
  • Like
Reactions: Johannes S
Auf Deinen Senf hingegen kann ich gerne verzichten!
Praktisch alle hier wollen dir helfen. Und das sogar kostenlos. Jeder hier hat unterschiedliche Erfahrungen und Kenntnisse. Empfehlungen fallen daher immer unterschiedlich aus, je nachdem, wen man gerade erwischt hat.

Du darfst beliebige Posts komplett ignorieren. Du solltest dich - meiner Meinung nach - aber eher nicht abwertend äußern. Und wenn du einen Namen anklickst, findest du auch einen "Ignore"-Knopf. Welchen Effekt der hat, ist mir allerdings gerade unklar.

Bedenke bitte auch, dass Feinheiten wie Ironie/Sarkasmus in Textform fast immer verloren gehen.
 
Last edited:
  • Like
Reactions: Bu66as
Der VPS-Gedanke ist für das zweite Standbein gar nicht so blöd, spart dir drüben den ganzen Strom- und USV-Zirkus und du musst nicht an zwei Orten Hardware pflegen. Ich würd dann aber einen CH- oder EU-Anbieter nehmen, bei dir liegen Kundenadressen und Bestelldaten drin, und das bei einem US-Hoster plus Cloudflare davor will man sich datenschutzmässig nicht antun. Für 4 Dollar kriegst du halt auch kein ECC und keine PLP-SSD sondern shared IO auf einem gut überbuchten Node, das relativiert sich schnell sobald die DB drauf liegt.

Realistisch fände ich für dich: Anwendung primär bei dir auf dem Rig, drüben auf einem kleinen VPS nur die MariaDB-Replica und ein PBS, der sich die Backups per Sync-Job bei dir abholt. Damit hast du Offsite-Kopie und Notfall-Standort, ohne zweiten Cluster. Umschalten dann bewusst von Hand, automatisches Failover über WAN baut dir mehr Probleme als es löst.