Red Hat Enterprise Linux 8
ストレージデバイスの管理
Red Hat Enterprise Linux 8 における単一ノードストレージの導入と設定
Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is
available at
http://creativecommons.org/licenses/by-sa/3.0/
. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must
provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,
Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,
Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States
and other countries.
Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.
Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and
other countries.
Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the
official Joyent Node.js open source or commercial project.
The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marks
or trademarks/service marks of the OpenStack Foundation, in the United States and other
countries and are used with the OpenStack Foundation's permission. We are not affiliated with,
endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
概要
概要
. . . . . . . . . . . . . . . . . . . .
目次
目次
オープンソースをより包摂的に オープンソースをより包摂的に RED HAT ドキュメントへのフィードバックドキュメントへのフィードバック (英語のみ英語のみ) 第 第1章章 利用可能なストレージオプションの概要利用可能なストレージオプションの概要 1.1. ローカルストレージオプション 1.2. リモートストレージオプション 1.3. GFS2 ファイルシステムのクラスター化ソリューション 1.4. GLUSTER 設定されたソリューション1.4.1. Red Hat Gluster Storage オプション 1.4.2. Red Hat Ceph Storage オプション 第 第2章章 「「RHEL システムロールを使用したローカルストレージの管理」システムロールを使用したローカルストレージの管理」 2.1. STORAGE ロールの概要 2.2. STORAGE システムロールでストレージデバイスを識別するパラメーター 2.3. ブロックデバイスに XFS ファイルシステムを作成する ANSIBLE PLAYBOOK の例 2.4. ファイルシステムを永続的にマウントする ANSIBLE PLAYBOOK の例 2.5. 論理ボリュームを管理する ANSIBLE PLAYBOOK の例 2.6. オンラインのブロック破棄を有効にする ANSIBLE PLAYBOOK の例
2.7. EXT4 ファイルシステムを作成してマウントする ANSIBLE PLAYBOOK の例 2.8. EXT3 ファイルシステムを作成してマウントする ANSIBLE PLAYBOOK の例 2.9. STORAGE システムロールを使用した RAID ボリュームの設定
2.10. STORAGE システムロールを使用した LVM POOL WITH RAID の設定 2.11. STORAGE ロールを使用した LUKS 暗号化ボリュームの作成 第 第3章章 パーティションの使用パーティションの使用 3.1. パーティションテーブルの表示 3.1.1. parted でパーティションテーブルの表示 3.1.2. parted print の出力例 3.2. ディスクへのパーティションテーブルの作成 3.2.1. ディスクのパーティション変更前の留意事項 パーティションの最大数 パーティションの最大サイズ サイズ調整 3.2.2. パーティションテーブルの種類の比較 3.2.3. MBR ディスクパーティション 3.2.4. 拡張 MBR パーティション 3.2.5. MBR パーティションタイプ 3.2.6. GUID パーティションテーブル 3.2.7. parted でディスクにパーティションテーブルを作成 3.3. パーティションの作成 3.3.1. ディスクのパーティション変更前の留意事項 パーティションの最大数 パーティションの最大サイズ サイズ調整 3.3.2. パーティションタイプ パーティションタイプまたはフラグ パーティションファイルシステムのタイプ 3.3.3. パーティション命名スキーム 3.3.4. マウントポイントとディスクパーティション 3.3.5. parted でパーティションの作成 3.3.6. fdisk でパーティションタイプの設定 8 9 10 10 11 12 13 13 13 15 15 15 16 17 17 18 19 19 20 21 22 24 24 24 24 25 25 26 26 26 27 27 28 29 30 31 32 32 32 33 33 33 33 33 34 35 35 37
. . . . . . . . 3.4. パーティションの削除 3.4.1. ディスクのパーティション変更前の留意事項 パーティションの最大数 パーティションの最大サイズ サイズ調整 3.4.2. parted でパーティションの削除 3.5. パーティションのサイズ変更 3.5.1. ディスクのパーティション変更前の留意事項 パーティションの最大数 パーティションの最大サイズ サイズ調整 3.5.2. parted でパーティションのサイズ変更 3.6. ディスクを再構成するストラテジー 3.6.1. パーティションが分割されていない空き領域の使用 3.6.2. 未使用パーティションの領域の使用 3.6.3. アクティブなパーティションの空き領域の使用 3.6.3.1. 破壊的な再構成 3.6.3.2. 非破壊的な再パーティション 3.6.3.2.1. 既存データの圧縮 3.6.3.2.2. 既存パーティションのサイズ変更 3.6.3.2.3. 新しいパーティションの作成 第 第4章章 永続的な命名属性の概要永続的な命名属性の概要 4.1. 非永続的な命名属性のデメリット 4.2. ファイルシステムおよびデバイスの識別子 ファイルシステムの識別子 デバイスの識別子 推奨事項 4.3. /DEV/DISK/ にある UDEV メカニズムにより管理されるデバイス名 4.3.1. ファイルシステムの識別子 /dev/disk/by-uuid/ の UUID 属性 /dev/disk/by-label/ のラベル属性 4.3.2. デバイスの識別子 /dev/disk/by-id/ の WWID 属性 /dev/disk/by-partuuid のパーティション UUID 属性 /dev/disk/by-path/ のパス属性
4.4. DM MULTIPATH を使用した WORLD WIDE IDENTIFIER 4.5. UDEV デバイス命名規則の制約 4.6. 永続的な命名属性の一覧表示 4.7. 永続的な命名属性の変更 第 第5章章 NVDIMM 永続メモリーストレージの使用永続メモリーストレージの使用 5.1. NVDIMM 永続メモリーテクノロジー 5.2. NVDIMM のインターリービングおよび地域 5.3. NVDIMM 名前空間 5.4. NVDIMM アクセスモード 5.5. ブロックデバイスとして動作する NVDIMM 上のセクター名前空間の作成 5.5.1. ndctl のインストール 5.5.2. 既存の NVDIMM 名前空間のセクターモードへの再設定 5.5.3. セクターモードでの新たな NVDIMM 名前空間の作成 5.6. NVDIMM でのデバイス DAX 名前空間の作成 5.6.1. デバイスのダイレクトアクセスモードの NVDIMM 5.6.2. ndctl のインストール 38 38 38 38 39 39 40 40 41 41 41 42 43 44 44 45 45 46 46 46 47 48 48 49 49 49 49 49 49 50 50 50 50 51 51 51 52 53 54 55 55 55 56 56 57 57 58 59 60 60 60
. . . . . . . . . . . . 5.6.3. 既存の NVDIMM 名前空間をデバイス DAX モードに再構成 5.6.4. デバイス DAX モードでの新しい NVDIMM 名前空間の作成 5.7. NVDIMM でのファイルシステム DAX 名前空間の作成 5.7.1. ファイルシステムの直接アクセスモードの NVDIMM ページごとのメタデータ割り当て fsdax 上のパーティションおよびファイルシステム 5.7.2. ndctl のインストール 5.7.3. ファイルシステム DAX モードへの既存の NVDIMM 名前空間の再設定 5.7.4. ファイルシステム DAX モードで新しい NVDIMM 名前空間の作成 5.7.5. ファイルシステム DAX デバイスでのファイルシステムの作成 5.8. NVDIMM 永続メモリーのトラブルシューティング 5.8.1. ndctl のインストール 5.8.2. S.M.A.R.T. を使用した NVDIMM 正常性 (ヘルス) の監視 5.8.3. 破損した NVDIMM デバイスの検出と交換 第 第6章章 未使用ブロックの破棄未使用ブロックの破棄 6.1. ブロックの破棄操作 要件 6.2. ブロック破棄操作のタイプ 推奨事項 6.3. バッチブロック破棄の実行 6.4. オンラインブロック破棄の有効化 6.5. RHEL システムロールを使用したオンラインのブロック破棄の有効化 6.5.1. オンラインのブロック破棄を有効にする Ansible Playbook の例 6.6. 定期的なブロック破棄の有効化 第 第7章章 ISCSI の使用の使用 7.1. ISCSI ターゲットの作成 7.1.1. targetcli のインストール 7.1.2. iSCSI ターゲットの作成 7.1.3. iSCSI バックストア 7.1.4. fileio ストレージオブジェクトの作成 7.1.5. ブロックストレージオブジェクトの作成 7.1.6. pscsi ストレージオブジェクトの作成 7.1.7. メモリーコピーの RAM ディスクストレージオブジェクトの作成 7.1.8. iSCSI ポータルの作成 7.1.9. iSCSI LUN の作成 7.1.10. 読み取り専用の iSCSI LUN の作成 7.1.11. iSCSI ACL の作成 7.1.12. iSCSI イニシエーターの作成 7.1.13. ターゲットのチャレンジハンドシェイク認証プロトコルの設定 7.1.14. イニシエーター用のチャレンジハンドシェイク認証プロトコルの設定 7.2. ISCSI セッションの監視 7.2.1. iscsiadm ユーティリティーで iSCSI セッションの監視 7.3. ISCSI ターゲットの削除 7.3.1. targetcli ツールで iSCSI オブジェクトの削除 7.4. DM MULTIPATH がデバイスタイムアウトの上書き 第 第8章章 ファイバーチャネルデバイスの使用ファイバーチャネルデバイスの使用 8.1. ファイバーチャネル論理ユニットのサイズ変更 8.2. ファイバーチャネルでデバイスのリンク切れ動作の特定 8.3. ファイバーチャンネル設定ファイル 8.4. DM MULTIPATH がデバイスタイムアウトの上書き 61 62 63 64 64 64 65 65 66 67 68 68 68 69 74 74 74 74 74 74 75 76 76 76 77 77 77 78 79 79 80 81 81 82 83 84 85 87 88 89 90 90 91 91 91 93 93 93 94 95
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 第
第9章章 FIBRE CHANNEL OVER ETHERNET の設定の設定 9.1. RHEL でハードウェア FCOE HBA の使用 9.2. ソフトウェア FCOE デバイスの設定 9.3. 関連情報 第 第10章章 EH_DEADLINE を使用したストレージエラーからの回復における最大時間の設定を使用したストレージエラーからの回復における最大時間の設定 10.1. EH_DEADLINE パラメーター eh_deadline が便利なシナリオ 可能な値 10.2. EH_DEADLINE パラメーターの設定 第 第11章章 スワップの使用スワップの使用 11.1. スワップ領域 11.2. システムの推奨スワップ領域 11.3. スワップ領域の追加 11.3.1. LVM2 論理ボリュームでのスワップ領域の拡張 11.3.2. スワップの LVM2 論理ボリュームの作成 11.3.3. スワップファイルの作成 11.4. スワップ領域の削除 11.4.1. LVM2 論理ボリュームでのスワップ領域の縮小 11.4.2. スワップの LVM2 論理ボリュームの削除 11.4.3. スワップファイルの削除 第 第12章章 スナップショットとしてのシステムアップグレードの管理スナップショットとしてのシステムアップグレードの管理 12.1. BOOM プロセスの概要 12.2. BOOM で別のバージョンへのアップグレード
12.3. RED HAT ENTERPRISE LINUX のバージョン間切り替え 12.4. スナップショットの削除
第
第13章章 NVME OVER FABRIC デバイスの概要デバイスの概要 13.1. RDMA を使用した NVME OVER FABRICS
13.1.1. configfs で NVMe/RDMA ターゲットの設定
13.1.2. nvmetcli を使用した NVMe/RDMA ターゲットの設定 13.1.3. NVMe/RDMA クライアントの設定
13.2. FC を使用した NVME OVER FABRICS
13.2.1. Broadcom アダプターの NVMe イニシエーターの設定 13.2.2. QLogic アダプターの NVMe イニシエーターの設定 第 第14章章 ディスクスケジューラーの設定ディスクスケジューラーの設定 14.1. RHEL 8 におけるディスクスケジューラーの変更 14.2. 利用可能なディスクスケジューラー 14.3. 各種ユースケースで異なるディスクスケジューラー 14.4. デフォルトのディスクスケジューラー 14.5. アクティブなディスクスケジューラーの決定 14.6. TUNED でディスクスケジューラーの設定 14.7. UDEV ルールでディスクスケジューラーの設定 14.8. 特定ディスクに任意のスケジューラーを一時的に設定 第 第15章章 リモートディスクレスシステムの設定リモートディスクレスシステムの設定 15.1. リモートディスクレスシステム用環境の準備 15.2. ディスクレスクライアントの TFTP サービスの設定 15.3. ディスクレスクライアントの DHCP サーバーの設定 15.4. ディスクレスクライアントのエクスポートしたファイルシステムの設定 15.5. リモートディスクレスシステムの再設定 15.6. リモートディスクレスシステムの読み込みにおける最も一般的な問題 97 97 97 99 100 100 100 100 101 102 102 102 103 103 104 104 105 105 106 107 108 108 108 112 113 115 115 115 117 118 119 120 121 124 124 124 125 125 125 126 128 129 130 130 131 131 132 134 135
. . . . . . . . . . . . . . . . 15.6.1. クライアントが IP アドレスを取得しない 15.6.2. リモートディスクレスシステムの起動時に、ファイルは使用できない 15.6.3. カーネル/initrd の読み込み時に、システムの起動に失敗した 第 第16章章 RAID の管理の管理
16.1. RAID (REDUNDANT ARRAY OF INDEPENDENT DISKS) 16.2. RAID のタイプ 16.3. RAID レベルとリニアサポート 16.4. LINUX RAID サブシステム 16.4.1. Linux ハードウェア RAID のコントローラードライバー 16.4.2. mdraid 16.5. ソフトウェア RAID の作成 16.6. インストール後のソフトウェア RAID の作成 16.7. STORAGE システムロールを使用した RAID ボリュームの設定 16.8. RAID の再設定 16.8.1. RAID の再成形 16.8.1.1. RAID のサイズ変更 (拡張)。 16.8.1.2. RAID のサイズ変更 (縮小) 16.8.2. RAID テイクオーバー 16.8.2.1. サポート対象の RAID 変換 16.8.2.2. RAID レベルへの変換 16.9. インストール後の ROOT ディスクの RAID1 への変換 16.10. 高度な RAID デバイスの作成 16.11. RAID の監視 16.12. RAID のメンテナンス 16.12.1. RAID で障害の発生したディスクの置き換え 16.12.2. アレイ内の破損したディスクの置き換え 16.12.3. RAID ディスクの再同期 第 第17章章 LUKS を使用したブロックデバイスの暗号化を使用したブロックデバイスの暗号化 17.1. LUKS ディスクの暗号化 17.2. RHEL 8 の LUKS バージョン 17.3. LUKS2 再暗号化中のデータ保護のオプション 17.4. LUKS2 を使用したブロックデバイスの既存データの暗号化 17.5. 独立したヘッダーがある LUKS2 を使用してブロックデバイスの既存データの暗号化 17.6. LUKS2 を使用した空のブロックデバイスの暗号化 17.7. STORAGE ロールを使用した LUKS 暗号化ボリュームの作成 第 第18章章 テープデバイスの管理テープデバイスの管理 18.1. テープドライブ管理ツールのインストール 18.2. テープデバイスへの書き込み 18.3. テープデバイスでのテープヘッドの切り替え 18.4. テープデバイスからのデータの復元 18.5. テープデバイスのデータの消去 18.6. テープコマンド 第 第19章章 STRATIS で階層化ローカルストレージの管理で階層化ローカルストレージの管理 19.1. STRATIS ファイルシステムの設定 19.1.1. Stratis の目的と機能 19.1.2. Stratis ボリュームの構成要素 19.1.3. Stratis で使用可能なブロックデバイス 対応デバイス 対応していないデバイス 19.1.4. Stratis のインストール 135 136 136 137 137 137 139 140 141 141 141 142 143 144 144 144 145 145 145 146 146 147 148 148 148 150 151 153 153 154 155 155 157 158 158 160 160 160 162 163 163 164 165 165 165 165 166 166 167 167
19.1.5. Stratis プールの作成 19.1.6. Stratis ファイルシステムの作成 19.1.7. Stratis ファイルシステムのマウント 19.1.8. Stratis ファイルシステムを永続的に維持 19.1.9. 関連情報 19.2. 追加のブロックデバイスで STRATIS ボリュームの拡張 19.2.1. Stratis ボリュームの構成要素 19.2.2. Stratis プールへのブロックデバイスの追加 19.2.3. 関連情報 19.3. STRATIS ファイルシステムの監視 19.3.1. さまざまなユーティリティーが報告する Stratis のサイズ 19.3.2. Stratis ボリュームの情報表示 19.3.3. 関連情報 19.4. STRATIS ファイルシステムでのスナップショットの使用 19.4.1. Stratis スナップショットの特徴 19.4.2. Stratis スナップショットの作成 19.4.3. Stratis スナップショットのコンテンツへのアクセス 19.4.4. Stratis ファイルシステムを以前のスナップショットに戻す 19.4.5. Stratis スナップショットの削除 19.4.6. 関連情報 19.5. STRATIS ファイルシステムの削除 19.5.1. Stratis ボリュームの構成要素 19.5.2. Stratis ファイルシステムの削除 19.5.3. Stratis プールの削除 19.5.4. 関連情報 167 169 170 171 172 172 172 173 173 173 173 174 174 175 175 175 175 176 177 177 177 177 178 179 180
オープンソースをより包摂的に
Red Hat は、コード、ドキュメント、および Web プロパティーにおける問題のある用語の修正に努め ています。取り組みの開始として、マスター、スレーブ、ブラックリスト、ホワイトリストの 4 つの用 語の修正に取り組みます。このため、これらの変更は今後の複数のリリースに対して段階的に実施され ます。詳細は、弊社の CTO のメッセージを参照してください。
RED HAT ドキュメントへのフィードバック (英語のみ)
ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合 は、以下のように行います。 特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。 1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。 2. マウスカーソルで、コメントを追加する部分を強調表示します。 3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。 4. 表示される手順に従ってください。 より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。 1. Bugzilla の Web サイトにアクセスします。 2. Component で Documentation を選択します。 3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ド キュメントの該当部分へのリンクも記入してください。 4. Submit Bug をクリックします。第
1章 利用可能なストレージオプションの概要
本章では、Red Hat Enterprise Linux 8 で利用可能なストレージの種類を説明します。Red Hat
Enterprise Linux は、ローカルストレージの管理、およびリモートストレージへの接続に使用するさま ざまなオプションを提供しています。図1.1「Red Hat Enterprise Linux ストレージダイアグラム (概 要)」では、さまざまなストレージオプションを説明します。
図
図1.1 Red Hat Enterprise Linux ストレージダイアグラムストレージダイアグラム (概要概要)
1.1. ローカルストレージオプション
以下は、Red Hat Enterprise Linux 8 で利用可能なローカルストレージオプションです。 基本的なディスク管理:
parted と fdisk を使用して、パーティションの作成、修正、削除、表示を行うことができま す。パーティショニングレイアウトの仕様は以下のようになります。
MBR (Master Boot Record) - BIOS ベースのコンピューターで使用されます。プライマリー パーティション、拡張パーティション、および論理パーティションを作成できます。 GPT (GUID Partition Table) - GUID (Globally Unique identifier) を使用し、一意のディスク およびパーティション GUID を提供します。
パーティションを暗号化するには、LUKS (Linux Unified Key Setup-on-disk-format) を使用 します。パーティションを暗号化する場合は、インストール時にオプションを選択し、パ スフレーズを入力させるプロンプトを表示します。このパスフレーズにより、暗号化キー のロックが解除されます。
ストレージ使用オプション:
NVDIMM (Non-Volatile Dual In-line Memory Modules) の管理 - メモリーとストレージの組 み合わせです。システムに接続した NVDIMM デバイスで、さまざまな種類のストレージを 有効にして管理できます。 ブロックストレージ管理 - 各ブロックに固有の識別子を持つブロックの形式でデータを保 存します。 ファイルストレージ - データは、ローカルシステムのファイルレベルに保存されます。こ れらのデータは、XFS (デフォルト) または ext4 を使用してローカルでアクセスしたり、 NFS と SMB を使用してネットワーク上でアクセスできます。 論理ボリュームの設定および管理: 論理ボリュームマネージャー (LVM) - 物理デバイスから論理ボリュームを作成します。論 理ボリューム (LV) は、物理ボリューム (PV) とボリュームグループ (VG) の組み合わせで す。LVM の設定には以下が含まれます。 ハードドライブから PV の作成 物理ボリュームからボリュームグループの作成 ボリュームグループから論理ボリュームを作成すると、マウントポイントが論理ボ リュームに割り当てられます。
Virtual Data Optimizer (VDO) - 重複排除、圧縮、およびシンプロビジョニングを使用し て、データの削減に使用されます。VDO の下で論理ボリュームを使用すると、次のことが できます。 VDO ボリュームの拡張 複数のデバイスにまたがる VDO ボリューム ローカルファイルシステム: XFS Ext4 Straits - テクノロジープレビューとして利用できます。Stratis は、高度なストレージ機能 に対応する、ユーザーとカーネルのハイブリッドローカルストレージ管理システムです。
1.2. リモートストレージオプション
ストレージの接続オプション:
iSCSI - RHEL 8 は targetcli ツールを使用して、iSCSI ストレージの相互接続を追加、削 除、表示、および監視します。
ファイバーチャネル (FC) - Red Hat Enterprise Linux 8 は、以下のネイティブファイバー チャネルドライバーを提供します。
lpfc qla2xxx Zfcp
NVMe (Non-volatile Memory Express) は、ホストソフトウェアユーティリティーがソリッ
ドステートドライブと通信できるようにするインターフェースです。次の種類はファブ リックトランスポートを使用して、NVMe over fabrics を設定します。
RDMA (Remote Direct Memory Access) を使用する NVMe over fabrics ファイバーチャネル (FC) を使用した NVMe over fabrics
Device Mapper のマルチパス (DM Multipath) を使用すると、サーバーノードとストレージ アレイとの間の複数の I/O パスを 1 つのデバイスに設定できます。これらの I/O パスは、個 別のケーブル、スイッチ、コントローラーを含むことができる物理的な SAN 接続です。 ネットワークファイルシステム: NFS SMB
1.3. GFS2 ファイルシステムのクラスター化ソリューション
Red Hat Global File System 2 (GFS2) ファイルシステムは、64 ビットの対称クラスターファイルシス テムで、共有名前空間を提供し、一般的なブロックデバイスを共有する複数のノード間の一貫性を管理 します。GFS2 ファイルシステムは、ローカルファイルシステムに可能な限り近い機能セットを提供す ると同時に、ノード間でクラスターの完全な整合性を強制することを目的としています。これを実現す るため、ノードはファイルシステムリソースにクラスター全体のロックスキームを使用します。この ロックスキームは、TCP/IP などの通信プロトコルを使用して、ロック情報を交換します。 場合によっては、Linux ファイルシステム API では、GFS2 のクラスター化された性質を完全に透過的 にすることができません。たとえば、GFS2 で POSIX ロックを使用しているプログラムは、GETLK の 使用を回避する必要があります。なぜなら、クラスター環境では、プロセス ID が、クラスター内の別 のノードに対するものである可能性があるためです。ただし、ほとんどの場合、GFS2 ファイルシステ ムの機能は、ローカルファイルシステムのものと同じです。
Red Hat Enterprise Linux (RHEL) Resilient Storage Add-On は GFS2 を提供します。GFS2 が必要とす るクラスター管理の提供は RHEL High Availability Add-On により提供されます。
gfs2.ko カーネルモジュールは GFS2 ファイルシステムを実装し、GFS2 クラスターノードに読み込ま れます。 GFS2 環境を最大限に利用するためにも、基礎となる設計に起因するパフォーマンス事情を考慮するこ とが重要です。GFS2 では、ローカルファイルシステムと同様、ページキャッシュで、頻繁に使用され るデータのローカルキャッシングを行ってパフォーマンスを向上します。クラスターのノード間で一貫 性を維持するために、glock ステートマシンでキャッシュ制御が提供されます。
GFS2 ファイルシステムの詳細は、「GFS2 ファイルシステムの設定」を参照してください。
1.4. GLUSTER 設定されたソリューション
このセクションでは、Red Hat Gluster Storage (RHGS) または Red Hat Ceph Storage (RHCS) などの glustered オプションの概要を説明します。
1.4.1. Red Hat Gluster Storage オプション
Red Hat Gluster Storage (RHGS) は、ソフトウェアが定義されたストレージプラットフォームです。こ れは、複数のサーバーから単一のグローバル名前空間に、ディスクストレージリソースを統合します。 GlusterFS はオープンソースの分散ファイルシステムです。これは、クラウドおよびハイブリッドのソ リューションに適しています。 GlusterFS は、GlusterFS のベースとなる異なるタイプのボリュームで構成され、さまざまな要件を提 供します。ボリュームは、ストレージ領域自体であるブリックのコレクションです。 GlusterFS ボリュームのタイプは次のとおりです。 分散 分散 GlusterFS ボリュームボリューム は、デフォルトのボリュームです。この場合、各ファイルは単一の ブリックに格納され、異なるブリック間で共有できません。 レプリケートされた レプリケートされた GlusterFS ボリュームボリューム タイプは、データのレプリカを維持します。この場 合、ブリックが失敗しても、ユーザーはデータにアクセスできます。 分散されレプリケートされた 分散されレプリケートされた GlusterFS ボリュームボリューム は、多数のシステムにレプリカを分散する ハイブリッドボリュームです。ストレージのスケーリングおよび信頼性の高さが重要な環境に は適しています。
RHGS に関する詳細は、「Red Hat gluster ストレージ管理ガイド」を参照してください。
1.4.2. Red Hat Ceph Storage オプション
Red Hat Ceph Storage (RHCS) はスケーラブルでオープンなソフトウェア定義のストレージプラット フォームで、Ceph ストレージシステムの最も安定したバージョンと、Ceph 管理プラットフォーム、 デプロイメントユーティリティー、サポートサービスを組み合わせたものです。
Red Hat Ceph Storage は、クラウドインフラストラクチャーおよび Web スケールオブジェクトスト レージ用に設計されています。Red Hat Ceph Storage クラスターは、以下のタイプのノードで構成さ れます。
Red Hat Ceph Storage Ansible 管理ノード管理ノード
このタイプのノードは、以前のバージョンの Red Hat Ceph Storage に行われた従来の Ceph 管理 ノードとして機能します。このタイプのノードでは、以下の機能が提供されます。 ストレージクラスターの一元管理 Ceph 設定ファイルおよびキー 必要に応じて、セキュリティー上の理由からインターネットにアクセスできないノードに Ceph をインストールするためのローカルリポジトリー ノードの監視 ノードの監視 各モニターノードは、クラスターマップのマスターコピーを維持する monitor デーモン (ceph-mon) を実行します。クラスターマップにはクラスタートポロジーが含まれます。Ceph クラスターに接続
するクライアントは、モニターからクラスターマップの現在のコピーを取得します。これにより、 クライアントがクラスターへのデータの読み取りおよび書き込みが可能になります。
重要
重要
Ceph は 1 つのモニターで実行できますが、実稼働クラスターで高可用性を確保するため には、Red Hat は少なくとも 3 つのモニターノードを持つデプロイメントのみをサポー トします。Red Hat は、750 個の OSD を超えるストレージクラスターに合計 5 つの Ceph Monitor をデプロイすることを推奨します。OSD ノードノード
各 Object Storage Device (OSD) ノードは Ceph OSD デーモン (ceph-osd) を実行し、ノードに割り 当てられている論理ディスクと相互作用します。Ceph は、この OSD ノードにデータを保存しま す。 Ceph は、非常に少数の OSD ノード (デフォルトは 3) で実行できますが、実稼働クラスターは、スト レージクラスターで中程度のスケール (たとえば OSD が 50 個) で始まります。理想的には、Ceph ク ラスターに複数の OSD ノードがあり、CRUSH マップを作成して分離された障害ドメインを許可しま す。 MDS ノードノード
各 Metadata Server (MDS) ノードは、Ceph ファイルシステム (CephFS) に保存されているファイ ルに関連する MDS デーモン (ceph-mds) を実行します。MDS デーモンは、共有クラスターへのア クセスも調整します。
Object Gateway ノードノード
Ceph Object Gateway ノードは、Ceph RADOS Gateway デーモン (ceph-radosgw) を実行し、 Ceph Storage クラスターへの RESTful ゲートウェイを使用するアプリケーションを提供する
librados 上に構築されたオブジェクトストレージインターフェースです。Ceph Object Gateway
は、以下の 2 つのインターフェースをサポートします。 S3
Amazon S3 RESTful API の大規模なサブセットと互換性のあるインターフェースでオブジェクトス トレージ機能を提供します。
Swift
OpenStack Swift API の大規模なサブセットと互換性のあるインターフェースでオブジェクトスト レージ機能を提供します。
第
2章 「RHEL システムロールを使用したローカルストレージの管
理」
Ansible を使用して LVM とローカルファイルシステム (FS) を管理するには、RHEL 8 で利用可能な RHEL システムロールの 1 つである storage ロールを使用できます。 storage ロールを使用すると、ディスク上のファイルシステム、複数のマシンにある論理ボリューム、 および RHEL 7.7 以降の全バージョンでのファイルシステムの管理を自動化できます。 RHEL システムロールと、その適用方法の詳細は、「RHEL システムロールの概要」 を参照してくださ い。2.1. STORAGE ロールの概要
storage ロールは以下を管理できます。 パーティションが分割されていないディスクのファイルシステム 論理ボリュームとファイルシステムを含む完全な LVM ボリュームグループ storage ロールを使用すると、次のタスクを実行できます。 ファイルシステムを作成する ファイルシステムを削除する ファイルシステムをマウントする ファイルシステムをアンマウントする LVM ボリュームグループを作成する LVM ボリュームグループを削除する 論理ボリュームを作成する 論理ボリュームを削除する RAID ボリュームを作成する RAID ボリュームを削除する RAID を使用して LVM プールを作成する RAID を使用して LVM プールを削除する2.2. STORAGE システムロールでストレージデバイスを識別するパラメー
ター
storage ロールの設定は、以下の変数に記載されているファイルシステム、ボリューム、およびプール にのみ影響します。 storage_volumes 管理対象のパーティションが分割されていない全ディスク上のファイルシステムの一覧 現在、パーティションはサポートされていません。storage_pools 管理するプールの一覧 現在、サポートされている唯一のプールタイプは LVM です。LVM では、プールはボリュームグ ループ (VG) を表します。各プールの下には、ロールで管理されるボリュームの一覧があります。 LVM では、各ボリュームは、ファイルシステムを持つ論理ボリューム (LV) に対応します。
2.3. ブロックデバイスに XFS ファイルシステムを作成する ANSIBLE
PLAYBOOK の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage ロールを適用 し、デフォルトパラメーターを使用してブロックデバイスに XFS ファイルシステムを作成します。
警告
警告
storage ロールは、パーティションが分割されていないディスク全体または論理ボ リューム (LV) でのみファイルシステムを作成できます。パーティションにファイ ルシステムを作成することはできません。 例 例2.1 /dev/sdb にに XFS を作成するを作成する Playbook ---- hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs roles: - rhel-system-roles.storage現在、ボリューム名 (この例では barefs) は任意です。storage ロールは、disks: 属性に一 覧表示されているディスクデバイスでボリュームを特定します。 XFS は RHEL 8 のデフォルトファイルシステムであるため、fs_type: xfs 行を省略すること ができます。 論理ボリュームにファイルシステムを作成するには、エンクロージングボリュームグループ を含む disks: 属性の下に LVM 設定を指定します。詳細は、「論理ボリュームを管理する Ansible Playbook の例」 を参照してください。 LV デバイスへのパスを指定しないでください。 関連情報 関連情報 storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-
storage システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。
2.4. ファイルシステムを永続的にマウントする ANSIBLE PLAYBOOK の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールをすぐに 適用して、XFS ファイルシステムを永続的にマウントします。
例
例2.2 /dev/sdb のファイルシステムをのファイルシステムを /mnt/data にマウントするにマウントする Playbook ---- hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data roles: - rhel-system-roles.storage この Playbook では、ファイルシステムが /etc/fstab ファイルに追加され、すぐにファイル システムをマウントします。 /dev/sdb デバイス上のファイルシステム、またはマウントポイントのディレクトリーが存 在しない場合は、Playbook により作成されます。 関連情報 関連情報 storage システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。
2.5. 論理ボリュームを管理する ANSIBLE PLAYBOOK の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールを適用し て、ボリュームグループに LVM 論理ボリュームを作成します。
例
例2.3 myvg ボリュームグループにボリュームグループに mylv 論理ボリュームを作成する論理ボリュームを作成する Playbook - hosts: all vars: storage_pools: - name: myvg disks: - sda - sdb - sdc volumes: - name: mylv size: 2G fs_type: ext4
mount_point: /mnt roles: - rhel-system-roles.storage myvg ボリュームグループは、次のディスクで構成されます。 /dev/sda /dev/sdb /dev/sdc myvg ボリュームグループがすでに存在する場合は、Playbook により論理ボリュームがボ リュームグループに追加されます。 myvg ボリュームグループが存在しない場合は、Playbook により作成されます。
Playbook は、mylv 論理ボリューム上に Ext4 ファイルシステムを作成し、/mnt ファイルシ ステムを永続的にマウントします。 関連情報 関連情報 storage システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。
2.6. オンラインのブロック破棄を有効にする ANSIBLE PLAYBOOK の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage ロールを適用 して、オンラインのブロック破棄を有効にして XFS ファイルシステムをマウントします。 例 例2.4 /mnt/data/ でのオンラインのブロック破棄を有効にするでのオンラインのブロック破棄を有効にする Playbook ---- hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data mount_options: discard roles: - rhel-system-roles.storage 関連情報 関連情報
この Playbook は、「ファイルシステムを永続的にマウントする Ansible Playbook の例」 で説
明している永続的なマウント例のすべての操作も実行します。
storage システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。
2.7. EXT4 ファイルシステムを作成してマウントする ANSIBLE
PLAYBOOK の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールを適用し て、Ext4 ファイルシステムを作成してマウントします。
例
例2.5 /dev/sdb にに Ext4 を作成し、を作成し、/mnt/data にマウントするにマウントする Playbook ---- hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext4 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage Playbook は、/dev/sdb ディスクにファイルシステムを作成します。 Playbook は、/mnt/data ディレクトリーにファイルシステムを永続的にマウントします。 ファイルシステムのラベルは label-name です。 関連情報 関連情報 storage システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。
2.8. EXT3 ファイルシステムを作成してマウントする ANSIBLE
PLAYBOOK の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールを適用し て、Ext3 ファイルシステムを作成してマウントします。
例
例2.6 /dev/sdb にに Ext3 を作成し、を作成し、/mnt/data にマウントするにマウントする Playbook ---- hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb
fs_type: ext3 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage Playbook は、/dev/sdb ディスクにファイルシステムを作成します。 Playbook は、/mnt/data ディレクトリーにファイルシステムを永続的にマウントします。 ファイルシステムのラベルは label-name です。 関連情報 関連情報 storage システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。
2.9. STORAGE システムロールを使用した RAID ボリュームの設定
storage システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL に
RAID ボリュームを設定できます。本セクションでは、要件に合わせて RAID ボリュームを設定するた めに、利用可能なパラメーターを使用して Ansible Playbook を設定する方法を説明します。
前提条件 前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記
注記
storage ソリューションをデプロイするシステムに、Red Hat Ansible
Automation Platform をインストールする必要はありません。 Playbook を実行するシステムに rhel-system-roles パッケージがインストールされている。 storage システムロールを使用して、RAID ボリュームをデプロイするシステムの詳細を記録し たインベントリーファイルがある。 手順 手順 1. 以下の内容を含む新しい playbook.yml ファイルを作成します。 - hosts: all vars: storage_safe_mode: false storage_volumes: - name: data type: raid disks: [sdd, sde, sdf, sdg] raid_level: raid0 raid_chunk_size: 32 KiB mount_point: /mnt/data
state: present roles: - name: rhel-system-roles.storage
警告
警告
特定の状況でデバイス名が変更する場合があります。たとえば、新しい ディスクをシステムに追加するときなどです。したがって、データの損失 を防ぐために、Playbook で特定のディスク名を使用することは推奨してい ません。 2. オプション:Playbook の構文を確認します。# ansible-playbook --syntax-check playbook.yml
3. インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
関連情報 関連情報
RAID の詳細は、「RAID の管理」 を参照してください。
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。
2.10. STORAGE システムロールを使用した LVM POOL WITH RAID の設定
storage システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL に
LVM pool with RAID を設定できます。本セクションでは、利用可能なパラメーターを使用して Ansible Playbook を設定し、LVM pool with RAID を設定する方法を説明します。
前提条件 前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記
注記
storage ソリューションをデプロイするシステムに、Red Hat Ansible
Automation Platform をインストールする必要はありません。
Playbook を実行するシステムに rhel-system-roles パッケージがインストールされている。
storage システムロールを使用して、LVM pool with RAID を設定するシステムの詳細を記録し
たインベントリーファイルがある。 手順
手順
1. 以下の内容を含む新しい playbook.yml ファイルを作成します。 - hosts: all vars: storage_safe_mode: false storage_pools: - name: my_pool type: lvm disks: [sdh, sdi] raid_level: raid1 volumes: - name: my_pool size: "1 GiB" mount_point: "/mnt/app/shared" fs_type: xfs state: present roles: - name: rhel-system-roles.storage
注記
注記
LVM pool with RAID を作成するには、raid_level パラメーターを使用して RAID タイプを指定する必要があります。
2. オプション:Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
3. インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
関連情報 関連情報 RAID の詳細は、「RAID の管理」 を参照してください。 storage システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。
2.11. STORAGE ロールを使用した LUKS 暗号化ボリュームの作成
storage ロールを使用し、Ansible Playbook を実行して、LUKS で暗号化されたボリュームを作成およ
び設定できます。 前提条件
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記
注記
ボリュームを作成するシステムに Red Hat Ansible Automation Platform をイン ストールする必要はありません。
Ansible コントローラーに rhel-system-roles パッケージがインストールされている。 storage システムロールを使用して、LUKS 暗号化ボリュームをデプロイするシステムの詳細を 記録したインベントリーファイルがある。 手順 手順 1. 以下の内容を含む新しい playbook.yml ファイルを作成します。 - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs fs_label: label-name mount_point: /mnt/data encryption: true encryption_password: your-password roles: - rhel-system-roles.storage 2. オプション:Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
3. インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
関連情報 関連情報 LUKS の詳細は、 17 を参照してください。LUKS を使用したブロックデバイスの暗号化 storage システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。 関連情報 関連情報 詳細は、rhel-system-roles パッケージをインストールして、以下のディレクトリーを参照して ください。 /usr/share/doc/rhel-system-roles/storage/ /usr/share/ansible/roles/rhel-system-roles.storage/
第
3章 パーティションの使用
システム管理者は、以下の手順に従ってさまざまな種類のディスクパーティションを作成、削除、およ び変更できます。 ブロックデバイスでパーティションを使用する長所と短所の概要は、ナレッジベースの記事 https://access.redhat.com/solutions/163853 を参照してください。3.1. パーティションテーブルの表示
システム管理者は、ブロックデバイスのパーティションテーブルを表示して、パーティションレイアウ トと個々のパーティションに関する詳細を確認できます。3.1.1. parted でパーティションテーブルの表示
この手順では、parted ユーティリティーを使用してブロックデバイスのパーティションテーブルを表 示する方法を説明します。 手順 手順 1. インタラクティブな parted シェルを起動します。 # parted block-device block-device を、調べるデバイスへのパス (例: /dev/sda) に置き換えます。 2. パーティションテーブルを表示します。 (parted) print 3. 必要に応じて次のコマンドを使用して、次に調べるデバイスに切り替えることもできます。 (parted) select block-device関連情報 関連情報 man ページの parted(8)
3.1.2.
parted printの出力例
このセクションでは、parted シェルの print コマンドの出力例を示し、出力内のフィールドを説明しま す。 例 例3.1 print コマンドの出力コマンドの出力Model: ATA SAMSUNG MZNLN256 (scsi) Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B Partition Table: msdos
Disk Flags:
1 1049kB 269MB 268MB primary xfs boot 2 269MB 34.6GB 34.4GB primary 3 34.6GB 45.4GB 10.7GB primary 4 45.4GB 256GB 211GB extended 5 45.4GB 256GB 211GB logical 以下は、フィールドの説明です。
Model: ATA SAMSUNG MZNLN256 (scsi)
ディスクタイプ、製造元、モデル番号、およびインターフェース。
Disk /dev/sda: 256GB
ブロックデバイスへのファイルパスとストレージ容量。
Partition Table: msdos
ディスクラベルの種類。 Number パーティション番号。たとえば、マイナー番号 1 のパーティションは、/dev/sda1 に対応しま す。 Start およびおよび End デバイスにおけるパーティションの開始場所と終了場所。 Type 有効なタイプは、メタデータ、フリー、プライマリー、拡張、または論理です。 File system ファイルシステムの種類。ファイルシステムの種類が不明な場合は、デバイスの File system フィールドに値が表示されません。parted ユーティリティーは、暗号化されたデバイスのファイ ルシステムを認識できません。 Flags パーティションのフラグ設定一覧。利用可能なフラグ は、boot、root、swap、hidden、raid、lvm、または lba です。
3.2. ディスクへのパーティションテーブルの作成
システム管理者は、ブロックデバイスでパーティションを使用できるように、さまざまな種類のパー ティションテーブルを使用してそのブロックデバイスをフォーマットできます。警告
警告
パーティションテーブルを使用してブロックデバイスをフォーマットすると、その デバイスに保存されているすべてのデータが削除されます。3.2.1. ディスクのパーティション変更前の留意事項
このセクションでは、パーティションの作成、削除、またはサイズ変更を行う前に考慮すべき重要な点 を説明します。注記
注記
注記
注記
このセクションでは、IBM Z アーキテクチャーに固有の DASD パーティションテーブル を説明しません。DASD の情報は、以下を参照してください。
IBM Z への Linux インスタンスの設定
IBM Knowledge Center の「What you should know about DASD」
パーティションの最大数 パーティションの最大数 デバイスで使用できるパーティションの数は、パーティションテーブルの種類によって異なります。 マスターブートレコード マスターブートレコード (MBR) パーティションテーブルでフォーマットされたデバイスでは、 次のいずれかの数だけパーティションを設定できます。 最大 4 つのプライマリーパーティション 最大 3 つのプライマリーパーティション、および 1 つの拡張パーティション、ならびにそ の拡張内に複数の論理パーティション GUID パーティションテーブルパーティションテーブル (GPT) でフォーマットしたデバイスにおけるパーティションの 最大数は 128 個です。GPT 仕様により、パーティションテーブル用に確保するエリアを拡大す ることで、さらに多くのパーティションを作成できますが、parted ユーティリティーで用いら れる一般的な方法で得られるエリアは 128 個に制限されます。
注記
注記
Red Hat では、特に理由がない限り、少なくとも少なくとも swap、/boot/、および / (root) のパー ティションを作成することが推奨されます。 パーティションの最大サイズ パーティションの最大サイズ デバイスのパーティションの最大サイズは、パーティションテーブルの種類により異なります。 マスターブートレコード マスターブートレコード (MBR) パーティションテーブルでフォーマットしたデバイスの最大サ イズは 2TiB になります。 GUID パーティションテーブルパーティションテーブル (GPT) でフォーマットしたデバイスの最大サイズは 8ZiB にな ります。 2TiB を超えるパーティションを作成する場合は、ディスクを GPT でフォーマットする必要がありま す。 サイズ調整 サイズ調整 parted ユーティリティーを使用した場合は、パーティションサイズを指定する際の接尾辞を選択でき ます。
MiB、、GiB、または、または TiB
サイズは 2 のべき乗で表示されます。
パーティションの開始点は、サイズが指定する正確なセクターに調整されます。 終了点は、指定されたサイズから 1 セクターを引いたサイズに調整されます。 MB、、GB、または、または TB
開始点と終了点は、指定された単位の半分以内に置かれます。たとえば、接尾辞 MB を使用する場 合は ±500 KB です。
3.2.2. パーティションテーブルの種類の比較
このセクションでは、ブロックデバイスに作成できるさまざまな種類のパーティションテーブルのプロ パティーを比較します。 表 表3.1 パーティションテーブルの種類パーティションテーブルの種類 パーティションテーブル パーティションテーブル パーティションの最大数パーティションの最大数 パーティションの最大サイズパーティションの最大サイズ マスターブートレコード (MBR) 4 つのプライマリー。または 3 つ のプライマリーと、拡張パーティ ション内に 12 の論理 2TiB GUID パーティションテーブル (GPT) 128 8ZiB3.2.3. MBR ディスクパーティション
本章の図では、パーティションテーブルが実際のディスクから分離されていることを示しています。た だし、これは完全に正確ではありません。実際には、パーティションテーブルは、ファイルシステムま たはユーザーデータの前のディスクの先頭に保管されますが、明確にするために以下の図で区切りま す。 図 図3.1 MBR パーティションテーブルがあるディスクパーティションテーブルがあるディスクDisk (MBR table)
Unused partition
Unused partition
上記の図で示したとおり、パーティションテーブルは 4 つのプライマリーパーティションの 4 つのセク ションに分けられます。プライマリーパーティションは、論理ドライブ (またはセクション) を 1 つだけ 含むことができるハードドライブのパーティションです。各セクションは、1 つのパーティションの定 義に必要な情報を保持できます。つまり、パーティションテーブルでは 4 つのパーティションを定義で きません。 各パーティションテーブルエントリーには、パーティションの重要な特徴がいくつか含まれています。 パーティションが開始して終了するディスク上のポイント。 パーティションが アクティブアクティブ であるかどうか。アクティブアクティブ としてフラグを付けることができ るパーティションは 1 つだけです。 パーティションのタイプ。
開始点と終了点は、パーティションのサイズとディスク上の場所を定義します。「active」フラグは、 一部のオペレーティングシステムブートローダーで使用されます。つまり、「active」とマークされて いるパーティションのオペレーティングシステムが起動します。 タイプは、パーティションの想定される使用方法を特定する数字です。一部のオペレーティングシステ ムでは、パーティションの種類を使用して特定のファイルシステムの種類を示し、特定のオペレーティ ングシステムに関連付けられていることを示すフラグを付け、パーティションに起動可能なオペレー ティングシステムが含まれていること、またはその 3 つの組み合わせを示します。 以下の図は、パーティションが 1 つあるドライブの例を示しています。 図 図3.2 1 つのパーティションを持つディスクつのパーティションを持つディスク
Disk (MBR table)
Primary partition
(DOS)
Unused partition
この例の 1 つのパーティションには、DOS というラベルが付けられています。このラベルはパーティ ションタイプを表示し、DOS は最も一般的なパーティションタイプです。
3.2.4. 拡張 MBR パーティション
4 つのパーティションがニーズに十分ではない場合は、拡張パーティションを使用して追加のパーティ ションを作成できます。これは、パーティションのタイプを「拡張」に設定することで実行できます。 拡張パーティションは、それ自体がディスクドライブのようなものです。拡張パーティション自体に完 全に含まれる、1 つ以上のパーティション (4 つのプライマリパーティションではなく、現在は論理パー ティションと呼ばれます) を指す独自のパーティションテーブルがあります。次の図は、1 つのプライマ リパーティションと、2 つの論理パーティションを含む 1 つの拡張パーティション (およびいくつかの未 パーティションの空き領域) を備えたディスクドライブを示しています。 図 図3.3 プライマリーパーティションと拡張プライマリーパーティションと拡張 MBR パーティションの両方を備えたディスクパーティションの両方を備えたディスクDisk (MBR table)
Primary partition
(DOS)
Primary partition
(Linux native)
この図は示すように、プライマリーパーティションと論理パーティションには違いがあります。最大 4 つのプライマリーパーティションと拡張パーティションしか存在できませんが、存在できる論理パー ティションの数には固定制限がありません。ただし、Linux でパーティションにアクセスする方法によ り、1 つのディスクドライブで 15 を超える論理パーティションを定義することはできません。
3.2.5. MBR パーティションタイプ
次の表は、一般的に使用される MBR パーティションタイプとそれらを表すために使用される 16 進数の リストです。 表 表3.2 MBR パーティションタイプパーティションタイプ MBR パーティションタパーティションタ イプ イプ 値 値 MBR パーティションタパーティションタ イプ イプ 値 値 Empty 00 Novell Netware 386 65 DOS 12 ビット FAT 01 PIC/IX 75 XENIX root O2 旧 MINIX 80 XENIX usr O3 Linux/MINUX 81 DOS 16 ビット (32M 以 下) 04 Linux swap 82 Extended 05 Linux ネイティブ 83 DOS 16 ビット (32 以上) 06 Linux 拡張 85 OS/2 HPFS 07 Amoeba 93 AIX 08 Amoeba BBT 94 AIX ブート可能 09 BSD/386 a5 OS/2 Boot Manager 0a OpenBSD a6 Win95 FAT32 0b NEXTSTEP a7 Win95 FAT32 (LBA) 0c BSDI fs b7 Win95 FAT16 (LBA) 0e BSDI swap b8 Win95 Extended (LBA) 0f Syrinx c7 Venix 80286 40 CP/M db Novell 51 DOS アクセス e1 PRep Boot 41 DOS R/O e3 GNU HURD 63 DOS セカンダリー f2Novell Netware 286 64 BBT ff
3.2.6. GUID パーティションテーブル
GUID パーティションテーブル (GPT) は、Globally Unique Identifier (GUID) を使用したパーティション 設定スキームです。GPT は、特にディスクのアドレス可能な最大ストレージ容量に制限されている MBR パーティションテーブルの制限に対応するために開発されました。MBR とは異なり、2 TiB (約 2.2 TB に相当) を超えるストレージに対応できません。GPT はこれよりも大きなハードディスクで使用 されます。アドレス可能な最大ディスクサイズは 2.2 ZiB です。また、デフォルトでは GPT は、最大 128 のプライマリーパーティションの作成に対応します。この数は、パーティションテーブルにより多 くの領域を割り当てることで拡張できます。
注記
注記
GPT には GUID に基づくパーティションタイプがあります。特定のパーティションには 特定の GUID が必要なことに注意してください。たとえば、EFI ブートローダーのシステ ムパーティションには GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B が必要で す。 GPT ディスクは論理ブロックアドレス設定 (LBA) を使用し、パーティションレイアウトは以下のよう になります。 MBR ディスクとの後方互換性を維持するために、GPT の最初のセクター (LBA 0) は MBR デー タ用に予約され、「保護 MBR」と呼ばれます。 プライマリー GPT ヘッダーは、デバイスの 2 番目の論理ブロック (LBA 1) から開始します。 ヘッダーには、ディスク GUID、プライマリーパーティションテーブルの場所、セカンダリ GPT ヘッダーの場所、および CRC32 チェックサム、およびプライマリーパーティションテー ブルが含まれます。また、テーブルにあるパーティションエントリーの数も指定します。 プライマリー GPT には、デフォルトの 128 パーティションエントリーがあり、それぞれエント リーサイズは 128 バイトで、パーティションタイプ GUID と一意のパーティション GUID が含 まれます。 セカンダリー GPT はプライマリー GPT と同じです。これは、プライマリーパーティション テーブルが破損した場合に、リカバリーのバックアップテーブルとして主に使用されます。 セカンダリー GPT ヘッダーは、ディスクの最後の論理セクターにあり、プライマリーヘッダー が破損した場合に GPT 情報を復元するために使用できます。これには、ディスク GUID、セカ ンダリーパーティションテーブルとプライマリー GPT ヘッダーの場所、それ自体とセカンダ リーパーティションテーブルの CRC32 チェックサム、および可能なパーティションエント リーの数が含まれています。 図 図3.4 GUID パーティションテーブルを含むディスクパーティションテーブルを含むディスク図
図3.4 GUID パーティションテーブルを含むディスクパーティションテーブルを含むディスク
Disk (GPT table)
GPT partition
(GUID: basic data)
File system
(FAT32)
GPT partition
(GUID: root)
重要
重要
GPT (GUIDパーティションテーブル) を含むディスクにブートローダーを正常にインス トールするには、BIOS ブートパーティションが必要です。これには、Anaconda によっ て初期化されるディスクが含まれます。ディスクに BIOS ブートパーティションがすで に含まれている場合は、再使用できます。3.2.7. parted でディスクにパーティションテーブルを作成
この手順では、parted ユーティリティーを使用するパーティションテーブルでブロックデバイスを フォーマットする方法を説明します。 手順 手順 1. インタラクティブな parted シェルを起動します。 # parted block-device block-device を、パーティションテーブルを作成するデバイスへのパス (例: /dev/sda) に 置き換えます。 2. デバイスにパーティションテーブルがあるかどうかを確認します。 (parted) print デバイスにパーティションが含まれている場合は、次の手順でパーティションを削除します。 3. 新しいパーティションテーブルを作成します。(parted) mklabel table-type
table-type を、使用するパーティションテーブルの種類に置き換えます。 msdo (MBR の場合) gpt (GPT の場合) 例 例3.2 GPT テーブルの作成テーブルの作成 たとえば、ディスクに GPT テーブルを作成するには、次のコマンドを使用します。
