Server (Web, File, DB, ...) virtualisieren?

ascer

Captain
Registriert
Juni 2008
Beiträge
3.703
Huhu Community,


ich würde mich gerne mal in die Virtualisierung von Serversystemen einarbeiten.
Mal angenommen, ich hätte eine Umgebung wo Web-, File-, Datenbankserver usw. laufen sollen, dann ist die Lösung alles auf einem großen System zu deployen ja nicht sonderlich schön. Zickt dann ein Server rum oder braucht das System wegen irgendwas einen Neustart, fällt alles andere mit aus.

Mein Plan wäre also optimalerweise für jeden Service einen eigenen, schlanken, virtualisierten Server einsetzen zu wollen. Sprich jeweils eine VM für Web-, File-, Datenbankenserver usw.

Als Serverbetriebssysteme habe ich bis jetzt immer Ubuntu Server oder Debian benutzt - das würde ich auch weiterhin tun.

Da ich auf dem Gebiet wenig Erfahrung habe, hätte ich gerne ein paar Tipps.
Bisher habe ich Virtualisierung nur zum Testen von Software benutzt, mit VirtualBox oder VMWare Workstation.
Gefühlt könnte das aber ziemlich Hardwareintensiv werden?
Wenn man je eine VM anlegen würde mit je einem kompletten Debian-System...

Das geht sicherlich auch schlauer?!

Welche Konzepte sollte man sich dort anschauen? Was würdet ihr als Virtualisierungslösung für solche Szenarien vorschlagen?


viele Grüße & vielen Dank

ascer
 
Zuletzt bearbeitet:
Die Frage ist nicht so sehr wie viele einzelne Server du anlegen willst, sondern wie viel Last die haben werden. Für den reinen Privatgebrauch und zum testen und spielen wird es nicht viel sein.

Du hast zwei Optionen:

1.: Desktopvirtualisierung, so wie du es bisher gemacht hast. Linux oder Windows auf ein System und dann mit VirtualBox oder VMware Workstation virtualisieren.
2.: Eigener Server mit Hypervisor, d.h. VMware ESX oder Microsoft Hyper-V.

Hardwareintensiv wird das für den normalen Gebrauch eigentlich nicht. Für 1 ist jeder aktuelle Spielerechner überdimensioniert und die meisten aktuellen Officerechner wären noch ausreichend. 2 braucht nicht mehr Leistung, ist dann aber eine eigene Maschine an der du nicht mehr sitzen und sonstige Aufgaben erledigen kannst. Musst du für dich entscheiden was bei dir in Frage kommt.

Eine etwas andere Herangehensweise wäre Docker, wobei einzelne Applikationen in eigenen Containern auf einem Host deployed werden.
 
Zuletzt bearbeitet:
Wieso denn immer die kommerziellen?

Wenn du sowieso Linux als Hostsystem einsetzt, kommst du an Xen bzw. KVM sowieso kaum vorbei.
Ich persönlich mag KVM lieber als Xen, weils einfacher zu bedienen ist (libvirt + virt-manager). Xen hat dafür Vorteile, was die Effizienz betrifft. Bei uns an der Uni hatten sie sich vor drei Jahren für Xen entschieden, weil bei KVM ein ganzer CPU-Kern nur mit Storage + virtual ethernet beschäftigt war. Das hat sich zwar mittlerweile gebessert, aber gefühlt ist Xen noch immer der ressourcenschonendere Hypervisor, wenn er richtig eingestellt ist.
Ist also eher Geschmacksfrage, welcher dir eher zuspricht.

Abgesehen davon gibts natürlich noch immer Containersysteme wie LXC oder Docker, die auf demselben Kernel laufen, aber weitgehend isoliert vom Host arbeiten. Wenn du nur nen Heimserver am Werkeln haben willst, würd ich mir das vielleicht mal näher ansehen. Spart Ressourcen und damit auch Strom.
Allerdings kannst du damit logischerweise keine Windows-VM's erstellen, oder VM's mit anderen Kerneln. Sicherheitstechnisch stehen vollvirtualisierte Systeme tendenziell auch besser als Container mit einem gemeinsamen Kernel.

