SCM HA 配置
配置
一个 Ozone 配置文件(ozone-site.xml)可以支持多组 SCM HA 节点集,以及多个 Ozone 集群。为了在可用的 SCM 节点之间进行选择,每个集群都需要一个逻辑名称,通过该名称可以解析出各个 Storage Container Manager 的 IP 地址(以及域名)。
这个逻辑名称称为 serviceId,可以在 ozone-site.xml 中进行配置。
大多数情况下,你只需要设置当前集群的值:
<property>
<name>ozone.scm.service.ids</name>
<value>cluster1</value>
</property>对于每个已定义的 serviceId,应为每个服务器定义一个逻辑配置名称。
<property>
<name>ozone.scm.nodes.cluster1</name>
<value>scm1,scm2,scm3</value>
</property>已定义的前缀可用于指定每个 SCM 服务的地址:
<property>
<name>ozone.scm.address.cluster1.scm1</name>
<value>host1</value>
</property>
<property>
<name>ozone.scm.address.cluster1.scm2</name>
<value>host2</value>
</property>
<property>
<name>ozone.scm.address.cluster1.scm3</name>
<value>host3</value>
</property>为获得可靠的高可用支持,请选择 3 个相互独立的节点来组成仲裁(Quorum)。
引导(Bootstrap)
第一个 SCM-HA 节点的初始化方式与非 HA 的 SCM 相同:
ozone scm --init第二个和第三个节点应当使用 引导(bootstrap) 而非初始化(init)方式启动。这些集群将加入到已配置的 RAFT 仲裁组中。当前服务器的 ID 由 DNS 名称标识,也可以通过 ozone.scm.node.id 显式设置。大多数情况下无需设置,因为基于 DNS 的 ID 检测通常就能正常工作。
ozone scm --bootstrap注意:这两个命令都只执行一次初始化。SCM 仍需通过运行 ozone --daemon start scm 来启动。
SCM Leader 切换
有关手动切换 SCM Leader 的信息,请参阅 Storage Container Manager Leader 切换 文档。
自动引导(Auto-bootstrap)
在某些环境中(例如 Kubernetes),我们需要一种通用的、统一的方式来初始化 SCM HA 仲裁组。提醒一下,标准的初始化流程如下:
- 在第一个「原始(primordial)」节点上:
ozone scm --init - 在第二/第三个节点上:
ozone scm --bootstrap
这一点可以改进:可以通过在配置中将 ozone.scm.primordial.node.id 设置为其中一个节点,来配置原始 SCM。
<property>
<name>ozone.scm.primordial.node.id</name>
<value>scm1</value>
</property>通过此配置,scm --init 和 scm --bootstrap 都可以安全地在所有 SCM 节点上执行。每个节点将根据 ozone.scm.primordial.node.id 以及自身的节点 ID,只执行适用于自己的操作。
注意:init/bootstrap 过程完成后,仍然需要启动 SCM。
ozone scm --init
ozone scm --bootstrap
ozone --daemon start scm在 Docker/Kubernetes 中,请使用 ozone scm 在前台启动它。
SCM HA 安全性

在执行 init 操作的 SCM 上,我们称这个 SCM 为初始 SCM(primordial SCM)。初始 SCM 使用自签名证书启动 root-CA,并用于为自己以及其他完成引导的 SCM 签发已签名证书。只有初始 SCM 才能为其他 SCM 签发已签名证书。因此,初始 SCM 在 SCM HA 集群中具有特殊角色,因为它是唯一能够向 SCM 签发证书的节点。
初始 SCM 扮演 root-CA 角色,它使用 sub-CA 证书为所有 SCM 实例签名。SCM 使用这些 sub-CA 证书为 OM/数据节点签名证书。
在引导一个 SCM 时,它会从主 SCM 获得一张已签名的证书,并启动 sub-CA。
各 SCM 上的 sub-CA 用于为集群中的 OM/DN 签发已签名证书。只有领导者 SCM 才会向 OM/DN 签发证书。
如何启用安全性
<property>
<name>ozone.security.enable</name>
<value>true</value>
</property>
<property>
<name>hdds.grpc.tls.enabled</name>
<value>true</value>
</property>除正常的 SCM HA 配置外,还需要上述配置。
始祖 SCM
始祖 SCM 由配置项 ozone.scm.primordial.node.id 决定,其值可以是 SCM 的节点 ID 或主机名。如果未定义该配置,则运行 init 命令的节点被视为始祖 SCM。
bin/ozone scm --init这将为根 CA 设置公钥、私钥对和自签名证书,同时生成公钥、私钥对和 CSR,以便从根 CA 获取子 CA 的签名证书。
引导 SCM
bin/ozone scm --bootstrap这将为子 CA 生成一对公钥和私钥,并生成 CSR,以便从根 CA 获取子 CA 的已签名证书。
注意:如果未定义初始(primordial)SCM,请确保只在其中一个 SCM 主机上运行 --init。使用 --bootstrap 启动其他 SCM 节点。
当前 SCM HA 安全性限制
- 不支持从非安全 HA 集群升级到安全 HA 集群。
实现细节
SCM HA 使用 Apache Ratis 在 SCM HA 仲裁组的成员之间复制状态。每个节点在本地 RocksDB 中维护块管理元数据。
该复制过程是 OM HA 复制过程的简化版本,因为它不使用双缓冲区(由于 SCM 请求的整体数据库吞吐量较低)。
数据节点会将所有报告(容器报告、管道报告等)并行发送给所有 SCM 节点。只有领导者节点可以分配/创建新的容器,并且只有领导者节点会向数据节点发送命令。
验证 SCM HA 设置
启动 SCM HA 之后,可以验证 SCM 节点是否形成了一个统一的仲裁组,而不是 3 个独立的 SCM 节点。
首先,检查所有 SCM 节点存储的 ClusterId 元数据是否相同:
cat /data/metadata/scm/current/VERSIONClusterId 包含在 VERSION 文件中,并且所有 SCM 节点上的该值应保持一致:
#Tue Mar 16 10:19:33 UTC 2021
cTime=1615889973116
clusterID=CID-130fb246-1717-4313-9b62-9ddfe1bcb2e7
nodeType=SCM
scmUuid=e6877ce5-56cd-4f0b-ad60-4c8ef9000882
layoutVersion=0你也可以创建数据,并使用 ozone debug 工具再次确认所有容器元数据都已完成复制。
bin/ozone freon randomkeys --numOfVolumes=1 --numOfBuckets=1 --numOfKeys=10000 --keySize=524288 --replicationType=RATIS --numOfThreads=8 --factor=THREE --bufferSize=1048576
# use debug ldb to check scm.db on all the machines
bin/ozone debug ldb --db=/tmp/metadata/scm.db ls
bin/ozone debug ldb --db=/tmp/metadata/scm.db scan --column-family=containers从非 HA 迁移到 HA SCM
添加额外的 SCM 节点,并扩展集群配置以反映新增的节点。使用 scm --bootstrap 命令对新增的 SCM 节点进行引导,并启动 SCM 服务。注意:在新增的 SCM 节点上运行 bootstrap 命令之前,请确保 ozone.scm.primordial.node.id 属性指向现有的 SCM。
评论
登录后参与评论
KnowForge