ストレージリソースとしての利用
まずは有事の際にストレージリソースとしての利用 じゃ。
ストレージリソースとしての利用ですか??
例えば障害によってデータが壊れた場合には
どう対処するのが一般的じゃ?
いくつか方法はありますが、大きく分けて2つあると考えています。
1つ目はデータをホスト側のサーバー側にリストアして利用します。
2つ目はバックアップソフトにもよりますが、インスタントリカバリなどの
機能があれば、そのままバックアップデータをマウントして利用します。
データの復旧方法その❶
バックアップデータをリストア
データの復旧方法その❷
インスタントリカバリ
リストアを完了しないと
データを起動できない
VMホストにバックアップデータ
をマウントさせて、インスタント
リカバリでデータを起動
リストアとインスタントリカバリの違いを動画の視聴に例えると…
DL完了してから視聴するか、
ストリーミング(DLしながら視聴)
するかの違いみたいなものですね。
てへへえ~
さすがじゃ。よく勉強しているな。
ただし後者のインスタントリカバリを利用する場合には、自分で用意したストレージがデータを払い出すだけのディスク I/O パフォーマンスが十分にあるかを計算するのが非常に難しい。
そもそも今までのバックアップ設計は基本的に"データを保存する場所"ということをメインに考えて、コスト的に安くなる様に設計をしているパターンが多い。
そのために、バックアップソフトウェア側にインスタントリカバリの機能を備えていても、データをマウントして利用する際にデータ転送速度が足りずに、仮想マシンがうまく起動できないなどの問題が起きてしまう事が多い。
安価なバックアップサーバーのインスタントリカバリ
バックアップサーバーの
リソースが足りないと、
うまくVMが立ち上がらない。
インスタントリカバリ中はバックアップイメージを読み込んでいるため、バックアップサーバーのディスクI/O領域にかなり負荷がかかる
一方でアプライアンス型はインスタントリカバリでの利用も想定に入れて設計されているモデルがほとんどである。特にスケールアウト型のノード数が多い場合には、十分なパフォーマンスが発揮できる仕様になっている。
またアプライアンスモデルの場合には管理画面上でソフトウェア的なバックアップの状況監視や設定だけでなく、その機器のつまりハードウェアのパフォーマンス状況をリアルタイムで見れるようになっているものもある。
よって緊急時にはそのハードウェアのパフォーマンス状況を見ながら必要最低限の仮想サーバーのみをインスタントリカバリでマウントして利用することが可能である。
アプライアンスのインスタントリカバリ
すぐにVMが立ち上がる。
I/Oパフォーマンスが高いだけでなく、
システムのパフォーマンスを確認できる。
そうか! アプライアンス型はバックアップソフトがハードと一体になっているのでバックアップ
サーバーのハードそのものの、パフォーマンス状況も見れるんですね。ここは大きな利点ですね。
あれ!? でも逆を言えば、普段はそのリソースを利用しないで置いておくということですよね。インスタントリカバリのためだけにリソースを余分に購入するのは少しもったいないですね。
いいところに目を付けたな。最近ではそのようなコンピュートリソースや
バックアップデータを保存しておくだけなのは非常にもったいないので、IOTなどの
データ分析、アプリ開発用のDBなどに再利用する動きがあるんじゃ。
開発側もサンプルデータでの開発ではなく、「直前まで利用していた実データを
使って開発がしたい」というような要望もたくさんある。
そのため高機能なアプライアンスのモデルになると、バックアップデータを
リンククローンで複製して利用することも可能じゃ。
もちろん、オリジナルのバックアップデータには影響がなく、差分のみ別に保存する
ことが出来るのじゃ。また、リンククローンで作成したデータにマウントを行う際、
REST API で連携できる機能を備えた製品なども多い。
従来のバックアップサーバー
高機能なアプライアンス
古いサンプルデータで
開発しても最新の本番環境に
最適な状態でアップデートできない
差異が発生
高機能アプライアンスなら
本番環境の最新クローン
データで開発ができる!!
ほぼ差異なし
リンククローンって何ですか?
REST API で連携って…!?
まず 「フルクローン」「 リンククローン」 を説明していこう。

pagetop