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

この記事では、Azureでの IBM Maximo Application Suite (MAS) の展開について説明します。 MAS は Red Hat OpenShift で実行されます。 Azure Red Hat OpenShift (ARO) は、運用、セキュリティ、ネットワークの要件を満たしている場合に推奨される OpenShift プラットフォームです。 Azureで自己管理 Red Hat OpenShift を使用するのは、特定の切断されたデプロイ パターンやクラスター レベルのカスタマイズなど、ARO が提供しない制御が必要な場合のみです。

この記事では、MAS のインストール方法の詳細については説明しません。 インストールの詳細については、「 Maximo Application Suite のインストール」を参照してください。

アーキテクチャ

次の図は、Azureでの ARO ベースの MAS 展開を示しています。

このアーキテクチャのVisio ファイルをダウンロードしてください。

要件に応じて、ワークロードを内部または外部向けのデプロイとしてデプロイできます。 この記事では、パブリックまたはプライベートの ARO デプロイ モデルは規定されていません。 ネットワーク トポロジ、接続モデル、セキュリティ制御、運用アクセス要件、コンプライアンス要件、MAS ユーザー アクセス パターンなど、Azureランディング ゾーン アーキテクチャに基づいて、コントロール プレーン、イングレス、エグレス アーキテクチャを選択します。

IBM がデプロイする MAS アプリケーションの外部データベースをサポートしている場合は、これらのデータベースを外部化して OpenShift クラスター内の状態を減らし、データベース管理をクラスター管理から切り離してみてください。

Workflow

インフラストラクチャの観点から見ると、このアーキテクチャには次の機能があります。

• 可用性ゾーン間で高可用性ワークロードをデプロイするためのAzure Red Hat OpenShiftマネージド サービス
• Azureネットワークとストレージと統合された OpenShift クラスター
• サポートされている MAS ストレージ要件のAzure Files Premium および Azure Files Standard
• Azure SQL Managed Instanceまたはコンテナーベースの IBM Db2 Warehouse
• OpenShift とそのコンテナーのドメイン ネーム システム (DNS) 管理のAzure DNS
• MAS へのシングル サインオン (SSO) のMicrosoft Entra ID

コンポーネント

• Azure Red Hat OpenShift (ARO) は、Azure上の MAS に推奨される OpenShift プラットフォームです。 ARO は、Azure仮想マシン (VM) 上のセルフマネージド クラスターと比較して、OpenShift の実行に対する運用上の責任を軽減します。

• Azure 仮想マシンは、オンデマンドでスケーラブルなコンピューティング リソースをデプロイするサービスとしてのインフラストラクチャ (IaaS) です。 ARO の代わりに Virtual Machines を使用して、Azureに自己管理 Red Hat OpenShift をデプロイします。

  必要に応じて、Azure Linux VM を MAS インストールと OpenShift 管理のジャンプ ボックスとして使用します。 Azure環境へのプライベート ネットワーク接続がある場合は、既存のセキュリティで保護されたマシンから管理を実行できます。

• Red Hat Enterprise Linux CoreOS は、OpenShift ノード用のオペレーティング システム イメージを提供します。

• Azure Load Balancerは、クラスターへの接続を提供します。 Load Balancerは、すべての受信および送信ユーザー データグラム プロトコル (UDP) および伝送制御プロトコル (TCP) プロトコル用の、高パフォーマンスで超低待機時間のレイヤー 4 負荷分散サービスです。 Load Balancerでは、ソリューションの高可用性を確保しながら、1 秒あたり何百万もの要求を処理できます。 Load Balancerはゾーン冗長であり、可用性ゾーン間の高可用性を確保します。

• Azure Virtual Network は、Azure のプライベート ネットワークの基本的な構成要素です。 ノードとAzure サービス間の通信とハイブリッド接続には、Virtual Networkを使用します。

• Azure Filesは、サーバー メッセージ ブロック (SMB) プロトコルとネットワーク ファイル システム (NFS) プロトコルを介してアクセスできる、クラウド内のフル マネージド ファイル共有を提供します。 Azure Filesを使用して、クラスター内のデータベースとシステムのステートフル データをホストします。

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

• Azure Bastionは、パブリック IP アドレスを介して公開することなく、リモート デスクトップ プロトコル (RDP) とセキュア シェル (SSH) アクセスを VM に提供するフル マネージド サービスです。 必要に応じて、Azure Bastionとサブネットを使用して、任意のワーカー ノードまたはオプションのジャンプ ボックス マシンへのセキュリティを強化します。

