Cet article est partagé par la communauté Huawei Cloud « Huawei Cloud Distributed Cloud Native UCS aide MetaERP à créer des services distribués à haute disponibilité au niveau de l'entreprise » , auteur : Cloud Container Future.
introduction
Huawei Cloud est récemment devenu le seul fabricant chinois sélectionné dans le rapport « Forrester Wave™ : Multicloud Container Platforms, Q4 2023 », avec de solides performances sur le marché. L'UCS cloud natif distribué Huawei Cloud est un service clé dans cette évaluation, et sa valeur dans les applications de conteneurs multi-cloud a été unanimement reconnue par l'évaluation. Dans le même temps, début décembre, UCS a réussi l'évaluation des capacités natives du cloud distribué de l'Académie chinoise des technologies de l'information et des communications, et Huawei Cloud est devenu le premier groupe d'entreprises à réussir l'évaluation des capacités natives du cloud distribué .
Pour UCS, outre la reconnaissance d'organisations faisant autorité, les pratiques de production de plus en plus à grande échelle de la part des utilisateurs finaux constituent la plus grande reconnaissance des capacités d'UCS. En particulier, les récents accidents fréquents de réseaux actifs à cluster unique ont attiré de plus en plus d'attention sur la reprise après sinistre et la multiactivité basée sur le multicluster, déclenchant une réflexion plus approfondie sur la disponibilité des services.
Dans cet article, nous présenterons en détail la reprise après sinistre et la pratique multiactive du multicluster UCS sur la base du cas d'application de production de Huawei MetaERP. MetaERP a des exigences commerciales complexes, une grande échelle de service et une haute disponibilité. La solution multicluster basée sur UCS, tout en étant compatible avec le pipeline d'origine à cluster unique, les outils d'exploitation et de maintenance et les vues de surveillance, fournit non seulement la capacité originale de reprise après sinistre à cluster unique basée sur les nœuds, AZ et d'autres défauts d'environnement traditionnels. , mais fournit également une reprise après sinistre en cas de panne globale du cluster et de panne logicielle propre à plusieurs clusters. Tout au long de la pratique de production, le retour le plus important des clients est que l'environnement de cluster gris introduit par la solution multicluster résout le problème des risques de mise à niveau locale d'un seul cluster et améliore considérablement la disponibilité du service.
formation technique
Avec la vulgarisation et l'application de la technologie cloud native avec Kubernetes comme noyau, de plus en plus de services de production à grande échelle s'exécutent sur la plate-forme Kubernetes. Il permet une expansion et une contraction pratiques des instances de conteneurs, une élasticité de charge extrême et une migration transparente des applications, aidant ainsi les utilisateurs à créer des applications cloud natives à grande échelle avec des exigences d'évolutivité élevées. De plus, les capacités de déploiement anti-affinité des nœuds et des AZ fournies par Kubernetes garantissent qu'il existe certaines instances disponibles pour fournir des services en cas de panne d'un seul nœud ou de l'ensemble de l'AZ, ce qui aide objectivement les utilisateurs à améliorer la disponibilité des applications.
Cependant, des cas récents de diverses pannes de cluster unique entraînant de graves défaillances commerciales ont causé de gros désagréments aux clients finaux. Un seul cluster Kubernetes a rencontré de sérieux défis dans de plus en plus de scénarios avec des exigences de haute disponibilité. Kubernetes lui-même est une plate-forme logicielle. Les pannes potentielles de ses composants de plan de contrôle et de plan de données sont garanties par le fabricant, et la probabilité qu'elles se produisent est faible, mais une fois qu'elles se produisent, elles auront un impact énorme. En particulier, il y a eu récemment de nombreux cas de pannes majeures dans l'industrie où la mise à niveau sur place de la version Kubernetes d'un cluster unique était anormale, entraînant l'indisponibilité de tous les services déployés dans le cluster et déclenchant des pannes de service mondiales.
La raison fondamentale de ce phénomène est l’existence d’un rayon d’explosion infini. C'est comme mettre tous ses œufs dans un panier solide : une fois qu'il y a un problème avec le panier, aucun œuf ne peut survivre. Le pire, c'est qu'à mesure que l'entreprise se développe, ce panier, qui était encore solide et utilisable au début, s'use de plus en plus avec le temps, mais au cours du processus, de plus en plus d'œufs sont constamment remplis, ce qui fait que le panier est cassé. il faudra y faire face tôt ou tard. L’idée intuitive et fondamentale pour résoudre ce genre de problème est de réduire le rayon d’explosion et de mettre les œufs dans plusieurs paniers.
En théorie, ce principe est simple : ne pas développer un seul cluster verticalement, mais augmenter le nombre de clusters horizontalement. Mais ce n'est pas si simple en pratique. L'une des principales raisons pour lesquelles les utilisateurs de MetaERP ont choisi de déployer de manière centralisée un grand nombre de services dans de grands clusters au début était de réduire les coûts d'exploitation et de maintenance de la plateforme. L'exploitation et la maintenance d'un seul cluster Kubernetes ont consommé beaucoup d'énergie. énergie de l'équipe. En théorie, plusieurs clusters Kubernetes entraîneront des problèmes de gestion et de maintenance opérationnelle. Le coût augmente de manière linéaire. Dans la pratique des applications d'entreprise à grande échelle représentées par MetaERP, nous sommes confrontés à de multiples problèmes complexes : comment contrôler de manière flexible la charge et le déploiement, la mise à niveau et l'élasticité de plusieurs objets de ressources sur plusieurs clusters ; comment gérer le trafic entrant de plusieurs clusters. ; comment contrôler plusieurs clusters. Trafic interne du cluster. Globalement, comment traduire la disponibilité théorique multicluster en valeur réelle pour les clients. La chose la plus importante est que le principe de MetaERP pour les fonctionnalités ci-dessus est que la capacité multi-cluster est compatible avec son utilisation originale en cluster unique, y compris les outils de ligne de commande d'origine en cluster unique, les pipelines CICD, les API de cluster appelées par les composants d'extension, etc. ., restent aussi inchangés que possible. Dans le même temps, il maintient une vue unifiée de la gestion des ressources, de la surveillance et de l'exploitation et de la maintenance pour les multi-clusters orientés applications, etc. La solution multicluster d'UCS répond une par une aux questions ci-dessus.
plan
Récupération des pannes dans les environnements traditionnels tels que les nœuds et les zones de disponibilité
Premièrement, la gestion des ressources multiclusters Karmada intégrée à UCS permet aux utilisateurs de distribuer dynamiquement les charges de travail sur plusieurs clusters gérés par flotte en fonction de politiques. Les nœuds gérés par chaque cluster proviennent de différentes zones de disponibilité (AZ), de sorte que chaque instance de la charge est intelligemment répartie dans différentes zones de disponibilité, permettant ainsi d'obtenir une haute disponibilité dans toutes les zones de disponibilité.
Lorsqu'un nœud échoue, les instances de chargement sur ce nœud échoueront complètement. À ce stade, le trafic accédant au service sera non seulement redistribué vers les copies correspondantes des autres nœuds du cluster, mais également vers les copies correspondantes dans d'autres clusters, garantissant ainsi la disponibilité globale du service.
Lorsqu'une zone de disponibilité échoue, tous les nœuds de la zone échouent, ce qui rend les instances de chargement indisponibles. Le trafic est automatiquement transféré vers d'autres clusters, c'est-à-dire des réplicas correspondants dans d'autres AZ, et l'activité de l'utilisateur n'est pas du tout affectée.
Grâce à l'analyse ci-dessus, la solution multicluster UCS couvre la disponibilité des services au niveau AZ et au niveau des nœuds fournie par le cluster unique d'origine de MetaERP. Elle ajoute également des fonctions qu'un seul cluster n'a pas besoin pour aider à améliorer globalement la disponibilité de l'entreprise.
Récupération des pannes logicielles du cluster
Outre les défaillances environnementales, un autre impact potentiel sur l'entreprise est la défaillance du logiciel du cluster lui-même. Bien que la probabilité de telles défaillances soit faible, une fois qu'elles se produisent, elles auront un impact important sur l'entreprise. Dans les applications client, il y a eu des problèmes tels qu'une surcharge du serveur Kube-api entraînant une défaillance du cluster, des anomalies du plan de données du cluster entraînant un échec de création normale de la charge et d'autres problèmes. Dans un environnement de cluster unique, basé sur des mécanismes conventionnels de détection de pannes et de commutation, les moyens efficaces que la plate-forme et l'entreprise peuvent prendre sont très limités.
Basé sur la solution multicluster UCS, lorsqu'une panne de cluster est détectée, Karmada peut basculer dynamiquement le trafic ciblant le cluster défaillant vers le backend de service d'un autre cluster disponible. Dans le même temps, selon la configuration de la stratégie, les instances de charge peuvent être migrées dynamiquement du cluster défaillant vers d'autres clusters disponibles. Il aide également les utilisateurs à juger l'entreprise par eux-mêmes. En cas d'urgence, lorsqu'un cluster s'avère défectueux, l'administrateur peut isoler toute la charge d'un cluster pour isoler rapidement et efficacement les pannes et maximiser la disponibilité globale de l'entreprise. .
Récupération des erreurs de mise à niveau du cluster
En pratique, la solution multicluster UCS apporte le plus grand avantage à l'activité MetaERP en assurant le processus de mise à niveau du cluster. Dans les mises à niveau d'entreprise, il est courant d'introduire diverses stratégies de mise à niveau en niveaux de gris, mais lors de la mise à niveau de plates-formes de cluster, il est assez difficile d'appliquer ce mécanisme en niveaux de gris. Si la version du cluster à mettre à niveau présente des problèmes ou est incompatible avec les services existants, les services existants peuvent être affectés par la mise à niveau. Par exemple, une incompatibilité du certificat principal de mise à niveau du cluster, des modifications du système de fichiers du conteneur affectant l'ordre de chargement des packages Jar provoquant des exceptions de démarrage de l'application, ou des chemins de mise à niveau inappropriés pour la version du cluster de réseau en direct provoquant l'échec du démarrage normal du cluster, etc., peuvent affecter le l'activité de l'ensemble du cluster.
Grâce à la solution multicluster UCS, les utilisateurs peuvent sélectionner un cluster comme environnement indépendant en niveaux de gris pour la mise à niveau, puis mettre à niveau un autre cluster une fois que l'acceptation commerciale finale a confirmé que la mise à niveau a réussi. Cette méthode évite la situation dans laquelle tous les services sont indisponibles en raison d'un échec de mise à niveau du cluster dans un scénario de cluster unique.
Voici les étapes détaillées :
1. Effectuez les mises à niveau du cluster dans les délais impartis pour l'entreprise. Tout d'abord, sélectionnez un cluster à mettre à niveau comme environnement en niveaux de gris et configurez les règles pour basculer tout le trafic vers un autre cluster.
2. Mettez à niveau les composants de la plate-forme du cluster en niveaux de gris et observez le fonctionnement normal de chaque composant.
3. Observez le fonctionnement de la charge dans le cluster en niveaux de gris pour vous assurer que la charge correspond à l'environnement du cluster en niveaux de gris et fonctionne normalement.
4. Basculez une petite quantité de trafic vers le cluster en niveaux de gris, effectuez une libération en niveaux de gris d'une partie de la charge et observez l'état d'exécution du service du point de vue commercial final. Lorsqu'il est confirmé que le cluster en niveaux de gris fonctionne normalement en fonction de l'activité, tout le trafic sera progressivement basculé vers le cluster en niveaux de gris.
5. Effectuez le processus de mise à niveau en niveaux de gris sur un autre cluster, en vous assurant que chaque cluster subit des tests et une validation similaires.
Dans les deuxième à quatrième étapes ci-dessus, si un problème survient, le cluster en niveaux de gris peut être réparé immédiatement sans affecter l'accès de l'utilisateur final. Grâce à cette méthode de mise à niveau en niveaux de gris du cluster, il est garanti que les problèmes survenant lors du processus de mise à niveau n'affecteront pas les services utilisateur.
Politique multiactive unifiée pour le trafic entrant et interne
Contrairement aux scénarios traditionnels de reprise après sinistre et d'actif-actif, qui reposent uniquement sur le contrôle du trafic entrant, UCS est intégré à une grille de services hautes performances et peut effectuer des actions de trafic cohérentes au sein de l'application. Dans un scénario de reprise après sinistre, la commutation est effectuée sur la base d'une politique de trafic unifiée via le proxy de grille et la passerelle d'entrée. Pour un même service cible, que le trafic provienne d'un accès interne au service ou d'un accès externe, les instances anormales peuvent être isolées selon des politiques unifiées pour garantir la haute disponibilité du service.
La migration du trafic accompagne la migration des applications avec de multiples fonctionnalités
Dans de nombreuses solutions de reprise après sinistre, le simple changement de trafic peut sembler résoudre le problème principal, mais en réalité, il existe encore des imperfections. Dans le scénario susmentionné, après avoir isolé le trafic d'une instance de cluster marquée comme non saine, le nombre de backends fournissant réellement des services peut être inférieur au nombre initialement attendu par l'utilisateur, ce qui entraînera objectivement une altération de la capacité globale du service. Cela ne répond évidemment pas aux exigences métiers de MetaERP en matière de haute disponibilité. La solution de migration des pannes multicluster fournie par UCS ne se limite pas à la commutation du trafic, mais combine également la migration de charge entre clusters et la migration des données en fonction de scénarios d'utilisateur réels pour créer un mécanisme de réponse aux pannes en trois dimensions. Autrement dit, en plus d'assurer la continuité des activités grâce à la commutation du trafic, la gestion de la charge dans plusieurs clusters est également utilisée pour migrer les charges des clusters anormaux vers d'autres clusters afin de garantir qu'il y a toujours un nombre suffisant d'instances de charge pour fournir des services aux utilisateurs. Disponibilité des services. Cette méthode qui combine migration de trafic et migration de charge garantit la disponibilité des services utilisateurs et garantit que la qualité globale du service répond aux attentes des utilisateurs.
Expérience cohérente dans un seul cluster, exploitation et maintenance simplifiées
Dans la solution de reprise après sinistre multicluster UCS, la gestion des pannes est effectuée au niveau de la granularité du cluster. Contrairement à la solution à cluster unique qui ne peut effectuer la détection et l'isolation des pannes qu'au niveau de l'instance, du nœud ou de la granularité AZ, l'ensemble du cluster peut être rapidement isolé pour obtenir une isolation rapide des défauts, améliorant ainsi la fiabilité de l'application. Toutefois, la fourniture de ces capacités n'augmente pas la complexité de gestion, d'exploitation et de maintenance pour l'utilisateur. La flotte multicluster UCS fournit des API et des modèles d'objet entièrement compatibles avec les clusters uniques, permettant aux outils de la plate-forme d'exploitation et de maintenance d'origine d'un cluster unique d'être connectés de manière transparente. Le pipeline d'origine de MetaERP peut être connecté à l'API Fleet sans trop de modifications pour réaliser la création et la mise à niveau des ressources Kubernetes telles que les déploiements de cluster, le service, le secret, le ConfigMap, le rôle et le RoleBinding.
Dans le même temps, UCS s'appuie sur les capacités de gestion des ressources multiclusters de Karmada et distribue les ressources au niveau de la flotte à plusieurs clusters gérés par flotte conformément aux politiques configurées par l'utilisateur. Le personnel d'exploitation et de maintenance de MetaERP peut utiliser l'outil de ligne de commande Kubernetes d'origine pour effectuer une gestion unifiée de l'exploitation et de la maintenance des ressources de la flotte, ce qui est fondamentalement la même que l'expérience d'un cluster unique. De plus, la vue de surveillance au niveau de la flotte orientée applications est également cohérente avec la surveillance métier au sein d'un seul cluster.
L'adoption de plusieurs clusters brise non seulement les limitations de capacité d'un seul cluster, mais augmente également considérablement la capacité globale de la plateforme, répondant ainsi aux besoins de croissance à grande échelle de l'activité MetaERP.
Résumer
La solution multicluster de MetaERP basée sur UCS couvre non seulement la gestion des pannes de ressources et d'environnement dans les scénarios traditionnels de reprise après sinistre, mais inclut également la capacité de gérer la plateforme elle-même, les pannes logicielles et les processus de mise à niveau de la plateforme, améliorant considérablement la disponibilité globale de l'entreprise. . Cette solution ne se limite pas à la méthode de déploiement de plusieurs AZ dans la même région sur le cloud, mais peut également être appliquée de manière flexible aux environnements inter-régions, aux environnements multi-cloud et aux environnements cloud hybrides. Grâce à un déploiement basé sur un environnement distribué, il peut gérer efficacement la charge et le trafic de plusieurs clusters, réaliser une reprise après sinistre et une multiactivité dans un environnement cloud distribué et améliorer encore la disponibilité des services utilisateur.
Les fonctionnalités multiclusters présentées ici ne représentent qu'une partie des fonctions des produits UCS distribués cloud natifs. Le cloud distribué offre aux utilisateurs la flexibilité de distribuer les capacités du cloud à divers emplacements physiques en fonction de leurs scénarios. En même temps, il simplifie l'utilisation des utilisateurs grâce à une gestion, une exploitation et une maintenance unifiées sur le cloud. En tant que premier produit cloud distribué du secteur, l'UCS cloud natif distribué de Huawei Cloud utilise des méthodes cloud natives pour distribuer le matériel, les logiciels, l'infrastructure et les services du fabricant aux centres de données des utilisateurs, aux périphéries, à d'autres cloud et à d'autres emplacements afin de répondre aux besoins des utilisateurs. Exigences pour les scénarios d'application tels qu'une faible latence, le traitement local des données, la conformité de la résidence des données ou la reprise après sinistre et la multiactivité. Sur la base d'une gestion d'applications distribuées à haute disponibilité multi-cloud et multi-cluster, nous construisons un trafic dynamique unifié mondial, une configuration d'applications, une sécurité zéro confiance, DevOps, l'exploitation et la maintenance des applications et d'autres capacités sur la flotte multi-cluster pour répondre aux besoins. des utilisateurs de grandes entreprises telles que MetaERP Demande croissante de modernisation des applications.
Dans le même temps, Karmada, le composant central de la solution multicluster UCS, continue de mûrir en servant des scénarios clients distribués cloud natifs et a été officiellement promu projet d'incubation CNCF ce mois-ci. À l'avenir, Karmada continuera d'explorer l'innovation technologique dans le domaine du multi-cluster cloud natif, afin que les solutions multi-cloud basées sur Karmada puissent être plus profondément intégrées dans l'écosystème technologique cloud natif.
À l'avenir, UCS continuera à diriger le développement de plates-formes de conteneurs multi-cloud et aidera les utilisateurs à réaliser un déploiement et une gestion plus efficaces et plus intelligents des applications cloud natives.
référence:
- 《Forrester Wave™ : Plateformes de conteneurs multicloud, T4 2023》测评：https://www.huaweicloud.com/news/2023/20231226154355792.html
- Évaluation des capacités natives du cloud distribué de l'Académie chinoise des technologies de l'information et des communications : https://mp.weixin.qq.com/s/ba7kIS8C4p-Ue3L3DgwWtA
- Karmada a été promue au projet d'incubateur CNCF : https://www.cncf.io/blog/2023/12/12/karmada-brings-kubernetes-multi-cloud-capabilities-to-cncf-incubator/
Cliquez pour suivre et découvrir les nouvelles technologies de Huawei Cloud dès que possible~
Broadcom a annoncé la fin du programme de partenariat VMware existant . Le site B s'est écrasé deux fois, l'incident de niveau 1 de Tencent "3.29"... Faisant le point sur les dix principaux incidents de temps d'arrêt en 2023, Vue 3.4 "Slam Dunk" publié, Yakult a confirmé la fuite des données 95G MySQL 5.7, Moqu, Li Tiaotiao... Bilan des projets et sites Web (open source) qui seront "arrêtés" en 2023 Le "2023 China Open Source Developer Report" est officiellement publié. Retour sur l'EDI il y a 30 ans : seulement TUI, couleur de fond lumineuse …… Julia 1.10 officiellement publiée Rust 1.75.0 publiée NVIDIA a lancé la GeForce RTX 4090 D spécialement en vente en Chine