システム管理者またはクラスタ管理者は、クラスタの機能およびパフォーマンスをモニタして、実運用に耐えうるようにクラスタの構成をチューニングする必要があるかもしれません。この章では、クラスタの機能調整、トラブルシューティングなどに役立つ情報について説明します。
この章で説明する項目は、以下のとおりです。
管理ツール
SSL 証明書の作成
同期化ツール
クラスタ管理コンソール（CMC）
トラブルシューティング
Turbolinux Cluster LoadBalancer 11 にはクラスタを管理するためのツールがいくつ含まれます。そのうち turboclusteradmin および tlclbconfig プログラムについては、第4章ですでに説明しました。これらはクラスタを構成し、その構成を変更するために使用する主要ツールです。
クラスタの構成変更とは、主に ATM、サービスノード、およびサービスの追加（削除）を行うことです。これは、初めてクラスタを構成したときの手順とほとんど同じです。主な特徴は、クラスタの運用中であっても、簡単に新しいノードやサービスを追加できることです。まず最初に単純な構成のクラスタから初めて、徐々にノードやサービスを追加していくことを勧めているのはこのためです。複雑なシステムよりも、単純なシステムから作業を開始する方が簡単です。
クラスタの設定を変更するもう 1 つの理由は、クラスタのパフォーマンスを最適化するためにチューニングを行うためです。
クラスタの実行に成功したら、クラスタの運用形態に合わせてチューニングを行う必要があるかもしれません。クラスタのパフォーマンスを最適化するのに修正できるパラメータがいくつかあります。チューニングできる主要なパラメータは、カーネルモジュールが使用するテーブルサイズと時間設定です。
クラスタのパフォーマンスを最適化するときは、ネットワークアナライザなどの高度なネットワークモニタリングツールを使用できます。ATM が生成するネットワークトラフィックのオーバーヘッド量を判断できます。このオーバーヘッドには、ハートビートブロードキャスト、サービスノードへの ping、およびエージェントによるサービスチェックが含まれます。また、チェックの頻度も調整できます。チェックの間隔を増やすと、サービスノードの 1 つが停止したときにサービスが使用できなくなる時間も増えることに注意してください。
調整が必要なパラメータの第一の候補は、カーネルモジュールが使用するテーブルサイズです。SpeedLink カーネルモジュールには、サーバー、サービス、およびコネクションに対するテーブルが存在します（SpeedLink については 項8.1 を参照してください）。これらのテーブルは、クラスタが受け取る最大利用数を保持できる十分な大きさに設定する必要がありますが、大きすぎてもいけません。サーバーやサービスの最適な数は、非常に簡単に判断できます。特にサービスの数はとても簡単に判断することができます。クラスタ化するために定義した各サービスは、テーブル内に 1 つのエントリが必要です。これらのサービスは 、tlclbconfig の［サービス設定］メニューで定義したサービスの数です。構成ファイルでは、Services セクションの Service 行で定義されています。
サーバーの数は、実際にはサーバーとサービスをペアにした数です。したがって、FTP および HTTP を処理するサービスノードが 10 ノードある場合は、サーバーテーブルの数は 20 ということになります。後でサービスノードを追加しやすくするために、現在必要な数より多少大きなテーブルサイズを指定するとよいでしょう。これは、サービスノードを追加するときにテーブルサイズを修正することはできますが、忘れてしまう可能性があるための配慮です。
コネクションの最大数を決定するのは簡単なことではありません。コネクションの最大数を低く設定すると、サービスを受け付けないコネクションの増加により、コネクションテーブルがオーバーフローを起こす可能性があります。コネクションテーブルに最適なサイズを判断する最良の方法は、クラスタの状態をモニタすることです。理想的には、一度に持つコネクションの予想最大数よりも多少大きくします。大ざっぱな方法は、コネクションの最大観測数を調べ、2 倍にすることです。これは、クラスタが突然、膨大なトラフィックを受け取らない限り、どのような状況にも対応できます。
ATM が NAT 転送方法 を使用している場合、コネクションの数を倍にしてください。これは、ATM がクライアントから NAT 変換アドレスに仮想のコネクションを作成し、NAT 変換アドレスからサービスノードに実際のコネクションを作成するからです。
これらの設定はすべて、tlclbconfig の［アドバンスドトラフィックマネジャ（ATM）設定］メニューから定義できます。また、構成ファイルでは AtmPool セクションの NumServices、NumServers、および NumConnections で定義されています。
クラスタを調整するのに使用できる時間設定に関するいくつかのパラメータがあります。クラスタに関連する時間設定は、テーブルサイズが定義されるのと同じ場所に定義されます。つまり、tlclbconfig の［アドバンスドトラフィックマネジャ（ATM）設定］メニューで定義できます。ここには、接続タイムアウト値の指定である［接続タイムアウト］とハートビートの頻度を指定する［ハートビートの周期］が含まれます。
［接続タイムアウト］は、通信のないアイドル状態のコネクションをコネクションテーブルに保持する時間を指定します。これは、クラスタで実行しているすべてのサービスに関連します。推奨値を以下に示します。
HTTP 30-60 秒
FTP 15-30 秒
Telnet 300 秒
複数のサービスをクラスタとして使用する場合は、最長のものを指定してください。
設定できるもう 1 つの時間に関するパラメータは、サービスとサービスノードをチェックする頻度です。これらの値を増やすとネットワークトラフィックのオーバーヘッドは減りますが、サービスノードがクラスタから削除される前に停止している時間が増えます。基本的に、このトレードオフをどの時点で容認するかを決定しなければなりません。サービスノードの数が少数（数台レベル）で、かつ 100Mbps のネットワーク環境下であれば、ネットワークオーバーヘッドを意識する必要はありません。
チェックの頻度を変更するには、tlclbconfig の［サーバーグループ設定］メニューから行います。ここの［サーバーのチェック］と［サービスのチェック］に 2 つの［間隔（秒）］があります。また、［タイムアウト］も含まれています。［間隔（秒）］はチェックする頻度を指定し、［タイムアウト］は、サービスノードまたはサービスが停止したと見なす応答時間を指定します。これらの設定は、構成ファイルでは ServerPool セクションで定義されています。
［間隔（秒）］は、常に対応する［タイムアウト］よりも長く設定しておく必要があります。そうしないと、最初の ping から応答を受け取る前に、別の ping が送信されてしまいます。応答を受け取とったときに、それが最初の ping に対する応答か、2 番めの ping に対する応答かがわからなくなります。