Andere Aufgaben mit Instanzen ausführen

Dies sind weitere Aufgaben, die mit den Instanzen ausgeführt werden können.

Vorbereitung

Dateien zwischen einer Instanz und einem lokalen Computer kopieren

Verwenden Sie gcloud compute scp, um Dateien zwischen einer Linux-Instanz und einem lokalen Computer zu übertragen:

gcloud compute scp my-instance:~/file-1 \
    my-instance:~/file-2 \
    ~/local-dir

So kopieren Sie Dateien vom lokalen Rechner in die Instanz:

gcloud compute scp ~/local-dir/file-1 \
    my-instance:~/remote-destination

Erkennen, ob die Ausführung in Compute Engine erfolgt

Im Allgemeinen möchte man wissen, ob Systeme in einer bestimmten Cloud-Umgebung ausgeführt werden. Anhand der folgenden Anleitung können Sie erkennen, ob die Ausführung in Compute Engine erfolgt.

Metadatenserver verwenden

Mit dem Metadatenserver können Sie einfach erkennen, ob die Anwendungen oder Skripts in einer Compute Engine-Instanz ausgeführt werden. Wenn Sie eine Anfrage an den Server senden, enthält die Antwort vom Metadatenserver den Header Metadata-Flavor: Google. Sie können nach diesem Header suchen, um verlässlich zu erkennen, ob die Ausführung in Compute Engine erfolgt.

Beispiel: Bei der folgenden curl-Anfrage wird ein Metadata-Flavor: Google-Header zurückgegeben, der angibt, dass die Anfrage über eine Compute Engine-Instanz gestellt wurde.


me@my-inst:~$ curl metadata.google.internal -i


HTTP/1.1 200 OK
Metadata-Flavor: Google
Content-Type: application/text
Date: Thu, 10 Apr 2014 19:24:27 GMT
Server: Metadata Server for VM
Content-Length: 22
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

0.1/

computeMetadata/

Andere Methoden verwenden

Linux

Bei Linux-Instanzen können Sie mit dem Tool dmidecode direkt auf die DMI/SMBIOS-Informationen in /proc/mem zugreifen. Wenn Sie den folgenden Befehl ausführen, sollte das dmidecode-Tool "Google Compute Engine" ausgeben und damit anzeigen, dass die Ausführung in Google Compute Engine erfolgt:

my@myinst:~$ sudo dmidecode -s system-product-name | grep "Google Compute Engine"
Google Compute Engine

Windows

Bei Windows-Instanzen wird "Google" als Systemhersteller und Modell aufgeführt. Mit Dienstprogrammen wie msinfo32.exe können Sie diese Informationen einsehen. Von msinfo32 werden z. B. folgende Informationen angezeigt:

msinfo32-Bildschirm, auf dem Google als Hersteller und Modell aufgeführt ist (zum Vergrößern klicken)
msinfo32-Bildschirm, auf dem Google als Hersteller und Modell aufgeführt ist (zum Vergrößern klicken)

Wenn Sie diese Informationen programmatisch auf einer Windows-Instanz bestimmen müssen, können Sie eine WMI-Anwendung (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) mit einigen Änderungen erstellen.

Instanzfehler behandeln

Leider kommt es bei einzelnen Instanzen gelegentlich zu Fehlern. Dies kann verschiedene Ursachen haben, einschließlich unerwarteter Ausfälle, Hardwarefehlern oder anderer Systemfehler. Um derartige Situationen zu verhindern, sollten Sie nichtflüchtige Speicher verwenden und die Daten regelmäßig sichern.

Wenn bei einer Instanz ein Fehler auftritt, wird sie automatisch mit demselben nichtflüchtigen Root-Speicher und denselben Metadaten und Instanzeinstellungen wie beim Fehler neu gestartet. Unter Verfügbarkeitsrichtlinien festlegen wird beschrieben, wie das Verhalten beim automatischen Neustart gesteuert wird.

Generell sollte das System so stabil konzipiert werden, dass der Ausfall einer einzelnen Instanz keine katastrophalen Folgen für die Anwendung hat. Weitere Informationen finden Sie in Robuste Systeme konzipieren.

