Azure Local にノードを追加する

適用対象: Azure Local の Hyperconverged デプロイ

この記事では、ノード (多くの場合、スケールアウトと呼ばれます) を Azure Local インスタンスに追加して容量を管理する方法について説明します。 この記事では、各サーバーをノードと呼びます。

ノードの追加について

既存のシステムにノードを追加することで、Azure Local でコンピューティングとストレージを同時に簡単にスケーリングできます。 Azure ローカル インスタンスでは、最大 16 個のノードがサポートされています。

システムに追加する新しい各物理ノードは、CPU の種類、メモリ、ドライブの数、ドライブの種類とサイズの点で、残りのノードと密接に一致する必要があります。

Azure ローカル インスタンスは、1 から 16 個のノードに動的にスケーリングできます。 スケーリングに応じて、オーケストレーター (ライフサイクル マネージャーとも呼ばれます) は、ドライブの回復性、オーケストレーター エージェントなどのオンプレミス エージェントを含むネットワーク構成、Arc 登録を調整します。 動的スケーリングでは、ネットワーク アーキテクチャを、スイッチなしで接続からネットワーク スイッチ経由で接続するように変更する必要がある場合があります。

重要

  • このリリースでは、任意の時点で 1 つのノードのみを追加できます。 ただし、記憶域プールが 1 回だけ再調整されるように、複数のノードを順番に追加できます。
  • システムからノードを完全に削除することはできません。

ノード ワークフローの追加

次のフロー図は、ノードを追加するプロセス全体を示しています。

ノードを追加するプロセスを示す図。

ノードを追加するには、次の大まかな手順に従います。

  1. 追加する新しいノードにオペレーティング システム、ドライバー、ファームウェアをインストールします。 詳細については、 OS のインストールを参照してください。
  2. Azure ポータルで PowerShell (Add-Server) またはAzure Local エクスペリエンスを使用して、準備済みノードを追加します。
  3. システムにノードを追加すると、新しい受信ノードが実際にノードを追加する前に、CPU、メモリ、ストレージ (ドライブ) の要件を満たしていることをシステムが検証します。
  4. ノードが追加されると、システムも検証され、正常に機能していることが確認されます。 次に、記憶域プールが自動的に再調整されます。 ストレージの再調整は、実際のワークロードに影響を与えない優先順位の低いタスクです。 再調整は、ノードの数と使用されるストレージに応じて、数日間実行できます。

注

カスタム ストレージ IP を使用して Azure Local インスタンスをデプロイした場合は、ノードの追加後に、ストレージ ネットワーク アダプターに IP を手動で割り当てる必要があります。

サポートされるシナリオ

ノードを追加すると、次のスケールアウト シナリオがサポートされます。

開始シナリオ ターゲット シナリオ 回復性の設定 ストレージ ネットワーク アーキテクチャ 監視設定
単一ノード 2 ノード システム 双方向ミラー スイッチを使用した場合と使用しない場合の設定 ターゲットシナリオには目撃者が必要です。
2 ノード システム 3 ノード システム 3 方向ミラー スイッチのみを使用して構成されている ターゲットシナリオでの証人は任意です。
3 ノード システム N ノード システム 3 方向ミラー スイッチのみ ターゲットシナリオでの証人は任意です。

システムを 2 から 3 つのノードにアップグレードすると、ストレージの回復性レベルが双方向ミラーから 3 方向ミラーに変わります。

現在、次のシナリオは、Azure ポータルではサポートされていません。

  • 単一ノードから 2 ノード システムへのスケールアウト
  • ラック対応クラスターのスケールアウト
  • ローカル可用性ゾーンを構成した分離型デプロイのスケールアウト
  • Azure Government クラウドにデプロイされたシステムでは、スケールアウトはサポートされていません

回復性の設定

このリリースでは、ノードの追加操作では、デプロイ後に作成するワークロード ボリュームに対して特定のタスクは実行されません。

ノードの追加操作では、必要なインフラストラクチャ ボリュームと、デプロイ中に作成するワークロード ボリュームの回復性設定が更新されます。 デプロイ後に作成する他のワークロード ボリュームの設定は同じままです (これらのボリュームの意図的な回復性設定は不明であり、システム スケールに関係なく双方向ミラー ボリュームが必要になる場合があるため)。

ただし、既定の回復性設定は記憶域プール レベルで更新されるため、デプロイ後に作成する新しいワークロード ボリュームは回復性設定を継承します。

ハードウェア要件

ノードを追加すると、システムは新しい受信ノードのハードウェアを検証し、ノードがシステムに追加する前にハードウェア要件を満たしていることを確認します。

コンポーネント コンプライアンス チェック
CPU 新しいノードに同じ数以上の CPU コアがあることを確認します。 受信ノードの CPU コアがこの要件を満たしていない場合は、警告が表示されます。 ただし、操作は許可されます。
[メモリ] 新しいノードに同じ量以上のメモリがインストールされていることを確認します。 受信ノードのメモリがこの要件を満たしていない場合は、警告が表示されます。 ただし、操作は許可されます。
ドライブ 新しいノードに、記憶域スペース ダイレクトで使用できるデータ ドライブの数が同じであることを確認します。 受信ノード上のドライブの数がこの要件を満たしていない場合は、エラーが報告され、操作がブロックされます。

前提条件

ノードを追加する前に、ハードウェアとソフトウェアの前提条件を満たす必要があります。

ハードウェアの前提条件

次の前提条件を満たしていることを確認します。

  1. 元の OEM から新しいAzure Local ハードウェアを取得します。 システムで使用する新しいノード ハードウェアを追加する場合は、OEM が提供するドキュメントを常に参照してください。
  2. 新しい物理ノードをラックなどの所定の場所に配置し、適切にケーブル接続します。
  3. ネットワーク環境で必要に応じて、物理スイッチ ポートを有効にして調整します。

ソフトウェアの必要なコンポーネント

次の前提条件を満たしていることを確認します。

  • AzureStackLCMUser は Active Directory でアクティブです。 詳細については、「 Active Directory の準備」を参照してください。
  • AzureStackLCMUserまたは同等のアクセス許可を持つ別のユーザーとしてサインインします。
  • AzureStackLCMUserの資格情報は変更されていません。

ノードの追加

Azure ポータルで PowerShell または Azure Local エクスペリエンスを使用して、Azure Local インスタンスにノードを追加できます。

ノードの追加ワークフローをスクリプト化して自動化する場合は、PowerShell を使用します。

準備 (PowerShell)

PowerShell を使用してノードを追加するには、次の手順に従います。

  1. 追加する新しいノードにオペレーティング システム、ドライバー、ファームウェアをインストールします。 詳細については、 OS のインストールを参照してください。

    重要

    バージョン 2503 以降では、既存のクラスターと同じソリューション バージョンの OS イメージを使用します。 ソリューションバージョンの取得を使用して実行中のソリューションのバージョンを特定し、OS イメージ テーブルを使用して一致するイメージを選択します。 一部のイメージ バージョンが一覧表示されない可能性があるため、Azureポータルからのみイメージを選択しないでください。

  2. 新しいノードを Arc に登録します。ガイダンスについては、「 Arc に登録してアクセス許可を設定する」を参照してください。

    注

    リソース グループ、リージョン、サブスクリプション、テナントなど、既存のノードと同じ Arc 登録パラメーターを使用します。

  3. 新しく追加したノードに、Azure Stack HCI デバイス管理 Role、Connected InfraVMs、Key Vault Secrets User を含む必要なアクセス許可を割り当てます。

  4. Add-Server コマンドレットを実行して、準備されたノードを Azure Local インスタンスに追加します。

    Example:

    Add-Server -Name "<new-node-name>"

  5. システム検証を待って、受信ノードが CPU、メモリ、ストレージ (ドライブ) の要件を満たしていることを確認します。

  6. ノードが正常に追加されたことを確認し、ストレージの再調整が完了することを許可します。 再調整は優先順位の低いバックグラウンド タスクであり、ノード数とストレージの使用状況に応じて、数日間実行できます。

単一ノード システムからのスケーリングの場合

Add-Serverを実行する前に、次のタスクを実行します。

  1. クォーラム監視者を構成する。 クォーラム監視者のデプロイを参照してください。

  2. 初期デプロイ中にストレージインテントを構成しなかった場合は、ストレージインテントを構成します。

    Example:

    Set-StorageNetworkIntent -Name "StorageNet" -StorageIntentAdapters "Ethernet1, Ethernet2" -Switchless $false -VLANID "877, 888"

ノードの追加操作を実行する

システムに既に存在するノードで、次の手順に従います。

  1. システムのデプロイ時に指定したドメイン ユーザー資格情報 (AzureStackLCMUser または同等のユーザー) を使用してサインインします。

  2. 次のコマンドを実行して、新しいノードのローカル管理者資格情報を使用して受信ノードを追加します。

    $HostIpv4 = "<IPv4 for the new node>"
$Cred = Get-Credential
Add-Server -Name "<Name of the new node>" -HostIpv4 $HostIpv4 -LocalAdminCredential $Cred

  3. Add-Serverによって返された操作 ID を保存します。 この ID を使用して、操作の進行状況を監視します。

操作の進行状況を監視する (PowerShell)

  1. 次のコマンドレットを実行し、前の手順の操作 ID を指定します。

    $ID = "<Operation ID>"
Start-MonitoringActionplanInstanceToComplete -ActionPlanInstanceID $ID

  2. ノードの追加操作が完了したら、ストレージの再調整の進行状況を監視します。

    Get-VirtualDisk | Get-StorageJob

    ストレージの再調整が完了すると、このコマンドレットは出力を返しません。

  3. 必要に応じて、Azureポータルでノードがすぐに表示されるように同期を強制します。

    Sync-AzureStackHCI

復旧のシナリオ

Scenario 軽減策 再実行が必要
オーケストレーターを使用せずに、帯域外の新しいノードを追加しました。 追加したノードを削除し、オーケストレーターを使用してノードを追加します。 いいえ
オーケストレーターを含む新しいノードを追加し、操作に失敗しました。 エラーを調査し、 Add-Server -Rerunを使用して失敗した操作を再実行します。 はい
オーケストレーターを含む新しいノードが追加され、操作が部分的に成功しましたが、新しい OS のインストールから開始する必要があります。 オーケストレーターが新しいノードでナレッジ ストアを既に更新しているため、修復ノードのシナリオを使用します。 はい

PowerShell のノード追加操作のトラブルシューティング

注

リリース 2508 以降では、 Add-Server コマンドの実行後に検証が実行されます。 テストが失敗した場合、検証コントロールはエラーの解決に役立つ詳細を返します。

ノードの追加中にエラーが発生した場合は、ログ ファイルに出力をキャプチャします。

Get-ActionPlanInstance -ActionPlanInstanceID $ID | Out-File log.txt

失敗した操作を再実行するには:

Add-Server -Rerun

注

カスタム ストレージ IP を使用して Azure Local インスタンスをデプロイした場合は、ノードの追加後に、ストレージ ネットワーク アダプターに IP を手動で割り当てる必要があります。

問題解決

ノードの追加操作中に問題が発生し、Microsoft サポートからの支援が必要な場合は、「 Azure Local の診断ログを収集する (プレビュー)」 の手順に従って、診断ログを収集して Microsoft に送信できます。

クラスターに追加する新しいノードから診断ログを提供する必要がある場合があります。 新しいノードから Send-DiagnosticData コマンドレットを実行していることを確認します。

次のステップ

  • Last updated on