はじめに

この記事は、ユーザーが IBM Techline (注：PartnerWorldの会員様のみアクセス可能です) から正式なサイジング見積もりを取得していることを前提として、ベスト・プラクティスを記したデプロイメント・ガイドラインを提供するものです。

前の 8.0 バージョンとは異なり、この 8.5 サイジング・ガイドライン文書には、必要な Gateway サーバー・インスタンスの数を計算するスプレッドシート・サイジング計算シートは添付されていません。

8.0 の計算シートは 8.5 のデプロイメントには機能しません。代わりに、IBM Techline (注：PartnerWorldの会員様のみアクセス可能です) からの正式なソフトウェア・サイジングのサポートを利用できます。支援を受けるには、IBM 営業担当員に問い合わせてください。

この記事を最大限に活用するには、IBM Techline (注：PartnerWorldの会員様のみアクセス可能です) サイジング・サービスによって提供される方法に従って、推奨された数のサーバー・インスタンスを運用するのに必要な CPU コア、RAM、およびインターネット帯域幅の数量を計算してください。また、以下のシナリオ 1、2、3 (セクション 5、6、7) をデプロイメントの例として使用してください。

用語の定義

CPU - 本書で CPU コアと呼んでいるのは、2 から 3 GHz のクロック・スピードで動作している独立した物理 CPU コア (ハイパー・スレッド化していないもの) のことです。

Sametime Gateway インスタンス - この用語は、スタンドアロンの Sametime Gateway サーバー、または Sametime Gateway クラスターの一部である Sametime Gateway サーバー・インスタンスを示します。

上に戻る

コンポーネント別の CPU とメモリーの要件

クラスター化された Sametime Gateway デプロイメントには、複数のプロセスが含まれています。表 1 は、必要な RAM と CPU の割り当てをプロセスのタイプ別に示したものです。

オペレーティング・システムのメモリー要件に関するメモ

オペレーティング・システムに必要な実際の RAM は、オペレーティング・システムの種類および同一ボックス上に共存しているプロセスの量に応じて異なります。

マシンの RAM サイズに関するメモ

上記に示したプロセスのすべてのメモリーは、利用可能な物理 RAM に収まらなければなりません。オペレーティング・システム、ストレージ・バックエンド、仮想メモリーには頼らないでください。

プロセスのすべてのメモリー要件を満たすだけの物理 RAM がない場合、OS は仮想メモリーをプロセス・メモリー用のコンテナーとして使い始めます。これによって、ページングが発生します。

ページングの概念は C++ アプリケーションに対して機能するものであり、JavaTM 仮想マシン (JVM) については正しく機能しません。JVM ガーベッジ・コレクション中に、JVM はメモリー内のすべてのオブジェクトにアクセスする必要があるため、他のものをオフロードしながら、メモリー・ページを RAM に過度にロードします (ページング)。この動作はすぐにパフォーマンスの低下につながります。

仮想マシン (VM) デプロイメントに対するハイパーバイザー RAM のオーバーコミットに関するメモ

十分な RAM を使用して VM を構成した場合でも、システム管理者に問い合わせ、ハイパーバイザー全体の RAM のオーバーコミットによって VM が影響を受けないことを確認する必要があります。

これを行うには、プロビジョンされた VM の RAM サイズと等しいメモリー予約 (VMware 用語) を使用して VM を構成します。同様に、VMware ツール・エージェントでメモリー・バルーンを無効にする必要があります。ハイパーバイザーには、VMware 以外にも、名称が異なる同様の概念が存在します。

Sametime Gateway クラスター (基本的には WebSphere Application Server クラスター) には、1 つ以上のサーバー・インスタンスを含めることができます。複数の Sametime Gateway インスタンスを同じ物理ボックス上に共存できます。

たとえば、8GB の RAM を持つクワッド・コアのサーバーは、次のサイジング計算に従って、4 個の Sametime Gateway インスタンスをサポートできます。

ゲートウェイのインスタンス = 1.8GB x 4 = 7.2GB
WebSphereのノード・エージェント = 180MB
OS = 512MB
___
総量 = 7.9GB

単一 CPU で実行されている SIP (Session Initiation Protocol) プロキシー・サーバーは、フルにロードされた 8 個の Sametime Gateway インスタンスが生成するトラフィックの量を処理できます。したがって、8n 個の Sametime Gateway インスタンスをサポートするには、n 個の SIP プロキシー・インスタンスが必要です (通常、各 Sametime Gateway インスタンスは約 60 トランザクション/秒で動作しています)。

上に戻る

帯域幅の要件

Sametime Gateway は公衆インターネットを通じて外部のコミュニティーと通信します。これに関して必要なネットワーク帯域幅は、在席確認のサブスクリプションの数に依存します (内部ユーザー 1 が外部ユーザー 2 の在席状況をサブスクライブし、同様にこの逆方向 にもサブスクライブが行われます)。

予測されるシステム内のアクティブなサブスクリプションの数は、平均的なユーザーがメンバー・リストに持っている外部連絡先の総数によって決められます。

この例では、100,000 サブスクリプションという値を使用してください。この値は、10,000 オンライン・ユーザーがいて、ローカル・ユーザーが 5 つの外部連絡先をメンバー・リストに持ち、外部ユーザーが 5 つのローカル連絡先をメンバー・リストに持つものとして計算されます (10K*(5+5))。

以下の測定は、Sametime Gateway 開発チームによって、XMPP (Extensible Messaging and Presence Protocol) ではなく、SIP プロトコルを通じて外部コミュニティーと統合している状態で行われました。

スタートアップ・プロセスによる帯域幅の使用量

内部ユーザーと外部ユーザーの両方がオンラインのときに Sametime Gateway が開始する場合、Gateway はすべてのユーザーについて、保留されている在席確認サブスクリプション要求を送受信します。

配信が必要な保留中のサブスクリプション数が 100,000 と仮定すると、合計 170MB をネットワーク上で送受信する必要があり、スタートアップ・プロセスにかかる時間は利用可能な帯域幅によって異なります。

105KB/s の対称帯域幅が利用できる場合、このプロセスは 27 分後に終了します [170MB / (105KB/s * 60s)]。

スタートアップ後 (定常状態) の帯域幅の使用量

Sametime Gateway が在席確認サブスクリプションの初期一括交換を終了すると、トラフィックは通常オペレーション時のトラフィック量に減少します。このトラフィックには、在席状況の変更、インスタント・メッセージ、および再サブスクライブなどのメッセージの送受信が含まれています。

定常状態では、平均帯域幅として 100,000 サブスクリプションごとに 105KB/s が必要です。これとは異なる数のサブスクリプションをシステムが処理するように求められている場合は、その数に応じてネットワーク要件を調整する必要があります。

たとえば、システムが 200,000 サブスクリプションを処理するよう求められている場合は、通常オペレーションで必要な平均帯域幅は「105KB/s * 2 = 210KB/s」となります。

上に戻る

デプロイメントに関するその他の考慮事項

NAT (ネットワーク・アドレス変換) デバイスを通じて接続する場合は、SIP プロキシー・サーバーを使用してください。ただし、SIP プロキシー・サーバーはスタンドアロンの Sametime Gateway Server では機能しません。Sametime Gateway クラスター (1 つ以上のサーバーとして定義されているクラスター) に接続する必要があります。

共存と高可用性

複数の Sametime Gateway (WebSphere Application Server) インスタンスを同じ物理ボックス上にデプロイするときは、フェイルオーバーについて考慮する必要があります。各 Sametime Gateway インスタンスは、それ自体の SIP セッションをピア Sametime Gateway インスタンスに複製します。しかし、この 2 つのインスタンスを同じ物理ボックス上に配置すると、システム全体の可用性が低下します。

あるプロセスがクラッシュした場合、クラッシュしたプロセスの代わりに別のプロセスが機能しますが、ボックス自体の障害 (オペレーティング・システム、電源、物理的な故障) が発生すると Single Point of Failure (単一障害点) となり、システムの可用性が低下します。このため、ピア・インスタンスを異なるボックスに配置するとよいでしょう。

メモ: Sametime Community サーバーおよび社内の LDAP ディレクトリーは、今回扱っているSametime Gateway デプロイメントの一部としては考えられていません。ほとんどの場合、これらのコンポーネントはすでにデプロイされて稼働しているものとします。

上に戻る

シナリオ #1: 基本的な環境

要件

基本的な環境における要件を表 2 に示します。

考察

このシナリオは最小限の構成であり、その中にはキャパシティー要件をサポートできるスタンドアロンの Sametime Gateway インスタンスが含まれています。

リソースを節約するために、Sametime Gateway インスタンスと、それに対応する DB2 インスタンスが同じ物理ボックス上に共存しています。NAT サポートが必要な場合は、1 つの Sametime Gateway サーバーを含む Sametime Gateway クラスターと SIP プロキシー・インスタンスが同じ 1 つのボックス上に配置することも可能かと思われます。

CPU要件
シングルコア

RAM 要件
ゲートウェイインスタンス = 1.8GB
OS = 512MB
___
合計 = 2.3GB

合計 RAM 使用量に関するメモ: オンライン・ユーザーのピーク数が 7,500 未満と予測される場合は、2GB の RAM のみを持つシステム上でシステムをホストできます。

帯域幅の要件

この例では、100,000 というサブスクリプション値を使用してください。この値は、オンライン・ユーザーが 10,000 で、各ユーザーが 5 つの外部連絡先をメンバー・リストに持ち、外部ユーザーも内部ユーザーをサブスクライブしているものとして計算されます (10K*5*2)。

このため、少なくとも 105KB/s の帯域幅を持つ対称インターネット接続が必要です。

メモ: 上記の帯域幅の要件は、SIP 上での通信にのみ適用されます (XMPP には適用されません)。

まとめ

この Sametime Gateway デプロイメントには、次のものを備えた単一のボックスが必要です。

• シングル CPU コア
• 2.3GB 以上の RAM
• 少なくとも 105KB/s の帯域幅を持つ対称インターネット接続

上に戻る

シナリオ #2: NAT を使用する大規模なデプロイメント (高可用性は未サポート)

要件

NAT を使用する大規模な環境での要件を表 3 に示します。

考察

この構成は大規模なデプロイメント (内部ユーザーが 35000) を表しており、各ローカル・ユーザーがメンバー・リストに保持する外部連絡先の平均数が比較的高い値 (10) になっています (通常は 5 と考えられています)。

この環境は Sametime Gateway の複数のインスタンスで構成されるため、受信するトラフィックを Sametime Gateway インスタンス間でロード・バランシングさせるために、少なくとも 1 つの SIP プロキシーが自動的に必要となります。

高可用性ソリューションの実装を希望する場合は、2 つの SIP プロキシーが必要です。SIP プロキシー・インスタンスは DB2 サーバーおよび WebSphere Application Server デプロイメント・マネージャーと同一場所に置いて、NAT 変換を実行する役割を持ちます。

この環境は高可用性をサポートしないため、ノード障害からのリカバリーにかかる時間は、高可用性をサポートする環境よりも長くなります。

CPU要件
Box1: 3 Sametime Gateway サーバーインスタンス = 3 コア
Box2: 2 Sametime Gateway サーバーインスタンス = 2 コア
Box3: DB2 + SIP Proxy = 1 + 1 = 2 コア

Box1の RAM 要件
Gateway インスタンス = 1.8GB * 3 = 5.4GB
WebSphereのノード・エージェント = 180MB
OS = 512MB
___
合計 = 6.1GB

Box2の RAM 要件
Gateway インスタンス = 1.8GB * 2 = 3.6GB
WebSphereのノード・エージェント = 180MB
OS = 512MB
___
合計 = 4.2GB

Box3の RAM 要件
WebSphere SIP Proxy サーバーインスタンス = 750MB
DB2 = 512MB
WebSphere Deployment manager = 350MB
WebSphereのノード・エージェント = 180MB
OS = 512MB
___
合計 = 2.3GB

帯域幅の要件

SIP プロキシーだけが、インターネット接続を通じて外部の世界と直接通信するコンポーネントです。

この例では、700,000 というサブスクリプション値を使用してください。この値は、オンライン・ユーザーが 35,000 で、各ユーザーが 10 の外部連絡先をメンバー・リストに持ち、外部ユーザーも内部ユーザーをサブスクライブしているものとして計算されます (35K*10*2)。

このため、帯域幅が上り下り共に少なくとも 735KB/s のインターネット接続が必要です (105KB/s * 7 で計算)。

メモ: 上記の帯域幅の要件は SIP 上の通信にのみ適用され、XMPP には適用されません。

まとめ

この Sametime Gateway デプロイメントには、以下の 3 つのボックスが必要です。

• Box1 3 CPU コア

Box2 2 CPU コア
Box3 2 CPU コア
• Box1 RAM 6.1GB 以上
Box2 RAM 4.2GB 以上
Box3 RAM 2.3GB 以上
• 帯域幅が上り下り共に少なくとも 735KB/s のインターネット接続

図 1 は、ボックス 1、2、3 は、上記の要件をサポートするのに必要な量を超えるリソースプロビジョンされています。これは、物理マシンを使用した場合のケースです。仮想化されたインフラストラクチャーを使用している場合は、要件に正確に一致させることがより簡単であり、リソースを節約できます。

上に戻る

シナリオ #3: 高可用性をもつ大規模な環境

要件

高可用性をもつ大規模な環境での要件を表 4 に示します。

考察

この構成は非常に大規模なデプロイメント (内部ユーザーが 75000) を表しており、各ローカル・ユーザーがメンバー・リストに保持する外部連絡先の平均数は通常の値 (5) になっています。14 個の Sametime Gateway インスタンスが必要で、3 または 4 個のインスタンスごとに固有のボックスに配置します。

サイジングのプランニングでは高可用性の要件を考慮に入れ、4 個の物理ボックスのうち 2 個がダウンした場合でも、この環境が通常どおり機能を継続できるようにします (7 から 8 個の Sametime Gateway インスタンスがあれば十分です)。

ボックス障害の場合でも最大の負荷分散を保証するように、セッション複製ピアが構成されます。推奨されるペアは、「1-5、2-9、3-13、4-6、7-10、8-14、11-12」です。

1 つのボックスに障害が発生した場合、その 100% の負荷は、残った 3 つのボックス間で、それぞれ 50%、25%、25% となるように分散されます (以下の「まとめ」セクションの図 2 参照)。複製ドメインの詳細については、Lotus Sametime Gateway InfoCenter のトピック「クラスターのノード複製とフェイルオーバーのセットアップ」を参照してください。

8 個の Sametime Gateway インスタンスごとに 1 つの SIP プロキシー・インスタンスが必要で、さらに高可用性の要件によるバックアップ・インスタンスを加えると、このアーキテクチャーには 4 個の SIP プロキシー・インスタンスが含まれます ((16/8)*2=4)。

ボックス #5 には SIP プロキシー・インスタンス #1 および #2 が含まれ、これらは DB2 サーバー #1 と WebSphere Application Server デプロイメント・マネージャーと同じ場所に置かれています。

ボックス #6 には SIP プロキシー・インスタンス #3 および #4 が含まれ、これらは #2 DB2 サーバーと同じ場所に置かれています。

何らかの種類のハードウェア・ロード・バランサー (適切なバックアップをともなう) デバイスを 4 個の SIP プロキシーの前に配置する必要があります。複数の SIP プロキシーの詳細については、InfoCenter のトピック「複数の SIP または XMPP プロキシー・サーバーを使用するためのガイドライン」を参照してください。SIP プロキシー・インスタンスは、NAT 変換を実行する役割を持っています。

フェイルオーバーを許可するために、DB2 サーバーもクラスター化されています (アクティブ/パッシブ構成で十分です)。

この環境は完全に高可用性をサポートします。

