none
耐障害性をあげるレプリケーションの実装について RRS feed

  • 質問

  • 初めて投稿します。

    WindowsServer2008R2 + SQLServer2008R2 StandardEdition の環境をもつ同レベルのサーバが5台あります。

    それぞれのサーバは、物理的に遠隔地の拠点に配置されていて、各サーバはそれぞれの拠点にある複数のクライアントから更新・参照されています。

    拠点にあるサーバは、全て同期が取られており、1拠点で更新された内容は、その他の全ての拠点に配られる必要があります。

    このような要件を実装するため、トランザクションレプリケーションを使用しようと考えていますが、耐障害性という面で分からない点があります。

    例えば、拠点A、拠点B、拠点C、拠点D、拠点Eがあるとして、拠点Aのサーバがダウンした場合に、残りの4拠点で同期が取られる必要があります。

    多重障害(拠点A及び拠点Bが共にダウン)の場合には、同期が停止することは致し方ないのですが、1拠点のダウンの場合は、残りの4拠点で同期を

    図る必要があります。

    この要件を満たす場合、EnterpriseEditionにある ピアツゥピアトランザクションレプリケーションを使用すれば実装出来ることは分かるのですが、

    残念ながら StandardEdition のためその選択肢を選べません。

    何か良いお知恵があれば、教えて下さい。どうぞよろしくお願い致します。

    2010年9月15日 12:46

回答

  • このような構成はできるみたいです。 ただ、ディストリビューション データベース の ミラーリングは不可みたいです。

    レプリケーションおよびデータベース ミラーリング
    http://msdn.microsoft.com/ja-jp/library/ms151799.aspx

    • 回答としてマーク 北の大地 2010年9月18日 2:11
    2010年9月16日 3:53
  • > パブリッシャをミラーリングするとかディストリビュータをミラーリングするとかの方法が取れると解決策になるのかもしれませんが、
    > そのような方法は現実的にとれるものなのでしょうか?

    もちろんできます。

    レプリケーションおよびデータベース ミラーリング
    http://msdn.microsoft.com/ja-jp/library/ms151799.aspx

    最初の質問の記述を見るとインターネットのように任意のどのノードがダウンしたとしても、別の経路からシステムが稼動し続ける分散型のシステムを考えているように理解できますが、まさにそれを実現するのがピアツーピア トランザクション レプリケーションであり、トポロジを構成することで経路を構成することができます。

    ピアツーピア トランザクション レプリケーションを使わない場合はどうしてもパブリッシャ・ディストリビュータという「これがダウンするとシステム全体が機能しなくなる」ノードができてしまいます。したがってピアツーピア トランザクション レプリケーションを選択肢からはずす場合は、パブリッシャ・ディストリビュータをフォルト トレラントにするしかない、ということになります。

    パブリッシャ・ディストリビュータの高可用性はミラーリングとフェールオーバー クラスタリングを組み合わせることでさらにあがりますが、費用や管理工数がかかりますのでそれらを考慮して手法を選ぶことになります。


    Please mark the thread as Answered when an answer resolves your problem. 回答が得られたら、もらった回答の [回答済み] ボタンをクリックしてスレッドを回答済みにしましょう
    • 回答としてマーク 北の大地 2010年9月18日 2:11
    2010年9月16日 3:59
  • リモートディストリビュータを使用すれば、パブリッシャマシンがダウン(ミラー側に切り替わっても)しても、全てのサーバーが孤立することはないと思います。

    ただ、リモートディストリビュータマシンがダウンすれば、同じことが起こりますが。。。

    peer-to-peer レプリケーションについて、検証を実施したことがあるのですが、制限が多く、使用することをやめたことがあります。(SQL Server 2005ですが)

    例えば、各拠点 A - E で更新される範囲が決まっている場合(A拠点では、ID 0-10000 までのデータを更新、B 拠点では、 ID 10001- 20000 までのエータを更新する もしくは、A拠点では A テーブルを、B拠点では B テーブルのみを更新する)はとっても有効だと思いますが、 A - E 拠点で更新される範囲が決まっていない場合は、衝突などが発生し、対処が必要となる場合があるため、すごく面倒であったような感じを受けています。

    まずは、Developer Edition などで実際に Peer-to-Peer レプリケーションを構築し、検証を実施されることをお勧めします。

    参考になれば。

    • 回答としてマーク 北の大地 2010年9月19日 7:49
    2010年9月18日 3:23

