云端原本就是群集化的架构，Atlassian 系列产品。应用的开发团队相当广范且行之有年，可是将应用程序作为节点（比方Jira,confluence,bamboo…等應用程式）然后群集化的运维团队却是少之又少，希望以基础架构的角度切入，由下面列举之细目引导大家了解 Altassian DataCenter这个 群集化的方案，进而盘点要建置DataCenter。究竟须要哪些第三方技术才可以完整这种架构：
群集化不可或缺的虚拟环境 (Virtualization)：
以一个节点为单位，虚拟节点当然要比实体节点好调度，并且群集化后的节点群。要在实体机之间迁移，没有俱备虚拟环境要怎样轻易的完毕这种任务。要发挥DataCeneter所带来的优点，虚拟环境是必备的条件之中的一个，且并不须要在特定的虚拟产品下执行。
例如以下知名的虚拟産品所建构的虚拟环境都能够
双机热备 (Hight Avaliable)
针对负载平衡，或许客户会列举出执行中的 jira 负载还好，不须要用到负载平衡。可是双机热备HA。就不单单仅仅是在性能或是备援的考量。反而是应用面。怎么说呢？相信在应用程序或是插件的升级需求大家都有，但要在哪个节点測试呢？为了測试多买一套应用程序吗？就算预算充裕。那測试完成确认是能够满足开发者需求。接下来要怎样在不干扰下把在线人员整个移转过来？还是就在线直接更新。
在线直接更新是大部份眼下的作法，所产的问题状况百出。有时还回复不了原始状态，轻则中断开发者的应用。重则数据遗失。
也因此，有了 DataCenter 的应用程序再加上 Pacemaker 所建置完好的双机热备，那么整个应用程序的群集或是插件的应用就拥有了顺畅的演化环境。相关的升级就能够放手去进行，前端开发团队所提出的需求也能高速反应。
(pacemaker,corosync) 双机热备首选技朮
全新建置的节点，在这里建议大家採用 CentOS or RedHat 7 也就是 Linux 核心是 3.10。pacemaker 建置过程有稍稍较之前 Redhat or CentOS 5~6 较依赖 cli（command line）但整个建置完好后，无论是节点之间服务切换的速度，或是一些故障分析，都较能经得起考验。
当然维持原有的 Linux HA 旧环境，或是操作系统版本号有须要让其它软件依赖的考量而无法升级，DataCenter 的架构仍然是能够完毕的。仅仅是在多节点的布署。操作系统最好选择以 Linux 核心为 3.10 来担任。
下面两张分别为 pacemaker 的堆栈及内构图示：
在 Pacemaker 下完整建构的双机热备 HA，在下面三种情境都是能够正常运作的。
网络文件系统(NFS)及存储装置(DRBD)
Home-shared 是 DataCenter 的一个关键，原本 Atlassian 系列的应用程序都有一个 Local Home，透过 NFS 这个网络文件系统让同一种 AP 多个节点，供享同一个 home directory。
如此协同运作，就能够让单一个节点所作的设置(比方插件升级或是安装)，群集里的其它成员也就跟着完毕。
NFS 的供应端能够是不论什么云存储的分布式文件系统技术，这里用 CEPH 为演示样例来作说明，前端是藉由 NFS 分享出来的网络文件系统，后端是由三个 osd 节点组合出来的 RAW device。接下来是一个有趣的组合。我把监控 mon 和元数据 msd 原来两个节点组合为一个节点总共两组，这样就能够为 NFS-server 建置一个 HA 也就是提供一个虚拟 IP 给 Atlassian AP 作挂载，这样 share home 就有了热备援啦！在这里的 Pacemake 建置 HA 主要是为了 NFS-server 服务，mon 及 msd 的组合节点原本就有热备援的机制存在。不须要依赖 Packmaker 的 HA。
请以以下图型来想像一下我所描写叙述的安排：
双机热备一開始我们都仅仅考虑到应用程序端，如今我们来看看数据库怎样跟双机热备集成，一開始当然想到数据库的存储位置，DRBD 跟 Pacemaker 整合的很严密，以它来作为数据库的存储位置再也理想只是了，这个装置在两个节点之间以块层级随时同步着，但尽有一方会被挂载着，因此这种构架方案不适合作数据库的负载均衡，仅仅合适数据库的双机热备。也就是HA。
DRBD 仅仅提供到 Raw Device。再上层的文件系统就由操作系统接手了，接下来的挂载再由 Pacemaker 安排。DRBD 模块负责着三个訪问（Raw Driver，Disk Driver。NIC Driver）。
这里写图片描写叙述
DRBD 算是非常忙碌的一个模块，由于是块层级的传输，所以尽管负责很多面向，但效率不减（訪问 DRBD 官网请连接http://drbd.linbit.com/
再次提醒： DRBD的存储构架，对群集而言仅仅适合集成双机热备构架也就是HA，不合适负载均衡的安排，这点请注意。
负载均衡 (LoadBalance)
HAproxy 是个很不错的负载均衡舵手，在这个角色下能够用简单的參数来调配，能够作到让出来面对client提出需求的 web-service 群，是用什么样的模式来运作。比方 roundrobin 或 static-rr 。甚至能够分头顾及到下层的数据库是不是採用 leastconn 模式。
当然 HAproxy 这么重要的网关怎么能够仅仅由单一的节点来担任，再建一组 HA 吗？一个非常有趣的安排，把 HAproxy 往群里面配。无论是由云存储的群（sql）或是云计算的群（html）都能够，仅仅要把群里每一个成员上的 HAproxy 服务所有启动，參数调配好后就由 Pacemaker 所供应出来的虚拟IP来面对client的需求訪问，这样 HAproxy 就有热备援的机制啦！
能够參考例如以下的图示想像一下这个有趣的安排。
- roundrobin:平均轮询在各个节点上。可调整权重让不同等级的server分配不同的负载。
- static-rr:平输询在各个节点上，但权重调整无效。无论各个server规格怎样。按总节点数平圴轮询。
- leastconn:適合sessions較長的服務端。比方 LDAP。SQL….等。權重調整後會較緩慢生效。
- first:该算法的目的是要始终使用最小server的数量。
- source:这确保了同一client地址将始终达到同样的server端。
- url:同 source 区别在用 url 来辨别client。
- url_arm:同 url 区别在有參数。通常是server对server的訪问。
- hdr:这一般指的是可识别的用户标头，也就是同一个用户帐号登入不同client作訪问server，都是由同一台server来服务。
- rdp-cookie:如同 hdr 但以 cookie 存在与否来判别是否改变訪问的主机。
设置步骤 (DataCenter Setup)
下面为 Atlassian 原厂 DataCenter for jira 的设置步骤
- 首先把数据库跟应用程序（这里指的是 jira）分离。
- 确认原本的 jira 版本号是在 6.3 以上（含），假设版本号条件不满足，请先进行升级或是改版计划。
- 将 Loadblance 的节点安排好，这篇文章建议的是 HAproxy server。
- 把 Local Home Directory 分享出来，作为 DataCenter 最重要的 Share Home 的一个位置。
- 增加第二个应用程序节点。把数据库设定好，NFS-client 设定好訪问 Shared Home。
- 将 HAproxy 上层之AP设定为 roundrobin 模式，将下层数据库设定为 lessconn 模式。然后所有串接起来，由 Pacemaker 建置好的虚拟 IP，准备接受客户端的訪问。
效能监控工具 (Performance Monitor)
在建置 DataCentor 的整个过程还算繁琐，不仅仅步骤繁多，构架多样化，但整个模型是一致的，会建构 jira 应用程序的 DataCenter 也就会建构其它应用程序的 DataCenter，整个过程中，在这里建议随时观測虛拟环境的效能监控工具。一边进行建置一边进行诊断，才不㑹进行了大部份的建构步骤才開始回头查问题的解决办法，那将㑹添加问题分析的困难度。
例如以下图标演示样例，在我们浏览 jiraIP 我们能够知道 ha1 和 ha2 彼此之间并不是 roundrobin 关系
在整个 DataCenter 建置完毕后開始上线。执行过程中要注意 CPU 负戴不要持续攀升在 80% 以上。持续攀升须要调优或是硬件升级，瞬间是不碍事的。
例如以下以 VMware 性能监控器显示仅仅有瞬间攀升。
本文作者：James XU（CSDN资深技术顾问）未经同意不得转载！
软件商城：http://mall.csdn.net/tool
热门活动：Atlassian 购软件赠技术服务限时特惠火热进行中！
