ブランクがあるインフラエンジニアの備忘録

ローカル用パッケージリポジトリサーバーの構築

Linuxは通常、インターネットを経由してパッケージを入手することが少なくありませんが、環境によってはインターネットへのアクセスが許されない場合や、独自のカスタムパッケージを社内のみで提供するといった、インターネットへ接続できない環境の場合、管理対象マシンは、社内のパッケージリポジトリサーバを使ってパッケージを入手します。構成例は以下の図になります。

図・パッケージリポジトリサーバーの構成例

◆Nginxのインストール

リポジトリサーバでは、ネットワーク配信のプロトコルとしてHTTPやFTPが利用できます。

HTTPでRPMパッケージを配信する為には、Webサーバーの構築が必要になるので、今回はNginxをインストールします。

[root@local1 ~]# dnf install -y nginx

[root@local1 ~]# systemctl enable --now nginx

Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.

[root@local1 ~]# systemctl is-active nginx

active

[root@local1 ~]# firewall-cmd --zone=public --add-service=http

success

[root@local1 ~]# firewall-cmd --runtime-to-permanent

success

◆パッケージのisoイメージの入手、設置

[root@local1 ~]# mkdir -p /var/www/html/cdrom

インターネットからAlmaLinuxのisoイメージをダウンロードする場合は以下を実行します。

[root@local1 ~]# curl -O https://repo.almalinux.org/almalinux/9.7/isos/x86_64/AlmaLinux-9.7-x86_64-dvd.iso

最新版のisoを入手するには上記方法のが良いですが、ネットが制限された環境でCDドライブからisoを作製する場合は、CDドライブにOSメディアを挿入し、以下のコマンドを実施します。

[root@local1 ~]# dd if=/dev/cdrom of=AlmaLinux-9-3-x86_64-dvd.iso

[root@local1 ~]# ls | grep Alma

AlmaLinux-9-3-x86_64-dvd.iso

上記何れかの手段で入手したisoイメージをマウントします。

[root@local1 ~]# mount -o loop,ro /root/AlmaLinux-9-3-x86_64-dvd.iso /mnt

Nginxが提供する /usr/share/nginx/htmlディレクトリ以下にAL9のリポジトリ用のディレクトリalma9を作成し、DVD isoイメージ内のデータをコピーします。

[root@local1 ~]# mkdir -p /usr/share/nginx/html/alma9

[root@local1 ~]# cp -a /mnt/* /usr/share/nginx/html/alma9/

alma9ディレクトリの中身を確認します。

[root@local1 ~]# ls -aF /usr/share/nginx/html/alma9/

./ BaseOS/ LICENSE extra_files.json media.repo

../ EFI/ RPM-GPG-KEY-AlmaLinux-9 images/

AppStream/ EULA TRANS.TBL isolinux/

◆メタデータの作成

パッケージリポジトリのメタデータ（パッケージリポジトリ全体を管理する為の情報）を作成します。

メタデータをもとにパッケージの現在の状態を把握できます。リポジトリのメタデータはcreaterepoコマンドで作成します。

以下のコマンドでインストールを実施します。

[root@local1 ~]# dnf install -y createrepo_c

つづいてリポジトリのメタデータを作成します。

[root@local1 ~]# createrepo --database /usr/share/nginx/html/alma9

Directory walk started

Directory walk done - 6834 packages

Temporary output repo path: /usr/share/nginx/html/alma9/.repodata/

Preparing sqlite DBs

Pool started (with 5 workers)

Pool finished

◆リポジトリの設定

リポジトリの設定ファイルalma9local,repoを作成します。

[root@local1 ~]# vi /etc/yum.repos.d/alma9local.repo

[local001]

name=AL 9 local repo

baseurl=http://10.0.1.11/alma9

gpgcheck=1

enabled=1

gpgkey=http://10.0.1.11/alma9/RPM-GPG-KEY-AlmaLinux-9

設定ファイルのパラメーターの意味は以下の表のとおりです。

つづいてRPMパッケージリポジトリサーバーでメタデータを読み込みます。

[root@local1 ~]# dnf clean all

26 ファイルが削除されました

[root@local1 ~]# export no_proxy=10.0.1.11

[root@local1 ~]# dnf list available \

--enablerepo=local001 --disablerepo=baseos,appstream,extras,epel,crb

一致するリポジトリーがありません: epel

AL 9 local repo 37 MB/s | 8.4 MB 00:00

メタデータの期限切れの最終確認: 0:00:02 前の 2026年04月20日 03時45分37秒に実施しました。

利用可能なパッケージ

389-ds-base.x86_64 2.3.6-3.el9_3 local001

389-ds-base-libs.x86_64 2.3.6-3.el9_3 local001

Box2D.i686 2.4.1-7.el9 local001

（以下略）

◆リポジトリを利用したRPMパッケージのインストールテスト

作成したlocal001リポジトリを使って、RPMパッケージをインストールできるか、テストとしてlogwatchをインストールしてみます。

logwatchがインストールされていないことを確認します。

[root@local1 ~]# rpm -qa | grep logwatch

インストールされていないことを確認し、logwatchをインストールしてみます。

[root@local1 ~]# dnf install -y \

--enablerepo=local001 --disablerepo=baseos,appstream,extras,epel,crb \

logwatch

一致するリポジトリーがありません: epel

メタデータの期限切れの最終確認: 0:11:04 前の 2026年04月20日 03時45分37秒に実施しました。

依存関係が解決しました。

================================================================================

パッケージ Arch バージョンリポジトリーサイズ

================================================================================

インストール:

logwatch noarch 7.5.5-6.el9 local001 382 k

依存関係のインストール:

perl-Date-Manip noarch 6.85-3.el9 local001 1.0 M

(中略)

インストール済み:

logwatch-7.5.5-6.el9.noarch perl-Date-Manip-6.85-3.el9.noarch

perl-Sys-CPU-0.61-26.el9.x86_64 perl-Sys-MemInfo-0.99-18.el9.x86_64

perl-diagnostics-1.37-480.el9.noarch perl-lib-0.65-480.el9.x86_64

s-nail-14.9.22-6.el9.x86_64

完了しました!

logwatch RPMパッケージがインストールされている事を確認します。

[root@local1 ~]# rpm -qa | grep logwatch

logwatch-7.5.5-6.el9.noarch

◆クライアントマシンで確認。

RPMを取得したいクライアントマシンでパッケージリポジトリサーバーが提供するlocal001リポジトリが利用できるかテストします。

クライアントマシンでログインし、RPMパッケージリポジトリサーバーのリポジトリ設定ファイルalma9local.repoファイルをコピーします。

[root@client ~]# scp 10.0.1.11:/etc/yum.repos.d/alma9local.repo \
/etc/yum.repos.d/

root@10.0.1.11's password:

alma9local.repo 100% 138 38.3KB/s 00:00

つづいて、クライアントマシンからdnfでRPMパッケージが取得できるか確認します。

[root@client ~]# dnf install -y \

--enablerepo=local001 --disablerepo=baseos,appstream,extras,epel,crb \

logwatch

一致するリポジトリーがありません: epel

AL 9 local repo 9.8 MB/s | 8.4 MB 00:00

メタデータの期限切れの最終確認: 0:00:03 前の 2026年04月20日 04時10分14秒に実施しました。

依存関係が解決しました。

================================================================================

パッケージ Arch バージョンリポジトリーサイズ

================================================================================

インストール:

logwatch noarch 7.5.5-6.el9 local001 382 k

依存関係のインストール:

perl-Date-Manip noarch 6.85-3.el9 local001 1.0 M

（中略）

インストール済み:

logwatch-7.5.5-6.el9.noarch perl-Date-Manip-6.85-3.el9.noarch

perl-Sys-CPU-0.61-26.el9.x86_64 perl-Sys-MemInfo-0.99-18.el9.x86_64

perl-diagnostics-1.37-480.el9.noarch perl-lib-0.65-480.el9.x86_64

s-nail-14.9.22-6.el9.x86_64

完了しました!

logwatch RPMパッケージがインストールされている事を確認します。

[root@client ~]#rpm -qa | grep logwatch

logwatch-7.5.5-6.el9.noarch

Windows Server 2016→2022へAD移行⑤　ドメイン/フォレストの機能レベルの変更

◆ドメイン/フォレストの機能レベルの変更のイメージ

◆ドメイン/フォレストの機能レベルの確認及び変更手順

➀「サーバーマネージャー」を起動します。「ツール」をクリックし、「Active Directory ドメインと信頼関係」をクリックします。

➁ 「Active Directory ドメインと信頼関係」が表示されます。「<ドメイン名>」で右クリックし、「ドメインの機能レベルの昇格」をクリックします。

③ 「ドメインの機能レベルの昇格」が表示されます。
Windows 2016ドメインから Windows 2019ドメインに移行した場合など、移行前のドメイン機能レベルが「Windows Server 2016」だった場合は、これ以上上げることはできません。「現在のドメインの機能レベル」がすでに「Windows Server 2016」と表示されている場合は昇格の作業が必要ありません。
上記の状態の場合、「閉じる」をクリックします。

④ 「Active Directory ドメインと信頼関係 [<dc名>]」で右クリックし、「フォレストの機能レベルの昇格」をクリックします。

⑤「フォレストの機能レベルの昇格」が表示されます。
Windows 2016ドメインから Windows 2019ドメインに移行した場合など、移行前のフォレスト機能レベルが「Windows Server 2016」だった場合は、これ以上上げることはできません。「現在のフォレストの機能レベル」がすでに「Windows Server 2016」と表示されている場合は昇格の作業は必要ありません。
上記の場合、「閉じる」をクリックします。

以上でドメイン移行作業は完了です。移行完了後は稼働確認を実施します。
例えば既存DCに参加していたクライアントＰＣが新規DCのドメインに参加できるか、新規のクライアントPCも問題なくドメインに参加できるか等を確認します。

