PowerFlex: Aşırı veri rolü değişimi, IO gecikmesine ve hatalara neden olur

Belirli küme durumu geçişleri altında, MDM rol dengeleme mantığı birçok taramada (her bir birim verisi parçasını hangi SDS düğümlerinin depoladığını izleyen dahili veri yapıları) hızlı, tekrarlanan birincil/ikincil rol anahtarları üretebilir. Her rol anahtarı, istemci tarafı (SDC) tarama eşlemelerini geçersiz kılar ve G/Ç yeniden denemelerini zorlar. Aynı anda yeterli sayıda tarama etkilendiğinde, kümülatif yeniden deneme ek yükü SDC ana bilgisayarlarında G/Ç gecikme süresinde ani artışlara ve G/Ç hatalarına neden olur. Ana bilgisayar ortamına bağlı olarak bu durum, uygulama G/Ç zaman aşımlarına, VM'lerin salt okunur duruma girmesine veya dosya sisteminin kullanılamamasına neden olabilir.

Bu davranış birden çok tetikleyici senaryoda gözlemlenmiştir ve tek bir operasyonel yordamla sınırlı değildir.

Ortak Göstergeler

• MDM_DATA_DEGRADED olay ve ardından 1-15+ dakika süren sürekli G/Ç gecikmesi
• SDC ana bilgisayarları, bozulma penceresi sırasında G/Ç hataları ve/veya G/Ç zaman aşımları bildiriyor
  • VMware (ESXi): VMFS sinyal zaman aşımları, SCSI donanım hataları (sense data: 0x4 0x0 0x0), salt okunur duruma giren VM'ler, potansiyel HA yük devretme
  • Linux: Sistem günlüklerindeki G/Ç hataları (/var/log/messages, dmesg), uygulamalarda G/Ç zaman aşımları veya dosya sistemi salt okunur olarak yeniden bağlama sorunu yaşanabilir
• MDM olay günlükleri, tek bir SDS kaybı için sistemin beklenenden daha uzun süre ALÇALTILMIŞ durumda olduğunu gösteriyor
• Sistem sonunda manuel müdahale olmadan NORMAL bir duruma geri döner (genellikle)

1. Senaryo: Düzgün SDS Kaybı (Bakım Modu Yok)

Ne zaman olabilir:

• Bu nadir görülen bir senaryodur. Düzgün olmayan bir SDS kaybı sırasında hızlı, tekrarlanan rol değiştirme olaylarının gerçekleşmesi için birkaç özel koşulun aynı anda mevcut olması gerekir:

• • Büyük ölçekli ortam - Önemli sayıda SDS düğümü ve birimi
  • Ağır üretim G/Ç yükü - SDS'nin başarısız olduğu anda önemli G/Ç etkinliği
  • Yeniden oluşturma iş yükü işleme kapasitesini aşıyor - Yeniden oluşturma gerektiren meta veri satırlarının sayısı, MDM dengeleyicinin döngü başına 1.024 satır sınırını aşıyor

Her yeniden dengeleme döngüsü, 1024 adede kadar meta veri satırı işleyebilir. Daha fazla satırın yeniden oluşturulması gerektiğinde, dengeleyici bir sonrakini oluşturmadan önce mevcut planı bitiremez.

Ne olur:

• SDS, MDM'den aniden ayrışır (olay SDS_DECOUPLED)
• Bu SDS ye bağlı olan tüm SDC'ler, SDC bağlantı kesme olayları → bağlantılarını kaybeder
• MDM, kümeyi DEGRADED (olay MDM_DATA_DEGRADED)
• Yeniden oluşturulacak satır sayısı 1.024'ün üzerinde olduğundan, MDM dengeleyicisi geçerli yeniden dengeleme planını tamamlayamaz
• Dengeleyici, önceki plan devam ederken yeni bir plan başlatır ve hızlı, tekrarlanan rol değiştirme olayları üretir
• İstemci SDC'leri sürekli G/Ç hataları görüyor (IO_FAULT_NOT_PRI, SCSI sense 0x4). Yeniden denemeler tükendikten sonra ana işletim sistemi G/Ç hataları, zaman aşımları veya salt okunur bir dosya sistemi bildirir
• MDM iz kanıtı:

Yeniden dengeleme iş yükü 1.024 satır sınırını aştığında MDM izlemesi eşiğin aşıldığını gösterir:

2026/03/28 22:43:53.246702 MED:7f1f984aedb0:balanceExec_HandleDegradedRows:00343: BALANCER: Storage Pool: 1193844800000000 - 1024 rows processed out of 1098 degraded rows. 0 allocation failures. 0 cumulative allocation failures.

Bu, 1.098 satırın yeniden oluşturulması gerektiğini, ancak geçerli döngüde yalnızca 1.024 satırın işlenebildiğini gösterir. Kalan satırlar, önceki plan tamamlanmadan önce yeni bir yeniden dengeleme planını tetikler ve geri bildirim döngüsünü başlatır.

Olaylar zinciri:

Log Source     Event / Pattern
MDM events     SDS_DECOUPLED — SDS formally declared dead
MDM events     MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces     Flood of IO_FAULT_NOT_PRI — SDS received IO for a comb it is no longer primary for
ESXi vmkernel  SCSI sense data: 0x4 0x0 0x0 — Hardware error
MDM events     MULTIPLE_SDC_CONNECTIVITY_CHANGES — Mass SDC connectivity storm
MDM events     SDC_DISCONNECTED_FROM_SDS_IP — SDCs losing contact with the failed SDS

SDC_DISCONNECTED_FROM_SDS_IP    SDC disconnected from SDS <name>
SDS_DECOUPLED                   SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

2. Senaryo: PMM girişi sırasında SDS kapanması

Ne zaman olabilir:
Bu, iki eş zamanlı olay gerektiren nadir bir senaryodur:

• Bir SDS, Korumalı Bakım Moduna (PMM) giriyor
• SDS başarısız oluyor veya PMM geçişi tamamlanmadan kapatılıyor

Ne olur: 

• MDM, PMM giriş komutunu alır ve başarılı olarak kaydeder
• SDS, PMM girişi devam ederken beklenmedik şekilde ayrışır
• MDM, kümeyi BOZULMUŞ olarak işaretler
• Rol dengeleyici, PMM giriş aşaması boyunca sürekli bir rol değiştirme döngüsüne girer
• PMM olmayan veri satırları, depolama havuzunun tamamında tekrar tekrar rol değiştirir
• SDS kümeye yeniden katılana ve bakım modu geçişini tamamlayana kadar fırtına devam eder

Olaylar zinciri:

Log Source  Event / Pattern
MDM events  CLI_COMMAND_SUCCEEDED — enter_protected_maintenance_mode command succeeded
MDM events  SDS_DECOUPLED — SDS decoupled before maintenance mode started
MDM events  MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces  Repeated role-switch operations across non-PMM rows

Örnek MDM olay sırası:

CLI_COMMAND_SUCCEEDED            Command enter_protected_maintenance_mode succeeded
SDS_DECOUPLED                    SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

SDS yeniden birleştiğinde ve PMM tamamlandığında:

SDS_MAINTENANCE_MODE_STARTED     SDS maintenance mode started
MDM_DATA_NORMAL                 The system is now in NORMAL state

3. Senaryo: Anında Bakım Modunda (IMM) SDS

Ne zaman olabilir:
SDS, Anında Bakım Moduna (IMM) girer veya çıkar. Bu senaryo, tek bir SDS bakım modundayken sistem belirli veriler için hangi SDS'nin G/Ç işlemesi gerektiğine karar veremediğinde gerçekleşir.

Ne olur:

• Sistem, aynı verileri sunmaktan hangi SDS'nin sorumlu olduğunu sürekli olarak değiştirir
• Bu sürekli değişiklikler, uygulamaların G/Ç isteklerini nereye göndereceklerini bilmedikleri anlamına gelir
• G/Ç'nin yanlış SDS'ye gönderilmesi, yeniden denemelere ve gecikmelere neden oluyor
• Uygulamalar, etkilenen verilere erişmeye çalışırken gecikme veya zaman aşımlarıyla karşılaşıyor

