OpenStack仮想マシンにデータボリュームをマウントするプロセスの分析

1 OpenStackについて

これは、パブリック クラウドとプライベート クラウドの展開と管理を実装する IaaS オープン ソース プロジェクトです。最も人気のあるオープンソース クラウド ソリューションの 1 つになりました。その中で、コンピューティング サービス コンポーネント Nova、ネットワーク サービス コンポーネント Neutron、ブロック ストレージ サービス コンポーネント Cinder が OpenStack のコア コンポーネントです。ここでは Nova と Cinder のコンポーネントに焦点を当て、Neutron のコンポーネントについては次の記事で詳しく紹介します。

[[203580]]

1.1 コンピューティング サービス NovaNova

このコンポーネントは、AWS の EC2 サービスと同様に、OpenStack にコンピューティング サービス (Compute as Service) を提供します。 Nova が管理する主なオブジェクトはクラウド ホスト (サーバー) であり、ユーザーは Nova API を通じてクラウド ホスト (サーバー) リソースを申請できます。クラウド ホストは通常​​、仮想マシンに対応しますが、必ずしもそうとは限りません。コンテナ (docker ドライバー) またはベアメタル マシン (ironic ドライバーとのインターフェイス) の場合もあります。

Nova がクラウド ホストを作成するために必要な 3 つのパラメーターは次のとおりです。

• 画像: クラウド ホストを起動したときのイメージです。イメージ ソースは、Glance または Cinder のボリューム (ボリュームからの起動) からダウンロードできます。
• フレーバー: フレーバーには、CPU コアの数、メモリ サイズ、ルート ディスク サイズ、スワップ サイズなど、要求されたリソースの数が含まれます。リソースの数に加えて、フレーバーには、IO 速度制限、CPU トポロジ、およびその他の機能を設定するために使用できる、追加仕様と呼ばれるいくつかの機能構成も含まれます。
• ネットワーク: クラウド ホストのテナント ネットワーク。

クラウド ホストを作成するための CLI は次のとおりです。

 nova ブート--image ${IMAGE_ID} --flavor m1.small --nic net-id=${NETWORK_ID} int32bit-test-1  

nova list を使用して、テナントのすべてのクラウド ホストのリストを表示します。

1.2 ブロックストレージサービス Cinder

Cinder コンポーネントは、AWS の EBS サービスと同様に、OpenStack にブロック ストレージ サービス (Block Storage as Service) を提供します。 Cinder によって管理される主なオブジェクトはデータ ボリュームです。ユーザーは、Cinder API を通じて、ボリュームの作成、削除、拡張、スナップショット、バックアップなどの操作を実行できます。

ボリュームを作成するには、次の 2 つのパラメータが必要です。

• volume_type: volume_type は、ストレージ バックエンド、QoS 情報などのバックエンド ストレージ情報に関連付けられています。
• size: 作成されたボリュームのサイズ。

20G のボリュームを作成します。

シンダー作成  --ボリュームタイプ ssd --name int32bit-テストボリューム 20  

現在、Cinder の最も一般的なアプリケーション シナリオは、Nova クラウド ホストにクラウド ハード ディスク機能を提供することです。ユーザーはボリュームを Nova クラウド ホストにマウントし、それをクラウド ホストの仮想ブロック デバイスとして使用できます。

ボリュームのマウントは Nova 側で行います。

nova ボリュームアタッチ ${server_id} ${volume_id}

Cinder は、Nova クラウド ホストにクラウド ハード ディスク機能を提供するだけでなく、ベア メタル マシン、コンテナーなどにデータ ボリューム機能を提供することもできます。John Griffith は、Cinder を使用して Docker にボリューム機能を提供する方法についてブログ記事を書いています: Cinder は Nova 以外にもブロック ストレージを提供します。

次の記事では、OpenStack がボリュームを仮想マシンにマウントする方法に焦点を当て、Nova と Cinder 間の相互作用を分析します。

2 ストレージの基本

2.1 iSCSIとは

iSCSI は、TCP/IP を介してブロック デバイスを共有するためのプロトコルです。このプロトコルを通じて、サーバーはローカル ブロック デバイスを他のサーバーと共有できます。つまり、このプロトコルは、インターネット経由でデバイスに SCSI コマンドを送信することを実装します。

iSCSI サーバーはターゲットと呼ばれ、クライアントはイニシエーターと呼ばれます。サーバーは複数のターゲットを同時に実行できます。ターゲットは、複数のバックストアを含めることができる物理ストレージ プールと考えることができます。 Backstore は共有するデバイスです。実際のアプリケーションには主に 2 つの種類があります。

• ブロック。つまり、ブロック デバイスは、/dev/sda などのローカル ハード ディスク、または LVM ボリュームになります。
• ファイルio。ローカル ファイルを、生の仮想ハード ディスクなどのブロック デバイスとして扱います。

上記 2 つのカテゴリの他に、pscsi、ramdisk なども存在します。

指定されたターゲットにバックストアを追加する必要があります。これにより、これらの物理デバイスが論理デバイスにマップされ、LUN (論理ユニット番号) と呼ばれる ID が割り当てられます。

iSCSI をより深く理解するために、次のセクションでは iSCSI の使用方法を手動で段階的に練習します。

2.2 iSCSIの実践

まず、ターゲットとしてiscsiサーバーを準備します。ここでは、CentOS 7 を例に、iscsi サービスをインストールして起動します。

 yum インストール targetcli -y
 systemctl ターゲットを有効にする
systemctl 開始ターゲット

targetcli を実行して、インストールが成功したかどうかを確認します。

 int32bit$ ターゲットcli
 targetcli シェル バージョン 2.1.fb41
 Copyright 2011-2013 Datera , Incおよびその他。
コマンドのヘルプについては、 「help」と入力してください。 
 
 /> ls
 o- / ................................... [...]
  o-バックストア ................................... [...]
  | o-ブロック............[ストレージオブジェクト: 0]
  | o- fileio ............ [ストレージオブジェクト: 0]
  | o- pscsi ............ [ストレージオブジェクト: 0]
  | o- ramdisk ........... [ストレージオブジェクト: 0]
  o-iscsi ........................ [ターゲット: 0]
  o- ループバック ........................ [ターゲット: 0]

すべてが正常であれば、targetcli シェルに入ります。すべてのバックストアと iSCSI ターゲットを表示するには、ルート ディレクトリで ls コマンドを実行します。

