So konfigurieren Sie den globalen Lastausgleich mit Google Cloud Platform

Google bietet globale Load Balancer an, die den Datenverkehr zu einem Backend-Service in der Region leiten, die dem Benutzer am nächsten liegt, um die Latenz zu verringern. In diesem Blog konfigurieren wir eine Beispielanwendung mit einem globalen Load Balancer unter Verwendung von terraform, um alle beteiligten Komponenten zu verstehen und den Load Balancer in Betrieb zu sehen. Wenn wir uns die Dokumentation des globalen http/s Load Balancers ansehen, sehen wir, dass die folgenden Komponenten erforderlich sind:

Anhand dieses Bildes werden wir die Terraform-Definition von oben nach unten aufbauen: das Internet (Adresse).

Internet

Um Internetverkehr zu unseren Instanzen zu erhalten, müssen wir eine externe Internetadresse reservieren. In Terraform wird diese wie folgt deklariert:

resource "google_compute_global_address" "paas-monitor" {
  name = "paas-monitor"
}

globale Weiterleitungsregel

Um den an Port 80 der erstellten IP-Adresse gerichteten Datenverkehr weiterzuleiten, müssen wir eine globale Weiterleitungsregel konfigurieren, die auf unseren HTTP-Proxy abzielt:

resource "google_compute_global_forwarding_rule" "paas-monitor" {
  name       = "paas-monitor-port-80"
  ip_address = "${google_compute_global_address.paas-monitor.address}"
  port_range = "80"
  target     = "${google_compute_target_http_proxy.paas-monitor.self_link}"
}

Ziel-Proxy mit URL-Map

Der Ziel-HTTP-Proxy verwendet eine URL-Map, um den Datenverkehr an das entsprechende Backend zu senden:

resource "google_compute_target_http_proxy" "paas-monitor" {
  name    = "paas-monitor"
  url_map = "${google_compute_url_map.paas-monitor.self_link}"
}

resource "google_compute_url_map" "paas-monitor" {
  name        = "paas-monitor"
  default_service = "${google_compute_backend_service.paas-monitor.self_link}"
}

In diesem Fall wird der gesamte Datenverkehr an unser Standard-Backend gesendet.

Backend-Dienst

Ein Backend-Service besteht aus einer oder mehreren Instanzgruppen, die mögliche Ziele für den Verkehr vom Ziel-Proxy sind. In unserem Beispiel gibt es drei regionale Instanzgruppen. Eine in den USA, eine in Europa und eine in Asien.

resource "google_compute_backend_service" "paas-monitor" {
  name             = "paas-monitor-backend"
  protocol         = "HTTP"
  port_name        = "paas-monitor"
  timeout_sec      = 10
  session_affinity = "NONE"

  backend {
    group = "${module.instance-group-us-central1.instance_group_manager}"
  }

  backend {
    group = "${module.instance-group-europe-west4.instance_group_manager}"
  }

  backend {
    group = "${module.instance-group-asia-east1.instance_group_manager}"
  }

  health_checks = ["${module.instance-group-us-central1.health_check}"]
}

Gesundheitschecks

Health Checks werden vom Load Balancer verwendet, um festzustellen,
welche Instanz den Datenverkehr bewältigen kann. Die Gesundheitsprüfungen werden auch zur Unterstützung bei der automatischen Heilung und bei rollenden Updates verwendet:

resource "google_compute_http_health_check" "paas-monitor" {
  name         = "paas-monitor-${var.region}"
  request_path = "/health"

  timeout_sec        = 5
  check_interval_sec = 5
  port               = 1337

  lifecycle {
    create_before_destroy = true
  }
}

Damit GCP den Gesundheitscheck durchführen kann, müssen wir die Firewall für GCP öffnen:

resource "google_compute_firewall" "paas-monitor" {
  ## firewall rules enabling the load balancer health checks
  name    = "paas-monitor-firewall"
  network = "default"

  description = "allow Google health checks and network load balancers access"

  allow {
    protocol = "icmp"
  }

  allow {
    protocol = "tcp"
    ports    = ["1337"]
  }

  source_ranges = ["35.191.0.0/16", "130.211.0.0/22", "209.85.152.0/22", "209.85.204.0/22"]
  target_tags   = ["paas-monitor"]
}