Etki:

• Müşteri etkisi: SDS İBB'deyken uygulamalar gecikmeleri ve zaman aşımlarını bildiriyor
• Süre: SDS İBB durumundayken devam eder
• Kurtarma: Otomatik - SDS IMM'den çıktığında çözülür

Olaylar zinciri:

Log Source  Event / Pattern
SDS traces  Repeated role-switch operations on the same data
SDS traces  Primary and secondary role switches on identical data

4. Senaryo: SDS Korumalı Bakım Modundan (PMM) Çıktı

Ne zaman olabilir:
SDS, Korumalı Bakım Modundan (PMM) çıkar. Bu senaryo her PMM çıkışı sırasında gerçekleşir. Nadir görülen bir durum değildir ancak önem derecesi, bakım modu işleminin ne kadar sürdüğüne bağlıdır.

Ne olur:

• SDS, PMM'den çıkarken rol dengeleyicinin veri segmentlerini geri dönen SDS'yi içerecek şekilde yeniden ataması gerekir
• Yeniden dengeleme işlemi, yalnızca geri dönen SDS'deki verileri değil, tüm depolama havuzunu etkiler
• Yeniden entegrasyon sırasında birçok veri segmentinde rol geçişleri gerçekleşir
• Rol atamaları kararlı hale geldikçe uygulamalar kısa süreli G/Ç hataları veya gecikme süresi yaşayabilir

Etki:

• Müşteri etkisi: Kısa bakım aralıkları için (5 saniyeden az), etki neredeyse hiç fark edilmez. Etkin G/Ç ile genişletilmiş bakım için, binlerce rol anahtarı meydana gelebilir ve bu da sürekli G/Ç kesintilerine neden olabilir
• Süre: Yeniden dengeleme tamamlanana kadar yeniden entegrasyon aşamasında devam eder
• Kurtarma: Otomatik

Olaylar zinciri:

Log Source  Event / Pattern
MDM events  Role-switch operations across the storage pool during exit
SDS traces  Repeated role-switch operations during reintegration

Örnek MDM olay sırası:

SDS_MAINTENANCE_MODE_EXIT_STARTED    SDS maintenance mode exit started
SDS_MAINTENANCE_MODE_EXIT_COMPLETED   SDS maintenance mode exit completed

Günlük Çıktıları:
 

MDM Olay Günlükleri: MDM olay günlüğü, küme düzeyindeki sırayı gösterir. Temel göstergeler, bakım modu çıkışı sırasındaki rol değiştirme işlemleridir.

SDS İzleme Günlükleri: SDS düğümleri üzerinde izleme günlükleri, yeniden entegrasyon sırasında tekrarlanan rol değiştirme işlemlerini gösterir:

raidComb_SetPriTgtGenNum: combId <id> combGenNum: cur <gen> new <gen>
contCmd_SetCombState: CombId <id> devId <id> PRI->SEC Switch roles
contCmd_SetCombState: CombId <id> devId <id> SEC->PRI Switch roles

Kısa bir zaman aralığında (saniyeler içinde binlerce veya daha fazla) yüksek sayıda Rol değiştirme girişi, bu sorunun SDS tarafındaki kesin göstergesidir.

SDC/Ana Bilgisayar Günlükleri: VMware (ESXi) SDC G/Ç taraması, hedef SDS ve hata kodunu gösteren yeniden denemeler:

vmkernel log
PowerFlex mapVolIO_Do_CK:1496 :Mit: <addr>. Retrying IO Type WRITE. Failed comb: <id>. SDS_ID <id>. Comb Gen <gen>. Head Gen <gen>.
PowerFlex mapVolIO_Do_CK:1510 :Mit: <addr>. Vol ID <id>. Last fault Status IO_FAULT_NOT_PRI(12). Retry count (1)

Yeniden denemeler tükenirse SCSI hataları döndürülür: 

