Google Cloud Platform für Nutzer von OpenStack

Dieser Artikel soll Nutzern, die mit OpenStack vertraut sind, die wichtigsten nötigen Konzepte vermitteln, um mit der Google Cloud Platform (GCP) beginnen zu können. Wenn Sie zum Beispiel eine Migration oder die Implementierung einer Hybrid-Lösung durchführen möchten, finden Sie hier nützliche Informationen.

Überblick

In diesem Artikel werden zunächst beispielhaft Architekturen von 3-Tier-Webanwendungen auf OpenStack und GCO verglichen. Dann werden Funktionen von OpenStack und GCP verglichen und kurze Referenztabellen bereitgestellt, die erklären, wie Begriffe und Konzepte in OpenStack denen in GCP entsprechen.

In diesem Artikel werden nicht die SDKs, APIs oder Befehlszeilentools verglichen, die von OpenStack und GCP zur Verfügung gestellt werden.

Eine komplette Liste der Google Platform-Produkte finden Sie unter Produkte und Dienste.

Cloud-Computing-Dienste

Cloud-Computing-Dienste stellen einige grundlegende Dienste zur Verfügung, darunter Compute-, Speicher-, Netzwerk-, Zugriffsverwaltungs-. und oft Datenbank-Dienste.

Die grundlegenden Dienste von OpenStack umfassen:

  • Compute: OpenStack Compute (Nova und Glance)
  • Speicherung: OpenStack Block Storage (Cinder)
  • Netzwerk: OpenStack Networking (Neutron)
  • Identitäts- und Zugriffsverwaltung: OpenStack Identity Service (Keystone)

Die grundlegenden Dienste der Cloud Platform umfassen:

Preise für die Google Cloud Platform

Die meisten GCP-Dienste werden nach Nutzungszeit abgerechnet. Dabei gibt es sekundengenaue oder minutengenaue Abrechnung und automatische Ermäßigungen bei steigender Nutzung. In Kombination mit flexibler Ressourcenverteilung, wie benutzerdefinierten Maschinentypen, können Sie mit dem Preismodell von GCP eine kosteneffektive Leistung für Ihre Anwendungen optimieren.

Weitere Informationen über Tools und Details zur Preiskalkulation liefern Ihnen die Preisrechner.

Vorteile der Google Cloud Platform

Seit 15 Jahren baut Google eine der weltweit schnellsten, leistungsfähigsten und hochwertigsten Cloudinfrastrukturen auf. Intern verwendet Google diese Infrastruktur für verschiedene globale Dienste mit hohem Traffic, darunter Gmail, Maps, YouTube und Google-Suche. Mit GCP können auch Sie diese Infrastruktur nutzen.

Beispielarchitekturen im Vergleich

In diesem Abschnitt wird verglichen, wie Sie Systeme für 3-Tier-Webanwendungen in OpenStack und in GCP aufbauen:

  • Die OpenStack-Konfiguration führt zu einer aktiven Backup-Konfiguration.
  • Die GCP-Konfiguration nutzt verwaltete Dienste und führt zu einer Aktiv-Aktiv-Konfiguration.

Eine typische 3-Tier-Webanwendung besteht aus den folgenden Komponenten:

  • Lastenausgleichsmodul
  • Webserver
  • Anwendungsserver
  • Datenbankserver

OpenStack: Aktiv-Backup-Konfiguration

Die in Abbildung 1 gezeigte OpenStack-Beispielkonfiguration hat folgende Eigenschaften:

  • Ressourcen werden auf zwei Regionen als zwei separate Ausfalldomains für Redundanz verteilt.
  • Das Netzwerk nutzt ein einzelnes Subnetz für alle Ebenen in jeder Region und sämtliche Server sind VM-Instanzen.
  • Sie definieren Sicherheitsgruppen für die vier Serverrollen und weisen sie den entsprechenden Instanzen zu.
  • Ein Cinder-Volume wird zu dem Datenbankserver als Daten-Volume hinzugefügt. Um Redundanz über alle Ausfalldomains sicherzustellen, wird die Datenbank in der aktiven Region auf dem Objektspeicher gesichert und, falls nötig, in einem Objektspeicher der Sicherungszone wiederhergestellt. (Diese Architektur nutzt keine Echtzeit-Replikation von Datenbanken, da die Bandbreite zwischen Regionen begrenzt ist.)
  • Diese Architektur bietet eine Aktiv-Backup-Konfiguration. Bei einer Ausfallsicherung des Dienstes in einer anderen Region wird die letzte Sicherung auf dem Datenbankserver in der Sicherungsregion wiederhergestellt.