• SQL Managed Instanceは、IBM がデプロイするアプリケーションのSQL Serverをサポートしている場合に、MAS に外部データ・サービスを提供します。 Oracle Exadata や IBM Db2 Warehouse など、別のデータベースを選択することもできます。 Azure SQL Databaseはサポートされていません。

• Twilio SendGrid は MAS からコンシューマーに電子メールを送信します。 MAS 展開で通知および従業員のディスパッチ シナリオ用の電子メール サービスが必要な場合は、必要に応じて Twilio SendGrid などの電子メール サービスを設計に組み込みます。

選択肢

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

• Azure Filesの代わりとしてAzure NetApp Filesを使用する。 Azure NetApp Filesは、高可用性と高パフォーマンスを必要とするワークロードをサポートします。
• サポートされている場合は、Azure上の Oracle Database を使用します。
• OpenShift Data Foundation で Db2 Warehouse を使用したい場合。

シナリオの詳細

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

• Maximo Manage。 資産管理を使用して運用パフォーマンスを向上させることで、ダウンタイムとコストを削減します。
• Maximo Monitor。 モノのインターネット (IoT) を使用して、大規模なリモート資産の高度な AI を利用した監視を行います。
• Maximo Health。 センサー、資産データ、およびメンテナンス履歴からの IoT データを使用して資産の正常性を管理します。
• Maximo ビジュアル検査。 新しい問題の視覚的分析に視覚的検査を使用するように機械学習モデルをトレーニングします。
• Maximo Predict。 機械学習とデータ分析を使用して、将来の障害を予測します。
• Maximo 共同作業。 機器メンテナンス データのナレッジ ベースから AI を利用したガイダンスを使用して技術者をサポートし、専門家へのリモート アクセスを提供します。
• Maximo Health, Safety and Environment (HSE)。 安全性、環境コンプライアンス、および作業制御プロセスを資産、場所、作業指示書に接続します。
• Maximo Civil Infrastructure. 検査、欠陥追跡、メンテナンスアクティビティを統合して、資産の寿命を向上させ、重要なシステムの運用を維持し、市民インフラの総所有コストを削減します。
• 最大の不動産と施設。 スペース管理、予約、資本プロジェクト、施設条件評価、リース管理、運用、メンテナンスを使用して、不動産ポートフォリオと施設資産を管理します。

考えられるユース ケース

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

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

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

推奨事項

この記事は、Azureで現在サポートされている MAS 9.x の展開について書かれています。 Microsoft IBM MAS チームや他のパートナーと協力して、このソリューションが最適に実行されるように構成され、Azureで最適なエクスペリエンスを提供するように構成されています。 このドキュメント、アーキテクチャ、ガイダンスは、Microsoft Azure Well-Architected Framework で説明されているベスト プラクティスに従います。 このドキュメント以外の製品固有の質問とサポートについては、IBM アカウント チームにお問い合わせください。

この記事は、IBM とパートナーによるインストールのサポートがある場合のアーキテクチャ ガイダンスに使用します。 Azureには、ライセンスの持ち込みをサポートする MAS のインストール パスも用意されています。 詳細については、「IBM Maximo Application Suite (Bring Your Own License (BYOL))」を参照してください。

IBM が選択した OpenShift バージョンおよび MAS アプリケーションとの互換性を備えた、サポートされている MAS バージョンをインストールします。 新しいAzureデプロイの場合は、セルフマネージド クラスターが必要な場合を除き、優先される OpenShift プラットフォームとして ARO を使用します。

OpenShift のサポート互換性は、3 つの重複するサポート境界 (IBM MAS 互換性、Red Hat OpenShift ライフサイクル サポート、ARO バージョンの可用性) に依存します。 ソフトウェア製品互換性レポート (SPCR) に IBM が一覧表示しない OpenShift バージョン、または Red Hat または ARO のサポート外の OpenShift バージョンを使用すると、MAS 展開がサポートされなけれな状態になる可能性があります。

デプロイを構築する前に、IBM Maximo Application Suite の概要、Microsoft Azureへのインストールの計画、およびソフトウェア製品互換性レポート (SPCR) のドキュメントを確認して、現在のデプロイと構成の要件を理解してください。

デプロイに進む前に、設計に関する次の質問に回答してください。

