MENU

ハイパーコンバージド・インフラ ~バックアップの視点で考えるメリットとデメリット

 
 

 

注目を集める
ハイパーコンバージド・インフラ

 
近年、ITインフラとしての仮想化環境が浸透し、多くの企業が利用している。そこでは導入・運用の簡便さから、サーバー内蔵ストレージを活用するハイパーコンバージド・インフラが注目されている。
 
 仮想化環境は従来、複数のサーバーと、それに外部接続される共有ストレージ装置を組み合わせて構築するのが一般的であった。ところが、ハイパーコンバージド・インフラは複数サーバーの内蔵ストレージをソフトウェアで束ね、これを共有ストレージとして利用する。
 
 そのため物理的なコンポーネントとしては、サーバーのみのシンプルな構成で構築できる。外部接続で使用していた共有ストレージ装置の機能をサーバーの内蔵ストレージに集約することで、サーバーと共有ストレージ装置を接続していたSAN(ストレージ・エリア・ネットワーク)や共有ストレージ装置に関する構築、設定、運用・監視が不要となる。
 
 このことからハイパーコンバージド・インフラは、導入や運用が簡便であるというイメージが広がり、利用が活発化している。
 
 しかしハイパーコンバージド・インフラでは、内蔵ストレージのみで構成されたシステムのデータ保護に目を向ける必要がある。そこで今回は、ハイパーコンバージド・インフラでのデータ保護方針やバックアップに関する課題点について解説する。
 

 

データ保護の課題

 
 
 一般的な外付けストレージ装置では通常、データ保護の方式としてRAIDが採用されている。データの保全性を考えた場合、1台のサーバーだけでデータを保存するのは不安である。外付けストレージ装置では制御装置が通常2台以上装備されているが、単体サーバーではHDD障害、サーバー障害などでデータを失う可能性がある。
 
 そこでデータの信頼性を確保するため、1つのデータに対する書き込み要求をソフトウェアにより複数のサーバー間で2重化、3重化して保存することで、最新データを冗長化し保護する。この方式により、ハードウェア障害によるサーバーダウンが万一発生しても、残ったサーバーにミラーリングされたデータコピーがあるので、システムを復旧できる。「これでデータの保全性は保たれる」と、安堵するユーザーは多いだろう。
 
 しかし、このような運用形態で本当にデータの可用性は保たれるのだろうか。たとえばハイパーコンバージド・インフラでは、データのバックアップは不要なのだろうか。答えはノーだ。いくら2重、3重にミラーリングしたとしても、操作ミスによる誤ったデータの削除、アプリケーションのロジックエラー、パラメータの設定ミス、システムへのパッチ適用の失敗といった論理的エラーに対しては、残念ながらどんなに多重化した書き込みでも対応できない。
 
 当たり前だが、ミラーリングにより多重化されたデータはすべて同時に削除されたり、変更されたりして、誤った操作を素直に反映してしまう。これはミラーリングの正常な動作なので、元には戻せない。このような状況に対応するには、最新以外のある時点のデータや、システム単位での静止状態をバックアップ・コピーとして別立てで保存する必要がある。
 

 

バックアップの課題

 
 データのミラーリングによる冗長化を採用しているハイパーコンバージド・インフラでも、バックアップは重要であるとわかったところで、実際のバックアップ取得に関するいくつかの課題について順に解説していこう。

 

課題点1 本番データとバックアップ・データの混在
 
 
 ハイパーコンバージド・インフラでは一般に、内蔵ストレージであるSSD(Solid State Drive)やHDD(Hard Disk Drive)を共有のストレージ・プールとしてまとめ、論理的に分割し、分割されたストレージ領域を各仮想区画(ゲストOS、VMなど)に割り当てる。これはバックアップの保存先についても同様である。
 
 したがって、細かな配置を考慮せずにストレージ領域を割り当てると、仮想区画の本番データとそのバックアップ・データが、同一のSSDまたはHDDに混在して保存されることになる。これはバックアップの本質的かつ重大な問題となる。単一のHDD障害であっても、そのHDD上の本番データとバックアップ・データが同時に失われる可能性があるからだ。これでは、バックアップを取得した意味がない(図表1)。 
 
 

 

 しかしハイパーコンバージド・インフラでは複数サーバーへミラーリングすることでデータを冗長化しているので、このようなケースでも、単一のHDD障害やサーバー障害によるデータ消失の危機を回避できる。
 
 ただしこの場合、バックアップ・データも同様にミラーリングされることになる。これにより、バックアップ・データでありながら、ミラーリングによる2重化、3重化により、2倍、3倍のストレージ領域を消費する。これは限られた容量しか実装できないサーバー内蔵ストレージ環境では、大きな問題であると言える。

 

