Cloud-Speicher der Enterprise-Klasse mit NGINX Plus und Minio

Nitish Tawari

Dies ist ein Gastbeitrag von Nitish Tiwari, einem Softwareentwickler bei Minio, einem auf Cloud-Anwendungen spezialisierten Server für verteilten Objektspeicher, sowie über den DevOps-Ansatz für die Entwicklung und Bereitstellung von Anwendungen. Nitish interessiert sich für softwarebasierte Infrastruktur, insbesondere für Speicher- und verteilte Systeme.

In diesem Beitrag erklärt Nitish, wie NGINX und NGINX Plus als Reverse-Proxy und Load-Balancer für Minio-Server eingesetzt werden. Der Beitrag gilt gleichermaßen für NGINX und NGINX Plus; der Kürze halber wird darin nur NGINX Plus erwähnt.

Objektspeicher konzipieren

Fast alle Anwendungen benötigen Speicher, doch verschiedene Apps haben unterschiedliche Speicheranforderungen und nutzen ihn auf jeweils eigene Weise. Ein Dokumentenspeicher beispielsweise muss bei geringem Datenbestand möglicherweise nicht viele Leseanfragen verarbeiten, sollte aber im Laufe der Zeit skalierbar sein. Eine andere Anwendung, etwa eine Bildergalerie, muss sowohl Anfragen schnell beantworten als auch mit der Zeit skalieren können.

Diese Feinheiten erschweren die Einrichtung des Speichers. Doch es gibt auch Grund zur Zuversicht: Seit sich Objektspeicher als Standard für die Speicherung unstrukturierter Daten etabliert haben, ist HTTP zum Standardkommunikationsprotokoll geworden und vereinheitlicht die Kommunikation zwischen Anwendungen und Speichersystemen.

Dennoch bleibt die Frage: Wie lässt sich eine Objektspeicherumgebung aufbauen, die auf die Anforderungen Ihrer Anwendung zugeschnitten und dennoch flexibel ist?

Da Objektspeicher HTTP-Server und -Clients umfasst, ist es sinnvoll, einen vielseitigen Webserver wie NGINX Plus vorzuschalten, der den HTTP-Datenverkehr verarbeitet. Ein schlanker Objektspeicherserver wie Minio kann im Backend skalierbaren Speicher bereitstellen. Die Flexibilität eines solchen Systems ist der Schlüssel zur Entwicklung eines Dienstes auf Enterprise-Niveau.

Mit NGINX Plus können Administratoren den eingehenden Datenverkehr nicht nur per Load Balancing verteilen, sondern ihn auch zwischenspeichern, drosseln, SSL/TLS terminieren und sogar anhand verschiedener Parameter filtern. Minio hingegen bietet einen schlanken Objektspeicherserver, der mit Amazon S3 kompatibel ist.

MinIO wurde für KI-Speicher entwickelt und eignet sich besonders für die Speicherung unstrukturierter Daten wie Fotos, Videos, Protokolldateien, Sicherungen sowie VM- und Container-Images. Der Minio-Server ist so schlank, dass er ähnlich wie Node.js, Redis und MySQL zusammen mit dem Anwendungs-Stack bereitgestellt werden kann. Minio unterstützt außerdem einen verteilten Modus, mit dem sich mehrere Laufwerke – selbst auf verschiedenen Rechnern – zu einem einzigen Objektspeicher-Server zusammenfassen lassen.

In diesem Beitrag untersuchen wir einige der Funktionen von NGINX Plus in verschiedenen Anwendungsfällen und erfahren, wie sie sich mit Minio kombinieren lassen, um ein produktionsreifes, hoch skalierbares, hochverfügbares und stabiles Objektspeichersystem einzurichten.

NGINX Plus als Reverse-Proxy und Load-Balancer

NGINX Plus ist als Reverse-Proxy-Server weithin bekannt. Doch wozu benötigt man einen Reverse-Proxy für Minio? Sehen wir uns einige der Anwendungsfälle an:

• Mit einem NGINX Plus-Reverse-Proxy vor einem oder mehreren Minio-Servern können Sie Minio-Serverinstanzen im Laufe der Zeit auf andere Rechner bzw. an andere Standorte verschieben, ohne Clients oder Anwendungen aktualisieren zu müssen.
• NGINX Plus kann den eingehenden Datenverkehr per Lastenausgleich gleichmäßig auf verteilte Minio-Serverinstanzen verteilen.
• Ein NGINX Plus-Proxy kann mithilfe des Minio-Clients (mc) und des Befehls „mirror“ Teil einer hochverfügbaren Objektspeicher-Konfiguration mit Minio sein.

NGINX Plus fungiert als Reverse-Proxy für den Client-Datenverkehr, indem Anfragen an einen Backend-Server weitergeleitet werden, der unter der durch die proxy_pass-Direktive angegebenen URL erreichbar ist. Im folgenden Konfigurationsausschnitt wird eine eigenständige Minio-Instanz auf localhost ausgeführt und ist daher unter http://localhost:9000 erreichbar. Alle Anfragen, die über Port 80 an das oberste Verzeichnis (/) unter www.example.com eingehen, werden an Minio weitergeleitet. NGINX Plus setzt den Host-Header explizit auf den Wert aus der ursprünglichen Anfrage.

server {    listen 80;
    server_name www.example.com;

    location / {
        proxy_set_header Host $http_host;
        proxy_pass       http://localhost:9000;
    }
}

Wenn Sie mehrere Minio-Server betreiben, verteilen Sie den Datenverkehr auf diese, indem Sie sie in einem upstream-Konfigurationsblock aufführen und die Upstream-Gruppe in der proxy_pass-Direktive referenzieren:

upstream minio_servers { server minio-server-1:9000; server minio-server-2:9000; }

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_set_header Host $http_host;
        proxy_pass       http://minio_servers;
    }
}

Weitere Informationen zur Einrichtung von NGINX oder NGINX Plus als Proxy für Minio finden Sie in der Minio-Dokumentation.

SSL/TLS-Terminierung

Da HTTPS mittlerweile das Standardprotokoll für einen Großteil des Web-Datenverkehrs ist, empfiehlt es sich, für Minio einen HTTPS-Server statt lediglich eines HTTP-Servers bereitzustellen. NGINX Plus lässt sich relativ einfach als HTTPS-Server einrichten. Zunächst benötigen Sie ein SSL/TLS-Zertifikat; Let’s Encrypt stellt kostenlose SSL/TLS-Zertifikate bereit und lässt sich in NGINX Plus integrieren.

Im nächsten Schritt bearbeiten Sie die NGINX Plus-Konfigurationsdatei. Geben Sie dazu den Parameter ssl für die Direktive listen im Block server an und geben Sie anschließend die Dateien an, die das Serverzertifikat und den privaten Schlüssel enthalten:

server {    listen 80;
    server_name www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name         www.example.com;

    ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        proxy_set_header Host $http_host;
        proxy_pass       http://localhost:9000;
    }
}

Weitere Informationen zur SSL/TLS-Terminierung finden Sie im NGINX Plus-Administratorhandbuch.

Caching

Objektspeicherserver sind nicht gerade für ihre Geschwindigkeit bekannt, doch das muss nicht zwangsläufig langsame Antworten an Clients bedeuten. Wenn Sie das Caching auf dem NGINX Plus-Server aktivieren, speichert dieser häufig abgerufene Daten zwischen und kann sie sofort an den Client zurückgeben, ohne die Anfrage an den Backend-Server weiterleiten zu müssen.

Und so funktioniert es: Der Webcache von NGINX Plus befindet sich zwischen einem Client und Minio und speichert eine Kopie jeder angeforderten Inhaltsdatei. Fordert ein Client Inhalte an, die im Cache gespeichert sind, liefert NGINX Plus diese direkt aus, ohne Minio zu kontaktieren. Dadurch wird sowohl die Antwortzeit für den Client verbessert als auch die Last auf dem Minio-Server reduziert.

Sie richten den NGINX Plus-Cache für Minio mit den Direktiven „proxy_cache_path“ und „proxy_cache“ ein. Die Direktive „proxy_cache_path“ legt den Speicherort und die Konfiguration des Caches fest, und die Direktive „proxy_cache“ aktiviert ihn. Weitere Informationen finden Sie unter „Leitfaden zum Caching mit NGINX und NGINX Plus“.

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_set_header Host $http_host;
        proxy_pass       http://localhost:9000;
    }
}

Drosselung

Manchmal müssen Sie Anfragen aus geschäftlichen oder sicherheitsrelevanten Gründen drosseln. Mit NGINX Plus können Sie die verfügbare Bandbreite, die Anzahl der Anfragen oder die Anzahl der Verbindungen begrenzen.

Um die Bandbreite zu begrenzen, verwenden Sie die Direktive „limit_rate“. Dieses Beispiel begrenzt die Downloadgeschwindigkeit auf 200 KB pro Sekunde:

server {    # ...
    location /images/ {
        limit_rate 200k;
        # ...
    }
}

Verwenden Sie zur Anfragedrosselung die Direktiven „limit_req“ und „limit_req_zone“, wie im folgenden Beispiel, das jede eindeutige IP-Adresse auf 10 Anfragen pro Sekunde begrenzt und dabei kurzzeitige Spitzen von 20 Anfragen zulässt.

limit_req_zone $binary_remote_addr zone=my_req_limit:10m rate=10r/s;
server {
    # ...
    location /images/ {
        limit_req zone=my_req_limit burst=20;
        # ...
    }
}

Um die Anzahl der Verbindungen zu begrenzen, verwenden Sie die Direktiven „limit_conn“ und „limit_conn_zone“. In diesem Beispiel wird jede eindeutige IP-Adresse auf 5 gleichzeitige Verbindungen beschränkt.

limit_conn_zone $binary_remote_addr zone=my_conn_limit:10m;
server {
    # ...
    location /images/ {
        limit_conn my_conn_limit 5;
        # ...
    }
}

Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch.

Zusammenfassung

In diesem Beitrag haben wir den Einsatz verschiedener Funktionen von NGINX Plus für den Lastenausgleich demonstriert – insbesondere für den Lastenausgleich vor einem Minio-Objektspeicherserver. Die Kombination aus NGINX Plus und Minio ermöglicht es Ihnen, einen flexiblen Objektspeicherserver einzurichten, der auf die Anforderungen Ihrer Anwendung zugeschnitten ist.

Weitere Informationen zum Load Balancing mit NGINX Plus finden Sie in diesen Blogbeiträgen und anderen Ressourcen:

• Hochleistungs-Load-Balancing – ein allgemeiner Überblick über Load-Balancing mit NGINX und NGINX Plus
• NGINX Plus-Administratorhandbuch
• 5 Gründe für den Umstieg auf Software für den Lastenausgleich, ein E-Book, das die wichtigsten Gründe für den Abschied von hardwarebasierten ADCs erläutert

Wenn Sie NGINX Plus selbst ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Über den Autor

Nitish Tawari

Weitere Blogbeiträge von Nitish Tawari