Azure VM のデプロイで LzLabs Software Defined Mainframe (SDM) を使用する

Azure Virtual Machines
Azure Database for PostgreSQL
Azure Virtual Network
Azure Resource Manager

LzLabs ソフトウェア定義メインフレーム (SDM) では、レガシ アプリケーションのソース コードを検索、変更、再コンパイルする必要がなくなるため、従来のワークロードの再ホストのリスクと複雑さが大幅に軽減されます。 このアプローチにより、z/Architecture バイナリ実行可能プログラムは、オープン システム ソフトウェア スタックを実行している x86_64 アーキテクチャ コンピューターでネイティブな速度で動作することが可能になり、レガシを最新化する道が開かれます。

アーキテクチャ

付属の記事のテキストで詳細に説明されているアーキテクチャとデータ フローを示す図。このアーキテクチャの SVG ファイル をダウンロードします。

ワークフロー

  1. LzLabs SDM アプリケーションは、3270 ターミナルを介して通常のメインフレーム アプリケーションと同じようにアクセスされます。 任意のターミナル エミュレーターを使用できます。 管理、管理、およびその他のアクティビティのために、 LzWorkbench クライアント が使用されます。 サーバー コンポーネントは SDM VM 上で実行されます。
  2. 通常ポート アクセスは、顧客のセキュリティ要件に適合するように構成されています。
  3. SDM のセキュリティで保護された実装では、次の要素で構成される Web サービス フロント エンドを実装する必要があります。
  4. SDM は、仮想ネットワーク (VNet) ピアリングを使用して、バックアップ、ディザスター リカバリー (DR)、およびセカンダリ Azure リージョンにフェールオーバーするように構成できます。 これにより、初期 VM がオフラインになった場合に一貫性のあるレプリカが保持されるため、運用ワークロードに対する SDM の可用性が向上します。
  5. 運用環境の SDM 仮想マシンはレプリケートされ、 Azure Site Recoveryによってフェールオーバー リージョン内で同期されます。 このサービスは、運用環境のメイン OS ディスクと、接続されたディスク イメージをセカンダリ リージョン SDM と同期します。 これは、インデックス ファイル処理 (アイテム 10 を参照) を担当するディスクを除く、接続されているすべてのディスクに対して実行されます。 また Azure Site Recovery は、他のすべての VM イメージをセカンダリ リージョンと同期するためにも使用されます。
  6. このアーキテクチャのデータベースは PostgreSQL IaaS です。 現時点では、Azure PostgreSQL サービスは使用できません。また、デプロイの SDM で PostgreSQL サービスとしてのインフラストラクチャを使用する必要があります。 これは、ユーザー定義データ型 (UDT) を処理するための Azure PostgreSQL の制限によるものです。 セカンダリ リージョンのデータベース インスタンスは、先行書き込みトランザクション ログを使用して最新の状態に保たれます。 これにより、リージョン間のフェールオーバーが可能になります。 フェールオーバーが発生すると、モードがアクティブに設定されます。 運用環境のフェールオーバー データベースを運用リージョン内でトランザクション的に一貫性のある状態に保つために、同じプロセスが使用されます。 先行書き込みトランザクション ログを使用して、これら 2 つのレプリカを同期した状態に保つことで、データベース層の可用性が高くなります。 注: 最適なパフォーマンスを得るには、データベース VM と SDM VM が Azure 近接配置グループに配置されている必要があります。
  7. システムへのセキュリティで保護されたアクセスを維持するために、DR リージョンに Web サービス フロント エンドをデプロイする必要があります。 多くのメインフレーム ワークロードには、CICS トランザクションと DB2 データにアクセスするための API Web サービス レイヤーがあります。
  8. Active Directory Domain Services 拡張機能を使用して RACF とトップ シークレット ID を統合する場合、LzVault は、メインフレームから移行されたセキュリティ ルールに対して Azure での認証と承認を提供します。
  9. Barman サーバーはデータ層で構成されます。 これにより、運用リージョンとセカンダリ リージョンの両方における、特定の時点に復旧するための PostgreSQL データベースのスナップショット レプリカが提供されます。
  10. アイテム 5 に記載されているように、SDM のインデックス付きファイル処理を保持するディスクは、データベース ミラーリング ソリューションを使用してリージョン間で同期する必要があります。 これは、Azure Site Recovery が、データベースに必要なトランザクションの一貫性を保証できないためです。 インデックス付きファイル処理は PostgreSQL 内ではないため、これを提供できるソリューションを使用する必要があります。
  11. バッチ ジョブ処理のスケジューリングに対応するには、 Azure Logic Apps や SMA などのスケジューラを使用する必要があります。
  12. 可用性を実現するために、Azure 可用性セットには 2 台の SDM VM がデプロイされています。 Azure Load Balancer は、2 台の VM に負荷分散サービスを提供します。 状態は、 Azure 共有ディスクを使用して 2 台の VM 間で共有されます。 これは、DRDB を使用して DR インスタンスにレプリケートされます。

