ByteDoc 3.0:MongoDB 云原生实践

admin 2022年5月2日14:27:13安全文章 云安全评论6 views6375字阅读21分15秒阅读模式

动手点关注 干货不迷路 👆

背景

本文分享的是 Bytedoc 3.0 关于集群交付方面的内容以及一些云原生的实践:如何将 Bytedoc 3.0 与云原生的能力结合起来,交付用户一个开箱即用的集群,与软件层的能力相匹配,最大化展示 Bytedoc 3.0 具备的“弹性”能力。

面临的问题

数据库服务的使用者有两方:用户(业务)和 DBA(运维),运维能力不断增强,才能给用户更好的服务体验。

用户需求

ByteDoc 3.0:MongoDB 云原生实践

运维需求

ByteDoc 3.0:MongoDB 云原生实践

目标与思路

目标

为了解决上述问题,Bytedoc 3.0 软件层已经实现了相关的能力,我们需要在交付层提供类似的能力,以匹配整体的“”能力:

目标 1:数据库能快速扩展/恢复从库,秒级扩展数据库的读能力。扩容从库实例自动化程度要高,扩容速度尽可能快;

目标 2:计算资源能够按需扩展。对计算密集型业务,能快速扩展计算资源,而且能分配更多的资源供用户使用,匹配实际负载;

目标 3:提升计算/存储资源利用率,降低业务使用成本。

目标 4:更标准的交付能力与更高的交付质量,给用户提供更好的数据库服务。

实现思路

我们通过“Kubernetes 云原生”化来实现我们的目标:

Kubernetes 是业界通用的,用于自动部署,扩展和管理容器化应用程序的开源编排系统。简单地说,它能够系统化地打包、运行、管理你的服务,在这里是 Bytedoc 数据库服务。这使得我们能够结合已有的运维经验和业界通用服务交付/管理解决方案,提供更好的、更高质量的数据库服务,以发挥 Bytedoc 3.0 十足的"弹性"能力

ByteDoc 1.0 时期,大多数数据库服务实例是直接部署到虚拟机上的,资源的分配受限于虚拟机规格的划分,无法灵活地、按需要分配机器资源,导致大部分的机器资源空闲出来,无法得到有效利用;同时,因为计算与存储的资源绑定,在 1.0 的自研部署平台中,实现容器化部署十分困难,虚拟机部署的方案就一直保留下来。

直到 ByteDoc 3.0 的出现,将数据下沉存储层,交付服务时,更多关注计算层方面的资源分配,使得容器化部署模式可行。结合 Kubernetes 对容器部署与管理的解决方案,我们将容器大部分自动化管理操作交由给 Kubernetes 控制器管理,专注于 ByteDoc 3.0 服务编排过程,如集群部署、从库扩容等,以充分发挥 3.0 的"弹性"能力。

云原生实践

服务云原生化,实际上是一个“迁移”的过程,将原有服务打包、运行、管理能力,以 Kubernetes 提供的解决方案为标准,重现出来。

在 Kubernetes 中,我们把 ByteDoc 3.0 集群定义为一种定制资源(CustomResource)。提供数据库服务,实际上就是创建了一种资源;和 K8s 内置的工作负载资源一样,定制资源也需要一个控制器来进行管理,通常把这类控制器称作 Operator。

所以,ByteDoc 3.0 云原生实践的关键是构建 ByteDoc Operator。

Kubernetes 基本概念

容器化部署

前面说到,Kubernetes 是一个容器编排系统,主要的职责是管理容器生命周期,所以实际的应用程序应该提前打包成一个容器镜像,以便于交付给 K8s 来使用。

Pod

https://kubernetes.io/zh/docs/concepts/workloads/pods/

我们打包好的容器最后会运行在 Pod 中,由 Pod 管理起来。

Pod 是 K8s 中内置的最基本的资源之一,也是最小部署的计算单元,可以类比于一些共享机器资源的容器组。

如果一个 Pod (内的容器)因异常导致退出,通常情况下,这个 Pod 会被删除销毁,高级 workload 会新建一个全新的 Pod 来代替它,而不是“重启”该 Pod。

高级 workload

通常情况下,我们构建的 Operator 不会去直接创建 Pod;而是使用 K8s 提供的高级 workload 资源,他们会帮我们把 Pod 创建出来,并提供一些基本的资源管理能力。

Deployment:

  • 维护一组给定数量的、完全相同的 Pod,通常用于无状态服务。

StatefulSet:

  • 同样维护一组 Pod,特别的是,每个 Pod 都有稳定的网络标示;在此情景下,如果一个 Pod 被销毁重建,在外部使用者看来,该 Pod 是进行“重启”了,所以通常用于有状态的服务。

如何与 K8s 交互

Kubernetes  控制面的核心是  API 服务器。API 服务器负责提供 HTTP API,以供用户、集群中的不同部分和集群外部组件相互通信。

一般而言,我们与 K8s 交互是通过“声明式”,而非“动作命令式”。

# sample.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 6
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

ByteDoc 3.0 在 Kubernetes 上的架构

ByteDoc 3.0:MongoDB 云原生实践

(ByteDoc 经典架构,由三部分组成)

mongos:

  • 代理层,负责转发、简单处理用户请求;
  • 需要感知 Config Server,从中获取 Shard 的拓扑;

config server:

  • 复制集模式,区分主从;
  • 存储集群元信息,包括每个 shard 内实例的地址;

shard:

  • 复制集模式,区分主从;
  • server 层,处理用户请求;
ByteDoc 3.0:MongoDB 云原生实践
  • mongos - deployment,对应无状态的服务
  • config server/shard - statefulset,对应有状态的服务

对于 mongo 的复制集,复制集成员需要用一个网络标示(host、dns、服务发现、headless service 等)注册进配置中,才能与其他复制集成员进行通信;所以在这里,我们使用 StatefulSet 提供的稳定的网络标示作为成员名称,保证数据库实例(对应的 pod)故障恢复后,以同样的身份加入到复制集中,正常地提供服务。

联邦模式

多机房场景下的架构

实际上,上述 ByteDoc 3.0 集群是在单机房下的架构,在线上生产环境中,还要考虑多机房容灾的场景;在多机房场景下,我们希望一个 3 副本的集群,每个计算实例是分别部署在不同的机房,但是这些副本又是需要在同一个复制集中的,在参考了几种跨 K8s 方案后,我们采取了下面的多机房架构:

ByteDoc 3.0:MongoDB 云原生实践

有哪些候选的跨 K8s 的方案?

  1. 社区提供的 Federation V1 方案(deprecated,后续改进为 V2 方案)

    主要提供两个主要能力来支持管理多个集群:跨集群同步资源 & 跨集群服务发现

  2. 云原生 SRE 团队提供的通用 operator 方案
...
spec:
    charts:
    - name: nginx
      chart: charts/nginx
      values: '"replicaCount": "{{ .replica_count | default 1 }}"'
    cluster:
    - placement:
      - names:
        - cluster-sample
    execJobs:
    - name: ls
      command:
      - ls
      - "-l"
      mustBefore:
      - chart.nginx
    var:
      replica_count: '2'
  • 定义一系列的 chart、K8s 集群、执行任务、变量
  • 通过通用 operator 在多个 K8s 集群上完成资源部署、任务执行
  1. MongoDB 官方提供的跨 K8s 方案
  • 通过 mongodb 额外的 k8s-agent 完成跨 K8s 集群场景下,复制集与集群的构建
  • 代码未开源

为什么选择了现在这种方案?

我们当前的方案实际上和社区的 Federation 方案比较相似,通过以下的能力搭建完整的 ByteDoc 3.0 集群:

  • 资源复制:operator 连接 worker K8s,创建基本相同的资源
  • 服务发现:分具体的网络场景,如果使用 overlay 网络,可以使用社区支持的无头服务(headless service);如果是走 underlay 网络,则需要额外的服务发现能力
  • 组建 ByteDoc 集群:将实例组建为集群的核心逻辑,比较复杂,不太容易通过任务的形式实现

因此,我们选择这种 Meta Operator 的方案,通过 worker K8s 创建资源,后续 Operator 完成集群的搭建工作。

达到期望状态

spec:
  global:
    chartVersion: "1.0.0.0"
    bytedocVersion: "3.0"
    image: "example_image"
  mongos:
    replicaCount: 2
    resources:
      limits:
        cpu: "4"
        memory: 2Gi
      requests:
        cpu: "1"
        memory: 1Gi
  shard:
    shardsCount: 1
    replicaCount: 4
    ...
  config:
    replicaCount: 3
    ...
  placement:
    - name: vdc1
      vdc: "vdc1"

那么 ByteDoc Operator 到底执行了什么逻辑呢?Operator 其实也满足 K8s 控制器的设计理念,也就是,每个资源对象有一个期望状态,operator 需要把资源对象调整至期望状态,这个调整过程称为 Reconcile。

再仔细探究一下,ByteDoc 集群分为 3 个组件,只要 Mongos、config server、shard 三个组件都达到期望状态,最后将组件“连接”起来,整个集群也达到期望状态了;

所以我们可以将整个集群的 Reconcile,分解为对若干个模块 Reconcile,当每个小的模块都达到期望状态,整个集群也达到了期望状态,bytedoc operator 大致是基于这样的设计理念。

所以,我们的 operator 大致流程如下:

ByteDoc 3.0:MongoDB 云原生实践

状态管理 - Status

https://kubernetes.io/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status

Status 顾名思义就是用来存储一个资源对象当前状态的,可以充当状态机或小型存储使用。可以用来实现:

  • 一次性操作的完成情况:如初始化是否完成
  • 镜像/服务版本
  • 组件 status
  • 集群升级进度控制
  • 备份进度控制
  • 资源变更是否完成
    • 通常记录在字段 observedGeneration
    • 当我们对集群 CR 做变更时,metadata 中的 generation 计数会 +1,operator 需要在达到这次变更的期望状态时,设置相等的 observedGeneration 计数,以方便查询 CR 变更已完成。
  • 等等
status:
  replica_set:
    ll2022-shard-0:
      inline:
        added_as_shard: true
        initialized: true
        read_only_ready: true
        ready: 3
        size: 3
        status: ready
      placement:
        vdc1:
          ready: 3
          size: 3
          status: ready
          vdc: vdc1
    ...

资源模板化管理 - Helm

上面说到,ByteDoc 每个组件实际上用了 K8s 内置的资源来管理的,一般情况下,我们不需要从头编写整个 CR 的 yaml 文件,更多的是调整一个固定模板里的动态参数,比如 mongos 的实例数,CPU、Mem 资源限制等。

从此出发,工程实现上就有两种方向:

  • 将 yaml 模板硬编码到代码中,通过变量替换,生成目标的资源文件;
  • 将 yaml 模板以文件的形式存放,通过字符替换,生成目标的资源文件;

模板渲染与资源发布

我们采用的是第二种方法的一个较为优雅的版本,用 Helm (code)管理内置资源文件的渲染和发布 在 operator 镜像中,我们按照 helm 的标准,维护了一系列 charts 文件。

ByteDoc 3.0:MongoDB 云原生实践

在创建资源时,利用 helm sdk,将参数渲染到 charts 模板中,生成实际的资源 yaml,接着发布到 worker K8s 集群中,operator 只需要等待资源完全 ready 就可以继续执行变更了。

模板版本管理

另一个优雅的地方在于,此方案可以存放不同版本的 charts 模板,按版本划分为不同的目录;

当我们需要发布一个新版本的 charts 模板时,旧版本的服务并不会受到影响;而新创建的服务可以使用新版本的 charts 模板。

防止误操作

引入 K8s 帮助我们交付/管理集群有很多便利之处,但实际上也是一把双刃剑,可以不经意地误操作多数集群,导致数据库服务可用性受损。

可能的场景包括:

  • 误删除集群资源对象 -> 导致服务下线
  • 误缩容实例至 0 -> 无实例提供服务
  • 误删除 CRD -> 导致所有对应资源对象删除,所有服务下线

Finalizers

https://kubernetes.io/zh/docs/concepts/overview/working-with-objects/finalizers/

这是一个 K8s 防止误删除原生的解决方案,它是一个标示位,任何涉及删除的操作,都需要检查是否存在 finalizers。

  • 当 finalizer 存在时,经过 API Server 的删除资源的请求都会被 block 住,直到 finalizer 被清除;
  • 通常 finalizer 标记由对应的 operator 管理,在每次变更发生时,检查并添加 finalizer 标记;
  • 当接收到删除请求时,判断是否满足删除条件。在我们的场景下,一般需要等待 7 天的删除冷静期,所以如果遇到误删除操作,我们是有 7 天的时间进行恢复的;

实例数量缩容下限

这是一个很简单的方案,在接收到 CR 缩容变更时,检查其数量是否 > 0,不接受 = 0 的缩容,避免极端情况下,无可用实例的情况。

容灾能力

ByteDoc 3.0:MongoDB 云原生实践

实践效果

ByteDoc 3.0:MongoDB 云原生实践

加入我们


字节跳动文档数据库团队致力于为用户提供方便高效的海量 json 数据在线存取服务。我们正在开发完善一个用法上直观清晰,容量和性能上极具弹性,充分发挥最新软硬件技术的半结构化数据库产品与服务。目前已经有抖音、头条、西瓜、番茄小说等业务以及大量内部中台用户在使用。欢迎对数据库、分布式、云原生等方向感兴趣的优秀同学加入我们!

招聘链接:

云原生半结构化数据库架构师:

https://jobs.bytedance.com/campus/position/7068542748089125151/detail?referral_code=EPDMFRJ

云原生半结构化数据库研发工程师:

https://jobs.bytedance.com/campus/position/7068541261485246734/detail?referral_code=EPDMFRJ


ByteDoc 3.0:MongoDB 云原生实践  点击“阅读原文”了解岗位详情!

原文始发于微信公众号(字节跳动技术团队):ByteDoc 3.0:MongoDB 云原生实践

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年5月2日14:27:13
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  ByteDoc 3.0:MongoDB 云原生实践 http://cn-sec.com/archives/969665.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: