none
Exchange2013環境で特定のCASサーバにＲＰＣセッション集中 RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    以下の環境で特定のCASサーバへＲＰＣセッションが集中する事象が発生しています。設定上確認するポイントがあれば教えてください。

    ＜サーバ環境＞

    　CASサーバ：３台（負荷分散構成：負荷分散装置で設定）、MBXサーバ（３台、DAG構成）

    ＜クライント環境＞

    　Windows7+Outlook2010,windows10+Outlook2013,Windows10+Outlook2016(複数あり）

    ＜状況：RPCセッション数が特定のCASサーバに集中する＞

    　CAS＃１：１００００　CAS＃2：１００００　CAS#3：４７０００　CAS#3を負荷分散からはずした場合でも１８０００セッションは残っている。（接続先はＭＢＸ#1、＃２、＃３）

    ＜メールボックス利用形態＞

    　・個人メールボックス（クライアントログオンユーザー用のメールボックス）・共有メールボックス（必要なユーザーにフルアクセス権を与えて、Outlook上でアカウント追加実施）

    よろしくお願いいたします。

    　

    nakamoto

    2019年2月5日 2:24
    |

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票

    CAS3号機は、別サイトにお配置していたりしないでしょうか？

    同一サイトであれば、原則として、特に偏ることは本来ないはずです。

    もしくは、http接続時にプロキシを経由するといった設定をクライアントに行っている場合、プロキシ側で除外設定などを行わなければ、CASへのアクセスもHTTPSの接続が発生すると思うので、プロキシ経由などになることで接続に偏りが出ることは考えられます。



    • 編集済み Hotaka 2019年2月5日 3:36
    2019年2月5日 3:05
    |
  • Question
    サインインして投票
    0
    サインインして投票

    CASサーバについては＃１、＃２、＃３とも同一サイトに存在しています。接続に関してはプロキシは経由させていない状態です。

    nakamoto

    2019年2月5日 3:50
    |
  • Question
    サインインして投票
    0
    サインインして投票
    ちなみに RPC 接続はクライアントからのセッションという理解でよいですか？
    2019年2月5日 5:08
    |
  • Question
    サインインして投票
    0
    サインインして投票

    Autodiscover(SCP)含めて各種サービスのエンドポイントは全て負荷分散装置向くように設定されているのですよね。

    Outlook側でタスクトレイとCtrl+右クリックで接続状態を開いていただいて、負荷分散装置のVIPを向いているのではなくCAS#3のFQDNを向いているセッションが無いか確認できますでしょうか？

    2019年2月13日 0:45
    |
  • Question
    サインインして投票
    0
    サインインして投票

    あらためて確認しました。

    １．Outlook2016接続状態の確認

    　　SMTPアドレス：Outlookサインオンアカウント　プロキシサーバ：実CASサーバ（CAS#1~CAS#3）

    　　サーバー名：メールボックスのExchange GUID+@メールドメイン名

    ２．Get-OutlookAnyWhereコマンドでの確認結果

    　　CASサーバ＃１のInternalHostname　→　CSAサーバ＃１

    　　CASサーバ＃２のInternalHostname　→　CSAサーバ＃２

    　　CASサーバ＃３のInternalHostname　→　CSAサーバ＃３

    　　※本設定が「１．Outlook2016接続状態の確認」で負荷分散装置のVIPを向いていないのと関係があるのでしょうか？　　

    　　※各サーバのInternalHostnameは負荷分散装置に向ける必要がありますでしょうか？

    ３．その他

    　　CASサーバ：３台　MBXサーバ：３台を順次、再起動しましたが、特定のCASサーバ（＃３）は再起動直後

    　　でも10000セッション存在しておりました。（他２台は１０００セッション）

    　　※CASサーバへセッション（Outlook、MBXサーバ）が残っているように思われます。Outlook、MBXサーバで

    　　　セッションを維持（キャッシュ）する動きはあるのでしょうか？ある場合、クリアする方法はありますでしょうか？

    よろしくお願いいたします。

    　　

    　　　

    　

    nakamoto

    2019年6月18日 7:23
    |
  • Question
    サインインして投票
    0
    サインインして投票
    セッションはどのように見ていますか？通常は、パフォーマンスモニタから確認すると思いますが
    2019年6月18日 7:44
    |
  • Question
    サインインして投票
    0
    サインインして投票
    パフォーマンスモニタで常時確認しています

    nakamoto

    2019年6月18日 8:32
    |
  • Question
    サインインして投票
    0
    サインインして投票

    RPCセッション数の確認は各CASサーバ上のパフォーマンスモニタで以下の値を取得しています。

    ローカルコンピュータ￥ASP.NET Applications￥Requests Executing￥_LM_W3SVC_1_ROOT_RPC

    よろしくお願いいたします

    nakamoto

    2019年6月19日 0:38
    |
  • Question
    サインインして投票
    0
    サインインして投票

    まず、CASに関して再起動されれば、RPCセッションはリセットされます。(リセットが適切かどうかは置いておきますが)

    これは、IISの動作なので、Exchange 固有の動きではありません。

    したがって、再起動後に　10000セッション残っていたというわけではなく、新規の接続が10000セッション部合ったということかと思います。

    明らかな偏りが発生していますが、LB側の設定は正しいのでしょうか。LBから切り離してもセッションが維持されているのは、LB経由でない接続があるからではないですか？

    Exchange 側の設定でここまでの偏りが発生するとはあまり思えません。

    2019年6月19日 5:21
    |
  • Question
    サインインして投票
    0
    サインインして投票

    >したがって、再起動後に　10000セッション残っていたというわけではなく、新規の接続が10000セッション部合ったという>ことかと思います。

    OutlookAnyWhereが以下に設定されているため、Outlookからピンポインで物理CASサーバに接続されるということはありますでしょうか？

    Get-OutlookAnyWhereコマンドでの確認結果

    　　CASサーバ＃１のInternalHostname　→　CSAサーバ＃１

    　　CASサーバ＃２のInternalHostname　→　CSAサーバ＃２

    　　CASサーバ＃３のInternalHostname　→　CSAサーバ＃３

    nakamoto

    2019年6月26日 0:39
    |
  • Question
    サインインして投票
    0
    サインインして投票

    特定のCASに絞っているわけではないので、関係が無いように思います。

    SCPの値ってどうなっているのでしょうか

    https://blog.engineer-memo.com/2010/12/25/exchange-の-autodiscover-について-ドメイン環境で-scp/
    • 編集済み Hotaka 2019年6月26日 5:24
    2019年6月26日 5:11
    |
  • Question
    サインインして投票
    0
    サインインして投票

    SCPの値（AutoDiscoverServiceInternalUri）は正しく負荷分散装置が設定されていました。

    nakamoto

    2019年7月2日 8:31
    |
  • Question
    サインインして投票
    0
    サインインして投票

    であれば、ドメイン端末はSCPの値を見て Outlookで、対象のFQDNに接続しますので、LBがどう後続のCASに流しているかだけのように思えます。

    ただ、問題が長期化しているのであれば、MSのサポートに確認して切り分けたほうが良い問題に思えます。



    • 編集済み Hotaka 2019年7月3日 8:24
    2019年7月3日 8:06
    |