いまからでも遅くない！仮想化基盤運用者に向けたコンテナ基盤移行で 気にすべきポイント

この資料は、「仮想化基盤の運用に携わっているが、将来コンテナ基盤の導入を検討することになりそうなので、仮想化基盤とコンテナ基盤の差異を知っておきたい」という方に向けて作成しました。
・仮想化基盤の運用と何が同じで何が変わるのか
・仮想化基盤からコンテナ基盤への移行は簡単なのか
・仮想化基盤とコンテナ基盤の使い分けはあるのか?
ということをテーマとしていますので、基盤運用者視点で知っておきたいことは何かを学び、それを各自で掘り下げてコンテナ基盤への移行をデザインするきっかけの一つとしてご利用ください。

留意点
　自分の学びとして調査した情報をまとめた個人の見解です。誤解して理解している箇所があるかもしれません。情報の正確性はご自身でもチェックください。

　上記のコンセプトのため、技術の掘り下げとしては浅い内容となっています。コンテナ基盤を深く知りたい方や、コンテナ基盤の運用ベストプラクティスを知りたい方向けの内容とはなっていない点に注意ください。
　また、すべての差異を網羅しているわけではありません（例えばライセンスの考え方やバージョンアップなどのライフサイクルの違いなど）。

Transcript

1. ςΫϊϩδʔࣄۀຊ෦ΧελϚʔαΫηε ͍·͔ΒͰ΋஗͘ͳ͍ʂ Ծ૝Խج൫ӡ༻ऀʹ޲͚ͨ ίϯςφج൫ҠߦͰ ؾʹ͢΂͖ϙΠϯτ ౔ଜ ஧ੜ 4FOJPS
   $VTUPNFS
   4VDDFTT
   .BOBHFS
   "DDPVOU
   4QFDJBMJTU ೔ຊΞΠɾϏʔɾΤϜגࣜձࣾ
