Thursday, November 5, 2026
Home » So optimieren Sie Ihr Netzwerk vor der Bereitstellung einer gestreckten Multi-Site-Architektur mit Scality RING

So optimieren Sie Ihr Netzwerk vor der Bereitstellung einer gestreckten Multi-Site-Architektur mit Scality RING

Dank langjähriger Erfahrung mit Kunden weltweit und aus allen Branchen wissen die Solution Engineers von Scality, wie sich Datenschutz und Verfügbarkeit für die IT maximieren lassen. Wir haben gesehen, dass gestreckte Multi-Site-Architekturen Kunden eine beeindruckende Verfügbarkeit bieten – doch vor der Bereitstellung gilt es, einige zentrale Faktoren im Netzwerk zu beachten. 

Mit anderen Worten: Wir möchten unseren Kunden helfen, ihr Netzwerk so zu optimieren, dass die Bereitstellung von Scality RING ein Kinderspiel wird. Wie bringen Sie Ihr Netzwerk also in Topform für eine gestreckte Architektur? Lesen Sie weiter.

Gestreckte Multi-Site-Bereitstellungen von Scality RING: RPO- und RTO-Ziele festlegen

Schnelle Wiederherstellung und Datenschutz ohne Einbußen bei Performance oder Verfügbarkeit der Anwendungen

Für die meisten Organisationen ist das bevorzugte Bereitstellungsmodell für Scality RING eine sogenannte gestreckte Architektur – bei der alle Knoten eines Clusters gleichmäßig auf verschiedene physische Standorte verteilt sind (in der Cloud-Terminologie Verfügbarkeitszonen). Gestreckte Architekturen über zwei oder drei Standorte sind bei Scality üblich. Dieser Ansatz stellt sicher, dass ein ganzer Standort – plus ein weiterer Server oder eine Festplattengruppe – ausfallen kann und dennoch voller Lese- und Schreibzugriff mit einem Recovery Point Objective (RPO) und einer Recovery Time Objective (RTO) von null erhalten bleibt. 

Warum ist das wichtig? Selbst wenn ein Standort wegen eines Stromausfalls oder Netzwerkproblemen (oder Schlimmerem) ausfällt oder nicht erreichbar ist, sind Sie weiterhin gegen einen weiteren Ausfall geschützt – ohne Auswirkungen auf die Verfügbarkeit der Anwendungen.

Maximaler Schutz mit schnellerer Wiederherstellung – ohne Datenverlust 

Um Daten über mehrere Standorte hinweg zu schützen, wird RING als vollständig synchroner gestreckter Cluster konfiguriert – damit wird der Anwendung ein Schreibvorgang erst dann bestätigt, wenn die Daten vollständig auf persistenten Medien gespeichert sind.

Diese Datenverteilung über mehrere Standorte hilft Kunden in Verbindung mit den Datenschutzfunktionen von Scality, eine Datenbeständigkeit von 14 Neunen zu erreichen. Das ist einer der Gründe, warum die anspruchsvollsten und datenorientiertesten Organisationen der Welt Scality ihre geschäftskritischen Daten anvertrauen.

Einfacherer Betrieb im Fehlerfall mit synchronen gestreckten Architekturen

Eine weitere Möglichkeit, Daten über mehrere Standorte zu schützen, ist die asynchrone Replikation. Dabei replizieren zwei unabhängige RINGs alle (oder einen Teil der) Daten gegenseitig. Sie wird eingesetzt, wenn die Entfernung zwischen den Standorten größer oder das Netzwerk langsamer ist, als ein gestrecktes RING es verkraftet. 

Dieser Ansatz hat zwar den Vorteil, größere Entfernungen zwischen Rechenzentren zu ermöglichen, doch Organisationen bevorzugen in der Regel den synchronen Datenschutz eines gestreckten RING, da er den Betrieb im Fehlerfall vereinfacht. Neben einer potenziell längeren und komplizierteren RTO bringt eine asynchrone Replikation immer ein RPO mit sich – die jüngsten Daten sind also am zweiten Standort nicht geschützt. Das passt möglicherweise nicht zu den Datenschutzanforderungen mancher Organisationen oder Anwendungen. Je nach Faktoren wie der Änderungsrate der Daten in der Anwendung und der Bandbreite oder Latenz des Netzwerks zwischen den Standorten kann das RPO untragbar groß werden.

Async & Sync

