15. オブジェクト ストレージのブートストラップ

完了までの推定時間: 7 時間

操作可能なコンポーネントの所有者: OBJ

スキル プロファイル: デプロイ エンジニア

15.1. ネットワークの要件

SG1000 と SG6060 のケーブル接続図については、次の図を参照して、GRID、Admin、Client の各ネットワークを構成してください。

ストレージ ラックの構成

15.1.1. Admin Node SG1000

SG1000 には少なくとも 2 つの管理ノードが必要です。

各管理ノードには、次のそれぞれに 1 つずつ、合計 4 つの IP アドレスが必要です。

  • BMC ネットワーク。
  • 管理ネットワーク。
  • クライアント ネットワーク。
  • Grid Network。

次の 3 つのサブネットが必要です。

  • 管理ネットワーク。
  • BMC ネットワーク。

クライアント ネットワークとグリッド ネットワーク、および各サブネットのサブネット マスクは 30 ビット以下にする必要があります。

15.1.2. ストレージ ノード SG6060 および SG6000

モデル SG6060 と SG6000 には、少なくとも 3 つのストレージ ノードが必要です。

ストレージ ノードごとに、次のそれぞれに 1 つずつ、合計 5 つの IP アドレスが必要です。

  • BMC ネットワーク（管理）。
  • 管理者ネットワーク（mgmt）。
  • Grid Network。
  • ストレージ コントローラ ネットワーク（mgmt）。注: ストレージ コントローラ ネットワークには 2 つの IP アドレスが必要です。

次のそれぞれに 2 つのサブネットが必要です。

  • BMC ネットワーク。
  • 管理ネットワーク。
  • ストレージ コントローラ ネットワーク。
  • Grid Network。

次の表に、管理ノードとストレージ ノードの IP アドレスの数を示します。

必要な IP の数 管理ネットワーク クライアント ネットワーク グリッド ネットワーク
管理ノード 2 1 1
ストレージ ノード 4 0 1

次の 3 つのサブネットが必要です。

  • 管理ネットワーク。
  • クライアント ネットワーク。
  • Grid Network。

各サブネットのサブネット マスクは 30 ビット以下にする必要があります。

15.1.3. ネットワークの詳細

15.1.3.1. Distributed Cloud 管理プレーン ネットワーク:

Distributed Cloud Out-of-Band（OOB）管理ネットワークには、Object Storage Baseboard Management Controller（BMC）ネットワークと管理ネットワークが含まれています。ネットワークは mgmtsw に接続します。

次のそれぞれに OOB BMC IP アドレスが必要です。

  • SG1000
  • SG6000

次の各項目に OOB 管理 IP アドレスが必要です。

  • SG1000
  • SG6000
  • SG6060

15.1.3.2. Distributed Cloud データプレーン ネットワーク

データプレーン ネットワークは、外部オブジェクト StorageGRID（SG1000）クライアント LIF と NetApp のクライアント ネットワークで構成されています。

  • 各 SubnetClaim を特定する手順については、以下をご覧ください。

    • S3 API エンドポイント:
    1. cellconfig ファイルで external-objectstorage-client-lif-subnet を検索します。
    2. 割り当てられた CIDR/ゲートウェイ IP アドレスを指定する対応する SubnetClaim を特定します。

    • SG1000 グリッド ネットワーク アプライアンスのエンドポイント:

      1. cellconfig ファイルで objectstorage-admin-nodes-lif-subnet を検索します。
      2. 割り当てられた CIDR/ゲートウェイ IP アドレスを指定する対応する SubnetClaim を特定します。

  • SG6060 グリッド ネットワーク アプライアンスのエンドポイント:

    1. cellconfig ファイルで objectstorage-storage-nodes-lif-subnet を検索します。
    2. 割り当てられた CIDR/ゲートウェイ IP アドレスを指定する対応する SubnetClaim を特定します。

15.2. 準備

15.2.1. 情報を収集する

推定所要時間: 5 ～ 10 分

このセクションに進む前に、ネットワーク ブートストラップと構成で Distributed Cloud インスタンスが完了し、Operator が最も正確または最新の cellconfig ファイルにアクセスできるか、ブートストラップにアクセスできることを確認してください。

15.2.1.1. ストレージ ハードウェア デバイスの情報を収集する

Distributed Cloud インスタンスは、ラック内のハードウェア デバイスを識別するために、固定の命名規則に従います。具体的には、次のオブジェクト ストレージ デバイスです。

  • 管理ノード（SG1000）: <cell>-<rack>-objsadm[node-number]。たとえば、af-ae-objsadm01 は管理ノードを表します。
  • ストレージ コンピューティング コントローラ ノード（SG6000-CN）: <cell>-<rack>-objs[node-number]。例: af-ae-objs01。
  • ストレージ コントローラ シェルフ（E2860）: <cell>-<rack>-objs[node-number]-s1。例: af-ae-objs01-s1
  • ストレージ ノード コントローラ（SG6060）: <cell>-<rack>-objs[node-number]-s1-[controller number]。（af-ae-objs01-s1-01、af-ae-objs01-s1-02 など）。

15.2.1.2. 管理プレーンのネットワーク情報を収集する

ネットワークのブートストラップと構成の間に、Operator は管理プレーンのサブネットを作成する必要があります。オブジェクト ストレージ システムでは、ブートストラップ プロセス中に次の情報が必要です。

  1. 管理サブネット。
  2. 管理ゲートウェイの IP アドレス。
  3. 管理サブネットに予約されている 16 個の IP アドレス、各管理ノードに 2 個の IP アドレス、各ストレージ ノードに 4 個の IP アドレス。

SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet から管理ゲートウェイの IP アドレスを見つけます。<cell> と <rack> は、「ストレージ ハードウェア デバイスの情報を収集する」の手順で特定されたものと同じです。例: af-ae-mgmtsw01-objs-os-subnet

kubectl get subnetclaim -n root <cell>-<rack>-mgmtsw01-objs-os-subnet -o jsonpath='{.status.ipv4SubnetStatus.reservedIpRanges[?(.type == "GatewayReservation")].ipRange.startIPAddress}'

コマンドの値を MANAGEMENT_SWITCH_GATEWAY に格納します。

15.2.1.3. データプレーンのネットワーク情報を収集する

続行する前に、ネットワークのブートストラップと構成時にオブジェクト ストレージ システム用に 3 つのサブネットをプロビジョニングしていることを確認してください。

次のサブネットが存在するかどうかを確認します。

  • objectstorage-admin-nodes-lif-subnet
  • objectstorage-storage-nodes-lif-subnet
  • external-objectstorage-client-lif-subnet

SubnetClaim の名前を指定して、次のコマンドを実行します。

kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME

次の出力が表示されます。

NAME                                    CIDRCLAIM                             OVERLAY-NETWORK   IPV4-CIDR     IPV6-CIDR   VLAN   READY   VLANREADY
objectstorage-admin-nodes-lif-subnet   objectstorage-admin-nodes-lif-cidr   ObjectStorage     10.7.7.0/24                  7      True    True

次のフィールドが存在するかどうかを確認します。

  1. VLAN
  2. READY: True
  3. VLANREADY: True

15.2.1.4. 依存関係情報を収集する

オブジェクト ストレージ システムは、Distributed Cloud の次のコアサービスとインフラストラクチャに依存しています。

  • NTP
  • ハードウェア セキュリティ モジュール（HSM）
  • DNS

15.2.1.5. TO-BE-FILLED フィールドを更新する

obj-cellobj.yaml ファイルで TO-BE-FILLED 値を確認し、更新します。

次のコマンドを実行して、値が YAML ファイルに存在しないことを確認します。

cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"

15.2.2. ローカル接続による構成管理ネットワーク

推定所要時間: 30 ～ 45 分

このサブセクションでは、各 StorageGRID アプライアンス ノードの管理ネットワークを設定します。管理ネットワークが構成されると、ブートストラッパーから管理ネットワークの IP を使用して StorageGRID ノードにアクセスします。

すべての ObjectStorage デバイスに対して、次の手順を行います。

  • af-ae-objsadm01
  • af-ae-objsadm02
  • af-ae-objs01
  • af-ae-objs02
  • af-ae-objs03

StorageGRID デバイスをブートストラップするには、2 つの管理ノードと 3 つのストレージ ノードを含む各デバイスに、管理ネットワークのポート 6 でクラッシュ カートを使用して接続し、https://169.254.0.1:8443 にアクセスして管理ネットワークで管理 IP アドレスを設定します。

  1. イーサネット ケーブルを使用して、クラッシュ カートをサービス アプライアンスの右端の RJ-45 ポートに直接接続します。次の図は、管理ノードとストレージ ノードのポート 6 の例を示しています。

    管理者ノードのポート 6

    ストレージ ノードのポート 6

  2. クラッシュ カートでウェブブラウザを開きます。

  3. 各マシンの https://169.254.0.1:8443 に移動します。

  4. StorageGRID アプライアンス インストーラのメニューバーで、[Configure Networking] > [Link Configuration] をクリックします。管理ネットワークが有効になっているかどうかを確認します。

    管理ネットワークを有効にする

  5. 管理ネットワークの IP アドレスを構成するには、[ネットワークを構成 > IP 構成] を選択します。

  6. [管理者ネットワーク] セクションまでスクロールし、[IP 割り当て] で [静的] を選択して、ノードに対応する管理 IP アドレス managementIP を入力します。各ノードの管理 IP は、obj-cellobj.yaml ファイルで確認できます。次に例を示します。

    • ObjectStorageAdminNode（SG1000）:

      apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
kind: ObjectStorageAdminNode
metadata:
  creationTimestamp: null
  name: af-ae-objsadm01
spec:
  network:
    bmcIP: 10.251.188.11/24
    clientIP: 10.251.113.2/28
    dataIP: 10.1.0.66/26
    managementIP: 10.251.188.10/24
  siteName: objectstorage-site

    • ObjectStorageStorageNode（SG6000）:

      apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
kind: ObjectStorageStorageNode
metadata:
  creationTimestamp: null
  name: af-ae-objs01
spec:
  network:
    bmcIP: 10.251.243.34/24
    controllerAManagementIP: 10.251.243.35/24
    controllerBManagementIP: 10.251.243.36/24
    dataIP: 10.1.0.132/26
    managementIP: 10.251.243.33/24
  siteName: objectstorage-site

    ゲートウェイを MANAGEMENT_SWITCH_GATEWAY に設定します。

    次の画像は、obj-cellobj.yaml ファイルで割り当てられた管理 IP アドレスを使用して af-ae-objs01 を構成する例を示しています。

    管理ネットワークを構成する

  7. [保存] をクリックし、IP アドレスが更新されたかどうかを確認します。

  8. ブートストラップから管理 IP アドレスに ping を実行して、到達可能であることを確認します。

    1. ブートストラップから管理 IP アドレスに ping を実行し、到達可能であることを確認します。
    2. すべてのノードに管理ネットワーク上の IP アドレスが割り当てられたら、管理 IP アドレスを使用して StorageGRID ノードのインストール GUI にアクセスします。

トラブルシューティング:

ノードが ping できない場合:

  1. 上記の手順 3 で StorageGRID ノードのインストール UI にアクセスし、ダイアログ バナーにエラーが表示されていないか確認します。エラーの解決を試みます。必要に応じてエンジニアに連絡します。
  2. [Configure Networking] > [IP Configuration] に移動します。正しい [Admin Network] セクションに正しい静的 IP とゲートウェイが構成されていることを確認します。確認後、StorageGRID ノードが管理ネットワーク構成を完全に登録しないことがあります。
  3. ステップ 5 ～ 8 をもう一度実行し、管理ノードのネットワークを確認します。

オブジェクト ストレージ システムのインストールを続行するには、各ノードの StorageGRID ノード インストール GUI へのアクセスが必要です。

15.2.3. StorageGRID をアップグレードする

推定所要時間: 1 ～ 1.5 時間

StorageGRID をアップグレードする前に、StorageGRID ソフトウェアのバージョンを確認します。[Advanced > Upload StorageGRID Software] に移動します。現在の StorageGRID バージョンが表示されます。

バンドルされている StorageGRID のインストール バージョンを確認します。

gdcloud artifacts tree oci | grep object-storage/os

出力例は次のようになります。

│   │   │       └── gpc-system-object-storage/os:11.8.0
    ├── gpc-system-object-storage/os:sha256-d4cb75f91f43a92cb580db98faae12e87ec49d2b27c7db8a056d6411ac3b6044.sig

この例では、バージョンはアーティファクトに 11.8.0 としてタグ付けされています。

バージョンの値を SG_INSTALL_VERSION に保存します。

バンドルされている StorageGRID ファームウェアのバージョンを確認します。

gdcloud artifacts tree oci | grep object-storage/firmware

出力例は次のようになります。

│   │   │       ├── gpc-system-object-storage/firmware:3.8.1
    ├── gpc-system-object-storage/firmware:sha256-20a664504c342b5f14188114fad7a1e7d40abc042690bb0f776aa67cecff52e1.sig

この例では、バージョンはアーティファクトに 3.8.1 としてタグ付けされています。

バージョンの値を SG_FIRMWARE_VERSION に保存します。

ノードのバージョンが SG_INSTALL_VERSION でない場合は、次の手順に進んで StorageGRID のインストール バージョンをアップグレードまたはダウングレードします。現在のバージョンが SG_INSTALL_VERSION の場合は、SANtricity のアップグレードのセクションに進みます。

StorageGRID のバージョンを確認する

15.2.3.1. ファームウェアをアップグレードする

すべての StorageGRID ノードで次の手順を行います。

  • af-ae-objsadm01
  • af-ae-objsadm02
  • af-ae-objs01
  • af-ae-objs02
  • af-ae-objs03

  1. バンドルからファームウェア イメージを取得します。

    gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/firmware:SG_FIRMWARE_VERSION

tar -xvzf storage/gpc-system-object-storage/firmware.tar.gz

    このファイルは storagegrid_firmware_install/ で入手できます。

  2. StorageGRID ノードで StorageGRID Appliance Installer に移動します。[Advanced]（詳細設定） > [Upgrade Firmware]（ファームウェアをアップグレード）を選択します。選択したファームウェア バージョンのファームウェア イメージ storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2 とチェックサム storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1 をアップロードします。アップロード後、StorageGRID はファイルの検証を自動的に開始します。通常、検証には 5 ～ 10 分ほどかかります。

    ファームウェア イメージをアップロードする

  3. 2 つの緑色のチェックマークが表示されたら、[Upgrade Inactive Partition] をクリックします。

    非アクティブなパーティションをアップグレードする

    Successfully updated the firmware on the inactive partition メッセージを受信したら、[Current Firmware] セクションで、非アクティブ パーティションが正しいバージョンであることを確認します。

    [Reboot] と [Swap Partitions] を 2 回クリックします。

  4. ノードの再起動が完了したら、手順 1 と 2 を繰り返して、他のパーティションのファームウェアをアップグレードします。アクティブ パーティションは選択されたバージョンで、非アクティブ パーティションには古いバージョンが含まれています。

    他の非アクティブなパーティションをアップグレードする

15.2.3.2. StorageGRID ソフトウェアをアップグレードする

すべてのノードのファームウェアのアップグレードが正しいバージョンに完了したら、2 つの管理ノードでソフトウェアを選択したバージョンにアップグレードします。ストレージ ノードは管理ノードのソフトウェアを模倣してプルするため、アップグレードする必要はありません。

SG1000 の管理ノードで次の手順を行います。

  • af-ae-objsadm01
  • af-ae-objsadm02

  1. バンドルからインストール イメージを取得します。

    gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/os:SG_INSTALL_VERSION

tar -xvzf storage/gpc-system-object-storage/os.tar.gz

    ファイルは storagegrid_os_install/ で入手できます。

  2. [Advanced] -> [Upload StorageGRID Software] に移動します。[削除] をクリックして現在のソフトウェアを削除し、次のように新しいソフトウェア パッケージ storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb と対応するチェックサム storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5 をアップロードします。

    StorageGRID パッケージをアップロードする

  3. ソフトウェアのアップロードが完了したら、ノードのソフトウェアが選択したバージョンに更新されていることを確認します。

    StorageGRID のバージョンを確認する

15.2.4. SANtricity をアップグレードする

推定所要時間: 1 ～ 1.5 時間

SANtricity をアップグレードする前に、SANtricity ソフトウェアのバージョンを確認します。SANtricity UI に移動し、[Support > UPGRADE CENTER > Begin Upgrade] をクリックします。現在の SANtricity バージョンが表示されます。

バンドルされた SANtricity のインストール バージョンを確認します。

gdcloud artifacts tree oci | grep object-storage/santricity

出力例は次のようになります。

│   │   │       └── gpc-system-object-storage/santricity:11.70.5R1
    ├── gpc-system-object-storage/santricity:sha256-b145edeb8b24cac420862e7ef09224009aa51da6c6508f5a113753cc07db6ec5.sig

この例では、バージョンはアーティファクトに 11.70.5R1 としてタグ付けされています。

バージョンの値を SANTRICITY_OS_VERSION に保存します。

SANtricity のバージョンが SANTRICITY_OS_VERSION より前の場合は、次の手順に進んで SANtricity OS のバージョンをアップグレードします。それ以外の場合は、インストールに進みます。

SANtricity のバージョンを確認する

15.2.4.1. SANtricity OS をアップグレードする

SANtricity UI で、各ストレージ ノードに対して次の手順を行います。

  1. バンドルからインストール イメージを取得します。

    gdcloud artifacts extract oci santricity \
    --image-name=gpc-system-object-storage/santricity:SANTRICITY_OS_VERSION

tar -xvzf santricity/gpc-system-object-storage/santricity.tar.gz

    アップグレード ファイルは santricity/SANTRICITY_OS_VERSION/ で入手できます。

  2. [Support] > [UPGRADE CENTER] に移動します。[SANtricity OS Software upgrade] で [Begin Upgrade] をクリックします。[参照] をクリックして、SANtricity OS ソフトウェア ファイルを選択します。次のように、新しいソフトウェア パッケージ RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp をアップロードします。

    SANtricity パッケージをアップロードする

  3. [開始] をクリックし、操作を実行することを確認します。

  4. アップグレードが完了したら、バージョンが更新されていることを確認します。

    SANtricity のバージョンを確認する

15.3. インストール

15.3.1. Secret を作成する

推定所要時間: 15 ～ 30 分

シークレットの作成に使用する値を取得するには、cellcfg ディレクトリを使用します。

  1. objectstoragestoragenodes の名前を取得します。

    $ CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
$ sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' CELLCFG_PATH/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'

    出力例:

    # CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
# sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' ./cellcfg/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
ah-ac-objs01
ah-ac-objs02
ah-ac-objs03

  2. ストレージ ノードの BMC IP アドレスを取得します。

    echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /bmcIP/p" $CELL_ID-obj-cellobj.yaml | grep bmcIP | awk '{print $2}' | cut -d'/' -f1):8443

  3. 前のコマンドの出力にあるリンクから SANtricity システム マネージャーにログインします。以前にパスワードを設定していない場合は、パスワードを作成してログインします。

    SANtricity システム マネージャーにログインする

    1. SANtricity パスワードを忘れた場合は、StorageGRID E2860 シリアル コンソールからリセットします。E2860 ディスク アレイのシリアルポートに接続する場合、ターミナルの設定は 115200 8N1 です。

  4. 両方のコントローラの SANtricity システム マネージャーで NTP サーバーのアドレスを構成します。

    NTP サーバーのアドレスを構成する

    1. NTP サーバーのアドレスを取得する

       kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP
 ```

    2. SANtricity システム マネージャーで [Hardware] を選択します。

    3. グラフィックにドライブが表示されている場合は、[Show back of shelf] をクリックします。グラフィックが変更され、ドライブではなくコントローラが表示されます。

    4. 設定するコントローラをクリックします。コントローラのコンテキスト メニューが表示されます。

    5. [NTP サーバーを構成] を選択します。[Configure Network Time Protocol (NTP) Server] ダイアログが開きます。

    6. [コントローラ（A または B）で NTP を有効にする] を選択します。ダイアログに追加の選択肢が表示されます。

    7. [NTP サーバー アドレスを手動で指定する] を選択します。前のコマンドで取得した IP のいずれかを使用して、プライマリ NTP サーバー アドレスを入力します。

    8. [保存] をクリックします。

  5. cell.yaml ファイルで、各ストレージ ノードの SANtricity 認証情報を含むシークレットを更新します。シークレットが存在しない場合は、次のテンプレートに沿ってシークレットを追加します。

    apiVersion: v1
kind: Secret
metadata:
  creationTimestamp: null
  name: <STORAGE_NODE_NAME>-santricity
  namespace: gpc-system
stringData:
  password: 'PASSWORD'
  username: 'admin'
type: Opaque

  6. 前の手順でリストした各ストレージ ノードのシークレットを作成します。

    kubectl create secret generic \
   --namespace=gpc-system STORAGE_NODE_NAME-santricity \
   --from-literal=username=admin \
   --from-literal=password=PASSWORD

検証:

  1. 前の手順でリストした各ストレージ ノードで、次のコマンドを実行します。前の手順で設定した Santricity ユーザー名が出力されます。管理者を検証します。

    kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo

  2. 前の手順でリストした各ストレージ ノードで、次のコマンドを実行します。Santricity パスワードが出力されます。

    kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo

  3. 次のコマンドを実行して、Santricity Management UI の URL を取得します。ユーザー名とパスワードを使用して Santricity にログインします。

    echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /controllerAManagementIP/p" $CELL_ID-obj-cellobj.yaml | grep controllerAManagementIP | awk '{print $2}' | cut -d'/' -f1):8443

トラブルシューティング:

検証ステップ 1 または 2 の実行時にシークレットが見つからない場合は、kubectl create secret ステップをもう一度実行します。

Santricity Management UI にログインできない場合:

  1. StorageGRID E2860 シリアル コンソールから管理者認証情報をリセットします。
  2. 最後の手順を除く、前の手順をすべて実行します。

  3. 各ノードの既存の Santricity シークレットを削除します。

    kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity

  4. 最後の手順を実行して、Santricity シークレットを再作成します。

15.3.2. オブジェクト ストレージをブートストラップする

オブジェクト ストレージのブートストラップ プロセスは、最初のゾーンと参加ゾーンで異なります。ご自身の状況に応じて、該当するセクションを参照してください。

重要: 続行する前に、アンカー ゾーンのグローバル API ブートストラップが完了していることを確認してください。

15.3.2.1. 最初のゾーンでオブジェクト ストレージをブートストラップする

次のコマンドを実行して、オブジェクト ストレージをブートストラップします。

gdcloud system objectstorage install --config /CELLCFG_PATH  --first-zone --enable-objectstorage-hsm -v 5

15.3.2.2. 参加ゾーンでオブジェクト ストレージをブートストラップする

トラブルシューティング:

  1. Google Cloud CLI コマンドがタイムアウトするか、エラーを返した場合は、返された問題を解決します。
  2. エラーの詳細については、ログイン gpc-system/obj-infra-cluster-cm-backend-controller Pod を確認してください。

15.3.2.3. 参加ゾーンでオブジェクト ストレージをブートストラップする

推定所要時間: 30 ～ 60 分

参加ゾーンで Object Storage をブートストラップするには、アンカー ゾーンと参加ゾーンの Object Storage Reconciler 間の調整が必要です。ブートストラップ時に 2 つのゾーン間の Reconciler の安全な制御された通信チャネルが存在しないため、IO は 2 つのゾーン間の Object Storage Reconciler の安全な通信を手動で容易にする必要があります。

  1. アンカー ゾーンのルート管理者ゾーン クラスタとグローバル クラスタで、クラスタ管理者の事前定義ロールを自分に付与します。詳細については、IAM ランブックをご覧ください。

または、アンカー ゾーンで次の 2 つのロール バインディングを適用します。

グローバル API で:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: mz-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: mz-bootstrap-global-backend-controllers-role
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: fop-cluster-admin@example.com

ルート管理クラスタの場合:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: cluster-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: cluster-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: fop-cluster-admin@example.com

  1. アンカー ゾーンでコマンドを実行して DNS サーバーの IP を取得し、後で使用できるように書き留めます。 sh kubectl --kubeconfig /ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH get service gpc-coredns-external-udp -n dns-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

  2. アンカー ゾーンにリンクするように参加ゾーンの DNS スタブ リゾルバを設定します。

    1. systemd-resolved sh systemctl disable systemd-resolved.service --now を無効にして停止する

    2. resolv.conf ファイルが存在する場合は削除 sh rm -f /etc/resolv.conf

    3. アンカー ゾーンの DNS サーバー IP を参加ゾーンの resolv.conf に書き込みます。 sh vim /etc/resolv.conf /etc/resolv.conf ファイルの内容の例: sh nameserver 10.200.40.0

  3. 参加ゾーンに TokenRequest YAML ファイルを作成します。

    gdcloud system multi-zone create-token-request --zone JOINING_ZONE_NAME --client-type obj-join --cluster kind --namespace gpc-system --output-file TOKEN_REQUEST_YAML_PATH

    JOINING_ZONE_NAME は、セクションの末尾のメモで説明されているように、顧客受付アンケートのゾーン名に置き換えます。

  4. TokenRequest YAML ファイルをアンカーゾーンに転送します。

    scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH

  5. TokenRequest YAML をアンカー ゾーンの root-admin グローバル クラスタに適用します。

    kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH

  6. アンカー ゾーンにトークン YAML ファイルを作成します。

    gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH

  7. トークン YAML ファイルを参加ゾーンに転送します。

    scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH

  8. 参加ゾーンの KIND クラスタにトークン YAML を適用します。

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH

  9. アンカー ゾーンに ObjectStorageBootstrap YAML ファイルを作成します。

    gdcloud system objectstorage create-bootstrap --output-file  OBJECT_STORAGE_BOOTSTRAP_YAML_PATH

  10. ObjectStorageBootstrap YAML ファイルを結合ゾーンに転送します。

    scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH

  11. ObjectStorageBootstrap YAML ファイルを参加ゾーンの KIND クラスタに適用します。

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH

  12. 参加ゾーンでオブジェクト ストレージをブートストラップします。

    gdcloud system objectstorage install --config /CELLCFG_PATH  --add-zone --enable-objectstorage-hsm -v 5