完了までの推定時間: 7 時間
操作可能なコンポーネントのオーナー: KUB/SERV/OBJ/FILE/PNETスキル プロファイル: デプロイ エンジニア
このガイドでは、内部クラスタと組織のインフラストラクチャ クラスタのコントロール プレーンとして機能するルート管理クラスタを作成します。
19.1. ルーティング構成を設定する
ブートストラップ サーバーのインストール中に静的ルートが追加されたことを確認します。静的ルートがない場合は、ブートストラッパーに静的ルートを追加します。
DATA_CIDR=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -o jsonpath={.spec.ipv4Spec.staticCidrBlocks[0]})
DATA_GATEWAY=$(kubectl get subnetclaims -n root control-plane-subnet -o jsonpath={.status.ipv4SubnetStatus.gateway})
ip route replace ${DATA_CIDR} via ${DATA_GATEWAY}
このルートは、ブートストラップのデータプレーン インターフェースからルート管理クラスタの API サーバーへのアクセスを提供します。GDC の API サーバーの詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。
19.2. ルート管理クラスタを作成する
次のコマンドは、3 つのコントロール プレーン ノードを持つルート管理クラスタを作成します。デフォルトのテナント モードはマルチテナント モードです。
gdcloud system admin-cluster install -v=3 \
--tenant-mode=multi \
--root-admin-node-count=3 \
--generate-admin-yaml \
--addon-manager-manifests-set harbor.postgresqlHA.enabled=true \
--addon-manager-manifests-set harbor.productionEnvironment.enabled=true \
--addon-manager-manifests-set storage.mode=ontap \
--addon-manager-manifests-set gpuFeature.enabled=true \
--addon-manager-manifests-set rootAdmin.controller.adminLBPoolSize=23 \
--addon-manager-manifests-set rootAdmin.controller.systemLBPoolSize=60 \
--addon-manager-manifests-set network.noInternalSubnet=false \
--addon-manager-manifests-set minStage=FEATURE_THRESHOLD
ルート管理クラスタを作成するには、クラスタ CR の構成ファイルが必要です。デフォルトでは、構成は自動的に生成されます。フラグ --generate-admin-yaml を false に設定し、--admin-yaml-path を指定してターゲット構成パスを参照するようにすることで、クラスタ構成をカスタマイズすることもできます。
ルート管理クラスタのインストールが完了すると、ルート管理クラスタの kubeconfig が /root/release/root-admin/root-admin-kubeconfig に保存されます。
クラスタのインストール後に、ユーザー管理者ユーザー インターフェース（UI）の URL が出力されます。後のオペレーションで使用するために、この値を覚えておきます。次のコマンドを使用して取得することもできます。
gdcloud system admin-cluster describe
19.3. コンポーネントをルート管理クラスタにデプロイする
次のコマンドは、操作可能なコンポーネント ライフサイクル テンプレートをルート管理クラスタにデプロイします。
gdcloud system component deploy --kubeconfig KUBECONFIG --names=* --pivot-from=/root/.kube/config
19.4. ルート管理者の機能ゲートを構成する
production と異なる機能ステージのしきい値がある場合は、OOPS-P0072 に従って、しきい値に合わせて機能ゲートを更新する必要があります。
19.5. ブートストラッパーでスタブ リゾルバを構成する
次のコマンドを使用して、ブートストラップで DNS スタブ リゾルバを設定します。コンソールにアクセスするには、このスタブ リゾルバが必要です。
gdcloud system dns install
この構成により、次の図に示すように、すべての組織のドメイン名がブートストラッパーから解決可能になります。
19.6. iLo IP アドレスを設定する
次の手順では、管理ノードの ILO IP アドレスを static に設定します。
ADMIN_NODE=NODE NAME
RACK=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.metadata.labels.system\.private\.gdc\.goog/rack-name}')
ILO_IP=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.ip}')
ILO_GATEWAY=$(kubectl --kubeconfig KUBECONFIG get subnetclaims -n root $RACK-mgmtsw01-server-bmc-subnet -o jsonpath='{.status.ipv4SubnetStatus.gateway}')
BMC_CREDS=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.credentialsRef.name}')
ILO_USER=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.username}' | base64 --decode)
ILO_PASS=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.password}' | base64 --decode)
echo Target Server: $ADMIN_NODE
echo ILO IP: $ILO_IP
echo ILO Gateway: $ILO_GATEWAY
echo ILO Username: $ILO_USER
echo ILO Password: $ILO_PASS
クラスタ内の情報に基づいて、上記の情報が正しいことを確認します。上記の情報が正確な場合は、次のコマンドを実行します。
DHCP を無効にします。
curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"DHCPv4": {"DHCPEnabled": false}}' | jq '.'Expected result:
MessageId: iLO.2.15.ResetRequiredIP アドレスとゲートウェイを構成します。
curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"IPv4Addresses":[{"Address":"'${ILO_IP}'","Gateway":"'${ILO_GATEWAY}'","SubnetMask":"255.255.255.0"}],"IPv4StaticAddresses": [{"Address": "'${ILO_IP}'", "Gateway": "'${ILO_GATEWAY}'", "SubnetMask": "255.255.255.0"}]}' | jq .Expected result:
MessageId: Base.1.4.SuccessiLO マネージャーをリセットします。
curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq .Expected result:
MessageId: iLO.2.15.ResetInProgressイーサネットの設定が適用されていることを確認します。レスポンスがハングしている場合は、リセットが完了していません。現在の curl コマンドをキャンセルし、20 秒待ってからもう一度お試しください。
curl --insecure -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 -X GET | jq .
各ステップの HTTP 戻り値が想定される結果と一致することを確認して、成功を確認します。
クラスタに存在するすべてのルート管理者ノードに対して、前の手順を繰り返します。
19.7. OI ネットワークと Google Distributed Cloud（GDC）のエアギャップ接続を確立する
このセクションでは、接続を確立するために Operations Suite Infrastructure（OI）と Distributed Cloud ネットワークに構成ファイルをプロビジョニングする方法について説明します。
これらの手順では、一部の Distributed Cloud ファイルへのアクセスと、ランタイム ネットワーク情報を取得するための Distributed Cloud インスタンスのルート管理クラスタへの接続が必要です。
19.7.1. 始める前に
デプロイ プロセスのこの段階では、次のすべてが当てはまる必要があります。
両方の OIR スイッチがケーブル接続され、電源がオンになり、適切なバージョンにアップグレードされ、ベース構成と ACL 構成が適用されている。
両方の OIF ファイアウォールがケーブル接続され、電源がオンになり、適切なバージョンにアップグレードされ、FIPS-CC モードが有効になり、基本構成が適用されている。
Distributed Cloud 接続のプロビジョニング全体を完了するには、Distributed Cloud インスタンスでネットワーク ブートストラップが完了し、kind クラスタからルート管理者クラスタに移動している必要があります。
19.7.2. 環境を準備する
次の手順に備えて、次の情報を収集し、環境変数を設定して環境を準備します。
OI は、ローカルまたはリモートの 2 つの方法で接続できます。ローカル接続は、同じデータセンター内のラック間のファイバー接続を使用して、OI を Distributed Cloud に直接接続します。リモート接続は、長距離トランスポートを使用して別のロケーションに接続します。この仕様は、Distributed Cloud 相互接続構成のプロビジョニングに必要な interconnect.yaml ファイルで指定できます。このファイルには、GDC 相互接続の構成に必要なすべての情報が含まれています。
19.7.2.1. 相互接続 YAML 仕様
| 属性 |
説明 |
例 |
|---|---|---|
zones[ ] map |
OI デプロイが接続する必要がある Distributed Cloud セルに関する情報。 Distributed Cloud セルのリストに接続するには、各ゾーンの各 Distributed Cloud セルの情報を含む zones のリストを指定します。ゾーン オプション |
例:zones: |
19.7.2.2. ゾーン オプション
interconnect.yaml ファイル内の Distributed Cloud セルに関する情報を伝えます。
| 属性 |
説明 |
使用量 |
|---|---|---|
zoneName文字列 |
OI デプロイが接続する必要がある Distributed Cloud セルの略称。 | zones: |
uplinkSpeeduint32 |
（省略可）接続の上りリンク速度（10 または 100）を指定します。 |
値:10、100デフォルト: 10uplinkSpeed: 100 |
localInstanceint |
ocit.yaml ファイルの OI デプロイ サイトの InstanceID。ローカル接続は、同じデータセンター内のラック間の光ファイバー接続を使用して、オペレーション スイート インフラストラクチャ コア ラック（OIR）サイトを Distributed Cloud に直接接続します。 |
zones: |
remoteInstance[ ] int |
ocit.yaml ファイルの OI デプロイサイトの InstanceID(s)リモート接続は、長距離転送を使用して別のロケーションに接続します。 remoteInstance 値のリストを指定して、すべての OIR サイトの構成を生成し、指定された Distributed Cloud セルに接続できます。 |
zones: zones: |
ローカル接続の場合は、interconnect.yaml ファイルを次のように構成します。
zones:
- zoneName: ah
uplinkSpeed: 100
localInstanceID: 1
cellCfg: /path/to/cellcfg
リモート接続の場合は、interconnect.yaml ファイルを次のように構成します。
zones:
- zoneName: ah
uplinkSpeed: 100
remoteInstanceIDs:
- 2
cellCfg: /path/to/cellcfg
マルチサイト OI デプロイの場合は、interconnect.yaml ファイルを次のように指定します。
zones:
- zoneName: ah
uplinkSpeed: 100
localInstanceID: 1
remoteInstanceIDs:
- 2
cellCfg: /path/to/cellcfg
19.7.3. スイッチ構成を生成する
これらの手順では、Distributed Cloud への接続をプロビジョニングするためにネットワーク デバイスに適用するパッチ構成が生成されます。
occonfigtool generate cell config -c /path/to/interconnect.yaml -o path/to/ocit.yaml
これにより、サイトごとに次の構成ファイルが生成されます。
| 構成ファイル | デバイス | 関数 |
|---|---|---|
| occoresw101.incremental | occoresw101 | Distributed Cloud インスタンスへの接続用にデバイスにパッチを適用する構成 |
| occoresw101.acl | occoresw101 | 分散クラウド ネットワークでトラフィックの適用を行うための ACL をパッチ適用する構成。 |
| occoresw102.incremental | occoresw102 | Distributed Cloud インスタンスへの接続用にデバイスにパッチを適用する構成 |
| occoresw102.acl | occoresw102 | 分散クラウド ネットワークでトラフィックの適用を行うための ACL をパッチ適用する構成。 |
| ocsw101.incremental | ocs1w01 | Distributed Cloud インスタンスへの接続用にデバイスにパッチを適用する構成 |
| ocsw101.acl | ocsw101 | 分散クラウド ネットワークでトラフィックの適用を行うための ACL をパッチ適用する構成。 |
| ocsw102.incremental | ocsw102 | Distributed Cloud インスタンスへの接続用にデバイスにパッチを適用する構成 |
| ocsw102.acl | ocsw102 | 分散クラウド ネットワークでトラフィックの適用を行うための ACL をパッチ適用する構成。 |
19.7.4. ファイアウォール ポリシーを生成する
ファイアウォール ルールを生成するには、occonfigtool がルート管理クラスタの Kubernetes API にアクセスする必要があります。KUBECONFIG 環境変数が root-admin-kubeconfig に設定されていることを確認します。
export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export OCIT_CONFIG_FILE=/path/to/ocit.yaml
次のコマンドを実行して、ファイアウォール ルールを生成します。
occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}
| 構成ファイル | デバイス | 関数 |
|---|---|---|
| firewall-rules.base | occorefw01 | Distributed Cloud インスタンスへの接続用にデバイスにパッチを適用する構成 |
19.7.5. 構成を適用する
出力ファイルを使用して、前の手順と同じ手順で、スイッチとファイアウォールの各ネットワーク デバイスに構成を適用します。
19.8. Distributed Cloud RoutePolicy リソースを更新する
Distributed Cloud は、ルートポリシーを使用して、ルーティング テーブルにアドバタイズできるネットワークを適用します。
OI を外部ネットワークとして追加する場合は、新しいネットワークを想定するように RoutePolicy CR を更新する必要があります。
これには、kubectl を使用して root-admin-cluster にアクセスする必要があります。適切な KUBECONFIG 変数が設定されていることを確認します。
export KUBECONFIG=/root/deploy/root-admin/root-admin-kubeconfig
確認するには、次の操作を行います。
kubectl get routepolicy -n gpc-system
次のような出力が表示されます。
NAME AGE
customerpeering-routepolicy 19d
datacenter-routepolicy 19d
mgmtnetworkoperationcenter-routepolicy 19d
networkoperationcenter-routepolicy 19d
これらの手順では、networkoperationcenter-routepolicy と mgmtnetworkoperationcenter-routepolicy に焦点を当てます。
19.8.1.1. データ ネットワーク ルートポリシーを修正する
ocinfo.opscenter.local.txt から、次のサブネット（ネットワークとプレフィックス長を含む）を取得します。
- OCCORE-SERVERS（次の例では
$OCCORE_SERVERS_NETとして使用） - OC-WORKSTATIONS（次の例では
$OC_WORKSTATIONS_NETとして使用）
次の変数を入力して、これらの値を使用してルートポリシーを調整します。
export OCCORE_SERVERS_NET=$OCCORE_SERVERS_NET
export OC_WORKSTATIONS_NET=$OC_WORKSTATIONS_NET
次に例を示します。
export OCCORE_SERVERS_NET=172.21.0.0/24
export OC_WORKSTATIONS_NET=172.21.32.0/24
環境変数を設定したら、次の kubectl コマンドを実行します。
kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OCCORE_SERVERS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OC_WORKSTATIONS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
出力例:
routepolicy.system.private.gdc.goog/networkoperationcenter-routepolicy patched
19.8.1.2. パッチ管理ネットワーク ルートポリシー
ocinfo.opscenter.local.txt から、次のサブネット（ネットワークとプレフィックス長を含む）を取得します。
- OCCORE-JUMPHOSTS（次の例では
$OCCORE_JUMPHOSTS_NETとして使用） - OCCORE-ILOS（次の例では
$OCCORE_ILOS_NETとして使用）
次の変数を入力して、これらの値を使用してルートポリシーを調整します。
export OCCORE_JUMPHOSTS_NET=$OCCORE_JUMPHOSTS_NET
export OCCORE_ILOS_NET=$OCCORE_ILOS_NET
次に例を示します。
export OCCORE_JUMPHOSTS_NET=172.21.2.0/27
export OCCORE_ILOS_NET=172.21.2.32/27
環境変数を設定したら、次の kubectl コマンドを実行します。
kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OCCORE_JUMPHOSTS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
--type=json -p="[
{
'op': 'add',
'path': '/spec/in/ipPrefixList/0',
'value': {
'action': 'Permit',
'ipPrefix': '${OCCORE_ILOS_NET:?}',
'prefixLengthMatchers': [
{
'operator': 'LE',
'prefixLength': 32
}
]
}
}
]"
出力例:
routepolicy.system.private.gdc.goog/mgmtnetworkoperationcenter-routepolicy patched
19.9. OI Distributed Cloud のネットワーク接続を検証する
このデプロイの時点で、次の条件を満たしている必要があります。
occoresw101とoccoresw102は、base、acl、incremental、incremental-aclの構成ファイルで構成されています。ocsw101とocsw102の両方がbase、acl、incremental、incremental-aclの構成ファイルで構成されています。occorefw101とoccoref102は、base構成ファイルとfirewall-rules.base構成ファイルで構成されています。- データセンターとオペレーション センター間のアップリンクが接続され、運用可能になっている。
- Distributed Cloud 間の物理アップリンクが検証されます。
上記の条件のいずれかが満たされていない場合、現在の状態によって出力が大きく異なる可能性があり、本番環境で期待どおりの動作が生成されない可能性があります。
19.9.1. 予想される出力
次のスニペットは、次のコマンドの既知の良好な環境からの出力を示しています。
show ip bgp summary vrf allshow ip bgp vrf allshow ip route vrf allshow lldp neighbors
これらのスニペットは、同じコマンドを使用して本番環境と比較できます。
19.9.2. キーの検証
次の出力で確認すべき主な事項は次のとおりです。
- BGP セッションが
Idle、Active、Closingの状態になっていない。 - すべての BGP セッションで
State/PrxRcd値が0より大きい。 - すべての BGP セッションに、継続的に増加する
Up/Downタイマーが表示されます。 - 分散クラウドの
externalCIDRプレフィックス（CIQ にあります）は、GDCH-DATA、GDCH-DATA-TRANSIT、OC-WORKSTATIONS、OCCORE-SERVERSの各 VRF のルーティング テーブルと BGP テーブルに存在します。 - Distributed Cloud
oobManagementCIDRs（CIQ にあります）は、GDCH-MGMT、GDCH-MGMT-TRANSIT、HW-INFRAの各 VRF のルーティング テーブルと BGP テーブルに存在します。
19.9.3. OCCORESW
次の表に、Distributed Cloud 相互接続の各 occore switch で想定される出力を示します。この手順の前に、すべてのネットワーク検証を完了する必要があります。ここで説明する BGP ネイバーとルートは、前述の BGP ネイバーとルートとともに存在する必要があります。すべてのスイッチで出力を検証します。
| VRF |
BGP ネイバー |
BGP ネイバーから受信した想定ルート |
BGP ネイバーにアドバタイズされるルート |
|---|---|---|---|
| GDCH-DATA-TRANSIT | AGGSW01 |
|
|
| GDCH-DATA-TRANSIT | AGGSW02 |
|
|
| GDCH-DATA-TRANSIT | OCCOREFW から OC-DATA VRF への HairPinned BGP セッション |
|
|
| OC-DATA | OCSW01 BGP セッション |
|
|
| OC-DATA | OCSW02 BGP セッション |
|
|
| OC-DATA | OCCORESW BGP セッション |
|
|
| GDCH-MGMT-TRANSIT | MGMTAGGSW01 |
|
|
| GDCH-MGMT-TRANSIT | MGMTAGGSW02 |
|
|
| GDCH-MGMT-TRANSIT | OCCORF を使用して HW-INFRA VRF にヘアピン接続された BGP セッション |
|
19.9.4. OCSW
次の表に、Distributed Cloud 相互接続手順の実行後の各 oc switch の出力の予想を示します。この手順の前に、すべてのネットワーク検証を完了する必要があります。ここで説明する BGP ネイバーとルートは、前述の BGP ネイバーとルートとともに存在する必要があります。すべてのスイッチで出力を検証します。
| VRF |
BGP ネイバー |
BGP ネイバーから受信した想定ルート |
|---|---|---|
| OC-DATA | OCCORESW01 BGP セッション |
|
| OC-DATA | OCCORESW02 BGP セッション |
|
出力コマンド スニペットは、Distributed Cloud の検証コマンドで確認できます。
19.9.5. マルチサイト OI デプロイの検証
以降のセクションでは、相互接続された複数の Distributed Cloud セルを使用してマルチサイト デプロイを検証する方法について説明します。この段階では、2 つのサイトを含むトポロジは次のようになります。
- 青色の接続は、サイト 1 が Distributed Cloud セル 01 とセル 02 に接続されていることを示しています。
- 赤い接続は、サイト 2 が Distributed Cloud セル 01 とセル 02 に接続されていることを示しています。
- 緑色の接続は、サイト 1 とサイト 2 の相互接続を示しています。
すべてのスイッチのすべてのサイトで、これらのセクションに記載されている手順を完了する必要があります。
19.10. OI ネットワークの最終手順を実施する
この段階では、すべての構成が生成され、すべてのデバイスに適用されている必要があります。
ネットワーク アクセス リストは、特定の想定されるフローを許可する状態になり、すべてのトラフィックを許可するデフォルト ルールも設定されています。
ここで、デプロイを運用に引き渡す必要があります。Operational Suite の機能、実装、提供されるサービスは、お客様によって異なります。そのため、トラフィック要件はさまざまです。
運用部門がデプロイを承認すると、ACL を処理してネットワーク トラフィック フローを完全に保護するのは運用部門のタスクになります。
これらのタスクを実行するために、運用ランブックが提供されます。
19.11. オブジェクト ストレージをアップグレードする
オブジェクト ストレージのブートストラップ中に、ノードに StorageGRID のサポートされている最新のマイナー バージョンがインストールされました。ただし、ターゲット バージョンを最新のホットフィックス パッチ バージョンに更新する必要がある場合があります。
次のコマンドを使用して、リリース メタデータからターゲット StorageGRID バージョンを特定します。
kubectl get releasemetadata -o jsonpath='{.items[0].spec.infraComponents.objectStorage.storageGridOSImageVersion}'
StorageGRID の現在のバージョンがターゲット バージョンでない場合は、ターゲット バージョンでオブジェクト ストレージのアップグレードを実行します。
19.12. 発生しうる問題
19.12.1. ストレージ仮想マシンが調整されない
要約: ルート管理クラスタの作成中にストレージ仮想マシンが準備完了にならない。
問題: ルート管理クラスタを作成した後、Storage Virtual Machine リソースが調整されず、次のような警告イベントが表示されます。
StorageVirtualMachine Reconcile error, retrying: SVM status update failed,
error: failed to get network interface info: Get
"https://172.22.147.128/api/network/ip/interfaces?fields=%2A%2A&max_records=4096&svm.name=root-admin":
EOF
セキュリティ上の理由で SSL を禁止するストレージ クラスタの構成ミスが原因で、この問題が発生する可能性があります。
回避策:
シリアルに接続するか、SSH を使用してストレージ クラスタに接続し、次のコマンドを実行します。
security ssl modify -server-enabled true -client-enabled true -vserver
CELL_ID-stge-clus-01
接続後、Storage Virtual Machine リソースは調整できます。
19.12.2. ファイアウォール TLS サーバー証明書のインストールでブートストラップが失敗する
ステップ 20 で説明されているルート管理者コントロール プレーンのブートストラップ タスクを実行すると、TLSServerCertification エラーが発生することがあります。
回避策:
ファイアウォール サーバー証明書のインストールを再試行するには、IO サービス マニュアル FW-R1008 に記載されている手順を参照してください。インストールが正常に完了したら、--start-phase コマンドとともに gdcloud コマンドを使用して、root-admin ブートストラップを続行します。