Instanz über die UUID identifizieren

Jede virtuelle Maschine verfügt über eine UUID (Universally Unique Identifier), auf die bei Linux-Images mit dem dmidecode-Tool zugegriffen werden kann. Eine UUID wird aus der Projekt-ID, der Zone und dem Instanznamen der virtuellen Maschine berechnet. Die UUID ist unter den virtuellen Maschinen von Compute Engine eindeutig und während der Lebensdauer der Instanz stabil. UUIDs bleiben während Neustarts der virtuellen Maschine bestehen. Wenn Sie die virtuelle Maschine löschen und dann im selben Projekt, in derselben Zone und mit demselben Instanznamen neu erstellen, ist auch die UUID identisch.

Um die UUID einer Instanz in einer Linux-Instanz zu ermitteln, führen Sie den folgenden Befehl über die virtuelle Maschine aus:

me@myinst:~$ sudo dmidecode -t system | grep UUID

Das Tool sollte eine Antwort wie die folgende ausgeben:

  UUID: FE0C672D-324F-25F1-052C-6C50FA8B7397

Pakete installieren und Instanz konfigurieren

Der Instanzersteller hat Administratorberechtigungen für jede Instanz, die er einem Projekt hinzufügt, und steht automatisch auf der SUDO-Liste.

Wenn Sie als Administrator in einer Instanz angemeldet sind, können Sie Pakete installieren und die Instanz genau wie einen normalen Linux-Rechner konfigurieren. So können Sie z. B. Apache installieren:


user@myinst:~$ sudo apt-get update && sudo apt-get install apache2
Reading package lists... Done

Building dependency tree
Reading state information... Done
The following extra packages will be installed:

[...]

Sie können Dateien mithilfe von gcloud compute scp zwischen dem lokalen Computer und der Instanz verschieben, wie unter Dateien zwischen einer Instanz und einem lokalen Computer kopieren beschrieben.

Zur Ausführung von "apt-get" benötigt der Computer Zugriff auf das Internet. Dies bedeutet, dass eine externe IP-Adresse oder Zugriff auf einen Internetproxy erforderlich ist.

Compute Engine ändert ein spezielles Attribut im Metadatenserver einer virtuellen Maschine kurz bevor im Rahmen eines ausstehenden Infrastrukturwartungsereignisses eine Livemigration oder die Beendigung und der Neustart der virtuellen Maschine versucht wird. Das Attribut maintenance-event wird vor und nach einem Wartungsereignis aktualisiert, sodass Sie erkennen können, wann diese Ereignisse bevorstehen. Mit dieser Information können Sie Skripts oder Befehle einfacher automatisieren, die Sie vor und/oder nach einem Wartungsereignis ausführen möchten.

Weitere Informationen finden Sie auf der entsprechenden Seite der Metadatenserver-Dokumentation im Abschnitt mit dem Hinweis zur transparenten Wartung.

Alle Instanzen auflisten

Sie können eine Liste aller Instanzen in einem Projekt über instances list aufrufen:

gcloud compute instances list
NAME               ZONE          MACHINE_TYPE  INTERNAL_IP    EXTERNAL_IP     STATUS
example-instance   us-central1-a n1-standard-1 10.105.155.92  173.255.114.53  RUNNING
example-instance-2 us-central1-a n1-standard-1 10.181.215.203 146.148.32.59   RUNNING

Standardmäßig stellt gcloud compute eine Zusammenfassung aller Ressourcen in allen verfügbaren Zonen bereit. Geben Sie für eine Liste der Ressourcen einer einzelnen Zone in der Anfrage das Flag --zones an.

In der API müssen Sie Anfragen an zwei verschiedene Methoden stellen, um eine zusammengefasste Liste der Ressourcen oder eine Liste der Ressourcen innerhalb einer Zone zu erhalten. Stellen Sie für eine zusammengefasste Liste eine GET-Anfrage an den aggregatedList-URI dieser Ressource und ersetzen das Projekt durch Ihre eigene Projekt-ID:

https://www.googleapis.com/compute/v1/projects/myproject/aggregated/instances

