ESXi5 VM's im selben Netz "trennen" und monitoren

Mete888

Semiprofi
Thread Starter
Mitglied seit
05.01.2007
Beiträge
1.853
Ort
Zürich, Schweiz
Hallo zusammen

Kenne mich eigentlich relativ gut aus, was VMWare ESX angeht.
Habe mir vor einigen Tagen einen eigenbau ESXi 5 Server gekauft, welcher nun bei einem Hoster steht.

Der Hoster hat mir ein öffentliches /27 Subnetz zugeteilt (1 Switchport). An diesem Switchport ist der ESX angeschlossen und geht an dnm vSwitch1. An vSwitch1 hängt die VMWare Management Konsole sowie zwei VMs (VM1 und VM2). VM1 und VM2 haben ebenfalls jeweils eine IP aus dem gleichen /27 IP Netz.

Welche möglichkeiten gibt es, den Traffic von VM1 und VM2 getrennt zu loggen (Datenvolumen pro Monat z.B.)?

Auch wäre es schön, die zwei VM's "trennen" zu können. Sprich, nimmt VM1 z.B. die IP von VM2 an, so entsteht normalerweise ein IP Adresskonflikt.. ist ja logisch... kann man dies irgendwie gescheit verhindern?
Wichtig ist, dass die Lösung gratis/günstig ist und die VM's weiterhin öffentliche IP's aus dem selben Netz besitzen.

Sollte meiner Meinung nach mit einer Appliance realisierbar sein, stehe wohl aber momentan auf dem Schlauch...

Danke für eure Inputs.

Hier ein Kurzüberblick über den Aufbau:
zeichnung1.png


Gruss Mete
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Moinsen,

das Datenvolumen könntest du dir z.B über der Reiter "Leistung" der jeweiligen VM im vSphere Client anzeigen (musst dafür dann da noch auf Netzwerk wechseln und dir das Diagramm nach Wunsch anpassen)

Wieso sollte eine VM von alleine einfach eine IP einer anderen VM bekommen? Im RZ sind die IPs der Server (oder in deinem Falle VM) eigentlich immer statisch eingetragen. Oder es gibt einen DHCP der anhand der MAC die Adressen zuweist. Und auch die ändert sich in der Regel nicht von Geisterhand.

Wenn du was anderes meinst, dann beschreibst am besten noch was ausfühlicher ;)
 
Moinsen,

das Datenvolumen könntest du dir z.B über der Reiter "Leistung" der jeweiligen VM im vSphere Client anzeigen (musst dafür dann da noch auf Netzwerk wechseln und dir das Diagramm nach Wunsch anpassen)

Wieso sollte eine VM von alleine einfach eine IP einer anderen VM bekommen? Im RZ sind die IPs der Server (oder in deinem Falle VM) eigentlich immer statisch eingetragen. Oder es gibt einen DHCP der anhand der MAC die Adressen zuweist. Und auch die ändert sich in der Regel nicht von Geisterhand.

Wenn du was anderes meinst, dann beschreibst am besten noch was ausfühlicher ;)

Guten Morgen

Danke für deine Antwort.
Also den Reiter Leistung kenne ich :) Dort kann man jedoch unter ESXi5 nur die Zeitspanne "Echtzeit" auswählen, andere können leider nicht definiert werden (oder ich bin zu dumm). Zudem wäre es mir lieber das Datenvolumen zu sehen, anstatt die Bandbreitenauslastung.

Bezüglich den VM's: Ich würde gerne zwei VM's für bekannte bereitstellen... Nimmt jetzt einer der beiden aus welchen Gründen auch immer eine falsche IP (welche schon vergeben ist), ist die VM, welcher diese IP eigentlich zugeordnet ist nicht mehr erreichbar...

Gruss Mete
 
Das mit der IP kannst du nicht verhindern, zumindest nicht so einfach...
Es macht auch wenig Sinn das zu trennen, denn schließlich willst du, das die VM selbst im INet erreichbar ist, würde man hier trennen, wäre kein Connect mehr möglich. Was man machen könnte, du baust dir ne Router VM und klemmst die jenigen anderen VMs dahinter... Dann kannst du hinter der Router VM machen was du willst. Trennen, oder nicht, DHCP zur Not aktivieren usw.
Nachteil, du musst ein NAT Einrichten, sonst bekommst du die VMs hinter dem Router nicht vom INet aus erreicht.
Man könnte nun 1:1 NAT machen, da du ja mehr wie eine öffentliche IP hast...


Zum Traffic, man könnte den ESX monitoren, es gibt dedizierte Software, die die Counter auslesen und Bandbreiten anzeigen können.
Alternativ ne Netflow Appliance zwischen klemmen...
 
