OpenStackサーバー更改時のトラブル対応(computeノード編)

2025-01-20

OpenStackサーバー更改時のトラブル対応(computeノード編)

記事をシェアする

はじめに

私たちのチームでは、OpenStackを活用して利用者に仮想環境を提供しています。OpenStackは、オープンソースソフトウェア(OSS)のクラウドコンピューティングプラットフォームです。仮想環境上でのマシン、ストレージ、ネットワークなどのリソースを統合管理できるインフラストラクチャを提供します。私たちはこのOpenStackをオンプレミス環境で数年前に導入しました。しかし、当時購入したサーバーの保守期限が近づいていたため、これを機にサーバーの更改作業を進めることになりました。この記事では、その過程で発生したcomputeノードのトラブルと対応内容について紹介します。

サーバー更改の概要

既存OpenStack環境

構築当初のOpenStackのバージョンはMitakaでしたが、数年前にバージョンアップを行い現在はQueensを使用しています。ノードの構成は以下のとおりです。

No.	ノード	台数	OS	更改する台数
1	controller	2	CentOS 7.5.1804	2
2	network	2	CentOS 7.5.1804	2
3	compute	8	CentOS 7.5.1804	4
4	block	4	CentOS 7.5.1804	3
5	object	3	CentOS 7.5.1804	3

OS選定と更改方針

OSは「Ubuntu」を採用しました。選定理由は以下のとおりです。

候補	採否の理由
Ubuntu	OpenStack公式 ⧉でサポートが明記されており、各バージョンにLTS(Long-Term Support)があるため
CentOS Stream	安定版の先行確認環境の位置付けであり、運用上の安定性に懸念があるため
Rocky Linux AlmaLinux	CentOSの後継として利用されているが、OpenStack公式 ⧉ではサポートが明記されていないため

UbuntuのバージョンはUbuntu 18.04 LTSを採用しました。Ubuntu 18.04 LTSのサポート期限は2023年5月であり、本来であればUbuntu 20.04 LTS以上を採用すべきです。しかし、QueensはUbuntu 20.04 LTSに対応しておらず、Ubuntu 20.04 LTSを使用するためには、OpenStackをQueensからUssuriまで4段階もバージョンアップする必要があります。このOSおよびOpenStackのバージョンアップとサーバー更改を同時に行うことは極めて困難であったため、まずはUbuntu 18.04 LTSでサーバー更改を行い、その後、OSおよびOpenStackのバージョンアップを行う方針としました。サーバー更改後の構成は以下のとおりです。

No.	ノード	台数	OS	更改対象
1	controller	2	Ubuntu 18.04.6 LTS	○
2	network	2	Ubuntu 18.04.6 LTS	○
3	compute	4	CentOS 7.5.1804	ー
4	compute	4	Ubuntu 18.04.6 LTS	○
5	block	1	CentOS 7.5.1804	ー
6	block	3	Ubuntu 18.04.6 LTS	○
7	object	3	Ubuntu 18.04.6 LTS	○

更改方法

構築当初の手順書とOpenStack公式 ⧉の手順を参考に、新computeノードをOpenStackに1台追加します。その後、旧computeノード上のインスタンスを移行し、旧computeノードをOpenStackから削除します。この手順を繰り返して作業を進めます。

移行方法

移行対象インスタンス

旧computeノードから新computeノードへ移行するインスタンスは以下のとおりです。

インスタンス種類

※1：OpenStackが提供するデータベースサービスです。データベースのデプロイ、管理、スケーリングを簡単に実行できる仕組みを提供します。詳細についてはOpenStack公式 ⧉を参照してください。
※2：OpenStackが提供する共有ファイルシステムサービスです。仮想マシンやアプリケーションが利用可能な共有ファイルシステムの作成、管理をサポートします。詳細についてはOpenStack公式 ⧉を参照してください。

移行方法

インスタンスの数が多いため、openstackコマンドを用いたスクリプトを作成し、移行作業を自動化します。このスクリプトは、利用者へのサービス影響を最小限に抑えるために、atコマンドを使用し、夜間に実行します。

