次の方法で共有


Azure での Unisys ClearPath MCP 仮想化

Azure ExpressRoute
Azure Storage
Azure Virtual Machines
Azure Virtual Network

Unisysメインフレームシステムは、その系列を最初の商用メインフレームまでトレースします。 Unisys ClearPath Forward (CPF) Dorado (2200) および Libra (Master Control Program) システムは、フル機能のメインフレームオペレーティング環境です。 ミッション クリティカルなワークロードを処理するために垂直方向にスケーリングできます。 これらのシステムは、エミュレート、変換、または Azure に最新化できます。 Azure では、同様のパフォーマンス特性または改善されたパフォーマンス特性とサービス レベル アグリーメント メトリックが提供されます。

この記事では、従来の Unisys CPF Libra メインフレームを使用して、Microsoft パートナーである Unisys の仮想化テクノロジを使用する方法について説明します。 このアプローチは、メインフレームを Azure にすばやく移行するのに役立ちます。 これにより、アプリケーション コードを再書き込みまたは再コンパイルしたり、データベース アーキテクチャを再設計したりする必要がなくなります。 レガシ コードは、元の形式で保持されます。 アプリケーション画面、ユーザー操作、および基になるデータ構造は変更されず、ユーザーを再トレーニングする必要がなくなります。

Unisys のリプラットフォームにより、Libra システム全体が現在の専用ハードウェアから仮想マシン (VM) として Azure に持ち上げられます。 マスター コントロール プログラム (MCP) OS とすべてのプロセッサ、ライブラリ、およびデータは、独自の環境と同じように表示されます。 ソフトウェア シリーズ MCP OS には Unisys のライセンスが必要です。 このアーキテクチャには、仮想テープ サーバーの操作や自動化とワークロード管理 (OpCon) などの機能を管理するサポート VM が含まれています。 これらの VM は、Web サービスやその他のサポート機能も処理します。

このアプローチの利点は、他の手法と比較して Azure に迅速に移行することです。 ハードウェアのメンテナンスと施設のコストは発生しないため、投資収益率 (ROI) が速くなります。 MCP 環境は変更されないため、ユーザーまたはプログラマの再トレーニングに関連するコストも発生しません。

クライアントの目標に応じて、移行された MCP は、MCP 環境内または Azure 内でアプリケーションを最新化するための最終的な状態または最初のステップです。 この移行方法では、アプリケーションを更新するための測定パスを計画できます。 既存のアプリケーション コードで行った投資が保持されます。 変換後は、他の Azure データ分析サービスを使用することもできます。

建築

次のアーキテクチャ図は、Azure に移行する前の一般的なオンプレミスの Unisys CPF Libra (MCP) メインフレームを示しています。

Unisys CPF Libra の一般的なオンプレミス メインフレーム アーキテクチャを示す図。

次のアーキテクチャ図は、従来の Unisys CPF Libra メインフレームに Unisys 仮想化テクノロジを適用する方法を示しています。

Azure での仮想化後のメインフレーム アーキテクチャを示す図。

この図は、Azure での仮想化後のメインフレーム アーキテクチャのアーキテクチャとコンポーネントを示しています。 点線は、図をオンプレミスと Azure の 2 つのメイン セクションに分割します。 [オンプレミス] セクションでは、ユーザー アイコンはオンプレミス ユーザーを表します。 オンプレミス セクションには、レガシ システム出力デバイスを表す 2 つのアイコンも含まれています。 実線は、Azure ExpressRoute を表すアイコンをオンプレミス のユーザー、レガシ デバイス、および Azure セクションにあるピア仮想ネットワークに接続します。 Azure セクションには、外部 VM に移行されたさまざまな操作を表すアイコンも含まれています。 線はこれらのアイコンを Azure Storage アカウントの Azure Private Link に接続します。 別の行は、Windows Server 仮想マシン上のさまざまなシステムを含むボックスにストレージ アカウントを接続します。 これらのシステムには、通信、統合ミドルウェア、操作と監視、アプリケーション サーバー、ファイルと DBMS の機能、および MCP オペレーティング システムが含まれます。 Azure Site Recovery というラベルの付いたボックスには、これらのコンポーネントがすべて含まれています。

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

ワークフロー

