Tirez le meilleur parti de MinIO avec des configurations réseau optimales : voici comment

MinIO peut être déployé de manière distribuée qui utilise efficacement les ressources de calcul et de stockage de plusieurs machines physiques ou virtuelles. Il peut s'agir de MinIO exécuté dans un environnement de cloud privé ou public, comme avec Amazon Web Services, Google Cloud Platform, la plateforme Azure de Microsoft et bien d'autres. MinIO peut se déployer sur plusieurs types de topologies – en production, nous recommandons le déploiement Multi-Node Multi-Drive (MNMD). MinIO recommande la réplication de site pour fournir une prise en charge du basculement et de la récupération de niveau BC/DR pour votre déploiement sur site unique, que vous pouvez concevoir et optimiser pour votre cas d'utilisation.

Dans un article de blog précédent, nous avons déjà discuté de certaines des meilleures pratiques à utiliser lors de la sélection du matériel pour votre déploiement MinIO . Nous avons abordé divers aspects du matériel, notamment le choix de la meilleure région, les bonnes configurations de lecteur, de processeur et de mémoire, et même certaines des configurations réseau recommandées. Bien que nous ayons abordé un large éventail de bonnes pratiques en matière de conception de systèmes, nous pouvons toujours aller plus loin et nous aborderons aujourd'hui certains des points les plus subtils de la conception de MinIO pour obtenir les meilleures performances des disques et des réseaux.

Dans cet article de blog, nous approfondirons les configurations réseau avec lesquelles vous pouvez configurer MinIO selon les différentes stratégies de réplication et topologies de réseau qui peuvent être utilisées pour garantir que vos données sont stockées et accessibles efficacement sur plusieurs déploiements MinIO. Vous n'avez pas besoin d'effectuer de configuration complexe telle que la configuration de cartes réseau liées/doubles (ce qui ajoute une surcharge supplémentaire).

Stratégies de réseautage simples

MinIO est un backend de stockage compatible S3 pour les services cloud natifs. En général, nous considérons le trafic réseau soit entre les applications et le cluster, soit entre les nœuds du cluster. En raison du trafic entre les nœuds, il est primordial que la mise en réseau entre les nœuds soit aussi rapide que possible. Chaque pool se compose d'un groupe indépendant de nœuds avec leurs propres ensembles d'effacement. MinIO doit interroger chaque pool pour déterminer l'ensemble d'effacement correct vers lequel il dirige les opérations de lecture et d'écriture, de sorte que chaque pool supplémentaire ajoute un trafic inter-nœuds minimal mais accru par appel. Le pool qui contient le bon jeu d'effacement répond alors à l'opération, restant entièrement transparent pour l'application.

Il est révolu le temps où l’entreprise pouvait se contenter de cartes réseau 1 GbE ou 10 GbE. La charge de travail des entreprises modernes utilise idéalement des cartes réseau 100 GbE. Compte tenu des limites physiques et de la surcharge du protocole TCP, ces cartes réseau devraient fournir 80 à 90 % de la bande passante disponible, généralement autour de 10 Go/s pour les cartes réseau à 100 Gbit/s, jusqu'à 12 Go/s sur des réseaux très bien provisionnés. MinIO n'a besoin d'aucune configuration réseau supplémentaire prête à l'emploi pour profiter de toute la bande passante car il écoute sur toutes les interfaces. MinIO prêt à l'emploi prend en charge l'écoute sur plusieurs interfaces réseau (NIC).

Vous n'avez besoin d'aucune autre configuration spéciale pour la mise en réseau MinIO, mais en utilisant éventuellement certaines des bases de mise en réseau dont nous avons parlé précédemment, vous pouvez acheminer le trafic MinIO via une interface spécifique.

Dans cet exemple, nous utiliserons un système d'exploitation Linux pour faire la démonstration, mais les bases de la mise en réseau sont les mêmes quel que soit le système d'exploitation que vous utilisez. L'implémentation peut légèrement varier en fonction de la configuration du réseau mais cela devrait vous donner une idée.

Nous allons d'abord commencer par lister la table de routage

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

Si vous avez configuré vos serveurs MinIO pour qu'ils se trouvent dans la plage CIDR 10.56.98.16/28, disons que l'une des adresses IP du nœud MinIO est 10.56.98.21 et sera acheminée via l'interface eth0 car /28 correspond à l'entrée de la table de routage pour 10.56. .98.0/24.

Mais si vous souhaitez acheminer le trafic MinIO via eth1 plutôt que eth0, nous devons ajouter une route spécifique pour le CIDR MinIO afin que tout trafic correspondant à ce sous-réseau soit acheminé via cette interface réseau spécifique.

 $ ip route add 10.56.98.16/28 dev eth1

Une fois la route ajoutée, listons à nouveau la table de routage pour voir à quoi elle ressemble

 $ 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

Nous voyons maintenant un itinéraire pour le /28 CIDR. Si vous cinglez le nœud MinIO 10.56.98.21, il sera désormais acheminé via l'interface eth1. En effet, lorsqu'il y a deux routes où /24 chevauche /28, généralement la route avec le préfixe le plus long est privilégiée (dans ce cas /28) et aura priorité sur toute autre route de préfixe plus courte lors de l'acheminement du trafic. C'est ce qu'on appelle la règle de préfixe de correspondance la plus longue.