Windows Server 2016→2022へAD移行④続き　IPアドレスの変更

◆IP アドレスの変更
新規DCのIPアドレスとドメインメンバーのDNSサーバー設定に関して、表 5の変更方法が考えられます。お客様の環境や要件に合わせて(A)、(B)、どちらかのパターンの変更方法を選択する必要があります。
■表　IPアドレス変更方法。

▢パターン（A）のIPアドレス変更（移行前のDCが使用していたIPアドレスへの変更）
◆IPアドレス、一時的なDNSサーバー設定の変更（本手順は、WIN2022DC1、WIN2022DC2で行います。）
➀WIN2022DC1のIPアドレスとDNSを以下に変更します。
IP：10.0.1.111→10.0.1.11
代替DNSサーバー：10.0.1.112→無し

➁WIN2022DC2のIPアドレスとDNSを以下に変更します。
IP：10.0.1.112→10.0.1.12
優先DNSサーバー：127.0.0.1→10.0.1.11
代替DNSサーバー：10.0.1.111→無し

◆DNSレコードの確認と複製

➀ 「サーバーマネージャー」を起動します。「このローカルサーバーの構成」をクリックします。

➁「DNS マネージャー」が表示されます。「前方参照ゾーン」の「<ドメイン名>」を開きます。名前が「(親フォルダーと同じ)」、種類が「Host (A)」のレコードを確認します。変更後のWIN2022DC1、WIN2022DC2のIPアドレスが登録されていない場合は登録します。変更前のIPアドレスが残っている場合は削除します。

③手順➁と同様に、名前がWIN2022DC1、WIN2022DC2、種類が「Host (A)」のレコードを確認します。
変更後のWIN2022DC1、WIN2022DC2のIPアドレスが登録されていない場合は登録します。変更前のIPアドレスが残っている場合は削除します。

④ 「DomainDnsZones」を開きます。手順➁と同様に、名前が「(親フォルダーと同じ)」、種類が「Host (A)」のレコードを確認します。
変更後のWIN2022DC1、WIN2022DC2のIPアドレスが登録されていない場合は登録します。変更前のIPアドレスが残っている場合は削除します。

⑤「ForestDnsZones」を開きます。手順➁と同様に、名前が「(親フォルダーと同じ)」、種類が「Host (A)」のレコードを確認します。
変更後のWIN2022DC1、WIN2022DC2のIPアドレスが登録されていない場合は登録します。変更前のIPアドレスが残っている場合は削除します。

⑥「_msdcs.<ドメイン名>」の「gc」を開きます。手順➁と同様に、名前が「(親フォルダーと同じ)」、種類が「Host (A)」のレコードを確認します。
変更後のWIN2022DC1、WIN2022DC2のIPアドレスが登録されていない場合は登録します。変更前のIPアドレスが残っている場合は削除します。

⑦ 管理者としてコマンドプロンプトを起動し、次のコマンドを実行します。
ipconfig /flushdns

⑧ 次のコマンドを実行します。
repadmin /syncall /AeP

すべてのパーティションで「SyncAll はエラーなしで終了しました。」と表示されることを確認します。

◆DNSサーバー設定の変更
➀WIN2022DC1のDNSを以下に変更します。
代替DNSサーバー：無し→10.0.1.12

➁WIN2022DC2のDNSを以下に変更します。
優先DNSサーバー：10.0.1.11→127.0.0.1
代替DNSサーバー：無し→10.0.1.11

▢パターン(B) ドメインメンバーのDNSサーバー設定を変更
ドメインメンバーのDNSサーバー設定を新規DCのIPアドレスに変更する場合、以下を実施します。
⑴ドメインメンバーのDNSサーバー設定を静的に管理している環境ではすべてのドメインメンバーのDNS サーバー設定を変更します。
⑵DHCP サーバーで DNS サーバー設定を配布している環境では DHCPサーバーの設定を変更します。

これらの場合は、すべてのドメインメンバーのDNSサーバー設定を変更する作業にかかる時間や、 DHCP サーバーでの変更がすべてのドメインメンバーに反映されるまでの時間を考慮する必要があります。既存DCを降格する前に、新規DCを参照するようDNSサーバー設定を変更し、すべてのドメインメンバーで変更が反映されてから既存DCの降格作業を行います。

Windows Server 2016→2022へAD移行④　既存DCに対してメンバーサーバーへの降格、ワークグループへの変更、ネットワークからの撤去

◆既存DCに対してメンバーサーバーへの降格、ワークグループへの変更、ネットワークからの撤去のイメージ

◆Windows Server 2016DCの降格
既存DCの降格、ワークグループへの変更を行い、ネットワークから撤去します。

DNSサーバー設定の変更各DCのDNSサーバーの設定で、既存DCのWIN2016DC1、WIN2016DC2のIPアドレスは削除し、新規 DCのWIN2022DC1、WIN2022DC2のIPアドレスを追加します。

◆本検証のDNS設定
DNSを以下の設定に変更します。
➀WIN2016DC1
DNS:127.0.0.1(優先)、10.0.1.12（代替）→10.0.1.111(優先)、10.0.1.112（代替）

➁WIN2016DC2
DNS:127.0.0.1(優先)、10.0.1.11（代替）→10.0.1.111(優先)、10.0.1.112（代替）

③WIN2022DC1
DNS:10.0.1.11(優先)、10.0.1.112（代替）→127.0.0.1(優先)、10.0.1.112（代替）

④WIN2022DC2
DNS:10.0.1.11(優先)、10.0.1.112（代替）→127.0.0.1(優先)、10.0.1.112（代替）

◆DNS委任レコードの変更（本作業はWIN2022DC1で行います）

➀ 「サーバーマネージャー」を起動します。「ツール」をクリックし、「DNS」をクリックします。

➁ 「DNS マネージャー」が表示されます。「前方参照ゾーン」、「<ドメイン名>」の「_msdcs」を開きます。「_msdcs」を右クリックし、「プロパティ」をクリックします。

因みに上記の様に「_msdcs」を右クリックしても「プロパティ」がなく、「_msdcs」のアイコンが黄色で表示されている場合は、「_msdcs」が委任ではなく「<ドメイン名>」の下にドメインとして作成されています。この場合は、以降の手順は不要です。次項の既存DCの降格に進みます。

③ 「_msdcs のプロパティ」が表示されます。「ネームサーバー」で、既存の Windows Server 2016DC1を選択し、「削除」をクリックします。既存のWindows Server 2016DCが複数登録されている場合はすべて削除します。

④「追加」をクリックします。

⑤「新規ネームサーバーレコード」が表示されます。「サーバーの完全修飾ドメイン名 (FQDN)」にWIN2022DC1のFQDN （「WIN2022DC1.nora.ac.jp」）を入力し、「解決」をクリックします。

⑥ 「この NS レコードの IP アドレス」にWIN2022DC1のIPアドレスが入力されます。「::1」が入力された場合は、これを選択して「削除」をクリックし、IPv4アドレスのみにします。

⑦ 「OK」をクリックします。

⑧「_msdcs のプロパティ」に戻ります。「追加」をクリックします。

⑨「新規ネームサーバーレコード」が表示されます。「サーバーの完全修飾ドメイン名 (FQDN)」にWIN2022DC1のFQDN （「WIN2022DC1.nora.ac.jp」）を入力し、「解決」をクリックします。「この NS レコードの IP アドレス」にdc2019-2のIPアドレスが入力されます。「OK」をクリックします。

⑩ 「_msdcs のプロパティ」に戻ります。「OK」をクリックします。

⑪ 「DNS マネージャー」に戻ります。名前が「(親フォルダーと同じ)」、種類が「Name Server (NS)」のレコードとして、WIN2022DC1、WIN2022DC2が登録されたことを確認します。

◆既存DCの降格(本手順は、WIN2016DC1、WIN2016DC2で行います。)

➀ 「サーバーマネージャー」を起動します。「管理」をクリックし、「役割と機能の削除」をクリックします。

➁「役割と機能の削除ウィザード」が開始し、「開始する前に」が表示されます。「次へ」をクリックします。

③「対象サーバーの選択」が表示されます。「サーバープールからサーバーを選択」を選択します。「サーバープール」から「WIN2016DC1」を選択し、「次へ」をクリックします。

④「サーバーの役割の削除」が表示されます。「Active Directory ドメインサービス」のチェックをクリックします。

⑤「Active Directory ドメインサービスを必要とする機能を削除しますか?」のダイアログが表示されます。「機能の削除」をクリックします。

⑥「検証結果」が表示されます。「このドメインコントローラーを降格する」をクリックします。

⑦ 「資格情報」が表示されます。「次へ」をクリックします。

⑧「警告」が表示されます。「削除の続行」にチェックを入れます。「次へ」をクリックします。

⑨ 「新しい Administrator パスワード」が表示されます。降格した後のローカルコンピューターのAdministratorユーザーのパスワードを入力します。「次へ」をクリックします。

⑩「オプションの確認」が表示されます。「降格」をクリックします。 DC降格処理が開始されます。

⑪ DC降格処理が完了すると自動で再起動が行われます。

⑫もう一台の既存DCにも同じ手順を実施します。

◆ワークグループへの変更（本手順は、WIN2016DC1、WIN2016DC2で行います。）

➀「サーバーマネージャー」を起動します。「このローカルサーバーの構成」をクリックします。

➁ ドメイン名をクリックします。

③「システムのプロパティ」が表示されます。「コンピューター名」タブの「変更」をクリックします。

④「コンピューター名/ドメイン名の変更」が表示されます。「ワークグループ」を選択し、「WORKGROUP」と入力します。「OK」をクリックします。

