Power Virtual Serverの構築　～オンプレミスIBM iのリフトアップ事例より

text：山浦 政弘＊、中村 陽一、中村 悟、岩崎 一弘＊　日本IBM  （＊は9月からキンドリルジャパン）

 

2020年秋に東京リージョンで正式リリースしたIBM CloudでのPower Virtual Serverは、2021年春には大阪リージョンでも利用が開始されました。これにより日本でも、徐々に利用するユーザーが増えています。

今回は、実際にIBM iを利用する企業のサーバーをPower Virtual Server上に構築した事例・経験談をご紹介しましょう。

Power Virtual Server について　

Power Virtual Server はその名のとおり、IBM Cloud上でPower SystemのIaaSを提供するサービスです。

Power Systemで稼働するIBM i、AIXおよびLinuxが稼働する環境を提供します。現在、Power Virtual Serverは世界7カ国、13データセンターでサービスを提供しています。日本では前述したとおり、東京と大阪の2カ所で稼働しています。

2021年の春に大阪リージョンでのPower Virtual Serverの正式リリースあたりから、徐々に利用するユーザーが増えています。最初はPoC（試験的な利用）が多かったですが、現在は本番業務での利用の検討や構築が本格化しています。

Power Virtual Serverを構成する要素　

Power Virtual Serverは、IBM Cloudのデータセンター内にありますが、IBM Cloudのx86サーバー群とは独立した環境に構築されています。

従来からあるIBM Cloudのx86サーバー群のエリアを「クラシックエリア（環境）」、Power Virtual Serverのエリアを「コロケ（Co-location）エリア（環境）」と呼んだりしています。双方のエリアのプライベートネットワーク間は、Direct Linkで結ばれています。

Power Virtual Serverを利用する場合、Power Systemの仮想サーバーを構築するだけではオンプレミスで稼働しているサーバーの代わりにはなりません。ネットワークやクラシック環境にもサーバーなどを準備して接続する必要があります。

・ユーザーのネットワークとIBM Cloudを接続するネットワーク
・クラシック環境（VRA、Reverse Proxy、ICOS）
・クラシック環境とコロケ環境を接続する環境

ユーザーのネットワーク（WAN）とIBM Cloudを接続し、Power Virtual Serverを利用する方法は下記の例があります。これらの接続方法から、業務に即した接続方法を検討して実装する必要があります。

1　パブリック接続（インターネット接続）
2　SSL-VPN
3　IP Sec VPN
4　専用線直接接続（GRE トンネル／NAT）
5　Megaportサービス（現在日本では大阪リージョンのみ利用可能）

プライベート接続かつ専用線接続でユーザーのネットワークとIBM Cloudを接続する場合、VRAが必要になります。

また、Power Virtual Serverはテープライブラリー／ドライブをサポートしていません。バックアップデータを保管しておくには、オブジェクトストレージ（ICOS）を利用する必要があります。

Power Virtual ServerからICOSを利用するには、クラシック環境にReverse Proxy Serverを構築するか、VRAによるルーティング／NATの設定が必要です。

IBM iのシステムを構築した事例

実際に構築した構成図は、図表2のようになります。PoCの場合は期間限定利用ということもあり、ユーザーのネットワークとIBM Cloud間をWANベンダーのCloud Exchangeサービスを利用し、VRAでNATを設定することで、ユーザーのサーバーとPower Virtual Server間の通信を実現しました。

NATの場合、構築は容易ですが、通信対象が増えるたびにNATの設定が必要となり、管理が煩雑になります。そのため本利用時には、ユーザーのネットワークにルータを設置し、GREトンネルで構成するように変更しました。

周辺の環境構築には十分な設計・構築時間が必要

Power Virtual Serverの仮想サーバーのインスタンス（サービス）を開始するのは、IBM Cloudのアカウントがあれば、数分～数十分で立ち上げられます。

しかし、ユーザーがオンプレミス環境または自社のオフィスから使用可能にするには、接続するネットワークやクラシック環境を構築する必要があります。

そのための全体設計、回線や接続サービス、クラシック環境の準備・構築には十分な時間が必要です。裏を返せば、この周辺環境を作成してしまえば、Power SystemのIBM i／AIX／Lunix環境の増設・削除が容易になり、柔軟なシステム構成が可能になります。

ディスクの構成

Power Virtual ServerのIBM i でも、オンプレミス環境でのIBM i のディスク構成セオリーに従って構成することが重要です。

