Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

NTP auf einer Compute-Instanz konfigurieren

Linux Windows

Viele Softwaresysteme, die von einer sorgfältigen Sequenzierung der Ereignisse abhängen, verlassen sich auf eine stabile, konsistente Systemuhr. Diese Systeme verwenden häufig Systemprotokolle mit Zeitstempeln, um die Zeitsynchronisierung zu gewährleisten und Probleme zu beheben, sobald sie auftreten. Damit die Systemuhren synchron bleiben, sind Compute Engine-Instanzen so vorkonfiguriert, dass sie das Network Time Protocol (NTP) verwenden, eine gebündelte Lösung aus Hardware und Software für die Zeitsynchronisierung.

NTP ist auch im seltenen Fall einer Schaltsekunde hilfreich, einer Anpassung der UTC-Zeit um eine Sekunde, um Änderungen der Erdrotation zu berücksichtigen. Schaltsekunden treten nicht in regelmäßigen Abständen auf, da die Rotationsgeschwindigkeit der Erde aufgrund klimatischer und geologischer Ereignisse unregelmäßig variiert. Frühere Schaltsekunden haben sich spürbar auf eine Vielzahl von Diensten und Anwendungen im Web ausgewirkt. Mit NTP-Servern wird sichergestellt, dass alle Server bei einer Schaltsekunde dieselbe Zeit melden.

In diesem Dokument wird beschrieben, wie Sie NTP-Server auf Ihren Compute-Instanzen konfigurieren, einschließlich der richtigen Verarbeitung von Schaltsekunden.

Google NTP-Server und Verteilen von Schaltsekunden – Übersicht

Bei einem Unix-Betriebssystem werden Schaltsekunden häufig durch Wiederholung der letzten Sekunde des Tages implementiert. Dies kann zu Problemen bei Software führen, die erwartet, dass Zeitstempel immer nur erhöht werden. Um dieses Problem zu umgehen, „verteilen“ die Zeitserver bei Google Clouddie zusätzliche Sekunde über 24 Stunden hinweg – 12 Stunden vor und 12 Stunden nach dem Auftreten der Schaltsekunde –, sodass betroffene Computer die zusätzliche Sekunde nicht alle zur gleichen Zeit als wiederholten Zeitstempel sehen. Dadurch wird das Risiko bei Systemen verringert, die von einem konsistenten Zeitstempel abhängig sind. Wir empfehlen, alle Compute-Instanzen so zu konfigurieren, dass sie die internen NTP-Dienste von Google verwenden.

Empfehlung gegen die Verwendung externer NTP-Dienste

Google Cloud kann nicht vorhersagen, wie externe NTP-Dienste wie pool.ntp.org mit Schaltsekunden umgehen. Wir raten dringend davon ab, externe NTP-Quellen mit Ihren Compute-Instanzen zu verwenden. Wenn Sie sowohl den NTP-Dienst von Google als auch einen externen Dienst verwenden, kann dies zu unvorhersehbaren Änderungen der Systemzeit führen. Die Verwendung von nur einer externen NTP-Quelle ist besser als eine Mischung. Externe NTP-Dienste, wie pool.ntp.org verwenden jedoch oft Stepping zur Verarbeitung der Schaltsekunde. Daher können Ihre Instanzen wiederholte Zeitstempel aufweisen.

Die sicherste Lösung besteht darin, die Compute-Instanzen so zu konfigurieren, dass nur ein einziger NTP-Server verwendet wird – der interne NTP-Server von Google. Weitere Informationen zum internen NTP-Server von Google finden Sie in den FAQs zu Google Public NTP.

Schaltsekundenverteilung mit Systemen außerhalb von Google Cloudverwenden

Die Schaltsekundenverteilung bei Google NTP-Servern ist eine praktische Möglichkeit, das Risiko bei der Wiederholung einer Sekunde bei zeitempfindlichen Systemen zu verwalten. Andere NTP-Dienste bieten möglicherweise ebenfalls für die meisten Softwaresysteme geeignete Lösungen zur Umgehung des Problems. Es ist jedoch wichtig, dass Sie die NTP-Dienste von Google, die Schaltsekundenverteilung verwenden, nicht mit öffentlichen NTP-Diensten kombinieren, die Schaltsekunden überspringen.

Wenn Sie Geräte außerhalb von Google Cloud mit der verteilten Zeit synchronisieren möchten, können Sie für diese Geräte Google Public NTP verwenden. Google Public NTP verwendet dasselbe Verteilungsverfahren für Schaltsekunden wie Compute Engine-Instanzen.

NTP für eigene Instanzen konfigurieren

So konfigurieren Sie Ihre Compute-Instanzen richtig:

Linux (chrony)

