2012年の終わり、Cybera （カナダ アルバータ州にある、サイバーインフラのデプロイを監督する権限を持つ非営利団体）が、彼らの DAIR プロジェクト (http://www.canarie.ca/en/dair-program/about) 用に新しい OpenStack クラウドをデプロイした。サービスインから数日後、あるコンピュートノードがロックアップした。問題のノードの再起動にあたり、私は顧客の権限でインスタンスを起動するため、そのノード上で何のインスタンスがホスティングされていたかを確認した。幸運にも、インスタンスは１つだけだった。
nova reboot コマンドは機能しなかったので、virsh を使用したが、すぐに仮想ディスクが見つからないとのエラーが返ってきた。この場合、仮想ディスクは Glance イメージで、イメージが最初に使用する際に /var/lib/nova/instances/_base にコピーされていた。何故イメージが見つからないのか？私はそのディレクトリをチェックし、イメージがないことを知った。
私は nova データベースを見直し、nova.instances テーブル中の当該インスタンスのレコードを見た。インスタンスが使用しているイメージは virsh が報告したものと一致した。よって、ここでは矛盾は発見されなかった。
私は Glance をチェックし、問題のイメージがそのユーザの作成したスナップショットであることに注目した。最終的に、それはグッドニュースだった。このユーザが影響を受けた唯一のユーザだった。
最後に、私は StackTack をチェックし、ユーザのイベントを見直した。彼らはいくつかのスナップショットを作ったり消したりしていた－ありそうな操作ではあるが。タイムスタンプが一致しないとはいえ、彼らがインスタンスを起動して、その後スナップショットを削除し、それが何故か /var/lib/nova/instances/_base から削除されたというのが私の結論だった。大した意味は無かったが、それがその時私が得た全てだった。
コンピュートノードがロックアップした原因はハードウェアの問題だったことが判明した。我々はそのハードウェアを DAIR クラウドから取り外し、修理するよう Dell に依頼した。Dell が到着して作業を開始した。何とかかんとか（あるいはタイプミス）で、異なるコンピュートノードを落としてしまい、再起動した。素晴らしい。
そのノードが完全に起動した際、インスタンスが起動した時に何が起こるのかを見るため、私は同じシナリオを実行して、インスタンスを復旧した。インスタンスは全部で４つあった。３つは起動し、１つはエラーになった。このエラーは以前のエラーと同じだった。「unable to find the backing disk.」マジ、何で？
再度、イメージがスナップショットであることが判明した。無事に起動した他の３インスタンスは標準のクラウドイメージであった。これはスナップショットの問題か？それは意味が無かった。
DAIR のアーキテクチャは /var/lib/nova/instances が共有 NFS マウントであることに注意したい。これは、全てのコンピュートノードがそのディレクトリにアクセスし、その中に _base ディレクトリが含まれることを意味していた。その他の集約化エリアはクラウドコントローラーの /var/log/rsyslog だ。このディレクトリは全コンピュートノードの全ての OpenStack ログが収集されていた。私は、virsh が報告したファイルに関するエントリがあるのだろうかと思った。
dair-ua-c03/nova.log:Dec 19 12:10:59 dair-ua-c03 2012-12-19 12:10:59 INFO nova.virt.libvirt.imagecache [-] Removing base file: /var/lib/nova/instances/_base/7b4783508212f5d242cbf9ff56fb8d33b4ce6166_10
あっはっは！じゃぁ、OpenStack が削除したのか。でも何故？
Essex で、_base 下の任意のファイルが使用されていないかどうか定期的にチェックして確認する機能が導入された。もしあれば、Nova はそのファイルを削除する。このアイデアは問題がないように見え、品質的にも良いようだった。しかし、この機能を有効にすると最終的にどうなるのか？Essex ではこの機能がデフォルトで無効化されていた。そうあるべきであったからだ。これは、Folsom で有効になることが決定された (https://bugs.launchpad.net/nova/+bug/1029674)。私はそうあるべきとは思わない。何故なら
何かを削除する操作はデフォルトで有効化されるべきではない。
今日、ディスクスペースは安価である。データの復元はそうではない。
次に、DAIR の共有された /var/lib/nova/instances が問題を助長した。全コンピュートノードがこのディレクトリにアクセスするため、全てのコンピュートノードは定期的に _base ディレクトリを見直していた。あるイメージを使用しているインスタンスが１つだけあり、そのインスタンスが存在するノードが数分間ダウンした場合、そのイメージが使用中であるという印を付けられなくなる。それゆえ、イメージは使用中に見えず、削除されてしまったのだ。そのコンピュートノードが復帰した際、そのノード上でホスティングされていたインスタンスは起動できない。
