2 Configuration matérielle requise et recommandations #
La configuration matérielle requise de Ceph dépend fortement du workload des E/S. La configuration matérielle requise et les recommandations suivantes doivent être considérées comme un point de départ de la planification détaillée.
En général, les recommandations données dans cette section dépendent du processus. Si plusieurs processus sont situés sur la même machine, les besoins en UC, RAM, disque et réseau doivent être additionnés.
2.1 Aperçu du réseau #
Ceph compte plusieurs réseaux logiques :
Un réseau d'interface client appelé
réseau public.Un réseau interne approuvé, le réseau back-end, appelé
réseau de grappes. Cette option est facultative.Un ou plusieurs réseaux client pour les passerelles. Ceci est facultatif et sort du cadre de ce chapitre.
Le réseau public est le réseau sur lequel les daemons Ceph communiquent entre eux et avec leurs clients. Cela signifie que tout le trafic de la grappe Ceph passe par ce réseau, sauf dans le cas où un réseau de grappe est configuré.
Le réseau de grappe est le réseau back-end entre les noeuds OSD, pour la réplication, le rééquilibrage et la récupération. Lorsqu'il est configuré, ce réseau facultatif devrait idéalement fournir deux fois la bande passante du réseau public avec la réplication tripartite par défaut, étant donné que l'OSD primaire envoie deux copies aux autres OSD par le biais de ce réseau. Le réseau public est situé entre les clients et les passerelles d'un côté pour communiquer avec les moniteurs, les gestionnaires ainsi qu'avec les noeuds MDS et OSD. Il est également utilisé par les moniteurs, les gestionnaires et les noeuds MDS pour communiquer avec les noeuds OSD.
2.1.1 Recommandations concernant le réseau #
Nous vous recommandons d'utiliser un seul réseau tolérant aux pannes avec une bande passante suffisante pour répondre à vos besoins. Pour l'environnement de réseau public Ceph, nous recommandons deux interfaces réseau 25 GbE (ou plus rapides) liées à l'aide de 802.3ad (LACP). Cette recommandation est considérée comme la configuration minimale pour Ceph. Si vous utilisez également un réseau en grappe, nous recommandons quatre interfaces réseau 25 GbE liées. La liaison de deux ou plusieurs interfaces réseau offre un meilleur débit grâce à l'agrégation de liens et, compte tenu des liens et commutateurs redondants, une meilleure tolérance aux pannes et une meilleure maintenabilité.
Vous pouvez également créer des VLAN pour isoler différents types de trafic sur une liaison. Par exemple, vous pouvez créer une liaison pour fournir deux interfaces VLAN, l'une pour le réseau public et l'autre pour le réseau en grappe. Ce n'est toutefois pas nécessaire lors de la configuration du réseau Ceph. Vous trouverez des détails sur la liaison des interfaces sur le site https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-network.html#sec-network-iface-bonding.
La tolérance aux pannes peut être améliorée en isolant les composants dans des domaines de défaillance. Pour améliorer la tolérance aux pannes du réseau, la liaison d'une interface à partir de deux cartes d'interface réseau (NIC) distinctes offre une protection contre la défaillance d'une seule carte réseau. De même, la création d'une liaison entre deux commutateurs protège contre la défaillance d'un commutateur. Nous vous recommandons de vous adresser au fournisseur de l'équipement réseau afin de définir le niveau de tolérance aux pannes requis.
La configuration réseau d'administration supplémentaire (qui permet, par exemple, de séparer les réseaux SSH, Salt ou DNS) n'est ni testée ni prise en charge.
Si les noeuds de stockage sont configurés via DHCP, les timeouts par défaut peuvent ne pas être suffisants pour que le réseau soit configuré correctement avant le démarrage des différents daemons Ceph. Si cela se produit, les instances MON et OSD de Ceph ne démarreront pas correctement (l'exécution de systemctl status ceph\* entraînera des erreurs de type « unable to bind » [liaison impossible]). Pour éviter ce problème, nous vous recommandons d'augmenter le timeout du client DHCP sur au moins 30 secondes pour chaque noeud de votre grappe de stockage. Pour ce faire, vous pouvez modifier les paramètres suivants sur chaque noeud :
Dans /etc/sysconfig/network/dhcp, définissez
DHCLIENT_WAIT_AT_BOOT="30"
Dans /etc/sysconfig/network/config, définissez
WAIT_FOR_INTERFACES="60"
2.1.1.1 Ajout d'un réseau privé à une grappe en cours d'exécution #
Si vous ne spécifiez pas de réseau pour la grappe lors du déploiement de Ceph, il suppose un environnement de réseau public unique. Bien que Ceph fonctionne parfaitement avec un réseau public, ses performances et sa sécurité s'améliorent lorsque vous définissez un second réseau de grappe privé. Pour prendre en charge deux réseaux, chaque noeud Ceph doit disposer d'au moins deux cartes réseau.
Vous devez apporter les modifications suivantes à chaque noeud Ceph. Ces modifications sont relativement rapides à apporter à une petite grappe, mais peuvent prendre beaucoup de temps si votre grappe est composée de centaines ou de milliers de noeuds.
Définissez le réseau de la grappe à l'aide de la commande suivante :
#ceph config set global cluster_network MY_NETWORKRedémarrez les OSD pour qu'ils se lient au réseau de grappe spécifié :
#systemctl restart ceph-*@osd.*.serviceVérifiez que le réseau privé de la grappe fonctionne comme prévu au niveau du système d'exploitation.
2.1.1.2 Noeuds de moniteur sur des sous-réseaux distincts #
Si les noeuds de moniteur se trouvent sur plusieurs sous-réseaux, par exemple s'ils se trouvent dans des pièces différentes et sont desservis par différents commutateurs, vous devez spécifier leur adresse de réseau public en notation CIDR :
cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_NPar exemple :
cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"
Si vous spécifiez plusieurs segments de réseau pour le réseau public (ou en grappe) comme décrit dans cette section, chacun de ces sous-réseaux doit pouvoir être routé vers tous les autres. Dans le cas contraire, les daemons MON et les autres daemons Ceph sur différents segments de réseau ne peuvent pas communiquer et il en résulte une grappe divisée. De plus, si vous utilisez un pare-feu, veillez à inclure chaque sous-réseau ou adresse IP dans vos iptables et ouvrez leur les ports nécessaires sur tous les noeuds.
2.2 Configurations d'architecture multiples #
SUSE Enterprise Storage prend en charge les architectures x86 et Arm. Si nous considérons chaque architecture, il est important de noter que d'un point de vue du nombre de coeurs par OSD, de la fréquence et de la mémoire RAM, il n'y a pas de différence réelle entre les architectures de processeurs en termes de dimensionnement.
Comme pour les processeurs x86 plus petits (non-serveurs), les coeurs basés sur Arm moins performants peuvent ne pas fournir une expérience optimale, en particulier lorsqu'ils sont utilisés pour des réserves codées à effacement.
Dans toute la documentation, SYSTEM-ARCH est utilisé à la place de x86 ou Arm.
2.3 Configuration du matériel #
Pour bénéficier d'une expérience optimale avec le produit, nous vous recommandons de commencer par configurer la grappe recommandée. Pour une grappe de test ou une grappe ne nécessitant pas de performances très importantes, nous documentons une configuration minimale prise en charge pour la grappe.
2.3.1 Configuration minimale de la grappe #
Une configuration de grappe minimale pour le produit se compose des éléments suivants :
Au moins quatre noeuds physiques (noeuds OSD) avec cohabitation des services
Ethernet Dual-10 Go en tant que réseau lié
Un noeud Admin distinct (peut être virtualisé sur un noeud externe)
Une configuration détaillée est la suivante :
Un noeud Admin distinct avec 4 Go de RAM, quatre coeurs et 1 To de capacité de stockage. Il s'agit généralement du noeud Salt Master. Les passerelles et services Ceph et de passerelles, tels que Ceph Monitor, Metadata Server, Ceph OSD, Object Gateway ou NFS Ganesha ne sont pas pris en charge sur le noeud Admin, car il doit orchestrer indépendamment les processus de mise à jour et de mise à niveau de la grappe.
Au moins quatre noeuds OSD physiques, avec huit disques OSD chacun, reportez-vous à la Section 2.4.1, « Configuration minimale requise » pour consulter la configuration requise.
La capacité totale de la grappe doit être dimensionnée de sorte que, même si un noeud est indisponible, la capacité totale utilisée (y compris la redondance) ne dépasse pas 80 %.
Trois instances de Ceph Monitor. Pour des raisons de latence, les moniteurs doivent être exécutés à partir d'un espace de stockage SSD/NVMe et non à partir de disques durs.
Les moniteurs, le serveur de métadonnées et les passerelles peuvent cohabiter sur les noeuds OSD. Reportez-vous à la Section 2.12, « OSD et Monitor partageant un même serveur » concernant la cohabitation des moniteurs. Si vous faites cohabiter des services, les exigences de mémoire et d'UC doivent être additionnées.
La passerelle iSCSI, Object Gateway et le serveur de métadonnées ont au minimum besoin de 4 Go de RAM incrémentielle et de quatre coeurs.
Si vous utilisez CephFS, S3/Swift, iSCSI, au moins deux instances des rôles respectifs (serveur de métadonnées, Object Gateway, iSCSI) sont requises à des fins de redondance et de disponibilité.
Les noeuds doivent être dédiés à SUSE Enterprise Storage et ne doivent pas être utilisés pour d'autres workloads physiques, conteneurisés ou virtualisés.
Si l'une des passerelles (iSCSI, Object Gateway, NFS Ganesha, serveur de métadonnées, etc.) est déployée au sein de machines virtuelles, ces dernières ne doivent pas être hébergées sur les machines physiques servant d'autres rôles de grappe. (Ce n'est pas nécessaire puisqu'elles sont prises en charge en tant que services cohabitants.)
Lors du déploiement de services en tant que machines virtuelles sur des hyperviseurs en dehors de la grappe physique principale, les domaines de défaillance doivent être respectés afin de garantir la redondance.
Par exemple, ne déployez pas plusieurs rôles du même type sur le même hyperviseur, tels que plusieurs instances MON ou MDS.
Lors d'un déploiement sur des machines virtuelles, il est particulièrement important de s'assurer que les noeuds disposent d'une solide connectivité réseau et d'une synchronisation horaire fonctionnant convenablement.
Les noeuds d'hyperviseur doivent avoir la bonne taille pour éviter les interférences occasionnées par d'autres workloads consommant des ressources de processeur, de RAM, de réseau et de stockage.
2.3.2 Configuration recommandée pour une grappe en production #
Une fois votre grappe développée, nous vous recommandons de déplacer les instances Ceph Monitor, les serveurs de métadonnées et les passerelles vers des noeuds distincts afin d'améliorer la tolérance aux pannes.
Sept noeuds de stockage des objets
Aucun noeud n'excède environ 15 % du stockage total.
La capacité totale de la grappe doit être dimensionnée de sorte que, même si un noeud est indisponible, la capacité totale utilisée (y compris la redondance) ne dépasse pas 80 %.
Ethernet de 25 Go ou plus chacun lié à la grappe interne et au réseau public externe.
Plus de 56 OSD par grappe de stockage.
Reportez-vous à la Section 2.4.1, « Configuration minimale requise » pour d'autres recommandations.
Noeuds d'infrastructure physique dédiés.
Trois noeuds de moniteur Ceph : 4 Go de RAM, processeur à 4 coeurs, disques SSD RAID 1.
Reportez-vous à la Section 2.5, « Noeuds de moniteur » pour d'autres recommandations.
Noeuds Object Gateway : 32 Go de RAM, processeur à 8 coeurs, disques SSD RAID 1.
Reportez-vous à la Section 2.6, « Noeuds Object Gateway » pour d'autres recommandations.
Noeuds Passerelle iSCSI : 16 Go de RAM, processeur à 8 coeurs, disques SSD RAID 1.
Reportez-vous à la Section 2.9, « Noeuds de passerelle iSCSI » pour d'autres recommandations.
Noeuds MDS (un actif/un de secours) : 32 Go de RAM, processeur à 8 coeurs, disques SSD RAID 1.
Reportez-vous à la Section 2.7, « Noeuds de serveur de métadonnées » pour d'autres recommandations.
Un noeud Admin SES : 4 Go de RAM, processeur à 4 coeurs, disques SSD RAID 1.
2.3.3 Configuration multipath #
Si vous souhaitez utiliser du matériel multipath, assurez-vous que LVM voit multipath_component_detection = 1 dans le fichier de configuration sous la section devices. Vous pouvez vérifier à l'aide de la commande lvm config.
Vous pouvez également vous assurer que LVM filtre les composants mpath d'un périphérique via la configuration du filtre LVM. Cela dépendra de l'hôte.
Ce n'est pas recommandé et ne doit être envisagé que si multipath_component_detection = 1 ne peut pas être défini.
Pour plus d'informations sur la configuration multipath, consultez l'adresse https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-multipath.html#sec-multipath-lvm.
2.4 Noeuds de stockage des objets #
2.4.1 Configuration minimale requise #
Les recommandations d'UC suivantes tiennent compte des périphériques indépendamment de l'utilisation par Ceph :
1x thread d'UC 2 GHz par disque rotatif.
2x threads d'UC 2 GHz par disque SSD.
4x threads d'UC 2 GHz par disque NVMe.
Réseaux 10 GbE séparés (public/client et interne), 4x 10 GbE requis, 2x 25 GbE recommandés.
Mémoire RAM totale requise = nombre d'OSD x (1 Go +
osd_memory_target) + 16 GoReportez-vous au Section 28.4.1, « Configuration du dimensionnement automatique du cache » pour plus de détails sur
osd_memory_target.Disques OSD dans les configurations JBOD ou les configurations RAID-0 individuelles.
Le journal OSD peut résider sur le disque OSD.
Les disques OSD doivent être exclusivement utilisés par SUSE Enterprise Storage.
Disque et SSD dédiés au système d'exploitation, de préférence dans une configuration RAID 1.
Allouez au moins 4 Go de RAM supplémentaires si cet hôte OSD doit héberger une partie d'une réserve en cache utilisée pour la hiérarchisation du cache.
Les moniteurs Ceph, la passerelle et les serveurs de métadonnées peuvent résider sur les noeuds de stockage des objets.
Pour des raisons de performances de disque, les noeuds OSD sont des noeuds sans système d'exploitation. Aucun autre workload ne doit s'exécuter sur un noeud OSD, sauf s'il s'agit d'une configuration minimale d'instances Ceph Monitor et Ceph Manager.
Disques SSD pour journal avec un ratio journal SSD à OSD de 6:1.
Assurez-vous qu'aucun périphérique de bloc en réseau n'est assigné aux noeuds OSD, tels que des images de périphérique de bloc RADOS ou iSCSI.
2.4.2 Taille minimale du disque #
Deux types d'espace disque sont nécessaires pour l'exécution sur un OSD : l'espace pour le périphérique WAL/DB et l'espace primaire pour les données stockées. La valeur minimale (et par défaut) pour le périphérique WAL/DB est de 6 Go. L'espace minimum pour les données est de 5 Go, car les partitions inférieures à 5 Go sont automatiquement assignées à une pondération de 0.
Ainsi, bien que l'espace disque minimal pour un OSD soit de 11 Go, il est recommandé de ne pas utiliser un disque inférieur à 20 Go, même à des fins de test.
2.4.3 Taille recommandée pour les périphériques WAL et DB de BlueStore #
Reportez-vous à la Section 1.4, « BlueStore » pour plus d'informations sur BlueStore.
Nous vous recommandons de réserver 4 Go pour le périphérique WAL. Alors que la taille minimale de la base de données est de 64 Go pour les workloads RBD uniquement, la taille recommandée pour les workloads Object Gateway et CephFS est de 2 % de la capacité du périphérique principal (mais au moins 196 Go).
ImportantNous recommandons des volumes de base de données plus importants pour les déploiements à charge élevée, en particulier si l'utilisation de RGW ou de CephFS est importante. Réservez une certaine capacité (emplacements) pour installer plus de matériel et plus d'espace DB si nécessaire.
Si vous envisagez de placer les périphériques WAL et DB sur le même disque, il est recommandé d'utiliser une partition unique pour les deux périphériques, plutôt que d'utiliser une partition distincte pour chacun. Cela permet à Ceph d'utiliser également le périphérique DB pour les opérations WAL. La gestion de l'espace disque est donc plus efficace, car Ceph n'utilise la partition DB pour le WAL qu'en cas de nécessité. Un autre avantage est que la probabilité que la partition WAL soit pleine est très faible, et lorsqu'elle n'est pas entièrement utilisée, son espace n'est pas gaspillé, mais utilisé pour les opérations de DB.
Pour partager le périphérique DB avec le WAL, ne spécifiez pas le périphérique WAL et indiquez uniquement le périphérique DB.
Pour plus d'informations sur la spécification d'une disposition OSD, reportez-vous au Section 13.4.3, « Ajout d'OSD à l'aide de la spécification DriveGroups ».
2.4.4 SSD pour les partitions WAL/DB #
Les disques SSD n'ont pas de pièces mobiles. Cela réduit le temps d'accès aléatoire et la latence de lecture tout en accélérant le débit de données. Comme leur prix par Mo est significativement plus élevé que le prix des disques durs tournants, les disques SSD ne conviennent que pour un stockage plus petit.
Les OSD peuvent constater une amélioration significative de leurs performances en stockant leurs partitions sur un disque SSD et les données d'objet sur un disque dur distinct.
Étant donné que les partitions WAL/DB occupent relativement peu d'espace, vous pouvez partager un disque SSD avec plusieurs partitions WAL/DB. N'oubliez pas qu'avec chaque partition WAL/DB, les performances du disque SSD se dégradent. Il est déconseillé de partager plus de six partitions WAL/DB sur le même disque SSD et 12 sur des disques NVMe.
2.4.5 Nombre maximal recommandé de disques #
Vous pouvez avoir autant de disques sur un serveur que ce dernier l'autorise. Il existe quelques aspects à considérer lorsque vous planifiez le nombre de disques par serveur :
Bande passante du réseau. Plus vous avez de disques sur un serveur, plus il y a de données à transférer via la ou les cartes réseau pour les opérations d'écriture sur disque.
Mémoire. Plus de 2 Go de RAM sont utilisés pour le cache BlueStore. Avec la valeur par défaut de l'option
osd_memory_target, à savoir 4 Go, le système dispose d'une taille de cache de départ raisonnable pour les supports rotatifs. Si vous utilisez des disques SSD ou NVMe, pensez à augmenter la taille du cache et l'allocation de RAM par OSD afin d'optimiser les performances.Tolérance aux pannes. Si le serveur complet tombe en panne, plus il comporte de disques, plus le nombre d'OSD perdus temporairement par la grappe est important. En outre, pour maintenir les règles de réplication en cours d'exécution, vous devez copier toutes les données du serveur en panne vers les autres noeuds de la grappe.
2.5 Noeuds de moniteur #
Au moins trois noeuds MON sont requis. Le nombre de moniteurs doit toujours être impair (1+2n).
4 Go de RAM.
Processeur à quatre coeurs logiques.
Un SSD ou un autre type de support de stockage suffisamment rapide est vivement recommandé pour les moniteurs, en particulier pour le chemin
/var/lib/cephsur chaque noeud de moniteur, car le quorum peut être instable avec des latences de disque élevées. Deux disques en configuration RAID 1 sont recommandés pour la redondance. Il est recommandé d'utiliser des disques distincts ou au moins des partitions de disque distinctes pour les processus Monitor, afin de protéger l'espace disque disponible du moniteur contre des phénomènes tels que le grossissement excessif du fichier journal.Il ne doit y avoir qu'un seul processus Monitor par noeud.
La combinaison des noeuds OSD, Monitor ou Object Gateway n'est prise en charge que s'il y a suffisamment de ressources matérielles disponibles. Cela signifie que les besoins de tous les services doivent être additionnés.
Deux interfaces réseau liées à plusieurs commutateurs.
2.6 Noeuds Object Gateway #
Les noeuds Object Gateway doivent avoir au moins six coeurs de processeur et 32 Go de RAM. Lorsque d'autres processus sont colocalisés sur la même machine, leurs besoins doivent être additionnés.
2.7 Noeuds de serveur de métadonnées #
Le dimensionnement approprié des noeuds MDS (Metadata Server, Serveur de métadonnées) dépend du cas d'utilisation spécifique. En règle générale, plus le nombre de fichiers ouverts que le serveur de métadonnées doit traiter est important, plus l'UC et la RAM requises sont importantes. La configuration minimale requise est la suivante :
4 Go de RAM pour chaque daemon MDS.
Interface réseau liée.
2,5 GHz d'UC avec au moins 2 coeurs.
2.8 Noeud Admin #
Au moins 4 Go de RAM et une UC quadruple coeur sont requis. Cela inclut l'exécution de Salt Master sur le noeud Admin. Pour les grappes de grande taille avec des centaines de noeuds, 6 Go de RAM sont conseillés.
2.9 Noeuds de passerelle iSCSI #
Les noeuds de passerelle iSCSI doivent avoir au moins six coeurs de processeur et 16 Go de RAM.
2.10 SES et autres produits SUSE #
Cette section contient des informations importantes concernant l'intégration de SES avec d'autres produits SUSE.
2.10.1 SUSE Manager #
SUSE Manager et SUSE Enterprise Storage n'étant pas intégrés, SUSE Manager ne peut actuellement pas gérer une grappe SES.
2.11 Limitations concernant les noms #
Ceph ne prend généralement pas en charge les caractères non-ASCII dans les fichiers de configuration, les noms de réserve, les noms d'utilisateur, etc. Lors de la configuration d'une grappe Ceph, il est recommandé d'utiliser uniquement des caractères alphanumériques simples (A-Z, a-z, 0-9) et des ponctuations minimales (« . », « - », « _ ») dans tous les noms d'objet/de configuration Ceph.
2.12 OSD et Monitor partageant un même serveur #
Bien qu'il soit techniquement possible d'exécuter des OSD et des instances Monitor sur le même serveur dans des environnements de test, il est vivement recommandé de disposer d'un serveur distinct pour chaque noeud de moniteur en production. Le principal motif concerne la performance : plus la grappe contient d'OSD, plus les noeuds MON doivent effectuer un grand nombre d'opérations d'E/S. Et lorsqu'un serveur est partagé entre un noeud MON et plusieurs OSD, les opérations d'E/S des OSD constituent un facteur limitant pour le noeud de moniteur.
Un autre aspect consiste à déterminer s'il convient de partager des disques entre un OSD, un noeud MON et le système d'exploitation sur le serveur. La réponse est simple : si possible, dédiez un disque distinct à l'OSD et un serveur distinct au noeud de moniteur.
Bien que Ceph prenne en charge les OSD basés sur les répertoires, un OSD doit toujours avoir un disque dédié autre que celui du système d'exploitation.
S'il est vraiment nécessaire d'exécuter l'OSD et le noeud MON sur le même serveur, exécutez MON sur un disque distinct en montant le disque dans le répertoire /var/lib/ceph/mon pour obtenir des performances légèrement meilleures.