CPU要件
Box1/Box2: 4 Sametime Gateway サーバーインスタンス = 4 コア
Box3/Box4: 3 Sametime Gateway サーバーインスタンス = 3 コア
Box5/Box6: DB2 + SIP Proxy + SIP Proxy = 1 + 1 +1 = 3 コア

Box1/Box2の RAM 要件
Gateway インスタンス = 1.8GB * 4 = 7.2GB
WebSphereのノード・エージェント = 180MB
OS = 512MB
___
合計 = 7.9GB

Box3/Box4の RAM 要件
Gateway インスタンス = 1.8GB * 3 = 5.4GB
WebSphereのノード・エージェント = 180MB
OS = 512MB
___
合計 = 6.1GB

Box5の RAM 要件
WebSphere SIP Proxy サーバーインスタンス = 750MB
WebSphere SIP Proxy サーバーインスタンス = 750MB
DB2 = 512MB
WebSphere Deployment manager = 350MB
WebSphereのノード・エージェント = 180MB
OS = 512MB
___
合計 = 3GB

Box6の RAM 要件
WebSphere SIP Proxy サーバーインスタンス = 750MB
WebSphere SIP Proxy サーバーインスタンス = 750MB
DB2 = 512MB
WebSphereのノード・エージェント = 180MB
OS = 512MB
___
合計 = 2.7GB

帯域幅の要件

SIP プロキシーだけが、インターネット接続を通じて外部の世界と直接通信するコンポーネントです。

この例では、750,000 というサブスクリプション値を使用してください。この値は、オンライン・ユーザーが 75,000 で、各ユーザーが 5 の外部連絡先をメンバー・リストに持ち、外部ユーザーも内部ユーザーをサブスクライブしているものとして計算されます (75K*5*2)。

このため、帯域幅が少なくとも 788KB/s の対称インターネット接続が必要です (105KB/s * 7.5 で計算)。

メモ: 上記の帯域幅の要件は SIP 上の通信にのみ適用され、XMPP には適用されません。

まとめ

この Sametime Gateway デプロイメントには、次のような 6 個のボックスが必要です (図 2 参照)。

• Box1 と Box2
  • 4 CPU コア
  • RAM 7.9GB 以上
• Box3 と Box4
  • 3 CPU コア
  • RAM 6.1GB 以上
• Box5 と Box6
  • 3 CPU コア
  • RAM 3GB 以上
• 上り下り最低788KB/sの帯域幅があるインターネット接続

上に戻る

まとめ

この記事のキー・ポイントを以下にまとめます。

1. サイジングは、デプロイメント計画の初期の段階で実行すべき重要なプロセスです。
2. ゲートウェイ・サイジングの結果は、システム内のサブスクリプションの総数に最も大きな影響を受けます。この数は、メモリー使用量の要件を示します。
3. サブスクリプション数は、オンライン・ローカル・ユーザーの数に、ローカル・ユーザーがメンバー・リストに保持している外部連絡先の平均数を掛けることによって算出されます。メンバー・リスト内のユーザー数の見積もりは、パイロット・プロジェクトの間に決定するとよいでしょう。
4. サイジング要件が同じであっても、複数のトポロジーが可能です。各トポロジーにはさまざまな長所と短所があり、システム・アーキテクトは特定のトポロジーに取り組む前に慎重に考慮する必要があります。
5. 小さいキャパシティーのクラスターから開始し、時間の経過にともなう要件の拡大に応じて、サーバーを追加できます。
6. IBM Techline (注：PartnerWorldの会員様のみアクセス可能です) からの正式なソフトウェア・サイジング・サポートを利用できます。支援を受けるには、IBM 営業担当員に問い合わせてください。

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• コンポーネント別の CPU とメモリーの要件
• 帯域幅の要件
• デプロイメントに関するその他の考慮事項
• シナリオ #1: 基本的な環境
• シナリオ #2: NAT を使用する大規模なデプロイメント (高可用性は未サポート)
• シナリオ #3: 高可用性をもつ大規模な環境
• まとめ
• 著者について
• コメント