OpenStack における稀だが便利な操作

[[207647]]

序文

私は 2013 年に OpenStack の作業を開始し、Pike バージョンがリリースされてから数年が経ちました。使用してみると、便利な操作がたくさんあるのに、あまり触れられていないことに気づきました。ここで紹介したい内容を直接指摘するつもりはありませんが、次のような疑問を直接提起したいと思います。

• プライベート画像を他のテナントと共有するにはどうすればいいですか?
• 大きな画像をアップロードすると常にタイムアウトになる場合はどうすればよいでしょうか?ユーザーが悪意のある画像をアップロードした場合はどうすればよいですか?
• 仮想マシンのセキュリティを確保し、誤操作を防ぐために、ユーザーが仮想マシン上で操作を実行できないようにするにはどうすればよいですか?
• 仮想マシンが長期間使用されていないにもかかわらずリソースを占有し続ける場合はどうすればよいでしょうか?
• 仮想マシンのファイル システムがクラッシュします。修復するためにレスキューモードに入るにはどうすればいいですか?
• ストレージ システム内の既存のデータ ボリュームを OpenStack にインポートするにはどうすればよいですか?
• ボリュームをホストにマウントできますか?
• ボリュームを別のテナントに転送するにはどうすればよいですか?
• ボリュームのバックアップには問題はありませんが、データベースのデータが失われた場合はどうすればよいでしょうか?

次に、OpenStackの既存機能を通じて、それぞれの課題をどのように解決するかを詳しく紹介します。

一目

メンバー

イメージは OpenStack において非常に重要なデータです。ユーザーのオペレーティング システム データを保存します。したがって、画像のセキュリティを確保することは非常に重要です。通常、Glance にアップロードされた画像は、公開または非公開に設定できます。パブリック イメージはすべてのテナントに表示されますが、プライベート イメージはテナント自身にのみ表示されます。 Glance の新バージョンでは、新しい可視性状態共有が導入され、この状態のイメージを指定されたテナントと共有できるようになりました。共有対象テナントはメンバーと呼ばれます。イメージにアクセスするには、イメージのメンバーにテナントを追加するだけです。

まず、次のようにして管理テナントの下にミラーを作成します。

一目でわかるイメージ-作成  --disk-format raw --container-format bare --name cirror-3.0 --file cirros-3.0.img  

デモ テナントでは画像が表示されません。

 $ ソース openrc_demo
 $ イメージリストを見る
+ ----+------+  
 | ID |名前|
 + ----+------+  
 + ----+------+  

ミラー メンバーにデモを追加します。

 $ 一覧メンバーを作成ec5426f5-ab4d-43a6-a1e1-5a1919a​​a7bea fb498fdd27e74750a6b209158437696c
 + ----------------------------------------+-------------------------------------+----------+  
 |画像ID |会員ID |ステータス |
 + ----------------------------------------+-------------------------------------+----------+  
 | ec5426f5-ab4d-43a6-a1e1-5a1919a​​a7bea | fb498fdd27e74750a6b209158437696c |保留中 |
 + ----------------------------------------+-------------------------------------+----------+  

管理者はメンバーにデモを追加し、デモは確認する必要があります (例: member-update):

 $ 一覧メンバー- 更新ec5426f5-ab4d-43a6-a1e1-5a1919a​​a7bea fb498fdd27e74750a6b209158437696c 承認済み
+ --------------------------------------+-------------------------------------+----------+  
 |画像ID |会員ID |ステータス |
 + --------------------------------------+-------------------------------------+----------+  
 | ec5426f5-ab4d-43a6-a1e1-5a1919a​​a7bea | fb498fdd27e74750a6b209158437696c |承認済み |
 + --------------------------------------+-------------------------------------+----------+  

これで、デモ テナントの下に共有イメージが表示されます。

 $ イメージリストを見る
+ --------------------------------------+---------------------+  
 | ID |名前|
 + --------------------------------------+---------------------+  
 | ec5426f5-ab4d-43a6-a1e1-5a1919a​​a7bea |サーロ-3.0 |
 + --------------------------------------+---------------------+  

タスク

通常、image-create を使用して画像をアップロードしますが、これには少なくとも次の 2 つの問題があります。

1. イメージには検証がないので、任意のイメージや悪意のあるファイルをアップロードでき、Glance をオブジェクト ストレージとして使用することもできます :)。
2. 画像は通常サイズが大きいため、アップロードすると多くのリソースが消費され、速度も遅くなります。大きな画像をアップロードすると、簡単にアップロードタイムアウトが発生する可能性があります。

