サーバーを仮想化するということは、パッチを適用して更新するための別のOSレイヤー、より多くの作業、より大きなリスクを意味しますか？
検索を行いましたが、パッチ適用とシステムアップデートに関する問題に対処するものは見つかりませんでした。サーバーには必要なパッチが必要であるというガイドラインがあります。 VMホストがある場合、パッチを適用して更新するための追加のレイヤーはありますか？ベアメタルハイパーバイザーを使用している場合でも？メタルサーバーを使用しているのとは対照的ですか？（つまり、より多くの作業とテストおよびドキュメント私のガイドライン）。
タイプ1 /ベアメタルハイパーバイザーはどのくらいの頻度で更新されますか？それは重要ですか？それが追加のソフトウェアレイヤーであるという事実は、より複雑でリスク（セキュリティと信頼性）をもたらしますか？ （例：99％バグフリーソフトウェアx 99％バグフリーソフトウェア= 98％バグフリーシステム）？
（私の実際の経験は、VMWare WorkstationとServer、およびVirtualBoxを使用したものです。）
はい、VMwareのような製品にはパッチを適用する必要があります（ 更新は累積 ）が、パッチはメインラインのオペレーティングシステムよりも頻度が低く、潜在的な攻撃ですベクトルが小さい-ハイパーバイザーを公開してはいけません。
例として、VMware ESXiバージョン5.0（5.1ではない）を使用します...
ESXi 5.0には、次の更新スケジュールがあります。
2011年9月から現在までに、ESXi 5.0製品に[〜＃〜] ten [〜＃〜]の更新がありました。それらのうち、[〜＃〜] six [〜＃〜]は、セキュリティに焦点を当てた更新が、次のような説明とともに更新バンドルに組み込まれました。
"ESXi NFSトラフィック解析の脆弱性"CVE-2012-2448 。
これらのセキュリティの脆弱性は、一般的なLinuxのセキュリティバグを反映していることがあるため、現実のものですが、ほとんどの組織はリスクの影響をあまり受けないと思います。ただし、このリスクを評価するのはエンジニア次第です。ユーザーは、 次のエクスプロイト を修正するために大規模なダウンタイムを望んでいますか？
"GNU Cライブラリ（別名glibcまたはlibc6）2.11.1以前のmisc/mntent_r.cのencode_nameマクロは、ncpmountおよびmount.cifsで使用されているため、改行を適切に処理しません。マウントポイント名の文字。これにより、ローカルユーザーは、細工されたマウントリクエストを介して、サービス拒否（mtabの破損）を引き起こしたり、マウントオプションを変更して特権を取得したりできます。」
多分？そうでないかもしれない。
VMwareのUpdate Manager を実行していますが、バグの影響を受けた場合、または機能の拡張が必要な場合にのみ更新される傾向があります。クラスター化されたセットアップで実行する場合、パッチ適用は簡単で、実行中のVMへのダウンタイムはありません。他に差し迫った理由がない場合は、四半期ごとに更新するよう努めます。パッチはモノリシックイメージとして提供されるため、個々のホストは完全に再起動する必要があります。
ちなみに、VMware ESXiのセットアップを継承したり、通常は管理していないシステムで作業したりすると、 never のホストが実行されていることがよくあります。 = VMwareパッチが適用されていた。 それは間違っています!!しかし、システムが稼働すると、管理者がどのようにその間違いを犯す可能性があるかがわかります。
「ベアメタル」ホストを使用した仮想化に慣れていない場合、これはかなり良い質問です。このように行うには、従来のOS上でサービス/アプリケーションとして実行されるハイパーバイザーで採用するアプローチとは異なる考え方が必要です。
私の経験では、ESXとHyperVは、従来のオペレーティングシステムよりも全体的に少ないパッチを適用する必要があると言っても過言ではありません。これは、パッチを適用する必要がまったくないこと、または「必要性」に関係なく一部のパッチを適用しても効果がないことを意味しません 、ただし、これは、ホストにパッチを適用するためのサービスへの中断の頻度を減らし、管理下に置く必要があることを意味します。ハイパーバイザーOSには、他のOSと同様に潜在的なセキュリティリスクがあり、このリスクのエクスポージャーを最小限に抑えることができます（たとえば、ハイパーバイザー管理を分離されたVLAN that can '侵害されたサーバーから論理的に到達する）リスクがまったくないふりをするのは愚かなことです。
したがって、たとえば4つの非仮想サーバーがあり、それらをすべて同じ個別の仮想化ホストに移動すると、ホストシステムにパッチを適用する（または対処する）必要性によって引き起こされる可能性のある混乱の量が増加します。そのことについては、ハードウェアの問題など）。
このリスクが発生する可能性は比較的低いと思いますが（仮想ホストへのパッチ適用と一種のパッチ適用の違いについて話しています）スタンドアロンシステムとにかく）に対して行う必要がある再起動が必要なため、影響が大きいという事実から逃れることはできません。
では、なぜそれを行うのですか？
仮想化の真の利点は、複数のホストをセットアップし、ホストが連携するように構成できることです。これにより、1つのホストに障害が発生した場合、またはパッチをスケジュールしたい場合に、ゲストを1つのホストから別のホストに移動できます。ホストシステム。
このアプローチを使用して、5つのESXホストに順番にパッチを適用し、その上で実行されている40の仮想サーバーにまったく中断することなくパッチを適用しました。これは単に規模の経済の問題です-この種の複雑なセットアップを構築し、@ ewwhiteが彼の回答で言及している種類のツールを使用して管理する価値がある十分な潜在的な仮想ゲストマシンがあれば、リスクを軽減することでの見返りあなたが心配しているのは非常に早く到着します。
仮想サーバーには、物理サーバーと同じメンテナンスとパッチが必要です。ベアメタルハイパーバイザーには、セキュリティのためだけでなく、バグの修正とパフォーマンスの向上のための更新が必要です。サーバーの数が多いほど、サーバーを最新の状態に保つために必要な作業が増えます。サーバーが物理的であるか仮想的であるかは関係ありません。
上記の回答に基づくと、次のように思われます。サーバーを仮想化すると、セキュリティと信頼性がより複雑になり、リスクが高まりますが、サーバーを仮想化することでダウンタイムを削減できるというメリットと比較検討する必要があります。
ご使用の環境で監査、テスト、および文書化が必要な場合は、仮想化環境の追加ワークロードの費用便益を、サーバーとシステムスタッフの数とともに考慮する必要があります。私たちの環境では、仮想化された環境の監査証跡を維持するためのスタッフ/スタッフの時間がありません。私たちのビジネスプロセスでは、ある程度のダウンタイムが発生する可能性がありますが、監査証跡とドキュメントを見逃すことはできません。