|
|
|
首先是大规模集群管理问题。我们要明确集群的概念，集群不是泛指各功能服务器的总合，而是指为了达到某一目的或功能的服务器、硬盘资源的整合（机器数大于两台），对于应用来说它就是一个整体，目前常规集群可分为：高可用性集群（HA），负载均衡集群（如LVS），分布式存储、计算存储集群（DFS，如Google GFS、Yahoo Hadoop），特定应用集群（某一特定功能服务器组合、如DB、Cache层等），目前互联网行业主要基于这四种类型；对于前两种类似，如果业务简单、应用上Post操作比较少，可以简单地采用四层交换机解决（如F5），达到服务高可用／负载均衡的作用，对于资源紧张的公司也有一些开源解决办法如lvs+ha，非常灵活；对于后两种，那就考验公司技术实力及应用特点了，第三种DFS主要应用于海量数据应用上，如邮件、搜索等应用，特别是搜索要求就更高了，除了简单海量存储，还包括数据挖掘、用户行为分析；如Google、Yahoo就能保存分析近一年的用户记录数据，而Baidu应该少于30天、Soguo就更少了。这些对于搜索准备性及用户体验是至关重要的。
|
|
|
|
接下来，我们再谈谈如何科学管理集群，有以下关键几点。
|
|
|
|
|
|
主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行及潜在问题的及时发现与干预。
|
|
|
|
（1）服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端Web Server，就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否崩溃、通过ICMP包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，这些只是一部分，还有多种监控方式，依应用特点而定。还有一些问题需解决，如集群过大，如何高性能地进行监控也是一个现实问题。
|
|
|
|
（2）集群状态类的监控或统计，为合理管理调优集群提供数据参考，包括服务瓶颈、性能问题、异常流量、攻击等问题。
|
|
|
|
|
|
（1）硬件故障问题。对于成百上千或上万机器的集群，服务器死机、硬件故障概率是非常大的，几乎每时每刻都有服务硬件问题。死机、硬盘损坏、电源故障、内存故障、交换机故障等问题随时可能出现。针对这种情况，我们在设计网站架构时需要充分考虑到这些问题，并将其视为常态；更多地依靠应用的冗余机制来规避这种风险，给系统工程师足够宽裕的处理时间。这就是考验运维工程师及网站架构师的地方了，好的设计能达到Google所描述的自恢复能力，如GFS，糟糕的设计就是一台服务器的死机可能会造成大面积服务的连锁故障反映，直接对用户拒绝响应。
|
|
|
|
（2）应用故障问题；可能是某一Bug被触发，或某一性能阈值被超越、攻击等情况不一而定，但重要的一点是要有对这些问题的预防性措施，不能想当然，它不会出问题，如真出问题了，如何应对？这需要运维工程师平时做足功夫，包括应急响应速度、故障处理的科学性、备用方案的有效性等。
|
|
|
|
|
|
简而言之，就是将我们日常手动进行的一些工作通过工具，系统自动来完成，解放我们的双手，例如：没有工具前，我们安装系统需要一台一台裸机安装，如2000台，可能需要10人/10天，而现在通过自动化工具，只需几个简单命令就能解决这个问题。还有如机器人类程序，自动完成以往每天人工干预的工作，使其自动完成、汇报结果，并具备一定的专家系统能力，能做一些简单的是／非判断、优化选择等。应该说，自动化运维是运维工程师职业化的一个追求，利己利公，虽然这是一个异常艰巨的任务，不断变更的业务、不规范化的应用设计、开发模式、网络架构变更、IDC变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化等工作。自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现。
|
|
|
|
总结一下运维中关键技术：大量高并发网站的设计方案；高可靠、高可伸缩性网络架构设计；网站安全问题，如何避免被黑？南北互联问题，动态CDN解决方案；海量数据存储架构。
|
|
|
