メインフレームから Azure に切り替えるMake the switch from mainframes to Azure

Azure は、従来のメインフレーム アプリケーションを実行するための代替プラットフォームとして、高可用環境にハイパースケールのコンピューティングとストレージを提供します。As an alternative platform for running traditional mainframe applications, Azure offers hyperscale compute and storage in a high availability environment. メインフレーム環境に関連するコストをかけずに、最新のクラウドベースのプラットフォームの価値と敏捷性が手に入ります。You get the value and agility of a modern, cloud-based platform without the costs associated with a mainframe environment.

このセクションでは、メインフレーム プラットフォームから Azure への切り替えに関する技術的なガイダンスを提供します。This section provides technical guidance for making the switch from a mainframe platform to Azure.

メインフレームと Azure

MIPS と vCPUMIPS vs. vCPUs

メインフレームのワークロードを実行するために必要な仮想中央処理装置 (vCPU) の数を決定するための汎用のマッピング式はありません。There is no universal mapping formula that exists for determining the number of virtual central processing units (vCPUs) needed to run mainframe workloads. ただし、100万命令毎秒 (MIPS) のメトリックは、多くの場合、Azure 上の vCPU にマップされます。However, the metric of a million instructions per second (MIPS) is often mapped to vCPUs on Azure. MIPS では、特定のマシンの 1 秒あたりのサイクル数を一定の値にすることで、メインフレームの全体的なコンピューティング能力を測定します。MIPS measures the overall compute power of a mainframe by providing a constant value of the number of cycles per second for a given machine.

小規模な組織では 500 MIPS 未満で済みますが、大規模な組織は通常 5,000 MIPS を超えます。A small organization might require less than 500 MIPS, while a large organization typically uses more than 5,000 MIPS. 1 MIPS あたり 1,000 ドルの場合、大規模な組織では 5,000 MIPS のインフラストラクチャをデプロイするために年間約 500 万ドルを費やします。At $1,000 per single MIPS, a large organization spends approximately $5 million annually to deploy a 5,000-MIPS infrastructure. この規模の一般的な Azure デプロイの年間コスト見積もりは、MIPS インフラストラクチャのコストの約 1/10 です。The annual cost estimate for a typical Azure deployment of this scale is approximately one-tenth the cost of a MIPS infrastructure. 詳細については、ホワイト ペーパー「Demystifying Mainframe-to-Azure Migration (メインフレームから Azure への移行の解明)」の表 4 を参照してください。For details, see Table 4 in the Demystifying Mainframe-to-Azure Migration white paper.

Azure による vCPU への MIPS の正確な計算は、vCPU の種類と実行している正確なワークロードによって変わります。An accurate calculation of MIPS to vCPUs with Azure depends on the type of vCPU and the exact workload you are running. ただし、ベンチマーク調査は、必要となる vCPU の数と種類を見積もるための優れた基盤となります。However, benchmark studies provide a good basis for estimating the number and type of vCPUs you will need. 最近の HPE zREF ベンチマークは、以下の見積もりを提供しています。A recent HPE zREF benchmark provides the following estimates:

  • オンライン (CICS) ジョブの場合、HP Proliant サーバー上で実行される Intel ベース コアあたり 288 MIPS。288 MIPS per Intel-based core running on HP Proliant servers for online (CICS) jobs.

  • COBOL バッチ ジョブの場合、Intel コアあたり 170 MIPS。170 MIPS per Intel core for COBOL batch jobs.

このガイドでは、オンライン処理の場合は vCPU あたり 200 MIPS、バッチ処理の場合は vCPU あたり 100 MIPS と見積もります。This guide estimates 200 MIPS per vCPU for online processing and 100 MIPS per vCPU for batch processing.

注意

このような見積もりは、新しい仮想マシン (VM) シリーズが Azure で使用できるようになると変わる可能性があります。These estimates are subject to change as new virtual machine (VM) series become available in Azure.

高可用性とフェールオーバーHigh availability and failover