そのため、Glance はバージョン V2 以降でタスクの概念を導入しました。タスクは画像をアップロードするタスク フローを定義し、その後 Glance は非同期で実行して結果をフィードバックします。 Glance タスクの概要については、「Glance のタスク API の使用を開始する」を参照してください。

まずタスクを定義します。json ファイルは次のようになります。

 { "input" : { "image_properties" : { "container_format" : "bare" 、 "disk_format" : "raw" 、 "name" : "cirros-0.3.5-x86_64" }、 "import_from" : "http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img" 、 "import_from_format" : "raw" }、 "type" : "import" }

タスクを作成します:

 $ タスク作成  --type インポート --input "$(cat import_image.json | jq '.input')"  
 + ------------------------+--------------------------------------------------------------------------------+  
 |プロパティ |価値 |
 + ------------------------+--------------------------------------------------------------------------------+  
 |作成日時 | 2017-09-28T08:03:47Z |
 | id | 564b5ee4-56db-4360-bb71-d1d1c4d896a2 |
 |入力 | { "image_properties" : { "container_format" : "bare" , "name" : |
 | | "cirros-0.3.5-x86_64" }, "import_from_format" : "raw" , "import_from" : |
 | | "http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img" } |
 |メッセージ | |
 |オーナー | ae21d957967d4df0865411f0389ed7e8 |
 |結果 |なし |
 |ステータス |保留中 |
 |タイプ |インポート |
 |更新日時 | 2017-09-28T08:03:47Z |
 + ------------------------+--------------------------------------------------------------------------------+  

タスクを表示:

 $ タスクリストを一目で見る
+ --------------------------------------+--------+----------------+----------------------------+  
 | ID |タイプ |ステータス |オーナー |
 + --------------------------------------+--------+----------------+----------------------------+  
 | 564b5ee4-56db-4360-bb71-d1d1c4d896a2 |インポート |処理 | ae21d957967d4df0865411f0389ed7e8 |
 + --------------------------------------+--------+----------------+----------------------------+  

この時点で、Glance はイメージを非同期的にダウンロードし、完了するとステータスが成功に変わります。

 $ 一目でタスクを表示 564b5ee4-56db-4360-bb71-d1d1c4d896a2
 + ------------------------+--------------------------------------------------------------------------------+  
 |プロパティ |価値 |
 + ------------------------+--------------------------------------------------------------------------------+  
 |作成日時 | 2017-09-28T09:32:10Z |
 |有効期限 | 2017-09-30T09:33:54Z |
 | id | 564b5ee4-56db-4360-bb71-d1d1c4d896a2 |
 |入力 | { "image_properties" : { "container_format" : "bare" 、 "disk_format" : "raw" 、 "name" : |
 | | "cirros-0.3.5-x86_64" }, "import_from_format" : "raw" , "import_from" : |
 | | "http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img" } |
 |メッセージ | |
 |オーナー | ae21d957967d4df0865411f0389ed7e8 |
 |結果 | { "画像ID" : "e5f8a941-f14f-4065-b381-b537271eba4c" } |
 |ステータス |成功 |
 |タイプ |インポート |
 |更新日時 | 2017-09-28T09:33:54Z |
 + ------------------------+--------------------------------------------------------------------------------+  

結果には画像 ID が保存されます。

この設計の本来の意図は良いのですが、Mitaka バージョン以降、タスク API は非推奨になりました。コミュニティはイメージのインポート プロセスのリファクタリングを準備しています。イメージのインポート リファクタリングを参照してください。

ノヴァ

ロック

この機能は仮想マシンをロックするという、比較的わかりやすい機能です。通常のユーザーは、ロックされた仮想マシンに対していかなる操作も実行できません。管理者はこの操作を使用して仮想マシンのセキュリティを確保し、ユーザーのミスを防ぐことができます。

ただし、ロックは通常のユーザーにのみ適用され、管理者はロックを無視することに注意してください。

まず仮想マシンを作成します。

 nova ブート--image f0b1239a-bb34-4cfb-ad06-e18cbb8ee4b9 --flavor m1.small --nic net-id=9f3aad86-f3c1-499b-ba62-5708dd229466 int32bit-test-lock  

ロック操作を実行します。

ノヴァロック d7873036-15b0-4a06-9507-999dbf097c62

次に、通常のユーザー (管理者以外) を使用して、仮想マシン上で任意の操作を実行します。

 $ ソース openrc_demo
 $ nova を再起動 d7873036-15b0-4a06-9507-999dbf097c62
