s*********b
发帖数: 815 | 1 基础架构出问题的几率其实挺高的，关键是系统架构要在设计时就考虑到怎么容错，而
应用层的架构和Amazon又没有关系。这次AWS的问题出在一个Availability Zone
(us-east-1c)里的EBS服务抽风，因为一坨所谓的"network event"就开始大规模地执行
镜像操作，直接导致依赖EBS做数据服务底层的系统挂掉。偏偏大票startups都用EBS，
或者用基于RDS的EBS，于是悲剧了。按理说系统部署在多个availability zone的公司应
该没有问题，可惜现在用EBS服务的EC2机器必须同挂上的EBS在同一个availability zone
(EBS是网络服务，类似NFS，如果跨数据中心的话对Amazon的网络压力太大，而且性能
也不好控制）。于是这些EC2也悲剧了。其实这类问题也不难解决，就是把failover做到
应用层：数据服务分布刀不同的availability zone，并保持同步。一个availability zone
不行了，立马切换到另一个。这项功能RDS已经提供了，估计用的人不多。另外很多公司
的服务器都部署在Zone C，一点冗余没有，当然是当掉没商量。还有就是，很多系统没有
做graceful degradation。比如说利用cache层让系统至少可以只读（reddit就做了这个）。
或者利用availability更高的S3和SimpleDB+cache做数据服务。减少对EBS的依赖，利用S3
储存AMI，这样虽然启动慢点，但是机器不需要依赖EBS。这对cache系统的机器就很重要。
再说回Amazon。为啥一枚network event都会让EBS打鸡血？估计这和一个月还是俩月前
Google的gmail不得不动用磁带备份回复账户的原因一样：应用层的逻辑错误导致系统进
入某个没有测试的状态，然后黑天鹅事件就发生乐。具体到EBS，估计这个所谓的"event"让
EBS的镜像系统不知道到底哪坨EBS volume需要re-mirror了，于是进入“安全模式”，从头
re-mirror。于是整个数据库的磁盘操作就疯狂乐，带宽也饱和乐，EC2的IO和load
average也火箭飞升乐，RDS和基于EBS的数据服务也没有响应乐。看来EBS的后台程序没有
实现一致性检查或者支持快速查询的日志系统（这个纯粹是我的猜测哈。我就职高毕业，所
以说错乐恳请各位老大指点）。相信AWS搞了事后分析后，可以快速加上这类检查。比如利
用Merckle tree检查一致性，用日志回滚，都是Amazon玩儿腻的小技巧。
总之就是EBS导致的宕机也不是不可修补的缺陷。分布系统当掉真是常事。就像另外某
老大说的一样，刚开始云服务是不完美，但只要塔提供最够的经济好处，丫迟早越变越好。 |
t**********g
发帖数: 3388 | |
s*********b
发帖数: 815 | 3 Elastic Block Storage，就是他们的网络磁盘。
【在 t**********g 的大作中提到】
: EBS是什么的缩写
|
c****e
发帖数: 1453 | 4 "数据服务分布刀不同的availability zone，并保持同步。"
This is not trivial and usually means high latency. Actually it's just what
S3 offers. |
s*********b
发帖数: 815 | 5
what
嗯，一旦要划分服务乐，就不会"trivial"，不过latency还好吧，数据同步可以异步
实现，牺牲强一致，接受最终一致。而且这个策略是为容错设计，不用把数据同步
平时的普通操作。
【在 c****e 的大作中提到】
: "数据服务分布刀不同的availability zone，并保持同步。"
: This is not trivial and usually means high latency. Actually it's just what
: S3 offers.
|
u**d
发帖数: 211 | 6 我今天才看到 amazon 的报告
http://aws.amazon.com/message/65648/
看过之后，我觉得事故很难简单归咎于“容错设计”
从某种意义上，我感觉恰恰是因为设计过于强调容错了，
i.e. availability 和 consistency
上面报告里提到了，network 的一个简单错误很快就恢复了
但是在 high availability 和 strong consistency 下
在网络恢复之后，各个节点误认为当机，于是及时更新数据，导致资源耗尽
这本来就是一个两难，如果为了要避免网络和磁盘资源的拥塞
只能全局做一些 scheduling，而结果就是必然牺牲某些节点的
availability 和 consistency --- 这又和一开始的设计理念有些矛盾
如果非要对系统设计挑刺，如何 replicate, re-mirror 等等大概可以再考虑
当然，有些设计大概是可以改进的。比如报告里提到软件层 (EBS control panel)
资源耗尽，因为底层存储长时间没有响应，而 control panel 又 queue 了
非常多的 requests。我觉得这种设计大概也是基于对底层存储 high availabiltiy
和 strong consistency 的假设，所以没有 abort。如果借鉴 transaction
systems 里的 rule of thumb，一段时间没有响应就 abort，大概能避免 control
panel
的问题。
至于下面提到的 log (日志) 我觉得是没有道理的。log 平时维护的代价很高，
而它只能保证 consistency，好处是 recovery 会比较快。
但为了 availability，就要 replicate log。
日常用去来，比起只 replicate data 来说要慢太多。
总的来说，我觉得似乎应该重新思考在 distributed system 里宣扬的
availability 和 consistency 理念。特别是对于 cloud service 是
面对很多小公司，在某个错误下，是否能对于每个公司都保证服务
还是 cloud 公司首先要维护系统整体的性能。
司应
zone
做到
availability zone
公司
没有
这个）。
利用S3
重要。
统进
event"让
，从头
没有
业，所
比如利
越好。
【在 s*********b 的大作中提到】
: 基础架构出问题的几率其实挺高的，关键是系统架构要在设计时就考虑到怎么容错，而
: 应用层的架构和Amazon又没有关系。这次AWS的问题出在一个Availability Zone
: (us-east-1c)里的EBS服务抽风，因为一坨所谓的"network event"就开始大规模地执行
: 镜像操作，直接导致依赖EBS做数据服务底层的系统挂掉。偏偏大票startups都用EBS，
: 或者用基于RDS的EBS，于是悲剧了。按理说系统部署在多个availability zone的公司应
: 该没有问题，可惜现在用EBS服务的EC2机器必须同挂上的EBS在同一个availability zone
: (EBS是网络服务，类似NFS，如果跨数据中心的话对Amazon的网络压力太大，而且性能
: 也不好控制）。于是这些EC2也悲剧了。其实这类问题也不难解决，就是把failover做到
: 应用层：数据服务分布刀不同的availability zone，并保持同步。一个availability zone
: 不行了，立马切换到另一个。这项功能RDS已经提供了，估计用的人不多。另外很多公司
|
P**********0
发帖数: 412 | 7 大家都是在哪儿查的这次出错的原因。想找个英文的看一下 |
s**x
发帖数: 7506 | 8 Primary Outage
At 12:47 AM PDT on April 21st, a network change was performed as part of our
normal AWS scaling activities in a single Availability Zone in the US East
Region. The configuration change was to upgrade the capacity of the primary
network. During the change, one of the standard steps is to shift traffic
off of one of the redundant routers in the primary EBS network to allow the
upgrade to happen.....
这个象极了导致切诺贝利核爆炸的试验 。。。
【在 u**d 的大作中提到】
: 我今天才看到 amazon 的报告
: http://aws.amazon.com/message/65648/
: 看过之后，我觉得事故很难简单归咎于“容错设计”
: 从某种意义上，我感觉恰恰是因为设计过于强调容错了，
: i.e. availability 和 consistency
: 上面报告里提到了，network 的一个简单错误很快就恢复了
: 但是在 high availability 和 strong consistency 下
: 在网络恢复之后，各个节点误认为当机，于是及时更新数据，导致资源耗尽
: 这本来就是一个两难，如果为了要避免网络和磁盘资源的拥塞
: 只能全局做一些 scheduling，而结果就是必然牺牲某些节点的
|
y****u
发帖数: 11 | 9 which software can do this? Cassandra doesn't perform well.
【在 s*********b 的大作中提到】
:
: what
: 嗯，一旦要划分服务乐，就不会"trivial"，不过latency还好吧，数据同步可以异步
: 实现，牺牲强一致，接受最终一致。而且这个策略是为容错设计，不用把数据同步
: 平时的普通操作。
|
f******2
发帖数: 2455 | 10 you did not configure it well, i think
【在 y****u 的大作中提到】
: which software can do this? Cassandra doesn't perform well.
|
|
|
c***d
发帖数: 996 | 11 这个。。。容错和容错不一样， 不能说容错出了问题就不应该容错了。
zookeeper已经提供了一种类似全局scheduling的机制， 牺牲单个节点的一点性能也没
什么大不了的， 现在这些问题都是
empirical的, 不能因噎废食。
【在 u**d 的大作中提到】
: 我今天才看到 amazon 的报告
: http://aws.amazon.com/message/65648/
: 看过之后，我觉得事故很难简单归咎于“容错设计”
: 从某种意义上，我感觉恰恰是因为设计过于强调容错了，
: i.e. availability 和 consistency
: 上面报告里提到了，network 的一个简单错误很快就恢复了
: 但是在 high availability 和 strong consistency 下
: 在网络恢复之后，各个节点误认为当机，于是及时更新数据，导致资源耗尽
: 这本来就是一个两难，如果为了要避免网络和磁盘资源的拥塞
: 只能全局做一些 scheduling，而结果就是必然牺牲某些节点的
|
s*********b
发帖数: 815 | 12 嗯，我当初猜测的宕机原因都错了，所以随后的分析也就不靠谱了。
【在 u**d 的大作中提到】
: 我今天才看到 amazon 的报告
: http://aws.amazon.com/message/65648/
: 看过之后，我觉得事故很难简单归咎于“容错设计”
: 从某种意义上，我感觉恰恰是因为设计过于强调容错了，
: i.e. availability 和 consistency
: 上面报告里提到了，network 的一个简单错误很快就恢复了
: 但是在 high availability 和 strong consistency 下
: 在网络恢复之后，各个节点误认为当机，于是及时更新数据，导致资源耗尽
: 这本来就是一个两难，如果为了要避免网络和磁盘资源的拥塞
: 只能全局做一些 scheduling，而结果就是必然牺牲某些节点的
|
c******n
发帖数: 4965 | 13 这个报告太好了
textbook 一样
首先那个ops guy and his boss 肯定当天就fire 掉了
另外这个overall design philosophy 就有问题， 他们一直要求这个mirroring
process 必须跑着，否则就disable API access, 这个不行， 如果router restore 之
后大家先挺着， 一点点restart mirroring, 有些ebs nodes 先operate under single
node mode, suffer higher loss probability, 那整个system 可以慢慢恢复。 这个
single node mode 期间， 有可能有些node permanently fail, 但最后的结果可能比
现在这样全世界都知道的region total failure 好很多。
他们restore 的步骤其实当时也可以照上面的思路，disable re-mirroring on the
affected volumes, then in the process, gradually add capacity and enable re-
mirroring on the affected volumes one by one
总的来说就是他们总要试图保证entire system availability (replicate everyone),
但是这样的代价就是extremely high cost on the capacity of the mechanisms to
achieve this (EBS control plane couldn't take the flood, no more disk
capacity to do the further remirroring ), and realistically no system can
have such capacity, so they can't achieve the entire system availability, so
the entire (or most of the system) fails. clearly the other alternative
is to guarantee the availability and consistency of the MOST of the
components of the system, by quickly disabling the degrading the affected
components (temporarily disabling re-mirroring on the "stuck" volumes)
【在 u**d 的大作中提到】
: 我今天才看到 amazon 的报告
: http://aws.amazon.com/message/65648/
: 看过之后，我觉得事故很难简单归咎于“容错设计”
: 从某种意义上，我感觉恰恰是因为设计过于强调容错了，
: i.e. availability 和 consistency
: 上面报告里提到了，network 的一个简单错误很快就恢复了
: 但是在 high availability 和 strong consistency 下
: 在网络恢复之后，各个节点误认为当机，于是及时更新数据，导致资源耗尽
: 这本来就是一个两难，如果为了要避免网络和磁盘资源的拥塞
: 只能全局做一些 scheduling，而结果就是必然牺牲某些节点的
|
r********r
发帖数: 964 | 14 我是门外汉，不过是不是优化throttling的话就至少可以避免整个死掉？
single
【在 c******n 的大作中提到】
: 这个报告太好了
: textbook 一样
: 首先那个ops guy and his boss 肯定当天就fire 掉了
: 另外这个overall design philosophy 就有问题， 他们一直要求这个mirroring
: process 必须跑着，否则就disable API access, 这个不行， 如果router restore 之
: 后大家先挺着， 一点点restart mirroring, 有些ebs nodes 先operate under single
: node mode, suffer higher loss probability, 那整个system 可以慢慢恢复。 这个
: single node mode 期间， 有可能有些node permanently fail, 但最后的结果可能比
: 现在这样全世界都知道的region total failure 好很多。
: 他们restore 的步骤其实当时也可以照上面的思路，disable re-mirroring on the
|
t**********g
发帖数: 3388 | 15 Totally agree. 这样的系统应该分priority。最高优先级的拥有最多的resource (re-
mirror first)。
single
【在 c******n 的大作中提到】
: 这个报告太好了
: textbook 一样
: 首先那个ops guy and his boss 肯定当天就fire 掉了
: 另外这个overall design philosophy 就有问题， 他们一直要求这个mirroring
: process 必须跑着，否则就disable API access, 这个不行， 如果router restore 之
: 后大家先挺着， 一点点restart mirroring, 有些ebs nodes 先operate under single
: node mode, suffer higher loss probability, 那整个system 可以慢慢恢复。 这个
: single node mode 期间， 有可能有些node permanently fail, 但最后的结果可能比
: 现在这样全世界都知道的region total failure 好很多。
: 他们restore 的步骤其实当时也可以照上面的思路，disable re-mirroring on the
|
u**d
发帖数: 211 | 16 如果基于“任何时候都只有小部分当机”的假设
这样的 design philosophy 是可以的
但是对于地震、洪水、停电这种大规模的当机
这样的设计显然没有考虑到 recovery 过程中会发生的灾难
所以这次事故还是有教育意义的
single
re-
),
to
so
alternative
【在 c******n 的大作中提到】
: 这个报告太好了
: textbook 一样
: 首先那个ops guy and his boss 肯定当天就fire 掉了
: 另外这个overall design philosophy 就有问题， 他们一直要求这个mirroring
: process 必须跑着，否则就disable API access, 这个不行， 如果router restore 之
: 后大家先挺着， 一点点restart mirroring, 有些ebs nodes 先operate under single
: node mode, suffer higher loss probability, 那整个system 可以慢慢恢复。 这个
: single node mode 期间， 有可能有些node permanently fail, 但最后的结果可能比
: 现在这样全世界都知道的region total failure 好很多。
: 他们restore 的步骤其实当时也可以照上面的思路，disable re-mirroring on the
|
u**d
发帖数: 211 | 17 至于 re-mirror 的过程中 disable api，我觉得并没有问题
并不十分了解 re-mirror 过程，但是一般来讲
当机之后，各个节点之间肯定要 sync 保证数据的 consistency
在 recovery 没有完成之前允许 api 访问，很可能无法保证 consistency
single
re-
),
to
so
alternative
【在 c******n 的大作中提到】
: 这个报告太好了
: textbook 一样
: 首先那个ops guy and his boss 肯定当天就fire 掉了
: 另外这个overall design philosophy 就有问题， 他们一直要求这个mirroring
: process 必须跑着，否则就disable API access, 这个不行， 如果router restore 之
: 后大家先挺着， 一点点restart mirroring, 有些ebs nodes 先operate under single
: node mode, suffer higher loss probability, 那整个system 可以慢慢恢复。 这个
: single node mode 期间， 有可能有些node permanently fail, 但最后的结果可能比
: 现在这样全世界都知道的region total failure 好很多。
: 他们restore 的步骤其实当时也可以照上面的思路，disable re-mirroring on the
|
