Skip to main content
How to enable StorageGRID in your environment
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Conditions préalables à l'installation de StorageGRID

Contributeurs
PDF

Découvrez les besoins en ressources de calcul, de stockage, de réseau, docker et de nœuds pour déployer StorageGRID.

Exigences de calcul

Le tableau ci-dessous répertorie les ressources minimales requises pour chaque type de nœud StorageGRID. Il s'agit des ressources minimales requises pour les nœuds StorageGRID.

Type de nœud Cœurs de processeurs RAM

Admin

8

24 GO

Stockage

8

24 GO

Passerelle

8

24 GO

En outre, chaque hôte Docker physique doit disposer d'un minimum de 16 Go de RAM pour fonctionner correctement. Ainsi, par exemple, pour héberger deux des services décrits dans le tableau ensemble sur un hôte Docker physique, effectuez le calcul suivant :

24 + 24 + 16 = 64 Go de RAM et 8 + 8 = 16 cœurs

Comme nombre de serveurs modernes dépassent ces exigences, nous combinons six services (conteneurs StorageGRID) en trois serveurs physiques.

Configuration réseau requise

Les trois types de trafic StorageGRID sont les suivants :

  • Trafic de grille (requis). Trafic StorageGRID interne qui circule entre tous les nœuds de la grille.

  • Trafic Admin (facultatif). Trafic utilisé pour l'administration et la maintenance du système.

  • Trafic client (facultatif). Le trafic qui circule entre les applications client externes et la grille, y compris toutes les demandes de stockage objet des clients S3 et Swift.

Vous pouvez configurer jusqu'à trois réseaux à utiliser avec le système StorageGRID. Chaque type de réseau doit se trouver sur un sous-réseau distinct sans chevauchement. Si tous les nœuds se trouvent sur le même sous-réseau, aucune adresse de passerelle n'est requise.

Pour cette évaluation, nous allons déployer sur deux réseaux, qui contiennent la grille et le trafic client. Il est possible d'ajouter un réseau d'administration plus tard pour servir cette fonction supplémentaire.

