メインフレーム アプリケーションの移行Mainframe application migration

アプリケーションをメインフレーム環境から Azure に移行する場合、ほとんどのチームは実際的なアプローチに従います。つまり、いつでもどこでも可能なかぎり再利用し、アプリケーションを再作成または置換するときは段階的デプロイを開始します。When migrating applications from mainframe environments to Azure, most teams follow a pragmatic approach: reuse wherever and whenever possible, and then start a phased deployment where applications are rewritten or replaced.

アプリケーションの移行には、通常、次の方法の 1 つ以上が含まれます。Application migration typically involves one or more of the following strategies:

  • 再ホスト: メインフレームから既存のコード、プログラム、およびアプリケーションを移動し、コードを再コンパイルして、クラウド インスタンスでホストされているメインフレーム エミュレーターで実行できます。Rehost: You can move existing code, programs, and applications from the mainframe, and then recompile the code to run in a mainframe emulator hosted in a cloud instance. このアプローチは、一般に、クラウドベースのエミュレーターへのアプリケーションの移動で開始し、その後でクラウドベースのデータベースにデータベースを移行します。This approach typically starts with moving applications to a cloud-based emulator, and then migrating the database to a cloud-based database. データとファイルの変換と共に、ある程度のエンジニアリングとリファクタリングが必要です。Some engineering and refactoring are required along with data and file conversions.

    または、従来のホスティング プロバイダーを使用して再ホストすることができます。Alternatively, you can rehost using a traditional hosting provider. クラウドの主要な利点の 1 つは、インフラストラクチャ管理のアウトソーシングです。One of the principal benefits of the cloud is outsourcing infrastructure management. メインフレームのワークロードを代わりにホストしてくれるデータセンター プロバイダーを見つけることができます。You can find a datacenter provider that will host your mainframe workloads for you. このモデルでは、時間を購入し、ベンダーのロックインを減らし、一時的なコスト削減を実現できます。This model may buy time, reduce vendor lock in, and produce interim cost savings.

  • 廃止: 不要になったすべてのアプリケーションを、移行の前に廃止する必要があります。Retire: All applications that are no longer needed should be retired before migration.

  • 再構築: 最新の手法を使用してプログラムを全面的に書き直す組織もあります。Rebuild: Some organizations choose to completely rewrite programs using modern techniques. このアプローチはコストと複雑さが追加されるため、リフト アンド シフト アプローチほど一般的ではありません。Given the added cost and complexity of this approach, it's not as common as a lift and shift approach. 多くの場合、この種の移行の後では、コード変換エンジンを使用してモジュールとたコードの置き換えを始めるのが理にかなっています。Often after this type of migration, it makes sense to begin replacing modules and code using code transformation engines.

  • 置換: このアプローチでは、メインフレームの機能を、クラウドの同等の機能で置き換えます。Replace: This approach replaces mainframe functionality with equivalent features in the cloud. 1 つのオプションであるサービスとしてのソフトウェア (SaaS) では、財務、人事、製造、エンタープライズ リソース プランニングなど、企業の関心事のために特に作成されたソリューションが使用されます。Software as a service (SaaS) is one option, which is using a solution created specifically for an enterprise concern, such as finance, human resources, manufacturing, or enterprise resource planning. さらに、以前はカスタム メインフレーム ソリューションを使用して解決されていた問題を、今では多くの業界固有アプリを使用して解決できるようになっています。In addition, many industry-specific apps are now available to solve problems that custom mainframe solutions used to previously solve.

最初に移行する必要があるワークロードを計画した後、、関連するアプリケーション、レガシ コード ベース、データベースを移動するための要件を決定することを、検討する必要があります。You should consider starting by planning those workloads that you want to initially migrate, and then determine those requirements for moving associated applications, legacy code bases, and databases.

Azure でのメインフレームのエミュレーションMainframe emulation in Azure