• どのような MAS アプリケーションが必要ですか?
• アプリケーションにはどのような依存関係がありますか?
• お使いの MAS バージョンとアプリケーションに対して IBM はどの OpenShift バージョンをサポートしていますか?
• ARO は要件を満たしていますか、または Azure で自己管理 Red Hat OpenShift が必要ですか?
• 必要なデータベース
• 必要な VM の数とサイズは?
• ユーザーは外部ネットワークから接続する必要がありますか?

Maximo Application Suite

現在サポートされている MAS 9.x リリースを使用し、アーキテクチャを完了する前に、IBM SPCR でサポートされている OpenShift のバージョン、データベース、依存関係を検証します。 Maximo Application Suite の以前のバージョンを使用している場合は、IBM ライフサイクルの状態を確認し、サポートされている MAS 9.x リリースへのアップグレードを計画してください。

完全なビジネス シナリオに必要な MAS アプリケーションを確認し、各アプリケーションの要件を確認します。 詳細については、 「IBM Maximo Application Suite システム要件」を参照してください。

MAS アプリケーションごとに個別のデータベースが必要になる場合があります。 IBM がアプリケーションの外部データベースをサポートしている場合は、データベースの外部化を試みます。この方法では、OpenShift 内で操作する必要がある状態の量が減るためです。 Microsoftおよび IBM は、Azure上の MAS 用に次のデータベースをテストおよびサポートしています。

• SQLマネージドインスタンス
• IBM Db2 Warehouse on Cloud Pak for Data 5

Azure SQL DatabaseとAzure Cosmos DBはサポートされていません。

Oracle クラウド インフラストラクチャまたは VM 上で、相互接続を使用して Oracle Exadata を実行することもできます。 この構成は公式にはテストされていませんが、成功したと報告されています。 相互接続の詳細については、「Interconnecting Oracle Cloud with Microsoft Azure」を参照してください。

MAS とそのアプリケーションの一部は、MongoDB と Kafka に依存しています。 IBM の既定のクラスター内 MongoDB Community Edition デプロイと Strimzi Kafka デプロイは、サポート、バックアップ、および回復の要件に合わせて使用します。 この選択は、Kafka と MongoDB が内部 MAS 依存関係であり、ソリューションが MAS の外部でそれらを使用しない場合に適しています。

より強力なバックアップ、スケーリング、またはディザスター リカバリー操作が必要な場合は、Azureの MongoDB Atlas や Azure 上の Confluent Cloud などの外部マネージド サービスを使用してみてください。 Behavior Analytics Services (BAS) などの一部の MAS 前提条件では、外部化はできないが、OpenShift クラスターに永続的なストレージを提供する必要があるデータベースを使用します。

OpenShift クラスター内で実行される状態ベースのサービスの場合は、定期的にデータをバックアップし、バックアップを別のリージョンに移動します。 特に OpenShift 内で Kafka または MongoDB を実行する場合は、災害の復旧戦略を設計、計画、決定します。 状態を保持するサービスの場合は、可能であれば、サービスとしての外部Azure プラットフォーム (PaaS) オファリングを使用して、停止中のサポート性を向上させます。

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

Azure Red Hat OpenShift

Azure上の MAS に推奨される OpenShift プラットフォームとして ARO を使用します。 ARO は、Azureでマネージド OpenShift サービスを提供します。これにより、OpenShift プラットフォームのインストール、修正プログラムの適用、運用に関する運用上の負担が軽減されます。 MAS とそのアプリケーション構成、ワーカー容量計画、ネットワーク統合、ID 統合、ストレージの選択、データ保護、ディザスター リカバリーをまだ所有している。

ARO に MAS を展開する前に、次の推奨事項を検討してください。

• バージョンの互換性。 MAS バージョンと選択した MAS アプリケーションでサポートされている OpenShift バージョンを IBM が一覧表示します。 ターゲット Azure リージョンで、同じ OpenShift バージョンが ARO で使用でき、サポートされていることを確認します。 これらのバージョンは 拡張更新サポート (EUS) リリースであるため、可能な場合は、実稼働 MAS 展開用に偶数の OpenShift バージョンを選択します。

  選択したすべての MAS アプリケーションと依存関係について、IBM が選択した OpenShift バージョンをサポートしていることをクロス検証します。 MAS コンポーネントが IBM SPCR の要件として新しい奇数の OpenShift リリースを一覧表示する場合は、クラスターのバージョンを選択する前に、IBM SPCR、Red Hat ライフサイクル サポート、および ARO バージョンの可用性に対して完全なコンポーネント セットを検証します。

