預計完成時間：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 伺服器」。
19.2. 建立根管理員叢集
下列指令會建立具有三個控制層節點的根管理員叢集。預設的租戶模式為多租戶模式。
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) 的網址。請記下這個 ID，以供後續作業使用。您也可以使用下列指令擷取該值：
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 '.'預期結果：
MessageId: iLO.2.15.ResetRequired設定 IP 位址和閘道。
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 .預期結果：
MessageId: Base.1.4.Success重設 iLO 管理員。
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 .預期結果：
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 基礎架構 (OI) 和 Distributed Cloud 網路建立連線。
這些步驟需要存取部分 Distributed Cloud 檔案，並連線至 Distributed Cloud 執行個體的根管理員叢集，才能擷取執行階段網路資訊。
19.7.1. 事前準備
在部署程序的這個階段，必須符合下列所有條件：
兩個 OIR 交換器都已接線、開機、升級至適當版本，並套用基本和 ACL 設定。
兩個 OIF 防火牆都已接上電纜、開機、升級至適當版本、啟用 FIPS-CC 模式，並套用基本設定。
如要完成整個 Distributed Cloud 連線佈建作業，Distributed Cloud 執行個體必須完成網路啟動程序，並從 kind 叢集移至根管理叢集。
19.7.2. 準備環境
請先收集下列資訊並設定環境變數，為後續步驟做好準備。
您可以透過本機或遠端連線兩種方式連線至 OI。
本機連線會使用同一資料中心機架間的光纖連線，直接將 OI 連線至 Distributed Cloud。遠端連線會使用長途傳輸連線至不同地點。這項規格可透過 interconnect.yaml 檔案提供，這是佈建 Distributed Cloud 互連設定的必要條件。這個檔案包含設定 GDC 互連所需的所有資訊。
19.7.2.1. 互連 YAML 規格
| 屬性 |
說明 |
範例 |
|---|---|---|
zones[ ] map |
OI 部署作業需要連線的 Distributed Cloud 儲存格相關資訊。 如要連線至 Distributed Cloud 儲存格清單，請指定 zones 清單，其中包含每個可用區中每個 Distributed Cloud 儲存格的資訊。
可用區選項 |
範例：zones: |
19.7.2.2. 可用區選項
在 interconnect.yaml 檔案中，攜帶 Distributed Cloud 儲存格的相關資訊：
| 屬性 |
說明 |
用量 |
|---|---|---|
zoneName字串 |
OI 部署作業需要連線的 Distributed Cloud 儲存格縮寫。 | zones: |
uplinkSpeeduint32 |
(選用) 提供連線的上傳速度：(10 或 100)。
|
值：10、100預設值： 10uplinkSpeed: 100 |
localInstanceint |
OI 部署網站的 InstanceID (來自 ocit.yaml 檔案)。本機連線會使用同一資料中心機架間的光纖連線，將 Operations Suite 基礎架構核心機架 (OIR) 站點直接連線至 Distributed Cloud。 |
zones: |
remoteInstance[ ] int |
InstanceID(s) 的 OI 部署網站 (來自 ocit.yaml 檔案遠端連線會使用長途傳輸連線至不同地點或多個地點。 您可以提供 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，透過 Distributed Cloud 網路強制執行流量。 |
| occoresw102.incremental | occoresw102 | 修補裝置的設定，以便連線至 Distributed Cloud 執行個體 |
| occoresw102.acl | occoresw102 | 設定修補 ACL，透過 Distributed Cloud 網路強制執行流量。 |
| ocsw101.incremental | ocs1w01 | 修補裝置的設定，以便連線至 Distributed Cloud 執行個體 |
| ocsw101.acl | ocsw101 | 設定修補 ACL，透過 Distributed Cloud 網路強制執行流量。 |
| ocsw102.incremental | ocsw102 | 修補裝置的設定，以便連線至 Distributed Cloud 執行個體 |
| ocsw102.acl | ocsw102 | 設定修補 ACL，透過 Distributed Cloud 網路強制執行流量。 |
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計時器。 - Distributed Cloud
externalCIDR前置字元 (位於 CIQ 中) 會出現在GDCH-DATA、GDCH-DATA-TRANSIT、OC-WORKSTATIONS和OCCORE-SERVERSVRF 的路由表和 BGP 表格中。 - Distributed Cloud
oobManagementCIDRs(位於 CIQ 中) 存在於GDCH-MGMT、GDCH-MGMT-TRANSIT和HW-INFRAVRF 的路由表和 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 | 使用 OCCOREFW 至 HW-INFRA VRF 的 HairPinned 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 儲存格的多站點部署作業。 此時，具有兩個網站的拓撲結構如下所示：
- 藍色連線表示網站 1 已連線至 Distributed Cloud cell 01 和 cell 02。
- 紅色連線表示網站 2 已連線至 Distributed Cloud cell 01 和 cell 02。
- 綠色連線代表網站 1 和網站 2 之間的互連。
您必須為所有交換器上的所有網站完成這些章節列出的步驟
19.10. 執行 OI 網路的最後步驟
在這個階段，所有設定都必須已產生並套用至所有裝置。
網路存取清單目前的狀態允許特定預期流程，但也有允許所有流量的預設規則。
您現在必須將部署作業交給營運團隊。Operational Suite 的功能、實作方式和服務因客戶而異。因此流量規定也不同。
作業團隊接受部署後，就必須處理 ACL，並充分確保網路流量安全。
我們提供作業 Runbook，協助您執行這些工作。
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
連線後，儲存空間虛擬機器資源就能進行協調。
19.12.2. 防火牆 TLS 伺服器憑證安裝失敗，導致啟動程序失敗
執行步驟 20 所述的根管理員控制平面啟動工作時，可能會遇到 TLSServerCertification 失敗。
解決辦法：
如要重新嘗試安裝防火牆伺服器憑證，請參閱 IO 服務手冊 FW-R1008 中的操作說明。成功完成安裝後，請使用 gdcloud 指令搭配 --start-phase 指令，繼續進行根管理員啟動程序。