⑤ 上記メッセージが表示されます。「OK」をクリックします。

⑥上記メッセージが表示されます。「OK」をクリックします。

⑦上記メッセージが表示されます。「OK」をクリックします。

⑧「システムのプロパティ」に戻ります。「閉じる」をクリックします。

⑨上記メッセージが表示されます。「今すぐ再起動する」をクリックします。再起動が開始されます。
⑩再起動後、WIN2016DC1をシャットダウンし、ネットワークから撤去します。
⑪WIN2016DC2についても同様の手順を実施します。

◆既存DC降格後の確認
降格したWIN2016DC1、WIN2016DC2の情報が残っていないか、以下の場所を確認します。もし、WIN2016DC1、WIN2016DC2 の情報が残っていた場合は削除し、WIN2022DC1、WIN2022DC2の名前もしくは IP アドレスのみにします。（降格後も一部残った情報に関しては画像付き）

・「Active Directory ユーザーとコンピューター」の「<ドメイン名>」-「Domain Controllers」 OU配下

・「Active Directory サイトとサービス」の「Sites」-「<サイト名>」-「Servers」配下
・「DNS マネージャー」の「<ドメイン名>」ゾーンにある以下のレコード
　 名前が「(親フォルダーと同じ)」、種類が「Name Server (NS)」のレコード
　 名前が「(親フォルダーと同じ)」、種類が「Host (A)」のレコード
　 「_sites」-「<サイト名>」-「_tcp」にある、名前が「_gc」、「 _kerberos」、「 _ldap」、種類が「Service Location (SRV)」のレコード
　 「_tcp」にある、名前が「_gc」、「 _kerberos」、「 _kpasswd」、「 _ldap」、種類が「 Service Location (SRV)」のレコード
　 「_udp」にある、名前が「_kerberos」、「 _kpasswd」、種類が「 Service Location (SRV)」のレコード

　 「DomainDnsZones」にある、名前が「(親フォルダーと同じ)」、種類が「 Host (A)」のレコード
　 「DomainDnsZones」-「_sites」-「<サイト名>」-「_tcp」にある、名前が「_ldap」、種類が「Service Location (SRV)」のレコード

　 「DomainDnsZones」-「_tcp」にある、名前が「_ldap」、種類が「Service Location (SRV)」のレコード

　 「ForestDnsZones」にある、名前が「(親フォルダーと同じ)」、種類が「 Host (A)」のレコード
　 「ForestDnsZones」-「_sites」-「<サイト名>」-「_tcp」にある、名前が「_ldap」、種類が「Service Location (SRV)」のレコード

　 「ForestDnsZones」-「_tcp」にある、名前が「_ldap」、種類が「 Service Location (SRV)」のレコード

・「DNS マネージャー」の「_msdcs.<ドメイン名>」ゾーンにある以下のレコード
　 名前が「(親フォルダーと同じ)」、種類が「Name Server (NS)」のレコード
　 名前が「」、種類が「Alias (CNAME)」のレコード
　 「dc」-「_sites」-「<サイト名>」-「_tcp」にある、名前が「_kerberos」、「 _ldap」、種類が「Service Location (SRV)」のレコード
　 「dc」-「_tcp」にある、名前が「_kerberos」、「 _ldap」、種類が「 Service Location (SRV)」のレコード
　 「domains」-「」-「_tcp」にある、名前が「_ldap」、種類が「 Service Location (SRV)」のレコード
　 「gc」にある、名前が「(親フォルダーと同じ)」、種類が「Host (A)」のレコード
　 「gc」-「_sites」-「<サイト名>」-「_tcp」にある、名前が「_ldap」、種類が「 Service Location (SRV)」のレコード
　 「gc」-「_tcp」にある、名前が「_ldap」、種類が「Service Location (SRV)」のレコード

また、次の場所についてもFSMO（PDC エミュレーター）の役割を転送させた WIN2022DC1 の名前になっているか確認します。
・「DNS マネージャー」の「_msdcs.<ドメイン名>」ゾーンにある次のレコード
　 「pdc」-「_tcp」にある、名前が「_ldap」、種類が「Service Location (SRV)」のレコード

Windows Server 2016→2022へAD移行③　FSMOの転送

◆FSMOを新規DCに転送するイメージ

◆FSMOの転送
Active Directory では、フォレストもしくはドメイン内で1台のDCのみで実行する必要のある処理があります。このような処理を実行するよう割り当てられた DC を「Flexible Single Master Operations」 (FSMO) の役割の所有者と呼びます。 FSMOには次があります。・ PDCエミュレーター・ RIDマスター・インフラストラクチャーマスター・スキーママスター・ドメイン名前付け操作マスター FSMO の役割を持った DC が存在しない状態とならないよう、既存DCを降格する前に新規DCに FSMOの役割を転送します。
以下を新規DC（WIN2022DC1）で実行します。

➀管理者としてPowerShellを起動し、次のコマンドを実行します。
Move ADDirectoryServerOperationMas terRole -Identity "WIN2022DC1" OperationMasterRole PDCEmulator,RIDMaster,Infrastr uctureMaster,SchemaMaster,Do mainNamingMaster

PDCエミュレーター、RIDマスター、インフラストラクチャーマスター、スキーママスター、ドメイン名前付け操作マスターを移動するか確認のメッセージが表示されます。それぞれに対して「Y」を入力し、Enter キーを押します。移動に成功するとエラーなどは表示されずに終了します。

以下、実施例

➁次のコマンドを実行します。
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,Infrastr uctureMaster | fl

PDCエミュレーター、RIDマスター、インフラストラクチャーマスターがWIN2022DC1に変更されたことを確認します。以下、実行例

③次のコマンドを実行します。
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster | fl
スキーママスター、ドメイン名前付け操作マスターが WIN2022DC1に変更されたことを確認します。以下、実行例。

Windows Server 2016→2022へAD移行➁　Windows Server 2022DC の追加

◆Windows Server 2022DC の追加イメージ

今回は上記イメージの右側の新規DC2台を追加していきます。

◆Windows Server 2022マシンにActive Directoryをインストール
（WIN2022DC1、WIN2022DC2の両方で実施）

➀「サーバーマネージャー」を起動します。「ダッシュボード」で「役割と機能の追加」をクリックします。

➁「役割と機能の追加ウィザード」が開始し、「開始する前に」が表示されます。「次へ」をクリックします。

③「インストールの種類の選択」が表示されます。「役割ベースまたは機能ベースのインストール」を選択し、「次へ」をクリックします。

④ 「対象サーバーの選択」が表示されます。「サーバープールからサーバーを選択」を選択します。「サーバープール」で「（ホスト名）」を選択し、「次へ」をクリックします。

⑤ 「サーバーの役割の選択」が表示されます。「Active Directory ドメインサービス」にチェックを入れます。

⑥「Active Directory ドメインサービスに必要な機能を追加しますか?」のダイアログが表示されます。「機能の追加」をクリックします。

⑦「サーバーの役割の選択」の画面に戻ります。「Active Directory ドメインサービス」にチェックがついたことを確認し、「次へ」をクリックします。

⑧「機能の選択」が表示されます。「次へ」をクリックします。

⑨「Active Directory ドメインサービス」が表示されます。「次へ」をクリックします。

⑩「インストールオプションの確認」が表示されます。「インストール」をクリックします。
以降、「インストールの進行状況」が表示され、Active Directory ドメインサービスのインストールが開始します。完了するまで待機します。
Active Directory ドメインサービスのインストールが完了すると、「構成が必要です。<サーバー名>でインストールが正常に完了しました。」というメッセージが表示されます。「閉じる」をクリックします。

⑪1台目が終了したら2台目も同様の手順を行います。

◆ドメインコントローラーへの昇格

➀「サーバーマネージャー」の通知アイコンをクリックし、「このサーバーをドメインコントローラーに昇格する」をクリックします。

➁ 「Active Directory ドメインサービス構成ウィザード」が開始し、「配置構成」が表示されます。「既存のドメインにドメインコントローラーを追加する」を選択します。ドメインの「選択」をクリックします。

③「Windows セキュリティ」が表示されます。ドメインの管理者ユーザーの名前とパスワードを入力します。「OK」をクリックします。

④「フォレストからのドメインの選択」が表示されます。ドメインを選択し、「OK」をクリックします。

⑤ ドメイン名と資格者情報が入力されたことを確認し、「次へ」をクリックします。

⑥ 「ドメインコントローラーオプション」が表示されます。「ドメインネームシステム (DNS) サーバー」、「グローバルカタログ (GC)」のチェックをオンにします。「サイト名」は、リストからサイト名を選択します。ディレクトリサービス復元モード（DSRM）のパスワードを入力します。すべての設定が完了したら、「次へ」をクリックします。

⑦ 「DNS オプション」が表示されます。「次へ」をクリックします。

⑧「追加オプション」が表示されます。「レプリケート元」は「任意のドメインコントローラー」を選択します。「次へ」をクリックします。（なお、既存のドメインコントローラーを選んだ時はエラーが発生しました）

⑨「パス」が表示されます。「次へ」をクリックします。

⑩ 「準備オプション」が表示されます。「次へ」をクリックします。

⑪ 「オプションの確認」が表示されます。「次へ」をクリックします。

⑫「前提条件のチェック」が表示されます。チェックが完了するまで待機します。
チェックに問題がなければ、上記の様に「すべての前提条件のチェックに合格しました。 [インストール] をクリックしてインストールを開始してください。」と表示されます。「インストール」をクリックします。

⑬Active Directory ドメインサービスの構成が完了すると、サーバーは自動的に再起動します。

⑭もう一台の新規DCにも同様の手順を実施します。

◆ 同期の確認
・コマンドプロンプトで「repadmin /replsummary」コマンドを実行します。
以下、実行例。

