Je nachdem, wie kritisch die Zeiterfassung in Ihrer Umgebung ist, möchten Sie möglicherweise nicht, dass Server1 ein Single Point of Failure ist. Wenn Sie es zu Wartungs- oder Reparaturzwecken für einen längeren Zeitraum offline schalten müssen, hören seine Peers auf, sich zu synchronisieren. Von da an geht es nur noch bergab.
Warum nicht Server1, Server2, Server3, Server4 alle mit 4 oder 5 Internet-Peers synchronisieren lassen? Dann kann Ihr internes Netzwerk auf diese Systeme verweisen?
Herkömmliche Weisheit sagt, dass 3 das ist, was Sie für das Quorum brauchen, aber Sie müssen tolerant sein, wenn mindestens einer als falscher Ticker bestimmt wird oder offline geht.
Bitte sehen Sie; 5.3.3. Upstream-Zeitservermenge
Darüber hinaus erwähnen Sie Verrücktheiten und Probleme mit Ihrer aktuellen Konfiguration. Es wäre hilfreich, die Ausgabe von ntpq -p zu sehen für die entsprechenden Hosts.
Obwohl es nicht ganz richtig ist, dass 2 Server nutzlos sind, empfiehlt der Best Current Practices RFC-Entwurf 4 als Minimum. Der Schnittpunktalgorithmus von NTP hängt nicht nur vom Quorum in der Nummer ab von Servern, sondern auch in der Qualität der Zeit, zu der sie zurückkehren - und das kann man nicht vorhersagen. Also je mehr desto besser. Es ist kein Problem, bis zu 10 Upstream-NTP-Server zu haben.
Wie Aaron erwähnte, sollten Ihre vorgeschlagenen Server 1-4 alle auf Upstream-NTP-Server verweisen, und Ihre internen Systeme sollten auf alle 4 verweisen. Die Server 1-4 können auch miteinander peeren (im symmetrischen Modus), aber das ist nicht unbedingt erforderlich.
Es ist wichtig zu verstehen, warum Sie NTP an keinem Punkt Ihrer Architektur über einen einzelnen Server leiten sollten:NTP erfordert mehrere Server für Genauigkeit , nicht nur Redundanz (siehe die NTP-Dokumentation für eine Beschreibung der Algorithmen, die erklärt, warum). (Shameless Plug:Ich habe an anderer Stelle mehr darüber geschrieben, einschließlich Vorschlägen für die Architektur.)