Virtualisierung mit ISPConfig unter Debian 9

[Natsu]

Huhu Zusammen,
ich bin aktuell am überlegen, zu ISPConfig umzuziehen. Hier einige Infos:

Aktuell läuft auf dem 4 Kerner (8 Kerne via htop) mit 32 GB DDR 3 RAM Froxlor mit nginx, mysql (bzw. mariaDB), ts3 (mit ATHP Lizenz), Mailserver (postfix + dovecot), proftpd und ein Minecraftserver (4/8 GB als Zuweisung). Hoster ist Hetzner.

Problem ist, dass ich mit Froxlor nicht so arbeiten kann, wie ich es gerne möchte, nehmlich, nebst dem Angebot von TS 3 Servern und Webspace, auch vServer und vorerst Minecraftserver.

Somit dachte ich mir, weg von Froxlor und hin zu ISPConfig. Nun ist mir bekannt, dass es ein großes 3.1 Handbuch gibt, wofür sich die 5,- € sicherlich lohnen werden, es gibt auch Anleitungen (HowTo's), die ich mir angeschaut habe (u. a. HOWTOFORGE-URL-ERSETZEN/tutorial/perfect-server-debian-jessie-nginx-bind-dovecot-ispconfig-3.1/ ), jedoch bin ich mir nicht sicher, ob diese auch auf Debian 9 übertragbar sind, zudem habe ich nun folgende Fragen, die für mich zu klären sind und ein paar FAQ, was ich geplant habe:

Q: Was ist genau mein Plan, für den aktuellen Rootserver?
A: Dieser soll in vServer unterteilt werden, wobei der Datenbankserver (MySql bzw. MariaDB) direkt neben ISPConfig laufen soll und die vServer-Instanzen darauf zugreifen sollen (dies sollte intern möglich sein, andernfalls über die statisch zugewiesene IP in der Netzwerkkonfiguration).

VServer 1 & 2 sind für den Webhostingbereich geplant, benötigen also Zugriff auf den Datenbankserver, wie auch zu einem Mail- und FTP-Server (was nicht das Problem ist, da ich hier postfix und dovecot, sowie proftpd bevorzuge, es gehen aber auch Alternativen) und auch einen Webserver. Nun kann man dem Kunden ja nicht einfach nginx aufzwingen, gerade wegen dieser .htaccess Sache ^^ - also benötige ich entweder vServer 1 & 2 um getrennt nginx/Apache 2 anbieten zu können oder über die Variante mit dem nginx-proxy (noch nicht eingelesen, was dann Pflicht wäre). PHP-Versionen sollen dann von PHP 5 bis PHP 7.1 reichen, aber das ist wohl das geringere Problem.

VServer 3 & 4 ist ausschließlich für Teamspeak 3 da. VServer 3 wäre die Hauptinstanz, wenn diese wegen Wartung down geht, soll vServer 4 übernehmen (oder bei anderen Problemen, z. B. der Erreichbarkeit von vServer 3). In diesem Fall muss ich natürlich irgendwie regelmäßig eine Kopie von vServer 3 auf vServer 4 spiegeln, was die Daten angeht. Da die Datenbank im Hauptsystem liegen soll, muss diese nicht gepsiegelt werden. Das Monitoringscript dafür muss am Ende natürlich feststellen, ob der Hauptserver nutzbar ist oder nicht und wenn ja, soll er die Instanz auf vServer 4 runterfahren und die Instanz auf vServer 3 starten (sonst gibt es ein Lizenzkonflikt, wegen doppelten Server-UIDs und beide Instanzen würden sich abschalten).

VServer 5 wäre der letzte vServer und soll Minecraftserver bedienen, hier jedoch vorerst ohne Failover, denn Minecraft verbraucht Unmengen an RAM (je nach dem, ob Vanilla oder Modded und wie viele Spieler). Darum würde dieser wohl sehr schnell auf einen zweiten Rootserver ausgegliedert werden (der ebenfalls in das zentrale ISPConfig verankert werden soll, um gesteuert werden zu können).

Bis auf vServer 5, sollten alle anderen vServer weitesgehenst ausfallsicher sein (mit Ausnahme der Datenbank, aber dann wäre wohl eh alles offline). Entweder, weil ein zweiter vServer die Arbeit des vorherigen vServers übernimmt oder weil eine Failover-IP zur Umleitung zur Verfügung steht.

Nun ist die Frage, welches Tutorial dies für Debain 9 beschreibt oder ob die Tutorials von Debian 8 bzw. Debian 6 (HOWTOFORGE-URL-ERSETZEN/installing-openvz-plus-management-of-vms-through-ispconfig-3-debian-6.0) ok sind. Auch muss ich gucken, wie ich dann meine Domain richtig implementiere, sodass für alle (v)Server die FQDNs korrekt gesetzt sind (server1 . MeineDomain . de, server2 . MeineDomain . de, ff.) und auch die eventuell zu machenden Änderungen im ZONEFILE bei Hetzner korrekt sind (es werden für alle (v)Server die Hetzner DNS Server genutzt werden, keine eigenen) und dass ich ohne Probleme www . MeineDomain . de nutzen kann (Dummy-URLs mit spaces versehen, werden ja als URL konvertiert -.-).

Ich würde mich über hilfreiche Antworten sehr freuen, da ich nicht eine Woche an dem Setup verbringen will oder alle zwei Tage alles neu aufsetzen muss, wegen etwaigen Fehlern.

Zusatznotiz: SSH werde ich ausschließlich via KeyFile-Authentication einrichten, bei allein Instanzen (4096 bit RAS - DSA, ECDSA stehen mir auch zur Verfügung) und ich setze mich gerade mit tmux auseinander, um nicht pro SSH-User eine PuttY-Konsole zu benötigen, was aber nicht ganz einfach zu sein scheint, wer dieses Tool nutz, bzw. tmuxinator verwendet (Layout) und mir dabei auch helfen kann, einfach eine Notiz hinterlassen und ich melde mich dann mit dem, was mir vorschwebt.

Zwecks IPs für die vServer ... da erwarte ich noch eine Rückmeldung seitens Hetzner, wie ich was zu bestellen habe. Bis zu 6 IPs sollen möglich sein (ungeachtet der RIPE-Richtlinie).

Gruß
Natsu

PS: An die Administration: Schön, dass man bei seinem ersten Post keine Links nutzen darf (wer auch immer diese idiotische Idee hatte). Dies beeinträchtigt gesetzte Referenzen, da der/die Leser nun mehr den Link kopieren und manuell öffnen müssen, was somit zusätzlich aus meiner Sicht die Integrität des Beitrages/Posts beeinträchtigt, gerade wenn man mit Beispielen arbeiten muss. Dies ist meine Meinung dazu, somit bitte ich um die Ersetzung der Non-Links zu korrekten Hyperlinks, danke.

 

[Till]

OpenVZ gibt es nur bis max. Debian 8 da das OpenVZ Projekt seine Kernelentwicklung eingesellt hat. Du wirst also keine VServer unter ISPConfg mit Deban 9 verwalten können bis wir ein komplett neues VM Modul entwickelt haben das nicht auf OpenVZ basiert. Stattdessen kannst Du z.B. Proxmox nehmen zusammen mit dem ISPConfig Proxmox Modul: https://git.ispconfig.org/EXT/proxmox

PS: An die Administration: Schön, dass man bei seinem ersten Post keine Links nutzen darf (wer auch immer diese idiotische Idee hatte). Dies beeinträchtigt gesetzte Referenzen, da der/die Leser nun mehr den Link kopieren und manuell öffnen müssen, was somit zusätzlich aus meiner Sicht die Integrität des Beitrages/Posts beeinträchtigt, gerade wenn man mit Beispielen arbeiten muss. Dies ist meine Meinung dazu, somit bitte ich um die Ersetzung der Non-Links zu korrekten Hyperlinks, danke.

Das ist schlicht einen Notwendigkeit da hier ansonsten ein paar hundert Spam Links pro Tag gepostet werden. Und wir wissen schon welches Tutorial Du meinst wenn Du den Titel des Tutorials postest.

 

[Natsu]

Danke für deine Rückmeldung Till

Ok, also kann ich aktuell auf OpenVZ verzichten. Nicht gerade die besten Neuigkeiten, hilft aber nichts. ^^
Gut, dann werde ich mich mit Proxmox auseinandersetzen müssen oder existiert dafür bereits ein Tutorial? Einlesen muss ich mich ja so oder so am Ende.

 

[Till]

Ich glaube nicht dass es dafür ein Tutorial gibt, zumindest nicht auf Howtoforge.

 

[Natsu]

Ok, das ist natürlich schade.
Hab zugleich mal etwas gegooglet und hab interessante Sachen gefunden, die ich aber in einem Doppelpost ergänzen werde, wegen der Link-Geschichte. ^^

 

[Natsu]

Gefunden habe ich dieses Tutorial (einfach das englische auf deutsch übersetzt): https://www.taste-of-it.de/proxmox-ve-5-0-auf-debian-9-stretch-installieren/

Nun ist die Frage, ob ich danach einfach ISPConfig installieren kann oder nicht und ob es notwendig ist, die Bridge zuvor anzulegen oder nicht.
Kann ich https://www.howtoforge.com/virtual-...ns-servers-on-debian-squeeze-with-ispconfig-3 als Vorlage nutzen? Hier kommt es am Ende drauf an, was davon verwendet werden kann und was nicht, nur fehlt mir leider die Zeit, um alles ausgiebig zu testen (abgesehen von den IPs für den Test), da ich nur über einen Rootserver verfüge.

 

[HSorgYves]

Wieso nimmst Du nicht das Debian Stretch Tutorial für ISPConfig? Du brauchst kein Multiserver Tutorial, wenn Du eh nur einen Server zur Verfügung hast. Notfalls kannst Du immer das Upgrade Script von ISPConfig ausführen, wenn Du was in der falschen Reihenfolge installiert hast.

 

[Till]

Soweit ich es sehe verbindet sich das plugin ja per IP / hostname mit proxmox. ISPConfig muss also garnicht auf dem server installiert sein auf dem proxmox läuft und ich würde es auch gernicht dort installieren sondern in einer vm. Also proxmox auf den server selbst installieren nach welcehm tutorial auch immer, das hat ja nix mit ISPConfig zu tun, dann vm anlegen und dort ispconfig installieren (nach deb9 perfect server) mit proxmox modul und das verbindet sich dann mit proxmox auf dem host.

 

[nowayback]

ist diese ganze aktion hier wirklich durchdacht?

Q: Was ist genau mein Plan, für den aktuellen Rootserver?
A: Dieser soll in vServer unterteilt werden, wobei der Datenbankserver (MySql bzw. MariaDB) direkt neben ISPConfig laufen soll und die vServer-Instanzen darauf zugreifen sollen (dies sollte intern möglich sein, andernfalls über die statisch zugewiesene IP in der Netzwerkkonfiguration).

ok, also wenn diese maschine platt ist/nicht erreichbar/etc. können auch vserver1 und vserver2 nichts mehr tun?

Nun kann man dem Kunden ja nicht einfach nginx aufzwingen, gerade wegen dieser .htaccess Sache ^^ - also benötige ich entweder vServer 1 & 2 um getrennt nginx/Apache 2 anbieten zu können oder über die Variante mit dem nginx-proxy (noch nicht eingelesen, was dann Pflicht wäre).

Version 2: nginx verweigert den dienst, apache ist nicht mehr zu erreichen?

VServer 3 & 4 ist ausschließlich für Teamspeak 3 da. VServer 3 wäre die Hauptinstanz, wenn diese wegen Wartung down geht, soll vServer 4 übernehmen (oder bei anderen Problemen, z. B. der Erreichbarkeit von vServer 3).

Wenn vServer3 und vServer4 auf der gleichen Maschine hängen, hängen sie meist auch am gleichen Netz... Wenn es da Probleme mit der Erreichbarkeit gibt, sind beide gleich betroffen. Ebenfalls wenn du den Host rebootest.

Da die Datenbank im Hauptsystem liegen soll, muss diese nicht gepsiegelt werden.

Damit sind wir wieder bei 1. db nicht erreichbar sind 2 TS server nutzlos

Bis auf vServer 5, sollten alle anderen vServer weitesgehenst ausfallsicher sein (mit Ausnahme der Datenbank, aber dann wäre wohl eh alles offline). Entweder, weil ein zweiter vServer die Arbeit des vorherigen vServers übernimmt oder weil eine Failover-IP zur Umleitung zur Verfügung steht.

Wenn dir dein Blech ausfällt ist Ruhe. Da ist nichts ausfallsicher und irgendwelche Platten/Rams/Kühler/Netzteile müssen ab und an einfach mal getauscht werden und soweit ich weiß sind die wenigsten Server die man mieten kann bei Hetzner auf Redundanz ausgelegt.

Zwecks IPs für die vServer ... da erwarte ich noch eine Rückmeldung seitens Hetzner, wie ich was zu bestellen habe. Bis zu 6 IPs sollen möglich sein (ungeachtet der RIPE-Richtlinie).

Bei dem was du hier vorhast reichen 2 IPs (weil apache und nginx beide auf Port 80). Den Rest kann man alles via NAT abbilden.

Mein Post soll keine Kritik sein, sondern eher dazu anregen nochmal drüber nachzudenken ob und was du wirklich aufbauen willst und brauchst. Das was du nämlich eigentlich vorhast ist ein Setup für das 3-4 Bleche benötigt werden, im Idealfall an 2 Standorten, und die sollten nen ziemlich schnelles internes Netz haben zum spiegeln.

Grüße
nwb

 

[vikozo]

Also ich habe auf meiner Hardware Proxmox Installiert.
Unter Proxmox ein Debian ISO file als template integriert.
Unter Proxmox einen Virtuellen Server erstellt für Debian.
Debian Installiert
und dann gemäss dem Howto Tutorial ISPConfig installiert.

 

[Natsu]

Wieso nimmst Du nicht das Debian Stretch Tutorial für ISPConfig? Du brauchst kein Multiserver Tutorial, wenn Du eh nur einen Server zur Verfügung hast. Notfalls kannst Du immer das Upgrade Script von ISPConfig ausführen, wenn Du was in der falschen Reihenfolge installiert hast.

Weil ich dann immer alle Services runterfahren müsste, jedoch per Multiserver gezielt das ausschalten kann, was aktuell gewartet werden muss.

@nowayback - Mit NAT müsste ich mich auseinander setzen, das habe ich noch nicht getan. Und für mich ist es durchdacht und Hetzner hat 100%ig eine Redundanz, ich habe ein RZ von denen besichtigen können, glaube das RZ in Falkenstein war es gewesen.

Es ist klar, dass, wenn die Hauptkiste down geht, auch alle VMs down sind. Was den Webserver angeht ... wenn ich dies auf zwei vServer trenne und nicht den nginx-proxy benutze, dann ist es dem apache egal, ob der nginx abraucht oder nicht, umgekehrt ebenfalls. Wäre dann zwei eigenständige vServer für das Webhosting.

Bei der TS3-Geschichte kann man noch mal überlegen, wie man das ganze spiegeln kann, andernfalls gibt's keine DB, sondern lediglich Ausweichserver, die auf Adresse und Port lauschen, damit man sich noch unterhalten kann (natürlich fehlen dann u. a. Rechte und Dateien, aber man kann sich immerhin noch unterhalten).

Fazit ist, dass das Setup nicht für 3-4 Blechs gedacht ist, sonst wäre jeder vServer Weltweit ja Schwachsinn, da immerhin ettliche vServer auf Rootservern laufen (manchmal auch viel zu viele auf einen, aber soll egal sein, an dieser Stelle ^^). Wenn da das Wirtssystem down geht, ist auch bei diesen VMs das Licht aus, was im Grunde ja das selbe wäre, nur wer braucht rein für TS 3 einen Root mit 32 GB RAM? Ich nicht, das meiste frisst bei mir der MC-Server.

Soweit ich es sehe verbindet sich das plugin ja per IP / hostname mit proxmox. ISPConfig muss also garnicht auf dem server installiert sein auf dem proxmox läuft und ich würde es auch gernicht dort installieren sondern in einer vm. Also proxmox auf den server selbst installieren nach welcehm tutorial auch immer, das hat ja nix mit ISPConfig zu tun, dann vm anlegen und dort ispconfig installieren (nach deb9 perfect server) mit proxmox modul und das verbindet sich dann mit proxmox auf dem host.

@vikozo - Ok, wenn sich das Plugin per IP/Host verbindet, macht es mehr sinn, wie Ihr es geschrieben habt.

 

[wotan2005]

Das RZ selber hat Redundanzen, aber was bringt die Ausfallsicherheit, wenn der Single-Point-off-Fail dein einziges Blech ist, stimmt rein gar nichts! Das was du hier beschreibst, nennt sich Ausfallsicherheit und die hast du nun mal nicht mit NUR einem Blech.

Richtig wäre es wen du mindestens zwei mal Blech nimmst und dann entsprechend verteilst:
Blech 1 in RZ1)
ispConfig Masterserver
vserver1
vserver3
vserver5 DB Master-Master

