作者: Tim Gross
翻译: 孙薇
自动化模式(Autopilot Pattern)是一种设计应用与基础架构的方式,旨在推动应用系统中的各个组件自动化。组成应用的每个容器都有自己的生命周期,我们将这些生命周期的行为封装到了应用的容器中,而没有依赖外部架构。 下文将讲述我们是如何借助这种模式,部署和运行其中一种常被认为难以在Docker容器中运行的复杂、有状态的应用:MySQL。 运行MySQL我们从常见的MySQL部署开始:从主节点到副本节点执行异步复制。客户端查询副本节点,或对主节点执行写入操作。这个架构会引发一些关于服务发现和拓扑结构的问题: - 副本节点如何知道在哪儿能找到主节点?
- 主节点如何告知副本节点从哪儿开始执行复制?
- 客户端如何知道在哪儿找到节点,哪些节点接受写入操作?
在执行部署后,我们还有一系列疑问: - 我们怎样进行备份?
- 如何主节点出现故障,如何对副本节点进行升级来进行替换?
- 在故障转移期间,其他的副本节点怎样知道在哪儿能找到新的主节点?
- 客户端如何知道我们执行了故障转移?
当然,其中一些问题已经有了现成的答案。配置管理工具经常会负责应用中架构的配置工作,但如果运行时应用拓扑出现变更,配置管理工具是无法回应的。数据库即服务(DBaaS)负责执行管理工作,不过如今大多的配置已不再控制范围内,成本也更为高昂。 对应用来说,还有一个选择就是执行自动化运行。在这种模式下,要对应用模式执行优化,代表着要让应用知道如何适应整个系统:启动、关闭、缩放、发现和恢复。最大限度地减少人为干涉,意味着错误更少,有更多的时间花在更重要的业务上。 很明显我们没打算重写MySQL,因此需要找出办法为现有的应用提供这个功能,而我们选择了Containerbuddy。 架构我们需要利用这些组件部署MySQL: MySQL:我们使用了MySQL5.6(Percona Server),使用XtraBackup运行热快照备份;
Consul:用来协调复制与故障转移工作;
Manta:Joyent的对象存储系统,为存储MySQL快照备份提供安全经久的服务;
Containerbuddy:包含在我们的MySQL容器中,负责编配bootstrap behavior,通过onStart、health、onChange处理器,调用Consul中存储的key和checks协调复制的工作。
triton-mysql.py:Containerbuddy在执行MySQL编配的繁重任务时会调用到的小型Python应用。 所有代码与配置都能在GitHub中找到。
架构图当开始新的MySQL节点时,Containerbuddy的onStart处理器会调用triton-mysql.py。Containerbuddy会fork Percona Server并等待,同时运行onStart、health、onChange处理器。结果就是类似这样在MySQL容器中的进程树: root@993acf351cd9:/# ps axo uid,pid,ppid,stime,cmdUID PID PPID STIME CMDroot 1 0 19:02 /bin/containerbuddymysql 94 1 19:02 |_ mysqld --console --gtid-mode=ON...root 107 1 19:04 |_ python /bin/triton-mysql.py healthroot 109 1 19:04 | |_ /usr/bin/innobackupex --no-timestamp...root 120 1 19:06 |_ python /bin/triton-mysql.py healthroot 121 1 19:06 |_ mysql -u repl -p...自组装由于我们只用了几个Docker镜像,无需使用单独的调度器来管理发现与引导服务,简单地使用下面的命令就可以运行堆栈: docker-compose up -d出现的第一个节点会登录Consul发现服务,尝试并查找主节点。如果第一个节点发现主节点还不存在,则将自身作为主节点,并初始化数据库。使用Consul会话通过atomic锁写入密码,这样就会有一个且仅有一个节点成为主节点。
主节点也会通过Percona XtraBackup来建立自己的快照备份节点,并将这个快照备份与最近的binlog发送到Manta对象存储系统中。(这个操作会周期性或在binlog变化时重复执行。)这些路径被记录在Consul中,我们会使用这些路径来执行下一步的复制。 一旦主节点建立完毕并且运行正常,我们就能很简单地扩展副本节点: docker-compose scale mysql=3在onStart处理器中,每个副本节点都会向Consul请求主节点的位置,然后从主节点建立备份节点。然后再向Consul请求最近快照备份的位置,从Manta下载该备份,然后使用GTIDs与主节点执行同步。一旦操作完成,这些副本节点就会在Consul注册为正常运行的节点。 自监控在MySQL进程的运行过程中,Containerbuddy会通过容器中捆绑的mysql客户端执行定期检查。在这种情况下使用简单的SELECT 1便能很容易地检查副本节点的状态,或者运行中的查询数。如果检查通过,Containerbuddy将会在一个TTL内对Consul写入一个区域数据。
自修复如果从服务中移除主节点(假设运行docker),容器中的Containerbuddy会立即从Colcul中移除它的注册信息,而副本节点会收到这个onChange事件。
尽管副本节点在几秒钟内发现了这个变化,也必须等待Concul的锁定结束。一旦锁定结束,所有副本节点会尝试获取锁定,无论哪个节点获胜,都会将自己升级为主节点。剩下的节点会自动根据新的主节点执行重新配置。 亲手尝试一下吧! 自动模式下的PerconaServer可以满足你对高性能、高可用性的MySQL兼容数据库的需求。可以用它来支持大量依赖于MySQL兼容服务器的开源应用,包括WordPress、Drupal、Joomla、TYPO3、MODx、phpBB、MyBB等等。 所有代码在GitHub上都能找到。 原文:https://www.joyent.com/blog/dbaas-simplicity-no-lock-in
|