3-Tier-Webanwendungen

Abbildung 1: Ein System für 3-Tier-Webanwendungen in OpenStack

GCP: Aktiv-Aktiv-Konfiguration

Die GCP-Beispielkonfiguration, die in Abbildung 2 gezeigt wird, hat die folgenden Eigenschaften:

  • Ressourcen werden einem einzigen Subnetz zugewiesen, das mehrere Zonen in einer Region für Redundanz abdeckt.
  • Web- und Anwendungsserver werden als VM-Instanzen bereitgestellt.
  • Firewallregeln werden mithilfe von Tags definiert, um Ziele für Pakete festzulegen.
  • Die Zugriffskontrolle wird basierend auf der IP-Adresse der Quelle als Teil der Cloud SQL-Konfiguration konfiguriert. Cloud SQL ist ein von der GCP verwalteter Dienst für MySQL-Datenbanken, der Datenreplikation zwischen mehreren Zonen bietet. Planmäßige Sicherungen und Failover-Vorgänge sind automatisiert und Sie können auf die Datenbank von mehreren Zonen in der gleichen Region aus zugreifen. Failover zwischen Zonen sind für die Anwendungen, die in VM-Instanzen laufen, erkennbar. Sie können auf eine einzelne Cloud SQL-Instanz von mehreren Zonen aus zugreifen. (Von Cloud SQL gibt es zwei Generationen: Cloud SQL First Generation und Cloud SQL Second Generation. Sie haben verschiedene Eigenschaften und ein anderes Standardverhalten bei Replikation und Failover.)
  • Google Cloud Load Balancing ist ein HTTP(S)-Load-Balancing-Dienst, mit dem Sie eine einzelne, globale IP-Adresse (VIP) verwenden können, um den Clientzugriff auf mehrere Regionen und Zonen zu verteilen.
  • Die Architektur stellt eine Aktiv-Aktiv-Konfiguration über mehrere Zonen bereit. Dies führt zu einem redundanten Dienst über Ausfalldomains.

3-Tier-Webanwendung 2

Abbildung 2: Ein System für 3-Tier-Webanwendungen in GCP.

Die Funktionen im Vergleich

In diesem Abschnitt werden Details der in den Beispielarchitekturen verwendeten Funktionen verglichen.

Netzwerkarchitektur

In diesem Abschnitt wird verglichen, wie OpenStack- und GCP-Netzwerke innerhalb von Regionen und Zonen arbeiten. Außerdem werden Projekte und Mandanten, IP-Adressen und Failover und Firewallregeln behandelt.

Regionen und Zonen

Nachfolgend werden die Bedingungen und Konzepte von OpenStack mit denen von GCP verglichen:

OpenStack GCP Hinweise
Region Region In OpenStack kann eine Region mehrere Rechenzentren umspannen. In GCP entspricht eine Region einem Rechenzentrums-Campus, auf dem sich gewöhnlich mehrere unabhängige Gebäude befinden.
Verfügbarkeitszone Zone In OpenStack wird eine Verfügbarkeitszone üblicherweise verwendet, um mehrere Server mit gemeinsamen Attributen zu identifizieren.

In GCP entspricht eine Zone einem Cluster innerhalb eines Rechenzentrums.

In OpenStack ist eine Region definiert als Cluster, der von dedizierten Controller-Knoten verwaltet wird. Eine Region besteht aus Verfügbarkeitszonen. Sie verwenden Verfügbarkeitszonen, um mehrere Gruppen von Ressourcen zu definieren, wie beispielsweise Compute-Knoten und Speichergehäuse.

In GCP ist eine Region ein unabhängiger, geographischer Bereich, der aus Zonen besteht. Speicherorte innerhalb dieser Regionen weisen gewöhnlich Rundlauf-Latenzen von unter 5 ms auf dem 95. Perzentil auf. Wie die Verfügbarkeitszonen in OpenStack ist eine Zone ein Bereitstellungsbereich für GCP-Ressourcen innerhalb einer Region. Eine Zone sollte als einzelne Ausfalldomain gesehen werden.

GCP stellt ein dediziertes internes Netzwerk über alle Regionen bereit, sodass Bandbreite und Latenz zwischen verschiedenen Zonen in der gleichen Region vergleichbar sind mit Bandbreite und Latenz innerhalb einer einzelnen Region. Sie können eine fest gekoppelte Cluster-Anwendung über mehrere Zonen bereitstellen, ohne sich Gedanken um Bandbreite und Latenz zwischen den Zonen machen zu müssen.

Um unerwartete Ausfälle zu verhindern, kann es auf beiden Plattformen hilfreich sein, Anwendungen über mehrere Zonen oder Regionen bereitzustellen. Zonen werden in GCP als unabhängige Ausfalldomains angesehen. Im Gegensatz dazu werden in OpenStack Regionen (statt Verfügbarkeitszonen) als unabhängige Ausfalldomains gesehen, da sich Verfügbarkeitszonen in einer einzelnen Region die gleichen Controller-Knoten teilen. Eine Liste mit GCP-Regionen und -Zonen finden Sie unter Cloud-Standorte.

Projekte und Mandanten

Nachfolgend werden die Bedingungen und Konzepte von OpenStack mit denen von GCP verglichen:

OpenStack GCP Hinweise
Mandant Projekt Alle Ressourcen in GCP müssen zu einem Projekt gehören. Nutzer können Ihre eigenen Projekte erstellen.

In OpenStack können nur Administratoren neue Mandanten erstellen.

Für GCP-Dienste wird ein Google-Konto benötigt. GCP gruppiert Ihre Dienstnutzung nach Projekten. Sie können mehrere, vollständig unabhängige Projekte unter demselben Konto erstellen und Nutzer können ihre eigenen Projekte unter deren Konten erstellen. Ressourcen innerhalb eines Projekts können leicht zusammenarbeiten, beispielsweise indem sie durch ein internes Netzwerk kommunizieren, das den Regeln zu Regionen und Zonen unterliegt. Ressourcen in jedem Projekt werden von denen in anderen Projekten isoliert. Sie können sie nur mit einer externe Netzwerkverbindung verbinden.

Dieses Modell erlaubt es Ihnen, Projektorte für verschiedene Abteilungen oder Gruppen in Ihrem Unternehmen zu erstellen. Dieses Modell kann auch für Tests nützlich sein: Nachdem Sie mit einem Projekt fertig sind, können Sie es löschen und alle Ressourcen, die von diesem Projekt erstellt wurden, werden ebenfalls gelöscht.

OpenStack nutzt den Begriff Mandant für eine ähnliche Funktionalität zur Aufteilung von Ressourcen für verschiedene Gruppen. In OpenStack können nur Systemadministratoren neue Mandante erstellen.

Netzwerkkonfiguration

Nachfolgend werden die Bedingungen und Konzepte von OpenStack mit denen von GCP verglichen:

OpenStack GCP Hinweise
Neutron Cloud Virtual Network Cloud Virtual Network ist ein verwalteter Netzwerkdienst. In GCP können Sie mehrere Netzwerke in Ihrem Projekt definieren und jedes Netzwerk ist unabhängig.
Virtuelles privates Netzwerk
Virtuelles privates Netzwerk Ein einzelnes virtuelles privates Netzwerk in GCP erstreckt sich über alle Regionen, die durch ein internes Netzwerk von GCP verbunden sind. Ein virtuelles privates Netzwerk in Neutron erstreckt sich über alle Verfügbarkeitszonen in einer Region.

In einer typischen OpenStack Neutron-Bereitstellung ist jedes Netzwerk eines virtuellen Mandanten in seinem eigenen privaten Netzwerkort enthalten. Wie in Abbildung 1 gezeigt, müssen Sie nicht notwendigerweise mehrere Subnetze verwenden, aber Sie können, wenn nötig, mehrere Subnetze konfigurieren. Abbildung 3 zeigt ein virtuelles Netzwerk, das aus einem einzelnen virtuellen Router und drei virtuellen Switches besteht. Zwei der virtuellen Switches verbinden sich mit dem externen Netzwerk über den virtuellen Router. AZ-1 und AZ-2 sind Verfügbarkeitszonen.

Virtuelles Netzwerk

Abbildung 3: Beispiel einer Netzwerkkonfiguration in OpenStack

GCP bietet zwei Netzwerktypen: Legacy und Subnetz.

Das Legacy-Netzwerk stellt ein einzelnes privates Subnetz zur Verfügung, das alle Regionen der Welt umspannt, wie in Abbildung 4 gezeigt.

