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

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

Kapasitesini, istemci yedeklemeleri için ayrılan alan ve bu alanın kullanım oranı GSAN olarak değerlendirmek genellikle en kolay yaklaşımdır.

• Tekilleştirme hakkında temel bilgiler
• Kontrol noktası, kontrol noktası doğrulama (hfscheck) ve Çöp Toplama hakkında temel bilgiler ve her birinin önemi.
• (veya Kullanıcı) Kapasitesi ile GSAN İşletim Sistemi Kapasitesi arasındaki fark
• Değişim Oranı
• Sabit Durum

• Izgara erişim durumu "admin mode" (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 Denetimi 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ı (Izgara admin mode'a [yönetici modu] 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. Belirli bir süre sonra, yedeklemeler yapılandırılmış saklama ve süre sonu işlemlerine göre sona erer ve Avamar ızgarasında geri yükleme için bulunmaz. 
3. Çöp Toplama (GC) olarak adlandırılan 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 öbeklerini bulur. GC, başka hiçbir geçerli yedeklemenin aynı verileri paylaşmadığını doğrular (tekilleştirme nedeniyle) ve ardından Avamar Server 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 gelen veri miktarı, temizlenen günlük veri miktarıyla yaklaşık olarak aynı olduğunda, buna "Sabit Durum" denir. Yüklenen her Avamar ızgarasının amacı budur.

Yeni bir Avamar ızgarası kurulup yapılandırılmadan önce, yedekleme verilerini depolamak için gereken kapasiteyi belirlemek üzere genel önyükleme 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 vb. tahmin eder.

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

Aşağıdaki her sorun giderme adımının 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 sorun teşkil ediyorsa kapasite sorunlarını giderme işlemi durdurulmalı ve diğer sorunlar ele alınmalıdır. Diğer sorunlar çözüldükten sonra kapasite yeniden gözden geçirilebilir.

Bir durum denetimi çalıştırılmalıdır (Avamar: Avamar Server'da proactive_check.pl sistem durumu denetimi komut dosyasını çalıştırma ancak komut status.dpn minimumda 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ım gerekirse Dell Technologies Avamar Destek ekibine bir Servis Talebi oluşturun.

2. Adım. Kapasite Bilgisi Toplama: 

Avamar Kapasitesi sorunlarını gidermek için gereken tüm 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 kapasiteyi gösterir.

3.Adım. İş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ıda 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 Kapasitesi sorun giderme işlemleri devam ettirilmelidir. 

4. Adım. 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, status.dpn komutu veya daha düşük kapasiteyi gösteren diğer toplanan çıktılardan bazıları ile doğrulanabilir.

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

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

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

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

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

Şeritlerin "dengeli" olması veya ızgaradaki farklı diskler ve düğümler arasında eşit olarak dağıtılması beklenir 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, hiçbir disk veya düğümün işleyebileceğinden (veya izin verilenden) daha fazla şerit oluşturmaması için kasıtlı olarak yapılmıştır; bu nedenle, dengeli şeritlere sahip olmak Kapasite için ö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, birden fazla düğümdeki bölümlerle değil, yalnızca aynı düğümdeki veri bölümleriyle sınırlıdır. 

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 bir sınır aşılabilir ve bu da şu şekilde adlandırılır: "freespaceunbalance". Bu GSAN Kapasitesinde değil, genellikle işletim sisteminde olsa da GSAN Kapasitesi sorunu olarak bildirilebilir.

6. Adım. Çö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ı, son 30 gün için GC'nin 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ı aşağıdakileri içerebilir ancak bunlarla sınırlı değildir:

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 öncelikle aşağıdaki makaleyi referans olarak kullanarak bu sorunu ele alın: Avamar: Çöp Toplama (GC) Hatalarında Sorun Giderme (Çözüm Yolu)
(Herhangi bir sorun zaten çözülmüşse bir sonraki adıma geçin.)

7. Adım. 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"/>

Bu örnekte maxtime 14400 (saniye) olan değerini not edin.
(0 değeri sınırsız anlamına gelir)

b. GC'nin ne kadar süre ç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. Kapasitesini GSAN bir soğanın katmanları gibi düşünün. İç katmanlar görülmeden önce dış katmanlar soyulmalı veya çıkarılmalıdır. Her geçiş, GSAN depolanan verilerin bir katmanıdır.)

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ı ve elapsed-time (saniye) not edin.

c. Sıfır olmadığını varsayarak maxtime 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 süre çı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. Bunlar arasında, geçmişte önemli bir süre veya günler boyunca çalıştırmak için yeterli zamanın olmaması, yanlış yapılandırma, hatalar ve daha fazlası sayılabilir.

veya geçiş sayısı ile ilgili endişeleriniz varsa maxtimedaha ayrıntılı inceleme için Dell Technologies Avamar Destek Ekibine bir Servis Talebi oluşturun.

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

GC'nin yeterince uzun süre çalıştığı doğrulandıysa veriler, Çöp Toplama denetimi dışındaki nedenlerle toplanmıyor olabilir. Genel olarak kontrol edilmesi gereken belgelenmiş nedenlerin listesi şu şekildedir:

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ı"na sahip İstemcileri bulmak için bu makaleyi kullanın: Avamar: capacity.sh komut dosyasıyla kapasiteyi yönetme. (Hem "% OF TOTAL" hem de "CHGRATE" gözden geçirin.)

c. Atlanan karmaları şu makaleye göre kontrol edin: Avamar: Avamar Çöp Toplama, temizlenemeyen "atlanan karmalar" bildirir. Bunlar nadir de olsa meydana geliyorsa bu durum normaldir ve atlanabilir.

d. Avamar Server'ı her istemciden en son ve en yeni 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 GSAN DD arka ucuna geçirildiyse veya yanlışlıkla bir GSAN yedeklemesi olduysa ancak GSAN Kapasitesi azalmıyorsa daha ayrıntılı inceleme için Dell Technologies Avamar Destek Ekibine bir Servis Talebi oluşturun.

9.Adım. 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 bunun bir yapılandırma sorunu veya yanlışlıkla oluşmuş bir veri sorunu olmadığı tespit edildiğinde:

Bu, verilerin silinmesini veya belirli istemcilerin diğer Avamar ızgaralarına taşınmasını, yeni veri düğümlerinin eklenmesini vb. seçeneklerin değerlendirilmesini gerektirebilir.

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

a. Kapasite sorunları giderildikten sonra Avamar Admin kullanıcı arayüzünde 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 içinde gerçek sorunları "maskeleyebilir" ve gizleyebilir ancak birkaç gün veya hafta sonra tekrar ortaya çıkmalarına neden olarak bu manuel işin zaman kaybına dönüşmesiyle sonuçlanır.
• Buna ek olarak manuel GC, zamanlama dışında çalıştığı 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 değerlendirilmemelidir. Bu değişikliğin bir Avamar L2 mühendisi veya Konu Uzmanı (SME) tarafından onaylanması gerekir.
• Ne yazık ki bu tür eylemler genellikle Avamar ızgarasında çeşitli şekillerde kalıcı hasara neden olabilir ve bu hasar yalnızca ek depolama düğümleri eklenerek veya yeniden dağıtım ile çö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 unutmayın.