Saturday, 19. April 2008
Türkische Peaks
Ich hab ja schonmal über unseren Zeitserver hier geschrieben und die Probleme, die die Clients anscheinend damit haben. Jetzt wollte ich mal wissen, wie viele "Kunden" unser Server eigentlich hat. Ein Dump über 24 Stunden brachte Klarheit. Der Trafficverlauf dieses Tages war wie üblich: Eine Grundlast von 1-2 kByte/s und ein paar Peaks mit einigen kByte/s.
Besonders überrascht hat mich die hohe Anzahl verschiedener Clients. 242634 verschiedene IP-Adressen schlugen beim Server auf, ein paar Clients werden sicher mehrfach gezählt, weil sie sich unter verschiedenen IP-Adressen melden, aber allzu gross sollte der Fehler bei einem Tag Messzeit nicht sein.
Eigentlich hatte ich mit ein paar Tausend Nutzern gerechnet. Anscheinend ist das pool.ntp.org-Projekt doch beliebter als ich dachte. Der Server ist zwar auch bei der Liste der öffentlichen Stratum-2-Server gelistet, aber ich denke, die werden eher wenige Leute verwenden. Der Traffic von ca. 10 GByte/Monat ist jedenfalls seit der Eintragung dort nicht merklich gestiegen.
Die Verteilung der Häufigkeit ist interessant:
Diese hohe Anzahl der Wenignutzer wundert mich ein bisschen. Üblicherweise greifen andere ntp-Server im 1024-Sekunden-Takt zu. Nur die "einfacheren" Systeme zur Synchronisation wie "ntpdate" oder der Client von Windows synchronisieren sich seltener. Anscheinend verwenden doch ziemlich viele die einfachen Systeme statt sich mit einem ntpd zu beschäftigen. Hat ja auch Sinn, ein Rechner ohne besondere Anforderungen sollte mit 1 Synchronisation pro Tag oder pro Woche gut über die Runden kommen, so schlecht sind die eingebauten Uhren schliesslich auch nicht und ein paar Sekunden Abweichung sollte kaum jemand merken. Vielleicht sind viele Clients auch nicht mal echte Rechner, sondern irgendwelche DSL-Router, die sich bei jeder Einwahl mal die Zeit abholen.
Am oberen Ende sieht es grausam aus. Hier dominieren einige wenige Rechner, die völlig sinnlos Anfragen durch die Welt schicken und sich im Minutentakt synchronisieren. Das oberste halbe Prozent der Vielnutzer macht 30% des Traffics aus, 6% verbraucht allein der Spitzenreiter, ein Rechner der Humboldt-Universität zu Berlin, wo sie anscheinend sehr schlechte Rechneruhren sehr häufig synchronisieren müssen. Das ganze sieht nach einem NAT-Gateway für viele Uni-Rechner aus, weshalb auch meine automatische Aussperrung aufdringlicher Clients nicht hinhaut. Möglicherweise verhindert dieses Gateway sogar die Antworten des Servers und die Leute dort profitieren garnicht von ihrer Hartnäckigkeit.
Die Aufschlüsselung nach Ländern ist eher langweilig. Drei Länder bekommen 95% des Traffics ab, der Rest verteilt sich gleichmässig auf die ganze Welt.
Der grosse Anteil deutscher Clients war zu erwarten. Man sucht sich ja wegen der Paketlaufzeit gezielt möglichst nahe Server zur Synchronisation aus, der Pool ist auch "national" organisiert und liefert z.B. unter de.pool.ntp.org eine Liste deutscher Zeitserver aus und unter europe.pool.ntp.org eine Liste europäischer.
Die türkischen Clients überraschen auch nicht gross. Die Türk Telekom verkauft anscheinend DSL-Modems oder Router an ihre Kunden, die auf europe.pool.ntp.org voreingestellt sind. Auf diese Weise spart sich dieser Provider einen eigenen Server für seine Kunden und lässt den Pool für sich arbeiten.
Eigentlich ist die Lastverteilung im Pool gerecht geregelt. Jede Anfrage nach "europe.pool.ntp.org" wird mit einem anderen Satz von 5 IP-Adressen beantwortet, die der Nameserver des Pools aus seiner Liste nimmt. Allerdings fragen die Clients nicht den Nameserver des Pools, sondern einen der Nameserver ihres Providers, der die Frage weitervermittelt und die Antwort für einige Zeit speichert und innerhalb dieser Zeit nicht erneut nachfragt. Die Gültigkeitsdauer der Antwort bestimmt der Poolnamesever, zur Zeit sind dort 20 Minuten eingestellt. Aus Sicht des Poolnameservers ist das vernünftig, er hält sich so die vielen Clients vom Leib und lässt die Nameserver der Provider arbeiten. Genau dafür ist diese Gültigkeitsdauer im Nameservice auch gedacht.
Aus Sicht der 5 einzelnen ntp-Server bedeutet das, dass sie für 20 Minuten die einzig zuständigen Zeitserver für ganz viele Clients eines Providers sind. Falls der Provider nur einen Nameserver hat, müssen sie sogar ganz allein sämtliche Kunden dieses Providers bedienen. Bei Langzeitnutzern als Clients würde das auch nichts machen, die fragen einmal beim booten nach und bleiben dann bei einem bestimmten Server. Die überwiegende Anzahl der "Einmalsynchronisierer" kommt aber dabei als Peak auf diese fünf Server zu.
Bei Kunden normaler Provider fallen diese Lastspitzen fast nicht auf, es kommen ja nicht alle Nameserver aller Provider gleichzeitig auf die Idee, ausgerechnet unseren Zeitserver zu speichern. Lediglich t-online und deutsche Telekom sind überhaupt in der Verteilung der Last zu sehen, weil der magentane Riese für 10% aller deutschen Kunden steht. Ich hab die Zuordnung zum Provider anhand des DNS gemacht, Clients mit eigenem Eintrag in den Nameserver werden also nicht zugeordnet. Viele der Kunden "sonstiger" Provider dürften also in Wirklichkeit zu einem der grossen Provider gehören, so erkläre ich mir jedenfalls die hohe Korrelation "Sonstiger" Provider mit der T-Firma.
Die Türken dagegen scheinen für DSL-Leitungen ein recht starkes Monopol der Türk Telekom zu haben. Und so werden auf einen Schlag die Hälfte aller türkischen DSL-Modems an unseren ntp-Server verwiesen. Die Auswertung der Peaks in den frühen Morgenstunden zeigt recht deutlich die geringen Schwankungen bei den anderen Providern im Vergleich zu den Clients der Türk Telekom.
"Kleinprovider" wie Arcor und Alice haben ebenfalls ihre Spitzenzeiten, die gehen allerdings in der Masse ihres grossen Konkurrenten unter. Ihre Peaks bestehen aus einer handvoll Clients mit ein paar Paketen pro Minute:
Wirklich hoch werden die Berge, wenn zufällig mehrere Nameserver der Türk Telekom auf einen einzelnen ntp-Server zeigen. der Berg um 12 lässt sich jedenfall ganz gut mit einem Nameserver für die erste halbe Stunde und einem zusätzlichen Nameserver für den Rest der Zeit erklären (Einheit der y-Achse ist bei diesen Diagrammen übrigens Pakete/Zehntelstunde)
Wenn man den Traffic allein betrachtet, sollten die türkischen Peaks kein allzu grosses Problem darstellen, ich schreibe hier ja nur über ein paar kByte/s, also keine wirklich interessante Datenmenge. Selbst in Peaks habe ich noch nie über 20 oder 30kByte/s beobachtet. Im Vergleich zum Webserver hier ist das eher wenig, zumal dort die Besucher wesentlich unregelmässiger kommen.
Was aber wirklich ein Problem darstellt ist die grosse Anzahl der Clients. Viele ntp-Server hängen hinter Routern und Firewalls, die in irgendeiner Form speichern, welche Verbindungen gerade aktiv sind, und haben nur begrenzt Platz in ihrer Tabelle offener Verbindungen. Das wäre zwar in vielen Fällen nicht nötig, im Falle von ntp, das das udp-Protokoll verwendet, schon fast unsinnig, wird aber trotzdem so gemacht. In manchen Fällen kann man das auch auschalten, in manchen auch nicht, weil die Firewall einfach an dieser Stelle nicht konfiguriert werden kann oder der Betreuer derselben über die Anzahl der zulässigen Verbindungen nicht diskutieren möchte.
Rechner hinter Firewalls mit knapp bemessenem Tabellenplatz für offene Verbindungen kommen also als Zeitserver für europe.pool.ntp.org nicht in Frage. Sobald deren Tabelle mit z.B. 8000 oder 16000 Verbindungen vollgelaufen ist, stellen die den Betrieb auf allen Internetprotokollen ein und warten erstmal ab. Das stört natürlich ungemein, wenn man die Kiste in erster Linie als Web/Mail/Fileserver betreiben möchte und Zeitservice nur ein Nebenjob ist. Folgerndes Bild zeigt die Anzahl der Verbindungen, die blaue Linie steht für das udp-Protokoll.
Aus meiner Sicht gibt es keine. Die Türken von unserem Server aussperren ist gemein. Schliesslich ist der einzelne Kunde eines fiesen Providers nicht schuld. Allen Kunden der Türk Telekom die falsche Zeit zu liefern würde gehen, gilt aber als unehrenhaft. So bliebe nur den Nameserver des Providers abzuweisen oder die eigentlich vorgeschriebene Lösung für Firmen, die den Pool nutzen wollen: Speziell für ihn die IP-Adresse eines speziellen Zeitserver als Antwort zu schicken. Der darf dann auch gern in Ankara oder Istanbul stehen.
Für eine freundliche Lösung, die die Kunden nicht im Regen stehen lässt, bräuchte man aber Kontakt zu diesem Provider. Das haben auch schon ein paar Leute aus dem Pool probiert, aber der scheint recht unzugänglich zu sein. Möglicherweise scheitert es auch nur an den mangelnden Sprachkenntnissen.
Die Clients und der Traffic
Besonders überrascht hat mich die hohe Anzahl verschiedener Clients. 242634 verschiedene IP-Adressen schlugen beim Server auf, ein paar Clients werden sicher mehrfach gezählt, weil sie sich unter verschiedenen IP-Adressen melden, aber allzu gross sollte der Fehler bei einem Tag Messzeit nicht sein.
Eigentlich hatte ich mit ein paar Tausend Nutzern gerechnet. Anscheinend ist das pool.ntp.org-Projekt doch beliebter als ich dachte. Der Server ist zwar auch bei der Liste der öffentlichen Stratum-2-Server gelistet, aber ich denke, die werden eher wenige Leute verwenden. Der Traffic von ca. 10 GByte/Monat ist jedenfalls seit der Eintragung dort nicht merklich gestiegen.
Die Verteilung der Häufigkeit ist interessant:
- 30% der Clients haben nur einmal gefragt
- 84% der Clients haben weniger als 6 Pakete verschickt
- 98% der Clients haben maximal 1x/Stunde zugegriffen
Diese hohe Anzahl der Wenignutzer wundert mich ein bisschen. Üblicherweise greifen andere ntp-Server im 1024-Sekunden-Takt zu. Nur die "einfacheren" Systeme zur Synchronisation wie "ntpdate" oder der Client von Windows synchronisieren sich seltener. Anscheinend verwenden doch ziemlich viele die einfachen Systeme statt sich mit einem ntpd zu beschäftigen. Hat ja auch Sinn, ein Rechner ohne besondere Anforderungen sollte mit 1 Synchronisation pro Tag oder pro Woche gut über die Runden kommen, so schlecht sind die eingebauten Uhren schliesslich auch nicht und ein paar Sekunden Abweichung sollte kaum jemand merken. Vielleicht sind viele Clients auch nicht mal echte Rechner, sondern irgendwelche DSL-Router, die sich bei jeder Einwahl mal die Zeit abholen.
Am oberen Ende sieht es grausam aus. Hier dominieren einige wenige Rechner, die völlig sinnlos Anfragen durch die Welt schicken und sich im Minutentakt synchronisieren. Das oberste halbe Prozent der Vielnutzer macht 30% des Traffics aus, 6% verbraucht allein der Spitzenreiter, ein Rechner der Humboldt-Universität zu Berlin, wo sie anscheinend sehr schlechte Rechneruhren sehr häufig synchronisieren müssen. Das ganze sieht nach einem NAT-Gateway für viele Uni-Rechner aus, weshalb auch meine automatische Aussperrung aufdringlicher Clients nicht hinhaut. Möglicherweise verhindert dieses Gateway sogar die Antworten des Servers und die Leute dort profitieren garnicht von ihrer Hartnäckigkeit.
Die Aufschlüsselung nach Ländern ist eher langweilig. Drei Länder bekommen 95% des Traffics ab, der Rest verteilt sich gleichmässig auf die ganze Welt.
- 46% des Verkehrs geht nach Deutschland
- 45% geht in die Türkei
- 4% nach Grossbritanien
Der grosse Anteil deutscher Clients war zu erwarten. Man sucht sich ja wegen der Paketlaufzeit gezielt möglichst nahe Server zur Synchronisation aus, der Pool ist auch "national" organisiert und liefert z.B. unter de.pool.ntp.org eine Liste deutscher Zeitserver aus und unter europe.pool.ntp.org eine Liste europäischer.
Die türkischen Clients überraschen auch nicht gross. Die Türk Telekom verkauft anscheinend DSL-Modems oder Router an ihre Kunden, die auf europe.pool.ntp.org voreingestellt sind. Auf diese Weise spart sich dieser Provider einen eigenen Server für seine Kunden und lässt den Pool für sich arbeiten.
Die Peaks
Eigentlich ist die Lastverteilung im Pool gerecht geregelt. Jede Anfrage nach "europe.pool.ntp.org" wird mit einem anderen Satz von 5 IP-Adressen beantwortet, die der Nameserver des Pools aus seiner Liste nimmt. Allerdings fragen die Clients nicht den Nameserver des Pools, sondern einen der Nameserver ihres Providers, der die Frage weitervermittelt und die Antwort für einige Zeit speichert und innerhalb dieser Zeit nicht erneut nachfragt. Die Gültigkeitsdauer der Antwort bestimmt der Poolnamesever, zur Zeit sind dort 20 Minuten eingestellt. Aus Sicht des Poolnameservers ist das vernünftig, er hält sich so die vielen Clients vom Leib und lässt die Nameserver der Provider arbeiten. Genau dafür ist diese Gültigkeitsdauer im Nameservice auch gedacht.
Aus Sicht der 5 einzelnen ntp-Server bedeutet das, dass sie für 20 Minuten die einzig zuständigen Zeitserver für ganz viele Clients eines Providers sind. Falls der Provider nur einen Nameserver hat, müssen sie sogar ganz allein sämtliche Kunden dieses Providers bedienen. Bei Langzeitnutzern als Clients würde das auch nichts machen, die fragen einmal beim booten nach und bleiben dann bei einem bestimmten Server. Die überwiegende Anzahl der "Einmalsynchronisierer" kommt aber dabei als Peak auf diese fünf Server zu.
Bei Kunden normaler Provider fallen diese Lastspitzen fast nicht auf, es kommen ja nicht alle Nameserver aller Provider gleichzeitig auf die Idee, ausgerechnet unseren Zeitserver zu speichern. Lediglich t-online und deutsche Telekom sind überhaupt in der Verteilung der Last zu sehen, weil der magentane Riese für 10% aller deutschen Kunden steht. Ich hab die Zuordnung zum Provider anhand des DNS gemacht, Clients mit eigenem Eintrag in den Nameserver werden also nicht zugeordnet. Viele der Kunden "sonstiger" Provider dürften also in Wirklichkeit zu einem der grossen Provider gehören, so erkläre ich mir jedenfalls die hohe Korrelation "Sonstiger" Provider mit der T-Firma.
Die Türken dagegen scheinen für DSL-Leitungen ein recht starkes Monopol der Türk Telekom zu haben. Und so werden auf einen Schlag die Hälfte aller türkischen DSL-Modems an unseren ntp-Server verwiesen. Die Auswertung der Peaks in den frühen Morgenstunden zeigt recht deutlich die geringen Schwankungen bei den anderen Providern im Vergleich zu den Clients der Türk Telekom.
"Kleinprovider" wie Arcor und Alice haben ebenfalls ihre Spitzenzeiten, die gehen allerdings in der Masse ihres grossen Konkurrenten unter. Ihre Peaks bestehen aus einer handvoll Clients mit ein paar Paketen pro Minute:
Wirklich hoch werden die Berge, wenn zufällig mehrere Nameserver der Türk Telekom auf einen einzelnen ntp-Server zeigen. der Berg um 12 lässt sich jedenfall ganz gut mit einem Nameserver für die erste halbe Stunde und einem zusätzlichen Nameserver für den Rest der Zeit erklären (Einheit der y-Achse ist bei diesen Diagrammen übrigens Pakete/Zehntelstunde)
Das Problem
Wenn man den Traffic allein betrachtet, sollten die türkischen Peaks kein allzu grosses Problem darstellen, ich schreibe hier ja nur über ein paar kByte/s, also keine wirklich interessante Datenmenge. Selbst in Peaks habe ich noch nie über 20 oder 30kByte/s beobachtet. Im Vergleich zum Webserver hier ist das eher wenig, zumal dort die Besucher wesentlich unregelmässiger kommen.
Was aber wirklich ein Problem darstellt ist die grosse Anzahl der Clients. Viele ntp-Server hängen hinter Routern und Firewalls, die in irgendeiner Form speichern, welche Verbindungen gerade aktiv sind, und haben nur begrenzt Platz in ihrer Tabelle offener Verbindungen. Das wäre zwar in vielen Fällen nicht nötig, im Falle von ntp, das das udp-Protokoll verwendet, schon fast unsinnig, wird aber trotzdem so gemacht. In manchen Fällen kann man das auch auschalten, in manchen auch nicht, weil die Firewall einfach an dieser Stelle nicht konfiguriert werden kann oder der Betreuer derselben über die Anzahl der zulässigen Verbindungen nicht diskutieren möchte.
Rechner hinter Firewalls mit knapp bemessenem Tabellenplatz für offene Verbindungen kommen also als Zeitserver für europe.pool.ntp.org nicht in Frage. Sobald deren Tabelle mit z.B. 8000 oder 16000 Verbindungen vollgelaufen ist, stellen die den Betrieb auf allen Internetprotokollen ein und warten erstmal ab. Das stört natürlich ungemein, wenn man die Kiste in erster Linie als Web/Mail/Fileserver betreiben möchte und Zeitservice nur ein Nebenjob ist. Folgerndes Bild zeigt die Anzahl der Verbindungen, die blaue Linie steht für das udp-Protokoll.
Die Lösung
Aus meiner Sicht gibt es keine. Die Türken von unserem Server aussperren ist gemein. Schliesslich ist der einzelne Kunde eines fiesen Providers nicht schuld. Allen Kunden der Türk Telekom die falsche Zeit zu liefern würde gehen, gilt aber als unehrenhaft. So bliebe nur den Nameserver des Providers abzuweisen oder die eigentlich vorgeschriebene Lösung für Firmen, die den Pool nutzen wollen: Speziell für ihn die IP-Adresse eines speziellen Zeitserver als Antwort zu schicken. Der darf dann auch gern in Ankara oder Istanbul stehen.
Für eine freundliche Lösung, die die Kunden nicht im Regen stehen lässt, bräuchte man aber Kontakt zu diesem Provider. Das haben auch schon ein paar Leute aus dem Pool probiert, aber der scheint recht unzugänglich zu sein. Möglicherweise scheitert es auch nur an den mangelnden Sprachkenntnissen.
Trackbacks
Trackback-URL für diesen Eintrag