インスタンス d7873036-15b0-4a06-9507-999dbf097c62 はロックされています(HTTP 409) (リクエスト ID: req-60271d7d-9afd-4ff4-a150-dfb632d5007f)
エラー (CommandError):指定されたサーバーを再起動できません。
 $ nova削除d7873036-15b0-4a06-9507-999dbf097c62
インスタンス d7873036-15b0-4a06-9507-999dbf097c62 はロックされています(HTTP 409) (リクエスト ID: req-3e63515b-6e2e-419a-8c91-b27b1a546f12)
エラー (CommandError): できません 指定されたサーバーを削除します。

また、一般ユーザーもロック操作を実行できること、および一般ユーザーが実行したロックをどのユーザーでもロック解除できることも強調しておく必要があります。ただし、ロックが管理者によって実行された場合、デフォルトのポリシーでは一般ユーザーはロック解除を実行できません。

 $ ノヴァロック解除 d7873036-15b0-4a06-9507-999dbf097c62
エラー (禁止): ポリシーにより、os_compute_api:os-lock-server:unlock:unlock_overrideの実行が許可されていません。 (HTTP 403) (リクエスト ID: req-9fabda60-4857-429e-ab1d-6ca6fb36844e)

棚に置く

長期間使用されていない仮想マシンの中には、電源をオフにしてもリソースを占有し、新しい仮想マシンを作成できないものがあります。または、ユーザーが長期間滞納しており、仮想マシンを時間内に削除しなかったために、リソースが占有されている可能性があります。この時点で、shelve 操作を通じてリソースを一時的に解放できます。

シェルブ操作の原理は、まず仮想マシンのスナップショットを作成して Glance にアップロードし、次に OpenStack から仮想マシンを削除してすべてのリソースを解放することです。

ノヴァシェルブ 5b540e93-e931-45ed-a7f3-1dc2e88d8d33

shelve が完了したら、仮想マシンが libvirt から完全に削除されたかどうかを確認します。

 $ nova list --fields id、name、status、instance_name  
 + --------------------------------------+------------------------------------------+-------------------------------------+----------------------------+----------------------------+  
 | ID | ID |名前|ステータス |インスタンス名|
 + --------------------------------------+------------------------------------------+-------------------------------------+----------------------------+----------------------------+  
 | 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | int32ibt テスト シェルフ |棚上げ_オフロード済み |インスタンス-0000033b |
 + --------------------------------------+------------------------------------------+-------------------------------------+----------------------------+----------------------------+  
 virsh コマンドでリストされたすべてのファイルを表示します。 grep インスタンス-0000033b  

instance-0000033b が削除されたことがわかります。

作成されたスナップショットを表示するには、glance を使用します。

 $ イメージリストを一目見る | grep は保留
| 36d7d6a0-aa18-4373-ad79-afcae8609489 | int32ibt テストを棚上げします |

仮想マシンを復元する場合は、スナップショットに基づいて仮想マシンを再起動し、スナップショットを削除する unshelve を使用して復元できます。

 $ nova シェルフ解除 5b540e93-e931-45ed-a7f3-1dc2e88d8d33
 $ ノヴァリスト
+ --------------------------------------+---------------+----------+----------------+-------------+----------------------+  
 | ID |名前|ステータス |タスクの状態 |パワーステート |ネットワーク |
 + --------------------------------------+---------------+----------+----------------+-------------+----------------------+  
 | 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | int32ibt テスト シェルフ |アクティブ | - |ランニング |テストネット=10.0.51.22 |
 + --------------------------------------+---------------+----------+----------------+-------------+----------------------+  

レスキュー

ファイル システムがクラッシュしたときに修復するためにレスキュー モードに入ったり、クラッシュしたファイル システムを修復するために Live CD を介して一時的なオペレーティング システムに入ったりすることがよくあります。

OpenStack を使用して仮想マシンを起動するときに問題が発生し、起動できない場合はどうすればよいですか?

もちろん、仮想マシンのルート ディスクをローカルにマウントし (ceph を使用している場合は、rbd マップを介して直接)​​、ホスト マシンで修復することもできます。しかし、クラウドプロバイダーとしてそうすることは明らかに不可能であり、そうしないとユーザーのデータがあまりにも安全でなくなってしまいます。ユーザーが自分で修正する必要があります。

Nova はレスキュー API を提供しており、その実装原理は基本的に上記の方法と同じです。まず、 rescue サブコマンドの使い方を見てみましょう。

 nova rescue [ --password <パスワード>] [--image <イメージ>] <サーバー>  