• デプロイ パス。 ランディング ゾーン、ネットワーク、ID、ストレージ、運用制御Azure既存の ARO クラスターを使用します。 IBM が提供する自動化で、サポートされている OpenShift インフラストラクチャを作成または再利用する場合は、IBM Azure Marketplace インストール・パスを使用します。 ARO が要件を満たしていない場合にのみ、Azureで自己管理 Red Hat OpenShift を使用します。

• リージョンの選択。 可能であれば 、可用性ゾーン を持つリージョンを使用します。 ターゲット リージョンがそのパターンをサポートしている場合は、ゾーン間で ARO ワーカー ノードを構成します。 自己管理型の OpenShift の場合は、インストール ファイル install-config.yaml を構成して、OpenShift が複数のゾーンにノードを配置するようにします。 ゾーンで障害が発生した場合、他のゾーンのノードが作業を引き継ぐと、ソリューションが引き続き機能できます。

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

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

自己管理 OpenShift

ARO が制御、分離、または切断されたデプロイの要件を満たしていない場合は、Azureで自己管理 Red Hat OpenShift を使用します。 自己管理型展開の場合は、次のインストール方法のいずれかを選択します。

• Installer Provisioned Infrastructure (インストーラーによってプロビジョニングされたインフラストラクチャ, IPI)。 この方法では、インストーラーを使用して、Azureに OpenShift 環境をデプロイして構成します。 IPI は、セキュリティとネットワークの要件を満たす場合に使用します。

• ユーザー提供インフラストラクチャ (User Provisioned Infrastructure, UPI)。 この方法を使用すると、デプロイをきめ細かく制御できます。 UPI では、環境を構築するためにさらに多くの手順と考慮事項が必要です。 IPI または ARO がニーズを満たしていない場合は、UPI を使用します。 プライベートまたは切断されたインストールは、UPI の一般的なユース ケースです。

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

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

エアギャップ インストールは、セキュリティ要件である場合にのみ使用してください。 エアギャップにより、ソリューション運用が大幅に複雑になります。 ソフトウェアのインストール、コンテナーのミラーリング、セキュリティの脆弱性から保護するためのミラーの更新、ファイアウォールの管理などのアクティビティは、運用上の多大な労力を消費する可能性があります。

エアギャップ インストールの詳細については、次の Red Hat OpenShift ドキュメントを参照して、Azureでの切断されたインストールとプライベート クラスターを参照してください。

• oc-mirror を使用して切断されたインストール用のイメージをミラーリングする
• Azure

エアギャップされた OpenShift のインストール後、 切断された環境に関するガイダンスについては MAS ドキュメントに進むことができます。

ノードと環境のサイズ設定

Maximo Visual Inspection を除くすべてのワークロードについては、選択したリージョンでワーカー ノードとして使用できる現在の世代の Ds または Das シリーズの VM ファミリ (Dsv6 など) から開始します。 Premium Storage をサポートし、デプロイする MAS アプリケーションの CPU、メモリ、ストレージの要件を満たす VM サイズを選択します。

Maximo 目視検査 では、機械学習を実行するために GPU ノードが必要です。 このソリューションでは CUDA が使用され、NVIDIA GPU のみがサポートされます。 ARO の場合は、現在の ARO ワーカー ノード サポート リストから NVIDIA GPU VM サイズを選択し、MAS と OpenShift のバージョンで IBM がサポートしていることを確認します。 セルフマネージド OpenShift の場合は、IBM と Red Hat でサポートされている NVIDIA GPU VM サイズを選択します。

GPU ワーカー ノードの場合は、最小のノードから始めて、要件の増加に合わせてスケールアップします。

ARO と自己管理の OpenShift の場合は、ワーカー ノードに対して同じ MAS ワークロードサイズ設定ガイダンスを使用します。 高可用性をサポートするために 、可用性ゾーン 間でワーカー ノードを構成します。 自己管理型の OpenShift の場合は、可用性ゾーン間でコントロール プレーンも構成します。 次の開始点を使用します。

• 制御ノード。 ARO の場合、コントロール プレーンはサービスの一部として管理されます。 セルフマネージド OpenShift の場合は、選択したリージョン内の可用性ゾーンごとに少なくとも 1 つの VM を使用します。

