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

rickcafe

本期话题：
1.就你工作的的本身，谈谈你是否需要冗余和高可用？

我们是给客户做系统建设和服务的，很多客户需要冗余和高可用的系统；

一般来说，只要涉及公共利益的运营平台或企业核心业务系统，都会有7*24小时不间断的服务要求，比如电子商务（如网上商城）、金融服务机构（如网银、网上交易）、政府公共平台（如海关EDI）、企业重要生产系统（如ERP、CRM、MES、PDM、SCM）等等。

因为社会已经信息化了，人们的日常生活、企事业单位的正常运作无不依赖于IT系统，信息系统对保障业务的连续性越来越重要，所以冗余和高可用也是遍地都是。就算是小微企业的金蝶ERP也不希望跑在单个硬盘上吧？硬盘坏了，丢失数据，停机好几天，老板都要骂人了，何况大点的企业和客户。


2.如果需要冗余或者高可用，你是如何实现的？使用商业解决方案？还是开源解决方案？

实现有很多种档次的，很多种方式，不一而论，如本地冗余、灾备系统等……。

服务器：如RAID技术、集群技术等；
存储：如RAID、本地镜像、克隆、卷复制、基于存储设备间的数据复制（同步、异步）、存储虚拟化、CDP等等；
应用：同城容灾、异地容灾、双活数据中心、两地三中心、数据库级的灾备（如Oracle的Data Guard、MYSQL、SQL Server的主从模式）、主机系统+应用级别的容灾、基于第三方软件（如VCS）的容灾，基于虚拟化的容灾（如VMware的HA、FT、SRM）

商业还是开源？

当然是商业解决方案了。有技术支持，有服务，重要的是有法律免责。否则使用免费软件，系统宕了，数据丢了，影响公共利益了，触犯法律了，需要有人坐牢了，那谁来负责呢？总不是是选择和使用免费软件的IT工程师吧？如果不是他，那还能是谁呢？就是他干的，就他级别最低。所以为了法律风险了也不能用免费的、开源的。除非是小企业，什么都是老板说了算，出事了他可以跑路，人间蒸发，那无所谓了，大家随便搞吧。


3.你的工作环境发生因冗余或者高可用导致的事故吗？你是如何防止该类事故的再次发生？

因冗余或高可用导致的事故？这倒是很少听说，本来就解决系统可靠性、可用性的问题，结果自己成了问题了，成了故障点。这种现象确实很罕见。

不过也不是没有，常在河边走，谁能不湿鞋？

以前我维护过一个客户的sun HA双机数据库系统，集群软件用的是sun cluster 3.1。sun cluster是别人装的，可能是安装有问题，用solaris explorer命令采集系统数据时，会把sun cluster的软件程序都“采集”进来，造成采集数据包往往是200多MB，一般正常的只有1、2MB；有次维护客户系统时，因不太了解sun cluster的技术细节，建议客户将一些sun cluster生成的“无用的”日志数据移动另外一个备份目录，以减少explorer的采集数量，客户同意了。结果我刚操作完，sun cluster立刻宕掉了，启也启不来，吓坏了，定了定神，才想起可能和这个操作有关，再将sun cluster的“垃圾数据”移回来，sun cluster就恢复正常了，虚惊一场。这可是7*24小时不能宕机的系统，绝对影响全市人民利益，每次停机都要发公告的，出了事绝对是重大责任事故，谁也兜不住，市长都会打电话的，当时吓的一身冷汗。

还有一次是IBM小机双机+Oracle RAC，客户需要更换网络设备，重新插拔所有小机网线，会导致Oracle CRS的 VIP暂时失效，这本来不是事，但用户没有记得private IP、也记错了public IP地址，导致两台小机全登录不进去（当然登录不进去了），结果无法重启Oracle RAC；当时误以为是小机网卡故障了（客户坚持说他没记错IP），搞的一片紧张，后来花了几个小时才找到正确的IP，才登录进去维护，当时也是吓得半死+一对雾水+不可思议。

问题的原因分析很简单。高可用系统往往有其技术的复杂一面，如果不了解相关的技术和前人的配置，不要自以为是的擅自修改，擅自处理，一定要注意规范细节。

同时，系统一定要留有完整的安装配置文档。如果没有文档，就要在维护中加以整理完善。在做重要操作时，一定要有基础的配置文档做支撑，有回退的预案，并向客户说明整个操作流程，提醒重要的注意点。

千万不要想当然。你以为我知道，我以为你知道，你以为我懂，我以为你懂，结果大家全不知道，全不懂，这才是最可怕的。

为什么容灾系统需要演练呢？就是因为大家都不熟嘛。去年宁夏银行宕机30多个小时，造成银行业的重大事故，不就是因为不懂不熟不会操作，没买服务嘛。以为特简单的事，随便一操作，结果整个系统都挂掉，挂掉之后因为技术水平不行，就判断不了，解决不了，都傻在那儿。

光有技术的高可用没用的，还要人的高可用。

唉，说了半天废话，就是要完善系统运维管理制度、操作规范、操作流程，**和保存系统的技术文档，努力提高自己的技术水平，按规矩办事。

dengbao2001

rickcafe 发表于 2015-01-31 21:08
本期话题：
1.就你工作的的本身，谈谈你是否需要冗余和高可用？

感谢你的分享，你的经验值得我们借鉴和学习

有机天使