Rescue は指定されたイメージを使用して仮想マシンを再作成し、元の仮想マシンのルート ディスクを新しく作成された仮想マシンの追加ディスクとしてマウントします。より正確に言うと、これはフレーバーやネットワークなどの元の仮想マシン情報を再利用する再構築操作です。

注意: レスキューによって新しく作成された仮想マシンは、指定されたキー ペアをサポートしません。再構築もサポートされていません。この問題は数日前にメーリングリストで議論され、Q バージョンで実装される予定です。

試してみましょう

$ nova レスキュー--image f0b1239a-bb34-4cfb-ad06-e18cbb8ee4b9 5b540e93-e931-45ed-a7f3-1dc2e88d8d33  
 + ----------+--------------+  
 |プロパティ |価値 |
 + ----------+--------------+  
 |adminPass |4mDD7BGsfvMN |
 + ----------+--------------+  
 $ ノヴァリスト
+ --------------------------------------+------+----------+-----------+-------------+---------------------+  
 | ID |名前|ステータス |タスクの状態 |パワーステート |ネットワーク |
 + --------------------------------------+------+----------+-----------+-------------+---------------------+  
 | 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | 2 |アクティブ |救助 |ランニング |テストネット=10.0.51.22 |
 + --------------------------------------+------+----------+-----------+-------------+---------------------+  

仮想マシンの再構築が完了したら、そのステータスを確認します。

 $ ノヴァリスト
+ --------------------------------------+------+----------+-----------+-------------+---------------------+  
 | ID |名前|ステータス |タスクの状態 |パワーステート |ネットワーク |
 + --------------------------------------+------+----------+-----------+-------------+---------------------+  
 | 5b540e93-e931-45ed-a7f3-1dc2e88d8d33 | 2 |レスキュー | - |ランニング |テストネット=10.0.51.22 |
 + --------------------------------------+------+----------+-----------+-------------+---------------------+  

仮想マシンのステータスが RESCUE に変わります。

マウントされたブロックデバイスを表示するには、virsh を使用します。

 $ virsh domblklist 5b540e93-e931-45ed-a7f3-1dc2e88d8d33
ターゲットソース
--------------------------------------------------------  
 vda /var/lib/nova/instances/5b540e93-e931-45ed-a7f3-1dc2e88d8d33/disk.rescue
 vdb /var/lib/nova/インスタンス/5b540e93-e931-45ed-a7f3-1dc2e88d8d33/ディスク

disk.rescue は新しく作成された仮想マシンの一時ルート ディスクであり、disk は元の仮想マシンのルート ディスクです。このとき、新しく作成した仮想マシンに入り、元の仮想マシンのルートディスクを操作します。

操作が完了したら、unrescue サブコマンドを使用して復元します。

ノヴァ アンレスキュー 5b540e93-e931-45ed-a7f3-1dc2e88d8d33

Unrescue は仮想マシンを再構築し、以前のルート ディスクをルート ディスクとして再利用し、以前に作成された一時ルート ディスクを削除します。

シンダー

管理

Cinder がボリュームを作成する場合、通常、バックエンド ストレージ システムがボリュームを作成し、それを Cinder ボリュームと 1 対 1 でマッピングする役割を担います。

Ceph の rbd イメージなど、ストレージ システムにすでにボリュームがいくつかある場合、それらを Cinder でどのように管理できますか?幸いなことに、Cinder は OpenStack 外部の一部ストレージ データ ボリュームのインポートをサポートしています。この操作は管理と呼ばれます。次にこのプロセスを説明します。

LVM バックエンド ドライバーを使用していると仮定して、まず LV を作成します。

 $ lvcreate --name int32bit-test-LV --size 1G cinder-volumes  
  論理ボリューム「int32bit-test-LV」が作成されました。
 $ レベル | grep int32bit
 int32bit-テスト-LV cinder-ボリューム-wi-a ----- 1.00g  

ボリュームを作成するには、manage サブコマンドを使用します。

 $ cinder manage --name int32bit-test-manage 'devstack@lvm#cinder-volumes' int32bit-test-LV  
 + --------------------------+------------------------------------------------+  
 |プロパティ |価値 |
 + --------------------------+------------------------------------------------+  
 |添付ファイル | [] |
 |可用性ゾーン |新星