• [ワーカー ノード]。 選択したリージョン内の可用性ゾーンごとに、少なくとも 2 台のマシンを使用します。 IBM ガイダンス、選択した MAS アプリケーション、および予想される負荷に基づいてワーカー ノードのサイズを設定します。

MAS コアでは、標準サイズの基本インストールに 13 個の vCPU が必要です。 ワーカー ノードのサイズ設定は、構成がデプロイする MAS アプリケーションと環境の負荷によって異なります。 たとえば、10 人のユーザーの Maximo Manage には、さらに 2 つの vCPU が必要です。 これらの値を開始点として扱い、MAS 9.x バージョン、選択したアプリケーション、および予想される使用に関する現在の IBM Maximo Application Suite システム要件 に照らしてサイズを検証します。

自己管理型の OpenShift の場合は、VM の種類を互いに似た状態に保ち、ワーカー ノードと制御ノード間の各可用性ゾーンとの近接性を確保します。 ARO の場合は、ワーカー ノード プールを同じ MAS ワークロード要件に合わせ、リージョンの容量Azureします。

OpenShift oc コマンド ライン インターフェイスを使用したり、MAS をインストールしたりするためにジャンプ ボックスが必要な場合は、組織の管理とセキュリティの要件を満たすサポートされている Linux VM をデプロイします。

ネットワークの構成

ARO の場合は、IBM、Red Hat、およびネットワーク チームが別のオプションを検証しない限り、ARO がデプロイする既定の OpenShift ネットワーク構成を使用します。 ARO コントロール プレーン ノード、ワーカー ノード、Azure サービス依存関係、プライベート エンドポイント、データベース、ハイブリッド接続用の仮想ネットワークと個別のサブネットを計画します。 アップグレード容量や将来のスケールアウトなど、必要な OpenShift ワーカー ノードの数に合わせてノード サブネットのサイズを設定します。

自己管理型の OpenShift の場合は、ブートストラップとインストーラーによって作成されたインフラストラクチャの要件も含まれます。 OpenShift API とノードへの管理アクセスは、承認されたネットワーク パス (ハイブリッド接続、セキュリティで保護されたジャンプ ホスト、組織が必要とするその他の制御など) に制限します。 クラスターエグレスを制限する場合は、OpenShift、MAS インストール、コンテナー イメージプル、更新、監視、および外部サービスに必要な送信依存関係を計画します。

ARO での標準的な MAS 運用インストールの場合は、緊密にパックされた仮想ネットワークから始めないでください。 ランディング ゾーンで許可されている場合は、/16 のクラスレス Inter-Domain ルーティング (CIDR) プレフィックスなど、より大きなアドレス空間を予約し、専用サブネットを割り当てます。 ARO コントロール プレーン サブネットには少なくとも /24 の計画サイズを使用し、ワーカー ノード サブネットには少なくとも /24 計画サイズを使用します。 プライベート エンドポイントと外部データベース サービス用の /27 以上のサブネットを追加します。 必要に応じてAzure Bastionをデプロイする場合は、プレフィックス /26 の AzureBastionSubnet という名前のサブネットを追加します。 Azure Bastion要件の詳細については、「アーキテクチャ」を参照してください。

自己管理型の OpenShift を使用し、IP アドレスが短い場合は、制御ノード サブネットに /27、ワーカー ノード サブネットに /27 の最小プレフィックスを使用して、制約付きの高可用性構成を設計できます。 この制限付きサイズ設定は、ARO 運用デプロイの開始点として使用しないでください。 仮想ネットワークまたはノード サブネットのサイズを下にしないでください。 インストール後の OpenShift デプロイの再対応は中断され、再デプロイが必要になる場合があります。

別のコンテナー ネットワーク インターフェイス (CNI) を使用する場合は、それに応じてネットワークのサイズを設定します。 一部の標準アプリケーションを使用する MAS では、800 を超えるポッドがデプロイされます。このポッドには、おそらく /21 以上の CIDR プレフィックスが必要です。

データベースの詳細

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

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

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

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

• Premium では、より高いスループットと ReadWriteMany (RWX) ワークロード用の NFS 共有が提供されます。 このようなボリュームは、Cloud Pak for Data の Db2 Warehouse や Maximo Manage の Postgres など、RWX ワークロードのクラスター全体で使用されます。

