Déployer IBM Maximo Application Suite sur Azure

Cet article décrit le déploiement d’IBM Maximo Application Suite (MAS) sur Azure. MAS s’exécute sur Red Hat OpenShift. Azure Red Hat OpenShift (ARO) est la plateforme OpenShift préférée si elle répond à vos exigences opérationnelles, de sécurité et de mise en réseau. Utilisez Red Hat OpenShift auto-géré sur Azure uniquement quand vous avez besoin de contrôler qu'ARO ne fournit pas, comme des modèles de déploiement déconnectés spécifiques ou une personnalisation au niveau du cluster.

Cet article ne décrit pas en détail comment installer MAS. Pour plus d’informations sur l’installation, consultez Installation de Maximo Application Suite.

Architecture

Le diagramme suivant illustre un déploiement MAS basé sur ARO sur Azure.

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

Vous pouvez déployer la charge de travail en tant que déploiement interne ou externe, en fonction de vos besoins. Cet article ne prescrit pas de modèle de déploiement ARO public ou privé. Choisissez l’architecture du plan de contrôle, de l’entrée et de la sortie en fonction de votre architecture de zone d’atterrissage Azure, notamment sa topologie de mise en réseau, son modèle de connectivité, ses contrôles de sécurité, les exigences d’accès opérationnel, les exigences de conformité et les modèles d’accès utilisateur MAS.

Quand IBM prend en charge les bases de données externes pour les applications MAS que vous déployez, essayez de externaliser ces bases de données pour réduire l’état à l’intérieur du cluster OpenShift et dissocier la gestion des bases de données à partir de la gestion des clusters.

Flux de travail

Du point de vue de l’infrastructure, cette architecture offre les fonctionnalités suivantes :

• Un service managé Azure Red Hat OpenShift pour déployer des charges de travail hautement disponibles dans les zones de disponibilité
• Un cluster OpenShift intégré à la mise en réseau et au stockage Azure
• Azure Files Premium et standard Azure Files pour les exigences de stockage MAS prises en charge
• Azure SQL Managed Instance ou IBM Db2 Warehouse basé sur des conteneurs
• Azure DNS pour la gestion DNS (Domain Name System) d’OpenShift et de ses conteneurs
• Microsoft Entra ID pour l’authentification unique (SSO) dans MAS

Composants

• Azure Red Hat OpenShift (ARO) est la plateforme OpenShift préférée pour MAS sur Azure. ARO réduit votre responsabilité opérationnelle pour l’exécution d’OpenShift, par rapport à un cluster auto-géré sur Azure machines virtuelles.

• Machines virtuelles Azure est une infrastructure en tant que service (IaaS) qui déploie des ressources informatiques évolutives à la demande. Utilisez Machines Virtuelles au lieu d’ARO pour déployer Red Hat OpenShift auto-géré sur Azure.

  Si vous le souhaitez, utilisez Azure machines virtuelles Linux comme sauts pour l’installation de MAS et l’administration OpenShift. Si vous disposez d’une connectivité réseau privée dans votre environnement de Azure, vous pouvez effectuer l’administration à partir d’une machine sécurisée existante.

• Red Hat Enterprise Linux CoreOS fournit l’image du système d’exploitation pour les nœuds OpenShift.

• Azure Load Balancer fournit une connectivité au cluster. Load Balancer est un service d’équilibrage de charge de couche 4 haute performance et ultra-faible latence pour tous les protocoles TCP (User Datagram Protocol) entrants et sortants. Load Balancer pouvez gérer des millions de requêtes par seconde tout en garantissant que votre solution est hautement disponible. Load Balancer est redondant interzone, ce qui garantit une haute disponibilité entre les zones de disponibilité.

• Le réseau virtuel Azure est le composant fondamental pour vos réseaux privés dans Azure. Utilisez Réseau virtuel pour la communication entre les nœuds et les services Azure et pour la connectivité hybride.

• Azure Files fournit des partages de fichiers entièrement managés dans le cloud accessibles via les protocoles SMB (Server Message Block) et NFS (Network File System). Utilisez Azure Files pour héberger les données avec état des bases de données et des systèmes à l’intérieur du cluster.

• Azure DNS gère la résolution DNS pour les conteneurs à l’intérieur et à l’extérieur de la solution. Azure DNS prend en charge tous les enregistrements DNS courants et fournit une haute disponibilité.

• Azure Bastion est un service entièrement géré qui fournit un accès RDP (Remote Desktop Protocol) et un accès SSH (Secure Shell) aux machines virtuelles sans aucune exposition via des adresses IP publiques. Utilisez éventuellement Azure Bastion et un sous-réseau pour améliorer l’accès à la sécurité à l’un des nœuds Worker ou aux machines de jump box facultatives.

• SQL Managed Instance fournit des services de données externes à MAS quand IBM prend en charge SQL Server pour les applications que vous déployez. Vous pouvez également choisir une autre base de données, telle qu’Oracle Exadata ou IBM Db2 Warehouse. Azure SQL Database n'est pas pris en charge.

