1. はじめに
IBM CloudのVirtual Server for VPCにおいては、現在システムバックアップを取得する機能がありません。
そこで、本記事では、IBM CloudのVPCのVSI(Virtual Server)のシステム・バックアップ方法について、Virtual Server for Classicとの違いを元に、Virtual Server for VPCの機能を利用したシステムバックアップの代替策を記載します。
後半では、いくつかのパラメータの変化を確認しました。
Image Templateを取得しているためデータや設定は基本的に変更されていないはずですが、Image templateという複数のサーバーを生成する仕組みの上で、元のサーバーと変わってしまっていないかという箇所を重点的に選択して確認してみました。
Virtual Private Cloud (VPC)のシステムバックアップ、及び、代替策
しかしながら、IBM CloudのVPC上のVSIにはClassicのような、イメージからブートする・ロードするといった機能に相当する機能がなく、VPCのVSIでOSのリカバリが必要となった場合、新たにVSIを作成する方法しかございません。この場合、通常のオペレーションでは、IPアドレスなどが変更されてしまい、システムバックアップとしては利用できないこととなります。
そこでシステムバックアップの代替策として、VSIのimage template機能を利用した手順をご案内いたします。この手順に則れば、OSの構成やソフトウェアの導入・構成など、起動ディスクに関する構成情報をリストアすることが可能となり、システムバックアップと同等の効果を得ることができます。(あくまで代替案ですので、ご理解ください...)
バックアップ手順:
1. boot volumeのイメージを作成
リストア手順:
1. リストア対象のVSIを削除
2. イメージリストア用のAPIコマンドの作成(そこで、IPアドレスを指定)
3. APIコマンドの実行
システムリストアで、元のVSIと同じIPアドレスを付与する場合、IPアドレスがかぶらないように、新規VSI作成前に古いVSIを削除しておく必要があります。
2. VPC上のVSIのバックアップ作成 & リストアストア手順について
以下の流れに沿って、手順についてご紹介いたします。
1. 今回利用したバックアップ対象環境概要
2. イメージを利用したバックアップ手順
3. リストア手順
4. リストア後の確認(パラメータなどの変更点の確認)
2-1. 今回利用したバックアップ対象環境概要
今回利用したVSIの概要について説明いたします。イメージ作成するVSIのOSは以下の通りです。
a) OS: Red Hat Enterprise Linux 8.4 (Ootpa)
b) Data Volume: 50GBをattach
2-2 バックアップの取得(boot volumeイメージの作成)
VSIの詳細画面からアクションメニュー → インスタンスの停止を選択し、対象のVSIを停止します。
※ boot volumeイメージの作成する場合は、システム停止が必須となります。
- VSIの詳細画面から
アクションメニュー
→インスタンスの停止
を選択し、対象のVSIを停止します。
※Data Volumeはsnapshot機能を用いてバックアップを取得しました。
3. システム・リストア方法
3-0. 削除前の注意
サーバーを削除する前に、以下をご確認ください。
- 可能であれば一度同じVPC or 異なるVPCで、Image templateを使ってサーバーが正しくプロビジョニングできることを確認する。
- 異なるVPCであれば同じIPアドレスが使用可能です。
- Boot volumeも自動削除を無効にしておき、万が一消去された設定があったときにリストアできるように備えておく。新環境の十分な確認を以って削除する。
3-1. リストア対象のVSIを削除
VSIの詳細画面からアクションメニュー
→ インスタンスの削除
を選択し、対象のVSIを停止します。
3-2. イメージリストア用のAPIコマンドの作成(そこで、IPアドレスを指定)
1.インスタンス作成画面にて、オペレーティング・システム
→ カスタム・イメージ
からリストア対象VSIのイメージを選択し、サンプルAPI呼び出しの取得
をクリックします。
2.以下のような画面が表示されるので赤枠部分をクリックしてコピーし、シェルスクリプトとして保存します。
(create_vsi.shファイルを作成し、コピーしたものを中にペースト)
3.IPアドレスの指定がないので、primary_netowork_interface
内に primary_ipv4_address
フィールドを追加します。
(省略)
"primary_network_interface": {
"name": "eth0",
"primary_ipv4_address": "10.0.1.5", # <- この行を追加
"allow_ip_spoofing": false,
"subnet": {
"id": "02e7-ff96ff2a-fa27-4d88-b855-98fb85112636"
},
"security_groups": [
{
"id": "r022-1a2bb9f2-7647-4332-8a1b-eb925fb6e160"
}
]
},
(省略)
3-3. リストアのAPIコマンドの実行
1.IAMトークンの取得 コピーしたAPIを実行する際に$iam_tokenを使用するので、以下のコマンドでIAMトークンを取得します。
アクセストークン取得に関しての詳細はこちら。
# export iam_token=`ibmcloud iam oauth-tokens | awk '{printf $4}'`
2.シェルスクリプトを実行すると、VSIが作成されます。
# sh create_vsi.sh
{"bandwidth":4000,"boot_volume_attachment":......
(省略)
3.VSI作成されたことを確認
これで無事にリストアすることができました。
IPアドレスもリストア対象のVSIと同じものが割り当てられています。
Data Volumeについては、Snapshotから復元してattachしました。
4. リストア後の確認(パラメータなどの変更点の確認)
リストア前後の変更点を、以下のパラメータで確認してみます。
1. IPアドレス・MACアドレス
2. uuid
3. machine id
4. ip routeコマンド
5. /etc/ssh/sshd_config ファイル
6. ~/.ssh/配下
4-1. IPアドレス、MACアドレス
MACアドレスは変更されています。
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 02:00:08:0e:74:a5 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.5/26 brd 10.0.1.63 scope global dynamic noprefixroute eth0
valid_lft 327sec preferred_lft 327sec
inet6 fe80::8ff:fe0e:74a5/64 scope link
valid_lft forever preferred_lft forever
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 02:00:02:0e:74:a5 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.5/26 brd 10.0.1.63 scope global dynamic noprefixroute eth0
valid_lft 200sec preferred_lft 200sec
inet6 fe80::2ff:fe0e:74a5/64 scope link
valid_lft forever preferred_lft forever
4-2. uuid
2つのコマンドで確認し、uuidは異なるidが付与されていました。
# cat /sys/devices/virtual/dmi/id/product_uuid
61a3ca85-7c12-41ff-bc25-8f7a0f6a6559
# dmidecode -s system-uuid
61a3ca85-7c12-41ff-bc25-8f7a0f6a6559
# cat /sys/devices/virtual/dmi/id/product_uuid
9e3c5e58-7772-435a-82a7-867c534b9847
# dmidecode -s system-uuid
9e3c5e58-7772-435a-82a7-867c534b9847
また、Volumeのuuidは、vda配下に変化はありませんでした。
# lsblk -pf
NAME FSTYPE LABEL UUID MOUNTPOINT
/dev/vda
├─/dev/vda1
├─/dev/vda2 vfat 7B77-95E7 /boot/efi
└─/dev/vda3 xfs root d47ead13-ec24-428e-9175-46aefa764b26 /
/dev/vdb
/dev/vdc iso9660 cidata 2021-11-03-06-01-14-00
/dev/vdd swap SWAP-xvdb1 32456c80-7060-4ba9-8e38-7da59c08facc
#
# lsblk -pf
NAME FSTYPE LABEL UUID MOUNTPOINT
/dev/vda
├─/dev/vda1
├─/dev/vda2 vfat 7B77-95E7 /boot/efi
└─/dev/vda3 xfs root d47ead13-ec24-428e-9175-46aefa764b26 /
/dev/vdb
/dev/vdc iso9660 cidata 2021-11-04-06-17-43-00
/dev/vdd swap SWAP-xvdb1 e4385e9f-3bc2-4786-aef3-b981c944ea55
4-3. machine id
machine idに変化はありませんでした。
# hostnamectl
Static hostname: vsi-backup
Icon name: computer-vm
Chassis: vm
Machine ID: 7fa98b608ea40d90149abb93ba5df113
Boot ID: 91fa86323ca541be8d203a8ebded0e2c
Virtualization: kvm
Operating System: Red Hat Enterprise Linux 8.4 (Ootpa)
CPE OS Name: cpe:/o:redhat:enterprise_linux:8.4:GA
Kernel: Linux 4.18.0-305.7.1.el8_4.x86_64
Architecture: x86-64
# hostnamectl
Static hostname: vsi-backup
Icon name: computer-vm
Chassis: vm
Machine ID: 7fa98b608ea40d90149abb93ba5df113
Boot ID: 69c197fa5c9242a0af97be846ffa975f
Virtualization: kvm
Operating System: Red Hat Enterprise Linux 8.4 (Ootpa)
CPE OS Name: cpe:/o:redhat:enterprise_linux:8.4:GA
Kernel: Linux 4.18.0-305.7.1.el8_4.x86_64
Architecture: x86-64
4-4. ip routeコマンド
リストア前に以下を追加しました。
192.168.0.0/24 via 10.0.1.1 dev eth0 proto static metric 100
結果、ルーティングテーブルは変更を加えた箇所は、リストア後に反映されていませんでした。
# ip r
default via 10.0.1.1 dev eth0
default via 10.0.1.1 dev eth0 proto dhcp metric 100
192.168.0.0/24 via 10.0.1.1 dev eth0 proto static metric 100
10.0.1.0/26 dev eth0 proto kernel scope link src 10.0.1.5 metric 100
# ip r
default via 10.0.1.1 dev eth0
default via 10.0.1.1 dev eth0 proto dhcp metric 100
10.0.1.0/26 dev eth0 proto kernel scope link src 10.0.1.5 metric 100
4-5. /etc/ssh/sshd_config ファイル
ファイルの編集部分に変化はありませんでした。
(中略)
#ClientAliveInterval 0
#ClientAliveCountMax 3
ClientAliveInterval 30
ClientAliveCountMax 3
(中略)
#ClientAliveInterval 0
#ClientAliveCountMax 3
ClientAliveInterval 30
ClientAliveCountMax 3
4-6. ~/.ssh/配下
sshする際に使用する公開鍵を、リストア前は鍵を1つ、リストア後は鍵を2つ、IBM Cloudポータルにて指定しました。
また、リストア前にbackup-test.txt
ファイルを別で作成しました。
authorized_keysファイルのみ中身が変化していました。
# cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC...
(中略)
== [追加したkey元PC①]
#
# cat backup-test.txt
backup test
# cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC...
(中略)
...OcZ8oHCQ== [追加したkey元PC①]
ssh-rsa AAAAB3NzaC...
(中略)
...OZc4fxQ== [追加したkey元PC②]
#
# cat backup-test.txt
backup test
5. リカバリの際にも元のVSIを残しておく運用方法を取りたいと言う場合
最初からCLIかAPIを使ってsecondary Interfaceを定義して利用するIP addressを明示的に指定してください。リカバリの際には、一旦異なるprimary IP addressで新たなVSIを作成し、元のVSIからsecondary IP addressを削除して、新たなVSIにsecondary interfaceとそのIP addressを明示的に指定して追加することで、secondary IP addressを旧VSIから新VSIに移動してください。
注意
Imageの作成の際には、VSIを停止する必要があるので、日常的なシステムバックアップとして使うことは難しいと思います。OSのupgradeなど、停止を伴う作業の際に、Imageの作成をし直すなどの工夫が必要でしょう。
参考
IPアドレス指定のプロビジョニングに関して、こちらを参考にさせていただきました。
IBM Cloud: VPCのVSIをIPアドレス指定でプロビジョニングする方法