[Çözüldü] Vmware ve sanallarda yavaşlık hk.

Gönderen: @balanar

↑

Merhaba,

Bugüne kadar hiçbir sorun yaşamadık 3 senedir. Herhangi bir değişiklikte yapmadık.

Dün sabahtan beri tüm sanal makinelerimizde bir yavaşlık var. Windowslara bağlanacağım makinenin kendine gelmesi 5dk sürüyor. Bazen daha uzun. Makinelerde başlata basıyorsunuz 2-3 dk kendine gelemiyor. Linux tarafında çalışan otomasyonlarda sorgu yapmaya kalktıgımızda PHP tarafında 5dk döndürüyor.

Sunucu ile storage alt alta fiziksel olarak herşey çalışıyor. Sorun ne olabilir? VMware ESXi 7.0.3 versiyonu mevcut.

Neyi gözden kaçırıyor olabilirim neyi kontrol etmeliyim? Tecrübe üstadlarımızdan destek bekliyorum..

Merhaba,

Öncelikle performance monitor'u kontrol etmeniz gerekiyor. Mevcut sanal sunucularınızdan birtanesi bir sebepten dolayı yüksek IO yapıyor olabilir. Veya storage'ınız üzerinde disk arızası olabilir ve bundan dolayı storage'da bir performans kaybı olabilir. 

Tayfun bey peki, storage disk arızası olsa hem fiziksel olarak hemde sistemde uyarı vermezmi? Çünkü sistemden baktığımda herşey normal görünüyor health ok

Gönderen: @balanar

↑

Tayfun bey peki, storage disk arızası olsa hem fiziksel olarak hemde sistemde uyarı vermezmi? Çünkü sistemden baktığımda herşey normal görünüyor health ok

Eğer storage üzerinde bir uyarı vs görmüyorsanız ozaman mevcut sanal sunucularınız içerisinde birtane VM yüksek IO yapıyor ve storage'ı darboğaza sokuyor olabilir. Bazen sanal sunuculara bulaşan virüsler bunlara sebep olabiliyor.

Örneğin;

2025-03-28T04:44:20.561Z cpu7:2098383)WARNING: ScsiDeviceIO: 1513: Device naa.600c0ff000663da046788a6301000000 performance has deteriorated. I/O latency increased from average value of 815 microseconds to 187972 microseconds.
2025-03-28T04:44:26.483Z cpu10:2098383)WARNING: ScsiDeviceIO: 1513: Device naa.600c0ff000663da046788a6301000000 performance has deteriorated. I/O latency increased from average value of 816 microseconds to 381907 microseconds.
2025-03-28T04:44:33.357Z cpu39:2098381)WARNING: ScsiDeviceIO: 1513: Device naa.600c0ff000663da046788a6301000000 performance has deteriorated. I/O latency increased from average value of 816 microseconds to 149909 microseconds.
2025-03-28T04:44:54.579Z cpu20:2098383)WARNING: ScsiDeviceIO: 1513: Device naa.600c0ff000663da046788a6301000000 performance has deteriorated. I/O latency increased from average value of 816 microseconds to 25618 microseconds.
2025-03-28T04:44:55.944Z cpu13:2098381)WARNING: ScsiDeviceIO: 1513: Device naa.600c0ff000663da046788a6301000000 performance has deteriorated. I/O latency increased from average value of 816 microseconds to 57389 microseconds.
2025-03-28T04:44:59.163Z cpu51:2098383)WARNING: ScsiDeviceIO: 1513: Device naa.600c0ff000663da046788a6301000000 performance has deteriorated. I/O latency increased from average value of 816 microseconds to 124009 microseconds.

2025-03-28T04:44:23.804Z cpu100:2098386)WARNING: ScsiDeviceIO: 1513: Device naa.600c0ff000663da084b08a6301000000 performance has deteriorated. I/O latency increased from average value of 969 microseconds to 22092 microseconds.
2025-03-28T04:44:26.843Z cpu15:2098387)WARNING: ScsiDeviceIO: 1513: Device naa.600c0ff000663da00121fc6601000000 performance has deteriorated. I/O latency increased from average value of 3328 microseconds to 71939 microseconds.
2025-03-28T04:44:27.141Z cpu15:2098387)WARNING: ScsiDeviceIO: 1513: Device naa.600c0ff000663da084b08a6301000000 performance has deteriorated. I/O latency increased from average value of 969 microseconds to 47604 microseconds.

doğru yere bakıyorum değil mi tayfun bey? Hangi makienin bunu yaptığına nasıl erişebilirim?

Evet zaten warning atmış durumda. Bu uyarı, storage'in IO'yu karşılayamadığı anlamına geliyor. Her sunucunun task manager'indan disk değerlerini inceleyebilir veya esxi/vcenter üzerinden performance monitor > disks bölümünden read7write değerlerini kontrol edebilirsiniz.