In einem Subnetz-Netzwerk, zu sehen in Abbildung 5, ist ein virtueller Switch mit einem virtuellen OpenStack Neutro-Router verbunden und virtuelle Switches sind durch das interne Netzwerk verbunden. Alle Subnetze können über eine private IP-Adresse miteinander verbunden werden, sodass Sie keine globale IP-Adresse oder das Internet für die Kommunikation zwischen Regionen verwenden müssen.

In GCP können Sie eine Mischung aus Legacy-Netzwerken und Subnetz-Netzwerken in einem Projekt nutzen. Jedes neu erstellte Projekt beinhaltet ein vordefiniertes Netzwerk mit dem Namen default, in welchem sich wiederum ein Subnetz mit dem Namen default in jeder Region befindet.

Legacy-Netzwerk

Abbildung 4: Beispiel einer Legacy-Netzwerkkonfiguration auf der Google Cloud Platform

Subnetz-Netzwerk

Abbildung 5: Beispiel einer Subnetz-Netzwerkkonfiguration auf der Google Cloud Platform

IP-Adressen

Nachfolgend werden die Bedingungen und Konzepte von OpenStack mit denen von GCP verglichen:

OpenStack GCP
Instanzen haben private, interne IP-Adressen. Eine globale IP-Adresse (eine Floating-IP-Adresse) kann, falls nötig, zugewiesen werden.

Instanzen haben private, interne IP-Adressen. Zusätzlich wird beim Erstellen einer Instanz mit dem "gcloud"-Befehlszeilentool automatisch eine sitzungsspezifische IP-Adresse zugewiesen. Statische IP-Adressen können, falls nötig, ebenfalls zugewiesen werden.
Globale IP-Adressen sind notwendig für die Kommunikation zwischen Instanzen in verschiedenen Regionen oder unter verschiedenen virtuellen Routern. Subnetze in allen Regionen können über eine private IP-Adresse miteinander verbunden werden, sodass Sie keine globale IP-Adresse oder das Internet für die Kommunikation zwischen Instanzen verwenden müssen.

In Neutron kommunizieren VM-Instanzen in einem privaten Netzwerk über virtuelle Switches und Router unter Verwendung privater IP-Adressen, die zu Beginn zugewiesen wurden. Globale IP-Adressen werden nicht standardmäßig zugewiesen.

Der virtuelle Router verarbeitet den Zugang von VM-Instanzen zum externen Netzwerk, sodass Instanzen die dem virtuellen Router zugewiesene gemeinsame globale IP-Adresse teilen. Um eine Instanz für das externe Netzwerk freizugeben und Verbindungen von externen Nutzern zuzulassen, weisen Sie der Instanz eine Floating-IP-Adresse aus einem Pool von globalen IP-Adressen zu.

Da sich das virtuelle Netzwerk in einer einzelnen Region befindet, müssen Instanzen in unterschiedlichen Regionen die Floating-IP-Adresse verwenden, um über das externe Netzwerk zu kommunizieren.

Ein einzelnes Netzwerk kann mehrere virtuelle Router enthalten. VM-Instanzen, die mit verschiedenen Routern verbunden sind, können nicht direkt mit privaten IP-Adressen kommunizieren. Sie kommunizieren jedoch durch das externe Netzwerk, indem Sie Floating-IP-Adressen verwenden.

In GCP haben anfangs alle VM-Instanzen eine interne IP-Adresse und eine externe IP-Adresse. Sie können eine externe IP-Adresse trennen, falls nötig.

Standardmäßig sind externe IP-Adressen sitzungsabhängig, also gebunden an das Bestehen der Instanz. Wenn Sie eine Instanz herunterfahren und dann wieder starten, wird ihr möglicherweise eine andere externe IP-Adresse zugewiesen. Sie können auch eine permanente IP-Adresse – genannt statische IP – anfordern, um sie einer Instanz zuzuordnen. Eine statische IP-Adresse ist Ihre, bis Sie sich entscheiden, sie freizugeben und sie explizit VM-Instanzen zuweisen. Statische IP-Adressen können nach Bedarf Instanzen zugeordnet oder von Instanzen genommen werden.

Wie in den Beispielarchitekturen zu einer 3-Tier-Webanwendung gezeigt, müssen Sie in OpenStack bei Failover, da Sie nicht die gleiche IP-Adresse in verschiedenen Regionen verwenden können, einen zusätzlichen Mechanismus wie Dynamic DNS nutzen, um den Clients den Zugriff auf den Dienst mit gleichen URLs zu erlauben.