Asynchrone Replikation zwischen RINGs

  1. Daten werden in RING geschrieben und über alle Server geschützt
  2. Die Anwendung erhält die Bestätigung, sobald die Daten auf allen Servern auf persistenten Medien gespeichert sind
  3. Die Daten werden asynchron in das Ziel-RING repliziert

Synchroner Betrieb in einem gestreckten RING

  1. Daten werden in RING geschrieben und über alle Standorte geschützt
  2. Die Anwendung erhält die Bestätigung, sobald die Daten auf allen Servern an allen Standorten auf persistenten Medien gespeichert sind

Asynchrone Replikation vs. synchroner Betrieb

Unterm Strich kann eine synchrone gestreckte Architektur mit klaren RPO- und RTO-Zielen die geschäftlichen Auswirkungen deutlich verbessern. Die Fachbereiche können diese Ziele gemeinsam mit der IT festlegen, da sie in der Regel eng mit den Service Level Agreements (SLAs) zwischen der Anwendung und ihren internen oder externen Nutzern verknüpft sind.

Weitere Vorteile eines gestreckten RING: mehr Schutz und mehr Effizienz

Ein gestrecktes RING kann über RPO und RTO hinaus weitere Vorteile haben. Viele Kunden nutzen Scality beispielsweise als Backup-Ziel. Werden Daten an ein gestrecktes RING gesendet,  ist das Backup praktisch sofort vor dem Verlust eines Standorts geschützt – unter Umständen muss es also nicht zusätzlich an einen anderen Ort kopiert werden.

Ein weiterer Vorteil eines gestreckten RING ist die effiziente Speicherung und der effiziente Schutz von Daten, was im großen Maßstab entscheidend ist. Einige unserer Kunden verfügen über Videoaufzeichnungen im Umfang von mehreren Dutzend Petabyte, die sich nicht reproduzieren lassen. Diese wertvollen Daten müssen geschützt werden, doch die dafür nötige Hardware kann unerschwinglich teuer sein. Scality RING minimiert diese Kosten.

Kosteneinsparungen: gestreckt über drei Standorte vs. repliziert über zwei Standorte spart erheblich Hardware-Overhead

Um große Datenmengen in einem über drei Standorte gestreckten RING zu schützen, fällt typischerweise ein Overhead von etwa 75 % an. Würden diese Daten dagegen zwischen zwei RINGs repliziert, entstünde ein Overhead von 100 % für die zusätzliche Datenkopie plus weitere 33 % pro Standort für den lokalen Schutz. 

Mit Overhead meinen wir hier die Menge an zusätzlicher Speicherhardware, die bereitgestellt werden muss, um den Schutz der Daten bei einem Doppelausfall einschließlich eines Standortverlusts zu garantieren.

Profi-Tipp: Bestehende Netzwerkprobleme vor der Bereitstellung eines gestreckten RING erkennen und beheben

Bei etwa einem Drittel der Implementierungen gestreckter Architekturen stellen wir Netzwerkprobleme fest, die vor der Einführung von RING behoben werden müssen. Diese Probleme – von kleineren Fehlkonfigurationen bis hin zu veralteter Hardware – bestehen bereits im Netzwerk des Kunden und werden zu Beginn der RING-Implementierung aufgedeckt. 

Um Verzögerungen zu vermeiden und sofort den vollen Nutzen aus RING zu ziehen, ist es wichtig, Ihr Netzwerk vorzubereiten. Für eine optimale Bereitstellung empfehlen wir in der Regel eine Bandbreite von mindestens 10 Gbit/s und eine Latenz von <5 ms im Weitverkehrsnetz – je nach Workload und Performance-Erwartungen des Kunden kann das variieren.

