18
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 260332
Url: https://administrator.de/contentid/260332
Printed on: April 24, 2024 at 03: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
Danke erstmal, Berthold. Das klingt schon mal nicht schlecht, auch die Möglichkeit, das Ganze über ein Web Interface zu konfigurieren gefällt mir.
Ich brauche allerdings noch mehr Informationen zum ersten Schritt, dem Einrichten und Anbinden dieser ersten VM, die als Router fungieren soll. Ich dachte, wenn ich dieser VM den Bond zuweise, dann sollte sie bereits Internetzugriff haben, aber das läuft auch noch nicht. Was genau muss ich denn in meinem rootserver und auf dieser ersten VM einstellen?
Ich brauche allerdings noch mehr Informationen zum ersten Schritt, dem Einrichten und Anbinden dieser ersten VM, die als Router fungieren soll. Ich dachte, wenn ich dieser VM den Bond zuweise, dann sollte sie bereits Internetzugriff haben, aber das läuft auch noch nicht. Was genau muss ich denn in meinem rootserver und auf dieser ersten VM einstellen?
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.
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
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....
Hallo aqui,
danke, dass Du Dich hier dazu meldest. Deine teilweise erheiternden Kommentare zeigen mir, dass ich wohl noch weit von meinem Ziel entfernt bin.
Wie ich bereits gesagt habe, bin ich auf dem Gebiet kompletter Neuling. Deine Hoffnung, ich sei kein Student, muss ich leider zerstören
, aber ich versichere Dir, dass ich für gewöhnlich tatsächlich anders arbeite. Das Problem ist, dass ich hier ein Praktikum am Lehrstuhl mache und derjenige, der sich eigentlich bisher mit diesem Thema befasst hat in Elternzeit gegangen ist. Für eine ausführliche Eigenrecherche und Einarbeitung fehlt mir leider die Zeit, da auch ein Haufen wichtiger Prüfungen und Seminararbeiten anstehen, die meinen Terminkalender gut ausfüllen. Das nur ein wenig zu meinem Hintergrund, ich will Euch jetzt keine weiteren "Ausreden" an den Kopf werfen.
Ich erwähnte ja, dass ich Euch gerne alle weiteren Informationen zukommen lasse, aber ich muss gestehen, dass ich nicht weiß, was Ihr alles wissen müsst, um mir effizient helfen zu können. Ich habe bei der Umsetzung, innerhalb der gegebenen Umstände, freie Hand. Was in der "Black Box Server" geschieht, ist dem Prof. und den anderen Mitarbeitern egal, solange das Endergebnis halbwegs die geforderte Funktionalität bietet. Ich nehme also gerne alle Server und VM Konstellationen/Konfigurationen an, die meine Aufgabe lösen.
Deinen Rat, mich mit dem RZ abzusprechen, nehme ich schon mal dankbar an, vielleicht können die mir auch weitere Hinweise geben. Dennoch denke ich, dass Ihr mir hier sicher auch weiterhelfen könnt, wenn ich Euch die richtigen Informationen liefere.
Um das Problem nochmal zu spezifizieren:
Am Lehrstuhl haben wir einen Server, der per DHCP vom RZ eine Adresse im Uninetz erhält. Diese ist jedoch konstant, wir bekommen immer die gleiche Adresse zugewiesen. 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. Im Übrigen weiß ich auch nicht, ob das immer ohne weiteres möglich ist. Auf diesem Server sollen jetzt verschiedene PHP Apps laufen, die für den Lehrstuhl entwickelt wurden. Diese werden jeweils auf einer eigenen VM untergebracht. Der Zugriff auf diese Apps soll durch Aufrufe folgender Art aus dem Uni VPN möglich sein: http://lehrstuhlServerName/phpApp1/
Angedacht war, dass eine zusätzliche VM dafür sorgen soll, die Anfragen aus dem Uninetz an die restlichen VMs zu verteilen (z.B. per apache Reverse Proxy).
Alles weitere ist eigentlich freigestellt und unbestimmt, was für mich bedeutet, dass ich in der Vielzahl der Möglichkeiten leider etwas untergehe, da dies das erste Mal ist, dass ich so etwas realisieren muss.
Konkrete Antworten auf Deine Punkte:
1. Nicht festgelegt, das soll ich passend zur Lösung entscheiden.
2. Im Prinzip muss nur die VM erreichbar sein, die die Anfragen auf die anderen verteilt.
Wenn das jetzt alles immer noch komisch erscheint, sagt mir genau, was Ihr noch braucht.
danke, dass Du Dich hier dazu meldest. Deine teilweise erheiternden Kommentare zeigen mir, dass ich wohl noch weit von meinem Ziel entfernt bin.
Wie ich bereits gesagt habe, bin ich auf dem Gebiet kompletter Neuling. Deine Hoffnung, ich sei kein Student, muss ich leider zerstören
, aber ich versichere Dir, dass ich für gewöhnlich tatsächlich anders arbeite. Das Problem ist, dass ich hier ein Praktikum am Lehrstuhl mache und derjenige, der sich eigentlich bisher mit diesem Thema befasst hat in Elternzeit gegangen ist. Für eine ausführliche Eigenrecherche und Einarbeitung fehlt mir leider die Zeit, da auch ein Haufen wichtiger Prüfungen und Seminararbeiten anstehen, die meinen Terminkalender gut ausfüllen. Das nur ein wenig zu meinem Hintergrund, ich will Euch jetzt keine weiteren "Ausreden" an den Kopf werfen.Ich erwähnte ja, dass ich Euch gerne alle weiteren Informationen zukommen lasse, aber ich muss gestehen, dass ich nicht weiß, was Ihr alles wissen müsst, um mir effizient helfen zu können. Ich habe bei der Umsetzung, innerhalb der gegebenen Umstände, freie Hand. Was in der "Black Box Server" geschieht, ist dem Prof. und den anderen Mitarbeitern egal, solange das Endergebnis halbwegs die geforderte Funktionalität bietet. Ich nehme also gerne alle Server und VM Konstellationen/Konfigurationen an, die meine Aufgabe lösen.
Deinen Rat, mich mit dem RZ abzusprechen, nehme ich schon mal dankbar an, vielleicht können die mir auch weitere Hinweise geben. Dennoch denke ich, dass Ihr mir hier sicher auch weiterhelfen könnt, wenn ich Euch die richtigen Informationen liefere.
Um das Problem nochmal zu spezifizieren:
Am Lehrstuhl haben wir einen Server, der per DHCP vom RZ eine Adresse im Uninetz erhält. Diese ist jedoch konstant, wir bekommen immer die gleiche Adresse zugewiesen. 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. Im Übrigen weiß ich auch nicht, ob das immer ohne weiteres möglich ist. Auf diesem Server sollen jetzt verschiedene PHP Apps laufen, die für den Lehrstuhl entwickelt wurden. Diese werden jeweils auf einer eigenen VM untergebracht. Der Zugriff auf diese Apps soll durch Aufrufe folgender Art aus dem Uni VPN möglich sein: http://lehrstuhlServerName/phpApp1/
Angedacht war, dass eine zusätzliche VM dafür sorgen soll, die Anfragen aus dem Uninetz an die restlichen VMs zu verteilen (z.B. per apache Reverse Proxy).
Alles weitere ist eigentlich freigestellt und unbestimmt, was für mich bedeutet, dass ich in der Vielzahl der Möglichkeiten leider etwas untergehe, da dies das erste Mal ist, dass ich so etwas realisieren muss.
Konkrete Antworten auf Deine Punkte:
1. Nicht festgelegt, das soll ich passend zur Lösung entscheiden.
2. Im Prinzip muss nur die VM erreichbar sein, die die Anfragen auf die anderen verteilt.
Wenn das jetzt alles immer noch komisch erscheint, sagt mir genau, was Ihr noch braucht.
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
Ja, genau, vollkommen richtig. Diese Fakten sind mir so bereits bewusst und ich verstehe sie auch (Kennen und Können sind trotzdem noch zwei verschiedene Angelegenheiten ;) ) Meine Wahl wäre daher auch, wie gesagt, der Reverse Proxy gewesen.
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. Den eigentlichen Server muss ich aber doch auch noch erreichen können, ohne dass ich wieder mit Monitor und Tastatur unterm Arm in den Serverraum laufen muss.
Konkret geht es mir also erst mal darum, diese erste VM einzurichten.Kannst Du/Könnt Ihr mir die Schritte dazu genauer erklären?
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. Den eigentlichen Server muss ich aber doch auch noch erreichen können, ohne dass ich wieder mit Monitor und Tastatur unterm Arm in den Serverraum laufen muss.
Konkret geht es mir also erst mal darum, diese erste VM einzurichten.Kannst Du/Könnt Ihr mir die Schritte dazu genauer erklären?
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.
Ok, ich verstehe. Ob ich eine neue IP vom Rechenzentrum erhalte, ist wohl fragwürdig und hängt auch vom Prof ab, ob der das will. Der Workaround erscheint mir wirklich etwas "dirty" und ich weiß nicht, ob ich davon wirklich einen Vorteil hätte.
So wie ich das sehe, wäre dann die einfachste Lösung, dass ich den Reverse Proxy direkt auf dem XenServer laufen lasse. 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.
Gibt es also keine andere Möglichkeit, alle Anfragen aus dem UniNetz durch den XenServer zu leiten, zu einer vorgeschobenen VM, die dann an die anderen die passenden Anfragen verteilt (prinzipiell mal ohne NAT und Portverteilung)? Eine Lösung mit drei Netzen, z.B. dass der XenServer normal ans UniNetz angebunden ist, gleichzeitig mit dem Reverse Proxy in einem privaten Netz ist und dieser wiederum in einem weiteren privaten Netz mit den WebApp-VMs? Es ist ja aus meiner Sicht nicht nötig, dass Reverse Proxy und/oder VMs direkt mit dem UniNetz verbunden sind. Wir wollten halt diese dreistufige Konstellation umsetzen, aber wenn das nicht ohne Weiteres möglich ist, dann will ich mich auch nicht daran festkrallen.
So wie ich das sehe, wäre dann die einfachste Lösung, dass ich den Reverse Proxy direkt auf dem XenServer laufen lasse. 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.
Gibt es also keine andere Möglichkeit, alle Anfragen aus dem UniNetz durch den XenServer zu leiten, zu einer vorgeschobenen VM, die dann an die anderen die passenden Anfragen verteilt (prinzipiell mal ohne NAT und Portverteilung)? Eine Lösung mit drei Netzen, z.B. dass der XenServer normal ans UniNetz angebunden ist, gleichzeitig mit dem Reverse Proxy in einem privaten Netz ist und dieser wiederum in einem weiteren privaten Netz mit den WebApp-VMs? Es ist ja aus meiner Sicht nicht nötig, dass Reverse Proxy und/oder VMs direkt mit dem UniNetz verbunden sind. Wir wollten halt diese dreistufige Konstellation umsetzen, aber wenn das nicht ohne Weiteres möglich ist, dann will ich mich auch nicht daran festkrallen.
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.
Blöde Frage: Wäre denn nicht ein Portforwarding von 80 und 443 auf eine VM im möglich, die nur eine RFc1918-IP hat und dann als Reverse-Proxy fungiert? Die anderen Ports stünden ja dann immer noch für das Hostmanagement zur Verfügung...
Oder irre ich jetzt total?
Oder irre ich jetzt total?
Ich denke, viel mehr als http(s) werden die WebApps nicht brauchen und das könnte man durch den Reverse Proxy verteilen. Von meinem Verständnis aus, sollte das gehen. Das scheint mir auf jeden Fall mal die "sinnvollste" Möglichkeit zu sein.
Ich müsste also zuerst eine Portweiterleitung von Server an Reverse Proxy einrichten und anschließend den Reverse Proxy selbst konfigurieren. Könnt Ihr mir dazu nähere Infos geben?
Noch eine kleine Frage, die mich beschäftigt. Wie installiere ich eventuell für die WebApps notwendige Packages auf den VMs, wenn die nicht am Internet angebunden sind?
Die Methode, die zwischengeschobene VM rauszulassen, behalte ich mal in der Hinterhand, falls alle Stricke reißen. Euren "dirty trick" kann ich dann in der vorlesungsfreien Zeit ausprobieren
Ich müsste also zuerst eine Portweiterleitung von Server an Reverse Proxy einrichten und anschließend den Reverse Proxy selbst konfigurieren. Könnt Ihr mir dazu nähere Infos geben?
Noch eine kleine Frage, die mich beschäftigt. Wie installiere ich eventuell für die WebApps notwendige Packages auf den VMs, wenn die nicht am Internet angebunden sind?
Die Methode, die zwischengeschobene VM rauszulassen, behalte ich mal in der Hinterhand, falls alle Stricke reißen. Euren "dirty trick" kann ich dann in der vorlesungsfreien Zeit ausprobieren
Aber die VMs sind doch ans Internet angebunden... Eben nur nicht direkt, sondern via NAT: siehe hier: NAT
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 ...?!
Sorry, das letzte hab ich jetzt nicht ganz verstanden. Wieso müsste der RP dann auf dem Hypervisor selbst laufen? Meinst Du, ich kann den RP nicht auf einer VM unterbringen, zu der ich Port 80 und 443 weiterleite?
Danke für die Links!
Danke für die Links!
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 ...?!