In GCP hingegen können Sie eine einzelne, globale IP-Adresse (VIP), die von Cloud Load Balancing zur Verfügung gestellt wurde, verwenden, um den Client-Zugriff auf mehrere Regionen und Zonen zu verteilen. Dies bietet Failover zwischen Regionen und Zonen, was für den Client erkennbar ist.

Firewalls

Nachfolgend werden die Bedingungen und Konzepte von OpenStack mit denen von GCP verglichen:

OpenStack GCP Hinweise
Erzwingt Firewallregeln mithilfe von Sicherheitsgruppen. Erzwingt Firewallregeln mithilfe von Regeln und Tags. Eine Sicherheitsgruppe in OpenStack beinhaltet mehrere ACLs, die Sie durch Instanz-Rolle definieren und dann einer Instanz zuweisen.

Sicherheitsgruppen in OpenStack müssen für jede Region definiert sein.

GCP-Regeln und -Tags können einmal definiert und in allen Regionen verwendet werden.

In OpenStack enthält eine Sicherheitsgruppe mehrere Zugriffskontrolllisten (ACLs), die unabhängig von VM-Instanzen sind. Sie können einer VM-Instanz eine Sicherheitsgruppe zuweisen, um die ACLs auf diese Instanz anzuwenden. Gewöhnlich definieren Sie Sicherheitsgruppen nach VM-Instanz-Rollen, wie Webserver oder Datenbankserver.

Beispielsweise definieren Sie für die Beispielarchitektur die folgenden Sicherheitsgruppen für jede Region:

Sicherheitsgruppe Quelle Protokoll
load-balancer Beliebig HTTP/HTTPS
Subnetz-Verwaltung SSH
web-server load-balancer HTTPS
Subnetz-Verwaltung SSH
web-application web-server TCP 8080
Subnetz-Verwaltung SSH
database web-application MYSQL
Subnetz-Verwaltung SSH

Sie können die Paketquelle mit einem Subnetz-Bereich oder dem Namen einer Sicherheitsgruppe festlegen. In der obigen Tabelle steht Subnetz-Verwaltung für einen Subnetz-Bereich, von dem aus sich Systemadministratoren zu Wartungszwecken beim Gastbetriebssystem anmelden.

Bei dieser Architektur wird angenommen, dass Client-SSL beim Lastenausgleichsmodul, das über HTTPS mit Webservern kommuniziert, beendet ist. Webserver kommunizieren mit Anwendungsservern über TCP 8080. MySQL wird für die Datenbankserver verwendet.

Nachdem Sie diese Sicherheitsgruppen definiert haben, weisen Sie sie jeder Instanz wie folgt zu:

Instanz Sicherheitsgruppe
Lastenausgleichsmodul load-balancer
Webserver web-server
Anwendungsserver web-application
Datenbankserver database

In GCP können Sie mit Cloud Virtual Network mithilfe von Regeln und Tags Firewallregeln definieren, die alle Regionen umfassen. Ein Tag ist eine willkürliche Bezeichnung, die einer VM-Instanz zugeordnet ist. Sie können einer einzelnen VM-Instanz mehrere Tags zuordnen. Eine Regel ist eine ACL, die unter den folgenden Bedingungen Paketfluss ermöglicht:

  • Quelle: IP-Bereich, Subnetz, Tags
  • Ziel: Tags

Zum Beispiel definieren Sie erst eine Regel, die es ermöglicht, Pakete mit einem Ziel-Port TCP 80 von jeder IP-Adresse zum Tag Webserver zu schicken. Dann können Sie das Webserver-Tag zu jeder VM-Instanz hinzufügen, um HTTP-Verbindungen zu ihnen zu erlauben. Sie verwalten Tags, um Instanzrollen festzulegen, und Regeln, um ACLs festzulegen, die separat mit Rollen korrespondieren.

Abbildung 6 zeigt einige vordefinierte Regeln für das Standardnetzwerk in einem neu erstellten Projekt. Beispielsweise ist 10.128.0.0/9 ein Subnetz-Bereich, der zugrunde liegende Subnetze in allen Regionen enthält. Der Subnetz-Bereich kann in jedem Projekt unterschiedlich sein. Von Anfang bis zum Ende erlauben die Regeln folgende Netzwerkverbindungen:

  • Internet Control Message Protocol (ICMP)-Pakete von einer beliebigen externen Quelle.
  • Beliebige Pakete zwischen jeder Instanz, die mit dem Standardnetzwerk verbunden ist.
  • Remote Desktop Protocol (RDP)-Verbindung von einer beliebigen externen Quelle.
  • Secure Shell (SSH)-Verbindung von einer beliebigen externen Quelle.