C:\Users\Administrator.NORA>repadmin /replsummary

レプリケーションの要約開始時刻: 2026-04-12 00:23:27

レプリケーションの要約のためのデータ収集を開始します。

これにはしばらく時間がかかる場合があります:

.......

ソース DSA 最大デルタ失敗/合計 %% エラー

WIN2016DC1 35m:11s 0 / 10 0

WIN2016DC2 35m:11s 0 / 10 0

WIN2022DC1 36m:32s 0 / 10 0

WIN2022DC2 17m:18s 0 / 10 0

宛先 DSA 最大デルタ失敗/合計 %% エラー

WIN2016DC1 27m:15s 0 / 10 0

WIN2016DC2 36m:35s 0 / 10 0

WIN2022DC1 35m:14s 0 / 10 0

WIN2022DC2 04m:05s 0 / 10 0

実行結果から、「失敗/合計」の列で失敗の数 (「/」の左側の数) が0であること、「最大デルタ」

の列で最近複製されたことを確認します。

・コマンドプロンプトで「net share」コマンドを実行します。
以下、実行例。

C:\Users\Administrator.NORA>net share

共有名リソース注釈

-------------------------------------------------------------------------------

C$ C:\ Default share

IPC$ Remote IPC

ADMIN$ C:\Windows Remote Admin

NETLOGON C:\Windows\SYSVOL\sysvol\nora.ac.jp\SCRIPTS

Logon server share

SYSVOL C:\Windows\SYSVOL\sysvol Logon server share

コマンドは正常に終了しました。

実行結果から、「共有名」の列に「NETLOGON」と「SYSVOL」の共有が出力されることを確認

します。

・Powershellで「 Get-CimInstance -Namespace "root\microsoftdfs" -ClassName "DfsrReplicatedFolderInfo"」コマンドレットを実行します。以下、実行例。

C:\Users\Administrator.NORA> Get-CimInstance -Namespace "root\microsoftdfs" -ClassName "DfsrReplicatedFolderInfo"

PS C:\Users\Administrator.NORA> Get-CimInstance -Namespace "root\microsoftdfs" -ClassName "DfsrReplicatedFolderInfo"

CurrentConflictSizeInMb : 0

CurrentStageSizeInMb : 0

LastConflictCleanupTime : 2026/04/12 0:20:39

LastErrorCode : 0

LastErrorMessageId : 0

LastTombstoneCleanupTime : 2026/04/12 0:20:39

MemberGuid : F64AD7D0-49FC-4B3C-9BE0-5657D98E8F26

MemberName : WIN2022DC2

ReplicatedFolderGuid : 6A0FF805-9A20-43F5-821A-B0FB1CB1CA1A

ReplicatedFolderName : SYSVOL Share

ReplicationGroupGuid : 88B86D7B-FB66-4630-955E-9FE5AA0A1DFE

ReplicationGroupName : Domain System Volume
State : 4

PSComputerName :

「ReplicatedFolderName : SYSVOL Share」の「State : 」が「4」となっていることを確認します。

・イベントビューアーの確認。

イベントビューアーを開き、「アプリケーションとサービスログ」-「DFS Replication」イベントログに、DFSRでの初期同期完了を示すID:4604のイベントが記録されていることを確認します。

・「C:\Windows\SYSVOL\domain」フォルダーにテスト用のファイルを作成し、他のDCにファイルが複製されることを確認します。

Windows Server 2016→2022へAD移行➀　ドメイン移行のイメージと移行事前作業

◆既存ドメインのバージョンアップの概要
ドメイン移行に伴い、リプレイスを行うことを仮定とした検証を実施します。
手順のイメージは以下の様になります。

➀nora.ac.jpドメインにWindows Server 2016のWIN2016DC1、WIN2016DC2という二台の既存ドメインコントローラー（以下、DC）が設置されています。

➁既存ドメインにWindows Server 2022の新規DCを二台追加します。

③FSMOを新規DCに転送します。

④既存DCに対してメンバーサーバーへの降格、ワークグループへの変更、ネットワークからの撤去を行います。

⑤（機能レベルが“Windows Server 2012 R2”以前である場合）機能レベルを“Windows Server 2016”に変更します。

◆本検証のネットワーク設定
➀WIN2016DC1
OS:Windows Server 2016
IP:10.0.1.11/24
DNS:127.0.0.1(優先)、10.0.1.12（代替）

➁WIN2016DC2
OS:Windows Server 2016
IP:10.0.1.12/24
DNS:127.0.0.1(優先)、10.0.1.11（代替）

③WIN2022DC1
OS:Windows Server 2022
IP:10.0.1.111/24
DNS:10.0.1.11(優先)、10.0.1.12（代替）

④WIN2022DC2
OS:Windows Server 2022
IP:10.0.1.112/24
DNS:10.0.1.11(優先)、10.0.1.12（代替）

③④のDNSは移行時のみの一時的な設定です。
又、③④のIPアドレスに関しては最終的にそのまま使うか、既存DC➀➁と同じにするか二つのパターンについて別稿で説明します。

◆移行事前作業
⑴既存ドメインのDCのバックアップ
問題が発生した場合に元に戻せるよう、既存のドメインのすべてのDCでバックアップを取得します。 Windows Server 2022 の DCを追加することでスキーマのバージョンアップが行われます。スキーマバージョンも元に戻さなければならない場合に備えて、すべての DC でバックアップを取得します。もし問題が発生し、移行作業開始前の状態に戻す必要がある場合には、すべてのDCをバックアップからリストアします。

⑵ 既存ドメインの確認
Windows 2022 ドメインへの移行を行う前に、既存のWindows 2016ドメインが次の状態であることを確認します。
・ ADやSYSVOLの複製が正常に行われていること
・フォレストの機能レベルが”Windows Server 2008”以降であること
・ SYSVOLの複製方式がDFSRであること

◆ADやSYSVOLの複製の確認
ADやSYSVOLの複製が正常に行われていることを確認するには、各DCで以下の確認を行います。
・「repadmin /replsummary」コマンドを実行。
以下、実行例

C:\Users\Administrator.NORA>repadmin /replsummary

レプリケーションの要約開始時刻: 2026-04-11 00:00:27

レプリケーションの要約のためのデータ収集を開始します。

これにはしばらく時間がかかる場合があります:

.......

ソース DSA 最大デルタ失敗/合計 %% エラー

WIN2016DC1 35m:11s 0 / 10 0

WIN2016DC2 35m:11s 0 / 10 0

宛先 DSA 最大デルタ失敗/合計 %% エラー

WIN2016DC1 27m:15s 0 / 10 0

WIN2016DC2 36m:35s 0 / 10 0

実行結果から、「失敗/合計」の列で失敗の数 (「/」の左側の数) が0であること、「最大デルタ」の列で最近複製されたことを確認します。

・「net share」コマンドを実行。
以下、実行例

C:\Users\Administrator.NORA>net share

共有名リソース注釈

-------------------------------------------------------------------------------

C$ C:\ Default share

IPC$ Remote IPC

ADMIN$ C:\Windows Remote Admin

NETLOGON C:\Windows\SYSVOL\sysvol\nora.ac.jp\SCRIPTS

Logon server share

SYSVOL C:\Windows\SYSVOL\sysvol Logon server share

コマンドは正常に終了しました。

実行結果から、「共有名」の列に「NETLOGON」と「SYSVOL」の共有が出力されることを確認します。

・「C:\Windows\SYSVOL\domain」フォルダー (もしくは、SYSVOL の複製方式を FRS から DFSR に移行した環境では、「C:\Windows\SYSVOL_DFSR\domain」フォルダー) にテスト用のファイルを作成し、他のDCにファイルが複製されることを確認します。

上記のいずれかで問題が見られる場合は、しばらく時間をあけたり、OS 再起動を行ったりした後に再度ご確認ください。その後も問題が見られる場合は、以降の手順に進む前に複製の問題を解消します。

◆ドメイン／フォレスト機能レベルの確認

Windows 2022ドメインへの移行は、既存ドメインのフォレスト機能レベルが”Windows Server 2008”以上である必要があります。

既存のWindows 2016ドメインのドメイン機能レベル、フォレスト機能レベルが”Windows Server 2003”である場合は、ドメイン機能レベル、フォレスト機能レベルを”Windows Server 2008”以上に上げます。

手順は以下になります。

➀スタートボタンより「Windows管理ツール」＞「Active Directory ドメインと信頼関係」をクリックします。

➁「Active Directory ドメインと信頼関係」が表示されます。「<ドメイン名>」で右クリックし、「ドメインの機能レベルの昇格」をクリックします。

③ 「ドメインの機能レベルの昇格」が表示されます。「利用可能なドメインの機能レベルを選択してください」で、「Windows Server 2008」以上を選択します。（上記は「Windows Server 2008」なので問題ないのですが、練習の為「Windows Server 2016」を選択しています。）

④「上げる」をクリックします。

⑤上記メッセージが表示されます。「OK」をクリックします。

⑥上記メッセージが表示されます。「OK」をクリックします。

⑦再度➁を実行し、「現在のドメインの機能レベル」が「Windows Server 2008」以上になっていることを確認します。

⑧「Active Directory ドメインと信頼関係<dc名>」で右クリックし、「フォレストの機能レベルの昇格」をクリックします。

⑨「フォレストの機能レベルの昇格」が表示されます。「利用可能なフォレストの機能レベルを選択してください」で、「Windows Server 2008」以上を選択します。（右では「Windows Server 2016」を選択しています。）

⑩「上げる」をクリックします。

⑪上記メッセージが表示されます。「OK」をクリックします。

⑫上記メッセージが表示されます。「OK」をクリックします。

⑬ 再度、手順⑧を実行し、「現在のフォレストの機能レベル」が「Windows Server 2008」以上になっていることを確認します。「OK」または「キャンセル」をクリックします。

◆SYSVOL複製方式の確認

既存ドメインが過去にWindows 2003ドメインから移行し、SYSVOL複製方式をFRSからDFSRに変更していない場合は、既存ドメインではFRSが使用されています。

Windows Server 2019、Windows Server 2022はFRSをサポートしていません。既存ドメインのSYSVOL複製方式がFRSである場合は、Windows 2022ドメインへの移行を行う前にFRSからDFSRに変更する必要があります。

現在のDFSR移行のグローバル状態を取得します。

管理者としてコマンドプロンプトを起動し、次のコマンドを実行します。

dfsrmig /GetGlobalState

上記の様に「削除済み」と表示された場合はすでにDFSRが使用されているため、DFSRへの移行は不要です。

◆Hyper-V等仮想環境使用時の新規DC側ホストの設定
　Hyper-V等の仮想環境でADを構築すると、イベントビューアーで以下の様な警告が発生することがあります。

　上記警告はホストの物理マシンのHDDがSATAで、仮想マシンの仮想HDDもSATAで、デバイスの書き込みキャッシュが有効だと発生します。以下の様にデバイスマネージャーの仮想ディスクから確認できます。

「デバイスマネージャー」＞「ディスク　ドライブ」＞「（ディスク名）」を右クリックし、「プロパティ」

「ポリシー」タブで「デバイスの書き込みキャッシュを有効にする」のチェックを外し、「OK」をクリックすれば、デバイスの書き込みキャッシュが無効になります。

ただし、この操作は仮想マシン上ではエラーになるので、ホストの物理マシン上で行います。

既存環境の場合は上記操作は事前に検討が必要ですが、新規の物理ホストでSATAの使用せざるを得ない場合や、仮想マシンインストール用の物理ディスクを分割されている場合等は、上記キャッシュを無効にするのが望ましいかもしれません。

Pacemaker④　DRBD

今回はPacemakerの公式サイトを参考にDRBDを用いたストレージの複製を行います。

◆ DRBDパッケージをインストールします。

[root@pcmk-1 ~]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

[root@pcmk-1 ~]# dnf install -y https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm

[root@pcmk-1 ~]# dnf install -y kmod-drbd9x drbd9x-utils

[root@pcmk-1 ~]# dnf install -y policycoreutils-python-utils

DRBDはデフォルトのSELinuxセキュリティポリシーでは動作できません。ここでは単純にDRBDプロセスをSELinuxから除外します。

[root@pcmk-1 ~]# semanage permissive -a drbd_t

別ノード（pcmk-2）もここまでのインストール及び設定を行います。同じなので内容は省略します。

DRBDはポート7789を使用するように設定しますので、各ホストからはそのポートを許可します。

[root@pcmk-1 ~]# firewall-cmd --permanent --add-rich-rule='rule family="ipv4" \

source address="10.0.1.102" port port="7789" protocol="tcp" accept'

success

[root@pcmk-1 ~]# firewall-cmd --reload

success

[root@pcmk-2 ~]# firewall-cmd --permanent --add-rich-rule='rule family="ipv4" \

source address="10.0.1.101" port port="7789" protocol="tcp" accept'

success

[root@pcmk-2 ~]# firewall-cmd --reload

success

◆DRBD用のディスクボリュームを割り当てる

DRBDは各ノードに独自のブロックデバイスが必要です。これは物理ディスクパーティションや論理ボリューム次のようになります。

公式ドキュメントによれば、512MiBの論理ボリュームを使用しますが、これは単一のHTMLファイルとGFS2メタデータには十分すぎるほどだそうです。

[root@pcmk-1 ~]# vgs

VG #PV #LV #SN Attr VSize VFree

almalinux_basic 2 2 0 wz--n- 19.99g 1020.00m

[root@pcmk-1 ~]# lvcreate --name drbd-demo --size 512M almalinux_basic

Logical volume "drbd-demo" created.

[root@pcmk-1 ~]# lvs

LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert

drbd-demo almalinux_basic -wi-a----- 512.00m

root almalinux_basic -wi-ao---- <17.00g

swap almalinux_basic -wi-ao---- 2.00g

＊余談ですが本来、VGの「almalinux_basic」の部分はインストール時のhostnameが正しいのですが、今回は雛型マシン「almalinux_basic」をVirtualBOXのコピー機能で複製した仮想マシンの為、VGがそのまま残っています。本来のVGは「pcmk-1」となり、次に行うノード、pcmk-2のVGは「pcmk-2」となりますが、以下の例も同じ雛型マシンからコピーした為、VGが同じ「almalinux_basic」になっています。VGの名前を変更するとマシンが起動しなくなったため、止むを得ずそのまま使っていますが、VGが別ノードと重なっても正常に動作確認出来た為、VGはそのまま使用します。

同じサイズで2つ目のノードを繰り返します

[root@pcmk-1 ~]# ssh pcmk-2 -- lvcreate --name drbd-demo --size 512M almalinux_basic

Logical volume "drbd-demo" created.

念の為に2つ目のノードで確認

[root@pcmk-2 ~]# lvs

LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert

drbd-demo almalinux_basic -wi-a----- 512.00m

root almalinux_basic -wi-ao---- <17.00g

swap almalinux_basic -wi-ao---- 2.00g

◆DRBDの設定

DRBD構成を構築するための一連のコマンドは存在しないため、単純に両方のノードでこのサンプル構成を実行します。

[root@pcmk-1 ~]#cat <<END >/etc/drbd.d/wwwdata.res

