关闭

集群化 Atlassian 产品 (Containerize)

5542人阅读 评论(1) 收藏 举报

集群化 Atlassian 产品 (Containerize)

容器化 Atlassian 产品就目前 Atlassian 的用戶环境來看,似乎并不多见,主要是因为当前生产环境中集群化 Atlassian 产品并不普谝,我们知道集群架构不外乎就三种:
1. 高可用 (High Availability)
2. 负载平衡 (Load Balancing)
3. 高效能 (High Performance)

不管集群架構是如何組合,整個框架离不开三层式 Client->AP->DB 平台架構,大致如下示意图:
这里写图片描述

原厂目前提供支援集群化的产品就 JIRA/Confluence/ServiceDesk/Bitbucket 这四款,主要是满足 高可用性/负载平衡 这倆种集群架构,也就是官方所谓的Data Center 版本,那没有购买 Data Center 版本的 Atlassian 用户,或是其他还未支援 Data Center 版本的产品比如 bamboo/hipchat/fisheye …等等,就不能建置高可用性(High Availability)集群架构了吗?答案是否定的喔。


集群架构模式 (Cluster Modle):

以下分別为(AP/DB)的三种典型集群模式:
AP 的三种构架跟DB的三种构架都可以交叉组合来运行,各有各的特性跟优缺点,对客户而言没有最好的组合,只有最适当的组合。

(AP DB) 的三种典型集群模式:

Browser->AP 的三种群集模式如图示:
这里写图片描述

AP->DB 的三种群集模式如图示:
这里写图片描述

关于高性能(Hight Performance) Atlassian官方目前并没有支持,所以这部分我们後面就不讨论了。

应用程式的容器化

我们先提出针对建置高可用性所不可缺少的重要架构,那就是容器化(Containerize),首先我们要把Atlassian应用程序给容器化,以下为容器化的架构图:

docker 架构一定要先健全,才能进行到容器化的步骤
这里写图片描述

PS. alpine 是 Docker 平台众多操作系统中很被看好,他轻量化镜像过程短暂,可达到快速布署的要。

高可用性(High Availability)

HA对于应用程式或是数据库,都只有在各自或是同一个节点上运行,各自或是同时切换都应该不影响从客户端到 AP 连至数据库的一路串接。

(HA Resource) 高可用性的相关资源

在高可用性构架下,相关的资源如下:

  • 虚疑IP
  • 容器化应用程序
  • 数据库服务
  • DRBD存储装置

以下两张分别为 高可用 (Hight Availability) 的示意及内构图示:

这里写图片描述

在 Pacemaker 下完整建构的双机热备(HA),只有一组是可以正常运作的。

Atlassian 应用程序(HA)的安排

由于Atlassian的应用程序是以java平台在运行,从启动到服务准备就绪,是比一般程序所需的时间要多一点开销。所以如果没有Docker容器化的帮助,是没有办法嵌入到高可用的框架当中的。

这里写图片描述

(PostgreSQL/MySQL) 数据库(HA)的安排

HA的构架下,数据库与DRBD搭配建置是一个完美的组合,数据库运行另一个节点,随时接收块层级的数据同步,待运行节点的虚拟** IP 因故障或是维护需求切换至备用节点后**DRBD存储装置即刻接收,整个高可用的数据库服务节点就算是切换完成。

以下为数据库高可用构架示意图:

这里写图片描述

虚拟IP节点的另一端,虽然没有运行数据库服务,但事实上DRBD一直以块层级的同步方式持续在进行着。

负载均衡 (Load Balancing)

在负载均衡的构架中,最大的不同在于HAproxy及应用程序服务(JIRA/Confluence)由操作系统负责,并没有嵌入pacemaker的集群构架里面,集群构架中主要是在管理虚拟IP的切换。

(LB resources) 负载均衡的相关资源

以下两张分别为 AP 負載均衡 DB 高可用性 的示意及内构图示:
这里写图片描述