Azure Files NFS では、転送中の暗号化がサポートされます。 MAS OpenShift クライアントで NFS 暗号化を使用できない場合は、アカウントを安全な転送強制ポリシーから除外できます。 詳細については、「NFS Azure ファイル共有: 暗号化」を参照してください。 プライベート エンドポイントを使用して、共有にプライベート接続を提供します。

Cloud Pak for Data を使用して Db2 Warehouse をデプロイする場合は、OpenShift Data Foundation を使用します。 さまざまな Db2 Warehouse データ型に対して Ceph File System (CephFS) および RADOS Block Device (Ceph RBD) ストレージ クラスを使用する OpenShift Data Foundation の例については、「 Cloud Pak for Data コンソールを使用した Db2 インスタンスの作成」を参照してください。

コンテナー ストレージ インターフェイス (CSI) ドライバーでAzure Blob Storageを使用しないでください。これは、一部のポッドの実行が必要なハード リンクをサポートしていないためです。

考慮事項

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

[信頼性]

OpenShift には、自己復旧、スケーリング、回復性のための機能が組み込まれています。 OpenShift と MAS は、コンポーネントが失敗して回復することを想定しています。 自己復旧の主な要件は、クラスターに十分なワーカー ノードがあるということです。 Azure リージョン内のゾーン障害から復旧するには、可用性ゾーン間で制御ノードとワーカー ノードのバランスを取る必要があります。

MAS と OpenShift はストレージを使用して、Kubernetes クラスターの外部で状態を保持します。 障害発生時にストレージの依存関係が引き続き機能するようにするために、可能な場合は必ずゾーン冗長ストレージを使用してください。 ゾーン冗長ストレージは、1 つのゾーンで障害が発生しても引き続き使用できます。

ヒューマン エラーを防ぐために、できるだけ多くの自動化を使用して MAS をデプロイします。 選択した MAS バージョン、OpenShift プラットフォーム、およびデプロイ パスに対して、現在の IBM インストール ドキュメントとサポートされている自動化を使用します。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、セキュリティ設計レビューのチェックリストを参照してください。

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

ARO デプロイを使用すると、ARO 共有責任モデルの恩恵を受けることができます。 Azure Red Hat OpenShiftは、マネージド OpenShift プラットフォームの修正プログラムの適用、更新、監視をユーザーに代わって行う、Microsoftと Red Hat によって共同で設計、運用、およびサポートされています。 ARO の上にデプロイする責任は引き続きお客様にあります。 この責任には、MAS とそのアプリケーション構成、ID 統合、ネットワーク制御、ワーカー容量計画、ストレージの選択、バックアップとディザスター リカバリー、シークレット、データ保護、コンプライアンス要件が含まれます。 詳細については、「Azure Red Hat OpenShiftとAzure Red Hat OpenShift 4.0 サポート ポリシーの概要」を参照してください。

Microsoftは、次のレベルでAzure プラットフォームにセキュリティ保護を構築します。

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

OpenShift プラットフォームがサポートし、IBM が MAS のバージョンとアプリケーションをサポートする OpenShift バージョンを使用します。 可能な場合は、サポートされている長期サポート リリースを使用してください。 自己管理型の OpenShift を使用する場合は、OpenShift プラットフォームと基になる VM の修正プログラムの適用と保守を行う必要があります。 ARO を使用する場合、Microsoftは修正プログラムの適用と管理を処理します。

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

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

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

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

認証

MAS では、Security Assertion Markup Language (SAML) に対する SSO がサポートされています。 Microsoft Entra IDを SAML ID プロバイダーとして使用するには、Microsoft Entra IDでエンタープライズ アプリケーションを作成し、MAS をサービス プロバイダーとして構成します。 詳細については、Microsoft Entra Maximo Application Suite との SSO 統合に関するページを参照してください。

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

また、OpenShift 管理アクセス用に OAuth を構成する必要があります。 ARO については、「Azure Red Hat OpenShift クラスターのMicrosoft Entra認証を構成する」を参照してください。 自己管理型の OpenShift については、「 OpenShift Container Platform 4.21 での ID プロバイダーの構成」を参照してください。

リソースのアクセスと監査

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

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

Azureでの標準的な MAS 展開には、次の主なコスト ドライバーが含まれます。

