Welches Verhalten ist bei mehreren Hostnameneinträgen mit unterschiedlichen IP-Adressen in /etc/hosts zu erwarten?

Welches Verhalten ist bei mehreren Hostnameneinträgen mit unterschiedlichen IP-Adressen in /etc/hosts zu erwarten?

Ich weiß, das wurde diskutiertIn mehrere setzt, aber es scheint noch keine endgültige Antwort zu geben - zumindest nicht für RHEL 6. Ich hoffe nur, dass jemand darauf hinweisen kannWiees funktioniert, also kann ich ein bisschen graben.

Kurzfassung:Ich habe einen OpenVZ-Hostknoten mit einer öffentlichen IP-Adresse, der als Reverse-Proxy für eine Reihe von OpenVZ-Containern mit privaten IP-Adressen fungiert. Ich habe 2 Container mit demselben Namen erstellt (wenn Sie wissen möchten, warum, springen Sie zur Langfassung unten) und der HN hat auch diese Einträge (unter anderem) in seinem /etc/hosts:

# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy

Ich kann OpenVZ verwenden, um jeden dieser Hosts nach ID anzuhalten/fortzusetzen, und der Reverse-Proxy scheint Anfragen auf magische Weise an den gerade laufenden Host weiterzuleiten (z. B. an die IP-Adresse 10.0.0.130oder ) 10.0.0.131. Aber ich kann beim besten Willen nicht herausfinden, welche Software das macht. Ist es Apache? Ist es etwas im Netzwerksystem des HN? Etwas anderes? Es scheint zu funktionieren, aber ich würde gerne mehr darüber wissen, warum/wie, da es auch große Meinungsverschiedenheiten darüber zu geben scheint, ob essollenüberhaupt funktionieren. Um es klarzustellen: Ich suche hier nicht nach Round-Robin oder Lastausgleich. Nur nach einem einfachen, manuellen Umschalten von einem OpenVZ-Container zu einem anderen.

Lomg-Version:Während ich einige Skripte zum Erstellen und Verwalten einer Reihe von OpenVZ-Containern einrichtete, habe ich ein Skript namens erstellt, make_clone.shdas eine Vorlage verwendet und einen neuen Container erstellt. Das Skript verwendet zwei Parameter – die Container-ID und den gewünschten Hostnamen. Unter anderem weist es 10.0.0.*dem Container eine neue IP-Adresse zu und konfiguriert einige Netzwerke, wobei ein Element darin besteht, einen Eintrag in die Datei des Hostknotens einzufügen /etc/hosts.

Während ich einige Backup-/Wiederherstellungsskripte für diese Container testete, wollte ich „so tun“, als sei ein bestimmter Container gestorben, einen anderen mit demselben Namen starten und das Backup wiederherstellen. Anstatt den ursprünglichen Container tatsächlich zu löschen, nahm ich vzctl stop 130ihn einfach offline. Dann erstellte ich einen neuen Container mit der ID 131, aber mit demselben Namen. Nachdem er hochgefahren war, stellte ich die MySQL-Datenbank wieder her und überprüfte (über einen Browser), ob ich darauf zugreifen konnte – er läuft mit Joomla mit einigen Anpassungen – und alles war in Ordnung.

Aber dann bemerkte ich, dass ich in den Hostknoten /etc/hosts(unter anderem) diese beiden Einträge hatte:

# Generated by make_clone.sh
10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy

Der Hostknoten fungiert auch als Reverse-Proxy. Nur der Hostknoten hat eine externe IP-Adresse und seine Apache-Konfiguration ordnet Subdomains effektiv Containern zu. Daher gibt es neben den oben genannten Einträgen in /etc/hosts auch Abschnitte wie diesen in der httpd-Konfiguration:

` Servername testbackup.xxx.yy

    ProxyRequests Off
    <Proxy *>
            Order deny,allow
            Allow from all
    </Proxy>

    ProxyPass /server-status !
    ProxyPass / http://testbackup.xxx.yy/
    ProxyPassReverse / http://testbackup.xxx.yy/

    <Location />
            Order allow,deny
            Allow from all
    </Location>

`

