最近、IPMI BMCの障害により、サーバーの1つがハングしました。これは、CentOS 6.3OpenStackコンピューティングホストサービングKVM qcow2バックエンドを備えた仮想マシンです。
VM EC2 Ubintuのイメージ(precise-server-cloudimg-AMD64-disk1.img)に基づく)が実行されていました。
システムの再起動後、奇妙なことがわかりました。VMのsshホストキーが再作成されました(13:25-再起動時間):
root@weather:~# ll /etc/ssh/*key
-rw------- 1 root root 668 Nov 21 13:25 /etc/ssh/ssh_Host_dsa_key
-rw------- 1 root root 227 Nov 21 13:25 /etc/ssh/ssh_Host_ecdsa_key
-rw------- 1 root root 1679 Nov 21 13:25 /etc/ssh/ssh_Host_rsa_key
また、FSリカバリプロセス中に、一部の孤立したiノードが削除されたことがわかりました。
Nov 21 13:25:23 weather kernel: [ 0.901159] EXT4-fs (vda1): INFO: recovery required on readonly filesystem
Nov 21 13:25:23 weather kernel: [ 0.902688] EXT4-fs (vda1): write access will be enabled during recovery
Nov 21 13:25:23 weather kernel: [ 1.930773] EXT4-fs (vda1): ext4_Orphan_cleanup: deleting unreferenced inode 1286
......
Nov 21 13:25:23 weather kernel: [ 1.940810] EXT4-fs (vda1): ext4_Orphan_cleanup: deleting unreferenced inode 53755
Nov 21 13:25:23 weather kernel: [ 1.940815] EXT4-fs (vda1): ext4_Orphan_cleanup: deleting unreferenced inode 53754
Nov 21 13:25:23 weather kernel: [ 1.940819] EXT4-fs (vda1): 8 Orphan inodes deleted
私の質問は、なぜsshキーを再作成できるのかということです。ファイルシステムのデータ損失の結果である可能性がありますか?そして、将来これを防ぐ方法は?
qcow2キャッシュモードは、libvirt VM構成でライトスルーに設定されています。ホストファイルシステムは、BBUを備えたハードウェアRAIDコントローラーに配置されたZFS(zfsonlinux)です。
これが再起動時のファイルシステムの不整合の結果である場合-sshキーファイルは変更されず、すべての関連データが安定したメディアに同期されると予想されるため、私は非常に不思議に思っています。
誰も知的なことを言うために介入しなかったので、私は明白なことを述べます。
はい、ファイルシステムのデータ損失の結果である可能性があります。私はubuntuについて話すことはできませんが、CentOS(RHスタイル)のsshd起動スクリプトは、キーが欠落している場合に自動作成を提供し、ubuntuも同様のことを行うと思います。
If基盤となるホストの障害の結果としてVMのファイルシステムが破損した場合、およびその破損によりシステムのsshキーが取り出されたその後自動的に再生成されるため、変更されると思います。
それは何が起こったのですか?残念ながら、現時点では誰にもわからないと思います。
システムがtripwire
dだった場合は、FSのベースライン監査のようなものがあり、現在の状態を比較して、より多くの情報を得ることができます。 VMイメージに正確に何が起こったかについての決定。現状では、このマシンが完全なクリーンな再構築を正当化するのに十分な感度があるかどうか、または完全なクリーンな再構築を正当化するかどうかについてビジネス上の決定を行う必要があります。あなたはただ肩をすくめて、それをそれらの一つとして受け入れます。