Wie oben erwähnt, können Probleme in vielen Bereichen des Netzwerks auftreten. Hier die häufigsten Probleme, auf die Sie achten und die Sie beheben sollten:

  • Paketverluste beheben: Ein Paketverlust liegt vor, wenn ein Netzwerkpaket sein Ziel nicht erreicht – meist, um das Netzwerk vor Überlastung zu schützen oder die Effizienz zu maximieren – und kann verschiedene Ursachen haben. Traffic Shaping, etwa durch Raten- oder Verbindungsbegrenzungen, kann den RING-Datenverkehr unbeabsichtigt stören. Werden Pakete verworfen, wiederholt der Sender die Übertragung nach einer Timeout-Periode – das kann die Latenz erhöhen, und das erneut gesendete Paket verbraucht zusätzliche Bandbreite, wodurch weniger Bandbreite für andere Anwendungen oder Netzwerkverkehr bleibt.
  • Routing optimieren: Der Weg, den die Pakete durch das Netzwerk nehmen, ist für einen verteilten Speicher-Cluster wie RING wichtig. Wie bei jedem Netzwerkverkehr muss sichergestellt sein, dass er die schnellste Route über die am besten geeigneten Verbindungen nimmt. Wir haben in Großbritannien einen Fall erlebt, in dem Pakete für ein 20 Kilometer entferntes Rechenzentrum über 300 Kilometer in den Norden Englands und 300 Kilometer zurück an die Südküste geschickt wurden. Die längere Strecke verursachte eine höhere Latenz, als die Anwendung verkraften konnte – mit extrem langsamen Antwortzeiten.  Die Lehre daraus: Gestalten Sie das Netzwerkdesign so, dass die Daten der schnellsten Route folgen können!
  • Überlastete Verbindungen vermeiden: Mit diesen Empfehlungen vermeiden Sie überlastete Verbindungen, die sich auf verschiedene Weise bemerkbar machen können:
    • Grundlegende Routing-Probleme beheben: Wie oben erwähnt, können Netzwerke, die Datenverkehr fälschlicherweise über Verbindungen mit zu wenig Bandbreite leiten, den Pfad schnell überlasten und die Performance von RING beeinträchtigen. Das lässt sich leicht beheben, indem man die zugrunde liegenden Routing-Probleme korrigiert. 
    • Spitzenzeiten auswerten und die richtige Bandbreite bestimmen: Physische Verbindungen werden oft mit anderen Anwendungen geteilt, was zu unerwartetem Verhalten bei RING führen kann. Manchmal wird die Spitzenauslastung bei der Bewertung der verfügbaren ISL-Kapazität nicht berücksichtigt, sodass Verbindungen zu bestimmten Tageszeiten oder bei bestimmten Prozessen überlastet sind. Eine richtig gestaltete Quality-of-Service-Richtlinie (QoS) kann helfen, solche Situationen zu entschärfen, oder mehr dauerhaft bereitgestellte Bandbreite löst das Problem. Im Rahmen einer RING-Implementierung wird manchmal zusätzliche Bandbreite benötigt und von den Fachbereichen zugesagt. Wir haben jedoch Verzögerungen bei der Umsetzung erlebt, die wiederum die vollständige Einführung von RING verzögern können. 
    • Jedes Glied der Kette berücksichtigen: Wir haben sogar erlebt, dass Endnutzer bei Kunden langsame Antwortzeiten hatten, weil die Verbindungen zum Desktop nur 1 Gbit/s betrugen – die erwartete Performance wurde erst nach einem Upgrade erreicht.
  • Regeln von Intrusion-Detection-Systemen (IDS) prüfen: Ein gestrecktes RING ist ein verteilter Speichercluster und nutzt daher viele Verbindungen. Jedes Objekt oder jede Datei, die eine Anwendung liest oder schreibt, besteht im Backend aus mindestens 12 Datenblöcken. Die Zahl der erforderlichen Verbindungen zwischen allen RING-Ressourcen kann also erheblich sein. Die 12 Blöcke sind unverzichtbar, um eine Datenbeständigkeit von bis zu 14 Neunen zu erreichen – aus Sicht eines IDS können all diese Verbindungen jedoch wie ein Angriff auf das Netzwerk aussehen, woraufhin das IDS einen Teil des Datenverkehrs einschränkt. Die IDS-Regeln müssen daher so eingerichtet werden, dass die RING-Komponenten die benötigten Verbindungen nutzen können.
  • Auf schlecht sitzende Kabel achten: Ach ja, der Erzfeind jedes Netzwerkadministrators. Einige unserer Kunden mit hohen Performance-Anforderungen verfügen über sehr schnelle und grundsolide Netzwerke. Kürzlich begann jedoch bei einem Kunden die Performance auf einer seiner Verbindungen nachzulassen. In diesem Bereich des Netzwerks hatte sich nichts geändert, und alles lief lange Zeit gut – daher stand der Router (einschließlich Kabel und Port) zunächst nicht im Fokus der Untersuchung. Einige Fehler traten auf der Verbindung auf, doch der Fehler war sporadisch und wurde nicht sofort erkannt und eingegrenzt – ein typischer „Wackelkontakt“. Mit der Zeit, während sich das Kabel langsam aus dem Port löst, zeigt sich das Problem schließlich vollständig und lässt sich erkennen und leicht beheben.
  • Einen Load Balancer mit Health Checks verwenden: Für S3-Implementierungen von RING ist ein externer Load Balancer erforderlich. So lässt sich die volle Performance von RING ausschöpfen, indem der Datenverkehr auf mehrere Endpunkte verteilt und skalierbarer, paralleler Datenzugriff ermöglicht wird. Wir empfehlen stets einen Load Balancer mit Health-Check-Funktion. Warum? Fällt ein Endpunkt aus irgendeinem Grund aus, werden ohne Health Checks weiterhin Daten an diesen fehlerhaften Endpunkt gesendet. Die Anwendung wartet bis zum Ablauf des Timeouts auf eine Antwort, versucht es dann erneut und erreicht hoffentlich einen funktionierenden Endpunkt. Das wiederholt sich und beeinträchtigt die Performance der Frontend-Anwendung, bis der Endpunkt entfernt wird. Hardwarebasierte Load Balancer können zudem Durchsatzgrenzen haben, die bei der Planung berücksichtigt werden sollten.