Vous pouvez vérifier que le trafic de 10.56.98.16/28 est acheminé de manière appropriée si vous cinglez 10.56.98.21, puis vérifiez le tcpdump comme ci-dessous. Vous remarquerez que le trafic de la source 10.56.98.18 est acheminé via eth1 vers 10.56.98.21.

 $ 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

Comme vous pouvez le voir avec MinIO, aucun port ou service spécial supplémentaire n'est nécessaire pour réaliser la séparation du trafic. MinIO est conçu dans un souci de simplicité et nous réfléchissons toujours à la construction ou à l'achat dans ce cas plutôt que d'architecturer quelque chose de complexe comme un service de passerelle. MinIO exploite les bases de mise en réseau déjà disponibles au niveau de la couche du système d'exploitation pour obtenir le même résultat avec aussi peu de frais généraux que possible.

Nous pouvons pousser cette idée un peu plus loin. De nos jours, les serveurs disposent d'au moins 2 interfaces avec la possibilité d'en ajouter d'autres. Ainsi, plutôt que de faire passer le trafic des applications via les mêmes interfaces que MinIO, vous pouvez également faire fonctionner votre application sur un bloc CIDR distinct (choisissez un bloc adapté à la taille de votre application). Cette séparation garantit que le trafic MinIO pour la réplication et le rééquilibrage n'affecte pas les performances de l'application et vice versa. Il vous donne également la possibilité de surveiller et de suivre le trafic pour garantir que MinIO dispose toujours de la capacité et de la bande passante dont il a besoin pour effectuer ses opérations sans affecter ses performances.

Mais que se passe-t-il si vous disposez de MinIO sur différents sites ou régions ? Comment pouvez-vous le configurer efficacement pour garantir qu’il n’y a pas de goulots d’étranglement en termes de performances ? Eh bien, MinIO propose plusieurs types de configurations de réplication pour certains des cas d'utilisation les plus stricts.

L’une des stratégies de réplication les plus prolifiques est la réplication de site à site. Cela vous permet de démarrer MinIO avec un seul cluster et de l'étendre au nombre N à mesure que le besoin augmente. Supposons que vous disposez d’une application ETL/ELT qui s’exécute sur 3 sites différents. Généralement, les données ne sont disponibles que dans une des régions et les autres régions doivent extraire d'énormes volumes de données entre les régions afin de faire fonctionner leur processus. Inutile de dire que cela est non seulement très inefficace, mais cela exerce également une pression énorme sur l'infrastructure réseau et provoque potentiellement des goulots d'étranglement pour les autres applications partageant le WAN.

Dans une configuration de réplication de site à site, vous écrivez les données uniquement sur le cluster MinIO du premier site. Le processus de réplication copiera automatiquement les données sur les autres sites. Aucune modification supplémentaire n’est nécessaire à apporter à l’application ETL/ELT. Il vous suffit de pointer les tâches de chaque site vers leur cluster MinIO respectif soutenu par un proxy inverse tel que Nginx et les lectures seront beaucoup plus rapides qu'elles ne le seraient sur le WAN dans toutes les régions, comme indiqué ci-dessous.

Mais cela soulève la question : est-il possible d’affiner davantage le trafic ? Disons que vous ajoutez le fichier de données au site 1, il le répliquera immédiatement sur d'autres sites, quelle que soit l'heure de la journée. Cela peut se produire pendant la période de pointe, lorsque d'autres tâches ETL/ELT sont en cours d'exécution et que simultanément les ressources du réseau sont utilisées pour répliquer des données qui pourraient ne pas être utilisées avant le lendemain, lorsque le prochain lot est censé s'exécuter. Que peut-on faire dans ce cas ? C'est là que la réplication par lots de MinIO s'avère utile. La réplication par lots vous permet de choisir le type de données que vous souhaitez répliquer à un moment précis, elle est entièrement configurable. Dans ce cas, une tâche de réplication par lots peut être configurée pour s'exécuter en dehors des heures d'ouverture, lorsque le trafic est le plus faible. Étant donné que les temps d'accès aux applications peuvent varier tout au long de la journée, de la semaine et même du mois, c'est là que la surveillance du trafic réseau MinIO s'avère utile afin que vous puissiez configurer votre travail par lots pour qu'il s'exécute exactement au bon moment. Vous pouvez déployer des sites homologues dans différents racks, centres de données ou régions géographiques pour prendre en charge des fonctions telles que BC/DR ou des performances de lecture/écriture géolocalisées dans un magasin d'objets MinIO distribué à l'échelle mondiale.

Dernières pensées

Pour récapituler, l'architecture réseau de MinIO est l'une des plus simples et des plus directes du marché. Plutôt que de réinventer la roue, MinIO utilise les bases du réseau pour atteindre la parité avec certains des autres magasins de données avec une configuration complexe de réseau et de passerelle qui est presque impossible à déboguer. Peu importe le nombre de fois que vous déboguez le même problème, vous aurez l'impression que c'est la première fois que vous le rencontrez en raison de la nature obscurcie de l'architecture. MinIO se concentre plutôt sur des abstractions de niveau supérieur qui évitent au développeur d'applications de devoir maintenir la réplication des données et se concentrent plutôt sur le stockage et le traitement des données.

Comme d'habitude, si vous avez des questions sur la configuration du réseau MinIO ou sur la façon de le configurer, assurez-vous de nous contacter sur Slack ou mieux encore, inscrivez-vous à l'abonnement SUBNET !