IBM i でのディスク構成セオリー

・ASPを構成するディスク装置のサイズは揃える
・ASPを構成するディスク装置本数は多いほうがよい

Power Virtual ServerのIBM i VSIのLSU (ロード・ソース・ユニット) は、80GBになっています。そのため、まずは80GBのボリュームを構成し、システムASPに追加して必要な容量を確保することが推奨されます。

必要な容量が数TBと大きくなる場合には、1ボリュームあたりの容量を200GB程度で、まとまった本数をシステムASPに追加するとよいでしょう。

その場合、LSUのみは80GBで、IBM i 7.3以降ではLSUを含むボリュームサイズの拡大がサポートされているので、サイズを揃えるようにしてください。

ただしPower Virtual Serverでサポートされている、それ以前のIBM i 7.1、7.2ではサイズがアンバランスになります。

システムASPにボリュームを追加したあとに、STRASPBAL OPTION(*ENDALC) UNIT(1) でLSUへのオブジェクト配置を止めて、STRASPBAL TYPE(*MOVDTA) TIMLMT(*NOMAX) でマイクロコード以外のオブジェクトはすべて追加構成したボリュームにバランシングさせることで、サイズ・アンバランスの影響を最低限に抑えられます。

オンプレミス環境のサーバーからPower Virtual Serverへのデータ移行

通常のオンプレミス環境のシステム移行であれば、物理テープを使うケースがほとんどです。しかしPower Virtual Serverには、物理テープドライブがサポートされていないので、代替方法を検討する必要があります。

最も簡単な方法としては、ディスク上に保管ファイル（SAVF）、または仮想テープイメージにより移行対象のライブラリー／オブジェクトのバックアップを取得して、FTPでPower Virtual Serverに転送して復元する方法があります。

この場合、オンプレミス環境に保管ファイルや仮想テープイメージをいったん保管するためのディスクの空き容量が必要になります。

今回経験したケースでは、ディスクに空き容量があったので、保管ファイルを取得するケースを選択しました。ただし、保管ファイルを極力小さくしようとSAVLIBコマンドの圧縮オプションを*HIGHにしたところ、サイズは低減できたものの、大容量のDBライブラリーの保管に11時間も要しました（約363GB→約93GBに圧縮）。

また圧縮率を上げたバックアップはCPUやメモリ資源が必要なので、業務で稼働しているシステムをックアップする際には注意が必要です。

移行データのバックアップ時にディスクの空き容量が足りない場合は、HABPソリューションツール（システムレプリケーションツール）の利用が考えられます。

このツールの利用により、移行対象のライブラリーやオブジェクトをオンプレミスからPower Virtual Server上にレプリケーション設定をして、コピーします。

主なレプリケーションツールは、送信先にライブラリーやオブジェクトがない場合、それを順番に保管→送信という操作を実行するので、少しずつ送信できます。

また送信が完了したあとも、業務稼働で変更があった部分は更新してくれるので、サービスイン／最終移行（オンプレミスからPower Virtual Serverへの切り替え）の際のデータ移行時間を最小化できます。

今回の構築経験では、ツールを使ってゼロからのデータ同期等をテストしましたが、初期同期では時間がかかるものの、問題なくデータ移行や同期ができることを確認しました。

IBM Cloudではほかにも、Mass Data Migration（大容量USBデバイス、以下MDM）といった大規模データの移行サービスもあります。しかしIBM iに関しては、MDMへのデータ保管の準備が簡単ではないことから、現時点では適用が難しいと思います。

バックアップの仕組みの構築が必要

ここまで何度か記載したように、Power Virtual Serverには物理テープライブラリー／ドライブがサポートされていません。

IBM iユーザーでは、9割以上がバックアップに物理テープを使用しています。よって代替のバックアップ方法を検討する必要があります。

これにはいくつかの方法が考えられますが、今回はIBMライセンスプログラムで実現できる「Backup Recovery Media Service」（以下、BRMS）、「IBM Cloud Storage Solution for IBM i」（以下、ICC）、「Object Storageサービス」（以下、ICOS)を組み合わせた代替バックアップ方法を構築しました。

BRMSは、Power Virtual ServerのインスタンスをIBM iで構築した場合には必ずライセンスプログラムが導入されています。

ICCについては、インスタンス構築時にソフトウェアオプションで導入を選択できるので、導入しておきます。

この方法でのバックアップでは、OSの仮想DVD／テープドライブ機能を利用して、システムやユーザーデータのバックアップを取得します。

取得後、バックアップイメージファイルを自動で圧縮してICOSに転送します。これによりICOSに転送したイメージファイルの世代管理を行えます。期限を過ぎたイメージファイルは自動的に削除します。

復元したいライブラリー／オブジェクトがある場合は、BRMSのメニューから復元したいデータのバックアップ日時と対象オブジェクトを選択すると、自動でICOSからPower Virtual Server上に対象のバックアップイメージをダウンロードしてデータを復元できます。

今回経験したケースでは、次のようにバックアップの要件を定義しました。

日次バックアップ：
バックアップ対象データは約500GB。7世代保管。1:00から毎日取得開始。

月次バックアップ：
システム全体のバックアップ（LIC／OSを含める）

◎バックアップイメージファイルの一時退避用にストレージを追加

・バックアップイメージに向けたストレージ領域を確保します。必要な容量を計算して、クラウドマネージメントコンソールからストレージを追加してASP2を作成します。

◎ICOSの準備 バケットの作成

◎Power Virtual ServerからICOSへの接続環境を設定

・ICCのコマンドまたはメニューから、Reverse Proxy経由のICOSへの接続を設定します。
・接続設定は、ユーザーデータバックアップ用に圧縮オプションを設定したものと、システムバックアップ用に非圧縮のものの双方を作成すると便利です。
・次のBRMSの初期化によって、作成したICCの接続定義と同名のBRMS媒体ポリシーが自動作成されるので、接続定義はバックアップ種別単位の種別名で(たとえば日次バックアップであればDAILYBKなど) 作成するとわかりやすいです。

◎BRMSの初期化→ICCの設定がOSやBRMS上に設定される

・BRMSとICCが導入された状態でBRMSの初期化（INZBRM *DATA）を実行すると、BRMSとICCの連携環境が自動設定されます。バックアップタスクの制御グループ／ポリシー、メディアポリシーなどが設定されます。システムバックアップ用のバックアップ制御グループは、非圧縮の接続定義に対してのみ自動作成されます。
　
◎ICCの設定を利用してバックアップを設定

・自動作成された媒体ポリシーに保管日数を指定するなど、初期化で作成されたポリシーや設定を取得したいバックアップに合わせて設定を実施します。

日次バックアップを実行すると、次のように動作します。

・30GBのテープイメージファイルが作成される（イメージファイル名は自動採番される）。またテープイメージファイルのサイズは、デフォルトではシステムの空き容量に合わせて自動的に決定されるが、データ域の作成で変更することも可能。
・システムバックアップでは、イメージファイルにデータがバックアップされる。
・30GBを超えたら、自動で次のテープイメージファイルが作成される。
・作成された30GBのイメージファイルをICOSに転送するジョブが作成され、ジョブ待ち行列に投入される。
・イメージファイル転送ジョブはイメージを圧縮して、ICOSに転送される。転送はバッチで行われる。転送バッチ・ジョブはサブシステムQICC/QICCSBSで動くので、事前にQICCSBSを開始しておく必要がある。
・作成されたテープイメージファイルは作成され次第、次々にICOSに転送される。

月次バックアップを実行すると、次のように動作します。

・システムバックアップ部分（SAVSYS）は、4.5GBのDVDイメージが作成される（イメージファイルは自動採番される）。
・4.5GBを超えたら、DVDイメージファイルが自動作成される。
・システムバックアップでは、イメージファイルにSAVSYSで取得されるデータがバックアップされる。
・データバックアップ部分は、30GBのテープイメージファイルが作成される（イメージファイルは自動採番される）。
・自動で30GBのテープイメージファイルが作成される。
・制限状態のため、イメージファイルの転送は行われないものの、JOBQ QICC/QICCJOBQに転送ジョブが投入された状態となる。保管完了後に制限状態を解除してQICCSBSを開始することで、転送が順次に実行される。

バックアップの実行　

バックアップの実行では、設定したバックアップ制御グループを実行します。制御グループに設定された順番で、バックアップが以下のように実行されます。

（1）　バックアップ前の処理の実行（制御グループに設定している場合）
（2）　30GBのバックアップイメージファイルが作成される。イメージファイル名はBRMSが自動採番
（3）　バックアップイメージファイルが仮想テープライブラリーにマウントされ、データ保管が実行される。
（4）　バックアップデータが30GBに達したら、自動で新たな30GBのイメージファイルが作成され、続けてデータ保管が実行される。
（5）　データの入った30GBのイメージファイルをICOSに転送するジョブがICCのサブシステムのジョブ待ち行列に登録される。
（6）　ICOSに転送するジョブがICCのサブシステム配下で実行される。イメージファイルは圧縮され、ICOSに転送される。

このようにして、物理テープと同様のバックアップが可能となります。

バックアップイメージファイルの管理は、BRMSで実行されます。イメージファイルのファイル名はランダムです。世代管理、データの復元などはBRMSのメニューから操作できます。

バックアップ実行時の注意点

実際に、上記のようにシステムを設定してバックアップを実行したところ、データバックアップ中やICOSへのデータ転送時にシステムに大きな負荷がかかりました。

これはデータバックアップ時およびICCによるICOS転送時のデータ圧縮処理が、Power SystemのCPUを使って実行されるためです。

物理テープの場合は、テープドライブのハードウェアで圧縮が行われます。災害対策（DR）機やテスト用のシステムでは、システム資源を最低限で割り当てるケースがありますが、この場合はバックアップに時間がかかる可能性があります。

私たちの経験したケースでは、CPU：0.25コア、メモリ：4GBの構成では物理テープの2倍程度の時間を要することになりました。

またシステムに高負荷状態が続き、ICOSへの転送でエラーになることがありました。よって、次のように対応することでICOSへの転送エラーを回避しました。

・ICCのサブシステムの同時実行ジョブ数は10から3に変更（省略値は10）
・バックアップ実行前にICCのジョブ待ち行列を保留にしておき、データバックアップが完了したあとに、ジョブ待ち行列を解放する制御を設定（これによりデータバックアップとICOSへの転送ジョブが同時並列に実行されないように制御）

これにより、ICOSへの転送でのエラーは発生しなくなりました。また、データバックアップ時間は物理テープと比較して「多少の時間増」程度に短縮でき、ICOSへのイメージファイル転送はその後、順次実施できました。

バックアップデータの復元

バックアップしたデータをイメージファイルから復元したいときは、BRMSのメニューから実行します。

復元メニューから復元したいライブラリー／オブジェクト、およびどの日時にバックアップされたものかを指定します。BRMSから行うことで、復元したいライブラリー／オブジェクトの入っているバックアップイメージファイルを自動で選択して、ICOSからダウンロードして復元します。

メニューから実行したあとICOSからダウンロードして復元しますので、復元作業にはある程度時間がかかります。

上記のように設定することで、物理テープドライブがない状況でも、今までと同様のバックアップ環境を構築できます。

ただしシステムバックアップからのシステムの復元は、少し複雑です。

最初に復元したいシステムとは別に、Power Virtual Server上にネットワーク・インストール・サーバーとしてのIBM i インスタンスを構成します。

このインスタンスに、ICOSからライセンス内部コードやOSベース部分などが含まれた仮想DVDイメージファイルをダウンロードし、ネットワーク・インストール用のイメージ・カタログとしてエクスポートします。

このイメージ・カタログからシステムを復元していく形式です。仮想DVDイメージからの復元が完了後、復元システムにICOSからユーザーデータなど、その他部分が含まれた仮想テープイメージファイルをダウンロードして復元していきます。

この手順はすべて、BRMSでのシステムバックアップを実行した際に作成できる回復報告書に記載されているので、バックアップ取得時には忘れずに回復報告書も出力し、復元に備えて保管しておきましょう。

システム全体のバックアップを取る方法としては、ディスクのスナップショットを取っておく方法もあります。

この場合、CHGASPACTコマンドでディスク内のデータの静止状態を作成したり、システムをシャットダウンしたりして、システムの静止点を取る必要があります。

スナップショットの取得はIBM Cloud CLI＋REST APIにて実行可能です。IBM CloudのWebに接続可能な環境からの実行が必要です。

一次言語が英語　

Power Virtual Serverは、ベースイメージが英語で作成されています。また、コンソール画面のコードページが37となっており、変更できません。そのため日本語DBCS (2962) を一次言語にすると、コンソール画面が文字化けします。

私たちが経験した環境では二次言語に日本語DBCSを導入して、システム環境を設定して利用しました。システム環境を設定する必要はありますが、業務影響はほとんどありませんでした。

