Avamar: Avamar'da askıya alınmış bölümler, şeritler ve hfscheck hataları

1. Avamar Administrator Server kullanıcı arayüzünde aşağıdaki hata görüntülenebilir. Bu mesaj bir Dial Home Servis İsteği (SR) oluşturabilir:

Symptom Code: 22632, Desc: A server disk has become suspended.

2. Aşağıdakilerle ilgili UYARI mesajları perfbeat İş parçacığı, içindeki veri depolama düğümlerinde rapor edilir /data01/cur/gsan.log:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66
WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended
WARN: <1084> changing disk 0 on node 0.3 to suspended state

3. Komutta status.dpn çıktı, bir diskte şeritlerin askıya alındığını gösterir:
(Bu çıktı yalnızca "WARN <1084>" oluştuğunda üretilir.)

Örneğin:

0.8 10.10.10.10 7.3.1-125 ONLINE fullaccess mhpu+0hpu+0hpu 1 false 7.36 16350564 3401334 56.0% 66%(onl:1,SUS:2374) 50%(onl:2439) 50%(onl:2433) 

Bu çıktı, 2374 adet askıya alınmış şerit olduğunu gösterir.

4. Komutta hfschecBir bölüm askıya alınırsa k başarısız olur. hfscheck çalışıyor. Hataya bir örnek: /data01/hfscheck/err.log veya /data01/cur/err.log ar: 

ERROR: <0001> indexstripe::hfschecksweepbody stripe=0.0-1209 proxy=0.0-1209 indexelem([hash=ee9b2fe66b4bd472e28c4f41c5097dbeaba7131a stripe=0.1-DF8 offset=1285]) goodowner=true goodelem=false

Periyodik olarak, varsayılan olarak her beş dakikada bir, gsan I/O veri bölümlerinden küçük okumalar gerçekleştirerek alt sistem.

Okuma performansının normal performansın %10 u kadar olup olmadığını doğrular.

Aşağıdaki örnekte mesaj, uyarı mesajını oluşturan belirli bir düğümde, uzun sayıda deneme üzerinden ortalama okuma performansının hfscheck çalışıyordu yaklaşık 54.03 MB/saniyedir. Bununla birlikte, bu özel testte, gerçek performans 0,57 MB/saniye idi ve bu, ortalama değerin %10'u olan "sınırının" veya 5,4029 MB/saniyenin altındaydı.

Event Summary = perfbeat::outoftolerance mask=[hfscheck] average=54.03 limit=5.4029 mbpersec=0.57

Bu testin asıl amacı, aşağıdakilerle ilgili bir sorun olduğuna dair bazı uyarılar sağlamaktı: I/O Okuma performansının aşırı yavaş olmasına neden olan alt sistem. 

Bu durumda, "ortalama" diskin% 10'undan daha yavaş I/O performans.

Komutta perftriallimit Daha önce tolerans dışı olması gereken ardışık disk okuma testlerinin sayısını belirtir perfbeat Bir diskin bozulmuş olabileceğinden şüphelenir.

Komutta perfinterval (varsayılan 300 sn veya 5 dakika) her biri arasında ne kadar bekleneceğini belirtir perftriallimit test.

Ne zaman perfbeat Bir diskin performansının düştüğünden şüphelenirse gsan Soğuk duruma ulaşmak için (diskle ilgili tüm etkinlikleri durdurun). 

En fazla 20 dakika bekler (kablolu) gsan zaman aşımına uğramadan ve diski askıya almadan önce bu duruma ulaşmak için.

Soğuk duruma ulaşılırsa, o zaman perfbeat Gerçekleştirir perfcoldtriallimit (varsayılan 4) daha fazla okuma testi aralıklı perfcoldinterval (varsayılan 30) saniye arayla.

Ancak tüm bu sınamalar diskin hala düşük performansta olduğunu gösteriyorsa disk askıya alınır.

Askıya alınan disklerin olası nedenleri:

• Soğuk bir duruma ulaşmaya çalışırken, gsan her zaman en az bir dakika bekler (kablolu). Ayrıca bekleyen tüm gsan disklerini de bekler I/O işlemlerini tamamlamak veya askıya almak için ilgili faaliyetler. Ancak, soğuk bir duruma ulaşıldıktan sonra, işletim sistemi hala disk çalışıyor olabilir I/O, önbelleğini boşaltmak gibi. Bu temizleme etkinliği, disklerin neden gereksiz yere askıya alındığına ilişkin olası bir açıklamadır. Daha büyük miktarda bellekle, temizlenmesi gereken çok daha fazla önbellek verisi olabilir.

• Başka bir olası açıklama, performans geçmişi bilgilerinin, çeşitli performans sırasında beklenen disk okuma performansının ne olması gerektiğini doğru bir şekilde tahmin etmemesidir. gsan faaliyetler çünkü gsan's Davranış, geçmişin yansıtamayacağı kadar hızlı değişti (geçmiş, son 10 günlük performans ölçümlerinin ortalamasıdır).