具体的な targetcli コマンドについては、公式ドキュメントを参照してください。ここで注目すべきは、targetcli シェルにはコンテキスト セッションがあり、これは Linux ファイル システム ディレクトリとして簡単に理解できるということです。さまざまな機能は、現在いるディレクトリの場所に対応しています。たとえば、/backstores ディレクトリにいる場合はバックストアを管理でき、/iscsi ディレクトリにいる場合はすべての iscsi ターゲットを管理できます。 pwd で現在の作業ディレクトリを表示したり、cd で作業ディレクトリを切り替えたり、help で現在の作業環境のヘルプ情報を表示したり、ls でサブディレクトリ構造を表示したりすることができます。コマンドの補完には Tab キーを使用できますが、これは Linux シェルの操作と非常によく似ているため、比較的簡単に使用できます。

簡単にするために、fileio タイプのバックストアを作成します。まず、/backstores/fileio ディレクトリに cd します。

 /> cd /backstores/fileio
 /backstores/fileio> test_fileio を作成/tmp/test_fileio.raw 2G write_back= false  
 fileio test_fileioを作成しました サイズ2147483648

test_fileio という名前の fileio タイプのバックストアを作成しました。ファイル パスは /tmp/test_fileio.raw、サイズは 2G で、ファイルが存在しない場合は自動的に作成されます。

バックストアを作成した後、ターゲットを作成し、/iscsi ディレクトリに cd します。

 /iscsi> iqn.2017-09.me.int32bit:int32bitを作成します
ターゲット iqn.2017-09.me.int32bit:int32bit を作成しました。
 TPG 1を作成しました。
デフォルトのポータルは作成されません。ターゲット内の TPG は IP:ポートを共有できません。
 /iscsi>

上記では、int32bit という名前のターゲットを作成しました。先頭の iqn.2017-09.me.int32bit は iSCSI 修飾名 (IQN) です。具体的な意味については、Wikipedia-ISCSI を参照してください。ここでは、単純に一意の名前空間として理解できます。 ls コマンドを使用して、ディレクトリ iqn.2017-09.me.int32bit:int32bit が作成されたことがわかりました (注: 実際にはディレクトリではありませんが、ここではこのように理解します)。

ターゲットを作成した後、ターゲットをエクスポートする、つまり、ポータルと呼ばれるリスニング状態に入る必要があります。ポータルの作成も非常に簡単です。

 /iscsi> cd iqn.2017-09.me.int32bit:int32bit/tpg1/portals/
 /iscsi/iqn.20.../tpg1/portals> 10.0.0.4を作成します
デフォルトのIPポート3260を使用
ネットワーク ポータル 10.0.0.4:3260 を作成しました。

上記では、10.0.0.4 がサーバーの IP アドレスです。ポートが指定されていない場合は、デフォルトのポート 3260 が使用されます。

ターゲットが作成されました。これで、先ほど作成したバックストアをこのターゲットに追加できます。

 /iscsi/iqn.20.../tpg1/portals> cd ../luns
 /iscsi/iqn.20...ビット/tpg1/luns> /backstores/fileio/test_fileioを作成します
LUN 0 を作成しました。

この時点で、ターゲットには lun デバイスが含まれています。

 /iscsi/iqn.20...ビット/tpg1/luns> ls /iscsi/iqn.2017-09.me.int32bit:int32bit/
 o- iqn.2017-09.me.int32bit:int32bit ................................................................................................ [TPG: 1]
  o-tpg1 ................................................................................................ [ -gen-aclsなし、 -authなし]
    o- acls ................................................................................................................ [ACL: 0]
    o-luns ............................................................................................................................. [LUN: 1]
    | o-lun0 ............................................................................. [fileio/test_fileio (/tmp/test_fileio.raw)]
    o-ポータル ................................................................................................................ [ポータル: 0]

次に、クライアント側の iSCSI イニシエーターを構成します。

 yum インストール iscsi-initiator-utils -y
 systemctl を有効にする iscsid iscsi
 systemctl 開始 iscsid iscsi

このマシンのイニシエーター名を取得します:

 int32bit $ cat /etc/iscsi/イニシエータ名.iscsi
イニシエーター名=iqn.1994-05.com.redhat:e0db637c5ce

クライアントはサーバー ターゲットに接続する必要があり、ACL 認証も必要です。サーバーにクライアントのアクセス権を追加し、サーバー上で実行します。

 int32bit$ ターゲットcli
 targetcli シェル バージョン 2.1.fb41
 Copyright 2011-2013 Datera , Incおよびその他。
コマンドのヘルプについては、 「help」と入力してください。 
 
 /> cd /iscsi/iqn.2017-09.me.int32bit:int32bit/tpg1/acls
 /iscsi/iqn.20...ビット/tpg1/acls> iqn.1994-05.com.redhat:e0db637c5ce を作成します
iqn.1994-05.com.redhat:e0db637c5ceのノード ACL を作成しました
マップされた LUN 0 を作成しました。

注: 上記ではアカウントとパスワードを設定していないため、クライアントは直接ログインできます。

準備はすべて整いました。クライアント側でターゲットに接続しましょう。

まず、iscsiadm コマンドを使用して、ローカルで表示可能なターゲット リストを自動的に検出します。

 int32bit $ iscsiadm --mode discovery --type sendtargets --portal 10.0.0.4 | grep int32bit  
 10.0.0.4:3260,1 iqn.2017-09.me.int32bit:int32bit

ターゲットを見つけたら、ログインして検証することで使用できます。

 int32bit $ iscsiadm -m node -T iqn.2017-09.me.int32bit:int32bit -l
ログイン  [iface: default 、ターゲット: iqn.2017-09.me.int32bit :int32bit、ポータル: 10.0.0.4,3260] (複数)
 [iface: default 、target: iqn.2017-09.me.int32bit:int32bit、portal: 10.0.0.4,3260]へのログインに成功しました。

ログインしているすべてのターゲットを表示できます。

 int32ビット $ iscsiadm -m セッション
tcp: [173] 10.0.0.4:3260,1 iqn.2010-10.org.openstack:volume-1e062767-f0bc-40fb-9a03-7b0df61b5671 (非フラッシュ)
 tcp: [198] 10.0.0.4:3260,1 iqn.2010-10.org.openstack:volume-060fe764-c17b-45da-af6d-868c1f5e19df (非フラッシュ)
 tcp: [199] 10.0.0.4:3260,1 iqn.2010-10.org.openstack:volume-757f6281-8c71-430e-9f7c-5df2e3008b46 (非フラッシュ)
 tcp: [203] 10.0.0.4:3260,1 iqn.2010-10.org.openstack:volume-2ed1b04c-b34f-437d-9aa3-3feeb683d063 (非フラッシュ)
 tcp: [205] 10.0.0.4:3260,1 iqn.2017-09.me.int32bit:int32bit (非フラッシュ)

この時点で、ターゲットはローカル ブロック デバイスに自動的にマップされており、lsblk を使用して表示できます。

 int32ビット $ lsblk --scsi  
名前HCTL タイプ ベンダー モデル REV TRAN
 sda 0:0:2:0 ディスク ATA インテル SSDSC2BX40 DL2B
 sdb 0:0:3:0 ディスク ATA INTEL SSDSC2BX40 DL2B
 sdc 0:0:4:0 ディスク ATA INTEL SSDSC2BX40 DL2B
 sdd 0:0:5:0 ディスク ATA INTEL SSDSC2BX40 DL2B
 sde 0:0:6:0 ディスク ATA インテル SSDSC2BX40 DL2B
 sdf 0:0:7:0 ディスク ATA インテル SSDSC2BX40 DL2B
 sdg 0:2:0:0 ディスク DELL PERC H330 Mini 4.26
 sdh 183:0:0:0 ディスク LIO-ORG IBLOCK 4.0 iscsi
 sdi 208:0:0:0 ディスク LIO-ORG IBLOCK 4.0 iscsi
 sdj 209:0:0:0 ディスク LIO-ORG IBLOCK 4.0 iscsi
 sdk 213:0:0:0 ディスク LIO-ORG IBLOCK 4.0 iscsi
 sdm 215:0:0:0 ディスク LIO-ORG test_fileio 4.0 iscsi

マップされたローカルデバイスは /dev/shm であることがわかります。その後、ローカル ハード ドライブのように使用できます。

上記では、ターゲット サーバー上のローカル ファイルを通じてブロック単位でデータを共有します。これは通常、テストにのみ使用されます。実稼働環境では、実際のブロック デバイスは通常、共有用に商用ストレージによって提供されます。 OpenStack Cinder が LVM ドライバーを使用する場合、LVM ボリュームを通じて共有されます。これを達成するのは難しくありません。ブロック バックストアに LVM に対応する LV PATH を追加するだけです。この状況については、この記事の後半で詳しく説明します。

2.3 cinder-rtstool の紹介

先ほど使用した targetcli は Datera によって開発されました。Datera はこの CLI ツールを提供するだけでなく、Python ライブラリ rtslib も提供しています。プロジェクトのアドレスはrtslibです。おそらく何らかの理由で、コミュニティは rtslib プロジェクトをフォークし、「フリー ブランチ」という名前の別のブランチ、つまり rtslib-fb プロジェクトを維持しました。現在、これら 2 つのブランチは互換性がない可能性があります。そのため、targetcli、rtslib、configshell が同じバージョン ブランチ (すべて fb またはすべて non-fb) にあることを確認してください。

OpenStack コミュニティは、rtstool に基づく CLI ツールをカプセル化しました。これが、これから紹介する cinder-rtstool ツールです。このツールの使い方は非常に簡単です。ヘルプ情報を確認してみましょう:

 $ cinder-rtstool --help  
使用法：
 cinder-rtstool create [デバイス] [名前] [ユーザーID] [パスワード] [iser_enabled] <イニシエーターIQN、IQN2、IQN3、...> [-a<IP1、IP2、...>] [-pPORT]
 cinder-rtstool add -initiator [target_iqn] [userid] [ password ] [initiator_iqn]
 cinder-rtstool削除-イニシエーター [ターゲットIQN] [イニシエーターIQN]
 cinder-rtstool ターゲットを取得する
cinder-rtstool削除[iqn]
 cinder-rtstool 検証
cinder-rtstool 保存 [ファイルへのパス]

このツールは主にターゲット側、つまり cinder-volume が配置されているノードで実行されます。 create コマンドは、対応するポータルの作成を含め、ターゲットをすばやく作成し、デバイスをターゲットに追加するために使用されます。 add-initiator は ACL の作成に対応し、get-targets は現在のサーバーによって作成されたすべてのターゲットを一覧表示します。他のコマンドについては詳しく説明しません。基本的に、その機能は推測できると思います。

2.4 ceph rbdの紹介

Ceph は、高いスケーラビリティ、高いパフォーマンス、高い信頼性の利点を備えたオープンソースの分散ストレージ システムです。また、ブロック ストレージ サービス (rbd)、オブジェクト ストレージ サービス (rgw)、ファイル システム ストレージ サービス (cephfs) も提供します。これは現在、OpenStack の主流のバックエンド ストレージであり、OpenStack に統合された共有ストレージ サービスを提供しています。 OpenStack のバックエンド ストレージとして Ceph を使用すると、少なくとも次の利点があります。

1. すべてのコンピューティング ノードはストレージを共有するため、移行中にブロック デバイスをコピーする必要はありません。コンピューティング ノードがクラッシュした場合でも、仮想マシンは別のコンピューティング ノード上ですぐに起動できます (退避)。
2. COW 機能を利用すると、仮想マシンを作成するときに、イメージ全体をダウンロードせずにイメージに基づいてクローンを作成するだけで済み、クローン操作のオーバーヘッドは基本的にゼロになります。
3. Ceph rbd はシンプロビジョニングをサポートしています。これは、オンデマンドでスペースを割り当てることを意味し、Linux ファイルシステムのスパースファイルに似ています。 20 GB の仮想ハード ディスクの作成を開始すると、実際の物理ストレージ領域は占有されません。データが書き込まれるときにのみスペースが 1 つずつ割り当てられるため、ディスクが過負荷になります。

ceph の詳細については、公式ドキュメントを参照してください。ここでは rbd について簡単に紹介します。

先ほど紹介した iSCSI にはターゲットという概念があります。ストレージ デバイスを指定されたターゲットに追加し、LUN にマップする必要があります。 rbd にはプールの概念もあります。 rbd によって作成された仮想ブロック デバイス インスタンスは、イメージと呼ばれます。すべての画像はプールに含める必要があります。ここではプールの役割については説明せず、単に名前空間として理解します。