Vordefinierte Firewallregeln

Abbildung 6: Vordefinierte Firewallregeln in Virtual Cloud Network für das Standardnetzwerk

Weitere Informationen finden Sie unter Netzwerke und Firewalls verwenden.

Für die Firewall-Regeln in GCP verwenden Sie Tags, um das Ziel der Pakete festzulegen und Subnetz-Bereiche oder Tags, um die Quellen der Pakete festzulegen. In diesem Szenario definieren Sie die folgenden Regeln:

Quelle Ziel Protokoll
130.211.0.0/22 web-server HTTP, HTTPS
web-server web-application TCP 8080
Subnetz-Verwaltung web-server, web-application SSH

In der oben stehenden Tabelle ist 130.211.0.0/22 ein Subnetz-Bereich, von dem das Lastenausgleichsmodul und die Systemdiagnose auf den Webserver zugreifen. Subnetz-Verwaltung steht für einen Subnetz-Bereich, von dem aus sich Systemadministratoren zu Wartungszwecken im Gästebetriebssystem anmelden können. web-server und web-application sind Tags, die dem Webserver respektive dem Anwendungsserver zugewiesen sind. Statt Regeln festzulegen, wie Sie es bei Sicherheitsgruppen machen würden, weisen Sie Instanzen Tags entsprechend ihren Rollen zu.

Die Zugriffskontrolle für die Datenbankverbindung wird anhand der Quell-IP-Adresse als Teil der Cloud SQL-Konfiguration konfiguriert.

Speicherung

Nachfolgend werden die Bedingungen und Konzepte von OpenStack mit denen von GCP verglichen:

OpenStack GCP Hinweise
Cinder Volumes Nichtflüchtiger Speicher Dauerhafter Speicherplatz mit angegliederten Instanzen

Mit dem nichtflüchtigen Speicher in GCP werden Daten automatisch verschlüsselt, bevor sie von einer Instanz zu einem Speicherort in einem nichtflüchtigen Speicher gelangen.

Sitzungsspezifische Festplatten Sitzungsspezifischer Speicherplatz mit angegliederten Instanzen
OpenStack Swift Cloud Storage Objektspeicher-Dienste
Ephemerische Laufwerke und Cinder Volumes

OpenStack bietet zwei Optionen für Laufwerke mit angegliederten Instanzen: ephemerische Laufwerke und Cinder Volumes.

Ephemerische Laufwerke sind für die Verwendung als Systemfestplatten, die Betriebssystemdateien beinhalten, gedacht und Cinder Volumes sind zum Speichern von persistenten Anwendungsdaten vorgesehen. Da Live-Migration bei ephemerischen Laufwerken nicht verfügbar ist, werden Cinder Volumes häufig auch als Systemfestplatte verwendet.

Wenn ein ephemerisches Laufwerk als Systemfestplatte genutzt wird, wird ein Image des Betriebssystem-Templates in den lokalen Speicher eines Compute-Knotens kopiert und das lokale Image wird zur Instanz hinzugefügt. Wenn die Instanz zerstört wird, wird das Image auch zerstört.

Cinder Volumes stellen einen persistenten Festplattenbereich zur Verfügung, der sich im externen Speichergerät befindet. In typischen Bereitstellungen ist das Blockgerät an den Compute-Knoten angehängt, der das iSCSI-Protokoll verwendet, und als virtuelles Laufwerk an die Instanz angehängt. Wenn die Instanz zerstört wird, verbleibt das angehängte Volume im externen Gerät und kann von einer anderen Instanz nochmal verwendet werden.

Anwendungssoftware, die auf der Instanz ausgeführt wird, kann auch auf den Objektspeicher von OpenStack Swift zugreifen.

Sitzungsspezifisches Laufwerk und Cinder-Volume

Abbildung 7: Vergleich eines ephemerischen Laufwerks mit einem Cinder Volume in OpenStack

Nichtflüchtiger Speicher

GCP bietet nichtflüchtige Speicherung angehängt an eine Instanz in der Form von persistenten Laufwerken, welche den Cinder Volumes in OpenStack ähneln. Ein nichtflüchtiger Speicher wird als eine Systemfestplatte verwendet, die Betriebssystemdateien enthält, und um persistente Anwendungsdaten zu speichern. Die Daten werden automatisch verschlüsselt, bevor Sie von einer Instanz zu einem Speicherort in einem nichtflüchtigen Speicher gelangen. Sie können einen einzelnen nichtflüchtigen Speicher auf bis zu 64 TB erweitern, aber die maximale Kapazität der hinzugefügten Festplatte wird durch die Größe der Instanz beschränkt. Weitere Informationen in Speicheroptionen.

