La haute disponibilité et la continuité des activités sont cruciales pour que les applications et les services restent opérationnels.
Les grappes à haute disponibilité permettent aux services essentiels de continuer à fonctionner, même si les serveurs ou les composants matériels tombent en panne.
SUSE Linux offre un ensemble d’outils robustes pour créer et gérer ces grappes.
Dans cet article, nous explorons l’état actuel de la mise en grappe dans SUSE Linux, en nous concentrant sur les technologies clés telles que Pacemaker, Corosync, DRBD et d’autres.
Celles-ci, à quelques différences près, sont disponibles sur x86 et ppc64le.

Pacemaker : le cerveau de la grappe

Pacemaker est le moteur qui gère les grappes à haute disponibilité dans SUSE Linux.
Sa fonction principale est de gérer les ressources des clusters, en veillant à ce que les services critiques soient opérationnels et se rétablissent rapidement en cas de défaillance. Pacemaker surveille en permanence les ressources (bases de données, services Web, systèmes de fichiers, etc.) et, s’il détecte un problème, migre ces ressources vers d’autres nœuds de la grappe pour les maintenir en état de marche.
Pacemaker se distingue par sa flexibilité et sa capacité à gérer une grande variété de ressources.
Des simples services aux systèmes distribués plus complexes, il est capable de gérer la plupart des scénarios de haute disponibilité dont une entreprise peut avoir besoin.

Corosync : le système nerveux du cluster

Corosync est responsable de la communication entre les nœuds de la grappe.
Il veille à ce que tous les nœuds aient à tout moment la même vision de l’état de la grappe, ce qui est essentiel pour une prise de décision coordonnée.
Il gère également le quorum, qui détermine s’il y a suffisamment de nœuds actifs pour que la grappe fonctionne en toute sécurité.
Si le quorum est perdu, des mesures peuvent être prises pour éviter la perte de données ou même l’arrêt du service.

DRBD : l’épine dorsale des données

DRBD (Distributed Replicated Block Device) est une solution de réplication de stockage au niveau des blocs qui réplique les données entre les nœuds en temps réel.
Avec DRBD, les données d’un serveur sont répliquées sur un autre serveur presque instantanément, créant ainsi une copie exacte.
Ceci est particulièrement utile dans les scénarios où il est crucial que les données critiques soient toujours disponibles, même si un nœud tombe en panne.
Combiné à Pacemaker, DRBD permet aux services de continuer à fonctionner en ayant accès aux mêmes données, même s’ils se trouvent sur des nœuds différents.

Autres technologies clés dans les grappes SUSE Linux

En plus de Pacemaker, Corosync et DRBD, il existe d’autres technologies essentielles pour construire des clusters robustes sur SUSE Linux :

• SBD (Storage-Based Death) : SBD est un outil de clôture qui permet d’isoler un nœud qui se comporte mal et de l’empêcher de causer des problèmes dans la grappe.
  Pour ce faire, on utilise un dispositif de stockage partagé que les nœuds utilisent pour communiquer leur état.
• OCF (Open Cluster Framework) : les scripts OCF constituent la base des ressources gérées par Pacemaker.
  Ils définissent comment démarrer, arrêter et vérifier l’état d’une ressource, offrant ainsi la flexibilité nécessaire pour intégrer un large éventail de services dans le cluster.
• Csync2 : Un outil pour synchroniser les fichiers entre les nœuds d’un cluster.
  Il permet de s’assurer que les fichiers de configuration et autres données critiques sont toujours à jour sur tous les nœuds.

Situation actuelle et tendances futures

Les clusters dans SUSE Linux ont mûri et s’adaptent aux nouvelles demandes des entreprises.
Avec l’adoption croissante des environnements de conteneurs et avec des parties dans différents clouds, les clusters dans SUSE Linux évoluent pour mieux s’y intégrer.
Cela inclut une meilleure prise en charge de l’orchestration des conteneurs et des applications distribuées qui nécessitent une haute disponibilité au-delà de la réplication de deux disques par DRBD et du maintien en vie d’une IP virtuelle :). Toujours est-il qu’aujourd’hui, la combinaison de Pacemaker, Corosync, DRBD et d’autres outils constitue une base solide pour créer des clusters à haute disponibilité qui peuvent évoluer et s’adapter aux besoins de SAP HANA et d’autres solutions qui nécessitent une disponibilité élevée, voire totale. Si tu as besoin d’aide, SIXE peut t’aider.