Standardmäßig nutzen die meisten Linux-Releases chrony, um die NTP-Einstellungen und die Zeitsynchronisierung zu verwalten. Damit chrony nur den internen NTP-Dienst verwendet, prüfen Sie die chrony-Konfiguration und entfernen Sie externe NTP-Server:

Stellen Sie mit ssh eine Verbindung zu Ihrer Compute-Instanz her.
Console
So stellen Sie über die Console eine SSH-Verbindung zur Compute-Instanz her:
1. Rufen Sie in der Google Cloud -Console die Seite VM-Instanzen auf.
  
  Zur Seite „VM-Instanzen“
2. Klicken Sie für die Instanz, die Sie konfigurieren möchten, auf den Button SSH.
gcloud
Führen Sie den folgenden Befehl aus, um über die Google Cloud CLI eine SSH-Verbindung zur Compute-Instanz herzustellen:
gcloud compute instances ssh INSTANCE_NAME
Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz, zu der Sie eine Verbindung herstellen.
Führen Sie auf der Instanz chronyc sources aus, um den aktuellen Status Ihrer NTP-Konfiguration zu prüfen:
```
$ chronyc sources
```
Die Ausgabe sieht dann ungefähr so aus:
```
 210 Number of sources = 2
 MS Name/IP address         Stratum Poll Reach LastRx Last sample
 ===============================================================================
 ^* metadata.google.internal      2   6   377     4    -14us[  -28us] +/-  257us
 ^- 38.229.53.9                   2   6    37     4   -283us[ -297us] +/-   28ms
```
Wenn Sie einen einzelnen Eintrag sehen, der auf metadata.google oder metadata.google.internal verweist, müssen Sie keine Änderungen vornehmen. Wenn Sie mehrere Quellen sehen, gemischt zwischen metadata.google und einer öffentlichen Quelle wie pool.ntp.org, aktualisieren Sie Ihre Quellen, um alle externen NTP-Server zu entfernen.

In der Beispielausgabe gibt es zwei Datensätze, einer, der auf metadata.google.internal verweist und ein weiterer, der auf eine externe Adresse verweist. Da mehrere Quellen vorhanden sind, müssen Sie Ihre NTP-Server aktualisieren, um die Adresse 38.229.53.9 zu entfernen, wie im nächsten Schritt beschrieben.
Konfigurieren Sie Ihre NTP-Server zum Entfernen externer NTP-Server.

Bearbeiten Sie die Datei /etc/chrony/chrony.conf mit Ihrem bevorzugten Texteditor, um den zusätzlichen NTP-Server aus der Liste zu entfernen. Suchen Sie alle Zeilen, die mit server external_source_ip_or_name beginnen, und entfernen Sie sie.

Nachdem Sie die /etc/chrony/chrony.conf-Datei bearbeitet haben, starten Sie den chrony-Dienst neu. Der Befehl zum Neustarten kann je nach Linux-Distribution variieren, wie in den folgenden Beispielen gezeigt:
```
sudo service chrony restart
```
```
sudo systemctl restart chrony
```

Prüfen Sie Ihre Konfiguration. Dazu führen Sie den Befehl chronyc sources noch einmal aus:

$ chronyc sources

Die Ausgabe sollte in etwa so aussehen:

 210 Number of sources = 1
 MS Name/IP address         Stratum Poll Reach LastRx Last sample
 ===============================================================================
 ^* metadata.google.internal      2   7   377    98  -1343ns[-1588ns] +/-  396us

Linux (ntpd)

Ältere Linux-Distributionen, die chrony nicht unterstützen, verwenden stattdessen ntpd, um ihre NTP-Einstellungen und die Zeitsynchronisierung zu verwalten. Damit ntpd nur den internen NTP-Dienst verwendet, prüfen Sie die ntpd-Konfiguration und entfernen Sie externe NTP-Server:

Stellen Sie mit ssh eine Verbindung zu Ihrer Compute-Instanz her.
Console
So stellen Sie über die Console eine SSH-Verbindung zur Compute-Instanz her:
1. Rufen Sie in der Google Cloud -Console die Seite VM-Instanzen auf.
  
  Zur Seite „VM-Instanzen“
2. Klicken Sie für die Instanz, die Sie konfigurieren möchten, auf den Button SSH.
gcloud
Führen Sie den folgenden Befehl aus, um über die Google Cloud CLI eine SSH-Verbindung zur Compute-Instanz herzustellen:
gcloud compute instances ssh INSTANCE_NAME
Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz, zu der Sie eine Verbindung herstellen möchten.
Führen Sie auf der Instanz ntpq -p aus, um den aktuellen Status der NTP-Konfiguration zu prüfen:
```
$ ntpq -p
```
Die Ausgabe sieht dann ungefähr so aus:
```
remote           refid           st t when poll reach   delay   offset  jitter

==============================================================================
*metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285
*217.162.232.173 130.149.17.8     2 u  191 1024  176   79.245    3.589  27.454
```
Wenn Sie einen einzelnen Eintrag sehen, der auf metadata.google oder metadata.google.internal verweist, müssen Sie keine Änderungen vornehmen. Bei mehreren Quellen, die aus einer Mischung von metadata.google und einer öffentlichen Quelle wie pool.ntp.org bestehen, müssen Sie die Quellen aktualisieren, um externe NTP-Server zu entfernen.

