PS组的兄弟们：
关于我们公司的服务器架构的可行性分析我想分几个方面来阐述一下，当然阐述归阐述，畅想归畅想，最后方案的确定还需小清的审核，一个好的方案不仅仅满足目前的需求，同时能够对未来的3年也能应对。
1.系统监控
这一块儿，我们系统运维小组有切肤之痛。80的SUN服务器因流量过大造成我们整个100M共享里面所有服务器的访问过慢，从问题的产生到问题的解决。经历了一个很漫长很痛苦的一整天。周波同志差点因为这个问题被上海办的同仁用板砖拍死。今天由于EDM的集中发送同样造成了网络的拥塞。我们寻找问题所在也用了将近4个小时。这对于我们运维小组而言，不单单是被打一巴掌，被说几句的问题。这体现了我们运维小组的运维水平不高。记得当初和soju一起聊天。他说，怎么小屋子里面无缘无故的播放歌曲？我说，是我们的服务器挂了。奥，这样，这样挺好呀，挂了就知道。是的，我们达到了服务器挂掉我们就知道。我们算是有成果了吗？不，不能，为什么我们不能在服务器挂掉之前我们就知道。我们应该时时对我们服务器的CPU，I／O，内存，带宽以及一些运行的服务一目了然。我们运维小组可以达到这个要求。也有能力达到这个要求。3月底，我们对一款监控软件进行了实验性研究。后来因为IDF的加入，不得不中断。我们从实验结果可知。他是符合我们目前的状况。同时也可以应对未来的几年公司发展的需要（就目前的发展速度），有了前两次的惨痛，我们应该加快我们的步伐让这款监控软件来为企业服务，我们预计利用1个月的时间，来完善和丰富他，使之达到我们企业的要求。还有就是我们服务器周期性自动重启已经应用服务的自动重启，举个例子：我们的windows服务器5天自动重启一次，我们的tomcat应用服务软件3天自动重启一次。这样就解决了一些网站的应用问题。比如说：经过几天，tomcat虽然dos界面还在，但是网站就是不能访问。或者因为服务器运行了很长的时间，内存利用很大造成服务器很慢等问题。
2.前端应用
去年，也就是2008年10月中旬，Tim提出来我们是不是也能在云计算方面作一些东西出来，然后投入了人力，我们从满腔热情，到遭受挫折，跌倒了，爬起来，再跌倒，再爬起，期间有欢欣鼓舞，也有短暂的迷茫，当然其中大部分时间是在经受挫折和压力，但是不得不承认我们经历的这些磨难还是沉淀了一些东西的。记得这次IDF大会，我专门去听了Intel关于云计算作的工作汇报，其中一个问答给我留下了深刻的印象，一个技术员向北京交通大学的博导提出一个问题：当初网格炒的很火的时候，国家向大学注入了很多的钱来进行这方面的研究，但是到现在我们也没看到哪儿一所大学在网格方面给社会带来效益，现在云计算又很火，国家还是投入了很多的钱到大学，我想问，这次是不是也和网格一样，无疾而终，记住，国家的钱是用我们纳税人的。这个问题一经提出，立刻博得热烈的掌声。当然博导回答问题也很真诚：他说，是的，你说的是没有错的。我们经历了网格时代，到现在又开始了云计算时代。如果没有当初的网格方面的研究，我们对现在的云就没有这么好的了解，也不能在过去的这段时间里能和铁道部共同交流，对目前铁路运输提出这么样的架构。博导的回答同样也博得了一片掌声。我想说的是，3月份，Grace大姐提出了一个需求，就是建立一个网站。功能简单，一个注册，注册完毕之后能看视频，但是这个网站的访问量很大，需要架构设计的很良好。针对这种情况我们的想法是：apache+tomcat+mssql的架构，当然假如无法满足应用，我们打算采用小型负载均衡和代理缓存服务器Squid，一个架构设计是一方面，调优又是另外很重要的方面。我想我们有以前的技术沉淀，我们对这个架构的实施还是有一定信心的。至于时间点和具体实施策略，我想小清会给我们作很好的指导。
3。网络架构：
经历了一次sun做活动我们把sun服务器给分离出去了。经历这次EDM的群发，是不是我们应该把一台单独的EDM邮件服务器给分离出去，就目前这种网络接入方式，100M共享已经渐渐不能满足我们的需要了。根据业务划分我们是否应该再增加一台邮件服务器，同时根据监控的需要我们需要一台nagios监控服务器。邮件服务器的分离和sun服务器的分离，这样这两台服务器就裸露在对外的环境中，是否需要增加一台firewall来增加系统的安全性还是通过系统本身的防火墙和iptables来解决安全问题。假如根据目前形式以及到年底的时间里，我们会增加很多的业务，我们需要购买几台服务器，那我们就应该来购买硬件firewall，这需要我们系统运维组进行准确的判断。此问题我想我们运维小组集中起来进行开会探讨了。还有服务器的布线系统，目前我们的网线布置是杂乱的，无序的。我们需要拿出特定的时间来进行整理。整理的好处就是再也不用因为机房工作人员重启服务器造成网络断线了。这样的问题以前发生过多次，我想大家还是记忆犹新的。
4。容灾备份。
DAS，NAS，SAN这个几个技术概念我给tony讲过，其实概念只是概念，逮到老鼠的才是好猫，根据上述的网络架构，我们应该采用的是NAS，我们这次购置的96服务器特意安装了1T硬盘。就是为了我们的备份，那我们的备份软件及备份策略怎么采用。有一款非常棒的备份软件就是：NBU，当然还有我们以前讨论的rsync,我们到底选用什么，其实已经有了标准：
第一：易用性，第二：稳定性，第三：恢复效率，根据这三点我想大家应该会选择NBU了。据个例子：关于数据库的backup，假如我们不选用NBU，只能先把数据库进行完整备份到本地，然后拷贝到96，然后再删除本地文件，即使这样还是产生了问题，对于差异备份怎么处理的问题。假如我们选用NBU，完全不用为这些事情操心。NBU解决了这一切，备份软件选定，那我们就应该立足此软件制定属于我们自己的备份策略，就目前来说，我的想法还不够成熟，等我们运维小组开会再作详细讨论。
5。性能测试。
应该说我们企业现在是以cisco和sun的业务为主，但是我们的触角也延展到了门户网站，看了Tim最近的邮件有一个香港旅游局的项目，这同样是门户性网站。我们小组的谁敢说，我们的滚石网站可以容纳多少多少的PV流量。不能，是因为我们自己没底，我们自己也没有经过压力测试，性能测试。这块儿对我们运维小组而言，是一片真空。滚石的项目和即将到来的香港旅游局的项目给了我们很好的契机，对我们测试这块儿是一个很好的磨练，还是当初搭建postfix邮件服务器时的那句话，虽然我们对此一无所知，但我们仍然自信满满！
6。服务架构
我记得当初提出过“服务模块化”的概念，就是把某种服务器集中到某台或者某几台服务器上，独立出来专门做此服务。当初提出时，在Tim那里没有获得通过，我想我们现在应该对此方案的可行性进行分析并考虑具体实施了。数据库模块化，前端应用模块化，容灾备份模块化等等，这样作，有利于资源的统一规划，同样也有利于各个inode的压力缓解（通过负载均衡措施）
关于我们公司的服务器架构的可行性分析我想分几个方面来阐述一下，当然阐述归阐述，畅想归畅想，最后方案的确定还需小清的审核，一个好的方案不仅仅满足目前的需求，同时能够对未来的3年也能应对。
1.系统监控
这一块儿，我们系统运维小组有切肤之痛。80的SUN服务器因流量过大造成我们整个100M共享里面所有服务器的访问过慢，从问题的产生到问题的解决。经历了一个很漫长很痛苦的一整天。周波同志差点因为这个问题被上海办的同仁用板砖拍死。今天由于EDM的集中发送同样造成了网络的拥塞。我们寻找问题所在也用了将近4个小时。这对于我们运维小组而言，不单单是被打一巴掌，被说几句的问题。这体现了我们运维小组的运维水平不高。记得当初和soju一起聊天。他说，怎么小屋子里面无缘无故的播放歌曲？我说，是我们的服务器挂了。奥，这样，这样挺好呀，挂了就知道。是的，我们达到了服务器挂掉我们就知道。我们算是有成果了吗？不，不能，为什么我们不能在服务器挂掉之前我们就知道。我们应该时时对我们服务器的CPU，I／O，内存，带宽以及一些运行的服务一目了然。我们运维小组可以达到这个要求。也有能力达到这个要求。3月底，我们对一款监控软件进行了实验性研究。后来因为IDF的加入，不得不中断。我们从实验结果可知。他是符合我们目前的状况。同时也可以应对未来的几年公司发展的需要（就目前的发展速度），有了前两次的惨痛，我们应该加快我们的步伐让这款监控软件来为企业服务，我们预计利用1个月的时间，来完善和丰富他，使之达到我们企业的要求。还有就是我们服务器周期性自动重启已经应用服务的自动重启，举个例子：我们的windows服务器5天自动重启一次，我们的tomcat应用服务软件3天自动重启一次。这样就解决了一些网站的应用问题。比如说：经过几天，tomcat虽然dos界面还在，但是网站就是不能访问。或者因为服务器运行了很长的时间，内存利用很大造成服务器很慢等问题。
2.前端应用
去年，也就是2008年10月中旬，Tim提出来我们是不是也能在云计算方面作一些东西出来，然后投入了人力，我们从满腔热情，到遭受挫折，跌倒了，爬起来，再跌倒，再爬起，期间有欢欣鼓舞，也有短暂的迷茫，当然其中大部分时间是在经受挫折和压力，但是不得不承认我们经历的这些磨难还是沉淀了一些东西的。记得这次IDF大会，我专门去听了Intel关于云计算作的工作汇报，其中一个问答给我留下了深刻的印象，一个技术员向北京交通大学的博导提出一个问题：当初网格炒的很火的时候，国家向大学注入了很多的钱来进行这方面的研究，但是到现在我们也没看到哪儿一所大学在网格方面给社会带来效益，现在云计算又很火，国家还是投入了很多的钱到大学，我想问，这次是不是也和网格一样，无疾而终，记住，国家的钱是用我们纳税人的。这个问题一经提出，立刻博得热烈的掌声。当然博导回答问题也很真诚：他说，是的，你说的是没有错的。我们经历了网格时代，到现在又开始了云计算时代。如果没有当初的网格方面的研究，我们对现在的云就没有这么好的了解，也不能在过去的这段时间里能和铁道部共同交流，对目前铁路运输提出这么样的架构。博导的回答同样也博得了一片掌声。我想说的是，3月份，Grace大姐提出了一个需求，就是建立一个网站。功能简单，一个注册，注册完毕之后能看视频，但是这个网站的访问量很大，需要架构设计的很良好。针对这种情况我们的想法是：apache+tomcat+mssql的架构，当然假如无法满足应用，我们打算采用小型负载均衡和代理缓存服务器Squid，一个架构设计是一方面，调优又是另外很重要的方面。我想我们有以前的技术沉淀，我们对这个架构的实施还是有一定信心的。至于时间点和具体实施策略，我想小清会给我们作很好的指导。
3。网络架构：
经历了一次sun做活动我们把sun服务器给分离出去了。经历这次EDM的群发，是不是我们应该把一台单独的EDM邮件服务器给分离出去，就目前这种网络接入方式，100M共享已经渐渐不能满足我们的需要了。根据业务划分我们是否应该再增加一台邮件服务器，同时根据监控的需要我们需要一台nagios监控服务器。邮件服务器的分离和sun服务器的分离，这样这两台服务器就裸露在对外的环境中，是否需要增加一台firewall来增加系统的安全性还是通过系统本身的防火墙和iptables来解决安全问题。假如根据目前形式以及到年底的时间里，我们会增加很多的业务，我们需要购买几台服务器，那我们就应该来购买硬件firewall，这需要我们系统运维组进行准确的判断。此问题我想我们运维小组集中起来进行开会探讨了。还有服务器的布线系统，目前我们的网线布置是杂乱的，无序的。我们需要拿出特定的时间来进行整理。整理的好处就是再也不用因为机房工作人员重启服务器造成网络断线了。这样的问题以前发生过多次，我想大家还是记忆犹新的。
4。容灾备份。
DAS，NAS，SAN这个几个技术概念我给tony讲过，其实概念只是概念，逮到老鼠的才是好猫，根据上述的网络架构，我们应该采用的是NAS，我们这次购置的96服务器特意安装了1T硬盘。就是为了我们的备份，那我们的备份软件及备份策略怎么采用。有一款非常棒的备份软件就是：NBU，当然还有我们以前讨论的rsync,我们到底选用什么，其实已经有了标准：
第一：易用性，第二：稳定性，第三：恢复效率，根据这三点我想大家应该会选择NBU了。据个例子：关于数据库的backup，假如我们不选用NBU，只能先把数据库进行完整备份到本地，然后拷贝到96，然后再删除本地文件，即使这样还是产生了问题，对于差异备份怎么处理的问题。假如我们选用NBU，完全不用为这些事情操心。NBU解决了这一切，备份软件选定，那我们就应该立足此软件制定属于我们自己的备份策略，就目前来说，我的想法还不够成熟，等我们运维小组开会再作详细讨论。
5。性能测试。
应该说我们企业现在是以cisco和sun的业务为主，但是我们的触角也延展到了门户网站，看了Tim最近的邮件有一个香港旅游局的项目，这同样是门户性网站。我们小组的谁敢说，我们的滚石网站可以容纳多少多少的PV流量。不能，是因为我们自己没底，我们自己也没有经过压力测试，性能测试。这块儿对我们运维小组而言，是一片真空。滚石的项目和即将到来的香港旅游局的项目给了我们很好的契机，对我们测试这块儿是一个很好的磨练，还是当初搭建postfix邮件服务器时的那句话，虽然我们对此一无所知，但我们仍然自信满满！
6。服务架构
我记得当初提出过“服务模块化”的概念，就是把某种服务器集中到某台或者某几台服务器上，独立出来专门做此服务。当初提出时，在Tim那里没有获得通过，我想我们现在应该对此方案的可行性进行分析并考虑具体实施了。数据库模块化，前端应用模块化，容灾备份模块化等等，这样作，有利于资源的统一规划，同样也有利于各个inode的压力缓解（通过负载均衡措施）
就说这六点吧，我们小组需要群策群力，当然需要不同的声音。这样的小组才具有活力，我只是说出我的想法，可行性及实施方案需要大家的共同意见及小清的拍案审核。
本文转自guoli0813 51CTO博客，原文链接：http://blog.51cto.com/guoli0813/148599，如需转载请自行联系原作者