resource "wwwdata" {

device minor 1;

meta-disk internal;

net {

protocol C;

allow-two-primaries yes;

fencing resource-and-stonith;

verify-alg sha1;

}

handlers {

fence-peer "/usr/lib/drbd/crm-fence-peer.9.sh";

unfence-peer "/usr/lib/drbd/crm-unfence-peer.9.sh";

}

on "pcmk-1" {

disk "/dev/almalinux_basic/drbd-demo";

node-id 0;

}

on "pcmk-2" {

disk "/dev/almalinux_basic/drbd-demo";

node-id 1;

}

connection {

host "pcmk-1" address 10.0.1.101:7789;

host "pcmk-2" address 10.0.1.102:7789;

}

END

別ノード（pcmk-2）も上記と同じファイルを作成します。

◆DRBDの初期化

設定が整ったことで、DRBDを稼働させることができます。

これらのコマンドはDRBDリソースのローカルメタデータを作成します。 DRBDカーネルモジュールが読み込まれていることを確認し、DRBDリソースを呼び出します。 1つのノードで実行します。

[root@pcmk-1 ~]# drbdadm create-md wwwdata

initializing activity log

initializing bitmap (16 KB) to all zero

Writing meta data...

New drbd meta data block successfully created.

[root@pcmk-1 ~]# modprobe drbd

[root@pcmk-1 ~]# drbdadm up wwwdata

--== Thank you for participating in the global usage survey ==--

The server's response is:

you are the 3769th user to install this version

このノードでのDRBDの状況を確認します。

[root@pcmk-1 ~]# drbdadm status

wwwdata role:Secondary

disk:Inconsistent open:no

pcmk-2 connection:Connecting

別ノード（pcmk-2）も同様の操作を行います。

[root@pcmk-2 ~]# drbdadm create-md wwwdata

--== Thank you for participating in the global usage survey ==--

The server's response is:

[root@pcmk-2 ~]# modprobe drbd

[root@pcmk-2 ~]# drbdadm up wwwdata

結果が表示されない？

再びpcmk-1でDRBDの状況を確認すると、2つのDRBDノードが正しく通信していることが確認出来ます。

[root@pcmk-1 ~]# drbdadm status

wwwdata role:Secondary

disk:Inconsistent open:no

pcmk-2 role:Secondary

peer-disk:Inconsistent

データの整合性を保つために、DRBDにどのノードを指定すべきかを伝える必要があります。

pcmk-1からみてwwwdata role:Secondaryに成っている為、このノードをPrimaryにするには以下のコマンドを実行します。

[root@pcmk-1 ~]# drbdadm primary --force wwwdata

暫くして状況を確認すると以下の様に表示されます。

[root@pcmk-1 ~]# drbdadm status

wwwdata role:Primary

disk:UpToDate open:no

pcmk-2 role:Secondary

peer-disk:UpToDate

別ノードから確認すると以下の様になります。

[root@pcmk-2 ~]# drbdadm status

wwwdata role:Secondary

disk:UpToDate open:no

pcmk-1 role:Primary

peer-disk:UpToDate

最終的には以下の表示になります

[root@pcmk-1 ~]# drbdadm status

wwwdata role:Primary

disk:UpToDate open:no

pcmk-2 role:Secondary

peer-disk:UpToDate

[root@pcmk-2 ~]# drbdadm status

wwwdata role:Secondary

disk:UpToDate open:no

pcmk-1 role:Primary

peer-disk:UpToDate

◆DRBDディスクの入力

プライマリの役割を持つノード（pcmk-1）上のDRBDデバイス上でファイルシステムを作成します。

[root@pcmk-1 ~]# mkfs.xfs /dev/drbd1

meta-data=/dev/drbd1 isize=512 agcount=4, agsize=32765 blks

= sectsz=512 attr=2, projid32bit=1

= crc=1 finobt=1, sparse=1, rmapbt=0

= reflink=1 bigtime=1 inobtcount=1 nrext64=0

data = bsize=4096 blocks=131059, imaxpct=25

= sunit=0 swidth=0 blks

naming =version 2 bsize=4096 ascii-ci=0, ftype=1

log =internal log bsize=4096 blocks=16384, version=2

= sectsz=512 sunit=0 blks, lazy-count=1

realtime =none extsz=4096 blocks=0, rtextents=0

[root@pcmk-1 ~]# mount /dev/drbd1 /mnt

念の為に正常にマウントが行われたのか確認します。

[root@pcmk-1 ~]# df -h

ファイルシスサイズ使用残り使用% マウント位置

devtmpfs 4.0M 0 4.0M 0% /dev

tmpfs 854M 33M 822M 4% /dev/shm

tmpfs 342M 5.4M 337M 2% /run

/dev/mapper/almalinux_basic-root 17G 5.1G 12G 30% /

/dev/sda1 960M 389M 572M 41% /boot

tmpfs 171M 52K 171M 1% /run/user/42

tmpfs 171M 36K 171M 1% /run/user/0

/dev/drbd1 448M 29M 419M 7% /mnt

新規作成したファイルシステムのマウントを確認出来たらウェブドキュメントを埋め込みます・

[root@pcmk-1 ~]# cat <<-END >/mnt/index.html

<html>

</html>

END

[root@pcmk-1 ~]# cat /mnt/index.html

<html>

</html>

ウェブドキュメントのルートと同じSELinuxポリシーを適用後、アンマウントします。

[root@pcmk-1 ~]# chcon -R --reference=/var/www/html /mnt

[root@pcmk-1 ~]# umount /dev/drbd1

◆DRBDデバイス用クラスタの設定

便利な機能の一つは、複数の変更をキューに入れられることです。ファイルに変更をまとめてコミットします。これを行うには、まずCIBの現在の生のXML設定でファイルに入力します。

[root@pcmk-1 ~]# pcs cluster cib drbd_cfg

DRBDデバイス用のクラスタリソースを作成し、両方のノードで同時にリソースを実行できるように追加のクローンリソースを作成します。

[root@pcmk-1 ~]# pcs -f drbd_cfg resource create WebData ocf:linbit:drbd \

drbd_resource=wwwdata op monitor interval=29s role=Promoted \

monitor interval=31s role=Unpromoted

[root@pcmk-1 ~]# pcs -f drbd_cfg resource promotable WebData \

promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1 \

notify=true

Deprecation Warning: configuring meta attributes without specifying the 'meta' keyword is deprecated and will be removed in a future release

[root@pcmk-1 ~]# pcs resource status

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

* WebSite (ocf:heartbeat:apache): Started pcmk-1

[root@pcmk-1 ~]# pcs resource config

Resource: ClusterIP (class=ocf provider=heartbeat type=IPaddr2)

Attributes: ClusterIP-instance_attributes

cidr_netmask=24

ip=10.0.1.103

Operations:

monitor: ClusterIP-monitor-interval-30s

interval=30s

start: ClusterIP-start-interval-0s

interval=0s timeout=20s

stop: ClusterIP-stop-interval-0s

interval=0s timeout=20s

Resource: WebSite (class=ocf provider=heartbeat type=apache)

Attributes: WebSite-instance_attributes

configfile=/etc/httpd/conf/httpd.conf

statusurl=http://localhost/server-status

Operations:

monitor: WebSite-monitor-interval-1min

interval=1min

start: WebSite-start-interval-0s

interval=0s timeout=40s

stop: WebSite-stop-interval-0s

interval=0s timeout=60s

すべての変更に納得したら、コミットできます。ファイルをライブCIBにプッシュすることで、すべて一度に処理します。

[root@pcmk-1 ~]# pcs cluster cib-push drbd_cfg --config

CIB updated

なお、以下のように上記のアップデートを一度で行うこともできます。

# pcs resource create WebData ocf:linbit:drbd \

drbd_resource=wwwdata op monitor interval=29s role=Promoted \

monitor interval=31s role=Unpromoted \

promotable promoted-max=1 promoted-node-max=1 clone-max=2 \

clone-node-max=1 notify=true

クラスターが新しい構成で何をしたのか見てみます。

[root@pcmk-1 ~]# pcs resource status

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

* WebSite (ocf:heartbeat:apache): Started pcmk-1

* Clone Set: WebData-clone [WebData] (promotable):

* Promoted: [ pcmk-1 ]

* Unpromoted: [ pcmk-2 ]

DRBDのデバイスがPromoted: [ pcmk-1 ]がプライマリ、Unpromoted: [ pcmk-2 ]がセカンダリとして動作している事が分かります。

[root@pcmk-1 ~]# pcs resource config

Resource: ClusterIP (class=ocf provider=heartbeat type=IPaddr2)

Attributes: ClusterIP-instance_attributes

cidr_netmask=24

ip=10.0.1.103

Operations:

monitor: ClusterIP-monitor-interval-30s

interval=30s

start: ClusterIP-start-interval-0s

interval=0s timeout=20s

stop: ClusterIP-stop-interval-0s

interval=0s timeout=20s

Resource: WebSite (class=ocf provider=heartbeat type=apache)

Attributes: WebSite-instance_attributes

configfile=/etc/httpd/conf/httpd.conf

statusurl=http://localhost/server-status

Operations:

monitor: WebSite-monitor-interval-1min

interval=1min

start: WebSite-start-interval-0s

interval=0s timeout=40s

stop: WebSite-stop-interval-0s

interval=0s timeout=60s

Clone: WebData-clone

Meta Attributes: WebData-clone-meta_attributes

clone-max=2

clone-node-max=1

notify=true

promotable=true

promoted-max=1

promoted-node-max=1

Resource: WebData (class=ocf provider=linbit type=drbd)

Attributes: WebData-instance_attributes

drbd_resource=wwwdata

Operations:

demote: WebData-demote-interval-0s

interval=0s timeout=90

monitor: WebData-monitor-interval-29s

interval=29s role=Promoted

monitor: WebData-monitor-interval-31s

interval=31s role=Unpromoted

notify: WebData-notify-interval-0s

interval=0s timeout=90

promote: WebData-promote-interval-0s

interval=0s timeout=90

reload: WebData-reload-interval-0s

interval=0s timeout=30

start: WebData-start-interval-0s

interval=0s timeout=240

stop: WebData-stop-interval-0s

interval=0s timeout=100

◆ファイルシステム用クラスタの設定

動作するDRBDデバイスができたので、そのファイルシステムをマウントする必要があります。

[root@pcmk-1 ~]# pcs cluster cib fs_cfg

[root@pcmk-1 ~]# pcs -f fs_cfg resource create WebFS Filesystem \

device="/dev/drbd1" directory="/var/www/html" fstype="xfs"

Assumed agent name 'ocf:heartbeat:Filesystem' (deduced from 'Filesystem')

[root@pcmk-1 ~]# pcs -f fs_cfg constraint colocation add \

WebFS with Promoted WebData-clone

[root@pcmk-1 ~]# pcs -f fs_cfg constraint order \

promote WebData-clone then start WebFS

Adding WebData-clone WebFS (kind: Mandatory) (Options: first-action=promote then-action=start)

また、Apacheも同じ環境で動かす必要があるとクラスターに伝える必要があります。Apacheが開始する前に、マシンがファイルシステムとして機能しなければなりません。

[root@pcmk-1 ~]# pcs -f fs_cfg constraint colocation add WebSite with WebFS

[root@pcmk-1 ~]# pcs -f fs_cfg constraint order WebFS then WebSite

Adding WebFS WebSite (kind: Mandatory) (Options: first-action=start then-action=start)

更新された設定を確認します。

[root@pcmk-1 ~]# pcs -f fs_cfg constraint

Location Constraints:

resource 'WebSite' prefers node 'pcmk-2' with score 50

Colocation Constraints:

resource 'WebSite' with resource 'ClusterIP'

score=INFINITY

Started resource 'WebFS' with Promoted resource 'WebData-clone'

score=INFINITY

resource 'WebSite' with resource 'WebFS'

score=INFINITY

Order Constraints:

start resource 'ClusterIP' then start resource 'WebSite'

promote resource 'WebData-clone' then start resource 'WebFS'

start resource 'WebFS' then start resource 'WebSite'

新しい設定を確認した後、アップロードして、クラスターがそれを実行します。

[root@pcmk-1 ~]# pcs cluster cib-push fs_cfg --config

CIB updated

[root@pcmk-1 ~]# pcs resource status

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

* WebSite (ocf:heartbeat:apache): Started pcmk-1

* Clone Set: WebData-clone [WebData] (promotable):

* Promoted: [ pcmk-1 ]

* Unpromoted: [ pcmk-2 ]

* WebFS (ocf:heartbeat:Filesystem): Started pcmk-1

[root@pcmk-1 ~]# pcs resource config

Resource: ClusterIP (class=ocf provider=heartbeat type=IPaddr2)

Attributes: ClusterIP-instance_attributes

cidr_netmask=24

ip=10.0.1.103

Operations:

monitor: ClusterIP-monitor-interval-30s

interval=30s

start: ClusterIP-start-interval-0s

interval=0s timeout=20s

stop: ClusterIP-stop-interval-0s

interval=0s timeout=20s

Resource: WebSite (class=ocf provider=heartbeat type=apache)

Attributes: WebSite-instance_attributes

configfile=/etc/httpd/conf/httpd.conf

statusurl=http://localhost/server-status

Operations:

monitor: WebSite-monitor-interval-1min

interval=1min

start: WebSite-start-interval-0s

interval=0s timeout=40s

stop: WebSite-stop-interval-0s

interval=0s timeout=60s

Resource: WebFS (class=ocf provider=heartbeat type=Filesystem)

Attributes: WebFS-instance_attributes

device=/dev/drbd1

directory=/var/www/html

fstype=xfs

Operations:

monitor: WebFS-monitor-interval-20s

interval=20s timeout=40s

start: WebFS-start-interval-0s

interval=0s timeout=60s

stop: WebFS-stop-interval-0s

interval=0s timeout=60s

Clone: WebData-clone

Meta Attributes: WebData-clone-meta_attributes

clone-max=2

clone-node-max=1

notify=true

promotable=true

promoted-max=1

promoted-node-max=1

Resource: WebData (class=ocf provider=linbit type=drbd)

Attributes: WebData-instance_attributes

drbd_resource=wwwdata

Operations:

demote: WebData-demote-interval-0s

interval=0s timeout=90

monitor: WebData-monitor-interval-29s

interval=29s role=Promoted

monitor: WebData-monitor-interval-31s

interval=31s role=Unpromoted

notify: WebData-notify-interval-0s

interval=0s timeout=90

promote: WebData-promote-interval-0s

interval=0s timeout=90

reload: WebData-reload-interval-0s

interval=0s timeout=30

start: WebData-start-interval-0s

interval=0s timeout=240

stop: WebData-stop-interval-0s

interval=0s timeout=100

◆クラスターフェイルオーバーのテスト

クラスターのサービスをstopしてテストしていましたが別のサービスも稼働している為、ノード故障を安全にシミュレートするにはstandbyを実行します。

[root@pcmk-1 ~]# pcs node standby pcmk-1

[root@pcmk-1 ~]# pcs status

Cluster name: mycluster

WARNINGS:

warning: Support for the Master role is deprecated and will be removed in a future release. Use Promoted instead.

Warnings found during check: config not valid

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Sat Apr 4 18:53:17 2026 on pcmk-1

* Last change: Sat Apr 4 18:53:13 2026 by root via root on pcmk-2

* 2 nodes configured

* 5 resource instances configured

Node List:

* Node pcmk-1: standby

* Online: [ pcmk-2 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-2

* WebSite (ocf:heartbeat:apache): Started pcmk-2

* Clone Set: WebData-clone [WebData] (promotable):

* Promoted: [ pcmk-2 ]

* Stopped: [ pcmk-1 ]

* WebFS (ocf:heartbeat:Filesystem): Started pcmk-2

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

リソースが全てpcmk-2に移動したことを確認出来たので、ノードのスタンバイ状態を戻します。

[root@pcmk-1 ~]# pcs node unstandby pcmk-1

[root@pcmk-1 ~]# pcs status

Cluster name: mycluster

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Sat Apr 4 18:56:06 2026 on pcmk-1

* Last change: Sat Apr 4 18:56:04 2026 by root via root on pcmk-2

* 2 nodes configured

* 5 resource instances configured

Node List:

* Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-2

* WebSite (ocf:heartbeat:apache): Started pcmk-2

* Clone Set: WebData-clone [WebData] (promotable):

* Promoted: [ pcmk-2 ]

* Unpromoted: [ pcmk-1 ]

* WebFS (ocf:heartbeat:Filesystem): Started pcmk-2

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

クラスターは以前行ったリソースの固定設定のため、そのままになります。

pcmk-1にリソースを戻すにはpcmk-2も同様に一旦スタンバイ状態にします。

[root@pcmk-1 ~]# pcs node standby pcmk-2

暫く経ってから確認すると以下の状態になります。

[root@pcmk-1 ~]# pcs status

Cluster name: mycluster

WARNINGS:

warning: Support for the Master role is deprecated and will be removed in a future release. Use Promoted instead.

Warnings found during check: config not valid

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Sat Apr 4 19:00:07 2026 on pcmk-1

* Last change: Sat Apr 4 18:59:42 2026 by root via root on pcmk-1

* 2 nodes configured

* 5 resource instances configured

Node List:

* Node pcmk-2: standby

* Online: [ pcmk-1 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

* WebSite (ocf:heartbeat:apache): Started pcmk-1

* Clone Set: WebData-clone [WebData] (promotable):

* Promoted: [ pcmk-1 ]

* Stopped: [ pcmk-2 ]

* WebFS (ocf:heartbeat:Filesystem): Started pcmk-1

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

pcmk-1にリソースが移動したことを確認後、pcmk-2のスタンバイを解除します。

[root@pcmk-1 ~]# pcs node unstandby pcmk-2

暫く経った後、正常稼働を確認します。

[root@pcmk-1 ~]# pcs status

Cluster name: mycluster

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Sat Apr 4 19:03:18 2026 on pcmk-1

* Last change: Sat Apr 4 19:02:17 2026 by root via root on pcmk-1

* 2 nodes configured

* 5 resource instances configured

Node List:

* Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

* WebSite (ocf:heartbeat:apache): Started pcmk-1

* Clone Set: WebData-clone [WebData] (promotable):

* Promoted: [ pcmk-1 ]

* Unpromoted: [ pcmk-2 ]

* WebFS (ocf:heartbeat:Filesystem): Started pcmk-1

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

◆参考
Clusters from Scratch » 8. Replicate Storage Using DRBD
DRBD9.0 LINBIT

Pacemaker③　Apache HTTP Serverをクラスタサービスとして追加

今回は公式サイトを参考にApacheをクラスタサービスとして追加してみます。

◆Apacheをインストールする

[root@pcmk-1 ~]# dnf install -y httpd wget

[root@pcmk-1 ~]# firewall-cmd --permanent --add-service=http

success

[root@pcmk-1 ~]# firewall-cmd --reload

success

◆ウェブサイト文書の作成

[root@pcmk-1 ~]# cat <<-END >/var/www/html/index.html

<html>

<body>My Test Site - $(hostname)</body>

</html>

END

[root@pcmk-1 ~]# cat /var/www/html/index.html

<html>

</html>

Apache Status URLを有効にする

ペースメーカーはリソースエージェントを使って状態を監視します

[root@pcmk-1 ~]# cat <<-END >/etc/httpd/conf.d/status.conf

SetHandler server-status

Require local

</Location>

END

別ノード（pcmk-2）にもここまでの流れと同じ事を実施します。

（上記と同じなので内容は省略します）

◆クラスタの設定

[root@pcmk-1 ~]# pcs resource create WebSite ocf:heartbeat:apache \

configfile=/etc/httpd/conf/httpd.conf \

statusurl="http://localhost/server-status" \

op monitor interval=1min

デフォルトでは、すべてのリソースの開始、停止、監視、およびその他の操作は20秒です。

ここではグローバルオペレーションのタイムアウトのデフォルトを240秒に調整します

[root@pcmk-1 ~]# pcs resource op defaults

[root@pcmk-1 ~]# pcs resource op defaults update timeout=240s

Warning: Defaults do not apply to resources which override them with their own defined values

[root@pcmk-1 ~]# pcs resource op defaults

Meta Attrs: op_defaults-meta_attributes

timeout=240s

暫くたった後、クラスターの状態を確認します。

[root@pcmk-1 ~]# pcs status

Cluster name: mycluster

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-1 (version 2.1.10-1.1.el9_7-5693eaeee) - MIXED-VERSION partition with quorum

* Last updated: Wed Apr 1 03:25:22 2026 on pcmk-1

* Last change: Wed Apr 1 03:23:34 2026 by root via root on pcmk-1

* 2 nodes configured

* 2 resource instances configured

Node List:

* Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

* WebSite (ocf:heartbeat:apache): Started pcmk-2

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

「WebSite」の行で「(ocf:heartbeat:apache):」とapache起動が確認できますが、「Started pcmk-2」となっています。

なお、もしリソース起動が失敗したら以下のコマンドで原因を探ります

wget -O - http://localhost/server-status

Not FoundForbidden<Location /server-status>

この様に表示された場合、ブロックが正しいか確認します。

◇リソースが同じホスト上で実行されることを確実にする

Pacemakerは、1台のマシンの負荷を軽減するために、一般的に設定済みのリソースをクラスタノード間に分散させます。

しかし、クラスタに対して、同じホストの2つのリソースが関連していて、実行する必要があることを伝えることができます。

これを実現するために、リソースを起動するノードのスコア値を設定し、同居制約を用います。

スコア値の優先度は以下になります。

-INFINITY < 負の値 < 0 < 正の値 < INFINITY

[root@pcmk-1 ~]# pcs constraint colocation add WebSite with ClusterIP INFINITY

[root@pcmk-1 ~]# pcs constraint

Colocation Constraints:

resource 'WebSite' with resource 'ClusterIP'

score=INFINITY

[root@pcmk-1 ~]# pcs status

Cluster name: mycluster

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Wed Apr 1 03:34:50 2026 on pcmk-1

* Last change: Wed Apr 1 03:34:20 2026 by root via root on pcmk-1

* 2 nodes configured

* 2 resource instances configured

Node List:

* Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

* WebSite (ocf:heartbeat:apache): Started pcmk-1

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

上記の様に、WebSiteのStartedがpcmk-1になったことが確認出来ます。

◇リソースの開始と停止を順序通りに行う

[root@pcmk-1 ~]# pcs constraint order ClusterIP then WebSite

Adding ClusterIP WebSite (kind: Mandatory) (Options: first-action=start then-action=start)

[root@pcmk-1 ~]# pcs constraint

Colocation Constraints:

resource 'WebSite' with resource 'ClusterIP'

score=INFINITY

Order Constraints:

start resource 'ClusterIP' then start resource 'WebSite'

◇あるノードを他より優先する

[root@pcmk-1 ~]# pcs constraint location WebSite prefers pcmk-2=50

[root@pcmk-1 ~]# pcs constraint

Location Constraints:

resource 'WebSite' prefers node 'pcmk-2' with score 50

Colocation Constraints:

resource 'WebSite' with resource 'ClusterIP'

score=INFINITY

Order Constraints:

start resource 'ClusterIP' then start resource 'WebSite'

[root@pcmk-1 ~]# pcs status

Cluster name: mycluster

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Wed Apr 1 03:52:00 2026 on pcmk-1

* Last change: Wed Apr 1 03:51:22 2026 by root via root on pcmk-1

* 2 nodes configured

* 2 resource instances configured

Node List:

* Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

* WebSite (ocf:heartbeat:apache): Started pcmk-1

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

現在のスコア値を確認するには以下のコマンドを入力します。

[root@pcmk-1 ~]# crm_simulate -sL

Current cluster status:

* Node List:

* Online: [ pcmk-1 pcmk-2 ]

* Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

* WebSite (ocf:heartbeat:apache): Started pcmk-1

Assignment Scores:

* pcmk__primitive_assign: ClusterIP allocation score on pcmk-1: 200

* pcmk__primitive_assign: ClusterIP allocation score on pcmk-2: 50

* pcmk__primitive_assign: WebSite allocation score on pcmk-1: 100

* pcmk__primitive_assign: WebSite allocation score on pcmk-2: -INFINITY

上記の場合、スコア値からpcmk-1の方がClusterIP及び WebSiteリソースが優先されます。

◇資源を手動で移動する

上記ではWebSiteのリソースがpcmk-1でしたが、これをpcmk-2に移動してみます。

[root@pcmk-1 ~]# pcs resource move WebSite pcmk-2

Location constraint to move resource 'WebSite' has been created

Waiting for the cluster to apply configuration changes...

Location constraint created to move resource 'WebSite' has been removed

Waiting for the cluster to apply configuration changes...

resource 'WebSite' is running on node 'pcmk-2'

[root@pcmk-1 ~]# pcs constraint

Location Constraints:

resource 'WebSite' prefers node 'pcmk-2' with score 50

Colocation Constraints:

resource 'WebSite' with resource 'ClusterIP'

score=INFINITY

Order Constraints:

start resource 'ClusterIP' then start resource 'WebSite'

[root@pcmk-1 ~]# pcs status

Cluster name: mycluster

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Wed Apr 1 04:01:04 2026 on pcmk-1

* Last change: Wed Apr 1 03:59:59 2026 by root via root on pcmk-1

* 2 nodes configured

* 2 resource instances configured

Node List:

* Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-2

* WebSite (ocf:heartbeat:apache): Started pcmk-2

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

◆参考
Clusters from Scratch » 7. Add Apache HTTP Server as a Cluster Service

Pacemaker➁　Active/Passive Clusterの作成

前回の構成にActive/Passive Clusterの作成します。

◇リソースの追加

[root@pcmk-1 ~]# pcs resource create ClusterIP ocf:heartbeat:IPaddr2 \

ip=10.0.1.103 cidr_netmask=24 op monitor interval=30s

「ocf:heartbeat:IPaddr2」は追加したい３つのリソースを伝えています。

最初のフィールド(上記ではocf)はリソースの基準となるもの

2つ目のフィールド（上記ではheartbeat）はプロバイダーと呼ばれ現在OCFリソースのみでサポートされています。

3つ目のフィールド（上記ではIPaddr2）はリソースエージェントの名前。

フィールドごとのリソースについて詳細を見て行きます。
最初のフィールドのリソース標準のリストを取得するには以下のコマンドを入力します。

[root@pcmk-1 ~]# pcs resource standards

lsb

ocf

service

systemd

2つ目のフィールドのプロバイダーのリソースのリストを取得するには以下のコマンドを入力します。

[root@pcmk-1 ~]# pcs resource providers

heartbeat

openstack

pacemaker

3つ目のフィールドの利用可能な全てのリソースエージェントを取得するには以下のコマンドを入力します。

root@pcmk-1 ~]# pcs resource agents ocf:heartbeat

apache

conntrackd

corosync-qnetd

（中略）

IPaddr2

（略）

システム上で利用可能なすべてのリソースエージェントをリストアップしたい場合は、以下のコマンドを入力します。

[root@pcmk-1 ~]# pcs resource list

ocf:heartbeat:CTDB - CTDB Resource Agent

ocf:heartbeat:Delay - Waits for a defined timespan

ocf:heartbeat:Dummy - Example stateless resource agent

ocf:heartbeat:Filesystem - Manages filesystem mounts

ocf:heartbeat:IPaddr2 - Manages virtual IPv4 and IPv6 addresses (Linux specific

version)

（略）

「Full List of Resources」の「ClusterIP (ocf:heartbeat:IPaddr2)」が追加されている事を確認します。

[root@pcmk-1 ~]# pcs status

Cluster name: mycluster

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Wed Apr 1 01:46:45 2026 on pcmk-1

* Last change: Wed Apr 1 01:34:06 2026 by root via root on pcmk-1

* 2 nodes configured

* 1 resource instance configured

Node List:

* Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-1

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

リソースが実行されているノードでIPアドレスが追加されているのを確認します。

以下の場合、「enp0s8」の行に「inet 10.0.1.103/24」が追加されています。

[root@pcmk-1 ~]# ip -o addr show

1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever

1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever

2: enp0s3 inet 192.168.128.101/24 brd 192.168.128.255 scope global noprefixroute enp0s3\ valid_lft forever preferred_lft forever

2: enp0s3 inet6 2400:2200:5be:5f91:a00:27ff:fec5:4ceb/64 scope global dynamic mngtmpaddr \ valid_lft 86208sec preferred_lft 14208sec

2: enp0s3 inet6 fe80::a00:27ff:fec5:4ceb/64 scope link \ valid_lft forever preferred_lft forever

3: enp0s8 inet 10.0.1.101/24 brd 10.0.1.255 scope global noprefixroute enp0s8\ valid_lft forever preferred_lft forever

3: enp0s8 inet 10.0.1.103/24 brd 10.0.1.255 scope global secondary enp0s8\ valid_lft forever preferred_lft forever

3: enp0s8 inet6 fe80::a00:27ff:fe16:428/64 scope link \ valid_lft forever preferred_lft forever

◇フェイルオーバーを実行する

高可用性を確認する為に、リソース実行中のマシンを止めてフェイルオーバーをトリガーします。

[root@pcmk-1 ~]# pcs cluster stop pcmk-1

pcmk-1: Stopping Cluster (pacemaker)...

pcmk-1: Stopping Cluster (corosync)...

稼働していない事を確認します。

[root@pcmk-1 ~]# pcs status

Error: error running crm_mon, is pacemaker running?

crm_mon: Connection to cluster failed: Connection refused

別のノードでクラスタ状態を確認します。

[root@pcmk-2 ~]# pcs status

Cluster name: mycluster

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Wed Apr 1 01:59:53 2026 on pcmk-2

* Last change: Wed Apr 1 01:34:06 2026 by root via root on pcmk-1

* 2 nodes configured

* 1 resource instance configured

Node List:

* Online: [ pcmk-2 ]

* OFFLINE: [ pcmk-1 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-2

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

上記の様にフェイルオーバーが起きたことを確認できます。

次に止めたノードを再起動して、暫くしてからクラスタの状態を確認します。

[root@pcmk-1 ~]# pcs cluster start pcmk-1

pcmk-1: Starting Cluster...

[root@pcmk-2 ~]# pcs status

Cluster name: mycluster

Cluster Summary:

* Stack: corosync (Pacemaker is running)

* Current DC: pcmk-2 (version 2.1.10-1.1.el9_7-5693eaeee) - partition with quorum

* Last updated: Wed Apr 1 02:07:12 2026 on pcmk-2

* Last change: Wed Apr 1 01:34:06 2026 by root via root on pcmk-1

* 2 nodes configured

* 1 resource instance configured

Node List:

* Online: [ pcmk-1 pcmk-2 ]

Full List of Resources:

* ClusterIP (ocf:heartbeat:IPaddr2): Started pcmk-2

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

ノードリストでマシンが2台ともOnlineになっていることが確認出来ます。

逆のノードでも同じことを試してみます。

（内容省略）

◇回復後のリソース移動を防ぐ

AlmaLinux 9では、クラスタのセットアッププロセスが自動的に行われますデフォルトのリソース粘着度スコア

[root@pcmk-1 ~]# pcs resource defaults

Meta Attrs: build-resource-defaults

resource-stickiness=1

以下の例ではデフォルトのリソースの固定度を100に上げています

[root@pcmk-1 ~]# pcs resource defaults update resource-stickiness=100

Warning: Defaults do not apply to resources which override them with their own defined values

[root@pcmk-1 ~]# pcs resource defaults

Meta Attrs: build-resource-defaults

resource-stickiness=100

ブランクがあるインフラエンジニアの備忘録

ローカル用パッケージリポジトリサーバーの構築

Windows Server 2016→2022へAD移行⑤ ドメイン/フォレストの機能レベルの変更

Windows Server 2016→2022へAD移行④続き IPアドレスの変更

Windows Server 2016→2022へAD移行④ 既存DCに対してメンバーサーバーへの降格、ワークグループへの変更、 ネットワークからの撤去

Windows Server 2016→2022へAD移行③ FSMOの転送

Windows Server 2016→2022へAD移行➁ Windows Server 2022DC の追加

Windows Server 2016→2022へAD移行➀ ドメイン移行のイメージと移行事前作業

Pacemaker④ DRBD

Pacemaker③ Apache HTTP Serverをクラスタサービスとして追加

Pacemaker➁ Active/Passive Clusterの作成

Windows Server 2016→2022へAD移行⑤　ドメイン/フォレストの機能レベルの変更

Windows Server 2016→2022へAD移行④続き　IPアドレスの変更

Windows Server 2016→2022へAD移行④　既存DCに対してメンバーサーバーへの降格、ワークグループへの変更、ネットワークからの撤去

Windows Server 2016→2022へAD移行③　FSMOの転送

Windows Server 2016→2022へAD移行➁　Windows Server 2022DC の追加

Windows Server 2016→2022へAD移行➀　ドメイン移行のイメージと移行事前作業

Pacemaker④　DRBD

Pacemaker③　Apache HTTP Serverをクラスタサービスとして追加

Pacemaker➁　Active/Passive Clusterの作成