ISC DHCP Server Cluster: partner-down state beenden

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Benutzeravatar
pangu
Beiträge: 1400
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

ISC DHCP Server Cluster: partner-down state beenden

Beitrag von pangu » 21.09.2013 12:33:27

Hi Leute,

ich setze ISC DHCP-Server auf zwei verschiedenen Hosts ein, die im Cluster arbeiten (primary/secondary). Dabei wird der Pool 192.168.1.1-254 so aufgeteilt, dass quasi Host1 die IP-Bereich 192.168.1.1-128 reserviert hat, und der Host2 sich um .129-254 kümmert. Das ist ein interner Prozess von ISC DHCP, das manual beschreibt das so:
The failover protocol allows two DHCP servers (and no more than two) to share a common address pool. Each server will have about half of the available IP addresses in the pool at any given time for allocation. If one server fails, the other server will continue to renew leases out of the pool, and will allocate new addresses out of the roughly half of available addresses that it had when communications with the other server were lost.
Wenn jetzt der Host2 ausfallen würde, entsteht folgendes Problem: der Client der von Host2 ursprünglich die Lease 192.168.1.222 erhalten hatte möchte nun nach Ablauf der eingestellten Lease-Periode (in meinem Falle 1 Tag) seine Lease erneuern. Der Host2 ist jedoch nicht erreichbar, und nur ER ist für diese Lease verantwortlich. Der Client würde also seine Lease nicht mehr erneuern können. Neue Clients die sich registrieren haben keine Probleme, den sie würden von Host1 abgearbeitet und erhalten von dem eine IP (irgendeine zwischen .1 und .128 die eben frei ist).

Aufgrund von großen und etwas länger anhaltenden Wartungsarbeiten musste ich meinen Host2 herunterfahren und durfte das Problem selbst erleben, das dadurch zustande kam. Abhilfe konnte ich nur dadurch schaffen, indem ich dem Host1 explizit und manuell in den Modus "partner-down" gesetzt habe. Dadurch weiß der Host1, dass sein Partner wirklich unerreichbar ist, und nun kümmert er sich ebenfalls für den Bereich, für den ursprünglich Host2 verantwortlich war (also für .129 bis .254). Nur so konnten alle Clients mit abgelaufener Lease zwischen .129 und .254 wieder eine gültige IP erhalten, und zwar vom Host1. Dadurch verloren sie sogar ihre alte Lease, sie bekamen von Host1 eine neue IP zugewiesen (was mich aber nicht sonderlicht störte). Das manual beschreibt das so:
It is possible during a prolonged failure to tell the remaining server that the other server is down, in which case the remaining server will (over time) reclaim all the addresses the other server had available for allocation, and begin to reuse them. This is called putting the server into the PARTNER-DOWN state.
Den Host1 (also der wo noch arbeitet) kann man durch zwei Möglichkeitenin den Zustand "partner-down" stellen. Ich habe das mit der Methode gemacht, indem man das lease-file bearbeitet. Das manual sagt:
You can put the server into the PARTNER-DOWN state either by using the omshell (1) command or by stopping the server, editing the last peer state declaration in the lease file, and restarting the server. If you use this last method, be sure to leave the date and time of the start of the state blank:

failover peer name state {
my state partner-down;
peer state state at date;
}
Ich habe also auf Host1 den DHCP-Server mit /etc/init.d/isc-dhcp-server stop erst beendet und dann die Datei /var/lib/dhcp/dhcpd.leases geöffnet. Dort habe ich den letzten Abschnitt gesucht der mit dem oben genannten Block existiert, und dort den state auf "partner-down" in der Zeile my state gesetzt. Datum+Zeit habe ich unberührt belassen.
Nachdem ich den Host1 DHCP-Server wieder gestartet habe, konnten all die Clients die zuvor eine IP aus Bereich .129-.254 hatten, endlich wieder eine gültige Lease vom Host1 erhalten und somit waren sie wieder im Netzwerk.

Nun habe ich den Host2 wieder soweit und möchte den hochfahren, bin mir aber nicht sicher ob ich den einfach so nun hochfahren kann und er sich automatisch mit Host1 wieder verbindet und sich synchronisiert. Das manual sagt dazu:
When the other server comes back online, it should automatically detect that it has been offline and request a complete update from the server that was running in the PARTNER-DOWN state, and then both servers will resume processing together.
Demnach interpretier ich das also so, dass ich wirklich einfach nur meinen Host2 wieder hochfahren könnte und das alles automatisch abgeglichen wird und das Cluster wieder "hoffentlich" in den Modus "Normal-communication" gesetzt wird.

Die folgenden Zeilen aus dem manual beunruhigen mich jedoch ein wenig:
It is possible to get into a dangerous situation: if you put one server into the PARTNER-DOWN state, and then *that* server goes down, and the other server comes back up, the other server will not know that the first server was in the PARTNER-DOWN state, and may issue addresses previously issued by the other server to different clients, resulting in IP address conflicts. Before putting a server into PARTNER-DOWN state, therefore, make sure that the other server will not restart automatically.
Eigentlich sollte ich mir ja diesbezüglich aber keine Sorgen machen sollen, denn Host1 den ich in den Modus "partner-down" versetzt habe, war ja nonstop online und Host2 war nonstop offline.

