Azure に IBM Maximo Application Suite をデプロイする

IBM Maximo Application Suite (MAS) 8.x は OpenShift 上で実行されます。OpenShift と Azure へのインストールに推奨されるパターンを理解することをお勧めします。 詳細については、「Azure でのインストールの準備」を参照してください。 このアーキテクチャは、OpenShift クラスターを示しています。 MAS のインストール方法については詳しく説明しません。 インストール プロセスの詳細については、 「OperatorHub からの Maximo Application Suite のインストール」を参照してください。

アーキテクチャ

このアーキテクチャの Visio ファイルをダウンロードします。

ワークロードは、要件に応じて、内部または外部にデプロイできます。

ワークフロー

インフラストラクチャの観点から、このアーキテクチャでは次のものが提供されます。

• 可用性ゾーン間で高可用性ワークロードをデプロイするコンテナー ホスティング プラットフォーム
• ストレージと統合された worker ノードと制御ノードの民営化されたデプロイ
• Azure Premium Files とストレージ用の標準ファイル (OpenShift Data Foundation は必要ありません)
• Azure VM 上の SQL Server、またはコンテナーベースの IBM Db2 Warehouse
• OpenShift とそのコンテナーの DNS 管理のための Azure DNS
• MAS へのシングルサインオン (SSO) のための Microsoft Entra ID

コンポーネント

• Azure Virtual Machines を OpenShift プラットフォームをホストし、Maximo コンテナーを実行します。 Virtual Machines は、サービスとしてのインフラストラクチャ (IaaS) オファリングです。 Virtual Machines を使用して、オンデマンドのスケーラブルなコンピューティング リソースをデプロイできます。

• OpenShift 用のカスタム VM イメージを Red Hat Enterprise Linux CoreOS に提供します。

• クラスターへの接続を Azure Load Balancer に提供します。 Azure Load Balancer は、すべての UDP と TCP プロトコル向けの高パフォーマンス、超低待機時間のレイヤー 4 負荷分散サービス (受信および送信) です。 これは、ソリューションの高可用性を保証しながら、1 秒あたり数百万の要求を処理するように構築されています。 Azure Load Balancer は、ゾーン冗長であるため、Availability Zones 全体で高可用性を確保します。

• ノード間の通信、Azure サービス、ハイブリッド接続のニーズに対する Virtual Network。 Virtual Network は、Azure 内のプライベート ネットワークのための基本的な構成要素です。

• Azure Files は、クラスター内のデータベースとシステムのステートフル データをホストします。 Azure Files は、業界標準の SMB および Network File System (NFS) プロトコルを介してアクセスできる、クラウド内のフル マネージド ファイル共有を提供します。

• ソリューションの内外のコンテナーの DNS 解決を管理する Azure DNS。 Azure DNS では、すべての一般的な DNS レコードがサポートされ、高可用性が提供されます。

• 任意のワーカー ノードまたはオプションの JumpBox マシンに安全にアクセスするための Azure Bastion (オプション) とサブネット。 Azure Bastion は、パブリック IP アドレスを介して公開することなく、VM への安全でシームレスな RDP および SSH アクセスを提供するフル マネージド サービスです。

• Azure Virtual Machines における SQL Server (オプション) Azure Virtual Machines (VM) 上の SQL Server によって、データ サービスを MAS に提供します。 データベースは、Oracle Exadata や IBM Db2 Warehouse などの別のデータベースにすることもできます。 Azure SQL Database と Azure SQL Managed Instance は現在、サポートされていません。

• MAS からコンシューマーにメールを送信する Twilio Send Grid (オプション)。

• OpenShift をインストールするジャンプ ボックスを提供する Azure の Linux 仮想マシン (オプション)。 インストール後に Kubernetes 構成ファイルが含まれているため、この VM を使用して OpenShift クラスターに接続および管理することもできます。 Azure 環境へのネットワーク接続がある場合は、既存のマシンからインストールを実行できます。

代替

通常、次のサービスは必要ありませんが、効果的な代替手段になります。

• Azure Files の代わりに Azure NetApp Files。 NetApp Files では、高可用性と高パフォーマンスを備えたあらゆる種類のワークロードがサポートされます。
• SQL Server または Db2 Warehouse を使用する場合、Azure 上の Oracle Database。
• OpenShift Data Foundation で Db2 Warehouse を使用する場合、OpenShift Data Foundation。

シナリオの詳細

IBM の Maximo Application Suite (MAS) (Maximo とも呼ばれます) は、AI ベースの資産メンテナンスを備えたエンタープライズ資産管理プラットフォームです。 MAS では、運用上の回復性と信頼性に重点を置いています。 このスイートは、コア アプリケーション プラットフォーム、MAS、アプリケーション、およびプラットフォーム上の業界固有のソリューションで構成されています。 各アプリケーションには、次のような特定の利点があります。

• 管理。 資産管理を使用して運用パフォーマンスを向上させることで、時間とコストを削減します。
• モニター。 IoT を使用して、大規模なリモート資産の高度な AI を利用した監視を行います。
• [正常性] : センサー、資産データ、メンテナンス履歴の IoT データを使用して資産の正常性を管理します。
• 目視検査。 新しい問題の視覚的分析に視覚的検査を使用するように機械学習モデルをトレーニングします。
• 予測。 機械学習とデータ分析を使用して、将来の障害を予測します。
• 支援。 技術者を支援するには、機器のメンテナンス データのサポート情報に AI を利用したガイダンスを提供し、専門家にリモート アクセスを提供します。
• 安全性。 センサーからデータを収集して分析し、コンテキスト データを提供して、意味のある分析を導き出します。
• Civil. 検査、欠陥の追跡、メンテナンス アクティビティを統合して、資産の寿命を向上させ、重要なシステムを運用し続け、民間インフラの総保有コストを削減します。

これらのアプリケーションと MAS 8.x は、Azure での使用のためにテストされます。 Microsoft と IBM Maximo チームは、このソリューションが Azure で最適に実行されるよう構成されていることを確認するために提携しました。 この記事では、IBM およびインストールのパートナーからのサポートを受けているお客様向けに、Azure で MAS 8. x を実行するための設計を提供します。 製品固有の質問については、IBM チームにお問い合わせください。 Azure Marketplace には、持ち込みライセンスをサポートする MAS 向けの代替インストールが用意されています。 詳細については、「IBM Maximo Application Suite (Bring Your Own License (BYOL))」を参照してください。

考えられるユース ケース

多くの業界やセクターでは、次のように MAS のソリューションを使用しています。

• エネルギー、公益事業
• 石油、ガス
• 製造
• 旅行、自動車および輸送
• 公共機関

MAS のユース ケースの詳細については、IBM の Web サイト (IBM Maximo Application Suite) を参照してください。

Recommendations

Azure との最適な統合オプションが提供されるため、最新の安定バージョンの MAS をインストールすることをお勧めします。 サポートされているバージョンは MAS の特定のバージョンによって異なるため、サポートされている OpenShift のバージョンに細心の注意を払います。

以前またはそれ以降のメジャー バージョンの OpenShift を使用すると、MAS の公式サポートから除外される可能性があります。 独自のデプロイを構築する前に、クイックスタート ガイドを使用して MAS をデプロイし、デプロイと構成のしくみを理解することをお勧めします。 これがどのように行われるかを把握すると、実装の設計要件の作成が高速化されます。 詳細については、「クイック スタート ガイド: Maximo Application Suite on Azure」を参照してください。

当社では IBM や他のパートナーと密接に協力して、ガイダンス、アーキテクチャ、クイック スタート ガイドが Azure で最高のエクスペリエンスを提供できるようにします。 Microsoft Azure Well-Architected Framework で説明されているベスト プラクティスに従います。 このドキュメント以上のサポートについては、IBM アカウント チームにお問い合わせください。

デプロイを続行する前に、設計に関して次の質問に回答する必要があります。

• どのような MAS アプリケーションが必要ですか?
• アプリケーションにはどのような依存関係がありますか?
• どのバージョンの OpenShift が必要ですか?
• どの OpenShift のインストール方法を使用すべきですか?
• どのようなデータベースが必要ですか?
• 必要な VM の数とサイズは?
• ユーザーは外部ネットワークから接続しますか?

Maximo Application Suite

Microsoft では、Azure で MAS バージョン 8.5 以降をテストしました。 当社では最新バージョンの MAS (バージョン 8.7) を使用することをお勧めします。