• Twilio SendGrid envoie des e-mails de MAS à ses consommateurs. Si votre déploiement MAS a besoin d’un service de messagerie pour les scénarios de notification et de répartition des effectifs, incorporez éventuellement un service de messagerie tel que Twilio SendGrid dans votre conception.

Autres solutions

Les services suivants ne sont généralement pas nécessaires, mais sont des alternatives efficaces :

• Azure NetApp Files en remplacement de Azure Files. Azure NetApp Files prend en charge les charges de travail nécessitant une haute disponibilité et des performances élevées.
• Oracle Database sur Azure si elle est prise en charge et que vous le préférez.
• OpenShift Data Foundation si vous souhaitez utiliser Db2 Warehouse sur OpenShift Data Foundation.

Détails du scénario

IBM Maximo Application Suite est une plateforme de gestion des ressources d’entreprise avec maintenance des ressources basée sur l’IA. MAS se concentre sur la résilience opérationnelle et la fiabilité. La suite se compose de la plateforme d’application principale MAS et des applications suivantes et des solutions spécifiques au secteur qui sont basées sur la plateforme.

• Maximo Manage. Réduit les temps d’arrêt et les coûts à l’aide de la gestion des ressources pour améliorer les performances opérationnelles.
• Maximo Monitor. Utilise l’Internet des objets (IoT) pour une supervision avancée basée sur l’IA des ressources distantes à grande échelle.
• Maximo Health. Gère l’intégrité des ressources à l’aide de données IoT à partir de capteurs, de données de ressources et d’historique de maintenance.
• Inspection visuelle Maximo. Entraîne les modèles Machine Learning à utiliser l’inspection visuelle pour l’analyse visuelle des problèmes émergents.
• Maximo Predict. Prédit les défaillances futures à l’aide du Machine Learning et de l’analytique des données.
• Maximo Collabore. Prend en charge les techniciens avec des conseils basés sur l’IA à partir d’une base de connaissances de données de maintenance d’équipement et fournit un accès à distance aux experts.
• Maximo Health, Safety and Environment (HSE) Connecte la sécurité, la conformité environnementale et le contrôle des processus de travail aux ressources, aux emplacements et aux ordres de travail.
• Maximo Civil Infrastructure. Intègre l’inspection, le suivi des défauts et les activités de maintenance afin d’améliorer la durée de vie des ressources, de maintenir le fonctionnement des systèmes critiques et de réduire le coût total de possession de l’infrastructure civile.
• Maximo Real Estate and Facilities. Gère les portefeuilles immobiliers et les actifs des installations avec la gestion de l’espace, les réservations, les projets d’immobilisations, l’évaluation des conditions des installations, la gestion des baux, les opérations et la maintenance.

Cas d’usage potentiels

De nombreuses industries et secteurs utilisent des solutions MAS, telles que les domaines suivants :

• Énergie et services publics
• Hydrocarbures
• Industrie
• Voyage, automobile et transport
• Secteur public

Pour plus d’informations sur les cas d’utilisation de MAS, consultez IBM Maximo Application Suite sur le site web IBM.

Recommandations

Cet article est écrit pour les déploiements MAS 9.x pris en charge actuels sur Azure. Microsoft travaillé avec l’équipe IBM MAS et d’autres partenaires pour vous assurer que cette solution est configurée pour s’exécuter de manière optimale et offrir la meilleure expérience sur Azure. Cette documentation, architecture et conseils suivent les meilleures pratiques décrites dans le framework Microsoft Azure Well-Architected. Contactez votre équipe de compte IBM pour connaître les questions spécifiques au produit et le support au-delà de cette documentation.

Utilisez cet article pour obtenir des conseils sur l’architecture lorsque vous avez pris en charge IBM et un partenaire pour l’installation. Azure propose également un chemin d’installation pour MAS qui prend en charge l’apport de votre propre licence. Pour plus d'informations, consultez IBM Maximo Application Suite (apportez votre propre licence (BYOL)).

Installez une version MAS prise en charge que IBM répertorie comme compatible avec votre version OpenShift et vos applications MAS sélectionnées. Pour les nouveaux déploiements Azure, utilisez ARO comme plateforme OpenShift préférée, sauf si vous avez besoin d’un cluster auto-géré.

La compatibilité de la prise en charge d’OpenShift dépend de trois limites de prise en charge qui se chevauchent : compatibilité IBM MAS, prise en charge du cycle de vie Red Hat OpenShift et disponibilité de la version ARO. L’utilisation d’une version OpenShift qu’IBM ne répertorie pas dans les rapports de compatibilité des produits logiciels (SPCR) ou qui n’est pas prise en charge par Red Hat ou ARO peut laisser votre déploiement MAS non pris en charge.

