Archiv für August, 2012

Wie in meinem letzten Beitrag über den Einsatz von Resource Pools beschrieben kann man in vmware Resource Pools eine Einstellung treffen ob dieser Resource Pool Resourcen vom übergeordneten Pool beziehen darf oder nicht (Expandable Reservation).

Da der übergeordnete Pool in einem vmware vSphere Cluster die gesamten Cluster Resourcen umfasst, (CPU Leistung aller Hosts im Cluster summiert, ebenso physikalischer RAM in allen Hosts aufsummiert) besteht die Möglichkeit Hostübergreifende Resource Silos zu bilden.

Die Idee der Resource Silos sieht dann folgendermassen aus:

Wir nehmen mal eine Unternehmen mit verschiedenen Abteilungen an die alle auf einem vSphere Cluster gehostet werden. Jede Abteilung hat verschiedene VMs die sie betreibt. Möglicherweise haben die Abteilungen sogar das Recht selbst VMs zu erstellen oder umzukonfigurieren.

Der „arme“ vmware Administrator steht nun vor der Aufgabe mit Bordmitteln dafür zu sorgen, das die Abteilungen größtmögliche Freiheiten genießen, sich aber nicht gegenseitig behindern, indem Sie zu viele Resourcen aus dem Cluster beziehen. Was könnte man nun tun?

Eine interessante Lösung währe ein Konzept basierend auf Resource Pools.

Jede Abteilung wird in einen eigenen Resource Pool gepackt. Das sähe dann z.B. so aus:

Das alleine nutzt unserem Admin aber noch nicht sehr viel. Er kann nun zwar den Abteilungen Rechte auf Ihre Resource Pools geben, doch Resource Pools nur für Rechtestrukturen sollten niemals angelegt werden. Das währe auch mit Foldern unter dem View „VMs und Templates“ möglich.

Erinnern wir uns mal an den Schalter „Expandable Reservation“ für CPU und Memory. Des weiteren denken wir mal an die Möglichkeit Limits zu setzen.

Hier haben wir eine interessante Möglichkeit Resourcen Silos zu definieren.

Wir nehmen dazu unsere Cluster Resourcen, bauen für jede Abteilung im Cluster einen „Abteilungs-Root-Resource Pool“ und konfigurieren diesen wie folgt.

–          Expandable Reservation sowohl für CPU als auch für Memory := NO

–          Limit für Memory z.B. für eine Abteilung 32 GB, für eine andere 64 GB usw. je nach Anforderung bzw. bei zahlenden Kunden nach Bezahlung

–          CPU MHz ebenso wie Memory mit einem festen Limit

Was passiert nun?

Eine Abteilung kann innerhalb Ihres zugewiesenen Pools Resourcen bis zum definierten Limit verbrauchen (getreu dem Motto „Die merken schon wenn es eng wird“). Erreichen sie das Limit können sie keiner Nachbarabteilung „das Wasser oder die Resourcen abgraben“, denn durch den Schalter „Expandable NO“ werden bei Overcommitment im Resource Pool keine weiteren Resourcen vom Cluster bezogen.

Durch das Limit auf CPU und Memory haben wir praktisch ein Resourcen Silo im Cluster gebaut. So als wenn die physikalischen Abteilungsserver der Vergangenheit die Limitierung der IT Resourcen darstellen. Vorteil hier, wenn tatsächlich mehr Resourcen benötigt werden kann entweder der Resourc Pool neu definiert werden, oder es wird weitere Hardware beschafft und dann der Resource Pool erweitert (Limits erhöhen!).

Somit haben wir ohne Zusatztools einfach und sicher unsere vSphere Cluster Resourcen auf die Abteilungen heruntergebrochen.

Was halten Sie von dieser Idee? (Kommentare erwünscht)