Sollte ich für diesen Anwendungsfall Proxmox verwenden?

Sollte ich für diesen Anwendungsfall Proxmox verwenden?

Ich muss also grundsätzlich eine Webanwendung hosten, die komplett auf PHP basiert, und außerdem eine MySQL-Datenbank mit HA.

Es wird zwei Server in verschiedenen Rechenzentren geben.

Und ich überlege, ob wir Proxmox mit zwei VMs verwenden sollten, eine für die Webanwendung und eine andere für die Datenbank.

Oder ob ich einfach Debian installieren und alles zusammenfügen und damit fertig sein soll.

HA für den Webserver wird von einer HaProxy-Instanz verwaltet, die sich auf einem anderen Server befindet. Datenbank-HA wird von ProxySQL in HA verwaltet (der MysQL-Server und ProxySQL befinden sich also im Grunde auf demselben Server), aber meine Anwendungen müssen wissen, mit welchem ​​ProxySQL sie sich verbinden sollen.

Wenn ich Proxmox verwende, ist dies mit Keepalived ziemlich einfach, da alles interne IPs verwendet und alles in Ordnung ist.

Aber wenn ich Debian verwende, sind es die öffentlichen IPs, und das Hosting, das ich verwende (OVH), hat etwas, das dies ermöglicht, sogenannte Floating IPs. Die Umstellung dauert jedoch etwa 5 Minuten, sodass die Site 5 Minuten lang nicht erreichbar ist.

Die Verwendung von Proxmox bietet mir noch weitere Vorteile: Ich kann Server hochfahren, um Upgrades durchzuführen und dann einfach wechseln usw., ohne dass etwas kaputt geht. Die Verwendung von Debian impliziert direkt eine Neuformatierung des Servers usw.

Und natürlich wird die Leistung durch die Verwendung von Proxmox leicht beeinträchtigt, aber ich denke, das ist vernachlässigbar.

Beide Lösungen haben Vor- und Nachteile und ich bin mir nicht wirklich sicher, in welche Richtung ich gehen soll.

Also Virtualisierung oder Bare Metal?

Die Server sind:

CPU: Xeon-E 2288G - 8c/16t
Memory: 32GB
Disks: 2× 960GB SSD NVMe - RAID 1

Irgendwelche Ideen? Danke!

Antwort1

Ihre Begründung für die Verwendung von Proxmox scheint hier zu sein, dass Sie Keepalived verwenden können (obwohl ich nicht genau weiß, wofür). Das scheint ein massiver Overkill zu sein.

Es gibt noch andere Gründe, die in diesem Zusammenhang Sinn machen könnten und auf die Sie hingewiesen haben.

Sie erwähnen auch die Floating IPs von OVH.

Dies ist das XY-Problem.

Ihr Hauptanliegen scheint darin zu bestehen, sicherzustellen, dass (mindestens einer) der Dienste über eine virtuelle IP verfügbar ist.

  • Virtuelle IPs funktionieren über Rechenzentren hinweg nicht ohne eine ausgeklügelte Routing-Konfiguration. Komplexität ist schlecht.

  • Virtuelle IPs als HA-Mechanismus sind Mist. Sie verlassen sich darauf, dass Ihr Systemetwaswenn es in einem defekten Zustand ist. Es gibt Komplikationen rund um Split Brain. Es ist schwierig zu testen/überwachen. Es kommt immer zu einer Unterbrechung des Dienstes.

  • Sie benötigen keine virtuelle IP – wenn ProxySQL (oder haproxy oder ähnliches) auf jedem Knoten verfügbar/konfiguriert ist, der eine Verbindung zur Datenbank herstellen muss, und alle Datenbankknoten kennt, haben Sie HA für Ihren Datenbankdienst. Für den HTTP-Dienst ist der Schlüsselteil von HA Round-Robin-DNS-Adressen über mehrere Hosts hinweg. NB: Es gibt im Internet immer noch viele Fehlinformationen über rrDNS und HTTP. Es behandelt Fälle, die ein Load Balancer nicht bewältigen kann, und behandelt die meisten Anwendungsfälle, die ein Load Balancer abdeckt.

Der größte Kostenfaktor bei der Verwendung von Virtualisierung in einem solchen Kontext ist der DBMS-Festplatten-E/A. Wenn die MySQL-Leistung einen erheblichen Einfluss auf die Gesamtleistung des Dienstes hat und Ihr Budget dies zulässt, können Sie dieses Problem beseitigen, indem Sie einen dedizierten Festplattencontroller und Speicher an die DBMS-VM weitergeben.

verwandte Informationen