none
SQLServer2005のレプリケーションについて RRS feed

  • 質問


  • 現在地理的に離れた2地点でデータ処理をしているサーバ・クライアント型
    のシステムがあります。

    A地点
    サーバ、クライアント

    B地点
    クライアント

    が存在し、B地点に置かれたクライアントとVPNにてA地点に設置してある
    サーバにアクセスして動作しています。
    これはシステムとしては1つのようなイメージで運用も楽だったのですが、
    B地点のクライアント及びデータ量が増大するにしたがってA-B地点間の
    ネットワーク帯域では処理しきれなくなりました。

    そこで、B地点にもサーバを設置し、SQLServerのレプリケーション機能を使用
    することを考えております。

    要件は以下の通りです。
    ・A地点、B地点では共にデータの参照、更新を行います。
    ・更新されたデータは共に相手方に伝わる必要があります。
    ・更新するデータはA地点とB地点のクライアントで同じデータを更新する
     可能性があります。
    ・同期はテーブル単位ではなく、DB単位で行いたい。
    ・レプリケーションによってテーブルの列数などが変わらない。

    このような時、どのようなレプリケーションを選択するのがいいのでしょうか?
    いろいろ調べてみるとトランザクション・レプリケーションが該当しそうなのですが、
    上記要件を満たすためにこのレプリケーションがどうであるか、また、実際にレプリケーション
    を設定するに当たっての注意点などアドバイスをいただければと思っています。

    DBサーバはSQLServer StandardEditionです。

    2007年11月5日 7:48

回答

  •  米田です。

     

    > B地点のクライアント及びデータ量が増大するにしたがってA-B地点間の
    > ネットワーク帯域では処理しきれなくなりました。
    >
    > そこで、B地点にもサーバを設置し、SQLServerのレプリケーション機能を使用
    > することを考えております。
     既に各種レプリケーションに習熟していますか?

     仮にそうでなければ、

    ・A地点にターミナルサービス用サーバー追加。アプリを実行

     B地点のクライアントは端末的に使用

    を評価してみた方がいいと思います。

     

     レプリケーションでやろうとすると、かなり難度の高いパターンに見えます。

    2007年11月5日 13:38
  • それは何台のクライアントが、どんなアプリケーションを実行するかによりますね。

    この使い方でぱっと思いつくボトルネックは次の3つです。

     

    1. ライセンス数

    当然ですがライセンス数以上の端末はターミナル サーバーに接続できません。これが足りなくなったら足すしかありません。

     

    2. CPU

    クライアント アプリケーションが重い処理をしているなら、10 人が使えば CPU も一人の時の 10 倍使います。CPU がボトルネックに達したら CPU をアップグレードするか、ターミナル サーバーを増やします。

     

    3. ネットワーク

    RDP プロトコルの通信が発生しますからね。これは色数を減らしたり音を再生しないことでネットワーク トラフィックを減らせます。解像度を落とすことも出来ますが、フルスクリーンでないと使用感に違和感が出るのでユーザーには歓迎されないでしょう。

     

    ということで、ネットワークの帯域幅を心配しているのならクライアントの設定を変更して数台のクライアントを用意してみて、どれくらいの帯域を使うのか調べてみてはいかがでしょうか。

    特定のポートがどれくらいの帯域を使っているかは、NEGiES で調べることができます。

     

    でもまあ、この方法で問題が解決すると決まったわけではないんで帯域幅の拡大や運用方法の変更もオプションとして提示したほうがよいとは思いますよ。テーブルデザインが変わってはいけないのならトランザクション レプリケーションは使えません。どの方法もメリットとデメリットがありますね。

    2007年11月6日 3:31

すべての返信

  •  米田です。

     

    > B地点のクライアント及びデータ量が増大するにしたがってA-B地点間の
    > ネットワーク帯域では処理しきれなくなりました。
    >
    > そこで、B地点にもサーバを設置し、SQLServerのレプリケーション機能を使用
    > することを考えております。
     既に各種レプリケーションに習熟していますか?

     仮にそうでなければ、

    ・A地点にターミナルサービス用サーバー追加。アプリを実行

     B地点のクライアントは端末的に使用

    を評価してみた方がいいと思います。

     

     レプリケーションでやろうとすると、かなり難度の高いパターンに見えます。

    2007年11月5日 13:38

  • 米田さん。ありがとうございます。

    レプリケーションは経験がなく、さらに上記のような状況になってから調べ始めているところなので
    技術的に不安があります。


    そこでご提案いただいたターミナルサービス用サーバを追加する件ですが、
    B地点のクライアントはデータの参照、更新に時間がかかっていますが、クライアント端末は
    業務アプリとして使用しているため画面の表示も重要になります。
    上記のような状態でターミナルサービスとしてB地点からA地点にアクセスした場合に、画面の表示更新は
    スムーズに行えるものでしょうか?


    流れるデータ量は各端末でアプリを実行した場合より増えたりはしないのでしょうか?
    データ更新が終了していても画面の更新が終わらなければユーザーは耐えられないような気がします。

    2007年11月6日 1:18
  • それは何台のクライアントが、どんなアプリケーションを実行するかによりますね。

    この使い方でぱっと思いつくボトルネックは次の3つです。

     

    1. ライセンス数

    当然ですがライセンス数以上の端末はターミナル サーバーに接続できません。これが足りなくなったら足すしかありません。

     

    2. CPU

    クライアント アプリケーションが重い処理をしているなら、10 人が使えば CPU も一人の時の 10 倍使います。CPU がボトルネックに達したら CPU をアップグレードするか、ターミナル サーバーを増やします。

     

    3. ネットワーク

    RDP プロトコルの通信が発生しますからね。これは色数を減らしたり音を再生しないことでネットワーク トラフィックを減らせます。解像度を落とすことも出来ますが、フルスクリーンでないと使用感に違和感が出るのでユーザーには歓迎されないでしょう。

     

    ということで、ネットワークの帯域幅を心配しているのならクライアントの設定を変更して数台のクライアントを用意してみて、どれくらいの帯域を使うのか調べてみてはいかがでしょうか。

    特定のポートがどれくらいの帯域を使っているかは、NEGiES で調べることができます。

     

    でもまあ、この方法で問題が解決すると決まったわけではないんで帯域幅の拡大や運用方法の変更もオプションとして提示したほうがよいとは思いますよ。テーブルデザインが変わってはいけないのならトランザクション レプリケーションは使えません。どの方法もメリットとデメリットがありますね。

    2007年11月6日 3:31

  • Jermain さん、ありがとうございます。

    レプリケーションで解決可能か、それともターミナルサービスなど他の方法を使用するかなど
    含めてもう一度総合的に検討してみたいと思います。

    ちなみにテーブルデザインを変更しないとなるとレプリケーションは使えないでしょうか?
    2007年11月6日 6:18
  •  うっち さんからの引用

    ちなみにテーブルデザインを変更しないとなるとレプリケーションは使えないでしょうか?

     

    言葉が足りませんでした。失礼しました。テーブルに主キーがないとトランザクション レプリケーションでパブリッシュすることはできません。つまり、主キーがないテーブルをパブリッシュしたい場合は主キーを追加しなければならないので、テーブルデザインを変更しなければなりません。

     

    "主キーがないテーブルがある場合は" をスキップしてしまいました。

    2007年11月6日 20:10

  • たびたびありがとうございます。

    レプリケーション予定のDBは全テーブルに主キーが設定されていますので
    その点は大丈夫そうです。

    もう少しレプリケーションについて調べてみます。
    ありがとうございました。

    2007年11月7日 4:49