VMWare API in Web-Anwendung - unterschiedliche Antwortzeiten

[ThoSchu]

Situation:
Eine Web-Anwendung, über die mit Hilfe der VMWare API Informationen zu unterschiedlichen VMWare-Objekten, wie virtuelle Maschinen, Datastores, Snapshots etc. abgefragt werden können, läuft auf zwei identischen Cluster-Knoten. Auf beiden Knoten ist neben dem IIS das Virtual Center installiert und der Web-Service läuft.
Die Seiten werden über einen Alias-Namen angefragt. Die Anfragen werden von einem Loadbalancer entsprechend an einen Knoten weitergeleitet.
Die Web-Anwendung wurde in C# programmiert und verwendet .NET 2.0.

Phänomen:
Antworten insbesondere bei der Erstellung von Listen (z.B. einer Übersicht über alle Snapshots zu virtuellen Maschinen) dauern je nach Knoten unterschiedlich lange. Die Zeitdifferenz ist z.T. drastisch. Z.B.
Snapshot-Übersicht auf Knoten 1: 00:00:04.6720245
Snapshot-Übersicht auf Knoten 2: 00:02:25.2646953
Es wurden aus exakt derselben Applikation exakt dieselben Daten abgefragt. Wie eingangs erwähnt sind nicht nur beide IIS identisch konfiguriert.

Leider war meine Suche nach einer Ursache für das Phänomen bisher erfolglos. Nun hoffen ich, jemand in diesem Forum kann weiter helfen. Ziel ist es, auch den langsamen Knoten auf die Antwortzeiten des schnellen zu bringen.

Vielen Dank im Voraus!

[Tschoergez]

äääh, nochmal: Du hast zwei VC-Dienste auf verschiedenen Servern aktiv, die jeweils auf die gleiche Datenbank zugreifen????

Ist das überhaupt supportet? (Ich hätte jetzt nicht einmal gedacht, dass das überhaupt gut geht.... )

Viele grüße,
Jörg

[ThoSchu]

Es handelt sich um einen Cluster.

[Tschoergez]

dann: was für ein cluster? MSCS oder irgendwelche Drittanbieter?

[ThoSchu]

Wie eingangs erwähnt: C#, ,NET2.0, IIS!
Windows 2003.
Aber das Clustering ist nicht das Problem und auch nicht die Ursache für das Verhalten. Wären die beiden Maschinen nicht in einem Cluster-Verbund, könnte das Phänomen auch beobachtet werden. Durch den Aufruf der Anwendung lokal auf dem jeweiligen Rechner, kann dasselbe Verhalten nachzuvollzogen werden.
Ich vermute eher einen Unterschied bei der Kommunikation des Webservices mit der Datenbank, oder beim Datenaustausch zwischen der Web-Applikation (VimService) und dem WebService (SOAP, WSDL, XML). Leider fehlt mir der richtige Ansatz.

[ThoSchu]

Was ist los Leute? - So früh schon die Flinte in's Korn werfen?
Hat keiner eine Idee? Es muss ja nicht gleich die entgültige Lösung sein. Über einen Ansatz würde ich mich schon freuen.

[Tschoergez]

kannst Du mal ein Bild malen von Deiner Infrastruktur?
Wo läuft das VC, wo liegt die Datenbank, wo die Webserver, und wo die Applikation? Ich kann mir Deine Umgebung noch nicht wirklich vorstellen...

Was für ne Applikation ist das (welche Programmiersprache)?

Viele Grüße,
Jörg

[ThoSchu]

Lest Ihr eigentlich ab und zu auch die älteren Einträge zu einem Thema?
Also nochmal:
Auf zwei Knoten in einem Cluster-Verbund unter W2K3 läuft jeweils ein VC.
Das VC wird über einen Aliasnamen angesprochen, der auf den Namen des Clusters bzw. seine IP verweist. Damit existiert immer nur ein VC in der Infrastruktur, da die Instanz immer nur auf einem Cluster-Knoten aktiv sein kann.
Die Webserver, IIS 6.0, laufen auf den Cluster-Knoten. Der IIS ist nicht geclustert. Ein Loadbalancer übernimmt hier die Lastverteilung.
Beide Knoten sind absolut identisch installiert und konfiguriert. Das gilt auch für den IIS auf jedem Knoten.
Bei der Applikation handelt sich um eine Web-Applikation, geschrieben in C#, die .Net 2.0 nutzt. Für den Zugriff auf die VM-Ware-Objekte im VC aus der Applikation wird die VMWare-API verwendet, die wiederum gem. den Definitionen von VMWare mit Hilfe von SOAP und WSDL auf Methoden/Eigenschaften zugreift, die vom VMWare-WebService zur Verfügung gestellten werden. Die Verbindung aus der Applikation zum VimService wird über den Alias des VC hergestellt. Der VMWare-WebService ist wie das VC geclustert und läuft nur auf dem Knoten, auf dem das VC aktiv ist.
Es sind dieselben Applikations-Dateien auf die beiden Webserver verteilt worden.

