web-dev-qa-db-ja.com

ESX3.5リソースグループ

私はDBAであり、主にSQLサーバーといくつかのアプリケーションサーバーをホストするvmware ESX 3.5クラスターを管理しています。リソースグループの設定方法について質問がありますただし、ESXの1つと競合していますリソースの管理方法に関するシステム管理者。

クラスター（3ノード、ノードあたり32GB）は現在、77GBのRAMを消費するように構成された33のゲストをホストしていますが、ESXは44GBのみがアクティブであると報告しています。クラスターは、ライブサーバー、テストサーバー、開発サーバー、およびその他のいくつかのゲストをホストします。

私がやりたいのは、サーバーリソースの管理を簡素化し、関連するサーバーのパフォーマンスを管理およびレポートできるようにすることです。

たとえば、Live SQLサーバー、SharePointサーバー、CRMサーバーなどで消費されるリソース（RAM、ディスク、CPU）。

次に行ったことは、4つの「トップレベル」リソースグループを作成することです。

1-High    - For the most mission critical services (ie. the live SQL server)
  32768 memory shares
2-Normal  - For the majority of the remaining live systems (CRM, Sharepoint etc)
  16384 memory shares
3-Dev     - Test and development systems
  8192 memory shares
4-Low     - Non supported servers (no sla, temporary build servers etc)
  1024 memory shares

サーバーを独自の「アプリケーション」リソースグループ（SQL Live、SQL Test、CRM Live、CRM Testなど）にグループ化しましたが、これらのグループに明示的なリソース制限を設定していません。

次に、「アプリケーション」グループを適切な「トップレベル」リソースグループに配置します。

たとえば、各サブグループには4つのゲストがあり、それぞれに1つのCPUと1GBのRAMがあります

1-High               32768 shares
    SQL Live         4 guests
2-Normal             16384 shares
    CRM Live         4 guests
    Sharepoint Live  4 guests
3-Dev                16384 shares
    CRM Test         4 guests
    SQL Test         4 guests
    Sharepoint test  4 guests
4-Low 
    Remaining cruft  4 guests

Sysadminの担当者は、「Sharepointは必要なリソースの50％のうち28％しか取得できない」と言っています。

彼に返信する前に、アドバイスと私の仮定の確認を得ることができますか？

  • 通常の操作では、クラスターはRAM（またはCPU）をオーバーコミットしていないため、CPUまたはRAMのいずれのゲストにもリソース制限は適用されません。
  • ホストの1つに障害が発生した場合、64GBのRAMが使用可能です。ゲストが再起動されると（HAとDRSが有効になっています）、残りのホストがゲストの再起動を開始します。 RAMをオーバーコミットします。
  • 最優先のサービスがサービスを維持できるようにしたい
  • 個々のゲストを細かく管理したくありません！

あなたの考えや経験は何ですか？

vmware-esxresource-management
2
Guy

私がこれを正しく読んでいれば、あなたはあなたの環境の通常の操作について正しいですが、競合が発生したときにそれがどのように機能するかについてあなたのどちらかが正しいかどうかはわかりません。

競合がない場合（リソース使用率が80％BTWを超えると競合が開始されます）、共有は効果がありません。ご使用の環境での通常の操作に関する限り、リソースグループは表面的なものになります。

競合がある場合、システム管理者が示しているようにCPUリソースが制限されますが、ホストを失った場合は必ずしもそうなるとは限りません。

子リソースプールの共有を変更したかどうかはわかりません。これらはすべて正常に設定されていると仮定します。

共有の仕組みに競合があると仮定すると、各リソースプールは、そのレベルの共有の合計量の割合に等しいリソースの割合を取得します。最初のレベルでは、最大58kのシェアがあるため、高プールは約56％、通常は28％、開発は14％、低は1.7％になります。同じルールが適用されてもプールの合計は影響を受けない場合、そのレベルで追加の共有を明示的に設定しない限り、各プール内でサブプールはそのプールのリソースを均等に共有します。

したがって、競合が発生した場合、Live Sharepointシステムは競合するリソースの28％の50％、つまり14％を取得します。

CPUの絶対最小値とRAM共有によって割り当てられます。これらの主な欠点は、値が高すぎると、リソースが保証されないため、クラスターがVMの再起動を試みることさえできない可能性があることです。

また、Windowsシステムでの通常の操作ではシステムが最大44GBしか消費しない場合でも、VMが起動すると、メモリの100％が（簡単に）割り当てられます。これにより、メモリの競合シナリオがトリガーされる可能性があります。フェイルオーバー中は、実行後のシステムに実際には十分なRAMがあります。心配しすぎる以上に注意を払う必要がありますが、HAの再起動時に問題が発生する可能性があります。

追加するために編集
個々のVMまたは子リソースグループのデフォルトの共有設定に変更を加えていない場合、すべてのVMをある構造内のレベルを上に移動しても、個々のVMに割り当てられるリソースの割合は変わりません。子RGは1つだけで、親に直接配置します。ただし、複数の子RGがあり、それぞれに異なる数のVMがある場合、これは当てはまりません。

あなたの例では、子RGに4つのSharepoint VMがあり、子グループに2つのCRMVMがあるとします。 Sharepoint VMはそれぞれ約3.5％（28％/ 4の50％）を取得し、CRM VMはそれぞれ7％（28％/ 2の50％）を取得します。これらすべてを親RGに移動し、空の子RGを削除すると、6つのVMが通常のRGで使用可能なリソースの28％を共有し、それぞれが最大4.7％（28％/ 6）になります。

もちろん、子リソースグループまたは個々のVMの共有を変更すると、これはすべて変更されます。

6
Helvick

リソース定義は、オーバーコミットされたクラスターでのみ有効になります。

1
Chopper3