Best Practices für die Einführung einer gestreckten Architektur

Das Presales-Team von Scality arbeitet in der Regel eng mit dem IT-Team Ihrer Organisation zusammen, um zu verstehen, was Sie von Scality RING benötigen. Auf Basis Ihrer Anwendungs- und Performance-Anforderungen gibt es Empfehlungen zu den Netzwerkanforderungen. In manchen Fällen deckt der Einsatz von RING lange verborgene Fehler im Netzwerk auf, von denen Sie nichts wussten, etwa Routing-Fehler oder veraltete Hardware (wie oben erwähnt).

Am besten beziehen Sie das Netzwerkteam frühzeitig ein. So versteht es genau, welche zusätzliche Last RING auf das Netzwerk bringt, vor allem in Bezug auf die Bandbreite. Zudem bleibt Zeit für eine mögliche Neugestaltung, Neukonfiguration oder Investitionen in neue Geräte oder Verbindungen. Wir stellen fest, dass die besten Implementierungsprojekte dann gelingen, wenn alle IT-Beteiligten – einschließlich des Netzwerkteams des Kunden – einbezogen sind und regelmäßig kommunizieren.

Weitere empfohlene Best Practices: 

  • Quality-of-Service-Richtlinien im Netzwerk umsetzen, die den RING-Datenverkehr priorisieren, oder dedizierte VLANs mit definierter Bandbreite nutzen, die den RING-Datenverkehr abgrenzen und ihm ein angemessenes Performance-Niveau bieten.
  • Software und Firmware auf Netzwerkgeräten aktualisieren– das sorgt für mehr Stabilität und bessere Performance. Prüfen Sie zudem, ob alles richtig konfiguriert ist.
  • Das Netzwerk regelmäßig überwachen und analysieren, um die zugrunde liegenden Ursachen von Latenz wie Paketverluste oder Überlastungen zu erkennen und zu beheben. In den Worten eines unserer Implementierungsingenieure: „Überwachen, überwachen, überwachen – überall hinschauen und jeden Port überwachen und grafisch darstellen.“
  • Eine Netzwerkanalyse durch einen Drittanbieter in Betracht ziehen, bevor der Umfang von RING festgelegt wird – so erhalten Sie eine unabhängige Sicht auf das Netzwerk, und etwaige Probleme lassen sich aufdecken und beheben. 

Die Behebung von Netzwerkproblemen kann Organisationen auch weitere Vorteile bringen, etwa mehr verfügbaren Netzwerkdurchsatz oder höhere Resilienz. Netzwerke zu verwalten ist komplex und zeitaufwendig – aber unverzichtbar.

Mit Scality RING die Weichen für den Erfolg stellen

Scality RING hilft Organisationen jeder Größe, beispiellose Skalierbarkeit und Sicherheit mit erstklassiger Performance zu wettbewerbsfähigen Kosten zu erreichen. Es ist die Speicherlösung für Ihre intelligente, flexible Cloud-Datenarchitektur. Den maximalen Nutzen aus der Bereitstellung ziehen Sie jedoch nur, wenn Sie sich die Zeit genommen haben, das richtige Fundament zu legen. Bei Scality setzen wir alles daran, dass unsere Kunden das Beste aus ihrer Investition herausholen, indem sie die Grundlagen für den Erfolg schaffen.