編集

次の方法で共有


AIX UNIX オンプレミスから Azure Linux への移行

Azure NetApp Files
Azure Site Recovery
Azure SQL データベース
Azure Virtual Machines
Azure Virtual Network

このソリューションでは、IBM AIX Unix プラットフォームから Azure での Red Hat Enterprise Linux (RHEL) への移行について説明します。 実世界の例には、医療とヒューマン サービスの大規模な顧客向けアプリケーションが挙げられます。 トランザクション時間と待機時間の短縮は、レガシ システムと Azure システムの両方にとって重要な要件でした。 関連するグラフィック イメージを含むネットワーク ファイル ストアにリンクされたデータベースに、顧客情報を格納することが重要な機能です。 Azure では、このニーズに Azure NetApp Files で対応しています。

アーキテクチャ

次の図は、移行前のオンプレミスの AIX レガシ システム アーキテクチャを示しています。

移行前の AIX システム アーキテクチャを示す図。

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

  • ネットワーク アプライアンスは、広範なネットワーク ルーティングと負荷分散レイヤー (A) を提供します。

  • プレゼンテーション層 (B) は、独自のサブネット内の 3 つの Java Web フロントエンド マシンを使用します。これにより、ファイアウォールによってネットワーク トラフィックがセグメント化されます。

  • ファイアウォール (C) は、参加しているすべての層とサブシステムの間にネットワーク境界を提供します。 ファイアウォールは有効ですが、管理上の負担もあります。

  • システムは、3 つの Web アプリケーションサーバーを持つアプリケーション層 (D) に対して、ユーザー要求を提供します。

  • アプリケーション層は、DB2 データベースと、ネットワーク接続ストレージ (NAS) を呼び出します。

    • データベース (E) は、AIX 上の DB2 です。 HA/DR クラスターでは、3 つの DB2 サーバーが構成されています。

    • アプリケーションでは、顧客とユーザーのための画像や PDF などのバイナリ オブジェクトが NAS サブシステム (F) に保存されます。

  • 管理サーバーおよび MQ サーバー (G) は、ファイアウォールによってセグメント化された、独自のサブネット内にあります。

  • ライトウェイト ディレクトリ アクセス プロトコル (LDAP) ID 管理サービス (H) は、ファイアウォールによってセグメント化された、独自のサブネット内にあります。

次の図は、Azure RHEL の移行後のシステム アーキテクチャを示しています。

移行後の Azure アーキテクチャを示す図。

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

データフロー

  1. Azure のシステムへのトラフィックは、Azure ExpressRoute と Azure Traffic Manager を経由するようにルーティングされます。

    • ExpressRoute は、Azure 仮想ネットワークへの、セキュリティで保護された、信頼性の高いプライベート接続を提供します。 ExpressRoute は、信頼性が高く、低遅延で高速の、最大 100 Gbps の帯域幅で Azure に接続します。
    • Traffic Manager は、公開アプリケーションのトラフィックを Azure リージョン間で分散します。
  2. ネットワーク管理層は、エンドポイントのセキュリティ、ルーティング、および負荷分散のサービスを提供します。 このレイヤーでは、Azure Load Balancer と Azure Web Application Firewall が使用されます。

  3. Azure App Service がプレゼンテーション層として機能します。 App Service は、.NET または Java アプリケーション用のサービスとしてのプラットフォーム (PaaS) 層です。 Azure リージョン内および Azure リージョン間での可用性とスケーラビリティのために App Service を構成できます。

  4. このソリューションは、ネットワーク セキュリティ グループでセグメント化された独自の仮想ネットワーク内の各アプリケーション層をカプセル化します。

  5. 可用性セットと共有 Azure Storage は、アプリケーション層レベルの仮想マシン (VM) に対して HA とスケーラビリティを提供します。 アプリケーション クラスター サーバーはトランザクションの状態を共有し、必要に応じて VM をスケールアップします。

  6. アプリケーションは、プライベート エンドポイント接続を使用して、Azure SQL Database にデータを格納したり、データにアクセスしたりします。 SQL Database は、自動および地域間 BCDR の geo レプリケーションと自動フェールオーバー グループを提供する、ビジネス継続性の構成で実行されます。

  7. Azure NetApp Files は、バイナリデータへの高速アクセスとセカンダリ リージョンへのレプリケーションを備えた共有 NAS を提供します。

  8. セカンダリ リージョンには、次のコンポーネントを含む BCDR が用意されています。

    • Azure Site Recovery では、アクティブ/パッシブ構成で DR フェールオーバー用の VM イメージがバックアップされます。 Site Recovery は、セカンダリ リージョンに整合性のある VM イメージ レプリカを作成し、VM イメージの同期を維持します。
    • SQL Database ビジネス継続性の構成によって、データベース トランザクションの一貫性が維持されます。 SQL Database は、レプリカ データベースをプロビジョニングし、同期または非同期のデータレプリケーションとの同期を維持します。

