Avamar: İşletim Sistemi (OS) Kapasitesi (Çözüm Yolu)

Avamar'da İşletim Sistemi Kapasitesi sorunlarını işleme veya giderme.

Bu Çözüm Yolu makalesi, Avamar'daki işletim sistemi kapasitesi sorunlarını ele almak veya gidermek için tasarlanmıştır.


İşletim Sistemi Kapasitesi ile ilgili temel kavramlar ve bilgiler için Avamar eğitim makalesine bakın: Kapasite Yönetimi Kavramları ve Eğitimi

Eğitim makalesinde özetlendiği gibi, bu makalenin geri kalanına devam etmek için aşağıdaki konuların makul bir şekilde anlaşılması gerekir:

• Kontrol noktaları (cp), kontrol noktası doğrulama (hfscheck)ve Çöp Toplama (GC) ve her birinin önemi
• Arasındaki fark GSAN ("Kullanıcı Kapasitesi" ve İşletim Sistemi Kapasitesi olarak da bilinir)
• Kontrol noktası ek yükü verileri
• Veri bölümlerinden herhangi biri toplam fiziksel işletim sistemi kapasitesi alanının %89'undan fazlaysa çöp toplama işlemi çalıştırılamaz.
• Avamar ızgarası %100 Kullanıcı kapasitesine ne kadar yakınsa kontrol noktası ek yükü için o kadar az işletim sistemi kapasitesi vardır.
• Asenkron çatırtı, depolanan kontrol noktası sayısı dahil olmak üzere kontrol noktası ek yüküne katkıda bulunan faktörler, HFSCheck ve kontrol noktası doğrulaması, önemi vb.
• İşletim Sistemi Kapasite düzeylerini bulma
• İşletim Sistemi Kapasitesini azaltmak için temel eylemler

Genellikle en kolay yöntem, işletim sistemi kapasitesinin GSAN verileri (daha spesifik olarak bu veriler için ayrılan alan) ve Avamar kontrol noktaları tarafından oluşturulan ek yük. Kontrol noktalarının sayısı ne kadar fazla ve değişim oranı ne kadar yüksekse, kontrol noktası ek yükü de o kadar yüksek olur.

Yüksek işletim sistemi kapasitesinin etkileri arasında şunlar olabilir:

• Garbage Collection Failure: GC, MSG_ERR_DISKFULL ile başarısız oluyor işletim sistemi kapasitesi %89'un üzerine çıkarsa
• Yedekleme veya Çoğaltma hatası: İşletim Sistemi Kapasitesi %90'ın üzerine çıkarsa yedeklemeler veya gelen çoğaltma işlemleri MSG_ERR_STRIPECREATE vererek başarısız olabilir. (Bu yalnızca yeni bir veri şeridi oluşturulması gerektiğinde geçerlidir. Yeni bir şerit gerekmese de yedekleme ve çoğaltma başarıyla çalışabilir.)
• Checkpoint Failure: İşletim sistemi kapasitesi %96'nın üzerine çıkarsa kontrol noktası MSG_ERR_DISKFULL ile başarısız oluyor

Yukarıdakilerden de anlaşılacağı üzere İşletim Sistemi Kapasitesi, diğer Avamar Kapasiteleri de yüksek olduğunda genellikle ele alınması gereken ilk Avamar Kapasitesi türüdür. En azından, İşletim Sistemi Kapasitesi belirli düzeylere ulaştığında bile Çöp Toplama çalıştırılamaz. GSAN veya kullanıcı kapasitesi de yüksektir.

Genel olarak, GC başarısız olduğunda MSG_ERR_DISKFULL işletim sistemi kapasitesi %89'un üzerine çıktığında İşletim Sistemi Kapasitesi yüksek kabul edilir. İşletim Sistemi Kapasitesi %89'un altındaysa hiçbir bakım işi etkilenmez. 

Avamar OS Kapasitesi, aşağıdaki nedenlerin herhangi bir kombinasyonu nedeniyle artabilir:

• Yedekleme verilerinin Yüksek Değişim Hızı, "çok fazla çok hızlı" ekleme
• Yüksek GSAN veya İşletim Sistemi Kapasitesi için daha az yer bırakan ve hatta bazen daha yüksek değişiklik oranlarına neden olabilen "Kullanıcı Kapasitesi"
• Kontrol noktası başarıyla tamamlanamıyor, bu da çıktıda görüldüğü gibi "MSG_ERR_DISKFULL" durumuyla sonuçlanıyor.
• Kontrol noktası doğrulaması (hfscheck) yakın zamanda başarısız oldu veya çalışmadı, bu nedenle en eski kontrol noktaları devredilemez veya kaldırılamaz
• Kontrol noktaları, kontrol noktası tutma ayarlarının çok yüksek olması da dahil olmak üzere başka nedenlerle devre dışı bırakılmıyor