完全なビジネス シナリオに必要な MAS アプリケーションを確認し、各アプリケーションの要件を確認します。 詳細については、 「IBM Maximo Application Suite システム要件」を参照してください。 アプリケーションごとに個別のデータベースが必要な場合があります。 Azure で次のデータベースをテストし、サポートしています。

• Windows または Linux を使用する Azure VM 上の SQL Server バージョン 2019
• IBM Db2 Warehouse on Cloud Pak for Data 3.5

相互接続を使用して、VM または Oracle Cloud Infrastructure で Oracle Exadata を実行することもできますが、これはテスト済みの構成ではありません。 相互接続の詳細については、「Oracle Cloud と Microsoft Azure の相互接続」を参照してください。 現時点では、Azure SQL Database、Azure SQL Managed Instance、Azure Cosmos DB はサポートされていません。

MAS とそのアプリケーションの一部には、MongoDB と Kafka への依存関係があります。 パフォーマンスと運用に関する考慮事項に基づいて、これらのソリューションをデプロイする方法を決定します。 既定では、MongoDB Community Edition と Strimzi Kafka がクラスター内にデプロイされます。 MAS の前提条件の一部 (BAS など) では、外部化できませんが、永続的ストレージを OpenShift クラスターに提供する必要があるデータベースを使用します。

OpenShift クラスター内で実行される状態ベースのサービスの場合、データを頻繁にバックアップし、バックアップを別のリージョンに移動する必要があります。 OpenShift 内で Kafka または MongoDB を実行する場合は特に、障害発生時の復旧戦略を設計および計画し、それに応じて決定します。

状態を保持するサービスの場合は、可能な限り外部の Azure サービスとしてのプラットフォーム (PaaS) オファリングを使用します。 これにより、停止中のサポート性が向上します。

一部のサービスには、IBM Watson Machine Learning や IBM App Connect などの他の IBM ツールとサービスが必要な場合があります。 すべてのツールとサービスを同じ OpenShift クラスターにデプロイできます。

OpenShift

OpenShift をインストールする前に、使用する方法を決定する必要があります。

• Installer Provisioned Infrastructure (IPI)。 この方法では、インストーラーを使用して Azure に OpenShift 環境をデプロイおよび構成します。 IPI は Azure にデプロイする最も一般的な方法であり、セキュリティ要件が厳しすぎる場合を除き、IPI を使用する必要があります。

• User Provisioned Infrastructure (UPI)。 この方法では、デプロイをきめ細かく制御できます。 UPI では、環境を構築するためにさらに多くの手順と考慮事項が必要です。 IPI がニーズを満たしていない場合は、UPI を使用します。 UPI の一般的なユース ケースは、プライベートでエアギャップされたインストール用です。 環境の構築時に送信インターネット アクセスがない場合は、UPI を選択します。

OPENShift のインストールを完了するために必要な作業量が大幅に削減されるため、可能な限り IPI を使用することをお勧めします。

OpenShift をインストールするときは、次の考慮事項を解決する必要があります。

• リージョンの選択。 可用性ゾーンのあるリージョンを使用することをお勧めします。 デプロイ中、OpenShift は構成ファイル install-config.yaml の構成に基づいて、ゾーン間でノードの作成を自動的に試行します。 既定では、OpenShift は利用可能なすべてのノードと可用性ゾーン間でワークロードのバランスを取ります。 ゾーンで障害が発生した場合、作業を引き継ぐ可能性のある他のゾーンにノードを配置することで、ソリューションは引き続き機能することができます。

• バックアップと復旧。 バックアップと復旧には、Azure Red Hat OpenShift の手順を使用できます。 詳細については、「Azure Red Hat OpenShift 4 クラスター アプリケーションのバックアップを作成する」を参照してください。 バックアップと復旧にこの方法を使用する場合は、データベースの別のディザスター リカバリーの方法を指定する必要があります。

• フェールオーバーする。 2 つのリージョンに OpenShift をデプロイし、 Red Hat Advanced Cluster Management を使用することを検討してください。 ソリューションにパブリック エンドポイントがある場合は、リージョンが停止したときにトラフィックを適切なクラスターにリダイレクトするため、それらのエンドポイントとインターネットの間に Azure Traffic Manager を配置できます。 このような状況では、アプリケーション状態と永続ボリュームも移行する必要があります。

