Alors, vous voulez construire un cluster Ceph ?

Je suis un grand fan de Ceph, la solution de stockage définie par logiciel, open-source et massivement évolutive. Sa capacité à s’auto-réparer et à faire face à des événements de cluster autrement traumatisants (oh, vous avez perdu un nœud ? pas de problème !), combinée à son absence de points de défaillance uniques, en fait l’un de mes favoris.

Vous trouverez ci-dessous trois principes simples qui peuvent aider à diriger la conception de grands ou de petits clusters.

Si votre objectif principal est les dollars par mégaoctet de stockage, alors naturellement vous pourriez graviter vers les serveurs qui peuvent prendre le plus grand nombre de disques, et les plus grands disques que vous pouvez obtenir.

Faites attention ici. Il y a quelques considérations avec les clusters ‘étroits et profonds’ :

1. Chaque nœud détient un plus grand pourcentage des données de votre cluster. Exemple : dans un cluster à trois nœuds, chaque nœud détient 33 % de vos données. Dans un cluster de dix nœuds, ce n’est que 10% par nœud. La perte d’un seul nœud dans un petit cluster entraînera une migration de données nettement plus importante, en particulier lorsque le cluster commence à se remplir, et potentiellement une panne si vous n’avez pas configuré correctement les ratios plein et quasi plein de votre cluster.
2. Forcer plus de trafic réseau sur moins de nœuds. Ceph est un système de stockage basé sur le réseau, donc avec moins de nœuds, vous forcez beaucoup de trafic client sur moins de NIC. Cela s’aggrave lorsque le nombre de disques par nœud augmente, car vous avez plus d’OSD qui se disputent une bande passante limitée. Pire encore, pendant les événements de récupération, votre trafic de récupération entre en concurrence avec les E/S des clients sur votre réseau, ce qui a un impact supplémentaire sur l’expérience des utilisateurs.
3. Pour un nombre élevé de disques par nœud, le contrôleur de disque peut être un goulot d’étranglement s’il ne dispose pas d’une bande passante suffisante pour transporter tous vos disques à pleine vitesse.
4. Augmentation du temps de récupération et de guérison lorsque vous perdez un nœud entier, car davantage de données doivent être répliquées et récupérées.

Les performances globales du cluster s’échelonnent très bien lorsque le nombre de nœuds augmente. Vous trouverez ici une comparaison d’un cluster de 3 nœuds par rapport à un cluster de 5 nœuds avec BlueStore.

Si vous visez un grand cluster, résistez à la tentation d’emballer tous les disques dans le moins de nœuds possible.

En résumé :

• Ceph évolue très bien à mesure que le nombre de nœuds augmente.
• Avoir trop peu de nœuds dans le cluster place plus de vos données de cluster sur chaque nœud, ce qui augmente les E/S de récupération et les temps de récupération.
• Vous pouvez commencer avec aussi peu que trois nœuds, mais si vous pouvez vous permettre de répartir vos disques sur plus de nœuds, il est préférable de le faire.

Soyez généreux avec la mise en réseau

Il est inutile de mettre des supports rapides dans un serveur puis de les entraver avec une connexion réseau de 1GbE. Visez 10GbE pour la production, au minimum, et mieux encore, cherchez à avoir plusieurs interfaces 10Gb liées avec le protocole de contrôle d’agrégation de liens (LACP) pour une bande passante accrue. Ceph est un système de stockage basé sur le réseau, donc une chose dont le cluster ne devrait pas manquer est la bande passante du réseau.

Séparer toujours votre réseau orienté vers le public de votre réseau interne de cluster. Le réseau public transportera le trafic client, tandis que le réseau interne transportera le trafic de battement de cœur, de réplication et de récupération entre les OSD. Si vous pouvez vous passer des cartes d’interface réseau, faites passer ces deux réseaux par des interfaces distinctes. Les séparer améliore la réactivité des clients pendant les événements de récupération, et aide les événements de récupération à se terminer plus rapidement car les E/S de récupération ne sont pas en concurrence avec les E/S des clients sur la même NIC.

N’oubliez pas non plus que le réseau interne transporte votre trafic de réplication, donc chaque écriture sur le réseau public entraînera (n-1) écritures sur le réseau interne, où n est le nombre de répliques. Ceph n’accusera réception d’une écriture au client que lorsqu’elle aura été écrite dans les journaux/WALs de tous les réplicas – vous ne voulez donc pas que les écritures de réplication soient goulotées sur le réseau. Si vous faites un usage intensif des pools répliqués, envisagez de dimensionner votre réseau de cluster pour qu’il soit n-1 fois plus grand que le réseau public.

Enfin, pour la redondance, assurez-vous de câbler vos nœuds à des commutateurs supérieurs de rack redondants. Vous ne voulez pas perdre un nœud entier – ou un ensemble de nœuds – parce qu’un seul commutateur a échoué !

Pour résumer :

• 10Gbit Ethernet pour la production au minimum.
• Séparer vos réseaux publics et de cluster, idéalement sur des NIC différentes mais au moins dans des VLAN/sous-réseaux différents.
• Souvenir de la règle empirique (n-1) pour les données répliquées – envisager de dimensionner votre réseau interne pour être n-1 fois plus grand que le public.
• N’oubliez pas de câbler pour la redondance, et d’établir correctement vos liaisons au niveau du système d’exploitation.
• Et en supplément : n’oubliez pas les trames jumbo sur vos interfaces !

Un support flash pour les métadonnées BlueStore.

Ceph n’accuse réception d’une écriture sur le client qu’une fois que les données ont été écrites dans le journal d’écriture (WAL) de l’OSD primaire et dans les WAL de toutes les répliques. Ainsi, plus l’écriture dans le WAL est rapide, plus Ceph accusera réception rapidement de l’écriture, et meilleur sera l’IOPS d’écriture pour le client.

Vos WALs, et idéalement vos métadonnées BlueStore RocksDB, devraient être sur le support le plus rapide que vous pouvez obtenir – SSD au minimum, et NVMe si possible. Si vous construisez un cluster full-HDD, envisagez fortement de dépenser un peu plus par nœud et d’ajouter au moins deux périphériques de support rapides pour les métadonnées et les WAL.

Pour éviter les goulots d’étranglement sur votre périphérique de support rapide, considérez la vitesse d’écriture soutenue de vos disques de données et comparez-la à l’écriture soutenue de votre périphérique rapide. Si votre disque dur peut écrire à 100MB/s soutenu, et votre SSD peut gérer 500MB/s soutenu, alors plus de 4-5 OSD par SSD et vous serez embouteillé par le SSD pour les écritures. NVMe est parfait pour ce cas d’utilisation, étant donné que leurs vitesses d’écriture soutenues peuvent atteindre les gigaoctets par seconde.

Enfin, ayez toujours plus d’un dispositif SSD/NVMe par nœud pour les métadonnées/WAL afin de vous assurer que vous ne perdrez pas tous les OSD sur le nœud si un dispositif de métadonnées échoue.

Pour résumer :

• Ceph accuse réception d’une écriture à un client lorsqu’elle a été écrite dans le WAL de l’OSD primaire et les WAL de toutes les répliques. Il fait cela pour préserver l’intégrité de vos données.
• WAL et RocksDB devraient être sur le support le plus rapide que vous pouvez obtenir – idéalement NVMe – pour obtenir une réponse au client aussi rapidement que possible.
• Ne surabonnez pas vos périphériques rapides pour votre WAL/RocksDB. Si vous le faites, vous ne faites que déplacer le goulot d’étranglement vers votre périphérique rapide.
• Ayez plus d’un périphérique rapide pour éviter de perdre tous les OSD sur un nœud si votre périphérique WAL échoue.

Résumé

Ceph est un système de stockage défini par logiciel basé sur le réseau qui évolue horizontalement de manière exceptionnelle. Ci-dessus, ce ne sont que quelques principes pour vous aider à mettre en place un système à haute performance – ne pas aller trop étroit ou profond, garder le cluster alimenté en bande passante, et utiliser des supports rapides pour vos métadonnées et WAL.