IT运维技术讨论之三：如何满足运维不间断服务的需求

dengbao2001

一介村夫 发表于 2015-01-11 01:26
ChinaRen还在啊

校友录不在啊

现在没个人还用ChinaRen呀

一介村夫

dengbao2001 发表于 2015-01-12 10:53
校友录不在啊

现在没个人还用ChinaRen呀

是打不开了，但是自己的主页上的信息还有。

dengbao2001

欢迎大家就此话题发表意见，谢谢！踊跃参与话题者，就有机会获得《24小时365天不间断服务：服务器/基础设施核心技术》

niao5929

高可用是必须的应用场景。现在最终要的是如何解决我们面对的停机问题。使用传统的HA，是用资源的并行和浪费来满足系统稳定性的。不过现在的LINUX系统倒是有更高级的集群系统。但其管理成本太高。我们如何能更高效的利用细胞节点的计算资源。同时降低整体集群系统的部署难度这些很值得学习和研究。模块化的细胞节点更有利于构建分布式并行集群系统。这需要细胞节点操作系统本身的系统本地化强大功能。事实上我们目前的高可用系统正是首先因为细胞节点的能力比之前的计算节点性能提高了很多倍，因此我们才创造了更大的集群系统应用池。所以一味的强调云是个很扯淡的事情。我个人还是认为，我们首先需要本地功能足够强大的细胞节点系统。这样才可以有真正的高可用

dengbao2001

niao5929 发表于 2015-01-12 13:39
高可用是必须的应用场景。现在最终要的是如何解决我们面对的停机问题。使用传统的HA，是用资源的并行和浪费 ...

除了应用层，网络层，服务器层，存储层，都可以谈谈嘛

不间断服务应该需要多个层面的配合，简单的一个机房停电，你的服务器HA马上就不能HA了，你说呢

bbzsxjj

1.就你工作的的本身，谈谈你是否需要冗余和高可用？
  我们是IT行业，对用户访问质量要求很高，冗余/高可用是必须做到要求！
2.如果需要冗余或者高可用，你是如何实现的？使用商业解决方案？还是开源解决方案？
  冗余/高可用一般使用keepalived/haproxy/nginx去实现，在选择服务方面，一般选择分布式的系统，比如:fastdfs,mongdb，利用分布式系统自身的冗余/高可用机制保证业务正常运行，硬件本身可以使用raid机制保障磁盘的高可用，虚拟化的完整解决方案也可以，不过
  商业的解决
3.你的工作环境发生因冗余或者高可用导致的事故吗？你是如何防止该类事故的再次发生？
  一般都是单点故障导致事故，高可用本身的故障，一般出现在使用方法和数据一致性问题导致故障，只要做好监控，一般可以较快的发现此类故障。  

dengbao2001

bbzsxjj 发表于 2015-01-12 13:52
1.就你工作的的本身，谈谈你是否需要冗余和高可用？
  我们是IT行业，对用户访问质量要求很高，冗余/高可用 ...

网络层面呢，也可以谈谈吗



也可以谈谈具体的应用方面的HA

比如文件服务器，邮件服务器，数据库服务器都可以举例说明下嘛

bbzsxjj

回复 17# dengbao2001


    网络方面：
         内网： 一般可以使用双线接入，双链路方式保障
         外网：一般使用CDN，跨机房，智能DNS来保障
    比如：
         一个简单的WEB冗余系统：
              1.前端缓存使用CDN加速服务，有条件引入多家CDN，使用智能DNS对线路进行分配。
              2.内部系统，可以使用keepalive+nginx做前端web服务器，使用双master方式保障冗余/高可用及资源的利用
              3.网络方面使用双线接入，可以使用cisco自己的链路冗余方案保障
              4.文件系统可以使用fastdfs+nginx，使用fastdfs的storage的冗余方式保障一组服务器中任意宕机1台服务器不影响业务，并使用keepalived+2台tracker服务，利用虚拟ip保                       障trackersever的高可用。
              5.最关键的部分，监控业务逻辑及系统层，有异常需要及时报警。
              另外也有些其他的方法，总之思想就是单点绝对不能存在在系统的架构中，多用分布式/集群/HA，具体的需要根据实际情况搭配，越简单越好，切忌把架构搞的过于复杂，层次越简单效率越高，越好管理。

dengbao2001

bbzsxjj 发表于 2015-01-12 15:06
回复 17# dengbao2001

你说的都是当前你们系统的实现方法吗？

bbzsxjj

回复 19# dengbao2001


    恩，这些基本都是通常自己搞的时候的一些实现方法，具体的问题具体对待！看投入成本/需求/管理去考虑方案。