現場の視点で見る災害対策（3）：WAN回線の設計とリハーサル：ディザスタリカバリで強い企業を作る（1/4 ページ）

ディザスタリカバリを机上の空論に終わらせず、実のあるものにするためには、しっかりした足回りの回線を用意すること、そしてリハーサルを実施することが非常に重要だ。

[小川晋平，ITmedia]

本記事の関連コンテンツは、オンライン・ムック「ディザスタリカバリで強い企業を作る」でご覧になれます。

足回りはどう作る？　WAN回線の設計

●キャリア側の経路

　ディザスタリカバリ（DR）サイトを構築する方法は前回説明したとおりとして、プライマリサイトとDRサイトの間はWAN回線で接続されることになる。さて、この回線はキャリアのネットワーク側では、どのような経路を通っているか、ご存じだろうか？

　例えばNTT系列の場合、東京では大手町に、大阪では堂島に回線が集約される。すなわち、大手町や堂島はネットワーク回線のアキレスけんとなっており、これらの場所が被災した場合には、たとえ自社のプライマリサイトやDRサイトが動いていても、サービス継続に影響があることを理解しておく必要がある。

　こうした情報は、実際にプライマリサイトとDRサイトの間のWAN回線を選定する際にキャリアに経路について質問すれば、丁寧に教えてもらえるだろう。

　重要な社会インフラを支える企業でもない限り、自力で光ファイバを敷設することは現実的ではない。またダークファイバを借りるとしても、やはりどこかにキャリアサービスと同じようなアキレスけんが存在し得る。

　一般の企業であれば、WAN回線にはキャリア各社が提供するサービスを用いるのが妥当だろう。万一、キャリアの地理的集約点が被災したとしても、その場合は社会全体のネットワークも稼働しない。そのため、このリスクは「許容する」という姿勢の方が投資対効果は高まる。

●差分データの測定

　DRサイト構築に当たり、拠点間でレプリケーションを行う場合は、あらかじめトラフィックがどれくらい発生するかを測定し、それに基づいて必要な帯域を契約する必要がある。WAN回線がボトルネックになると、被災したわけでもないのにシステム稼働に支障が生じてしまう可能性もある。そうした事態を避けるために、必要十分な帯域を確保しておくことが重要だ。

　レプリケーションを行う場合、初期同期を除けば、あとは差分データのみの送信となる。これにより、使用するWAN帯域を節約することができる。

　一方、前回紹介したディスクI/Oの横取り方式では、実際に発生するディスクI/OすべてがWAN上を流れることになる。この場合、1日のピーク時にどれくらいのディスクI/Oが発生しているのかを測定し、必要なWAN帯域を予測する。

●不要データの削除とILMの活用

　レプリケーションを行う前に、まず、現在プライマリサイトに保存されているデータはすべて、本当に必要なものかどうかを改めて見直してみよう。

　レプリケーションを行う際にはまず「初期同期」が必要になるが、そもそもプライマリサイトのデータが少なければ、システムのあらゆるリソースの負荷が軽減される。プライマリサイト側でのデータ削除は、劇的にコストを削減してくれる有効な策の1つだ。

　とはいえ実際には、大企業になればなるほど、調整やエンドユーザーへの依頼が難しくなり、なかなかプライマリサイト側のデータを捨てられない状態になっているのが実情だ。

　そこで考えたいのがILM（情報ライフサイクル管理）の導入である。一定期間アクセスされないデータはGB単価の低いディスクにアーカイブしてしまい、変更のほとんどないボリュームとして隔離する。この結果、ほぼリアルタイムでのレプリケーションが求められる重要なデータは変更頻度の多い部分のみであるため、GB単価の低いディスクに隔離したデータはテープバックアップなど他の低廉なデータ保護手法を採用することが可能となる。このアプローチにより、通常のレプリケーションに掛かる負荷やサーバリソースを軽減することができる。

図1●ILMを活用して負荷を減らす

●初期同期の苦しみを乗り越える方法

　レプリケーションでどうしても必要になる初期同期だが、前述の通り、コピーすべきデータをあらかじめ減らしておけば、その分リソースへの負荷は減る。

　このとき、WAN回線の帯域に十分な余裕があれば、ネットワーク経由で初期同期を行えばよいだろう。しかしデータ量が多くなればなるほど、ネットワークでの初期同期は現実的でなくなってくる。

　例えば、実効容量10TBのファイルサーバの初期同期を行うケースを考えてみよう。東京-大阪間で100Mbpsの帯域を契約しているとして、そのうち20Mbpsを同期用に使えると仮定する。この場合、この20Mbpsをフルに使えたとしても、1日かけて同期することができる量は

20M（bit/sec）×3600（second）×24（hour）÷8（bit/Byte）＝216GB

で216GBしかない。もしこのネットワークで10TB分の同期を行おうとすると、46日強かかる計算となる。東京-大阪間で1GbpsのWAN回線を契約できる金銭的余裕があればいいが、そういった企業のほうが少ないだろう。