エアギャップ インストール

規制コンプライアンスなど、場合によっては、Azure への MAS のエアギャップ インストールが必要になる場合があります。 エア ギャップ とは、受信または送信のインターネット アクセスがないことを意味します。 インターネット接続がない場合、インストールでは、MAS または OpenShift のインストールの実行時にインストールの依存関係を取得できません。

セキュリティ要件である場合を除き、エアギャップインストールを行うことをお勧めしません。 エア ギャップにより、ソリューションの運用が大幅に複雑になります。 ソフトウェアのインストール、コンテナーのミラーリング、セキュリティの脆弱性から保護するミラーの更新、ファイアウォールの管理などのアクティビティは、非常に時間がかかる場合があります。

エアギャップ インストールの詳細については、次の OpenShift ドキュメントを参照してください。

• 切断されたインストール用のミラーリング イメージ
• Azure へのプライベート クラスターのインストール

OpenShift をインストールしたら、同様のガイダンスについては MAS ドキュメントを参照してください。

環境を共有する

すべてのワークロード (目視検査を除く) では、最新の Ds シリーズ VM をワーカー ノードとして使用することをお勧めします。 たとえば、 Dsv3、 Dasv4、 Dsv4、 Dasv5、 Dsv5 などです。 可能な場合は、パフォーマンスが向上するため、最新バージョンを使用することをお勧めします。 Premium Storage のある VM のみを使用してください。

Maximo 目視検査 では、機械学習を実行するために GPU ノードが必要です。 このソリューションでは CUDA が使用され、NVIDIA GPU のみがサポートされます。 推奨される VM の種類は NCv3 と NCasT4_v3です。 YOLOv3 を使用してトレーニングする必要がある場合は、Ampere ベースの GPU が必要です。 大規模なトレーニング タスクには、NVadsA10 v5 または NC A100 v4 を使用します。

GPU マシンの場合は、最小ノードから始めて、要件の増加に合わせてスケールアップすることをお勧めします。

他のすべてのマシンでは、高可用性をサポートするように 可用性ゾーン 間で VM を構成することをお勧めします。 ノードを次のように構成します。

• 制御ノード。 選択したリージョン内の可用性ゾーンごとに少なくとも 1 つの VM。 vCPU の数を少なくとも 4 にすることをお勧めします。 このリファレンスでは、Standard_D8s_v4 ノードを 3 つ使用します。

• [ワーカー ノード]。 選択したリージョン内の可用性ゾーンごとに少なくとも 2 つの VM。 vCPU の数を少なくとも 8 にすることをお勧めします。 このリファレンスでは、Standard_D8s_v4 ノードを 6 つ使用します。

MAS コアでは、標準サイズの基本インストールに 13 個の vCPU が必要です。 ワーカー ノードのサイズ設定は、構成がデプロイする MAS アプリケーションと環境の負荷によって異なります。 たとえば、10 人のユーザーの管理には、別の 2 つの vCPU が必要です。 サイズ設定の適切な見積もりを得るために、IBM Maximo Application Suite のシステム要件を確認することをお勧めします。

ワーカー ノードと制御ノードの間の各可用性ゾーンとの近接性を提供するために、VM の種類を相互に似た状態に保つようにします。 つまり、制御ノードに v4 VM を使用する場合は、ワーカー ノードにも v4 VM を使用します。

OpenShift コマンド ライン インターフェイス (oc) を使用したり MAS をインストールしたりするのにジャンプ ボックスが必要な場合は、Red Hat Enterprise Linux のバージョン 8.4 を実行している VM をデプロイします。

ネットワーク

OpenShift では、OpenShift のソフトウェア定義ネットワーク (SDN) の既定のコンテナー ネットワーク インターフェイス (CNI) プロバイダーを使用します。 既定の OpenShift CNI の詳細については、「OpenShift Container Platform のクラスター ネットワーク オペレーター」を参照してください。 必要な OpenShift 制御ノードとワーカー ノードの数、およびデータベースやストレージ アカウントなどのその他の要件に合わせて、ネットワークのサイズを設定する必要があります。

