• TOP > Dynamics CRM > CRMのインストールと構成
  • CRMレポート拡張機能のインストール
  • CRMの高可用性オプション

• 役割グループに分割してインストールできる。
• それぞれのコンポーネントに高可用性ソリューションを適用できる。

補足（本ページの構成）: 「役割ごとに分割できるから、
役割ごとに別々の高可用性の手段を当てる」というのが本ページの骨子である。
冗長化アーキテクチャで言えば、

対象	手段	性格
フロントエンド	NLB	ステートレスな負荷分散
SQL Server	WSFC / AlwaysOn	ステートフルなフェイル・オーバ
ドメイン コントローラ	複数台	もともと分散システム
E-mail Router	クラスタリング	フェイル・オーバ

という当て方になる。
状態を持つか持たないかで手段が変わるという原則が、
そのまま現れている構成である。

• Microsoft Dynamics CRM Server マルチプルサーバー トポロジのサポート
  https://technet.microsoft.com/ja-jp/library/hh699756.aspx

• CRM Server
• SQL Server
• AD DC

• 冗長電源
• RAID
• メモリ（ホットスワップ）
• NIC チーミング

• SQL Server は単一のコンピュータに分離されていること。

• 少なくとも以下の 2 つの役割のインストールが必要

  • Web アプリケーションサーバー
  • 組織 Web サービス

• 従って、以下の役割グループが
  ネットワーク負荷分散可能と言える。

  • フルサーバー
  • フロントエンドサーバー

• Microsoft Dynamics CRM Server を複数のコンピュータにインストールする
  https://technet.microsoft.com/ja-jp/library/Hh699803.aspx

• プロトコル：（TCP, UDP の）"両方"
• 分散方法：ユニキャストモード
• アフィニティ：単一モード

補足（アフィニティ「単一」の意味）: NLB のアフィニティを
単一（Single）にすると、同じクライアント IP からの要求が常に同じノードへ
振り分けられる（いわゆるスティッキー セッション）。
CRM の Web アプリケーションがセッション状態を持つため必要になる設定である。

反面、

• プロキシ経由で多数のクライアントが同一 IP に見える環境では偏る
• ノード障害時にセッションが失われる

という弱点がある。後述の
「展開で NLB を使用する」を有効にすると
WIF のセッション Cookie が暗号化・署名されるようになり、
ノード間でセッションを引き継げるようになる。

• SPN

• 1 台目
  • ［展開オプションの指定］ページ → ［新しい展開の作成］
  • ［セキュリティ アカウントの指定］ページ → SPN の構成で作成したアカウントを指定する。
• 2 台目
  • ［展開オプションの指定］ページ → ［既存の展開に接続し、必要な場合はアップグレードする］
  • ［セキュリティ アカウントの指定］ページ → SPN の構成で作成したアカウントを指定する。

補足（両ノードで同じアカウントを使う理由）: SPN は
サービス名とアカウントを 1 対 1 で結びつけるため、
仮想クラスター名に対する SPN は 1 つのアカウントにしか登録できない。
したがって、全ノードの CRMAppPool を
同一のドメイン アカウントで動かす必要がある。
ここを揃えないと、一部のノードに当たったときだけ
Kerberos 認証が失敗する、という切り分けの難しい症状になる。

• 展開マネージャーの［Dynamics CRM］の［プロパティ］の［Web アドレス］タブで、

  • 仮想クラスター名が表示されていることを確認する。
  • ［詳細設定］をクリックし、［展開で NLB を使用する］を選択する。
    これにより、次のように、Windows Identity Framework (WIF) を構成する。
    • Microsoft Dynamics CRM セッション認証クッキーの暗号化、暗号化解除。
    • 署名に暗号証明書を使用する。

• Microsoft Dynamics CRM を IFD 用に構成
  Set-Crmsetting ifdSettings PowerShell コマンドを実行するか、
  または展開マネージャーを起動し、
  インターネットに接続する展開の構成ウィザードを実行してドメイン値を追加または修正する。

  • NLB 仮想クラスター ドメイン名を使用
    • ［Web アプリケーション サーバーのドメイン］
    • ［組織 Web サービスのドメイン］
    • ［検出 Web サービスのドメイン］

補足: IFD 構成については
CRMインターネット展開用の構成（IFD）を参照。

• クラスタリング

アクティブ / パッシブのみサポート

• SQL Server クラスタを構築
• SQL Server クラスタの仮想サーバ名を使用して CRM サーバをインストール
  （「SQL Server の選択」ページで SQL Server クラスタの仮想サーバ名を入力）

• 既存の SQL Server をバックアップしてクラスタにリストアする。

• Web アプリケーションを実行しているコンピュータのレジストリを編集。

  • Changing a Microsoft Dynamics CRM 2013 SQL Server for a Deployment - Microsoft Dynamics CRM Community
    https://community.dynamics.com/crm/b/tsgrdcrmblog/archive/2014/08/15/changing-a-microsoft-dynamics-crm-2013-sql-server-for-a-deployment

    • On the computers running Microsoft Dynamics CRM, modify the registry value:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\configdb
    • Old Value
      DataSource=SQLServer;InitialCatalog=MSCRM_CONFIG;Integrated Security=SSPI
    • New Value
      DataSource=NewSQLServer;InitialCatalog=MSCRM_CONFIG;Integrated Security=SSPI

• IIS を再起動する。

• 組織データベースだけバックアップ・リストアで移行

• 展開マネージャで以下を実施

  • 組織を無効化
  • 組織を編集（SQL Server 名を SQL Server クラスタ名に変更）
  • 組織を有効化

• IIS を再起動する。

補足（2 つの移行手順の違い）: 構成データベース（MSCRM_CONFIG）の
接続先はレジストリに、組織データベースの接続先は
構成データベースの中に持たれている。
このため、

• 全体を移す → レジストリを直接書き換える（サポート外に近い手順）
• 組織だけ移す → 展開マネージャの GUI で完結する

という違いになる。可能なら後者を選ぶ方が安全である。

利用可能

利用可能だが将来削除され、AlwaysOnに置き換わる。

• AlwaysOn 可用性グループ

利用可能

移行メモ: 元ページの予想どおり、データベース ミラーリングは
SQL Server 2012 で非推奨となり、現在は AlwaysOn 可用性グループが標準である。

そもそも分散システムなので 2 台以上あれば良い。

クラスタリングに対応しており、
高可用性とフェイル・オーバー機能を提供。

オプションであり、アクセスを妨げないが、影響は考慮しておく。

• 本 Wiki 内
  • CRMのインストールと構成
  • CRMのサーバ機能
  • 冗長化アーキテクチャ
  • NLB / MSCS/WSFC
  • SPN
  • ローリング・アップグレード

---

Tags: Dynamics CRM