Avant de générer votre déploiement, passez en revue la vue d’ensemble d’IBM Maximo Application Suite, la planification de l’installation sur Microsoft Azure et la documentation des rapports de compatibilité des produits logiciels (SPCR) pour comprendre les exigences de déploiement et de configuration actuelles.

Avant de poursuivre votre déploiement, répondez aux questions suivantes sur votre conception :

• Quelles applications MAS avez-vous besoin ?
• Quelles sont les dépendances dont disposent vos applications ?
• Quelle version d’OpenShift IBM prend-elle en charge pour vos applications et versions MAS ?
• ARO répond-il à vos besoins ou avez-vous besoin de Red Hat OpenShift auto-géré sur Azure ?
• Quelles bases de données avez-vous besoin ?
• Quel nombre et taille de machines virtuelles avez-vous besoin ?
• Les utilisateurs doivent-ils se connecter à partir de réseaux externes ?

Maximo Application Suite

Utilisez une version actuelle de MAS 9.x prise en charge et validez les versions, bases de données et dépendances OpenShift prises en charge dans IBM SPCR avant de finaliser l’architecture. Si vous utilisez une version antérieure de Maximo Application Suite, passez en revue son état du cycle de vie IBM et planifiez une mise à niveau vers une version MAS 9.x prise en charge.

Passez en revue les applications MAS dont vous avez besoin pour votre scénario métier complet, puis passez en revue les exigences de chacune des applications. Pour plus d’informations, consultez Exigences système IBM Maximo Application Suite.

Chaque application MAS peut avoir besoin d’une base de données distincte. Essayez de externaliser les bases de données si IBM prend en charge une base de données externe pour l’application, car cette approche réduit la quantité d’état que vous devez utiliser à l’intérieur d’OpenShift. Microsoft et IBM testés et prennent en charge les bases de données suivantes pour MAS sur Azure :

• SQL Managed Instance
• IBM Db2 Warehouse sur Cloud Pak pour les données 5

Azure SQL Database et Azure Cosmos DB ne sont pas pris en charge.

Vous pouvez également choisir d’exécuter Oracle Exadata sur Oracle Cloud Infrastructure ou sur une machine virtuelle à l’aide d’une interconnexion. Cette configuration n’est pas officiellement testée, mais elle a été correctement testée. Pour plus d’informations sur l’interconnexion, consultez Interconnecting Oracle Cloud avec Microsoft Azure.

MAS et certaines de ses applications dépendent de MongoDB et kafka. Utilisez les déploiements MongoDB Community Edition et Strimzi Kafka par défaut ibm quand ils correspondent à vos besoins de support, de sauvegarde et de récupération. Ce choix est approprié lorsque Kafka et MongoDB sont des dépendances MAS internes et que votre solution ne les utilise pas en dehors de MAS.

Essayez d’utiliser des services managés externes, tels que MongoDB Atlas sur Azure ou Confluent Cloud sur Azure, lorsque vous avez besoin d’opérations de sauvegarde, de mise à l’échelle ou de récupération d’urgence plus fortes. Certaines conditions préalables à MAS, telles que Behavior Analytics Services (BAS), utilisent des bases de données qui ne peuvent pas être externalisées, mais nécessitent un stockage persistant à fournir au cluster OpenShift.

Pour les services basés sur l’état qui s’exécutent à l’intérieur du cluster OpenShift, sauvegardez régulièrement des données et déplacez les sauvegardes dans une autre région. Concevez, planifiez et décidez d’une stratégie de récupération pour les sinistres, en particulier lorsque vous exécutez Kafka ou MongoDB à l’intérieur d’OpenShift. Pour les services qui conservent l’état, utilisez des offres PaaS (Platform as a Service) externes Azure si possible pour améliorer la prise en charge lors d’une panne.

Certains services peuvent nécessiter d’autres outils et services IBM, tels qu’IBM Watson Machine Learning et IBM App Connect. Vous pouvez déployer tous ces outils et services sur le même cluster OpenShift.

Azure Red Hat OpenShift

Utilisez ARO comme plateforme OpenShift préférée pour MAS sur Azure. ARO fournit un service OpenShift géré sur Azure, ce qui réduit votre charge opérationnelle pour l’installation, la mise à jour corrective et l’exploitation de la plateforme OpenShift. Vous possédez toujours MAS et sa configuration d’application, la planification de la capacité de travail, l’intégration réseau, l’intégration des identités, les choix de stockage, la protection des données et la récupération d’urgence.

Avant de déployer MAS sur ARO, tenez compte des recommandations suivantes :

• Compatibilité des versions. Sélectionnez une version OpenShift que IBM répertorie comme prise en charge pour votre version MAS et les applications MAS sélectionnées. Vérifiez que la même version d’OpenShift est disponible et prise en charge par ARO dans votre région cible Azure. Dans la mesure du possible, sélectionnez une version OpenShift numérotée pair pour les déploiements MAS de production, car ces versions sont des versions euS (Extended Update Support).

  Vérifiez que IBM prend en charge la version OpenShift sélectionnée pour toutes les applications et dépendances MAS sélectionnées. Si un composant MAS répertorie une version d’OpenShift numérotée plus récente comme condition requise dans IBM SPCR, validez le composant complet défini sur IBM SPCR, la prise en charge du cycle de vie Red Hat et la disponibilité des versions ARO avant de choisir la version du cluster.