In dem Szenario, das ich beschreibe, würde es aufgrund der Skripte tatsächlich mit zwei dieser Abschnitte enden, aber sie wären identisch – es bezieht sich auf den Container nach Hostnamen, nicht nach IP, was mich glauben lässt, dass es nicht Apache an sich ist, das den „funktionierenden“ Container auswählt. Ich kann jetzt zu navigieren (natürlich unter Verwendung des echten Domänennamens) und Apache scheint die Anfragen problemlos an den von oder http://testbackup.xxx.yy/weiterzuleiten, der gerade aktiv ist. Ich kann zwischen ihnen wechseln, indem ich die OpenVZ-Container einfach anhalte/fortsetze.10.0.0.13010.0.0.131

Ich habe nicht damit gerechnet, dass das funktioniert – aber es ist schön, dass es funktioniert. Meine Frage ist: Sollte es funktionieren? Kann man sich darauf verlassen? Oder ist es nur ein Zufallsprodukt, das nicht mehr funktioniert, wenn der kleine Mist, der irgendwo in eine andere Konfigurationsdatei gelangt ist, aufgeräumt wird?

Antwort1

Da ein Host mehrere IP-Adressen haben kann, sehen Sie das erwartete Verhalten. Es ist, als ob Sie mehrere Spitznamen hätten, wie: Bossman, Haus, Jungle-Jim usw. Jeder, der mich kennt, weiß, dass das meine Spitznamen sind (es sind allerdings nicht wirklich meine Spitznamen).

Sofern Sie nicht versuchen, über eine IP-Adresse auf die Ressource zuzugreifen, sollten Ihre Systeme so funktionieren, als wäre nichts passiert. (Technisch gesehen sollte das Generieren einer neuen IP-Adresse auf einem Container Ihre Dienste nicht beeinträchtigen, solange diese Dienste nicht an die IP-Adresse gebunden sind. In Ihrem Fall hatten Sie vielleicht einfach Glück und Ihre Apps liefen reibungslos.)

Beispiel: Ich könnte einem Host 4 IP-Adressen zuweisen:

10.0.0.130 testbackup.xxx.yy
10.0.0.131 testbackup.xxx.yy
10.0.0.132 testbackup.xxx.yy
10.0.0.133 testbackup.xxx.yy

Beispiel 1

Alle diese IP-Adressen verweisen auftestbackup.xxx.yy, das heißt, wenn ich versuche, auftestbackup.xxx.yy, komme ich zu einem von ihnen, je nachdem, welche IP-Adresse zum Zeitpunkt meiner Anfrage aktiv/reagierend ist. Auch dies funktioniert nur, solange der Dienst, auf den Sie zugreifen möchten, nicht speziell an diese IP-Adresse gebunden ist.

Wenn Sie jedoch10.0.0.133und Sie haben versucht, auf die Ressource zuzugreifenspeziellab 10.0.0.133 (dh http://10.0.0.133/) würden Sie eine Fehlermeldung erhalten.

AKTUALISIEREN:

Wenn Sie Apache VirtualHosts verwenden:

<VirtualHost *:80>
DocumentRoot /www/example1
ServerName www.example.com

# Other directives here

</VirtualHost>

<VirtualHost *:80>
DocumentRoot /www/example2
ServerName www.example.org

# Other directives here

</VirtualHost>

Mit dieser Konfiguration können zwei Sites dieselbe IP-Adresse und denselben Port verwenden. Wenn Sie Ihre VirtualHosts so eingerichtet haben, übernimmt VirtualHosts Ihr automatisches Routing ( ServerNametheoretisch, wenn Sie beide Felder als denselben Host aufgeführt haben).

Sie haben angegeben, dass Sie OpenVZ verwenden. OpenVZ ermöglicht zwar den unabhängigen Betrieb Ihrer Sites, aber physisch befinden sie sich alle auf demselben Host. Sofern Sie nicht jedem einzelnen VE einen eigenen Hostnamen zuweisen und versuchen, auf diesen Hostnamen zuzugreifenspeziellWährend die Site nicht erreichbar ist, verhält sie sich wie erwartet, als wäre sie erreichbar.

Wenn Sie beispielsweise einer der OpenVZ/IP-Adressen einen anderen Hostnamen zugewiesen haben:

10.0.0.133 mybackup.xxx.yy

Wenn Sie es herunternehmen 10.0.0.133, können Sie von nicht mybackup.xxx.yymehr darauf zugreifen, aber von können Sie darauf zugreifen testbackup.xxx.yy(weil es über die anderen IP-Adressen läuft, die noch aktiv und mit verknüpft sind testbackup.xxx.yy).

Bildbeschreibung hier eingeben

verwandte Informationen