グリーン IT を促進する ― アプリケーションのマイグレーションおよびリホストの実用ガイド

IBM Project Big Green チームがアプリケーションのマイグレーションを通して学んだ手法、ベスト・プラクティス、教訓を詳しく探る

このガイドは、分散環境からアプリケーションのワークロードを移行した実際の経験を基に作成されています。具体的には、Power、pSeries、または RS/6000 ハードウェア上の AIX ワークロード、Sun ハードウェア上の Solaris ワークロード、あるいは x86 ハードウェア (つまり、IBM eServer から IBM System z までの主に IBM System z9 または z10 モデル) 上の Linux ワークロードなどです。

Joydipto Banerjee, IBM Certified Consulting IT Specialist , IBM  

Joydipto BanerjeeJoydipto Banerjee は、IBM Project Big Green の主任マイグレーション・エンジニアとして、AIX プラットフォームから SUSE Linux on System z メインフレームへのアプリケーションのマイグレーションに従事しました。この分野で 3 年近く分析、評価、移植の実践的経験を積んでいる彼は、IBM アプリケーションのマイグレーションの手法およびフェーズ全体に長けています。


developerWorks 貢献著者レベル

Debasis Choudhuri, IBM Certified Senior Architect, IBM

Photo of Debasis ChoudhuriDebasis Choudhuri は、サーバーの統合およびマイグレーションにおけるインフラストラクチャー分野の専門家です。彼は、インベントリー分析、IT ランドスケープ・アセスメント、アーキテクチャー、ターゲット・ソリューションのサイジングで広範な経験を積んでいます。複数のデータ・センター統合および IT 変換プロジェクトでアーキテクトを務めた経験があります。現在、IBM Big Green の Program Architecture チームのメンバーです。



LK Swift, IBM Senior Certified Architect, IBM

Photo of LK SwiftLK Swift は、IBM でサーバー・マイグレーションおよび統合プログラムの主任アーキテクトを務めています。



2012年 8月 09日

はじめに

大規模なアプリケーションの開発および保守を行う部門の多くは、新しい環境へのコア・アプリケーションおよびデータベースのマイグレーションを検討するなかで、マイグレーションをどこから始めればよいのか、マイグレーションをどのように計画して実施すればよいのか、そしてマイグレーション・プロセスに潜む落とし穴をどのように避ければよいのかがわからず、途方に暮れています。標準的な手法またはガイドラインを把握していない限り、プラットフォーム間でアプリケーションを迅速かつ効果的にマイグレーションするための作業量を推定するのは困難になります。

この記事では、IBM 内部の約 3900 台のサーバーを、Linux をオペレーティング・システムとする約 30 台の System z に統合することを目標に掲げ、大きな成功を収めている IBM Project Big Green について探ります。記事の目的は、このプロジェクトが従った包括的なアプローチを紹介し、ベスト・プラクティスとツールに関する知識を共有し、サーバーを統合して仮想化する際の出発点となる指針を提供することです。

記事では、似たような UNIX プラットフォーム間でのマイグレーションに焦点を絞りますが、ここで説明する内容は他のマイグレーション・シナリオにも同じく役立ちます。この記事の対象読者は、マイグレーション・エンジニア、マイグレーション・アーキテクト、技術チーム・リーダーです。あらゆるマイグレーション・プロジェクトで、すべてのスキル・レベルに共通の参考資料として役立つはずです。


マイグレーション・プロセスの概要

まず、「ワークロード」という用語を理解してください。ワークロードとは、仮想環境または非仮想環境のいずれにおいても、オペレーティング・システム (OS) 上で実行される 1 つのアプリケーションまたは複数のアプリケーションを指します。ワークロードは、ハードウェアで実行される OS、その OS 層で実行されるミドルウェア、そしてそのミドルウェア・システムで実行されるアプリケーション一式 (または似たようなアプリケーションのグループ) で構成されます。データベース・ワークロードの例としては、以下のものが挙げられます。

  • DB2 または Oracle のワークロード
  • Web アプリケーション (Java アプリケーション、WebSphere アプリケーション、Weblogic アプリケーション、その他) のワークロード
  • 静的イメージまたは静的ページとしてのフロントエンド・ワークロード
  • 中間層のアプリケーション (WebSphere MQ、Message Broker、Web サービス、その他) のワークロード

各種 UNIX (AIX、Solaris、x/Linux など) のワークロードを z/Linux (または任意のプラットフォーム) にマイグレーションするのは、技術的には難しいことではありません。この種のマイグレーションが複雑な作業になってしまうのは、アセスメントを行って適切な計画を立てる上での経験が不足しているためです。秩序だったガイドラインと適切なフェーズに分かれた段階的なアプローチによって、変換プロセスは確かなものになります。標準的なマイグレーション・サイクルは、図 1 に示すフェーズで構成されます。

図 1. マイグレーションの概要
発見から、マッピング、プロビジョニング、マイグレーション、構成、テスト、実稼働への段階的進行を示す図

あらゆるマイグレーションの取り組みは、大まかに以下のフェーズに分類することができます。

  • 発見 (Discover) フェーズでは、サーバー・インベントリーおよびアプリケーションの依存関係を調べて明らかにします。
  • マッピング (Map) フェーズでは、マイグレーション要求およびターゲット・トポロジーを作成します。
  • プロビジョニング、マイグレーションおよび構成 (Provision, migrate, and configure) フェーズでは、ターゲット環境を構築し、アプリケーションのデプロイメントおよび移植を行います。
  • テスト (Test) フェーズでは、新しい環境にマイグレーションしたアプリケーションをテストし、実稼働を開始します。

マイグレーション・フェーズの詳細

  1. サーバーの特定とインベントリーの作成
  2. サーバーとアプリケーションの絞り込み
  3. 計画および設計
  4. サーバーとアプリケーションのマイグレーション
  5. 実稼働開始後処理

以下の図 2 に、具体的なサブカテゴリーを示したマイグレーション・フローを記載します。典型的なマイグレーションの取り組みは、「サーバーの特定とインベントリーの作成」から始まります。これは、対象範囲内のサーバーを詳しく調べて、マイグレーションの有力候補を識別するプロセスです。このプロセスでリストに挙がった有力候補は、次のステップ「サーバーとアプリケーションの絞り込み」でさらに絞り込まれます。実現可能性の詳細な調査により、最終的なマイグレーション候補が選出されて、「ウェーブ (波)」を形作るように論理的にグループ化されます。次のフェーズとなる「計画および設計」では、この絞り込まれたサーバーとアプリケーションのリストを基に、綿密なターゲット・トポロジーおよびマイグレーションが計画されます。詳細な設計が最終決定に至ると、次は「サーバーとアプリケーションのマイグレーション」と呼ばれる実行フェーズに進みます。このフェーズでは、ターゲット環境を構築し、アプリケーションをマイグレーションした後、マイグレーション後のアプリケーションが徹底的にテストされます。マイグレーション・フェーズを完了した後は、新しいサーバーの実稼働を開始し、最後のフェーズとなる「実稼働開始後処理」で古いサーバーのデコミッショニングを行います。

図 2. マイグレーション・フェーズの詳細
ステップおよびサブステップからなるフロー・チャートとして表されたマイグレーション・フェーズの詳細図

ここからは、マイグレーションに伴うステップを理解するために、上記で説明したフェーズとその作業を順に詳しく説明します。


サーバーの特定とインベントリーの作成

最初のステップは、どのサーバーをマイグレーションの対象とするかを特定することです。そして、サーバーと各サーバー上のソフトウェアの両方についてのインベントリーを作成します。

サーバーの特定

マイグレーションの取り組みでは、マイグレーションの対象とする適切なアセットつまりサーバーを特定することが重要です。合意されたワークロード管理に従って、各サーバーをマイグレーションの対象または対象外に振り分ける作業は、プロジェクト・アーキテクトおよび変換プログラムを実施している本部が行います。インベントリーの検証プロセスで最初に行わなければならない作業の 1 つは、既存のワークロードを調査することです (Intel ベースなのか、メインフレームなのか、その他のプラットフォームなのかを調査します)。サーバー、アプリケーション、ネットワーク機器、ソフトウェア、構成ファイル、オペレーティング・システム、そしてその他の IT インフラストラクチャー・コンポーネント間の依存関係を把握するために利用する製品としては、IBM Tivoli Application Dependency Discovery Manager (TADDM) が役立ちます。

マイグレーションの対象とする環境を選択するための最初の基準としては、表 1 に記載するワークロード分散モデルのサンプルを使用することができます。このモデルには、マイグレーションの候補としてサーバーを選択する基準となる実際のサーバー・リソースの使用率 (CPU、RAM、ネットワーク I/O など) のパーセンテージは記載されていませんが、このモデルを所定の適切な使用率の基準と併せて使用することで、サーバーをマイグレーションの候補とするか対象外とするかを判断することができます。

表 1. ワークロード分散モデルのサンプル
分類:サーバーの特徴:プラットフォームの特徴:
メインフレーム
  • CPU 使用率が持続的にピークとなる割合が少なく、必要とされる平均メモリー使用量も少ない
  • I/O 処理の割合が高く、I/O のトランザクション処理がある
  • メインフレーム内でのデータの近接性がある
  • メインフレーム専用のソフトウェアである
  • メインフレーム上のアプリケーションの別のコンポーネントである
Intel
  • Intel 上ですでに仮想化済みである
  • 用意されているイメージの数が少ない
  • Intel 専用のソフトウェアである
  • メインフレーム上の Linux ですべての Linux ニーズを満たせるわけではない
AIX/UNIX
  • AIX/UNIX 上での CPU 使用率が持続的にピークとなる割合が多い
  • AIX/UNIX 専用のソフトウェアである
  • AIX/UNIX 上ですでに仮想化済みである

サーバーとアプリケーションの絞り込み

このフェーズでは、マイグレーションの有力候補のリストをさらに絞り込みます。

変換計画と実現可能性の調査

  1. サーバーの複雑度を定義して、マイグレーション作業量を推定する

    仮想化されたターゲット環境にマイグレーションする有力候補として 1 台のサーバーまたは複数のサーバーを特定した後に重要となる次のステップは、サーバーのハードウェアおよびソフトウェアで調査した各種パラメーターに応じて、サーバーを単純なサーバー、中間的な複雑度のサーバー、複雑なサーバー、あるいは非常に複雑なサーバーとして分類することです。図 3 に、選択基準の一例を示します。

    図 3. サーバーのタイプに基づくマイグレーションの複雑度
    各種のマイグレーションの複雑度モデルを色分けして示すボックス

    単純なサーバー (Simple server) は、1 つの OS インスタンスの下で 1 つのアプリケーションまたはアプリケーションの一部をホストします。その一例は、WebSphere 環境で実行される単一の Web アプリケーションをホストする、Wintel ベースのシングル・コア CPU またはデュアル・コア CPU のサーバーです。

    中間的な複雑度のサーバー (Medium server) は、2 つまたは 3 つのアプリケーションをホストできる一方、複数の仮想マシン (VM) が定義されていないサーバーです。単純なサーバーと同じく、1 つの OS インスタンスで稼働します。例えば、1 つの OS の下で WebSphere Application Server (WAS)、DB2、IBM Http Server (IHS) フロントエンドといった、1 つのアプリケーションの複数のインスタンスを実行するサーバーなどがあります。このようなサーバーは、開発環境やテスト環境でよく見られます。

    複雑なサーバー (Complex server) とは、多くの場合、複数の CPU を使用するサーバーです。これらの CPU に、複数の論理区画 (LPAR) が定義されている場合もあります。この場合、LPAR のそれぞれに 1 つの OS がある構成か、LPAR のそれぞれに複数の VM があり、その VM がそれぞれに 1 つの OS を持つ構成になっています。これらの OS 上では同じシステム・リソース (ネットワーク I/O など) を共有する複数の (または関連性のない) アプリケーションがホストされます。例えば System p は、複数の LPAR でそれぞれ個別に AIX、p-Linux OS またはその他の OS および VM を実行し、同じネットワーク I/O を共有する多数の異なるアプリケーションを実行する場合があります。

    非常に複雑なサーバー (Very complex server) には、一般に複数の CPU があり、そのそれぞれに複数の LPAR を定義することができます。この場合、LPAR のそれぞれに 1 つの OS がある構成か、LPAR のそれぞれに複数の VM があり、その VM がそれぞれに 1 つの OS を持つ構成になっています。これらの OS 上では同じシステム・リソース (ネットワーク I/O など) を共有する複数の (または関連性のない) アプリケーションがホストされます。このようなサーバーは、ハードウェアまたはソフトウェアによる負荷分散機能あるいはフェイルオーバー機能によって、別のサーバーとクラスターを構成します。

    例えば HACMP クラスターで、複数の LPAR が DB2 データベースをホストする p-Linux または AIX の個々の OS を実行する場合などがあります。

  2. アプリケーションの複雑度を定義して、アプリケーションのマイグレーション作業量を推定する

    サーバーの複雑度を定義するだけでは、マイグレーションの作業量を完全に理解することにはなりません。サーバーが単純であっても、実行する製品、技術、あるいはアプリケーションが複雑な場合もあります。したがってマイグレーションを理解する上では、アプリケーションの観点から複雑度の分類を行うことも同じく重要です。図4 に、単純なアプリケーションから非常に複雑なアプリケーションまでの複雑度を示します。

    図 4. アプリケーションのタイプに基づくマイグレーションの複雑度
    各種のアプリケーションの複雑度を色分けして示すボックス

    単純なアプリケーション (Simple app)

    • 以下に該当するデータベース:
      • 比較的小規模なデータベース
      • データ・センター (DC) 内でのマイグレーション
      • 単一のインスタンスを実装するサーバーを使用
      • アプリケーションの所有者が 2 人までのサーバーを使用
      • ネイティブ言語のコードが使用されていない (コード修正の必要がない) データベース
      • 週末のサービス停止期間を設けられるアプリケーションを使用
    • 以下に該当する WAS/Java アプリケーション:
      • JVM サイズが比較的小さいか、単一の JVM 実装
      • WAS の移行による API の変更がなく、現状のままアプリケーションが使用できる場合 (例えば、WAS 6.1.x から 6.1.x への移行、WAS 5.1 から 6.0.x への移行、WAS 6.1 から 7.0.x への移行など)
      • アプリケーション所有者が 2 人までのアプリケーション・サーバーを使用
      • ネイティブ言語 (例えば、C/C++ など) のコードが使用されていない (コード修正の必要がない) アプリケーション
    • 以下に該当する IHS:
      • 大部分が静的ページ (HTML、画像、JavaScript など) で、CGI スクリプトや Perl モジュールがほとんど使用されない、あるいはハード・コーディングされた IP アドレスによるデータベースおよび依存関係の直接呼び出しがほとんど使用されない場合
    • 以下に該当する Domino:
      • 外部のデータ・ソースやスクリプトとのやりとりを行わず、.NSF データベース内に必要なものがすべて含まれるアプリケーション

    中間的な複雑度のアプリケーション (Meidum app) は、常にケース・バイ・ケースで判断されます。単純であるか、複雑であるかの評価は、ボリューム、ユーザー・ベース、アーキテクチャー、ミドルウェア製品、そしてそのすべての組み合わせに依存するためです。例えば、WebSphere Commerce Suite (WCS) を WCS 6.x から 6.x にマイグレーションする場合、カスタム JSP もカスタム・モジュールも使用しないのであれば、これは中間的な複雑度のマイグレーションとなります。けれども、カスタム JSP またはプログラム・モジュールの数が多く、バージョンを 5.5/5.6 から 6.x にアップグレードするとなると、作業量推定の分析次第では、複雑なアプリケーションまたは非常に複雑なアプリケーションと判断される傾向があります。

    • 以下の場合にも、中間的な複雑度のアプリケーションとして分類されます。
      • 単純な J2EE アプリケーションをマイグレーションする際に、コードの修正が必要になるものの、その修正は、JRE 1.4.2 から 1.5 への API の変更に限られる場合
      • タイプ 2 からタイプ 4 ドライバーへの変更
      • データベースを使用する Domino アプリケーション、あるいは外部データ・ソースへの Java 接続を使用する Domino アプリケーション (Lotus Enterprise Integrator (LEI) の使用を含む)
      • ターゲット環境で使用可能なツールを使用して開発された (移植の必要がほとんどない) カスタム・アプリケーション

    複雑なアプリケーション (Complex app)

    • パーティション化されたデータベース (DPF を備えた DB2) または大規模なサイズのデータベース (DC 間マイグレーション)。以下の点を判断の目安にすることができます。
      • 1TB 以上のストレージがサーバーに接続されている
      • データベースに常時サポートが必要であり、しかも保守の時間枠が限られている
      • 現在データベースがディザスター・リカバリー (DR) 用コードを実装している
      • 大量の CPU リソースや I/O リソースを必要とするデータウェアハウジング・データベース
      • サーバーに多数のインスタンスがある (例えば、1 台で 3 つ以上のインスタンスを使用)
    • WAS/Java アプリケーション ― WAS バージョン 4.0/5.0 から 6.0/6.1/7.0 にアップグレードする場合 (アーキテクチャーが変更されるため)。最小限のカスタマイズで WCS 5.5/5.6 から 6.x にアップグレードする場合。カスタマイズなしの PDM または WCM でのポータル・マイグレーションの場合。
    • IHS ― 静的コンテンツと動的コンテンツが混在する場合。大規模なアプリケーションのバックエンドに複雑な再書き込みルールがあり、バックエンドの呼び出しが複雑な場合。ディレクトリー構造に依存する CGI/Perl スクリプトや、外部 Perl モジュールとの依存関係がある CGI/Perl スクリプト、貧弱なコーディング標準でコーディングされている (再作成を要する) CGI などを多用している場合。
    • Domino ― サード・パーティーのアプリケーション・コードまたはエクステンダーを使用している場合。Domino 要素がポータル内で使用されている場合。下位レベルの Domino API または OS API が使用されている場合。複雑さが中程度の Domino アプリケーションを Windows から Linux (または Linux on System z) にマイグレーションする場合。

      一般に、アプリケーションが現在実装しているのが DR 用コード、サード・パーティーのアプリケーション・コード、ポーティングが必要だが同じ開発環境を使用する何千ものモジュールを持つカスタム・コード、そして開発環境の変更 (例えば Visual Age から GNU ツール・スイートへの変更など) が必要なカスタム・コードの場合、マイグレーションが複雑になると考えられます。

    非常に複雑なアプリケーション (Very complex app)
    • データベース ― DB2 データベースを AIX から zOS にマイグレーションする場合。この類のマイグレーションには、ファイルシステムの変更に応じた大々的な改訂、データ・ボリュームが 1TB を超える DPF、データベース間のマイグレーション (ORACLEから DB2、Informix から DB2 へのマイグレーションなど)、そして zLinux でサポートされていない DB2 エクステンダーのためのマイグレーションが必要になります。
    • WebSphere ― アプリケーションが現在 WebSphere の古いバージョン (WAS 3.5 や 4.0 など) 上で実行されている場合。アプリケーション・コードを WAS 7.0 にデプロイするためにコードを大幅に改訂する必要がある場合。WebSphere Process Server の大量のワークフローを WebSphere Integration Developer (WID) を使用してカスタマイズする必要がある場合。

複雑なアプリケーションとは一般に、他の OS ではサポートされていない言語で開発されたカスタム・プログラムを使用するアプリケーション、コードの改訂を別の言語で行わなければならないアプリケーション、カスタマイズされた複数の API プログラムを使用する必要があるアプリケーション、あるいは現在の環境に固有の API またはライブラリーを使用しなければならないカスタム・アプリケーションです。

ウェーブ計画: グループごとのマイグレーション

図 5 では、実際のマイグレーション複雑度レベルを判別するために、アプリケーションとサーバー両方の複雑度が考慮されています。

図 5. サーバーとアプリケーションの複雑度の組み合わせ
アプリケーションとサーバーの複雑度を組み合わせてマイグレーションの複雑度を分類する方法を示す図

サーバーとアプリケーションのマイグレーションは一般に、サーバーのマイグレーション計画時に決定されたウェーブ (グループ) 式アプローチによって行われます。スクリーニング (選別) フェーズで絞り込まれたマイグレーション候補のサーバーとアプリケーションを特定したら、ウェーブ (グループ) 内のマイグレーションに、大まかな推定タイムラインを割り当てます。ウェーブ・プロジェクトの開始後は、サーバーとアプリケーションの複雑度によって、ハードウェアおよびサーバー、さらにはアプリケーションのバイナリーおよびデータに関連付けられたマイグレーションの全体的複雑度という点で、マイグレーションのタイムラインが導き出されます。

ウェーブ計画のプロセスとしては、他にもアプリケーションの順次処理プロセス、アプリケーションの優先順位決定プロセス、事業年度末プロセス、企業凍結プロセスなどがありますが、これらのプロセスはプロジェクトごとに固有であるため、この記事では取り上げません。

ウェーブを形成したら、次はウェーブ・プロジェクト・マネージャーがマイグレーションに取り組むためのプロジェクト計画を準備します。プロジェクト・マネージャーは、クライアント・チームに相談して、システム・テストおよびユーザー・アクセプタンス・テストに必要な作業量を推定してもらいます。プロジェクトの計画という観点からは、以下のフェーズがあります (表 2 も参照)。

  1. ソリューションの開始と計画 ― 実現可能性を調査し、重要な技術的判断を下し、ターゲット環境を最終決定します。
  2. 実行および管理 ― マイグレーション対象として認定された各アプリケーションのマイグレーションを実行および管理するための詳細な計画を作成します。
  3. 実稼働開始および終結 ― 最後に、新しい環境を実稼働状態にし、プロジェクトの終結手順に従います。
表 2. ウェーブ計画のフェーズ
ソリューションの開始および計画実行および管理実稼働開始および終結
  • 資料をレビューして確定する。アセット担当主任に相談する。
  • 環境、ゾーンを決定し、障害要因を明らかにする。
  • ターゲット環境および動作プラットフォームを決定する。
  • 将来的なアーキテクチャーまたはターゲットとするアーキテクチャーを決定する。
  • 詳細な計画を完成させ、マイグレーション対象として認定されたアプリケーションごとに、技術的マイグレーションの、実行および管理を行う。
  • アセット担当主任に相談および報告する。
  • 切り替え作業、切り替え後の作業、および終結作業を計画する。
  • 計画についてアセット担当主任に相談および報告する。

計画および設計

計画および設計フェーズの一環として、顧客と一緒にマイグレーションするサーバーとアプリケーションの状況をまとめます。そのアセスメントを基に、技術ソリューションを設計します。

アプリケーション・アセスメント

顧客とのアプリケーション・アセスメントは、最初にアンケート調査、続いて主要な利害関係者とアプリケーション・チームの技術メンバーとのミーティングによって行われます。したがって、まずはマイグレーション対象のサーバーとアプリケーションの状況に関する情報を収集するためのアプリケーション・アセスメント・アンケート (Application Assessment Questionnaire: AAQ) を作成する必要があります。

AAQ で収集するユーザー・データとしては、主に以下の属性が挙げられます。

サーバーの状況:

  • サーバー名 (FQDN)
  • クラスター (はい/いいえ)
  • クラスター・サーバー名
  • 実行環境 (本番用/ステージング用/テスト用/開発用)
  • サーバー・ロケーション (都市/データ・センター/ホスティング環境)
  • サーバー・タイプ (Web/アプリケーション/データベース/ハイブリッド)
  • ネットワーク・ゾーン (内部/外部/DMZ)
  • サーバーの IP アドレス
  • ハードウェア製造元
  • 型式
  • プロセッサー数
  • メモリーに関する情報
  • ストレージに関する情報
  • 物理/仮想
  • サーバー使用率
  • 平均使用率
  • ピーク使用率
  • ピーク時間
  • サーバー構成履歴

アプリケーションの状況:

  • サーバーで実行されているアプリケーションの名前は何ですか?
  • アプリケーションとビジネスでのそのアプリケーションの役割を簡単に説明してください。説明には、アプリケーションの機能と全体的な動作を含めてください。
  • このアプリケーションは、大規模なエンタープライズ・アプリケーション・グループ (Enterprise Application Group: EAG) の一部を成すコンポーネントですか?
  • アプリケーションが EAG を構成するコンポーネントとなっている場合、このアプリケーションとその EAG を構成する他のアプリケーションとが連動する必要がありますか (例えば、アプリケーションまたは EAG を構成する他のアプリケーションに、他のプロジェクトとのアクションと密接に結合された依存関係あるいは機能があるため、これらを 1 つの単位として扱う必要がありますか)?
  • このアプリケーションは社内で開発されたものですか?それとも、独立系ソフトウェア・ベンダー (Independent Software Vendor: ISV) から購入した製品ですか?以下のなかから、該当する答えを選択してください。
    • カスタムまたは自社開発
    • 民生品 ― 修正なし
    • 民生品 ― マイナーな修正
    • 民生品 ― 大幅な修正
  • 主要なアプリケーション・ソフトウェア・ベンダー、そして使用しているソフトウェアのリリースまたはバージョンは何ですか?
  • このアプリケーションは現在どのプラットフォームで実行されていますか (Windows、Linux、AIX、Solaris、その他)?
  • そのプラットフォームは望ましいプラットフォームですか、それともその他に検討中、あるいは希望するプラットフォームがありますか?
  • Account Focal (顧客担当者)、DPE (Delivery Project Executive: プロジェクト責任者)、またはこのアプリケーションのすべての最終決定権 (技術文書やユーザー・アクセプタンス・テストなど) を任されているのは誰ですか?
  • アプリケーションの機能を全面的に理解するのに役立つ図面または文書がありますか?
  • アプリケーションまたはそのホスト・サーバーに大幅な変更、アップグレード、または非常に重要なプロジェクトが予定されていますか?
  • このアプリケーションは以下のうちのどれに当てはまりますか?
    • スタンドアロン・アプリケーション
    • アプリケーションおよびデータベース
    • インフラストラクチャーまたはユーティリティー
    • スタンドアロン Web
    • Web アプリケーションおよびデータベース
  • このアプリケーションは何らかの共通 (共有) サービスを使用していますか?使用している場合は、そのサービスについて詳しく説明してください (例: ファイアウォール、プロキシーおよびリダイレクト、認証、Lotus Notes レプリケーション、MQ Series、Web 認証)。一般に、Web でアクセスできるアプリケーションは、共通サービスが関わっていることを意味します。

ネットワーク情報やアプリケーションの詳細、ならびに今後のストラテジーと拡張について収集するには、これよりも重要な情報が必要になります。さらに、ある特定のアプリケーションのためにデプロイするデータベース (DB2)、ミドルウェア (WebSphere Application Server)、メッセージング (WebSphere MQ) などの特定のソフトウェアに関する詳細を収集するには、別のアンケートが必要になることも考えられます。

技術ソリューションの設計

技術ソリューションの設計は、変換管理プログラムの中で最も重要なフェーズの 1 つです。インベントリーの検証による情報、サーバーとアプリケーションの状況、そして顧客とのミーティングの結果がすべて、この技術ソリューション設計に取り込まれます。

技術ソリューション設計の重要な作業成果として、Excel ベースの成果物である TSD (Technical Solution Design) に取り込まれるのは、以下の内容です。

  • ソリューションの概要
  • TSD 固有の前提と、明らかにされたリスクについての記録
  • ソリューションの説明。これには、アーキテクチャーに関する決定事項とアプリケーションへの影響も含まれます。
  • ソース・サーバーに関するすべての情報を記載した表
  • アプリケーションとサーバーのマッピング・テーブル。このテーブルには、各アプリケーションと、そのアプリケーションが実行される各サーバーのエントリーが含まれます。このマッピングは多対多の関係になります。
  • ターゲット・サーバーに関するすべての情報を記載した表
  • ターゲット環境の図と説明
  • アーキテクチャーに関する決定事項と、その代替候補に関する検討事項からなる、ソリューションの説明
  • 具体的な前提およびリスク

特定のアーキテクチャー決定シナリオの説明

技術ソリューションを設計する際には、ターゲット環境、ターゲット・プラットフォーム、ターゲット・トポロジー、およびターゲット環境とのアプリケーションの適合性に関して、重要なアーキテクチャー上の決定を下す必要があります。これについて説明するために、以下の 3 つの例を取り上げます。

例 1:Linux 仮想環境での製品の適合性

  • サブジェクト・エリア: Linux 仮想プラットフォームでの適合性に基づくソリューション・アーキテクチャー
  • 課題または問題の定義: マイグレーションのスコープは、3 つの顧客環境に複製する Linux スタックを構築することです。例えば、以下の顧客環境があります (これに限定されるわけではありません)。
    • 開発環境
    • テスト環境
    • 本番環境

    この 3 つの環境に順次 J2SS アプリケーションをデプロイします。

  • 前提: J2EE コンテナーは、WebSphere Application Server (WAS) とします。
  • 選択肢:
    1. OS と WAS ミドルウェアからなる開発環境を構築した後、複製技術を適用してテスト環境および本番環境を作成します。
    2. OS と、Linux ミドルウェアをベースとした WAS Hypervisor Edition からなる開発環境を作成した後、複製技術を適用してテスト環境および本番環境を作成します。
  • 決定: 選択肢 2 を採用。
  • 理由: WAS Standard Edition または WAS Enterprise Edition で Linux OS を構築すると、インストール時に現行環境のホスト名と IP アドレスの参照が統合されて、密接に結合されます。このことから、開発用 Linux イメージから新たに複製を作成した後は、WAS が新しい Linux ビルド・イメージで機能しなくなります。WAS の多数の箇所 (セル名や WAS プロファイル内のセル名やその他の箇所) には、古いホスト名や IP アドレスの参照が格納されているためです。古いプロファイルを削除して新しいプロファイルを作成するとなると、マイグレーションでの作業が追加されることになります。

    この問題を避けるために、Linux ベースの WAS Hypervisor Edition を選択します。WAS Hypervisor Edition は、現行の環境と密接に結合しません。そのため、依存関係を削除するスクリプトを手作業で作成する手間を省くことができます。

例 2:Linux 環境での移植性に関係する要素

  • サブジェクト・エリア: プラットフォームの選択に関するソリューション・アーキテクチャーの例
  • 課題または問題の定義: アプリケーションとバックエンド・データベース・サーバーを AIX から Linux on System z にマイグレーションします。サーバー・アプリケーションと DB2 バックエンド・コンポーネントのすべては、現在仮想化されていない AIX 環境で実行されています。クライアントは、サーバーを Linux または AIX のいずれかをベースとした仮想環境に移し、仮想化を利用して、スケーラビリティーと運用コストの点でコンピューティング・プラットフォームを改善することを目的としています。
  • 前提: Linux 仮想化プラットフォームと AIX 仮想化プラットフォームを使用できます。経済的な観点からは、Linux の価格設定モデルのほうが AIX 仮想化よりも魅力的です。
  • 選択肢:
    1. ソース・プラットフォームは AIX であるため、サーバー内のすべてのコンポーネントを AIX で作成し、仮想化します。マイグレーション関連のリスクは、この選択肢では最小限となります。
    2. クライアントにとって Linux は経済的にメリットがあるため、サーバー内のすべてのコンポーネントを Linux で作成し、仮想化します。
    3. バックエンド・データベースは AIX で作成し、フロントエンド・コンポーネントは AIX および Linux で作成して仮想化します。
  • 決定: 選択肢 3 を採用。
  • 理由: DB2 コンポーネントには、理想的には Linux on System z が適しています。それは、頻繁な I/O 処理が予想されるワークロードの管理にはメインフレーム・アーキテクチャーのほうが適しており、DB2 データベース・バックエンドには本質的にアプリケーション・サーバー・コンポーネントより多くの I/O 処理が伴うためです。ただし、クライアントはバックエンド DB2 コンポーネントのクラスタリングも必要としていました。それには、以下の理由から、DB2 を AIX または pSeries で稼働させなければなりません。
    • 新しく作成された Tivoli Storage Automation (TSA) や zLinux の DB2 HADR とは対照的に、HACMP は成熟したクラスタリング・ツールです。さらに、TSA は z テスト環境では十分にテストされていません。
    • DB2 サーバーの使用率が持続的に高い値を保つ (75% を上回る率) 状況には、pSeries ハードウェアが非常に適しています。WAS コンポーネントのワークロードは CPU への負担が少ないことから、Linux on System z に適しています。

例 3:Linux 環境のデータ・センターでの運用に関する側面

  • サブジェクト・エリア: データ・センターの選択に関するソリューション・アーキテクチャーの例
  • トピック: 運用モデルおよびホスティング・ロケーション。ポキプシー (Poughkeepsie) データ・センターまたはボールダー (Boulder) データ・センターに、インフラストラクチャーを構築します。
  • 課題または問題の定義: サウスベリー (Southbury) にある現在の IBM データ・センターから、ニューヨーク州ポキプシーまたはコロラド州ボールダーの新しい仮想化 Linux 環境にサーバー・ワークロードをマイグレーションします。
  • 選択肢:
    1. ポキプシー
    2. ボールダー
  • 決定: 選択肢 1 を採用。
  • 理由:
    • 将来的な拡張の方向性を考えると、ポキプシーでのサーバー・キャパシティー (大容量) およびストレージ・キャパシティーと z9 および z10 の可用性ならびに共有キャパシティーは、より要件に適合しています。
    • サウスベリーとポキプシーは近接しているため、データ・マイグレーションが容易になります。
    • サウスベリーとポキプシーではタイムゾーンが同じであるという利点が、運用の複雑さを最小限に抑えます。

キャパシティー・プランニングとサーバー・サイジングに関する注意事項:

新しい統合サーバー環境でのリソースの最適な割り当てまたはサイジングを決定するため、さらには予想されるワークロードのパフォーマンスを確実にするために、キャパシティー管理手法が適用されます。以下に挙げる要素を確実にするためには、ターゲット・サーバー・ハードウェアの適切なサイジングが不可欠です。

  • パフォーマンス
  • 将来的な拡大
  • 統合率
  • 経済的利益

図 6 に、上記の要素と計画およびサイジングとの関係を示します。

図 6. キャパシティー・プランニングおよびサーバー・サイジングの要素
キャパシティー・プランニングのさまざまな要素が互いにサポートする仕組みを示す図

サーバー・サイジングは、アセスメント・フェーズとインベントリー・フェーズでのデータ収集に基づいて行います。一例として、サーバーの現行ハードウェア・モデル、CPU のパフォーマンス・メトリック、および既存のハードウェアで使用可能なコア数およびチップ数を分析した後、各サーバーの相対パフォーマンス (rPerf: Relative Performance) 値に基づいて、サイジングを計算することができます。その際には、極めて重要な以下の項目を調べてください。

  • サーバー製造元
  • サーバー・モデル
  • CPU の数
  • CPU のコア数
  • CPU 速度
  • CPU 使用率
  • 搭載されている RAM
  • 使用されている RAM
  • ストレージの割り当て量と使用量

他のサーバーの CPU 使用率のピークを直接の判断基準としてサイジングを推定し、その推定をワークロードの特性に応じて調整します。サーバー統合のサイジング推定の正確さは、提供される情報によって左右されます。不正確な推定になる最も一般的な理由は、現行サーバーの CPU 使用率が不正確なことです。サイジングの際に使用する個々のサーバーの CPU 使用率のピークと全サーバーでのピーク需要のパターンが、正確な推定には不可欠です。ピーク負荷が発生する時間がサーバーによって異なる場合には、ピークが同時に発生する場合よりもサーバー・キャパシティーの要件は大幅に小さくなります。ワークロードの特性の違いも、重要な要素です。ワークロードの特性の違いによって、サイジングの結果が 4 倍違うものになることもあります。誤った情報あるいは正確さを欠いた情報を入力すると、サイジングの結果は妥当なものではなくなります。非常に重要な点として、サイジングの際に使用する情報が、現行サーバーのワークロードと CPU 使用率を正確に反映していることを確実にしてください。

さらに、CPU 使用率のピーク・データを正しく収集することも重要です。CPU 使用率のピーク・データは、瞬間的なピークではなく、15 分から 30 分のピーク需要期間の平均 CPU 率を表すものでなければなりません。顧客が 8 時間シフトまたは 1 日の平均 CPU 使用率に関するデータを持っている場合には、ピーク使用率と平均使用率の比を適用して、ピーク時の合間の CPU 使用率を正しく反映する必要もあります。

ベンチマークのサイジング・パラメーターには以下のものが含まれます。

  • アプリケーション・プログラム
  • パフォーマンス・モニター
  • データ・ファイル (データ・セット) およびデータベース
  • スクリプト (ユーザー・コマンド) またはジョブ
  • ワーキング・セットのサイズ
  • ターミナル・シミュレーション
  • ユーザー入力のサイズ
  • 平均思考時間と思考時間の分布
  • トランザクション速度
  • 応答時間基準
  • 運用方法

ベスト・プラクティスとしては以下の内容が挙げられます。

  • IBM では、アンケートの情報をサイジングの入力データとして使用しています。
  • サイジング・シミュレーションにより、顧客が計画したビジネス・ボリュームを潜在的ワークロードに変換します。
  • 潜在的運用での CPU、メモリー、およびディスク要件を考慮します。
  • 実際のワークロードに対する機能評価を行います。
  • サイジングのガイドライン、手法、およびツールについて理解します。
  • サイジング、キャパシティー・プランニング、またはパフォーマンス分析のそれぞれを実践する場合のサイジング要求と、それぞれに特有のシナリオでツールや手法を使用する場合のサイジング要求を検証し、その違いを明らかにします。さらに顧客の環境にサイジング要求を適用する方法についても検証します。
  • 適用可能な場合には、IBM のサイジング・ツールを使用します。または ISV のサイジング手法およびツールを使用します。その際には、必ず最新バージョンのサイジング・ツールを使用してください。
  • マイクロ・パーティショニングがサイジングにどのように影響するかを理解し、出力された結果で説明します。
  • 拡張計画を含め、ヘッドルームと複数のサイジングを提供します。
  • ツールの精度には、+/- 30% が求められます。
  • ボリューム測定データ・ポイントを入手し、それが承認されていることを確認します。さもないと、連鎖反応によって、不適切なサイジングが行われる結果になってしまいます。
  • バッチ処理に対する並列処理の影響を考慮します。

