ESX / VMware nicht erklärbare Netzwerkphänomen

[rutz]

Hallo,

ich habe ein Problem wo ich nicht genau greifen kann bzw. finden kann.

Wir haben derzeit ca. 24 Hostserver und ca. 100 VM.

Da von SAP auch Virtualisierung unter VMWare auch freigeben wurde sind wir derzeit auch dabei dies nach und nach zu machen.

Jetzt bekomme ich von den SAP Kollegen und auch paar anderen Kollegen mitgeteilt das anscheinend im Hintergrund Verbindungsabbrüche zur Datenbank bestehen. Andere Kollege meint auch das im Hintergrund VMWare anscheinend Verbindungsprobleme gibt.

Wenn ich nun von Windowsseite her ein Dauerping durchführe und Logs auswerte sehe ich das es meist unter 1ms bleibt und gelegentlich auf ca. 15 ms hochgeht. Jedoch richtige Verbindungsabbrüche nicht.

Kennt noch jemand die Problematik oder kann mir TIPS geben wie und wo ich da schauen oder schrauben kann.

Vom Build auf den ESX Server ist Update 2 und Update 3.

Bin momentan ratlos. Denn auch laut Leistungsberichte gibt es bei den Systemen keine Abbrüche.

Danke im voraus, wenn Infos benötigt reiche ich die gerne nach besten Wissen nach

[kastlr]

Hallo,

was genau meinen deine Kollegen denn, wenn Sie von Verbindungsabbrüchen zur Datenbank reden?
Das remote Clients die Verbindung zum DB Server verlieren oder der SAP/DB Server Probleme beim Zugriff auf seine Volumes hat und dabei lange Antwortzeiten sichtbar werden?

Ich nehme mal an, das die SAP Applikation sich einer Oracle DB bedient.
Befinden sich SAP und DB auf einer VM?
Wurde beim Anlegen der SAP/DB VM auf die besonderen Anforderungen bezüglich Log Files etc geachtet?

Wir benötigen einfach mehr Infos, was genau das Problem in welcher Umgebung ist (OS & DB, SAN, VMDK oder RDM etc..)

Gruß
Ralf

[rutz]

Kein thema, wenn Infos fehlen reiche ich die gerne nach, wollte nur wissen was ihr braucht.

Also zu deiner Frage bzw. gewünschten Infos.

Verbindungsmässig vom SAP Kollege meinte er das der Apllikationsserver zum Datenbankserver Fehler bei der Lanverbindung. Generelle Verbindungsabbrüche gibt es meines Wissens nicht.

Also OS von der VM Maschine ist Windows Server 2003 Enterprise 64-Bit
DB von SAP ist DB2 Versionsstand genau müsste ich erfragen falls ihr den genauen Stand braucht.

Also die Datenbankplatte wird durch das SAN direkt durchgeschleift zur VMWare sprich zugeordnete RAW Device.

Ansonsten die restlichen Festplatten sind von SAN-Platten die die ESX Server direkt sehen.

DB ist vom Applikationsserver getrennt.

Welche genaue Anforderungen meinst du wegen den LOG Files? Die Infos wo ich hatte haben wir eigentlich beachtet. Sprich feste Speicherzuweisung und Reservierung. Doch wegen Log Files hab ich jetzt keine Infos. Kannst du mir dies erläutern.

ESX Version ist ESX 3.5.0 Build 123630

Der andere Kollege meldet das VErbindungsabbrüche auftreten im Lunix. Wie gesagt kann es nicht nachvollziehen, da bisher mir keinerlei Probleme bekannt waren und andere Server irgendwie nicht die Probleme haben (oder bisher nicht aufgefallen ist).

Hoffe hilft weiter, wenn noch was fehlen sollte einfach sagen, dann reiche ich es gerne nach.

[kastlr]

Hallo,

sofern deine ESX Server über genug Resourcen verfügen, würde ich die SAP VM und DB VM auf einem ESX Server laufen lassen, um den Netzwerkverkehr zwischen den VM's durchs RAM laufen zu lassen.

Und leider hilft uns die Aussage deines SAP Kollegen nicht wirklich weiter, schließlich wissen wir immer noch nicht, welche Fehler er denn nun sieht.

Mit DB2 kenne ich mich nicht aus, jedoch zeichnen sich DB Logfiles durch einen extrem hohen Schreibanteil aus.
Daher sollten diese möglichst auf RAID 1 Platten liegen und idealerweise nur der VM zugewiesen sein.
Ob du jetzt RDM oder VMDK dafür benutzt ist nicht wirklich entscheidend, vielmehr ob die verwendete Disk mehrere VM's enthält die durch andere ESX Server gehostet werden.
In dem Fall können SCSI Reservierungen massive Auswirkungen auf die Performance haben.
Aber dafür existieren meines Wissens SAP Dokumentationen, wie ein DB2 Umfeld unter VMware in Verbindung mit SAP aussehen sollte.