• Chemin d’accès au déploiement. Utilisez un cluster ARO existant lorsque vous disposez de Azure zone d’atterrissage, de mise en réseau, d’identité, de stockage et de contrôles opérationnels préexistants. Utilisez le chemin d’installation d’IBM Place de marché Azure lorsque vous souhaitez que l’automatisation fournie par IBM crée ou réutilise l’infrastructure OpenShift prise en charge. Utilisez Red Hat OpenShift auto-géré sur Azure uniquement quand ARO ne répond pas à vos besoins.

• Sélection de la région. Utilisez une région qui possède des zones de disponibilité si possible. Configurez les nœuds Worker ARO entre les zones lorsque la région cible prend en charge ce modèle. Pour OpenShift auto-géré, configurez le fichier d’installation, install-config.yaml, afin qu’OpenShift place les nœuds entre les zones. S’il existe une panne dans une zone, votre solution peut continuer à fonctionner en ayant des nœuds dans d’autres zones prenant le contrôle du travail.

• Sauvegarde et récupération. Vous pouvez utiliser les instructions de sauvegarde et de récupération Azure Red Hat OpenShift. Pour plus d’informations, consultez Creater une sauvegarde d’application de cluster Azure Red Hat OpenShift 4. Si vous utilisez cette méthode pour la sauvegarde et la récupération, vous devez fournir une autre méthode de récupération d’urgence pour la base de données.

• Effectuez le basculement. Envisagez de déployer OpenShift dans deux régions et d’utiliser Red Hat Advanced Cluster Management. Si votre solution a des points de terminaison publics, vous pouvez placer Azure Traffic Manager entre les points de terminaison et Internet pour rediriger le trafic vers le cluster approprié dans une panne régionale. Dans ce cas, vous devez également migrer les états de vos applications et les volumes persistants.

OpenShift auto-géré

Utilisez Red Hat OpenShift auto-géré sur Azure si ARO ne répond pas à vos exigences de déploiement de contrôle, d'isolation ou de déconnexion. Pour les déploiements autogérés, choisissez entre les méthodes d’installation suivantes :

• Infrastructure provisionnée par l'installateur (IPI). Cette méthode utilise un programme d’installation pour déployer et configurer l’environnement OpenShift sur Azure. Utilisez IPI quand elle répond à vos exigences en matière de sécurité et de mise en réseau.

• Infrastructure provisionnée par l'utilisateur (UPI). Cette méthode vous permet de contrôler avec précision votre déploiement. L’UPI nécessite davantage d’étapes et de considérations pour créer votre environnement. Utilisez UPI si IPI ou ARO ne répondent pas à vos besoins. Une installation privée ou déconnectée est un cas d’usage courant pour UPI.

Installation à air gapped

Certains cas, tels que la conformité réglementaire, peuvent nécessiter une installation aérée par air de MAS sur Azure. Air-gapped signifie qu’il n’y a pas d’accès Internet entrant ou sortant. Sans connexion Internet, votre installation ne peut pas récupérer les dépendances pour l’installation de MAS ou OpenShift au moment de l’exécution.

Utilisez une installation à air gapped uniquement s’il s’agit d’une exigence de sécurité. Un écart d’air ajoute une complexité significative aux opérations de solution. Les activités telles que l’installation de logiciels, les conteneurs de mise en miroir, la mise à jour des miroirs pour se protéger contre les vulnérabilités de sécurité ou la gestion des pare-feu peuvent consommer des efforts opérationnels importants.

Pour plus d’informations sur les installations à air libre, consultez la documentation Red Hat OpenShift suivante pour les installations déconnectées et les clusters privés sur Azure :

• Mise en miroir d’images pour une installation déconnectée à l’aide d’oc-mirror
• Installation d’un cluster privé sur Azure

Après l’installation d’OpenShift par air, vous pouvez continuer avec la documentation MAS pour obtenir des conseils sur les environnements déconnectés.

Dimensionnement du nœud et de l’environnement

Pour toutes les charges de travail, à l’exception de Maximo Visual Inspection, commencez par les familles de machines virtuelles de la série Ds ou Das de génération actuelle, telles que Dsv6, qui sont disponibles en tant que nœuds Worker dans votre région choisie. Choisissez les tailles de machine virtuelle qui prennent en charge le stockage Premium et répondent aux exigences de processeur, de mémoire et de stockage pour les applications MAS que vous déployez.