Azure クラウド サービスでは従来のメインフレーム環境をエミュレートでき、メインフレームの既存のコードとアプリケーションを再利用できます。Azure cloud services can emulate traditional mainframe environments, enabling you to reuse existing mainframe code and applications. エミュレートできる一般的なサーバー コンポーネントとしては、オンライン トランザクション処理 (OLTP) システム、バッチ システム、データ インジェスト システムなどがあります。Common server components that you can emulate include online transaction processing (OLTP), batch, and data ingestion systems.

OLTP システムOLTP systems

多くのメインフレームには、膨大なユーザーのために何千または何百万もの更新を処理する OLTP システムがあります。Many mainframes have OLTP systems that process thousands or millions of updates for huge numbers of users. 多くの場合、これらのアプリケーションでは、顧客情報管理システム (CICS)、情報管理システム (IMS)、ターミナル インターフェイス プロセッサ (TIP) など、トランザクション処理と画面フォーム処理のソフトウェアが使用されます。These applications often use transaction processing and screen-form handling software, such as customer information control system (CICS), information management systems (IMS), and terminal interface processor (TIP).

OLTP アプリケーションを Azure に移動するときは、メインフレームのトランザクション処理 (TP) モニター用のエミュレーターを、Azure 上の仮想マシン (VM) を使用し、サービスとしてのインフラストラクチャ (IaaS) として実行できます。When moving OLTP applications to Azure, emulators for mainframe transaction processing (TP) monitors are available to run as infrastructure as a service (IaaS) using virtual machines (VMs) on Azure. 画面処理とフォームの機能も、Web サーバーで実装できます。The screen handling and form functionality can also be implemented by web servers. このアプローチは、データ アクセスとトランザクションのための ActiveX データ オブジェクト (ADO)、Open Database Connectivity (ODBC)、Java Database Connectivity (JDBC) などのデータベース API と組み合わせることができます。This approach can be combined with database APIs, such as ActiveX data objects (ADO), open database connectivity (ODBC), and Java database connectivity (JDBC) for data access and transactions.

時間の制約があるバッチ更新Time-constrained batch updates

銀行、保険、政府で使用されているものなどの多くのメインフレーム システムでは、数百万のアカウント レコードの更新が毎月または毎年実行されます。Many mainframe systems perform monthly or annual updates of millions of account records, such as those used in banking, insurance, and government. メインフレームでは、高スループットのデータ処理システムを提供することで、この種のワークロードが処理されます。Mainframes handle these types of workloads by offering high-throughput data handling systems. メインフレームのバッチ ジョブは、通常、本質的にシリアルであり、パフォーマンスのためにメインフレーム バックボーンによって提供される IOPS (1 秒あたりの入力/出力操作数) に依存します。Mainframes batch jobs are typically serial in nature and depend on the input/output operations per second (IOPS) provided by the mainframe backbone for performance.

クラウドベースのバッチ環境では、パフォーマンスのために並列コンピューティングと高速ネットワークが使用されます。Cloud-based batch environments use parallel compute and high-speed networks for performance. バッチ処理のパフォーマンスを最適化する必要がある場合、Azure ではさまざまなコンピューティング、ストレージ、およびネットワークのオプションが提供されています。If you need to optimize batch performance, Azure provides various compute, storage, and networking options.

データ インジェスト システムData ingestion systems

メインフレームでは、小売、金融サービス、製造、その他のソリューションから、処理のためにデータの大きなバッチが取り込まれます。Mainframes ingest large batches of data from retail, financial services, manufacturing, and other solutions for processing. Azure では、AzCopy などの簡単なコマンド ライン ユーティリティを使用して、保存場所との間でデータのコピーを実行できます。With Azure, you can use simple command-line utilities such as AzCopy for copying data to and from storage location. また、Azure Data Factory サービスを使用すると、各種のデータ ストアからデータを取り込み、データ主導型のワークフローを作成してスケジューリングすることもできます。You can also use the Azure Data Factory service, enabling you to ingest data from disparate data stores to create and schedule data-driven workflows.