Fiche d’astuces pour créer et gérer des grappes avec Pacemaker sur SUSE Linux

Voici une modeste feuille de contrôle pour t’aider à créer et à gérer des clusters avec Pacemaker sur SUSE Linux.
Partager, c’est se soucier des autres !

Mise à jour ! Ce n’est plus une rumeur mais officiellement pris en charge à partir du 19 juillet 2024 (voir annonce).

Une brève histoire de la virtualisation imbriquée sur le matériel IBM

La virtualisation imbriquée permet à une machine virtuelle (VM) d’héberger d’autres VM, créant ainsi un environnement de virtualisation en couches. Cette capacité est particulièrement bénéfique dans les scénarios d’entreprise où la flexibilité, l’évolutivité et la gestion efficace des ressources (si nous économisons sur l’unité centrale, nous économisons sur les licences en $$$) sont essentielles.

Bien qu’il puisse être utilisé à des fins de test avec KVM sur x86 ou VMware, les performances sont souvent sous-optimales en raison des multiples traductions et modifications des instructions matérielles avant qu’elles n’atteignent l’unité centrale ou le sous-système d’E/S. Ce problème n’est pas propre à ces plateformes et peut également affecter d’autres technologies de virtualisation.

Sur des plateformes comme Z, bien que l’impact de la virtualisation imbriquée sur les performances existe, les améliorations et les optimisations de l’hyperviseur peuvent atténuer ces effets, ce qui la rend viable à 100 % pour une utilisation en entreprise.

Couches de virtualisation sur IBM Mainframe

Avant de se plonger dans le KVM imbriqué sur PowerVM, il est essentiel de comprendre les technologies similaires. Si le mainframe est le grand-père de la technologie actuelle des serveurs, le partitionnement logique (LPAR) et les technologies de virtualisation (zVM) sont les grands-mères des solutions d’hyperviseurs.

Sur cette image (tirée de cet excellent article d’Anbarasan Sekar), tu peux voir jusqu’à 4 couches.

Virtualisation de niveau 1 : Montre une LPAR fonctionnant sous Linux en mode natif

Virtualisation de niveau 2 : Montre les machines virtuelles fonctionnant sur l’hyperviseur z/VM ou KVM.

Virtualisation de niveau 3 : Montre l’imbrication des machines virtuelles z/VM

Virtualisation de niveau 4 : Montre des conteneurs Linux qui peuvent soit fonctionner comme des conteneurs autonomes, soit être orchestrés avec kubernetes.

Jette maintenant un coup d’œil à cette ancienne image (2010) de l’architecture de la plateforme Power d’IBM. Est-ce que tu vois quelque chose de similaire ? :) Passons à autre chose !

Déployer des machines virtuelles au sommet d’une LPAR PowerVM Linux

Si nous avons des LPAR sur Power où nous pouvons exécuter AIX, Linux et IBM i, et dans Linux, nous pouvons installer KVM, pouvons-nous exécuter des VM à l’intérieur d’une LPAR ?

Pas tout à fait ; il échouera à un moment ou à un autre. Pourquoi ? Parce que KVM n’est pas zVM (pour l’instant), et que nous avons besoin de quelques ajustements dans le code du noyau Linux pour prendre en charge la virtualisation imbriquée non seulement avec les processeurs IBM Power9 ou Power10, mais aussi avec le sous-système de mémoire et les E/S Power.

En examinant les listes de diffusion de kernel.org, nous pouvons voir des développements prometteurs. Réussir à faire fonctionner plusieurs VM avec KVM sur un LPAR PowerVM signifie porter une fantastique technologie de virtualisation mainframe sur IBM Power, ce qui nous permet de faire fonctionner des VM et la virtualisation Kubernetes/OpenShift sur ppc64le à des fins de production. Cela ferait une différence significative si la pénalité de performance était minime.La virtualisation du processeur sur les systèmes Power et Mainframe alloue simplement du temps de processeur sans mapper un thread complet comme le font KVM ou VMware. Par conséquent, il est techniquement possible d’ajouter un hyperviseur par-dessus sans affecter de manière significative les performances, comme le fait IBM avec LinuxOne.

