LC2009 Tutorial: device-mapper

Transcription

1 device-mapper 解説 日本電気株式会社 野村淳一 2009 年 9 月 18 日

2 device-mapper 解説 はじめに device-mapper とは 各種 device-mapper ターゲットの機能 device-mapper の概念と構造 device-mapper を使う Request-based device-mapper の紹介 さいごに Page 2

3 はじめに Page 3

4 はじめに ハードディスクなどのストレージデバイスは高速化 大容量化の一途をたどっていますが 拡張性や耐障害性 暗号化 バックアップなど機能面での重要性も増しています Linux では このような機能拡張をソフトウェア的に行なうために device-mapper という仕組みが 2.6 カーネルから取り込まれています このチュートリアルでは device-mapper について その背景や機能 内部構造について解説します Page 4

5 device-mapper とは Page 5

6 Linux におけるストレージデバイス ストレージデバイスは ブロックデバイス として抽象化 例えば以下のようなデバイスが Linux 上では以下のように 内蔵ディスク USB メモリ Linux /dev/sda 内蔵ディスク /dev/sdb USB メモリ /dev/sdc 論理ディスク (RAID カード ) ハードウェア RAID カード 論理ボリューム 冗長化パスをもつディスクアレイ /dev/sdd 論理ディスク 1 ( ディスクアレイ, 経路 1) /dev/sde 論理ディスク 1 ( ディスクアレイ, 経路 2) Page 6

7 ストレージデバイスへの I/O ストレージデバイスへの I/O は概ね以下のような流れになる アプリケーション ファイルの読み書き要求 ファイルシステム ファイル上の位置とストレージデバイス上のブロックとの対応づけ ブロックデバイスドライバ ( 共通部分 ) ブロックの読み書き要求の各種制約チェック 変換 並べ替え ブロックデバイスドライバ ( ハードウェア固有部分 ) 読み書き要求をストレージデバイスの理解可能な形にして指示 ストレージデバイス device-mapper Page 7

8 device-mapper とは device-mapper は 2.6 カーネルから取り込まれた Linux のブロックデバイスドライバおよびそれをサポートするライブラリ群 ( dm, DM と略される ) ブロックデバイスの共通部分にプラグインし ブロックの読み書き要求に対して様々な変換を加えることができる 開発された経緯 2.6 カーネル開発時 論理ボリュームの管理機構として EVMS と LVM2 という二つの機能が競合していた 多機能化しコードが複雑化する中で 論理ボリュームに対する I/O を物理デバイスに対する I/O にマッピングする機能を双方のカーネル内共通部分として括り出し 論理ボリュームの構成管理のような固有の処理はユーザスペースで行なうようにしたのが device-mapper Page 8

9 device-mapper の機能と利用例 一つまたは複数のブロックデバイスへの I/O をとりまとめ変換を加える機能を提供する Linear ( ブロック位置のオフセット変更 ) Striped (I/O 要求を一定サイズで分割して複数のデバイスへ発行 ) Mirror (I/O 要求を複数のデバイスへ発行 ) Multipath (I/O 要求をいずれか一つのデバイスに発行 ) Snapshot ( ブロック内容変更時に旧内容をバックアップにコピー ) Crypt ( ブロック単位での暗号化 復号 ) 使用アプリケーション LVM2 ( 論理ボリュームマネージャ ) multipath-tools ( 冗長パス管理ツール ) dmraid ( ソフトウェア RAID 管理ツール ) cryptsetup ( 暗号化デバイス管理ツール ) Page 9

10 各種 device-mapper ターゲットの機能 Page 10

11 linear 最も基本的なターゲット 指定オフセットを加えて他のブロックデバイスに I/O を転送 DM デバイス ディスク 1 ディスク 2 ディスク 3 Page 11

12 striped 指定のストライプサイズ境界で 複数のデバイスに I/O を振り分ける (RAID0 相当 ) DM デバイス ディスク 1 ディスク 2 Page 12

13 mirror 書き込みは配下の全デバイスに 読み込みはいずれか一つのから (RAID1 相当 ) ディスク上の各位置について複数のデバイス間で内容が一致しているかどうかを随時記録 更新するログデバイスを別途指定可能 ディスクの新規追加や突発的な電源断による再起動など 同期状態にずれがある場合 ディスク間でコピーを行なう DM デバイス ディスク 3 同期状態の記録 ディスク 1 ディスク 2 Page 13

14 multipath ディスク実体に対して複数のパス ( アクセス経路 ) がある場合 Linux では各パスについて別々のブロックデバイスが割り当てられる multipath ターゲットでは それらのパスを一つの DM デバイスにまとめ I/O を振り分けたり パスが切断された場合に別パスでリトライしたりする DM デバイス 経路 1 経路 2 ( ディスク実体 ) Page 14

15 snapshot snapshot-origin と snapshot の 2 種類のターゲットドライバから構成される snapshot-origin は linear マッピングと同様だが 書き込みがあった場合 snapshot ターゲットに通知する snapshot は通知を受けると古い内容をコピーする 読み込み時 コピーがあればそれを なければ origin の内容を返す DM デバイス (origin) DM デバイス (snapshot) 変更前ブロックをコピー ディスク 1 ディスク 2( ディスク 1 の差分情報を保持 ) Page 15

16 crypt テーブルのパラメータで指定された方法で ブロック内容を暗号化 復号する DM デバイス 暗号化 復号 ディスク Page 16

17 zero, error, delay テストやデバッグで便利なターゲット zero: 読み込んだブロックの中身は全て 0 error: 全ての読み書きが I/O エラー delay: 一定時間の遅延後 下位のブロックデバイスにI/O 発行 常に中身が全て 0 のブロックを返す 常に I/O エラー I/O 発行するまで遅延を入れる zero error delay Page 17

18 device-mapper の概念と構造 Page 18

19 device-mapper の構成概念と構造 ファイルシステム I/O 要求 /dev/mapper/.. というデバイスが device-mapper 機能を持つ ブロックデバイス (/dev/mapper/..) device-mapper ブロックデバイス DM テーブル セクタ位置からターゲットドライバとパラメータを特定 複数の dm デバイスをスタック可能 デバイス使用中にテーブル置き換えて構成変更可能 ターゲットドライバ ターゲットドライバ 他のブロックデバイスにマッピング Page 19

20 device-mapper のマッピング例 /dev/mapper/... 0~99 番セクタへの I/O は linear ターゲットによって sda にマップ ( オフセット 0) 0~99 DM テーブル 100~ ~299 Linear -> sda, offset 0 Linear -> sdb, offset 20 Striped -> sdc, sdd 200~299 番セクタへの I/O は striped ターゲットによって sdc, sdd にマップ striped ターゲット linear ターゲット linear ターゲット /dev/sda /dev/sdb /dev/sdc /dev/sdd Page 20

21 device-mapper のスタッキング /dev/mapper/map0 /dev/mapper/map1 /dev/mapper/map2 device-mapper デバイス (/dev/mapper/..) 自身もブロックデバイスなので 各種のマップをスタックすることが可能 Page 21

22 device-mapper の構成変更 (1) /dev/mapper/.. ブロックデバイス ターゲットドライバ device-mapper の特徴の一つは ブロックデバイスを使用中に構成変更できること 上図中 が各コンポーネントで処理されている I/O 要求とした場合 どのように構成変更を行なうか 内部の動作を見てみる Page 22

23 device-mapper の構成変更 (2) テーブルのロード /dev/mapper/.. ブロックデバイス ターゲットドライバ ターゲットドライバ 新規のテーブルを作成しロードする ターゲットドライバは必要なメモリを確保 この段階では 新しいテーブルは使用されず I/O 要求は古いテーブルにより処理継続される Page 23

24 device-mapper の構成変更 (3) サスペンド /dev/mapper/.. サスペンド開始すると処理中の I/O が完了するまで待つ 新規 I/O は dm の入り口でキューされる ブロックデバイス ターゲットドライバ ターゲットドライバ サスペンド完了時点でターゲットドライバ配下には処理中の I/O が無い状態になる Page 24

25 device-mapper の構成変更 (4) レジューム /dev/mapper/.. レジュームするとキューされていた I/O が新しいテーブルを使って処理され始める ブロックデバイス 古いテーブルは既に使われていないので安全に解放できる ターゲットドライバ Page 25

26 device-mapper を使う Page 26

27 device-mapper の基本 デバイスファイル名 : /dev/mapper と /dev/dm-* /dev/mapper/< マップ名 > を使うことが推奨される /dev/dm-< 番号 > はカーネル内でのブロックデバイス共通の名前管理のための便宜的なもの マップを作成する順番により変動するので 通常使うべきではない sysfs 上では dm-< 番号 > を参照せざるを得ないが /sys/block/dm-< 番号 >/dm/name に < マップ名 > が格納されている DM アプリケーションによって他の名前 ( 通常 /dev/mapper/.. へのシンボリックリンク ) が用意されることもある multipath: /dev/mpath/< デバイス名 > LVM2: /dev/< ボリュームグループ名 >/< ボリューム名 > Page 27

28 dmsetup device-mapper の API にほぼ 1:1 対応した操作を行なえる 情報表示 dmsetup ls [--tree] : DM デバイス一覧 ( またはツリー表示 ) dmsetup table: DM テーブルの表示 dmsetup info [-c]: DM デバイスの状態 作成 構成変更 削除 dmsetup create < マップ名 > : デバイス作成 echo <DM テーブル > dmsetup load < マップ名 > : テーブルのロード dmsetup resume < マップ名 >: ロードしたテーブルに置き換え dmsetup remove < マップ名 >: デバイス削除 ただし dmsetup を直接使うのは主にデバッグやテストなど 通常は各 DM アプリケーション (LVM2 や multipath-tools) を使う 作成から使用まで (DM アプリケーション間でほぼ共通 ) 論理デバイス作成 ( アプリケーション固有の構成管理情報作成 ) 論理デバイスの activation (DM デバイス作成 ) 以降 状態表示や deactivation 論理デバイス削除は随時 Page 28

29 DM アプリケーション 各 DM アプリケーションの使い方概要 新規作成 LVM2 lvcreate m ultipath-tools dm raid cryptsetup m ultipath.conf に装置情報 装置専用のBIO Sユーテ cryptsetup luksform at を記載 ィリティなどでRAID メ タデータ作成 Activation lvchange -ay m ultipathd 起動 dm raid -ay cryptsetup lukso pen D eactivationlvchange -an m ultipath -f dm raid -an cryptsetup luksc lose 構成変更 lvresiz e, m ultipath.conf の設定変更装置専用のBIO Sユーテ cryptsetu p luksaddkey lvconvert, pvm ove ィリティなどから行なうなど 削除 lvrem ove m ultipath.conf でブラック dm raid -E ( 特になし ) リスト指定 状態表示 lvs m ultipath -ll dm raid -c cryptsetup luksd um p Page 29

30 Request-based device-mapper の紹介 Page 30

31 Linux ブロックデバイスの内部構造 ブロックデバイス ファイルシステム I/O スケジューラ 低レベルデバイスドライバ ( ハードウェア固有処理 ) BIO request BIO はファイルシステムなどからブロックデバイスに対する I/O 要求単位 ブロックデバイス内部では BIO を request という 箱 に詰め込む request は I/O スケジューラのキューに置かれ 対象ディスク領域が連続している BIO は一つの request にまとめられる 低レベルデバイスドライバには request が I/O 単位として発行される Page 31

32 従来の BIO-based device-mapper の位置づけ I/O スケジューラより上の層に位置づけられ BIO が処理対象 /dev/mapper/.. ファイルシステム BIO ブロックデバイス I/O スケジューラ request 低レベルデバイスドライバ Page 32

33 BIO-based device-mapper における multipath の動作 BIO 何個毎にパス切り替えの判断を行なうかをパラメータ (rr_min_io) で指定する 実際に低レベルデバイスドライバに発行される I/O は request 単位なので I/O スケジューラの動作によっては期待した負荷分散にならない ファイルシステム BIO based DM multipath I/O スケジューラ I/O スケジューラ BIO request 低レベルデバイスドライバ 低レベルデバイスドライバ Page 33

34 パス切り替え間隔 (rr_min_io) による動作の違い rr_min_io=1 rr_min_io=2 BIO based DM multipath BIO based DM multipath rr_min_io=4 rr_min_io=8 BIO based DM multipath BIO based DM multipath Page 34

35 BIO-based multipath での問題点 READ 向けの最 300 適な rr_min_io 250 BIO based dm WRITE 向けの最適な rr_min_io Throughput[MB/s] BIO Seq READ MP BIO Seq WRITE MP BIO Seq READ Single BIO Seq WRITE Single 50 Page rr_min_io I/O パターンを予想して最適なパス切り替え間隔を見つける必要あり WRITE はある程度のまとまった量の要求として出される場面が多く I/O スケジューラでマージされる可能性も高い その場合には rr_min_io は大きめの方が良い READ は応答性が要求されるため細かなサイズでマージされずに出される場面が多く rr_min_io は小さい方が良い

36 request-based device-mapper I/O スケジューラより下の層にも device-mapper の機能を追加 request を単位として機能するため multipath の負荷分散で効果を発揮 カーネルより使用可能 BIO-based か request-based かはターゲットによって使い分け ( 現状 multipath のみ request-based) ファイルシステム BIO /dev/mapper/.. I/O スケジューラ request Request based DM multipath 低レベルデバイスドライバ 低レベルデバイスドライバ Page 36

37 さいごに Page 37

38 device-mapper に関する情報 Device-mapper Resource Page dm-devel メーリングリスト device-mapper のカーネル側機能に関する議論 device-mapper multipath に関する議論 lvm-devel メーリングリスト device-mapper のユーザスペースライブラリに関する議論はこちらでも行なわれることあり Page 38

39