Das mit der IP kannst du nicht verhindern, zumindest nicht so einfach...
Es macht auch wenig Sinn das zu trennen, denn schließlich willst du, das die VM selbst im INet erreichbar ist, würde man hier trennen, wäre kein Connect mehr möglich. Was man machen könnte, du baust dir ne Router VM und klemmst die jenigen anderen VMs dahinter... Dann kannst du hinter der Router VM machen was du willst. Trennen, oder nicht, DHCP zur Not aktivieren usw.
Nachteil, du musst ein NAT Einrichten, sonst bekommst du die VMs hinter dem Router nicht vom INet aus erreicht.
Man könnte nun 1:1 NAT machen, da du ja mehr wie eine öffentliche IP hast...


Zum Traffic, man könnte den ESX monitoren, es gibt dedizierte Software, die die Counter auslesen und Bandbreiten anzeigen können.
Alternativ ne Netflow Appliance zwischen klemmen...

Huhu

Danke für dein Feedback.
Entschuldige die später Antwort... Eine Router VM hatte ich auch bereits erstellt und getestet, das funktioniert einwandfrei, jedoch ist hier das Problem, dass die VM's dann keine öffentliche IP mehr haben... Sprich auf den VM's direkt muss jeweils eine private IP Adresse konfiguriert werden, das möchte ich eigentlich nicht...

Gibt es eine 1:1 Nat Möglichkeit mit welcher man eine externe IP Adresse auch "hinter der Router VM" verwenden kann?

Danke und Gruss
Mete
 
? - Du sprichst aus der Internetseite heraus, die VM doch nicht mit der privaten Adresse an. - Das NAT ermöglicht ja das Du von extern die öffentliche nimmst und die am Router übersetzt wird und intern dann die private genutzt wird. - der Router kann dann je nach einstellungen eben mehrere öffentliche Adressen auf die jeweiligen privaten übersetzten, das sollte von außen also erstmal keinen Unterschied machen. - ich versteh Dein Problem nicht ganz...
 
? - Du sprichst aus der Internetseite heraus, die VM doch nicht mit der privaten Adresse an. - Das NAT ermöglicht ja das Du von extern die öffentliche nimmst und die am Router übersetzt wird und intern dann die private genutzt wird. - der Router kann dann je nach einstellungen eben mehrere öffentliche Adressen auf die jeweiligen privaten übersetzten, das sollte von außen also erstmal keinen Unterschied machen. - ich versteh Dein Problem nicht ganz...

Ich möchte den VM's hinter dem Router keine Privaten IP's geben... Sprich ein "ifconfig" oder "ipconfig" auf den VM's sollte die Loopback IP (127.0.0.1) und die externe IP ausgeben, jedoch keine interne IP...

Bei einem NAT hat man ja immer die Übersetzung zwischen öffentlichen und Privaten IP's....

Gruss Mete
 
Das, was du da planst, geht so nicht.

Auf der einen Seite willst du, dass beide Rechner getrennt voneinander sind -> Änderung der IP soll den anderen Rechner nicht beeinflussen.

Auf der andere Seite willst du, dass beide Rechner eben nicht getrennt sind -> sollen im selben Netz sein, mit einer direkten Erreichbarkeit von außen

Du mußt dich hier also für einen Weg entscheiden, bzw noch einmal eine ordentliche Stange Geld in die Hand nehmen.

Die einzige Möglichkeit um das zu realisieren, wäre der einsatzes eines ORDENTLICHEN Routers. Dieser bekommt dann 1x das Netz vom Provider angedüdelt, darauf laufen dann verschiedene Subinterfaces, welche dann per default Route den jeweils dahinter angeschlossen Rechner routen.

Das wären dann 2800er von Cisco zB.

Ob man sowas über ein Linux umsetzen kann, weiß ich nicht, dazu kenn ich die wirklichen Routingfähigkeiten nicht.

Mit solchen Spielzeugen wir IPCOP oder IPFIRE kommst du an der Stelle nicht weit.
Es muß also "echtes" Routing her und kein PAT oder NAT, das sind alles Verschleierungen, die dir so nicht weiterhelfen.

Aber auch bei diesen Lösungen hast du dann wiederum interneIPs, weil es eben, wie gesagt nicht anders geht.

Die einfachste Möglichkeit wäre es, wenn du den Benutzern der Rechner keine Rechte gibst, dass diese am Netzwerk rumfummeln dürfen.

EDIT:
Wenn du einen Router einsetzt, dann muß du zwangsläufig 2 Netze haben, 1x das Externe und 1x das Interne. 2 Netze bedeutet aber immer auch, dass es 2 IP-Ranges gibt.
 