Wenn Sie leistungsfähigen lokalen Speicher benötigen, können Sie auch lokale persistente SSD-Laufwerke verwenden. Jede lokale SSD ist 375 GB groß, aber Sie können bis zu acht lokale SSD-Geräte pro Instanz hinzufügen, um insgesamt 3 TB lokalen SSD-Speicher zu erreichen. Beachten Sie, dass Live-Migration für Instanzen mit angehängten lokalen SSDs verfügbar ist. Da die Daten in lokalen SSDs während der Live-Migration zwischen Instanzen kopiert werden, kann die Speicherleistung temporär abnehmen.

Anwendungssoftware, die auf der Instanz ausgeführt wird, kann auf die Objektspeicherung von Cloud Storage zugreifen. Dies ist ein gehosteter Dienst für die Speicherung von und den Zugriff auf eine Vielzahl an binären Objekten oder Blobs von verschiedener Größe.

VM-Instanzen

Nachfolgend werden die Bedingungen und Konzepte von OpenStack mit denen von GCP verglichen:

OpenStack GCP Hinweis
Instanztyp Maschinentyp In OpenStack können normale Nutzer keine eigenen Instanztypen erstellen.

In GCP kann jeder Nutzer eigene Instanztypen erstellen.
Metadatendienst Metadatenserver OpenStack stellt nur Informationen über Instanzen bereit.

GCP stellt auch Informationen über Projekte bereit.

Wenn Sie eine neue VM-Instanz in OpenStack starten, wählen Sie einen Instanztyp, um die Größe der Instanz festzulegen. Beispielsweise die Anzahl an vCPUs und die Speichergröße. Wenn Ihnen die entsprechenden Zugriffsrechte von Ihrem Systemadministrator zugewiesen werden, können Sie weitere Instanztypen definieren. Normalen Nutzern ist es nicht erlaubt, eigene Instanztypen hinzuzufügen.

In GCP sind Instanztypen als Maschinentypen definiert. Zusätzlich zu der Wahl eines vordefinierten Maschinentyps kann ein Nutzer die Anzahl der vCPUs und die Speichergröße separat anpassen, um einen benutzerdefinierten Maschinentyp erstellen. Weitere Informationen in Maschinentypen.

Metadaten

OpenStack bietet einen Metadatendienst, um Informationen über VM-Instanzen von der Instanz Gastbetriebssystem zu erhalten, wie beispielsweise Instanztyp, Sicherheitsgruppen und zugewiesene IP-Adresse. Sie können auch benutzerdefinierte Metadaten in der Form Schlüssel/Wert hinzufügen. OpenStack bietet einen Typ von Metadaten, der Nutzerdaten genannt wird. Sie können eine ausführbare Textdatei als user-data angeben, wenn Sie eine neue Instanz starten, damit der Agent cloud-init im Gästebetriebssystem ausgeführt wird und Startkonfigurationsaufgaben nach ihren Inhalten, wie das Installieren von Anwendungspaketen, durchführt. Mit der URL unter http://169.254.169.254/latest/meta-data greifen Sie auf Metadaten des Gästebetriebssystems zu.

GCP stellt Metadatenserver zum Abrufen von Informationen über Instanzen und Projekte des Instanz-Gastbetriebssystems zur Verfügung. Projekt-Metadaten werden von allen Instanzen in dem Projekt geteilt. Sie können benutzerdefinierte Metadaten sowohl zu Instanz-Metadaten als auch zu Projekt-Metadaten in der Form Schlüssel/Wert hinzufügen. GCP bietet spezielle Metadaten mit den Namen startup-script und shutdown-script, die ausgeführt werden, wenn Sie die Instanz starten oder herunterfahren.

Anders als user-data in OpenStack wird startup-script jedes Mal ausgeführt, wenn Sie die Instanz neustarten. Die beiden Skripts startup-script und shutdown-script werden von dem Agent in den compute-image-packages verarbeitet. Diese sind in den Images mit Betriebssystemvorlagen vorinstalliert. Weitere Informationen unter Instanz-Metadaten speichern und abrufen.

Verwenden Sie eine der folgenden URLs, um auf Metadaten vom Gastbetriebssystem zuzugreifen:

  • http://metadata.google.internal/computeMetadata/v1/
  • http://metadata/computeMetadata/v1/
  • http://169.254.169.254/computeMetadata/v1/