2. © 2024 IBM Corporation 2 免責事項 セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独⾃の⾒解を反映したものです。それらは情報提供の⽬的のみで提供されており、 いかなる参加者に対しても法律的またはその他の指導や助⾔を意図したものではなく、またIBM製品やサービスがお客様に適⽤ある特定の法令に適合することを保証する ものでもありません。本講演資料に含まれている情報については、完全性と正確性を期するよう努めておりますが、「現状のまま」提供され、明⽰または黙⽰にかかわら ず、商業性、特定の⽬的への適合性、⾮侵害性を含め、いかなる保証も伴わないものとします。本講演資料またはその他の資料の使⽤によって、あるいはその他の関連に よって、いかなる損害が⽣じた場合も、IBMは責任を負わないものとします。 本講演資料で⾔及されるIBM製品、プログラム、またはサービスは、IBMがビジネスを⾏っ ているすべての国・地域でご提供可能なわけではありません。本講演資料で⾔及される将来の展望（製品リリース⽇付や製品機能を含む）は、市場機会またはその他の要 因に基づいてIBM独⾃の決定権をもっていつでも変更できるものとし、将来の製品または機能が使⽤可能になること、もしくは特定の結果を確約することを意図するもの ではありません。本講演資料は、⾔及される IBM製品またはサービスに適⽤ある契約条件を変更するものでも、追加の表明または保証を意図するものでもありません。 本講演資料に含まれている内容は、参加者の活動によって特定の結果が⽣じると述べる、または暗⽰することを意図したものでも、またそのような結果を⽣むものでもあ りません。 ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、⼊出⼒構成、ストレージ構 成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているものと同様の結果を 得られると確約するものではありません。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。 IBM、IBM ロゴ、ibm.com、 Instana 、 Turbonomic は、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。他の製品名およびサービス名等は、それぞれIBMまたは各 社の商標である場合があります。現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。 Red Hat、Red Hat Enterprise Linux(RHEL)、OpenShift、およびOpenShift Virtualizationは、Red Hat Inc.または⼦会社の⽶国およびその他の国における商標または登録商標です。 DockerおよびDockerのロゴはDocker,Inc.の⽶国およびその他の国における商標または登録商標です。 Cloud Native Computing Foundation、CNCF、Kubernetes、fluentd 、 Prometheusは、⽶国及びその他の国における The Linux Foundation の商標または登録商標です。 Rancherは、Rancher Labsの⽶国およびその他の国における商標または登録商標です。 Microsoft、 Windows、Windows Server、Azure、およびHyper-Vは，⽶国Microsoft Corporationの⽶国およびその他の国における登録商標または商標です。 Java およびすべての Java 関連の商標およびロゴは Oracle やその関連会社の⽶国およびその他の国における商標または登録商標です。 IOWN®は⽇本電信電話株式会社の商標または登録商標です。 Linux(R)は、⽶国およびその他の国におけるLinus Torvaldsの登録商標です。 Ubuntuは、Canonical Ltd.の商標または登録商標です。 VMware、VMwareロゴ、VMware ESXi、vMotion、vSphere HA、vSAN、Aria、Aria Operations、Aria AutomationおよびVAAI はVMware, Inc の⽶国およびその他の国における登録商標または商標です。 JP1は株式会社⽇⽴製作所の⽇本における商品名称（商標⼜は，登録商標）です。 Elastic、Elasticsearch、およびその他の関連するマークは、⽶国およびその他の国におけるElasticsearch B.V.の商標、ロゴ、または登録商標です。 Grafana、Lokiは、Grafana Labs, Incの⽶国およびその他の国における登録商標です。 NetApp、NetApp Astra Control Centerは、⽶国およびその他の国におけるNetApp, Incの登録商標です。 その他記載の会社名、製品名は、それぞれの会社の商標または登録商標です。
3. © 2024 IBM Corporation 3 講座の⽬的と ゴール 仮想化基盤の運⽤に携わっているが、将来コンテナ基盤の導⼊を 検討することになりそうなので、知識を深めておきたい ・仮想化基盤の運⽤と何が同じで何が変わるのか ・仮想化基盤からコンテナ基盤への移⾏は簡単なのか ・仮想化基盤とコンテナ基盤の使い分けはあるのか ⼊⾨レベルで基盤運⽤者視点で知っておきたいことは何かを学ぶ (Kubernetesの細かな構成、例えばMasterの構成要素はetcd, Manager..とかには触れません) この講座からの学び ・仮想化基盤とコンテナ基盤の違いを理解する それぞれの技術の成り⽴ちと実装の違い ・コンテナ基盤に乗せるべきアプリケーションの要件・特性 ・仮想化基盤に残すべきアプリケーションの要件・特性 ・仮想化基盤とコンテナ基盤での運⽤の考え⽅の差異 免責事項にありますが、過去のVMwareの学びをベースにKubernetesを個⼈的に調査してまとめましたので、誤って理解してい る場合もあります。この観点で確認が必要だというポイントを押さえる⽬的で利⽤し、ご⾃分で事実確認と深掘りください。
4. © 2024 IBM Corporation 4 経歴：30年以上IT関連の職務 ⼟村 忠⽣ つちむら ただお Senior Customer Success Manager VMware vEXPERT 2012-2022 企画開発職：ソフトウェア企画開発 技術営業職：仮想化基盤プリセールス プロダクト企画職：仮想化ソリューション企画開発 事業企画職：全社技術戦略リサーチ Customer Success Manager Architect 2021/4 2003/9 1990/4 C, C++, Java クラサバ 携帯情報端末 VMware Hyper-V vSAN, HCI Azure Stack HCI Hybrid Cloud 量⼦コンピューティング HPC Processer Cloud 5G スマートカード認証 2022/4 IOWN コンシューマー向けソフトウェアからエンタープライズソフトウェアの開発と マネジメントの経験 シンクライアントから仮想化OEMの⽴ち上げ、検証、教育、技術⽀援、仮想化 ソリューション企画などの経験（シンクライアント端末、IAサーバ＆ストレージ） 経営トップ層の技術投資判断のための技術リサーチのチームをマネジメント＆Playing メガバンクのお客様担当：購⼊頂いたHybrid Cloud SWのDeployment＆Renewalを推進
5. © 2024 IBM Corporation 5 アンケートの お願い Slidoへの 参加⽅法 WebExまたは以下のいずれかの⽅法でブラウザ・スマホなどから 回答をお願いいたします。 23ίʔυಡΈऔΓ Լه63-΁ΞΫηε͠ IUUQTBQQTMJEP Πϕϯτίʔυ EPKPQN Λೖྗ もしくはこちら https://app.sli.do/event/qLR8CcjeSSyqekT5zWbgj1 今回盛りだくさんのため、質問があればアンケートに記載ください。 connpassで可能なものは回答予定です。
6. © 2024 IBM Corporation 6 講義内容 1.仮想化とコンテナの成り⽴ち 2.インフラデザインの違いを知る（コンテナ） 3.インフラ構築の違いを知る（コンテナ） 4.インフラ運⽤の違いを知る（Kubernetes）
7. © 2024 IBM Corporation 7 仮想化とコンテナの成り⽴ち ͦΕͧΕͷٕज़ͷ੒ΓཱͪΛ஌Δ͜ͱͰɺͦΕͧΕͷ໨ࢦͨ͠ํ޲ੑͷҧ͍Λཧղ͢Δ Ծ૝Խʢ7.XBSFʣ ίϯςφʢ%PDLFSʣ ,VCFSOFUFT ஂମ໊ VMware Inc Docker Inc CNCF Cloud Native Computing Foundation 7FSϦϦʔε࣌ظ 2001(VMware ESX Server) 2013 2016設⽴ Kubernetesは2015 V1.0 ։ൃͷϕʔε Berkeleyの研究室から メインフレームの仮想化を x86へ Linuxのcgroups(2006) （だと思いますが確証なし） Google Borg コンテナはCRI-O ૂ͍ ハードウェアレベルの仮想化 OSレベルの仮想化 コンテナオーケストレーション ར༻ྖҬʢ౰ॳʣ レガシーOS延命と リソース集約 開発環境効率化 クラウドネイティブ技術 ؅ཧͷࢹ఺ʢϨΠϠʔʣ インフラ アプリケーション 単⼀ノード 運⽤（インフラ、アプリ） クラスター（複数ノード） ϝοηʔδ 7JTPO Any Cloud, Any Application, Any Device Build, Ship, and Run Any App, Anywhere Cloud Native Definition ߏங パッケージを導⼊ （Install & Setup） Infrastructure as Code Infrastructure as Code ໨ࢦͨ͠ํ޲ੑ 仮想化基盤（集約） DevOps クラウドネイティブ コンテナ基盤運⽤
8. インフラデザインの違い 仮想化基盤とコンテナ基盤の差異その1 仮想化とコンテナ技術の成り⽴ちの違いから、それぞれの技術の デザインの違いを学ぶ 画像：いらすとや
9. © 2024 IBM Corporation 9 仮想化環境とコンテナ環境の違い（ベーシック） それぞれの技術のデザインの差異を理解することで、利⽤⽤途の違いも理解する Ϣʔβۭ̙ؒ ίϯςφ Ϣʔβۭ̗ؒ ίϯςφ Ծ૝Ϛγϯ̙ Ծ૝Ϛγϯ̗ 7.XBSF
   &49J ʢϋΠύʔόΠβʣ 7.XBSF
   &49J ʢϋΠύʔόΠβʣ Ծ૝Ϛγϯ̖ Ծ૝Ϛγϯ̘ ήετ̨̤ ΞϓϦέʔγϣϯ ήετ̨̤ ΞϓϦέʔγϣϯ Ծ૝Խ؀ڥ ϗετ̨̤ ʢΧʔωϧʣ ϗετ̨̤ ʢΧʔωϧʣ Ϣʔβۭ̖ؒ ίϯςφ Ϣʔβۭ̘ؒ ίϯςφ Ϣʔβʔϓϩηε Ϣʔβʔϓϩηε ίϯςφ؀ڥ ू໿౓Λ͋͛ͯ෺ཧαʔό୆਺Λ࡟ݮ͍͔ͨ͠ΒɺԾ૝؀ڥΛίϯςφ؀ڥʹ੾Γସ͑Δͱ͍͏ൃ૝͸/( 仮想化からコンテナ移⾏を検討する時に、コンテナ環境の軽量性を活かせるのではと短絡的に思考してはいけないポイント ίϯςφϥϯλΠϜ ίϯςφϥϯλΠϜ ΧʔωϧΛϢʔβۭؒ" #͕ڞ༗͢Δ͜ͱͰ7.ΑΓܰྔԽ ゲストOS は不要
10. © 2024 IBM Corporation 10 Ϣʔβۭ̗ؒ コンテナデザインのポイント① コンテナの特性（強み）を活かすデザインを⼼がけよう ϗετ̨̤ ʢΧʔωϧʣ Ϣʔβۭ̖ؒ Ϣʔβϓϩηε ᶃܰྔੑΛ׆͔ͨ͠σβΠϯ Ϣʔβϓϩηε Ϣʔβϓϩηε ίϯςφͷܰྔੑΛଛͳΘͳ͍ ̍ίϯςφ̍ϓϩηεઃܭ͕جຊ ϗετ̨̤ ʢΧʔωϧʣ Ϣʔβۭ̖ؒ Ϣʔβϓϩηε ᶄσʔλ͸ίϯςφͱ໋ӡΛڞʹ͢Δ ίϯςφ͕ഁغ͞ΕΔͱσʔλ΋ফ͑Δɺ ΠϛϡʔλϒϧʢشൃʣͳσβΠϯ͕جຊɻ Ӭଓ͍ͤͨ͞σʔλ͸ίϯςφͷ֎ʹอଘ σʔλ
11. © 2024 IBM Corporation 11 コンテナデザインのポイント② データの持ち⽅、保全の仕⽅の基本を理解しよう Ϣʔβۭ̗ؒ ϗετ̨̤ ʢΧʔωϧʣ Ϣʔβۭ̖ؒ Ϣʔβϓϩηε Ϣʔβϓϩηε Ծ૝ϚγϯΛ όοΫΞοϓ ˣ ίϯςφΛ όοΫΞοϓ ᶆόοΫΞοϓσβΠϯ ӬଓσʔλΛ࣋ͯͳ͍͔Βɺ ίϯςφͷόοΫΞοϓ͸ෆཁɻ *OGSBTUSVDUVSF
    BT
    $PEFͰ͙͢ʹ ίϯςφ͸࠶ݱग़དྷΔ͔Βɺ औΔͳΒίʔυͱϢʔβσʔλ ᶅอ͍࣋ͨ͠ϩά΍σʔλ͸ίϯςφ֎΁ ϗετ̨̤ ʢΧʔωϧʣ Ϣʔβۭ̖ؒ Ϣʔβϓϩηε σʔλ σʔλ ϗετ΍֎෦ͷϘϦϡʔϜͱಉظΛ औͬͯσʔλͷอશରࡦΛऔΔ όοΫΞοϓ͸ ͜͜ΛऔΔ
12. © 2024 IBM Corporation 12 補⾜＠コンテナ環境でのストレージの考え⽅ 仮想マシンとは異なり、プロセス終了や電源断でデータも消える Ծ૝Խ؀ڥ ϩʔΧϧετϨʔδ ίϯςφ؀ڥ 7.XBSF
    &49J ϗετ04 ίϯςφϥϯλΠϜ コンテナアプリケーション OSとアプリ コンテナの 中にデータ を保存 仮想マシンの中 にデータを保存 コンテナ終了と共にデータも喪失 ίϯςφʹอ࣋ͨ͠σʔλ͸ɺͲ͜ʹ΋Ҿ͖ܧ͕Εͣίϯςφͱӡ໋Λڞʹ͢Δ࢓༷ ಛʹίϯςφͷϩά͕ফ͑Δ͜ͱ͸ɺτϥϒϧγϡʔτʹக໋తͳӨڹΛٴ΅ͨ͢Ίରࡦ͕ඞਢ 仮想マシン終了でもデータを保持 VM OS APP VM VM VMDK VMDK VMDK コン テナ コン テナ
13. © 2024 IBM Corporation 13 実際の画⾯での確認 コンテナを終了させ、同じ⼿順で起動した場合のデータの⾒え⽅をご覧いただきます。 Ubuntu コンテナ上のコンソールからtestfile.txtを作成 コンテナを終了して、再度同じ⼿順でコンテナを起動 Ubuntuイメージからubuntutest01コンテナを起動 Ubuntu上に作成していたtestfile.txtは存在しない VMwareでは、VMを構成する仮想マシンA.VMXファイルとゲストOSやデータを格納している仮想マシンA.VMDK を使って起動し、ファイル作成して終了し、また同じ仮想マシンAファイルを起動しても作成したファイルは存在する
14. © 2024 IBM Corporation 14 コンテナ環境には永続ストレージを導⼊する プロセスが終了しても保持したいデータは、永続ストレージに格納する ίϯςφ؀ڥ 7.XBSF
    &49J ϗετ04 ڞ༗ετϨʔδʢ7.'4
    PS
    W4"/ʣ ίϯςφϥϯλΠϜ コンテナアプリケーション コンテナから 永続ストレージ へデータを移す コンテナ環境のログやデータの保存のために、永続ストレージを導⼊する Ծ૝Խ؀ڥ ڞ༗ετϨʔδ HW障害でダウ ンしたVMを別 のHWで再起動 7.XBSF
    &49J ӬଓετϨʔδ 1FSTJTUFOU
    7PMVNF 17
    仮想環境はデータ保全 ⽬的よりは、運⽤を効 率化する機能利⽤ （vMotionやHA）を 活⽤する⽬的が強い コンテナ環境は、必要なデータを保持する ⽬的でストレージを導⼊するから、 “永続”ストレージと呼ばれている VM VMDK VM コン テナ
15. © 2024 IBM Corporation 15 実際の画⾯での確認 永続ストレージにマウントしたコンテナを終了させ、起動した場合のデータの⾒え⽅をご覧いただきます。 永続ストレージqm1dataを/home/testvolに マウントさせてコンテナを起動 Testvolにtestfile.txtを作成 コンテナを終了して、再度同じ⼿順でコンテナを起動 永続ストレージ上に作成していたtestfile.txtが残っている
16. © 2024 IBM Corporation 16 サーバ集約⽬的で仮想環境をコンテナ環境へ単純移⾏することは出来ない理由① VMwareで出来る構成とコンテナで出来る構成の違い Ϣʔβۭ̙ؒ 3)&- Ϣʔβۭ̗ؒ 3)&- 7.XBSF
    &49J ʢϋΠύʔόΠβʣ Ծ૝Ϛγϯ̖ 8JOEPXT
    4FSWFS
     /&5ΞϓϦ Ծ૝Խ؀ڥ ϗετ̨̤ 3)&- ʢΧʔωϧʣ Ϣʔβۭ̖ؒ 3)&- Ϣʔβۭ̘ؒ 3)&- Ϣʔβʔϓϩηε Ϣʔβʔϓϩηε ίϯςφ؀ڥ ϗετ04ͷΧʔωϧΛڞ༗ग़དྷͳ͍ҟͳΔ04΍όʔδϣϯґଘͷΞϓϦέʔγϣϯ͸Քಇ͠ͳ͍ Ծ૝Ϛγϯ# 8JOEPXT
    4FSWFS
     ΞϓϦ Ծ૝Ϛγϯ$ 3)&-
     ΞϓϦ Ծ૝Ϛγϯ% 3)&-
     ΞϓϦ 8JOEPXTͱ3)&-ɺ͋Δ͍͸ҟͳΔόʔδϣϯ˞Ͱ ߏ੒͞Εͨ7.ΛҰͭͷΧʔωϧͰڞ༗Ͱ͖ͳ͍ ίϯςφϥϯλΠϜ ίϯςφϥϯλΠϜ ※例えばLinux Kernelの互換の範囲内で稼働するアプリは ホストのLinux versionと異なっていても稼働する場合がある コンテナ化すればどこでも稼働は、厳密には間違い
17. © 2024 IBM Corporation 17 単純なサーバ集約⽬的で仮想環境をコンテナ環境へ単純移⾏は出来ない理由② アプリケーションがコンテナ環境のお作法に則っているかもしっかり確認しよう Ϣʔβۭ̙ؒ Ϣʔβۭ̗ؒ Ծ૝Ϛγϯ̙ Ծ૝Ϛγϯ̗ 7.XBSF
    &49J ʢϋΠύʔόΠβʣ 7.XBSF
    &49J ʢϋΠύʔόΠβʣ Ծ૝Ϛγϯ̖ Ծ૝Ϛγϯ̘ ήετ̨̤ ΞϓϦέʔγϣϯ ήετ̨̤ ΞϓϦέʔγϣϯ Ծ૝Խ؀ڥ ϗετ̨̤ ʢΧʔωϧʣ ϗετ̨̤ ʢΧʔωϧʣ Ϣʔβۭ̖ؒ Ϣʔβۭ̘ؒ Ϣʔβʔϓϩηε Ϣʔβʔϓϩηε ίϯςφ؀ڥ ストレージ（共有ボリューム） 永続ストレージ 永続ストレージ 共有ボリュームへの書き込み 排他制御はVMFS or VAAIが実施 共有ファイルの書き込み 排他制御はアプリで考慮 ྖҬഁյʹΑΔۀ຿ఀࢭʹͳΒͳ͍Α͏ʹίϯςφҠߦ͢ΔΞϓϦΛબఆ͢Δ͜ͱ ίϯςφϥϯλΠϜ ίϯςφϥϯλΠϜ OpenShift徹底⼊⾨ P268 永続ボリューム(PV)への アクセス制御を参照
18. © 2024 IBM Corporation 18 VMware環境とコンテナ環境のストレージ制御の違い KubernetesやOpenShiftには、VMware VAAIのHardware Assisted Lockingを使うような仕組みはない ストレージとのインタフェースであるCSIドライバーのストレージベンダー実装内容を要確認 VAAI（VMware vSphere storage APIs Array Integration）：ESXiからストレージへのアクセス処理をストレージ側にオフロードして、 ESXi側の負荷を軽減する技術。ストレージベンダーがPlug-Inを提供 CSI（Container Storage Interface）: コンテナ基盤（Kubernetes）のコンテナワークロードにストレージを公開するインターフェース ストレージベンダーがCSIドライバー（コンテナイメージ）を提供 7""*ͷετϨʔδॲཧ Ծ૝Խʢ7.XBSF
    7""*ʣ ίϯςφʢ$4*ʣ 'VMM
    $PQZ 7.ෳ੡
    4OBQTIPU • •Volume Cloning, Snapshot #MPDL
    ;FSPJOHʢ7PMॳظԽʣ • )BSEXBSF
    "TTJTUFE
    -PDLJOHʢഉଞ੍ޚʣ •（Block単位） 5IJO
    1SPWJTJPOJOH
    4QBDF
    3FDMBNBUJPO ະ࢖༻ྖҬͷղ์ • ॲཧͷΦϑϩʔυ͕໨తͷ7""*ͱɺ$4*͸ํ޲ੑ͕ҧ͏ͷͰҰ֓ʹൺֱ͸ग़དྷͳ͍
19. © 2024 IBM Corporation 19 インフラデザインの違いの章での理解ポイント ʮԾ૝ϚγϯΛͦͷ··ίϯςφʹҠߦ͢Δʯͱ͍͏εςοϓ͸ຊےͰ͸ͳ͍ɻ ΞϓϦέʔγϣϯΛΫϥ΢υωΠςΟϒΞʔΩςΟΫνϟʹϦϥΠτʢϞμφΠζʣ͢Δ͜ͱΛਪ঑ Ծ૝Խ؀ڥͷཁ݅΍࢓༷Λͦͷ··ʹɺίϯςφʹ͢Δͱ ΋ͬͱޮ཰ԽͰ͖ΔΑͶɺͱ͍͏͍ܰߟ͑Ͱಋೖࣦͯ͠ഊ ͢Δέʔε͕ଟ͍ Ϋϥ΢υωΠςΟϒʹϦϥΠτ͢Δͷ͸޻਺΋ίετ΋͔͔Γେมɻ ΋͏গָ͠ʹԾ૝؀ڥΛίϯςφ؀ڥʹҠߦ͢Δ͜ͱ͸ग़དྷͳ͍ͷʁ
20. © 2024 IBM Corporation 20 RedHat OpenShift Virtualization 仮想マシンをコンテナに変換ではなく、仮想マシンをそのままコンテナ基盤で動かすという発想 ΞϓϦέʔγϣϯͷϞμφΠζԽͱڞʹԾ૝Ϛγϯ΋ίϯςφͰ؅ཧ͢Δӡ༻؅ཧͷҰݩԽʹ࠷ద 集約してリソース最適化をさらに進める道具ではなく、仮想化基盤の移⾏形態の⼀つとして捉えるべき 1PE ϗετ̨̤ ʢ3)&-
    $PSF04ʣ ϗετ̨̤ ʢ3)&-
    $PSF04ʣ 0QFO4IJGU 1PEɿίϯςφ܈ 仮想マシン⾯ RHEL、Windows仮想マシン稼働可 https://access.redhat.com/articles/973163#ocpvirt VMwareの分散仮想スイッチ対応 GPU, vTPM(Windows 11稼働に必須)もサポート 複数VMから物理アダプタを利⽤するSR-IOVも可能 (ただしvMotion/HAが利⽤不可の機能制約なのでほぼ未利⽤？) VMwareからOpenShift Virtualizationへの移⾏ツール Red Hat Migration Toolkit for Virtualization (MTV) 運⽤⾯ ・vMotion(永続ボリュームとRWXで接続必須), HA相当の管理が可能 [OpenShift Virtualization] Node跨ぎのLive Migrationで本当にVMは停 ⽌しないのか検証してみた @masaki-oomura様公開記事 詳細はRedHatサイトへ https://www.redhat.com/ja/technologies/cloud-computing/openshift/virtualization Ծ૝Ϛγϯ̖ ήετ̨̤ ΞϓϦέʔγϣϯ Ϣʔβۭ̖ؒ Ϣʔβʔϓϩηε
21. インフラ構築の違い 仮想化基盤とコンテナ基盤の差異その2 それぞれの技術の構築の違いを学ぶ 画像：いらすとや
22. © 2024 IBM Corporation 22 αʔόʔηοτΞοϓ 今までのサーバ構築の流れ（⼈⼿の作業） ؅ཧπʔϧ΍ϛυϧ΢ΣΞɺ ΞϓϦέʔγϣϯηοτΞοϓ ຊ൪ۀ຿ωοτϫʔΫ΁ͷ઀ଓ 4&561 ・HW設定(BIOS, 他) ・OSとドライバー ・HW設定（BIOS、他） ・ハイパーバイザー インストールと設定 ・仮想マシン作成など OR ϥοΩϯάʢϥοΫ΁ͷηοςΟϯάʣ
23. © 2024 IBM Corporation 23 仮想マシンの作成 新規作成 テンプレートから作成 仮想マシンの複製 vSphere ClientからGUIで仮想マシンを 払い出すのが⼀般的 ⼤規模環境では、VMware Aria Automation で、カタログからセルフサービスも可能
24. © 2024 IBM Corporation 24 αʔόʔηοτΞοϓ コンテナ基盤の構築の流れ＝今までのサーバー構築の流れとほぼ同じ（⼈⼿の作業） ؅ཧπʔϧ΍ϛυϧ΢ΣΞɺ ΞϓϦέʔγϣϯηοτΞοϓ ຊ൪ۀ຿ωοτϫʔΫ΁ͷ઀ଓ 4&561 ・HW設定（BIOS、他） ・コンテナランタイム (+ OpenShiftなど) インストールと設定 ・ノード作成、クラスタ 作成など ϥοΩϯάʢϥοΫ΁ͷηοςΟϯάʣ ロードバランサー
25. © 2024 IBM Corporation 25 コンテナ構築（Infrastructure as Code：コード実⾏） Dockerfile（コンテナ定義） マニフェスト（Kubernetes） $PEFॻ͍ͯ#VJMEͯ͠ίϯςφΠϝʔδΛ࡞੒ 4IJQ ࣮͠ߦ 3VO ͢Δ ɾίϯςφ಺ͷωοτϫʔΫ͸ࣗಈઃఆ ɾίϯςφ֎ͱͷ઀ଓ͸ϩʔυόϥϯαʔͷϙʔτΛࢦఆ͢Δ͚ͩ ଞͷ΍Γํ΋͋Δ コード化されているので、⾃動化のレベルは仮想化基盤よりも進歩している コンテナ基盤にはロードバランサーは必須といっても良い
26. © 2024 IBM Corporation 26 コラム YAML記述のルールは事前に把握 $
    $ Ͱ։ൃ͖ͯͨ͠਎ʹ͸ɺ:".-ͷهड़ͷ͓࡞๏͕ িܸͰͨ͠ɻ <λϒ>ίʔυݫې Πϯσϯτ͸൒֯εϖʔεͰ Πϯσϯτ͕$ $ ͷ ΍\^ͷ୅ΘΓ ͳͷͰɺۭനͷ਺Λἧ͑Δ͜ͱɻ ͜Μͳ୯७ͳࣄΛ஌Βͳ͍ͱɺݟͨ໨͸ ؒҧ͍ͬͯͳ͍ͷʹಈ͔ͳ͍ͷͰࠔ࿭͠·͢ɻ Ŗ
    ͸഑ྻͰӈล͕഑ྻͷཁૉͩʜͳΜͯɻɻɻ
27. © 2024 IBM Corporation 27 最⼤構成の⽐較 7.XBSF
    W4QIFSF
     ,VCFSOFUFT
    7 ."9
    7.ʛίϯςφ  $MVTUFS   ."9 )PTUʛϊʔυ    ."9
    $MVTUFSʛ1PE     W$FOUFS؅ཧ10/
    7.   W$FOUFS؅ཧ&49J )PTU   VMware vSphere7.0 Configuration Limits https://configmax.esp.vmware.com/guest?vmwareproduct=vSphere&release=vSphere%207.0&categories=2-0 Kubernetes ⼤規模クラスターの構築 https://kubernetes.io/ja/docs/setup/best-practices/cluster-large/
28. インフラ運⽤の違い 仮想化基盤とコンテナ基盤の差異その4 運⽤構成、監視、ログ、可⽤性、メンテナンス、 仮想マシンとコンテナの払い出しはどう違う？ 画像：いらすとや
29. © 2024 IBM Corporation 29 仮想化基盤とコンテナ基盤運⽤の考え⽅の違い コンテナ基盤の運⽤は、仮想化基盤の運⽤⽅針からマインドセットを変える必要がある ಉ͡ۀ຿ӨڹΛ཈͑Δ໨తͰ΋ɺ࣮ݱ͢ΔͨΊͷσβΠϯͷΞϓϩʔν͕·ͬͨ͘ҟͳΔͨΊɺ Ծ૝Ϛγϯ͔Βίϯςφ΁ͷ୯७Ҡߦ͸ةݥ Ծ૝Խ؀ڥ ίϯςφ؀ڥ &49J ϗετ04 ίϯςφϥϯλΠϜ &49J ・システムの特性に応じて、可⽤性のレベル/SLAに応じて松⽵梅構成で インフラを分けてがっつり管理できるデザインにしがち ・VMがどのハードウェアで動いているか把握したい、 動く先を管理したい要求（欲求かも）がある ・仮想マシンが⼀つでもダウンすることは由々しき⾃体として処理 される（特に松レベル） ・根本原因は何かを追求して、2度とダウンが発⽣しない対策を求める ・余裕を持ったサイジングで導⼊し、5年間変更せず塩漬け運⽤する 業務停⽌を防ぐ⽬的でダウンしない堅牢なシステムを追求 業務停⽌を防ぐ⽬的でダウンしても影響しないシステムを追求 ・ダウンしても業務影響がないようにコンテナのデザインを⾏う ・コンテナが１つダウンしても動ぜずに、システム全体として定義 された“あるべき姿”と⽐べて問題があるかを重視 基盤⾃⾝も”あるべき姿”を保つ様に⾃律して稼働する(Kubernetes) →クラウドネイティブデザインが依存関係は疎結合、処理はマイクロ サービス化されていることも上記の考え⽅に影響 ・コンテナがどのハードウェアで稼働するかは意識しないし、 Deployment要求に対してはシステム側が稼働先を⾃動処理する ଞͷίϯςφͰΧόʔͰ͖Δ͔Β0, ͜Ε͕མͪΔͱۀ຿͕ࢭ·Δʜ 7. 7. 7. 7. 7. 7. ίϯ ςφ ίϯ ςφ ίϯ ςφ ίϯ ςφ ίϯ ςφ ίϯ ςφ ϗετ04 ίϯςφϥϯλΠϜ
30. © 2024 IBM Corporation 30 Kubernetes Ϋϥελ σʔληϯλʔ Ϋϥελʔ )"
    $MVTUFS
    %34
    $MVTUFSͳͲʣ VMware環境を⾼度に運⽤管理するAriaとOpenShiftが同じ様な⽴ち位置 ベーシックな運⽤管理のvCenterの⽴ち位置は、Kubernetesが該当 コンテナ基盤の構成要素をVMware構成で例えてみる ϊʔυ XPSLFS 1PE ίϯςφ ίϯςφ ϊʔυ 1PE ίϯςφ 7.XBSF
    W$FOUFS &49J &49J W"QQ 7.ͷάϧʔϓ 7. 7. 7. 7. ϚχϡϑΣετ ,VCFSOFUFTͷ ઃఆϑΝΠϧ 7.XBSF
    "SJB 0QFO4IJGU
    3BODIFSͳͲ ུه͸,T Ϛελʔϊʔυ ίϯςφ੍ޚ Ϛελʔϊʔυ ίϯςφ੍ޚ Ϛελʔϊʔυ ίϯςφ੍ޚ 注意：KubernetesはDockerコンテナは⾮推奨 CRI-O等別のコンテナランタイムを利⽤ vAPPにはIPアドレスは割り当てないが、 PodにはIPアドレスが割り当てられる ϊʔυ *OGSB 1PE ؔ࿈ίϯςφΛάϧʔϓԽͯ͠؅ཧ ίϯςφ ϊʔυ *OGSB ίϯςφ ϊʔυ *OGSB 3PVUFS -PHHJOH
    5PPM 3FHJTUSZ .POJUPSJOH
    5PPM OpenShiftのライセンス課⾦ はworkerノードのみ σʔληϯλʔ vAppの作成 https://docs.vmware.com/jp/VMware- vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-2A95EBB8- 1779-40FA-B4FB-4D0845750879.html
31. © 2024 IBM Corporation 31 KubernetesとOpenShift運⽤構成の差分 ベーシック構成と⾼度な運⽤管理の差分例 Red Hat OpenShift とKubernetes https://www.redhat.com/ja/technologies/cloud-computing/openshift/red-hat-openshift-kubernetes エンタープライズ利⽤であれば、運⽤構成とサポート⾯でOpenShift利⽤を推奨
32. © 2024 IBM Corporation 32 ・コンテナを運⽤・管理する単位であり、KubernetesにDeployする時はPod単位に実施する ・Podはコンテナ１つのシングルコンテナPodと、関連するコンテナを束ねて管理するマルチコンテナPodがある 補⾜：Podとは 1PE ίϯςφ ίϯςφ 1PE ίϯςφ ίϯςφ ReplicaSet Deployment Kubernetesではコンテナ単位ではなく、 Pod単位で管理する Podを管理するオブジェクト。 複数のPodをグループ化する際に ReplicaSetを利⽤する ReplicaSetを管理するオブジェクト。 Podの変更を検知し、新しいReplicaSet を作成しコンテナを置き換える。 ローリングアップデートでも活⽤する。 1PE
    *1ΞυϨε ίϯςφ ίϯςφ 1PE
    *1ΞυϨε ίϯςφ ネットワークネームスペース ネットワークネームスペース ストレージネームスペース ストレージネームスペース ・Pod内のコンテナは同じホストで稼働するが、 相互に隔離されており、独⽴して稼働する (Linux namespace, cgroupsなど活⽤) ・Podがダウンすると新たなPodが⽴ち上がり 可⽤性を保つことができる ・同じPod内に関連するコンテナを集めて、 コンテナ間の通信をシンプル化できる
33. © 2024 IBM Corporation 33 1PE
     ・仮想環境では、仮想マシン１つ１つがIPアドレスを保有する。固定IPも可 ・コンテナ環境では、Podに対してIPアドレスを割り当て、Pod内のコンテナでIPアドレスを共有する(Pod再起動で別IP割当て) 補⾜：IPアドレス問題 Ծ૝Ϛγϯ͔ΒίϯςφҠߦͰ͸*1ΞυϨεͷ࠶ઃܭΛߟྀ͢Δඞཁ͕͋Δ Ծ૝Խ؀ڥ ίϯςφ؀ڥ &49J  ϗετ04  ίϯςφϥϯλΠϜ &49J  7.ຖʹ*1ΞυϨεͱ."$ΞυϨεΛอ༗ 7.  ίϯ ςφ ίϯ ςφ 7.  7.  7.  ݻఆ*1ɺ(MPCBM
    *1ׂΓ౰ͯՄ 1PE
     ίϯ ςφ ίϯ ςφ 1PEຖʹ*1ΞυϨεͱ ωοτϫʔΫωʔϜε ϖʔεΛอ༗ Kubernetesには、4つの異なる対応すべきネットワークの問題があります: 1.⾼度に結合されたコンテナ間の通信: これは、Podおよびlocalhost通信によって解決されます。 2.Pod間の通信: 本ドキュメントの主な焦点です。 3.Podからサービスへの通信: これはServiceでカバーされています。 4.外部からサービスへの通信: これはServiceでカバーされています。 https://kubernetes.io/ja/docs/concepts/cluster-administration/networking/ Service(Iptables) L4ロードバランサー ・ノード間通信はVXLAN（オーバレイ）を利⽤ ・外部との通信はKubernetesにIngressを追加 L7ロードバランサーを利⽤ 1PE಺ͷίϯςφؒ͸ MPDBMIPTU௨৴ ネットワークネームスペース ネットワークネームスペース ⽤途 VMware vSwitch Kubernetes 管理/vMotion LAN(L2/L3) VMkernel Port ?? 業務LAN(L4-L7) VM port group Service / Ingress 物理NIC接続⽤ Up link Port ホストOS側で実施 チーミング 可（vmnicを束ねる） 可（ボンディング） vSwitch (VM Port Group) vSwitch (VM Port Group) Up link port Up link port vNIC vNIC vNIC vNIC Veth Veth ϗετ04  ίϯςφϥϯλΠϜ 1PEͷ࠶ىಈͰ*1ΞυϨε͕มΘΔͨΊɺ4FSWJDFΛ࢖͍Ծ૝*1ͰݻఆԽ
34. © 2024 IBM Corporation 34 インフラの可⽤性の違い 障害発⽣時の⾃動復旧の仕組みはどう変わるのか？ 7.XBSF
    &49J 7. Ծ૝Խج൫ ίϯςφج൫ ڞ༗ετϨʔδ ίϯςφ͸ىಈ͸ૣ͍͕ɺSFTUBSU1PMJDZͰىಈ·Ͱͷ࣌ؒઃఆʹӨڹΛड͚Δ 7. 7. *NBHF W4QIFSF
    )" ・仮想マシンがダウンした場合は、 同じESXi上で仮想マシンを再起動 7.XBSF
    &49J 7.XBSF
    &49J 7. vSphere HA Cluster ・仮想マシンのBootが発⽣するので、 起動は分単位かかる ・ダーティシャットダウンからの 起動なので、アプリケーションの リカバリーを⾏う場合あり 7. 7. *NBHF W$FOUFS ؂ࢹ ,T
    XPSLFS
    OPEF ίϯ ςφ ӬଓετϨʔδ ίϯ ςφ ίϯςφ *NBHF ,VCFSOFUFT
    4FMGIFBMJOH ・コンテナがダウンした場合は、 マニュフェストに則って⻘コンテナ をDeployし２つ稼働を保つ ,T
    XPSLFS
    OPEF ,T
    NBTUFS
    OPEF ίϯ ςφ ・数秒単位で状態を 回復する ・コンテナの作り直し 永続ストレージの データは引き継ぐが、 プロセスは新規 ίϯ ςφ ϚχϡϑΣετ ίϯ ςφ ２つ稼働 ・ESXiがダウンした場合は、 HA Cluster内のESXi上で再起動 ・worker nodeがダウンした場合も、 別のworker nodeでマニュフェストの 状態を保つ様にDeployする
35. © 2024 IBM Corporation 35 補⾜：Kubernetesの⾼可⽤性 ヘルスチェック機構 ⽣死監視だけではなく、アプリケーションのリクエスト処理の可否状態も監視 ՔಇதͰ΋ॲཧग़དྷͳ͍൒ࢮঢ়ଶͷݕग़ͳͲΛิ͏ͨΊʹ΋྆ํ׆༻͢Δ͜ͱΛ͓קΊ Liveness Probe（⽣死監視） Readiness Probe（準備監視） 指定時間の間隔でアプリケーションの⽣死を監視する。 アプリケーションのダウンを検知したら、Kubernetes が ⾃動的に Pod を終了して再起動する。 指定時間の間隔でアプリケーションへのリクエスト処理を 監視する。 アプリケーションが処理出来ない状態であれば、 Kubernetes がロードバランサーなどを制御して、 該当アプリへの通信を⾏わないようにする 1PE
     ίϯ ςφ ίϯ ςφ ネットワークネームスペース 1PE
     ίϯ ςφ ίϯ ςφ ネットワークネームスペース Kubernetes Document: Liveness Probe、Readiness ProbeおよびStartup Probeを使⽤する https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ pods/probe/exec-liveness.yaml periodSecondsフィールドは、 kubeletがLiveness Probeを5秒 おきに⾏うように指定。 initialDelaySecondsフィール ドは、kubeletが最初のProbe を実⾏する前に5秒間待機する ように指定。 Service Liveness Probe 正 常 異 常 再起動 kubelet 1PE
     ίϯ ςφ ίϯ ςφ ネットワークネームスペース 1PE
     ίϯ ςφ ίϯ ςφ ネットワークネームスペース Service readiness Probe 正 常 異 常 トラフィックカット kubelet
36. © 2024 IBM Corporation 36 インフラのメンテナンス性の違い vMotion(Live Migration)のような仕組みはあるのか？ → どちらもローリングアップデートができる仕掛けあり ίϯςφج൫
    ϩʔϦϯάΞοϓσʔτ 7.XBSF
    &49J 7. Ծ૝Խج൫ ڞ༗ετϨʔδ 7. 7. *NBHF ϝϯςφϯεϞʔυ ・ESXiをメンテナンスモードにする と、vMotionで仮想マシンを別のESXi 上に移動する ・移動が完了したらESXiのメンテナ ンスをして再起動（⼿動）する 7.XBSF
    &49J 7.XBSF
    &49J vSphere HA Cluster ・vMotion(DRS)なので、 ネットワークが瞬断するが、 TCPIPの⾃動リカバリで セッションを維持（無停⽌） ①同じ仮想マシンを 起動（Net-OFF) ②メモリ情報をコピー（繰り返す） 静⽌点を取って最後のコピー。 ③RARPを投げてスイッチのMAC アドレステーブルを書き換え、 ネットワーク経路を切り替える ,T
    XPSLFS
    OPEF چ3FQMJDB4FU ӬଓετϨʔδ ・アプリは、新しいReplicaSetに新バー ジョンのPodを作って、旧バージョンの Podを削除し、徐々に新旧⼊れ替える。 ,T
    XPSLFS
    OPEF ,T
    NBTUFS
    7 1PE ・Podのアップデート は無停⽌可能 ・基盤のアップデート はアプリの冗⻑化を前 提に無停⽌可能 ・ノードはPodを他のノードに移してVup したら、他のノードのPodを移してVupを 繰り返す 1PE 1PE ৽3FQMJDB4FU 1PE 1PE 1PE ,T
    NBTUFS
    7 1PE 1PE 1PE 1PE ,T
    NBTUFS
    7 ,T
    NBTUFS
    7 1PE 1PE 1PE 1PE アプリのアップデート ノードのアップデート Podのデータも消え るので、永続スト レージとの切断・ 接続を忘れずに。 ίϯςφج൫͸ɺW4QIFSF
    )"૬౰ͷϩδοΫͳͷͰɺແఀࢭͷ࣮ݱ͸ෳ਺ͷίϯςφʢ1PEʣͰۀ຿ΛΧόʔ͠߹͏લఏ
37. © 2024 IBM Corporation 37 補⾜：Kubernetesのもう⼀つのアップデート⼿法 – ブルーグリーンアップデート 「既存のコンテナにパッチを適⽤ or VerUPする」ではなく、パッチが適⽤された or 新バージョンのコンテナを作成し置き換え 新旧同時並⾏稼働させ、問題なければ新しい⽅にネットワーク経路を切り替える ΞϓϦέʔγϣϯͷೖΕସ͑ όʔδϣϯ͕ҟͳΔಉ͡΋ͷΛೋͭฒߦՔಇͤ͞ΔͷͰϦιʔεʹ༨༟͕ඞཁͱͳΔ コンテナA DB V10.1 DBPort = 3306:3306 コンテナB DB V10.2 DBPort = 3307:3306 3307 3306 3306 3306 db: ports: - “3306:3306” db: ports: - “3307:3306” ΫϥελͷೖΕସ͑ ,T
    XPSLFS
    W 1PE 1PE ,T
    XPSLFS
    7 1PE 1PE ロードバランサー 監視ソフト メモ：VMware vCenterのアップデート機能では ブルーグリーンアップデートを利⽤ https://blogs.vmware.com/vmware-japan/2023/06/vsphereplus_vcenter_update.html
38. © 2024 IBM Corporation 38 重要：仮想化基盤屋からみたコンテナアプリはクラウドネイティブであるべき理由 基盤側で出来る限界とアプリ側でやらなければならないことを理解して、どこまコンテナ移⾏するかを判断しよう Ծ૝Խج൫ӡ༻ऀʹҰ൪ཧղͯ͠΄͍͜͠ͱແఀࢭͷϨϕϧʢ࢓૊Έʣ͕·ͬͨ͘ҧ͏ ɾίϯςφج൫ʹҠߦͤ͞ΔΞϓϦέʔγϣϯ͸ɺW.PUJPOϨϕϧͷۀ຿ܧଓੑ·Ͱ͸ٻΊͳ͍࢓૊ΈͰ ಥൃతͳΠϯϑϥো֐͕ൃੜͯ͠΋໰୊͕ͳ͍ͱ൑அͰ͖Δۀ຿ͷΈʹߜΔ΂͠ ɾେ੾ͳγεςϜΛίϯςφج൫ʹҠߦͤ͞ΔͳΒɺΞϓϦέʔγϣϯΛΫϥ΢υωΠςΟϒʹ͢΂͠ 
    ΞϓϦ͕མͪͯ΋Өڹ͠ͳ͍ૄ݁߹
    
    ʢॲཧ͕ฦͬͯ͜ͳ͚Ε͹଴ͪଓ͚ͣʹɺ࠶౓ॲཧΛґཔ͠ͳ͓͢Α͏ͳϓϩηεʹറΒΕͳ͍࡞Γʣ 
    ϚΠΫϩαʔϏεʢҰॠͰॲཧΛऴΘΒͤΔγϯϓϧͳॲཧʹࡉ෼Խʣ ɾΫϥ΢υωΠςΟϒԽ͞ΕͨΞϓϦ͔ͩΒɺίϯςφج൫ͷӡ༻͕҆ఆԽ͢Δ コンテナはプロセス ϗετ̨̤ ʢΧʔωϧʣ Ϣʔβۭ̖ؒ ίϯςφ Ϣʔβʔϓϩηε ίϯςφϥϯλΠϜ コンテナ基盤（Kubernetes）にはプロセスのメモリ データを他のコンテナに引き継いで処理を継続する vMotionレベルの機能は提供されない。引き継がれる のは永続ストーレージに保存されたデータまで。 1PE
    " ロードバランサー 1PE
    "` 処理の継続は処理可能な 別のPodに処理を渡す OpenShift VirtualizationのVMはLive Migration出来 るが、管理されるPodはLive Migration出来ないので、 Kubernetesノードのメンテ時はVirtualization管理と コンテナ管理の⼿順を整理しておくことを忘れずに
39. © 2024 IBM Corporation 39 ベーシックなインフラ運⽤監視構成の違い 運⽤監視を意識した基本的な構成要素の違いを把握する 7.XBSF
    &49J 7. Ծ૝Խج൫ .BTUFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ ίϯςφج൫ ετϨʔδ ,VCFSOFUFTͷ؂ࢹ͸ϚχϑΣετʢ͋Δ΂͖࢟ʣ΍ϚΠΫϩαʔϏεɺଟ͘ͷϩάͳͲ ߟྀ͢΂͖΋ͷ͕૿͑ͯɺैདྷͷ؂ࢹιϑτ΢ΣΞ͚ͩͰ͸ରԠͰ͖ͳ͘ͳΔ 管理者 .BTUFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ 8PSLFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ .BTUFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ 8PSLFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ 8PSLFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ ετϨʔδ 7. 7. W$FOUFS
    4FSWFS Ծ૝Խج൫ͷӡ༻؂ࢹ "SJB
    0QFSBUJPOT ߴ౓ͳϦιʔεӡ༻؅ཧ HV/VM 管理 キャパシティ、性能監視 )8ϕϯμʔ5PPM ෦඼ނোɺԹ౓ɺ#*04'JSN HW監視、ストレージ管理 統合監視App (REST API) ELK, JP1等 管理者 OpenShift, ELK, Grafana, Loki, Prometheus + Operator等 コンテナ基盤 監視⽤Instana 0QFO4IJGU ,VCFSOFUFT コンテナ管理 キャパシティ 性能監視 HW監視、ストレージ管理 ベンダーToolのコンテナ版もある （NetApp Astra Control Center） ϚχϡϑΣετ
40. © 2024 IBM Corporation 40 コンテナ環境では、コンテナの多さや、マイクロサービスやAPI Callを多⽤したクラウドネイティブアプリケーションによる トラブルシュートの難しさから、APMと呼ばれるアプリ内のAPI Callに踏み込んだパフォーマンス監視ツールの導⼊を推奨する コラム：コンテナ環境で必要となるAPMという考え⽅ アプリケーションの呼び出し関係を可視化 分散トレースにより、サービスの呼出し順序も可視化 エラーや警告のログメッセージは⾃動で捕捉 IBM Instana Observability - kubernetesインフラの監視とアプリの監視の両⽅に対応
41. © 2024 IBM Corporation 41 ログの管理はどう変わる？ ・コンテナ内に取得されるログは、コンテナを終了させたりダウンすると、ログも消滅する ・必要なログはコンテナ外のSyslogサーバに集めておくような⼯夫が必須 7.XBSF
    &49J 7. 7. 7.XBSF
    &49J "11 W$F OUFS 04 Syslog, event-log, messages App-log, Java-log.. vm-support vc-support Ծ૝Խ؀ڥͷओͳϩά VMware vCenter Server 4.x, 5.x, 6.x および 7.0 の診断情報の収集 (1011641) VMware ESX/ESXi の診断情報の収集 (653) VMware 製品の診断情報の収集 (1010705) جຊతʹ͸ɺW4QIFSF
    8FC
    $MJFOUͷػೳͰγεςϜϩάΛΤΫεϙʔτ apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: ~ outputs: - name: rsyslog type: syslog syslog: facility: local0 rfc: RFC3164 payloadKey: message severity: informational url: 'tls://xxxxxx.com:514' ~ ϩΪϯάઃఆ BQQMZ ΞϓϦέʔγϣϯ ίϯςφ ΞϓϦέʔγϣϯ ίϯςφ ඪ४ɾΤϥʔग़ྗ TZTMPHసૹ TZTMPHαʔό $MVTUFS-PH'PSXBSEFSͷઃఆʹΑΓ ΞϓϦϩάΛTZTMPHసૹͰ͖Δ ログ管理 このほかにネットワークのログをSyslogに 送ったり、Podの標準出⼒なども集約する ϩά؅ཧͷ؍఺͔Β΋ɺίϯςφΞϓϦͷϩά͸ඪ४ग़ྗʹग़͢σβΠϯ͕ਪ঑ Ծ૝ϚγϯͰϩάͷग़ྗઌ͕ݻఆ͞Ε͍ͯΔΞϓϦ͔ΒͷίϯςφҠߦ͸ཁ஫ҙ˞ 必読：Kubernetesドキュメントのロギングのアーキテクチャ ※参考 サイドカーコンテナという仕組みを使ってアプリの ログを標準出⼒に⾶ばすことが可能。