【スクリプトの処理内容】

インスタンスの状態を確認します。
インスタンスの状態が起動状態の場合、インスタンスを停止状態にします。
指定したcomputeノードにインスタンスを移行します。
上記1～3の処理を全インスタンスについて繰り返します。

スクリプトで使用するopenstackコマンドは以下のとおりです。

openstackコマンド	用途
openstack server show <インスタンスID>	指定したインスタンスの状態を確認する
openstack server stop <インスタンスID>	指定したインスタンスを停止状態にする
openstack server migrate --live <新computeノード名> <インスタンスID>	指定したcomputeノードにインスタンスを移行する

トラブルシューティング

新computeノードでインスタンスが作成できない(設定不足)

新computeノードにOpenStackのパッケージをインストールし、必要なコンフィグファイルを設定した後、Novaコンポーネントのサービスを起動しました。次に、openstack compute service listコマンドを実行したところ、新computeノードのNovaサービスが正常に表示されました。しかし、新computeノード上でインスタンスの作成を試みたところエラーが発生し、computeノードが正常に動作していない状況であることが判明しました。/var/log/nova-compute.logを確認したところ、以下のようなエラーメッセージが出力されていました。

1
ERROR nova.compute.manager [req-35424485-5aae-434e-87fc-7b3472b4bd21 - - - - -] Error updating resources for node compute201dev.: OSError: [Errno 2] No such file or directory: '/usr/lib/python2.7/dist-packages/instances'
2
ERROR nova.compute.manager Traceback (most recent call last):
3
ERROR nova.compute.manager   File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 7579, in update_available_resource_for_node
4
ERROR nova.compute.manager     rt.update_available_resource(context, nodename)
5
ERROR nova.compute.manager   File "/usr/lib/python2.7/dist-packages/nova/compute/resource_tracker.py", line 704, in update_available_resource
6
ERROR nova.compute.manager     resources = self.driver.get_available_resource(nodename)
7
ERROR nova.compute.manager   File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 6475, in get_available_resource
8
ERROR nova.compute.manager     disk_info_dict = self._get_local_gb_info()
9
ERROR nova.compute.manager   File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5744, in _get_local_gb_info
10
ERROR nova.compute.manager     info = libvirt_utils.get_fs_info(CONF.instances_path)
11
ERROR nova.compute.manager   File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/utils.py", line 370, in get_fs_info
12
ERROR nova.compute.manager     hddinfo = os.statvfs(path)
13
ERROR nova.compute.manager OSError: [Errno 2] No such file or directory: '/usr/lib/python2.7/dist-packages/instances'

/etc/nova/nova.confを確認したところ、instances_pathが設定されていなかったため、この設定を追加しました。その後、再度インスタンスの作成を試みたところ、上記のエラーメッセージは出力されなくなりましたが、インスタンスの作成には依然として失敗しました。さらなる調査の結果、openstack hypervisor listコマンドを実行すると、新computeノードが一覧に表示されておらず、何らかの設定が不足していることが判明しました。この問題についてOpenStack公式(Queensバージョン) ⧉を確認したところ、「Add the compute node to the cell database」という項目がありました。この項目の作業に必要な以下のコマンドを実行していなかったことがわかりました。

1
# su -s /bin/bash -c "nova-manage cell_v2 discover_hosts" nova

原因は、この機能はNewtonリリースで導入されたもので、サーバー更改の手順検討時に参照したMitaka構築時の手順にはこのコマンドが記載されていなかったことにありました。このコマンドは、実行中のcomputeノードを発見し、それらをNovaの管理データベースに登録するための操作を行います。このコマンドを実行することで、openstack hypervisor listコマンドで新computeノードが一覧に表示されるようになりました。

新computeノードでインスタンスが作成できない(CPUモデルの未サポート)

新computeノードでインスタンスを作成しようとしましたが、以下のエラーが発生し、作成に失敗しました。

1
Instance failed to spawn: libvirtError: internal error: process exited while connecting to monitor:yyyy-MM-ddTHH:mm:SS.ssssssZ qemu-system-x86_64: CPU feature avx512dq not found

