新着Pick
245Picks
Pick に失敗しました

人気 Picker
バックアップ用のディスク装置への自動切換えに失敗したと報じられていますが、本当にそんな単純なことが原因だとしたら、技術は素人ながらシステム会社の運営に曲がりなりにも携わった身として、俄かには信じ難い思いです。常時テストを繰り返していて当然ですし、これだけ重要なシステムならもっと冗長性を持たせて当然じゃないのかな・・・ ドコモ口座に関わる不正の問題もそうですが、歴史的に役所と関りの深い組織でシステムの安全性に関わる問題が多く起きているように感じるのは気のせいか (・・?
「法律に基づいて詳しい原因や再発防止策などを報告するよう命じました」とありますが、当然のことでしょう。まさか、同一の拠点内にバックアップ機が一つあっただけ、なんてことはないと信じたいけれど、国外にも大きな影響を及ぼす事態を起こしただけに、それでなくともデジタル化が遅れていると露呈した我が国のシステム運用体制全般の信頼に影響を及ぼしかねません。しっかり原因を究明して不安を取り除いて欲しいと念じます。(・_・)ウーン
共有ディスク装置というのは恐らくこのような製品だと思います。
https://www.fujitsu.com/jp/products/computing/storage/disk/eternus-dx/dx8900/

これは一筐体に何百個ものディスクを差し込むことができ、ディスクの冗長化構成(RAID)を組んでリアルタイムで同時書き込み可能になっています。(ホストだと最大四重化くらいします。)ディスクは壊れやすく、予兆検知で交換できるので、この冗長化機構はまずトラブルが起こることはありません。ネットワークケーブルや電源ケーブル等も全て冗長化されます。

こういう冗長化機構の制御をするため、筐体にはCPUやメモリも搭載されており、このCPUやメモリ等が壊れると大変なことになってしまいます。これらは非常に機能停止しにくい部品になっている上に冗長化されていたりもするのですが、マザーボードは冗長化できないので、さらにこの筐体そのものの冗長化構成が組まれることが一般的です。
つまり、RAIDに加えて筐体間のリアルタイム同期処理もされているようなものです。
恐らくこのような筐体間冗長化製品機能を使い、一号機と二号機の同期を取っていたのだと思います。
https://www.fujitsu.com/jp/products/computing/storage/disk/eternus-dx/feature/010/

今回は筐体間冗長化製品機能に何らかの不具合があった可能性があると思われますが(あくまで個人的推測です。)、マザーボードの故障パターンを網羅し、大量書き込み中に絶妙な故障が起きても切り替わることをテストし切ることはできません。

現実はさらに複雑で、バックアップ拠点との間でも冗長化も必要で、このような遠隔バックアップ製品も使っていたはずです。
https://www.fujitsu.com/jp/products/computing/storage/disk/eternus-dx/feature/022/

このような製品機能は実際に使われ、改善を繰り返すことで100%に近い機能品質になるのですが、いかんせん、まず壊れない部品が絶妙な壊れ方をすることはほとんどなく、技術者にとっては無念でしょうが、今回の挙動自体は不運な事故だったと考えるのが妥当かもしれません。
辛坊さんのような影響力のある方が、細かい原因が公開される前にご自身がおっしゃるように技術の素人としての見識と経験だけで、こうあるべきと断定されるのは先日の東証での記者会見で技術的素人の方々の質問とあまり変わりがありません。

バックアップはRPOやRTOと深く関わりのある考え方になり、BCPとして別のロケーションに構えることと、HA(高可用性)は異なります。
今回の障害はいまの報道内容によると、この高可用性の仕組みで正から副への切り替えに失敗したようです。
これはバックアップではなく、アクティブ/スタンバイという考え方になります。

ディスク装置と言われても、一般の方には馴染みのないものですが、ストレージ機器と呼ばれるものを利用するシステムで環境を構築したエンジニアから考えさせていただくと、今回の件は稀にあり得る話です。

ただ、この稀な状況が起こった場合に、接続された各システムへの影響を考慮しきれなかったのだと感じます。

原因がとても珍しいバグだとすれば、今後の反省材料として生かしていくことが次の信頼性に繋がるのではないでしょうか。
2日連続で止まらなくて良かったです。