Die Verwendung der Web-Applikation sieht wie folgt aus:
1. Verbindung zur Website durch Aufruf der URL im Browser (URL=Alias-Namen der Website wie im Loadbalancer hinterlegt).
2. Loadbalancer leitet die Anfrage entsprechend der Lastverteilung an Webserver 1 oder Webserver 2 weiter.
3. Aus der Web-Applikation wird über die VMWare-API eine Verbindung zum VC hergestellt. Die URI für den Webservice ist der Alias des VC (einschl. /sdk). Nicht die eines der beiden Cluster-Knoten! Damit landet die Anfrage beim in diesem Moment aktiven VC (siehe Erklärung am Anfang dieses Eintrags).

Je nach dem, an welchen Webserver die Anfrage geleitet wird, gibt es sehr deutliche Unterschiede bei den Antwortzeiten, wenn Infos von VMWare-Objekten abgerufen werden. Das ist auch zu beobachten, wenn die Website lokal auf dem jeweiligen Webserver aufgerufen wird.
Werden die Webserver direkt angesprochen, also nicht über den Alias-Namen, tritt dasselbe Phänomen auf. Es spielt außerdem keine Rolle, auf welchem Cluster-Knoten gerade das VC aktiv ist.

Wie gesagt, Betriebssystem der Knoten, IIS und, soweit ich es übersehe, auch die VCs sind absolut identisch. Selber Patch-Stand, selbe Netzkartenkonfiguration, dieselben Einstellungen vom .NET, usw.

Da aus der Web-Applikation über SOAP und WSDL auf den Webservice des VC zugegriffen wird, vermute ich hier die Ursache:
- Kommunikation aus Applikation von Webserver 1 mit VC -> schnell
- Kommunikation aus Applikation von Webserver 2 mit VC -> langsam
.NET-Konfiguration: identisch
IIS-Konfiguration: identisch
OS-Konfiguration: identisch
NIC-Konfiguration: identisch (bis natürlich auf die IP)

Es wäre mir auch eine Hilfe, wenn mir jemand einen Kontakt nennen könnte, an den ich mich wenden kann.

[Tschoergez]

nanana, nicht so ungeduldig Wenn Du siehtst, dass eh nur einer überhaupt antwortet, kannst Du schon davon ausgehen, dass ich Deine Antworten lese

Auf jeden Fall kann ich mir jetzt ein Bild von Deiner Umgebung machen, was vorher noch nicht ging...
Also MSCS (warum nicht gleich...).

D.h also, wenn der Aufruf Deines Programms auf dem Knoten erfolgt, auf dem gerade das VC aktiv ist, "bleibt" alles auf dem gleichen Server.

Wenn der Aufruf auf dem jeweiligen anderen Server erfolgt, dann wird natürlich auf den Tomcat zugegriffen, der auf dem VC-aktiven-Server läuft.

Bin ich soweit noch richtig?

Kannst Du unterschiede feststellen ind der Zeit, wie lange auf beiden Servern z.b. Namensauflösung des VC-Aliasnamen braucht? reverse-Namensauflösung? (dass nicht das schon der Fehler ist)

Wie lange dauert es, bis jeweils auf jedem Server der Managed Object Browser aufgerufen wird?

Testversuch über ein anderes Script, zB das viperltoolkit, um .net auszuschließen?

Und: hast Du die Standard-SSL-Zertifikate für den Tomcat drin? Bleibt das Problem, wenn Du die Verschlüsselung ganz abstellst für den Zugriff auf die API?

Und lässt sich der fehler "umkehrt-rum" reproduzieren, wenn Server2 der aktive VC-Knoten ist?

...mal so ein paar Anregungen, wie ich an die Sache rangehen würde.
Kontakt wüsste ich jetzt außer dem VMware Support keinen, höchstens vllt. mal im offiziellen Forum posten, der SDK-Abschnitt ist da noch nicht so überlaufen...

Viele Grüße, und schönes Wochenende!
jörg