エミュレーション環境だけでなく、Azure では、既存のメインフレーム環境を拡張できるサービスとしてのプラットフォーム (PaaS) および分析サービスも提供されています。In addition to emulation environments, Azure provides platform as a service (PaaS) and analytics services that can enhance existing mainframe environments.

OLTP ワークロードを Azure に移行するMigrate OLTP workloads to Azure

リフト アンド シフト アプローチは、既存のアプリケーションを Azure にすばやく移行するためのコード不要のオプションです。The lift and shift approach is the no-code option for quickly migrating existing applications to Azure. 各アプリケーションはそのままの状態で移行されます。このため、コード変更に伴うリスクとコストのどちらも負担することなく、クラウドのメリットを享受できます。Each application is migrated as is, which provides the benefits of the cloud without the risks or costs of making code changes. Azure でのメインフレーム トランザクション処理 (TP) モニター用のエミュレーターの使用では、このアプローチがサポートされています。Using an emulator for mainframe transaction processing (TP) monitors on Azure supports this approach.

さまざまなベンダーの TP モニターを利用でき、Azure 上のサービスとしてのインフラストラクチャ (IaaS) オプションである仮想マシンで実行できます。TP monitors are available from various vendors and run on virtual machines, an infrastructure as a service (IaaS) option on Azure. 次の図は、IBM の z/OS メインフレーム上のリレーショナル データベース管理システム (DBMS) である IBM DB2 を利用するオンライン アプリケーションを移行する前と後を示したものです。The following before and after diagrams show a migration of an online application backed by IBM DB2, a relational database management system (DBMS), on an IBM z/OS mainframe. DB2 for Z/OS では、データの格納用には VSAM (Virtual Storage Access Method) ファイルが使用され、フラット ファイル用には ISAM (Indexed Sequential Access Method: 索引順次アクセス方式) が使用されます。DB2 for z/OS uses virtual storage access method (VSAM) files to store the data and Indexed Sequential Access Method (ISAM) for flat files. このアーキテクチャでは、トランザクション監視用に CICS も使用されます。This architecture also uses CICS for transaction monitoring.

エミュレーション ソフトウェアを使用した Azure へのメインフレーム環境の "リフト アンド シフト" 移行

Azure では、TP マネージャーと JCL を用いたバッチ ジョブを実行するために、エミュレーション環境が使用されています。On Azure, emulation environments are used to run the TP manager and the batch jobs that use JCL. データ層では、DB2 が Azure SQL Database に置き換えられていますが、Microsoft SQL Server、DB2 LUW、または Oracle Database を使用することもできます。In the data tier, DB2 is replaced by Azure SQL Database, although Microsoft SQL Server, DB2 LUW, or Oracle Database can also be used. エミュレーターでは、IMS、VSAM、および SEQ がサポートされています。An emulator supports IMS, VSAM, and SEQ. メインフレームのシステム管理ツールは、VM 上で実行される Azure サービスおよび他のベンダーのソフトウェアによって置き換えられています。The mainframe's system management tools are replaced by Azure services, and software from other vendors, that run in VMs.

画面処理とフォーム入力の機能は一般に Web サーバーを使用して実装され、データ アクセスおよびトランザクションには ADO、ODBC、JDBC などのデータベース API と組み合わせることができます。The screen handling and form entry functionality is commonly implemented using web servers, which can be combined with database APIs, such as ADO, ODBC, and JDBC for data access and transactions. 使用する Azure IaaS コンポーネントの正確なラインナップは、選択するオペレーティング システムによって異なります。The exact line-up of Azure IaaS components to use depends on the operating system you prefer. 次に例を示します。For example:

  • Windows ベースの VM の場合:画面処理とビジネス ロジック用にはインターネット インフォメーション サービス (IIS) と ASP.NET。Windows–based VMs: Internet Information Server (IIS) along with ASP.NET for the screen handling and business logic. データ アクセスとトランザクションには ADO.NET を使用します。Use ADO.NET for data access and transactions.

  • Linux ベースの VM の場合:使用可能な Java ベースのアプリケーション サーバー。たとえば、画面処理と Java ベースのビジネス機能用の Apache Tomcat など。Linux–based VMs: The Java-based application servers that are available, such as Apache Tomcat for screen handling and Java-based business functionality. データ アクセスとトランザクションには JDBC を使用します。Use JDBC for data access and transactions.