Dann gibt es noch im Windows Umfeld die Empfehlung, die verwendeten NTFS Partitionen zu allignen.
Jedoch ist die nur beim Anlegen der Partition möglich, es bringt ungefähr 10-12% mehr Performance (sofern es sich hier um ein Performance Problem handelt).

Es gibt ein paar Möglichkeiten, eine VM zu tunen, aber dazu müßte man schon wissen, wo denn das Problem auftritt.

Wenn es z. B. immer im Anschluß an eine vMotion Operation zu LAN Problemen kommt, solltest du mal die verwendeten LAN Switche auf ihre STP Einstellungen überprüfen.
Dabei kann man auch gleich die Einstellungen für Jumbo Frames prüfen.

Oder man paßt die Zahl der erlaubten ausstehenden IO Requests oder die Queue Length der verwendeten HBA's, sofern das SAN Array der Engpass ist.

Gruß
Ralf

[rutz]

Hallo,

also zu den Platten.

Also gnerell kommen eigentlich alle aus unserem SAN Bereich.

Meist sind die Platten ca. 750 GB groß und da kann es durchaus sein dass mehrere VM aus diesem Pool Ihre Standardplatten bekommen. Ist das Generell immer ein Problem beim Plattenzugriff?

Bei den SAP Systemen selbst sind die VM so konfiguriert das die System Platten einen SCSI Controller bekommen haben, die normale Datenplatte einen eigenen SCSI Controller und die RAw-Platte ebenso auf einen eigenen SCSI Controller definiert wurde.

Generell sind die Datenbankplatten (wo die DB2 Datenbank) drauf liegt per SAN erstmal an jeden ESX-Server angebunden, damit diese sichtbar ist für ggf. VMotion. Jedoch der Zugriff direkt in die VMWare immer dann Virtuell durchgeschleift wird auf die LUN der SAN-Platte.

Das mit den NTFS allignen müsste ich mal nachlesen, weil bisher hab ich eigentlich mit dem Standard anlegen keinerlei Probleme gehabt innerhalb der VM. Wobei mit SAP unter VM noch keine Erfahrungen existieren.

Dann werd ich mich mal weiter schlau machen.

Generell gibt es in SAP anscheinend eine Transaktion zum schauen von Lanauslastung und Pakete und da gibt es anscheinend bei "LAN-Fehler Aus (pro Sek)" immer 360 und das ist gegenüber älteren wo noch auf physischer Hardware laufen lt. Aussage ungewöhnlich, da dort immer 0 ist.

Bei VMotion kommt es eigentlich zu keinen Problem, da VMotion momentan nicht genutzt wird in dem Cluster. Sprich hier die Ressourcen eigentlich ausreichen.

[kastlr]

Hallo,

je mehr Hosts auf eine shared Disk zugreifen, desto größer ist die Chance, das einer dieser Hosts den Zugriff auf die Disks kurzfristig mit einer SCSI Reservation blockiert.
Dies ist kein Problem, da damit die Konsistenz des Filesystem gewährleistet werden soll.
Aber in diesem Zeitraum kann halt kein anderer Server an die Disk, alle IO's von anderen ESX Servern müssen warten.
Das kann zu Performance Problemen führen.
Eigentlich sollten diese Reservierungen nicht oft genutzt werden, aber das hängt natürlich auch von deiner speziellen Umgebung und ihrer Nutzung ab.

Das Thema Filesystem Allignment unter Windows ist schon ziemlich alt.
Sofern du die Partitionen nicht mit dem Tool diskpar.exe angelegt hast, sind diese garantiert nicht alligned.
Erst mit W2K8 hat MS dieses Verhalten geändert.
Zu diesem Thema müßtest du reichlich Informationen von deinem SAN Vendor erhalten.

Mit "LAN Fehler Aus (pro Sek)" kann ich leider gar nichts anfangen, das könnte alles Mögliche bedeuten.
Allerdings müßtet Ihr ein Wahnsinns LAN euer eigen nennen, wenn eure SAP Applikation bei 360 Fehlern pro Sekunde immer noch mit der DB kommunizieren kann.
Zumindest müßte das LAN/der Server/die Applikation diesen Fehler innerhalb von ca. 2ms erkennen, damit du in dieser Sekunde überhaupt noch ein paar TCP/IP Packete senden/empfangen kannst.

Frag Ihn doch einfach mal nach dem Durchsatz pro Sekunde, der müßte dann ja annähernd 0 sein.
Dann müßten aber auch alle SAP User auf die Barikaden gehen, schließlich erhalten Sie Ihre Daten ja vom Applikationsserver, der sich die Daten wieder aus der Datenbank holen muß.
Bei einem Performance oder Connectivity Problem zwischen SAP und DB Server würden das alle SAP User sofort merken.

Daher glaube ich persönlich, das euer SAP Mensch mal auf Gut Glück versucht hat, dir den schwarzen Peter zuzuschieben.

Bin schon gespannt, wie's weitergeht.
Gruß
Ralf