sense data: 0x4 0x0 0x0   -- SCSI Hardware Error

Tanılama ipucu: Birden fazla SDS düğümünde (yalnızca sorun olan düğümde değil) G/Ç hataları görüyorsanız bu durum, normal düşük durum davranışından ziyade rol değiştirme fırtınasına işaret ediyor olabilir. G/Ç hataları tek bir SDS ye yalıtılmışsa bu, beklenen düşük performans davranışıdır.

5. Senaryo: Bakım Modu Aşama Geçişleri 

Ne zaman olabilir:
Geçiş sırasında, bir SDS bakım moduna (IMM veya PMM) girdiğinde veya çıktığında - şu anda durum normalden MM'ye veya MM'den tekrar normale değişir.

Ne olur:

• Rol dengeleyici, değişikliğe uyum sağlamak için veri sorumluluklarını yeniden dağıtır
• Sistem yeni düzenlemeye alıştıkça kısa süreli rol değiştirme patlamaları meydana gelir
• Uygulamalar, geçiş sırasında kısa gecikme artışlarıyla karşılaşabilir

Etki:

• Müşteri etkisi: Saniyelerden birkaç dakikaya kadar süren kısa gecikme artışları. Genellikle uygulama zaman aşımı eşiklerinin altında
• Süre: Saniyeler ila birkaç dakika sürer, sonra yerleşir
• Kurtarma: Otomatik

Olaylar zinciri:

Log Source  Event / Pattern
SDS traces  Brief role-switch operations during phase transitions

MDM rol dengesi mantığındaki bir yazılım hatası, SDS kaybı veya bakım modu işlemi nedeniyle küme duruma geçtiğinde bir geri bildirim döngüsüne neden olur.

MDM, belirli koşullarda etkilenen taraklara G/Ç sağlamaktan sorumlu olan SDS düğümlerini tekrar tekrar atar. Her yeniden atama, SDC'nin verilerin nerede bulunduğuna ilişkin önbelleğe alınmış görünümünü geçersiz kılarak G/Ç yeniden denemelerini zorlar. Birçok tarama aynı anda etkilendiğinde, yeniden atamaların hacmi SDC'lerin güncelleme yeteneğinden daha fazladır ve bu da birden çok ana bilgisayarda sürekli G/Ç hatalarına neden olur.

Fırtına tipik olarak kendi kendini sınırlar. Küme kararlı hale geldikten sonra çözülür ancak süre, koruma etki alanının boyutuna ve olay sırasındaki G/Ç yüküne bağlıdır.

Bu sorun PowerFlex Core sürüm 4.5.6'da giderildi. Kullanıma sunulduğunda bu sürüme yükseltin. Sürüm zaman çizelgesi bilgileri için Dell Destek ekibiyle iletişime geçin.

Planlı bakım işlemleri için:

• MDM günlükleri görüntülenene kadar SDS'yi kapatıp açmayın veya yeniden başlatmayın SDS_MAINTENANCE_MODE_STARTED. Fiziksel bakıma devam etmeden önce SDS'nin bakım moduna tam olarak girdiğini doğrulayın.
• Bakım moduna girerken veya çıkarken ani gecikme artışlarını izleyin.

Planlanmamış SDS kesintileri için:

• Fırtına kendi kendini sınırlar ve genellikle küme stabilize olurken dakikalar içinde çözülür. Sorun gözlemlenirse şunları yapın: getinfo günlükleri koruma etki alanındaki tüm SDS düğümlerinden, tüm yönetici MDM'lerinden olaydan sonra mümkün olan en kısa sürede kaydedin ve Dell Destek ile iletişime geçin.

Sorunun kendi kendine çözülmediği nadir durumlarda, yeniden oluşturmanın geçici olarak devre dışı bırakılması ve yeniden etkinleştirilmesi MDM'nin kararlı hale gelmesini sağlayabilir:

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --disable_rebuild

# 5-10 saniye bekleyin, ardından yeniden oluşturmayı etkinleştirin: 

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --enable_rebuild