Red Hat Enterprise Linux 7 · 2020-03-16 · 1.1. red hat enterprise linux 7 の新機能と拡張パートi ルルシステテム第2章ファイルテムの構造造メンテナナン

Red Hat Enterprise Linux 7

ストレージ管理ガイド

RHEL 7 における 1 ノードストレージの導入および設定

Last Updated: 2020-03-16

Red Hat Enterprise Linux 7 ストレージ管理ガイド

RHEL 7 における 1 ノードストレージの導入および設定

Milan NavrátilRed Hat Customer Content Services

Jacquelynn EastRed Hat Customer Content Services

Don DomingoRed Hat Customer Content Services

Josef BacikServer Development Kernel File [email protected]ディスク割り当て

Kamil DudkaBase Operating System Core Services - [email protected]アクセス制御リスト

Hans de GoedeBase Operating System [email protected]パーティション

Harald HoyerEngineering Software [email protected]ファイルシステム

Dennis KeefeBase Operating Systems Kernel [email protected]

Doug LedfordServer Development Hardware [email protected]

Daniel NovotnyBase Operating System Core Services - [email protected]/proc ファイルシステム

Nathan Straz

Quality Engineering QE - [email protected]

Andy WalshBase Operating Systems Kernel [email protected]

David WysochanskiServer Development Kernel [email protected]/LVM2

Michael ChristieServer Development Kernel [email protected]オンラインストレージ

Sachin PrabhuSoftware Maintenance エンジニアリング[email protected]

Rob EversServer Development Kernel [email protected]オンラインストレージ

David HowellsServer Development Hardware [email protected]

David LehmanBase Operating System [email protected]インストール時のストレージ設定

Jeff MoyerServer Development Kernel File [email protected]ソリッドステートディスク

Eric SandeenServer Development Kernel File [email protected]、ext4、XFS、暗号化ファイルシステム

法律上の通知法律上の通知

Copyright © 2018 Red Hat, Inc.

This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0Unported License. If you distribute this document, or a modified version of it, you must provideattribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hattrademarks must be removed.

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 Statesand 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 Statesand/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union andother countries.

Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by theofficial Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marksor trademarks/service marks of the OpenStack Foundation, in the United States and othercountries 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 Enterprise Linux 7 でストレージデバイスおよびファイルシステムを効果的に管理する方法を説明します。本ガイドは、Red Hat Enterprise Linux または Fedora について、基礎から中級レベルの知識をお持ちのシステム管理者を対象にしています。

http://creativecommons.org/licenses/by-sa/3.0/

Mike SnitzerServer Development Kernel [email protected]/O スタックと制限

Red Hat Subject Matter Experts

Contributors

編集者編集者

Marek SuchánekRed Hat Customer Content [email protected]

Apurva BhideRed Hat Customer Content [email protected]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

目次目次

第第1章章概要概要1.1. RED HAT ENTERPRISE LINUX 7 の新機能と拡張

パートパート I. ファイルシステムファイルシステム

第第2章章ファイルシステムの構造およびメンテナンスファイルシステムの構造およびメンテナンス2.1. ファイルシステム階層標準 (FHS) の概要2.2. 特殊な RED HAT ENTERPRISE LINUX ファイルの場所2.3. /PROC 仮想ファイルシステム2.4. 未使用ブロックの破棄

第第3章章 XFS ファイルシステムファイルシステム3.1. XFS ファイルシステムの作成3.2. XFS ファイルシステムのマウント3.3. XFS クォータの管理3.4. XFS ファイルシステムのサイズの拡大3.5. XFS ファイルシステムの修復3.6. XFS ファイルシステムの一時停止3.7. XFS ファイルシステムのバックアップと復元3.8. エラー動作の設定3.9. XFS ファイルシステムのその他のユーティリティー3.10. EXT4 から XFS への移行

第第4章章 EXT3 ファイルシステムファイルシステム4.1. EXT3 ファイルシステムの作成4.2. EXT3 ファイルシステムへの変換4.3. EXT2 ファイルシステムに戻す

第第5章章 EX4 ファイルシステムファイルシステム5.1. EXT4 ファイルシステムの作成5.2. EXT4 ファイルシステムのマウント5.3. EXT4 ファイルシステムのサイズ変更5.4. EXT2、EXT3、EXT4 のファイルシステムのデバッグを行います。5.5. EXT2、EXT3、EXT4 のファイルシステムの復元5.6. EXT4 ファイルシステムのその他のユーティリティー

第第6章章 BTRFS (テクノロジープレビューテクノロジープレビュー)6.1. BTRFS ファイルシステムの作成6.2. BTRFS ファイルシステムのマウント6.3. BTRFS ファイルシステムのサイズ変更6.4. 複数デバイスの統合ボリューム管理6.5. SSD の最適化6.6. BTRFS の参考資料

第第7章章 GLOBAL FILE SYSTEM 2

第第8章章 NETWORK FILE SYSTEM (NFS)8.1. NFS の概要8.2. NFS クライアントの設定8.3. AUTOFS8.4. 一般的な NFS マウントオプション8.5. NFS サーバーの起動と停止8.6. NFS サーバーの設定

77

9

1010181819

2021222325262627303233

37383839

41424445454749

51515152555959

61

62626567737475

目次目次

1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.7. NFS のセキュア化8.8. NFS と RPCBIND8.9. PNFS8.10. NFS で PNFS SCSI レイアウトを有効にする8.11. NFS リファレンス

第第9章章サーバーメッセージブロックサーバーメッセージブロック (SMB)9.1. SMB 共有の使用9.2. SMB 共有のマウント

第第10章章 FS-CACHE10.1. 性能に関する保証10.2. キャッシュの設定10.3. NFS でのキャッシュの使用10.4. キャッシュの間引き制限 (CACHE CULL) の設定10.5. 統計情報10.6. FS-CACHE リファレンス

パートパート II. ストレージ管理ストレージ管理

第第11章章ストレージをインストールする際の注意点ストレージをインストールする際の注意点11.1. 特に注意を要する事項について

第第12章章ファイルシステムのチェックファイルシステムのチェック12.1. FSCK のベストプラクティス12.2. FSCK に関するファイルシステム固有の情報

第第13章章パーティションパーティション使用中のデバイス上でのパーティションの操作パーティションテーブルの変更13.1. パーティションテーブルの表示13.2. パーティションの作成13.3. パーティションの削除13.4. パーティションタイプの設定13.5. FDISK を使用したパーティションのサイズ変更

第第14章章 SNAPPER を用いたスナップショットの作成および維持を用いたスナップショットの作成および維持14.1. 初期 SNAPPER 設定の作成14.2. SNAPPER スナップショットの作成14.3. SNAPPER スナップショット間の変更の追跡14.4. スナップショット間の変更の取り消し14.5. SNAPPER スナップショットの削除

第第15章章 SWAP領域領域15.1. SWAP 領域の追加15.2. SWAP 領域の削除15.3. SWAP 領域の移動

第第16章章 SYSTEM STORAGE MANAGER (SSM)16.1. SSM バックエンド16.2. 一般的な SSM タスク16.3. SSM のリソース

第第17章章ディスク割り当てディスク割り当て17.1. ディスククォータの設定17.2. ディスククォータの管理

8487888994

969696

102103103105106107107

109

110110

113113114

118118118119121

124125125

128128129132136137

138139141

143

144144146153

154154159

ストレージ管理ガイドストレージ管理ガイド

2

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17.3. ディスククオータのリファレンス

第第18章章 RAID (REDUNDANT ARRAY OF INDEPENDENT DISKS)18.1. RAID のタイプ18.2. RAID レベルとリニアサポート18.3. LINUX RAID サブシステム18.4. ANACONDA インストーラーの RIAD サポート18.5. インストール後のルートディスクの RAID1 への変換18.6. RAID セットの設定18.7. 高度な RAID デバイスの作成

第第19章章 MOUNT コマンドの使い方コマンドの使い方19.1. 現在マウントされているファイルシステムの一覧表示19.2. ファイルシステムのマウント19.3. ファイルシステムのアンマウント19.4. MOUNT コマンドのリファレンス

第第20章章 VOLUME_KEY 機能機能20.1. VOLUME_KEY コマンド20.2. VOLUME_KEY の個人ユーザーとしての使用20.3. 規模の大きな組織での VOLUME_KEY の使用20.4. VOLUME_KEY のリファレンス

第第21章章ソリッドステートディスクの導入ガイドラインソリッドステートディスクの導入ガイドライン導入に関する考慮事項パフォーマンスチューニングに関する注意点

第第22章章書き込みバリア書き込みバリア22.1. 書き込みバリアの重要性22.2. 書き込みバリアの有効化と無効化22.3. 書き込みバリアに関する注意点

第第23章章ストレージのストレージの I/O 調整とサイズ調整とサイズ23.1. ストレージアクセス用のパラメーター23.2. ユーザー領域のアクセス23.3. I/O 規格23.4. 入出力パラメーターのスタック23.5. 論理ボリュームマネージャー23.6. パーティションとファイルシステムのツール

第第24章章リモートディスクレスシステムの設定リモートディスクレスシステムの設定24.1. ディスクレスクライアントの TFTP サービスの設定24.2. ディスクレスクライアントの DHCP の設定24.3. ディスクレスクライアントのエクスポートしたファイルシステムの設定

第第25章章オンラインストレージ管理オンラインストレージ管理25.1. ターゲットの設定25.2. ISCSI イニシエーターの作成25.3. チャレンジハンドシェイク認証プロトコルの設定25.4. ファイバーチャネル25.5. ファイバーチャネルオーバーイーサネットインターフェースの設定25.6. 起動時に FCOE インターフェースを自動マウントする設定25.7. ISCSI25.8. 永続的な命名25.9. ストレージデバイスの削除

162

163163164166167167168168

170170171

180181

182182183184186

187187189

190190190191

193193194195196196197

199199

200201

203203212214215217219

220221

226

目次目次

3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25.10. ストレージデバイスへのパスの削除25.11. ストレージデバイスまたはパスの追加25.12. ストレージの相互接続のスキャン25.13. ISCSI 検出の設定25.14. ISCSI オフロードとインターフェースバインディングの設定25.15. ISCSI 相互接続のスキャン25.16. ISCSI ターゲットへのログイン25.17. オンライン論理ユニットのサイズ変更25.18. RESCAN-SCSI-BUS.SH による論理ユニットの追加と削除25.19. リンク切れ動作の修正25.20. SCSI コマンドタイマーとデバイス状態の制御25.21. オンラインストレージ設定のトラブルシューティング25.22. EH_DEADLINE を使用したエラーからの回復における最大時間の設定

第第26章章 DEVICE MAPPER を使ったマルチパス設定を使ったマルチパス設定 (DM MULTIPATH) と仮想マシン用ストレージと仮想マシン用ストレージ26.1. 仮想マシン用のストレージ26.2. DM MULTIPATH

第第27章章外部アレイ管理外部アレイ管理 (LIBSTORAGEMGMT)27.1. LIBSTORAGEMGMT 導入27.2. LIBSTORAGEMGMT 用語27.3. LIBSTORAGEMGMT のインストール27.4. USING LIBSTORAGEMGMT の使用

第第28章章永続メモリー永続メモリー: NVDIMMNVDIMMs インターリービング永続メモリーアクセスモード28.1. NDCTL による永続メモリー設定28.2. ブロックデバイスとして使用するために永続メモリーを設定する (レガシーモード)28.3. ファイルシステムダイレクトアクセス用の永続メモリーの設定28.4. デバイス DAX モードで使用するために永続メモリーの設定28.5. NVDIMM のトラブルシューティング

パートパート III. VDO によるデータの重複排除と圧縮によるデータの重複排除と圧縮

第第29章章 VDO 統合統合29.1. VDO の論理概要29.2. システム要件29.3. VDO の使用29.4. VDO の管理29.5. ディプロイメントシナリオ29.6. VOD のチューニング29.7. VDO コマンド29.8. /SYS の統計ファイル

第第30章章 VOD 評価評価30.1. はじめに30.2. テスト環境の準備30.3. データ効率のテスト手順30.4. パフォーマンステスト手順30.5. 問題の報告30.6. 結論

付録付録A ストレージ管理に関するストレージ管理に関する RED HAT CUSTOMER PORTAL LABSSCSI DECODER

227228230231231

236238239242243246247248

250250250

252252253255256

260260261261

264264265266

271

272272275279283292294300318

320320321

324333338338

339339


4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

FILE SYSTEM LAYOUT CALCULATORLVM RAID CALCULATORISCSI HELPERSAMBA CONFIGURATION HELPERMULTIPATH HELPERNFS HELPERMULTIPATH CONFIGURATION VISUALIZERRHEL BACKUP AND RESTORE ASSISTANT

付録付録B 改訂履歴改訂履歴

索引索引

339339339339339340340340

341

343

目次目次

5


6

第1章概要『ストレージ管理ガイド』では、Red Hat Enterprise Linux 7 で対応しているファイルシステムやデータストレージの機能を詳細に解説しています。本ガイドは管理者が単一のノード (クラスター化していない状態) でストレージソリューションを管理する場合に簡単に参照できるように構成されています。

ストレージ管理ガイドは、「ファイルシステム」、「ストレージ管理」、「VDO によるデータの重複排除と圧縮」というセクションに分割されています。

「ファイルシステム」では、Red Hat Enterprise Linux 7 がサポートするさまざまなファイルシステムについて説明します。まず、ファイルシステムの最適な使用方法について説明していきます。

「ストレージ管理」では、Red Hat Enterprise Linux 7 が対応している様々なツールやストレージ管理タスクについて説明します。対応ツールやストレージ管理タスクについて説明し、これらの最適な使用方法について説明します。

「VDO によるデータの重複排除と圧縮」では、仮想データオプティマイザー (VDO) について説明しています。ここでは、ストレージ要件を低減させるために VDO を使用する方法を説明しています。

1.1. RED HAT ENTERPRISE LINUX 7 の新機能と拡張

Red Hat Enterprise Linux 7 は、以下のファイルシステムの拡張機能を特長としています。

eCryptfs は含まれない

Red Hat Enterprise Linux 7 には eCryptfs は含まれません。ファイルの暗号化の詳細は、Red Hat のセキュリティガイドを参照してください。

System Storage Manager

Red Hat Enterprise Linux 7 には、System Storage Manager という新規アプリケーションが含まれます。これは、複数のストレージテクノロジーを管理するコマンドラインインターフェースを提供します。詳細は、16章System Storage Manager (SSM)を参照してください。

デフォルトファイルシステムとしての XFS

Red Hat Enterprise Linux 7 では、XFS はデフォルトのファイルシステムです。XFS ファイルシステムの詳細は、3章XFS ファイルシステムを参照してください。

ファイルシステムの再編成

Red Hat Enterprise Linux 7 は、新たなファイルシステム構造を導入しています。ディレクトリーの /bin、/sbin、/lib、および /lib64 は /usr の下にネスト化されます。

Snapper

Red Hat Enterprise Linux 7 では、Snapper と呼ばれる新規ツールを導入し、LVM および Btrfs のスナップショットを簡単に作成し、管理できるようになりました。詳細は、14章Snapper を用いたスナップショットの作成および維持を参照してください。

Btrfs (テクノロジープレビュー)

注記注記

第第1章章概要概要

7

注記注記

Red Hat Enterprise Linux 7 では、Btrfs をテクノロジープレビュー機能として利用できますが、Red Hat Enterprise Linux 7.4 リリース以降に廃止されました。これは、Red HatEnterprise Linux の今後のメジャーリリースで削除されます。

詳細は、Red Hat Enterprise Linux 7.4 リリースノートの「Deprecated Functionality」を参照してください。

Btrfs は、統合された LVM 操作を含む、より良いパフォーマンスと拡張性を提供することを目的としたローカルのファイルシステムです。このファイルシステムは、Red Hat では完全にサポートされていないため、テクノロジープレビューになっています。Btrfs の詳細は、6章Btrfs (テクノロジープレビュー)を参照してください。

NFSv2 はサポート対象外

Red Hat Enterprise Linux 7 では、NFSv2 はサポート対象外になりました。


8

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html

パート I. ファイルシステム

「ファイルシステム」セクションでは、ファイルシステムの構造および保守、Btrfs テクノリジープレビュー、および Red Hat が完全にサポートするファイルシステム (ext3、ext4、GFS2、XFS、NFS、および FS-Cache) に関する情報を提供します。

注記注記



Red Hat Enterprise Linux のファイルシステムやストレージの制限に関する概要は、Red Hat ナレッジベース「Red Hat Enterprise Linux テクノロジの機能と制限」を参照してください。

XFS は、Red Hat Enterprise Linux 7、および Red Hat におけるデフォルトのファイルシステムです。他のファイルシステムを使用する強い動機がある場合を除いて、XFS を使用することが推奨されます。一般的なファイルシステムとそのプロパティーに関する一般的な情報は、Red Hat ナレッジベースの記事「How to Choose your Red Hat Enterprise Linux File System 」を参照してください。

パートパート I. ファイルシステムファイルシステム

9


https://access.redhat.com/ja/articles/1271503

https://access.redhat.com/articles/3129891

第2章ファイルシステムの構造およびメンテナンスファイルシステムの構造は、オペレーティングシステムにおける最も基本的な体系です。オペレーティングシステムがユーザー、アプリケーション、およびセキュリティーモデルと相互作用する方法は、オペレーティングシステムがストレージデバイス上のファイルをどのように編成しているかによってほぼ決まります。共通のファイルシステム構造を提供することで、ユーザーとプログラムが確実にファイルにアクセスして書き込みを実行できるようにします。

ファイルシステムは、ファイルを以下の 2 つの論理カテゴリーに分けます。

共有可のファイルと共有不可のファイル共有可のファイルと共有不可のファイル

共有可能ファイルはローカルにアクセスでき、リモートホストからアクセスできます。共有不可能ファイルは、ローカルでのみ利用できます。

可変ファイルと静的ファイル可変ファイルと静的ファイル

文書などの可変ファイルは、いつでも変更できます。バイナリーなどの静的ファイルは、システム管理者の操作なしで変更できます。

このようにファイルをカテゴリー別に分類すると、各ファイルの機能と、それらのファイルを含むディレクトリーに割り当てられた権限を関連付けるのに役立ちます。オペレーティングシステムとそのユーザーがどのようにファイルと相互作用するかによって、ファイルの置かれるディレクトリーの設定が決定されます。たとえば、そのディレクトリーを読み込み専用か、または読み込み/書き込み権限でマウントするか、もしくは各ユーザーがそのファイルに対してどのようなアクセスレベルを持つかが決定されます。この体系の最上位レベルが重要になり、その下にあるディレクトリーへのアクセスが制限されます。最上位レベルから下位にわたってアクセスルールが準拠されないと、セキュリティー上の問題が発生する可能性があります。

2.1. ファイルシステム階層標準 (FHS) の概要

Red Hat Enterprise Linux は、ファイルシステム階層標準：Filesystem Hierarchy Standard (FHS) のファイルシステム構造を使用します。これは、多くのファイルタイプとディレクトリーの名前、場所、および権限を定義します。

FHS ドキュメントは、FHS 準拠のファイルシステムに対する権威のあるリファレンスですが、この標準では定義していない、または拡張可能な分野が数多く残されています。このセクションでは、この標準の概要を説明し、この標準で扱われていないファイルシステムの他の部分について説明します。

FHS 準拠によってもたらされる最も重要な要素は以下の 2 点にまとめられます。

FHS 準拠の他のシステムとの互換性

/usr/ パーティションを読み込み専用でマウントできること。/usr/ には共通の実行可能ファイルが含まれており、ユーザーがこのパーティションを変更することができないため、この点は重要になります。さらに、/usr/ は読み込み専用でマウントされるため、CD-ROM ドライブから、または読み込み専用の NFS マウント経由で他のマシンからマウントすることができます。

2.1.1. FHS の組織

ここで言及したディレクトリーやファイルは、FHS　ドキュメントで指定されている小さなサブセットです。完全な情報の多くは、http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf の最新の FHS ドキュメンテーションを参照してください。file-hierarchy(7) man ページでも概要を参照できます。

注記注記


10

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf

注記注記

どのディレクトリーが利用可能であるかは、所定のシステムに何がインストールされているかによって異なります。以下の一覧は、インストールされている内容の一例に過ぎません。

2.1.1.1. ファイルシステム情報の収集ファイルシステム情報の収集

df コマンドコマンド

df コマンドは、システムのディスク領域の使用量を報告します。出力は以下のようになります。

例例2.1 df コマンド出力コマンド出力

Filesystem 1K-blocks Used Available Use% Mounted on/dev/mapper/VolGroup00-LogVol00 11675568 6272120 4810348 57% / /dev/sda1 100691 9281 86211 10% /bootnone 322856 0 322856 0% /dev/shm

デフォルトで、df はパーティションサイズを 1 キロバイトのブロック単位で示し、使用中/利用可能のディスク領域の容量をキロバイトで示します。この情報をメガバイトやギガバイトで表示するには、コマンド df -h を使用します。-h という引数は "human-readable (人に認識可能な)" 形式という意味です。df -h の出力は以下のようになります。

例例2.2 df -h コマンドの出力コマンドの出力

Filesystem Size Used Avail Use% Mounted on/dev/mapper/VolGroup00-LogVol00 12G 6.0G 4.6G 57% / /dev/sda1 99M 9.1M 85M 10% /bootnone 316M 0 316M 0% /dev/shm

注記注記

上記の例で、マウント済みのパーティション /dev/shm は、システムの仮想メモリーファイルシステムを表します。

du コマンドコマンド

du コマンドは、ディレクトリー内のファイルによって使用されている領域の概算を示すもので、各サブディレクトリーのディスク使用量を表示します。du の出力の最後の行はディレクトリーの合計ディスク使用量を表示します。ディレクトリーの合計ディスク使用量を人間が認識できる形式でのみ表示するには、du -hs を使用します。他のオプションについては、man du を参照してください。

Gnome システムモニターシステムモニター

システムのパーティションとディスク領域の使用状況をグラフィカル形式で表示するには、アプリケーアプリケーションション → システムツールシステムツール → システムモニターシステムモニターを順にクリックするか、またはコマンド gmnoe-system-monitor を使用して、Gnome システムモニターシステムモニターを使用します。ファイルシステムファイルシステムタブを選択

第第2章章ファイルシステムの構造およびメンテナンスファイルシステムの構造およびメンテナンス

11

すると、システムのパーティションが表示されます。以下の図は、ファイルシステムファイルシステムタブを示しています。

図図2.1 Gnome システムモニター内のファイルシステムタブシステムモニター内のファイルシステムタブ

2.1.1.2. /boot/ ディレクトリーディレクトリー

/boot/ ディレクトリーには、システムを起動するために必要な Linux カーネルなどの静的ファイルが含まれます。これらのファイルはシステムが正常に起動するために不可欠です。

警告警告

/boot/ ディレクトリーを削除しないでください。削除するとシステムを起動できなくなります。

2.1.1.3. /dev/ ディレクトリーディレクトリー

/dev/ ディレクトリーには、以下のデバイスタイプを表すデバイスノードが含まれます。

システムに接続しているデバイス

カーネルで提供される仮想デバイス

これらのデバイスノードはシステムが正常に機能するために不可欠です。udevd デーモンは、必要に応


12

これらのデバイスノードはシステムが正常に機能するために不可欠です。udevd デーモンは、必要に応じて /dev/ 内でデバイスノードを作成したり削除したりします。

/dev/ ディレクトリーとサブディレクトリー内のデバイスは、キャラクターキャラクター (マウスやキーボードなどの、シリアルストリームの入出力のみを提供) か、またはブロックブロック (ハードドライブやフロッピーなど、ランダムにアクセス可能なデバイス) のいずれかです。GNOME または KDE をインストールしている場合、一部のストレージデバイスは接続時 (例: USB を使用) や挿入時 (例: CD や DVD ドライブを使用) で自動的に検出されて、ポップアップウィンドウがそのコンテンツを表示します。

表表2.1 /dev ディレクトリー内にある共通ファイルの例ディレクトリー内にある共通ファイルの例

ファイルファイル説明説明

/dev/hda プライマリー IDE チャネル上のマスターデバイス

/dev/hdb プライマリー IDE チャネル上のスレーブデバイス

/dev/tty0 1 番目の仮想コンソール

/dev/tty1 2 番目の仮想コンソール

/dev/sda プライマリー SCSI または SATA チャネル上の 1 番目のデバイス

/dev/lp0 １番目のパラレルポート

有効なブロックデバイスは、以下の 2 つのタイプのエントリーのいずれかになります。

マッピングされたデバイスマッピングされたデバイス

ボリュームグループ内の論理ボリューム、例: /dev/mapper/VolGroup00-LogVol02

静的なデバイス静的なデバイス

従来のストレージボリューム。たとえば、/dev/sdbX。sdb はストレージデバイス名、X はパーティション番号になります。/dev/sdbX は、/dev/disk/by-id/WWID または /dev/disk/by-uuid/UUID になる場合があります。詳細は「永続的な命名」を参照してください。

2.1.1.4. /etc/ ディレクトリーディレクトリー

/etc/ ディレクトリーは、マシンに対してローカルな設定ファイル用に確保されています。バイナリーを含めるべきではないので、バイナリーがある場合は、/usr/bin/ または /usr/sbin/ に移動します。

たとえば、/etc/skel/ ディレクトリーは、「スケルトン」ユーザーファイルを保管しますが、このファイルは、最初にユーザーを作成する際にホームディレクトリーに追加するために使用されます。アプリケーションもこのディレクトリーにその設定ファイルを保存して実行時にそれを参照します。/etc/exports ファイルはリモートホストにエクスポートするファイルシステムを制御します。

2.1.1.5. /mnt/ ディレクトリーディレクトリー

/mnt/ ディレクトリーは、NFS ファイルシステムマウントなど、一時的にマウントされたファイルシステムのために確保されます。すべてのリムーバブルストレージメディアには、/media/ ディレクトリーを使用します。自動的に検出されたリムーバブルメディアは /media ディレクトリーにマウントされま


13

す。

重要重要

/mnt ディレクトリーはインストールプログラムで使用することはできません。

2.1.1.6. /opt/ ディレクトリーディレクトリー

/opt/ ディレクトリーは、通常デフォルトインストールの一部ではないソフトウェアやアドオンパッケージ用に確保されています。/opt/ にインストールするパッケージは、名前がそのパッケージと同じディレクトリーを作成します (例: /opt/パッケージ名パッケージ名/)。ほとんどの場合、そのようなパッケージは予想可能なサブディレクトリー構造に従って、ほとんどがそのバイナリーを /opt/パッケージ名パッケージ名/bin/ に保存し、それらの man ページを /opt/パッケージ名パッケージ名/man/ に保存します。

2.1.1.7. /proc/ ディレクトリーディレクトリー

/proc/ ディレクトリーは、カーネルから情報を抽出するか、またはカーネルに情報を送る特別なファイルを収納しています。その情報の例としては、システムメモリー、cpu 情報、およびハードウェア設定などがあります。/proc/ の詳細については、「/proc 仮想ファイルシステム」を参照してください。

2.1.1.8. /srv/ ディレクトリーディレクトリー

/srv/ ディレクトリーには、Red Hat Enterprise Linux システムが提供するサイト特有のデータが含まれています。このディレクトリーは、ユーザーに対して FTP、WWW、または CVS などの特定のサービス用のデータファイルの場所を提供します。特定ユーザーにのみ関連するデータは /home/ ディレクトリーに置く必要があります。

2.1.1.9. /sys/ ディレクトリーディレクトリー

/sys/ ディレクトリーは、カーネルに固有の新しい sysfs 仮想ファイルシステムを使用します。カーネルのホットプラグハードウェアデバイスに対するサポートの強化により、/sys/ ディレクトリーは、/proc/ で保管されている情報に似た情報を格納し、ホットプラグデバイス固有のデバイス情報を階層表示で示します。

2.1.1.10. /usr/ ディレクトリーディレクトリー

/usr/ ディレクトリーは、複数マシンで共有されるファイル用に使われます。/usr/ ディレクトリーは多くの場合、独自のパーティション上に置かれ、読み込み専用でマウントされます。/usr/ には少なくとも以下のサブディレクトリーが含まれます。

/usr/bin

このディレクトリーはバイナリー用に使用されます。

/usr/etc

このディレクトリーは、システム全体の設定ファイル用に使用されます。

/usr/games

このディレクトリーはゲームを保管します。

/usr/include

このディレクトリーは C ヘッダーファイル用に使用されます。


14

/usr/kerberos

このディレクトリーは、Kerberos 関連のバイナリーとファイル用に使用されます。

/usr/lib

このディレクトリーは、シェルスクリプトやユーザーに直接利用されるように設計されていないオブジェクトファイルとライブラリー用に使用されます。

Red Hat Enterprise Linux 7.0 では、/lib/ ディレクトリーは /usr/lib にマージされています。このディレクトリーには、/usr/bin/ および /usr/sbin/ のバイナリーを実行するために必要なライブラリーが収納されています。これらの共有ライブラリーイメージは、システムを起動したり root ファイルシステム内でコマンドを実行したりするために使用されます。

/usr/libexec

このディレクトリーには、他のプログラムから呼び出される、小さなヘルパープログラムが収納されています。

/usr/sbin

Red Hat Enterprise Linux 7.0 では、/sbin は /usr/sbin に移動しました。このディレクトリーにはシステムの起動、復元、または修復に不可欠なバイナリーを含むシステム管理バイナリーがすべて含まれます。/usr/sbin/ のバイナリーを使用するには root 権限が必要です。

/usr/share

このディレクトリーは、アーキテクチャーに固有ではないファイルを格納します。

/usr/src

このディレクトリーは、ソースコードを格納します。

/var/tmp にリンクされたにリンクされた /usr/tmp

このディレクトリーは、一時ファイルを格納します。

/usr/ ディレクトリーには、/local/ サブディレクトリーが含まれる必要もあります。FHS に準じて、このサブディレクトリーはソフトウェアをローカルでインストールする際にシステム管理者によって使用されます。さらに、このサブディレクリーはシステムの更新時に上書きされないように保護されます。/usr/local ディレクトリーは /usr/ と似た構造を持ち、以下のサブディレクトリーが含まれます。

/usr/local/bin

/usr/local/etc

/usr/local/games

/usr/local/include

/usr/local/lib

/usr/local/libexec

/usr/local/sbin

/usr/local/share

/usr/local/src


15

Red Hat Enterprise Linux による /usr/local/ の使用は FHS とは少々異なります。FHS では、システムソフトウェアのアップグレード時に保護するソフトウェアを格納するために /usr/local/ を使用する必要があるとしています。しかし、RPM パッケージマネージャーパッケージマネージャーはソフトウェアアップグレードを安全に実行できるため、ファイルを /usr/local/ に保存して保護する必要はありません。

代わりに、Red Hat Enterprise Linux は /usr/local/ をマシンに対してローカルのソフトウェア用に使用します。たとえば /usr/ ディレクトリーが読み込み専用の NFS 共有としてリモートホストからマウントされている場合も、パッケージまたはプログラムを /usr/local/ ディレクトリー下にインストールすることができます。

2.1.1.11. /var/ ディレクトリーディレクトリー

FHS では、Linux が /usr/ を読み込み専用としてマウントすることを求めているため、ログファイルを書き込むプログラムや、spool/ ディレクトリーまたは lock/ ディレクトリーを必要とするすべてのプログラムは、それらを /var/ ディレクトリーに書き込む必要があります。FHS では、 /var/ がスプールディレクトリーおよびファイル、ログデータ、一過性/一時的ファイルを含む可変データ用であるとしています。

/var/ ディレクトリー内にある一部のディレクトリーを以下に示します。

/var/account/

/var/arpwatch/

/var/cache/

/var/crash/

/var/db/

/var/empty/

/var/ftp/

/var/gdm/

/var/kerberos/

/var/lib/

/var/local/

/var/lock/

/var/log/

/var/spool/mail/ にリンクされた /var/mail

/var/mailman/

/var/named/

/var/nis/

/var/opt/

/var/preserve/


16

/var/run/

/var/spool/

/var/tmp/

/var/tux/

/var/www/

/var/yp/

重要重要

/var/run/media/user ディレクトリーには、USB ストレージメディア、DVD、CD-ROM、および Zip ディスクなどのリムーバブルメディアのマウントポイントとして使用されるサブディレクトリーが含まれます。以前は /media/ ディレクトリーが使用されたことに注意してください。

messages や lastlog などのシステムログファイルは、/var/log/ ディレクトリーに置かれます。/var/lib/rpm/ ディレクトリーは、RPM システムデータベースを収納します。ロックファイルは /var/lock/ ディレクトリーに置かれますが、通常はそのファイルを使用するプログラム用のディレクトリー内にあります。/var/spool/ ディレクトリーには、一部のプログラムのデータファイルを保存するサブディレクトリーがあります。これらのサブディレクトリーには以下が含まれます。

/var/spool/at/

/var/spool/clientmqueue/

/var/spool/cron/

/var/spool/cups/

/var/spool/exim/

/var/spool/lpd/

/var/spool/mail/

/var/spool/mailman/

/var/spool/mqueue/

/var/spool/news/

/var/spool/postfix/

/var/spool/repackage/

/var/spool/rwho/

/var/spool/samba/

/var/spool/squid/

/var/spool/squirrelmail/


17

/var/spool/up2date/

/var/spool/uucp/

/var/spool/uucppublic/

/var/spool/vbox/

2.2. 特殊な RED HAT ENTERPRISE LINUX ファイルの場所

Red Hat Enterprise Linux は特殊なファイルに対応するために、FHS の構造を少々拡張しています。

RPM に関連するほとんどのファイルは、/var/lib/rpm/ ディレクトリー内に保管されます。RPM の詳細は、man rpm を参照してください。

/var/cache/yum/ ディレクトリーには、システムの RPM ヘッダー情報を含む、パッケージアップデーパッケージアップデーターターが使用するファイルを収納しています。この場所は、システムの更新中にダウンロードされるRPM を一時的に保存するためにも使用されます。Red Hat Network の詳細は、オンラインのhttps://rhn.redhat.com/を参照してください。

Red Hat Enterprise Linux に固有のもう 1 つの場所は、/etc/sysconfig/ ディレクトリーです。このディレクトリーは、様々な設定情報を保存します。起動時に実行される多くのスクリプトはこのディレクトリーにあるファイルを使用します。

2.3. /PROC 仮想ファイルシステム

ほとんどのファイルシステムとは異なり、/proc にはテキストファイルもバイナリーファイルも含まれていません。仮想ファイルを格納しているため、/proc は仮想ファイルシステムと呼ばれています。これらの仮想ファイルは、通常、大量の情報が含まれていてもサイズはゼロバイトです。

/proc ファイルシステムはそれ自体がストレージに使用されることはありません。その主要な目的は、ハードウェア、メモリー、実行中のプロセス、および他のシステムコンポーネントに対してファイルベースのインターフェースを提供することです。そのため、対応する /proc ファイルを確認することにより、数多くのシステムコンポーネントに関するリアルタイム情報を取得できます。/proc 内の一部のファイルは、カーネルを設定するように操作することもできます (ユーザーおよびアプリケーションの両方から可能)。

以下の /proc ファイルはシステムストレージの管理と監視に関連しています。

/proc/devices

現在設定してある様々なキャラクターデバイスとブロックデバイスを表示します。

/proc/filesystems

現在カーネルによってサポートされているすべてのファイルシステムのタイプを一覧表示します。

/proc/mdstat

システム上の複数ディスクの設定または RAID の設定の現在の情報がある場合は、ここに含まれます。

/proc/mounts

現在システムで使用されているすべてのマウントを一覧表示します。

/proc/partitions


18

https://rhn.redhat.com/

パーティションブロックの割り当て情報が含まれます。

/proc ファイルシステムの詳細は、Red Hat Enterprise Linux 7 『導入ガイド』を参照してください。

2.4. 未使用ブロックの破棄

バッチ破棄やオンライン破棄のオペレーションは、マウントされたファイルシステムの機能であり、ファイルシステムが使用していないブロックを破棄します。ソリッドステートドライブやシンプロビジョニングされたストレージの両方に役立ちます。

バッチ破棄操作バッチ破棄操作は、fstrim コマンドで、ユーザーによって排他的に実行されます。このコマンドは、ユーザーの条件に一致する、ファイルシステム内のすべての未使用ブロックを破棄します。

オンライン破棄操作オンライン破棄操作は、mount コマンドの一環として -o discard オプションまたは、/etc/fstab ファイルの discard オプションのいずれかで、マウント時に指定されます。これらは、ユーザー介入なしてリアルタイムに実行されます。オンライン破棄操作は、解放に使用される移行中のブロックのみを破棄します。

両方の操作タイプは、Red Hat Enterprise Linux 6.2 以降の ext4 ファイルシステムと Red HatEnterprise Linux 6.4 以降の XFS ファイルシステムとの使用に対応しています。また、基礎となるファイルシステムのブロックデバイスは、物理的な破棄操作に対応している必要があります。/sys/block/device/queue/discard_max_bytes ファイルに格納されている値がゼロでない場合は、物理的な破棄操作に対応しています。

fstrim コマンドを以下で実行している場合:

破棄操作に対応していないデバイス、または

デバイスの 1 つが破棄操作に対応していない、複数のデバイスから成る論理デバイス (LVM または MD)。

以下のメッセージが表示されます。

fstrim -v /mnt/non_discardfstrim: /mnt/non_discard: 破棄操作に対応していません

注記注記

mount コマンドでは、-o discard オプションを指定することで、破棄操作に対応していないデバイスのマウントが可能になります。

システムのワークロードがバッチ破棄で対応できない場合や、パフォーマンスを維持するためにオンライン破棄オペレーションが必要な場合を除き、バッチ破棄オペレーションを推奨します。

詳細については、fstrim(8) と mount(8) man ページを参照してください。


19

第3章 XFS ファイルシステムXFS は、拡張性とパフォーマンスが高いファイルシステムで、元々は Silicon Graphics, Inc. で設計されたファイルシステムでした。XFS は、Red Hat Enterprise Linux 7 のデフォルトのファイルシステムです。

XFS の主な特徴の主な特徴

XFS は、より迅速にクラッシュリカバリを行うメタデータジャーナリングに対応しています。

XFS ファイルシステムは、マウントされてアクティブな際にデフラグおよび拡張できます。

また、Red Hat Enterprise Linux 7 は XFS に固有のユーティリティのバックアップと復元に対応しています。

割り当て機能割り当て機能

XFS には以下のような割り当てスキームが備わっています。

エクステント (領域) ベースの割り当て

ストライプを認識できる割り当てポリシー

遅延割り当て

領域の事前割り当て

遅延割り当てやその他のパフォーマンス最適化は、ext4 だけでなく XFS ファイルシステムにも影響を与えます。つまり、プログラムによる XFS ファイルシステムへの書き込みは、書き込み後にそのプログラムが fsync() 呼び出しを実行しない限り、オンディスクになるとは限りません。

ファイルシステム (ext4 および XFS) での遅延割り当ての影響に関する詳細は、5章ex4 ファイルシステムの割り当て機能を参照してください。

注記注記

ディスク領域に空きがある場合でも、ファイルの作成および展開を実行すると、ENOSPIC で予期しない書き込みエラーが出て失敗する場合があります。これは XFSの設計がパフォーマンス志向型であるために生じます。ただし、これは残りの領域が数ブロック程度である場合にのみ生じるため、実際には問題にはなりません。

XFS ファイルシステムのその他の機能ファイルシステムのその他の機能

XFS ファイルシステムは次のような機能にも対応しています。

拡張属性拡張属性 (xattr)

このシステムにより、各ファイルの、名前と値の組み合わせを追加で関連付けられるようになります。これはデフォルトで有効になります。

クォータのジャーナリングクォータのジャーナリング

クラッシュ後に行なわれる時間がかかるクォータの整合性チェックが不要になります。

プロジェクトプロジェクト/ディレクトリーのクォータディレクトリーのクォータ

ディレクトリーツリー全体にクォータ制限を適用することができます。


20

サブセカンドサブセカンド (1 秒未満秒未満) のタイムスタンプのタイムスタンプ

タイムスタンプをサブセカンド (1 秒未満) 単位にできます。

デフォルトのデフォルトの atime の動作はの動作は relatime

XFS のデフォルトでは Relatime が有効になっています。noatime と比較すると、オーバヘッドはほとんどなく、同じ atime の値を維持します。

3.1. XFS ファイルシステムの作成

XFS ファイルシステムを作成するには、以下のコマンドを使用します。

# mkfs.xfs block_device

ブロックデバイスへのパスで block_device を置き換えます。たとえば、/dev/sdb1、/dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a、または /dev/my-volgroup/my-lv がこれに当たります。

通常、デフォルトのオプションは一般的な使用に最適なものです。

既存のファイルシステムを含むブロックデバイス上で mkfs.xfs を使用する場合は、-f オプションを使ってそのファイルシステムを上書きします。

例例3.1 mkfs.xfs コマンド出力コマンド出力

以下に mkfs.xfs コマンドの出力例を示します。

meta-data=/dev/device isize=256 agcount=4, agsize=3277258 blks = sectsz=512 attr=2data = bsize=4096 blocks=13109032, imaxpct=25 = sunit=0 swidth=0 blksnaming =version 2 bsize=4096 ascii-ci=0log =internal log bsize=4096 blocks=6400, version=2 = sectsz=512 sunit=0 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0

注記注記

XFS ファイルシステムの作成後にサイズを縮小することはできません。ただし、xfs_growfs コマンドを使ってサイズを拡大することはできます。詳細は「XFS ファイルシステムのサイズの拡大」を参照してください。

ストライプブロックデバイスストライプ化されたブロックデバイス (RAID5 アレイなど) の場合、ファイルシステムの作成時にストライプの配列を指定することができます。適切なストライプ配列を使用することで XFS ファイルシステムのパフォーマンスが飛躍的に高まります。

ファイルシステムを LVM ボリュームや MD ボリューム上に作成すると、mkfs.xfs によって最適な配列が選択されます。配列情報をオペレーティングシステムにエクスポートするハードウェア RAID にも、最適な配列の選択を行うものがあります。

第第3章章 XFS ファイルシステムファイルシステム

21

デバイスがストライプの配列情報をエクスポートする場合、mkfs ユーティリティ (ext3、ext4、およびxfs 用) がこの配列を自動的に使用します。ストライプの配列が、ストレージにストライプの配列があるにもかかわらず mkfs ユーティリティによって検出されない場合は、以下のオプションを使用してファイルシステムの作成時にストライプの配列を手動で指定することができます。

su=value

ストライプユニットまたは RAIDのチャンクサイズを指定します。value はバイト単位で指定します。オプションで k、 m、 g などを後ろに付けます。

sw=value

1 RAID デバイス内のデータディスク数または 1 ストライプ内のストライプユニット数を指定します。

以下の例では、チャンクサイズが 64k、ストライプユニット数が 4 つの RAID デバイスを指定しています。

# mkfs.xfs -d su=64k,sw=4 /dev/block_device

関連情報XFS ファイルシステムについての詳細は、以下を参照してください。

mkfs.xfs(8) man ページ

「Red Hat Enterprise Linux パフォーマンスチューニングガイド」の「XFS のチューニング」

3.2. XFS ファイルシステムのマウント

XFS ファイルシステムは、追加のオプションを付けなくてもマウントできます。たとえば、以下のようになります。

# mount /dev/device /mount/point

Red Hat Enterprise Linux 7 のデフォルトは inode64 です。

注記注記

mke2fs とは異なり、mkfs.xfs は設定ファイルを使用せず、すべてコマンドラインに指定されます。

書き込みバリア

書き込みキャッシュが有効にされているデバイスへの電力供給が停止した場合でも、ファイルシステムの整合性を確保できるようにするため、XFS ではデフォルトで書き込みバリアを使用します。したがって、書き込みキャッシュがないデバイスや、書き込みキャッシュがバッテリー駆動型のデバイスには、nobarrier オプションを使ってバリアを無効にします。

# mount -o nobarrier /dev/device /mount/point

書き込みバリアについての詳細は、22章書き込みバリアを参照してください。

Direct Access のテクノロジープレビュー


22

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/performance_tuning_guide/index

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/performance_tuning_guide/index#sect-Red_Hat_Enterprise_Linux-Performance_Tuning_Guide-Configuration_tools-Configuring_file_systems_for_performance

Red Hat Enterprise Linux 7.3 以降、Direct Access (DAX) は、ext4 および XFS ファイルシステムでのテクノロジープレビューとして利用できます。これは、アプリケーションがアドレス空間に永続メモリーを直接マッピングすることを意味します。DAX を使用するには、永続メモリーがシステムに設定されている必要があります。永続メモリーは通常、1 つまたは複数の NVDIMM (Non-Volatile Dual In-lineMemory Module) 形式で提供され、DAX をサポートするファイルシステムは NVDIMM に作成する必要があります。また、ファイルシステムは、dax のマウントオプションでマウントする必要があります。DAX でマウントしたファイルシステムにファイルを mmap すると、アプリケーションのアドレス空間にストレージが直接マッピングされます。

3.3. XFS クォータの管理

XFS クォータサブシステムでディスク領域 (ブロック) およびファイル (inode) の使用量に関する制限の管理を行います。こうした項目の使用量に関する制御や報告は、ユーザー、グループ、ディレクトリーまたはプロジェクトの各レベルで行います。また、ユーザーのクォータ、グループのクォータ、ディレクトリーまたはプロジェクトのクォータはそれぞれ個別に有効にできますが、グループとプロジェクトのクォータについては相互に排他的となります。

ディレクトリー単位またはプロジェクト単位で管理を行う場合、XFS は特定のプロジェクトに関連付けられたディレクトリー階層のディスク使用量を管理します。これにより、XFS は複数のプロジェクト間にある組織をまたがった「グループ」の境界を認識します。ディレクトリー単位またはプロジェクト単位でクォータの管理を行うことにより、ユーザーのクォータやグループのクォータを管理する場合よりも広範囲な制御レベルを得ることができます。

XFS のクォータは、マウント時に特定のマウントオプションを付けて有効にします。各マウントオプションは noenforce として指定することもできます。これを指定すると、一切の制限を適用することなく使用量に関する報告を可能にします。有効なクォータのマウントオプションは以下の通りです。

uquota/uqnoenforce: ユーザーのクォータ

gquota/gqnoenforce: グループクォータ

pquota/pqnoenforce: プロジェクトクォータ

クォータを有効にすると、xfs_quota ツールを使ってディスク使用量の制限を設定し、その報告が可能になります。デフォルトでは、xfs_quota はベーシックモードでインタラクティブに実行されます。ベーシックモードのサブコマンドは使用量の報告のみを実行します。このコマンドはすべてのユーザーが使用できます。xfs_quota の基本的なサブコマンドには以下が含まれます。

quota username/userID

任意の username または数字による userID の使用量と制限を表示します。

df

空き/使用済みブロック数および空き/使用済み inode 数を表示します。

一方、xfs_quota にはエキスパートモードもあります。このモードのサブコマンドで制限を実際に設定することができるため、このサブコマンドを使用できるのは上位の特権を持つユーザーに限られます。エキスパートモードのサブコマンドをインタラクティブに使用するには、以下のコマンドを使用します。

# xfs_quota -x

エキスパートモードサブコマンドには、以下が含まれます。

report /path


23

特定のファイルシステムのクォータ情報を表示します。

limit

クォータの制限を変更します。

ベーシックモードまたはエキスパートモードのサブコマンド一覧については、サブコマンドの help をご覧ください。

すべてのサブコマンドは、コマンドラインからも-c オプションを使って直接実行させることができます。エキスパートのサブコマンドの場合は -x を使用できます。

例例3.2 サンプルのクォータレポートの表示サンプルのクォータレポートの表示

たとえば、/home (/dev/blockdevice 上) のクォータレポートのサンプルを表示するには、xfs_quota -x -c 'report -h' /home コマンドを使用します。これにより、次のような出力が表示されます。

User quota on /home (/dev/blockdevice)BlocksUser ID Used Soft Hard Warn/Grace---------- ---------------------------------root 0 0 0 00 [------]testuser 103.4G 0 0 00 [------]...

ホームディレクトリーが /home/john のユーザー john に対して、inode 数のソフトとハードの制限をそれぞれ 500 と 700 に設定するには、次のコマンドを使用します。

# xfs_quota -x -c 'limit isoft=500 ihard=700 john' /home/

この場合、マウント済みの xfs ファイルシステムである mount_point を渡します。

デフォルトでは、limit サブコマンドはターゲットがユーザーであると認識します。このため、ターゲットをグループとして制限を設定する場合は -g オプションを使います (上記の例の場合も同様)。さらに、プロジェクトの場合は -p を使います。

ブロックのソフトとハードの制限は、isoft または ihard の代わりに bsoft または bhard を使って設定することもできます。

例例3.3 ブロックのソフトとハードの制限の設定ブロックのソフトとハードの制限の設定

たとえば、/target/path ファイルシステム上の accounting グループに対してソフトとハードのブロック制限をそれぞれ 1000m と 1200m に設定する場合は次のコマンドを使用します。

# xfs_quota -x -c 'limit -g bsoft=1000m bhard=1200m accounting' /target/path

注記注記

コマンドの bsoft と bhard ではバイト単位でカウントします。

重要重要


24

重要重要

man xfs_quota では、リアルタイムのブロック (rtbhard/rtbsoft) がクォータの設定時の有効な単位として説明されていますが、本リリースではリアルタイムのサブボリュームは有効にされません。このため、rtbhard と rtbsoft のオプションは適用できません。

プロジェクト制限の設定

プロジェクトで管理されているディレクトリー群に対して制限を設定する前に、まずそのディレクトリー群を /etc/projects に追加します。プロジェクト名を /etc/projectid に追加して、複数のプロジェクト ID とプロジェクト名をマッピングさせることができます。プロジェクトを /etc/projects に追加したら、次のコマンドを使用してそのプロジェクトディレクトリーを初期化します。

# xfs_quota -x -c 'project -s projectname' project_path

次のコマンドを実行して、初期化したディレクトリー群を持つプロジェクトのクォータを設定します。

# xfs_quota -x -c 'limit -p bsoft=1000m bhard=1200m projectname'

クォータ設定の汎用ツール (quota、repquota、および edquota など) を使用しても XFS のクォータを操作することができます。ただし、これらのツールは XFS のプロジェクトのクォータでは使用きません。

重要重要

Red Hat は、他の利用可能なすべてのツールの中でも、xfs_quota の使用を推奨します。

XFS のクォータの設定方法については、man xfs_quota、man projid(5)、および man projects(5) を参照してください。

3.4. XFS ファイルシステムのサイズの拡大

xfs_growfs コマンドを使用すると、マウント中の XFS ファイルシステムを拡大することができます。

# xfs_growfs /mount/point -D size

-D size オプションを使用して、ファイルシステムをその size (ファイルシステムのブロック数) まで大きくします。 -D size オプションを指定しないと、xfs_growfs はデバイスで対応できる最大サイズにまで、ファイルシステムを拡大します。

-D size を指定して XFS ファイルシステムを拡大する前に、基礎となるブロックデバイスが将来的にファイルシステムを保持できるサイズであることを確認してください。サイズ変更する場合は対象となるブロックデバイスに適した方法を使用してください。

注記注記

XFS ファイルシステムはマウントしている状態でも拡大することはできますが、逆にそのサイズを縮小することはできません。

ファイルシステムを拡大する方法は man xfs_growfs を参照してください。


25

3.5. XFS ファイルシステムの修復

XFS ファイルシステムを修復するには、xfs_repair を使用します。

# xfs_repair /dev/device

xfs_repair ユーティリティーは拡張性に優れ、多くの inode を持つ非常に大きなファイルシステムさえも効率的に修復できるよう設計されています。他の Linux ファイルシステムとは異なり、xfs_repairは、XFS ファイルシステムが正常にアンマウントされていなかった場合でもブート時には実行されません。正常にアンマウントされなかった場合、xfs_repair はマウント時にログの内容を再現し、ファイルシステムの整合性を確保します。

警告警告

xfs_repair ユーティリティーは、ダーティーログを持つ XFS ファイルシステムを修復できません。ログを消去するには、XFS ファイルシステムをマウントしてからアンマウントします。ログが破損していて再現できない場合は -L (ログのゼロ化を強制) オプションを使ってログの消去を行います (xfs_repair -L /dev/device)。ただし、これを行うと破損が悪化したりデータを損失したりする場合があります。

XFS ファイルシステムの修復方法の詳細は、man xfs_repair を参照してください。

3.6. XFS ファイルシステムの一時停止

ファイルシステムに対する書き込みアクティビティの停止または再開を行うには、以下のコマンドを使用します。

# xfs_freeze mount-point

書き込みアクティビティを停止することで、ハードウェアベースのデバイススナップショットを使用して、一貫性のある状態にファイルシステムをキャプチャーできます。

注記注記

xfs_freeze ユーティリティーは xfsprogs パッケージで提供されます。これは x86_64でのみ利用できます。

XFS ファイルシステムを一時停止 (フリーズ) するには、以下のコマンドを使用します。

# xfs_freeze -f /mount/point

XFS ファイルシステムのフリーズを解除する場合は、次のコマンドを使用します

# xfs_freeze -u /mount/point

LVM のスナップショットを取るのに、xfs_freeze を使ってファイルシステムを一時停止にする必要は


26

LVM のスナップショットを取るのに、xfs_freeze を使ってファイルシステムを一時停止にする必要はありません。LVM 管理ツールが、スナップショットを取る前に XFS ファイルシステムを自動的に一時停止します。

XFS ファイルシステムのフリーズおよびフリーズ解除に関する詳細は、man xfs_freeze をご覧ください。

3.7. XFS ファイルシステムのバックアップと復元

XFS ファイルシステムのバックアップと復元には、以下のユーティリティが関与します。

バックアップの作成を行うための xfsdump

バックアップから復元するための xfsrestore

3.7.1. XFS バックアップと復元の機能

バックアップバックアップ

xfsdump ユーティリティを使用すると、以下を行うことができます。

通常のファイルイメージへのバックアップ。

通常のファイルに書き込むことができるバックアップは 1 つだけです。

テープドライブへのバックアップ。

xfsdump ユーティリティーを使用すると、同じテープに複数のバックアップを書き込むこともできます。バックアップは複数のテープをまたぐことができます。

複数のファイルシステムを単一のテープデバイスにバックアップするには、XFS バックアップがすでに含まれているテープにバックアップを書き込むだけです。これにより、新しいバックアップが前のバックアップに追加されます。デフォルトでは、xfsdump は既存のバックアップを上書しません。

増分バックアップの作成。

xfsdump ユーティリティーはダンプレベルを使用して、他のバックアップの相対的なベースバックアップを決定します。0 から 9 までの数字は、ダンプレベルの増加を表します。増分バックアップは、下位レベルの最後のダンプ以降に変更されたファイルのみをバックアップします。

フルバックアップを実行するには、ファイルシステムでレベルレベル0のダンプを実行します。

レベル 1 のダンプは、フルバックアップ後の最初の増分バックアップです。次の増分バックアップはレベル 2 になります。これは、最後のレベル 1 のダンプ以降に変更されたファイルのみをバックアップします。レベル 9 まで同様です。

ファイルを絞り込むサイズ、サブツリー、または i ノードフラグを使用してバックアップからファイルを除外。

復元復元

xfsrestore ユーティリティは、xfsdump によって生成されたバックアップからファイルシステムを復元します。xfsrestore ユーティリティには、2 つのモードがあります。

simple モードでは、ユーザーはレベル 0 のダンプからファイルシステム全体を復元できます。


27

simple モードでは、ユーザーはレベル 0 のダンプからファイルシステム全体を復元できます。これがデフォルトのモードです。

cumulative モードでは、増分バックアップ (つまりレベル 1 からレベル 9) からファイルシステムを復元できます。

各バックアップは、session ID または session label で一意に識別されます。複数のバックアップを含むテープからバックアップを復元するには、対応するセッション ID またはラベルが必要です。

バックアップから特定のファイルを抽出、追加、または削除するには、xfsrestore インタラクティブモードを起動します。インタラクティブモードでは、バックアップファイルを操作する一連のコマンドが提供されます。

3.7.2. XFS ファイルシステムのバックアップ

この手順では、XFS ファイルシステムの内容をファイルまたはテープにバックアップする方法を説明します。

手順手順3.1 XFS ファイルシステムのバックアップファイルシステムのバックアップ

次のコマンドを使用して XFS ファイルシステムをバックアップします。

# xfsdump -l level [-L label] -f backup-destination path-to-xfs-filesystem

level を、バックアップのダンプレベルに置き換えます。フルバックアップを実行するには 0 を使用し、それに続く増分バックアップを実行するには 1 から 9 を使用します。

backup-destination を、バックアップを保存する場所のパスに置き換えます。宛先は通常のファイル、テープドライブ、またはリモートテープデバイスです。たとえば、ファイルの場合は /backup-files/Data.xfsdump、テープドライブの場合は /dev/st0 に置き換えます。

path-to-xfs-filesystem を、バックアップする XFS ファイルシステムのマウントポイントに置き換えます。たとえば、/mnt/data/ と置き換えます。ファイルシステムをマウントする必要があります。

複数のファイルシステムをバックアップして単一のテープデバイスに保存する場合は、復元時にそれらを簡単に識別できるように -L label オプションを使用して各バックアップにセッションラベルを追加します。label をバックアップの名前 (backup_data など) に置き換えます。

例例3.4 複数の複数の XFS ファイルシステムのバックアップファイルシステムのバックアップ

/boot/ および /data/ ディレクトリーにマウントした XFS ファイルシステムの内容をバックアップして、/backup-files/ ディレクトリーにファイルとして保存するには以下を実行します。

# xfsdump -l 0 -f /backup-files/boot.xfsdump /boot# xfsdump -l 0 -f /backup-files/data.xfsdump /data

1 つのテープデバイスにある複数のファイルシステムのバックアップを作成するには、-L label オプションを使用して各バックアップにセッションラベルを追加します。

# xfsdump -l 0 -L "backup_boot" -f /dev/st0 /boot# xfsdump -l 0 -L "backup_data" -f /dev/st0 /data


28

関連情報関連情報

XFS ファイルシステムのバックアップの詳細は、xfsdump(8) man ページを参照してください。

3.7.3. バックアップからの XFS ファイルシステムの復元

この手順では、XFS ファイルシステムの内容をファイルまたはテープのバックアップから復元する方法を説明します。

前提条件前提条件

「XFS ファイルシステムのバックアップ」の説明にあるように、XFS ファイルシステムのファイルまたはテープのバックアップが必要です。

手順手順3.2 バックアップからのバックアップからの XFS ファイルシステムの復元ファイルシステムの復元

バックアップを復元するコマンドは、フルバックアップから復元するのか、増分バックアップから復元するのか、または単一のテープデバイスから複数のバックアップを復元するのかによって異なります。

# xfsrestore [-r] [-S session-id] [-L session-label] [-i] -f backup-location restoration-path

backup-location を、バックアップの場所に置き換えます。宛先は通常のファイル、テープドライブ、またはリモートテープデバイスです。たとえば、ファイルの場合は /backup-files/Data.xfsdump、テープドライブの場合は /dev/st0 に置き換えます。

restoration-path を、ファイルシステムを復元するディレクトリーへのパスに置き換えます。たとえば、/mnt/data/ と置き換えます。

ファイルシステムを増分 (レベル 1 からレベル 9) バックアップから復元するには、-r オプションを追加します。

複数のバックアップを含むテープデバイスからバックアップを復元するには、-S または -Lオプションを使用してバックアップを指定します。

-S オプションではセッション ID でバックアップを選択でき、 -L オプションではセッションラベルで選択できます。セッション ID とセッションラベルを取得するには、xfsrestore -I コマンドを使用します。

session-id をバックアップのセッション ID に置き換えます。たとえば、b74a3586-e52e-4a4a-8775-c3334fa8ea2c と置き換えます。session-label をバックアップのセッションラベルに置き換えます。たとえば、my_backup_session_label と置き換えます。

xfsrestore をインタラクティブに使用するには、-i オプションを使用します。

xfsrestore による指定デバイスの読み込みが終了すると、インタラクティブなダイアログが開始されます。インタラクティブな xfsrestore シェルで使用できるコマンドは cd、ls、add、delete、および extract などになります。コマンドの詳細な一覧については help コマンドをご覧ください。

例例3.5 複数の複数の XFS ファイルシステムの復元ファイルシステムの復元

XFS バックアップファイルを復元し、その内容を /mnt/ の下のディレクトリーに保存するには、次


29

XFS バックアップファイルを復元し、その内容を /mnt/ の下のディレクトリーに保存するには、次の手順を実行します。

# xfsrestore -f /backup-files/boot.xfsdump /mnt/boot/# xfsrestore -f /backup-files/data.xfsdump /mnt/data/

複数のバックアップを含むテープデバイスから復元するには、各バックアップをセッションラベルまたはセッション ID で指定します。

# xfsrestore -f /dev/st0 -L "backup_boot" /mnt/boot/# xfsrestore -f /dev/st0 -S "45e9af35-efd2-4244-87bc-4762e476cbab" /mnt/data/

テープからバックアップを復元するときの情報メッセージテープからバックアップを復元するときの情報メッセージ複数のファイルシステムのバックアップを使用してテープからバックアップを復元するとき、xfsrestore ユーティリティーがメッセージを出すことがあります。メッセージは、xfsrestore がテープ上の各バックアップを順番に調べたときに、要求されたバックアップと一致するものが見つかったかどうかを通知します。次に例を示します。

xfsrestore: preparing drivexfsrestore: examining media file 0xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)xfsrestore: examining media file 1xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)[...]

一致するバックアップが見つかるまで、情報メッセージが表示され続けます。


XFS ファイルシステムの復元の詳細は、xfsrestore(8) man ページを参照してください。

3.8. エラー動作の設定

I/O 操作の際にエラーが発生したとき、XFS ドライバーは以下のいずれかの方法で応答します。

以下のいずれかの条件が満たされるまで続行します。

I/O 操作が成功するか、

I/O 操作がカウントを再試行するか、時間の制限が超過

エラーを永続的なものとし、システムを停止します。

XFS は現在、以下のエラー条件を認識しています。このエラーには、希望の動作を詳細に設定できます。

EIO: デバイスへの書き込み試行中のエラー

ENOSPC: デバイスに空き容量がありません

ENODEV: デバイスが見つかりません


30

特定のハンドラーが定義されていないその他のエラー条件全ては、単一かつグローバルな設定を共有します。

XFS がエラーを永続的と見なす条件を設定できます。これは、最大再試行回数と最大時間 (秒) の両方を指定できます。XFS は、いずれかの条件が満たされると、再試行を停止します。

その他の設定に関係なく、ファイルシステムのマウントを解除するときはすぐに再試行をキャンセルするオプションがあります。これにより、永続的なエラーが発生した場合でも、マウント解除操作を成功させることができます。

3.8.1. 特定の条件と不確定の条件の設定ファイル

エラーの動作を制御する設定ファイルは、/sys/fs/xfs/device/error/ ディレクトリーに位置しています。

/sys/fs/xfs/device/error/metadata/ ディレクトリーには、各固有のエラー条件のサブディレクトリーが含まれます。

EIO エラー条件用の /sys/fs/xfs/device/error/metadata/EIO/

ENODEV エラー条件用の /sys/fs/xfs/device/error/metadata/ENODEV/

ENOSPC エラー条件用の /sys/fs/xfs/device/error/metadata/ENOSPC/

それぞれには、以下の設定ファイルが含まれます。

/sys/fs/xfs/device/error/metadata/condition/max_retries: XFS が操作を再試行する最大回数を制御します。

/sys/fs/xfs/device/error/metadata/condition/retry_timeout_seconds: XFS が操作の再試行を停止するまでの時間制限 (秒)

以前のセクションの説明以外のその他すべての考えられるエラー条件は、これらのファイルの共通の設定を使用します。

/sys/fs/xfs/device/error/default/max_retries: 再試行の最大数を制御

/sys/fs/xfs/device/error/default/retry_timeout_seconds: 再試行する時間制限を制御

3.8.2. 特定の条件と未確定の条件のファイルシステムの動作の設定

再試行の最大数を設定するには、希望の回数を max_retries ファイルに書き込みます。

特定の条件:

# echo value > /sys/fs/xfs/device/error/metadata/condition/max_retries

未確定の条件:

# echo value > /sys/fs/xfs/device/error/default/max_retries

value は、-1 から許容最大値の C 符号付き整数の int の値です。64 ビット Linux では、 2147483647 です。

時間制限を設定するには、希望の秒数を retry_timeout_seconds ファイルに書き込みます。


31

特定の条件:

# echo value > /sys/fs/xfs/device/error/metadata/condition/retry_timeout_seconds

未確定の条件:

# echo value > /sys/fs/xfs/device/error/default/retry_timeout_seconds

value は、-1 から 86400 までの数値です。これは、1 日の秒数です。

max_retries と retry_timeout_seconds オプションでは両方とも、-1 が永続を意味し、0 がただちに停止を意味します。

device はデバイスの名前です。これは、/dev/ ディレクトリーにあり、たとえば sda がこれにあたります。

注記注記

各エラー条件のデフォルトの動作は、エラーコンテキストによって異なります。ENODEV のようなエラーは、試行回数に関係なく、致命的で回復不可として考慮されます。そのため、これらのデフォルト値は 0 です。

3.8.3. マウント解除動作の設定

fail_at_unmount オプションを設定している場合、ファイルシステムはマウント解除の際にその他すべての設定を上書きし、I/O 操作を再試行することなく、ファイルシステムのマウントをすぐに解除します。これにより、永続エラーが発生した場合でも、マウント解除操作を成功させることができます。

マウント解除動作の設定方法:

# echo value > /sys/fs/xfs/device/error/fail_at_unmount

value は 0 または 1 のいずれかです。

1 は、エラーが見つかった場合にすぐに再試行をキャンセルすることを意味します。

0 は max_retries と retry_timeout_seconds オプションを順守することを意味します。

device はデバイスの名前です。これは、/dev/ ディレクトリーにあり、たとえば sda がこれにあたります。

重要重要

fail_at_unmount オプションは、ファイルシステムのマウント解除試行を行う前に、設定を行う必要があります。マウント解除操作が始まると、設定ファイルやディレクトリーは利用できなくなります。

3.9. XFS ファイルシステムのその他のユーティリティー

Red Hat Enterprise Linux 7 には XFS ファイルシステム管理用のユーティリティーが他にもあります。

xfs_fsr

マウントしている XFS ファイルシステムのデフラグを行う際に使用します。引数を指定せずに呼び


32

出すと、xfs_fsr はマウントしているすべての XFS ファイルシステム内にあるすべての通常ファイルのデフラグを行います。このユーティリティーでは、ユーザーによるデフラグの一時停止や、一時停止した部分からのデフラグの再開が可能です。

さらに、xfs_fsr /path/to/file のように指定すると、xfs_fsr で 1 つのファイルのみをデフラグできます。XFS はデフォルトで断片化の発生を防ぐため、ファイルシステム全体を定期的にデフラグしないことが推奨されます。システム全体でデフラグを行うと、空き領域が断片化する可能性があります。

xfs_bmap

XFS ファイルシステム内のファイル群で使用されているディスクブロックのマップを表示します。指定したファイルによって使用されているエクステントや、該当するブロックがないファイルの領域 (ホール) を一覧表示します。

xfs_info

XFS ファイルシステムの情報を表示します。

xfs_admin

XFS ファイルシステムのパラメーターを変更します。xfs_admin ユーティリティーで変更できるのは、アンマウントされているデバイスやファイルシステムのパラメーターのみです。

xfs_copy

XFS ファイルシステム全体のコンテンツを 1 つまたは複数のターゲットに同時にコピーします。

また、XFS ファイルシステムのデバッグや分析を行う際に以下のユーティリティーが役に立ちます。

xfs_metadump

XFS ファイルシステムのメタデータをファイルにコピーします。Red Hat では、アンマウントされているファイルシステムや読み取り専用のマウントされているファイルシステムをコピーする場合にのみ xfs_metadump ユーティリティーの使用をサポートしています。これ以外のファイルシステムにこのユーティリティーを使用すると、破損したダンプまたは整合性のないダンプが生成される可能性があります。

xfs_mdrestore

XFS メタダンプイメージ (xfs_metadump で生成されたイメージ) をファイルシステムのイメージに復元します。

xfs_db

XFS ファイルシステムのデバッグを行います。

上記のユーティリティーの詳細は、それぞれの man ページをご覧ください。

3.10. EXT4 から XFS への移行

Red Hat Enterprise Linux 7.0 より、デフォルトのファイルシステムが ext4 から XFS に変更になりました。本セクションでは、使用または管理時における XFS ファイルシステムの違いについて取り上げます。

ext4 ファイルシステムは Red Hat Enterprise Linux 7 でも完全にサポートされており、インストール時に ext4 を選択できます。ext4 から XFS への移行は可能ですが、必須ではありません。


33

3.10.1. Ext3/4 と XFS の違い

ファイルシステムの修復ファイルシステムの修復

Ext3/4 は、起動時にユーザー空間で e2fsck を実行し、必要時にジャーナルを復元しますが、XFSは、マウント時にカーネル空間でジャーナルの復元を実行します。fsck.xfs シェルスクリプトは提供されますが、initscript の要件を満たすためだけに提供され、意味のあるアクションは実行しません。

XFS ファイルシステムの修復またはチェックが要求される場合は、xfs_repair コマンドを使用します。読み取り専用のチェックには -n オプションを使用します。

xfs_repair コマンドは、ダーティーログを持つファイルシステムでは機能しません。このようなファイルシステムを修復するには、まず mount と unmount を実行し、ログを再生する必要があります。ログが破損していたり、再生できない場合には、-L オプションを使用して、ログのゼロ化を実行できます。

XFS ファイルシステムのファイルシステムの修復の詳細は、「XFS」を参照してください。

メタデータのエラー動作メタデータのエラー動作

ext3/4 ファイルシステムでは、メタデータのエラーが生じた場合、デフォルトで継続させた状態で動作を設定することができます。XFS に回復不能なメタデータのエラーが生じた場合、ファイルシステムはシャットダウンし、EFSCORRUPTED エラーが戻されます。システムログには、発生したエラーの詳細情報が記載されます。さらに、必要な場合には xfs_repair を実行することを推奨します。

クォータクォータ

XFS クォータは再マウントできないオプションです。クォータを有効にするには、-o quota オプションを初回マウント時に指定する必要があります。

クォータパッケージの標準ツールは基本的なクォータ管理タスクを実行できますが (setquota および repquota などのツール)、xfs_quota ツールは、プロジェクトクォータの管理など、XFS 固有の機能に使用できます。

quotacheck コマンドは、XFS ファイルシステムに一切影響を与えません。クォータアカウンティングがオンに設定される初回時に、XFS は自動の quotacheck を内部で実行します。XFS クォータのメタデータはファーストクラスのジャーナリングされたメタデータオブジェクトであるため、クォータシステムは、クォータが手動でオフに設定されるまで常に一貫性を維持します。

ファイルシステムのサイズ変更ファイルシステムのサイズ変更

XFS ファイルシステムには、ファイルシステムを小さくするユーティリティーがありません。ただし、XFS ファイルシステムは、xfs_growfs コマンドを使ってオンラインで拡張できます。

Inode 数数

256 バイトの inode があり 1 TB を超えるファイルシステムの場合や、512 バイトの inode があり 2TB を超えるファイルシステムの場合、XFS の inode の数は 2 の 32 乗を上回る場合があります。このように inode の数が大きくなると、32 ビットの stat を呼び出す際に EOVERFLOW 戻り値が出力され失敗します。この問題は、4 つの割り当てグループを使用した非ストライプ化した、デフォルトの Red Hat Enterprise Linux 7 設定を使用していると発生する可能性があります。カスタム設定、たとえばファイルシステムを拡張、または XFS ファイルシステムのパラメーターを変更すると、挙動が異なる場合があります。

アプリケーションは、通常、このように数が大きい inode 番号を処理します。必要に応じて、-o inode32 パラメーターを使用して XFS ファイルシステムをマウントして、inode の番号を強制的に2 の 32 乗未満にします。inode32 を使用しても、64 ビット番号で割り当ててある inode には影響


34

しません。

重要重要

inode32 オプションは、特定の環境で必要とされない限り使用しない使用しないでください。inode32 オプションは割り当て動作を変更します。したがって、低レベルのディスクブロックに、inode の割り当てに利用できる領域がない場合は、ENOSPC エラーが発生する場合があります。

予測型の事前割り当て予測型の事前割り当て

XFS は、ファイルの書き込み時の EOF を超えたブロックの割り当てに予測型の事前割り当てを使用します。これは、NFS サーバーでの同時ストリーミングの書き込みワークロードによって発生するファイル断片化を防ぎます。デフォルトでは、この事前割り当ては、ファイルのサイズと共に拡大し、「du」の出力に表示されます。予測型の事前割り当てが設定されたファイルが 5 分間ダーティーにならないと、この事前割り当ては破棄されます。inode がその前にキャッシュから解放されると、inode が解放 (reclaim) された時に事前割り当てが破棄されます。

早期に出される ENOSPC の問題が予測型の事前割り当てによるものであると見られる場合は、事前割り当ての固定量を、-o allocsize=amount マウントオプションで指定することができます。

断片化に関連したツール断片化に関連したツール

断片化は、遅延割り当てや予測型の事前割り当てなど、各種のヒューリスティックおよび動作によるものであるため、XFS ファイルシステムで大きな問題となることはほとんどありません。ファイルシステムの断片化を測定したり、ファイルシステムのデフラグを行うためのツールは存在しますが、それを使用することは推奨されません。

xfs_db frag コマンドは、ファイルシステムの割り当てを、パーセントで表される単一の断片化の数に抽出することを試行します。コマンドが出力した内容を理解するには、多くの専門知識が必要になります。たとえば、断片化の割合が 75% というは、ファイルごとの平均エクステント数が 4 しかないことを意味します。したがって、断片化の問題を調べるには、xfs_db フラグの出力だけでは十分とは言えず、より注意深く分析を行うことが推奨されます。

警告警告

xfs_fsr コマンドは、個別ファイル、またはファイルシステム上のすべてのファイルをデフラグするのに使用できます。ファイルの場所が破損したり、空き領域の断片化が発生したりする可能性があるので、特に後者をデフラグすることは推奨されておりません。

XFS とと ext3 およびおよび ext4 で使用されるコマンドの比較で使用されるコマンドの比較

以下の表は、ext3 および ext4 で使用される共通のコマンドと、XFS 固有のコマンドを比較しています。

表表3.1 ext3 およびおよび ext4 の共通コマンドとの共通コマンドと XFS のコマンドの比較のコマンドの比較


35

タスクタスク ext3/4 XFS

ファイルシステムの作成 mkfs.ext4 または mkfs.ext3 mkfs.xfs

ファイルシステムのチェック e2fsck xfs_repair

ファイルシステムのサイズ変更 resize2fs xfs_growfs

ファイルシステムのイメージの保存

e2image xfs_metadump および xfs_mdrestore

ファイルシステムのラベル付けまたはチューニング

tune2fs xfs_admin

ファイルシステムのバックアップ dump および restore xfsdump および xfsrestore

以下の表は、XFS ファイルシステムで機能する汎用ツールを示していますが、XFS バージョンにはさらに多くの固有機能があるため、これらの使用を推奨します。

表表3.2 ext4 とと XFS の汎用ツールの汎用ツール

タスクタスク ext4 XFS

Quota quota xfs_quota

ファイルマッピング filefrag xfs_bmap

ここにリストされている多くの XFS コマンドの詳細は 3章XFS ファイルシステムで確認できます。また、XFS 管理ツールの man ページで詳細情報を確認することもできます。


36

第4章 EXT3 ファイルシステムext3 ファイルシステムは、基本的に、ext2 ファイルシステムが拡張されたバージョンです。さまざまな改善点により、以下のような利点が提供されます。

可用性可用性

予期しない停電やシステムクラッシュ (クリーンでないシステムシャットダウンとも言われる) が発生すると、マシンにマウントしている各 ext2 ファイルシステムは、e2fsck プログラムで整合性をチェックする必要があります。これは時間を浪費するプロセスであり、大量のファイルを含む大型ボリュームでは、システムの起動時間を著しく遅らせます。このプロセスの間、そのボリュームにあるデータは使用できません。

稼働中のファイルシステムで fsck -n を実行することはできますが、変更を加えることはできないため、部分的に書き込まれたメタデータが発生すると誤解を生じさせる結果になりかねません。

スタック内で LVM が使用されている場合は、ファイルシステムの LVM スナップショットを取り、スナップショットで fsck を実行する方法も考えられます。

もしくは、ファイルシステムを読み込み専用で再マウントするオプションがあります。保留中のメタデータ更新 (および書き込み) は、すべて再マウントの前にディスクへ強制的に入れられます。これにより、これ以前に破損がない限り、ファイルシステムは整合性を確保でき、fsck -n の実行が可能になります。

ext3 ファイルシステムで提供されるジャーナリングは、クリーンでないシステムシャットダウンが発生してもこの種のファイルシステムのチェックが不要であることを意味します。ext3 の使用していても整合性チェックが必要になる唯一の場面は、ハードドライブの障害が発生した場合など、ごく稀なハードウェア障害のケースのみです。クリーンでないシャットダウンの発生後に ext3 ファイルシステムを復元する時間は、ファイルシステムのサイズやファイルの数量に左右されません。むしろ、整合性の維持のために使用されるジャーナルのサイズで決まります。デフォルトのジャーナルサイズの場合は、ハードウェアのスピードにもよりますが、復元にかかる時間は１秒ほどになります。

注記注記

Red Hat で対応している ext3 の唯一のジャーナリングモードはdata=ordered (デフォルト) です。

データの整合性データの整合性

ext3 ファイルシステムは、クリーンでないシステムシャットダウンが発生した際にデータの整合性が失われることを防止します。ext3 ファイルシステムにより、データが受けることのできる保護のタイプとレベルを選択できるようになります。ファイルシステムの状態に関しては、ext3 のボリュームはデフォルトで高度なレベルのデータ整合性を維持するように設定されています。

速度速度

ext3 のジャーナリングはハードドライブのヘッド動作を最適化するため、一部のデータを複数回書き込んだとしても、ほとんどのケースで、ext2 よりもスループットが高くなります。速度を最適化するために 3 つのジャーナリングモードから選択できますが、システムに障害が発生する可能性のある状況では、モードの選択はデータの整合性がトレードオフの関係になることがあります。

注記注記

Red Hat で対応している ext3 の唯一のジャーナリングモードはdata=ordered (デフォルト) です。

第第4章章 EXT3 ファイルシステムファイルシステム

37

容易な移行容易な移行

ext2 から ext3 へ移行して、再フォーマットをせずに堅固なジャーナリングファイルシステムの利点を活かす操作は簡単です。このタスクの実行の詳細は、「ext3 ファイルシステムへの変換」を参照してください。

注記注記

Red Hat Enterprise Linux 7 は、統一された extN ドライバーを提供します。これは、ext2 および ext3 設定を無効にすると提供され、これらのオンディスク形式に対して ext4.ko を使用します。これは、使用される ext ファイルシステムの種類を問わず、カーネルのメッセージは常に ext4 を参照することを意味します。

4.1. EXT3 ファイルシステムの作成

インストール後に、ext3 ファイルシステムを新たに作成する必要がある場合があります。たとえば、システムに新しいディスクドライブを追加した時に、そのドライブにパーティション設定して ext3 ファイルシステムを使用します。

1. mkfs.ext3 ユーティリティを使用して、ext3 ファイルシステムのパーティションまたは LVMボリュームをフォーマットします。

# mkfs.ext3 block_device


2. e2label ユーティリティを使用してファイルシステムにラベル付けます。

# e2label block_device volume_label

UUID の設定ファイルシステムに特定の UUID を設定することも可能です。ファイルシステムを作成する際に UUIDを指定するには、-U オプションを指定します。

# mkfs.ext3 -U UUID device

設定したい UUID を UUID に置き換えます。例: 7cd65de3-e0be-41d9-b66d-96d749c02da7

UUID を追加するために、ext3 ファイルシステムへのパスで device を置き換えます。例: /dev/sda8

既存のファイルシステムの UUID を変更するには、「永続的な命名属性の変更」を参照してください。

関連情報

mkfs.ext3(8) man ページ

e2label(8) man ページ

4.2. EXT3 ファイルシステムへの変換


38

tune2fs コマンドは、ext2 ファイルシステムを ext3 に変換します。

注記注記

ext2 を ext3 に変換する場合は、常に e2fsck ユーティリティーを使用し、tune2fs の使用前後にファイルシステムをチェックしてください。ext2 の ext3 への変換を試みる前に、エラーが発生する場合に備えてすべてのファイルシステムをバックアップします。

さらに Red Hat では、可能な場合は、ext2 から ext3 に変換するのではなく、新しいext3 ファイルシステムを作成して、お持ちのデータを移行することをお勧めしています。

ext2 ファイルシステムを ext3 に変換するには、root としてログインしてから、ターミナルで以下のコマンドを入力します。

# tune2fs -j block_device

block_device には、変換される ext2 ファイルシステムが入ります。

df コマンドを実行して、マウントしたファイルシステムを表示します。

4.3. EXT2 ファイルシステムに戻す

ext2 ファイルシステムに戻すには、以下の手順を使います。

分かりやすくするために、このセクションのサンプルコマンドではブロックデバイスに以下のような値を使用します。

/dev/mapper/VolGroup00-LogVol02

手順手順4.1 ext3 からから ext2 に戻すに戻す

1. root でログインしてから以下を入力し、パーティションをアンマウントします。

# umount /dev/mapper/VolGroup00-LogVol02

2. 以下のコマンドを入力して、ファイルシステムタイプを ext2 に変更します。

# tune2fs -O ^has_journal /dev/mapper/VolGroup00-LogVol02

3. 以下のコマンドを入力して、パーティションのエラーをチェックします。

# e2fsck -y /dev/mapper/VolGroup00-LogVol02

4. 次に、以下を入力して、パーティションを ext2 ファイルシステムとして再度マウントします。

# mount -t ext2 /dev/mapper/VolGroup00-LogVol02 /mount/point

/mount/point を、実際に使用するパーティションのマウントポイントに置き換えます。

注記注記

第第4章章 EXT3 ファイルシステムファイルシステム

39

注記注記

パーティションの root レベルに .journal ファイルが存在する場合は、それを削除します。

パーティションを永続的に ext2 に変更したい場合は、忘れずに /etc/fstab ファイルを更新してください。更新せずにブートすると、変更した箇所が元に戻ります。


40

第5章 EX4 ファイルシステムext4 ファイルシステムは、ext3 ファイルシステムに拡張を加えたファイルシステムです。 Red HatEnterprise Linux 7 では、ファイルサイズが最大 16 テラバイトまでサポートされます。また、Red HatEnterprise Linux 6 でサポートされるファイルシステムは最大 16 テラバイトでしたが、Red HatEnterprise Linux 7 では最大 50 テラバイトになりました。サポートされるサブディレクトリーの数は無制限 (ext3 ファイルシステムの場合は最大 32,000 までの対応) ですが、リンク数が 65,000 を超えると1 にリセットされ、増加しなくなります。bigalloc 機能は現在サポートされていません。

注記注記

ext3 と同様、fsck を実行する場合は、ext4 ボリュームのアンマウントが必要になります。詳細については 4章ext3 ファイルシステムをご覧ください。

主な特長主な特長

(ext2 および ext3 で使用された従来のブロックマッピングスキームと異なり) ext4 ファイルシステムはエクステントを使用し、サイズの大きいファイルを使用する場合のパフォーマンスが向上されているため、そのメタデータのオーバーヘッドが減少します。また、ext4 では、未使用のブロックグループと inode テーブルのセクションにそれぞれラベル付けが行なわれます。これにより、ファイルシステムのチェック時にこれらを省略することができます。また、ファイルシステムチェックの速度が上がるため、ファイルシステムが大きくなるほどその便宜性は顕著になります。


ext4 ファイルシステムには、以下のような割り当てスキームが備わっています。

永続的な事前割り当て

遅延割り当て

マルチブロック割り当て

ストライプ認識割り当て

遅延割り当てや他のパフォーマンスが最適化されるため、ext4 のディスクへのファイル書き込み動作は ext3 の場合とは異なります。ext4 では、プログラムがファイルシステムへの書き込みを実行しても、fsync() 呼び出しを発行しない限り、その書き込みがオンディスクになる保証はありません。

ext3 では、fsync() の呼び出しがなくても、ファイルが新たに作成されると、そのほぼ直後にデフォルトでディスクに書き込みが強制されます。この動作により、書き込まれたデータがオンディスクにあることを、fsync() 使って確認しないというプログラムのバグが表面化しませんでした。一方、ext4 ファイルシステムは、ディスクへの変更書き込みの前に数秒間待機することが多く、書き込みを結合して再度順序付けを行うことにより、ext3 を上回るディスクパフォーマンスを実現しています。

第第5章章 EX4 ファイルシステムファイルシステム

41

警告警告

ext3 とは異なり、ext4 ファイルシステムでは、トランザクションコミット時にディスクへのデータの書き込みを強制しません。このため、バッファーされた書き込みがディスクにフラッシュされるまでに時間がかかります。他のファイルシステムと同様、永続的なストレージにデータが書き込まれたことを確認するには、fsync() などのデータ整合性チェックの呼び出しを使用してください。

ext4 のその他の機能のその他の機能

ext4 ファイルシステムでは次の機能にも対応しています。

拡張属性 (xattr) — システムで、ファイルごとに追加の名前と値のペアを関連付けられるようになります。

クォータジャーナリング機能 — クラッシュ発生後に、時間のかかるクォータ整合性チェックが不要になります。

注記注記

ext4 で対応しているジャーナリングモードは data=ordered のみです (デフォルト)。

サブセカンドのタイムスタンプ — サブセカンドのタイムスタンプを指定します。

5.1. EXT4 ファイルシステムの作成

ext4 ファイルシステムを作成するには、以下のコマンドを使用します。

# mkfs.ext4 block_device


一般的な用途では、デフォルトのオプションが最適です。

例例5.1 mkfs.ext4 コマンドの出力コマンドの出力

以下にこのコマンドのサンプル出力を示します。出力結果には、ファイルシステムの配列や機能が表示されます。

~]# mkfs.ext4 /dev/sdb1mke2fs 1.41.12 (17-May-2010)Filesystem label=OS type: LinuxBlock size=4096 (log=2)Fragment size=4096 (log=2)


42

Stride=0 blocks, Stripe width=0 blocks245280 inodes, 979456 blocks48972 blocks (5.00%) reserved for the super userFirst data block=0Maximum filesystem blocks=100663296030 block groups32768 blocks per group, 32768 fragments per group8176 inodes per groupSuperblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done Creating journal (16384 blocks): doneWriting superblocks and filesystem accounting information: done

重要重要

tune2fs を使用して、ext3 ファイルシステムで特定の ext4 機能を有効にすることができます。ただし、この方法で tune2fs を使用することは十分にテストされていないため、Red Hat Enterprise Linux 7 ではサポート対象外サポート対象外となります。したがって、Red Hatは、tune2fs で変換またはマウントした ext3 ファイルシステムに関しては、一貫性のあるパフォーマンスや、予測可能な動作を保証していません。

ストライプブロックデバイスストライプ化されたブロックデバイス (RAID5 アレイ) の場合は、ファイルシステムを作成する際にストライプの配列を指定することができます。適切なストライプ配列を使用することで、ext4 ファイルシステムのパフォーマンスが大幅に改善されます。

LVM ボリュームや MD ボリュームにファイルシステムを作成する場合は、mkfs.ext4 によって最適な配列が選択されます。オペレーティングシステムに配列情報をエクスポートするハードウェア RAID の中にも、こうした最適な配列を選択するものがあります。

ストライプ配列を指定する場合は、mkfs.ext4 の -E オプション (拡張されたファイルシステムのオプション) に次のようなサブオプションを付けて使用します。

stride=value

RAID のチャンクサイズを指定します。

stripe-width=value

1 RAID デバイス内のデータディスク数または 1 ストライプ内のストライプユニット数を指定します。

どちらのサブオプションを使用する場合でも、value には、ファイルシステムのブロック単位で指定する必要があります。たとえば、4k のブロックファイルシステムの 64k ストライプ (16 x 4096) を指定する場合は、以下のようなコマンドになります。

# mkfs.ext4 -E stride=16,stripe-width=64 /dev/block_device

UUID の設定ファイルシステムに特定の UUID を設定することも可能です。ファイルシステムを作成する際に UUIDを指定するには、-U オプションを指定します。


43

# mkfs.ext4 -U UUID device

設定したい UUID を UUID に置き換えます。例: 7cd65de3-e0be-41d9-b66d-96d749c02da7

UUID を追加するために、ext4 ファイルシステムへのパスに device を置き換えます。例: /dev/sda8

既存のファイルシステムの UUID を変更するには、「永続的な命名属性の変更」を参照してください。

関連情報ext4 ファイルシステムについての詳細は、以下を参照してください。

mkfs.ext4(8) man ページ

5.2. EXT4 ファイルシステムのマウント

ext4 ファイルシステムは、オプション付けずにマウントすることができます。

# mount /dev/device /mount/point

ext4 ファイルシステムは、動作に影響を与えるマウントオプションにも対応しています。たとえば、acl パラメーターはアクセス制御リストを有効にし、user_xattr パラメーターはユーザーによる拡張属性を有効にします。両方のオプションを有効にするには、以下のようにそれぞれのパラメーターに -o を付けて使用します。

# mount -o acl,user_xattr /dev/device /mount/point

ext3 の場合と同様、data_err=abort オプションを使用して、エラーがファイルデータに生じた場合にジャーナルを中止するようにできます。

# mount -o data_err=abort /dev/device /mount/point

tune2fs ユーティリティーを使用すると、管理者は、ファイルシステムのスーパーブロックにデフォルトのマウントオプションを設定できるようになります。詳細については man tune2fs をご覧ください。

書き込みバリア

書き込みキャッシュが有効になっているデバイスへの電力供給が停止した場合でも、ファイルシステムの整合性を確保できるようにするため、ext4 ではデフォルトで書き込みバリアを使用します。したがって、書き込みキャッシュがないデバイスや、書き込みキャッシュがバッテリー駆動型のデバイスには、以下のように nobarrier オプションを使ってバリアを無効にします。

# mount -o nobarrier /dev/device /mount/point

書き込みバリアについての詳細は、22章書き込みバリアを参照してください。

Direct Access のテクノロジープレビュー

Red Hat Enterprise Linux 7.3 以降、Direct Access (DAX) では、アプリケーションがアドレス空間に永続メモリーを直接マッピングする手段を、ext4 および XFS ファイルシステムでのテクノロジープレビューとして提供するようになりました。DAX を使用するには、永続メモリーがシステムに設定されている必要があります。永続メモリーは通常、1 つまたは複数の NVDIMM (Non-Volatile Dual In-line


44

Memory Module) 形式で提供され、DAX をサポートするファイルシステムは NVDIMM に作成する必要があります。また、ファイルシステムは、dax のマウントオプションでマウントする必要があります。DAX でマウントしたファイルシステムにファイルを mmap すると、アプリケーションのアドレス空間にストレージが直接マッピングされます。

5.3. EXT4 ファイルシステムのサイズ変更

ext4 ファイルシステムのサイズを大きくする前に、基礎となるブロックデバイスが将来的にファイルシステムを保持するのに十分なサイズであることを確認してください。該当するブロックデバイスのサイズを変更する場合は、ブロックデバイスに適した方法を使ってサイズ変更を行ってください。

ext4 ファイルシステムは、resize2fs を使用して、マウントしたままの状態でサイズを大きくすることができます。

# resize2fs /mount/device size

resize2fs コマンドは、アンマウントしているアンマウントしている ext4 ファイルシステムのサイズを小さくすることもできます。

# resize2fs /dev/device size

ext4 ファイルシステムのサイズを変更する際に、特定の単位を示すサフィックスが使用されていない限り、resize2fs ユーティリティーは、ファイルシステムのブロックサイズ単位でサイズを読み込みます。特定の単位を指定するには、以下のサフィックスを使用します。

s — 512 バイトのセクター

K — キロバイト

M — メガバイト

G — ギガバイト

注記注記

拡張時のサイズパラメーターはオプションになります (多くの場合は不要です)。resize2fs は、論理ボリュームやパーティションなど、使用できるコンテナーの全領域に渡って自動的に拡張を行います。

ext4 ファイルシステムのサイズ変更に関する詳細は、man resize2fs をご覧ください。

5.4. EXT2、EXT3、EXT4 のファイルシステムのデバッグを行います。

この手順では、ext4、ext3、または ext2 ファイルシステムの内容をファイルにバックアップする方法を説明します。

前提条件

システムが長時間稼働している場合は、バックアップを行う前に、パーティションで e2fsck を実行してください。

# e2fsck /dev/device

手順手順5.1 ext2、、ext3、、ext4 のファイルシステムのデバッグを行います。のファイルシステムのデバッグを行います。


45

手順手順5.1 ext2、、ext3、、ext4 のファイルシステムのデバッグを行います。のファイルシステムのデバッグを行います。

1. /etc/fstab ファイルの内容と fdisk -l コマンドの出力を含めた設定情報をバックアップします。これは、パーティションの復元に役立ちます。

この情報を取得するには、sosreport または sysreport ユーティリティを実行します。sosreport の詳細は、「Red Hat Enterprise Linux 4.6 以降における sosreport の役割と取得方法」ナレッジベース記事を参照してください。

2. パーティションのロールに依存:

バックアップしているパーティションがオペレーティングシステムのパーティションである場合、レスキューモードにシステムを起動します。『システム管理者のガイド』の「Booting to Rescue Mode」を参照してください。

通常のデータパーティションをバックアップしている場合は、マウントを解除してください。

マウントしているときに、データパーティションをバックアップすることも可能ですが、マウントしたデータパーティションのバックアップ結果は、予測できないことがあります。

dump ユーティリティを使用して、マウントされているファイルシステムをバックアップする必要がある場合は、ファイルシステムに強い負荷がかかっていないときに行います。バックアップの際に実行中のアクティビティが多いほど、バックアップ破損のリスクが高まります。

3. dump ユーティリティを使用して、パーティションのコンテンツをバックアップします。

# dump -0uf backup-file /dev/device

backup-file を、バックアップを保存するファイルへのパスに置き換えます。バックアップするext4 パーティションの名前に device を置き換えます。バックアップは、バックアップしているパーティションではなく、別のパーティションにマウントしたディレクトリーに保存するようにしてください。

例例5.2 複数の複数の ext4 パーティションのバックアップパーティションのバックアップ

/dev/sda1、/dev/sda2、/dev/sda3 パーティションの内容を /backup-files/ ディレクトリーに保存されてるバックアップファイルにバックアップするには、以下のコマンドを使用します。

# dump -0uf /backup-files/sda1.dump /dev/sda1# dump -0uf /backup-files/sda2.dump /dev/sda2# dump -0uf /backup-files/sda3.dump /dev/sda3

リモートバックアップを行うには、ssh ユーティリティを使用するか、パスワードレスの sshログインを設定します。ssh やパスワードレスログインの詳細は、『システム管理者のガイド』の「Using the ssh Utility」と「Using Key-based Authentication」を参照してください。

たとえば、ssh を使用する場合:

例例5.3 ssh を使用したリモートバックアップの実行を使用したリモートバックアップの実行


46

https://access.redhat.com/ja/solutions/78443

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#sec-Booting_to_Rescue_Mode

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/s1-ssh-clients#s2-ssh-clients-ssh

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/s1-ssh-configuration#s2-ssh-configuration-keypairs

# dump -0u -f - /dev/device | ssh [email protected] dd of=backup-file

標準のリダイレクトを使用している場合は、-f オプションを別に渡す必要があります。

関連情報

詳細は、dump(8) man ページを参照してください。

5.5. EXT2、EXT3、EXT4 のファイルシステムの復元

この手順では、ext4、ext3、または ext2 ファイルシステムをファイルのバックアップから復元する方法を説明します。

前提条件

「ext2、ext3、ext4 のファイルシステムのデバッグを行います。」で説明しているように、パーティションのバックアップとメタデータが必要になります。

手順手順5.2 ext2、、ext3、、ext4 のファイルシステムの復元のファイルシステムの復元

1. オペレーティングシステムパーティションで復元を行っている場合は、レスキューモードにシステムを起動します。『システム管理者のガイド』の「Booting to Rescue Mode」を参照してください。

このステップは、通常のデータパーティションには不要です。

2. fdisk または parted ユーティリティを使用して復元するパーティションを再構築します。

パーティションが存在しない場合は再作成します。新しいパーティションは、復元したデータを含めるのに十分な大きさである必要があります。開始の数値と終了の数値を正しく取得することが重要です。バックアップを行う際、fdisk ユーティリティから取得したパーティションの開始セクター番号と終了番号があります。

パーティションの変更の詳細は、13章パーティションを参照してください。

3. mkfs ユーティリティを使用して、対象のパーティションをフォーマットします。

# mkfs.ext4 /dev/device

重要重要

バックアップファイルを保存しているパーティションは、フォーマットしないでしないでくださいください。

4. 新しいパーティションを作成した場合は、すべてのパーティションのラベルを再び付けます。これにより、/etc/fstab ファイルのエントリーにマッチします。

# e2label /dev/device label

5. 一時マウントポイントを作成し、これらでパーティションをマウントします。


47

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#sec-Booting_to_Rescue_Mode

# mkdir /mnt/device# mount -t ext4 /dev/device /mnt/device

6. マウントしたパーティション上のバックアップからデータを復元します。

# cd /mnt/device# restore -rf device-backup-file

リモートマシンで復元を行う場合や、リモートホストに保存されているバックアップから復元を行う場合は、ssh ユーティリティを使うことができます。ssh の詳細は、『システム管理者のガイド』の「ssh ユーティリティの使用」のセクションを参照してください。

以下のコマンドのパスワードレスログインを設定します。パスワードレス ssh ログインの設定の詳細は、『システム管理者のガイド』の「鍵ベース認証の使用」を参照します。

同じマシンで保存したバックアップファイルからリモートマシン上のパーティションを復元します。

# ssh remote-address "cd /mnt/device && cat backup-file | /usr/sbin/restore -r -f -"

別のリモートマシンで保存したバックアップファイルからリモートマシン上のパーティションを復元します。

# ssh remote-machine-1 "cd /mnt/device && RSH=/usr/bin/ssh /usr/sbin/restore -rf remote-machine-2:backup-file"

7. 再起動:

# systemctl reboot

例例5.4 複数の複数の ext4 パーティションの復元パーティションの復元

/dev/sda1、/dev/sda2、/dev/sda3 パーティションを例5.2「複数の ext4 パーティションのバックアップ」から復元するには:

1. fdisk コマンドを使用して復元するパーティションを再構築します。

2. 対象パーティションをフォーマットします。

# mkfs.ext4 /dev/sda1# mkfs.ext4 /dev/sda2# mkfs.ext4 /dev/sda3

3. すべてのパーティションのラベルを再び付けることで、/etc/fstab ファイルに一致します。

# e2label /dev/sda1 Boot1# e2label /dev/sda2 Root# e2label /dev/sda3 Data

4. 作業ディレクトリーを準備します。

新規パーティションのマウント:


48

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/s1-ssh-clients#s2-ssh-clients-ssh

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#s2-ssh-configuration-keypairs

# mkdir /mnt/sda1# mount -t ext4 /dev/sda1 /mnt/sda1# mkdir /mnt/sda2# mount -t ext4 /dev/sda2 /mnt/sda2# mkdir /mnt/sda3# mount -t ext4 /dev/sda3 /mnt/sda3

バックアップファイルを含むパーティションをマウントします。

# mkdir /backup-files# mount -t ext4 /dev/sda6 /backup-files

5. マウントしたパーティションにバックアップからデータを復元します。

# cd /mnt/sda1# restore -rf /backup-files/sda1.dump# cd /mnt/sda2# restore -rf /backup-files/sda2.dump# cd /mnt/sda3# restore -rf /backup-files/sda3.dump

6. 再起動:

# systemctl reboot

関連情報

詳細は、restore(8) man ページを参照してください。

5.6. EXT4 ファイルシステムのその他のユーティリティー

Red Hat Enterprise Linux 7 には、他にも ext4 ファイルシステム管理ユーティリティーがあります。

e2fsck

ext4 ファイルシステムの修復時に使用します。ext4 でディスク構造が変更されたため、ext3 ファイルシステムよりも効率的なチェックと修復が行えるようになりました。

e2label

ext4 ファイルシステムのラベル変更を行います。このツールは ext2 および ext3 のファイルシステムでも動作します。

quota

ext4 ファイルシステムで、ユーザーおよびグループごとのディスク領域 (ブロック) やファイル(inode) の使用量を制御し、それを報告します。quota の詳細は man quota および「ディスククォータの設定」をご覧ください。

fsfreeze

ファイルシステムへのアクセスを中断する際、フリーズにはコマンド # fsfreeze -f mount-point を使用し、フリーズ解除には # fsfreeze -u mount-point を使用します。これにより、ファイルシステムへのアクセスが停止し、安定したイメージがディスクに作成されます。


49

注記注記

device-mapper ドライブに fsfreeze を使用する必要はありません。

詳細は、man ページの fsfreeze(8) を参照してください。

「ext4 ファイルシステムのマウント」で説明している通り、tune2fs ユーティリティーでは ext2、ext3 および ext4 の各ファイルシステムの設定可能なファイルシステムパラメーターを調整することもできます。また、ext4 ファイルシステムのデバッグや分析を行う際には次のツールが役に立ちます。

debugfs

ext2、ext3、ext4 の各ファイルシステムのデバッグを行います。

e2image

ext2、ext3、ext4 の重要なファイルシステムメタデータを、任意のファイルに保存します。

上記のユーティリティーの詳細は、各 man ページをご覧ください。


50

第6章 BTRFS (テクノロジープレビュー)

注記注記



Btrfs は次世代 Linux ファイルシステムで、高度な管理、信頼性、および拡張性機能を提供します。Btrfs は、スナップショット、圧縮機能および統合デバイス管理を提供する点でユニークと言えます。

6.1. BTRFS ファイルシステムの作成

基本的な Btrfs ファイルシステムを作成するには、以下のコマンドを使用します。

# mkfs.btrfs /dev/device

追加デバイスを備えた Btrfs ファイルシステムを作成し、メタデータおよびデータ用のマルチデバイスプロファイルを指定する詳細な方法は、「複数デバイスの統合ボリューム管理」を参照してください。

6.2. BTRFS ファイルシステムのマウント

Btrfs ファイルシステムでデバイスをマウントするには、以下のコマンドを使用します。

# mount /dev/device /mount-point

その他の役に立つオプション:

device=/dev/name

このオプションをマウントコマンドに追加すると、brtfs は Btrfs ボリューム用に指定されたデバイスをスキャンします。このオプションは、Btrfs 以外のデバイスのマウントを試みるとマウントに失敗するため、確実にマウントを成功させるために使用します。

注記注記

これは、すべてのデバイスをスキャンすることを示しているだけで、すべてのデバイスがファイルシステムに追加されるわけではありません。

max_inline=number

このオプションは、メタデータ B ツリーリーフ内のインラインデータに使用できる最大スペース (バイト単位) を設定します。デフォルトは 8192 バイトです。4k ページの場合は、リーフに適合させる必要のある追加ヘッダーがあるため、このサイズは 3900 バイトに制限されます。

alloc_start=number

このオプションは、ディスクストレージの割り当てにおける開始点を設定します。

thread_pool=number

第第6章章 BTRFS (テクノロジープレビューテクノロジープレビュー)

51


このオプションは、割り当てられるワーカースレッドの数を指定します。

discard

このオプションは、解放されたブロック上で discard/TRIM を有効にします。

noacl

このオプションは、ACL の使用を無効にします。

space_cache

このオプションは、ディスク上の空き領域のデータを保存し、ブロックグループのキャッシュを高速化します。これは、永続的な変更であり、古いカーネルでブートしても問題はありません。

nospace_cache

このオプションは、上記の space_cache を無効にします。

clear_cache

このオプションは、マウント時にすべての空き領域キャッシュをクリアにします。このオプションは安全ですが、キャッシュ領域の再ビルドをトリガーします。そのため、再ビルドプロセスを終了させるためにファイルシステムをマウントした状態にしておきます。このマウントオプションは、1回限り、かつ空き領域に関する問題が明らかになった後にのみ使用します。

enospc_debug

このオプションは、「空き領域が残っていない」問題をデバッグするために使用されます。

recovery

このオプションは、マウント時の自動リカバリーを有効にします。

6.3. BTRFS ファイルシステムのサイズ変更

btrfs ファイルシステムのサイズを変更することはできませんが、ファイルシステムが使用する各デバイスのサイズは変更できます。使用しているデバイスが 1 つしかない場合は、ファイルシステムのサイズ変更と同様のことが行われます。使用しているデバイスが複数ある場合は、手動でのサイズ変更が必要になります。

注記注記

単位サイズは大文字と小文字を区別しないため、GiB には G と g の両方を使用できます。

このコマンドは、テラバイトを表す t や、ペタバイトを表す p を使用することはできません。使用できるのは、k、m、および g のみとなります。

Btrfs ファイルシステムの拡大

単一のデバイスでファイルシステムを拡大するには、以下のコマンドを使用します。

# btrfs filesystem resize amount /mount-point

例を示します。


52

# btrfs filesystem resize +200M /btrfssingleResize '/btrfssingle' of '+200M'

複数デバイスのファイルシステムを拡大するには、拡大するデバイスを指定する必要があります。最初に、特定のマウントポイントに btrfs ファイルシステムがあるデバイスをすべて表示します。

# btrfs filesystem show /mount-point


# btrfs filesystem show /btrfstestLabel: none uuid: 755b41b7-7a20-4a24-abb3-45fdbed1ab39 Total devices 4 FS bytes used 192.00KiB devid 1 size 1.00GiB used 224.75MiB path /dev/vdc devid 2 size 524.00MiB used 204.75MiB path /dev/vdd devid 3 size 1.00GiB used 8.00MiB path /dev/vde devid 4 size 1.00GiB used 8.00MiB path /dev/vdf

Btrfs v3.16.2

拡大するデバイスの devid を確認した後、以下のコマンドを使用します。

# btrfs filesystem resize devid:amount /mount-point


# btrfs filesystem resize 2:+200M /btrfstestResize '/btrfstest/' of '2:+200M'

注記注記

amount には、特定の容量ではなく max を指定することでもできます。max にすると、デバイスの空き容量がすべて使用されます。

btrfs ファイルシステムの縮小

単一のデバイスでファイルシステムを縮小するには、以下のコマンドを使用します。



# btrfs filesystem resize -200M /btrfssingleResize '/btrfssingle' of '-200M'

複数デバイスのファイルシステムを縮小するには、縮小するデバイスを指定する必要があります。最初に、特定のマウントポイントに btrfs ファイルシステムがあるデバイスをすべて表示します。




53


Btrfs v3.16.2

縮小するデバイスの devid を確認した後、以下のコマンドを使用します。



# btrfs filesystem resize 2:-200M /btrfstestResize '/btrfstest' of '2:-200M'

ファイルシステムのサイズ設定

単一のデバイスでファイルシステムを特定のサイズに設定するには、以下のコマンドを使用します。



# btrfs filesystem resize 700M /btrfssingleResize '/btrfssingle' of '700M'

複数デバイスのファイルシステムのサイズを設定するには、変更するデバイスを指定する必要があります。最初に、特定のマウントポイントに btrfs ファイルシステムがあるデバイスをすべて表示します。




Btrfs v3.16.2

変更するデバイスの devid を確認した後、以下のコマンドを使用します。




54

# btrfs filesystem resize 2:300M /btrfstestResize '/btrfstest' of '2:300M'

6.4. 複数デバイスの統合ボリューム管理

BTRFS ファイルシステムは、多くのデバイスの上に作成することができ、ファイルシステムの作成後に複数のデバイスを追加することができます。デフォルトでは、メタデータが 2 つのデバイス間でミラー化され、データは表示されるすべてのデバイス間でストライプ化されます。ただし、デバイスが 1つしかない場合、メタデータはそのデバイス上に複製されます。

6.4.1. 複数デバイスによるファイルシステムの作成

「Btrfs ファイルシステムの作成」で詳細に説明されているように、mkfs.btrfs コマンドではオプションとして、データ -d とメタデータ -m を指定できます。有効な仕様は以下の通りです。

raid0

raid1

raid10

dup

single

-m single オプションは、メタデータの複製を行なわないことを通知します。この機能は、ハードウェア RAID を使用する場合に必要になることがあります。

注記注記

RAID 10 を正しく実行するには、最低でも 4 台のデバイスが必要です。

例例6.1 RAID 10 btrfs ファイルシステムの作成ファイルシステムの作成

4 つのデバイスにわたるファイルシステムを作成します (ミラー化されたメタデータ、ストライプ化されたデータ)。

# mkfs.btrfs /dev/device1 /dev/device2 /dev/device3 /dev/device4

ミラー化せずにメタデータをストライプ化します。

# mkfs.btrfs -m raid0 /dev/device1 /dev/device2

データとメタデータの両方に raid10 を使用します。

# mkfs.btrfs -m raid10 -d raid10 /dev/device1 /dev/device2 /dev/device3 /dev/device4

単一デバイス上でメタデータを複製しません。

# mkfs.btrfs -m single /dev/device

ドライブのサイズが異なる場合に、各デバイスの容量を完全に使用するには single オプションを使用


55

ドライブのサイズが異なる場合に、各デバイスの容量を完全に使用するには single オプションを使用します。

# mkfs.btrfs -d single /dev/device1 /dev/device2 /dev/device3

新規デバイスを、すでに作成されたマルチデバイスファイルシステムに追加するには、以下のコマンドを使用します。

# btrfs device add /dev/device1 /mount-point

Btrfs モジュールの再起動または再読み込みの後に、btrfs device scan コマンドを使用して、すべてのマルチデバイスファイルシステムを検出します。詳細は、「btrf デバイスのスキャン」を参照してください。

6.4.2. btrf デバイスのスキャン

btrfs device scan を使用して、/dev 以下のすべてのブロックデバイスをスキャンし、BTRFS ボリュームをプローブします。ファイルシステム内で複数のデバイスと共に実行されている場合、Btrfs モジュールの読み込み後に実行されます。

すべてのデバイスをスキャンするには、以下のコマンドを使用します。

# btrfs device scan

1 つのデバイスをスキャンするには、以下のコマンドを使用します。

# btrfs device scan /dev/device

6.4.3. 新規デバイスの btrfs ファイルシステムへの追加

btrfs filesystem show コマンドを使用して、すべての btrfs ファイルシステムと、そのファイルシステムに含まれるデバイスを一覧表示します。

btrfs device add コマンドは、マウントされたファイルシステムに新規のデバイスを追加するために使用されます。

btrfs filesystem balance コマンドは、すべての既存デバイス間で割り当てられたエクステントのバランスを取ります (再ストライピング)。

新規デバイスを追加する上記のコマンド例は以下の通りです。

例例6.2 新しいデバイスの新しいデバイスの btrfs ファイルシステムへの追加ファイルシステムへの追加

最初に、btrfs ファイルシステムの作成とマウントを行います。btrfs ファイルシステムを作成する詳細な方法は「Btrfs ファイルシステムの作成」、btrfs ファイルシステムをマウントする詳細な方法は「Btrfs ファイルシステムのマウント」を参照してください。

# mkfs.btrfs /dev/device1# mount /dev/device1

次に、マウントされた btrfs ファイルシステムに 2 つ目のデバイスを追加します。

# btrfs device add /dev/device2 /mount-point


56

これらのデバイス上のメタデータとデータは、依然として /dev/device1 にのみ保存されます。これがすべてのデバイスに広がるようにバランスを取る必要があります。

# btrfs filesystem balance /mount-point

ファイルシステムのバランスの調整には時間がかかります。ファイルシステムにあるデータとメタデータをすべて読み取り、それを新規デバイス全体に再度書き込むためです。

6.4.4. btrfs ファイルシステムの変換

非 RAID ファイルシステムを RAID に変換するには、デバイスを追加し、チャンク割り当てプロファイルを変更するバランスフィルターを実行します。

例例6.3 btrfs ファイルシステムの変換ファイルシステムの変換

この場合のように、既存の単一デバイスシステムの /dev/sdb1 を raid1 システムの 2 つのデバイスに変換し、単一ディスクの障害から保護するには、以下のコマンドを使用します。

# mount /dev/sdb1 /mnt# btrfs device add /dev/sdc1 /mnt# btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt

重要重要

メタデータが単一デバイスのデフォルトから変換されない場合、それは DUP のままになります。これは、ブロックのコピーが別々のデバイスに置かれることを保証するものではありません。データが変換されない場合、重複コピーは全く存在しません。

6.4.5. btrfs デバイスの削除

btrfs device delete コマンドを使用して、オンラインデバイスを削除します。また、安全に削除するために使用中のすべてのエクステントをファイルシステムの他のデバイスに再配信します。

例例6.4 btrfs ファイルシステム上でのデバイスの削除ファイルシステム上でのデバイスの削除

最初に、いくつかの btrfs ファイルシステムを作成し、マウントします。

# mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde# mount /dev/sdb /mnt

一部のデータをファイルシステムに追加します。

最後に、必要なデバイスを削除します。

# btrfs device delete /dev/sdc /mnt

6.4.6. btrfs ファイルシステムでの障害のあるデバイスの置き換え

「btrfs デバイスの削除」は、障害のあるデバイスを削除するために使用できます。ただし、これは


57

「btrfs デバイスの削除」は、障害のあるデバイスを削除するために使用できます。ただし、これはスーパーブロックが依然として読み込み可能な場合に限られます。デバイスが見つからなかったり、スーパーブロックが壊れていたりすると、ファイルシステムは低下モードでマウントする必要があります。

# mkfs.btrfs -m raid1 /dev/sdb /dev/sdc /dev/sdd /dev/sde

ssd is destroyed or removed, use -o degraded to force the mount to ignore missing devices

# mount -o degraded /dev/sdb /mnt

'missing' is a special device name

# btrfs device delete missing /mnt

コマンド btrfs device delete missing は、ファイルシステムのメタデータで記述されているものの、ファイルシステムのマウント時には表示されない最初のデバイスを削除します。

重要重要

デバイスが見つからないことがあることを考慮しても、特定の RAID レイアウトに必要なデバイスの最小数を下回ることは考えられません。障害のあるものを削除するために、新たなデバイスを追加することが必要になる場合があります。

たとえば、2 つのデバイスからなる raid1 レイアウトで、デバイスが失敗した場合には、以下を実行する必要があります。

1. 低下モードでのマウント

2. 新規デバイスの追加

3. 見つからないデバイスの削除

6.4.7. btrfs ファイルシステムの /etc/fstab への登録

initrd がない場合、または btrfs デバイススキャンを実行しない場合、ファイルシステムのすべてのデバイスを mount コマンドに明示的に渡すと、マルチボリューム btrfs ファイルシステムをマウントすることができます。

例例6.5 /etc/fstab エントリーの例エントリーの例

適切な /etc/fstab エントリーの例は、以下のようになります。

/dev/sdb /mnt btrfs device=/dev/sdb,device=/dev/sdc,device=/dev/sdd,device=/dev/sde 0

UUID (universally unique identifier) を使用することもできます。UUID は、デバイスパスよりも安定性が高くなります。


58

6.5. SSD の最適化

btrfs ファイルシステムを使用して SSD を最適化することができます。これは 2 つの方法で実行することができます。

最初の方法として、/sys/block/device/queue/rotational が単一の指定されたデバイスに対してゼロである場合に mkfs.btrfs は単一デバイスでのメタデータの複製をオフにします。これは、コマンドラインで -m single を指定するのと同等の動作になります。-m dup オプションを指定すると、この設定はオーバーライドされ、メタデータの複製が強制実行されます。ただし、SSD ファームウェアが両方のコピーを失う可能性があるため、複製は不要です。スペースの無駄やパフォーマンスコストを考慮してもそのように言えます。

2 つ目として、SSD マウントオプションの ssd、 nossd、および ssd_spread などのグループを使用する方法があります。

ssd オプションは、いくつかのことを実行します。

大規模なメタデータクラスター割り当てを可能にします。

可能な場合は、データをより順次に割り当てます。

キーとブロックの順番を一致させるため btree リーフの再書き込みを無効にします。

複数プロセスをバッチ処理を行なわずに、ログのフラグメントをコミットします。

注記注記

ssd マウントオプションは ssd オプションのみを有効にします。これを無効にするには、nossd オプションを使用します。

一部の SSD のパフォーマンスは、ブロック番号を再利用する場合に最もよくなることが多くあります。また、クラスター化によって未使用領域の大きなチャンクが厳密に割り当てられるとパフォーマンスが大幅に向上する場合もあります。デフォルトでは、mount -o ssd は、割り当てられたブロックが混在している可能性のある複数の空きブロックがある場合に、ブロックの複数のグループを検索します。コマンド mount -o ssd_spread は、割り当て済みのブロックが混在していないことを確認します。これにより、ローエンドの SSD のパフォーマンスが強化されます。

注記注記

ssd_spread オプションは、ssd と ssd_spread オプションの両方を有効にします。これらのどちらのオプションも無効にするには、nossd を使用します。

ssd_spread オプションは、いずれの ssd オプションも指定されず、デバイスのいずれかが非回転デバイスの場合は、自動的に設定されません。

これらのオプションは、これらを使用することによりパフォーマンスが改善されるか、または低下するかを調べるために、ご使用の特定のビルドですべてテストする必要があります。ビルドにより、SSDファームウェアとアプリケーション負荷の組み合わせはそれぞれ異なるためです。

6.6. BTRFS の参考資料

man ページ btrfs(8) には、すべての重要な管理コマンドについての記載があります。とくに、以下が含まれます。


59

スナップショットを管理するためのすべてのサブボリュームコマンド。

デバイスを管理するための device コマンド。

scrub、balance、および defragment コマンド。

man ページの mkfs.btrfs(8) には、関連するすべてのオプションを含め、BTRFS ファイルシステムを作成する方法についての情報が含まれます。

btrfs システム上の fsck に関する情報を記載した man ページの btrfsck(8)。


60

第7章 GLOBAL FILE SYSTEM 2Red Hat Global File System 2 (GFS2) はネイティブのファイルシステムで、直接　Linux カーネルファイルシステムのインターフェースと相互作用します (VFS 層)。クラスターファイルシステムとして実装すると、GFS2 は配信メタデータと複数のジャーナルを採用します。

GFS2 は 64 ビットのアーキテクチャーをベースとし、理論的には 8 エクサバイトのファイルシステムを収容することができます。ただし、現在対応している GFS2 ファイルシステムの最大サイズは 100 テラバイトです。システムで 100 テラバイトを超える GFS2 ファイルシステムが必要な場合には Red Hatサービス担当者にご連絡ください。

ファイルシステムのサイズを確定する際は復元時のニーズを考慮してください。非常に大きなファイルシステムでの fsck コマンドの実行は時間がかかり、メモリーを大量に消費することになります。また、ディスクやディスクのサブシステムで障害が発生すると、その復元時間は使用するバックアップメディアの速度によって制限されます。

Red Hat Cluster Suite で設定する場合、Red Hat GFS2 のノードは Red Hat Cluster Suite の設定および管理ツールで設定し、管理することができます。Red Hat GFS2 により、Red Hat クラスター内のGFS2 ノード群でデータを共有でき、このノード群全体で整合性のあるファイルシステム名前空間の単一ビューが提供されます。これにより、異なる複数のノード上の複数プロセスが GFS2 のファイル群を共有できるようになり、その共有方法は同じノード上の複数のプロセスが 1 つのローカルファイルシステム上のファイル群を共有する場合と同様で、両者にはっきり識別できる違いはありません。Red HatCluster Suite の詳細については、『Cluster Administration』ガイドを参照してください。

GFS2 はリニアボリュームまたはミラーボリュームとなる論理ボリューム (LVM で作成) 上に作成してください。Red Hat Cluster Suite の LVM で作成した論理ボリュームは CLVM (クラスター全体でのLVM の実装) で管理し、CLVM デーモンの clvmd で有効にして Red Hat Cluster Suite のクラスター内で実行します。このデーモンにより、LVM2 を使用してクラスター全体で複数の論理ボリュームを管理できるようになり、クラスター内のすべてのノードが論理ボリュームを共有できるようになります。論理ボリュームマネージャーについては、「論理ボリュームマネージャーの管理」ガイドを参照してください。

gfs2.ko カーネルモジュールは GFS2 ファイルシステムを実装しており、GFS2 クラスターノードにロードされます。

クラスター化ストレージと非クラスター化ストレージの GFS2 ファイルシステムの作成と設定の総合的な情報は、Red Hat の「Global File System 2」ガイドを参照してください。

第第7章章 GLOBAL FILE SYSTEM 2

61

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/logical_volume_manager_administration/index

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/global_file_system_2/index

第8章 NETWORK FILE SYSTEM (NFS)ネットワークファイルシステム (NFS) を利用すると、リモートのホストはネットワーク経由でファイルシステムをマウントし、そのファイルシステムをローカルにマウントしているファイルシステムと同じように操作することができるようになります。また、システム管理者は、リソースをネットワーク上の中央サーバーに統合することができるようになります。

この章では、基本的な NFS の概念と補足的な情報に焦点を絞って説明します。

8.1. NFS の概要

現在、Red Hat Enterprise Linux には以下の 2 つの主要バージョンの NFS が含まれています。

NFS バージョン 3 (NFSv3) は安全な非同期書き込みをサポートしており、以前の NFSv2 よりもエラー処理において安定しています。64 ビットのファイルサイズとオフセットもサポートしているため、クライアントは 2 GB を超えるファイルデータにアクセスできます。

NFS バージョン 4 (NFSv4) はファイアウォールやインターネットを介して動作し、rpcbindサービスを必要とせず、ACL に対応し、ステートフルな操作を利用します。

Red Hat Enterprise Linux は 7.4 リリース以来、NFS バージョン 4.2 (NFSv4.2) に完全に対応しています。

以下は Red Hat Enterprise Linux 7.5 における NFSv4.2 の機能です。

サーバー側のコピー: NFSv4.2 は copy_file_range() システム呼び出しに対応しています。これにより、NFS クライアントはネットワークリソースを無駄にせずに、効率よくデータをコピーできます。

スパースファイル: ファイルの容量効率を検証し、プレースホルダーを許可してストレージ効率を向上します。これは、1 つ以上のホールを持つファイルです。これらのホールは、割り当てられていない、または初期化されていないゼロのみから成るデータブロックです。NFSv4.2 の lseek() 操作は seek_hole() と seek_data() に対応しています。これにより、アプリケーションがスパースファイルにホールの場所をマッピングできるようになります。

スパース予約: ストレージサーバーが空き領域を予約することを許可します。これにより、サーバーで領域が不足することがなくなります。NFSv4.2 は、スペースを予約するための allocate() 操作、スペースの予約を解除するための deallocate() 操作、およびファイル内のスペースの事前割り当てまたは割り当て解除を行う fallocate() 操作をサポートしています。

ラベル付き NFS: データアクセス権を強制し、NFS ファイルシステム上の個々のファイルに対して、クライアントとサーバー間の SELinux ラベルを有効にします。

レイアウト拡張: NFSv4.2 では、新しい操作 layoutstats() を利用できます。この操作では、クライアントがレイアウトとの通信についてのメタサーバーを通知するのに使用できます。

最大 4.1 までの 7.4 以前のバージョンの Red Hat Enterprise Linux

NFSv4.1 の機能は次のとおりです。

ネットワークのパフォーマンスとセキュリティーを強化し、Parallel NFS (pNFS) のクライアント側サポートも含みます。

コールバックに個別の TCP 接続を必要としなくなりました。これにより、NAT やファイアウォールが干渉した場合など、クライアントと通信できない場合でも NFS サーバーは委任を許可できます。


62

応答が失われて、操作が 2 回送信された場合に特定の操作が不正確な結果を返すことがあるという以前の問題を防ぐために、1 回限りのセマンティクスを提供します (リブート操作を除く)。

NFS クライアントはデフォルトで NFSv4.1 を使用してマウントを試みます。サーバーが NFSv4.1 に対応していない場合は、NFSv4.0 にフォールバックします。サーバーが NFSv4.0 に対応していない場合は、NFSv3 にフォールバックします。

注記注記

NFS バージョン 2 (NFSv2) は、Red Hat のサポート対象外になりました。

NFS の全バージョンで、IP ネットワーク経由で実行する Transmission Control Protocol (TCP) を使用することができ、NFSv4 の場合は TCP が必須になります。NFSv3 では IP ネットワーク経由で実行するUser Datagram Protocol (UDP) を使用してクライアントとサーバー間のステートレスなネットワーク接続を提供することができます。

UDP で NFSv3 を使用する場合、(通常の状況では) ステートレスな UDP 接続のプロトコルのオーバーヘッドは TCP より少なくなります。つまり、クリーンで適度なトラフィックのネットワーク上では、UDP の方がパフォーマンスがよくなります。ただし、UDP はステートレスのため、予期しないサーバーダウンなどが発生すると、UDP クライアントはサーバーの要求でネットワークを飽和させ続けます。また、UDP の場合にフレームがなくなると、RPC 要求全体を再転送しなければならなくなります。一方、TCP の場合、再送信が必要なのは失ったフレームのみになります。こうした理由から NFSサーバーへの接続には TCP プロトコルが推奨されます。

マウントおよびロックのプロトコルが NFSv4 プロトコルに組み込まれています。サーバーは、一般的に使用されている TCP ポート 2049 でもリッスンします。このように、NFSv4 では、デーモン rpcbind[1]、 lockd、rpc.statd とのやりとりが必要なくなります。rpc.mountd デーモンは、NFS サーバーでエクスポートをセットアップするのに必要ですが、送信オペレーションには関与しません。

注記注記

Red Hat Enterprise Linux では、TCP が NFS バージョン 3 のデフォルトの転送プロトコルになります。UDP は互換性に必要となる場合は使用できますが、その使用範囲についてはできるだけ限定することを推奨しています。NFSv4 には TCP が必須となります。

すべての RPC/NFS デーモンには '-p' コマンドラインオプションがあり、ポートを設定することができるため、ファイアウォールの設定が容易になります。

TCP ラッパーによってクライアントにアクセスが許可されると、NFS サーバーは、/etc/exports 設定ファイルを参照して、そのクライアントがエクスポート済みファイルシステムへのアクセスできるかどうかを確認します。アクセスが可能なことが確認されると、そのユーザーは、ファイルおよびディレクトリーへの全操作を行えるようになります。

重要重要

ファイアーウォールを有効にしている Red Hat Enterprise Linux のデフォルトインストールで NFS を正しく動作させるために、IPTables は、デフォルトの TCP ポート 2049 に設定してください。IPTables が正しく設定されていないと、NFS は正常に動作しません。

NFS の初期化スクリプトおよび rpc.nfsd プロセスでは、システム起動中の指定ポートへのバインドが可能になりました。ただし、このポートが使用できない場合や、別のデーモンと競合してしまう場合は、エラーが発生しやすくなる可能性があります。

第第8章章 NETWORK FILE SYSTEM (NFS)

63

8.1.1. 必須サービス

Red Hat Enterprise Linux では、NFS ファイル共有を提供するのに、カーネルベースのサポートとデーモンのプロセスの組み合わせを使用します。NFS のすべてのバージョンは、クライアントとサーバー間の Remote Procedure Call (RPC) に依存します。Red Hat Enterprise Linux 7 での RPC サービスは rpcbind サービスで制御されます。NFS ファイルシステムの共有やマウントには、実装されているNFS のバージョンに応じて次のようなサービスが連携して動作することになります。

注記注記

portmap サービスは、Red Hat Enterprise Linux の旧バージョンで、RPC プログラム番号を、IP アドレスとポート番号の組み合わせにマッピングするのに使用されていました。このサービスは、Red Hat Enterprise Linux 7 でIPv6 に対応にするため、rpcbind に置き換えられています。

nfs

systemctl start nfs により NFS サーバーおよび該当の RPC プロセスが起動し、共有 NFS ファイルシステムの要求が処理されます。

nfslock

systemctl start nfs-lock は、適切な RPC プロセスを起動する必須サービスをアクティベートし、NFS クライアントがサーバー上のファイルをロックできるようにします。

rpcbind

rpcbind で、ローカルの RPC サービスからポート予約を受け取ると、これらのポートはリモートのRPC サービスによってアクセス可能であることが公開されます。rpcbind は、RPC サービスの要求に応答し、要求された RPC サービスへの接続のセットアップを行います。NFSv4 では rpcbind は使用されません。

以下の RPC プロセスは NFS サービスと連携して動作します。

rpc.mountd

NFS サーバーは、このプロセスを使用して NFSv3 クライアントの MOUNT 要求を処理します。要求されている NFS 共有が現在 NFS サーバーで公開されているか、またその共有へのクライアントのアクセスが許可されているかをチェックします。マウントの要求が許可されると、rpc.mountdサーバーは Success ステータスで応答し、この NFS 共有用の File-Handle を NFS クライアントに戻します。

rpc.nfsd

rpc.nfsd では、サーバーが公開している明示的な NFS のバージョンとプロトコルを定義できます。NFS クライアントが接続するたびにサーバースレッドを提供するなど、NFS クライアントの動的なデマンドに対応するため、Linux カーネルと連携して動作します。このプロセスは nfs サービスに対応します。

lockd

lockd はクライアントとサーバーの両方で実行されるカーネルスレッドです。Network LockManager (NLM) プロトコルを実装し、NFSv3 のクライアントがサーバー上でファイルのロックを行えるようにします。NFS サーバーが実行中で、NFS ファイルシステムがマウントされていれば、このプロセスは常に自動的に起動します。

rpc.statd


64

Network Status Monitor (NSM) RPC プロトコルを実装します。NFS サーバーが正常にシャットダウンされず再起動すると、NFS クライアントに通知します。 rpc.statd は、nfslock サービスによって自動的に起動されるため、ユーザー設定を必要としません。このプロセスは NFSv4 では使用されません。

rpc.rquotad

リモートユーザーのユーザークォータ情報を提供します。rpc.rquotad は nfs サービスによって自動的に起動するため、ユーザー設定を必要としません。

rpc.idmapd

rpc.idmapd は、ネットワーク上の NFSv4 の名前 ( user@domain 形式の文字列) とローカルの UIDおよび GID とのマッピングを行う NFSv4 クライアントアップコールおよびサーバーアップコールを提供します。idmapd を NFSv4 で正常に動作させるには、 /etc/idmapd.conf ファイルを設定する必要があります。最低でもNFSv4 マッピングドメインを定義する「Domain」パラメーターを指定する必要があります。NFSv4 マッピングドメインが DNS ドメイン名と同じであると、このパラメーターをスキップできます。クライアントとサーバーが ID マッピングの NFSv4 マッピングドメインに一致しないと、適切に動作しません。

注記注記

Red Hat Enterprise Linux 7 では、NFSv4 サーバーのみが rpc.idmapd を使用します。NFSv4 はキーリングベースの idmapper の nfsidmap を使用します。nfsidmapは要求に応じてカーネルによって呼び出され、ID マッピングを実行するスタンドアロンプログラムで、デーモンではありません。nfsidmap に問題がある場合、クライアントは rpc.idmapd を使用してフォールバックします。nfsidmap の詳細は、nfsidmap の man ページを参照してください。

8.2. NFS クライアントの設定

mount コマンドの使用でクライアント側に NFS 共有をマウントします。その形式は次のようになります。

# mount -t nfs -o options server:/remote/export /local/directory

このコマンドは以下のような変数を使用します。

options

マウントオプションのカンマ区切りの一覧です。有効な NFS マウントオプションの詳細は、「一般的な NFS マウントオプション」を参照してください。

サーバーサーバー

マウント予定のファイルシステムをエクスポートするサーバーのホスト名、IP アドレス、または完全修飾型ドメイン名

/remote/export

サーバーからエクスポートされるファイルシステム/ディレクトリー、つまり、マウントするディレクトリー

/local/directory

/remote/export をマウントする必要のあるクライアントの場所


65

Red Hat Enterprise Linux 7 で使用される NFS プロトコルのバージョンは、mount オプション nfsvers、またはvers で識別できます。デフォルトでは、mount は、mount -t nfs の形で NFSv4 を使用します。サーバーが NFSv4 をサポートしない場合は、サーバーでサポートされているバージョンにクライアントが自動的に格下げをします。nfsvers/vers オプションを使用して、サーバーでサポートされない特定のバージョンを渡すと、マウントは失敗します。また、ファイルシステムタイプ nfs4も、レガシー用に使用可能です。これは、mount -t nfs -o nfsvers=4 host:/remote/export /local/directory の実行と同じ意味を持ちます。

詳細は、man mount を参照してください。

NFS 共有が手動でマウントされると、その共有は次のブートでは自動的にマウントされません。RedHat Enterprise Linux はブート時にリモートファイルシステムを自動的にマウントするために以下の 2つの方法を提供します。 /etc/fstab ファイルと autofs サービスです。詳細は、「/etc/fstab を使用したNFS ファイルシステムのマウント」と「autofs」を参照してください。

8.2.1. /etc/fstab を使用した NFS ファイルシステムのマウント

別のマシンから NFS 共有をマウントする代替方法に、/etc/fstab ファイルに行を追加する方法があります。その行には、NFS サーバーのホスト名、エクスポートされるサーバーディレクトリー、およびNFS 共有がマウントされるローカルマシンディレクトリーを記述する必要があります。/etc/fstab ファイルを修正するには root 権限が必要です。

例例8.1 構文の例構文の例

/etc/fstab 内に入れる行の一般的な構文は以下のようになります。

server:/usr/local/pub /pub nfs defaults 0 0

マウントポイントである /pub はこのコマンドを実行する前にクライアントマシン上に存在しなければなりません。クライアントシステムの /etc/fstab にこの行を追加した後は、コマンド mount /pub を使用すると、マウントポイント /pub がサーバーからマウントされます。

NFS エクスポートをマウントするための有効な /etc/fstab エントリーには、以下の情報が含まれている必要があります。

server:/remote/export /local/directory nfs options 0 0

変数である、server、/remote/export、/local/directory、および options は手動で NFS 共有をマウントする際に使用するものと同じです。詳細は、「NFS クライアントの設定」を参照してください。

注記注記

マウントポイント /local/directory は、/etc/fstab が読み込まれる前にクライアント上に存在しなければなりません。そうでないと、マウントは失敗します。

/etc/fstab を編集した後に、システムが新しい設定を登録するように、マウントユニットを再生成します。

# systemctl daemon-reload



66

/etc/fstab の詳細情報については、man fstab を参照してください。

8.3. AUTOFS

/etc/fstab を使用する場合、ユーザーが NFS でマウントしたファイルシステムにそれほど頻繁にはアクセスしなくても、システムにはその使用頻度に関係なくマウントしているファイルシステム専用のリソースを維持しなければならないという弱点があります。マウント数が 1 ~ 2 に限られている場合は問題になりませんが、1 度に数多くのシステムに対して複数のマウントを維持する場合にはシステム全体のパフォーマンスに影響を与える可能性があります。この /etc/fstab の代わりとなるものがカーネルベースの automount ユーティリティーです。自動マウント機能は次の 2 つのコンポーネントで構成されます。

ファイルシステムを実装するカーネルモジュール

他のすべての機能を実行するユーザー領域デーモン

automount ユーティリティーでは NFS ファイルシステムの自動マウントおよび自動アンマウントが可能なため (オンデマンドによるマウント機能)、システムのリソースを節約することができます。このユーティリティーは、AFS、SMBFS、CIFS、およびローカルのファイルシステムなど他のファイルシステムをマウントする場合にも使用することができます。

重要重要

nfs-utils パッケージは「NFS ファイルサーバー」および「ネットワークファイルシステムクライアント」の両グループの一部になっているため、デフォルトではベースグループと一緒にインストールされなくなりました。このため、NFS 共有を自動マウントする前に、nfs-utils がシステムにインストールされていることを確認してください。

また、autofs も「ネットワークファイルシステムクライアント」グループの一部です。

autofs は、デフォルトの主要設定ファイルとして /etc/auto.master (マスターマップ) を使用します。これは、ネームサービススイッチ (NSS) のメカニズムと autofs 設定 (/etc/sysconfig/autofs) を使用して別のネットワークソースと名前を使用するように変更できます。autofs バージョン 4 デーモンのインスタンスはマスターマップ内に設定された各マウントポイントに対して実行されるため、任意のマウントポイントに対してコマンドラインから手動で実行することが可能でした。しかし、autofs バージョン 5 では、設定されたすべてのマウントポイントは 1 つのデーモンを使って管理されるため、これを実行することができなくなりました。すべての自動マウントはマスターマップ内で設定しなければなりません。これは業界標準となる他の自動マウント機能の一般的な要件と一致します。マウントポイント、ホスト名、エクスポートしたディレクトリー、および各種オプションは各ホストに対して手作業で設定するのではなく、すべて 1 つのファイルセット (またはサポートされている別のネットワークソース) 内に指定することができます。

8.3.1. autofs バージョン 5 の改善点 (バージョン 4 との比較)

autofs バージョン 5 をバージョン 4 と比較した場合の特長を以下に示します。

ダイレクトマップサポートダイレクトマップサポート

ファイルシステム階層内の任意のポイントでファイルシステムを自動マウントするメカニズムは autofs 内の複数のダイレクトマップで提供されます。1 つのダイレクトマップはそのマスターマップ内の /- マウントポイントで表されます。１つのダイレクトマップ内にある複数のエントリーにはキーとして絶対パス名が含まれます (インダイレクトマップでは相対パス名が使用される)。

レイジーマウントとアンマウントのサポートレイジーマウントとアンマウントのサポート


67

一つのキーの配下の複数マウントポイントから構成される階層はマルチマウントマップの複数エントリーで表されます。 -hosts マップなどがその例で、一般的には /net/host 配下の任意のホストにあるエクスポートをすべてマルチマウントマップのエントリとして自動マウントするために使用します。 -hosts マップを使用する場合、 /net/host に対して ls を行うと host にある各エクスポート用の autofs で起動するマウントをマウントします。つまり、アクセスが発生するとエクスポートがマウントされ、一定時間アクセスがないとマウントの有効期限が切れます。サーバーにアクセスする際に大量のエクスポートがある場合、必要とされるアクティブなマウント数を大幅に減少させることができます。

LDAP サポートの強化サポートの強化

autofs の設定ファイル (/etc/sysconfig/autofs) により、サイトが実装する autofs のスキーマを指定できる仕組みが提供されます。このため、アプリケーション自体で試行錯誤してスキーマを確定する必要がなくなります。また、認証済みの LDAP サーバーへのバインドにも対応するようになり、一般的な LDAP サーバー実装でサポートしているほとんどのメカニズムを使用するようにます。このため /etc/autofs_ldap_auth.conf という新しい設定ファイルが追加されています。使用法はこの XML 形式を使用するデフォルト設定ファイル自体に記載されています。

Name Service Switch (nsswitch) 設定を適切に処理設定を適切に処理

特定の設定データをどこから取り込むのかを指定する場合に使用するのが Name Service Switch 設定ファイルです。データのアクセスには同一のソフトウェアインターフェースを維持しながら、管理者が使用するバックエンドのデータベースの選択には柔軟性を持たせることができるようになります。バージョン 4 の自動マウント機能では NSS 設定の処理が徐々に向上されていましたが十分とは言えませんでした。一方、 Autofs バージョン 5 ではニーズに対応できる完全実装となります。

このファイルでサポートされている構文についてはman nsswitch.conf を参照してください。すべての NSS データベースが有効なマップソースであるとは限らないため、無効なマップソースはパーサーによって拒否されることに注意してください。ファイル、yp、nis、nisplus、ldap、hesiod などが有効なソースになります。

１１つのつの autofs マウントポイントに対して複数のマスターマップのエントリーマウントポイントに対して複数のマスターマップのエントリー

頻繁に使用されるのにまだ説明していないのがダイレクトマウントポイント /- に対する複数のマスターマップのエントリーの処理についてです。各エントリのマップキーがマージされて 1つのマップとして動作します。

例例8.2 １１つのつの autofs マウントポイントに対して複数のマスターマップのエントリーマウントポイントに対して複数のマスターマップのエントリー

以下は、ダイレクトマウント用の connectathon テストマップの一例です。

/- /tmp/auto_dcthon/- /tmp/auto_test3_direct/- /tmp/auto_test4_direct

8.3.2. autofs の設定

自動マウント機能の主要設定ファイルは /etc/auto.master になります。これがマスターマップとも呼ばれるもので、「autofs バージョン 5 の改善点 (バージョン 4 との比較)」で説明しているように変更することも可能です。マスターマップにはシステム上で autofs によって制御されているマウントポイントおよびその該当設定ファイルまたは自動マウントマップと呼ばれるネットワークソースが記載されています。マスターマップの形式は以下のようになります。


68

mount-point map-name options

この形式で使用されている変数を以下に示します。

mount-point

autofs のマウントポイント、/home などになります。

map-name

マウントポイントの一覧とマウントポイントがマウントされるファイルシステムの場所が記載されているマップソース名です。

options

オプションが与えられている場合、該当マップ内のすべてのエントリにそのオプションが適用されます。エントリー自体にはオプション指定を行いません。オプションが累積されていた autofs バージョン 4 とは異なる動作になります。混合環境の互換性を実装させるため変更が加えられています。

例例8.3 /etc/auto.master ファイルファイル

以下に /etc/auto.master ファイル内にある行の一例を示します (cat /etc/auto.master で表示)。

/home /etc/auto.misc

マップの一般的な形式はそのマスターマップと同じですが、マスターマップではエントリーの末尾に表示される「オプション (options)」がマウントポイント (mount-point) と場所 (location) の間に表示されます。

mount-point [options] location

この形式で使用されている変数を以下に示します。

mount-point

autofs のマウントポイントを参照しています。これは 1 インダイレクトマウントの単一ディレクトリー名であっても、複数のダイレクトマウント用のマウントポイントの完全パスであっても構いません。ダイレクトマップとインダイレクトマップの各エントリーキー ( mount-point) の後に空白で区切られたオフセットディレクトリー (「/」で始まるサブディレクトリー名) が記載されます。これがマルチマウントエントリーと呼ばれるものです。

options

オプションが与えられている場合、そのマップエントリー用のマウントオプションになります。エントリー自体にはオプション指定を行いません。

location

ローカルファイルシステムのパス (Sun マップ形式のエスケープ文字「:」が先頭に付き、マップ名が/ で始まる)、NFS ファイルシステム、他の有効なファイルシステムの場所などのファイルシステムの場所を参照します。

以下は、マップファイルのサンプルコンテンツです (例: /etc/auto.misc)。


69

payroll -fstype=nfs personnel:/dev/hda3sales -fstype=ext3 :/dev/hda4

マップファイルの先頭コラムは autofs マウントポイントを示しています (sales と payroll、サーバー名が personnel)。2 番目のコラムは autofs マウントのオプションを示し、3 番目のコラムはマウントのソースを示しています。上記の場合、/home/payroll と /home/sales がautofs マウントポイントになります。 -fstype= は省略されることが多く、一般的には正常な動作に特に必要とされません。

ディレクトリーが存在していない場合は自動マウント機能によりそのディレクトリーが作成されます。自動マウント機能が起動する前からディレクトリーが存在している場合にはそのディレクトリーの削除は行われません。

automount デーモンを起動するには、以下のコマンドを使用します。

# systemctl start autofs

automount デーモンを再起動するには、以下のコマンドを使用します。

# systemctl restart autofs

所定の設定を使用して /home/payroll/2006/July.sxc などのアンマウントされている autofs ディレクトリーへのアクセスが要求されると、自動マウントのデーモンがそのディレクトリーを自動的にマウントすることになります。タイムアウトが指定されている場合は、タイムアウト期間中にそのディレクトリーへのアクセスがないと自動的にアンマウントされます。

automount デーモンのステータスを表示するには、以下のコマンドを使用します。

# systemctl status autofs

8.3.3. サイトの設定ファイルの無効化/拡大

クライアントシステム上の特定マウントポイントのサイトデフォルト値を無効にする場合に便利です。たとえば、次のような状況を想定してみます。

自動マウント機能のマップが NIS に格納され、 /etc/nsswitch.conf ファイルには次のようなディレクティブがあるとします。

automount: files nis

auto.master ファイルには次が含まれます。

+auto.master

NIS auto.master マップファイルには以下が含まれます。

/home auto.home

NIS auto.home マップには、以下が含まれます。

beth fileserver.example.com:/export/home/bethjoe fileserver.example.com:/export/home/joe* fileserver.example.com:/export/home/&


70

/etc/auto.home ファイルマップは存在しません。

このような状況でクライアントシステムが NIS マップの auto.home を無効にして、ホームのディレクトリーを別のサーバーからマウントする必要があると仮定します。クライアントは次のような /etc/auto.master マップを使用する必要があります。

/home /etc/auto.home+auto.master

/etc/auto.home マップには次のエントリーが含まれます。

* labserver.example.com:/export/home/&

自動マウント機能で処理されるのは 1 番目に出現するマウントポイントのみになるため、/home にはNIS auto.home マップではなく、/etc/auto.home のコンテンツが含まれます。

一方、サイト全体の auto.home マップにいくつかのエントリーを加えて拡大させたい場合は、 /etc/auto.home ファイルマップを作成して新しいエントリーを組み込み、最後に NIS auto.home マップを組み込みます。/etc/auto.home ファイルマップは次のようになります。

mydir someserver:/export/mydir+auto.home

NIS auto.home マップの条件により、ls /home コマンドは以下を出力します。

beth joe mydir

autofs は読み込み中のファイルマップと同じ名前のファイルマップの内容を組み込まないため、上記の例は期待通りに動作します。このように autofs は nsswitch 設定内の次のマップソースに移動します。

8.3.4. LDAP を使用した自動マウント機能のマップの格納

LDAP から自動マウント機能のマップを取得するよう設定しているシステムにはすべて LDAP クライアントのライブラリーをインストールしておかなければなりません。Red Hat Enterprise Linux なら、openldap パッケージは automounter の依存パッケージとして自動的にインストールされるはずです。LDAP アクセスを設定する際は /etc/openldap/ldap.conf ファイルを編集します。BASE、URI、スキーマなどが使用するサイトに適した設定になっていることを確認してください。

自動マウント機能のマップを LDAP に格納するために既定された最新のスキーマが rfc2307bis に記載されています。このスキーマを使用する場合は、スキーマの定義のコメント文字を取り除き autofs 設定 (/etc/sysconfig/autofs) 内にセットする必要があります。

例例8.4 autofs 設定のセッティング設定のセッティング

DEFAULT_MAP_OBJECT_CLASS="automountMap"DEFAULT_ENTRY_OBJECT_CLASS="automount"DEFAULT_MAP_ATTRIBUTE="automountMapName"DEFAULT_ENTRY_ATTRIBUTE="automountKey"DEFAULT_VALUE_ATTRIBUTE="automountInformation"

設定内でコメントされていないスキーマエントリーが上記だけであることを確認しま


71

設定内でコメントされていないスキーマエントリーが上記だけであることを確認します。automountKey は rfc2307bis スキーマの cn 属性を置換します。以下は、LDAP Data InterchangeFormat (LDIF) 設定のサンプルです。

例例8.5 LDF の設定の設定

# extended LDIF## LDAPv3# base <> with scope subtree# filter: (&(objectclass=automountMap)(automountMapName=auto.master))# requesting: ALL#

# auto.master, example.comdn: automountMapName=auto.master,dc=example,dc=comobjectClass: topobjectClass: automountMapautomountMapName: auto.master

# extended LDIF## LDAPv3# base <automountMapName=auto.master,dc=example,dc=com> with scope subtree# filter: (objectclass=automount)# requesting: ALL#

# /home, auto.master, example.comdn: automountMapName=auto.master,dc=example,dc=comobjectClass: automountcn: /home

automountKey: /homeautomountInformation: auto.home

# extended LDIF## LDAPv3# base <> with scope subtree# filter: (&(objectclass=automountMap)(automountMapName=auto.home))# requesting: ALL#

# auto.home, example.comdn: automountMapName=auto.home,dc=example,dc=comobjectClass: automountMapautomountMapName: auto.home

# extended LDIF## LDAPv3# base <automountMapName=auto.home,dc=example,dc=com> with scope subtree# filter: (objectclass=automount)# requesting: ALL#


72

# foo, auto.home, example.comdn: automountKey=foo,automountMapName=auto.home,dc=example,dc=comobjectClass: automountautomountKey: fooautomountInformation: filer.example.com:/export/foo

# /, auto.home, example.comdn: automountKey=/,automountMapName=auto.home,dc=example,dc=comobjectClass: automountautomountKey: /automountInformation: filer.example.com:/export/&

8.4. 一般的な NFS マウントオプション

リモートホストに NFS を使用してファイルシステムをマウントする以外にも、マウントした共有を簡単に使用できるようマウント時に指定できるオプションがあります。これらのオプションは、手動で mount コマンド、/etc/fstab 設定、autofs などを実行する場合に使用できます。

以下に NFS マウントに一般的に使用されているオプションを示します。

lookupcache=mode

特定マウントポイントのディレクトリーエントリーのキャッシュをカーネルにどのように管理させるかを指定します。mode に使用できる引数は、all、none、pos/positive になります。

nfsvers=version

使用する NFS プロトコルのバージョンを指定します。version は 3、4 のいずれかになります。複数の NFS サーバーを実行するホスト群に便利です。バージョンを指定しないと、NFS はカーネルおよび mount コマンドで対応している最近のバージョンを使用します。

vers オプションは nfsvers と同一であり、互換性を持たせる目的で本リリースに含まれています。

noacl

ACP の処理をすべてオフにします。古いバージョンの Red Hat Enterprise Linux、Red Hat Linux、Solaris と連動させる場合に必要となることがあります。こうした古いシステムには、最新の ACL テクノロジーに対する互換性がないためです。

nolock

ファイルのロック機能を無効にします。この設定は、非常に古いバージョンの NFS サーバーに接続する場合に必要となる場合があります。

noexec

マウントしたファイルシステムでバイナリーが実行されないようにします。互換性のないバイナリーを含む、Linux 以外のファイルシステムをマウントしている場合に便利です。

nosuid

set-user-identifier または set-group-identifier ビットを無効にします。リモートユーザーが setuidプログラムを実行しても、必要以上の特権を得られないようにします。

port=num

NFS サーバーポートの数値を指定します。num を 0 (デフォルト値) にすると、mount は、使用す


73

NFS サーバーポートの数値を指定します。num を 0 (デフォルト値) にすると、mount は、使用するポート番号に関するリモートホストの rpcbind サービスのクエリーを実行します。リモートホストの NFS デーモンがその rpcbind サービスに登録されていない場合は、標準の NFS ポート番号TCP 2049 が代わりに使用されます。

rsize=num およびおよび wsize=num

これらのオプションは、単一の NFS 読み取りまたは書き込み操作で転送される最大バイト数を設定します。

rsize と wsize には固定のデフォルト値はありません。デフォルトでは、NFS はサーバーとクライアントの両方がサポートしている最大の値を使用します。Red Hat Enterprise Linux 7 では、クライアントとサーバーの最大値は 1,048,576 バイトです。詳細は、ナレッジベースの記事「What are thedefault and maximum values for rsize and wsize with NFS mounts?」を参照してください。

sec=mode

デフォルト設定は sec=sys で、ローカルの UNIX UID および GID を使用します。 AUTH_SYS を使用して NFS 操作を認証します。

sec=krb5 は、ユーザー認証に、ローカルの UNIX UID と GID ではなく Kerberos V5 を使用します。

sec=krb5i は、ユーザー認証に Kerberos V5 を使用し、データの改ざんを防ぐ安全なチェックサムを使って、NFS 動作の整合性チェックを行います。

sec=krb5p は、ユーザー認証に Kerberos V5 を使用し、整合性チェックを実行し、トラフィックの傍受を防ぐため NFS トラフィックの暗号化を行います。これが最も安全な設定になりますが、パフォーマンスのオーバーヘッドも最も高くなります。

tcp

NFS マウントが TCP プロトコルを使用するよう指示します。

udp

NFS マウントが UDP プロトコルを使用するよう指示します。

詳細は、man mountとman nfs を参照してください。

8.5. NFS サーバーの起動と停止

前提条件

NFSv2 または NFSv3 接続に対応しているサーバーについては、rpcbind[1] サービスを実行している必要があります。rpcbind がアクティブであるかどうかを確認するには、以下のコマンドを使用します。

$ systemctl status rpcbind

rpcbind を必要としない NFSv4 のみのサーバーを設定するには、「NFSv4 専用サーバーの設定」を参照します。

Red Hat Enterprise Linux 7.0 では、NFS サーバーが NFSv3 をエクスポートし、ブート時に起動するようになっている場合は、nfs-lock サービスを手動で起動して有効化する必要があります。


74

https://access.redhat.com/solutions/753853

# systemctl start nfs-lock# systemctl enable nfs-lock

Red Hat Enterprise Linux 7.1 以降では、必要に応じて nfs-lock が自動的に開始し、手動での有効化を試みると失敗します。

手順

NFS サーバーを起動するには、次のコマンドを使用します。

# systemctl start nfs

起動時に NFS を起動できるようにするには、以下のコマンドを使用します。

# systemctl enable nfs

サーバーを停止させるには、以下を使用します。

# systemctl stop nfs

restart オプションは、NFS をいったん停止させてから起動し直す手順を一度に行うことができる短縮オプションです。NFS の設定ファイルを変更してから、その変更を有効にする際の最も効率的な方法です。このサーバーを再起動するには、以下のコマンドを使用します。

# systemctl restart nfs

/etc/sysconfig/nfs ファイルを編集したら、以下のコマンドを実行して nfs-config サービスを再起動し、新しい値が適用されるようにします。

# systemctl restart nfs-config

try-restart コマンドは、nfs が現在稼働中である場合に限り起動させます。このコマンドは、Red Hat init スクリプトの condrestart (conditional restart) と同様、NFS が実行されていないとデーモンを起動しないため便利です。

条件付きでサーバーを再起動するには、以下を入力します。

# systemctl try-restart nfs

サービスを再起動せずに NFS サーバー設定ファイルの再読み込みを実行するには、以下のように入力します。

# systemctl reload nfs

8.6. NFS サーバーの設定

NFS サーバーのエクスポートを設定する方法は 2 つあります。

NFS の設定ファイル /etc/exports を手動で編集する方法。

コマンドラインで、コマンド exportfs を使用する方法。


75

8.6.1. /etc/exports 設定ファイル

/etc/exports ファイルは、リモートホストにどのファイルシステムをエクスポートするかを制御し、オプションを指定します。以下の構文ルールに従います。

空白行は無視する。

コメント行は、ハッシュ記号 (#) で始める。

長い行はバックスラッシュ (\) を使って折り返す。

エクスポートするファイルシステムは、それぞれ 1 行で指定する。

許可するホストの一覧は、エクスポートするファイルシステムの後に空白文字を追加し、その後に追加する。

各ホストのオプションは、ホスト識別子の直後に括弧を追加し、その中に指定する。ホストと最初の括弧の間には空白を入れない。

エクスポートするファイルシステムのエントリーは、以下のように指定します。

export host(options)

ここでは、以下のような変数を使用しています。

export

エクスポートするディレクトリー

host

エクスポートを共有するホストまたはネットワーク

options

host に使用するオプション

各ホストにそれぞれオプションを付けて、複数のホストを 1 行で指定することができます。この場合は、以下のように、各ホスト名の後に、そのホストに対するオプションを括弧を付けて追加します。ホストは空白文字で区切ります。

export host1(options1) host2(options2) host3(options3)

ホスト名を指定する別の方法は、「ホスト名の形式」を参照してください。

最も簡単な方法は、/etc/exports ファイルに、エクスポートするディレクトリーと、そのディレクトリーへのアクセスを許可するホストを指定するだけです。以下の例のようになります。

例例8.6 /etc/exports ファイルファイル

/exported/directory bob.example.com

この例では、bob.example.com が、 NFS サーバーの /exported/directory/ をマウントできます。ここではオプションが指定されていないため、NFS では、デフォルトデフォルト設定が使用されます。


76

デフォルトの設定は以下のようになります。

ro

エクスポートするファイルシステムは読み込み専用です。リモートホストは、このファイルシステムで共有されているデータを変更することができません。このファイルシステムで変更 (読み書き)を可能にするには、rw オプションを指定します。

sync

NFS サーバーは、以前の要求で発生した変更がディスクに書き込まれるまで、要求に応答しません。代わりに非同期書き込みを有効にするには、async オプションを指定します。

wdelay

NFS サーバーは、別の書き込み要求が差し迫っていると判断すると、ディスクへの書き込みを遅らせます。これにより、複数の書き込みコマンドが同じディスクにアクセスする回数を減らすことができるため、書き込みのワークロードが低下し、パフォーマンスが向上します。これを無効にするには、no_wdelay を指定します。no_wdelay は、デフォルトの sync オプションが指定されている場合に限り利用可能になります。

root_squash

(ローカルからではなく) リモートリモートから接続している root ユーザーが root 権限を持つことを阻止します。代わりに、そのユーザーには、NFS サーバーによってユーザー ID nfsnobody がく割り当てられます。これにより、リモートの root ユーザーの権限を、最も低いローカルユーザーレベルにまで下げ (squash) て、権限を持たずにリモートサーバーに書き込むのを阻止します。no_root_squash と指定すると、この root squashing が無効になります。

(root を含む) すべてのリモートユーザーの権限を下げるには、all_squash を使用します。特定ホストのリモートユーザーに対して、NFS サーバーが割り当てるユーザー ID とグループ ID を指定するには、anonuid と anongid のオプションをそれぞれ以下のように使用します。

export host(anonuid=uid,anongid=gid)

ここで、uid と gid はそれぞれ、ユーザー ID 番号およびグループ ID 番号です。 anonuid と anongid のオプションを使用することで、リモート NFS ユーザーが共有する特別なユーザーおよびグループアカウントを作成できるようになります。

デフォルトでは、access control lists (アクセス制御リスト) (ACL) は、Red Hat Enterprise Linux ではNFS によってサポートされています。この機能を無効にするには、ファイルシステムをエクスポートする際に no_acl オプションを指定します。

エクスポートするファイルシステムのデフォルトはすべて、明示的に上書きする必要があります。たとえば、rw オプションを指定しないと、エクスポートするファイルシステムは読み込み専用として共有されます。以下は、/etc/exports の例になりますが、ここでは 2 つのデフォルトオプションを上書きしています。

/another/exported/directory 192.168.0.3(rw,async)

このエントリーでは、192.168.0.3 が /another/exported/directory/ を読み込み書き込マウントできるように設定しています。そして、ディスクへの書き込みはすべて非同期となります。エクスポートオプションの詳細は、man exportfs を参照してください。

さらに、デフォルト値が指定されていないオプションも利用できます。たとえば、サブツリーチェックを無効にする、安全でないポートからのアクセスの許可する、安全でないファイルロックを許可する(一部の初期 NFS クライアント実装で必要) などの機能があります。あまり使用されないオプションの


77

詳細は、man exports を参照してください。

重要重要

/etc/exports ファイルでは、特に空白文字ついては、非常に厳しく扱われます。ホストとエクスポートされるファイルシステムの間、そしてホスト同士の間には、必ず空白文字を挿入してください。また、それ以外の場所 (コメント行を除く) には、絶対に空白文字を追加しないでください。

たとえば、以下の 2 つの行は意味が異なります。

/home bob.example.com(rw)/home bob.example.com (rw)

最初の行は、bob.example.com からのユーザーにのみ、/home ディレクトリーへの読み/書きアクセスを許可します。２番目の行は、bob.example.com からのユーザーには、ディレクトリーを読み込み専用 (デフォルト) でマウントすることを許可しており、その他のユーザーには、読み込み/書き込みでマウントすることを許可します。

8.6.2. exportfs コマンド

NFS 経由でリモートユーザーにエクスポートされているすべてのファイルシステム、並びにそれらのファイルシステムのアクセスレベルは /etc/exports ファイル内に一覧表示してあります。nfs サービスが開始すると、/usr/sbin/exportfs コマンドが起動してこのファイルを読み込み、実際のマウントプロセスのために制御を rpc.mountd (NFSv3の場合) とその後にrpc.nfsd に渡します。この時点でファイルシステムがリモートユーザーに使用可能になります。

/usr/sbin/exportfs コマンドを手動で発行すると、root ユーザーは NFS サービスを再開始せずにディレクトリーをエクスポートするか、しないかを選択できるようになります。適切なオプションが与えられると、/usr/sbin/exportfs コマンドはエクスポートしたファイルシステムを /var/lib/nfs/xtab に書き込みます。rpc.mountd はファイルシステムへのアクセス権限を決定する際に xtab ファイルを参照するため、エクスポートしたファイルシステム一覧への変更はすぐに反映されます。

/usr/sbin/exportfs で利用可能な一般的なオプションの一覧は以下のようになります。

-r

/etc/exports 内に一覧表示してあるすべてのディレクトリーから /etc/lib/nfs/xtab 内に新しいエクスポート一覧を構成することにより、それらのディレクトリーがエクスポートされることになります。結果的にこのオプションが /etc/exports 内のいずれかの変更でエクスポート一覧をリフレッシュすることになります。

-a

/usr/sbin/exportfs に渡される他のオプションに応じて、すべてのディレクトリーがエクスポートされるか、またはされないことになります。他のオプションが指定されない場合は、/usr/sbin/exportfs は、/etc/exports 内に指定してあるすべてのファイルシステムをエクスポートします。

-o file-systems

/etc/exports 内に一覧表示されていないエクスポートされるディレクトリーを指定します。file-systems の部分を、エクスポートされるファイルシステムに置き換えます。これらのファイルシステムは、/etc/exports で指定されたものと同じフォーマットでなければなりません。このオプション


78

は、多くの場合、エクスポート用ファイルシステム一覧に永続的に追加する前に、エクスポート予定のファイルシステムをテストするために使用されます。/etc/exports 構文の詳細は、「/etc/exports 設定ファイル」を参照してください。

-i

/etc/exports を無視します。コマンドラインから出されたオプションのみが、エクスポート用ファイルシステムの定義に使用されます。

-u

すべての共有ディレクトリーをエクスポートしません。コマンド /usr/sbin/exportfs -ua は、すべての NFS デーモンを稼働状態に維持しながら、NFS ファイル共有を保留します。NFS 共有を再度有効にするには、exportfs -r を使用します。

-v

詳細表示を意味します。exportfs コマンドを実行するときに表示されるエクスポート、または非エクスポートのファイルシステムの情報が、より詳細に表示されます。

exportfs コマンドにオプションを渡さない場合と、現在エクスポートされているファイルシステムの一覧が表示されます。exportfs コマンドの詳細については、man exportfs を参照してください。

8.6.2.1. NFSv4 でで exportfs の使用の使用

Red Hat Enterprise Linux 7 では、提示されるファイルシステムは自動的に同じパスを使用して NFSv3およびNFSv4 クライアントで利用可能になるため、NFSv4 のエクスポートを設定するための特別なステップは必要ありません。これは、以前のバージョンとの相違点です。

クライアントが NFSv4 を使用しないようにするには、/etc/sysconfig/nfs に RPCNFSDARGS= -N 4を設定し、NFSv4 の使用を停止します。

8.6.3. ファイアウォール背後での NFS の実行

NFS には、rpcbind が必要です。これは、RPC サービスにポートを動的に割り当て、ファイアウォールルールの構成に問題を引き起こす可能性があります。クライアントがファイアウォールの背後にあるNFS 共有にアクセスできるようにするには、/etc/sysconfig/nfs ファイルを編集して、RPC サービスを実行するポートを設定します。クライアントがファイアウォールを介して RPC クォータにアクセスできるようにするには、「ファイアウォールからの RPC クォータを許可する」を参照してください。

/etc/sysconfig/nfs ファイルは、デフォルトではすべてのシステムに存在しているわけではありません。/etc/sysconfig/nfs が存在しない場合は作成し、以下を指定します。

RPCMOUNTDOPTS="-p port"

これにより、rpc.mount コマンドラインに「-p port」が追加され、rpc.mount -p port になります。

nlockmgr サービスが使用するポートを指定するには、/etc/modprobe.d/lockd.conf ファイルの nlm_tcpport オプションと nlm_udpport オプションに、ポート番号を設定します。

NFS の起動に失敗すると、/var/log/messages がチェックされます。一般的に、すでに使用されているポート番号を指定した場合に NFS の起動に失敗します。/etc/sysconfig/nfs の編集後、以下のコマンドを実行して nfs-config サービスを再起動し、Red Hat Enterprise Linux 7.2 以下のバージョンで新しい値が反映されるようにします。

# systemctl restart nfs-config


79

NFS サーバーを再起動します。

# systemctl restart nfs-server

rpcinfo -p を実行し、変更が反映されたことを確認します。

注記注記

NFSv4.0 コールバックがファイアウォールを通過するように許可するには、/proc/sys/fs/nfs/nfs_callback_tcpport をセットして、サーバーがクライアント上のそのポートに接続できるようにします。

このプロセスは、NFSv4.1 またはそれ以降には必要ありません。そして mountd、statd、および lockd のための他のポート群は純粋な NFSv4 環境では必要ありません。

8.6.3.1. NFS エクスポートの検出エクスポートの検出

NFS サーバーがエクスポートするファイルシステムを発見する方法は２種類あります。

NFSv3 をサポートするいずれかのサーバー上で、showmount コマンドの使用です。

$ showmount -e myserverExport list for mysever/exports/foo/exports/bar

NFSv4 t 対応のサーバーで、root ディレクトリーをマウントマウントします。

# mount myserver:/ /mnt/# cd /mnt/exports# ls exportsfoobar

NFSv4 と NFSv3 の両方をサポートするサーバーでは、上記の方法はいずれも機能し、同じ結果を出します。

注記注記

Red Hat Enterprise Linux 6 以前には、設定の仕方によって旧来の NFS サーバーは別々のパス経由で NFSv4 クライアントにファイルシステムをエクスポートすることがありました。それらのサーバーではデフォルトで NFSv4 を有効にしていないため、これは問題にはなっていません。

8.6.4. ファイアウォールからの RPC クォータを許可する

ディスククォータを使用するファイルシステムをエクスポートする場合は、クォータ RPC (RemoteProcedure Call) サービスを使用して、NFS クライアントにディスククォータデータを提供できます。

手順手順8.1 ファイアウォールの背後でファイアウォールの背後で RPC クォータのアクセスを可能にするクォータのアクセスを可能にする


80

1. rpc-rquotad サービスを有効にするには、以下のコマンドを使用します。

# systemctl enable rpc-rquotad

2. rpc-rquotad サービスを起動するには、以下のコマンドを使用します。

# systemctl start rpc-rquotad

rpc-rquotad が有効な場合は、nfs-server サービスが起動した後に自動的に起動します。

3. ファイアウォールの背後で、クォータ RPC サービスにアクセスできるようにするには、UDPポートまたは TCP ポート 875 を開く必要があります。デフォルトのポート番号は /etc/services ファイルに指定します。

デフォルトのポート番号は、/etc/sysconfig/rpc-rquotad ファイルの RPCRQUOTADOPTS 変数に -p port-number を追加すると上書きできます。

4. /etc/sysconfig/rpc-rquotad ファイルへの変更を有効にするには、rpc-rquotad を再起動します。

# systemctl restart rpc-rquotad

リモートホストにクォータを設定するデフォルトでは、リモートホストだけがクォーターを読み込めます。クォータを設定できるようにするには、/etc/sysconfig/rpc-rquotad ファイルの RPCRQUOTADOPTS 変数に -S オプションを追加します。

/etc/sysconfig/rpc-rquotad ファイルへの変更を有効にするには、rpc-rquotad を再起動します。

# systemctl restart rpc-rquotad

8.6.5. ホスト名の形式

ホストは以下の形式にすることができます。

単独マシン単独マシン

完全修飾型ドメイン名 (サーバーで解決可能な形式)、ホスト名 (サーバーで解決可能な形式)、あるいは IP アドレス

ワイルドカードで指定された一連のマシンワイルドカードで指定された一連のマシン

* または ? の文字を使用して文字列の一致を指定します。ワイルドカードは IP アドレスでは使用しないことになっていますが、逆引き DNS ルックアップが失敗した場合には偶然に機能するかも知れません。ワイルドカードを完全修飾型ドメイン名に指定する時は、ドット(.) はワイルドカードの一部にはなりません。例えば、*.example.com はone.example.com を範囲に入れますがone.two.example.com はその範囲に入りません。

IP ネットワークネットワーク

a.b.c.d/z を使用します。ここで、a.b.c.d はネットワークであり、z はネットマスクのビット数です(例えば、 192.168.0.0/24)。別の使用可能形式は a.b.c.d/netmask となり、ここで a.b.c.d がネットワークで、netmask がネットマスクです (例えば、 192.168.100.8/255.255.255.0)。

Netgroup


81

形式 @group-name を使用します。ここで、group-name は NIS netgroup の名前です。

8.6.6. RDMA で NFS の有効化 (NFSoRDMA)

Red Hat Enterprise Linux 7 では、RDMA に対応するハードウェアが存在すると、RDMA (remote directmemory access) サービスが自動的に有効になります。

RDMA 上で NFS を有効化するには:

1. rdma と rdma-core パッケージをインストールします。

/etc/rdma/rdma.conf ファイルにはデフォルトで XPRTRDMA_LOAD=yes が設定されており、NFSoRDMA クライアントクライアントモジュールをロードする rdma サービスが必要になります。

2. NFSoRDMA サーバーサーバーモジュールを自動的にロードするには、/etc/rdma/rdma.conf に SVCRDMA_LOAD=yes 行を追加します。

/etc/sysconfig/nfs ファイルの RPCNFSDARGS="--rdma=20049" は、NFSoRDMA サービスがクライアントをリッスンするポート番号 (20049) を指定します。『RFC 5667』では、RDMA で NFSv4 サービスを提供する場合は、サーバーがポート 20049 をリッスンすることが定められています。

3. /etc/rdma/rdma.conf ファイルを編集したら、nfs サービスを再起動します。


以前のカーネルバージョンで /etc/rdma/rdma.conf の変更を有効にするには、システムを再起動する必要があります。

8.6.7. NFSv4 専用サーバーの設定

デフォルトで、NFS サーバーは Red Hat Enterprise Linux 7 の NFSv2、NFSv3、および NFSv4 接続をサポートします。ただし、NFS バージョン 4.0 以降のみをサポートするように NFS を設定することもできます。NFSv4 では rpcbind サービスがネットワークをリッスンする必要がないため、これにより、システム上で開いているポートと実行中のサービスの数が最小限に抑えられます。

NFS サーバーが NFSv4 専用として設定されていると、NFSv2 または NFSv3 を使用して共有をマウントしようとするクライアントは、次のようなエラーでマウントに失敗します。

要求された NFS バージョンまたはトランスポートプロトコルがサポートされていません。

手順手順8.2 NFSv4 専用サーバーの設定専用サーバーの設定

NFS サーバーを NFS バージョン 4.0 以降のみをサポートするように設定する方法を説明します。

1. /etc/sysconfig/nfs 設定ファイルに以下の行を追加して、NFSv2、NFSv3、UDP を無効化します。

RPCNFSDARGS="-N 2 -N 3 -U"

2. 任意で、RPCBIND、MOUNT、および NSM プロトコル呼び出しのリッスンを無効にします。これは NFSv4 専用の場合は不要です。


82

https://tools.ietf.org/html/rfc5667

これらのオプションを無効にすると、次のような影響があります。

NFSv2 または NFSv3 を使用してサーバーから共有をマウントしようとするクライアントが応答しなくなります。

NFS サーバー自体が NFSv2 および NFSv3 ファイルシステムをマウントできなくなります。

これらのオプションを無効にするには:

以下の行を /etc/sysconfig/nfs ファイルに追加します。

RPCMOUNTDOPTS="-N 2 -N 3"

関連サービスを無効化します。

# systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket

3. NFS サーバーを再起動します。


変更は、NFS サーバーを起動または再起動するとすぐに反映されます。

NFSv4 専用の設定の確認専用の設定の確認

netstat ユーティリティーを使用することで、NFS サーバーが NFSv4 専用モードで設定されていることを確認できます。

以下は、NFSv4 専用サーバーでの netstat の出力例です。RPCBIND、MOUNT、NSM のリッスンも無効になります。nfs が唯一リッスンする NFS サービスとなります。

# netstat -ltu

Active Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:nfs 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN tcp 0 0 localhost:smtp 0.0.0.0:* LISTEN tcp6 0 0 [::]:nfs [::]:* LISTEN tcp6 0 0 [::]:12432 [::]:* LISTEN tcp6 0 0 [::]:12434 [::]:* LISTEN tcp6 0 0 localhost:7092 [::]:* LISTEN tcp6 0 0 [::]:ssh [::]:* LISTEN udp 0 0 localhost:323 0.0.0.0:* udp 0 0 0.0.0.0:bootpc 0.0.0.0:* udp6 0 0 localhost:323 [::]:*

NFSv4 専用サーバーを設定する前の netstat 出力には、sunrpc と mountd サービスが含まれます。

# netstat -ltu

Active Internet connections (only servers)


83

Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:nfs 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:36069 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:52364 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:sunrpc 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:mountd 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN tcp 0 0 localhost:smtp 0.0.0.0:* LISTEN tcp6 0 0 [::]:34941 [::]:* LISTEN tcp6 0 0 [::]:nfs [::]:* LISTEN tcp6 0 0 [::]:sunrpc [::]:* LISTEN tcp6 0 0 [::]:mountd [::]:* LISTEN tcp6 0 0 [::]:12432 [::]:* LISTEN tcp6 0 0 [::]:56881 [::]:* LISTEN tcp6 0 0 [::]:12434 [::]:* LISTEN tcp6 0 0 localhost:7092 [::]:* LISTEN tcp6 0 0 [::]:ssh [::]:* LISTEN udp 0 0 localhost:323 0.0.0.0:* udp 0 0 0.0.0.0:37190 0.0.0.0:* udp 0 0 0.0.0.0:876 0.0.0.0:* udp 0 0 localhost:877 0.0.0.0:* udp 0 0 0.0.0.0:mountd 0.0.0.0:* udp 0 0 0.0.0.0:38588 0.0.0.0:* udp 0 0 0.0.0.0:nfs 0.0.0.0:* udp 0 0 0.0.0.0:bootpc 0.0.0.0:* udp 0 0 0.0.0.0:sunrpc 0.0.0.0:* udp6 0 0 localhost:323 [::]:* udp6 0 0 [::]:57683 [::]:* udp6 0 0 [::]:876 [::]:* udp6 0 0 [::]:mountd [::]:* udp6 0 0 [::]:40874 [::]:* udp6 0 0 [::]:nfs [::]:* udp6 0 0 [::]:sunrpc [::]:*

8.7. NFS のセキュア化

NFS は、システム全体を、既知の大量のホスト群で透過的に共有する場合に適しています。ただし、使いやすさがある反面、さまざまなセキュリティー問題を伴います。サーバーにおける NFS セキュリティーリスクを最低限に抑え、データを保護するために、サーバー上の NFS ファイルシステムをエクスポートする場合や、クライアントにマウントする場合に、以下のセクションを考慮に入れるようにしてください。

8.7.1. AUTH_SYS とエクスポート制御による NFS 保護

従来より、NFS ではエクスポートしたファイルへのアクセスを制御するために 2 種類のオプションを提供しています。

1 つ目は、IP アドレスまたはホスト名を使って、どのホストにどのファイルシステムのマウントを許可するかを、サーバー側で制限するオプションです。

2 つ目は、ローカルユーザーと同じ方法で、サーバーが NFS クライアント上のユーザーに対してファイルシステムの権限を強制するオプションです。従来より、AUTH_SYS (AUTH_UNIX とも言います) を使って行われ、ユーザーの UID や GID の指定はクライアントに依存します。つまり、悪意のあるクライアントや誤って設定されたクライアントがこれを誤用し、ファイルへのアクセスを許可すべきではないユーザーに対して、ファイルへのアクセスを簡単に与えてしまうことができるため注意が必要です。


84

こうしたリスクを抑えるため、管理者によって共通のユーザーおよびグループ ID へのユーザー権限が取り消されたり、読み取り専用のアクセスに制限されたりすることがよくあります。ただし、こうしたソリューションは NFS 共有が当初意図されていた方法で使用されることを制限することになります。

また、NFS ファイルシステムをエクスポートしているシステムで使用している DNSサーバーのコントロールが攻撃者に奪われると、特定のホスト名または完全修飾ドメイン名に関連付けられているシステムが、未承認のマシンに向かう可能性があります。この時、NFS マウントには、これ以上の安全確保を目的としたユーザー名やパスワード情報の交換が行われないため、この未承認のマシンが NFS 共有のマウントを許可されたシステムになってしまいます許可されたシステムになってしまいます。

NFS 経由でディレクトリーのエクスポートを行う際にワイルドカードを使用する場合は慎重に行ってください。ワイルドカードの対象が予定よりも広い範囲のシステムを対象とする可能性があります。

また、TCP ラッパーで rpcbind[1] サービスへのアクセスを制限することも可能です。iptables でルールを作成しても rpcbind、rpc.mountd、rpc.nfsd などによって使用されるポートへのアクセスを制限することができます。

NFS および rpcbind に対する安全対策については man iptables を参照してください。

8.7.2. AUTH_GSS による NFS の保護

NFSv4 には、RPCSEC_GSS および Kerberos バージョン 5 の GSS-API メカニズムの実装が義務付けられ、NFS セキュリティーに大きな変革がもたらされました。ただし、RPCSEC_GSS や Kerberos のメカニズムは、NFS のいずれのバージョンでも利用できます。FIPS モードでは、FIPS が許可するアルゴリズムのみを使用できます。

AUTH_SYS とは異なり、RPCSEC_GSS Kerberos メカニズムでは、ファイルにアクセスしているユーザーを正確に表示することを、サーバーがクライアントに依存しなくなりました。代わりに、暗号を使用してサーバーに対してユーザー認証を行うため、Kerberos 情報を持たない悪意あるクライアントがなりすまし攻撃を行うことはできなくなります。RPCSEC_GSS Kerberos メカニズムでは、Kerberos の設定後、追加の変更を行わなくても動作するため、これがマウントをセキュアにする最も簡単な方法となります。

Kerberos の設定NFSv4 Kerberos に対応するサーバーを設定する前に、KDC (Kerberos Key Distribution Centre) をインストールして設定する必要があります。Kerberos は、対象暗号化と信頼されているサードパーティー(KDC) を使用したネットワーク認証システムで、これによりクライアントとサーバーが互いに認証できるようになります。Red Hat は、Kerberos の設定に IdM (Identity Management) を使用することが推奨されます。

手順手順8.3 IdM がが RPCSEC_GSS を使用するように、を使用するように、NFS サーバーおよびクライアントを設定するサーバーおよびクライアントを設定する

1. NFS サーバーサイドに、nfs/hostname.domain@REALM プリンシパルを作成します。

サーバーサイドとクライアントサイドに、host/hostname.domain@REALM プリンシパルを作成します。

クライアントとサーバーの各キータブに該当するキーを追加します。

詳細は、Red Hat Enterprise Linux 7 Linux ドメイン ID、認証、およびポリシーガイド「サービスエントリーおよび Keytab の追加と編集」セクションと「Kerberos 対応の NFS サーバーの設定」セクションを参照してください。

2. サーバーサイドでは、sec= オプションを使用して、必要なセキュリティーフレーバーを有効にします。すべてのセキュリティーフレーバーと非暗号化マウントを有効にするには、次のコマンドを実行します。


85

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/index

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/services.html#adding-service-entry

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/kerb-nfs.html

/export *(sec=sys:krb5:krb5i:krb5p)

sec= オプションを使用するのに有効なセキュリティーフレーバーは、以下のようになります。

sys: 非暗号化保護、デフォルト

krb5: 認証のみ

krb5i: 整合性保護

krb5p: プライバシー保護

3. クライアントサイドでは、sec=krb5 (設定によっては sec=krb5i もしくは sec=krb5p となります) をマウントオプションに追加します。

# mount -o sec=krb5 server:/export /mnt

NFS クライアントの設定方法は、Red Hat Enterprise Linux 7 Linux ドメイン ID、認証、およびポリシーガイドの「Kerberos 対応の NFS クライアントの設定」セクションを参照してください。


Red Hat は IdM を使用することを推奨していますが、AD (Active Directory) Kerberos サーバーもサポート対象となります。詳細は、Red Hat ナレッジベースの記事「How to set up NFSusing Kerberos authentication on RHEL 7 using SSSD and Active Directory」を参照してください。

Kerberos で保護された NFS 共有で root としてファイルを書き込む必要がある場合は、https://access.redhat.com/articles/4040141を参照してください。この設定は推奨されていないことに注意してください。

NFS クライアント設定についての詳細は、exports(5) と nfs(5) マニュアルページと「一般的な NFS マウントオプション」を参照してください。

gssproxy と rpc.gssd を同時に使用する方法など、RPCSEC_GSS フレームワークの詳細は、「GSSD flow description を参照してください」。

8.7.2.1. NFSv4 によるによる NFS の保護の保護

NFSv4 には、Microsoft Windows NT モデルの機能や幅広い導入の経緯があるため、POSIX モデルではなく、Microsoft Windows NT モデルをベースとした ACL サポートが含まれます。

NFSv4 でセキュリティーに関する、もう 1 つの重要な特長は、ファイルシステムをマウントする際に MOUNT プロトコルを使用する必要がなくなりました。この MOUNT プロトコルには、ファイル処理の方法にセキュリティー上欠点がある可能性のあることが指摘されています。

8.7.3. ファイル権限

リモートホストにより、NFS ファイルシステムが読み取り、または読み取り/書き込みの権限でマウントされると、それぞれの共有ファイルを保護できるのはその権限のみになります。同じユーザー ID 値を共有している 2 ユーザーが同じ NFS ファイルシステムをマウントすると、それらのユーザーはファイルを相互に変更することができます。さらに、クライアントシステムに root としてログインするいずれのユーザーも、su - コマンドを使用して NFS 共有経由のファイルにすべてアクセスできます。

デフォルトでは、アクセス制御リスト (ACL) は Red Hat Enterprise Linux 環境下の NFS によってサ


86

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/index

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/kerb-nfs.html#krb-nfs-client


https://access.redhat.com/articles/4040141

http://www.citi.umich.edu/projects/nfsv4/gssd/

デフォルトでは、アクセス制御リスト (ACL) は Red Hat Enterprise Linux 環境下の NFS によってサポートされます。Red Hat は、この機能を有効な状態にしておくことを推奨しています。

NFS はファイルシステムをエクスポートする際に、デフォルトで root squash の機能を使用します。これにより、そのローカルマシン上で root ユーザーとして NFS 共有にアクセスするすべてのユーザーのID は nobody に設定されます。Root squash 機能はデフォルトオプションの root_squash で制御されます。このオプションの詳細については、「/etc/exports 設定ファイル」を参照してください。できる限りこの root squash 機能は無効にしないでください。

NFS 共有を読み取り専用でエクスポートする場合、all_squash オプションの使用を考慮してください。このオプションにより、エクスポートしたファイルシステムにアクセスするすべてのユーザーは nfsnobody ユーザーのユーザー ID を取得します。

8.8. NFS と RPCBIND

注記注記

次のセクションは、後方互換用に rpcbind サービスを必要とする NFSv3 の実装のみに適用されます。

rpcbind を必要としない NFSv4 のみのサーバーを設定する方法は、「NFSv4 専用サーバーの設定」を参照してください。

rpcbind[1] ユーティリティーは、RPC サービスを、それらのサービスがリッスンするポートにマッピングします。RPC のプロセスが開始すると、その開始が rpcbind に通知され、そのプロセスがリッスンしているポートおよびそのプロセスが処理することが予想される RPC プログラム番号が登録されます。クライアントシステムが、特定の RPC プログラム番号を使って、サーバーの rpcbind との通信が行われると、rpcbind サービスによりクライアントが適切なポート番号にリダイレクトされ、要求されたサービスと通信できるようになります。

RPC ベースのサービスは、クライアントの受信要求の接続を確立するのに、必ず rpcbind を使用します。したがって、RPC ベースのサービスが起動する前に、rpcbind が利用可能な状態にする必要があります。

rpcbind サービスはアクセス制御に TCP ラッパーを使用するため、 rpcbind のアクセス制御ルールはRPC ベースのすべてのすべてのサービスに影響します。代わりに、NFS RPC の各デーモンごとにアクセス制御ルールを指定することも可能です。こうしたルールの正確な構文に関しては rpc.mountd および rpc.statd の man ページに記載されている情報を参照してください。

8.8.1. NFS および rpcbind に関するトラブルシューティング

rpcbind[1] では通信に使用するポート番号と RPC サービス間の調整を行うため、トラブルシューティングを行う際は rpcbind を使って現在の RPC サービスの状態を表示させると便利です。rpcinfo コマンドを使用すると RPC ベースの各サービスとそのポート番号、RPC プログラム番号、バージョン番号、および IP プロトコルタイプ (TCP または UDP) が表示されます。

rpcbind に対して適切な RPC ベースの NFS サービスが有効になっていることを確認するには、次のコマンドを使用します。

# rpcinfo -p

例例8.7 rpcinfo -p コマンドの出力コマンドの出力


87

以下に上記コマンドの出力例を示します。

program vers proto port service 100021 1 udp 32774 nlockmgr 100021 3 udp 32774 nlockmgr 100021 4 udp 32774 nlockmgr 100021 1 tcp 34437 nlockmgr 100021 3 tcp 34437 nlockmgr 100021 4 tcp 34437 nlockmgr 100011 1 udp 819 rquotad 100011 2 udp 819 rquotad 100011 1 tcp 822 rquotad 100011 2 tcp 822 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100005 1 udp 836 mountd 100005 1 tcp 839 mountd 100005 2 udp 836 mountd 100005 2 tcp 839 mountd 100005 3 udp 836 mountd 100005 3 tcp 839 mountd

正しく開始していない NFS サービスが 1 つでもあると、rpcbind は、そのサービスのクライアントから正しいポートに RPC 要求をマッピングできません。多くの場合、rpcinfo 出力に NFS がない場合、NFS を再起動すると rpcbind に正しく登録され、機能を開始します。

rpcinfo の詳細およびオプション一覧については man ページを参照してください。

8.9. PNFS

Parallel NFS (pNFS) のサポートは、NFS v4.1 標準の一部として Red Hat Enterprise Linux 6.4 で提供されました。pNFS アーキテクチャーは NFS の拡張性を向上させるため、パフォーマンスが強化される場合もあります。つまり、サーバーが pNFS も実装した場合、クライアントは同時に複数サーバーを介してデータにアクセスできるようになります。3 つのストレージプロトコルまたはレイアウト (ファイル、オブジェクト、ブロック) に対応します。

注記注記

このプロトコルは、ファイル、オブジェクト、ブロックの 3 つの pNFS レイアウトタイプに対応します。ただし、Red Hat Enterprise Linux 6.4 クライアントが対応しているレイアウトタイプはファイルだけで、オブジェクトとブロックはテクノロジープレビューになります。

pNFS Flex ファイルFlexible Files (フレキシブルファイル) は、pNFS の新しいレイアウトです。これは、スタンドアローンの NFSv3 と NFSv4 サーバーのスケールアウト名前空間への集約が可能になります。Flex Files 機能は、RFC 7862 仕様で説明しているように NFSv4.2 規格の一部です。

Red Hat Enterprise Linux は Red Hat Enterprise Linux 7.4 以来、Flex Files サーバーから NFS 共有をマウントできます。


88

pNFS 共有のマウント

pNFS 機能を有効化するには、NFS バージョン 4.1 またはそれ以降の pNFS を有効化したサーバーから shares (共有) をマウントします。

# mount -t nfs -o v4.1 server:/remote-export /local-directory

サーバーで pNFS を有効にすると、最初のマウント時に nfs_layout_nfsv41_files カーネルが自動的に読み込まれます。出力のマウントエントリーには minorversion=1 が含まれているはずです。以下のコマンドを使用して、モジュールが読み込まれたことを確認します。

$ lsmod | grep nfs_layout_nfsv41_files

Flex Files に対応したサーバーから Flex Files 機能を持つ NFS 共有をマウントするには、

# mount -t nfs -o v4.2 server:/remote-export /local-directory

nfs_layout_flexfiles モジュールがロードされているかどうかを検証します。

$ lsmod | grep nfs_layout_flexfiles

関連情報pNFS の詳細情報は、http://www.pnfs.com を参照してください。

8.10. NFS で PNFS SCSI レイアウトを有効にする

NFS サーバーとクライアントを構成して、データにアクセスするために pNFS SCSI レイアウトを使用できます。pNFS SCSI は、ファイルへの長時間のシングルクライアントアクセスを伴うユースケースで有益です。

前提条件

クライアントとサーバーの両方が SCSI コマンドを同じブロックデバイスに送信できるようにする必要があります。つまり、ブロックデバイスは共有 SCSI バス上にある必要があります。

ブロックデバイスに XFS ファイルシステムが含まれている必要があります。

SCSI デバイスは、SCSI-3 Primary Commands 仕様で説明されている SCSI PersistentReservations に対応する必要があります。

8.10.1. pNFS SCSI レイアウト

SCSI レイアウトは、pNFS ブロックレイアウトの作業に基づいています。レイアウトは SCSI デバイス全体で定義されます。これには、SCSI 永続予約に対応できる論理ユニット (LU) として、一連の固定サイズブロックが含まれます。LU デバイスは、SCSI デバイス ID により識別されます。

pNFS SCSI は、ファイルへの長時間の単一クライアントアクセスを伴うユースケースで良好に機能します。例としては、クラスターを収容するメールサーバーまたは仮想マシンが挙げられます。

クライアントとサーバーとの間の操作クライアントとサーバーとの間の操作NFS クライアントがファイルの読み取りまたは書き込みを行うと、クライアントは LAYOUTGET 操作を実行します。サーバーは、SCSI デバイス上のファイルの場所で応答します。クライアントは、使用する SCSI デバイスを決定するために、GETDEVICEINFO の追加操作の実行が必要になる場合がありま


89

http://www.pnfs.com

す。この操作が正しく機能すると、クライアントが READ 操作および WRITE 操作をサーバーに送信する代わりに、SCSI デバイスに直接 I/O 要求を発行できます。

クライアント間のエラーまたは競合により、サーバーがレイアウトを取り消すか、クライアントにレイアウトを発行しない可能性があります。この場合、クライアントは、I/O 要求を SCSI デバイスに直接送信する代わりに、サーバーに READ 操作および WRITE 操作を発行するようにフォールバックします。

操作を監視するには、「pNFS SCSI レイアウト機能の監視」を参照してください。

デバイスの予約デバイスの予約pNFS SCSI は、予約の割り当てを介してフェンシングを処理します。サーバーはクライアントにレイアウトを発行する前に、SCSI デバイスを予約して、登録済みのクライアントのみがデバイスにアクセスできるようにします。クライアントがその SCSI デバイスにコマンドを発行できるが、デバイスに登録されていない場合、そのデバイスでのクライアントからの多くの操作は失敗します。たとえば、サーバーがクライアントにそのデバイスのレイアウトを与えていない場合は、クライアントの blkid コマンドは XFS ファイルシステムの UUID の表示に失敗します。

サーバーは、自身の永続的な予約を削除しません。これにより、クライアントとサーバーを再起動しても、デバイス上のファイルシステム内のデータが保護されます。SCSI デバイスの用途を変えるには、NFS サーバー上の永続的な予約を手動で削除することが必要になる場合があります。

8.10.2. pNFS と互換性のある SCSI デバイスの確認

この手順では、SCSI デバイスが pNFS SCSI レイアウトをサポートしているかどうかを確認します。


sg3_utils パッケージをインストールします。

# yum install sg3_utils

手順手順8.4 pNFS と互換性のあると互換性のある SCSI デバイスの確認デバイスの確認

サーバーとクライアントの両方で、適切な SCSI デバイスのサポートを確認します。

# sg_persist --in --report-capabilities --verbose path-to-scsi-device

Persist Through Power Loss Active (電力損失が発生しても持続する) (PTPL_A) ビットが設定されていることを確認します。

例例8.8 pNFS SCSI に対応するに対応する SCSI デバイスデバイス

以下は、pNFS SCSI に対応する SCSI デバイスの sg_persist 出力の例です。PTPL_A ビットは 1 を報告します。

inquiry cdb: 12 00 00 00 24 00 Persistent Reservation In cmd: 5e 02 00 00 00 00 00 20 00 00 LIO-ORG block11 4.0 Peripheral device type: diskReport capabilities response: Compatible Reservation Handling(CRH): 1 Specify Initiator Ports Capable(SIP_C): 1 All Target Ports Capable(ATP_C): 1 Persist Through Power Loss Capable(PTPL_C): 1


90

Type Mask Valid(TMV): 1 Allow Commands: 1 Persist Through Power Loss Active(PTPL_A): 1 Support indicated in Type mask: Write Exclusive, all registrants: 1 Exclusive Access, registrants only: 1 Write Exclusive, registrants only: 1 Exclusive Access: 1 Write Exclusive: 1 Exclusive Access, all registrants: 1


man ページの sg_persist(8)

8.10.3. サーバーでの pNFS SCSI の設定

この手順では、pNFS SCSI レイアウトをエクスポートするように NFS サーバーを構成します。

手順手順8.5 サーバーでのサーバーでの pNFS SCSI の設定の設定

1. サーバーで、SCSI デバイスに作成された XFS ファイルシステムをマウントします。

2. NFS バージョン 4.1 以降をエクスポートするように NFS サーバーを構成します。/etc/nfs.confファイルの [nfsd] セクションで次のオプションを設定します。

[nfsd]

vers4.1=y

3. pnfs オプションを使用して、NFS 経由で XFS ファイルシステムをエクスポートするようにNFS サーバーを構成します。

例例8.9 pNFS SCSI をエクスポートするためのをエクスポートするための /etc/exports のエントリーのエントリー

/etc/exports 設定ファイルの次のエントリーは、/exported/directory/ にマウントされたファイルシステムを、pNFS SCSI レイアウトとして allowed.example.com クライアントにエクスポートします。

/exported/directory allowed.example.com(pnfs)


NFS サーバーの構成の詳細は、「NFS サーバーの設定」を参照してください。

8.10.4. クライアントでの pNFS SCSI の設定

この手順では、pNFS SCSI レイアウトをマウントするように NFS クライアントを構成します。


NFS サーバーは、pNFS SCSI 経由で XFS ファイルシステムをエクスポートするように構成されています。「サーバーでの pNFS SCSI の設定」を参照してください。


91

れています。「サーバーでの pNFS SCSI の設定」を参照してください。

手順手順8.6 クライアントでのクライアントでの pNFS SCSI の設定の設定

クライアントで、NFS バージョン 4.1 以降を使用して、エクスポートされた XFS ファイルシステムをマウントします。

# mount -t nfs -o nfsvers=4.1 host:/remote/export /local/directory

NFS なしで XFS ファイルシステムを直接マウントしないでください。


NFS 共有のマウントの詳細は、「NFS クライアントの設定」を参照してください。

8.10.5. サーバーでの pNFS SCSI 予約の解放

この手順では、NFS サーバーが SCSI デバイスに保持している永続的な予約を解放します。これにより、pNFS SCSI をエクスポートする必要がなくなったときに SCSI デバイスを再利用できます。

サーバーから予約を削除する必要があります。別の IT Nexus から削除することはできません。


sg3_utils パッケージをインストールします。

# yum install sg3_utils

手順手順8.7 サーバーでのサーバーでの pNFS SCSI 予約の解放予約の解放

1. サーバーにある予約をクエリーします。

# sg_persist --read-reservation path-to-scsi-device

例例8.10 /dev/sda で予約のクエリーで予約のクエリー

# sg_persist --read-reservation /dev/sda

LIO-ORG block_1 4.0 Peripheral device type: disk PR generation=0x8, Reservation follows: Key=0x100000000000000 scope: LU_SCOPE, type: Exclusive Access, registrants only

2. サーバーの既存の登録を削除します。

# sg_persist --out \ --release \ --param-rk=reservation-key \ --prout-type=6 \ path-to-scsi-device


92

例例8.11 /dev/sda の予約の削除の予約の削除

# sg_persist --out \ --release \ --param-rk=0x100000000000000 \ --prout-type=6 \ /dev/sda

LIO-ORG block_1 4.0 Peripheral device type: disk


man ページの sg_persist(8)

8.10.6. pNFS SCSI レイアウト機能の監視

pNFS クライアントとサーバーが適切な pNFS SCSI 操作を交換するか、通常の NFS 操作にフォールバックするかを監視できます。


pNFS SCSI クライアントおよびサーバーが構成されます。

8.10.6.1. nfsstat を使用したサーバーからのを使用したサーバーからの pNFS SCSI 操作の確認操作の確認

この手順では、nfsstat ユーティリティーを使用して、サーバーからの pNFS SCSI 操作を監視します。

手順手順8.8 nfsstat を使用したサーバーからのを使用したサーバーからの pNFS SCSI 操作の確認操作の確認

1. サーバーから提供される操作を監視します。

# watch --differences \ "nfsstat --server | egrep --after-context=1 read\|write\|layout"

Every 2.0s: nfsstat --server | egrep --after-context=1 read\|write\|layout

putrootfh read readdir readlink remove rename2 0% 0 0% 1 0% 0 0% 0 0% 0 0%--setcltidconf verify write rellockowner bc_ctl bind_conn0 0% 0 0% 0 0% 0 0% 0 0% 0 0%--getdevlist layoutcommit layoutget layoutreturn secinfononam sequence0 0% 29 1% 49 1% 5 0% 0 0% 2435 86%

2. クライアントとサーバーは、次の場合に pNFS SCSI 操作を使用します。

カウンター layoutget、layoutreturn、および layoutcommit の増分。これは、サーバーがレイアウトを提供していることを意味します。

サーバーのカウンター read および write は増加しません。これは、クライアントが SCSIデバイスに対して直接 I/O 要求を実行していることを意味します。


93

8.10.6.2. mountstats を使用したクライアントからのを使用したクライアントからの pNFS SCSI 操作の確認操作の確認

この手順では、/proc/self/mountstats ファイルを使用して、クライアントからの pNFS SCSI 操作を監視します。

手順手順8.9 mountstats を使用したクライアントからのを使用したクライアントからの pNFS SCSI 操作の確認操作の確認

1. 各マウントの操作カウンターの一覧を表示します。

# cat /proc/self/mountstats \ | awk /scsi_lun_0/,/^$/ \ | egrep device\|READ\|WRITE\|LAYOUT

device 192.168.122.73:/exports/scsi_lun_0 mounted on /mnt/rhel7/scsi_lun_0 with fstype nfs4 statvers=1.1 nfsv4: bm0=0xfdffbfff,bm1=0x40f9be3e,bm2=0x803,acl=0x3,sessions,pnfs=LAYOUT_SCSI READ: 0 0 0 0 0 0 0 0 WRITE: 0 0 0 0 0 0 0 0 READLINK: 0 0 0 0 0 0 0 0 READDIR: 0 0 0 0 0 0 0 0 LAYOUTGET: 49 49 0 11172 9604 2 19448 19454 LAYOUTCOMMIT: 28 28 0 7776 4808 0 24719 24722 LAYOUTRETURN: 0 0 0 0 0 0 0 0 LAYOUTSTATS: 0 0 0 0 0 0 0 0

2. その結果では、以下のようになります。

LAYOUT 統計は、クライアントとサーバーが pNFS SCSI 操作を使用する要求を示します。

READ および WRITE の統計は、クライアントとサーバーが NFS 操作にフォールバックする要求を示します。

8.11. NFS リファレンス

NFS サーバーの管理は難しい課題となる場合があります。本章では言及していませんが、NFS 共有のエクスポートやマウントに利用できるオプションは多数あります。詳細は次のソースを参照してください。

インストールされているドキュメント

man mount — NFS のサーバー設定およびクライアント設定に使用するマウントオプションに関して総合的に説明しています。

man fstab — ブート時にファイルシステムをマウントするために使用する /etc/fstab ファイルの形式について記載しています。

man nfs — NFS 固有のファイルシステムのエクスポートおよびマウントオプションについて詳細に説明しています。

man exports — NFS ファイルシステムのエクスポート時に /etc/exports ファイル内で使用する一般的なオプションを表示します。


94

役立つ Web サイト

http://linux-nfs.org — プロジェクトの更新状況を確認できる開発者向けの最新サイトです。

http://nfs.sourceforge.net/ — 開発者向けのホームページで、少し古いですが、役に立つ情報が多数掲載されています。

http://www.citi.umich.edu/projects/nfsv4/linux/ — Linux 2.6 カーネル用 NFSv4 のリソースです。

http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.111.4086 — NFS バージョン 4 プロトコルの機能および拡張機能について記載しているホワイトペーパーです。

関連書籍

『Managing NFS and NIS』 (Hal Stern、Mike Eisler および Ricardo Labiaga 著、O'Reilly &Associates 出版): 各種の NFS エクスポートやマウントオプションについて記載している優れた参考ガイドです。

『NFS Illustrated』 (Brent Callaghan 著、Addison-Wesley Publishing Company 出版): NFS と他のネットワークファイルシステムとの比較、NFS 通信がどのように発生するかなどが詳細に紹介されています。

[1] rpcbind サービスは、旧バージョンの Red Hat Enterprise Linux で、各 RPC プログラムの番号を、IP アドレスのポート番号の組み合わせにマッピングするために使用していた portmap に代わります。詳細は「必須サービス」を参照してください。


95

http://linux-nfs.org

http://nfs.sourceforge.net/

http://www.citi.umich.edu/projects/nfsv4/linux/

http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.111.4086

第9章サーバーメッセージブロック (SMB)サーバーメッセージブロック (SMB) プロトコルは、ファイル共有やプリンター共有などのサーバー上のリソースにアクセスするのに使用されるアプリケーション層ネットワークプロトコルを実装します。Microsoft Windows では、SMB はデフォルトで実装されています。Red Hat Enterprise Linux を使っている場合は、Samba と cifs-utils ユーティリティを使用して、リモートサーバーから SMB 共有をマウントします。

注記注記

SMB のコンテキストでは、SMB ダイアレクトである CIFS (Common Internet FileSystem) プロトコルが言及されています。SMB と CIFS の両方のプロトコルがサポートされており、SMB と CIFS 共有のマウントに関連するカーネルモジュールとユーティリティーはどちらも cifs という名前を使用します。

9.1. SMB 共有の使用

『Red Hat システム管理者のガイド』の『Samba』を参照してください。

9.2. SMB 共有のマウント

Red Hat Enterprise Linux では、カーネルの cifs.ko ファイルシステムモジュールにより、SMB プロトコルを利用できます。ただし、SMB 共有をマウントして作業を行うには、cifs-utils パッケージをインストールする必要があります。

# yum install cifs-utils

cifs-utils パッケージでは、以下を行うためのユーティリティを利用できます。

SMB と CIFS 共有をマウントする

カーネルのキーリングで NT Lan Manager (NTLM) の認証情報を管理する

SMB および CIFS 共有のセキュリティー記述子でアクセス制御リスト (ACL) を設定し、表示する

9.2.1. サポートされている SMB プロトコルバージョン

cifs.ko カーネルモジュールは、以下の SMB プロトコルバージョンに対応しています。

SMB 1

SMB 2.0

SMB 2.1

SMB 3.0

注記注記

プロトコルのバージョンにより、すべての SMB 機能が実装されているわけではありません。


96

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#sect-Samba

9.2.1.1. UNIX 拡張機能のサポート拡張機能のサポート

Samba は、SMB プロトコルの CAP_UNIX 機能ビットを使用して UNIX 拡張機能を提供します。これらの拡張機能は cifs.ko カーネルモジュールでもサポートされています。ただし、Samba とカーネルモジュールはどちらも、SMB 1 プロトコルでのみ UNIX 拡張機能をサポートしています。

UNIX 拡張機能を使用するには、以下の手順を実行します。

1. /etc/samba/smb.conf ファイルの [global] セクションにある server min protocol オプションを NT1 に設定します。これは Samba サーバーのデフォルトです。

2. mount コマンドに -o vers=1.0 オプションを指定し、SMB 1 プロトコルを使用して共有をマウントします。たとえば、次のようになります。

mount -t cifs -o vers=1.0,username=user_name //server_name/share_name /mnt/

デフォルトで、カーネルモジュールは SMB 2 またはサーバーでサポートされている最新のプロトコルバージョンを使用します。-o vers=1.0 オプションを mount コマンドに渡すと、カーネルモジュールは UNIX 拡張機能の使用に必要な SMB 1 プロトコルを使用することを強制されます。

UNIX 拡張機能が有効になっているかどうかを確認するには、マウントされた共有のオプションを表示します。

# mount...//server/share on /mnt type cifs (...,unix,...)

マウントオプションの一覧に unix エントリーが表示されている場合は、UNIX 拡張機能が有効になっています。

9.2.2. SMB 共有の手動マウント

SMB 共有を手動でマウントするには、-t cifs パラメーターで mount ユーティリティを使用します。

# mount -t cifs -o username=user_name //server_name/share_name /mnt/Password for user_name@//server_name/share_name: ********

I-o オプションオプションパラメーターでは、共有のマウントに使用されるオプションを指定できます。詳細は、mount.cifs(8) man ページの「よく使用されるマウントオプション」と『OPTIONS』のセクションを参照してください。

例例9.1 暗号化された暗号化された SMB 3.0 接続を使用した共有のマウント接続を使用した共有のマウント

\\server\example\ 共有を DOMAIN\Administrator ユーザーとして、暗号化 SMB 3.0 接続から /mnt/ディレクトリーにマウントするには以下を実行します。

# mount -t cifs -o username=DOMAIN\Administrator,seal,vers=3.0 //server/example /mnt/Password for user_name@//server_name/share_name: ********

9.2.3. システム起動時の SMB 共有の自動マウント

システムの起動時に SMB 共有を自動的にマウントするには、共有のエントリーを /etc/fstab ファイル

第第9章章サーバーメッセージブロックサーバーメッセージブロック (SMB)

97

システムの起動時に SMB 共有を自動的にマウントするには、共有のエントリーを /etc/fstab ファイルに追加します。たとえば、次のようになります。

//server_name/share_name /mnt cifs credentials=/root/smb.cred 0 0

重要重要

システムが自動的に共有をマウントできるようにするには、ユーザー名、パスワード、およびドメイン名を認証情報ファイルに保存する必要があります。詳細は、「認証情報ファイルを使用した SMB 共有への認証」を参照してください。

/etc/fstab ファイルの 4 番目のフィールドでは、認証情報ファイルへのパスなど、マウントオプションを指定します。詳細は、mount.cifs(8) man ページの「よく使用されるマウントオプション」と『OPTIONS』のセクションを参照してください。

共有が正常にマウントされたことを確認するには、次のように入力します。

# mount /mnt/

9.2.4. 認証情報ファイルを使用した SMB 共有への認証

特定の状況では、管理者がユーザー名とパスワードを入力せずに共有をマウントする必要があります。この場合、認証情報ファイルを作成します。例:

手順手順9.1 認証情報ファイルの作成認証情報ファイルの作成

1. ~/smb.cred などのファイルを作成し、そのファイルのユーザー名、パスワード、およびドメイン名を指定します。

username=user_namepassword=passworddomain=domain_name

2. 所有者だけがファイルにアクセスできるようにパーミッションを設定します。

# chown user_name ~/smb.cred# chmod 600 ~/smb.cred

mount ユーティリティーに credentials=file_name マウントオプションを渡すか、/etc/fstab ファイルでオプションを使用して、ユーザー名とパスワードの入力を求められずに共有をマウントできるようになります。

9.2.5. マルチユーザー SMB マウントの実行

共有をマウントするために指定した認証情報により、デフォルトでマウントポイントのアクセス権が決まります。たとえば、共有をマウントするときに DOMAIN\example ユーザーを使用した場合は、どのローカルユーザーが操作を実行しても、共有に対するすべての操作はこのユーザーとして実行されます。

ただし特定の状況では、システムの起動時に管理者が自動的に共有をマウントしたい場合でも、ユーザーは自分の認証情報を使用して共有のコンテンツに対して操作を実行する必要があります。そんなとき multiuser マウントオプションを使用すると、このシナリオを設定できます。


98

重要重要

multiuser を使用するには、sec=security_type マウントオプションを、認証ファイルとともに krb5 または ntlmssp オプションなど、非対話型の方法で認証情報を与えることのできるセキュリティタイプに設定する必要があります。「ユーザーとしての共有へのアクセス」を参照してください。

root ユーザーは、multiuser オプションと共有の内容への最低限のアクセスを持つアカウントを使用して、共有をマウントします。通常のユーザーは、cifscreds ユーティリティーを使用して、現在のセッションのカーネルキーリングに自分のユーザー名とパスワードを渡すことができます。ユーザーがマウントされた共有のコンテンツにアクセスすると、カーネルは、共有のマウントに最初に使用されたものではなく、カーネルキーリングからの認証情報を使用します。

multiuser オプションによる共有のマウントオプションによる共有のマウント

システムの起動時に、multiuser オプションを使用して自動的に共有をマウントするには、次の手順を実行します。

手順手順9.2 multiuser オプションによるオプションによる /etc/fstab ファイルエントリーの作成ファイルエントリーの作成

1. /etc/fstab ファイルに共有のエントリーを作成します。たとえば、次のようになります。

//server_name/share_name /mnt cifs multiuser,sec=ntlmssp,credentials=/root/smb.cred 0 0

2. 共有をマウントします。

# mount /mnt/

システムの起動時に共有を自動的にマウントしない場合は、-o multiuser,sec=security_type を mount コマンドに渡して手動で共有をマウントします。SMB 共有の手動マウントの詳細は、「SMB 共有の手動マウント」を参照してください。

SMB 共有が共有が multiuser オプションを使用してマウントされているかどうかの確認オプションを使用してマウントされているかどうかの確認

共有が multiuser オプションでマウントされているかどうかを確認するには:

# mount...//server_name/share_name on /mnt type cifs (sec=ntlmssp,multiuser,...)

ユーザーとしての共有へのアクセスユーザーとしての共有へのアクセス

SMB 共有が multiuser オプションを使用してマウントされている場合、ユーザーはサーバーの認証情報をカーネルのキーリングに提供できます。

# cifscreds add -u SMB_user_name server_namePassword: ********

これで、ユーザーがマウントされた SMB 共有を含むディレクトリーで操作を実行すると、サーバーは、共有がマウントされたときに最初に使用されたものではなく、このユーザーのファイルシステムのパーミッションが適用されます。

注記注記


99

注記注記

複数のユーザーが、マウントされた共有上で自分の認証情報を使用して同時に操作を実行できます。

9.2.6. よく使用されるマウントオプション

SMB 共有をマウントすると、マウントオプションにより次のことが決まります。

サーバーとの接続がどのように確立されるか。たとえば、サーバーに接続するときに使用される SMB プロトコルバージョンはどれか。

共有がローカルファイルシステムにどのようにマウントされるか。たとえば、複数のローカルユーザーがサーバー上のコンテンツにアクセスできるようにするために、システムがリモートファイルとディレクトリーのパーミッションを上書きする場合など。

/etc/fstab ファイルの 4 番目のフィールドまたは mount コマンドの -o パラメーターで複数のオプションを設定するには、それらをカンマで区切ります。たとえば、手順9.2「multiuser オプションによる /etc/fstab ファイルエントリーの作成」を参照してください。

次のリストは、よく使用されるマウントオプションの概要を示しています。

表表9.1 よく使用されるマウントオプションよく使用されるマウントオプション

オプションオプション説明説明

credentials=file_name 認証情報ファイルへのパスを設定します。「認証情報ファイルを使用したSMB 共有への認証」を参照してください。

dir_mode=mode サーバーが CIFS UNIX 拡張機能をサポートしていない場合は、ディレクトリーモードを設定します。

file_mode=mode サーバーが CIFS UNIX 拡張機能をサポートしていない場合は、ファイルモードを設定します。

password=password SMB サーバーへの認証に使用されるパスワードを設定します。あるいは、credentials オプションを使用して認証情報ファイルを指定します。

seal SMB 3.0 またはそれ以降のプロトコルバージョンを使用して接続の暗号化サポートを有効化します。よって、vers を 3.0 またはそれ以降に指定して、seal を使用します。例9.1「暗号化された SMB 3.0 接続を使用した共有のマウント」を参照してください。

sec=security_mode ntlmsspi などのセキュリティーモードを設定して、NTLMv2 パスワードハッシュとパケット署名を有効にします。使用できる値のリストは、mount.cifs(8) man ページにあるオプションの説明を参照してください。

サーバーが ntlmv2 セキュリティモードに対応していない場合は、デフォルトの sec=ntlmssp を使用します。セキュリティ上の理由から、安全でない ntlm セキュリティモードは使用しないでください。

username=user_name SMB サーバーへの認証に使用されるユーザー名を設定します。あるいは、credentials オプションを使用して認証情報ファイルを指定します。


100

vers=SMB_protocol_version サーバーとの通信に使用される SMB プロトコルバージョンを設定します。


完全な一覧は、mount.cifs(8) man ページの『OPTIONS』セクションを参照してください。


101

第10章 FS-CACHEFS-Cache とはファイルシステムによって使用される永続的なローカルキャッシュのことです。ネットワーク経由で取得されたデータをローカルのディスクにキャッシングします。ユーザーがネットワーク経由でマウントしているファイルシステムのデータにアクセスする場合にネットワークのトラフィックを最小限に抑えます (NFS など)。

以下に FS-Cache がどのように動作するのかを高次元で図解します。

図図10.1 FS-Cache の概要の概要

FS-Cache はシステムのユーザーおよび管理者に対してできるだけ透過的になるよう設計されています。Solaris の cachefs とは異なり、マウントしたファイルシステムに重ねてマウントすることなくサーバー上のファイルシステムがクライアントのローカルキャッシュと直接相互作用できるようになります。NFS の場合、マウントオプションを使って FS-Cache が有効になっている NFS 共有をマウントするようクライアントに指示します。

FS-Cache はネットワーク経由で動作するファイルシステムの基本的な動作を変更するものではありません。単にファイルシステムにデータをキャッシュできる永続的な場所を提供しているだけです。たとえば、クライアントは FS-Cache が有効になっているかいなかに関わらず NFS 共有をマウントすることができます。また、キャッシュされた NFS はキャッシュに収まらないファイル群を処理することができます (集約的であるか個別であるかを問わない)。これはファイル群を部分的にキャッシュすることができ、前もって完全に読み込む必要性がないためです。また、FS-Cache はクライアントのファイルシステムドライバーのキャッシュで発生したすべての I/O エラーを非表示にします。


102

キャッシングのサービスを提供するには、キャッシュバックエンドが必要になります。キャッシュバックエンドとは、キャッシングサービスを提供するよう設定されたストレージのドライバーを指します(cachefiles)。この場合、FS-Cache には、キャッシュバックエンドとして拡張属性 (ext3 など) や bmap に対応するブロックベースのファイルシステムをマウントしておく必要があります。

FS-Cache はネットワーク経由であるかその他の手段であるかを問わず、ファイルシステムを任意でキャッシュすることはできません。FS-Cache、データの格納および検索、メタデータのセットアップおよび検証などでの相互作用を可能にするよう共有ファイルシステムのドライバーを変更する必要があります。FS-Cache には永続性に対応するためキャッシュしたファイルシステムのインデックスキーおよびコヒーレンスデータが必要になります。インデックスキーはファイルシステムのオブジェクトとキャッシュのオブジェクトを一致させ、コヒーレンスデータはキャッシュのオブジェクトがまだ有効であるかどうかを確定します。

注記注記

Red Hat Enterprise Linux 7 では、cachefilesd はデフォルトでインストールされていないため、手動でインストールする必要があります。

10.1. 性能に関する保証

FS-Cache ではパフォーマンの向上は保証していませんパフォーマンの向上は保証していません。ただし、ネットワーク渋滞を避けることで一貫したパフォーマンスを実現します。キャッシュバックエンドを使用することによりパフォーマンスの低下が起こります。たとえば、キャッシュされた NFS 共有ではネットワーク全体を検索するためディスクへのアクセスが増加します。FS-Cache はできるだけ非同期にするよう試行しますが、これができない同期パス (読み込みなど) があります。

たとえば、2 台のコンピューター間で NFS 共有をキャッシュするために負荷のない GigE ネットワークを介して FS-Cache を使用しても、ファイルのアクセスにおけるパフォーマンスの向上はまったく見られません。むしろ、NFS 要求の場合はローカルディスクではなくサーバーメモリーから対応した方が速くなります。

したがって FS-Cache の使用には、各種の要素間での妥協妥協が伴うと言えます。NFS トラフィックのキャッシュに FS-Cache を使用すると、クライアント側の速度は多少遅くなりますが、ネットワークの帯域幅を使用せずローカルに読み取り要求に対応することでネットワークおよびサーバー側の負荷を大幅に低減させることができます。

10.2. キャッシュの設定

現在、Red Hat Enterprise Linux 7 で提供しているのは cachefiles キャッシングバックエンドのみになります。cachefilesd デーモンにより cachefiles が開始され、管理されます。cachefiles によるキャッシングサービスの提供方法については /etc/cachefilesd.conf ファイルで制御します。

キャッシュバックエンドで最初に行うのはキャッシュとして使用するディレクトリーの設定です。次のパラメーターを使用して行います。

$ dir /path/to/cache

一般的に、キャッシュバックエンドのディレクトリーは以下のように /etc/cachefilesd.conf 内に /var/cache/fscache として設定されます。

$ dir /var/cache/fscache

キャッシュバックエンドディレクトリーを変更する場合は、selinux の内容を /var/cache/fscache と同じにする必要があります。

第第10章章 FS-CACHE

103

# semanage fcontext -a -e /var/cache/fscache /path/to/cache# restorecon -Rv /path/to/cache

キャッシュを設定する際に、/path/to/cache をディレクトリー名に置き換えます。

注記注記

selinux の内容を設定するコマンドが正しく動作いない場合は、以下のコマンドを使用します。

# semanage permissive -a cachefilesd_t# semanage permissive -a cachefiles_kernel_t

FS-Cache は、/path/to/cache をホストするファイルシステム内にキャッシュを格納します。ノートブックでは root ファイルシステム (/) をホストのファイルシステムとして使用することをお勧めします。ただし、デスクトップマシンの場合は、特にキャッシュ用にディスクパーティションをマウントするのは慎重に行ってください。

FS-Cache のキャッシュバックエンドで必要とされる機能に対応するファイルシステムには、次のような Red Hat Enterprise Linux 7 に実装されているファイルシステムが含まれます。

ext3 (拡張属性が有効)

ext4

Btrfs

XFS

ホストのファイルシステムはユーザー定義の拡張属性に対応する必要があります。FS-Cache はこれらの属性を使って一貫性を維持するための情報を格納します。ext3 ファイルシステム (device) のユーザー定義による属性を有効にするには、以下を使用します

# tune2fs -o user_xattr /dev/device

または、ファイルシステムの拡張属性をマウント時に以下のように有効にすることもできます。

# mount /dev/device /path/to/cache -o user_xattr

キャッシュバックエンドは、そのキャッシュを支えるパーティション上の特定の空き領域量を維持することで動作します。空き領域を使用する他の要素に応じてキャッシュは増大したり縮小したりして rootファイルシステム (ノートブックなど) で安全にキャッシュを使用できるようにしています。FS-Cacheではデフォルトでこの動作が設定され、キャッシュの間引き (cache cull) 制限で設定を行うことができます。キャッシュの間引き制限を設定する方法については「キャッシュの間引き制限 (Cache Cull) の設定」を参照してください。

設定ファイルを所定の場所に配置したら、cachefilesd サービスを起動します。

# systemctl start cachefilesd

起動時に cachefilesd が起動するよう設定するには次のコマンドを root で実行します。

# systemctl enable cachefilesd


104

10.3. NFS でのキャッシュの使用

NFS は明示的に指示しない限りキャッシュは使用しません。FS-Cache を使用するように NFS マウントを設定するには、mount コマンドに -o fsc オプションを組み込みます。

# mount nfs-share:/ /mount/point -o fsc

ファイルがダイレクト I/O や書き込みのために開かれていない限り、/mount/point の下にあるファイル群へのアクセスはすべてキャッシュに移ります。詳細は「NFS でのキャッシュの制限」を参照してください。NFS インデックスは NFS のファイル名ではなくファイルハンドルを使ってファイル名ではなくファイルハンドルを使ってコンテンツをキャッシュします。つまりハードリンクしたファイルはキャッシュを正しく共有できることになります。

NFS のバージョン 2、3、4 がキャッシュ機能に対応しています。ただし、各バージョンではキャッシングに異なるブランチを使用します。

10.3.1. キャッシュの共有

NFS キャッシュ共有を行う上でいくつか考慮すべき問題点があります。キャッシュは永続的であり、キャッシュ内のデータブロックは次の 4 つのキーの順序でインデックス化されます。

レベル 1: サーバーの詳細

レベル 2: いくつかのマウントオプション、セキュリティータイプ、FSID、識別子

レベル 3: ファイルハンドル

レベル 4: ファイル内のページ番号

スーパーブロック間での整合性の管理に関する問題を避けるには、データをキャッシュする NFS のスーパーブロックすべてに固有のレベル 2 キーを持たせます。通常、同じソースボリュームとオプションを持つ 2 つの NFS マウントは 1 つのスーパーブロックを共有するため、そのボリューム内に異なるディレクトリーをマウントする場合でもキャッシングを共有することになります。

例例10.1 キャッシュの共有キャッシュの共有

2 つの mount コマンドを例にあげます。

mount home0:/disk0/fred /home/fred -o fsc

mount home0:/disk0/jim /home/jim -o fsc

/home/fred と /home/jim には同じオプションがあるので、スーパーブロックを共有する可能性が高くなります。とくに NFS サーバー上の同じボリュームやパーティションから作成されている場合は共有する可能性が高くなります (home0)。ここで、2 つの後続のマウントコマンドを示します。

mount home0:/disk0/fred /home/fred -o fsc,rsize=230

mount home0:/disk0/jim /home/jim -o fsc,rsize=231

この場合、/home/fred と /home/jim は、レベル 2 の異なるネットワークアクセスパラメーターを持つため、スーパーブロックを共有しません。次のマウントコマンドも同様です。

mount home0:/disk0/fred /home/fred1 -o fsc,rsize=230

mount home0:/disk0/fred /home/fred2 -o fsc,rsize=231


105

上記の 2 つのサブツリー (/home/fred1 と /home/fred2) は 2 回回キャッシュされます。

スーパーブロックの共有を回避するもう 1 つの方法は nosharecache パラメーターで明示的に共有を避ける方法です。同じ例を示します。

mount home0:/disk0/fred /home/fred -o nosharecache,fsc

mount home0:/disk0/jim /home/jim -o nosharecache,fsc

この場合、レベル 2 キーの home0:/disk0/fred と home0:/disk0/jim を区別することができないため、1 つのスーパーブロックのみの使用が許可されます。これに対処するには、固有の識別子を少なくともどちらか 1 つのマウントに追加します (fsc=unique-identifier)。

mount home0:/disk0/fred /home/fred -o nosharecache,fsc

mount home0:/disk0/jim /home/jim -o nosharecache,fsc=jim

/home/jim のキャッシュで使用されるレベル 2 キーに固有識別子の jim が追加されます。

10.3.2. NFS でのキャッシュの制限

ダイレクト I/O で共有ファイルシステムからファイルを開くと自動的にキャッシュが回避されます。この種のアクセスはサーバーに直接行なわれる必要があるためです。

書き込みで共有ファイルシステムからファイルを開いても NFS のバージョン 2 およびバージョン 3 では動作しません。これらのバージョンのプロトコルは、クライアントが別のクライアントからの同じファイルへの同時書き込みを検出するのに必要な整合性の管理に関する十分な情報を提供しません。

ダイレクト I/O または書き込みのいずれかで共有ファイルシステムからファイルが開かれると、キャッシュされているファイルのコピーはフラッシュされます。ダイレクト I/O や書き込みの動作によってファイルが開かれなくなるまで、FS-Cache はそのファイルの再キャッシュを行いません。

また、FS-Cache の今回のリリースでは通常の NFS ファイルのみをキャッシュします。FS-Cache はディレクトリーやシンボリックリンク、デバイスファイル、FIFO、ソケットなどはキャッシュしませんキャッシュしません。

10.4. キャッシュの間引き制限 (CACHE CULL) の設定

cachefilesd デーモンは、共有ファイルシステムからのリモートデータをキャッシングすることで機能し、ディスク上の領域を解放します。ただし、これにより使用可能な空き領域をすべて消費してしまう可能性があり、ディスクに root パーティションも格納している場合には問題となる可能性があります。これを制御するために、cachefilesd は古いオブジェクト (最近のアクセスが少ないオブジェクト)をキャッシュから破棄することにより空き領域の一定量を維持します。これは、キャッシュカリングとして知られています。

キャッシュの間引きは、基礎となるファイルシステムで利用可能なブロックとファイルのパーセンテージに基づいて実行されます。6 つの制限が /etc/cachefilesd.conf の設定で管理されます。

brun N% (ブロックのパーセンテージブロックのパーセンテージ), frun N% (ファイルのパーセンテージファイルのパーセンテージ)

キャッシュの空き領域と利用可能なファイルの数がこれらの制限を上回る場合、間引き動作がオフになります。


106

bcull N% (ブロックのパーセンテージブロックのパーセンテージ), fcull N% (ファイルのパーセンテージファイルのパーセンテージ)

キャッシュの空き領域と利用可能なファイルの数がこれらの制限のいずれかを下回る場合、間引き動作が開始されます。

bstop N% (ブロックのパーセンテージブロックのパーセンテージ), fstop N% (ファイルのパーセンテージファイルのパーセンテージ)

キャッシュの空き領域と利用可能なファイルの数がこれらの制限のいずれかを下回る場合、間引き動作によってこれらのレベルが再び制限を超えるまで、ディスク領域またはファイルの割り当ては行なわれません。

各設定の N のデフォルト値は以下の通りです。

brun/frun - 10%

bcull/fcull - 7%

bstop/fstop - 3%

これらの設定を行う場合に、以下が正しく適用されていることを確認してください。

0 ≤ bstop < bcull < brun < 100

0 ≤ fstop < fcull < frun < 100

空き領域と利用可能なファイルのパーセンテージがそれぞれ表示されますが、df プログラムで表示されるような 100 % から差し引いたパーセンテージとしては表示されません。

重要重要

間引き動作は、bxxx と fxxx のペアに同時に依存します。これらを別個に処理することはできません。

10.5. 統計情報

FS-Cache では全般的な統計情報も追跡します。次のようにして表示させます。

# cat /proc/fs/fscache/stats

FS-Cache の統計には決定ポイントとオブジェクトカウンターに関する情報が含まれます。詳細は、以下のカーネルドキュメントを参照してください。

/usr/share/doc/kernel-doc-version/Documentation/filesystems/caching/fscache.txt

10.6. FS-CACHE リファレンス

cachefilesd の詳細および設定方法については man cachefilesd と man cachefilesd.conf をご覧ください。次のカーネルドキュメントにも cachefilesd に関する記載があります。

/usr/share/doc/cachefilesd-version-number/README

/usr/share/man/man5/cachefilesd.conf.5.gz

/usr/share/man/man8/cachefilesd.8.gz

デザイン制約、利用可能な統計、機能を含む FC-Cache の概要は、以下のカーネルドキュメントを参照


107

デザイン制約、利用可能な統計、機能を含む FC-Cache の概要は、以下のカーネルドキュメントを参照してください。/usr/share/doc/kernel-doc-version/Documentation/filesystems/caching/fscache.txt


108

パート II. ストレージ管理

「ストレージ管理」セクションでは、最初に Red Hat Enterprise Linux 7 のストレージに関する考察を説明し、パーティション、論理ボリューム管理、swap パーティションの説明が続きます。次に、ディスククォータ、RAID システムについて説明し、マウントコマンド、volume_key、acl などの機能説明がこれに続きます。その後に、SSD チューニング、書き込みバリア、I/O 制限、ディスクレスシステムについて説明し、オンラインストレージについて詳細に説明した後、Device Mapper のマルチパス化と仮想ストレージについて説明します。

パートパート II. ストレージ管理ストレージ管理

109

第11章ストレージをインストールする際の注意点ストレージデバイスやファイルシステムの設定の多くはインストール時にしか実行することができません。ファイルシステムタイプなどの他の設定については、再フォーマットせずに変更できるのは特定の時点までになります。このようにストレージの設定については Red Hat Enterprise Linux 7 をインストールする前に慎重に計画する必要があります。

本章ではシステムのストレージ設定を計画する際の注意点について説明しています。実際のインストール方法については (インストール時のストレージ設定も含む)、Red Hat 提供の「インストールガイド」を参照してください。

Red Hat が正式にサポートするサイズおよびストレージの制限などの詳細情報については、記事のhttp://www.redhat.com/resourcelibrary/articles/articles-red-hat-enterprise-linux-6-technology-capabilities-and-limits を参照してください。

11.1. 特に注意を要する事項について

本セクションでは、ストレージの設定で特に注意を要する事項について記載しています。

/home、 /opt、 /usr/local には別々のパーティションを用意する

将来的にシステムのアップグレードが想定される場合、/home、/opt、/usr/local は別々のデバイスに配置します。これによりユーザーやアプリケーションのデータを維持した状態で、オペレーティングシステムを含むデバイスまたはファイルシステムの再フォーマットが可能になります。

IBM System Z における DASD デバイスと zFCP デバイス

IBM System Z のプラットフォームでは、DASD デバイスと zFCP デバイスは Channel Command Word(CCW) メカニズムで設定されます。CCW のパスをシステムに明示的に追加してからオンラインにする必要があります。DASD デバイスの場合、起動コマンドラインか、または CMS 設定ファイル内で DASD= パラメーターにデバイス番号 (またはデバイス番号の範囲) を記載します。

zFCP デバイスの場合は、デバイス番号、論理ユニット番号 (LUN)、ワールドワイドポート名 (WWPN)を記載する必要があります。zFCP が初期化されると CCW パスにマッピングが行われます。起動コマンドライン (または CMS 設定ファイル内) の FCP_x= の行を使用して、インストーラーに対してこの情報を指定することができます。

LUKS を使用してブロックデバイスを暗号化する

LUKS/dm-crypt を使ってブロックデバイスを暗号化するとデバイス上に存在しているフォーマットがすべて破棄されます。このため、まず暗号化するデバイス (ある場合) を選択してください。次に、新しいシステムのストレージ設定をインストールプロセスの一部としてアクティブにします。

古い BIOS RAID メタデータ

ファームウェア RAID 用に設定したシステムのディスクに残っている RAID メタデータを削除しないま削除しないまままでそのディスクをシステムから移動すると、Anaconda がディスクを正常に検出できなくなる場合があります。


110

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/installation_guide/index

http://www.redhat.com/resourcelibrary/articles/articles-red-hat-enterprise-linux-6-technology-capabilities-and-limits

警告警告

ディスクから RAID メタデータを削除または消去すると、保存データがすべて破棄される可能性があります。Red Hat では、これを実行する前に必ずバックアップを取っておくことをお勧めします。

注記注記

dmraid を使用して RAID ボリュームを作成した場合は、dmraid ユーティリティを使用して削除してください。これは、廃止予定です。

# dmraid -r -E /device/

RAID デバイスの管理については man dmraid および 18章RAID (Redundant Array of Independent Disks)を参照してください。

iSCSI の検出と設定

iSCSI ドライブのプラグアンドプレイ検出の場合には、iBFT 起動が可能なネットワークインターフェースカード (NIC) のファームウェアで設定を行ってください。インストール時の iSCSI ドライブのCHAP 認証がサポートされています。ただし、インストール時の iSNS 検出はサポートされていません。

FCoE の検出と設定

Fibre Channel over Ethernet (FCoE) ドライブのプラグアンドプレイ検出は、EDD で起動可能な NIC のファームウェアで設定を行ってください。

DASD

インストール中にダイレクトアクセスストレージデバイス (DASD) を追加したり設定したりすることはできません。このデバイスは CMS 設定ファイル内で指定してください。

DIF/DIX を有効にしているブロックデバイス

DIF/DIX は、特定の SCSI ホストバスのアダプターおよびブロックデバイスで提供されているハードウェアチェックサムの機能です。DIF/DIX が有効になっていると、ブロックデバイスを汎用目的で使用した場合にエラーが発生します。DIF/DIX チェックサムの計算後はバッファーされたデータが上書きされないようにするためのインターロックがバッファー書き込みパス内にないため、バッファーされた入出力または mmap(2) ベースの入出力が正常に動作しなくなります。

これにより入出力がチェックサムのエラーで後で失敗することになります。すべてのブロックデバイス(またはファイルシステムベース) のバッファーされた入出力または mmap(2) 入出力に対する共通の問題となるため、上書きによるこれらのエラーを回避することはできません。

このため、DIF/DIX を有効にしているブロックデバイスは O_DIRECT を使用するアプリケーションでのみ使用するようにしてください。こうしたアプリケーションはローブロックデバイスを使用するはずです。また、XFS ファイルシステムを通して発行されるのが O_DIRECT 入出力のみである限り、

第第11章章ストレージをインストールする際の注意点ストレージをインストールする際の注意点

111

DIF/DIX が有効になっているブロックデバイスで XFS ファイルシステムを使用しても安全です。特定の割り当て動作を行う際にバッファーされた入出力にフォールバックを行わないファイルシステムはXFS のみです。

DIF/DIX チェックサムの計算後に入出力データが変更されないようにするのは常にアプリケーションの役目となるため、DIF/DIX を使用できるアプリケーションを O_DIRECT 入出力および DIF/DIX ハードウェアでの使用を目的として設計されたアプリケーションに限ってください。


112

第12章ファイルシステムのチェックファイルシステムについては、その整合性をチェックでき、オプションでファイルシステム固有のユーザースペースのツールを使って修復を実行することができます。これらのツールは、通常 fsck ツールと呼ばれます。この fsck は、file system check の省略版です。

注記注記

これらのファイルシステムのチェックは、ファイルシステム全体でのメタデータの整合性のみを保証します。これらは、ファイルシステムに含まれる実際のデータを認識しないため、データリカバリーツールではありません。

ファイルシステムの不整合はさまざまな理由によって生じる可能性があります。これらの理由には、ハードウェアのエラー、ストレージ管理のエラー、およびソフトウェアのバグを含みますが、これらに限定されません。

最新のメタデータジャーナリングファイルシステムが一般的になる前に、ファイルシステムのチェックは、システムがクラッシュしたり、電源が切れたりするたびに必要となっていました。これは、ファイルシステムの更新が中断し、不整合な状態が生じる可能性があったためです。結果として、ファイルシステムのチェックは、ブート時に、/etc/fstab にリストされた各ファイルシステムで行なわれてきました。ジャーナリングファイルシステムの場合、通常これは非常に短い操作で実行できます。ファイルシステムのメタデータジャーナリングにより、クラッシュが発生した後でも整合性が確保されるためです。

ただし、ジャーナリングファイルシステムの場合であっても、ファイルシステムの不整合や破損が生じることがあります。いったんこれが生じると、ファイルシステムのチェッカーを使用してファイルシステムを修復する必要があります。以下は、この手順を実行する際のベストプラクティスとその他の役立つ情報です。

重要重要

マシンが起動しない場合、ファイルシステムが極めて大きい場合、またはファイルシステムがリモートストレージにある場合を除き、Red Hat はファイルシステムチェックの無効化を推奨しません。/etc/fstab の 6 番目のフィールドを 0 に設定すると起動時にファイルシステムのチェックを無効にすることができます。

12.1. FSCK のベストプラクティス

一般的に、ファイルシステムのチェックおよび修復ツールを実行することにより、チェックによって見つかる不整合の一部を自動的に修復できることが予想されます。場合によっては、重度にダメージを受けた inode やディレクトリーは、修復できない場合に破棄されることがあります。ファイルシステムへの大幅な変更が発生する可能性があります。予想外の、または好ましくない変更が永続的に行なわれないようにするには、以下の予防的な手順を実行します。

Dry run

ファイルシステムのほとんどのチェッカーには、チェックを行うものの、ファイルシステムの修復は行なわない操作モードがあります。このモードでは、チェッカーは、発見したエラーと実行した可能性のあるアクションを出力しますが、ファイルシステムを実際に変更することはありません。

注記注記

第第12章章ファイルシステムのチェックファイルシステムのチェック

113

注記注記

整合性チェックの後のフェーズでは、修復モードで実行されていた場合に前のフェーズで修正されていた可能性のある不整合を発見し、追加のエラーを出力する可能性があります。

ファイルシステムのイメージ上での初回操作ファイルシステムのイメージ上での初回操作

ほとんどのファイルシステムは、メタデータのみを含むスパースコピーであるメタデータイメージの作成に対応しています。ファイルシステムのチェッカーは、メタデータ上でのみ動作するため、このようなイメージを使用して、実際のファイルシステムの修復の Dry Run を実行し、実際に加えられた可能性のある変更を評価することができます。変更が受け入れ可能なものである場合は、修復はファイルシステム自体で実行できます。

注記注記

ファイルシステムが大幅に損傷している場合、メタデータイメージの作成に関連して問題が発生する可能性があります。

サポート調査のためのファイルシステムイメージの保存サポート調査のためのファイルシステムイメージの保存

修復前のファイルシステムのメタデータイメージは、破損の原因がソフトウェアのバグの可能性がある場合のサポート調査を行う上で役に立つことがあります。修復前のイメージに見つかる破損のパターンは、根本原因の分析に役立つことがあります。

アンマウントされたファイルシステム上のみの操作アンマウントされたファイルシステム上のみの操作

ファイルシステムの修復は、アンマウントされたファイルシステムのみで実行する必要があります。ツールには、ファイルシステムへの単独アクセスが必要であり、それがないと追加の損傷が発生する可能性があります。一部のファイルシステムはマウントされているファイルシステムでチェックのみのモードのみをサポートしますが、ほとんどのファイルシステムツールは、修復モードでこの要件を実行します。チェックのみのモードがマウントされているファイルシステム上で実行されている場合、アンマウントされていないファイルシステム上で実行される場合には見つからない正しくないエラーを見つける可能性があります。

ディスクエラーディスクエラー

ファイルシステムのチェックツールは、ハードウェアの問題を修復することはできません。修復を正常に機能させるには、ファイルシステムは完全に読み取り可能かつ書き込み可能である必要があります。ファイルシステムがハードウェアのエラーによって破損する場合、まずファイルシステムを dd(8) ユーティリティーなどを使って、良好なディスクに移行する必要があります。

12.2. FSCK に関するファイルシステム固有の情報

12.2.1. ext2、ext3、および ext4

上記のすべてのファイルシステムは、ファイルシステムのチェックと修復を実行するために e2fsck バイナリーを使用します。ファイル名の fsck.ext2、fsck.ext3、および fsck.ext4 は、この同じバイナリーのハードリンクです。これらのバイナリーはブート時に自動的に実行され、それらの動作はチェックされるファイルシステムやファイルシステムの状態に基づいて異なります。

完全なファイルシステムのチェックおよび修復が、メタデータジャーナリングファイルシステムではない ext2 や、ジャーナルのない ext4 ファイルシステムについて実行されます。

メタデータジャーナリングのある ext3 と ext4 ファイルシステムの場合、ジャーナルはユーザースペー


114

メタデータジャーナリングのある ext3 と ext4 ファイルシステムの場合、ジャーナルはユーザースペースで再生され、バイナリーが終了します。これは、ジャーナルの再生によりクラッシュ後のファイルシステムの整合性が確保するため、デフォルトのアクションになります。

これらのファイルシステムで、マウント中にメタデータの不整合が生じると、それらはその事実をファイルシステムのスーパーブロックに記録します。ファイルシステムにこのようなエラーのマークが付けられていることを e2fsck が発見すると、e2fsck はジャーナルの再生後にフルチェックを実行します(ある場合)。

e2fsck は、-p オプションが指定されていない場合、実行時にユーザー入力を求める場合があります。-p オプションは e2fsck に対して、安全に実行される可能性のあるすべての修復を自動的に実行するように指示します。ユーザーの介入が必要な場合、e2fsck はその出力の未解決の問題を示し、この状態を出口コードに反映させます。

共通して使用される e2fsck の実行時のオプションには以下が含まれます。

-n

非変更モードです。チェックのみの操作です。

-b スーパーブロックスーパーブロック

プライマリーブロックが損傷している場合、別のスーパーブロックのブロック番号を指定します。

-f

スーパーブロックに記録されたエラーがない場合に、フルチェックを強制実行します。

-j ジャーナルデバイスジャーナルデバイス

外部のジャーナルデバイス (ある場合) を指定します。

-p

ユーザー入力のないファイルシステムを自動的に修復または「preen (修復)」する

-y

すべての質問に「yes」の回答を想定する

e2fsck のすべてのオプションが e2fsck(8) man ページで指定されています。

以下の 5 つの基本フェーズが、実行中に e2fsck で実行されます。

1. Inode、ブロック、およびサイズのチェック。

2. ディレクトリー構造のチェック。

3. ディレクトリー接続のチェック。

4. 参照数のチェック。

5. グループサマリー情報のチェック。

e2image(8) ユーティリティーは、診断またはテスト目的で、修復前のメタデータイメージを作成するために使用できます。-r オプションは、テスト目的で、ファイルシステム自体と同じサイズのスパースファイルを作成するために使用する必要があります。その後 e2fsck は、結果として作成されるファイルで直接動作できます。イメージが診断目的でアーカイブまたは提供される場合に、-Q オプションを指定する必要があります。これにより、送信に適したよりコンパクトなファイル形式が作成されます。


115

12.2.2. XFS

ブート時に修復は自動的に行なわれません。ファイルシステムのチェックまたは修復を開始するには、xfs_repair ツールを使用します。

注記注記

fsck.xfs バイナリーは xfsprogs パッケージにありますが、これは、ブート時に fsck.filesystem バイナリーを検索する initscript に対応するためにのみ存在します。fsck.xfs は、終了コードとして 0 を設定して終了します。

古い xfsprogs パッケージにはxfs_check ツールが含まれます。このツールは非常にスピードが遅く、大きなファイルシステムに対して十分な拡張性がありません。そのため、xfs_repair -n が優先的に選択され、これは非推奨になっています。

ファイルシステム上のクリーンログは xfs_repair が動作するために必要です。ファイルシステムがクリーンな状態でアンマウントされなかった場合、xfs_repair を使用する前に、マウントとアンマウントが実行される必要があります。ログが破損していて再生できない場合、-L オプションを使用してログをゼロ化できます。

重要重要

-L オプションは、ログを再生できない場合にのみ使用する必要があります。このオプションは、ログ内のすべてのメタデータの更新を破棄し、結果としてさらに不整合を生じさせます。

-n オプションを使用して、Dry Run で、チェックのみモードの xfs_repair を実行することができます。このオプションが指定されると、ファイルシステムに一切の変更は行なわれません。

xfs_repair で使用できるオプションは非常に限られています。共通に使用されるオプションには以下が含まれます。

-n

変更不可モードです。チェックのみの操作です。

-L

メタデータログがゼロになります。マウントによってログを再生できない場合にのみ使用します。

-m maxmem

最大 MB の実行時に使用されるメモリーを制限します。必要な最小メモリーの概算を出すために 0を指定できます。

-l logdev

外部ログデバイス (ある場合) を指定します。

xfs_repair のすべてのオプションが xfs_repair(8) man ページで指定されています。

以下の 8 つの基本フェーズが、実行中に xfs_repair によって実施されます。

1. Inode および inode ブロックマップ (アドレス指定) のチェック。


116

2. Inode 割り当てマップのチェック。

3. Inode サイズのチェック。

4. ディレクトリーのチェック。

5. パス名のチェック。

6. リンク数のチェック。

7. フリーマップのチェック。

8. スーパーブロックのチェック。

詳細は、man ページの xfs_repair(8) を参照してください。

xfs_repair はインタラクティブな操作ではありません。すべての操作は、ユーザーの入力なしに自動的に実行されます。

診断またはテスト目的で、修復前のメタデータイメージを作成する必要がある場合は、xfs_metadump(8) および xfs_mdrestore(8) ユーティリティーを使用することができます。

12.2.3. Btrfs

注記注記



btrfsck ツールは btrfs ファイルシステムをチェックし、修復するために使用されます。このツールはまだ開発の初期段階にあり、ファイルシステムの破損のすべてのタイプを検出または修復できない可能性があります。

デフォルトで、btrfsck はファイルシステムを変更しません。つまり、デフォルトでチェックのみモードを実行します。修復が必要な場合は、--repair オプションを指定する必要があります。

以下の 3 つの基本フェーズを、実行中に btrfsck によって実行します。

1. エクステントのチェック。

2. ファイルシステムの root チェック。

3. ルートの参照数のチェック。

btrfs-image(8) ユーティリティーを使用して、診断またはテストの目的で、修復前のメタデータイメージを作成することができます。


117


第13章パーティション

注記注記

ブロックデバイスでパーティションを使用することの長所と短所の概要は、ナレッジベースアーティクルのhttps://access.redhat.com/solutions/163853を参照してください。

parted ユーティリティでは、以下を行うことができます。

既存パーティションテーブルの表示

既存パーティションのサイズ変更

空き領域または他のハードドライブからの、パーティションの追加

parted パッケージは、デフォルトで Red Hat Enterprise Linux 7 にインストールされています。 partedを起動するには、以下のコマンドを root で実行します。

# parted /dev/sda

/dev/sda を、設定するドライブのデバイスに置き換えます。

使用中のデバイス上でのパーティションの操作使用の終了が予定されるデバイス上のパーティションは、いずれもマウントすべきではなく、そのデバイスで swap 領域を有効にしないでください。

パーティションの削除またはサイズ変更を行う場合は、パーティションが存在するデバイスが使用中でない必要があります。

使用中のデバイスに新しいパーティションを作成することは可能ですが、推奨されていません。

パーティションテーブルの変更同じディスク上の別のパーティションが使用中のときにパーティションテーブルを変更することは一般的に推奨されていません。これは、カーネルがパーティションテーブルを再読み込みできないためです。結果として、変更が実行中のシステムに適用されません。このような状況では、システムを再起動するか、以下のコマンドを実行して、新しいパーティションまたは変更したパーティションをシステムに登録させてください。

# partx --update --nr partition-number disk

現在使用中のディスクを変更する最も簡単な方法:

1. システムディスクの場合など、ディスク上のパーティションのマウントを解除できない場合は、レスキューモードでシステムをブートします。

2. ファイルシステムをマウントするように指示されたら、スキップスキップを選択します。

ドライブに、使用中のパーティション、つまり、マウント解除しているファイルシステムを使用またはロックしているシステムプロセスがない場合は、umount コマンドを使用してそれらのパーティションのマウントを解除してから swapoff コマンドを使用し、ハードドライブ上のすべての swap 領域をオフにします。

一般的に使用されている parted コマンドを表示するには、表13.1「parted コマンド」を参照してくだ


118


一般的に使用されている parted コマンドを表示するには、表13.1「parted コマンド」を参照してください。

重要重要

ファイルシステムの作成には、parted ユーティリティを使用せずに、mkfs ツールを使ってください。

表表13.1 parted コマンドコマンド

コマンドコマンド説明説明

help 利用可能なコマンドの一覧を表示します

mklabel label パーティションテーブル用のディスクラベルを作成します

mkpart part-type [fs-type] start-mb end-mb 新しいファイルシステムを作成せずに、パーティションを作成します

name minor-num name Mac と PC98 のディスクラベル用のみのパーティションに名前を付けます

print パーティションテーブルを表示します

quit parted を終了します

rescue start-mb end-mb start-mb から end-mb へ、消失したパーティションを復旧します。

rm minor-num パーティションを削除します

select device 設定する別のデバイスを選択します

set minor-num flag state パーティションにフラグを設定します。state はオンまたはオフのいずれかになります

toggle [NUMBER [FLAG] パーティション NUMBER 上の FLAG の状態を切り替えます

unit UNIT デフォルトのユニットを UNIT に設定します

13.1. パーティションテーブルの表示

パーティションテーブルを表示:

1. parted を起動します。

2. 以下のコマンドを実行して、パーティションテーブルを表示します。

第第13章章パーティションパーティション

119

(parted) print

以下のようなテーブルが表示されます。

例例13.1 パーティションテーブルパーティションテーブル

Model: ATA ST3160812AS (scsi)Disk /dev/sda: 160GBSector size (logical/physical): 512B/512BPartition Table: msdos

Number Start End Size Type File system Flags 1 32.3kB 107MB 107MB primary ext3 boot 2 107MB 105GB 105GB primary ext3 3 105GB 107GB 2147MB primary linux-swap 4 107GB 160GB 52.9GB extended root 5 107GB 133GB 26.2GB logical ext3 6 133GB 133GB 107MB logical ext3 7 133GB 160GB 26.6GB logical lvm

以下は、パーティションテーブルの説明です。

Model: ATA ST3160812AS (scsi): ディスクタイプ、製造元、モデル番号、インターフェースの説明

Disk /dev/sda: 160GB: ブロックデバイスとストレージへのファイルパスを表示

パーティションテーブルパーティションテーブル: ディスクのラベルタイプを表示

パーティションテーブルでは、Number がパーティション番号を示します。たとえば、マイナー番号が１のパーティションは /dev/sda1 に相当します。Start と End の値は、メガバイト単位の値になります。有効な Type として、metadata (メタデータ)、free (空き領域)、primary(プライマリー)、extended (拡張)、logical (論理) を使用できます。Filesystem は、ファイルシステムのタイプです。フラグフラグは、パーティションに設定したフラグを一覧表示しています。利用可能なフラグは、boot、root、swap、hidden、raid、lvm、lba です。

パーティションテーブルの File system は、以下のいずれかを利用できます。

ext2

ext3

fat16

fat32

hfs

jfs

linux-swap

ntfs

reiserfs


120

hp-ufs

sun-ufs

xfs

デバイスの File system に値が示されていない場合は、そのファイルシステムが不明であることを示します。

注記注記

parted を再起動せずに、別のデバイスを選択するには、以下のコマンドを使用して、/dev/sda を、選択するデバイスに置き換えます。

(parted) select /dev/sda

これは、デバイスのパーティションテーブルの表示と設定を行うことができます。

13.2. パーティションの作成

警告警告

使用中のデバイスに、パーティションを作成しないようにしてください。

手順手順13.1 パーティションの作成パーティションの作成

1. パーティションを作成する前に、レスキューモードで起動します (または、デバイス上のパーティションをアンマウントして、デバイス上の swap 領域をすべてオフにします)。

2. parted を起動します。

# parted /dev/sda

/dev/sda を、パーティションを作成するデバイス名に置き換えます。

3. 現在のパーティションテーブルを表示し、十分な空き領域があるかどうかを確認します。

(parted) print

空き領域が十分でない場合は、現在のパーティションのサイズを変更できます。詳細については「fdisk を使用したパーティションのサイズ変更」を参照してください。

パーティションテーブルから、新しいパーティションの開始点と終了点、およびパーティションのタイプを決定します。プライマリーパーティションは、1 つのデバイス上に 4 つまで保有できます (この場合は拡張パーティションは含みません)。パーティションが 5 つ以上必要な場合は、プライマリーパーティションを 3 つ、拡張パーティションを１つにし、その拡張パーティションの中に複数の論理パーティションを追加します。ディスクパーティションの概要は、Red Hat Enterprise Linux 7 インストールガイド内の付録ディスクパーティションの概要を参照してください。


121


https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/installation_guide/appe-disk-partitions-overview

4. パーティションの作成方法:

(parted) mkpart part-type name fs-type start end

part-type を、環境に合わせてプライマリー、論理、拡張に置き換えます。

name を、パーティション名で置き換えます。GPT パーティションテーブルには名前が必要です。

fs-type を、btrfs、ext2、ext3、ext4、fat16、fat32、hfs、hfs+、linux-swap、ntfs、reiserfs、または xfs に置き換えます。fs-type は任意です。

環境に合わせて、start end を、メガバイト表記のサイズに置き換えます。

たとえば、ハードドライブの 1024 メガバイトから 2048 メガバイトに ext3 ファイルシステムのプライマリーパーティションを作成するには、以下のコマンドを入力します。

(parted) mkpart primary 1024 2048

注記注記

代わりに mkpartfs コマンドを使用すると、パーティションが作成されてからファイルシステムが作成されます。parted は、ext3 ファイルシステムの作成をサポートしないため、ext3 ファイルシステムを作成する場合は、mkpart を使用してから、後述のように mkfs コマンドを使ってファイルシステムを作成します。

Enter を押すと変更が反映されるため、押す前に再度確認してください。

5. パーティションテーブルを表示して、以下のコマンドを使用し、作成されたパーティションがパーティションタイプ、ファイルシステムタイプ、サイズが、パーティションテーブルに正しく表示されていることを確認します。

(parted) print

新しいパーティションのマイナー番号も覚えておいてください。そのパーティション上のファイルシステムにラベルを付けることができます。

6. parted シェルを終了します。

(parted) quit

7. parted を閉じたら以下のコマンドを使用して、カーネルが新しいパーティションを認識していることを確認します。

# cat /proc/partitions

parted では、最大で 128 のパーティションを作成できます。GPT (GUID Partition Table) の仕様により、パーティションテーブル用に確保するエリアを拡大することでさらに多くのパーティションを作成することができますが、parted で用いられる一般的な方法で得られるエリアは、128 個のパーティションに制限されます。


122

13.2.1. パーティションのフォーマットとラベル付け

パーティションをフォーマットしてラベルを付けるには、以下の手順を使用します。

手順手順13.2 パーティションのフォーマットとラベル付けパーティションのフォーマットとラベル付け

1. パーティションにはファイルシステムがありません。ext4 ファイルシステムを作成するには、以下を使用します。

# mkfs.ext4 /dev/sda6

警告警告

パーティションをフォーマットすると、そのパーティションに現存するすべてのデータが永久に抹消されます。

2. パーティション上のファイルシステムにラベルを付けます。たとえば、新規パーティションのファイルシステムが /dev/sda6 であり、それに Work のラベルを付ける場合は、以下を使用します。

# e2label /dev/sda6 "Work"

デフォルトでは、インストールプログラムはパーティションのマウントポイントをラベルとして使用して、ラベルが固有なものとなるようにします。ユーザーは使用するラベルを選択できます。

3. root としてマウントポイント (例、/work) を作成します

13.2.2. パーティションを /etc/fstab に追加

1. root として、/etc/fstab ファイルを編集して、パーティションの UUID で新規パーティションを含めます。

パーティションの UUID の完全なリストを表示するには、blkid -o list コマンドを使用し、個別のデバイス詳細を表示するには、blkid device コマンドを使用します。

/etc/fstab:

最初の列には、UUID= が含まれており、これにはファイルのシステム UUID が続きます。

次の列には、新しいパーティションのマウントポイントが含まれます。

3 つ目の列は、ext4 または swap といったファイルシステムタイプが含まれます。

4 つ目の列は、ファイルシステムのマウントオプションが一覧表示されています。ここでの defaults は、パーティションがデフォルトオプションでブート時にマウントされることを意味しています。

5、6 つ目のフィールドは、バックアップとチェックオプションを指定します。非 root パー


123

5、6 つ目のフィールドは、バックアップとチェックオプションを指定します。非 root パーティションの値の例は 0 2 です。

2. システムが新しい設定を登録するように、マウントユニットを再生成します。


3. ファイルシステムをマウントして、設定が機能することを確認します。

# mount /work

その他の情報その他の情報

/etc/fstab のフォーマットの詳細は、fstab(5) man ページを参照してください。

13.3. パーティションの削除

警告警告

パーティションが設定されているデバイスが使用中の場合は、削除しないでください。

手順手順13.3 パーティションの削除パーティションの削除

1. パーティションを削除する前に、以下のいずれかの操作を行います。

レスキューモードでブートするか、

デバイス上のパーティションのマウントを解除し、デバイス上のスワップ領域をオフにします。

2. parted ユーティリティを起動します。

# parted device

deviceを、パーティションを削除するデバイスに置き換えます。例: /dev/sda

3. 現在のパーティションテーブルを表示して、削除するパーティションのマイナー番号を確認します。

(parted) print

4. rm コマンドでパーティションを削除します。例えば、マイナー番号 3 のパーティションを削除するのは以下のコマンドです。

(parted) rm 3

変更は Enter を押すと変更が反映されるため、押す前にコマンドを再度確認してください。


124

5. パーティションを削除したら、print コマンドを使用して、パーティションテーブルから削除されていることを確認します。

(parted) print

6. parted シェルを終了します。

(parted) quit

7. パーティションが削除されていることをカーネルが認識しているかを確かめるために /proc/partitions ファイルの内容を調べます。

# cat /proc/partitions

8. パーティションを /etc/fstab ファイルから削除します。削除されたパーティションを宣言している行を見つけ、その行をファイルから削除します。

9. システムが新しい /etc/fstab 設定を登録するように、マウントユニットを再生成します。


13.4. パーティションタイプの設定

パーティションタイプ (ファイルシステムタイプとは異なる) は、実行中のシステムではほとんど使用されません。ただし、パーティションタイプは、systemd-gpt-auto-generator など、デバイスを自動的に識別してマウントするためにパーティションタイプを使用するオンザフライジェネレーターにとって重要です。

fdisk ユーティリティを起動し、t を実行することで、パーティションタイプを設定できます。以下の例では、最初のパーティションのタイプを Linux ではデフォルトである 0x83 に変更する方法を示しています。

# fdisk /dev/sdcCommand (m for help): tSelected partition 1Partition type (type L to list all types): 83Changed type of partition 'Linux LVM' to 'Linux'.

parted ユーティリティでは、パーティションタイプの、「フラグ」へのマッピングを試行することでパーティションタイプの一部を制御できます。これは、エンドユーザーには不便です。parted ユーティリティは、LVM または RAID など特定のパーティションタイプのみを処理できます。parted で最初のパーティションの lvm フラグを削除するには、以下を使用します。

# parted /dev/sdc 'set 1 lvm off'

一般的に使用されるパーティションタイプや、パーティションタイプを示すための 16 進数の一覧は、『Red Hat Enterprise Linux 7 インストールガイド』の「パーティション: 1 つのドライブの分割」を参照してください。

13.5. FDISK を使用したパーティションのサイズ変更

fdisk ユーティリティーを使用して、GPT、MBR、Sun、SGI または BSD のパーティションテーブルを


125

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/installation_guide/index#sect-disk-partitions-basics

作成して操作できます。fdisk の GUID パーティションテーブル (GPT) サポートは、実験的フェーズにあるため、 GPT を使用しているディスクには、parted ユーティリティーを使用することが推奨されます。

fdisk を使用してパーティションサイズを変更する場合は、パーティションを削除して再作成するため、パーティションのサイズを変更する前に、ファイルシステムに保存されているデータをバックアッバックアッププしてから、手順をテストします。

重要重要

サイズを変更するパーティションは、そのディスクの最後のパーティションである必要があります。

Red Hat は、LVM パーティションの拡張およびサイズ変更だけをサポートします。

手順手順13.4 パーティションのサイズ変更パーティションのサイズ変更

以下の手順は、参照用としてのみ提供しています。 fdisk を使用してパーティションのサイズを変更します。

1. デバイスをアンマウントします。

# umount /dev/vda

2. 以下の例のように、fdisk disk_name を実行します。

# fdisk /dev/vdaWelcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them. Be careful before using the write command.

Command (m for help):

3. p オプションで、削除するパーティションのライン番号を確認します。

Command (m for help): pDisk /dev/vda: 16.1 GB, 16106127360 bytes, 31457280 sectorsUnits = sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk label type: dosDisk identifier: 0x0006d09a

Device Boot Start End Blocks Id System/dev/vda1 * 2048 1026047 512000 83 Linux/dev/vda2 1026048 31457279 15215616 8e Linux LVM

4. d オプションで、パーティションを削除します。パーティションが 2 つ以上ある場合は、 fdiskが削除するパーティションの番号を指定するように指示します。

Command (m for help): dPartition number (1,2, default 2): 2Partition 2 is deleted


126

5. n オプションで新しいパーティションを作成し、指示に従います。今後のサイズ変更に必要な容量を十分に確保するようにしてください。(Enter を押したときの) fdisk のデフォルトの動作は、デバイスの領域をすべて使用することです。パーティションの末尾は、セクターで指定するか、人が判読できる値を +<size><suffix> の形式 (例: +500M、+10G) で指定できます。

fdisk は、パーティションの末尾を物理セクターに合わせて調整するため、空き領域をすべて使用したくない場合は、人が判読できるサイズ設定を選択することが推奨されます。(セクター単位で) 実際の数値を指定すると、fdisk がパーティションの調整を行うことはなくなります。

Command (m for help): nPartition type: p primary (1 primary, 0 extended, 3 free) e extendedSelect (default p): *Enter*Using default response pPartition number (2-4, default 2): *Enter*First sector (1026048-31457279, default 1026048): *Enter*Using default value 1026048Last sector, +sectors or +size{K,M,G} (1026048-31457279, default 31457279): +500MPartition 2 of type Linux and of size 500 MiB is set

6. パーティションのタイプを LVM に設定します。

Command (m for help): tPartition number (1,2, default 2): *Enter*Hex code (type L to list all codes): 8eChanged type of partition 'Linux' to 'Linux LVM'

7. 変更が正しければ、w を押して変更を書き込みます。書き込みにエラーがあると、選択したパーティションが不安定になる可能性があります。

8. デバイスで e2fsck を実行し、整合性を確認します。

# e2fsck /dev/vdae2fsck 1.41.12 (17-May-2010)Pass 1:Checking inodes, blocks, and sizesPass 2:Checking directory structurePass 3:Checking directory connectivityPass 4:Checking reference countsPass 5:Checking group summary informationext4-1:11/131072 files (0.0% non-contiguous),27050/524128 blocks

9. デバイスをマウントします。

# mount /dev/vda

詳細は、fdisk(8) の man ページを参照してください。


127

第14章 SNAPPER を用いたスナップショットの作成および維持スナップショットボリュームはターゲットボリュームの指定時のコピーで、ファイルシステムを以前の状態に戻す方法を提供します。Snapper は、Btrfs およびシンプロビジョニング対応 LVM ファイルシステムのスナップショットを作成および維持するコマンドラインツールです。

14.1. 初期 SNAPPER 設定の作成

Snapper には、Snapper が操作を行う各ボリュームにそれぞれ設定ファイルが必要です。設定ファイルは手動で設定する必要があります。デフォルトでは、root ユーザーだけが snapper コマンドを実行できます。

警告警告

シンプロビジョニングを使用している場合は、シンプールの空き容量を監視します。シンプールを完全に消耗すると、データが失われることがあります。詳細は、『Red Hat Enterprise Linux 7 論理ボリュームマネージャー管理ガイド』の「シンプロビジョニングされた論理ボリューム (シンボリューム)」を参照してください。

Btrfs ツールおよびファイルシステムはテクノロジープレビューとして提供されるため、実稼働システムでの使用には適していないことに注意してください。

root 以外のユーザーまたはグループが特定の Snapper コマンドを実行できるようにすることは可能ですが、特権のないユーザーやグループのパーティションは昇格しない昇格しないことが推奨されます。特権を昇格すると SELinux をすり抜けることとなり、セキュリティーのリスクを伴う可能性があります。sudo インフラストラクチャーの使用を検討することを、セキュリティー部門に相談することが推奨されます。

注記注記



手順手順14.1 Snapper 設定ファイルの作成設定ファイルの作成

1. 以下のいずれかを作成または選択します。

Red Hat がサポートするファイルシステムが構築されたシンプロビジョニング対応の論理ボリューム

Btrfs サブボリューム

2. ファイルシステムをマウントします。

3. このボリュームを定義する設定ファイルを作成します。


128

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/logical_volume_manager_administration/index#thinprovisioned_volumes


LVM2 の場合

# snapper -c config_name create-config -f "lvm(fs_type)" /mount-point

たとえば、/lvm_mount でマウントされている LVM2 サブボリューム上に ext4 ファイルシステムで lvm_config という設定ファイルを作成するには、以下を使用します。

# snapper -c lvm_config create-config -f "lvm(ext4)" /lvm_mount

Btrfs の場合

# snapper -c config_name create-config -f btrfs /mount-point

-c config_name オプションは設定ファイルの名前を指定します。

create-config は、設定ファイルの作成を Snapper に指示します。

-f file_system は、使用するファイルシステムを Snapper に指示します。省略すると、Snapper はファイルシステムの検出を試みます。

/mount-point は、サブボリュームまたはシンプロビジョニング対応 LVM2 ファイルシステムがマウントされた場所を指定します。

/btrfs_mount にマウントされた Btrfs サブボリュームに btrfs_config という名前の設定ファイルを作成するには、以下を使用します。

# snapper -c btrfs_config create-config -f btrfs /btrfs_mount

設定ファイルは /etc/snapper/configs/ ディレクトリーに保存されます。

14.2. SNAPPER スナップショットの作成

Snapper は、以下の種類のスナップショットを作成できます。

プリスナップショットプリスナップショット

プリスナップショットは、ポストスナップショットの起点となります。プリスナップショットおよびポストスナップショットは密接に関係し、この間のファイルシステムの変更を追跡します。プリスナップショットはポストスナップショットの前に作成する必要があります。

ポストスナップショットポストスナップショット

ポストスナップショットは、プリスナップショットの終点となります。結合されたプリスナップショットおよびポストスナップショットは比較の範囲を定義します。デフォルトでは、関連するポストスナップショットが正常に作成された後、バックグラウンド比較を作成するために新しいSnapper ボリュームが設定されます。

シングルスナップショットシングルスナップショット

シングルスナップショットは、特定時に作成されるスタンドアロンのスナップショットです。シングルスナップショットは変更のタイムラインを追跡するために使用され、後で戻る点があります。

14.2.1. プリスナップショットおよびポストスナップショットのペアの作成

第第14章章 SNAPPER を用いたスナップショットの作成および維持を用いたスナップショットの作成および維持

129

14.2.1.1. Snapper を用いたプリスナップショットの作成を用いたプリスナップショットの作成

プリスナップショットを作成するには、以下を実行します。

# snapper -c config_name create -t pre

-c config_name オプションは、名前付き設定ファイルの仕様に従ってスナップショットを作成します。設定ファイルが存在しない場合は「初期 Snapper 設定の作成」を参照してください。

create -t オプションは、作成するスナップショットの種類を指定します。許可されるエントリーは pre、post、または single です。

たとえば、「初期 Snapper 設定の作成」で作成された lvm_config 設定ファイルを使用してプリスナップショットを作成するには、以下を実行します。

# snapper -c SnapperExample create -t pre -p1

-p オプションは、作成されたスナップショットの数を出力する任意のオプションです。

14.2.1.2. Snapper を用いたポストスナップショットの作成を用いたポストスナップショットの作成

ポストスナップショットは、スナップショットの終点で、「Snapper を用いたプリスナップショットの作成」の手順に従って親のプリスナップショットを作成してから、作成する必要があります。

手順手順14.2 ポストスナップショットの作成ポストスナップショットの作成

1. プリスナップショットの番号を確認します。

# snapper -c config_name list

たとえば、lvm_config 設定ファイルを使用して作成されたスナップショットの一覧を表示するには、以下を実行します。

# snapper -c lvm_config listType | # | Pre # | Date | User | Cleanup | Description | Userdata-------+---+-------+-------------------+------+----------+-------------+---------single | 0 | | | root | | current |pre | 1 | | Mon 06<...> | root | | |

この出力は、プリスナップショットの番号が 1 であることを表しています。

2. 以前作成されたプリスナップショットにリンクされるポストスナップショットを作成します。

# snapper -c config_file create -t post --pre-num pre_snapshot_number

-t post オプションは、ポストスナップショットの作成を指定します。

--pre-num オプションは、対応するプリスナップショットを指定します。

たとえば、lvm_config 設定ファイルを使用してポストスナップショットを作成し、番号が 1 のプリスナップショットにリンクするには、以下を実行します。


130

# snapper -c lvm_config create -t post --pre-num 1 -p2

-p オプションは、作成されたスナップショットの数を出力する任意のオプションです。

3. 番号が 2 のポストスナップショットが作成され、番号が 1 のプリスナップショットとペアになります。list コマンドで確認します。

# snapper -c lvm_config listType | # | Pre # | Date | User | Cleanup | Description | Userdata-------+---+-------+-------------------+------+----------+-------------+---------single | 0 | | | root | | current |pre | 1 | | Mon 06<...> | root | | |post | 2 | 1 | Mon 06<...> | root | | |

14.2.1.3. プリまたはポストスナップショットでのコマンドのラッピングプリまたはポストスナップショットでのコマンドのラッピング

プリスナップショットおよびポストスナップショット内でコマンドをラッピングすることも可能です。これはテスト時に便利です。簡単な手順は、手順14.3「プリまたはポストスナップショットでのコマンドのラッピング」を参照してください。

1. snapper create pre snapshot コマンドを実行します。

2. ファイルシステムの内容に影響する可能性があるアクションを実行するため、1 つまたは複数のコマンドを実行します。

3. snapper create post snapshot コマンドを実行します。

手順手順14.3 プリまたはポストスナップショットでのコマンドのラッピングプリまたはポストスナップショットでのコマンドのラッピング

1. プリスナップショットおよびポストスナップショットでコマンドをラッピングするには、以下を行います。

# snapper -c lvm_config create --command "command_to_be_tracked"

たとえば、/lvm_mount/hello_file ファイルの作成を追跡するには、以下を実行します。

# snapper -c lvm_config create --command "echo Hello > /lvm_mount/hello_file"

2. これを確認するには、status コマンドを実行します。

# snapper -c config_file status first_snapshot_number..second_snapshot_number

たとえば、最初のステップで変更した内容を追跡するには、以下を実行します。

# snapper -c lvm_config status 3..4+..... /lvm_mount/hello_file

必要な場合は list コマンドを実行し、スナップショットの番号を確認します。

status コマンドの詳細は、「Snapper スナップショット間の変更の追跡」を参照してください。

スナップショットが例のコマンドのみをキャプチャーするとは限らないことに注意してください。


131

スナップショットが例のコマンドのみをキャプチャーするとは限らないことに注意してください。Snapper はユーザーによる変更だけでなく、システムによる変更もすべて記録します。

14.2.2. シングル Snapper スナップショットの作成

シングル Snapper スナップショットの作成は、プリスナップショットまたはポストスナップショットの作成と似ており、create -t オプションのみがシングルスナップショットを指定します。シングルスナップショットは、他のスナップショットと関連せずに単一のスナップショットを作成するために使用されます。しかし、自動的に比較を生成したり、追加情報をリストする必要がなく、LVM2 シンボリュームのスナップショットを作成する明確な方法が必要な場合は、Snapper の代わりに System StorageManager を使用することが推奨されます (「スナップショット」参照)。

シングルスナップショットを作成するには、以下を実行します。

# snapper -c config_name create -t single

たとえば、以下のコマンドは lvm_config 設定ファイルを使用してシングルスナップショットを作成します。

# snapper -c lvm_config create -t single

シングルスナップショットは、変更の追跡用に特別に設計されたものではありませんが、snapper diffコマンド、xadiff コマンド、および status コマンドを使用すると、2 つのスナップショットを比較できます。各コマンドの詳細は「Snapper スナップショット間の変更の追跡」を参照してください。

14.2.3. スナップショットを自動的に取得するよう Snapper を設定

スナップショットの自動取得は、Snapper の主な機能の 1 つです。デフォルトでは、ボリュームに対して Snapper を設定すると、Snapper はそのボリュームのスナップショットを 1 時間ごとに取得します。

デフォルトの設定では、Snapper は以下の周期でスナップショットを取得します。

10 時間周期のスナップショット。最後のスナップショットは Daily スナップショットとして保存されます。

10 日周期のスナップショット。月最後のスナップショットは Monthly スナップショットとして保存されます。

10 カ月周期のスナップショット。最後のスナップショットは Yearly スナップショットとして保存されます。

10 年周期のスナップショット。

Snapper はデフォルトで 50 個以下のスナップショットを保持しますが、デフォルトでは作成後 1,800秒未満のスナップショットはすべて保持されます。

デフォルト設定は、/etc/snapper/config-templates/default ファイルに指定されます。snapper create-config コマンドを実行して設定を作成すると、未指定の値はすべてデフォルト設定を基に設定されます。定義されたボリュームの設定は、/etc/snapper/configs/config_name ファイルで編集できます。

14.3. SNAPPER スナップショット間の変更の追跡

status、diff、および xadiff コマンドを使用して、スナップショット間におけるサブボリュームの変更を追跡します。


132

status

status コマンドは、2 つのスナップショットの間で作成、編集、または削除されたファイルおよびディレクトリーを一覧表示します (2 つのスナップショットの間で発生した変更の包括的なリスト)。システム管理者は、このコマンドを使用して、過剰な情報が含まれない、適度な変更の概要を取得できます。

詳細は「status コマンドによる変更の比較」を参照してください。

diff

diff コマンドは、1 つ以上の変更が検出された場合に status コマンドが出力する 2 つのスナップショットの間に変更されたファイルおよびディレクトリーの差異を表示します。

詳細は「diff コマンドによる変更の比較」を参照してください。

xadiff

xadiff コマンドは、2 つのスナップショットの間にファイルまたはディレクトリーの拡張属性がどのように変更されたかを比較します。

詳細は「xadiff コマンドによる変更の比較」を参照してください。

14.3.1. status コマンドによる変更の比較

status コマンドは、2 つのスナップショットの間で作成、編集、または削除されたファイルおよびディレクトリーを表示します。

2 つのスナップショット間のファイル状態を表示するには、以下を実行します。

# snapper -c config_file status first_snapshot_number..second_snapshot_number


たとえば、以下のコマンドは lvm_config 設定ファイルを使用して、スナップショット 1 と 2 との間に加えられた変更を表示します。

#snapper -c lvm_config status 1..2tp.... /lvm_mount/dir1-..... /lvm_mount/dir1/file_ac.ug.. /lvm_mount/file2+..... /lvm_mount/file3....x. /lvm_mount/file4cp..xa /lvm_mount/file5

出力の最初の部分にある文字と点 (ピリオド) は列とします。

+..... /lvm_mount/file3||||||123456

列 1 はファイル (ディレクトリーエントリー) タイプの変更を示します。可能な値は以下のとおりです。

列列 1


133

出力出力意味意味

. 何も変更されていません。

+ ファイルが作成されました。

- ファイルが削除されました。

c コンテンツが変更されました。

t ディレクトリーエントリーのタイプが変更されました。たとえば、以前のシンボリックリンクは同じファイル名を持つ通常ファイルに変更されました。

列 2 は、ファイル権限の変更を示しています。使用できる値は次のとおりです。

列列 2


. いずれの権限も変更されていません。

p 権限が変更されました。

列 3 は、ユーザー所有権の変更を示しています。使用できる値は以下のとおりです。

列列 3


. いずれのユーザー所有権も変更されていません。

u ユーザーの所有権が変更されました。

列 4 は、グループ所有権の変更を示しています。使用できる値は以下のとおりです。

列列 4


. グループ所有権は変更されていません。

g グループ所有権は変更されました。

列 5 は、拡張属性の変更を示しています。使用できる値は以下のとおりです。


134

列列 5


. 拡張属性は変更されていません。

x 拡張属性は変更されました。

列 6 は、アクセス制御リスト (ACL) の変更を示しています。使用できる値は以下のとおりです。

列列 6


. ACL は変更されませんでした。

a ACL は変更されました。

14.3.2. diff コマンドによる変更の比較

diff コマンドは、2 つのスナップショットの間に編集されたファイルおよびディレクトリーの変更箇所を表示します。

# snapper -c config_name diff first_snapshot_number..second_snapshot_number


たとえば、lvm_config 設定ファイルを使用してスナップショット 1 と 2 の間で変更されたファイルを比較するには、以下を使用します。

# snapper -c lvm_config diff 1..2--- /lvm_mount/.snapshots/13/snapshot/file4 19<...>+++ /lvm_mount/.snapshots/14/snapshot/file4 20<...>@@ -0,0 +1 @@+words

この出力は、file4 に「words」をファイルに追加して編集されたことを示しています。

14.3.3. xadiff コマンドによる変更の比較

xadiff コマンドは、2 つのスナップショットの間にファイルまたはディレクトリーの拡張属性がどのように変更されたかを比較します。

# snapper -c config_name xadiff first_snapshot_number..second_snapshot_number


たとえば、lvm_config 設定ファイルを使用してスナップショット 1 と 2 との間の xadiff の出力を表示するには、以下を実行します。


135

# snapper -c lvm_config xadiff 1..2

14.4. スナップショット間の変更の取り消し

既存の 2 つの Snapper スナップショット間の変更を元に戻すには、undochange コマンドを、以下の形式で実行します。1 は最初のスナップショットで、2 は 2 つ目のスナップショットになります。

snapper -c config_name undochange 1..2

重要重要

undochange コマンドを使用しても、Snapper ボリュームは元の状態に戻らず、データの整合性は維持されません。指定範囲外で行われるファイルの編集 (例: スナップショット 2 以降) は、スナップショット 1 の状態に戻されても変更しません。たとえば、undochange を実行してユーザーが作成したものを元に戻す場合、そのユーザーが所有するファイルはそのままの状態を維持できます。

また、スナップショットの作成時にファイルの整合性を保証するメカニズムはないため、undochange コマンドを使用すると、すでに存在する不整合がスナップショットに戻される可能性があります。

undochange コマンドは失敗する可能性が高いため、ルートファイルシステムにはSnapper の undochange コマンドを使用しないでください。

以下の図は、undochange コマンドの仕組みを表しています。

図図14.1 時間経過後の時間経過後の Snapper の状態の状態

上記の図では、snapshot_1 が作成されてから、file_a が作成され、file_b が削除されています。その後 Snapshot_2 が作成されてから、file_a が編集され、file_c が作成されています。これがシステムの現在の状態です。現在のシステムには編集後の file_a があり、file_b はなく、新規作成された file_c があります。


136

undochange コマンドが呼び出されると、最初のスナップショットと 2 つ目のスナップショットの間に編集されたファイルのリストが生成されます。この図の状態で、snapper -c SnapperExample undochange 1..2 コマンドを実行すると、編集されたファイルのリスト (file_a が作成され、file_b が削除されてます) が作成され、現在のシステムに適用されます。したがって、以下のようになります。

現在のシステムには file_a がありません。snapshot_1 が作成されてから作成されたからです。

file_b は、snapshot_1 から、現在のシステムにコピーされます。

指定期間外に作成されたため、file_c は存在します。

file_b と file_c が競合すると、システムが破損する可能性があります。

また、snapper -c SnapperExample undochange 2..1 コマンドを使用することも可能です。この場合、現在のシステムにある file_a が、snapshot_1 のものに置き換わるため、snapshot_2 を作成した後に加えられた変更内容は元に戻ります。

mount および unmount コマンドを使用した変更の取り消しundochange コマンドが、変更を元に戻す最適な方法ではないことがあります。status コマンドと diffコマンドを併用して、適切な判断を行ってください。さらには、Snapper ではなく、mount コマンドと unmount コマンドを使用します。mount コマンドと unmount コマンドは、Snapper ワークフロー外のコンテンツを閲覧する場合に限り便利です。

必要に応じて、mount コマンドで、マウント前に対応する LVM Snapper スナップショットをアクティベートします。スナップショットをマウントし、古いバージョンのファイルを複数抽出する場合は、mount コマンドおよび unmount コマンドを使用します。ファイルを元に戻す場合は、マウントしているスナップショットから現在のファイルシステムにコピーします。現在のファイルシステムであるスナップショット 0 は、手順14.1「Snapper 設定ファイルの作成」から作成したライブファイルシステムです。このファイルを、元の /mount-point のサブツリーにコピーします。

明示的なクライアント側のリクエストには、mount コマンドおよび unmount コマンドを使用します。/etc/snapper/configs/config_name ファイルには、ユーザーおよびグループを追加できるALLOW_USERS= 変数および ALLOW_GROUPS= 変数が含まれます。snapperd を使用すると、追加されたユーザーおよびグループのマウント操作を実行できます。

14.5. SNAPPER スナップショットの削除

スナップショットの削除手順

# snapper -c config_name delete snapshot_number

list コマンドを実行して、スナップショットが正常に削除されたことを確認できます。


137

第15章 SWAP領域Linux の swap 領域は、物理メモリー (RAM) の空き容量がなくなると使用されます。システムがより多くのメモリーリソースを必要とする場合、RAM に空き容量がないとメモリーの非アクティブなページが swap 領域に移されます。RAM の容量が小さいマシンでは swap 領域が役に立ちますが、容量の大きい RAM の代わりとしてはなりません。swap 領域は、物理メモリーよりもアクセスに時間がかかるハードドライブ上にあります。swap 領域は、専用のスワップパーティション (推奨)、スワップファイル、またはスワップパーティションとスワップファイルの組み合わせにすることができます。Btrfs は swap領域をサポートしないため注意してください。

過去数年、推奨される swap 領域のサイズは、システムの RAM サイズとともに直線的に増加していました。しかし、最近のシステムのメモリーサイズは数百ギガバイトまで増加したため、現在推奨されるswap 領域の容量は、システムメモリーではなくシステムメモリーのワークロードの関数であると考えられています。

表15.1「システムの推奨 swap 領域」は、ご使用のシステムの RAM 容量別に、システムがハイバネートするために十分なメモリーが不要な場合と必要な場合のスワップパーティションの推奨サイズをまとめています。推奨の swap 領域はインストール中に自動的に確定されますが、ハイバネーションも可能にするには、カスタムパーティション分割の段階で swap 領域の編集が必要となります。

表15.1「システムの推奨 swap 領域」の推奨情報は、メモリーの容量が小さいシステム (1 GB 以下) で特に重要になります。システムで十分な swap 領域を割り当てできないと、安定性の問題や、インストールされたシステムが起動できない問題などが発生する原因となることがあります。

表表15.1 システムの推奨システムの推奨 swap 領域領域

システム内のシステム内の RAM の容量の容量推奨される推奨される swap 領域領域ハイバネートを許可する場合に推ハイバネートを許可する場合に推奨される奨される swap 領域領域

⩽ 2 GB RAM 容量の 2 倍 RAM 容量の 3 倍

> 2 GB – 8 GB RAM 容量と同じ RAM 容量の 2 倍

> 8 GB – 64 GB 最低 4GB RAM 容量の 1.5 倍

> 64 GB 最低 4GB ハイバネートは推奨されません

ご使用のシステムが表15.1「システムの推奨 swap 領域」に記載されている境界線上 (RAM が 2GB、8GB または 64GB) になる場合、swap サイズやハイバネートへの対応を決める際は慎重に行なってください。システムリソースに余裕がある場合は、swap 領域を大きくするとパフォーマンスが向上することがあります。140 個を超える論理プロセッサーまたは 3 TB を超える RAM があるシステムには、最低でも 100 GB の swap 領域を確保することが推奨されます。

高速のドライブ、コントローラー、およびインターフェイスを搭載したシステムでは、複数のストレージデバイスに swap 領域を分散すると、swap 領域のパフォーマンスも向上します。

重要重要


138

重要重要

swap 領域として割り当てたファイルシステムおよび LVM2 ボリュームは使用中に変更してはいけませんいけません。システムプロセスやカーネルが swap 領域を使用しているときに swapを変更しようとしても変更に失敗します。swap の使用量とその使用場所を確認するには、free および cat /proc/swaps コマンドを使用します。

システムが rescue モードで起動している間に swap 領域を変更してください。詳細は『Red Hat Enterprise Linux 7 インストールガイド』のレスキューモードでコンピューターを起動するを参照してください。ファイルシステムのマウントを要求されたら Skipを選択してください。

15.1. SWAP 領域の追加

場合によっては、インスト－ルした後にさらに swap 領域の追加が必要になることもあります。例えば、システムの RAM の容量を 1 GB から 2 GB にアップグレードした時点に swap 領域が 2 GB のままかも知れません。メモリー集中型の操作や大容量のメモリーを必要とするアプリケーションを実行する場合には、swap 領域を 4 GB に増加することが有効な対処法となります。

選択肢が３つあります: 新規の swap パーティションの作成、新規の swap ファイルの作成、あるいは、既存の LVM2 論理ボリューム上で swap の拡張。この中で既存論理ボリュームの拡張を推奨致します。

15.1.1. LVM2 論理ボリュームでの swap 領域の拡張

Red Hat Enterprise Linux 7 は、デフォルトで、使用可能なすべての領域をインストール時に使用します。この設定を選択している場合、まず swap 領域として使用するボリュームグループに新しい物理ボリュームを追加しなければなりません。

swap 領域のボリュームグループにストレージを追加した後に、それを拡張することができるようになります。これを実行するには、次の手順に従います (/dev/VolGroup00/LogVol01 ボリュームのサイズを 2 GB 拡張するとします)。

手順手順15.1 LVM2 論理ボリュームでの論理ボリュームでの swap 領域の拡張領域の拡張

1. 関連付けられている論理ボリュームの swap 機能を無効にします。

# swapoff -v /dev/VolGroup00/LogVol01

2. LVM2 論理ボリュームをサイズ変更して 2 GB 拡張します。

# lvresize /dev/VolGroup00/LogVol01 -L +2G

3. 新しい swap 領域をフォーマットします。

# mkswap /dev/VolGroup00/LogVol01

4. 縮小した論理ボリュームを有効にします。

# swapon -v /dev/VolGroup00/LogVol01

5. swap 論理ボリュームの拡張に成功したかどうかをテストするには、アクティブな swap 容量を調べます。

第第15章章 SWAP領域領域

139

https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-boot-options-maintenance.html#sect-boot-options-rescue

$ cat /proc/swaps$ free -h

15.1.2. swap の LVM2 論理ボリュームの作成

2 GB の swap ボリュームグループを追加します (/dev/VolGroup00/LogVol02 が追加する swap ボリュームであるとします)。

1. サイズが 2 GB の LVM2 論理ボリュームを作成します。

# lvcreate VolGroup00 -n LogVol02 -L 2G



3. 次のエントリーを /etc/fstab ファイルに追加します。

/dev/VolGroup00/LogVol02 swap swap defaults 0 0



5. 論理ボリュームで swap をアクティブ化します。


6. swap 論理ボリュームの作成に成功したかどうかをテストするには、アクティブな swap 容量を調べます。


15.1.3. swap ファイルを作成する

swap ファイルを追加します。

手順手順15.2 スワップファイルの追加スワップファイルの追加

1. 新しい swap ファイルのサイズをメガバイト単位で決定してから 1024 をかけてブロック数を確定します。たとえば swap ファイルのサイズが 64 MB の場合、ブロック数は 65536 になります。

2. 空のファイルの作成:

# dd if=/dev/zero of=/swapfile bs=1024 count=65536

希望のブロックサイズと同等の値に count を置き換えます。

3. 以下のコマンドでスワップファイルをセットアップします。


140

# mkswap /swapfile

4. スワップファイルのセキュリティを変更して、全ユーザーに読み込みできなくします。

# chmod 0600 /swapfile

5. ブート時にスワップファイルを有効化するには、/etc/fstab を root として編集して、以下のエントリーを含めます。

/swapfile swap swap defaults 0 0

次にシステムが起動すると新しい swap ファイルが有効になります。

6. システムが新しい /etc/fstab 設定を登録するように、マウントユニットを再生成します。


7. スワップファイルをすぐに有効化する方法:

# swapon /swapfile

8. 新しいスワップファイルの作成と有効化に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。


15.2. SWAP 領域の削除

時には、インスト－ルの後に swap 領域を減量することが賢明な場合もあります。例えば、システムのRAM サイズを 1 GB から 512 MB にダウングレードした場合、swap 領域が 2 GB のままで残ることになります。この状況では、2 GB はディスク領域の無駄になりますので、swap 領域を 1 GB に減量した方がリソースの有効活用になります。

ここでも選択肢が３つあります: swap 用に使用していた LVM2 論理ボリューム全体を削除、swap ファイルの削除、あるいは既存の LVM2 論理ボリューム上の swap 領域の低減。

15.2.1. LVM2 論理ボリュームでの swap 領域の縮小

以下のようにして LVM2 の swap 論理ボリュームを縮小します (/dev/VolGroup00/LogVol01 が縮小するボリュームであるとします)。

手順手順15.3 LVM2 のの swap 論理ボリュームの縮小論理ボリュームの縮小



2. LVM2 論理ボリュームをサイズ変更して 512 MB 分縮小します。

# lvreduce /dev/VolGroup00/LogVol01 -L -512M


141



4. 論理ボリュームで swap をアクティブ化します。


5. swap 論理ボリュームの縮小に成功したかどうかをテストするには、アクティブな swap 容量を調べます。


15.2.2. swap の LVM2 論理ボリュームの削除

swap ボリュームグループを削除します (/dev/VolGroup00/LogVol02 が削除するボリュームであるとします)。

手順手順15.4 swap ボリュームグループの削除ボリュームグループの削除



2. LVM2 論理ボリュームを削除します。

# lvremove /dev/VolGroup00/LogVol02

3. 次の関連エントリーを /etc/fstab ファイルから削除します。

/dev/VolGroup00/LogVol02 swap swap defaults 0 0



5. 論理ボリュームの削除に成功したかどうかをテストするには、アクティブな swap 容量を調べます。


15.2.3. swap ファイルの削除

swap ファイルを削除します。

手順手順15.5 swap ファイルの削除ファイルの削除

1. シェルプロンプトで次のコマンドを実行して swap ファイルを無効にします (swap ファイルの


142

1. シェルプロンプトで次のコマンドを実行して swap ファイルを無効にします (swap ファイルの場所が/swapfile であるとします)。

# swapoff -v /swapfile

2. /etc/fstab ファイルから該当するエントリーを削除します。



4. 実際のファイルを削除します。

# rm /swapfile

15.3. SWAP 領域の移動

ある場所から別の場所にスワップ領域を移動するには:

1. スワップ用領域の削除「Swap 領域の削除」。

2. スワップ用領域の追加「Swap 領域の追加」。


143

第16章 SYSTEM STORAGE MANAGER (SSM)System Storage Manager (SSM) は、さまざまなテクノロジーでストレージを管理するコマンドラインインターフェースを提供します。ストレージシステムは、Device Mappers (DM)、論理ボリュームマネージャー (LVM)、Multiple Devices (MD) の使用によってますます複雑になっています。これにより、システムはユーザーが使いにくいものとなり、エラーは問題が生じやすくなります。SSM は統一されたユーザーインターフェースを作成してこの問題を軽減します。このインターフェースによって、ユーザーは複雑なシステムを簡単に実行できるようになります。たとえば、SSM を使用せずに新しいファイルシステムを作成およびマウントするには、5 つのコマンドを使用する必要がありますが、SSMを使用すると 1 つのコマンドのみが必要になります。

本章では、SSM がさまざまなバックエンドと対話する仕組みや、一般的なユースケースを詳細に説明します。

16.1. SSM バックエンド

SSM は、デバイス、プールおよびボリュームの抽象化に準拠する ssmlib/main.py のコア抽象化レイヤーを使用し、基盤のテクノロジーの詳細を無視します。ボリュームおよびプールの create、snapshot、または remove などの特定のストレージ技術を処理するため、バックエンドを ssmlib/main.py で登録できます。

SSM にはすでに複数のバックエンドが登録されています。以下のセクションでは、これらのバックエンドの基本情報を説明し、プール、ボリューム、スナップショット、およびデバイスの処理方法の定義についても説明します。

16.1.1. Btrfs バックエンド

注記注記



Btrfs は多くの高度な機能を持つファイルシステムで、SSM ではボリューム管理バックエンドとして使用されます。プール、ボリューム、およびスナップショットは Btrfs バックエンドで作成できます。

16.1.1.1. Btrfs プールプール

Btrfs ファイルシステム自体はプールです。デバイスを追加して拡張したり、デバイスを削除して縮小することができます。SSM は Btrfs プールの作成時に Btrfs ファイルシステムを作成します。新規作成された各 Btrfs プールにはプールと同じ名前のボリュームが 1 つあり、プール全体を削除しないと削除できません。Btrfs プールのデフォルトの名前は btrfs_pool です。

プールの名前はファイルシステムのラベルとして使用されます。システム内にラベルのない Btrfs ファイルシステムがすでに存在する場合は、Btrfs プールは、btrfs_device_base_name という形式で、内部使用向けの名前を生成します。

16.1.1.2. Btrfs ボリュームボリューム

プールの最初のボリュームの後に作成されたボリュームはサブボリュームと同じです。サブボリューム


144


プールの最初のボリュームの後に作成されたボリュームはサブボリュームと同じです。サブボリュームを作成するために Btrfs ファイルシステムがアンマウントされた場合、SSM は Btrfs ファイルシステムを一時的にマウントします。

ボリュームの名前は、Btrfs ファイルシステムのサブボリュームのパスとして使用されます。たとえば、サブボリュームは /dev/lvm_pool/lvol001 のように表示されます。ボリュームの作成には、このパスのすべてのオブジェクトが存在する必要があります。ボリュームはこのマウントポイントで参照することもできます。

16.1.1.3. Btrfs スナップショットスナップショット

SSM では、システムのすべての Btrfs ボリュームからスナップショットを作成できます。Btrfs はサブボリュームとスナップショットを区別しないことに注意してください。そのため、SSM は Btrfs スナップショットの宛先を認識できませんが、特別な名前の形式を認識しようとします。スナップショットの作成時に指定される名前が特定のパターンに一致しない場合、スナップショットは認識されず、その代わりに通常の Btrfs ボリュームとして一覧表示されます。

16.1.1.4. Btrfs デバイスデバイス

Btrfs では、特殊デバイスをその上に作成する必要がありません。

16.1.2. LVM バックエンド

プール、ボリューム、およびスナップショットは LVM を使って作成できます。以下は、LVM の観点から見た定義です。

16.1.2.1. LVM プールプール

LVM プールは、LVM ボリュームグループと同じです。つまり、デバイスと新規論理ボリュームのグループ化は LVM プールから実行できます。デフォルトの LVM プール名は lvm_pool です。

16.1.2.2. LVM ボリュームボリューム

LVM ボリュームは通常の論理ボリュームと同じです。

16.1.2.3. LVM スナップショットスナップショット

スナップショットが LVM ボリュームから作成される場合、新規の snapshot ボリュームが作成され、それは他の LVM ボリュームと全く同様の方法で処理されます。Btrfs とは異なり、LVM はスナップショットと通常のボリュームを区別することができるため、スナップショットの名前が特定のパターンに一致している必要はありません。

16.1.2.4. LVM デバイスデバイス

SSM では、ユーザーに対して透過的な物理デバイス上に LVM バックエンドを作成する必要があります。

16.1.3. Crypt バックエンド

SSM における Crypt バックエンドは、cryptsetup および dm-crypt target を使用して暗号化されたボリュームを管理します。Crypt バックエンドは、通常のブロックデバイス上 (または LVM または MD ボリュームなどの他のボリューム上) に暗号化されたボリュームを作成するための通常のバックエンドとして使用したり、単一の手順で暗号化された LVM ボリュームを作成するために使用したりできます。

ボリュームのみが crypt バックエンドを使って作成できます。プールはサポートされておらず、特殊な

第第16章章 SYSTEM STORAGE MANAGER (SSM)

145

ボリュームのみが crypt バックエンドを使って作成できます。プールはサポートされておらず、特殊なデバイスは不要です。

次のセクションは、crypt の観点からボリュームおよびスナップショットを定義します。

16.1.3.1. crypt ボリュームボリューム

crypt ボリュームは dm-crypt によって作成され、元の暗号化されたデバイス上のデータを暗号化されていない状態で表します。RAID またはデバイスの連結はサポートしません。

luks と plain の 2 つのモード (拡張) がサポートされます。デフォルトでは luks が使用されます。拡張の詳細は、man cryptsetup の出力を参照してください。

16.1.3.2. crypt スナップショットスナップショット

Crypt バックエンドはスナップショットの作成をサポートしていません。ただし、暗号化されたボリュームが LVM ボリューム上に作成される場合、ボリューム自体のスナップショットを作成できます。その後、スナップショットは cryptsetup を使用して開くことができます。

16.1.4. Multiple Devices (MD) バックエンド

MD バックエンドは、現時点で、システム内の MD ボリュームについての情報を収集することに制限されています。

16.2. 一般的な SSM タスク

以下のセクションでは、共通の SSM タスクについて説明します。

16.2.1. SSM のインストール

SSM をインストールするには、以下のコマンドを使用します。

# yum install system-storage-manager

関連パッケージがインストールされている場合にのみ、いくつかのバックエンドが有効にされます。

LVM バックエンドには lvm2 パッケージが必要です。

Btrfs バックエンドには btrfs-progs パッケージが必要です。

Crypt バックエンドには device-mapper および cryptsetup パッケージが必要です。

16.2.2. 検出された全デバイスの情報表示

list コマンドを使用すると、検出されたすべてのデバイス、プール、およびスナップショットの情報を表示できます。オプションを指定せずに ssm list を実行すると、以下の出力が表示されます。

# ssm list----------------------------------------------------------Device Free Used Total Pool Mount point----------------------------------------------------------/dev/sda 2.00 GB PARTITIONED/dev/sda1 47.83 MB /test/dev/vda 15.00 GB PARTITIONED


146

/dev/vda1 500.00 MB /boot/dev/vda2 0.00 KB 14.51 GB 14.51 GB rhel----------------------------------------------------------------------------------------------------------Pool Type Devices Free Used Total------------------------------------------------rhel lvm 1 0.00 KB 14.51 GB 14.51 GB---------------------------------------------------------------------------------------------------------------------------------Volume Pool Volume size FS FS size Free Type Mount point---------------------------------------------------------------------------------/dev/rhel/root rhel 13.53 GB xfs 13.52 GB 9.64 GB linear //dev/rhel/swap rhel 1000.00 MB linear/dev/sda1 47.83 MB xfs 44.50 MB 44.41 MB part /test/dev/vda1 500.00 MB xfs 496.67 MB 403.56 MB part /boot---------------------------------------------------------------------------------

表示内容を絞り込むには、引数を使用して表示する項目を指定します。ssm list --help コマンドを実行すると、使用できるオプションのリストが表示されます。

注記注記

指定した引数によっては、すべての情報が表示されないことがあります。

devices または dev 引数を実行すると一部のデバイスが省略されます。CDROM および DM/MD デバイスなどはボリュームとしてリストされ、意図的に表示されません。

一部のバックエンドはスナップショットに対応せず、スナップショットと通常のボリュームを区別できません。このようなバックエンドに snapshot 引数を使用すると、SSM はスナップショットを特定するためにボリューム名を認識しようとします。SSM の正規表現がスナップショットのパターンに一致しない場合、スナップショットは認識されません。

メインの Btrfs ボリューム (ファイルシステム自体) 以外のアンマウントされたBtrfs ボリュームは表示されません。

16.2.3. 新規のプール、論理ボリューム、およびファイルシステムの作成

このセクションでは、デフォルトの名前で新しいプールを作成します。このプールには /dev/vdb および /dev/vdc デバイス、1 G の論理ボリューム、および XFS ファイルシステムが含まれます。

このようなプールを作成するには、ssm create --fs xfs -s 1G /dev/vdb /dev/vdc コマンドを使用します。以下のオプションが使用されます。

--fs オプションは必要なファイルシステムの種類を指定します。現在サポートされるファイルシステムの種類は次のとおりです。

ext3

ext4

xfs

btrfs


147

-s は論理ボリュームのサイズを指定します。以下の接尾辞がユニットの定義でサポートされます。

キロバイトの場合は K または k

メガバイトの場合は M または m

ギガバイトの場合は G または g

テラバイトの場合は T または t

ペタバイトの場合は P または p

エクサバイトの場合は E または e

/dev/vdb および /dev/vdc の 2 つのデバイスを作成します。

# ssm create --fs xfs -s 1G /dev/vdb /dev/vdc Physical volume "/dev/vdb" successfully created Physical volume "/dev/vdc" successfully created Volume group "lvm_pool" successfully created Logical volume "lvol001" created

他にも ssm command には便利なコマンドが 2 つあります。その 1 つが -p pool コマンドです。このコマンドは、ボリュームが作成されるプールを指定します。プールが存在しない場合は、SSM によって作成されます。このコマンドは上記の例では省略されているため、SSM によってデフォルトの名前 lvm_pool が使用されます。しかし、既存の命名規則に合った特定の名前を使用する場合は -p オプションを使用します。

2 つ目の便利なオプションは -n name コマンドです。このコマンドは新規作成された論理ボリュームに名前を付けます。-p と同様に、既存の命名規則に合った特定の名前を使用するために必要になります。

これらの 2 つのオプションを使用した例を以下に示します。

# ssm create --fs xfs -p new_pool -n XFS_Volume /dev/vdd Volume group "new_pool" successfully created Logical volume "XFS_Volume" created

1 つのコマンドのみを使用して、 2 つの物理ボリューム、1 つのプール、および 1 つの論理ボリュームが作成されます。

16.2.4. ファイルシステムの一整合性確認

ssm check コマンドはボリューム上のファイルシステムの整合性をチェックします。チェックする複数のボリュームを指定することができます。ボリューム上にファイルシステムがない場合、ボリュームはスキップされます。

ボリューム lvol001 のすべてのデバイスをチェックするには、コマンド ssm check /dev/lvm_pool/lvol001 をチェックします。

# ssm check /dev/lvm_pool/lvol001Checking xfs file system on '/dev/mapper/lvm_pool-lvol001'.Phase 1 - find and verify superblock...Phase 2 - using internal log - scan filesystem freespace and inode maps...


148

- found root inode chunkPhase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - process newly discovered inodes...Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6No modify flag set, skipping phase 5Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ...Phase 7 - verify link counts...No modify flag set, skipping filesystem flush and exiting.

16.2.5. ボリュームの容量追加

ssm resize コマンドは、指定されたボリュームとファイルシステムのサイズを変更します。ファイルシステムがない場合、ボリュームの容量のみが変更されます。

この例では、現在 900MB の lvol001 という論理ボリュームが 1 つ /dev/vdb にあります。

# ssm list-----------------------------------------------------------------Device Free Used Total Pool Mount point-----------------------------------------------------------------/dev/vda 15.00 GB PARTITIONED/dev/vda1 500.00 MB /boot/dev/vda2 0.00 KB 14.51 GB 14.51 GB rhel/dev/vdb 120.00 MB 900.00 MB 1.00 GB lvm_pool/dev/vdc 1.00 GB--------------------------------------------------------------------------------------------------------------------------Pool Type Devices Free Used Total---------------------------------------------------------lvm_pool lvm 1 120.00 MB 900.00 MB 1020.00 MBrhel lvm 1 0.00 KB 14.51 GB 14.51 GB-----------------------------------------------------------------------------------------------------------------------------------------------------Volume Pool Volume size FS FS size Free Type Mount point


149

--------------------------------------------------------------------------------------------/dev/rhel/root rhel 13.53 GB xfs 13.52 GB 9.64 GB linear //dev/rhel/swap rhel 1000.00 MB linear/dev/lvm_pool/lvol001 lvm_pool 900.00 MB xfs 896.67 MB 896.54 MB linear/dev/vda1 500.00 MB xfs 496.67 MB 403.56 MB part /boot--------------------------------------------------------------------------------------------

論理ボリュームをさらに 500 MB 増やす必要があります。これには、デバイスをプールに追加する必要があります。

~]# ssm resize -s +500M /dev/lvm_pool/lvol001 /dev/vdc Physical volume "/dev/vdc" successfully created Volume group "lvm_pool" successfully extendedPhase 1 - find and verify superblock...Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunkPhase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes...Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3No modify flag set, skipping phase 5Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ...Phase 7 - verify link counts...No modify flag set, skipping filesystem flush and exiting. Extending logical volume lvol001 to 1.37 GiB Logical volume lvol001 successfully resizedmeta-data=/dev/mapper/lvm_pool-lvol001 isize=256 agcount=4, agsize=57600 blks = sectsz=512 attr=2, projid32bit=1 = crc=0data = bsize=4096 blocks=230400, imaxpct=25 = sunit=0 swidth=0 blksnaming =version 2 bsize=4096 ascii-ci=0 ftype=0log =internal bsize=4096 blocks=853, version=2 = sectsz=512 sunit=0 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0data blocks changed from 230400 to 358400

SSM はデバイス上でチェックを実行した後、指定した容量分ボリュームを拡張します。これは、ssm list コマンドで確認できます。


150

# ssm list------------------------------------------------------------------Device Free Used Total Pool Mount point------------------------------------------------------------------/dev/vda 15.00 GB PARTITIONED/dev/vda1 500.00 MB /boot/dev/vda2 0.00 KB 14.51 GB 14.51 GB rhel/dev/vdb 0.00 KB 1020.00 MB 1.00 GB lvm_pool/dev/vdc 640.00 MB 380.00 MB 1.00 GB lvm_pool------------------------------------------------------------------------------------------------------------------------Pool Type Devices Free Used Total------------------------------------------------------lvm_pool lvm 2 640.00 MB 1.37 GB 1.99 GBrhel lvm 1 0.00 KB 14.51 GB 14.51 GB----------------------------------------------------------------------------------------------------------------------------------------------------Volume Pool Volume size FS FS size Free Type Mount point----------------------------------------------------------------------------------------------/dev/rhel/root rhel 13.53 GB xfs 13.52 GB 9.64 GB linear //dev/rhel/swap rhel 1000.00 MB linear/dev/lvm_pool/lvol001 lvm_pool 1.37 GB xfs 1.36 GB 1.36 GB linear/dev/vda1 500.00 MB xfs 496.67 MB 403.56 MB part /boot----------------------------------------------------------------------------------------------

注記注記

LVM ボリュームのみ容量を減らすことが可能です。他のボリュームタイプではサポートされません。容量を減らすには、+ の代わりに - を使用します。たとえば、LVM ボリュームの容量を 50M 減らすには、以下のコマンドを使用します。

# ssm resize -s-50M /dev/lvm_pool/lvol002 Rounding size to boundary between physical extents: 972.00 MiB WARNING: Reducing active logical volume to 972.00 MiB THIS MAY DESTROY YOUR DATA (filesystem etc.)Do you really want to reduce lvol002? [y/n]: y Reducing logical volume lvol002 to 972.00 MiB Logical volume lvol002 successfully resized

+ または - を指定しないと、値は絶対値として認識されます。

16.2.6. スナップショット

既存ボリュームのスナップショットを作成するには、ssm snapshot コマンドを使用します。

注記注記

この操作は、ボリュームが属するバックエンドがスナップショットをサポートしない場合には失敗します。

lvol001 のスナップショットを作成するには、以下のコマンドを使用します。


151

# ssm snapshot /dev/lvm_pool/lvol001 Logical volume "snap20150519T130900" created

ssm list を使用して、追加されたスナップショットセクションを確認します。

# ssm list----------------------------------------------------------------Device Free Used Total Pool Mount point----------------------------------------------------------------/dev/vda 15.00 GB PARTITIONED/dev/vda1 500.00 MB /boot/dev/vda2 0.00 KB 14.51 GB 14.51 GB rhel/dev/vdb 0.00 KB 1020.00 MB 1.00 GB lvm_pool/dev/vdc 1.00 GB------------------------------------------------------------------------------------------------------------------------Pool Type Devices Free Used Total--------------------------------------------------------lvm_pool lvm 1 0.00 KB 1020.00 MB 1020.00 MBrhel lvm 1 0.00 KB 14.51 GB 14.51 GB------------------------------------------------------------------------------------------------------------------------------------------------------Volume Pool Volume size FS FS size Free Type Mount point----------------------------------------------------------------------------------------------/dev/rhel/root rhel 13.53 GB xfs 13.52 GB 9.64 GB linear //dev/rhel/swap rhel 1000.00 MB linear/dev/lvm_pool/lvol001 lvm_pool 900.00 MB xfs 896.67 MB 896.54 MB linear/dev/vda1 500.00 MB xfs 496.67 MB 403.56 MB part /boot--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Snapshot Origin Pool Volume size Size Type----------------------------------------------------------------------------------/dev/lvm_pool/snap20150519T130900 lvol001 lvm_pool 120.00 MB 0.00 KB linear----------------------------------------------------------------------------------

16.2.7. 項目の削除

デバイス、プール、またはボリュームを削除するには ssm remove を使用します。

注記注記

削除時にデバイスがプールによって使用されていると、コマンドの実行に失敗します。コマンドの実行を強制するには、-f 引数を使用します。

削除時にボリュームがマウントされていると、コマンドの実行に失敗します。これは、-f引数を使用して強制できません。

lvm_pool およびその内容をすべて削除するには、以下のコマンドを実行します。

# ssm remove lvm_poolDo you really want to remove volume group "lvm_pool" containing 2 logical volumes? [y/n]: yDo you really want to remove active logical volume snap20150519T130900? [y/n]: y Logical volume "snap20150519T130900" successfully removed


152

Do you really want to remove active logical volume lvol001? [y/n]: y Logical volume "lvol001" successfully removed Volume group "lvm_pool" successfully removed

16.3. SSM のリソース

SSM の詳細は、以下のリソースを参照してください。

man ssm ページは説明や例を提供し、本書には記載されていないすべてのコマンドおよびオプションの詳細を提供します。

SSM のローカルドキュメントは doc/ ディレクトリーにあります。

SSM wiki は、http://storagemanager.sourceforge.net/index.html からアクセスできます。

メーリングリストは https://lists.sourceforge.net/lists/listinfo/storagemanager-devel からサブスクライブでき、メーリングリストのアーカイブはhttp://sourceforge.net/mailarchive/forum.php?forum_name=storagemanager- devel からアクセスできます。メーリングリストは、開発者が情報交換を行う場です。現在、ユーザーのメーリングリストはないため、質問がある場合はこのメーリングリストに投稿してください。


153

http://storagemanager.sourceforge.net/index.html

https://lists.sourceforge.net/lists/listinfo/storagemanager-devel

http://sourceforge.net/mailarchive/forum.php?forum_name=storagemanager- devel

第17章ディスク割り当てディスク領域はディスククォータ (quota) によって制限できます。ディスククォータは、ユーザーが過度のディスク領域を消費するか、パーティションが満杯になる前にシステム管理者に警告をします。

ディスククォータは、ユーザーグループ用にも個別のユーザー用にも設定できます。これにより、ユーザーが参加しているプロジェクトに割り振られた領域 (プロジェクトごとに所有グループが存在すると想定) とは別に、ユーザー固有のファイル (電子メールなど) に割り振った領域を管理することが可能になります。

さらにクォータは、消費されるディスクブロックの数の制御だけでなく、inode (UNIX ファイルシステム内のファイルに関する情報を含むデータ構造) の数も制御するように設定できます。inode はファイル関連の情報を組み込むように使用されるため、これが作成されるファイルの数を制御することも可能にします。

ディスククォータを実装するには、quota RPM をインストールしておく必要があります。

注記注記

本章はすべてのファイルシステムを対象としていますが、一部のファイルシステムには独自のクォータ管理ツールが含まれています。詳細については、これらのファイルシステムの説明の該当する部分を参照してください。

XFS ファイルシステムは、「XFS クォータの管理」を参照してください。

Btrfs にはディスククォータがないため、ここでは扱われません。

17.1. ディスククォータの設定

ディスククォータを実装するには、以下の手順を用います。

1. /etc/fstab を修正することで、ファイルシステムごとのクォータを有効にします。

2. ファイルシステムを再マウントします。

3. クォータデータベースファイルを作成して、ディスク使用状況テーブルを生成します。

4. クォータポリシーを割り当てます。

これらの各ステップは、以下のセクションで詳しく解説しています。

17.1.1. クォータの有効化

手順手順17.1 クォータの有効化クォータの有効化

1. root でログインします。

2. /etc/fstab ファイルを編集します。

3. usrquota または grpquota のどちらかのオプション、またはそれら両方をクォータが必要となるファイルシステムに追加します。

例例17.1 /etc/fstab の編集の編集

たとえば、テキストエディター vim を使用するには、以下を入力します。


154

# vim /etc/fstab

例例17.2 クォータの追加クォータの追加

/dev/VolGroup00/LogVol00 / ext3 defaults 1 1LABEL=/boot /boot ext3 defaults 1 2none /dev/pts devpts gid=5,mode=620 0 0none /dev/shm tmpfs defaults 0 0none /proc proc defaults 0 0none /sys sysfs defaults 0 0/dev/VolGroup00/LogVol02 /home ext3 defaults,usrquota,grpquota 1 2/dev/VolGroup00/LogVol01 swap swap defaults 0 0 . . .

この例では、/home ファイルシステムがユーザーとグループの両方のクォータを有効にしています。

注記注記

以下の例では、Red Hat Enterprise Linux のインストール時に個別の /home パーティションが作成されていると想定しています。root (/) パーティションは /etc/fstab ファイル内でクォータポリシーを設定するために使用できます。

17.1.2. ファイルシステムの再マウント

usrquota または grpquota オプションのどちらか、またはそれら両方を追加した後には、fstab エントリーが修正されたそれぞれのファイルシステムを再マウントします。ファイルシステムがどのプロセスでも使用されていない場合は、以下のメソッドのいずれかを使用します。

umount コマンドを実行して、その後に mount コマンドを発行してファイルシステムを再マウントします。各種ファイルシステムのマウントとアンマウント用の特定の構文に関しては、umount と mount の両方の man ページを参照してください。

mount -o remount file-system コマンド (ここで file-system はファイルシステムの名前) を実行してファイルシステムを再マウントします。たとえば、/home ファイルシステムを再マウントするには、mount -o remount /home コマンドを実行します。

ファイルシステムが現在使用中の場合、そのファイルシステムを再マウントする最も簡単な方法は、システムを再起動することです。

17.1.3. クォータデータベースファイルの作成

クォータが有効にされたそれぞれのファイルシステムを再マウントした後は、quotacheck コマンドを実行します。

quotacheck コマンドは、クォータが有効にされているファイルシステムを検証し、現在のディスク使用状況テーブルをファイルシステムごとに作成します。このテーブルは、ディスク使用状況についてのオペレーティングシステム用コピーを更新するのに使用されます。また、ファイルシステムのディスククォータファイルが更新されます。

注記注記

第第17章章ディスク割り当てディスク割り当て

155

注記注記

quotacheck コマンドは、ディスク使用状況テーブルがマウント時に自動的に完成するため、XFS には全く影響を与えません。詳細情報については、xfs_quota(8) の manページを参照してください。

手順手順17.2 クォータデータベースファイルの作成クォータデータベースファイルの作成

1. 以下のコマンドを使用してファイルシステムでクォータファイルを作成します。

# quotacheck -cug /file system

2. 以下のコマンドを使用して、ファイルシステムごとに現在のディスクの使用率の表を生成します。

# quotacheck -avug

クォータファイルを作成するのに使用するオプションを以下に示します。

c

クォータファイルが、クォータを有効化して各ファイルシステムに作成される必要があることを指定します。

u

ユーザークォータを確認します。

g

グループクォータをチェックします。-g のみを指定すると、グループクォータファイルが作成されます。

-u または -g オプションのいずれかを指定している場合は、ユーザークォータファイルのみが作成されます。

以下のオプションは、現在のディスク使用率の表を生成するのに使用されます。

a

クォータが有効にされた、ローカルマウントのファイルシステムをすべてチェック

v

クォータチェックの進行状態について詳細情報を表示

u

ユーザーディスククォータの情報をチェック

g

グループディスククォータの情報をチェック

quotacheck の実行が終了すると、有効なクォータ (ユーザーまたはグループ、あるいは両方) に対応す


156

quotacheck の実行が終了すると、有効なクォータ (ユーザーまたはグループ、あるいは両方) に対応するクォータファイルには、/home などのクォータが有効なローカルマウントの各ファイルシステム用のデータが追加されます。

17.1.4. ユーザーごとのクォータ割り当て

最終ステップは、edquota コマンドを使用したディスククォータの割り当てです。

前提条件

ユーザーは、ユーザークォータを設定する前に存在する必要があります。

手順手順17.3 ユーザーごとのクォータ割り当てユーザーごとのクォータ割り当て

1. ユーザークォータを割り当てるには、以下のコマンドを使用します。

# edquota username

クォータを割り当てるユーザーで username を置き換えます。

2. ユーザーのクォータが設定されていることを確認するには、以下のコマンドを使用します。

# quota username

例例17.3 ユーザーへのクォータの割り当てユーザーへのクォータの割り当て

たとえば、クォータが /etc/fstab 内で /home パーティション (以下の例では /dev/VolGroup00/LogVol02) 用に有効になっていて、コマンド edquota testuser が実行されると、システムのデフォルトとして設定されているエディターに以下が表示されます。

Disk quotas for user testuser (uid 501): Filesystem blocks soft hard inodes soft hard /dev/VolGroup00/LogVol02 440436 0 0 37418 0 0

注記注記

EDITOR 環境変数で定義されているテキストエディターが edquota によって使用されます。このエディターを変更するには、使用している ~/.bash_profile ファイル内で EDITOR 環境変数を選択するエディターへの完全パスに設定します。

最初の列はクォータが有効になっているファイルシステムの名前です。2 つ目の列はユーザーが現在使用しているブロック数を示します。その次の 2 つの列はこのファイルシステムでのユーザーに対するソフトおよびハードブロックリミットを設定するために使用されます。inodes の列は、現在ユーザーが使用している inode の数を示します。最後の列は、ファイルシステム上のユーザーに対するソフトおよびハードの inode 制限を設定するために使用されます。

ハードブロックリミットは、ユーザーまたはグループが使用可能な絶対最大ディスク容量です。この上限に達すると、それ以上のディスク容量を使用できなくなります。

ブロックのソフトリミットは、使用可能なディスク容量の最大値を定義します。しかし、ハードリミットとは異なり、ソフトリミットは一定の期間だけ超過できるようになっています。この期間は猶予期間として知られています。猶予期間は秒、分、時間、日、週、または月で表されます。


157

いずれかの値がゼロに設定してある場合は、そのリミットは設定されていないことになります。テキストエディターで必要な制限に変更します。

例例17.4 必要な制限の変更必要な制限の変更


Disk quotas for user testuser (uid 501): Filesystem blocks soft hard inodes soft hard /dev/VolGroup00/LogVol02 440436 0 0 37418 0 0

ユーザーのクォータが設定されていることを確認するには、以下のコマンドを使用します。

# quota testuserDisk quotas for user username (uid 501): Filesystem blocks quota limit grace files quota limit grace /dev/sdb 1000* 1000 1000 0 0 0

17.1.5. グループごとのクォータ割り当て

クォータは、グループごとに割り当てることも可能です。

前提条件

グループは、グループクォータを設定する前に存在する必要があります。

手順手順17.4 グループごとのクォータ割り当てグループごとのクォータ割り当て

1. グループクォータを設定するには、以下のコマンドを使用します。

# edquota -g groupname

2. グループクォータが設定されていることを確認するには、以下のコマンドを使用します。

# quota -g groupname

例例17.5 グループへのクォータの割り当てグループへのクォータの割り当て

たとえば、devel グループのグループクォータを設定するには、以下のコマンドを使用します。

# edquota -g devel

このコマンドにより、グループの既存クォータがテキストエディターに表示されます。

Disk quotas for group devel (gid 505):Filesystem blocks soft hard inodes soft hard/dev/VolGroup00/LogVol02 440400 0 0 37418 0 0

このリミットを変更し、ファイルを保存します。

グループクォータが設定されたことを確認するには、次のコマンドを使用します。


158

# quota -g devel

17.1.6. ソフトリミットの猶予期間の設定

所定のクォータがソフトリミットを持つ場合、その猶予期間 (ソフトリミットを超過してもよい期間の値) は以下のコマンドで編集できます。

# edquota -t

このコマンドはユーザーまたはグループのいずれかの inode またはブロックのクォータに対して機能します。

重要重要

他の edquota コマンドは特定のユーザーまたはグループのクォータで機能しますが、-tオプションはクォータが有効になっているすべてのファイルシステムで機能します。

17.2. ディスククォータの管理

クォータが実装されている場合には、若干の保守が必要となります。大半は、クォータの超過監視および精度確認という形となります。

ユーザーが繰り返しクォータを超過したり、常にソフトリミットに達している場合には、ユーザーのタイプや、ユーザーの作業にディスク容量が及ぼす影響の度合に応じて、システム管理者には 2 つの選択肢があります。管理者は、ユーザーが使用するディスク領域を節約する方法をわかるようにするか、ユーザーのディスククォータを拡大するかのいずれかを行うことができます。

17.2.1. 有効化と無効化

クォータはゼロに設定することなく、無効にすることができます。すべてのユーザーとグループのクォータをオフにするには、以下のコマンドを使用します。

# quotaoff -vaug

-u か -g のどちらも指定されていない場合、ユーザーのクォータのみが無効になります。-g のみが指定されている場合は、グループのクォータのみが無効になります。-v スイッチはコマンドが実行する際に状態の詳細情報を表示します。

ユーザーとグループクォータを再び有効化するには、以下のコマンドを使用します。

# quotaon

すべてのファイルシステムにユーザーとグループのクォータを有効にするには、以下のコマンドを使用します。

# quotaon -vaug

-u または -g のどちらも指定されていない場合、ユーザーのクォータのみが有効になります。-g のみが指定されている場合は、グループのクォータのみが有効になります。

/home などの特定のファイルシステムにクォータを有効にするには、以下のコマンドを使用します。


159

# quotaon -vug /home

注記注記

quotaon コマンドは、マウント時に自動的に実行されるため、XFS に常に必要となる訳ではありません。詳細情報については、quotaon(8) の man ページを参照してください。

17.2.2. ディスククォータに関するレポート

ディスク使用状況のレポートを作成するには、repquota ユーティリティーの実行が必要になります。

例例17.6 repquota コマンドの出力コマンドの出力

たとえば、コマンド repquota /home は以下の出力を生成します。

*** Report for user quotas on device /dev/mapper/VolGroup00-LogVol02Block grace time: 7days; Inode grace time: 7days Block limits File limitsUser used soft hard grace used soft hard grace----------------------------------------------------------------------root -- 36 0 0 4 0 0kristin -- 540 0 0 125 0 0testuser -- 440400 500000 550000 37418 0 0

クォータが有効化されたすべてのファイルシステム (オプション -a) のディスク使用状況レポートを表示するには、以下のコマンドを使用します。

# repquota -a

分かりやすいレポートが表示されますが、ここでいくつかのポイントを説明します。各ユーザーの後に表示される -- はブロックまたは inode が超過しているかどうかを素早く判別するための手段です。どちらかのソフトリミットが超過していると、対応する - の位置に + が表示されます。最初の- はブロックの制限で、2 つ目が inode の制限を示します。

通常、grace 列は空白です。ソフトリミットが超過した場合、この列には猶予期間の残り時間の値に等しい時間指定が含まれます。猶予期間が超過した場合、この位置には none が表示されます。

17.2.3. クォータの精度維持

システムクラッシュなどにより、ファイルシステムが正常のマウント解除に失敗した場合は、以下のコマンドを実行する必要があります。

# quotacheck

ただし、システムがクラッシュしていないとしても、quotacheck は定期的に実行できます。quotacheck を定期的に実行する安全な方法には、以下が含まれます。

次回の再起動時に次回の再起動時に quotacheck を確実に実行するを確実に実行する

注記注記


160

注記注記

この方法は、定期的に再起動される (ビジーな) 複数ユーザーシステムに最も適しています。

/etc/cron.daily/ または /etc/cron.weekly/ ディレクトリーにシェルスクリプトを保存するか、以下のコマンドを使用してスケジュール設定します。

# crontab -e

crontab -e には、touch /forcequotacheck コマンドが含まれます。このスクリプトは root ディレクトリーに空の forcequotacheck ファイルを作成するため、起動時にシステムの init スクリプトがこれを検索します。このディレクトリーが発見されると init スクリプトは quotacheck を実行します。その後、init スクリプトは /forcequotacheck ファイルを削除します。このように、cron でこのファイルが定期的に作成されるようにスケジュールすることにより、次回の再起動時に quotacheck を確実に実行することができます。

cron の詳細は、man cron を参照してください。

シングルユーザーモードでシングルユーザーモードで quotacheck を実行を実行

quotacheck を安全に実行する別の方法として、クオータファイルのデータ破損の可能性を回避するためにシングルユーザーモードでシステムを起動して、以下のコマンドを実行する方法があります。

# quotaoff -vug /file_system

# quotacheck -vug /file_system

# quotaon -vug /file_system

実行中のシステム上で実行中のシステム上で quotacheck を実行を実行

必要な場合には、いずれのユーザーもログインしておらず、チェックされているファイルシステムに開いているファイルがない状態のマシン上で quotacheck を実行することができます。quotacheck -vaug file_system コマンドを実行します。このコマンドは、quotacheck が指定の file_system を読み込み専用として再マウントできない場合に失敗します。チェックの後には、ファイルシステムは読み込み/書き込みとして再マウントされることに注意してください。

警告警告

読み込み/書き込みでマウントされているライブのファイルシステム上での quotacheck の実行は、quota ファイルが破損する可能性があるため、推奨されません。

cron の設定方法の詳細は、man cron を参照してください。


161

17.3. ディスククオータのリファレンス

ディスククォータに関する更なる情報は、以下にあげるコマンドの man ページを参照してください。

quotacheck

edquota

repquota

quota

quotaon

quotaoff


162

第18章 RAID (REDUNDANT ARRAY OF INDEPENDENT DISKS)RAID の登場した背景には、容量が小さく手頃なディスクドライブを複数集めてアレイに結合させ、容量が大きく高価なドライブに負けないパフォーマンスと冗長性を実現しようとする動きがありました。この複数のデバイスからなるアレイは、コンピューター上では単一の論理ストレージユニットまたはドライブとして表されます。

RAID では複数のディスクに情報を拡散させることができます。ディスクのストライピング (RAID レベル 0)、ディスクのミラーリング (RAID レベル 1)、パリティーによるディスクのストライピング (RAIDレベル 5) などの技術を使用して冗長性を得ながら待ち時間を抑え、帯域幅を増幅させることでハードディスクがクラッシュした場合の復元力を最大限に引き出します。

データは、一貫して同じサイズの大きさのチャンク (通常は 256K または 512K、ただし他の値も可) に分割され、アレイ内の各ドライブに分散されます。各チャンクは導入している RAID レベルに応じてRAID アレイ内のハードドライブに書き込まれます。データが読み込まれるとこのプロセスが逆をたどります。その動作はアレイ内の複数のドライブがまるで一台の大容量ドライブであるかのように見えます。

システム管理者や大容量のデータを管理している方にとって RAID は利点の多いテクノロジーとなります。RAID を採用する主な利点を示します。

速度を高める

単一の仮想ディスクを使用してストレージ容量を増加させる

ディスク障害によるデータ損失のリスクを最小限に抑える

18.1. RAID のタイプ

RAID には、ファームウェア RAID、ハードウェア RAID、ソフトウェア RAID の 3 種類の RAID タイプがあります。

ファームウェア RAID

ファームウェア RAID (ATARAID とも呼ばれる) とは、ソフトウェア RAID の種類でファームウェアベースのメニューを使って RAID セットを設定することができます。この種類の RAID で使用されるファームウェアは BIOS にも搭載され、RAID セットから起動することができます。RAID セットのメンバーをマークするオンディスクのメタデータ形式は製造元によって異なります。Intel Matrix RAID がファームウェア RAID システムの一例となります。

ハードウェア RAID

ハードウェアベースのアレイでは、RAID サブシステムをホストとは別に管理します。ホストに対して、1 RAID アレイごとに 1 つのディスクを表します。

ハードウェア RAID デバイスはシステムの内部にあっても外部にあっても構いません。内部デバイスは一般的には特殊なコントローラーカードで構成され、RAID の作業はオペレーティングシステムに対して透過的に処理されます。外部デバイスは一般的には SCSI、ファイバーチャネル、iSCSI、InfiniBand、他の高速ネットワークなどの相互接続でシステムに接続され、システムには論理ボリュームとして表されます。

RAID コントローラーカードはオペレーティングシステムに対し SCSI コントローラーのように動作し、実際のドライブ通信をすべて処理します。ドライブはユーザーによって RAID コントローラに接続されてから (通常の SCSI コントローラー同様に)、RAID コントローラーの構成に追加されます。オペレーティングシステムではこの違いを認識できません。

第第18章章 RAID (REDUNDANT ARRAY OF INDEPENDENT DISKS)

163

ソフトウェア RAID

ソフトウェア RAID では、カーネルディスク (ブロックデバイス) コード内に各種の RAID レベルを実装しています。高価なディスクコントローラーカードやホットスワップ機能のシャーシ [2] などを必要としないため、もっとも安価なソリューションとなります。ソフトウェア RAID は安価な IDE ディスクでも SCSI ディスクでも動作します。また、最近の高速な CPU でもソフトウェア RAID は一般的にハードウェア RAID より優れたパフォーマンスを見せます。

Linux カーネルにはマルチディスク (MD) ドライバーが含まれ、これにより RAID ソリューションは完全にハードウェアに依存しなくてもよくなります。ソフトウェアベースのアレイのパフォーマンスはサーバーの CPU 性能や負荷に左右されます。

Linux ソフトウェア RAID スタックの主な機能:

マルチスレッド設計

再構成を行うことなく Linux マシン間でのアレイの移動が可能

待機状態のシステムリソースを使ってバックグラウンドでのアレイの再構成が可能

ホットスワップ可能なドライブのサポート

CPU の自動検出でストリーミング SIMD サポートなどの特定 CPU の機能を活用

アレイ内の複数ディスク上にある不正セクターを自動修正

RAID データの整合性を定期的にチェックしアレイの健全性を確保

アレイの予防的なモニタリング、重要なイベントが発生した際は指定アドレスへの警告メールを送信

書き込みを集中としたビットマップ、アレイ全体を再同期させるのではなく再同期を必要とするディスク部分を正確にカーネルに認識させることで再同期イベントの速度を大幅に高速化

再同期のチェックポイント機能、再同期中のコンピュータの再起動時に全体をすべてやり直すのではなく前回の停止時点から再同期を開始

インストール後のアレイのパラメーター変更が可能、新しいディスクを追加しディスク 4 台のRAID5 から 5 台の RAID5 に増大させることが可能。この拡大作業はライブで行うことができ、新しいアレイでの再インストールは不要

18.2. RAID レベルとリニアサポート

RAID ではレベル 0、1、4、5、6、10、リニアなどの各種設定に対応します。 RAID タイプは以下のように定義されます。

レベルレベル 0

ストライピングとも呼ばれる RAID レベル 0 はストライプ化したデータをマッピングする技術でパフォーマンスが本位とされます。つまり、アレイに書き込まれたデータはストライプに分割されアレイのメンバーディスク群に分散して書き込まれます。レベル固有のオーバーヘッドも少なく I/Oパフォーマンスに優れていますが冗長性はまったくありません。

RAID レベル 0 実装の多くがアレイ内のメンバーデバイス群にデータの分散を行う際、最小サイズのデバイスに合わせたサイズまでしかデータの分散を行いません。つまり、各デバイスの容量が異なる場合、すべて最小サイズのドライブと同じサイズであるかのように扱われます。したがってレ


164

ベル 0 アレイの一般的なストレージ容量はハードウェア RAID 内の最小サイズのメンバーディスクの容量と同じになるか、ソフトウェア RAID 内の最小サイズのメンバーパーティションにアレイ内のディスク数かパーティション数をかけたものと同じ容量になります。


ミラーリングとも呼ばれる RAID レベル 1 は RAID 形式の中では最も長く使用されているレベルになります。同一データをアレイの各メンバーディスクに書き込むことで冗長性を提供し、各ディスクにミラリングしたコピーを残します。ミラーリングは簡素でありながら高いデータ可用性を提供するため現在でもよく使用されています。レベル 1 は 2 台以上のディスクで動作、データに関する信頼性が高く読み込み頻度の高いアプリケーションのパフォーマンスは向上されますが、相当のオー

バーヘッドも必要とします。 [3]

レベル 1 アレイのストレージ容量は、ハードウェア RAID 内でミラリングされている最小サイズのハードディスクと同じ容量か、ソフトウェア RAID 内でミラリングされている最小のパーティションと同じ容量になります。レベル 1 の冗長性が RAID タイプのなかでは最高となります。アレイは単一ディスクのみで動作可能です。


レベル 4 ではデータ保護のため単一ディスクドライブに集中したパリティー [4] を使用します。専用パリティーディスクは RAID アレイへのすべての書き込みトランザクションでパリティー固有のボトルネックとなるため、システム管理者が意図的にこのボトルネックを考慮に入れてソフトウェアRAID デバイスを設計している場合を除き (アレイにデータの移植が完了したら書き込みのトランザクションはほとんど発生しないようなアレイ)、レベル 4 はライトバックのキャッシュ機能などのテクノロジーが付随されない限りめったに使用されません。このように RAID レベル 4 は稀にしか使用されないため、 Anaconda のオプションとして提供されていません。ただし、ユーザーが必要とする場合には手動による作成が可能です。

ハードウェア RAID レベル 4 のストレージ容量は、最小サイズのメンバーのパーティションにパーティション数から 1 を引いたを引いた数をかけたものと同じ容量になります。 RAID レベル 4 アレイのパフォーマンスは常に非対称となります。つまり、読み込みの方が書き込みより優れているということです。パリティーを生成する際に書き込みの方が CPU やメインメモリーを多く消費し、また実際のデータをディスクに書き込み際にもデータだけではなくパリティーも書き込むためバスの帯域幅を余計に消費します。一方、読み込みの場合はアレイが低下状態でない限りはデータを読み取るだけでパリティーは関係ありません。その結果、通常の動作状況で同じデータ転送量の場合、読み込みの方がドライブやコンピュータのバス全体に対するトラフィックが少なくなります。


最も一般的なタイプの RAID です。アレイのメンバーディスクドライブすべてにパリティーを分散させることで、RAID レベル 5 はレベル 4 で見られた書き込みに関するボトルネックを解消します。パフォーマンス関連の唯一のボトルネックはパリティーを計算するプロセス自体となります。最近のCPU やソフトウェア RAID ではパリティーを非常に早く生成できるようになってきたため、これもボトルネックではなくなってきています。ただし、ソフトウェア RAID5 アレイ内に非常に多数のメンバーデバイスがあり、全デバイスでの結合された集合データの転送速度が高速になる場合にはこのボトルネックが問題となってくる可能性があります。

レベル 4 と同様、レベル 5 のパフォーマンスも非対称となり、読み込みの方が書き込みより大幅にパフォーマンスが高くなります。RAID レベル 5 のストレージ容量はレベル 4 と同じです。


データの冗長性および維持がパフォーマンスより重要となると共に、レベル 1 での領域使用に関する非効率性は認められないような場合、一般的に採用される RAID レベルになります。レベル 6 ではアレイ内の 2 台のドライブの損失からの復元が可能となる複合パリティースキームを使用してい


165

ます。この複合パリティースキームによりソフトウェア RAID デバイスにはかなり大きな負荷がCPU にかかることとなる他、書き込みのトランザクション時の負荷も大きくなります。このため、レベル 6 はレベル 4 および 5 よりさらに非対称なパフォーマンスを見せます。

RAID レベル 6 アレイの合計容量は、 RAID レベル 5 および 4 の計算方法と同じですが、デバイス数から (1 ではなく) 追加パリティストレージ領域用に2を引きます。


この RAID レベルではレベル 0 のパフォーマンス性とレベル 1 の冗長性の両方を取り入れることを目的としています。また、デバイスが 2 つ以上あるレベル 1 のアレイでは無駄になる領域を低減します。レベル 10 では、 3 台のドライブアレイで格納するデータのコピーは 2 つのみとなるよう設定することが可能です。これによりアレイの全体サイズを最小サイズのデバイスと同じサイズ (3 台のドライブのレベル 1 アレイと同様) ではなく、最小サイズの 1.5 倍のサイズにすることができるようになります。

レベル 10 アレイを作成する際の使用可能なオプションの数が多く、特定のユースケースに適切なオプションを選択することが簡単ではないため、インストール時に作成するのは実用的とは言えません。コマンドラインツールの mdadm を使用すると手作業で作成することができます。オプションの詳細およびパフォーマンスに関するトレードオフは man md を参照してください。

リニアリニア RAID

より大きな仮想ドライブを作成するために複数ドライブをグループ化するのがリニア RAID です。リニア RAID では、1 つのメンバードライブから順次チャンクを割り当て、ドライブが完全に満杯になってから次のドライブに移動します。メンバードライブ間での I/O 動作が分割される可能性はないため、グループ化によってはパフォーマンスの向上は見られません。また、リニア RAID では冗長性も得られません。メンバードライブの 1 つに障害が発生した場合はアレイ全体が使用できないため、実際には信頼性についても低下します。容量は全メンバーディスクの合計になります。

18.3. LINUX RAID サブシステム

Linux の RAID は以下のサブシステムから構成されます。

Linux ハードウェア RAID のコントローラードライバー

Linux ではハードウェア RAID コントローラーに特定の RAID サブシステムはありません。特殊な RAIDチップセットを使用するため、ハードウェア RAID のコントローラーにはそれ自体のドライブが同梱されています。このドライバーによりシステムは RAID セットを通常のディスクとして検出することができるようになります。

mdraid

mdraid サブシステムは Linux 向けのソフトウェア RAID ソリューションとして設計され、また Linux 環境のソフトウェア RAID に適したソリューションとなります。このサブシステムでは独自のメタデータ形式を使用します。一般的にはネイティブの mdraid メタデータと呼ばれます。

mdraid では外部のメタデータとして知られる他のメタデータ形式にも対応しています。Red HatEnterprise Linux 7 では外部のメタデータで mdraid を使用し ISW / IMSM (Intel のファームウェアRAID) セットにアクセスします。mdraid セットは mdadm ユーティリティーで設定および制御を行います。

dmraid

Device-mapper RAID や dmraid はディスクをひとつの RAID セットにまとめるメカニズムを提供するデ


166

Device-mapper RAID や dmraid はディスクをひとつの RAID セットにまとめるメカニズムを提供するデバイスマッパーのカーネルコードを参照します。同じこのカーネルでは RAID 設定のメカニズムは提供していません。

dmraid は完全にユーザー領域で設定され、各種のオンディスクメタデータ形式への対応を容易にしています。このため、dmraid は幅広いファームウェア RAID 実装で使用されています。また、dmraid はIntel のファームウェア RAID にも対応しますが、Red Hat Enterprise Linux 7 では mdraid を使ってIntel ファームウェア RAID セットにアクセスします。

注記注記

dmraid は、Red Hat Enterprise Linux 7.5 リリース以降から推奨されなくなっています。詳細は、Red Hat Enterprise Linux 7.4 リリースノートの「Deprecated Functionality」を参照してください。

18.4. ANACONDA インストーラーの RIAD サポート

システム上のハードウェアおよびファームウェア RAID セットはすべて Anaconda インストーラーによって自動的に検出され、インストールが行えるようになります。また、 Anaconda は mdraid を使用してソフトウェア RAID に対応しているため、既存の mdraid セットを認識することができます。

Anaconda ではインストール時に RAID セットを作成するユーティリティーを提供しています。ただし、このユーティリティーでは新しいセットのメンバーにできるのはパーティションのみになります(ディスク全体とは対照的)。セットにディスク全体を使用するには、ディスク全体にまたがる 1 つのパーティションを作成し、そのパーティションを RAID セットのメンバーとして使用します。

RAID セットが root ファイルシステムによって使用される場合、Anaconda により特殊なカーネルコマンドラインオプションがブートローダーの設定に渡され、 root ファイルシステムを検索する前に RAIDセットをアクティブにするよう initrd に指示します。

インストール中に RAID を設定する説明は、Red Hat Enterprise Linux 7 「インストールガイド」を参照してください。

18.5. インストール後のルートディスクの RAID1 への変換

Red Hat Enterprise Linux 7 のインストール後に RAID の一部でないルートディスクを RAID1 ミラーに変換する必要がある場合は、Red Hat ナレッジベースの記事「How do I convert my root disk to RAID1after installation of Red Hat Enterprise Linux 7?」を参照してください。

PowerPC (PPC) アーキテクチャーでは、以下の追加ステップを行う必要があります。

1. PowerPC Reference Platform (PReP) ブートパーティションの内容を /dev/sda1 から /dev/sdb1 にコピーします。

# dd if=/dev/sda1 of=/dev/sdb1

2. 両方のディスクの最初のパーティション上で prep および boot フラグを更新します。

$ parted /dev/sda set 1 prep on$ parted /dev/sda set 1 boot on

$ parted /dev/sdb set 1 prep on$ parted /dev/sdb set 1 boot on

注記注記


167

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality



注記注記

PowerPC マシンでは grub2-install /dev/sda コマンドを実行できず、エラーが返されますが、システムは想定どおり起動します。

18.6. RAID セットの設定

一般的には、ほとんどの RAID セットがその作成時にファームウェアメニューやインストーラーを使って設定されます。システムのインストール後、できればマシンを再起動したりファームウェアメニューに入らずに RAID セットの作成や変更を行う必要が生じることがあります。

RAID セットを簡単に設定したり、ディスクの追加後でも新たなセットを定義したりすることができるハードウェア RAID コントローラーがあります。これらのコントローラーには標準の API がないためドライバー固有のユーティリティーを使用する必要があります。詳細は、ご使用のハードウェア RAID コントローラーの説明書などを参照してください。

mdadm

Linux では mdadm コマンドラインツールを使ってソフトウェア RAID の管理を行います (mdraid)。 mdadm の各種のモードおよびオプションについては man mdadm を参照してください。man にはソフトウェア RAID アレイの作成や監視、組み立てなど一般的な作業についても役に立つ事例が記載されています。

dmraid

その名の通り dmraid はデバイスマッパー RAID セットの管理に使用されます。 dmraid ツールは各種の形式に対応している複数のメタデータ形式のハンドラを使用して ATARAID デバイスの検索を行います。対応している形式の一覧を表示させるには、dmraid -l を実行します。

「Linux RAID サブシステム」で説明している通り、RAID セットをいったん作成するとその後は dmraid ツールによる設定を行うことはできません。dmraid の使い方については man dmraid を参照してください。

18.7. 高度な RAID デバイスの作成

インストール完了後では作成できないアレイ上にオペレーティングシステムをインストールしたい場合があります。一般的には /boot や root ファイルシステムを複雑な RAID デバイス上にセットアップする場合などです。このような場合、 Anaconda ではサポートしていないアレイオプションを使わなければならない場合があります。これを回避する策として次の手順を行います。

手順手順18.1 高度な高度な RAID デバイスの作成デバイスの作成

1. インストールディスクを挿入します。

2. 最初に起動した時点で、インストールインストールやアップグレードアップグレードではなくレスキューモードレスキューモードを選択します。レスキューモードレスキューモードでシステムが完全に起動すると、コマンドラインターミナルが表示されます。

3. このターミナルで parted を使用し、RAID パーティションを目的のハードドライブ上に作成します。次に、mdadm を使用し、使用できるすべての設定およびオプションを使ってこれらのパーティションから RAID アレイを手作業で作成します。実行方法の詳細については、13章パーティション、man parted、および man mdadm を参照してください。

4. アレイを作成したら、オプションでアレイ上にファイルシステムを作成することもできます。


168

5. コンピューターを再起動して、今度はインストールインストールかアップグレードアップグレードを選択し通常通りにインストールを行います。 Anaconda によってシステム内のディスクが検索され、すでに存在している RAID デバイスが検出されます。

6. システム内のディスクの使い方に関しては、カスタムレイアウトカスタムレイアウトを選択して次へ次へをクリックします。デバイスの一覧にすでに存在している MD RAID デバイス群が表示されます。

7. RAID デバイスを選択し、編集編集をクリックしてそのマウントポイントと (オプションで) 使用するファイルシステムのタイプを設定し完了完了をクリックします。Anaconda によりすでに存在しているこの RAID デバイスへのインストールが行われ、レスキューモードレスキューモードで作成したときに選択したカスタムオプションが維持されます。

注記注記

制約のあるインストーラーのレスキューモードレスキューモードに man ページは含まれません。man mdadm および man md にはいずれもカスタム RAID アレイを作成する場合に役立つ情報が記載されているため、回避策を講じている間に必要となる場合があります。このような場合には、 man ページを表示させたマシンにアクセスをしておくか、レスキューレスキューモードモードで起動してカスタムアレイを作成する前に man ページを印刷しておくと便利です。

[2] ホットスワップ機能のシャーシを使用するとシステムの電源を落とさずにハードドライブを取り除くことができます。

[3] RAID レベル 1 では同じ情報がアレイ内の全ディスクに書き込まれることになるためデータの信頼性は高くなりますが、レベル 5 などのパリティベースの RAID レベルに比べ領域使用の効率性は低くなります。ただし、この効率性性の低さによりパフォーマンスが向上されます。パリティベースの RAID レベルではパリティを生成するためにかなりの CPU を消費します。一方、RAID レベル 1 では単純に同じデータを複数の RAID メンバーに複数回書き込むだけのため、CPU のオーバーヘッドは非常に少なくなります。RAID レベル 1 はソフトウェア RAID を採用しているマシン上ではパリティベースの RAID レベルより優れたパフォーマンスを見せます。また、マシン上のCPU リソースには RAID アクティビティ以外の動作による負担が常にかかります。

[4] パリティー情報はアレイ内の残りのメンバーディスクのコンテンツに応じて計算されます。この情報はアレイ内のいずれかのディスクに障害が発生した場合に行われるデータの再構成に使用されます。再構成されたデータは、置換される前に障害が発生したディスクへの I/O 要求に応えるため使用され、また置換後に障害が発生したディスクへの移植にも使用されます。


169

第19章 MOUNT コマンドの使い方

Linux や UNIX、また同様のオペレーティングシステムでは、パーティションやリムーバブルデバイス(CD、 DVD、 USB フラッシュドライブなど) 上にあるファイルシステムをディレクトリーツリー内の特定のポイント (マウントポイント) に接続したり取り外したりすることができます。ファイルシステムの接続や取り外しを行う場合は、mount コマンドと umount コマンドをそれぞれ使用します。本章では、これらのコマンドの基本的な使い方や、マウントポイントの移動や共有サブツリーの作成などの高度なテクニックについてもいくつか扱います。

19.1. 現在マウントされているファイルシステムの一覧表示

現在接続している全ファイルシステムを表示させる場合は、引数を指定せずに以下のコマンドを使用します。

$ mount

上記のコマンドで既知のマウントポイントの一覧が表示されます。行ごとにデバイス名、ファイルシステムのタイプ、マウントしているディレクトリー、およびマウントオプションなどの情報が以下のような形で表示されます。

device on directory type type (options)

Red Hat Enterprise Linux 6.1 からは findmnt ユーティリティーも使用できるようになりました。このユーティリティーを使うとマウントしているファイルシステムをツリー形式で表示させることができます。現在接続している全ファイルシステムを表示させるには、findmnt コマンドを実行します。いずれの引数も付けません。

$ findmnt

19.1.1. ファイルシステムタイプの指定

mount コマンドの出力には、デフォルトで sysfs や tmpfs など各種の仮想ファイルシステムが含まれます。特定のファイルシステムタイプのデバイスのみを表示するには、-t オプションを指定します。

$ mount -t type

findmnt コマンドを使用して、特定のファイルシステムのデバイスを表示させる場合も同様です。

$ findmnt -t type

一般的なファイルシステムタイプの一覧については表19.1「一般的なファイルシステムのタイプ」をご覧ください。使用例については例19.1「現在マウントされている ext4 ファイルシステムの一覧表示」を参照してください。

例例19.1 現在マウントされている現在マウントされている ext4 ファイルシステムの一覧表示ファイルシステムの一覧表示

通常、/ パーティションと /boot パーティションはいずれも ext4 を使用するようフォーマットされます。このファイルシステムを使用しているマウントポイントだけを表示する場合は、以下のコマンドを使用します。


170

$ mount -t ext4/dev/sda2 on / type ext4 (rw)/dev/sda1 on /boot type ext4 (rw)

findmnt コマンド使用してマウントポイントを一覧表示するには、以下を入力します。

$ findmnt -t ext4TARGET SOURCE FSTYPE OPTIONS/ /dev/sda2 ext4 rw,realtime,seclabel,barrier=1,data=ordered/boot /dev/sda1 ext4 rw,realtime,seclabel,barrier=1,data=ordered

19.2. ファイルシステムのマウント

特定のファイルシステムを接続するには、以下のような形式で mount コマンドを使用します。

$ mount [option…] device directory

device は、以下で識別できます。

block device へのフルパス: 例 /dev/sda3

幅広く一意の識別子 (UUID): - 例 UUID=34795a28-ca6d-4fd8-a347-73671d0c19cb

ボリュームラベル: - 例 LABEL=home

ファイルシステムがマウントされると、directory の元のコンテンツにアクセスできなくなります。

重要重要

Linux では、すでにファイルシステムが接続されているディレクトリーに対してファイルシステムをマウントする動作が阻止されることはありません。特定のディレクトリーがマウントポイントとして使用されているかどうかを確認するには、そのディレクトリーを引数として findmntユーティリティーを実行し、終了コードを確認します。

ディレクトリーにいずれのファイルシステムも接続されていない場合は 1 を返します。

デバイス名、目的のディレクトリー、またはファイルシステムタイプなど、必要な情報をすべて指定せずに mount コマンド実行すると、mount コマンドは /etc/fstab ファイルの内容を読み取り、指定のファイルシステムが記載されているか確認します。/etc/fstab ファイルには、選択したファイルシステムがマウントされるデバイス名およびディレクトリーのリスト、ファイルシステムタイプ、およびマウントオプションが含まれます。そのため、/etc/fstab で指定されたファイルシステムをマウントするときに、以下のオプションの 1 つを選択できます。

root でコマンドを実行しない限り、ファイルシステムのマウントには権限が必要であることに注意してください (「マウントオプションの指定」を参照)。

注記注記

findmnt directory; echo $?

mount [option…] directorymount [option…] device

第第19章章 MOUNT コマンドの使い方コマンドの使い方

171

注記注記

特定のデバイスの UUID やラベル (デバイスがラベルを使用している場合) を確認するには、次のようにして blkid コマンドを使用します。

たとえば、/dev/sda3 の情報を表示:

# blkid /dev/sda3/dev/sda3: LABEL="home" UUID="34795a28-ca6d-4fd8-a347-73671d0c19cb" TYPE="ext3"

19.2.1. ファイルシステムタイプの指定

ほとんどの場合、mount によって自動的にファイルシステムが検出されます。ただし、NFS (NetworkFile System) や CIFS (Common Internet File System) などの認識できないファイルシステムがあるため、こうしたファイルシステムの場合は手作業で指定しなければなりません。ファイルシステムのタイプを指定するには次のように mount コマンドを使用します。

$ mount -t type device directory

表19.1「一般的なファイルシステムのタイプ」は、mount コマンドで使用できる一般的なファイルシステムのタイプの一覧を表示します。利用可能なファイルシステムのタイプの詳細は「man ページ」を参照してください。

表表19.1 一般的なファイルシステムのタイプ一般的なファイルシステムのタイプ

タイプタイプ説明説明

ext2 ext2 ファイルシステム



btrfs btrfs ファイルシステム

xfs xfs ファイルシステム

iso9660 ISO 9660 ファイルシステム、通常は CD などの光学メディアで使用されます。

jfs JFS ファイルシステムは IBM によって開発されました。

nfs NFS ファイルシステム、ネットワーク経由でファイルにアクセスする場合に一般的に使用されます。

nfs4 NFSv4 ファイルシステム、ネットワーク経由でファイルにアクセスする場合に一般的に使用されます。

blkid device


172

ntfs NTFS ファイルシステム、 Windows オペレーティングシステムを稼動しているマシンで一般的に使用されます。

udf UDF ファイルシステム、DVD などの光学メディアで一般的に使用されます。

vfat FAT ファイルシステム、Windows オペレーティングシステムを稼動しているマシンや特定のデジタルメディア (USB フラッシュドライブ、フロッピーディスクなど) 上で一般的に使用されます。

タイプタイプ説明説明

使用例については例19.2「USB フラッシュドライブのマウント」を参照してください。

例例19.2 USB フラッシュドライブのマウントフラッシュドライブのマウント

旧式の USB フラッシュドライブは FAT ファイルシステムを使用していることがよくあります。このようなドライブが /dev/sdc1 デバイスを使用しているとします。また /media/flashdisk/ というディレクトリーが存在すると仮定します。このデバイスを /media/flashdisk/ ディレクトリーにマウントするには、 root で次のようにシェルプロンプトに入力します。

19.2.2. マウントオプションの指定

マウントの追加オプションを指定する場合は、次のような形式のコマンドを使用します。

複数のオプションを使う場合は、コンマの後に空白を入れないようにしてください。空白を入れてしまうと、mount は空白の後の値を追加のパラメーターとして解釈してしまいます。

一般的なマウントオプションの一覧を表19.2「一般的なマウントオプション」に示します。使用できる全オプションの一覧については「man ページ」セクションに記載している該当の man ページをご覧ください。

表表19.2 一般的なマウントオプション一般的なマウントオプション


async ファイルシステム上での非同期の入/出力を許可します。

auto mount -a コマンドを使ったファイルシステムの自動マウントを許可します。

defaults async,auto,dev,exec,nouser,rw,suid のエイリアスを指定します。

exec 特定のファイルシステムでのバイナリーファイルの実行を許可します。

loop イメージをループデバイスとしてマウントします。

~]# mount -t vfat /dev/sdc1 /media/flashdisk

mount -o options device directory


173

noauto mount -a コマンドを使ったファイルシステムの自動マウントをデフォルトの動作として拒否します。

noexec 特定のファイルシステムでのバイナリーファイルの実行を拒否します。

nouser 普通のユーザー (つまり root 以外のユーザー) によるファイルシステムのマウントおよびアンマウントを拒否します。

remount ファイルシステムがすでにマウントされている場合は再度マウントを行います。

ro 読み取り専用でファイルシステムをマウントします。

rw ファイルシステムを読み取りと書き込み両方でマウントします。

user 普通のユーザー (つまり root 以外のユーザー) によるファイルシステムのマウントおよびアンマウントを許可します。


使用例については例19.3「ISO イメージのマウント」を参照してください。

例例19.3 ISO イメージのマウントイメージのマウント

ISO イメージ (または一般的にはディスクイメージ) はループデバイスを使用することでマウントすることができます。Fedora 14 インストールディスクの ISO イメージが現在の作業ディレクトリーにあると仮定します。また、/media/cdrom/ と言うディレクトリーが存在するとします。このイメージを /media/cdrom/ ディレクトリーにマウントするには次のコマンドを実行します。

# mount -o ro,loop Fedora-14-x86_64-Live-Desktop.iso /media/cdrom

ISO9660 は設計上、読み取り専用のファイルシステムになっていることに注意してください。

19.2.3. マウントポイントの共有

システム管理作業の中には、同じファイルシステムにディレクトリーツリー内の複数の場所からのアクセスする必要がある場合があります (chroot 環境を準備する場合など)。Linux では同じファイルシステムを複数のディレクトリーに必要なだけマウントすることが可能です。また、mount コマンドは重複したマウントポイントを持たせることができる --bind オプションを実装します。以下のように使用します。

$ mount --bind old_directory new_directory

上記のコマンドにより、ユーザーはいずれの場所からでもファイルシステムにアクセスできるようになりますが、これは元のディレクトリー内にマウントされているファイルシステムには適用されません。これらのマウントも含めるには、以下のコマンドを実行します。

$ mount --rbind old_directory new_directory

さらに Red Hat Enterprise Linux 7 では、可能な限り柔軟性を持たせるために、共有サブツリーと呼ば


174

さらに Red Hat Enterprise Linux 7 では、可能な限り柔軟性を持たせるために、共有サブツリーと呼ばれる機能を実装しています。次の 4 種類のマウントを使用することができます。

共有マウント共有マウント

共有マウントにより、任意のマウントポイントと全く同一の複製マウントポイントを作成することができます。マウントポイントを共有マウントしてマークすると、元のマウントポイント内のあらゆるマウントが反映されます。マウントポイントのタイプを共有マウントに変更するには、シェルプロンプトで以下を入力します。

$ mount --make-shared mount_point

代わりに、選択したマウントポイントとその下にあるすべてのマウントポイントのマウントタイプを変更するには:

$ mount --make-rshared mount_point

使用例については、例19.4「共有マウントポイントの作成」を参照してください。

例例19.4 共有マウントポイントの作成共有マウントポイントの作成

他のファイルシステムがマウントされる一般的な場所が 2 箇所あります。リムーバルメディア用の /media/ ディレクトリーと一時的にファイルシステムをマウントする場合の /mnt/ 所です。共有マウントを使用することで、これら 2 種類のディレクトリーが同じコンテンツを共有できるようになります。これを実行するには、root になり、/media/ ディレクトリーを shared としてマークします。

# mount --bind /media /media# mount --make-shared /media

以下のコマンドを使用して、複製を /mnt ディレクトリーに作成します。

# mount --bind /media /mnt

これで /media 内のマウントが /mnt/ 内にも表示されることが確認できます。たとえば、CD-ROM ドライブに何らかのコンテンツを持つメディアがあり、/media/cdrom/ ディレクトリーが存在する場合は次のコマンドを実行します。

# mount /dev/cdrom /media/cdrom# ls /media/cdromEFI GPL isolinux LiveOS# ls /mnt/cdromEFI GPL isolinux LiveOS

同様に、/mnt/ ディレクトリー内にマウントしているファイルシステムが /media/ 内に反映されていることを確認できます。たとえば、/mnt/flashdisk/ というディレクトリーが存在し、また何らかのコンテンツを持つ USB フラッシュドライブが /dev/sdc1 デバイスを使用するとした場合、この USB をプラグインしてから次を入力します。

# # mount /dev/sdc1 /mnt/flashdisk# ls /media/flashdisken-US publican.cfg# ls /mnt/flashdisken-US publican.cfg


175

スレーブマウントスレーブマウント

スレーブマウントにより、所定のマウントポイントの複製を作成する際に制限を課すことができます。マウントポイントをスレーブマウントとしてマークすると、元のマウントポイント内のすべてのマウントがそれに反映されますが、スレーブマウント内のマウントはオリジナルには反映されません。マウントポイントのタイプをスレーブマウントに変更するには、シェルプロンプトで次を入力します。

選択したマウントポイントとその下にあるすべてのマウントポイントのマウントタイプを変更することも可能です。次のように入力します。

使用例については例19.5「スレーブマウントポイントの作成」を参照してください。

例例19.5 スレーブマウントポイントの作成スレーブマウントポイントの作成

/media/ ディレクトリーの内容が /mnt/ ディレクトリーでも表示されるようにしながら、/mnt/ディレクトリー内のマウントは /media/ ディレクトリーには反映させない方法を以下に示します。root になり、まず /media/ ディレクトリーに shared のマークを付けます。

次に /media ディレクトリーの複製を /mnt/ ディレクトリーに作成して、今度は「slave」のマークを付けます。

/media 内のマウントが /mnt/ でも表示されるかを確認します。たとえば、CD-ROM ドライブに何らかの内容を持つメディアがあり、/media/cdrom/ というディレクトリーが存在するとします。次のコマンドを実行します。

~]# mount /dev/cdrom /media/cdrom~]# ls /media/cdromEFI GPL isolinux LiveOS~]# ls /mnt/cdromEFI GPL isolinux LiveOS

また、/mnt/ ディレクトリー内にマウントされているファイルシステムが /media/ に反映されていることを確認します。たとえば、/dev/sdc1 デバイスを使用する何らかのコンテンツを含むUSB フラッシュドライブをプラグインしており、かつ /mnt/flashdisk/ ディレクトリーが存在している場合に以下を入力します。

~]# mount /dev/sdc1 /mnt/flashdisk~]# ls /media/flashdisk~]# ls /mnt/flashdisken-US publican.cfg

mount --make-slave mount_point

mount --make-rslave mount_point

~]# mount --bind /media /media~]# mount --make-shared /media

~]# mount --bind /media /mnt~]# mount --make-slave /mnt


176

プライベートマウントプライベートマウント

プライベートマウントはマウントのデフォルトタイプであり、共有マウントやスレーブマウントと異なり、伝播イベントの受信や転送は一切行いません。マウントポイントを明示的にプライベートマウントにするには、シェルプロンプトで以下を入力します。

または、選択したマウントポイントとその下にあるすべてのマウントポイントを変更することもできます。

使用例については例19.6「プライベートマウントポイントの作成」を参照してください。

例例19.6 プライベートマウントポイントの作成プライベートマウントポイントの作成

例19.4「共有マウントポイントの作成」の状況を考慮に入れ、共有マウントポイントが次のコマンドを使って root で以前に作成されていると仮定します。

/mnt/ ディレクトリーに private のマークを付けるには、次のように入力します。

これで /media/ 内のマウントはいずれも /mnt/ 内では表示されないことを確認できるようになります。たとえば、CD-ROM デバイスに何らかのコンテンツを含むメディアがあり、/media/cdrom/ ディレクトリーが存在する場合に、次のコマンドを実行します。

~]# mount /dev/cdrom /media/cdrom~]# ls /media/cdromEFI GPL isolinux LiveOS~]# ls /mnt/cdrom~]#

また、/mnt/ ディレクトリー内にマウントしているファイルシステムは /media/ ディレクトリーには反映されないことを確認することもできます。たとえば、/dev/sdc1 デバイスを使用し、何らかのコンテンツを含む USB フラッシュドライブをプラグインして、/mnt/flashdisk/ ディレクトリーが存在する場合に以下を入力します。

~]# mount /dev/sdc1 /mnt/flashdisk~]# ls /media/flashdisk~]# ls /mnt/flashdisken-US publican.cfg

バインド不可能なマウントバインド不可能なマウント

任意のマウントポイントに対して一切複製が行われないようにするには、バインド不能のマウントを使用します。マウントポイントのタイプをバインド不能のマウントに変更するには、次のようにシェルプロンプトに入力します。

mount --make-private mount_point

mount --make-rprivate mount_point

~]# mount --bind /media /media~]# mount --make-shared /media~]# mount --bind /media /mnt

~]# mount --make-private /mnt


177

または、選択したマウントポイントとその下にあるすべてのマウントポイントを変更することもできます。

使用例については例19.7「バインド不可能なマウントポイントの作成」を参照してください。

例例19.7 バインド不可能なマウントポイントの作成バインド不可能なマウントポイントの作成

/media/ ディレクトリーが共有されないようにする場合は、root として、以下を実行します。

# mount --bind /media /media# mount --make-unbindable /media

これにより、これ以降にこのマウントの複製を作成しようとするとエラーが出て失敗します。

# mount --bind /media /mntmount: wrong fs type, bad option, bad superblock on /media,missing codepage or helper program, or other errorIn some cases useful info is found in syslog - trydmesg | tail or so

19.2.4. マウントポイントの移動

ファイルシステムがマウントされているディレクトリーを変更するには、次のコマンドを使用します。

# mount --move old_directory new_directory

使用例については例19.8「既存の NFS マウントポイントの移動」を参照してください。

例例19.8 既存の既存の NFS マウントポイントの移動マウントポイントの移動

NFS ストレージにはユーザーのディレクトリーが含まれ、すでに /mnt/userdirs/ にマウントされています。root として、次のコマンドを使用してこのマウントポイントを /home に移動します。

# mount --move /mnt/userdirs /home

マウントポイントが正しく移動したことを確認するため、両方のディレクトリーのコンテンツを表示させます。

# ls /mnt/userdirs# ls /homejill joe

19.2.5. ルートルートへの読み取り専用パーミッションの設定

場合によっては、ルートファイルシステムを読み取り専用パーミッションでマウントする必要があるこ

mount --make-unbindable mount_point

mount --make-runbindable mount_point


178

場合によっては、ルートファイルシステムを読み取り専用パーミッションでマウントする必要があることがあります。ユースケースの例には、システムの予期せぬ電源切断後に行うセキュリティーの向上またはデータ整合性の保持が含まれます。

19.2.5.1. 起動時に読み取り専用パーミッションでマウントするよう起動時に読み取り専用パーミッションでマウントするようルートルートを設定を設定

1. /etc/sysconfig/readonly-root ファイルで READONLY を yes に変更します。

# Set to 'yes' to mount the file systems as read-only.READONLY=yes[出力は省略されています]

2. /etc/fstab ファイルでルートエントリー (/) の defaults を ro に変更します。

/dev/mapper/luks-c376919e... / ext4 ro,x-systemd.device-timeout=0 1 1

3. ro を /etc/default/grub ファイルの GRUB_CMDLINE_LINUX ディレクティブに追加し、rw が含まれないようにします。

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ro"

4. GRUB2 設定ファイルを再作成します。

# grub2-mkconfig -o /boot/grub2/grub.cfg

5. tmpfs ファイルシステムで書き込みパーミッションでマウントされるファイルおよびディレクトリーを追加する必要がある場合は、/etc/rwtab.d/ ディレクトリーでテキストファイルを作成し、そのファイルに設定を追加します。たとえば、/etc/example/file を書き込みパーミッションでマウントするには、以下の行を /etc/rwtab.d/example ファイルに追加します。

files /etc/example/file

重要重要

tmpfs のファイルおよびディレクトリーの変更内容は、再起動後に永続されません。

この手順の詳細は、「書き込みパーミッションを保持するファイルおよびディレクトリー」を参照してください。

6. システムを再起動します。

19.2.5.2. ルートルートを即時に再マウントを即時に再マウント

システムの起動時にルート (/) が読み取り専用パーミッションでマウントされた場合、書き込みパーミッションで再マウントできます。

# mount -o remount,rw /

これは、誤って / が読み取り専用パーミッションでマウントされた場合に便利です。


179

/ を読み取り専用パーミッションで再マウントする場合は、以下を実行します。

# mount -o remount,ro /

注記注記

このコマンドは、/ 全体全体を読み取り専用パーミッションでマウントします。「起動時に読み取り専用パーミッションでマウントするようルートルートを設定」に説明があるように、RAM にコピーして特定ファイルおよびディレクトリーの書き込みパーミッションを保持する方がよいでしょう。

19.2.5.3. 書き込みパーミッションを保持するファイルおよびディレクトリー書き込みパーミッションを保持するファイルおよびディレクトリー

システムが適切に機能するためには、一部のファイルやディレクトリーに書き込みパーミッションが必要になります。ルートが読み取り専用モードである場合、これらのファイルやディレクトリーは tmpfs一時ファイルシステムの RAM にマウントされます。このようなファイルおよびディレクトリーのデフォルトのセットは、以下が含まれる /etc/rwtab ファイルから読み取りされます。

dirs /var/cache/mandirs /var/gdm[出力は省略されています]empty /tmpempty /var/cache/foomatic[出力は省略されています]files /etc/adjtimefiles /etc/ntp.conf[出力は省略されています]

/etc/rwtab ファイルのエントリーは以下の形式にしたがいます。

ファイルまたはディレクトリーがファイルまたはディレクトリーが tmpfs にコピーされる方法にコピーされる方法ファイルまたはディレクトリーへファイルまたはディレクトリーへのパスのパス

ファイルまたはディレクトリーは、以下の 3 つの方法で tmpfs にコピーできます。

empty path: 空のパスが tmpfs にコピーされます。例: empty /tmp

dirs path: ディレクトリーツリーは空の状態で tmpfs にコピーされます。例: dirs /var/run

files path: ファイルまたはディレクトリーツリーはそのまま tmpfs にコピーされます。例: files /etc/resolv.conf

カスタムパスを /etc/rwtab.d/ に追加する場合も同じ形式が適用されます。

19.3. ファイルシステムのアンマウント

以前にマウントしていたファイルシステムを切り離す場合、以下のいずれかの umount コマンドを使用します。

$ umount directory$ umount device

ファイルシステムのアンマウントを root でログインしている間に行わない場合は、アンマウントに適切な権限が必要です。詳細は、「マウントオプションの指定」を参照してください。使用例は例19.9「CD のアンマウント」を参照してください。

重要重要


180

重要重要

ファイルシステムを使用中に (このファイルシステム上でプロセスが読み取りを行っている場合や、カーネルによって使用中の場合など)、umount コマンドを実行するとエラーを出して失敗します。次のように fuser コマンドを使ってファイルシステムにアクセスしているプロセスを判別します。

$ fuser -m directory

/media/cdrom/ ディレクトリーにマウントしているファイルシステムにアクセスしているプロセスを表示させる場合は、以下を実行します。

$ fuser -m /media/cdrom/media/cdrom: 1793 2013 2022 2435 10532c 10672c

例例19.9 CD のアンマウントのアンマウント

/media/cdrom/ ディレクトリーに以前にマウントしていた CD のマウントを解除する場合は、以下を実行します。

$ umount /media/cdrom

19.4. MOUNT コマンドのリファレンス

コマンドなどの詳細については、以下のドキュメントをご覧ください。

man ページ

man 8 mount: mount コマンドの man ページです。使い方などに関する詳細が記載されています。

man 8 umount: umount コマンドの man ページです。使い方などに関する詳細が記載されています。

man 8 findmnt: findmnt コマンドの man ページです。使い方などに関する詳細が記載されています。

man 5 fstab: /etc/fstab ファイル形式に関する詳細が記載されている man ページです。

役立つ Web サイト

『Shared subtrees』 — 共有サブツリーの概念について解説されている LWN の記事です。


181

http://lwn.net/Articles/159077/

第20章 VOLUME_KEY 機能

volume_key 機能では libvolume_key と volume_key の 2 種類のツールを提供しています。libvolume_key はストレージボリュームの暗号キーを操作したりボリュームとは別に格納したりするためのライブラリーになります。 volume_key は暗号化されたハードドライブへのアクセスを取り戻すためにキーとパスフレーズを抽出する関連コマンドラインツールになります。

第一ユーザーがキーやパスワードを忘れてしまった、ユーザーが突然退職してしまった、ハードウェアまたはソフトウェアの障害で暗号化していたボリュームのヘッダーが破損したためデータを抽出する必要がある、などといった場合にこの機能は便利です。企業などの場合、エンドユーザーにコンピュータを手渡す前に IT ヘルプデスクによって volume_key を使用した暗号キーのバックアップをとっておくことが可能です。

現在、volume_key で対応しているのは LUKS ボリュームの暗号形式のみです。

注記注記

volume_key は Red Hat Enterprise Linux 7 サーバーの標準インストールには含まれません。volume_key のインストールについては、http://fedoraproject.org/wiki/Disk_encryption_key_escrow_use_casesを参照してください。

20.1. VOLUME_KEY コマンド

volume_key の形式は次のようになります。

volume_key [OPTION]... OPERAND

volume_key の動作のモードとオペランド (演算対象) は以下のいずれかのオプションを指定して確定します。

--save

このコマンドはオペランド volume [packet] を予期します。packet を指定すると、volume_key はその packet からキーとパスフレーズを抽出します。packet を指定しない場合は、volume_key がvolume からキーとパフフレーズを抽出します。必要に応じてユーザー入力を求めます。キーとパスフレーズは 1 つまたは複数の出力パケットに格納されます。

--restore

このコマンドはオペランド volume packet を予期します。volume を開き、packet 内にあるキーとパスフレーズを使って volume に再びアクセスできるようにします。新しいパスフレーズの入力など、必要に応じてユーザー入力を求めます。

--setup-volume

このコマンドはオペランド volume packet name を予期します。volume を開き、packet 内のキーとパスフレーズを使って volume を name という名前に設定して解読したデータ用に使用できるようにします。

Name は dm-crypt ボリュームの名前です。この操作により解読したボリュームは /dev/mapper/name として使用できるようになります。

新しいパスフレーズを追加するなど、このコマンドでの操作は volume を永続的に変更することはありません。ユーザーは解読されたボリュームにアクセスして変更を行うことができ、処理中にvolume を変更することができます。


182

http://fedoraproject.org/wiki/Disk_encryption_key_escrow_use_cases

--reencrypt、、 --secrets、、 --dump

この 3 種類のコマンドは同じような機能ですが出力方法が異なります。それぞれにオペランドpacket が必要です。各コマンドは packet を開いて必要に応じて解読します。--reencrypt はその情報を 1 つまたは複数の新しい出力パケットに格納します。--secrets は packet に含まれているキーとパスフレーズを出力します。--dump は packet のコンテンツを出力しますが、キーとパスフレーズはデフォルトでは出力しません。これは --with-secrets をコマンドに追加することで変更できます。また、--unencrypted コマンドを使ってパケットの暗号化されていない部分だけをダンプすることも可能です。これには、パスフレーズやプライベートキーは必要ありません。

上記のコマンドのそれぞれには、次のオプションを付けることができます。

-o、、--output packet

このコマンドでデフォルトのキーやパスフレーズを packet に書き込みます。デフォルトのキーまたはパスフレーズはボリューム形式によって異なります。期限切れにならないようものを選択してください。また、--restore を使ってボリュームへのアクセスを取り戻すことができることを確認します。

--output-format format

このコマンドはすべての出力パケットに対して指定した format を使用します。現在使用できるformat は以下のいずれかになります。

asymmetric: CMS を使ってパケット全体を暗号化します。証明書が必要です。

asymmetric_wrap_secret_only: 機密情報またはキーとパスフレーズのみをラップします。証明書が必要です。

passphrase: GPG を使ってパケット全体を暗号化します。パスフレーズが必要です。

--create-random-passphrase packet

英数字のランダムなパスフレーズを生成して volume に追加 (他のパスフレーズには影響しません)した後に、このパスフレーズを packet に格納します。

20.2. VOLUME_KEY の個人ユーザーとしての使用

volume_key を個人ユーザーとして使用すると、以下の手順に従って暗号キーを保存することができます。

注記注記

このファイル内の全サンプルで /path/to/volume は LUKS デバイスになり、その中に含まれるプレーンテキストデバイスにはなりません。blkid -s type /path/to/volume を使用すると type="crypto_LUKS" が表示されるはずです。

手順手順20.1 volume_key のスタンドアロンとしての使用のスタンドアロンとしての使用

1. 次を実行します。

volume_key --save /path/to/volume -o escrow-packet

キーを保護するためのエスクローパケットのパスフレーズの入力を求めるプロンプトが表示されます。

第第20章章 VOLUME_KEY 機能機能

183

2. 生成された escrow-packet ファイルを保存し、パスフレーズを忘れないようにしてください。

ボリュームのパスフレーズを忘れてしまった場合は、保存したエスクローパケットを使ってデータへのアクセスを復元します。

手順手順20.2 エスクローパケットを用いたデータアクセスの復元エスクローパケットを用いたデータアクセスの復元

1. volume_key を実行することができ、エスクローパケットが使用できる環境でシステムを起動します (レスキューモードなど)。


volume_key --restore /path/to/volume escrow-packet

エスクローパケットの作成時に使用したエスクローパケットのパスフレーズの入力を求めるプロンプト、次にボリュームの新しいパスフレーズの入力を求めるプロンプトが表示されます。

3. 選択したパスフレーズを使ってこのボリュームをマウントします。

暗号化したボリュームの LUKS ヘッダー内にあるパスフレーズスロットを解放するには、忘れてしまった古いパスフレーズを cryptsetup luksKillSlot コマンドを使って削除します。

20.3. 規模の大きな組織での VOLUME_KEY の使用

大規模な組織では、システム管理者の誰もが知っている単一のパスワードを使ってシステムごとに異なるパスワードを管理していくのは非現実的であるばかりでなく、セキュリティー上の危険も伴います。こうした状況に対応するため、volume_key では非対称暗号を使用します。これにより、コンピューター上の暗号化されたデータへのアクセスに必要なパスワードを知り得る人の人数を最小限に抑えることができます。

本セクションでは、暗号キーを保存する前の準備として必要な手順や、暗号キーを保存する方法、ボリュームへのアクセスを取り戻す方法、および緊急時のパスフレーズを設定する方法について説明します。

20.3.1. 暗号キーを保存するための準備

暗号キーを保存する前に、準備しておく必要のあることがいくつかあります。

手順手順20.3 準備準備

1. X509 証明書とプライベートキーのペアを作成します。

2. プライベートキーを他人に漏らしたりしない信頼できるユーザーを指定します。これらのユーザーはエスクローパケットを解読できるようになります。

3. エスクローパケットの解読に使用するシステムを選択します。これらのシステムでプライベートキーを含む NSS データベースのセットアップを行います。

プライベートキーが NSS データベースに作成されていない場合は、次の手順に従います。

証明書とプライベートキーを PKCS#12 ファイルに保存します。

次を実行します。

certutil -d /the/nss/directory -N


184

これで NSS データベースのパスワードを選択できるようになりました。各 NSS データベースには別々のパスワードを持たせることができるため、指定したユーザーがそれぞれ別々の NSS データベースを使用する場合はユーザー間で 1 つのパスワードを共有する必要はありません。

次を実行します。

4. システムをインストールしているユーザーか、または既存のシステムにキーを保存しているユーザー全員に証明書を配信します。

5. 保存したプライベートキー用にマシンおよびボリュームからそのキーの検索が可能なストレージを用意します。たとえば、マシン 1 台に対して 1 つのサブディレクトリーを持つ単純なディレクトリーでも、他のシステム管理タスクにも使用されるデータベースであっても構いません。

20.3.2. 暗号キーの保存

必要な準備が整ったら (「暗号キーを保存するための準備」を参照)、次の手順で暗号キーを保存することができるようになります。

注記注記

このファイル内の全サンプルで /path/to/volume は LUKS デバイスになり、その中に含まれるプレーンテキストデバイスにはなりません。blkid -s type /path/to/volume を使用すると type="crypto_LUKS" が表示されるはずです。

手順手順20.4 暗号キーの保存暗号キーの保存


2. 生成した escrow-packet ファイルを準備したストレージに保存し、システムおよびボリュームに関連付けます。

この手順は手作業で行うこともできますが、システムインストールの一部としてスクリプト化して実行することもできます。

20.3.3. ボリュームへのアクセスの復元

暗号キーの保存 (「暗号キーを保存するための準備」および「暗号キーの保存」を参照) が完了したら、必要に応じてドライバーへのアクセスを取り戻すことができます。

手順手順20.5 ボリュームへのアクセスの復元ボリュームへのアクセスの復元

1. パケットのストレージからそのボリュームのエスクローパケットを取得して、指定ユーザーの 1人が解読できるようにそのエスクローパケットを送信します。

2. 指定ユーザーは次を実行します。

pk12util -d /the/nss/directory -i the-pkcs12-file

volume_key --save /path/to/volume -c /path/to/cert escrow-packet

volume_key --reencrypt -d /the/nss/directory escrow-packet-in -o escrow-packet-out

第第20章章 VOLUME_KEY 機能機能

185

NSS データベースのパスワードを入力した後に、指定ユーザーは暗号化する escrow-packet-out のパスフレーズを選択します。パスフレーズは毎回異なるものになっても構いません。このパスフレーズは、暗号キーが指定ユーザーから目的のシステムに移動する間のみ暗号キーを保護します。

3. 指定ユーザーから escrow-packet-out ファイルとパスフレーズを受け取ります。

4. レスキューモードなど、volume_key の実行が可能で、escrow-packet-out ファイルが利用可能な環境で目的のシステムを起動します。


指定ユーザーによって選択されたパケットのパスフレーズの入力と、ボリューム用の新しいパスフレーズの入力を求めるプロンプトが表示されます。

6. 選択したボリュームパスフレーズでボリュームをマウントします。

忘れてしまった古いパスフレーズは cryptsetup luksKillSlot で削除し、暗号化しているボリュームのLUKS ヘッダー内のパスフレーズスロットを解放することができます。これは、cryptsetup luksKillSlot device key-slot を使って実行します。詳細とサンプルについては、cryptsetup --help でご覧ください。

20.3.4. 緊急時のパスフレーズの設定

状況によって (たとえば、出張中などの場合)、システム管理者が影響を受けたシステムを直接操作できないことがありますが、そのような場合でもユーザーはデータにアクセスしなければならないことがあります。その場合、volume_key をパスフレーズや暗号キーで動作させることができます。

システムのインストール時に次を実行します。

ランダムなパスフレーズが生成され、指定したボリュームに追加されてから passphrase-packet に保存されます。--create-random-passphrase と -o オプションを組み合わせるとパケットを同時に生成することが可能です。

ユーザーがパスワードを忘れてしまった場合、指定ユーザーは次を実行します。

ランダムなパスフレーズを表示します。このパスフレーズをエンドユーザーに渡します。

20.4. VOLUME_KEY のリファレンス

volume_key の詳細は、以下を参照してください。

/usr/share/doc/volume_key-*/README にある readme ファイル

volume_key の man ページ (man volume_key で表示)

オンラインのドキュメント(http://fedoraproject.org/wiki/Disk_encryption_key_escrow_use_cases)

volume_key --restore /path/to/volume escrow-packet-out

volume_key --save /path/to/volume -c /path/to/ert --create-random-passphrase passphrase-packet

volume_key --secrets -d /your/nss/directory passphrase-packet


186

http://fedoraproject.org/wiki/Disk_encryption_key_escrow_use_cases

第21章ソリッドステートディスクの導入ガイドラインソリッドステートディスク (SSD) とは、永続的なデータの格納に NAND フラッシュチップを使用するストレージデバイスを指します。今までのディスクとは大きく異なり、回転する円盤状の磁気記憶媒体にデータを格納します。SSD では、論理ブロックアドレス (LBA) 全体における、データへのアクセス時間は一定になります。一方、回転媒体を使用するこれまでのディスクでは、広範囲のアドレスにまたがるデータにアクセスするため時間がかかります。このように、SSD デバイスの方が待ち時間やスループットに優れています。

使用中のブロック数がディスクの最大容量に近づくにつれ、パフォーマンスが低下してきます。パフォーマンス低下の度合いはデバイスのベンダーごとに大きく異なりますが、いずれのデバイスにもある程度のパフォーマンス低下が見られます。

パフォーマンス低下の問題に対応するため、ホストシステム (Linux カーネルなど) では、特定のブロック範囲が使用されなくなっていることをストレージに知らせる discard 要求を使用できます。SSD はこの情報に基づいて領域を内部で解放し、解放した空きブロックをウェアレベリングに使用することができます。discard 要求が実行できるのは、そのストレージが、ストレージプロトコル (ATA または SCSI)に対応している場合のみです。discard の要求は、ストレージプロトコル固有のネゴシエート済みのdiscard コマンドによって、ストレージに対して発行します (ATA の場合は TRIM コマンド、SCSI の場合は WRITE SAME (UNMAP を設定)、または UNMAP コマンドになります)。

以下の条件を満たす場合は、discard のサポートを有効にすると大変便利です。

ファイルシステムに空き容量がある場合。

基盤のストレージデバイスの論理ブロックが、ほぼ書き込み済みである場合。

TRIM の詳細は、「Data Set Management T13 Specifications」を参照してください。

UNMAP の詳細は、「SCSI Block Commands 3 T10 Specification」のセクション 4.7.3.4 を参照してください。

注記注記

市販のソリッドステートデバイスのすべてが discard に対応しているわけではありません。お使いのソリッドステートデバイスが discard に対応しているかどうかを調べるには、デバイスの内部割り当て単位のサイズである /sys/block/sda/queue/discard_granularity を確認します。

導入に関する考慮事項SSD の内部レイアウトと動作上の理由から、内部 erase block boundary 上でデバイスのパーティション設定を行うことが最適です。Red Hat Enterprise Linux 7 のパーティションユーティリティは、SSD がトポロジー情報をエクスポートする場合に適切なデフォルトを選択します。ただし、デバイスが not トポロジー情報をエクスポートする場合、Red Hat では、最初のパーティションを 1MB 境界で作成することを推奨しています。

SSD には、ベンダーによってさまざまなタイプの TRIM メカニズムがあります。ディスクの初期バージョンは、読み込みコマンドの後にデータの漏洩の可能性を妥協することでパフォーマンスを向上していました。

以下は、TRIM メカニズムのタイプです。

非決定性 TRIM

決定性 TRIM (DRAT)

第第21章章ソリッドステートディスクの導入ガイドラインソリッドステートディスクの導入ガイドライン

187

http://t13.org/Documents/UploadedDocuments/docs2008/e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc

http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r26.pdf

決定性 Read Zero after TRIM (RZAT)

最初の 2 種類の TRIM メカニズムは、TRIM が別のデータまたは同じデータを返すと、read コマンドとして LBA に対してデータ漏洩を引き起こす可能性があります。Red Hat では、データの漏洩を防ぐためにも、この TRIM メカニズムを推奨しています。これは SSD でのみ影響します。RZAT メカニズムに対応しているディスクを選んでください。

使用している TRIM のタイプは、ハードウェイ実装によって異なります。ATA 上で TRIM メカニズムのタイプを調べるには、hdparm コマンドを使用します。TRIM メカニズムのタイプを調べるには、以下の例を参照してください。

# hdparm -I /dev/sda | grep TRIMData Set Management TRIM supported (limit 8 block)Deterministic read data after TRIM

詳細は、man hdparm を参照してください。

LVM が使用する論理ボリュームマネージャー (LVM)、device-mapper (DM) ターゲット、および MD(ソフトウェア RAID) は discard 要求をサポートします。discard 要求に対応しない DM ターゲットはdm-snapshot、dm-crypt、dm-raid45 です。dm-mirror では、Red Hat Enterprise Linux 6.1 で discard要求に対応するようになり、MD は、バージョン 7.0 以降で discard 要求に対応するようになりました。

SSD で RAID レベル 5 を使用する場合は、SSD で discard が適切に処理されないとパフォーマンスが低下します。discard は、raid456.conf ファイルまたは GRUB2 設定にします。手順については、以下を参照してください。

手順手順21.1 raid456.conf にに discard の設定の設定

devices_handle_discard_safely モジュールパラメーターが raid456 モジュールに設定されています。raid456.conf ファイルで discard を有効にするには、以下の手順を行います。

1. ハードウェアが discard をサポートするかどうかを確認するには、以下のコマンドを実行します。

# cat /sys/block/disk-name/queue/discard_zeroes_data

戻り値が 1 の場合は discard が有効です。0 が返った場合は、RAID コードがディスクを取り除く必要があるため、さらに時間がかかります。

2. /etc/modprobe.d/raid456.conf ファイルを作成し、次の行を追加します。

options raid456 devices_handle_discard_safely=Y

3. dracut -f コマンドを実行して、初期 ramdisk (initrd) を再構築します。

4. システムを再起動して、変更を有効にします。

手順手順21.2 GRUB2 設定に設定に discard を設定します。を設定します。

devices_handle_discard_safely モジュールパラメーターは raid456 モジュールに設定されています。GRUB2 設定で discard を有効にするには、以下を行います。

1. ハードウェアが discard をサポートするかどうかを確認するには、以下のコマンドを実行します。


188

# cat /sys/block/disk-name/queue/discard_zeroes_data

戻り値が 1 の場合は discard が有効です。0 が返った場合は、RAID コードがディスクを取り除く必要があるため、さらに時間がかかります。

2. /etc/default/grub ファイルに次の行を追加します。

raid456.devices_handle_discard_safely=Y

3. GRUB2 設定ファイルの場所は、システムが BIOS ファームウェアか UEFI を使っているかで異なります。次のいずれかのコマンドを実行し、GRUB2 設定ファイルを再作成します。

BIOS ファームウェアを使用している場合は、以下のコマンドを使用します。

# grub2-mkconfig -o /boot/grub2/grub.cfg

UEFI ファームウェアを使用している場合は、以下のコマンドを使用します。

# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

4. システムを再起動して、変更を有効にします。

注記注記

Red Hat Enterprise Linux 7 では、ext4 と XFS ファイルシステムのみが discard に完全に対応しています。

Red Hat Enterprise Linux 6.3 以前では、ext4 ファイルシステムだけが discard に完全に対応しています。Red Hat Enterprise Linux 6.4 以降では、ext4 ファイルシステムと XFS ファイルシステムの両方がdiscard を完全にサポートします。デバイスで discard コマンドを有効にするには、mount コマンドの discard オプションを使用します。たとえば、discard を有効にして /dev/sda2 を /mnt にマウントするには、以下のコマンドを実行します。

# mount -t ext4 -o discard /dev/sda2 /mnt

ext4 は、デフォルトでは discard コマンドを発行しません。discard コマンドを正しく実装しないデバイスで問題が発生するのを回避するためです。Linux の swap コードは、discard を有効にしたデバイスに対して discard コマンドを発行するため、この動作を制御するオプションはありません。

パフォーマンスチューニングに関する注意点ソリッドステートディスクでのパフォーマンスチューニングに関する詳細は、『Red HatEnterprise Linux 7 パフォーマンスチューニングガイド』の「ソリッドステートディスク」セクションを参照してください。

第第21章章ソリッドステートディスクの導入ガイドラインソリッドステートディスクの導入ガイドライン

189

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Performance_Tuning_Guide/index.html#sect-Red_Hat_Enterprise_Linux-Performance_Tuning_Guide-Considerations-Solid_State_Disks

第22章書き込みバリア書き込みバリアとはカーネルのメカニズムで、電力供給の停止が揮発性の書き込みキャッシュを持つストレージデバイスに対して発生した場合でもファイルシステムのメタデータは永続的なストレージに正しい順序で書き込まれるようにします。また、書き込みバリアが有効になっているファイルシステムでは、電力供給の停止が発生しても fsync() で転送されるデータの永続性を維持します。

書き込みバリアを有効にすると相当のパフォーマンス低下を招くアプリケーションがあります。特に、fsync() をかなり頻繁に使用するアプリケーションや小さなファイルの作成、削除を繰り返すアプリケーションの場合、実行速度がかなり遅くなる可能性が高くなります。

22.1. 書き込みバリアの重要性

ファイルシステムは、整合性が維持されるようメタデータの安全な更新を行います。ジャーナリングされたファイルシステムによりメタデータの更新がトランザクションにバンドルされて次のように恒久ストレージに送信されます。

1. トランザクションのボディーがストレージデバイスに送信されます。

2. 次に、コミットブロックが送信されます。

3. トランザクションとそのトランザクションのコミットブロックがディスクに書き込まれると、ファイルシステムは、そのトランザクションが電力供給の停止にも耐え得るとみなします。

ただし、キャッシュの容量が大きいストレージデバイスの場合、電力供給が停止している間のファイルシステムの整合性の維持はより複雑になります。ローカルの S-ATA ドライブや SAS ドライブのようなストレージターゲットのデバイスには 32 MB から 64 MB の書き込みキャッシュがある場合があります(最近のドライブ)。ハードウェア RAID コントローラーには内部書き込みキャッシュがあるものがよくあります。さらに、NetApp、IBM、Hitachi、EMC (その他多数) などのハイエンドアレイにも大容量のキャッシュがあります。

書き込みキャッシュのあるストレージデバイスは、データがキャッシュに入った時点で I/O は「complete」(完了) と報告します。キャッシュの電力供給が停止した場合にはデータも失われます。さらに悪いことに、永続的なストレージへのキャッシュのデステージにより、元のメタデータの順序が変わってしまう場合もあります。これが発生すると、関連付けられている完全なトランザクションがないままコミットブロックがディスクに現れる可能性があります。その結果、電力復旧後にジャーナルは初期化されていないトランザクションブロックをファイルシステムに再生する場合があり、これがデータの不整合や破損を招くことになります。

書き込みバリアの動作

Linux カーネルでの書き込みバリアは、I/O の前後にストレージの書き込みキャッシュをフラッシュすることで実施されます。これは順序が非常に重要順序が非常に重要になります。トランザクションが書き込まれた後、ストレージキャッシュがフラッシュされてコミットブロックの書き込みが行われます。その後、再びキャッシュがフラッシュされます。これにより以下が確実に行われることになります。

ディスクにすべてのデータが含める

再度の順序付けは行わない

バリアを有効にすると、fsync() 呼び出しによってストレージキャッシュのフラッシュも実行されます。これにより fsync() が返された直後に電力供給の停止が発生した場合でも、ファイルのデータは必ずディスク上で永続化します。

22.2. 書き込みバリアの有効化と無効化


190

電源供給の停止が発生した場合のデータ破損のリスクを軽減するため、バッテリー駆動の書き込みキャッシュを使用するストレージデバイスがあります。一般的にはハイエンドのアレイや数種のハードウェアコントローラではバッテリー駆動の書き込みキャッシュを使用しています。ただし、キャッシュの揮発性がカーネルには見えないため、Red Hat Enterprise Linux 7 ではデフォルトで、対応している全ジャーナリングファイルシステム上の書き込みバリアを有効にしています。

注記注記

書き込みキャッシュは I/O のパフォーマンス向上を目的として設計されています。ただし、書き込みバリアを有効にするということは、これらのキャッシュを継続的にフラッシュするということであり、これにより大幅なパフォーマンス低下が生じる可能性があります。

揮発性ではないバッテリー駆動の書き込みキャッシュを持つデバイスや、書き込みキャッシュ機能を無効にしているデバイスに対しては、mount に -o nobarrier オプションを使ってマウント時に書き込みバリアを安全に無効にすることができます。ただし、書き込みバリアに対応していないデバイスがあります。こうしたデバイスの場合、エラーメッセージが /var/log/messages に記録されます。詳細は、表22.1「ファイルシステムごとの書き込みバリアエラーメッセージ」を参照してください。

表表22.1 ファイルシステムごとの書き込みバリアエラーメッセージファイルシステムごとの書き込みバリアエラーメッセージ

ファイルシステムファイルシステムエラーメッセージエラーメッセージ

ext3/ext4 JBD: barrier-based sync failed on device - disabling barriers

XFS Filesystem device - Disabling barriers, trial barrier write failed

btrfs btrfs: disabling barriers on dev device

22.3. 書き込みバリアに関する注意点

データ保護に書き込みバリアを必要としないシステム設定があります。こうしたシステム設定ではほとんどの場合、書き込みバリアを有効にすることが大幅なパフォーマンス低下を招く要因となるため、書き込みバリア以外の方法を選択するのが得策と言えます。

書き込みキャッシュの無効化

データ整合性の問題を回避するもう 1 つの方法は、電力供給の停止が発生した場合に書き込みキャッシュによるデータが損失しないようにすることです。可能な場合は、書き込みキャッシュを無効にしてしまうのが最適な方法です。1 つまたは複数の SATA ドライブ (ローカル SATA Controller Intel AHCI 部分と区別) を搭載している簡単なサーバーやデスクトップでは、次のようにして該当の SATA ドライブの書き込みキャッシュを以下のコマンドで無効にすることができます。

# hdparm -W0 /device/

バッテリー駆動の書き込みキャッシュ

バッテリー駆動の書き込みキャッシュを持つハードウェア RAID コントローラーを使用している場合にも書き込みバリアは不要になります。このようなコントローラーを装備したシステムでそのコンポーネ

第第22章章書き込みバリア書き込みバリア

191

ントとなるドライブが搭載している書き込みキャッシュが無効になっている場合、コントローラーがライトスルーキャッシュとして動作します。このため、電力供給停止時でも書き込みキャッシュのデータは維持されることがカーネルで認識されます。

ほとんどの場合、コントローラーは該当ドライブへの問い合わせや操作に製造元固有のツールを使用します。たとえば、LSI Megaraid SAS コントローラーの場合はバッテリー駆動の書き込みキャッシュを使用し、この種のコントローラーには該当ドライブの管理に MegaCli64 ツールが必要になります。LSIMegaraid SAS のすべてのバックエンドドライブの状態を表示する場合は以下のようにします。

# MegaCli64 -LDGetProp -DskCache -LAll -aALL

LSI Megaraid SAS の全バックエンドドライブの書き込みキャッシュを無効にする場合は次のようにします。

# MegaCli64 -LDSetProp -DisDskCache -Lall -aALL

注記注記

ハードウェア RAID カードはシステムの稼働中にバッテリー充電を行います。一定時間以上システムの電源がオフになるとバッテリーの充電がなくなるため、電力供給停止時に保存したデータが不安定になります。

ハイエンドのアレイ

ハイエンドのアレイには、電力供給停止時におけるデータ保護に関してさまざまな方法があるため、外付け RAID ストレージ内の内部ドライブの状態を確認する必要はありません。

NFS

データの整合性は NFS サーバー側で処理されるため、NFS クライアント側では書き込みバリアを有効にする必要はありません。電源供給の停止中、データの永続性が確保されるよう NFS サーバーの設定を行ってください (書き込みバリアまたは別の方法のいずれかによる)。


192

第23章ストレージの I/O 調整とサイズ最近の SCSI および ATA 標準への強化により、ストレージデバイスが推奨の (また、場合によっては必須の) I/O 調整と I/O サイズを示すようになりました。この情報は特に物理的なセクターサイズを 512バイトから 4 キロバイトに増加させている新しいディスクドライブで役に立ちます。また、チャンクサイズやストライプのサイズがパフォーマンスに影響を与える可能性がある RAID デバイスに対しても役に立ちます。

ベンダー提供の I/O 調整と I/O サイズの情報を処理するために Linux I/O スタックが強化され、ストレージ管理ツール (parted、lvm、mkfs.* など) によるデータ配置とアクセスの最適化が可能になります。レガシーデバイスが I/O 調整や I/O サイズなどのデータをエクスポートしない場合、Red HatEnterprise Linux 7 のストレージ管理ツールは安全のため 4k (または 4k より大きい 2 の累乗) の境界でI/O を調整します。これにより、4k セクターのデバイスが必須または推奨の I/O 調整やサイズを表示しない場合であっても正しく動作するようになります。

オペレーティングシステムがデバイスから取得した情報の判別については「ユーザー領域のアクセス」を参照してください。このデータはこの後にデータの配置を確定するためにストレージ管理ツールによって使用されます。

IO スケジューラーは Red Hat Enterprise Linux 7 から変更されました。デフォルトの IO スケジューラーは、SATA ドライブの場合を除き、Deadline です。CFQ は SATA ドライブのデフォルト IO スケジューラーです。高速なストレージの場合、Deadline のパフォーマンスは CFQ を上回り、Deadline の使用時には、特別なチューニングなしにパフォーマンスが強化されます。

一部のディスク (SAS 回転ディスクなど) に適したデフォルトが設定されていない場合は、IO スケジューラーを CFQ に変更してください。これはワークロードによって異なります。

23.1. ストレージアクセス用のパラメーター

オペレーティングシステムは、次の情報を使って I/O の調整とサイズを確定します。

physical_block_size

デバイスが動作できる最小の内部ユニット

logical_block_size

デバイス上の場所指定に外部で使用される

alignment_offset

基礎となる物理的なアライメントのオフセットとなる Linux ブロックデバイス (パーティション/MD/LVM デバイス) の先頭部分のバイト数

minimum_io_size

ランダムな I/O に対して推奨のデバイス最小ユニット

optimal_io_size

ストリーミング I/O に対するデバイスの推奨ユニット

たとえば、特定の 4K セクターのデバイスでは、内部では physical_block_size に 4K を使用しているのに、Linux に対してはより小さい 512 バイトの logical_block_size を公開している場合があります。この違いが I/O の調整ミスを招くことがあります。これに対処するため、ブロックデバイスの先頭が基

第第23章章ストレージのストレージの I/O 調整とサイズ調整とサイズ

193

礎となる物理的なアライメントのオフセットとなる場合、Red Hat Enterprise Linux 7 の I/O スタックは必ず alignment_offset に十分なサイズとなるよう必然的に調整される境界 (physical_block_size) 上ですべてのデータエリアを開始しようとします。

ストレージの製造元では、デバイスのランダムな I/O (minimum_io_size) およびストリーミングの I/O(optimal_io_size) に対して推奨となる最小ユニットに関する I/O hints も提供しています。たとえば、 minimum_io_size と optimal_io_size は RAID デバイスのチャンクサイズとストライプサイズにそれぞれ該当します。

23.2. ユーザー領域のアクセス

常に正しく調整された正しいサイズの入出力を使用するよう注意してください。とくに、ダイレクトな入出力アクセスの場合には重要となります。ダイレクトな入出力は logical_block_size の境界上で、logical_block_size の倍数単位で調整してください。

ネイティブの 4K デバイス (つまり、logical_block_size が 4K という意味) では、アプリケーションがデバイスの logical_block_size の倍数単位でダイレクトな入出力を行うことが重要となってきます。つまり、4k の調整した入出力ではなく 512 バイトの調整した入出力を行うネイティブな 4k デバイスではアプリケーションの実行は失敗することになります。

これを回避するには、正しい入出力調整とサイズを使用していることを確認するためアプリケーションにデバイスの入出力パラメーターの問い合わせを行わせる必要があります。前述のように入出力のパラメーターは sysfs とブロックデバイス ioctl の両方のインターフェースを介して公開されます。

詳細は man libblkid を参照してください。man ページは libblkid-devel パッケージで提供しています。

sysfs インターフェース

/sys/block/disk/alignment_offset

または

/sys/block/disk/partition/alignment_offset

注記注記

ファイルの場所は、ディスクが物理ディスク (ローカルディスク、ローカルRAID、またはマルチパス LUN) または仮想ディスクであるかによって異なります。最初のファイルの場所は物理ディスクに適用でき、2 つ目のファイルの場所は仮想ディスクに適用できます。これは、virtio-blk は常にパーティションのアライメント値を報告するためです。物理ディスクはアライメント値を報告する場合と報告しない場合があります。

/sys/block/disk/queue/physical_block_size

/sys/block/disk/queue/logical_block_size

/sys/block/disk/queue/minimum_io_size

/sys/block/disk/queue/optimal_io_size

カーネルは、入出力のパラメーター情報を提供しないレガシーなデバイス用にこれらの sysfs 属性をエクスポートします。たとえば、以下のようになります。


194

例例23.1 sysfs インターフェースインターフェース

alignment_offset: 0physical_block_size: 512logical_block_size: 512minimum_io_size: 512optimal_io_size: 0

ブロックデバイス ioctls

BLKALIGNOFF: alignment_offset

BLKPBSZGET: physical_block_size

BLKSSZGET: logical_block_size

BLKIOMIN: minimum_io_size

BLKIOOPT: optimal_io_size

23.3. I/O 規格

本セクションでは ATA デバイスおよび SCSI デバイスによって使用される入出力の標準について説明します。

ATA

ATA デバイスは IDENTIFY DEVICE コマンドで適切な情報を報告する必要があります。ATA デバイスが報告する入出力パラメーターは、physical_block_size、logical_block_size、' alignment_offset のみになります。その他の I/O hints は ATA コマンドセットの範囲外となります。

SCSI

Red Hat Enterprise Linux 7 の I/O パラメーターのサポートでは、少なくとも SCSI プライマリーコマンドプロトコルのバージョンバージョン 3 (SPC-3) が必要になります。カーネルが SPC-3 の準拠を求めるデバイスに対して送信するのは、拡張した問い合わせ (BLOCK LIMITS VPD ページへのアクセスを取得するため) と READ CAPACITY(16) コマンドのみになります。

READ CAPACITY(16) コマンドでブロックサイズと調整オフセットを与えます。

LOGICAL BLOCK LENGTH IN BYTES は、 /sys/block/disk/queue/physical_block_size の取得に使用します

LOGICAL BLOCKS PER PHYSICAL BLOCK EXPONENT は、 /sys/block/disk/queue/logical_block_size の取得に使用します

LOWEST ALIGNED LOGICAL BLOCK ADDRESS は、以下の取得に使用します

/sys/block/disk/alignment_offset

/sys/block/disk/partition/alignment_offset

I/O hints は BLOCK LIMITS VPD ページ (0xb0) にあります。また、このページは以下を取得するため


195

I/O hints は BLOCK LIMITS VPD ページ (0xb0) にあります。また、このページは以下を取得するため OPTIMAL TRANSFER LENGTH GRANULARITY や OPTIMAL TRANSFER LENGTH も使用します。

/sys/block/disk/queue/minimum_io_size

/sys/block/disk/queue/optimal_io_size

sg3_utils パッケージで sg_inq ユーティリティーを与えます。このユーティリティーを使って BLOCK LIMITS VPD ページにアクセスします。次を実行します。

# sg_inq -p 0xb0 disk

23.4. 入出力パラメーターのスタック

Linux 入出力スタックの層はすべて各種の入出力パラメーターがスタックまで伝播するよう設計されています。任意の層が属性を消費したり多くのデバイスを集約する場合、その層は適切な入出力パラメーターを公開しなければなりません。これにより上位の層のデバイスまたはツールは変換後のストレージを正確に認識することができるようになります。例をいくつか示します。

ゼロ以外の alignment_offset の調整は入出力スタック内の 1 つの層に限ってください。この層によって調整が完了すると alignment_offset がゼロのデバイスがエクスポートされます。

LVM で作成したストライプ化した Device Mapper (DM) によって、そのストライプ数 (ディスク数) とユーザー入力のチャンクサイズに応じた minimum_io_size と optimal_io_size がエクスポートされなければなりません。

Red Hat Enterprise Linux 7 では、Device Mapper と Software Raid (MD) デバイスのドライバーを使用することで異なる入出力パラメーターを持つデバイスの自由な組み合わせを実現しています。カーネルのブロック層によって各デバイスの入出力パラメーターを合理的に組み合わせるよう試行されます。カーネル自体は異種のデバイスの組み合わせを避けることはありませんが、異種のデバイスの組み合わせによって生じるリスクについては注意が必要になります。

たとえば、512 バイトのデバイスと 4K のデバイスを一つの論理的な DM デバイスに組み合わせ、logical_block_size を 4K にすることができます。このようなハイブリッドデバイス上で層を構成するファイルシステムは 4K がアトミックに書き込みされるとみなしますが、実際には 512 バイトのデバイスの場合には 8 つの論理ブロックアドレスに広がることになります。4K の logical_block_size を上位レベルの DM デバイスに使用すると、システムのクラッシュが発生した場合に 512 バイトのデバイスには不完全な書き込みが起こる可能性が高くなります。

複数のデバイスの入出力パラメーターを組み合わせると競合が起きる場合には、デバイスには不完全な書き込みの可能性があり、誤調整されていることを示す警告がブロック層によって発行される場合があります。

23.5. 論理ボリュームマネージャー

LVM は、カーネルの DM デバイス管理に使用するユーザー領域ツールを提供します。LVM は LVM 管理のデバイスに関連付けられているゼロ以外の alignment_offset に十分なサイズを確保するためデータエリア (任意の DM デバイスによって使用される) の開始点をずらします。つまり、論理ボリュームが正しく調整されることになります (alignment_offset=0)。

デフォルトでは LVM はいずれの alignment_offset の調整も行いますが、/etc/lvm/lvm.conf 内の data_alignment_offset_detection を 0 に設定することでこの動作を無効にすることができます。この動作の無効化はお勧めしません。

また、 LVM はデバイスの I/O hints も検出します。デバイスのデータエリアの開始は sysfs で公開され


196

また、 LVM はデバイスの I/O hints も検出します。デバイスのデータエリアの開始は sysfs で公開される minimum_io_size や optimal_io_size の倍数になります。 optimal_io_size が定義されていない場合は (つまり 0 になっている場合)、 minimum_io_size が使用されます。

デフォルトではこのような I/O hints は LVM によって自動的に確定されますが、 /etc/lvm/lvm.conf 内の data_alignment_detection を 0 に設定することでこの動作を無効にすることができます。この動作の無効化はお勧めしません。

23.6. パーティションとファイルシステムのツール

本セクションでは、さまざまなパーティションツールやファイルシステム管理ツールがどのようにしてデバイスの入出力パラメータと相互作用するのかについて説明しています。

util-linux-ng の libblkid と fdisk

util-linux-ng パッケージに入っている libblkid ライブラリにはデバイスの入出力パラメータへアクセスするためのプログラム的な API が含まれています。 libblkid によってアプリケーション、特にダイレクト入出力を使用するアプリケーションがその入出力要求を正しく区分できるようになります。 util-linux-ng に入っている fdisk ユーティリティーは libblkid を使ってデバイスの入出力パラメータを全パーティションで最適となる配置に定義します。 fdisk ユーティリティーによって 1MB の境界ですべてのパーティション調整が行われます。

parted と libparted

parted の libparted ライブラリも libblkid の入出力パラメータ API を使用します。Anaconda Red HatEnterprise Linux 7 インストーラーでは libparted が使用されます。つまり、インストーラまたは parted のいずれかで作成されるパーティションはすべて正しく調整されることになります。入出力パラメータを提供しないようなデバイスで作成されるパーティションの場合、デフォルトのアライメントは 1MB になります。

経験的法則による parted では次を使用します。

1 番目のプライマリーパーティションの開始のオフセットには常に報告された alignment_offset を使用します。

optimal_io_size を指定すると (つまり 0 以外を指定)、 optimal_io_size の境界にあるパーティションすべての調整を行います。

optimal_io_size を指定しないと (つまり 0)、 alignment_offset は 0 になります。また、 minimum_io_size は 2 の累乗になり 1MB のデフォルトアライメントを使用します。

これが I/O hints を提供しないようなレガシーなデバイスの汎用になります。このようにデフォルトでは全パーティションが 1MB の境界で調整されます。

注記注記

Red Hat Enterprise Linux 7 では、I/O hints を提供するデバイスとしないデバイスとを alignment_offset=0 や optimal_io_size=0 で区別することはできません。この様なデバイスには単一の SAS 4K デバイスなども含まれます。最悪の場合、ディスクの先頭にある 1MB の領域を失うことになります。

ファイルシステムのツール

各種の mkfs.filesystem ユーティリティーも拡張されデバイスの入出力パラメータを使用するようになっています。こうしたユーティリティーでは、基礎となるストレージデバイスの


197

logical_block_size より小さいブロックサイズを使用したファイルシステムのフォーマットは行えません。

mkfs.gfs2 の場合を除き、他の mkfs.filesystem ユーティリティーもすべて I/O hints を使って基礎となるストレージデバイスの minimum_io_size と optimal_io_size に応じたオンディスクデータ構造とデータエリアをレイアウトします。これにより、ファイルシステムを各種の RAID (ストライプ化) レイアウトに応じて最適にフォーマットできるようになります。


198

第24章リモートディスクレスシステムの設定PXE 経由で起動する基本的なディスクレスシステムを設定する場合、次のようなパッケージが必要になります。

tftp-server

xinetd

dhcp

syslinux

dracut-network

注記注記

dracut-network パッケージをインストールした後、以下の行を /etc/dracut.conf に追加します。

add_dracutmodules+="nfs"

リモートディスクレスシステムを起動するには、tftp サービス (tftp-server 提供) と DHCP サービス(dhcp 提供) の両方が必要になります。tftp サービスは、PXE ローダーを使ってネットワーク経由でカーネルのイメージとinitrd を取得する際に使用されます。

注記注記

SELinux は NFSv4.2 上でのみサポートされます。SELinux を使用するには、以下の行を /etc/sysconfig/nfs に追加して NFS を明示的に有効にする必要があります。

RPCNFSDARGS="-V 4.2"

/var/lib/tftpboot/pxelinux.cfg/default で root=nfs:server-ip:/exported/root/directoryを root=nfs:server-ip:/exported/root/directory,vers=4.2 に変更します。

最後に、NFS サーバーを再起動します。

次のセクションでは、ネットワーク環境にリモートディスクレスシステム群を導入する場合に必要な手順について簡単に説明します。

重要重要

一部の RPM パッケージでは、ファイル機能 (setcap や getcap など) の使用が開始されました。しかし、現在 NFS はファイル機能をサポートしないため、ファイル機能を使用するパッケージのインストールや更新に失敗します。

24.1. ディスクレスクライアントの TFTP サービスの設定

前提条件

必要なパッケージをインストールします。24章リモートディスクレスシステムの設定を参照します。

第第24章章リモートディスクレスシステムの設定リモートディスクレスシステムの設定

199

手順tftp を設定するには、以下の手順を実行します。

手順手順24.1 tftp の設定方法の設定方法

1. ネットワーク上での PXE ブートを有効化:

# systemctl enable --now tftp

2. tftp root ディレクトリー (chroot) は /var/lib/tftpboot に置かれます。以下のようにして /usr/share/syslinux/pxelinux.0 を /var/lib/tftpboot/ にコピーします。

# cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/

3. tftp root ディレクトリー内に pxelinux.cfg ディレクトリーを作成します。

# mkdir -p /var/lib/tftpboot/pxelinux.cfg/

4. tftp トラフィックを許可するために、ファイアウォールルールを設定します。

tftp は TCP ラッパーに対応しているため、 /etc/hosts.allow 設定ファイルで、tftp へのホストアクセスを設定できます。TCP ラッパーと /etc/hosts.allow 設定ファイルの設定に関する詳細は、Red Hat Enterprise Linux 7 のセキュリティガイドを参照してください。hosts_access(5)でも、/etc/hosts.allow の情報を参照できます。

次のステップディスクレスクライアントの tftp を設定した後に、DHCP、NFS およびエクスポートしたファイルシステムの設定を行います。DHCP、NFS、エクスポートした「ディスクレスクライアントの DHCP の設定」と「ディスクレスクライアントのエクスポートしたファイルシステムの設定」を参照してください。

24.2. ディスクレスクライアントの DHCP の設定

前提条件


tftp サービスを設定します。「ディスクレスクライアントの tftp サービスの設定」を参照してください。

手順

1. tftpサーバ－を設定した後は、同じホストマシン上で DHCP サービスの設定が必要となります。DHCP サーバーの設定の説明は、「HDCP サーバーの設定」を参照してください。

2. 以下の設定を /etc/dhcp/dhcpd.conf に追加することで、DHCP サーバーで PXE ブートを有効化します。

allow booting;allow bootp;class "pxeclients" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";


200

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/security_guide/index

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/networking_guide/index#sec-dhcp-configuring-server

next-server server-ip; filename "pxelinux.0";}

server-ip には tftp サービスと DHCP サービスがあるホストマシンの IP アドレスを入力します。

注記注記

libvirt 仮想マシンがディスクレスクライアントとして使用されると、libvirt によって DHCP サービスが提供され、スタンドアロン DHCP サーバーは使用されません。このような場合、libvirt ネットワーク設定の virsh net-edit で bootp file='filename' オプションを使用してネットワークブートを有効にする必要があります。

次のステップこれで tftp と DHCP の設定が完了しました。NFS とエクスポートしたファイルシステムを設定します。説明は、「ディスクレスクライアントのエクスポートしたファイルシステムの設定」を参照してください。

24.3. ディスクレスクライアントのエクスポートしたファイルシステムの設定

前提条件


tftp サービスを設定します。「ディスクレスクライアントの tftp サービスの設定」を参照してください。

DHCP を設定します。「ディスクレスクライアントの DHCP の設定」を参照してください。

手順

1. エクスポートしたファイルシステム (ネットワーク内でディスクレスのクライアントが使用) のroot ディレクトリーを NFS 経由で共有します。/etc/exports に root ディレクトリーを追加してディレクトリーをエクスポートするように NFS サービスを設定します。実行方法の詳細については、「/etc/exports 設定ファイル」を参照してください。

2. ディスクレスのクライアントに完全に対応できるようにするには、root ディレクトリーにはRed Hat Enterprise Linux の完全なインストールを組み込む必要があります。既存のインストールをクローン化するか、新しいベースシステムをインストールしてください。

実行中のシステムで同期するには、rsync ユーティリティを使用します。

# rsync -a -e ssh --exclude='/proc/*' --exclude='/sys/*' \ hostname.com:/exported-root-directory

rsync で同期するために実行しているシステムのホスト名に hostname.com を置き換えます。

エクスポートしたファイルシステムへのパスで exported-root-directory を置き換えます。

Red Hat Enterprise Linux を、エクスポートした場所にインストールするには、--

第第24章章リモートディスクレスシステムの設定リモートディスクレスシステムの設定

201

Red Hat Enterprise Linux を、エクスポートした場所にインストールするには、--installroot オプションを指定して yum ユーティリティを使用します。

# yum install @Base kernel dracut-network nfs-utils \ --installroot=exported-root-directory --releasever=/

エクスポートしたファイルシステムをディスクレスクライアントが使用できるようにする前に行っておかなければならない設定があります。次の手順に従ってください。

手順手順24.2 ファイルシステムの設定ファイルシステムの設定

1. ディスクレスのクライアントが使用するカーネルを選択し (vmlinuz-kernel-version)、 tftp のboot ディレクトリーにコピーします。

# cp /boot/vmlinuz-kernel-version /var/lib/tftpboot/

2. NFS サポートで initrd (initramfs-kernel-version.img) を作成します。

# dracut --add nfs initramfs-kernel-version.img kernel-version

3. 以下のコマンドで initrd のファイルパーミッションを 644 に変更します。

# chmod 644 initramfs-kernel-version.img

警告警告

initrd のファイルパーミッションが変更されない場合は、pxelinux.0 ブートローダーが「ファイルが見つかりません」というエラーで失敗します。

4. 作成した initramfs-kernel-version.img を tftp boot ディレクトリーにもコピーします。

5. initrd と /var/lib/tftpboot/ ディレクトリー内のカーネルを使用するようにデフォルトの起動設定を編集します。この設定によりディスクレスクライアントの root には、エクスポートしたファイルシステム (/exported/root/directory) を読み込みと書き込みの両方の権限でマウントするよう指示されます。/var/lib/tftpboot/pxelinux.cfg/default ファイルに以下の設定を追加します。

default rhel7

label rhel7 kernel vmlinuz-kernel-version append initrd=initramfs-kernel-version.img root=nfs:server-ip:/exported/root/directory rw

server-ip には tftp サービスと DHCP サービスがあるホストマシンの IP アドレスを入力します。

これで NFS 共有をディスクレスのクライアントにエクスポートする準備が整いました。これらのディスクレスのクライアントは PXE のネットワーク経由で起動できるようになります。


202

第25章オンラインストレージ管理オペレーティングシステムを稼動させたまま再起動せずにストレージデバイスの追加、削除、またはサイズ変更を実行したい場合がよくあります。本章では、 Red Hat Enterprise Linux 7 のホストシステムを稼動させたままでシステム上のストレージデバイスを再設定する手順について簡単に説明しています。さらに、本章では iSCSI およびファイバーチャネルのストレージ相互接続について扱います。他のタイプについての詳細は今後追加していく予定です。

本章では、ストレージデバイスの追加、削除、変更、モニターを中心に説明します。ファイバーチャネルおよび iSCSI プロトコルについては詳細に説明しません。プロトコルについては他のドキュメントを参照してください。

さまざまな sysfs オブジェクトを参照しますが、sysfs オブジェクトの名前やディレクトリー構成はRed Hat Enterprise Linux の主要なリリースごとに変更されます。これは、アップストリームとなるLinux カーネルで安定した内部 API が提供されていないためです。移行が可能な方法で sysfs オブジェクトを参照する方法についてのガイドラインは、カーネルソースツリーにある /usr/share/doc/kernel-doc-version/Documentation/sysfs-rules.txt を参照してください。

警告警告

オンラインでのストレージの再設定は慎重に行ってください。プロセス中のシステム障害や中断は予期しない結果を招く恐れがあります。変更の操作を行っている間は、エクステントが最大となるようシステム負荷をできるだけ軽減させることをお勧めします。これにより、設定変更の途中で入出力エラーやメモリー不足によるエラーなどが発生する可能性が低減します。次のセクションでは、これに関してさらに詳しく説明します。

また、オンラインストレージの再設定を行う前にすべてのデータのバックアップを取ることを推奨します。

25.1. ターゲットの設定

Red Hat Enterprise Linux 7 では、targetcli シェルを、Linux-IO ターゲットの設定を表示、編集、および保存するためのフロンドエンドとして使用するため、カーネルターゲットの設定ファイルを直接操作する必要はありません。targetcli ツールはコマンドラインインターフェースで、管理者はこれを使用してファイル、ボリューム、ローカル SCSI デバイス、または RAM ディスクに関連付けられたローカルストレージリソースをリモートにエクスポートできます。targetcli ツールははツリーベースのレイアウトと、組み込みのタブ補完が含まれ、完全な自動補完サポートとインラインドキュメントを提供します。

targetcli の階層は、カーネルのインターフェースに常に一致するとは限りません。これは、targetcliが可能な限り簡素化されているためです。

重要重要

targetcli の変更内容を永続化するには、ターゲットサービスを開始し、有効にします。

# systemctl start target# systemctl enable target

第第25章章オンラインストレージ管理オンラインストレージ管理

203

25.1.1. targetcli のインストールおよび実行

targetcli をインストールするには、以下を実行します。

# yum install targetcli

target を開始するには、以下を実行します。

# systemctl start target

target サービスがブート時に起動するように設定するには、以下を実行します。

# systemctl enable target

ファイアウォールの 3260 ポートを開放し、ファイアウォール設定をリロードします。

# firewall-cmd --permanent --add-port=3260/tcpSuccess# firewall-cmd --reloadSuccess

targetcli コマンドを実行してから ls を実行し、ツリーインターフェイスのレイアウトを取得します。

# targetcli:/> lso- /........................................[...] o- backstores.............................[...] | o- block.................[Storage Objects: 0] | o- fileio................[Storage Objects: 0] | o- pscsi.................[Storage Objects: 0] | o- ramdisk...............[Storage Ojbects: 0] o- iscsi...........................[Targets: 0] o- loopback........................[Targets: 0]

注記注記

Red Hat Enterprise Linux 7.0 では、Bash から targetcli コマンド (例: targetcli iscsi/ create) を使用できず、エラーも出力されませんでした。Red Hat Enterprise Linux 7.1 からは、エラーステータスコードが出力されるようになったため、shell スクリプトで targetcli が使いやすくなりました。

25.1.2. バックストアの作成

バックストアは、ローカルマシンにエクスポートされた LUN のデータを保存するさまざまな方法に対応します。ストレージオブジェクトを作成して、バックストアが使用するリソースを定義します。

注記注記


204

注記注記

Red Hat Enterprise Linux 6 では、作成されたマッピングを「バッキングストア」と呼びました。他の意味で使用される「バッキングストア」と混合しないように、Red HatEnterprise Linux 7 では、作成されたマッピングを「ストレージオブジェクト」と呼び、別のバッキングデバイスを示す場合は「バックストア」と呼んでいます。

LIO がサポートするバックストアデバイスは次のとおりです。

FILEIO (Linux ファイルと関連付けられたストレージファイルと関連付けられたストレージ)

FILEIO ストレージオブジェクトは、write_back または write_thru 操作のいずれかをサポートします。write_back はローカルファイルシステムキャッシュを有効にします。これにより、パフォーマンスが向上しますが、データ損失のリスクが大きくなります。write_back=false を使用して write_back を無効にし、 write_thru を利用することが推奨されます。

fileio ストレージオブジェクトを作成するには、以下の例のようにコマンド /backstores/fileio create file_name file_location file_size write_back=false を実行します。

/> /backstores/fileio create file1 /tmp/disk1.img 200M write_back=falseCreated fileio file1 with size 209715200

BLOCK (Linux BLOCK デバイスデバイス)

ブロックドライバーは、/sys/block に指定されているブロックデバイスを LIO で使用できるようにします。このようなブロックデバイスには、物理デバイス (HDD、SSD、CD、DVD など) および論理デバイス (ソフトウェアまたはハードウェア RAID ボリューム、LVM ボリュームなど) が含まれます。

注記注記

通常、BLOCK バックストアは最良のパフォーマンスを提供します。

ブロックデバイスを使用して BLOCK バックストアを作成するには、以下のコマンドを使用します。

# fdisk /dev/vdbWelcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.Be careful before using the write command.

Device does not contain a recognized partition tableBuilding a new DOS disklabel with disk identifier 0x39dc48fb.

Command (m for help): nPartition type: p primary (0 primary, 0 extended, 4 free) e extendedSelect (default p): *Enter*Using default response pPartition number (1-4, default 1): *Enter*First sector (2048-2097151, default 2048): *Enter*Using default value 2048Last sector, +sectors or +size{K,M,G} (2048-2097151, default 2097151): +250M


205

Partition 1 of type Linux and of size 250 MiB is set

Command (m for help): wThe partition table has been altered!

Calling ioctl() to re-read partition table.Syncing disks.

/> /backstores/block create name=block_backend dev=/dev/vdbGenerating a wwn serial.Created block storage object block_backend using /dev/vdb.

注記注記

論理ボリューム上で BLOCK バックストアを作成できます。

PSCSI (Linux パススルーパススルー SCSI デバイスデバイス)

SCSI エミュレーションなしで SCSI コマンドの直接パススルーをサポートするストレージオブジェクト、および /proc/scsi/scsi に lsscsi とともに表示される基盤の SCSI デバイスで SCSI コマンドの直接パススルーをサポートするストレージオブジェクトは、バックストアとして設定できます。SCSI-3 以上がこのサブシステムによってサポートされます。

警告警告

PSCSI は上級ユーザーのみが使用するようにしてください。非対称論理ユニット割り当て (ALUA) や永続予約 ( VMware ESX や vSphere によって使用される永続予約など) は、通常はデバイスのファームウェアに実装されず、誤作動やクラッシュが発生する原因となることがあります。確信が持てない場合、実稼働の設定には BLOCK を使用してください。

この例の /dev/sr0 を使用して物理 SCSI デバイスである TYPE_ROM デバイスの PSCSI バックストアを作成するには、以下を使用します。

/> backstores/pscsi/ create name=pscsi_backend dev=/dev/sr0Generating a wwn serial.Created pscsi storage object pscsi_backend using /dev/sr0

メモリーコピーメモリーコピー RAM ディスクディスク (Linux RAMDISK_MCP)

メモリーコピー RAM ディスク (ramdisk) は、完全な SCSI エミュレーションと、イニシエーターのメモリーコピーを使用した個別のメモリーマッピングが含まれる RAM ディスクを提供します。メモリーコピー RAM ディスクはマルチセッションの機能を提供し、実稼働を目的とした高速で不安定なマスストレージでは特に便利です。

1 GB の RAM ディスクバックストアを作成するには、以下のコマンドを実行します。


206

/> backstores/ramdisk/ create name=rd_backend size=1GBGenerating a wwn serial.Created rd_mcp ramdisk rd_backend with size 1GB.

25.1.3. iSCSI ターゲットの作成

iSCSI ターゲットを作成するには、以下の手順に従います。

手順手順25.1 iSCSI ターゲットの作成ターゲットの作成

1. targetcli を実行します。

2. iSCSI の設定パスに移動します。

/> iscsi/

注記注記

cd コマンドでもディレクトリーの変更ができ、移動先へのパスも表示します。

3. デフォルトのターゲット名を使用して iSCSI ターゲットを作成します。

/iscsi> createCreated targetiqn.2003-01.org.linux-iscsi.hostname.x8664:sn.78b473f296ffCreated TPG1

または、特定の名前を使用して iSCSI ターゲットを作成します。

/iscsi > create iqn.2006-04.com.example:444Created target iqn.2006-04.com.example:444Created TPG1

4. ls でターゲットをリストし、新規作成されたターゲットが表示されることを確認します。

/iscsi > lso- iscsi.......................................[1 Target] o- iqn.2006-04.com.example:444................[1 TPG] o- tpg1...........................[enabled, auth] o- acls...............................[0 ACL] o- luns...............................[0 LUN] o- portals.........................[0 Portal]

注記注記

Red Hat Enterprise Linux 7.1 では、ターゲットが作成されるとデフォルトのポータルも作成されます。

25.1.4. iSCSI ポータルの設定


207

iSCSI ポータルを設定するには、最初に iSCSI ターゲットを作成し、TPG と関連付ける必要があります。この手順は、「iSCSI ターゲットの作成」を参照してください。

注記注記

Red Hat Enterprise Linux 7.1 では、iSCSI ターゲットが作成されるとデフォルトのポータルも作成されます。このポータルは、デフォルトのポート番号 (0.0.0.0:3260) ですべての IP アドレスをリッスンするよう設定されます。このポータルを削除し、特定のポータルのみを追加するには、/iscsi/iqn-name/tpg1/portals delete ip_address=0.0.0.0 ip_port=3260 を使用し、必要な情報で新しいポータルを作成します。

手順手順25.2 iSCSI ポータルの作成ポータルの作成

1. TPG に移動します。

/iscsi> iqn.2006-04.example:444/tpg1/

2. ポータルを作成する方法には、デフォルトポータルを作成する方法と、リッスンする IP アドレスを指定してポータルを作成する方法の 2 つがあります。

デフォルトポータルを作成する方法では、デフォルトの iSCSI ポート 3260 を使用し、ターゲットがそのポートのすべての IP アドレスをリッスンできるようにします。

/iscsi/iqn.20...mple:444/tpg1> portals/ createUsing default IP port 3260Binding to INADDR_Any (0.0.0.0)Created network portal 0.0.0.0:3260

リッスンする IP アドレスを指定してポータルを作成するには、以下のコマンドを使用します。

/iscsi/iqn.20...mple:444/tpg1> portals/ create 192.168.122.137Using default IP port 3260Created network portal 192.168.122.137:3260

3. ls コマンドを実行して新規作成されたポータルが表示されることを確認します。

/iscsi/iqn.20...mple:444/tpg1> lso- tpg.................................. [enambled, auth] o- acls ......................................[0 ACL] o- luns ......................................[0 LUN] o- portals ................................[1 Portal] o- 192.168.122.137:3260......................[OK]

25.1.5. LUN の設定

LUN を設定するには、最初にストレージオブジェクトを作成します。詳細は「バックストアの作成」を参照してください。

手順手順25.3 LUN の設定の設定

1. 作成済みのストレージオブジェクトの LUN を作成します。


208

/iscsi/iqn.20...mple:444/tpg1> luns/ create /backstores/ramdisk/rd_backendCreated LUN 0.

/iscsi/iqn.20...mple:444/tpg1> luns/ create /backstores/block/block_backendCreated LUN 1.

/iscsi/iqn.20...mple:444/tpg1> luns/ create /backstores/fileio/file1Created LUN 2.

2. 変更内容を表示します。

/iscsi/iqn.20...mple:444/tpg1> lso- tpg.................................. [enambled, auth] o- acls ......................................[0 ACL] o- luns .....................................[3 LUNs] | o- lun0.........................[ramdisk/ramdisk1] | o- lun1.................[block/block1 (/dev/vdb1)] | o- lun2...................[fileio/file1 (/foo.img)] o- portals ................................[1 Portal] o- 192.168.122.137:3260......................[OK]

注記注記

デフォルトの LUN 名は 0 で始まることに注意してください。Red HatEnterprise Linux 6 の tgtd を使用した場合は 1 で始まっていました。

3. ACL を構成します。詳細は、「ACL の設定」を参照してください。

重要重要

デフォルトでは、読み書きパーミッションを持つ LUN が作成されます。ACL が作成された後に新しい LUN が追加された場合、その LUN は利用可能なすべての ACL に自動的にマップされます。これはセキュリティー上のリスクとなります。以下の手順に従って、読み取り専用の LUN を作成します。

手順手順25.4 読み取り専用の読み取り専用の LUN の作成の作成

1. 読み取り専用パーミッションを持つ LUN を作成するには、最初に以下のコマンドを使用します。

/> set global auto_add_mapped_luns=falseParameter auto_add_mapped_luns is now 'false'.

これにより、LUN が既存の ACL へ自動的にマッピングされないようになり、LUN を手動でマッピングできるようになります。

2. 次に、コマンド iscsi/target_iqn_name/tpg1/acls/initiator_iqn_name/ create mapped_lun=next_sequential_LUN_number tpg_lun_or_backstore=backstore write_protect=1 を実行し、LUN を手動作成します。

/> iscsi/iqn.2015-06.com.redhat:target/tpg1/acls/iqn.2015-06.com.redhat:initiator/ create mapped_lun=1 tpg_lun_or_backstore=/backstores/block/block2 write_protect=1


209

Created LUN 1.Created Mapped LUN 1./> lso- / ...................................................... [...] o- backstores ........................................... [...] <snip> o- iscsi ......................................... [Targets: 1] | o- iqn.2015-06.com.redhat:target .................. [TPGs: 1] | o- tpg1 ............................ [no-gen-acls, no-auth] | o- acls ....................................... [ACLs: 2] | | o- iqn.2015-06.com.redhat:initiator .. [Mapped LUNs: 2] | | | o- mapped_lun0 .............. [lun0 block/disk1 (rw)] | | | o- mapped_lun1 .............. [lun1 block/disk2 (ro)] | o- luns ....................................... [LUNs: 2] | | o- lun0 ...................... [block/disk1 (/dev/vdb)] | | o- lun1 ...................... [block/disk2 (/dev/vdc)] <snip>

(mapped_lun0 の (rw) とは異なり) mapped_lun1 行の最後に (ro) が表示されますが、これは、読み取り専用であることを表しています。

3. ACL を構成します。詳細は、「ACL の設定」を参照してください。

25.1.6. ACL の設定

接続している各イニシエーターに対して ACL を作成します。これにより、イニシエーターの接続時に認証が強制され、LUN のみが各イニシエーターに公開されます。通常、各イニシエーターは LUN へ排他的にアクセスできます。ターゲットおよびイニシエーターは一意の識別名を持ちます。ACL を設定するには、イニシエーターの一意名を知っている必要があります。open-iscsi イニシエーターの場合は、/etc/iscsi/initiatorname.iscsi で一意名を確認できます。

手順手順25.5 ACL の設定の設定

1. acls ディレクトリーへ移動します。

/iscsi/iqn.20...mple:444/tpg1> acls/

2. ACL を作成します。イニシエーターの /etc/iscsi/initiatorname.iscsi にあるイニシエーター名を使用するか、簡単に覚えられる名前を使用している場合は「iSCSI イニシエーターの作成」を参照して ACL がイニシエーターと一致するようにします。例を以下に示します。

/iscsi/iqn.20...444/tpg1/acls> create iqn.2006-04.com.example.foo:888Created Node ACL for iqn.2006-04.com.example.foo:888Created mapped LUN 2.Created mapped LUN 1.Created mapped LUN 0.

注記注記


210

注記注記

上記の例の挙動は、使用する設定によって異なります。この場合、グローバル設定の auto_add_mapped_luns が使用されます。これは、LUN を作成されたACL に自動的にマップします。

ターゲットサーバーの TPG ノードに、ユーザーが作成した ACL を設定します。

/iscsi/iqn.20...scsi:444/tpg1> set attribute generate_node_acls=1

3. 変更内容を表示します。

/iscsi/iqn.20...444/tpg1/acls> lso- acls .................................................[1 ACL] o- iqn.2006-04.com.example.foo:888 ....[3 Mapped LUNs, auth] o- mapped_lun0 .............[lun0 ramdisk/ramdisk1 (rw)] o- mapped_lun1 .................[lun1 block/block1 (rw)] o- mapped_lun2 .................[lun2 fileio/file1 (rw)]

25.1.7. ファイバーチャネルオーバーイーサネット (FCoE) ターゲットの設定

targetcli を使用すると、「ファイバーチャネルオーバーイーサネットインターフェースの設定」で説明した FCoE における LUN のマウントの他に、FCoE の他のマシンへ LUN をエクスポートすることもサポートされます。

重要重要

次に進む前に、「ファイバーチャネルオーバーイーサネットインターフェースの設定」を参照して、基本的な FCoE 設定が完了しており、fcoeadm -i を実行すると、設定したFCoE インターフェースが表示されることを確認してください。

手順手順25.6 FCoE ターゲットの設定ターゲットの設定

1. FCoE ターゲットを設定するには、targetcli パッケージとその依存関係をインストールする必要があります。targetcli の基本および設定に関する詳細は、「ターゲットの設定」を参照してください。

2. FCoE インターフェースで FCoE ターゲットインスタンスを作成します。

/> tcm_fc/ create 00:11:22:33:44:55:66:77

FCoE インターフェースがシステムにある場合、create の後にタブ補完を行うと、使用可能なインターフェースが表示されます。このインターフェースがない場合は、fcoeadm -i でアクティブなインターフェースが表示されることを確認してください。

3. バックストアをターゲットインスタンスにマッピングします。

例例25.1 バックストアのターゲットインスタンスへのマッピング例バックストアのターゲットインスタンスへのマッピング例

/> tcm_fc/00:11:22:33:44:55:66:77

/> luns/ create /backstores/fileio/example2


211

4. FCoE イニシエーターからの LUN へのアクセスを許可します。

/> acls/ create 00:99:88:77:66:55:44:33

LUN が指定のイニシエーターにアクセスできるようになりました。

5. 再起動後も変更を維持するには、saveconfig コマンドを使用し、入力が要求されたら yes を入力します。この作業を行わないと、再起動後に設定が失われます。

6. exit とタイプするか、ctrl+D を押して targetcli を終了します。

25.1.8. targetcli によるオブジェクトの削除

バックストアを削除するには、以下のコマンドを使用します。

/> /backstores/backstore-type/backstore-name

ACL などの iSCSI ターゲットの一部を削除するには、以下のコマンドを使用します。

/> /iscsi/iqn-name/tpg/acls/ delete iqn-name

(ACL、LUN、およびポータルのすべてを含む) ターゲット全体を削除するには、以下のコマンドを使用します。

/> /iscsi delete iqn-name

25.1.9. targetcli のリファレンス

targetcli の詳細については、次のリソースを参照してください。

man targetcli

targetcli の man ページ。ウォークスルーの例が含まれています。

Linux SCSI Target Wiki

http://linux-iscsi.org/wiki/Targetcli

Andy Grover によるスクリーンキャストによるスクリーンキャスト

https://www.youtube.com/watch?v=BkBGTBadOO8

注記注記

この動画は 2012 年 2 月 28 日にアップロードされたため、サービス名が targetcli から target に変更されています。

25.2. ISCSI イニシエーターの作成

「ターゲットの設定」に従って targetcli でターゲットを作成したら、iscsiadm ユーティリティーを使


212

http://linux-iscsi.org/wiki/Targetcli

https://www.youtube.com/watch?v=BkBGTBadOO8

「ターゲットの設定」に従って targetcli でターゲットを作成したら、iscsiadm ユーティリティーを使用してイニシエーターを設定します。

Red Hat Enterprise Linux 7 のデフォルトでは、iSCSI サービスの起動に時間がかかります。したがって、iscsiadm コマンドが実行してから、このサービスが起動します。

手順手順25.7 iSCSI イニシエーターの作成イニシエーターの作成

1. iscsi-initiator-utils をインストールします。

# yum install iscsi-initiator-utils -y

2. 「ACL の設定」で ACL にカスタム名を付けた場合は、それに合わせて /etc/iscsi/initiatorname.iscsi ファイルを修正します。

# cat /etc/iscsi/initiatorname.iscsiInitiatorName=iqn.2006-04.com.example.node1

# vi /etc/iscsi/initiatorname.iscsi

3. ターゲットを検出します。

# iscsiadm -m discovery -t st -p target-ip-address 10.64.24.179:3260,1 iqn.2006-04.com.example:3260

4. 手順 3 で検出したターゲット IQN で、ターゲットにログインします。

# iscsiadm -m node -T iqn.2006-04.com.example:3260 -l Logging in to [iface: default, target: iqn.2006-04.com.example:3260, portal: 10.64.24.179,3260] (multiple)Login to [iface: default, target: iqn.2006-04.com.example:3260, portal: 10.64.24.179,3260] successful.

「ACL の設定」の説明どおりにイニシエーター名を ACL に追加しさえすれば、この手順に従って、同じ LUN に接続されるイニシエーターをいくつでも作成できます。

5. iSCSI ディスク名を見つけて、この iSCSI ディスク上にファイルシステムを作成します。

# grep "Attached SCSI" /var/log/messages

# mkfs.ext4 /dev/disk_name

disk_name を、/var/log/messages で表示されている iSCSI ディスク名に置き換えます。


# mkdir /mount/point# mount /dev/disk_name /mount/point

/mount/point を、実際に使用するパーティションのマウントポイントに置き換えます。

7. システムのブート時にファイルシステムを自動的にマウントするように /etc/fstab を編集します。


213

# vim /etc/fstab/dev/disk_name /mount/point ext4 _netdev 0 0

disk_name を iSCSI ディスク名に置き換えます。

8. ターゲットからログオフします。

# iscsiadm -m node -T iqn.2006-04.com.example:3260 -u

25.3. チャレンジハンドシェイク認証プロトコルの設定

ACL を設定して iSCSI イニシエーターを作成したら、チャレンジハンドシェイク認証プロトコル(CHAP) をセットアップします。ACL の設定と iSCSI イニシエーターの作成の詳細は、「ACL の設定」と「iSCSI イニシエーターの作成」を参照してください。

CHAP により、ユーザーはパスワードでターゲットを保護できるようになります。このイニシエーターは、このパスワードでターゲットに接続できることを認識している必要があります。

手順手順25.8 ターゲットのターゲットの CHAP の設定の設定

1. 属性認証を設定します。

/iscsi/iqn.20...mple:444/tpg1> set attribute authentication=1

Parameter authentication is now '1'.

2. ユーザー ID とパスワードを設定します。

/iscsi/iqn.20...mple:444/tpg1> set auth userid=redhat

Parameter userid is now 'redhat'.

/iscsi/iqn.20...mple:444/tpg1> set auth password=redhat_passwd

Parameter password is now 'redhat_passwd'.

手順手順25.9 イニシエーターのイニシエーターの CHAP の設定の設定

1. iscsid.conf ファイルを編集します。

iscsid.conf ファイルで CHAP 認証を有効化します。

# vi /etc/iscsi/iscsid.conf

node.session.auth.authmethod = CHAP

デフォルトでは、node.session.auth.authmethod オプションは None に設定されています。

ターゲットユーザー名とパスワードを iscsid.conf ファイルに追加します。


214

node.session.auth.username = redhatnode.session.auth.password = redhat_passwd

2. iscsid サービスを再起動します。

# systemctl restart iscsid.service

詳細は、targetcli と iscsiadm の man ページを参照してください。

25.4. ファイバーチャネル

このセクションでは、ファイバーチャネル API、ネイティブの Red Hat Enterprise Linux 7 ファイバーチャネルドライバー、およびこれらのドライバーのファイバーチャネル機能について説明します。

25.4.1. ファイバーチャネル API

以下は、ユーザースペース API の提供に使用されるファイルを含む /sys/class/ ディレクトリーの一覧です。それぞれの項目で、ホスト番号は H、バス番号は B、ターゲットは T、論理ユニット番号 (LUN)は L、およびリモートポート番号は R で表示されています。

重要重要

マルチパスソフトウェアを使用されている場合は、このセクションで記載する値のいずれかを変更する前に、ご使用のハードウェアのベンダーにお問い合わせになることをお勧めします。

トランスポートトランスポート: /sys/class/fc_transport/targetH:B:T/

port_id — 24-bit ポート ID/アドレス

node_name — 64-bit ノード名

port_name — 64-bit ポート名

リモートポートリモートポート: /sys/class/fc_remote_ports/rport-H:B-R/

port_id

node_name

port_name

dev_loss_tmo: scsi デバイスがシステムから削除されるタイミングを制御します。dev_loss_tmo がトリガーされると、scsi デバイスが削除されます。

multipath.conf では、dev_loss_tmo を infinity に設定できます。これは、値を2,147,483,647秒または 68 年に設定します。また、これは最大 dev_loss_tmo 値です。

Red Hat Enterprise Linux 7 では、fast_io_fail_tmo オプションを設定しないと、dev_loss_tmo は 600 秒に制限されます。 Red Hat Enterprise Linux 7 のデフォルトでは、multipathd を実行していると、fast_io_fail_tmo は 5 秒に設定されています。そうでなければ、off に設定されています。

fast_io_fail_tmo: 「不良」としてリンクをマークする前に待機する秒数を指定します。リン


215

fast_io_fail_tmo: 「不良」としてリンクをマークする前に待機する秒数を指定します。リンクが不良としてマークされると、一致するパス上の既存の実行している I/O または新しいI/O がエラーを起こします。

I/O がブロックされたキューに存在する場合は、dev_loss_tmo の期限が切れ、キューのブロックが解除されるまでエラーを起こしません。

If fast_io_fail_tmo が off 以外の値に設定されていると、dev_loss_tmo は制限されません。fast_io_fail_tmo が off に設定されると、デバイスがシステムから削除されるまで I/Oはエラーを起こしません。fast_io_fail_tmo が数値に設定されていると、fast_io_fail_tmoタイムアウトがトリガーするとすぐにエラーを起こします。

ホストホスト: /sys/class/fc_host/hostH/

port_id

issue_lip: リモートポートを再度検出するようにドライバーに命令します。

25.4.2. ネイティブファイバーチャネルのドライバーと機能

Red Hat Enterprise Linux 7 には、以下のネイティブファイバーチャネルドライバーが同梱されます。

lpfc

qla2xxx

zfcp

bfa

重要重要

qla2xxx ドライバーは、デフォルトでイニシエーターモードで実行します。Linux-IO でqla2xxx を使用するには、対応する qlini_mode モジュールパラメーターでファイバーチャネルのターゲットモードを有効にします。

最初に、qla デバイス用のファームウェアパッケージ (ql2200-firmware など) がインストールされていることを確認します。

ターゲットモードを有効にするには、/usr/lib/modprobe.d/qla2xxx.conf qla2xxx モジュール設定ファイルに以下のパラメーターを追加します。

options qla2xxx qlini_mode=disabled

次に、dracut -f コマンドを実行して初期 ramdisk (initrd) を再構築し、システムを再起動して変更を有効にします。

表25.1「ファイバーチャネル API の機能」では、Red Hat Enterprise Linux 7 の各ネイティブドライバーにおけるファイバーチャネル API 機能を説明しています。「X」は、該当する機能のサポートがあることを示します。

表表25.1 ファイバーチャネルファイバーチャネル API の機能の機能


216

lpfc qla2xxx zfcp bfa

トランスポート port_id

X X X X

トランスポート node_name

X X X X

トランスポート port_name

X X X X

リモートポート dev_loss_tmo

X X X X

リモートポート fast_io_fail_tmo

X X [a] X [b] X

ホスト port_id X X X X

ホスト issue_lip X X X

[a] Red Hat Enterprise Linux 5.4 以降でサポート

[b] Red Hat Enterprise Linux 6.0 以降でサポート

25.5. ファイバーチャネルオーバーイーサネットインターフェースの設定

ファイバーチャネルオーバーイーサネット (FCoE) インターフェースのセットアップと導入には、2 つのパッケージが必要です。

fcoe-utils

lldpad

これらのパッケージをインストールしたら、以下の手順を実行して、仮想 LAN (VLAN) で FCoE を有効にします。

手順手順25.10 FCoE を使用するためのイーサネットインターフェースを設定を使用するためのイーサネットインターフェースを設定

1. 新規の VLAN を設定するには、既存のネットワークスクリプト (例: /etc/fcoe/cfg-eth0) のコピーを作成し、FCoE をサポートするイーサネットデバイスの名前を変更します。これは、デフォルトの設定ファイルになります。FCoE デバイスが ethX の場合は、以下を実行します。

# cp /etc/fcoe/cfg-ethx /etc/fcoe/cfg-ethX

必要に応じて cfg-ethX の内容を編集します。ネットワーキングインターフェースが、ハードウェアの Data Center Bridging Exchange (DCBX) プロトコルクライアントを実装場合は、DCB_REQUIRED を no に設定します。

2. 起動中にデバイスが自動的にロードするように設定するには、そのデバイスの /etc/sysconfig/network-scripts/ifcfg-ethX ファイルに、ONBOOT=yes と設定します。たとえ


217

ば、FCoE デバイスが eth2 の場合は、/etc/sysconfig/network-scripts/ifcfg-eth2 ファイルに設定します。

3. 以下を実行し、データセンターブリッジングデーモン (dcbd) を起動します。

# systemctl start lldpad

4. ネットワーキングインターフェースがハードウェア DCBX クライアントを実装する場合は、このステップを省略します。

インターフェースでソフトウェア DCBX クライアントが必要な場合は、以下のコマンドを実行して、イーサネットインターフェースでデータセンターブリッジングを有効にします。

# dcbtool sc ethX dcb on

次に、以下を実行して、イーサネットインターフェースで FCoE を有効にします。

# dcbtool sc ethX app:fcoe e:1

これらのコマンドは、イーサネットインターフェースの dcbd の設定を変更していない場合に限り有効になります。

5. 以下を使用して、FCoE デバイスをロードします。

# ip link set dev ethX up

6. 次のコマンドで FCoE を開始します。

# systemctl start fcoe

他のすべての fabric 設定が正しければ、まもなく FCoE デバイスが表示されます。設定したFCoE デバイスを表示するには、以下を実行します。

# fcoeadm -i

FCoE を使用するためにイーサネットインターフェースを正しく設定した後は、FCoE と lldpad サービスをスタートアップで起動するように設定することをおすすめします。これを行うには、systemctlユーティリティを使用します。

# systemctl enable lldpad

# systemctl enable fcoe

注記注記

# systemctl stop fcoe コマンドを実行するとデーモンは停止しますが、FCoE インターフェースの設定はリセットされません。リセットするには、# systemctl -s SIGHUP kill fcoe コマンドを実行します。

Red Hat Enterprise Linux 7 では、DCB 対応のイーサネットインターフェースの DBC 設定をクエリおよび設定に、ネットワークマネージャーを使用できます。


218

25.6. 起動時に FCOE インターフェースを自動マウントする設定

注記注記

このセクションの情報は、Red Hat Enterprise Linux 6.1 の時点では /usr/share/doc/fcoe-utils-version/README でご覧いただけます。複数のマイナーリリースで生じる可能性のある変更についてはこの README を参照してください。

新しく検出されたディスクは、udev ルール、autofs、および他の類似の方法でマウントできます。しかし、特定のサービスが FCoE ディスクの起動時のマウントを要求することがあります。そのような場合には、FCoE ディスクは fcoe サービスの実行後すぐにすぐに、かつ FCoE ディスクを要求するサービスの開始前に前にマウントされる必要があります。

FCoE ディスクを起動時に自動マウントするように設定するには、正式な FCoE マウントコードを fcoeサービスのスタートアップスクリプトに追加します。fcoe のスタートアップスクリプトは、/lib/systemd/system/fcoe.service です。

FCoE マウントコードは、単純フォーマットの FCoE ディスク、LVM、またはマルチパスデバイスのノードを使用しているかどうかなどのシステム設定ごとに異なります。

例例25.2 FCoE マウントコードマウントコード

以下は、/etc/fstab 内のワイルドカードで指定されたファイルシステムをマウントするための FCoEマウントコードのサンプルです。

mount_fcoe_disks_from_fstab() { local timeout=20 local done=1 local fcoe_disks=($(egrep 'by-path\/fc-.*_netdev' /etc/fstab | cut -d ' ' -f1))

test -z $fcoe_disks && return 0

echo -n "Waiting for fcoe disks . " while [ $timeout -gt 0 ]; do for disk in ${fcoe_disks[*]}; do if ! test -b $disk; then done=0 break fi done

test $done -eq 1 && break; sleep 1 echo -n ". " done=1 let timeout-- done

if test $timeout -eq 0; then echo "timeout!" else echo "done!" fi


219

# mount any newly discovered disk mount -a 2>/dev/null }

mount_fcoe_disks_from_fstab 関数は、fcoe サービススクリプトが fcoemon デーモンを開始した後後にに呼び出される必要があります。この関数が、/etc/fstab 内の以下のパスで指定されている FCoE ディスクをマウントします。

/dev/disk/by-path/fc-0xXX:0xXX /mnt/fcoe-disk1 ext3 defaults,_netdev 0 0/dev/disk/by-path/fc-0xYY:0xYY /mnt/fcoe-disk2 ext3 defaults,_netdev 0 0

fc- サブストリングと _netdev サブストリングを持つエントリーは、mount_fcoe_disks_from_fstab関数が FCoE ディスクマウントエントリリーを識別できるようにします。/etc/fstab のエントリーの詳細は、man 5 fstab を参照してください。

注記注記

fcoe サービスは FCoE ディスク検出のタイムアウトを実装しません。そのため、FCoEマウントコードでは独自のタイムアウト期間を実装する必要があります。

25.7. ISCSI

このセクションでは、iSCSI API および、iscsiadm ユーティリティーについて説明します。iscsiadmユーティリティーを使用するには、yum install iscsi-initiator-utils を実行して iscsi-initiator-utilsパッケージをインスト－ルしてください。

Red Hat Enterprise Linux 7 では、iSCSI サービスはデフォルトでレイジーに開始されます。root がiSCSI デバイスになかったり、node.startup = automatic でマークされたノードがない場合は、iscsidまたは iscsi カーネルモジュールの起動を要求をする iscsiadm コマンドが実行されるまでは、iSCSIサービスは開始されません。たとえば、ディスカバリーコマンド iscsiadm -m discovery -t st -p ip:port を実行すると、iscsiadmin が iSCSI サービスを開始します。

iscsid デーモンを強制的に実行して、iSCSI カーネルモジュールのロードするには、systemctl start iscsid.service コマンドを実行します。

25.7.1. iSCSI API

実行中のセッションに関する情報を得るには、以下を実行します。

# iscsiadm -m session -P 3

このコマンドは、セッション/デバイスの状態、セッション ID (sid)、いくつかのネゴシエートしたパラメーター、およびセッション経由でアクセス可能な SCSI デバイスを表示します。

より短い出力 (たとえば、sid とノード間のマッピングのみの表示) には、以下を実行します。


または

# iscsiadm -m session


220

これらのコマンドは、以下の形式で実行中のセッションの一覧を表示します。

driver [sid] target_ip:port,target_portal_group_tag proper_target_name

例例25.3 iscsisadm -m session コマンドの出力コマンドの出力


# iscsiadm -m session

tcp [2] 10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.33615311tcp [3] 10.15.85.19:3260,3 iqn.1992-08.com.netapp:sn.33615311

iSCSI API の詳細は、/usr/share/doc/iscsi-initiator-utils-version/README を参照してください。

25.8. 永続的な命名

Red Hat Enterprise Linux では、ストレージデバイスを識別する方法が複数あります。特にドライブへのインストール時やドライブの再フォーマット時に誤ったデバイスにアクセスしないようにするため、適切なオプションを使用して各デバイスを識別することが重要になります。

25.8.1. ストレージデバイスのメジャー番号とマイナー番号

sd ドライバーによって管理されるストレージデバイスは、メジャーデバイス番号とそれらに関連するマイナー番号によって内部で識別されます。この目的で使用されるメジャーデバイス番号は、連続した範囲にありません。各ストレージデバイスは、デバイス全体またはデバイス内のパーティションの識別に使用されるメジャー番号とマイナー番号によって表されます。sd<letter(s)>[number(s)] の形式でデバイスおよび番号に割り当てられるメジャー番号およびマイナー番号の間には直接的な関係があります。sd ドライバーによって新しいデバイスが検出されると、利用可能なメジャー番号およびマイナー番号の範囲が割り当てられます。デバイスがオペレーティングシステムから削除されると、メジャー番号とマイナー番号の範囲が解放され、後で再使用されます。

デバイスが検出されると、メジャーおよびマイナー番号の範囲と、関連する sd 名がそのデバイスに割り当てられます。そのため、デバイス検出の順番が変わった場合、メジャーおよびマイナー番号の範囲と、関連する sd 名との関係が変更される可能性があります。これは、一部のハードウェア設定ではまれですが (シャーシ内の物理的な場所によって SCSI ターゲット ID が割り当てられる内部 SCSI コントローラーおよびディスクなどの場合)、以下の例のような状況で発生する可能性があります。

ディスクが起動しなかったり、SCSI コントローラーに応答しないことがあります。この場合は、通常のデバイスプローブにより検出されません。ディスクはシステムにアクセスできなくなり、後続のデバイスは関連する次の sd 名が含まれる、メジャーおよびマイナー番号の範囲があります。たとえば、通常 sdb と呼ばれるディスクが検出されないと、sdc と呼ばれるディスクが sdb として代わりに表示されます。

SCSI コントローラー (ホストバスアダプターまたは HBA) が初期化に失敗し、その HBA に接続されているディスクすべてが検出されなかった場合。後続のプローブされた HBA に接続しているディスクは、異なるメジャーおよびマイナー番号の範囲および異なる関連する sd 名を割り当てられます。

システムに異なるタイプの HBA が存在する場合、ドライバー初期化の順序が変更される可能性があります。これにより、これらの HBA に接続されているディスクが異なる順序で検出される可能性があります。また、HBA がシステムの他の PCI スロットに移動された場合でも発生する可能性があります。


221

ストレージアレイや干渉するスイッチの電源が切れた場合など、ストレージデバイスがプローブされたときに、ファイバーチャネル、iSCSI、または FCoE アダプターを持つシステムに接続されたディスクがアクセスできなくなる可能性があります。システムが起動するまでの時間よりもストレージアレイがオンラインになるまでの時間の方が長く、電源の障害後にシステムが再起動すると、この問題が発生する可能性があります。一部のファイバーチャネルドライバーは WWPN マッピングへの永続 SCSI ターゲット ID を指定するメカニズムをサポートしますが、メジャーおよびマイナー番号の範囲や関連する sd 名は予約されず、一貫性のある SCSIターゲット ID 番号のみが提供されます。

そのため、/etc/fstab ファイルなどにあるデバイスを参照するときにメジャーおよびマイナー番号の範囲や関連する sd 名を使用することは望ましくありません。誤ったデバイスがマウントされ、データが破損する可能性があります。

しかし、場合によっては他のメカニズムが使用される場合でも sd 名の参照が必要になる場合もあります (デバイスによりエラーが報告される場合など)。これは、Linux カーネルはデバイスに関するカーネルメッセージで sd 名 (および SCSI ホスト、チャネル、ターゲット、LUN タプル) を使用するためです。

25.8.2. World Wide Identifier (WWID)

World Wide Identifier (WWID) を使用するとデバイスを正確に識別することが可能です。 WWID は、SCSI 標準がすべての SCSI デバイスに必要とするシステムに依存しない永続的な ID です。各ストレージデバイスの WWID は一意となることが保証され、デバイスのアクセスに使用されるパスに依存しません。

この識別子は、 Device Identification Vital Product Data (ページ 0x80) または Unit Serial Number (ページ 0x83) を取得するための SCSI Inquiry を発行することで取得することができます。WWID から現在の/dev/sd 名へのマッピングは /dev/disk/by-id/ ディレクトリー内で管理されているシンボリックリンクで確認できます。

例例25.4 WWID

たとえば、ページ 0x83 の識別子を持つデバイスは、以下のような設定になります。

scsi-3600508b400105e210000900000490000 -> ../../sda

または、ページ 0x80 の識別子を持つデバイスは、以下のような設定になります。

scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda

Red Hat Enterprise Linux では、WWID ベースのデバイス名からそのシステム上の現在の /dev/sd 名への正しいマッピングを自動的に維持します。デバイスへのパスが変更したり、別のシステムからそのデバイスへのアクセスがあった場合にも、アプリケーションはディスク上のデータ参照に /dev/disk/by-id/ を使用することができます。

1 つのシステムから 1 つのデバイスへのパスが複数ある場合、 DM Multipath は WWID を使って検出を行います。次に DM Multipath は /dev/mapper/3600508b400105df70000e00000ac0000 などの単一の「擬似デバイス」を /dev/mapper/wwid ディレクトリー内に示します。

multipath -l コマンドは、永続化されていない識別子であるHost:Channel:Target:LUN、/dev/sd名、major:minor 番号へのマッピングを表示します。

3600508b400105df70000e00000ac0000 dm-2 vendor,product


222

[size=20G][features=1 queue_if_no_path][hwhandler=0][rw] \_ round-robin 0 [prio=0][active] \_ 5:0:1:1 sdc 8:32 [active][undef] \_ 6:0:1:1 sdg 8:96 [active][undef]\_ round-robin 0 [prio=0][enabled] \_ 5:0:0:1 sdb 8:16 [active][undef] \_ 6:0:0:1 sdf 8:80 [active][undef]

DM Multipath は、各 WWID ベースのデバイス名からシステムの対応する /dev/sd 名の適切なマッピングを自動的に維持します。これらの名前は、パスの変更後も永続され、他のシステムからデバイスにアクセスしたときに一貫性を保持します。

user_friendly_names 機能を使用すると (DM Multipath の機能)、WWID は /dev/mapper/mpathn の形式の名前にマッピングされます。デフォルトでは、このマッピングは /etc/multipath/bindings ファイル内で維持されます。このファイルが維持されている限り、これら mpathn の名前は永続的となります。

重要重要

user_friendly_names を使用する場合は、クラスターで一貫した名前を取得するのにその他の操作を行う必要があります。「DM マルチパス」のクラスター内で整合性のあるマルチパスデバイス名の維持のセクションを参照してください。

システムにより提供される永続的な名前の他に、udev ルールを使用して独自の永続的な名前を実装し、ストレージの WWID にマップすることもできます。

25.8.3. udev メカニズム (/dev/disk/by-*) によって管理されるデバイス名

udev のメカニズムは、主な 3 つのコンポーネントで構成されます。

カーネルカーネル

デバイスの追加、削除、または変更時にユーザー領域へ送信されるイベントを生成します。

udevd については、以下を実行します。については、以下を実行します。

イベントを受信します。

udev ルールルール

udev サービスがカーネルイベントを受信したときに行う操作を指定します。

このメカニズムはストレージデバイスのみでなく、Linux の全種類のデバイスに使用されます。ストレージデバイスの場合、Red Hat Enterprise Linux には /dev/disk/ ディレクトリーにシンボリックリンクを作成する udev ルールが含まれ、ストレージデバイスのコンテンツ、一意な識別子、シリアル番号、またはデバイスのアクセスに使用されるハードウェアパスを用いてストレージデバイスを参照できます。

/dev/disk/by-label/

このディレクトリーのエントリーは、デバイスに保存されたコンテンツ (データ) のラベルを用いてストレージデバイスを参照するシンボリック名を提供します。blkid ユーティリティは、デバイスからデータを読み取り、そのデバイスの名前 (ラベル) を判断するために使用されます。例を以下に示します。

/dev/disk/by-label/Boot


223

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/dm_multipath/index

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/dm_multipath/index#multipath_consistent_names

注記注記

情報はデバイス上のコンテンツ (データ) から取得されるため、コンテンツが別のデバイスにコピーされても、ラベルは同じになります。

また、以下の構文どおりにラベルを使用すると /etc/fstab のデバイスを参照することもできます。

LABEL=Boot

/dev/disk/by-uuid/

このディレクトリーのエントリーは、デバイスに保存されたコンテンツ (データ) の一意な識別子を用いてストレージデバイスを参照するシンボリック名を提供します。blkid ユーティリティは、デバイスからデータを読み取り、デバイスの一意な識別子 (UUID) を取得するために使用されます。例を以下に示します。

UUID=3e6be9de-8139-11d1-9106-a43f08d823a6

/dev/disk/by-id/

このディレクトリーのエントリーは、一意な識別子 (他のストレージデバイスとは異なる) を用いてストレージデバイスを参照するシンボリック名を提供します。識別子はデバイスのプロパティーですが、デバイス上のコンテンツ (データ) には保存されません。例を以下に示します。

/dev/disk/by-id/scsi-3600508e000000000ce506dc50ab0ad05

/dev/disk/by-id/wwn-0x600508e000000000ce506dc50ab0ad05

ID は、デバイスのワールドワイド ID またはデバイスのシリアル番号から取得されます。/dev/disk/by-id/ エントリーにパーティション番号が含まれることもあります。例を以下に示します。

/dev/disk/by-id/scsi-3600508e000000000ce506dc50ab0ad05-part1

/dev/disk/by-id/wwn-0x600508e000000000ce506dc50ab0ad05-part1

/dev/disk/by-path/

このディレクトリーのエントリーは、デバイスのアクセスに使用されるハードウェアパスを用いてストレージデバイスを参照するシンボリック名を提供します。PCI 階層のストレージコントローラーへの参照で始まり、SCSI ホスト、チャネル、ターゲット、および LUN 番号が含まれ、任意でパーティション番号が含まれます。メジャーおよびマイナー番号または sd 名のよりも、これらの名前の使用が推奨されますが、ファイバーチャネル SAN 環境でターゲット番号が変更しないようにし(永続バインディングなどを使用)、ホストアダプターを別の PCI ストッロに移す場合は名前の使用を更新するよう注意する必要があります。さらに、HBA のプローブに失敗した場合、ドライバーが異なる順序でロードされた場合、または新しい HBA がシステムにインストールされた場合など、SCSI ホスト番号が変更する可能性があります。バイパスリストの例を以下に示します。

/dev/disk/by-path/pci-0000:03:00.0-scsi-0:1:0:0

/dev/disk/by-path/ エントリーに以下のようなパーティション番号が含まれることもあります。


224

/dev/disk/by-path/pci-0000:03:00.0-scsi-0:1:0:0-part1

25.8.3.1. udev デバイスの命名規則の制限デバイスの命名規則の制限

以下は、udev の命名規則の制限の一例です。

udev イベントに対して udev ルールが処理されるときに udev メカニズムはストレージデバイスをクエリーする機能に依存する可能性があるため、クエリーの実行時にデバイスにアクセスできない場合がある可能性があります。これは、デバイスがサーバーシャーシにない場合にファイバーチャネル、iSCSI、または FCoF ストレージデバイスで発生する可能性が高くなります。

カーネルも udev イベントをいつでも送信する可能性があるため、デバイスにアクセスできない場合に /dev/disk/by-*/ リンクが削除される可能性があります。

udev イベントが生成される時点とそのイベントが処理される時点の間で遅延が発生することがあります (大量のデバイスが検出され、ユーザー領域の udevd デーモンによる各デバイスのルールの処理に時間がかかる場合など)。これにより、カーネルがデバイスを検出する時点と /dev/disk/by-*/ の名前が利用できる時点の間で遅延が発生することがあります。

ルールによって呼び出される blkid などの外部プログラムによってデバイスが短期間開放され、他の目的でデバイスにアクセスできなくなる可能性があります。

25.8.3.2. 永続的な命名属性の変更永続的な命名属性の変更

udev 命名属性は永続的ですが、システム再起動で変更されません。以下の永続的な命名属性には、カスタムの値を設定できます。

UUID: ファイルシステム UUID

LABEL: ファイルシステムラベル

UUID と LABEL 属性はファイルシステムに関連するため、使用する必要のあるツールは、そのパーティションのファイルシステムに依存します。

XFS ファイルシステムの UUID または LABEL 属性を変更するには、ファイルシステムのマウントを解除し、xfs_admin ユーティリティを使用して属性を変更します。

# umount /dev/device# xfs_admin [-U new_uuid] [-L new_label] /dev/device# udevadm settle

ext4、ext3、ext2 ファイルシステムの UUID または LABEL 属性を変更するには、tune2fsユーティリティを使用します。

# tune2fs [-U new_uuid] [-L new_label] /dev/device# udevadm settle

new_uuid を、設定したい UUID に置き換えます。例: 1cdfbc07-1c90-4984-b5ec-f61943f5ea50。new_label を backup_data などのラベルに置き換えます。

注記注記


225

注記注記

udev 属性の変更はバックグラウンドで行われ、時間がかかる場合があります。udevadm settle コマンドは変更が完全に登録されるまで待機します。これにより、次のコマンドが新しい属性を正しく利用できるようになります。

また、新しいデバイスを作成した後に、このコマンドを使う必要があります。たとえば、parted ツールを使用してカスタムの PARTUUID または PARTLABEL属性でパーティションを作成する後や、新しいファイルシステムを作成した後が考えられます。

25.9. ストレージデバイスの削除

ストレージデバイス自体へのアクセスを削除する前に、デバイスのデータのバックアップを取ることをお勧めします。次に、I/O をフラッシュしてオペレーティングシステムのデバイスへのすべての参照を削除します (以下を参照)。デバイスでマルチパス機能を使用している場合は、マルチパスの「擬似デバイス」 (「World Wide Identifier (WWID)」) とそのデバイスへのパスを表す各識別子に対してこれを行います。マルチパスデバイスへの 1 つのパスだけを削除してその他のパスをそのまま残しておく場合は「ストレージデバイスまたはパスの追加」に記載されているように、手順はより単純になります。

システムのメモリーが不足している際に I/O をフラッシュするとさらに負荷がかかるため、メモリーが不足している状態でのストレージデバイスの削除は推奨しません。メモリーレベルを判別するには、vmstat 1 100 コマンドを実行します。以下の場合にはデバイスの削除は推奨されません。

100 中 10 を超えるサンプルで空きメモリーがメモリー合計の 5% を下回っている場合 (free を使用してメモリー合計を表示することもできます)

swap 機能がアクティブになっている場合 (vmstat 出力で si と so の欄がゼロ以外の値になっている場合はアクティブです)

デバイスへのすべてのアクセスを削除する一般的な手順は以下になります。

手順手順25.11 デバイスの完全削除デバイスの完全削除

1. デバイスのユーザーをすべて終了させ、必要に応じてデータのバックアップを取ります。

2. umount を使ってデバイスにマウントしているファイルシステムをすべてアンマウントします。

3. デバイスを使用している md および LVM ボリュームからそのデバイスを削除します。デバイスが LVM ボリュームグループのメンバーである場合、pvmove コマンドを使ってデータをデバイスから移動させる必要がある場合があります。次に vgreduce コマンドを使って物理ボリュームを削除し、(オプションで) pvremove コマンドを使ってディスクから LVM のメタデータを削除します。

4. multipath -l コマンドを実行して、multipath デバイスとして設定されたデバイスのリストを見つけます。デバイスがマルチパスデバイスとして設定されている場合は、multipath -f deviceコマンドを実行して、未処理の I/O をフラッシュし、マルチパスデバイスを削除します。

5. 使用したパスに未処理の I/O をフラッシュします。これは、I/O のフラッシュを行うための umount または vgreduce 操作のない raw デバイスに重要です。これは、以下の条件の際に行う必要があります。

デバイスがマルチパスデバイスとして設定されていない場合や、

デバイスがマルチパスデバイスとして設定され、I/O が過去において個別のパスに直接発行されている場合。


226

以下のコマンドを使用して、未処理の I/O をフラッシュします。

# blockdev --flushbufs device

6. /dev/sd、/dev/disk/by-path、または major:minor 番号など、システム上のアプリケーション、スクリプトおよびユーティリティーのデバイスのパスに基づく名前への参照をすべて削除します。これは将来別のデバイスを追加する場合に、それらのデバイスが現在のデバイスと間違われないようにするのに重要です。

7. 最後に SCSI サブシステムからデバイスへの各パスを削除します。これを実行するには、echo 1 > /sys/block/device-name/device/delete コマンドを使用します。ここで device-name は sde などになります。

echo 1 > /sys/class/scsi_device/h:c:t:l/device/delete は上記の変形です。h は HBA 番号、cは HBA 上のチャネル、t は SCSI のターゲット ID、 l は LUN になります。

注記注記

これらのコマンドの古い形式である echo "scsi remove-single-device 0 0 0 0" > /proc/scsi/scsi は廃止予定になっています。

デバイスの device-name、HBA 番号、HBA チャネル、SCSI のターゲット ID、LUN などは、lsscsi、scsi_id、multipath -l、ls -l /dev/disk/by-* など各種のコマンドで確認することができます。

手順25.11「デバイスの完全削除」の実行後は、実行中のシステムからデバイスを物理的にかつ安全に取り除くことができるようになります。実行中に他のデバイスに対する I/O を停止する必要はありません。

物理的なデバイスの除去とその後に SCSI バスの再スキャン (「ストレージの相互接続のスキャン」) を実行して物理的なオペレーティングシステムの状態を更新し、変更を反映するなどの他の手順は推奨されません。これにより、I/O タイムアウトによる遅延が生じ、デバイスが予期せず削除される可能性があります。相互接続の再スキャンを行う必要がある場合には I/O を一時停止してから行ってください(「ストレージの相互接続のスキャン」を参照)。

25.10. ストレージデバイスへのパスの削除

マルチパスを使用するデバイスの 1 つのパスを削除する一般的な手順を以下に示します (デバイスへの他のパスは変更しません)。

手順手順25.12 ストレージデバイスへのパスの削除ストレージデバイスへのパスの削除

1. /dev/sd、/dev/disk/by-path、major:minor 番号など、システム上のアプリケーション、スクリプトおよびユーティリティーのデバイスのパスに基づく名前へのすべての参照を削除します。これは、将来別のデバイスを追加する場合に、これらのデバイスが現在のデバイスと間違われないようにするのに重要です。

2. echo offline > /sys/block/sda/device/state を使ってパスをオフラインにします。

オフラインにすると、このパスのデバイスに送信される後続の I/O がすぐに失敗し始めます。Device-mapper-multipath は、このデバイスへの別のパスを継続して使用します。

3. SCSI サブシステムからパスを削除します。echo 1 > /sys/block/device-name/device/delete


227

3. SCSI サブシステムからパスを削除します。echo 1 > /sys/block/device-name/device/deleteコマンドを使用します。ここで、device-name は sde などになります (手順25.11「デバイスの完全削除」の記載を参照)。

手順25.12「ストレージデバイスへのパスの削除」の実行後に、実行中のシステムからパスを安全に削除することができます。これを実行している間に I/O を停止する必要はありません。device-mapper-multipath は、設定済みのパスのグループ化とフェールオーバーポリシーに応じて、残りのパスへのI/O の再ルーティングを行います。

物理的なデバイスの除去とその後に SCSI バスの再スキャンを実行して物理的なオペレーティングシステムの状態を更新し、変更を反映するなどの他の手順は推奨されません。これにより、I/O タイムアウトによる遅延が生じ、デバイスが予期せず削除される可能性があります。相互接続の再スキャンを行う必要がある場合には I/O を一時停止してから行ってください (「ストレージの相互接続のスキャン」を参照)。

25.11. ストレージデバイスまたはパスの追加

デバイスを追加する際には、システムが新規デバイスに割り当てるパスベースのデバイス名 (例えば、/dev/sd 名、major:minor 番号、および /dev/disk/by-path 名など) がすでに削除されているデバイスで以前に使用されていた可能性があることに注意してください。これまでに使用されたパスベースのデバイス名がある場合、これに対する古い参照がすべて削除されていることを確認してください。そうしないと、新規デバイスが古いデバイスとして誤って認識されてしまう可能性があります。

手順手順25.13 ストレージデバイスまたはパスの追加ストレージデバイスまたはパスの追加

1. ストレージデバイスまたはパスを追加する際の最初のステップは、その新規デバイスへのアクセス、または既存デバイスまでの新規パスへのアクセスを物理的に有効にすることです。これは、ファイバーチャネルまたは iSCSI ストレージサーバーでベンダー固有のコマンドを使用して実行します。これを行う際には、使用するホストに表示される新規ストレージ用の LUN の値に注意してください。ストレージサーバーがファイバーチャネルの場合は、そのストレージサーバーの World Wide Node Name (WWNN) を記録し、ストレージサーバー上のすべてのポートに単一の WWNN が使用されるかどうかを判別します。そうでない場合は、新規の LUN へのアクセスには、各ポートの World Wide Port Name (WWPN) が使用されることに注意してください。

2. 次に、オペレーティングシステムに新規のストレージデバイス、または既存デバイスへのパスを認識させるようにします。使用するコマンドは以下のとおりです。

$ echo "c t l" > /sys/class/scsi_host/hosth/scan

上記のコマンドで、h は　HBA 番号を、c は HBA 上のチャネルを示し、 t は SCSI のターゲット ID を、l は LUN を示します。

注記注記

このコマンドの古い形式である、echo "scsi add-single-device 0 0 0 0" > /proc/scsi/scsi は廃止予定になっています。

a. ファイバーチャネルハードウェアの中には、RAID アレイに新たに作成される LUN が LoopInitialization Protocol (LIP) オペレーションが実行されるまでオペレーティングシステムから確認できないものもあります。確認する方法については「ストレージの相互接続のスキャン」を参照してください。

重要重要


228

重要重要

LIP が必要な場合、このオペレーションを実行している間は I/O を停止する必要があります。

b. 新しい LUN が RAID アレイに追加されているのにもかかわらず、オペレーティングシステムで設定されていない場合、sg3_utils パッケージに含まれている sg_luns コマンドを使用して、LUN のリストがアレイによってエクスポートされていることを確認してください。これにより、RAID アレイに対して SCSI REPORT LUNS コマンドが実行され、現在あるLUN のリストが返されます。

すべてのポートに単一の WWNN を実装するファイバーチャネルストレージサーバーでは、sysfs で WWNN を検索することにより、正しい値の h、c、およびt (HBA 番号、HBAチャネルおよび SCSI ターゲット ID) を判別できます。

例例25.5 正しい正しい h、、c、、t の値を判別の値を判別

たとえば、ストレージサーバーの WWNN が 0x5006016090203181 の場合、以下を使用します。

$ grep 5006016090203181 /sys/class/fc_transport/*/node_name

これにより、以下のような出力が表示されます。

/sys/class/fc_transport/target5:0:2/node_name:0x5006016090203181 /sys/class/fc_transport/target5:0:3/node_name:0x5006016090203181 /sys/class/fc_transport/target6:0:2/node_name:0x5006016090203181 /sys/class/fc_transport/target6:0:3/node_name:0x5006016090203181

上記は、このターゲットに対して 4 つのファイバーチャネルのルート (2 つの単一チャネルHBA のそれぞれが 2 つのストレージポートへのアクセスが設定されている) があることを示しています。LUN の値が 56 であると想定すると、以下のコマンドで最初のパスが設定されます。

$ echo "0 2 56" > /sys/class/scsi_host/host5/scan

新規デバイスへの各パスに対してこれを実行する必要があります。

すべてのポートに対する単一の WWNN を実装しないファイバーチャネルのストレージサーバーでは、sysfs 内でそれぞれの WWPN を検索することによって、正しい HBA 番号、HBAチャネル、および SCSI ターゲット ID を判別することができます。

HBA 番号、HBA チャネル、および SCSI ターゲット ID を判別するための別の方法として、新規デバイスと同じパス上にすでに設定してある別のデバイスを参照する方法があります。これは、lsscsi、scsi_id、multipath -l、および ls -l /dev/disk/by-* などの様々なコマンドで達成できます。この情報、および新規デバイスの LUN 番号は、上記に示してあるように新規デバイスへのパスの探索とその設定に使用することができます。

3. デバイスへすべての SCSI パスを追加した後には、multipath コマンドを実行して、デバイスが正しく設定されているかどうかチェックします。この時点で、デバイスは、md、LVM、mkfs、または mount などに追加することができます。

上述のステップに従うと、デバイスは実行中のシステムに安全に追加することができます。これを実行


229

する際に他のデバイスへの I/O を停止する必要はありません。SCSI バスの再スキャン (またはリセット) を伴う他の手順は、これによりオペレーティングシステムが現在のデバイスの接続状態を反映するように状態の更新を行うため、ストレージの I/O が実行中の場合は推奨されません。

25.12. ストレージの相互接続のスキャン

コマンドによっては、1 つまたは複数の相互接続のリセットやスキャン (または両方) を実行でき、1 つの操作で複数のデバイスを追加および削除する可能性があります。このようなスキャンは、I/O 操作のタイムアウト中に遅延が発生する原因となり、デバイスが予期せず削除される可能性があるため、大きな混乱が生じる可能性があります。Red Hat は、必要な場合のみ必要な場合のみ相互接続のスキャンを使用することを推奨します。ストレージの相互接続をスキャンするときは以下の制約に注意してください。

手順を実行する前に、対象となる相互接続上の I/O はすべて一時停止してフラッシュする必要があります。また、スキャン結果の確認は I/O を再開する前に行ってください。

デバイスの削除と同様、システムがメモリー不足になっている状態での相互接続スキャンは推奨されません。メモリーのレベルを確認するには vmstat 1 100 コマンドを実行します。100 件中 10 件を超えるサンプルでメモリー空き領域がメモリーの合計の 5% 未満である場合は、相互接続のスキャンは推奨されません。また、スワップがアクティブである場合 (vmstat 出力の siとso の欄がゼロ以外の値である場合)、相互接続のスキャンは推奨されません。free コマンドを使用してメモリーの合計容量を表示することもできます。

以下のコマンドを使用すると、ストレージの相互接続をスキャンできます。

echo "1" > /sys/class/fc_host/host/issue_lip

Loop Initialization Protocol (LIP) を実行してから相互接続をスキャンし、現在バス上にあるデバイスを反映するよう SCSI 層を更新します。LIP は基本的にはバスのリセットであり、デバイスの追加や削除が行われます。この手順は、ファイバーチャネルの相互接続で新しい SCSI ターゲットを設定するために必要になります。

issue_lip は非同期の操作であることに注意してください。このコマンドはスキャン全体が終了する前に完了することがあります。/var/log/messages を監視して issue_lip の完了を判断する必要があります。

lpfc、qla2xxx、および bnx2fc ドライバーは issue_lip をサポートします。Red HatEnterprise Linux の各ドライバーによってサポートされる API 機能については表25.1「ファイバーチャネル API の機能」を参照してください。

/usr/bin/rescan-scsi-bus.sh

/usr/bin/rescan-scsi-bus.sh スクリプトは Red Hat Enterprise Linux 5.4 で導入されました。デフォルトではシステム上のすべての SCSI バスがこのスクリプトによってスキャンされ、バス上の新しいデバイスを反映するよう SCSI レイヤーが更新されます。このスクリプトは、デバイスの削除や LIPの実行を可能にする追加のオプションも提供します。既知の問題を含むこのスクリプトの詳細は「rescan-scsi-bus.sh による論理ユニットの追加と削除」を参照してください。

echo "- - -" > /sys/class/scsi_host/hosth/scan

このコマンドは、ストレージのデバイスまたはパスを追加する方法として「ストレージデバイスまたはパスの追加」で説明しているコマンドと同じです。ただし、この場合にはチャネル番号、SCSIターゲット ID、および LUN の値がワイルドカードになります。識別子とワイルドカードのあらゆる組み合わせが可能であるため、必要に応じて対象を絞り込むことも広げることも可能です。この手順では LUN を追加しますが、その削除は行いません。

modprobe --remove driver-name, modprobe driver-name

modprobe --remove driver-name コマンドの実行後に modprobe driver-name コマンドを実行す


230

ると、ドライバーによって制御されるすべての相互接続の状態が完全に再初期化されます。これは強硬手段ではありますが、場合によっては適切な処置であることがあります。たとえば、このコマンドを使用すると異なるモジュールパラメーターの値でドライバーを再起動することができます。

25.13. ISCSI 検出の設定

デフォルトの iSCSI 設定ファイルは /etc/iscsi/iscsid.conf です。このファイルには iscsid と iscsiadmによって使用される iSCSI の設定が含まれます。

ターゲットの検出時に、iscsiadm ツールは /etc/iscsi/iscsid.conf 内の設定を使用して 2 種類の記録を作成します。

ノードの記録ノードの記録 - /var/lib/iscsi/nodes

ターゲットへのログイン時に iscsiadm によってこのファイル内の設定が使用されます。

検出の記録検出の記録 - /var/lib/iscsi/discovery_type

同じターゲットに対して検出を行う場合、iscsiadm によってこのファイル内の設定が使用されます。

検出に別の設定を使用する前に、現在の検出記録 (例: /var/lib/iscsi/discovery_type) を削除します。これを行うには、以下のコマンドを使用します。[5]

# iscsiadm -m discovery -t discovery_type -p target_IP:port -o delete

ここでは、discovery_type は sendtargets、isns、fw のいずれかに設定できます。

検出の各種タイプについては、iscsiadm(8) man ページの『DISCOVERY TYPES』のセクションを参照してください。

検出記録の設定を再設定する方法は 2 通りあります。

検出を行う前に /etc/iscsi/iscsid.conf ファイルを直接編集します。検出の設定は、プレフィックス discovery を使用します。それらを表示するには、以下を実行します。

# iscsiadm -m discovery -t discovery_type -p target_IP:port

または、iscsiadm を使って以下のように検出記録の設定を直接変更することもできます。

# iscsiadm -m discovery -t discovery_type -p target_IP:port -o update -n setting -v %value

利用可能な setting オプションや有効な value オプションについては、iscsiadm(8) man ページを参照してください。

検出の設定を行うと、その後のターゲット検出の試行からは新しい設定が使用されるようになります。新しい iSCSI ターゲットのスキャン方法については、「iSCSI 相互接続のスキャン」を参照してください。

iSCSI ターゲットの検出を設定する詳細な方法は、iscsiadm と iscsid の各 man ページを参照してください。/etc/iscsi/iscsid.conf ファイルには適切な設定構文に関するサンプルも複数含まれています。

25.14. ISCSI オフロードとインターフェースバインディングの設定


231

本章では、ソフトウェア iSCSI を使用する際にセッションを NIC ポートに結合させるための iSCSI インターフェースを設定する方法について説明します。また、オフロード機能に対応するネットワークデバイスでインターフェースを使用できるよう設定を行う方法についても説明しています。

iSCSI が結合に使用するパスや NIC を指定できるようネットワークサブシステムを設定することができます。たとえば、ポータルと NIC が別々のサブネットにセットアップされている場合、結合用の iSCSIインターフェースを手作業で設定する必要はありません。

結合用の iSCSI インターフェースを設定する前に、まず次のコマンドを実行します。

$ ping -I ethX target_IP

ping が失敗する場合はセッションを NIC に結合することはできません。このような場合にはネットワーク設定をまず確認してください。

25.14.1. 利用可能な iface 設定の表示

iSCSI オフロードとインターフェースバインディングは、以下の iSCSI イニシエーター実装でサポートされます。

ソフトウェアソフトウェア iSCSI

このスタックはセッションごとに iSCSI ホストインスタンス (scsi_host) を割り当てます。接続は 1セッションに 1 接続です。結果として /sys/class_scsi_host と /proc/scsi は、ログインしている各接続/セッションに対して 1 つの scsi_host を報告します。

オフロードオフロード iSCSI

このスタックは各 PCI デバイスに対して scsi_host を割り当てます。このため、ホストのバスアダプター上の各ポートは、HBA ポートごとに別々の scsi_host を持つ異なった PCI デバイスとして表示されます。

いずれのタイプのイニシエーター実装を管理する場合も iscsiadm は iface 構造を使用します。この構造では、複数のセッションの結合に使用する各 HBA ポート、ソフトウェア iSCSI、またはネットワークデバイス (ethX) などの /var/lib/iscsi/ifaces に iface の設定を記載しておく必要があります。

利用可能な iface の設定を表示するには、iscsiadm -m iface を実行します。次のような形式で iface の情報が表示されます。

iface_name transport_name,hardware_address,ip_address,net_ifacename,initiator_name

それぞれの値または設定については次の表を参照してください。

表表25.2 iface の設定の設定

設定設定説明説明

iface_name iface の設定名

transport_name ドライバー名

hardware_address MAC アドレス


232

ip_address このポートに使用する IP アドレス

net_iface_name ソフトウェア iSCSI セッションの vlan またはエイリアス結合に使用する名前 (iSCSI オフロードの場合、再起動するとこの値は維持されないため net_iface_name は <empty> になります)

initiator_name /etc/iscsi/initiatorname.iscsi で定義されているイニシエーターのデフォルト名を無効にする場合に使用

設定設定説明説明

例例25.6 iscsiadm -m iface コマンドの出力例コマンドの出力例

以下に iscsiadm -m iface コマンドの出力例を示します。

iface0 qla4xxx,00:c0:dd:08:63:e8,20.15.0.7,default,iqn.2005-06.com.redhat:madmaxiface1 qla4xxx,00:c0:dd:08:63:ea,20.15.0.9,default,iqn.2005-06.com.redhat:madmax

ソフトウェア iSCSI の場合、iface 設定には固有の名前を持たせなければなりません (65 文字未満)。オフロード機能に対応するネットワークデバイスの iface_name は transport_name.hardware_name の形式で表示されます。

例例25.7 Chelsio ネットワークカードを使用する場合のネットワークカードを使用する場合の iscsiadm -m iface の出力の出力

たとえば、Chelsio ネットワークカードを使用しているシステムで iscsiadm -m iface コマンドを実行した場合の出力例は以下のようになります。

default tcp,<empty>,<empty>,<empty>,<empty>iser iser,<empty>,<empty>,<empty>,<empty>cxgb3i.00:07:43:05:97:07 cxgb3i,00:07:43:05:97:07,<empty>,<empty>,<empty>

特定の iface 設定をさらにわかりやすい方法で表示することもできます。これを実行するには、-I iface_name オプションを使用します。これにより、次のような形式で設定が表示されます。

iface.setting = value

例例25.8 Chelsio 集中型ネットワークアダプターによる集中型ネットワークアダプターによる iface 設定を使用設定を使用

前述の例と同じ Chelsio 統合型ネットワークアダプターによる iface 設定は次のように表示されます(iscsiadm -m iface -I cxgb3i.00:07:43:05:97:07) 。

# BEGIN RECORD 2.0-871iface.iscsi_ifacename = cxgb3i.00:07:43:05:97:07iface.net_ifacename = <empty>iface.ipaddress = <empty>iface.hwaddress = 00:07:43:05:97:07


233

iface.transport_name = cxgb3iiface.initiatorname = <empty># END RECORD

25.14.2. ソフトウェア iSCSI 用 iface の設定

前述のように、セッションをバインドするために使用される各ネットワークオブジェクトにはiface の設定が必要になります。

その前に

ソフトウェア iSCSI 用の iface 設定を作成するには、以下のコマンドを実行します。

# iscsiadm -m iface -I iface_name --op=new

これは、指定された iface_name を使用して、新規の空の空の iface 設定を作成します。既存の iface 設定が、すでに同じ iface_name を持っている場合は、それが新規の空の設定で上書きされます。

iface 構成の特定の設定を行うには、以下のコマンドを使用します。

# iscsiadm -m iface -I iface_name --op=update -n iface.setting -v hw_address

例例25.9 iface0 のの MAC アドレスの設定アドレスの設定

たとえば、iface0 の MAC アドレス ( hardware_address) を 00:0F:1F:92:6B:BF に設定するには、以下を実行します。

# iscsiadm -m iface -I iface0 --op=update -n iface.hwaddress -v 00:0F:1F:92:6B:BF

警告警告

default または iser を iface の名前として使用しないでください。これらのストリングは後方互換性について iscsiadm で使用される特別な値です。default または iser という名前の手動で作成された iface 構成は、いずれも後方互換性を無効にします。

25.14.3. iSCSI Offload 用 iface の設定

デフォルトでは、iscsiadm は各ポートの iface 設定を作成します。利用可能な iface 設定を表示するには、ソフトウェア iSCSI で使用する同じコマンドを使用します (例: iscsiadm -m iface)。

iSCSI オフロードにネットワークカードの iface に使用する前に、オフロードインターフェイスの iface.ipaddress 値を、インターフェースが使用するイニシエーター IP アドレスに設定します。

be2iscsi ドライバーを使用するデバイスについては、この IP アドレスは BIOS のセットアップ画面で設定します。


234

その他すべてのデバイスの iface の IP アドレスを設定するには、以下を使用します。

# iscsiadm -m iface -I iface_name -o update -n iface.ipaddress -v initiator_ip_address

例例25.10 Chelsio カードのカードの iface IP アドレスの設定アドレスの設定

たとえば、cxgb3i.00:07:43:05:97:07 という iface 名のカードを使用するときに iface IP アドレスを20.15.0.66 に設定するには、以下を使用します。

# iscsiadm -m iface -I cxgb3i.00:07:43:05:97:07 -o update -n iface.ipaddress -v 20.15.0.66

25.14.4. iface のポータルに対する結合/結合解除

相互接続のスキャンに iscsiadm を使用すると、iscsiadm ユーティリティーは /var/lib/iscsi/ifaces 内の各 iface 構成の iface.transport 設定をまず最初にチェックします。次にこの iface.transport 設定が tcp になっている iface 構成に検出したポータルを結合します。

この動作は互換性を目的として実装されました。この動作を無効にする場合は、次のように -I iface_name を使って iface に結合させるポータルを指定します。

# iscsiadm -m discovery -t st -p target_IP:port -I iface_name -P 1[5]

デフォルトでは、iscsiadm は、オフロード機能を使用する iface 構成にはポータルを自動結合しません。オフロード機能を使用する iface 構成の場合、iface.transport に tcp が設定されることはないためです。このため、iface 構成には、検出されたポータルに手作業で結合する必要があります。

既存の iface にポータルを一切結合しないようにすることもできます。以下のように iface_name に default を使用します。

# iscsiadm -m discovery -t st -p IP:port -I default -P 1

ターゲットと iface 間の結合を削除する場合は次を使用します。

# iscsiadm -m node -targetname proper_target_name -I iface0 --op=delete[6]

特定の iface の結合をすべて削除する場合は次を使用します。

# iscsiadm -m node -I iface_name --op=delete

特定のポータルに対する結合を削除する場合は次を使用します。

# iscsiadm -m node -p IP:port -I iface_name --op=delete

注記注記

/var/lib/iscsi/iface 内に iface 構成が定義されておらず、-I オプションが使用されていない場合は、iscsiadm により、ネットワークサブシステムが特定ポータルが使用するデバイスを決定できることになります。


235

25.15. ISCSI 相互接続のスキャン

iSCSI では、新しいストレージが追加されたことを示す iSCSI 非同期イベントがターゲットによって送信されると、スキャンが自動的に行われます。

ただし、ターゲットが iSCSI 非同期イベントを送信しない場合は iscsiadm ユーティリティーを使って手作業でスキャンを行う必要があります。スキャンを行う前に、適切な --targetname --portal の値をまず取得する必要があります。ご使用のデバイスモデルが 1 ターゲットに 1 論理ユニットとポータルのみをサポートしている場合は、以下のように iscsiadm を使ってホストに対し sendtargets コマンドを発行します。

# iscsiadm -m discovery -t sendtargets -p target_IP:port[5]

出力は以下のような形式になります。

target_IP:port,target_portal_group_tag proper_target_name

例例25.11 iscsiadm を使用したを使用した sendtargets コマンドの発行コマンドの発行

たとえば、proper_target_name が iqn.1992-08.com.netapp:sn.33615311 で target_IP:port が 10.15.85.19:3260 になるターゲットでは出力は次のようになります。

10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.3361531110.15.85.19:3260,3 iqn.1992-08.com.netapp:sn.33615311

上記の例では、ターゲットにはポータルが 2 つあり、 target_ip:port にはそれぞれ 10.15.84.19:3260 と 10.15.85.19:3260 を使用しています。

各セッションに使用される iface 構成を表示させる場合は -P 1 オプションを追加します。このオプションにより、セッション情報が以下のようにツリー形式で表示されます。

Target: proper_target_name Portal: target_IP:port,target_portal_group_tag Iface Name: iface_name

例例25.12 iface 構成の表示構成の表示

たとえば、iscsiadm -m discovery -t sendtargets -p 10.15.85.19:3260 -P 1 の場合、出力は以下のようになります。

Target: iqn.1992-08.com.netapp:sn.33615311 Portal: 10.15.84.19:3260,2 Iface Name: iface2 Portal: 10.15.85.19:3260,3 Iface Name: iface2

上記から、ターゲットの iqn.1992-08.com.netapp:sn.33615311 はその iface に iface2 を使用していることがわかります。

デバイスモデルによっては、1 つのターゲットに複数の論理ユニットやポータルがあるものがありま


236

デバイスモデルによっては、1 つのターゲットに複数の論理ユニットやポータルがあるものがあります。この場合、最初に sendtargets コマンドをホストに発行して、ターゲット上で新しいポータルを探します。次に既存のセッションを再スキャンするのに以下を使用します。

# iscsiadm -m session --rescan

セッションの SID 値を以下のようにして指定することで特定セッションの再スキャンを実行することもできます。

# iscsiadm -m session -r SID --rescan[7]

複数のターゲットに対応するデバイスの場合、sendtargets コマンドをホストに実行し、各ターゲット各ターゲットの新しいポータルを探す必要があります。--rescan オプションを使用して既存のセッションを再スキャンし、既存セッションの新しい論理ユニットを検索します。

重要重要

--targetname と --portal の値の取得に使用する sendtargets コマンドにより /var/lib/iscsi/nodes データベースのコンテンツが上書きされます。このデータベースは /etc/iscsi/iscsid.conf 内の設定を使って再設定されることになります。ただし、セッションが現在ログイン中で使用されている場合は再設定は行われません。

新しいターゲットやポータルの追加や古いターゲットやポータルの削除を安全に行うには、-o new オプションと -o delete オプションをそれぞれ使用します。たとえば、新しいターゲットやポータルを /var/lib/iscsi/nodes を上書きせずに追加する場合は次のコマンドを使用します。

iscsiadm -m discovery -t st -p target_IP -o new

検索中にターゲットが表示しなかった /var/lib/iscsi/nodes のエントリーを削除するには、次を使用します。

iscsiadm -m discovery -t st -p target_IP -o delete

次のようにして、両方のタスクを同時に行うこともできます。

iscsiadm -m discovery -t st -p target_IP -o delete -o new

sendtargets コマンドにより次のような出力が生成されます。

ip:port,target_portal_group_tag proper_target_name

例例25.13 sendtargets コマンドの出力コマンドの出力

たとえば、ターゲット、論理ユニット、およびポータルが 1 つで target_name が equallogic-iscsi1になるデバイスの場合、出力は次のようになります。

10.16.41.155:3260,0 iqn.2001-05.com.equallogic:6-8a0900-ac3fe0101-63aff113e344a4a2-dl585-03-1


237

proper_target_name と ip:port,target_portal_group_tag は「iSCSI API」にある同じ名前の値と同一になることに注意してください。

これで iSCSI デバイスの手作業によるスキャンを行うために必要な --targetname と --portal の適切な値を確認できました。次のコマンドを実行します。

# iscsiadm --mode node --targetname proper_target_name --portal ip:port,target_portal_group_tag \ --login [8]

例例25.14 iscsiadm コマンドコマンド

前述の例を使用すると (proper_target_name は equallogic-iscsi1)、このコマンドは以下のようになります。

# iscsiadm --mode node --targetname \ iqn.2001-05.com.equallogic:6-8a0900-ac3fe0101-

63aff113e344a4a2-dl585-03-1 \ --portal 10.16.41.155:3260,0 --login[8]

25.16. ISCSI ターゲットへのログイン

「iSCSI」に記載されているように、ターゲットの検出やログインを行うには iSCSI サービスを実行していなければなりません。iSCSI サービスを起動するには次を実行します。

# systemctl start iscsi

このコマンドを実行すると、iSCSI の init スクリプトは node.startup の設定が automatic に設定されているターゲットに自動的にログインします。これは、すべてのターゲットの node.startup 設定のデフォルト値になります。

ターゲットへの自動ログインを行わないようにするには、node.startup の設定を manual にします。これを実行するには、次のコマンドを実行します。

# iscsiadm -m node --targetname proper_target_name -p target_IP:port -o update -n node.startup -v manual

記録全体を削除することによっても自動ログインを回避できます。これを実行するには、次を実行します。

# iscsiadm -m node --targetname proper_target_name -p target_IP:port -o delete

ネットワーク上の iSCSI デバイスからファイルシステムを自動的にマウントするには、/etc/fstab にマウント用のパーティションエントリーを追加して _netdev オプションを付けます。たとえば、起動時に iSCSI デバイスの sdb を /mount/iscsi に自動的にマウントする場合は、次の行を /etc/fstab に追加します。

/dev/sdb /mnt/iscsi ext3 _netdev 0 0

iSCSI ターゲットに手動でログインする場合は次のコマンドを使用します。

# iscsiadm -m node --targetname proper_target_name -p target_IP:port -l


238

注記注記

proper_target_name と target_IP:port はターゲットのフルネームと IP アドレス/ポートの組み合わせを参照します。詳細については、「iSCSI API」と「iSCSI 相互接続のスキャン」を参照してください。

25.17. オンライン論理ユニットのサイズ変更

ほとんどの場合、オンラインの論理ユニットのサイズを完全に変更するには 2 つの作業が必要になります。論理ユニット自体のサイズを変更する作業、そしてそのサイズ変更を該当するマルチパスデバイスに反映させる作業です (システムでマルチパス機能を有効にしている場合)。

オンラインの論理ユニットのサイズ変更は、ストレージデバイスのアレイ管理インターフェースから論理ユニットのサイズを変更するところから始めます。手順はアレイによって異なるため、詳細についてはストレージアレイの製造元が提供しているドキュメントを参照してください。

注記注記

オンラインのファイルシステムのサイズを変更する場合には、パーティション設定しているデバイス上にはそのファイルシステムを配置させないようにしてください。

25.17.1. ファイバーチャネル論理ユニットのサイズ変更

オンライン論理ユニットのサイズを変更したら、システムによって最新のサイズが検出されるよう論理ユニットの再スキャンを行います。ファイバーチャネルの論理ユニットの場合なら次のコマンドを使用します。

$ echo 1 > /sys/block/sdX/device/rescan

重要重要

マルチパス機能を使用しているシステムのファイバーチャネル論理ユニットを再スキャンする場合は、マルチパス設定されている論理ユニットのパスを表す各 sd デバイス(sd1、 sd2 など) に対して前述のコマンドを実行します。どのデバイスがマルチパス論理ユニットのパスであるかを判断するには、multipath -ll を使用して、サイズ変更した論理ユニットに一致するエントリーを探します。エントリーの WWID を参照すると、サイズ変更した論理ユニットに一致するエントリーを簡単に見つけることができます。

25.17.2. iSCSI 論理ユニットのサイズ変更

オンライン論理ユニットのサイズを変更したら、システムによって最新のサイズが検出されるよう論理ユニットの再スキャンを行います。iSCSI デバイスの論理ユニットの場合なら次のコマンドを使用します。

# iscsiadm -m node --targetname target_name -R[5]

target_name はデバイスがある場所のターゲット名にします。

注記注記


239

注記注記

次のコマンドを使っても iSCSI 論理ユニットを再スキャンすることができます。

# iscsiadm -m node -R -I interface

interface はサイズ変更した論理ユニットに該当するインターフェース名です (iface0 など)。

上記のコマンドは、echo "- - -" > /sys/class/scsi_host/host/scan コマンドと同じ動作で新しいデバイスのスキャンを行います (「iSCSI 相互接続のスキャン」を参照)。

上記のコマンドは、 echo 1 > /sys/block/sdX/device/rescan コマンドと同じ動作で新しい論理ユニットまたは変更した論理ユニットの再スキャンを行います。ファイバーチャネルの論理ユニットを再スキャンしたときに使用したコマンドと同じです。

25.17.3. マルチパスデバイスのサイズ更新

マルチパス機能がシステムで有効になっている場合は、論理ユニットサイズでの変更を論理ユニットの該当するマルチパスデバイスに対しても反映させる必要があります (論理ユニットのサイズ変更論理ユニットのサイズ変更後後)。multipathd を使って変更を反映させることができます。まず、 service multipathd status を使用して multipathd が実行中であることを確認します。 multipathd が正常に動作していることを確認したら、次のコマンドを実行します。

# multipathd -k"resize map multipath_device"

multipath_device の変数は /dev/mapper 内にある該当デバイスのマルチパスエントリーになります。システム上でマルチパス機能がどのように設定されているかによって multipath_device の形式は次の2 種類のいずれかになります。

mpathX: X は使用デバイスの該当エントリーになります (mpath0 など)

WWID: 3600508b400105e210000900000490000 などです

サイズ変更した論理ユニットに該当するマルチパスエントリーの確認には multipath -ll を実行します。システム内に既存しているマルチパスの全エントリ一覧および該当デバイスのメジャー番号とマイナー番号が表示されます。

重要重要

multipath_device に対してキュー待ちしているコマンドがある場合には、 multipathd -k"resize map multipath_device" を使用しないでください。つまり、 no_path_retryパラメーター (/etc/multipath.conf 内) が "queue" に設定されていて、デバイスへのアクティブなパスがない場合には、このコマンドを使用しないでください。

マルチパスの詳細は、「Red Hat Enterprise Linux 7 DM マルチパス」ガイドを参照してください。

25.17.4. オンライン論理ユニットの Read/Write ステータスの変更

ストレージデバイスによっては、ユーザーが Read/Write (R/W) から Read-Only (RO) へ、RO からR/W へデバイスのステータスを変更できるものもあります。通常これは、ストレージデバイスの管理インターフェースから行います。オペレーティングシステムは、変更があっても、デバイスのステータス


240


の表示を自動更新しません。本章に説明されている手順に従い、オペレーティングシステムがこの変更を認識するようにします。

以下のコマンドを実行して、デバイスの R/W ステータスに関するオペレーティングシステムの現在のビューを確認します。この際 XYZ は任意のデバイス識別子に置き換えてください。

# blockdev --getro /dev/sdXYZ

以下のコマンドは、Red Hat Enterprise Linux 7 でも利用できます。

# cat /sys/block/sdXYZ/ro 1 = read-only 0 = read-write

マルチパスを使用する場合は、multipath -ll コマンドからの出力の2行目にある ro または rwフィールドを参照してください。例えば、以下のようになります。

36001438005deb4710000500000640000 dm-8 GZ,GZ500[size=20G][features=0][hwhandler=0][ro]\_ round-robin 0 [prio=200][active] \_ 6:0:4:1 sdax 67:16 [active][ready] \_ 6:0:5:1 sday 67:32 [active][ready]\_ round-robin 0 [prio=40][enabled] \_ 6:0:6:1 sdaz 67:48 [active][ready] \_ 6:0:7:1 sdba 67:64 [active][ready]

R/W ステータスを変更するには、以下の手順に従います。

手順手順25.14 R/W ステータスの変更ステータスの変更

1. RO から R/W へデバイスを移動するには、手順 2 を参照してください。

R/W から RO へデバイスを移動するには、これ以上書き込みがされないようにします。アプリケーションを停止するか、適切なアプリケーション固有のアクションを使用して、書き込みが行われないように設定します。

見処理の書き込み I/O がすべて完了しているか、以下のコマンドで確認します。

# blockdev --flushbufs /dev/device

任意の識別子で device を置き換えます。デバイスマッパーマルチパスは、これが dev/mapperのエントリーになります。例えば、/dev/mapper/mpath3 などです。

2. ストレージデバイスの管理インターフェースを使用して、R/W から RO、または RO から R/Wへステータスを変更します。この手順は、アレイごとに異なります。詳細情報は、該当のストレージアレイのベンダーが出している文書を参照してください。

3. デバイスを再度スキャンして、デバイスの R/W ステータスに関するオペレーティングシステムのビューを更新します。デバイスマッパーマルチパスを使用している場合、デバイスへのパスごとにこの再スキャンを行ってから、デバイスマップをリロードするようマルチパスに指示を出すコマンドを発行します。

このプロセスについては、「論理ユニットの再スキャン」で詳しく説明されています。

25.17.4.1. 論理ユニットの再スキャン論理ユニットの再スキャン

「オンライン論理ユニットの Read/Write ステータスの変更」の記載の通り、オンライン論理ユニット


241

「オンライン論理ユニットの Read/Write ステータスの変更」の記載の通り、オンライン論理ユニットの Read/Write ステータスを変更後、以下のコマンドを使用して、ステータスの更新をシステムが検出できるように論理ユニットを再スキャンします。

# echo 1 > /sys/block/sdX/device/rescan

マルチパス機能を使用するシステムで論理ユニットを再スキャンするには、マルチパス化された論理ユニットに対するパスを指す sd デバイスごとに上記のコマンドを実行してください。たとえば、sd1、sd2、その他の sd デバイスにコマンドを実行します。どのデバイスがマルチパスユニットへのパスとなっているか判断するには、multipath -11 を使用して、変更される論理ユニットと同じエントリーを検索します。

例例25.15 multipath -11 コマンドの使用コマンドの使用

たとえば、上記の multipath -11 は WWID 36001438005deb4710000500000640000 の LUN のパスを表示します。この場合、以下を入力してください。

# echo 1 > /sys/block/sdax/device/rescan# echo 1 > /sys/block/sday/device/rescan# echo 1 > /sys/block/sdaz/device/rescan# echo 1 > /sys/block/sdba/device/rescan

25.17.4.2. マルチパスデバイスのマルチパスデバイスの R/W ステータスの更新ステータスの更新

マルチパス機能が有効な場合、論理ユニットを再スキャンした後、ステータスの変更を論理ユニットに該当するマルチパスデバイスで反映させる必要があります。以下のコマンドで、マルチパスデバイスマップをリロードして、変更を反映します。

# multipath -r

次に、multipath -11 コマンドを使用して変更を確定します。

25.17.4.3. 資料資料

追加の情報は、Red Hat ナレッジベースで確認いただけます。ナレッジベースへアクセスするには、https://www.redhat.com/wapps/sso/login.html?redirect=https://access.redhat.com/knowledge/へ移動してログインします。次に、https://access.redhat.com/kb/docs/DOC-32850 の記事にアクセスしてください。

25.18. RESCAN-SCSI-BUS.SH による論理ユニットの追加と削除

sg3_utils パッケージは、必要に応じてホストの論理ユニット設定を自動的に更新する rescan-scsi-bus.sh スクリプトを提供します (デバイスがシステムに追加された後)。rescan-scsi-bus.sh スクリプトはまた、サポートされているデバイス上で issue_lip も実行できます。このスクリプトの使用法の詳細については、rescan-scsi-bus.sh --help を参照してください。

sg3_utils パッケージをインストールするには、yum install sg3_utils を実行します。

rescan-scsi-bus.sh に関する既知の問題

rescan-scsi-bus.sh スクリプトを使用する際には、以下の既知の問題に注意してください。

rescan-scsi-bus.sh が正常に機能するためには、最初にマップされる論理ユニットは LUN0 で


242

https://www.redhat.com/wapps/sso/login.html?redirect=https://access.redhat.com/knowledge/

https://access.redhat.com/kb/docs/DOC-32850

rescan-scsi-bus.sh が正常に機能するためには、最初にマップされる論理ユニットは LUN0 でなければなりません。最初にマップされた論理ユニットが LUN0 である場合にのみ、rescan-scsi-bus.sh はこれを検出できます。--nooptscan オプションを使用した場合でも、rescan-scsi-bus.sh は、最初にマップされた論理ユニットを検出しない限り、他の論理ユニットをスキャンできません。

論理ユニットが初めてマップされる場合には、競合状態により、rescan-scsi-bus.sh を 2 回実行することが必要になります。最初のスキャンでは、rescan-scsi-bus.sh は単に LUN0 のみを追加するだけです。他のすべての論理ユニットは 2 回目のスキャンで追加されます。

--remove オプションが使用されると、rescan-scsi-bus.sh スクリプト内のバグが、論理ユニット内の変化を認識するための機能を誤った方法で実行します。

rescan-scsi-bus.sh スクリプトは、ISCSI の論理ユニットの削除を認識しません。

25.19. リンク切れ動作の修正

本セクションでは、ファイバーチャネルまたは iSCSI のプロトコルのいずれかを使用しているデバイスに関するリンク切れの動作を修正する方法について説明します。

25.19.1. ファイバーチャネル

ドライバーがトランスポートの dev_loss_tmo コールバックを実装している場合、トランスポートの問題が検出されるとリンクを経由したデバイスへのアクセス試行がブロックされます。デバイスがブロックされているかどうかを確認するには次のコマンドを実行します。

$ cat /sys/block/device/device/state

デバイスがブロックされている場合は blocked が返されます。通常通りにデバイスが稼働している場合は running が返されます。

手順手順25.15 リモートポートの状態判断リモートポートの状態判断

1. リモートポートの状態を判別するには、次のコマンドを実行します。

$ cat/sys/class/fc_remote_port/rport-H:B:R/port_state

2. リモートポート (およびこのポートを介してアクセスされるデバイス) がブロックされている場合は、このコマンドにより Blocked が返されます。通常通りにリモートポートが稼働している場合は Online が返されます。

3. dev_loss_tmo 秒以内に問題が解決されない場合、リモートポートおよびデバイスのブロックが解除され、そのデバイス上で実行されているすべての I/O (およびそのデバイスに送信される新規 I/O すべて) が失敗します。

手順手順25.16 dev_loss_tmo の変更の変更

dev_loss_tmo の値を変更する場合は、ファイルに対して必要な値の echo を実行します。たとえば、dev_loss_tmo を 30 秒に設定するには、以下を実行します。

$ echo 30 >/sys/class/fc_remote_port/rport-H:B:R/dev_loss_tmo


243

dev_loss_tmo の詳細は、「ファイバーチャネル API」を参照してください。

リンク切れが dev_loss_tmo の値を超える場合、scsi_device および sdN デバイスは削除されます。通常、ファイバーチャネルのクラスはデバイスをそのままの状態にします。すなわち、/dev/sdxは、/dev/sdx のままになります。これは、ターゲットバインディングがファイバーチャネルドライバーによって保存されるためであり、ターゲットポートが返されると、SCSI アドレスが忠実に再作成されます。ただし、これは常に保証される訳ではなく、LUN のストレージ内のボックス設定に追加の変更が行なわれない場合にのみ、sdx は復元されます。

25.19.2. dm-multipath を実装している iSCSI の設定

dm-multipath を実装している場合、コマンドをマルチパスレイヤーにただちに委ねるよう iSCSI タイマーを設定することをお勧めします。次の行を /etc/multipath.conf ファイル内にある device { の下にネストさせます。

features "1 queue_if_no_path"

これにより、dm-multipath 層ですべてのパスが失敗すると I/O エラーが再試行され、キューに入れられます。

SAN に問題がないことを監視するため iSCSI タイマーをさらに調整する必要性が生じる場合があります。設定できる iSCSI タイマーには NOP-Out の間隔、 NOP-Out のタイムアウトおよび replacement_timeout などがあります。これらについては次のセクションで説明します。

25.19.2.1. NOP-Out インターバルインターバル/タイムアウトタイムアウト

SAN に関する問題の監視を支援するために、iSCSI レイヤーは各ターゲットに NOP-Out 要求を送信します。NOP-Out 要求がタイムアウトになる場合には、iSCSI レイヤーは実行中のコマンドを停止して、SCSI レイヤーに対し、可能な時点にそれらのコマンドを再度キューに入れるように指示することで対応します。

dm-multipath が使用されている場合、SCSI レイヤーが実行中のコマンドを停止して、それらのコマンドをマルチパスレイヤーに委ねます。次に、マルチパスレイヤーは別のパス上でこれらのコマンドを再試行します。dm-multipath が使用されていないいない場合には、これらのコマンドは 5 回まで再試行されてから完全に停止します。

NOP-Out 要求のインターバル (間隔) はデフォルトで 10秒です。これを調節するには、/etc/iscsi/iscsid.conf を開いて以下の行を編集します。

node.conn[0].timeo.noop_out_interval = [interval value]

インターバルが設定されると、iSCSI レイヤーはその [interval value] 秒ごとに各ターゲットに対してNOP-Out 要求を送信します。

デフォルトでは、NOP-Out 要求は 10 秒[9] でタイムアウトになります。これを調節するには、/etc/iscsi/iscsid.conf を開いて以下の行を編集します。

node.conn[0].timeo.noop_out_timeout = [timeout value]

これは、iSCSI レイヤーが [timeout value] 秒後に NOP-Out 要求をタイムアウトさせるように設定します。

SCSI エラーハンドラーエラーハンドラー


244

SCSI エラーハンドラーが実行中の場合、あるパス上で実行中のコマンドは、そのパス上で NOP-Out要求がタイムアウトになってもすぐには停止しません。その代わりに、これらのコマンドは replacement_timeout 秒の経過後経過後に停止します。replacement_timeout の詳細は、「replacement_timeout」を参照してください。

SCSI エラーハンドラーが実行中であるかどうかを確認するには、以下を実行します。


25.19.2.2. replacement_timeout

replacement_timeout は、iSCSI レイヤーが実行中のコマンドを停止する前にタイムアウトになっているパス/セッションが再確立するまで待機する時間の長さを制御します。デフォルトの replacement_timeout 値は 120 秒です。

replacement_timeout を調整するには、/etc/iscsi/iscsid.conf を開いて以下の行を編集します。

node.session.timeo.replacement_timeout = [replacement_timeout]

/etc/multipath.conf 内の 1 queue_if_no_path オプションは、コマンドをマルチパスレイヤーにすぐに委ねるように iSCSI タイマーを設定します (「dm-multipath を実装している iSCSI の設定」を参照)。この設定は、I/O エラーがアプリケーションに伝搬することを防ぐので、replacement_timeout は 15秒から 20 秒に設定するのが適切でしょう。

replacement_timeout を低めに設定すると、(NOP-Out タイムアウト状態で) I/O は新しいパスにすぐに送信され、実行されます。その際に iSCSI レイヤーは停止したパス/セッションを再確立するよう試行します。すべてのパスがタイムアウトになるとマルチパスとデバイスマッパーレイヤーは、/etc/iscsi/iscsid.conf ではなく、/etc/multipath.conf の設定に基づいて内部的に I/O をキューに入れます。

重要重要

検討しているポイントがフェイルオーバーのスピードかセキュリティーかなどを問わず、replacement_timeout の推奨される値は、他の要素によって決まります。これらの要素には、ネットワーク、ターゲット、およびシステムのワークロードなどが含まれます。そのため、replacements_timeout に対する新たな設定を加える場合、これを徹底的にテストしてからミッションクリティカルなシステムに適用することが推奨されます。

25.19.3. iSCSI のルート

iSCSI ディスクから直接ルートパーティションにアクセスする場合は、iSCSI タイマーを設定し、iSCSIレイヤーからパスまたはセッションの再確立が複数回試行されるようにします。また、コマンドが即座に SCSI レイヤーのキューに置かれてはなりません。これは dm-multipath を実装する場合に行う作業とは逆になります。

まず NOP-Out を無効にします。NOP-Out の間隔とタイムアウトをいずれもゼロにすると NOP-Outは無効になります。これを設定するには、/etc/iscsi/iscsid.conf ファイルを開いて次のように編集します。

node.conn[0].timeo.noop_out_interval = 0node.conn[0].timeo.noop_out_timeout = 0

上記に合わせて、replacement_timeout には大きめの数値を設定します。これによりシステムのパス


245

上記に合わせて、replacement_timeout には大きめの数値を設定します。これによりシステムのパスやセッションの再確立に要する待機時間が長くなります。replacement_timeout を調整するには、/etc/iscsi/iscsid.conf ファイルを開いて次のように編集します。

node.session.timeo.replacement_timeout = replacement_timeout

/etc/iscsi/iscsid.conf の設定が終了したら、影響を受けるストレージの再検出を行う必要があります。再検出によってシステムは /etc/iscsi/iscsid.conf で設定した新しい値を読み込み、その値を使用できるようになります。iSCSI デバイスの検出方法については、「iSCSI 相互接続のスキャン」を参照してください。

特定セッションのタイムアウトの設定特定セッションのタイムアウトの設定

特定セッションに対してタイムアウトを設定し、それを非永続的にすることができます(/etc/iscsi/iscsid.conf ファイルを使用しない方法)。これを実行するには、次のコマンドを実行します(状況に応じて変数を変更してください)。

# iscsiadm -m node -T target_name -p target_IP:port -o update -n node.session.timeo.replacement_timeout -v $timeout_value

重要重要

ルートパーティションへのアクセスを必要とする iSCSI セッションには、本セクションに記載されている設定を行うことを推奨します。他のタイプのストレージへのアクセスを必要とする iSCSI セッション (つまり dm-multipath を使用するシステムの場合) については、「dm-multipath を実装している iSCSI の設定」を参照してください。

25.20. SCSI コマンドタイマーとデバイス状態の制御

Linux SCSI レイヤーは、各コマンドでタイマーをセットします。このタイマーが時間切れになると、SCSI レイヤーは host bus adapter (HBA) を休止して、残りのコマンドすべてがタイムアウトになるか、完了するのを待ちます。その後に、SCSI レイヤーはドライバーのエラーハンドラーを始動します。

エラーハンドラーがトリガーされると、以下の操作を順番に試行します (そのいずれかが正しく実行されるまで試行が続きます)。

1. コマンドの中止

2. デバイスのリセット

3. バスのリセット

4. ホストのリセット

これらの操作がすべて失敗する場合、デバイスは offline 状態にセットされます。この状況が発生すると、そのデバイスへのすべての I/O は、問題が修正されてユーザーがデバイスを running に設定しない限り、失敗します。

デバイスがファイバーチャネルプロトコルを使用し、rport がブロックされている場合はプロセスが異なります。この場合、ドライバーはエラーハンドラーをアクティベートする前に rport が再度オンラインになるまで数秒間待ちます。これにより、一時的なトランスポートの問題でデバイスがオフラインにならないようにします。


246

デバイスの状態

デバイスの状態を表示するには、以下を使用します。

$ cat /sys/block/device-name/device/state

デバイスを running 状態に設定するには、以下を使用します。

# echo running > /sys/block/device-name/device/state

コマンドタイマー

コマンドタイマーを制御するには、/sys/block/device-name/device/timeout ファイルを編集します。

# echo value > /sys/block/device-name/device/timeout

このコマンド上の value は実装するタイムアウト値 (秒単位) に置き換えてください。

25.21. オンラインストレージ設定のトラブルシューティング

このセクションでは、ユーザーがオンラインストレージの再設定で直面する一般的な問題へのソリューションを提供します。

論理ユニットの削除状況がホスト上に反映されません。論理ユニットの削除状況がホスト上に反映されません。

設定済みのファイラーで論理ユニットが削除されても、その変更はホスト上には反映されません。そのような場合、論理ユニットは陳腐化しているため、dm-multipath が使用されると、lvm コマンドは無限にハングします。

これを回避するには、以下の手順を実行します。

手順手順25.17 陳腐化した論理ユニットの回避策陳腐化した論理ユニットの回避策

1. /etc/lvm/cache/.cache 内のどの mpath リンクエントリーが陳腐化した論理ユニットに固有のものであるかを判別します。これを実行するには、以下のコマンドを実行します。

$ ls -l /dev/mpath | grep stale-logical-unit

例例25.16 特定の特定の mpath リンクエントリーを判別リンクエントリーを判別

たとえば、stale-logical-unit が 3600d0230003414f30000203a7bc41a00 である場合、以下の結果が出る可能性があります。

lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5

これは、3600d0230003414f30000203a7bc41a00 が dm-4 と dm-5 の 2 つの mpathリンクにマップされていることを示しています。

2. 次に、/etc/lvm/cache/.cache を開いて、stale-logical-unit および stale-logical-unit がマッ


247

2. 次に、/etc/lvm/cache/.cache を開いて、stale-logical-unit および stale-logical-unit がマップされる mpath リンクを含むすべての行を削除します。

例例25.17 関連した行の削除関連した行の削除

直前のステップと同じ例を使用すると、削除する必要のある行は以下になります。

/dev/dm-4 /dev/dm-5 /dev/mapper/3600d0230003414f30000203a7bc41a00/dev/mapper/3600d0230003414f30000203a7bc41a00p1/dev/mpath/3600d0230003414f30000203a7bc41a00/dev/mpath/3600d0230003414f30000203a7bc41a00p1

25.22. EH_DEADLINE を使用したエラーからの回復における最大時間の設定

重要重要

ほとんどのシナリオでは、eh_deadline パラメーターを有効にする必要はありませんが、ファイバーチャネルスイッチとターゲットポートとの間でリンクが切れていたり、HBA (Host Bus Adapter) が、RSCN (Registered State Change Notification) を受け取らないなどの一部のシナリオでは、eh_deadline パラメーターを使用すると便利です。このとき、I/O 要求とエラー回復のコマンドではエラーが発生せず、すべてタイムアウトになります。したがって、この環境に eh_deadline を設定すると、回復時間に上限が設定されるため、失敗した I/O を、マルチパスで利用可能な別のパスで再試行できます。

ただし、RSCN を有効にすると、HBA がリンクを登録しなくなるか、もしくは利用できなくなります。I/O とエラー回復のコマンドがすぐに失敗し、それによりマルチパスの再試行が可能になるため、eh_deadline 機能が提供する利点が利用できなくなります。

SCSI ホストオブジェクトの eh_deadline パラメーターを使用すると、SCSI エラー処理がエラー回復を実行する最大時間 (HBA を停止してリセットするまでの時間) を設定することができます。

eh_deadline パラメーターの値は秒単位で指定し、デフォルト値は off です。これにより、時間制限が無効になり、エラー回復がすべて行われます。sysfs とともに scsi_mod.eh_deadline カーネルパラメーターを使用すると、すべての SCSI HBA にデフォルト値を設定できます。

eh_deadline の有効期限が切れると HBA がリセットされるため、失敗したパスだけでなく、この HBAにあるすべてのターゲットパスが影響を受けます。その結果、何らかの理由で冗長パスの一部が利用できないと、I/O エラーが発生します。したがって、すべてのターゲットに、完全に冗長なマルチパス設定が設定されていない場合は、eh_deadline を有効にしないでください。

[5] target_IP 変数および port 変数は、ターゲット/ポータルの IP アドレスおよびポートの組み合わせをそれぞれ参照します。詳細は「iSCSI API」および「iSCSI 相互接続のスキャン」を参照してください。

[6] proper_target_name の詳細は「iSCSI 相互接続のスキャン」を参照してください。

[7] セッションの SID 値を取得する方法の詳細は、「iSCSI API」を参照してください。


248

[8] このコマンドは、改行がない 1 行のコマンドになりますが、印刷版または PDF 版では複数の行で表されることがあります。行の前にバックスラッシュ「\」が付いている場合は、バックスラッシュを除いた 1 つのコマンドを示していることに注意してください。

[9] Red Hat Enterprise Linux 5.4 より前のバージョンでは、デフォルトの NOP-Out 要求のタイムアウトは 15 秒でした。


249

第26章 DEVICE MAPPER を使ったマルチパス設定 (DMMULTIPATH) と仮想マシン用ストレージRed Hat Enterprise Linux 7 は DM Multipath と仮想マシン用ストレージに対応しています。

26.1. 仮想マシン用のストレージ

Red Hat Enterprise Linux 7 は以下の仮想マシン用のファイルシステムまたはオンラインストレージ手段に対応しています。

ファイバーチャネル

iSCSI

NFS

GFS2

Red Hat Enterprise Linux 7 の仮想化では、仮想インスタンスの管理に libvirt を使用しています。libvirtユーティリティーでは仮想化したゲスト用のストレージ管理にストレージプールという概念を採用しています。ストレージプールとは複数の小さなボリュームに区分けしたり、ゲストに直接割り当てたりすることのできるストレージを指します。ストレージプールのボリュームは仮想化したゲストに割り当てることができます。以下に、利用可能なストレージプールのカテゴリーを示します。

ローカルストレージのプールローカルストレージのプール

ローカルストレージには、直接ホストに接続されるストレージデバイス、ファイルやディレクトリー、ローカルディレクトリー、ディスクに直接接続されたディスクや LVM ボリュームグループが含まれます。

ネットワークネットワーク (共有共有) ストレージプールストレージプール

ネットワークストレージとは、標準プロトコルを使ってネットワーク経由で共有されるストレージデバイスが該当します。ファイバーチャネル、iSCSI、NFS、GFS2、SCSI RDMA などのプロトコルを使った共有ストレージデバイスが含まれ、ホスト間での仮想化の移動には必須となります。

Red Hat Enterprise Linux が対応しているストレージプールのタイプの詳細は、 Red Hat Red HatEnterprise Linux 仮想化の導入および管理ガイドを参照してください。

26.2. DM MULTIPATH

DM Multipath は、サーバーノード群とストレージアレイ群の間の複数の入出力パスを 1 つのデバイスに設定することができる機能になります。こうした入出力パスは物理的な SAN 接続であり、別々のケーブル、スイッチ、コントローラーなどが含まれる可能性があります。マルチパス機能により入出力パスを集約し、集約されたパスで構成される新しいデバイスを作成できます。

DM Multipath は主に次のような理由で使用されます。

冗長性冗長性

DM Multipath を active/passive に設定するとフェイルオーバーを行うことができます。active/passive に設定すると、常に全体の半分のパスだけが使用されます。I/O パス上のいずれかの構成要素に障害が発生すると、DM Multipath により別のパスへの切り替えが行われます。

パフォーマンスの向上パフォーマンスの向上


250

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/storage_pools

DM Multipath を active/active モードに設定すると、I/O はラウンドロビン式でパス全体に分散されます。I/O パスの負荷を検出し、動的に負荷分散の再調整を行うことができる設定もあります。

詳細は、Red Hat DM Multipath ガイドを参照してください。

第第26章章 DEVICE MAPPER を使ったマルチパス設定を使ったマルチパス設定 (DM MULTIPATH) と仮想マシン用ストレージと仮想マシン用ストレージ

251


第27章外部アレイ管理 (LIBSTORAGEMGMT)Red Hat Enterprise Linux 7 には、libStorageMgmt という新たな外部アレイ管理パッケージが標準装備されています。

27.1. LIBSTORAGEMGMT 導入

libStorageMgmt ライブラリーは、独立したアプリケーションプログラミングインターフェイス (API)のストレージアレイです。開発者として、API を使うことで、さまざまなストレージ洗いを管理して、ハードウェアアクセラレーション機能を利用できます。

このライブラリーは、よりレベルが高い管理ツール向けビルディングブロックとして使用されます。さらに、エンドシステムの管理者は、ストレージを手動で管理し、ストレージ管理タスクをスクリプトで自動化するためのツールとして、このライブラリーを使用することもできます。

libStorageMgmt ライブラリーでは、以下の操作を実行できます。

ストレージプール、ボリューム、アクセスグループ、またはファイルシステムの一覧表示。

ボリューム、アクセスグループ、ファイルシステム、または NFS エクスポートの作成および削除。

ボリューム、アクセスグループ、またはイニシエーターへのアクセスの付与および削除。

スナップショット、クローン、およびコピーによるボリュームの複製。

アクセスグループの作成および削除、ならびにグループのメンバーの編集。

すべての操作がアレイ上で行なわれるため、CPU や相互接続帯域幅などのサーバーリソースは使用されません。

libstoragemgmt パッケージにより利用可能になる機能:

クライアントアプリケーションおよびプラグインの開発者向けの安定した C および PythonAPI。

ライブラリーを使用するコマンドラインインターフェース (lsmcli)。

プラグインを実行するデーモン (lsmd)。

クライアントアプリケーションのテストを許可するシミュレーターのプラグイン (sim)。

アレイとのインターフェース用のプラグインのアーキテクチャー。


252

警告警告

このライブラリーとその関連ツールには、それが管理するアレイ上にあるすべてのデータを破棄する機能があります。論理エラーを削除するため、本番稼働システムを使用して作業する前に、ストレージシミュレーターのプラグインに対してアプリケーションとスクリプトの開発とテストを行うことが推奨されます。また、本番への導入前に、実際の非本番稼働ハードウェアでアプリケーションとスクリプトのテストを行うことも、可能な場合には強く推奨されます。

Red Hat Enterprise Linux 7 の libStorageMgmt ライブラリーは、REPORTED LUNS DATA HASCHANGED という unit attention に対処する、デフォルトの udev ルールを追加します。

ストレージの設定が変更すると、Unit Attention ASC/ASCQ コードの 1 つが変更を報告します。その後uevent が生成され、sysfs によって自動的に再スキャンされます。

/lib/udev/rules.d/90-scsi-ua.rules ファイルには、カーネルが生成できる他のイベントを列挙するサンプルルールが含まれます。

libStorageMgmt ライブラリーは、ストレージアレイの相違を調整するためにプラグインアーキテクチャーを使用します。libStorageMgmt プラグインや、これらの書き込み方法は、Red Hat の「開発者ガイド」を参照してください。

27.2. LIBSTORAGEMGMT 用語

アレイベンダーおよびストレージ標準は複数存在し、同様の機能に言及する場合でも異なる用語が使用されています。このライブラリーでは、以下の用語を使用します。

ストレージアレイストレージアレイ

Network Attached Storage (NAS) を使用して、ブロックアクセス (FC、FCoE、iSCSI) またはファイルアクセスを提供するストレージシステム。

ボリュームボリューム

Storage Area Network (SAN) ストレージアレイは、FC、iSCSI、または FCoE などの異なるトランスポート上で、ホストバスアダプター (HBA) にボリュームを公開できます。ホスト OS は、これをブロックデバイスとして処理します。multipath[2] が有効になっている場合、1 つのボリュームは、多くのディスクに公開されます)。

また、これは論理ユニット番号 (LUN)、(SNIA 用語では) StorageVolume、または仮想ディスクとしても知られています。

プールプール

ストレージスペースのグループです。ファイルシステムまたはボリュームはプールから作成できます。プールは、ディスク、ボリューム、および他のツールから作成できます。プールは、RAID 設定またはプロビジョニング設定を保持することもできます。

これは、SNIA 用語では StoragePool として知られています。

スナップショットスナップショット

任意の時点の、読み取り専用の、スペース効率のよいデータのコピーです。

第第27章章外部アレイ管理外部アレイ管理 (LIBSTORAGEMGMT)

253

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/developer_guide/index

これは、読み取り専用のスナップショットとしても知られています。

クローンクローン

任意の時点の、読み取りおよび書き込み可能な、スペース効率のよいデータのコピーです。

これは、読み取りおよび書き込み可能なスナップショットとしても知られています。

コピーコピー

データの完全なビット単位のコピーです。フルスペースを占有します。

鏡面印刷鏡面印刷

継続的に更新されるコピー (同期および非同期) です。

アクセスグループアクセスグループ

1 つまたは複数のストレージボリュームへのアクセスが付与される iSCSI、FC、および FCoE イニシエーターの集合です。これにより、ストレージボリュームにアクセスできるのは、指定のイニシエーターに限られます。

これは、イニシエーターグループとしても知られています。

アクセス許可アクセス許可

ボリュームを、指定のアクセスグループまたはイニシエーターに公開します。現在、libStorageMgmt ライブラリーは、特定の論理ユニット番号を選択する機能のある LUN マッピングをサポートしていません。libStorageMgmt ライブラリーでは、ストレージアレイは、割り当て時に、次に利用可能な LUN を選択します。SAN からブートを設定するか、または 256 を超えるボリュームをマスクするには、OS、ストレージ、または HBA 資料を必ず参照してください。

アクセス許可は、LUN マスクとしても知られています。

システムシステム

ストレージアレイまたは直接接続のストレージ RAID を表します。

ファイルシステムファイルシステム

Network Attached Storage (NAS) ストレージアレイは、NFS または CIFS プロトコルのいずれかを使用して、IP ネットワーク経由で OS をホストするファイルシステムを公開できます。ホスト OSは、クライアントのオペレーティングシステムによって、これをマウントポイントか、またはファイルが含まれるフォルダーとして処理します。

ディスクディスク

データを保持する物理ディスクです。これは通常、RAID 設定を使ってプールを作成する場合に使用されます。

これは、SNIA 用語では DiskDrive として知られています。

イニシエーターイニシエーター

イニシエーターは、ファイバーチャネル (FC) またはファイバーチャネルオーバーイーサネット(FCoE) では、ワールドワイドポートネーム (WWPN) またはワールドワイドノード名 (WWNN) です。iSCSI では、iSCSI 修飾名 (IQN) です。NFS または CIFS では、ホスト名またはホストの IP アドレスです。


254

子の依存関係子の依存関係

一部のアレイでは、元になるもの (親ボリュームまたはファイルシステム) と子 (スナップショットまたはクローンなど) の間に、暗黙的な関係があります。たとえば、親に依存する子が 1 つ以上ある場合は、その親を削除することはできません。API は、このような関係が存在するかどうかを判別するためのメソッドと、必要なブロックを複製することで依存関係を削除するメソッドを提供します。

27.3. LIBSTORAGEMGMT のインストール

コマンドラインや、必要なランタイムライブラリーおよびシミュレータープラグインを使用するために libStorageMgmt をインストールするには、以下のコマンドを使用します。

# yum install libstoragemgmt libstoragemgmt-python

ライブラリを使用する C アプリケーションを開発するには、以下のコマンドで libstoragemgmt-develパッケージをインストールします。

# yum install libstoragemgmt-devel

ハードウェアアレイと共に使用するために libStorageMgmt をインストールするには、以下のコマンドを使って、適切なプラグインパッケージを 1 つ以上選択します。

# yum install libstoragemgmt-name-plugin

利用可能なプラグインには、以下が含まれます。

libstoragemgmt-smis-plugin

汎用 SMI-S アレイサポート。

libstoragemgmt-netapp-plugin

NetApp ファイルの特殊サポート。

libstoragemgmt-nstor-plugin

NexentaStor の特殊サポート。

libstoragemgmt-targetd-plugin

targetd の特殊サポート。

次に、デーモンがインストールされ、次回のブート時に起動するように設定されます。システムを再起動せずにデーモンをすぐに使用するには、デーモンを手動で開始します。

アレイを管理するには、プラグインによるサポートが必要です。ベースインストールパッケージには、多くのベンダー用のオープンソースのブラグインが含まれます。その他のプラグインパッケージは、アレイのサポートが改善されると別途利用可能になります。現在サポートされているハードウェアには、継続的に変更と改善が追加されています。

libStorageMgmt デーモン lsmd は、システムの任意の標準サービスのように動作します。

libStorageMgmt サービスのステータスをチェックするには:


255

# systemctl status libstoragemgmt

サービスを停止するには:

# systemctl stop libstoragemgmt

サービスを起動するには:

# systemctl start libstoragemgmt

27.4. USING LIBSTORAGEMGMT の使用

libStorageMgmt を対話形式で使用するには、lsmcli ツールを使用します。

lsmcli ツールを実行するには、以下の 2 つのことが必要です。

アレイと、アレイで必要な設定可能なオプションに接続するためのプラグインを特定するために使用される URI (Uniform Resource Identifier)。

アレイで有効なユーザー名およびパスワード。

URI は以下の形式になります。

plugin+optional-transport://user-name@host:port/?query-string-parameters

必要な要件は、各プラグインで異なります。

例例27.1 プラグインによって要件が異なる例プラグインによって要件が異なる例

ユーザー名またはパスワードを必要としないシミュレーターのプラグインユーザー名またはパスワードを必要としないシミュレーターのプラグイン

sim://

ユーザー名のユーザー名の root を使用するを使用する SSL 経由の経由の NetApp プラグインプラグイン

ontap+ssl://[email protected]/

EMC アレイ用のアレイ用の SSL 経由の経由の SMI-S プラグインプラグイン

smis+ssl://[email protected]:5989/?namespace=root/emc

URI を使用する方法としては、以下の 3 つがあります。

1. コマンドの一部として URI を渡します。

$ lsmcli -u sim://

2. URI を環境変数に保存します。

$ export LSMCLI_URI=sim://

3. ~/.lsmcli ファイルに URI を指定します。ここでは、名前と値のペアを「=」で区切ります。現在サポートされる設定は uri のみです。


256

使用する URI を指定するのは、この順番で行う必要があります。3 つの方法がすべて使われる場合は、コマンドラインで一番最初に実行されたものが適用されます。

コマンドラインに -P を追加するか、または環境変数の LSMCLI_PASSWORD に設定して、パスワードを指定します。

例例27.2 lsmcli の例の例

以下の例は、コマンドラインを使用して新規ボリュームを作成し、これをイニシエーターに表示する方法を示します。

この接続によって処理されるアレイをリストします。

$ lsmcli list --type SYSTEMSID | Name | Status-------+-------------------------------+--------sim-01 | LSM simulated storage plug-in | OK

ストレージプールをリストします。

$ lsmcli list --type POOLS -HID | Name | Total space | Free space | System ID-----+---------------+----------------------+----------------------+-----------POO2 | Pool 2 | 18446744073709551616 | 18446744073709551616 | sim-01POO3 | Pool 3 | 18446744073709551616 | 18446744073709551616 | sim-01POO1 | Pool 1 | 18446744073709551616 | 18446744073709551616 | sim-01POO4 | lsm_test_aggr | 18446744073709551616 | 18446744073709551616 | sim-01

ボリュームを作成します。

$ lsmcli volume-create --name volume_name --size 20G --pool POO1 -HID | Name | vpd83 | bs | #blocks | status | ...-----+-------------+----------------------------------+-----+----------+--------+----Vol1 | volume_name | F7DDF7CA945C66238F593BC38137BD2F | 512 | 41943040 | OK | ...

iSCSI イニシエーターを含むアクセスグループを作成します。

$ lsmcli --create-access-group example_ag --id iqn.1994-05.com.domain:01.89bd01 --type ISCSI --system sim-01ID | Name | Initiator ID |SystemID---------------------------------+------------+----------------------------------+--------782d00c8ac63819d6cca7069282e03a0 | example_ag | iqn.1994-05.com.domain:01.89bd01 |sim-01

iSCSI イニシエーターを含むアクセスグループを作成します。

$ lsmcli access-group-create --name example_ag --init iqn.1994-05.com.domain:01.89bd01 --init-type ISCSI --sys sim-01ID | Name | Initiator IDs | System ID---------------------------------+------------+----------------------------------+-----------782d00c8ac63819d6cca7069282e03a0 | example_ag | iqn.1994-05.com.domain:01.89bd01 | sim-01

新たに作成されたボリュームに対して、アクセスグループの表示を許可します。


257

$ lsmcli access-group-grant --ag 782d00c8ac63819d6cca7069282e03a0 --vol Vol1 --access RW

ライブラリーの設計上、inter-process communication (IPC) によりクライアントとプラグインの間のプロセスが分離します。これにより、プラグインのバグが原因で、クライアントアプリケーションがクラッシュすることがなくなります。さらに、プラグインの作成者が、独自に選択したライセンスを使ってプラグインを作成する手段も提供します。クライアントが URI を渡すライブラリーを開くと、クライアントライブラリーが URI を参照し、どちらのプラグインを使用する必要があるのかを決定します。

プラグインは、実際はスタンドアロンのアプリケーションですが、コマンドライン上で渡されるファイルディスクリプターを持つように設計されています。クライアントライブラリーは、デーモンにプラグインをフォークし、実行させる適切な Unix ドメインソケットを開きます。これにより、クライアントライブラリーには、プラグインによるポイントツーポイントの通信チャンネルが提供されます。デーモンは、既存クライアントに影響を与えることなく再起動できます。クライアントがそのプラグインに対してライブラリーをオープンにしている間に、プラグインプロセスが実行します。1 つまたは複数のコマンドが送信されると、プラグインは閉じられ、プラグインプロセスはクリーンアップしてから終了します。

lsmcli のデフォルトの動作は、操作が完了するまで待機します。したがって、要求される操作によっては、数時間待機する可能性があります。コマンドラインで -b オプションを指定すれば、通常の使用に戻ることができます。終了コードが 0 の場合は、コマンドが完了しています。終了コードが 7 の場合はコマンドが進行中で、標準出力にはジョブ ID が書き込まれます。その後、必要に応じてそのジョブ IDを使用し、ユーザー自身またはスクリプトで lsmcli --jobstatus JobID を実行すれば、コマンドのステータスを照会できます。ジョブが完了すると、終了値は 0 となり、結果が標準出力に出力されます。コマンドが依然として進行中の場合は、戻り値が 7 となり、完成度 (パーセント) が標準出力に出力されます。

例例27.3 非同期の例非同期の例

ボリュームを作成します。コマンドがすぐに返されるように、-b オプションを渡します。

$ lsmcli volume-create --name async_created --size 20G --pool POO1 -b JOB_3

終了値をチェックします。

$ echo $?7

7 は、ジョブが依然として進行中であることを示しています。

ジョブが完了しているかどうかをチェックします。

$ lsmcli job-status --job JOB_333

終了値をチェックします。7 はジョブが依然として進行中であることを示しているため、標準の出力が完成度です。上記の画面の場合では、33% です。

$ echo $?7

しばらく待ち、終了値を再び確認します。


258

$ lsmcli job-status --job JOB_3ID | Name | vpd83 | Block Size | ...-----+---------------+----------------------------------+-------------+-----Vol2 | async_created | 855C9BA51991B0CC122A3791996F6B15 | 512 | ...

0 は成功を意味し、標準の出力が新しい値を表示します。

スクリプトの場合は、-t SeparatorCharacters オプションを渡してください。これにより、出力の解析がより簡単になります。

例例27.4 スクリプトの例スクリプトの例

$ lsmcli list --type volumes -t#Vol1#volume_name#049167B5D09EC0A173E92A63F6C3EA2A#512#41943040#21474836480#OK#sim-01#POO1Vol2#async_created#3E771A2E807F68A32FA5E15C235B60CC#512#41943040#21474836480#OK#sim-01#POO1

$ lsmcli list --type volumes -t " | "Vol1 | volume_name | 049167B5D09EC0A173E92A63F6C3EA2A | 512 | 41943040 | 21474836480 | OK | 21474836480 | sim-01 | POO1Vol2 | async_created | 3E771A2E807F68A32FA5E15C235B60CC | 512 | 41943040 | 21474836480 | OK | sim-01 | POO1

$ lsmcli list --type volumes -s---------------------------------------------ID | Vol1Name | volume_nameVPD83 | 049167B5D09EC0A173E92A63F6C3EA2ABlock Size | 512#blocks | 41943040Size | 21474836480Status | OKSystem ID | sim-01Pool ID | POO1---------------------------------------------ID | Vol2Name | async_createdVPD83 | 3E771A2E807F68A32FA5E15C235B60CCBlock Size | 512#blocks | 41943040Size | 21474836480Status | OKSystem ID | sim-01Pool ID | POO1---------------------------------------------

一般的なスクリプトには、Python ライブラリーを使用することが推奨されます。

lsmcli の詳細は、lsmcli man ページまたは lsmcli --help を参照してください。


259

第28章永続メモリー: NVDIMMストレージクラスメモリーとも呼ばれる永続メモリー (pmem) は、メモリーとストレージの組み合わせです。pmem は、ダイナミック RAM (DRAM) の低アクセスレイテンシーと広帯域幅をストレージの永続性を組み合わせます。

永続メモリーはバイトアドレス指定可能であるため、CPUロードを使用してアクセスでき、命令を格納できます。従来のブロックベースのストレージにアクセスするのに必須の read() または write() システム呼び出しに加え、pmem はダイレクトロードにも対応しており、プログラミングモデルを格納します。

永続メモリーのパフォーマンス特性は、アクセスレイテンシーが非常に低い DRAM と似ています。通常、10,000 〜 100,000 ナノ秒です。

永続メモリーの内容は、ストレージのように電源がオフになった際に保持されます。

永続メモリーを使用すると、以下のようなユースケースにメリットがあります。永続メモリーを使用すると、以下のようなユースケースにメリットがあります。

高速スタート高速スタート: データセットが既にメモリーに存在します。データセットが既にメモリーに存在します。

高速スタートは、ウォームキャッシュ (warm cache) 効果とも呼ばれます。ファイルサーバーは起動すると、メモリー内にファイルコンテンツを置きません。クライアントがデータの読み書きを行うため、そのデータはページキャッシュでキャッシュされます。最終的には、キャッシュに含まれるデータはホットデータが大半になります。再起動後、システムはこのプロセスを再び起動する必要があります。

永続メモリーでは、アプリケーションが正しく設計されていれば再起動においてウォームキャッシュを維持できます。この場合、関与するページキャッシュはありません。アプリケーションは、永続メモリーで直接データをキャッシュします。

高速書き込みキャッシュ高速書き込みキャッシュ

ファイルサーバーは多くの場合、データが耐久性のあるメディアに存在するまで、クライアントの書き込みリクエストを承認しません。高速書き込みキャッシュとして永続メモリーを使用すると、pmem の低レイテンシーにより、ファイルサーバーが書き込みリクエストをすばやく承認できるようになります。

NVDIMMs インターリービング非揮発性デュアルインラインメモリモジュール (NVDIMMs) は、通常の DRAM と同じ方法でインターリーブセットにグループ化できます。インターリーブセットは、複数の DIMM にわたる RAID 0 (ストライプ) のようなものです。

以下は、NVDIMMS インターリービングのメリットです。

DRAM のように、NVDIMMs は、インターリーブセットに設定するとパフォーマンス向上を図ることができます。

これは、複数の小さな NVDIMMs を 1 つの大きな論理デバイスに組み合わせるのに使用できます。

システム BIOS または UEFI ファームウェアを使用してインターリーブセットを設定します。

Linux では、1 つのリージョンのデバイスがインターリーブセットごとに作成されます。

以下は、リージョンデバイスとラベルの関係を説明しています。

お使いの NVDIMMs がラベルに対応していると、リージョンデバイスをさらに名前空間に分割


260

お使いの NVDIMMs がラベルに対応していると、リージョンデバイスをさらに名前空間に分割できます。

NVDIMM がラベルに対応していない場合、リージョンデバイスは単一の名前空間のみを含めることができます。この場合、カーネルは、リージョン全体を対象としたデフォルトの名前空間を作成します。

永続メモリーアクセスモード永続メモリーデバイスは、sector、fsdax、devdax (デバイスダイレクトアクセス) または raw モードで使用できます。

sector モードモード

ストレージを高速ブロックデバイスとして示します。セクターモードは、永続メモリーを使用するように変更されていないレガシーアプリケーションや、デバイスマッパーを含むフル I/O スタックを利用するアプリケーションに使用すると便利です。

fsdax モードモード

このモードでは、永続メモリーデバイスがストレージネットワークインダストリーアソシエーション (SNIA) 非揮発性メモリー (NVM) プログラミングモデル仕様で説明されているように、ダイレクトアクセスプログラミングに対応します。このモードでは、I/O がカーネルのストレージスタックをバイパスし、多くのデバイスマッパードライバーが使用できなくなります。

devdax モードモード

devdax (デバイス DAX) モードは、DAX キャラクターデバイスノードを使用して永続メモリーにraw アクセスを与えます。devdax デバイスのデータは、CPU キャッシュフラッシングとフェンシング命令を使用して強化できます。特定のデータベースや仮想マシンハイパーバイザーは、devdaxモードからメリットを得ることができます。ファイルシステムは、デバイス devdax インスタンスでは作成できません。

raw モードモード

raw モード名前空間にはいくつかの制限があるため、使用すべきではありません。

28.1. NDCTL による永続メモリー設定

ndctl ユーティリティを使用して永続メモリーデバイスを設定します。ndctl ユーティティをインストールするには、以下のコマンドを使用します。

# yum install ndctl

手順手順28.1 ラベルに対応していないデバイスの永続メモリーの設定ラベルに対応していないデバイスの永続メモリーの設定

1. お使いのシステム上で利用できる pmem リージョンを一覧表示します。以下の例では、このコマンドが、ラベルに対応していない NVDIMM-N デバイスを一覧表示しています。

# ndctl list --regions[ { "dev":"region1", "size":34359738368, "available_size":0, "type":"pmem"

第第28章章永続メモリー永続メモリー: NVDIMM

261

https://www.snia.org/tech_activities/standards/curr_standards/npm

}, { "dev":"region0", "size":34359738368, "available_size":0, "type":"pmem" }]

Red Hat Enterprise Linux は各リージョンのデフォルト名前空間を作成します。これは、NVDIMM-N デバイスがラベルに対応していないためです。つまり、利用可能なサイズは 0 バイトです。

2. システム上に非アクティブの名前空間すべてを一覧表示します。

# ndctl list --namespaces --idle[ { "dev":"namespace1.0", "mode":"raw", "size":34359738368, "state":"disabled", "numa_node":1 }, { "dev":"namespace0.0", "mode":"raw", "size":34359738368, "state":"disabled", "numa_node":0 }]

3. この容量を利用するために非アクティブな名前空間を設定します。たとえば、DAX 対応のファイルシステムに namespace0.0 を使用するには、以下のコマンドを使用します。

# ndctl create-namespace --force --reconfig=namespace0.0 --mode=fsdax --map=mem { "dev":"namespace0.0", "mode":"fsdax", "size":"32.00 GiB (34.36 GB)", "uuid":"ab91cc8f-4c3e-482e-a86f-78d177ac655d", "blockdev":"pmem0", "numa_node":0}

手順手順28.2 ラベルに対応しているデバイスの永続メモリーの設定ラベルに対応しているデバイスの永続メモリーの設定

1. お使いのシステム上で利用できる pmem リージョンを一覧表示します。以下の例では、このコマンドが、ラベルに対応している NVDIMM-N デバイスを一覧表示しています。

# ndctl list --regions[ {


262

"dev":"region5", "size":270582939648, "available_size":270582939648, "type":"pmem", "iset_id":-7337419320239190016 }, { "dev":"region4", "size":270582939648, "available_size":270582939648, "type":"pmem", "iset_id":-137289417188962304 }]

2. NVDIMM デバイスがラベルに対応している場合、デフォルトの名前空間は作成されません。また、--force または --reconfigure フラグなしでリージョンから 1 津以上の名前空間を割り当てることができます。

# ndctl create-namespace --region=region4 --mode=fsdax --map=dev --size=36G{ "dev":"namespace4.0", "mode":"fsdax", "size":"35.44 GiB (38.05 GB)", "uuid":"9c5330b5-dc90-4f7a-bccd-5b558fa881fe", "blockdev":"pmem4", "numa_node":0}

これで、同じリージョンから別の名前空間を作成できるようになりました。

# ndctl create-namespace --region=region4 --mode=fsdax --map=dev --size=36G{ "dev":"namespace4.1", "mode":"fsdax", "size":"35.44 GiB (38.05 GB)", "uuid":"91868e21-830c-4b8f-a472-353bf482a26d", "blockdev":"pmem4.1", "numa_node":0}

また、以下のコマンドを使用して、同じリージョンから別のタイプの名前空間を作成することもできます。

# ndctl create-namespace --region=region4 --mode=devdax --align=2M --size=36G{ "dev":"namespace4.2", "mode":"devdax", "size":"35.44 GiB (38.05 GB)", "uuid":"a188c847-4153-4477-81bb-7143e32ffc5c", "daxregion": { "id":4, "size":"35.44 GiB (38.05 GB)", "align":2097152,


263

"devices":[ { "chardev":"dax4.2", "size":"35.44 GiB (38.05 GB)" }] }, "numa_node":0}

ndctl ユーティリティの詳細は、man ndctl を参照してください。

28.2. ブロックデバイスとして使用するために永続メモリーを設定する (レガシーモード)

高速ブロックデバイスとして永続メモリーを使用するには、名前空間をセクターモードに設定します。

# ndctl create-namespace --force --reconfig=namespace1.0 --mode=sector{ "dev":"namespace1.0", "mode":"sector", "size":17162027008, "uuid":"029caa76-7be3-4439-8890-9c2e374bcc76", "sector_size":4096, "blockdev":"pmem1s"}

たとえば、namespace1.0 は、セクターモードに設定されています。ブロックデバイスの名前が pmem1 から pmem1s に変更されていることに注意してください。このデバイスは、システム上のその単おブロックデバイスと同じ方法で使用できます。たとえば、デバイスはパーティション設定することが可能です。また、デバイス上にファイルシステムを作成できます。デバイスは、dm-cache のキャッシュデバイスとすることができます。

28.3. ファイルシステムダイレクトアクセス用の永続メモリーの設定

ファイルシステムダイレクトアクセスでは、名前空間を fsdax モードに設定する必要があります。このモードでは、ダイレクトアクセスプログラミングモデルが可能になります。デバイスが fsdax モードに設定されると、ファイルシステムをその上に作成し、-o fsdax マウントオプションでマウントできます。そして、このファイルシステム上のファイルで mmap() 操作を実行するアプリケーションは、ストレージに直接アクセスできるようになります。以下の例を参照してください。

# ndctl create-namespace --force --reconfig=namespace0.0 --mode=fsdax --map=mem{ "dev":"namespace0.0", "mode":"fsdax", "size":17177772032, "uuid":"e6944638-46aa-4e06-a722-0b3f16a5acbf", "blockdev":"pmem0"}

この例では、namespace0.0 は名前空間 fsdax モードに変換されます。--map=mem 引数を指定することで、ndctl は、ダイレクトメモリーアクセス (DMA) に使用したオペレーティングシステムデータ構造をシステム DRAM に配置します。

DMA を実行するには、メモリーリージョンの各ページのデータ構造がカーネルによって必要とされま


264

す。このデータ構造のオーバーヘッドは 4 KiB ページごとに 64 バイトです。小型デバイスについては、オーバーヘッドの量が DRAM に一致するのに十分な小ささであるため問題ありません。たとえば、16 GiB 名前空間は、ページ構造に 256 MiB のみを必要とします。これは、--map=mem パラメーターで示されているように、NVDIMM デバイスが通常小さく高額であるためカーネルのページトラッキングデータ構造を DRAM に格納することが好ましいと考えられています。

今後、NVDIMM デバイスのサイズはテラバイトになる可能性があります。このようなデバイスについては、ページトラッキングデータ構造の格納に必要なメモリーの量がシステム内の DRAM の容量を超えることが考えられます。1 TiB の永続メモリーには、ページ構造だけに 16 GiB 必要となります。結果として、このような状況では、永続メモリー自体にデータ構造を格納するために --map=dev パラメーターを指定ことが望ましいと言えます。

fsdax モードで名前空間を設定した後、名前空間はファイルシステムに対して使用できるようになります。Red Hat Enterprise Linux 7.3 より、Ext4 と XFS ファイルシステムの両方では、テクノロジープレビューとして永続メモリーを使用できます。ファイルシステム作成には、特殊引数は必要ありません。DAX 機能を取得するには、dax マウントオプションを指定してファイルシステムをマウントしてください。例:

# mkfs -t xfs /dev/pmem0# mount -o dax /dev/pmem0 /mnt/pmem/

これで、アプリケーションは永続メモリーを使用して /mnt/pmem/ ディレクトリーでファイルを作成できます。また、ファイルを開くことや、mmap 操作を使用してダイレクトアクセス用にファイルをマッピグできます。

ダイレクトアクセスに使用するために pmem デビアス上でパーティションを作成する場合は、パーティションがページの境界に揃えられている必要があります。Intel 64 と AMD64 アーキテクチャでは、パーティションの開始と終了部分に最低 4KiB (2MiB 推奨) のアライメントが必要なります。デフォルトでは、parted ツールが 1MiB 境界上でパーティションをアラインします。最初のパーティションについては、パーティションの開始として 2MiB を指定します。パーティションのサイズが 2MiB の倍数である場合、その他すべてのパーティションも同じように調整されます。

28.4. デバイス DAX モードで使用するために永続メモリーの設定

デバイス DAX (devdax) は、ファイルシステムの関与なしで、アプリケーションがストレージに直接アクセスできる手段を与えます。デバイス DAX のメリットは、フォールト粒度を保証できることです。これは、ndctl ユーティリティで --align オプションを指定して設定できます。

# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax --align=2M

指定されたコマンドでは、オペレーティングシステムが 1 度に 2MiB ページでエラーするようにします。Intel 64 と AMD64 アーキテクチャについては、以下のフォールト粒度に対応しています。

4KiB

2MiB

1GiB

デバイス DAX ノード (/dev/daxN.M) は以下のシステム呼び出しのみに対応しています。

open()

close()


265

mmap()

fallocate()

read() と write() 変数には対応していません。これは、ユースケースが、永続メモリープログラミングに関連づけられているためです。

28.5. NVDIMM のトラブルシューティング

28.5.1. S.M.A.R.T. を使用した NVDIMM 正常性の監視

一部の NVDIMMs は正常性情報の取得に Self-Monitoring, Analysis and Reporting Technology(S.M.A.R.T.) インターフェースに対応しています。

NVDIMM 正常性を定期的に監視することで、データの損失を回避します。「破損した NVDIMM の検出と置換」で説明しているように、S.M.A.R.T. が NVDIMM の正常性ステータスについて問題を報告すると、置き換えられます。


一部のシステム上では、以下のコマンドを使用して正常性情報を取得するために acpi_ipmi ドライバーをロードする必要があります。

# modprobe acpi_ipmi

手順手順

正常性情報にアクセスするには、以下のコマンドを使用します。

# ndctl list --dimms --health... { "dev":"nmem0", "id":"802c-01-1513-b3009166", "handle":1, "phys_id":22, "health": { "health_state":"ok", "temperature_celsius":25.000000, "spares_percentage":99, "alarm_temperature":false, "alarm_spares":false, "temperature_threshold":50.000000, "spares_threshold":20, "life_used_percentage":1, "shutdown_state":"clean" } }...

28.5.2. 破損した NVDIMM の検出と置換

システムログまたは S.M.A.R.T. で報告された NVDIMM 関連のエラーメッセージが使った場合は、


266

システムログまたは S.M.A.R.T. で報告された NVDIMM 関連のエラーメッセージが使った場合は、NVDIMM デバイスがエラーを起こしていることが考えられます。この場合、以下を行う必要があります。

1. NVDIMM デバイスがエラーしていることを検出

2. そこに格納されているデータをバックアップ

3. デバイスを物理的に交換。

手順手順28.3 破損した破損した NVDIMM の検出と置換の検出と置換

1. 破損した DIMM を検出するには、以下のコマンドを使用します。

# ndctl list --dimms --regions --health --media-errors --human

badblocks フィールドは、NVDIMM が破損していることを示しています。dev フィールドの名前をメモしてください。以下の例では、nmem0 が破損しています。

例例28.1 NVDIMM デバイスの正常性ステータスデバイスの正常性ステータス

# ndctl list --dimms --regions --health --media-errors --human

... "regions":[ { "dev":"region0", "size":"250.00 GiB (268.44 GB)", "available_size":0, "type":"pmem", "numa_node":0, "iset_id":"0xXXXXXXXXXXXXXXXX", "mappings":[ { "dimm":"nmem1", "offset":"0x10000000", "length":"0x1f40000000", "position":1 }, { "dimm":"nmem0", "offset":"0x10000000", "length":"0x1f40000000", "position":0 } ], "badblock_count":1, "badblocks":[ { "offset":65536, "length":1, "dimms":[ "nmem0" ] } ],


267

"persistence_domain":"memory_controller" } ]}

2. 以下のコマンドを使用して、破損した NVDIMM の phys_id 属性を見つけます。

# ndctl list --dimms --human

以前の例から、nmem0 が破損した NVDIMM であることがわかっています。よって、nmem0の phys_id 属性を見つけます。以下の例では、phys_id は 0x10 です。

例例28.2 NVDIMMs のの phys_id 属性属性

# ndctl list --dimms --human

[ { "dev":"nmem1", "id":"XXXX-XX-XXXX-XXXXXXXX", "handle":"0x120", "phys_id":"0x1c" }, { "dev":"nmem0", "id":"XXXX-XX-XXXX-XXXXXXXX", "handle":"0x20", "phys_id":"0x10", "flag_failed_flush":true, "flag_smart_event":true }]

3. 以下のコマンドを使用して、破損した NVDIMM のメモリースロットを見つけます。

# dmidecode

出力において、Handle 識別子が、破損した NVDIMM の phys_id 属性と一致するエントリーを見つけます。Locator フィールドは、破損した NVDIMM によって仕様されたメモリースロットを一覧表示します。以下の例では、nmem0 が 0x0010 識別子に一致し、DIMM-XXX-YYYY メモリースロットを使用します。

例例28.3 NVDIMM メモリースロットリスティングメモリースロットリスティング

# dmidecode

...Handle 0x0010, DMI type 17, 40 bytesMemory Device Array Handle: 0x0004 Error Information Handle: Not Provided


268

Total Width: 72 bits Data Width: 64 bits Size: 125 GB Form Factor: DIMM Set: 1 Locator: DIMM-XXX-YYYY Bank Locator: Bank0 Type: Other Type Detail: Non-Volatile Registered (Buffered)...

4. NVDIMM 上の名前空間のすべてのデータをバックアップします。NVDIMM を交換する前にデータをバックアップ市内場合は、システムから NVDIMM を削除するとデータが失われます。

警告警告

時折、NVDIMM が完全に破損すると、バックアップが失敗することがあります。

これを回避するためにも、「S.M.A.R.T. を使用した NVDIMM 正常性の監視」で説明しているように、S.M.A.R.T. を使用して NVDIMM デバイスを定期的に監視して、破損する前にエラーを起こしている NVDIMM を交換してください。

以下のコマンドを使用して、NVDIMM 上の名前空間を一覧表示します。

# ndctl list --namespaces --dimm=DIMM-ID-number

以下の例では、nmem0 デバイスには、バックアップが必要な namespace0.0 と namespace0.2 名前空間が含まれます。

例例28.4 NVDIMM 名前リストの一覧表示名前リストの一覧表示

# ndctl list --namespaces --dimm=0

[ { "dev":"namespace0.2", "mode":"sector", "size":67042312192, "uuid":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", "raw_uuid":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", "sector_size":4096, "blockdev":"pmem0.2s", "numa_node":0 }, { "dev":"namespace0.0",


269

"mode":"sector", "size":67042312192, "uuid":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", "raw_uuid":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", "sector_size":4096, "blockdev":"pmem0s", "numa_node":0 }]

5. 破損した NVDIMM を物理的に交換します。


270

パート III. VDO によるデータの重複排除と圧縮

ここでは、Virtual Data Optimizer (VDO) を利用できるようにすることで、既存のストレージ管理アプリケーションに重複排除したブロックストレージ機能を追加する方法を説明しています。

パートパート III. VDO によるデータの重複排除と圧縮によるデータの重複排除と圧縮

271

第29章 VDO 統合

29.1. VDO の論理概要

Virtual Data Optimizer (VDO) は、ブロックストレージの圧縮したプールと重複排除したプールを簡単に作成できるブロック仮想化テクノロジーです。

重複排除重複排除とは、重複ブロックの複数のコピーを削除することで、ストレージリソースの消費を低減させるための技術です。

同じデータを 1 度以上書き込むのではなく、VDO は各重複ブロックを検出し、オリジナルブロックへの参照として記録します。VDO は論理ブロックアドレス (VDO 上のストレージレイヤーによって使用) から物理ブロックアドレス (VDO 下のストレージ層によって使用) へのマッピングを維持します。

重複排除を行った後、複数の論理ブロックアドレスが同じ物理ブロックアドレスにマッピングできます。これらは、shared blocks と呼ばれます。ブロック共有は、ブロックの読み書きを行うストレージのユーザーには表示されません。VDO が存在していない場合は表示されます。共有ブロックが上書きされると、新しい物理ブロックが新しいブロックデータを格納するために割り当てられ、共有物理ブロックにマッピングされているその他の論理ブロックアドレスが変更されないようにします。

Compression は、ログファイルやデータベースなどブロックレベルの冗長性を見せる必要がないファイル形式で動作するデータ低減技術です。詳細は「圧縮の使用」を参照してください。

VDO ソリューションは、以下のコンポーネントから成ります。

kvdo

重複排除、圧縮、シンプロビジョニングしたブロックストレージボリュームを利用できるようするために Linux デバイスマッパー層に読み込むカーネルモジュール。

uds

ボリューム上で Universal Deduplication Service (UDS) インデックスと通信して、重複排除を行うためにデータを分析するカーネルモジュール。

コマンドラインツールコマンドラインツール

最適化したストレージの設定と管理について。

29.1.1. UDS カーネルモジュール (uds)

UDS インデックスは、VDO 製品の基盤を形成します。新しいデータの断片ごとに、その断片が以前に格納されたものと同じであるかどうかを素早く判別します。インデックスが一致を見つけた場合、ストレージシステムは、同じ情報を複数にわたり格納しないように既存の項目を内部的に参照します。

UDS インデックスは、uds カーネルモジュールとしてカーネル内で実行します。

29.1.2. VDO カーネルモジュール (uds)

kvdo Linux カーネルモジュールは、Linux デバイスマッパー層内でブロック層の重複排除サービスを利用できるようにします。Linux カーネルで、デバイスマッパーは、ブロックストレージのプールを管理するためのジェネリックフレームとして機能します。これにより、ブロックプロセスモジュールの、


272

カーネルブロックインターフェースと実際のストレージデバイスドライバー間のストレージスタックへの挿入が可能になります。

kvdo モジュールは、ブロックストレージに直接アクセスできる、または XFS や ext4 などの多くの利用可能な Linux ファイルシステムの 1 つから表示できるブロックデバイスとして表示されます。kvdoが VDO ボリュームからデータの (論理) ブロックの読み込みをリクエストされると、リクエストされた論理ブロックが基礎となる物理ブロックにマッピングされ、リクエストされたデータを読み込んで返します。

kvdo が、VDO ボリュームにブロックデータを書き込むリクエストを受信すると、まず、DISCARD または TRIM リクエストであるかどうかや、データが統合的にゼロであるかどうかをチェックします。どちらかである場合は、kvdo がブロックマップを更新し、リクエストを承認します。そうでなければ、リクエストによって使用する物理ブロックが割り当てられます。

VDO 書き込みポリシーの概要書き込みポリシーの概要

kvdo モジュールが同期モードで動作している場合:

1. リクエストのデータを一時的に、割り当てられたブロックに書き込み、リクエストを承認します。

2. 承認が完了すると、ブロックデータの MurmurHash-3 署名を計算してブロックの重複排除が試行されます。これは、VDO インデックスに送信されます。

3. VDO インデックスに同じ署名とともにブロックのエントリーが含まれる場合、kvdo は示されたブロックを読み込み、同一であるかを検証するために 2 つのブロックのバイト対バイトの比較を行います。

4. 同一であることが確認されると、kvdo はブロックマップを更新します。よって、論理ブロックが、一致する物理ブロックに向き、割り当てられた物理ブロックをリリースします。

5. VDO インデックスに、書き込まれているブロックの署名のエントリーを含まない場合や、示されたブロックが同じデータを含まない場合は、kvdo はブロックマップを更新して、一時的な物理ブロックを永続的にします。

kvdo が非同期モードで動作している場合:

1. データを書き込む代わりに、リクエストをすぐに承認します。

2. 上記の説明と同じようにブロックの重複排除試行が行われます。

3. ブロックが重複していることがわかると、kvdo はブロックマップを更新して、割り当てられたブロックをリリースします。そうでなければ、リクエストのデータを、割り当てられたブロックに書き込み、ブロックマップを更新して物理ブロックを永続なものにします。

29.1.3. VDO ボリューム

VDO はバッキングストアとしてブロックデバイスを使用します。これは、1 つ以上のディスク、パーティション、あるいはフラットからなる物理ストレージの集合を含めることができます。VDO ボリュームがストレージ管理ツールによって作成されると、VDO は UDS インデックスと VDO ボリュームの両方のボリュームから容量を保有します。これは、ともに作用し、ユーザーやアプリケーションが重複排除したブロックストレージを利用できるようになります。図29.1「VDO ディスク整理」では、これらのつながりの仕組みを説明しています。

第第29章章 VDO 統合統合

273

図図29.1 VDO ディスク整理ディスク整理

スラブスラブ

VDO ボリュームの物理ストレージは、数多くのスラブに分割されます。これらのそれぞれは、物理容量の隣接する領域です。指定のボリュームのすべてのスラブが同じサイズになります。これは、128 MBのべき乗で最大 32 GB のサイズとなります。

デフォルトのスラブサイズは、より小さなテストシステムで VDO の評価を行えるように 2 GB となっています。単一の VDO ボリュームは最大 8096 スラブを利用できます。よって、2 GB スラブのデフォルトの設定では、最大許容物理ストレージは 16 TB となります。32 GB のスラブを使用すると、最大許容ストレージは 256 TB となります。メタデータ用に VDO によって最低 1 つの完全スラブが予約されます。そのため、ユーザーデータの格納には使用できません。

スラブのサイズは、VDO ボリュームのパフォーマンスには影響しません。

表表29.1 物理ボリュームサイズによる推奨の物理ボリュームサイズによる推奨の VDO スラブサイズスラブサイズ

物理ボリュームサイズ物理ボリュームサイズ推奨スラブサイズ推奨スラブサイズ

10–99 GB 1 GB

100 GB – 1 TB 2 GB

2–256 TB 32 GB

スラブのサイズは、vdo create コマンドに --vdoSlabSize=megabytes オプションを指定することで制御できます。

物理サイズと利用可能な物理サイズ物理サイズと利用可能な物理サイズ

物理サイズと利用できる物理サイズの両方で、VDO が利用できるブロックデバイス上のディスク容量が説明されています。

物理サイズ物理サイズは、基礎となるブロックデバイスと同じサイズです。VDO は、このストレージを以下に使用します。

重複排除・圧縮できるユーザーデータ

UDS インデックスなどの VDO メタデータ

利用可能な物理サイズ利用可能な物理サイズは、VDO がユーザーデータ使用できる物理サイズの部分です。

これは、物理サイズからメタデータのサイズを引き、指定のスラブサイズでスラブにボリュームを分割した後に残りを引いたものと同等です。


274

たとえば、さまざまなサイズのブロックデバイスに必要なストレージ VDO メタデータの数などについては、「物理ボリュームサイズによる VDO システム要件の例」を参照してください。

論理サイズ論理サイズ

--vdoLogicalSize オプションが指定されると、論理ボリュームサイズはデフォルトで利用できる物理ボリュームサイズになります。図29.1「VDO ディスク整理」では、VDO が重複排除したストレージターゲットがブロックデバイスの上に完全に配置していて、VDO ボリュームの物理サイズが基礎となるブロックデバイスと同じサイズであることを意味することに注意してください。

VDO は現在、絶対最大論理サイズ 4PB の物理母リュームンのサイズの最大 256 倍の論理サイズに対応しています。

29.1.4. コマンドラインツール

VDO には、設定と管理を行うための以下のコマンドラインツールが含まれます。

vdo

VDO ボリュームの作成、設定、制御

vdostats

使用率とパフォーマンスの統計を表示

29.2. システム要件

プロセッサーのアーキテクチャーIntel 64 の命令セットを実装している 1 つ以上のプロセッサーが必要です。これは、AMD64 またはIntel 64 アーキテクチャーのプロセッサーを意味します。

RAM各 VDO ボリュームには、2 つの異なるメモリー要件があります。

VDO モジュールには、370 MB とさらに 268 MBが、管理される物理ストレージの 1 TB ごとに必要になります。

Universal Deduplication Service (UDS) インデックスは、最低 250 MB の DRAM を必要とします。これは、重複排除に必要なデフォルトの容量です。UDS のメモリー使用率の詳細は、「UDS インデックスメモリー要件」を参照してください。

ストレージVDO ボリュームは、シンプロビジョニングされたブロックデバイスです。物理スペースが不足しないようにするには、後で拡張できるボリュームをストレージに配置します。このような拡張可能なストレージの例は、LVM ボリュームまたは MD RAID アレイです。

単一の VDO ボリュームは、最大 256 TB の物理ストレージを使用するように設定できます。VDO が与えられているストレージプールの物理サイズから VDO マネージドボリュームの使用可のサイズを判別するには、「VDO ストレージ領域の要件」を参照してください。

追加のシステムソフトウェアVDO は以下のソフトウェアに依存します。

LVM


275

Python 2.7

yum パッケージマネージャーは、すべての必要なソフトウェアの依存関係を自動的にインストールします。

ストレージスタックの VDO の配置一般に、特定のストレージ層は VDO に配置し、その他は VDO 上に配置する必要があります。

VDO 下: DM-Multipath、DM-Crypt、ソフトウェア RAID (LVM または mdraid)。

VDO の上: LVM キャッシュ、LVM スナップショット、LVM シンプロビジョニング

以下の設定には対応していません。

VDO ボリューム上の VDO: ストレージ → LVM → VDO

LVM スナップショット上の VDO

LVM キャッシュ上の VDO

ループバックデバイス上の VDO

LVM シンプロビジョニング上の VDO

VDO 上の暗号化されたボリューム: ストレージ → VDO → DM-Crypt

VDO ボリューム上のパーティション: fdisk、parted、および同等のパーティション

VDO ボリューム上の RAID (LVM、MDまたはその他のタイプ)

重要重要

VDO は、sync と async の 2 つの書き込みモードに対応しています。VDO が sync モードに切り替わっている場合、VDO デバイスへの書き込みは、基礎となるストレージがデータを永続的に書き込んだときに承認されます。VDO が async モードに切り替わっている場合は、永続ストレージに書き込まれる前に承認されます。

基礎となるストレージの動作に一致させるためにも VDO 書き込みポリシーを設定することが不可欠です。デフォルトでは、VDO 書き込みポリシーは auto オプションに設定されます。これにより、適切なポリシーが自動的に選択されます。

詳細は「VDO 書き込みモードの選択」を参照してください。

29.2.1. UDS インデックスメモリー要件

UDS インデックスは 2 つの部分から成ります。

一意のブロックごとに最大 1 つのエントリーを含むメモリーでは、コンパクトな表が用いられています。

発生する際に、インデックスに対して示される関連のブロック名を順に記録するオンディスクコンポーネント。

UDS は、メモリーの各エントリーに対して平均 4 バイトを使用します (キャッシュを含む)。

オンディスクコンポーネントは、UDS に渡されたデータの有限履歴を維持します。UDS では、この重


276

複排除ウィンドウ内に収まるデータに対する重複排除アドバイスを参照できます。これには、最近表示されたブロックの名前が含まれます。この重複排除ウィンドウでは、UDS が、大容量のデータレポジトリをインデックス化するのに必要なメモリの量を制限すると同時に、可能な限り効率よくデータをインデックス化できます。重複排除ウィンドウの制限をよそに、最高レベルの重複排除を持つ多くのデータベースも、最高峰の一時ローカリティー — を示します。つまり、多くの重複排除は、ほぼ同じときに書き込まれた一連のブロックで行われるということを意味します。さらに、一般的に書き込まれるデータは、だいぶ前に書き込まれたデータよりも、最近先込まれたデータの重複を排除する傾向があります。よって、指定した期間にわたる指定のワークロードについては、UDSが最近のデータまたはすてぼのデータのみをいデックス化するかどうかについて、重複率が同じになることが多々あります。

重複データは一時的なローカリティーを示す傾向があるため、ストレージシステムで各ブロックをインデックス化する必要はほぼありません。そうでなかれば、インデックスメモリーのコストが、重複排除によって軽減したストレージコストの節約量を上回ります。インデックスサイズの要件は、データ取得の率に密接により関連しています。たとえば、合計 100 TB の容量があっても、1 週間に 1 TB という消費率のストレージシステムを考慮してください。4 TB の重複排除ウィンドウにより、UDS は前月内に書き込まれたデータの中から最も冗長性のあるものを検出できます。

UDS のスパースインデックス (Sparce Indexing) 機能 (VDO の推奨モード) は、メモリ内の最も関連性のあるインデックスエントリーのみの取得を試行することで一時的なローカリティーを利用します。UDS は、同じ量のメモリーを使用しならが、10 倍の大きさの重複排除ウィンドウを維持できます。スパースインデックスは対象範囲が最も広く、密インデックスはより多くの通知を行います。多くのワークロードについては、同じ量のメモリーを考えると、密インデックスとスパースインデックスの重複排除率における差異はほぼありません。

このインデックスに必要なメモリーは、希望のサイズの重複排除ウィンドウによって判別されます。

密インデックスについては、UDS は 1 GB の RAM ごとに 1 TB の重複排除ウィンドウを与えます。通常、最大 4 TB までのストレージシステムには 1 GB インデックスで十分です。

スパースインデックスについては、UDS は 1 GB の RAM ごとに 10 TB の重複排除ウィンドウを与えます。通常、最大 40 TB までの物理ストレージには 1 GB のスパースインデックスで十分です。

UDS インデックスメモリー要件の具体事例は、「物理ボリュームサイズによる VDO システム要件の例」を参照してください。

29.2.2. VDO ストレージ領域の要件

VDO は、VDO メタデータと実際の UDS 重複排除インデックスの両方にストレージが必要です。

VDO は、その基礎となる物理ストレージに 2 種類のメタデータを書き込みます。

最初のタイプは、VDO ボリュームの物理サイズに対応し、物理ストレージの各 4 GB に約1MB を使用し、スラブごとにさらに 1 MB を使用します。

次のタイプは、VDO ボリュームの論理サイズに対応し、論理ストレージの各 1 GB に約1.25 MB を消費します。これは、スラブに四捨五入されます。

スラブの説明は、「VDO ボリューム」を参照してください。

UDS インデックスは、VDO ボリュームグループ内に格納され、関連の VDO インスタンスによって管理されます。必要なストレージの容量は、インデックスのタイプと、インデックスに割り当てられている RAM の容量によります。RAM の各 1 GB ごとに、密 UDS インデックスは、ストレージの 17 GB を使用します。また、スパース UDS インデックスはストレージの 170GB を使用します。

VDO ストレージ要件の具体事例は、「物理ボリュームサイズによる VDO システム要件の例」を参照し


277

VDO ストレージ要件の具体事例は、「物理ボリュームサイズによる VDO システム要件の例」を参照してください。

29.2.3. 物理ボリュームサイズによる VDO システム要件の例

以下の表では、基礎となる物理ボリュームのサイズに基づいて VDO のおおよそのシステム要件を示しています。各表では、プライマリストレージやバックアップストレージといった、意図されたディプロイメントに合った要件が一覧表示されています。

正確な数値は、VDO ボリュームの設定により異なります。

プライマリーストレージディプロイメントプライマリーストレージディプロイメント

プライマリーストレージケースの場合、UDS インデックスは、物理ボリュームの 0.01% から 25％のサイズになります。

表表29.2 プライマリストレージのプライマリストレージの VDO ストレージとメモリー要件ストレージとメモリー要件

物理ボリュー物理ボリュームサイズムサイズ

10 GB – 1–TB 2–10 TB 11–50 TB 51–100 TB 101–256 TB

RAM 使用率使用率 250 MB Dense: 1 GB

Sparse:250 MB

2 GB 3 GB 12 GB

ディスクの使ディスクの使用率用率

2.5 GB Dense: 10 GB

Sparse: 22 GB

170 GB 255 GB 1020 GB

インデックスインデックスタイプタイプ

Dense Dense またはSparse

Sparse Sparse Sparse

バックアップストレージディプロイメントバックアップストレージディプロイメント

バックアップストレージケースの場合、UDS インデックスは、バックアップセットのサイズを対象としますが、物理ボリュームよりも大きいわけではありません。バックアップセットや物理サイズが将来増大する見込みがある場合は、これをインデックスサイズに考慮してください。

表表29.3 バックアップストレージのバックアップストレージの VDO ストレージとメモリ要件ストレージとメモリ要件

物理ボリュー物理ボリュームサイズムサイズ

10 GB – 1 TB 2–10 TB 11–50 TB 51–100 TB 101–256 TB

RAM 使用率使用率 250 MB 2 GB 10 GB 20 GB 26 GB

ディスクの使ディスクの使用率用率

2.5 GB 170 GB 850 GB 1700 GB 3400 GB

インデックスインデックスタイプタイプ

Dense Sparse Sparse Sparse Sparse


278

29.3. VDO の使用

29.3.1. はじめに

VDO (Virtual Data Optimizer) は、重複排除、圧縮、およびシンプロビジョニングの形で、Linux でインラインのデータ削減を行います。VDO ボリュームを設定する場合は、VDO ボリュームを構築するブロックデバイスと、作成する論理ストレージのサイズを指定します。

アクティブな VM またはコンテナーをホストする際、Red Hat では、10:1 の論理・物理の割合でストレージのプロビジョニングを行うことをおすすめしています。1 TB の物理ストレージを利用している場合は、10 TB の論理ストレージとして示します。

Ceph が提供するタイプなどのオブジェクトストレージの場合、Red Hat は、物理と論理の割合を 1 対 3 にすることを推奨します。つまり、物理ストレージを 1 TB にした場合は、論理ストレージを 3 TB にします。

いずれの場合も、VDO が作成する論理デバイスにファイルシステムを置くだけで、直接使用することも、分散クラウドストレージアーキテクチャーの一部として使用することもできます。

本章は、VDO デプロイメントのユースケースを説明します。

Red Hat Virtualization を使用して構築した場合など、仮想サーバーで直接接続するユースケース

Ceph Storage を使用して構築された場合など、オブジェクトベースの分散ストレージクラスターのクラウドストレージのユースケース

注記注記

Ceph による VDO ディプロイメントには現在対応していません。

この章では、どちらのユースケースにも簡単にデプロイできる、標準の Linux ファイルシステムで使用する VDO の設定例を示します。詳細は「ディプロイメント例」の図をご覧ください。

29.3.2. VDO のインストール

VDO は、以下の RPM パッケージを使用してディプロイされます。

vdo

kmod-kvdo

VDO をインストールするには、yum パッケージマネージャーを使用して RPM パッケージをインストールします。

# yum install vdo kmod-kvdo

29.3.3. VDO ボリュームの作成

ブロックデバイスのボリュームを作成します。複数の VDO ボリュームを、同じマシンにある複数のデバイスに作成できます。この方法を選択する場合は、システムの VDO の各インスタンスに、それぞれ別の名前とデバイスを指定する必要があります。

重要重要


279

重要重要

拡張可能なストレージをバッキングブロックデバイスとして使用します。詳細は、「システム要件」を参照してください。

以下のすべての手順で、vdo_name を、VDO ボリュームに使用する識別子 (vdo1 など) に置き換えます。

1. VDO Manager を使用して VDO ボリュームを作成します。

# vdo create \ --name=vdo_name \ --device=block_device \ --vdoLogicalSize=logical_size \ [--vdoSlabSize=slab_size]

block_device を、VDO ボリュームを作成するブロックデバイスの永続名 (/dev/disk/by-id/scsi-3600508b1001c264ad2af21e903ad031f など) に置き換えます。

重要重要

永続的なデバイス名を使用します。永続的出ないデバイス名を使用すると、デバイスの名前が変わった場合に VDO は今後正しく起動しなくなることがあります。

永続的な名前の詳細は、「永続的な命名」を参照してください。

logical_size を、VDO ボリュームが含まれる論理ストレージのサイズに置き換えます。

アクティブな仮想マシンまたはコンテナーストレージの場合は、使用する論理のサイズを、ブロックデバイスの物理サイズの 10 倍になるようにします。たとえば、ブロックデバイスのサイズが 1 TB の場合は、10T を使用します。

オブジェクトストレージの場合は、使用する論理のサイズを、ブロックデバイスの物理サイズの 3 倍になるようにします。たとえば、ブロックデバイスのサイズが 1 TB の場合は、3T を使用します。

ブロックデバイスが 16 TiB より大きい場合は、--vdoSlabSize=32G を指定して、ボリューム上のスラブサイズを 32 GiB に壮大します。

16 TiB を超えるブロックデバイス上の 2 GiB のデフォルトスラブサイズを使用すると、vdo create コマンドが以下のエラーで失敗します。

vdo: ERROR - vdoformat: formatVDO failed on '/dev/device': VDO Status: Exceeds maximum number of slabs supported

詳細は「VDO ボリューム」を参照してください。

例例29.1 コンテナーストレージ用にコンテナーストレージ用に VDO 用の作成用の作成

たとえば、1 TB ブロックデバイスでコンテナーストレージ用に VDO ボリュームを作成するには、次のコマンドを実行します。

# vdo create \


280

--name=vdo1 \ --device=/dev/disk/by-id/scsi-3600508b1001c264ad2af21e903ad031f \ --vdoLogicalSize=10T

VDO ボリュームを作成すると、VDO により /etc/vdoconf.yml 設定ファイルにエントリーが追加されます。次に、vdo.service systemd ユニットを使用して、デフォルトでボリュームを起動します。

重要重要

VDO ボリュームを作成する際にエラーが発生する場合は、ボリュームを削除してクリーンアップします。詳細は、「作成に失敗したボリュームの削除」を参照してください。

2. ファイルシステムを作成します。

XFS ファイルの場合:

# mkfs.xfs -K /dev/mapper/vdo_name

ext4 ファイルシステムの場合:

# mkfs.ext4 -E nodiscard /dev/mapper/vdo_name


# mkdir -m 1777 /mnt/vdo_name# mount /dev/mapper/vdo_name /mnt/vdo_name

4. ファイルシステムを設定して自動的にマウントするには、/etc/fstab ファイルまたは systemd胸トユニットのいずれかを使用します。

/etc/fstab 設定ファイルを使用する場合は、以下の行をファイルに追加します。

XFS ファイルの場合:

/dev/mapper/vdo_name /mnt/vdo_name xfs defaults,_netdev,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0

ext4 ファイルシステムの場合:

/dev/mapper/vdo_name /mnt/vdo_name ext4 defaults,_netdev,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0

または、systemd unit を使用する場合、正しいファイル名で systemd マウントユニットファイルを作成します。VDO ボリュームのマウントポイントは、/etc/systemd/system/mnt-vdo_name.mount ファイルを以下の内容で作成してください。

[Unit]Description = VDO unit file to mount file system


281

name = vdo_name.mountRequires = vdo.serviceAfter = multi-user.targetConflicts = umount.target

[Mount]What = /dev/mapper/vdo_nameWhere = /mnt/vdo_nameType = xfs

[Install]WantedBy = multi-user.target

例の systemd ユニットファイルは、/usr/share/doc/vdo/examples/systemd/VDO.mount.example でもインストールされます。

5. VDO デバイスのファイルシステムで discard 機能を有効にします。パッチ操作とオンライン操作の両方が VDO で有効です。

discard 機能の設定の詳細は、「未使用ブロックの破棄」を参照してください。

29.3.4. VDO の監視

VDO はシンプロビジョニングされているため、ファイルシステムとアプリケーションには、使用中の論理領域のみが表示されるため、利用できる実際の物理容量を認識しません。

VDO 容量の使用率と効率は、vdostats ユーティリティを使用して監視できます。

# vdostats --human-readable

Device 1K-blocks Used Available Use% Space saving%/dev/mapper/node1osd1 926.5G 21.0G 905.5G 2% 73% /dev/mapper/node1osd2 926.5G 28.2G 898.3G 3% 64%

VDO ボリュームの物理ストレージ容量が不足しそうになると、VDO はシステムログに警告を報告します。以下のようなものになります。

Oct 2 17:13:39 system lvm[13863]: Monitoring VDO pool vdo_name.Oct 2 17:27:39 system lvm[13863]: WARNING: VDO pool vdo_name is now 80.69% full.Oct 2 17:28:19 system lvm[13863]: WARNING: VDO pool vdo_name is now 85.25% full.Oct 2 17:29:39 system lvm[13863]: WARNING: VDO pool vdo_name is now 90.64% full.Oct 2 17:30:29 system lvm[13863]: WARNING: VDO pool vdo_name is now 96.07% full.

重要重要

VDO ボリューム上の物理容量を監視し、容量不足を回避します。物理ブロックが不足すると、VDO ボリューム上の最近の書き込まれた未承認のデータが失われることがあります。

29.3.5. ディプロイメント例

以下の例では、KVM とその他のディプロイメントで VDO を使用できる方法を示しています。


282

KVM を使用したを使用した VDO デプロイメントデプロイメント

DAS (Direct Attached Storage) を使用して設定した KVM サーバーに VDO を正常にデプロイする方法は、図29.2「KVM を使用した VDO デプロイメント」を参照してください。

図図29.2 KVM を使用したを使用した VDO デプロイメントデプロイメント

その他のディプロイメントシナリオその他のディプロイメントシナリオ

VDO ディプロイメントの詳細は、「ディプロイメントシナリオ」を参照してください。

29.4. VDO の管理

29.4.1. VDO の開始または停止

指定の VDO ボリューム、またはすべての VDO ボリューム、関連の UDS インデックスを開始するには、管理ユーティリティが以下のコマンドのいずれかを起動する必要があります。

# vdo start --name=my_vdo# vdo start --all

vdo パッケージをインストールすると、VDO systemd ユニットがデフォルトでインストールされ有効化されます。このユニットはシステムスタートアップで自動的に vdo start --all を実行し、すべての有有効化された効化された VDO ボリュームを起動します。詳細は「システムブートで VDO ボリュームを自動的に起動」を参照してください。

指定の VDO ボリューム、すべての VDO ボリューム、関連の UDS インデックスを停止するには、以下のコマンドのいずれかを使用します。

# vdo stop --name=my_vdo# vdo stop --all

VDO ボリュームの停止には、ストレージデバイスの速度とボリュームが書き込む必要があるデータ量に基づいた時間がかかります。

ボリュームは、UDS インデックスの 1GiB ごとに常に約 1GiB を書き込みます。

スパース UDS インデックスでは、ボリュームはブロックマップキャッシュサイズに加えてスラブごとに最大 8MiB のデータ量を追加で書き込みます。


283

正常でないシャットダウン後に再起動すると、VDO はメタデータの一貫性を確認するために再構築を行い、必要であれば修復を行います。再構築は自動で、ユーザーの介入は不要です。再構築プロセスの詳細は、「正常でないシャットダウン後の VDO ボリュームのリカバリー」を参照してください。

VDO は、書き込みモードに依存する各種書き込みを再構築します。

同期モードでは、シャットダウンの前に VDO によって承認されたすべての書き込みが再構築されます。

非同期モードでは、前回の承認したフラッシュリクエストの前に承認されたすべての書き込みが再構築されます。

どちらのモードであっても、フラッシュによって承認されていない、あるいは確認されていない一部の書き込みも再構築されることがあります。

VDO 書き込みモードの詳細は、「VDO 書き込みモードの選択」を参照してください。

29.4.2. VDO 書き込みモードの選択

VDO は、sync、async、auto の 3 つの書き込みモードに対応しています。

VDO が sync モードに切り替わっている場合、その上の層は、書き込みコマンドがデータを永続ストレージに書き込むことを想定します。結果として、ファイルシステムやアプリケーションには不要です。たとえば、FLUSH または Force Unit Access (FUA) リクエストを発行すると、データが重要な点で永続になります。

VDO は、書き込みコマンドが完了したときにデータが永続ストレージに買い込まれることを基礎となるストレージが保証するとにのみ、sync モードに切り替える必要があります。つまり、ストレージは、揮発性のある書き込みキャッシュがない状態か、キャッシュからの書き込みがある状態のいずれかである必要があります。

VDO が async モードに指定されていると、書き込みコマンドが承認されたときに永続ストレージへのデータの書き込みが保証されなくなります。このファイルシステムまたはアプリケーションは FLUSH または FUA リクエストを発行紙、各トランザクションの重要な点でデータの永続性を確率する必要があります。

書き込みコマンドが完了したときに基礎となるストレージが永続ストレージに対するデータの書き込みを保証しない場合は VDO を async モードに設定する必要があります。これは、ストレージに揮発性のあるライトバックキャッシュがある場合です。

デバイスが揮発性キャッシュを使うかどうかを調べる方法は、「揮発性キャッシュの確認」を参照してください。

警告警告

VDO が async モードで稼働している場合は、Atomicity、Consistency、Isolation、Durability (ACID) に準拠しません。VDO ボリューム上で ACIDコンプライアンスを想定するアプリケーションやファイルシステムがある場合は、async モードにより、予期しないデータの損失が発生することがあります。

auto モードは、各デバイスの性質に基づいて sync または async を自動的に選択します。これ


284

auto モードは、各デバイスの性質に基づいて sync または async を自動的に選択します。これはデフォルトのオプションです。

書き込みポリシーが動作する、より詳細な論理概要は、「VDO 書き込みポリシーの概要」を参照してください。

書き込みポリシーを設定するには、--writePolicy オプションを指定します。これは、VDO ボリュームを「VDO ボリュームの作成」で作成するとき、または changeWritePolicy サブコマンドで既存のVDO ボリュームを変更するときのいずれかで指定できます。

# vdo changeWritePolicy --writePolicy=sync|async|auto --name=vdo_name

重要重要

正しくない書き込みポリシーを使用すると、電源故障の際にデータが失われることがあります。

揮発性キャッシュの確認揮発性キャッシュの確認

デバイスに書き込みキャッシュがあるかどうかを調べるには、/sys/block/block_device/device/scsi_disk/identifier/cache_type sysfs ファイルを読みます。例:

デバイス sda には、書き込みキャッシュがあるあることが示されています。

$ cat '/sys/block/sda/device/scsi_disk/7:0:0:0/cache_type'

write back

デバイス sda には、書き込みキャッシュがないないことが示されています。

$ cat '/sys/block/sdb/device/scsi_disk/1:2:0:0/cache_type'

None

また、カーネルブートログでは、上記のデバイスに書き込みキャッシュがあるかどうかを調べることができます。

sd 7:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUAsd 1:2:0:0: [sdb] Write cache: disabled, read cache: disabled, supports DPO and FUA

システムログの読み方は、『システム管理者のガイド』の「ログファイルの表示と管理を参照してください。

これらの例では、以下の VDO の書き込みポリシーを使用します。

sda デバイスの async モード

sdb デバイスの sync モード

注記注記

cache_type の値が none または write through である場合は、sync 書き込みポリシーを使用するように VDO を設定する必要があります。


285

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#ch-Viewing_and_Managing_Log_Files

29.4.3. VDO ボリュームの削除

VDO ボリュームは、以下を実行してシステムから削除できます。

# vdo remove --name=my_vdo

VDO ボリュームを削除する前に、ファイルシステムのマウントを解除して、ストレージを使用しているアプリケーションを停止します。 vdo remove コマンドは、VDO ボリュームと関連の UDS インデックスと同様、属する論理ボリュームを削除します。

29.4.3.1. 作成に失敗したボリュームの削除作成に失敗したボリュームの削除

vdo ユーティリティが VDO ボリュームを作成する際にエラーが発生した場合、ボリュームは中間状態のままになります。これはたとえば、システムがクラッシュした場合や、電源が故障した場合、実行中の vdo create コマンドを管理者が中断した場合に発生する可能性があります。

この状況に対処するには、--force オプションを指定して作成に失敗したボリュームの削除を行います。

# vdo remove --force --name=my_vdo

ボリュームの作成に失敗して以来、管理者がシステム設定を変更して競合を発生させたため --force オプションの指定が必要となります。--force オプションを指定しないと、vdo remove コマンドは以下のメッセージとともにエラーを返します。

[...]A previous operation failed.Recovery from the failure either failed or was interrupted.Add '--force' to 'remove' to perform the following cleanup.Steps to clean up VDO my_vdo:umount -f /dev/mapper/my_vdoudevadm settledmsetup remove my_vdovdo: ERROR - VDO volume my_vdo previous operation (create) is incomplete

29.4.4. UDS インデックスの設定

VDO は、高パフォーマンス重複排除インデックスである UDS を使用して、格納されているデータの重複ブロックを検出します。重複排除ウィンドウは、インデックスが記憶している以前に書き込まれたブロックの数です。重複排除ウィンドウのサイズは調整可能です。指定のウィンドウサイズについては、インデックスが特定の量の RAM やディスク容量を必要とします。ウィンドウのサイズは通常、--indexMem=size オプションを指定してインデックスメモリーのサイズを指定して判別されます。使用するディスク容量は、自動的に定められます。

一般的に、Red Hat では、すべてのプロダクションユースケースに sparse UDS インデックスの使用をお勧めしています。これは、非常に効率的なインデックスデータ構造で、重複排除ウィンドウのブロックごとに約 10 分の 1 の DRAM のバイトが必要となります。ディスクでは、ブロックごとに約 72 バイトのディスク容量が必要となります。このインデックスの最小設定は、256 MB の DRAM とディスク上の約 25 GB の容量を使用します。この設定を使用するには、--sparseIndex=enabled --indexMem=0.25オプションを vdo create コマンドに指定します。この設定では、2.5 TB (つまり、2.5 TB の履歴を記憶する) の重複排除ウィンドウが指定されます。多くのユースケースでは、最大 10 TB のサイズのストレージプールの重複排除に 2.5 TB の重複排除ウィンドウで十分です。

ただし、インデックスのデフォルト設定は、dense インデックスを使用します。このインデックスは、


286

ただし、インデックスのデフォルト設定は、dense インデックスを使用します。このインデックスは、DRAM におけて非常に効率が低い (10 倍) ですが、必要最低ディスク容量もかなり低く (10 倍) なっています。これにより、制約のある環境での評価には便利です。

一般的に、VDO ボリュームの物理サイズの 4 分の 1 の重複排除ウィンドウが推奨された設定と言えます。ただし、これは実際の要件ではありません。小さな重複排除ウィンドウ (物理ストレージの量に比べて) であっても、多くのユースケースで壮大な量の重複データを見つけることができます。さらに大きなウィンドウも使用できますが、多くの場合、あまりメリットがありません。

この重要なシステムパラメーターの調整は、Red Hat テクニカルアカウントマネージャーまでご相談ください。

29.4.5. 正常でないシャットダウン後の VDO ボリュームのリカバリー

正常にシャットダウンしなかったボリュームを再起動すると、VDO は動作を継続させるためにメタデータの一部を再構築する必要があります。これは、ボリュームが起動した際に自動的に行われます。(正常にシャットダウンされていないボリュームで、このプロセスを実行するには、「再構築の強制」も参照してください。)

データのリカバリーは、デバイスの書き込みポリシーに依存します。

VDO が同期ストレージで稼働していて、書き込みポリシーが sync に設定されていた場合は、ボリュームに書き込まれたすべてのデータが完全に復元されます。

書き込みポリシーが async であった場合、VDO に FLUSH コマンドを送信したり、FUA フラグ (強制ユニットアクセス) でタグづけられた書き込み I/O で強化されていない場合は、一部の書き込みは復元できないことがあります。これは、fsync、fdatasync、sync、umount などのデータの完全性の操作を実行することでユーザーモードから実現できます。

29.4.5.1. オンラインリカバリーオンラインリカバリー

多くの場合、正常でない VDO ボリュームの再構築作業の大部分は、VDO ボリュームがオンラインになってからや、読み書きリクエストをサービスしているときに行うことができます。最初に、書き込みリクエストに利用可能な容量は制限されることがあります。ボリュームのメタデータの多くが復元されると、より多くの空き容量が利用できるようになります。さらに、まだリカバリーされていない一部のボリュームにデータが存在すると、VDO の復元中に書き込まれたデータの、クラッシュ前に書き込まれたデータに対する重複排除に失敗する可能性があります。データは、ボリュームがリカバリーされているときに圧縮することができます。以前に圧縮したブロックは依然として読み込みや上書きを行うことができます。

オンラインリカバリーを行う際、統計の多くは利用できません。たとえば、使用中のブロック使用中のブロックや空きブ空きブロックロックなどは参照できません。これらの統計は、再構築が完了してから参照可能になります。

29.4.5.2. 再構築の強制再構築の強制

VDO は、多くのハードウェアやソフトウェアエラーから復元できます。VDO ボリュームのリカバリーを正しく行えない場合は、ボリュームの再起動にわたり永続する読み取り専用モードに置かれます。ボリュームが読み取り専用モードになると、データの保持や正常性が保証されなくなります。このような場合、Red Hat では、読み取り専用ボリュームからデータをコピーし、バックアップからボリュームを復元することをおすすめします。(vdostats コマンドの操作モード操作モードの属性は、読み取り専用モードです。)

データ破損のリスクを受け入れられる場合は、VDO ボリュームのメタデータのオフライン再構築を強制することも可能です。これにより、ボリュームをオンラインに戻し、利用できるようにできます。繰り返しますが、再構築したデータの完全性は保証できません。

読み取り専用の VDO ボリュームの再構築を強制するには、まず、ボリュームが稼働している場合は停


287

読み取り専用の VDO ボリュームの再構築を強制するには、まず、ボリュームが稼働している場合は停止します。

# vdo stop --name=my_vdo

--forceRebuild オプションを指定してボリュームを再起動します。

# vdo start --name=my_vdo --forceRebuild

29.4.6. システムブートで VDO ボリュームを自動的に起動

システムブートの際、vdo systemd ユニットは、activatedとして設定されている VDO デバイスすべてを自動的に起動します。

特定の既存のボリュームが自動的に起動しないようにするには、以下のコマンドのいずれかを実行して、これらのボリュームを無効化無効化します。

特定のボリュームを無効化するには以下を実行します。

# vdo deactivate --name=my_vdo

すべてのボリュームを無効化するには以下を実行します。

# vdo deactivate --all

逆に、ボリュームを有効化するには、以下のコマンドのいずれかを実行します。

特定のボリュームを有効化するには以下を実行します。

# vdo activate --name=my_vdo

すべてのボリュームを有効化するには以下を実行します。

# vdo activate --all

--activate=disabled オプションを vdo create コマンドに指定することで、自動的に起動しない VDOボリュームを作成できます。

VDO ボリューム上に LVM ボリュームを配置するシステムと同様、VDO ボリューム下に配置するシステムについては (例: 図29.5「重複排除された統合ストレージ」)、適切な順序でサービスを起動することが重要です。

1. LVM の低層を最初に起動する必要があります (多くのシステムでは、LVM2 パッケージがインストールされていれば、この層を起動するように自動的に設定されています)。

2. 次に、vdo systemd ユニットを起動する必要があります。

3. 最後に、LVM ボリュームやその他のサービスを、稼働している VDO 上で実行するには、その他のスクリプトを実行する必要があります。

29.4.7. 重複排除の無効化と再有効化

一部の例では、ボリュームへの読み書きを行うことができる状態で VDO ボリュームに書き込まれてい


288

一部の例では、ボリュームへの読み書きを行うことができる状態で VDO ボリュームに書き込まれているデータの重複排除を一時的に無効化することが求められることがあります。重複排除を無効化すると、後続の書き込みが重複排除されなくなるため、すでに重複排除されたデータが残ります。

VDO ボリュームでの重複排除を停止するには、以下のコマンドを使用します。

# vdo disableDeduplication --name=my_vdo

これにより、関連の UDS インデックスを停止し、重複排除がアクティブでなくなったことをVDO ボリュームに伝えます。

VDO ボリュームでの重複排除を再起動するには、以下のコマンドを使用します。

# vdo enableDeduplication --name=my_vdo

これにより、関連の UDS インデックスを再起動し、重複排除が再びアクティブになったことをVDO ボリュームに認識させます。

--deduplication=disabled オプションを vdo create コマンドに指定することで、新しい VDO ボリュームを作成するときに重複排除を無効化することができます。

29.4.8. 圧縮の使用

29.4.8.1. はじめにはじめに

ブロックレベルの重複排除に加え、VDO では、HIOPS Compression™ テクノロジーを使用することでインラインブロックレベルの圧縮も使用できます。重複排除は仮想マシン環境やバックアップアプリケーションにとって最適なソリューションですが、一般的にブロックレベルの冗長性を見せないログファイルやデータベースなど構造化・未構造化ファイル形式には、圧縮がよく機能します。

圧縮は、重複として識別されていないブロックで動作します。一意のデータが初めて見つかった場合に圧縮されます。既に格納されているデータの後続のコピーは、その他の圧縮手順を必要とせずに重複排除されます。この圧縮機能は、１度に多くの圧縮操作を処理できるようにする並列パッキングアルゴリズムに基づいています。ブロックの最初の並び替えや、リクエスト元への応答を終えると、最適なパッキングアルゴリズムが複数のブロックを見つけ、圧縮されると、単一の物理ブロックに収まることができます。特定の物理ブロックが追加のアシュクブロックを保持できないと判断されると、ストレージに書き込まれ、圧縮されていないブロックが解放されて再利用されます。既にリクエスト元に応答してから、この圧縮とパッキング操作を行うことで、圧縮によりレイテンシーによるペナルティーを最低限に抑えることができます。

29.4.8.2. 圧縮の有効化と無効化圧縮の有効化と無効化

VDO ボリューム圧縮はデフォルトでオンになっています。

ボリュームを作成する際、--compression=disabled オプションを vdo create コマンドに追加することで圧縮を無効化できます。

圧縮は、必要であれば既存の VDO ボリュームで停止することで、パフォーマンスを最大化することや、圧縮できないと思われるデータの処理を高速化できます。

VDO ボリュームで圧縮を停止するには、以下のコマンドを使用します。

# vdo disableCompression --name=my_vdo


289

再び起動するには、以下のコマンドを使用します。

# vdo enableCompression --name=my_vdo

29.4.9. 空き容量の管理

VDO は、シンプロビジョニングされたブロックストレージターゲットであるため、VDO が使用する物理容量が、ストレージのユーザーに示されているボリュームのサイズと異なることがあります。インテグレーターやシステム管理者は、この相違点を利用して、ストレージコストを節約することができますが、書き込まれたデータが、期待した重複排除率を実現できない場合は、ストレージ容量が予期しない状態で発生しないように注意することが重要です。

論理ブロック (仮想ストレージ) の数が物理ブロック (実際のストレージ) の数を上回ると、ファイルシステムやアプリケーションが予期せずに容量不足になることがあります。このため、VDO を使用しているストレージシステムは、VDO の空きプールのサイズを監視する方法をストレージ管理者に提供する必要があります。この空きプールのサイズは、vdostats ユーティリティを使用して判別できます。詳細は、「vdostats」を参照してください。このユーティリティのデフォルトの出力は、Linux dfユーティリティに類似した形式で実行しているすべての VDO ボリュームの情報を一覧表示します。例:

Device 1K-blocks Used Available Use%/dev/mapper/my_vdo 211812352 105906176 105906176 50%

VDO ボリュームの物理ストレージ容量が不足しそうになると、VDO はシステムログに警告を報告します。以下のようなものになります。

Oct 2 17:13:39 system lvm[13863]: Monitoring VDO pool my_vdo.Oct 2 17:27:39 system lvm[13863]: WARNING: VDO pool my_vdo is now 80.69% full.Oct 2 17:28:19 system lvm[13863]: WARNING: VDO pool my_vdo is now 85.25% full.Oct 2 17:29:39 system lvm[13863]: WARNING: VDO pool my_vdo is now 90.64% full.Oct 2 17:30:29 system lvm[13863]: WARNING: VDO pool my_vdo is now 96.07% full.

VDO 空きプールのサイズが特定のレベルを下回ると、ストレージ管理者は、データの削除 (削除したデータが重複していないときに容量を再取得する)、物理ストレージの追加、または LUN の削除を行って対処できます。

重要重要

VDO ボリューム上の物理容量を監視し、容量不足を回避します。物理ブロックが不足すると、VDO ボリューム上の最近の書き込まれた未承認のデータが失われることがあります。

ファイルシステムでの容量の再取得ファイルシステムでの容量の再取得

ファイルシステムが DISCARD、TRIM、または UNMAP コマンドを使用してブロックが空いていることを通信しない限り、VDO は容量を再取得できません。DISCARD、TRIM、または UNMAP を使用しないファイルシステムについては、バイナリのゼロからなるファイルを保存して、そのファイルを削除することで手動で再取得できます。

ファイルシステムは、2 つのうちいずれか 1 つの方法で DISCARD リクエストを発行するように設定できます。

リアルタイム破棄リアルタイム破棄 (オンライン破棄またはインライン破棄オンライン破棄またはインライン破棄)

リアルタイム破棄が有効化されると、ファイルシステムは、ユーザーがファイルを削除して容量を


290

リアルタイム破棄が有効化されると、ファイルシステムは、ユーザーがファイルを削除して容量を解放したときに REQ_DISCARD リクエストをブロックレイヤーに送信します。VDO はこれらのリクエストを受信し、空きプールに容量を返します。ブロックが共有されていと想定します。

オンライン破棄に対応しているファイルシステムについては、マウント時に discard オプションを設定することで有効化できます。

バッチ破棄バッチ破棄

バッチ破棄はユーザー起動の操作で、ファイルシステムが、使用していないブロックのブロックレイヤー (VDO) に通知します。これは、FITRIM という ioctl リクエストをファイルシステムに送信することで行います。

fstrim ユーティリティ (cron の例) を使用することで、この ioctl をファイルシステムに送信できます。

discard 機能の詳細は、「未使用ブロックの破棄」を参照してください。

ファイルシステムなしでの容量の再取得ファイルシステムなしでの容量の再取得

ファイルシステムなしでブロックストレージターゲットとしてストレージを使用している場合でも空き容量を管理することも可能です。たとえば、単一の VDO ボリュームは、Logical Volume Manager(LVM) をその上にインストールすることで複数のサブボリュームに分割できます。ボリュームのプロビジョン解除を行う前に、blkdiscard コマンドを実行して、論理ボリュームによって以前使用されている容量を解放できます。LVM は REQ_DISCARD コマンドに対応しており、容量を解放するために適切な論理ブロックアドレスで VDO にリクエストをフォワーディングします。その他のボリュームマネージャーが使用されている場合は、REQ_DISCARD に対応するか、SCSI デバイスには UNMAP、ATA デバイスには TRIM に対応する必要があります。

ファイバーチャンネルまたはイーサネットネットワーク上での容量の再取得ファイバーチャンネルまたはイーサネットネットワーク上での容量の再取得

VDO ボリューム (ボリュームの一部) はプロビジョニングすることで、LIO や SCST などの SCSI ターゲットフレームワークを使用してファイバーチャンネルストレージファブリックやイーサネットネットワークでホストすることができます。SCSI イニシエーターは UNMAP コマンドを使用して、シンプロビジョニングしたストレージターゲットで容量を解放できます。ただし、SCSI ターゲットフレームワークは、このコマンドのサポートを通知するように設定する必要があります。UNMAP の対応は、以下のコマンドを実行して Linux ベースの SCSI イニシエーターで検証できます。

# sg_vpd --page=0xb0 /dev/device

出力では、「Maximum unmap LBA count」(最大未マッピングカウント) 値がゼロより大きいことを確認します。

29.4.10. 論理ボリュームサイズの増大

管理アプリケーションは、vdo growLogical サブコマンドを使用して VDO ボリュームの論理サイズを増大できます。ボリュームが増大したら、管理側がデバイスやVDO ボリュームの新しいサイズ上のファイルシステムに通知を行う必要があります。

# vdo growLogical --name=my_vdo --vdoLogicalSize=new_logical_size

このコマンドを使用すると、ストレージ管理者が容量が不足しないように論理サイズの十分に小さいVDO ボリュームを最初に作成できるようになります。一定期間が過ぎると、データ整理の実際の率を評価できます。十分であれば、VDO の論理サイズは、容量節約を活用するために増大できます。


291

29.4.11. 物理ボリュームサイズの増大

VDO ボリュームに利用できる物理ストレージ容量を増大するには:

1. 基礎となるデバイスのサイズを増大します。

正確な手順は、デバイスのタイプによって異なります。たとえば、MBR パーティションのサイズを変更するには、「fdisk を使用したパーティションのサイズ変更」で説明しているようにfdiskユーティリティを使用します。

2. growPhysical オプションを使用して、新しい物理ストレージ容量を VDO ボリュームに追加します。

# vdo growPhysical --name=my_vdo

このコマンドでは、VDO ボリュームを縮小することはできません。

29.4.12. Ansible による VDO の自動化

Ansible ツールを使用することで、VDO ディプロイメントと管理を自動化できます。詳細は、以下を参照してください。

Ansible ドキュメンテーション: https://docs.ansible.com/

VDO Ansible モバイルドキュメンテーション:https://docs.ansible.com/ansible/latest/modules/vdo_module.html

29.5. ディプロイメントシナリオ

VDO はさまざまな方法で展開でき、ブロックとファイルアクセスの両方、ローカルとリモートストレージの両方に重複排除したストレージを利用できます。VDO は、標準の Linux ブロックデバイスとして重複排除したストレージを認識させているため、標準ファイルシステム、iSCSI と FC ターゲットドライバーと使うことや、または統合ストレージとして使うことができます。

29.5.1. iSCSI ターゲット

シンプルな例として、VDO ストレージターゲットすべては、iSCSI ターゲットとしてリモート iSCSI イニシエーターにエクスポートできます。

図図29.3 重複排除したブロックストレージターゲット重複排除したブロックストレージターゲット

iSCSI ターゲットの詳細は、http://linux-iscsi.org/を参照してください。

29.5.2. ファイルシステム


292

https://docs.ansible.com/

https://docs.ansible.com/ansible/latest/modules/vdo_module.html

http://linux-iscsi.org/

代わりにファイルアクセスが必要な場合、ファイルシステムは VDO 上で作成でき、Linux NFS サーバーや Samba から NFS または CIFS ユーザーに使えるようにすることができます。

図図29.4 重複排除した重複排除した NAS

29.5.3. LVM

より機能豊富なシステムは、LVM を利用して、重複排除処理を施した同じストレージプールによってすべてカバーされる複数の LUN を利用できるようになります。図29.5「重複排除された統合ストレージ」では、VDO ターゲットは物理ボリュームとして登録されています。よって、LVM で管理できます。複数の論理ボリューム ((LV1 から LV4) は、重複排除されたストレージプールから作り出されます。これにより、VDO は基礎となる重複排除されたストレージプールに対する統合ブロック/ファイルアクセスに対応できます。

図図29.5 重複排除された統合ストレージ重複排除された統合ストレージ

重複排除した統合ストレージデザインでは、複数のファイルシステムが同じ重複排除ドメインを LVMツールから共同で使用できます。また、ファイルシステムはすべて VDO 上で、LVM スナップショット、copy-to-write、縮小を利用することや、機能を強化することができます。

29.5.4. 暗号化

本日、データセキュリティは非常に重要です。データの暗号化に関する内部ポリシーを採用する会社が増えています。DM-Crypt などのLinux デバイスマッパーメカニズムは VDO と互換性があります。VDO ボリュームを暗号化すると、データセキュリティの確率に役立ちます。また、依然としてVDO 上


293

のあらゆるファイルシステムがディスクの最適化のための重複排除機能を利用できます。VDO 上で暗号化を適用すると、データの重複排除が行われれば、あまり結果がでないことがあります。VDO が重複排除を行う前に、暗号化により、別の重複ブロックがレンダリングされます。

図図29.6 暗号化での暗号化での VDO の使用の使用

29.6. VOD のチューニング

29.6.1. VDO のチューニングの概要

データベースやその他複雑なソフトウェアのチューニングと同様、VDO のチューニングには、壮大なシステム制限の妥協が関与するため、いくらか実験が必要となります。VDO のチューニングに利用できるプライマリコントロールは、さまざまなタイプの作業、これらのスレッドの GPU 親和性の設定、キャッシュ設定に割り当てられたスレッドの数です。

29.6.2. VDO アーキテクチャの背景

VDO カーネルドライバーはマルチスレッドで、複数の同時 I/O リクエストにわたり処理コストを焼却することでパフォーマンスを向上します。1 つのスレッドに I/O リクエストを開始から終了まで処理させるのではなく、さまざまなステージの作業を 1 つ以上のスレッドまたはスレッドグループに委任し、I/O リクエストがパイプラインを通り抜ける際に、間にメッセージを受け渡します。これにより、1 つのスレッドは、I/O 操作が処理されるたびにロックとロック解除を行わずにグローバルデータ構造にすべてのアクセスを直列することができます。VDO ドライバーを適切にチューニングすると、要求された処理ステージをスレッドが完了するたびに、同じ処理に待ち行列に入れられた別のリクエストが存在するようになります。これらのスレッドを絶えず使うと、コンテキストの切り替えやスケジュール設定のオーバーヘッドを低減させることができ、パフォーマンスを向上できます。個別のスレッドは、基礎となるストレージシステムへの I/O オペレーションのキューの追加や、UDS へのメッセージなど、ブロックできるオペレーティングシステムの部分にも使用されます。

VDO が使用するさまざまなワーカースレッドタイプ:

ローカルゾーンスレッドローカルゾーンスレッド

logical スレッド (文字列 kvdo:logQ を含むプロセス名) は、VDO デバイスのユーザーに示される論理ブロック数 (LBN) と基礎となるストレージシステムの物理ブロック数 (PBN) 間におけるマッピングを維持します。これらは、2 つの I/O 操作をロックし、同じブロックへの書き込みが同時に処理されないようにしています。論理ゾーンスレッドは、読み込みと書き込みの両方の処理の際にアクティブになります。

LBN は小分けされます (ブロックマップページには、3 MB を超える LBN が含まれます)。分けられ


294

LBN は小分けされます (ブロックマップページには、3 MB を超える LBN が含まれます)。分けられた LBN は、スレッド間において分けられた zones へとグループ化されます。

ある不運なアクセスパターンにより、時折、何らかのスレッドに作業が集してしまうことがありますが、処理はスレッドに妥当に分配されます。たとえば、指定のブロックマップページ内の LBN に頻繁なアクセスがあると、論理スレッドの 1 つが、すべての操作を処理してしまいます。

論理ゾーンスレッドの数は、vdo コマンドに --vdoLogicalThreads=thread count オプションを指定することで制御できます。

物理ゾーンスレッド物理ゾーンスレッド

Physical、または kvdo:physQ スレッドは、データブロックの割り当てを管理し、リファレンスカウントを維持します。これらは、書き込み操作中にアクティブになります。

LBN のように、PBN は、スラブというチャンクに分けられます。これは、さらにゾーンへと分けられ、処理負荷を分配するワーカースレッドへと割り当てられます。

物理ゾーンスレッドの数は、vdo コマンドに --vdoPhysicalThreads=thread count オプションを指定することで制御できます。

I/O 発信スレッド発信スレッド

kvdo:bioQ スレッドは、VDO からストレージシステムにブロック I/O ( bio) 操作を送信します。これらは、その他の VDO スレッドによってキューに追加された I/O リクエストを取得し、基礎となるデバイスドライバーに受け渡します。このスレッドは、デバイスと通信し、デバイスに関連したデータ構造を更新します。または、処理するデバイスドライバーのカーネルスレッドのリクエストをセットアップします。I/O リクエストの送信は、基礎となるデバイスのリクエストキューがフルであればブロックできます。そのため、この作業は、処理の遅延を避けるために、専用のスレッドによって行われます。

これらのスレッドが頻繁に ps または top ユーティリティによって D 状態に示されている場合、VDO は頻繁に、I/O リクエストでストレージシステムを頻繁に使っている状態です。これは、ストレージシステムが並列に複数のリクエストをサービスできる場合は、あるいは、リクエスト処理がパイプライン型であれば良い状態です。一部の SSD は可能です。スレッド CPU 使用率が、これらの期間で非常に低い場合は、I/O 発信スレッドの数を減らせる可能性があります。

CPU 使用率とメモリ競合は、VDO 下のデバイスドライバーに依存します。より多くのスレッドが追加され、デバイスドライバーの CPU、メモリ、ロック競合をチェックすると、I/O リクエストごとの CPU 使用率が増大します。

I/O 発信スレッドの数は、vdo コマンドに --vdoBioThreads=thread count オプションを指定することで制御できます。

CPU 処理スレッド処理スレッド

kvdo:cpuQ スレッドは、その他のスレッドタイプに関連したデータ構造への排他的なアクセスをブロックしたり、これを必要としないハッシュ値の計算やデータブロックの圧縮など CPU 集約的な作業を実行するために存在します。

CPU 処理スレッドの数は、vdo コマンドに --vdoCpuThreads=thread count オプションを指定することで制御できます。

I/O 承認スレッド承認スレッド

kvdo:ackQ スレッドは、VDO 上に来るすべてに対するコールバックを発行し (たとえば、カーネルページキャッシュ、またはダイレクト I/O を行うアプリケーションプログラムスレッド)、I/O リクエストの完了を報告します。


295

承認処理スレッドの数は、vdo コマンドに --vdoAckThreads=thread count オプションを指定することで制御できます。

拡張不可拡張不可 VDO カーネルスレッドカーネルスレッド:

重複排除スレッド重複排除スレッド

kvdo:dedupeQ は、待ち行列に入れられた I/O リクエストを取得して UDS に通信します。サーバーがリクエストを十分に速く処理できない場合や、カーネルメモリがその他のシステムアクティビティによって制約されている場合、ソケットバッファーが埋まる可能性があるため、この作業は別のスレッドで行われます。つまり、スレッドがブロックする必要があれば、その他の VDO プロスは続行できます。また、長い遅延 (数秒) 後には、I/O リクエストをスキップするためのタイムアウトメカニズムもあります。

ジャーナルスレッドジャーナルスレッド

kvdo:journalQ スレッドは、リカバリージャーナルを更新し、書き込み用のジャーナルブロックのスケジュール設定を行います。VDO デバイスは、1 つのジャーナルのみを使用するため、この作業はスレッドにわたって分配できません。

パッカースレッドパッカースレッド

圧縮が有効化されている場合に書き込みパスでアクティブな kvdo:packerQ スレッドは、kvdo:cpuQ スレッドで圧縮されたデータブロックを収集し、容量の無駄を最小限に抑えます。存在するパッカーデータ構造は 1 つのみなため、VDO デバイスごとに 1 パッカースレッドが存在します。

29.6.3. チューニングする値

29.6.3.1. CPU/メモリーメモリー

29.6.3.1.1. 論理、物理、論理、物理、CPU、承認スレッドカウント、承認スレッドカウント

論理、物理、CPU、そして I/O 承認作業は、複数のスレッドにわたり分散できます。これらの数は、VDO デバイスが再起動すれば、初期設定または後で指定できます。

1 つのコア、または 1 つのスレッドは、指定した時間において無限の作業を行うことができます。1 つのスレッドがあれば、すべてのデータブロックのハッシュ値を計算できます。たとえば、毎秒処理できるデータブロックの数にハードリミットを課すことになります。複数のスレッド (およびコア) で作業を分割すると、ボトルネックを緩和できます。

スレッドまたはコアの使用率が 100% につれ、より多くの作業項目が処理のキューに追加される傾向があります。これにより、CPU のアイドルサイクルが短くなることがありますが、個別の I/O リクエストの待ち行列入れの遅延やレイテンシーは通常増加します。一部のキュー理論モデルによると、70% または 80% の使用率レベルにタスセルと、通常の処理時間よりも数倍長い角の遅延が発生することがあります。そのため、このような処理は、50% 以上の使用率でスレッドまたはコアに対してさらに作業を分配するのに役立ちます。

逆の場合では、スレッドまたは CPU には非常に軽い負荷がかかっています (頻繁にスリープ状態)。このようなものに作業を割り当てることは、さらに多くのコストが発生することになりかねません。(別のスレッドの復帰を試行するスレッドは、スケジューラーのデータ構造でグローバルロックを取得する必要があります。また、作業を別のコアに転送するためにプロセッサー間の中断を送信することもあります)。VDO スレッドで設定されるコアが多いほど、作業がスレッド間で移動したり、スレッドがコア間で移動したりするため、一定のデータがキャッシュされなくなります。つまり、あまりにも多くの作業を分配すると、パフォーマンスの低下につながる可能性があります。

I/O リクエストごとの論理、物理、CPU スレッドが実行する作業は、ワークロードのタイプに基づいて


296

I/O リクエストごとの論理、物理、CPU スレッドが実行する作業は、ワークロードのタイプに基づいて変わります。そのため、サービスすることが期待される別のタイプのワークロードでシステムをテストする必要があります。

重複排除に成功した同期モードの書き込み操作は、新しいデータの書き込みに比べ、さらなる I/O 操作(以前に格納したデータブロックの読み込み)、一部の CPU サイクル (新しいデータブロックを比較してマッチするかどうかを検証)、ジャーナル更新 (以前格納したデータブロックの PBN に LBN を再マッピング) を必然的に伴います。非同期モードで重複排除が検出されると、データの書き込み操作は、読み込みを犠牲にして会費されます。また、上記で説明した操作を比較します。書き込みごとのジャーナル更新は 1 つのみです。これは、重複排除の検出のありなしに関係ありません。

圧縮が有効化されると、圧縮可能データの読み込みと書き込みには、CPU スレッドによる、さらに多くの処理が必要になります。

すべてのゼロバイト (ゼロブロック) を含むブロックは、一般的に発生するため特別に扱われます。ブロックマップのデータなどには、特殊なエントリーが使われます。ゼロブロックはストレージデバイスに書き込まれたり、ストレージデバイスから読み込まれたりしません。つまり、オールゼロブロックは、誤解を招くような結果を生み出す可能性があります。ゼロブロックまたは初期化していないブロック上の書き込みを行うテストにも、少なからず同じ事が言えます。これは、物理スレッドによって行われる参照カウント更新が、ゼロまたは初期化されていないブロックに対して必要とされていないためです。

I/O 操作の承認は、行われている作業タイプや、操作されているデータによって大幅に影響されない唯一のタスクです。これは、1 つのコールバックが I/O 操作ごとに発行されるためです。

29.6.3.1.2. CPU アフィニティとアフィニティと NUMA

NUMA ノード境界にわたるメモリーへのアクセスは、ローカルノード上のメモリーにアクセスするよりも時間がかかります。ノード上のコア間における最終レベルのキャッシュを共有する Intel プロセッサーでは、ノード間のキャッシュ競合は、ノード内のキャッシュ競合よりも大きな問題となります。

top などのツールは、作業を行う CPU サイクルや、引き留められているサイクルの区別を行うことはできません。これらのツールは、実際の作業としてキャッシュ競合と低速メモリーを解釈します。結果として、ノード間のスレッドを移動すると、毎秒ごとに実行する操作の数が増えると同時に、スレッドの見かけの CPU 使用率が低減したように見えることがあります。

VDO のカーネルスレッドの多くは、1 つのみのスレッドによってアクセスされるデータ構造を維持しますが、I/O リクエストについてのメッセージを頻繁に交換します。VDO スレッドが複数のノードで実行されている場合や、スレッドが、スケジューラーによって、あるノードから別のノードに割り当てられている場合は、競合率が高くなることがあります。その他の VDO 関連の作業 (VDO への I/O 送信や、ストレージデバイスの中断処理など) を実行できる場合は、競合が低減できる可能性があります。1 つのノードに、すべての VDO 関連の作業を実行できるほどのサイクル外ない場合、その他のノードに移動するためにスレッドを選択したときにはメモリーの競合を考慮する必要があります。

実用的であれば、taskset ユーティリティで、1 つのノード上で VDO スレッドを収集します。その他のVDO 関連の作業が、同じノード上で実行できれば、さらに競合を低減させることができます。その場合、処理需要に合わせるための CPU パワーが欠如すると、その他ノードに移動するノードを選ぶときにメモリー競合を考慮しなければなりません。たとえば、ストレージデバイスのドライバーに、維持しなければならないデータ構造が多い場合、デバイスの中断処理と VDO の I/O 送信 (デバイスのドライバーコードを呼び出す bio スレッド) を別のノードに移動するのに役立ちます。I/O 承認 (承認スレッド) と高レベルの I/O 送信スレッド (ダイレクト I/O を行うユーザーモードスレッド、またはペアリングされたカーネルページのキャッシュ flush スレッド) も良い対策と言えます。

29.6.3.1.3. 周波数の調整周波数の調整

電力消費が問題でなければ、/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ファイル (存


297

在する場合) に文字列 performance を書き込むことで、結果がより良いものになります。これらの sysfs ノードが存在しない場合、Linux またはシステムの BIOS では、CPU 周波数管理の設定にさらに優れたオプションを利用できます。

パフォーマンス測定は、ワークロードに基づいて周波数が動的に変化する CPU によってさらに複雑化します。これは、タスクの切り替えやキャッシュ競合がない場合であっても、CPU が行っているその他の作業により、作業の特定の部分を実現するために必要時間が異なるためです。

29.6.3.2. キャッシュキャッシュ

29.6.3.2.1. ブロックマップキャッシュブロックマップキャッシュ

VDO は、効率を向上するために多くのブロックマップページをキャッシュします。このキャッシュサイズはデフォルトで 128 MB ですが、vdo コマンドに --blockMapCacheSize=megabytes オプションを指定することで増大させることができます。より大きなキャッシュを使用すると、ランダムアクセスワークロードに対するメリットを大いに得ることができます。

29.6.3.2.2. 読み込みキャッシュ読み込みキャッシュ

第 2 のキャッシュは、VDO の重複排除アドバイスを検証するためにストレージシステムからデータブロックの読み込みをキャッシュするのに使用できます。同じようなデータブロックが短期間で見られた場合は、必要な I/O 操作数が減ります。

また、読み込みキャッシュは、圧縮ユーザーデータを含むストレージブロックを保持します。複数の圧縮ブロックが短期間で書き込まれる場合、圧縮バージョンが同じストレージシステムブロックに配置されることがあります。同じように、短期間に読み込まれれば、キャッシングにより、ストレージシステムからさらなる読み込みのニーズを避けることができます。

vdo command's --readCache={enabled | disabled} オプションは、読み込みキャッシュが使用されるかどうかを制御します。有効化すると、キャッシュの最低サイズは 8 MB になりますが、これは --readCacheSize=megabytes オプションで増大します。読み込みキャッシュを管理することで、多少のオーバーヘッドを受けます。そのため、ストレージシステムが十分に高速であればパフォーマンスは上昇しません。読み込みキャッシュはデフォルトで無効化されています。

29.6.3.3. ストレージシステムストレージシステム I/O

29.6.3.3.1. Bio スレッドスレッド

RAID 構成の一般的なハードドライブでは、I/O 操作の送信に必要となるのは 1 つまたは 2 つの bio スレッドです。ストレージデバイスドライバーが、1 つまたは 2 つのスレッドが非常にアクティブで、ストレージデバイスが頻繁にアイドル状態というような、相当な量の作業 (データ構造の更新や、デバイスとの通信) を行うために I/O 送信スレッドを必要とする場合、bio スレッドカウントを、相殺のために増大させることができます。ただし、ドライバー実装によっては、スレッドカウントを上昇させすぎると、競合のキャッシュやスピンロックに発展することがあります。デバイスアクセス時間がすべてのNUMA ノードにわたって統一されていない場合は、ストレージデバイスコントローラーに対してノード「closest」上で bio スレッドを実行するのに役立ちます。

29.6.3.3.2. IRQ 処理処理

デバイスドライバーが割り込みハンドラーで重要な作業を行い、スレッド型の IRQ ハンドラーを使用しない場合は、スケジューラーによる最高のパフォーマンスの発揮が妨げられることがあります。ハードウェア割り込みをサービスするのに費やした CPU 時間は、ある意味では通常の VDO (またはその他の)カーネルスレッドのように見えることがあります。たとえば、ハードウェア IRQ 処理がコアサイクルの30% を必要とした場合、同じコア上のビジーなカーネルスレッドは残りの 70% のみを使用できます。


298

ただし、そのスレッドに列を成す作業がコアサイクルの 80% を求める場合、スレッドは追いつくことはなく、スケジューラーは、あまりビジーでないコアに切り替える代わりに、そのコアで妨げられた状態で実行するように、そのスレッドを放置します。

このようなデバイスドライバーを高負荷の VDO 下で使用すると、ハードウェア割り込みのサービスに多くのサイクルが必要となります (top ディスプレイのヘッダーにおける %hi インジケーター)。その場合、特定のコアに対して IRQ 処理を割り当て、これらのコアで実行しないように VDO カーネルスレッドの CPU アフィニティを調整するとよいかもしれません。

29.6.3.4. 最大破棄セクター最大破棄セクター

VDO デバイスに対する DISCARD (TRIM) 操作の最大許容サイズは、システムの使用率に基づいて /sys/kvdo/max_discard_sectors から調整できます。デフォルトは 8 セクター (1 つの 4 KB ブロック)です。VDO が依然として 1 度に 1 ブロック、ループ状態で処理を行いますが、より大きなサイズを指定することができます。これは、1 つの破棄されたブロックのメタデータ更新がジャーナルに書き込まれ、次のブロックで開始する前にディスクにフラッシュされるようになります。

ローカルファイルシステムとして VDO ボリュームを使用する場合、Red Hat テストでは、小さなはきサイズが最もよく昨日することがわかっています。Linux カーネルの一般的なブロックデバイスコードが、大型の破棄リクエストを複数の小さなリクエストに分割し、並列して送信するためです。デバイスの I/O アクティビティが低い場合は、VDO は大きなリクエストよりも、より多くの小さなリクエストを同時かつ素早く処理できます。

VDO デバイスが SCSI ターゲットとして使用される場合は、イニシエーターやターゲットソフトウェアにより、考慮すべき要素が生まれます。ターゲット SCSI ソフトウエアが SCST である場合、最大破棄サイズを読み込み、イニシエーターにリレーします。(Red Hat は、LIO SCSI ターゲットコードとともに VDO 設定の調整を試行していません。)

Linux SCSI イニシエーターコードにより、1 度に 1 つの破棄操作が可能になるため、最大サイズを超えた破棄リクエストは、複数のより小さな破棄へと分割され、1 度に 1つずつターゲットシステム (およびVDO) に送信されます。そのため、多くの破棄操作を順番に処理する VDO 処理加え、2 つのシステム間いおける往復の通信時間により、さらなるレイテンシーが生まれます。

より大きな最大破棄サイズを設定すると、この通信のオーバーヘッドを低減させることができます。ただし、より大きなリクエストは、すべて VDO に渡され、1 度に 1 つの 4 KB ブロックが処理されます。ブロックごとの通信遅延はありませんが、より大きなブロックに対する処理時間の増大により、SCSIイニシエーターソフトウェアがタイムアウトすることがあります。

SCSI ターゲット使用率については、Red Hat は、典型的な破棄時間をイニシエーターのタイムアウト設定内に維持しつつ、最大破棄サイズを比較的大きめに設定することを推奨しています。たとえば、数秒ごとの余分な往復コストが、パフォーマンスに大幅に影響を与えず、30 または 60 秒のタイムアウトの SCSI イニシエーターはタイムアウトするべきではありません。

29.6.4. ボトルネックの識別

VDO パフォーマンスに影響を与えるものには複数の主要要素があり、最も影響のあるものを識別するためのツールもあります。

top や ps で見られるような 70% を超えるスレッドや CPU 使用率は一般的に、1 つのスレッドまたは 1つの CPU に、あまりにも多くの作業が集中していることを意味します。ただし、一部のケースでは、VDO スレッドが CPU で実行されるようにスケジュールさ設定されていても、実際に何も作業が行われていないことを意味する場合もあります。このようなシナリオは、角のハードウェア割り込みハンドラー処理、コアまたは NUMEA ノード間のメモリ競合、またはスピンロックの競合によって発生することがあります。

システムパフォーマンスの検証に top ユーティリティを使用する場合、Red Hat では top -H を実行し


299

てすべてのプロセススレッドを個別に表示してから、1 f j キーを入力して Enter/リターンキーを押します。次に top コマンドにより、個別の CPU コアのロードが表示され、最後に実行した書くプロセスまたはスレッド上の CPU を識別します。これにより、以下の情報がわかります。

コアに %id (アイドル) と %wa (I/O 待機) 値がある場合、ある種の作業でビジー状態が維持されます。

コアの %hi 値が非常に低い場合、そのコアは通常の処理作業を行っています。これは、カーネルスケジューラーによって負荷分散が行われています。そのセットにさらにコアを追加すると、NUMA 競合を取り込まない限り、負荷を低減させることができます。

コアの %hi が数パーセント以上で、そのコアに 1 つのスレッドのみが割り当てられ、%id と %wa がゼロである場合、コアはコミットされ過ぎており、スケジューラーは状況に対処していません。この場合、カーネルスレッドやデバイス中断処理は、個別のコアで維持するように割り当てられます。

perf ユーティリティは、多くのパフォーマンスカウンターを検証できます。Red Hat では、スレッドやプロセッサーが行っている作業の検証には、第一歩として perf top サブコマンドの使用をおすすめします。たとえば、bioQ スレッドが多くのサイクルを消費して、スピンロックを取得しようとしている場合、VDO 下のデバイスドライバーに競合が多く発生することがあります。また、bioQ スレッドの数を低減せることで、状況を緩和できる可能性があります。たとえば、bioQ スレッドやデバイス中断ハンドラーが各種ノードで動作している場合、CPU の使用率が高いと (スピンロックの取得など)、NUMAノード間に競合が見られることがあります。プロセッサーが対応していれば、stalled-cycles-backend、cache-misses、node-load-misses などのカウンターを参照してみてください。

sar ユーティリティは、複数のシステム統計についてのレポートを定期的に出力できます。sar -d 1 コマンドは、1 病後とのブロックデバイスの使用率レベル (最低でも 1 つの処理中の操作がある時間の割合) やキューの長さ (待機中の I/O リクエストの数) を報告します。ただし、すべてのブロックデバイスドライバーがこのような情報を報告できるわけではありません。よって、sar の便利性は、使用中のデバイスドライバーによって変わります。

29.7. VDO コマンド

このセクションでは、以下の VDO ユーティリティを説明します。

vdo

vdo ユーティリティは、VDO のkvdo と UDS のコンポーネントの両方を管理します

また、圧縮の有効化または無効化にも使用できます。

vdostats

vdostats ユーティリティでは、Linux のdf ユーティリティと似た形式で、それぞれ設定した (あるいは指定した) デバイスの統計が表示されます。

29.7.1. vdo

vdo ユーティリティは、VDO のkvdo と UDS のコンポーネントの両方を管理します

概要概要

vdo { activate | changeWritePolicy | create | deactivate | disableCompression | disableDeduplication | enableCompression | enableDeduplication | growLogical | growPhysical | list | modify | printConfigFile | remove | start | status | stop }


300

[ options... ]

サブコマンドサブコマンド

表表29.4 VDO サブコマンドサブコマンド

サブコマンドサブコマンド説明説明


301

create VDO ボリュームとその関連インデックスを作成し、利用できるようにします。−−activate=disabled オプションを指定すると、VDO ボリュームが作成されますが、利用できなくなります。−−force を指定しない限り、既存のファイルシステムやフォーマットされた VDO ボリュームを上書きすることはありません。このコマンドは、root 特権で実行する必要があります。指定できるオプションは以下の通りです。

--name=volume (必須)

--device=device (必須)

--activate={enabled | disabled}

--indexMem=gigabytes

--blockMapCacheSize=megabytes

--blockMapPeriod=period

--compression={enabled | disabled}

--confFile=file

--deduplication={enabled | disabled}

--emulate512={enabled | disabled}

--sparseIndex={enabled | disabled}

--vdoAckThreads=thread count

--vdoBioRotationInterval=I/O count

--vdoBioThreads=thread count

--vdoCpuThreads=thread count

--vdoHashZoneThreads=thread count

--vdoLogicalThreads=thread count

--vdoLogLevel=level

--vdoLogicalSize=megabytes

--vdoPhysicalThreads=thread count

--readCache={enabled | disabled}

--readCacheSize=megabytes

--vdoSlabSize=megabytes

--verbose

--writePolicy={ auto | sync | async }

--logfile=pathname



302

remove 停止した 1 つ以上の VDO ボリュームと関連インデックスを削除します。このコマンドは、root 特権で実行する必要があります。指定できるオプションは以下の通りです。

{ --name=volume | --all } (必須)

--confFile=file

--force

--verbose

--logfile=pathname

start 停止した 1 つ以上の有効化された VDO ボリュームと関連サービスを開始します。このコマンドは、root 特権で実行する必要があります。指定できるオプションは以下の通りです。


--confFile=file

--forceRebuild

--verbose

--logfile=pathname

stop 実行中の 1 つ以上の有効化された VDO ボリュームと関連サービスを開始します。このコマンドは、root 特権で実行する必要があります。指定できるオプションは以下の通りです。


--confFile=file

--force

--verbose

--logfile=pathname

activate 1 つ以上の VDO ボリュームを有効化します。有効化したボリュームは、start

コマンドを使用して開始できます。このコマンドは root 特権で実行する必要があります。指定できるオプションは以下の通りです。


--confFile=file

--logfile=pathname

--verbose



303

deactivate 1 つ以上の VDO ボリュームを無効化します。無効化したボリュームは、start

コマンドでは開始できません。現在実行しているボリュームの無効化では停止できません。停止すると、無効化した VDO ボリュームは再び開始する前に有効化する必要があります。このコマンドは、root 権限で実行する必要があります。指定できるオプションは以下の通りです。


--confFile=file

--verbose

--logfile=pathname

status VDO システムやボリューム YAML 形式で報告します。このコマンドは、root 特権なしでも情報が不完全となりますが、root 特権は不要です。指定できるオプションは以下の通りです。


--confFile=file

--verbose

--logfile=pathname

出力は、表29.6「VDO ステータス出力」を参照してください。

list 開始した VDO ボリュームのリストを表示します。−−all を指定すると、起動したボリュームと起動していないボリュームの両方を表示します。このコマンドは root 特権で実行する必要があります。指定できるオプションは以下の通りです。

--all

--confFile=file

--logfile=pathname

--verbose



304

modify 1 つまたはすべの VDO ボリュームの設定パラメーターを変更します。変更は、VDO デバイスを次に起動したときに適用されます。既に実行しているデバイスは影響を受けません。指定できるオプションは以下の通りです。



--blockMapPeriod=period

--confFile=file








--readCacheSize=megabytes

--verbose

--logfile=pathname

changeWritePolicy 1 つまたはすべての実行中の VDO ボリュームの書き込みポリシーを変更します。このコマンドは、root 特権で実行する必要があります。



(必須)

--confFile=file

--logfile=pathname

--verbose



305

enableDeduplication 1 つ以上の VDO ボリュームで重複排除を有効化します。このコマンドは、root 特権で実行する必要があります。指定できるオプションは以下の通りです。


--confFile=file

--verbose

--logfile=pathname

disableDeduplication 1 つ以上の VDO ボリュームで重複排除を無効化します。このコマンドは、root 特権で実行する必要があります。指定できるオプションは以下の通りです。


--confFile=file

--verbose

--logfile=pathname

enableCompression 1 つ以上の VDO ボリュームで圧縮を有効化します。VDO ボリュームが稼働中の場合は、すぐに適用されます。VDO ボリュームが稼働していない場合は、VDO ボリュームが次回起動したときに圧縮が有効になります。このコマンドは root 特権で実行する必要があります。指定できるオプションは以下の通りです。


--confFile=file

--verbose

--logfile=pathname

disableCompression 1 つ以上の VDO ボリュームで圧縮を無効にします。VDO ボリュームが稼働中の場合は、すぐに適用されます。VDO ボリュームが稼働していない場合は、VDO ボリュームが次回起動したときに圧縮が無効になります。このコマンドは root 特権で実行する必要があります。指定できるオプションは以下の通りです。


--confFile=file

--verbose

--logfile=pathname



306

growLogical 論理容量を VDO ボリュームに追加します。このボリュームは実際に存在し、実行している必要があります。このコマンドは root 特権で実行する必要があります。指定できるオプションは以下の通りです。


--vdoLogicalSize=megabytes

(必須)

--confFile=file

--verbose

--logfile=pathname

growPhysical 物理容量を VDO ボリュームに追加します。このボリュームは実際に存在し、実行している必要があります。このコマンドは root 特権で実行する必要があります。指定できるオプションは以下の通りです。


--confFile=file

--verbose

--logfile=pathname

printConfigFile 設定ファイルを stdout に出力します。このコマンドには、root 特権が必要です。指定できるオプションは以下の通りです。

--confFile=file

--logfile=pathname

--verbose


オプションオプション

表表29.5 VDO オプションオプション


--indexMem=gigabytes ギガバイトの UDS サーバーメモリーの量を指定します。デフォルトのサイズは 1 GB です。特定の浮動小数の値は、整数である限り 0.25、0.5、0.75 が使用できます。

--sparseIndex={enabled | disabled}

スパークインデックスの有効化または無効化。デフォルトは disabledです。


307

--all このコマンドがすべての設定済みの VDO ボリュームに適用する必要があることを示します。--name オプションを指定して使用することはできません。


ブロックマップページのキャッシュング用に割り当てられたメモリーの量を指定します。この値は、4096 の倍数である必要があります。B(ytes)、K(ilobytes)、M(egabytes)、G(igabytes)、T(erabytes)、P(etabytes)、または E(xabytes) サフィックスを指定して値を使うこともできます。サフィックスを指定しない場合、値は最低 128M で 16T 未満である必要があります。15% のメモリーオーバーヘッドが存在することに注意してください。

--blockMapPeriod=period ブロックマップの数の更新を判別する 1 〜 16380 の値。これは、キャッシュされたページがディスクにフラッシュされる前に蓄積することがあります。値が高くなると、通常の動作の際のパフォーマンスを犠牲にしてクラッシュ後のリカバリー時間を低減します。デフォルトの値は16380 です。このパラメーターを調整する場合は、Red Hat の担当者までご相談ください。

--compression={enabled | disabled}

VDO デバイス内で圧縮を有効化または無効化します。デフォルトでは有効化されています。パフォーマンスを最大化するためや、圧縮しないと思われるデータンの処理速度を向上するために圧縮は無効化されています。

--confFile=file 代替の設定ファイルを指定します。デフォルトは /etc/vdoconf.yml です。

--deduplication={enabled | disabled}

VDO デバイス内で重複排除の有効化または無効化を行います。デフォルトは enabled です。優れた重複排除を適用できず、圧縮が依然として必要だと考えられる場合は、重複排除が無効化されることがあります。

--emulate512={enabled | disabled}

512 バイトブロックデバイスエミュレーションモードを有効化します。デフォルトは disabled です。

--force VDO ボリュームを停止するまえにマウントしたファイルシステムのマウントを解除します。

--forceRebuild 読み取り専用 VDO ボリュームを起動する前にオフライン再構築を強制します。これにより、オンラインに戻して利用できるようになります。このオプションを指定すると、データが損失したり、破損したりすこのオプションを指定すると、データが損失したり、破損したりすることがあります。ることがあります。

--help vdo ユーティリティのドキュメンテーションを表示します。

--logfile=pathname このスクリプトのログメッセージがダイレクトされる場所を指定します。警告やエラー目セージは常に syslog にも記録されます。



308

--name=volume 指定した VDO ボリュームで動作します。--all を指定して使用することはできません。

--device=device VDO ストレージに使用するデバイスの絶対パスを指定します。

--activate={enabled | disabled}

引数 disabled は、VDO ボリュームのみを作成できることを示しています。このボリュームは、起動することや、有効化することはできません。このデフォルトは、enabled です。


リクエストした VDO I/O 操作の完了を承認するためにしようするスレッドの数を指定します。デフォルトは 1 です。この値は最低 0 から100 までに設定する必要があります。

--vdoBioRotationInterval=I/O count

I/O 操作の数を指定し、作業を次に登録する前に各 bio 送信スレッドにキューを加えます。デフォルトは 64 です。この値は 1 から 1024 までに設定する必要があります。


I/O 操作をストレージデバイスに送信するのに使用するスレッドの数を指定します。1 〜 100 の値で設定します。デフォルトは 4 で、この値は 1以上 100 以下である必要があります。


ハッシングや圧縮などの CPU 負荷の高い作業に使用するスレッドの数を指定します。デフォルトは 2 です。この値は 1 以上 100 以下で設定する必要があります。


ブロックデータから計算したハッシュ値に基づいて VDO 処理の部分をさらに分割するスレッドの数を指定します。デフォルトは 1 です。この値は、0 以上 100 以下で設定する必要があります。vdoHashZoneThreads, vdoLogicalThreads と vdoPhysicalThreads は、すべてゼロまたはすべてゼロ以外である必要があります。


ブロックデータから計算したハッシュ値に基づいて VDO 処理の部分をさらに分割するスレッドの数を指定します。この値は、0 以上 100 以下で設定する必要があります。9 以上の論理スレッドカウントでは、十分に大きなブロックマップキャッシュサイズを排他的に指定する必要があります。vdoHashZoneThreads, vdoLogicalThreads と vdoPhysicalThreads は、すべてゼロまたはすべてゼロ以外である必要があります。デフォルトは 1 です。

--vdoLogLevel=level VDO ドライバーログレベルを指定します。critical、error、warning、notice、info、または debug。レベルは、大文字と小文字を区別します。デフォルトは info です。

--vdoLogicalSize=megabytes メガバイトで論理 VDO ボリュームサイズを指定します。S(ectors)、B(ytes)、K(ilobytes)、M(egabytes)、G(igabytes)、T(erabytes)、P(etabytes) または E(xabytes) サフィックスとともに値を使うのは任意です。オーバープロビジョニングボリュームに使用。これは、ストレージデバイスのサイズに対するデフォルトです。



309


物理ブロックアドレスに基づいて VDO 処理の部分をさらに分割するスレッドの数を指定します。値は、0 以上 16 以下で設定する必要があります。初期以降のスレッドの追加は、さらに 10 MB の RAM を消費します。vdoPhysicalThreads、vdoHashZoneThreads、vdoLogicalThreads は、すべてゼロまたはぜべてゼロ以外である必要があります。デフォルトは 1 です。


VDO デバイス内で読み込みキャッシュを有効化または無効化します。デフォルトは disabled です。書き込みワークロードに高度の重複排除が含まれると想定される場合はキャッシュを有効化する必要があります。または、高度に圧縮可能なデータの集中的なワークロードを読み込む場合はキャッシュを有効化する必要があります。

--readCacheSize=megabytes さらなる VDO デバイス読み込みキャッシュサイズをメガバイトで指定します。S(ectors), B(ytes)、K(ilobytes)、M(egabytes)、G(igabytes)、T(erabytes)、P(etabytes) または E(xabytes) サフィックスとともに値を使うのは任意です。デフォルトは 0M です。MB の指定した読み込みキャッシュごと、bio スレッドごとに 12 MB のメモリが使用されます。

--vdoSlabSize=megabytes VDO が増大した増分サイズを指定します。小さな値を使用すると、利用できる最大合計物理サイズが制約されます。S(ectors)、B(ytes)、K(ilobytes)、M(egabytes)、G(igabytes)、T(erabytes)、P(etabytes)、または E(xabytes) サフィックスを指定して値を使うこともできます。サフィックスを指定しないと、値はメガバイトとして解釈されます。

--verbose コマンドを実行する前に出力します。


書き込みポリシーを指定します。

auto: VDO 下のストレージ層に基づいて sync または asyncを選択します。ライトバックキャッシュが存在する場合は、async が選ばれます。それ以外では、sync が選ばれます。

sync: データが安定して書き込まれた後にのみ書き込みが承認されます。これはデフォルトのポリシーです。このポリシーこのポリシーは、基礎となるストレージが同期的出ない場合には機能しませは、基礎となるストレージが同期的出ない場合には機能しません。ん。

async: データが、安定したストレージに書き込みを行うためにキャッシュされた後にのみ、書き込みが承認されます。フラッシュされていないデータは、このモードでの永続性が保証されません。


status サブコマンドは、以下の情報を YAML 形式で返し、以下のキーに分割します。

表表29.6 VDO ステータス出力ステータス出力


310

キーキー説明説明

VDOステータス

このキーの情報は、ホストの名前とステータスの問い合わせが行われた日付と時刻を示します。この領域に報告されるパラメーターには以下が含まれます。

ノード VDO が実行されているシステムのホスト名。

日付 vdo ステータスコマンドが実行された日付と時間。

カーネルモジュール

このキーの情報は、構成されているカーネルについてです。

読み込み済み

カーネルモジュールがロードされているかどうか (True または False)。

バージョン情報

設定されている kvdo のバージョンの情報。

Configuration

このキーの情報は、VDO 設定ファイルの場所とステータスを示します。

File VDO 設定ファイルの場所。

Lastmodified

VDO 設定ファイルの最終更新日。

VDOs すべての VDO ボリュームの設定情報を示します。各 VDO ボリュームに報告されたパラメーターには以下が含まれます。

ブロックサイズ

VDO ボリュームのブロックサイズ (バイト)

512 byteemulation

ボリュームが 512 バイトエミュレーションモードで実行しているかどうかを示します。

Enablededuplication

ボリュームに重複排除が有効化されているかどうか。

Logical size VDO ボリュームの論理サイズ。

物理サイズ VDO ボリュームの基礎となる物理ストレージのサイズ。

書き込みポリシー

書き込みポリシーの設定値 (同期または非同期)

VDOstatistics

vdostats ユーティリティの出力

29.7.2. vdostats


311

vdostats ユーティリティでは、Linux のdf ユーティリティと似た形式で、それぞれ設定した (あるいは指定した) デバイスの統計が表示されます。

root 権限で実行しない場合は、vdostats ユーティリティは完全に機能しません。

概要概要

vdostats [ --verbose | --human-readable | --si | --all ] [ --version ] [ device ...]

オプションオプション

表表29.7 vdostats オプションオプション


--verbose 1 台 (または複数) の VDO デバイスの使用率とブロック I/O (bios) を表示します。詳細は表29.9「vdostats --verbose 出力」を参照してください。

--human-readable

ブロック値を読みやすい形式で表示します (ベース 2: 1 KB = 210 バイト = 1024 バイ

ト)。

--si --si オプションは、--human-readable オプションの出力を変更し、SI 単位 (ベース10: 1 KB = 103 バイト = 1000 バイト) を使用します。--human-readable オプションを

指定しないと、--si オプションは機能しません。

--all このオプションは、後方互換性のみに使用します。現在では、--verbose オプションと同等です。

--version vdostats バージョンを表示します。

device ... レポートする 1 つ以上の特定のボリュームを指定します。この引数を指定しないと、vdostats はすべてのデバイスをレポートします。

出力出力

以下の例では、オプションを指定しない場合のサンプルを示しています。これは表29.8「デフォルトのvdostats 出力」で説明しています。

Device 1K-blocks Used Available Use% Space Saving%/dev/mapper/my_vdo 1932562432 427698104 1504864328 22% 21%

表表29.8 デフォルトのデフォルトの vdostats 出力出力

項目項目説明説明

デバイス VDO ボリュームへのパス

1K ブロック VDO ボリュームに割り当てられた 1K ブロックの合計数 (= 物理ボリュームサイズ * ブロックサイズ / 1024)


312

Used VDO ボリュームで使用した 1K ブロックの合計数 (= 使用物理ブロック * ブロックサイズ / 1024)

利用可能 VDO ボリュームで利用できる 1K ブロックの合計数 (= 物理空きブロック * ブロックサイズ / 1024)

使用% VDO ボリュームで使用している物理ブロックの割合 (= 使用ブロック / 割り当てブロック * 100)

容量節約% VDO ボリューム上で節約した物理ブロックの割合 (= [使用論理ブロック - 使用物理ブロック / 使用論理ブロック])


--human-readable オプションは、ブロックカウントを従来の単位に変換します (1 KB = 1024 バイト)。

Device Size Used Available Use% Space Saving%/dev/mapper/my_vdo 1.8T 407.9G 1.4T 22% 21%

--human-readable と --si オプションは、ブロックカウントを SI 単位に変換します (1 KB = 1000 バイト)。

Device Size Used Available Use% Space Saving%/dev/mapper/my_vdo 2.0T 438G 1.5T 22% 21%

--verbose (表29.9「vdostats --verbose 出力」) オプションは 1 台 (あるいはすべて) の VDO デバイスの VDO デバイス統計を表示します。

表29.9「vdostats --verbose 出力」の太字太字で出力された統計は、今後のリリースで継続的にレポートされます。残りのフィールドは、ソフトウェアサポートを主目的としています。また、今後のリリースで変更されることがあります。管理ツールでは、これらのフィールドに依存すべきではありません。また、管理ツールは、統計が報告される順番にも依存するべきではありません。

表表29.9 vdostats --verbose 出力出力


Version これらの統計のバージョン。

Release version VDOのリリースバージョン

Data blocks used データを保存するために VDO ボリュームによって現在使用されている物理ブロックの数。

Overhead blocks used VDO メタデータを保存するために VDO ボリュームによって現在使用されている物理ブロックの数。

Logical blocks used 現在マッピングされている論理ブロックの数。


313

Physical blocks VDO ボリュームに割り当てられた物理ブロックの合計数。

Logical blocks VDO ボリュームによってマッピングできる論理ブロックの最大数。

1K-blocks VDO ボリュームに割り当てられた 1K ブロックの合計数 (= 物理ボリュームサイズ* ブロックサイズ / 1024)

1K-blocks used VDO ボリュームで使用した 1K ブロックの合計数 (= 使用物理ブロック * ブロックサイズ / 1024)

1K-blocks available VDO ボリュームで利用できる 1K ブロックの合計数 (= 物理空きブロック * ブロックサイズ / 1024)

Used percent VDO ボリュームで使用している物理ブロックの割合 (= 使用ブロック / 割り当てブロック * 100)

Saving percent VDO ボリューム上で節約した物理ブロックの割合 (= [使用論理ブロック - 使用物理ブロック / 使用論理ブロック])

Block map cache size ブロックマップキャッシュのサイズ (バイト)

Write policy アクティブ書き込みポリシー (同期または非同期)。これは、vdo changeWritePolicy --writePolicy=auto|sync|async から設定されます。

Block size VDO ボリュームのブロックサイズ (バイト)

Completed recoverycount

VDO ボリュームが異常なシャットダウンからリカバリーした回数。

Read-only recoverycount

VDO ボリュームが読み取り専用モードからリカバリーした回数 (vdo start --forceRebuild を使用)

Operating mode VDO ボリュームが正常に動作しているかどうか、リカバリーモードになっているかどうか、読み取り専用モードになっているかどうかを示します。

Recovery progress (%) オンラインリカバリーの進捗状況を示します。または、ボリュームがリカバリーモードになっていない場合は N/A を示します。

Compressed fragmentswritten

VDO ボリュームが前回再起動してから書き込まれた圧縮フラグメントの数。

Compressed blockswritten

VDO ボリュームが前回再起動してから書き込まれた圧縮フラグメントの数。

Compressed fragmentsin packer

まだ書き込まれていない、処理されている圧縮フラグメントの数。



314

Slab count スラブの合計数

Slabs opened ブロックが今まで割り当てられていないスラブの合計数。

Slabs reopened VDO が起動してから再びスラブが解放された回数。

Journal disk full count リカバリージャーナルがフルであったため、リカバリージャーナルエントリをリクエストが作成できなかった回数。

Journal commitsrequested count

リカバリージャーナルがスラブジャーナルコミットを要求した回数。

Journal entries batching 書き込まれたジャーナルエントリーの数を引いた、開始されたジャーナルエントリーの書き込みの数。

Journal entries started メモリーで作成されたジャーナルエントリーの数。

Journal entries writing ストレージにコミットされたジャーナルエントリーの数を引いた、送信した書き込みのジャーナルエントリーの数。

Journal entries written 書き込みが発行されたジャーナルエントリーの合計数。

Journal entriescommitted

ストレージに書き込まれたジャーナルエントリーの数。

Journal blocks batching 書き込まれたジャーナルブロックの数を引いた、開始されたジャーナルブロックの書き込みの数。

Journal blocks started メモリーでタッチされたジャーナルブロックの数。

Journal blocks writing コミットされたジャーナルブロックの数を引いた、書き込まれたジャーナルブロックの数 (アクティブメモリーのメタデータとともに)。

Journal entries written 書き込みが発行されたブロックエントリーの合計数。

Journal blockscommitted

ストレージに書き込まれたジャーナルブロックの数。

Slab journal disk fullcount

オンディスクスラブジャーナルの数がフルであった回数。

Slab journal flush count フラッシュしきい値を超えていたスラブジャーナルにエントリーが追加された回数。

Slab journal blockedcount

ブロックしきい値を超えていたスラブジャーナルにエントリーが追加された回数。



315

Slab journal blockswritten

発行されたスラブジャーナルブロック書き込みの数。

Slab journal tail busycount

スラブジャーナルの書き込みを待つ、書き込みリクエストがブロックされた回数。

Slab summary blockswritten

発行されたスラブサマリーブロックの数。

Reference blockswritten

発行された参照ブロックの数。

Block map dirty pages ブロックマップキャッシュの dirty ページの数。

Block map clean pages ブロックマップキャッシュのクリーンページの数。

Block map free pages ブロックマップキャッシュの空きページの数。

Block map failed pages 書き込みエラーのあるブロックマップキャッシュページの数。

Block map incomingpages

キャッシュに読み込まれているブロックマップキャッシュページの数。

Block map outgoingpages

書き込まれているブロックマップキャッシュページの数。

Block map cachepressure

空きページが必要なときに利用できなかった回数。

Block map read count ブロックマップページ読み込みの合計数。

Block map write count ブロックマップページ書き込みの合計数。

Block map failed reads ブロックマップ読み込みの合計数。

Block map failed writes ブロックマップ書き込みエラーの合計数。

Block map reclaimed 再取得されたブロックマップページの合計数。

Block map readoutgoing

書き込まれているページのブロックマップ読み込みの合計数。

Block map found incache

ブロックマップヒットの合計数。



316

Block map discardrequired

ページの破棄を必要したブロックマップの合計数。

Block map wait for page ページを待つ必要のあるリクエストの合計数。

Block map fetchrequired

ページ取得を必要とするリクエストの合計数。

Block map pages loaded ページ取得の合計数。

Block map pages saved ページ保存の合計数。

Block map flush count ブロックマップによって発行されたフラッシュの合計数。

Invalid advice PBNcount

無効なアドバイスを返したインデックスの合計数

No space error count. VDO ボリュームの容量不足によって失敗した書き込みリクエストの数。

Read only error count 読み取り専用モードの VDO ボリュームによって失敗した書き込みリクエストの数。

Instance VDO インスタンス

512 byte emulation 512 バイトエミュレーションがボリュームに対してオンまたはオフであるかを示します。

Current VDO IOrequests in progress.

VDO が現在処理している I/O リクエストの数。

Maximum VDO IOrequests in progress

VDO が処理した同時 I/O リクエストの最大数。

Current dedupe queries 現在実行している重複排除クエリーの数。

Maximum dedupequeries

実行中の重複排除クエリーの最大数。

Dedupe advice valid 重複排除アドバイスが適切であった回数。

Dedupe advice stale 重複排除が不適切であった回数。

Dedupe advice timeouts 重複排除クエリーがタイムアウトした回数。

Flush out 基礎となるストレージに対して VDO が送信したフラッシュリクエストの数。



317

Bios in... Bios in partial...Bios out... Bios meta...Bios journal... Bios pagecache... Bios outcompleted... Bio metacompleted... Bios journalcompleted... Bios pagecache completed... Biosacknowledged... Biosacknowledged partial...Bios in progress...

これらの統計は、指定のフラグで各カテゴリの bios を数えます。カテゴリは以下の通りです。

bios in: VDO によって受信されたブロック I/O リクエストの数。

bios in partial: VDO によって受信された一部のブロック I/O リクエストの数。512 バイトエミュレーションモードにのみ適用。

bios out:ストレージデバイスに対して VDO によって送信されたメタデータ以外のブロック I/O リクエスト。

bios meta: ストレージデバイスに対して VDO によって送信されたメタデータブロック I/O リクエストの数。

bios journal:ストレージデバイスに対して VDO によって送信されたリカバリージャーナルブロック I/O リクエストの数。

bios page cache:ストレージデバイスに対して VDO によって送信されたブロックマップ I/O リクエスト。

bios out completed: ストレージデバイスによって完了したメタデータ以外のブロック I/O リクエストの数。

bios meta completed: ストレージデバイスによって完了したメタデータブロック I/O リクエストの数。

bios journal completed:ストレージデバイスによって完了したリカバリージャーナルブロック I/O リクエストの数。

bios page cache completed:ストレージデバイスによって完了したブロックマップ I/O リクエストの数。

bios acknowledged: VDO によって承認されたブロック I/O リクエストの数。

bios acknowledged partial: VDO によって承認された一部のブロックI/O リクエストの数。512 バイトエミュレーションモードにのみ適用。

bios in progress: まだ承認されていない VDO に送信された bios の数。

3 種類のフラグ:

read: 書き込み以外の bios の数 (REQ_WRITE フラグセットなしの bios)

write: 書き込み bios の数 (REQ_WRITE フラグセットありの bios)

discard: REQ_DISCARD フラグセットありの bios の数

Read cache accesses VDO が読み込みキャッシュを検索した回数。

Read cache hits 読み込みキャッシュがヒットした回数。


29.8. /SYS の統計ファイル

稼働している VDO ボリュームの統計は、/sys/kvdo/volume_name/statistics ディレクトリーのファイルから読むことができます。ここでは、VDO ボリュームの名前は volume_name です。これにより、


318

シェルスクリプトおよび管理ソフトウェアによるアクセスに適した vdostats ユーティリティによって生成されたデータに代替のインターフェースが生まれます。

以下の表に一覧表示されている者に加え、statistics ディクトリーには複数のファイルがあります。これらの統計ファイルは、今後のリリースで必ずしも利用できるとは限りません。

表表29.10 統計ファイル統計ファイル

ファイルファイル説明説明

dataBlocksUsed データを保存するために VDO ボリュームによって現在使用されている物理ブロックの数。

logicalBlocksUsed 現在マッピングされている論理ブロックの数。

physicalBlocks VDO ボリュームに割り当てられた物理ブロックの合計数。

logicalBlocks VDO ボリュームによってマッピングできる論理ブロックの最大数。

mode VDO ボリュームが正常に動作しているかどうか、リカバリーモードになっているかどうか、読み取り専用モードになっているかどうかを示します。


319

第30章 VOD 評価

30.1. はじめに

VDOは、ブロックレベルの重複排除、圧縮、シンプロビジョニング機能をプライマリストレージで利用できるようにするソフトウェアです。VDO は、LInux デバイスマッパーフレームワーク内にインストールされます。ここでは、VDO が既存のブロックデバイスの所有権を取得し、データ効率プロパティとともに、より高度なレベルの新しいブロックデバイスに再マッピングします。特に、VDO は、10 台以上のデバイスで有効能力を倍増させることができます。このメリットを活用するには、システムリソースがさらに必要になるため、システムパフォーマンスにおける VDO の影響を測定することが不可欠です。

ほぼ間違いなくストレージベンダーは、既存の社内テストプランと、新しいストレージ製品を評価するための知識を擁しています。VDO 層は、重複排除と圧縮を識別するのに役立ちます。そのため、別のテストが必要となることがあります。効果的なテストをプランニングするには、VDO アーキテクチャーを研究し、以下の項目を探求することが必要です。

VDO 固有の設定プロパティ (エンドユーザーアプリケーションのパフォーマンスチューニング)

ネイティブ 4KB ブロックデバイスであることの影響

重複排除と圧縮のアクセスパターンと分配に対するレスポンス

高負荷環境におけるパフォーマンス (非常に重要)

アプリケーションに基づいたコスト vs 容量 vs パフォーマンスの分析

このような要素をあらかじめ考慮できなければ、特定のテストの検証を誤り、テストやデータ収集作業を顧客に繰り替えさせるといった状況が生まれます。

30.1.1. 期待されることと成果

この評価ガイドは、ベンダーの社内評価作業を置き換えるのではなく、強化することを目的としています。評価を行う人物が比較的少ない時間で、VDO の統合の正確な評価を行えるようになりｍす。このガイドでは、以下を行うために設計されています。

エンジニアがテストデバイスから最適なレスポンスを導き出すコンフィ牛ーレション設定を特定できるようにする

製品の設定ミスを回避するための基本的なパラメーターのチューニングの理解を深める

「実際」のアプリケーション結果に対して比較を行うために、リファレンスとしてパフォーマンス結果ポートフォリオを作成する

さまざまなワークロードがパフォーマンスやデータ効率に影響を及ぼす仕組みを見いだす

VDO 実装で市場投入までの時間を短縮する

このテスト結果は、特定のストレージ環境に統合した際に Red Hat エンジニアが VDO の動作を理解するのに役立ちます。OEMは、重複排除と圧縮対応デバイスを設計する方法を理解します。また、それぞれの顧客がデバイスを最適に使用するためにアプリケーションをチューニングすることができます。

このドキュメントの手順は、VDO が最も実際的に評価できる状況下を生み出すように設計されています、テスト手順やパラメーターを変更すると、結果が正しくないものになる可能性があります。Red Hat セールスエンジニアは、テスト計画を変更するためのガイドを提供することができます。


320

30.2. テスト環境の準備

VDO を評価する前に、テストの際に使用するホストシステム設定、VDO 設定、ワークロードを考慮することが重要です。これらの選択は、データの最適化 (容量の効率) やパフォーマンス (帯域幅やレイテンシー) の両方のベンチマークに影響します。テストプラン考案の際に考慮すべき項目について、以下のセクションで一覧に示しています。

30.2.1. システムの設定

利用できる CPU コアの数とタイプ。これは、taskset ユーティリティを使用して制御できます。

利用可能なメモリと取り付けられているメモリの合計数

ストレージデバイスの設定

Linux カーネルのバージョン。Red Hat Enterprise Linux 7 では単一の Linux カーネルバージョンのみを利用できることに注意してください。

インストールされているパッケージ。

30.2.2. VDO 設定

パーティションスキーム

VDO ボリュームで使用しているファイルシステム

VDO ボリュームに割り当てられている物理ストレージサイズ

作成した論理 VDO ボリュームのサイズ

スパースまたは密インデックス

メモリサイズの UDS インデックス

VDO のスレッド設定

30.2.3. ワークロード

テストデータを生成するためのツールタイプ

同時クライアント数

書き込まれたデータの重複 4 KB ブロックの量

読み書きパターン

ワーキングセットサイズ

VDO ボリュームは、各テストが同じディスク環境で行われるように特定のテスト間において再作成する必要があります。詳細はテストセクションで読んでください。

30.2.4. 対応システム設定

Red Hat は、Intel 64 アーキテクチャ上の Red Hat Enterprise Linux 7 で VDO をテストしています。

第第30章章 VOD 評価評価

321

VDO のシステム要件は、「システム要件」を参照してください。

VDO を評価する際には、以下のユーティリティーが推奨されています。

Flexible I/O Tester version 2.08 は、fio パッケージより利用できます。

sysstat version 8.1.2-2 またはそれ以降は、sysstat パッケージから利用できます。

30.2.5. テスト前のシステム準備

このセクションでは、評価中にパフォーマンスを最適化するためのシステムの設定方法を説明します。特定のテストで確立した暗黙的な限界を超えたテストを行うと、結果が異常になり、テスト時間が失われることがあります。例えば、このガイドでは、100 GB アドレス範囲にわたるランダム読み込みを行うテストを説明しています。500 GB のワーキングセットをテストするには、VDO ブロックマップキャッシュに割り当てられた DRAM の容量を適切に増大する必要があります。

システムの設定

お使いの CPU は最も高いパフォーマンス設定で稼働していることを確認してください。

可能であれば BIOS 設定や Linux cpupower ユーティリティを使用して周波数スケーリングを無効化してください。

可能であればターボモードを有効化し、スループットを最大化します。ターボモードでは、テスト結果に変動性が生じますが、パフォーマンスは、ターボなしのテストのパフォーマンスと一致することや、これを超過することがあります。

Linux の設定

ディスクベースソリューションについては、Linux では I/O スケジューラーアルゴリズムを利用できます。これにより、複数の読み込み/書き込みリクエストがキューに入っていれば、これらを処理できます。デフォルトでは、Red Hat Enterprise Linux は CFQ(Completely Fair Queuing) スケジューラーを使用しています。これは、多くの状況において回転ディスク (ハードディスク) アクセスを向上するような方法でリクエストを処理します。Red Hat では、回転ディスクに Deadline スケジューラーを使用することをおすすめしています。Red Hat ラボでは、より優れたスループットとレイテンシーを実現できることがわかっています。デバイス設定を以下に従って変更します。

# echo "deadline" > /sys/block/device/queue/scheduler

フラッシュベースのソリューションについては、noop スケジューラーが、Red Hat ラボテストにおいて、優れたランダムアクセススループットとレイテンシーを示しています。

# echo "noop" > /sys/block/device/queue/scheduler

ストレージデバイスの設定

ファイルシステム (ext4、XFS など) は、パフォーマンスに独自の影響を及ぼすことがあります。また、パフォーマンス測定を歪めることがあり、結果において VDO の影響を見つけにくくなります。合理性が認められる場合は、raw ブロックデバイスでパフォーマンスの測定を行うことをおすすめします。これが不可能であれば、ターゲット実装において使用するファイルシステムでデバイスをフォーマットしてください。

30.2.6. VDO 内部構造

Red Hat では、評価を完全かつ正しく行うには VDO の全般的なメカニズムを理解することは不可欠だ


322

Red Hat では、評価を完全かつ正しく行うには VDO の全般的なメカニズムを理解することは不可欠だと考えています。テストを行う人物が、特定の用途やユースケースを模造するためにテストプランの方向を変えることや、新しいプランを考案したいと考える場合に特にこのような理解が重要となります。詳細は、29章VDO 統合を参照してください。

Red Hat テストプランは、デフォルトの VDO 設定で動作するように書かれています。新しいテストを開発する際は、次のセクションの一覧の VDO パラメーターの一部を調整する必要があります。

30.2.7. VDO の最適化

高負荷高負荷

おそらく、最適なパフォーマンスを実現するために最も重要となるストラテジーは、ストレージシステムの負荷を示す、最適な I/O キューデプスを判別することです。最も現代的なストレージシステムは、高 I/O デプスで最適に動作します。VDO のパフォーマンスは、多くの同時リクエストで、最も適格に示すことができます。

同期同期 vs 非同期書き込みポリシー非同期書き込みポリシー

VDO は、同期または非同期という 2 つの書き込みポリシーで動作することが考えられます。デフォルトでは、VDO は、基礎となるストレージデバイスにとって最適な書き込みポリシーを自動的に選択します。

パフォーマンスをテストする際は、選択した書き込みポリシー VDO を把握しておく必要があります。以下のコマンドでは、お使いの VDO ボリュームの書き込みポリシーを示しています。

# vdo status --name=my_vdo

書き込みポリシーの詳細は、「VDO 書き込みポリシーの概要」と「VDO 書き込みモードの選択」を参照してください。

メタデータのキャッシングメタデータのキャッシング

VDO は、論理ブロックアドレスから物理ブロックアドレスへのマッピングの表を維持します。VDOは、特定のブロックにアクセスする際に関連のマッピングを検索する必要があります。デフォルトでは、VDO は DRAM に 128 MB を割り当て、1 度に 100 GB の論理領域への効率的なアクセスに対応します。このテストプランでは、この設定オプションに対する適切なワークロードが生まれます。

設定したキャッシュサイズを超えるワーキングセットには、リクエストをサービスするためにさらなるI/O が必要になります。この場合、パフォーマンスが低下します。さらにメモリが利用できる場合は、ブロックマップキャッシュを増大する必要があります。ワーキングセットが、ブロックマップがメモリに保持できる量を超えると、関連のブロックマップページを参照するために、さらに I/O オーバーヘッドが発生することがあります。

VDO マルチスレッド設定マルチスレッド設定

最適なパフォーマンスを実現するためには、VDO のスレッド設定を調整する必要があります。VDO ボリュームを作成する際にこれらの設定を変更する方法は、VDO 統合ガイドを参照してください。最適な設定を見いだすテストの設計の相談は Red Hat セールスエンジニアまでご連絡ください。

データ内容データ内容

VDO が重複排除と圧縮を行うため、これらの機能を効果的に利用するには、テストデータセットを選択する必要があります。


323

30.2.8. 読み込みパフォーマンスのテストを行うための特別な考慮事項

読み込みパフォーマンスをテストする際には、以下の 3 つのことを考慮する必要があります。

1. 4 KB ブロックに書き込みが行われたことがない場合、VDO はストレージに対して I/O を実行しなくなり、ゼロブロックですぐに応答します。

2. 4 KB ブロックに書き込みが行われたことがある場合、VDO はストレージに対して I/O を実行しなくなり、ゼロブロックですぐに応答します。

このような性質により、読み込むデータがない場合に、読み込みパオフォーマンスが非常に高速になります。これにより、読み込みテストが実際のデータを事前に入力することが必須になります。これにより、読み込みテストが実際のデータを事前に入力することが必須になります。

30.2.9. クロストーク

あるテストが別のテストの結果に影響を及ぼさないようにするには、各テストの各反復に対して新しいVDO ボリュームを作成することが推奨されます。

30.3. データ効率のテスト手順

以下の詳細なテスト手順に従うことで、VODO の検証を正しく行うことができます。このセクションでは、想定される結果とともに一連の手順を説明します。これは、評価を行うタイミングを図るテストの一例としても参照できます。

テスト環境次のセクションのテストケースでは、テスト環境を以下のようなものと仮定します。

1 台以上の Linux 物理ブロックデバイスを利用できる。

ターゲットブロックデバイス (例: /dev/sdb) が 512 GB を超える。

柔軟な I/O テスター (fio) バージョン 2.1.1 以降がインストールされている。

VDO がインストールされている。

テスト環境を完全に把握するためにも、テストを行う前に以下の情報を記録する必要があります。

カーネルのビルド番号を含む、使用している Linux ビルド。

rpm -qa コマンドから取得した、インストールされているパッケージの完全なリスト。

完全なシステム仕様:

CPU のタイプと数 (/proc/cpuinfo から参照可能)。

ベース OS が起動した後に参照できる搭載メモリとサイズ (/proc/meminfo から参照可能)。

使用しているドライブコントローラーのタイプ。

使用しているディスクのタイプと数。

実行しているプロセスの完全なリスト (ps aux などのリスト)。

VDO で使用するために作成した物理ボリュームとボリュームグループの名前 (pvs や vgs で表示可能)。


324

VDO ボリュームのフォーマットを行う際に使用したファイルシステム (該当する場合)。

マウントしたディレクトリーのパーミッション。

/etc/vdoconf.yaml の内容。

VDO ファイルの場所。

sosreport を実行することで、必要な多くの情報を取得できます。

ワークロードVDO を効果的にテストするには、実際のワークロードを再現するデータセットを使用する必要があります。このデータセットは、さまざまな状況下でパフォーマンスのデモンストレーションを行うために、重複排除や圧縮できるデータとできないデータのバランスを調整することができます。

再現性を持つデータを合成的に生成できるツールはいくつかあります。特に、VDbench と fio は、テスト中の使用におすすめです。

このガイドでは fioを使用します。評価を成功させるには、引数の理解が不可欠です。

表表30.1 fio オプションオプション

引数引数説明説明値値

--size データ fio のサイズがジョブごとのターゲットに送信されます (以下の numjobs を参照)。

100 GB

--bs fio によって生成される各読み書きリクエストのブロックサイズ。Red Hat では、VOD の 4 KB デフォルトに一致するように 4 KB ブロックサイズを推奨しています。

4k

--numjobs fio がベンチマークを実行するために作成するジョブの数。

各ジョブは、--size パラメーターで指定されたデータの量を送信します。

最初のジョブは、--offset パラメーターで指定したオフセットで、デバイスにデータを送信します。後続のジョブは、- - offset_increment パラメーターが指定されていない限り、ディスクの同じ領域を書き込みます (上書き)。これにより、以前のジョブがその値によって開始された各ジョブがオフセットされます。フラッシュでパフォーマンスを最大限まで引き出すには、最低でも 2 つのジョブが必要です。回転ディスク (HDD) スループットのサチュレートには、1 つのジョブで十分です。

1 (HDD)

2 (SSD)

--thread fio ジョブに、フォークされるのではなく、スレッドで実行するように命令します。これにより、コンテキストスイッチを制限することでパフォーマンスを向上できる可能性があります。

<N/A>


325

--ioengine Linux では、複数の I/O エンジンを利用できます。これは、fio を使用してテストできます。Red Hat のテストでは、非同期のバッファなしのエンジンを使用します (libaio)。別のエンジンについては、Red Hat セールスエンジニアまでご相談ください。

Linux libaio エンジンは、1 つ以上のプロセスがランダムなリクエストを同時に行うワークロードを評価するのに使用されます。libaio では、データが取得される前に、単一のスレッドから非同期的に複数のリクエストを作成できます。これにより、リクエストが同期的なエンジンから manythreads によって与えられる場合に必要となるコンテキストスイッチの数が制限されます。

libaio

--direct これを設定すると、Linux カーネルのページキャッシュをバイパスするデバイスにリクエストを送信できるようになります。

Libaio エンジン: libaio は、direct を有効化 (=1) して使う必要があります。または、カーネルは、すべての I/O リクエストの sync AIPI にリゾートすることがあります。

1 (libaio)

--iodepth 常時実行している I/O バッファーの数。

iodepth を高く指定すると、通常では、ランダム読み込みまたは書き込みのパフォーマンスが向上します。高デプスでは、コントローラーが常にバッチリクエストを受けるようにします。ただし、iodepth を高く設定しすぎると (1K 以上)、予期しないレイテンシーが発生することがあります。Red Hat では、128 〜 512 の iodepth を推奨していますが、最終値は妥協点で、アプリケーションのレイテンシー許容に依存します。

128 (最小)

--iodepth_batch_submit iodepth バッファープールが空になり始めたときに作成するI/O の数。このパラメーターは、テスト中の I/O からバッファー生成を切り替えるタスクを制限します。

16

--iodepth_batch_complete

バッチを送信する前に完了する I/O の数(iodepth_batch_complete)。このパラメーターは、テスト中の I/O からバッファー生成を切り替えるタスクを制限します。

16

--gtod_reduce レイテンシーを計算するために時刻の呼び出しを無効化します。この設定が有効化されると (=0) スループットが低減します。レイテンシー測定が必要な場合を除き、有効化 (=1) してください。

1

引数引数説明説明値値

30.3.1. VDO テストボリュームの設定

1. 512 GB の物理ボリューム上で、論理サイズの物理ボリューム上で、論理サイズ 1 TB でで VDO ボリュームを作成しますボリュームを作成します

1. VDO ボリュームを作成します。

同期ストレージのトップ上で VDO async モードをテストするには、--writePolicy=async


326

同期ストレージのトップ上で VDO async モードをテストするには、--writePolicy=asyncオプションを指定して非同期ボリュームを作成します。

# vdo create --name=vdo0 --device=/dev/sdb \ --vdoLogicalSize=1T --writePolicy=async --verbose

同期ストレージ上で VDO sync モードをテストするには、--writePolicy=sync オプションを指定して同期ボリュームを作成します。

# vdo create --name=vdo0 --device=/dev/sdb \ --vdoLogicalSize=1T --writePolicy=sync --verbose

2. XFS または ext4 ファイルシステムで新しいデバイスをフォーマットします。

XFS:

# mkfs.xfs -K /dev/mapper/vdo0

ext4:

# mkfs.ext4 -E nodiscard /dev/mapper/vdo0

3. フォーマット済みのデバイスをマウント:

# mkdir /mnt/VDOVolume# mount /dev/mapper/vdo0 /mnt/VDOVolume && \ chmod a+rwx /mnt/VDOVolume

30.3.2. VDO 効率のテスト

2. VDO ボリュームへの読み書きテストボリュームへの読み書きテスト

1. 32 GB のランダムデータを VDO ボリュームに書き込みます。

$ dd if=/dev/urandom of=/mnt/VDOVolume/testfile bs=4096 count=8388608

2. VDO ボリュームからデータを読み込み、VDO ボリュームではない別の場所に書き込みます。

$ dd if=/mnt/VDOVolume/testfile of=/home/user/testfile bs=4096

3. diff を使用して 2 つのファイルを比較します。ファイルが同じであることが報告されるはずです。

$ diff -s /mnt/VDOVolume/testfile /home/user/testfile

4. VDO ボリューム上の第 2 の場所にファイルをコピーします。

$ dd if=/home/user/testfile of=/mnt/VDOVolume/testfile2 bs=4096

5. 第 3 のファイルを第 2 のファイルと比較します。同じファイルであることが報告されるはずで


327

5. 第 3 のファイルを第 2 のファイルと比較します。同じファイルであることが報告されるはずです。

$ diff -s /mnt/VDOVolume/testfile2 /home/user/testfile

3. VDO ボリュームの削除ボリュームの削除

1. VDO ボリューム上に作成されたファイルシステムのマウント解除:

# umount /mnt/VDOVolume

2. コマンドを実行して VDO ボリューム vdo0 をシステムから削除します。

# vdo remove --name=vdo0

3. ボリュームが削除されたことを確認します。vdo list には、VDO パーティションについてのリストがないはずです。

# vdo list --all | grep vdo

4. 重複排除の測定重複排除の測定

1. 「VDO テストボリュームの設定」に従って、VDO ボリュームを作成してマウントします。

2. vdo1 から vdo10 という VDO ボリューム上に 10 個のディレクトリーを作成して、テストデータセットの 10 個のコピーを保持します。

$ mkdir /mnt/VDOVolume/vdo{01..10}

3. ファイルシステムに従って、使用ディスク容量を調べます。

$ df -h /mnt/VDOVolume

Filesystem Size Used Avail Use% Mounted on/dev/mapper/vdo0 1.5T 198M 1.4T 1% /mnt/VDOVolume

結果を表にまとめてください。

統計統計ベアファイルシステムベアファイルシステムシード後シード後 10 個のコピー個のコピー後後

ファイルシステム利用サイズ 198 MB

使用済み VDO データ

使用済み VDO 論理

4. 以下のコマンドを実行して値を記録します。「使用済みデータブロック」は、VDO 下で実行している物理デバイス上のユーザーデータによって使用されているブロック数です。「使用済み論理ブロック」は、最適化前に使用したブロックの数です。これは、測定の開始地点として使


328

用されます。

# vdostats --verbose | grep "blocks used"

data blocks used : 1090overhead blocks used : 538846logical blocks used : 6059434

5. VOD ボリュームのトップレベルでのデータソースファイルの作成

$ dd if=/dev/urandom of=/mnt/VDOVolume/sourcefile bs=4096 count=1048576

4294967296 bytes (4.3 GB) copied, 540.538 s, 7.9 MB/s

6. 使用中の使用済み物理ディスク容量を再び調べます。これにより、書き込みしたファイルに一致する、使用済みブロック数における上昇が表示されます。


Filesystem Size Used Avail Use% Mounted on/dev/mapper/vdo0 1.5T 4.2G 1.4T 1% /mnt/VDOVolume


data blocks used : 1050093 (increased by 4GB)overhead blocks used : 538846 (Did not change)logical blocks used : 7108036 (increased by 4GB)

7. それぞれ 10 個のサブディレクトにファイルをコピーします。

$ for i in {01..10}; do cp /mnt/VDOVolume/sourcefile /mnt/VDOVolume/vdo$i done

8. 再び、使用済み (使用済みデータブロック) 物理ディスク容量を確認します。この数は、上記のステップ 6 の結果と同等ですが、ファイルシステムのジャーナリングとメタデータにより、多少の増大が見られます。


Filesystem Size Used Avail Use% Mounted on/dev/mapper/vdo0 1.5T 45G 1.3T 4% /mnt/VDOVolume


data blocks used : 1050836 (increased by 3M)overhead blocks used : 538846logical blocks used : 17594127 (increased by 41G)

9. テストデータを書き込む前に、見つかった値からファイルシステムによって使用されている容量の、この新しい値を差し引きます。これは、ファイルシステムの視点から、このテストによって消費される容量です。


329

10. 記録した統計から節約できた容量を見てください。

注意注意: 以下の表では、値が MB/GB に変換されています。vdostats ”ブロック” は 4,096 B です。

統計統計ベアファイルシステムベアファイルシステムシード後シード後 10 個のコピー個のコピー後後

ファイルシステム利用サイズ 198 MB 4.2 GB 45 GB

使用済み VDO データ 4 MB 4.1 GB 4.1 GB

使用済み VDO 論理 23.6 GB* 27.8 GB 68.7 GB

* 1.6 TB フォーマットドライブのファイルシステムオーバーヘッド

5. 圧縮の測定圧縮の測定

1. 最低でも 10 GB の物理サイズ、論理サイズの VDO ボリュームを作成します。重複排除を無効化して圧縮を有効にするオプションを追加します。

# vdo create --name=vdo0 --device=/dev/sdb \ --vdoLogicalSize=10G --verbose \ --deduplication=disabled --compression=enabled

2. 転送する前に VDO 統計を調べます。使用しているデータブロックと論理ブロックをメモします (両方とも 0)。


3. XFS または ext4 ファイルシステムで新しいデバイスをフォーマットします。

XFS:

# mkfs.xfs -K /dev/mapper/vdo0

ext4:

# mkfs.ext4 -E nodiscard /dev/mapper/vdo0

4. フォーマット済みのデバイスをマウント:

# mkdir /mnt/VDOVolume# mount /dev/mapper/vdo0 /mnt/VDOVolume && \ chmod a+rwx /mnt/VDOVolume

5. 未完了の圧縮を完了させるために VDO ボリュームを同期します。

# sync && dmsetup message vdo0 0 sync-dedupe

6. 再び VDO 統計を調べます。使用論理ブロックと使用データブロックは、ファイルシステムの


330

6. 再び VDO 統計を調べます。使用論理ブロックと使用データブロックは、ファイルシステムのみの圧縮で節約した 4 KB ブロックの数です。VDO は、ファイルシステムオーバーヘッドと同様、実際のユーザーデータも最適化します。


7. /lib の内容を VDO ボリュームにコピーします。合計サイズを記録します。

# cp -vR /lib /mnt/VDOVolume

...sent 152508960 bytes received 60448 bytes 61027763.20 bytes/sectotal size is 152293104 speedup is 1.00

8. Linux キャッシュと VDO ボリュームを同期します。

# sync && dmsetup message vdo0 0 sync-dedupe

9. VDO 統計を再び調べます。使用した論理ブロックとデータブロックを調べます。


使用した論理ブロック - 使用データブロックは、/lib ファイルのコピーに対して使用した容量 (4 KB ブロック単位) を示します。

合計サイズ (「4. 重複排除の測定」の表) - (論理ブックと使用済みデータブロック * 4096)= バイトが圧縮によって節約されます。

10. VDO ボリュームの削除:

# umount /mnt/VDOVolume && vdo remove --name=vdo0

6. VDO 圧縮効率のテスト圧縮効率のテスト

1. 「VDO テストボリュームの設定」に従って、VDO ボリュームを作成してマウントします。

2. ボリュームを削除せずに、「4. 重複排除の測定」と「5. 圧縮の測定」の実験を繰り返します。vdostats において、容量節約の変化を見てください。

3. 独自のデータセットで実験を行います。

7. TRIM Zとと DISCARD についてについて

シンプロビジョニングでは、基礎となる物理ストレージよりも論理ストレージ容量または仮想ストレージ容量を大きくできます。ファイルシステムなどのアプリケーションは、より大きな仮想レイヤーのストレージで実行できるといったメリットを得ることができます。また、データ重複排除などのデータ効率技術により、すべてのデータを保存する必要があった物理的なブロックの数を減らすことができます。これらのストレージ節約からメリットを得るには、物理ストレージ層が、アプリケーションデータが削除されたときを把握する必要があります。

従来のファイルシステムは、データが削除されたときに、基礎となるストレージに通知を行う必要はありませんでした。シンプロビジョニングしたストレージを扱うファイルシステムは、TRIM または DISCARD コマンドを送信して、論理ブロックが不要になった際にストレージシステムに通知します。


331

これらのコマンドは、ブロックが dscard マウントオプションを指定して削除されれば送信できます。または、これらのコマンドは、使用されていない論理ブロックを検出し、TRIM または DISCARD コマンドという形式で、ストレージシステムに情報を送信するようにファイルシステムに命令する fstrimなどのユーティリティを実行することで統制下で送信できます。

仕組みは、以下の手順に従うことで見ることができます。

1. 「VDO テストボリュームの設定」に従って、新しい VDO 論理ボリュームを作成してマウントします。

2. ファイルシステムをトリムして、不要なブロックを削除します (この方法は時間がかかります)。

# fstrim /mnt/VDOVolume

3. 次のコマンドを実行して、以下の表に初期状態を記録します。

$ df -m /mnt/VDOVolume

ファイルシステムで使用されている容量を見ることができます。また、vdostats を実行して、どの程度の物理データブロックと論理データブロックがしようされているかを確認します。

4. VDO 上で実行しているファイルシステムに重複してないデータで 1 GB ファイルを作成します。

$ dd if=/dev/urandom of=/mnt/VDOVolume/file bs=1M count=1K

そして、同じデータを収集します。ファイルシステムは、さらに 1 GB を使用しているはずです。また、使用したデータブロックや論理ブロックは同じように増大します。

5. fstrim /mnt/VDOVolume を実行して、新しいファイルを作成後にも影響がないことを確認します。

6. 1 GB ファイルを削除します。

$ rm /mnt/VDOVolume/file

パラメーターを確認して記録します。ファイルシステムは、ファイルが削除されたことを認識してますが、物理ブロックや論理ブロックの数に変更はありません。これは、ファイル検出が、基礎となるストレージに通信していないためです。

7. fstrim /mnt/VDOVolume を実行して、同じパラメーターを記録します。fstrim は、ファイルシステムの空きブロックを検索し、TRIM コマンドを、使用していないアドレスの VDO ボリュームに送信します。これにより、関連の論理ブロックがリリースされ、VDO が TRIM を処理し、基礎となる物理ブロックがリリースされます。

ステップステップ使用されるファイル容使用されるファイル容量量 (MB)

使用されているデータ使用されているデータブロックブロック

使用されている論理ブ使用されている論理ブロックロック

Initial

1 GB ファイルの追記亜


332

fstrim の実行

1 GB ファイルの削除

fstrim の実行

ステップステップ使用されるファイル容使用されるファイル容量量 (MB)

使用されているデータ使用されているデータブロックブロック

使用されている論理ブ使用されている論理ブロックロック

この演習から、TRIM プロセスが必要であるため、基礎となるストレージが使用容量を正確に把握できます。fstrim は、より効率を高めるために 1 度に多くのブロックを解析するコマンドラインツールです。代替の方法としては、マウントの際にファイルシステム discard オプションを使用することが考えられます。この破棄 (discard) オプションは、各ファイルシステムのブロックが削除された後に基礎となるストレージを更新します。これにより、スループットの速度が低減する可能性がありますが、使用率をより正確に把握できます。また、TRIM または DISCARD する必要があることが VDO に限らないということを理解することが重要です。すべてのシンプロビジョニングしたストレージシステムが同じ課題を抱えています。

30.4. パフォーマンステスト手順

このセクションでの目標は、VDO がインストールされているデバイスのパフォーマンスプロファイルを構築することです。各テストは、VDO がインストールされている状態とされていない状態で行う必要があります。これにより、ベースシステムのパフォーマンスに関連して VDO のパフォーマンスを評価することができます。

30.4.1. 第 1: I/O デプスの影響、固定 4 KB ブロック

このテストでの目標は、アプライアンスに対して最適なスループットを生成し、レイテンシーを最低限に抑える I/O デプスを判別することです。VDO は、従来のストレージデバイスに使われていた従来の512 B ではなく、4 KB セクターサイズを使用します。セクターサイズを大きくすることで、より容量の多いストレージに対応し、パフォーマンスを向上して、多くのオペレーティングシステムで使用されるキャッシュバッファーサイズに一致できるようになります。

1. 4 KB I/O および、1、8、16、32、64、128、256、512、1024 の I/O デプスで 4 コーナーテストを実行します。

連続の 100% 読み込み。固定 4 KB*

連続の 100% 書き込み。固定 4 KB

ランダムの 100% 読み込み。固定 4 KB*

ランダムの 100% 書き込み。固定 4 KB**

* 書き込み書き込み fio ジョブを最初に実行することで、読み込みテスト中に読み込める領域を事前に入ジョブを最初に実行することで、読み込みテスト中に読み込める領域を事前に入力力

** 4 KB ランダム書き込みランダム書き込み I/O 実行後に実行後に VDO ボリュームを再作成ボリュームを再作成

サンプルシェルテスト入力 (書き込み):

# for depth in 1 2 4 8 16 32 64 128 256 512 1024 2048; do fio --rw=write --bs=4096 --name=vdo --filename=/dev/mapper/vdo0 \


333

--ioengine=libaio --numjobs=1 --thread --norandommap --runtime=300\ --direct=1 --iodepth=$depth --scramble_buffers=1 --offset=0 \ --size=100g done

2. 各データポイントでスループットとレイテンシーを記録して、グラフに示します。

3. テストを繰り返し、4 コーナーテストを完了させます。--rw=randwrite、--rw=read、--rw=randread

結果は、以下のグラフ通りです。重要なのは、I/O の上昇により、スループット増大が低減することが証明されている範囲と変曲点の動作です。同じように、連続アクセスやランダムアクセスは、異なる値でピークに達しますが、あらゆるストレージ構成に対して異なります。図30.1「I/O デプス解析」の各パフォーマンスカーブの「曲部」に注意してください。マーカー 1 は、ポイント X の連続スループットのピークを示し、マーカー 2 は、ポイント Z でのランダム 4 KB スループットのピークを示しています。

このアプライアンスは、連続 4 KB I/O デプス > X からメリットを得ていません。そのデプスを超えると、帯域幅の上昇が減少し、平均リクエストレイテンシーが各追加 I/O リクエストに対して 1:1 上昇します。

このアプライアンスは、このアプライアンスは、ランダム 4 KB I/O デプス > Z からメリットを得ていません。そのデプスを超えると、帯域幅の上昇が減少し、平均リクエストレイテンシーが各追加 I/O リクエストに対して 1:1 上昇します。

図図30.1 I/O デプス解析デプス解析

図30.2「ランダム書き込みの、増大する I/O のレイテンシーレスポンス」では、図30.1「I/O デプス解析」のカーブの「曲部」の後のランダム書き込みレイテンシーの例を示しています。ベンチマーキング処理では、最も低いレスポンス時間ペナルティを受ける最大スループットのポイントでテストを行う必要があります。このサンプルアプライアンスのテスト計画を進めていくにあたり、I/O デプス = Z で別のデータを収集します。


334

図図30.2 ランダム書き込みの、増大するランダム書き込みの、増大する I/O のレイテンシーレスポンスのレイテンシーレスポンス

30.4.2. 第 2 段階: I/O リクエストサイズの影響

このテストの目標は、以前の手順で判別した最適な I/O デプスで、テスト下のシステムの最適なパフォーマンスを生成するブロックサイズを理解することです。

1. 8 KB から 1 の範囲にわたる可変ブロックサイズ (2 のべき乗) で、MB固定 I/O デプスで 4 コーナーテストを実行します。テスト間に読み込む領域と、テスト間に再作成するボリュームの領テスト間に読み込む領域と、テスト間に再作成するボリュームの領域を事前に入力することを忘れないでください。域を事前に入力することを忘れないでください。

2. 「第 1: I/O デプスの影響、固定 4 KB ブロック」で判別した値に I/O デプスを設定します。

サンプルシェルテスト入力 (書き込み):

# z=[see previous step]# for iosize in 4 8 16 32 64 128 256 512 1024; do fio --rw=write --bs=$iosize\k --name=vdo --filename=/dev/mapper/vdo0 --ioengine=libaio --numjobs=1 --thread --norandommap --runtime=300 --direct=1 --iodepth=$z --scramble_buffers=1 --offset=0 --size=100g done


4. テストを繰り返し、4 コーナーテストを完了させます。--rw=randwrite、--rw=read、--rw=randread

この結果では、いくつか重要なことに気がつくことでしょう。この例では:

連続書き込みが、リクエストサイズでピークのスループットに達します。この曲部は、設定可能なアプリケーション、または特定のリクエストサイズが大半を占めるアプリケーションがより多くのスループットを生成します。これは、4 KB I/Os がマージすることでメリットを得ることがあるためです。

連続読み込みは、ポイント Z で同じようなピークスループットに達します。これらのピーグ後は、I/O が完了するまでの全体的なレイテンシーが、これ以上のスループットなしで上昇することを覚えておいてください。このサイズを超える I/O を受け入れないようにデバイスを調整することが最善です。

ランダム読み込みは、ポイント X でピークスループットに達します。一部のデバイスは、大きなリクエストサイズのランダムアクセスで、ほぼ連続のスループット率に達することがあります。一方、その他は、真の連続アクセスと異なる場合に、より多くのペナルティを受けること


335

になります。

ランダム書き込みは、ポイント Y でピークスループットに達します。ランダム書き込みは、重複排除デバイスの多くの相互作用を伴います。また、VDO は、リクエストサイズや I/O デプスが大きい場合に特に高パフォーマンスを発揮します。

このテストの結果図30.3「リクエストサイズ vs スループット分析とキー変曲点ポイント」は、ストレージデバイスの特徴や特定のアプリケーションのユーザーエクスペリエンスを理解するのに役立ちます。さまざまなリクエストサイズでパフォーマンスを増大するために、さらなる調整が必要かどうかは、Red Hat セールスエンジニアまでご相談ください。

図図30.3 リクエストサイズリクエストサイズ vs スループット分析とキー変曲点ポイントスループット分析とキー変曲点ポイント

30.4.3. 第 3 段階: 混合読み書き I/O の影響

このテストは、混合 I/O 負荷 (読み込み/書き込み) を示したとき VDO を持つアプリライアンスが動作する仕組みを理解することを目的としています。また、最適なランダムキューデプスと 4 KB から 1 MBリのクエストサイズで読み込み/書き込みの混合の影響を分析します。状況に合わせて適切な方を使用してください。

1. 固定 I/O デプス、 8 KB から 256 KB の範囲の可変ブロックサイズ (2 のべき乗) で 4 コーナーテストを実行し、読み込み率を 10% インクリメントに設定します。これは 0 % から始まります。テスト間に読み込む領域や、再作成する領域を事前に入力するのを忘れないでください。テスト間に読み込む領域や、再作成する領域を事前に入力するのを忘れないでください。

2. 「第 1: I/O デプスの影響、固定 4 KB ブロック」で判別した値に I/O デプスを設定します。

サンプルテスト入力 (読み込み/書き込み混合):

# z=[see previous step]# for readmix in 0 10 20 30 40 50 60 70 80 90 100; do for iosize in 4 8 16 32 64 128 256 512 1024; do fio --rw=rw --rwmixread=$readmix --bs=$iosize\k --name=vdo \ --filename=/dev/mapper/vdo0 --ioengine=libaio --numjobs=1 --thread \ --norandommap --runtime=300 --direct=0 --iodepth=$z --scramble_buffers=1 \ --offset=0 --size=100g done done


図30.4「パフォーマンスは、変化する読み込み/書き込み混合にわたり一貫性があります」では、VDO


336

図30.4「パフォーマンスは、変化する読み込み/書き込み混合にわたり一貫性があります」では、VDOがどのように I/O 負荷に応答する例を示しています。

図図30.4 パフォーマンスは、変化する読み込みパフォーマンスは、変化する読み込み/書き込み混合にわたり一貫性があります書き込み混合にわたり一貫性があります

パフォーマンス (集約) とレイテンシー (集約) は、混合する読み込みと書き込みの範囲にわたり比較的に一貫しており、より低い最大書き込みスループットから、より高い最大読み込みスループットという傾向にあります。

この動作は、ストレージによって異なります。しかし、ここで重要なことは、パフォーマンスが、変換する負荷下で一環しており、特定の読み書き混合を示すアプリケーションに対して期待されるパフォーマンスを理解できることです。予期しない結果が出た場合、VOD またはストレージデバイス自体に変更が必要でれば、Red Hat セールスエンジニアがわかりやすくご説明させていただきます。

注意注意: 同等の一貫性を示すシステムは、準最適な設定を示します。このような場合は、Red Hat セールスエンジニアまでご連絡ください。

30.4.4. 第 4 段階: アプリケーション環境

これらの最終テストは、VOD を持つシステムが、実際のアプリケーション環境で展開されたときの動作の仕組みを理解することを目的としています。可能であれば、実際のアプリケーションを使用し、これまで学んだ知識を適用してください。アプライアンスでの許容範囲のキューデプスの制限を考慮します。可能であれば、VDO パフォーマンスにより優勢なブロックサイズでリクエストを発行してください。

リクエストサイズ、I/O 負荷、読み込み/書き込みパターンなどは、一般的に予測が難しくなっています。アプリケーションのユースケース (フィルター、仮想デスクトップ、データベース) によって異なり、アプリケーションは、特定の動作またはマルチテナントアクセスに基づいて I/O のタイプが異なることが多々あるためです。

この最終テストでは、混合環境における一般的な VDO パフォーマンスを示しています。想定している環境について、より詳細な情報がある場合は、これらの設定もテストしてください。

サンプルテスト入力 (読み込み/書き込み混合):

# for readmix in 20 50 80; do for iosize in 4 8 16 32 64 128 256 512 1024; do fio --rw=rw --rwmixread=$readmix --bsrange=4k-256k --name=vdo \ --filename=/dev/mapper/vdo0 --ioengine=libaio --numjobs=1 --thread \ --norandommap --runtime=300 --direct=0 --iodepth=$iosize \


337

--scramble_buffers=1 --offset=0 --size=100g done done

各データポイントでスループットとレイテンシーを記録し、これをグラフで示します (図30.5「混合環境パフォーマンス」)。

図図30.5 混合環境パフォーマンス混合環境パフォーマンス

30.5. 問題の報告

VOD の操作中に問題が発生した場合には、Red Hat セールスエンジニアが問題を再現しやすくするためにも、可能な限りの情報を集めることが重要です。

問題の報告には、以下の内容を含めるようにしてください。

テスト環境の詳細な説明。詳しくは「テスト環境」を参照

VDO 設定

問題が発生したユースケース

エラーが発生したときに行った操作

コンソールまたはターミナル上のテキストエラーメッセージ

カーネルログファイル

カーネルクラッシュダンプ (参照可能であれば)

sosreport の出力。Linux 環境全体を説明したデータがキャプチャされます

30.6. 結論

ストレージシステムに VDO を統合するにあたり、このよく構築された評価プランや他の評価プランに一通り目を通すことが重要です。この評価プロセスでは、パフォーマンスの理解と潜在的な互換性問題を把握することが重要です。この評価の結果を得ることで、重複排除や圧縮を実証することだけでなく、VDO を実装するシステムのパフォーマンスプロファイルを得ることができます。また、この結果は、実際のアプリケーションで達成した結果が期待通りか否かを判別するのにも役立ちます。最後に、これらの結果を利用して、VDO と相性良く動作するタイプのアプリケーションを予測することができます。


338

付録A ストレージ管理に関する RED HAT CUSTOMER PORTALLABSRed Hat Customer Portal Labs のツールは、パフォーマンスの向上、問題のトラブルシューティング、セキュリティー問題の特定、設定の最適化に役立てていただくために開発しました。この付録では、ストレージ管理に関連する Red Hat Customer Portal Labs ツールの概要を説明します。Red HatCustomer Portal Labs は https://access.redhat.com/labs/ からご利用いただくことができます。

SCSI DECODERSCSI decoder は、SCSI エラーメッセージの理解を容易にするため、SCSI エラーメッセージを /log/*ファイルまたはログファイルのスニペットにデコードするように作られています。

SCSI decoder は、各 SCSI エラーメッセージを個別に診断し、問題を効果的に解決するためのソリューションを提示します。

FILE SYSTEM LAYOUT CALCULATORFile System Layout Calculator は、現在使用しているストレージ、または使用が計画されているストレージに関する情報を入力すると、ext3、ext4、および xfs の各ファイルシステムを作成するのに最適なパラメーターを提示します。クエスチョンマーク ("?") にマウスポインターを置くと、各フィールドの簡単な説明が表示されます。また、画面の下の方にスクロールすると、すべてのオプションの説明が確認できます。

File System Layout Calculator で、指定した RAID ストレージに提供されているパラメーターを使用して、ファイルシステムを作成するコマンドを生成します。作成されたコマンドをコピーして、root でそのコマンドを実行して、必要なファイルシステムを作成します。

LVM RAID CALCULATORLVM RAID Calculator は、ストレージ情報を入力すると、RAID に論理ボリューム (LVM) を作成するのに最適なパラメーターを提示するために作られました。クエスチョンマーク ("?") にマウスポインターを置くと、各フィールドの簡単な説明が表示されます。また、画面の下の方にスクロールすると、すべてのオプションの説明が確認できます。

LVM RAID Calculator で、指定した RAID ストレージに LVM を作成するコマンドを生成します。作成されたコマンドをコピーして、root でそのコマンドを実行して、必要な LVM を作成します。

ISCSI HELPERiSCSI Helper は、インターネットプロトコル (IP) ネットワーク越しにブロックレベルのストレージを提供し、サーバーの仮想環境でストレージプールを使用できるようにします。

iSCSI Helper では、入力した設定に基づいて、iSCSI ターゲット (サーバー) または iSCSI イニシエーター (クライアント) のロールに合わせてシステムを構成するスクリプトを生成します。

SAMBA CONFIGURATION HELPERSamba Configuration Helper は、基本的なファイルと、Samba を通してプリンター共有を提供する設定を作成します。

Server をクリックして、基本的なサーバー設定を指定します。

Shares をクリックして、共有するディレクトリーを追加します。

Server をクリックして、割り当てるプリンターを個別に追加します。

MULTIPATH HELPER

Multipath Helper は、Red Hat Enterprise Linux 5、6、または 7 のマルチパスデバイスに最適な設定を

付録付録A ストレージ管理に関するストレージ管理に関する RED HAT CUSTOMER PORTAL LABS

339

https://access.redhat.com/labs/

https://access.redhat.com/labs/scsi

https://access.redhat.com/labs/fslayoutcalculator

https://access.redhat.com/labs/lvmraidcalculator

https://access.redhat.com/labs/iscsihelper/

https://access.redhat.com/labs/sambaconfig/

Multipath Helper は、Red Hat Enterprise Linux 5、6、または 7 のマルチパスデバイスに最適な設定を作成します。手順に従っていけば、カスタムのエイリアスやデバイスのブラックリストなど、高度なマルチパス設定を作成できます。

また、Multipath Helper は、確認に使用する multipath.conf ファイルも提供します。必要な設定が終了したら、インストールスクリプトをダウンロードして、サーバーで実行します。

NFS HELPERNFS Helper を使えば、新しい NFS サーバーやクライアントの設定が簡単に行えます。手順に従ってエクスポートまたはマウントの情報を指定すると、NFS 設定スクリプトがダウンロードできるようになります。

MULTIPATH CONFIGURATION VISUALIZERMultipath Configuration Visualizer は sosreport のファイルを解析してダイアグラムを提供し、マルチパス環境を視覚化します。Multipath Configuration Visualizer を使用して、以下を表示します。

サーバーの HBA (Host Bus Adapters)、ローカルデバイス、および iSCSI デバイスを含むホストコンポーネント

ストレージのストレージコンポーネント

サーバーとストレージとの間のファブリック、またはイーサネットのコンポーネント

上記の全コンポーネントのパス

.xz、.gz、または .bz2 形式で圧縮した sosreport をアップロードするか、クライアントの解析用に選択したディレクトリーに sosreport を展開します。

RHEL BACKUP AND RESTORE ASSISTANTRHEL Backup and Restore Assistant は、バックアップと復元のツールと、Linux における一般的なシナリオに関する情報を提供します。

対象ツール:

dump およびおよび restore: ext2、ext3、または ext4 のファイルシステムのバックアップ

tar およびおよび cpio: たとえばテープドライブをバックアップする際に使用される、ファイルおよびフォルダーのアーカイブまたは復元

rsync: バックアップ操作の実行と、ファイルとディレクトリーの同期

dd: 関連するファイルシステムやオペレーティングシステムとは無関係に、ブロックごとにファイルをコピー

対象シナリオ:

障害回復

ハードウェアの移行

パーティションテーブルのバックアップ

重要なフォルダーのバックアップ

増分バックアップ

差分バックアップ


340

https://access.redhat.com/labs/multipathhelper/

https://access.redhat.com/labs/nfshelper/

https://access.redhat.com/labs/mpcv/

https://access.redhat.com/labs/rbra/

付録B 改訂履歴

改訂改訂 4-09 Mon Jan 7 2019 Marek Suchanek非同期のアップデート

改訂改訂 4-08 Mon Oct 23 2018 Marek Suchanek7.6 GA 公開用ドキュメントの準備

改訂改訂 4-07 Thu Sep 13 2018 Marek Suchanek非同期のアップデート

改訂改訂 4-00 Fri Apr 6 2018 Marek Suchanek7.5 GA 公開用ドキュメントバージョン

改訂改訂 3-95 Thu Apr 5 2018 Marek Suchanek非同期のアップデート

改訂改訂 3-93 Mon Mar 5 2018 Marek Suchanek新章: VDO 統合

改訂改訂 3-92 Fri Feb 9 2018 Marek Suchanek非同期のアップデート

改訂改訂 3-90 Wed Dec 6 2017 Marek Suchanek7.1 Alpha 公開用バージョン

改訂改訂 3-86 Mon Nov 6 2017 Marek Suchanek非同期のアップデート。

改訂改訂 3-80 Thu Jul 27 2017 Milan Navratil7.4 GA 公開用ドキュメントバージョン

改訂改訂 3-77 Wed May 24 2017 Milan Navratil非同期のアップデート。

改訂改訂 3-68 Fri Oct 21 2016 Milan Navratil7.3 GA 公開用バージョン

改訂改訂 3-67 Fri Jun 17 2016 Milan Navratil非同期のアップデート。

改訂改訂 3-64 Wed Nov 11 2015 Jana Heves7.2 GA 公開用バージョン

改訂改訂 3-33 Wed Feb 18 2015 Jacquelynn East7.1 GA 向けバージョン

改訂改訂 3-26 Wed Jan 21 2015 Jacquelynn EastCeph の概要を追加

改訂改訂 3-22 Thu Dec 4 2014 Jacquelynn East7.1 Beta

改訂改訂 3-4 Thu Jul 17 2014 Jacquelynn Easttargetcli に関する新しい章を追加

改訂改訂 3-1 Tue Jun 3 2014 Jacquelynn East

付録付録B 改訂履歴改訂履歴

341

7.0 GA リリース向けバージョン


342

索引

シンボル

/boot/ ディレクトリーディレクトリー, /boot/ ディレクトリーディレクトリー

/dev/shm, df コマンドコマンド

/etc/fstab, ext3 ファイルシステムへの変換ファイルシステムへの変換, /etc/fstab を使用したを使用した NFS ファイルシステムのマウントファイルシステムのマウント,ファイルシステムのマウントファイルシステムのマウント

/etc/fstab ファイルファイル

ディスククォータを有効化ディスククォータを有効化, クォータの有効化クォータの有効化

/local/directory (クライアントの設定、マウントクライアントの設定、マウント)

NFS, NFS クライアントの設定クライアントの設定

/proc

/proc/devices, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/filesystems, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/mdstat, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/mounts, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/mounts/, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/partitions, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/devices

仮想ファイルシステム仮想ファイルシステム (/proc), /proc 仮想ファイルシステム仮想ファイルシステム

/proc/filesystems


/proc/mdstat


/proc/mounts


/proc/mounts/


/proc/partitions


/remote/export (クライアントの設定、マウントクライアントの設定、マウント)


1 ユーザーユーザー

volume_key, volume_key の個人ユーザーとしての使用の個人ユーザーとしての使用

はじめにはじめに, 概要概要

索引索引

343

アンマウントアンマウント, ファイルシステムのアンマウントファイルシステムのアンマウント

イニシエーターの実装イニシエーターの実装

オフロードとインターフェースのバインディングオフロードとインターフェースのバインディング

iSCSI, 利用可能な利用可能な iface 設定の表示設定の表示

インストーラーのサポートインストーラーのサポート

RAID, Anaconda インストーラーのインストーラーの RIAD サポートサポート

インストール時のストレージ設定インストール時のストレージ設定

channel command word (CCW), IBM System Z におけるにおける DASD デバイスとデバイスと zFCP デバイスデバイス

DASD デバイスとデバイスと zFCP デバイスデバイス - IBM System z, IBM System Z におけるにおける DASD デバイスとデバイスと zFCPデバイスデバイス

DIF/DIX を有効化にしているブロックデバイスを有効化にしているブロックデバイス, DIF/DIX を有効にしているブロックデバイスを有効にしているブロックデバイス

iSCSI の検出と設定の検出と設定, iSCSI の検出と設定の検出と設定

LUKS/dm-crypt、ブロックデバイスの暗号化、ブロックデバイスの暗号化, LUKS を使用してブロックデバイスを暗号化するを使用してブロックデバイスを暗号化する

別々のパーティションを用意する別々のパーティションを用意する (/home、、 /opt、、 /usr/local), /home、、 /opt、、 /usr/local にはには別々のパーティションを用意する別々のパーティションを用意する

古い古い BIOS RAID メタデータメタデータ, 古い古い BIOS RAID メタデータメタデータ

更新更新, ストレージをインストールする際の注意点ストレージをインストールする際の注意点

最新情報最新情報, ストレージをインストールする際の注意点ストレージをインストールする際の注意点

インタラクティブな操作インタラクティブな操作 (xfsrestore)

XFS, 復元復元

インデックスキーインデックスキー

FS-Cache, FS-Cache

エキスパートモードエキスパートモード (xfs_quota)

XFS, XFS クォータの管理クォータの管理

エクスポートしたファイルシステムエクスポートしたファイルシステム

ディスクレスのシステムディスクレスのシステム, ディスクレスクライアントのエクスポートしたファイルシステムの設定ディスクレスクライアントのエクスポートしたファイルシステムの設定

エラーメッセージエラーメッセージ

書き込みバリア書き込みバリア, 書き込みバリアの有効化と無効化書き込みバリアの有効化と無効化

オフラインの状態オフラインの状態

Linux SCSI レイヤーレイヤー, SCSI コマンドタイマーとデバイス状態の制御コマンドタイマーとデバイス状態の制御

オフロードとインターフェースバインディングオフロードとインターフェースバインディング

iSCSI, iSCSI オフロードとインターフェースバインディングの設定オフロードとインターフェースバインディングの設定

オプションオプション (クライアントの設定、マウントクライアントの設定、マウント)


オンラインストレージオンラインストレージ


344

トラブルシューティングトラブルシューティング, オンラインストレージ設定のトラブルシューティングオンラインストレージ設定のトラブルシューティング

ファイバーチャネルファイバーチャネル, ファイバーチャネルファイバーチャネル

概要概要, オンラインストレージ管理オンラインストレージ管理

sysfs, オンラインストレージ管理オンラインストレージ管理

オンライン論理ユニットオンライン論理ユニット

read/write ステータスの変更ステータスの変更, オンライン論理ユニットのオンライン論理ユニットの Read/Write ステータスの変更ステータスの変更

キャッシュの共有キャッシュの共有

FS-Cache, キャッシュの共有キャッシュの共有

キャッシュの設定キャッシュの設定

FS-Cache, キャッシュの設定キャッシュの設定

キャッシュの間引き制限キャッシュの間引き制限

FS-Cache, キャッシュの間引き制限キャッシュの間引き制限 (Cache Cull) の設定の設定

キャッシュを設定するキャッシュを設定する


キャッシュバックエンドキャッシュバックエンド

FS-Cache, FS-Cache

クォータの管理クォータの管理


コヒーレンスデータコヒーレンスデータ

FS-Cache, FS-Cache

コマンドコマンド

volume_key, volume_key コマンドコマンド

コマンドタイマーコマンドタイマー (SCSI)

Linux SCSI レイヤーレイヤー, コマンドタイマーコマンドタイマー

サイズ変更サイズ変更

ext4, ext4 ファイルシステムのサイズ変更ファイルシステムのサイズ変更

サイズ変更済みの論理ユニット、サイズ変更サイズ変更済みの論理ユニット、サイズ変更, オンライン論理ユニットのサイズ変更オンライン論理ユニットのサイズ変更

サイズ変更済みの論理ユニットのサイズを変更するサイズ変更済みの論理ユニットのサイズを変更する, オンライン論理ユニットのサイズ変更オンライン論理ユニットのサイズ変更

サイト設定ファイルの無効化と拡大サイト設定ファイルの無効化と拡大 (autofs)

NFS, autofs の設定の設定

サーバーサーバー (クライアントの設定、マウントクライアントの設定、マウント)


システムストレージマネージャーシステムストレージマネージャー

索引索引

345

SSM

バックエンドバックエンド, SSM バックエンドバックエンド

システム情報システム情報

ファイルシステムファイルシステム, ファイルシステム情報の収集ファイルシステム情報の収集

/dev/shm, df コマンドコマンド

シンプルモードシンプルモード (xfsrestore)

XFS, 復元復元

ストライピングストライピング

RAID, RAID レベルとリニアサポートレベルとリニアサポート

RAID の基本の基本, RAID (Redundant Array of Independent Disks)

ストライプ配列ストライプ配列

ext4, ext4 ファイルシステムの作成ファイルシステムの作成

ストレージの相互接続、スキャンストレージの相互接続、スキャン, ストレージの相互接続のスキャンストレージの相互接続のスキャン

ストレージの相互接続をスキャンするストレージの相互接続をスキャンする, ストレージの相互接続のスキャンストレージの相互接続のスキャン

ストレージをインストールする際の注意点ストレージをインストールする際の注意点

CCW (channel command word), IBM System Z におけるにおける DASD デバイスとデバイスと zFCP デバイスデバイス

DASD デバイスとデバイスと zFCP デバイスデバイス - IBM System z, IBM System Z におけるにおける DASD デバイスとデバイスと zFCPデバイスデバイス

DIF/DIX を有効にしているブロックデバイスを有効にしているブロックデバイス, DIF/DIX を有効にしているブロックデバイスを有効にしているブロックデバイス

iSCSI の検出と設定の検出と設定, iSCSI の検出と設定の検出と設定

LUKS/dm-crypt、ブロックデバイスの暗号化、ブロックデバイスの暗号化, LUKS を使用してブロックデバイスを暗号化するを使用してブロックデバイスを暗号化する

別々のパーティションを用意する別々のパーティションを用意する (/home、、 /opt、、 /usr/local), /home、、 /opt、、 /usr/local にはには別々のパーティションを用意する別々のパーティションを用意する

古い古い BIOS RAID メタデータメタデータ, 古い古い BIOS RAID メタデータメタデータ

更新更新, ストレージをインストールする際の注意点ストレージをインストールする際の注意点

最新情報最新情報, ストレージをインストールする際の注意点ストレージをインストールする際の注意点

ストレージアクセスのパラメーターストレージアクセスのパラメーター

I/O の調整とサイズの調整とサイズ, ストレージアクセス用のパラメーターストレージアクセス用のパラメーター

ストレージアクセス用のパラメーターストレージアクセス用のパラメーター

I/O の調整とサイズの調整とサイズ, ストレージアクセス用のパラメーターストレージアクセス用のパラメーター

ストレージデバイスにパスを追加ストレージデバイスにパスを追加, ストレージデバイスまたはパスの追加ストレージデバイスまたはパスの追加

ストレージデバイスへのパス、削除ストレージデバイスへのパス、削除, ストレージデバイスへのパスの削除ストレージデバイスへのパスの削除

ストレージデバイスへのパス、追加ストレージデバイスへのパス、追加, ストレージデバイスまたはパスの追加ストレージデバイスまたはパスの追加

ストレージデバイスへのパスを削除するストレージデバイスへのパスを削除する, ストレージデバイスへのパスの削除ストレージデバイスへのパスの削除

スループットクラススループットクラス

ソリッドステートディスクソリッドステートディスク, ソリッドステートディスクの導入ガイドラインソリッドステートディスクの導入ガイドライン


346

スレーブマウントスレーブマウント, マウントポイントの共有マウントポイントの共有

ソフトウェアソフトウェア iSCSI

iSCSI, ソフトウェアソフトウェア iSCSI 用用 iface の設定の設定

オフロードおよびインターフェースのバインディングオフロードおよびインターフェースのバインディング


ソフトウェアソフトウェア iSCSI 用用 iface



ソフトウェアソフトウェア RAID (参照参照 RAID)

ソリッドステートディスクソリッドステートディスク

SSD, ソリッドステートディスクの導入ガイドラインソリッドステートディスクの導入ガイドライン

TRIM コマンドコマンド, ソリッドステートディスクの導入ガイドラインソリッドステートディスクの導入ガイドライン

スループットクラススループットクラス, ソリッドステートディスクの導入ガイドラインソリッドステートディスクの導入ガイドライン

デプロイメントデプロイメント, ソリッドステートディスクの導入ガイドラインソリッドステートディスクの導入ガイドライン

導入ガイドライン導入ガイドライン, ソリッドステートディスクの導入ガイドラインソリッドステートディスクの導入ガイドライン

ターゲットターゲット

iSCSI, iSCSI ターゲットへのログインターゲットへのログイン

ダンプのレベルダンプのレベル

XFS, バックアップバックアップ

ダーティーログダーティーログ (XFS ファイルシステムの修復ファイルシステムの修復)

XFS, XFS ファイルシステムの修復ファイルシステムの修復

ダーティーログを持つダーティーログを持つ XFS ファイルシステムの修復ファイルシステムの修復


ツールツール (パーティション設定および他のファイルシステムの機能用パーティション設定および他のファイルシステムの機能用)

I/O の調整とサイズの調整とサイズ, パーティションとファイルシステムのツールパーティションとファイルシステムのツール

ディスククォータディスククォータ, ディスク割り当てディスク割り当て

その他のリソースその他のリソース, ディスククオータのリファレンスディスククオータのリファレンス

グループごとの割り当てグループごとの割り当て, グループごとのクォータ割り当てグループごとのクォータ割り当て

ソフトリミットソフトリミット, ユーザーごとのクォータ割り当てユーザーごとのクォータ割り当て

ハードリミットハードリミット, ユーザーごとのクォータ割り当てユーザーごとのクォータ割り当て

ファイルシステムごとの割り当てファイルシステムごとの割り当て, ソフトリミットの猶予期間の設定ソフトリミットの猶予期間の設定

ユーザーごとの割り当てユーザーごとの割り当て, ユーザーごとのクォータ割り当てユーザーごとのクォータ割り当て

有効化有効化, ディスククォータの設定ディスククォータの設定, 有効化と無効化有効化と無効化

/etc/fstab の修正の修正, クォータの有効化クォータの有効化

quotacheck の実行の実行, クォータデータベースファイルの作成クォータデータベースファイルの作成

クォータファイルの作成クォータファイルの作成, クォータデータベースファイルの作成クォータデータベースファイルの作成

索引索引

347

無効化無効化, 有効化と無効化有効化と無効化

猶予期間猶予期間, ユーザーごとのクォータ割り当てユーザーごとのクォータ割り当て

管理管理, ディスククォータの管理ディスククォータの管理

レポーティングレポーティング, ディスククォータに関するレポートディスククォータに関するレポート

ディスククオータディスククオータ

の管理の管理

quotacheck コマンドを使用したチェックコマンドを使用したチェック, クォータの精度維持クォータの精度維持

ディスクストレージディスクストレージ (参照参照ディスククォータディスククォータ)

parted (参照参照 parted)

ディスクレスのシステムディスクレスのシステム

DHCP、設定、設定, ディスクレスクライアントのディスクレスクライアントの DHCP の設定の設定

tftp サービス、設定サービス、設定, ディスクレスクライアントのディスクレスクライアントの tftp サービスの設定サービスの設定

エクスポートしたファイルシステムエクスポートしたファイルシステム, ディスクレスクライアントのエクスポートしたファイルシステディスクレスクライアントのエクスポートしたファイルシステムの設定ムの設定

ネットワーク起動サービスネットワーク起動サービス, リモートディスクレスシステムの設定リモートディスクレスシステムの設定

リモートディスクレスシステムリモートディスクレスシステム, リモートディスクレスシステムの設定リモートディスクレスシステムの設定

必要なパッケージ必要なパッケージ, リモートディスクレスシステムの設定リモートディスクレスシステムの設定

ディスクレスクライアントのディスクレスクライアントの DHCP を設定するを設定する

ディスクレスのシステムディスクレスのシステム, ディスクレスクライアントのディスクレスクライアントの DHCP の設定の設定

ディスクレスクライアントのディスクレスクライアントの tftp サービスを設定するサービスを設定する

ディスクレスのシステムディスクレスのシステム, ディスクレスクライアントのディスクレスクライアントの tftp サービスの設定サービスの設定

ディレクトリーディレクトリー

/boot/, /boot/ ディレクトリーディレクトリー

/dev/, /dev/ ディレクトリーディレクトリー

/etc/, /etc/ ディレクトリーディレクトリー

/mnt/, /mnt/ ディレクトリーディレクトリー

/opt/, /opt/ ディレクトリーディレクトリー

/proc/, /proc/ ディレクトリーディレクトリー

/srv/, /srv/ ディレクトリーディレクトリー

/sys/, /sys/ ディレクトリーディレクトリー

/usr/, /usr/ ディレクトリーディレクトリー

/var/, /var/ ディレクトリーディレクトリー

デバイス、削除デバイス、削除, ストレージデバイスの削除ストレージデバイスの削除

デバイスがブロックされているか確認するデバイスがブロックされているか確認する

ファイバーチャネルファイバーチャネル

リンク切れの動作を修正するリンク切れの動作を修正する, ファイバーチャネルファイバーチャネル


348

デバイスの削除デバイスの削除, ストレージデバイスの削除ストレージデバイスの削除

デバイスの状態デバイスの状態

Linux SCSI レイヤーレイヤー, デバイスの状態デバイスの状態

デプロイメントデプロイメント


トラブルシューティングトラブルシューティング

オンラインストレージオンラインストレージ, オンラインストレージ設定のトラブルシューティングオンラインストレージ設定のトラブルシューティング

トランスポートトランスポート

ファイバーチャネルファイバーチャネル API, ファイバーチャネルファイバーチャネル API

ドライバードライバー (ネイティブネイティブ)、ファイバーチャネル、ファイバーチャネル, ネイティブファイバーチャネルのドライバーと機能ネイティブファイバーチャネルのドライバーと機能

ネイティブファイバーチャネルドライバーネイティブファイバーチャネルドライバー, ネイティブファイバーチャネルのドライバーと機能ネイティブファイバーチャネルのドライバーと機能

ネットワークファイルシステムネットワークファイルシステム (参照参照 NFS)

ネットワーク起動サービスネットワーク起動サービス

ディスクレスのシステムディスクレスのシステム, リモートディスクレスシステムの設定リモートディスクレスシステムの設定

ハイエンドのアレイハイエンドのアレイ

書き込みバリア書き込みバリア, ハイエンドのアレイハイエンドのアレイ

ハードウェアハードウェア RAID (参照参照 RAID)

ハードウェアハードウェア RAID のコントローラードライバーのコントローラードライバー

RAID, Linux ハードウェアハードウェア RAID のコントローラードライバーのコントローラードライバー

バインド不可能なマウントバインド不可能なマウント, マウントポイントの共有マウントポイントの共有

バックアップと復元バックアップと復元

XFS, XFS ファイルシステムのバックアップと復元ファイルシステムのバックアップと復元

バックアップの復元バックアップの復元

XFS, 復元復元

バッテリー駆動の書き込みキャッシュバッテリー駆動の書き込みキャッシュ

書き込みバリア書き込みバリア, バッテリー駆動の書き込みキャッシュバッテリー駆動の書き込みキャッシュ

パリティーパリティー


パーティションパーティション

サイズ変更サイズ変更, fdisk を使用したパーティションのサイズ変更を使用したパーティションのサイズ変更

フォーマットフォーマット

mkfs , パーティションのフォーマットとラベル付けパーティションのフォーマットとラベル付け

一覧の表示一覧の表示, パーティションテーブルの表示パーティションテーブルの表示

作成作成, パーティションの作成パーティションの作成

削除削除, パーティションの削除パーティションの削除

索引索引

349

パーティションテーブルパーティションテーブル

表示表示, パーティションテーブルの表示パーティションテーブルの表示


オンラインストレージオンラインストレージ, ファイバーチャネルファイバーチャネル


ファイバーチャネルオーバーイーサネットファイバーチャネルオーバーイーサネット

FCoE, ファイバーチャネルオーバーイーサネットインターフェースの設定ファイバーチャネルオーバーイーサネットインターフェースの設定

ファイバーチャネルドライバーファイバーチャネルドライバー (ネイティブネイティブ), ネイティブファイバーチャネルのドライバーと機能ネイティブファイバーチャネルのドライバーと機能

ファイルシステムファイルシステム, ファイルシステム情報の収集ファイルシステム情報の収集

Btrfs, Btrfs (テクノロジープレビューテクノロジープレビュー)

ext2 (参照参照 ext2)

ext3 (参照参照 ext3)

FHS 標準標準, FHS の組織の組織

構造構造, ファイルシステムの構造およびメンテナンスファイルシステムの構造およびメンテナンス

組織組織, FHS の組織の組織

階層階層, ファイルシステム階層標準ファイルシステム階層標準 (FHS) の概要の概要

ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

ext4, ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

ファイルシステムのサイズの拡大ファイルシステムのサイズの拡大

XFS, XFS ファイルシステムのサイズの拡大ファイルシステムのサイズの拡大

ファイルシステムのタイプファイルシステムのタイプ

ext4, ex4 ファイルシステムファイルシステム

GFS2, Global File System 2

ファイルシステムの修復ファイルシステムの修復


ファイルシステムタイプファイルシステムタイプ

XFS, XFS ファイルシステムファイルシステム

ブロックされたデバイス、確認ブロックされたデバイス、確認



ブロックデバイスブロックデバイス ioctls (ユーザー領域のアクセスユーザー領域のアクセス)

I/O の調整とサイズの調整とサイズ, ブロックデバイスブロックデバイス ioctls

プライベートマウントプライベートマウント, マウントポイントの共有マウントポイントの共有

プロジェクト制限プロジェクト制限 (の設定の設定)

XFS, プロジェクト制限の設定プロジェクト制限の設定


350

ポートの状態ポートの状態 (リモートリモート)、判別、判別



マウントマウント

XFS, XFS ファイルシステムのマウントファイルシステムのマウント

マウントマウント (クライアントの設定クライアントの設定)


マウントするマウントする, ファイルシステムのマウントファイルシステムのマウント

ext4, ext4 ファイルシステムのマウントファイルシステムのマウント

マウントポイントを移動するマウントポイントを移動する, マウントポイントの移動マウントポイントの移動

ミラーリングミラーリング


ユーザースペースユーザースペース API ファイルファイル


ユーザー領域のアクセスユーザー領域のアクセス

I/O の調整とサイズの調整とサイズ, ユーザー領域のアクセスユーザー領域のアクセス

リニアリニア RAID


リモートディスクレスシステムリモートディスクレスシステム


リモートポートリモートポート


リモートポートの状態、判別リモートポートの状態、判別



リモートポートの状態を判別するリモートポートの状態を判別する



リンク切れの動作を修正するリンク切れの動作を修正する, リンク切れ動作の修正リンク切れ動作の修正

ファイバーチャネルファイバーチャネル, ファイバーチャネルファイバーチャネル

レベルレベル


索引索引

351

ログインするログインする

iSCSI ターゲットターゲット, iSCSI ターゲットへのログインターゲットへのログイン

一時停止一時停止

XFS, XFS ファイルシステムの一時停止ファイルシステムの一時停止

主な特長主な特長



仮想ファイルシステム仮想ファイルシステム (/proc)

/proc/devices, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/filesystems, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/mdstat, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/mounts, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/mounts/, /proc 仮想ファイルシステム仮想ファイルシステム

/proc/partitions, /proc 仮想ファイルシステム仮想ファイルシステム

仮想マシン用のストレージ仮想マシン用のストレージ, 仮想マシン用のストレージ仮想マシン用のストレージ

作成作成


XFS, XFS ファイルシステムの作成ファイルシステムの作成

入出力パラメータのスタック入出力パラメータのスタック

I/O の調整とサイズの調整とサイズ, 入出力パラメーターのスタック入出力パラメーターのスタック

共有サブツリー共有サブツリー, マウントポイントの共有マウントポイントの共有




共有マウント共有マウント, マウントポイントの共有マウントポイントの共有


別々のパーティションを用意する別々のパーティションを用意する (/home、、 /opt、、 /usr/local)

ストレージをインストールする際の注意点ストレージをインストールする際の注意点, /home、、 /opt、、 /usr/local には別々のパーティションには別々のパーティションを用意するを用意する

利用可能な利用可能な iface の設定を表示するの設定を表示する







352

古い古い BIOS RAID メタデータメタデータ

ストレージをインストールする際の注意点ストレージをインストールする際の注意点, 古い古い BIOS RAID メタデータメタデータ

実行中のセッション、その情報の取り込み実行中のセッション、その情報の取り込み

iSCSI API, iSCSI API

実行中の状態実行中の状態


導入ガイドライン導入ガイドライン


必要なパッケージ必要なパッケージ



追加と削除追加と削除

LUN (論理ユニット番号論理ユニット番号), rescan-scsi-bus.sh による論理ユニットの追加と削除による論理ユニットの追加と削除

性能に関する保証性能に関する保証

FS-Cache, 性能に関する保証性能に関する保証

既知の問題既知の問題


LUN (論理ユニット番号論理ユニット番号), rescan-scsi-bus.sh に関する既知の問題に関する既知の問題

更新更新

ストレージをインストールする際の注意点ストレージをインストールする際の注意点, ストレージをインストールする際の注意点ストレージをインストールする際の注意点

書き込みのバリア書き込みのバリア

XFS, 書き込みバリア書き込みバリア

書き込みキャッシュ、無効にする書き込みキャッシュ、無効にする

書き込みバリア書き込みバリア, 書き込みキャッシュの無効化書き込みキャッシュの無効化

書き込みキャッシュを無効にする書き込みキャッシュを無効にする

書き込みバリア書き込みバリア, 書き込みキャッシュの無効化書き込みキャッシュの無効化

書き込みバリア書き込みバリア


NFS, NFS

エラーメッセージエラーメッセージ, 書き込みバリアの有効化と無効化書き込みバリアの有効化と無効化

ハイエンドのアレイハイエンドのアレイ, ハイエンドのアレイハイエンドのアレイ

バッテリー駆動の書き込みキャッシュバッテリー駆動の書き込みキャッシュ, バッテリー駆動の書き込みキャッシュバッテリー駆動の書き込みキャッシュ

定義定義, 書き込みバリア書き込みバリア

書き込みキャッシュを無効にする書き込みキャッシュを無効にする, 書き込みキャッシュの無効化書き込みキャッシュの無効化

索引索引

353

書き込みバリの動作書き込みバリの動作, 書き込みバリアの動作書き込みバリアの動作

書き込みバリアの重要性書き込みバリアの重要性, 書き込みバリアの重要性書き込みバリアの重要性

有効または無効にする有効または無効にする, 書き込みバリアの有効化と無効化書き込みバリアの有効化と無効化

書き込みバリアの動作書き込みバリアの動作

書き込みバリア書き込みバリア, 書き込みバリアの動作書き込みバリアの動作

書き込みバリアの重要性書き込みバリアの重要性

書き込みバリア書き込みバリア, 書き込みバリアの重要性書き込みバリアの重要性

最大サイズ最大サイズ


最大サイズ最大サイズ, GFS2 ファイルシステムファイルシステム, Global File System 2

最新情報最新情報

ストレージをインストールする際の注意点ストレージをインストールする際の注意点, ストレージをインストールする際の注意点ストレージをインストールする際の注意点

有効または無効にする有効または無効にする

書き込みバリア書き込みバリア, 書き込みバリアの有効化と無効化書き込みバリアの有効化と無効化

検出検出

iSCSI, iSCSI 検出の設定検出の設定

概要概要, 概要概要

オンラインストレージオンラインストレージ, オンラインストレージ管理オンラインストレージ管理

永続的な命名永続的な命名, 永続的な命名永続的な命名

特定セッションのタイムアウト、設定特定セッションのタイムアウト、設定

iSCSI 設定設定, 特定セッションのタイムアウトの設定特定セッションのタイムアウトの設定

相互接続相互接続 (スキャンするスキャンする)

iSCSI, iSCSI 相互接続のスキャン相互接続のスキャン

相互接続をスキャンする相互接続をスキャンする

iSCSI, iSCSI 相互接続のスキャン相互接続のスキャン

累積モード累積モード (xfsrestore)

XFS, 復元復元

統計情報統計情報 (追跡追跡)

FS-Cache, 統計情報統計情報

統計情報を追跡する統計情報を追跡する

FS-Cache, 統計情報統計情報

自動マウント機能のマップを格納、自動マウント機能のマップを格納、格納に格納に LDAP を使用を使用 (autofs)

NFS, サイトの設定ファイルの無効化サイトの設定ファイルの無効化/拡大拡大


354

記録の種類記録の種類

検出検出


設定設定

検出検出




階層、ファイルシステム階層、ファイルシステム, ファイルシステム階層標準ファイルシステム階層標準 (FHS) の概要の概要

高度な高度な RAID デバイス作成法デバイス作成法

RAID, 高度な高度な RAID デバイスの作成デバイスの作成

A

Anaconda サポートサポート

RAID, Anaconda インストーラーのインストーラーの RIAD サポートサポート

API、、iSCSI, iSCSI API

API、ファイバーチャネル、ファイバーチャネル, ファイバーチャネルファイバーチャネル API

ATA 標準標準

I/O の調整とサイズの調整とサイズ, ATA

autofs , autofs, autofs の設定の設定

(参照参照 NFS)

autofs バージョンバージョン 5

NFS, autofs バージョンバージョン 5 の改善点の改善点 (バージョンバージョン 4 との比較との比較)

B

bcull (キャッシュ間引き制限の設定キャッシュ間引き制限の設定)


brun (キャッシュ間引き制限の設定キャッシュ間引き制限の設定)


bstop (キャッシュ間引き制限の設定キャッシュ間引き制限の設定)


Btrfs

ファイルシステムファイルシステム, Btrfs (テクノロジープレビューテクノロジープレビュー)

索引索引

355

C

cachefiles

FS-Cache, FS-Cache

cachefilesd


CCW、、 channel command word

ストレージをインストールする際の注意点ストレージをインストールする際の注意点, IBM System Z におけるにおける DASD デバイスとデバイスと zFCP デバイデバイスス

channel command word (CCW)


D

DASD デバイスとデバイスと zFCP デバイスデバイス - IBM System z


debugfs (ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー)


dev ディレクトリーディレクトリー, /dev/ ディレクトリーディレクトリー

device-mapper マルチパス機能マルチパス機能, DM Multipath

dev_loss_tmo



dev_loss_tmo を変更するを変更する



dev_loss_tmo、変更、変更



df, df コマンドコマンド

DHCP、設定、設定

ディスクレスのシステムディスクレスのシステム, ディスクレスクライアントのディスクレスクライアントの DHCP の設定の設定

DIF/DIX を有効にしているブロックデバイスを有効にしているブロックデバイス

ストレージをインストールする際の注意点ストレージをインストールする際の注意点, DIF/DIX を有効にしているブロックデバイスを有効にしているブロックデバイス


356

direct map support (autofs version 5)


dm-multipath

iSCSI 設定設定, dm-multipath を実装しているを実装している iSCSI の設定の設定

dmraid

RAID, dmraid

dmraid (RAID セットを設定するセットを設定する)

RAID, dmraid

du, du コマンドコマンド

E

e2fsck, Ext2 ファイルシステムに戻すファイルシステムに戻す

e2image (ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー)


e2label


e2label (ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー)


enhanced LDAP support (autofs version 5)


etc ディレクトリーディレクトリー, /etc/ ディレクトリーディレクトリー

ext2

ext3 から戻すから戻す, Ext2 ファイルシステムに戻すファイルシステムに戻す

ext3

ext2 から変換から変換, ext3 ファイルシステムへの変換ファイルシステムへの変換

作成作成, Ext3 ファイルシステムの作成ファイルシステムの作成

特徴特徴, ext3 ファイルシステムファイルシステム

ext4

debugfs (ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー), ext4 ファイルシステムのその他のファイルシステムのその他のユーティリティーユーティリティー

e2image (ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー), ext4 ファイルシステムのその他のファイルシステムのその他のユーティリティーユーティリティー

e2label, ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

e2label (ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー), ext4 ファイルシステムのその他のファイルシステムのその他のユーティリティーユーティリティー

fsync(), ex4 ファイルシステムファイルシステム

mkfs.ext4, ext4 ファイルシステムの作成ファイルシステムの作成

索引索引

357

nobarrier マウントオプションマウントオプション, ext4 ファイルシステムのマウントファイルシステムのマウント

quota (ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー), ext4 ファイルシステムのその他のファイルシステムのその他のユーティリティーユーティリティー

resize2fs (ext4 のサイズ変更のサイズ変更), ext4 ファイルシステムのサイズ変更ファイルシステムのサイズ変更

stride (ストライプ配列を指定ストライプ配列を指定), ext4 ファイルシステムの作成ファイルシステムの作成

stripe-width (ストライプ配列を指定ストライプ配列を指定), ext4 ファイルシステムの作成ファイルシステムの作成

tune2fs (マウントするマウントする), ext4 ファイルシステムのマウントファイルシステムのマウント

サイズ変更サイズ変更, ext4 ファイルシステムのサイズ変更ファイルシステムのサイズ変更

ストライプ配列ストライプ配列, ext4 ファイルシステムの作成ファイルシステムの作成

ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー, ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

ファイルシステムのタイプファイルシステムのタイプ, ex4 ファイルシステムファイルシステム

マウントするマウントする, ext4 ファイルシステムのマウントファイルシステムのマウント

主な特長主な特長, ex4 ファイルシステムファイルシステム

作成作成, ext4 ファイルシステムの作成ファイルシステムの作成

割り当て機能割り当て機能, ex4 ファイルシステムファイルシステム

書き込みバリア書き込みバリア, ext4 ファイルシステムのマウントファイルシステムのマウント

F

FCoE

FCoE を使用するためにイーサネットインターフェースを設定を使用するためにイーサネットインターフェースを設定, ファイバーチャネルオーバーイーサファイバーチャネルオーバーイーサネットインターフェースの設定ネットインターフェースの設定

ファイバーチャネルオーバーイーサネットファイバーチャネルオーバーイーサネット, ファイバーチャネルオーバーイーサネットインターファイバーチャネルオーバーイーサネットインターフェースの設定フェースの設定

必要なパッケージ必要なパッケージ, ファイバーチャネルオーバーイーサネットインターフェースの設定ファイバーチャネルオーバーイーサネットインターフェースの設定

FCoE を使用するためにイーサネットインターフェースを設定を使用するためにイーサネットインターフェースを設定


FHS, ファイルシステム階層標準ファイルシステム階層標準 (FHS) の概要の概要, FHS の組織の組織

(参照参照ファイルシステムファイルシステム)

findmnt (コマンドコマンド)

マウントのリストマウントのリスト, 現在マウントされているファイルシステムの一覧表示現在マウントされているファイルシステムの一覧表示

FS-Cache

bcull (キャッシュ間引き制限の設定キャッシュ間引き制限の設定), キャッシュの間引き制限キャッシュの間引き制限 (Cache Cull) の設定の設定

brun (キャッシュ間引き制限の設定キャッシュ間引き制限の設定), キャッシュの間引き制限キャッシュの間引き制限 (Cache Cull) の設定の設定

bstop (キャッシュ間引き制限の設定キャッシュ間引き制限の設定), キャッシュの間引き制限キャッシュの間引き制限 (Cache Cull) の設定の設定

cachefiles, FS-Cache

cachefilesd, キャッシュの設定キャッシュの設定

NFS (で使用するで使用する), NFS でのキャッシュの使用でのキャッシュの使用

NFS (キャッシュの制限キャッシュの制限), NFS でのキャッシュの制限でのキャッシュの制限

tune2fs (キャッシュを設定するキャッシュを設定する), キャッシュの設定キャッシュの設定

インデックスキーインデックスキー, FS-Cache


358

キャッシュの共有キャッシュの共有, キャッシュの共有キャッシュの共有

キャッシュの間引き制限キャッシュの間引き制限, キャッシュの間引き制限キャッシュの間引き制限 (Cache Cull) の設定の設定

キャッシュを設定するキャッシュを設定する, キャッシュの設定キャッシュの設定

キャッシュバックエンドキャッシュバックエンド, FS-Cache

コヒーレンスデータコヒーレンスデータ, FS-Cache

性能に関する保証性能に関する保証, 性能に関する保証性能に関する保証

統計情報統計情報 (追跡追跡), 統計情報統計情報

fsync()



G

GFS2

gfs2.ko, Global File System 2

ファイルシステムのタイプファイルシステムのタイプ, Global File System 2

最大サイズ最大サイズ, Global File System 2

GFS2 ファイルシステムの最大サイズファイルシステムの最大サイズ, Global File System 2

gfs2.ko


Global File System 2

gfs2.ko, Global File System 2

ファイルシステムのタイプファイルシステムのタイプ, Global File System 2

最大サイズ最大サイズ, Global File System 2

gquota/gqnoenforce


H

host

ファイバーチャンネルファイバーチャンネル API, ファイバーチャネルファイバーチャネル API

I

I/O の調整とサイズの調整とサイズ, ストレージのストレージの I/O 調整とサイズ調整とサイズ

ATA 標準標準, ATA

Linux I/O スタックスタック, ストレージのストレージの I/O 調整とサイズ調整とサイズ

logical_block_size, ユーザー領域のアクセスユーザー領域のアクセス

LVM, 論理ボリュームマネージャー論理ボリュームマネージャー

READ CAPACITY(16), SCSI

SCSI 標準標準, SCSI

索引索引

359

sysfs インターフェースインターフェース (ユーザー領域のアクセスユーザー領域のアクセス), sysfs インターフェースインターフェース

ストレージアクセスのパラメーターストレージアクセスのパラメーター, ストレージアクセス用のパラメーターストレージアクセス用のパラメーター

ツールツール (パーティション設定および他のファイルシステムの機能用パーティション設定および他のファイルシステムの機能用), パーティションとファイルシスパーティションとファイルシステムのツールテムのツール

ブロックデバイスブロックデバイス ioctls (ユーザー領域のアクセスユーザー領域のアクセス), ブロックデバイスブロックデバイス ioctls

ユーザー領域のアクセスユーザー領域のアクセス, ユーザー領域のアクセスユーザー領域のアクセス

入出力パラメーターのスタック入出力パラメーターのスタック, 入出力パラメーターのスタック入出力パラメーターのスタック

iface (iSCSI オフロード用の設定オフロード用の設定)

オフロードとインターフェースバインディングオフロードとインターフェースバインディング

iSCSI, iSCSI Offload 用用 iface の設定の設定

iface のポータルに対する結合のポータルに対する結合/結合解除結合解除


iSCSI, iface のポータルに対する結合のポータルに対する結合/結合解除結合解除

iface の設定の設定



iface の設定、表示の設定、表示



iface を結合を結合/結合を解除する結合を解除する


iSCSI, iface のポータルに対する結合のポータルに対する結合/結合解除結合解除

iSCSI


ソフトウェアソフトウェア iSCSI, ソフトウェアソフトウェア iSCSI 用用 iface の設定の設定

ソフトウェアソフトウェア iSCSI 用用 iface, ソフトウェアソフトウェア iSCSI 用用 iface の設定の設定


iface のポータルに対する結合のポータルに対する結合/結合解除結合解除, iface のポータルに対する結合のポータルに対する結合/結合解除結合解除

iface の設定の設定, 利用可能な利用可能な iface 設定の表示設定の表示

iface の設定、表示の設定、表示, 利用可能な利用可能な iface 設定の表示設定の表示

イニシエーターの実装イニシエーターの実装, 利用可能な利用可能な iface 設定の表示設定の表示

利用可能な利用可能な iface の設定を表示するの設定を表示する, 利用可能な利用可能な iface 設定の表示設定の表示

オフロードとインターフェースバインディングオフロードとインターフェースバインディング, iSCSI オフロードとインターフェースバインディンオフロードとインターフェースバインディングの設定グの設定


360

iface (iSCSI オフロード用の設定オフロード用の設定), iSCSI Offload 用用 iface の設定の設定

ソフトウェアソフトウェア iSCSI, ソフトウェアソフトウェア iSCSI 用用 iface の設定の設定

ターゲットターゲット, iSCSI ターゲットへのログインターゲットへのログイン

ログインするログインする, iSCSI ターゲットへのログインターゲットへのログイン

検出検出, iSCSI 検出の設定検出の設定

記録の種類記録の種類, iSCSI 検出の設定検出の設定

設定設定, iSCSI 検出の設定検出の設定

相互接続をスキャンする相互接続をスキャンする, iSCSI 相互接続のスキャン相互接続のスキャン

iSCSI API, iSCSI API

iSCSI のルートのルート

iSCSI 設定設定, iSCSI のルートのルート

iSCSI の検出と設定の検出と設定

ストレージをインストールする際の注意点ストレージをインストールする際の注意点, iSCSI の検出と設定の検出と設定

iSCSI の論理ユニット、サイズ変更の論理ユニット、サイズ変更, iSCSI 論理ユニットのサイズ変更論理ユニットのサイズ変更

iSCSI の論理ユニットのサイズを変更するの論理ユニットのサイズを変更する, iSCSI 論理ユニットのサイズ変更論理ユニットのサイズ変更

L

lazy mount/unmount support (autofs version 5)


limit (xfs_quota エキスパートモードエキスパートモード)


Linux I/O スタックスタック

I/O の調整とサイズの調整とサイズ, ストレージのストレージの I/O 調整とサイズ調整とサイズ

logical_block_size

I/O の調整とサイズの調整とサイズ, ユーザー領域のアクセスユーザー領域のアクセス

LUKS/dm-crypt、ブロックデバイスの暗号化、ブロックデバイスの暗号化

ストレージをインストールする際の注意点ストレージをインストールする際の注意点, LUKS を使用してブロックデバイスを暗号化するを使用してブロックデバイスを暗号化する

LUN (論理ユニット番号論理ユニット番号)

追加と削除追加と削除, rescan-scsi-bus.sh による論理ユニットの追加と削除による論理ユニットの追加と削除

rescan-scsi-bus.sh, rescan-scsi-bus.sh による論理ユニットの追加と削除による論理ユニットの追加と削除

必要なパッケージ必要なパッケージ, rescan-scsi-bus.sh による論理ユニットの追加と削除による論理ユニットの追加と削除

既知の問題既知の問題, rescan-scsi-bus.sh に関する既知の問題に関する既知の問題

LVM

I/O の調整とサイズの調整とサイズ, 論理ボリュームマネージャー論理ボリュームマネージャー

索引索引

361

M

mdadm (RAID セットを設定するセットを設定する)

RAID, mdadm

mdraid

RAID, mdraid

mkfs , パーティションのフォーマットとラベル付けパーティションのフォーマットとラベル付け

mkfs.ext4


mkfs.xfs


mnt ディレクトリーディレクトリー, /mnt/ ディレクトリーディレクトリー

mount (コマンドコマンド), mount コマンドの使い方コマンドの使い方

オプションオプション, マウントオプションの指定マウントオプションの指定

ファイルシステムをマウントするファイルシステムをマウントする, ファイルシステムのマウントファイルシステムのマウント

マウントポイントの表示マウントポイントの表示, 現在マウントされているファイルシステムの一覧表示現在マウントされているファイルシステムの一覧表示

マウントポイントを移動するマウントポイントを移動する, マウントポイントの移動マウントポイントの移動

共有サブツリー共有サブツリー, マウントポイントの共有マウントポイントの共有





multiple master map entries per autofs mount point (autofs version 5)


N

NFS

/etc/fstab , /etc/fstab を使用したを使用した NFS ファイルシステムのマウントファイルシステムのマウント

/local/directory (クライアントの設定、マウントクライアントの設定、マウント), NFS クライアントの設定クライアントの設定

/remote/export (クライアントの設定、クライアントの設定、マウントマウント), NFS クライアントの設定クライアントの設定

autofs

configuration, autofs の設定の設定

LDAP, LDAP を使用した自動マウント機能のマップの格納を使用した自動マウント機能のマップの格納

拡大拡大, サイトの設定ファイルの無効化サイトの設定ファイルの無効化/拡大拡大

autofs バージョンバージョン 5, autofs バージョンバージョン 5 の改善点の改善点 (バージョンバージョン 4 との比較との比較)

condrestart, NFS サーバーの起動と停止サーバーの起動と停止

direct map support (autofs version 5), autofs バージョンバージョン 5 の改善点の改善点 (バージョンバージョン 4 との比較との比較)

enhanced LDAP support (autofs version 5), autofs バージョンバージョン 5 の改善点の改善点 (バージョンバージョン 4 との比較との比較)


362

FS-Cache, NFS でのキャッシュの使用でのキャッシュの使用

lazy mount/unmount support (autofs version 5), autofs バージョンバージョン 5 の改善点の改善点 (バージョンバージョン 4 とのとの比較比較)

multiple master map entries per autofs mount point (autofs version 5), autofs バージョンバージョン 5 の改の改善点善点 (バージョンバージョン 4 との比較との比較)

NFS およびおよび rpcbind に関するトラブルシューティングに関するトラブルシューティング, NFS およびおよび rpcbind に関するトラブルシューに関するトラブルシューティングティング

proper nsswitch configuration (autofs version 5), use of, autofs バージョンバージョン 5 の改善点の改善点 (バージョバージョンン 4 との比較との比較)

RDMA, RDMA でで NFS の有効化の有効化 (NFSoRDMA)

rfc2307bis (autofs), LDAP を使用した自動マウント機能のマップの格納を使用した自動マウント機能のマップの格納

rpcbind , NFS とと rpcbind

TCP, NFS の概要の概要

UDP, NFS の概要の概要

その他のリソースその他のリソース, NFS リファレンスリファレンス

インストールされているドキュメントインストールされているドキュメント, インストールされているドキュメントインストールされているドキュメント

役に立つ　役に立つ　Web サイトサイト, 役立つ役立つ Web サイトサイト

関連書籍関連書籍, 関連書籍関連書籍

はじめにはじめに, Network File System (NFS)

オプションオプション (クライアントの設定、マウントクライアントの設定、マウント), NFS クライアントの設定クライアントの設定

クライアントクライアント

autofs , autofs

マウントオプションマウントオプション, 一般的な一般的な NFS マウントオプションマウントオプション

設定設定, NFS クライアントの設定クライアントの設定

サイトの設定ファイルを無効化する／拡大するサイトの設定ファイルを無効化する／拡大する (autofs), autofs の設定の設定

サーバーサーバー (クライアントの設定、マウントクライアントの設定、マウント), NFS クライアントの設定クライアントの設定

サーバーの設定サーバーの設定, NFS サーバーの設定サーバーの設定

/etc/exports , /etc/exports 設定ファイル設定ファイル

exportfs コマンドコマンド, exportfs コマンドコマンド

NFSv4でで exportfs コマンドコマンド, NFSv4 でで exportfs の使用の使用

セキュリティーセキュリティー, NFS のセキュア化のセキュア化

NFSv3 ホストのアクセスホストのアクセス, AUTH_SYS とエクスポート制御によるとエクスポート制御による NFS 保護保護

NFSv4 ホストのアクセスホストのアクセス, AUTH_GSS によるによる NFS の保護の保護

ファイル権限ファイル権限, ファイル権限ファイル権限

ファイアウォールでの設定ファイアウォールでの設定, ファイアウォール背後でのファイアウォール背後での NFS の実行の実行

ホスト名の形式ホスト名の形式, ホスト名の形式ホスト名の形式

マウントマウント (クライアントの設定クライアントの設定), NFS クライアントの設定クライアントの設定

停止停止, NFS サーバーの起動と停止サーバーの起動と停止

再読み込み再読み込み, NFS サーバーの起動と停止サーバーの起動と停止

再起動再起動, NFS サーバーの起動と停止サーバーの起動と停止

索引索引

363

動作について動作について, NFS の概要の概要

必須サービス必須サービス, 必須サービス必須サービス

書き込みバリア書き込みバリア, NFS

状態状態, NFS サーバーの起動と停止サーバーの起動と停止

自動マウント機能のマップを格納、自動マウント機能のマップを格納、格納に格納に LDAP を使用を使用 (autofs), サイトの設定ファイルの無効化サイトの設定ファイルの無効化/拡大拡大

起動起動, NFS サーバーの起動と停止サーバーの起動と停止

NFS (で使用するで使用する)

FS-Cache, NFS でのキャッシュの使用でのキャッシュの使用

NFS (キャッシュの制限キャッシュの制限)

FS-Cache, NFS でのキャッシュの制限でのキャッシュの制限

NFS およびおよび rpcbind に関するトラブルシューティングに関するトラブルシューティング

NFS, NFS およびおよび rpcbind に関するトラブルシューティングに関するトラブルシューティング

NFS でのキャッシュの制限でのキャッシュの制限

FS-Cache, NFS でのキャッシュの制限でのキャッシュの制限

nobarrier マウントオプションマウントオプション


XFS, 書き込みバリア書き込みバリア

NOP-Out (無効化無効化)


NOP-Out を無効にするを無効にする


NOP-Out 要求要求

リンク損失の修正リンク損失の修正

iSCSI 設定設定, NOP-Out インターバルインターバル/タイムアウトタイムアウト

O

opt ディレクトリーディレクトリー, /opt/ ディレクトリーディレクトリー

P

Parallel NFS

pNFS, pNFS

parted , パーティションパーティション

コマンドの表コマンドの表, パーティションパーティション

デバイスの選択デバイスの選択, パーティションテーブルの表示パーティションテーブルの表示

パーティションのサイズ変更パーティションのサイズ変更, fdisk を使用したパーティションのサイズ変更を使用したパーティションのサイズ変更


364

パーティションの作成パーティションの作成, パーティションの作成パーティションの作成

パーティションの削除パーティションの削除, パーティションの削除パーティションの削除

パーティションテーブルの表示パーティションテーブルの表示, パーティションテーブルの表示パーティションテーブルの表示

概要概要, パーティションパーティション

pNFS

Parallel NFS, pNFS

pquota/pqnoenforce


proc ディレクトリーディレクトリー, /proc/ ディレクトリーディレクトリー

proper nsswitch configuration (autofs version 5), use of


Q

queue_if_no_path

iSCSI 設定設定, dm-multipath を実装しているを実装している iSCSI の設定の設定


iSCSI 設定設定, replacement_timeout

quota (ext4 ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー)


quotacheck , クォータデータベースファイルの作成クォータデータベースファイルの作成

quotacheck コマンドコマンド

でクオータの正確度をチェックでクオータの正確度をチェック, クォータの精度維持クォータの精度維持

quotaoff , 有効化と無効化有効化と無効化

quotaon , 有効化と無効化有効化と無効化

R

RAID

Anaconda サポートサポート, Anaconda インストーラーのインストーラーの RIAD サポートサポート

dmraid, dmraid

dmraid (RAID セットを設定するセットを設定する), dmraid

mdadm (RAID セットを設定するセットを設定する), mdadm

mdraid, mdraid

RAID のサブシステムのサブシステム, Linux RAID サブシステムサブシステム

RAID セットを設定するセットを設定する, RAID セットの設定セットの設定

インストーラーのサポートインストーラーのサポート, Anaconda インストーラーのインストーラーの RIAD サポートサポート

ストライピングストライピング, RAID レベルとリニアサポートレベルとリニアサポート

ソフトウェアソフトウェア RAID, RAID のタイプのタイプ

索引索引

365

ハードウェアハードウェア RAID, RAID のタイプのタイプ

ハードウェアハードウェア RAID のコントローラードライバーのコントローラードライバー, Linux ハードウェアハードウェア RAID のコントローラードライのコントローラードライバーバー

パリティーパリティー, RAID レベルとリニアサポートレベルとリニアサポート

ミラーリングミラーリング, RAID レベルとリニアサポートレベルとリニアサポート

リニアリニア RAID, RAID レベルとリニアサポートレベルとリニアサポート

レベルレベル, RAID レベルとリニアサポートレベルとリニアサポート

レベルレベル 0, RAID レベルとリニアサポートレベルとリニアサポート




採用する利点採用する利点, RAID (Redundant Array of Independent Disks)

高度な高度な RAID デバイス作成法デバイス作成法, 高度な高度な RAID デバイスの作成デバイスの作成

RAID のサブシステムのサブシステム

RAID, Linux RAID サブシステムサブシステム

RAID セットを設定するセットを設定する

RAID, RAID セットの設定セットの設定

RDMA

NFS, RDMA でで NFS の有効化の有効化 (NFSoRDMA)

READ CAPACITY(16)

I/O の調整とサイズの調整とサイズ, SCSI

read/write ステータスの変更ステータスの変更

オンライン論理ユニットオンライン論理ユニット, オンライン論理ユニットのオンライン論理ユニットの Read/Write ステータスの変更ステータスの変更

Red Hat Enterprise Linux 固有のファイルの場所固有のファイルの場所

/etc/sysconfig/, 特殊な特殊な Red Hat Enterprise Linux ファイルの場所ファイルの場所

(参照参照 sysconfig ディレクトリーディレクトリー)

/var/cache/yum, 特殊な特殊な Red Hat Enterprise Linux ファイルの場所ファイルの場所

/var/lib/rpm/, 特殊な特殊な Red Hat Enterprise Linux ファイルの場所ファイルの場所

replacement_timeout


iSCSI 設定設定, SCSI エラーハンドラーエラーハンドラー, replacement_timeout

replacement_timeoutM


report (xfs_quota エキスパートモードエキスパートモード)



366

rescan-scsi-bus.sh



resize2fs, Ext2 ファイルシステムに戻すファイルシステムに戻す

resize2fs (ext4 のサイズ変更のサイズ変更)

ext4, ext4 ファイルシステムのサイズ変更ファイルシステムのサイズ変更

rfc2307bis (autofs)

NFS, LDAP を使用した自動マウント機能のマップの格納を使用した自動マウント機能のマップの格納

rpcbind , NFS とと rpcbind

(参照参照 NFS)

NFS, NFS およびおよび rpcbind に関するトラブルシューティングに関するトラブルシューティング

rpcinfo , NFS およびおよび rpcbind に関するトラブルシューティングに関するトラブルシューティング

状態状態, NFS サーバーの起動と停止サーバーの起動と停止

rpcinfo , NFS およびおよび rpcbind に関するトラブルシューティングに関するトラブルシューティング

S

SCSI エラーハンドラーエラーハンドラー

リング損失の修正リング損失の修正

iSCSI 設定設定, SCSI エラーハンドラーエラーハンドラー

SCSI コマンドタイマーコマンドタイマー

Linux SCSI レイヤーレイヤー, コマンドタイマーコマンドタイマー

SCSI コマンドタイマーとデバイス状態の制御コマンドタイマーとデバイス状態の制御


SCSI 標準標準

I/O の調整とサイズの調整とサイズ, SCSI

SMB (参照参照 SMB)

srv ディレクトリーディレクトリー, /srv/ ディレクトリーディレクトリー

SSD


SSM

System Storage Manager, System Storage Manager (SSM)

list コマンドコマンド, 検出された全デバイスの情報表示検出された全デバイスの情報表示

resize コマンドコマンド, ボリュームの容量追加ボリュームの容量追加

snapshot コマンドコマンド, スナップショットスナップショット

インストールインストール, SSM のインストールのインストール

索引索引

367

バックエンドバックエンド, SSM バックエンドバックエンド

stride (ストライプ配列を指定ストライプ配列を指定)


stripe-width (ストライプ配列を指定ストライプ配列を指定)


su (mkfs.xfs のサブオプションのサブオプション)


sw (mkfs.xfs のサブオプションのサブオプション)


swap 領域領域, swap領域領域

LVM2

作成作成, swap のの LVM2 論理ボリュームの作成論理ボリュームの作成

削除削除, swap のの LVM2 論理ボリュームの削除論理ボリュームの削除

拡張拡張, LVM2 論理ボリュームでの論理ボリュームでの swap 領域の拡張領域の拡張

縮小縮小, LVM2 論理ボリュームでの論理ボリュームでの swap 領域の縮小領域の縮小

ファイルファイル

作成作成, swap ファイルを作成するファイルを作成する, swap ファイルの削除ファイルの削除

作成作成, Swap 領域の追加領域の追加

削除削除, Swap 領域の削除領域の削除

拡張拡張, Swap 領域の追加領域の追加

推奨サイズ推奨サイズ, swap領域領域

移動移動, Swap 領域の移動領域の移動

sys ディレクトリーディレクトリー, /sys/ ディレクトリーディレクトリー

sysconfig ディレクトリーディレクトリー, 特殊な特殊な Red Hat Enterprise Linux ファイルの場所ファイルの場所

sysfs

概要概要

オンラインストレージオンラインストレージ, オンラインストレージ管理オンラインストレージ管理

sysfs インターフェースインターフェース (ユーザー領域のアクセスユーザー領域のアクセス)

I/O の調整とサイズの調整とサイズ, sysfs インターフェースインターフェース

System Storage Manager

SSM, System Storage Manager (SSM)

list コマンドコマンド, 検出された全デバイスの情報表示検出された全デバイスの情報表示

resize コマンドコマンド, ボリュームの容量追加ボリュームの容量追加

snapshot コマンドコマンド, スナップショットスナップショット

インストールインストール, SSM のインストールのインストール


368

T

tftp サービス、設定サービス、設定

ディスクレスのシステムディスクレスのシステム, ディスクレスクライアントのディスクレスクライアントの tftp サービスの設定サービスの設定

TRIM コマンドコマンド


tune2fs

でで ext2 に戻すに戻す, Ext2 ファイルシステムに戻すファイルシステムに戻す

でで ext3 に変換に変換, ext3 ファイルシステムへの変換ファイルシステムへの変換

tune2fs (キャッシュを設定するキャッシュを設定する)


tune2fs (マウントするマウントする)


U

udev rule (timeout)

command timer (SCSI), コマンドタイマーコマンドタイマー

umount, ファイルシステムのアンマウントファイルシステムのアンマウント

uquota/uqnoenforce


usr ディレクトリーディレクトリー, /usr/ ディレクトリーディレクトリー

V

var ディレクトリーディレクトリー, /var/ ディレクトリーディレクトリー

var/lib/rpm/ ディレクトリーディレクトリー, 特殊な特殊な Red Hat Enterprise Linux ファイルの場所ファイルの場所

var/spool/up2date/ ディレクトリーディレクトリー, 特殊な特殊な Red Hat Enterprise Linux ファイルの場所ファイルの場所

version

what is new

autofs, autofs バージョンバージョン 5 の改善点の改善点 (バージョンバージョン 4 との比較との比較)

volume_key

1 ユーザーユーザー, volume_key の個人ユーザーとしての使用の個人ユーザーとしての使用

コマンドコマンド, volume_key コマンドコマンド

W

World Wide Identifier (WWID)

永続的な命名永続的な命名, World Wide Identifier (WWID)

索引索引

369

WWID

永続的な命名永続的な命名, World Wide Identifier (WWID)

X

XFS

fsync(), XFS ファイルシステムファイルシステム

gquota/gqnoenforce, XFS クォータの管理クォータの管理

limit (xfs_quota エキスパートモードエキスパートモード), XFS クォータの管理クォータの管理

mkfs.xfs, XFS ファイルシステムの作成ファイルシステムの作成

nobarrier マウントオプションマウントオプション, 書き込みバリア書き込みバリア

pquota/pqnoenforce, XFS クォータの管理クォータの管理

report (xfs_quota エキスパートモードエキスパートモード), XFS クォータの管理クォータの管理

su (mkfs.xfs のサブオプションのサブオプション), XFS ファイルシステムの作成ファイルシステムの作成

sw (mkfs.xfs のサブオプションのサブオプション), XFS ファイルシステムの作成ファイルシステムの作成

uquota/uqnoenforce, XFS クォータの管理クォータの管理

xfsdump, バックアップバックアップ

xfsprogs, XFS ファイルシステムの一時停止ファイルシステムの一時停止

xfsrestore, 復元復元

xfs_admin, XFS ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

xfs_bmap, XFS ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

xfs_copy, XFS ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

xfs_db, XFS ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

xfs_freeze, XFS ファイルシステムの一時停止ファイルシステムの一時停止

xfs_fsr, XFS ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

xfs_growfs, XFS ファイルシステムのサイズの拡大ファイルシステムのサイズの拡大

xfs_info, XFS ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

xfs_mdrestore, XFS ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

xfs_metadump, XFS ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

xfs_quota, XFS クォータの管理クォータの管理

xfs_repair, XFS ファイルシステムの修復ファイルシステムの修復

インタラクティブな操作インタラクティブな操作 (xfsrestore), 復元復元

エキスパートモードエキスパートモード (xfs_quota), XFS クォータの管理クォータの管理

クォータの管理クォータの管理, XFS クォータの管理クォータの管理

シンプルモードシンプルモード (xfsrestore), 復元復元

ダンプのレベルダンプのレベル, バックアップバックアップ

ダーティーログを持つダーティーログを持つ XFS ファイルシステムの修復ファイルシステムの修復, XFS ファイルシステムの修復ファイルシステムの修復

バックアップと復元バックアップと復元, XFS ファイルシステムのバックアップと復元ファイルシステムのバックアップと復元

ファイルシステムのサイズの拡大ファイルシステムのサイズの拡大, XFS ファイルシステムのサイズの拡大ファイルシステムのサイズの拡大

ファイルシステムの修復ファイルシステムの修復, XFS ファイルシステムの修復ファイルシステムの修復

ファイルシステムタイプファイルシステムタイプ, XFS ファイルシステムファイルシステム

プロジェクト制限プロジェクト制限 (の設定の設定), プロジェクト制限の設定プロジェクト制限の設定


370

マウントマウント, XFS ファイルシステムのマウントファイルシステムのマウント

一時停止一時停止, XFS ファイルシステムの一時停止ファイルシステムの一時停止

主な特長主な特長, XFS ファイルシステムファイルシステム

作成作成, XFS ファイルシステムの作成ファイルシステムの作成

割り当て機能割り当て機能, XFS ファイルシステムファイルシステム

書き込みバリア書き込みバリア, 書き込みバリア書き込みバリア

累積モード累積モード (xfsrestore), 復元復元

xfsdump

XFS, バックアップバックアップ

xfsprogs


xfsrestore

XFS, 復元復元

xfs_admin

XFS, XFS ファイルシステムのその他のユーティリティーファイルシステムのその他のユーティリティー

xfs_bmap


xfs_copy


xfs_db


xfs_freeze


xfs_fsr


xfs_growfs

XFS, XFS ファイルシステムのサイズの拡大ファイルシステムのサイズの拡大

xfs_info


xfs_mdrestore


xfs_metadump


索引索引

371

xfs_quota


xfs_repair



372

Documents

Red Hat Enterprise Linux 7 · 2020-03-16 · 1.1. red hat enterprise linux 7 の新機能と拡張 パートi ルルシステテム 第2章ファイル テムの構造造 メンテナナン

Red Hat Enterprise Linux 7 · 2020-03-16 · 1.1. red hat enterprise linux 7 の新機能と拡張パートi ルルシステテム第2章ファイルテムの構造造メンテナナン