如何自己开发一套服务器管理系统

转载表面上看，是一套基于B/S方式实现的分布式管理系统，但其实背后的架构是基于C/S完成的。你以为他是一只鞋吗？其实他是一个吹风机。作为界面化的系统，浏览器框架是不可或缺的，但更加重要的东西在Socket上面。

一、需要解决中央控制端到各节点服务器之间的通信。

这个其实牵扯到一个通信协议的问题，各语言都有自己的socket，thread的库，直接调用即可。但是这个通信协议就需要自己来完成了。既不能太简单，太简单了，明码传输，如果别人获知了这个接口，就很容易执行一些令人讨厌的 *** 作。也不能太复杂，太复杂了等于是给自己找麻烦，所以简单的数据包编解码的工作或者用token验证的方式是需要的。通信协议起码要两种，一种是传输命令执行的协议，一种是传输文件的协议。

二、跨语言的socket通信

为什么要跨语言，主控端和代理端通信，用什么语言开发其实无所谓。但是为了给自己省事，尽可能使用服务器上已经有了的默认语言，Ambari前期采用phppuppet的方式管理集群，这不是不可以，puppet自己解决了socket通信协议和文件传输的问题，可你需要为了puppet在每台服务器上都安装ruby。我是个有点服务器和代码洁癖的人。光是为了一个puppet就装个ruby，我觉得心里特对不起服务器的资源。所以我自己写了一个python的代理端。python是不管哪个linux系统在安装的时候就都会有了。然后主控端的通信，可以用python实现，也可以用php实现，但是考虑到对于更多的使用者来说，改php可能要比改tornado简单许多，所以就没用python开发。hadoop分支版本众多，发布出去，用户要自己修改成安装适合自己的hadoop发行版，就势必要改源码，会php的明显比会python的多。php里面的model封装了所有的 *** 作，而python只是个 *** 作代理人的角色而已。

所以也延伸出一个问题，什么语言用来做这种分布式管理系统的代理端比较合适，我自己觉得，也就是python比较合适了， *** 作系统自带，原生的package功能基本够用。用java和php也可以写agent，但是你势必在各节点预先就铺设好jre或者php运行环境。这就跟为什么用python和java写mapred的人最多是一样的。没人拦着你用nodejs写mapred，也可以写，就是你得在每个节点都装v8的解释引擎，不嫌麻烦完全可以这样干。原理参看map/rece论文，不解释。perl也是 *** 作系统原生带的，但是perl的可维护性太差了，还是算了吧。

所以这就牵扯到一个跨语言的socket问题，理论上来说，这不存在什么问题。但这是理论上的，实际开发过程中确实存在问题，比如socket长连接，通信数据包在底层的封装方式不同。我没有使用xml-rpc的原因之一就是我听说php的xmlrpc跟其他语言的xmlrpc有不同的地方，需要修改才能用,我就没有用这种办法。最早是自己定义的 *** 作协议，这时就遇到了这些问题，所以后来直接采用了thrift方式。就基本不存在跨语言的socket通信问题了。

三、代理端执行结果的获取

无论命令还是文件是否在代理端执行成功，都需要获取到执行结果返回给中央端。所以这里也涉及一个读取节点上的stdout和stderr的问题。这个总体来说不是很难，都有现成的包。当然这个时候你需要的是阻塞执行，而不能搞异步回调。

还有个问题是，我要尽可能使用python默认就带的包，而尽量不让服务器去访问internet下载第三方的包。

还有代理端最重要的一点，就是python的版本兼容性。centos5用python24，centos6用python26，ubuntu基本默认都是27。所以一定要最大限度的保证语言的跨版本兼容性，要是每个 *** 作系统和每一个版本我都写一个代理，我一个人就累死了。

四、浏览器端的model，view，controller

这里面你要封装好所有的通信协议，以及需要在节点上面执行的脚本。发送文件的 *** 作和数据库 *** 作也要在model里面完成。

如果对tcl/tk很熟，也可以写基于 *** 作系统界面方式的管理，不用浏览器就是了。

view对我来说是最痛苦的事，都是现学的jQuery怎么用，前端的工作太可怕了。关于这方面，没有太多可描述的，html和js带给我的只有痛苦的回忆，万恶的undefined。