42. © 2024 IBM Corporation 42 インフラの払い出し（Deployment）はどう変わる？ プライベートクラウドで仮想マシンを提供していたサービスが、コンテナ環境になるとどこまで⾯倒を⾒る必要があるのか？ 7.XBSF
    &49J Ծ૝Ϛγϯ̖ ήετ̨̤ Ծ૝Խ؀ڥ͸ӡ༻ऀ͕7.Λ࡞੒͢ΔϊʔυΛܾΊͯ࡞੒ ετϨʔδ ίϯςφ؀ڥ͸ඞཁͳ࣌ʹར༻ऀ͕͙͢ʹίϯςφΛ࡞ΕΔ؀ڥ͕Ұൠతɻ *5ӡ༻ऀ͸ͦͷͨΊͷج൫ͷ؅ཧʹूதͰ͖ΔΑ͏ʹͳΔ ෷͍ग़͠࡞ۀ W$16 (#
    .FN 5#
    %*4, (C
    /*$ʷ 3)&-
     ͷ7.ΛԼ͍͞ IT運⽤者 利⽤者 依頼 ESX #3とBLVol2に リソースがあるから、 そこに作成しよう。 vSphere Clientから 作成して払い出し ίϯςφ؀ڥ͸͢΂ͯࣗಈԽ ඞཁͳίϯςφΛ :".-ʹॻ͍ͯ #VJME
    
    3VO͢Δͱɺ ഑ஔ΋ϊʔυ΋ ࣗಈͰॲཧ͞ΕΔ 利⽤者 .BTUFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ .BTUFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ 8PSLFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ .BTUFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ 8PSLFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ 8PSLFS
    OPEF ϗετ̨̤ ʢΧʔωϧʣ ετϨʔδ IT運⽤者 ࣄલʹར༻෦໳ʹ 8PSLFS
    OPEFΛ 1SPKFDUͱͯ͠੾Γ ग़͠ΞΫηεݖΛ෇ ༩しておく
43. © 2024 IBM Corporation 43 運⽤に必要なものも揃っているコンテナ基盤 IBM Storage Fusion HCI https://www.ibm.com/jp-ja/products/storage-fusion
44. 最後に 仮想化基盤とコンテナ基盤の差異 この講座で伝えたいメッセージ 画像：いらすとや
45. © 2024 IBM Corporation 45 皆さんへの メッセージ 1.仮想化環境とコンテナは切り離して考える 仮想化環境とコンテナ環境は、デザインや特性の違いから、 既存環境の延⻑上のコンテナ化という発想は捨てて、別物として扱う。 2.仮想マシンからコンテナへの単純移⾏という幻想は捨てる コンテナ基盤の運⽤の仕組みを理解した上で、コンテナに移⾏するなら （アプリ・運⽤共に）クラウドネイティブ設計にする 3.VMwareからの脱却⽬的でコンテナを考えている⽅は コンテナ環境で仮想マシンを稼働させて管理する 「RedHat OpenShift Virtualization」を検討ください ただし、コンテナ基盤の中での仮想マシン運⽤となることを理解して、 クラウドネイティブ化も並⾏して進めるようにデザインしてください 4.コンテナ基盤のインフラに迷ったら、IBM Fusion HCIを検討ください。 コンテナ基盤の運⽤に必要な⼀式がまるっと揃います
46. © 2024 IBM Corporation 46 宣伝：IBM Storage Fusion HCI オンプレミスでのコンテナ運⽤に必要なOpenShift環境をまるっとアプライアンス化したハイパーコンバージドインフラです VMwareベースの仮想マシンをコンバーターでRedHat KVMベースの仮想マシンに変換し、OpenShift環境で稼働できるインフラです。 ⽣成AIのWorkloadに対応するGPUを搭載することもできます。 ίϯςφ 0QFO4IJGU $POUBJOFS όοΫΞοϓ ϦετΞ αʔϏε ετϨʔδ ϑΝΠϧγεςϜ αʔϏε ౷߹ӡ༻؅ཧ μογϡϘʔυ αʔϏε σʔλ࿈ܞ Χλϩά αʔϏε˞ Ծ૝Ϛγϯ 0QFO4IJGU 7JSUVBMJ[BUJPO 0QFO4IJGU
    $POUBJOFS
    1MBUGPSN ετϨʔδ /7.F
    'MBTI
    
    
    
    
    
    
    αʔόʔ $16
    (16˞
    
    
    
    
    
    
    ωοτϫʔΫ (C& ίϯςφج൫ ソフトウェア 概要 Red Hat OpenShift コンテナプラットフォーム Storage Scale Erasure Code Edition コンテナネイティブ 分散ファイルシステム（ストレージ） Backup & Restore サービス コンテナ環境向けバックアップ Appliance Management アプライアンス管理 Red Hat Advanced Cluster Management（オプション） OpenShift クラスター管理 ハードウェア 数量 42Uラック 1 Compute/Storage サーバー 6 7.68 TB フラッシュ・ドライブ 12 (2 x 6 サーバー) 100GbE Switch (内部通信) 2 Ethernet Switch (管理) 2 ハードウェア最⼩構成（ラック内で20nodeまで拡張化） ソフトウェア・コンポーネント
47. © 2024 IBM Corporation 47 アンケートの お願い Slidoへの 参加⽅法 WebExまたは以下のいずれかの⽅法でブラウザ・スマホなどから 回答をお願いいたします。 23ίʔυಡΈऔΓ Լه63-΁ΞΫηε͠ IUUQTBQQTMJEP Πϕϯτίʔυ EPKPQN Λೖྗ もしくはこちら https://app.sli.do/event/qLR8CcjeSSyqekT5zWbgj1 今回盛りだくさんのため、質問があればアンケートに記載ください。 connpassで可能なものは回答予定です。
49. ߨԋ͔࣌Βͷࢿྉมߋ • εϥΠυ /*$νʔϛϯάͷͱ͜Ζɻ 0QFO4IJGU
    7JSUVBMJ[BUJPOͰ΋ϘϯσΟϯάग़དྷΔͨΊՄʹ͠·ͨ͠ɻ
50. ࣭໰ɾճ౴ • ΞϓϦΛίϯςφʹҠߦ͢Δࡍɺ ΧʔωϧΛڞ༗͢ΔͨΊʹɺϑΝΠϧഁյ͕ى͜ΔՄೳੑ͕͋Δ
    ͱ͍͏͓࿩Ͱ͕ͨ͠ɺ۩ମతʹ͸ͲͷΑ͏ͳಈ͖Λ͢Δίϯϙʔ ωϯτ͕ةݥʢؾΛ͚ͭͶ͹ͳΒͳ͍΋ͷʣͰ͠ΐ͏͔ʁ ΠϝʔδΛ๲Β·͍ͤͨͷͰɺྫ͑͹ͲΜͳ΋ͷ͕͋Δ͔ɺՄೳͳൣғͰ͝ڭ͍͚ࣔͨͩ·͢ͱ͋Γ͕͍ͨ Ͱ͢ɻ ճ౴ɿ આ໌͕఻ΘΒͣਃ͠༁͋Γ·ͤΜɻ ϑΝΠϧഁյ͸Χʔωϧڞ༗ͷઆ໌ͷͱ͜ΖͰ͸ͳ͘ɺ7.XBSFͷڞ༗ετϨʔδͷॻ͖ࠐΈഉଞ੍ޚͷͱ͜ΖͰ͓఻͑ͨ͠಺༰Ͱ͢ɻ7.XBSFͰ͸ෳ਺ͷ&49J͔Βڞ ༗ετϨʔδ΁ͷॻ͖ࠐΈΛ-PDLػߏΛ༻੍͍ͯޚ͢ΔػೳΛ࣮૷΋͘͠͸ετϨʔδϕϯμʔͷ7""*
    1MVH*OͰ࣮૷ͯ͠ϑΝΠϧഁյΛ๷͍Ͱ͍·͢ɻͭ·ΓΠϯϑϥ ଆͰ੍ޚ͢ΔखஈΛఏڙ͍ͯ͠Δͷʹର͠ɺίϯςφͰ͸0QFO4IJGUపఈೖ໳ʹهࡌ͞Ε͍ͯΔΑ͏ʹɺΦʔέετϨʔγϣϯπʔϧଆͰ͸ഉଞ੍ޚػೳ͕ఏڙ͞Εͣɺ ͦ͜͸ΞϓϦଆͰ࣮૷͢Δ͔ɺετϨʔδଆͰ࣮૷͢Δඞཁ͕͋Γ·͢ɻઆ໌ͷதͰ΋ίϯςφʢ,VCFSOFUFTʣ؀ڥ͸ɺίϯςφऴྃͱͱ΋ʹσʔλ͕ফ͑ΔΠϛϡʔ λϒϧʢͭ·Γίϯςφ͸σʔλΛ࣋ͨͳ͍4UBUFMFTTʣͳσβΠϯ͕ϕʔεͰ͢ɻ͜ͷͨΊɺಛʹΫϥ΢υωΠςΟϒͳ࡞ΓͰ͸ͳ͍ɺԾ૝Խج൫ͷ7.ΞϓϦέʔγϣ ϯ͸σʔλΛอ࣋͢Δඞཁ͕͋Δ4UBUFGVMͳέʔε͕ଟ͍ͱࢥΘΕ·͢ɻ·ͣ͸ɺσʔλΛ࡞੒ɾߋ৽ɾ࡟আ͢Δॲཧ͕࣮૷͞ΕͨΞϓϦέʔγϣϯ͸ཁ஫ҙͰ͢ɻ ߨٛͰ͸৮Ε·ͤΜͰ͕ͨ͠ɺ͜ͷΑ͏ͳΞϓϦέʔγϣϯΛίϯςφԽ͢Δ৔߹͸ɺ4UBUFGVMͰ͋Δ͜ͱΛ໌ࣔ͢Δඞཁ͕͋Γɺ4UBUFGVM4FUΛఆٛ͢Δඞཁ͕͋Γ·͢ɻ 4UBUFGVM4FUͷ໾ׂʹ͍ͭͯ͸,VCFSOFUFTͷϚχϡΞϧΛࢀর͍ͩ͘͞ɻ IUUQTLVCFSOFUFTJPKBEPDTDPODFQUTXPSLMPBETDPOUSPMMFSTTUBUFGVMTFU ͞Βʹಛʹίϯςφ͸ෳ਺ͷίϯςφͰॲཧΛ৑௕Խͯ͠ॲཧͷܧଓੑʢՄ༻ੑʣΛ֬อ͢ΔσβΠϯ͕ଟ͍ͷͰɺӬଓετϨʔδʹରͯ͠σʔλΛอଘ͢Δඞཁ͕͋Δ ΞϓϦέʔγϣϯͷ৔߹ɺಉ͡ϑΝΠϧʹରͯ͠ॻ͖ࠐΈΛ࣮ࢪ͢ΔՄೳੑ͕ߴ͘ͳΔ͔΋͠Ε·ͤΜɻ σʔλͷॻ͖ࠐΈॲཧ͕࣮૷͞Ε͍ͯͯ΋ɺԾ૝Խج൫Ͱ͸γϯάϧߏ੒ͰॲཧΛ͢ΔͷͰॻ͖ࠐΈ੍ޚΛ࣮૷͢Δඞཁ͕ͳ͔͕ͬͨɺίϯςφͰ͸W.PUJPO͕ͳ͘ͳΔ ͷͰɺϊʔυϝϯςφϯεதͰ΋ॲཧΛܧଓ͢ΔͨΊʹɺಉ͡ΞϓϦΛ̎ͭҎ্Քಇͤͯ͞ॲཧΛฒߦ࣮ߦͤ͞ΔܗͰՄ༻ੑΛ֬อ͢ΔΑ͏ͳΞϓϦέʔγϣϯߏ੒Λऔ ΔέʔεͰ͸ɺॻ͖ࠐΈͷ੍ޚΛΞϓϦଆͰ࣮૷͢Δඞཁ͕͋Δͱߟ͍͑ͯ·͢ɻ
51. ࣭໰ɾճ౴ • ֤ϋʔυ΢ΣΞϕϯμʔ͕ϑΝΠϧ؀ڥͷ෼཭ʹରԠ͍ͯ͠Δ͔֬ೝ͢΂͠ɺͱͷ͓࿩Ͱ͕ͨ͠ɺྫ͑͹*#.੡඼ʹ͓͍ͯ͸ɺͲͷ͋ͨΓͷυΩϡϝϯτΛݟΕ͹ྑ ͍Ͱ͠ΐ͏͔ʁ ճ౴ɿ ӬଓϘϦϡʔϜ΁ͷॻ͖ࠐΈഉଞ੍ޚͰྖҬഁյΛ๷͙࢓૊ΈʹରԠ͍ͯ͠Δ͔ʹ͍ͭͯ͸ɺ·ͣίϯςφج൫ରԠετϨʔδΛఏڙ͍ͯ͠Δ͔Λ8FCͰ֬ೝ͠ɺରԠ Ͱ͋Ε͹ετϨʔδϕϯμʔ͕ఏڙ͍ͯ͠Δ$4*υϥΠόʔͷػೳ࢓༷΍੡඼ϚχϡΞϧΛ֬ೝ͢Δͱྑ͍ͱࢥ͍·͢ɻهࡌ͕ͳ͍৔߹͸ɺϕϯμʔʹ໰͍߹ΘͤͯΈͯ ͍ͩ͘͞ɻ *#.ͷ৔߹͸ɺͪ͜Βʹ$4*υϥΠόʔͷϚχϡΞϧ͕͋Γ·͢ɻ IUUQTXXXJCNDPNEPDTKBTUHCMPDLDTJESJWFS /FU"QQ
    "TUSB
    5SJEFOUͷυΩϡϝϯτʹ͸ҎԼͷΑ͏ͳ੍ݶ͕هࡌ͞Ε͍ͯ·͢ɻಋೖΛݕ౼͞Ε͍ͯΔ֤ࣾͷετϨʔδϚχϡΞϧΛಡ·ΕΔͷ΋ྑ͍ͱࢥ͍·͢ɻ IUUQTEPDTOFUBQQDPNKBKQUSJEFOUUSJEFOUVTFWPMVNFTIBSFIUNM&#%#'&"USJEFOUDUMHFU &##&#%%&"&&$&""&"&#$&"&&"&#$"& &#