Modifier

Share via


Migration de AIX UNIX local vers Azure Linux

Azure NetApp Files
Azure Site Recovery
Azure SQL Database
Machines virtuelles Azure
Réseau virtuel Azure

Cette solution décrit une migration d’une plateforme IBM AIX Unix vers Red Hat Enterprise Linux (RHEL) dans Azure. L’exemple concret était une application du Département de la Santé et des Services sociaux pour un client important. Une latence et une durée de transaction faibles étaient des critères importants pour les systèmes hérités et Azure. Une fonctionnalité clé est le stockage des informations sur les clients dans une base de données liée à un magasin de fichiers réseau contenant des images graphiques associées. Azure répond à ce besoin avec Azure NetApp Files.

Architecture

Le diagramme suivant illustre l’architecture système héritée AIX locale prémigration :

Diagramme illustrant l’architecture système AIX prémigration.

Téléchargez un fichier Visio de cette architecture.

  • Les appliances réseau fournissent une couche étendue de routage réseau et d’équilibrage de charge (A).

  • Le niveau de présentation (B) utilise trois ordinateurs front-end web Java dans leur propre sous-réseau, qui segmente le trafic réseau avec des pare-feux.

  • Les pare-feux (C) fournissent des limites réseau entre tous les niveaux participants et les sous-systèmes. Bien que les pare-feux soient efficaces, ils constituent également une charge administrative.

  • Le système fournit des demandes de l’utilisateur à la couche Application (D), qui possède trois serveurs d’applications web.

  • La couche Application appelle la base de données DB2 et le stockage NAS (Network Attached Storage) :

    • La base de données (E) est DB2 sur AIX. Trois serveurs DB2 sont configurés dans un cluster de haute disponibilité/reprise d’activité.

    • L’application stocke des objets binaires tels que des images et des fichiers PDF pour les clients et les utilisateurs dans un sous-système NAS (F).

  • Les serveurs de gestion et d’administration et les serveurs MQ (G) se trouvent dans leur propre sous-réseau, segmenté avec des pare-feux.

  • Les services de gestion des identités LDAP (Lightweight Directory Access Protocol) (H) sont dans leur propre sous-réseau, segmenté avec des pare-feux.

Le diagramme suivant illustre l’architecture système postmigration RHEL dans Azure :

Diagramme illustrant l’architecture Azure postmigration.

Téléchargez un fichier Visio de cette architecture.

Dataflow

  1. Le trafic dans le système Azure est routé via Azure ExpressRoute et Azure Traffic Manager :

    • ExpressRoute assure une connexion privée, sécurisée et fiable aux réseaux virtuels Azure. ExpressRoute se connecte à Azure avec une faible latence, une haute fiabilité et une vitesse élevée ainsi qu’avec des bandes passantes allant jusqu’à 100 Gbits/s.
    • Traffic Manager répartit le trafic des applications publiques entre les régions Azure.
  2. Une couche de gestion réseau fournit des services de sécurité de point de terminaison, de routage et d’équilibrage de charge. Cette couche utilise Azure Load Balancer et le pare-feu d’applications web Azure.

  3. Azure App Service sert de niveau de présentation. App Service est une couche PaaS (Platform-as-a-Service) pour les applications .NET ou Java. Vous pouvez configurer App Service pour la disponibilité et la scalabilité dans et entre les régions Azure.

  4. La solution encapsule chaque couche Application dans son propre réseau virtuel, segmenté avec les groupes de sécurité réseau.

  5. Les groupes à haute disponibilité et le stockage Azure partagé assurent la haute disponibilité et la scalabilité pour les machines virtuelles au niveau de la couche Application. Les serveurs de cluster d’application partagent l’état de la transaction et effectuent un scale-up des machines virtuelles en fonction des besoins.

  6. L’application utilise une connexion de point de terminaison privé pour stocker les données et y accéder dans Azure SQL Database. SQL Database s’exécute dans une configuration de continuité d’activité, qui fournit la géoréplication et les groupes de basculement automatique pour une procédure BCDR automatique et par-delà les frontières.

  7. Azure NetApp Files fournit un stockage NAS partagé, avec un accès rapide aux données binaires et à la réplication vers la région secondaire.

  8. La région secondaire offre les composants suivants à la procédure BCDR :

    • Azure Site Recovery sauvegarde les images de machine virtuelle pour le basculement de reprise d’activité dans une configuration active/passive. Site Recovery crée des réplicas d’image de machine virtuelle cohérents dans la région secondaire et assure la synchronisation des images de machine virtuelle.
    • La configuration de continuité d’activité de SQL Database garantit la cohérence des transactions de base de données. SQL Database provisionne les bases de données de réplica et assure leur synchronisation avec une réplication synchrone ou asynchrone des données.

