Éléments à prendre en compte lors de l'exécution de serveurs NTP publics

Ainsi, il m'est récemment apparu que puisque j'ai 3 horloges GPS dans mon réseau, je pouvais, techniquement, redonner un peu et servir du temps au reste du monde. Jusqu'à présent, je n'ai pas vraiment vu d'inconvénients avec ces idées, mais j'ai les questions suivantes;

1. Puis-je virtualiser cela? Je ne vais pas dépenser de l'argent et du temps à défendre le matériel pour cela, donc la virtualisation est un must. Étant donné que les serveurs auront accès à trois sources de la couche 1, je ne vois pas comment cela peut être un problème à condition que la configuration ntpd soit correcte

2. Quel type de trafic un serveur NTP public (faisant partie de pool.ntp.org) voit-il normalement? Et de quelle taille de machine virtuelle ai-je besoin pour cela? ntpd ne devrait pas être trop gourmand en ressources pour autant que je sache, mais je préfère le savoir à l'avance.

3. Quels aspects de sécurité y a-t-il? Je pense simplement installer ntpd sur deux machines virtuelles dans la DMZ, autoriser uniquement ntp à travers le FW, et seulement ntp sortir de la DMZ vers les serveurs internes ntp. Il semble également que certains paramètres ntp soient recommandés en fonction de la page du pool NTP, mais sont-ils suffisants? https://www.ntppool.org/join/configuration.html

4. Ils recommandent de ne pas configurer le pilote d'horloge LOCAL, est-ce équivalent à supprimer la configuration de la source horaire LOCAL des fichiers de configuration?

5. Autre chose à considérer?

Tout d'abord, c'est bon pour vous; c'est une chose utile et ouverte au public. Cela dit, et compte tenu de votre clarification, vous envisagez de créer une ou plusieurs machines virtuelles DMZ qui se synchroniseront et rendront public l'heure à partir de vos trois serveurs stratin-1 (internes) compatibles GPS Meinberg:

1. Edit : la virtualisation est discutée de temps en temps sur la liste des pools ; une récente date de juillet 2015, qui peut être suivie à partir de cet email . Ask Bjørn Hansen, le chef de projet, a posté sur le sujet et n'a pas dénoncé la virtualisation. De toute évidence, un certain nombre d'opérateurs de serveurs de pool se virtualisent en ce moment, donc je ne pense pas que quiconque vous tirera dessus, et comme une affiche le montre clairement, si vos serveurs ne sont pas fiables, le système de surveillance de pool les supprimera simplement du bassin. KVM semble être la technologie de virtualisation préférée; Je n'ai trouvé personne utilisant spécifiquement VMWare, donc je ne peux pas dire à quel point une virtualisation est "honnête". Peut-être le meilleur résumé sur le sujet dit

   Mes serveurs de pool sont virtualisés avec KVM sur mes propres hôtes KVM. La surveillance indique que le serveur est assez précis et fournit un temps stable pour les 2-3 dernières années. Mais je ne configurerais pas de serveur de pool sur un serveur virtuel loué d'un autre fournisseur.

2. Il s'agit du nombre moyen quotidien de clients distincts par seconde que je vois sur mon serveur de pool (au Royaume-Uni, dans les zones européennes et mondiales) au cours de l'année écoulée:

   

   Cela n'impose pratiquement aucune charge système détectable ( ntpdsemble utiliser entre 1% et 2% d'un CPU, la plupart du temps). À noter qu'à un moment donné de l'année, la charge a brièvement culminé à près d'un millier de clients par seconde (Max: 849,27); Je surveille la charge excessive et les alarmes ne se sont pas toutes déclenchées, donc je peux seulement noter que même ce niveau de charge n'a pas posé de problème, même brièvement.

3. Les configurations recommandées par le projet sont les meilleures pratiques et fonctionnent pour moi. J'utilise également iptablespour limiter les clients à deux paquets entrants dans une fenêtre de dix secondes (c'est incroyable le nombre de clients impolis qui pensent qu'ils devraient être libres d'éclater afin de régler rapidement leur propre horloge).

4. Ou supprimez toutes les lignes faisant référence aux adresses de serveur commençant par 127.127.

5. Les recommandations de bonnes pratiques recommandent également plus de trois horloges, vous pouvez donc choisir quelques autres serveurs publics ou serveurs de pool spécifiques, en plus de vos trois serveurs de la couche 1.

   Je noterais également que si vous envisagez de mettre ces deux machines virtuelles sur le même matériel hôte, vous devriez probablement exécuter celui-ci, mais doubler la bande passante déclarée au pool (c'est-à-dire accepter deux fois plus de requêtes que vous ne le feriez autrement). ).

Tout d'abord, félicitations pour une question NTP qui n'est pas du type facepalm. :-) J'ai inclus quelques graphiques au bas de cet article pour vous donner une idée des choses. La machine virtuelle en question est définie sur 100 Mbits / s dans le panneau de configuration du pool et se trouve au Royaume-Uni, en Europe et dans les pools mondiaux.

