[TR] Dell-EMC Data Domain Sistemlerinde Bellek Gereksinimleri ve Genişletilmiş Depolama Yapılandırmaları Notları

Kurumsal yedekleme altyapılarında Dell EMC Data Domain sistemleri yüksek veri koruma verimliliği, deduplikasyon başarımı ve ölçeklenebilir mimarisi sayesinde uzun yıllardır kritik bir konumda yer alıyor.

Ancak bu sistemlerde kapasite artırımı yapılırken gözden kaçırılan en önemli konulardan biri depolama genişlemesi ile sistem belleği arasındaki doğrudan ilişkidir.

Çünkü Data Domain tarafında yalnızca disk eklemek yeterli değildir eklenen kapasitenin sağlıklı biçimde çalışabilmesi için sistemin bellek yapısının da desteklenen konfigürasyona uygun olması gerekir.

Aksi durumda dosya sistemi devre dışı kalabilir, genişletme işlemi başarısız olabilir veya beklenen kullanılabilir kapasiteye ulaşılamayabilir.

Bu nedenle Data Domain platformlarında kapasite planlaması yapılırken yalnızca “kaç TB disk eklenebilir” sorusuna değil aynı zamanda “bu kapasite için ne kadar RAM gerekir, kaç shelf desteklenir, hangi I/O modülleri kullanılmalıdır, cache ve metadata yapısı nasıl konumlandırılmalıdır?” sorularına da net yanıt verilmelidir.

Bu makalemde tam olarak bu ihtiyaca cevap veriyor ve farklı Data Domain modelleri için bellek ile kapasite eşleşmelerini detaylandırıyor.

Neden bellek kapasitesi bu kadar önemli?

Data Domain mimarisinde bellek yalnızca işletim sistemi veya temel servisler için kullanılan pasif bir kaynak değildir.

Bellek dosya sistemi yönetimi, metadata işleme, veri yerleşimi, deduplikasyon süreçleri ve genişleyen shelf mimarisinin stabil biçimde çalıştırılması açısından kritik rol oynar.

Sisteme yeni shelf eklendiğinde kapasite artışı yalnızca fiziksel disk sayısını büyütmez; aynı zamanda yönetilmesi gereken metadata miktarını, cache ihtiyacını ve işlem yükünü de artırır. İşte bu yüzden birçok modelde belirli kapasite seviyelerinin üzerine çıkabilmek için ek RAM zorunludur.

Yanlış yapılandırılmış bir ortamda en sık görülen belirtiler arasında şunlar yer alır yeni shelf eklenememesi, storage expansion işleminin tamamlanamaması, dosya sisteminin başlatılamaması, kullanılabilir alanın beklenenden düşük görünmesi ve sistem tarafından “misconfiguration” uyarılarının üretilmesi.

Özellikle “Memory size goes below the configured size” benzeri alarmlar, sistem belleğinin mevcut yapılandırmayı desteklemediğini açık biçimde gösterir. Bazı durumlarda sistem doğrudan kernel logger modunda açılabilir ve normal servisler devreye giremez.

Yanlış yapılandırmanın başlıca nedenleri

Sahada karşılaşılan sorunların önemli bir kısmı planlama aşamasındaki eksiklerden kaynaklanır. En yaygın senaryo, sisteme ek shelf takılması ancak buna karşılık gelen memory kit yükseltmesinin yapılmamasıdır. Yani fiziksel disk kapasitesi büyütülür fakat sistemin bu genişlemeyi yönetebilmesi için gereken RAM eklenmez.

Bunun dışında chassis swap işlemlerinde mevcut bellek modüllerinin yeni kasaya taşınmaması DIMM modüllerinin arızalı olması, yanlış slota takılması veya tam oturmaması da benzer sonuçlar doğurabilir. Bazı ortamlarda ise sorun donanımdan değil de lisans tarafından kaynaklanır gerekli lisansların eklenmemesi veya güncellenmemesi de kapasite kullanımını kısıtlayabilir.

Bu tip hatalar genellikle genişletme sonrası ortaya çıkar. Sistem yöneticisi yeni shelf’in fiziksel olarak göründüğünü fark eder ancak beklediği kapasite artışını göremez. Daha ileri vakalarda dosya sistemi hiç başlamaz ve olay yalnızca kapasite kaybı olmaktan çıkıp doğrudan servis kesintisine dönüşür. Bu nedenle Data Domain üzerinde kapasite artırımı yapılacaksa işlem öncesinde modelin desteklediği bellek-shelf-kapasite üçlüsünün mutlaka doğrulanması gerekir.

Kontrol için kullanılabilecek temel Data Domain CLI komutları

