内容不错,只是条理有些混乱,整理了一下
一、设定容量目标
1. 不同的需求和测量方法
* 服务成功率 3个9还是5个9
* 业务容量需求
* 用户期望
2. 架构决策
* 提供测量点
* 找到可能瓶颈:磁盘吞吐、磁盘容量、CPU、RAM、网络
* 硬件决策:根据需求,确定合适的服务器架构
二、测量
1. 测量工具的功能
* 随着时间记录和保存数据
* 构建自定义度量指标
* 比较各种来源的度量指标
* 导入导出度量指标
Cacti/Munin/Ganglia/Hyperic HQ
2. 进行容量规划的必要测量
1. 测量记录服务器的主要功能:apache请求、数据库查询
2. 测量记录服务器的基础硬件资源:CPU、内存、磁盘、网络
3. 判断服务器的主要功能如何与其硬件资源相关联:并发N个请求占%M的CPU,N%的内存
4. 找到服务器可接受的最大资源使用量:线下模拟真实的生产负载(网络层引流)
3. 具体场景
1. 日志&SNMP
2. 应用层测量:产品指标,blog数量,用户注册,DAU...
3. 存储容量:存储消耗速率,读写操作比,IO_WAIT时间
4. 数据库容量:每秒查询、打开连接数、从库滞后时间、Cache命中率
5. 缓存系统:工作集大小和数据动态变化率
缓存类型 | 特 性 | 缓存上限 | 资源瓶颈
小或缓慢增长的工作集 | 100%命中 | 请求速率 | 磁盘IO CPU 内存
大或快速增长的工作集 | 移动窗口 持续迁出 | 命中率、LRU时间 | 缓存大小
三、趋势预测
1. 去顶测量和绘制每个资源定义的度量指标
2. 对拥有的资源应用约束限制
3. 使用曲线拟合推算出何时使用量会超限
四、部署
目标
* 最小化扩容需要的时间
* 配置集中管理
* 绝不进入单个服务器,使用集中式管理服务器完成
* 环境保持一致,使得故障排查变得简单
实现
1. 自动化环境初始化
* 基于package配置:Solaris Jumpstart/Red Hat Kickstart和Debian FAI
* 基于系统镜像:SystemImager
2. 自动化部署:配置管理系统
1. 该系统把配置文件组成有用的子系统,你可以才去不同的方式通过这些子系统建立生产系统
2. 该系统把当前运行系统的所有信息存储在一个地方,使得备份或者复制变得方便
3. 该系统从系统管理员的大脑中提取知识信息,然后以一种文档化和可重复利用的形式存储
3.权限管理和访问控制
LDAP或者使用配置管理系统完成
附录A 虚拟化和云计算
有几个是否选择云服务的决策案例,几个不使用云服务的原因
* 资源隔离不透彻,不同实例相互影响,使得性能变化多端难以预测(估计说的是IO)
* 没有合适的服务等级协议SLA(4个9之类)
* 法律方面第三方个人隐私、安全以及数据所有权的concern
附录B 对瞬时增长的处理
* 暂时关闭一些功能
* 页面静态化
* 开启临时性缓存
* 安抚用户
附录C 一堆工具