Avamar GSAN veya Kullanıcı Kapasitesi Çözümleme Yolu

İşletim Sistemi (OS) Kapasitesi ile ilgili temel kavramlar ve anlayış için bkz . Avamar: Kapasite Genel Eğitimi - Çözüm Yolu

Dikkate alınması en kolay yoldur GSAN İstemci yedeklemeleri için alan ve kullanım olarak kapasite.

• Tekilleştirmenin temel anlayışı
• Kontrol noktasının temel anlayışı, kontrol noktası doğrulaması (hfscheck) ve Çöp Toplama ve her birinin önemi.
• Arasındaki fark GSAN (veya Kullanıcı) Kapasite ve İşletim Sistemi Kapasitesi
• Değişim Oranı
• Sabit Durum

• Şebeke erişim durumu "yönetici modu" olarak değiştiğinde Yedekleme veya Çoğaltma hatası

  • İstemci yedekleme işi aşağıdakine benzer bir mesajla başarısız olabilir:  )avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• Yedekleme zamanlayıcısının otomatik olarak devre dışı bırakılması (birisi tarafından onaylanıp temizlenene kadar)

• %80 - Kapasite Uyarısı
• %95 - Durum Kontrolü Sınırına ulaşıldı (bu işlem bazen, en azından manuel olarak onaylanana kadar yedekleme zamanlayıcısını devre dışı bırakabilir)
• %100 - Sunucu Salt Okunur Sınırına ulaşıldı (Kılavuz yönetici moduna geçer)

1. Avamar'ın tekilleştirme nedeniyle her bir istemci yedekleme işi arasındaki yalnızca küçük değişiklikleri ve farklılıkları kaydetmesi ve depolaması gerekir. Yeni yedeklemeler (veya gelen çoğaltmalar) çalıştırıldıkça yeni veriler eklenebilir ve Avamar kapasitesi veya kullanım değeri artabilir. 
2. Yedeklemeler yapılandırılmış saklama ve süre sonu işlemlerine göre belirli bir süre sonra sona erer ve geri yüklenebilir Avamar ızgarasında bulunamaz. 
3. Çöp Toplama (GC) adlı Avamar bakım işi çalıştırıldığında, süresi dolan bu yedeklemeler nedeniyle artık ihtiyaç duyulmayan tüm benzersiz veri bölümlerini veya parçalarını bulur. GC, aynı verileri başka hiçbir yedeklemenin paylaşmadığını doğrular (tekilleştirme nedeniyle) ve ardından Avamar sunucu kapasitesini veya kullanımını azaltmak için artık gerekli olmayan veri öbeklerini kaldırır veya serbest bırakır.

Eklenen günlük veri miktarı, temizlenen günlük veri miktarıyla yaklaşık olarak aynı olduğunda, buna "Sabit Durum" denir. Kurulan her Avamar ızgarasının amacı budur.

Yeni bir Avamar ızgarası kurulmadan ve yapılandırılmadan önce, yedekleme verilerini saklamak için gereken kapasiteyi belirlemek üzere genel kurulum öncesi boyutlandırma hesaplamaları yapılır. Bu hesaplamalar, müşterilerin saklama gereksinimlerine ve ne kadar verinin yedekleneceğine bağlıdır. Ayrıca, bu verilerin ortalama olarak ne kadarının tekilleştirilebileceğini de tahmin eder.

1. Çöp Toplama tutarlı bir şekilde çalışmıyor
2. Çöp Toplama performansı yavaş veya yeterince uzun sürmüyor
3. Avamar ızgara kurulumundan önceki tekilleştirme tahminleri yeterince doğru değil
4. Avamar ızgara kurulumundan önce hesaplananlar dışındaki veriler bu Avamar sunucusuna yedekleniyor.
5. Diğer nedenler

Aşağıdaki sorun giderme adımlarının her birinin ortam için doğru olduğunu doğrulayın:

1. Adım Veri Toplama:

Avamar ızgarasıyla ilgili kapasite dışı başka bir sorun olmadığından emin olun. Varsa sorun giderme kapasitesinden ÖNCE bunlarla ilgilenilmesi gerekebilir.