五、跨 *** 作系统的安装文件封装。

要适应不同的 *** 作系统也是个很麻烦的事情，需要用agent提前获知 *** 作系统的发行分支，版本号。然后去找到对应的安装文件去执行。你不能保证一个分布式系统的集群中所有的节点都可以访问internet，更多的情况是这些节点都存在在一个安全的内网中。只有个别几个节点是可以访问外网的。所以，我势必要把所有的安装文件以及他们的依赖尽可能集中起来。我不确定安装 *** 作系统的lzo，yum或者apt-get会去下什么鬼东西，甚至无论是yum还是apt-get，里面都没有hadoop-lzo的库文件。所以，最好的办法是自己编译打包rpm和deb包。直接安装就好了，别去找repo下载什么。

这就是第五步工作，把需要的依赖的东西自己编译打包成rpm和deb。

deb包很好解决，但是rpm就没那么好办了，需要学习rpm的编译文件如何编写，这块是挺麻烦的，但是这玩意用好了还是挺不错的。现在我自制的安装包里面就已经包含了自己编译的lzo和snappy两种压缩库，以及hadoop-gpl-packaging的rpm和deb。下一个发布的easyhadoop将直接支持centos5,6，suse，以及ubuntu/debian的系统上安装hadoop。已经自带了lzo和snappy以及lzop和snzip。

六、把这些所有东西，整合到一个系统里面。

关联这些所有事情间的联系，整合到一个浏览器界面里面去。写一个分布式的管理脚本不难，写一个界面也不难，但是也许是我的水平不行，这两件事结合起来让他们协同工作还是有点难度的。对我来说，写界面的工作可能更难一点。

Cloudera可能是十来个人在写Manager的东西，ambari也是放到github和apachesvn上面，apache基金会的各种committer在写。easyhadoop没他们功能那么强大，一年来只有我一个人设计架构，功能，各种语言的编码，测试，发布。Fortheloveofgod,WhathaveIdone(英文部分请站在山顶仰天长啸)T_T。从前台到后台，到hadoop和生态系统以及他们的依赖软件的单独patch、编译打包。(系统yum或者apt-get的包不如自己打的好使。)

从时间上来看，全球第一款开源的hadoop部署管理系统应该还是属于ambari，2011年8月开始写的，2012年9月底进入apache的incubator。我是大概2012年8月开始写的easyhadoop，全球第一没赶上，估计国内第一个开源的hadoop管理系统还是可以排上的。

已有设备如何利用？

服务器可以利旧，但要注意兼容性列表和稳定性。

如上介绍，超融合完全基于 x86 、ARM等架构的通用服务器构建，所以用户已有服务器是可以用来构建超融合系统。但需要注意以下几点：

1需要保证服务器以及配件都要严格符合厂商的兼容性列表要求。一般来说，服务器改造成超融合节点还需要加配 SSD、万兆网卡等配件；
2 一个集群中的硬件尽可能地保持配置统一，否则低配置节点会影响整体集群的性能
3尽管超融合的分布式存储有副本保证可靠性，但一般来说超过3年的设备不建议使用，一方面陈旧设备的使用会提升多个设备同时出现故障的概率，影响整体的稳定性；另一方面，老旧设备配件的后续采购也是一大问题。

SAN存储不能用在资源池中，但可以构建冗余的系统

由于超融合系统通过分布式存储软件和 x86 、ARM等架构的通用服务器构建了存储池，所以原有的 SAN 存储和光纤交换机都不需要整合在新系统中。在 SmartX 的客户中，部分用户会将产品用在核心生产业务中，并同时使用原有的存储构建一个冗余的系统。冗余的方式可以采用应用层面的负载均衡和冗余，也可以采用类似 Oracle Data Guard 做数据库层面的冗余（以上方式都需要增加部分服务器），从而在超融合副本等技术的保护之下，再上一层保险。既增加了业务的可靠性，又利用了原有的设备。

