[TR] HPE StoreOnce Catalyst Store’da Housekeeping Performans Sorununun Analizi ve Çözüm Adımları

Geçtiğimiz günlerde bir müşterimizin HPE StoreOnce altyapısında Veeam Backup job’larının beklenmedik şekilde yavaşladığı ve neredeyse tüm işlerde sürekli “Target Bottleneck” uyarısı oluştuğu bir vakayla karşılaştım.

İlk aşamada problem klasik bir storage performans darboğazı gibi görünüyordu. Ancak katmanlı şekilde yaptığımız inceleme sonucunda, sorunun doğrudan disk performansından ya da ağ tarafındaki bir darboğazdan değil StoreOnce housekeeping mekanizmasının tıkanmasından kaynaklandığı net şekilde ortaya çıktı.

Bu tip vakalarda en kritik nokta belirtileri yalnızca yüzeysel olarak değerlendirmemek ve StoreOnce’un arka planda çalışan bakım süreçlerini de analiz kapsamına almaktır. Çünkü housekeeping süreçleri durduğunda ya da ilerleyemediğinde sistem yalnızca kapasite tarafında değil aynı zamanda deduplikasyon verimliliği, metadata erişimi ve genel yazma performansı açısından da ciddi şekilde etkilenir.

Problemin İlk Belirtileri

Sahada karşılaştığımız belirtiler oldukça tipikti ancak ilk bakışta doğrudan housekeeping’e işaret etmeyebilirdi. StoreOnce üzerinde yaptığımız kontroller sırasında aşağıdaki bulgular dikkat çekti:

Pending Housekeeping değeri 51.9 TB seviyesine ulaşmıştı.
Processed Housekeeping grafiği neredeyse sıfırdı.
Housekeeping işlemlerinin uzun süredir ilerlemediği grafiksel olarak net şekilde görülüyordu.
Kernel log tarafında sürekli tekrar eden şu hata mevcuttu.
“hpilo… could not dequeue a packet”
İşletim sistemi seviyesinde queue stall benzeri bir tıkanma gözlemleniyordu.
Veeam backup job’ları özellikle finalize aşamasında olağan dışı sürelerde bekliyordu.
Backup penceresi uzuyor, throughput düşüyor ve Veeam tarafında “Target Bottleneck” alarmı sürekli görünüyordu.

Bu belirtiler birlikte değerlendirildiğinde artık sorunun yalnızca “yedekler yavaş çalışıyor” şeklinde basit bir performans problemi olmadığı StoreOnce üzerinde housekeeping süreçlerinin sağlıklı ilerlemediği dolayısıyla backend temizlik ve metadata düzenleme mekanizmasının kilitlendiği anlaşılmış oldu.

Housekeeping Nedir ve Neden Kritik Öneme Sahiptir?

StoreOnce mimarisinde housekeeping mekanizması çoğu zaman göz ardı edilir oysa sistemin sürdürülebilir performansı açısından en önemli arka plan süreçlerinden biridir.

Housekeeping temel olarak şu görevleri yerine getirir;

Deduplikasyon metadata yapısını düzenler.
Silinmiş veya artık kullanılmayan blokları fiziksel olarak temizler.
Fragmentasyonu azaltır.
Capacity reclamation sürecine katkı sağlar.
Yazma ve okuma performansının dengeli kalmasına yardımcı olur.

StoreOnce deduplikasyon mantığı gereği yoğun metadata işleyen bir yapıya sahiptir. Bu yüzden housekeeping süreci durduğunda yalnızca boş alan geri kazanımı etkilenmez aynı zamanda metadata erişim maliyeti artar I/O zincirinde gecikmeler oluşur ve cihazın genel yanıt verme süresi düşer.

Bunun doğrudan yansıması ise backup işlerinde yavaşlama, finalize sürelerinin uzaması, repository tarafında darboğaz oluşması ve bazı durumlarda restore operasyonlarının da etkilenmesidir.

Kısacası housekeeping’in durması StoreOnce üzerinde görünmeyen ama tüm performans katmanını etkileyen kritik bir bozulma halidir.

Kök Neden Analizi

Vakada ilk etapta storage utilization, disk latency, Catalyst store davranışı, Veeam repository bağlantısı ve ağ trafiği gibi klasik alanlar kontrol edildi. Ancak bu katmanlarda sorunu açıklayacak kadar büyük ve sürekli bir anomali görülmedi. Asıl kırılım, StoreOnce housekeeping metriklerine ve sistem loglarına inildiğinde ortaya çıktı.

Özellikle şu iki gösterge belirleyici oldu:

Pending housekeeping miktarının çok yüksek olması
Processed housekeeping değerinin uzun süre neredeyse hiç ilerlememesi

Bu duruma ek olarak kernel loglarında dönen “hpilo could not dequeue a packet” benzeri hata mesajları sistemin alt seviyede bazı queue işlemlerinde takıldığını düşündürdü.