Bevor ich jedoch den Host2 nun hochfahre, wollte ich auch eure Meinung einholen wie ihr das seht und ob ich den Host2 tatsächlich bedenkenlos hochfahren kann. Sicher ist sicher :)
Danke euch und viele Grüße,
Pangu.
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Benutzeravatar
pangu
Beiträge: 1400
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

Re: ISC DHCP Server Cluster: partner-down state beenden

Beitrag von pangu » 22.09.2013 12:18:26

Ich antworte jetzt mal selbst. Nach reichtlicher Überlegung habe ich es gewagt und den Host2 wieder gestartet

Im Log des Host1 tauchten dabei folgende relevante Informationen auf, während der Host2 seinen DHCP-Server wieder startete:
Sep 22 12:04:36 r4dv3ld002 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: peer moves from normal to normal
Sep 22 12:04:36 r4dv3ld002 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: peer moves from normal to recover
Sep 22 12:04:36 r4dv3ld002 dhcpd: Update request all from DHCP-Cluster Beispiel GmbH: sending update
Sep 22 12:04:36 r4dv3ld002 dhcpd: bind update on 192.168.200.44 from DHCP-Cluster Beispiel GmbH rejected: 192.168.200.44: invalid state transition: active to free
Sep 22 12:04:36 r4dv3ld002 dhcpd: bind update on 192.168.200.16 from DHCP-Cluster Beispiel GmbH rejected: 192.168.200.16: invalid state transition: active to free
Sep 22 12:04:36 r4dv3ld002 dhcpd: bind update on 192.168.200.147 from DHCP-Cluster Beispiel GmbH rejected: 192.168.200.147: invalid state transition: active to free
Sep 22 12:04:36 r4dv3ld002 dhcpd: bind update on 192.168.200.124 from DHCP-Cluster Beispiel GmbH rejected: 192.168.200.124: invalid state transition: active to free
[...]
Sep 22 12:04:36 r4dv3ld002 dhcpd: bind update on 192.168.200.211 from DHCP-Cluster Beispiel GmbH rejected: 192.168.200.211: invalid state transition: active to free
Sep 22 12:04:38 r4dv3ld002 dhcpd: Sent update done message to DHCP-Cluster Beispiel GmbH
Sep 22 12:04:38 r4dv3ld002 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: peer moves from recover to recover-done
Sep 22 12:04:38 r4dv3ld002 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: I move from partner-down to normal
Sep 22 12:04:38 r4dv3ld002 dhcpd: balancing pool 26997b0 192.168.0.0/16 total 254 free 184 backup 55 lts 64 max-own (+/-)24
Sep 22 12:04:38 r4dv3ld002 dhcpd: balanced pool 26997b0 192.168.0.0/16 total 254 free 96 backup 143 lts -24 max-misbal 36
Sep 22 12:04:38 r4dv3ld002 dhcpd: Sending updates to DHCP-Cluster Beispiel GmbH.
Sep 22 12:04:38 r4dv3ld002 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: peer moves from recover-done to normal
Im Log des bereits aktiven Host1 erschienen folgende Logs:
Sep 22 12:04:51 r4dv3ld003 dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1
Sep 22 12:04:51 r4dv3ld003 dhcpd: Copyright 2004-2010 Internet Systems Consortium.
Sep 22 12:04:51 r4dv3ld003 dhcpd: All rights reserved.
Sep 22 12:04:51 r4dv3ld003 dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Sep 22 12:04:51 r4dv3ld003 dhcpd: Wrote 253 leases to leases file.
Sep 22 12:04:51 r4dv3ld003 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: I move from normal to startup
Sep 22 12:04:51 r4dv3ld003 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: peer moves from normal to partner-down
Sep 22 12:04:51 r4dv3ld003 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: I move from startup to recover
Sep 22 12:04:51 r4dv3ld003 dhcpd: Sent update request all message to DHCP-Cluster Beispiel GmbH
Sep 22 12:04:53 r4dv3ld003 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: peer update completed.
Sep 22 12:04:53 r4dv3ld003 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: I move from recover to recover-done
Sep 22 12:04:53 r4dv3ld003 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: peer moves from partner-down to normal
Sep 22 12:04:53 r4dv3ld003 dhcpd: failover peer DHCP-Cluster Beispiel GmbH: I move from recover-done to normal
Sep 22 12:04:53 r4dv3ld003 dhcpd: balancing pool 25755e0 192.168.0.0/16 total 254 free 118 backup 55 lts -31 max-own (+/-)17
Sep 22 12:04:53 r4dv3ld003 dhcpd: balanced pool 25755e0 192.168.0.0/16 total 254 free 118 backup 55 lts -31 max-misbal 26
Sieht also aus, als ob alles im grünen Bereich wäre und der Cluster wieder ordnungsgemäß funktioniere und aktiv ist. In diesem Sinne, schönen Sonntag to @ll

Grüße,
Pangu
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Antworten