ページ : 1 2 3
<この記事を全て表示する場合はこちらをクリック>
着々と容量が増大していくファイルサーバに保存されていくデータのバックアップ方法について最近考えていました。
数か月前の話になるんですけど、ファイルサーバとして利用していたストレージのDISKが一気に5本くらい認識しなくなりまして、少なからず動揺してしまった事も踏まえてです。
ちなみに今回作りたいなと思っているファイルサーバは以下のような要件です。
・保存データは4TB程度
・NTFSベースのアクセス権限を実装したい
・サービスダウンから1時間以内にサービス復旧
・出来るだけメンテナンスに手間をかけたくない
・サービス復旧時、なるべくデータをロールバックさせたくない
また、毎度の事ですが、僕の主観的なところであって、すべてのシステムに当てはまるわけでも、強要するわけでも無いので、軽ーく読んでいただければ幸いです。
ファイルサーバのバックアップには、昔ながらのLTOテープを利用していたのですが、保存しなければならないデータが増えるに従い、やはり書き戻す場合の時間も増えてしまいます。例えば利用するサーバにもよるかもしれませんが、1Gpbsの回線を利用してデータを転送したとしても、理論値で一時間に486GB、実際には細かいテキストファイルやらログファイルなんかもあるので、現実的な速度で考えて、200～300GBくらいが目安だと個人的には思っています。
こうなると、いくらギガビットイーサが高速と言えど、数TB規模のデータの場合、下手すれば復旧に一日以上かかってしまうケースも起こりえるかもしれません。データを保存しているサーバが破損してしまった場合、やはり代替サーバをすぐに準備出来るようにしておき、そちらを利用者に利用してもらっている間にデータの復旧なり修理を行うべきです。
ファイルサーバの冗長構成について
自宅のファイルサーバであれば、データが吹き飛んで泣くのは自分だけなのでまあ問題は無いのですが、企業でのファイルサーバであれば、やはり冗長構成を取っておくのが無難だと思います。
DISK構成について
最近、RAID6構成も対応するハードウェアが目立つようになりましたが、保存するストレージが一つしか無いのであれば、RAID5及びRAID6よりもRAID10をお勧めします。
僕がRAID10をお勧めするのは以下の点からです。
・DISK破損時のリビルドがRAID5,6に比べて速い
・DISKが2本以上破損しても、（運が良ければ）復旧可能
なんだかあまりパッとしない利点かもしれませんが、それほどDISK破損は怖いものです、・・・特に自分には。特にRAID5のアレイが破損した時のリビルドなんて、本当に寿命が縮まる勢いです。
サーバ冗長構成について
DISKをRAID構成にして冗長化しておいたとしても、それだけで安心してはいられません。
サーバもいつクラッシュするかなんて分かりませんし、DISKストレージもいつ破損するか分かりません。また、NTFSエラーが発生して、DISKエラーを修復させたい場合なんかも、代替サーバが無ければじっくりと作業する事も難しいです。
書き込みが発生しないシステムのロードバランスは比較的簡単に実装出来るんだけど、読み書きの発生するシステムはなかなか難しい部分があります。
DISKストレージを冗長化する
個人の体感的なお話になりますが、Windows Serverをファイルサーバとして利用している場合、どちらかと言うと、サーバ本体よりも、ストレージが破損する頻度の方が高い気がします。
そこで、同じ型の外付けストレージを2個接続して、それらをさらにOSの機能としてミラーリングします。こうする事により、複数のストレージに対して、安全にデータを保存する事が出来ます。
ただし、サーバ本体が破損した場合にはどの道ダウンタイムは発生しますし、DISKエラーが発生した場合には回避するのが難しいかもしれません。
iSCSI接続のストレージを利用する
Windows Vista以降、OSが標準サポートしているiSCSI機能を利用して、iSCSI接続のストレージを利用して障害発生時にストレージの向き先を簡単に変更出来るようにする方法です。
自分が試した中では、ローカルネットワークでの利用においてはiSCSIを利用してもMSアクセスのデータを開くのが極端に遅くなる等の不具合は、体感上まったく感じませんでした。
デメリットと言えば、やはり通常のDASと比べて割高になる事や、ギガビットイーサを利用した事によるアクセス速度位でしょうか。ただ、遅いといっても、通常ファイルサーバと利用者間の通信は1GBpsのLANでしょうから、ファイルサーバ用途としては十分に利用する事は可能です。
また、MPIOを利用して通信を行うNICの数を増やすことにより、速度は向上させることが出来ます。
試したことは無いですが、DASとiSCSIのストレージをOS上でミラーリングして、サーバ破損時にiSCSIだけ向き先を変更すれば、直近までのデータを利用する事は出来るかもしれません。
DFSRを利用したファイルレプリケーション
Windows ServerにはDFSR（Distributed File System Replication）っていう便利な機能がついていて、この機能を利用すれば複数のサーバ間でのファイルの複製が簡単に実装出来ます。
イメージとしては、Robocopyが特定のフォルダに対して、常に実行されている感じです。
すごく便利に感じるDFSRですが、こいつもそのままファイルサーバ用途のサーバに実装すると若干悩ましい目にあいます。
書き込みの競合したデータは一時保管場所に退避される
複数のサーバを拠点間で展開していた場合に発生するシナリオです。
同じディレクトリ構成を共有で公開しているサーバA、Bがあり、それぞれのサーバを利用するユーザが単一のファイルを別サーバ上でそれぞれ同時期に保存すると、DFSRの機能により、どちらかが削除されるか、ステージングと呼ばれる退避場所に保存されます。
拠点間のユーザが全く別のデータを更新するのであれば問題無いのですが、特定のファイルに対して頻繁に書き込みを行う場合、気をつけなければならない点だと思います。
こちらはWindows Server 2003 R2の時にしか試していませんが、例えばサーバAであるユーザがワード文書を開いていた場合、サーバAで他のユーザが同じワード文書を開くと排他制御がかかるのですが、同時期にサーバBでワード文書を開いた場合には排他制御はかかりません。
この辺はおそらく、データ保存場所を分ける等で、運用方法で回避するしかないと思われます。
エクセルファイルが稀に消える
これもおそらく陥りやすいトラブルなんじゃないかと思います。
エクセルファイルの保存方法と、DFSRのファイル複製の方法がお互いに干渉しあって発生するようです。Microsoftのサポートページを見る限り、エクセルを共有ドライブ上で保存しないようにするか、DFSRを実行する時間帯をずらすくらいしか対策は無いようです。
スナップショット機能をサポートしたストレージを利用する
高価なストレージには、ストレージ間のスナップショットをサポートしている機種があり、こういった機器を利用することにより、ストレージレベルで異なるストレージに対してデータをバックアップする事が出来ます。
ただ、自分が試した範囲での話になってしまいますが、スナップショット先の領域はOSにマウントさせていてはいけないようで、障害発生時にある程度のオペレーションが必要になってしまいます。
結局のところ・・・
結局のところ、iSCSIストレージや、ストレージ間のスナップショットも魅力的だったのですが、そこまでかけてファイルサーバってコストをかけるものなのか・・・？と思い、サーバとストレージをそれぞれ冗長構成にして、DFSRとエクセルファイルの仕様に基づき、ファイルを利用者がおそらく居ないであろう深夜帯のみ同期させようかと思っています。
ただ、稀にDFSRで上手くレプリケーションされないデータがあったので、その辺の検出をどうやればいいのか等はまだ悩み中です。定期的にRobocopyすれば良いのでは・・・？なんて思ったことは思ったのですが、それならDFSR利用しないでRobocopyのみで済むのでは・・・なんて本末転倒な感じになってしまったり・・・。
とりあえずは運用ルールで決め事を作って3年～5年くらい利用してみて、その後、新しい技術が出たらまた考えなおしてみたいと思います。
5年後、10GBpsに対応したiSCSIストレージが安価になっている事を祈りつつ・・・。
