今年有个很流行的网络缩写:豪做友。大概的意思是:土豪,我们做朋友吧。
赋诗(打油)一首:
软件公司真土豪 指点江山意气高
如果公司很屌丝 苦B才干架构师
俺N年前在一个项目里,被要求做一个架构设计,然后被告知:服务器数量是2——俺虽然不知道俺当时的表情,不过一个声音在我空旷的心灵里撞击回响直至轰鸣:真特么二啊……
我的生涯一片无悔,我想起那天下午夕阳下的奔跑,那是我逝去的青春。——《万万没想到:第1集》 台词
好吧,说点儿正经话。
架构能忽悠人的地方在于,纸面上,你只要画上诸如:负载均衡、一主多从等等跟过家家、搭积木一样的东东就够,剩下的问题,是祈祷“有个土豪做朋友”~~~
架构能搞死人的地方在于,
1 你需要对满足不了你图纸的要求的现实世界做一个尽可能精确的评估和适配
2 对初始参数多样而且随时在变化的情况做多个预案,(有云:架构不做Plan B,便为英雄也枉然) 比如:。。。。对于硬件上的许诺,比如给我服务器100台,我从来都只当会给我落实50台,从而来要求开发出的代码需要达到的性能——最特么坑爹的是:果然被我猜中了,每次都会打折扣!!!
3 有随时调整甚至改写服务的准备(这个可能跟你部署的应用没关系,而是要改某个系统服务的源码,所以先赶紧补血补蓝吧,不然要被拿首血然后三杀 -_-b)
——”打土豪分田地“毕竟已经是过去时了,面对现实吧——有困难要上、没困难制造困难也要上——这才叫能耐啊,骚年~~~
啊咧……-_-b 上面这句话貌似有什么不对的地方......我的意思是,是男人,就开扎古!!!
下面先设计一个系统仿真和优化的方案,其实,我最想用的建模工具是petrinet,不过现在认识不够,所以还是玩儿最常用的遗传算法吧——足够暴力,效果不错,最主要的原因是可以偷懒——让机器去死磕去吧:)
目标:
对asp服务器集群进行仿真,通过遗传算法优选出最有效的部署方案。
至于为什么要费这么大的劲做这个,理由是:服务器的数量不少,款式太多,各种硬件配置都有,而且部分机器性能相差悬殊。在这种情况下,很难通过直觉和经验进行判断。
在实际的部署和调试中也经常遇到一些头疼的问题:比如squid的权重因子的设置,由于不同服务器的磁盘大小差别太大,机柜的上联带宽也存在不同的情况,只能通过猜测,一个个实验,不是这台磁盘空间不足报警了就是那台网络带宽撑满了。在服务器数量大的情况下实在是非常头疼,而且对配置优化的结果毫无底气——因为这个是人工试错的结果,根本不能确定是否是全局最优的。
当然,用事实说话、用数据说话而不是经验和猜测可能是设计架构的时候需要考虑的一个问题。设计这个方案的另外一个目的就是为了对未来的硬件需求做一个评估。
如果有效的话,也许可以形成一个新的产品:架构优化工具。
专用吐槽格,可以跳过,不影响阅读。 |
好吧,这里还有一个隐藏关卡:《亚波の吐槽》 这个关卡里面的大boss——亚波同学,经常上门打脸、长期吐槽我的架构设计不合理。 为了通关,不使出究极奥义——”宇智波反弹“是糊弄不过去的了 -_-b 亚波同学,你这算躺着也中枪么? :-) |
集群设定:
缩写 | 说明 | 取值范围 | 类型 |
CHM | 服务器 | N 台 序号依次为: CHM1 CHM2 CHM3 CHM4 …CHMn | 常量 |
CHF | F5调度 | 1 台 | 常量 |
CHC | 机柜 | M台 序号依次为: CHC1 CHC2 CHC3 CHC4 …CHCm 上联入口带宽: CHCi1 CHCi2 CHCi3 …CHCim 上联出口带宽: CHCo1 CHCo2 CHCo3 …CHCom | 常量 |
服务器单元设定:
Machine Hardware设定:
缩写 | 说明 | 取值范围 | 类型 |
MHC | CPU | 100 | 常量 |
MHM | Memory | 内存大小Mb | 常量 |
MHD | Hard Disk | 读 / 写速率 Mb/sec 磁盘大小 Mb | 常量 |
MHN | Network interface Card | Mb/sec | 常量 |
MHL | Location 从属机柜 | 机柜序号CNO | 变量 |
Machine Software设定:
缩写 | 说明 | 取值范围 | 类型 |
MSF | 是否接受F5调度 | 1 接受 0 不接受 | 变量 |
MSS | Squid 节点权重 | [0, 100] 百分数 0 不承担缓存任务 aka不部署 X% 承担百分之x的缓存任务 | 变量 |
MSN | Nginx 部署 | 0 不部署 1 部署 | 变量 |
遗传算法设计:
一个部署方案视作一个基因序列,
基因序列:
如有n台服务器,则基因为:
M1 | M2 | M3 | M4 | M5 | M6 | … | Mk | … | Mn |
其中基因片Mk的组成结构为:
从属机柜序号 | 是否加入F5群组 | squid权重 (0为不部署) | 是否部署nginx |
CNO | MSF | MSS | MSN |
基因片初始化:createGenFrag
设有n台服务器,m个机柜,
CNO = random(0, 1) * m
MSF = random(0, 1) * 1
MSS = random(0, 1) * 10
MSN = random(0, 1) * 1
基因Gen变异:createGen
For k in (1 … n) :
Gen[] = creatGenFrag()
Squid权重重新配比:normalizeMSS
ms_total = 0
For k in (1 … n) :
ms_total += Gen[k].mss
For k in (1 … n) :
Gen[k].mss = Gen[k].mss/ ms_total * 10
基因杂交:
交叉位置 idx = random(0, 1) * n
GenNew = Gen1[0 : idx] + Gen2[idx : n]
normalizeMSS(GenNew)
评估函数:
Value = Cost(Gen)
实现前文提到的仿真计算,获得整个系统能处理的最大并发数
Value 越大,说明集群配置的效果越好。
输入:
线上集群的三日或者一周访问日志。
仿真 :
预设和假定:
1. 时间片tick:一个时间片模拟1 秒,一个时间片内接收到的请求视作并发任务,请求数为并发数。
2. 延时设定
a) 一旦并发数对某项资源的需求超出其物理上限,将根据该项资源的物理上限计算当前时间片能处理的请求数,未能完成的请求转入下一个时间片处理。
b) 请求会一直阻塞直到完成,不考虑超时即可终止服务的策略。
c) 不考虑前端服务器根据后端服务器繁忙与否主动选择空闲后端的策略。
3. 单个请求返回的文件大小为1M。(724G * 4disk / 3087899 StoreEntries = 983Kb)
4. 对于nginx,文件的输出/ 输入的比率为:1 : 3。
Cost 成本函数
使用线上服务器日志或者选择一台物理测试机进行压力和采样。
消耗资源为r,设请求数pa,经一致性hash调度后本地缓存为pl、代理响应为pr,squid缓存对象数量o,实时命中率为h,磁盘大小d,
k、w为常数,请求文件大小 s (常量 1Mb)
假设:r与p、o、h等变量存在线性关系。
1. Squid
a) 缓存:LRU
b) 调度:一致性hash
c) 资源:
i. CPU:r1 = k1 * pa+ w1
ii. 内存:r2 = k2 * o + w2 (存储于内存的缓存对象索引大小)
iii. 磁盘:
1) 磁盘大小:r3 = o * s
2) 磁盘读:r3 = pa * h * s
3) 磁盘写:r4 = pl * s
iv. 网络:
1) 入:pa * (1 - h) * s
2) 出:pa * s
2. Nginx
a) CPU:r1 = k1 * p+ w1
b) 内存:r2 = k2 * pa * s + w2
c) 网络:
i. 入:pa * s * 3 (默认出入比 1:3)
ii. 出:pa * s
3. Server
a) 上述模块的资源消耗不能超过服务器的物理上限(常量)
b) 网络:如果上述两个服务模块处于同一台物理机,则网络出入量需要去除本地通讯部分。
4. Cabinet 机柜的上联出入带宽
计算:
由于运算量巨大,可能要考虑分布式计算:
多个服务器,一个master,多个worker
1. Master处理初始化工作
2. 将制造的基因交付给worker
3. Worker进行cost运算,将结果返回给master
4. Master评估各种基因的效果,进行优选、变异和杂交
5. 如果未完成迭代次数,回到2
6. 得到最优结果
拟使用erlang 或者 使用 gearman
结果解释:
从属机柜序号 | 是否加入F5群组 | squid权重 (0为不部署) | 是否部署nginx |
CNO | MSF | MSS | MSN |
机柜数最多10,权重最大9,若服务器有4台,则结果可能为:
0141015110011001
0141 0151 1001 1001
解读为:
0号机柜部署两台服务器,
前端是F5,两台机器均安装squid和nginx模块,其中一台权重4( 4/9),一台权重5(5/9)
1号机柜部署两台服务器,
均只安装nginx模块
ps 补充一句,留个记号:最近看到一个paper,<基于元胞自动机遗传算法的云资源调度>,讲的是用元胞自动机和遗传算法来做云计算的结构优化,在完成上文的实验之后,可能会考虑试试。主要是里面提到的云计算仿真平台 cloudsim 似乎有点儿意思:)
先记录几个数字:
1 : 1.9
1 : 2.3
关于cpu和程序的关系测量:
http://blog.csdn.net/hbhhww/article/details/7168507
http://wangcong.org/articles/valgrind.html
http://book.51cto.com/art/201201/313562.htm
http://zh.wikipedia.org/wiki/%E6%97%B6%E9%92%9F%E9%A2%91%E7%8E%87
http://blog.chinaunix.net/uid-24774106-id-2779245.html
http://blog.csdn.net/solstice/article/details/5196544