Stockage cloud de niveau entreprise avec NGINX Plus et Minio

Nitish Tawari

Cet article de blog invité a été rédigé par Nitish Tiwari, développeur de logiciels chez Minio, un serveur de stockage d’objets distribué spécialisé dans les applications cloud et l’approche DevOps du développement et du déploiement d’applications. Nitish s’intéresse notamment aux infrastructures logicielles, en particulier au stockage et aux systèmes distribués.

Dans cet article, Nitish explique comment utiliser NGINX et NGINX Plus comme proxy inverse et répartiteur de charge pour les serveurs Minio. Cet article s’applique aussi bien à NGINX qu’à NGINX Plus ; par souci de concision, seul NGINX Plus y est mentionné.

Conception d’un stockage objet

Presque toutes les applications ont besoin d’un espace de stockage, mais chacune a des besoins et des usages spécifiques en la matière. Prenons l’exemple d’un système de stockage de documents : lorsqu’il est de petite taille, il n’a pas forcément à traiter de fréquentes requêtes de lecture, mais il doit pouvoir évoluer au fil du temps. Une autre application, comme une galerie d’images, doit à la fois répondre rapidement aux requêtes et évoluer dans le temps.

Ces subtilités compliquent la configuration du stockage. Toutefois, tout n’est pas si sombre : avec l’avènement du stockage objet comme méthode par défaut pour stocker les données non structurées, HTTP est devenu le mode de communication par défaut, normalisant ainsi la façon dont les applications communiquent avec le stockage.

La question demeure toutefois : comment concevoir une infrastructure de stockage objet adaptée aux besoins de votre application, tout en restant flexible ?

Étant donné que le stockage objet fait intervenir des serveurs et des clients HTTP, il est judicieux de placer en frontal un serveur web polyvalent tel que NGINX Plus pour gérer le trafic HTTP. Un serveur de stockage objet léger tel que Minio peut être utilisé pour fournir un stockage évolutif en backend. La flexibilité d’un tel système est essentielle pour créer un service de niveau entreprise.

Avec NGINX Plus, les administrateurs peuvent non seulement équilibrer la charge du trafic entrant, mais aussi le mettre en cache, limiter son débit, assurer la terminaison SSL/TLS et même le filtrer selon différents paramètres. Minio, quant à lui, propose un serveur de stockage d’objets léger et compatible avec Amazon S3.

MinIO est conçu pour le stockage dédié à l’IA et convient particulièrement au stockage de données non structurées telles que des photos, des vidéos, des fichiers journaux, des sauvegardes ainsi que des images de machines virtuelles et de conteneurs. Le serveur Minio est suffisamment léger pour être intégré à la pile applicative, à l’instar de Node.js, Redis et MySQL. Minio prend également en charge un mode distribué, qui permet de regrouper plusieurs disques – même situés sur des machines différentes – au sein d’un seul serveur de stockage d’objets.

Dans cet article, nous explorerons certaines des fonctionnalités de NGINX Plus dans différents cas d’usage et verrons comment les associer à Minio pour mettre en place un système de stockage d’objets adapté à la production, hautement évolutif, hautement disponible et stable.

NGINX Plus en tant que proxy inverse et équilibreur de charge

NGINX Plus est bien connu en tant que serveur proxy inverse. Mais pourquoi a-t-on besoin d’un proxy inverse pour Minio ? Examinons quelques cas d’utilisation :

• Avec un proxy inverse NGINX Plus placé devant un ou plusieurs serveurs Minio, vous pouvez déplacer au fil du temps les instances de serveur Minio vers d’autres machines ou emplacements, sans avoir à mettre à jour les clients ni les applications.
• NGINX Plus peut équilibrer la charge du trafic entrant et le répartir uniformément entre les différentes instances distribuées de serveurs Minio.
• Un proxy NGINX Plus peut faire partie d’une configuration de stockage d’objets à haute disponibilité avec Minio, à l’aide de la commande mc mirror de Minio Client.

NGINX Plus agit comme proxy inverse pour le trafic client en transmettant les requêtes à un serveur backend, qui écoute à l’URL spécifiée par la directive proxy_pass. Dans l’extrait de configuration suivant, une instance Minio autonome s’exécute sur localhost, et est donc accessible à l’adresse http://localhost:9000. Toutes les requêtes arrivant sur le port 80 et visant le répertoire racine (/) de www.example.com sont transmises à Minio. NGINX Plus définit explicitement l’en-tête Host sur la valeur qu’il avait dans la requête d’origine.

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

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