Zuletzt bearbeitet:
Ich möchte den VM's hinter dem Router keine Privaten IP's geben... Sprich ein "ifconfig" oder "ipconfig" auf den VM's sollte die Loopback IP (127.0.0.1) und die externe IP ausgeben, jedoch keine interne IP...

Bei einem NAT hat man ja immer die Übersetzung zwischen öffentlichen und Privaten IP's....

Gruss Mete

Was hindert dich daran?
Ich habe so das Gefühl, du weist nichtmal, wovon du überhaupt sprichst...

Die einzige Möglichkeit wäre, wenn du dir dort vom Provider einen zweiten IP Bereich geben lässt, den du unabhängig vom ersten frei nutzen kannst.
Aber selbst diese quasi physische Trennung hindert immernoch niemanden daran, eine IP auf ner VM zu vergeben, welche sich mit einer anderen IP überschneidet und somit einem Adresskonflikt gleich kommt.

Der jenige Admin, der den Spaß schlussendlich administrieren soll, muss also so oder so aufpassen, was er tut. Anders funktioniert es nicht.


@underclocker2k4
man kann auch mit nem Linux oder gar Windows "echtes" Routing betreiben...
Aber so recht bringt ihn das nicht weiter.
 
Das beste wäre wohl, wenn er sich mal in simple Netzwertechnik einarbeitet ;) Das beantwortet die Frage gleich von selbst.
 
Das beste wäre wohl, wenn er sich mal in simple Netzwertechnik einarbeitet ;) Das beantwortet die Frage gleich von selbst.

Danke für euer Feedback...
Es gibt auch möglichkeiten mit diesem IP Netz "unabhängige" VM's zu machen...
Router VM einrichten, und das Netz in kleiner Netze unterteilen, so einfach wäre die Lösung gewesen.... Bisher funktioniert diese Lösung gut... Werde mal noch bisschen testen.

Danke und Gruss
Mete
 
Nicht wirklich ;)
Denn oben schriebst du, du willst verhindern, das VM x ungewollt durch ich nenn es mal ein Versehen, eine IP zugewiesen bekommt, welche schon von VM 1 oder weis der Teufel welche belegt ist. Und genau das verhinderst du damit nicht...

Zwar trennst du die beiden Netze in zwei Parts auf, dafür verlierst du ganz paar Adressen für nichts ;)
Dazu kommt, das du auf dem Router des Providers "statische Routen Einträge" benötigst, um das Netz, was ihm bekannt ist, weiter aufzusplitten. Sonst wird das nix. Denn er kann die beiden losgelösten Netze, welche du durch das Trennen erzeugen willst, nicht selbst erreichen, obwohl er das denkt (weil seine interne Seite eine 27Bit Maske hat)

Unterm Strich wäre es einfacher mit privaten Netzen sowie NAT zu arbeiten ;)
 
Nicht wirklich ;)
Denn oben schriebst du, du willst verhindern, das VM x ungewollt durch ich nenn es mal ein Versehen, eine IP zugewiesen bekommt, welche schon von VM 1 oder weis der Teufel welche belegt ist. Und genau das verhinderst du damit nicht...

Zwar trennst du die beiden Netze in zwei Parts auf, dafür verlierst du ganz paar Adressen für nichts ;)
Dazu kommt, das du auf dem Router des Providers "statische Routen Einträge" benötigst, um das Netz, was ihm bekannt ist, weiter aufzusplitten. Sonst wird das nix. Denn er kann die beiden losgelösten Netze, welche du durch das Trennen erzeugen willst, nicht selbst erreichen, obwohl er das denkt (weil seine interne Seite eine 27Bit Maske hat)

Unterm Strich wäre es einfacher mit privaten Netzen sowie NAT zu arbeiten ;)

Doch, das wird damit unterbunden...
Router VM: WAN ist verbunden zum vSwitch1, welcher wiederum zum Uplink vom Provider angehängt ist.
Die Router VM hat drei weitere NICs. Jede NIC ist an einen anderen vSwitch angeschlossen.
Jede VM ist an jeweils einen eigenen VSwitch angeschlossen. Auf der Router VM wird jedes Interface mit einem eigenen /30 IP Netz konfiguriert (1IP für Netz, 1IP für Router VM, 1IP für VM, 1IP für Broadcast). Wird eine andere IP Verwendet, so liegt dies ausserhalb des Netzes, und somit verwirft die Router VM diese Packete, sprich die VM kann die anderen VM's nicht beinflussen bzw. es ist kein IP Adresskonflikt möglich...

Gruss Mete
 
Dennoch schießt sich der jenige, der die IP falsch konfiguriert damit in die Ecke... Der Aufwand, das ganze richtig zu machen bleibt exakt identisch. Der Sinn ist also immernoch nicht gegeben.

Aber mir solls egal sein, mach halt wie du denkst ;)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh