WAFSによる災害対策
今だからこそ災害対策を実施するべきだというコメントを書きました。いろいろな方から災害対策の重要性を認識できたとコメントをいただいています。その災害対策に役に立つであろう技術が出てきています。直接みなさんの企業では使われない技術かもしれませんが、お付き合いいただければと思います。
災害対策やセキュリティのためなどの理由により重要なシステムほどデータセンタ内に機器を設置することが多くなってきています。メールシステムやファイルサーバもその例外ではなくデータセンタに集中させる企業が多いのが最近の状況のようです。しかし、データセンタに集中させてしまうとデータセンタから遠い支店からのようなWAN経由のアクセスではメール、ファイル・アクセスにおいて遅延が発生し、ユーザの使い勝手が悪くなる現状があります。
また、帯域が逼迫することでほかの重要な通信（例えば音声通話やネットワーク管理のための通信など）に悪影響を与えてしまう可能性も捨てきれない。１MBを超えるような大きなファイルを保存するだけで非常に時間がかかり、またそのファイル保存中には他のユーザの重要なアクセスもそれ以上に遅くなってしまう。ファイルサーバのアクセス性能を向上するためにはこれまで下記の2つの対策がこれまで考えられてきました。
- WAN回線を極力高速にして、ファイル・アクセス分の負担を吸収する
- 拠点のLANごとにファイル・サーバを設置し、WANになるべく負担を掛けない
（１）のWAN回線の高速化は、通信回線の高い日本では企業の収益を時には圧迫してしまう危険性があり、（２）の拠点ごとのファイルサーバ設置ではWANに負荷はかからないがそれぞれの支店での管理が煩雑になっています。支店での管理では、ひどい場合はバックアップ取得後のテープメディアを総務の女性が毎朝交換することが日常業務のひとつとなる現状もあるのではないでしょうか。これらの問題を解決するためWAFSと呼ばれる技術が開発され、企業の中で導入が検討されるようになってきています。
WAFS装置のマネージャをデータセンタにエージェントを支店にそれぞれ配置することにより、WAFSに搭載されているキャッシュにデータが一時的に格納されるようになります。常に使われるファイルはキャッシュ上に存在するため読み込みが早いだけでなく、支店でのファイルの書き込みも早くなるというのがWAFSの一番の特徴です。WANを経由してデータセンタのファイルサーバへファイルを書き込むとデータセンタ側での正常な処理が終わらない限り、クライアントからは処理待ちの状態となります。アプリケーションの下の保存中の数字やメモリが遅く、遅く100%に近づいていく長いこと待たされる状態です。もしWAFSが支店にあればクライアントはローカルLANに接続されているWAFSのキャッシュ上に書き込みを行うだけで処理が終了するため、データセンタへ書き込むよりも非常に短時間に書き込み処理が行われます。このキャッシュに書き込まれたファイルはWAFSがネットワークの帯域が空いている時間に自動的にデータセンタ側のWAFSへ転送するという仕組みが一般的なようです
多くのWAFS製品では、独自の圧縮技術により通常のファイルアクセスよりも高速に転送が行えるようになっているようです。ベンダ各社独自の圧縮技術であるためセキュリティ上も安全な転送が可能となるのが強みです。
ファイルサーバを集約するこにより、管理が簡単になり、なおかつ情報の漏洩を防止できればWAFS導入の本当のメリットを感じていただけると思います。WAFSはネットワークの帯域が細い、データセンタから遠い拠点向けの製品です。ネットワークが太くデータセンタからも近い拠点ではいくらアクセスが遅いと感じられる環境でもWAFSを導入しても意味がない場合もあります。災害対策のためにより安全なデータセンタへ資源を集中させることも必要ですが、そのシステムを使うユーザ、本当に必要なのかの判断をして導入してもらいたいです。
iSCSIはどこへ行った？
４年ほど前にiSCSIというデータを転送するためのストレージプロトコルが世間を賑わせた頃がある。「iSCSIはFCに変わる」、「iSCSIの出現でストレージエリアネットワーク（SAN）の世界は大きく変わることになる」と雑誌は騒ぎ立てていた。実際にふたを開けてみるとどうだろうか？ iSCSIはまだそれほど普及していない。
iSCSIとは、シスコシステムズとIBMが提案しているSCSIコマンドをTCP/IP/Ethernet上で伝送するための技術である。SCSIコマンドがトランスポート層のTCPでカプセル化され、TCP/IPヘッダが付与された後、IPパケットとして転送できるようになる。IPのネットワーク上をSCSIデータを流すことができる画期的な技術だと取り上げられたが、やはりサーバとストレージの間のデータを転送するためのネットワークである。TCP/IPの世界とは違いパケットは無くせない、性能も求められるという理由で普及しなかった。
またその頃は、iSCSIは既存のIPネットワークを使えるので扱いやすく、ネットワークエンジニアが管理できるので導入がしやすいと言われていたが、結局はネットワーク内を通るデータに関して少なからずストレージに関する知識が必要になるので、ファイバチャネルでもiSCSIでも管理者の負荷は同じとなるためそれほど広まりを見せなかった。
同じ頃、サーバとストレージ間の重要なデータを既設の社内ネットワーク（LAN）を通してよいものかと議論もあったことは事実である。時間によっては大量のデータ転送が伴うサーバ−ストレージ間転送が既設のLANの負荷を高めてしまったら元も子もないので、iSCSI専用にネットワークを作る必要もあり、iSCSIは既存のネットワークを通すことができる画期的な技術であるというメリットはなくなってしまったのである。
また、ストレージベンダのiSCSI対応製品出荷の遅れ、iSCSI対応HBAの価格高、ファイバチャネル製品の需要増など様々な影響もあり、iSCSIは忘れられる存在となってしまった。未だにストレージベンダ各社は比較的高く販売できるファイバチャネル製品を好むし、IPネットワークに接続できてしまうということはイコールベンダの垣根は取り外されてしまうことと同じである。まだ多少製品の相性が残るストレージ業界の製品ではベンダの垣根を取ることは売り上げの減少にすぐに繋がってしまう危険性も捨てきれない。iSCSIはおそらくこういったベンダの思惑もあり、ユーザの手に届く前に無くなってしまったのだと思う。
今後はベンダの垣根がなくなる時代に突入する。目先の利益を考えずにユーザのための仕組み、ユーザが本当に必要だと感じてもらえるようなソリューションを提供してもらいたいとベンダに問いたい。
ファイルサーバとNASの違いは？
NASとはファイルサーバに代わるファイル共有のための専用機器のことです。Network Attached Storageの略でネットワークに直接接続し、他の機器からネットワークボリュームを提供する専用ストレージのことを言います。
ファイルサーバと違うのは、ファイルサーバはWindowsやLinux、UNIXなど既存のOSを使いサーバ本体とストレージ筐体を導入して構築することがほとんどです。構築のための費用もかかりますし、OSによってはファイルサービス以外のサービスやプロセスも動いているため、性能やセキュリティに少なからず影響することが懸念です。
NASはファイル専用ストレージであるために、NAS上で動作しているOSはファイルサービス専用OSです。専用OSであるため、ファイルサービスのためにカスタマイズやチューニングが行われており、性能が良い傾向があります。またNAS装置はサーバ部分（OSが乗る部分）とストレージ部分が同一筐体に納められているため、NAS装置を購入し、ネットワークに接続して簡単な設定を行えばすぐに使えるという手軽さがあります。
＜NASの特徴＞
・NASはファイルを共有するために 直接100 BASE-TX/10BASE-TやGigabit Ethernetなどのネットワークに接続できるストレージデバイスです。
・ファイルサーバに特化したハードウェアです。
・マルチプラットフォーム対応なので、Ethernet接続可能であれば利用OSを選びません。
災害対策とは具体的になにをするのか
地震が発生しているのは東京近郊だけではない。近年日本で起きた大地震をまとめてみると非常に大きな地震が北海道から九州まで頻繁に発生しているのがわかると思う。日本はまぎれもなく地震大国である。9月11日のニューヨークの事件では対岸の火事だと思われていた災害だが、日本では驚くほど地震が多く、そのための備えは万全にしておきたい。
キーワードは、昨日25日にも書いたが「失われたデータは戻ってこない」である。例え災害に遭ったとしてもサーバ・ストレージなどのハードウェアやサーバ上で稼動しているソフトウェアは購入することができる。新しくシステムを作り直せば良いのである。しかし、一度失われたデータは絶対にもとに戻らないのである。ご自分の名刺フォルダに何枚の名刺が保存されているだろうか？社会人の経験が長ければ長いほど、名刺の数は膨大な量になるはずである。自分も名刺用クリアフォルダに10冊もの名刺が収められている。皆さんの財産だともいえるこの名刺が仮に火事で無くなってしまったら、同じ名刺を1枚ずつ集めなおすことは至難の業だと思う。お世話になった方の連絡先もわからず、これまで築いてきた人脈が失われていしまう可能性はないだろうか？例えば、その名刺を住所録などの電子データにすることで火事からは守られるかもしれない。これが「バックアップ」である。災害対策とは、その電子化したデータをCDROMに焼いてオフィスとは別の場所（自宅や耐火金庫）に保管することと同じです。データをバックアップ媒体とは別な場所に保管する遠隔地保管がいわゆる災害対策と言われるシステムです
データの送り方も、テープメディアやROM媒体に保存して移動させる方法や、WAN回線を使って別な場所にあるシステムに送る方法、ストレージの機能で別な場所に遠隔地コピーする方法など様々である。媒体で送る方法は原始的であるが一番コストが安い災害対策の方法です。逆に、ストレージなどの遠隔地コピー機能は、データの送る速度は速いが、非常に高価なソリューションであるので、ここでもデータの重要度に応じて２〜３パターンの災害対策システムを考えて導入することが良いだろう。
災害への備えがなければ企業には必ず損失が付いてまわります
いつ起こるかを心配するのではなく、いつ起こっても大丈夫なように備えをしておきたい
今だからこそ災害対策（地震からデータを守れるか？）
7月24日のメールシステムは基幹系という内容でもわかると思いますが、企業の持っているストレージ容量はどんどん増えてます。増え続けるデータを守るためのバックアップについて7月16日、17日にも書きました。ストレージ設計⑨ - 誰かに任せておけないストレージ バックアップはどちらかというとハードウェアやソフトウェアの障害や人的ミスからデータを守る（復旧）するための方法です。
日本は地震大国ですから、障害からデータを守れても局所的な地震による被害からあなたの会社のデータを守れますか？9月11日にニューヨークで起こった悲しい事件のあとに多くのIT企業は今こそ災害対策について考えるべきだと問われていました。多くの雑誌でも取り上げられ、「災害対策システムを構築していたおかげでビジネスが短期間に復旧できた、データが守られたおかげで損失を被らずにすんだ」と話題になっていました。
しかし、日本では災害対策システムはそれほど導入されなかった。対岸の火事であったと同時に、企業のシステム担当者は、自分が担当の間に災害が起こらなければいいやと考え、導入を先送りしてきています。2005年に発生した関東近郊の地震の震源地とその大きさを表した図があります。最近では、都心を囲むように関東近郊で多くの地震が発生しているのがわかります。
最近地震が多いと感じている方が多いと思われるますが、これほど多くの地震が東京近郊で起きているのだが自分の会社では災害に対する備えができていないと感じているシステム担当者は多いのではないだろうか？同じようなシステムを災害対策用のデータセンタに二重に作るのは費用もかかるし、大変です。データだけでも退避させておけば、システムは復旧できます。ハードウェア、ソフトウェアは購入できますが、失われたデータはもとに戻りません。
メールはすでに基幹システム
もうすでに何年前のことなのか誰も覚えていないと思いますが、会社間の取り引きを電話とFAXでやり取りをし、手紙は郵便で送っていた時代があった。その内容が電子化され、メールで必要な書類が送れるようになり、使い方によってはメールでリアルタイムで話ができるようになった。遠距離でもすぐに相手へのメールが届けられる。もう欠かせないビジネスツールのひとつであるが、企業のメールシステムは、情報システムだけの位置付けだろうか？冒頭に書いたように「もしメールが止まったら」お客様への連絡はどうすれば良いのか、受発注業務はメールが止まっている間FAXに代えられるだろうか。もはやメールシステムは、基幹系システムと位置付けても異論のない存在なのである。
ストレージとは関係ないように思えるだろうが、メールも日々圧迫しているデータのひとつであると思ってもらいたい。基幹系であるメールシステムのデータは果たして守られているだろうか？
社会人になった頃、まだメールには添付ファイルもなく、インターネットの回線も３２Kだった。懐かしいと思われる方も多くいられるだろうし、信じられないと思われる若い方もいられるだろう。その時代から考えるとメールシステムのディスク容量は大幅に増えたに違いない。
今はどうだろうか？WordやPowerPointなどのドキュメントに画像を張り付けるとどれくらい増えるだろうか？フォントの色を変えれば？背景を付けると？ プレゼン資料に効果的なアニメーションを付けるとどうだろうか？おそらく２６KBであったファイルは５０KBとなり、画像のおかげで２００KBとなり、背景のおかげて５００KBとなり・・・これが今の添付ファイルの現状である。この大きな添付ファイルのおかげで企業のメールシステムは悲鳴をあげている。もういくら容量制限をしてもディスクが足りない状況なのである。
また、重要なデータはすべてメールにしか残していないという社員もいると思う。メールシステムを添付ファイルのローカルディスク保存先としてやファイルサーバのように使っていると消せないデータがメールシステムに残る。メールの本文にだけ重要な内容が書かれている場合でもそのメールは消さずに、もしくはテキストに落として保存するようなことをしている人は少ないと思われる。
身近なメールシステムだが、基幹系であるという認識のもとで内部データの整理、重要なデータのバックアップ、何かトラブルが発生した場合の代替手段を考えておきたいものである。
テープとディスクバックアップはどちらが早い？続き
テープメディアの書き込み速度については、現在最高の性能を持ったLTO3でさえ 80MB/sであるから1時間に288GBのデータを書き込むことができる。並行して書き込みを行うなどのテープ装置だけでのバックアップ時間短縮の方法を除いても、ディスクに比べれば、同じ、もしくは遅いことがわかる。また、どんなに頑張ってもテープでは無くすことができない“テープメディアの入れ替え時間”がある。テープライブラリの中にはピッカーと呼ばれるロボットアームが１つ、ないし２つ搭載されている。バーコードの情報を読み込み、そのテープメディアが何番スロットにあり、バックアップソフトウェアの命令によりそのテープメディアを何番のドライブ（データを書き込む部分）に入れる。バックアップを取得したあとは、そのテープメディアをもとのスロットへ戻してあげる処理が必要である。その一連の流れの時間はテープへのバックアップをしている限り無くすことができない時間である。
テープへのバックアップで一番のマイナスポイントは、障害に弱いということである。障害のポイントはひとつはテープメディアの障害、もうひとつはテープライブラリの障害が考えられる。テープメディアは、お馴染みのVHSビデオテープと同じようにメディアの中へデータを書き込むためのテープが巻かれて収納されている。誰でも一度は経験していることだが、このテープが引っ掛かったり、テープに傷が付いたりすると記憶しているデータそのものが使えなくなってしまうことがある。障害が発生し、バックアップを取得しているはずのテープが使えない状態であったら、非常に大きな損失を被ってしまう。それを防ぐためにテープからテープへのコピー機能やテープRAID ＜詳細は、テープRAIDの仕組み＞と呼ばれる機能が用意されている。テープは壊れるのである。それに比べてディスクは、最低限RAIDが組まれている。ディスク1本が障害となってもそのデータはRAID機能により守られている。ディスクのほうが障害には強いのである。
テープへのバックアップも悪いことばかりではない。導入に際して一番のポイントは外部保管ができることである。外部保管ができるということは、簡単に災害対策ができるということである。オフィスのビルとは別の場所にある銀行の耐火金庫などに納めておけば（同じビルの1階にある銀行の金庫では意味がないことはわかっていただけると思うが）、災害によりビルが崩落した場合でもデータだけは守られるからである。
テープバックアップとディスクバックアップは用途に応じて使い分けていただきたい。システムの重要度、データの必要性に応じてバックアップ媒体を変える、ディスクへのバックアップも良いのだという意識を持っていただきたい
