von Redaktion IT-A…
Lesezeit
2 Minuten
Seite 2 - vSphere: Best Practices für Infrastruktur, Betrieb & Troubleshooting (2)
Das Ressourcen-Pool-Paradoxon
Betrachten wir ein einfaches Beispiel aus nur zwei Ressourcenpools auf oberster Ebene. Ein Pool mit der Priorisierung High und einen zweiten Pool mit der Priorisierung Low. Pool High und Pool Low teilen die Gesamtressourcen im Verhältnis 4:1. Das entspricht 80 Prozent für High und 20 Prozent für Low. Angenommen es gibt 20 VMs im Pool High und zwei VMs im Pool Low. Jede VM im Pool High erhält ein Zwanzigstel der 80 Prozent Gesamtressourcen (4 Prozent). Im Pool Low erhält jede VM die Hälfte der 20 Prozent Gesamtressourcen (10 Prozent). Es wurde also genau das Gegenteil der ursprünglichen Idee erreicht.
Standardpools funktionieren nur dann erwartungsgemäß, wenn sich darin jeweils die gleiche Anzahl uniformer VMs (mit gleicher Anzahl vCPU und RAM) befindet. Dies ist aber in der Realität fast nie der Fall. Besser sind hier an gepasste Ressourcen-Pools (Custom Pools). Dabei werden die virtuellen Ressourcen im Pool aufsummiert und pro virtueller Ressource im Pool High vier Anteile vergeben, im Pool Normal zwei Anteile und im Pool Low ein Anteil. Wir verwenden den Begriff "Anteil", weil dieser nur dazu dient, ein Verhältnis der Pools zueinander zu errechnen. Ob wir dabei 4:1 oder 4000:1000 Anteile haben, spielt keine Rolle.
Angenommen es gibt im benutzerdefinierten Pool "Produktion" 20 VMs mit insgesamt 50 vCPUs und im benutzerdefinierten Pool "Test" zwei VMs mit insgesamt vier vCPUs. Pro vCPU im Pool Produktion werden vier Anteile vergeben (50 x 4 Anteile = 200 Anteile). Pro vCPU im Pool Test wird ein Anteil vergeben (4 x 1 Anteil = 4 Anteile). Die Gesamtressourcen werden zwischen den beiden neuen Pools nun nicht mehr im Verhältnis 4:1, sondern im Verhältnis 200:4 verteilt. Das entspricht (gerundet) 98 Prozent für den Produktionspool und zwei Prozent für den Test-pool. Jede vCPU im Produktionspool erhält somit zwei Prozent der Gesamtressourcen und eine vCPU im Testpool 0,5 Prozent der Ressourcen. Wir erreichen somit die ursprünglich angedachte Priorisierung der VMs auf Basis ihrer vCPUs beziehungsweise RAM-Ressourcen.
VMs und Pools auf einer Ebene
VMs und Pools sind für den Cluster Objekte, denen Ressourcen zugeteilt werden können. Sie werden streng hierarchisch verwaltet. Ressourcen-Pools können untergeordnete Pools haben. Diese teilen sich die Ressourcen ihres gemeinsamen Elternpools und geben ihren Anteil an darunter liegende Objekte weiter (Child Objects). VM-Objekte dürfen keine untergeordneten Objekte haben. Sie sind das Ende der Ressourcenkette. Objekte auf einer Hierarchie-Ebene heißen "Geschwister" (englisch Siblings).
Sind keine Priorisierungen definiert (Standard), werden sie in Bezug auf Ressourcen gleichbehandelt. Zwei Standardpools auf oberster Ebene ohne Priorisierung teilen sich die Cluster-Ressourcen zu gleichen Teilen, womit jeder Pool 50 Prozent der Gesamtressourcen erhält. Zwei untergeordnete Standardpools erhalten so wiederum je 50 Prozent des Elternpools, was 25 Prozent der Gesamtressourcen entspricht.
Mischen wir VM-Objekte mit Poolobjekten auf einer Ebene, so werden diese gleichberechtigt behandelt. Ein Ressourcenpool, der 50 VMs enthält, erhält somit genau die gleiche Menge an Ressourcen wie eine einzelne VM, die neben diesem Pool auf derselben Ebene liegt. Sie sollten VMs daher niemals auf einer Ebene mit Pools platzieren.
Manch ein Administrator kann übrigens der Versuchung nicht widerstehen, die vermeintlich ungeordneten VMs in der "Hosts & Cluster"-Ansicht etwas zu ordnen. Es werden Pools angelegt, die als Ordner und Unterordner fungieren. Im Standard haben diese keine Priorisierung (Normal) und teilen die Ressourcen innerhalb jeder Ebene zu gleichen Anteilen. Es bedarf nicht viel Fantasie sich vorzustellen, ab der wievielten Schachtelebene es ungewollt zu erheblichen Ressourcenverknappungen kommen wird. Wer seine VMs ordnen und strukturieren möchte, sollte dies in der Ansicht "VMs & Vorlagen" tun. Hier dürfen Sie Ordner und Unterordner nach Wunsch einrichten, ohne dass dies Auswirkungen auf die Leistung der VM hat.
Seite 2: Das Ressourcen-Pool-Paradoxon
Im dritten Teil geht es darum, wie sich vSphere-Admins mit Drittanbieterwerkzeugen vor allem beim Monitoring das Leben leichter machen. In der ersten Folge des Workshops warfen wir einen Blick auf die Hardware Compatibility List und gingen Fehlerquellen in DNS und LAN auf den Grund.
dr/ln/Dr. Jens Söldner und Dr. Michael Schröder
Betrachten wir ein einfaches Beispiel aus nur zwei Ressourcenpools auf oberster Ebene. Ein Pool mit der Priorisierung High und einen zweiten Pool mit der Priorisierung Low. Pool High und Pool Low teilen die Gesamtressourcen im Verhältnis 4:1. Das entspricht 80 Prozent für High und 20 Prozent für Low. Angenommen es gibt 20 VMs im Pool High und zwei VMs im Pool Low. Jede VM im Pool High erhält ein Zwanzigstel der 80 Prozent Gesamtressourcen (4 Prozent). Im Pool Low erhält jede VM die Hälfte der 20 Prozent Gesamtressourcen (10 Prozent). Es wurde also genau das Gegenteil der ursprünglichen Idee erreicht.
Standardpools funktionieren nur dann erwartungsgemäß, wenn sich darin jeweils die gleiche Anzahl uniformer VMs (mit gleicher Anzahl vCPU und RAM) befindet. Dies ist aber in der Realität fast nie der Fall. Besser sind hier an gepasste Ressourcen-Pools (Custom Pools). Dabei werden die virtuellen Ressourcen im Pool aufsummiert und pro virtueller Ressource im Pool High vier Anteile vergeben, im Pool Normal zwei Anteile und im Pool Low ein Anteil. Wir verwenden den Begriff "Anteil", weil dieser nur dazu dient, ein Verhältnis der Pools zueinander zu errechnen. Ob wir dabei 4:1 oder 4000:1000 Anteile haben, spielt keine Rolle.
Angenommen es gibt im benutzerdefinierten Pool "Produktion" 20 VMs mit insgesamt 50 vCPUs und im benutzerdefinierten Pool "Test" zwei VMs mit insgesamt vier vCPUs. Pro vCPU im Pool Produktion werden vier Anteile vergeben (50 x 4 Anteile = 200 Anteile). Pro vCPU im Pool Test wird ein Anteil vergeben (4 x 1 Anteil = 4 Anteile). Die Gesamtressourcen werden zwischen den beiden neuen Pools nun nicht mehr im Verhältnis 4:1, sondern im Verhältnis 200:4 verteilt. Das entspricht (gerundet) 98 Prozent für den Produktionspool und zwei Prozent für den Test-pool. Jede vCPU im Produktionspool erhält somit zwei Prozent der Gesamtressourcen und eine vCPU im Testpool 0,5 Prozent der Ressourcen. Wir erreichen somit die ursprünglich angedachte Priorisierung der VMs auf Basis ihrer vCPUs beziehungsweise RAM-Ressourcen.
VMs und Pools auf einer Ebene
VMs und Pools sind für den Cluster Objekte, denen Ressourcen zugeteilt werden können. Sie werden streng hierarchisch verwaltet. Ressourcen-Pools können untergeordnete Pools haben. Diese teilen sich die Ressourcen ihres gemeinsamen Elternpools und geben ihren Anteil an darunter liegende Objekte weiter (Child Objects). VM-Objekte dürfen keine untergeordneten Objekte haben. Sie sind das Ende der Ressourcenkette. Objekte auf einer Hierarchie-Ebene heißen "Geschwister" (englisch Siblings).
Sind keine Priorisierungen definiert (Standard), werden sie in Bezug auf Ressourcen gleichbehandelt. Zwei Standardpools auf oberster Ebene ohne Priorisierung teilen sich die Cluster-Ressourcen zu gleichen Teilen, womit jeder Pool 50 Prozent der Gesamtressourcen erhält. Zwei untergeordnete Standardpools erhalten so wiederum je 50 Prozent des Elternpools, was 25 Prozent der Gesamtressourcen entspricht.
Mischen wir VM-Objekte mit Poolobjekten auf einer Ebene, so werden diese gleichberechtigt behandelt. Ein Ressourcenpool, der 50 VMs enthält, erhält somit genau die gleiche Menge an Ressourcen wie eine einzelne VM, die neben diesem Pool auf derselben Ebene liegt. Sie sollten VMs daher niemals auf einer Ebene mit Pools platzieren.
Manch ein Administrator kann übrigens der Versuchung nicht widerstehen, die vermeintlich ungeordneten VMs in der "Hosts & Cluster"-Ansicht etwas zu ordnen. Es werden Pools angelegt, die als Ordner und Unterordner fungieren. Im Standard haben diese keine Priorisierung (Normal) und teilen die Ressourcen innerhalb jeder Ebene zu gleichen Anteilen. Es bedarf nicht viel Fantasie sich vorzustellen, ab der wievielten Schachtelebene es ungewollt zu erheblichen Ressourcenverknappungen kommen wird. Wer seine VMs ordnen und strukturieren möchte, sollte dies in der Ansicht "VMs & Vorlagen" tun. Hier dürfen Sie Ordner und Unterordner nach Wunsch einrichten, ohne dass dies Auswirkungen auf die Leistung der VM hat.
Seite 2: Das Ressourcen-Pool-Paradoxon
Im dritten Teil geht es darum, wie sich vSphere-Admins mit Drittanbieterwerkzeugen vor allem beim Monitoring das Leben leichter machen. In der ersten Folge des Workshops warfen wir einen Blick auf die Hardware Compatibility List und gingen Fehlerquellen in DNS und LAN auf den Grund.
| << Vorherige Seite | Seite 2 von 2 |
dr/ln/Dr. Jens Söldner und Dr. Michael Schröder
