刚才我们已经简单使用了一下 aws ,现在开始一些准备
获取证书
从首页进入安全证书
AWS 有很多种安全方法,我们选择第三个访问密钥
然后你可以看到你现有的安全凭证
选择生成一个安全证书,妥善的保管它!
注意!
安全证书很重要 很重要。网上有无数人因为证书泄漏,被人恶意的挖矿,爬虫,攻击等等,白白花费了 aws 的费用,。所以一定要保管好,要保管好,要保管好! 重要的事情说 3 遍。
如果发现证书丢失,赶紧上网注销证书!
申请一个密钥对
点击 EC2 面板,选择密钥对
生成一个密钥,给它取一个名字
下载密钥
这个名字很重要,编码的时候会用到
用 linux 主机转换这个密钥 可以参考 http://blog.csdn.net/iamshaofa/article/details/7878346
用 SecureCRT 登录, 需要根据 xxx.pem 生成一个公钥文件 xxx.pem.pub 。不过生成*.pub 还是需要 linux 下进行:
$ chmod 700 xxx.pem
$ ssh-keygen -y -f xxx.pem >xxx.pem.pub
就是说,先改一下*.pem 的权限,然后再用 ssh-keygen 制作 pub 文件
证书和密钥的区别:
证书可以访问你的服务,权利非常大, API 开发需要利用证书,对你的请求进行签名。是你用户身份的标识 密钥对是弹性云计算中主机访问使用时候使用的密钥,没有它你无法连接上新创建的主机。
一个分布式系统,从 0 开始构建,我是按照下面的步骤进行
如果是网站测试的话,我认为可以把软件安装这部分 改为为安装 http 服务器, tomcat ,数据库, Php/Java 程序,准备 Memcached/redis, LVS 代理 这样的业务。实质只是运行的软件不一样,但是流程上大同小异。
我们可以在网页里一步步的点,如果是这样做,云计算就完全没有存在的必要,所以我们需要使用 AWS 提供的 API 接口,创建我们的主机, VPC 网络,最后利用 API 销毁这些主机。
一般公司使用 jenkins 对软件包进行编译,打包,单元测试这些过程。如果是持续开发的环境,这样的系统是必备的。目前从 0 开始,我把过程简化成为一个 shell 脚本,编译完成所有的软件。
写了一个简单的脚本,可以为系统准备随机数据,为每台服务器准备它们需要的启动脚本,停止脚本, redis 启动,清空等一系列脚本。
很明显我们需要一个开源自动化配置管理工具,选择非常多 Saltstack, cfeng, puppet 以及 ansible. 在不考虑语言本身的差异,这几个软件差异并不大,考虑到目前的实际情况,我认为在这个项目中 ansible 有一个比较好的优势:使用 ssh 无需为每台服务器安装相应的客户端,这非常方便。并且执行的批处理也很简单。所以我选择 ansible 作为部署软件。
用 ansible 批处理的形式完成
需要一个监控的服务,可以对测试的情况做及时的捕捉,掌握状态。已经提供了部分 zabbix 系统的脚本,但是完整实现还需一些代码,所以目前写了直接写屏软件,用它记录各个服务器压力测试的状态,类似股票市场的监控图。因为服务器的各个时间点状态,都有记录所以可以在后期做测试。 它看上去是这样的
已经有专门的脚本支持
整个系统的数据准备,软件编译,分发,部署,测试命令分发,我都在一台主机 10.0.1.11 上完成,这是唯一可以连接 internet 的服务器。这样其他所有的主机都无需连接 Internet ,可以节省网络费用。 fakewechat 使用是 Go 语言编写,所以不存在第三方库依赖问题,非常适合快速部署。
从发布测试成熟度来看,我认为可以分为几个阶段, 第一个阶段就是茹毛饮血 hardcode 的脚本时代(就像我目前做的),第二个就是 自动脚本时代, 第三代 就是 service 时代,第四代则是智能管理时代。我觉得,在云时代,企业产品云化需要这样的服务。
脚本是一年多以前写的,语言 python, 类库 boto2 , 目前 boto 版本是 3.
位置: https://github.com/xiaojiaqi/fakewechat/blob/master/aws/create_vpc.py
只需要用修改几个参数就可以完成
脚本很简单,它大概做了一下几件事情
运行文件即可,大概 1 , 2 分钟。几十台服务器就已经安装,配置完成。 IP 网关也配置完成。 步骤 1 , 2 完成
现在使用 SecureCRT 连接服务器
SecureCRT 的配置过程是这样的
创建一个连接
将主机的 IP 设置进去,(服务器 IP 可以从控制台获得,也可以用 DNS 管理)
如果是 RHEL 则默认登录用户是 ec2-user, 大部分 Linux 是 root
设置公钥文件,选择 刚才转换好的文件
接受密钥,完成连接
我们假设最先登录的主机为 10.0.1.11,它有外部 IP. 但是我们简称它为 10.0.1.11 主机,下面的操作都是在这台主机上完成的
5. 进入进入$HOME/gopath/src/github.com/fakewechat/bin 运行 deploy.sh 脚本主要完成了下面的事情 - 运行 listcm.py 脚本,为每一台主机生成它们需要的配置文件和启动脚本,关闭脚本,数据载入脚本,结果校验脚本,收集脚本这样一些列的脚本。 - 自动生成部署需要的 ansible 脚本 - 在本地生成初始数据 - 生成主机 IP 列表,并将主机 IP 列表配置到 ansible 的 hosts 文件中,这样 ansible 可以对所有主机进行控制 - 运行部署的 ansible 脚本,将所有的初始数据和程序,系统配置文件都部署到主机上,并设置权限 - 为每台主机重新设置内核参数,并关闭防火墙 - 在每台主机上,启动 redis 服务 - 在每台主机上,将初始数据载入 redis 服务器 - 启动服务器的监控服务器 - 启动服务注册发现服务 - 在每台服务器上,启动服务程序,让服务程序自动注册
做到这一步就完成了大部分的准备工作 (默认的配置是 4 个 rg, 每个 rg 是 1000 位用户,在运行前,修改脚本 num_rg 代表 rg 的数目 rg_size 代表这个 rg 里的用户数目 如果是 100 万用户,可以采用 40 台主机,每台主机 2.5 万个用户的配置)
脚本总共生成了 100 万位用户,用户之间的相互关系 29741136 条,平均每位用户接近 30 条。其中每位用户在同一个 rg 的关系为 20 条,跨 rg 的关系为 10 条。每位用户向自己的好友发送 5 条消息,测试共产生了 1.4 亿条(148705680)条消息,并完全正确接受。经过验证数据的没有问题,每位用户都成功发送了消息,也成功接受了消息。 因为消息需要跨服务器进行交互,从侧面证明,系统不是单独在单机上运作,是全集群有消息交互的。
1 台服务器 和 2 台服务器的数据可以见
4 台服务器处理 10 万用户, 40 台服务器处理 100 万用户 对比
可以看到 计数器显示,系统的吞吐数据有接近线性的增长,这表明软件原型 在 100 万级别有水平扩展的能力。
仔细回想了一下,经验收获不多,但是教训有一些。列下来引以为戒吧!
最开始的设计,在 10.0.1.11 上将所有的数据准备好,然后导入 redis 服务器。开始一切都很好,当开始百万用户级别的时候,导入这些用户的时间就让人无法接受,每台主机需要接近 10 分钟才能导入完成。 40 台主机就是 400 分钟。这是极大的浪费。所以 流程改进为改完所有的数据文件,复制到每一台主机上,用 golang 的程序载入,基本做到了几十秒内完成。
教训: 大规模并发服务,任何地方都不能单点运行,当规模扩大了,缺陷也立刻被放大。
一开始希望用低端的主机,实现"蚂蚁吃大象"的办法完成百万级用户测试,但是到最后的时候,因为 CPU 分数用尽,导致系统基本停止。最后只有换比较高端的主机。
教训 对系统的 CPU 使用情况没有仔细分析,对 AWS 主机分类理解不够
生成配置的脚本 bug ,导致某台主机的端口冲突,引起某个服务自动下线。最后在监控上发现服务数目不够,才查到了原因。
教训 监控需要更加智能,更细致。
连接 AWS 的网络连接并不稳定,结果某次断线,导致测试中断,最后重新测试
教训: 需要长期运行的程序 应该用 screen 这样的程序放到后台, 更好的办法是 service 化。 此外如果程序不是无状态的,就无法重试继续,需要对流程进行改进。
本来监控程序的刷新频率,靠业务数据驱动,每次有更新就自动刷新,用户少的时候,没有问题。当 40 台服务器一起更新的时候,刷新速度就没办法看了,导致流量涨得太高。 只能改成每 3 秒刷新一下
教训 品质细节需要实践
虽然使用了 ansible 分发程序,但是可以看得出分发过程,仍然是系统的瓶颈,同时也是个单点故障。这套部署架构并不适合更多的主机。
教训 大规模云计算系统里应该利用 p2p 进行程序部署,分发。
AWS 的账单可以从这里看
账单的组成部分:
点击查看详单
流量部分
主机部分
价格可以从这里看
http://aws.amazon.com/cn/ec2/pricing/
总之,用完以后,立刻删除所有的资源!
最后提醒一下, AWS 的客服非常好!有任何问题都可以直接和他交流,可以很快得到解决。
如果觉得对项目有兴趣可以访问 https://github.com/xiaojiaqi/fakewechat 本文地址 https://github.com/xiaojiaqi/fakewechat/wiki/Stress-Testing-in-the-Cloud 会持续更新
如果觉得有收获,让我知道 0.01 元
支持一下你的项目 1.00 元
1
alang 2016-05-06 00:30:33 +08:00
如果?如何?
现在的年轻人真的不注意标题错别字么? |
2
binux 2016-05-06 00:42:26 +08:00
既然都用 AWS 了,你可以用 Launch Configuration 的 user data 自动部署啊。
还是那句话,你这样的玩法,和随便到哪申请一大批 VPS 没有区别。 |
3
isnowify 2016-05-06 00:47:54 +08:00 via iPhone
自己压力测试后申请退款??
|
4
imlonghao 2016-05-06 00:54:30 +08:00 via Android
通常来说,是十分不建议直接用根证书的,一旦泄露整个账号就 GG 。推荐使用的是 IAM ,赋予好相应的权限,安全性很好一些。
--- 凭什么免单?难道这算是 unexpected charges 么? |
5
azh7138m 2016-05-06 08:12:13 +08:00 via Android
申请退款是不是不太厚道啊
|
6
Citrus 2016-05-06 08:28:04 +08:00 via iPhone
如果最后一个申请真的是测完要求退款的话,那问题就有点严重了。。。
|
7
firefox12 OP no, 我申请按照普通 t2.mirco 收费,而不是 RHEL, 因为我看到 Linux 是 0.02$. RHEL 我自然认为是一种 Linux 。
并且计费时间有出入, 40 个 instance 我认为没有使用这么多时间,最后客服直接给免了。 这个申请是在测试以前,你没看到所有的 instance 类型都是 t2.micro 吗? |
8
ladyv2 2016-05-06 10:34:03 +08:00
aws 的性能比 azure 还是差太多。。
|