第2章 バックアップの機能
今まではバックアップの必要性や手法、
種類についてみてきたが
第2章では機能についてみていこう!!
博士…了解です。
いよいよ2章でレベルアップですね。
仮想化でのストレージ連携・
アプリケーション連携
まずは 仮想化でのストレージ連携・アプリケーション連携編 じゃ。
この二つは別々の機能だが密接に関係しているので
同時に説明していくぞ。そもそもストレージはわかるか?
ストレージとは、コンピュータ内で扱ったデータやプログラムなどの
デジタル情報を保存・記憶する装置やシステム
ですよね。
ストレージを利用することで大容量の保存や長期的な記憶が
可能と習いました。
ハードディスク・フロッピーディスクなどがこれにあたるんですよね。
一般的なストレージの一例
そうじゃ。
ただし今から話すストレージとは、
仮想化環境を構築する際に利用するストレージ のことじゃ。
有名なところでいうとNetApp社のFASシリーズや
Dell EMCのUnityのようなSANやNASじゃな。
ここの章ではSANやNASをストレージと定義する。
代表的なSAN/NASストレージの一例
それなら聞いたことがあります。
数百万円以上するたかーいやつですよね。
高いか安いかはユーザーによって違うのでさておき、最近では多数の
企業で仮想化環境は導入されている。そして仮想化環境には
先ほど紹介したSANやNASなどのストレージが必要じゃ。
つまり 仮想化環境のデータは基本すべてこのストレージに格納されている
ことになる。よって ストレージに保存されるデータの整合性を担保して
バックアップを取ることが必須
になるんじゃ。
データの整合性 」って何ですか?
データの整合性とは、仮想化環境のOSとアプリケーション間の
データを正確にバックアップできているかどうか?
ということじゃ。

例えば城宝くんが管理者で、
君は"仮想マシンのデータのバックアップを開始した"と仮定する。
しかしそのデータの移動中、仮想マシンのデータベースサーバーで
ユーザーがデータを書き換えてしまった。
するとこのバックアップ中のデータはどうなるかな?

どんなに小さな変化でも変更が発生した場合、このバックアップは
非整合となる。
つまり元の仮想マシンのデータとバックアップ先に保存している
仮想マシンのデータは同一ではない。
よって正確にバックアップできたとは言えない
のじゃ。
でも博士。
別に少しぐらい変更が入ってもいいんじゃないでしょうか?
少しの変更でも良いか悪いかは、そのデータを利用する
ユーザーや企業が決めることで、君が決めるべきではない。

さらに、これが仮想マシンのゲストOSを構成する重要なファイルや、
OracleのようなDBで
確実なデータのコミット(保証)が必要なシステムにおいては、
最悪の場合データの復旧ができなくなる こともあるのじゃ。
よーく、肝に銘じておくように!
はい。すいません。ところで博士。
そろそろ仮想化でのストレージ連携とアプリケーション
連携を説明してください。
よーし! 図解で説明するぞ。
図解:仮想化でのストレージ連携・アプリケーション連携
データベース連携
整合性を保証するためには、一旦アプリケーションを停止し、静止状態の業務ボリュームをコピーする必要があります。
代表的なデータベース(Oracle/Microsoft SQL Serverなど)には、一定期間、業務ボリューム上のデータを書き換えないようにするために、トランザクションをログファイルに集積する機能が備わっています。このようなデータベース側の機能を利用して、瞬間的に停止している間に業務ボリュームをコピーすることで、業務への影響を最小限に抑えたデータベースの無停止バックアップが可能となります。
なるほど。アプリケーションや仮想化、ストレージそれぞれに
バックアップの静止点のポイントは違うものの、
データの整合性を担保するためにデータが変化しない
状態を作り出してバックアップを実行している

ことがよくわかりました。

初めはバックアップはどこかにデータをコピーしておけばいいと
考えていましたが、大企業など大きな環境では
いろいろ考えることが多いんですね。
よし。なかなか分かってきたようじゃな。
では次に バックアップの拡張性 を考えてみよう。
バックアップの拡張性ですか。
そう、基本的にデータは
いろんな要因で増えていくんじゃ。
ではデータが増える要因を考えてみよう。
データが増える要因
❶コンプライアンス的な観点から古いデータも
 保存してく必要がある。
❷長年のデータを含めたデータ分析が必要になることがあり
 古いデータを削除できない。
❸写真など素材のデータ自体がリッチコンテンツ化して
 容量が増えている。
❹会社の成長に合わせて社員数増加、事業拡張による
 支店増設でデータ作成量が増えている。
これらの要因を考えて将来どのぐらいまでの拡張が必要か?
を考える必要があるんじゃ。
そんな… 未来を予測するのは不可能ですよ…
そうじゃな。だからこそ 拡張性のある
バックアップシステムを事前に検討して
構築すること
が必要なんじゃ。
例えば想定される環境ごとに
考慮されている機能をいくつか見ていこう!
複数サイトのバックアップがしたい
現在急成長している企業で支店が毎月増えている。各支店にはファイルサーバーなどのサーバーが置いてある。各支店のバックアップを本社で管理したい。
統合管理機能
本社に統合管理サーバーを設置することで、一つの拠点から各支店のバックアップ管理が可能となる。
バックアップの拡張性を持たせたい
動画の作成などで大量のデータが毎月増えていく。
でも最初から数年後を計画して大きな容量のバックアップサーバーを構築すると予算が足りない。
スケールアップ/スケールアウト機能
拡張が必要な時に、スケールアップ/スケールアウト機能付きアプライアンスを買い足すことで、
容量を増やすことができる。
スケールアップ/スケールアウト機能は、あとから買い足した
複数のアプライアンスで保存領域をプールできるんですね!
無駄に大容量のバックアップサーバーを買ってしまって損した!
ということにならなくていいですね。
グループ会社のバックアップ管理を分担したい
会社が買収でどんどん大きくなっている。
でも、元々は別の会社であるため、システムが統合できるまでは別々に管理したい。
マルチテナント機能
マルチテナント機能付バックアップサーバーを設置すれば、一つのシステムを各社専用のバックアップサーバーとして分割し、各社へ提供することができる。
バックアップのマルチテナント
バックアップシステムのマルチテナント化は他のシステムのマルチテナントと同様、ひとつのシステムをテナントごとに論理分割して、複数の企業や部署に割り当てることができる機能です。テナントのユーザーはまるで自分専用に用意されたシステムであるかのように操作することができます。企業ごとに用意していたバックアップシステムをひとつに統合して、各企業は用意されたテナント内で自由にバックアップやリストアを行うことができます。その性質からグループ企業の統合バックアップ基盤やIaaSなどのサービスを提供しているプロバイダ向けの機能とも言えます。
BaaS(Backup as a Service)として提供されます。

pagetop