プッシュ通知の概要
クラスタでプッシュ通知が有効になっている場合、Cisco Unified Communications Manager と IM and Presence Service は、Apple クラウドまたは Google クラウドのプッシュ通知サービスのいずれかを使用して、iOS または Android デバイス上で実行されている互換性のある Cisco Jabber または Webex クライアントにプッシュ通知を送信します。プッシュ構成を使用すると、システムがバックグラウンドモード（サスペンドモードとも呼ばれる）に入った後でも、クライアントと通信できます。プッシュ構成がない場合、バックグラウンドモードに入ったクライアントにコールやメッセージを送信できない場合があります。
プッシュ通知の暗号化されたペイロードには、次の PII 情報が含まれます。
-
表示名
-
ディスプレイ番号
-
ハントパイロット DN
次の表に、Apple プッシュ通知サービス（APNS）とローカルプッシュ通知サービス（LPNS）のサポートマトリックスの詳細を示します。
|
Unified CM |
IM and Presence Service |
Cisco Expressway（MRA が展開されている場合） |
Cisco Jabber |
Webex アプリ |
モバイル オペレーティング システム |
注 |
|
|---|---|---|---|---|---|---|---|
|
Apple：APNS メッセージング |
11.5(1)SU2 |
11.5(1)SU2 |
X8.9.1 |
11.8.1 |
該当なし |
12 |
Apple および Cisco クラウドとの接続が必要です。 |
|
Apple：APNS コール |
11.5(1)SU3 |
11.5(1)SU3 |
X 8.10.1 |
11.9.0 |
40.6 |
12 |
— |
|
Apple：APNS CallKit |
11.5(1)SU8 および 12.5(1)SU3 および 14 |
該当なし |
X 12.6 |
12.9 |
40.6 |
13 |
— |
|
Apple：APNS 中国リージョン |
12.5(1)SU3 および 14 |
12.5(1) SU3 |
X 12.6 |
12.9 MR |
41.4 |
13 |
— |
|
Android：FCM |
12.5(1)SU3 および 14 |
12.5(1) SU3 |
X12.6.2 |
12.9.1 |
40.8 |
8.0 |
Google および Cisco クラウドとの接続が必要です。 |
|
Apple：LPNS |
14SU3 |
該当なし |
非対応 |
14.2 |
43.6 |
16.5 |
WiFi 展開でサポート |
Unified Communications Manager および IM and Presence Service の導入では、プッシュ通知が次のクライアントで使用されます。
|
通信タイプ |
プッシュ通知を使用するクライアント |
オペレーティング システム |
パートナークラウドサービス |
ローカルプッシュ接続 |
|---|---|---|---|---|
|
通話 |
iPhone または iPad 版 Cisco Jabber iPhone または iPad 版 Cisco Webex |
iOS |
Apple プッシュ通知サービス（Apple クラウド内） |
Unified CM バージョン 14SU3 および Webex アプリ 43.6 以降または Cisco Jabber 14.2 以降でサポートされています。 |
|
コール |
Android 版 Cisco Jabber Android 版 Cisco Webex |
Android |
Android プッシュ通知サービス（Google クラウド内） |
非対応 |
|
メッセージ * |
iPhone または iPad 版 Cisco Jabber |
iOS |
Apple プッシュ通知サービス（Apple クラウド内） |
非対応 |
|
メッセージ * |
Android の Cisco Jabber |
Android |
Android プッシュ通知サービス（Google クラウド内） |
非対応 |
* メッセージングの場合、Webex アプリクライアントは IM and Presence Service ではなく、Webex アプリクラウドに登録します。
 （注） |
iOS と Android の両方における特定のプッシュ通知機能の最小リリース情報については、「プッシュ通知の最小リリースと機能サポート」 を参照してください。 |
プッシュ通知の動作
スタートアップ時に、Android および iOS プラットフォームデバイスにインストールされている Cisco Jabber クライアントは Unified Communications Manager と IM and Presence Service に登録します。また、Android または iOS で実行される Webex アプリクライアントは、コール用に Unified Communications Manager に登録し、メッセージング用に Webex アプリクラウドに登録します。また、Jabber クライアントおよび Webex クライアントは、実行しているプラットフォームに応じて、Google クラウドまたは Apple クラウドにも登録します。クライアントがフォアグラウンドモードのままである限り、コールまたはメッセージをクライアントに直接送信できます。
ただし、クライアントがバックグラウンドモードに切り替わると（バッテリ寿命を維持するために発生することがあります）、標準の通信チャネルが利用できないため、クライアントとの直接通信ができません。プッシュ通知は、パートナーのクラウド（Apple または Google）を介してクライアントに到達するための代替チャネルを提供します。
（注） |
次の条件のいずれかに当てはまる場合、Cisco Jabber クライアントおよび Webex アプリクライアントはサスペンドモードで実行されていると見なされます。
|
上の図は、Android および iOS 版 Cisco Jabber クライアントがバックグラウンドで実行されているか、または停止したときの動作を示しています。標準チャネルが利用できないため、プッシュ通知が Cisco cloud の Push REST サービスに送信され、シスコクラウドはこの通知を適切なパートナークラウド（Apple または Google）に転送し、さらにパートナークラウドがプッシュ通知をクライアントに転送します。クライアントは、コールまたはメッセージを受け入れるためにオンプレミス導入に再登録します。
この図では、(1) Jabber クライアントが、オンプレミスの Unified Communications Manager と、IM and Presence Service 導入に Expressway 経由で接続する MRA 導入。(2) エンタープライズ ネットワーク内からオンプレミス導入に直接接続する Android または iOS 版 Cisco Jabber クライアントを示しています。
（注） |
Windows および iOS デバイスに同時にログインしている Jabber ユーザーの場合は、プッシュ通知は次のように動作します。
|
プッシュ通知の動作
次の表に、Unified Communications Manager と IM and Presence Service がオンプレミスで導入されている場合のプッシュ通知のクライアント動作を示します。
（注） |
Webex アプリクライアントは、メッセージングにオンプレミスの IM and Presence Service ではなく、Webex アプリクラウドを使用します。 |
（注） |
Apple IOS CallKit の上限により、iOS の Webex App および Cisco Jabber はビデオ通話として常に表示されます。 |
|
Cisco Jabber または Webex クライアントの状態... |
iOS12 を実行中 |
iOS13 以降のバージョンまたは Android が実行中 |
||||
|---|---|---|---|---|---|---|
|
フォアグラウンドモード |
音声/ビデオ通話 Unified CM は、SIP チャネルを使用して Cisco Jabber または Webex クライアントに通話を直接送信します。 また、Unified CM はフォアグラウンドモードのクライアントにプッシュ通知を送信します。ただし、プッシュ通知はコールの確立に使用されません（代わりに標準の SIP チャネルが使用されます）。 メッセージ（Jabber のみ） IM and Presence Service は、標準の通信チャネルを使用して Cisco Jabber にメッセージを直接送信します。IM and Presence Service は、フォアグラウンドモードのクライアントにプッシュ通知を送信しません。 |
音声/ビデオ通話 Unified CM は、SIP チャネルを使用して Cisco Jabber または Webex クライアントに通話を直接送信します。 また、Unified CM はフォアグラウンドモードのクライアントにプッシュ通知を送信します。ただし、プッシュ通知はコールの確立に使用されません（代わりに標準の SIP チャネルが使用されます）。 メッセージ（Jabber のみ） IM and Presence Service は、標準の通信チャネルを使用して Cisco Jabber にメッセージを直接送信します。IM and Presence Service は、フォアグラウンドモードのクライアントにプッシュ通知を送信しません。 |
||||
|
バックグラウンドモード |
音声/ビデオ通話 SIP チャネルは使用できません。Unified CM はプッシュ通知チャネルを使用します。プッシュ通知を受信すると、クライアントは Unified CM に再登録し、SIP チャネルを介して SIP INVITE を受信します。 メッセージ（Jabber のみ） 標準チャネルは使用できません。IM and Presence Service は、プッシュ通知チャネルを使用して Jabber に IM 通知を送信します。ユーザーが通知をクリックすると、クライアントはフォアグラウンドモードに移行し、IM and Presence Service とのセッションを再開してメッセージをダウンロードします。
|
音声/ビデオ通話 SIP チャネルはコールに使用できません。Unified CM は「VoIP」プッシュ通知チャネルを使用します。プッシュ通知を受信すると、クライアントは発信者 ID を使用して CallKit を起動し、Unified CM に再登録し、SIP チャネルを介して SIP INVITE を受信します。その後、ユーザーはコールに応答できます。 メッセージ（Jabber のみ） 標準チャネルは使用できません。IM and Presence Service は、「メッセージ」プッシュ通知チャネルを使用して Jabber に IM 通知を送信します。ユーザーが通知をクリックすると、クライアントはフォアグラウンドモードに移行し、IM and Presence Service とのセッションを再開してメッセージをダウンロードします。
|
Apple プッシュ通知
iOS で実行されている Cisco Jabber および Cisco Webex クライアント（たとえば、iPhone および iPad の Cisco Jabber）は、Apple クラウドで実行される Apple プッシュ通知サービスからプッシュ通知を受信します。
Cisco Jabber 12.9 リリース以降では、すべての新しい iOS アプリケーションおよび更新は、 iOS 13 以降のバージョンを使用して構築されます。iOS 13 では、Apple は中断されたアプリケーションに対するプッシュ通知を iOS 12 と異なる方法で処理します。
-
iOS 13 のプッシュ通知は、通話用の「VoIP」チャネルとメッセージング用の別の「メッセージ」チャネルを使用して配信されます。これは、すべてのプッシュ通知トラフィックが同じチャネルを使用して配信される iOS 12 とは異なっています。
-
プッシュ通知は、2020 年 8 月現在、Apple iOS クライアントに必須です。
-
iOS クライアントは、通知を受信すると、CallKit をすぐに起動して着信コールを示します。
-
プッシュ通知の「VoIP」トラフィックには、クライアントが CallKit の CallerID フィールドに入力するために使用する発信者 ID 情報（表示名、番号）が含まれます。ユーザーは、Cisco Jabber または Cisco Webex をフォアグラウンドに移行させて、新しいセッションに対してプッシュ通知が有効になっている新しいセッションを開始する必要があります。そうでない場合、発信側の元の名前と番号が着信側のデバイスに表示されます。
-
不在着信通知：発信者が進行中の発信通話を切断した場合、2 回目のプッシュ通知が、プッシュ対応デバイスに送信されます。プッシュ通知は、プッシュ対応デバイスが 13 秒以内に着信通話を登録しない場合にも送信されます。
-
共有回線：別のデバイスとの共有回線を持つプッシュ通知対応デバイスが通話を受信し、共有回線が通話に応答した場合、プッシュ通知対応デバイスは、通話は別のデバイスが応答したと記載された 2 番目のプッシュ通知を受信します。
-
「VoIP」タイプのプッシュ通知は優先順位が高いと見なされ、遅延なく配信されます。
（注） |
どのプッシュ通知機能がどの Unified CM リリースで対応されているかについては、「プッシュ通知の最小リリースと機能サポート」を参照してください。 |
以下の画像は、VoIP プッシュ通知が iOS13 以降のバージョンで送信された際の状況の概要を示しています。
iOS13 以降のバージョンおよび APNS 変更と Cisco Jabber または Webex アプリのプッシュ通知 Calling エクスペリエンスの比較
次の表では、クライアントがアップグレードされ、サーバーがアップグレードされていない場合、またはクライアントはアップグレードされていないが、サーバーがアップグレードされた場合のユーザー体験動作が示されています。
|
画面がロックされている場合 |
画面がロック解除済みの場合 |
|
|---|---|---|
|
Cisco Jabber 12.9 |
|
|
|
Cisco Jabber 12.8 以前 |
|
|
（注） |
メッセージプッシュ通知のユーザエクスペリエンスの動作に変化はありません。 |
プッシュ通知のクラウドセキュリティ
セキュリティは、Cisco Jabber および Cisco Webex アーキテクチャのプッシュに対する取り組みの中心にあります。すべてのプッシュ通知コンテンツは、ユーザーがサインインするときに Cisco Jabber と Cisco Webex によって定義される 256 ビットの Advanced Encryption Standard（AES）キーを使用して暗号化されます。このキーは、クライアントが定期的に更新することもできます。プッシュ通知の一部として送信されるコンテンツはすべて暗号化されます。
シスコのクラウドプッシュサービスでは、暗号化されたペイロードが必要で、Apple または Google クラウドに送信する前に暗号化されていないコンテンツが拒否されます。シスコのクラウドプッシュサービスとの通信はすべて、Transport Layer Security（TLS）を使用して保護されます。これにより、APNS を介してプッシュされるコンテンツが暗号化されます。
PushRest サービスは、オンプレミスのサーバーから取得したペイロードをキャッシュしません。PushRest サービスはプロキシであり、情報を Apple または Google クラウドに渡します。
すべての個人識別情報（PII）が暗号化されます。暗号化されたペイロード内にはないが、セキュアな TLS 接続を使用して送信されるサービス外の詳細情報は次の情報だけです。
-
プッシュターゲット。クライアント（場合によっては APNS または FCM）が生成した、特定のプッシュセッションデバイス用のトークンで、時々ローテーションされるか、それ以降のサインインで変更されます。
-
トラッキング ID（問題が発生した場合、デバッグでメッセージが使用されるごとにクライアントによって生成される ID）
iOS13 プッシュ通知（中国地域）
Unified Communications Manager は、iOS13 バージョン以降のデバイス上で実行されている Cisco Jabber または Webex クライアントの VoIP コールプッシュ通知をサポートします。また、IM and Presence Service は、iOS13 以降のバージョンのデバイス上で実行される Cisco Jabber クライアントに対するメッセージプッシュ通知をサポートします。中国の大陸地域にあるプッシュ通知対応デバイスへの着信コールを受信すると、iOS デバイスで実行されているクライアントは、規制の要件によって CallKit ビューを表示できません。代わりに、名前や番号などの発信者 ID の詳細を含むメッセージ通知が表示されます。
中国大陸地域の iOS13 以降のバージョンの Cisco Jabber および Cisco Webex クライアント：
-
VoIP コールプッシュ通知メッセージを受信した場合、CallKit ビューを表示できません。
-
VoIP コールプッシュ通知メッセージによって、アプリケーションは着信コールと発信者 ID に関する情報を含むメッセージトーストを表示します。
これにより、エンドユーザーはコールに応答する前に、発信者のアイデンティティを確認できます。メッセージ通知をタップすると、アプリケーションが起動して Unified Communications Manager に登録します。登録が成功すると、Unified Communications Manager は着信コールをアプリケーションにルーティングします。
（注） |
Unified Communications Manager がユーザーにコールをルーティングするには、Cisco Jabber および Cisco Webex クライアントでメッセージ通知をすぐにタップすることをお勧めします。設定した時間（13 秒）以内にユーザーがメッセージ通知をタップしない場合、着信コールは CallKit を介して受信者にアラートを通知せず、不在着信メッセージ通知がユーザーに送信されます。 中国地域のプッシュ通知は iOS デバイス専用で、最小リリースは 12.5(1)SU3 です。Android デバイスではサポートされていません。 Cisco Jabber 12.9 MR が必要です。IM and Presence Service プッシュ通知は、この規制の影響を受けません。 |
Android プッシュ通知
12.5(1)SU3 では、Unified Communications Manager は Android デバイス上で実行されている Cisco Jabber または Webex クライアントに対する VoIP プッシュ通知をサポートしています。また、IM and Presence Service は、Android クライアント上の Cisco Jabber に対するメッセージングプッシュ通知をサポートします。
着信コールがある場合、Unified Communications Manager プッシュ通知サービス（CPNS）は、Google クラウド経由で、サスペンドモードまたはバックグラウンドモードで実行されている Android クライアントにプッシュ通知を送信します。通知を受信すると、Cisco Jabber または Webex クライアントがコールを受信するために Unified Communications Manager に再登録します。
（注） |
|
（注） |
Cisco Jabber for Android クライアントは、2024 年 8 月 31 日までに Android ターゲット API レベル 34（Android 14）に更新する必要があります。詳細については、https://developer.android.com/google/play/requirements/target-sdkを参照してください。 この新しいバージョンの Cisco Jabber では、Android の VoIP ソケットはサポートされません。FCM を介したプッシュ通知は、バックグラウンドモードまたはサスペンドモードでアプリケーションに通知するためにサポートされている唯一の方法です。詳細については、https://developer.android.com/about/versions/14/changes/fgs-types-requiredを参照してください。 Unified Communications Manager、IM and Presence Service、および Expressway を、サポートされている次のバージョンにただちに更新することを強く推奨します。
|
（注） |
Google クラウドからの Android プッシュ通知サービスを使用してサインインする Cisco Jabber および Cisco Webex クライアントの一部として、サブスクライバサービス FCM（Firebase Cloud Messaging）と FCM:dev がサポートされています。 |
Unified Communications Manager のフェールオーバーが発生した場合のプッシュ通知
Unified Communications Manager グループは、デバイスが登録できる最大 3 台の冗長構成のサーバーの優先順位付きリストです。各グループには、1 個のプライマリ ノードと最大 2 個のバックアップ ノードが含まれます。ノードをリストする順序によって、最初のノードがプライマリノード、2 番目のノードがバックアップノード、3 番目のノードが第 3 のノードになります。
Unified Communication Manager では、デバイスプールは、デバイスグループに設定の共通のセットを提供し、特定のロケーション情報に従ってデバイスを設定できます。デバイスプール設定を使用して、Cisco Unified Communications Manager グループにデバイスを割り当てることができます。
Cisco Jabber または Cisco Webex クライアントがバックグラウンドまたは中断状態に移行し、クライアントが登録されているプライマリノードがネットワークから外れた場合、またはクラッシュした場合、Cisco Jabber または Cisco Webex に対するコールにより Unified CM からのプッシュ通知がトリガーされます。
以前、Cisco Jabber または Cisco Webex が登録していたノードに登録を試みましたが、登録は失敗しました。現在は、それに続いてデバイスプール内のアクティブノードへの接続を試みて、正常に登録されます。Cisco Jabber または Cisco Webex クライアントが登録する必要がある現在のアクティブノードを検出するこのプロセスにより時間のロスが発生します。
Unified Communications Manager プッシュ通知サービス（CPNS）は、プッシュ通知が送信されるたびに、Cisco Jabber または Cisco Webex が正しいアクティブノードに登録されるようにして損失や遅延を回避することを目的としています。このプッシュ通知要求は現在のアクティブノード情報を含んでいるため、クライアントは同じノードに登録し直すか、または現在のアクティブノードにすばやく登録できます。
（注） |
アクティブノードは、12.5(1)SU3 リリース以降のプッシュ通知にのみ含まれます。 |
次の図は、クライアントがバックグラウンドモードまたは中断状態中に、プライマリノードがサービス停止状態になる、Unified Communications Manager のフェールオーバーの例です。クライアントの着信コールを受信すると、Unified Communications Manager は、プライマリ登録ノードがダウンしているため、バックアップノードをアクティブノードとして指定したプッシュ通知を送信します。プッシュ通知を受信すると、クライアントはバックアップノードに登録します。
クラウド接続のプロキシサポート
一部の導入では、プロキシサーバーを使用して Cisco Cloud に接続する必要がある場合があります。これは、オンプレミスの展開が企業のファイアウォールの背後にあり、クラウドへの直接アクセスを許可しない場合に特に当てはまります。
Unified Communications Manager は、Cisco Web セキュリティアプライアンスを HTTPS プロキシサーバとしてサポートしています。ただし、以下のいずれかのコールフローをサポートする HTTP または HTTPS プロキシサーバーを使用することができます。認証を有効にして HTTP プロキシを使用する場合は、ログイン情報のセキュリティのためにプロキシサーバーのダイジェスト認証を設定することを推奨します。
HTTPS プロキシのサポートされているコールフロー
HTTPS プロキシのサポートされているコールフロー
プロキシサーバーのキャパシティの要件
プッシュ通知用の Proxy Server Capacity Calculator を使用して、プロキシサーバーが処理できるキャパシティを推定します。導入に適用される情報を入力すると、この計算ツールは HTTP プロキシサーバーがプッシュ通知の展開で処理できる必要があるトランザクション数を出力します。
プロキシサーバーの DNS 要件
-
Unified Communications Manager でプロキシサーバ接続を設定する場合、プロキシサーバーの FQDN アドレスを使用すると、DNS がプロキシサーバへの接続に使用されます。プロキシサーバーの FQDN が複数の IP アドレスに解決される場合、Unified Communications Manager は最初の IP アドレスを試行して 2 秒待機してから、2 番目のアドレスに進みます。
-
プッシュ通知を送信した後、Unified Communications Manager は確認を 5 秒待機してから、2 番目のアドレスを試行します。
-
Cisco cloud 接続用のプロキシサーバーでは、接続の失敗に対するフェールオーバープロセスを高速化するために、プロキシサーバーを低いフェールオーバーレートで設定することを推奨しています。
-
Cisco Web Security アプライアンスを導入している場合、FQDN は WSA の仮想 IP アドレスにマップする必要があります。
（注） |
プロキシ IP アドレスのデフォルトの有効期限 (TTL) は、1 時間になります。そのため、IP アドレスが変更された場合、その変更が DNS 要求に対して利用可能になるまでに最大 1 時間かかることがあります。 |
IM and Presence に対するプッシュ通知の高可用性
プッシュ通知の高可用性によって、Android および iOS 版 Cisco Jabber クライアントのプッシュ通知を有効にした IM and Presence セッションのフェールオーバーと冗長性が実現します。この機能を使用すると、IM and Presence Service は IM セッションをローカルのインメモリデータベース (IMDB) に保存します。これは、サブクラスタバックアップノード上のインメモリデータベースに自動的に複製されます。これにより、バックアップノードはセッション情報を確実に取得し、ユーザからのユーザアクションなしにセッションを引き継ぐことができます。
IM 履歴
プッシュ通知の高可用性が設定されている場合、Cisco Jabber ユーザーはフェールオーバーが発生したときにチャット履歴を失うことはありません。
Jabber が一時停止モードの場合の未読メッセージキュー
プッシュ通知対応の IM セッションの場合、Android または iOS 版 Cisco Jabber クライアントがサスペンドモードに移行すると、IM and Presence Service はクライアントにプッシュ通知を送信しますが、未開封のインスタントメッセージ、プレゼンスアップデート、およびその他の XMPP スタンザ（チャットルーム招待など）の送信を停止します。代わりに、クライアントがプッシュ通知をクリックするか、または再びフォアグラウンドモードになるまで、これらのメッセージはローカルサーバ上でキューに入れられます。
Cisco Jabber が一時停止モードの場合、プッシュ通知が有効になっている IM セッションの未読メッセージキューに関連する制限があります。一部のフェールオーバーの使用例では、未開封メッセージキューが失われます。この状況が発生した場合の説明については、「冗長性とフェールオーバーの使用例」を参照してください。
冗長性とフェールオーバーの使用例
この機能には、次の使用例が含まれています。
-
ノードの障害（自動フェールオーバー）：ノードに障害が突然発生した場合、バックアップノードは IM セッションを引き継ぎ、この場合のプッシュ通知はバックアップノードから Cisco Jabber ユーザーに送信されます。ユーザーは、操作したり、IM 履歴を失ったりすることなく、作業を継続できます。ただし、クライアントが中断モードの間に障害が発生したサーバーでキューに入れられた、クライアントにまだ送信されていない未開封メッセージは失われます。
-
ノードのシャットダウン (手動フェールオーバー)：ノードが正常にシャットダウンされると、バックアップノードは IM セッションを引き継ぎ、プッシュ通知はバックアップノードから送信され続けます。ユーザーは、操作したり、IM 履歴を失ったりすることなく、作業を継続できます。元のノードでキューに入れられ、Jabber クライアントへの送信を待機していた未読メッセージは、バックアップノードが引き継ぐと一時的に失われます。ただし、元のノードが復帰し、ユーザーが元のノードにフォールバックした後、そのメッセージキューが取得され、ユーザーに送信されます。
-
Cisco XCP ルータのクラッシュ：Cisco XCP ルータが突然クラッシュした場合、ルータが復帰すると、ノードはセッションを再開し、プッシュ通知の送信を続行します。IM 履歴は維持されるため、Cisco Jabber ユーザーはユーザーアクションなしに作業を継続できます。ただし、ルータのクラッシュ前にサーバーのキューに格納された未読メッセージがクライアントにまだ送信されていないときは失われます
-
Cisco XCP ルータの再起動：管理者が Cisco XCP ルータを再起動した場合 (設定の更新後など)、IM 履歴と未開封メッセージキューの両方が維持されます。ルータが再起動すると、IM and Presence Service はプッシュ通知の送信を再開します。Jabber クライアントが再度ログインすると、未開封メッセージキューが送信されます。
（注） |
音声コールおよびビデオ コールの場合、冗長性とフェールオーバーは Cisco Unified Communications Manager グループによって処理されます。 |
Push v3 対応デバイスの HA イベント中にサポートされる再ログインレート
このセクションでは、導入の必要性に応じて PUSH v3 対応デバイスの HA イベント中のクライアントの再ログインレートを計算する方法について説明します。
この手順では、15,000 の OVA があり、次の順序で配布されることを前提としています。
-
IM and Presence パブリッシャノードに登録された 2,000 人のユーザーは Push v3 対応です。
-
IM and Presence パブリッシャノードに直接登録された 5,500 人のユーザーは、プッシュ対応ではありません。
-
IM and Presence サブスクライバノードに登録された 7,500 人のユーザーは、プッシュ対応ではありません。
高可用性イベントの場合、サポートされるフェールオーバーレートは 4 ユーザ/秒以下である必要があります。このレートは、次の測定値を使用して実現できます。
クライアントの再ログイン下限を 200 に設定し、クライアントの再ログイン上限を 2075 に設定した場合、再ログインレートは次の方法で計算されます。
7500/(2075-200)= 4 ユーザ/秒
（注） |
|
フィードバック