Beispiel einer Failover-Cloud-Architektur Teil 3

Bei diesem Text handelt es sich um eine maschinell erstellte Übersetzung. Eine überarbeitete Version ist in Planung.

In Teil 1 und Teil 2 sprachen wir über Failover-Cloud-Architekturen und Lastausgleichslösungen, die auf Keepalived und IPVS basieren. Dies ist eine sehr häufige Situation, wenn es um den Lastausgleich von Webservern geht - oft muss man komplexe Funktionalitäten mit Lastausgleich abgleichen, während man sicherstellt, dass sein System läuft.

Möglicherweise müssen die Load Balancer HTTPS-Sitzungen abgebrochen, Header und/oder Cookies geändert oder Inhalte manipuliert werden, je nach URI-spezifischen Umleitungen von verschiedenen Backends und/oder dem Load Balancer, um Proxy-Funktionalitäten zur Verfügung zu stellen. Es gibt heute viele verschiedene Load Balancing und Reverse Proxy Lösungen, um all diese Funktionalitäten zu handhaben (HAProxy, Varnish, Apache...), aber wir verwenden HAProxy für die Zwecke dieses Blog-Posts.

HAProxy (High Availability Proxy) ist vielleicht die populärste Open-Source-Software der Branche, die in der Lage ist, die meisten Funktionen zu beherrschen, die für den Betrieb einer vollständig redundanten Web-Anwendungsumgebung erforderlich sind. Es ist auch sehr bekannt für seine Fähigkeiten, die Zuverlässigkeit und Leistung bei der Verwendung sehr komplexer Workload-Verteilungsalgorithmen zu verbessern. HAProxy bietet eine Vielzahl von Lastausgleichsalgorithmen, die Möglichkeit, die Nutzungsfrequenz eines bestimmten Servers einzustellen, sowie viele weitere Funktionalitäten. Einige gängige Beispiele für Lastausgleichsalgorithmen sind: Round Robin, sticky sessions, Health Checks, least conn etc. Darüber hinaus kann HAProxy auf den meisten linuxbasierten Distributionen sowie auf Solaris oder FreeBSD ausgeführt werden.

In früheren Artikeln haben wir diskutiert, wie es möglich war, eine mit den VRRP-Komponenten von Keepalived und HAProxy zu erstellen und zu konfigurieren. Die VRRP-Komponente kann auch in Kombination mit anderen Tools (wie Firewalls, virtuelle Router, VPN-Gateways etc.) eingesetzt werden, um eine hohe Verfügbarkeit zu erreichen.

Setup Concept

Um eine leistungsstarke und hochverfügbare Umgebung zu schaffen, werden wir zwei HAProxy-basierte Load Balancer (HAProxy1 und HAProxy2) verwenden. Jeder Load Balancer ist mit einer zusätzlich reservierten öffentlichen IP-Adresse konfiguriert. In unserem Fall sind beide IP-Adressen als Round Robin DNS-Adressen konfiguriert. Um Verluste zu vermeiden, sind die konfigurierten IP-Adressen, die im Falle einer Dienstunterbrechung benachrichtigt werden, die VRRP-Komponenten von Keepalived und werden auch verwendet, um ein Failover auf den HAProxy-Servern zu erstellen. In unserem Beispiel haben wir 4 "echte" Webserver als Backend angeschlossen, aber Sie können jederzeit Backend-Server hinzufügen/abziehen.

Die einzelnen Server sind einer der beiden Brandabschnitte im ProfitBricks Rechenzentrum zugeordnet. Dabei ist es unser Ziel, sicherzustellen, dass Ihre Komponenten jederzeit verfügbar sind - auch bei Ausfall einer Brandzone.

Einrichtung des Rechenzentrumsdesigners (DCD)

IP-Adressen, die im öffentlichen DNS platziert werden, sind Adressen, die im DCD (Data Center Designer) in Ihrem Konto reserviert sind. Diese beiden Adressen müssen jedem der VRRP-Systeme auf der öffentlichen Netzwerkschnittstelle als zusätzliche IPs dem System zugeordnet werden, das als Master für den jeweiligen VIP fungiert.

DCD IP Manager - Reserve IPs

ProfitBricks DCD Server - Inspektionspanel - Netzwerk

Nun müssen Sie eine IP-Failover-Gruppe im öffentlichen LAN einrichten, wie in Teil 1.

VRRP-Setup mit Keepalived