Von VMware und HyperV halte ich nicht besonders viel. Sie sind zwar als fertiges (Windows-) Produkt gut zu benutzen, aber wehe dir, du willst mal speziellere Sachen wie PCI-Passthrough oder bestimmte Netzwerkkonfigurationen einsetzen...
Ganz zu schweigen von dem DKMS-Gedöns (VMware/Virtualbox) und dem Nichtvorhandensein under Linux (HyperV)...
 
Zuletzt bearbeitet:
https://www.virtualbox.org/
VirtualBox is a powerful x86 and AMD64/Intel64 virtualization product for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL) version 2.

https://www.vmware.com/de/products/esxi-and-esx/overview
ESXi kann kostenlos als Teil von vSphere Hypervisor oder kostenpflichtig als Teil einer vSphere Edition genutzt werden.

Es gibt natürlich auch Lizenzen für den ESX, aber die braucht man nicht zwingend. Mit dem Funktionsumfang der freien Variante kommt man zu Hause weit genug.
Und bevor man Enterprise Plus Lizenzen kauft gäbe es nach der freien Variante auch noch ein Essentials Kit für drei Server mit je zwei CPUs und einer vCenter Lizenz für 600 Euro. Wenn man so weit ist, dass das ein Thema ist, dann sind 600 Euro dafür geschenkt.
 
DunklerRabe schrieb:
(...)
Du hast zwei Optionen:

1.: Desktopvirtualisierung, so wie du es bisher gemacht hast. Linux oder Windows auf ein System und dann mit VirtualBox oder VMware Workstation virtualisieren.
2.: Eigener Server mit Hypervisor, d.h. VMware ESX oder Microsoft Hyper-V.

Option 1 würde ich ausschließen. Jene wäre ja quasi die "quick'n'dirty" Variante, die ich jetzt schon habe. Das ganze ist zwar nur zum Spielen und Ausprobieren, ich würde das aber dennoch gerne vernünftig machen.

Bei Option 2: welchen Vorteil bietet denn VMware ESX konkret? Hyper-V fällt aus, ich habe ausschließlich Linux-Software (und damit Server) im Einsatz.






Hoeze schrieb:
Wenn du sowieso Linux als Hostsystem einsetzt, kommst du an Xen bzw. KVM sowieso kaum vorbei.

Warum explizit? Ich kenne beide Lösungen bis jetzt nur vom Lesen her.


Hoeze schrieb:
Abgesehen davon gibts natürlich noch immer Containersysteme wie LXC oder Docker, die auf demselben Kernel laufen, aber weitgehend isoliert vom Host arbeiten. Wenn du nur nen Heimserver am Werkeln haben willst, würd ich mir das vielleicht mal näher ansehen. Spart Ressourcen und damit auch Strom.

Das hört sich interessant an. D.h. im Prinzip hätte man dann z.B. einen Webserver-Container, der den Kernel vom Wirtsystem nutzt, d.h. selbst keinen "eigenen" Kernel hat und damit auch keine Ressourcen "verbrennt"?

Tendenziell ist es ja eigentlich die schönste Variante, ein Basissystem zu haben und darin dann virtualisiertes Zeug zu haben, das z.B. einzig und allein einen Webserver virtualisiert.

Wenn man Web-, File-, DB-Server usw. vernünftig einzeln virtualisieren möchte, gibt es ja eigentlich keinen Grund, jeweils ein komplettes Debian-System zu virtualisieren? 95% des Systems ( /bin, /lib(64), /etc, usw.) sind ja größtenteils gleich.

Wie genau würde denn so eine Containerlösung funktionieren?


Hoeze schrieb:
Allerdings kannst du damit logischerweise keine Windows-VM's erstellen, oder VM's mit anderen Kerneln.

Das ist egal. Ein, zwei wenige Sachen gefallen mir bei Ubuntu Server besser, da hätte ich dann einen 14.04 LTS Server, der Rest würde alles mit Debian 8 laufen. In beiden Fällen würde mir kein Szenario einfallen, wo ich unterschiedliche Kernel bräuchte.


