CRS Dynamic Feature

[Falk R.]

Hallo,

ich hoffe hier erreiche ich alle die am CRS Feature mitwirken.
Zuerst einmal ein dickes Lob für die bisherige Umsetzung des CRS.

Jetzt mein Anliegen:
Da ich seit 2006 mit vSphere arbeite, habe ich einige Fehler von VMware gesehen, welche man nicht wiederholen muss. Bis vSphere6 hatte VMware ihr DRS Feature basierend auf CPU und RAM Auslastung des Hosts, was sich aber oft als unoptimal herausgestellt hat. Seit vSphere7 wird die CPU Latenz der VM als Grundlage genommen.
Das mit der CPU Latenz sehe ich als schwer umsetzbar bei PVE weil die Zentrale Instanz mit Datenbank nicht vorhanden ist.
Eventuell kann aber bei PVE CPU Pressure und ioWait mit einbezogen werden in die Kalkulation. Die RAM Auslastung lässt sich ja einfach umsetzen und ist auch bei vSphere als untergeordneter Wert noch in der Kalkulation.

Ich hoffe, dass ich meine Meinung noch rechtzeitig kundgetan habe.
Bei Fragen bin ich über alle Kommunikationswege erreichbar.

Gruß,
Falk

 

[fiona]

Hallo,

Das mit der CPU Latenz sehe ich als schwer umsetzbar bei PVE weil die Zentrale Instanz mit Datenbank nicht vorhanden ist.
Eventuell kann aber bei PVE CPU Pressure und ioWait mit einbezogen werden in die Kalkulation. Die RAM Auslastung lässt sich ja einfach umsetzen und ist auch bei vSphere als untergeordneter Wert noch in der Kalkulation.

für den dynamischen Scheduler ist (unter anderem) CPU-Pressure zu berücksichtigen ist auf jeden Fall geplant, hier gab es schon einen ersten Ansatz. Das Problem mit dem Broadcasten im Cluster ist allerdings, dass da recht schnell viel Traffic zustande kommt. Idealerweise müsste nur der aktuelle HA-Master die Daten bekommen (und im Grunde auch nur auf Anfrage). Da sind wir noch am Überlegen, wie wir es konkret umsetzen.

RAM wird eher eine übergeordnete Rolle als CPU spielen, weil RAM ist ja wirklich limitiert

Ein bisschen was and der Infrastruktur vom HA-Manager muss auch noch getan werden, damit er als Scheduler auch nicht HA-Gäste mit einbeziehen kann.

 

[Falk R.]

Hallo,

für den dynamischen Scheduler ist (unter anderem) CPU-Pressure zu berücksichtigen ist auf jeden Fall geplant, hier gab es schon einen ersten Ansatz. Das Problem mit dem Broadcasten im Cluster ist allerdings, dass da recht schnell viel Traffic zustande kommt. Idealerweise müsste nur der aktuelle HA-Master die Daten bekommen (und im Grunde auch nur auf Anfrage). Da sind wir noch am Überlegen, wie wir es konkret umsetzen.

RAM wird eher eine übergeordnete Rolle als CPU spielen, weil RAM ist ja wirklich limitiert

Ein bisschen was and der Infrastruktur vom HA-Manager muss auch noch getan werden, damit er als Scheduler auch nicht HA-Gäste mit einbeziehen kann.

Hi Fiona,

VMware hat für DRS auch bis zu 3 VMs pro Cluster für die Datensammlung.
Eventuell kann man das ja auch in eine VM oder ein LXC auslagern. Die wird dann nur ausgerollt wenn man das Feature nutzen möchte.
Damit wäre nicht der Host so belastet.
Da das CRS aber stark mit dem HA Manager verknüpft ist, weiß ich nicht ob das geht.

 

[fiona]

VMware hat für DRS auch bis zu 3 VMs pro Cluster für die Datensammlung.
Eventuell kann man das ja auch in eine VM oder ein LXC auslagern. Die wird dann nur ausgerollt wenn man das Feature nutzen möchte.
Damit wäre nicht der Host so belastet.

Versteh ich jetzt nicht. Wie soll das Auslagern in Gäste helfen? Der Traffic muss ja trotzdem über den Host laufen und man hat eigentlich nur mehr Overhead mit den Gästen? Und dann muss noch die Information vom Gast zum HA-Manager übermittelt werden.

 

[Falk R.]

Ich habe keine Ahnung wie das mit dem HA Manager verknüpft ist. Bei vSphere verteilt sich der Traffic auf 3 kleine VMs, welche auch irgendwie Redundant miteinander sprechen. War nur eine Idee von mir. Man kann ja auch von anderen lernen.

Ich finde es schon mal sehr schön, das Pressure mit einfließt.

 

[tom]

Man kann ja auch von anderen lernen.

Natürlich, aber Traffic in einen Gast auslagern um dann wieder zum Host zu übertragen ist eher sinnbefreit bzw. verursacht mehr Aufwand und nicht weniger.