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_POOL
20.1.3 Block Deviceイメージの一覧 #
「mypool」という名前のプール内のBlock Deviceを一覧にするには、次のコマンドを実行します。
cephuser@adm >
rbd ls mypool
20.1.4 イメージ情報の取得 #
「mypool」という名前のプール内のイメージ「myimage」から情報を取得するには、次のコマンドを実行します。
cephuser@adm >
rbd info mypool/myimage
20.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/myimage
20.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/file
20.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ファイルシステムを作成します。#
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
を置き換えてから、デバイスをマウントして正しくマウントされたかを確認します。#
mount /dev/rbd0 /mnt#
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.デバイスの新しいサイズ全体を使用するようファイルシステムを拡張します。
#
xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000
デバイスへのアクセスが終わったら、デバイスをマップ解除してアンマウントできます。
cephuser@adm >
rbd device unmap /dev/rbd0#
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システムによってトリガされます。このために、systemd
パッケージにのユニットファイルである
rbdmap.serviceceph-common
が含まれています。
このスクリプトは引数を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.デバイスの新しいサイズ全体を使用するようファイルシステムを拡張します。
#
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==
EOF
cephuser@adm >
rbd --cluster remote mirror pool peer bootstrap import \
--site-name remote image-pool token
20.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/image1
20.4.2.4 イメージミラーリングの無効化 #
特定のイメージのミラーリングを無効にするには、mirror image disable
サブコマンドと共にプール名とイメージ名を指定します。
cephuser@adm >
rbd --cluster local mirror image disable POOL_NAME/IMAGE_NAME
20.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_NAME
20.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 VALUE
rbd cache
RBD (RADOS Block Device)のキャッシュを有効にします。デフォルトは「true」です。
rbd cache size
RBDキャッシュのサイズ(バイト単位)。デフォルトは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 min
QoSの最小スケジュールチック(ミリ秒)。デフォルトは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-diff
Fast-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.1を使用して展開したクラスタでは、古いクライアント(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