バッチ ワークロードを Azure に移行するMigrate batch workloads to Azure

Azure でのバッチ操作は、メインフレーム上の一般的なバッチ環境とは異なります。Batch operations in Azure differ from the typical batch environment on mainframes. メインフレームのバッチ ジョブは、通常、本質的にシリアルであり、パフォーマンスのためにメインフレーム バックボーンによって提供される IOPS に依存します。Mainframe batch jobs are typically serial in nature and depend on the IOPS provided by the mainframe backbone for performance. クラウドベースのバッチ環境では、パフォーマンスのために並列コンピューティングと高速ネットワークが使用されます。Cloud-based batch environments use parallel computing and high-speed networks for performance.

Azure を使用するバッチ処理のパフォーマンスを最適化するには、次のようなコンピューティングストレージネットワーク、および監視のオプションを検討します。To optimize batch performance using Azure, consider the compute, storage, networking, and monitoring options as follows.

ComputeCompute

次のコマンドを使用します。Use:

  • クロック速度が最高の VM。VMs with the highest clock speed. 多くの場合、メインフレームのアプリケーションはシングル スレッドであり、メインフレームの CPU は非常に高いクロック速度です。Mainframe applications are often single-threaded and mainframe CPUs have a very high clock speed.

  • データのキャッシュとアプリケーションの作業領域に対応する大容量のメモリを備えた VM。VMs with large memory capacity to allow caching of data and application work areas.

  • アプリケーションが複数のスレッドをサポートしている場合は、マルチスレッド処理を利用するために高密度 vCPU を備えた VM。VMs with higher density vCPUs to take advantage of multithreaded processing if the application supports multiple threads.

  • 並列処理。Azure は並列処理用に簡単にスケールアウトし、より多くのコンピューティング能力をバッチ実行に提供します。Parallel processing, as Azure easily scales out for parallel processing, delivering more compute power for a batch run.

ストレージStorage

次のコマンドを使用します。Use:

  • 使用可能な最大の IOPS のために Azure Premium SSD または Azure Ultra SSDAzure premium SSD or Azure ultra SSD for maximum available IOPS.

  • ストレージ サイズあたりの IOPS を上げるために複数のディスクによるストライピング。Striping with multiple disks for more IOPS per storage size.

  • 複数の Azure ストレージ デバイスに IO を分散させるためのストレージのパーティション分割。Partitioning for storage to spread IO over multiple Azure storage devices.

ネットワークNetworking

監視Monitoring

  • 監視ツール、Azure MonitorApplication Insights、および Azure ログを使用すると、管理者はバッチ実行の過剰なパフォーマンスを監視し、ボトルネックを回避することができます。Use monitoring tools, Azure Monitor, Application Insights, and Azure logs enable administrators to monitor any over performance of batch runs and help eliminate bottlenecks.

開発環境を移行するMigrate development environments

クラウドの分散アーキテクチャは、最新の手法とプログラミング言語のメリットを提供するさまざまな開発ツールのセットに依存します。The cloud's distributed architectures rely on a different set of development tools that provide the advantage of modern practices and programming languages. この移行を容易にするには、IBM z/OS 環境をエミュレートするように設計された他のツールで開発環境を使用することができます。To ease this transition, you can use a development environment with other tools that are designed to emulate IBM z/OS environments. 次に、Microsoft と他のベンダーが提供するオプションの一覧を示します。The following list shows options from Microsoft and other vendors:

コンポーネントComponent Azure のオプションAzure Options
z/OSz/OS Windows、Linux、UNIXWindows, Linux, or UNIX
CICSCICS Micro Focus、Oracle、GT Software (Fujitsu)、TmaxSoft、Raincode、NTT Data によって提供される Azure サービス、または Kubernetes を使用した書き換えAzure services offered by Micro Focus, Oracle, GT Software (Fujitsu), TmaxSoft, Raincode, and NTT Data, or rewrite using Kubernetes
IMSIMS Micro Focus と Oracle によって提供される Azure サービスAzure services offered by Micro Focus and Oracle
アセンブラーAssembler Raincode と TmaxSoft からの Azure サービス、COBOL、C、Java、またはオペレーティング システムの機能へのマップAzure services from Raincode and TmaxSoft; or COBOL, C, or Java, or map to operating system functions
JCLJCL JCL、PowerShell、または他のスクリプト ツールJCL, PowerShell, or other scripting tools
COBOLCOBOL COBOL、C、または JavaCOBOL, C, or Java
NaturalNatural Natural、COBOL、C、または JavaNatural, COBOL, C, or Java
FORTRAN と PL/IFORTRAN and PL/I FORTRAN、PL/I、COBOL、C、また JavaFORTRAN, PL/I, COBOL, C, or Java
REXX と PL/IREXX and PL/I REXX、PowerShell、または他のスクリプト ツールREXX, PowerShell, or other scripting tools

データベースとデータを移行するMigrate databases and data

アプリケーションの移行には、通常、データ層の再ホストが伴います。Application migration usually involves rehosting the data tier. Azure Database Migration Service を使用すると、Azure SQL Managed InstanceAzure Database for PostgreSQLAzure Database for MySQL などの Azure 上のフルマネージド ソリューションに、SQL Server、オープンソース、その他のリレーショナル データベースを移行できます。You can migrate SQL Server, open-source, and other relational databases to fully managed solutions on Azure, such as Azure SQL Managed Instance, Azure Database for PostgreSQL, and Azure Database for MySQL with Azure Database Migration Service.

たとえば、メインフレームのデータ層で次のものが使用されている場合に移行できます。For example, you can migrate if the mainframe data tier uses:

  • IBM DB2 または IMS データベース。Azure で Azure SQL Database、SQL Server、DB2 LUW、または Oracle Database を使用します。IBM DB2 or an IMS database, use Azure SQL database, SQL Server, DB2 LUW, or Oracle Database on Azure.

  • VSAM および他のフラット ファイル。Azure SQL、SQL Server、DB2 LUW、または Oracle で ISAM (Indexed Sequential Access Method: 索引順次アクセス方式) を使用します。VSAM and other flat files, use Indexed Sequential Access Method (ISAM) flat files for Azure SQL, SQL Server, DB2 LUW, or Oracle.

  • Generation Data Group (GDG)。Azure では、同様の機能を GDG に提供する名前付け規則とファイル名拡張子を使用するファイルに移行します。Generation Date Groups (GDGs), migrate to files on Azure that use a naming convention and filename extensions that provide similar functionality to GDGs.

IBM のデータ層には、やはり移行する必要がある複数の主要なコンポーネントが含まれます。The IBM data tier includes several key components that you must also migrate. たとえば、データベースを移行するときは、z/OS VSAM データ セットである dbextent をそれぞれが含む、プールに含まれるデータのコレクションも移行します。For example, when you migrate a database, you also migrate a collection of data contained in pools, each containing dbextents, which are z/OS VSAM data sets. 移行には、ストレージ プール内のデータの場所を示すディレクトリが含まれる必要があります。Your migration must include the directory that identifies data locations in the storage pools. また、移行計画では、データベースで実行された操作の記録を含むデータベース ログを考慮する必要があります。Also, your migration plan must consider the database log, which contains a record of operations performed on the database. データベースには、1 つ、2 つ (デュアルまたは代替)、または 4 つ (デュアルおよび代替) のログが含まれる場合があります。A database can have one, two (dual or alternate), or four (dual and alternate) logs.

