关于diarc系统的运行和维护的思考以及可行性建议

PS组中的兄弟

关于我们公司服务器架构的可行性分析，我想在几个方面进行详细说明. 当然，将详细解释，并且将想象出来. 最终计划需要由小青进行审查. 一个好的计划不仅要满足，而且当前的需求也可以满足未来三年的需求.

1. 系统监控

在这方面，我们的系统运维团队会遇到麻烦. 80 SUN服务器的流量过多，导致从问题生成到问题解决的100M共享中的所有服务器访问速度太慢. 经过漫长而痛苦的一天. 由于这个问题，周波同志几乎被上海办事处的同事杀死. 如今，EDM的集中传输还导致网络拥塞. 我们花了将近4个小时才找到问题所在. 对于我们的运维团队来说，这不只是一记耳光. 这反映出我们的运维团队的运维水平较低. 记得和烧酒聊天. 他说，为什么要无故在屋子里播放歌曲？我说我们的服务器挂了. 哦，很好. 我知道挂断电话的时间. 是的，我们知道何时到达服务器挂起. 我们成功了吗？不，不，为什么在服务器挂起之前我们无法知道. 我们应该始终清楚了解服务器的CPU，I / O，内存，带宽和一些正在运行的服务. 我们的运营团队可以满足这一要求. 它也能够满足此要求. 3月底，我们对监控软件进行了实验研究. 后来，由于IDF，它不得不被中断. 从实验结果我们知道. 他符合我们目前的情况. 同时，它也可以满足公司未来几年的发展需求（以目前的发展速度）. 在前两个痛苦中，我们应该加快步伐，并让此监视软件为企业服务. 我们希望用1个月的时间来改善和丰富他，以满足我们企业的要求. 我们的服务器也会定期自动重启. 应用程序服务的自动重新启动已应用. 例如: 我们的Windows服务器每5天自动重启一次，而我们的tomcat应用服务软件则每3天自动重启一次. 解决了一些网站的应用问题. 例如: 几天后，尽管tomcat界面仍然存在，但无法访问该网站. 或者是因为服务器已经运行了很长时间，并且内存利用率非常高，导致服务器运行缓慢等等.

2. 前端应用程序

去年，在2008年10月中，Tim提出了我们是否也可以利用云计算来做点事情，然后投资于人力. 出于热情，我们遭受了挫折，跌倒了，站起来，再次跌落和攀爬，在此期间充满了欢乐和短暂的困惑. 当然，大多数时候都遇到挫折和压力，但我必须承认，我们所经历的困难加剧了某些情况. 我记得这次IDF会议，我特别听了英特尔关于云计算的工作报告，其中的一个问题和答案给我留下了深刻的印象. 一名技术人员向北京交通大学的博士生问了一个问题: 网格非常流行. 火灾发生时，该国向大学注入了大量资金，以进行该领域的研究，但直到现在，我们还没有看到一所能从电网方面为社会带来好三月份要求建立一个网站. 功能很简单，一个注册即可，注册后可以观看视频，但是这个网站有很多访问，而且架构需要精心设计. 针对这种情况，我们的想法是: apache + tomcat + mssql架构，当然，如果它不能满足应用程序的需求，我们计划使用小型负载平衡和代理缓存服务器Squid，一方面是架构设计，调音也是非常重要的方面. 我认为我们有以前的技术沉淀，我们对这种体系结构的实施仍然有一定的信心. 至于时间安排和具体的实施策略，我想小青会给我们很好的指导.

3. 网络架构:

在进行了sun活动之后，我们分离了sun服务器. 在经历了这个EDM组之后运维技术可行性分析，我们是否应该分离一个单独的EDM邮件服务器？通过这种网络访问方法，100M共享已逐渐无法满足我们的需求. 根据业务部门，我们应该添加另一个邮件服务器吗？同时，根据监控需要，我们需要一台nagios监控服务器. 邮件服务器的分离和sun服务器的分离，使得这两个服务器暴露在外部环境中，无论是否需要添加防火墙以提高系统的安全性或通过防火墙解决安全性问题和系统本身的iptables. 如果按照目前的形式和到年底的时间，我们将增加很多业务，我们需要购买几台服务器，那么我们应该购买硬件防火墙，这需要我们的系统运维团队做出准确的决定判断. 我认为我们的运维团队聚集在一起讨论此问题. 还有一个服务器接线系统. 目前，我们的网络电缆布局混乱无序. 我们需要花一些时间来组织. 排序的优点是不再需要断开网络连接，因为机房工作人员会重新启动服务器. 这样的问题以前已经发生过很多次了，我想每个人都还记忆犹新.

4. 灾难恢复.

我告诉Tony，DAS，NAS和SAN的技术概念. 实际上，这个概念仅仅是一个概念. 是捉老鼠的好猫. 根据以上网络架构，我们应该使用NAS. 这次我们购买了96个服务器中有意安装了1T硬盘. 仅针对我们的备份，如何使用我们的备份软件和备份策略. 有一个非常好的备份软件: NBU，当然是我们之前讨论过的rsync，最终我们选择了什么，实际上，已经有了标准:

第一: 易用性，第二: 稳定性，第三: 恢复效率，基于这三点，我认为每个人都应该选择NBU. 举一个例子: 关于备份，如果我们不选择NBU，我们只能将完整备份到本地，然后复制到96，然后删除本地文件，即使这样做仍然会引起问题，如何处理差异备份问题. 如果选择NBU，则完全不必担心这些事情. NBU解决了所有这些问题，并选择了备份软件，然后我们应基于该软件来开发自己的备份策略. 目前，我的想法还不够成熟，我们将在运维团队见面时进行详细讨论.

5. 性能测试.

应该说我们的业务主要是基于cisco和sun的业务，但是我们的触角也已经扩展到门户网站. 看完蒂姆最近的邮件后，香港旅游发展局有一个项目. 这也是一个门户网站. 谁敢说我们的滚石网站可以容纳多少PV流量. 不，这是因为我们没有底线，我们自己也没有通过压力测试和性能测试. 这是我们运维团队的真空. 滚石项目和即将到来的香港旅游发展局项目为我们提供了一个很好的机会来为我们测试这一作品. 这与构建后缀邮件服务器时的句子相同. 一无所知运维技术可行性分析，但我们仍然有信心！

6. 服务架构

我记得最初提出了“服务模块化”的概念，即某个服务器集中在一个或多个服务器上，并且专用于此服务. 最初提出该建议时，蒂姆未批准. 我认为我们现在应该分析该计划的可行性，并考虑具体实施. 的模块化，前端应用程序的模块化，灾难恢复和备份的模块化等，这有利于资源的统一规划，也有利于每个inode的压力缓解（通过负载均衡措施）

仅谈谈这六点，我们小组需要共同努力，当然需要不同的声音. 这样的团体充满活力. 我只是说我的想法. 可行性和实施计划需要大家的共同意见和小青的审计.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-245380-1.html