Avec la popularité croissante de Rook, il est bon de discuter de ses sous-marins et des problèmes qui vous attendent sur le chemin.
À propos de moi : expérience en administration de ceph depuis la version hammer, fondateur de la communauté sur telegram.
Pour ne pas être un simple bavard, je me référerai aux articles reconnus sur Habr (selon le classement) concernant les problèmes avec ceph. J'ai également rencontré la plupart de ces problèmes. Les liens vers le matériel utilisé sont à la fin de l'article.
Dans l'article sur Rook, nous mentionnons ceph, non pas par hasard - Rook est en fait ceph enveloppé dans kubernetes, ce qui signifie qu'il hérite de tous ses problèmes. Commençons par les problèmes de ceph.
Simplification de la gestion de cluster
Un des avantages de Rook est la commodité de la gestion de ceph via kubernetes.
Cependant, ceph comprend plus de 1000 paramètres de configuration, tandis que via rook, nous ne pouvons en modifier qu'une petite partie.
Exemple sur Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook se positionne comme un moyen pratique d'installer et de mettre à jour ceph.
Il n'y a aucun problème avec l'installation de ceph sans Rook - un playbook ansible peut être écrit en 30 minutes, mais il y a de nombreux problèmes avec les mises à jour.
Citation d'un post de Krok
Exemple : comportement incorrect de crush tunables après la mise à jour de hummer à jewel
> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
…
}
Mais même dans le cadre de versions mineures, il peut y avoir des problèmes.
Exemple : mise à jour 12.2.6 conduisant le cluster dans un état de santé err et un PG conditionnellement corrompu
Ne pas mettre à jour, attendre et tester ? Mais nous utilisons Rook principalement pour faciliter les mises à jour aussi.
Complexité de la récupération après sinistre du cluster dans Rook
Exemple : OSD tombe en produisant des erreurs. Vous soupçonnez qu'il y a un problème avec l'un des paramètres du config, vous souhaitez changer le config pour un démon spécifique, mais vous ne pouvez pas, car vous êtes sur kubernetes et DaemonSet.
Il n'y a pas d'alternative. ceph tell osd.Num injectargs ne fonctionne pas - OSD est tombé.
Complexité du débogage
Pour certains réglages et tests de performances, il est nécessaire de se connecter directement au socket du démon osd. Dans le cas de Rook, il faut d'abord trouver le conteneur nécessaire, ensuite y entrer, découvrir l'absence d'outils de débogage et très déchanter.
Complexité de montée successive d'OSD
Exemple : OSD tombe à cause d'une OOM, le rééquilibrage commence, puis les suivants tombent.
Solution : Élever l'OSD un par un, en attendant qu'il soit complètement intégré au cluster avant de faire monter les suivants. (Pour plus de détails, voir le rapport Ceph. Anatomie des catastrophes).
Dans le cas d'installations baremetal, cela se fait simplement à la main ; dans le cas de Rook avec une OSD par nœud, il n'y a pas de problèmes particuliers, mais des problèmes de montée séquentielle se posent si OSD > 1 par nœud.
Bien sûr, ces problèmes sont résolvables, mais nous utilisons Rook pour simplifier, et nous avons en fait une complexité accrue.
La complexité de la définition des limites pour les démons ceph
Pour une installation baremetal, il est assez facile de calculer les ressources nécessaires pour le cluster — des formules et des études existent. Si vous utilisez des CPU faibles, vous devrez tout de même effectuer une série de tests de performance, découvrir ce qu'est Numa, mais c'est tout de même plus simple que dans Rook.
Dans le cas de Rook, en plus des limites de mémoire qui peuvent être calculées, la question de la définition de la limite CPU se pose.
Vous devrez vous donner du mal pour les tests de performance. En cas de valeurs limites trop basses, vous obtiendrez un cluster lent, et si vous définissez unlim, vous obtiendrez une utilisation active du CPU lors du rééquilibrage, ce qui aura un impact négatif sur vos applications dans Kubernetes.
Problèmes d'interaction réseau v1
Pour ceph, il est recommandé d'utiliser un réseau 2x10 Gb. Un pour le trafic client et l'autre pour les besoins opérationnels de ceph (rééquilibrage). Si vous utilisez ceph sur baremetal, cette séparation est facile à configurer ; si vous utilisez Rook, la séparation par réseaux vous posera des problèmes, car tous les configurations de cluster ne permettent pas d'attribuer deux réseaux différents à un pod.
Problèmes d'interaction réseau v2
Si vous refusez de séparer les réseaux, le trafic de rééquilibrage de ceph saturera toute la bande passante et vos applications dans Kubernetes seront ralenties ou tomberont. Vous pouvez réduire la vitesse de rééquilibrage de ceph, mais ce faisant, vous prenez le risque accru qu'un deuxième nœud tombe du cluster pour des raisons de disques ou OOM, entraînant alors un état garanti de lecture seule pour le cluster.
Rééquilibrage prolongé — longues lenteurs des applications
Citation du post Ceph. Anatomie des catastrophes.
Performance du cluster de test :
Une opération d'écriture de 4 Ko prend 1 ms, avec une performance de 1000 opérations/seconde dans un thread.
Une opération de 4 Mo (taille de l'objet) prend 22 ms, avec une performance de 45 opérations/seconde.
Ainsi, lorsque un domaine sur trois échoue, le cluster se trouve pendant un certain temps dans un état dégradé, et la moitié des objets chauds se répartit entre différentes versions, ce qui entraîne que la moitié des opérations d'écriture commence par une récupération forcée.
Le temps de récupération forcée est estimé — les opérations d'écriture sur un objet dégradé.
D'abord, nous lisons 4 Mo en 22 ms, nous écrivons en 22 ms, puis nous écrivons 4 Ko de données en 1 ms. Au total, cela fait 45 ms pour une opération d'écriture sur un objet dégradé sur SSD, alors que notre performance normale était de 1 ms — une chute de performance de 45 fois.
Plus nous avons de pourcentage d'objets dégradés, plus la situation devient préoccupante.
Il s'avère que la vitesse de rééquilibrage est critique pour le bon fonctionnement du cluster.
Paramètres spécifiques des serveurs pour ceph
Ceph peut nécessiter un réglage spécifique de l'hôte.
Exemple : réglages sysctl et JumboFrame, certains de ces réglages peuvent avoir des effets négatifs sur votre charge.
La nécessité réelle de Rook reste à questionner.
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 propres serveurs, la gestion de ceph sera plus facile sans Kubernetes.
Vous louez des serveurs dans un hébergement low cost ? Vous allez avoir beaucoup de plaisir avec le réseau, ses latences et sa bande passante, ce qui influence clairement ceph de manière négative.
Total : L'implémentation de Kubernetes et l'implémentation du stockage sont des tâches différentes avec des considérations différentes et des solutions variées — les mélanger signifie faire un trade-off potentiellement dangereux pour l'un ou l'autre. Combiner ces solutions sera très difficile même à l'étape de conception, et il reste encore la période d'exploitation.
Liste des références utilisées :
Mais vous parlez de Ceph… est-il si bon ?
Ceph. Anatomie d'une catastrophe
Source : habr.com