Stellen Sie in den Clientbibliotheken eine Anfrage an die Funktion instances().aggregatedList:

def listAllInstances(auth_http, gce_service):
  request = gce_service.instances().aggregatedList(project=PROJECT_ID)
  response = request.execute(auth_http)

  print response

Stellen Sie für eine Liste der Instanzen in einer einzelnen Zone eine GET-Anfrage an den folgenden URI und ersetzen das Projekt durch Ihre eigene Projekt-ID und die Zone durch die Zone der Instanzen:

https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-f/instances

Stellen Sie in den API-Clientbibliotheken eine instances().list-Anfrage:

def listInstances(auth_http, gce_service):
  request = gce_service.instances().list(project="myproject",
    zone="us-central1-f")
  response = request.execute(auth_http)

  print response

Kosten mit präemptiven Instanzen verringern

Google Compute Engine bietet präemptive Instanzen, die Sie zu einem wesentlich günstigeren Preis als reguläre Instanzen erstellen und ausführen können. Wenn die Anwendungen fehlertolerant sind und einer Instanzinstabilität standhalten können, können präemptive Instanzen die Compute Engine-Kosten wesentlich verringern. Weitere Informationen finden Sie in der Dokumentation Präemptive Instanzen.

NTP (Network Time Protocol) für Instanzen einrichten

Viele Softwaresysteme, die von einer sorgfältigen Sequenzierung der Ereignisse abhängen, verlassen sich auf eine stabile, konsistente Systemuhr. System-Logs, die von den meisten Diensten geschrieben werden, umfassen einen Zeitstempel, mit dem Probleme in verschiedenen Komponenten eines Systems einfacher behoben werden können. Compute Engine-Instanzen sind zur Verwendung von NTP (Network Time Protocol) vorkonfiguriert, um die Systemuhren synchron zu halten.

NTP hält nicht nur die Serverzeit synchron, sondern ist auch im seltenen Fall einer Schaltsekunde nützlich. Mit einer Schaltsekunde wird die UTC-Zeit um eine Sekunde angepasst, um Änderungen bei der Erdumdrehung Rechnung zu tragen. Schaltsekunden treten nicht in regelmäßigen Abständen auf, weil die Geschwindigkeit der Erdumdrehung aufgrund von klimatischen und geologischen Ereignissen unregelmäßig variiert. In früheren Zeiten haben Schaltsekunden bei vielen Diensten und Anwendungen im Web Chaos angerichtet. Mit NTP-Servern wird sichergestellt, dass alle Server bei einer Schaltsekunde dieselbe Zeit melden.

In diesem Abschnitt wird beschrieben, wie die NTP-Server auf den virtuellen Maschinen konfiguriert werden, damit sie sich bei einer Schaltsekunde ordnungsgemäß verhalten.

Google NTP-Server und Verteilen von Schaltsekunden

Schaltsekunden bei der Unix-Zeit werden für gewöhnlich 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 die zusätzliche Sekunde über zwanzig Stunden hinweg – zehn vor und zehn nach dem Auftreten der Schaltsekunde –, sodass Computer die zusätzliche Sekunde nicht plötzlich als wiederholten Zeitstempel sehen. Dadurch wird das Risiko bei Systemen verringert, die von einem konsistenten Zeitstempel abhängig sind. Es wird empfohlen, alle VM-Instanzen von Compute Engine so zu konfigurieren, dass die internen Google NTP-Dienste verwendet werden.

NTP für eigene Instanzen konfigurieren

Google kann nicht voraussagen, wie externe NTP-Dienste, wie z. B. pool.ntp.org, die Schaltsekunde behandeln. Es wird empfohlen, möglichst keine externen NTP-Quellen in Verbindung mit virtuellen Compute Engine-Maschinen zu verwenden. Noch schlimmer wäre die gleichzeitige Verwendung eines Google NTP-Dienstes und eines externen Dienstes. Dies könnte 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 wahrscheinlich Stepping zur Verarbeitung der Schaltsekunde. Dies führt dazu, dass virtuelle Maschinen möglicherweise einen wiederholten Zeitstempel sehen.

