このページは Cloud Translation API によって翻訳されました。

動的拡張を実行する

このページでは、ストレージリソースとコンピューティングリソースを追加してシステムを動的に拡張するプロセスについて説明します。次のタイプの拡張機能の手順について説明します。

水平サーバーラックの拡張: ゾーンに新しいラックを追加します。このラックには、コンピューティングノード、コンソール、トップオブラック（ToR）スイッチ、管理（MGMT）スイッチが含まれています。
垂直サーバー拡張: 空の拡張スロットがあるラックにサーバー拡張ブロックを追加します。
垂直ファイルとブロックストレージの拡張: 既存のストレージクラスタに空の拡張スロットがあるラックにストレージノードを追加します。同じストレージスイッチに接続されているストレージノードは、同じクラスタに属します。

さまざまなタイプの動的拡張の詳細については、動的拡張の概要をご覧ください。

始める前に

ゾーンを変更する前に、次のことを行う必要があります。

ハードウェアの検査を実施し、OEM との承認手続きを行います。ラックの検査の手順に沿って対応します。
KUBECONFIG の生成に沿って、コントロールプレーンノードの管理クラスタの KUBECONFIG を生成します。このガイドのすべての kubectl 手順で、生成された KUBECONFIG 構成ファイルを使用します。
ルートクラスタの現在の Google Distributed Cloud（GDC）エアギャップバージョンが 1.13.1 以降であることを確認します。
```
kubectl --kubeconfig $KUBECONFIG get org root -n gpc-system
```
GDC tar ファイルをダウンロードします。詳しくは、ファイルをダウンロードするをご覧ください。
新しいアプライアンスのファームウェアを準備します。
1. GDC ハードウェアのパケット交換デバイス。詳細については、スイッチをご覧ください。
2. ONTAP の手動アップグレードの手順に沿って、ONTAP ファイルストレージとブロックストレージを更新します。
gdcloud system doctor を使用して GDCH システムが正常であることを確認します。gdcloud system doctor コマンドを使用できない場合は、ネットワークインストールの確認の代替方法を使用します。

サーバーラックの水平方向の拡張を行う

コンピューティングノード、コンソール、ToR スイッチ、管理スイッチで構成される新しいラックを、水平サーバーラック拡張によってゾーンに追加します。このセクションで説明する手順は、単一のラックを対象としています。複数のラックがある場合は、各ラックにこの手順を適用します。

リセットオペレーションを実施する

次の機器は安全にリセットする必要があります。

セキュアリセットシリアルコンソールサーバーを実行します。デプロイごとにシリアルコンソールが異なる場合があるため、これらの手順については Google にお問い合わせください。
Raritan 配電ユニット（PDU）で安全なリセットを実行します。
1. USB-b ケーブルをシステムコントローラから Raritan PDU に接続します。
2. ローカルシリアルコンソールで、コマンド reset factorydefaults を使用して PDU を出荷時のデフォルト設定にリセットします。
3. PDU が admin/legrand に設定されました。
安全な消去の手順に沿って、安全なリセットを実行し、ファームウェアを更新して、ToR スイッチと MGMT スイッチを PowerOn Auto Provisioning（POAP）にリセットします。
各サーバーに接続し、安全な消去を手動で実行します。

アーティファクトを準備する

必要な構成ファイルとカスタムリソースを適用する手順は次のとおりです。

gdcloud system assets add コマンドを使用して、ZonalExpansion YAML ファイル、ハードウェア CustomResources、ハードウェア SubcomponentOverride リソースを生成します。
```
gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af
```
使用する各ファイルに対して FILE_PATH を置き換えます。各ファイルが異なる場所にある場合、このパスは異なる可能性があります。

ZonalExpansion カスタムリソースは、追加されたすべてのオブジェクトを追跡し、すべてのオブジェクトのステータスを報告します。

ZonalExpansion YAML ファイルを確認する際は、次のガイダンスを使用してください。
- name フィールドは、az-ae-expansion などの説明的なものにする必要があります。
- assets フィールドには、新しい拡張ラック内のすべての新しいアプライアンスを含める必要があります。
ZonalExpansion リソースの例を次に示します。
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01
```
Infrastructure as Code（IAC）ツールを使用して、ZonalExpansion カスタムリソースを適用します。詳細については、Infrastructure as Code の設定をご覧ください。または、IAM-R0004 ランブックに沿って、kubectl を使用してこれを行います。
ZonalExpansion リソースと NonCompliantDeviceSet リソースが作成されたことを確認します。
1. ZonalExpansion リソースのステータスを確認します。
```
kubectl --kubeconfig $KUBECONFIG get -A zonalexpansion -o yaml
```
  この段階で、プリフライトチェックは理由 ReasonAssetsNotExisted で失敗します。
2. NonCompliantDeviceSet リソースは、noncompliantassets- という接頭辞が付いた名前で存在している必要があります。
3. アセットリストは、ZonalExpansion カスタムリソースの assets フィールドと同じである必要があります。
OLT-R0003 の手順に沿ってアセットを更新します。
新しいラックの ToR スイッチと MGMT スイッチを、既存のラックのアグリゲーションスイッチに接続します。
スイッチをベースラックに物理的に接続します。

サーバーのブートストラップを完了する

このフェーズはほとんどが自動化されていますが、いくつかの手順が必要です。ブートストラップの進行状況をモニタリングし、失敗ケースを処理する必要があります。

コントローラは、条件 PreflightCheck=True が満たされると、ブートストラッププロシージャを自動的に開始します。
条件 NetworkBootstrapSucceed=True が ZonalExpansion カスタムリソースに公開されていることを確認します。この条件は ZonalExpansion.Status.PNETBootstrapStatus にあります。
スイッチが NonCompliantDeviceSet リストから削除されたことを確認します。
```
kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A -o yaml
```
EXPANSION_NAME は、ゾーン拡張カスタムリソースの名前に置き換えます。

返された YAML ファイルの Spec.Assets フィールドにスイッチが含まれていないことを確認します。この削除により、GDC はネットワーク ACL を更新して、他のアプライアンスのブートストラップ手順を許可できます。更新された 2 つのネットワーク ACL は、quarantine-mgmt-switch-acl と quarantine-data-switch-acl です。

サーバーのすべてのベースボード管理コントローラ（BMC）IP アドレスを一覧表示し、iLO IP アドレスが新しいベアメタルマシンに割り当てられ、ブートストラップを開始できることを確認します。

kubectl --kubeconfig $KUBECONFIG get servers -n gpc-system -o=custom-columns=SERVER:.metadata.name,BMC_IP:.spec.bmc.ip

出力例:

 SERVER       BMC_IP
 yz-aa-bm01   10.128.136.2
 yz-aa-bm02   10.128.136.3
 yz-aa-bm03   10.128.136.4
 yz-ab-bm01   10.128.136.66
 yz-ab-bm02   10.128.136.67
 yz-ab-bm03   10.128.136.68
 yz-ac-bm01   10.128.136.130
 yz-ac-bm02   10.128.136.131
 yz-ac-bm03   10.128.136.132
 yz-ac-bm04   10.128.136.133
 yz-ac-bm05   10.128.136.134
 yz-ac-bm06   10.128.136.135
 yz-ac-bm07   10.128.136.136
 yz-ac-bm08   10.128.136.137
 yz-ac-bm09   10.128.136.138
 yz-ac-bm10   10.128.136.139
 yz-ac-bm11   10.128.136.140
 yz-ac-bm12   10.128.136.141
 yz-ac-bm13   10.128.136.142
 yz-ac-bm14   10.128.136.143
 yz-ac-bm15   10.128.136.144
 yz-ac-bm16   10.128.136.145
 yz-ac-bm17   10.128.136.146
 yz-ac-bm18   10.128.136.147

GDC は、サーバーを並行してブートストラップし、セキュア消去、検証、BIOS 設定の更新などのブートストラップ手順を実行します。

ServerBootstrapSucceeded=True 条件が ZonalExpansion カスタムリソースに公開されていることを確認します。この条件は ZonalExpansion.Status.SERVBootstrapStatus にあります。
- ブートストラップが成功すると、サーバーのベアメタルホストのステータスが Available または Provisioned の状態になります。
- CLI の詳細レベルが 4 の場合、"Not all servers in the ZonalExpansion are bootstrapped" のようなログが表示され、まだ準備ができていないサーバーのリストが表示されます。

サーバーが NonCompliantDeviceSet リストから削除されたことを確認します。

kubectl --kubeconfig $KUBECONFIG get noncompliantdevicesets -n gpc-system "noncompliantassets-EXPANSION_NAME" -o yaml

条件 ExpansionSucceeded=True が ZonalExpansion カスタムリソースに公開されていることを確認します。この条件は ZonalExpansion.Status.Conditions にあります。

NonCompliantDeviceSet リストが削除されたことを確認します。

kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A

予想される出力:

`Error from server (NotFound): noncompliantdevicesets.system.private.gdc.goog "noncompliantassets-EXPANSION_NAME" not found`

垂直方向のサーバー拡張を行う

垂直サーバー拡張により、空の拡張スロットがあるラックにサーバー拡張ブロックを追加します。この拡張の手順の多くは、コンピューティングの水平方向の拡張と似ています。垂直サーバーラックの拡張を行う手順は次のとおりです。

6 ノードの容量を占有する標準サーバーブロック、または 3 ノードの容量を消費する GPU サーバーブロックを物理的にインストールします。ラックごとに複数のブロックを追加できます。警告: ケーブルを mgmtsw スイッチまたは aggsw スイッチに接続しないでください。詳細については、スイッチをご覧ください。
電源以外のケーブル接続は行わないでください。この手順により、サーバーの電源投入プロセスで、サーバーが到着時にオフラインになっていないことを確認できます。
gdcloud system assets add コマンドを使用して、ZonalExpansion YAML ファイルとハードウェア SubcomponentOverride リソースを生成します。
```
gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af
```
使用する各ファイルに対して FILE_PATH を置き換えます。各ファイルが異なる場所にある場合、このパスは異なる可能性があります。

ZonalExpansion YAML ファイルを確認する際は、次のガイダンスを使用してください。
- name フィールドは、az-ae-expansion などの説明的なものにする必要があります。
- assets フィールドには、新しい拡張ラック内のすべての新しいアプライアンスを含める必要があります。
ZonalExpansion リソースの例を次に示します。
```
apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01
```
先ほど作成した ZonalExpansion カスタムリソースをクラスタに適用します。
ZonalExpansion リソースと NonCompliantDeviceSet リソースが作成されたことを確認します。
1. ZonalExpansion リソースのステータスを確認します。この段階で、プリフライトチェックは理由 ReasonAssetsNotExisted で失敗します。
2. NonCompliantDeviceSet リソースは、noncompliantassets- という接頭辞が付いた名前で存在している必要があります。
3. アセットリストは、ZonalExpansion カスタムリソースの assets フィールドと同じである必要があります。
OLT-R0003 の手順に沿ってアセットを更新します。
OLT-R0001 ランブックに沿って、隔離スイッチ ACL が実行されていることを確認します。
サーバーのケーブル接続がまだ完了していない場合は、接続します。Hewlett Packard Enterprise（HPE）から提供されたケーブル接続ファイルに従います。
サーバーのブートストラッププロセスが正常に開始され、完了することを確認します。詳細については、サーバーのブートストラップを完了するをご覧ください。

ファイルとブロックストレージの垂直方向の拡張を行う

これらの手順には、垂直方向のストレージノード拡張（単一ラック）に必要な手順が含まれています。ストレージノードの拡張は、既存のラックのストレージ機能を拡張するために新しい ONTAP ストレージノードが追加されたときに実行されます。ここでは、新しいストレージデバイスのケーブル接続手順は説明しません。既存のクラスタで新しいストレージノードを消去、アップグレード、追加する手順のみを説明します。

ストレージノードの拡張を設定する

ストレージノードの拡張用にクラスタを準備する手順は次のとおりです。

KUBECONFIG の生成に沿って、コントロールプレーンノードの管理クラスタの KUBECONFIG を生成します。このガイドのすべての kubectl ステップで、生成された KUBECONFIG 構成ファイルを使用します。

ノード拡張の初期設定を行う間、ストレージ Reconciler を無効にするには、SubcomponentOverride リソースを適用します。

kubectl --kubeconfig $KUBECONFIG apply -f - <<EOF
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
    name: file-storage-sub-override
    namespace: root
spec:
    subComponentRef: "file-storage"
    backend:
        operableParameters:
            controller:
                enableReconcilers: ""
                disableReconcilers: "*"
EOF

オーバーライドが機能し、file-storage リコンサイラが無効になっていることを確認します。
```
kubectl --kubeconfig $KUBECONFIG describe deployment file-storage -n
file-system | grep reconcilers
```
次の画面が表示されます。
```
--enable-reconcilers=
--disable-reconcilers=*
```
この状態が表示されない場合は、SubcomponentOverride リソースが適用されるまで数分待ってから、このチェックをもう一度実行します。数分経っても SubcomponentOverride が適用されない場合は、GDC エンジニアリングサポートにお問い合わせください。

gdcloud system assets add コマンドを使用して、ZonalExpansion YAML ファイルとハードウェア SubcomponentOverride リソースを生成します。

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af
```
Replace FILE_PATH for each of the files used. Note, this path might be different if each file is in a different location.

Use the following guidance when reviewing the `ZonalExpansion` YAML file:

The `name` field must be descriptive, such as aj-ad-expansion.
The `assets` field must include all new appliances in the new expansion rack.
Here is an example of a `ZonalExpansion` resource:

```sh
apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
name: file
namespace: gpc-system
spec:
assets:
- kind: StorageNode
    name: aj-ad-stge03-01
- kind: StorageNode
    name: aj-ad-stge03-02
```

先ほど作成した ZonalExpansion カスタムリソースをクラスタに適用します。
ZonalExpansion リソースと NonCompliantDeviceSet リソースが作成されたことを確認します。
1. ZonalExpansion リソースのステータスを確認します。この段階で、プリフライトチェックは理由 ReasonAssetsNotExisted で失敗します。
2. NonCompliantDeviceSet リソースは、noncompliantassets- という接頭辞が付いた名前で存在している必要があります。
3. アセットリストは、ZonalExpansion カスタムリソースのアセットフィールドと同じにする必要があります。
IaC ツールを使用して、次のハードウェアアセット SubcomponentOverride リソースをルート管理者クラスタに適用します。
- file/file-storage.yaml
- inv/inv-core.yaml
注: 生成された SubcomponentOverride には、クラスタにすでに適用されているオーバーライドは含まれません。現在の SubcomponentOverride をキャプチャし、対応する生成された SubcomponentOverride に追加して、オーバーライドが失われないようにします。

新しいノードがクラスタに追加されたことを確認します。

kubectl --kubeconfig $KUBECONFIG get storagenodes -n gpc-system

新しいノードカスタムリソースが追加され、より新しい経過時間が表示されます。

  NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
  aj-ad-stge01-01   172.22.243.129   169.254.0.1      AFF-A250   37d
  aj-ad-stge01-02   172.22.243.130   169.254.0.3      AFF-A250   37d
  aj-ad-stge03-01   172.22.243.133   169.254.0.9      AFF-A400   20d
  aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d

describe コマンドを使用して、両方のノードに関する情報を取得します。これらのノードには、後の手順で必要な情報が含まれています。
```
kubectl --kubeconfig $KUBECONFIG describe storagenode NODE_NAME -n gpc-system
```
NODE_NAME は、作成した各ノードの名前に置き換えます。

出力例:
```
NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d
```

ストレージノードの拡張プロセスを完了する

ストレージノードの拡張プロセスを完了する手順は次のとおりです。

新しいストレージノードを手動でアップグレードします。各ノードで、システムコントローラからファイルを配信する ONTAP の手動アップグレードの手順に沿って操作します。
新しいストレージノードの安全な消去を実行します。新しい ONTAP ノードの場合は、ONTAP のリセットの手順に沿ってノードをリセットします。
新しいストレージノードを初期化します。前の手順で説明した、新しく追加された StorageNode カスタムリソースの情報を使用します。ノードごとに、ONTAP アプライアンスを初期化するの手順を行います。

注: cellcfg の手順は実行しないでください。代わりに、前のステップでキャプチャした値を使用します。
ONTAP の設定に沿って、新しいノードから現在のクラスタにケーブル接続します。
既存のクラスタに新しいノードを追加するの手順に沿って、新しいノードをクラスタに追加します。

動的拡張のトラブルシューティング

サービスマニュアルの次のランブックを使用して、動的拡張の問題をトラブルシューティングします。

OLT-R0001
OLT-R0002
OLT-R0003