オン コールフライデーが、オン コールのくすぶる世界の物語とともに再びやって来ました。
今日の思い出は「Phil」によるものです。彼は数年前、OpenStack Grizzly をベースに製品を作ろうと決めた無名のパブリック クラウド ベンダーをサポートすることになった人物です。
決して楽しい経験ではなかったと言っても過言ではない。フィルは、経験からくる少しの苦みを込めてこう言った。「OpenStackは、主に数万行分のPython、RabbitMQ、MySQLデータベース、Cephストレージ、そして運用チームを追い詰めてデータセンターの闇の片隅で暴力的に殺害することを目的として野放しにされたSDNのようなものだった」
言いたいことを言ってください、フィル。
ついに見つけた…ITディレクターの人間としての良識の最後のかけらを。それも、気の毒なUnixエンジニアのために。
続きを読む
崇高な財団に公平を期すために言うと、「私たちが作り上げた、脈動する悪の塊のような巨大なシステムは、すべてOpenStackのせいではありません」と彼は認めた。プロジェクト開始当時、チームはパブリッククラウドについて何も知らず、「私たちの無能さが、立ち上げ後数年間にいくつかの大きな失敗につながったのです」。
問題のベンダーを推測するのはあなたにお任せします。
「ビジネス上の決断のいくつかは、毎日私たちを悩ませました。魂を破壊するようなチケットが次々とありました」とフィルは回想する。
フィルは、プロジェクト（彼の言葉を借りれば「創造の落とし子」）から抜け出すことに失敗し、ビーストが危うく陥る12時間の間、一日中看病した後、家にいた。
その日はうまくいきませんでした。コンピューティング ノードが限界に達し、Ceph クラスターの 4TB ディスクに障害が発生し、「リカバリ オペレーションによってクライアント オペレーションがロックされ、読み取り/書き込みを実行できなくなりました (これにより、8CPU 32GB RAM の Windows ボックスが Ceph クラスターでボリュームを探している間にコンピューティング ノードのローカル ディスクをスラッシングし始めたため、すでに負荷がかかっていたコンピューティング ノードがさらに破損しました)。」
聞くところによると、非常に不確実な計画の結果に対処する、ただの一日のようです。
「今日はもう仕事が終わって、テレビの前でゆっくりしながら、早く突然死を祈ろうと思っていたら」フィルの携帯からデータセンターの異常を知らせる音が鳴り響いた。ビーストが注意を促していた。
コンピューティングノードの1つがダウンしていました。通常であれば、これは何の問題にもなりません。というのも、この時点でOpenStackはゲストを故障ノードからより健全なノードへ移行し、それに応じてVMを起動できるからです。
「残念ながら、ビーストにはこれがありませんでした。」
ストレージクラスターは数十台の4TB 7,200rpmドライブで構成されていたため、各自の60GBのルートディスクはコンピューティングノード上に存在していました。ルートディスクの実行に必要なIOPSは、このクラスターを壊滅させてしまうほどでした。20～30のゲストをSSH経由で他のノードに移行することは不可能でした。
「とにかく、他のコンピューティング ノードには十分なローカル ディスクがありませんでした。」
ああ、そして「バックアップは存在しませんでした。」
フィルはそのノードをオンラインに戻さなければならなかった。リモートアクセスによるリセットは不可能だった。ハードウェアの電源が完全に切れているようだった。わずか45分の距離にあるデータセンターへ向かうしかなかった。
「そこに着いたとき、コンピューティング ノードの電源ボタンを何度も押して悪態をついても問題は解決しないことにすぐに気付きました」とフィルは思い出しながら語ります。
電源ケーブルは問題なかったため、Phil はコンピューティング ノード自体を詳しく調べざるを得ませんでした。
「箱を少し近づけすぎたかもしれない」と彼は認めた。
電源を切ってから2時間経っても、マシンの蓋は「朝食を揚げられるほど熱かった」。箱の中を覗くと、最悪の状態が判明した。オンボードのRAIDコントローラーは「完全に焼け焦げ、チップセットは黒く剥がれ落ちていた。[爆発時に非常に熱かったため]」
この時までに、ミッションクリティカルなマシンを「SLA に裏付けされていない安価なプラットフォーム」にインストールすることを選択したクライアントからの電話が鳴り響き始めていました。当然のことですが、彼らはそうしました。
ハードウェアサプライヤーからの交換品の供給が「ええ、いつでも」という状況で、フィルは困り果てていました。当然ながら、予備のRAIDカードは在庫にありませんでしたが、少し新しいサーバーはありました。これは、どうしても必要だった容量を増やすために用意したものでしたが、乞食には選べないのです…。
まず、故障したサーバーからミラーリングされたOSドライブを取り外し、新しいマシンに接続しました。UbuntuとOpenStackには、新しい環境を理解させるための準備が整いました。スタック全体にpingを数回送信した後、新しいマシンはシャットダウンし、心臓が止まりそうな第2段階へと進みました。
「ゲストは」と、トラウマで記憶が曖昧になっているフィルは言う。「10 台ほどのドライブにまたがる RAID 6 アレイに保存されていました。」
彼は慎重に各ドライブをマシンからマシンへと移動させ、ベイ番号が合っていることを確認した。作業が終わると、息を呑みながら電源ボタンを押した。
「『この外部 RAID 構成をインポートしますか?』という恐ろしいメッセージがポップアップ表示されたとき、私はもう一度深呼吸をして、「もういいや」ボタンを押して待ちました。
「その後に起こったことは私自身も驚きました。」
すべてがうまくいきました。ゲストVM（仮想インターフェースのリセットが必要）が起動し、すべてオンラインに戻りました。
フィルの仕事は終わり、彼は「少し年を取り、少し悲しくなり、そして、飲酒問題に本格的に取り組むことに少し近づいた」。
当然のことながら、The Register紙はOpenStackチームに対し、当時は同社のソフトウェアを動作させるのが少々難しかったのではないかと指摘しました。最高執行責任者（COO）のマーク・コリアー氏も同意見で、次のように語っています。「NASAがOpenStackを立ち上げた当時は、文字通りロケット科学者でなければ動作させることができませんでした。
「しかし今では、わずか 4 人で 10 万コアを超える OpenStack を実行する Adobe Advertising Cloud が稼働しており、私たちは大きな進歩を遂げてきたと言えます。」
きっととても賢い4人でしょう。
OpenStackのインストールがひどく失敗し、その影響範囲に巻き込まれたことはありませんか？あるいは、誰も完全に理解していないプロジェクトの渦中に巻き込まれたことはありませんか？運命の電話がかかってきた時、あなたはどうしましたか？On Callにご連絡いただき、その体験を詳しくお聞かせください。®
