ローカルホストキャッシュ
ヒント:
Studioの [ホーム] ノードでは、サービス正常性アラート機能により、ローカルホストキャッシュとゾーンが正しく構成されていることを確認するための予防的なアラートが表示されます。これにより、停止が発生した場合でも、ローカルホストキャッシュが機能するためユーザーは影響を受けません。アラートには2つのレベルがあります。ホーム(フラグアイコン)に表示されるサイト全体のアラートと、各ゾーンの[トラブルシューティング]タブに表示されるゾーン関連のアラートです。詳しくは、「ゾーン」を参照してください。
ローカルホストキャッシュ(LHC)を使用すると、Cloud ConnectorがCitrix Cloudと通信できなくなった場合でも、Citrix DaaS(旧称Citrix Virtual Apps and Desktopsサービス)環境での接続仲介操作を続行できるようになります。ローカルホストキャッシュは、ネットワーク接続の切断時間が60秒に達すると作動します。
ローカルホストキャッシュがあれば、接続済みのユーザーは、停止状態が発生した場合も途切れることなく作業を続行できます。再接続時および新規接続時の接続遅延は最小限に抑えられます。
重要:
オンプレミスのStoreFront環境を使用している場合は、VDAが登録されている(または登録できる)すべてのCloud Connectorを、Delivery ControllerとしてStoreFrontに追加する必要があります。StoreFrontに追加されていないCloud Connectorは停止モードに移行できないため、ユーザーの起動に失敗することがあります。
オンプレミスのStoreFrontを使用しない展開の場合は、Citrix Workspaceプラットフォームのサービス継続性機能を使用して、ユーザーが停止中にリソースに接続できるようにします。詳しくは、「サービス継続性」を参照してください。
データコンテンツ
ローカルホストキャッシュには、メインデータベースの情報の一部として次の情報が格納されます:
- サイトから公開されたリソースに対する権限が割り当てられているユーザーおよびグループのID。
- サイトの公開リソースを現在使用しているか、最近使用したユーザーのID。
- サイトで構成されているVDAマシン(リモートPCアクセスマシンを含む)のID。
- 公開リソースへの接続で頻繁に使用されているCitrix WorkspaceアプリクライアントマシンのID(名前とIPアドレス)
また、メインデータベースが利用できなくなったときに確立され、現在アクティブな接続に関する情報も格納されています:
- Citrix Workspaceアプリで実行されたクライアントマシンエンドポイント分析の結果
- サイトに関連するインフラストラクチャマシン(Citrix GatewayやStoreFrontサーバーなど)のID
- ユーザーによる最近のアクティビティの日時とタイプ
機能
ローカルホストキャッシュがCitrix Cloudとどのように相互作用するかを表示します。
通常の操作中
- Cloud Connector上のプリンシパルブローカー(Citrix Remote Broker Provider Service)は、StoreFrontからの接続要求を受け取ります。プリンシパルブローカーは、Citrix Cloudと通信して、Cloud Connectorに登録済みのVDAにユーザーを接続します。
- Citrix Config Synchronizer Service(CSS)は、Citrix Cloudのブローカーを5分おきにチェックして、構成に変更がないか確認します。こうした変更には、管理者によるもの(デリバリーグループのプロパティの変更など)とシステム操作(マシン割り当てなど)があります。
-
前回のチェック以降に構成が変更された場合、CSSは、Cloud Connectorのセカンダリブローカーに情報を同期(コピー)します(セカンダリブローカーは、上記の図で示されているようにHigh Availability ServiceまたはHAブローカーとも呼ばれます)。
前回のチェック以降に変更された項目だけでなく、すべての構成データがコピーされます。CSSは、Cloud Connector上のMicrosoft SQL Server Express LocalDBデータベースに構成データをインポートします。このデータベースはローカルホストキャッシュデータベースとして参照されます。CSSは、ローカルホストキャッシュデータベースの情報がCitrix Cloudのサイトデータベースの情報と一致することを確認します。ローカルホストキャッシュデータベースは、同期が発生するたびに再作成されます。
Cloud Connectorをインストールする場合、(ローカルホストキャッシュデータベースで使用するために)自動でMicrosoft SQL Server Express LocalDBがインストールされますローカルホストキャッシュデータベースをCloud Connector間で共有することはできません。ローカルホストキャッシュデータベースのバックアップを作成する必要はありません。構成の変更が検出されるたびに再作成されます。
- 前回のチェック以降に変更が発生行われていない場合、構成データはコピーされません。
停止状態中
停止が開始された場合:
- セカンダリブローカーは、接続要求のリッスンと処理を開始します。
- 停止状態の開始時には、セカンダリブローカーに最新のVDA登録データはありませんが、VDAとの通信が始まると登録処理がトリガーされます。その処理中、セカンダリブローカーは、そのVDAに関する現在のセッション情報も取得します。
- セカンダリブローカーが接続を処理する間も、プリンシパルブローカーは引き続きCitrix Cloudへの接続を監視します。接続が回復すると、プリンシパルブローカーはセカンダリブローカーに接続情報のリスニングを停止するように指示して、仲介操作を再開します。VDAがプリンシパルブローカーと次に通信するときに、登録処理がトリガーされます。セカンダリブローカーは、前回の停止状態以降に残っているVDA登録をすべて削除します。CSSは、Citrix Cloudで構成が変更されたことを検出すると、情報の同期を再開します。
同期中に停止状態が開始されるという可能性の低い事象では、その時点のインポートは破棄され、最新の既知の構成が使用されます。
イベントログに、同期および停止状態が発生した時刻が記録されます。
停止モードでの操作に時間制限は適用されませんが、
意図的に停止を引き起こすこともできます。これを行う理由と方法について詳しくは、「停止状態の強制」を参照してください。
リソースの場所にCloud Connectorが複数存在する場合
CSSは、他のタスクの合間に、リソースの場所内にあるすべてのCloud Connectorに関する情報を定期的にセカンダリブローカーに提供しますリソースの場所で他のCloud Connectorを実行している各セカンダリブローカーは、この情報からすべてのピアセカンダリブローカーを把握します。
セカンダリブローカーは独立したチャネルで相互に通信します。これらのセカンダリブローカーは、実行しているマシンのFQDN名のアルファベット順の一覧を使用して、停止状態が発生したときにどのセカンダリブローカーがゾーン内の仲介操作を担当するかを決定(選出)します。停止状態中、すべてのVDAが、選出されたセカンダリブローカーに再登録します。選出されていないゾーン内のセカンダリブローカーは、受信接続とVDA登録要求を能動的に拒否します。
重要:
リソースの場所内のConnectorは、
http://<FQDN_OF_PEER_CONNECTOR>:80/Citrix/CdsController/ISecondaryBrokerElection
で相互に接続できる必要があります。Connectorがこのアドレスで通信できない場合、複数のブローカーが選出され、ローカルホストキャッシュイベント中に断続的な起動エラーが発生する可能性があります。
停止状態中に、選出されたセカンダリブローカーに障害が発生した場合、別のセカンダリブローカーが選出されて処理を引き継ぎ、VDAは新しく選出されたセカンダリブローカーに登録されます。
停止状態中にCloud Connectorを再起動した場合:
- このCloud Connectorがブローカーに選出されていない場合は、再起動しても影響はありません。
- このCloud Connectorをブローカーに選出している場合は、別Cloud Connectorが選出されてVDAはそちらに登録されます。再起動したCloud Connectorの電源がオンになると、このCloud Connectorが自動的に仲介処理を引き継ぐため、VDAはこちらのConnectorにもう一度登録されます。このシナリオでは、登録中にパフォーマンスに影響が生じることがあります。
イベントログには、選出に関する情報が含まれます。
停止状態中にできなくなること、およびその他の相違点
停止モードでの操作に時間制限は適用されませんが、リソースの場所からCitrix Cloudの接続が失われた場合は、可能な限り迅速にリソースの場所の接続を復元することをお勧めします。
停止状態中:
- ローカルホストキャッシュイベント中、Studioに一時的にアクセスできない場合があります。Studioにアクセスできる場合、HAモードで動作しているリソースの場所にあるVDAはStudioで未登録として表示されます。これらのVDAには、ローカルホストキャッシュで引き続きアクセスできます。
-
Remote PowerShell SDKへのアクセスが制限されます。
- 次のことを最初に行う必要があります:
- レジストリキー
EnableCssTestMode
を値1で追加します:New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
- SDKプロキシがコマンドレット呼び出しをリダイレクトしようとしないようにするため、SDK認証を
OnPrem
に設定します:$XDSDKAuth="OnPrem"
- ポート89を使用します:
Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ContollerDNSName, DesktopGroupName, RegistrationState
- レジストリキー
- これらのコマンドを実行すると、次のものを使用できるようになります:
- すべての
Get-Broker*
コマンドレット。
- すべての
- 次のことを最初に行う必要があります:
- 停止状態中は、監視データがCitrix Cloudに送信されなくなります。このため、[監視]機能には、停止状態中のアクティビティは表示されません。
- ハイパーバイザー資格情報をホストサービスから取得できません。すべてのマシンの電力状態が不明で、電源操作を発行できません。ただし、電源が入っているホスト上のVMを接続要求のために使用することができます。
- 割り当てられたマシンは、通常の操作中に割り当てが発生した場合のみ使用できます。停止状態中は新しい割り当てはできません。
- リモートPCアクセスマシンの自動登録と構成はできません。ただし、通常の操作中に登録、構成されたマシンは使用できます。
- サーバーでホストされるアプリケーションとデスクトップのユーザーは、リソースが異なるゾーンにある場合、構成されている最大セッション数よりも多くのセッションを使用できる場合があります。
- 各ゾーンは、LHCイベント中に個別に動作します。停止状態中は、ゾーン間での起動(あるゾーンのブローカーから別のゾーンのVDAへ)はサポートされません。StoreFrontの詳細なヘルス チェック機能を使用して、LHCイベント中に起動要求を適切なゾーンにルーティングします。
- デリバリーグループ内のVDAに対してスケジュールされた再起動が開始される前にサイトデータベースの停止が発生した場合、停止が終了すると再起動が開始されます。このシナリオは意図しない結果につながる可能性があります。詳しくは、「データベースの停止によるスケジュールされた再起動の遅延」を参照してください。
- [ゾーン優先度]を構成できません。構成されていても、環境設定はセッション起動では考慮されません。
- タグを使用してリソースの場所を指定するタグ制限機能は、セッション起動ではサポートされていません。このタグ制限が構成されていて、StoreFrontストアの [詳細なヘルスチェック] オプションが有効になっている場合、セッションが断続的に起動に失敗することがあります。
StoreFrontの要件
オンプレミスのStoreFront環境を使用している場合は、VDAが登録されている(または登録できる)すべてのCloud Connectorを、Delivery ControllerとしてStoreFrontに追加する必要があります。StoreFrontに追加されていないCloud Connectorは停止モードに移行できないため、ユーザーの起動に失敗することがあります。
リソースの可用性
停止状態中のリソースの可用性(アプリとデスクトップ)を確保するには、次の2 つの方法があります:
- 展開内のすべてのリソースの場所にリソースを公開します。
- StoreFront 1912 CU4またはそれ以降を使用している場合は、リソースを少なくとも1つのリソースの場所に公開し、すべてのStoreFrontサーバーで詳細なヘルスチェックをオンにします。StoreFront 2308より前のバージョンでは、詳細なヘルスチェックはデフォルトでオフになっており、管理者が有効にする必要があります。StoreFrontバージョン2308およびそれ以降では、この機能はデフォルトで有効になっています。詳細なヘルスチェックを有効にする方法の詳細と手順については、 「詳細なヘルス チェック」を参照してください。
アプリケーションとデスクトップのサポート
LHCは次の種類のVDAと配信モデルをサポートしています:
VDAの種類 | 配信モデル | LHCイベント中のVDAの可用性 |
---|---|---|
マルチセッションOS | アプリケーションとデスクトップ | 常に利用できます。 |
シングルセッションOS静的(割り当て済み) | デスクトップ | 常に利用できます。 |
電源管理されたシングルセッションOSランダム(プール)
|
デスクトップ
|
デフォルトでは利用できません。プールされたデリバリーグループ内の電源管理されたVDAに対する、すべてのセッション起動の試みは、デフォルトで失敗します。
LHCイベント中の新しい接続で利用可能にできます。詳しくは、Studioを使用した有効化およびPowerShellを使用した有効化を参照してください。 重要: 電源管理された、シングルセッションのプールされたマシンへのアクセスを有効にすると、以前のユーザーセッションからのデータと変更が後続のセッションに残る可能性があります。 |
注:
プールされたデリバリーグループ内の電源管理されたデスクトップVDAへのアクセスを有効にしても、通常の操作中に構成された
ShutdownDesktopsAfterUse
プロパティの機能結果には影響しません。LHC中にこれらのデスクトップへのアクセスが有効になっている場合、LHCイベントの完了後、VDAは自動的に再起動しません。プールされたデリバリーグループ内の電源管理されたデスクトップVDAは、再起動するまで以前のセッションのデータを保持できます。VDAの再起動は、ユーザーがLHC以外の操作中にVDAからログオフしたとき、または管理者がVDAを再起動したときに発生することがあります。
Studioを使用し、電源管理されたシングルセッションOSのプールされたVDAに対してLHCを有効にする
Studioを使用すると、デリバリーグループごとに、LHCイベント中にこれらのマシンを新しい接続で利用できるようになります:
- デリバリーグループの作成中にこの機能を有効にするには、「デリバリーグループの作成」を参照してください。
- 既存のデリバリーグループでこの機能を有効にするには、「デリバリーグループの管理」を参照してください
注:
この設定は、電源管理されたVDAを配信するプールされたデスクトップデリバリーグループに対する、Studioでのみ使用できます。
PowerShellを使用し、電源管理されたシングルセッションOSのプールされたVDAに対してLHCを有効にする
特定のデリバリーグループ内のVDAに対してLHCを有効にするには、次の手順を実行します:
-
次のコマンドを実行して、サイトレベルでこの機能を有効にします:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
-
デリバリーグループ名を指定してこのコマンドを実行し、デリバリーグループのLHCを有効にします:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
電源管理されたVDAを含む新しく作成されたプールされたデリバリーグループで、デフォルトのLHCの可用性を変更するには、次のコマンドを実行します:
Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true
ローカルホストキャッシュが動作していることを確認する
ローカルホストキャッシュが正しく構成されていることを確認する方法を以下の動画で説明します。
ローカルホストキャッシュが適切に設定され動作していることを確認するには:
- StoreFrontを使用している場合は、ローカルのStoreFrontが、このリソースの場所内のすべてのCloud Connectorをポイントしていることを確認します。
- 同期のインポートが正常に完了していることを確認します。イベントログをチェックします。
- 各Cloud Connectorにローカルホストキャッシュデータベースが作成されていることを確認します。これにより、必要に応じてHigh Availability Serviceが処理を引き継げるようになります。
- Cloud Connectorサーバーで
c:\Windows\ServiceProfiles\NetworkService
を参照します。 -
HaDatabaseName.mdf
およびHaDatabaseName_log.ldf
が作成されたことを確認します。
- Cloud Connectorサーバーで
- リソースの場所にあるすべてのCloud Connectorを強制的に停止します。ローカルホストキャッシュが動作することを確認したら、すべてのCloud Connectorを通常モードに戻します。これには約15分かかります。
イベントログ
イベントログに、同期および停止状態が発生した時刻が示されます。イベントビューアーのログでは、停止状態モードはHAモードと見なされます。
Config Synchronizer Service
通常の操作中、ローカルホストキャッシュブローカーを使用してCSSが構成データをローカルホストキャッシュデータベースにインポートすると次のイベントが発生することがあります。
- 503:Citrix Config Sync Serviceが更新された構成を受信しました。このイベントは、Citrix Cloudから更新済みの構成を受信するたびに発生します。このイベントは、同期プロセスが開始されたことを表します。
- 504:Citrix Config Sync Serviceが更新された構成をインポートしました。構成のインポートが正常に完了しました。
- 505:Citrix Config Sync Serviceがインポートに失敗しました。構成のインポートが正常に完了しませんでした。過去に正常にインポートされた構成がある場合、停止状態の発生時にはその構成が使用されます。ただし、この構成は現在の構成よりも古いものです。使用可能な過去の構成がない場合、停止状態中、サービスはセッション仲介に参加できません。この場合は、「トラブルシューティング」セクションを確認の上、Citrixサポートにお問い合わせください。
- 507:システムが停止状態であり、ローカルホストキャッシュブローカーが使用中であるため、Citrix Config Sync Serviceによりインポートが中止されました。サービスは新しい構成を受け取りましたが、停止状態が発生したためインポートは中止されました。これは正常な動作です。
- 510:プライマリ構成サービスから構成サービス構成データを受信していません。
- 517:プライマリブローカーとの通信に問題がありました。
- 518:セカンダリブローカー(High Availability Service)が実行されていないため、Config Syncスクリプトが中止されました。
高可用性サービス
このサービスは、ローカルホストキャッシュブローカーとも呼ばれます。
- 3502:停止状態が発生しローカルホストキャッシュブローカーが仲介操作を実行しています。
- 3503:停止状態が解消され、通常の操作が再開しました。
- 3504:どのローカルホストキャッシュブローカーが選出されたかと、選出に関わった他のローカルホストキャッシュブローカーを示します。
- 3507:ローカルホストキャッシュの更新された状態情報を2分ごとに提供します。この情報は、選択されたブローカーでローカルホストキャッシュモードがアクティブであることを示すものです。停止時間、VDA登録、セッション情報など、停止の概要も含まれます。
- 3508:選択されたブローカー上でローカルホストキャッシュがアクティブではなくなり、通常の操作が復元されたことを通知します。停止時間、ローカルホストキャッシュ(LHC)イベント中に登録されたマシンの数、LHCイベント中に成功した起動の数など、停止の概要も含まれます。
- 3509:選択されていないブローカー上でローカルホストキャッシュがアクティブであることを通知します。2分ごとの停止時間と選択されているブローカーも通知します。
- 3510:選択されていないブローカー上でローカルホストキャッシュがアクティブでなくなったことを通知します。停止時間と選択されているブローカーも通知します。
Remote Broker Provider
このサービスは、Citrix CloudとVDAおよびCloud Connector間のプロキシとして機能します。
- 3001:Cloud ConnectorがHAモードに移行する必要があるかどうかを確認します。このイベントは、Cloud Connectorのヘルスチェックが1回失敗した後に発生します。60秒後に追加のヘルスチェックが失敗した場合、Cloud ConnectorはHAモードに移行します。
- 3002:Cloud ConnectorがHAモードに移行できないことを通知します。HAモードに移行できない理由はイベント情報に含まれます。
-
3003:Cloud ConnectorがさまざまなHAモード状態に移行していることを通知します。この図は、HAモードの開始と終了の状態を示しています。イベントでは以下の詳細が提供されます:
- Cloud Connectorの移行前の状態。
- Cloud Connectorの移行後の状態。
- 前の状態の継続期間。
注:
Cloud Connectorで、3001イベントが頻繁に表示されることがあります。これらのイベントはネットワークの状態によって発生する可能性があり、心配する必要はありません。
停止状態の強制
停止状態は意図的に発生させることもできます。
- ネットワークが稼動と停止を繰り返している場合。ネットワークの問題が解決するまで強制的に停止状態にすることにより、通常モードと停止状態モードの移行が繰り返され、VDA登録ストームが頻繁に発生するのを防げます。
- 障害回復プランをテストするには:
- ローカルホストキャッシュが正常に動作することを確認する場合。
Cloud Connectorは強制停止中に更新できますが、予期しない問題が発生する可能性があります。強制停止モードの間隔を避けるために、Cloud Connectorの更新のスケジュールを設定することをお勧めします。
強制的に停止状態にするには、各Cloud Connectorサーバーのレジストリを編集します。HKLM\Software\Citrix\DesktopServer\LHC
でOutageModeForced
を作成し、REG_DWORD
を1
に設定します。この設定により、ローカルホストキャッシュブローカーはCitrix Cloudへの接続状態に関係なく停止状態モードに入ります。値を0
に設定すると、ローカルホストキャッシュブローカーの停止状態モードは終了します。
イベントを確認するには、C:\ProgramData\Citrix\workspaceCloud\Logs\Plugins\HighAvailabilityService
のCurrent_HighAvailabilityService
ログファイルを監視します。
トラブルシューティング
ローカルホストキャッシュデータベースへの同期インポートが失敗し505イベントがポストされた場合には、次のトラブルシューティングツールが役立ちます。
CDFトレーシング:ConfigSyncServerモジュールおよびBrokerLHCモジュール向けのオプションが用意されています。これらのオプションと他のブローカーモジュールを組み合わせることで、問題を特定できます。
レポート:同期インポートが失敗した場合は、レポートを生成できます。このレポートの最後に、エラーの原因となったオブジェクトが記載されています。このレポート機能は同期速度に影響するため、Citrixでは使用しないときは無効にしておくことをお勧めします。
CSSトレースレポートを有効化および作成するには、次のコマンドを入力します:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC
-Name EnableCssTraceMode -PropertyType DWORD -Value 1
HTMLレポートはC:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html
に格納されます。
レポートが生成されたら、次のコマンドを入力してレポート機能を無効にします:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC
-Name EnableCssTraceMode -Value 0
ローカルホストキャッシュ用のPowerShellコマンド
PowerShellコマンドを使用して、Cloud Connector上のローカルホストキャッシュを管理できます。
PowerShellモジュールは、Cloud Connector上の次の場所にあります。
C:\Program Files\Citrix\Broker\Service\ControlScripts
重要:
このモジュールはCloud Connector上でのみ実行します。
PowerShellモジュールのインポート
PowerShellモジュールをインポートするには、Cloud Connectorで次のコマンドを実行します。
cd C:\Program Files\Citrix\Broker\Service\ControlScripts
Import-Module .\HighAvailabilityServiceControl.psm1
LHCを管理するためのPowerShellコマンド
以下のコマンドレットは、Cloud ConnectorでLHCモードをアクティブ化して管理するのに役立ちます。
コマンドレット | 機能 |
---|---|
Enable-LhcForcedOutageMode |
ブローカーをLHCモードにします。Enable-LhcForcedOutageMode が正しく機能するには、ローカルホストキャッシュのデータベースファイルがConfigSync Serviceによって正常に作成されている必要があります。このコマンドレットは、LHCが実行されていたCloud Connectorでのみ、LHCを強制的にアクティブ化します。LHCをアクティブにするには、リソースの場所内のすべてのCloud Connectorでこのコマンドレットを実行する必要があります。 |
Disable-LhcForcedOutageMode |
ブローカーのLHCモードを解除します。このコマンドレットは、実行されたCloud Connector上でのみLHCモードを無効にします。Disable-LhcForcedOutageMode をリソースの場所内のすべてのCloud Connectorで実行する必要があります。 |
Set-LhcConfigSyncIntervalOverride |
Citrix Config Synchronizer Service(CSS)がCitrix DaaSサイト内に構成変更がないかをチェックする間隔を設定します。この時間間隔の範囲は60秒(1分)~3600秒(1時間)です。この設定は、LHCが実行されていたCloud Connectorにのみ適用されます。Cloud Connector全体で一貫した設定になるよう、各Cloud Connectorでこのコマンドレットを実行することを検討してください。たとえば、次のようになります:Set-LhcConfigSyncIntervalOverride -Seconds 1200
|
Clear-LhcConfigSyncIntervalOverride |
Citrix Config Synchronizer Service(CSS)がCitrix DaaSサイト内に構成変更がないかをチェックする間隔をデフォルト値の300秒(5分)に設定します。この設定は、LHCが実行されていたCloud Connectorにのみ適用されます。Cloud Connector全体で一貫した設定になるよう、各Cloud Connectorでこのコマンドレットを実行することを検討してください。 |
Enable-LhcHighAvailabilitySDK |
LHCが実行されていたCloud Connector内で、すべてのGet-Broker* コマンドレットへのアクセスを有効にします。 |
Disable-LhcHighAvailabilitySDK |
LHCが実行されていたCloud Connector内で、Broker PowerShellコマンドレットへのアクセスを無効にします。 |
注:
- Cloud Connectorで
Get-Broker*
コマンドレットを実行する場合は、ポート89を使用します。例:
Get-BrokerMachine -AdminAddress localhost:89
- LHCモードではないCloud ConnectorのLHCブローカーは、構成情報のみを保持しています。
- LHCモード中、選択されたCloud ConnectorのLHCブローカーは次の情報を保持しています。
- リソースの状態
- セッションの詳細
- VDA登録
- 構成情報
追加情報
以下については、「ローカルホストキャッシュのスケールおよびサイズの考慮事項」を参照してください:
- テスト方法と結果
- RAMサイズの考慮事項
- CPUコアとソケットの構成に関する考慮事項
- ストレージの考慮事項