前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >容器下的两地三中心建设

容器下的两地三中心建设

原创
作者头像
陈少文
修改2021-10-11 10:36:49
2.3K0
修改2021-10-11 10:36:49
举报
文章被收录于专栏:陈少文

1. 关于两地三中心

如上图,两地三中心的架构,是为了提高系统的容错、容灾的能力。当一个数据中心不可用时,能够将关键业务的流量切换到其他数据中心,可以抵御城市级的自然灾害。

两地指的是,地理上不同的两座城市,而三中心指的是:

  • 生产中心
  • 同城灾备中心
  • 异地灾备中心

2. 机房的网络连接

如上图,两地三中心架构的前提是,各个机房是互联互通的。因此,我们需要搭建一个低延时的环形网络。光纤的长度,通常在 50 KM 以上。如果租用了运营商的专线,延时可以高一点,但通常不会超过 20 ms。如果是同城光纤,延时只有 3 ms 左右。

我们需要在机房间距、延时二者之间进行取舍:

  • 机房间距离越远,容灾能力越强,但光纤会更长,延时会更高
  • 机房间距离越短,容灾能力越差,但光纤会越短,延时会很低

在同城的两个机房之间,网络延时很低,数据一致性很高。而异地机房,由于距离很远,可以租用专线与另外两个机房互联,避免过高的延时。

3. 应用流量的分发

如上图,是用户访问应用时的流量走向:

  1. 用户通过域名访问应用服务,通过智能 DNS 解析到地理上更近的机房 IP
  2. 在机房中,使用虚拟机部署有一个 LB 服务,对流量进行切分,一部分流量被切分到了另外一个机房
  3. 两个机房的服务,分别响应不同用户的请求

3.1 为什么是异地机房承载流量

没有经过流量冲击的路径是不可靠的。即使做了高可用、容灾,如果没有常态化的演练,系统也不会具备应对的能力。

因此,在多机房建设时,非常重要的一点就是,让更多机房获得访问流量。这里选择的是,两个异地的机房作为日常主要的流量机房,原因如下:

  • 更好演练灾难发生时的状况
  • 租用专线之后,异地机房延时能满足要求
  • 有足够预算购买专线带宽

3.2 为什么 DNS 之后,还有一层 LB

这里可能会有一个疑问,在机房外,DNS 对流量进行了一次切分,在机房内,LB 又对流量进行了一次切分,原因如下:

  • DNS 生效慢,增加一层 LB 能更快切换流量
  • 准确控制分配至各机房的流量比例
  • 支持按机房灰度发布应用的版本

4. 有状态与无状态的分层

如上图,有状态应用和无状态应用的分层,使得服务架构更加清晰。由无状态应用对外提供服务,而有状态应用为无状态应用提供服务。

这里的有状态应用,使用的是虚拟机部署的高可用服务,或者直接购买厂商的云服务中间件。

4.1 无状态应用

如上图,无状态应用基于 Kubernetes 提供运行时环境。得益于其强大的弹性与自愈能力,我们只需要关注于对各种云原生组件的使用,对参数的调优,即可满足大部分的业务需求。

对于无状态应用,我们通常会采用 Ingress 或 NodePort 的方式,对外暴露服务。两者的区别主要在于:

  • 支持的服务数量。每个 NodePort 会占用一个端口
  • 功能差异。Ingress 能提供 Host、灰度、子 Path 路径等功能
  • 组件数量。Ingress 需要更多组件支撑
  • 运维成本。Ingress 更新时,影响面更大,运维成本高
  • 迁移成本。NodePort 可能会发生端口冲突

Kubernetes 并不是保证服务 100% 可用,而是一旦服务异常时,能够快速利用空闲资源新建。同时,Kubernetes 还面临集群升级、主机维护等问题,因此,对于一些低频变更、对稳定性要求高的服务,我们采用的是虚拟机部署。

比如这里的 LB,LB 是一个影响面很大的应用,而且数量不会很多,我们通常会采用高可用的模式,部署在几台虚拟机上。

4.2 有状态应用

  • 镜像仓库

Harbor 的高可用通常有两种方式:

  1. 多个独立部署的 Harbor 实时同步。不同的 Harbor 实例之间,镜像可能不一致,有一定时延。
  2. 多个 Harbor 共享一个存储后端。多个 Harbor 实例,共享一个存储后端,数据一致性有保障了,但对存储后端的分布式要求更高。

这里采用的是 Harbor 共享存储高可用 + dragonFly 的方式。在非主要流量机房,部署高可用的 Harbor,通过 dragonFly 分发镜像到各个机房,机房中的主机通过 dfget 配置 mirror 拉取镜像。如下图:

使用 dragonFly 分发镜像,能减少同一个镜像,多副本应用实例部署时的拉取次数,节省专线的带宽。

  • MySQL 多机房 MHA 高可用

相较于国外使用 PostgreSQL,国内使用 MySQL 特别多。MHA(Master High Availability)是一套成熟的 MySQL 解决方案。在 MySQL 发生故障时,MHA 能在 30 秒以内完成数据库的故障切换操作,同时最大程度的保障数据一致性。

  • Redis 多机房集群模式

Redis 集群通过分片来实现数据共享,并提供复制和故障转移。相较于哨兵模式只有一个 master,集群模式有多个 master,具有高的可用性。

5. 总结

本篇主要是简单总结了一下两地三中心的架构。所写即所见的抽象,并不能完全尽述细节。主要内容如下:

  • 两地三中心的要点,是要构建一个环形的互联互通机房网络
  • 有状态应用采用虚拟机部署,无状态应用采用 Kubernetes 部署
  • 访问流量,先通过 DNS 切分到机房,在机房中再通过 LB 切分到各个集群

https://www.chenshaowen.com/blog/the-construction-of-two-places-and-three-centers-under-the-container.html

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 关于两地三中心
  • 2. 机房的网络连接
  • 3. 应用流量的分发
    • 3.1 为什么是异地机房承载流量
      • 3.2 为什么 DNS 之后,还有一层 LB
      • 4. 有状态与无状态的分层
        • 4.1 无状态应用
          • 4.2 有状态应用
          • 5. 总结
          相关产品与服务
          容器服务
          腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档