XenServer aufsetzen mit mehreren Ubuntu Servern für WebApps
Hallo,
ich möchte für ein Praktikum an der Uni einen Server für den Lehrstuhl aufsetzen. Bisher kenne ich mich noch so gut wie gar nicht in diesem Bereich aus und benötige daher Hilfe.
Folgendes soll ich realisieren:
Auf dem Server soll XenServer laufen, darauf dann mehrere Ubuntu Server VMs, die für jeweils ein kleines PHP Programm zuständig sind (z.B. für die Verwaltung der Tutoren). Eine der VMs soll als Reverse Proxy fungieren und die Anfragen aus dem Netz an die jeweiligen VMs/Programme weiterleiten.
Was ich bisher gemacht habe:
Ich habe XenServer 6.2 zum Laufen gebracht und einen Bond zwischen meinen beiden NICs erstellt. Der Server erhält seine Adresse und Einstellungen über DHCP vom Rechenzentrum der Uni. Das läuft auch, ich habe Zugriff auf das Internet und den Rest des Uni-Netzes. Neue VMs kann ich auch erstellen, diesen weise ich dann den Bond als Netzwerk zu.
Mein Problem:
Die VMs, die ich auf dem Sever aufsetze, haben keine Verbindung zum Internet. Ich habe nur die eine IP Adresse für den Server zur Verfügung, da ich nicht für jede neue VM zum Rechenzentrum laufen kann. Leider weiß ich nicht, wie ich jetzt den XenServer als eine Art Router verwenden soll, um die VMs an das Netz anzubinden, bzw. was ich wo machen/einstellen muss, um oben beschriebene Funktionalität herzustellen.
Ich verwende einen WinPC mit XenCenter, um mich von zu Hause aus mit dem Ganzen zu beschäftigen (btw, gibt es eine Möglichkeit, die Konsolen der VMs etwas zu beschleunigen? Die reagieren mit hoher Verzögerung...)
Ich hoffe, mein Problem ist einigermaßen verständlich beschrieben, falls Ihr mehr Infos benötigt, dann sagt mir bitte genau, was ich besser beschreiben soll / was Ihr noch braucht und ich liefere das nach.
Vielen Dank schon mal im Voraus,
Alex
ich möchte für ein Praktikum an der Uni einen Server für den Lehrstuhl aufsetzen. Bisher kenne ich mich noch so gut wie gar nicht in diesem Bereich aus und benötige daher Hilfe.
Folgendes soll ich realisieren:
Auf dem Server soll XenServer laufen, darauf dann mehrere Ubuntu Server VMs, die für jeweils ein kleines PHP Programm zuständig sind (z.B. für die Verwaltung der Tutoren). Eine der VMs soll als Reverse Proxy fungieren und die Anfragen aus dem Netz an die jeweiligen VMs/Programme weiterleiten.
Was ich bisher gemacht habe:
Ich habe XenServer 6.2 zum Laufen gebracht und einen Bond zwischen meinen beiden NICs erstellt. Der Server erhält seine Adresse und Einstellungen über DHCP vom Rechenzentrum der Uni. Das läuft auch, ich habe Zugriff auf das Internet und den Rest des Uni-Netzes. Neue VMs kann ich auch erstellen, diesen weise ich dann den Bond als Netzwerk zu.
Mein Problem:
Die VMs, die ich auf dem Sever aufsetze, haben keine Verbindung zum Internet. Ich habe nur die eine IP Adresse für den Server zur Verfügung, da ich nicht für jede neue VM zum Rechenzentrum laufen kann. Leider weiß ich nicht, wie ich jetzt den XenServer als eine Art Router verwenden soll, um die VMs an das Netz anzubinden, bzw. was ich wo machen/einstellen muss, um oben beschriebene Funktionalität herzustellen.
Ich verwende einen WinPC mit XenCenter, um mich von zu Hause aus mit dem Ganzen zu beschäftigen (btw, gibt es eine Möglichkeit, die Konsolen der VMs etwas zu beschleunigen? Die reagieren mit hoher Verzögerung...)
Ich hoffe, mein Problem ist einigermaßen verständlich beschrieben, falls Ihr mehr Infos benötigt, dann sagt mir bitte genau, was ich besser beschreiben soll / was Ihr noch braucht und ich liefere das nach.
Vielen Dank schon mal im Voraus,
Alex
Please also mark the comments that contributed to the solution of the article
Content-Key: 260332
Url: https://administrator.de/contentid/260332
Printed on: April 26, 2024 at 17:04 o'clock
18 Comments
Latest comment
Hallo Alex,
da gibt es verschiedene Möglichkeiten, wie man vorgehen kann. Ich habe es bei einem ähnlichen Setup (allerdings auf Proxmox-Basis) mit einem Router (pfSense) als VM gelöst. Den Maschinen musst du dann eben interne Netzwerkinterfaces zuweisen und nicht den bond. Den bekommt nur das WAN-Interface des Routers. Die Internet-Anbindung muss dann per NAT erfolgen.(Wenn du nur eine IP hast)
Diese Variante finde ich persönlich auch dank der Weboberfläche gut zu konfigurieren.
Alternativ kannst du auch mit iptables arbeiten, siehe hier: http://blog.manula.org/2012/04/manually-configuring-nat-networking-in.h ...
Beste Grüße!
Berthold
da gibt es verschiedene Möglichkeiten, wie man vorgehen kann. Ich habe es bei einem ähnlichen Setup (allerdings auf Proxmox-Basis) mit einem Router (pfSense) als VM gelöst. Den Maschinen musst du dann eben interne Netzwerkinterfaces zuweisen und nicht den bond. Den bekommt nur das WAN-Interface des Routers. Die Internet-Anbindung muss dann per NAT erfolgen.(Wenn du nur eine IP hast)
Diese Variante finde ich persönlich auch dank der Weboberfläche gut zu konfigurieren.
Alternativ kannst du auch mit iptables arbeiten, siehe hier: http://blog.manula.org/2012/04/manually-configuring-nat-networking-in.h ...
Beste Grüße!
Berthold
Das Problem ist ja, dass du nur eine IP hast. Wenn du jetzt einen virtuellen Router einsetzen willst, dann muss dieser die externe IP zugewiesen bekommen. Dazu legst du eine Bridge über das Bond-Device an, weist aber dem Root-Server keine IP zu.
Nun kannst du den Root-Server allerdings erstmal nicht mehr über das Netzwerk erreichen. Das geht dann eben auch nur über eine interne Bridge, der kein externer Port zugewiesen ist -> Quasi ein virtueller Switch.
Jedenfalls ist das eine Variante, die ich bereits einmal umgesetzt habe.
Nun kannst du den Root-Server allerdings erstmal nicht mehr über das Netzwerk erreichen. Das geht dann eben auch nur über eine interne Bridge, der kein externer Port zugewiesen ist -> Quasi ein virtueller Switch.
Jedenfalls ist das eine Variante, die ich bereits einmal umgesetzt habe.
![Mitglied: 114757 Mitglied: 114757](/images/members/profile_male_64x64.png)
Moin,
wenn du nur eine IP zur Verfügung hast must du NAT machen, dazu das IP-Routing aktivieren
und in der Firewall das Masquerading auf dem öffentlichen Interface aktivieren:
Gruß jodel32
wenn du nur eine IP zur Verfügung hast must du NAT machen, dazu das IP-Routing aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o "interface" -j MASQUERADE
Na ja, der TO müsste bevor er weitermacht erstmal 2 grundsätzliche Fragen klären:
Gut... Punkt kann schonmal NICHT Bridging sein, denn das würde bedeutetn das die VMs IP aus dem Hostnetz sprich dem Uni Netz verwenden und auch ins Internet könnten. Ist nicht der Fall wie der TO schon geklärt hat also Haken dran.
Bleibt also noch NAT oder Hostmode.
NAT würde bedeuten das der XEN Server ein Port Forwarding oder Port Translation machen muss bzw. mit Reverse Proxy arbeiten muss.
Im Hostmode muss Routing aktiviert werden wie Kollege jodel32 schon beschrieben hat.
Beim Routing greift aber Punkt 2, denn das funktioniert nur dann wenn das IP Subnetz der VMs auch routebar ist im Uninetz ansonsten ist das Netz nicht transparent erreichbar im Uni Netz.
Aus der Tatsache das der TO sich nicht einmal offizelle Adressen für die VMs, sei es aus Faulheit oder weil er sich gar nicht bekommt, vom Uni RZ besorgen kann lässt sich auch schliessen das das VM Netz keine offizell gerouteten IP Adressen verwendet.
Allein die vollkommen unübliche Tatsache dynamische DHCP IP Adressen für einen zentralen VM Server zu verwenden lässt schon nichts Gutes erahnen
Kein Netzwerker macht sowas bei einem Server !
Allein schon die Dynamik der DHCP Adresse am Server ist tödlich. Ändert sich die einmal wie es bei der Dynamik von DHCP ja mal geschuldet ist, dann ist der Zugriff von außen so oder so Makulatur und müsste neu an diese IP angepasst werden.
Allein DAS verbietet schon den Einsatz von DHCP für die Server IP.
Fazit daraus: Unter den genannten IP Adress design Voraussetzungen (zu denen der TO leider rein gar nichts sagt !) bleibt nur noch NAT Modus mit Port Forwarding oder Reverse Proxy übrig wenn nur einzig die Xen Host IP als offizielle Adresse im Uni Netz hängt.
All das lässt schliessen das das nichts sauber geplantes ist sondern eher nach einem Bastelprojekt aussieht was mit dem RZ Betreib nicht wirklich abgestimmt ist.
Kann man nur hoffen das der TO KEIN Student ist ?! An der Uni lernt man es anders zu arbeiten....
- 1.) WIE ist das Netzwerk der VMs an den Host angebunden ? Im Bridging, NAT oder Hostmode ?
- 2.) Das interne Netz was für die VMs benutzt wird ist das ein RFC 1918 IP Netz (Privates netz) oder ist das eine offizielles Netz was im Uni Netz routebar ist.
Gut... Punkt kann schonmal NICHT Bridging sein, denn das würde bedeutetn das die VMs IP aus dem Hostnetz sprich dem Uni Netz verwenden und auch ins Internet könnten. Ist nicht der Fall wie der TO schon geklärt hat also Haken dran.
Bleibt also noch NAT oder Hostmode.
NAT würde bedeuten das der XEN Server ein Port Forwarding oder Port Translation machen muss bzw. mit Reverse Proxy arbeiten muss.
Im Hostmode muss Routing aktiviert werden wie Kollege jodel32 schon beschrieben hat.
Beim Routing greift aber Punkt 2, denn das funktioniert nur dann wenn das IP Subnetz der VMs auch routebar ist im Uninetz ansonsten ist das Netz nicht transparent erreichbar im Uni Netz.
Aus der Tatsache das der TO sich nicht einmal offizelle Adressen für die VMs, sei es aus Faulheit oder weil er sich gar nicht bekommt, vom Uni RZ besorgen kann lässt sich auch schliessen das das VM Netz keine offizell gerouteten IP Adressen verwendet.
Allein die vollkommen unübliche Tatsache dynamische DHCP IP Adressen für einen zentralen VM Server zu verwenden lässt schon nichts Gutes erahnen
Allein schon die Dynamik der DHCP Adresse am Server ist tödlich. Ändert sich die einmal wie es bei der Dynamik von DHCP ja mal geschuldet ist, dann ist der Zugriff von außen so oder so Makulatur und müsste neu an diese IP angepasst werden.
Allein DAS verbietet schon den Einsatz von DHCP für die Server IP.
Fazit daraus: Unter den genannten IP Adress design Voraussetzungen (zu denen der TO leider rein gar nichts sagt !) bleibt nur noch NAT Modus mit Port Forwarding oder Reverse Proxy übrig wenn nur einzig die Xen Host IP als offizielle Adresse im Uni Netz hängt.
All das lässt schliessen das das nichts sauber geplantes ist sondern eher nach einem Bastelprojekt aussieht was mit dem RZ Betreib nicht wirklich abgestimmt ist.
Kann man nur hoffen das der TO KEIN Student ist ?! An der Uni lernt man es anders zu arbeiten....
Deine Hoffnung, ich sei kein Student, muss ich leider zerstören
Na ja als Altphilologe oder Ur- und Frühgeschichte Student darf man auch solche Fragen stellen...da sind wir etwas nachsichtiger ich versichere Dir, dass ich für gewöhnlich tatsächlich anders arbeite.
Na...obs denn wirklich stimmt ??der sich eigentlich bisher mit diesem Thema befasst hat in Elternzeit gegangen ist.
So so...und eine entsprechende Vertretung war dann jedem egal..?! Admin.de wirds richten...Zurück zum Thema...
Diese ist jedoch konstant, wir bekommen immer die gleiche Adresse zugewiesen
Das ist schonmal gut und muss auch bei externem Zugriff zwingend so sein. Fragt sich jetzt nur noch: Immer die gleiche IP weil der lease eben noch im Lease Cache ist oder ist das wirklich fest auf die Mac Adresse gebunden ??Aber egal für die eigentliche Fragestellung ist das erstmal irrelevant !
Weitere IPs soll es nicht vom RZ geben. Man darf mir sicher Faulheit unterstellen, aber es geht vorwiegend um leichte Erweiterbarkeit, ohne ständig neue IPs anfordern zu müssen.
Ist ja auch erstmal egal...man kann es mit etwas mehr Aufwand ja auch unter diesen Umständen lösen !Kommen wir mal zum generellen Problem was du lösen musst:
Du betreibst ja irgendwo von dir frei geratene oder bestimmte IP Adressen unter den VMs, da du ja keine offiziell zugeteilten aus dem Uni Netz bekommst oder dir das zuviel Aufwand ist...was auch immer.
Vorzugsweise verwendest du dann (hoffentlich) RFC 1918 IP Adressen also Private IPs:
http://de.wikipedia.org/wiki/Private_IP-Adresse.
Ist das der Fall bedeutet das dann gleichzeitig, das diese IPs nicht nur im gesamten Uninetz unbekannt sind sondern auch im Internet ! Logisch ! Konsequnz ist das diese IPs aus dem Uni Netz NICHT erreichbar sind !
Fazit: Die einzige IP Adresse mit der du auf die VMs mit deinen ausgedachten IP Adressen zugreifen kannst, ist einzig und allein die vom RZ zugeteilte IP !
Daraus resultiert auch das deine selbst vergebenen IP Adressen der VMs bzw. Netze niemals im Uninetz auftauchen dürfen, geschweige denn sichtbar sein dürfen. Ansonsten müsste das mit dem RZ abgestimmt sein und in den Campus Routern überall eingetragen sein. Es ist daher so oder so sinnfrei weil kein Router auf dem gesamten Uni Campus diese IP Netze und Adressen kennt und damit ein Routing und eine Erreichbarkeit IP technisch unmöglich ist.
Daraus wiederum das Fazit:
Du kannst einzig und allein nur NAT betreiben, also ein IP Adress Translation oder alternativ einen Reverse Proxy im deine VM IP Adressen aus dem Uninetz zu erreichen.
DAS sollte dir erstmal aus reiner IP Infrastruktur Sicht bewusst sein.
Dir bleibt also einzig NAT mit Port Translation oder der Reverse Proxy der auf der Uni IP arbeitet die dir vom RZ vergeben wurde ! Diese IP ist ja dein einziges Tor zu deinen VMs...logisch.
Der reverse Proxy ist also erstmal technisch die beste Lösung, denn bei NAT und Port Translation würden deine VMs alle auf unterschiedlichen TCP Ports arbeiten müssen wie 8080, 8081, 8082 usw. usw. Ein Umstand den du sicher nicht willst.
Bleibt also wenn dann nur der Reverse Proxy.
Solange du dir diese Fakten bewusst machst ist gar nichts komisch an deinem Vorhaben
Mein dringendstes Problem ist jetzt, dass ich diesen Reverse Proxy nicht direkt auf dem zugrunde liegenden Server, sondern auf einer extra VM einrichten will. Diese soll ans Uninetz angebunden sein und außerdem in dem privaten Netz mit den anderen VMs sein.
Yepp....genau DAS ist der Punkt und die richtige Vorgehensweise.Da du aber die eine IP schon für den Server und das Mangement desselben verbraten hast, musst du wohl wohl üoer übel den Gang nach Canossa antreten, sprich also ins RZ und um eine weitere IP Adresse für den Reverse Proxy betteln gehen.
Da wird dir nix anderes übrig bleiben um das Dilemma lösen zu können.
Es gäbe aber auch einen Quick und Dirty Workaround...
- Du vergibst dem XEN Server eine Fantasieadresse im Uni Netz z.B. 1.1.1.1 /30 zum Management.
- Dann konfigurierst du deinen Client zum Management des Servers die 1.1.1.2 /30 und kannst so den Server managen.
- Die NIC des XEN bridgest du mit dem Uni Netz natürlich und vergibst dann dem Reverse Proxy auf dessen Bein im Uni Netz die dir zugeteilte Adresse !
- Voila...Problem ohne Canossa Gang gelöst.
Mit der 1er IP und dem 30er Subnetz gibt es mit an Sicherheit grenzender Wahrscheinlichkeit wohl keinerlei Konflikte.
Der Workaround erscheint mir wirklich etwas "dirty" und ich weiß nicht, ob ich davon wirklich einen Vorteil hätte.
Ist er auch aber deine einzige Chance das überhaupt zum Laufen zu bekommen OHNE eine weitere IP Adresse. Und ein bischen tricksen ist ja an der Uni erlaubt.Ansonsten kannst du dein Projekt gleich ganz begraben, das ist dir doch auch selber klar, oder ?
XenServer für Reverse Proxy und VMs für WebApps wären dann in einem normalen privaten Netzwerk miteinander. Somit würde die vorgeschobene VM entfallen.
Das wäre dann dein einziger anderer Ausweg aus dem Dilemma...Gibt es also keine andere Möglichkeit, alle Anfragen aus dem UniNetz durch den XenServer zu leiten, zu einer vorgeschobenen VM
Nein, denn wie sollte das denn ohne eine weitere IP Adresse gehen ?? Du kannst deine einzige Adresse ja nicht einfach teilen auf 2 Hosts wie sollte das gehen ??Alternative ist dann höchstens das du per IPv6 das gesamte Management machst und nur v4 zum RP nimmst. Eine IPv6 local Unicast IP wird ja immer dynmaisch vergeben und damit verstösst du gegen keinerlei IP Adressierungsregel des RZ !
Das wäre dann die etwas sauberere Variante des Tricks.
Wenn du mit XEN arbeitest brauchst du ja immer eine IP für den Hypervisor selber und für deine VM mit dem RP...da beisst die Maus keinen Faden ab.
Aber die VMs sind doch ans Internet angebunden... Eben nur nicht direkt, sondern via NAT: siehe hier: NAT
![Mitglied: 114757 Mitglied: 114757](/images/members/profile_male_64x64.png)
Die Firewall (IPTables) welche auch dein NAT für die VMs macht ist dein Freund fürs PORT-Forwarding !
http://www.fclose.com/816/port-forwarding-using-iptables/
http://www.fclose.com/816/port-forwarding-using-iptables/
Aber die VMs sind doch ans Internet angebunden...
Die gehen bei der o.a. Lösung aber durch den Reverse Proxy !Das mit dem Port Forwarding ist natürlich auch eine Lösung wenn es wirklich nur um die Ports TCP 80 und TCP 443 geht.
Die kann man in der Tat mit iptables dann vom Host fest forwarden auf einen Reverse Proxy. Bedeutet das der RP dann aber auf dem Hypervisor selber laufen muss und ob das geht bei XEN ...?!
Zitat von @aqui:
> Aber die VMs sind doch ans Internet angebunden...
Die gehen bei der o.a. Lösung aber durch den Reverse Proxy !
Nö, der User fragte, wie er auf den Maschinen Packages installieren kann. Die Verbindung ins Internet geht über NAT... Über den ReverseProxy gehen nur die Anfragen, die von aussen kommen> Aber die VMs sind doch ans Internet angebunden...
Die gehen bei der o.a. Lösung aber durch den Reverse Proxy !
Das mit dem Port Forwarding ist natürlich auch eine Lösung wenn es wirklich nur um die Ports TCP 80 und TCP 443 geht.
Die kann man in der Tat mit iptables dann vom Host fest forwarden auf einen Reverse Proxy. Bedeutet das der RP dann aber auf dem
Hypervisor selber laufen muss und ob das geht bei XEN ...?!
Wieso sollte der RP auf dem Hypervisor laufen müssen? EInfach die entsprechenden Ports an eine VM durchreichen und diese dann als ReverseProxy aufsetzen... Das sollte doch wirklich kein Problem sein.Die kann man in der Tat mit iptables dann vom Host fest forwarden auf einen Reverse Proxy. Bedeutet das der RP dann aber auf dem
Hypervisor selber laufen muss und ob das geht bei XEN ...?!