Instanzgruppen

Um den Datenverkehr zu einer Instanz in der nächstgelegenen Region zu leiten, werden regional verwaltete Instanzgruppen verwendet. Diese Gruppen verteilen die virtuellen Maschinen über alle Zonen in der Region und schützen so vor dem Ausfall einer einzelnen Zone. Die regionalen Instanzgruppen werden mit einer Instanzvorlage, einem benannten Port und einer Zustandsprüfung konfiguriert.

resource "google_compute_region_instance_group_manager" "paas-monitor" {
  name = "paas-monitor-${var.region}"

  base_instance_name = "paas-monitor-${var.region}"
  region             = "${var.region}"
  instance_template  = "${google_compute_instance_template.paas-monitor.self_link}"

  version {
    name              = "v1"
    instance_template = "${google_compute_instance_template.paas-monitor.self_link}"
  }

  named_port {
    name = "paas-monitor"
    port = 1337
  }

  auto_healing_policies {
    health_check      = "${google_compute_http_health_check.paas-monitor.self_link}"
    initial_delay_sec = 30
  }

  update_strategy = "ROLLING_UPDATE"

  rolling_update_policy {
    type            = "PROACTIVE"
    minimal_action  = "REPLACE"
    max_surge_fixed = 10
    min_ready_sec   = 60
  }
}

In diesem Beispiel werden regionale Instanzgruppen in us-central1, europe-west4 und asia-east1 eingesetzt.

das Backend

Die Backend-Anwendung für dieses Beispiel ist der paas-monitor, eine Webanwendung, die die Identität des antwortenden Servers und die Latenz dieses Aufrufs meldet. Sie ermöglicht es dem Benutzer, den Gesundheitsstatus umzuschalten und den Prozess auf Wunsch sogar zu beenden, um das Verhalten der Hosting-Plattform zu sehen. Sie ist als Docker-Image verpackt und kann wie folgt ausgeführt werden:

"docker run -d -p 1337:1337 
    --env 'MESSAGE=gcp at ${var.region}' 
    --env RELEASE=v3.0.4.16 mvanholsteijn/paas-monitor:latest"

Dieser Befehl wird in der Vorlage für die Compute-Instanz als Startbefehl angegeben.

Demonstration

Im folgenden Video demonstrieren wir die Anwendung und die Möglichkeiten des globalen Load Balancers: Proximity Routing zu der Region/Zone, die dem Benutzer am nächsten ist, Failover und Rolling Updates.

Installation

Wenn Sie diese Anwendung in Ihrem Projekt installieren möchten, installieren Sie terraform,
erstellen Sie ein Google-Projekt und konfigurieren Sie Ihr gcloud SDK so, dass es darauf verweist. Führen Sie dann die folgenden Befehle aus:

git clone https://github.com/binxio/deployment-google-global-load-balancer-application.git
cd deployment-google-global-load-balancer-application

GOOGLE_PROJECT=$(gcloud config get-value project)
terraform init
terraform apply -auto-approve
open http://$(terraform output ip-address)

Es kann ein paar Minuten dauern, bis der Datenverkehr Ihre Anwendung erreicht. Bis dahin werden Sie http 404- und 502-Fehler erhalten.

Fazit

Obwohl in der Dokumentation von einem Global HTTP/S Load Balancer die Rede ist, haben wir in unserem Projekt
nicht "den" Load Balancer erstellt oder konfiguriert. Wir haben alle im Diagramm eingezeichneten Komponenten in unserem Terraform-Plan eindeutig konfiguriert. Wenn Sie genau hinsehen, haben wir lediglich eine Reihe von Traffic-Routing-Konstrukten erstellt, die von der Google Compute Platform verwendet werden, um den Traffic zu unserer Anwendung zu leiten. In unserem nächsten Blog werden wir zeigen, wie wir das davor liegende Content Delivery Network konfigurieren.