次のワークフローは、前の図に対応しています。 最初の 3 つの手順は、両方の図に対応し、システムの元の状態と移行された状態の類似点を強調します。

  1. Azure のシステム リソースにアクセスするための Web ブラウザーは、オンデマンドユーザーとオンライン ユーザー向けの従来のBuroughs ターミナル エミュレーションに代わるものになります。 ユーザーは、トランスポート層セキュリティ (TLS) ポート 443 を介して Web ベースのアプリケーションにアクセスします。 Web ベースのアプリケーションのプレゼンテーション 層は変更されず、ユーザーの再トレーニングの必要性が最小限に抑えられます。 ユーザーの再トレーニングが問題でない場合は、最新の UX フレームワークを使用して Web アプリケーション プレゼンテーション レイヤーを更新できます。 VM への管理者アクセスの場合は、 Azure Bastion ホスト を使用して、開いているポートを最小限に抑え、セキュリティを強化します。

  2. プリンターとその他のレガシ システム出力デバイスは、IP アドレス経由で Azure ネットワークに接続されている場合にサポートされます。 MCP の印刷機能は、アプリケーションの変更が不要になるように保持されます。

  3. 操作は MCP から外部 VM に移動されます。 エコシステム内の OpCon VM を使用して、環境全体を監視および制御することで、より多くの自動化を実現できます。

  4. 物理テープが使用中の場合は、仮想テープに変換されます。 テープの書式設定と読み取り/書き込み機能は保持されます。 テープは、Azure またはオフライン ストレージに書き込まれます。 テープ機能が維持されるため、ソース コードを書き換える必要がなくなります。 この方法を使用する利点には、仮想テープ ファイルのバックアップ用の Azure Blob Storage アカウントと、ディスク メディアに対して直接入力/出力操作が実行されるため、アクセス時間が短縮されることがあります。

  5. MCP ストレージ コンストラクトは、Azure Storage にマップできます。 この方法では、MCP ドライブ マッピングの名前付け規則が維持されます。 アプリケーションや操作の変更は必要ありません。

  6. Azure Site Recovery にはディザスター リカバリー (DR) 機能が用意されています。 Azure データセンターで障害が発生した場合の迅速なフェールオーバーのために、Azure VM をセカンダリ Azure リージョンにミラーリングします。

コンポーネント

  • Azure Virtual Machines は、Azure が提供するオンデマンドでスケーラブルなコンピューティング リソースの 1 つです。 Azure VM を使用すると、物理ハードウェアを購入して保守することなく、仮想化の柔軟性を実現できます。 このアーキテクチャでは、Virtual Machines は Unisys CPF Libra ワークロードをホストします。 このアプローチは、独自のハードウェアから Azure へのシームレスな移行を保証するのに役立ちます。

  • Azure Virtual Network は、Azure のプライベート ネットワークの基本的な構成要素です。 Virtual Network を使用すると、Virtual Machines など、さまざまな種類の Azure リソースが、互い、インターネット、オンプレミス ネットワークとより安全に通信できるようになります。 Virtual Network は、独自のデータセンターで運用する従来のネットワークに似ていますが、スケール、可用性、分離など、Azure インフラストラクチャの利点が含まれています。 このアーキテクチャでは、Virtual Network により、移行された Unisys CPF Libra ワークロードと他の Azure サービス間の通信が容易になります。

  • 仮想ネットワーク インターフェイス カード を使用すると、Azure VM はオンライン、Azure、およびオンプレミスのリソースと通信できます。 このアーキテクチャでは、同じ Azure VM にさらにネットワーク インターフェイス カードを追加できます。 このセットアップにより、Solaris 子 VM はそれぞれ専用のネットワーク インターフェイス デバイスと IP アドレスを持つことができます。

  • Azure マネージド ディスク は、Azure によって管理され、Virtual Machines で使用されるブロックレベルのストレージ ボリュームです。 使用可能なディスクの種類は、Azure Ultra Disk Storage、Azure Premium SSD、Azure Standard SSD、Azure Standard HDD です。 このアーキテクチャでは、移行されたワークロードの高パフォーマンスと信頼性を確保するために、Premium SSD または Ultra Disk Storage をお勧めします。

  • Azure Files には、業界標準のサーバー メッセージ ブロック プロトコルを使用してアクセスできるフル マネージドのファイル共有がクラウドに用意されています。 Windows、Linux、macOS のクラウドまたはオンプレミスのデプロイでは、Azure ファイル共有を同時にマウントできます。 Azure Files は、信頼性と拡張性に優れたファイル ストレージを提供することで、移行されたワークロードをサポートします。

  • Azure ExpressRoute は、接続プロバイダーが容易にするプライベート接続を介して、オンプレミス ネットワークを Microsoft Cloud に拡張します。 ExpressRoute を使用して、Azure や Microsoft 365 などの Microsoft クラウド サービスへの接続を確立します。 このアプローチにより、移行された Unisys CPF Libra ワークロードとオンプレミス リソース間の接続性が向上し、信頼性が高くなります。

  • Site Recovery を使用すると、ワークロードをプライマリの場所からセカンダリの場所にレプリケートできます。 このアーキテクチャでは、Site Recovery を使用して、移行されたワークロードのシステムの可用性と一貫性を確保します。