|起動可能 |誤り|
 |一貫性グループ ID |なし |
 |作成日時 | 2017-09-28T03:09:55.000000 |
 |説明 |なし |
 |暗号化された |誤り|
 | id | 9394b827-4ad0-488e-8df8-26476b3a8662 |
 |メタデータ | {} |
 |移行ステータス |なし |
 |マルチアタッチ |誤り|
 |名前| int32bit テスト管理 |
 | os-vol-host-attr:ホスト | devstack@lvm#cinder-ボリューム |
 | os-vol-mig-status-attr:migstat |なし |
 | os-vol-mig-status-attr:name_id | os-vol-mig-status-attr:name_id |なし |
 | os-vol-テナント属性:テナント ID | 42ee53fa480f49149ce5c3df4a953a6b |
 |レプリケーションステータス |なし |
 |サイズ| 0 |
 |スナップショット ID |なし |
 |ソースボリュームID |なし |
 |ステータス |作成中 |
 |更新日時 |なし |
 |ユーザーID | a61a3c0659bd4cca8cb5f66ea2fe3df7 |
 |ボリュームタイプ |なし |
 + --------------------------+------------------------------------------------+  

上記の 2 つのパラメータのうち、最初のものはホストです。 Cinder のホスト形式は hostname@backend#pool であることに注意してください。不明な場合は、管理者アカウントを使用してボリュームの 1 つを表示し、その os-vol-host-attr:host を確認します。もう 1 つのパラメーターは識別子で、これはバックエンド ストレージ ボリュームの名前です。 LVM の場合は LV 名、Ceph rbd の場合はイメージ名です。

ボリュームのステータスが使用可能に変わると、ボリュームが正常に作成され、指定された LV が正常にインポートされたことを示します。

作成した LV がまだ存在するかどうかを確認するには、lvs を使用します。

 $ レベル | grep int32bit

作成された int32bit-test-LV は存在しないことがわかりました。どうしたの？次のようにソースコードを確認しました。

 def manage_existing(自己、ボリューム、既存の参照):
   lv_name = existing_ref[ 'ソース名' ]
   self.vg.get_volume(ボリューム名) 
 
   volutils.check_already_managed_volume(self.db, lv_name) の場合:
       例外を発生させます。ManageExistingAlreadyManaged(volume_ref=lv_name) 
 
   # OpenStack の内部名と一致するようにLV の名前を変更しようとします。
   試す：
       self.vg.rename_volume(lv_name, ボリューム[ 'name' ])
 processutils.ProcessExecutionErrorを除き、excとして:
       exception_message = (_( "論理ボリューム %(name)s の名前変更に失敗しました。"  
 "エラー メッセージ: %(err_msg)s" )
                            % { '名前' : lv_name,
 'err_msg' : 標準エラー出力})
       例外を発生させます。VolumeBackendAPIException(
           データ=例外メッセージ)

ソース コードから、Cinder は Cinder ボリュームに対応するように LV の名前を自動的に変更することがわかります。管理と作成***の違いは次のようになります。

• create はバックエンド ドライバーを呼び出してボリュームを作成します。
• Manage はバックエンド ドライバーを呼び出してボリュームの名前を変更します。

もちろん、反対の操作である unmanage もありますが、これは基本的に delete 操作と同じです。唯一の違いは、delete はバックエンド ストレージを呼び出してデータ ボリュームを完全に削除するのに対し、unmanage はボリューム データベース レコードのみを削除し、バックエンド ストレージのデータ ボリュームは削除しないことです。

ただし、Cinder は現在、ローカル マシンへのボリュームのインポート/エクスポートをサポートしていません。ただし、管理機能は元々、インポート ボリューム ブループリントを実装するために設計されました。エクスポートインポートボリュームの追加を参照してください。

ローカルアタッチ

OpenStack のブロック ストレージ サービスである Cinder は、通常、OpenStack 仮想マシンにマウントされ、仮想ハード ディスクとして使用されます。しかし、ボリュームは物理マシンまたはホストマシンにマウントできますか?答えはイエスです！ボリュームをローカルにマウントします。これをローカル アタッチと呼びます。

ただし、デフォルトの cinderclient にはローカル アタッチ コマンドがないため、cinderclient 拡張パッケージをインストールする必要があります。

 pip で python-brick-cinderclient-ext をインストールします

インストール後、cinder CLI にさらに 2 つのサブコマンドがあることがわかります。

 cinderヘルプgrep ローカル ローカルアタッチ 
ローカルデタッチ

以下はボリュームをローカルにマウントする方法を示しています。

まずボリュームを作成します。

 $ シンダー作成  --ボリュームタイプ lvm --name int32bit-test-local-attach 1  
 + --------------------------+------------------------------------------------+  
 |プロパティ |価値 |
 + --------------------------+------------------------------------------------+  
 |添付サーバー | [] |
 |添付ファイル ID | [] |
 |可用性ゾーン |新星
