[]阿里云香港节点宕机，业务中断13小时
运维派推荐
运维派问答社区是专注于IT运维领域的学习、交流、互助的平台，这是属于IT运维人自己的技术社区。
> []阿里云香港节点宕机，业务中断13小时
1群： - 运维综合
2群： - 运维综合
3群：1689067
- Linux Shell脚本
微信：yunweipai（或扫描以下二维码）
6月21日，阿里云香港节点9点30分左右突然全线崩溃，截止当天晚上22点左右逐渐恢复，历时13小时，并且还不是全面恢复。
甚至有部分用户出现数据丢失，微博网友@routerpipe提出，“网络恢复了，但数据盘数据损毁。”
公有云出现故障宕机并不少见，即使AWS也曾出现过宕机事件，但此次阿里云香港节点13小时的故障让其蒙羞。
据阿里云官方回应称，本次故障因香港运营商IDC电力问题所致，并提到正在香港加快第二机房的建设，开通后将会提供更快速响应的容灾能力。
此回应并没有得到多数用户的认可，“严重怀疑阿里云香港是云计算的服务了，是不是随便在哪个机房租用了几个机柜就号称云计算？”、“所谓的99.999%的可靠性成了一句笑话。”...
长时间的中断也导致很多用户的直接损失，“我今天新游戏上线，广告都打出去了，结果你们害我成这样，这个损失怎么算？”不少用户提出向阿里云索赔。
我们注意到，有部分用户收到了阿里云方面给出的赔偿方案，“提供100倍的故障时间赔偿”，这也是阿里云官网公开的赔偿方案，对应此次是大约2个月左右的使用期限。但这样的方案较多用户并不认同，“业务的损失这个是没有什么标准的，重要的是我流失了客户，失去了信誉这个都不知道怎么追讨。”
有业内从业者指出，“实际上，目前为止也没见过那个传统的服务器厂商，因为服务器崩溃了，要对用户进行赔偿。基本上，大部分用户都会采用两台或多台服务器，考虑和构建容灾高可用方案；云时代，当用户习惯发生转变，购买物理主机也慢慢转变成购买云主机，如何保证云主机的高可用性，混合云环境的服务器高可用性，已然成为了行业热点。”
转载请注明： &
与《[]阿里云香港节点宕机，业务中断13小时》相关的文章.
长微博分享
博主暂未提供此篇文章的长微博，请联系站长。
二维码分享
打开微信（或者其他社交APP），选择“发现”，进入“扫一扫”拍摄即可。匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。检测一台机器是否宕机的应用场景如下：
1, 工作机器宕机，总控节点需要能够检测到并且将原有服务迁移到集群中的其它节点。
2, 总控节点宕机，总控节点的备份节点（一般称为Slave）需要能够检测到并替换成主节点继续对外服务。
检测一台机器是否宕机必须是可靠的。在大规模集群中，机器可能出现各种异常，比如停电，磁盘故障，过于繁忙导致假死等。对于机器假死，如果总控节点认为机器宕机并将服务迁移到其它节点，假死的机器又认为自己还可以提供服务，则会出现多个节点服务同一份数据而导致数据不一致的情况。
首先必须明确，理论上检测另外一台机器是否宕机是无法做到的，有兴趣的同学可以参考Fischer的论文。可以简单理解如下：A机器往B机器发送心跳包，如果B机器不发送响应，A无法确定B机器是宕机了还是过于繁忙，由于A和B两台机器的时钟可能不同步，B机器也无法确定多久没有收到A机器的心跳包可以认为必须停止服务。因此，A机器没有办法确定B机器已经宕机或者采取措施强制B机器停止服务。
当然，工程实践中，由于机器之间会进行时钟同步，我们总是假设A和B两台机器的本地时钟相差不大，比如相差不超过0.5秒。这样，我们可以通过Lease机制进行宕机检测。Lease机制就是带有超时时间的一种授权。假设总控节点需要检测工作节点是否宕机，总控节点可以给工作节点发放Lease授权，工作节点持有有效期内的Lease才允许提供服务，否则主动下线停止服务。工作节点的Lease快要到期的时候向总控节点重新申请Lease（一般称为renewLease），总控节点定时检测所有工作机的Lease授权是否合法，如果发现某台工作机Lease失效，可以将工作机上的服务迁移到集群中的其它机器，这时因为工作机发现自己Lease失效会主动停止服务。当然，这里需要注意，由于总控节点和工作机的时钟可能不一致且有网络延迟，总控节点上的Lease超时时间要长，也就是说，如果工作节点的Lease超时时间是12秒，总控节点可能需要13秒后才能确认工作节点已经停止了服务，从而避免数据不一致问题。
同构节点之间的选主也有一个宕机检测问题。比如总控节点宕机，备份节点需要能够检测并升级为主节点继续对外服务。Mysql数据库经常采用Heartbeat + DRBD (Distributed Replicated Block Device) + Mysql的高可用性方案，据说能够达到3个9的高可用性，主节点和备节点维持Heartbeat心跳，当提供服务的主节点出现故障时，备节点的Heartbeat检测到主节点没有心跳（例如，Ping不通主节点），备节点自动接管虚拟IP，升级为主节点提供Mysql读写服务。由于Heartbeat检测机器主节点宕机不可靠，这个方案存在众所周知的脑裂问题，即集群中可能同时存在多个主节点同时提供服务。解决这个问题本质上还是需要引入仲裁节点，比如Heartbeat + DRBD方案中引入Fence节点使出现问题的节点从集群中脱离，或者引入分布式锁服务，比如Chubby的开源实现Zookeeper服务。分布式锁服务实现主节点选举大致如下：主节点和备节点到Chubby中抢锁，抢到锁的节点在锁的有效期(Lease期)内提供服务，当主节点锁的Lease快要到期时，主节点申请延长锁的超时时间，正常情况下分布式锁服务总是优先满足主节点的请求，当主节点出现故障时，备节点能够抢到锁切换为主节点提供服务。
最后还有一个问题，假设总控节点通过Lease机制检测工作节点是否宕机，这种方案是可靠的，不过当总控节点宕机时，如果不采取任何措施，集群中的所有工作节点都将因为无法重新申请Lease而停止服务，这就是带有总控节点的设计固有的脆弱性，某个设计或者编码的错误都有可能造成严重的影响。解决这个问题一般会有一个叫做Grace Period的机制，工作节点Lease超时时将停止服务，但是工作节点并不一开始就重启或者下线，而是处于一种危险状态(称为Jeopardy)，这种状态持续一个Grace Period，比如45秒。如果在Grace Period 内总控节点重启，工作节点和总控节点重新联系上从而可以切换为正常状态继续提供服务。
您的举报已经提交成功，我们将尽快处理，谢谢！
机构与机器的区别在于：机构只是一个构件系统，而机器除构件系统外还包含电气、液压等其他装置；机构只用于传递运动和力，而机器除传递运动和力之外，还应当有变换或传递能...
组装台式机自由度高，性价比最好，不过由于市场价格波动大、水分多，新手极容易被不良商家坑害，组装机适合对市场有一定了解且动手能力较强的人选择；品牌台式机自由度不高...
由银联，银行，或第三方支付公司直接对商户的机子属于一清，钱“直接”到“商户账户”。二清是指有POS机的商户，再申请增机，卖给你或租赁给你用，你的钱由一清的商户再...
答: 我家有时也会这样
大家还关注11gR2 RAC启用iptables导致节点宕机问题处理
11gR2 RAC启用iptables导致节点宕机问题处理
通常，在安装时，绝大多数都是要求把selinux及iptables关闭，然后再进行安装的。但是在运营商的中，很多安全的因素，需要将现网的数据库主机上的iptables开启的。
在开启iptables时就要注意了，比如一RAC中的hosts配置如下：
192.168.142.115 & & & subsdb1 & & & &&
192.168.142.117 & & & subsdb1-vip &&
10.0.0.115 & & & & & &subsdb1-priv&
192.168.142.116 & & & subsdb2 & & &
192.168.142.118 & & & subsdb2-vip &&
10.0.0.116 & & & & & &subsdb2-priv
192.168.142.32 & & & &db-scan
那么理所当然的要将上面的IP都要放通的。但是在实际操作中，已经放通了上面的IP，结果数据库一的个实例宕掉了。
看看数据库的alert日志：
Tue Aug 20 00:29:40 2013
IPC Send timeout detected. Sender: ospid 8284 [oracle@subsdb2 (LMD0)]
Receiver: inst 1 binc
ospid 15851
IPC Send timeout to 1.0 inc 10 for msg type 65521 from opid 12
Tue Aug 20 00:29:48 2013
IPC Send timeout detected. Sender: ospid 8276 [oracle@subsdb2 (PING)]
Receiver: inst 2 binc
ospid 8276
Tue Aug 20 00:29:52 2013
Detected an inconsistent instance membership by instance 2
Errors in file /oracle/app/oracle/diag/rdbms/gdordb/GDOR/trace/GDORDB2_lmon_8282.trc &(incident=784092):
ORA-29740: evicted by instance number 2, group incarnation 12
Incident details in: /oracle/app/oracle/diag/rdbms/gdordb/GDORDB2/incident/incdir_784092/GDORDB2_lmon_.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My
Support for error and packaging details.
Errors in file /oracle/app/oracle/diag/rdbms/gdordb/GDORDB2/trace/GDORDB2_lmon_8282.trc:
ORA-29740: evicted by instance number 2, group incarnation 12
LMON (ospid: 8282): terminating the instance due to error 29740
Tue Aug 20 00:29:54 2013
ORA-1092 : opitsk aborting process
Tue Aug 20 00:29:54 2013
License high water mark = 29
Tue Aug 20 00:29:57 2013
System state dump requested by (instance=2, osid=8282 (LMON)), summary=[abnormal instance termination].
System State dumped to trace file /oracle/app/oracle/diag/rdbms/gdordb/GDORDB2/trace/GDORDB2_diag_8272.trc
Instance terminated by LMON, pid = 8282
USER (ospid: 31106): terminating the instance
Instance terminated by USER, pid = 31106
单纯从上面来看，初步可以断定是内部通信有问题，但是如何解决？
但再从数据库的alert和ASM实例的alert日志中都有这样的信息：
Private Interface 'bond2:1' configured from GPnP for use as a private interconnect.
& [name='bond2:1', type=1, ip=169.254.148.209, mac=00-25-b5-00-00-67, net=169.254.0.0/16, mask=255.255.0.0, use=haip:cluster_interconnect/62]
Public Interface 'bond0' configured from GPnP for use as a public interface.
& [name='bond0', type=1, ip=192.168.142.116, mac=00-25-b5-00-01-cb, net=192.168.142.0/24, mask=255.255.255.0, use=public/1]
Picked latch-free SCN scheme 3
从这个信息来看，RAC的内部通信还要用到net=169.254.0.0/16的IP，再从MOS Doc ID 也有这样的说明，最后用ifconfig查到了RAC的两个节点中使用到的169网段的IP为：
169.254.122.59
169.254.148.209&
在iptables中放通了这两个IP后，集群正常。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'}