メインコンテンツへスキップ
管理および監視コンソールと Web Station は同じクラスターにクラスター化されます。
NLB (Network Load Balancing) クラスターは、Application Server のほか、IIS (Internet Information Services) サービスを使用する管理および監視コンソールや Web Station のインストールにも使用されます。ワークロードを分散し、リクエスト処理を高速化するため、Application Server は NLB クラスターにデプロイできます。 Network Load Balancing 機能の詳細については、Microsoft の Web サイトのこちらのページを参照してください。

​
Application Server の NLB クラスターの設定

このセクションでは、Application Server 用の NLB クラスターを設定する手順を順を追って説明します。 管理および監視コンソールと Web Station は、Application Server とともにクラスター化されます。 NLB クラスター設定の詳細については、Microsoft の Web サイトを参照してください。
以下で使用するアドレス、コンピューター名、ドメイン名などは必須ではなく、管理者が変更できます。
クラスターの設定 クラスターを設定するには、次の手順を実行します。
  1. 各クラスター ノードに Application Server をインストールします。データベース、ファイル ストレージ フォルダー、Processing Server、Licensing Server、および Application Server クライアントは別のコンピューター上に配置する必要があります。このコンピューターには、クラスター内のすべてのノードからアクセスできなければなりません。
  2. Windows Features で、クラスター内の各ノードに Network Load Balancing を追加します。これを行うには、Server Manager のメイン ウィンドウで Add Features リンクをクリックします (Start → Administrative Tools → Server Manager をクリック) 。
  3. クラスター全体としてノードにアクセスするための IP アドレスをクラスターに割り当てます (これは仮想クラスター アドレスになります) 。これを行うには、いずれかのノードで Network Load Balancing Manager を開き (Server Manager → Tools → Network Load Balancing Manager をクリック) 、クラスターを右クリックしてショートカット メニューから Cluster Properties アイテムを選択します。
ノードでクライアント/クラスター トラフィックとその他のネットワーク トラフィックに単一のネットワーク インターフェイスを使用する場合 (通常、Multicast モードではこの構成です) 、クラスター内の各ホストには専用の IP アドレスが必要です (すべてのクラスター ノードに共通の仮想アドレスに加えて) 。ホストは、Telnet、SSH、その他のプロトコルを介してクラスター ノードへの接続を受信する場合や、クラスター ノードから外部へ接続する場合に、仮想クラスター アドレスではなく専用の IP アドレスを使用します。 すべてのクラスター ノードは、クラスター宛てのすべての受信トラフィックを受信する必要があります。特定のクエリに対してどのクラスター ノードが応答するかは、負荷分散アルゴリズムによって決定されます。Unicast と Multicast のどちらを選択するかは、ネットワーク構成によって異なります。
  1. IIS 用の Performance Monitor (Microsoft Management Console のツールバーからアクセス可能) を使用して、ノードのアクティビティを監視できます。Web Service オブジェクトで、各ノードについて Default Web Site の ISAPI Extension Requests/sec カウンターを追加します (これは IIS 内での Application Server の場所です) 。
クラスターの動作モード Unicast と Multicast のどちらを選択するかは、ネットワーク構成によって異なります。これら 2 つの方法の詳細については、Microsoft の Web サイトのこのページを参照してください。 クラスター内のワークロードの負荷分散とホストの設定 クラスター トラフィックの負荷分散とフィルタリングは、ポートごとに設定できます。 ABBYY FlexiCapture の動作には TCP プロトコルが必要です。フィルタリング モードには、single host と multiple host の 2 つがあります。
  • Single host このモードではフォールト トレランスは提供されますが、ワークロードの負荷分散はできません。一度にアクティブになるクラスター ノードは 1 つだけです。
  • Multiple host 事前定義された範囲のポートからのトラフィックは、クラスター内で最も優先順位の高いノードによって処理されます。すべてのクラスター ノードが同時に動作します。このモードでは、ワークロードの負荷分散とフォールト トレランスの両方が提供されます。
事前定義された範囲のポートからのトラフィックは、各ノード間で負荷分散されます。さらに、Affinity パラメーターを次のように設定できます。
  • None (推奨されません) このオプションを選択すると、1 つのクライアントからの複数の接続 (TCP セッション) が異なるノードによって処理されることがあります。
  • Single (推奨) このオプションを選択すると、1 つのクライアントからのすべての接続が 1 つのノードによって処理されます。
  • Network (Class C) (推奨) このオプションを選択すると、TCP/IP Class C アドレス空間からのすべてのクエリが 1 つのノードによって処理されます。これは、クライアントとクラスターの間にプロキシサーバーがある場合に必要になることがあります。
Application Server の設定 Application Server を設定するには、次の手順を実行します。
  1. クラスター内のすべてのノードからアクセスできる共有フォルダーを作成します。
  2. Microsoft SQL Server、Azure サーバー、Oracle サーバー、または PostgreSQL サーバーをインストールします。これらのサーバーは、クラスターのすべてのノードから利用できる必要があります。
  3. すべてのクラスター ノードに Application Server をインストールします。
  4. 最初のクラスター ノードで、管理および監視コンソールを実行し、データベースを作成して、ファイル保存用の共有フォルダーを指定します。
  5. 残りの各クラスター ノードで、管理および監視コンソールを実行し、作成したデータベースに接続します。 重要! この操作では、SQL 認証を使用する必要があります。
  6. SQL Server、Azure サーバー、Oracle サーバー、または PostgreSQL サーバーで、IIS を実行しているアカウントに対応する、すべてのクラスター ノード上のすべてのユーザーに対し、そのデータベースへのフル コントロールのアクセス許可を付与します (サービス一覧で World Wide Web Publishing Service が実行されている必要があります) 。最初のノードの権限は、データベースの作成時に自動的に付与されます。その他の権限は手動で付与する必要があります。既定では、IIS はユーザー Network Service で実行されます。この場合、IIS が NodeN という名前のコンピューター上で実行されているとすると、サーバー上でユーザー DomainName\NodeN$ にフル コントロールのアクセス許可を付与する必要があります。
  7. クラスター内で Application Server を利用できず、それでも PING 要求がクラスターに到達する場合は、IIS がクラスター内で利用可能かどうかを確認してください。この確認を行うには、静的な *.html ファイルをフォルダー %systemdrive%\inetpub\wwwroot に配置し (通常、このフォルダーにはすでに iisstart.htm ファイルがあります) 、ブラウザーでこのファイルを開きます: \ClusterAddress\iisstart.htm。ファイルを開くときは、ブラウザーのプロキシサーバー設定を確認してください。
Application Server クライアントの実行 すべてのクラスター ノードを 1 つのドメインに配置し、Application Server クライアントをドメイン ユーザー アカウントで実行することをお勧めします。 以下の理由により、ローカル ユーザー アカウントで Application Server クライアントを実行することは推奨されません。 通常の (つまり、クラスター化されていない) Application Server の構成では、次の認証方法を使用できます。Application Server がインストールされているコンピューター上に、独自のユーザー名とパスワードを持つローカル ユーザーを作成します。その後、任意のクライアントがこのユーザーのアカウントで Application Server に接続できるようになります。 クラスター化構成では、クライアント要求を処理する Application Server が異なるコンピューター上に配置される可能性があり、それに応じて実際のユーザー名も変わります。node1 コンピューターではユーザー名は node1\User となり、node2 コンピューターでは node2\User になります。これにより、システムの動作に支障が生じる可能性があります。 Application Server クライアントをドメイン ユーザーで実行すると、この問題を回避できます。 ドメインに属していないリモート コンピューター上のクライアントを接続するには、基本認証と、クラスターが属するドメイン内のユーザー アカウントを使用できます。クラスター化された Application Server がクラスター ドメイン内にあり、検証オペレーターのコンピューターがこのドメイン内にないとします。必要なのは、クラスター ドメイン内にユーザー cluster\VerificationOperator 用のアカウントを作成し、そのアカウント名とパスワードを検証オペレーターに伝えることだけです。これで検証オペレーターは、このアカウントと Verification Station 上の基本認証を使用して Application Server に接続できるようになります。
クライアントで基本認証を使用するには、IIS でフォルダー FlexiCapture12\Server に対して基本認証を必ず有効にしてください。そうしないと、接続を試みたときにユーザーに HTTP 401 エラーが表示されます。