Le système contient également les composants suivants :

  • Une ou plusieurs machines virtuelles du réseau virtuel de gestion offrent des fonctionnalités de gestion et d’administration.

  • Azure Service Bus implémente l’infrastructure MQ Series et fournit des services de file d’attente de messages pour les applications. Pour plus d’informations sur la migration de MQ Series vers Azure Service Bus, consultez Migrer d’ActiveMQ vers Azure Service Bus.

  • Microsoft Entra ID assure la gestion des identités et des accès pour toutes les entités et identités Azure migrées à partir des services LDAP hérités.

Composants

  • Azure ExpressRoute étend un réseau local aux services cloud Microsoft via une connexion privée facilitée par un fournisseur de connectivité. ExpressRoute assure une connexion privée, sécurisée et fiable au système Azure, avec une faible latence ainsi qu’une vitesse et une bande passante élevées.

  • Azure Traffic Manager est un équilibreur de charge du trafic DNS qui répartit le trafic entre les régions Azure, tout en offrant haute disponibilité et réactivité rapide.

  • Azure Load Balancer prend en charge la haute disponibilité en distribuant le trafic réseau entrant entre les machines virtuelles back-end en fonction des règles d’équilibrage de charge et des sondes d’intégrité configurées. Load Balancer opère sur couche 4 du modèle OSI (Open Systems Interconnection).

  • Le pare-feu d’applications web Azure est un service WAF natif cloud qui protège les applications web contre les attaques malveillantes et les vulnérabilités web courantes.

  • Azure App Service est un service d’hébergement web entièrement géré pour déployer rapidement et facilement des applications web d’entreprise pour n’importe quelle plateforme sur une infrastructure cloud scalable et fiable.

  • Les machines virtuelles Azure constituent l’un des services Azure qui fournissent des ressources informatiques scalables à la demande. Les machines virtuelles Azure vous permettent de tirer parti de la flexibilité de la virtualisation sans avoir à acheter le matériel physique ni à en assurer la maintenance.

    • Les disques managés SSD Azure sont des volumes de stockage de niveau bloc pour les machines virtuelles Azure.
    • Les cartes réseau virtuelles Azure permettent aux machines virtuelles Azure de communiquer avec des ressources locales, sur Internet et sur Azure. Vous pouvez ajouter plusieurs cartes réseau virtuelles à une machine virtuelle Azure, de sorte que les machines virtuelles enfants puissent avoir leurs propres périphériques d’interface réseau et adresses IP dédiés.
  • Le réseau virtuel Azure est le bloc de construction fondamental pour vos réseaux privés Azure. Un réseau virtuel permet à de nombreux types de ressources Azure, comme les machines virtuelles, de communiquer en toute sécurité entre elles, avec Internet et avec les réseaux locaux. Le réseau virtuel offre des avantages de l’infrastructure Azure tels que la scalabilité, la disponibilité et l’isolation.

  • Le stockage Azure Files offre des partages de fichiers entièrement gérés dans le cloud qui sont accessibles via le protocole SMB (Server Message Block) standard. Les déploiements cloud et locaux de Windows, Linux et macOS peuvent monter des partages de fichiers Azure simultanément.

  • Azure SQL Database est une base de données PaaS entièrement managée qui s’exécute toujours sur le système d’exploitation le plus récent et la version stable du moteur de base de données SQL Server, avec la disponibilité la plus élevée. Azure SQL Database prend en charge les fonctions de gestion de base de données, telles que les mises à niveau, la mise à jour corrective, les sauvegardes et la supervision, sans intervention de l’utilisateur.

  • Azure NetApp Files offre des partages de fichiers Azure de qualité professionnelle, reposant sur NetApp. Azure NetApp Files permet aux entreprises de migrer et d’exécuter facilement des applications complexes basées sur des fichiers sans modification du code.

  • Azure Site Recovery est un service de reprise d’activité natif Azure. Azure Site Recovery déploie des processus de réplication, de basculement et de récupération pour que l’exécution des applications se poursuive pendant les pannes planifiées et non planifiées.

  • Azure Service Bus est un service de messagerie cloud fiable avec une intégration hybride simple.

  • Microsoft Entra ID est un service de gestion des identités et des accès d'entreprise basé sur le cloud de Microsoft. L’authentification unique et l’authentification multifacteur Microsoft Entra aident les utilisateurs à se connecter et à accéder aux ressources, tout en les protégeant contre les attaques de cybersécurité.

Autres solutions

Les environnements Azure App service sont adaptés aux charges de travail d’application nécessitant une grande échelle, une isolation et un accès réseau sécurisé. Cette fonctionnalité offre des environnements entièrement isolés et dédiés pour l’exécution sécurisée d’applications App Service à grande échelle. Les environnements App Service peuvent héberger les types d’applications suivants :

  • Applications web Linux, comme dans l’exemple actuel
  • Applications web Windows
  • Conteneurs Docker
  • Applications mobiles
  • Fonctions

Détails du scénario

Une nette différence entre le système hérité et l’implémentation cloud concerne la gestion de la segmentation du réseau. Le système hérité segmentait les réseaux avec des pare-feux. Une plateforme cloud comme Azure segmente les réseaux avec des réseaux virtuels et des groupes de sécurité réseau qui filtrent le trafic en fonction de plusieurs critères.