Gönderen: @tayfundeger

↑

Evet zaten warning atmış durumda. Bu uyarı, storage'in IO'yu karşılayamadığı anlamına geliyor. Her sunucunun task manager'indan disk değerlerini inceleyebilir veya esxi/vcenter üzerinden performance monitor > disks bölümünden read7write değerlerini kontrol edebilirsiniz.

Bu alanda göremedim veya yanlış yerden bakıyorum. Müsaitlik durumunuz varsa tam olarak nereden bakılacağı noktasında tarif etmeniz mümkün mü tayfun bey. Yaklaşık 36 saattir uykusuz duruyoruz, bakan kör olmuşuz..

Ben güncel vcenter'a hakim değilim sadece fikir verebilirim.
Bu ekranlardan net durum tespit edilemiyorsa log temelli bakmak lazım. O tepe noktalarına vuran vm'i tespit edip o vm içerisinde ki perf. durumunu analiz edin.
Tayfun hocamın dediği gibi storage bir şekilde IO taşıran bir şeylere yetersiz kalıyor. Storage'in cpu ve bellek kullanımını da kontrol edin, log'larını inceleyin mesela bir şekilde parity işlemi yapıyorsa healty görünür herşey ama perf. sürünür.
Güç isteyen VM'lerinizin de sadece task manager dan değil Resource monitor yapın birinin OS'undan kaynaklanan bir şeyden olabilir o zaman vcenter ekranlarına bariz yansımayabilir.
Daha nokta atış yorumları Tayfun hoca müsait olduğunda yapacaktır.

Merhaba, Tayfun ve İbrahim hocam aslında nokta atışı bilgi vermiş. Loglarda da göründüğü gibi bir şey size aşırı yük bindiriyor ve storage üniteniz bunu kaldıramıyor. Bunu tespit etmek için 3. parti izleme ürünleri kullanabilirsiniz. Solarwinds, PRTG vb, ancak durum bu kadar kötü ise yani tüm sistem bundan etkileniyor ise muhtemel bu ürünlerde doğru düzgün log toplayamayabilir. Ancak bu işin en doğrusu tüm sistemin izlenmesi. Gördüğüm kadarı ile sizde herhangi bir izleme aracı yok. Bu tür altyapılar için öncelikle server,storage ve vmware katmanını izleyen bir ürün + sanal makineleri izleyen ayrı veya benzer bir performans monitoring ürünü olmalı. Neden bu katmanlar ayırıyoruz? Örneğin sizdeki gibi bir durumda windows veya linux ortamındaki performans ürünleri doğru sonuç vermez, çünkü OS katmanında yüksek CPU veya RAM kullanımı yoktur, olmamasının sebebi ise (bazen de storage geç cevap verdiği için tam tersi yüksek cpu kullanımı görürsünüz, özetle bunu incelemek zaten uzmanlık isteyen bir iştir) storage gecikmesi kaynaklı aslında OS response alamadığı için kaynak da tüketemez vs. Ama bunu zaten siz OS de canlı canlı yaşamışsınız. Zaten sorunun alt katmandaki storage performans yetersizliği olduğu da belli. Peki bu kadar performans isteyen kim? Ürün yok ise eğer öncelikle loglardaki naa ID lerine bakarak bunların LIN veya datastore olduğunu düşünürseniz bu uyarıları hangi LUN, Data store için verdiğine bakın.Eğer bir kolerasyon bulursanız yani örüntü, en çok şu ID de oluyor gibi ona yoğunlaşın. Örnek bir kod, ID' den datastore' a dönün

esxcli storage core device list | grep -A10 naa.600c0ff000663da046788a6301000000

Sonra bu datastore üzerindeki sanal makineleri bulun

vim-cmd vmsvc/getallvms | grep "Sorunlu_Datastore_Adı"

Sonra bu makinelerden şüphelendikleriniz var mı kontrol edin, veya onlara izleme programı kurun trial da olsa veya kapatabilyorsanız kapatın. O anda yine erişiminiz var ise ESXi ssh ile bağlanıp aşağıdaki komut ile en fazla I/O tüketen sanal makineyi bulabilirsiniz

esxtop

Burada Tayfun hocam' ın makalesi var

ESXTOP Kullanımı - ÇözümPark

Eğer sorunu bu şekilde de çözemiyorsan dediğim gibi profesyonel bir yardım almanı öneririm.

Hepinize çok teşekkür ediyorum profesyonel bilgiler için..

Birkaç disk'te meta clear işlemi vs yaptılar yurtdışından. Rebalance tamamlandıktan sonra düzeldi herşey

