バックアップ世代の数え方
しばらく休んでしまいました。1週間ぶりのストレージブログです。
前回のバックアップエンジニアの基礎知識に続いて、第2弾としてバックアップ世代の考え方をまとめてみたいと思います。
バックアップを取得するときにバックアップを取りたいデータの容量も重要です。元のデータが何GB、何TBあるのかで様々な方法が考えられ、保存先のメディアも考えなければなりません。しかし、本当に重要なのはそのデータを何日分保存するのか、言い換えれば、何日前までの状態に戻せば良いのかということです。
毎日更新が入るようなデータであれば2,3日分バックアップを取れば十分でしょう。1週間前のデータを取っておいても毎日更新がかかっているようなデータであれば1週間前のデータを戻すことのほうが、手間になるかもしれないですし、ビジネスのリアルタイム性が失われるかもしれません。
逆に、毎週末にバッチジョブが流れることでデータの更新がかかり、前月のデータと比較しないといけないようなデータ、例えば毎月末の決算データなどは毎週更新がかかり前の月のデータが必要ということは、最低でも5週間分の週末データが必要になります。
世代の考え方ですが、1世代という言い方をした場合、実はバックアップを保存するために必要な容量は2世代分必要なのです。バックアップ取得中のことを考えてください。バックアップは指定された場所にデータが取得されます。1世代の容量しかない場合は、同じ場所に上書きされます。もし、バックアップ取得中に不具合が発生してしまったら、元のデータは残っていません。上書きされるということは不具合が発生するまでの間はデータが上書きされてます。中途半端な上書きがあるような状態で、元のデータが残っているはずがありません。この状態を防止するために1世代といっても前回正常取得されたデータは残しておきたいという思いから、1世代分データを保存する容量に余裕を持つことが重要です。
1世代 → 元データ量ｘ2倍
2世代 → 元データ量ｘ3倍 ・・・
という計算をして、それぞれの世代分バックアップを残すために必要な保存先容量を計算するようにしてください。
バックアップは重要だ
ストレージエンジニアに必要な知識、経験について、これまでいろいろと書いてきている。アプリケーションの知識と経験がないとストレージは語れないと思うといつも書いているが、アプリケーションを導入するときに密接に関わっているし、ストレージの知識も必要なバックアップについて、これまであまり書いてきていないことに気が付いた。
ストレージエンジニアであればバックアップが語れなければ稼げない。
バックアップを考える上で重要な点をいくつか書いていきたいと思う。
ストレージに保存されたデータをバックアップするときにどのようなポイントを考えなければならないのか。エンジニアとして最低限考えるヒアリングポイントか下記になると思う。
- バックアップ対象データ容量
- アプリケーションの種類
- 止められるのか、止められないのか
- バックアップに許される時間は
- バックアップ取得先のメディアはテープかディスクか
- ストレージのスナップショットは使うか使わないか
上記の点はこれからまとめていくとして、まずアプリケーションのデータをバックアップするときの基本の考えをまとめないといけない。それは、
- データの静止点を必ず作ること
- データを復旧するために許される時間はどれくらいであるのか
バックアップで重要なことはどこまでのデータがバックアップされていて、復旧のときに何時までのデータが戻るのかということである。夜中0時であれば0時までのデータは必ず戻せるというポイント、データの静止点を作らなければならない。即ち、0時までに書き込まれたデータはバックアップされているから守られていて安心という状態を作ってあげることが必要だ。何時までのデータが戻るのかわからないというのは、どうやってデータを復旧して良いのかわからないと言っているのと同じである。必ずデータの静止点は作りたい。
サービスによっては使われているアプリケーションを24時間止めることができないこともあると思う。そんなときはバックアップソフトウェアの機能を使用したり、データベースであればログを貯めることで「バックアップ対象のデータベース本体への書き込みが行われていない＝静止しているように見せる状態」を作り出すこともできる。
静止点さえ作ることができれば、あとはなにかあったときにデータを戻して復旧すれば良い。復旧のために許される時間はどれくらいなのかも次に重要な点で、前述の24時間稼動し続けるシステムにおいては、すぐにでも復旧させなければ収益に直結してしまう企業もあると思う。2時間以内、4時間以内など非常に厳しい復旧時間でも、なんとかデータを戻すことは現在の技術でいくらでも可能である。不可能を可能にする技術もこれから紹介していくが、ポイントは復旧時間を考慮してシステムの企画、提案をすること。
静止点と復旧時間を意識してバックアップを考えたい。
これからのシステムエンジニア
お盆休みでも書き込みをしたいと思いながらも長い間書き込みができず、すみませんでした。8月9日以来の書き込みで自分でも久しぶりだなぁと思ってしまいました。
ストレージに関係することですが、私が考えるこれからのシステムエンジニアについてまとめてみたいと思います。皆さんなりの考えがあると思いますので、ぜひコメントください。
ストレージ仮想化の部分でも書きましたが仮想化は誰のため？ - 誰かに任せておけないストレージ、今特にサーバとOSの違いはなくなってきていると思っている。どのベンダのサーバでもスペック、構成、保守は同じであり、またサーバ仮想化ソフトウェアやブレードサーバなどが大勢を占めている現在のシステムではどのベンダのものを選んでも同じだと思われる。違うのは、価格と営業の顔、保守員の顔くらいではないだろうか。アプリケーションがどのOSでも搭載できる今のIT業界ではOSがどのようなベンダのサーバでも載るのだから、違いはないと言われてはベンダのエンジニアはなにも反論できないのではないだろうか？唯一違うのはベンダそれぞれが販売しているUNIXだと思われるが、このUNIXも搭載されるアプリケーションに遜色がない状況となってきている。
サーバの中身も変わらず価格もそれほど違いが無く、ブレードサーバがこれからの売れ筋製品だとすれば、サーバが壊れたら障害復旧用に準備している予備のブレードサーバを入れ替えれば良いのである。これこそ最近流行のパーツを交換するだけでシステムが復旧できてしまう「チェンジニア」の姿ではないだろうか？ベンダが復旧の時間が早くなるシステムを販売し、運用が簡単になる製品を開発すればするほど、実は自分の首を絞めていることになるはずである。
これからのシステムエンジニアに求められる２つの要素をあげるとすると、DB、メールなどのアプリケーション（ミドルウェア）が経験として語れるということと、そのアプリケーションのデータを保存するデータ格納領域（ストレージ）が語れることが重要になってくる。ストレージはサーバがどのベンダのものであろうとどのようなアプリケーションがインストールされようと必要になる製品であり技術である。OSやサーバはどのベンダのものを使用しても、その上にインストールされるアプリケーションが24時間動き続ければ同じことだと思う。
これからはアプリケーションとストレージが経験から語れるエンジニアが増えてくることを願いたい。広くシステムを語れることで、エンジニアとしての価値もあがるはずである。このブログでは、ストレージエンジニアに必要な知識、経験を広く伝えるようにこれからも書き込みをしていきたいと思っている。
iSCSIは使えるかも
7月28日のブログでiSCSIはどこへ行ったのかiSCSIはどこへ行った？ - 誰かに任せておけないストレージという内容をまとめました。iSCSIとはどういったものか、また、まだ一般的に普及していない技術であるということを書きました。
よく考えてみるとiSCSIも使えるなぁと思うことがありまして、追加でまとめてみようかと思いここに書いています。人によりストレージやサーバに対する考え方が異なるのでなんとも言えませんが、ストレージエンジニアひとりの声として、フィードバックがあればコメントいただければと思います。
iSCSIはファイバチャネルに比べればまだ普及していない技術です。前回も記載しましたがSCSIデータをIPに載せて送ることができる技術でIBMとCiscoが3,4年前に高らかに発表していた技術です。当時は、iSCSI専用のHBAも売り出されており、FCに代わるストレージ転送技術として考えられていました。まだ一般的にどの顧客でも使われている技術というわけではないですが、バックアップ専用ディスクやアーカイブ転用ディスクとして構築費用が安価なことを材料に導入されているお客様が多いようです。
最近のx86サーバなどは標準でGbitのポートが2ポート付いています。1ポートをデータ用に使い、もう1ポートをストレージアクセス、またはバックアップ用として使うことがあるようです。サーバ標準で搭載されているポートだからこそ案件で余分なオプションを購入しなくても導入できるという手軽さが受けているようです。
また、Windows 2003 R2では、iSCSIストレージ上にブート領域を置くiSCSIブートもサポートされています。内蔵のディスクドライブではなく外部ストレージのブート領域を置くことで、万が一そのサーバに障害が発生した場合でもiSCSIブートの領域を他のサーバに接続させるだけで、そのサーバを復旧させることが可能になります。FCスイッチやHBAなどファイバチャネルの高価な製品を購入することなくiSCSIブートや早期復旧システムが構築できることはシステム管理者にとって非常に嬉しいことです。
これからはユーザ側からiSCSIを盛り上げて、より多くの製品がiSCSI対応となることを進めていく必要があるかもしれません。
災害対策のためのデータコピー
昨日災害対策システムを構築する上で考えなければならないポイントをまとめてみた。システム、データそれぞれの重要度に応じて対策をする必要があることと、復旧に許される時間によって災害対策サイトにどのようなシステムを構築すれば良いかを記載した。
災害対策システムではどのような方法でデータをコピー、もしくは転送すれば良いのだろうか？
データコピー方法としては、下記があげられるかと思う。
- ストレージ筐体間コピー機能
- データコピーソフトウェアを利用
- バックアップソフトウェアによる転送
- テープメディアの移送
ストレージ装置、特にハイエンドストレージと呼ばれる高機能なストレージは、同じストレージ装置を本番サイトと災害対策サイトの両方に設置することにより筐体間でストレージ内部の保存されたデータをコピーするという機能がある。ハイエンドストレージという高価なストレージを2箇所に導入するため非常に高価なシステムであるが、サーバではなくストレージのコントローラ部分がコピーを実現するため信頼性が高く、比較的早くデータコピーをすることができる。ストレージ装置に別途ソフトウェアのライセンスを購入しなければならないが、24時間稼動し続けなければならないシステムにとっては信頼性があるデータコピー機能として多くの実績がある。
ハイエンドストレージは高いという企業もいると思われるので、ストレージのコントローラではなくサーバのCPUでコピーを実現するのがデータコピーソフトウェアと呼ばれる専用ソフトウェアである。サーバにインストールする必要があるために若干サーバ性能に影響があると思われるが、ストレージ筐体間コピー機能に比べれば遥かに安価なソリューションとして災害対策が実現できる。データ更新分だけ送るという差分コピー機能を備えたものや2箇所での更新にも対応した双方向コピーを実現するソフトウェアなど様々なソフトウェアが販売されている。アプリケーションによってはそのアプリケーション専用オプションも用意されており、コピーの際にサービスを一切止めることなくデータコピーができるものもある。
意外に知られていない方法がバックアップソフトウェアによる転送である。バックアップソフトウェアには、バックアップソフトウェア自身をインストールしなくてもサーバ内データのバックアップが取得できるリモートエージェント、もしくはリモートオプションというライセンスが存在する。ネットワーク経由でサーバのデータをバックアップするオプションなのだが、このオプションはどのようなネットワークでも対応する。遠隔地など距離が離れているサーバでもネットワークの性能さえ許せばバックアップが取得できる。バックアップソフトウェアはすでに一般的でどのような企業でも導入されているはずであるので、その用途をバックアップだけではなく災害対策にまで広げてみることをお勧めする。バックアップソフトウェアが導入されていればそのオプション機能を追加するだけで災害対策が実現できるため非常に安価な仕組みが構築できる。
しかしながら、バックアップデータを遠隔地に保存するということは、そのデータ自身がバックアップソフトウェアによって独自の圧縮がかかっている場合が多い。同じバックアップソフトウェアによって復元する手間がこの仕組みには必要であるので、復旧に時間がかかることを覚えておきたい。
最後のテープメディアを移送する方法は、メインフレームなどが導入され始めた頃から変わらない災害対策システムである。何度も何度も繰り返すが、ハードウェア、ソフトウェアは購入できても一度失われたデータは二度と戻らない。災害対策としてデータが保存されたテープメディアを別な場所に移送し保管する方法は一番安価に実現できるソリューションである。安価ではあるが、復旧する際には一番時間がかかるのも事実。移送先からテープを戻す必要もあるし、テープ装置がなければ中に保存されたデータを読み込むこともできない。ある程度復旧に許される時間が長いシステムであれば効果的なソリューションだと思う。
災害対策といっても実際どれくらいの距離を離せばよいのだろうか？昔は東京−大阪間など比較的距離の長い災害対策をする企業が多かったようだが、最近では中距離での災害対策が多い。東京都内のサイトであれば例えば横浜、千葉、埼玉など近郊の地域、名古屋であれば静岡、三重などの地域、大阪では京都、和歌山など中距離のデータセンタでの災害対策システム構築が増えている。地震は局所的に被害が出ることがほとんどで広い地域で被害が出ることが少ないことが理由としてあげられる。また、中距離であれば通信費用の高い日本でもまだコストを抑えられることも距離が短くなっている理由である。法律でも60km以上などと定められているものもある。業界によって対策を考えたい。
「データは失われれば二度と戻ってこない」災害はいつ起こるかわからないが起こったときでは遅い。安価なソリューションや今持っているソフトウェアでも十分に構築できる。今すぐにでも重要なデータだけは守っておきたい。
災害対策システムの構築
過去3回にわたり災害対策というキーワードで情報を配信してきている。地震からデータを守れるかを書いた今だからこそ災害対策（地震からデータを守れるか？） - 誰かに任せておけないストレージ、災害対策とは具体的にはなにをしなければいけないのかをまとめた災害対策とは具体的になにをするのか - 誰かに任せておけないストレージ、少し視点を変えて高速ファイルアクセスを実現するWAFS機器の紹介WAFSによる災害対策 - 誰かに任せておけないストレージでも災害対策をまとめた。
しかし、災害対策システムを構築する上で考えなければいけないポイントを書き忘れているので、ここにまとめたいと思います。
災害対策というが実際に何を守ることが必要なのだろうか？
重要度という観点でみてみたい。
- 基幹系システム（メインフレーム、UNIX等の24時間止められないシステム）
- 情報系システム（メール、ファイルシステムなど）
- 元データ（失われれば二度と復旧できないデータ）
- 計算データ（元データがあれば計算による復元できるデータ）
基幹系システムとは企業活動、社会活動に無くてはならず、24時間止めることの許されないシステムである。記憶に新しいところでいけば、航空管制システムの障害、東証のシステムダウンなどがあげられるが、止まることでニュースになるようなシステムのことを言う。こういった社会的に影響の大きなシステムは災害対策をすべきだろう。
情報系システムは企業活動に必要であるが、止まっても代わりがあるようなシステムのことをいう。メールは基幹系システムメールはすでに基幹システム - 誰かに任せておけないストレージという内容をまとめたことがあるが、例えばFAXや電話など代わりになるような方法があれば基幹系とは必ずしも呼ばれないかもしれない。
データについては災害などで失われたときに二度と復元できない「元データ」と計算すれば復元できる「計算データ」がある。企業がこれまで蓄積してきた個人データ、ノウハウが詰まった企業活動に必要なデータなどいろいろあるが「元データ」だけはなんとしても災害対策として退避しておくべきだろう。
さて、システムとデータそれぞれに重要度を付けた。次に考えるべきポイントは、災害が発生してからどのくらいの時間で復旧するべきなのかということである。重要なシステムであれば災害が発生するしないに関わらずすぐにでも使い続けたいと思うだろう。復旧時間を考えると3種類のシステム構築が考えられる。
- そっくり同じシステムを災害対策サイトに構築
- 本番復旧まで予備的に使われる性能を落としたシステムの構築
- データだけを災害対策として退避
そっくり同じシステムを構築しておけば、災害が発生しても以前と変わらない性能で企業活動、社会活動に影響ない仕組みを作ることができるだろう。性能を落としたシステムであれば、例えば業務に最低限必要なシステムだけ提供することも可能であるし、性能は落ちているが災害が発生したのだからしかたがないとユーザも納得してくれるだろう。
以前も書いたがデータさえ守っておけばハードウェア、ソフトウェアを購入するだけで何度でもシステムは作り直すことができる。その意味ではデータだけを災害対策として守っておくだけで随分と対応が違ってくることになる。
それぞれに共通することはデータは必ず退避しておかなくてはならないということだと思う。データの退避方法は明日書いてみたい。
仮想化は誰のため？
メインフレームの時代からVirtualization（仮想化）について様々な技術が生み出されてきた。CPUやメモリなどサーバの仮想化についてはハードウェア機能や仮想化ソフトウェアにて実現されている。1台の物理的なサーバに複数のOSやアプリケーションを搭載することができ、逆に複数の物理的なサーバをまとめて1台のサーバとして動作させる機能を有しているハードウェアもある。
ストレージについては、仮想化がない環境では物理的、もしくは論理的なディスク（LUN）はサーバに対して1対1で割り当てられるのが一般的な構成である。しかし、1対1で割り振られてしまうとあるサーバでは９０％も使用しているのに対し、あるサーバに割り振られたディスクドライブは１０％も使っていないなどサーバの使用率、強いてはアプリケーションの処理、作りなどによりディスクドライブの使用率に大きな差が生まれてしまう。一度サーバへディスクドライブを割り振ってしまうとサーバ再起動を伴うメンテナンス時間を設けない限りサーバから使用していないディスクドライブを省くことができないため、24時間365日稼動を求められるシステムでは振り分けが難しい。
また、容量が足りず急にディスクドライブの拡張が必要になったサーバではサーバを停止し、外部ストレージ装置へディスクドライブを追加し、サーバを再起動させ、ドライブを認識しフォーマットをかけるという作業が必要になる。メンテナンスのために非常に長い時間システムを止める必要があり、かつ一歩間違えれば他のディスクドライブにも影響を与えかねない作業であるため事前のフルバックアップも取得したい気持ちになる。ストレージの仮想化は複数の物理的、もしくは論理的なディスク（LUN）をひとつのディスク（LUN）として仮想的に認識させる機能であり、大きくまとめると下記３つの機能が実現される。
1.ボリューム管理 - ディスク（LUN）の集中管理が可能となる。また、仮想ストレージ内でのボリュームコピー機能
2.高速バックアップ - 上記ボリュームコピー機能を使用したバックアップの信頼性の向上、リストアの高速化を実現
3.リモートコピー - 長距離サイトへのリモートコピーを仮想化により実現
例えば、Bサーバへ１００GBが急に必要となった場合でも、仮想ストレージの中から空いている領域を集めて１００GBのディスク容量をサーバへ割り当てることがGUIの操作だけで可能となる。もちろんサーバ再起動は必要ない
仮想化を実現する製品は大きく分けると下記４つがあげられる。
・サーバ上で動作するもの
・ストレージ上で動作するもの
・アプライアンス製品
・スイッチ上で動作するもの
以前からサーバ上に搭載するソフトウェア（下表、サーバソリューション）にて現在仮想化と呼ばれる機能が実現されているが、仮想化としてまとめたいストレージをすべてサーバのOS上に一時的にも認識させる必要があり、ボリュームの管理が複雑になるというデメリットがある。仮想化を実現する製品として下記の製品タイプが考えられているが、実用面から見るとスイッチ上で動作する仮想化製品が一番だと考える業界関係者が多い
