Déployer IBM Maximo Application Suite (MAS) sur Azure

IBM Maximo Application Suite (MAS) 8.x s’exécute sur OpenShift, et il est utile de vous familiariser avec OpenShift et les modèles suggérés pour l’installation sur Azure. Pour plus d’informations, consultez Préparation à l’installation sur Azure. Cette architecture illustre un cluster OpenShift. L’installation de MAS n’est pas détaillée. Pour en savoir plus sur le processus d’installation, consultez Installation de Maximo Application Suite à partir d’OperatorHub.

Architecture

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

La charge de travail peut être déployée en interne ou en externe, en fonction de vos besoins.

Workflow

Du point de vue de l’infrastructure, cette architecture fournit les éléments suivants :

• Plateforme d’hébergement de conteneurs pour déployer des charges de travail hautement disponibles dans des zones de disponibilité
• Déploiement privatisé de nœuds de travail et de contrôle intégrés au stockage
• Fichiers Premium Azure et fichiers standard pour le stockage (OpenShift Data Foundation non requis)
• SQL Server sur machines virtuelles Azure ou un entrepôt IBM Db2 basé sur un conteneur
• Azure DNS pour la gestion DNS d’OpenShift et de ses conteneurs
• Microsoft Entra ID pour l'authentification unique dans MAS

Composants

• Les machines virtuelles Azure pour héberger la plateforme OpenShift et exécuter les conteneurs Maximo. Machines virtuelles est une offre IaaS (Infrastructure-as-a-Service). Vous pouvez utiliser des machines virtuelles pour déployer des ressources de calcul à la demande et évolutives.

• Red Hat Enterprise Linux CoreOS pour fournir une image de machine virtuelle personnalisée pour OpenShift.

• Équilibreurs de charge Azure pour fournir une connectivité au cluster. Azure Load Balancer est un service d’équilibrage de charge de 4e couche à ultra faible latence et hautes performances (en entrée et en sortie) pour tous les protocoles UDP et TCP. Il est conçu pour gérer des millions de demandes par seconde, tout en garantissant la haute disponibilité de votre solution. Azure Load Balancer est redondant interzone, garantissant une haute disponibilité de la fonctionnalité Zones de disponibilité.

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

• Azure Files hébergeant les données avec état des bases de données et des systèmes à l’intérieur du cluster. Azure Files offre des partages de fichiers complètement managés dans le cloud, accessibles via les protocoles SMB et NFS.

• Azure DNS pour gérer 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 (facultatif) et un sous-réseau pour accéder en toute sécurité à l’un des nœuds Worker ou aux machines JumpBox facultatives. Azure Bastion est un service complètement managé qui fournit un accès RDP et SSH sécurisé et transparent aux machines virtuelles sans exposition via des adresses IP publiques.

• SQL Server sur Machines virtuelles Azure (facultatif) SQL Server sur Machines virtuelles Azure pour fournir des services de données à MAS. La base de données peut également être une autre, comme Oracle Exadata ou IBM Db2 Warehouse. Azure SQL Database et Azure SQL Managed Instance ne sont pas pris en charge pour l’instant.

• Twilio Send Grid (facultatif) pour envoyer des e-mails de MAS à vos consommateurs.

• Machines virtuelles Linux dans Azure (facultatif) pour fournir une zone de saut pour l’installation d’OpenShift. Vous pouvez également utiliser cette machine virtuelle pour connecter et gérer le cluster OpenShift, car elle contient le fichier de configuration Kubernetes après l’installation. Si vous disposez d’une connectivité réseau dans votre environnement Azure, vous pouvez effectuer l’installation à partir d’un ordinateur existant.

Autres solutions

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

• Azure NetApp Files comme remplacement de Azure Files. NetApp Files prend en charge n’importe quel type de charge de travail avec une haute disponibilité et des performances élevées.
• Oracle Database sur Azure si vous préférez SQL Server ou Db2 Warehouse.
• OpenShift Data Foundation si vous souhaitez utiliser Db2 Warehouse sur OpenShift Data Foundation.

