From acfffca95446533a980bf0ca1cfd037822375eca Mon Sep 17 00:00:00 2001 From: Abby <78209557+abby-cyber@users.noreply.github.com> Date: Thu, 16 Mar 2023 15:43:36 +0800 Subject: [PATCH 1/5] config-rolling-update-strategy-for-operator --- docs-2.0/20.appendix/0.FAQ.md | 2 +- .../11.rolling-update-strategy.md | 37 +++++++++++++++++++ .../9.upgrade-nebula-cluster.md | 4 ++ mkdocs.yml | 9 +++-- 4 files changed, 47 insertions(+), 5 deletions(-) create mode 100644 docs-2.0/nebula-operator/11.rolling-update-strategy.md diff --git a/docs-2.0/20.appendix/0.FAQ.md b/docs-2.0/20.appendix/0.FAQ.md index 1f10081af16..0d1b78ff264 100644 --- a/docs-2.0/20.appendix/0.FAQ.md +++ b/docs-2.0/20.appendix/0.FAQ.md @@ -525,7 +525,7 @@ dmp 文件是错误报告文件，详细记录了进程退出的信息，可以 ### 防火墙中需要开放哪些端口？ -如果没有修改过[配置文件](../5.configurations-and-logs/1.configurations/1.configurations.md) 中预设的端口，请在防火墙中开放如下端口： +如果没有修改过[配置文件](../5.configurations-and-logs/1.configurations/1.configurations.md)中预设的端口，请在防火墙中开放如下端口： |服务类型|端口| |-|-| diff --git a/docs-2.0/nebula-operator/11.rolling-update-strategy.md b/docs-2.0/nebula-operator/11.rolling-update-strategy.md new file mode 100644 index 00000000000..72fb055b868 --- /dev/null +++ b/docs-2.0/nebula-operator/11.rolling-update-strategy.md @@ -0,0 +1,37 @@ +# NebulaGraph 集群的滚动更新策略 + +NebulaGraph 集群使用分布式架构将数据分成多个逻辑分片，每个分片存储在不同的节点上。分布式系统中，同一份数据通常会有多个副本。为了保证多个副本数据的一致性，NebulaGraph 集群使用 Raft 协议实现了多分片副本同步。Raft 协议中，每个分片都会选举出一个 Leader 副本，Leader 副本负责处理写请求，Follower 副本负责处理读请求。 + +通过 Operator 创建的 NebulaGraph 集群在滚动更新过程中，一个存储节点会暂时停止提供服务以进行更新。关于滚动更新的概述，参见[执行滚动更新](https://kubernetes.io/zh-cn/docs/tutorials/kubernetes-basics/update/update-intro/)。如果 Leader 副本所在的节点停止提供服务，会导致该分片的读写不可用。为了避免这种情况，Operator 会在 NebulaGraph 集群滚动更新过程中，默认将 Leader 副本迁移到其他未受影响节点上。这样，当一个存储节点处于更新状态时，其他节点上的 Leader 副本能够继续处理客户端请求，以保证集群的读写可用性。 + +一个存储节点上的所有 Leader 副本全部迁移到其他节点的这个过程可能会持续较长时间。为了更好地控制滚动更新的时间，Operator 提供了一个名为`enableForceUpdate`参数。当确定没有外部访问流量时，可将该参数设置为`true`，这样，Leader 副本将不会被迁移到其他节点上，从而加快滚动更新的速度。 + +## 滚动更新触发条件 + +Operator 会在以下情况下触发 NebulaGraph 集群的滚动更新： + +- NebulaGraph 集群的版本发生变化。 +- NebulaGraph 集群的配置发生变化。 + +## 配置滚动更新策略 + +在创建集群实例的 YAML 文件中，添加`spec.storaged.enableForceUpdate`参数，设置为`true`或`false`，以控制滚动更新的速度。 + +当`enableForceUpdate`为`true`时，表示不迁移分片 Leader 副本，从而加快滚动更新的速度；反之，表示迁移分片 Leader 副本，以保证集群的读写可用性。默认值为`false`。 + +!!! caution + + 设置`enableForceUpdate`为`true`时，请确保没有外部访问流量。 + +YAML 文件示例： + +```yaml +... +spec: +... + storaged: + enableForceUpdate: true // 设置为 true 时，加快滚动更新的速度。 + ... +``` + + diff --git a/docs-2.0/nebula-operator/9.upgrade-nebula-cluster.md b/docs-2.0/nebula-operator/9.upgrade-nebula-cluster.md index 95adc9ce69d..3e26c5c6464 100644 --- a/docs-2.0/nebula-operator/9.upgrade-nebula-cluster.md +++ b/docs-2.0/nebula-operator/9.upgrade-nebula-cluster.md @@ -203,3 +203,7 @@ 1 vesoft/nebula-metad:{{nebula.tag}} 3 vesoft/nebula-storaged:{{nebula.tag}} ``` + +## 加速升级过程 + +集群的升级过程是一个滚动更新的过程也是耗时的过程，因为 Storage 服务的 Leader 分片副本会进行状态转移。用户可在集群实例的 YAML 文件中配置`enableForceUpdate`参数，来略过 Leader 分片副本转移操作，以达到加速升级的过程。详情参见[滚动更新策略](11.rolling-update-strategy.md)。 \ No newline at end of file diff --git a/mkdocs.yml b/mkdocs.yml index 43f89a8c2e5..665c820cd5f 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -713,15 +713,16 @@ nav: - 部署 NebulaGraph: - 使用 Kubectl 部署 NebulaGraph 集群: nebula-operator/3.deploy-nebula-graph-cluster/3.1create-cluster-with-kubectl.md - 使用 Helm 部署 NebulaGraph 集群: nebula-operator/3.deploy-nebula-graph-cluster/3.2create-cluster-with-helm.md + - 连接 NebulaGraph: nebula-operator/4.connect-to-nebula-graph-service.md - 配置 NebulaGraph: - 自定义 NebulaGraph 集群的配置参数: nebula-operator/8.custom-cluster-configurations/8.1.custom-conf-parameter.md - 回收 PV: nebula-operator/8.custom-cluster-configurations/8.2.pv-reclaim.md #ent - 均衡扩容后的 Storage 数据: nebula-operator/8.custom-cluster-configurations/8.3.balance-data-when-scaling-storage.md - - 升级 NebulaGraph: nebula-operator/9.upgrade-nebula-cluster.md - - 连接 NebulaGraph: nebula-operator/4.connect-to-nebula-graph-service.md -#ent - - 备份与恢复: nebula-operator/10.backup-restore-using-operator.md + - 升级 NebulaGraph: nebula-operator/9.upgrade-nebula-cluster.md + - 滚动更新策略: nebula-operator/11.rolling-update-strategy.md +#ent + - 备份与恢复: nebula-operator/10.backup-restore-using-operator.md - 故障自愈: nebula-operator/5.operator-failover.md - 常见问题: nebula-operator/7.operator-faq.md From 6da5a6b0cee4564907601b20f1b5d259c7f18e18 Mon Sep 17 00:00:00 2001 From: Abby <78209557+abby-cyber@users.noreply.github.com> Date: Thu, 16 Mar 2023 15:46:07 +0800 Subject: [PATCH 2/5] change doc title --- docs-2.0/nebula-operator/9.upgrade-nebula-cluster.md | 2 +- mkdocs.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs-2.0/nebula-operator/9.upgrade-nebula-cluster.md b/docs-2.0/nebula-operator/9.upgrade-nebula-cluster.md index 3e26c5c6464..1d9c1ca41bc 100644 --- a/docs-2.0/nebula-operator/9.upgrade-nebula-cluster.md +++ b/docs-2.0/nebula-operator/9.upgrade-nebula-cluster.md @@ -206,4 +206,4 @@ ## 加速升级过程 -集群的升级过程是一个滚动更新的过程也是耗时的过程，因为 Storage 服务的 Leader 分片副本会进行状态转移。用户可在集群实例的 YAML 文件中配置`enableForceUpdate`参数，来略过 Leader 分片副本转移操作，以达到加速升级的过程。详情参见[滚动更新策略](11.rolling-update-strategy.md)。 \ No newline at end of file +集群的升级过程是一个滚动更新的过程也是耗时的过程，因为 Storage 服务的 Leader 分片副本会进行状态转移。用户可在集群实例的 YAML 文件中配置`enableForceUpdate`参数，来略过 Leader 分片副本转移操作，以达到加速升级的过程。详情参见[配置滚动更新策略](11.rolling-update-strategy.md)。 \ No newline at end of file diff --git a/mkdocs.yml b/mkdocs.yml index 665c820cd5f..0de4139869d 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -720,7 +720,7 @@ nav: #ent - 均衡扩容后的 Storage 数据: nebula-operator/8.custom-cluster-configurations/8.3.balance-data-when-scaling-storage.md - 升级 NebulaGraph: nebula-operator/9.upgrade-nebula-cluster.md - - 滚动更新策略: nebula-operator/11.rolling-update-strategy.md + - 配置滚动更新策略: nebula-operator/11.rolling-update-strategy.md #ent - 备份与恢复: nebula-operator/10.backup-restore-using-operator.md - 故障自愈: nebula-operator/5.operator-failover.md From ddb2fe24b0a93aa824c383911a75e09a8c479a20 Mon Sep 17 00:00:00 2001 From: Abby <78209557+abby-cyber@users.noreply.github.com> Date: Thu, 16 Mar 2023 17:24:10 +0800 Subject: [PATCH 3/5] Update 11.rolling-update-strategy.md --- docs-2.0/nebula-operator/11.rolling-update-strategy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs-2.0/nebula-operator/11.rolling-update-strategy.md b/docs-2.0/nebula-operator/11.rolling-update-strategy.md index 72fb055b868..b9b717e1a0a 100644 --- a/docs-2.0/nebula-operator/11.rolling-update-strategy.md +++ b/docs-2.0/nebula-operator/11.rolling-update-strategy.md @@ -1,6 +1,6 @@ # NebulaGraph 集群的滚动更新策略 -NebulaGraph 集群使用分布式架构将数据分成多个逻辑分片，每个分片存储在不同的节点上。分布式系统中，同一份数据通常会有多个副本。为了保证多个副本数据的一致性，NebulaGraph 集群使用 Raft 协议实现了多分片副本同步。Raft 协议中，每个分片都会选举出一个 Leader 副本，Leader 副本负责处理写请求，Follower 副本负责处理读请求。 +NebulaGraph 集群使用分布式架构将数据分成多个逻辑分片，这些分片通常均分在不同的节点上。分布式系统中，同一份数据通常会有多个副本。为了保证多个副本数据的一致性，NebulaGraph 集群使用 Raft 协议实现了多分片副本同步。Raft 协议中，每个分片都会选举出一个 Leader 副本，Leader 副本负责处理写请求，Follower 副本负责处理读请求。 通过 Operator 创建的 NebulaGraph 集群在滚动更新过程中，一个存储节点会暂时停止提供服务以进行更新。关于滚动更新的概述，参见[执行滚动更新](https://kubernetes.io/zh-cn/docs/tutorials/kubernetes-basics/update/update-intro/)。如果 Leader 副本所在的节点停止提供服务，会导致该分片的读写不可用。为了避免这种情况，Operator 会在 NebulaGraph 集群滚动更新过程中，默认将 Leader 副本迁移到其他未受影响节点上。这样，当一个存储节点处于更新状态时，其他节点上的 Leader 副本能够继续处理客户端请求，以保证集群的读写可用性。 @@ -23,7 +23,7 @@ Operator 会在以下情况下触发 NebulaGraph 集群的滚动更新： 设置`enableForceUpdate`为`true`时，请确保没有外部访问流量。 -YAML 文件示例： +配置示例： ```yaml ... From 18c971ddaac306832b90662e1147e72e3147af4a Mon Sep 17 00:00:00 2001 From: Abby <78209557+abby-cyber@users.noreply.github.com> Date: Thu, 16 Mar 2023 17:54:16 +0800 Subject: [PATCH 4/5] Update 8.2.pv-reclaim.md --- .../8.custom-cluster-configurations/8.2.pv-reclaim.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs-2.0/nebula-operator/8.custom-cluster-configurations/8.2.pv-reclaim.md b/docs-2.0/nebula-operator/8.custom-cluster-configurations/8.2.pv-reclaim.md index 60a1b3be2ee..ffcb6cdb3de 100644 --- a/docs-2.0/nebula-operator/8.custom-cluster-configurations/8.2.pv-reclaim.md +++ b/docs-2.0/nebula-operator/8.custom-cluster-configurations/8.2.pv-reclaim.md @@ -2,7 +2,7 @@ NebulaGraph Operator 使用持久化卷 PV（Persistent Volume）和持久化卷声明 PVC（Persistent Volume Claim）来存储持久化数据。如果用户不小心删除了一个 NebulaGraph 集群，默认 PV 和 PVC 对象及其数据仍可保留，以确保数据安全。 -用户也可以在集群实例的配置文件中通过设置参数`spec.enablePVReclaim`为`true`来定义在删除集群后自动删除 PVC 以释放数据。至于在删除 PVC 后是否删除 PV，用户需要自定义 PV 的回收策略。参见 [StorageClass 中设置 reclaimPolicy](https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy)和 [PV Reclaiming](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming) 了解 PV 回收策略。 +用户也可以在集群实例的配置文件中通过设置参数`spec.enablePVReclaim`为`true`来定义在删除集群后自动删除 PVC 以释放数据。至于在删除 PVC 后是否删除 PV，用户需要自定义 PV 的回收策略。参见 [StorageClass 中设置 reclaimPolicy](https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy) 和 [PV Reclaiming](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaiming) 了解 PV 回收策略。 ## 前提条件 From 3915f3e65845e85527c46671c312d732dc8f99fa Mon Sep 17 00:00:00 2001 From: Abby <78209557+abby-cyber@users.noreply.github.com> Date: Fri, 17 Mar 2023 13:46:55 +0800 Subject: [PATCH 5/5] Update 11.rolling-update-strategy.md --- docs-2.0/nebula-operator/11.rolling-update-strategy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs-2.0/nebula-operator/11.rolling-update-strategy.md b/docs-2.0/nebula-operator/11.rolling-update-strategy.md index b9b717e1a0a..cc7d5ea0a07 100644 --- a/docs-2.0/nebula-operator/11.rolling-update-strategy.md +++ b/docs-2.0/nebula-operator/11.rolling-update-strategy.md @@ -21,7 +21,8 @@ Operator 会在以下情况下触发 NebulaGraph 集群的滚动更新： !!! caution - 设置`enableForceUpdate`为`true`时，请确保没有外部访问流量。 + 设置`enableForceUpdate`为`true`时，确保没有流量进入集群进行读写操作。因为该设置会强制重建集群 Pod，此过程会发生数据丢失或客户端请求失败的情况。 + 配置示例：