標準的な MAS 運用インストールでは、Classless Inter-Domain Routing (CIDR) プレフィックス /24 が提供するアドレス空間を持つ仮想ネットワークをお勧めします。 仮想ネットワークには、3 つまたは 4 つのサブネットがあります (Bastion の場合)。 OpenShift の場合、ワーカー ノードのサブネットの CIDR プレフィックスは /25 で、制御ノードのプレフィックスは /27 です。 エンドポイントのサブネットとオプションの外部データベース サーバーのプレフィックスは、/27 である必要があります。 Azure Bastion をデプロイする場合 (オプション)、/26 のプレフィックスの AzureBastionSubnet という名前のサブネットが必要です。 Azure Bastion の要件の詳細については、「アーキテクチャ」を参照してください。

IP アドレスが不足している場合は、制御ノードのサブネットに /27、ワーカー ノードのサブネットに /27 の最小プレフィックスを持つ高可用性構成を実装できます。

別の CNI を使用する場合は、それに応じてネットワークのサイズを変更します。 一部の標準アプリケーションを使用する MAS では、800 を超えるポッドがデプロイされており、/21 以上の CIDR プレフィックスを必要となる可能性が高くなります。

データベースの詳細

MAS のさまざまなコンポーネントは、メタデータ ストアとして MongoDB を使用します。 既定のガイダンスでは、クラスター内に MongoDB Community Edition をデプロイします。 その方法を使用してデプロイする場合は、データベースをバックアップおよび復元する適切な手順が整っていることを確認してください。 MongoDB Atlas は外部化されたストア、バックアップ、スケーリングなどを提供するため、Azure で MongoDB Atlas を使用することを検討してください。 Azure では現在、Azure Cosmos DB での MongoDB API の使用はサポートされていません。

IoT サービスをデプロイする場合は、Kafka エンドポイントも指定する必要があります。 既定のガイダンスでは、Strimzi を使用して OpenShift クラスター内に Kafka をデプロイします。 ディザスター リカバリー中は、Strimzi 内のデータが失われる可能性が高くなります。 Kafka 内のデータ損失が許容できない場合は、Azure での Confluent Kafka の使用を検討する必要があります。 現時点では、Kafka エンドポイントを使用した Azure Event Hubs はサポートされていません。

MAS にはポッド内に多数のデータベースが含まれており、それらのデータベースは MAS 用に提供されるファイル システム上で状態を保持します。 ゾーンの障害を吸収できるように、ゾーン冗長ストレージ メカニズム (ZRS) を使用してクラスターの外部の状態を保持することをお勧めします。 推奨されるパターンは、次の構成で Azure File Storage を使用することです。

• Standard。 スループットと ReadWriteOnce (RWO) ワークロードを削減するためのサーバー メッセージ ブロック (SMB) 共有を提供します。 Standard は、ストレージに頻繁に書き込まず、単一の永続ボリューム (IBM 単一レベルストレージなど) を必要とするアプリケーション部分に最適です。

• Premium。 スループットと ReadWriteMany (RWX) ワークロードを向上させるために、ネットワーク ファイル システム (NFS) 共有を提供します。 これらのようなボリュームは、Cloud Pak for Data の Db2 Warehouse や Manage の Postgres など、RWX ワークロード用にクラスター全体で使用されます。

Azure Blob Storage でセキュリティで保護された転送を適用するためのポリシーを無効にするか、アカウントをそのようなポリシーから除外してください。 NFS を使用する Azure Premium Files では、セキュリティで保護された転送を無効にする必要があります。 共有へのプライベート接続を保証するには、 必ずプライベート エンドポイントを使用してください。

既定では、Db2 Warehouse は OpenShift Data Foundation (旧称 OpenShift Container Storage) の上にデプロイされます。 コスト、パフォーマンス、スケーリング、信頼性の理由から、OpenShift Data Foundation ではなく NFS で Azure Premium Files を使用することをお勧めします。

必要なハード リンクはサポートされていないため、CSI ドライバーで Azure BLOB を使用しないでください。 一部のポッドは、ハード リンクなしでは実行できません。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

資産メンテナンスのライフサイクルへのアクセスと可視性の維持は、組織が効率的に運用し、アップタイムを維持できる最大の機会の 1 つです。 環境のセキュリティ体制を向上するには、セキュリティで保護された認証を使用し、ソリューションを最新の状態に保つことが重要です。 暗号化を使用して、アーキテクチャとの間でやり取りされるすべてのデータを保護します。