Dernières nouvelles de KVM sur IBM PowerVM LPARs (mai 2024)

1) Ajouter une capacité VM pour permettre la virtualisation imbriquée
Résumé : Ce message traite de la mise en œuvre des capacités de virtualisation imbriquée dans KVM pour PowerPC, y compris les configurations de modules et la prise en charge des processeurs POWER9.

2) API PAPR imbriquée (KVM sur PowerVM)
Résumé : Il détaille l’extension de l’état des registres pour l’API PAPR imbriquée, la gestion de plusieurs VCPU et la mise en œuvre d’hyperappels spécifiques.

3) KVM : PPC : Book3S HV : virtualisation HV imbriquée
Résumé : Une série de correctifs améliorant la virtualisation imbriquée dans KVM pour PowerPC, notamment la gestion des hypercalls, des défauts de page et des tables de mappage dans debugfs.

Pour des informations plus détaillées, tu peux consulter les liens suivants :

• PPC Interface paravirtuelle KVM
• lore.kernel.org/kvm-ppc
• Le patch de Gautam

Pourrons-nous installer Windows sur les systèmes Power (pour le plaisir) ?

CAKE – Perhaps, Perhaps, Perhaps (Official Audio)

Reste à l’écoute !

Sortir d’un contrat Oracle Unlimited License Agreement (ULA) et migrer vers les systèmes IBM Power peut être un processus complexe, mais bien exécuté, il peut offrir des économies significatives et des avantages à long terme. Dans cet article, nous allons explorer comment faire cette transition efficacement et sans pénalités, en nous basant sur des exemples réels.

Comprendre Oracle ULA

Tout d’abord, il est essentiel de comprendre ce qu’implique une ULA Oracle. C’est un contrat qu’Oracle a acheté à une société tierce et qui continue d’effrayer et de ravir à parts égales. Permet l’utilisation illimitée de certains logiciels Oracle pendant une période déterminée, généralement entre 3 et 5 ans. À la fin du contrat ULA, l’entreprise doit déclarer l’utilisation de ces produits et cela devient leur “certification” pour les futurs audits de licence. Un célèbre dicton dit que le diable que tu connais vaut mieux que le diable que tu ne connais pas. Et une autre que le diable se cache dans les détails. Dans le cas d’Oracle, il n’y a pas deux ULA identiques. Elles reposent toutes sur le même postulat “quand Oracle pense qu’il peut obtenir de l’argent de son client”. Mais au-delà, il existe des règles du jeu qui, une fois comprises, nous permettent d’aider nos clients.

Étapes pour quitter l’ULA d’Oracle

1. Audit initial: avant l’achèvement de l’ULA, nous effectuons un audit interne pour bien comprendre l’utilisation que tu fais actuellement des produits Oracle. Il s’agit notamment d’identifier les produits qui sont essentiels et ceux qui peuvent être remplacés ou jetés.
2. Analyse des besoins futurs: nous évaluons les besoins futurs de ton entreprise en termes de logiciels et de bases de données. Cette étape est cruciale pour déterminer si la transition vers IBM Power est faisable et quelles sont les économies potentielles.
3. Examen des contrats de licence de tiers: les contrats Oracle pouvant être complexes, il est conseillé de travailler avec des consultants spécialisés dans les licences Oracle. Ils peuvent t’aider à comprendre les implications de ta LRU et à savoir comment t’en sortir sans encourir de pénalités.
4. Nous négocions avec Oracle: nous t’aidons à négocier un nouvel accord qui correspond le mieux à tes besoins actuels et futurs.
5. Planification de la migration: élaborer un plan détaillé pour passer d’Oracle à IBM Power.

Migration vers IBM Power

La migration vers IBM Power implique le déplacement des charges de travail des bases de données et des applications Oracle vers un environnement IBM. Cela peut inclure l’utilisation d’IBM Db2, qui est connu pour ses hautes performances et sa sécurité.