なお、2021年第3四半期からはコンソール画面の日本語対応が予定されているので、一次言語を日本語DBCSにすることも可能になります。

システムのシリアル番号とソフトウェアのキー

Power Virtual Serverはインスタンスを構築したときに、マシンがアサインされます。その際にシステムのシリアル番号がわかるようになります。これはシステム値のQSRLNBRを参照することで確認できます。

またシステムをOFFにして再度起動すると、別のハードウェアで起動して、シリアル番号が変わる可能性があります。

主にベンダーが提供するパッケージソフトウェアには、シリアル番号からライセンスキーを作成して入力しないと動作しないものがあります。

そのため該当するソフトウェアを導入する必要がある場合は、シリアル番号が変わらないようにするために、インスタンス作成の際には、PINをハードウェアでロックの設定をしておく必要があります。

この設定を行うと、ハードウェア障害時に別のハードウェアでインスタンスを起動できず、ハードウェアの修復を待つことになります。よって、わずかではありますが可用性が落ちることが懸念されます。

このようにPower Virtual Serverの利用はとても簡単ですが、最初に利用する場合は以下の2点が課題になると思います。

・ネットワーク環境の構築（企業～クラウド間のネットワーク）
・オンプレミス環境からクラウド環境へのデータ移行方法

この点を解決できれば、Power Virtual Serverを気軽に利用できるようになります。

Power Virtual Serverは、日本での正式リリースから約1年になります。今後、次のような改善が予定されています。

・コンソールの日本語対応
・ソフトウェアベースの仮想テープライブラリー（VTL）の実装

オンプレミス環境に対するクラウドサービスの優位性は、ハードウェアやソフトウェアを初期に購入しなくてよい（初期投資が少ない）ことと、サーバー（システム）の調達時間が短く、短時間で構築できることです。

それに対して、共有部分も多いので保守などで意図しない期間に業務への影響が懸念されたり、長期間（3～5年以上）利用する場合はオンプレミス環境のほうがコストパフォーマンスに優れる場合もあります。

オンプレミス環境かクラウド環境かは、こうしたメリットとデメリットをよく検討した上で決定することが必要です。今回私たちが経験したように、テスト環境や災害対策環境では、クラウドの利用がメリットを感じやすいケースではないかと考えます。

 

◎参照資料
・技術よりな人が最初に読む「IBM Cloud柔らか層本」第3.1版
・IBM Could Storage Solution for IBM i V1.2.0 Users Guide
・IBM PowerVM Best Practices | IBM Redbooks

---

著者｜

山浦 政弘氏

日本アイ・ビー・エム株式会社（9月からキンドリルジャパン合同会社）
グローバルテクノロジーサービス事業部 ソリューション 第二サービスラインソリューション
シニアアーキテクト / TEC-J Steering Committeeメンバー

1988年に入社。CSRとして神奈川県のミッドレンジサーバーのハードウェア保守を担当。その後SEに転向し、Power System関連のインフラサービス、船舶ソリューション、災害対策などのレジリエンシー関連のサービスに従事。現在は、アーキテクトとしてインフラサービスのPre-Sales活動を中心に活動している。

中村 陽一氏

日本アイ・ビー・エム株式会社
IBMラボサービス　サーバー・ソリューション
シニアITスペシャリスト

2003年に日本アイ・ビー・エム システムズ・エンジニアリング入社。2004年よりIBM iを主たる技術エリアとして活動。2021年に現在の部門へ出向、主としてプロジェクト実施局面における技術支援を担当している。

中村 悟氏

日本アイ・ビー・エム株式会社
IBMラボサービス　サーバー・ソリューション
ITコンサルタント

1992年に入社。開発エンジニアとして大和事業所にてノートブック、プリンタ、ストレージ開発に従事。その後、IBMラボサービスに移動しPower Systems関連製品の設計・構築支援など、Post-Salesのデリバリーを中心に活動している。

 

岩崎 一弘氏

日本アイ・ビー・エム株式会社（9月からキンドリルジャパン合同会社）
グローバルテクノロジーサービス クラウドデリバリー 第9クラウドサービス
アドバイザリーITスペシャリスト

2003年に入社。入社以来、災害対策部門に所属し、主にIBM i関連のシステム構築、災害対策ソリューションの導入、災害対策システム運用に携わっている。