パブリッククラウドプラットフォームへの Red Hat Enterprise Linux 7 のデプロイメント
Red Hat Enterprise Linux のカスタムイメージの作成およびパブリッククラウドプラットフォーム用の Red Hat High Availability クラスターの設定
概要
第1章 Microsoft Azure での仮想マシンとして Red Hat Enterprise Linux 7 イメージをデプロイ
Azure に Red Hat Enterprise Linux (RHEL) 7 イメージをデプロイするオプションは複数あります。本章では、イメージを選択するオプションを説明し、ホストシステムおよび仮想マシンのシステム要件の一覧を紹介します。本章では、ISO イメージからカスタム VM を作成し、そのイメージを Azure にアップロードして、Azure 仮想インスタンスを起動する手順も説明します。
ISO イメージからカスタム仮想マシンを作成することは可能ですが、Red Hat Image Builder 製品を使用して、特定のクラウドプロバイダーで使用するようにカスタマイズされたイメージを作成することを推奨します。詳細は Image Builder ガイド を参照してください。
この章では、Azure のドキュメントを参照している箇所が多数あります。多くの手順に関する詳細は、参照している Azure ドキュメントを確認してください。
Azure でセキュアに使用できる Red Hat 製品の一覧は、Red Hat on Microsoft Azure を参照してください。
前提条件
- Red Hat カスタマーポータル のアカウントに登録している。
- Microsoft Azure アカウントに登録している。
- Red Hat Cloud Access プログラムでサブスクリプションが有効になっている。Red Hat Cloud Access プログラムでは、Red Hat サブスクリプションを、物理システムまたはオンプレミスシステムから、Red Hat のフルサポートのある Azure へ移動できます。
関連情報
1.1. Azure での Red Hat Enterprise Linux イメージオプション
以下の表には、イメージの選択肢を記載し、イメージオプションの相違点を示しています。
表1.1 イメージオプション
イメージオプション | サブスクリプション | サンプルシナリオ | 留意事項 |
---|---|---|---|
Red Hat Gold Image のデプロイを選択する | 既存の Red Hat サブスクリプションを活用する | Red Hat Cloud Access プログラム を使用してサブスクリプションを有効にし、Azure で Red Hat Gold Image を選択します。Gold イメージおよび Azure でイメージにアクセスする方法は、Red Hat Cloud Access Reference Guide を参照してください。 | このサブスクリプションには、Red Hat のコストが含まれていますが、他のインスタンスのコストは、Microsoft 社に支払うことになります。 Red Hat Gold Image は、既存の Red Hat サブスクリプションを活用するため、クラウドアクセスイメージと呼ばれています。Red Hat は、クラウドアクセスイメージを直接サポートします。 |
Azure に移動するカスタムイメージをデプロイすることを選択する | 既存の Red Hat サブスクリプションを活用する | Red Hat Cloud Access プログラム を使用してサブスクリプションを有効にし、カスタムイメージをアップロードし、サブスクリプションを割り当てます。 | このサブスクリプションには、Red Hat のコストが含まれていますが、他のインスタンスのコストは、Microsoft 社に支払うことになります。 Azure に移行するカスタムイメージは、既存の Red Hat サブスクリプションを活用するため、クラウドアクセスイメージと呼ばれています。Red Hat は、クラウドアクセスイメージを直接サポートします。 |
RHEL を含む既存の Azure イメージをデプロイすることを選択する | Azure イメージには、Red Hat 製品が含まれる | Azure コンソールを使用して仮想マシンを作成する際に RHEL イメージを選択するか、Azure Marketplace から仮想マシンを選択します。 | 従量課金モデルで 1 時間ごとに Microsoft 社に支払います。このようなイメージはオンデマンドと呼ばれています。 Azure は、サポート契約に基づいてオンデマンドイメージのサポートを提供します。 Red Hat は、イメージの更新を提供します。Azure により、Red Hat Update Infrastructure (RHUI) から更新を利用できるようにします。 |
Red Hat Image Builder を使用して、Azure 用のカスタムイメージを作成できます。詳細は Image Builder ガイド を参照してください。
本章の残りの部分には、Red Hat Enterprise Linux カスタムイメージに関連する情報および手順が記載されています。
1.2. ベースイメージの理解
本セクションでは、事前設定されたベースイメージおよびその設定を使用する方法を説明します。
1.2.1. カスタムベースイメージの使用
仮想マシンを手動で設定するには、ベース (スタートアップ) 仮想マシンイメージで開始します。ベース仮想マシンイメージを作成したら、設定設定を変更して、仮想マシンがクラウドで動作するために必要なパッケージを追加できます。イメージのアップロード後に、特定のアプリケーションに追加の設定変更を行うことができます。
RHEL の Hyper-V クラウドイメージを準備するには、Hyper-V Manager から RHEL 7 仮想マシンの準備 を参照してください。
1.2.2. 必要なシステムパッケージ
本章の手順では、Red Hat Enterprise Linux を実行しているホストシステムを使用していることを前提としています。この手順を正常に行うには、ホストシステムに以下のパッケージをインストールする必要があります。
表1.2 システムパッケージ
パッケージ | 詳細 | コマンド |
---|---|---|
qemu-kvm | このパッケージは、ユーザーレベルの KVM エミュレーターを使用し、ホストとゲスト仮想マシン間の通信を容易にします。 |
|
qemu-img | このパッケージは、ゲスト仮想マシンのディスク管理を提供します。qemu-img パッケージは qemu-kvm パッケージの依存関係としてインストールされます。 | |
libvirt | このパッケージは、ハイパーバイザーおよびホストシステムと対話するためにサーバーおよびホスト側のライブラリーを提供し、ライブラリー呼び出しの処理、仮想マシンの管理およびハイパーバイザーの制御を行う libvirtd デーモンも提供します。 |
表1.3 その他の仮想化パッケージ
パッケージ | 詳細 | コマンド |
---|---|---|
virt-install |
このパッケージは、コマンドラインからの仮想マシンを作成するために |
|
libvirt-python | このパッケージは、Python プログラミング言語で書かれているアプリケーションが libvirt API で提供されるインターフェイスを使用できるようにするモジュールが含まれています。 | |
virt-manager | このパッケージには、仮想マシンマネージャー (VMM) と呼ばれる virt-manager ツールが含まれます。VMM は、仮想マシンを管理するためのグラフィカルツールです。管理 API として libvirt-client ライブラリーを使用します。 | |
libvirt-client |
このパッケージは、libvirt サーバーにアクセスするためのクライアント側の API とライブラリーを提供します。libvirt-client パッケージには、コマンドラインまたは特別な仮想化シェルから仮想マシンとハイパーバイザーを管理および制御する |
関連情報
1.2.3. Azure VM 設定
Azure 仮想マシンには、以下の設定設定が必要です。設定の一部は、最初の仮想マシン作成時に有効になります。Azure 用の仮想マシンイメージのプロビジョニング時に、その他の設定が設定されます。エラーが発生する場合に、手順を進める時に、必要に応じてこの手順を再度参照してください。
表1.4 仮想マシンの設定設定
設定 | 推奨事項 |
---|---|
ssh |
Azure VM へのリモートアクセスを確立するには、 |
dhcp | プライマリー仮想アダプターは、dhcp (IPv4 のみ) 用に設定する必要があります。 |
swap 領域 | 専用 swap ファイルまたは swap パーティションは作成しないでください。Windows Azure Linux Agent (WALinuxAgent) を使用してスワップ領域を設定できます。 |
NIC | プライマリー仮想ネットワークアダプター用に virtio を選択します。 |
暗号化 | カスタムイメージで RHEL 7.5 以降を実行している場合には、Azure で完全なディスク暗号化に Network Bound Disk Encryption (NBDE) を使用します。NBDE は、RHEL 7.5 以降でのみサポートされます。 |
1.2.4. ISO イメージからのベースイメージの作成
以下の手順は、カスタム ISO イメージ作成の手順と初期設定の要件を示しています。イメージを設定したら、このイメージを、追加の仮想マシンインスタンスを作成するためのテンプレートとして使用できます。
手順
- Red Hat カスタマーポータル から最新の Red Hat Enterprise Linux 7 Binary DVD ISO イメージをダウンロードします。
- 仮想化用のホストマシンを有効にしていることを確認します。詳細および手順は、仮想化スタートガイド を参照してください。
基本的な Red Hat Enterprise Linux 仮想マシンを作成し、起動します。手順は、仮想化コマンドラインインターフェイスの使用 を参照してください。
コマンドラインを使用して仮想マシンを作成する場合は、デフォルトのメモリーと CPU を仮想マシンの容量に設定するようにしてください。仮想ネットワークインターフェイスを virtio に設定します。
基本的なコマンドラインの例を以下に示します。
virt-install --name isotest --memory 2048 --vcpus 2 --disk size=8,bus=virtio --location rhel-7.0-x86_64-dvd.iso --os-variant=rhel7.0
VMM アプリケーションを使用して仮想マシンを作成する場合は、仮想マシンマネージャーの使用 の手順を行います。以下の点に注意してください。
- 仮想マシンをすぐに起動 は選択しないでください。
- メモリー と ストレージのサイズ を、希望の設定に変更します。
- インストールを開始する前に、仮想ネットワークインターフェイス設定 で モデル を virtio に変更し、vCPUs を仮想マシンの容量設定に変更していることを確認します。
以下の追加インストールの選択と変更を確認します。
- 標準 RHEL オプションを使用して 最小インストール を選択します。
インストール先 で、カスタムストレージ設定 を選択します。以下の設定情報を使用して選択を行います。
- /boot で、500 MB 以上であることを確認してください。
- ファイルシステムの場合は、boot パーティションおよび root パーティションの両方に xfs、ext4、ext3 のいずれかを使用します。
- swap 領域を削除します。swap 領域は、WALinuxAgent により Azure 内の物理ブレードサーバー上で設定されます。
- インストール概要 画面で、ネットワークおよびホスト名 を選択します。イーサネット を オン に切り替えます。
インストール開始時に、以下を行います。
-
root
のパスワードを作成します。 - 管理者ユーザーアカウントを作成します。
-
- インストールが完了したら、仮想マシンを再起動して root アカウントにログインします。
-
root
でログインしたら、イメージを設定できます。
1.3. Microsoft Azure のベースイメージの設定
ベースイメージには、Azure で RHEL 7 仮想マシンイメージとして機能するための設定変更が必要です。以下のセクションでは、Azure で必要な追加の設定変更を説明します。
1.3.1. Hyper-V デバイスドライバーのインストール
Microsoft は、Linux Integration Services (LIS) for Hyper-V パッケージの一部として、ネットワークおよびストレージデバイスのドライバーを提供しています。Hyper-V デバイスドライバーを Azure 仮想マシンとしてプロビジョニングする前に、仮想マシンイメージへのインストールが必要になる場合があります。lsinitrd | grep hv
コマンドを使用して、ドライバーがインストールされていることを確認します。
手順
以下の
grep
コマンドを実行して、必要な Hyper-V デバイスドライバーがインストールされているかどうかを確認します。# lsinitrd | grep hv
以下の例では、必要なドライバーがすべてインストールされています。
# lsinitrd | grep hv drwxr-xr-x 2 root root 0 Aug 12 14:21 usr/lib/modules/3.10.0-932.el7.x86_64/kernel/drivers/hv -rw-r--r-- 1 root root 31272 Aug 11 08:45 usr/lib/modules/3.10.0-932.el7.x86_64/kernel/drivers/hv/hv_vmbus.ko.xz -rw-r--r-- 1 root root 25132 Aug 11 08:46 usr/lib/modules/3.10.0-932.el7.x86_64/kernel/drivers/net/hyperv/hv_netvsc.ko.xz -rw-r--r-- 1 root root 9796 Aug 11 08:45 usr/lib/modules/3.10.0-932.el7.x86_64/kernel/drivers/scsi/hv_storvsc.ko.xz
すべてのドライバーがインストールされていない場合は、残りの手順を完了してください。
注記hv_vmbus
ドライバーは、すでにこの環境に追加されている可能性があります。このドライバーが存在する場合でも、仮想マシンで次の手順を実行してください。-
/etc/hv.conf.d
にhv.conf
という名前のファイルを作成します。 以下のドライバーパラメーターを
dracut.conf
ファイルに追加します。add_drivers+=" hv_vmbus " add_drivers+=" hv_netvsc " add_drivers+=" hv_storvsc "
注記引用符の前後に空白に注意してください (例:
add_drivers+=" hv_VMBus ")
。これにより、環境内にその他の Hyper-V ドライバーが存在している場合に、一意のドライバーが読み込まれます。initramfs
イメージを再生成します。# dracut -f -v --regenerate-all
検証手順
- マシンを再起動します。
-
lsinitrd | grep hv
コマンドを実行して、ドライバーがインストールされていることを確認します。
1.3.2. 追加の設定設定の変更
仮想マシンを Azure で動作するには、さらなる設定変更が必要です。追加の変更を行うには、以下の手順を行います。
手順
- 必要な場合は、仮想マシンの電源を入れます。
仮想マシンを登録し、Red Hat Enterprise Linux 7 リポジトリーを有効にします。
# subscription-manager register --auto-attach
cloud-init (存在する場合) の停止および削除
cloud-init
サービスを停止します。# systemctl stop cloud-init
cloud-init
ソフトウェアを削除します。# yum remove cloud-init
その他の仮想マシン変更の完了
/etc/ssh/sshd_config
ファイルを編集し、パスワード認証を有効にします。PasswordAuthentication yes
一般的なホスト名を設定してください。
# hostnamectl set-hostname localhost.localdomain
/etc/sysconfig/network-scripts/ifcfg-eth0
ファイルを編集 (または作成) します。以下のパラメーターのみを使用してください。注記ifcfg-eth0
ファイルは、RHEL 7 DVD ISO イメージには存在しないため、作成する必要があります。DEVICE="eth0" ONBOOT="yes" BOOTPROTO="dhcp" TYPE="Ethernet" USERCTL="yes" PEERDNS="yes" IPV6INIT="no"
すべての永続的なネットワークデバイスルールがある場合は削除します。
# rm -f /etc/udev/rules.d/70-persistent-net.rules # rm -f /etc/udev/rules.d/75-persistent-net-generator.rules # rm -f /etc/udev/rules.d/80-net-name-slot-rules
ssh
が自動的に起動するように設定します。# systemctl enable sshd # systemctl is-enabled sshd
カーネルブートパラメーターを変更します。
-
/etc/default/grub
ファイルのGRUB_CMDLINE_LINUX
行の先頭にcrashkernel=256M
を追加します。crashkernel=auto
が存在する場合は、crashkernel=256M
に変更します。 次の行がない場合は、
GRUB_CMDLINE_LINUX
行の末尾に追加します。earlyprintk=ttyS0 console=ttyS0 rootdelay=300
以下のオプションが存在する場合は削除します。
rhgb quiet
-
grub.cfg
ファイルを再生成します。# grub2-mkconfig -o /boot/grub2/grub.cfg
Windows Azure Linux Agent (WALLinuxAgent) をインストールして有効にします。
# yum install WALinuxAgent -y # systemctl enable waagent
注記No package
WALinuxAgent
availableというエラーメッセージが表示された場合は、rhel-7-server-extras-rpms
リポジトリーをインストールします。再度インストールを試行する前に、# subscription-manager repos --enable=rhel-7-server-extras-rpms
コマンドを実行します。/etc/waagent.conf
で以下の行を編集して、プロビジョニングされた仮想マシン用にスワップ領域を設定します。プロビジョニングされた仮想マシンに適した swap 領域を設定します。Provisioning.DeleteRootPassword=n ResourceDisk.Filesystem=ext4 ResourceDisk.EnableSwap=y ResourceDisk.SwapSizeMB=2048
プロビジョニングの準備
Red Hat Subscription Manager から仮想マシンの登録を解除します。
# subscription-manager unregister
既存のプロビジョニングの詳細をクリーンアップして、Azure プロビジョニング用に仮想マシンを準備します。Azure は、仮想マシンを Azure に再プロビジョニングします。このコマンドは、データ損失の警告を生成しますが、これは正常です。
# waagent -force -deprovision
シェル履歴をクリーンアップし、仮想マシンをシャットダウンします。
# export HISTSIZE=0 # poweroff
1.4. イメージの固定 VHD 形式への変換
すべての Microsoft Azure 仮想マシンイメージは、固定 VHD
形式である必要があります。イメージは、VHD に変換する前に 1 MB の境界で調整する必要があります。このセクションでは、必要に応じて、イメージを、qcow2
形式から固定の VHD
形式に変換して配置する方法を説明します。イメージを変換したら、Azure にアップロードできます。
手順
イメージを
qcow2
形式からraw
形式に変換します。$ qemu-img convert -f qcow2 -O raw <image-name>.qcow2 <image-name>.raw
以下のコンテンツを使用してシェルスクリプトを作成します。
#!/bin/bash MB=$((1024 * 1024)) size=$(qemu-img info -f raw --output json "$1" | gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}') rounded_size=$((($size/$MB + 1) * $MB)) if [ $(($size % $MB)) -eq 0 ] then echo "Your image is already aligned. You do not need to resize." exit 1 fi echo "rounded size = $rounded_size" export rounded_size
スクリプトを実行します。この例では
align.sh
という名前を使用します。$ sh align.sh <image-xxx>.raw
- Your image is already aligned. You do not need to resize. (イメージはすでに整列しています。サイズを変更する必要はありません。)と表示されたら、次の手順に進みます。
- 値が表示されると、イメージは調整されません。イメージの調整 セクションの手順を使用してイメージのサイズを変更してから、次の手順に進むようにしてください。
次のコマンドを使用して、ファイルを固定
VHD
形式に変換します。サンプルでは qemu-img バージョン 2.12.0 を使用します。
$ qemu-img convert -f raw -o subformat=fixed,force_size -O vpc <image-xxx>.raw <image.xxx>.vhd
変換されると、
VHD
ファイルは Azure にアップロードする準備が整います。
イメージのアライメント
以下の手順は、raw
ファイルの整列が行われていない場合にのみ行います。
検証スクリプトの実行時に表示される丸め値を使用して、
raw
ファイルのサイズを変更します。$ qemu-img resize -f raw <image-xxx>.raw <rounded-value>
raw
イメージファイルをVHD
形式に変換します。サンプルでは qemu-img バージョン 2.12.0 を使用します。
$ qemu-img convert -f raw -o subformat=fixed,force_size -O vpc <image-xxx>.raw <image.xxx>.vhd
変換されると、
VHD
ファイルは Azure にアップロードする準備が整います。
1.5. Azure CLI のインストール
ホストマシンで Azure コマンドラインインターフェイス (Azure CLI 2.1) をインストールするには、以下の手順を実行します。Azure CLI 2.1 は、Azure で仮想マシンを作成し、管理する Python ベースのユーティリティーです。
前提条件
- Azure CLI を使用するための Microsoft Azure のアカウントがある。
- Azure CLI をインストールするために Python 3.x がインストールされている。
手順
Microsoft リポジトリーキーをインポートします。
$ sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
ローカル Azure CLI リポジトリーエントリーを作成します。
$ sudo sh -c 'echo -e "[azure-cli]\nname=Azure CLI\nbaseurl=https://packages.microsoft.com/yumrepos/azure-cli\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/azure-cli.repo'
yum
パッケージインデックスを更新します。$ yum check-update
Python バージョンを確認 (
python --version
) し、必要に応じて Python 3.x をインストールします。$ sudo yum install python3
Azure CLI をインストールします。
$ sudo yum install -y azure-cli
Azure CLI を実行します。
$ az
1.6. Azure でのリソースの作成
VHD
ファイルをアップロードして Azure イメージを作成する前に、以下の手順に従って、必要な Azure リソースを作成します。
手順
次のコマンドを実行して、システムを Azure で認証し、ログインします。
$ az login
注記お使いの環境でブラウザーが利用可能な場合、CLI は Azure サインインページでブラウザーを開きます。詳細およびオプションは、Sign in with Azure CLI を参照してください。
Azure リージョンにリソースグループを作成します。
$ az group create --name <resource-group> --location <azure-region>
以下に例を示します。
$ az group create --name azrhelclirsgrp --location southcentralus { "id": "/subscriptions//resourceGroups/azrhelclirsgrp", "location": "southcentralus", "managedBy": null, "name": "azrhelclirsgrp", "properties": { "provisioningState": "Succeeded" }, "tags": null }
ストレージアカウントを作成します。有効な SKU 値の詳細は、SKU Types を参照してください。
$ az storage account create -l <azure-region> -n <storage-account-name> -g <resource-group> --sku <sku_type>
以下に例を示します。
$ az storage account create -l southcentralus -n azrhelclistact -g azrhelclirsgrp --sku Standard_LRS { "accessTier": null, "creationTime": "2017-04-05T19:10:29.855470+00:00", "customDomain": null, "encryption": null, "id": "/subscriptions//resourceGroups/azrhelclirsgrp/providers/Microsoft.Storage/storageAccounts/azrhelclistact", "kind": "StorageV2", "lastGeoFailoverTime": null, "location": "southcentralus", "name": "azrhelclistact", "primaryEndpoints": { "blob": "https://azrhelclistact.blob.core.windows.net/", "file": "https://azrhelclistact.file.core.windows.net/", "queue": "https://azrhelclistact.queue.core.windows.net/", "table": "https://azrhelclistact.table.core.windows.net/" }, "primaryLocation": "southcentralus", "provisioningState": "Succeeded", "resourceGroup": "azrhelclirsgrp", "secondaryEndpoints": null, "secondaryLocation": null, "sku": { "name": "Standard_LRS", "tier": "Standard" }, "statusOfPrimary": "available", "statusOfSecondary": null, "tags": {}, "type": "Microsoft.Storage/storageAccounts" }
ストレージアカウントの接続文字列を取得します。
$ az storage account show-connection-string -n <storage-account-name> -g <resource-group>
以下に例を示します。
[clouduser@localhost]$ az storage account show-connection-string -n azrhelclistact -g azrhelclirsgrp { "connectionString": "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=azrhelclistact;AccountKey=NreGk...==" }
接続文字列をコピーし、次のコマンドに貼り付けて、接続文字列をエクスポートします。この文字列は、システムをストレージアカウントに接続します。
$ export AZURE_STORAGE_CONNECTION_STRING="<storage-connection-string>"
以下に例を示します。
[clouduser@localhost]$ export AZURE_STORAGE_CONNECTION_STRING="DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=azrhelclistact;AccountKey=NreGk...=="
ストレージコンテナーを作成します。
$ az storage container create -n <container-name>
以下に例を示します。
[clouduser@localhost]$ az storage container create -n azrhelclistcont { "created": true }
仮想ネットワークを作成します。
$ az network vnet create -g <resource group> --name <vnet-name> --subnet-name <subnet-name>
以下に例を示します。
[clouduser@localhost]$ az network vnet create --resource-group azrhelclirsgrp --name azrhelclivnet1 --subnet-name azrhelclisubnet1 { "newVNet": { "addressSpace": { "addressPrefixes": [ "10.0.0.0/16" ] }, "dhcpOptions": { "dnsServers": [] }, "etag": "W/\"\"", "id": "/subscriptions//resourceGroups/azrhelclirsgrp/providers/Microsoft.Network/virtualNetworks/azrhelclivnet1", "location": "southcentralus", "name": "azrhelclivnet1", "provisioningState": "Succeeded", "resourceGroup": "azrhelclirsgrp", "resourceGuid": "0f25efee-e2a6-4abe-a4e9-817061ee1e79", "subnets": [ { "addressPrefix": "10.0.0.0/24", "etag": "W/\"\"", "id": "/subscriptions//resourceGroups/azrhelclirsgrp/providers/Microsoft.Network/virtualNetworks/azrhelclivnet1/subnets/azrhelclisubnet1", "ipConfigurations": null, "name": "azrhelclisubnet1", "networkSecurityGroup": null, "provisioningState": "Succeeded", "resourceGroup": "azrhelclirsgrp", "resourceNavigationLinks": null, "routeTable": null } ], "tags": {}, "type": "Microsoft.Network/virtualNetworks", "virtualNetworkPeerings": null } }
1.7. Azure イメージのアップロードおよび作成
以下の手順に従って、VHD
ファイルをコンテナーにアップロードし、Azure カスタムイメージを作成します。
システムを再起動すると、エクスポートしたストレージ接続文字列は維持されません。以下の手順でいずれかのコマンドが失敗した場合は、再び接続文字列をエクスポートしてください。
手順
ストレージコンテナーに
VHD
ファイルをアップロードします。ストレージコンテナーの一覧を表示するには、az storage container list
を実行します。$ az storage blob upload --account-name <storage-account-name> --container-name <container-name> --type page --file <path-to-vhd> --name <image-name>.vhd
以下に例を示します。
$ az storage blob upload --account-name azrhelclistact --container-name azrhelclistcont --type page --file rhel-image-7.vhd --name rhel-image-7.vhd Percent complete: %100.0
アップロードした
VHD
ファイルの URL を以下の手順で取得します。$ az storage blob url -c <container-name> -n <image-name>.vhd
以下に例を示します。
$ az storage blob url -c azrhelclistcont -n rhel-image-7.vhd "https://azrhelclistact.blob.core.windows.net/azrhelclistcont/rhel-image-7.vhd"
Azure カスタムイメージを作成します。
$ az image create -n <image-name> -g <resource-group> -l <azure-region> --source <URL> --os-type linux
注記仮想マシンのハイパーバイザーのデフォルトの生成は V1 です。必要に応じて、
--hyper-v-generation V2
オプションを使用して V2 ハイパーバイザーの世代を指定できます。第 2 世代の仮想マシンは、UEFI ベースのブートアーキテクチャーを使用します。第 2 世代の仮想マシンの詳細は Support for generation 2 VMs on Azure を参照してください。このコマンドは、Only blobs formatted as VHDs can be imported(VHD としてフォーマットされたブロブのみがインポート可能) というエラーを返す場合があります。 このエラーは、イメージが
VHD
に変換される前に最も近い 1 MB の境界に合致していないことを意味します。以下に例を示します。
$ az image create -n rhel7 -g azrhelclirsgrp2 -l southcentralus --source https://azrhelclistact.blob.core.windows.net/azrhelclistcont/rhel-image-7.vhd --os-type linux
1.8. Azure での仮想マシンの作成および起動
以下の手順では、イメージから管理ディスクの Azure 仮想マシンを作成するための最小限のコマンドオプションを説明します。追加オプションは、az vm create を参照してください。
手順
次のコマンドを実行して仮想マシンを作成します。
$ az vm create -g <resource-group> -l <azure-region> -n <vm-name> --vnet-name <vnet-name> --subnet <subnet-name> --size Standard_A2 --os-disk-name <simple-name> --admin-username <administrator-name> --generate-ssh-keys --image <path-to-image>
注記--generate-ssh-keys
オプションを指定すると、秘密鍵と公開鍵のペアが作成されます。秘密鍵ファイルと公開鍵ファイルが、システムの~/.ssh
に作成されます。公開鍵は、--admin-username
オプションで指定したユーザーの仮想マシン上のauthorized_keys
ファイルに追加されます。詳細は、その他の認証方法 を参照してください。たとえば、以下のようになります。
[clouduser@localhost]$ az vm create -g azrhelclirsgrp2 -l southcentralus -n rhel-azure-vm-1 --vnet-name azrhelclivnet1 --subnet azrhelclisubnet1 --size Standard_A2 --os-disk-name vm-1-osdisk --admin-username clouduser --generate-ssh-keys --image rhel7 { "fqdns": "", "id": "/subscriptions//resourceGroups/azrhelclirsgrp/providers/Microsoft.Compute/virtualMachines/rhel-azure-vm-1", "location": "southcentralus", "macAddress": "", "powerState": "VM running", "privateIpAddress": "10.0.0.4", "publicIpAddress": "<public-IP-address>", "resourceGroup": "azrhelclirsgrp2"
SSH セッションを開始し、仮想マシンにログインします。
[clouduser@localhost]$ ssh -i /home/clouduser/.ssh/id_rsa clouduser@<public-IP-address>. The authenticity of host, '<public-IP-address>' can't be established. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '<public-IP-address>' (ECDSA) to the list of known hosts.
ユーザープロンプトが表示された場合は、Azure VM が正常にデプロイされます。
これで、Azure ポータルにアクセスして、リソースの監査ログとプロパティーを確認できます。このポータルでは、仮想マシンを直接管理できます。複数の仮想マシンを管理している場合は、Azure CLI を使用する必要があります。Azure CLI では、Azure 内のリソースに強力なインターフェイスを利用できます。Microsoft Azure で仮想マシンを管理するために使用するコマンドの詳細は、CLI で az --help
コマンドを実行するか、Azure CLI コマンドリファレンス を参照してください。
1.9. その他認証方法
セキュリティーを強化するために推奨されますが、Azure 生成のキーペアを使用する必要はありません。以下の例は、SSH 認証用の 2 つの方法を示しています。
例 1: 次のコマンドオプションは、公開鍵ファイルを生成せずに新しい仮想マシンをプロビジョニングします。これにより、SSH は、パスワードを使用した SSH 認証を許可できます。
$ az vm create -g <resource-group> -l <azure-region> -n <vm-name> --vnet-name <vnet-name> --subnet <subnet-name> --size Standard_A2 --os-disk-name <simple-name> --authentication-type password --admin-username <administrator-name> --admin-password <ssh-password> --image <path-to-image>
$ ssh <admin-username>@<public-ip-address>
例 2: このコマンドオプションにより、新しい Azure 仮想マシンがプロビジョニングされ、既存の公開鍵ファイルを使用した SSH 認証が許可されます。
$ az vm create -g <resource-group> -l <azure-region> -n <vm-name> --vnet-name <vnet-name> --subnet <subnet-name> --size Standard_A2 --os-disk-name <simple-name> --admin-username <administrator-name> --ssh-key-value <path-to-existing-ssh-key> --image <path-to-image>
$ ssh -i <path-to-existing-ssh-key> <admin-username>@<public-ip-address>
1.10. Red Hat サブスクリプションの割り当て
Red Hat Cloud Access プログラムで有効になっているサブスクリプションを割り当てるには、以下の手順を行います。
前提条件
サブスクリプションが有効になっている。
手順
システムを登録します。
subscription-manager register --auto-attach
サブスクリプションを割り当てます。
- アクティベーションキーを使用して、サブスクリプションを割り当てることができます。カスタマーポータルのアクティベーションキーを作成する を参照してください。
- または、サブスクリプションプール (Pool ID) の ID を使用してサブスクリプションを手動で割り当てることができます。コマンドラインでのサブスクリプションのアタッチと削除 を参照してください。
第2章 Microsoft Azure での Red Hat High Availability クラスターの設定
Red Hat は、Red Hat Enterprise Linux(RHEL)7.4 以降で高可用性 (HA) をサポートします。本章では、仮想マシンインスタンスをクラスターノードとして使用して Microsoft Azure に Red Hat HA クラスターを設定するための情報および手順を説明します。本章の手順では、Azure 用のカスタムイメージを作成していることを前提としています。クラスターに使用する RHEL 7 イメージを取得するオプションは複数あります。Azure のイメージオプションに関する詳細は、Azure における Red Hat Enterprise Linux Image オプション を参照してください。
本章では、Azure の環境設定の前提条件を説明します。環境を設定したら、Azure 仮想マシンインスタンスを作成および設定できます。
本章では、個別の仮想マシンノードを Azure の HA ノードのクラスターに変換する HA クラスターの作成に固有の手順も説明します。これには、各クラスターノードに高可用性パッケージおよびエージェントをインストールし、フェンシングを設定し、Azure ネットワークリソースエージェントをインストールする手順が含まれます。
本章では、Microsoft Azure のドキュメントを参照している箇所が多数あります。多くの手順に関する詳細は、参照している Azure ドキュメントを確認してください。
前提条件
- Azure コマンドラインインターフェイス (CLI) をインストールする必要があります。詳細は、Azure CLI のインストール を参照してください。
- Red Hat Cloud Access プログラム でサブスクリプションを有効にします。Red Hat Cloud Access プログラムでは、Red Hat サブスクリプションを、物理システムまたはオンプレミスシステムから、Red Hat のフルサポートのある Azure へ移動できます。
関連情報
2.1. Azure でのリソースの作成
可用性セットを作成するには、以下の手順を実施します。本章の後続のタスクを完了するには、これらのリソースが必要です。
手順
可用性セットを作成します。すべてのクラスターノードは同じ可用性セットにある必要があります。
$ az vm availability-set create --name _MyAvailabilitySet_ --resource-group _MyResourceGroup_
以下に例を示します。
[clouduser@localhost]$ az vm availability-set create --name rhelha-avset1 --resource-group azrhelclirsgrp { "additionalProperties": {}, "id": "/subscriptions/.../resourceGroups/azrhelclirsgrp/providers/Microsoft.Compute/availabilitySets/rhelha-avset1", "location": "southcentralus", "name": “rhelha-avset1", "platformFaultDomainCount": 2, "platformUpdateDomainCount": 5, ...omitted
2.2. Azure Active Directory アプリケーションの作成
Azure Active Directory アプリケーションを作成するには、以下の手順を行います。Azure AD アプリケーションは、クラスター内のすべてのノードに対する HA 操作のアクセスを承認し、自動化します。
前提条件
Azure コマンドラインインターフェイス (CLI) をインストールする必要があります。
手順
- Microsoft Azure サブスクリプションの管理者または所有者であることを確認します。Azure AD アプリケーションを作成するには、この承認が必要です。
Azure アカウントにログインします。
$ az login
次のコマンドを実行して Azure AD アプリケーションを作成します。独自のパスワードを使用するには、
--password
オプションをコマンドに追加します。強固なパスワードを作成してください。$ az ad sp create-for-rbac --name _FencingApplicationName_ --role owner --scopes "/subscriptions/_SubscriptionID_/resourceGroups/_MyResourseGroup_"
以下に例を示します。
[clouduser@localhost ~] $ az ad sp create-for-rbac --name FencingApp --role owner --scopes "/subscriptions/2586c64b-xxxxxx-xxxxxxx-xxxxxxx/resourceGroups/azrhelclirsgrp" Retrying role assignment creation: 1/36 Retrying role assignment creation: 2/36 Retrying role assignment creation: 3/36 { "appId": "1a3dfe06-df55-42ad-937b-326d1c211739", "displayName": "FencingApp", "name": "http://FencingApp", "password": "43a603f0-64bb-482e-800d-402efe5f3d47", "tenant": "77ecefb6-xxxxxxxxxx-xxxxxxx-757a69cb9485" }
続行する前に、以下の情報を保存します。フェンスエージェントを設定するには、この情報が必要です。
- Azure AD アプリケーション ID
- Azure AD アプリケーションのパスワード
- テナント ID
- Microsoft Azure サブスクリプション ID
2.3. Red Hat HA パッケージおよびエージェントのインストール
すべてのノードで以下の手順を実行します。
手順
仮想マシンを Red Hat に登録します。
$ sudo -i # subscription-manager register --auto-attach
すべてのリポジトリーを無効にします。
# subscription-manager repos --disable=*
RHEL 7 Server リポジトリーおよび RHEL 7 Server HA リポジトリーを有効にします。
# subscription-manager repos --enable=rhel-7-server-rpms # subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
すべてのパッケージを更新します。
# yum update -y
カーネルを更新したら再起動します。
# reboot
pcs
、pacemaker
、fence agent
、resource agent
およびnmap-ncat
をインストールします。# yum install -y pcs pacemaker fence-agents-azure-arm resource-agents nmap-ncat
2.4. HA サービスの設定
すべてのノードで以下の手順を実行します。
手順
ユーザー
hacluster
は、前のセクションのpcs
およびpacemaker
のインストール時に作成されました。すべてのクラスターノードにhacluster
のパスワードを作成します。すべてのノードに同じパスワードを使用します。# passwd hacluster
firewalld.service
が有効化されている場合は、RHEL ファイアウォールにhigh availability
サービスを追加します。# firewall-cmd --permanent --add-service=high-availability # firewall-cmd --reload
pcs
サービスを起動し、システムの起動時に開始できるようにします。# systemctl enable pcsd.service --now
検証手順
pcs
サービスが実行していることを確認します。# systemctl is-active pcsd.service
2.5. クラスターの作成
ノードのクラスターを作成するには、以下の手順を実施します。
手順
ノードのいずれかで以下のコマンドを実行し、pcs ユーザー
hacluster
を認証します。クラスターの各ノードの名前を指定します。# pcs host auth _hostname1_ _hostname2_ _hostname3_
たとえば、以下のようになります。
[root@node01 clouduser]# pcs host auth node01 node02 node03 Username: hacluster Password: node01: Authorized node02: Authorized node03: Authorized
クラスターを作成します。
# pcs cluster setup --name _hostname1_ _hostname2_ _hostname3_
たとえば、以下のようになります。
[root@node01 clouduser]# pcs cluster setup --name newcluster node01 node02 node03 ...omitted Synchronizing pcsd certificates on nodes node01, node02, node03... node02: Success node03: Success node01: Success Restarting pcsd on the nodes in order to reload the certificates... node02: Success node03: Success node01: Success
検証手順
クラスターを有効にします。
# pcs cluster enable --all
クラスターを起動します。
# pcs cluster start --all
たとえば、以下のようになります。
[root@node01 clouduser]# pcs cluster enable --all node02: Cluster Enabled node03: Cluster Enabled node01: Cluster Enabled [root@node01 clouduser]# pcs cluster start --all node02: Starting Cluster... node03: Starting Cluster... node01: Starting Cluster...
2.6. フェンスデバイスの作成
クラスター内の任意のノードからフェンシングを設定するには、以下の手順を実施します。
手順
利用可能なインスタンスで、フェンスが可能なものを特定します。
# fence_azure_arm -l [appid] -p [authkey] --resourceGroup=[name] --subscriptionId=[name] --tenantId=[name] -o list
たとえば、以下のようになります。
[root@node1 ~]# fence_azure_arm -l XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -p XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX --resourceGroup=hacluster-rg --subscriptionId=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX --tenantId=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -o list node01-vm, node02-vm, node03-vm,
フェンスデバイスを作成します。
pcmk_host_map
コマンドを使用して、RHEL ホスト名をインスタンス ID にマッピングします。# pcs stonith create _clusterfence_ fence_azure_arm login=_AD-Application-ID_ passwd=_AD-passwd_ pcmk_host_map="_pcmk-host-map_ resourcegroup= _myresourcegroup_ tenantid=_tenantid_ subscriptionid=_subscriptionid_
検証手順
他のノードのいずれかに対してフェンスエージェントをテストします。
# pcs stonith fence _azurenodename_
たとえば、以下のようになります。
[root@node01 ~]# pcs stonith fence fenceazure Resource: fenceazure (class=stonith type=fence_azure_arm) Attributes: login=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX passwd=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX pcmk_host_map=nodea:nodea-vm;nodeb:nodeb-vm;nodec:nodec-vm pcmk_reboot_retries=4 pcmk_reboot_timeout=480 power_timeout=240 resourceGroup=rg subscriptionId=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX tenantId=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX Operations: monitor interval=60s (fenceazure-monitor-interval-60s) [root@node01 ~]# pcs stonith fenceazure (stonith:fence_azure_arm): Started nodea
ステータスを確認して、ノードが起動したことを確認します。
# watch pcs status
以下に例を示します。
[root@node01 ~]# watch pcs status fenceazure (stonith:fence_azure_arm): Started nodea
2.7. Azure 内部ロードバランサーの作成
Azure 内部ロードバランサーは、ヘルスプローブ要求に応答しないクラスターノードを削除します。
以下の手順を実行し、Azure 内部ロードバランサーを作成します。各ステップは特定の Microsoft 手順を参照し、HA のロードバランサーをカスタマイズするための設定が含まれます。
前提条件
Azure コントロールパネル へのアクセス
手順
- 基本ロードバランサーを作成。IP アドレスの割り当てタイプの場合は、内部ロードバランサー、基本 SKU、および 動的 を選択します。
- バックエンドのアドレスプールを作成します。バックエンドプールを HA に Azure リソースを作成した時に作成された可用性セットに関連付けます。ターゲットネットワーク IP 設定は設定しないでください。
- ヘルスプローブを作成します。ヘルスプローブの場合は TCP を選択し、ポート 61000 を入力します。別のサービスに干渉しない TCP ポート番号を使用できます。特定の HA 製品アプリケーション (SAP HANA や SQL Server など) については、Microsoft と連携して使用する正しいポートを指定する必要がある場合があります。
- ロードバランサールールを作成します。ロードバランシングルールを作成する場合は、事前に設定されているデフォルト値を使用します。フローティング IP (ダイレクトサーバーを返す) を 有効 に設定してください。
2.8. ロードバランサーリソースエージェントの設定
ヘルスプローブを作成したら、ロードバランサー
リソースエージェントを設定する必要があります。このリソースエージェントは、Azure ロードバランサーからヘルスプローブ要求に応答し、要求に応答しないクラスターノードを削除するサービスを実行します。
手順
Azure id
コマンドを入力して、Azure ロードバランサーリソースエージェントの説明を表示します。これは、このエージェントのオプションとデフォルトの操作を示しています。# pcs resource describe _azure-id_
ノード上の IP を管理する
Ipaddr2
リソースを作成します。# pcs resource create _resource-id_ IPaddr2 ip=_virtual/floating-ip_ cidr_netmask=_virtual/floating-mask_ --group _group-id_ nic=_network-interface_ op monitor interval=30s
たとえば、以下のようになります。
[root@node01 ~]# pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=172.16.66.99 cidr_netmask=24 --group CloudIP nic=eth0 op monitor interval=30s
ロードバランサー
リソースエージェントを設定します。# pcs resource create _resource-loadbalancer-name_ azure-lb port=_port-number_ --group _cluster-resources-group_
検証手順
pcs status
コマンドを実行して結果を表示します。[root@node01 clouduser]# pcs status
たとえば、以下のようになります。
[root@node01 ~]# pcs status Cluster name: hacluster WARNINGS: No stonith devices and stonith-enabled is not false Stack: corosync Current DC: nodeb (version 1.1.22-1.el7-63d2d79005) - partition with quorum Last updated: Wed Sep 9 16:47:07 2020 Last change: Wed Sep 9 16:44:32 2020 by hacluster via crmd on nodeb 3 nodes configured 0 resource instances configured Online: [ node01 node02 node03 ] No resources Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
関連情報
2.9. 共有ブロックストレージの設定
このセクションでは、Microsoft Azure Shared Disks を使用して Red Hat High Availability クラスターに共有ブロックストレージを設定するオプションの手順を説明します。この手順では、1TB 共有ディスクを持つ 3 つの Azure 仮想マシン (3 ノードクラスター) を想定しています。
これは、ブロックストレージを設定するスタンドアロンの例です。この手順では、クラスターを作成していないことを前提としています。
前提条件
- ホストシステムに Azure CLI をインストールし、SSH キーを作成している。
以下の作成を含むクラスター環境を Azure で作成している。リンクは、Microsoft Azure のドキュメントにあります。
手順
Azure コマンド
az disk create
を使用して、共有ブロックボリュームを作成します。$ az disk create -g resource_group -n shared_block_volume_name --size-gb disk_size --max-shares number_vms -l location
たとえば、以下のコマンドは、Azure Availability Zone
westcentralus
内 のリソースグループsharedblock
にshared-block-volume.vhd
という名前の共有ブロックボリュームを作成します。$ az disk create -g sharedblock-rg -n shared-block-volume.vhd --size-gb 1024 --max-shares 3 -l westcentralus { "creationData": { "createOption": "Empty", "galleryImageReference": null, "imageReference": null, "sourceResourceId": null, "sourceUniqueId": null, "sourceUri": null, "storageAccountId": null, "uploadSizeBytes": null }, "diskAccessId": null, "diskIopsReadOnly": null, "diskIopsReadWrite": 5000, "diskMbpsReadOnly": null, "diskMbpsReadWrite": 200, "diskSizeBytes": 1099511627776, "diskSizeGb": 1024, "diskState": "Unattached", "encryption": { "diskEncryptionSetId": null, "type": "EncryptionAtRestWithPlatformKey" }, "encryptionSettingsCollection": null, "hyperVgeneration": "V1", "id": "/subscriptions/12345678910-12345678910/resourceGroups/sharedblock-rg/providers/Microsoft.Compute/disks/shared-block-volume.vhd", "location": "westcentralus", "managedBy": null, "managedByExtended": null, "maxShares": 3, "name": "shared-block-volume.vhd", "networkAccessPolicy": "AllowAll", "osType": null, "provisioningState": "Succeeded", "resourceGroup": "sharedblock-rg", "shareInfo": null, "sku": { "name": "Premium_LRS", "tier": "Premium" }, "tags": {}, "timeCreated": "2020-08-27T15:36:56.263382+00:00", "type": "Microsoft.Compute/disks", "uniqueId": "cd8b0a25-6fbe-4779-9312-8d9cbb89b6f2", "zones": null }
Azure コマンド
az disk show
を使用して共有ブロックボリュームを作成していることを確認します。$ az disk show -g resource_group -n shared_block_volume_name
たとえば、次のコマンドは、リソースグループ
sharedblock-rg
内の共有ブロックボリュームshared-block-volume.vhd
の詳細を表示します。$ az disk show -g sharedblock-rg -n shared-block-volume.vhd { "creationData": { "createOption": "Empty", "galleryImageReference": null, "imageReference": null, "sourceResourceId": null, "sourceUniqueId": null, "sourceUri": null, "storageAccountId": null, "uploadSizeBytes": null }, "diskAccessId": null, "diskIopsReadOnly": null, "diskIopsReadWrite": 5000, "diskMbpsReadOnly": null, "diskMbpsReadWrite": 200, "diskSizeBytes": 1099511627776, "diskSizeGb": 1024, "diskState": "Unattached", "encryption": { "diskEncryptionSetId": null, "type": "EncryptionAtRestWithPlatformKey" }, "encryptionSettingsCollection": null, "hyperVgeneration": "V1", "id": "/subscriptions/12345678910-12345678910/resourceGroups/sharedblock-rg/providers/Microsoft.Compute/disks/shared-block-volume.vhd", "location": "westcentralus", "managedBy": null, "managedByExtended": null, "maxShares": 3, "name": "shared-block-volume.vhd", "networkAccessPolicy": "AllowAll", "osType": null, "provisioningState": "Succeeded", "resourceGroup": "sharedblock-rg", "shareInfo": null, "sku": { "name": "Premium_LRS", "tier": "Premium" }, "tags": {}, "timeCreated": "2020-08-27T15:36:56.263382+00:00", "type": "Microsoft.Compute/disks", "uniqueId": "cd8b0a25-6fbe-4779-9312-8d9cbb89b6f2", "zones": null }
Azure コマンド
を使用して、3 つのネットワークインターフェイスを作成します。それぞれ異なるaz network nic create
<nic_name>
を使用して、以下のコマンドを実行します。$ az network nic create -g resource_group -n nic_name --subnet subnet_name --vnet-name virtual_network --location location --network-security-group network_security_group --private-ip-address-version IPv4
たとえば、以下のコマンドは、
shareblock-nodea-vm-nic-protected
という名前のネットワークインターフェイスを作成します。$ az network nic create -g sharedblock-rg -n sharedblock-nodea-vm-nic-protected --subnet sharedblock-subnet-protected --vnet-name sharedblock-vn --location westcentralus --network-security-group sharedblock-nsg --private-ip-address-version IPv4
Azure コマンド
az vm create
を使用して 3 つの仮想マシンを作成し、共有ブロックボリュームを割り当てます。オプションの値は、各仮想マシンに独自の<vm_name>
、<new_vm_disk_name>
、<nic_name>
を持つ点で異なります。$ az vm create -n vm_name -g resource_group --attach-data-disks shared_block_volume_name --data-disk-caching None --os-disk-caching ReadWrite --os-disk-name new-vm-disk-name --os-disk-size-gb disk_size --location location --size virtual_machine_size --image image_name --admin-username vm_username --authentication-type ssh --ssh-key-values ssh_key --nics -nic_name_ --availability-set availability_set --ppg proximity_placement_group
たとえば、次のコマンドは、
sharedblock-nodea-vm
という名前の仮想マシンを作成します。$ az vm create -n sharedblock-nodea-vm -g sharedblock-rg --attach-data-disks shared-block-volume.vhd --data-disk-caching None --os-disk-caching ReadWrite --os-disk-name sharedblock-nodea-vm.vhd --os-disk-size-gb 64 --location westcentralus --size Standard_D2s_v3 --image /subscriptions/12345678910-12345678910/resourceGroups/sample-azureimagesgroupwestcentralus/providers/Microsoft.Compute/images/sample-azure-rhel-7.0-20200713.n.0.x86_64 --admin-username sharedblock-user --authentication-type ssh --ssh-key-values @sharedblock-key.pub --nics sharedblock-nodea-vm-nic-protected --availability-set sharedblock-as --ppg sharedblock-ppg { "fqdns": "", "id": "/subscriptions/12345678910-12345678910/resourceGroups/sharedblock-rg/providers/Microsoft.Compute/virtualMachines/sharedblock-nodea-vm", "location": "westcentralus", "macAddress": "00-22-48-5D-EE-FB", "powerState": "VM running", "privateIpAddress": "198.51.100.3", "publicIpAddress": "", "resourceGroup": "sharedblock-rg", "zones": "" }
検証手順
クラスター内の各仮想マシンについて、仮想マシン
<ip_address>
で SSH コマンドを使用して、ブロックデバイスが利用できることを確認します。# ssh ip_address "hostname ; lsblk -d | grep ' 1T '"
たとえば、次のコマンドは、仮想マシン IP
198.51.100.3
のホスト名およびブロックデバイスを含む詳細を一覧表示します。# ssh 198.51.100.3 "hostname ; lsblk -d | grep ' 1T '" nodea sdb 8:16 0 1T 0 disk
SSH コマンドを使用して、クラスター内の各仮想マシンが同じ共有ディスクを使用していることを確認します。
# ssh _ip_address_s "hostname ; lsblk -d | grep ' 1T ' | awk '{print \$1}' | xargs -i udevadm info --query=all --name=/dev/{} | grep '^E: ID_SERIAL='"
たとえば、以下のコマンドは、インスタンス IP アドレス
198.51.100.3
のホスト名および共有ディスクボリューム ID が含まれる詳細を一覧表示します。# ssh 198.51.100.3 "hostname ; lsblk -d | grep ' 1T ' | awk '{print \$1}' | xargs -i udevadm info --query=all --name=/dev/{} | grep '^E: ID_SERIAL='" nodea E: ID_SERIAL=3600224808dd8eb102f6ffc5822c41d89
共有ディスクが各仮想マシンに割り当てられていることを確認したら、クラスターの回復性の高いストレージを設定できます。Red Hat High Availability クラスターに回復性の高いストレージを設定する方法は、クラスターに GFS2 ファイルシステムを設定 を参照してください。GFS2 ファイルシステムに関する一般的な情報は、GFS2 ファイルシステムの設定と管理 を参照してください。
第3章 Amazon Web Services での EC2 インスタンスとしての Red Hat Enterprise Linux イメージのデプロイメント
Amazon Web Services (AWS) に EC2 インスタンスとして Red Hat Enterprise Linux (RHEL) 7 イメージをデプロイするオプションは多数あります。本章では、イメージを選択するオプションを説明し、ホストシステムおよび仮想マシンのシステム要件の一覧を紹介します。本章では、ISO イメージからカスタム VM を作成し、そのイメージを EC2 にアップロードして、EC2 インスタンスを起動する手順も説明します。
ISO イメージからカスタム仮想マシンを作成することは可能ですが、Red Hat Image Builder 製品を使用して、特定のクラウドプロバイダーで使用するようにカスタマイズされたイメージを作成することを推奨します。Image Builder を使用すると、AMI (Amazon Machine Image ami
形式) を作成およびアップロードできます。詳細は Image Builder ガイド を参照してください。
この章では、Amazon のドキュメントを参照している箇所が多数あります。手順の詳細は、参照している Amazon ドキュメントを確認してください。
AWS でセキュアに使用できる Red Hat 製品の一覧は、Red Hat on Amazon Web Services を参照してください。
前提条件
- Red Hat カスタマーポータル のアカウントに登録している。
- AWS にサインアップして、AWS リソースを設定します。詳細は Setting Up with Amazon EC2 を参照してください。
- Red Hat Cloud Access プログラム でサブスクリプションを有効にします。Red Hat Cloud Access プログラムでは、Red Hat のサブスクリプションを、物理システムまたはオンプレミスシステムから、Red Hat のフルサポートのある AWS へ移動できます。
関連情報
3.1. AWS での Red Hat Enterprise Linux イメージオプション
以下の表には、イメージの選択肢を記載し、イメージオプションの相違点を示しています。
表3.1 イメージオプション
イメージオプション | サブスクリプション | サンプルシナリオ | 留意事項 |
---|---|---|---|
Red Hat Gold Image のデプロイを選択する | 既存の Red Hat サブスクリプションを活用する | Red Hat Cloud Access プログラム を使用してサブスクリプションを有効にし、AWS で Red Hat Gold Image を選択します。 | このサブスクリプションには、Red Hat のコストが含まれていますが、他のインスタンスのコストは、Amazon 社に支払うことになります。 Red Hat Gold Image は、既存の Red Hat サブスクリプションを活用するため、クラウドアクセスイメージと呼ばれています。Red Hat は、クラウドアクセスイメージを直接サポートします。 |
AWS に移動するカスタムイメージをデプロイすることを選択する | 既存の Red Hat サブスクリプションを活用する | Red Hat Cloud Access プログラム を使用してサブスクリプションを有効にし、カスタムイメージをアップロードし、サブスクリプションを割り当てます。 | このサブスクリプションには、Red Hat のコストが含まれていますが、他のインスタンスのコストは、Amazon 社に支払うことになります。 AWS に移行するカスタムイメージは、既存の Red Hat サブスクリプションを活用するため、クラウドアクセスイメージと呼ばれています。Red Hat は、クラウドアクセスイメージを直接サポートします。 |
RHEL を含む既存の Amazon イメージをデプロイすることを選択する | AWS EC2 イメージには Red Hat 製品が含まれる | AWS マネジメントコンソール でのインスタンスの起動時に RHEL イメージを選択するか、AWS Marketplace からイメージを選択します。 | Amazon 社に、従量課金モデルで 1 時間ごとに支払います。このようなイメージはオンデマンドイメージと呼ばれています。Amazon 社はオンデマンドイメージをサポートします。 Red Hat は、イメージの更新を提供します。AWS により、Red Hat Update Infrastructure (RHUI) から更新を利用できるようにします。 |
Red Hat Image Builder を使用して、AWS 用のカスタムイメージを作成できます。詳細は Image Builder ガイド を参照してください。
オンデマンドインスタンスは、Red Hat Cloud Access インスタンスに変換できません。オンデマンドイメージから Red Hat Cloud Access bring-your-own-subscription (BYOS) イメージに変更するには、Red Hat Cloud Access インスタンスを新たに作成し、オンデマンドインスタンスからデータを移行します。データを移行した後に、オンデマンドのインスタンスをキャンセルして二重請求を回避します。
本章の残りの部分には、カスタムイメージに関する情報および手順が記載されています。
3.2. AWS CLI のインストール
本章の多くの手順には、AWS CLI の使用が含まれます。AWS CLI をインストールするには、以下の手順を実行します。
前提条件
AWS アクセスキー ID および AWS シークレットアクセスキーを作成していてアクセスできる。情報および手順は、AWS CLI の設定 を参照してください。
手順
Python 3 および
pip
ツールをインストールします。# yum install python3 # yum install python3-pip
pip
コマンドを使用して、AWS コマンドラインツール をインストールします。# pip3 install awscli
aws --version
コマンドを実行して、AWS CLI をインストールしたことを確認します。$ aws --version aws-cli/1.16.182 Python/2.7.5 Linux/3.10.0-957.21.3.el7.x86_64 botocore/1.12.172
AWS アクセスの詳細に従って、AWS コマンドラインクライアントを設定します。
$ aws configure AWS Access Key ID [None]: AWS Secret Access Key [None]: Default region name [None]: Default output format [None]:
3.3. 仮想マシン設定設定
クラウド仮想マシンには、以下の設定設定が必要です。
表3.2 仮想マシンの設定設定
設定 | 推奨事項 |
---|---|
ssh |
仮想マシンへのリモートアクセスを確立するには、 |
dhcp | プライマリー仮想アダプターは、dhcp 用に設定する必要があります。 |
3.4. ISO イメージからのベース仮想マシンの作成
このセクションの手順に従って、ISO イメージからベースイメージを作成します。
前提条件
仮想化の 導入および管理ガイド に従って、Red Hat Enterprise Linux 7 ホストマシンの仮想化を有効にします。
3.4.1. ISO イメージのダウンロード
手順
- Red Hat カスタマーポータル から最新の Red Hat Enterprise Linux ISO Image をダウンロードします。
-
イメージを
/var/lib/libvirt/images
ディレクトリーに移動します。
3.4.2. ISO イメージからの仮想マシンの作成
手順
- 仮想化用のホストマシンを有効にしていることを確認します。仮想化パッケージのインストールに関する情報および手順は、既存の Red Hat Enterprise Linux システム上への仮想化パッケージのインストール を参照してください。
基本的な Red Hat Enterprise Linux 仮想マシンを作成し、起動します。仮想マシンの作成手順は、仮想マシンの作成 を参照してください。
コマンドラインを使用して仮想マシンを作成する場合は、デフォルトのメモリーと CPU を仮想マシンの容量に設定するようにしてください。仮想ネットワークインターフェイスを virtio に設定します。
基本的なコマンドラインの例を以下に示します。
virt-install --name _vmname_ --memory 2048 --vcpus 2 --disk size=8,bus=virtio --location rhel-7.0-x86_64-dvd.iso --os-variant=rhel7.0
virt-manager アプリケーションを使用して仮想マシンを作成する場合は、virt-manager を使用したゲストの作成 の手順を実行します。以下の点に注意してください。
- 仮想マシンをすぐに起動 は選択しないでください。
- メモリー と ストレージのサイズ を、希望の設定に変更します。
- インストールを開始する前に、仮想ネットワークインターフェイス設定 で モデル を virtio に変更し、vCPUs を仮想マシンの容量設定に変更していることを確認します。
3.4.3. RHEL インストールの完了
仮想マシンが起動したら、以下の手順を実行してインストールを完了し、root アクセスを有効にします。
手順
- インストールプロセス中に使用する言語を選択します。
インストール概要 ビューで、以下を行います。
- ソフトウェアの選択 をクリックし、最小インストール を選択します。
- 完了 をクリックします。
インストール先 をクリックし、ストレージ設定 で カスタム を選択します。
-
/boot
で、500 MB 以上であることを確認してください。残りの領域は、root/
に使用できます。 - 標準のパーティションが推奨されますが、論理ボリューム管理 (LVM) を使用することも可能です。
- ファイルシステムには、xfs、ext4、ext3 などを使用できます。
- 変更が完了したら、完了 をクリックします。
-
- インストールの開始 をクリックします。
- Root パスワード を設定します。
-
インストールが完了したら、仮想マシンを再起動して
root
でログインします。 イメージを設定します。
注記cloud-init
パッケージがインストールされ、有効になっていることを確認します。- 仮想マシンの電源をオフにします。
3.5. Red Hat Enterprise Linux イメージの AWS へのアップロード
ホストマシンで本セクションにある手順に従って、イメージを AWS にアップロードします。
3.5.1. S3 バケットの作成
AWS にインポートするには、Amazon S3 バケットが必要です。Amazon S3 バケットは、オブジェクトを格納する Amazon リソースです。イメージのアップロードプロセスの一環として、S3 バケットを作成し、イメージをバケットに移動します。以下の手順に従って、バケットを作成します。
前提条件
- AWS CLI がインストールされていること。詳細は、AWS CLI のインストール を参照してください。
手順
- Amazon S3 コンソール を起動します。
- Create Bucket をクリックします。Create Bucket ダイアログが表示されます。
Name and region ビューで、以下を行います。
- Bucket name を入力します。
- Region を選択します。フィールドにリージョンを入力するか、ドロップダウンをクリックして、利用可能な全リージョンから使用するリージョンを選択します。
- 次へ をクリックします。
- Configure options ビューでは、目的のオプションを選択し、Next をクリックします。
- Set permissions ビューで、デフォルトのオプションを変更または受け入れ、Next をクリックします。
- バケットの設定を確認します。
Create bucket をクリックします。
注記AWS CLI を使用してバケットを作成することもできます。たとえば、
aws s3 mb s3://my-new-bucket
は、my-new-bucket
という名前の S3 バケットを作成します。mb
コマンドの詳細は、AWS CLI コマンドリファレンス を参照してください。
3.5.2. vmimport ロールの作成
仮想マシンのインポートに必要な vmimport
ロールを作成するには、以下の手順を実行します。詳細は、Amazon ドキュメントの VM Import Service Role を参照してください。
手順
trust-policy.json
という名前のファイルを作成し、以下のポリシーを追加します。システムの任意の場所にファイルを保存し、その場所を書き留めます。{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "vmie.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals":{ "sts:Externalid": "vmimport" } } } ] }
create role
コマンドを実行してvmimport
ロールを作成します。trust-policy.json
ファイルの場所への完全なパスを指定します。file://
の接頭辞をパスに設定します。以下に例を示します。aws iam create-role --role-name vmimport --assume-role-policy-document file:///home/sample/ImportService/trust-policy.json
role-policy.json
という名前のファイルを作成し、以下のポリシーを追加します。s3-bucket-name
を、S3 バケットの名前に置き換えます。{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket" ], "Resource":[ "arn:aws:s3:::s3-bucket-name", "arn:aws:s3:::s3-bucket-name/*" ] }, { "Effect":"Allow", "Action":[ "ec2:ModifySnapshotAttribute", "ec2:CopySnapshot", "ec2:RegisterImage", "ec2:Describe*" ], "Resource":"*" } ] }
put-role-policy
コマンドを使用して、作成したロールにポリシーを割り当てます。role-policy.json
ファイルの完全パスを指定します。以下に例を示します。aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document file:///home/sample/ImportService/role-policy.json
関連情報
3.5.3. AMI の S3 への変換およびプッシュ
Amazon Machine Image (AMI) を S3 に変換してプッシュするには、以下の手順を実行します。サンプルは典型的なもので、qcow2
ファイル形式でフォーマットされたイメージを raw
形式に変換します。Amazon では、OVA
、VHD
、VHDX
、VMDK
、および raw
の形式のイメージを利用できます。Amazon で利用できるイメージ形式の詳細は、VM import/Export の仕組み を参照してください。
手順
qemu-img
コマンドを実行してイメージを変換します。以下に例を示します。qemu-img convert -f qcow2 -O raw rhel-server-7.7-1-x86_64-kvm.qcow2 rhel-server-7.7-1-x86_64-kvm.raw
イメージを S3 にプッシュします。
aws s3 cp rhel-server-7.7.1-x86_64-kvm.raw s3://s3-_bucket-name_
注記この手順では数分かかる場合があります。完了したら、AWS S3 コンソール を使用して、イメージが S3 バケットに正常にアップロードされたことを確認できます。
3.5.4. raw イメージからの AMI の作成
raw イメージから AMI を作成するには、以下の手順を実行します。
前提条件
- AWS CLI がインストールされていること。詳細は、AWS CLI のインストール を参照してください。
手順
-
AWS CLI で
aws ec2 import-image
コマンドを実行すると、raw イメージから AMI を作成できます。
# aws ec2 import-image --platform Linux --license-type BYOL --no-encrypted --description _imagedescription_ --architecture x86_64 --disk-containers Format=Raw,UserBucket="{S3Bucket=virtqes1,S3Key=rhel-server-ec2-7.9-30.x86_64.raw}" --region _regionname_
関連情報
3.5.5. AMI からのインスタンスの起動
AMI からインスタンスを起動して設定するには、以下の手順を行います。
手順
- AWS EC2 Dashboard から、Images を選択して、AMI を選択します。
- イメージを右クリックして、Launch を選択します。
ワークロードの要件を満たす、もしくは超過する Instance Type を選択します。
インスタンスタイプに関する情報は、Amazon EC2 Instance Types を参照してください。
Next:Configure Instance Details をクリックします。
- 作成する インスタンス数 を入力します。
- Network で、AWS 環境でのセットアップ の際に作成した VPC を選択します。インスタンスのサブネットを選択するか、新しいサブネットを作成します。
自動割り当てパブリック IP では、Enable を選択します。
注記これらは、基本インスタンスの作成に必要な最小限の設定オプションです。アプリケーション要件に応じて追加オプションを確認します。
- Next: Add Storage をクリックします。デフォルトのストレージが十分であることを確認してください。
Next: Add Tags をクリックします。
注記タグを使用すると、AWS リソースの管理に役立ちます。タグ付けの詳細は、Amazon EC2 リソースにタグを付ける を参照してください。
- Next:Configure Security Group をクリックします。AWS 環境でのセットアップ の際に作成したセキュリティーグループを選択します。
- Review and Launch をクリックします。選択内容を確認します。
Launch をクリックします。既存の鍵のペアの選択、または新しい鍵のペアの作成に関するダイアログが表示されます。AWS 環境でのセットアップ 時に作成した鍵のペアを選択します。
注記秘密鍵のパーミッションが正しいことを確認します。必要に応じて
chmod 400 <keyname>.pem
コマンドオプションを使用してパーミッションを変更します。- Launch Instances をクリックします。
View Instances をクリックします。インスタンスに名前を付けることができます。
インスタンスを選択して Connect をクリックすると、インスタンスへの SSH セッションを開始できます。A standalone SSH client に記載されているコマンドの例を使用してください。
注記または、AWS CLI を使用してインスタンスを起動することもできます。詳細は、Amazon 社のドキュメントの Launching, Listing, and Terminating Amazon EC2 Instances を参照してください。
3.5.6. Red Hat サブスクリプションの割り当て
Red Hat Cloud Access プログラムで有効になっているサブスクリプションを割り当てるには、以下の手順を行います。
前提条件
サブスクリプションが有効になっている。
手順
システムを登録します。
subscription-manager register --auto-attach
サブスクリプションを割り当てます。
- アクティベーションキーを使用して、サブスクリプションを割り当てることができます。カスタマーポータルのアクティベーションキーを作成する を参照してください。
- または、サブスクリプションプール (Pool ID) の ID を使用してサブスクリプションを手動で割り当てることができます。コマンドラインでのサブスクリプションのアタッチと削除 を参照してください。
第4章 AWS での Red Hat High Availability クラスターの設定
本章では、EC2 インスタンスをクラスターノードとして使用し、Amazon Web Services (AWS) での Red Hat High Availability (HA) クラスターを設定する情報および手順を説明します。クラスターに使用する Red Hat Enterprise Linux (RHEL) イメージを取得するオプションは複数あります。AWS のイメージオプションの詳細は、AWS での Red Hat Enterprise Linux Image オプション を参照してください。
本章では、AWS の環境設定の前提条件を説明します。環境を設定したら、EC2 インスタンスを作成および設定できます。
本章では、個別のノードを AWS の HA ノードのクラスターに変換する HA クラスターの作成に固有の手順も説明します。これには、各クラスターノードに高可用性パッケージおよびエージェントをインストールし、フェンシングを設定し、AWS ネットワークリソースエージェントをインストールする手順が含まれます。
この章では、Amazon のドキュメントを参照している箇所が多数あります。多くの手順に関する詳細は、参照している Amazon ドキュメントを確認してください。
前提条件
- AWS コマンドラインインターフェイス (CLI) をインストールする必要があります。AWS CLI のインストールに関する詳細は、AWS CLI のインストール を参照してください。
- Red Hat Cloud Access プログラム でサブスクリプションを有効にします。Red Hat Cloud Access プログラムでは、Red Hat のサブスクリプションを、物理システムまたはオンプレミスシステムから、Red Hat のフルサポートのある AWS へ移動できます。
関連情報
4.1. AWS アクセスキーおよび AWS シークレットアクセスキーの作成
AWS CLI をインストールする前に、AWS アクセスキーおよび AWS シークレットアクセスキーを作成する必要があります。フェンシングおよびリソースエージェントの API は AWS アクセスキーおよびシークレットアクセスキーを使用してクラスター内の各ノードに接続します。
以下の手順に従って、キーを作成します。
前提条件
IAM ユーザーアカウントに Programmatic アクセスがある。詳細は、Setting up the AWS Environment を参照してください。
手順
- AWS コンソール を起動します。
- AWS アカウント ID をクリックしてドロップダウンメニューを表示し、My Security Credentials を選択します。
- Users をクリックします。
- ユーザーを選択し、Summary 画面を開きます。
- Security credentials タブをクリックします。
- Create access key をクリックします。
-
.csv
ファイルをダウンロード (または両方の鍵を保存) します。フェンスデバイスの作成時に、この鍵を入力する必要があります。
4.2. HA パッケージおよびエージェントのインストール
全ノードで以下の手順を実行し、HA パッケージおよびエージェントをインストールします。
手順
以下のコマンドを入力して、AWS Red Hat Update Infrastructure (RHUI) クライアントを削除します。Red Hat Cloud Access サブスクリプションを使用するため、サブスクリプションに加えて AWS RHUI を使用しないでください。
$ sudo -i # yum -y remove rh-amazon-rhui-client*
仮想マシンを Red Hat に登録します。
# subscription-manager register --auto-attach
すべてのリポジトリーを無効にします。
# subscription-manager repos --disable=*
RHEL 7 Server リポジトリーおよび RHEL 7 Server HA リポジトリーを有効にします。
# subscription-manager repos --enable=rhel-7-server-rpms # subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
すべてのパッケージを更新します。
# yum update -y
カーネルを更新したら再起動します。
# reboot
pcs、pacemaker、fence agent およびリソースエージェントをインストールします。
# yum -y install pcs pacemaker fence-agents-aws resource-agents
hacluster
ユーザーは、前の手順でpcs
およびpacemaker
のインストール時に作成されました。すべてのクラスターノードにhacluster
のパスワードを作成します。すべてのノードに同じパスワードを使用します。# passwd hacluster
firewalld.service
が有効化されている場合は、RHEL ファイアウォールにhigh availability
サービスを追加します。# firewall-cmd --permanent --add-service=high-availability # firewall-cmd --reload
pcs
サービスを起動し、システムの起動時に開始できるようにします。# systemctl enable pcsd.service --now
検証手順
pcs
サービスが実行していることを確認します。
# systemctl is-active pcsd.service
4.3. クラスターの作成
ノードのクラスターを作成するには、以下の手順を実施します。
手順
ノードのいずれかで以下のコマンドを実行し、pcs ユーザー
hacluster
を認証します。クラスターの各ノードの名前を指定します。# pcs host auth _hostname1_ _hostname2_ _hostname3_
たとえば、以下のようになります。
[root@node01 clouduser]# pcs host auth node01 node02 node03 Username: hacluster Password: node01: Authorized node02: Authorized node03: Authorized
クラスターを作成します。
# pcs cluster setup --name _hostname1_ _hostname2_ _hostname3_
たとえば、以下のようになります。
[root@node01 clouduser]# pcs cluster setup --name newcluster node01 node02 node03 ...omitted Synchronizing pcsd certificates on nodes node01, node02, node03... node02: Success node03: Success node01: Success Restarting pcsd on the nodes in order to reload the certificates... node02: Success node03: Success node01: Success
検証手順
クラスターを有効にします。
# pcs cluster enable --all
クラスターを起動します。
# pcs cluster start --all
たとえば、以下のようになります。
[root@node01 clouduser]# pcs cluster enable --all node02: Cluster Enabled node03: Cluster Enabled node01: Cluster Enabled [root@node01 clouduser]# pcs cluster start --all node02: Starting Cluster... node03: Starting Cluster... node01: Starting Cluster...
4.4. フェンスデバイスの作成
フェンシングを設定するには、以下の手順を実行します。
手順
以下の AWS メタデータクエリーを入力し、各ノードのインスタンス ID を取得します。フェンスデバイスを設定するには、これらの ID が必要です。詳細は Instance Metadata and User Data を参照してください。
# echo $(curl -s http://169.254.169.254/latest/meta-data/instance-id)
たとえば、以下のようになります。
[root@ip-10-0-0-48 ~]# echo $(curl -s http://169.254.169.254/latest/meta-data/instance-id) i-07f1ac63af0ec0ac6
フェンスデバイスを作成します。
pcmk_host_map
コマンドを使用して、RHEL ホスト名をインスタンス ID にマッピングします。AWS アクセスキーおよび AWS シークレットアクセスキーの作成 で先ほど設定した AWS アクセスキーおよび AWS シークレットアクセスキーを使用します。# pcs stonith create cluster_fence fence_aws access_key=access-key secret_key=_secret-access-key_ region=_region_ pcmk_host_map="rhel-hostname-1:Instance-ID-1;rhel-hostname-2:Instance-ID-2;rhel-hostname-3:Instance-ID-3"
たとえば、以下のようになります。
[root@ip-10-0-0-48 ~]# pcs stonith create clusterfence fence_aws access_key=AKIAI*******6MRMJA secret_key=a75EYIG4RVL3h*******K7koQ8dzaDyn5yoIZ/ region=us-east-1 pcmk_host_map="ip-10-0-0-48:i-07f1ac63af0ec0ac6;ip-10-0-0-46:i-063fc5fe93b4167b2;ip-10-0-0-58:i-08bd39eb03a6fd2c7" power_timeout=240 pcmk_reboot_timeout=480 pcmk_reboot_retries=4
検証手順
他のノードのいずれかに対してフェンスエージェントをテストします。
# pcs stonith fence _awsnodename_
たとえば、以下のようになります。
[root@ip-10-0-0-48 ~]# pcs stonith fence ip-10-0-0-58 Node: ip-10-0-0-58 fenced
ステータスを確認して、ノードがフェンスされていることを確認します。
# watch pcs status
たとえば、以下のようになります。
[root@ip-10-0-0-48 ~]# pcs status Cluster name: newcluster Stack: corosync Current DC: ip-10-0-0-46 (version 1.1.18-11.el7-2b07d5c5a9) - partition with quorum Last updated: Fri Mar 2 20:01:31 2018 Last change: Fri Mar 2 19:24:59 2018 by root via cibadmin on ip-10-0-0-48 3 nodes configured 1 resource configured Online: [ ip-10-0-0-46 ip-10-0-0-48 ip-10-0-0-58 ] Full list of resources: clusterfence (stonith:fence_aws): Started ip-10-0-0-46 Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
4.5. クラスターノードへの AWS CLI のインストール
以前のバージョンでは、AWS CLI をホストシステムにインストールしていました。ネットワークリソースエージェントを設定する前に、クラスターノードに AWS CLI をインストールする必要があります。
各クラスターノードで以下の手順を実行します。
前提条件
AWS アクセスキーおよび AWS シークレットアクセスキーを作成している。詳細は、AWS アクセスキーおよび AWS シークレットアクセスキーの作成 を参照してください。
手順
- AWS CLI のインストール の手順を行います。
以下のコマンドを実行して、AWS CLI が適切に設定されていることを確認します。インスタンス ID およびインスタンス名が表示されます。
以下に例を示します。
[root@ip-10-0-0-48 ~]# aws ec2 describe-instances --output text --query 'Reservations[*].Instances[*].[InstanceId,Tags[?Key==`Name`].Value]' i-07f1ac63af0ec0ac6 ip-10-0-0-48 i-063fc5fe93b4167b2 ip-10-0-0-46 i-08bd39eb03a6fd2c7 ip-10-0-0-58
4.6. ネットワークリソースエージェントのインストール
HA 操作が機能するために、クラスターは AWS ネットワークリソースエージェントを使用してフェイルオーバー機能を有効にします。設定された時間内にノードがハートビートチェックに応答しない場合、ノードはフェンスされ、操作はクラスター内の追加のノードにフェイルオーバーします。これを使用するには、ネットワークリソースエージェントを設定する必要があります。
順序
と コロケーション
の制約を適用するため、同じグループ に 2 つのリソースを追加します。
セカンダリープライベート IP リソースと仮想 IP リソースを作成
セカンダリープライベート IP アドレスを追加し、仮想 IP を作成するには、以下の手順を行います。この手順は、クラスター内の任意のノードから実行できます。
手順
以下のコマンドを実行して、
AWS Secondary Private IP Address
リソースエージェント (awsvip) の説明を表示します。これは、このエージェントのオプションとデフォルトの操作を示しています。# pcs resource describe awsvip
次のコマンドを実行して、
VPC CIDR
ブロックで未使用のプライベート IP アドレスを使用して 2 番目のプライベート IP アドレスを作成します。# pcs resource create privip awsvip secondary_private_ip=_Unused-IP-Address_ --group _group-name_
以下に例を示します。
[root@ip-10-0-0-48 ~]# pcs resource create privip awsvip secondary_private_ip=10.0.0.68 --group networking-group
仮想 IP リソースを作成します。これは、フェンシングされたノードからフェイルオーバーノードに即時に再マッピングできる VPC IP アドレスで、サブネット内のフェンスされたノードの失敗をマスクします。
# pcs resource create vip IPaddr2 ip=_secondary-private-IP_ --group _group-name_
たとえば、以下のようになります。
root@ip-10-0-0-48 ~]# pcs resource create vip IPaddr2 ip=10.0.0.68 --group networking-group
検証手順
pcs status
コマンドを実行して、リソースが実行していることを確認します。
# pcs status
以下に例を示します。
[root@ip-10-0-0-48 ~]# pcs status Cluster name: newcluster Stack: corosync Current DC: ip-10-0-0-46 (version 1.1.18-11.el7-2b07d5c5a9) - partition with quorum Last updated: Fri Mar 2 22:34:24 2018 Last change: Fri Mar 2 22:14:58 2018 by root via cibadmin on ip-10-0-0-46 3 nodes configured 3 resources configured Online: [ ip-10-0-0-46 ip-10-0-0-48 ip-10-0-0-58 ] Full list of resources: clusterfence (stonith:fence_aws): Started ip-10-0-0-46 Resource Group: networking-group privip (ocf::heartbeat:awsvip): Started ip-10-0-0-48 vip (ocf::heartbeat:IPaddr2): Started ip-10-0-0-58 Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
Elastic IP アドレスの作成
Elastic IP アドレスは、フェンシングされたノードからフェイルオーバーノードに即時に再マッピングできるパブリック IP アドレスで、フェンスされたノードの障害をマスクします。
これは、先に作成した仮想 IP リソースとは異なることに注意してください。Elastic IP アドレスは、サブネット接続ではなく、公開用インターネット接続に使用されます。
-
上で作成した 同じグループ に 2 つのリソースを追加して、
順序
とコロケーション
の制約を適用します。 以下の AWS CLI コマンドを入力して、Elastic IP アドレスを作成します。
[root@ip-10-0-0-48 ~]# aws ec2 allocate-address --domain vpc --output text eipalloc-4c4a2c45 vpc 35.169.153.122
以下のコマンドを実行して、AWS のセカンダリー Elastic IP Address リソースエージェント (awseip) の説明を表示します。これは、このエージェントのオプションとデフォルトの操作を示しています。
# pcs resource describe awseip
ステップ 1 で作成して割り当てられた IP アドレスを使用して、セカンダリー Elastic IP アドレスリソースを作成します。
# pcs resource create elastic awseip elastic_ip=_Elastic-IP-Address_allocation_id=_Elastic-IP-Association-ID_ --group networking-group
たとえば、以下のようになります。
# pcs resource create elastic awseip elastic_ip=35.169.153.122 allocation_id=eipalloc-4c4a2c45 --group networking-group
検証手順
pcs status
コマンドを実行して、リソースが実行していることを確認します。
# pcs status
以下に例を示します。
[root@ip-10-0-0-58 ~]# pcs status Cluster name: newcluster Stack: corosync Current DC: ip-10-0-0-58 (version 1.1.18-11.el7-2b07d5c5a9) - partition with quorum Last updated: Mon Mar 5 16:27:55 2018 Last change: Mon Mar 5 15:57:51 2018 by root via cibadmin on ip-10-0-0-46 3 nodes configured 4 resources configured Online: [ ip-10-0-0-46 ip-10-0-0-48 ip-10-0-0-58 ] Full list of resources: clusterfence (stonith:fence_aws): Started ip-10-0-0-46 Resource Group: networking-group privip (ocf::heartbeat:awsvip): Started ip-10-0-0-48 vip (ocf::heartbeat:IPaddr2): Started ip-10-0-0-48 elastic (ocf::heartbeat:awseip): Started ip-10-0-0-48 Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
Elastic IP アドレスのテスト
以下のコマンドを入力して、仮想 IP (awsvip) および Elastic IP (awseip) のリソースが機能していることを確認します。
手順
ローカルワークステーションから、上で作成した Elastic IP アドレスへの SSH セッションを開始します。
$ ssh -l ec2-user -i ~/.ssh/<KeyName>.pem elastic-IP
以下に例を示します。
$ ssh -l ec2-user -i ~/.ssh/cluster-admin.pem 35.169.153.122
- SSH 経由で接続したホストが、作成された elastic リソースに関連付けられたホストであることを確認します。
4.7. 共有ブロックストレージの設定
このセクションでは、Amazon EBS のマルチアタッチボリュームを使用する Red Hat High Availability クラスターの共有ブロックストレージを設定するオプションの手順を説明します。この手順では、1TB 共有ディスクを持つ 3 つのインスタンス (3 ノードクラスター) を想定しています。
手順
AWS コマンド create-volume を使用して共有ブロックボリュームを作成 します。
$ aws ec2 create-volume --availability-zone availability_zone --no-encrypted --size 1024 --volume-type io1 --iops 51200 --multi-attach-enabled
たとえば、以下のコマンドは、
us-east-1a
アベイラビリティーゾーンにボリュームを作成します。$ aws ec2 create-volume --availability-zone us-east-1a --no-encrypted --size 1024 --volume-type io1 --iops 51200 --multi-attach-enabled { "AvailabilityZone": "us-east-1a", "CreateTime": "2020-08-27T19:16:42.000Z", "Encrypted": false, "Size": 1024, "SnapshotId": "", "State": "creating", "VolumeId": "vol-042a5652867304f09", "Iops": 51200, "Tags": [ ], "VolumeType": "io1" }
注記次の手順で
VolumeId
が必要になります。クラスターの各インスタンスについて、AWS コマンド
attach-volume
を使用して共有ブロックボリュームを割り当てます。<instance_id>
および<volume_id>
を使用します。$ aws ec2 attach-volume --device /dev/xvdd --instance-id instance_id --volume-id volume_id
たとえば、以下のコマンドは共有ブロックボリューム
vol-042a5652867304f09
をinstance i-0eb803361c2c887f2
に接続します。$ aws ec2 attach-volume --device /dev/xvdd --instance-id i-0eb803361c2c887f2 --volume-id vol-042a5652867304f09 { "AttachTime": "2020-08-27T19:26:16.086Z", "Device": "/dev/xvdd", "InstanceId": "i-0eb803361c2c887f2", "State": "attaching", "VolumeId": "vol-042a5652867304f09" }
検証手順
クラスター内の各インスタンスについて、インスタンス
<ip_address>
で SSH コマンドを使用して、ブロックデバイスが利用できるようにされていることを確認します。# ssh <ip_address> "hostname ; lsblk -d | grep ' 1T '"
たとえば、以下のコマンドは、インスタンス IP
198.51.100.3
のホスト名およびブロックデバイスを含む詳細を一覧表示します。# ssh 198.51.100.3 "hostname ; lsblk -d | grep ' 1T '" nodea nvme2n1 259:1 0 1T 0 disk
SSH
コマンドを使用して、クラスター内の各インスタンスが同じ共有ディスクを使用していることを確認します。# ssh ip_address "hostname ; lsblk -d | grep ' 1T ' | awk '{print \$1}' | xargs -i udevadm info --query=all --name=/dev/{} | grep '^E: ID_SERIAL='"
たとえば、以下のコマンドは、インスタンス IP アドレス
198.51.100.3
のホスト名および共有ディスクボリューム ID が含まれる詳細を一覧表示します。# ssh 198.51.100.3 "hostname ; lsblk -d | grep ' 1T ' | awk '{print \$1}' | xargs -i udevadm info --query=all --name=/dev/{} | grep '^E: ID_SERIAL='" nodea E: ID_SERIAL=Amazon Elastic Block Store_vol0fa5342e7aedf09f7
共有ディスクが各インスタンスに接続されていることを確認したら、クラスターの回復性の高いストレージを設定できます。Red Hat High Availability クラスターに回復性の高いストレージを設定する方法は、クラスターに GFS2 ファイルシステムを設定 を参照してください。GFS2 ファイルシステムに関する一般的な情報は、GFS2 ファイルシステムの設定と管理 を参照してください。
第5章 Google Cloud Platform での Google Compute Engine インスタンスとしての Red Hat Enterprise Linux イメージのデプロイメント
Google Cloud Platform (GCP) に Google Compute Engine (GCE) インスタンスとして Red Hat Enterprise Linux (RHEL) 7 イメージをデプロイするオプションは複数あります。本章では、イメージを選択するオプションを説明し、ホストシステムおよび仮想マシンのシステム要件の一覧を紹介します。本章では、ISO イメージからカスタム VM を作成し、GCE にアップロードして、インスタンスを起動する手順を説明します。
この章では、Google のドキュメントを参照している箇所が多数あります。多くの手順に関する詳細は、参照している Google ドキュメントを参照してください。
GCP 向けの Red Hat 製品認定の一覧は、Red Hat on Google Cloud Platform を参照してください。
前提条件
- Red Hat カスタマーポータル のアカウントがある (本章の手順を完了するのに必要)。
- Google Cloud Platform コンソールにアクセスするために、GCP でアカウントを作成している。詳細は Google Cloud を参照してください。
- Red Hat Cloud Access プログラム で、Red Hat サブスクリプションを有効にしている。Red Hat Cloud Access プログラムでは、Red Hat のサブスクリプションを、物理システムまたはオンプレミスシステムから、Red Hat のフルサポートのある GCP へ移動できます。
5.1. GCP での Red Hat Enterprise Linux イメージオプション
以下の表には、イメージの選択肢を記載し、イメージオプションの相違点を示しています。
表5.1 イメージオプション
イメージオプション | サブスクリプション | サンプルシナリオ | 留意事項 |
---|---|---|---|
GCP に移動するカスタムイメージをデプロイすることを選択する | 既存の Red Hat サブスクリプションを活用する | Red Hat Cloud Access プログラム を使用してサブスクリプションを有効にし、カスタムイメージをアップロードし、サブスクリプションを割り当てます。 | その他のすべてのインスタンスコストを支払うことになりますが、サブスクリプション自体には Red Hat 製品コストが含まれます。 GCP に移行するカスタムイメージは、既存の Red Hat サブスクリプションを活用するため、クラウドアクセスイメージと呼ばれています。Red Hat は、クラウドアクセスイメージを直接サポートします。 |
RHEL を含む既存の GCP イメージをデプロイすることを選択する | GCP イメージには、Red Hat 製品が含まれる | GCP Compute Engine でインスタンスを起動する時に RHEL イメージを選択するか、Google Cloud Platform Marketplace からイメージを選択します。 | 従量課金モデルでは、GCP に 1 時間ごとに支払います。このようなイメージはオンデマンドイメージと呼ばれています。GCP は、サポート契約に基づいてオンデマンドイメージのサポートを提供します。 |
オンデマンドインスタンスは、Red Hat Cloud Access インスタンスに変換できません。オンデマンドイメージから Red Hat Cloud Access bring-your-own subscription (BYOS) イメージに変更するには、Red Hat Cloud Access インスタンスを新たに作成し、オンデマンドインスタンスからデータを移行します。データを移行した後に、オンデマンドのインスタンスをキャンセルして二重請求を回避します。
本章の残りの部分には、カスタムイメージに関する情報および手順が記載されています。
5.2. ベースイメージの理解
本セクションでは、事前設定されたベースイメージおよびその設定を使用する方法を説明します。
5.2.1. カスタムベースイメージの使用
仮想マシンを手動で設定するには、ベース (スタートアップ) 仮想マシンイメージで開始します。ベース仮想マシンイメージを作成したら、設定設定を変更して、仮想マシンがクラウドで動作するために必要なパッケージを追加できます。イメージのアップロード後に、特定のアプリケーションに追加の設定変更を行うことができます。
5.2.2. 仮想マシン設定設定
クラウド仮想マシンには、以下の設定設定が必要です。
表5.2 仮想マシンの設定設定
設定 | 推奨事項 |
---|---|
ssh |
仮想マシンへのリモートアクセスを確立するには、 |
dhcp | プライマリー仮想アダプターは、dhcp 用に設定する必要があります。 |
5.3. ISO イメージからのベース仮想マシンの作成
このセクションの手順に従って、ISO イメージからベースイメージを作成します。
前提条件
仮想化の 導入および管理ガイド に従って、Red Hat Enterprise Linux 7 ホストマシンの仮想化を有効にします。
5.3.1. ISO イメージのダウンロード
手順
- Red Hat カスタマーポータル から最新の Red Hat Enterprise Linux ISO Image をダウンロードします。
-
イメージを
/var/lib/libvirt/images
ディレクトリーに移動します。
5.3.2. ISO イメージからの仮想マシンの作成
手順
- 仮想化用のホストマシンを有効にしていることを確認します。仮想化パッケージのインストールに関する情報および手順は、既存の Red Hat Enterprise Linux システム上への仮想化パッケージのインストール を参照してください。
基本的な Red Hat Enterprise Linux 仮想マシンを作成し、起動します。仮想マシンの作成手順は、仮想マシンの作成 を参照してください。
コマンドラインを使用して仮想マシンを作成する場合は、デフォルトのメモリーと CPU を仮想マシンの容量に設定するようにしてください。仮想ネットワークインターフェイスを virtio に設定します。
基本的なコマンドラインの例を以下に示します。
virt-install --name _vmname_ --memory 2048 --vcpus 2 --disk size=8,bus=virtio --location rhel-7.0-x86_64-dvd.iso --os-variant=rhel7.0
virt-manager アプリケーションを使用して仮想マシンを作成する場合は、virt-manager を使用したゲストの作成 の手順を実行します。以下の点に注意してください。
- 仮想マシンをすぐに起動 は選択しないでください。
- メモリー と ストレージのサイズ を、希望の設定に変更します。
- インストールを開始する前に、仮想ネットワークインターフェイス設定 で モデル を virtio に変更し、vCPUs を仮想マシンの容量設定に変更していることを確認します。
5.3.3. RHEL インストールの完了
仮想マシンが起動したら、以下の手順を実行してインストールを完了し、root アクセスを有効にします。
手順
- インストールプロセス中に使用する言語を選択します。
インストール概要 ビューで、以下を行います。
- ソフトウェアの選択 をクリックし、最小インストール を選択します。
- 完了 をクリックします。
インストール先 をクリックし、ストレージ設定 で カスタム を選択します。
-
/boot
で、500 MB 以上であることを確認してください。残りの領域は、root/
に使用できます。 - 標準のパーティションが推奨されますが、論理ボリューム管理 (LVM) を使用することも可能です。
- ファイルシステムには、xfs、ext4、ext3 などを使用できます。
- 変更が完了したら、完了 をクリックします。
-
- インストールの開始 をクリックします。
- Root パスワード を設定します。
-
インストールが完了したら、仮想マシンを再起動して
root
でログインします。 イメージを設定します。
注記cloud-init
パッケージがインストールされ、有効になっていることを確認します。- 仮想マシンの電源をオフにします。
5.4. RHEL イメージの GCP へのアップロード
ホストマシンで本セクションにある手順に従って、イメージを GCP にアップロードします。
5.4.1. GCP での新規プロジェクトの作成
GCP で新規プロジェクトを作成するには、以下の手順を行います。
前提条件
GCP でアカウントを作成している。作成していない場合は、Google Cloud で詳細を参照してください。
手順
- GCP コンソール を起動します。
- Google Cloud Platform の右側にあるドロップダウンメニューをクリックします。
- ポップアップメニューから 新しいプロジェクト をクリックします。
- 新しいプロジェクト ウィンドウに、新規プロジェクトの名前を入力します。
- 組織 を確認します。ドロップダウンメニューをクリックして、必要に応じて組織を変更します。
- 親組織またはフォルダーの 場所 を確認します。参照 をクリックして検索し、必要に応じてこの値を変更します。
作成 をクリックして、新しい GCP プロジェクトを作成します。
注記Google Cloud SDK をインストールしたら、CLI コマンドの
gcloud projects create
を使用してプロジェクトを作成できます。簡単な例を以下に示します。gcloud projects create my-gcp-project3 --name project3
この例では、プロジェクト ID
my-gcp-project3
とプロジェクト名project3
のプロジェクトを作成します。詳細は、gcloud project create を参照してください。
関連情報
5.4.2. Google Cloud SDK のインストール
Google Cloud SDK をインストールするには、以下の手順を行います。
前提条件
- GCP でプロジェクトがない場合は、これを作成します。詳細は Google Cloud Platform でプロジェクトの新規作成 を参照してください。
- ホストシステムに Python 2.7 以降が含まれることを確認します。そうでない場合は、Python 2.7 をインストールします。
手順
- GCP の説明に従って、Google Cloud SDK アーカイブをダウンロードし、抽出します。詳細は、GCP ドキュメント Quickstart for Linux を参照してください。
Google Cloud SDK の初期化と同じ手順に従います。
注記Google Cloud SDK を初期化すると、
gcloud
CLI コマンドを使用してタスクを実行でき、プロジェクトとインスタンスに関する情報を取得できます。たとえば、gcloud compute project-info describe --project <project-name>
コマンドを使用してプロジェクト情報を表示できます。
5.4.3. Google Compute Engine の SSH 鍵の作成
以下の手順に従って、GCE で SSH 鍵を生成して登録し、そのパブリック IP アドレスを使用してインスタンスに直接 SSH 接続できるようにします。
手順
ssh-keygen
コマンドを使用して、GCE で使用する SSH 鍵ペアを生成します。# ssh-keygen -t rsa -f ~/.ssh/google_compute_engine
- GCP Console Dashboard ページ から、Google の Cloud Console バナー の左側にある ナビゲーション メニューをクリックし、Compute Engine を選択して Metadata を選択します。
- SSH 鍵 をクリックして、編集 をクリックします。
~/.ssh/google_compute_engine.pub
ファイルから生成された出力を入力し、保存 をクリックします。これで、標準の SSH を使用してインスタンスに接続できます。
# ssh -i ~/.ssh/google_compute_engine <username>@<instance_external_ip>
gcloud compute config-ssh
コマンドを実行すると、インスタンスのエイリアスを設定ファイルに追加できます。エイリアスは、インスタンス名による単純な SSH 接続を許可します。gcloud compute config-ssh
コマンドの詳細は、gcloud compute config-ssh を参照してください。
5.4.4. GCP ストレージでのストレージバケットの作成
GCP にインポートするには、GCP Storage バケットが必要です。以下の手順に従って、バケットを作成します。
手順
GCP にログインしていない場合は、次のコマンドを実行してログインします。
# gcloud auth login
ストレージバケットを作成します。
# gsutil mb gs://bucket_name
注記Google Cloud コンソールを使用してバケットを作成することもできます。詳細は、バケットの作成 を参照してください。
関連情報
5.4.5. GCP バケットへのイメージの変換およびアップロード
以下の手順に従って、GCP バケットにイメージを変換してアップロードします。サンプルは典型的なものです。qcow2
イメージを raw
形式に変換してから、そのイメージをアップロードするために tar を使用します。
手順
qemu-img
コマンドを実行してイメージを変換します。変換されたイメージは、disk.raw
という名前になるはずです。# qemu-img convert -f qcow2 -O raw rhel-sample.qcow2 disk.raw
イメージに tar コマンドを実行します。
# tar --format=oldgnu -Sczf disk.raw.tar.gz disk.raw
そのイメージを、以前作成したバケットにアップロードします。アップロードには数分かかる場合があります。
# gsutil cp disk.raw.tar.gz gs://bucket_name
検証手順
- Google Cloud Platform のホーム画面で、折りたたまれたメニューアイコンをクリックし、ストレージ を選択してから ブラウザー を選択します。
バケットの名前をクリックします。
バケット名の下に、tar コマンドを実行したイメージが表示されます。
注記GCP コンソール を使用してイメージをアップロードすることもできます。これを行うには、バケットの名前をクリックしてから ファイルのアップロード をクリックします。
関連情報
5.4.6. GCP バケットのオブジェクトからイメージの作成
以下の手順に従って、GCP バケットのオブジェクトからイメージを作成します。
手順
以下のコマンドを実行して GCE のイメージを作成します。作成するイメージの名前、バケット名、および tar コマンドを実行したイメージの名前を指定します。
# gcloud compute images create my-image-name --source-uri gs://my-bucket-name/disk.raw.tar.gz
注記または、Google Cloud コンソールを使用して、イメージを作成することもできます。詳細は、カスタムイメージの作成、削除、および中止 を参照してください。
必要に応じて、GCP コンソールでイメージを検索します。
- Google Cloud Console バナーの左側にある ナビゲーション メニューをクリックします。
- Compute Engine を選択し、イメージ を選択します。
5.4.7. イメージからの Google Compute Engine インスタンスの作成
GCP コンソールを使用して GCE 仮想マシンインスタンスを設定するには、以下の手順を行います。
以下の手順では、GCP コンソールを使用して基本的な仮想マシンインスタンスを作成する方法を説明します。GCE 仮想マシンインスタンスおよびその設定オプションの詳細は、VM インスタンスの作成と起動 を参照してください。
手順
- GCP Console Dashboard ページ から、Google の Cloud Console バナー の左側にある ナビゲーション メニューをクリックし、Compute Engine を選択して イメージ を選択します。
- イメージを選択します。
- インスタンスの作成 をクリックします。
- インスタンスの作成 ページで、インスタンスの 名前 を入力します。
- 地域 と ゾーン を選択します。
- ワークロードの要件を満たす、もしくは超過する マシン設定 を選択します。
- ブートディスク にイメージ名が指定されていることを確認します。
- 必要に応じて、ファイアウォール で HTTP トラフィックを許可する か、HTTPS トラフィックを許可する を選択します。
作成 をクリックします。
注記これらは、基本インスタンスの作成に必要な最小限の設定オプションです。アプリケーション要件に応じて追加オプションを確認します。
- VM インスタンス にあるイメージを見つけます。
GCP Console Dashboard から、Google の Cloud Console バナー の左側にある ナビゲーション メニューをクリックし、Compute Engine を選択してから 仮想マシンインスタンス を選択します。
注記または、CLI コマンド
gcloud compute instances create
を使用して、イメージから GCE 仮想マシンインスタンスを作成することもできます。簡単な例を以下に示します。gcloud compute instances create myinstance3 --zone=us-central1-a --image test-iso2-image
この例では、既存のイメージ
test-iso2-image
に基づいて、ゾーンus-central1-a
にmyinstance3
という名前の仮想マシンインスタンスを作成します。詳細は、gcloud compute instances create を参照してください。
5.4.8. インスタンスへの接続
以下の手順に従って、そのパブリック IP アドレスを使用して GCE インスタンスに接続します。
手順
次のコマンドを実行して、インスタンスが実行されていることを確認します。このコマンドは、インスタンスが実行しているかどうかを示し、実行している場合は実行中のインスタンスのパブリック IP アドレスなど、GCE インスタンスに関する情報一覧を表示します。
# gcloud compute instances list
標準の SSH を使用してインスタンスに接続します。この例では、上述の手順で作成した
google_compute_engine
キーを使用します。# ssh -i ~/.ssh/google_compute_engine <user_name>@<instance_external_ip>
注記GCP は、インスタンスに対して SSH を多数実行する方法を提供します。詳細は、Connecting to instances を参照してください。
5.4.9. Red Hat サブスクリプションの割り当て
Red Hat Cloud Access プログラムで有効になっているサブスクリプションを割り当てるには、以下の手順を行います。
前提条件
サブスクリプションが有効になっている。
手順
システムを登録します。
subscription-manager register --auto-attach
サブスクリプションを割り当てます。
- アクティベーションキーを使用して、サブスクリプションを割り当てることができます。カスタマーポータルのアクティベーションキーを作成する を参照してください。
- または、サブスクリプションプール (Pool ID) の ID を使用してサブスクリプションを手動で割り当てることができます。コマンドラインでのサブスクリプションのアタッチと削除 を参照してください。
第6章 Google Cloud Platform での Red Hat High Availability クラスターの設定
本章では、Google Compute Engine (GCE) 仮想マシンインスタンスをクラスターノードとして使用して、Google Cloud Platform (GCP) に Red Hat High Availability (HA) クラスターを設定する情報および手順を説明します。
本章には、GCP の環境を設定するための前提条件の手順が含まれています。環境を設定したら、GCP 仮想マシンインスタンスを作成および設定できます。
本章では、個別のノードを GCP の HA ノードのクラスターに変換する HA クラスターの作成に固有の手順も説明します。これには、各クラスターノードに高可用性パッケージおよびエージェントをインストールし、フェンシングを設定し、GCP ネットワークリソースエージェントをインストールする手順が含まれます。
この章では、GCP のドキュメントを参照している箇所が多数あります。詳細は、記載の GCP ドキュメントを参照してください。
前提条件
- GCP ソフトウェア開発きっと (SDK) をインストールする必要があります。詳細は、Google クラウド SDK のインストール を参照してください。
- Red Hat Cloud Access プログラム でサブスクリプションを有効にします。Red Hat Cloud Access プログラムでは、Red Hat のサブスクリプションを、物理システムまたはオンプレミスシステムから、Red Hat のフルサポートのある GCP へ移動できます。
- アクティブな GCP プロジェクトに属し、プロジェクトでリソースを作成するのに十分なパーミッションを持っている必要があります。
- プロジェクトには、個別ユーザーではなく、仮想マシンインスタンスに属する サービスアカウント が必要です。別のサービスアカウントを作成する代わりに、デフォルトのサービスアカウントを使用する方法は、Using the Compute Engine Default Service Account を参照してください。
またはプロジェクト管理者がカスタムサービスアカウントを作成する場合、サービスアカウントは以下のロールに設定する必要があります。
- クラウドトレースエージェント
- コンピュート管理者
- コンピュートネットワーク管理者
- クラウドデータベースユーザー
- ロギング管理者
- 監視エディター
- 監視メトリックライター
- サービスアカウント管理者
- ストレージ管理者
関連情報
- Support Policies for RHEL High Availability Clusters - Google Cloud Platform Virtual Machines as Cluster Members
- Support Policies for RHEL High Availability clusters - Transport Protocols
- VPC network overview
- Exploring RHEL High Availability's Components, Concepts, and Features - Overview of Transport Protocols
- Design Guidance for RHEL High Availability Clusters - Selecting the Transport Protocol
- Quickstart for Red Hat and Centos
6.1. GCP での Red Hat Enterprise Linux イメージオプション
以下の表には、イメージの選択肢を記載し、イメージオプションの相違点を示しています。
表6.1 イメージオプション
イメージオプション | サブスクリプション | サンプルシナリオ | 留意事項 |
---|---|---|---|
GCP に移動するカスタムイメージをデプロイすることを選択する | 既存の Red Hat サブスクリプションを活用する | Red Hat Cloud Access プログラム を使用してサブスクリプションを有効にし、カスタムイメージをアップロードし、サブスクリプションを割り当てます。 | その他のすべてのインスタンスコストを支払うことになりますが、サブスクリプション自体には Red Hat 製品コストが含まれます。 GCP に移行するカスタムイメージは、既存の Red Hat サブスクリプションを活用するため、クラウドアクセスイメージと呼ばれています。Red Hat は、クラウドアクセスイメージを直接サポートします。 |
RHEL を含む既存の GCP イメージをデプロイすることを選択する | GCP イメージには、Red Hat 製品が含まれる | GCP Compute Engine でインスタンスを起動する時に RHEL イメージを選択するか、Google Cloud Platform Marketplace からイメージを選択します。 | 従量課金モデルでは、GCP に 1 時間ごとに支払います。このようなイメージはオンデマンドイメージと呼ばれています。GCP は、サポート契約に基づいてオンデマンドイメージのサポートを提供します。 |
オンデマンドインスタンスは、Red Hat Cloud Access インスタンスに変換できません。オンデマンドイメージから Red Hat Cloud Access bring-your-own subscription (BYOS) イメージに変更するには、Red Hat Cloud Access インスタンスを新たに作成し、オンデマンドインスタンスからデータを移行します。データを移行した後に、オンデマンドのインスタンスをキャンセルして二重請求を回避します。
本章の残りの部分には、カスタムイメージに関する情報および手順が記載されています。
6.2. 必要なシステムパッケージ
本章の手順では、Red Hat Enterprise Linux を実行しているホストシステムを使用していることを前提としています。この手順を正常に行うには、ホストシステムに以下のパッケージをインストールする必要があります。
表6.2 システムパッケージ
パッケージ | 詳細 | コマンド |
---|---|---|
qemu-kvm | このパッケージは、ユーザーレベルの KVM エミュレーターを使用し、ホストとゲスト仮想マシン間の通信を容易にします。 |
|
qemu-img | このパッケージは、ゲスト仮想マシンのディスク管理を提供します。qemu-img パッケージは qemu-kvm パッケージの依存関係としてインストールされます。 | |
libvirt | このパッケージは、ハイパーバイザーおよびホストシステムと対話するためにサーバーおよびホスト側のライブラリーを提供し、ライブラリー呼び出しの処理、仮想マシンの管理およびハイパーバイザーの制御を行う libvirtd デーモンも提供します。 |
表6.3 その他の仮想化パッケージ
パッケージ | 詳細 | コマンド |
---|---|---|
virt-install |
このパッケージは、コマンドラインからの仮想マシンを作成するために |
|
libvirt-python | このパッケージは、Python プログラミング言語で書かれているアプリケーションが libvirt API で提供されるインターフェイスを使用できるようにするモジュールが含まれています。 | |
virt-manager | このパッケージには、仮想マシンマネージャー (VMM) と呼ばれる virt-manager ツールが含まれます。VMM は、仮想マシンを管理するためのグラフィカルツールです。管理 API として libvirt-client ライブラリーを使用します。 | |
libvirt-client |
このパッケージは、libvirt サーバーにアクセスするためのクライアント側の API とライブラリーを提供します。libvirt-client パッケージには、コマンドラインまたは特別な仮想化シェルから仮想マシンとハイパーバイザーを管理および制御する |
関連情報
6.3. HA パッケージおよびエージェントのインストール
全ノードで以下の手順を実行し、High Availability パッケージおよびエージェントをインストールします。
手順
すべてのリポジトリーを無効にします。
# subscription-manager repos --disable=*
RHEL 7 Server リポジトリーおよび RHEL 7 Server HA リポジトリーを有効にします。
# subscription-manager repos --enable=rhel-7-server-rpms # subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
すべてのパッケージを更新します。
# yum update -y
pcs pacemaker
、fence agent およびリソースエージェントをインストールします。# yum install -y pcs pacemaker fence-agents-gce resource-agents-gcp
カーネルを更新したら、マシンを再起動します。
# reboot
6.4. HA サービスの設定
高可用性サービスを設定するには、すべてのノードで以下の手順を実行します。
手順
hacluster
ユーザーは、前の手順でpcs
およびpacemaker
のインストール時に作成されました。すべてのクラスターノードにhacluster
ユーザーのパスワードを作成します。すべてのノードに同じパスワードを使用します。# passwd hacluster
firewalld
サービスが有効になっている場合は、RHEL に高可用性サービスを追加します。# firewall-cmd --permanent --add-service=high-availability # firewall-cmd --reload
pcs
サービスを起動し、システムの起動時に開始できるようにします。# systemctl enable pcsd.service --now
検証手順
pcs
サービスが実行していることを確認します。# systemctl is-active pcsd.service
6.5. クラスターの作成
ノードのクラスターを作成するには、以下の手順を実施します。
手順
ノードのいずれかで以下のコマンドを実行し、pcs ユーザー
ha cluster
を認証します。クラスターの各ノードの名前を指定します。# pcs cluster auth _hostname1_ _hostname2_ _hostname3_ -u hacluster
たとえば、以下のようになります。
[root@node01 ~]# pcs cluster auth node01 node02 node03 -u hacluster node01: Authorized node02: Authorized node03: Authorized
クラスターを作成します。
# pcs cluster setup --name cluster-name _hostname1_ _hostname2_ _hostname3_
検証手順
クラスターを有効にします。
# pcs cluster enable --all
クラスターを起動します。
# pcs cluster start --all
6.6. フェンスデバイスの作成
ほとんどのデフォルト設定では、GCP インスタンス名と RHEL ホスト名は同じです。
クラスター内の任意のノードからフェンシングを設定するには、以下の手順を実施します。
手順
クラスターの任意のノードから GCP インスタンス名を取得します。出力には、インスタンスの内部 ID も表示されることに注意してください。
# fence_gce --zone _gcp_ _region_ --project= _gcp_ _project_ -o list
たとえば、以下のようになります。
[root@rhel71-node-01 ~]# fence_gce --zone us-west1-b --project=rhel-ha-testing-on-gcp -o list 44358**********3181,InstanceName-3 40819**********6811,InstanceName-1 71736**********3341,InstanceName-2
フェンスデバイスを作成します。
pcmk_host-name
コマンドを使用して、RHEL ホスト名をインスタンス ID にマッピングします。# pcs stonith create _clusterfence_ fence_gce pcmk_host_map=_pcmk-hpst-map_ fence_gce zone=_gcp-zone_ project=_gcpproject_
たとえば、以下のようになります。
[root@node01 ~]# pcs stonith create fencegce fence_gce pcmk_host_map="node01:node01-vm;node02:node02-vm;node03:node03-vm" project=hacluster zone=us-east1-b
検証手順
他のノードのいずれかに対してフェンスエージェントをテストします。
# pcs stonith fence gcp nodename
ステータスを確認して、ノードがフェンスされていることを確認します。
# watch pcs status
たとえば、以下のようになります。
[root@node01 ~]# watch pcs status Cluster name: gcp-cluster Stack: corosync Current DC: rhel71-node-02 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum Last updated: Fri Jul 27 12:53:25 2018 Last change: Fri Jul 27 12:51:43 2018 by root via cibadmin on rhel71-node-01 3 nodes configured 3 resources configured Online: [ rhel71-node-01 rhel71-node-02 rhel71-node-03 ] Full list of resources: us-east1-b-fence (stonith:fence_gce): Started rhel71-node-01 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
6.7. GCP ノードの承認の設定
アカウント認証情報を使用して GCP にアクセスするようにクラウドの SDK ツールを設定します。
手順
各ノードで次のコマンドを実行し、プロジェクト ID およびアカウントの認証情報で各ノードを初期化します。
# gcloud-ra init
6.8. GCP ネットワークリソースエージェントの設定
クラスターは、実行中のインスタンスにセカンダリー IP アドレス (エイリアス IP) を 割り当てた GCP ネットワークリソースエージェントを使用します。これは、クラスター内の異なるノード間で渡すことのできるフローティング IP アドレスです。
手順
以下のコマンドを入力して、GCP 仮想 IP アドレスリソースエージェント (gcp-vpc-move-vip) の説明を表示します。これは、このエージェントのオプションとデフォルトの操作を示しています。
# pcs resource describe gcp-vpc-move-vip
リソースエージェントを、プライマリーサブネットアドレス範囲またはセカンダリーサブネットアドレス範囲を使用するように設定できます。本セクションでは、両方の手順を説明します。
プライマリーサブネットアドレス範囲
手順
プライマリー VPC サブネットのリソースを設定するには、以下の手順を実行します。
aliasip
リソースを作成します。未使用の内部 IP アドレスを含めます。コマンドに CIDR ブロックを含めます。# pcs resource create aliasip gcp-vpc-move-vip alias_ip=_UnusedIPaddress/CIDRblock_ --group _group-name_ --group _networking-group_
ノード上の IP を管理する
IPaddr2
リソースを作成します。# pcs resource create vip IPaddr2 nic=_interface_ ip=_AliasIPaddress_ cidr_netmask=32 --group _group-name_ --group _networking-group_
vipgrp
でネットワークリソースをグループ化します。# pcs resource group add vipgrp aliasip vip
検証手順
リソースが起動し、
vipgrp
でグループ化されていることを確認します。# pcs status
リソースが別のノードに移動できることを確認します。
# pcs resource move vip _Node_
たとえば、以下のようになります。
# pcs resource move vip rhel71-node-03
別のノードで
vip
が正常に起動することを確認します。# pcs status
セカンダリーサブネットアドレス範囲
セカンダリーサブネットアドレス範囲のリソースを設定するには、以下の手順を実施します。
手順
セカンダリーサブネットアドレス範囲を作成します。
# gcloud-ra compute networks subnets update _SubnetName_ --region _RegionName_ --add-secondary-ranges _SecondarySubnetName_=_SecondarySubnetRange_
たとえば、以下のようになります。
# gcloud-ra compute networks subnets update range0 --region us-west1 --add-secondary-ranges range1=10.10.20.0/24
aliasip
リソースを作成します。セカンダリーサブネットアドレス範囲に未使用の内部 IP アドレスを作成します。コマンドに CIDR ブロックを含めます。# pcs resource create aliasip gcp-vpc-move-vip alias_ip=_UnusedIPaddress/CIDRblock_ --group _group-name_ --group _networking-group_
ノード上の IP を管理する
IPaddr2
リソースを作成します。# pcs resource create vip IPaddr2 nic=_interface_ ip=_AliasIPaddress_ cidr_netmask=32 --group _group-name_ --group _networking-group_
検証手順
リソースが起動し、
vipgrp
でグループ化されていることを確認します。# pcs status
リソースが別のノードに移動できることを確認します。
# pcs resource move vip _Node_
たとえば、以下のようになります。
[root@rhel71-node-01 ~]# pcs resource move vip rhel71-node-03
別のノードで
vip
が正常に起動することを確認します。# pcs status