1.3. Considérations relatives à la prise en charge de GFS2
Pour pouvoir bénéficier de l'assistance de Red Hat pour un cluster exécutant un système de fichiers GFS2, vous devez prendre en compte les politiques d'assistance pour les systèmes de fichiers GFS2.
1.3.1. Taille maximale du système de fichiers et du cluster
Le tableau suivant résume la taille maximale actuelle du système de fichiers et le nombre de nœuds pris en charge par GFS2.
| Paramètres | Maximum |
|---|---|
| Nombre de nœuds | 16 (x86, Power8 sur PowerVM) 4 (s390x sous z/VM) |
| Taille du système de fichiers | 100TB sur toutes les architectures supportées |
GFS2 est basé sur une architecture 64 bits, qui peut théoriquement accueillir un système de fichiers de 8 EB. Si votre système nécessite des systèmes de fichiers GFS2 plus importants que ceux actuellement pris en charge, contactez votre représentant Red Hat.
Lorsque vous déterminez la taille de votre système de fichiers, vous devez tenir compte de vos besoins en matière de récupération. L'exécution de la commande fsck.gfs2 sur un système de fichiers très volumineux peut prendre beaucoup de temps et consommer une grande quantité de mémoire. En outre, en cas de défaillance d'un disque ou d'un sous-système de disque, le temps de récupération est limité par la vitesse de votre support de sauvegarde. Pour plus d'informations sur la quantité de mémoire nécessaire à la commande fsck.gfs2, voir Détermination de la mémoire nécessaire à l'exécution de fsck.gfs2.
1.3.2. Taille minimale de la grappe
Bien qu'un système de fichiers GFS2 puisse être implémenté dans un système autonome ou dans le cadre d'une configuration en grappe, Red Hat ne prend pas en charge l'utilisation de GFS2 en tant que système de fichiers à nœud unique, à l'exception des cas suivants :
- Red Hat prend en charge les systèmes de fichiers GFS2 à nœud unique pour le montage d'instantanés de systèmes de fichiers en grappe qui pourraient être nécessaires, par exemple, à des fins de sauvegarde.
Un cluster à nœud unique montant des systèmes de fichiers GFS2 (qui utilise DLM) est pris en charge en tant que nœud de reprise après sinistre (DR) sur un site secondaire. Cette exception n'est valable qu'à des fins de reprise après sinistre et non pour transférer la charge de travail du cluster principal vers le site secondaire.
Par exemple, la copie des données du système de fichiers monté sur le site secondaire alors que le site principal est hors ligne est prise en charge. Toutefois, la migration d'une charge de travail du site principal directement vers un site secondaire à nœud unique n'est pas prise en charge. Si la charge de travail complète doit être migrée vers le site secondaire à nœud unique, le site secondaire doit être de la même taille que le site primaire.
Red Hat recommande que lorsque vous montez un système de fichiers GFS2 dans un cluster à un seul nœud, vous spécifiez l'option de montage
errors=panicafin que le cluster à un seul nœud panique lorsqu'un retrait GFS2 se produit puisque le cluster à un seul nœud ne sera pas en mesure de se clôturer lui-même lorsqu'il rencontrera des erreurs de système de fichiers.
Red Hat prend en charge un certain nombre de systèmes de fichiers haute performance à nœud unique qui sont optimisés pour un nœud unique et qui ont donc généralement moins de frais généraux qu'un système de fichiers en grappe. Red Hat recommande d'utiliser ces systèmes de fichiers de préférence à GFS2 dans les cas où un seul nœud doit monter le système de fichiers. Pour plus d'informations sur les systèmes de fichiers pris en charge par Red Hat Enterprise Linux 9, reportez-vous à Gestion des systèmes de fichiers.