Maximo Visual Inspection nécessite des nœuds GPU pour effectuer son machine learning. La solution utilise CUDA et prend uniquement en charge les GPU NVIDIA. Pour ARO, choisissez une taille de machine virtuelle GPU NVIDIA dans la liste actuelle de prise en charge du nœud worker ARO, puis confirmez qu’IBM le prend en charge pour vos versions DE MAS et OpenShift. Pour OpenShift auto-managé, choisissez une taille de machine virtuelle GPU NVIDIA prise en charge par IBM et Red Hat.

Pour les nœuds Worker GPU, commencez par le plus petit nœud et effectuez un scale-up à mesure que vos besoins augmentent.

Pour ARO et OpenShift auto-géré, utilisez les mêmes instructions de dimensionnement de charge de travail MAS pour les nœuds Worker. Configurez les nœuds Worker entre les zones de disponibilité pour prendre en charge la haute disponibilité. Pour OpenShift auto-géré, configurez également le plan de contrôle entre les zones de disponibilité. Utilisez le point de départ suivant :

• Nœuds de contrôle. Pour ARO, le plan de contrôle est géré dans le cadre du service. Pour OpenShift auto-managé, utilisez un minimum d’une machine virtuelle par zone de disponibilité dans la région sélectionnée.

• Nœuds de travail. Utilisez au moins deux machines par zone de disponibilité dans la région sélectionnée. Dimensionner les nœuds Worker en fonction des instructions IBM, des applications MAS sélectionnées et de la charge attendue.

Le cœur MAS nécessite 13 processeurs virtuels pour une installation de base de taille standard. Le dimensionnement des nœuds Worker varie en fonction des applications MAS que votre configuration déploie et de la charge sur votre environnement. Par exemple, Maximo Manage pour 10 utilisateurs nécessite 2 processeurs virtuels. Traitez ces valeurs comme des points de départ et validez le dimensionnement par rapport à la configuration système actuelle d’IBM Maximo Application Suite pour votre version MAS 9.x, les applications sélectionnées et l’utilisation attendue.

Pour OpenShift auto-géré, essayez de conserver des types de machines virtuelles similaires les uns aux autres pour fournir une proximité avec chacune des zones de disponibilité entre les nœuds worker et de contrôle. Pour ARO, alignez les pools de nœuds Worker sur les mêmes exigences de charge de travail MAS et Azure capacité régionale.

Si vous avez besoin d’une zone de rebond pour utiliser l’interface de ligne de commande OpenShift oc ou pour installer MAS, déployez une machine virtuelle Linux prise en charge qui répond aux exigences d’administration et de sécurité de votre organisation.

Configuration réseau

Pour ARO, utilisez la configuration de mise en réseau OpenShift par défaut que ARO déploie, sauf si IBM, Red Hat et votre équipe réseau valident une autre option. Planifiez le réseau virtuel et les sous-réseaux distincts pour les nœuds du plan de contrôle ARO, les nœuds Worker, les dépendances de service Azure, les points de terminaison privés, les bases de données et la connectivité hybride. Dimensionner les sous-réseaux de nœuds pour le nombre de nœuds Worker OpenShift dont vous avez besoin, notamment la capacité de mise à niveau et le scale-out ultérieur.

Pour OpenShift auto-géré, incluez également les exigences d’infrastructure créées par le programme d’amorçage et le programme d’installation. Conservez l’accès administratif à l’API OpenShift et aux nœuds limités aux chemins réseau approuvés, tels que la connectivité hybride, les hôtes de rebond sécurisés ou d’autres contrôles requis par votre organisation. Si vous limitez la sortie du cluster, planifiez les dépendances sortantes requises pour OpenShift, l’installation de MAS, les extractions d’images conteneur, les mises à jour, la surveillance et les services externes.

Pour une installation de production MAS standard sur ARO, ne commencez pas par un réseau virtuel étroitement packé. Réservez un espace d’adressage plus grand, tel qu’un préfixe CIDR (Classless Inter-Domain Routing) de /16 lorsque votre zone d’atterrissage l’autorise et allouez des sous-réseaux dédiés. Utilisez au moins une taille de planification /24 pour le sous-réseau du plan de contrôle ARO et au moins une taille de planification /24 pour le sous-réseau du nœud Worker. Ajoutez un sous-réseau /27 ou plus pour les points de terminaison privés et les services de base de données externes. Si vous déployez éventuellement Azure Bastion, ajoutez un sous-réseau nommé AzureBastionSubnet avec le préfixe /26. Pour plus d’informations sur les exigences Azure Bastion, consultez Architecture.

Si vous utilisez OpenShift autogéré et que vous manquez d’adresses IP, vous pouvez concevoir une configuration à haut niveau de disponibilité limitée avec un préfixe minimal de /27 pour le sous-réseau du nœud de contrôle et /27 pour le sous-réseau de nœud Worker. N’utilisez pas ce dimensionnement limité comme point de départ pour un déploiement de production ARO. Ne pas sous-réseaux de réseau virtuel ou de nœud. Readdressing an OpenShift deployment after installation is disrupt and might require redeployment.