rbd コマンドを使用して rbd イメージを作成できます。

 $ rbd -p test2を作成します  --size 1024 int32bit-test-rbd --新しいフォーマット 
 $ rbd -p テスト2 ls
 int32bit テスト rbd
 centos7.raw
 $ rbd -p test2 情報 int32bit-test-rbd
 rbd イメージ'int32bit-test-rbd' :
サイズ1024 MB 、オブジェクト数 256
オーダー22 (4096 kB オブジェクト)
        ブロック名プレフィックス: rbd_data.9beee82ae8944a
        フォーマット: 2
        特徴: レイヤー化
        フラグ:

上記では、create サブコマンドを使用して、サイズが 1G の int32bit-test-rbd という名前のイメージを作成します。ここで、-p パラメータ値 test2 はプール名です。 ls コマンドを使用してすべてのイメージのリストを表示したり、info コマンドを使用してイメージの詳細情報を表示したりできます。

iSCSI が lun デバイスを作成した後、イニシエーターはログインを通じてデバイスをローカル コンピューターにマップします。 rbd イメージは、マップ操作を通じてローカル コンピューターにマップされます。クライアントに ceph クライアント パッケージをインストールし、証明書を構成したら、rbd map を使用して証明書をローカル コンピューターにマップするだけです。

 $ rbd -p test2 マップ int32bit-test-rbd
 /dev/rbd0

この時点で、作成されたイメージをローカル ブロック デバイスとして /dev/rbd0 にマッピングしました。これで、デバイスをローカル ディスクのように使用できるようになりました。

2.5 ブロックデバイスを仮想マシンにマウントする方法

仮想マシンにブロック デバイスを提供するには、qemu-kvm で --drive パラメータを使用して指定するだけです。 libvirt を使用する場合、CLI virsh を例にとると、attach-device サブコマンドを使用してデバイスを仮想マシンにマウントできます。このコマンドには 2 つの必要なパラメータが含まれています。1 つはドメイン、つまり仮想マシン ID であり、もう 1 つはデバイスのアドレス情報を含む XML ファイルです。

 $ virsh help アタッチデバイス
名前 
    アタッチデバイス - XML ファイルからデバイスをアタッチする
 
  概要
    アタッチデバイス <ドメイン> <ファイル> [ --persistent] [--config] [--live] [--current]   
 
  説明
    XML <ファイル>からデバイスを接続します。 
 
  オプション
    [ --domain] <文字列> ドメイン名、ID、またはUUID  
    [ --file] <文字列> XMLファイル 
 --persistent ライブ変更を永続化する 
 --config 次回の起動に影響します 
 --live 実行中のドメインに影響します 
 --current 現在のドメインに影響します 

iSCSI デバイスは、まず lun デバイスをホスト マシンにマップし、次にそれをローカル デバイスとしてマウントする必要があります。簡単なデモ XML は次のとおりです。

 <ディスクタイプ= 'ブロック'デバイス= 'ディスク' >
      <ドライバー名= 'qemu'タイプ = 'raw'キャッシュ = 'none' io = 'native' />
      <ソース dev= '/dev/disk/by-path/ip-10.0.0.2:3260-iscsi-iqn.2010-10.org.openstack:volume-2ed1b04c-b34f-437d-9aa3-3feeb683d063-lun-0' />
      <ターゲットデバイス= 'vdb'バス= 'virtio' />
      <シリアル>2ed1b04c-b34f-437d-9aa3-3feeb683d063</シリアル>
      <アドレス タイプ = 'pci'ドメイン = '0x0000'バス = '0x00'スロット = '0x06'  関数= '0x0' />
 </ディスク>

ソースは、LUN デバイスからローカル デバイスにマップされたパスであることがわかります。

libvirt は、rbd イメージの直接マウント (ホストに rbd カーネル モジュールが含まれている必要があります) と、最初にホストにマップすることなく rbd プロトコルを介してイメージにアクセスすることをサポートすることに言及する価値があります。デモの XML ファイルは次のとおりです。

 <ディスクタイプ= 'ネットワーク'デバイス= 'ディスク' >
      <ドライバー名= 'qemu'タイプ = 'raw'キャッシュ = 'writeback' />
      <認証ユーザー名= 'admin' >
        <シークレットタイプ= 'ceph' uuid= 'bdf77f5d-bf0b-1053-5f56-cd76b32520dc' />
      </auth>
      <ソースプロトコル= 'rbd'  名前= 'nova-pool/962b8560-95c3-4d2d-a77d-e91c44536759_disk' >
        <ホスト名= '10.0.0.2'ポート = '6789' />
        <ホスト名= '10.0.0.3'ポート = '6789' />
        <ホスト名= '10.0.0.4'ポート = '6789' />
      </ソース>
      <ターゲットデバイス= 'vda'バス= 'virtio' />
      <アドレス タイプ = 'pci'ドメイン = '0x0000'バス = '0x00'スロット = '0x05'  関数= '0x0' />
 </ディスク>

したがって、Cinder で LVM ドライバーを使用する場合は、まず LV を iSCSI ターゲットに追加し、それをコンピューティング ノードのホストにマップする必要があります。 rbd ドライバーを使用する場合は、それをコンピューティング ノードにマップする必要がなく、直接マウントできます。

上記ではストレージに関する基本的な知識を紹介しました。この知識があれば、OpenStack nova と cinder を理解するのは非常に簡単です。次に、正式なトピックに入り、OpenStack 仮想マシンにデータ ボリュームをマウントするプロセスを分析します。

3 OpenStack仮想マシンボリュームマウントソースコード分析

ここでは、LVM ドライバーを使用する Ciner、lioadm を使用する iSCSI ドライバーを例に挙げ、バックエンド構成を次のようにします。

 [lvm]
 iscsi_helper=lioadm
ボリュームドライバ=cinder.volume.drivers.lvm.LVMVolumeDriver
ボリュームバックエンド名=lvm
ボリュームグループ = cinderボリューム

