web-dev-qa-db-ja.com

Openstack Mass / Jujuリカバリ

私はjujuを使用してMAASに基づいてOpenstackを作成しました。インスタンスやプロジェクトなどを作成しました。データベースとopenstackの設定ファイルのバックアップを作成しました。私はサービスkeystoneを破棄して削除することにより、回復が可能かどうかを確認するために、テスト回復を試みています。 keystoneデータベースも削除します。 (バックアップされます)したがって、jujuを使用して、壊れていた古いキーストーンを破壊し、新しいキーストーンをデプロイします。これにより、すべてのプロジェクト(テナント)がなくなっており、インスタンスがどのプロジェクトにも属していないという事実を除いて、実際に再び実行されます。だから、私はトークンなしでキーストーンデータベースを復元しますが、それを行うと、地平線でエラーが発生し、キーストーンはクライアントを認証しません。

壊れたキーストーンノードを復元する最良の方法は何でしょうか...?ジュジュでキーストーンをやり直すと、新しいトークンが得られるようです。ジュジュは何とか古いキーストーンを新しいキーストーンに注入できますか?

5
Julius

あなたが当たっている問題は、キーストーンチャームがキーストーンデータベースの外にいくつかの情報を保存することです。具体的には、サービスのユーザー名とパスワードはディスクにローカルに保存されるため、keystoneに関連する追加のサービスユニットがあれば、keystoneサービスは要求されたユーザーの正しいパスワードを関連サービスに渡すことができます。

また、keystoneをデプロイするときに管理パスワードと管理トークンの構成を提供していない場合にも問題が発生します。 Keystoneサービスユニットは、明示的に設定されていない場合、これらをランダムに生成します。したがって、新しいKeystoneサービスユニットを削除してから追加すると変更されます。

最終的には、2番目のkeystoneサービスユニットのディスク上に生成されたパスワードと一致しない、(最初のサービスユニットによって作成された)データベース内のハッシュ化されたパスワードのセットです。

理想的には、jujuの何らかの汎用オブジェクトストレージ機能(object-put/object-getを考えてください)でこれを修正しますが、これはサポートされている機能ではありません。

パスワードとトークンのディスク上のストレージはすべて/ var/lib/keystoneで行われます。これらをkeystoneサービスユニット自体のバックアップの一部として選択できる場合があります。ただし、新しいサービスユニットを追加すると、これらのファイルを復元する前にサービスリレーションが起動するため、競合が発生します。

OpenStackチャームのメンテナーの1人として、これについてもう少し考えて、もっとエレガントなものを思いつくことができるかどうかを確認します。

1
jamespage