本記事の概要:
-
ストレージシステムロールで、論理ボリュームマネージャー (LVM) のボリュームグループ、論理グループ、ファイルシステムの設定を自動化する方法を説明します。
自動化は、効率の向上、時間の節約、一貫性の向上などに役立つので、Red Hat Enterprise Linux (RHEL) には、大量のタスクの自動化に便利な機能が含まれています。RHEL のシステムロール とは、RHEL に同梱されている Ansible コンテンツのコレクションのことで、このシステムロールを使用して多くの手作業でのタスクを効率化するとともに、ワークフローに一貫性を持たせることができます。
RHEL には、論理ボリュームマネージャー (LVM) ボリュームグループ、論理ボリューム、ファイルシステムの設定を自動化できる storage システムロールが含まれています。storage ロールは、LVM を使用せずに、パーティション分割されていないディスクでファイルシステムを作成することにも対応します。さらに、storage ロールは、暗号化、重複排除、圧縮、RAID などの高度なストレージ機能の自動化も可能です。
RHEL システムロールを使用したローカルストレージの管理 のドキュメントには、さまざまなシナリオで storage システムロールを使用する方法に関する情報と Playbook のサンプルが含まれています。
この記事では、複数のシステム間でストレージロールを使用することに焦点を当てているので、ストレージデバイスの名前が一致しない場合があります。たとえば、storage ロールを使用して多くの RHEL ホストで新しいボリュームグループ、論理ボリューム、ファイルシステムを実装する場合には、これらの RHEL ホストで使用されるストレージデバイス名に、一貫性がなくなってしまいます。
環境の概要
今回の環境には、controlnode という名前のコントロールノード (RHEL 8.5 を実行) と、rhel8-server3 と rhel8-server4 の管理対象ノード (いずれも RHEL 8.5 を実行) があります。 上記のサーバーでは、以下のストレージデバイスを使用します。
rhel8-server3 |
rhel8-server4 |
OS のボリュームグループに使用される vda (25GB) |
OS のボリュームグループに使用される vda (20GB) |
vdb (20GB) |
vdb (15GB) |
vdc (10GB) |
vdc (10GB) |
vdd (15GB) |
vdd (10GB) |
vde (10GB) |
vde (15GB) |
vdf (15GB) |
このように、各サーバーには 10GB ディスク (表の青いセル) が 2 つと 15 GB のディスク (表の赤いセル) が 2 つありますが、この 2 つのサーバーにある上記のストレージデバイス名は一致しません。
この例では、以下の新しいボリュームグループ、論理ボリューム、ファイルシステムを設定します。
-
10 GB ディスクを 2 つ使用する web_vg ボリュームグループ (表の青いセル)
-
web_lv 論理ボリュームで、ボリュームグループの全容量を使用し、 /web にマウントされる。
-
-
15GB ディスクを 2 つ使用する database_vg ボリュームグループ (表の赤いセル)
-
database_lv 論理ボリュームで、ボリュームグループの容量の 50% を使用し、/database にマウントされる。
-
backup_lv 論理ボリュームで、ボリュームグループの容量の 20% を使用し、/backup にマウントされる。
-
ボリュームグループの容量の 30% は今後の拡張に備え、空けておく必要がある。
-
通常、storage システムロールを使用する場合は、このロールに対して、ディスクデバイスの一覧が指定されます。たとえば、15GB のディスクを 2 つ使用して、database_vg ボリュームグループ、論理ボリューム、およびファイルシステムを rhel8-server3 に作成する基本的な Playbook には以下が含まれます。
- hosts: rhel8-server3 vars: storage_pools: - name: database_vg disks: - vdd - vdf volumes: - name: database_lv size: 50% mount_point: "/database" state: present - name: backup_lv size: 20% mount_point: "/backup" state: present roles: - redhat.rhel_system_roles.storage
この Playbook は、15GB のディスクに vdd と vdf のデバイス名が指定されている rhel8-server3 では機能しますが、rhel8-server4 のホストでは vdf デバイスがないので失敗します。さらに、vdd デバイスは rhel8-server4 に存在していますが、10GB であるため、このボリュームグループを 15GB のディスクに配置する必要があります。
host_vars ディレクトリを作成して、各ホストに固有の変数を定義できます。こうすることで、各ホストで使用するディスクを指定できるようになります。ただし、複数のホストがある場合は、各ホストからディスク情報を手動で収集して、その情報をホストごとに host_vars ファイルに指定するのはすぐに実用的でなくなります。
このシナリオでは、Ansible ファクト を使用して、Ansible がディスクを動的に検索していきます。
Ansible ファクト
デフォルトでは、Ansible を使用してホストで Playbook を実行すると、最初のタスクで各ホストからファクトが収集されます。これらのファクトには、ストレージデバイスに関する情報など、各ホストに関する多くの情報が含まれています。
コントロールノードには、以下のエントリーを含む inventory.yml という名前のインベントリーファイルがあります。
all: hosts: rhel8-server3: rhel8-server4:
※ Ansible 自動化コントローラーをコントロールノードとして使用する場合には、このインベントリーは SCM プロジェクト (例: GitHub または GitLab) あるいは このドキュメントに記載の awx-manage ユーティリティ を使用してインポートできます。 |
$ ansible rhel8-server3 -m setup -i inventory.yml
ansible_devices のリストなど、収集されたファクトが表示されます。このリストでは、以下のように、ディスクデバイスごとにエントリーが 1 つ割り当てられています。
"vdc": { "holders": [], "host": "SCSI storage controller: Red Hat, Inc. Virtio block device (rev 01)", "links": { "ids": [], "labels": [], "masters": [], "uuids": [] }, "model": null, "partitions": {}, "removable": "0", "rotational": "1", "sas_address": null, "sas_device_handle": null, "scheduler_mode": "none", "sectors": "20971520", "sectorsize": "512", "size": "10.00 GB", "support_discard": "512", "vendor": "0x1af4", "virtual": 1 },
ファクトには、size フィールドのディスクサイズに関する情報と、holders、links、および partitions に関する情報が含まれます。
holders、links、および partitions フィールドを目安として使用して、ディスクにデータが含まれている可能性があるかどうかを確認できます。storage ロールで使用すべきディスクを選択する Playbook をビルドする場合に、上記のフィールドを使用して、データがすでに含まれている既存ディスクを除外することができます。ただし、最初の実行時に storage ロールでこれらの未使用のデバイスが設定されるので、このタイプのロジックはべき等ではありません。この Playbook は、後続の実行で未使用のディスクを見つけられなくなり、失敗します。
このブログ記事で紹介した例では、オペレーティングシステム (OS) を起動するディスク (全管理対象ノードの vda デバイス) を除く、システム上のすべてのストレージがこの storage デバイスにより制御されるので、すでにデータが含まれている可能性のあるディスクを選択しても構いません。
strage ロールが使用するディスクにデータが含まれいるものを誤って特定しまうとデータが損失する可能性があるので、細心の注意を払う必要があります。
Ansible ファクトを用いた storage ロールで使用するディスクの選択
この例では、web_vg ボリュームグループに 10GB ディスクを 2 つ、database_vg ボリュームグループには 15GB ディスクを 2 つ検索して、使用していきます。今回使用する環境では、すべてのストレージデバイスが vd で始まり、OS はすべてのサーバーの vda にインストールされているので、使用するディスクの検索時には vda を除外します。
また、この環境では storage ロールが、システム上にある vda デバイス以外のストレージをすべて管理しているので、データがすでに含まれているディスクを検索して使用する Playbook はここでは重要ではありません。お使いの全環境が storage ロールで管理されていない場合は、Playbook でデータがすでに含まれている可能性のあるディスクを使用して、データが損失されないように細心の注意を払う必要があります。
使用環境に基づいて、ご自身の基準でディスクを特定する Playbook を作成してください。
- hosts: all tasks: - name: Identify disks that are 10 GB for web_vg set_fact: web_vg_disks: "{{ ansible_devices | dict2items | selectattr('key', 'match', '^vd.*') | rejectattr('key', 'match', '^vda$') | selectattr('value.size', 'match', '^10.00 GB') | map(attribute='key') | list }}" - name: Identify disks that are 15 GB for database_vg set_fact: database_vg_disks: "{{ ansible_devices | dict2items | selectattr('key', 'match', '^vd.*') | rejectattr('key', 'match', '^vda$') | selectattr('value.size', 'match', '^15.00 GB') | map(attribute='key') | list }}" - name: Show value of web_vg_disks ansible.builtin.debug: var: web_vg_disks - name: Show value of database_vg_disks ansible.builtin.debug: var: database_vg_disks
最初のタスクでは、デバイス名が vd (vdaを除く) で始まる ansible_devices を特定し、サイズが 10GB のディスクを特定します。上記で特定したディスクは web_vg_disks リスト変数に割り当てられます。
2 つ目のタスクも同じように機能し、database_vg ボリュームグループに 15GB のディスクを特定して、database_vg_disks 変数に、特定済みディスクの一覧を保存します。
3 番目と 4 番目のタスクでは web_vg_disks と database_vg_disks 変数の内容を表示します。
Playbook は、実行すると以下のように表示します。
TASK [Show value of web_vg_disks] ******************************************************************************************** ok: [rhel8-server3] => { "web_vg_disks": [ "vde", "vdc" ] } ok: [rhel8-server4] => { "web_vg_disks": [ "vdd", "vdc" ] } TASK [Show value of database_vg_disks] *************************************************************************************** ok: [rhel8-server3] => { "database_vg_disks": [ "vdf", "vdd" ] } ok: [rhel8-server4] => { "database_vg_disks": [ "vdb", "vde" ] }
この Playbook で、サーバーごとに使用するディスクが正しく特定されました。
Playbook へのストレージ設定の追加
使用するディスクを特定するロジックができました。次の手順では、storage ロールを使用して、必要なボリュームグループ、論理ボリューム、およびファイルシステム設定を実装します。
別のタスクを Playbook に追加して、storage ロールを呼び出します。storage.yml という名前の Playbook の全内容は以下のとおりです。
- hosts: all tasks: - name: Identify disks that are 10 GB for web_vg set_fact: web_vg_disks: "{{ ansible_devices | dict2items | selectattr('key', 'match', '^vd.*') | rejectattr('key', 'match', '^vda$') | selectattr('value.size', 'match', '^10.00 GB') | map(attribute='key') | list }}" - name: Identify disks that are 15 GB for database_vg set_fact: database_vg_disks: "{{ ansible_devices | dict2items | selectattr('key', 'match', '^vd.*') | rejectattr('key', 'match', '^vda$') | selectattr('value.size', 'match', '^15.00 GB') | map(attribute='key') | list }}" - name: Show value of web_vg_disks ansible.builtin.debug: var: web_vg_disks - name: Show value of database_vg_disks ansible.builtin.debug: var: database_vg_disks - name: Run storage role vars: storage_pools: - name: web_vg disks: "{{ web_vg_disks }}" volumes: - name: web_lv size: 100% mount_point: "/web" state: present - name: database_vg disks: "{{ database_vg_disks }}" volumes: - name: database_lv size: 50% mount_point: "/database" state: present - name: backup_lv size: 20% mount_point: "/backup" state: present include_role: name: rhel-system-roles.storage
Run storage role タスクでは、storage_pool 変数を定義して、目的とするストレージ設定を指定します。このタスクは、web_vg ボリュームグループと、その容量を 100% 使用する web_lv 論理グループを作成し、ファイルシステムを割り当てて /web にマウントするように指定します。このボリュームグループは、1 つ前のタスクで、指定の基準を満たして検出されたディスクをもとに定義した web_vg_disks 変数に記載されているディスクを使用する必要があります。
同様に、database_vg ボリュームグループと、その容量の 50% を使用して database_lv 論理ボリュームを作成し、ファイルシステムを割り当てて /database にマウントされるように指定します。また、容量の 20% を使用した backup_lv 論理グループも必要で、ファイルシステムを割り当てて /backup にマウントします。このボリュームグループは、1 つ前のタスクで、基準を満たして検出されたディスクをもとに定義した database_vg_disks 変数に記載されているディスクを使用する必要があります。
※ Ansible 自動化コントローラーをコントロールノードとして使用する場合には、こちらのドキュメントに記載の手順に従い、プロジェクトを作成して、この Ansible Playbook を Red Hat Ansible Automation Platform にインポートしてください。Ansible Playbook の保存に Git リポジトリを使用するのは非常に一般的です。Ansible Automation Platform では、Playbook、認証情報、およびインベントリーを含むジョブという単位で自動化を保存します。こちらのドキュメント に従って、ジョブテンプレートを作成します。 |
Playbook の実行
この時点では、すべてが整っており、Playbook を実行する準備ができています。このデモでは、RHEL コントロールノードを使用して、コマンドラインから Playbook を実行します。cd
コマンドを使用して storage ディレクトリに移動し、ansible-playbook
コマンドを使用して Playbook を実行します。
[ansible@controlnode ~]$ cd storage/ [ansible@controlnode storage]$ ansible-playbook storage.yml -b -i inventory.yml
storage.yml Playbook を実行すること、root (-b フラグ) に昇格すること、inventory.yml ファイルを Ansible インベントリー (-i ファイル) として使用することを指定しています。
Playbook の実行後に、失敗したタスクがないことを確認する必要があります。
※ Ansible 自動化コントローラーをコントロールノードとして使用する場合には、自動化コントローラーの Web インタフェースからジョブを起動できます。 |
設定の検証
設定の検証には、各管理ノードで lsblk
コマンドを実行します。
$ ssh rhel8-server3 lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 25G 0 disk ├─vda1 252:1 0 1G 0 part /boot └─vda2 252:2 0 24G 0 part ├─rhel-root 253:0 0 21.5G 0 lvm / └─rhel-swap 253:1 0 2.5G 0 lvm [SWAP] vdb 252:16 0 20G 0 disk vdc 252:32 0 10G 0 disk └─web_vg-web_lv 253:4 0 20G 0 lvm /web vdd 252:48 0 15G 0 disk └─database_vg-database_lv 253:3 0 15G 0 lvm /database vde 252:64 0 10G 0 disk └─web_vg-web_lv 253:4 0 20G 0 lvm /web vdf 252:80 0 15G 0 disk └─database_vg-backup_lv 253:2 0 6G 0 lvm /backup $ ssh rhel8-server4 lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 20G 0 disk ├─vda1 252:1 0 1G 0 part /boot └─vda2 252:2 0 19G 0 part ├─rhel-root 253:0 0 17G 0 lvm / └─rhel-swap 253:1 0 2G 0 lvm [SWAP] vdb 252:16 0 15G 0 disk └─database_vg-backup_lv 253:2 0 6G 0 lvm /backup vdc 252:32 0 10G 0 disk └─web_vg-web_lv 253:4 0 20G 0 lvm /web vdd 252:48 0 10G 0 disk └─web_vg-web_lv 253:4 0 20G 0 lvm /web vde 252:64 0 15G 0 disk └─database_vg-database_lv 253:3 0 15G 0 lvm /database
どちらのサーバーにも、 web_vg ボリュームグループが 2 つの 10GB ディスク上に、database_vg が2 つの 15GB ディスク上に設定されていることが分かります。また、論理ボリュームのサイズが任意の設定と一致しているかを検証することもできます。
次のステップ
この Playbook はべき等であるため、再度実行することができ、システムを特定の状態に変更する必要がない限り、タスクで何も変更されません。
database_vg では、論理ボリュームはこのボリュームグループで使用可能な容量の合計 70% しか使用していません (50% が databale_lv、20% が backup_lv)。つまり、各ホストのこのボリュームグループには 9GB の空きがあることになります。これらの論理ボリュームの 1 つと、対応するファイルシステムの容量を増やすには、Playbook にアクセスして、割り当てる必要のある容量の割合を更新するだけです。
たとえば、Playbook で database_lv のサイズを 50% から 60% に増やして、Playbook を再実行すると、database_lv と対応の /database ファイルシステムは 15GB から 18GB に増えます。
まとめ
storage RHEL システムロールを使用すると、RHEL 環境でストレージに一貫性をもたせ、素早く設定できます。
Red Hat では、RHEL 環境の他の重要な側面を自動化できるように、RHEL システムロール を多数提供しています。他のロールを確認するには、提供されている RHEL システムロール一覧 を確認し、今すぐ RHEL サーバーの管理を効率化、整合化、自動化してみてください。
Red Hat Ansible Automation Platform の詳細は、E ブック The automation architect's handbook (英語版) を確認してください。
執筆者紹介
Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management. He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).
類似検索
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
オリジナル番組
エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー
製品
ツール
試用、購入、販売
コミュニケーション
Red Hat について
エンタープライズ・オープンソース・ソリューションのプロバイダーとして世界をリードする Red Hat は、Linux、クラウド、コンテナ、Kubernetes などのテクノロジーを提供しています。Red Hat は強化されたソリューションを提供し、コアデータセンターからネットワークエッジまで、企業が複数のプラットフォームおよび環境間で容易に運用できるようにしています。
言語を選択してください
Red Hat legal and privacy links
- Red Hat について
- 採用情報
- イベント
- 各国のオフィス
- Red Hat へのお問い合わせ
- Red Hat ブログ
- ダイバーシティ、エクイティ、およびインクルージョン
- Cool Stuff Store
- Red Hat Summit