Diğer disk bölümlerindeki yüksek işletim sistemi kapasitesi, yanlış veri yerleşimi, günlük dosyalarının çok büyük olması vb. gibi çeşitli nedenlerden kaynaklanabilir.

• Hızlı bir arka plan için Avamar kontrol noktaları, salt okunur bir anlık görüntü ve canlı verilere bağlantıdır. Bu, bağlantılarla oluşturulduğu için oluşturulduktan hemen sonra sıfır ekstra disk alanı kullanır. Canlı verilerde herhangi bir değişiklik yoksa kontrol noktası ek alan kullanmaz.
• Kontrol noktası aynı kalırken canlı veriler değiştikçe bu durum değişir. Bu noktada, kontrol noktasındaki verilerin orijinal bir kopyası ve değiştirilen verilerin güncellenmiş canlı kopyası bulunur. Bu tamamen tasarım gereği ve kasıtlıdır. Bu nedenle ayrılmış İşletim Sistemi Kapasitesi alanı vardır.
• Ancak değişiklik verilerinin miktarı veya hızı aniden ve büyük ölçüde artarsa bu durum, işletim sistemi kapasitesi boyutunda alışılmadık bir ani artışa neden olabilir ve "çok fazla çok hızlı" olarak değerlendirilebilir
• Komutta capacity.sh aracı, çıktıyı birkaç gün boyunca karşılaştırırken bunu neden olarak gösterir.

Çöp Toplama dahil olmak üzere yüksek Avamar OS Kapasitesi nedeniyle bakım işleri başarısız oluyorsa şu adımları izleyin:

1. Durumun bir resmini çizmek için tüm Avamar Capacity bilgilerini toplayın: Avamar: Kapasite sorunlarını gidermek için gereken bilgileri toplama.

2. Ardından, işletim sistemi kapasitesinin ne kadar yüksek olduğunu ve hangi eylemlerin gerekli olabileceğini gözden geçirin. Veri toplama makalesinden bu, aşağıdaki komut kullanılarak bulunabilir: 

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

Avamar'ın çalışma şekline göre fs-percent-full için gösterilen EN YÜKSEK değer, geçerli işletim sistemi kapasitesi için sınırlayıcı faktördür. Düğüm tipine, oluşturulmasına ve boyutuna bağlı olarak, yedekleme ve kontrol noktası verilerini depolayan veri bölümlerinin sayısı değişebilir. Linux İşletim Sisteminden görüldüğü gibi, bunlar "/data0*" gibi diskler veya bölümler olabilir, burada "*" tek bir rakam olabilir. Veri bölümlerinin sayısı düğüm tipine, donanım nesline ve boyutuna bağlıdır (ve değiştirilemez).

3. Bulunan kontrol noktalarının sayısını ve bunların komuttan ne yakın zamanda doğrulandığını gözden geçirin:

cplist

cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980

4. Aşağıdaki komutu çalıştırarak denetim noktası işlemlerinin "MSG_ERR_DISKFULL"dan başarısız olup olmadığını doğrulayın:

dumpmaintlogs --types=cp --days=4 | grep "\<430"

Kontrol noktaları başarıyla tamamlandıysa aşağıdakine benzer bir çıktı görünür:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

MSG_ERR_DISKFULL nedeniyle başarısız olursa şu çıktı gösterilir:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

6. Değişim oranını belirleyin:

capacity.sh  

Örnek çıktı:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

Bazen yüksek değişim oranı veya "çok fazla çok hızlı" durumu tekrarlanırsa, bu, genel değişim oranının düşürülmesiyle hafifletilebilir. GSAN veya kullanıcı kapasitesi. Daha düşük bir GSAN kapasite, İşletim Sistemi Kapasitesi ek yükü için biraz daha fazla alan vardır ve ayrıca daha az veri depolama kapsayıcısı değişikliğine neden olur. Bu senaryoyla ilgili yardım için Dell Technologies Avamar Destek ekibine bir Servis İsteği açın , aksi takdirde 7. adımdan devam edin.

7. Diğer disk bölümlerindeki yüksek işletim sistemi kapasitelerine sahip sorunların çeşitli nedenleri vardır ancak çözümler teknik destek gerektirir. Dell Technologies Avamar Destek ekibine bir Servis İsteği açın, aksi takdirde 7. adımdan devam edin.

İşletim Sistemi Kapasitesi karşılandıktan sonra, GSAN kapasitesi veya diğer Avamar kapasiteleri gözden geçirilebilir. Bkz. Avamar Kapasite Sorun Giderme, Sorunlar ve Sorular - Tüm Kapasite (Çözüm Yolu)