Azure Analysis Services のスケールアウトAzure Analysis Services scale-out

スケールアウトによって、クエリ プール内の複数のクエリ レプリカ間でクライアント クエリを分散して、負荷の高いクエリのワークロードを実行している間の応答時間を短縮できます。With scale-out, client queries can be distributed among multiple query replicas in a query pool, reducing response times during high query workloads. クエリ プールから処理を分離して、クライアント クエリが処理操作の悪影響を受けないようにすることもできます。You can also separate processing from the query pool, ensuring client queries are not adversely affected by processing operations. スケールアウトを構成するには Azure Portal から行うか、または Analysis Services の REST API を使用します。Scale-out can be configured in Azure portal or by using the Analysis Services REST API.

スケールアウトは Standard 価格レベルのサーバーで使用できます。Scale-out is available for servers in the Standard pricing tier. 各クエリ レプリカは、お使いのサーバーと同じ料金で課金されます。Each query replica is billed at the same rate as your server. すべてのクエリ レプリカは、サーバーと同じリージョンに作成されます。All query replicas are created in the same region as your server. 構成できるクエリ レプリカ数は、サーバーが存在しているリージョンによって制限されます。The number of query replicas you can configure are limited by the region your server is in. 詳細については、「リージョンごとの可用性」を参照してください。To learn more, see Availability by region. スケールアウトでは、サーバーで使用可能なメモリの量は増えません。Scale-out does not increase the amount of available memory for your server. メモリを増やすには、プランをアップグレードする必要があります。To increase memory, you need to upgrade your plan.

スケール アウトする理由Why scale out?

一般的なサーバーのデプロイでは、1 つのサーバーで、処理サーバーとクエリ サーバーの両方の役割を果たします。In a typical server deployment, one server serves as both processing server and query server. サーバー上のモデルに対するクライアント クエリの数が、加入しているサーバー プランのクエリ プロセッシング ユニット (QPU) を超過した場合、またはモデル処理が負荷の高いクエリのワークロードと同時に発生した場合、パフォーマンスが低下することがあります。If the number of client queries against models on your server exceeds the Query Processing Units (QPU) for your server's plan, or model processing occurs at the same time as high query workloads, performance can decrease.

スケールアウトでは、最大 7 つの追加のクエリ レプリカ リソース (プライマリ サーバーを含めて合計 8 つ) を含むクエリ プールを作成できます。With scale-out, you can create a query pool with up to seven additional query replica resources (eight total, including your primary server). 重要な場面では、QPU の需要を満たせるようにクエリ プール内のレプリカの数をスケーリングできます。また、処理サーバーはいつでもクエリ プールから分離できます。You can scale the number of replicas in the query pool to meet QPU demands at critical times, and you can separate a processing server from the query pool at any time.

クエリ プール内にあるクエリ レプリカの数に関わらず、ワークロードの処理はクエリ レプリカ間で分散されません。Regardless of the number of query replicas you have in a query pool, processing workloads are not distributed among query replicas. プライマリ サーバーが処理サーバーとして機能します。The primary server serves as the processing server. クエリ レプリカは、クエリ プール内のプライマリ サーバーと各レプリカ間で同期されているモデル データベースに対するクエリにのみ機能します。Query replicas serve only queries against the model databases synchronized between the primary server and each replica in the query pool.

スケールアウトすると、新しいクエリ レプリカがクエリ プールに増分的に追加されるのに最大 5 分かかることがあります。When scaling out, it can take up to five minutes for new query replicas to be incrementally added to the query pool. すべての新しいクエリ レプリカが稼働すると、新しいクライアント接続はクエリ プール内のリソースに負荷分散されます。When all new query replicas are up and running, new client connections are load balanced across resources in the query pool. 既存のクライアント接続は、現在の接続先のリソースから変更されることはありません。Existing client connections are not changed from the resource they are currently connected to. スケールインすると、クエリ プールから削除されるクエリ プール リソースへの既存のクライアント接続が終了します。When scaling in, any existing client connections to a query pool resource that is being removed from the query pool are terminated. クライアントは、残りのクエリ プールのリソースに再接続できます。Clients can reconnect to a remaining query pool resource.

しくみHow it works

スケールアウトを初めて構成すると、プライマリ サーバー上のモデル データベースが新しいクエリ プール内の新しいレプリカと自動的に同期されます。When configuring scale-out the first time, model databases on your primary server are automatically synchronized with new replicas in a new query pool. 自動同期は 1 回だけ行われます。Automatic synchronization occurs only once. 自動同期中に、(暗号化されて BLOB ストレージに保存された) プライマリ サーバーのデータ ファイルが 2 番目の場所にコピーされ、同様に暗号化されて BLOB ストレージに保存されます。During automatic synchronization, the primary server's data files (encrypted at rest in blob storage) are copied to a second location, also encrypted at rest in blob storage. その後、クエリ プール内のレプリカは、ファイルの 2 番目のセットからのデータとともにハイドレートされます。Replicas in the query pool are then hydrated with data from the second set of files.

自動同期は初めてサーバーをスケールアウトするしか実行されませんが、手動同期を実行することもできます。While an automatic synchronization is performed only when you scale-out a server for the first time, you can also perform a manual synchronization. 同期により、クエリ プール内のレプリカのデータがプライマリ サーバーのデータと一致することが保証されます。Synchronizing assures data on replicas in the query pool match that of the primary server. プライマリ サーバーでモデルを処理 (更新) する場合は、処理操作が完了したで同期が行われる必要があります。When processing (refresh) models on the primary server, a synchronization must be performed after processing operations are completed. この同期により、BLOB ストレージ内のプライマリ サーバーのファイルから 2 つ目のファイル セットに、更新されたデータがコピーされます。This synchronization copies updated data from the primary server's files in blob storage to the second set of files. その後、クエリ プール内のレプリカは、BLOB ストレージ内の 2 つ目のファイル セットから、更新されたデータとともにハイドレートされます。Replicas in the query pool are then hydrated with updated data from the second set of files in blob storage.

その後のスケールアウト操作を実行すると、たとえばクエリ プール内のレプリカの数を 2 つから 5 つに増やすと、新しいレプリカが BLOB ストレージ内のファイル セットからデータとともにハイドレートされます。When performing a subsequent scale-out operation, for example, increasing the number of replicas in the query pool from two to five, the new replicas are hydrated with data from the second set of files in blob storage. 同期はありません。There is no synchronization. スケール アウト後に同期を実行すると、クエリ プール内の新しいレプリカは 2 回ハイドレートされ、冗長ハイドレーションになります。If you then perform a synchronization after scaling out, the new replicas in the query pool would be hydrated twice - a redundant hydration. その後のスケールアウト操作を実行するときは、次の点に留意することが重要です。When performing a subsequent scale-out operation, it's important to keep in mind:

  • 追加されたレプリカの冗長ハイドレーションを回避するため、スケールアウト操作の前に同期を実行してください。Perform a synchronization before the scale-out operation to avoid redundant hydration of the added replicas. 同時実行同期とスケールアウト操作を同時に実行することはできません。Concurrent synchronization and scale-out operations running at the same time are not allowed.

  • 処理スケールアウトの操作を両方とも自動化する場合に重要なことは、最初にプライマリ サーバーでデータを処理してから同期を実行し、その後でスケールアウト操作を実行することです。When automating both processing and scale-out operations, it's important to first process data on the primary server, then perform a synchronization, and then perform the scale-out operation. この順序により、QPU とメモリのリソースに対する影響が最小限に抑えられます。This sequence assures minimal impact on QPU and memory resources.

  • スケールアウト操作中、クエリ プール内のすべてのサーバー (プライマリ サーバーを含む) が一時的にオフラインになります。During scale-out operations, all servers in the query pool, including the primary server, are temporarily offline.

  • クエリ プールにレプリカがない場合でも、同期は許可されます。Synchronization is allowed even when there are no replicas in the query pool. プライマリ サーバーでの処理操作からの新しいデータを使用してゼロから 1 つ以上のレプリカにスケールアウトする場合は、まずクエリ プールにレプリカがない状態で同期を実行してから、スケールアウトします。スケール アウトする前に同期することで、新しく追加されたレプリカの冗長ハイドレーションが回避されます。If you are scaling out from zero to one or more replicas with new data from a processing operation on the primary server, perform the synchronization first with no replicas in the query pool, and then scale-out. Synchronizing before scaling out avoids redundant hydration of the newly added replicas.

  • モデル データベースをプライマリ サーバーから削除しても、クエリ プール内のレプリカから自動的には削除されません。When deleting a model database from the primary server, it does not automatically get deleted from replicas in the query pool. そのデータベースのファイルをレプリカの共有 BLOB ストレージの場所から削除してから、クエリ プール内のレプリカ上のモデル データベースを削除する、Sync-AzAnalysisServicesInstance PowerShell コマンドを使用して、同期操作を実行する必要があります。You must perform a synchronization operation by using the Sync-AzAnalysisServicesInstance PowerShell command that removes the file/s for that database from the replica's shared blob storage location and then deletes the model database on the replicas in the query pool. model データベースがクエリ プール内のレプリカには存在していてプライマリ サーバーには存在していないかどうかを調べるには、 [処理中のサーバーと照会中のプールを分けてください][はい] に設定されていることを確認します。To determine if a model database exists on replicas in the query pool but not on the primary server, ensure the Separate the processing server from querying pool setting is to Yes. 次に、SSMS を使用し、:rw 修飾子を使ってプライマリ サーバーに接続して、データベースが存在するかどうかを確認します。Then use SSMS to connect to the primary server using the :rw qualifier to see if the database exists. 次に、:rw 修飾子を使わずに接続することでクエリ プール内のレプリカに接続して、同じデータベースがそこにも存在するかどうかを確認します。Then connect to replicas in the query pool by connecting without the :rw qualifier to see if the same database also exists. データベースがクエリ プール内のレプリカには存在していて、プライマリ サーバーには存在していない場合は、同期操作を実行します。If the database exists on replicas in the query pool but not on the primary server, run a sync operation.

  • プライマリ サーバー上のデータベースの名前を変更する場合は、データベースがすべてのレプリカに適切に同期されようにするために必要な追加の手順があります。When renaming a database on the primary server, there's an additional step necessary to ensure the database is properly synchronized to any replicas. 名前を変更した後、-Database パラメーターに古いデータベース名を指定して Sync-AzAnalysisServicesInstance コマンドを使用して同期を実行します。After renaming, perform a synchronization by using the Sync-AzAnalysisServicesInstance command specifying the -Database parameter with the old database name. この同期により、古い名前を持つデータベースとファイルがレプリカから削除されます。This synchronization removes the database and files with the old name from any replicas. その後、新しいデータベース名で -Database パラメーターを使用して、もう一度同期を実行します。Then perform another synchronization specifying the -Database parameter with the new database name. 2 回目の同期により、新しい名前のデータベースが 2 つ目のファイル セットにコピーされ、レプリカがハイドレートされます。The second synchronization copies the newly named database to the second set of files and hydrates any replicas. これらの同期は、ポータルでモデルの同期コマンドを使用して実行することはできません。These synchronizations cannot be performed by using the Synchronize model command in the portal.

同期化モードSynchronization mode

既定では、クエリ レプリカは増分ではなく、完全にリハイドレートされます。By default, query replicas are rehydrated in full, not incrementally. リハイドレートは段階的に行われます。Rehydration happens in stages. 一度に 1 つ以上のレプリカが同時にオンラインになっていることを確認するために (少なくとも 3 つのレプリカがある場合)、一度に 2 つづつデタッチおよびアタッチされます。They are detached and attached two at a time (assuming there are at least three replicas) to ensure at least one replica is kept online for queries at any given time. 場合によっては、このプロセスの実行中に、クライアントがオンライン レプリカの 1 つに再接続する必要になる場合があります。In some cases, clients may need to reconnect to one of the online replicas while this process is taking place. ReplicaSyncMode 設定を使用して、クエリ レプリカの同期を並列で実行するように指定できるようになりました。By using the ReplicaSyncMode setting, you can now specify query replica synchronization occurs in parallel. 並列同期には、次のような利点があります。Parallel synchronization provides the following benefits:

  • 同期時間が大幅に短縮されます。Significant reduction in synchronization time.
  • 同期プロセス中のレプリカ間のデータに一貫性が保たれる可能性が高くなります。Data across replicas are more likely to be consistent during the synchronization process.
  • データベースは同期プロセス全体を通してすべてのレプリカでオンラインに保持されるため、クライアントは再接続する必要はありません。Because databases are kept online on all replicas throughout the synchronization process, clients do not need to reconnect.
  • メモリ内キャッシュは、変更されたデータのみが段階的に更新されます。これは、モデルを完全にリハイドレートするよりも高速です。The in-memory cache is updated incrementally with only the changed data, which can be faster than fully rehydrating the model.

ReplicaSyncMode の設定Setting ReplicaSyncMode

SSMS を使用して、詳細プロパティで ReplicaSyncMode を設定します。Use SSMS to set ReplicaSyncMode in Advanced Properties. 指定できる値は、The possible values are:

  • 1 (既定値): 完全なレプリカ データベースのリハイドレート (増分)。1 (default): Full replica database rehydration in stages (incremental).
  • 2:並列での同期の最適化。2: Optimized synchronization in parallel.

RelicaSyncMode 設定

ReplicaSyncMode=2 を設定する場合、更新する必要のあるキャッシュの量によっては、クエリ レプリカによってさらにメモリが消費される可能性があります。When setting ReplicaSyncMode=2, depending on how much of the cache needs to be updated, additional memory may be consumed by the query replicas. クエリで使用できるようデータベースをオンラインに保つため、変更されたデータの量によっては、古いセグメントと新しいセグメントの両方が同時にメモリに保持されるので、この操作では、レプリカに対して最大 2 倍のメモリが必要になることがあります。To keep the database online and available for queries, depending on how much of the data has changed, the operation can require up to double the memory on the replica because both the old and new segments are kept in memory simultaneously. レプリカ ノードのメモリ割り当てはプライマリ ノードと同じであり、通常は更新操作のためにプライマリ ノードには追加のメモリがあります。そのため、レプリカのメモリが不足することは稀です。Replica nodes have the same memory allocation as the primary node, and there is normally extra memory on the primary node for refresh operations, so it may be unlikely that the replicas would run out of memory. また、一般的なシナリオでは、データベースがプライマリ ノードで増分更新されるため、メモリを倍にする必要があることは珍しくありません。Additionally, the common scenario is that the database is incrementally updated on the primary node, and therefore the requirement for double the memory should be uncommon. 同期操作でメモリ不足エラーが発生した場合は、既定の手法 (一度に 2 つづつアタッチまたはデタッチする手法) を使用して再試行します。If the Sync operation does encounter an out of memory error, it will retry using the default technique (attach/detach two at a time).

クエリ プールから分離した処理Separate processing from query pool

処理操作とクエリ操作の両方のパフォーマンスを最大限にするために、処理サーバーをクエリ プールから分離することができます。For maximum performance for both processing and query operations, you can choose to separate your processing server from the query pool. 分離すると、新規のクライアント接続は、クエリ プール内のクエリ レプリカにのみ割り当てられます。When separated, new client connections are assigned to query replicas in the query pool only. 処理操作にそれほど時間がかからない場合は、、処理操作と同期操作を実行している間だけ処理サーバーをクエリ プールから分離し、その後、クエリ プールに戻すこともできます。If processing operations only take up a short amount of time, you can choose to separate your processing server from the query pool only for the amount of time it takes to perform processing and synchronization operations, and then include it back into the query pool. クエリ プールから処理サーバーを分離するとき、またはクエリ プールに追加して戻すときは、操作が完了するまでに最大で 5 分かかることがあります。When separating the processing server from the query pool, or adding it back into the query pool can take up to five minutes for the operation to complete.

QPU の使用状況を監視するMonitor QPU usage

お使いのサーバーでスケールアウトが必要かどうかを判断するには、Azure portal でメトリックを使用してサーバーを監視しますTo determine if scale-out for your server is necessary, monitor your server in Azure portal by using Metrics. QPU が頻繁に上限に達するようであれば、モデルに対するクエリの数が、お使いのプランに設定されている QPU の制限を超過していることになります。If your QPU regularly maxes out, it means the number of queries against your models is exceeding the QPU limit for your plan. クエリ スレッド プール キュー内のキュー数が、利用可能な QPU を超過した場合も、クエリ プールのジョブ キュー長のメトリックは増加します。The Query pool job queue length metric also increases when the number of queries in the query thread pool queue exceeds available QPU.

注意しておくとよいもう 1 つのメトリックは、ServerResourceType 別の平均 QPU です。Another good metric to watch is average QPU by ServerResourceType. このメトリックは、プライマリ サーバーの平均 QPU とクエリ プールの平均 QPU を比較します。This metric compares average QPU for the primary server with the query pool.


ServerResourceType 別の QPU を構成するTo configure QPU by ServerResourceType

  1. メトリックの折れ線グラフで、 [メトリックの追加] をクリックします。In a Metrics line chart, click Add metric.
  2. [リソース] でサーバーを選択し、 [メトリック名前空間][Analysis Services standard metrics](Analysis Services の標準的なメトリック) を選択します。次に、 [メトリック][QPU] を選択し、 [集計][平均] を選択します。In RESOURCE, select your server, then in METRIC NAMESPACE, select Analysis Services standard metrics, then in METRIC, select QPU, and then in AGGREGATION, select Avg.
  3. [Apply Splitting](分割の適用) をクリックします。Click Apply Splitting.
  4. [値] で、 [ServerResourceType] を選択します。In VALUES, select ServerResourceType.

詳細な診断ログDetailed diagnostic logging

スケールアウトされたサーバー リソースのより詳細な診断には、Azure Monitor ログを使用します。Use Azure Monitor Logs for more detailed diagnostics of scaled out server resources. ログに対して Log Analytics クエリを使用して、サーバーおよびレプリカ別に QPU とメモリを分割できます。With logs, you can use Log Analytics queries to break out QPU and memory by server and replica. 詳細については、Analysis Services の診断ログに関するページのクエリの例を参照してください。To learn more, see example queries in Analysis Services diagnostics logging.

スケールアウトを構成するConfigure scale-out

Azure PortalIn Azure portal

  1. ポータルで、 [スケールアウト] をクリックします。スライダーを使用してクエリ レプリカ サーバーの数を選択します。In the portal, click Scale-out. Use the slider to select the number of query replica servers. 選択したレプリカの数は既存のサーバーの数に追加されます。The number of replicas you choose is in addition to your existing server.

  2. [処理中のサーバーと照会中のプールを分けてください] で、[はい] を選択してクエリ サーバーから処理中のサーバーを除外します。In Separate the processing server from the querying pool, select yes to exclude your processing server from query servers. 既定の接続文字列 (:rw なし) を利用するクライアント接続は、クエリ プールのレプリカにリダイレクトされます。Client connections using the default connection string (without :rw) are redirected to replicas in the query pool.

    スケールアウト スライダー

  3. [保存] をクリックして新しいクエリ レプリカ サーバーをプロビジョニングします。Click Save to provision your new query replica servers.

初めてサーバーでスケールアウトを構成すると、プライマリ サーバー上のモデル データベースがクエリ プール内のレプリカと自動的に同期されます。When configuring scale-out for a server the first time, models on your primary server are automatically synchronized with replicas in the query pool. 自動同期は、1 つまたは複数のレプリカへのスケールアウトを初めて構成するときに、1 回だけ行われます。Automatic synchronization only occurs once, when you first configure scale-out to one or more replicas. その後で同じサーバー上のレプリカの数を変更しても、自動同期はそれ以上トリガーされませんSubsequent changes to the number of replicas on the same server will not trigger another automatic synchronization. サーバーのレプリカを 0 に設定してから、もう一度任意の数のレプリカにスケールアウトしても、自動同期が再度行われることはありません。Automatic synchronization will not occur again even if you set the server to zero replicas and then again scale-out to any number of replicas.


同期操作は、手動で実行するか、REST API を使用して実行する必要があります。Synchronization operations must be performed manually or by using the REST API.

Azure PortalIn Azure portal

[概要] > 対象のモデル > [Synchronize model](モデルの同期) の順に選択します。In Overview > model > Synchronize model.

[同期] アイコン


sync 操作を使用します。Use the sync operation.

モデルを同期するSynchronize a model

POST https://<region><servername>:rw/models/<modelname>/sync

同期状態を取得するGet sync status

GET https://<region><servername>/models/<modelname>/sync

リターン状態コード:Return status codes:

コードCode 説明Description
-1-1 無効Invalid
00 レプリケーション中Replicating
11 リハイドレート中Rehydrating
22 完了Completed
33 失敗Failed
44 終了処理中Finalizing



この記事は、新しい Azure PowerShell Az モジュールを使用するために更新されました。This article has been updated to use the new Azure PowerShell Az module. AzureRM モジュールはまだ使用でき、少なくとも 2020 年 12 月までは引き続きバグ修正が行われます。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Az モジュールと AzureRM の互換性の詳細については、「Introducing the new Azure PowerShell Az module (新しい Azure PowerShell Az モジュールの概要)」を参照してください。To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Az モジュールのインストール手順については、Azure PowerShell のインストールを参照してください。For Az module installation instructions, see Install Azure PowerShell.

PowerShell を使用する前に、最新の Azure PowerShell モジュールをインストールまたは更新しますBefore using PowerShell, install or update the latest Azure PowerShell module.

同期を実行するには、Sync-AzAnalysisServicesInstance を使用します。To run sync, use Sync-AzAnalysisServicesInstance.

クエリ レプリカの数を設定するには、Set-AzAnalysisServicesServer を使用します。To set the number of query replicas, use Set-AzAnalysisServicesServer. 省略可能な -ReadonlyReplicaCount パラメーターを指定します。Specify the optional -ReadonlyReplicaCount parameter.

処理サーバーをクエリ プールから分離するには、Set-AzAnalysisServicesServer を使用します。To separate the processing server from the query pool, use Set-AzAnalysisServicesServer. 省略可能な -DefaultConnectionMode パラメーターを Readonly を使用するように指定します。Specify the optional -DefaultConnectionMode parameter to use Readonly.

詳しくは、Az.AnalysisServices モジュールでのサービス プリンシパルの使用に関する記事をご覧ください。To learn more, see Using a service principal with the Az.AnalysisServices module.


サーバーの [概要] ページに、サーバー名が 2 つ表示されます。On your server's Overview page, there are two server names. サーバーのスケールアウトをまだ構成していない場合は、両方のサーバー名は同じものとして機能します。If you haven't yet configured scale-out for a server, both server names work the same. サーバーのスケールアウトを構成したら、接続の種類に応じて適切なサーバー名を指定する必要があります。Once you configure scale-out for a server, you need to specify the appropriate server name depending on the connection type.

Power BI Desktop、Excel、カスタム アプリなどのエンドユーザー クライアントの接続については、 [サーバー名] を使用します。For end-user client connections like Power BI Desktop, Excel, and custom apps, use Server name.

SSMS、Visual Studio、および PowerShell、Azure 関数アプリ、AMO の接続文字列については、 [管理サーバー名] を使用します。For SSMS, Visual Studio, and connection strings in PowerShell, Azure Function apps, and AMO, use Management server name. 管理サーバー名は特殊な :rw (読み取り/書き込み) 修飾子を含みます。The management server name includes a special :rw (read-write) qualifier. すべての処理操作は (プライマリ) 管理サーバーで発生します。All processing operations occur on the (primary) management server.


スケールアップ、スケールダウン、およびスケールアウトScale-up, Scale-down vs. Scale-out

複数のレプリカを持つサーバーの価格レベルを変更できます。You can change the pricing tier on a server with multiple replicas. 同じ価格レベルがすべてのレプリカに適用されます。The same pricing tier applies to all replicas. スケーリング操作では、まずすべてのレプリカが一度に停止された後、すべてのレプリカが新しい価格レベルで起動されます。A scale operation will first bring down all replicas all at once then bring up all replicas on the new pricing tier.


問題: ユーザーに "Cannot find server '<Name of the server>' instance in connection mode 'ReadOnly' " (接続モード 'ReadOnly' でサーバー '<サーバーの名前>' インスタンスが見つかりません) というエラーが表示されます。Issue: Users get error Cannot find server '<Name of the server>' instance in connection mode 'ReadOnly'.

解決方法: [処理中のサーバーと照会中のプールを分けてください] オプションが選択されているとき、既定の接続文字列 (:rw なし) を利用するクライアント接続は、クエリ プールのレプリカにリダイレクトされます。Solution: When selecting the Separate the processing server from the querying pool option, client connections using the default connection string (without :rw) are redirected to query pool replicas. 同期が完了していないため、クエリ プールのレプリカがオンラインになっていない場合、リダイレクトのクライアント接続は失敗することがあります。If replicas in the query pool are not yet online because synchronization has not yet been completed, redirected client connections can fail. 接続の失敗を防ぐには、同期の実行時にクエリ プール内に少なくとも 2 台のサーバーが含まれている必要があります。To prevent failed connections, there must be at least two servers in the query pool when performing a synchronization. 各サーバーは、他方のオンライン状態を維持したまま、個別に同期されます。Each server is synchronized individually while others remain online. 処理時にクエリ プール内の処理サーバーを使用しないことを選択した場合は、そのサーバーを処理用のプールから削除し、処理が完了した後、同期が行われる前にプールに戻すことができます。If you choose to not have the processing server in the query pool during processing, you can choose to remove it from the pool for processing, and then add it back into the pool after processing is complete, but prior to synchronization. 同期の状態を監視するには、メモリと QPU のメトリックを使用します。Use Memory and QPU metrics to monitor synchronization status.

サーバー メトリックの監視 Monitor server metrics
Azure Analysis Services を管理するManage Azure Analysis Services