メインフレーム システムでは、メインフレームの結合と Parallel Sysplex を使用する場合、ファイブ ナインの可用性 (99.999%) が提供されることがよくあります。Mainframe systems often offer five 9s availability (99.999 percent) when mainframe coupling and Parallel Sysplex are used. それでも、システム運用者は、保守と初期プログラム読み込み (IPL) のためのダウンタイムをスケジュールする必要があります。Yet system operators still need to schedule downtime for maintenance and initial program loads (IPLs). 実際の可用性は、ハイエンドの Intel ベースのサーバーに匹敵するツー ナインまたはスリー ナインに近づきます。The actual availability approaches two or three 9s, comparable to high end, Intel-based servers.

対照的に、Azure はコミットメントベースのサービス レベル アグリーメント (SLA) を提供します。この場合、複数ナインの可用性が既定であり、ローカルまたは地域ベースのサービスのレプリケーションに最適化されています。By comparison, Azure offers commitment-based service level agreements (SLAs), where multiple 9s availability is the default, optimized with local or geo-based replication of services.

Azure は、ローカルでも他の地域内でも、複数のストレージ デバイスからデータをレプリケートすることで可用性を向上します。Azure provides additional availability by replicating data from multiple storage devices, either locally or in other geographic regions. Azure ベースの障害が発生した場合、コンピューティング リソースはローカルまたはリージョン レベルでレプリケートされたデータにアクセスできます。In the event of an Azure-based failure, compute resources can access the replicated data on either the local or regional level.

Azure SQL DatabaseAzure Cosmos Database などの Azure のサービスとしてのプラットフォーム (PaaS) リソースを使用すると、Azure で自動的にフェールオーバーを処理できます。When you use Azure platform as a service (PaaS) resources, such as Azure SQL Database and Azure Cosmos Database, Azure can automatically handle failovers. Azure サービスとしてのインフラストラクチャ (IaaS) を使用する場合、フェールオーバーは、SQL Server の Always On 機能、フェールオーバー クラスタリング インスタンス、可用性グループなどの特定のシステム機能に依存します。When you use Azure infrastructure as a service (IaaS), failover relies on specific system functionality, such as SQL Server Always On features, failover clustering instances, and availability groups.

スケーラビリティScalability

メインフレームは通常スケールアップしますが、クラウド環境はスケールアウトします。メインフレームは結合機能 (CF) を使用してスケールアウトできますが、ハードウェアとストレージのコストが高いため、メインフレームのスケールアウトは高価です。Mainframes typically scale up, while cloud environments scale out. Mainframes can scale out with the use of a coupling facility (CF), but the high cost of hardware and storage makes mainframes expensive to scale out.

さらに、CF は密結合コンピューティングを提供しますが、Azure のスケールアウト機能は疎結合です。A CF also offers tightly coupled compute, whereas the scale-out features of Azure are loosely coupled. クラウドは、使用量ベースの課金モデルでは、オンデマンドのコンピューティング能力、ストレージ、およびサービスのスケールによって、正確なユーザー仕様に合わせてスケールアップまたはスケールダウンできます。The cloud can scale up or down to match exact user specifications, with compute power, storage, and services scaling on demand under a usage-based billing model.

バックアップと回復Backup and recovery

一般的に、メインフレームのお客様は、災害時に備えてディザスター リカバリー サイトを保守するか、独立したメインフレーム プロバイダーを利用しています。Mainframe customers typically maintain disaster recovery sites or make use or an independent mainframe provider for disaster contingencies. ディザスター リカバリー サイトとの同期は、通常、データのオフライン コピーを使用して実行されます。Synchronization with a disaster recovery site is usually done through offline copies of data. どちらの方法も高コストが発生します。Both options incur high costs.

自動化された geo 冗長性は、メインフレームの結合機能を介しても利用できます。Automated geo-redundancy is also available through the mainframe coupling facility. この方法はコストが高く、通常、ミッション クリティカルなシステム用に予約されています。This approach is expensive and is typically reserved for mission-critical systems. 対照的に、Azure には、実装が簡単で費用対効果の高いバックアップ復旧、および冗長性のオプションがあり、ローカル レベルまたはリージョン レベルで、または geo 冗長性を介して利用できます。In contrast, Azure has easy-to-implement and cost-effective options for backup, recovery, and redundancy at local or regional levels, or via geo-redundancy.

ストレージStorage