コンポーネント

  • Azure Virtual Machines は、Azure が提供するオンデマンドでスケーラブルなコンピューティング リソースのひとつです。 Azure Virtual Machine (VM) では、VM を実行する物理的なハードウェアを購入して維持する必要がなく、仮想化がもたらす柔軟性が提供されます。
  • 仮想ネットワーク (VNet) は、Microsoft Azure Virtual Network 内のプライベート ネットワークの基本的な構成要素です。 Microsoft Azure Virtual Network を使用すると、VM などのさまざまな種類の Azure リソースが相互、インターネット、オンプレミスのネットワークと安全に通信できるようになります。 Microsoft Azure Virtual Network は、自社のデータセンターで運用する従来のネットワークと似ていますが、スケール、可用性、分離性など、Azure のインフラストラクチャのさらなる利点が提供されます。
  • Azure Virtual Network Interface は、Azure VM がインターネット、Azure のその他リソース、オンプレミス リソースと通信できるようにする Network Interface Controller (NIC) です。 このアーキテクチャで示されているように、同じ VM にネットワーク インターフェイス カードを追加することができ、それにより、Solaris の子 VM で独自の専用ネットワーク インターフェイス デバイスと IP アドレスを使用できます。
  • Azure SSD マネージド ディスク は、Azure によって管理されて Azure Virtual Machines で使用されるブロックレベルの記憶域ボリュームです。 使用できるディスクの種類は、Ultra Disk、Premium SSD、Standard SSD、Standard ハード ディスク ドライブ (HDD) です。 このアーキテクチャでは、Premium SSD または Ultra Disk SSD をお勧めします。
  • Microsoft Azure Storage と Azure Files によって提供されるクラウド内のフル マネージド ファイル共有には、業界標準のサーバー メッセージ ブロック (SMB) プロトコルを使用してアクセスできます。 Azure ファイル共有は、クラウドまたはオンプレミス デプロイにある Windows、Linux、および macOS に同時にマウントできます。
  • Azure ExpressRoute を利用すると、接続プロバイダーが提供するプライベート接続を介して、オンプレミスのネットワークを Microsoft クラウドに拡張できます。 ExpressRoute では、Microsoft Azure、Office 365 などの Microsoft クラウド サービスへの接続を確立できます。
  • Azure SQL Database は、アップグレード、修正プログラムの適用、バックアップ、監視などにユーザーの介入なしでほとんどのデータベース管理機能を処理するフル マネージドの PaaS (サービスとしてのプラットフォーム) データベース エンジンです。 Azure SQL Database は常に、最新の安定したバージョンの SQL Server データベース エンジンおよびパッチが適用された OS 上で実行され、99.99% の可用性を備えています。 Azure SQL Database に組み込まれた PaaS 機能により、お客様は、ビジネスにとって不可欠なドメイン固有のデータベース管理や最適化アクティビティに集中することができます。

シナリオの詳細

LzLabs ソフトウェア定義メインフレーム (SDM) は、ワークロードの再ホストとメインフレーム アプリケーションの最新化プラットフォームです。 SDM は、ソース コードの変更、再コンパイル、またはデータ型の変換を必要としない、オープン システムでのメインフレーム レガシ アプリケーションの実行を可能にします。 また、SDM には、システム全体の整合性や操作を損なうことなく、最新の言語および実装にレガシ アプリケーションが適切に最新化されることを可能にする機能が備わっています。

