Exadata X8M-2 KVM仮想化ベストプラクティス

Transcript

1. Exadata X8M-2 KVM 仮想化ベストプラクティス KVM Virtualization Best Practices for RoCE/PMEM-Based Systems 2020/10/12 https://www.oracle.com/a/tech/docs/exadat a-kvm-overview.pdf
2. Safe harbor statement 以下の事項は、弊社の⼀般的な製品の⽅向性に関する概要を説明するものです。また、 情報提供を唯⼀の⽬的とするものであり、いかなる契約にも組み込むことはできません。以 下の事項は、マテリアルやコード、機能を提供することを確約するものではないため、購買 決定を⾏う際の判断材料になさらないで下さい。 オラクル製品に関して記載されている機能の開発、リリース、時期及び価格については、弊 社の裁量により決定され、変更される可能性があります。 Copyright © 2020, Oracle and/or its affiliates 2
3. Exadata X8M-2 KVM 仮想化ベストプラクティス https://www.oracle.com/a/tech/docs/exadata- kvm-overview.pdf
4. • ユースケース • Exadata 仮想化ソフトウェア要件 • Exadata 分離の考慮点 • Exadata KVM サイジングと前提条件 • Exadata KVM デプロイメント概要 • Exadata KVM 管理とオペレーションライフサイクル • 移⾏, HA, バックアップ・リストア, アップグレード、パッチ適⽤ • 監視、リソース管理 • KVMドメインの管理 • コマンドオプション⼀覧 • Appendix: KVM のネットワークについて アジェンダ 4 Copyright © 2020, Oracle and/or its affiliates
5. KVM を利⽤した⾼性能な仮想化データベースプラットフォーム • KVM hypervisor • Linux カーネル上で稼働する性能が改善された Type2 ハイパーバイザー（ホストOS 上で稼働するタイプのハイパーバイザー。Xen はハードウエア上でハイパーバイザーが直 接動く Type1 ハイパーバイザー） • VM はワークロードの統合のために CPU, memory, OS, and sysadmin の 分離 を提供 • Hosting, cloud, cross department consolidation, test/dev, non- database or third party applications • Exadata VM は物理ハードウエアに近いパフォーマンスを提供 • データベースのI/Oはハイパーバイザーをバイパスして⾼速なRDMAネットワークへアクセ ス • Exadata の I/O リソース制御と組み合わせることでフルスタックの 分離レベルを可能に • VM によるトラステッド・パーティション上で別々にDBオプションや他ソ フトウェアのライセンス可能 Exadata 仮想化 5 X8M-2 DB 11.2.0.4 以降 GI 12.1.0.2 以降 FINANCE SUPPLY CHAIN SALES Exadata 19.3 以降 Copyright © 2020, Oracle and/or its affiliates
6. • VM は独⽴性は優れているが、効率や管理性は乏しい • VMは独⽴したOS,メモリ、CPU があり、それぞれ個別にパッチ適 ⽤する • 信頼できるデータベース管理者、システム管理者なしに分離可 能 • ⼀つのOS上でのデータベース統合は効率がいいが分離 性に乏しい • データベース Resource Manager 機能はオーバーヘッド無し • リソースは動的に共有可能 • 信頼できる管理者が正しく設定する必要がある • VM と DB統合を組み合わせるのが最適な⽅法 • VM中で複数の信頼できるDBないしはプラガブルデータベースを ⽤いた DB統合 • サーバー毎に少ないVM数に制限することにより、リソース（CPU、 メモリ、パッチ）を分断した際に発⽣するオーバーヘッドを削減 Exadata 上での統合の選択肢（ユースケース） 6 VM マルチテナントデー タベースの場合 1つのサーバー上に 複数 DBを置く場 合 Virtual Machineの場合 DBごとに専⽤ サーバーを置く場 合 VM VM 分離性 効率 Copyright © 2020, Oracle and/or its affiliates
7. Database Server: ベアメタル / 物理環境と仮想環境 ソフトウェアアーキテクチャの⽐較 7 Database Server: 仮想環境 KVM Host Exadata (Linux w/ KVM, fw) KVM Guest-n Exadata (Linux) Oracle GI/DB homes KVM Guest-2 Exadata (Linux) Oracle GI/DB homes KVM Guest-1 Exadata (Linux) Oracle GI/DB homes Database Server: ベアメタル / 物理環境 Exadata (Linux, fw) Oracle GI/DB homes Storage Grid, Networking,他については同様 - vs - Copyright © 2020, Oracle and/or its affiliates
8. ベアメタル / 物理環境と仮想環境の違い 8 Topic 仮想環境のベアメタル / 物理環境からの違い ハードウエア対応 2-socket モデルのみ対応 VM クラスター構成 1ないしはそれ以上のVMクラスターを所有、それぞれのVMクラスターでそれぞれの GI/DB をインスト ール Exadata ストレージ構成 それぞれの VM クラスター毎に grid disks / DATA disk group / RECO disk group が分離 DB サーバーディスク構成 標準のファイルシステムサイズは⼩さくなる。GI/DB はそれぞれ分かれたファイルシステムになる ソフトウェアアップデート DB サーバーは KVM Host (Linux + fw), KVM Guest それぞれに patchmgr でのアップデー トが必要 EXAchk KVM Host / Storage Serversで1回の実⾏が必要, それぞれの VM クラスター（KVM Guest) 毎に1回の実⾏が必要 Enterprise Manager EM + Oracle Virtual Infrastructure plug-in + Exadata plug-in Copyright © 2020, Oracle and/or its affiliates
9. • ハードウエア • RoCE インターコネクトを備えた2-socket systems (e.g. X8M-2) • ソフトウエア (MOS 888828.1 を確認) • Exadata 19.3.0 以降（Exadata X8M ⾃体 Exadata 20.1.0 以降推奨） • Oracle Linux Kernel-based Virtual Machine (KVM) を⽤いた仮想化 • KVM Host と Guests は異なるバージョンで稼働可能 • Grid Infrastructure • 推奨 - GI 19, 最新の RU • 対応 - GI 12.1.0.2 以降のリリース, 2019-July RU 以降と必要なパッチ • Database • 推奨 - DB 19, 最新の RU • 対応 - DB 19, 18, 12.2.0.1, 12.1.0.2, or 11.2.0.4 –MOS 888828.1 で要件を確認 Exadata KVM 要件 9 Copyright © 2020, Oracle and/or its affiliates
10. • KVM/RoCE と Xen/InfiniBand の相互運⽤性 • KVM は RoCE インターコネクトのシステムのみでサポート (例 X8M) • Xen は InfiniBand インターコネクトのシステムのみでサポート (例 X8, X7, 他.) • X8 以前のシステムで Exadata 19.3 にアップグレード、ないしはExadata 19.3 で新規にインストールされたシステム は継続して Xen が利⽤されます • RoCE システムと InfiniBand システム間のラック間接続は不可 • 分離された KVM/RoCE ベースのシステムと Xen/InfiniBand ベースのシステムはData Guard / Goldden Gate での統合は可能 • 例 KVMベースのシステムをプライマリーに、 Xen ベースのシステムをスタンバイで利⽤ • Xen から KVM への移⾏ • Data Guard, GoldenGate, RMAN, ZDM 等でデータベースを移⾏ Exadata KVM 要件 10 Copyright © 2020, Oracle and/or its affiliates
11. • それぞれの VM RAC クラスターはそれぞれの Exadata grid disks と ASM Disk Groupsを所持します • 4.4.4 Setting Up ASM-Scoped Security on Oracle Exadata Storage Servers • クライアントネットワーク、管理ネットワークの分離のために802.1Q VLAN Tagging を利⽤ • OEDA での初期セットアップ時に実施（スイッチ側の設定が事前に必要）に従って⼿動での後⽇設定 • Implementing Tagged VLAN Interfaces in KVM based Oracle VM Environments on Exadata (Doc ID 2710712.1) • プライベートネットワークの分離 • RoCEsスイッチポートの設定によるサーバー単位の分離 （Exadata 19.3まで） • 同⼀サーバー内の複数のVMは同じVLANを共有 • Secure Fabric を⽤いた VM 単位の分離（Exadata 20.1 移⾏） • ExaCLI を⽤いた Storage Server 管理の分離 セキュリティ分離の推奨 11 Copyright © 2020, Oracle and/or its affiliates
12. • Reference Architecture Sizing Tool を⽤いて各データベースのピーク時の CPU, memory, disk space の必要量を算出 • サイジングはデプロイメントの前に実施して、実施結果に応じてOEDAを設定 • 考慮点 • KVM Host reserved memory • KVM Host reserved CPU • KVM Guest の⻑期的なローカルファイルシステムの増加を考慮 • ⻑期間稼働する KVM Guest はすべてのディスクスペースをアロケートすることを考慮して予算化する（sparseness や、 shareable reflinks は効果が無い） • それぞれのVMクラスターはそれぞれの grid disks と disk groupsを所持する • Sizing tool は現時点では仮想化システムを考慮していません Exadata KVM サイジングの推奨 12 Copyright © 2020, Oracle and/or its affiliates
13. • メモリはオーバープロビジョニング不可 • すべての KVM Guests メモリ + KVM Host reserved memory の合計 <= 物理搭載メモリ • KVM Host reserves memory = 24GB + (総物理メモリの 6%) • この領域は KVM Guest のメモリには利⽤できません • KVM Guest メモリーサイジング • すべての KVM Guest のメモリの合計 <= 1,390 GB (DBサーバーで最⼤メモリオプション の場合） • KVM Guest あたり最⼩ 16 GB (OS, GI/ASM, 初期DB, 少ない接続数をサポート するために必要) • ⼀つの KVM Guest で利⽤の場合、最⼤ 1,390 GB • Exadata のメモリサイズはオンラインでの変更不可（KVM Guest の再起動が必要） メモリー サイジング推奨 13 Copyright © 2020, Oracle and/or its affiliates
14. • CPU はオーバープロビジョニング可能 • しかしながら、もしもすべての Guest が完全にアクティブな場合、ワークロードパフォーマンスのコンフリクトが発⽣ する場合がある • 1 vCPU == 1 hyper-thread; 1 core == 2 hyper-threads == 2 vCPUs • KVM Host は 2 cores (4 vCPUs)を予約利⽤ • KVM Guest は 2 コア分利⽤不可能 • KVM Guest CPU サイジング • KVM Guest あたりの最⼩ CPU = 2 cores (4 vCPUs) • KVM Guest あたりの最⼤ CPU = システム上の全 core数 - 2 (KVM Host 予約利⽤分) • 例: X8M-2 48 cores (96 vCPUs) Guest で最⼤利⽤可能 core 数 46 cores (92 vCPUs) • VM あたりの cores/vCPUs はオンラインで変更可能 • The number of vCPUs must be a multiple of 2.（2の倍数で指定） CPU サイジング推奨 14 Copyright © 2020, Oracle and/or its affiliates
15. • KVM Guest のローカルファイルシステムのオーバープロビジョニングは推奨されていませんが可能です • 初期にアロケートされた実際のスペースは sparseness や shareable reflinks のため、⾒かけよりもちいさくなっ ています、しかしながら、時が経つにつれ、shared space は分岐して、少ないスペースになっていきます • ⻑期間稼働する KVM Guest はすべてのディスクスペースをアロケートすることを考慮して予算化する （sparseness や、shareable reflinks は効果が無い） • オーバープロビジョニングは予期しない領域不⾜のエラーを発⽣する場合があります • オーバープロビジョニングはディスクイメージバックアップのリストアを阻害する場合があります ローカルディスク サイジング推奨 15 Copyright © 2020, Oracle and/or its affiliates
16. • X8M-2 database server – ローカルディスク 4 x 1.2 TB RAID5 構成 • VM⽤のローカルディスクスペース デフォルト 1.46 TB, 最⼤（オンライン拡張可能） 3.15 TB • (Database Server Storage Expansion Kit for X8Mが新規販売されたので、最⼤容量が変わる可能性があります） • KVM Guest あたりデフォルト 141 GB 利⽤ • KVM Guest のローカルスペースは初期セットアップ後にローカルディスクイメージを追加することで拡張可能（例︔KVM Host のファイルシステムに存在するファイルで、KVM Guest からはローカルディスクイメージで⾒える） • ユーザーファイルについては共有ストレージを⽤意することにより拡張可能 (e.g. ACFS, DBFS, 外部 NFS, OCI File Storage) • Oracle/Linux binaries/configuration/diagnostic filesとして共有ストレージを利⽤することは不可. ファイルアクセス、ネットワーク不具合によりシステムがクラッシュ、ハングする場合あり ローカルディスク サイジング推奨 16 Copyright © 2020, Oracle and/or its affiliates
17. • それぞれのクラスターのために diskgroupは すべての Storage Server にまたがって構成する • それぞれの VM クラスターはそれぞれの grid disks を保持します • 最初の VM クラスターの Disk group サイズは将来的な VM 追加を考慮してサイジングする • 初期セットアップですべての領域を使ってしまっている場合、新しいクラスター追加時は既存の diskgroup を shrink する作業が必要になります。 • grid disk へのアクセス制限には ASM-Scoped Security を利⽤する Exadata Storage 推奨 17 VM Cluster Cluster nodes Grid disks (DATA/RECO すべての Storage Server 上のすべてのディスクのす べてのクラスター⽤） clu1 db01vm01 db02vm01 DATAC1_CD_{00..11}_cel01 RECOC1_CD_{00..11}_cel01 DATAC1_CD_{00..11}_cel02 RECOC1_CD_{00..11}_cel02 DATAC1_CD_{00..11}_cel03 RECOC1_CD_{00..11}_cel03 clu2 db01vm02 db02vm02 DATAC2_CD_{00..11}_cel01 RECOC2_CD_{00..11}_cel01 DATAC2_CD_{00..11}_cel02 RECOC2_CD_{00..11}_cel02 DATAC2_CD_{00..11}_cel03 RECOC2_CD_{00..11}_cel03 Copyright © 2020, Oracle and/or its affiliates
18. デプロイ時のスペックと制限 18 *1 core = 1 OCPU = 2 hyper-threads = 2 vCPUs カテゴリ X8M-2 VMs データベースサーバーあたり最⼤VM数 12（下記以外） 384GB メモリのシステム、かつ、 Secure Fabric で構成された場合 8 Memory ノードあたりの物理メモリ（標準/最⼤） 384 GB / 1.5 TB KVM Guest ごとの最⼩メモリ 16 GB KVM Guest ごとの最⼤メモリ 1,390 GB CPU/vCPU ノードあたりのコア数 48/96 VMあたり最⼩コア数 2/4 VMあたり最⼤コア数 46/92 Disk 全 KVM Guest で使える物理ノードあたりの総ディスク利⽤可能領域 3.15 TB デプロイ時に KVM Guest 毎に利⽤できるディスク領域（OEDAテンプレートのデフォルト） 141 GB Copyright © 2020, Oracle and/or its affiliates
19. VMs on Exadata の構成は OEDA でのみ実施されます 1. OEDA で構成を作成する 2. OEDA でのデプロイメントのためにお客様環境を準備する • DNS の準備、必要に応じてスイッチへ VLAN 設定 3. EXADATA に OEDA の準備をする • switch_to_ovm.sh; reclaimdisks.sh; (KVMでは不要）、applyElasticConfig.sh 4. OEDAでデプロイする デプロイメント概要 19 Copyright © 2020, Oracle and/or its affiliates
20. 仮想化、ないしはベアメタルの選択 • KVMを選択 • All Linux VM • All Linux Physical • Custom (some VM, some Physical) • データベースサーバーはKVM ないしはベアメタルで構成され ます OEDA 構成ツール 20 Copyright © 2020, Oracle and/or its affiliates
21. Define Clusters • 決めること 1. 作成するVM数 2. VM クラスターを作成する DB nodes, Storage Server • 推奨はクラスター毎に全 Storage Server を利⽤ • “VM cluster?” とは︖ • Oracle GI / RACを実⾏し、 それぞれが同 じ共有 Exadata ストレージ （ ASM が管 理）にアクセスする、 異なるデータベース・ サーバー上に ある 1つ以上のユーザー・ドメ イン OEDA 構成ツール 21 Copyright © 2020, Oracle and/or its affiliates
22. Cluster Configuration • それぞれのVMクラスターはそれぞれの下記構成情報を必要とします • OS User Name と OS Group Name • Clusters • Grid Infrastructure バージョンと、GI Home のパス名 • Exadata System Software バージョン (Guest Image Version） • VM size (CPU Cores (vCPU) , Memory(GB) ) • ASM Disk Groups （構成する storage grid disks) • Database バージョンと Oracle Home のパス名 • 初期データベース構成 • Client, Backup, Admin のネットワーク構成 OEDA 構成ツール 22 Copyright © 2020, Oracle and/or its affiliates
23. Advanced Network Configuration • Admin ネットワークと Client ネットワークは 802.1Q VLAN Taggingが利⽤可能 • VM間の Admin ネットワーク と Client ネットワークを分離 するために、⼀意の VLAN ID と IP アドレスをクラスター 毎に設定 • AdminネットワークとClient ネットワークスイッチはOEDA の設定の前にVLAN tag の 設定が必要 OEDA 構成ツール 23 Copyright © 2020, Oracle and/or its affiliates
24. Installation Template • Installation Template 上のすべて の VM クラスターの設定が正しいかを 確認 (DNS, スイッチ, VLANs, etc.). OEDA 構成ツール 24 Copyright © 2020, Oracle and/or its affiliates
25. ネットワーク要件 OEDA 構成ツール 25 Component Domain Network ホスト名 例 Database servers KVM Host (DBサーバーあたり一つ） Mgmt eth0 dm01dbadm01 Mgmt ILOM dm01dbadm01-ilom KVM Guest (DBサーバー毎に一つ以上) Mgmt eth0（オプション） dm01dbadm01vm01 Client bondeth0 dm01client01vm01 Client VIP dm01client01vm01-vip Client SCAN dm01vm01-scan Private RoCE dm01dbadm01vm01-priv Storage servers (物理環境と同じ) Mgmt eth0 dm01celadm01 Mgmt ILOM dm01celadm01-ilom Private RoCE dm01celadm01-priv Switches (物理環境と同じ) Mgmt and Private dm01sw-adm, dm01sw-roce Copyright © 2020, Oracle and/or its affiliates
26. • 主要なメンテナンスツール • vm_maker コマンド • virsh コマンドは使わない • OEDACLI - OEDA Command Line Interface • 参照 Exadata Database Machine Maintenance Guide • Chapter 6 – “Managing Oracle VM Domains Using KVM” Exadata KVM 基本管理作業 26 Copyright © 2020, Oracle and/or its affiliates
27. • ベアメタルから仮想化環境への動的、ないしはオンラインの移⾏⼿段 • Data Guard ないしはバックアップによるデータベースの移動 ー最⼩のダウンタイム • 1ノード、ないしはノードのサブセットの仮想化環境へのコンバート • 既存のベアメタル環境から仮想化環境への移⾏のために必要なこと • 既存のデータベースのバックアップ取得、既存のハードウエアをOEDAで仮想化環境に再セットアップ、データベー スのリストア • 既存 Exadata KVM 環境へのデータベースの複製 • 移⾏元から移⾏先への移動の場合、標準的な Exadata の移⾏プラクティスが適⽤されます • 参考 Best Practices for Migrating to Exadata Database Machine Exadata KVM マイグレーション 27 Copyright © 2020, Oracle and/or its affiliates
28. • 動的に、ないしはオンラインのベアメタル環境から仮想化環境への移⾏には下記の⼿段が利⽤可能です • （まだ KVM に合わせた更新がされていません） • Migrate to OVM RAC cluster using the existing bare metal Oracle RAC cluster with zero downtime • Migrate to OVM RAC cluster by creating a new OVM RAC cluster with minimal downtime • Migrate to OVM RAC cluster using Oracle Data Guard with minimal downtime • Migrate to OVM RAC cluster using RMAN backup and restore with complete downtime • 必要要件、詳細な⼿順については下記NOTE参照 • Migration of a Bare metal RAC cluster to an OVM RAC cluster on Exadata (Doc ID 2099488.1) Exadata KVM マイグレーション 28 Copyright © 2020, Oracle and/or its affiliates
29. • KVM Host • 外部環境への標準的なバックアップ・リストア⼿順 • KVM Guest – 2つの⽅法 • KVM Host 内でのバックアップ: VM disk images のスナップショットと外部へのスナップショットバックアップ • KVM Guest 内でのバックアップ: 標準的な OS バックアップ・リストアプラクティスが適⽤ • ローカルディスクスペースへのオーバープロビジョニングが適⽤されている場合、VMバックアップのリストアによりスペー スの削減が減少する（排除する場合もある）（オーバープロビジョニングに依存することにより、完全なVMリスト アが阻害される場合がある) • Database バックアップ・リストア • 標準的な Exadata MAA プラクティス（RMAN, ZDLRA, CLoud storage) • 参照 Exadata Database Machine Maintenance Guide 仮想化環境でのバックアップ・リストア⼿順 29 Copyright © 2020, Oracle and/or its affiliates
30. Component to update Method Storage servers 物理環境と同じ。ssh アクセス可能ないずれかのサーバーからすべての Storage Server へ patchmgr コマンドで実施、 ないしは Storage Server Cloud Scale Software Update 機能の利⽤ RDMA Network Fabric switches 物理環境と同じ。ssh アクセス可能ないずれかのサーバーからすべてのスイッチへ patchmgr コマンドで実施 Database server – KVM Host sshアクセス可能ないずれかのサーバーからすべての KVM Host へ patchmgr コマンドで実施 KVM Host アップデートはデータベースサーバーのファームウエアも更新します KVM Host の再起動はすべてのローカルVM を再起動します KVM Guest のソフトウエアは KVM Host のアップデートの最中には更新されません。 KVM Host / Guest は同⼀バージョンの必要はありません。（特定のアップデートの順番が必要になる場合があります MOS 888828.1参照) Database server – KVM Guest ssh アクセス可能ないずれかのサーバーからすべての KVM Guest へ patchmgr コマンドで実施 ⼀般的には VM クラスター毎に実施します (例 全ノードの vm01 に適⽤,その後 vm02 を適⽤, など） ないしは次のノードに移る前に KVM Host上のすべての VM に対して適⽤実施します Grid Infrastructure / Database OEDACLI を⽤いて、標準的なアップグレード、パッチ適⽤⽅法が適⽤されます。VMクラスター毎に実施されます。 GI/DB homes は初期セットアップで⾏われたように disk image がマウントされているべきです ソフトウエアアップデート 30 Copyright © 2020, Oracle and/or its affiliates
31. • EXAchk は KVM Host と KVM Guest で実⾏されます • すべての KVM Hosts, Storage Servers, スイッチ に対して、⼀つの KVM Host から実⾏されます（ RoCE スイッチに対してのチェックは 2020/09現在未実装、実装待ち） • すべての KVM Guest、クラスターの GI/DB に対して、それぞれの VM Cluster の⼀つの KVM Guest で実 ⾏されますに • Exadata Storage Software Versions Supported by the Oracle Enterprise Manager Exadata Plug-in (MOS 1626579.1) • ExaWatcher は KVM Host と KVM Guest で稼働しています • Database/GI 監視プラクティス は同様に適⽤されます • 考慮点 • KVM Host は EM 、ないしカスタムエージェントを収容するサイジングになっていません • Oracle Linux Virtualization Manager は Exadata KVM をサポートしていません ヘルスチェックと監視 31 Copyright © 2020, Oracle and/or its affiliates
32. • Exadata MAA 障害・復旧プラクティスは同様に適⽤可能です。 • 参照 MAA Best Practices for Oracle Exadata Database Machine • Live Migration はサポートされていません。ノード間のワークロード移動には RAC を利⽤ Exadata MAA/HA 32 Copyright © 2020, Oracle and/or its affiliates
33. • Exadata のリソースマネージメントのプラクティスは同様に適⽤可能です • Exadata IORM/ Flash ストレージ・リソースへのアクセス優先度管理は同じように使⽤可能 • VM内、クラスター内のデータベース・リソース・マネージャー機能も同様に適⽤可能です • VM 内の cpu_count はデータベースのインスタンスレベルで設定する必要があります。 • 推奨最⼩値 cpu_count=2. • ローカルディスクのリソース管理、優先度管理機能はありません • I/O インテンシブなワークロードは、内蔵ディスクの使⽤を使うべきではない • ⾼い I/O 性能や帯域が必要な場合には、Exadata 上の ACFS,DBFS,ないしはNFS を使⽤する リソース管理 33 Copyright © 2020, Oracle and/or its affiliates
34. Exadata KVM / Xen ⽐較 34 Category KVM ベース Xen ベース ⽤語 KVM Host, KVM Guest dom0, domU 対応ハードウエア X8M-2 (RDMA Network Fabric switches利⽤) X2-2 〜 X8-2 (InfiniBand スイッチ利⽤) ハイパーバイザー KVM (UEKに含まれる) Xen VM 管理コマンド vm_maker, OEDACLI xm, OEDACLI, domu_maker Database Server ソフトウェアアップデート KVM Host と KVM Guest へ同じ ISO/yum repository を⽤いて patchmgr コマンドで適⽤ dom0 / domU で異なる ISO/yum repository を⽤い て patchmgr コマンドで適⽤ デプロイメント reclaimdisks.sh 不要 reclaimdisks.sh が⼿動のステップで必要 ファイルシステム構成 XFS ext4, /EXAVMIMAGES は OCFS Copyright © 2020, Oracle and/or its affiliates
35. Copyright © 2020, Oracle and/or its affiliates 35