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コミュニケーションズ株式会社  中級者向け 

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

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

© NTT Communications Corporation All Rights Reserved. 4 方針  計画 
ホストOS  背景  概要編  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編  目次 

© NTT Communications Corporation All Rights Reserved. 5 背景  •
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  背景  概要編 

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

© NTT Communications Corporation All Rights Reserved. 7 ホスト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 にゃんぱすなのんほげぴよほげぴよ • バージョンアップ

© NTT Communications Corporation All Rights Reserved. 8 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  背景  概要編 

© NTT Communications Corporation All Rights Reserved. 9 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

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

© NTT Communications Corporation All Rights Reserved. 12 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  背景  概要編 

© NTT Communications Corporation All Rights Reserved. 13 検証方針; 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

© NTT Communications Corporation All Rights Reserved. 14 検証方針; 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%だというのか、その審美眼は我々にあるのか     • ともあれ、下の表を全て検証済み( ✓)とすれば良いだろう  

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

© NTT Communications Corporation All Rights Reserved. 16 今回お話する３つの辛いお話  特定条件でLM失敗 
Rx,Tx Swap  ブートしないゲスト  問題編  ブートしないゲスト  Rx, Tx Swap  特定条件でLM失敗 

Ⓒ NTT Communications Corporation All Rights Reserved. 17 特定条件でLM失敗  Rx,Tx
Swap  ブートしないゲスト  問題編 

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

© NTT Communications Corporation All Rights Reserved. 19 Broadwell, Skylakeで特定のゲストOSがブートしない 
• 原因は命令セット; SMAP にゲストOSが対応していないため   ◦ SMAP: Supervisor mode access prevention   ▪ ユーザ空間をカーネルから保護するための機能の1つ     • x86は新世代に移行すると命令セットが追加されることもあり、　　　　　　　　　　　　　　　ゲストOSの対応状況によってはブートしないこともある   ◦ libvirtd のデフォルトでは、ゲストのCPUはホストのCPUを模倣するため     • ここで解せないのは SMAP が実は Broadwell で追加された拡張だったということ  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編  CPv1 CPv2 LM Haswell ✓ ✓ 要検証 Broadwell ✓(なんで？）失敗要検証 Skylake N/A 失敗 N/A SMAPの有無で  成否が決まるなら、   CPv1 on Broadwell も失敗したはずでは？ 

© NTT Communications Corporation All Rights Reserved. 20 CPv1 on
Broadwellで成功、原因は古い libvirt ゆえに  • CPv1 での libvirtd が絶妙に古いため SMAP をサポートしておらず、すり抜けていた   ◦ つまり、我々の Broadwell 基盤はSMAPを提供していなかった     • リリース頻度が早いと知見がたまる頻度も高いはず…   ◦ HVの機種変更/libvirtdのバージョンアップを行ってきた知見が欲しい   ▪ We are hiring  CPv1 CPv2 LM Haswell ✓ ✓ 要検証 Broadwell ✓ 失敗要検証 Skylake N/A 失敗 N/A 特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

© NTT Communications Corporation All Rights Reserved. 21 Skylake での対応;
ゲストOSをアップデート  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編  • レガシー故に動かないゲストOSがあるなら、ゲストOS側で対応すべき   ◦ 対応していない/出来ないゲストOSは、提供しない   ◦ 基盤としてはCPUの新機能は可能な限り提供したい       • CPv2検証において、Skylake は互換性を検証しなくてよい(CPv1がない)   ◦ なんて楽なんだ…    User OS(Host) OS(Guest) SMAP対応版 Kernel Skaylake 物理 CPv1 CPv2 LM Haswell ✓ ✓ 要検証 Broadwell ✓ 失敗要検証 Skylake N/A ✓ N/A

© NTT Communications Corporation All Rights Reserved. 22 Broadwell での対応;
ホストOSをnosmapでブート  特定条件でLM失敗  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 Haswell ✓ ✓ 要検証 Broadwell ✓ ✓ 要検証 Skylake N/A ✓ N/A

© NTT Communications Corporation All Rights Reserved. 23 今回お話する３つの辛いお話  特定条件でLM失敗 
Rx,Tx Swap  ブートしないゲスト  問題編  ブートしないゲスト  Rx, Tx Swap  特定条件でLM失敗 

© NTT Communications Corporation All Rights Reserved. 25 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 特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

© NTT Communications Corporation All Rights Reserved. 26 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 するなんて仕様変更あるわけないしな...  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

© NTT Communications Corporation All Rights Reserved. 27 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 送信したぞ受信したぞ特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

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

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

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

© NTT Communications Corporation All Rights Reserved. 31 今回お話する３つの辛いお話  ブートしないゲスト 
Rx, Tx Swap  特定条件でLM失敗  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

© NTT Communications Corporation All Rights Reserved. 33 2020年某日 Rolling
Update(Production) 初週 

© NTT Communications Corporation All Rights Reserved. 34 CPv2 CPv2
CPv2 2020年某日 Rolling Update 初週  CPv2 CPv2 v2 v2 v2 v2 v2 v1 v1 v1 v1 v1 順調に作業が進んでいるね  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

CPv2 2020年某日 Rolling Update 初週  CPv2 CPv2 v2 v2 v2 v2 v2 v1 v1 v1 v1 v1 次は CPv1 を CPv2 に  LMして……っと  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

CPv2 2020年某日 Rolling Update 初週  CPv2 CPv2 v2 v2 v2 v2 v2 v1 v1 v1 v1 v1 ん...?  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

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

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

© NTT Communications Corporation All Rights Reserved. 40 • 原因 
◦ 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 解決済」であることに胸をなでおろす特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

◦ 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 解決済」であることに胸をなでおろす特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

© NTT Communications Corporation All Rights Reserved. 45 • 条件 
◦ Windows VM  ◦ かつてLMを実施されているVM  ◦ LM後、一度も電源OFF/ONや、VM内 RebootがされていないVM    • Windows VMでの状態遷移は右の通り     • CPv1(LMed)はQEMUの内部変数を保持することによって生じており、事前の検知は困難   バグ起因でLMを契機に新しい状態が出来ていた  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編  VM Spawn LM LM LM CPv1 CPv2 VM Spawn CPv1 (LMed) OFF → ON, Reboot in VM LM(Fail) ホストレイヤでの WindowsVM状態遷移 

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

© NTT Communications Corporation All Rights Reserved. 47 • ユーザ影響
◦ 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 を抜去  特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

© NTT Communications Corporation All Rights Reserved. 48 有限リソースの中で我々はどうするべきだったか  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 same volume caused corruption - Red Hat Customer Portal] (https://access.redhat.com/solutions/2832101) どうすれば事前検証の段階でこの記事にたどり着けただろうか？特定条件でLM失敗  Rx,Tx Swap  ブートしないゲスト  問題編 

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

© NTT Communications Corporation All Rights Reserved. 53 まとめ  様々な問題を踏みぬいてナレッジを貯めながら、
  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    

CODT2021_エンタープライズ向け クラウドサービスにおける 大規模・商用環境での ホスト...

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

More Decks by NTT Communications

Other Decks in Technology

Featured

Transcript

CODT2021_エンタープライズ向けクラウドサービスにおける大規模・商用環境でのホスト...

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