Blech 2 in RZ2)
vserver2
vserver4
vserver6 DB Master-Master

nun kann ein komplettes RZ ausfallen und deine Dienste sind immer noch erreichbar. Genau das ist die Interpretation deines Vorhabens.

 

[nowayback]

Fazit ist, dass das Setup nicht für 3-4 Blechs gedacht ist, sonst wäre jeder vServer Weltweit ja Schwachsinn, da immerhin ettliche vServer auf Rootservern laufen (manchmal auch viel zu viele auf einen, aber soll egal sein, an dieser Stelle ^^). Wenn da das Wirtssystem down geht, ist auch bei diesen VMs das Licht aus, was im Grunde ja das selbe wäre

Du noch viel lernen musst kleiner Padawan ;-)
Setz dich mal auseinander mit echten FailOver- und HA- Clustern... Da geht keine VM down. Da ist es vollkommen egal ob mal ne Kiste abraucht oder ein Uplink platt ist. Da können sogar Switche abrauchen ohne das du was davon merkst.

Wie gesagt, für mich ist dein Setup, so wie du es geschrieben hast, völliger Blödsinn.
Nehmen wir mal deine letzte Aussage: Du sagst der 2. TS ist dann halt ohne Rechte, ohne Dateien und logischerweise auch ohne Lizenz. Wie willst du denn da alle Leute draufbekommen? Und glaubst du wirklich jemand geht dann auf nen anderes TS wo etliche andere sind und er nirgends seine Ruhe hat weil auch niemand Rechte hat um Regeln durchzusetzen? Völliger Quark. Davon abgesehen ist mir noch kein TS Prozess einfach abgeraucht sodass dieses Scenario jemals hätte eintreten können. Entweder es gibt Probleme mit der Anbindung (DDoS & Co.) oder Probleme mit dem Host. In beiden Fällen hilft ein zweiter TS auf der gleichen Maschine überhaupt nichts. Für die Zeit eines Reboots wird auch kein User nen TS Server wechseln, denn so ein Reboot dauert bei mir unter 30 Sekunden. Da haben User gerade mal gemerkt das nix mehr geht und es noch nicht mal geschafft ins TS zu wechseln...
Sollte reichen für den TS Kram... Kommen wir zur Redundanz...
Redundanz ist etwas was von ganz groß bis ganz klein vorhanden sein muss, ansonsten sind all das SPoFs (Single Point of Failure). Natürlich hat Falkenstein eine redundante Stromversorgung und auch mehrere Leitungen. Dein gemieteter Server hat aber wahrscheinlich nur ein Netzteil und eine Netzwerkkarte. Knall nun dein Netzteil weg, bringt dir die redundante Stromversorgung des RZ gar nichts. Gleiches gilt für die NIC. Das sind dann deine SPoFs - um mal nur 2 zu nennen.
Webserver? Nagut:
Wenn du eine VM mit Apache aufsetzt und eine VM mit nginx und keine als Reverse-Proxy oder Backup für den anderen dient kann man das tatsächlich machen um Kunden die Auswahl zu ermöglichen. Das ist aber nicht das Problem was du damit hast, denn was läuft denn auf Webservern? Richtig Anwendungen bei denen häufig Datenbanken zum Einsatz kommen. Diese Datenbank hast du aber auf die ISPConfig Instanz gepackt, die dir im Fehlerfall 2 nutzlose Webserver zurücklässt. Die billigste Lösung wäre einfach je eine DB auf die Webserver VMs, aber da geht es langsam aber sicher auf Performanceengpässe zu. Außerdem nimmst du dir damit die Möglichkeit das Kunden zwischen Apache und nginx switchen können. Also müsste ne Replikation zwischen beiden DBs her und da gehts irgendwann auch auf den Plattenplatz, die Bandbreite und die Geschwindigkeit der Platten. Ach ja und 2 zusätzliche DB Server benötigen auch 2x RAM,.... und selbst wenn du auch das hinbekommst kann immernoch die Umgebung verhindern dass beide VMs erreichbar sind, die Replikation fehlschlägt, Emails sind noch nicht gesynct,...
Ich kann dir hier tausende Gründe und Lösungen aufzeigen, aber all das ändert nichts daran, dass deine Idee nicht durchdacht ist.