Belgede, mevcut donanım ve konfigürasyonu teyit etmek için çeşitli Data Domain CLI komutları öneriliyor. Örneğin system show meminfo komutu kurulu bellek bilgilerini, system show hardware fiziksel donanım özetini, enclosure show memory ve enclosure show topology ise enclosure seviyesindeki bellek ve topoloji bilgisini gösterebilir. filesys show space kullanılabilir alanı doğrulamak için önem taşırken, storage show all ve elicense show all komutları da kapasite ve lisans tarafındaki eksikleri tespit etmede oldukça değerlidir. Yanlış yapılandırma şüphesinde bu komutların çıktıları, ilgili modelin desteklenen referans mimarisiyle karşılaştırılmalıdır.

Eski nesil modellerde bellek ve kapasite ilişkisi

Data Domain’in daha eski modellerinde yapılandırmalar bugünkü kadar esnek olmasa da bellek-kapasite bağı yine kritik öneme sahipti. Örneğin DD160 modeli 6 TB depolama için 6 GB bellek ile sınırlıyken, DD620 modeli 12 TB’a kadar 8 GB bellekle çalışıyordu. DD2200 serisinde ise 4 TB giriş seviyesi model 8 GB RAM ile gelirken, 14/24 TB varyantlarında bu değer 16 GB’a çıkıyordu ve harici depolama desteği bulunmuyordu. Bu detaylar, küçük ölçekli sistemlerde bile bellek ile kapasite arasındaki orantının tasarımın temel parçası olduğunu gösteriyor.

Benzer şekilde DD2500 modelinde 32 GB RAM ile temel yapılandırma sunulurken maksimum 1 adet 30 TB SAS shelf destekleniyor; sistem 64 GB RAM’e çıkarıldığında ise 4 adet 30 TB veya 3 adet 45 TB shelf seviyesine kadar genişleyebiliyordu. Bu da bellek artışının yalnızca performans değil, doğrudan genişleme hakkı sağladığını gösteren iyi bir örnek.

Orta segment Data Domain sistemlerinde büyüme mantığı

Orta segmentte yer alan DD4200, DD4500, DD6300, DD6800 ve DD7200 gibi modellerde bellek yükseltmesinin etkisi çok daha belirgin hale geliyor. Örneğin DD4200, 128 GB RAM ile 8 adet 30 TB veya 5 adet 45 TB shelf’e kadar çıkabilirken, Extended Retention senaryosunda daha fazla shelf ve çift katmanlı aktif/arşiv yapı desteklenebiliyor. Cloud Tier kullanılan senaryolarda ise aktif katman için ayrı, bulut metadata alanı için ayrı shelf gereksinimleri devreye giriyor. Bu da sistem tasarımının yalnızca kapasite değil, kullanım senaryosuna göre de değiştiğini gösteriyor.

DD4500 tarafında 192 GB RAM temel yapılandırma için yeterliyken, Extended Retention ve Cloud Tier gibi senaryolarda shelf sayısı, metadata alanı ve SAS I/O modülü gereksinimi artıyor. Özellikle retention ve cloud mimarilerinde yalnızca aktif kapasiteye değil, metadata ve archive tier tarafına da kaynak ayrılması gerekiyor. Bu nedenle bu platformlarda kapasite planlaması yapılırken “toplam disk sayısı” yerine “aktif katman + arşiv + metadata” olarak düşünmek daha doğru olur.

DD7200 modeli ise iyi bir örnek sunuyor: 128 GB RAM ile temel konfigürasyonda 360 TB RAW seviyesine çıkılabilirken, 256 GB RAM ile 540 TB RAW kapasiteye kadar genişleme mümkün oluyor. Extended Retention ile bu sınır daha da yukarı taşınırken, Cloud Tier senaryosunda ayrıca metadata shelf zorunluluğu doğuyor. Yani aynı model, kullanılan bellek ve lisans türüne göre tamamen farklı ölçeklerde çalışabiliyor.

Yeni nesil ve büyük ölçekli modellerde durum

Kapasite büyüdükçe bellek gereksinimi de dramatik biçimde artıyor. DD9300, DD9500, DD9800 ve yeni nesil PowerProtect DD6900/DD9400/DD9900 ailesi bunun en net örneklerini oluşturuyor. Örneğin DD9300 temel yapılandırmada 192 GB bellekle gelirken, genişletilmiş yapıda 384 GB RAM ile çok daha yüksek aktif, archive ve cloud tier kapasitesi destekleniyor. Metadata on Flash (MDoF) tarafında da SSD sayıları artıyor; bu durum yüksek kapasiteyle birlikte metadata yönetiminin ne kadar önemli hale geldiğini gösteriyor.

DD9500 ve DD9800 modelleri ise shelf sayısı, I/O modülü, aktif katman ve cloud tier kapasitesi bakımından çok daha büyük yapılara hitap ediyor. DD9500’de temel yapılandırma 256 GB RAM ile 540 TB RAW kapasite sunarken, expanded konfigürasyonda 512 GB RAM ile bu değer 1080 TB RAW seviyesine çıkabiliyor. Extended Retention kullanıldığında toplam kapasite 2160 TB RAW düzeyine kadar uzanabiliyor. DD9800 tarafında ise expanded yapı 768 GB RAM ile 1260 TB RAW aktif kapasiteye, retention senaryosunda bunun iki katına kadar çıkabiliyor. Cloud Tier kullanımında metadata shelf ihtiyacı ve toplam kullanılabilir kapasite de buna paralel şekilde büyüyor.

Yeni nesil PowerProtect DD6900, DD9400 ve DD9900 sistemlerinde artık yalnızca kapasite değil, shelf tipi uyumluluğu da önem kazanıyor. Bu modellerde sadece SAS shelf desteği bulunuyor; SATA shelf desteklenmiyor. Ayrıca bazı disk tipleri yalnızca controller headswap yükseltmelerinde desteklenirken, yeni kurulumlarda kullanılmıyor. Örneğin DD6900 modelinde 288 GB RAM, DD9400’de 576 GB RAM, DD9900’da ise 1152 GB RAM gibi çok yüksek bellek miktarlarıyla çalışılıyor. Bu rakamlar, modern Data Domain platformlarının metadata, cache tier ve cloud tier operasyonları için ne kadar yoğun kaynak kullandığını açık biçimde ortaya koyuyor.

PowerProtect DD3300 gibi giriş seviyesi modeller neden farklı?

Öte yandan tüm Data Domain ailesi büyük ölçekli değildir. PowerProtect DD3300 gibi daha kompakt sistemlerde yapı çok daha kapalıdır. Bu modelin 4 TB, 16 TB ve 32 TB kullanılabilir kapasiteye sahip varyantları bulunur ve harici storage eklenemez. 4 TB model yalnızca 16 TB’a, 16 TB model ise 32 TB’a genişletilebilir; fakat 4 TB model doğrudan 32 TB’a çıkarılamaz. Her varyantta bellek miktarı ve disk yerleşimi farklıdır. Bu da küçük modellerde bile üretici tarafından tanımlanan büyüme yolunun dışına çıkılamayacağını gösterir.

Cloud Tier ve Extended Retention neden özel planlama ister?

Birçok kurum Data Domain’i yalnızca aktif yedekleme alanı olarak değil, aynı zamanda uzun süreli saklama ve bulut entegrasyonu için de kullanıyor. Bu noktada Extended Retention ve Cloud Tier yapıları devreye giriyor. Ancak bu iki senaryo, temel active tier yapılandırmasına göre daha fazla bellek, daha fazla SAS bağlantısı ve çoğu zaman ekstra metadata shelf gerektiriyor. Örneğin bazı modellerde Cloud Tier için ayrı metadata shelf sayısı açıkça tanımlanmış durumda; bazı büyük modellerde 4 veya 5 adet 60 TB metadata shelf zorunlu hale geliyor. Bu gereksinim göz ardı edildiğinde sistem teoride cloud tier lisansına sahip olsa bile pratikte stabil çalışmayabilir veya desteklenen kapasite sınırlarına ulaşamayabilir.

Operasyonel açıdan çıkarılması gereken dersler

Bu dokümandan çıkarılacak en önemli sonuç şudur: Data Domain sistemlerinde kapasite artışı, sadece disk ekleme işi değildir. Her büyüme adımı; RAM kapasitesi, SAS I/O modülü sayısı, shelf tipi, metadata alanı, lisans durumu ve modelin desteklediği mimari sınırlar çerçevesinde değerlendirilmelidir. Aksi halde görünürde küçük bir donanım eklemesi, doğrudan dosya sistemi kesintisine neden olabilir.

Sahadaki operasyon ekipleri için en sağlıklı yaklaşım, herhangi bir genişletme öncesinde şu soruların yanıtını netleştirmektir: Mevcut model hangi bellek seviyesinde çalışıyor? Eklenmek istenen shelf sayısı bu RAM ile destekleniyor mu? Cloud Tier veya Extended Retention varsa metadata ve cache gereksinimleri karşılanıyor mu? Gerekli lisanslar tanımlı mı? DIMM yerleşimleri üretici dokümantasyonuna uygun mu? Bu kontrol listesi uygulanmadan yapılacak her genişletme işlemi risk taşır.

Data Domain platformları son derece güçlü ve ölçeklenebilir sistemlerdir; ancak bu ölçeklenebilirlik tamamen desteklenen konfigürasyon kuralları çerçevesinde mümkündür. Özellikle bellek ve depolama kapasitesi arasındaki ilişki, sistemin sağlıklı çalışmasının temel taşlarından biridir. Yetersiz RAM ile yapılan kapasite artışları; performans sorunlarından dosya sistemi kapanmasına kadar uzanan ciddi sonuçlar doğurabilir. Bu nedenle her Data Domain modelinde kapasite planlaması yapılırken yalnızca disk sayısına değil, bellek konfigürasyonuna, shelf mimarisine, lisans durumuna ve metadata gereksinimlerine birlikte bakılmalıdır. Doğru planlanmış bir yapılandırma, hem genişleme süreçlerini sorunsuz hale getirir hem de veri koruma altyapısının uzun vadede stabil ve desteklenebilir kalmasını sağlar.