シナリオの詳細

このシナリオでは、Unisys の仮想化テクノロジを使用して Unisys CPF Libra ワークロードを Azure に移行するためのコンテキストを提供します。 主な目標は、既存のアプリケーション コードとユーザー操作を維持しながら、Azure への迅速かつ低リスクの移行を実現することです。 この方法により、アプリケーション コードを書き換えたり、データベース アーキテクチャを再設計したりする必要がなくなり、ユーザーやプログラマがシームレスに移行できるようになります。

顧客の目標は次のとおりです。

  • Unisys CPF Libra ワークロードを Azure に迅速に移行します。
  • 移行プロセスに関連するリスクを最小限に抑えます。
  • 既存のアプリケーション コードとユーザー操作を維持します。
  • ハードウェアのメンテナンスと施設のコストを削減します。
  • 迅速な ROI を実現します。

このソリューションを実装する利点は次のとおりです。

  • 他の手法と比較して、Azure への迅速な移行。
  • ハードウェアのメンテナンスと施設のコストの排除。
  • ユーザーとプログラマの再トレーニングに関連するコストはかからなくなります。
  • 既存のアプリケーション コードへの投資の保持。
  • MCP 環境内または Azure 内のアプリケーションをさらに最新化する可能性があります。

潜在的なユース ケース

  • 既存の Unisys CPF Libra ワークロードを Azure に迅速かつ低リスクで移行します。
  • Azure Arc を使用して、Azure が既存のオンプレミス ワークロードの DR 環境になるようにします。
  • 既存のクライアント機能に Azure データ サービスを追加します。
  • コーディング、アプリケーション テスト、トレーニングの目的で、追加の開発環境とテスト環境を確立します。

考慮 事項

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

確実

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性設計レビューチェックリスト」を参照してください。

Azure の Unisys CPF は、Site Recovery を使用してシステムの可用性と一貫性を確保します。 Site Recovery は、バックアップ システムまたは DR 目的のベースラインを確立します。 Site Recovery ベースラインは、環境の完全に機能する状態を示す DR システムのブループリントと考えることができます。 Site Recovery を使用すると、プライマリ リージョンの障害が発生した場合に DR の Azure リージョン間フェールオーバーが有効になります。 DR 機能は、Azure VM をセカンダリ Azure リージョンにミラーリングします。 これらの機能により、Azure データセンターの障害が発生した場合の迅速なフェールオーバーが保証されます。

安全

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

Unisys CPF は本質的に安全性の高いシステムです。 保存データの暗号化による Azure セキュリティ対策の付加価値により、エンタープライズ ソリューションのセキュリティが向上します。

コストの最適化

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

Azure の Unisys CPF を使用すると、ハードウェアのメンテナンスと先行施設のコストを削減できます。 システムを運用または使用するためにスタッフを再トレーニングする必要がないようにすることで、さらに節約できます。 仮想化されたコンピューターは、データセンターのフロアとまったく同じように実行されます。

また、最初に VM の容量を適切にサイズ設定し、必要に応じてサイズを変更するプロセスに従って、コストを最適化することもできます。 詳細については、Well-Architected フレームワークの コスト最適化設計原則を参照してください。

Azure 製品の構成とコストの見積もりにはAzure 料金計算ツールを使用してください。 VM は MCP に使用されます。 サポート VM は、印刷またはテープに使用されます。 ストレージ アカウントの種類は、パフォーマンスのニーズとデータ保持ポリシーに応じて、Premium SSD ストレージから Standard BLOB ストレージまでさまざまです。

Unisys CPF のオファリングと価格の詳細については、 Unisys CPF ソリューション カタログを参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「オペレーショナル エクセレンス設計レビュー チェックリスト」を参照してください。

Unisys は、Dr フェールオーバーを提供する Site Recovery などの新機能を導入しながら、スタッフに既知の環境を提示することで、オペレーショナル エクセレンスを実証します。

Azure Resource Manager テンプレートを使用してソリューションをデプロイし、Azure Monitor を使用してパフォーマンスを測定および改善することで、運用効率を最適化できます。 詳細については、「 DevOps アーキテクチャの設計DevOps の監視」を参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率設計レビュー チェックリスト」を参照してください。

Unisys は、Azure の運用パフォーマンスと Gold、Platinum、および Titanium のオファリングを照合して、クライアントのワークロードを運用上のニーズに合わせます。 Azure 上の Unisys 仮想化は、Azure Monitor と パフォーマンス診断を通じてパフォーマンス効率を向上させます。 これらのツールを使用すると、リアルタイムの最適化と予防的な問題解決が可能になり、ワークロード管理が向上します。

貢献

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

プリンシパルの作成者:

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

次の手順

詳細については、次のリソースを参照してください。