Was ist hybrider Lastenausgleich?
Hybrider Lastenausgleich bezeichnet die Verteilung von Clientanfragen auf mehrere Serveranwendungen, die in unterschiedlichen Umgebungen ausgeführt werden: lokal, in einer Private Cloud und in der Public Cloud. Hybrider Lastenausgleich maximiert die Zuverlässigkeit, Geschwindigkeit und Kosteneffizienz der Bereitstellung von Inhalten – unabhängig davon, wo sie sich befinden – und sorgt so für ein optimales Benutzererlebnis.
Allgemeine Informationen zu Load Balancern finden Sie unter 80 % Ersparnis gegenüber Hardware-Load-Balancern.
Viele Unternehmen migrieren heute Anwendungen von lokalen Servern in die Public Cloud, um von Vorteilen wie niedrigeren Kosten und einer einfachen bedarfsgerechten Skalierung zu profitieren. Eine vollständige Migration erfolgt jedoch in der Regel nicht über Nacht, und die Cloud eignet sich nicht für jede Anwendung. Daher müssen Unternehmen häufig eine Kombination aus lokalen und cloudbasierten Anwendungen verwalten. Beispielsweise könnte ein Unternehmen einen Outlook-E-Mail-Server nutzen, der vom internen IT-Team vor Ort installiert und verwaltet wird, Kundendaten jedoch in einem cloudbasierten CRM wie Salesforce.com speichern und seinen Onlineshop auf Amazon Web Services hosten. Mit einer hybriden Load-Balancing-Lösung greifen Benutzer über einen zentralen Zugangspunkt auf die Anwendungen zu, während der Load Balancer den Datenverkehr erkennt und auf die verschiedenen Standorte verteilt.
Unternehmen, die in Private Clouds investiert haben, stehen vor einer noch komplexeren Situation, da sie die Last auf drei Ressourcenstandorte verteilen müssen. Wie die Public Cloud ist auch eine Private Cloud ein virtuelles Rechenzentrum, das extern von einem Cloud-Anbieter gehostet wird. Im Gegensatz zur Public Cloud garantiert sie jedoch dedizierten Speicherplatz und dedizierte Rechenleistung, die nicht mit anderen Kunden des Cloud-Anbieters geteilt werden.
Mit einer hybriden Lastverteilungslösung können Unternehmen den Datenverkehr nahtlos auf lokale Server, Private Clouds und die Public Cloud verteilen, sodass jede Anfrage von der jeweils am besten geeigneten Ressource bearbeitet wird. Die Entscheidung zur Lastverteilung kann auf Faktoren wie den folgenden basieren:
- Standort – Public-Cloud-Ressourcen sind fast immer geografisch verteilt. Gleiches gilt für die lokalen Ressourcen und Private-Cloud-Ressourcen multinationaler Unternehmen. Wenn Benutzer mit dem nächstgelegenen Server verbunden werden, verringert sich die Netzwerklatenz und es können lokalisierte Inhalte bereitgestellt werden (beispielsweise Texte in der Sprache des Landes, in dem sich der Server befindet).
- Anfragetyp – Hybride Load-Balancing-Lösungen können Anfragen für verschiedene Arten von Inhalten – Videos, Bilder oder Anwendungsdaten wie Preis- und Bestandsinformationen – an die Server weiterleiten, auf denen die jeweilige Art von Inhalten gehostet wird. Durch den Einsatz spezialisierter Server, die für die von ihnen bereitgestellten Inhalte optimiert werden können, entfällt die Notwendigkeit, dieselben Inhalte an jedem Standort zu duplizieren.
- Geschäftswert – Anfragen von strategisch wichtigen Kunden oder Anfragen, die voraussichtlich Umsatz generieren, können für eine möglichst schnelle und zuverlässige Bereitstellung an dedizierte Server weitergeleitet werden, während Anfragen mit geringerem Wert an eine kostengünstigere Ressource weitergeleitet werden.
- Sicherheit – Unternehmen können die größtmögliche Kontrolle über sensible Daten behalten, indem sie diese in einer Private Cloud oder lokal hosten, während sie nicht vertrauliche Daten zur Kosteneinsparung in der Public Cloud speichern.
- Kosten – Durch die hybride Lastverteilung zwischen dedizierten und Cloud-Ressourcen können Unternehmen ihren Nutzern auf möglichst kosteneffiziente Weise ein optimales Erlebnis bieten.
Hardware- vs. Software-Load-Balancing
Herkömmliche Load-Balancing-Lösungen basieren auf proprietärer Hardware, die in einem Rechenzentrum untergebracht ist und deren Anschaffung, Wartung und Aufrüstung mit erheblichen Kosten verbunden sein kann. Softwarebasierte Load Balancer können die Leistung und Zuverlässigkeit hardwarebasierter Lösungen zu deutlich geringeren Kosten bieten, da sie auf Standardhardware ausgeführt werden.
Die meisten Unternehmen folgen bewährten Verfahren und stellen Load Balancer in derselben Umgebung bereit wie die Ressourcen, deren Last sie verteilen: lokal für Anwendungen, die im Rechenzentrum ausgeführt werden, und in der Cloud für cloudbasierte Anwendungen. Anbieter von Cloud-Infrastrukturen gestatten in ihren Umgebungen in der Regel keine kundeneigene oder proprietäre Hardware. Daher müssen Unternehmen, die lokal Hardware-Load-Balancer einsetzen, für Cloud-Ressourcen dennoch einen Software-Load-Balancer verwenden. Das bedeutet, dass das IT-Personal zwei unterschiedliche Load-Balancing-Lösungen verstehen und verwalten muss. Im Gegensatz dazu kann dieselbe softwarebasierte Load-Balancing-Lösung, beispielsweise NGINX und NGINX Plus, sowohl lokal als auch in der Cloud bereitgestellt werden. Dadurch lassen sich die betriebliche Komplexität, die Kosten sowie der Zeitaufwand für die Entwicklung und Bereitstellung von Anwendungen reduzieren.
Wie kann NGINX helfen?
NGINX Plus und NGINX sind erstklassige Load-Balancing-Lösungen, die von stark frequentierten Websites wie Dropbox, Netflix und Zynga eingesetzt werden. Mehr als 350 Millionen Websites weltweit vertrauen auf NGINX Plus und NGINX Open Source, um ihre Inhalte schnell, zuverlässig und sicher bereitzustellen.
Als Software-Load-Balancer ist NGINX Plus deutlich kostengünstiger als Hardwarelösungen mit vergleichbarem Funktionsumfang. Darüber hinaus lässt es sich problemlos in einer Cloud-Infrastruktur wie Amazon Elastic Cloud Compute (EC2) bereitstellen, um die Last auf Ressourcen in der Public Cloud sowie auf lokale Ressourcen und Ressourcen in der Private Cloud zu verteilen.
Wenn Sie mehr über die Vorteile von NGINX Plus für den Lastenausgleich Ihrer Anwendungen erfahren möchten, laden Sie unser E-Book Fünf Gründe für die Wahl eines Software-Load-Balancers herunter.