Si vous disposez de plusieurs serveurs Minio, répartissez la charge du trafic entre eux en les répertoriant dans un bloc de configuration upstream et en référençant le groupe upstream dans la directive proxy_pass :

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;
    }
}

Pour plus d’informations sur la configuration de NGINX ou NGINX Plus en tant que proxy pour Minio, consultez la documentation de Minio.

Terminaison SSL/TLS

HTTPS devenant désormais le protocole par défaut pour une grande partie du trafic web, il est judicieux de déployer un serveur HTTPS, plutôt qu’un simple serveur HTTP, pour Minio. Il est assez facile de configurer NGINX Plus en tant que serveur HTTPS. Pour commencer, vous avez besoin d’un certificat SSL/TLS ; Let’s Encrypt fournit gratuitement des certificats SSL/TLS et s’intègre à NGINX Plus.

L’étape suivante consiste à modifier le fichier de configuration de NGINX Plus. Vous devez ici spécifier le paramètre « ssl » dans la directive « listen » du bloc « server », puis indiquer les fichiers contenant le certificat du serveur et la clé privée :

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;
    }
}

Pour plus d’informations sur la terminaison SSL/TLS, consultez le Guide d’administration de NGINX Plus.

Mise en cache

Les serveurs de stockage d’objets ne sont pas réputés pour leur rapidité, mais cela ne signifie pas nécessairement que les réponses aux clients doivent être lentes. Lorsque vous activez la mise en cache sur le serveur NGINX Plus, celui-ci enregistre les données fréquemment consultées et peut les renvoyer immédiatement au client sans avoir à transmettre la requête au serveur backend.

Voici comment cela fonctionne. Le cache web de NGINX Plus se place entre un client et Minio et enregistre une copie de chaque fichier de contenu demandé. Lorsqu’un client demande un contenu stocké dans le cache, NGINX Plus le lui renvoie directement, sans contacter Minio. Cela permet à la fois d’améliorer le temps de réponse pour le client et de réduire la charge sur le serveur Minio.

Vous configurez le cache NGINX Plus pour Minio à l’aide des directives « proxy_cache_path » et « proxy_cache ». La directive « proxy_cache_path » définit l’emplacement et la configuration du cache, tandis que la directive « proxy_cache » l’active. Pour plus de détails, consultez le document « Guide de la mise en cache avec NGINX et 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;
    }
}

Limitation du débit

Il est parfois nécessaire de limiter les requêtes pour des raisons commerciales ou de sécurité. Avec NGINX Plus, vous pouvez limiter la bande passante disponible, le nombre de requêtes ou le nombre de connexions.

Pour limiter la bande passante, utilisez la directive « limit_rate ». Cet exemple limite la vitesse de téléchargement à 200 Ko par seconde :

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

Pour limiter le débit des requêtes, utilisez les directives « limit_req » et « limit_req_zone », comme dans cet exemple qui limite chaque adresse IP unique à 10 requêtes par seconde, tout en autorisant des pics de 20 requêtes.

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;
        # ...
    }
}

Pour limiter le nombre de connexions, utilisez les directives « limit_conn » et « limit_conn_zone ». Cet exemple limite chaque adresse IP unique à 5 connexions simultanées.

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

Pour plus de détails, consultez le Guide d’administration de NGINX Plus.

Résumé

Dans cet article, nous avons présenté l’utilisation de plusieurs fonctionnalités de NGINX Plus pour la répartition de charge, notamment devant un serveur de stockage d’objets Minio. L’association de NGINX Plus et de Minio vous permet de mettre en place un serveur de stockage d’objets flexible, adapté aux besoins de votre application.

Pour en savoir plus sur l’équilibrage de charge avec NGINX Plus, consultez ces articles de blog et autres ressources :

• Équilibrage de charge haute performance, une présentation générale de l’équilibrage de charge avec NGINX et NGINX Plus
• Guide d’administration de NGINX Plus
• 5 raisons de passer à une solution logicielle pour l’équilibrage de charge, un ebook qui présente les principales raisons d’abandonner les contrôleurs de mise à disposition d’applications (ADC) matériels

Pour essayer NGINX Plus, commencez dès aujourd’hui votre essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Nitish Tawari

Autres articles de Nitish Tawari