組織リソースを管理する

Google Distributed Cloud（GDC）エアギャップのインフラストラクチャ オペレーター（IO）として、システム ヘルスを検証し、ユーザーとネットワークを構成し、コンピューティング、ストレージ、ネットワーキングなどの基盤となるハードウェア システムのライフサイクルを管理します。

始める前に

このドキュメントの内容を実施するには、次のリソースへのアクセス権が必要です。

  • gdcloud CLI または kubectl CLI

  • Linux 環境

組織の管理に必要な権限を取得するには、セキュリティ管理者に組織管理者（organization-admin）ロールの付与を依頼してください。

サーバーにアクセスしてモニタリングする

GDC サーバーにアクセスして状態をモニタリングし、安全で最新の状態であり、機能していることを確認します。

組織のサーバーのモニタリングの詳細については、指標のクエリと表示をご覧ください。

サーバーのライフサイクルを管理する

サーバーのライフサイクル管理には次の機能が含まれます。

  • 電源をオフにして再度オンにするか、再起動します。
  • 再イメージング。
  • ベースボード管理コントローラ（BMC）と複合プログラマブル ロジック デバイス（CPLD）のファームウェア アップデート。
  • オペレーティング システムまたはソフトウェアのアップデート。
  • セキュリティ設定などのオペレーティング システムの構成。

ベース オペレーティング システムのセキュリティ パッチ、サーバーホスト ソフトウェアのバンドル アップグレード、サーバー ファームウェアのアップグレードは、メンテナンスの時間枠で定期的に実行されます。

メンテナンスの時間枠には、次のアクションが含まれます。

  • サーバー オペレーティング システムに緊急のセキュリティ アップデートをインストールします。
  • 1 台以上のサーバーでホスト ソフトウェア バンドルをアップグレードします。
  • 1 台以上のサーバーのファームウェアをアップグレードします。

ワークロード サーバーの追加と管理

ワークロード サーバーを追加するか、既存のワークロード サーバーを管理するには、iac リポジトリに保存されている OrganizationZonalConfig カスタム リソースを更新します。

  1. 使用可能なサーバーとサーバータイプのリストを生成します。

    kubectl get servers -n gpc-system -o \
    jsonpath='{range .items[?(@.status.bareMetalHostStatus.provisionState=="available")]}{.metadata.name}{"\t"}{.spec.serverHardware.machineClassName}{"\t"}{.status.bareMetalHostStatus.provisionState}{"\n"}{end}'

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

    ag-aa-bm04   o1-standard1-64-gdc-metal   available
ag-ab-bm07   o1-standard1-64-gdc-metal   available
ag-ab-bm11   o1-highmem1-96-gdc-metal    available
ag-ab-bm12   o1-highmem1-96-gdc-metal    available
ag-ab-bm13   o1-highmem1-96-gdc-metal    available
ag-ab-bm14   o1-highgpu1-48-gdc-metal    available
ag-ab-bm15   o1-highgpu1-48-gdc-metal    available
ag-ab-bm16   o1-highgpu1-48-gdc-metal    available

    使用可能なサーバーをメモし、組織のワークロード サーバーを変更するときに、使用可能なサーバーのみを割り当てるようにします。

  2. iac リポジトリで OrganizationZonalConfig カスタム リソース YAML ファイルを開きます。

    vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml

    次のように置き換えます。

    • IAC_REPO_PATH: iac リポジトリのフォルダパス。
    • ORG_NAME: 組織の名前。
    • ZONE: ユニバース内のゾーンの名前。ゾーン名は {generalRegion}-{regionQualifier}{regionCounter}-{zoneLetter} の形式で派生します。例: us-central1-b。ゾーン属性値の説明については、お客様受付アンケートのゾーン セクションをご覧ください。

  3. YAML ファイルの workloadServers セクションを更新します。新しいワークロード サーバーを追加するか、各タイプの既存のサーバーの数を管理します。

    ...
workloadServers:
  o1-highmem1-40-gdc-metal: 1
  o1-standard1-64-gdc-metal: 2
  o1-highmem1-96-gdc-metal: 3
  o1-highmem1-104-gdc-metal: 4
  o1-highmem1-448-gdc-metal: 5
  o1-highgpu1-48-gdc-metal: 6
...

  4. インタラクティブ エディタを保存して閉じます。

  5. 組織のゾーン構成 YAML ファイルに対する変更をステージングして commit します。

    git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit

  6. 更新を GitLab に push します。

    git -c http.sslVerify=false push

  7. コードレビューとマージを待ちます。

  8. Distributed Cloud デプロイのすべての Distributed Cloud ゾーンのすべての GitLab リポジトリに対して、同じコンテンツとディレクトリ構造でこれらの手順を繰り返します。

    Distributed Cloud のデプロイでは、各ゾーンに個別の切断された GitLab インスタンスが含まれています。GitLab で作成、更新、削除されたグローバル リソースごとに、各ゾーンの GitLab リポジトリにまったく同じコンテンツを commit する必要があります。グローバル ルート Reconciler Pod は、グローバル API の zoneselectionresult カスタム リソースの primary フィールドで定義されたプライマリ Distributed Cloud ゾーンで実行されます。Reconciler は、プライマリ ゾーンの GitLab からグローバル API にデータを同期します。

  9. 割り当てたワークロード サーバーが使用可能であることを確認します。

    kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig get servers -n gpc-system -o \
    jsonpath='{range .items[?(@.spec.nodePoolClaimRef.namespace=="org-1")]}{.metadata.name}{"\t"}{.status.provisionReady}{"\n"}{end}'

    ワークロード サーバーが true に設定されている場合、使用可能です。出力は次のようになります。

    zi-aa-bm04      true
zi-aa-bm05      true
zi-aa-bm06      true

ストレージ容量を増やす

ゾーンで使用できる各組織のストレージ容量は、OrganizationZonalConfig リソースの capacities フィールドで定義されます。

これらのストレージ クラスの割り当てを増やすには、各ゾーンの OrganizationZonalConfig リソースを更新します。

  1. iac リポジトリで OrganizationZonalConfig カスタム リソース YAML ファイルを開きます。

    vim IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE.yaml

    次のように置き換えます。

    • IAC_REPO_PATH: iac リポジトリのフォルダパス。
    • ORG_NAME: 組織の名前。
    • ZONE: ユニバース内のゾーンの名前（us-central1-b など）。ゾーン属性値の詳細については、お客様のオンボーディング アンケートのゾーンのセクションをご覧ください。

  2. YAML ファイルの capacities セクションを、ストレージ タイプの新しい割り当て値で更新します。次に例を示します。

    # Several lines of code are omitted here.
spec:
  capacities:
    storage:
      file-standard: FILE_QUOTA
      block-standard: BLOCK_QUOTA
      object-standard: OBJECT_QUOTA

    次のように置き換えます。

    • FILE_QUOTA: ゾーン内のファイル ストレージの新しい割り当て値（10Ti など）。
    • BLOCK_QUOTA: ゾーン内のブロック ストレージの新しい割り当て値（10Ti など）。
    • OBJECT_QUOTA: ゾーン内のオブジェクト ストレージの新しい割り当て値（10Ti など）。

    OrganizationZonalConfig リソース内でストレージ容量を定義する方法については、TypedResourceCapacities リファレンス ドキュメントをご覧ください。

  3. インタラクティブ エディタを保存して閉じます。

  4. 組織のゾーン構成 YAML ファイルに対する変更をステージングして commit します。

    git add IAC_REPO_PATH/iac/infrastructure/global/orgs/root/ORG_NAME-ZONE
git commit

  5. 更新を GitLab に push します。

    git -c http.sslVerify=false push

  6. コードレビューとマージを待ちます。

  7. GDC デプロイのすべての GDC ゾーンのすべての GitLab リポジトリに対して、同じコンテンツとディレクトリ構造で上記の手順を繰り返します。