Machen Sie das Beste aus MinIO mit optimalen Netzwerkkonfigurationen – so geht's

MinIO kann auf verteilte Weise bereitgestellt werden, wodurch die Ressourcen der Rechen- und Speicherressourcen mehrerer physischer oder virtueller Maschinen effizient genutzt werden. Dabei kann es sich um MinIO handeln, das in einer privaten oder öffentlichen Cloud-Umgebung ausgeführt wird, beispielsweise mit Amazon Web Services, der Google Cloud Platform, der Azure-Plattform von Microsoft und vielen anderen. MinIO kann in verschiedenen Topologietypen bereitgestellt werden – in der Produktion empfehlen wir die Multi-Node Multi-Drive (MNMD)-Bereitstellung. MinIO empfiehlt die Standortreplikation , um Failover- und Wiederherstellungsunterstützung auf BC/DR-Niveau für Ihre Bereitstellung an einem einzelnen Standort bereitzustellen, die Sie für Ihren Anwendungsfall entwerfen und optimieren können.

In einem früheren Blogbeitrag haben wir bereits einige der Best Practices besprochen, die Sie bei der Auswahl der Hardware für Ihre MinIO-Bereitstellung verwenden sollten. Wir haben verschiedene Aspekte der Hardware angesprochen, von der Auswahl der besten Region über die richtigen Laufwerks-, CPU- und Speicherkonfigurationen bis hin zu einigen der empfohlenen Netzwerkkonfigurationen. Während wir auf eine Reihe verschiedener Best Practices für das Systemdesign eingegangen sind, können wir jederzeit tiefer gehen. Heute werden wir uns mit einigen Feinheiten bei der Entwicklung von MinIO befassen, um die beste Leistung aus Laufwerken und Netzwerken herauszuholen.

In diesem Blogbeitrag gehen wir eingehend auf die Netzwerkkonfigurationen ein, mit denen Sie MinIO für die verschiedenen Replikationsstrategien und Netzwerktopologien konfigurieren können, die verwendet werden können, um sicherzustellen, dass Ihre Daten über mehrere MinIO-Bereitstellungen hinweg effizient gespeichert und abgerufen werden. Sie müssen keine komplexe Konfiguration vornehmen, wie z. B. die Einrichtung von Bonded/Dual-NICs (was zusätzlichen Overhead verursacht).

Einfache Netzwerkstrategien

MinIO ist ein S3-kompatibles Speicher-Backend für Cloud-native Dienste. Im Allgemeinen stellen wir uns Netzwerkverkehr entweder als zwischen Apps und dem Cluster oder zwischen Knoten im Cluster vor. Aufgrund des knotenübergreifenden Verkehrs ist es von größter Bedeutung, dass die Vernetzung zwischen den Knoten so schnell wie möglich erfolgt. Jeder Pool besteht aus einer unabhängigen Gruppe von Knoten mit eigenen Löschsätzen. MinIO muss jeden Pool abfragen, um den richtigen Löschsatz zu ermitteln, an den es Lese- und Schreibvorgänge weiterleitet, sodass jeder zusätzliche Pool minimalen, aber erhöhten knotenübergreifenden Datenverkehr pro Aufruf hinzufügt. Der Pool, der den richtigen Löschsatz enthält, reagiert dann auf den Vorgang und bleibt für die Anwendung völlig transparent.

Vorbei sind die Zeiten, in denen Unternehmen mit 1-GbE- oder 10-GbE-NICs auskommen konnten. Der moderne Unternehmens-Workload nutzt idealerweise 100-GbE-NICs. Angesichts der physikalischen Einschränkungen und des Overheads des TCP-Protokolls ist zu erwarten, dass diese Netzwerkkarten 80–90 % der verfügbaren Bandbreite liefern, im Allgemeinen etwa 10 GB/s für 100-Gbit/s-Netzwerkkarten, bis zu 12 GB/s in wirklich gut ausgestatteten Netzwerken. MinIO benötigt keine zusätzliche Netzwerkkonfiguration, um die gesamte Bandbreite zu nutzen, da es alle Schnittstellen überwacht. MinIO unterstützt standardmäßig das Abhören mehrerer Netzwerkschnittstellen (NICs).

Sie benötigen keine weitere spezielle Konfiguration für das MinIO-Netzwerk, können aber optional mithilfe einiger der zuvor besprochenen Netzwerkgrundlagen den MinIO-Verkehr über eine bestimmte Schnittstelle leiten.