Détails du scénario

IBM Maximo Application Suite (MAS), également appelé Maximo, est une plateforme de gestion des ressources d’entreprise avec la maintenance des ressources basée sur l’IA. MAS se concentre sur la résilience opérationnelle et la fiabilité. La suite se compose d’une plateforme d’applications de base, MAS et d’applications et de solutions spécifiques au secteur au-dessus de la plateforme. Chaque application offre un avantage spécifique :

• Gérer. Réduire le temps et les coûts en utilisant la gestion des ressources pour améliorer les performances opérationnelles.
• Surveiller. Utiliser IoT pour une surveillance avancée basée sur l’IA des ressources distantes à grande échelle.
• Intégrité. Gérer 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. Entraîner des modèles Machine Learning pour utiliser l’inspection visuelle pour l’analyse visuelle des problèmes émergents.
• Prédire. Prédire les échecs futurs à l’aide du Machine Learning et de l’analytique des données.
• Aider. Aider les techniciens en fournissant des conseils basés sur l’IA à un base de connaissances de données de maintenance de l’équipement et en leur donnant un accès à distance aux experts.
• Sécurité. Collecter et analyser des données à partir de capteurs, fournir des données contextuelles et dériver des analyses significatives.
• Civil. Intégrer l’inspection, le suivi des défauts et les activités de maintenance pour améliorer la durée de vie des ressources, maintenir le fonctionnement des systèmes critiques et réduire les coûts totaux de propriété de l’infrastructure civile.

Ces applications et MAS 8.x sont testés pour une utilisation sur Azure. Microsoft et l’équipe IBM Maximo sont partenaires pour garantir que cette solution est configurée pour s’exécuter de manière optimale sur Azure. Cet article fournit une conception pour l’exécution de MAS 8.x sur Azure pour les clients qui prennent en charge IBM et un partenaire pour l’installation. Contactez votre équipe IBM pour des questions spécifiques au produit. Le Place de marché Azure offre une autre installation pour MAS qui prend en charge l’apport de votre propre licence. Pour plus d’informations, consultez IBM Maximo Application Suite (BYOL).

Cas d’usage potentiels

De nombreuses industries et secteurs utilisent les solutions dans MAS, telles que :

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

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

Recommandations

Nous vous recommandons d’installer la dernière version stable de MAS, car elle fournit les meilleures options d’intégration avec Azure. Soyez attentif aux versions d’OpenShift prises en charge, car les versions prises en charge varient avec la version spécifique de MAS.

L’utilisation de versions majeures antérieures ou ultérieures d’OpenShift peut entraîner une chute de la prise en charge officielle de MAS. Avant de créer votre propre déploiement, nous vous recommandons d’utiliser le guide de démarrage rapide pour déployer MAS afin de comprendre le fonctionnement du déploiement et de la configuration. Savoir comment cela est fait accélère la création des exigences de conception pour votre implémentation. Pour plus d’informations, consultez guide de démarrage rapide : Maximo Application Suite sur Azure.

Nous travaillons en étroite collaboration avec IBM et d’autres partenaires pour vous assurer que les conseils, l’architecture et le guide de démarrage rapide vous offrent la meilleure expérience sur Azure. Ils suivent les meilleures pratiques décrites dans Microsoft Azure Well-Architected Framework. Contactez votre équipe de compte IBM pour obtenir du support au-delà de cette documentation.

Avant de poursuivre votre déploiement, vous devez répondre aux questions suivantes sur la conception :

• Quelles applications MAS avez-vous besoin ?
• Quelles sont les dépendances dont disposent vos applications ?
• Quelle version d’OpenShift est requise ?
• Quelle méthode d’installation d’OpenShift devez-vous utiliser ?
• Quelles bases de données sont nécessaires ?
• Quel nombre et taille de machines virtuelles avez-vous besoin ?
• Les utilisateurs se connecteront-ils à partir de réseaux externes ?

Maximo Application Suite

Microsoft a testé MAS versions 8.5 et ultérieures sur Azure. Notre recommandation est d’utiliser la dernière version de MAS, qui est la version 8.7.

Passez en revue les applications MAS dont vous avez besoin pour votre scénario métier complet, puis passez en revue les exigences pour chacune des applications. Pour plus d’informations, consultez Exigences système IBM Maximo Application Suite. Chacune des applications peut avoir besoin de bases de données distinctes. Nous avons testé et pris en charge les bases de données suivantes sur Azure :

• SQL Server sur Machines virtuelles Azure version 2019 utilisant Windows ou Linux
• IBM Db2 Warehouse sur Cloud Pak for Data 3.5

Vous pouvez également choisir d’exécuter Oracle Exadata sur une machine virtuelle ou sur Oracle Cloud Infrastructure à l’aide de l’interconnexion, mais ce n’est pas une configuration testée. Pour plus d’informations sur l’interconnexion, consultez En savoir plus sur l’interconnexion d’Oracle Cloud avec Microsoft Azure. Actuellement, Azure SQL Database, Azure SQL Managed Instance et Azure Cosmos DB ne sont pas pris en charge.

MAS et certaines de ses applications ont des dépendances sur MongoDB et Kafka. Décidez comment déployer ces solutions en fonction des considérations relatives aux performances et aux opérations. Les valeurs par défaut sont de déployer MongoDB Community Edition et Strimzi Kafka à l’intérieur des clusters. Certaines des conditions préalables de MAS, par exemple BAS, utilisent des bases de données qui ne peuvent pas être externalisées, mais qui 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, la sauvegarde fréquente des données et le déplacement des sauvegardes dans une autre région sont nécessaires. Concevez et planifiez une stratégie de récupération d’urgence, et décidez en conséquence, en particulier lors de l’exécution de Kafka ou de MongoDB à l’intérieur d’OpenShift.

Pour les services qui conservent l’état, utilisez des offres PaaS (Platform as a Service) Azure externes lorsque cela est possible. Cela améliore la prise en charge lors d’une panne.

Certains des 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 les outils et services sur le même cluster OpenShift.

OpenShift

Avant d’installer OpenShift, vous devez déterminer la méthode que vous utiliserez :

• Programme d’installation de l’infrastructure provisionnée (IPI). Cette méthode utilise un programme d’installation pour déployer et configurer l’environnement OpenShift sur Azure. IPI est la méthode la plus courante pour le déploiement sur Azure, et vous devez utiliser IPI, sauf si vos exigences de sécurité sont trop strictes pour le faire.

• Infrastructure approvisionné par l’utilisateur (UPI). Cette méthode permet un contrôle précis sur votre déploiement. L’UPI nécessite davantage d’étapes et de considérations pour créer votre environnement. Utilisez l’UPI si l’IPI ne répond pas à vos besoins. Un cas d’usage courant pour l’UPI est destiné à une installation privée déconnectée. Choisissez l’UPI lorsque vous n’avez pas d’accès Internet sortant lors de la création de l’environnement.

Nous vous recommandons d’utiliser l’IPI chaque fois que possible, car elle réduit considérablement la quantité de travail nécessaire pour terminer l’installation d’OpenShift.

Lors de l’installation d’OpenShift, vous devez résoudre les considérations suivantes :

• Sélection de la région. Nous vous recommandons d’utiliser une région avec des zones de disponibilité. Pendant le déploiement, OpenShift tente automatiquement de créer des nœuds entre les zones en fonction de la configuration dans le fichier de configuration, install-config.yaml. Par défaut, OpenShift équilibre les charges de travail sur tous les nœuds disponibles et dans les zones de disponibilité. S’il existe une panne dans une zone, votre solution peut continuer à fonctionner en ayant des nœuds dans d’autres zones qui peuvent reprendre le travail.

