存档

文章标签 ‘运维架构’

运维架构的一些思考(4)

2012年6月20日 2,896 views 没有评论

凌晨2点有一个升级.睡不着. 写下这篇 文章. 不一定全面, 但可以给大家一个参考.

ssd盘发展,对于我们架构的影响.

1. 基于主机的高可用越来越成为趋势. 而不是传统的小机,高端存储的集中式的管理,这点可以参考网上炒作的”淘宝的去IOE”,部分反应了现实,说点题外话,我本人对于这种一刀切很反感,oracle是一个整体解决方案商,有它的价值所在,不是那么容易去的,不能为去而去. 一些公司有点跟风,而技术是最忌讳跟风的 ,在没有碰到瓶颈和真正的需要之前,去什么or不去什么差异不大,节省不了什么成本,仍然需要深刻理解应用,才能做出合适的规划;
2. cpu和带宽可能会出现瓶颈. 以前硬件cpu基本过剩. 但随着磁盘io能力的提升,单台主机可以部署多个实例, cpu和带宽可能会出现瓶颈 ,多个实例,需要留意NUMA架构优势,避免其负面影响;
3. 传统的raid作为一种成熟机制,仍然值得在ssd上做. (条带和数据库的block size仍然需要考量) .虽然我倾向于做raid1+0,但是为了节省成本,生产中一般是raid5和raid0,在故障率可接受的情况,不用太过ca[……]

Read more

运维架构的一些思考(3)

2012年5月29日 2,454 views 没有评论

关于监控.

关于监控的查看, 许多时候,不只是运维人员需要查看,研发同学也需要查看,产品同学可能也想看看. 用户希望的是单点登录获取所有有用信息,他需要从一个点就可以获取到所有的信息,而不是存在多个信息孤岛,所以有必要整合各种监控产品.让用户尽可能方便获取他要关注的一些指标.
如果研发同学也能实时查看到整个服务的一个性能变化趋势, 会有助于他们改进程序.
许多故障发现问题的时候,往往已经晚了,如果监控并没有及时发现, 那么是否有更实时的方式, 是否可以对关键的访问进行实时统计,实时在线记录各种性能数据呢?这样会投入一定开发成本, 但对于用户体验的改善更有针对性.
生产环境, 数据库往往在最后一环, 如果应用服务不能及时预警,那么一个小小的升级,都可能导致突然数据库流量大增, 导致数据库宕掉.  互联网公司许多服务为了快速上线,压力测试往往并没有做. 部分原因是认为开发成本高,想赶进度,部分原因是产品和研发同学自己都不清楚具体的数据, 许多人希望进行快速上线,快速迭代, 在运营中不断调整架构和改善程序,  如果要适应这样的模式, 更加需要服务的监控预警功能,有必要细化到许[……]

Read more

运维架构的一些思考(2)

2012年5月6日 1,859 views 没有评论
关于代理,负载均衡软硬件的稳定和服务隔离的重要性
由于技术限制和数据安全的考虑,一般数据库是单点的. 而之上的负载均衡设备, 代理, web服务器一般是能冗余故障处理的.
现实生产中,往往为了充分利用资源,会不断在一台主机上堆叠服务,之后为了提高可维护性,保障服务稳定,又会开始不断隔离,分离部署或者利用虚拟机技术.  许多中型公司都有几百甚至上千台服务器, 怎么避免服务之间的资源争用影响到服务的稳定呢? 不仅需要软件架构的松耦合,硬件部署也需要尽量隔离.   web服务如果不是很稳定,由于前面有F5负载均衡设备或者其他负载均衡软件,出现性能问题导致宕机的情况可以得到缓解,但如果web服务器和数据库服务器部署在一起,宕机或者负载很高往往会导致数据库的异常. 我们在部署数据库的时候,往往会进行一些容量规划,但内存往往是不能控制的.一个不稳定的web服务,可能导致内存急剧升高,最终导致触发OS的OOM机制,直接kill掉数据库.
关于负载均衡,LVS,Haproxy这些开源软件已经非常成熟,而且在许多大公司得到了大量应用,在很多情况下都可以代替硬件负载均衡设备,而且伸缩性也更强[……]

Read more

运维架构的一些思考(1)

2012年5月4日 2,177 views 没有评论

关于多集群部署,跨IDC同步数据.

多IDC部署主要是为了改善用户体验, 容灾,最主要的目的我想还是为了用户体验,   也有部分由于历史原因,应用的分布导致了跨IDC的访问.
可以理解为一种CDN加速方案.
首先,我想任何架构的部署,设计,都是要基于已经存在的一些历史访问性能数据或者监控数据. 而这些数据往往是可以通过各种方式收集也一般易于从应用程序侧收集的. 所以如果有需要改善用户体验,最好基于已经存在的用户访问的响应时间数据,以衡量是否采取就近部署节点加速用户响应的方案;
其次, 我们需要明确加速的是什么内容?往往数据库的流量只占据流量的很少一部分,那么我们是否有必要在许多集群都部署数据库从库, 能不能换一种思路,部署cache节点来加速响应? 使用cache节点有一个弱点,失效可能比较复杂, 但如果是海量访问的站点,往往cache才是成本最低的方案,可以支撑大得多的流量和并发, 数据库的主从很稳健,但其实是在网络稳定的情况,数据库下面还有一层网络层,如果网络层不可靠,那么数据库也可以认为是不可靠的.而生产中的实践已经证明了跨网复制一直存在不稳定情况;
可能许[……]

Read more