エラーメッセージに記載されている「avx512dq」について調査した結果、これは第3世代Intel Xeon(開発コード名:Ice Lake)で追加された命令セット拡張であることがわかりました。そこで、新旧computeノードのCPUを確認したところ、新computeノードのCPUはIce Lakeを搭載しており、一方で旧computeノードのCPUは第1世代Intel Xeon(開発コード名:Skylake)を搭載していることが判明しました。さらに、libvirt関連のエラーが発生していることから、新旧computeノードにおけるlibvirtdおよびQEMUのバージョンも確認しました。その結果、新computeノードのQEMUバージョンが旧computeノードに比べて古い状態であることが判明しました。

	旧computeノード	新computeノード
libvirtd	3.9.0	4.0.0
QEMU	2.9.0	2.5.0

そこで、QEMUがサポートしているCPUモデルやオプションを確認するため、新computeノードでqemu-system-x86_64 -cpu helpコマンドを実行しました。その結果、新computeノードのQEMUではIce LakeのCPUモデルがサポートされておらず、オプションにも「avx512dq」が含まれていないことが確認できました。

1
# qemu-system-x86_64 -cpu help
2
x86           qemu64  QEMU Virtual CPU version 2.5+
3
x86           phenom  AMD Phenom(tm) 9550 Quad-Core Processor
4
x86         core2duo  Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz
5
x86            kvm64  Common KVM processor
6
x86           qemu32  QEMU Virtual CPU version 2.5+
7
x86            kvm32  Common 32-bit KVM processor
8
x86          coreduo  Genuine Intel(R) CPU           T2600  @ 2.16GHz
9
x86              486
10
x86          pentium
11
x86         pentium2
12
x86         pentium3
13
x86           athlon  QEMU Virtual CPU version 2.5+
14
x86             n270  Intel(R) Atom(TM) CPU N270   @ 1.60GHz
15
x86           Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)
16
x86           Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)
17
x86          Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)
18
x86     Nehalem-IBRS  Intel Core i7 9xx (Nehalem Core i7, IBRS update)
19
x86         Westmere  Westmere E56xx/L56xx/X56xx (Nehalem-C)
20
x86    Westmere-IBRS  Westmere E56xx/L56xx/X56xx (IBRS update)
21
x86      SandyBridge  Intel Xeon E312xx (Sandy Bridge)
22
x86 SandyBridge-IBRS  Intel Xeon E312xx (Sandy Bridge, IBRS update)
23
x86        IvyBridge  Intel Xeon E3-12xx v2 (Ivy Bridge)
24
x86   IvyBridge-IBRS  Intel Xeon E3-12xx v2 (Ivy Bridge, IBRS)
25
x86    Haswell-noTSX  Intel Core Processor (Haswell, no TSX)
26
x86 Haswell-noTSX-IBRS  Intel Core Processor (Haswell, no TSX, IBRS)
27
x86          Haswell  Intel Core Processor (Haswell)
28
x86     Haswell-IBRS  Intel Core Processor (Haswell, IBRS)
29
x86  Broadwell-noTSX  Intel Core Processor (Broadwell, no TSX)
30
x86 Broadwell-noTSX-IBRS  Intel Core Processor (Broadwell, no TSX, IBRS)
31
x86        Broadwell  Intel Core Processor (Broadwell)
32
x86   Broadwell-IBRS  Intel Core Processor (Broadwell, IBRS)
33
x86       Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)
34
x86       Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)
35
x86       Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)
36
x86       Opteron_G4  AMD Opteron 62xx class CPU
37
x86       Opteron_G5  AMD Opteron 63xx class CPU
38
x86             host  KVM processor with all supported host features (only available in KVM mode)
39

40
Recognized CPUID flags:
41
  fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 pn clflush ds acpi mmx fxsr sse sse2 ss ht tm ia64 pbe
42
  pni|sse3 pclmulqdq|pclmuldq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cid fma cx16 xtpr pdcm pcid dca sse4.1|sse4_1 sse4.2|sse4_2 x2apic movbe popcnt tsc-deadline aes xsave osxsave avx f16c rdrand hypervisor
43
  fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f rdseed adx smap pcommit clflushopt clwb avx512pf avx512er avx512cd
44

45
  md-clear spec-ctrl ssbd
46
  syscall nx|xd mmxext fxsr_opt|ffxsr pdpe1gb rdtscp lm|i64 3dnowext 3dnow
47
  lahf_lm cmp_legacy svm extapic cr8legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb
48
  invtsc
49
  ibpb virt-ssbd
50
  xstore xstore-en xcrypt xcrypt-en ace2 ace2-en phe phe-en pmm pmm-en
51
  kvmclock kvm_nopiodelay kvm_mmu kvmclock kvm_asyncpf kvm_steal_time kvm_pv_eoi kvm_pv_unhalt kvmclock-stable-bit
52
  npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pause_filter pfthreshold
53
  xsaveopt xsavec xgetbv1 xsaves
54
  arat

以上の調査結果を踏まえ、CPUモデルにIce Lakeをサポートし、「avx512dq」オプションを含むQEMUバージョンにすれば、インスタンスを起動できると考えました。この仮説に基づき、QEMUのバージョンを順番に更新したところ、バージョン「2.11.1」で期待通りの結果が得られました。

1
# qemu-system-x86_64 -cpu help
2
Available CPUs:
3
x86              486
4
x86   Broadwell-IBRS  Intel Core Processor (Broadwell, IBRS)
5
x86 Broadwell-noTSX-IBRS  Intel Core Processor (Broadwell, no TSX, IBRS)
6
x86  Broadwell-noTSX  Intel Core Processor (Broadwell, no TSX)
7
x86        Broadwell  Intel Core Processor (Broadwell)
8
x86 Cascadelake-Server  Intel Xeon Processor (Cascadelake)
9
x86           Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)
10
x86        EPYC-IBPB  AMD EPYC Processor (with IBPB)
11
x86             EPYC  AMD EPYC Processor
12
x86     Haswell-IBRS  Intel Core Processor (Haswell, IBRS)
13
x86 Haswell-noTSX-IBRS  Intel Core Processor (Haswell, no TSX, IBRS)
14
x86    Haswell-noTSX  Intel Core Processor (Haswell, no TSX)
15
x86          Haswell  Intel Core Processor (Haswell)
16
x86   Icelake-Client  Intel Core Processor (Icelake)
17
x86   Icelake-Server  Intel Xeon Processor (Icelake)
18
x86   IvyBridge-IBRS  Intel Xeon E3-12xx v2 (Ivy Bridge, IBRS)
19
x86        IvyBridge  Intel Xeon E3-12xx v2 (Ivy Bridge)
20
x86     Nehalem-IBRS  Intel Core i7 9xx (Nehalem Core i7, IBRS update)
21
x86          Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)
22
x86       Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)
23
x86       Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)
24
x86       Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)
25
x86       Opteron_G4  AMD Opteron 62xx class CPU
26
x86       Opteron_G5  AMD Opteron 63xx class CPU
27
x86           Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)
28
x86 SandyBridge-IBRS  Intel Xeon E312xx (Sandy Bridge, IBRS update)
29
x86      SandyBridge  Intel Xeon E312xx (Sandy Bridge)
30
x86 Skylake-Client-IBRS  Intel Core Processor (Skylake, IBRS)
31
x86   Skylake-Client  Intel Core Processor (Skylake)
32
x86 Skylake-Server-IBRS  Intel Xeon Processor (Skylake, IBRS)
33
x86   Skylake-Server  Intel Xeon Processor (Skylake)
34
x86    Westmere-IBRS  Westmere E56xx/L56xx/X56xx (IBRS update)
35
x86         Westmere  Westmere E56xx/L56xx/X56xx (Nehalem-C)
36
x86           athlon  QEMU Virtual CPU version 2.5+
37
x86         core2duo  Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz
38
x86          coreduo  Genuine Intel(R) CPU           T2600  @ 2.16GHz
39
x86            kvm32  Common 32-bit KVM processor
40
x86            kvm64  Common KVM processor
41
x86             n270  Intel(R) Atom(TM) CPU N270   @ 1.60GHz
42
x86          pentium
43
x86         pentium2
44
x86         pentium3
45
x86           phenom  AMD Phenom(tm) 9550 Quad-Core Processor
46
x86           qemu32  QEMU Virtual CPU version 2.5+
47
x86           qemu64  QEMU Virtual CPU version 2.5+
48
x86             base  base CPU model type with no features enabled
49
x86             host  KVM processor with all supported host features (only available in KVM mode)
50
x86              max  Enables all features supported by the accelerator in the current host
51

52
Recognized CPUID flags:
53
  fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 pn clflush ds acpi mmx fxsr sse sse2 ss ht tm ia64 pbe
54
  pni pclmulqdq dtes64 monitor ds-cpl vmx smx est tm2 ssse3 cid fma cx16 xtpr pdcm pcid dca sse4.1 sse4.2 x2apic movbe popcnt tsc-deadline aes xsave osxsave avx f16c rdrand hypervisor
55
  fsgsbase tsc-adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512dq avx512f mpx rdseed adx smap avx512ifma pcommit clflushopt clwb avx512pf avx512er avx512cd sha-ni avx512bw avx512vl
56
  avx512vbmi umip pku ospke avx512vbmi2 gfni vaes vpclmulqdq avx512vnni avx512bitalg avx512-vpopcntdq la57 rdpid
57
  avx512-4vnniw avx512-4fmaps md-clear spec-ctrl arch-capabilities ssbd
58
  syscall nx mmxext fxsr-opt pdpe1gb rdtscp lm 3dnowext 3dnow
59
  lahf-lm cmp-legacy svm extapic cr8legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid-msr tbm topoext perfctr-core perfctr-nb
60
  invtsc
61
  wbnoinvd ibpb amd-ssbd virt-ssbd amd-no-ssb
62
  xstore xstore-en xcrypt xcrypt-en ace2 ace2-en phe phe-en pmm pmm-en
63
  kvmclock kvm-nopiodelay kvm-mmu kvmclock kvm-asyncpf kvm-steal-time kvm-pv-eoi kvm-pv-unhalt kvm-pv-tlb-flush kvmclock-stable-bit
64

65

66

67
  npt lbrv svm-lock nrip-save tsc-scale vmcb-clean flushbyasid decodeassists pause-filter pfthreshold
68
  xsaveopt xsavec xgetbv1 xsaves
69
  arat
70

71

72
  rdctl-no ibrs-all rsba skip-l1dfl-vmentry ssb-no mds-no pschange-mc-no taa-no

新computeノードでQEMUのバージョンを「2.11.1」にアップグレードするには、パッケージの依存関係からceph-commonのバージョンを「10.2.11」から「12.2.0」に引き上げる必要がありました。ただし、この処理には一つ懸念がありました。それは、blockノードが管理するCeph^※3のバージョン「10.2.11」との互換性です。computeノードのceph-commonはblockノードのCephとの通信を担います。したがって、双方のバージョンが異なる場合、通信のインターフェース部分で互換性問題が発生する可能性がありました。しかし、今回のバージョン引き上げは2バージョンの差に過ぎないため、インターフェースに大きな変更が加わっている可能性は低いと判断しました。この仮説に基づき、試験的にceph-commonを「12.2.0」にアップグレードする対応を実施しました。その結果、インスタンスは正常に作成できました。また、インスタンスに対してボリュームをアタッチして読み書きできることを確認しました。

※3：OSSの分散ストレージソフトウェアです。OpenStackのCinderと連携して高可用性、冗長性、スケーラビリティーを提供します。詳細についてはOpenStack環境でBlockストレージを増設する - 基礎知識編を参照してください。

インスタンスがopenstackコマンドで移行できない

今回の移行は、インスタンスが停止状態で進めることを想定し、openstack server migrateコマンドを使用して移行を試みました。しかし、以下のエラーが発生しました。

1
# openstack server migrate --live compute1 e395f33f-7bed-44e8-bc45-01081d635aa2
2
Cannot 'os-migrateLive' instance e395f33f-7bed-44e8-bc45-01081d635aa2 while it is in vm_state stopped (HTTP 409) (Request-ID: req-27788ce6-69c4-4954-884d-3425d34cd2eb)

