Hallo Gemeinde,
ich habe eine Problem und komme einfach nicht weiter.
Wir haben ca 20 ESX 4 Host´s im SAN. Ca. 10TB sind über Datacore San Symphony an die Server gemappt.
Seit ca. 4 Wochen beschweren sich die Anwender über die schlechte Performance.
Die ESX Server sowie die VM´s haben keine Probleme (RAM, CPU).
Der Zugriff auf das Storage ist als Fehler identifiziert.
Leider ist aus sicht den SAN alles "Grün". Keine Fehler wurden gefunden.
Was mich nur sehr wundert. Wenn ich in der Serviceconsole mit DD ein File kopiere (In der selben LUN) erreiche ich Werte von 2-5MB/s. Wenn ich ein lokales VMFS Volume benutze komme ich auf Werte von ca. 50MB/s. Mein Kollege (AIX Admin) erreicht auf der selben LUN ca. 30MB/s
Hat jemand eine Idee (Langsam bin ich ratlos!!!!!!)
Danke
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Performance Probleme im SAN
-
irix
- King of the Hill
- Beiträge: 13063
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Messaktionen innerhalb der COS sind Aufgrund der sehr limitierten Resourcen selbiger nicht Aussagekraeftig. Noch schlimmer wird es wenn man mit den Linux Boardmitteln auf einem VMFS arbeitet.
Wenn du schon in einem VMFS herumkopierst dann benutze vmkfstool damit der ESX Kernel entsprechend optimieren kann beim arbeiten mit VMFS.
Ich aber wuerde aus einer VMs heraus mal IOmeter anschmeissen und gucken was da fuer Werte herausfallen.
Wie haben fuer sowas einei Arbeits VM und speichern die Statistik regelmaessig und gucken auch nach Umbauten immer mal wieder nach und vergleichen die Werte.
Gruss
Joerg
Wenn du schon in einem VMFS herumkopierst dann benutze vmkfstool damit der ESX Kernel entsprechend optimieren kann beim arbeiten mit VMFS.
Ich aber wuerde aus einer VMs heraus mal IOmeter anschmeissen und gucken was da fuer Werte herausfallen.
Wie haben fuer sowas einei Arbeits VM und speichern die Statistik regelmaessig und gucken auch nach Umbauten immer mal wieder nach und vergleichen die Werte.
Gruss
Joerg
Mein Fehler
Ja, ich glaube mit DD zu kopieren war eine schlechte Idee (Dafür ist das VMFS Dateiformat ja nicht geeignet)
Die Datei wird mit "DD" ja langsam aufgebaut. Somit entstehen SCSI Konflikte!
Die Datei wird mit "DD" ja langsam aufgebaut. Somit entstehen SCSI Konflikte!
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
ein dd ist ein denkbar schlechter Performance Test, schließlich handelt es sich hierbei um eine single thread Applikation.
SAN Arrays sind aber darauf ausgelegt, mehrere parallele Threads zu bedienen.
Was hat sich denn vor 4 Wochen geändert?
So eine Umgebung ist ja nicht aus dem Nichts entstanden, sondern hat sich im Laufe der Zeit ergeben.
Und wie kommst du überhaupt zu der Erkenntniss, das der Storage als Verusacher eures Problems feststeht?
Schließlich kommst du im selben Thread mit der Info, das dein AIX Admin auf der selben LUN 30 MB/s Transferrate hinbekommt.
Denn eigentlich ist dem Storage egal, ob dort ein Windows, ESX oder AIX Hosts seine IO's loswerden möchte.
Da du bisher mit Informationen sehr sparsam umgegangen bist, können wir dir auch nur bedingt helfen.
Überprüfe bzw. beantworte mal folgende Punkte & Fragen
Gruß
Ralf[/list]
ein dd ist ein denkbar schlechter Performance Test, schließlich handelt es sich hierbei um eine single thread Applikation.
SAN Arrays sind aber darauf ausgelegt, mehrere parallele Threads zu bedienen.
Was hat sich denn vor 4 Wochen geändert?
So eine Umgebung ist ja nicht aus dem Nichts entstanden, sondern hat sich im Laufe der Zeit ergeben.
Und wie kommst du überhaupt zu der Erkenntniss, das der Storage als Verusacher eures Problems feststeht?
Schließlich kommst du im selben Thread mit der Info, das dein AIX Admin auf der selben LUN 30 MB/s Transferrate hinbekommt.
Denn eigentlich ist dem Storage egal, ob dort ein Windows, ESX oder AIX Hosts seine IO's loswerden möchte.
Da du bisher mit Informationen sehr sparsam umgegangen bist, können wir dir auch nur bedingt helfen.
Überprüfe bzw. beantworte mal folgende Punkte & Fragen
- - Anzahl VM's pro LUN?
- Failover Policy für alle LUN's auf allen Servern?
- Betrifft es alle VM's oder nur einige?
- Welche CPU Ready Werte haben die betroffenen VM's?
- Wie sieht es mit Swapping aus (VM und/oder ESX)?
- Was bringt ein esxtop bei Verwendung des Parameters d?
Gruß
Ralf[/list]
Re: Performance Probleme im SAN
f12345 hat geschrieben:Der Zugriff auf das Storage ist als Fehler identifiziert.
Leider ist aus sicht den SAN alles "Grün". Keine Fehler wurden gefunden.
VMware kann man wohl ausschließen, da sollte man eher an anderer Ecke suchen.
Performance
Ich versuche jetzt mal mehr Infos zu schreiben.
Wir benutzen SANSymphony 6.0.3 Update4 (Mit 4 SDS Servern)
Der Storage Pool ist 10TB groß (Exklusiv für VMware)
Datacore spiegelt die 10TB über 2 Rechenzentren
Storage im SAN gesammt 50TB (Fast alles über Datacore)
14SAN Switche in 2 Fabrics
Laut Datacore Auswertung komme ich mit Vmware auf 5000 I/O/s
Im vCenter werden ca. 300 VM´s verwaltet. ca. 250 Vm´s sind in unserem SAN.
Gesichert werden die VM´s über einen lokalen TSM Clienten. Gleichzeitig habe ich noch einen VCB Proxy. Dieser soll monatlich alle VM´s auch ins TSM sichern. Momentan musste ich die VCB Proxy Sicherung ausplanen. (Wegen der aktuellen Probleme)
Was ist passiert? Das ist leider schwer zu sagen. Vor ca. 2 Monaten habe ich alles ESX Server von 3.5 auf 4.0 migriert.
Was leider sehr auffällig ist, im Performance Counter auf ALLEN ESX Server sehe ich stündlich 2 Peak´s . Latency bis zu 1500ms.
Leider können wir nicht identifizieren wer oder was die Peaks erzeugt.
Ein Call bei Datacore, VMware, Hitachi ist offen. Keiner kann sich die Probleme erklären.
In der Vergangenheit habe ich mich noch nie mit diesem Theama beschäftigt da ich noch nie Probleme mit der Performance unter ESX hatte. (Angefangen habe ich mit der Version 2.5)
In einer VM habe ich den IOMeter aum laufen. Ich benutze die Default Einstellung mit 100% lesenden Zugriff. Schreibender Zugriff kann nur schwerlich gemessen werden, da es über die SDS´s ja komplett in dem Cache abgefangen wird.
Die I/O Werte von IOMeter im meiner VM schwanken zwichen 80-115 I/O´s.
Wenn dich dieselbe VM auf einen lokalen Storage kopiere bekomme ich von IOmeter ca. 200 I/O´s.
Ich habe vor einem Jahr eine kleine Vmware SAN Umgebung in Shanghai aufgebaut. Hier erziehle ich mit IOmeter ca. 190 I/O´s.
Bei lokalem Storage sowie im SAN Shanghai habe ich jedoch wesentlich bessere Latenzwerte.
Ich hoffe ich konnte mit diesen knappen Worten ein wenig Licht ins dunkel bringen.
Wir benutzen SANSymphony 6.0.3 Update4 (Mit 4 SDS Servern)
Der Storage Pool ist 10TB groß (Exklusiv für VMware)
Datacore spiegelt die 10TB über 2 Rechenzentren
Storage im SAN gesammt 50TB (Fast alles über Datacore)
14SAN Switche in 2 Fabrics
Laut Datacore Auswertung komme ich mit Vmware auf 5000 I/O/s
Im vCenter werden ca. 300 VM´s verwaltet. ca. 250 Vm´s sind in unserem SAN.
Gesichert werden die VM´s über einen lokalen TSM Clienten. Gleichzeitig habe ich noch einen VCB Proxy. Dieser soll monatlich alle VM´s auch ins TSM sichern. Momentan musste ich die VCB Proxy Sicherung ausplanen. (Wegen der aktuellen Probleme)
Was ist passiert? Das ist leider schwer zu sagen. Vor ca. 2 Monaten habe ich alles ESX Server von 3.5 auf 4.0 migriert.
Was leider sehr auffällig ist, im Performance Counter auf ALLEN ESX Server sehe ich stündlich 2 Peak´s . Latency bis zu 1500ms.
Leider können wir nicht identifizieren wer oder was die Peaks erzeugt.
Ein Call bei Datacore, VMware, Hitachi ist offen. Keiner kann sich die Probleme erklären.
In der Vergangenheit habe ich mich noch nie mit diesem Theama beschäftigt da ich noch nie Probleme mit der Performance unter ESX hatte. (Angefangen habe ich mit der Version 2.5)
In einer VM habe ich den IOMeter aum laufen. Ich benutze die Default Einstellung mit 100% lesenden Zugriff. Schreibender Zugriff kann nur schwerlich gemessen werden, da es über die SDS´s ja komplett in dem Cache abgefangen wird.
Die I/O Werte von IOMeter im meiner VM schwanken zwichen 80-115 I/O´s.
Wenn dich dieselbe VM auf einen lokalen Storage kopiere bekomme ich von IOmeter ca. 200 I/O´s.
Ich habe vor einem Jahr eine kleine Vmware SAN Umgebung in Shanghai aufgebaut. Hier erziehle ich mit IOmeter ca. 190 I/O´s.
Bei lokalem Storage sowie im SAN Shanghai habe ich jedoch wesentlich bessere Latenzwerte.
Ich hoffe ich konnte mit diesen knappen Worten ein wenig Licht ins dunkel bringen.
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
über welche Anzahl LUN's reden wir denn nun?
Bei ca. 300 VM's wirst du ja so ungefähr 500 virtuelle Disks im Einsatz haben.
Daher wäre es schon von Bedeutung zu sehen, wie sich deren Last auf der physikalischen Ebene verteilen.
Weiterhin solltest du mal die Multipath Einstellungen überprüfen, ob du bereits auf Round Robin bist.
Die klassische Einstellung erfordert nämlich die Manuelle Verteilung der LUN's über die vorhandenen HBA's, solltest du daran nichts geändert haben, wird einer deiner HBA's die ganze Arbeit machen müssen.
Eine Latency von 1500ms ist höchstwahrscheinlich wieder mal völliger Blödsinn, mit Sicherheit machst du während dieses Zeitraums deutlich mehr als 1 IO/s auf dem entsprechenden ESX Server.
Klagen deine User denn immer nur zu diesen Zeiten über eine mangelhafte Performance oder generell?
Bei deiner Umgebung vermute ich einfach mal, das du zu wenige LUN's konfiguriert hast.
Mit den Standardeinstellungen verwendest du einen HBA Queue Depth von 32, somit kann jeder HBA maximal 32 ausstehende IO's handhaben.
Sobald dieser Wert überschritten ist, wartet der VMkernel auf einen freien Slot.
Wenn du jetzt nur wenige LUN's im Einsatz hast, müssen diese sich die ganze Last teilen.
Sollte das aber nicht immer so gelingen, bremst das eventuell den/die ganzen Hosts aus.
Viel Erfolg,
Ralf
über welche Anzahl LUN's reden wir denn nun?
Bei ca. 300 VM's wirst du ja so ungefähr 500 virtuelle Disks im Einsatz haben.
Daher wäre es schon von Bedeutung zu sehen, wie sich deren Last auf der physikalischen Ebene verteilen.
Weiterhin solltest du mal die Multipath Einstellungen überprüfen, ob du bereits auf Round Robin bist.
Die klassische Einstellung erfordert nämlich die Manuelle Verteilung der LUN's über die vorhandenen HBA's, solltest du daran nichts geändert haben, wird einer deiner HBA's die ganze Arbeit machen müssen.
Eine Latency von 1500ms ist höchstwahrscheinlich wieder mal völliger Blödsinn, mit Sicherheit machst du während dieses Zeitraums deutlich mehr als 1 IO/s auf dem entsprechenden ESX Server.
Klagen deine User denn immer nur zu diesen Zeiten über eine mangelhafte Performance oder generell?
Bei deiner Umgebung vermute ich einfach mal, das du zu wenige LUN's konfiguriert hast.
Mit den Standardeinstellungen verwendest du einen HBA Queue Depth von 32, somit kann jeder HBA maximal 32 ausstehende IO's handhaben.
Sobald dieser Wert überschritten ist, wartet der VMkernel auf einen freien Slot.
Wenn du jetzt nur wenige LUN's im Einsatz hast, müssen diese sich die ganze Last teilen.
Sollte das aber nicht immer so gelingen, bremst das eventuell den/die ganzen Hosts aus.
Viel Erfolg,
Ralf
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 25 Gäste