1. Je pense que MadHatter a bien couvert ce sujet - la virtualisation devrait bien se passer. Comme vous le dites, s'ils se nourrissent de vos strates 1 connectées au GPS, ils devraient être raisonnablement solides. D'après mon expérience, les machines virtuelles ont tendance à être un peu plus nerveuses que le métal nu en termes de fréquence (voir le graphique ci-dessous), mais c'est ce que vous attendez - elles ont affaire à une couche d'émulation d'horloge (espérons-le assez efficace) et potentiellement bruyante voisins. Si vous préférez ne pas voir ce genre de nervosité, utilisez plutôt des serveurs plus anciens ou des ordinateurs de bureau inutilisés comme votre DMZ stratum 2.

2. Cette machine virtuelle est 1 cœur, 2 Go de RAM, exécutant Ubuntu 16.04 LTS, virtualisée dans OpenStack (hyperviseur KVM). Comme vous pouvez le voir, la RAM est un peu exagérée.

3. Les paramètres recommandés - y compris le fait de ne pas configurer le pilote local - sont ceux par défaut dans Ubuntu 16.04. Je suis très proche de la configuration du stock, autre que la liste des pairs.

4. (voir au dessus)

5. Je commencerais probablement la bande passante sur le côté bas et augmenterais la bande passante après l'avoir surveillée un peu. Si vos machines virtuelles sont toutes proches les unes des autres et proches de vos strates 1 en termes de latence du réseau, je ferais probablement en sorte que toutes les machines virtuelles parlent à toutes les strates 1, et les paireraient probablement entre elles et activeraient également le mode orphelin.

Voici les graphiques - ils couvrent tous la même période d'environ 3 semaines, à l'exception de celui du réseau, qui avait quelques pics dus aux sauvegardes. Lorsque les pointes du réseau étaient là, je ne pouvais même pas voir le trafic NTP normal, alors j'ai zoomé un peu pour montrer l'arrière-plan habituel.

Décalage du système de fréquence du réseau de mémoire CPU

Quelques points à considérer avec NTP

Il y a déjà de bonnes réponses ici. J'ajoute juste quelques réflexions par souci d'exhaustivité basées sur mes propres expériences.

Je suggérerais d'activer la journalisation NTP et les asymétries d'horloge du graphique et les corrections sur le métal nu par rapport à la machine virtuelle en ce qui concerne cette discussion si cela est un problème. Je ne pense pas que cela puisse être généralisé facilement car le matériel et la configuration varient selon les implémentations. Il serait peut-être préférable d'obtenir vos propres numéros sur celui-ci.

J'ai toujours suggéré aux gens de choisir des rôles système de serveurs ou de périphériques réseau qui ont un temps CPU assez constant et qui ne sont pas des noyaux sans tic ou qui ont des modes d'économie d'énergie activés. Évitez particulièrement les démons de ligne cpuspeed ou speed govenors ou les économies d'énergie avancées sur les serveurs NTP, même s'ils ne sont que la strate 2 de votre ferme. Une certaine stabilité peut être acquise en n'allant jamais plus loin que C-State 1, mais votre consommation d'énergie augmentera.

J'essaie également de m'assurer que les gens choisissent une poignée de serveurs de la couche 1 qui sont à moins de 40 ms de la périphérie de leur réseau, puis les répartissent sur vos serveurs NTP de périphérie et m'assure qu'aucun 2 serveurs derrière le même SNAT de votre réseau ne parlent sur le même serveur de la couche 1. Dans la même veine que burst, il n'est pas judicieux d'avoir plusieurs serveurs derrière le même SNAT utilisant les mêmes serveurs en amont, car il leur apparaîtra que vous avez activé la rafale même si vous ne l'avez pas fait.

Vous devez toujours honorer le kodpaquet du serveur en amont et disposer d'outils de surveillance vérifiant les décalages horaires et l'accessibilité des serveurs en amont.

Vous voudrez peut -être envisager d'avoir vos propres sources de temps exactes dans quelques-uns de vos centres de données avec lesquels vous pourrez vous pencher ou vous replier dans le cas peu probable où GPS SA est activé par les militaires. Il existe des appareils rentables spécialement pour cela. Même si vous êtes dans un environnement «cage» et que vous n'avez pas votre propre centre de données, certaines installations d'hébergement peuvent s'adapter à cela.

Voir le document de chronométrage vmware sur http://www.vmware.com/pdf/vmware_timekeeping.pdf

L'exécution d'un démon NTP dans une machine virtuelle n'est probablement pas une bonne idée, en particulier si vous avez besoin de temps fiable.

Voici un bon KB de VMware avec des paramètres de configuration réels pour différentes distributions de Linux

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427