SDM では、レガシ アプリケーションのソース コードを検索、変更、再コンパイルする必要がなくなるため、従来のワークロードの再ホストのリスクと複雑さが大幅に軽減されます。 このアプローチにより、z/Architecture バイナリ実行可能プログラムは、オープン システム ソフトウェア スタックを実行している x86_64 アーキテクチャ コンピューターでネイティブな速度で動作することが可能になり、レガシを最新化する道が開かれます。

考えられるユース ケース

  • ソース コードがない。 LzLabs は、メインフレームのワークロードを持ち、実行中のアプリケーションのソース コードを持たないお客様向けのソリューションです。 これは、ソリューションが、ソース コードを IP に提供していない、独立系ソフトウェア ベンダーから購入した、カスタマイズ可能な既製のソリューション (COTS) であった場合に発生する可能性があります。 また、このような COBOL ベースのアプリケーションは、かなり以前に記述されていることがよくあるため、ソース コードが失われたり、間違って与えられたりしている可能性があります。 ここで必要なのは、SDM で実行するためのロード モジュール (バイナリ) だけであるため、LzLabs でこの問題は解決されます。
  • お客様はソース コードを持っており、再ホストを希望している。 お客様がソース コードを所有していることはあり、メインフレーム ワークロードを再ホストしてコストを削減し、Azure などのクラウド プラットフォームの利点を活用することを望んでいるだけの場合があります。 この COBOL コードは、最新の DevOps 環境で SDM に保持できます。
  • フェールオーバー。 アップタイムを向上させ、ビジネス継続性における中断の可能性を回避するために、お客様は LzLabs SDM をフェールオーバー環境に使用できます。 この場合、ロード モジュールが SDM に読み込まれ、運用環境が使用できなくなったときに、セカンダリ環境として使用されます。

考慮事項

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

可用性

アプリケーション層の可用性は、図に示すように Azure Site Recovery と共に提供されます。 LzLabs SDM はデータベース層に PostgreSQL を活用するため、先行書き込みトランザクション ログで可用性が提供されます。 これにより、セカンダリ データベースが運用データベースとトランザクション上の一貫性があることが保証されます。

操作

図の Azure 環境は、Azure ポータルまたは Azure Resource Manager テンプレートとスクリプトを使用して管理されます。 これにより、資産の管理 (サイズ変更など) とセキュリティとアクセスの管理が可能になります。 実際の SDM 環境の管理は、LzWorkbench 管理ツールを使用して提供されます。 これにより、SDM での実行環境の作成と管理が可能になります。

パフォーマンス効率

メインフレーム ワークロードを Azure に移行するときは、vCPU あたり MIPS の比率が、vCPU あたり 50 から 150 MIPS までの範囲内であることに注意してください。 これは、ワークロードの種類によって異なります。 オンラインおよびバッチ環境用のメインフレーム ワークロードをプロファイリングし、それに応じてリソースのサイズを調整する必要があります。

スケーラビリティ

現時点では、SDM をスケーリングするためのソリューションは、vCPU とメモリを追加することによって仮想マシンをスケールアップすることです。

セキュリティ

Azure アセットへのアクセスは、Azure portal か Azure Resource Manager、またはその両方を使用して管理されます。 SDM のセキュリティは、SDM の Vault コンポーネントを使用して管理されます。 これにより、RACF またはトップ シークレットからのセキュリティとアクセス許可が、Azure での管理のために LDAP ベースの環境に移行されます。

コストの最適化

Azure 製品と構成のコストを見積もるには、 Azure 料金計算ツールを参照してください。

LzLabs ソフトウェアで定義されているメインフレーム製品とその関連サービスの価格の詳細については、 LzLabs の Web サイトを参照してください。

共同作成者

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

プリンシパル作成者:

  • Jonathon Frost | プリンシパル ソフトウェア エンジニア

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

次のステップ

  • 詳細については、 legacy2azure@microsoft.comにお問い合わせください。

LzLabs の次のリソースを参照してください。

Microsoft の次のドキュメントを参照してください。

Azure アーキテクチャ センターの次の関連する記事を参照してください。