In der Beispielausgabe gibt es zwei Datensätze, einer, der auf metadata.google verweist und ein weiterer, der auf eine externe Adresse verweist. Da es mehrere Quellen gibt, müssen Sie die NTP-Server aktualisieren, um die *217.162.232.173-Adresse zu entfernen, wie im nächsten Schritt beschrieben.
Konfigurieren Sie die NTP-Server so, dass externe Quellen entfernt werden.

Bearbeiten Sie zur Konfiguration der NTP-Server die Datei /etc/ntp.conf im Texteditor Ihrer Wahl. Suchen Sie in der Konfiguration nach dem Abschnitt servers und entfernen Sie alle NTP-Quellen, die nicht von Google stammen, z. B.:
```
vim /etc/ntp.conf
```
```
# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example
...
server metadata.google.internal iburst
```
Nachdem Sie die Datei /etc/ntp.conf bearbeitet haben, starten Sie den NTP-Dienst neu. Der Befehl zum Neustarten kann je nach Linux-Distribution vom folgenden Beispiel abweichen:
```
sudo service ntp reload
```
Hinweis: Standardmäßig fügt der DHCP-Client eine Liste von NTP-Servern zur ntp.conf-Datei hinzu. Wenn Sie eine Enterprise-Linux-Distribution verwenden und die vom DHCP-Client bereitgestellte NTP-Konfiguration ignorieren möchten, fügen Sie PEERNTP=no in der Datei /etc/sysconfig/network hinzu.

Prüfen Sie Ihre Konfiguration. Dazu führen Sie den Befehl ntpq -p noch einmal aus:

ntpq -p

remote           refid           st t when poll reach   delay   offset  jitter
==============================================================================
*metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285

Windows

Rufen Sie in der Google Cloud -Console die Seite VM-Instanzen auf.

Zur Seite „VM-Instanzen“
Klicken Sie neben der Windows-Instanz, zu der Sie eine Verbindung herstellen möchten, auf den Button RDP.
Klicken Sie nach der Anmeldung mit der rechten Maustaste auf das PowerShell-Symbol und wählen Sie Als Administrator ausführen aus.
Führen Sie an der Eingabeaufforderung den folgenden Befehl aus, um die aktuelle NTP-Konfiguration zu sehen:
```
w32tm /query /configuration
```
```
[Configuration]
...
Type: NTP (Local)
NtpServer: metadata.google.internal,
...
```
Wenn Sie einen einzelnen Eintrag sehen, der auf metadata.google oder metadata.google.internal verweist, müssen Sie keine Änderungen vornehmen. Bei mehreren Quellen als Mischung von metadata.google und einer öffentlichen Quelle müssen Sie den externen Server entfernen. Folgen Sie der Anleitung im Windows-Handbuch, um den NTP-Server zu konfigurieren.
Um eine größtmögliche Softwarekompatibilität auf Windows-VMs zu gewährleisten, empfiehlt Google die Verwendung des gVNIC-Treibers, was eine NTP-Genauigkeit von weniger als einer Millisekunde mit metadata.google gewährleistet.

Wenn Sie VirtIO mit Ihrer Windows-VM verwenden müssen, um eine Genauigkeit von weniger als einer Millisekunde zu erreichen, empfiehlt Google, dass Sie den Windows Time Service nicht verwenden (w32tm beenden und Registrierung aufheben).
1. Beenden Sie den Windows Time Service:
```
net stop w32time
```
2. Entfernen Sie den Windows Time Service aus dem Registry:
```
w32tm /unregister
```
3. Nachdem der Windows Time Service beendet und aus der Registry entfernt wurde, installieren Sie den Meinberg NTP-Client.
  
  Folgen Sie der Konfigurationsanleitung in der Meinberg-Dokumentation.
4. Konfigurieren Sie den NTP-Server für den Meinberg NTP-Client als metadata.google.internal.
  
  Warten Sie nach Abschluss der NTP-Konfiguration zwischen 5 und 15 Minuten, bis sich die Systemuhr in der Compute-Instanz mit dem NTP-Server stabilisiert hat.
  
  Informationen dazu, warum wir die Verwendung von w32tm nicht empfehlen, finden Sie in der Dokumentation zu bekannten Problemen.

Nächste Schritte

Weitere Informationen zur Compliance mit dem PCI-Datensicherheitsstandard
Lesen Sie die FAQs zu Google Public NTP.