システムには、次のコンポーネントも含まれています。

  • 管理仮想ネットワーク内の 1 つ以上の VM で、管理機能が提供されます。

  • Azure Service Bus は、MQ シリーズ インフラストラクチャを実装し、アプリケーションのメッセージ キュー サービスを提供します。 MQ シリーズから Azure Service Bus への移行の詳細については、ActiveMQ から Azure Service Bus への移行に関するページを参照してください。

  • Microsoft Entra ID は、レガシ LDAP サービスから移行されたすべての Azure エンティティと ID に対して ID とアクセス管理を提供します。

コンポーネント

  • Azure ExpressRoute により、接続プロバイダーが提供するプライベート接続を介して、オンプレミス ネットワークが Microsoft クラウド サービスへと拡張されます。 ExpressRoute は、低遅延で高速な帯域幅で、Azure システムへのセキュリティで保護された信頼性の高いプライベート接続を提供します。

  • Azure Traffic Manager は、トラフィックを Azure リージョン間に分散させる、高可用性と迅速な応答性を備えた DNS ベースのトラフィック ロード バランサーです。

  • Azure Load Balancer は、構成された負荷分散規則と正常性プローブに従って、バックエンド VM 間で着信ネットワーク トラフィックを分散することで、高可用性をサポートします。 ロード バランサーは、開放型システム間相互接続 (OSI) モデルの第 4 層で動作します。

  • Azure Web Application Firewall は、Web アプリを悪意のある攻撃や一般的な Web の脆弱性から保護するクラウドネイティブの WAF サービスです。

  • Azure App Service は、スケーラブルで信頼性の高いクラウド インフラストラクチャ上で任意のプラットフォームのエンタープライズ Web アプリをすばやく簡単にデプロイするための、フル マネージド Web ホスティング サービスです。

  • Azure Virtual Machines は、オンデマンドでスケーラブルなコンピューティング リソースを提供する Azure サービスのひとつです。 Azure VM を使用すると、物理ハードウェアを購入して維持する必要なしに、仮想化を柔軟に利用できます。

  • Azure Virtual Network は、Azure のプライベート ネットワークの基本的な構成ブロックです。 Virtual Network を使用すると、VM などのさまざまな Azure リソースで、相互に、およびインターネットやオンプレミス ネットワークと、安全に通信できます。 Virtual Network によって、スケーラビリティ、可用性、分離などの Azure インフラストラクチャの利点がもたらされます。

  • Azure Files Storage は、業界標準のサーバー メッセージ ブロック (SMB) プロトコルを介してアクセスできるフル マネージド ファイル共有をクラウドで提供します。 クラウドおよびオンプレミスの Windows、Linux、macOS デプロイで、Azure のファイル共有を同時にマウントできます。

  • Azure SQL Database は、常に最新の OS と安定した SQL Server データベース エンジンのバージョンで実行されるフル マネージド データベース PaaS であり、最高レベルの可用性を備えています。 SQL Database によって、アップグレード、修正プログラムの適用、バックアップ、監視などのデータベース管理機能がユーザーの介入なしで処理されます。

  • Azure NetApp Files は、NetApp を利用したエンタープライズレベルの Azure ファイル共有を提供します。 Azure NetApp Files を使用すると、企業はコードを変更することなくファイルベースの複雑なアプリケーションを簡単に移行して実行できます。

  • Azure Site Recovery は、Azure ネイティブの DR サービスです。 Azure Site Recovery では、計画的な、および予期しない停止中にアプリケーションの実行を継続できるように、レプリケーション、フェールオーバー、復旧のプロセスがデプロイされます。

  • Azure Service Bus は、シンプルなハイブリッド統合を備えた信頼性の高いクラウド メッセージング サービスです。

  • Microsoft Entra ID は、Microsoft のクラウドベースの ID およびアクセス管理のエンタープライズ サービスです。 Microsoft Entra シングルサインオンと多要素認証は、サイバーセキュリティ攻撃から保護しながら、ユーザーがサインインしてリソースにアクセスするのに役立ちます。

代替

Azure App Service 環境 は、高スケール、分離、およびセキュリティで保護されたネットワーク アクセスを必要とするアプリケーション ワークロードに適しています。 この機能は、App Service アプリを高スケールで安全に実行するための、完全に分離された専用環境を提供します。 App Service 環境では、次の種類のアプリをホストできます。

  • Linux Web アプリ (現在の例)
  • Windows Web アプリ
  • Docker コンテナー
  • モバイル アプリ
  • 関数

シナリオの詳細

レガシ システムとクラウド実装の明確な違いの 1 つは、ネットワークのセグメント化にあります。 レガシ システムでは、ネットワークはファイアウォールによってセグメント化されています。 Azure などのクラウド プラットフォームでは、仮想ネットワークと、複数の条件に基づいてトラフィックをフィルター処理するネットワーク セキュリティ グループによって、ネットワークがセグメント化されます。