• ARO クラスターのコスト (ワーカー ノード、課金対象のコントロール プレーンまたはクラスターの料金を含む)
• MAS Core およびデプロイする MAS アプリケーション用にサイズ設定されたワーカー ノード プール
• Maximo ビジュアル 検査用のオプションの GPU ワーカー ノード
• データベース・サービス (SQL Managed Instance、Db2 Warehouse、または IBM がサポートする別のデータベースなど)
• 永続ボリューム、バックアップ、およびインストール成果物のストレージ アカウントまたはマネージド ストレージ サービス
• DNS ゾーン、負荷分散、プライベート エンドポイント、およびAzure Bastionの省略可能なインスタンス

ARO と自己管理の OpenShift の両方に対して、標準の MAS デプロイでは通常、同じワーカー ノードのサイズ設定ベースラインが使用されます。 コスト見積の開始点として、次のインベントリを使用します。

• 6 つの worker VM。
• Db2 Warehouse 用の 3 つのワーカー VM。 一部の構成では、Db2 Warehouse を使用する代わりに、SQL Managed Instanceを置き換えることができます。
• 2 つのAzure Storage アカウント。
• 2 つの DNS ゾーン。
• 2 つのロード バランサー。
• Azure Bastion。
• MAS 内で Maximo Visual Inspection を実行する予定の場合は、1 つの Maximo Visual Inspection GPU ワーカー ノード。

コントロール プレーンのコストはデプロイ モデルによって異なります。 IPI または UPI を使用する自己管理型の OpenShift デプロイの場合は、3 つの制御 VM も含めます。 ARO の場合は、カスタマー マネージド コントロール VM を追加する代わりに、マネージド コントロール プレーンと ARO 固有のクラスター料金を考慮します。

コスト計算ツールを使用して、見積もりの例を確認できます。 構成は異なるため、デプロイを完了する前に、IBM サイズ設定チームで構成を確認してください。

このシナリオを展開

開始する前に、MAS バージョンと アプリケーションの IBM Maximo Application Suite システム要件 と IBM SPCR を確認してください。 デプロイを開始する前に、次のリソースを使用できるようにします。

• 閲覧者アクセス許可を持つAzure サブスクリプションへのアクセス
• サブスクリプションに 対する共同作成者 と ユーザー アクセス管理者 のアクセス許可を持つアプリケーション登録またはサービス プリンシパル名
• Azure DNS ゾーンへのドメインまたは委任されたサブドメイン
• サポートされている ARO クラスター、または ARO クラスターを作成するためのアクセス許可と前提条件
• デプロイ パスが OpenShift インフラストラクチャを作成または管理する場合の Red Hat からのプル シークレット
• MAS エンタイトルメント キー
• MAS のインストール後に作成する MAS ライセンス ファイル
• IBM 推奨クラスターのサイズ設定
• ARO と MAS の要件を満たす既存の仮想ネットワークまたは新しい仮想ネットワーク
• 具体的なデプロイに対する高可用性とディザスター リカバリーの要件
• 選択したデプロイ パスの構成の詳細 (ARO クラスターの詳細、自己管理の OpenShift インストール パラメーターなど)

環境を構築する前に、IBM Planning を参照して、Microsoft Azureのドキュメントにインストールし、設計パラメーターを理解してください。 現在のAzureインストール ガイダンスについては、Microsoft Azureの概要に関する Maximo Application Suite を参照してください。 現在の IBM ドキュメントと MAS バージョンのサポート マトリックスに対して、デプロイ プロセスを検証します。

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

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

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

貢献者

Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。

主要な著者:

• David Baumberg |チーフ アーキテクト
• ローランド・ニューウェンハウス |チーフアーキテクト

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

開始するためのヘルプについては、次のリソースを参照してください。

• Azure Red Hat OpenShift
• Maximo Application Suite on Microsoft Azure の概要
• Microsoft Azureへのインストールの計画
• Azure
• OpenShift UPI ガイド
• Maximo の要件
• IBM ソフトウェア製品互換性レポート
• IBM Maximo Application Suite (BYOL)

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

• IBM Passport Advantage
• Azure DNS の概要
• Azure NetApp Filesの導入
• Azure Red Hat OpenShiftの概要
• Red Hat カスタマー ポータル

関連リソース

• Azure エンタープライズ クラウド ファイル共有
• ARO クラスターに JBoss エンタープライズ アプリケーション プラットフォーム (EAP) を使用してJava アプリケーションをデプロイします