弁財天

ゴフマン「専門家を信じるのではなく、自分自身で考えて判断せよ」

日本電子計算「33自治体のデータがIaaSから消失」ファームウェアを更新したら1318の仮想OSの3割がディスクにアクセスできなり、さらに15%はバックアップも取れてなかったw。新たなコメディかw update17

VMwareのSEsparseスナップショットの「IO coalescing」とEMCのタイムファンダーw

日本電子計算のNTTデータのEMCストレージ不具合で全国50自治体システムが停止。復旧できなくなるw

【MUSCULAR】日本電子計算のストレージ障害の原因は「Dell EMC Unity 500」の並列処理…w

高負荷状態になるとゲストの書き込みIOは不整合になり、データが論理的に壊れてしまうとか。 1318のvmwareのデータはすべてどこか壊れているはずなのに、復旧できた自治体と消失した自治体があるのはなぜか? ここに解読のヒントがあると思われ…w

 Jip-Baseは仮想環境で構築しており、1318の仮想OS上で自治体などの業務システムが稼働していた。利用中の中野区によると、「仮想化ソフトにはVMware vSphereを使っている」という。12月4日のシステム障害の発生後、日本電子計算は12月5日にメーカーのEMCジャパンと共にストレージのファームウエアを修正したが、その適用の前にこの仮想環境の復旧を試みていたことを明かした。

 その過程でLUN(Logical Unit Number)という論理的なHDDを復旧しようとしたが、「ストレージ・プールがダウンしそうになるという、より深刻な状況が発生した」(日本電子計算の神尾拓朗公共事業部基盤サービス統括部部長)。慎重に検討した結果、やはりファームウエアの修正が必要と判断。EMCジャパンが12月5日午後4時にファームウエアを修正したが、ここまでの一連の作業で時間を取った。

「仮想化ソフトにはVMware vSphereを使っている」w

あー、福井システムかぁ。ファームウェアの不具合とサイバー攻撃を偽装しながら、九頭竜が証拠データの隠滅を図ってるのか…w

九頭竜のクラウドサービス基盤で1週間の障害。人的ミスを否定w。福井システムズのベンダーは富士通とNTT

「日本電子計算はファームウエアを修正すれば復旧できると考えていたが、論理的にデータの不整合が発生している部分があり、バックアップデータなどから復旧が必要なことが判明。その結果、多くの自治体システムで復旧に手間取ることになった。」w

え?なんだって?

じゃぁ全1318の7割の仮想OSのデータは起動できたけど論理的に壊れてるかもってか…

こわいわー…

kb.vmware.com→Virtual Machines running on an SEsparse snapshot may report guest data inconsistencies (59216)(Last Updated: 11/20/2019)

Cause
VMware has identified an issue in SEsparse VM snapshots that can cause data inconsistencies. This issue occurs when a VM is running on an SEsparse snapshot and experiences a burst of non-contiguous write IO in a very short period of time.

「原因 VMwareはSEsparse VM スナップショットがデータ不整合の原因になる問題を特定した。SEsparseスナップショットでVMを実行してるときで、極短時間に大量の非連続書き込みIO(non-contiguous write IO)が起きたときにこの問題は発生する。」w

あー、負荷テストもやってなかったんだw。この構成ちょっとマニアック杉でNTTデータには無理なんじゃね?w

もう何十年も前の話だけど、VIAのチップセットにつながった2つのハードディスクの間で巨大ファイルをコピーするとファイルが壊れる問題を思い出したぞw

docs.vmware.com→VMFS でのスナップショットのフォーマット

「SEsparse は、VMFS6 データストアのすべての差分ディスクのデフォルト フォーマットです。VMFS5 では、SEsparse は 2 TB 以上のサイズの仮想ディスクに使用されます。」w

スナップショット形式(SEsparse)のvmwareは高負荷状態になると書き込みデータが不整合になるw。高負荷時に書き込んだ自治体のデータは論理的に壊れているw。なんか終わってるな…。

virtualnomadblog.com→vSphere 6.x: SEsparse snapshot may cause guest OS file system corruption

Resolution
The issue is resolved the following releases:
vSphere 6.7 Update 1 - Fore more information, see VMware ESXi 6.7 Update 1 Release Notes.
vSphere 6.5 Patch - For more information, see VMware ESXi 6.5, Patch Release ESXi650-201810002.
vSphere 6.0 Patch - For more information, see VMware ESXi 6.0, Patch Release ESXi600-201810001.

Workaround
This issue can be prevented by disabling “IO coalescing” for SEsparse.

ESXiをバージョンアップするか、SEsparseの「IO coalescing」を無効にすれば回避できる。 しかし回避策を講じるまでのvmwareの1318ゲストのファイルは壊れている可能性がある…

アマゾンで起きた障害を思い出したw

【EBSのバグ】AWS東京リージョン(AZ apne1-az4)でEBSのパフォーマンス低下によるクラウド障害…

【QLDBのインデックスのバグだろw】アマゾンで他人の購入履歴が表示されるw

とりあえずESXiをバージョンアップしてSEsparseの「IO coalescing」を無効にすることで起動できる状態にしたあとに 別環境に再構築した環境にデータ破損を確認したながら移行するんだな。アマゾンだけでなく全世界でゲストのデータが破損してしまった可能性がある…w

jip.co.jp→「Jip-Base」の障害における復旧状況のご報告


「バックアップデータから仮想OSと業務データが特定できない」w

「調査の結果、一部についてはバックアップが取得できてなかったことが判明(12月15日)」w

はぁ?w

もろこれだわw、復元ポイントスプリッターが落ちたりハングアップしてバックアップできない件w 運用ミスか…

EMC Unityの復元ポイント作成プロセス(Kdriver.exe)が異常終了したことを、ログ監視で検知して再起動しなければならなかった。ログの異常監視をやってなかったのか。これは怒られるぞ。

1318の仮想OSが使うストレージのバックアップ(Kdriver.exe)や冗長化機能をテストしてなかった。ログ監視もなかった。なのでファームウェアを更新しようなど発想すらしなかった。なんか終わってるなー。宝の持ち腐れだw。

せっかくフェラーリを買ったのに、高価なスポーツカーはメンテしなければならないという発想が欠落していて、結果的に高速道路で炎上してしまうのと似てるw

ディスクは壊れてなかったのにファームウェアを更新したらオンラインにならないてどこかで見たなw これだ。

ビデオまであるじゃまいかw。

ファーム更新後に1318のうち395の仮想OSのディスクがオンラインにならなかったw←もうこの事実がインチキくさいw

投稿されたコメント:

コメント
コメントは無効になっています。