News
ZurückDiese Komponenten machen einen "LBaaS" aus
Die Load-Balancer von cloudscale sind eine durchdachte Sache: Sie helfen dir beim Betrieb von hochverfügbaren Setups und nehmen dir dabei viel mühsame Arbeit ab; gleichzeitig sind sie so flexibel, dass du sie – mit den passenden Settings – in ganz unterschiedlichen Anwendungsfällen einsetzen kannst. Dieser Beitrag geht auf die verschiedenen logischen Bestandteile eines Load-Balancers und ihre Möglichkeiten ein – so kannst du für deinen konkreten Fall das Maximum herausholen.
Der Load-Balancer "als Ganzes"
Ein cloudscale Load-Balancer besteht im Hintergrund aus einem redundanten Paar von virtuellen Servern, die wir für dich managen. Nach aussen hin teilen sie sich eine IP-Adresse (die sog. VIP, kurz für "virtuelle IP-Adresse"), die auf einem der beiden Systeme aktiv ist und – ähnlich einer Floating IP – bei einem erkannten Problem automatisch und praktisch nahtlos auf das andere System umgezogen wird. So verhindern wir, dass der Load-Balancer selbst zum Single Point of Failure wird, während du dir den Aufwand sparst, ein solches Setup in Eigenregie aufbauen und pflegen zu müssen.
Aus logischer Perspektive ist der Load-Balancer (bzw. das Load Balancer Object in der API) eine Art Klammer, die hinter der erwähnten VIP die nachfolgend beschriebenen Bestandteile "zusammenhält".
Zusätzliche Parameter sowie Beispiele für API-Requests und -Responses zu allen genannten Objects findest du wie immer in unserer umfassenden API-Dokumentation, so dass du alles gleich in der Praxis ausprobieren kannst.
Die Listeners
Ein Listener ist sozusagen das Ohr, mit dem dein Load-Balancer auf eingehende Verbindungen hört. Wenn du deinen Load-Balancer bspw. für HTTPS-Traffic einsetzen willst, wirst du typischerweise einen Listener auf TCP-Port 443 einrichten. Besonders praktisch: An dieser Stelle kannst du bereits definieren, welche Clients überhaupt eine Verbindung aufbauen dürfen. Erfasst du in allowed_cidrs eine oder mehrere IP-Adressen bzw. -Ranges, dann können sich nur diese, aber keine anderen Adressen zu deinem Listener verbinden.
Wie es mit dem einmal eingegangenen Traffic weitergeht, bestimmt sich nach dem konfigurierten Pool. Meist wirst du zu jedem Listener einen separaten Pool angeben, es ist aber auch möglich, mehrere Listeners auf den gleichen Pool zeigen zu lassen.
Die Pools und ihre Pool Members
Ein Pool fasst gewissermassen alle eingehenden Connections zusammen, die auf die gleiche Weise gehandhabt werden können. In erster Linie bedeutet das, die Connections an einen oder mehrere Backend-Server – die sog. Pool Members – zu verteilen, welche die Request dann bearbeiten. Für jeden Pool Member kannst du separat konfigurieren, unter welcher IP-Adresse und Port er bereit ist, die Connections aus diesem Pool anzunehmen. In unserem Beispiel müsste da also ein HTTPS-Server laufen, der aber nicht zwingend auf Port 443, sondern pro Pool Member separat auf einen beliebigen Port konfiguriert sein kann.
Direkt auf dem Pool selber konfigurierst du, nach welchem Schema die Connections bei zwei oder mehr Pool Members verteilt werden. Statt simplem round_robin kannst du mit least_connections neue Connections zu dem Pool Member leiten, der gerade die wenigsten aktiven Connections hat, oder mit source_ip alle Connections von einem bestimmten Client zum immer gleichen Pool Member – etwa für persistente Sessions bei einer Website.
Wähle zudem das protocol für deinen Pool: Mit tcp "sehen" bzw. loggen die Pool Members die IP-Adresse des Load-Balancers als vermeintlichen Client, da vom Load-Balancer zum Backend zwar die Nutzdaten weitergereicht werden, hierfür aber eine neue TCP-Verbindung aufgebaut wird. Mit proxy bzw. proxyv2 kannst du das umgehen, wenn deine Serversoftware es unterstützt (wie etwa nginx): Der Load-Balancer kann mit diesem Protokoll nicht nur die Nutzdaten der ursprünglichen Connection an den Backend-Server weitergeben, sondern auch die Information über die ursprüngliche Client-IP hinzupacken.
Die Health Monitors
Optional kannst du für jeden Pool einen Health Monitor konfigurieren. Damit legst du fest, wann die Pool Members als "gesund" gelten – etwa wenn sie auf Pings antworten oder auf einen konfigurierbaren HTTP-Request den erwarteten HTTP-Status-Code zurückliefern. Anhand des Health Monitors kann der Load-Balancer die einzelnen Pool Members periodisch überprüfen und das Balancing laufend so anpassen, dass eingehende Connections nur an funktionsfähige Backend-Server weitergereicht werden.
Zu guter Letzt möchten wir noch darauf hinweisen, dass ein Load-Balancer wahlweise aus dem Internet erreichbar sein kann oder nur aus einem deiner privaten Netze, etwa für Services innerhalb eines Kubernetes-Clusters. Öffentlich erreichbare Load-Balancer können zudem mit Floating IPs kombiniert werden. Ein einzelner Load-Balancer kann übrigens für eine Vielzahl von Services/Pools genutzt werden mit ihrem je separaten Set an Pool Members. Unser Load-Balancer "as a Service" ist aber nicht nur enorm flexibel, sondern mit CHF 1.50 pro Tag auch ausgesprochen günstig – und damit das ideale Upgrade für Setups, bei denen dir Availability wichtig ist.
Servers: Healthy.
Dein cloudscale-Team