Stell DIR die Frage was du wirklich brauchst und wie schlimm ein Ausfall von irgendetwas für einen definierten Zeitraum ist. Ein guter Zeitraum sind in der realen Welt maximal 2 Stunden und dann bekommt schon irgendjemand mächtig Schläge ;-)

Wenn du Hilfe dabei brauchst, dann liefer Zahlen, Daten, Fakten. Dann unterstütze ich dich gerne bei der Planung. Hat Hetzner eigentlich in der Zwischenzeit mal ne API bekommen für FO-IPs?

Grüße
nwb

 

[wotan2005]

@nowayback jepp die API für FO-IPs gibt es.

 

[nowayback]

@nowayback jepp die API für FO-IPs gibt es.

danke, hab bei denen schon ewig nichts mehr zu suchen gehabt ;-)

 

[Natsu]

Das RZ selber hat Redundanzen, aber was bringt die Ausfallsicherheit, wenn der Single-Point-off-Fail dein einziges Blech ist, stimmt rein gar nichts! Das was du hier beschreibst, nennt sich Ausfallsicherheit und die hast du nun mal nicht mit NUR einem Blech.

Richtig wäre es wen du mindestens zwei mal Blech nimmst und dann entsprechend verteilst:
Blech 1 in RZ1)
ispConfig Masterserver
vserver1
vserver3
vserver5 DB Master-Master