すべての返信

  • マージレプリケーションで 拠点A : パブリッシャ、拠点 B - E : サブスクライバ という構成でしょうか。

    サブスクライバがダウンしたとしても、その他の拠点で同期はできます。 ただ、パブリッシャ側にて障害が発生した場合は、同期を行なえなくなるというのが弱点でしょうか。

    • 回答としてマーク 北の大地 2010年9月18日 2:10
    • 回答としてマークされていない 北の大地 2010年9月18日 2:11
    • 回答としてマーク 北の大地 2010年9月18日 2:11
    • 回答としてマークされていない 北の大地 2010年9月18日 2:17
    2010年9月16日 2:48
  • 早速回答頂きましてありがとうございます。

    やはり、パブリッシャ側で障害が発生した場合は、各サブスクライバが孤立する形になりますよね。何か、パブリッシャをミラーリングするとかディストリビュータをミラーリングするとかの方法が取れると解決策になるのかもしれませんが、そのような方法は現実的にとれるものなのでしょうか?

    2010年9月16日 3:44
  • このような構成はできるみたいです。 ただ、ディストリビューション データベース の ミラーリングは不可みたいです。

    レプリケーションおよびデータベース ミラーリング
    http://msdn.microsoft.com/ja-jp/library/ms151799.aspx

    • 回答としてマーク 北の大地 2010年9月18日 2:11
    2010年9月16日 3:53
  • > パブリッシャをミラーリングするとかディストリビュータをミラーリングするとかの方法が取れると解決策になるのかもしれませんが、
    > そのような方法は現実的にとれるものなのでしょうか?

    もちろんできます。

    レプリケーションおよびデータベース ミラーリング
    http://msdn.microsoft.com/ja-jp/library/ms151799.aspx

    最初の質問の記述を見るとインターネットのように任意のどのノードがダウンしたとしても、別の経路からシステムが稼動し続ける分散型のシステムを考えているように理解できますが、まさにそれを実現するのがピアツーピア トランザクション レプリケーションであり、トポロジを構成することで経路を構成することができます。

    ピアツーピア トランザクション レプリケーションを使わない場合はどうしてもパブリッシャ・ディストリビュータという「これがダウンするとシステム全体が機能しなくなる」ノードができてしまいます。したがってピアツーピア トランザクション レプリケーションを選択肢からはずす場合は、パブリッシャ・ディストリビュータをフォルト トレラントにするしかない、ということになります。

    パブリッシャ・ディストリビュータの高可用性はミラーリングとフェールオーバー クラスタリングを組み合わせることでさらにあがりますが、費用や管理工数がかかりますのでそれらを考慮して手法を選ぶことになります。


    Please mark the thread as Answered when an answer resolves your problem. 回答が得られたら、もらった回答の [回答済み] ボタンをクリックしてスレッドを回答済みにしましょう
    • 回答としてマーク 北の大地 2010年9月18日 2:11
    2010年9月16日 3:59
  • NOBTA様、M_Lewis様 ご回答ありがとうございます。大変参考になりました。

    早速、ご紹介頂きました「レプリケーションおよびデータベースミラーリング」の環境を構築してみました。が、やはり、ディストリビュータをミラーリング出来ないため、このデータベースサーバがダウンしてしまうと全てのサーバが孤立するという状況になりました。

    やはり、ピアツゥピアトランザクションレプリケーションでないと今回の問題をクリアすることが出来ないということなんでしょうね。

    いろいろとご意見ありがとうございました。費用的に難しいかもしれませんが、Enterprise Edition へのアップグレードを検討致します。

    2010年9月18日 2:28
  • リモートディストリビュータを使用すれば、パブリッシャマシンがダウン(ミラー側に切り替わっても)しても、全てのサーバーが孤立することはないと思います。

    ただ、リモートディストリビュータマシンがダウンすれば、同じことが起こりますが。。。

    peer-to-peer レプリケーションについて、検証を実施したことがあるのですが、制限が多く、使用することをやめたことがあります。(SQL Server 2005ですが)

    例えば、各拠点 A - E で更新される範囲が決まっている場合(A拠点では、ID 0-10000 までのデータを更新、B 拠点では、 ID 10001- 20000 までのエータを更新する もしくは、A拠点では A テーブルを、B拠点では B テーブルのみを更新する)はとっても有効だと思いますが、 A - E 拠点で更新される範囲が決まっていない場合は、衝突などが発生し、対処が必要となる場合があるため、すごく面倒であったような感じを受けています。

    まずは、Developer Edition などで実際に Peer-to-Peer レプリケーションを構築し、検証を実施されることをお勧めします。

    参考になれば。

    • 回答としてマーク 北の大地 2010年9月19日 7:49
    2010年9月18日 3:23
  • NOBTA様 ご回答ありがとうございます。

    貴重なご意見ありがとうございます。大変参考になりました。

    なかなか難しいようですね。これからいろいろとハードルがあるようですが、一度検証を実施することと致します。

    ちなみに、NOBTA様は、A-E拠点で更新される範囲が決まっていないケースにおいて、別のツールなどで回避されたのでしょうか?

    もし、回避されていましたら、ぜひとも教えて下さい。

    2010年9月19日 7:53
  • peer-to-peer は、どのような機能であるかについて検証を実施しただけなので、実際に使用しておらず、代替案も調査しなかったのです。

    お役に立てず、すみません。

    ネットワークの回線が太い場合、すべての拠点から一つのデータベースに対して更新/参照するのも一つの方法かもしれません。

    2010年9月21日 1:32