Ik heb al eerder aangegeven in dit topic dat we connectivity issues hebben met een Exchange 2010 omgeving op vmware:
viewtopic.php?f=52&t=5949

Aangezien dat topic niet door mij is gestart leek het mij netjes een nieuwe aan te maken.

Inmiddels een case uit gezet bij vmware. Die zeiden dat het door disk latency kwam. Nu lijkt me dat sterk maar toch pogingen gedaan om de latency enigszins te verbeteren.

Nu is deze case inmiddels gesloten maar het probleem speelt nog steeds.

Inmiddels hebben we wat tests uitgevoerd in met client pc's in meerdere subnets. Want vermoedens bestonden dat het aan of de firewall of de loadbalancer zou kunnen liggen.

Na een test met een outlook client in hetzelfde lan als de loadbalancer, nog steeds dezelfde connectivity issues.
Na een test met een outlook client in hetzelfde lan als de Exchange servers ook nog steeds dezelfde connectivity issues (In deze setup worden dus LB en FW gepasseerd).

Ik begin nu dus toch te vermoeden dat het ergens op vmware spaak loopt, de issues treden bijna allemaal op alle clients tegelijkertijd op maar er zit geen logische tijdinterval tussen.

De default MTU op een vswitch staat op 1500 maar is deze setting in combinatie met Exchange2010 een logische? Wat kan ik nog doen?

Want ?
Hoe ?
Heb je al eens wat metingen gedaan met bijv. SQLIO (<- link) ? Ik kom toch zeer regelmatig issues tegen die allemaal toe te wijzen zijn aan een te kort aan IO's en/of het overlopen van (cache)queue's.

@Dukebox: Het lijkt mij sterk omdat vmware die mening heeft gebaseeerd over meldingen in de vmkernel log. Daar stond iets van "performance detoriated" Maar dat kunnen net zo goed backups of storage vmotions zijn geweest. In ieder geval zie ik tussen de latency en de connectivity issues geen gelijke interval.

Ik zal zeker die SQLIO een keer runnen, thanks btw. Maar hoe stel ik vast wat bij bij Exchange de absolute ondergrens qua IO?

De ondergrens kan je alleen vaststellen door te kijken wat nu je max is met bijv. SQLIO en wat exchange doet (dus monitoren en voornamelijk de pieken bekijken)

Wat voor disk latency zie je op de ESX(i) hosts?
Check dit bijvoorbeeld met ESXTOP of de performance counters binnen vCenter.

Als is met esxtop -u kijk dan zie ik op de datastores waar de system disks van Exchange op staan een latency gemiddeld tussen de 1 - 10 ms met af en toe flinke pieken tot boven de 100ms maar dat zijn enkele uitschieters.

100ms + duidt dus duidelijk op een mogelijke timeout / buffer underrun.

Zie hier Latancy grafiekje, zorgelijk?

550ms+.. ja ! Ik vind het helemaal wat aan de hoge kant.. als snel 20ms gemiddeld aan het begin.
Had je deze al eens bekeken ? http://www.vmware.com/files/pdf/techpap ... 1-SIOC.pdf
Neem aan dat al je OS volumes e.d. netjes aligned zijn ?

Gebruikte OS is W2K8R2, dat is toch altijd al aligned?

Klopt Windows 2008 aligned standaard, dat hoef je dus niet zelf meer te doen.
Overigens ben ik het met DukeBox eens dat de latency aan de hoge kant is.

raar tijdstip ook die piek van 550ms.. 20:05..misschien een backup die ergens anders gestart wordt..?
is die lateny grafiek afkomstig uit vcenter...? (sorry heb nog geen laatste versie van vcenter grafieken gezien so just wondering. )

_________________
visit my techblog at:
http://www.virtualistic.nl

@Dukebox: Ik heb SIOC bekeken maar in hoeverre dit effect zal hebben op een datastore met maar twee vm's? Het maakt het wel inzichtelijk dat wel.

Het zijn W2K8 machines, dus geen handmatige allign nodig.

@alphenit: Backup is goed mogelijk, en ja idd een grafiek uit vcenter.

Of updates AV? (of inderdaad backup)

In dit geval zou het ook op andere datastores moeten pieken

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

@Sdaems: En dat doet het ook

Tot nu toe:

Case vmware -> vmware omgeving is goed
Case HP -> Storage boxen zijn goed -> Subcase ISCSI Network switches, onderzoek gaande naar switch performance voor latency op sommige datastores.
Case F5 -> Loadbalancers zijn goed

Wat betreft Exchange:
Cas/Array servers in het zelfde LAN geplaatst als de Domain controllers en tot nu toe geen issues meer gehad.