QlikView Server のクラスター化

本章では、クラスター化された障害への適応力のある QlikView Server の構成を構築するためのアーキテクチャおよびインストール要件とオプションについて説明します。

次の図は、クラスター化および負荷分散化された QlikView Server の構成を示しています。

次の図は、障害への適応力のある、クラスター化され負荷分散化された QlikView Server の構成を示しています。ここでは AccessPoint ロード バランスが使用されています。

QlikView Server のロード バランス機能は QlikView Web ポータルの AccessPoint に含まれています。本章では、適宜、ネットワーク ロード バランスを使用して、このコンポーネントに障害への適応力をつける方法を説明します。

QlikView Server をクラスター化する理由

QlikView Server をクラスタ化ーすることにより、以下の目標を達成できます。

水平ユーザー スケーラビリティ

単一の QlikView Server によって提供できるよりも多くのリソースが必要な場合は、サーバーを追加することができます。たとえば、サーバーが 100 人の同時ユーザーに対応できるのに対し、200 人の同時ユーザーをサポートしなければならない状況においては、サーバーを追加できます。この場合、最初の 100 人のユーザーをサーバー A、次の 100 人をサーバー B に割り当てることができます。また、障害への適応力を提供できるようサーバーをクラスター化することも可能です。

障害への適応力

ユーザー数が増えると、QlikView へのユーザーの障害適応力も高まります。QlikView Server をクラスター化すると、構成に障害への適応力を組み込むことができます。単一のサーバーでは 100 人のユーザーをサポートできる上記の例の場合、障害への適応力を構成に組み込むために、3 台のサーバーが使用されます。これにより、1 台のサーバーを使えなくなっても (ハードウェアの故障などにより)、システムはまだ 200 人のユーザーに対応できます。3 台のサーバーすべてがアクティブなノードであれば、すべてのサーバーをフル稼働しなくても応答時間を短縮することができます。また、ノードが失われた場合でも影響されるユーザー数を少なくできます。

QlikView ではセッション復元のオプションが一切提供されていません。実際には、QlikView クラスターのノードが失われるとユーザーが実行していた分析も失われ、クラスターに再接続して作業を再開することになります。ただしこれは、QlikView アプリケーション内のデータが失われてリロードが必要になるということではありません。データはファイル システムの .qvw ファイルに保存されています。アプリケーションで何を選択してあったのかが失われてしまうのみです。

負荷分散

QlikView の構成では、QVS クラスター内にあるすべてのマシンの能力をフル活用するために、負荷分散アルゴリズムを採用しています。どの QVS を使うかは、AccessPoint が稼働する Web サーバーにより決定されます。QVS の負荷分散方法には、3 つのオプションがあります。参照:QVS の負荷分散オプション

クラスタ化ーされた QlikView 構成の要件

クラスター化された QlikView 構成の構築には、3 つの高レベルの必要条件があります。

  1. クラスター化された QlikView Server のライセンス キー
  2. ルートフォルダー用の共有ストレージ領域
  3. 同じビルド番号

クラスター化された QlikView Server のライセンス キー

クラスター化された環境では、QlikView Server マシンは同じライセンス キーを使ってインストールされます。これはクラスター化できるよう有効にしておかなくてはなりません。ライセンス認証ファイル (LEF) で以下のエントリを調べると確認できます。

NUMBER_OF_CLUSTER_NODES; 2 (クラスター内のノード数)

クラスター化された QlikView Server は共有ストレージを介して構成とライセンス情報をサーバー間で共有するため、構成およびライセンス管理はすべてのノードで QlikView Management Console (QMC) から 1 回だけ実行する必要があります。

サーバーは同じネットワーク サブネット上にインストールし、ルート ドキュメント ディレクトリを共有しなくてはなりません。これは共有ネットワーク ストレージの要件になります。構成情報は Persistent Global Objects (.pgo) ファイルに保存されます。

10 分たってもサーバーを起動またはリセットできない場合は、上記の LEF エントリをチェックしてください。これは通常、許可されている数よりも多くのマシンに QlikView Server がインストールされていることを示しています。

共有ネットワーク ストレージ

共有ネットワーク ストレージは上記の .pgo ファイルだけではなく、クラスターで必要な QlikView アプリケーションのストレージでも必要です。これにより、クラスターのノード全体で共有する協同オブジェクトも有効になります (.shared ファイルを使用)。

QlikView では、ドキュメント (.qvw ファイル)、.pgo.meta、および共有ファイル (.Shared または .TShared) のストレージを Windows ベースのファイル シェアでホストする必要があります。他のタイプのシステムでのファイルのホストはサポートされておらず、不安定な QVS クラスターが作成され、CAL が消失して QVS が止まる可能性があります。QlikView は QlikView Server から共有された SAN の使用をサポートしています。

注: QlikView Server 11.20 から QlikView Server 12.10 以降にアップグレードするときに、バックエンド ファイル システムが原因でインストールに各種の問題が発生する場合があります。QlikView Server 12.10 以降のバージョンではディスクをより集中的に使用するので、QlikView 11.20 より大規模なファイル サーバーを必要とします。QlikView 展開を計画する場合には、ストレージの種類およびリソース容量に留意することが重要です。詳細については、次の Qlik サポートの記事を参照してください。「QlikView and its backend File Share System」(QlikView とそのバックエンド ファイル共有システム)
注: QlikView では、Windows Distributed File System (DFS) をサポートしていません。

QVS の負荷分散オプション

QVS は 3 つの負荷分散戦略をサポートしています。

  • Random (ランダム) (既定設定): ラウンド ロビン タイプの戦略で、セッションがクラスターのノード全体で配布されるため、ほとんどのユーザーに適しています。
  • Loaded document (ロード済みドキュメント): 同じドキュメントのセッションが同じサーバーにルーティングされている場合に使用されます。この戦略は、クラスター内の単一のノードよりも多いドキュメントを取り扱うことができる構成向けです。AccessPoint は、ドキュメントがすでにロードされているかどうか、またサーバー上で利用できる RAM の容量に基づいて決定を下します。
  • RAM がオーバーロードしているCPU (CPU with RAM overload):QlikView Web Server (QVWS) は、(1) RAM と (2) CPU 使用率という 2 つの要素に基づいてトラフィックをルーティングできます。ノードは以下の基準を使用して選ばれます。
    • すべての利用可能なノードで RAM をすでに利用 (低レベル) できる場合は、最低 CPU 使用率のノードを選択します。
    • 利用可能なあらゆるノードで RAM の使用量が中程度の場合は、利用可能な RAM が最も多いノードを選びます。

QVS 負荷分散戦略を設定するには、QMC で [System] (システム) > [Setup] (設定) > [QlikView Web Servers] の順に選択してください。[AccessPoint] タブで Web サーバーを選択します。

Web Server の負荷分散

ネットワーク ロード バランサーは AccessPoint の障害への適応力を提供し、利用可能な AccessPoint サーバーにセッションをルーティングします。この機能はサードパーティのソフトウェアとハードウェアによるものです。

ロード バランサーに関してはいくつかの要件があります。

  • セッションの持続性/スティッキー セッションのサポート: 通常、クッキーを使用することでユーザー セッションをクラスター内の同じノードで存続できるようにします。
  • Availability (可用性): ロード バランサーは AccessPoint のウェブ サーバーと QlikView サーバーの可用性をチェックします。
  • ロード バランス アルゴリズムの何らかの形で、どのサーバーのロードが最も少ないか判定します。

セッションの持続性

ユーザーのセッションを一貫して同じサーバーにルーティングすることが要件になっています。これを行う方法はデバイスによって異なります。利用可能なオプションについては、ロード バランサー文書を参照してください。

可用性のチェック

AccessPoint の特別な Web ページでは、システムのステータスを自動的にチェックできます。

http://myAccessPoint/QvAjaxZfc/QvsStatus.aspx

AccessPoint とクラスター内の少なくとも 1 つの QlikView Server が応答する場合、このページは 200 の http ステータス コードを戻します。このページが返すその他のステータス コードは、エラーとみなされます。このページの一般的なエラーには以下のようなものがあります。

  • 404: The AccessPoint is unable to respond. Check the web server. (404:AccessPoint は応答できません。Web サーバーの設定を確認してください。)
  • 503: No QlikView Servers responded to the AccessPoint and therefore it cannot service user requests. (503: QlikView Server は AccessPoint に応答しないため、ユーザーのリクエストに対応できません。)

QlikView Server クラスターのステータスも Web ページに表示されます。

QlikView クラスターの構築とインストール

QMC を使用して QlikView Server クラスターを構成、有効化するには、以下の手順に従ってください。

  1. クラスターに最初の QlikView Server をインストールしてライセンスを授与します。これは QlikView Server の最初のコピーです。
  2. クラスター内のすべての QlikView Server がアクセスできるファイル システム上のフォルダーを指すよう、ドキュメント フォルダーを構成します。
  3. クラスターに次の QlikView Server をインストールします。
  4. すべての QlikView サービスがローカル管理者として実行され、「QlikView Administrators」ローカル グループのメンバーであることを確認します。
  5. QMC で [システム (System)] > [設定 (Setup)] を開き、サーバーを選択します。その後、[General (基本設定)] タブに進み、ライセンスのコントロール番号と、クラスターの 2 番目の QlikView Server へのアドレスを入力します。
  6. クラスターの名前を適切な名前に変更します。
  7. クラスターの QlikView Server ノードでステップ 3~5 を繰り返します。
  8. AccessPoint の設定で、クラスターが [Server Connections (サーバー接続)] で選択されていることを確認します。
  9. これでクラスターの設定は終了し、使用準備が整いました。