• Başka bir olası açıklama, hepsini beklememek gibi bir sorun olabileceğidir gsan disk I/O soğuk bir duruma ulaşmadan önce işlemlerini tamamlamak veya askıya almak için yapılan faaliyetler.

Ayrıca, araştırmalar gösterdi ki, hfscheck )indexsweep" aşaması (dizin şeritlerindeki tüm karmalar okunurken ve ardından birçok Veri Referanslı Günlük (DRL) dosyasına çok sayıda rastgele yazma işlemi gerçekleştirirken) test edildi I/O Performans önemli bir süre düşer.

Avamar Data Store Gen4, Gen4s ve Gen4T'de yazma işlemlerine okuma işlemlerine göre öncelik verilmiştir ve Datastore I/O alt sistem çok daha düşüktür. Ayrıca, bazı sürücüler (örneğin Seagate Megalodon sürücüler) tarafından gerçekleştirilen testlerin kafasını karıştırabilecek bazı farklı teknikler kullanır. perfbeat iplik.

Arkaplan:

Listede genellikle üç farklı uyarı mesajı görülür. gsan Günlük:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66

Uyarı <0968> , bir kişinin olduğunu gösterir. gsan I/O Test yavaştı.

Bu mesajı görmezden gelebilirsiniz.

WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended

Uyarı <1051> , yeterli sayıda yavaş okuma olduğunu gösterir. gsan veri bölümünü askıya alma durumuna getirilmesi düşünüldü, ancak bunu yapmamaya karar verildi. MSG_ERR_UNNECESSARY gösterdiği şey budur.

Bu mesajı görmezden gelebilirsiniz.

WARN: <1084> changing disk 0 on node 0.3 to suspended state

1084> numaralı uyarı<, gsan'ın veri bölümünü "askıya alınmış" duruma geçirdiğini gösterir.

Mesajınız göz ardı edilmemelidir.

Çözünürlük:

Şeritler askıya alınırsa aşağıdaki senaryoları araştırmak ve düzeltmek için aşağıdaki yönergeleri kullanın:

Askıya alınan bölümün konumunu belirlemek için aşağıdakileri gerçekleştirin:

1. Avamar Utility Node'da yönetici olarak oturum açın.

2. Kök ayrıcalığına yükseltin.

3. Avamar başına kök anahtarları yükleyin: Avamar Server'da Oturum Açma ve Çeşitli Anahtarları Yükleme (İngilizce).

4. Askıya alınan bölümün konumunu belirlemek için aşağıdaki komutu çalıştırın:

mapall --noerror 'grep -i "suspended" /data01/cur/err.log'

5. Yukarıdaki sonuçlarla ilgili senaryoları gözden geçirin:

• • Eylem gerekmez. Şeritler otomatik olarak çevrimiçi olur. Kuvvetle muhtemeldir hfscheck koşuyordu. 

• • Şeritler otomatik olarak çevrimiçi olarak geri dönerse, büyük olasılıkla çöp toplama veya hfscheck koşuyordu.
  • ÖNEMLİ: Bu, bir disk sorununun veya altta yatan bir sorunun göstergesi olabilir.
  • Sürücü henüz arızalanmamış olsa da aşağıdaki adımlar kullanılarak kontrol edilmesi gerekir:

1. Avamar'ın askıya aldığı diskle hangi fiziksel disklerin ilişkili olduğunu belirleyin. Sanal diskteki fiziksel disklerin askıya alınmasıyla ilgili sorunlar, askıya almanın temel nedenidir:

avsysreport pdisk vdisk=x 

Burada x, askıya alınan sanal diskin (veri bölümü) numarasıdır. Örneğin, ilk veri bölümü askıya alınmış şeritler gösteriyorsa, şu sorguyu sorgulayın: vdis=0.

2. Fiziksel disk düzeyinde disk arızası, öngörülen arıza veya başka hata olmadığını doğrulayın.

3. Söz konusu düğümdeki sanal diski temsil eden fiziksel disklerde SCSI hatası olmadığını doğrulayın (1. Adımda belirlenir). 

grep -i "MRMON\|scsi|Adaptec" /var/log/messages

4. Üzerine Yazma Modundaki Sanal Diskler, düşük nedeniyle diskin askıya alınmasına neden olabilir I/O. Denetleyicideki yazma ilkesini kontrol edin:

mapall --noerror --all+ 'avsysreport vdisk | grep "Write Policy"'  

2-4. adımlarda herhangi bir sorun algılanırsa daha fazla araştırma için Dell Technologies Avamar Destek te bir SR açın.

Senaryo# 3: Varsayılanı inceleyin perftriallimit Ayarlar:

1. Şunu doğrulayın: perftriallimit 0 olarak ayarlanır:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Eğer perftriallimit sıfırdan başka bir şeydir:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"