Dans cet article, Igor Kotenko, architecte en chef de Neoflex, partage son expérience de déploiement d'une plateforme de conteneurisation sur une infrastructure d'entreprise.
Les raisons pour lesquelles les entreprises choisissent généralement une solution sur site sont souvent non technologiques et souvent liées au financement. Quelqu'un essaie de réduire les coûts d'exploitation (payer pour des clouds externes) au profit de la capitalisation de l'entreprise (acheter ses propres serveurs), quelqu'un a déjà de solides ressources matérielles et souhaite les utiliser dans une architecture de microservices.
Avant de passer aux détails de mise en œuvre, passons aux termes.
Le terme «nuages» est considéré comme très encombré. Il est courant de faire la distinction entre différents types de solutions cloud:
- Infrastructure as a Service (IAAS) - matériel (généralement virtuel);
- Logiciel en tant que service (SAAS), par exemple, DBAS - base de données en tant que service;
- Plateforme en tant que service (PAAS);
- Application en tant que service (AAAS).
Dans le même temps, rien n'empêche les couches de s'appuyer les unes sur les autres. De toute évidence, il y aura une infrastructure sous la plate-forme ou le logiciel.
Il existe une certaine confusion à propos du terme «nuages privés». Parfois, cela s'appelle des clouds sur site, parfois déployés sur une infrastructure louée avec une isolation complète de votre segment de réseau. Il y avait même une mention de machines virtuelles avec mémoire et disques cryptés, tandis qu'un vidage de la mémoire ne donnera pas au fournisseur l'accès à vos informations. Dans cet article, nous aborderons les solutions déployées sur site.
Lors de l'introduction de clouds privés, on s'attend à ce qu'ils soient identiques aux clouds publics, mais seulement moins chers, plus sécurisés et plus fiables. Par conséquent, beaucoup de gens pensent que les clouds privés sont a priori meilleurs. Souvent, les experts déploient simplement la version sélectionnée de Kubernetes ou d'Openshift et pensent que c'est là que leur travail est terminé.
Ce que les entreprises s'attendent à obtenir lors de la mise en œuvre de clouds sur site:
- Faible coût des ressources. Parce que vous ne payez que ce que vous utilisez.
- La possibilité d'ajouter et de restituer des ressources le plus rapidement possible.
- Tolérance aux pannes. Le serveur s'est écrasé, un autre a été automatiquement donné à la place.
- Faible coût de maintenance.
Comment cela est-il réalisé dans les clouds publics?
En règle générale, en raison de l'automatisation des processus, des économies d'échelle (moins chères en vrac) et du partage des ressources entre différents consommateurs.
Regardons ces promesses dans le contexte des clouds privés.
1. Faible coût des ressources par rapport aux infrastructures conventionnelles.
En fait, il n'en est rien. Le même logiciel a été déployé sur les mêmes machines, mais dans des conteneurs. D'après notre expérience, au contraire, davantage de ressources sont gaspillées.
2. Capacité d'augmenter et de diminuer les ressources très rapidement.
Non. Pour vous développer, vous devez soit garder la réserve chaude des licences matérielles et logicielles inactives, soit d'abord jeter quelque chose d'inutile. Vous pouvez mettre des ressources hors d'usage, mais elles seront alors inactives.
3. Tolérance aux pannes.
Oui, mais il y a de nombreuses nuances. Disons que le serveur est en panne. Où puis-je en obtenir un autre? Comment le déployer et l'ajouter rapidement à un cluster? Si vous n'êtes pas Amazon, vous ne disposez pas d'une offre infinie de ressources.
4. Faible coût de l'assistance.
Nous avons ajouté au moins une couche supplémentaire (plateforme de conteneurisation), plusieurs nouveaux systèmes. Nous avons besoin de spécialistes dotés de nouvelles compétences. D'où viendront les économies?
Examinons ces questions plus en détail. Il est important de se rappeler que les clouds privés doivent coexister avec les systèmes hérités existants. Les organisations sont obligées de maintenir l'infrastructure des systèmes existants en parallèle, en organisant un environnement informatique hybride.
Naturellement, 99% du système n'est pas construit à partir de zéro. En règle générale, même avant la mise en œuvre d'une solution PAAS, il existe un ensemble de processus et d'automatisations pour prendre en charge l'ancienne infrastructure. Processus DevOps, planification et propriété des ressources, surveillance, mises à jour logicielles, sécurité - toutes ces questions doivent être coordonnées et modifiées lors de la mise en œuvre d'un cloud privé.
Comment les processus DevOps évoluent
En règle générale, avant d'implémenter votre propre PAAS, l'approche de création de DevOps est basée sur l'utilisation de systèmes d'automatisation de configuration tels que Ansible ou Chef. Ils vous permettent d'automatiser presque tous les processus informatiques de routine, souvent à l'aide de bibliothèques de scripts prêtes à l'emploi. Cependant, les plates-formes de conteneurisation promeuvent une approche alternative - une «infrastructure immuable». Son essence n'est pas de changer le système existant, mais de prendre une image virtuelle prête à l'emploi du système avec de nouveaux paramètres et de remplacer l'ancienne image par une nouvelle. La nouvelle approche n'annule pas l'ancienne, mais force l'automatisation de la configuration dans la couche infrastructure. Bien entendu, les systèmes hérités nécessitent de conserver l'ancienne approche.
Parlons de la couche infrastructure
La norme de facto en informatique est l'utilisation d'une infrastructure virtuelle. Comme le montre la pratique, l'option la plus courante consiste à utiliser vSphere. Il y a de nombreuses raisons à cela, mais il y a aussi des conséquences. Dans notre pratique, les problèmes fréquents de sursouscription en termes de ressources (tentative de coudre sept casquettes à partir d'une même peau) ont été aggravés par le manque quasi total de contrôle et d'influence sur ce processus de la part des responsables de la performance de la solution. La délimitation des domaines de responsabilité dans les divisions de l'entreprise, la formalisation des procédures de demande de ressources et les différents objectifs de la direction des divisions ont entraîné des problèmes dans l'environnement produit et des tests de charge incohérents. À un moment donné, notre service de développement a même créé un outil virtuel de mesure de la performance de base,pour diagnostiquer rapidement le manque de ressources matérielles.
Il est évident qu'une tentative de placer une plateforme de conteneurisation sur une telle infrastructure apportera de nouvelles couleurs au chaos existant.
La question de savoir si une plate-forme de conteneurisation sur site a besoin d'une infrastructure virtuelle ou est-il préférable de la mettre à nu (sur des serveurs de fer) a été discutée depuis longtemps et assez largement. Les articles sollicités par les fabricants de systèmes de virtualisation affirment qu'il n'y a pratiquement pas de pertes de performances et que les avantages sont trop importants. D'autre part, il existe des résultats de tests indépendants qui indiquent une perte de performance d'environ 10%. N'oubliez pas le coût des licences vSphere. Par exemple, pour installer une version gratuite de Kubernetes sur du matériel bon marché juste pour économiser de l'argent et payer vSphere? Décision controversée.
Il convient de mentionner une solution de virtualisation d'infrastructure open source, par exemple Open Stack. En général, il était considéré comme une solution nécessitant un investissement sérieux dans l'équipe. Il existe des statistiques sur le réseau selon lesquelles la taille de l'équipe de support d'Open Stack est de 20 à 60 personnes. Et c'est distinct du support de la plateforme de conteneurisation! Il existe peu de spécialistes de ce type sur le marché, ce qui augmente leur coût. Ces investissements ne rapportent généralement que de très gros volumes de ressources.
Il est important de considérer la présence de spécialistes aux compétences uniques dans l'entreprise. Malheureusement, les installations Kubernetes sans système d'exploitation, malgré les avantages de la transparence et la réduction des coûts de licence, sont souvent entravées, par exemple, par le manque d'outils d'automatisation d'installation appropriés. Nous espérons que l'avenir appartient à cette approche.
Un autre aspect qui influence le choix entre les installations virtuelles et bare-metal est l'organisation des serveurs de fer.
En règle générale, une organisation achète des serveurs à des fins spécifiques. Vous pouvez louer des serveurs dans le centre de données (à partir de ce qu'ils proposent), vous pouvez standardiser et unifier la nomenclature (simplifier la redondance des composants), vous pouvez économiser sur le matériel (de nombreux serveurs peu coûteux), vous pouvez économiser de l'espace rack. Différentes approches dans différentes organisations. En général, ce sont soit des serveurs puissants avec un grand nombre de cœurs et de mémoire, soit un volume relativement petit, soit un méli-mélo préfabriqué. Mais n'oubliez pas les besoins des systèmes existants. À ce stade, nous rencontrons à nouveau une contradiction dans les concepts. L'idéologie de Kubernetes est beaucoup de matériel peu coûteux et de préparation à ses échecs. Le serveur est tombé - peu importe, vos services sont passés à un autre. Les données sont fragmentées (dupliquées) et non liées à un conteneur. Idéologie héritée - redondance au niveau matériel. Matrices RAID,racks de disques, alimentations multiples sur le serveur, remplacement à chaud. Concentrez-vous sur une fiabilité maximale. Il peut être déraisonnablement coûteux de miser sur une telle infrastructure Kubernetes.
, …
Si une entreprise possède des serveurs hautes performances avec de nombreux cœurs intégrés, il peut être nécessaire de les répartir entre différents consommateurs. Ici, vous ne pourrez plus vous passer d'un système de virtualisation. Dans le même temps, il est nécessaire de prendre en compte la possibilité d'une panne du serveur ou d'un arrêt pour maintenance. L'arithmétique est simple: si vous avez deux serveurs, si l'un d'entre eux tombe en panne, vous avez besoin de 50% de réserve de marche sur chacun; si - 4 serveurs, si l'un échoue, vous avez besoin de 25% de réserve. À première vue, tout est simple - vous avez besoin d'un nombre infini de serveurs, la panne de l'un d'entre eux n'affectera pas la capacité totale et vous n'avez rien à réserver. Hélas, la taille des ressources d'un hôte ne peut pas être considérablement réduite. Au minimum, il doit contenir tous les composants associés, que la terminologie Kubernetes appelle «pods». Et, bien sûr, lors de l'écrasement dans des serveurs plus petits,les frais généraux des services de la plate-forme elle-même augmentent.
Pour des raisons pratiques, il est souhaitable d'unifier les paramètres d'hôte de la plate-forme. Dans les exemples proches de la réalité, il existe 2 centres de données (la prise en charge du scénario DR signifie au moins 50% de réservation de ressources en termes de capacité). Ensuite, les besoins de l'organisation en ressources de la plateforme de conteneurisation sont déterminés et la possibilité de la placer sur des hôtes standards ou virtuels. Recommandation Kubernetes - pas plus de 110 pods par nœud.
Ainsi, pour déterminer la taille du nœud, vous devez tenir compte des éléments suivants:
- Il est souhaitable de rendre les nœuds égaux;
- Les nœuds doivent s'adapter à votre matériel (pour les machines virtuelles - multiples, N virtuels pour une pièce de matériel);
- Si un nœud échoue (pour l'option avec infrastructure virtuelle - un serveur de fer), vous devez disposer de suffisamment de ressources sur les nœuds restants pour y déplacer les pods;
- Il ne peut pas y avoir trop de pods (> 110) sur un nœud;
- Toutes choses étant égales par ailleurs, il est souhaitable d'agrandir les nœuds.
Ces types de fonctionnalités doivent être pris en compte dans tous les aspects de l'architecture.
Journalisation centralisée - comment choisir parmi plusieurs options?
Surveillance - peut-être que votre système de surveillance existant ne fonctionnera pas, gardera-en deux ou migrera-t-il vers un nouveau?
La plate-forme met à jour une nouvelle version - régulièrement ou seulement lorsque cela est absolument nécessaire?
Équilibrage tolérant aux pannes entre deux centres de données - Comment?
Architecture de sécurité, interaction avec les systèmes hérités - il existe des différences par rapport aux clouds publics. Il est possible de recommander de construire des systèmes pour qu'il y ait une possibilité de migration vers les clouds publics, mais cela compliquera la solution.
La planification, l'allocation et la propriété des ressources pour les clouds publics et privés diffèrent peu. La principale différence est la quantité limitée de ressources. Si dans les clouds publics, il est possible à tout moment de prendre des ressources supplémentaires nécessaires, par exemple pour des tests de charge, alors sur site doit planifier soigneusement la séquence de leur utilisation. Cela signifie que vous pouvez avoir des lancements de nuit et, par conséquent, le travail des employés des 2e et 3e lignes augmentera à des heures inopportunes. Rien de nouveau pour ceux qui sont seuls, mais un goût amer de déception pour les miracles qui attendent l'adoption du cloud privé.
"Les cadres décident de tout"
Lors de la planification de la mise en œuvre d'une plateforme de conteneurisation sur site, il faut tout d'abord des spécialistes dotés de compétences uniques. Il n'y en a manifestement pas assez sur le marché du travail actuel. De plus, sans avoir d'expérience dans une telle mise en œuvre, il est même difficile de dresser une liste de tous les spécialistes nécessaires.
Par exemple, pour que la plate-forme fonctionne, vous devez sélectionner et installer un système de stockage. Quel que soit le système que vous choisissez (CEPH ou Portworx), il sera essentiel pour la plate-forme. Tout le monde sait qu'un administrateur est nécessaire pour maintenir une base de données. De même, un système de stockage de données a besoin d'un spécialiste distinct. Malheureusement, personne n'y pense avant d'implémenter le système! Notez que la différence entre les administrateurs pour différents produits est significative - comparable à la différence entre Oracle DBA et MS SQL DBA. Vous aurez besoin d'au moins deux personnes pour chaque rôle: les employés partent en vacances, tombent malades et même, Dieu nous en préserve, démissionnent. Et ainsi de suite pour chaque compétence, et la liste des compétences requises pour soutenir la solution est impressionnante.
Je voudrais immédiatement mettre en garde contre les tentatives de croiser toutes les compétences chez certains soldats universels. Leur coût, leur rareté et leurs risques de perte dépassent toutes les limites raisonnables.
Une fois de plus, la maintenance du cloud est un processus complexe. Les entreprises du cloud ne mangent pas leur pain pour rien: là-bas, derrière le brouillard nuageux, il y a beaucoup de technologie et de main-d'œuvre investie.
Bien entendu, l'utilisation de services de conseil peut accélérer considérablement la mise en œuvre de la plateforme. Des partenaires expérimentés vous aideront à éviter de nombreuses erreurs, à établir des processus et à former votre équipe. Cependant, si vous hébergez des services critiques pour votre entreprise sur la plateforme, il est tout aussi important de fournir un support et un développement de qualité. De plus, pour le moment, tous les systèmes existants sur le marché se développent activement, de nouvelles technologies apparaissent, de nouvelles versions de la plateforme peuvent nécessiter la migration de processus complexes et des tests sérieux avant la mise à jour. Une équipe de soutien solide est nécessaire pour assurer le fonctionnement fiable du système. Et vous aurez besoin d'une telle équipe sur une base continue.
Quand devriez-vous envisager de mettre en œuvre une plateforme de conteneurisation sur site?
Tout d'abord, il est nécessaire d'évaluer le rapport entre investissement et retour, le volume des coûts pour le matériel et les employés. Il doit y avoir soit de bonnes raisons pour ne pas pouvoir vivre dans des clouds publics, soit des besoins en ressources vraiment sérieux. Autrement dit, si environ 100 cœurs suffisent pour une organisation et que vous n'êtes pas prêt à étendre l'équipe de support à des dizaines de personnes, vous devriez probablement vous concentrer sur les clouds publics ou sur des configurations simples avec des serveurs d'applications. Une équipe minimale est requise pour prendre en charge la plate-forme et le coût peut ne pas être rentable. Cependant, avec des ressources évolutives et une automatisation compétente de tous les processus, l'avantage d'une solution privée peut être très important. Plusieurs centaines de nœuds peuvent être maintenus avec la même commande.
Un autre critère de sélection est la variabilité des besoins en ressources de calcul. Si les processus métier d’une entreprise créent une charge de ressources plus ou moins égale, il est plus rentable de développer sa propre infrastructure. Si vous avez besoin d'utiliser de grandes capacités, mais rarement, envisagez des clouds publics ou hybrides.
Dans tous les cas, lors du choix de solutions sur site, connectez-vous à un travail sérieux et systématique, préparez-vous à investir dans l'équipe. Passez du simple au complexe. Soyez attentif au calendrier de mise en œuvre et soyez particulièrement prudent lors de la mise à niveau vers de nouvelles versions de plate-forme. Utilisez l'expérience tirée des erreurs des autres, pas la vôtre.
Merci d'avoir lu cet article, nous espérons que vous trouverez l'information utile.