AWS障害原因は「サーバの過熱」
AWSの障害の原因は冷却システムの障害によるサーバの過熱が原因だった様です。
・AWS障害、大部分の復旧完了 原因は「サーバの過熱」
https://www.itmedia.co.jp/news/articles/1908/23/news117.html
システムが大規模化して冷却システムも複雑なのだろうとは思いますが、
サーバの過熱が原因とは素人目からすると凡ミスな感じがしますね。（^^；
30 件のコメント
コメントするには、ログインまたはメンバー登録（無料）が必要です。
AWSの構築がどうかわからないので意見の言いようがありません。
ってボケてみる(^_^;)
＞管理システム障害が原因です。
冗長化された空調設備が壊れたのか、
空調管理システムが壊れたから、冗長化された空調設備が正常に稼働
しなかったのか。。。
まぁ、いずれにせよ、週明けに文句言ってる人多そうだなぁ。。。
AWSを用いてサービス提供している事業者がSingle-AZで運用していた場合、
なんて説明するんだろ。。。
ふみえもんさんは玄人なのですね。
では、今回冗長化していた冷却システムが機能しかなった原因、
根本原因、対策を素人にわかりやすいように解説をお願いします。
玄人ならご存知ですよね？
サーバールーム内の冷却もいろいろな方法があるので、単に「冗長系の冷却設備が」云々と書いても個人的には「そもそも冗長設計じゃなくて分散して冷凍機置いてないか？。冗長設計とは何を指してるのか説明できるの？」ですね。
お気づきかもしれませんが、通常サーバールーム内の冷却は
・エリア内(室内)
・ラック内
・その他→場合によっては機器に対してスポット冷却(高発熱機器)
と考えます。この内エリア内に関しては冗長設計ではなく「エリア全体の空調として分散した冷凍機を配置→数台が壊れても他冷凍機が能力を上げて対応」とします。(それでも間に合わない場合を考慮して、普通はエリア内送風機も用意しています)
ラック内空調も基本的には床吹上、または吹き下ろし(ラック上部から)の他に、昨今では「壁面より横軸流」での冷却も採用しているので、効率よく冷却できる方法はいくらでも設計できます。
※当然のごとく、横軸流の場合はホットアイル(発熱の貯まるところ)と
コールドアイル(冷風の通るところ)をきちんと分離しないと、
全然冷却できません。
最近ではアイルキャッピングとして熱管理が当然に行われています。
冗長化するとなれば特定の高発熱機器に対してのスポット冷却でしょうが、そういう機器は「ラックに集約して配置しない」のが当たり前なので、推察するに「ラック搭載機器総合での発熱量設計を見誤っている」のがリカバリーに時間の掛かる結果となっているんじゃないかと思います。
まあ、発熱する機器は「きちんと排熱を考慮して配置する」のが当然ですので、あとは「どうやって正しく排熱させるか？(機器内外で)」だけです。なんとなくですが「サーバー内部の空冷ファンが壊れたままでも放置していた」のであれば、お粗末そのものとも考えられますが。
※そのために「Multi-AZなり Muti-Regionで分散しておけ！」も
確かに真ではありますが。
まあ、アマゾンウェブサービスでは口が裂けてもそう言えないのかも
しれません。あくまでも「個人の推測」ですよ:)。
換気扇が壊れたのかな？
僕の揚げ足を取ってもしゃあないと思います。
少なくとも、クラウドサービスにおいて、これほどの（熱暴走の）停止など聞いたことがありませんし、根幹に関わる問題です。
また、玄人なコメントは、ばななめろんさんが書いていらっしゃいますので、ご参照ください。
明日でも検証してみます。＞サーバーはクラウドにするんだよ。
分かるのに少し時間が掛かりました。
＞そら、焼きサバ(^_^;)
あ～、そういう意味でしたか？
なる程～(⌒‐⌒)
よく予習をされています。
素晴らしいです。
（あってる？）
(´▽｀ )♡
> 玄人から見ても凡ミスだと思います…
とまで書いた方が
> また、玄人なコメントは、ばななめろんさんが書いていらっしゃい
> ますので、ご参照ください。
というのは少々恥ずかしいと思います、ハイ。
※熱設計に関しては空調の効率的配置と類似してるところもあるので、
その範疇であれば「ちょっと調べれば普通にわかること」です。
→ご家庭でエアコン使う時に局所冷却するのと空間全体を冷却する
違いなども同等の系統。
調べずにあやふやなことを書くと突っ込まれる原因になりますので。
私自身もその手のファシリティ系統が専門なわけではありませんが、仕事の関係上「調べないと事が進まない」ので、自分で調べてさらに専門書を漁ってみたりした結果です。
それでも『常時 updateが必要』ですし、単純なものではない訳ですから「知らないなら知らないとか、モヤッとしたことは書かない」のが良いと思います。
※私自身、一瞬「はあ、ふみえもんさんってそういうの専門なんだ」と
感じてしまいましたが.....。:(
冷却装置が停止して、熱暴走の障害って…
こりゃ誰が見ても凡ミスやろ、と思ったので、書いたのですが、
書き方がマズかったですかね…
> ふみえもんさんは玄人なのですね。
> では、今回冗長化していた冷却システムが機能しかなった原因、
> 根本原因、対策を素人にわかりやすいように解説をお願いします。
> 玄人ならご存知ですよね？
根本原因や対策は「一つではない」ので、公開情報だけでは説明できないと思うんですがどうでしょうか？。
※それともそんなに単純なことが原因だと思います？。
空間冷却に対する熱設計も狭所と広い空間では「気流の流れなりいろいろな側面を考慮して検討しないとならない」ので。こればかりは慣れとかそういうものでは処理できません。
※厳密に考えると最終的には流体力学辺りに行き着くらしいです。
私自身そこまでは理解できないので、経験と勘に任せるしか
ありませんが。
ただ一因を上げるとすれば、今回の件は既に書いたとおり「発熱量管理の試算誤り」があるのでは？、と思えるくらいです。
ラック内の機器については「高発熱機器がある状態でも適切な気流の流れと気流通過時に奪われる熱の管理」が出来れば、そこそこ冷却は出来るわけです。
でもクラウドサービスなどの場合は「可能な限り高集約かつ高性能」が求められますから、発熱量管理をどの状態で想定していたのか(TurboBoost掛かりっぱなしか、それとも定常状態か、またはピーク性能仮説か？)で異なります。
個人的にはその辺りの目算を初めから誤っていたので、いざというとき「機器を止めて他のラックへ移し替える事が出来ない(例：ラックの空きがない、配線引き直しが移設前後のラックで稼働中は困難、電力量の限界など)」事情があったから、障害が長引いたとしか言えないところだと思います。
『> 玄人から見ても凡ミスだと思います…』という言葉は「事情を理解できる人間」が本来使うに適したものです。事情が判らず使うのはミスリードを誘うので、使うべきではないと考えます。
実際、データセンター内の空間といっても要は「建築なり空間設計に依存したものもある」ので、そんな簡単なことではない、もしくは「しがらみがあって、どうしても回避できない」場合もあります。
※昨今のデータセンターは賃借→小型エリアだったり、それこそ
「コンテナ型データセンター(44フィートコンテナよりも一回り位
大きなコンテナ内にデータセンター機能を詰め込んだもの)」も
ありますので。
一般の方が意識していないところにデータセンターって普通に存在するもんです。
ただ見る人間が見れば「あ、これはデータセンターファシリティだ！」って一発で気が付きます。(私自身、初めての場所でもいくつかは見て気が付くところもあります)
楽しくやりましょマイネ王
詳しくでました。
＞AWS障害、“マルチAZ”なら大丈夫だったのか？ インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」
2019年08月28日 18時59分 公開
＞ 今回の障害で、クラウドへの漠然とした不安から「オンプレミスへの回帰はどうか」という声もネット上にあった。しかし、ふたを開けてみれば5時間程度で大部分が復旧しており、オンプレミスで同様の障害があったときに同等の速度・労力で復旧できるかには疑問符が付く。
＞ AWSを利用する企業にとって、今回の障害は「どのようなサービス運用が適切なのか」を社内で議論する機会になりそうだ。
先程、さらに修正ありました。〉AWS障害、複数のアベイラビリティゾーン利用でも影響 AWSが説明を修正
ITmedia 2019-08-29 12:34
うーん気になるぅ。
WAF→WAFは生きていたけど、EC2インスタンスまでL7レベルでの監視をしていなかったので、5xxを返してましたゴメンナサイってオチ？
スティッキーセッション→Cookie等の情報に基づいて、対象EC2サーバへ振り向けたけど、EC2インスタンスがHTTP/HTTPSには応答しなかったので、5xxを返してましたゴメンナサイってオチ？
いずれも、ELBからL7レベルで監視していれば回避できたとかっていう話なのかなー？ELB触ったこと無いから、何処まで設定できるか知らんけど。
（独り言です。）
DCもしくはファシリティ側の空調+自社持ち込みの空調なのか、自社でファシリティとは別に冗長化してるのか。
自社持ち込みは吹き出し側にラジエーターをラックに据え付けるタイプと勝手に想像しましたが、その冗長化って何やろ？？PACかな？？