Hoeze schrieb:
Sicherheitstechnisch stehen vollvirtualisierte Systeme tendenziell auch besser als Container mit einem gemeinsamen Kernel.

Warum genau?


Hoeze schrieb:
Von VMware und HyperV halte ich nicht besonders viel. Sie sind zwar als fertiges (Windows-) Produkt gut zu benutzen, aber wehe dir, du willst mal speziellere Sachen wie PCI-Passthrough oder bestimmte Netzwerkkonfigurationen einsetzen...
Ganz zu schweigen von dem DKMS-Gedöns (VMware/Virtualbox) und dem Nichtvorhandensein under Linux (HyperV)...

Ich gehe mal davon aus, dass ich speziellere Sachen vorerst nicht zum Spielen benötige...aber Windows-Software ist für mich ohnehin uninteressant ^^
 
Zuletzt bearbeitet:
In Sachen Container kannst du dir auch nochmal LXD anschauen. Das ist ein Abstraktionslayer von LXC, das das Handling erleichtern und von Haus aus bessere Sicherheitsfeatures einrichten soll. Aktuell tendiere ich dazu, diesen Ansatz für meinen eigenen Server zu wählen.

Warum 'echte' VMs trotzdem sicherer sind? Na, genau wegen des geteilten Kernels. Mit einem Kernelexploit kann man es schaffen aus dem Container auszubrechen und hat dann direkt Zugriff auf den Host. Bei einer VM wäre das äquivalent über einen Exploit in der Virtualisierungssoftware möglich, allerdings ist die Angriffsfläche dafür wesentlich geringer.
 
Wenn du eh Debian als Serverbasis benutzt, könntest du dir auch Proxmox anschauen. Damit hast du für KVM (und LXC glaub ich) eine Weboberfläche mit vielen Möglichkeiten.

Bei ESX musst du auf jeden Fall auf die verwendete Hardware achten, weil da nicht die Fülle an Treibern geliefert wird, wie bei einem Linux oder Windows. Da endet man gerne mal mit einem System, dass den Onboard SATA Controller nicht erkennt oder so ^^

Zickt dann ein Server rum oder braucht das System wegen irgendwas einen Neustart, fällt alles andere mit aus.
Dafür betreibt man sowas im professionellen Umfeld ja auch mit mehreren Hosts. Gibt es mit einem Host Probleme, werden die dort laufenden VMs auf andere Hosts verschoben.
 
Zuletzt bearbeitet:
ascer schrieb:
Warum explizit? Ich kenne beide Lösungen bis jetzt nur vom Lesen her.
Naja, Xen und KVM sind halt DIE beiden großen Hypervisoren unter Linux. Anders als andere Lösungen sind deren Kernel-Komponenten direkt im Linux-Kernel. Sie funktionieren halt "out of the box" wenn man so will. Aber da bin ich jetzt mal faul und verweis dich auf Google :freaky:

ascer schrieb:
Das hört sich interessant an. D.h. im Prinzip hätte man dann z.B. einen Webserver-Container, der den Kernel vom Wirtsystem nutzt, d.h. selbst keinen "eigenen" Kernel hat und damit auch keine Ressourcen "verbrennt"?

Tendenziell ist es ja eigentlich die schönste Variante, ein Basissystem zu haben und darin dann virtualisiertes Zeug zu haben, das z.B. einzig und allein einen Webserver virtualisiert.

Wenn man Web-, File-, DB-Server usw. vernünftig einzeln virtualisieren möchte, gibt es ja eigentlich keinen Grund, jeweils ein komplettes Debian-System zu virtualisieren? 95% des Systems ( /bin, /lib(64), /etc, usw.) sind ja größtenteils gleich.

Wie genau würde denn so eine Containerlösung funktionieren?

