20 RADOS Block Device #
ブロックとは連続するバイトのことで、たとえば4MBブロックのデータなどです。ブロックベースのストレージインタフェースは、ハードディスク、CD、フロッピーディスクなどの回転型媒体にデータを保存する最も一般的な方法です。Block Deviceインタフェースはあらゆるところで利用されているため、仮想ブロックデバイスは、Cephのような大容量データストレージシステムを操作するための理想的な候補です。
Ceph Block
Deviceは物理リソースを共有でき、サイズの変更が可能です。データはCephクラスタ内の複数のOSD上にストライプされて保存されます。Ceph
Block Deviceは、スナップショットの作成、レプリケーション、整合性などのRADOSの機能を利用します。CephのRBD (RADOS Block
Device)は、カーネルモジュールまたはlibrbdライブラリを使用してOSDと対話します。
Cephのブロックデバイスは、高いパフォーマンスと無限のスケーラビリティをカーネルモジュールに提供します。これらは、QEMUなどの仮想化ソリューションや、OpenStackなど、libvirtに依存するクラウドベースのコンピューティングシステムをサポートします。同じクラスタを使用して、Object
Gateway、CephFS、およびRADOS Block Deviceを同時に運用できます。
20.1 Block Deviceのコマンド #
rbdコマンドを使用して、Block
Deviceイメージを作成、一覧、イントロスペクト、および削除できます。さらに、イメージのクローン作成、スナップショットの作成、スナップショットへのイメージのロールバック、スナップショットの表示などの操作にも使用できます。
20.1.1 複製プールでのBlock Deviceイメージの作成 #
Block Deviceをクライアントに追加する前に、既存のプール内に、関連するイメージを作成する必要があります(第18章 「ストレージプールの管理」を参照)。
cephuser@adm > rbd create --size MEGABYTES POOL-NAME/IMAGE-NAMEたとえば、「mypool」という名前のプールに情報を保存する「myimage」という名前の1GBのイメージを作成するには、次のコマンドを実行します。
cephuser@adm > rbd create --size 1024 mypool/myimage
サイズの単位のショートカット(「G」または「T」)を省略した場合、イメージのサイズはメガバイト単位になります。ギガバイトまたはテラバイトを指定するには、サイズの数字の後に「G」または「T」を使用します。
20.1.2 イレージャコーディングプールでのBlock Deviceイメージの作成 #
Block DeviceイメージのデータをEC (イレージャコーディング)プールに直接保存できます。RADOS Block
Deviceイメージは、「データ」部分と「メタデータ」部分で構成されます。ECプールには、RADOS
Block
Deviceイメージの「データ」部分のみを保存できます。プールはoverwriteフラグがtrueに設定されている必要があります。このように設定できるのは、プールが保存されているすべてのOSDがBlueStoreを使用している場合のみです。
ECプールにイメージの「メタデータ」の部分を保存することはできません。rbd
createコマンドの--pool=オプションを使用してイメージのメタデータを保存する複製プールを指定するか、イメージ名のプレフィックスとしてpool/を指定できます。
ECプールを作成します。
cephuser@adm >ceph osd pool create EC_POOL 12 12 erasurecephuser@adm >ceph osd pool set EC_POOL allow_ec_overwrites true
メタデータを保存する複製プールを指定します。
cephuser@adm > rbd create IMAGE_NAME --size=1G --data-pool EC_POOL --pool=POOLまたは:
cephuser@adm > rbd create POOL/IMAGE_NAME --size=1G --data-pool EC_POOL20.1.3 Block Deviceイメージの一覧 #
「mypool」という名前のプール内のBlock Deviceを一覧にするには、次のコマンドを実行します。
cephuser@adm > rbd ls mypool20.1.4 イメージ情報の取得 #
「mypool」という名前のプール内のイメージ「myimage」から情報を取得するには、次のコマンドを実行します。
cephuser@adm > rbd info mypool/myimage20.1.5 Block Deviceイメージのサイズの変更 #
RADOS Block
Deviceイメージはシンプロビジョニングされます。つまり、そこにデータを保存し始めるまでは、実際に物理ストレージを使用しません。ただし、--sizeオプションで設定する最大容量があります。イメージの最大サイズを増やす(または減らす)場合、次のコマンドを実行します。
cephuser@adm >rbd resize --size 2048 POOL_NAME/IMAGE_NAME # to increasecephuser@adm >rbd resize --size 2048 POOL_NAME/IMAGE_NAME --allow-shrink # to decrease
20.1.6 Block Deviceイメージの削除 #
「mypool」という名前のプール内にあるイメージ「myimage」に対応するBlock Deviceを削除するには、次のコマンドを実行します。
cephuser@adm > rbd rm mypool/myimage20.2 マウントとアンマウント #
RADOS Block Deviceを作成した後は、他のディスクデバイスと同じように使用できます。デバイスをフォーマットし、マウントしてファイルを交換できるようにし、完了したらアンマウントできます。
デフォルトでは、rbdコマンドはCephのadminユーザアカウントを使用してクラスタにアクセスします。このアカウントはクラスタに対する完全な管理アクセス権限を持ちます。そのため、Linuxワークステーションにrootでログインした場合と同様に、誤って損害を発生させてしまうリスクが発生します。したがって、特権を制限したユーザアカウントを作成して、RADOS
Block Deviceの通常の読み込み/書き込みアクセスに使用することが望ましいです。
20.2.1 Cephユーザアカウントの作成 #
Ceph Manager、Ceph Monitor、Ceph
OSDのケーパビリティを使用して新しいユーザアカウントを作成するには、cephコマンドとauth
get-or-createサブコマンドを使用します。
cephuser@adm > ceph auth get-or-create client.ID mon 'profile rbd' osd 'profile profile name \
[pool=pool-name] [, profile ...]' mgr 'profile rbd [pool=pool-name]'たとえば、vmsプールへの読み込み/書き込みアクセスと、imagesプールへの読み込み専用アクセスができる、qemuという名前のユーザを作成するには、次のコマンドを実行します。
ceph auth get-or-create client.qemu mon 'profile rbd' osd 'profile rbd pool=vms, profile rbd-read-only pool=images' \ mgr 'profile rbd pool=images'
ceph auth
get-or-createコマンドは特定のユーザ用のキーリングを出力します。また、キーリングを/etc/ceph/ceph.client.ID.keyringに書き込むことができます。
rbdコマンドを使用する場合、オプションの--id
ID引数を与えることでユーザIDを指定できます。
Cephユーザアカウントの管理の詳細については、第30章 「cephxを使用した認証」を参照してください。
20.2.2 ユーザ認証 #
ユーザ名を指定するには、--id
user-nameを使用します。cephx認証を使用する場合は、秘密を指定する必要もあります。秘密は、キーリング、または秘密が含まれるファイルから取得できます。
cephuser@adm > rbd device map --pool rbd myimage --id admin --keyring /path/to/keyringあるいは、
cephuser@adm > rbd device map --pool rbd myimage --id admin --keyfile /path/to/file20.2.3 RADOS Block Deviceを使用するための準備 #
Cephクラスタに、マップするディスクイメージが存在するプールが含まれることを確認します。プールは
mypool、イメージはmyimageという名前であると想定します。cephuser@adm >rbd list mypoolイメージを新しいBlock Deviceにマップします。
cephuser@adm >rbd device map --pool mypool myimageすべてのマップ済みデバイスを一覧にします。
cephuser@adm >rbd device list id pool image snap device 0 mypool myimage - /dev/rbd0作業対象のデバイスは
/dev/rbd0です。ヒント: RBDデバイスのパス/dev/rbdDEVICE_NUMBERの代わりに、永続的なデバイスパスとして/dev/rbd/POOL_NAME/IMAGE_NAMEを使用できます。例:/dev/rbd/mypool/myimage
/dev/rbd0デバイス上にXFSファイルシステムを作成します。root #mkfs.xfs /dev/rbd0 log stripe unit (4194304 bytes) is too large (maximum is 256KiB) log stripe unit adjusted to 32KiB meta-data=/dev/rbd0 isize=256 agcount=9, agsize=261120 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=1024 swidth=1024 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=8 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0使用するマウントポイントに
/mntを置き換えてから、デバイスをマウントして正しくマウントされたかを確認します。root #mount /dev/rbd0 /mntroot #mount | grep rbd0 /dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...これで、ローカルディレクトリと同じように、このデバイスとの間でデータを移動できます。
ヒント: RBDデバイスのサイズを増やすRBDデバイスのサイズが十分ではなくなった場合、簡単にサイズを増やすことができます。
RBDイメージのサイズを、たとえば10GBに増やします。
cephuser@adm >rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.デバイスの新しいサイズ全体を使用するようファイルシステムを拡張します。
root #xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
デバイスへのアクセスが終わったら、デバイスをマップ解除してアンマウントできます。
cephuser@adm >rbd device unmap /dev/rbd0root #unmount /mnt
ブート後にRBDのマッピングとマウントを行い、シャットダウン前にRBDをアンマウントするプロセスをスムーズにするため、rbdmapスクリプトとsystemdユニットが提供されています。20.2.4項 「rbdmap: ブート時のRBDデバイスのマッピング」を参照してください。
20.2.4 rbdmap: ブート時のRBDデバイスのマッピング #
rbdmapは、1つ以上のRBDイメージに対するrbd
mapおよびrbd device
unmapの操作を自動化するシェルスクリプトです。このスクリプトはいつでも手動で実行できますが、ブート時にRBDイメージを自動的にマップしてマウント(シャットダウン時にはアンマウントしてマップ解除)するのが主な利点です。これはInitシステムによってトリガされます。このために、ceph-commonパッケージにsystemdのユニットファイルであるrbdmap.serviceが含まれています。
このスクリプトは引数を1つ取り、mapまたはunmapのどちらかを指定できます。どちらの場合も、スクリプトは設定ファイルを解析します。デフォルトは/etc/ceph/rbdmapですが、環境変数RBDMAPFILEで上書きできます。設定ファイルの各行が、マップまたはマップ解除する1つのRBDイメージに対応します。
構成ファイルは次のような形式になっています。
image_specification rbd_options
image_specificationプール内のイメージのパス。pool_name/image_nameとして指定します。
rbd_options基礎となる
rbd device mapコマンドに渡されるパラメータのオプションのリスト。これらのパラメータとその値をコンマ区切り文字列として指定する必要があります。次に例を示します。PARAM1=VAL1,PARAM2=VAL2,...
次の例では、
rbdmapスクリプトで次のコマンドを実行します。cephuser@adm >rbd device map POOL_NAME/IMAGE_NAME --PARAM1 VAL1 --PARAM2 VAL2次の例では、ユーザ名とキーリングを対応する秘密とともに指定する方法を確認できます。
cephuser@adm >rbdmap device map mypool/myimage id=rbd_user,keyring=/etc/ceph/ceph.client.rbd.keyring
rbdmap
mapとして実行すると、設定ファイルを解析し、指定されているRBDイメージそれぞれに対して、最初にイメージをマップし(rbd
device mapを使用)、次にイメージをマウントしようと試みます。
rbdmap
unmapとして実行すると、設定ファイルに一覧にされているイメージがアンマウントされてマップ解除されます。
rbdmap
unmap-allは、設定ファイルに一覧にされているかどうかに関係なく、現在マップされているRBDイメージをすべてアンマウントし、その後マップ解除しようと試みます。
成功した場合、イメージはrbd device
map操作によって/dev/rbdXデバイスにマップされます。この時点でudevルールがトリガされ、実際にマップされたデバイスを指すフレンドリデバイス名のシンボリックリンク/dev/rbd/pool_name/image_nameが作成されます。
正常にマウントおよびアンマウントするには、/etc/fstabに「フレンドリ」デバイス名に対応するエントリが必要です。RBDイメージの/etc/fstabエントリを記述する場合、「noauto」(または「nofail」)マウントオプションを指定します。rbdmap.serviceは一般的にブートシーケンスのかなり遅い段階でトリガされるため、このオプションを指定することによって、Initシステムが、対象デバイスがまだ存在しない早すぎるタイミングでデバイスをマウントしないようにします。
rbdオプションの完全なリストについては、rbdのマニュアルページ(man
8 rbd)を参照してください。
rbdmapの使用法の例については、rbdmapのマニュアルページ(man
8 rbdmap)を参照してください。
20.2.5 RBDデバイスのサイズを増やす #
RBDデバイスのサイズが十分ではなくなった場合、簡単にサイズを増やすことができます。
RBDイメージのサイズを、たとえば10GBに増やします。
cephuser@adm >rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.デバイスの新しいサイズ全体を使用するようファイルシステムを拡張します。
root #xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
20.3 スナップショット #
RBDのスナップショットは、RADOS Block
Deviceイメージのスナップショットです。スナップショットにより、イメージの状態の履歴を保持します。Cephはスナップショットの階層化もサポートしており、VMイメージのクローンを素早く簡単に作成できます。rbdコマンド、およびさまざまな高レベルのインタフェース(QEMU、libvirt、OpenStack、CloudStackなど)を使用したBlock
Deviceのスナップショットをサポートしています。
イメージのスナップショットを作成する前に、入出力操作を停止し、保留中の書き込みをすべてフラッシュする必要があります。イメージにファイルシステムが含まれる場合、スナップショットの作成時に、そのファイルシステムが整合性のある状態である必要があります。
20.3.1 cephxの有効化と設定 #
cephxが有効な場合、ユーザ名またはIDと、そのユーザに対応する鍵が含まれるキーリングのパスを指定する必要があります。詳しくは「第30章 「cephxを使用した認証」」を参照してください。以降のパラメータを再入力せずに済むよう、CEPH_ARGS環境変数を追加することもできます。
cephuser@adm >rbd --id user-ID --keyring=/path/to/secret commandscephuser@adm >rbd --name username --keyring=/path/to/secret commands
例:
cephuser@adm >rbd --id admin --keyring=/etc/ceph/ceph.keyring commandscephuser@adm >rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands
CEPH_ARGS環境変数にユーザと秘密を追加して、毎回入力しなくて済むようにします。
20.3.2 スナップショットの基本 #
次の手順では、コマンドラインでrbdを使用して、スナップショットを作成、一覧、および削除する方法を説明します。
20.3.2.1 スナップショットの作成 #
rbdを使用してスナップショットを作成するには、snap
createオプション、プール名、およびイメージ名を指定します。
cephuser@adm >rbd --pool pool-name snap create --snap snap-name image-namecephuser@adm >rbd snap create pool-name/image-name@snap-name
例:
cephuser@adm >rbd --pool rbd snap create --snap snapshot1 image1cephuser@adm >rbd snap create rbd/image1@snapshot1
20.3.2.2 スナップショットの一覧 #
イメージのスナップショットを一覧にするには、プール名とイメージ名を指定します。
cephuser@adm >rbd --pool pool-name snap ls image-namecephuser@adm >rbd snap ls pool-name/image-name
例:
cephuser@adm >rbd --pool rbd snap ls image1cephuser@adm >rbd snap ls rbd/image1
20.3.2.3 スナップショットのロールバック #
rbdを使用して特定のスナップショットにロールバックするには、snap
rollbackオプション、プール名、イメージ名、およびスナップショット名を指定します。
cephuser@adm >rbd --pool pool-name snap rollback --snap snap-name image-namecephuser@adm >rbd snap rollback pool-name/image-name@snap-name
例:
cephuser@adm >rbd --pool pool1 snap rollback --snap snapshot1 image1cephuser@adm >rbd snap rollback pool1/image1@snapshot1
イメージをスナップショットにロールバックすることは、イメージの現在のバージョンをスナップショットのデータで上書きすることを意味します。ロールバックの実行にかかる時間は、イメージのサイズに応じて長くなります。イメージをスナップショットに「ロールバック」するよりもスナップショットから「クローンを作成する方が高速」であり、以前の状態に戻す場合はこの方法をお勧めします。
20.3.2.4 スナップショットの削除 #
rbdを使用してスナップショットを削除するには、snap
rmオプション、プール名、イメージ名、およびユーザ名を指定します。
cephuser@adm >rbd --pool pool-name snap rm --snap snap-name image-namecephuser@adm >rbd snap rm pool-name/image-name@snap-name
例:
cephuser@adm >rbd --pool pool1 snap rm --snap snapshot1 image1cephuser@adm >rbd snap rm pool1/image1@snapshot1
Ceph OSDはデータを非同期で削除するので、スナップショットを削除してもディスク領域はすぐには解放されません。
20.3.2.5 スナップショットの消去 #
rbdを使用してイメージのすべてのスナップショットを削除するには、snap
purgeオプションとイメージ名を指定します。
cephuser@adm >rbd --pool pool-name snap purge image-namecephuser@adm >rbd snap purge pool-name/image-name
例:
cephuser@adm >rbd --pool pool1 snap purge image1cephuser@adm >rbd snap purge pool1/image1
20.3.3 スナップショットの階層化 #
Cephでは、Block DeviceスナップショットのCOW (コピーオンライト)クローンを複数作成できます。スナップショットの階層化により、Ceph Block Deviceのクライアントはイメージを非常に素早く作成できます。たとえば、Linux VMが書き込まれたBlock Deviceイメージを作成してから、そのイメージのスナップショットを作成し、スナップショットを保護して、コピーオンライトクローンを必要な数だけ作成できます。スナップショットは読み込み専用なので、スナップショットのクローンを作成することでセマンティクスが簡素化され、クローンを素早く作成できます。
次のコマンドラインの例で使われている「親」および「子」という用語は、Ceph Block Deviceのスナップショット(親)と、そのスナップショットから作成された対応するクローンイメージ(子)を意味します。
クローンイメージ(子)にはその親イメージへの参照が保存されており、これによってクローンイメージから親のスナップショットを開いて読み込むことができます。
スナップショットのCOWクローンは、他のCeph Block Deviceイメージとまったく同じように動作します。クローンイメージに対して読み書きを行ったり、クローンを作成したり、サイズを変更したりできます。クローンイメージに特別な制約はありません。ただし、スナップショットのコピーオンライトクローンはスナップショットを参照するので、クローンを作成する前に「必ず」スナップショットを保護する必要があります。
--image-format 1はサポートされない
非推奨のrbd create --image-format
1オプションを使用して作成されたイメージのスナップショットを作成することはできません。Cephでサポートされているのは、デフォルトの「format
2」のイメージのクローン作成のみです。
20.3.3.1 階層化の基本事項 #
Ceph Block Deviceの階層化は簡単なプロセスです。まずイメージを用意する必要があります。続いて、イメージのスナップショットを作成し、スナップショットを保護する必要があります。これらの手順を実行した後、スナップショットのクローンの作成を開始できます。
クローンイメージは親スナップショットへの参照を持ち、プールID、イメージID、およびスナップショットIDを含みます。プールIDが含まれることは、あるプールから別のプール内のイメージへスナップショットのクローンを作成できることを意味します。
「イメージテンプレート」: Block Deviceの階層化の一般的な使用事例は、マスタイメージと、クローンのテンプレートとして機能するスナップショットを作成することです。たとえば、Linux配布パッケージ(たとえば、SUSE Linux Enterprise Server)のイメージを作成して、そのスナップショットを作成できます。定期的にイメージを更新して新しいスナップショットを作成できます(たとえば、
zypper ref && zypper patchの後にrbd snap createを実行します)。イメージが完成したら、いずれかのスナップショットのクローンを作成できます。「拡張テンプレート」: より高度な使用事例として、ベースイメージより多くの情報を提供するテンプレートイメージを拡張することがあります。たとえば、イメージ(VMテンプレート)のクローンを作成して、他のソフトウェア(たとえば、データベース、コンテンツ管理システム、分析システム)をインストールしてから、拡張イメージのスナップショットを作成でき、このスナップショットそのものをベースイメージと同じ方法で更新できます。
「テンプレートプール」: Block Deviceの階層化を使用する方法の1つが、テンプレートとして機能するマスタイメージと、それらのテンプレートの各スナップショットが含まれるプールを作成することです。その後、読み込み専用特権をユーザに拡張し、プール内での書き込みまたは実行の能力を持たなくても、スナップショットのクローンを作成できるようにします。
「イメージのマイグレーション/回復」: Block Deviceの階層化を使用する方法の1つが、あるプールから別のプールへデータを移行または回復することです。
20.3.3.2 スナップショットの保護 #
クローンは親スナップショットにアクセスします。ユーザが誤って親スナップショットを削除すると、すべてのクローンが壊れます。データの損失を防ぐため、クローンを作成する前に、スナップショットを保護する必要があります。
cephuser@adm >rbd --pool pool-name snap protect \ --image image-name --snap snapshot-namecephuser@adm >rbd snap protect pool-name/image-name@snapshot-name
例:
cephuser@adm >rbd --pool pool1 snap protect --image image1 --snap snapshot1cephuser@adm >rbd snap protect pool1/image1@snapshot1
保護されたスナップショットは削除できません。
20.3.3.3 スナップショットのクローンの作成 #
スナップショットのクローンを作成するには、親プール、イメージ、スナップショット、子プール、およびイメージ名を指定する必要があります。クローンを作成する前に、スナップショットを保護する必要があります。
cephuser@adm >rbd clone --pool pool-name --image parent-image \ --snap snap-name --dest-pool pool-name \ --dest child-imagecephuser@adm >rbd clone pool-name/parent-image@snap-name \ pool-name/child-image-name
例:
cephuser@adm > rbd clone pool1/image1@snapshot1 pool1/image2あるプールから別のプール内のイメージへスナップショットのクローンを作成できます。たとえば、一方のプール内に読み込み専用のイメージとスナップショットをテンプレートとして維持しておき、別のプール内に書き込み可能クローンを維持できます。
20.3.3.4 スナップショットの保護の解除 #
スナップショットを削除するには、まず保護を解除する必要があります。また、クローンから参照されているスナップショットは削除「できません」。スナップショットを削除する前に、スナップショットの各クローンをフラット化する必要があります。
cephuser@adm >rbd --pool pool-name snap unprotect --image image-name \ --snap snapshot-namecephuser@adm >rbd snap unprotect pool-name/image-name@snapshot-name
例:
cephuser@adm >rbd --pool pool1 snap unprotect --image image1 --snap snapshot1cephuser@adm >rbd snap unprotect pool1/image1@snapshot1
20.3.3.5 スナップショットの子の一覧 #
スナップショットの子を一覧にするには、次のコマンドを実行します。
cephuser@adm >rbd --pool pool-name children --image image-name --snap snap-namecephuser@adm >rbd children pool-name/image-name@snapshot-name
例:
cephuser@adm >rbd --pool pool1 children --image image1 --snap snapshot1cephuser@adm >rbd children pool1/image1@snapshot1
20.3.3.6 クローンイメージのフラット化 #
クローンイメージは親スナップショットへの参照を保持しています。子クローンから親スナップショットへの参照を削除する場合、スナップショットからクローンへ情報をコピーすることによって効果的にイメージを「フラット化」します。クローンのフラット化にかかる時間は、スナップショットのサイズに応じて長くなります。スナップショットを削除するには、まず子イメージをフラット化する必要があります。
cephuser@adm >rbd --pool pool-name flatten --image image-namecephuser@adm >rbd flatten pool-name/image-name
例:
cephuser@adm >rbd --pool pool1 flatten --image image1cephuser@adm >rbd flatten pool1/image1
フラット化されたイメージにはスナップショットからの情報がすべて含まれるため、階層化されたクローンよりも多くのストレージ領域を使用します。
20.4 RBDイメージのミラーリング #
RBDイメージを2つのCephクラスタ間で非同期でミラーリングできます。この機能には2つのモードがあります。
- ジャーナルベース
このモードは、RBDイメージのジャーナリング機能を使用して、クラスタ間でクラッシュコンシステントなレプリケーションを保証します。RBDイメージに対する書き込みが発生すると、まず関連するジャーナルに記録されてから、イメージが実際に変更されます。
remoteクラスタはジャーナルを読み込み、イメージのローカルコピーに更新内容を再現します。RBDイメージのジャーナリング機能を使用すると、RBDイメージに1回書き込むたびに2回の書き込みが発生するため、書き込みに伴う遅延が約2倍となることが見込まれます。- スナップショットベース
このモードは、RBDイメージのミラースナップショットを使用して、クラッシュコンシステントなRBDイメージをクラスタ間で複製します。このミラースナップショットはスケジュールに沿って定期的に作成するか、手動で作成します。
remoteクラスタは2つのミラースナップショットの間でなんらかのデータかメタデータが更新されているかを判定し、イメージのローカルコピーに差分をコピーします。RBDのfast-diffイメージ機能のおかげで、更新されたデータブロックは素早く計算できます。RBDイメージ全体をスキャンする必要はありません。このモードには時間的な整合性がないため、フェールオーバーシナリオの際に利用するには事前にスナップショットの差分全体を同期する必要があります。部分的に適用されたスナップショット差分については、使用する前に最新の完全に同期されたスナップショットまでロールバックします。
ミラーリングは、ピアクラスタ内のプールごとに設定します。ジャーナルベースのミラーリングだけを使用している場合、プール内の特定のイメージサブセットに設定することも、プール内のすべてのイメージを自動的にミラーリングするように設定することもできます。ミラーリングはrbdコマンドを使用して設定します。rbd-mirrorデーモンは、remoteのピアクラスタからイメージの更新を取得して、localクラスタ内のイメージに適用する処理を受け持ちます。
レプリケーションに対する要望に応じて、RBDミラーリングは単方向レプリケーション用または双方向レプリケーション用に設定できます。
- 単方向レプリケーション
データがプライマリクラスタからセカンダリクラスタにミラーリングされるだけであれば、
rbd-mirrorデーモンはセカンダリクラスタ上でのみ実行されます。- 双方向レプリケーション
データが、あるクラスタのプライマリイメージから別のクラスタの非プライマリイメージにミラーリングされる場合(逆も同様)、
rbd-mirrorデーモンは両方のクラスタで実行されます。
rbd-mirrorデーモンの各インスタンスは、local
Cephクラスタとremote
Cephクラスタへ同時に接続できる必要があります。たとえば、すべてのMonitorホストとOSDホストに接続できる必要があります。さらに、ミラーリングのワークロードを扱うため、ネットワークの2つのデータセンター間には十分な帯域幅が必要です。
20.4.1 プールの設定 #
次の手順では、rbdコマンドを使用してミラーリングを設定するための基本的な管理タスクを実行する方法を説明します。ミラーリングは、Cephクラスタ内のプールごとに設定します。
これらのプール設定手順は、両方のピアクラスタで実行する必要があります。これらの手順では、わかりやすくするため、localおよびremoteという名前の2つのクラスタが1つのホストからアクセス可能であることを想定しています。
異なるCephクラスタに接続する方法の詳細については、rbdのマニュアルページ(man 8
rbd)を参照してください。
以下の例におけるクラスタ名は、同名のCeph設定ファイルである/etc/ceph/remote.confと、同名のCephキーリングファイルである/etc/ceph/remote.client.admin.keyringに対応しています。
20.4.1.1 プールのミラーリングの有効化 #
プールのミラーリングを有効にするには、mirror pool
enableサブコマンド、プール名、およびミラーリングモードを指定します。ミラーリングモードはpoolまたはimageにすることができます。
- pool
ジャーナリング機能が有効な、プール内のすべてのイメージをミラーリングします。
- image
各イメージに対して明示的にミラーリングを有効にする必要があります。詳細については、20.4.2.1項 「イメージミラーリングの有効化」を参照してください。
例:
cephuser@adm >rbd --cluster local mirror pool enable POOL_NAME poolcephuser@adm >rbd --cluster remote mirror pool enable POOL_NAME pool
20.4.1.2 ミラーリングの無効化 #
プールのミラーリングを無効にするには、mirror pool
disableサブコマンドとプール名を指定します。この方法でプールのミラーリングを無効にした場合、ミラーリングを明示的に有効にしたイメージ(プール内)のミラーリングも無効になります。
cephuser@adm >rbd --cluster local mirror pool disable POOL_NAMEcephuser@adm >rbd --cluster remote mirror pool disable POOL_NAME
20.4.1.3 ピアのブートストラップ処理 #
rbd-mirrorデーモンがピアクラスタを検出するためには、ピアをプールに登録し、ユーザアカウントを作成する必要があります。このプロセスはrbdとともにmirror
pool peer bootstrap createとmirror pool peer bootstrap
importのコマンドを使用することで自動化できます。
rbdを使用して新しいブートストラップトークンを手動で作成するには、mirror pool
peer bootstrap
createコマンドとプール名に加えて、localクラスタを記述するためにオプションのフレンドリサイト名を指定します。
cephuser@local > rbd mirror pool peer bootstrap create \
[--site-name LOCAL_SITE_NAME] POOL_NAME
mirror pool peer bootstrap
createコマンドの出力はトークンです。このトークンをmirror pool peer bootstrap
importコマンドに提供する必要があります。たとえば、localクラスタで次のコマンドを実行します。
cephuser@local > rbd --cluster local mirror pool peer bootstrap create --site-name local image-pool
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5I \
joiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
rbdコマンドにより他のクラスタが作成したブートストラップトークンを手動でインポートするには、次の構文を使用します。
rbd mirror pool peer bootstrap import \ [--site-name LOCAL_SITE_NAME] \ [--direction DIRECTION \ POOL_NAME TOKEN_PATH
ここで、
- LOCAL_SITE_NAME
localクラスタを記述するための、オプションのフレンドリサイト名。- DIRECTION
ミラーリング方向。デフォルトは双方向ミラーリングを表す
rx-txに設定されていますが、単方向ミラーリングを表すrx-onlyに設定することもできます。- POOL_NAME
プールの名前。
- TOKEN_PATH
作成されたトークンへのファイルパス(標準入力から読み込む場合は、
-)。
たとえば、remoteクラスタで次のコマンドを実行します。
cephuser@remote > cat <<EOF > token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0IjoiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOFcephuser@adm > rbd --cluster remote mirror pool peer bootstrap import \
--site-name remote image-pool token20.4.1.4 クラスタピアの手動追加 #
20.4.1.3項 「ピアのブートストラップ処理」に記載したピアのブートストラップ方法の代わりに、手動でピアを指定することもできます。ミラーリングを実行するには、リモートのrbd-mirrorデーモンがローカルクラスタにアクセスする必要があります。リモートのrbd-mirrorデーモンが使用する新しいローカルCephユーザを作成します。次の例ではrbd-mirror-peerです。
cephuser@adm > ceph auth get-or-create client.rbd-mirror-peer \
mon 'profile rbd' osd 'profile rbd'
rbdコマンドにより、ミラーリングピアのCephクラスタを追加するには、次の構文を使用します。
rbd mirror pool peer add POOL_NAME CLIENT_NAME@CLUSTER_NAME
例:
cephuser@adm >rbd --cluster site-a mirror pool peer add image-pool client.rbd-mirror-peer@site-bcephuser@adm >rbd --cluster site-b mirror pool peer add image-pool client.rbd-mirror-peer@site-a
デフォルトでは、rbd-mirrorデーモンが、/etc/ceph/.CLUSTER_NAME.confに置かれたCeph設定ファイルにアクセスできる必要があります。この設定ファイルにはピアクラスタのMONのIPアドレスと、デフォルトまたはカスタムのキーリング検索パスに配置されたCLIENT_NAMEという名前のクライアント用キーリングが含まれます。キーリング検索パスの例は、/etc/ceph/CLUSTER_NAME.CLIENT_NAME.keyringなどです。
もしくは、ピアクラスタのMONとクライアントキーの両方または一方を、ローカルのCeph設定キーストアに安全に保存することもできます。ミラーリングピアを追加する際にピアクラスタの接続属性を指定するには、--remote-mon-hostオプションと--remote-key-fileオプションを使用します。例:
cephuser@adm >rbd --cluster site-a mirror pool peer add image-pool \ client.rbd-mirror-peer@site-b --remote-mon-host 192.168.1.1,192.168.1.2 \ --remote-key-file /PATH/TO/KEY_FILEcephuser@adm >rbd --cluster site-a mirror pool info image-pool --all Mode: pool Peers: UUID NAME CLIENT MON_HOST KEY 587b08db... site-b client.rbd-mirror-peer 192.168.1.1,192.168.1.2 AQAeuZdb...
20.4.1.5 クラスタピアの削除 #
ミラーリングピアクラスタを削除するには、mirror pool peer
removeサブコマンド、プール名、およびピアのUUID (rbd mirror pool
infoコマンドで参照可能)を指定します。
cephuser@adm >rbd --cluster local mirror pool peer remove POOL_NAME \ 55672766-c02b-4729-8567-f13a66893445cephuser@adm >rbd --cluster remote mirror pool peer remove POOL_NAME \ 60c0e299-b38f-4234-91f6-eed0a367be08
20.4.1.6 データプール #
宛先クラスタにイメージを作成する場合、rbd-mirrorは次のようにデータプールを選択します。
宛先クラスタにデフォルトのデータプールが設定されている場合は、そのプールを使用します(設定には、
rbd_default_data_pool設定オプションを使用します)。デフォルトのデータプールが設定されていない場合、ソースイメージが別のデータプールを使用しており、宛先クラスタに同じ名前のプールが存在するなら、そのプールを使用します。
これら2つの条件が満たされない場合、データプールは設定されません。
20.4.2 RBDイメージの設定 #
プール設定と異なり、イメージ設定はミラーリングピアの1つのCephクラスタのみで実行する必要があります。
ミラーリングされたRBDイメージは、「プライマリ」または「非プライマリ」のいずれかとして指定されます。これはイメージのプロパティであり、プールのプロパティではありません。非プライマリとして指定されたイメージは変更できません。
イメージに対して初めてミラーリングを有効にすると、イメージは自動的にプライマリに昇格します(プールのミラーモードが「pool」で、イメージのジャーナリング機能が有効な場合、ミラーリングは暗黙的に有効になります。または、rbdコマンドによって明示的に有効にします(20.4.2.1項 「イメージミラーリングの有効化」を参照してください)。
20.4.2.1 イメージミラーリングの有効化 #
ミラーリングがimageモードで設定されている場合、プール内の各イメージに対して明示的にミラーリングを有効にする必要があります。rbdコマンドを使用して特定のイメージのミラーリングを有効にするには、mirror
image enableサブコマンドと共にプール名とイメージ名を指定します。
cephuser@adm > rbd --cluster local mirror image enable \
POOL_NAME/IMAGE_NAME
イメージのミラーリングモードは、journalまたはsnapshotのどちらかを使用できます。
- journal(デフォルト)
journalモードに設定した場合、ミラーリング処理にRBDイメージのジャーナリング機能を使用して、イメージ内容の複製を行います。イメージに対するRBDイメージのジャーナリング機能が有効化されていなかった場合、自動的に有効化されます。- スナップショット
snapshotモードに設定した場合、ミラーリング処理にRBDイメージのミラースナップショット機能を使用して、イメージ内容の複製を行います。有効化した場合、最初のミラースナップショットが自動的に作成されます。RBDイメージのミラースナップショットをrbdコマンドにより追加で作成することもできます。
例:
cephuser@adm >rbd --cluster local mirror image enable image-pool/image-1 snapshotcephuser@adm >rbd --cluster local mirror image enable image-pool/image-2 journal
20.4.2.2 イメージジャーナリング機能の有効化 #
RBDのミラーリングは、RBDのジャーナリング機能を使用して、複製イメージが常にクラッシュコンシステントな状態を保つようにします。imageミラーリングモードを使用する場合、イメージのミラーリングを有効にするとジャーナリング機能が自動的に有効になります。poolミラーリングモードを使用する場合、イメージをピアクラスタにミラーリングするには、RBDイメージジャーナリング機能を有効にする必要があります。この機能は、イメージの作成時にrbdコマンドで--image-feature
exclusive-lock,journalingオプションを指定することによって有効にできます。
または、既存のRBDイメージに対して動的にジャーナリング機能を有効にすることもできます。ジャーナリングを有効にするには、feature
enableサブコマンド、プール名、イメージ名、および機能名を指定します。
cephuser@adm >rbd --cluster local feature enable POOL_NAME/IMAGE_NAME exclusive-lockcephuser@adm >rbd --cluster local feature enable POOL_NAME/IMAGE_NAME journaling
journaling機能はexclusive-lock機能に依存します。exclusive-lock機能がまだ有効になっていない場合は、有効にしてからjournaling機能を有効にする必要があります。
デフォルトですべての新規イメージのジャーナリングを有効にできます。Ceph設定ファイルにrbd default features
=
layering,exclusive-lock,object-map,deep-flatten,journalingを追加してください。
20.4.2.3 イメージのミラースナップショットの作成 #
スナップショットベースのミラーリングを使用する場合、RBDイメージの変更内容のミラーリングが必要になるたびに、ミラースナップショットを作成する必要があります。rbdコマンドを使用してミラースナップショットを手動で作成するには、mirror
image snapshotコマンドと共に、プール名とイメージ名を指定します。
cephuser@adm > rbd mirror image snapshot POOL_NAME/IMAGE_NAME例:
cephuser@adm > rbd --cluster local mirror image snapshot image-pool/image-1
デフォルトでイメージごとに作成されるミラースナップショットは3つだけです。上限に達した場合は、最新のミラースナップショットが自動的に削除されます。rbd_mirroring_max_mirroring_snapshots設定オプションにより、必要に応じて上限を上書きできます。また、イメージが削除された場合やミラーリングが無効化された場合には、ミラースナップショットが自動的に削除されます。
ミラースナップショットのスケジュールを定義することで、定期的にミラースナップショットを自動作成することも可能です。ミラースナップショットのスケジュールは、グローバル、プールごと、イメージごとのレベルで設定できます。どのレベルにも複数のミラースナップショットのスケジュールを設定できます。ただし、個別のミラーイメージに適用される最も詳細なスナップショットスケジュールだけが実行されます。
rbdコマンドを使用してミラースナップショットスケジュールを作成するには、mirror
snapshot schedule
addコマンドと、プール名またはイメージ名(オプション)、スナップショット間隔、開始時間(オプション)を指定します。
スナップショット間隔はサフィックスd、h、mを使用することでそれぞれ日、時、分の単位で指定できます。必要に応じて、開始時間をISO
8601日時フォーマットにより指定できます。次に例を示します。
cephuser@adm >rbd --cluster local mirror snapshot schedule add --pool image-pool 24h 14:00:00-05:00cephuser@adm >rbd --cluster local mirror snapshot schedule add --pool image-pool --image image1 6h
rbdコマンドを使用してミラースナップショットスケジュールを削除するには、mirror
snapshot schedule removeコマンドと、対応するスケジュールの追加コマンドに一致するオプションを指定します。
rbdコマンドを使用して特定のレベル(グローバル、プール、イメージ)のすべてのスナップショットスケジュールを一覧にするには、mirror
snapshot schedule
lsコマンドと、必要に応じてプール名またはイメージ名を指定します。また、--recursiveオプションを指定すると、指定したレベル以下のすべてのスケジュールを一覧にできます。次に例を示します。
cephuser@adm > rbd --cluster local mirror schedule ls --pool image-pool --recursive
POOL NAMESPACE IMAGE SCHEDULE
image-pool - - every 1d starting at 14:00:00-05:00
image-pool image1 every 6h
rbdコマンドを使用して、スナップショットベースのミラーリングRBDイメージが次はいつ作成されるかを確認するには、mirror
snapshot schedule statusコマンドとプール名またはイメージ名(オプション)を指定します。次に例を示します。
cephuser@adm > rbd --cluster local mirror schedule status
SCHEDULE TIME IMAGE
2020-02-26 18:00:00 image-pool/image120.4.2.4 イメージミラーリングの無効化 #
特定のイメージのミラーリングを無効にするには、mirror image
disableサブコマンドと共にプール名とイメージ名を指定します。
cephuser@adm > rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME20.4.2.5 イメージの昇格と降格 #
プライマリ指定をピアクラスタ内のイメージに移動する必要があるフェールオーバーシナリオの場合、プライマリイメージへのアクセスを停止し、現在のプライマリイメージを降格してから、新しいプライマリイメージを昇格し、代替クラスタ上のイメージへのアクセスを再開する必要があります。
--forceオプションを使用して昇格を強制できます。強制昇格は、降格をピアクラスタに伝搬できない場合(たとえば、クラスタ障害や通信停止が発生した場合)に必要です。この結果、2つのピア間でスプリットブレインシナリオが発生し、resyncサブコマンドを発行するまでイメージは同期されなくなります。
特定のイメージを非プライマリに降格するには、mirror image
demoteサブコマンドと共にプール名とイメージ名を指定します。
cephuser@adm > rbd --cluster local mirror image demote POOL_NAME/IMAGE_NAME
プール内のすべてのプライマリイメージを非プライマリに降格するには、mirror pool
demoteサブコマンドと共にプール名を指定します。
cephuser@adm > rbd --cluster local mirror pool demote POOL_NAME
特定のイメージをプライマリに昇格するには、mirror image
promoteサブコマンドと共にプール名とイメージ名を指定します。
cephuser@adm > rbd --cluster remote mirror image promote POOL_NAME/IMAGE_NAME
プール内のすべての非プライマリイメージをプライマリに昇格するには、mirror pool
promoteサブコマンドと共にプール名を指定します。
cephuser@adm > rbd --cluster local mirror pool promote POOL_NAMEプライマリまたは非プライマリの状態はイメージごとなので、2つのクラスタでI/O負荷を分割したり、フェールオーバーまたはフェールバックを実行したりできます。
20.4.2.6 イメージの再同期の強制 #
rbd-mirrorデーモンがスプリットブレインイベントを検出した場合、このデーモンは、イベントが修正されるまで、影響を受けるイメージのミラーリングを試行しません。イメージのミラーリングを再開するには、まず、古いと判定されたイメージを降格してから、プライマリイメージへの再同期を要求します。イメージの再同期を要求するには、mirror
image resyncサブコマンドと共にプール名とイメージ名を指定します。
cephuser@adm > rbd mirror image resync POOL_NAME/IMAGE_NAME20.4.3 ミラーリング状態の確認 #
ピアクラスタのレプリケーションの状態は、ミラーリングされたすべてのプライマリイメージについて保存されます。この状態は、mirror
image statusおよびmirror pool
statusの各サブコマンドを使用して取得できます。
ミラーイメージの状態を要求するには、mirror image
statusサブコマンドと共にプール名とイメージ名を指定します。
cephuser@adm > rbd mirror image status POOL_NAME/IMAGE_NAME
ミラープールのサマリ状態を要求するには、mirror pool
statusサブコマンドと共にプール名を指定します。
cephuser@adm > rbd mirror pool status POOL_NAME
mirror pool
statusサブコマンドに--verboseオプションを追加すると、プール内にあるすべてのミラーリングイメージについて状態の詳細も出力されます。
20.5 キャッシュの設定 #
Ceph Block Device
(librbd)のユーザスペースの実装では、Linuxページキャッシュを利用できません。したがって、Ceph
Block
Deviceには独自のインメモリキャッシングが含まれます。RBDのキャッシュはハードディスクキャッシュと同様に動作します。OSがバリア要求またはフラッシュ要求を送信すると、すべての「ダーティ」データがOSDに書き込まれます。つまり、ライトバックキャッシュを使用することは、フラッシュを適切に送信するVMで正常に動作する物理ハードディスクを使用することと同様に安全です。キャッシュはLRU
(「Least Rec ntly
Used」)アルゴリズムを使用しており、ライトバックモードでは、隣接する要求をマージしてスループットを向上させることができます。
Cephは、RBDのライトバックキャッシュをサポートしています。RBDのライトバックキャッシュを有効にするには、次のコマンドを実行します。
cephuser@adm > ceph config set client rbd_cache true
デフォルトでは、librbdはキャッシュを実行しません。書き込みと読み込みはストレージクラスタに直接送信され、書き込みはデータがすべてのレプリカのディスク上にある場合にのみ返されます。キャッシュを有効にすると、rbd
cache max
dirtyオプションで設定されている値より多くの未フラッシュバイトがある場合を除いて、書き込みはすぐに返されます。このような場合、書き込みはライトバックをトリガし、十分なバイトがフラッシュされるまでブロックされます。
CephはRBDのライトスルーキャッシュをサポートします。キャッシュのサイズを設定したり、ターゲットと制限を設定して、ライトバックキャッシュからライトスルーキャッシュに切り替えたりすることができます。ライトスルーモードを有効にするには、次のコマンドを実行します。
cephuser@adm > ceph config set client rbd_cache_max_dirty 0つまり、書き込みはデータがすべてのレプリカのディスク上にある場合にのみ返されますが、読み込みはキャッシュから行われる場合があります。キャッシュはクライアントのメモリ内にあり、各RBDイメージは専用のキャッシュを持ちます。キャッシュはクライアントに対してローカルであるため、イメージにアクセスする他のユーザがいる場合、整合性はありません。キャッシュが有効な場合、RBDに加えてGFSまたはOCFSを実行することはできません。
以下のパラメータがRADOS Block
Deviceの動作に影響します。これらのパラメータを設定するには、clientカテゴリを使用します。
cephuser@adm > ceph config set client PARAMETER VALUErbd cacheRBD (RADOS Block Device)のキャッシュを有効にします。デフォルトは「true」です。
rbd cache sizeRBDキャッシュのサイズ(バイト単位)。デフォルトは32MBです。
rbd cache max dirtyキャッシュがライトバックをトリガする「ダーティ」の制限(バイト単位)。
rbd cache max dirtyは、rbd cache sizeより小さくする必要があります。0に設定すると、ライトスルーキャッシュを使用します。デフォルトは24MBです。rbd cache target dirtyキャッシュがデータをデータストレージに書き込み始めるまでの「ダーティターゲット」。キャッシュへの書き込みはブロックしません。デフォルトは16MBです。
rbd cache max dirty ageライトバックの開始前にダーティデータがキャッシュ内に存在する秒数。デフォルトは1です。
rbd cache writethrough until flushライトスルーモードで開始し、最初のフラッシュ要求を受信したらライトバックに切り替えます。
rbdで実行されている仮想マシンが古すぎてフラッシュを送信できない場合(たとえば、カーネル2.6.32より前のLinuxのvirtioドライバ)は、この設定を有効にするのは消極的ですが安全です。デフォルトは「true」です。
20.6 QoS設定 #
一般的に、QoS (サービスの品質)とは、トラフィックの優先順位付けとリソース予約の方法のことを指します。これは特に、特別な要件を持つトラフィックを転送するために重要です。
次のQoS設定は、ユーザスペースのRBD実装であるlibrbdによってのみ使用され、kRBD実装では使用されません。iSCSIはkRBDを使用するため、QoS設定を使用しません。ただし、iSCSIでは、標準のカーネル機能を使用して、カーネルブロックデバイス層でQoSを設定できます。
rbd qos iops limit希望する秒あたりI/O操作数の上限。デフォルトは0 (制限なし)です。
rbd qos bps limit希望する秒あたりI/Oバイト数の上限。デフォルトは0 (制限なし)です。
rbd qos read iops limit希望する秒あたり読み取り操作数の上限。デフォルトは0 (制限なし)です。
rbd qos write iops limit希望する秒あたり書き込み操作数の上限。デフォルトは0 (制限なし)です。
rbd qos read bps limit希望する秒あたり読み取りバイト数の上限。デフォルトは0 (制限なし)です。
rbd qos write bps limit希望する秒あたり書き込みバイト数の上限。デフォルトは0 (制限なし)です。
rbd qos iops burst希望するI/O操作数のバースト上限。デフォルトは0 (制限なし)です。
rbd qos bps burst希望するI/Oバイト数のバースト上限。デフォルトは0 (制限なし)です。
rbd qos read iops burst希望する読み取り操作数のバースト上限。デフォルトは0 (制限なし)です。
rbd qos write iops burst希望する書き込み操作数のバースト上限。デフォルトは0 (制限なし)です。
rbd qos read bps burst希望する読み取りバイト数のバースト上限。デフォルトは0 (制限なし)です。
rbd qos write bps burst希望する書き込みバイト数のバースト上限。デフォルトは0 (制限なし)です。
rbd qos schedule tick minQoSの最小スケジュールチック(ミリ秒)。デフォルトは50です。
20.7 先読み設定 #
RADOS Block Deviceは、先読み/プリフェッチをサポートしており、小容量の順次読み込みが最適化されます。これは、仮想マシンの場合は通常はゲストOSによって処理されますが、ブートローダは効率的な読み込みを発行できません。キャッシュが無効な場合、先読みは自動的に無効になります。
次の先読み設定は、ユーザスペースのRBD実装であるlibrbdによってのみ使用され、kRBD実装では使用されません。iSCSIはkRBDを使用するため、先読み設定を使用しません。ただし、iSCSIでは、標準のカーネル機能を使用して、カーネルブロックデバイス層で先読みを設定できます。
rbd readahead trigger requests先読みをトリガするために必要な順次読み込み要求の数。デフォルトは10です。
rbd readahead max bytes先読み要求の最大サイズ。0に設定すると、先読みは無効になります。デフォルトは512KBです。
rbd readahead disable after bytesこの量のバイトRBDイメージから読み込みを行った後は、そのイメージが閉じられるまで先読みは無効になります。これにより、ゲストOSは起動時に先読みを引き継ぐことができます。0に設定すると、先読みは有効なままです。デフォルトは50MBです。
20.8 拡張機能 #
RADOS Block
Deviceは、RBDイメージの機能を拡張する拡張機能をサポートしています。RBDイメージの作成時にコマンドラインで機能を指定することも、rbd_default_featuresオプションを使用してCeph設定ファイルで機能を指定することもできます。
rbd_default_featuresオプションの値は、次の2つの方法で指定できます。
機能の内部値の合計として指定する。各機能には独自の内部値があります。たとえば、「layering」は1で、「fast-diff」は16です。したがって、これらの2つの機能をデフォルトで有効にするには、以下を含めます。
rbd_default_features = 17
機能のカンマ区切りリストとして指定する。この場合、前の例は次のようになります。
rbd_default_features = layering,fast-diff
deep-flatten、object-map、journaling、fast-diff、およびstripingの機能を使用するRBDイメージは、iSCSIではサポートされません。
次に、RBDの拡張機能のリストを示します。
layering階層化により、クローン作成を使用できます。
内部値は1で、デフォルトは「yes」です。
stripingストライピングは、複数のオブジェクトにデータを分散し、順次読み込み/書き込みワークロードの並列処理に役立ちます。これにより、大容量またはビジー状態のRADOS Block Deviceにおいて単一ノードのボトルネックを防ぎます。
内部値は2で、デフォルトは「yes」す。
exclusive-lock有効にすると、クライアントは書き込みを行う前にオブジェクトのロックを取得する必要があります。単一のクライアントが同時に1つのイメージにアクセスしている場合にのみ、排他ロックを有効にします。内部値は4です。デフォルトは「yes」です。
object-mapオブジェクトマップのサポートは、排他ロックのサポートに依存します。ブロックデバイスはシンプロビジョニングされます。つまり、実際に存在するデータのみを保存します。オブジェクトマップのサポートは、どのオブジェクトが実際に存在するか(ドライブに保存されたデータを持つか)を追跡するのに役立ちます。オブジェクトマップのサポートを有効にすると、クローン作成、保存密度の低いイメージのインポートとエクスポート、および削除のI/O操作が高速化されます。
内部値は8で、デフォルトは「yes」です。
fast-diffFast-diffのサポートは、オブジェクトマップのサポートと排他ロックのサポートに依存します。これは、オブジェクトマップに別のプロパティを追加することで、イメージのスナップショットと、スナップショットの実際のデータ使用と間の差分を生成する速度が大幅に向上します。
内部値は16で、デフォルトは「yes」です。
deep-flattenディープフラット化は、
rbd flatten(20.3.3.6項 「クローンイメージのフラット化」を参照)を、イメージそのもの以外にイメージのすべてのスナップショットでも機能するようにします。ディープフラット化がなければ、イメージのスナップショットは引き続き親に依存するため、スナップショットが削除されるまで親イメージを削除することはできません。ディープフラット化は、スナップショットがある場合でも、親をそのクローンから独立させます。内部値は32で、デフォルトは「yes」です。
ジャーナリングジャーナリングのサポートは排他ロックに依存します。ジャーナリングは、イメージに対するすべての変更を発生順に記録します。RBDミラーリング(20.4項 「RBDイメージのミラーリング」を参照)では、ジャーナルを使用してクラッシュ整合イメージを
remoteクラスタに複製します。内部値は64で、デフォルトは「no」です。
20.9 古いカーネルクライアントを使用したRBDのマッピング #
SUSE Enterprise Storage 7を使用して展開したクラスタでは、古いクライアント(SLE11 SP4 など)でサポートされない複数の機能(RBDイメージレベルの機能とRADOSレベルの機能の両方)が強制的に適用されるため、これらの古いクライアントはRBDイメージをマップできない場合があります。これが発生した場合、OSDログに次のようなメッセージが表示されます。
2019-05-17 16:11:33.739133 7fcb83a2e700 0 -- 192.168.122.221:0/1006830 >> \ 192.168.122.152:6789/0 pipe(0x65d4e0 sd=3 :57323 s=1 pgs=0 cs=0 l=1 c=0x65d770).connect \ protocol feature mismatch, my 2fffffffffff < peer 4010ff8ffacffff missing 401000000000000
CRUSHマップのバケットタイプを「straw」と「straw2」の間で切り替える場合は、計画的に行ってください。バケットタイプを変更するとクラスタの大規模なリバランスが発生するため、クラスタノードに重大な影響があることを想定しておいてください。
サポートされていないRBDイメージ機能を無効にします。例:
cephuser@adm >rbd feature disable pool1/image1 object-mapcephuser@adm >rbd feature disable pool1/image1 exclusive-lockCRUSHマップのバケットタイプを「straw2」から「straw」に変更します。
CRUSHマップを保存します。
cephuser@adm >ceph osd getcrushmap -o crushmap.originalCRUSHマップを逆コンパイルします。
cephuser@adm >crushtool -d crushmap.original -o crushmap.txtCRUSHマップを編集して、「straw2」を「straw」に置き換えます。
CRUSHマップを再コンパイルします。
cephuser@adm >crushtool -c crushmap.txt -o crushmap.new新しいCRUSHマップを設定します。
cephuser@adm >ceph osd setcrushmap -i crushmap.new
20.10 Block DeviceとKubernetesの有効化 #
Ceph RBDとKubernetes
v1.13以上をceph-csiドライバにより併用できます。このドライバはRBDイメージを動的にプロビジョニングしてKubernetesボリュームを支援します。また、RBDに支援されたボリュームを参照するポッドを実行中のワーカーノードで、RBDイメージをBlock
Deviceとしてマッピングします。
Ceph Block
DeviceとKubernetesを併用するには、Kubernetes環境にceph-csiをインストールして設定する必要があります。
ceph-csiはデフォルトではRBDカーネルモジュールを使用します。しかし、このモジュールがCeph
CRUSHの調整可能パラメータや、RBDイメージ機能をすべてサポートしているとは限りません。
デフォルトでは、Ceph Block DeviceはRBDプールを使用します。Kubernetesボリュームストレージ用のプールを作成します。Cephクラスタが実行中であることを確認してから、プールを作成します。
cephuser@adm >ceph osd pool create kubernetesRBDツールを使用してプールを初期化します。
cephuser@adm >rbd pool init kubernetesKubernetesと
ceph-csi用の新しいユーザを作成します。次のコマンドを実行し、生成されたキーを記録します。cephuser@adm >ceph auth get-or-create client.kubernetes mon 'profile rbd' osd 'profile rbd pool=kubernetes' mgr 'profile rbd pool=kubernetes' [client.kubernetes] key = AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg==ceph-csiは、Cephクラスタ用のCeph Monitorアドレスを定義するために、Kubernetesに保存されたConfigMapオブジェクトを必要とします。Cephクラスタの固有fsidとMonitorアドレスの両方を収集します。cephuser@adm >ceph mon dump <...> fsid b9127830-b0cc-4e34-aa47-9d1a2e9949a8 <...> 0: [v2:192.168.1.1:3300/0,v1:192.168.1.1:6789/0] mon.a 1: [v2:192.168.1.2:3300/0,v1:192.168.1.2:6789/0] mon.b 2: [v2:192.168.1.3:3300/0,v1:192.168.1.3:6789/0] mon.c次の例に示すような
csi-config-map.yamlファイルを生成します。なお、clusterIDはFSIDで、monitorsはMonitorアドレスで置き換えてください。kubectl@adm >cat <<EOF > csi-config-map.yaml --- apiVersion: v1 kind: ConfigMap data: config.json: |- [ { "clusterID": "b9127830-b0cc-4e34-aa47-9d1a2e9949a8", "monitors": [ "192.168.1.1:6789", "192.168.1.2:6789", "192.168.1.3:6789" ] } ] metadata: name: ceph-csi-config EOF作成されたら、Kubernetesに新しいConfigMapオブジェクトを保存します。
kubectl@adm >kubectl apply -f csi-config-map.yamlceph-csiはCephクラスタとの通信にcephx資格情報を必要とします。新しく作成したKubernetesユーザIDとcephxキーを使用して、次の例に示すようなcsi-rbd-secret.yamlファイルを生成します。kubectl@adm >cat <<EOF > csi-rbd-secret.yaml --- apiVersion: v1 kind: Secret metadata: name: csi-rbd-secret namespace: default stringData: userID: kubernetes userKey: AQD9o0Fd6hQRChAAt7fMaSZXduT3NWEqylNpmg== EOF生成されたら、Kubernetesに新しいシークレットオブジェクトを保存します。
kubectl@adm >kubectl apply -f csi-rbd-secret.yaml必要となるServiceAccountとRBAC ClusterRole/ClusterRoleBindingのKubernetesオブジェクトを作成します。これらのオブジェクトを、お客様のKubernetes環境に合わせてカスタマイズする必要はありません。そのため、
ceph-csi展開用のYAMLファイルから、オブジェクトを直接利用できます。kubectl@adm >kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yamlkubectl@adm >kubectl apply -f https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yamlceph-csiプロビジョナとノードプラグインを作成します。kubectl@adm >wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yamlkubectl@adm >kubectl apply -f csi-rbdplugin-provisioner.yamlkubectl@adm >wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yamlkubectl@adm >kubectl apply -f csi-rbdplugin.yaml重要デフォルトでは、プロビジョナとノードプラグインのYAMLファイルは、
ceph-csiコンテナの開発版リリースを取得します。リリース版を使用するように、YAMLファイルをアップデートする必要があります。
20.10.1 Kubernetes環境におけるCeph Block Deviceの利用 #
Kubernetes StorageClassはストレージクラスを定義します。複数のStorageClassオブジェクトを作成して、多様なサービス品質レベルと機能をマッピングできます。例としては、NVMeをベースのプールとHDDベースのプールの併用などです。
作成済みのKubernetesプールをマッピングするceph-csi
StorageClassを作成するには、次のYAMLファイルを使用できます。ただし、作成前にclusterIDプロパティと使用するCephクラスタのFSIDが一致することを確認してください。
kubectl@adm >cat <<EOF > csi-rbd-sc.yaml --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-rbd-sc provisioner: rbd.csi.ceph.com parameters: clusterID: b9127830-b0cc-4e34-aa47-9d1a2e9949a8 pool: kubernetes csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret csi.storage.k8s.io/provisioner-secret-namespace: default csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret csi.storage.k8s.io/node-stage-secret-namespace: default reclaimPolicy: Delete mountOptions: - discard EOFkubectl@adm >kubectl apply -f csi-rbd-sc.yaml
PersistentVolumeClaimはユーザからの抽象化ストレージリソースに対する要求です。要求後、PersistentVolumeClaimはポッドのリソースに関連付けられ、PersistentVolumeをプロビジョニングします。これは、Cephブロックイメージに支援されます。必要に応じてvolumeModeを付加することで、マウント済みのファイルシステム(デフォルト)と、Block
DeviceベースのRAWボリュームを選択できます。
ceph-csiを使用する場合、volumeModeにFilesystemを指定すると、ReadWriteOnce
accessMode要求とReadOnlyMany
accessMode要求の両方をサポートできます。また、volumeModeにBlockを指定すると、ReadWriteOnce
accessMode要求、ReadWriteMany
accessMode要求、ReadOnlyMany
accessMode要求をサポートできます。
たとえば、前の手順で作成したceph-csi-based
StorageClassを使用する、ブロックベースのPersistentVolumeClaimを作成するには、次のYAMLファイルを使用できます。これにより、csi-rbd-sc
StorageClassからRAWブロックストレージを要求します。
kubectl@adm >cat <<EOF > raw-block-pvc.yaml --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: raw-block-pvc spec: accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 1Gi storageClassName: csi-rbd-sc EOFkubectl@adm >kubectl apply -f raw-block-pvc.yaml
次に示すのは、前に述べたPersistentVolumeClaimをRAW Block
Deviceとしてポッドのリソースにバインドする例です。
kubectl@adm >cat <<EOF > raw-block-pod.yaml --- apiVersion: v1 kind: Pod metadata: name: pod-with-raw-block-volume spec: containers: - name: fc-container image: fedora:26 command: ["/bin/sh", "-c"] args: ["tail -f /dev/null"] volumeDevices: - name: data devicePath: /dev/xvda volumes: - name: data persistentVolumeClaim: claimName: raw-block-pvc EOFkubectl@adm >kubectl apply -f raw-block-pod.yaml
前の手順で作成した ceph-csi-based
StorageClassを使用する、ファイルシステムベースのPersistentVolumeClaimを作成するには、次のYAMLファイルを使用できします。これにより、csi-rbd-sc
StorageClassからマウント済みのファイルシステム(RBDイメージにより支援)を要求します。
kubectl@adm >cat <<EOF > pvc.yaml --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: rbd-pvc spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 1Gi storageClassName: csi-rbd-sc EOFkubectl@adm >kubectl apply -f pvc.yaml
次に示すのは、前に述べたPersistentVolumeClaimをマウント済みのファイルシステムとしてポッドのリソースにバインドする例です。
kubectl@adm >cat <<EOF > pod.yaml --- apiVersion: v1 kind: Pod metadata: name: csi-rbd-demo-pod spec: containers: - name: web-server image: nginx volumeMounts: - name: mypvc mountPath: /var/lib/www/html volumes: - name: mypvc persistentVolumeClaim: claimName: rbd-pvc readOnly: false EOFkubectl@adm >kubectl apply -f pod.yaml