停止状態では移行できない可能性があるため、休止状態や起動状態に変更して移行を試みましたが、いずれも成功しませんでした。

休止状態の場合

1
# openstack server migrate --live compute1 707bbb1f-75e3-4285-b718-3ad7ad956da5
2
Cannot 'os-migrateLive' instance 707bbb1f-75e3-4285-b718-3ad7ad956da5 while it is in vm_state suspended (HTTP 409) (Request-ID: req-b0ddde85-dd7c-4896-97d2-f6c8ca334598)

起動状態の場合

1
# openstack server migrate --live compute1 707bbb1f-75e3-4285-b718-3ad7ad956da5
2
compute3 は共有ストレージ上にありません: Shared storage live-migration requires either shared storage or boot-from-volume with no local disks. (HTTP 400) (Request-ID: req-954b3aef-e1f2-4de0-80d2-5f7a426d256a)

エラー内容から推測すると、openstack server migrateコマンドはインスタンスの移行には対応していない可能性があります。この問題を解決するため、別の方法を検討する必要がありました。OpenStackでは、統一されたコマンドラインクライアントであるopenstackコマンドが提供されています。通常、多くの操作がこのコマンドで実行可能ですが、すべての機能がカバーされているわけではありません。OpenStackの各コンポーネントには、それぞれ専用のコマンドラインクライアントが用意されている場合があり、特定の操作にはこれらを利用する必要があります。例えば、computeサービスであるNovaコンポーネントではnovaコマンドが提供されています。そこで、問題解決のためにnovaコマンドを調査しました。nova helpコマンドを実行してコマンド一覧を確認した結果、インスタンス移行に関連するnova migrateコマンドが見つかりました。このコマンドを用いることで、指定したcomputeノードにインスタンスを正常に移行できる可能性が高いと考えました。

手順は以下のとおりです。

nova migrateコマンドを実行します。

1
# nova migrate --host compute5 --poll e395f33f-7bed-44e8-bc45-01081d635aa2
2
Server migrating... 100% complete
3
Finished

インスタンスの状態を確認します。

1
# openstack server show e395f33f-7bed-44e8-bc45-01081d635aa2

インスタンスの状態がVERIFY_RESIZE(移行成功)であることを確認し、nova resize-confirmコマンド(移行の確定)を実行します。

1
# nova resize-confirm e395f33f-7bed-44e8-bc45-01081d635aa2

上記の手順を行うことで、問題なくインスタンスを移行することができました。

ただし、インスタンスを移行する際には、ホストアグリゲートの設定に注意が必要です。ホストアグリゲートが設定されているインスタンスをnova migrateコマンドで移行する場合、移行先のcomputeノードがホストアグリゲートの設定に含まれている必要があります。ホストアグリゲートとは、OpenStackの機能の一つで、特定の特性を持つcomputeノードをグループ化する仕組みです。私たちのOpenStack環境では、この機能を活用して、Linux系OSを起動するcomputeノードとWindows OSを起動するcomputeノードをホストアグリゲートで分類しています。例えば、Linux系OSを起動するcomputeノードをホストアグリゲートとして定義し、その設定を持つフレーバーを使用してインスタンスを作成すると、そのインスタンスはLinux系OSを起動するcomputeノード上に作成されます。

旧computeノードのサービスがリサイズ途中の情報が残っていて削除できない

インスタンスの移行が完了した旧computeノード(ノード名：compute4)のnova-computeサービス(サービスID：27)を削除するためopenstack compute service deleteコマンドを実行したところ、以下のメッセージが表示され、サービスの削除が失敗しました。

1
# openstack compute service delete 27
2
Failed to delete compute service with ID '27': Unable to delete compute service that has in-progress migrations. Complete the migrations or delete the instances first. (HTTP 409) (Request-ID: req-7752c29a-4e8d-4046-83d3-ff19eada8cd8)
3
1 of 1 compute services failed to delete.