Une autre différence entre les systèmes réside dans leurs modèles de haute disponibilité (HA) et de reprise d’activité (DR). Dans le système hérité, la haute disponibilité et la reprise d’activité utilisaient principalement des sauvegardes et, dans une certaine mesure, des serveurs redondants dans le même centre de données. Cette configuration offrait une reprise d’activité modeste, mais quasiment aucune fonctionnalité de haute disponibilité. L’amélioration de la haute disponibilité/reprise d’activité était un facteur clé pour le passage à la plateforme Azure. Azure utilise le clustering, le stockage partagé et Azure Site Recovery pour fournir un niveau élevé de haute disponibilité/reprise d’activité.

Cas d’usage potentiels

Les facteurs clés pour le passage d’un système IBM AIX local à RHEL dans Azure peuvent inclure les suivants :

  • Matériel mis à jour et coûts réduits. En local, les composants matériels hérités deviennent en permanence obsolètes et ne sont plus pris en charge. Les composants cloud sont toujours à jour. Les coûts au mois peuvent être moins élevés dans le cloud.

  • Environnement DevOps agile. Le déploiement de modifications de conformité dans un environnement AIX local peut prendre des semaines. Il se peut que vous deviez configurer plusieurs fois des environnements d’ingénierie des performances similaires pour tester les modifications. Dans un environnement cloud Azure, vous pouvez configurer le test d’acceptation utilisateur et les environnements de développement en quelques heures. Vous pouvez implémenter des modifications à l’aide d’un pipeline d’intégration continue/de livraison continue (CI/CD) DevOps moderne et bien défini.

  • Continuité d’activité et reprise d’activité (BCDR) améliorées Dans les environnements locaux, les objectifs de délai de récupération (RTO) peuvent être longs. Dans l’exemple d’environnement AIX local, l’objectif RTO via des sauvegardes et des restaurations classiques était de deux jours. La migration vers Azure a réduit l’objectif RTO à deux heures.

Considérations

Les considérations suivantes, basées sur le Microsoft Azure Well-Architected Framework, s’appliquent à cette solution :

Disponibilité

  • Azure NetApp Files peut conserver le magasin de fichiers dans la région secondaire mise à jour avec la réplication inter-région des volumes Azure NetApp Files. Cette fonctionnalité Azure assure une protection des données via la réplication de volume inter-région. Vous pouvez basculer des applications critiques en cas de panne à l’échelle d’une région. La réplication de volume inter-région est actuellement en préversion.

  • Les serveurs de cluster d’application effectuent un scale-up des machines virtuelles en fonction des besoins, ce qui augmente la disponibilité dans les régions Azure.

Opérations

Pour une supervision et une gestion proactives, envisagez d’utiliser Azure Monitor pour superviser les charges de travail AIX migrées.

Efficacité des performances

  • Les goulots d’étranglement potentiels de cette architecture sont les sous-systèmes de stockage et de calcul. Veillez à choisir vos références SKU de stockage et de machine virtuelle en conséquence.

  • Les types de disques de machine virtuelle disponibles sont les disques Ultra, les disques SSD (Solid-State Drive) Premium, les disques SSD standard et les disques durs standard. Pour cette solution, il est préférable d’utiliser des disques SSD Premium ou Ultra.

  • Pour estimer le dimensionnement des machines virtuelles provenant d’un système AIX, gardez à l’esprit que les processeurs AIX sont environ 1,4 fois plus rapides que la plupart des processeurs virtuels x86. Cette instruction peut varier en fonction de la charge de travail.

  • Placez plusieurs machines virtuelles qui doivent communiquer entre elles dans un groupe de placement de proximité. Le placement des machines virtuelles proches les unes des autres offre la latence de communication la plus faible.

Extensibilité

  • Azure ExpressRoute prend en charge une grande échelle pour les implémentations qui utilisent une bande passante importante pour la réplication initiale ou la réplication en continu des données modifiées.

  • La gestion de l’infrastructure, y compris la scalabilité, est automatisée dans les bases de données Azure.

  • Vous pouvez effectuer un scale-out de la couche Application en ajoutant d’autres instances de machine virtuelle du serveur d’applications.

Sécurité

Optimisation des coûts

  • La migration des charges de travail AIX vers Linux dans Azure peut générer des économies substantielles. Vous éliminez la maintenance matérielle, réduisez les coûts d’installation et pouvez généralement réduire les coûts d’exploitation d’un facteur de huit à 10. Azure peut prendre en charge une capacité supplémentaire pour les charges de travail saisonnières ou périodiques en fonction des besoins, ce qui réduit le coût global.

  • La migration des charges de travail AIX vers Azure permet également de réduire les coûts en utilisant des services natifs cloud. Voici quelques exemples :

    • Utilisation d’Azure App Service pour le niveau de présentation au lieu de configurer plusieurs machines virtuelles.
    • Segmentation des charges de travail avec des réseaux virtuels Azure au lieu d’utiliser des pare-feux matériels.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Étapes suivantes