OpenStack ソースコードの読み方の詳細については、「OpenStack ソースコードの読み方」を参照してください。ここでは詳細には触れません。ここで注目すべきは、Nova には、データ ボリュームと仮想マシン間のマッピング関係を保存するために特別に使用されるデータベース テーブルがあるということです。このテーブルは block_device_mapping と呼ばれ、そのフィールドは次のとおりです。

 MariaDB [nova]> desc block_device_mapping;
 + -----------------------+--------------+------+-----+---------+--------------+  
 |フィールド |タイプ |ヌル|キー|デフォルト|追加 |
 + -----------------------+--------------+------+-----+---------+--------------+  
 |作成日時 |日時 |はい | | NULL | |
 |更新日時 |日時 |はい | | NULL | |
 |削除された日付 |日時 |はい | | NULL | |
 | id |整数(11) |いいえ​プライバシーポリシーNULL |自動増分 |
 |デバイス名 | varchar (255) |はい | | NULL | |
 |終了時に削除 |整数(1) |はい | | NULL | |
 |スナップショット ID | varchar (36) |はい |マルNULL | |
 |ボリュームID | varchar (36) |はい |マルNULL | |
 |ボリュームサイズ |整数(11) |はい | | NULL | |
 |デバイスなし |整数(1) |はい | | NULL | |
 |接続情報 |中テキスト |はい | | NULL | |
 |インスタンスUUID | varchar (36) |はい |マルNULL | |
 |削除済み |整数(11) |はい | | NULL | |
 |ソースタイプ | varchar (255) |はい | | NULL | |
 |宛先タイプ | varchar (255) |はい | | NULL | |
 |ゲストフォーマット | varchar (255) |はい | | NULL | |
 |デバイスタイプ | varchar (255) |はい | | NULL | |
 |ディスクバス | varchar (255) |はい | | NULL | |
 |ブートインデックス |整数(11) |はい | | NULL | |
 |画像ID | varchar (36) |はい | | NULL | |
 + -----------------------+--------------+------+-----+---------+--------------+  

Cinder には、マウント ステータスを記録するための別のテーブル volume_attachment もあります。

 MariaDB [cinder]> desc volume_attachment;
 + ---------------+--------------+------+-----+----------+-------+  
 |フィールド |タイプ |ヌル|キー|デフォルト|追加 |
 + ---------------+--------------+------+-----+----------+-------+  
 |作成日時 |日時 |はい | | NULL | |
 |更新日時 |日時 |はい | | NULL | |
 |削除された日付 |日時 |はい | | NULL | |
 |削除済み |整数(1) |はい | | NULL | |
 | id | varchar (36) |いいえ​プライバシーポリシーNULL | |
 |ボリュームID | varchar (36) |いいえ​マルNULL | |
 |接続ホスト | varchar (255) |はい | | NULL | |
 |インスタンスUUID | varchar (36) |はい | | NULL | |
 |マウントポイント | varchar (255) |はい | | NULL | |
 |アタッチ時間 |日時 |はい | | NULL | |
 |デタッチ時間 |日時 |はい | | NULL | |
 |アタッチモード | varchar (36) |はい | | NULL | |
 |アタッチステータス | varchar (255) |はい | | NULL | |
 + ---------------+--------------+------+-----+----------+-------+  
 13行 で 設定(0.00 秒)

次に、nova-api から始めて、プロセスを段階的に実行します。

S1 ノヴァアピノヴァアピ

ボリュームをマウントするためのエントリ ポイントは nova/api/openstack/compute/volumes.py、コントローラーは VolumeAttachmentController、仮想マシンにボリュームをマウントするためのメソッドは create です。

このメソッドは、まずボリュームが仮想マシンにすでにマウントされているかどうかを確認します。

 bdms = オブジェクト.ブロックデバイスマッピングリスト.get_by_instance_uuid(
                コンテキスト、インスタンス.uuid)
 bdmのbdmsの場合:
    bdm.volume_id == volume_idの場合:
        _msg = _( "ボリューム %(volume_id)s が " に接続されました 
 "インスタンス %(server_id)s。" ) % {
 'ボリュームID' : ボリュームID、
 'server_id' : サーバーID}
        exc.HTTPConflict を発生させます (説明 = _msg)

次に、nova/compute/api.py の attach_volume メソッドを呼び出します。このメソッドは次のことを行います。

(1) ボリュームを作成する()

つまり、block_device_mapping テーブルに対応するレコードを作成します。 API ノードは、マウント後にターゲット仮想マシンのデバイス名 (/dev/vdb など) を取得できないため、コンピューティング ノードのみが仮想マシンがどのデバイスにマップされているかを認識します。したがって、bdm は API ノード上に作成されず、仮想マシンが配置されているコンピューティング ノードへの RPC 要求を通じて作成されます。リクエストメソッドは reserve_block_device_name です。これは最初に libvirt を呼び出して /dev/vdb などのデバイス名を割り当て、次に対応する bdm インスタンスを作成します。

(2) チェックアタッチとボリュームの確保()