参考となるサイジング・ツールの例:

  • IBM 製サイジング・ツール:VISIAN

    VISIAN は、Excel ベースの IBM 社内ツールです。このツールは、ソース・サーバーの技術構成 (サーバーの数、タイプ、CPU 速度、メモリーなど) とソース・サーバーのリソース使用率 (CPU 使用率、メモリー使用率、NW 使用率など) に関する情報を取り込み、仮想化層の特性、制限、オーバーヘッドを考慮してサイジングを行います。VMware ESX、MSVS、Virtual Iron、および pSeries ハイパーバイザーがサポートされます。

    VISIAN は、以下の計算を行います。

    1. 必要なターゲット・サーバー数
    2. 各ターゲット・サーバーに関する情報
      1. 仮想マシンの数
      2. 各ターゲット・サーバーで仮想化するソース・サーバーのリスト
      3. CPU、メモリー、ネットワーク、ディスク、ディスク・スペース、およびディスク I/O の使用率
    3. 必要な物理スペース (ラック・ユニット数)
    4. ハードウェアおよび仮想化ソフトウェアのコスト
  • よく使われているサード・パーティー製サイジング・ツール
    1. VMware Capacity Planner

      他のツールとは異なり、VMware Capacity Planner はターゲット VMware 環境だけに機能するホスト型アプリケーション・サービスです。このツールは多数のコンポーネントをネットワークにインストールしてデータを収集および管理します。これらのデータは VMware に送信されて分析されます。このツールの大きな欠点は、ソフトウェアの所有権が与えられず、継続的な作業には使用できないことです。ベンダー分析が完了すると、クライアントには、仮想化の目標を達成するためのさまざまな構成を提案するシナリオが提示されます。Capacity Planner サービスは、VMware のパートナー (コンサルタント、ハードウェア・ベンダー、ソフトウェア・ベンダー、およびその他の直販店を含む) が提供しています。

    2. Novell PlateSpin PowerRecon

      Novell の PowerRecon は、リモート・データ収集、ワークロード分析、そしてサーバー統合の計画とシナリオ比較を行うための機能を統合したツールです。このツールは、ワークロードの特質を CPU、ディスク、メモリー、ネットワークに分けて自動的に分析します。

    3. CiRBA

      CiRBA は、CPU、メモリー、I/O、オーバーヘッド、およびストレージを分析し、ハードウェア・サイジングの出発点としての概算を出すことができます。

    4. VMware Guided Consolidation

      この組み込みツールは、比較的小規模な IT 環境をターゲットとする Virtual Infrastructure 3 (VI3) の一部です。

      選択されたシステムの集合を分析して仮想化に最適なサーバーについてアドバイスをし、物理サーバーを仮想環境に変換 (P2V (Physical-to-Virtual) 変換) することができます。

フレーム配置のためのターゲット・トポロジー:

特に仮想環境で重要となる、マイグレーションのもう 1 つの重要な側面は、仮想マシン (VM) ゲストのターゲット・トポロジーおよび適切なフレームまたは物理コンテナーへの配置を設計および決定することです。

アプリケーション・スタック構成および依存関係の分析:

キャパシティー・プランニングの実施および依存関係に関する検討事項は、ソリューション設計フェーズで話し合って決定する必要があります。適切なアプリケーション・スタック構成に至るには、デプロイメントに関するさまざまな要素を検討しなければなりません。以下でデプロイメントに関するいくつかの要素を概説し、これらの要素内での明確な切り分けを行います。

  1. ソフトウェア・スタックのバージョン ― 例えば、WAS 6.0 アプリケーションと WAS 7.0 アプリケーション。バージョンによって、WAS のサポート・ライフサイクルは異なり、保守またはフィックスパックのリリース頻度は同じでない場合があります。
  2. セキュリティー ― レベル 4 のデータ・セキュリティーに必要なアプリケーションをグループ化します。より明確な責任分担および分離を維持するには、SSO 認証と非 SSO 認証をそれぞれ異なるフレームに分けます。
  3. パフォーマンスおよびスループット ― より高速な応答の SLA を必要とするアプリケーション、つまり理想的なパフォーマンスを維持するためにより大きなメモリー・フットプリントが求められるアプリケーション (例えば、ヒープ・サイズが 2GB の JVM を必要とするアプリケーションなど) は、単純なアプリケーション (例えば、ヒープ・サイズが 256 MB から 512 MB の JVM を必要とするアプリケーションなど) とは異なり、専用のアプリケーション・サーバーが必要になる場合があります。
  4. スケーラビリティー ― スケーリングしてアップグレード可能な共有アプリケーション、今後のリリースで Web サービスの導入が予定されているアプリケーション、災害復旧を想定したアプリケーション、そしてその他のカテゴリーに分類します。
  5. 可用性 ― SLA に基づきます。
  6. 災害復旧 (Disaster Recovery: DR) レベル ― 最適化された共有 DR インフラストラクチャーを設計するための第 1 層アプリケーションと第 2 層アプリケーションにグループ分けします。

仮想環境でのフレーム配置に関するアプリケーション・レベルの分析

仮想環境での VM ゲストの配置の決定は、アプリケーションの相互関係の観点から重要です。例えば、より高度な SLA アプリケーションについては、複数の VM に分散させなければなりません。アプリケーションの機能要件 (一例を挙げると、データ処理、I/O 処理が多くを占めるバッチ・ジョブ、大量のトランザクション処理、Web レンダリングなど) と、四半期または 1 年にわたってのピーク負荷の時間を明らかにすることができるので、それに応じて適切なフレームにアプリケーションを配置するように決定し、フレーム全体のワークロードを分散させることができます。

また、100% を超えるリソース割り当て (オーバーサブスクリプション) も可能です。つまり、仮想化のオンデマンド・キャパシティー・プランニングによって、上限しきい値として推奨される実際の物理キャパシティーに対処します。この決定は、ピーク時にすべての VM が同時に実行されるわけではないため、超過割り当てに対応できるプロセッサー・キャパシティーがあるという事実によって支持されるはずです。例えば、バッチ・サーバー・タイプのワークロードの Linux イメージを別のトランザクション・サーバーの Linux イメージと一緒に使用することで、使用可能なキャパシティーを超えた割り当てが可能になります。バッチ・ワークロードがアクティブになるのは夜間であり、トランザクション・サーバーは夜間にはアイドルまたは準アイドルであるためです。このようにすれば、ワークロード全体で適切にバランスをとってオーバーサブスクリプションに対応することができます。


サーバーとアプリケーションのマイグレーション

いよいよ、サーバーとアプリケーションのマイグレーションに取り掛かります。

IT 環境の構築

ソリューション設計ができたら、次はターゲット環境の構築に取り組みます。このフェーズでは、予定されたターゲット・イメージの詳細と仕様を含む、「ビルド・シート」として一般に知られている文書がコンパイルされます。このフェーズに達するまでには、ターゲット・ハードウェアのサイジングと、ユーザー ID、ファイルシステム、およびその他の項目に関連するユーザー要件のリストは完成しているはずです。

実際の IT 環境の構築プロセスは、IBM Tivoli Provisioning Manager (TPM) などのツールを使用して自動化することも、手作業で行うこともできます。どちらの手法を採用するかによって、ビルド・シートは Excel ベースになるか (手作業によるプロセスの場合)、自動プロビジョニング・ツール (例えば TPM) を指すセルフサービス Web インターフェース・ポータルになります。

