集群化 Atlassian 产品 (Containerize)

集群化 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 分别为 AP 及 DB

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

存储资源 (Storage Resource)

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

高可用性（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. 注意到负载均衡的所有数据库节点，单一节点脱离及重新加入集群后的是否正常持续支持服务。