Il n'a pas besoin de toi

Dans le cadre de la popularité croissante de Rook, je veux parler de ses pièges et des problèmes qui vous attendent en chemin.

À propos de moi: Expérience en administration Ceph avec la version Hammer, fondatrice de la communauté t.me/ceph_ru dans les télégrammes.

Afin de ne pas être infondé, je ferai référence à des articles acceptés par le Habr (à en juger par la note) sur les problèmes de ceph. J'ai également rencontré la plupart des problèmes dans ces messages. Liens vers le matériel utilisé à la fin du message.

Dans un article sur Rook, nous mentionnons le ceph pour une raison - Rook est essentiellement du ceph enveloppé dans des kubernetes, ce qui signifie qu'il hérite de tous ses problèmes. Nous allons commencer par les problèmes de ceph.

Simplifiez la gestion des clusters

Un des avantages de Rook est la commodité de gérer ceph via kuberentes.

Cependant, ceph contient plus de 1000 paramètres pour le réglage, en même temps, via la tour, nous ne pouvons en modifier qu'une petite partie.

Exemple lumineux
> spectacle de configuration ceph daemon mon.a | wc -l
1401

Rook est positionné comme un moyen pratique pour installer et mettre à jour ceph
Il n'y a pas de problème avec l'installation de ceph sans que le playbook Rook-ansible soit écrit en 30 minutes, mais il y a beaucoup de problèmes avec la mise à jour des problèmes.

Citation du post de Krok

Exemple: mauvais fonctionnement des écrasables accordables après la mise à niveau de hummer en bijou

> ceph osd crush show-tunables
{
...
"Straw_calc_version": 1,
"Allowed_bucket_algs": 22,
"Profil": "inconnu",
Optimal_tunables: 0,
...
}

Mais même dans les versions mineures, il y a des problèmes.

Exemple: mise à jour 12.2.6 amenant le cluster à une erreur de santé et une PG rompue conditionnellement
ceph.com/releases/v12-2-8-released

Ne pas mettre à jour, attendre et tester? Mais nous utilisons également Rook pour la commodité des mises à jour.

La complexité du cluster de reprise après sinistre dans Rook

Exemple: OSD bloque les erreurs qui se précipitent sous ses pieds. Vous suspectez que le problème se trouve dans l'un des paramètres de la configuration, vous souhaitez modifier la configuration d'un démon spécifique, mais vous ne pouvez pas, car vous disposez de kubernetes et de DaemonSet.

Il n'y a pas d'alternative. ceph tell osd.Num injectargs ne fonctionne pas - OSD ment.

Déboguer la complexité

Pour certains paramètres et tests de performances, vous devez vous connecter directement au socket du démon osd. Dans le cas de Rook, vous devez d'abord trouver le bon conteneur, puis y aller, trouver les éléments manquants pour le réglage du débogage et être très contrarié.

La difficulté d'élever séquentiellement l'OSD

Exemple: OSD tombe sur MOO, le rééquilibrage commence, puis la chute suivante.

Solution: Relevez l'OSD un par un, attendez qu'il soit entièrement inclus dans le cluster, puis augmentez les suivants. (Plus dans le rapport de Ceph. Anatomie d'une catastrophe.)

Dans le cas d'une installation baremetal, cela se fait simplement à la main, dans le cas de Rook et d'un OSD sur le nœud, il n'y a pas de problèmes particuliers, des problèmes de levage successifs se produiront si OSD> 1 sur le nœud.

Bien sûr, ils sont résolubles, mais nous portons Rook pour simplification, mais nous obtenons des complications.

La difficulté de sélectionner des limites pour les démons céph

Pour les installations de baremetal ceph, il est assez facile de calculer les ressources nécessaires par cluster - il existe des formules et des études. Lorsque vous utilisez des CPU faibles, vous devez toujours effectuer une série de tests de performances pour savoir ce qu'est Numa, mais c'est toujours plus simple que dans Rook.

Dans le cas de Rook, en plus des limites de mémoire qui peuvent être calculées, la question se pose de fixer la limite CPU.

Et puis vous devez transpirer avec des tests de performances. En cas de sous-estimation des limites, vous obtiendrez un cluster lent, dans le cas de la définition de illim, vous obtiendrez une utilisation active du processeur avec rééquilibrage, ce qui affectera gravement vos applications dans kubernetes.

Problèmes de mise en réseau v1

Pour ceph, il est recommandé d'utiliser un réseau 2x10 Go. Un pour le trafic client, un autre pour l'utilisation de bureau ceph (rééquilibrage). Si vous vivez avec ceph sur baremetal, alors cette séparation est facile à configurer, si vous vivez avec Rook, alors avec la séparation par réseaux, cela vous posera des problèmes, car loin de chaque configuration de cluster vous permet d'alimenter deux réseaux différents en pod.

Problèmes de mise en réseau v2

Si vous refusez de partager des réseaux, avec un rééquilibrage, le trafic ceph obstruera l'ensemble du canal et vos applications dans kubernetes ralentiront ou planteront. Vous pouvez réduire le taux de rééquilibrage de ceph, mais en raison du long rééquilibrage, vous obtenez un risque accru de chute du deuxième nœud du cluster sur des disques ou des MOO, et il est déjà garanti en lecture seule sur le cluster.

Rééquilibrage long - freins à application longue

Citation d'un article de Ceph. Anatomie de catastrophe.

Test des performances du cluster:

Une opération d'écriture de 4 Ko prend 1 ms, les performances 1000 opérations / seconde en 1 flux.

Une opération de 4 Mo en taille (taille d'objet) prend 22 ms, les performances 45 opérations / seconde.

Par conséquent, lorsque l'un des trois domaines échoue, le cluster est dans un état dégradé pendant un certain temps, et la moitié des objets chauds se propageront selon différentes versions, puis la moitié des opérations d'écriture commencera par une récupération forcée.

Le temps de récupération forcé est calculé approximativement - opérations d'écriture dans un objet dégradé.

Tout d'abord, nous lisons 4 Mo en 22 ms, écrivons 22 ms, puis 1 ms nous écrivons 4 Ko de données lui-même. Au total, 45 ms pour une opération d'écriture sur un objet dégradé sur le SSD, lorsque les performances standard étaient de 1 ms - une baisse de performances de 45 fois.

Plus nous avons le pourcentage d'objets dégradés, pire c'est.

Il s'avère que le taux de rééquilibrage est critique pour le bon fonctionnement du cluster.

Paramètres spécifiques au serveur pour ceph

ceph peut nécessiter un réglage spécifique de l'hôte.

Exemple: paramètres sysctl et même JumboFrame, certains de ces paramètres peuvent affecter négativement votre charge utile.

Le vrai besoin d'une tour reste en question

Si vous êtes dans le cloud, vous disposez d'un stockage de votre fournisseur de cloud, ce qui est beaucoup plus pratique.

Si vous êtes sur vos serveurs, la gestion de ceph sera plus pratique sans kubernetes.

Louez-vous un serveur dans un hébergement low cost? Ensuite, vous trouverez beaucoup de plaisir avec le réseau, ses retards et sa bande passante, ce qui affecte évidemment négativement ceph.

Total: L'introduction de kuberentes et l'introduction du référentiel sont des tâches différentes avec différentes options d'introduction et de solution différentes - les mélanger, cela signifie faire un compromis éventuellement dangereux pour ceci ou cela. La combinaison de ces solutions sera très difficile, même au stade de la conception, et il y a encore une période de fonctionnement.

Liste de la littérature utilisée:

Post # 1 Mais vous dites Ceph ... mais est-il bon?
Post # 2 Ceph. Anatomie de catastrophe