CephとOpenStack – ベストプラクティス 第2部

Ceph and OpenStack – Best Practices Part II

先週は Ceph と OpenStack – ベストプラクティス 第1部について紹介しましたが、今回は前回の提案に引き続き、CephとOpenStackを統合するためのベストプラクティスをいくつか追加で紹介します。これらの設定をさらに活用することで、OpenStackとCephをより高度に統合できます。

RAWイメージの使用

前回の記事 Ceph と OpenStack – ベストプラクティス 第1部 では、RBD自体にレイヤリング(layering)機能があることを紹介しましたが、この機能にはいくつかの制限があります。OpenStackにアップロードするイメージは、RBDレイヤリングを利用するためにRAW形式である必要があります。そのため、アップロードするすべてのイメージを事前にRAW形式に変換しておくことをお勧めします。qemu-imgコマンドを使えば、さまざまな形式を簡単に変換できます。

qemu-img  convert image.qcow2 image.raw

その後、RAW形式のイメージをOpenStackにアップロードすれば、RBDレイヤリング機能が使用されるようになります。

VMでVirtio-SCSIを使用するためのイメージ設定

エフェメラルディスクであれボリュームであれ、RBDバックエンドのNova VMは、デフォルトでVirtio-blkドライバを使用してゲストがRBDイメージにアクセスできるようにします。この際、VirtIOは準仮想化(paravirtual)I/Oバスを提供し、デバイスは/dev/vda、/dev/vdbのように命名されます。VirtIOブロックデバイスは軽量で効率的ですが、discardコマンドをサポートしていません。

discardを使用できないということは、ゲストがディスクをマウントする際にdiscardオプションを使用できないことを意味します。つまり、システムがfstrimを通じて解放されたブロックをクリアできないということです。これは、ユーザーが削除しようとしたデータが実際には削除されたり上書きされたりしないため、セキュリティ上の問題を引き起こします。セキュリティの問題に加えて、これは運用側にとっても問題となります。

discardがサポートされていないと、RBDイメージのRADOSオブジェクトがイメージのライフサイクル全体を通じて削除されなくなります。つまり、イメージ全体が削除されるまで存在し続けます。その結果、Cephクラスター内には、決して使用されることのない数万ものRADOSオブジェクトが存在し続ける可能性があります。

幸いなことに、別のVirtIOディスクドライバであるVirtIO SCSIコントローラ(virtio-scsi)は、discardコマンドをサポートしています。

OpenStack上でVirtIO SCSIコントローラーを有効にするには、glanceのイメージプロパティ(image properties)を設定する必要があります。具体的には、hw_scsi_modelとhw_disk_busの指定が必要です。以下のOpenStack CLIコマンドを使って簡単に設定できます:

openstack image set 
  --property hw_scsi_model=virtio-scsi 
  --property hw_disk_bus=scsi 
  <image 的名稱或 ID>

また、複数のイメージがある場合は、簡単なスクリプトを使用できます。

for i in $(openstack image list | awk '{print $2}' | sed "s/ID//g");
do
    openstack image  set --property hw_scsi_model=virtio-scsi --property hw_disk_bus=scsi \
        --property hw_qemu_guest_agent=yes --property os_require_quiesce=yes $i
done

このイメージを使用してインスタンスを作成すると、以前は/dev/vdXだったデバイス名が/dev/sdXに変わり、SCSIスタックのすべての情報を取得できるようになります。例えば、/proc/scsi/scsiが存在し、SCSIバスやコントローラの情報を取得したり、lssciを通じてLU(論理ユニット)などを確認したりできます。

ブートボリュームがSCSIコントローラ経由でインスタンスに提供されるだけでなく、その後アタッチされるすべてのボリュームも同様にSCSIコントローラを使用します。したがって、これらのボリュームでもdiscardを利用して空きブロックのクリーンアップを行うことができます。

CinderマルチバックエンドとボリュームタイプによるCephプールの使い分け

オールフラッシュとHDDの2つのCephプールが混在する場合、Cinderのマルチバックエンド(multi-backend)とボリュームタイプ(Volume Type)を使用して2つのプールを区別する必要があります。この場合、cinder.confでボリュームバックエンドの設定を変更する必要があります。

[DEFAULT]
enabled_backends=rbd-hdd,rbd-ssd
scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler
default_volume_type = hdd

[rbd-hdd]
rbd_ceph_conf=/etc/ceph/ceph.conf
rbd_user=cinder
backend_host=rbd:volumes
rbd_pool=volumes
volume_backend_name=rbd-hdd
volume_driver=cinder.volume.drivers.rbd.RBDDriver
rbd_secret_uuid = {{ cinder_rbd_secret_uuid }}

[rbd-ssd]
rbd_ceph_conf=/etc/ceph/ceph.conf
rbd_user=cinder
backend_host=rbd:volumes
rbd_pool=volumes-ssd
volume_backend_name=rbd-ssd
volume_driver=cinder.volume.drivers.rbd.RBDDriver
rbd_secret_uuid = {{ cinder_rbd_secret_uuid }}

上記の設定で、2つのCinderバックエンドを有効にしました。rbd-ssd<code> 跟 </code>rbd-hdd<code>。</code>rbd-ssd<code> 會使用 Ceph 的 </code>volumes-ssd<code> 這個 pool,而 </code>rbd-hdd<code> 使用 </code>volumes このプールです。さらに、Cinderのスケジュールドライバーと、デフォルトで選択されるボリュームタイプの設定も必要です。

最後に、OpenStack CLIを通じて、各バックエンドに対応するボリュームタイプを作成する必要があります:

openstack --os-username admin --os-tenant-name admin volume type create ssd
openstack --os-username admin --os-tenant-name admin volume type set ssd \
  --property volume_backend_name=rbd-ssd
openstack --os-username admin --os-tenant-name admin volume type create hdd
openstack --os-username admin --os-tenant-name admin volume type set hdd \
  --property volume_backend_name=rbd-hdd

その後は、ボリューム作成時にボリュームタイプを指定することで、対応するCephプールを利用できるようになります。

Cinderボリュームタイプを利用したQoSの適用

ボリュームタイプは通常、異なるCinderバックエンドを区別するために使用されます。例えば、ユーザーがCeph RBDとNetAppのどちらでボリュームを作成するかを選択できるようにします。しかし、それだけでなく、運用担当者はこの機能を利用して、同一のバックエンドに対して異なるQoSプロファイルを設定することもできます。Cinder QoSでは、ボリュームの最大IOPSや最大スループットなどを制限でき、OpenStack CLIやHorizonダッシュボードから設定可能です。

シーケンシャル読み書き速度を150MB/s、ランダム読み書き速度を1000 IOPSに制限する場合:

openstack volume qos create \
  --consumer front-end \
  --property total_bytes_sec=$((100<<20)) \
  --property total_iops_sec=1500 \
  "volume_qos"

次に、対応するボリュームタイプを作成し、QoSスペックを適用する必要があります:

openstack volume type create --public "volume_qos"
openstack volume qos associate "volume_qos" "volume_qos"

最後に、ボリュームタイプをパブリックに設定するか、特定のプロジェクトのみがアクセスできるように制限できます。

パートI

リファレンス


著作権表示:このブログのすべての記事は、以下のライセンスのもとで提供されています。 CC BY-NC-SA 4.0 (別途記載がある場合を除く)

コメントを残す