データベースの移行には、以下のコンポーネントも含まれます。Database migration also includes these components:

  • データベース マネージャー: データベース内のデータへのアクセスを提供します。Database manager: Provides access to data in the database. データベース マネージャーは、z/OS 環境内の専用のパーティションで実行されます。The database manager runs in its own partition in a z/OS environment.
  • アプリケーション リクエスター: アプリケーション サーバーに渡す前に、アプリケーションから要求を受け入れます。Application requester: Accepts requests from applications before passing them to an application server.
  • オンライン リソース アダプター: CICS トランザクションで使用するアプリケーション リクエスター コンポーネントが含まれます。Online resource adapter: Includes application requester components for use in CICS transactions.
  • バッチ リソース アダプター: z/OS バッチ アプリケーション用のアプリケーション リクエスター コンポーネントを実装します。Batch resource adapter: Implements application requester components for z/OS batch applications.
  • 対話式 SQL (ISQL): CICS アプリケーションおよびインターフェイスとして実行され、ユーザーが SQL ステートメントまたはオペレーター コマンドを入力できるようにします。Interactive SQL (ISQL): Runs as a CICS application and interface enabling users to enter SQL statements or operator commands.
  • 対話式 SQL (ISQL): CICS の制御下で実行され、CICS で使用可能なリソースとデータ ソースを使用します。CICS application: Runs under the control of CICS, using available resources and data sources in CICS.
  • バッチ アプリケーション: ユーザーとの対話型通信を行わずにプロセスのロジックを実行します。たとえば、一括データ更新プログラムを作成したり、データベースからレポートを生成したりします。Batch application: Runs process logic without interactive communication with users to, for example, produce bulk data updates or generate reports from a database.

Azure のスケールとスループットを最適化するOptimize scale and throughput for Azure

一般に、メインフレームはスケールアップし、クラウドはスケールアウトします。Azure で実行されるメインフレーム スタイルのアプリケーションのスケールとスループットを最適化するには、メインフレームでアプリケーションが分割および分離される方法を理解することが重要です。Generally speaking, mainframes scale up, while the cloud scales out. To optimize scale and throughput of mainframe-style applications running on Azure, it is important that you understand at how mainframes can separate and isolate applications. z/OS メインフレームでは、1 つのインスタンス上で特定のアプリケーションに対するリソースを分離して管理するために、論理パーティション (LPAR) と呼ばれる機能が使用されます。A z/OS mainframe uses a feature called Logical Partitions (LPARS) to isolate and manage the resources for a specific application on a single instance.

たとえば、メインフレームでは CICS 領域と関連する COBOL プログラム用に 1 つの論理パーティション (LPAR)、DB2 用に別の LPAR が使用される場合があります。For example, a mainframe might use one logical partition (LPAR) for a CICS region with associated COBOL programs, and a separate LPAR for DB2. 開発、テスト、およびステージング環境用に追加の LPAR が使用されることがよくあります。Additional LPARs are often used for the development, testing, and staging environments.

Azure では、この目的に別の VM を使用することの方が一般的です。On Azure, it's more common to use separate VMs to serve this purpose. 通常、Azure のアーキテクチャでは、アプリケーション層、データ層、開発用などにそれぞれ異なる VM のセットがデプロイされます。Azure architectures typically deploy VMs for the application tier, a separate set of VMs for the data tier, another set for development, and so on. 処理の各階層は、その環境に最も適した種類の VM と機能を使用して最適化できます。Each tier of processing can be optimized using the most suitable type of VMs and features for that environment.

さらに、各階層で適切なディザスター リカバリー サービスを提供することもできます。In addition, each tier can also provide appropriate disaster recovery services. たとえば、運用およびデータベース用の VM ではホットまたはウォーム リカバリーが必要であり、開発およびテスト用の VM ではコールド リカバリーをサポートするようなことがあります。For example, production and database VMs might require a hot or warm recovery, while the development and testing VMs support a cold recovery.