Die sicherste Lösung besteht darin, die virtuellen Compute Engine-Maschinen so zu konfigurieren, dass ein einzelner NTP-Server verwendet wird – der interne NTP-Server von Google. Mischen Sie keine externen NTP-Server mit Google NTP-Servern, da dies zu unerwartetem Verhalten führen kann.

Beachten Sie die folgenden Anleitungen, damit die virtuellen Maschinen ordnungsgemäß konfiguriert werden.

Linux

  1. Stellen Sie ein SSH-Verbindung zur Instanz her.

    Console

    1. Öffnen Sie in der GCP Console die Seite VM-Instanzen.
    2. Klicken Sie neben der zu konfigurierenden Instanz auf die Schaltfläche SSH.

      Screenshot der SSH-Schaltfläche

    gcloud

    Führen Sie mit dem gcloud-Befehlszeilentool folgenden Befehl aus:

    gcloud compute instances ssh INSTANCE
    

  2. Führen Sie auf der Instanz ntpq -p aus, um den aktuellen Status der NTP-Konfiguration zu prüfen:

    $ 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
    *217.162.232.173 130.149.17.8     2 u  191 1024  176   79.245    3.589  27.454
    

    Bei einem einzelnen Datensatz, der auf metadata.google oder metadata.google.internal verweist, brauchen Sie keine Änderungen vorzunehmen. Bei mehreren Quellen als Mischung von metadata.google und einer öffentlichen Quelle wie pool.ntp.org müssen Sie die Quellen aktualisieren, um externe NTP-Server zu entfernen.

    In diesem Beispiel gibt es zwei Datensätze. Der eine verweist auf metadata.google und der andere auf eine externe Adresse. Da mehrere Quellen vorhanden sind, müssen Sie die NTP-Server aktualisieren, um die Adresse *217.162.232.173 zu entfernen.

    1. Konfigurieren Sie die NTP-Server so, dass externe Quellen entfernt werden.

      Zur Konfiguration der NTP-Server bearbeiten Sie die Datei /etc/ntp.conf im Texteditor Ihrer Wahl. Suchen Sie den Abschnitt servers der Konfiguration und entfernen Sie alle Nicht-Google NTP-Quellen:

    $ 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 variieren:

    $ sudo service ntp reload
    1. Prüfen Sie die Konfiguration. Führen Sie den Befehl ntpq -p noch einmal aus, um Ihre Änderungen zu prüfen:
    $ 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

  1. Öffnen Sie in der GCP Console die Seite VM-Instanzen.
  2. Klicken Sie neben der Windows-Instanz, in der Sie sich anmelden möchten, auf die Schaltfläche RDP.

    Screenshot der SSH-Schaltfläche

  3. Klicken Sie nach der Anmeldung mit der rechten Maustaste auf das PowerShell-Symbol und wählen Sie Als Administrator ausführen aus.

    Screenshot des Powershell-Symbols

  4. Führen Sie an der Eingabeaufforderung den folgenden Befehl aus, um die aktuelle NTP-Konfiguration zu sehen:

    PS C:\Windows\system32>w32tm /query /configuration
    [Configuration]
    ...
    Type: NTP (Local)
    NtpServer: metadata.google.internal,
    ...
    

    Wenn ein einzelner Datensatz auf metadata.google oder metadata.google.internal verweist, brauchen Sie keine Änderungen vorzunehmen. 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.

Durch das Verteilen von Schaltsekunden bei Google NTP-Servern kann das Risiko bei der Wiederholung einer Sekunde bei zeitempfindlichen Systemen umgangen werden. Andere NTP-Dienste bieten möglicherweise ebenfalls für die meisten Softwaresysteme geeignete Lösungen zur Umgehung des Problems. Wichtig ist nur, dass Google NTP-Dienste, die Schaltsekunden verteilen, nicht mit öffentlichen NTP-Stepping-Diensten gemischt werden.

Wenn Sie Geräte außerhalb der Google Cloud mit der verteilten Zeit synchronisieren möchten, verwenden Sie Google Public NTP. Es verwendet dasselbe Verteilungsverfahren wie die VM-Instanzen von Compute Engine.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation