15.1. 网络要求
请参阅下图,了解 SG1000 和 SG6060 的布线图,以配置 GRID、Admin 和 Client 网络:

15.1.1. 管理节点 SG1000
您必须在 SG1000 中至少拥有两个管理节点。
对于每个管理员节点,您必须总共拥有四个 IP 地址,每个地址分别属于以下类别:
- BMC Network。
- Admin Network。
- 客户端网络。
- Grid Network。
您必须拥有三个子网,分别用于以下用途:
- Admin Network。
- BMC Network。
客户端网络和 Grid 网络,并且每个子网的子网掩码不得超过 30 位。
15.1.2. 存储节点 SG6060 和 SG6000
对于 SG6060 和 SG6000 型号,您必须至少有三个存储节点。
对于每个存储节点,您必须总共拥有 5 个 IP 地址,每个地址分别位于以下位置:
- BMC 网络(管理)。
- 管理网络。
- Grid Network。
- 存储控制器网络 (mgmt)。注意:存储控制器网络必须具有两个 IP 地址。
您必须为以下各项分别设置两个子网:
- BMC Network。
- Admin Network。
- 存储控制器网络。
- Grid Network。
下表列出了管理员节点和存储节点的 IP 地址数量:
| 所需的 IP 数量 | Admin Network | 客户端网络 | Grid Network |
|---|---|---|---|
| 管理员节点 | 2 | 1 | 1 |
| 存储节点 | 4 | 0 | 1 |
您必须拥有以下三个子网:
- Admin Network。
- 客户端网络。
- Grid Network。
每个子网的子网掩码不得超过 30 位。
15.1.3. 网络详情
15.1.3.1. 分布式云管理平面网络:
分布式云带外 (OOB) 管理网络包含对象存储库主板管理控制器 (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 端点:
- 在
cellconfig文件中,搜索external-objectstorage-client-lif-subnet。 - 确定相应的
SubnetClaim,该参数用于指定分配的 CIDR/网关 IP 地址。
SG1000 网格网络设备端点:
- 在
cellconfig文件中,搜索objectstorage-admin-nodes-lif-subnet。 - 确定相应的
SubnetClaim,该参数用于指定分配的 CIDR/网关 IP 地址。
- 在
SG6060 网格网络设备端点:
- 在
cellconfig文件中,搜索objectstorage-storage-nodes-lif-subnet。 - 确定相应的
SubnetClaim,该参数用于指定分配的 CIDR/网关 IP 地址。
- 在
15.2. 准备工作
15.2.1. 收集信息
预计用时:5-10 分钟
在继续本部分之前,请确保网络引导和配置已完成分布式云实例,并且操作员可以访问最准确或最新的 cellconfig 文件,或者可以访问引导。
15.2.1.1. 收集存储硬件设备信息
分布式云实例遵循固定的命名惯例,以标识机架中的硬件设备。具体而言,是以下对象存储设备:
- 管理节点(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. 收集管理平面网络信息
在网络引导和配置期间,操作员必须为管理平面创建子网。在引导过程中,对象存储系统需要以下信息:
- 管理子网。
- 管理网关 IP 地址。
- 管理子网中预留了 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. 收集数据平面网络信息
在继续之前,请确保您已在网络引导启动和配置期间为对象存储系统预配了三个子网。
检查以下子网是否存在:
-
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
检查是否存在以下字段:
VLANREADY: TrueVLANREADY: True
15.2.1.4. 收集依赖项信息
对象存储系统依赖于 Distributed Cloud 中的以下核心服务和基础架构:
- NTP
- 硬件安全模块 (HSM)
- DNS
15.2.1.5. 更新待填充字段
检查 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 设备,请使用故障排除设备连接到每个设备(包括两个管理节点和三个存储节点),并通过管理网络端口 6 访问 https://169.254.0.1:8443,以在管理网络上设置管理 IP 地址。
使用以太网线缆将故障排查车直接连接到服务设备最右侧的 RJ-45 端口。以下图表以管理节点和存储节点为例,展示了端口 6:


在急救车上打开网络浏览器。
在每台机器上前往
https://169.254.0.1:8443。在 StorageGRID 设备安装程序的菜单栏中,依次点击 Configure Networking > Link Configuration。检查管理员网络是否已启用。

如需配置管理员网络的 IP 地址,请依次选择 Configure Networking > IP Configuration。
向下滚动到管理网络部分,然后在 IP 分配中,选择静态,然后输入节点的相应管理 IP 地址
managementIP。您可以在obj-cellobj.yaml文件中找到每个节点的管理 IP。例如: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-siteObjectStorageStorageNode (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进行的配置:
点击保存,然后验证 IP 地址是否已更新。
从引导加载程序 ping 管理 IP 地址,以确保其可访问。
- 从引导加载程序 ping 管理 IP 地址,以确保其可访问。
- 所有节点在管理网络上都具有 IP 地址后,使用 StorageGRID 节点的管理 IP 地址访问其安装 GUI。
问题排查:
如果节点无法 ping 通:
- 从上一步(步骤 3)访问 StorageGRID 节点安装界面,并检查对话框横幅中是否显示任何错误。尝试解决错误。如有必要,请与工程师联系。
- 依次前往配置网络 > IP 配置。验证是否已在正确的“Admin Network”(管理网络)部分配置正确的静态 IP 和网关。有时,StorageGRID 节点在确认后无法完全注册管理网络配置。
- 再次执行第 5 步至第 8 步,并验证管理员节点网络。
必须能够访问每个节点上的 StorageGRID 节点安装 GUI,才能继续安装对象存储系统。
15.2.3. 升级 StorageGRID
预计用时:1-1.5 小时
在升级 StorageGRID 之前,请检查 StorageGRID 软件版本。依次前往高级 > 上传 StorageGRID 软件。您会看到当前的 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 部分。

15.2.3.1. 升级固件
请针对所有 StorageGRID 节点执行以下步骤:
-
af-ae-objsadm01 -
af-ae-objsadm02 -
af-ae-objs01 -
af-ae-objs02 -
af-ae-objs03
从软件包中提取固件映像:
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/中找到。在 StorageGRID 节点上,导航到 StorageGRID 设备安装程序。 依次选择高级 > 升级固件。上传所选固件版本的固件映像
storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2和校验和storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1。上传后,StorageGRID 会自动开始验证文件。验证通常需要大约 5 到 10 分钟。
出现两个绿色对勾标记后,点击升级非活动分区。

收到消息
Successfully updated the firmware on the inactive partition后,请查看当前固件部分,确保非活动分区确实是正确的版本。依次点击重新启动和交换分区两次。
节点完成重启后,重复执行步骤 1 和 2,以升级另一个分区中的固件。活跃分区是所选版本,而非活跃分区包含旧版本。

15.2.3.2. 升级 StorageGRID 软件
所有节点上的固件都升级到正确版本后,将两个管理节点上的软件升级到所选版本。无需升级存储节点,因为它们会模拟并拉取管理节点上的软件。
在 SG1000 的管理节点上,按照以下说明操作:
-
af-ae-objsadm01 -
af-ae-objsadm02
从软件包中提取安装映像:
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/中。前往 Advanced -> Upload StorageGRID Software。点击 Remove(移除)以移除当前软件,然后上传新软件包
storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb和相应的校验和storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5,如图所示:
软件上传完毕后,请确保节点的软件已更新到所选版本:

15.2.4. 升级 SANtricity
预计用时:1-1.5 小时
在升级 SANtricity 之前,请检查 SANtricity 软件版本。前往 SANtricity 界面,然后依次点击支持 > 升级中心 > 开始升级。系统会显示当前的 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 操作系统版本。否则,请前往安装。

15.2.4.1. 升级 SANtricity OS
在 SANtricity 界面中,按照以下说明操作每个存储节点:
从软件包中提取安装映像:
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/中。依次前往支持 > 升级中心。在 SANtricity 操作系统软件升级中,点击开始升级。点击浏览,选择 SANtricity OS 软件文件。上传新的软件包
RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp,如下所示:
点击开始,然后确认您要执行相应操作。
升级完成后,验证版本是否已更新:

15.3. 安装
15.3.1. 创建 Secret
预计用时:15-30 分钟
如需获取用于创建 Secret 的值,请使用 cellcfg 目录:
获取
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获取存储节点的 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通过上一个命令的输出结果中的链接登录 SANtricity 系统管理器。如果您之前未设置密码,请创建密码并登录:

- 如果 SANtricity 密码丢失,请通过 StorageGRID E2860 串行控制台重置密码。如需连接到 E2860 磁盘阵列串行端口,终端设置应为 115200 8N1。
在 SANtricity 系统管理器上为两个控制器配置 NTP 服务器地址:

获取 NTP 服务器地址
kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP ```在 SANtricity 系统管理器中选择硬件。
如果图形显示的是硬盘,请点击显示机架背面。图形会发生变化,显示控制器而非驱动器。
点击要配置的控制器。系统会显示控制器的上下文菜单。
选择 Configure NTP server。系统随即会打开“配置网络时间协议 (NTP) 服务器”对话框。
选择 I want to enable NTP on Controller (A or B)。对话框中会显示其他选择。
选择手动指定 NTP 服务器地址。使用上一个命令提取的 IP 之一输入主 NTP 服务器地址。
点击保存。
更新 cell.yaml 文件中包含每个存储节点 SANtricity 凭据的 Secret。如果这些 Secret 不存在,请按照以下模板添加 Secret:
apiVersion: v1 kind: Secret metadata: creationTimestamp: null name: <STORAGE_NODE_NAME>-santricity namespace: gpc-system stringData: password: 'PASSWORD' username: 'admin' type: Opaque为上一步中列出的每个存储节点创建 Secret:
kubectl create secret generic \ --namespace=gpc-system STORAGE_NODE_NAME-santricity \ --from-literal=username=admin \ --from-literal=password=PASSWORD
验证:
针对上一步中列出的每个存储节点运行以下命令。它会输出在上一步中设置的 Santricity 用户名。验证管理员:
kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo针对上一步中列出的每个存储节点运行以下命令。它会输出 Santricity 密码:
kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo运行以下命令以获取 Santricity 管理界面的网址。使用以下用户名和密码登录 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 管理界面,请执行以下操作:
- 通过 StorageGRID E2860 串行控制台重置管理员凭据。
- 执行除最后一步之外的所有先前步骤。
删除每个节点的现有 Santricity Secret:
kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity执行最后一步,重新创建 Santricity Secret。
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. 在加入区域中启动对象存储
问题排查:
- 如果 Google Cloud CLI 命令超时或返回错误,请解决返回的任何问题。
- 如需详细了解该错误,请检查登录
gpc-system/obj-infra-cluster-cm-backend-controllerpod。
15.3.2.3. 在加入区域中启动对象存储
预计用时:30-60 分钟
在加入区域中启动对象存储需要锚定区域和加入区域中的对象存储协调器进行协调。由于在启动时,调和器在两个可用区之间没有安全且受控的通信渠道,因此 IO 需要手动促进对象存储调和器在两个可用区之间的安全通信。
- 在锚定可用区中的根管理员区域集群和全局集群中,为自己授予集群管理员预定义角色。如需了解详情,请参阅 IAM 运行手册。
或者,在锚定区域中应用以下两个角色绑定:
在全局 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
在锚定区域中运行该命令以获取 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}'设置加入区域的 DNS 桩解析器,以与锚定区域关联:
停用并停止 systemd-resolved
sh systemctl disable systemd-resolved.service --now删除 resolv.conf 文件(如果存在)
sh rm -f /etc/resolv.conf将锚定区域的 DNS 服务器 IP 写入加入区域的 resolv.conf
sh vim /etc/resolv.conf/etc/resolv.conf 文件内容示例:sh nameserver 10.200.40.0
在加入区域中创建
TokenRequestYAML 文件。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替换为客户意见征集问卷中的可用区名称,如本部分末尾的注释中所述。将 TokenRequest YAML 文件转移到锚定区域。
scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH将 TokenRequest YAML 应用到锚定区域中的 root-admin 全局集群。
kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH在锚定区中创建令牌 YAML 文件。
gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH将令牌 YAML 文件转移到加入的区域。
scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH将令牌 YAML 应用到加入区域中的 KIND 集群。
kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH在锚定区域中创建 ObjectStorageBootstrap YAML 文件。
gdcloud system objectstorage create-bootstrap --output-file OBJECT_STORAGE_BOOTSTRAP_YAML_PATH将 ObjectStorageBootstrap YAML 文件转移到加入的可用区。
scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH将 ObjectStorageBootstrap YAML 文件应用于加入区域中的 KIND 集群。
kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH在加入的可用区中启动对象存储。
gdcloud system objectstorage install --config /CELLCFG_PATH --add-zone --enable-objectstorage-hsm -v 5