HAproxy/应用程序服务(JIRA/Confluence)一定要确认在操作系统上是有安装的,且操作系统重新启动,是会自动把服务启动的。

Atlassian 应用程式(LB)的安排

AP 在负载均衡下,每个节点随时都在接受着前台分配下来的服务需求,节点愈多总需求的消化速度也就愈快,也因此横向扩展是负载均衡构架下最主要的持色。

以下为 AP 的负载均衡构架示意图:

这里写图片描述

数据库(LB)的安排 (PostgreSQL/MySQL)

以下为 DB 的负载均衡构架示意图:

这里写图片描述

网路资源 (Network Resource)

虚拟IP算是集群构架的一个关键,如果针对的是负载均衡的构架,那虚拟IP就会担任一个类似网关的功能把前端的需求往后端作分流,让所有节点分摊任务请求,达到负戴均衡的效果。
换作是高可用性的构架时,那么虚拟* IP *便是应用程序的服务接口。

下图为两组虚拟 IP 分别为 APDB

这里写图片描述

在虚拟IP在节点之间漂移的过程中,对外的服务是会掉少许的网络封包,因为如此session是必须重建的,原有登入的网页是会需要重新登入的。

存储资源 (Storage Resource)

在群集构架下的存储资源,分为 HADRBD 及分布式存储,下列分别针对两种存储构架来说明一下。

高可用性(HA)存储构架

以下为高可用性构架下应用的 DRBD 同步存储装置

这里写图片描述

针对高可用性HA构架下的存储资源,DRBD 算是首选,当然其他的存储资源仍然可采用,主要是只有单一节点运行服务,所以块层级的DRBD同步的传输速率高,且也不适合负载均衡 。

分布式存储负载均衡(LB)构架

以下为分布式的存储构架,可搭配 MySQL/MariDB garala 分布数据库技术,达到去中心化的数据库集群。

下面为分布式存储构架示意图

这里写图片描述

除了DRBD以外的存储资源都可以采用了,不管是NFS/ceph/gluster等等都可以 。

集群机能检测 (Cluster Testing)

高可用性构架之测试环境

以下为高可用性的集群构架测试环境

这里写图片描述

高可用性构架的测试重点如下

  1. 切换数据库检查前端 AP 的服务是否正常。
  2. 检查 DRBD 的同步状况是否健康是个测试重点 。
  3. 测试容器化后的应用程序启动关闭是否正常。
  4. 测试容器化后的应用程序在节点之间切换后,服务是否能够持续提供。

负载均衡构架之测试环境

负载均衡构架之一 (AP-LB DB-HA)

以下为负载均衡的集群构架测试环境(数据库为高可用性 HA 构架)
这里写图片描述

负载均衡构架的测试重点如下:

  1. 不管虚拟IP如何漂移,后台的所有节点都不应该有闲置。
  2. 在前台持续跟AP互动的情况下,试着关闭一个节点,观察服务是否会造成不正常的影响,比如无法接手的情况。
  3. 单一节点必须确认当操作系统重新启动后,应用程序服务是否有自动启动,比如JIRA/Confluence/HAproxy。
  4. 本构架之数据库因为是采用高可用性构架,所以DRBD同步机制的健康状况,应该也是观察的重点。

负载均衡构架之二 (AP-LB DB-LB)

以下为负载均衡的集群构架测试环境(数据库及AP均为负戴均衡构架)
这里写图片描述

数据库的负载均衡测试重点如下:

  1. 针对数据库执行数据表单产生的写入删除测试,观察他节点的数据库是否有同步产生数据表单及删除的效果。
  2. AP前端的虚拟IP切换到他节点后,持续跟AP互动的情况下观察后台所有数据库节点,是不应该有闲置的节点发生 。
  3. 注意到负载均衡的所有数据库节点,单一节点脱离及重新加入集群后的是否正常持续支持服务。
1
0

猜你在找
查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:21041次
    • 积分:380
    • 等级:
    • 排名:千里之外
    • 原创:5篇
    • 转载:0篇
    • 译文:0篇
    • 评论:1条
    文章分类