［プライベートクラウド編］既存のバックアップ方式を踏襲してはいけない

　プライベートクラウドの設計の際に、サーバーの集約率やストレージの容量についてはきちんと検討される。しかしバックアップ方式については深く検討されず、既存のやり方をそのまま移行するという方針で進められてしまうことが少なくない。だが、既存のバックアップ方式をそのまま踏襲してはいけない。

　既存のシステムをプライベートクラウドへ移行するとき、多くの場合はコスト削減が主要な目的となる。そのため移行方針の検討では、多数のサーバーを何台に集約できるか、という指標に注目しがちだ。またバックアップに関しては、バックアップツールがオンラインバックアップをうたい文句にしているものもあり、それを使えば今よりも楽になる、とうのみにして検討をないがしろにしてしまうのである。

　また、移行に際して、バックアップに関するサービスレベルの低下に抵抗があることも多い。既存のバックアップウィンドウ（バックアップに利用できる時間）やRTO（Recovery Time Objective：目標復旧時間）、RPO（Recovery Point Objective：目標復旧時点）を変更することが困難で、移行をスムーズに進めるために既存のバックアップ方式を踏襲するという方針にせざるを得ない場合もある。

物理テープではクラウドの拡張に追随できない

　しかし、移行元のサーバーが個別にテープを用意してバックアップするという仕組みを採っている場合、物理テープをサポートしていない仮想化環境では個別にテープを用意することができない。そのため、移行先では統合されたバックアップの仕組みを検討する必要がある（図1）。

図1●クラウド移行時にはバックアップ方式を変更する

　その際、従来型の物理テープを使った手法にすると、バックアップジョブの並列実行の多重度がテープドライブ数に制約され、多数のサーバーがクラウド基盤に乗ってきた際にバックアップウィンドウの融通などが難しくなる。テープドライブには拡張性に限界があることが多いため、将来的なクラウド環境全体の拡張に追随できないこともあるのだ。

　バックアップツールについても見直しは必要である。単一サーバーのバックアップを取るのに最適なツールであっても、プライベートクラウドの環境ではバックアップ対象が多くなるため、運用に制約が出る場合がある。例えば、ツールによっては、バックアップジョブの並列実行が不可能であったり、管理できるバックアップ機器やバックアップ対象の数が少ないものもあったりする。

　オンラインでのバックアップについても、仮想環境ではWindows OSのVSS（Volume Shadow Copy Service）と連携させることが多い。既存のアプリケーションやOSがVSSに対応していない場合には、移行後もオンラインでバックアップを取得することはできない。

メンテナンス時間の調整が不可欠

　クラウド環境のバックアップでは、機器のメンテナンスのこともきちんと考慮しておく必要がある。

　クラウドへの移行前の運用がサーバーごとの個別対応だった場合、サーバーなどの機器のメンテナンス時は、その機器に関係するシステムだけを考慮して、メンテナンス時間を調整すればよい。しかしクラウド環境にサーバーを統合した場合、複数システムで機器を共有するので、その機器を使用するすべてのシステムについて調整が必要となる。

　そのため、移行後のサービスレベルで保証するバックアップ取得時間が、あるシステムは平日夜で、あるシステムは昼で、あるシステムは日曜日で、というようにまちまちであると、バックアップの稼働時間もまちまちになり、機器メンテナンスの制約になる。停止調整などの運用負荷も増加するので、結果的にサーバーのコストは低下しても運用コストが増加する事態も考えられる。

　つまり、プライベートクラウドへのサーバー統合のプロジェクトは、運用も含めたプロジェクトと考えるべきで、単純なサーバーのみの統合プロジェクトと考えるべきではないのだ。

　そして、バックアップに関する運用方式は、バックアップ機器のサイジングに大きく影響する。バックアップに使用する機器はサーバーに比べると比較的高価であり、サーバー統合に伴うコスト効果を減じる可能性もあるため、きちんと検討を行う必要がある。

最終的なシステム規模を意識して方式を決める

　クラウド移行時の問題を解決する方法としては、ドライブ数の制約の少ない仮想テープライブラリを使用することや、コストの安いNAS（Network Attached Storage）を用意して、そこにユーザーがセルフサービスでバックアップデータを配置するような仕組みに変更することが考えられる。その際は、システムごとのサービスレベルを整理して全体の停止時間を確保し、運用時間がまちまちにならないようにすることが望ましい。

　サービスレベルの見直しをユーザーが受け入れがたいような場合には、バックアップウィンドウなどの制約が少ない、ストレージ自体のコピー機能を用いたバックアップといったサービスメニューを用意することも考えられる。ただし、ディスクのコストが余分にかかるため、課金するコストを変えることなどを検討すべきだろう。

　またバックアップツールは、ある程度の規模が見込める場合は大規模環境向けのツールを利用することが望ましい。「Symantec NetBackup」や「HP DataProtector」など大規模環境向けのツールは、バックアップ対象とバックアップ機器を操作するサーバー、バックアップジョブの情報を管理するサーバーを分けて拡張可能な構成となっているからだ。これによって、段階的に拡張しながら、バックアップジョブを一元管理することができる。

　小規模環境向けのツールを導入した後で大規模環境向けのツールに直接バックアップジョブを移行することはできないため、事前に最終的な構成を意識して検討する必要がある。小規模環境向けのツールを使い続ける場合も、何台ごとにバックアップサーバーを追加するか、などのポリシーをあらかじめ決めておき、コスト計画に含めておくとよい。