Gastbetriebssystem-Agent
OpenStack GCP Hinweise
cloud-init Agent-Paket für Konfigurationsaufgaben compute-image-packages Agent-Paket für Konfigurationsaufgaben Der OpenStack-Agent erledigt nur die anfänglichen Boot-Einstellungen.

Der GCP-Agent erledigt die anfänglichen Boot-Einstellungen und dynamische Änderungen der Einstellungen während die Instanz ausgeführt wird.

In OpenStack ist das Agent-Paket mit dem Namen cloud-init in den Standard-Images des Gastbetriebssystems vorinstalliert. Es erledigt die anfänglichen Konfigurationsaufgaben beim ersten Hochfahren, wie den Platz für das Root-Dateisystem zu erweitern, einen öffentlichen SSH-Schlüssel zu speichern und das als Nutzerdaten zur Verfügung gestellte Skript auszuführen.

In GCP ist das Agent-Paket mit dem Namen compute-image-packages in den Standard-Images des Gastbetriebssystems vorinstalliert. Es erledigt die anfänglichen Konfigurationsaufgaben durch startup-script beim ersten Hochfahren und kümmert sich um die dynamische Systemkonfiguration während das Gastbetriebssystem ausgeführt wird, wie zum Beispiel neue öffentliche SSH-Schlüssel hinzuzufügen und die Netzwerkkonfiguration für den HTTP-Lastenausgleich zu ändern. Sie können einen neuen SSH-Schlüssel mithilfe der Google Cloud Platform Console oder des gcloud-Befehlszeilentools erstellen, nachdem Sie eine Instanz gestartet haben.

Google Cloud SDK ist in den Standard-Images des Gastbetriebssystems in GCP vorinstalliert. Sie können das SDK nutzen, um auf Dienste in GCP vom Gastbetriebssystem zuzugreifen, indem Sie ein Dienstkonto verwenden, dem standardmäßig gewisse Berechtigungen eingeräumt werden.

Zugriffskontrolle

Die Zugriffssteuerung wird in der GCP von Google Cloud IAM verbindlich pro Instanz festgelegt. Wenn Sie beispielsweise Ihre Anwendung auf einer Instanz ausführen möchten, um Daten in Google Cloud Storage zu speichern, können Sie der Instanz Lese- und Schreibberechtigungen zuweisen. Mit Cloud IAM müssen Sie keine Passwörter oder Anmeldecodes für Anwendungen, die in der Instanz ausgeführt werden, vorbereiten. Weitere Informationen unter Dienstkontos für Instanzen erstellen und freigeben.

OpenStack Keystone bietet Zugriffskontrolle für Dienst-APIs basierend auf dem Nutzerkonto, aber bietet keine Zugriffskontrolle basierend auf Instanzen für Anwendungs-APIs, wie Lese- und Schreibberechtigung für den Objektspeicher oder die Datenbank. Sie können, falls nötig, eine benutzerdefinierte Zugriffskontrolle für Anwendungs-APIs implementieren.

Über IaaS hinaus: PaaS (Platform as a Service)

In diesem Artikel werden die Komponenten und Dienste, die von OpenStack und der Cloud Platform angeboten werden und für IaaS essentiell sind, verglichen. Aber um das Beste aus GCP im Hinblick auf Verfügbarkeit, Skalierbarkeit und operative Effizienz herauszuholen, sollten Sie verwaltete Dienste als Bausteine für Ihr gesamtes System kombinieren.

Der volle Umfang von GCP-Diensten geht weit über das althergebrachte Konzept einer IaaS-Plattform hinaus und umfasst Folgendes:

Weitere Informationen

  • Weitere Informationen über die Anpassung von Google Cloud Dataproc an Speicher-, Computing- und Überwachungsdienste in GCP, um eine vollständige Plattform zur Datenverarbeitung zu erstellen.
  • Weitere Informationen zur Überwachung, dem Logging und der Diagnose mit Google Stackdriver.
  • Informationen über Google BigQuery, ein vollständig verwaltetes Data Warehouse für Analysen, das eine serverlose Plattform bereitstellt, sodass Sie sich auf die Datenanalyse mit SQL von Datensätzen im Petabyte-Bereich konzentrieren können.
  • Weitere Informationen zu Produkten und Diensten der Google Cloud Platform
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Google Cloud Platform für OpenStack-Nutzer