 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| 同期方式 | ||||||||||
|
スタンバイサーバでのデータの書き込みをもって、アクティブサーバのトランザクションを完了させる。スタンバイサーバにデータ損失がないため、データのリアルタイムな使用が可能である。だが一方、スタンバイサーバとの間のネットワークの帯域幅が狭いとパフォーマンスが低下するという課題がある（図3）。  図3：同期方式 |
||||||||||
| 非同期方式 | ||||||||||
|
スタンバイサーバでのデータの書き込みを待たずに、アクティブサーバのトランザクションを完了させる方式。コピーデータは一旦アクティブサーバの転送処理キューに送られ、バックグラウンドで逐次スタンバイサーバへのデータの転送が行われるため、システムのオンライン性能は影響を受けにくい。 災害時には損失したデータも更新ログと組み合わせることで最新の状態に復元できるため、ディザスタリカバリソリューションとして活用が可能である（図4）。  図4：非同期方式 |
||||||||||
| まとめ | ||||||||||
|
New Starの場合は、災害といっても天災ではなく人災であったのだが、このような致命的な被害を被ってみないとなかなかディザスタリカバリソリューションの導入は進みにくいことは確かだ。 しかしながら、1ついえることは、天災や人災はいつ誰にでも起き得るということだ。今回の事例での教訓としては、ディザスタリカバリソリューションは、設計面やコスト面を見ても、それほど敷居が高くはないということがおわかりいただけると思う。 また今回のシステムでは、従来Microsoft Exchange Enterprise Editionを使用していたが、LifeKeeperを導入する際にシステムの見直しを行った結果、Microsoft Exchange Standard Editionでも業務に十分対応できることが判明したため、ソフトウェアにかかるコストを削減することができたとのことである。思わぬ副産物である。 今後日本版SOX法の導入に伴い、データ保護やBCPの重要性がさらに高まっていくことが予想される。そこでシステムの再構築を検討されるのであれば、New Starのように大規模ではなくとも、ぜひともディザスタリカバリソリューションの導入を真剣に考えてみてはいかがだろうか。 以前よりも導入に際して敷居が低くなっていることや、今後のBCPニーズの高まりも相まってソリューションの選択肢も増えるが、まずはLifeKeeperのようなライトなソリューションから検討することをおすすめしたい。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