Si vous souhaitez utiliser une autre interface réseau de conteneur (CNI), dimensionner vos réseaux en conséquence. MAS avec certaines applications standard déploie plus de 800 pods, ce qui nécessite probablement un préfixe CIDR de /21 ou plus.

Spécificités de la base de données

Certains composants MAS utilisent MongoDB comme magasin de métadonnées. Les instructions par défaut sont de déployer MongoDB Community Edition à l’intérieur du cluster. Si vous utilisez cette méthode, vérifiez que vous disposez d’une procédure appropriée pour sauvegarder et restaurer la base de données. Envisagez d’utiliser MongoDB Atlas sur Azure pour fournir un magasin, des sauvegardes et une mise à l’échelle externalisés. Azure ne prend actuellement pas en charge l'utilisation des API MongoDB avec Azure Cosmos DB.

Si vous déployez des services IoT, vous devez également fournir un point de terminaison Kafka. Les instructions par défaut sont d’utiliser Strimzi pour déployer Kafka à l’intérieur du cluster OpenShift, mais les données de Strimzi sont probablement perdues lors de la récupération d’urgence. Si la perte de données dans Kafka est inacceptable, envisagez d’utiliser Confluent Kafka sur Azure. Actuellement, Azure Event Hubs n'est pas pris en charge avec les points de terminaison Kafka.

MAS inclut plusieurs bases de données dans ses pods, et ces bases de données conservent leurs états sur le système de fichiers fourni pour MAS. Pour absorber les défaillances de zone, utilisez un mécanisme de stockage redondant interzone (ZRS) pour conserver les états en dehors de vos clusters. Le modèle recommandé consiste à utiliser Azure stockage de fichiers avec les configurations suivantes :

• Standard fournit des partages SMB pour les charges de travail ReadWriteOnce (RWO) à débit inférieur. Utilisez Standard pour les parties de l’application qui n’écrivent pas souvent dans le stockage et nécessitent un seul volume persistant, tel que le stockage à niveau unique IBM.

• Premium fournit des partages NFS pour des charges de travail ReadWriteMany (RWX) plus élevées. Les volumes comme ceux-ci sont utilisés dans tout le cluster pour les charges de travail RWX, telles que Db2 Warehouse dans Cloud Pak for Data ou Postgres dans Maximo Manage.

Azure Files NFS prend en charge le chiffrement en transit. Si le client MAS OpenShift ne peut pas utiliser le chiffrement NFS, vous pouvez exempter le compte des stratégies d’application de transfert sécurisées. Pour plus d’informations, consultez NFS Azure partages de fichiers : Chiffrement. Utilisez un point de terminaison privé pour fournir une connectivité privée à vos partages.

Si vous déployez Db2 Warehouse via Cloud Pak for Data, utilisez OpenShift Data Foundation. Pour obtenir un exemple OpenShift Data Foundation qui utilise des classes de stockage Ceph File System (CephFS) et RADOS Block Device (Ceph RBD) pour différents types de données Db2 Warehouse, consultez Création de l’instance Db2 à l’aide de la console Cloud Pak for Data.

N'utilisez pas Stockage Blob Azure avec les pilotes CSI (Container Storage Interface), car il ne prend pas en charge les liens durs, que certains pods nécessitent d'exécuter.

Considérations

Ces considérations implémentent les piliers de l’infrastructure Azure Well-Architected, qui est un ensemble de tenets guidants que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

OpenShift offre des fonctionnalités intégrées pour la réparation automatique, la mise à l’échelle et la résilience. OpenShift et MAS s’attendent à ce que les composants échouent et récupèrent. Une condition essentielle pour la réparation automatique est que le cluster dispose de suffisamment de nœuds Worker. Pour récupérer d'une défaillance de zone au sein d'une région Azure, vos nœuds de contrôle et de calcul doivent être équilibrés entre les zones de disponibilité.

MAS et OpenShift utilisent le stockage pour conserver l’état en dehors du cluster Kubernetes. Pour vous assurer que les dépendances de stockage continuent de fonctionner pendant une défaillance, utilisez dans la mesure du possible le stockage redondant interzone. Le stockage redondant interzone reste disponible lorsqu’une seule zone échoue.

Pour éviter les erreurs humaines, déployez MAS en utilisant autant d’automatisation que possible. Utilisez la documentation actuelle sur l’installation d’IBM et l’automatisation prise en charge pour votre version MAS sélectionnée, la plateforme OpenShift et le chemin de déploiement.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

Le maintien de l’accès et de la visibilité dans le cycle de vie de maintenance de vos ressources peut être l’une des plus grandes opportunités de votre organisation de fonctionner efficacement et de maintenir le temps de fonctionnement. Pour améliorer la posture de sécurité de votre environnement, il est important d’utiliser l’authentification sécurisée et de maintenir vos solutions à jour. Utilisez le chiffrement pour protéger toutes les données qui se déplacent tant à l’intérieur qu’à l’extérieur de votre architecture.