Keepalived wird verwendet, um sicherzustellen, dass die öffentlichen IP-Adressen immer hochverfügbar sind. Um dies zu erreichen, werden zwei Gruppen gebildet: VGROUP1 und VGROUP2. Für jede VRRP-Gruppe wird eine VRRP-Instanz konfiguriert. Die VRRP-Instanz VI_PUBLIC_1 ist der ersten von zwei öffentlichen IP-Adressen zugeordnet und definiert den Host VRRP1 als Master. Die VRRP-Instanz VI_PUBLIC_2 ist der zweiten von zwei öffentlichen IP-Adressen zugeordnet und definiert den Host VRRP2 als Master.

!
! setup for 2 instances
!

! global config
global_defs {
   ! uncomment next line for host vrrp1
   lvs_id VRRP1
   ! uncomment next line for host vrrp2
   ! lvs_id VRRP2
}

! define vrrp groups
vrrp_sync_group VGROUP1 {
   group {
     VI_PUBLIC_1
   }
}

vrrp_sync_group VGROUP2 {
   group {
     VI_PUBLIC_2
   }
}

! vrrp instances
vrrp_instance VI_PUBLIC_1 {
   ! uncomment next line for host vrrp1
   state MASTER
   ! uncomment next line for host vrrp2
   ! state BACKUP
   interface eth0
   lvs_sync_daemon_inteface eth0
   virtual_router_id 51
   ! uncomment next line for host vrrp1
   priority 100
   ! uncomment next line for host vrrp2
   ! priority 50
   advert_int 1
   authentication {
       auth_type PASS
       auth_pass MySuperSecretPassword
   }
   virtual_ipaddress {
       162.254.25.80
   }
}

vrrp_instance VI_PUBLIC_2 {
   ! uncomment next line for host vrrp2
   ! state MASTER
   ! uncomment next line for host vrrp1
   state BACKUP
   interface eth0
   lvs_sync_daemon_inteface eth0
   virtual_router_id 52
   ! uncomment next line for host vrrp2
   ! priority 100
   ! uncomment next line for host vrrp1
   priority 50
   advert_int 1
   authentication {
       auth_type PASS
       auth_pass MySuperSecretPassword
   }
   virtual_ipaddress {
       162.254.25.81
   }
}

/etc/keepived/keepalived.conf - Diese Konfiguration ist auf Ihrem Host VRRP1 aktiv.

Die Änderungen für Ihren Host VRRP2 sind oben erläutert.

Load Balancer Setup mit HAProxy

Die HAProxy-Konfiguration ist für beide VRRP-Hosts identisch. Dies ist die Mindestkonfiguration, um HTTP-Lastausgleich zu implementieren.

/etc/haproxy/haproxy.conf - Diese Konfiguration erstellt einen HTTP-Lastausgleich "WebCheck", der die Bereitschaft der vier konfigurierten Webserver überprüft.

global
       log /dev/log   local0
       log /dev/log   local1 notice
       chroot /var/lib/haproxy
       user haproxy
       group haproxy
       daemon
 
defaults
       log     global
       mode   http
       option httplog
       option dontlognull
       contimeout 5000
       clitimeout 50000
       srvtimeout 50000

listen WebCheck 0.0.0.0:80
   mode http
   balance roundrobin
   option httpclose
   option forwardfor
   server web1 10.9.238.13:80 check
   server web2 10.9.238.14:80 check
   server web3 10.9.238.15:80 check
   server web4 10.9.238.16:80 check

Eingehende Anfragen werden gemäß den definierten Round Robin-Regeln an verfügbare Backend-Server verteilt. Bei der Konfiguration der Lastausgleiche sind zwei Einstellungen zu beachten:

  • Der virtuelle Server muss mit der Adresse 0.0.0.0.0.0 verbunden sein. Dadurch wird sichergestellt, dass bei einem Failover auf Anfragen die zusätzlich konfigurierten IPs des VRRP-Hosts beantwortet werden..
  • Die Option "forwardfor" muss gesetzt sein, um sicherzustellen, dass die Backend-Server-Requests immer die Load Balancer-Requests beantworten.

Um ein solches System praktisch nutzen zu können, ist es auch notwendig, eine Synchronisationsmethode für Ihre Web-/Anwendungsserverinhalte zu implementieren. Dies hängt natürlich direkt vom Betriebssystem/der Technologie ab, die auf den Webservern verwendet wird.  Dies ist eine Möglichkeit, eine Failover-Cloud-Architektur auf einer flexiblen Public Cloud wie ProfitBricks zu erstellen.  Welche Methoden verwenden Sie? Sie können sich jederzeit für unsere kostenlose 14-tägige Testversion anmelden und Ihre Lösung testen, mit dem Data Center Designer können Sie Ihre Idee schnell testen.

Links

Keepalived Startseite: http://www.keepalived.org/

HAproxy Startseite: http://www.haproxy.org/