システム間のもう 1 つの違いは、高可用性 (HA) とディザスター リカバリー (DR) のモデルです。 レガシ システムでは、HA および DR は主にバックアップを使用しており、同じデータ センターの冗長サーバーをある程度使用していました。 この構成では、わずかな DR が提供されていましたが、HA 機能はほとんどありませんでした。 HA および DR の向上が、Azure Platform への移行の重要な推進要因でした。 Azure は、クラスタリング、共有ストレージ、および Azure Site Recovery を使用して高レベルの HA および DR を提供します。

考えられるユース ケース

オンプレミスの IBM AIX から Azure での RHEL に移行するための主要な推進要因には、次のような要因が考えられます。

  • ハードウェアが更新され、コストが削減される。 オンプレミスでは、レガシ ハードウェア コンポーネントが古くなり、サポート対象外になることが頻繁に発生します。 クラウド コンポーネントは常に最新です。 クラウドでは、月単位のコストを削減できる可能性があります。

  • アジャイルな DevOps 環境。 オンプレミスの AIX 環境でコンプライアンスの変更をデプロイするには、数週間かかることがあります。 同様のパフォーマンス エンジニアリング環境を何度も設定して、変更をテストすることが必要になる場合があります。 Azure クラウド環境では、ユーザー受け入れテスト (UAT) と開発環境を数時間で設定できます。 明確に定義された、最新の DevOps 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用して、変更を実装できます。

  • ビジネス継続性とディザスター リカバリー (BCDR) の向上。 オンプレミス環境では、目標復旧時間 (RTO) が長くなる可能性があります。 オンプレミスの AIX 環境の例では、従来のバックアップと復元による RTO は 2 日間でした。 Azure に移行すると、RTO が 2 時間に短縮されました。

考慮事項

Microsoft Azure Well-Architected Frameworkに基づく次の考慮事項は、このソリューションに適用されます。

可用性

  • Azure NetApp Files では、Azure NetApp Files ボリューム のリージョン間レプリケーションを使用して、セカンダリ リージョンにファイル ストアを維持できます。 このAzure の機能によって、ボリュームのリージョン間レプリケーションを通じてデータ保護が提供されます。 リージョン全体で障害が発生した場合は、重要なアプリケーションをフェールオーバーできます。 ボリュームのリージョン間レプリケーションは、現在プレビュー段階です。

  • アプリケーション クラスター サーバーは必要に応じて VM をスケールアップします。これにより、Azure リージョン内の可用性が向上します。

操作

プロアクティブな監視と管理を行う場合は、移行される AIX ワークロードの監視に Azure Monitor を使用することを検討してください。

パフォーマンス効率

  • このアーキテクチャの潜在的なボトルネックは、ストレージとコンピューティングのサブシステムです。 必要に応じて、ストレージと VM SKU を選択するようにしてください。

  • 使用できる VM ディスクの種類は、Ultra ディスク、Premium ソリッド ステート ドライブ (SSD)、Standard SSD、Standard ハード ディスク ドライブ (HDD) です。 このソリューションでは、Premium SSD または Ultra ディスクを使用することをお勧めします。

  • AIX システムからの VM のサイズ設定を見積もる場合には、ほとんどの x86 vCPU よりも AIX CPU の方が約 1.4 倍高速である点に気を付けしてください。 このガイドラインは、ワークロードによって異なる場合があります。

  • 近接通信配置グループに、相互に通信する必要がある複数の VM を配置します。 VM 同士を近くに配置すると、通信待機時間が最も短くなります。

スケーラビリティ

  • Azure ExpressRoute では、初期レプリケーションまたは変更されたデータの継続的なレプリケーションのために大きな帯域幅を使用する実装の場合は、高スケールがサポートされます。

  • スケーラビリティを含むインフラストラクチャ管理は、Azure のデータベースで自動化されています。

  • アプリケーション サーバー VM インスタンスを追加することで、アプリケーション層をスケールアウトできます。

セキュリティ

コストの最適化

  • AIX ワークロードを Azure の Linux に移行すると、大幅なコスト削減が可能です。 ハードウェアのメンテナンスが排除され、設備のコストが削減されます。通常は運用コストを 8 倍から 10 倍削減できます。 Azure では、必要に応じて季節的または定期的なワークロードの追加容量に対応できます。そのため、全体的なコストが削減されます。

  • また、AIX ワークロードを Azure に移行すると、クラウドネイティブ サービスを使用することでコストを削減できます。 たとえば、次のようになります。

    • 複数の VM を設定する代わりに、Azure App Service をプレゼンテーション層に対して使用する。
    • ハードウェア ベースのファイアウォールを使用する代わりに、Azure 仮想ネットワークを使用してワークロードをセグメント化する。

共同作成者

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

プリンシパル作成者:

次の手順