Buna donanım hataları, veri bütünlüğü sorunları (çevrimdışı düğümler dahil), çevrimdışı şeritler, kontrol noktası doğrulama hataları veya başarısız bakım işleri dahildir. Bunlardan herhangi biri sorunsa kapasite sorunlarını giderme işlemi durdurulmalı ve diğer sorunlar giderilmelidir. Diğer sorunlar çözüldükten sonra kapasite yeniden gözden geçirilebilir.

Bir sistem durumu kontrolü çalıştırılmalıdır (Avamar: Bir Avamar Server üzerinde proactive_check.pl durumu denetimi komut dosyasını çalıştırma, ancak en azından status.dpn Komutu, aynı sorunların çoğuna hızlı bir genel bakış ve doğrulama sağlayabilir. Bilgi için bkz. Avamar: status.dpn komutu tarafından oluşturulan çıktıyı anlama

Daha fazla bilgi için aşağıdaki makaleye bakın: Avamar: Avamar sorun giderme hiyerarşisi" yaklaşımını doğru şekilde uygulama.

Kapasite dışı sorunları gidermek için yardıma ihtiyaç duyarsanız Dell Technologies Avamar Destek ekibiyle bir Servis İsteği oluşturun .

Adım 2. Kapasite Bilgilerinin Toplanması: 

Avamar Kapasitesi sorunlarını gidermek için gereken tüm gerekli bilgiler için aşağıdakilere bakın: Avamar: Kapasite sorunlarını gidermek için bilgi toplama

En azından, status.dpn komutu veya Avamar Administration kullanıcı arayüzündeki değerler GSAN kapasite.

Aşama 3. İşletim Sistemi Kapasitesinin dolu olup olmadığını kontrol edin:

Aşağıdaki komut, her disk bölümü için İşletim Sistemi Kapasitesinin geçerli değerini göstermeye yardımcı olur. Değerlerden herhangi biri, ikinci örnek çıktısında olduğu gibi %85'e ulaştıysa veya bu değeri aştıysa yüksek İşletim Sistemi Kapasitesi olarak kabul edilir:

avmaint nodelist | egrep 'nodetag|fs-percent-full'

Örnek çıktılar:

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

Yalnızca işletim sistemi kapasitesi %85'in altındaysa GSAN Kapasite sorunlarını giderme işlemleri devam ediyor. 

Adım 4. Bazen Kapasite olarak yanlış anlaşılabilecek Kapasite dışı sorunlar:

İstemci yedeklemelerinin "Kapasite" nedeniyle değil, "Kota" nedeniyle başarısız olması mümkündür. Bunlar bazen Kapasite olarak yanlış anlaşılabilir.

Bu durum şu şekilde doğrulanabilir: status.dpn komutu veya daha düşük kapasiteyi gösteren diğer toplanan çıktılardan bazıları.

Diğer sorunlar nedeniyle istemci yedeklemeleri başarısız olmuş veya çalıştırılmamış da mümkündür. Non-GSAN Kapasite nedenleri. Toplanan bilgiler bunu doğrulamalıdır veya Avamar Administration kullanıcı arayüzünde de görülebilir.

• Avamar: Meta Veri Kapasitesi Çözümleme Yolu
• Data Domain: Avamar Entegrasyon Çözüm Yolundan Yüksek Kapasite

Eğer GSAN Kapasite yüksektir ve bu diğer Kapasiteler de yüksektir, sorun giderme işlemleri herhangi bir sırada gerçekleştirilebilir (her zaman ilk sırada olması gereken İşletim Sistemi Kapasitesi hariç).

Adım 5. Şerit Dengesi ve İşletim Sistemi Disk Dengesi:

Avamar'daki "Stripes", veri düğümlerinde (tek düğümlü Avamar ızgarası hariç) yedekleme verilerinin depolandığı kapsayıcı dosyalarıdır.

Beklenti, şeritlerin "dengeli" olması veya ızgaradaki farklı diskler ve düğümler arasında eşit olarak dağıtılmasıdır, ancak bazen dengesiz hale gelebilirler.

Avamar'daki tasarımı gereği, Avamar kapasitesi söz konusu olduğunda en büyük düğüm veya disk bölümü sınırlayıcı faktördür.

Bu kasıtlıdır, bu nedenle disklerin veya düğümlerin hiçbiri işleyebileceklerinden (veya izin verilenden) daha fazla şerit oluşturmaz; bu nedenle dengeli şeritlere sahip olmak Kapasite açısından önemlidir.

Örneğin, Avamar ızgara genişletmesi için ek veri düğümleri eklerken, genel Avamar Kapasitesi yüzdesini azaltmak için şeritleri yeni düğümlere eşit olarak dağıtmak üzere dengeleme çalıştırılmalıdır.

Anlaşılması gereken başka bir denge türü de işletim sistemi Disk dengesidir. Bu, yalnızca aynı düğümdeki veri bölümleriyle sınırlıdır, birden çok düğümdeki bölümlerle sınırlı değildir. 

Aynı veri düğümünde, bir bölüm AYNI düğümün başka bir bölümünden çok daha büyük veya daha küçükse, "freespaceunbalance". Bu genellikle işletim sisteminde olsa da, GSAN Kapasite, olarak raporlanabilir GSAN Kapasite sorunu.

Adım 6. Çöp Toplama işleminin tamamlanıp tamamlanmadığını kontrol edin: 

Çöp toplama hakkında bilgi almak için aşağıdaki komutu çalıştırın:

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

İdeal olarak çıktı, GC'nin son 30 gün içinde tamamlandığını gösterir:

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

GC hata mesajları, bunlarla sınırlı olmamak üzere aşağıdakileri içerebilir:

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

GC başarısız oluyorsa, aşağıdaki makaleyi referans olarak kullanarak önce bunu ele alın: Avamar: Çöp Toplama (GC) Arızalarında Sorun Giderme (Çözüm Yolu)
(Herhangi bir sorun zaten çözüldüyse bir sonraki adıma geçin.)

Adım 7. GC yeterince uzun süre çalışıyor mu?

a. GC için izin verilen maksimum süreyi kontrol etmek için aşağıdaki komutu çalıştırın:

dumpmaintlogs --types=gc --days=30 | grep gcflags 

Örnek çıktı:

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

Not alın maxtime Bu örnekte 14400 (saniye) değeridir.
(0 değeri sınırsız anlamına gelir)

b. GC'nin ne kadar süreyle çalıştığını ve kaç "geçişin" tamamlandığını belirlemek için aşağıdaki komutu çalıştırın:
(Geçişler, depolanan yedekleme verilerinin katmanlarıyla ilgilidir. Düşünün GSAN Bir soğanın katmanları gibi kapasite. İç katmanlar görülmeden önce dış katmanlar soyulmalı veya çıkarılmalıdır. Her geçiş, GSAN Saklanan veriler.)

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

Örnek çıktı:

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

Geçiş sayısını not edin ve elapsed-time (saniye).

c. maxtime sıfır değilse, 2/3'ünü hesaplayın maxtimeve geçen süre ile karşılaştırın.
(Yukarıdaki örnekte 14400'ün 2/3'ü 9600'dür ve tüm geçen zaman çıktıları bu rakamın oldukça altındadır.)

Çeşitli sorunlar GC'nin yavaş çalışmasına veya her şeyi taramamasına neden olabilir. Bu, geçmişte önemli miktarda veya gün boyunca çalıştırmak için yeterli zamanınızın olmaması, yanlış yapılandırma, hatalar ve daha fazlasını içerebilir.

Hakkında endişeleriniz varsa maxtimeseçeneğine veya geçiş sayısına ulaşırsanız daha fazla araştırma yapmak için Dell Technologies Avamar Destek Ekibiyle bir Servis İsteği oluşturun .

Adım 8. GC'nin yeterli veya beklenen verileri kaldırmadığından şüpheleniyorsa:

GC'nin yeterince uzun süre çalıştığı doğrulanırsa veriler Çöp Toplama denetimi dışındaki nedenlerle toplanmıyor olabilir. Bu, genel olarak kontrol edilmesi gereken belgelenmiş nedenlerin bir listesidir:

a. Yedeklemelerin en azından bir süre sonra veya düzenli olarak sona erecek şekilde yapılandırıldığını doğrulayın. Sık sık süresi dolan yedeklemeler yoksa GC'nin yapacak fazla bir işi olmayacaktır.

b. "En Yüksek Değişim Oranı" İstemcilerini bulmak için bu makaleyi kullanın: Avamar: capacity.sh komut dosyasıyla kapasiteyi yönetme. (Her ikisini de gözden geçirin "% OF TOTAL" ve "CHGRATE".)

c. Avamar'a göre atlanan karmaları kontrol edin: Avamar Çöp Toplama, temizlenemeyen "atlanan karmalar" bildiriyor. Bunlar nadir de olsa meydana geliyorsa bu durum normaldir ve atlanabilir.

d. Avamar sunucusunu her istemciden en son ve en son yedeklemeyi tutmaya zorlayan bir bayrak veya seçenek vardır. Bu, istemcinin tüm yedeklemelerinin yanlışlıkla süresinin dolmasını önlemek için güvenlik amacıyla kullanılır. Ancak bu, veri temizleme ve Çöp Toplama söz konusu olduğunda başka sorunlara neden olabilir. Dell Technologies Avamar Destek ekibi bunun etkin olup olmadığını onaylayabilir.

e. Yedeklemeler yakın zamanda değiştirilmişse GSAN DD arka ucuna veya yanlışlıkla bir GSAN yedekleme, ancak GSAN Kapasite azalmazsa daha fazla araştırma için Dell Technologies Avamar Destek Ekibi ile bir Servis İsteği oluşturun .

Adım 9. Avamar ızgarası, eklenecek mevcut veya beklenen veri miktarı için küçüktür:

Yüksek kapasite için diğer tüm çözümler ve olası nedenler gözden geçirildikten sonra; bu, bir yapılandırma sorunu veya tesadüfi verilerle ilgili bir sorun değildir:

Bu, verilerin silinmesi veya belirli istemcileri diğer Avamar ızgaralarına taşıma, yeni veri düğümleri ekleme vb. seçeneklerin araştırılması gerekebileceği anlamına gelir.

Adım 10. Kapasite olaylarını onaylayın ve gerekirse yedekleme zamanlayıcısını devam ettirin:

a. Kapasite sorunları giderildikten sonra Avamar Admin UI'da kapasiteyle ilgili tüm olayları onaylayın.

b. Yedekleme zamanlayıcısını devam ettirin:

dpnctl start sched

Avamar Capacity ile ilgili diğer sorular, eğitim, sorun giderme ve daha fazlası için bkz.: Avamar: Kapasite Sorun Giderme, Sorunlar ve Sorular - Tüm Kapasite (Çözüm Yolu)

• Bu eylem kendi başına gerçek sorunları "maskeleyebilir" ve gizleyebilir, ancak birkaç gün veya hafta sonra tekrar ortaya çıkmalarına neden olarak bu manuel işin boşa harcanmasına neden olabilir.
• Buna ek olarak manuel GC, zamanlama dışı kaldığı için verimli çalışmayabilir.
  • Bazen, diğer sorunları daha da kötüleştirebilir. Daha fazla bilgi için bkz: Avamar: Manuel Çöp Toplama kullanımı hakkında

• Bu değişiklik veya eylem genellikle gerçekleştirilmez ve varsayılan olarak dikkate alınmamalıdır. Bir Avamar L2 mühendisi veya Konu Uzmanı (SME) bu değişikliği onaylamalıdır.
• Ne yazık ki, bu tür eylemler genellikle Avamar ızgarasında çeşitli şekillerde kalıcı hasara neden olabilir ve bu sorun yalnızca ek depolama düğümleri eklenerek veya yeniden dağıtımla çözülebilir.

Destek ekibi, Kapasite sorunlarının en faydalı şekilde çözülmesine yardımcı olmak istediği için yukarıda listelenen eylemlerin hiçbirinin gerçekleştirilmediğini anlayın.