次の図では、プライマリ サイトとセカンダリ サイトを使用して可能な Azure のデプロイを示します。The following figure shows a possible Azure deployment using a primary and a secondary site. プライマリ サイトには、運用、ステージング、およびテスト用の VM が高可用性でデプロイされます。In the primary site, the production, staging, and testing VMs are deployed with high availability. セカンダリ サイトは、バックアップおよびディザスター リカバリー用です。The secondary site is for backup and disaster recovery.

プライマリ サイトとセカンダリ サイトを使用して可能な Azure のデプロイ

メインフレームから Azure への段階的移行を実行するPerform a staged mainframe to Azure

メインフレームから Azure へのソリューションの移動では、"段階的な" 移行が必要な場合があります。つまり、一部のアプリケーションが最初に移動され、他のアプリケーションは一時的または永続的にメインフレームに残されます。Moving solutions from a mainframe to Azure may involve a staged migration, whereby some applications are moved first, and others remain on the mainframe temporarily or permanently. 通常、このアプローチには、メインフレームと Azure の間でアプリケーションとデータベースが相互運用できるシステムが必要です。This approach typically requires systems that allow applications and databases to interoperate between the mainframe and Azure.

一般的なシナリオでは、アプリケーションを Azure に移動し、アプリケーションによって使用されるデータはメインフレームで維持します。A common scenario is to move an application to Azure while keeping the data used by the application on the mainframe. Azure 上のアプリケーションがメインフレーム上のデータにアクセスできるようにするには、特定のソフトウェアが使用されます。Specific software is used to enable the applications on Azure to access data from the mainframe. さいわい、広範なソリューションでは、Azure と既存のメインフレーム環境間の統合、ハイブリッド シナリオのサポート、および時間をかけた移行が提供されています。Fortunately, a wide range of solutions provide integration between Azure and existing mainframe environments, support for hybrid scenarios, and migration over time. Microsoft パートナー、独立系ソフトウェア ベンダー、およびシステム インテグレーターがユーザーの作業を支援できます。Microsoft partners, independent software vendors, and system integrators can help you on your journey.

1 つのオプションとして Microsoft Host Integration Server があります。これは、メインフレームに残っている DB2 のデータにアクセスするために Azure のアプリケーションに必要な分散リレーショナル データベース アーキテクチャ (DRDA) を提供するソリューションです。One option is Microsoft Host Integration Server, a solution that provides the distributed relational database architecture (DRDA) required for applications in Azure to access data in DB2 that remains on the mainframe. メインフレームと Azure の統合に対する他のオプションとしては、IBM、Attunity、Codit、他のベンダーからのソリューション、およびオープン ソースのオプションがあります。Other options for mainframe-to-Azure integration include solutions from IBM, Attunity, Codit, other vendors, and open source options.

パートナー ソリューションPartner solutions

メインフレームの移行を検討している場合は、パートナー エコシステムが役に立ちます。If you are considering a mainframe migration, the partner ecosystem is available to assist you.

Azure では、メインフレームで現在実行されているシステムに対し、実績があり高可用性でスケーラブルなインフラストラクチャが提供されます。Azure provides a proven, highly available, and scalable infrastructure for systems that currently run on mainframes. 一部のワークロードは、比較的簡単に移行できます。Some workloads can be migrated with relative ease. CICS や IMS のように従来のシステム ソフトウェアに依存する他のワークロードは、パートナー ソリューションを使用して再ホストし、時間をかけて Azure に移行することができます。Other workloads that depend on legacy system software, such as CICS and IMS, can be rehosted using partner solutions and migrated to Azure over time. 何を選択しても、Microsoft とそのパートナーが、メインフレーム システムのソフトウェアの機能を維持しながら、Azure に対する最適化を支援します。Regardless of the choice you make, Microsoft and our partners are available to assist you in optimizing for Azure while maintaining mainframe system software functionality.

詳細情報Learn more

詳細については、次のリソースを参照してください。For more information, see the following resources: