diff --git a/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_Best_Practices_for_Deploying_OceanBase_on_K8s.md b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s.md similarity index 96% rename from docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_Best_Practices_for_Deploying_OceanBase_on_K8s.md rename to docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s.md index aaaf2d438..488d15d6a 100644 --- a/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_Best_Practices_for_Deploying_OceanBase_on_K8s.md +++ b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s.md @@ -1,5 +1,5 @@ --- -title: 在 K8S 上部署 OceanBase 的最佳实践 +title: 在 K8S 上部署 OceanBase 实践 weight: 2 --- > 本文作者：美的集团软件工程院 陈子鎏（OceanBase 社区论坛账号：@qchenzi） @@ -187,13 +187,13 @@ spec: ``` 部署完成后，如下图所示： -![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/001.png) +![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/001.png) **通过 OBProxy 访问 OB 集群**： 此时，可以通过 OBProxy 的 Service 提供 OB 数据库的访问入口，如下（obmysql 是我提前创建好的租户，testdb 是提前在 obmysql 下创建的用户）： -![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/002.png) +![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/002.png) 当然，在实际的生产中，我们采用的是域名访问的方式，而不是通过 IP 地址访问，因此需要进行域名重写，可看下一小节。 @@ -260,7 +260,7 @@ spec: 6. **如图所示**： - 直接通过域名即可访问，而不用关心 obproxy 的 service ip，进一步加强了集群的高可用能力 -![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/003.png) +![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/003.png) ### 2.6 监控与运维 @@ -305,21 +305,21 @@ svc-prometheus NodePort 12.80.144.38 9090:30090/TCP 7 2. 在 `Add data source` 页面，选择 `Prometheus` 作为数据源类型。 3. 在 `Prometheus` 页面，填写 `Name` 为 `ob-prometheus`，`URL` 为 `http://12.80.144.38:9090`(即上面的promethues对应的svc ip)，然后单击 `Save & Test` 按钮。 -![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/004.png) +![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/004.png) ##### 2.6.2.2 配置 Grafana Dashboard 1. 新建一个名为 OceanBase 的文件夹 -![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/005.png) +![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/005.png) 2. 进入该文件夹，接着导入文件链接：[grafana.yaml](https://github.com/oceanbase/ob-operator/blob/2.3.1/example/webapp/grafana.yaml) 中的grafana-dashboards-ob部分的json配置 -![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/006.png) +![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/006.png) 3. 监控展示如图 -![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/007.png) +![img](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/007.png) ## 3. 部署中遇到的问题及解决方案 diff --git a/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/03_misoperation_recovery.md b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/03_misoperation_recovery.md index 8673a172f..2d68fc27a 100644 --- a/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/03_misoperation_recovery.md +++ b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/03_misoperation_recovery.md @@ -4,8 +4,10 @@ weight: 3 --- > 本文作者：张瑞远（OceanBase 社区论坛账号：@五月） -> 在数据库管理中，误操作是一个常见但令人头疼的问题。无论是意外删除了重要数据、修改了关键配置，还是执行了错误的 SQL 语句，这些误操作都可能导致业务中断或数据丢失。幸运的是，OceanBase 提供了一系列机制和工具来帮助我们从误操作中恢复。本文将介绍几种有效的恢复方法，为那些可能犯错的管理员们提供一份 “后悔药”。 -> +在数据库管理中，误操作是一个常见但令人头疼的问题。无论是意外删除了重要数据、修改了关键配置，还是执行了错误的 SQL 语句，这些误操作都可能导致业务中断或数据丢失。 + +幸运的是，OceanBase 提供了一系列机制和工具来帮助我们从误操作中恢复。本文将介绍几种有效的恢复方法，为那些可能犯错的管理员们提供一份 “后悔药”。 + ## 一、备份与还原 ### 1.1 定期备份的重要性 @@ -124,11 +126,9 @@ ROLLBACK TO SAVEPOINT pointname; 该方法可以紧急拉起单副本，但是要尽快备份数据，或者修复集群！ - **单副本拉起这个方法不是官方的标准操作，有很多风险（例如多数派挂了，有可能在剩余的副本上看到的已经不是最新的数据了）。这个方法是标准意义上的 “奇技淫巧”，大家了解即可。** - ## 七、预防措施 最后，除了事后补救外，还需要加强事前预防。这包括但不限于： diff --git a/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction.md b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction.md new file mode 100644 index 000000000..dbc3f4790 --- /dev/null +++ b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction.md @@ -0,0 +1,207 @@ +--- +title: OceanBase 空间缩容实践 +weight: 5 +--- +> 本文作者：庆涛（OceanBase 社区论坛账号：@obpilot） + +0B 区别于其他数据库的一个特点是它的多租户和资源管理技术。这点很多人在初次部署 OB 时就发现了。比如说机器资源不够的时候，OB 启动会失败。OB 启动后，没有业务数据的情况下就占用磁盘大量空间等。这其中的细节原理在以前很多关于 OB 部署的文章里都有解释。 + +本文就解决一个问题，如何对 OB 的数据文件进行缩容。 + +## 1. OB 空间资源分配原理和实践 +在对数据文件进行缩容之前，首先要了解 OB 的空间资源分配原理。 + +OB 架构独特之一是多租户，设计思想是在多台无共享架构下的 PC 服务器上运行 OB 进程,攫取主机的主要资源组件为一个数据库资源池（集群），然后从集群里分配自定义的资源以租户（实例）形式给用户使用。所以 OB 部署后即使没有业务也会占用大量内存和磁盘空间。内存资源的使用以前已经介绍过原理，本文主要介绍空间资源。OB 进程（名字：`observer`）对空间资源的使用是分为三部分：运行日志、数据文件、事务日志文件。 + +### 1.1 OB 运行日志 +默认在 OB 软件安装目录下的 `log`里。企业版默认路径是：`/home/admin/oceanbase/log` 。OB 进程的运行日志（`observer.log`、`rootservice.log`）内容非常多，根据日志级别可以调整。日志内容主要是面向 OB 内核开发的，对普通用户可读性很差，还占用空间。生产环境建议为此预留 `300+G` 的空间，不然出问题的时候查不到日志（被清理了）就很麻烦。随着 OB 版本的迭代，OB 逐步在丰富这个日志文件的管理策略。除了可以控制日志级别、日志数量，近期版本还可以对过往日志进行压缩（压缩比高达`10:1`）。 + +![示例图片](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction/001.png) + + +上面是一些关键配置供参考，有兴趣的可以查阅官网。可以在进程初始化时指定，也可以事后修改。 + +### 1.2 OB 数据文件 +OB 进程只有一个数据文件，文件的大小就看你给的文件系统有多大空间，从几个 G 到几十 T 都行。OB 早期研发设计的时候觉得一个文件编程方便。现在看来对运维也非常方便。不管你的 OB 是怎么部署，OB 在每个节点上的进程只有一个数据文件。这个文件的大小通过三个参数控制： + ++ `datafile_size`:数据文件初始大小。 +如果你不希望 OB 一开始就占用很多空间，这个值就不要太大。生产可以 `100G` 起步。 ++ `datafile_disk_percentage`:数据文件初始大小占文件系统可用空间比例。 +早期 OB 版本这个参数默认 90% 。这个参数跟上面参数二选一。如果两个参数都不设置（为0），那么 OB 又取了 90% 的默认值。这就是为什么大部分人部署 OB 后空间使用很大导致剩余空间不足。 ++ `datafile_next`：数据文件增长一次增长的大小，默认是 0 表示不增长。这个还是要设置的，一般设置为 1G 就行。 ++ `datafile_maxsize`：数据文件最大大小，数据文件可以增长，但不能无限制增长，一定要设置一个文件系统能接受的大小。这个参数可以变大或变小，但是不能比当前的数据文件大小要小。也就是说，OB 的数据文件实际大小只能变大不能变小。 + +最佳实践：OB 进程启动的时候设置 `datafile_size` 初始大小（如 10G10G），设置数据文件最大大小 `datafile_maxsize`（如 500G~20T，在文件系统空间可以接受的范围内）。当 OB 数据文件增长后，就不能通过调整数据文件参数来缩小其大小，后面会介绍如何对数据文件进行缩容。 + +缩容之前也需要计算一下当前数据文件中实际使用空间大小，可以在 OCP 的集群的资源管理页面里查看已使用的日志空间和数据文件空间，或者用下面 SQL 查询也可以。 + +```sql +select a.svr_ip, + round(sum(a.data_disk_in_use)/1024/1024/1024 ) data_disk_use_G, + round(sum(a.log_disk_in_use)/1024/1024/1024 ) log_disk_use_G +from oceanbase.__all_virtual_unit a,oceanbase.dba_ob_tenants b +where a.tenant_id=b.tenant_id +group by svr_ip ; +``` + +### 1.3 OB 事务日志文件 +OB 的其他日志文件还有`slog`和`clog`。`slog` 是数据文件的索引，而`clog`是跟 OB 的事务有关，也是传统意义上的`redolog`。OB 从1.x~3.x，所有租户的事务日志是混合在一起的，OB 4.x 推出日志流 LS 功能后，事务日志按租户存放，并且日志流的粒度从以前的分区（分区组）扩大到近似租户粒度（每个租户下默认内部表一个日志流，业务表一个日志流）。日志流起始可以理解为 OB 数据同步方向的最小单位。所以当 OB 将主可用区（`primary_zone`）从单`zone`变更为多`zone`后，就会多出 1-2 个日志流。当使用复制表后，还会额外多出一个日志流（复制表的同步策略不是 `Paxos` 多数派同步，而是全同步）。 + +OB 4.x 后 OB 进程总的事务日志空间是通过下面两个参数控制： + ++ `log_disk_size` : 进程初始化后会预分配的日志目录空间大小（可以立即为日志资源池）。具体形式就是目录下`/data/log1/obdemo/clog/log_pool`有很多固定大小（64MB）的日志文件。 ++ `log_disk_percentage` : 作用跟上面一样，只不过是按文件系统可用空间比例控制的。 + +OB 在创建租户的时候，租户要指定 `log_disk_size`，其大小就是从 OB 进程的日志资源池（`log_pool`目录）里分配。如果进程的日志空间资源不足，租户资源池就分配报错。OB 租户在拿到确定的日志空间后，就在租户内部循环利用这个空间。OB 的 `clog` 内部使用可以循环覆盖。不过也存在一些场景下事务的 `clog` 由于还被需要不能被覆盖。这个原理很好理解，场景却非常多。这里就不列举了。一般来说尽量减少大事务、OB 每日合并和备份要正常、设置适当的数据文件转储参数。 + +![示例图片](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction/002.png) + +OB 租户的事务日志空间是可以在线调整的（变大或变小）。变小的时候，租户会将这部分空间归还给集群的日志空间池子。变小的前提也是对应的`clog`可以释放掉。在某些特殊场景下当租户某些事务的`clog`不能释放时，这个变小会失败。最佳实践：租户事务日志空间的大小建议为租户内存资源的 2~4 倍（内存越大，倍数可以越小），这样租户的事务很繁忙的时候瓶颈不会出在 `clog` 空间上。这个空间不要太小（比如说十几 G，这个就有点抠门了。） + +### 1.4 磁盘存储空间分配实践 +OB 部署的时候，上面三个 OB 空间建议使用独立的文件系统目录。有的时候交付会说用不同的盘，盘最终也是要格式化为文件系统并挂载。所以这里说的是独立的文件系统。 + +目录最佳实践如下： + +```bash +/home/ -- 不同的盘或者跟 OS 一起的盘 + |- admin/oceanbase/log -- 运行日志空间 + |- admin/oceanbase/store/obdemo/ + |- sstable -> /data/l/obdemo/sstable -- 数据文件空间 + |- slog -> /data/log1/obdemo/slog + |- clog -> /data/log1/obdemo/clog -- 事务日志空间 +/data/1 --- 不同的盘 +/data/log1 -- 不同的盘 +``` + +如果数据文件跟事务日志文件共用一个文件系统，在空间的分配策略上要先考虑事务日志文件，然后约束数据文件的最大大小，确保数据文件空间的增长不会导致事务日志文件无法分配必要的空间。 + +通常建议前面提到的每个跟文件大小有关的参数都建议明确设置，不要使用默认值。但是如果 OB 机器配置很好（磁盘容量很大），运维的重点根本不在这点磁盘空间上，那可以都使用默认值。 + +## 2 OB 数据文件缩容 +如果一开始没有设置好参数，导致数据文件很大了，要缩容这个数据文件的方法就是重建这个节点。 + +通常通过 OCP 也可以重建一个节点。这个任务会有点长（连软件一并重装了，启动参数沿用集群当前参数）。如果 OCP 任务因为别的原因出错了，OCP 的流程就无法走下去，此时就需要手动重建 OB 节点。 + +手动快速重建三副本架构 OB 集群的一个节点（五副本同理，不适合单副本架构）。利用 OB 部署最基本的原理。即使出错也是能快速应对。这个基本上是三副本 OB 集群里重建某个 OB 节点的最快速的方法。不过，这种方法也有一定操作风险，重建节点的时候三副本缺一个，不再有高可用能力。如果集群架构是 `2-2-2` ，操作起来会更稳妥一些，但是这个会触发 OB 内部两次数据迁移的过程。如果是集群架构是 `1-1-1`，则操作期间不能出现其他节点故障。 + +所以，这个 OB 节点数据文件缩容的方法属于高级技巧，谨慎使用。在执行之前也建议先回顾一下 OB 集群的手动部署过程和原理。这里就不再重复。 + +接下来就是 OB 数据文件缩容的步骤。 + +### 2.1 OB 集群合并 +为了降低操作风险，做之前先对整个 OB 集群发起一次合并。这一步是可选的操作，建议做。 + +```sql +mysql -h10.0.0.65 -uroot@sys#obdemo -P2883 -p -c -A oceanbase +alter system major freeze tenant=all; +``` + +然后等集群所有租户合并完毕。 + +### 2.2 OB 节点下线 +首先要让这个 OB 节点下线（OFFLINE）。这里不需要对 OB 集群去 `stop zone`，而是将 OB 集群节点默认的下线判定时间参数 `server_permanent_offline_time` 从默认值 `3600s` 改为 `300s` 。当然修改的时候只改这个节点的参数。方法如下。 + +```bash +mysql -h10.0.0.65 -uroot@sys#obdemo -P2883 -p -c -A oceanbase +alter system set server_permanent_offline_time='300s' server = '10.0.0.65:2882'; +``` + +然后停掉这个节点进程。 + +```bash +kill -9 `pidof observer` +``` + +5 分钟后， OB 集群就会判定这个节点永久下线，开始从集群里删除节点上对应的副本登记信息。通过观察 OB 集群的事件表 __all_rootservice_event_history 可以确认这个过程。 + +```sql +select gmt_create ,module,event,name1,value1,name2,value2,name3,value3,name4,value4 +from oceanbase.__all_rootservice_event_history +where 1=1 + and module in ('disaster_recovery') -- and event like 'disaster_recovery%' +order by gmt_create desc limit 500; +``` + +结果记录里会出现下列事件： + ++ `disaster_recovery_start` ++ `start_remove_ls_paxos_replica` ++ `finish_remove_ls_paxos_replica` + +### 2.3 清理 OB 相关目录 +这一步就非常重要。我们的目的只是重建数据文件，不是重装 OB 软件。所以要保留 OB 软件介质，软件相关目录，以及 OB 进程原来的启动参数文件 `etc/observer.config.bin` ，清除掉上次运行文件、运行日志文件等（清理干净，否则影响后面进程启动）。 + +具体方法如下： + +```bash +cd /home/admin/oceanbase +/bin/rm -rf audit/* run/* log/* +/bin/rm -rf /data/{1,log1}/obdemo/*/* +``` + +这里删除的路径非常有讲究,如果你少写一个 `*` 可能导致路径多删除了。那么你就要按照前面手动部署的方法补充好数据文件目录和事务日志目录的拓扑。所以，事先要记录一个正常的 OB 节点的数据文件和事务日志文件布局。这里是要保持目录结构，删除目录下的实际文件。如果你不确认，就将 `/bin/rm -rf` 替换为 `/bin/rm -ri` 一一确认删除的文件。 + +### 2.4 再次启动 OB 进程 +此时，只需要启动 OB 进程，由于前面保留了上次启动参数，这次就不用指定完整的启动参数（如果参数文件被删除了，那就要指定完整的启动参数，具体参考手动部署时拉起 OB 进程的参数并且将参数改为实际 OB 集群的参数。具体的参数就要去查看其他 OB 节点的参数文件了）。 + +这里一定要修改的参数是重新指定数据文件的初始大小参数 `datafile_size`。这个才是我们重建 OB 节点的目的。这里指定的初始大小尽量能够容纳当前集群里的业务数据量，否则 OB 进程还是会自动扩展数据文件大小。当然也可以重新制定参数 `datafile_maxsize` + +下面启动示例： + +```bash +su - admin +cd oceanbase && bin/observer -o "datafile_size=100G,datafile_next=1G,datafile_maxsize=1000G" +``` + +很快用 `df -h` 命令就能看到数据文件目录已使用空间就变为 100G 了。 + +### 2.5 等待 OB 自动补齐数据 +上面只是 OB 进程启动了，OB 还要在节点上自动补齐数据。这个过程时间的长短就看节点要承载的数据量有多大了。补数据的原理是 OB 发现三副本数据不全，根据租户的 `locality` 设置自动补齐当前节点的数据，数据复制来源是另外一个备副本。如果是 `2-2-2` 架构的集群，则是 OB 的负载均衡机制发挥作用。 + +可以通过观察 OB 集群的事件表来观察 OB 补齐副本数据的过程。 + +```bash +select gmt_create ,module,event,name1,value1,name2,value2,name3,value3,name4,value4 +from oceanbase.__all_rootservice_event_history +where 1=1 + and module in ('disaster_recovery') -- and event like 'disaster_recovery%' +order by gmt_create desc limit 500; +``` + +此时会看到日志流副本补充恢复的记录。事件包含： + ++ `start_add_ls_replica` ++ `finish_add_ls_replica` ++ `disaster_recovery_finish` + +恢复记录有租户级别的和全局级别的。一定要等到全局级别的恢复成功记录。恢复的过程中，会从其他备副本节点拉取数据，网络流量会比较大（默认网络占用比例由集群参数 `sys_bkgd_net_percentage` 设置），磁盘写吞吐也会比较高。 + +在上面的等待过程中，还有个关键步骤就是将永久离线时间参数改回去。不然，以后节点正常重启如果耗时过久，也会触发 OB 清理副本和重建副本的动作。 + +```sql +alter system set server_permanent_offline_time='3600s' server = '10.0.0.65:2882'; +``` + +### 2.6 数据验证 +注意： 一定要准确判断节点重建成功这个事件。特别是当你的目的是要挨个将三副本所有节点的数据文件缩容。如果一个节点副本没有重建完成 就开始做第二个节点了，将会人为导致多数派故障，也就没有了高可用能力，并且丢失了集群全部或部分数据。 + +所以，下面这个方法最终也要辅助判断一下。将业务租户的主可用区（`primary_zone`）都切换到重建节点所在节点上，如果查看日志流 LS 的主副本也在该节点上保持不变了，则说明 OB 在该节点上重建成功。 + +```sql +select MODIFY_TIME, tenant_id, ls_id, svr_ip,zone,role,MEMBER_LIST,PAXOS_REPLICA_NUMBER,REPLICA_TYPE,REBUILD +from CDB_OB_LS_LOCATIONS where role in ('LEADER'); +``` + +还有个办法就是租户数据切换到重建节点后，验证一下业务读写正常。 + +至此，一个 OB 节点的数据文件缩容成功。然后就可以做下一个节点。整个过程不用依赖 OCP 。 + +## 3. 总结 +上面就是 OB 数据文件缩容的原理和步骤，只适合三副本（以及以上）的 OB 集群，其原理是重建节点的数据。在重新拉起 OB 进程时重新指定缩容后的数据文件大小。数据修复的过程是 OB 内部自动的。数据文件缩容后，如果用户还要缩容文件系统，那就是操作系统和 LVM 的知识了。 + +更多阅读参考： + ++ [OB 4.2 手动部署实践](https://mp.weixin.qq.com/s/Zs0qwXKUT78JISxpuzXgbQ) ++ [OB 4.2 资源隔离原理](https://mp.weixin.qq.com/s/VwOEot4UGMWA899j13YAUQ) + diff --git a/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment.md b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment.md new file mode 100644 index 000000000..ebafe248d --- /dev/null +++ b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment.md @@ -0,0 +1,99 @@ +--- +title: 云服务器上 OceanBase 部署实践 +weight: 6 +--- +> 本文作者：庆涛（OceanBase 社区论坛账号：@obpilot） + +OB 官网文档对生产环境 OB 部署环境服务器给出指导配置，大部分企业客户都能够接受这个配置要求。少数客户的 IT 基础设施使用了超融合技术或者云的虚拟化技术，初次使用 OB 的时候不能给出物理服务器。还有一部分原因是有些客户出于 POC 或者试用看看的目的。 + +本文主要分享云服务器或虚拟机环下境部署 OB 一些实践经验。 + +## 云服务器环境分析 +云服务器的原理是云厂商将一批高配物理服务器的资源聚合为一个资源池，然后从中分出不同规格的云虚拟机。 + +大部分云服务器并不独占物理服务器的资源。云服务器的资源包括 CPU、内存、存储和网络。这些资源都有明确的规格定义，云厂商使用资源隔离技术去保障每个云服务器的资源的 QOS。 + +云服务器存储使用的多是云盘（只有阿里云少数高配云服务器配有本地 NVMe SSD）。云盘容量可以在线扩展，不同容量和类型的云盘对应的 IOPS、吞吐量和读写耗时都不一样。这其中读写耗时对数据库性能影响最大。 + +在部署 OB 之前建议先使用 FIO 对云盘性能进行测试。测试场景建议包括 4KB、2MB 的顺序写 IO 和 16K 的随机读 IO 。FIO 测试期间观察云盘读写 IOPS 、吞吐量(`bw`和时延（`latency`)。使用 `iostat` 命令也可以检测 IO i性能，重点观察 `rawait`、`wawait`和 `svctm` 。一般来说云盘在一定并发下的 `svctm` 如果超过`1ms`，那性能就离 NVMe SSD 性能差很多，部署 OB 后高并发读写场景下性能大概率也不会好。 + +云盘还有个能力就是可以在线扩容和缩容（重点是扩容）。OB 的部署对服务器需求里存储使用的是本地文件系统，OB 倾向于一次性锁定存储空间资源。所以云盘扩容后，新增的容量要体现在 OB 里还需要在磁盘分区、文件系统上做一些相应的扩容命令。 + +云服务器的网卡一般只有一块，除非你额外配置多个网卡。这个网卡也是虚拟网卡，云的技术会保证这个虚拟网卡链路的高可用，这点不像物理服务器要做双网口绑定技术。云服务器的虚拟网卡的带宽是有限制的，不一定有 10Gb，这点可以通过网络工具 `iperf` 压测网络和`iftop`监测网卡上下行带宽。如果云服务器的网卡带宽太低，也可能会制约 OB 服务器之间数据传输性能。OB 节点进程启动时也会判断网卡的速率，依赖的是操作系统的技术。在物理服务器上，少数国产系统或者少数不常用的网卡可能都会导致 OB 判断网卡速率失败。这个概率比较低。但是在云服务器上，虽然操作系统被 OB 兼容，虚拟网卡的速率操作系统却可能无法给出，导致 OB 判断网卡速率失败，OB 会选择按默认带宽（`1000Mb`）来计算。这个会限制 OB 节点传输时对网卡吞吐的利用率。 + +云服务器还有热迁移的能力（至少阿里云一早就有这个能力），指的是在线迁移云服务器到其他物理服务器上。云服务器的数据都在云盘上，所以换一个云服务器没什么问题。这里最关键的是 IP 不要变，因为 OB 不能接受节点 IP 变化。云服务器如果更换了 IP 对 OB 意味着是老 IP 节点掉线，新 IP 节点不被集群承认（需要清空数据，走新节点初始化流程加入到 OB 集群中）。 + +超融合或者 VMWare 等虚拟化平台做出的虚拟机也可能有上面类似的特点。 + +## 云服务器部署建议 +OB 部署环境不推荐云服务器，主要是为性能考虑。不过性能是跟业务需求期望相关。想在云盘上跑出本地盘（NVMe SSD）那样的性能，这个是妄想。撇开这个妄想外，OB 部署在云服务器上也是可以的。OB 技术本身并不限制存储的类型，更何况公有云 OB 也是运行在云服务器上。只要我们规避上面云盘和云虚拟网卡的那个问题就行。 + +### 云盘性能提升方法 +评估云盘的资源时大部分用户首先是从容量需求方面考虑，这个最容易计算。此外就是 IOPS 和吞吐，很多人都说不出业务需要多少数据库 IOPS 和吞吐。这个是正常的，即使在以前传统数据库规划里，这个 IOPS 评估也很难准确给出，都是拍脑袋。业务 SQL 写的好，大部分数据读写都走索引，数据库 IOPS 需求就低，带宽也低；SQL 写的不好，都是全表扫描，IOPS 和带宽需求就高。云盘一般有几万的 IOPS，这是够还是不够呢？实际使用经验表明这个够用了，云盘的问题并不出现在 IOPS 和吞吐上，而是 IO 时延上。 + +云盘的单块盘的小 IO 的时延在高并发时会很差，表现的跟机械盘一样（云厂商看到这个可能会有意见，也可能是因为我看到的客户买的云盘都不好）。但是如果购买多块云盘，使用 LVM 技术聚合在一起然后划分逻辑盘（LV）使用时，在相同的高并发场景下，单块逻辑盘小 IO 的平均时延却可以稳定在 `1ms` 以下，这个时延水平就比 `NVMe SSD` 差一小点，但是比机械盘好很多。这样使用的效果也能做到很好。 + +![示例图片](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment/001.png) + +所以，原本分配了1块 4TB 的云盘，可以调整为分配 10块 400G 的云盘。当然云厂商可能会说这种做法意义不大，云盘本来就是在后端将 IO 打散到多块物理盘上。这个说法也有一定道理，但是单盘性能就是有问题这个云厂商解决不了。而采用多块云盘使用 LVM 聚合在一起使用后，性能确实比单盘要好很多。 + +这里面盘的数量就很重要，容量不是首要考虑因素。建议盘的数量在 10 以上，单盘容量也不要少于 400G 。不过有些云厂商对云服务器能挂载的云盘数量也有上限，那就贴近它那个上限去申请。这样才可能最大化发挥云盘的性能。 + +多块云盘使用 LVM 技术时也有讲究。聚合为一个 VG 就可以，然后从 VG 里分出两个 LV ，分别给 OB 的事务日志和数据文件。 OB 的软件目录不要跟这个云盘混用。这里先定事务日志 LV 的大小，基本上是内存大小的 3512G ,那够生产环境用了。否则后期内存如果还扩容，需要考虑这个事务日志空间是否够。所以这里事务日志空间的大小也不要太小（在内存很小的时候）.除去给事务日志目录(`/data/log1`） ，VG 剩下的空间就都给数据文件目录（`/data/log1`）。 + +这里划分 LV 的时候有个关键点就是所有的 LV 都要是条带卷（`stripped`），而不是默认的线性卷，这样才可能做到将 IO 分散到所有的云盘上。这也是逻辑盘时延水平很低的关键原因。 + +下面是两个示例。`-i` 是 `pv`的数量（也是所用云盘的数量）,`-I` 是条带大小，官网给出的日志盘的条带是 `128B`，数据盘是 `1024B` 。这里条带大小多少最优我没有做过测试。 + +```bash +lvcreate -i 12 -I 1024 -l 100%free -n lv_oblog vgob +lvcreate -i 12 -I 128 -L 2048G -n lv_obdata vgob +``` + +LVM 划分正确的情况下，看云服务器的本地文件系统，大概类似下图。 + +![示例图片](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment/002.png) + +## 网卡速率设置 +OB 节点进程 `observer` 启动时会优先从 `{WORK_DIR}/etc/nic.rate.config` 配置文件中获取网卡速率的设置，如果该配置文件不存在，OceanBase 会尝试从操作系统查询网卡速率。 如果以上两者都无法获取到网卡速率时，则会采用默认配置。该配置往往因为和实际不符，导致迁移复制的时候网速很慢，主备库延迟过高，进而产生严重问题。OB 运行日志如果频繁提示类似下面信息，就属于这种情形。 + +```bash +[2024-10-08 08:58:04.565648] WDIAG [SERVER] get_network_speed_from_sysfs (ob_server.cpp:2692) [3760825][ServerGTimer][T0][Y0-0000000000000000-0-0] [lt=4][errcode=-4000] cannot get Ethernet speed, use default(tmp_ret=0, devname=“lo”) +[2024-10-08 08:58:04.565654] WDIAG [SERVER] runTimerTask (ob_server.cpp:3214) [3760825][ServerGTimer][T0][Y0-0000000000000000-0-0] [lt=5][errcode=-4000] ObRefreshNetworkSpeedTask reload bandwidth throttle limit failed(ret=-4000, ret=“OB_ERROR”) +``` + +有多种解决办法，最简单的就是直接构建一个 `nic.rate.config` 文件。文件内容具体格式为 `$(IF_NAME)=$(SPEED)`，SPEED 可以是数字 + 单位，也可以是纯数字，纯数字情况下采用默认单位 Mbps。配置文件示例（任选一种）： + +```bash +bond0=10000 +bond0=10000b +bond0=10000bit +bond0=10000k +bond0=10000kb +bond0=10000kbit +bond0=10000m +bond0=10000mb +bond0=10000mbit +bond0=100g +bond0=100gb +bond0=100gbit +``` + +配置后重启 OBServer 进程，运行日志会有下面提示就表示成功。 + +```bash +[2021-06-10 11:10:49.397019] INFO [SERVER] ob_server.cpp:2018 [72580][0][Y0-0000000000000000-0-0] [lt=8] [dc=0] succeed to init_bandwidth_throttle(sys_bkgd_net_percentage_=60, network_speed=1310720000, rate=786432000): +[2021-06-10 11:14:44.905396] INFO [SERVER] ob_server.cpp:2385 [72582][0][Y0-0000000000000000-0-0] [lt=11] [dc=0] network speed changed(from=1310720000, to=1048576000) +[2021-06-10 11:14:44.905421] INFO [SERVER] ob_server.cpp:2055 [72582][0][Y0-0000000000000000-0-0] [lt=3] [dc=0] succeed to reload_bandwidth_throttle_limit(old_percentage=60, new_percentage=60, network_speed=1048576000, rate=629145600) +``` + +当然这里注意，云服务器的虚拟网卡带宽不一定有 `10Gb`，具体多少要问云厂商。配置的值要贴合实际值。 + +还需要了解的是， OB 传输数据的时候会自己约束后台网络带宽使用比例，参数是：`sys_bkgd_net_percentage`，默认值是 `60`（百分比）。 + +## 总结 +云服务器跟普通服务器的区别就是其资源是虚拟化出来，都有相应的配额。特别是云盘有 IOPS和带宽限制，导致时延水平在高并发下会很差。通过 LVM 将多块云盘合并在一起使用时能有效降低高并发下 OB 数据盘的读写时延，从而提升 OB 的读写性能（缩小跟本地 NVMe SSD 盘的性能差距）。使用超融合技术分配的云服务器也可以采取类似方法来尽可能提升 OB 的读写性能。云服务器的网卡速率可能不能被 OB 识别到，通过写配置文件方式直接告诉 OB 当前网卡速率即可。 + +更多阅读参考： + +- [OB 4.2 SQL 性能抖动诊断案例分享](https://mp.weixin.qq.com/s/wT_qrEHqgOx1SHFpGy9K6g) \ No newline at end of file diff --git a/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment.md b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment.md new file mode 100644 index 000000000..eaf6e5690 --- /dev/null +++ b/docs/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment.md @@ -0,0 +1,113 @@ +--- +title: 利用混闪机型部署 OceanBase 集群的探索与实践 +weight: 7 +--- +> 本文作者：联通研究院 邱永刚 + +目前生产环境 OceanBase 数据库集群部署一般要求磁盘类型为 SSD 存储，OB 的存储高压缩比，大大节省了磁盘存储空间，但面对海量历史归档库等场景，仍存在存储不够用、计算资源浪费等问题。本文探讨了混闪机型（事务日志盘采用纯 SSD，数据盘采用机械硬盘）的可行性，通过详尽的验证过程，得出不同规格、不同场景下混闪机型相对纯闪机型的性能损耗及稳定性表现。同时结合生产环境的实际应用案例，为海量数据场景下部署 OceanBase 提供了参考。 + +在满足业务稳定性、性能要求的前提下，使用混闪机型进行部署，可大大降低硬件资源使用量、解决纯闪机型资源不足、存量资源无法使用等问题。 + +## **背景** +OceanBase 数据库的存储引擎基于 LSM-Tree 架构，基线数据存磁盘，增量数据直接写内存。当内存的增量数据达到一定阀值时，会触发增量数据落盘（转储），同时每天晚上的空闲时刻，系统也会自动进行全局动静数据的归并，生成基线数据（合并）。通过这种准内存的增量数据处理，可以大大提升增量数据增删改的性能。另外，由于基线数据是只读的，可以采用比较激进的压缩算法，在不损失查询性能的条件下，可以做到很高的压缩比。为了保证数据的持久性，在增量数据写内存的同时会将 redo_log 落盘并同步给从副本，满足多数派成功落盘的情况下事务才是成功的，同时转储合并也会有集中的磁盘 IO 操作，为了保证数据库的高性能，OB 官方会要求使用 SSD 存储来部署集群。 + +根据我们的理解，使用 SSD 存储主要是为了提高性能，有一些应用对性能要求并不高，所以我们之前也部署了一些机械盘的集群。在运行一段时间之后，陆续出现了一些 clog 不同步、集群不稳定，甚至于集群瘫痪的问题，为此我们也及时进行了固态盘的替换，但我们也一直没有停止对机械盘部署的探索。在看到 OB 官网发表的《[数据库历史库，成本与性能不可以兼得吗？](https://open.oceanbase.com/blog/12198675456)》文章后，我们了解到使用机械盘来部署 OB 也是可行的，于是我们也及时与文章作者进行了沟通，了解到了详细的使用场景与部署方式，得知对数据实时性要求较高的事务日志使用固态盘部署，数据盘使用机械盘部署的方案是可行的，于是，我们对这种混闪机型部署方式进行了验证。以下是详细验证过程。 + +**验证说明：** + +本次测试验证主要针对全闪机型与混闪机型进行对比 + +全闪机型：磁盘全部为 SSD + +混闪机型：事务日志盘为 SSD（本次测试为 NVME），数据盘为 HDD + +数据库版本：4.2.1.1 + +测试验证资源： + +全闪机型： + +麒麟 ARM * 3：国产化产品（ARM）:CPU 32 core * 2 / 内存 512G / 硬盘 SATA SSD 960G * 12 + +混闪机型： + +麒麟 ARM * 3：国产化产品（ARM）:CPU 32 core * 2 / 内存 512G / 硬盘 NVME 1.8T * 2 + SATA HDD 8T * 12 + +### **验证场景1：批量入库** +| | 8c16G | 16c32G | 32c64G | 64c128G | +| --- | --- | --- | --- | --- | +| 全闪 | 54903 | 85870 | 178158 | 221443 | +| 混闪 | 38622 | 61772 | 121918 | 164340 | + + +![示例图片](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/001.png) + +结论：批量入库场景下，性能随规格线性增长，32c64G 规格后，性能增长趋缓，混闪机型比全闪机型性能下降约 29%。 + +### **验证场景2：普通入库** +| | 8c16G | 16c32G | 32c64G | 64c128G | +| --- | --- | --- | --- | --- | +| 全闪 | 24490 | 48079 | 87440 | 91702 | +| 混闪 | 20513 | 40768 | 56511 | 56352 | + + + + +![示例图片](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/002.png) + +结论：普通入库场景下，性能随规格线性增长，32c64G 规格后，性能增长趋缓，混闪机型比全闪机型性能下降约 26%。 + +### **验证场景3：普通只读** +| | 8c16G | 16c32G | 32c64G | 64c128G | +| --- | --- | --- | --- | --- | +| 全闪 | 57283 | 106498 | 173308 | 198595 | +| 混闪 | 53010 | 96702 | 166397 | 188010 | + + +![示例图片](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/003.png) + +结论：普通只读场景下，性能随规格线性增长，32c64G 规格后，性能增长趋缓，混闪机型比全闪机型性能下降约 6%。 + +### **验证场景4：普通读写** +| | 8c16G | 16c32G | 32c64G | 64c128G | +| --- | --- | --- | --- | --- | +| 全闪读 | 36029 | 69911 | 131861 | 148802 | +| 全闪写 | 1801 | 3495 | 6593 | 7440 | +| 混闪读 | 34102 | 61301 | 111449 | 125255 | +| 混闪写 | 1705 | 3065 | 5572 | 6262 | + + +![示例图片](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/004.png) + +结论：普通读写场景下，性能随规格线性增长，32c64G 规格后，性能增长趋缓，混闪机型比全闪机型性能下降约 12%。 + +### **验证场景5：TP综合测试tpcc** +| | 8c16G | 16c32G | 32c64G | 64c128G | +| --- | --- | --- | --- | --- | +| 全闪 | 35127 | 82656 | 137854 | 158995 | +| 混闪 | 28042 | 67327 | 118766 | 157774 | + + +![示例图片](/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/005.png) + +结论：综合事务 TPCC 测试，混闪机型比全闪机型性能下降约 14%。 + +### **验证场景6：稳定性测试** +使用 sysbench 进行压力测试，设置并发度为 300，在普通读写场景下，数据库可以稳定运行 72 小时。 + +**验证结论：** + +- 通过对不同规格下各场景测试，混闪机型在入库场景下比全闪机型性能下降约 28%，只读场景性能下降约 6%，综合读写性能下降约 13%。 + +- 在稳定性方面，通过 72 小时 sysbench 高并发持续读写，数据库稳定运行无异常。但当前测试无法模拟实际生产环境复杂场景，OB 库在真实生产环境复杂场景下可能更易出现转储合并异常问题，影响集群稳定。 + +- 混闪机型用高性能的 NVME 或 SSD 来存储需实时落盘的事务日志，用 HDD 来存储数据量较大的业务数据，适用于对性能要求不高、业务相对简单、数据量较大的历史库、日志库、备份库等场景。 + +通过测试验证，混闪机型相比纯闪机型，会有 20% 左右的性能下降，稳定性方面也没有发现有直接的影响，这个结果极大的鼓舞了我们，因为我们有大量历史库、日志库场景，数据量庞大，但在线业务较少，对性能、计算资源要求不高。为此，我们即时进行了混闪机型替代，针对日志库场景，有业务一天的日志量在近 20 亿条，增量数据考虑多副本在 4T 左右，存储 1 个月数据需要纯闪机型机器 30 台。进行混闪机型替代后，只需要 3 台机器即可满足需求，一下子节省机器 27 台，仅这一个场景便节省硬件投资近 300 万元。另一方面，存量资源池存在大量机械盘主机，这样这些存量资源得以利用，避免了出现大量资源浪费的情况。 + +## **总结** +经过对混闪机型（即事务日志盘采用纯固态硬盘 SSD，数据盘采用机械硬盘 HDD）在性能与稳定性方面的严格测试与验证，结果显示，相较于纯闪机型，混闪机型在性能上约有 20% 的降幅，但在 OB 4.x 版本上能够保持持续且稳定的运行。混闪机型特别适合于那些对性能要求不苛刻、业务逻辑相对简单但数据量庞大的应用场景，诸如历史库、日志库、备份库等。通过实际生产环境的验证，其可行性得到了充分证实。 + +鉴于普通机型机械硬盘相较于固态硬盘在存储容量上通常高出一个数量级，混闪机型在这些特定场景下能够显著降低约 90% 的硬件成本。这一优势不仅大幅削减了硬件投入，还显著提升了资源利用率。以电信运营商的日志库为例，电信业务涉及大量且多元化的用户接入，除 BOSS 核心系统外，还会有手机营业厅、网上营业厅、各级子系统以及代理商等，通过服务调用日志分析，可以为业务运营提供宝贵的决策支持。采用混闪存储方案，在减少硬件成本的同时，还能提供更长时间的数据存储，进而为运营决策提供更加精准的数据支撑。 + +此外，混闪机型的引入打破了纯闪机型在 OceanBase 数据库部署上的单一限制。在当前信创替代加速、IT 技术日新月异的背景下，大大缩短了 IT 设备的更新换代周期，许多被替换下来的设备，其使用寿命往往远未达到 6 ~ 8 年的报废周期，弃之可惜。而这些设备虽然计算能力可能不是最优，但拥有高容量的机械硬盘。通过混闪部署 OceanBase 的方式，这些旧设备的利用价值得到了显著提升。同时，对于一些大公司而言，其设备采购往往涵盖多种机型，混闪机型的部署方式不仅拓宽了 OceanBase 在部署场景上的适用范围，还为多样化的应用场景提供了更加灵活、经济且高效的解决方案。 \ No newline at end of file diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/001.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/001.png similarity index 100% rename from static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/001.png rename to static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/001.png diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/002.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/002.png similarity index 100% rename from static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/002.png rename to static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/002.png diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/003.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/003.png similarity index 100% rename from static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/003.png rename to static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/003.png diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/004.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/004.png similarity index 100% rename from static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/004.png rename to static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/004.png diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/005.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/005.png similarity index 100% rename from static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/005.png rename to static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/005.png diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/006.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/006.png similarity index 100% rename from static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/006.png rename to static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/006.png diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/007.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/007.png similarity index 100% rename from static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_best_practices_for_deploying_oceanbase_on_k8s/007.png rename to static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/02_deploying_on_K8s/007.png diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction/001.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction/001.png new file mode 100644 index 000000000..d427a79cc Binary files /dev/null and b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction/001.png differ diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction/002.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction/002.png new file mode 100644 index 000000000..92ee4d7ea Binary files /dev/null and b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/05_resource_reduction/002.png differ diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment/001.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment/001.png new file mode 100644 index 000000000..f93c2acee Binary files /dev/null and b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment/001.png differ diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment/002.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment/002.png new file mode 100644 index 000000000..179ccf254 Binary files /dev/null and b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/06_cloud_server_deployment/002.png differ diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/001.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/001.png new file mode 100644 index 000000000..dda645709 Binary files /dev/null and b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/001.png differ diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/002.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/002.png new file mode 100644 index 000000000..aa455d001 Binary files /dev/null and b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/002.png differ diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/003.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/003.png new file mode 100644 index 000000000..db793e98a Binary files /dev/null and b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/003.png differ diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/004.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/004.png new file mode 100644 index 000000000..6e8c83438 Binary files /dev/null and b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/004.png differ diff --git a/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/005.png b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/005.png new file mode 100644 index 000000000..a2c216839 Binary files /dev/null and b/static/img/user_manual/operation_and_maintenance/zh-CN/user_practice_co-construction/07_ssd_hdd_hybrid_deployment/005.png differ