企業や組織のITは、その多くが仮想化基盤上で展開されており、その範囲は、オンプレミスにとどまらずクラウドにまで広がっています。データやアプリケーションが増大を続ける中、こうした環境の中核となるのがハイパーコンバージドインフラストラクチャ(HCI)です。そして、HCIやそこで動作する仮想化基盤の運用上、避けて通ることができないのがバックアップやディザスタ・リカバリ(Disaster Recovery : 災害対策。以下、DR)。そこで今回は、NutanixのHCIにおけるバックアップとDRについて、選択肢と選定基準を解説します。
関連記事:
- ハードウェア観点でのNutanixのHCI
- Nutanixのコンセプトを体現したハイパーバイザー「Nutanix AHV」とは
- ハイパーコンバージドインフラストラクチャ(HCI)とは
- HCIのメリット・デメリット、そしてNutanixの強みとは
◎HCIによるシンプル化はバックアップにもおよぶ
HCIは、SDS(Software Defined Storage : ソフトウェアによって定義されたストレージ)を用いてx86サーバーにコンピューティング機能とストレージ機能を統合した仮想化基盤で、サーバー・SAN・共有ストレージ装置を組み合わせた3Tier構成に比べて、設計・構築・運用管理などあらゆる側面でシンプルであることが最大の特長です。
HCIは、可用性の担保をソフトウェア制御で行っている、というのは前回のコラムで紹介しましたが、数あるHCIの中でも分散アーキテクチャによる優れた自己回復力を持つNutanixにおいてもバックアップやDRは重要です。
Nutanixは標準でスナップショットや遠隔レプリケーションの機能を提供しており、バックアップやDR環境の構築、運用を大幅にシンプル化できます。また、3rd partyのバックアップ製品と連携することもできますので、今回は「どのような機能があり」、「どんな場面で活用できるのか」について紹介します。
◎なぜNutanixにおいてもバックアップ&DRが必要なのか?
「RAIDによるデータ冗長化とバックアップは違う!」という話をよく聞くと思いますが、Nutanixの分散アーキテクチャによるデータ冗長化もバックアップとは違います。なぜなら、データ冗長化とバックアップでは、データを保護できる範囲が異なるからです。例えば、人為的なオペレーションミスやアプリケーションの問題などで、誤ったデータの書き込み処理が実行された場合、データ冗長化処理では誤ったデータをリアルタイムに冗長化してしまうため、正しいデータへの回復作業ができません。そもそも、データ冗長化の真の目的は「データ保護」というよりも、ディスクの故障が発生した場合においてダウンタイムなく処理を続ける「可用性の担保」のための仕組みだからです。逆に、データの冗長化を行わずにバックアップだけ取得していた場合、ディスク故障などが発生したときには、故障したディスクの交換やデータのリストアを行わないと業務再開できませんし、最後にバックアップを取得した時点から故障発生時点までのデータは失われてしまいます。ですから、データの冗長化とバックアップは「そもそも別のもの」であり、「どちらも必要」と言えます。
◎バックアップ&DRの検討事項
バックアップやDRがその真価を発揮するのは、何らかの問題が発生したときであるため、その問題を想定して、適切な対応策を講じておくことが重要です。下図は、バックアップやDRを行う上での主なポイントを項目別にまとめたものです。
これらの各項目に対して「絶対に順守する条件」と「できれば実現したいが、妥協できる条件」を明確に区別しながら優先度を決めて、実際の手段を選択することになります。「RPOが0で、RTOも極めて短く、かつ、あらゆる範囲の障害に対応でき、運用も簡単で、安価」などという都合のいい選択肢は存在しませんので、バランスが重要です。
◎ハイパーバイザーレベルよりも優れた、ストレージレベルでのスナップショット機能
仮想化環境において気軽に使われがちなハイパーバイザーのスナップショット機能ですが、残念ながら、実は運用においてあまり多用すべきものではありません。一例として、Nutanixと組み合わせて利用されることも多い、VMware ESXiのスナップショット運用に関するベストプラクティス(Best practices for using snapshots in the vSphere environment (1025279) - https://kb.vmware.com/s/article/1025279)から引用します。
- Do not use snapshots as backups.
「スナップショットをバックアップとして使わないこと」
- Maximum of 32 snapshots are supported in a chain. However, for a better performance use only 2 to 3 snapshots.
「32世代のスナップショットがサポートされているが、パフォーマンスを考慮し2-3世代までにすること」 - Do not use a single snapshot for more than 72 hours.
「1つのスナップショットを72時間以上利用しないこと」 (ストレージの容量圧迫やパフォーマンス低下を招くため)
これらの推奨事項の理由となるアーキテクチャ上での課題は、ここでは深堀りしませんが、結論として、ハイパーバイザーのスナップショット機能は、一時的に利用するためのもので、実運用の環境で多用すべきではありません。
一方、Nutanixのスナップショット機能は、ハイパーバイザーレベルの処理ではなく、分散ファイルシステムレベルでの処理を行い、「ブロックマップ」と呼ばれる「データの実体が、どこに存在するかという位置情報」を制御するのみで、スナップショットを作成できるようになっています。ブロックマップは、スナップショットではない通常のデータにも元々存在する管理情報ですので、スナップショットを作成していても、作成前と同等のパフォーマンスが得られ、安心して利用できます。
◎使い勝手のいいローカルスナップショットと非同期レプリケーション
Nutanixにおいては、前述の仕組みを用いて単一Nutanixクラスター内でのローカルスナップショット、およびほかのNutanixクラスターへの非同期レプリケーションが標準で提供されています。Nutanixクラスター全体・ラック全体・データセンター全体などの広範囲の障害に備えるには、リモートスナップショットが有効です。もちろん、レプリケーション先のNutanixクラスターでも仮想マシンを起動することができますので、単なるバックアップではなく、RTOの短い DR環境が構成可能です。
なお、この仕組みによるスナップショットとリモートレプリケーションは、非同期で処理され、最短で60分間隔での取得が実現できます。アプリケーションの整合性の担保や、ゲストOS管理者の権限によるファイル単位リストアなどの機能、多拠点間でのレプリケーション構成なども可能ですので、RPOさえ要件を満たしていれば非常に使い勝手のいい、Nutanix環境で第一の選択肢となり得るバックアップ&DR機能です。
リモートクラスターとの通信については、2回目以降のレプリケーション処理では「差分のみを転送する」、「転送時にデータを圧縮する」、「転送用の帯域幅を制限する」、「帯域制限を曜日や時間帯で変更する」といった機能も備えているため、ネットワークの利用状況を考慮した構成が可能です。(※これらのネットワーク関連機能は、次章の準同期、および同期レプリケーションでも共通で利用可能です)
他拠点間での非同期レプリケーション
◎より短いRPOを実現する準同期、および同期レプリケーション
非同期レプリケーションがRPO要件を満たさない場合の選択肢として、Nutanixは準同期および同期でのレプリケーションも提供しています。準同期は、非同期ではありますがRPOを1分まで短縮できます。また、完全同期ではRPOゼロを実現できます。ただし、これらはアプリケーションの整合性の担保、ファイル単位リストア、多拠点間でのレプリケーション構成などの機能がRPOの短縮とトレードオフになっています、また、同期レプリケーションは、データ書き込みの際、対向のサイトにまでデータのレプリカが書かれたことを以て書き込み完了と見なすため、ネットワークの遅延が性能に影響します。そのため、RTT(Round Trip Time: パケットの往復に要する時間)が5ms以下であることが要件となっています。非同期レプリケーションとの併用も可能ですので、制約事項を鑑み、本当にRPOの60分未満への短縮が必須なVMに対してピンポイントで利用しましょう。
◎さらなる柔軟性を求める場合には、3rd partyのバックアップ製品を活用
Nutanixのスナップショット機能および非同期・準同期・同期リモートレプリケーション機能を用いたバックアップ&DR以外に、さらなる柔軟性を求める場合には3rd partyのバックアップ製品を活用することも可能です。ここでいう柔軟性とは具体的には次のような要件がある場合です。
- テープライブラリやNAS、オブジェクトストレージなどの外部デバイスに、データを保管したい
- Nutanix以外の環境のバックアップも、一元的に行いたい
- アプリケーション視点でのリストアを行いたい
- パブリッククラウドなど、Nutanix環境以外へのリストアを行いたい
- バックアップデータとアーカイブ(長期保管)データを、別々のストレージに保管したい
あくまでNutanixの外の仕組みによるバックアップなので、Nutanixのリモートレプリケーション機能のように、データの保管先で即座に仮想マシンを起動できるわけではないためRTOに注意が必要ですが、これらの機能が優先されるケースもあるでしょう。
「Nutanix環境におけるバックアップ製品には、従来のストレージを利用していたときとは違う、何か特殊なものが必要なのではないか?」と思われることもあるのですが、実際には、そんなことはありません。ハイパーバイザーから見たときに、従来型ストレージとは異なるタイプのものとして認識されるHCIも存在しますが、Nutanixに関しては、vSphere環境であれば、NFSデータストアとして、Hyper-V環境であればSMB 3.0ファイルストレージとして振舞います。よって、それぞれのハイパーバイザーに対応済みのバックアップ製品であれば従来と何ら変わりなく利用可能です。つまり、3rd partyのバックアップ製品は「ハイパーバイザーに合わせて」選択するのが正解です。
1点だけ従来と異なるのは、Nutanixには、AHVという独自のハイパーバイザーが存在することです。AHVを利用する場合には、AHVに対応したバックアップ製品を選択してください。Nutanixは、バックアップベンダー各社と協業を進めており、本稿の執筆時点でVeeam・HYCU・Veritas・Arcserve・Commvault・Rublik・Zertoなどの製品がAHV対応認定を取得済みです。
◎3rd partyバックアップ製品を、よりシンプルかつ強力なものにする Nutanix Mine
3rd partyのバックアップ製品を利用する際の課題として、次のような点があります。
- バックアップ製品のコンポーネントを設計・構築する手間がかかる
- バックアップデータの保管先ストレージが遅いと、リストアに要する時間も増大してしまい、想定したRTOを守れない
これらを解消する手段としてNutanixが提供しているのが、「Nutanix Mine」です。Mineは、Nutanixとバックアップベンダーの提携により開発された、NutanixのHCIをベースにしたバックアップアプライアンス製品です。本稿執筆時点で対応済みなのはVeeamとHYCUの2社で、NutanixのHCI上に対応バックアップ製品がセットアップ済みの状態で提供されます。これにより、設計や構築の手間がなく、すぐにバックアップの設定が開始できます。また、データ保管先となるストレージもNutanixのHCIに準じた、高いパフォーマンスとスケーラビリティがあり、RTOの短縮にも効果的です。当然ながら、各バックアップ製品の持つ柔軟な機能がそのまま利用できますし、Mine向けのユーザーインターフェースの統合も行われているため、3rd partyバックアップ製品が必要な場面では有力な選択肢となるでしょう。
Nutanix Mine
◎NutanixがDR環境をクラウドサービスとして提供する「Xi Leap」
最後にもう1つ、Nutanixならではのものを紹介します。これまで紹介したバックアップ&DRの手段は、オンプレミスで利用するものでしたが、NutanixはDisaster Recovery as a ServiceであるXi Leapを提供しています。クラウドサービスであるため、オンプレミスでDR用のクラスターを導入する場合と比べると、構築不要で利用できることに加え、利用リソース量とサービスレベルをベースとした課金体系により初期投資を抑えることが可能となっています。
Xi Leapでは、Nutanixが機器やセキュリティを管理するDR用の環境と、オンプレミスのNutanixクラスターとの間で非同期レプリケーションを行えます。オンプレミスの環境がダウンした際には、Xi Leapのデータセンターで仮想マシンを稼働させることが可能です。オンプレミス側の環境は、NutanixのHCIを利用していれば、Nutanix AHVだけでなくVMware vSphereでも問題ありません。
また、「リカバリープラン」という設定によって、仮想マシンのリカバリー順序や、フェイルオーバー先でのIPアドレスの割当、フェイルオーバー&フェイルバック試験用の隔離VLANなどを構成でき、DRのオペレーションに掛かる負担を軽減できます。(※この機能はオンプレミス環境でも利用可能です)
Xi Leapは米国・英国・イタリアでサービスを開始しており、まもなく日本でもサービスを開始します(本稿執筆時点の情報に基づいています)。
まとめ
ここでは、Nutanix環境におけるバックアップとDRの選択肢と選定基準について解説しましたが、これらはどれか1つを選ぶ必要はなく、複数を組み合わせることも可能です。あまりたくさんの種類を組み合わせて複雑化するのは避けるべきですが、1つの手段であらゆる要件を満たすというのも現実的ではありませんので、業務観点、アプリケーション観点での要件を確認し、バランスの取れたRPO・RTOを計画することが重要です。
次のコラムでは、NutanixのHCIにおける「構成」という観点でのシンプルさと柔軟性について掘り下げていきたいと思います。