課題点2  肥大するバックアップ・データ領域
 
 単一の共有ストレージ領域に本番データとバックアップ・データを混在して保存する場合の課題点は前述のとおりである。ここに問題があることは、バックアップ取得を本気で考えたことのある人なら容易に推察できるだろう。
 
 解決策として思いつくのは、本番用 HDD/SSD とバックアップ用HDD/SSDを恣意的に分けることである。しかし、この場合も課題は残る。
 
 問題を理解するために、ここで本番データとバックアップ・データでは、どちらの容量が多いかを考えてみよう。単純に考えれば、バックアップ・データは本番データのコピーなので、最低でも同じ容量が必要なことはわかる。しかし、これでは不十分である。通常、バックアップは複数世代を保管するからだ。
 
 たとえば1世代(コピー)分しかバックアップをとっていない場合、次にバックアップを取得しようとすると、以前保持していたバックアップ・コピーに上書きすることになる。ちょうど上書きしている最中にデータへのダメージが発生した場合、本番データとバックアップ・データを同時に失う可能性がある。
 
 このため、複数世代を保持することが必要になる。保管世代数や保管パターンによってバックアップ容量は大きく変わる。世代管理は最低でも3世代以上、できれば1週間分(7世代)はとっておきたい。重複削減や差分バックアップなど各種のデータ削減テクニックを使ったとしても、バックアップの容量は少なくとも本番容量の2?3倍程度を用意するのが一般的である。
 
 つまり、同じHDD/SSDに本番データとバックアップ・データを混在させたくないと考えた場合、本番データを保存するHDD/SSDとバックアップ・データの保管用 HDD/SSD を互いに分離して、割り当てることになる。
 
 しかし、一般的によく使われる2Uサイズのサーバーの場合、内蔵ストレージとして搭載可能なHDD/SSDの数は、3.5インチであれば12個、2.5インチにしても24個である。本番データの容量「1」に対し、バックアップ・データの容量を非常に低く見積もって「2」と仮定する。たとえば同容量のHDDを使うとして、3.5インチで12本入る構成なら本番データ用に4本、バックアップ・データ用に8本使うことになる。
 
 賢明なユーザーなら、ここでの問題に気づくだろう。本番データ用はたった4本なのに、バックアップ・データには8本も HDD を占有するわけだ。本番を4本のHDDで処理せねばならないので、容量の問題にとどまらず、本番のパフォーマンスにも影響が生じる(図表2)

 

 

 

 このように、内蔵ストレージだけで構成された仮想化環境であるハイパーコンバージド・インフラでうまく、そして効率的にバックアップするのは意外に難しい。
 
 しかし、解決するのは簡単だ。バックアップは内蔵ストレージではなく、外部のストレージ装置にとればよい。これにより、確実に本番データとバックアップ・データを分離できる。無駄にバックアップ・データをミラーリングする必要もない。本番システムは、サーバーの内蔵ストレージをフルに利用できる(図表3)

 

【図表3】バックアップ用ストレージ

 

 簡便性重視で外部接続の共有ストレージ装置を外してはみたものの、データ保護に問題があっては本末顛倒である。たとえばiSCSI接続のバックアップ用ストレージ装置があれば、合理的にバックアップを取得できるうえ、各種リカバリー・シナリオを考えるうえでも大変便利である。
 

 

仮想化環境に特化した
バックアップ・ツール

 
 
 次に、バックアップ・ツールについて考えてみよう。
 
 確かにITインフラとして仮想化環境が浸透してきたとは言え、多くは個別のサーバーで稼働していたシステムを仮想化環境へ統合した段階にある。稼働しているOSやアプリケーションは従来のまま、バックアップについても従来のバックアップ・ツールを使用しているケースが多い。
 
 仮想化環境に統合されたものの、個々のシステムの運用は以前と変わらず、バックアップについても設定がバラバラで、頻度や取得のタイミングもまちまちの状況である。個別にバックアップ・ツールを使用している限り、新規に仮想区画を作成しても、そこで稼働するシステムごとにバックアップ・ツールのエージェントを導入し、設定する作業が必要となる。こうしたバックアップ課題の解決に向けては、仮想化環境に特化したバックアップ・ツールが求められる。
 
 そこで、仮想化環境向けの新しいバックアップ・ツールとして登場したのが、「IBM Spectrum Protect Plus」である。IBMのバックアップ・ソリューションと言えば、「IBM Spectrum Protect」(旧TSM)が思い当たる。しかし名称は似ていても、IBM Spectrum Protect Plusはまったくの別製品であり、仮想化環境のバックアップに特化したソリューションとして新たに設計されている(図表4)

 

 

 IBM Spectrum Protect Plusに、バックアップ先として外付けストレージ装置を採用することで、仮想区画ごとの個別対応によるバックアップ運用の負荷を削減し、仮想化環境全体の整合性を備えたバックアップ運用と柔軟なリカバリーによる復旧シナリオを実現できる。
 
 仮想化環境がITインフラとして浸透するなか、今後も多くの企業がハイパーコンバージド・インフラを導入するだろう。ハイパーコンバージド・インフラで見落としがちなデータ保護方式、バックアップ運用の検討に本稿が少しでも参考になれば幸いである。

 


著者

髙井 泰成 氏

1990年に日本IBM入社。以来、メインフレーム向けストレージ製品の製品サポートを担当。とくにテープ・ライブラリに関する米IBM発行の技術ガイド「Redbook」の執筆に携わるなど、テープ製品のスペシャリストとして活動。2007年よりテクニカル・セールスとして、ストレージ製品全般の製品サポートおよびプリセールス活動の支援を行っている。

 

 
 
 
 

新着