1.就你工作的的本身，谈谈你是否需要冗余和高可用？
  我们是搞油田应用的，这几年油田对信息化的**程度明显增加，陆续投入了不少钱，所以我现在这边管理的机房设备必须是24小时不间断的，因为井场是24小时工作的，数据会持续不断的传输到机房，所以主数据服务器必须要冗余。

2.如果需要冗余或者高可用，你是如何实现的？使用商业解决方案？还是开源解决方案？
  我们的数据服务器是SUN M8000，两台主机划分了四个域，之前一直是采用solaris的Cluster集群来做，但由于此集群中间出了不少问题，而且空闲了2个域，比较资源浪费，所以前阵子我们更换成Oracle RAC集群了，但目前还有点问题（莫名的出现某一台主机数据库内存消耗达到80%以上，可我们生产环境还没正式投入，谁知道问题出哪里啊），另外我们对部分服务器使用的是windows的故障转移集群，实现Hyper-V的漂移，另外就是大部分的服务器是应用了vmware虚拟化，用的ESXi 环境，自带HA，还是比较方便。但我们有一个web服务器目前居然还是裸机，无HA，我觉得实在不应该，由于我们这边很少linux 的系统，所以开源的产品用的很少，对windows web的HA有啥好的方法吗？

3、你的工作环境发生因冗余或者高可用导致的事故吗？你是如何防止该类事故的再次发生？
  服务器的事故虽然发生过，但由于有HA机制，到没太大影响，但存储出过2次事故：
（1）、 一次是低端存储故障：低端存储当初做的时候可能就没做好，由于停电导致磁盘故障，结果一下坏了3块盘，而存储的热备盘当初虽然是设置了，但不知道为何居然这次没起作用，造成了数据丢失，而且raid的磁盘分配也存在不合理，导致后期想数据恢复的时候所需要恢复的磁盘过多，成本太高，后来还好数据不是太重要，也就作罢了，如今是将存储配置全部重新制作，特别是热备盘这次专门还做了实验，检测是否可以起作用，但存储的HA确实么有好的办法。
（2）、第二次是日立的一个高端存储，也是机房突然停电，UPS待机时间不足，造成了日立存储设备断电，部分数据受损，不过高端的存储其本身内部机制还是完善的，所以数据总算没有大的损失，不过当时也是吓坏了，害的存储工程师坐着飞机连夜赶赴现场，总算抢救过来了，所以我现在对存储的高可用也是很头疼，暂没找到合适的方法，不知道大家有啥好的方法吗？最好是经济的方案，花大钱的估计是没戏

有机天使

1.就你工作的的本身，谈谈你是否需要冗余和高可用？
  我们是搞油田应用的，这几年油田对信息化的**程度明显增加，陆续投入了不少钱，所以我现在这边管理的机房设备必须是24小时不间断的，因为井场是24小时工作的，数据会持续不断的传输到机房，所以主数据服务器必须要冗余。

2.如果需要冗余或者高可用，你是如何实现的？使用商业解决方案？还是开源解决方案？
  我们的数据服务器是SUN M8000，两台主机划分了四个域，之前一直是采用solaris的Cluster集群来做，但由于此集群中间出了不少问题，而且空闲了2个域，比较资源浪费，所以前阵子我们更换成Oracle RAC集群了，但目前还有点问题（莫名的出现某一台主机数据库内存消耗达到80%以上，可我们生产环境还没正式投入，谁知道问题出哪里啊），另外我们对部分服务器使用的是windows的故障转移集群，实现Hyper-V的漂移，另外就是大部分的服务器是应用了vmware虚拟化，用的ESXi 环境，自带HA，还是比较方便。但我们有一个web服务器目前居然还是裸机，无HA，我觉得实在不应该，由于我们这边很少linux 的系统，所以开源的产品用的很少，对windows web的HA有啥好的方法吗？

3、你的工作环境发生因冗余或者高可用导致的事故吗？你是如何防止该类事故的再次发生？
  服务器的事故虽然发生过，但由于有HA机制，到没太大影响，但存储出过2次事故：
（1）、 一次是低端存储故障：低端存储当初做的时候可能就没做好，由于停电导致磁盘故障，结果一下坏了3块盘，而存储的热备盘当初虽然是设置了，但不知道为何居然这次没起作用，造成了数据丢失，而且raid的磁盘分配也存在不合理，导致后期想数据恢复的时候所需要恢复的磁盘过多，成本太高，后来还好数据不是太重要，也就作罢了，如今是将存储配置全部重新制作，特别是热备盘这次专门还做了实验，检测是否可以起作用，但存储的HA确实么有好的办法。
（2）、第二次是日立的一个高端存储，也是机房突然停电，UPS待机时间不足，造成了日立存储设备断电，部分数据受损，不过高端的存储其本身内部机制还是完善的，所以数据总算没有大的损失，不过当时也是吓坏了，害的存储工程师坐着飞机连夜赶赴现场，总算抢救过来了，所以我现在对存储的高可用也是很头疼，暂没找到合适的方法，不知道大家有啥好的方法吗？最好是经济的方案，花大钱的估计是没戏

rickcafe

回复 134# 有机天使


    请问这个日立存储是什么型号的？

dengbao2001

感谢各位呀！

这个活动都结束了，还有这么多朋友参与活动

dengbao2001

汗一个。。。。。。

shark010

做个记录。。。。。