|起動可能 |誤り|
 |一貫性グループ ID |なし |
 |作成日時 | 2017-09-28T02:50:16.000000 |
 |説明 |なし |
 |暗号化された |誤り|
 | id | af767c74-1902-4a7a-8fff-4ea68695a3f8 |
 |メタデータ | {} |
 |移行ステータス |なし |
 |マルチアタッチ |誤り|
 |名前| int32bit-テスト-ローカル-アタッチ |
 | os-vol-host-attr:ホスト |なし |
 | os-vol-mig-status-attr:migstat |なし |
 | os-vol-mig-status-attr:name_id | os-vol-mig-status-attr:name_id |なし |
 | os-vol-テナント属性:テナント ID | ae21d957967d4df0865411f0389ed7e8 |
 |レプリケーションステータス |なし |
 |サイズ| 1 |
 |スナップショット ID |なし |
 |ソースボリュームID |なし |
 |ステータス |作成中 |
 |更新日時 |なし |
 |ユーザーID | 70828c56f2844a9090d286c29a1fb599 |
 |ボリュームタイプ | lvm |
 + --------------------------+------------------------------------------------+  

ボリュームのステータスが利用可能になるまで待った後、local-attach サブコマンドを使用してボリュームをローカルにマウントします。

 $ cinderローカル-attach af767c74-1902-4a7a-8fff-4ea68695a3f8
 + ----------+-----------------------------------+  
 |プロパティ |価値 |
 + ----------+-----------------------------------+  
 |パス | /dev/sdb |
 | scsi_wwn | 360000000000000000e000000000010001 |
 |タイプ |ブロック |
 + ----------+-----------------------------------+  

上記の出力は、ボリュームがローカル コンピューターに正常にマウントされ、/dev/sdb にマップされていることを示しています。

ファイルシステムをインストールし、ローカルにマウントします。

 $ mkfs.ext4 /dev/sdb
 mke2fs 1.42.13 (2015年5月17日)
 262144 個の 4k ブロックと65536 個の inodeを持つファイルシステムを作成しています
ファイルシステム UUID: 2a3fdcac-3a68-494a-830d-2bbebddaa875
ブロックに保存されるスーパーブロックのバックアップ:
        32768、98304、163840、229376 
 
グループテーブルの割り当て: 完了
inode テーブルの書き込み: 完了
ジャーナルを作成中 (8192 ブロック): 完了
スーパーブロックとファイルシステムのアカウンティング情報の書き込み: 完了
 
 $ マウント /dev/sdb /mnt
 $ ls /月
紛失物+拾得物

この時点で、ボリュームをローカル ハード ディスクとして使用できます。 local-detach サブコマンドを使用して、ボリュームをローカル ホストから切り離すことができます。

移行

Glance はメンバーを通じて他のテナントとイメージを共有する機能をサポートしていることがわかっています。当然、次の疑問は、Cinder がボリュームの 1 つを他のテナントと共有できるかどうかです。残念ながら、Cinder にはメンバーの概念がないため、メンバーを介して他のテナントとボリュームを共有することはサポートされていません。

ただし、Cinder はボリュームの所有権を別のテナントに譲渡することをサポートしています。この動作は転送と呼ばれます。

まず、管理者テナントの下にボリュームを作成します。

シンダー作成  --name int32bit-テスト転送1  

この時点では、デモ テナントの下に作成したボリュームは表示されません。

 $ ソース openrc_demo
 $ シンダーリスト
+ --------+----------+------+------+---------------+----------+-------------+  
 | ID |ステータス |名前|サイズ|ボリュームタイプ |起動可能 |添付|​
 + --------+----------+------+------+---------------+----------+-------------+  
 + --------+----------+------+------+---------------+----------+-------------+  

管理テナントの下に転送を作成します。

 $ cinder 転送作成  --name テスト転送 int32bit テスト転送 
 + -------------+----------------------------------------+  
 |プロパティ |価値 |
 + -------------+----------------------------------------+  
 |認証キー |翻訳:
 |作成日時 | 2017-09-28T05:25:20.105051 |
 | id | b03c0b07-1e1c-4df3-b096-be3c66b433f7 |
 |名前|テスト転送 |
 |ボリュームID | 093f41b1-39f9-4a01-bfb8-116baf1dbe2f |
 + -------------+----------------------------------------+  

上記の auth_key 出力は非常に重要であり、作成されたときにのみ出力されます。後で API 経由でこの auth_key を取得することはできません。相手側はこの auth_key を通じて転送を受け取ります。この時点で、ボリュームのステータスは転送待ちに変わります。

