
如何使用Terraform在AWS上创建ShardingSphere Proxy高可用集群?
背景介绍
Terraform
Terraform[1] 是一个 Hashicorp[2] 开源的基础设施自动化编排工具,使用 IaC 的理念来管理基础设施的变更,并得到了 AWS,GCP,AZURE 等公有云厂商的支持以及社区提供的各种各样的 provider,已成为「基础设施即代码」领域最流行的实践方式之一,Terraform 有以下优点:
📌 支持多云部署
Terraform 适用于多云方案,将类似的基础结构部署到阿里云、其他云提供商或者本地数据中心。开发人员能够使用相同的工具和相似的配置文件同时管理不同云提供商的资源。
📌 自动化管理基础架构
Terraform 能够创建模块,可重复使用, 从而减少因人为因素导致的部署和管理错误。
📌 基础架构即代码
可以用代码来管理维护资源,允许保存基础设施状态,从而使用户能够跟踪系统中不同组件所做的更改,并与其他人共享这些配置 。
ShardingSphere-Proxy
Apache ShardingSphere 是一款分布式的数据库生态系统,可以将任意数据库转换为分布式数据库,并通过数据分片、弹性伸缩、加密等能力对原有数据库进行增强。
其设计哲学为 Database Plus,旨在构建异构数据库上层的标准和生态。它关注如何充分利用数据库的计算和存储能力,而并非实现一个全新的数据库。它站在数据库的上层视角,关注数据库之间的协作多于它们自身。
ShardingSphere-Proxy 的定位为透明化的数据库代理,理论上支持任何使用 MySQL、PostgreSQL、openGauss 协议的客户端操作数据,对异构语言、运维场景更友好。其对应用代码是无侵入的,用户只需更改数据库的连接串,就可以实现数据分片,读写分离等功能,作为数据基础设施的一部分,其自身的高可用性将非常重要。
使用 Terraform 部署
我们希望您通过 IaC 的方式去部署管理 ShardingSphere Proxy 集群,去享受 IaC 带来的好处。基于以上,我们计划使用 Terraform 创建一个多可用区的 ShardingSphere-Proxy 高可用集群。除此之外,在开始编写 Terraform 配置之前,我们先需要了解 ShardingSphere-Proxy 集群的基本架构图:
我们使用 ZooKeeper 来作为 Governance Center。可以看出,ShardingSphere-Proxy 自身是一个无状态的应用,在实际场景中,对外提供一个负载均衡即可, 由负载均衡去弹性分配各个实例之间的流量。为了保证 ZooKeeper 集群及 ShardingSphere-Proxy 集群的高可用,我们将使用以下架构创建:
ZooKeeper 集群
定义输入参数
为了达到可重用配置的目的,我们定义了一系列的变量,内容如下:
这些变量也可以在下面安装 ShardingSphere-Proxy 集群时更改。
配置 ZooKeeper 集群
ZooKeeper 服务实例我们使用了 aws 原生的 amzn2-ami-hvm
镜像,我们使用 count 参数来部署 ZooKeeper 服务,它指示 Terraform 创建的 ZooKeeper 集群的节点数量为 var.cluster_size 。
在创建 ZooKeeper 实例时,我们使用了 ignore_changes 参数来忽略人为的更改 tag ,以避免在下次运行 Terraform 时实例被重新创建。
可使用 cloud-init 来初始化 ZooKeeper 相关配置,具体内容见 [3]。我们为每个 ZooKeeper 服务都创建了对应的域名,应用只需要使用域名即可,以避免 ZooKeeper 服务重启导致 ip 地址更改带来的问题。
定义输出
在成功运行 terraform apply 后会输出 ZooKeeper 服务实例的 IP 及对应的域名。
ShardingSphere-Proxy 集群
定义输入参数
定义输入参数的目的也是为了达到配置可重用的目的。
配置 AutoScalingGroup
我们将创建一个 AutoScalingGroup 来让其管理 ShardingSphere-Proxy 实例,AutoScalingGroup 的健康检查类型被更改为 "ELB",在负载均衡对实例执行健康检查失败后,AutoScalingGroup 能及时移出坏的节点。
在创建 AutoScallingGroup 时会忽略以下更改,分别为:load_balancers 、 target_group_arns 。我们同样使用 cloud-init 来配置 ShardingSphere-Proxy 实例,具体内容见 [4]。
配置负载均衡
通过上一步创建好的 AutoScalingGroup 会 attach 到负载均衡上,经过负载均衡的流量会自动路由到 AutoScalingGroup 创建的 ShardingSphere-Proxy 实例上。
配置域名
我们将创建默认为 proxy.shardingsphere.org 的内部域名,实际内部指向到上一步创建的负载均衡。
配置 CloudWatch
我们将通过 STS 去创建包含 CloudWatch 权限的角色,角色会附加到由 AutoScalingGroup 创建的 ShardingSphere-Proxy 实例上,其运行日志会被 CloudWatch Agent 采集到 CloudWatch 上。
默认会创建名为 shardingsphere-proxy.log 的 log_group,CloudWatch 的具体配置见 [5]。
部署
在创建完所有的 Terraform 配置后就可以部署 ShardingSphere-Proxy 集群了。在实际部署之前,推荐您使用如下命令去检查配置是否按预期执行。
在确认完计划后,就可以去真正的执行了,运行如下命令:
完整的代码可以在 [6] 找到。更多的内容请查看我们的网站 [7]。
测试
测试的目标是证明创建的集群是可用的, 我们使用一个简单 case:使用 DistSQL 添加两个数据源及创建一个简单的分片规则,然后插入数据,查询能返回正确的结果。
默认我们会创建一个 proxy.shardingsphere.org 的内部域名, ShardingSphere-Proxy 集群的用户名和密码都是 root。
注:DistSQL(Distributed SQL)是 ShardingSphere 特有的操作语言,它与标准 SQL 的使用方式完全一致,用于提供增量功能的 SQL 级别操作能力, 详细说明见 [8]。
总结
Terraform 是帮助你实现 IaC 的有效工具,使用 Terraform 对迭代 ShardingSphere-Proxy 集群将非常有用。希望这篇文章能够帮助到对 ShardingSphere 以及 Terraform 感兴趣的人。
引用
文章转载自公众号: ShardingSphere官微
