Übertragung von AWS oder Azure über ein vom Kunden verwaltetes privates Netzwerk

Eine private Netzwerkverbindung, die entweder über Google Cloud Cross-Cloud Interconnect oder Partner Interconnect hergestellt wird, kann erhebliche Vorteile für die Datenübertragung zwischen AWS oder Azure und Cloud Storage bieten:

  • Mögliche Kostenoptimierung: Möglicherweise können Sie Ausleitungskosten sparen. Dies kann für Kunden mit bestehenden Interconnect-Verbindungen oder für Kunden, die große oder wiederkehrende Datenübertragungen durchführen, von Vorteil sein und zu erheblichen langfristigen Einsparungen führen.
  • Dedizierte Netzwerkbandbreite: Die Verwendung einer Interconnect-Verbindung kann einen konsistenten Durchsatz mit hoher Kapazität und eine geringere Latenz bieten. Das ist entscheidend für große, zeitkritische Migrationen und Echtzeit-Datensynchronisierung.
  • Compliance-Anforderungen erfüllen: Ideal für Arbeitslasten, bei denen es aufgrund gesetzlicher Anforderungen erforderlich ist, dass Daten nicht über das öffentliche Internet übertragen werden. Mit dieser Funktion können Sie Daten privat über die Interconnect-Verbindung übertragen, um Compliance zu erreichen, die Datenhoheit zu unterstützen und Audits zu vereinfachen.

Übersicht

In diesem Dokument werden die folgenden Schritte beschrieben:

  • Cross-Cloud Interconnect bestellen und konfigurieren
  • Endpunkt in S3 oder Azure erstellen
  • Regionalen internen Proxy-Network Load Balancer mit Hybridkonnektivität einrichten
  • Load Balancer bei Service Directory registrieren
  • Übertragung erstellen
  • Bestätigen, dass Traffic die Interconnect-Verbindung verwendet

Erforderliche Berechtigungen

Sie benötigen bestimmte Berechtigungen, um die einzelnen Abschnitte auszuführen. Diese Berechtigungen sind in der Dokumentation für die jeweiligen Schritte aufgeführt.

Interconnect-Optionen

Der Storage Transfer Service kann Daten von AWS und Azure über Cross-Cloud Interconnect (CCI) oder Partner Interconnect übertragen.

Die folgenden Schritte gelten speziell für CCI, sind aber auch bei der Konfiguration der Netzwerkeinstellungen für Partner Interconnect anwendbar.

Cross-Cloud Interconnect bestellen und konfigurieren

Eine Cross-Cloud Interconnect-Verbindung ist eine dedizierte physische Verbindung zwischen Google Cloud und anderen Cloud-Anbietern.

Wenn Sie bereits eine CCI-Verbindung haben, fahren Sie mit dem nächsten Abschnitt fort.

AWS

Folgen Sie der Anleitung unter Verbindung zu Amazon Web Services herstellen, um eine neue Cross-Cloud Interconnect-Verbindung zu bestellen und zu konfigurieren. Sie benötigen die richtigen Berechtigungen, um die Netzwerkeinstellungen sowohl in Google Cloud als auch in AWS zu konfigurieren.

In diesem Video werden die Schritte zum Bestellen und Konfigurieren einer CCI zwischen AWS und Google Cloud beschrieben.

Azure

Folgen Sie der Anleitung unter Verbindung zu Microsoft Azure herstellen, um eine neue Cross-Cloud Interconnect-Verbindung zu bestellen und zu konfigurieren. Sie benötigen die richtigen Berechtigungen, um die Netzwerkeinstellungen sowohl in Google Cloud als auch in Azure zu konfigurieren.

In diesem Video werden die Schritte zum Bestellen und Konfigurieren einer CCI Verbindung zwischen Azure und Google Cloud beschrieben.

Wenn Ihr Cloud Storage-Bucket ein regionaler Bucket ist, sollten Sie die CCI-Verbindung in derselben Region wie Ihren Bucket konfigurieren, um die Netzwerklatenz zu reduzieren.

