Parad0x hat heute Nacht den Automatischen Reboot wohl nicht überstanden…
Neustart hat er dem syslog nach wohl gemacht. Einziges was mir im syslog auf die schnelle aufgefallen ist das er wohl nach dem Neustart mit einer falschen Uhrzeit/Datum gestartet ist bis er sich irgendwann per NTP die richtige Zeit geholt hatte…
Zur Belustigung war das Datum auch noch der 1.April
@descilla es gab keinen Grafana Alert darüber. Es kamen stumpf keine Werte mehr in Grafana an.
Hab Parad0x Rebootet und die Knoten neu verteilt. Es gehen laut vnstat rund 100 Mbit im Moment durch Parad0x von daher nehme ich an das er läuft, aber Werte kommen im Grafana nach wie vor keine mehr an.
Edith: collectd auf Parad0x neu gestartet --> kommen wieder Werte an…
Für Kea kann jetzt neben memfile auch PostgreSQL als Storage Backend für die Leases genutzt werden:
Außerdem habe ich das Ganze mal auf des2 ausgerollt:
Ich habe die PostgreSQL Konfiguration erstmal so gelassen, wie sie ausgeliefert wurde. Vielleicht mögen da Leute mit mehr Erfahrung als ich mal drüber schauen, @kgbvax z. B… Ich werde zeitnah aber auch Leistungsdaten des PostgreSQL ins collectd schubsen.
PostgreSQL für kea auf remue-09 ebenfalls konfiguriert. Dist-upgrade durchgeführt, Kernel auf 4.9 (Debian backports) upgegraded und rebooted. Dabei ist aufgefallen, dass das systemd script für kea noch angepasst werden muss. Als kea starten wollte, war die Datenbank noch nicht da.
PSQL4Kea läuft jetzt ebenfalls auf nightbounce. Zuvor habe ich die Konfiguration „reboot sicher“ gemacht. Es wird als kea erst gestartet, nachdem der psql service gestartet wurde:
Morgen (oder in den nächsten Tagen) baue ich dann in das kea-collectd Script eine Abfrage ein, um die „pool utilization“ zu erfassen.
PSQL4Kea läuft jetzt auf allen Gateways. Ebenfalls die collectd rollen auf den Gateways neu ausgerollt.
Außerdem habe ich das Logging des Kea wieder auf WARN runter gedreht. Da unsere DHCP Probleme nun hinreichend untersucht wurden und nun quantitativ über collectd erfasst werden. Die Art des Loggings lässt sich nun über Variablen konfigurieren:
Auf dem Kartenserver hat der Let’s Encrypt Cronjob das Zertifikat für die .org Adresse wieder im nginx aktiviert wodurch die Karte nicht erreichbar war. Habe die komplette Konfig für die .org Domain aus dem acme Client entfernt und das Zertifikat für die .de neu generiert und wieder in den nginx gehängt. ==> Tut wieder.
Auf des2 und remue-09 war die Nacht über die fork-rate so bei 200/s. Es scheint so, als hätte sich der tunneldigger wieder in einen merkwürdigen Zustand versetzt.
...
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 586!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 385!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 728!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 732!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 582!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 361!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 319!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 396!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 391!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 435!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 441!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 406!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 395!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 414!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 431!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 427!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 445!
Mon, 03 Apr 2017 06:44:44 ERROR Failed to setup tunnel with id 416!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 425!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 437!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 403!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 404!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 440!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 439!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 392!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 399!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 426!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 389!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 434!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 422!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 443!
Mon, 03 Apr 2017 06:44:45 ERROR Failed to setup tunnel with id 583!
...
Beide TD neu gestartet. Läuft seit dem wieder. Kurz danach auf remue-09 zwecks rebalancing erneut neu gestartet, da der dom-01 auf remue-09 innerhalb kürzester zeit die dhcpv4 leases ausgegangen sind.
Kurz zu dem Async Commit ^^: Das kann man echt nur bringen wenn die Daten nicht kritisch sind, also nicht für anderer Zwecke übernehmen. Beim Crash gehen in diesem Falle maximal 3 * bg_writer_delay Daten verloren (etwas über eine Sekunde aktuell). Die Konsistenz der Daten ist allerdings nicht bedroht - im Worst Case fehlen nur die letzten. Schien mir für DHCP Leases vertretbar
Selbst mehrere Minuten wären in unserem Szenario vertretbar (im Vergleich zur vorherigen Situation). Aktuell (bei verwendung der „build-in“-Database csv->memfile) war es nämlich so, dass die kea server sich beim Starten (z. B. nach reboot) direkt auf die Nase gelegt haben (wenn sie länger als ca. 7 Tage liefen), weil sie sich an der Dateigröße verschluckt haben (laut kea mailinglisten ist das bekannt und „ist halt so“). Ich habe dann immer von Hand die lease-Datei löschen müssen, da war dann alles weg. Daher wurde es Zeit für ein richtiges DBS.
Man kann jetzt über DHCPv4 mehrere Nameserver announcen. Das ist konfiguierbar und es gibt zwei Typen: Alle anderen Gateways der Domäne als Nameserver und zusätzliche Namensserver (z. B. „externe“), die in den host_vars/group_vars in einer Liste angegeben werden:
Wenn die dhclients
auch so implementiert haben, sollte immer der Namensserver bevorzugt werden, von dem das DHCP Lease ausgestellt wurde.
Ich habe das auf remue-09 und des2 ausgerollt und ein stichprobenartiger Test verlief einwandfrei. Als zusätzliche (externe) Namensserver habe ich den vom FoeBud/Digitalcourage und den vom CCC in Berlin gesetzt.
Da Remue-09 die IP’s für Dom01 ausgegangen sind um ca 9.00 Uhr den Tunneldigger auf Remue-09 neu gestartet um einige Knoten aus Domäne 01 zu Des2 zu schubsen…
Der geplante reboot auf remue-09 heute Nacht war leider nicht erfolgreich (hing beim herunterfahren, hat nicht alle interfaces runter bekommen). Vorhin daher per Hand neu gestartet und ein paar l2tp verbindungen drauf geworfen.