• Sauvegarde et récupération. Vous pouvez utiliser les instructions relatives à Azure Red Hat OpenShift pour la sauvegarde et la récupération. Pour plus d’informations, consultez Créer 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 eux et Internet pour rediriger le trafic vers le cluster approprié en cas de panne d’une région. Dans ce cas, vous devez également migrer les états de vos applications et les volumes persistants.

Installations déconnectée

Dans certains cas, comme pour la conformité réglementaire, vous devrez peut-être installer MAS sur Azure en cas d’installation déconnectée. Déconnecté (ou « 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 d’installation au moment de l’exécution pour l’installation de MAS ou d’OpenShift.

Nous vous déconseillons d’effectuer une installation déconnectée, sauf s’il s’agit d’une exigence de sécurité. Un état déconnecté ajoute une complexité significative aux opérations de votre solution. Les activités telles que l’installation de logiciels, les conteneurs de mise en miroir, la mise à jour d’un miroir pour se protéger contre les vulnérabilités de sécurité et la gestion d’un pare-feu peuvent prendre beaucoup de temps.

Pour plus d’informations sur les installations déconnectées, consultez la documentation OpenShift suivante :

• Mise en miroir d’images pour une installation déconnectée
• Installation d’un cluster privé sur Azure

Une fois que vous avez installé OpenShift, consultez la documentation MAS pour obtenir des conseils similaires.

Dimensionnement de votre environnement

Pour toutes les charges de travail (à l’exception de l’inspection visuelle), nous vous recommandons d’utiliser les dernières machines virtuelles de la série Ds en tant que nœuds Worker. Voici quelques exemples : Dsv3, Dasv4, Dsv4, Dasv5 ou Dsv5. Nous vous recommandons d’utiliser les dernières versions, si possible, car elles offrent de meilleures performances. Utilisez uniquement des machines virtuelles possédant un stockage Premium.

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. Les types de machines virtuelles recommandés sont NCv3 et NCasT4_v3. Si vous devez effectuer l’apprentissage à l’aide de YOLOv3, vous aurez besoin de GPU basés sur Ampere. Utilisez la NVadsA10 v5 ou NC A100 v4 pour des tâches d’entraînement plus volumineuses.

Pour les machines GPU, nous vous recommandons de commencer par le plus petit nœud et de monter en puissance à mesure que vos besoins augmentent.

Pour toutes les autres machines, nous vous recommandons de configurer des machines virtuelles entre des zones de disponibilité pour prendre en charge la haute disponibilité. Configurez les nœuds comme suit :

• Nœuds de contrôle. Un minimum d’une machine virtuelle par zone de disponibilité dans la région sélectionnée. Nous avons recommandé d’avoir au moins 4 processeurs virtuels. Notre référence utilise 3x nœuds Standard_D8s_v4.

• Nœuds worker. Un minimum de deux machines par zone de disponibilité dans la région sélectionnée. Nous avons recommandé d’avoir au moins 8 processeurs virtuels. Notre référence utilise 6x nœuds Standard_D8s_v4.

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, Gérer pour 10 utilisateurs nécessite 2 processeurs virtuels. Nous vous recommandons de consulter la configuration système IBM Maximo Application Suite pour obtenir une bonne estimation du dimensionnement.

Essayez de conserver les 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. Autrement dit, si vous utilisez une machine virtuelle v4 pour vos nœuds de contrôle, utilisez également une machine virtuelle v4 pour vos nœuds Worker.

Si vous avez besoin d’une jump box pour utiliser l’interface de ligne de commande OpenShift (oc) ou pour installer MAS, déployez une machine virtuelle exécutant Red Hat Enterprise Linux version 8.4.

Réseau

Avec OpenShift, nous utilisons le fournisseur DNI (Container Network Interface) par défaut du SDN (Software-Defined Networking) d’OpenShift. Pour plus d’informations sur la CNI OpenShift par défaut, consultez l’opérateur de réseau de cluster dans OpenShift Container Platform. Vous devez dimensionner votre réseau pour le nombre de nœuds worker et de contrôle OpenShift dont vous avez besoin, ainsi que pour toutes les autres exigences, telles que les bases de données et les comptes de stockage.

Pour une installation de production MAS standard, nous recommandons un réseau virtuel avec l’espace d’adressage fourni par un préfixe CIDR de /24. Le réseau virtuel a trois ou quatre sous-réseaux (pour Bastion). Pour OpenShift, le sous-réseau pour les nœuds Worker a un préfixe CIDR de /25 et les nœuds de contrôle ont un préfixe de /27. Un sous-réseau pour les points de terminaison et un serveur de base de données externe facultatif doit avoir un préfixe /27. Si vous déployez Azure Bastion, qui est facultatif, vous avez besoin d’un sous-réseau nommé AzureBastionSubnet avec le préfixe /26. Pour plus d’informations sur la configuration requise pour Azure Bastion, consultez Architecture.

Si vous êtes court sur les adresses IP, vous pouvez implémenter une configuration hautement disponible avec un préfixe minimal de /27 pour le sous-réseau des nœuds de contrôle et /27 pour le sous-réseau des nœuds Worker.

Si vous souhaitez utiliser une autre CNI, dimensionnez 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

Différents composants de 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 la déployez à l’aide de 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, car il fournit un magasin externalisé, des sauvegardes, une mise à l’échelle, etc. 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 dans le cluster OpenShift. Lors d’une récupération d’urgence, les données à l’intérieur de Strimzi seront probablement perdues. Si la perte de données dans Kafka est inacceptable, vous devez envisager d’utiliser Confluent Kafka sur Azure. Actuellement, Azure Event Hubs avec des points de terminaison Kafka ne sont pas pris en charge.

MAS est fourni avec de nombreuses bases de données à l’intérieur de ses pods, et ces bases de données conservent leurs états sur le système de fichiers fourni pour MAS. Nous vous recommandons d’utiliser un mécanisme de stockage redondant interzone pour conserver les états en dehors de vos clusters pour pouvoir absorber les défaillances de zone. Notre modèle recommandé consiste à utiliser Stockage Fichier Azure avec les configurations suivantes :

• Standard. Fournit des partages SMB (Server Message Block) pour les charges de travail ReadWriteOnce (RWO) à débit inférieur. La norme est idéale pour les parties de l’application qui n’écrivent pas souvent dans le stockage et nécessitent un volume persistant unique (par exemple, un stockage à niveau unique IBM).

• Premium. Fournit des partages NFS (Network File System) pour des charges de travail ReadWriteMany (RWX) plus élevées. Les volumes comme ceux-ci sont utilisés dans l’ensemble du cluster pour les charges de travail RWX, tels que Db2 Warehouse dans Cloud Pak for Data ou Postgres dans Manage.

Veillez à désactiver les stratégies pour appliquer le transfert sécurisé sur le Stockage Blob Azure ou exempter les comptes de ces stratégies. Azure Premium Files avec NFS nécessite que le transfert sécurisé soit désactivé. Veillez à utiliser un point de terminaison privé pour garantir la connectivité privée à vos partages.

Par défaut, Db2 Warehouse se déploie sur OpenShift Data Foundation (anciennement OpenShift Container Storage). Pour des raisons de coût, de performances, de mise à l’échelle et de fiabilité, nous vous recommandons d’utiliser Azure Premium Files avec NFS au lieu d’OpenShift Data Foundation.

N’utilisez pas d’objet blob Azure avec des pilotes CSI, car il ne prend pas en charge les liens durs, qui sont requis. Certains pods ne peuvent pas s’exécuter sans liens durs.

Considérations

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

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier 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 un chiffrement pour protéger toutes les données qui se déplacent tant à l’intérieur qu’à l’extérieur de votre architecture.

Azure fournit MAS à l’aide des modèles d’infrastructure as a service (IaaS) et PaaS. Microsoft crée des protections de sécurité dans le service aux niveaux suivants :

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

Évaluez soigneusement les services et technologies que vous sélectionnez pour les zones situées au-dessus de l’hyperviseur, telles que la dernière version corrigée d’OpenShift pour une version majeure. Veillez à fournir les contrôles de sécurité appropriés pour votre architecture. Vous êtes responsable de la mise à jour corrective et de la maintenance de la sécurité des systèmes IaaS. Microsoft prend ce rôle pour les services PaaS.

Utilisez des groupes de sécurité réseau (NSG) pour filtrer le trafic réseau échangé avec des ressources au sein de votre réseau virtuel. Avec ces groupes, vous pouvez définir des règles qui accordent ou refusent l’accès à vos services SAS. Voici quelques exemples :

• Autoriser l’accès SSH aux nœuds OpenShift pour la résolution des problèmes
• Bloquer l’accès à toutes les autres parties du cluster
• Contrôler quels emplacements peuvent avoir accès à MAS et au cluster OpenShift

Si vous avez besoin d’accéder à vos machines virtuelles pour une raison quelconque, vous pouvez vous connecter via votre 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é, vous pouvez également accéder à vos machines virtuelles via Azure Bastion (facultatif). Pour des raisons de sécurité, vous ne devez pas exposer de machines virtuelles à un réseau ou à Internet sans configurer des groupes de sécurité réseau pour contrôler l’accès à ces machines.

Le chiffrement côté serveur (SSE) de Stockage sur disque Azure protège vos données. Il vous aide également à respecter les engagements de votre organisation en matière de sécurité et de conformité. Avec des disques managés Azure, SSE chiffre les données au repos conservées 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 actuellement en charge l'utilisation du langage SAML (Security Assertion Markup Language) via Microsoft Entra ID. Pour que cela fonctionne, vous avez besoin d'une application d'entreprise au sein de Microsoft Entra ID et soit de l'autorisation de modifier l'application, soit de l'assistance d'un administrateur global qui peut apporter les modifications nécessaires.

Le guide de démarrage rapide sur GitHub présente un didacticiel sur la configuration de SAML avec MAS. Pour plus d'informations, consultez Activation de l'authentification SAML par rapport à Microsoft Entra ID.

Avant de configurer l’authentification SAML, nous vous recommandons de passer par la configuration IBM et la configuration Azure. Pour plus d’informations sur SAML avec MAS, consultez SAML dans la documentation relative à MAS. Pour plus d’informations sur SAML avec Azure, consultez Démarrage rapide : Activer l’authentification unique pour une application d’entreprise.

Vous devez également configurer OAuth pour OpenShift. Pour plus d’informations, consultez Vue d’ensemble de l’authentification et de l’autorisation dans la documentation OpenShift.

Protéger votre infrastructure

Contrôlez l’accès aux ressources Azure que vous déployez. Chaque abonnement Azure entretient une relation d’approbation 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 assignant des rôles Azure à des utilisateurs ou à des groupes jusqu’à une certaine étendue. L’étendue peut être appliquée à un abonnement, à un groupe de ressources ou à une ressource unique. Veillez à auditer tous les changements apportés à l’infrastructure. Pour plus d’informations sur l’audit, consultez le journal d’activité Azure Monitor.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Un déploiement standard de MAS se compose des composants suivants :

• 3 machines virtuelles de contrôle
• 6 machines virtuelles Worker
• 3 machines virtuelles Worker pour l’entrepôt Db2
  • Vous pouvez remplacer SQL Server sur Machines virtuelles Azure dans certaines configurations, plutôt que d’utiliser Db2 Warehouse.
• 2 comptes de stockage Azure
• 2 zones DNS
• 2 équilibreurs de charge
• Azure Bastion
• 1 machine virtuelle d’inspection visuelle
  • Cela n’est pas nécessaire, sauf si vous envisagez d’exécuter l’inspection visuelle à l’intérieur de MAS.

Vous pouvez consulter un exemple d’estimation à l’aide de notre calculatrice de coûts. Les configurations varient et vous devez vérifier votre configuration avec votre équipe de dimensionnement IBM avant de finaliser votre déploiement.

Fiabilité

OpenShift dispose de fonctionnalités intégrées pour la réparation automatique, la mise à l’échelle et la résilience pour vous assurer que OpenShift et MAS fonctionnent correctement. OpenShift et MAS ont été conçus pour les parties qui échouent et récupèrent. Une condition essentielle pour que l’auto-guérison fonctionne, c’est qu’il y a suffisamment de nœuds Worker. Pour effectuer une récupération à partir d’une défaillance de zone au sein d’une région Azure, vos nœuds de contrôle et de travail 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, vous devez utiliser le stockage redondant interzone chaque fois que possible. Ce type de stockage reste disponible lorsqu’une zone échoue.

Étant donné que l’erreur humaine est courante, vous devez déployer MAS en utilisant autant d’automatisation que possible. Dans notre guide de démarrage rapide, nous fournissons des exemples de scripts pour configurer une automatisation complète et complète.

Déployer ce scénario

Avant de commencer, nous vous recommandons de consulter la configuration système IBM Maximo Application Suite. Veillez à disposer des ressources suivantes avant de commencer le déploiement :

• Accès à un abonnement Azure avec autorisation Lecteur
• Nom d’inscription d’application ou principal de service disposant des autorisations Contributeur et Administrateur d’accès utilisateur à l’abonnement
• Domaine ou sous-domaine délégué à une zone Azure DNS
• Extraire le secret de Red Hat pour déployer OpenShift
• Clé de droit MAS
• Fichier de licence MAS (créé après l’installation de MAS)
• Dimensionnement de cluster recommandé par IBM
• Réseau virtuel existant ou réseau virtuel créé par IPI, en fonction de vos besoins
• Exigences de haute disponibilité et de récupération d’urgence pour votre déploiement spécifique
• Fichier de configuration, install-config.yaml, pour le programme d’installation

Pour obtenir un guide pas à pas pour installer OpenShift et MAS sur Azure, notamment comment répondre aux conditions préalables, consultez notre guide de démarrage rapide sur GitHub.

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

Il est préférable de déployer des charges de travail à l’aide de l’infrastructure en tant que code (IaC) plutôt que de déployer manuellement des charges de travail, car 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é.

Avant de créer votre environnement, passez en revue le guide de démarrage rapide pour développer une compréhension des paramètres de conception. Le guide de démarrage rapide n’est pas destiné à un déploiement prêt pour la production, mais vous pouvez utiliser les ressources du guide pour accéder à un mécanisme de niveau production pour le déploiement.

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

Contributeurs

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

Auteurs principaux :

• David Baumgarten | Architecte de solution cloud senior
• Roeland Nieuwenhuis | Architecte de solution cloud principale

Autre contributeur :

• Gary Moore | Programmeur/rédacteur

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

Étapes suivantes

Pour vous aider à commencer, consultez les ressources suivantes :

• Installation d’OpenShift sur Azure
• Guide de démarrage rapide : Maximo Application Suite sur Azure
• Guide d’UPI OpenShift
• Conditions requises pour Maximo
• IBM Maximo Application Suite (BYOL)

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

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

Ressources associées

• Partage de fichiers cloud Azure en entreprise
• Vue d’ensemble de la maintenance prédictive dans le secteur de l’industrie
• Déployer une application Java avec JBoss EAP sur un cluster ARO