メインフレームのしくみを理解するには、さまざまな重複する用語を解読することも必要です。Part of understanding how mainframes work involves decoding various overlapping terms. たとえば、一般的に、中央ストレージ、物理メモリ、物理ストレージ、およびメイン ストレージは、すべてメインフレーム プロセッサに直接接続されているストレージを指します。For example, central storage, real memory, real storage, and main storage all generally refer to storage attached directly to the mainframe processor.

メインフレーム ハードウェアには、プロセッサや他の多くのデバイスが含まれます。たとえば、ダイレクト アクセス ストレージ デバイス (DASD)、磁気テープ ドライブ、一部のユーザー コンソールなどです。Mainframe hardware includes processors and many other devices, such as direct-access storage devices (DASDs), magnetic tape drives, and several types of user consoles. テープと DASD は、システム関数のためにユーザー プログラムによって使用されます。Tapes and DASDs are used for system functions and by user programs.

メインフレーム用の物理ストレージには、次のような種類があります。Types of physical storage for mainframes include:

  • 中央ストレージ: メインフレーム プロセッサ上に直接配置され、これはプロセッサまたは物理ストレージとも呼ばれます。Central storage: Located directly on the mainframe processor, this is also known as processor or real storage.
  • 補助ストレージ: メインフレームとは別に配置されます。この種類には、DASD 上のストレージが含まれ、ページング ストレージとも呼ばれます。Auxiliary storage: Located separately from the mainframe, this type includes storage on DASDs and is also known as paging storage.

クラウドには、柔軟でスケーラブルなオプションが幅広く用意されており、必要なオプションに対してのみ料金を支払います。The cloud offers a range of flexible, scalable options, and you will pay only for those options that you need. Azure Storage は、データ オブジェクトのための高度にスケーラブルなオブジェクト ストア、クラウドのためのファイル システム サービス、信頼性の高いメッセージング ストア、および NoSQL ストアを提供します。Azure Storage offers a massively scalable object store for data objects, a file system service for the cloud, a reliable messaging store, and a NoSQL store. VM の場合、マネージド ディスクとアンマネージド ディスクは、永続的でセキュリティで保護されたディスク ストレージを提供します。For VMs, managed and unmanaged disks provide persistent, secure disk storage.

メインフレームの開発とテストMainframe development and testing

メインフレーム移行プロジェクトの主なけん引役は、アプリケーション開発の変化する面です。A major driver in mainframe migration projects is the changing face of application development. 組織は、ビジネス ニーズに対する開発環境の俊敏性と応答性を高める必要があります。Organizations want their development environment to be more agile and responsive to business needs.

一般的に、メインフレームには、QA やステージング LPAR など、開発用とテスト用に別の論理パーティション (LPAR) があります。Mainframes typically have separate logical partitions (LPARs) for development and testing, such as QA and staging LPARs. メインフレーム開発ソリューションには、コンパイラ (COBOL、PL/I、アセンブラー) とエディターが含まれます。Mainframe development solutions include compilers (COBOL, PL/I, Assembler) and editors. 最も一般的なものは、IBM メインフレーム上で稼働する z/OS オペレーティング システム用の対話式システム生産性向上機能 (ISPF) です。The most common is the Interactive System Productivity Facility (ISPF) for the z/OS operating system that runs on IBM mainframes. その他には、ROSCOE Programming Facility (RPF) や、CA Librarian や CA-Panvalet などの Computer Associates ツールがあります。Others include ROSCOE Programming Facility (RPF) and Computer Associates tools, such as CA Librarian and CA-Panvalet.

エミュレーション環境とコンパイラは x86 プラットフォーム上で使用できるので、一般的に開発とテストはメインフレームから Azure に移行する最初のワークロードになる可能性があります。Emulation environments and compilers are available on x86 platforms, so development and testing can typically be among the first workloads to migrate from a mainframe to Azure. Azure の DevOps ツールの可用性と普及により、開発環境とテスト環境の移行が加速しています。The availability and widespread use of DevOps tools in Azure is accelerating the migration of development and testing environments.

ソリューションを Azure 上で開発およびテストし、メインフレームへの展開の準備が整ったら、コードをメインフレームにコピーしてそこでコンパイルする必要があります。When solutions are developed and tested on Azure and are ready for deployment to the mainframe, you will need to copy the code to the mainframe and compile it there.

次のステップNext steps