LINBIT SDS : DRBD dans Kubernetes
11 views
Skip to first unread message
Laurent Caillette
Mar 16, 2019, 7:17:31 AM3/16/19
to tec...@googlegroups.com
Je tombe plus ou moins par hasard sur l'annonce suivante : depuis mi-2018, LINBIT, l'éditeur de DRBD, intègre sa solution de réplication à Kubernetes. Avec l'association de Kubernetes et DRBD on peut monter son propre nuage avec des systèmes de fichiers répliqués. En gros c'est GCE (Google Compute Engine) sur //ton// infrastructure matérielle avec du code aux sources ouvertes.
J'avais déjà raconté mon expérience très positive avec `DRBD 8`. DRBD (Distributed Replicated Block Device) est une solution de réplication de périphérique en mode bloc intégrée au noyau Linux. Pour le prix d'un aller-retour réseau un volume se retrouve répliqué sur la machine d'à côté si on a choisi un fonctionnement primaire-secondaire. Si le disque ou contrôleur disque primaire tombe en panne, le secondaire prend alors le relai. Ça veut dire que n'importe quelle application qui écrit des fichiers se retrouve magiquement dotée d'une fonctionnalité de réplication. DRBD est fantastiquement bien conçu pour que la magie demeure complètement déterministe. À partir de `DRBD 9` on peut mélanger les réplications synchrones et asynchrones, et par exemple ajouter une réplication sur un site distant au fonctionnement précédemment décrit. L'utilisation de périphériques en mode bloc permet plein de bricolages, comme la réplication d'un volume chiffré, ou les instantanés ("snapshots") LVM. Je répète : DRBD est gratuit et les sources sont ouvertes.
Attention DRBD ne fait que de la réplication. Si on veut de la reprise sur panne automatique il faut également se préparer à des cas comme la partition de réseau. Une reprise sur panne naïve qui promeut automatiquement le secondaire en primaire peut se retrouver avec deux primaires qui évoluent indépendemment, exactement ce qu'on cherche à éviter. La solution c'est l'intégration à une solution comme Pacemaker qui garantit l'intégrité d'un groupe même en cas de partition réseau. On s'aperçoit très vite que les notions de groupe, d'état des nœuds et de réplication sont intimement liées.
Kubernetes est une solution d'orchestration pour grappe de serveurs, initialement développée en interne par Google, qui en a par la suite ouvert les sources, afin de promouvoir sa solution d'hébergement GCE qui supporte les descripteurs de déploiement de Kubernetes. Tu dis : je veux 50 serveurs NGINX et 1 MySQL avec 2 réplications et boum, le truc se débrouille pour instancier tout ça et à redémarrer les nœuds qui plantent. En dissociant l'infrastructure de la topologie applicative, Kubernetes met les déploiements massifs à portée de la ménagère de moins de 50 ans. Dans la même gamme que Kubernetes il y a aussi Docker Swarm, sur lequel je n'ai pas d'avis.
Arrivés là on a l'impression que Kubernetes est un super-Pacemaker qui juste oublié de faire ce qui nous intéresse : piloter DRBD. Au passage pourquoi faire du mode bloc si on a du MySQL répliqué ? Mais peut-être qu'on n'a pas envie de payer le surcoût du relationnel quand un système de fichiers suffit. Ou qu'on utilise une bibliothèque de persistance qui veut taper directement dans le système de fichiers. Jusqu'à récemment le périphérique en mode bloc avec réplication orchestrée par Kubernetes n'était possible que sur des infrastructures hébergées comme GCE mais aussi Digital Ocean, lequel a vraisemblablement codé son propre pilote Kubernetes.
Grâce aux efforts de LINBIT on peut maintenant déclarer des volumes DRBD qui seront montés comme des "PersistentVolumes" Kubernetes, avec plein d'options sympathiques. On peut alors déployer dans son propre nuage et maîtriser la localisation de ses données.
== Annexe
La [doc]
L'[annonce officielle]
La page d'accueil de [LINBIT SDS]
Les archives de Techos :
[DRBD (`1/5`) : haute disponibilité avec Linux]
[DRBD (`2/5`) : Périphérique en mode bloc]
[DRBD (`3/5`) : fonctionnement et mise en œuvre]
[DRBD (`4/5`) : Pacemaker]
[DRBD (`5/5`) : conclusion et perspectives]
Loïc Lefèvre
Mar 17, 2019, 4:50:43 AM3/17/19
to tec...@googlegroups.com
Salut Laurent,
sympa tout ca. Une question quand même qui me tarabusque, quand tu dis "Je répète : DRBD est gratuit et les sources sont ouvertes.". Autant, je comprends l'aspect gratuit, mais dans //ce contexte// (couche très basse), quel est le niveau d'importance du fait que les sources sont ouvertes selon toi ? Quelle population serait sensible, encore une fois par rapport à cette brique de //très bas niveau// ?
Merci et bon week-end !!!
Loïc
ps : oui, K8s, c'est cool et le IaaS aussi !!!
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "techos".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse techos+un...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse tec...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/techos.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
Laurent Caillette
Mar 17, 2019, 9:16:31 AM3/17/19
to tec...@googlegroups.com
Salut Loïc,
Si les sources sont ouvertes, ça réduit grandement les chances que l'éditeur fasse des bêtises ; il sait que s'il en fait la sanction sera immédiate, des utilisateurs reprendront la main sur le projet. Un cas célèbre c'est Oracle qui a fait quelque chose qui n'a pas plu avec Hudson, lequel a été fourché aussitôt pour donner Jenkins. Un autre cas c'est MySQL fourché en MariaDB. Pour changer d'éditeur, on a Microsoft qui a racheté Xamarin et arrêté le développement du compilateur Java-AOT, lequel a été fourché en RoboVM.
Le fait que la brique soit de bas niveau ne change rien. Si on te casse un bout de ton architecture ça fait toujours mal. Si tu mets de l'OSS partout tu limites le risque, pas la peine de se poser la question. La population sensible à ce genre de finesse ? Les professionnels qui se sont déjà brûlés les doigts et qui réfléchissent à deux fois avant d'installer un pilote propriétaire. D'ailleurs il y a des options dans Debian/Ubuntu pour empêcher ça, ce n'est pas moi qui l'ai inventé. Si tu installes un pilote propriétaire pour aller un peu plus vite ce n'est pas grave. Sinon c'est le moment de réviser ton archi. Après il y a d'autres considérations sur l'auditabilité du code, la sécurité, les temps de réponse pour obtenir un correctif. Si tu as les sources tu peux corriger d'abord et demander à officialiser le correctif plus tard.
Et oui le IaaS bien sûr c'est génial, une fois que tu as des garanties sur ta capacité à déménager, y compris vers une infrastructure auto-hébergée. Par exemple imagine une application dans GCE parce que c'est rapide et pas cher. Mais voilà qu'une réglementation impose une certaine localisation des données, mais les zones géographiques fournies par Google ne permettent pas un tel choix. Si tu as une solution de repli vers des serveurs dédiés OVH tu es sauvé. Sinon tu fais quoi ? S'obliger à concevoir une architecture sans composants propriétaires augmente les chances de pas en avoir "un bout qui reste coincé" dans la tuyauterie magique d'un hébergeur particulier.
Un petit mot gentil pour Oracle : j'ai vu que VirtualBox 6 améliorait les fonctionnalités d'export de VM pour un hébergement chez Oracle. J'espère de tout cœur qu'ils auront du succès. J'ai déjà dit tout le bien que je pensais de VirtualBox, si Oracle fait du pognon avec ils auront une bonne raison de continuer ce produit. Il y a plein de trucs à faire dans la virtualisation, surtout pour un éditeur qui construit ses propres serveurs.
Bon week-end tout le monde. J'ai encore une chance de ne pas le passer entièrement devant l'ordi.
Laurent Caillette
Mar 18, 2019, 6:27:17 AM3/18/19
to tec...@googlegroups.com
En lisant des trucs sur Kubernetes je tombe sur l'entrevue d'un mec de Gravitational qui raconte des trucs intéressants sur Kubernetes/etcd. Sur la page d'accueil de Gravitational :
"Deploy and update Kubernetes apps on 3rd party clouds, private environments behind firewalls, and even in air-gapped server rooms."
Des fois je suis fier de ne rien inventer. Gravitational édite Teleport, une solution d'authentification/autorisation pour administrer des grappes de serveurs. Teleport s'adresse à des clients qui doivent répondre à des normes sévères, et comme par hasard les sources sont ouvertes et le produit supporte le nuage auto-hébergé.
Reply all
Reply to author
Forward
0 new messages