Ich beschränk mich hier mal auf Docker, weil es im Prinzip nur LXC-Container für dich verwaltet.
Docker ist insofern ziemlich cool, weils schon viele fertige images gibt, du kannst sagen, "docker pull debian:stable" (man bemerke die git-ähnliche Syntax) und hast ein einsatzbereites Debian-Image.
Du kannst prinzipiell sämtliche Linux-Distributionen verwenden, die mit deinem Kernel laufen.
Für jede Instanz kannst du dann angeben, an welche Ports der Container gebunden werden soll und welche Directories in den Container gemountet werden sollen.
Ein Beispiel:
Ich selbst hab Docker dazu verwendet, dass ich Owncloud, Roundcube, ... in jeweils eigene Container mit angepassten Apache2's gesperrt hab und diese dann per Nginx-Proxy veröffentliche:
Code:
location /cloud/ {
                proxy_pass http://127.0.0.1:8001; #auf diesem Port lauscht mein Owncloud-Container
                include /etc/nginx/proxy_params;
}
D.h. wenn jemand owncloud hacken sollte, kann er zumindest nicht mein restliches System, und nicht mal andere Teile meines Web-Servers übernehmen.
 
Zuletzt bearbeitet: (Image != Instanz)
Der Vorteil beim ESX ist halt, dass du eine professionelle Lösung kriegst, die aber kostenlos ist. Hyper-V würde ich eigentlich gar nicht empfehlen, ich habs nur mal zwecks Vollständigkeit erwähnt.
Was die Hardware für ESX angeht: So stark drauf achten muss man heute gar nicht mehr, früher war das mal wesentlich strikter. Heute läuft der ESX auf fast jeder Hardware. Natürlich ist das in den meisten Fällen nicht supportet, aber das brauchst du zu Hause ja auch nicht.

Das Problem mit Containern ala Docker (ob es bei LXC ebenso ist weiß ich nicht) ist, dass zwischen den Containern und dem Host keine wirkliche Trennung existiert. Ich, und viele andere, halten das für ein grundsätzliches Problem und die Docker Entwickler eher für eine inherente Eigenschaft des Konzepts und eher für ein Feature als für einen Bug. Für einige Geschichten braucht man nicht mal einen Exploit, da ist der Zugriff auch einfach so möglich.
Bei VMs auf einem Hypervisor hast du diese Trennung, da kommt man nicht mal eben so aus einer VM auf dem Host. Da braucht man dann wirklich einen Exploit für eine Schwachstelle im Hypervisor und da ist mir noch nichts in der Art untergekommen. Der Footprint von einem ESX ist recht überschaubar und damit auch die Angriffsfläche.

Spielereien wie PCI Passthrough, wovon ich auch ausging, dass du das eher nicht brauchst, gibt es bei VMware natürlich auch. Ob das funktioniert oder nicht ist eher eine Frage der Hardware als der Software. Das ist dann wirklich noch ein Fall, wo man auf die gewählte Hardware achten muss.
 
Ok, vielen Dank für die interessanten Beiträge! :)
 
Wichtig bei Containern wäre noch, dass die Ressourcenbeschränkungen (CPU / RAM) nativ nicht möglich sind. Dafür greift man auf cgroups zurück.
Die Festplattenkapazität lässt sich je nach Herangehensweise, nur über die Filesystemgröße (bei LXC im Standard /var/lib/lxc) für alle Container gemeinsam bestimmen und kann mit Quatos granularer geregelt werden. Alternaitv bieten sich Container im Filesystem (qcow2) an, die sich wie virtuelle Festplatten bei VMWar/VirtualBox verhalten).

Und man kann die Container nicht nur über NAT und PAT ansprechen, so dass der Host Anfragen weiterleiten muss, sondern ihnen auch über Bridge Interfaces echte Netzwerkgeräte geben, so dass sie sich mehr nach einer VM anfühlen.


Abgesehen davon würde ich davon absehen wollen, die Filesystem /usr /etc /lib und so weiter in den Container zu mappen. Bekommt der Host ein Update machen dasss die Container zwangsweise mit... Kann schonmal unangenehm werden, wie ich aus eigener Erfahrung weiß. Und die vielleicht 500MB für eigene Binaries und Libraries tuen keinem weh.


Alles in allem sind Container an schlanke Lösung und eignen sich zum kennenlernen und testen sehr gut.
 
Zurück
Oben