En utilisant des déploiements ARO, vous bénéficiez du modèle de responsabilité partagée ARO. Azure Red Hat OpenShift est conjointement conçu, exploité et pris en charge par Microsoft et Red Hat, qui corrigent, mettent à jour et surveillent la plateforme OpenShift gérée en votre nom. Vous restez responsable des déploiements en plus d’ARO. Cette responsabilité inclut MAS et sa configuration d’application, l’intégration d’identité, les contrôles réseau, la planification de la capacité de travail, les choix de stockage, la sauvegarde et la récupération d’urgence, les secrets, la protection des données et les exigences de conformité. Pour plus d’informations, consultez Présentation de Azure Red Hat OpenShift et Azure Red Hat OpenShift stratégie de support 4.0.

Microsoft crée des protections de sécurité dans la plateforme Azure aux niveaux suivants :

• Centre de données physique
• Réseau physique
• Hôte physique
• Hyperviseur

Utilisez une version OpenShift prise en charge par votre plateforme OpenShift et ibm prend en charge votre version et vos applications MAS. Dans la mesure du possible, utilisez une version de support à long terme prise en charge. Si vous utilisez OpenShift auto-géré, vous êtes responsable de la mise à jour corrective et de la maintenance de la plateforme OpenShift et des machines virtuelles sous-jacentes. Si vous utilisez ARO, Microsoft gère les correctifs et la gestion.

Utilisez des groupes de sécurité réseau pour filtrer le trafic réseau vers et depuis les ressources dans votre réseau virtuel. En utilisant ces groupes, vous pouvez définir des règles qui accordent ou refusent l’accès à vos services MAS, par exemple :

• Autoriser l’accès SSH aux nœuds OpenShift pour la résolution des problèmes.
• Blocage de l’accès à toutes les autres parties du cluster.
• Contrôle des emplacements qui peuvent accéder à MAS et au cluster OpenShift.

Pour accéder à vos machines virtuelles, vous pouvez vous connecter via la connectivité hybride ou via la console d’administration OpenShift. Si vous disposez d'un déploiement en ligne ou que vous ne souhaitez pas vous appuyer sur la connectivité hybride, vous pouvez accéder à vos machines virtuelles via Azure Bastion. Pour des raisons de sécurité, n’exposez pas de machines virtuelles à un réseau ou à Internet sans configurer de groupes de sécurité réseau pour contrôler l’accès.

Le chiffrement côté serveur (SSE) de Stockage sur disque Azure protège vos données et vous aide à respecter les engagements de sécurité et de conformité de l’organisation. Avec Azure disques managés, SSE chiffre les données au repos lors de leur conservation dans le cloud. Ce comportement s’applique par défaut tant au système d’exploitation qu’aux disques de données. OpenShift utilise SSE par défaut.

Authentification

MAS prend en charge l’authentification unique avec Security Assertion Markup Language (SAML). Pour utiliser Microsoft Entra ID comme fournisseur d’identité SAML, créez une application d’entreprise dans Microsoft Entra ID et configurez MAS comme fournisseur de services. Pour plus d’informations, consultez l’intégration de Microsoft Entra SSO avec Maximo Application Suite.

Avant de configurer l’authentification SAML, passez en revue la configuration IBM et la configuration Azure. Pour plus d’informations sur SAML avec MAS, consultez Configuration de l’authentification SAML. Pour plus d’informations sur SAML avec Azure, consultez Quickstart : Activer l’authentification unique pour une application d’entreprise.

Vous devez également configurer OAuth pour l’accès administratif OpenShift. Pour ARO, consultez Configurer l’authentification Microsoft Entra pour un cluster Azure Red Hat OpenShift. Pour openShift auto-géré, consultez Configuration des fournisseurs d’identité dans OpenShift Container Platform 4.21.

Accès aux ressources et audit

Contrôlez l’accès aux ressources Azure que vous déployez. Chaque abonnement Azure a une relation de confiance avec un locataire Microsoft Entra. Utilisez le contrôle d’accès en fonction du rôle Azure (RBAC Azure) pour accorder aux utilisateurs de votre organisation les autorisations d’accès appropriées sur les ressources Azure. Accordez l’accès en affectant Azure rôles à des utilisateurs ou des groupes à une certaine étendue, comme un abonnement, un groupe de ressources ou une ressource unique. Auditez toutes les modifications apportées à l’infrastructure. Pour plus d’informations sur l’audit, consultez Azure Monitor journal d’activité.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de vérification de conception pour l’optimisation des coûts.

Un déploiement MAS standard sur Azure inclut les principaux pilotes de coûts suivants :

