Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

2021年7月に Cloud Operator Days Tokyo 2021 で発表した「エンタープライズ向け クラウドサービスにおける 大規模・商用環境での ホストOSバージョンアップ」の講演資料です。

イベント:https://cloudopsdays.com/archive/2021/
YouTube:https://youtu.be/PZU-xKxxGmg

NTT Communications

March 17, 2023
Tweet

More Decks by NTT Communications

Other Decks in Technology

Transcript

  1. © NTT Communications Corporation All Rights Reserved. エンタープライズ向け
 クラウドサービスにおける
 大規模・商用環境での


    ホストOSバージョンアップ
 
 PS本部 DPS部 クラウドプラットフォーム部門
 ソフトウェアアーキテクト
 佐野 成(@say3no)
 2021/07 CODT2021
 NTTコミュニケーションズ株式会社
 中級者向け

  2. © NTT Communications Corporation All Rights Reserved. 3 オープニングトーク;このセッションで話すこと
 ホストOSバージョンアップで感じた辛さ、学びなどについて、実例を踏まえてお話します

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

  3. © NTT Communications Corporation All Rights Reserved. 4 方針
 計画


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

  4. © 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
 背景
 概要編

  5. © 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を担保するワン … … … … …
  6. © 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 にゃんぱすなのん ほげぴよほげぴよ • バージョンアップ
  7. © 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
 背景
 概要編

  8. © 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
  9. © NTT Communications Corporation All Rights Reserved. 10 方針
 計画


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


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

  12. © 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
  13. © 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%だというのか、その審美眼は我々にあるのか 
 
 • ともあれ、下の表を全て検証済み( ✓)とすれば良いだろう 

  14. © NTT Communications Corporation All Rights Reserved. 15 方針
 計画


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

  15. © NTT Communications Corporation All Rights Reserved. 16 今回お話する3つの辛いお話
 特定条件でLM失敗


    Rx,Tx Swap
 ブートしないゲスト
 問題編
 ブートしないゲスト
 Rx, Tx Swap
 特定条件でLM失敗

  16. © 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
  17. © 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 も失敗した はずでは?

  18. © 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
 ブートしないゲスト
 問題編

  19. © 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
  20. © 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
  21. © NTT Communications Corporation All Rights Reserved. 23 今回お話する3つの辛いお話
 特定条件でLM失敗


    Rx,Tx Swap
 ブートしないゲスト
 問題編
 ブートしないゲスト
 Rx, Tx Swap
 特定条件でLM失敗

  22. © 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
 ブートしないゲスト
 問題編

  23. © 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
 ブートしないゲスト
 問題編

  24. © 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
 ブートしないゲスト
 問題編

  25. © 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
 ブートしないゲスト
 問題編

  26. © 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
 ブートしないゲスト
 問題編

  27. © 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
 ブートしないゲスト
 問題編

  28. © NTT Communications Corporation All Rights Reserved. 31 今回お話する3つの辛いお話
 ブートしないゲスト


    Rx, Tx Swap
 特定条件でLM失敗
 特定条件でLM失敗
 Rx,Tx Swap
 ブートしないゲスト
 問題編

  29. © 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
 ブートしないゲスト
 問題編

  30. © NTT Communications Corporation All Rights Reserved. 35 CPv2 CPv2

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

  31. © NTT Communications Corporation All Rights Reserved. 36 CPv2 CPv2

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

  32. © NTT Communications Corporation All Rights Reserved. 37 2020年某日 Rolling

    Update 初週
 v1 v2 このVM、
 LMがうまく
 いっていないような…?
 特定条件でLM失敗
 Rx,Tx Swap
 ブートしないゲスト
 問題編

  33. © 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
 ブートしないゲスト
 問題編

  34. © 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
 ブートしないゲスト
 問題編

  35. © 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
 ブートしないゲスト
 問題編

  36. © NTT Communications Corporation All Rights Reserved. 41 • 原因


    ◦ 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
 ブートしないゲスト
 問題編

  37. © NTT Communications Corporation All Rights Reserved. 42 • 原因


    ◦ 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
 ブートしないゲスト
 問題編

  38. © NTT Communications Corporation All Rights Reserved. 43 • 原因


    ◦ 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
 ブートしないゲスト
 問題編

  39. © 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状態遷移

  40. © NTT Communications Corporation All Rights Reserved. 46 4つの解法
 1.

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

  41. © 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
 ブートしないゲスト
 問題編

  42. © 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
 ブートしないゲスト
 問題編

  43. © NTT Communications Corporation All Rights Reserved. 49 コストをかければ事前に全て炙り出せるという幻想
 特定条件でLM失敗


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


    Rx, Tx Swap
 特定条件でLM失敗
 特定条件でLM失敗
 Rx,Tx Swap
 ブートしないゲスト
 問題編

  45. © NTT Communications Corporation All Rights Reserved. 52 まとめ
 仮想マシン

    なにもわからない 
 だが、共に生きることはできる 
 

  46. © 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