Endpunkt in S3 oder Azure erstellen

Erstellen Sie einen Endpunkt in Ihrem S3- oder Azure-Konto.

AWS

Erstellen Sie in Ihrem Amazon Web Services-Konto einen VPC-Endpunkt, der eine Verbindung zu S3 herstellt.

Folgen Sie dieser AWS-Anleitung, um den Endpunkt zu erstellen: Access an AWS service using an interface VPC endpoint (Auf einen AWS-Dienst über einen VPC-Endpunkt der Schnittstelle zugreifen).

Azure

Konfigurieren Sie einen privaten Endpunkt für das Speicherkonto in Azure. Folgen Sie dazu dieser Anleitung.

Für den Storage Transfer Service ist der Endpunkt *.blob.core.microsoft.net erforderlich. Der Endpunkt *.dfs.core.microsoft.net wird nicht unterstützt.

Notieren Sie sich nach der Erstellung die IP-Adresse des Endpunkts. Sie müssen die IP-Adresse angeben, wenn Sie im nächsten Abschnitt den Load Balancer erstellen.

Regionalen internen Proxy-Network Load Balancer mit Hybridkonnektivität einrichten

Richten Sie in Google Cloud einen regionalen internen Proxy-Network Load Balancer mit Hybridkonnektivität ein. Dadurch wird eine interne IP-Adresse bereitgestellt, die auf Clients beschränkt ist, die im selben VPC-Netzwerk wie der Load Balancer ausgeführt werden. Außerdem wird der Traffic an die S3-VPC-Endpunkte oder privaten Azure Storage-Endpunkte weitergeleitet, die Sie im vorherigen Abschnitt erstellt haben.

Sie sollten den Load Balancer im selben Projekt und VPC-Netzwerk wie den VLAN-Anhang erstellen, der mit der Cloud Interconnect-Verbindung verbunden ist. Die Interconnect-Verbindung selbst kann sich in einem anderen Projekt innerhalb derselben Organisation befinden, der Anhang muss sich jedoch in derselben VPC und Region wie der Load Balancer befinden.

Geben Sie die IP-Adresse des S3-VPC-Endpunkts oder des privaten Azure Storage-Endpunkts an, wenn Sie die Schritte unter Endpunkte zur NEG mit Hybridkonnektivität hinzufügen erreichen.

Notieren Sie sich die Frontend-IP-Adresse und den Port des NLB, da Sie sie im nächsten Abschnitt angeben müssen.

Verbindung validieren

Bevor Sie fortfahren, sollten Sie prüfen, ob der Load Balancer eine Verbindung zum Remote-Speicherendpunkt herstellen kann.

Anleitung:

  1. Erstellen Sie eine Compute Engine-VM im selben VPC-Netzwerk wie Ihren Load Balancer.

  2. Testen Sie von der VM aus mit curl die Verbindung zur IP-Adresse und zum Port des Load Balancers:

    curl -v --resolve HOSTNAME:PORT:LOAD_BALANCER_IP https://HOSTNAME

    Ersetzen Sie Folgendes:

    • HOSTNAME ist der Hostname Ihres Quellspeicheranbieters.
      • Verwenden Sie für AWS S3 den S3 API-Endpunkt für die Region Ihres Buckets, z. B. s3.us-west-1.amazonaws.com.
      • Verwenden Sie für Azure Storage den Blob-Endpunkt Ihres Speicherkontos, z. B. mystorageaccount.blob.core.windows.net.
    • PORT ist der Port, den Sie in der Weiterleitungsregel des Load Balancers konfiguriert haben, in der Regel 443.
    • LOAD_BALANCER_IP ist die Frontend-IP-Adresse Ihres Load Balancers.

Eine Antwort vom Remote-Endpunkt, auch wenn es sich um einen Fehler handelt, zeigt an, dass die Verbindung erfolgreich war. Ein Verbindungs-Timeout weist auf eine Fehlkonfiguration in Ihrer Netzwerkeinrichtung hin, die Sie beheben sollten, bevor Sie fortfahren.