1. Évaluation de la compatibilité: nous nous assurons que tes applications actuelles sont compatibles avec IBM Power. Oracle est Oracle dans toutes ses versions actuelles et futures, mais il peut toujours y avoir une application qui nécessite quelques modifications pour changer d’architecture (nous le faisons tous les jours et sans problème).
2. Conception du nouvel environnement : sur la base de l’audit précédent, nous concevons un nouvel environnement sécurisé, simple, puissant et stable, adapté à tes besoins et à ton budget.
3. Mise en œuvre d’IBM Power: nous t’aidons à acquérir et à déployer IBM Power. Nous mettons en place les bases de données et les applications nécessaires.
4. Migration des données: nous déplaçons les données d’Oracle vers IBM Power, en veillant à ce que l’intégrité des données soit maintenue tout au long du processus.
5. Tests de performance, HA et DR: effectuer des tests approfondis pour s’assurer que toutes les applications et bases de données fonctionnent correctement dans le nouvel environnement.
6. Formation et assistance technique: nous formons ton équipe à l’utilisation de la nouvelle plateforme et si tu en as besoin, tu peux faire appel à nos services de maintenance préventive et d’assistance technique pour les aider.

Plus de choses à aimer à propos d’Oracle in Power

Nous avons des playbooks Ansible officiels et pris en charge pour automatiser tous les déploiements et les opérations du jour 2 :

Beaucoup de documentation :

Et chez SIXE, en tant qu’organisme de formation officiel d’IBM, nous veillons à ce que tes équipes techniques maîtrisent la plateforme en quelques semaines. En tant que techniciens nous-mêmes, nous te garantissons qu’ils seront très reconnaissants de ce changement.

Quel budget puis-je économiser en migrant d’Oracle à IBM Power ?

En termes de coûts, la migration d’Oracle vers IBM Power peut permettre de réaliser des économies importantes, bien que celles-ci varient d’un client à l’autre. Des exemples concrets ont montré des économies de 20 à 60 % sur le coût total de possession (TCO) lors de la migration d’Oracle vers des solutions alternatives telles que IBM. Ces économies proviennent de la baisse des coûts de licence, de la réduction des besoins en matériel de haute performance grâce à l’efficacité d’IBM Power, et de la baisse des coûts de maintenance et d’assistance.

Mais les licences Oracle pour Power sont plus chères !

C’est vrai, mais nous avons des clients chez qui nous pouvons faire la même chose avec 25 cœurs Power10 qu’avec 100 dans un Exadata, mais IBM Power ne se limite pas à Oracle (bien qu’il y ait plus de 80 000 installations dans le monde). Tu peux déployer OpenShift, SAP HANA ou toute autre charge de travail fonctionnant sur SUSE, Red Hat, AIX et IBMi. En réalité, le cas d’utilisation le plus courant est la consolidation de tous les Exadatas et de la plupart des serveurs x86 en un Power10 dans chaque centre de données. Tout faire tourner sur un hyperviseur qui se situe à un autre niveau, où au lieu de “cartographier les cpus” comme le font KVM ou VMWare, la capacité de chacun est partagée en temps réel, ce qui permet de gagner en utilisation globale du système ainsi qu’en performance. Les Exadatas ont été une belle réussite marketing, mais ils ne sont ni moins chers, ni plus performants, ni n’offrent la sécurité d’IBM Power.

Conclusion

Sortir d’un contrat Oracle ULA et migrer vers IBM Power est tout à fait possible. En procédant correctement, on peut non seulement éviter les pénalités, mais aussi réaliser des économies considérables, tout en améliorant l’efficacité et l’adaptabilité technologique de l’entreprise. Il est essentiel d’avoir le soutien d’experts en matière de licences et de procéder à une analyse approfondie pour assurer une transition réussie.

Nous ne nous attendons pas à t’avoir convaincu, mais peut-être pourrions-nous discuter sans engagement, évoquer tes doutes et, si tu trouves cela intéressant, réaliser gratuitement une analyse de faisabilité . Dans le pire des cas, tu renouvelles la LRU telle quelle. Je plaisante (ou pas) :)