Blech 2 in RZ2)
vserver2
vserver4
vserver6 DB Master-Master

nun kann ein komplettes RZ ausfallen und deine Dienste sind immer noch erreichbar. Genau das ist die Interpretation deines Vorhabens.

Ok, dann wären also mind. 2 Bleche notwendig dafür. Gut, dann nur die Frage, warum zweimal ein DB Master-Master Server? Eventuell ein typo und der zweite sollte ein DB Master-Slave sein? Ist jetzt nur für das Verständnis, kann mich jetzt auch komplett irren .

Ok, bei 2 Bleche hätte ich pro Blech schon mal eine Haupt-IP. Virtualisierung würde dann via Proxmox laufen, incl. des ispConfig Masterservers nebst dem proxmox-master. Danach richte ich die vServer passend ein, was dann zusätzlich 6 IPs wären (3/Server).

Da das zweite Blech eh in nem anderem RZ stehen würde, würde das also passen. Ich muss dann nur aufpassen, dass ich nichts in den Configs verhaue und am ende auch korrekte ZONEFILES habe für alles. Lese mich auch durch vieles durch atm., nebst anderen wichtigen Sachen ^^.

Danke auf jeden Fall für die Darstellung

 

[wotan2005]

der vserver 5 und vserver6 sind deine DB server welche als Master-Master konfiguriert werden sollten, damit wenn ein Blech ausfällt, deine Anwendungen weiterhin in die DB schreiben können, was bei Master-Slave, wenn der Master ausfällt, nicht möglich ist. Bei Master-Master kann in beide DBs geschrieben werden, bei Master-Slave, wird ausschliesslich nur in die Master geschrieben und ist die weg, hast du wieder keine Ausfallsicherheit.