“Disk yavaş” tespitini duyduğumuzda önce hangi işlemin, ne zaman ve ne kadar yavaşladığını netleştirelim. Bir raporun on dakika geç bitmesiyle bütün sanal makinelerin aynı anda donması farklı kapsamlar taşır. Teşhise depolama ayarlarını değiştirerek başlamak, eldeki kanıtı da bozabilir.
Etkilenen alanı daraltalım
İlk sorular oldukça basit: Sorun tek uygulamada mı, aynı datastore üzerindeki makinelerde mi, bir hostta mı, yoksa bütün ortamda mı? Başlangıç zamanı belli mi? O sırada yedekleme, toplu veri aktarımı, snapshot konsolidasyonu veya planlı bakım var mı?
Bu bilgileri kısa bir zaman çizelgesine yazın. Saat dilimlerini ve ölçüm aralıklarını eşitleyin. Bir dakikalık host grafiğini saatlik depolama ortalamasıyla karşılaştırmak, kısa süreli sorunu görünmez hale getirebilir. Ekran görüntüsünün yanına mümkünse ham ölçüm aralığını da kaydedin.
Gecikmenin ölçüldüğü noktayı anlayalım
VMware ortamında esxtop, depolama gecikmesini farklı katmanlarda gösterir. Broadcom'un sayaç açıklamalarında DAVG cihaz sürücüsü seviyesindeki gecikmeyi, KAVG ESX çekirdek katmanındaki gecikmeyi, GAVG ise bu ikisinin toplamını temsil eder. QAVG, KAVG içinde yer alan kuyruk gecikmesidir. Bunlar ölçüm aralığındaki ortalamalardır.
DAVG yüksekse depolama sistemi ve ona giden yol üzerindeki verilerle karşılaştırma gerekir. KAVG belirgin yükseliyorsa host tarafındaki bekleme ve kuyruk davranışları incelenir. Tek bir sayaçtan kesin arıza ilan etmek yerine, aynı anda değişen diğer işaretleri arayın.
IOPS tek başına yeterli açıklama vermez
Aynı işlem sayısı farklı istek boyutları, okuma-yazma oranları ve erişim düzenlerinde farklı yük oluşturabilir. Bu yüzden IOPS ile birlikte aktarım miktarını, istek türünü, gecikmeyi ve kuyruk durumunu kaydedin. Uygulamanın kendi işlem süresini de bu zaman çizelgesine ekleyin.
Broadcom'un yüksek depolama gecikmesi örneği, DAVG, KAVG ve GAVG artışına kuyruk ve kullanım göstergelerinin eşlik edebildiğini gösteriyor. Kendi ortamınızda karşılaştırma için sağlıklı bir günün aynı saatini seçmek yararlı olur. Her sistem için geçerli tek bir milisaniye sınırı kabul etmeyin; uygulamanın ihtiyacını ve olağan davranışını esas alın.
Hipotezi küçük bir kontrolle sınayalım
Örneğin gecikmenin yalnızca yedek penceresinde arttığını gördünüz. Bu, ilişki gösterir; tek başına nedeni kanıtlamaz. Yedek işinin görev dağılımı, eşzamanlılığı ve storage tarafındaki yükü birlikte inceleyin. Onaylı bakım aralığında tek bir değişkeni kontrollü değiştirmek, birden fazla ayarı aynı anda değiştirmekten daha açıklayıcıdır.
Üretimde hazırlıksız yük testi çalıştırmayın. Kuyruk derinliği, yol politikası veya cache ayarı gibi değişiklikler üretici önerisi, etki değerlendirmesi ve geri dönüş planıyla ele alınmalı. Okuma amaçlı ölçümün yeterli olduğu aşamada yapılandırmaya dokunmak gerekmez.
Sonucu tekrar ölçerek kapatalım
Çözümden sonra sadece host grafiğinin düzelmesine bakmayın. Etkilenen iş akışını aynı yöntemle ölçün, karşılaştırma penceresini not edin ve başka iş yüküne sorun taşınmadığını kontrol edin. Kayıtta belirti, kanıt, yapılan değişiklik ve sonuç birlikte bulunsun. Bir sonraki benzer olayda hangi katmandan başlayacağımızı bu kayıt belirler.
Yorumlar (0)
Henüz onaylanmış yorum yok.