NLB bei Service Directory registrieren

Registrieren Sie den NLB in Service Directory. Der Storage Transfer Service verwendet Service Directory, um die Adresse des Load Balancers aufzulösen und eine direkte Verbindung zu ihm herzustellen.

Folgen Sie der Anleitung zum Registrieren eines internen Load Balancers. Verwenden Sie die IP-Adresse und den Port des Load Balancers, die Sie beim Angeben der Weiterleitungsregel erstellt haben.

Notieren Sie sich nach der Erstellung den Self-Link des Dienstes. Er hat das Format projects/{project_id}/locations/{location}/namespaces/{namespace}/services/{service}. Sie benötigen diesen Wert, wenn Sie den Übertragungsjob erstellen.

Übertragung erstellen

Erteilen Sie dem Dienst-Agent die folgenden Berechtigungen. Eine Anleitung zum Abrufen des Dienst-Agents und zum Erteilen von Berechtigungen für den Dienst-Agent finden Sie unter Berechtigungen für von Google verwaltete Dienst-Agents.

Wenn Sie einen Übertragungsjob erstellen möchten, der eine Cross-Cloud Interconnect-Verbindung verwendet, müssen Sie die Storage Transfer Service REST API verwenden. Senden Sie eine Anfrage wie folgt. Beachten Sie das Feld privateNetworkService. Hier geben Sie den Self-Link Ihres Service Directory-Dienstes an.

AWS 

POST https://storagetransfer.googleapis.com/v1/transferJobs

{
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "transferSpec": {
    "awsS3DataSource": {
        "privateNetworkService": "SERVICE_SELF_LINK",
        "bucketName": "S3_BUCKET_NAME",
        "awsAccessKey": {
          "accessKeyId": "ACCESS_KEY_ID",
          "secretAccessKey": "SECRET_ACCESS_KEY"
        }
    },
    "gcsDataSink": {
        "bucketName": "GCS_BUCKET_NAME"
    }
  }
}

Azure 

POST https://storagetransfer.googleapis.com/v1/transferJobs

{
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "transferSpec": {
      "azureBlobStorageDataSource": {
          "privateNetworkService": "SERVICE_SELF_LINK",
          "storageAccount": "AZURE_SOURCE_NAME",
          "container": "AZURE_CONTAINER",
          "azureCredentials": {
              "sasToken": "AZURE_SAS_TOKEN",
          }
      },
      "gcsDataSink": {
          "bucketName": "GCS_BUCKET_NAME"
      }
  }
}

Ersetzen Sie Folgendes:

  • SERVICE_SELF_LINK ist der Self-Link des Service Directory Dienstes. Er hat das Format projects/{project_id}/locations/{location}/namespaces/{namespace}/services/{service}.

Informationen zu anderen Feldern finden Sie in der Referenzdokumentation zu transferSpec.

Bestätigen, dass Traffic die Interconnect-Verbindung verwendet

Mit Cloud Monitoring können Sie den Traffic prüfen, der über Ihre Interconnect-Verbindung von AWS oder Azure übertragen wird.

  1. Rufen Sie in der Google Cloud Console Hybridkonnektivität > Cloud Interconnect auf.
  2. Wählen Sie den VLAN-Anhang aus, der mit Ihrer AWS-/Azure-Umgebung verbunden ist.
  3. Wählen Sie auf der Detailseite für Ihre Verbindung den Tab Monitoring aus. Suchen Sie nach Messwerten, die auf eine Datenübertragung hinweisen. Zum Beispiel:
    • Eingehende Byte:Dieser Messwert zeigt die Daten, die von AWS oder Azure in Ihre Google Cloud-VPC übertragen werden.
    • Betriebsstatus:Achten Sie darauf, dass sich sowohl die physische Verbindung als auch die BGP-Sitzung in einem fehlerfreien, betriebsbereiten Zustand befinden.