Ama hâla kafamda soru işaretleri var tabi. Hakan hocam tayfun beyin paylaşımına bakacağım çok faydalı olacak.. Çok sağolun

Merhaba, geri dönüş ve bilgi için teşekkürler, yani sorun storage üzerinde çıktı? Disklerdeki yoğunluk nedeni ile gecikme oluyordu, support case açtın, yurt dışından bağlandılar ve bunu tespit ettiler? Süper, geçmiş olsun. İyi çalışmalar.

Hakan hocam sorun tekrarladı.

Şuanda 19 SSD göreceğine 21 görüyor. Yurtdışından baglandilar firmware update işlemleri gerçekleştirdiler. Storage tarafını taşıyıp yeniden volume vs oluşturun diyorlar.

Pool A (ssdler) adapt

Pool B (hddler) raid6

Bu şekilde istiyorlar anladığım kadarıyla. Daha önce hepsi pool A tarafındayı. Ne alaka noluyor bizde çözemedik 🙁

Sizin buraya aktarabildikleriniz çok kısıtlı ve önceki yaptıklarını söylediğiniz şeyler de çok net anlaşılır değil.
Peki siz sorduğunuzda sorunun kaynağı, istenen aksiyonların nedenlerini anlatmıyorlar mı? Daha fazla detay alabilmeniz konuyu anlamanız lazım sonuçta cihazın durumunu, yapılandırmayı gören onlar. Yani ne diyorlarsa sorgulayıp uygulayın ama anlamanız önemli.

SSD ve HDD'ler aynı pool'da olur mu olur tiering konusudur. Cihaz, sürüm, yapılandırma bağımlıdır. Sizin sorun değişenler ve hot data'nın HDD'lere denk gelmesi kaynaklı olabilir. Ve HDD’lerin yüksek gecikmesi tüm SSD performansını yavaşlatır, IO sorunları oluşur yani storage sürünür.
Pool'un ayrılmasını istemelerinin nedenleri önemli.
Fiziksel 21 SSD varsa sorun kaynaklı hot swap'ların da dahil görünmesi kaynaklı olabilir.

İbrahim hocam güzel özetlemiş, SSD ile HDD aynı pool da olması çoğu zaman kabul görmez, ama boş bir storage yok ise işiniz zor, bu kadar veriyi bir yere çıkarmalı ve yeniden kurmanız gerekli.

Verileri taşıyıp yeniden yapılandırdılar fakat bana hâla ağır geliyor. Fakat bu ağırlık Scrub işleminden mi kaynaklı bilemedim.

Şimdi bu yapı yanlış o zaman?

Archive'nin Pool B'de mi olması gerekiyor?

Geri dönüş için teşekkürler. Evet, muhtemelen ondandır.
Ben tekrarı öneririm sizin bu soruları o cihazı bakanlara sormanız lazım, cihazı, sizi bilen onlar niçin o yapılandırmaya gidildiğini analiz edebilirler. Burada gerekli hiçbir detay yok.
Biz sadece genel geçerli cevapları verebiliriz bu durumda.

Dediğim gibi farklı disk sığa ve modelleri farklı array fakat aynı pool'da olur mu olur, buna tiering denir. Bunu cihaz model doc'larından inceleyebilirsiniz. Bu genel geçer bir konu değil cihaz bağımlı bir konu. O yüzden elinizde support varken en iyi yolu onlarla yürümeniz, gerekirse bir handikap konu varsa geleceğe bırakmadan şimdi operasyonu planlayarak düzeltme yada baştan yapılandırmaya gitmenizdir.
Ben zaten tiering ve storage uzmanı değilim bunlar marka, model bazlı öğrenilmesi gereken konular.
Fakat Hakan abinin dediği gibi de özellikle uzun vade için ayrı pool'lar ile yapılandırmaya gidilebilir bazen support edilse bile, uzmanın deneyimine de bağlı çünkü yaşadığınız gibi uzun vade de hot ve cold data konumları bir kere karıştı mı en başta sorduğunuz gibi sonuç verebilir, o süreçlerin arka planda bitmesi günler hatta haftalar sürebilir. Raid array'ler böyle yapılar arka planda sürekli devasa ERC işlemleri yaparlar ve bazen sistemin aldığı düzeltme aksiyonları uzun vade de bu tür durumlarla karşılaşılmasına sebep olur ayrı pool tercih edilir.

Pool'ların ayrımı ciddi bir iş yine o kararı o uzmanların danışmanlığında almaya çalışın derim. 

* dün gece yazdıklarım tam da kesintiye denk geldi birşeyler daha yazmıştım ama kaybolmuş revizyonlardan bunlar kalmış maalesef, hatırlamıyorum da ne demiştim.

Teşekkür ederim İbrahim bey bilgiler için..