Her StoreOnce vakasında bu hata birebir aynı anlama gelmeyebilir ancak burada gözlenen davranışla birlikte değerlendirildiğinde housekeeping sürecinin ilerleyememesine neden olan bir queue tıkanması veya servis seviyesinde kilitlenme senaryosu oldukça güçlü hale geldi.

Sonuç olarak root-cause şu şekilde netleşti:

StoreOnce housekeeping mekanizması ilerleyemiyor, pending iş yükü birikiyor, sistem metadata ve cleanup operasyonlarını tamamlayamıyor, bunun sonucunda Veeam job’ları repository tarafında ciddi performans kaybı yaşıyordu.

Uygulanan Çözüm Adımları

Sorunun teşhis edilmesinin ardından kontrollü ve düşük riskli bir müdahale planı izlendi. Uygulanan adımlar şu şekildeydi:

1. Housekeeping Pending / Processed metriklerinin doğrulanması

Öncelikle StoreOnce arayüzü ve ilgili izleme ekranları üzerinden housekeeping pending ve processed değerleri karşılaştırıldı. Burada amaç bunun geçici bir backlog mu yoksa gerçekten stuck olmuş bir housekeeping senaryosu mu olduğunu ayırt etmekti.

2. System log, kernel log ve iLO log incelemesi

Log tarafında özellikle queue, packet, service stall ve hardware management ilişkili kayıtlar incelendi.

Burada çıkan “hpilo could not dequeue a packet” satırları sorunun yalnızca uygulama seviyesi değil sistem servisleriyle de ilişkili olabileceğini gösterdi.

3. Housekeeping servisinin çalışıp çalışmadığının doğrulanması

Housekeeping tamamen durmuş mu, aktif görünüp gerçekte ilerlemiyor mu, yoksa işlem kuyruğunda blokaj mı oluşmuş; bu ayrımın yapılması çok önemliydi.

İnceleme sonucunda housekeeping’in işlevsel olarak ilerlemediği doğrulandı.

4. Kontrollü reboot planı

Mevcut backlog miktarı, servis davranışı ve log bulguları birlikte değerlendirildiğinde en hızlı, güvenilir ve düşük belirsizlik içeren yöntem olarak kontrollü reboot kararı alındı.

Bu noktada elbette aktif iş yükü, maintenance window ve backup zincirinin durumu dikkate alınarak hareket edildi.

5. Reboot sonrası housekeeping davranışının yeniden izlenmesi

Sistem yeniden ayağa kalktıktan sonra housekeeping süreci tekrar takip edildi.

Burada beklenen senaryo stuck olan queue’nun temizlenmesi ve housekeeping’in yeniden işleme başlamasıydı.

6. Pending kuyruğun temizlendiğinin doğrulanması

Reboot sonrasında pending housekeeping değerinin kademeli olarak düştüğü ve sonrasında sıfırlandığı görüldü. Processed housekeeping de tekrar normal akışına döndü.

Müdahale Sonrası Gözlenen Sonuçlar

Reboot sonrasında cihazın genel davranışında belirgin bir toparlanma yaşandı. Elde edilen sonuçlar şunlardı.

Pending Housekeeping = 0 TB
Housekeeping yeniden aktif şekilde çalışmaya başladı
Veeam job’larındaki Target Bottleneck uyarıları ortadan kalktı
Finalize süreleri normale döndü
Backup throughput değerleri beklenen seviyelere geldi
Repository tarafındaki gecikme gözle görülür şekilde azaldı

Bu iyileşme, sorunun doğrudan housekeeping tıkanmasından kaynaklandığını pratik olarak da doğrulamış oldu.

Reboot Mümkün Değilse Uygulanabilecek Alternatif Teknik Müdahaleler

Her ortamda reboot atmak mümkün olmayabilir. Özellikle 7/24 çalışan yapılarda kritik backup pencerelerinde veya değişiklik onayı gerektiren sistemlerde önce daha kontrollü müdahale yöntemleri değerlendirilmek istenebilir. Bu tür senaryolarda aşağıdaki alternatifler düşünülebilir.

1. Housekeeping servisinin manuel restart edilmesi

Bazı StoreOnce sürümlerinde housekeeping süreci servis seviyesinde takılmış olabilir. Böyle durumlarda SSH üzerinden kontrollü servis restart denenebilir.

services housekeeping --stop
services housekeeping --start

Bu yöntem, stuck halde bekleyen housekeeping sürecini toparlayabilir. Ancak her versiyonda aynı sonucu vermeyebilir. Uygulamadan önce mutlaka ilgili sürüm dokümantasyonu ve üretici önerileri dikkate alınmalıdır.

2. Housekeeping queue’nun soft reset ile temizlenmesi

Bazı durumlarda servis tamamen stop/start yerine abort edilerek yeniden başlatılabilir.

services housekeeping --abort
services housekeeping --start

Bu yöntem reboot kadar radikal değildir ancak stuck queue durumlarında işe yarayabilir. Yine de bu işlem öncesinde sistemin genel sağlık durumu dikkatlice kontrol edilmelidir.

3. Catalyst Store veya dedupe store seviyesinde doğrulama çalışmaları

Sorun sadece housekeeping servisinde değil alttaki store yapılarında tutarsızlık veya metadata bozulmasına yakın bir durumdan da besleniyor olabilir. Böyle senaryolarda şu kontroller anlamlıdır:

Metadata validation
Chunkstore consistency check
Store-level sağlık kontrolleri

Özellikle yüksek kapasitede uzun süredir çalışan çok yoğun retention ve silme operasyonu yaşayan ortamlarda bu doğrulama işlemleri ciddi fayda sağlayabilir.

4. Kapasite seviyesinin gözden geçirilmesi

HPE StoreOnce cihazları yüksek doluluk oranlarında housekeeping ve genel performans açısından daha hassas hale gelir.

Özellikle %85 ve üzeri kapasite kullanımı housekeeping hızını belirgin şekilde düşürebilir. Bu nedenle:

Eski restore point’lerin temizlenmesi
Kullanılmayan recovery chain’lerin kaldırılması
Retention politikasının optimize edilmesi gibi aksiyonlar cihazın rahatlamasına yardımcı olabilir.

5. HPE iLO ve sürücü firmware uyumluluğunun kontrol edilmesi

Vakada görülen “hpilo could not dequeue a packet” hatası tek başına kesin hüküm vermese de aşağıdaki olasılıkları gündeme getirir:

iLO firmware bug’ı,
Driver ile OS arasındaki uyumsuzluk,
Queue overflow,
Donanım yönetim katmanında gecikme veya kilitlenme,

Bu nedenle üretici tavsiyelerine göre firmware ve ilgili bileşen sürümlerinin kontrol edilmesi son derece önemlidir. Özellikle bilinen bug’ların yer aldığı versiyonlarda patch veya update uygulaması kalıcı çözüm sağlayabilir.

6. Dedupe ratio ve store yapısının değerlendirilmesi

Bazı ortamlarda housekeeping tıkanıklığı, bozulan store dengesi veya düzensiz chunk yerleşimiyle birleştiğinde performans sorunlarını daha da derinleştirebilir.

Bu durumda store-level compaction veya üretici önerisine uygun bakım operasyonları değerlendirilebilir. Ancak bu tür işlemler daha planlı ve dikkatli yapılmalıdır.

Veeam Tarafındaki Belirtilerin Önemi

Bu vaka ayrıca Veeam tarafında görülen bottleneck bilgisinin ne kadar kritik olduğunu da açık şekilde gösterdi. Pek çok ortamda “Source bottleneck”, “Proxy bottleneck” veya “Target bottleneck” mesajları sadece genel bir uyarı gibi algılanabiliyor.

Oysa doğru yorumlandığında, bu bilgi problemin hangi katmanda yoğunlaştığını anlamada çok değerli bir başlangıç noktasıdır.

Bu olayda Veeam’in sürekli Target Bottleneck göstermesi, sorunun proxy, network veya source taraftan çok repository/hedef tarafta aranması gerektiğini net şekilde ortaya koydu.

Elbette tek başına bu bilgi root-cause vermez; ancak doğru yönde ilerlemeyi sağlar.

Bu vaka backup performans sorunlarının her zaman disk I/O, ağ gecikmesi ya da proxy kaynaklarıyla açıklanamayacağını bazı durumlarda HPE StoreOnce’un arka planda çalışan housekeeping süreçlerindeki tıkanmanın tüm sistemi zincirleme biçimde yavaşlatabileceğini gösteren çok iyi bir örnek oldu.

Özellikle şu dersler öne çıkıyor.

StoreOnce performans sorunlarında housekeeping metrikleri mutlaka kontrol edilmelidir.
Pending ve Processed housekeeping değerleri, sistem sağlığı için kritik göstergelerdir.
Veeam tarafındaki bottleneck uyarıları doğru okunursa teşhis süresi ciddi şekilde kısalır.
Reboot çoğu zaman en hızlı toparlama yöntemi olabilir; ancak reboot mümkün değilse alternatif teknik müdahaleler de değerlendirilebilir.
Firmware, sürücü uyumluluğu, kapasite seviyesi ve store sağlığı uzun vadeli stabilite için göz ardı edilmemelidir.

Doğru analiz katmanlı inceleme ve zamanında müdahale sayesinde sistem tamamen stabil hale getirildi, backup hızları normal seviyelere döndü ve operasyonel risk ortadan kaldırıldı.