In diesem Beispiel verwenden wir zur Demonstration ein Linux-Betriebssystem, aber die Netzwerkgrundlagen sind unabhängig davon, welches Betriebssystem Sie verwenden, die gleichen. Die Implementierung kann je nach Netzwerkkonfiguration leicht variieren, dies sollte Ihnen jedoch einen Eindruck vermitteln.

Wir beginnen zunächst mit der Auflistung der Routentabelle

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.18

Wenn Sie Ihre MinIO-Server so konfiguriert haben, dass sie im CIDR-Bereich 10.56.98.16/28 liegen, nehmen wir an, dass eine der IP-Adressen des MinIO-Knotens 10.56.98.21 ist und über die eth0-Schnittstelle weitergeleitet wird, da /28 mit dem Routing-Tabelleneintrag für 10.56 übereinstimmt .98,0/24.

Wenn Sie den MinIO-Verkehr jedoch über eth1 statt über eth0 leiten möchten, müssen wir eine bestimmte Route für das MinIO CIDR hinzufügen, damit jeglicher Verkehr, der mit diesem Subnetz übereinstimmt, über diese bestimmte Netzwerkschnittstelle weitergeleitet wird

 $ ip route add 10.56.98.16/28 dev eth1

Sobald die Route hinzugefügt wurde, listen wir die Routing-Tabelle erneut auf, um zu sehen, wie sie aussieht

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18 10.56.98.16/28 dev eth1 scope link

Jetzt sehen wir eine Route für das /28 CIDR. Wenn Sie den MinIO-Knoten 10.56.98.21 anpingen, wird dieser nun über die eth1-Schnittstelle weitergeleitet. Dies liegt daran, dass bei zwei Routen, bei denen sich /24 mit /28 überschneidet, im Allgemeinen die Route mit dem längsten Präfix bevorzugt wird (in diesem Fall /28) und bei der Weiterleitung des Datenverkehrs Vorrang vor allen anderen Routen mit kürzerem Präfix hat. Dies wird als Präfixregel mit der längsten Übereinstimmung bezeichnet.

Sie können überprüfen, ob der Datenverkehr von 10.56.98.16/28 ordnungsgemäß weitergeleitet wird, indem Sie 10.56.98.21 anpingen und dann den TCP-Dump wie unten überprüfen. Sie werden feststellen, dass der Datenverkehr von der Quelle 10.56.98.18 über eth1 an 10.56.98.21 weitergeleitet wird.

 $ tcpdump -n -i eth1 icmp … 15:55:44.410450 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 123, length 64 15:55:44.410471 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 123, length 64 15:55:45.434489 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 124, length 64 15:55:45.434518 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 124, length 64 15:55:46.458490 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 125, length 64 15:55:46.458520 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 125, length 64

Wie Sie sehen, sind bei MinIO keine zusätzlichen speziellen Ports oder Dienste erforderlich, um eine Verkehrstrennung zu erreichen. MinIO ist auf Einfachheit ausgelegt und wir denken in diesem Fall immer über Build vs. Buy nach, anstatt etwas Komplexes wie einen Gateway-Dienst zu entwerfen. MinIO nutzt Netzwerkgrundlagen, die bereits auf der Betriebssystemebene verfügbar sind, um das gleiche Ergebnis mit so wenig Overhead zu erzielen wie möglich.

Wir können diese Idee noch einen Schritt weiterführen. Heutzutage verfügen Server über mindestens zwei Schnittstellen mit der Option, weitere hinzuzufügen. Anstatt also den Anwendungsverkehr über dieselben Schnittstellen wie MinIO laufen zu lassen, können Sie Ihre Anwendung auch auf einem separaten CIDR-Block ausführen lassen (wählen Sie einen Block, der für Ihre Anwendungsgröße geeignet ist). Durch diese Trennung wird sichergestellt, dass der MinIO-Verkehr für die Replikation und Neuverteilung die Leistung der Anwendung nicht beeinträchtigt und umgekehrt. Außerdem haben Sie die Möglichkeit, den Datenverkehr zu überwachen und zu verfolgen, um sicherzustellen, dass MinIO immer über die Kapazität und Bandbreite verfügt, die es für die Ausführung seiner Vorgänge benötigt, ohne seine Leistung zu beeinträchtigen.