分布式概念还是简单的吧，主要是理解为什么要分布式，和分布式主要做什么。
首先分布式的主要作用有以下几点：
1、提高应用的可用性：服务器要保持长时间能够有效的使用，但是现实情况又是很不稳定的，例如电脑会死机，会断电，硬件设备会损坏，使用分布式可以一定程度的解决这些问题。
2、分散服务器运行压力，这本身也是提高应用可用性的一个方面，例如你的应用功能很多，逻辑很复杂，或者 *** 作的数据量较大，单个应用或者机器难以甚至无法处理你的业务，那么就需要使用分布式。
分布式的概念其实也很简单，就是一个应用做不了或者难以做的事情，让多个应用去做，这就好比让一个人去完成的事情让多个人去完成，举个现实中很简单的例子，例如造车，造车这个工作本身一个造车厂可以完成这个任务，只是一个工厂造车，成本、技术、人员等等都会提高制作成本，而且因为技术过于驳杂，一个厂能造，但是成本和难度都会增加，但是拆分给多个厂来造车，例如一个厂造发动机，一个厂造底盘，一个厂造外壳，一个厂做电子仪表盘等等，把各个配件分散给不同的厂制作，这样每个厂专心做自己更专业的事情，这样既降低了成本，有提高了工作效率。
回到我们的web应用，一般来说，一个系统就是一个应用，系统里面有各种功能，例如学生信息管理系统，系统里面包含各种功能，例如用户登录和认证、权限配置和授权、学生信息的管理、学生的入学管理、学生的毕业管理、校友信息管理等等各种功能，但是当学生的数量特别多，内部业务逻辑特别复杂的时候，一个应用可能不能够承担起这个系统的正常运转，那么就可以考虑分布式，来使用多个应用完成这个系统的功能，例如做一个应用负责登录认证模块，一个应用处理授权的功能，另外一个应用处理学生信息的内容等等。
总结分布式，其实就是一个应用的事情让多个应用来解决，分布式是应用级别的分工，在一台机器的多个应用，我们叫垂直分布式，在多台机器上的分布式叫水平分布式，在一台机器的分布式实现起来比较简单，只需要实现应用之间的内存数据共享即可，内存数据共享方式很多，可以使用共享文件等等方式，多台机器的分布式就需要借助网络通信来共享数据，如果是通语言同技术的应用，可以直接共享内存数据，如果是不同语言的分布式应用，就需要参照一些通用传输协议的数据，例如xml json。

服务器集群：
服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。
服务器负载均衡：
负载均衡
（Load
Balancing）
建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
分布式服务器：
所谓分布式资源共享服务器就是指数据和程序可以不位于一个服务器上，而是分散到多个服务器，以网络上分散分布的地理信息数据及受其影响的数据库 *** 作为研究对象的一种理论计算模型服务器形式。分布式有利于任务在整个计算机系统上进行分配与优化，克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷，解决了网络GIS
中存在的数据异构、数据共享、运算复杂等问题，是地理信息系统技术的一大进步。
这个三种架构都是常见的服务器架构，集群的主要是IT公司在做，可以保障重要数据安全；负载均衡主要是为了分担访问量，避免临时的网络堵塞，主要用于电子商务类型的网站；分布式服务器主要是解决跨区域，多个单个节点达到高速访问的目前，一般是类似CDN的用途的话，会采用分布式服务器。
纯手工打字，希望可以帮的到你！

服务器集群：\x0d\ 服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。\x0d\服务器负载均衡：\x0d\\x0d\ 负载均衡 （Load Balancing） 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。\x0d\分布式服务器：\x0d\\x0d\ 所谓分布式资源共享服务器就是指数据和程序可以不位于一个服务器上，而是分散到多个服务器，以网络上分散分布的地理信息数据及受其影响的数据库 *** 作为研究对象的一种理论计算模型服务器形式。分布式有利于任务在整个计算机系统上进行分配与优化，克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷，解决了网络GIS 中存在的数据异构、数据共享、运算复杂等问题，是地理信息系统技术的一大进步。\x0d\这个三种架构都是常见的服务器架构，集群的主要是IT公司在做，可以保障重要数据安全；负载均衡主要是为了分担访问量，避免临时的网络堵塞，主要用于电子商务类型的网站；分布式服务器主要是解决跨区域，多个单个节点达到高速访问的目前，一般是类似CDN的用途的话，会采用分布式服务器。 \x0d\纯手工打字，希望可以帮的到你！

---