转载请说明出处：http://blog.csdn.net/cywosp/article/details/21259391
现在很多互联网科技公司，还有一些传统的it公司都在根据自身的业务发展来设计符合实情的分布式系统。虽然，已有很多优秀的开源分布式系统，但是由于需求不同，业务不同，这些只能在设计符合自身需求的分布式系统时用于参考。个人认为，设计一个分布式存储系统并不是太难，主要困难在于如何设计并实现一个可以自动化处理各个节点状态的分布式集群管理系统。分布式系统到现在已经发展了很多年了，有些公司已经部署并上线使用多年，但到现在也没有关于集群管理方面的权威标准，各个公司都是根据自身的条件来处理集群中的问题。
分布式集群管理在发展的过程中会有不同的发展阶段。对于公司而言，根据公司业务规模，技术水平的不同，集群管理的方式也有所不同。在最初时期，为了设计一个符合自身业务需求的分布式系统，可能会先部署一个开源系统来学习，并通过手工来管理，整个集群中没有任何的数据监控用于运维管理，当然这一时期也用不上。随着时间的推移，自己设计的系统从demo变成可商用，公司从成本上考虑，会将重心放在核心的业务实现上，一时无法顾及高效的运维，将集群管理工作先由运维人员或者开发人员来担任。在这一阶段，可能会使用一些零散的自动化脚本和第三方组件来管理。当然，以上叙述在大多数情况下会是一些刚刚起步，急于软件商用公司的开发方式。对于比较成熟的大公司而言，他们会投入大量的财力，物力去研发一套自己的集群管理软件，事实监控节点的状态，做到自动化测试，自动化故障处理，自动化部署以及自动化发布，平滑升级等等功能。还有一些业内领先的巨头公司，他们可能会在自动化故障处理方面做得更加出色。——个人认为集群中的故障处理是分布式管理中最为难处理的一块，是集群管理的核心。如何做到快速，精准的故障切换，这是极其困难的。尤其是系统规模达到一定程度后，机器出故障的频率也会显著增加，当集群内部网络拥塞时，故障则更加难以判断，如果单靠人去维护话，那是不切实际的。
分布式集群管理大概可分为以下几点：节点管理、设备的管理、集群容量管理、集群策略管理、服务管理以及节点故障处理等，一般采用一个主节点（Master），其他节点都为从节点（Slave）的设计方式。集群管理在整个架构中的位置大概如下图所示：
在分布式集群管理设计中需要关注及注意的事项：
- 单点问题。
- 网络要合理划分，避免内被网络被“污染”。
- 集群管理的相关操作不能影响数据流的正常传输以及传输性能。一般情况的做法是将管理网络与数据网络相互独立，内外访问网络分离。
- 集群管理师对各个节点的管理，因此，管理的内容以及节点相关状态由各个节点负责收集。
- 为保持各个节点之间的独立性，不同节点的相同集群管理模块服务间不相互通信。
- 集群中，各节点间的时间同步很重要，不能相差太多。一般做法是采用主节点（Master）使用NTP与外部标准的授时中心同步时间，然后各个从节点（Slave）去同步主节点的时间。
- 在集群中有些节点内部不需要实时监控的状态数据可以使用各自为政的方式定时向主节点（Master） 反馈。例如：内存使用率、CPU使用率、缓存状态等等。
- 节点内部模块最好使用相同的机制提供服务。（thrift、protocol buffer、RESTful等）
- 主节点（Master）故障切换应遵守最下切换原则（最短时间、最少数据迁移），在集群中的从节点中选择一个来做主接点（Master）。在一些分布式系统中会采用选举法，就近原则等方法来完成故障的切换。
- 管理中产生的重要数据要多点多副本的本分，所有操作都需要有相应的记录日志。
- 集群的设计一定要切合实际。软件设计往往会让人陷入完美、面面俱到的陷阱里。分布式软件的设计和开发是一个需要长时间、多人投入的项目，做好了，可以支撑一个公司快速的业务发展，做差了，则是劳民伤财，甚至团队成员分崩离去。如果你的客户是一些中小企业、事业单位、政府机关、医疗机构，那么花长时间去做一个只又三、五个节点的集群自动化管理，这是不太值得的，还不如在保证集群可管理的情况下将大量的时间放到业务的开发上，保证终端用户对产品的友好、简单的使用上。如果你的客户是一些拥有几万人的企业，或者整个互联网用户，那么集群自动化管理就尤为重要了。
好的架构是进化来的，不是设计来的好的功能也是进化来的，不是设计来的任何牛B的人物，都有一段苦B的经历在以卖软件为生的公司里，任何牛X的架构，没有财力支撑，没有优秀的程序员去实现，那么它也仅仅是个架构而已。