また、/var/log/nova/nova-api.logを確認すると、以下のエラーメッセージが出力されていました。

1
There are 1 in-progress migrations involving the host. Migrations (uuid:status): 24fa8417-d350-4278-a802-07a5d78811b0:pre-migrating

移行の状態を詳しく確認するためにnova migration-listコマンドを実行したところ、該当インスタンスの状態がpre-migratingと表示されました。これは、数年前に開始されたインスタンスのcompute2からcompute4への移行処理が、現在も「処理中」の状態であり、移行が完了していないことを示しています。これが原因でnova-computeサービスの削除に失敗しています。

1
# nova migration-list
2
+------+--------------------------------------+-------------+------------+----------------+--------------+--------------+---------------+--------------------------------------+------------+------------+----------------------------+----------------------------+-----------+
3
| Id   | UUID                                 | Source Node | Dest Node  | Source Compute | Dest Compute | Dest Host    | Status        | Instance UUID                        | Old Flavor | New Flavor | Created At                 | Updated At                 | Type      |
4
+------+--------------------------------------+-------------+------------+----------------+--------------+--------------+---------------+--------------------------------------+------------+------------+----------------------------+----------------------------+-----------+
5
| 331  | 82645d5b-7692-43c5-b920-d165472c0ba8 | compute2    | compute4   | compute2       | compute4     | 192.168.1.38 | pre-migrating | 24fa8417-d350-4278-a802-07a5d78811b0 | 185        | 191        | 2018-11-02T07:59:11.000000 | 2019-09-28T01:59:21.000000 | resize    |
6
+------+--------------------------------------+-------------+------------+----------------+--------------+--------------+---------------+--------------------------------------+------------+------------+----------------------------+----------------------------+-----------+

この状態になっている原因は、インスタンスの作成者がOpenStack Dashboardを使用してリサイズ操作を実行した後、リサイズを確定しないままインスタンスを削除したことで、移行処理が途中の状態(pre-migrating)のまま維持され、正常な移行が行えなくなった可能性が高いと考えられます。状態をpre-migrating以外にすればこの問題は解消すると考えられますが、インスタンスがすでに削除されているため、OpenStack Dashboardやコマンドラインクライアントから状態を更新することはできません。そのため、データベースを直接確認し、状態のカラムをfailedに更新しました。

インスタンスの状態を確認します。

1
> select * from migrations where instance_uuid = '24fa8417-d350-4278-a802-07a5d78811b0'\G
2
*************************** 1. row ***************************
3
          created_at: 2018-11-02 07:59:11
4
          updated_at: 2019-09-28 01:59:21
5
          deleted_at: NULL
6
                  id: 331
7
      source_compute: compute2
8
        dest_compute: compute4
9
           dest_host: 192.168.1.38
10
              status: pre-migrating
11
       instance_uuid: 24fa8417-d350-4278-a802-07a5d78811b0
12
old_instance_type_id: 185
13
new_instance_type_id: 191
14
         source_node: compute2
15
           dest_node: compute4
16
             deleted: 0
17
      migration_type: resize
18
              hidden: 0
19
        memory_total: NULL
20
    memory_processed: NULL
21
    memory_remaining: NULL
22
          disk_total: NULL
23
      disk_processed: NULL
24
      disk_remaining: NULL
25
                uuid: 82645d5b-7692-43c5-b920-d165472c0ba8

インスタンスの状態をfailedに更新します。

1
> update migrations set status='failed' where instance_uuid='24fa8417-d350-4278-a802-07a5d78811b0';
2
Query OK, 0 rows affected (0.00 sec)
3
Rows matched: 1  Changed: 0  Warnings: 0

この更新により、旧computeノードのnova-computeサービスを削除することができました。

おわりに

本記事では、OpenStackのcomputeノードを更改した際に発生したトラブルへの対応内容を紹介しました。本記事が、OpenStackを運用されている方や、これから導入やサーバ更改を検討される方々のお役に立てば幸いです。今後、blockノードやcontrollerノードなど、他のノードの移行に関するノウハウについても順次紹介していく予定です。

記事をシェアする