Azure では、サービスとしてのインフラストラクチャ (IaaS) と PaaS のモデルを使用して MAS を提供します。 Microsoft は、次のレベルでセキュリティ保護をサービスに構築します。

• 物理データセンター
• 物理ネットワーク
• 物理ホスト
• ハイパーバイザー

メジャー リリースの OpenShift の最新の修正プログラムが適用されたバージョンなど、ハイパーバイザーの上の領域に対して選択したサービスとテクノロジを慎重に評価します。 アーキテクチャに適切なセキュリティ コントロールを提供するようにしてください。 IaaS システムのセキュリティにパッチを適用して維持する責任があります。 Microsoft は PaaS サービスに対してこの役割を担っています。

ネットワーク セキュリティ グループを使用すると、仮想ネットワーク内のリソースとの間のネットワーク トラフィックをフィルター処理できます。 これらのグループを使用して、MAS サービスへのアクセスを許可または拒否するルールを定義できます。 たとえば、次のようになります。

• トラブルシューティング用に OpenShift ノードへの SSH アクセスを許可する
• クラスターの他のすべての部分へのアクセスをブロックする
• MAS と OpenShift クラスターにアクセスできる場所を制御する

何らかの理由で VM にアクセスする必要がある場合は、ハイブリッド接続または OpenShift 管理コンソール経由で接続できます。 オンライン デプロイがある場合、または接続に依存しない場合は、 Azure Bastion (省略可能) を使用して VM にアクセスすることもできます。 セキュリティ上の理由から、VM へのアクセスを制御するようにネットワーク セキュリティ グループを構成せずに、VM をネットワークまたはインターネットに公開しないでください。

Azure Disk Storage のサーバー側暗号化 (SSE) では、データが保護されます。 また、組織のセキュリティとコンプライアンスのコミットメントを満たすのにも役立ちます。 Azure マネージド ディスクでは、SSE はデータをクラウドに永続化するときに、保存データを暗号化します。 この動作は、既定で OS とデータ ディスクの両方に適用されます。 OpenShift では、既定で SSE が使用されます。

認証

MAS では現在、Microsoft Entra ID を介した Security Assertion Markup Language (SAML) の使用がサポートされています。 この作業を行うには、Microsoft Entra ID 内のエンタープライズ アプリケーションと、アプリケーションを変更するためのアクセス許可、または必要な変更を行うことができるグローバル管理者の支援が必要です。

GitHub のクイックスタート ガイドには、MAS で SAML を設定する方法に関するチュートリアルがあります。 詳細については、「Microsoft Entra ID に対する SAML 認証の有効化」を参照してください。

SAML ベースの認証を設定する前に、IBM 構成と Azure 構成を確認することをお勧めします。 MAS を使用した SAML の詳細については、MAS のドキュメントの「SAML」を参照してください。 Azure での SAML の詳細については、「クイック スタート: エンタープライズ アプリケーションのシングル サインオンを有効にする」を参照してください。

また、OpenShift 用に Open Authorization (OAuth) を構成する必要があります。 詳細については、OpenShift ドキュメントの「認証と承認の概要」を参照してください。

インフラストラクチャを保護する

デプロイする Azure リソースへのアクセスを制御します。 Azure のすべてのサブスクリプションは、Microsoft Entra テナント との間に信頼関係があります。 Azure ロールベースのアクセス制御 (RBAC) を使用して、組織内のユーザーに Azure リソースに対する適切なアクセス許可を付与します。 特定のスコープでユーザーまたはグループに Azure のロールを割り当てて、アクセス権を付与します。 スコープには、サブスクリプション、リソース グループ、または 1 つのリソースを指定できます。 インフラストラクチャに対するすべての変更を必ず監査してください。 監査の詳細については、「Azure Monitor アクティビティ ログ」を参照してください。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

MAS の標準的なデプロイは、次のコンポーネントで構成されます。

• 3 つの制御 VM
• 6 つのワーカー VM
• Db2 Warehouse 向けの 3 つの worker VM
  • 一部の構成では、Db2 Warehouse を使用するのではなく、Azure VM 上の SQL Server に置き換えることができます。
• Azure Storage アカウント
• 2 DNS ゾーン
• 2 Load balancers
• Azure Bastion
• 1 目視検査 VM
  • MAS 内で目視検査を実行する予定がない限り、これは必要ありません。

コスト計算ツールを使用して、見積もりの例を確認できます。 構成はそれぞれ異なるため、デプロイを終了する前に、IBM サイズ設定チームで構成を確認する必要があります。

[信頼性]

OpenShift には、OpenShift と MAS が正常に動作するように、自己復旧、スケーリング、復旧性のための機能が組み込まれています。 OpenShift と MAS は、障害が発生して復旧する部分用に設計されています。 自己復旧を機能させるために重要な要件は、十分なワーカー ノードがあることです。 Azure リージョン内のゾーン障害から復旧するには、可用性ゾーン間で制御ノードとワーカー ノードのバランスを取る必要があります。

MAS と OpenShift では、ストレージを使用して Kubernetes クラスターの外部で状態を保持します。 障害発生時にストレージの依存関係が引き続き機能するようにするには、可能な限り ゾーン冗長ストレージ を使用する必要があります。 この種類のストレージは、ゾーンで障害が発生しても引き続き使用できます。

人的エラーは一般的に起こるため、できるだけ多く自動化を使用して MAS をデプロイする必要があります。 クイック スタート ガイドでは、完全なエンド ツー エンドの自動化を設定するサンプル スクリプトをいくつか提供しています。

このシナリオのデプロイ

開始する前に、 「IBM Maximo Application Suite のシステム要件」を確認することをお勧めします。 デプロイを開始する前に、次のリソースを使用できることを確認してください。

• 閲覧者 のアクセス許可を持つ Azure サブスクリプションへのアクセス
• サブスクリプションに対する共同作成者 および ユーザー アクセス管理者 のアクセス許可を持つアプリケーションの登録、またはサービス プリンシパル名
• Azure DNS ゾーンへのドメインまたは委任されたサブドメイン
• Red Hat からシークレットをプルして OpenShift をデプロイする
• MAS エンタイトルメント キー
• MAS ライセンス ファイル (MAS インストール後に作成済み)
• IBM 推奨クラスターのサイズ設定
• 要件に応じて、IPI によって作成された既存の仮想ネットワークまたは新しい仮想ネットワーク
• 具体的なデプロイに対する高可用性とディザスター リカバリーの要件
• インストーラー用の構成ファイル install-config.yaml

前提条件に対処する方法など、Azure に OpenShift と MAS をインストールするためのステップ バイ ステップ ガイドについては、GitHub の 「クイックスタート ガイド」を参照してください。

デプロイに関する考慮事項

手動でデプロイすると間違って構成する可能性があるため、ワークロードを手動でデプロイするのではなく、コードとしてのインフラストラクチャ (IaC) を使用してワークロードをデプロイすることをお勧めします。 コンテナーベースのワークロードは、構成ミスに対してセンシティブであり、生産性が低下する可能性があります。

環境を構築する前に、クイック スタート ガイド を確認して、設計パラメーターの理解を深めます。 クイック スタート ガイドは、運用環境に対応したデプロイを目的としたものではありませんが、ガイドの資産を使用して、デプロイ用の運用グレードのメカニズムにアクセスできます。

IBM では、インストールに役立つ専門サービスを提供しています。 サポートについては、IBM チームにお問い合わせください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• David Baum | シニア クラウド ソリューション アーキテクト
• Roeland Nieuwenhuis |プリンシパル クラウド ソリューション アーキテクト

その他の共同作成者:

• Gary Moore | プログラマー/ライター

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

開始するのに役立つ、次のリソースを参照してください。

• Azure での OpenShift のインストール
• クイック スタート ガイド: Maximo Application Suite on Azure
• OpenShift UPI ガイド
• Maximo の要件
• IBM Maximo Application Suite (BYOL)

注目のテクノロジの詳細については、次のリソースを参照してください。

• IBM Passport Advantage
• Azure DNS の概要
• Azure NetApp Files の概要
• Red Hat on Azure の概要
• Red Hat Customer Portal

関連リソース

• Azure エンタープライズ クラウド ファイル共有
• 製造業における予測メンテナンスの概要
• JBoss エンタープライズ アプリケーション プラットフォーム (EAP) を使用して Java アプリケーションを ARO クラスターにデプロイする