デモテナントで承認:

 $ シンダー転送受け入れ b03c0b07-1e1c-4df3-b096-be3c66b433f7 c259b651426121fd
 + -----------+----------------------------------------------+  
 |プロパティ |価値 |
 + -----------+----------------------------------------------+  
 | id | b03c0b07-1e1c-4df3-b096-be3c66b433f7 |
 |名前|テスト転送 |
 |ボリュームID | 093f41b1-39f9-4a01-bfb8-116baf1dbe2f |
 + -----------+----------------------------------------------+  

最初のパラメータは転送 ID で、2 番目のパラメータは auth_key です。

デモでボリュームを確認します。

 $ シンダーリスト
+ -------------------------------------+----------+--------------------------+----------+-------------+----------+---------------+  
 | ID |ステータス |名前|サイズ|ボリュームタイプ |起動可能 |添付|​
 + -------------------------------------+----------+--------------------------+----------+-------------+----------+---------------+  
 | 093f41b1-39f9-4a01-bfb8-116baf1dbe2f |利用可能 | int32bit テスト転送 | 1 | lvmドライバ-1 |誤り| |
 + -------------------------------------+----------+--------------------------+----------+-------------+----------+---------------+  

ボリュームがデモ テナントに正常に転送されたことがわかります。

transfer_id と auth_key を取得した人は誰でも転送されたボリュームを受け取ることができるため、auth_key は必ず秘密にしておくようにしてください。 auth_key は一度だけ使用できます。引き継ぎが完了すると、対応する転送インスタンスは自動的に削除されます。

バックアップエクスポート

Cinder バックアップは、Cinder ボリュームを Ceph や Swift などのリモート ストレージ システムにバックアップできます。しかし、バックアップのメタデータはどうでしょうか?データベースレコードが失われた場合、データを復元することはできません。

バックアップ中にバックアップメタデータは保存されないのですか? と疑問に思う人もいるかもしれません。バックアップメタデータを使用しないのはなぜですか?これは、すべてのバックアップがメタデータをリモートで保存するわけではないためです。たとえば、cinder-volume とバックアップ ストレージ バックエンドの両方が Ceph ドライバーを使用する場合、バックアップはメタデータを必要としない rbd のインポートを直接使用します。したがって、バックアップされた Ceph にはメタデータは保存されません。

幸いなことに、Cinder はメタデータをエクスポートするためのバックアップ エクスポートをサポートしています。

 $ cinder --debug バックアップエクスポート fcbbfcca-b83e-4fab-acb6-7dbbd017b151  
 {
 「バックアップレコード」 : {
 「backup_service」 : 「cinder.backup.drivers.swift」 、
 「バックアップURL」 : 「eyJzdGF0dXM...efQ=="  
    }
 }

上記の eyJzdGF0dXM...efQ== 文字列は非常に長いです。組版の都合上、中間の大部分を省略しています。出力される backup_url は文字列です。それは何の用途ですか?ソースコードを確認してみましょう:

 def export_record(自己、コンテキスト、バックアップ):
 # ...
 # ドライバーに電話して バックアップ説明文字列を作成する
試す：
   バックアップサービス = self.service.get_backup_driver(コンテキスト)
   driver_info = backup_service.export_record(バックアップ)
   バックアップURL = バックアップ.encode_record(ドライバー情報 = ドライバー情報)
   バックアップレコード[ 'バックアップURL' ] = バックアップURL
例外をerrとして除く:
   メッセージ = six.text_type(エラー)
   例外を発生させます。InvalidBackup(理由=msg)

ソース コードから、export_record はバックアップ インスタンスを通じて encode_record を呼び出すことによって完了することがわかりました。 encode_record の役割は明らかにシリアル化プロセスです。ソースコードを見てみましょう:

 @base.remotable
 def encode_record(self, **kwargs):
 "" "オプションの追加情報を含むバックアップ オブジェクトを文字列にシリアル化します。" 「」  
    #余分なフィールドをエクスポートしたくないので、  怠惰を強制する
    # 読み込み中なので、dict(self)やself.obj_to_primitive は使用できません
    レコード = { name : field.to_primitive(self, name , getattr(self, name ))
のために  name 、 self.fields.items()内のフィールド}
    #代わりにkwargsを更新する必要があります 記録を上書きしないようにする
    #バックアップからの「実際の」データ
    クワーグ。更新（記録）
    戻り値 = jsonutils.dump_as_bytes(kwargs)
 base64.encode_as_text(retval)を返す

ソース コードからわかるように、バックアップは最初に json 形式にシリアル化され、次に base64 に変換されます。私はそれを確認できます:

 $ パイソン
Python 2.7.5 (デフォルト、 2016 年 11 月 6 日、 00:28:07)
 [GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] linux2上
「ヘルプ」 、 「著作権」 、 「クレジット」と入力してください または  "ライセンス"  詳細についてはこちらをご覧ください。
 >>> base64 をインポート
>>> base64.b64デコード( 'eyJzdGF0dXM...fQ==' )
 '{"status": "available", "temp_snapshot_id": null, "display_name": "2", "availability_zone": "nova", "deleted": false, "volume_id": "676ec7a5-d4ae-43d9-88cd-bd93dc143538", "restore_volume_id": null, "updated_at": "2017-08-30T05:56:47Z", "host": "devstack", "snapshot_id": null, "user_id": "a61a3c0659bd4cca8cb5f66ea2fe3df7", "service_metadata": "volume_676ec7a5-d4ae-43d9-88cd-bd93dc143538/20170830055626/az_nova_backup_fcbbfcca-b83e-4fab-acb6-7dbbd017b151", "id": "fcbbfcca-b83e-4fab-acb6-7dbbd017b151", "size": 1, "object_count": 22, "deleted_at": null, "container": "cinder-backup", "service": "cinder.backup.drivers.swift", "driver_info": {}, "created_at": "2017-08-30T05:56:23Z", "disk_size": 3444122, "display_description": "", "data_timestamp": "2017-08-30T05:56:23Z", "parent_id": null, "num_dependent_backups": 0, "fail_reason": null, "project_id": "42ee53fa480f49149ce5c3df4a953a6b", "temp_volume_id": null}'  

次に、データベースからバックアップ レコードを削除します。

 MariaDB [cinder]>削除  ID= 'fcbbfcca-b83e-4fab-acb6-7dbbd017b151'のバックアップから;
クエリは正常、1 行が影響を受けました (0.00 秒)

この時点で、Cinder はバックアップ レコードを見つけることができません。

 $ cinder バックアップ ショー fcbbfcca-b83e-4fab-acb6-7dbbd017b151
エラー:名前付きのボリュームバックアップがありません またはID​   'fcbbfcca-b83e-4fab-acb6-7dbbd017b151'が存在します。

次に、backup-import を使用してレコードを復元します。

 $ cinder バックアップをインポート cinder.backup.drivers.swift eyJzdGF0dXM...efQ==
 + ------------+----------------------------------------+  
 |プロパティ |価値 |
 + ------------+----------------------------------------+  
 | id | fcbbfcca-b83e-4fab-acb6-7dbbd017b151 |
 |名前|なし |
 |親ID |なし |
 |プロジェクトID | 42ee53fa480f49149ce5c3df4a953a6b |
 + ------------+--------------------------------------+  

バックアップ レコードが正常に復元されました:

 $ cinder バックアップ ショー fcbbfcca-b83e-4fab-acb6-7dbbd017b151
 + -----------------------+--------------------------------------+  
 |プロパティ |価値 |
 + -----------------------+--------------------------------------+  
 |可用性ゾーン |新星
|コンテナ | cinder バックアップ |
 |作成日時 | 2017-08-30T05:56:23.000000 |
 |データタイムスタンプ | 2017-08-30T05:56:23.000000 |
 |説明 | |
 |ディスクサイズ | 3444122 |
 |失敗理由 | |
 |依存バックアップあり |誤り|
 | id | fcbbfcca-b83e-4fab-acb6-7dbbd017b151 |
 |増分です |誤り|
 |名前| 2 |
 |オブジェクト数 | 22 |
 |親ID |なし |
 |プロジェクトID | 42ee53fa480f49149ce5c3df4a953a6b |
 |サイズ| 1 |
 |スナップショット ID |なし |
 |ステータス |利用可能 |
 |更新日時 | 2017-08-30T05:56:47.000000 |
 |ボリュームID | 676ec7a5-d4ae-43d9-88cd-bd93dc143538 |
 + -----------------------+--------------------------------------+  

要約する

上記では、主に次のような OpenStack の非常に便利な操作をいくつか紹介しました。

• 一目見るメンバー
• 一目でわかるタスク
• ノヴァロック
• ノヴァシェルフ
• ノヴァレスキュー
• 燃え殻管理
• cinder ローカルアタッチ
• cinder バックアップエクスポート
• 燃え殻の移動

今後も新しい興味深い操作を見つけて追加していきます。

【この記事は51CTOコラムニスト「Fu Guangping」によるオリジナル記事です。転載が必要な場合は51CTOまでご連絡ください]

この著者の他の記事を読むにはここをクリックしてください