仮想化を見直そう
新年、初日記です。
これまで読んでいただいていた方、すみません。長い目で見てください。
さて、最近仮想化は便利なのではないかと見直して見たことがある。
以前、「仮想化は誰のため？」仮想化は誰のため？ - 誰かに任せておけないストレージという日記を書いて、ストレージ仮想化とはどのような技術なのかを説明してみました。
ストレージ製品を販売しているベンダに左右されず最適なストレージを導入することができて、高速バックアップが実現でき、将来的には災害対策まで考えられている製品だということを紹介した。また、アプライアンス製品もあるが、エンジニアとしてはスイッチ上で実現して欲しいことも書いている。
仮想化が一番良いことは、オンラインでディスク追加ができることではないだろうか？
ベンダに左右されずに導入できるといってもそれぞれのベンダで管理方法は違うし、監視方法もストレージ製品によって異なる。バックアップも筐体をまたいでは難しい。スイッチ上で実現するには各社の足並みが揃わないなど問題が山積みです。
それでも仮想化を検討するのは、ずばり「ストレージがもう止められなくなっているので止めたくない」という一言に尽きるのではないか？仮想化の下にすべてのストレージを配置してしまえば、サーバは仮想化装置さえ見ていれば良いのだから、オンラインでのディスク追加が可能となるに違いない。仮想化を入れるメリットはそれくらいかな。
OSが語れるエンジニアの位置
いつもブログを書かないといけない、ダメだ今日は忙しくて・・・など葛藤しているが、自分で決めた1週間に1度という更新目標も守れずにいる。いつも期待させてしまい口だけだと思われてしまう自分が本当に情けない。
アクセスカウンタが日々増加していてこのようなブログを読んでいただけることに感謝です。
ありがとうございます。
最近、多くのお客様、エンジニアと話をして思うことですが、OSの話がまったく語られなくなってきたこと。そのOSでなければ動作しないアプリケーションというのも存在し、そういったアプリケーションは独自色が受け入れられているが、その他にどのOSでも動作するアプリケーションというのが増えているのではないか。
特に、データベース、メールなどが良い例なのではないだろうか。
UNIXでもLinuxでもWindowsでもほぼ同じように動作する。工夫すれば性能も同じくらい出せるはず。そんな状況でOS違いのコマンドなどを覚えてはたして意味があるのだろうかと思ってしまう自分がいる。これまでミドルウェアなどのアプリケーションを語れるエンジニアはOSの知識も必須だった。しかし、これからOSを語れるエンジニアはハードウェアよりのインフラに強いエンジニアが担当するようにシフトするのではないだろうか？
エンジニアが二極化し、アプリケーションが得意なエンジニアとインフラが得意なエンジニアにわかれ、それぞれアプリケーションが語れるエンジニアはどちらかというとエンドユーザやコンサルファーム寄り、インフラが得意なエンジニアはシステムインテグレータやベンダに多く集まる傾向が強くなるのではないだろうか？
ベンダとしてもインフラだけが語れてもこれから商売にならない。ソフトウェア会社を多く買収しているベンダは必ず成功するだろう
スナップショット機能によるバックアップ
バックアップについての最終回はストレージの機能を利用した俗に言うスナップショット機能によるバックアップについて書きたいと思います。
最近のバックアップ事情では24時間止めずにバックアップが取れることが重要になってきています。詳しくはこちらをお読みくださいバックアップだけでは止められない - 誰かに任せておけないストレージ
バックアップ時間を短縮し、オンラインでのバックアップを取得する方法としてストレージの世界でずっと使われてきた手法としてストレージ内部のコピー機能を使ったバックアップがあります。
ストレージのコピー機能とは大きく分けて2種類の方法があります。
- クローン（コピー）機能
- スナップショット機能
クローン（コピー）機能とは、ストレージ内部に管理者が指定したボリュームとまったく同じデータをコピーしてくれる機能です。またそのコピーされた領域は別のサーバにマウントして中のデータを見せることができるため、バックアップのときに「コピー ⇒ バックアップサーバにマウント ⇒ バックアップサーバにてバックアップ取得 ⇒ マウント削除」という一連の流れでアプリケーションが動いている本番サーバには一切の負荷をかけずにバックアップを取得することが可能です。24時間稼動し続けるという目的としては、本番サーバに負荷がかからない、本番のボリュームではなくバックアップ専用のボリュームができるというポイントから考えてオンラインに近いバックアップの手法として使うことができます。
注意点としては、バックアップは重要 - 誰かに任せておけないストレージに書かれてしますが、バックアップを取得するためには静止点を作る必要があります。データのコピーをする前に本番データの静止点をいかにして作るかを考えてバックアップの取得方法を考えましょう。
もうひとつの方法としてスナップショットバックアップがあります。スナップショットとは上記のクローン（コピー）機能のようにデータのコピーを作るわけではなく、ポインタと呼ばれるどこにどのようなデータが入っているのかというメタデータだけをコピーする方法です。ポインタが２つ作られればそのデータをもとにサーバへのマウント処理が行えるため、１つのポインタはそのまま本番サーバ用に使い、2つ目のポインタはバックアップサーバへのマウント用に使うことで同じデータを2台の違うサーバから見ることができます。
注意点としては、あくまでポインタを利用したバックアップのため、サーバがアクセスするボリュームはまったく同じボリュームとなります。そのため、バックアップ取得時はそのボリュームに対して負荷がかかることを忘れてはいけません。
バックアップをサーバではなくストレージ側で取得する方法はCPU負荷や運用管理面から考えても非常に有効な方法です。この機能は以前はハイエンドの高価なストレージ装置にのみ実装されていますが、最近では一部のストレージを除いてほぼすべてのローエンド・ミドルレンジのストレージ装置にも搭載されています。この機能を有効に活用できるようにバックアップを設計したいです、
バックアップはテープ？ディスク？
1週間に1度しか技術的なことをこのブログに書けていませんが、勘弁してください。自分のペースでこれくらいが今は一番良いと感じていますので、今後増やせるようなら増やしていきたいと思います。
さて、バックアップエンジニアとしてバックアップしたデータをどこに保存するのかは悩むところです。過去のブログに「テープとディスク、どちらが早いか」と書いたことがありますがテープvsディスク - 誰かに任せておけないストレージ、正直なところどちらも良い点があるので状況に応じて使い分けるというのが良いのです。
バックアップは、なにか障害など予期せぬトラブルやミスによって失われたデータを復旧することが主たる目的です。データを戻すということを考えたときに、なにが一番優先されるかということを「戻すときの状況をイメージして」考えてみましょう。
何度も書いていますが、システムの重要度や経験度対象アプリケーション - 誰かに任せておけないストレージが関係してきます。データをリストアで戻すときに早く戻せれば良いのか？慌てず確実に戻せれば良いのかによって、早く戻すにはディスク媒体へバックアップを取得しておく、確実に戻すには例えばフルバックアップを毎日取得しておくなどその状況に応じた戻し方、またその戻し方に最適なバックアップ保存先が決まってきます。
トラブルが起こったときに冷静でいられるのは余程の度胸の持ち主です。システムが重要であればあるほど大変な事態になるでしょう。ましてはデータを戻さなければならない状況など、考えたくもない状況であることは簡単に予想できます。その時にどのようにリストアして、その後リカバリ処理をして復旧するのかをバックアップ設計のときから意識しておきましょう。
避難訓練と同じです。その状況をイメージして設計ができるか。それがエンジニアに求められることでしょう。と、エンジニアの考え方論になってしまいましたが・・・戻しの状況を考えてバックアップ保存先を決めましょう。
バックアップに許される時間
毎週バックアップについて書きながら、バックアップは重要だなぁと改めて考えてしまう自分がいます。バックアップが重要だというよりも、バックアップ対象であるデータの重要度が高まっているのかもしれません。これからはサーバの処理能力よりもストレージへの書き込み速度やストレージ処理能力が重要になってくる時代が来るのではないでしょうか。
さて、今回はバックアップに許される時間について記載したいと思います。
前回バックアップだけでは止められないバックアップだけでは止められない - 誰かに任せておけないストレージで書きましたが、オンラインでバックアップを取得する方法はいくつかあります。止まっているように見せる機能、バックアップソフトウェアのオプション機能などがそれです。
バックアップは通常夜間に取得します。バックアップを取得する処理が本番サーバの処理能力に影響を与えてしまうからです。一般ユーザが使っている日中の時間帯にバックアップを流せば、おそらくクレームが来るでしょう。イメージとして、お昼や夕方に流れるクライアントPCのウィルスソフトウェア処理がわかりやすいでしょう。ウィルスの処理が走るとPCの処理能力が落ちます。遅くて嫌だなぁと感じることが多いのではないでしょうか。これと同じことがバックアップ処理中の本番サーバに起こるのです。
そのためにバックアップはユーザが使わないであろう午前0時から8時までの間に終わらせるのが一般的です。
しかしながら、データ容量が倍々に増える現在ではこの時間内に終われないことが問題としてあがっています。バックアップの取得方法も工夫する必要があるのです。そのためにバックアップソフトウェアでは、差分バックアップや増分バックアップと呼ばれる機能が備わっています。
差分、増分の違いは議論が分かれるところではありますが、ここでは差分は前回のフルバックアップからの更新データのことを言います。増分は、前回のフルバックアップからの更新でなおかつ直前の増分バックアップからの更新データのことを言うことにします。
フルバックアップを日曜日に取得したとすると、
→月曜日：差分、増分とも月曜日の更新データだけなので、容量は同じです。
→火曜日：差分はフルバックアップからの更新データですから、月曜日と火曜日の更新データ量がバックアップされる
増分は、直前の増分バックアップからの更新ですから、月曜日から火曜日にかけての1日分のデータです
・・・
→金曜日：差分はフルバックアップからのデータ更新なので月曜から金曜までの更新データがすべて取得されます
増分は、例えば金曜日一日分のデータだけを取得するだけで済みます
バックアップだけ考えると差分、増分機能を使うとバックアップ時間の短縮となります。しかし、バックアップエンジニアたる者、バックアップの時間短縮だけ考えているようでは半人前です。このバックアップデータをリストアするとき、サーバに何か障害やデータ破損があった場合の戻しの状況も考えなくてはいけません。
フルバックアップであれば、障害のあった直前のフルバックアップデータを戻せば終わりです。
差分バックアップであれば、フルバックアップデータと障害のあった直前の差分バックアップを戻すことになります
増分バックアップはやや複雑で、フルバックアップデータと障害のあった時までの増分バックアップデータをすべて戻さなければデータは復旧できません。
リストアに関して言うと、バックアップソフトウェアが自動でリストア処理をしてくれるのですが、やや複雑になります。ここまで考えることができてバックアップを語れるということです。
まだまだ書ききれませんが、残り2回で一人前のバックアップエンジニアにしてみせましょう。
バックアップだけでは止められない
バックアップについて書き始めるといろいろなことを考えてしまい、内容がぶれてしまうことがある。今回は最近バックアップについて思うことを書いてみたい。
最近一番思うこと、それは「昔は深夜の限られた時間だがアプリケーションを止めてバックアップできたのに、最近はバックアップだけではシステムを止めることができなくなってきたなぁ」ということ。顧客の24時間365時間可能な限りシステムは止めたくないという要望とインターネットの普及に伴いそもそも自分が使いたいサービスが止まるということをユーザが許してくれないということが背景にあるのではないだろうか。
バックアップを設計する上で一番大事なことは、「データの静止点を作ること」。詳しくは、こちらを読んでいただきたい＞バックアップは重要だ - 誰かに任せておけないストレージ
止められるのであれば、静止点は容易に作れる。アプリケーションが止まっている間はデータの更新がない状態になるわけなので、何時のバックアップが取られているのかという静止点が作れている。
止められない場合、どうするのか？
方法としては、２つ。
- アプリケーションの機能で止まっているように見せる
- バックアップソフトウェアのオプション機能で静止点を作る
データベースソフトウェアに多いが、ログの機能を有効に使ってユーザにそのアプリケーションが止まっていないように見せることができる。ユーザはデータを更新できるのだが、データベースソフトウェア側で実は更新データをログとして残し、バックアップを取得した後に、更新データを反映するということをしてくれる。これでバックアップの静止点問題は解決する。
また、バックアップソフトウェアにはオプション機能で様々なアプリケーションのデータを止めずにバックアップを取得することができるようにすることができる。バックアップソフトウェア側で何時までのバックアップを取得できているかということをコミットしてくれるようなものと認識してもらえれば良いだろう。メールソフトウェアやデータベースソフトウェア、DBを使ったファイルサーバ機能やポータル機能を使ったソフトウェアなどのために対応したオプションが用意されているので、もし止められないとわかったときはこの機能があるかないかでどのバックアップソフトウェアを購入するのか検討したい。
現在はアプリケーションをバックアップのためだけに止めることはできないと考えてよい。 止まっているように見せない機能は上述したとおりである。止められないという問題はそれなりに解決した。今、一番の問題はバックアップ時間がかかりすぎること。バックアップに時間がかかりすぎていることである。次回は、バックアップに許される時間を考え、どれだけ短くできるのかを記述したい
バックアップ対象アプリケーション
随分と長い間休んでしまいました。このブログは自分に課した宿題でしたが、忙しいことを理由に逃げていました。これからもストレージについてのこれまでの知識、経験について語っていきたいと思います。よろしくお願いします。
さて、休んでしまっていましたが、バックアップに関する考慮ポイント3点目です。
バックアップを語る上でもしかしたら一番重要かもしれないことが「バックアップ対象のアプリケーションが何か？」ということです。バックアップの仕事を受ける場合に、必ず聞くのが「対象アプリケーションはなに？」という質問です。
いろいろなアプリケーションにより特色が異なりますが、バックアップの取り方は千差万別。もしかしたらそのアプリケーションは止められないものかもしれませんし、バックアップソフトウェアが対応してないかもしれません。OSの種類も気になります。
「対象アプリはなに？」という質問をしたあとに、エンジニアとしては下記のことがパッと頭に浮かぶようにしたいものです。
- そのアプリケーションの重要度
- 一般的にそのアプリケーションが使われているシステム構成イメージ
- 一般的にそのアプリケーションはどのようなOSで動いていることが多いか
- 自分が経験したことがあるバックアップ対象アプリケーションかどうか
あくまで”一般的に”と書いているのは、お客様の好みによって（他にも理由はあるでしょうが、おそらく大部分は好みでしょう・・・）構成が変わることがあるので注意です。今回はデータベースを例にとりお話したいと思います。
①データベース（以下、DB）と聞くと重要度は高いように思います。システムの特性にもよりますが、②DBを使っているシステムは重要だというイメージがあるのでまずは止められないと思ったほうが良いでしょう。しかし、③DBの多くはログの機能によりユーザに対して止まっていないと仮想的に見せることができます。止められないと仮定して、ログの機能を使って止めていないように見せることをサポートしているバックアップソフトウェアは何か、言い換えると、④バックアップソフトウェアのエージェントと呼ばれるオプション機能が対応しているかどうかを考えます。⑤バックアップソフトウェアの選択に際して稼動しているOSも気になります。 最後にそのアプリケーションについて以前に経験したことがあるものでれば、バージョンが違っていても基本は同じようにバックアップできるものがほとんどなので、経験をもとに設計と構築、運用をすれば良いです。
パッと上記ポイントが考えられるようになればストレージエンジニア、もしくはバックアップエンジニアとしてお金をもらって仕事ができるでしょう。上記ポイントを考えられればプリセールスエンジニアとして提案書も書けるでしょうし、コンサルティングもできるようになるでしょう。
こういったポイントについて今後も記載していきます。中途半端な部分もあると思うので、その際はぜひコメントください。