いずれの手法を採用するにしても、ビルド・シートには、以下の基本的な詳細情報が含まれます。

  • 要求グループの詳細
    • 作成日
    • 要求者
  • ソース・サーバーの要約
    • サーバー数
    • 合計 CPU 数
    • 合計メモリー
  • ターゲット・サーバーの要約
    • サーバー数
    • 必要な合計 CPU 数
    • 必要な合計メモリー
    • 合計ローカル・ディスク・サイズ
  • 管理情報
    • アプリケーション名
    • 顧客
    • プロジェクト・マネージャー
  • ホストおよびネットワーク情報
    • ホスト
    • ホストのロケーション
    • ホストのアーキテクチャー
    • プライマリー IP アドレス
    • 完全修飾ドメイン名
  • ソフトウェア・コンポーネント
    • オペレーティング・システム
    • データベース
    • ミドルウェア
  • ローカル・ファイルシステム
    • マウント・ポイントのタイプ
    • サイズ (MB)
    • 所有者
    • グループ
    • パーミッション
    • ボリューム
  • ユーザー
    • 名前
    • プライマリー・グループ
    • セカンダリー・グループ

以上の要求事項をすべての利害関係者がレビューした後、マイグレーション・チームはサーバー・ビルド・チームに要求を提出します。すると、サーバー・ビルド・チームがイメージを用意してマイグレーション・チームに渡します。イメージを受け取ったマイグレーション・チームは、マイグレーション・プランで概説されている作業を開始します。

アプリケーションのマイグレーションとユニット・テスト

マイグレーション作業を開始するには、マイグレーション・プロセスに必要なすべてのステップが文書化されている必要があります。そのために、「マイグレーション計画」と呼ばれるこのフェーズでは、マイグレーション・プランを作成します。マイグレーション・プランとは、マイグレーション・チームが順に行う必要があるすべてのタスクを詳説する文書です。マイグレーション・プランには、作業の名前、その作業の所有者、開始日、予定される期間が記載されます。マイグレーション・チームの各メンバーは、マイグレーション・プランに記述されている、それぞれの担当タスクを行う必要があります。したがって、マイグレーション・プランは、優れた追跡文書になるというわけです。スプレッドシート・ベースのマイグレーション・プランには、通常、以下のセクションがあります。

  • 表紙: プロジェクト名、文書の承認者、改訂履歴
  • サーバー: マイグレーションするサーバーの名前
  • マイグレーション前: マイグレーション対象の各ソフトウェアに関するタスク
    • インストールされている DB2 クライアント/サーバーの確認
    • ソース・サーバーの詳細な表スペース・リストの取得
    • DB2 のバックアップおよびリストアの準備
    • ターゲット上での DB2 インスタンスの作成
    このセクションに記載されるアプリケーション固有のタスクには、サーバー準備状況のチェック、ソース・サーバーからターゲット・サーバーへのアプリケーションのファイルシステムとユーザー・ホーム・ディレクトリーのマイグレーションなどがあります。
  • マイグレーション: 各ソフトウェアに関連するタスク。環境のセットアップとコードの修正 (ユーザー・プロファイル、ログイン・シェル、環境変数などの設定や、アプリケーション・スクリプトにハード・コーディングされたパスの修正) も、この時点で行われます。DB2 の場合を例に挙げると、ソース環境でデータベース・サーバーをシャットダウンするタスク、オフライン・データベース・バックアップを開始するタスク、およびデータベースをターゲットでリストアするタスクがあります。アプリケーションが正しくインストールされて、新しい環境で運用可能になったら、環境の検証テストやユニット・テストを行います。
  • マイグレーション後: クリーンアップ・タスクを行います。このタスクで、マイグレーション中に作成されたカスタム・スクリプトや一時ユーザー ID を削除します。
  • 連絡先の詳細: マイグレーション作業に携わったすべての担当者の名前とそれぞれの連絡先の詳細が記載されます。
  • 問題: (オプション) マイグレーション中に直面した問題や、関連するコメントが記載されます。

サーバー準備状況チェック: (本番環境と非本番環境の両方に該当)

ターゲット・イメージがマイグレーション・チームに提供されると、そのサーバー・イメージが要件 (ビルド・シートに記載) に従っていることを検証するためにイメージで一連のチェックが行われます。このステップは、「サーバー準備状況チェック (Server Readiness Check)」と呼ばれ、イメージ・パラメーターをチェックする UNIX コマンドで構成されます。

例:

  1. ボリューム・グループ、ボリューム、ファイルシステム、およびマウント・ポイントは、ビルド・シートに指定されているとおりにセットアップされて構成されていますか?
    # lvs    or    # lvdisplay
    # vgs    or    # vgdisplay
    # cat fstab     ( to check mount points )
  2. ファイルシステムは、ビルド・シートでの指定に従って正しくセットアップされていますか?
    #df –h  < filesystem>

通常のチェックは、ユーザーシステムストレージインストール済みソフトウェア、および特殊な指示というカテゴリーに分類されます。マイグレーション・エンジニアは、それぞれのカテゴリーをチェックして、承認または却下します。大きな相違がある場合には、イメージをインフラストラクチャー・チームに返して修正させます。イメージが承認されてからでないと、アプリケーションのマイグレーションは開始されません。

マイグレーション後のタスク:

  • 非本番環境の場合:

    ソース・サーバーとアプリケーションをシャットダウンする前に、ユーザーにサービスが停止されることを通知します。ミドルウェア・スペシャリストのそれぞれが、DB2、Lotus Domino、WebSphere MQ などのソフトウェアのセットアップと構成に関する一連のタスクを行います。それと並行して、アプリケーションのバイナリーとファイルシステムをソース・サーバーからターゲット・サーバーにマイグレーションするタスクが開始されます。この時点で、ユーザー・ホーム・ディレクトリーもソース環境からターゲット環境にコピーされます。

    ソースからターゲットへのファイル転送で共通して使用される方法は、ファイルを TAR で圧縮してから、FTP モードでファイルをコピーするか、rsync を使用する方法です。

  • 本番環境の場合:

    本番環境では、DB2 や Lotus Domino などの各種ソフトウェアのセットアップおよび構成に関するタスクは前述のように行われますが、アプリケーション・ファイルとバイナリーは、ソース環境ではなく新しくマイグレーションされた開発サーバー (サーバーが実稼働状態になった後) からコピーされます。ユーザー・ホーム・ディレクトリーは、非本番環境の場合と同じく、対応する本番ソース・サーバーからコピーされます。

マイグレーション・タスク (本番環境と非本番環境の両方に該当):

これは、実際のマイグレーション・タスクが行われるメインのフェーズです。このフェーズでは、DB2、Lotus Domino、または WebSphere MQ などの各種ソフトウェア分野のそれぞれのスペシャリストが、マイグレーション・プランで定義されているマイグレーション・タスクを実行します。

  • マイグレーション・エンジニアは、ターゲット環境でのアプリケーションのファイルシステムとパーミッションのセットアップが、ソース・サーバーでのセットアップと同じであることを確認する必要があります。その際に行われる重要な作業には以下のものがあります。
    • ユーザー・プロファイル、ログイン・シェルの設定
    • アプリケーション環境変数の設定
    • アプリケーション・スクリプト内にハード・コーディングされたパスの修正
  • 新しい環境にアプリケーションが正しくインストールされた後は、実現可能性の調査フェーズおよびユニット・テストの結果で判断されたアプリケーション・ソース・コードの修正を行います。コードを修正する主な理由は、以下のものが変更されたことによるものです。
    • オペレーティング・システム
    • コンパイラー
    • ソフトウェア・バージョン
    • UNIX シェル・スクリプト
  • 徹底的なユニット・テストを行った上で、ユーザー・アクセプタンス・テストを行うアプリケーション・チームに新しいサーバーを引き渡します。

注: コード修正と移植作業の量と複雑さは、本番環境ではほぼ問題になりません。なぜなら、作業の大部分は開発環境で完了しているためです。

