CODT2021_エンタープライズ向けクラウドサービスにおける大規模・商用環境でのホストOSバージョンアップ / CODT2021_Host OS version upgrades for enterprise cloud services in large-scale, commercial environments

© NTT Communications Corporation All Rights Reserved.
エンタープライズ向け 
クラウドサービスにおける 
大規模・商用環境での 
ホストOSバージョンアップ 
 
PS本部 DPS部クラウドプラットフォーム部門 
ソフトウェアアーキテクト 
佐野　成(@say3no) 
2021/07 CODT2021 
NTTコミュニケーションズ株式会社 
中級者向け 

View Slide

© NTT Communications Corporation All Rights Reserved. 2
自己紹介 
ソフトウェアアーキテクト  
佐野　成(@say3no) 

View Slide

オープニングトーク;このセッションで話すこと 
ホストOSバージョンアップで感じた辛さ、学びなどについて、実例を踏まえてお話します  
● エンタープライズ向けクラウドサービスの辛さとはなにか  
○ 責務の重さ;互換性の担保をしないと行けない 
○ 仮想サーバーをほとんどコントロールできない  
■ 「どういうホストで動いているか」だけ  
■ 開発/検証速度を上げること;「どこで動いているか」の管理/変更容易性を上げること  
● IaC, autoconverge, post-copy  
 
● VMって難しい 
○ 可搬性/冪等性の低い使われ方をされている事が多い  
■ SLA 
○ 変数が多い 
■ 様々なゲストOS、様々なディストリビューション  
■ nova/qemu,libvirt 
■ 物理HVのマイクロアーキテクチャ(拡張ISA)  

View Slide

方針 
計画 
ホストOS 
背景 
概要編 
特定条件でLM失敗 
Rx,Tx Swap 
ブートしないゲスト 
問題編 
目次 

View Slide

背景 
● 2016年より仮想サーバーを提供  
○ 当初ECL2.0というサービス群の中の　1つ
として提供された 
○ 現在はSmart Data Platform(SDPF) 　とい
うクラウドサービス群の1つ  
 
● OpenStack Nova, Cinder, Glance, Masakari を活
用 
 
● 世界13拠点に展開 
○ HV総数約 3,500 台 
○ VM総数約 35,000 台  
○ 最大拠点で 660 台のHV  
  https://ecl.ntt.com/en/service-status/
方針 
計画 
ホストOS 
背景 
概要編 

View Slide

Compute node について 
● 現在3機種(3世代)のHVからなっている  
○ Haswell 
○ Broadwell 
○ Skylake 
 
● 各世代の中の40台で1クラスタ  
○ 36台 Active 
○ 4台 Hot Standby 
 
● ホストOSは Ubuntu/RHEL  
○ クラスタ毎に異なる 
 
● ホストが落ちるとmasakariがVMHAを発動  
 
 
方針 
計画 
ホストOS 
背景 
概要編 
<ホスト落ちたらVMをevacuateして
HAを担保するワン
…
…
…
…
…

View Slide

ホストOSについて 
● 今回対象となるホストOSの構成をバンドルし、世代として扱う  
○ Compute node version 1, 2 なので、 CPv1, CPv2 と呼称する 
方針 
計画 
ホストOS 
背景 
概要編 
CPv1 CPv2 備考
OS Ubuntu14.04/RHEL7.4 Ubuntu16.04/RHEL7.6
OpenStack Mitaka Mitaka ● 変更なし
docker N/A 19.03
● 各プロセスをコンテナで提供
● 非カーネルレイヤのアジリティ上昇
● 上記に伴うアーキテクチャの変更
libvirt にゃんぱすなのんほげぴよほげぴよ
● Ubuntu16 stable は 1.3.1
● CPv2 では stable を採用せずメジャーバージョンアップ
● 対応可能な OpenStack バージョンはより広くなるが …
qemu にゃんぱすなのんほげぴよほげぴよ ● バージョンアップ

View Slide

Spiral Update Plan 
OpenStack と Compute node OS を交互にアップデートする計画  
 
● Controller node 等は Ubuntu を利用  
● Compute node には Ubuntu と RHEL を利用  
● ディストリビューションから長期サポートが提供されるものを選ぶ  
○ アップデートの必要回数は少なくなるように  
 
