本記事の概要:
自動化は、効率の向上、時間の節約、一貫性の向上などに役立つので、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 つのサーバーにある上記のストレージデバイス名は一致しません。
この例では、以下の新しいボリュームグループ、論理ボリューム、ファイルシステムを設定します。
通常、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 が rhel8-server3 ホストから収集したファクトを素早く確認できます。
$ 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 (英語版) を確認してください。