システム結合テストおよびユーザー・アクセプタンス・テスト

マイグレーション作業が完了した時点で、新しい環境にイントールおよび移植されたアプリケーションは、クライアント・チームに引き渡され、検証と有効性の確認が行われることになります。このフェーズでは、クライアントのテスト・チームがアプリケーション・レベルのテストを行って、ビジネス機能が損なわれていないこと、そして満足できるパフォーマンス・レベルであることを確認します。このテスト期間中に、クライアント・チームが特定の問題やトラブルシューティングに関してマイグレーション・チームに相談することもあります。

テスト・フェーズで調整役を果たすのは、ウェーブ・プロジェクト・マネージャーまたはその任務を割り当てられたアセスメント・エンジニアです。調整役は、クライアント・チームと協力して以下の作業を行います。

  • クライアントのテスト・チームから毎日テストの進捗とアプリケーションの欠陥の状況に関する情報を集め、欠陥を解決する方法を提案して支援します。
  • 週に 1 度、テストのステータスをプロジェクト管理本部に報告します。
  • テストの依存関係、リスク、問題に関する支援を行います。

ただし、ウェーブ・プロジェクト・マネージャーまたは任命されたアセスメント・エンジニアはテストを実行したり、結果を検証したりすることはありません。これらのタスクを行うのは、一般にアプリケーション・テスト・チームの役目です。

本番環境のサーバーのカットオーバー

非本番環境の場合:

ユーザー・アクセプタンス・テストが完了すると、クライアント・チームが新しいサーバーを承認します。マイグレーション後のタスクでは、マイグレーションを支援するために一時的に新しいサーバーにインストールしたカスタム・スクリプトやファイルをすべて削除する必要があります。

本番環境の場合:

本番環境では、まったく新しいカットオーバー作業が開始されます。これには、ソース環境で本番サーバーをシャットダウンし、新しい環境で実稼働させる作業が含まれます。サーバーが稼働状態になるまではユーザーに影響を与えることから、アプリケーションのダウンタイムを最小限にするために、この作業はアプリケーションの保守時間枠内で週末に行われるのが通常です。

スプレッドシート・ベースのカットオーバー・プランは、以下のセクションで構成されます。

  • サーバー: カットオーバー対象の本番サーバーの名前が記載されます。
  • カットオーバー前: カットオーバー前に行うタスクが記載されます。これらのタスクには、ソース・サーバーをシャットダウンする準備、本番環境にインストールされているソフトウェアおよびアプリケーション・ファイルの最終確認、ソース環境でのデータベース・バックアップとターゲット環境でのリストア、URL 変更要求の実行依頼などのアクションがあります。
  • カットオーバー: カットオーバー・タスクが記載されます。ソース環境のアプリケーションとバッチ・ジョブの実際のシャットダウン・シーケンス、ターゲット環境でのこれらのアプリケーションとバッチ・ジョブの実行、URL/DNS の変更要求の実施、最終テストの実行、そして新しいシステムが使用できるようになったことについてのユーザーに対する通知といったタスクが含まれます。
  • カットオーバー後: カットオーバーの仕上げの作業が記載されます。これらのタスクで、アップストリーム/ダウンストリームの本番環境との変更の調整、残りの文書化タスクすべての完了に対処するとともに、新しい環境が安定するまで監視を行います。
  • ロールバック: プロビジョニングされた新しい環境の実稼働が開始された後に万が一失敗した場合には、前の環境に戻します。そのためのステップには、バックアウト・プロセスの開始、元の環境でのソフトウェアおよびアプリケーションの起動、バッチ・ジョブの実行、そして古いシステムを指す URL/DNS へのリダイレクトが含まれます。
  • 前提: カットオーバーに関する前提が記載されます。例えば、以下の前提があります。
    • データを移す前に、すべてのプログラム、スクリプト、テーブルがターゲット環境に揃っていること。
    • ターゲット環境で実稼働を開始するために必要なデータは、シャットダウンされたアプリケーションのデータのみであること。
    • すべてのテストが完了して、ターゲットへの再配置条件が満たされていること。
  • 連絡先の詳細: 切り替え作業に関与したすべての担当者の名前と連絡先詳細をリストにします。
  • 問題: (オプション) カットオーバー作業中に直面した問題または関連するコメントが記載されます。

本番環境と非本番環境の両方に共通:

ヘルス・チェック

アプリケーション・チームがアプリケーションでヘルス・チェックを行い、すべてが期待通りに機能していることを確認します。その後、イメージを実稼働に移す前に、インフラストラクチャー・チームがこれらのイメージで最終的なヘルス・チェックを行います。この作業には、セキュリティー・パッチ、監視作業、バックアップが用意されていることの確認が含まれます。関連するイメージの数によっては、作業に 2 日から 4 日かかる場合があるため、イメージ数に応じて作業時間を計画する必要があります。インフラストラクチャー・チームは、実稼働開始ミーティングでゴーサインを出して、ヘルス・チェック作業が完了していることを示さなければなりません。


実稼働開始後

サーバーが実稼働状態になった後、マイグレーション・チームは 2 つの最終ステップを行います。その 1 つは、保証期間としての作業、もう 1 つは古いサーバーの退避とデコミッショニングです。

カットオーバー後の保証

通常、ターゲット・サーバーが実稼働状態になった後は、マイグレーション・チームが新しい環境のパフォーマンスを監視して、問題の解決態勢を整えます。一般に 10 日間から 2 週間ほど続けられるこの監視期間は、保証期間と呼ばれます。保証期間中、クライアントはマイグレーション・チームのメンバーにあらゆる説明またはトラブルシューティングを要請することができます。保証期間が終了すると、クライアント・チームが保守およびサーバー維持の全責任を引き継ぎます。

退避およびデコミッショニングまたは用途変更

新しい非本番環境サーバーと本番環境サーバーがともに運用状態になり、事前定義された日数の間、重大な問題やダウンタイムが発生しなければ、古いサーバーが退避されて、デコミッショニングされるか、別の目的で使用されるようになります。


追跡

マイグレーション・プロセス全体をとおして、プロジェクトのフェーズと成果物を始めから終わりまで追跡することが必須です。このことから、通称テクニカル・ダッシュボード・チェックリスト (Technical Dashboard Checklist) と呼ばれる、Excel ベースのチェックリストを用意することをお勧めします。このチェックリストには、図 7 に示す項目が含まれます。

図 7. テクニカル・ダッシュボード・チェックリスト
マイグレーション中に追跡しなければならない項目が色分けして記載されたチェックリストの例

上記のテクニカル・ダッシュボード・チェックリストでは、「Item/Task (項目/タスク)」列にアクティビティーまたは成果物が記載されます。つまりここには、マイグレーション、カットオーバー、および他のプランでのタスクが記載されるということです。また、各タスクの所有者、完了予定日と完了日、そして完了状況も記載されます。マイグレーション・フェーズでは、マイグレーション・エンジニアが各就業日の終わりにこのチェックリストを更新して、それぞれのタスクと成果物の現状を反映することがベスト・プラクティスとなっています。色分け方式 (緑色、黄色、赤色) により、いつでもプロジェクトの正常性を視覚的に確認することができます。


まとめ

この記事では、アプリケーションのマイグレーションの概念について、マイグレーション作業の計画方法、準備方法、そして最終的な実施方法のガイドラインと併せて紹介しました。マイグレーションのすべてのフェーズ、主に必要となるアーキテクチャー上の決定事項、用意する作業成果物について正しく理解し、マイグレーション・プロセスに潜む落とし穴を避ける方法を学んでいただけたはずです。

参考文献

学ぶために

製品や技術を入手するために

  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Open source
ArticleID=829150
ArticleTitle=グリーン IT を促進する ― アプリケーションのマイグレーションおよびリホストの実用ガイド
publish-date=08092012