これには、check_attach と reserve_volume の 2 つのプロセスが含まれます。 Check_attach はボリュームがマウントできるかどうかを確認します。たとえば、ステータスは使用可能である必要があります。また、複数のマウントがサポートされている場合は、ステータスは使用中または使用可能である必要があります。メソッドの場所は、nova/volume/cinder.py の check_attach メソッドです。 reserve_volume は Cinder によって完了し、nova-api は cinder API を呼び出します。このメソッドは実際には何も行わず、ボリュームのステータスを接続に設定するだけです。メソッド フロー: nova-api -> cinder-api -> reserver_volume、メソッドは cinder/volume/api.py にあります:

 @wrap_check_policy
 def reserve_volume(自己、コンテキスト、ボリューム):
    期待値 = { 'multiattach' : volume.multiattach,
 'ステータス' : (( '利用可能' 、 '使用中' ) ボリュームのマルチアタッチの場合
それ以外  '利用可能' ）} 
 
    結果 = volume.conditional_update({ 'status' : 'attaching' }, 予想) 
 
    結果がない場合は:
        予想されるステータス = utils.build_or_str(予想される[ 'ステータス' ])
        msg = _( '予約するにはボリュームのステータスが %s である必要があります。' ) % expected_status
        LOG.エラー(メッセージ)
        例外を発生させます。InvalidVolume(理由=msg) 
 
    LOG.info(_LI( "ボリュームの予約が正常に完了しました。" ),
             リソース=ボリューム)

(3) RPC計算ノードのattach_volume()

この時点で、nova-api はターゲット コンピューティング ノードへの RPC 要求を開始します。 rpcapi.py の attach_volume メソッドは cast メソッドを呼び出すため、RPC は非同期呼び出しになります。この時点で、nova-api の作業は完了し、残りの作業は仮想マシンが配置されているコンピューティング ノードによって完了します。

S2 ノヴァコンピューティングノヴァコンピューティング

RPC リクエストを受信した後、コールバック関数のエントリは nova/compute/manager.py の attach_volume メソッドになります。このメソッドは、以前に作成された bdm インスタンス パラメータに従って driver_block_device に変換し、クラスの attach メソッドを呼び出します。これは特定のハードウェア層に到達しました。ボリュームの種類に応じて、異なる特定のクラスがインスタンス化されます。ここでのタイプはボリュームなので、nova/virt/block_device.py にある DriverVolumeBlockDevice に対応します。

仮想マシンがボリュームをマウントするための最も重要な方法であり、実装の中核でもあるアタッチ方法を見てみましょう。この方法はいくつかの段階に分かれています。一つずつ見ていきましょう。

(1) get_volume_connector()

このメソッドは、まず virt_driver.get_volume_connector(instance) を呼び出します。ここで、virt_driver は libvirt です。このメソッドは nova/virt/libvirt/driver.py にあり、実際には os-brick の get_connector_properties を呼び出します。

 get_volume_connector を定義します(self, インスタンス):
   root_helper = utils.get_root_helper()
コネクタ.get_connector_properties(を返します。
       root_helper、CONF.my_block_storage_ip、
       CONF.libvirt.iscsi_use_multipath、
       強制マルチパス= True 、
       ホスト=CONF.host)

os-brick は Cinder プロジェクトから分離されたライブラリであり、さまざまなストレージ システムのボリュームを管理するために特に使用されます。コード リポジトリは os-brick です。 get_connector_properties メソッドは、os_brick/initiator/connector.py にあります。

デフ get_connector_properties(root_helper、my_ip、マルチパス、enforce_multipath、
                             ホスト=なし):
    iscsi = ISCSIコネクタ(root_helper=root_helper)
    fc = linuxfc.LinuxFibreChannel(root_helper=root_helper) 
 
    小道具 = {}
    props[ 'ip' ] = my_ip
    props[ 'host' ] = host の場合 host、そうでない場合はsocket.gethostname()
    イニシエーター = iscsi.get_initiator()
    イニシエーターの場合:
        props[ 'initiator' ] = イニシエーター
    fc.get_fc_wwpns() 関数
    wwwpnsの場合:
        props[ 'wwpns' ] = wwpns
    fc.get_fc_wwnns() 関数
    場合:
        props[ 'wwnns' ] = wwnns
    props[ 'multipath' ] = (マルチパスと 
                          _check_multipathd_running(ルートヘルパー、
                                                    強制マルチパス
    props[ 'プラットフォーム' ] = プラットフォーム.マシン()
    props[ 'os_type' ] = sys.platform
リターンプロップ

このメソッドの最も重要なタスクは、コンピューティング ノードの情報 (IP、オペレーティング システムの種類など) とイニシエーター名 (セクション 2 を参照) を返すことです。

(2) volume_api.initialize_connection()

ついに、シンダーが実際の仕事をする番です!このメソッドは、Cinder API の initialise_connection メソッドを呼び出し、ボリュームが配置されている cinder-volume サービス ノードに RPC 要求を送信します。 cinder-api をスキップして、直接 cinder-volume に進みます。

S3 シンダーボリューム

コードの場所は cinder/volume/manager.py です。この方法も段階に分かれています。

(1) ドライバ.validate_connector()

この方法はドライバーによって異なります。 LVM + iSCSI の場合は、イニシエーター フィールド、つまり nova-compute ノードのイニシエーター情報があるかどうかを確認します。コードは cinder/volume/targets/iscsi.py にあります:

 defvalidate_connector(self, コネクタ):
   # NOTE(jdg): api はイニシエーター情報であるコネクタを渡します
   'イニシエーター'の場合 ない コネクタ内:
       err_msg = (_LE( 'ボリュームドライバにはiSCSIイニシエーターが必要です'  
 「コネクタ内の名前」 ))
       LOG.エラー(err_msg)
       例外が発生します。InvalidConnectorException(missing= 'initiator' )
戻る 真実 

上記のコードジャンプ プロセスに注意してください: drivers/lvm.py -> target/lio.py -> target/iscsi.py。つまり、lvm ドライバーはターゲットの対応するメソッドを呼び出します。ここでは lio を使用するため、lio.py を呼び出します。lio は iscsi から継承するため、iscsi.py にジャンプします。以下の分析では、これらの詳細をスキップして、次のセクションに直接進みます。

(2) ドライバ.create_export()

メソッドは cinder/volume/targets/iscsi.py にあります:

 def create_export(self、コンテキスト、ボリューム、ボリュームパス):
    # 'iscsi_name' : 'iqn.2010-10.org.openstack:volume-00000001'  
    iscsi_name = "%s%s" % (self.configuration.iscsi_target_prefix、
                           ボリューム[ '名前' ])
    iscsi_target、lun = self._get_target_and_lun(コンテキスト、ボリューム)
    chap_auth = self._get_target_chap_auth(コンテキスト、iscsi_name)
    chap_authでない場合:
        chap_auth = (vutils.generate_username(),
                     vutils.generate_password()) 
 
    # ポータルの IPとポートを取得する
    ポータル構成 = self._get_portals_config()
    tid = self.create_iscsi_target(iscsi_name,
                                   iscsi_target、
                                   ルン、
                                   ボリュームパス、
                                   chap_auth、
                                   **ポータル構成)
    データ = {}
    データ[ '場所' ] = self._iscsi_location(
        self.configuration.iscsi_ip_address、tid、iscsi_name、lun、
        自己.configuration.iscsi_secondary_ip_addresses)
    LOG.debug( 'provider_location を %s に設定' , data[ 'location' ])
    データ[ 'auth' ] = self._iscsi_authentication(
 'CHAP' 、*chap_auth)
データを返す

このメソッドの最も重要な操作は、create_iscsi_target メソッドを呼び出すことです。このメソッドは、実際には cinder-rtstool の create メソッドを呼び出します。

 command_args = [ 'cinder-rtstool' ,
 '作成する' 、
            パス、
名前、
            chap_auth_userid、
            chap_auth_password、
            self.iscsi_protocol == 'iser' ] + オプション引数
self._execute(*command_args, run_as_root= True )

つまり、create_export メソッドの主なタスクは、cinder-rtstool ツールを呼び出してターゲットを作成し、デバイスをターゲットに追加することです。

cinder-volume ノードでは、targetcli を通じてエクスポートされたすべてのターゲットを表示できます。

 /iscsi> ls /iscsi/ 1
 o-iscsi ................................................................................................................................ [ターゲット: 5]
  o- iqn.2010-10.org.openstack:volume-2ed1b04c-b34f-437d-9aa3-3feeb683d063 .................................. [TPG: 1]
  o- iqn.2010-10.org.openstack:volume-70347e2a-cdfc-4575-a891-3973ec264ec0 .................................. [TPG: 1]
  o- iqn.2010-10.org.openstack:volume-980eaf85-9d63-4e1e-9e47-75f1a14ecc40 .................................. [TPG: 1]
  o- iqn.2010-10.org.openstack:volume-db6aa94d-64cc-4996-805e-f768346d8082 .................................. [TPG: 1]

(3) ドライバ.initialize_connection()

これが最後のステップです。このメソッドは cinder/volume/targets/lio.py にあります:

 definitialize_connection(self、ボリューム、コネクタ):
    volume_iqn = volume[ 'プロバイダの場所' ].split( ' ' )[1]
    (認証方法、認証ユーザー、認証パス) = \
        ボリューム[ 'provider_auth' ].split( ' ' , 3)
    #ターゲット ACLにイニシエーター IQNを追加する
    試す：
        self._execute( 'cinder-rtstool' , 'add-initiator' ,
                      ボリューム_iqn、
                      認証ユーザー、
                      認証パス、
                      コネクタ[ 'イニシエーター' ],
                      run_as_root = True )
 putils.ProcessExecutionErrorを除く:
        LOG.exception(_LE( "イニシエーターIQN %sをターゲットに追加できませんでした" ),
                      コネクタ[ 'イニシエーター' ])
        例外が発生します。ISCSITargetAttachFailed(
            volume_id=ボリューム[ 'id' ])
    self._persist_configuration(ボリューム[ 'id' ])
 super(LioAdm, self).initialize_connection(ボリューム, コネクタ)を返します。

この方法の重要なタスクは、cinder-rtstool の add-initiator サブコマンドを呼び出すこと、つまり、作成したばかりのターゲット ACL にコンピューティング ノードのイニシエーターを追加することです。

targetcli の出力は次のとおりです。

 /iscsi> ls /iscsi/iqn.2010-10.org.openstack:volume-2ed1b04c-b34f-437d-9aa3-3feeb683d063/tpg1/acls/
 o- acls ................................................................................................................................ [ACL: 1]
  o- iqn.1994-05.com.redhat:e0db637c5ce .................................................. [1 方向認証、マップされた LUN: 1]
    o- マップされた lun0 ........................ [lun0 ブロック/iqn.2010-10.org.openstack:volume-2ed1b04c-b34f-437d-9aa3-3feeb683d063 (rw)]

したがって、シンダーの主なタスクは、ボリュームのISCSIターゲットとACLSを作成することです。シンダーボリュームの作業が終了し、Nova Computeに戻ります。

S4 Nova-Compute

Nova-Computeのステップ（2）に戻り、volume_api.initialize_connection（）を呼び出し、ステップ（3）を実行します。

（3）virt_driver.attach_volume（）

この時点で、Libvirtレイヤーに到達します。コードは nova/virt/libvirt/driver.py にあります。この方法は、次の手順に分かれています。

1。_Connect_Volume（）メソッドは、nova/virt/libvirt/volume/iscsi.pyのconnect_volume（）メソッドを呼び出します。この方法は、実際には、OS-BrickのConnect_Volume（）メソッドを直接呼び出します。この方法は、os_brick/initiator/connector.pyのiscsiconnectorクラスのconnect_volumeメソッドにあります。このメソッドは、以前に導入されたISCSIADMコマンドのディスコボリーとログインサブコマンドを呼び出します。つまり、LUNデバイスをローカルデバイスにマッピングします。

ISCSIADMを使用して、接続されているすべてのボリューム（ログイン）を表示できます。

 $ ISCSIADM -Mセッション
TCP：[203] 10.0.0.4:3260,1 IQN.2010-10.org.openStack：Volume-2ED1B04C-B34F-437D-9AA3-3FEEB683D063（非フラッシュ）
 TCP：[206] 10.0.0.4:3260,1 IQN.2010-10.org.openstack：Volume-980EAF85-9D63-4E1E-9E47-75F1A14ECC40（非フラッシュ）
 TCP：[207] 10.0.0.4:3260,1 IQN.2010-10.org.openstack：Volume-70347E2A-CDFC-4575-A891-3973EC264EC0（非フラッシュ）
 TCP：[208] 10.0.0.4:3260,1 IQN.2010-10.org.openStack：Volume-DB6AA94D-64CC-4996-805E-F768346D8082（非フラッシュ）

LSBLKを使用して、マッピングパスを表示します。

 $ lsblk -scsi  
名前HCTLタイプベンダーモデルRev Tran
 ...＃出力を省略します
SDH 216：0：0：0ディスクLIO-ORG IBLOCK 4.0 ISCSI
 SDI 217：0：0：0ディスクLIO-ORG IBLOCK 4.0 ISCSI
 SDJ 218：0：0：0ディスクLIO-ORG IBLOCK 4.0 ISCSI
 SDK 213：0：0：0 DISK LIO-ORG IBLOCK 4.0 ISCSI

Linux /dev /disk by-pathにもあります。

 $ ls -l/dev/disk/ by -path/
合計 0
 lrwxrwxrwx 1 root root 9 Sep 6 17:21 IP-10.0.0.4：3260-ISCSI-IQN.2010-10.org.openStack：Volume-2ED1B04C-B34F-437D-9AA3-3-3EEEB683D063-LUN-0-> ..//SSDK
 lrwxrwxrwx 1ルートルート9 Sep 8 17:34 IP-10.0.0.4：3260-ISCSI-IQN.2010-10.org.openStack：Volume-70347E2A-CDFC-4575-A891-3973EC264444444444575-A891-3973EC264444444444444444444444444
 lrwxrwxrwx 1ルートルート9 Sep 8 17:29 IP-10.0.0.4：3260-ISCSI-IQN.2010-10.org.openStack：Volume-980EAF85-9D63-4E1E-9E47-75F1A14ECCCCC40-LUN-0-> ../
 lrwxrwxrwx 1 root root 9 Sep 8 17:35 IP-10.0.0.4：3260-ISCSI-IQN.2010-10.org.openStack：Volume-DB6AA94D-64CC-4996-805E-F768346D8082-LUN-0-> ..//SDJ

2。_GET_VOLUME_CONFIG（）

ボリュームの情報を取得するには、実際にはXMLを生成するために必要な情報です。最も重要なことは、/dev/disk/by-path/ip-0.0.0.2:3260-iscsi-iqn.2010-10.openstack:volume-060fe764-c17b-45da-af6d-868c1f5e19df-lun-0を取得することです。返されたconfは最終的にXML形式に変換されます。このコードは、nova/virt/libvirt/volume/iscsi.pyにあります：

 def get_config（self、connection_info、disk_info）：
 "" "libvirtのXMLを返します。" 「」  
    conf = super（libvirtiscsivolumedriver、
                 self）.get_config（connection_info、disk_info）
    conf.source_type = "block"  
    conf.source_path = connection_info [ 'data' ] [ 'device_path' ]
    conf.driver_io = "ネイティブ"  
 confを返します

3。Guest.Attach_Device（）が最後に最後のステップに到達します。このステップは、実際には、Virsh Attach-Deviceコマンドを呼び出して、デバイスを仮想マシンにマウントすることに似ています。このコードは、nova/virt/libvirt/guest.pyにあります：

 def attach_device（self、conf、persistent = false 、live = false ）：
 "" "デバイスをゲストに接続します。 
 
   ：param conf ：添付するデバイスのlibvirtconfigobject
   ：Param Persistent：変更があるかどうかを示すためのブール 
                      永続的または ない 
   ：Param Live：ゲストに影響するかどうかを示すブール
実行状態
「」 「 」
   フラグ=永続的およびlibvirt.vir_domain_affect_configまたは0
   フラグ| = live and libvirt.vir_domain_affect_liveまたは0
   self._domain.attachdeviceflags（conf.to_xml（）、flags = flags）

Libvirtの作業は完成し、現時点ではボリュームが仮想マシンにマウントされています。

（4）volume_api.attach（）

nova/virt/block_device.pyに戻り、最後にvolume_api.attach（）メソッドが呼び出されます。この時点で、Cinder-APIはRPCを介してCinder-volumeを要求し、コードはCinder/Volume/Manager.pyにあります。この方法は何もしませんが、実際にデータベースを更新し、ボリューム状態を使用して使用し、対応する添付ファイルレコードを作成しています。

この時点で、OpenStackのマウントプロセス全体が最終的に終了しました。 Novaの観点から分析しています。 Cinderの観点から分析すると、Cinderには実際にはあまり作業がありません。概要は次のとおりです。

• Resirse_Volume：ボリュームのステータスをアタッチメントに変更して、他のノードがマウント操作を実行しないようにします。
• intialize_connection：ターゲット、lun、aclsなどを作成します。
• attach_volume：ボリュームステータスを使用して、マウントが成功します。

4 OpenStack仮想マシンマウントRBD分析

LVM + LIOのボリュームマウントプロセスを以前に分析しました。 RBDがマウントされた場合の違いは何ですか？ここでは、詳細なプロセスを詳細に導入するのではなく、Cinder-Volumeのinitialize_connectionから始めます。 cinder-volumeのinitialize_connectionステップを分析しました。

• driver.validate_connector（）
• driver.create_export（）
• driver.initialize_connection（）

Ceph RBDに対応するのは非常に簡単です。 RBDはISCSIのようなターゲットやポータルを作成する必要がないため、RBDドライバーのcreate_export（）メソッドは空です。

 def create_export（self、context、volume、connector）：
 "" "ボリュームをエクスポートします。 「」  
    合格

intialize_connection（）メソッドも非常にシンプルであり、プール、画像名、MONアドレス、CEPH構成情報などのRBD画像情報を直接返します。

 def initialize_connection（self、volume、connector）：
    ホスト、ports = self._get_mon_addrs（）
    data = {
 'driver_volume_type' ： 'rbd' 、
 'データ' ： {
 'name' ： '％s/％s' ％（self.configuration.rbd_pool、
                               音量。名前）、
 「ホスト」 ：ホスト、
 「ポート」 ：ポート、
 'auth_enabled' ：（ self.configuration.rbd_user is  何もない）、
 'auth_username' ：self.configuration.rbd_user、
 'Secret_type' ： 'Ceph' 、
 'Secret_uuid' ：self.configuration.rbd_secret_uuid、
 'Volume_id' ：volume.id、
 'rbd_ceph_conf' ：self.configuration.rbd_ceph_conf、
        }
    }
    log.debug（ '接続データ：％s' 、データ）

前述のように、RBDは仮想デバイスをホストにマッピングする必要がないため、Connect_Volumeメソッドも空です。

作業の残りの部分は、実際にはget_config（）メソッドを呼び出して、monアドレス、RBD画像情報、認証情報などをCEPHの情報を取得し、XML形式に変換することです。最後に、guest.attach_device（）を呼び出して、ボリュームマウントを完了します。

したがって、RBDマウントプロセスはISCSIよりもはるかに簡単です。

4 結論

プロセス全体を要約するには、LVM+LIOを例に取ります。ボリュームの作成からボリュームの取り付けまでのプロセスは次のとおりです。

Cinder-Volumeノードで指定されたLVMボリュームグループ（VG）でLVMボリューム（LV）の作成に相当するボリュームを作成します。

マウントボリュームはNOVAによって開始されます。 Nova-APIは、ボリュームステータスをチェックしてから、CINDERに通知します。 CINDERは、ボリュームステータスを設定して添付します。

残りの作業のほとんどは、最初にノードのISCSI名を取得するNova-Computeによって行われます。

Nova-ComputeはCinderをリクエストし、Cinderは対応するターゲットを作成し、ACLSにNova Computeノードを追加します。

Nova-Computeノードは、ISCSIAADMコマンドを介してボリュームをローカルエリアにマッピングします。このプロセスは、接続ボリュームと呼ばれます。

NOVA-Computeノードは、マウントされたXML構成ファイルを生成します。

Nova-Computeは、Virtual MachineにマウントボリュームにlibvirtのAttach-Deviceインターフェイスを呼び出します。

マウントプロセスは、次のフローチャートとして要約されています。

上記の分析は、添付APIの古いバージョンに基づいていることに注意する必要があります。コミュニティは、OCATAバージョンから新しいボリュームアタッチAPIを導入および開発しました。プロセス全体を再設計する必要がある場合があります。詳細については、新しい添付APIの追加を参照してください。この新しいAPI設計により、マルチマウントをより適切に実装し、CinderとNovaの一貫性のない状態の問題をより適切に解決します。

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

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