OpenStack Juno Mitaka Queens Ussuri
OS Controller etc. 14.04 16.04 18.04 20.04
Compute(Ubuntu) 14.04 14.04 16.04 18.04
Compute(RHEL) 7.1 7.4 7.6 8.2
方針 
計画 
ホストOS 
背景 
概要編 

View Slide

CP Rolling Update 
● Live-migration(LM) を使ってCPv1の空きホストを用意する
○ 宛先は CPv1,CPv2 どちらでもよい
○ NoisyなVMがいる場合などは時間がかかることもある
■ もし autoconverge や post-copy が使えれば、よりスムーズに LMすることができる(かも
● Ansibleをキックして、OSインストールからアプリの設定までノンストップで実現
○ およそ 30分で完了 
CPv1
VM
CPv1
VM
VM
①LM to CPv1 
CPv1
VM
CPv2
VM
②VerUP to CPv2 
CPv1
VM
CPv2
VM
VM VM
③LM to CPv2 
方針 
計画 
ホストOS 
背景 
概要編 
CPv2
v2 v2
v1
v1
v1
v1

View Slide

方針 
計画 
ホストOS 
背景 
概要編 
Rolling Update 下ホストレイヤでのVM状態遷移 
「互換性がある」と言うために
● 性能検証
● 非機能検証
● 機能検証
● etc…
LMを含んだ状態遷移考慮
● libvirt メジャーバージョンを跨ぐ
環境間での互換性検証
VM Spawn
LM
LM
LM
CPv1 CPv2
ホストレイヤでのVM状態遷移  
VM Spawn

View Slide

CPv2単体でも検証範囲広すぎ問題 
(VM) x (OpenStack/Qemu State) x (物理HV)
● VM = ゲストOSの数
○ ゲストOSおよそ 90 枚
○ 全網羅は無理でも　　　　　　　　各ディス
トリビューションくらいは
● OpenStack/Qemu State
○ nova states は右記の通り
○ ホストを必ず跨ぐタスクは特に厄介
■ Resize
■ LM
● 物理HV
○ Haswell
○ Broadwell
○ Skylake https://docs.openstack.org/nova/latest/reference/vm-states.html 
novaのvm states  
方針 
計画 
ホストOS 
背景 
概要編 

View Slide

検証方針; CPv2 と LM を分離して考える 
方針 
計画 
ホストOS 
背景 
概要編 
LM
CPv2
CPv2 単体検証
● 部分問題として分離
● Skylake → Haswell, Broadwell の順
○ Skylake はCPv1が乗らない運用
LM検証
● qemu, libvirtともに大きくバージョンアップし
たため念入りに
● 同世代CPでのLMは検証するものの、最低限
の実施
VM Spawn VM Spawn
LM
LM
LM
CPv1 CPv2
VM Spawn

View Slide

検証方針; CPv2 とLMを分離して考える 
方針 
計画 
ホストOS 
背景 
概要編 
VM Spawn
LM
LM
LM
CPv1 CPv2
VM Spawn
CPv1 CPv2 LM
Haswell ✓ 要検証要検証
Broadwell ✓ 要検証要検証
Skylake N/A 要検証 N/A
● この考え方は完全ではないだろうし、おそらく漏れもあろう  
 
● しかし Rolling Update を成功させるために95%くらいのカバレッジはあるのではないか  
○ なにをもって95%だというのか、その審美眼は我々にあるのか  
 
● ともあれ、下の表を全て検証済み( ✓)とすれば良いだろう  

View Slide

方針 
計画 
ホストOS 
背景 
概要編 
Rx,Tx Swap 
問題編 
目次 

View Slide

今回お話する３つの辛いお話 
Rx,Tx Swap 
問題編 
ブートしないゲスト  Rx, Tx Swap  特定条件でLM失敗 

View Slide

Ⓒ NTT Communications Corporation All Rights Reserved.
17
Rx,Tx Swap 
問題編 

View Slide

Broadwell, Skylakeで特定のゲストOSがブートしない 
● 原因は命令セット; SMAP にゲストOSが対応していないため  
○ SMAP: Supervisor mode access prevention  
■ ユーザ空間をカーネルから保護するための機能の1つ  
 
● x86は新世代に移行すると命令セットが追加されることもあり、　　　　　　　　　　　　　　　ゲストOSの対応状
況によってはブートしないこともある  
○ libvirtd のデフォルトでは、ゲストのCPUはホストのCPUを模倣するため  
 
● ここで解せないのは SMAP が実は Broadwell で追加された拡張だったということ 
Rx,Tx Swap 
問題編 
CPv1 CPv2 LM
Haswell ✓ ✓ 要検証
Broadwell ✓ 失敗要検証
Skylake N/A 失敗 N/A

View Slide

Broadwell, Skylakeで特定のゲストOSがブートしない 
● 原因は命令セット; SMAP にゲストOSが対応していないため  
○ SMAP: Supervisor mode access prevention  
■ ユーザ空間をカーネルから保護するための機能の1つ  
 
● x86は新世代に移行すると命令セットが追加されることもあり、　　　　　　　　　　　　　　　ゲストOSの対応状
況によってはブートしないこともある  
○ libvirtd のデフォルトでは、ゲストのCPUはホストのCPUを模倣するため  
 
● ここで解せないのは SMAP が実は Broadwell で追加された拡張だったということ 
Rx,Tx Swap 
問題編 
CPv1 CPv2 LM
Broadwell ✓(なんで？）失敗要検証

SMAPの有無で 
成否が決まるなら、  
CPv1 on Broadwell も失敗した
はずでは？ 

View Slide

CPv1 on Broadwellで成功、原因は古い libvirt ゆえに 
● CPv1 での libvirtd が絶妙に古いため SMAP をサポートしておらず、すり抜けていた  
○ つまり、我々の Broadwell 基盤はSMAPを提供していなかった  
 
● リリース頻度が早いと知見がたまる頻度も高いはず…  
○ HVの機種変更/libvirtdのバージョンアップを行ってきた知見が欲しい  
■ We are hiring 
CPv1 CPv2 LM
Rx,Tx Swap 
問題編 

View Slide

Skylake での対応; ゲストOSをアップデート 
Rx,Tx Swap 
問題編 
● レガシー故に動かないゲストOSがあるなら、ゲストOS側で対応すべき  
○ 対応していない/出来ないゲストOSは、提供しない  
○ 基盤としてはCPUの新機能は可能な限り提供したい  
 
 
● CPv2検証において、Skylake は互換性を検証しなくてよい(CPv1がない)  
○ なんて楽なんだ… 
 
User OS(Host)
OS(Guest)
SMAP対応版
Kernel
Skaylake
物理
CPv1 CPv2 LM
Skylake N/A ✓ N/A

View Slide

Broadwell での対応; ホストOSをnosmapでブート 
Rx,Tx Swap 
問題編 
● レガシー故に動かないゲストOSがあるなら、ゲストOS側で対応すべき  
○ 対応していない/出来ないゲストOSは、提供しない  
○ 基盤としてはCPUの新機能は可能な限り提供したい  
 
● ただしすでにCPv1で提供している Broadwell については、　　　　　　　　互換性の観点
から、引き続きSMAPを提供しない  
○ ホストのkernelをブートする際に nosmap を有効にすると、 CPUFlagsから
smap が見えなくなる(無効にできる)  
 
User OS(Host)
OS(Guest) Kernel(nosmap)
Broadwell
物理
CPv1 CPv2 LM
Broadwell ✓ ✓ 要検証
Skylake N/A ✓ N/A

View Slide

Rx,Tx Swap 
問題編 

View Slide

VM の network metric が逆転する 
● VM の network metric のRx,Tx が　　　　Swapしてい
るように見えるとの申告  
○ Monitoring チームより  
○ データを送信すると受信量が増え、　データ
を受信すると送信量が増える  
 
● virsh 経由で取得した Rx, Tx をETLするだけ  
○ デグレやバグが混入する要素はない  
○ それだけに CPv2 でも送受信が　　　　　出来た
時点で試験をパスしている  
 
CPv1 CPv2 LM
Haswell ✓ ✓ 検証中
Broadwell ✓ ✓ 検証中
Skylake N/A ✓ N/A
User
nova-comptue
OS (Host)
物理
qemu
OS (Guest)
User
libvirtd
kernel
kvm
virsh
Rx,Tx Swap 
問題編 

View Slide

VM の network metric が逆転する 
● VM の network metric のRx,Tx が　　　　Swapしてい
るように見えるとの申告  
○ Monitoring チームより  
○ データを送信すると受信量が増え、　データ
を受信すると送信量が増える  
 
● virsh 経由で取得した Rx, Tx をETLするだけ  
○ デグレやバグが混入する要素はない  
○ それだけに CPv2 でも送受信が　　　　　出来た
時点で試験をパスしている  
 
CPv1 CPv2 LM
Haswell ✓ ✓ 検証中
Broadwell ✓ ✓ 検証中
Skylake N/A ✓ N/A
User
nova-comptue
OS (Host)
物理
qemu
OS (Guest)
User
libvirtd
kernel
kvm
virsh

virsh が見ている値が Swap
するなんて仕様変更あるわ
けないしな... 
Rx,Tx Swap 
問題編 

View Slide

VMトラヒック、内から見るか？外から見るか？ 

むしろ今までが非直感的!
Swap するバグ修正はある 
NIC
User OS(Host)
TAP
むしろ今までがバグっていた
● libvirt v3.9.0 (2017-11-02) Bugfixes(https://libvirt.org/news.html)
○ Fix swapped interface statistics and QoS
■ Due to internal implementation, reported statistics for some types of interfaces were swapped　　　 (RX
appeared in TX and vice versa). 　　　　　　　　　　　　　　　　　　　　　　　　　　Similarly, QoS was set in
reversed way.
● 主体がゲストOS の NIC からホスト OS の TAP へ変更  
○ たしかに非直感的ではあったし、むしろなぜ我々は最初からホスト側を見なかったのか  
OS(Guest) Kernel
送信したぞ受信したぞ
Rx,Tx Swap 
問題編 

View Slide

検証を終えて;バージョンアップの適切な「歩幅」とは 
● 仮想マシン; ハード寄りなソフトウェア  
○ ソフトウェアとは抽象的で柔軟であること  
○ 「コンピュータ科学の歴史とは、複雑さを隠して、より洗練されたアプリケーションを作るための抽象
化の歴史です。」(『入門Kubernetes』より)  
● 「次いつになるかわからないからなるべく新しいやつ載せようぜ」vs 「怖いから無理せず少しずつバージョ
ンアップしていこうよ」  
○ ﾌｧｲｯ 
○ 理想は更新周期をはやめることなのは分かっているが…  
● libvirt の例などは我々がコントリビュータになる、くらいの姿勢でrelease note をきちんとなめる位のことを
習慣にすべきなのかもしれない  
CPv1 CPv2 LM
Haswell ✓ ✓ ✓
Broadwell ✓ ✓ ✓
Skylake N/A ✓ N/A
Rx,Tx Swap 
問題編 

View Slide

○ ﾌｧｲｯ 

CPv2, LM 検証でいろいろあっ
たけど、無事リリースできるこ
とになりました 
CPv1 CPv2 LM
Haswell ✓ ✓ ✓
Skylake N/A ✓ N/A
Rx,Tx Swap 
問題編 

View Slide

○ ﾌｧｲｯ 

運用さん、 
ローリングアップデート 
お願いします ^^ 
CPv1 CPv2 LM
Haswell ✓ ✓ ✓
Skylake N/A ✓ N/A
Rx,Tx Swap 
問題編 

View Slide

Rx,Tx Swap 
問題編 

View Slide

2020年某日 Rolling Update(Production) 初週 

View Slide

CPv2
CPv2
CPv2
2020年某日 Rolling Update 初週 
CPv2
CPv2
v2 v2 v2 v2
v2 v1 v1 v1
v1 v1
順調に作業が進んでいるね 
Rx,Tx Swap 
問題編 

View Slide

CPv2
CPv2
CPv2
CPv2
CPv2
v2 v2 v2 v2
v2 v1 v1 v1
v1 v1
次は CPv1 を CPv2 に 
LMして……っと 
Rx,Tx Swap 
問題編 

View Slide

CPv2
CPv2
CPv2
CPv2
CPv2
v2 v2 v2 v2
v2 v1 v1 v1
v1 v1
ん...? 
Rx,Tx Swap 
問題編 

View Slide

v1 v2
このVM、 
LMがうまく 
いっていないような…？ 
Rx,Tx Swap 
問題編 

View Slide

特定の条件でLMを行うと失敗する 
v2 v2 v2 v2
v2 v1 v1 v1
v1 v1
成功例
失敗例
● 商用でローリングアップデート中、CPv1 → CPv2 LM 失敗  
○ 対象は公式ゲストOSを使った windows VM  
○ しかし、CPv1 → CPv2 LM が成功した windows VM もあるのが解せない  
■ 検証でも成功している  
 
 
 
 
 
 
● 幸いにも対象のVMは社内ユーザの試用テナント  
Rx,Tx Swap 
問題編 

View Slide

● 商用でローリングアップデート中、CPv1 → CPv2 LM で LM 失敗  
○ 対象は公式ゲストOSを使った windows VM  
○ しかし、CPv1 → CPv2 LM が成功した windows VM もあるのが解せない  
■ 検証でも成功している  
 
 
 
 
 
 
● 幸いにも対象のVMは社内ユーザの試用テナント  
特定の条件でLMを行うと失敗する 
v2 v2 v2 v2
v2 v1 v1 v1
v1 v1
成功例
失敗例
Rx,Tx Swap 
問題編 

View Slide

● 原因 
○ Balloon device の扱いに関するqemuのバ
グ 
● 事象 
○ CPv1 → CPv2 へLMする時、　　　　以下
の全ての条件を満たす場合は　　失敗す
る 
● 条件 
○ Windows VM 
○ かつてLMを実施されているVM 
○ LM後、一度も電源OFF/ONや、VM内
RebootがされていないVM 
 
調査をすすめて分かったこと;  
[After live migration a windows instance, two qemu processes are writing to
same volume caused corruption - Red Hat Customer Portal]
(https://access.redhat.com/solutions/2832101)
「✓ SOLUTION 解決済」であることに胸をなでおろす
Rx,Tx Swap 
問題編 

View Slide

● 原因 
グ 
● 事象 
る 
● 条件 
○ Windows VM 
Rx,Tx Swap 
問題編 

View Slide

す
る　
開
発
の

View Slide

● 条件 
○ Windows VM 
 
● Windows VMでの状態遷移は右の通り  
 
● CPv1(LMed)はQEMUの内部変数を保持すること
によって生じており、事前の検知は困難  
バグ起因でLMを契機に新しい状態が出来ていた 
Rx,Tx Swap 
問題編 
VM Spawn
LM
LM
LM
CPv1 CPv2
VM Spawn
CPv1
(LMed)
OFF → ON,
Reboot in VM
LM(Fail)
ホストレイヤでの WindowsVM状態遷移 

View Slide

４つの解法 
1. お客様にVMの停止/起動あるいはRebootをしてもらう  
• 条件に合致するVMの特定はホスト側から可能  
 
2. Bugfix 版パッチをベンダに作成して頂いて対応する  
• 王道、ただし商用リリースまでどのくらいかかるか分からない  
• 結局停止起動 or Reboot が必要になる可能性もある  
 
3. お客様にゲストOSの中からBalloon device を無効化してもらう  
• 条件に合致するVMの特定はホスト側から可能  
• 諸悪の根源をVM内から無効化すれば事象は発生しない  
 
4. LM前にホストOS側からBalloon Device を抜去してしまう  
Rx,Tx Swap 
問題編 

View Slide

● ユーザ影響
○ Guest内のballoon driverが停止、それに伴うイベントログに
Information レベルでログが出力
■ それ以外の影響は無し
● 基盤側
○ SDPFの収容計画ではメモリ枯渇の問題が特別に懸念されていないため、　　　　　　　　　　　短期的に抜去し
たとして問題ない
■ 期間について;LM後ゲストで停止起動すると ballon device はまた生えてくる
● コマンド 
○ virsh qemu-monitor-command --hmp $ID device_del balloon0
■ ゲストOSからはballon device が抜去されたように見える
LM前にホストOS側からMemory Balloon Device を抜去 
Rx,Tx Swap 
問題編 

View Slide

有限リソースの中で我々はどうするべきだったか 
Release notes や CHANGELOG だけではリーチ出来ない
既知の問題に、どうすれ辿りつけるか  
 
Hostと異なるGuest OSの組み合わせを重点的に検証す
べきだった 
● 異なる組み合わせにおいて問題が起きやすい  
● Windows on Linux 
● FreeBSD on Linux 
● etc 
 
ナレッジ共有サイトを全部読めば分かる！  
● 無理 
○ RedHatだけで8000件(qemuで検索)  
○ 対象バージョンなどを絞る等でもリーチできな
い問題もある  [After live migration a windows instance, two qemu processes are writing to
どうすれば事前検証の段階でこの記事にたどり着けただろうか？
Rx,Tx Swap 
問題編 

View Slide

コストをかければ事前に全て炙り出せるという幻想 
Rx,Tx Swap 
問題編 
● どれだけ組み合わせ枝刈りの剪定が発達しても、全能でない限り肝心な枝を落とすこともある
○ そして我々は全能でないし組み合わせ爆発は今後も大きくなっていく
○ 今回のように全体計画をNヶ月遅らせる結末になることも
…
● つまり、事前検証で網羅しきれないケースは必ず存在する
○ lab やstagingで、 production のナマのVMを模倣するのは限界がある
● カナリアリリースが出来るような
Deploy Strategyの策定
○ 今回は結果として意図せずカナリアリリースをしていたと言えなくもない
○ staging or production ではなく、商用にカナリアリリースできる群を選定
■ 今回のような商用の社内アカウントなど
■ カナリア群にはホストとゲストが異種であるケースも含ませる

View Slide

今回お話した３つの辛いお話 
Rx,Tx Swap 
問題編 

View Slide

まとめ 
仮想マシンなにもわからない  
 
 

View Slide

まとめ 
仮想マシンなにもわからない  
だが、共に生きることはできる  
 

View Slide

まとめ 
様々な問題を踏みぬいてナレッジを貯めながら、  
SDPF仮想サーバー基盤はホストOSバージョンアップを成し遂げました  
● 物理と仮想の境界をつなぐもの; libvirt,kvm,qemu はもちろん、低レイヤの
知見を深めることにより、検証において、適切な枝刈りの審美眼を磨く事ができる  
● ゲストOSとホストOSの種別が異なる組み合わせには重点的な検証を行うべきである  
● 検証しても問題は起きることを受け入れた Deploy Strategy の整備(カナリアリリース等)  
 
こうした経験を踏まえ、枝刈りしてなお重い組み合わせ爆発に対しては、以下を取り組んでいます  
① 計算機で立ち向かう; マシンパワーで殴れる領域を増やす  
● IaC 領域の拡張と UT, FT 等各種 Test の Iikanji 結合  
● 以上を元にした全体のCI/CD強化  
②唯一のコントロール≒ LM によるホスト変更のアジリティの強化で検証時間の短縮  
● IaC 領域の拡張とLM前後で互換検証の自動化  
● autoconverge, post-copy など新しいLM機能やqemu live update  
 

View Slide

CODT2021_エンタープライズ向けクラウドサービスにおける大規模・商用環境でのホストOSバージョンアップ / CODT2021_Host OS version upgrades for enterprise cloud services in large-scale, commercial environments

CODT2021_エンタープライズ向けクラウドサービスにおける大規模・商用環境でのホストOSバージョンアップ / CODT2021_Host OS version upgrades for enterprise cloud services in large-scale, commercial environments

NTT Communications

More Decks by NTT Communications

Other Decks in Technology

Featured

Transcript

CODT2021_エンタープライズ向け クラウドサービスにおける 大規模・商用環境での ホストOSバージョンアップ / CODT2021_Host OS version upgrades for enterprise cloud services in large-scale, commercial environments

CODT2021_エンタープライズ向け クラウドサービスにおける 大規模・商用環境での ホストOSバージョンアップ / CODT2021_Host OS version upgrades for enterprise cloud services in large-scale, commercial environments

NTT Communications

More Decks by NTT Communications

Other Decks in Technology

Featured

Transcript

CODT2021_エンタープライズ向けクラウドサービスにおける大規模・商用環境でのホストOSバージョンアップ / CODT2021_Host OS version upgrades for enterprise cloud services in large-scale, commercial environments

CODT2021_エンタープライズ向けクラウドサービスにおける大規模・商用環境でのホストOSバージョンアップ / CODT2021_Host OS version upgrades for enterprise cloud services in large-scale, commercial environments