Il est très important de mapper les réseaux de manière cohérente aux interfaces sur tous les hôtes. Par exemple, s'il existe deux interfaces sur chaque nœud, sen192 et en224, elles doivent toutes être mappées sur le même réseau ou VLAN sur tous les hôtes. Dans cette installation, le programme d'installation les mappe dans les conteneurs Docker comme eth0@if2 et eth2@if3 (car le bouclage est if1 à l'intérieur du conteneur). Il est donc très important d'avoir un modèle cohérent.

Remarque sur la mise en réseau Docker

StorageGRID utilise la mise en réseau différemment de certaines implémentations de conteneurs Docker. Il n'utilise pas la mise en réseau fournie par Docker (ou Kubernetes ou Swarm). StorageGRID génère alors le conteneur sous la forme --net=none, de sorte que Docker ne fait rien pour le mettre en réseau. Une fois le conteneur généré par le service StorageGRID, un nouveau périphérique macvlan est créé à partir de l'interface définie dans le fichier de configuration du nœud. Ce périphérique a une nouvelle adresse MAC et agit comme un périphérique réseau distinct qui peut recevoir des paquets de l'interface physique. Le périphérique macvlan est alors déplacé dans l'espace de noms du conteneur et renommé eth0, eth1 ou eth2 à l'intérieur du conteneur. À ce stade, le périphérique réseau n'est plus visible dans le système d'exploitation hôte. Dans notre exemple, le dispositif réseau Grid est eth0 à l'intérieur des conteneurs Docker et le réseau client est eth2. Si nous disposions d'un réseau d'administration, le dispositif serait eth1 dans le conteneur.

Remarque La nouvelle adresse MAC du périphérique réseau de conteneur peut nécessiter l'activation du mode promiscuous dans certains environnements réseau et virtuels. Ce mode permet au périphérique physique de recevoir et d'envoyer des paquets pour les adresses MAC qui diffèrent de l'adresse MAC physique connue. si vous exécutez VMware vSphere, vous devez accepter le mode promiscuité, les modifications d'adresse MAC et les transmissions forgées dans les groupes de ports qui serviront le trafic StorageGRID lors de l'exécution de RHEL. Ubuntu ou Debian fonctionne sans ces changements dans la plupart des circonstances.

Conditions de stockage

Les nœuds nécessitent chacun des périphériques de disque SAN ou locaux de la taille indiquée dans le tableau suivant.

Remarque Les chiffres indiqués dans le tableau correspondent à chaque type de service StorageGRID, et non à la grille entière ou à chaque hôte physique. En fonction des choix de déploiement, nous calculerons les nombres pour chaque hôte physique dans , plus loin dans "Configuration et configuration requise de l'hôte physique"ce document. les chemins ou systèmes de fichiers marqués d'un astérisque seront créés dans le conteneur StorageGRID lui-même par l'installateur. L'administrateur n'a pas besoin de créer manuellement une configuration ou un système de fichiers, mais les hôtes ont besoin de périphériques en mode bloc pour répondre à ces exigences. En d'autres termes, le périphérique de bloc doit apparaître à l'aide de la commande, mais il ne doit lsblk pas être formaté ou monté dans le système d'exploitation hôte.
Type de nœud Objectif de LUN Nombre de LUN Taille minimale de la LUN Système de fichiers manuel requis Entrée de configuration de nœud suggérée

Tout

Espace système du nœud d'administration
/var/local (SSD utile ici)

Un pour chaque nœud d'administration

90 GO

Non

BLOCK_DEVICE_VAR_LOCAL = /dev/mapper/ADM-VAR-LOCAL

Tous les nœuds

Pool de stockage Docker au
/var/lib/docker for container pool

Un pour chaque hôte (physique ou machine virtuelle)

100 Go par conteneur

Oui – etx4

Na : formatez et montez en tant que système de fichiers hôte (non mappé dans le conteneur)

Admin

Journaux d'audit de nœud d'administration (données système dans le conteneur d'administration)
/var/local/audit/export

Un pour chaque nœud d'administration

200 GO

Non

BLOCK_DEVICE_AUDIT_LOGS =/dev/mapper/ADM-OS

Admin

Tables de nœuds d'administration (données système dans le conteneur d'administration)
/var/local/mysql_ibdata

Un pour chaque nœud d'administration

200 GO

Non

BLOCK_DEVICE_TABLES = /dev/mapper/ADM-MySQL

Nœuds de stockage

Stockage objet (dispositifs en mode bloc /var/local/rangedb0 ) (SSD utile ici) /var/local/rangedb1 /var/local/rangedb2

Trois pour chaque conteneur de stockage

4,000 GO

Non

BLOCK_DEVICE_RANGEDB_000 = /dev/mapper/SN-Db00
BLOCK_DEVICE_RANGEDB_001 = /dev/mapper/SN-Db01
BLOCK_DEVICE_RANGEDB_002 = /dev/mapper/SN-Db02

Dans cet exemple, les tailles de disques indiquées dans le tableau suivant sont requises par type de conteneur. Les exigences par hôte physique sont décrites dans "Configuration et configuration requise de l'hôte physique", plus loin dans ce document.

Tailles de disques par type de conteneur

Conteneur d'administration

Nom Taille (Gio)

Docker-Store

100 (par conteneur)

ADM-OS

90

SMA-Vérification

200

ADM-MySQL

200

Conteneur de stockage

Nom Taille (Gio)

Docker-Store

100 (par conteneur)

SN-OS

90

Rangedb-0

4096

Rangedb-1

4096

Rangedb-2

4096

Conteneur de passerelle

Nom Taille (Gio)

Docker-Store

100 (par conteneur)

/var/local

90

Configuration et configuration requise de l'hôte physique

En combinant les exigences de calcul et de réseau indiquées dans le tableau ci-dessus, vous pouvez obtenir un ensemble de matériel de base requis pour cette installation de trois serveurs physiques (ou virtuels) avec 16 cœurs, 64 Go de RAM et deux interfaces réseau. Si un débit plus élevé est souhaité, il est possible de lier deux interfaces ou plus sur la grille ou le réseau client et d'utiliser une interface marquée VLAN telle que bond0.520 dans le fichier de configuration du nœud. Si vous attendez des charges de travail plus intenses, il vaut mieux augmenter la mémoire pour l'hôte et les conteneurs.

Comme illustré dans la figure ci-dessous, ces serveurs hébergent six conteneurs Docker, deux par hôte. La RAM est calculée en fournissant 24 Go par conteneur et 16 Go pour le système d'exploitation hôte lui-même.

Exemple de disposition pour trois hôtes.

La mémoire RAM totale requise par hôte physique (ou machine virtuelle) est de 24 x 2 + 16 = 64 Go. Les tableaux suivants répertorient le stockage sur disque requis pour les hôtes 1, 2 et 3.

Hôte 1 Taille (Gio)

Docker Store

/var/lib/docker (Système de fichiers)

200 (100 x 2)

Conteneur Admin

BLOCK_DEVICE_VAR_LOCAL

90

BLOCK_DEVICE_AUDIT_LOGS

200

BLOCK_DEVICE_TABLES

200

Conteneur de stockage

SN-OS
/var/local (périphérique)

90

Rangedb-0 (périphérique)

4096

Rangedb-1 (périphérique)

4096

Rangedb-2 (dispositif)
Hôte 2 Taille (Gio)

Docker Store

/var/lib/docker (Partagé)

200 (100 x 2)

Conteneur passerelle

GW-OS */var/local

100

Conteneur de stockage

*/var/local

100

Rangedb-0

4096

Rangedb-1

4096

Rangedb-2
Hôte 3 Taille (Gio)

Docker Store

/var/lib/docker (Partagé)

200 (100 x 2)

Conteneur passerelle

*/var/local

100

Conteneur de stockage

*/var/local

100

Rangedb-0

4096

Rangedb-1

4096

Rangedb-2

Le Docker Store a été calculé en autorisant 100 Go par /var/local (par conteneur) x deux conteneurs = 200 Go.

Préparation des nœuds

Pour préparer l'installation initiale de StorageGRID, installez d'abord RHEL version 9.2 et activez SSH. Configurez les interfaces réseau, le protocole NTP (Network Time Protocol), le DNS et le nom d'hôte conformément aux bonnes pratiques. Vous avez besoin d'au moins une interface réseau activée sur le réseau en grille et une autre pour le réseau client. Si vous utilisez une interface marquée VLAN, configurez-la comme indiqué dans les exemples ci-dessous. Sinon, une simple configuration d'interface réseau standard suffit.

Si vous devez utiliser une balise VLAN sur l'interface réseau de la grille, votre configuration doit avoir deux fichiers /etc/sysconfig/network-scripts/ au format suivant :

# cat /etc/sysconfig/network-scripts/ifcfg-enp67s0
# This is the parent physical device
TYPE=Ethernet
BOOTPROTO=none
DEVICE=enp67s0
ONBOOT=yes
# cat /etc/sysconfig/network-scripts/ifcfg-enp67s0.520
# The actual device that will be used by the storage node file
DEVICE=enp67s0.520
BOOTPROTO=none
NAME=enp67s0.520
IPADDR=10.10.200.31
PREFIX=24
VLAN=yes
ONBOOT=yes

Cet exemple suppose que votre périphérique réseau physique pour le réseau de grille est enp67s0. Il pourrait également être un dispositif lié tel que bond0. Que vous utilisiez la liaison ou une interface réseau standard, vous devez utiliser l'interface marquée VLAN dans votre fichier de configuration de nœud si votre port réseau n'a pas de VLAN par défaut ou si le VLAN par défaut n'est pas associé au réseau de grille. Le conteneur StorageGRID lui-même ne débalise pas les trames Ethernet, il doit donc être géré par le système d'exploitation parent.

Configuration du stockage en option avec iSCSI

Si vous n'utilisez pas de stockage iSCSI, vous devez vous assurer que host1, host2 et host3 contiennent des périphériques de bloc de taille suffisante pour répondre à leurs besoins. Reportez-vous à la section pour connaître les exigences en matière de stockage pour "Tailles de disques par type de conteneur" les hôtes 1, 2 et 3.

Pour configurer le stockage avec iSCSI, procédez comme suit :

Étapes

  1. Si vous utilisez un stockage iSCSI externe tel que le logiciel de gestion des données NetApp E-Series ou NetApp ONTAP®, installez les packages suivants :

    sudo yum install iscsi-initiator-utils
sudo yum install device-mapper-multipath

  2. Recherchez l'ID d'initiateur sur chaque hôte.

    # cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.2006-04.com.example.node1

  3. En utilisant le nom d'initiateur de l'étape 2, mappez les LUN de votre périphérique de stockage (du nombre et de la taille indiqués dans le "Conditions de stockage" tableau) sur chaque nœud de stockage.

  4. Identifiez les LUN créées avec et connectez-vous à ces LUN iscsiadm .

    # iscsiadm -m discovery -t st -p target-ip-address
# iscsiadm -m node -T iqn.2006-04.com.example:3260 -l
Logging in to [iface: default, target: iqn.2006-04.com.example:3260, portal: 10.64.24.179,3260] (multiple)
Login to [iface: default, target: iqn.2006-04.com.example:3260, portal: 10.64.24.179,3260] successful.
    Remarque Pour plus de détails, consultez le "Création d'un initiateur iSCSI" portail des clients Red Hat.

  5. Pour afficher les chemins d'accès multiples et les WWID de LUN associés, exécutez la commande suivante :

    # multipath -ll

    Si vous n'utilisez pas iSCSI avec des périphériques à chemins d'accès multiples, montez simplement votre périphérique à l'aide d'un nom de chemin unique qui persistera à modifier et à redémarrer le périphérique.

    /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:1:0
    Astuce L'utilisation de /dev/sdx noms de périphériques peut entraîner des problèmes ultérieurement si des périphériques sont supprimés ou ajoutés. si vous utilisez des périphériques multivoies, modifiez le /etc/multipath.conf fichier pour utiliser les alias comme suit.
    Remarque Ces périphériques peuvent être présents ou non sur tous les nœuds, selon la disposition. 
    multipaths {
multipath {
wwid 36d039ea00005f06a000003c45fa8f3dc
alias Docker-Store
}
multipath {
wwid 36d039ea00006891b000004025fa8f597
alias Adm-Audit
}
multipath {
wwid 36d039ea00005f06a000003c65fa8f3f0
alias Adm-MySQL
}
multipath {
wwid 36d039ea00006891b000004015fa8f58c
alias Adm-OS
}
multipath {
wwid 36d039ea00005f06a000003c55fa8f3e4
alias SN-OS
}
multipath {
wwid 36d039ea00006891b000004035fa8f5a2
alias SN-Db00
}
multipath {
wwid 36d039ea00005f06a000003c75fa8f3fc
alias SN-Db01
}
multipath {
    wwid 36d039ea00006891b000004045fa8f5af
alias SN-Db02
}
multipath {
wwid 36d039ea00005f06a000003c85fa8f40a
alias GW-OS
}
}

Avant d'installer Docker sur votre système d'exploitation hôte, formatez et montez le support de LUN ou de disque /var/lib/docker. Les autres LUN sont définies dans le fichier de configuration du nœud et utilisées directement par les conteneurs StorageGRID. C'est-à-dire qu'ils n'apparaissent pas dans le système d'exploitation hôte ; ils apparaissent dans les conteneurs eux-mêmes et ces systèmes de fichiers sont gérés par le programme d'installation.

Si vous utilisez une LUN avec support iSCSI, placez un élément similaire à la ligne suivante dans votre fichier fstab. Comme indiqué, les autres LUN n'ont pas besoin d'être montées dans le système d'exploitation hôte, mais doivent apparaître comme périphériques de bloc disponibles.

/dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:1:0 /var/lib/docker ext4 defaults 0 0

Préparation de l'installation de Docker

Pour préparer l'installation de Docker, procédez comme suit :

Étapes

  1. Créez un système de fichiers sur le volume de stockage Docker sur les trois hôtes.

    # sudo mkfs.ext4 /dev/sd?

    Si vous utilisez des périphériques iSCSI avec chemins d'accès multiples, utilisez /dev/mapper/Docker-Store.

  2. Créer le point de montage du volume de stockage Docker :

    # sudo mkdir -p /var/lib/docker

  3. Ajoutez une entrée similaire pour docker-Storage-volume-device à /etc/fstab.

    /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:1:0 /var/lib/docker ext4 defaults 0 0

    L'option suivante _netdev est recommandée uniquement si vous utilisez un périphérique iSCSI. Si vous utilisez un périphérique de bloc local _netdev n'est pas nécessaire et defaults est recommandé.

    /dev/mapper/Docker-Store /var/lib/docker ext4 _netdev 0 0

  4. Montez le nouveau système de fichiers et affichez l'utilisation du disque.

    # sudo mount /var/lib/docker
[root@host1]# df -h | grep docker
/dev/sdb 200G 33M 200G 1% /var/lib/docker

  5. Désactivez l'échange et désactivez-le pour des raisons de performances.

    $ sudo swapoff --all

  6. Pour conserver les paramètres, supprimez toutes les entrées de swap de /etc/fstab telles que :

    /dev/mapper/rhel-swap swap defaults 0 0
    Remarque Si vous ne désactivez pas ces fichiers, les performances peuvent être considérablement réduites.

  7. Effectuez un redémarrage test de votre nœud pour vous assurer que le /var/lib/docker volume est persistant et que tous les périphériques de disque sont retournés.