Was aber, wenn Sie MinIO an verschiedenen Standorten oder in verschiedenen Regionen einsetzen? Wie können Sie es effektiv konfigurieren, um sicherzustellen, dass es keine Leistungsengpässe gibt? Nun, es gibt verschiedene Arten von Replikationskonfigurationen, die MinIO für einige der anspruchsvollsten Anwendungsfälle bietet.

Eine der produktivsten Replikationsstrategien ist die Site-to-Site-Replikation. Dadurch können Sie MinIO mit einem einzelnen Cluster starten und bei steigendem Bedarf auf N erweitern. Angenommen, Sie haben eine ETL/ELT-Anwendung, die auf drei verschiedenen Standorten ausgeführt wird. Im Allgemeinen sind die Daten nur in einer der Regionen verfügbar und die anderen Regionen müssen enorme Datenmengen über Regionen hinweg abrufen, um den Prozess auszuführen. Es versteht sich von selbst, dass dies nicht nur äußerst ineffizient ist, sondern auch einen enormen Druck auf die Netzwerkinfrastruktur ausübt und möglicherweise zu Engpässen bei anderen Anwendungen führt, die sich das WAN teilen.

Bei einer Site-to-Site-Replikationskonfiguration schreiben Sie die Daten nur in den MinIO-Cluster am ersten Standort. Durch den Replikationsprozess werden die Daten automatisch auf die anderen Sites kopiert. Es sind keine weiteren Änderungen an der ETL/ELT-Anwendung erforderlich. Sie verweisen die Jobs an jedem Standort einfach auf ihren jeweiligen MinIO-Cluster, der von einem Reverse-Proxy wie Nginx unterstützt wird, und die Lesevorgänge sind viel schneller als über regionales WAN, wie unten gezeigt.

Aber das wirft die Frage auf: Ist es möglich, den Verkehr noch weiter zu optimieren? Nehmen wir an, Sie fügen die Datendatei zu Standort 1 hinzu. Sie wird unabhängig von der Tageszeit sofort auf andere Standorte repliziert. Dies kann während der Spitzenzeit der Fall sein, wenn möglicherweise andere ETL/ELT-Jobs ausgeführt werden und gleichzeitig Netzwerkressourcen zur Replikation von Daten verwendet werden, die möglicherweise erst am nächsten Tag verwendet werden, wenn der nächste Stapel ausgeführt werden soll. Was kann man in diesem Fall tun? Hier bietet sich die Batch-Replikation von MinIO an. Bei der Batch-Replikation können Sie die Art der Daten auswählen, die Sie zu einem bestimmten Zeitpunkt replizieren möchten. Sie ist vollständig konfigurierbar. In diesem Fall kann ein Batch-Replikationsjob so eingestellt werden, dass er außerhalb der Geschäftszeiten ausgeführt wird, wenn der Datenverkehr am geringsten ist. Da die Anwendungszugriffszeiten im Laufe des Tages, der Woche und sogar des Monats variieren können, ist die Überwachung des MinIO-Netzwerkverkehrs praktisch, damit Sie Ihren Batch-Job so konfigurieren können, dass er genau zum richtigen Zeitpunkt ausgeführt wird. Sie können Peer-Standorte in verschiedenen Racks, Rechenzentren oder geografischen Regionen bereitstellen, um Funktionen wie BC/DR oder geo-lokale Lese-/Schreibleistung in einem global verteilten MinIO-Objektspeicher zu unterstützen.

Abschließende Gedanken

Um es noch einmal zusammenzufassen: Die Netzwerkarchitektur von MinIO ist eine der einfachsten und unkompliziertesten auf dem Markt. Anstatt das Rad neu zu erfinden, nutzt MinIO Netzwerkgrundlagen, um Parität mit einigen anderen Datenspeichern mit komplexen Netzwerk- und Gateway-Setups zu erreichen, die nahezu unmöglich zu debuggen sind. Unabhängig davon, wie oft Sie dasselbe Problem debuggen, wird es sich aufgrund der verschleierten Natur der Architektur so anfühlen, als wäre es das erste Mal, dass Sie darauf stoßen. Vielmehr konzentriert sich MinIO auf Abstraktionen auf höherer Ebene, die den Anwendungsentwickler von der Pflege der Datenreplikation entlasten und sich stattdessen auf die Speicherung und Verarbeitung der Daten konzentrieren.

Wenn Sie Fragen zur MinIO-Netzwerkkonfiguration oder deren Einrichtung haben, wenden Sie sich wie gewohnt über Slack an uns oder melden Sie sich noch besser für das SUBNET- Abonnement an!