• Coûts du cluster ARO, y compris les nœuds Worker et les frais de plan de contrôle ou de cluster facturables
• Pools de nœuds Worker dimensionnés pour MAS Core et les applications MAS que vous déployez
• Nœuds worker GPU facultatifs pour Maximo Visual Inspection
• Services de base de données, tels que SQL Managed Instance, Db2 Warehouse ou une autre base de données prise en charge par IBM
• Comptes de stockage ou services de stockage managés pour les volumes persistants, les sauvegardes et les artefacts d’installation
• Zones DNS, équilibrage de charge, points de terminaison privés et instance facultative de Azure Bastion

Pour ARO et OpenShift auto-géré, un déploiement MAS standard utilise généralement la même ligne de base de dimensionnement de nœud worker. Utilisez l’inventaire suivant comme point de départ pour l’estimation des coûts :

• Six machines virtuelles worker.
• Trois machines virtuelles worker pour Db2 Warehouse. Vous pouvez remplacer SQL Managed Instance dans certaines configurations au lieu d’utiliser Db2 Warehouse.
• Deux comptes stockage Azure.
• Deux zones DNS.
• Deux équilibreurs de charge.
• Azure Bastion.
• Un nœud worker GPU Maximo Visual Inspection, si vous envisagez d’exécuter Maximo Visual Inspection à l’intérieur de MAS.

Le coût du plan de contrôle diffère du modèle de déploiement. Pour les déploiements OpenShift auto-gérés qui utilisent IPI ou UPI, incluent également trois machines virtuelles de contrôle. Pour ARO, comptez le plan de contrôle managé et les frais de cluster spécifiques à ARO au lieu d’ajouter des machines virtuelles de contrôle géré par le client.

Vous pouvez consulter un exemple d’estimation à l’aide de la calculatrice de coûts. Les configurations varient. Vérifiez donc votre configuration avec votre équipe de dimensionnement IBM avant de finaliser votre déploiement.

Déployer ce scénario

Avant de commencer, passez en revue la configuration système requise d’IBM Maximo Application Suite et IBM SPCR pour votre version et vos applications MAS. Disposez des ressources suivantes avant de commencer le déploiement :

• Accès à un abonnement Azure avec l’autorisation Lecteur
• Un nom d’inscription d’application ou de principal de service disposant des autorisations Contributeur et Administrateur de l’accès utilisateur à l’abonnement
• Un domaine ou un sous-domaine délégué à une zone Azure DNS
• Un cluster ARO pris en charge ou les autorisations et conditions préalables à la création d’un cluster ARO pris en charge
• Secret d’extraction de Red Hat si votre chemin de déploiement crée ou gère l’infrastructure OpenShift
• Une clé de droit MAS
• Fichier de licence MAS que vous créez après l’installation de MAS
• Dimensionnement de cluster recommandé par IBM
• Un réseau virtuel existant ou un nouveau réseau virtuel qui répond aux exigences ARO et MAS
• Exigences de haute disponibilité et de récupération d’urgence pour votre déploiement spécifique
• Détails de configuration pour le chemin d’accès de déploiement sélectionné, tels que les détails du cluster ARO ou les paramètres d’installation OpenShift auto-gérés

Avant de créer votre environnement, consultez ibm Planning à installer sur Microsoft Azure documentation pour comprendre les paramètres de conception. Pour obtenir des instructions d’installation actuelles Azure, consultez Maximo Application Suite sur Microsoft Azure vue d’ensemble. Validez votre processus de déploiement par rapport à la documentation IBM actuelle et à la matrice de prise en charge de votre version MAS.

Points à prendre en considération pour le déploiement

Déployez des charges de travail à l’aide de l’infrastructure en tant que code (IaC) plutôt que manuellement. Le déploiement manuel peut entraîner une mauvaise configuration. Les charges de travail basées sur des conteneurs peuvent être sensibles à la configuration incorrecte, ce qui peut réduire la productivité.

IBM offre des services spécialisés pour vous aider à installer. Contactez votre équipe IBM pour obtenir du support.

Contributeurs

Microsoft conserve cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

• David Baumbaum | Architecte principal
• Roeland Nieuwenhuis | Architecte en chef

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Pour obtenir de l'aide pour commencer, consultez les ressources suivantes :

• Azure Red Hat OpenShift
• Vue d’ensemble de Maximo Application Suite sur Microsoft Azure
• Planification de l’installation sur Microsoft Azure
• Installation d’OpenShift sur Azure
• Guide d’UPI OpenShift
• Conditions requises pour Maximo
• Rapports de compatibilité des produits logiciels IBM
• IBM Maximo Application Suite (BYOL)

Pour en savoir plus sur les technologies proposées, consultez les ressources suivantes :

• IBM Passport Advantage
• Introduction à Azure DNS
• Introduction à Azure NetApp Files
• Présentation de Azure Red Hat OpenShift
• Portail des clients Red Hat

Ressources associées

• Azure partage de fichiers cloud d’entreprise
• Déployer une application Java utilisant la plateforme d'applications d'entreprise JBoss (EAP) sur un cluster ARO