Power Virtual Serverのベスト・プラクティス 2025　～＜後編＞災対環境と開発・テスト・検証環境のベスト・プラクティス

災対環境のベスト・プラクティス

災対環境はPowerVSの特徴を踏まえたうえで、以下の点から運用管理面や費用面でとても相性がよい。

◎被災時にのみ必要となる環境要件に対して、クラウドはリソース変更が柔軟（仮想マシンの作成・削除が容易）であること。

◎平常時には利用せず、コストをかけたくないという災対環境ならではの要件に対して、クラウドは従量課金（使った分だけ費用が掛かる）であること。

これらの理由により、災対環境は本番環境とは異なり、多くの場合でクラウド利用が効果的である。

クラウドで災対環境を効果的に実現するソリューションに、「災対環境自動構築ソリューション」がある。本稿ではこの「災対環境自動構築ソリューション」を採用して、クラウドに災対環境を実装する。

災対環境でのPowerVSの利用に際しては、以下の要件・考慮事項が考えられる。

①　本番環境がオンプレミス、クラウド、ハイブリッドのいずれでも構成可能であること
②　被災時に本番環境を引き継ぐためのデータ同期が実現できること
③　被災時に環境を利用可能にするため、災対発動時に環境構築する仕組みがあること

ここからは、本番稼働のシステムがオンプレミスか、クラウドかの場合に分けてサンプル構成を提示し、本番環境の配置場所によらずPowerVSが利用できることを示す。

本番稼働のシステムがオンプレミスにある場合

図表8は、本番稼働のシステムがオンプレミスにある場合のPowerVSを利用したサンプル構成である。

図表8の縦の点線より左側にオンプレミスの本番環境、右側にクラウドの災対環境を表している（IBM Cloud上にあるサービスは災対環境構築の自動化の仕組みに関するもので、後述する）。

もし災対環境にIAサーバーが必要な場合も、図表8の青枠のように、IBM CloudのVirtual Private Cloud（以下、VPC）上で作成可能である。

同パターンのデータ同期方法の概要と構成のポイントを、図表9にまとめた。

1つ目は、IBM CloudのIBM Spectrum Virtualize for Public Cloud（以下、SV4PC）を利用したデータ同期である。

オンプレミスで利用するストレージがIBM FlashSystemシリーズである場合は、SV4PCとの間でGlobal Mirrorが実施可能である。これによって短いRPOが実現可能となる。災対サーバーへのリストアも、PowerVSで作成した仮想マシンに紐づくボリュームに対してデータコピーを実施することで災害発生時に復旧できる。

2つ目は、ISP＋ICOSを使ったバックアップによるデータ同期の実現である。本番環境と災対環境にISPサーバーがあれば、ICOSへのデータ転送によって、サイトが離れていてもデータの復旧が可能である。

ここではいずれもIBM Cloud、VPC、PowerVS、オンプレミス間で通信経路の構成が必要である。そのためTransit Gateway、Direct Link、Power Edge Routerを使って通信経路を構成する。

本番稼働のシステムがクラウドにある場合

図表10は、本番稼働のシステムがクラウドにある場合のPowerVSを利用した構成である。

図表10の縦の点線より左側にクラウドの本番環境、右側にクラウドの災対環境を表している。前述したのと同様に、IAサーバーも想定可能である（災対構築の自動化部分は後述する）。

データ同期は、図表11のように、PowerVS標準機能であるGlobal Replication Services（以下、GRS）を使ってサイト間のデータを非同期でコピーする。

データのリストア時には、ボリュームを被災時に構築した仮想マシンに取り付けて有効化することで復旧する。GRSの構成は4ステップで実施する。データ同期・復旧時の運用などは、「Power Virtual Server サイト間同期ソリューション」などを参照してほしい。

災対環境では、災対発動時に環境構築する仕組みが重要となる。「災対環境自動構築ソリューション」では、人手をなるべく介さずに自動化する、すなわち災対発動時の自動的な環境構築を実現している。図表12にその仕組みを示す。

ここでは、本番オンプレミス環境のOSなどの設定情報をansible playbook化してGitにアップロードしておき、それを使ってTerraformやAnsibleで災対環境を構築する。

また人手を介さずにこれらを実施するために、CI/CDパイプラインのJenkinsによって、サーバーのデプロイを自動化する。

この仕組みを実現するための実際の構成を、図表13に示す。

サンプルの構成は本番環境の配置によらず、IBM Cloudのサービスを使って実現可能である。まず、自動化環境のための仮想サーバーをVPC上に配置する。そしてIBM CloudのサービスとしてGitを利用する。IBM Cloudから見て、オンプレミスからの情報通信用経路や災対環境の構築先のPowerVSにつながる経路は、Transit Gatewayを使って構築しておく。

災対環境のベスト・プラクティスで求められる要件・考慮事項に対して、サンプル構成でのポイントをまとめると図表14のようになる。

開発・テスト・検証環境のベスト・プラクティス

開発・テスト・検証環境におけるPowerVSの利用は、その特徴から次のメリットが大きい

◎一時的に利用するサーバーが多い環境で、仮想マシンの作成・削除が簡単に実行できること。

◎ハードウェアの調達や基盤構築などに時間を要するのを避けたい、あるいはプロジェクトの初期から利用したいといった環境であれば、IaaSを利用して初期コストを抑えられること。

一方で、本番稼働環境と配置が異なると、場合によっては構成不一致により本番環境と同等のテストが困難であり、そもそも基盤側のパラメータ・チューニングやテストを実行できない点に注意が必要である。

これらを踏まえると、開発環境でのPowerVSの利用は、注意点について理解しつつ、プロジェクト初期での利用やPoCで検証環境が必要な場合にとても有効である。

開発・テスト・検証環境でのPowerVSの利用に際しては、以下の要件・考慮事項が考えられる。

①　環境の払い出しにかかる時間が短いこと、短時間で環境構築が可能であること
②　環境の拡張と縮小が容易であること

図表15は、開発環境でのサンプル構成である。

図表15の青枠は、ネットワーク構成で選択可能であることを示している。PowerVSではインターネットに直接アクセス可能なパブリック・ネットワーク・インターフェースと、閉じたプライベート・ネットワーク・インターフェースを選択可能である。

図表15では、プライベート・ネットワークを使ってインターネットまで接続する例として、VPC上に踏み台サーバーを立てて外部から接続する構成や、直接ユーザーの開発ネットワークにつなげるように構成可能であることを示している。

本番環境もクラウドで運用している場合や、PowerVCを採用している場合には、IBM Cloud上にObject Storageも構成することで、キャプチャー・イメージのエクスポートによるカスタム・イメージの移植を容易に実行できる。

図表16に、仮想インスタンスの利用開始までのクイックスタートについて記した。

ワークスペースや仮想インスタンスの作成は、GUIでフォームを入力することにより作成可能であり、削除もボタン1つでできる。よって、短時間で簡単に仮想マシンを作成・削除できる。

図表17に、拡張の容易性を記した。

PowerVSでは、データセンターで利用可能なリソースの上限までワークスペースに仮想マシンを構築できるうえ、データセンターあたりの利用上限を超えて一時的に環境を拡張したい場合にも、別ワークスペースを作成するなどして、別のデータセンターで対応が可能である。

環境縮小についても、ハードウェアなどの物理機器を考慮することなく環境の削除が可能である。

開発・テスト・検証環境のベスト・プラクティスで求められる要件・考慮事項に対して、サンプル構成でのポイントをまとめると、図表18のようになる。

以上述べてきた各環境のベスト・プラクティスをまとめると、図表19のようになる。

いずれの環境でも、PowerVSを利用する際には事前の試算や利用計画を十分に考慮することで、PowerVSの特徴を活かし、効果的に利用することが可能である。

本稿で紹介したのは現時点でのベスト・プラクティスであり、継続的な機能拡張が進むPowerVSでは今後さらによい使い方、優れた構成が実現することを期待したい。