Veeam Backup & Replication Mimarisi: Proxy, Repository ve Transport

Gece başlayan yedek işi sabah 09:00’da hâlâ çalışıyorsa sorun genellikle Veeam’de değil, mimaridedir: tek sunucuya yığılmış roller, network moduna düşmüş proxy ya da görev sayısı kaldıramayacağı kadar yüksek bir depo. Küçük ortamda Veeam Backup & Replication’ı tek sunucuya kurup tüm rolleri orada bırakmak işler. Ortam yüzlerce sanal makineye, birden çok depolama sistemine ve ikinci bir siteye büyüdüğünde ise yedek penceresi, geri yükleme hızı ve dayanıklılık, bileşenlerin nereye ve hangi kapasiteyle yerleştirildiğine bağlanır. Aşağıda bileşenleri, transport modlarını, Hyper-V’ye özgü proxy seçeneklerini, boyutlandırmayı, Scale-Out Backup Repository yapısını ve darboğaz okumayı sırayla ele alıyoruz.

Veeam bileşenleri ve görevleri

Yapılandırma veritabanı Microsoft SQL Server veya PostgreSQL üzerinde çalışabilir. Backup server kaybedildiğinde yedekler kaybolmaz ama işler durur. Veeam’in yerleşik yapılandırma yedeğini (configuration backup) ana depodan farklı bir depoya şifreli olarak alın; şifreleme olmadan alınan yapılandırma yedeğinde kayıtlı kimlik bilgileri geri gelmez ve her bileşenin parolasını yeniden girmeniz gerekir. Backup server’ın üretim domain’ine üye olup olmayacağı ise ayrı bir güvenlik tasarımı kararıdır; burada ona girmiyoruz.

Transport modları karşılaştırması

VMware vSphere ortamında proxy’nin VM disklerini nasıl okuyacağını transport modu belirler. Otomatik seçimde Veeam önce doğrudan depolama erişimini, sonra virtual appliance modunu, en son network modunu dener. Sıralama doğru, sonuç her zaman değil.

Pratik kural: büyük bloklu depolama ve Fibre Channel/iSCSI ağına erişimi olan sunucu ve depolama altyapılarında fiziksel proxy ile Direct SAN; tamamen sanallaştırılmış ve küçük-orta ortamlarda her kümede hot-add proxy VM’leri; uzak şube ve tek host’lu ortamlarda network modu. Yavaş yedek şikâyetinde konsolda ilk baktığımız yer burasıdır: otomatik seçim sessizce network moduna düşmüş olabilir. Tipik nedenler, hot-add proxy’nin VM’in datastore’unu görmemesi veya Direct SAN için LUN’ların proxy’ye sunulmamasıdır. İş oturum kaydında kullanılan modu “[san]”, “[hotadd]” veya “[nbd]” etiketlerinden kontrol edin.

Hyper-V ortamında on-host ve off-host proxy

Hyper-V’de ayrı bir transport modu seçimi yoktur. Karar tek: veriyi kim okuyacak?

• On-host backup: Hyper-V host’unun kendisi kaynak proxy görevini üstlenir. Kurulumu basittir, ek donanım gerektirmez. Ama sıkıştırma ve tekilleştirme host’un CPU ve belleğini kullanır; yedek penceresinde üretim VM’leriyle aynı kaynağa talip olur.
• Off-host backup: Ayrı bir fiziksel Windows Server, Hyper-V rolü kurulu olarak proxy görevi görür. Depolama sisteminin donanım VSS sağlayıcısı, transportable shadow copy desteği sunmalıdır; snapshot proxy’ye bağlanır ve veri oradan okunur. SMB3 paylaşımlı depolamada da off-host senaryosu mümkündür. Proxy’nin işletim sistemi sürümünün Hyper-V host’larıyla uyumu için üreticinin güncel gereksinimlerini kontrol edin.

Üretim host’larında yedek penceresinde belirgin CPU baskısı varsa veya yedek işi gündüz mesaisine taşıyorsa off-host proxy’yi değerlendirin. Off-host kurulumda en sık takıldığımız nokta, depolama üreticisinin donanım VSS sağlayıcısının proxy’ye kurulmaması ya da sürümünün host’lardakiyle uyuşmamasıdır; bu durumda iş snapshot aşamasında düşer. Paylaşımlı depolama seçenekleri ve VSS sağlayıcı uyumu Hyper-V için paylaşımlı depolama seçimi yazısında ele alınıyor.

Proxy ve repository boyutlandırma

Veeam’de bir görev (task), bir VM diskinin işlenmesidir. Dört diskli bir VM, eşzamanlı görev sınırı izin veriyorsa dört görevle paralel işlenir. Hem proxy hem repository için “en fazla eşzamanlı görev” ayarı bulunur ve kaynaklar bu sayıya göre boyutlandırılır. Görev başına gereken çekirdek ve bellek değerleri sürümden sürüme değiştiği için kullandığınız sürümün sistem gereksinimleri belgesinden alın. Ezberden boyutlandırmayın.

Örnek hesap

Varsayımlar: 60 TB kullanılan kaynak veri, haftalık aktif tam yedek için hafta sonu 48 saatlik pencere, pilot testte ölçülen görev başına aktarım hızı 100 MB/s, görev başına 1 çekirdek ve 2 GB RAM (örnek değer; sürüm belgesiyle doğrulayın).

• Gereken toplam hız: 60.000.000 MB ÷ 172.800 sn ≈ 347 MB/s.
• Gereken en az eşzamanlı görev: 347 ÷ 100 ≈ 4 görev.
• Geri yükleme senaryosu, aynı anda birden çok sistemin dönmesi ve iş tekrarları için pay bırakıldığında tasarım hedefi 8–12 görev.
• Bu, işletim sistemi kaynakları hariç iki proxy’de 6’şar çekirdek ve 12’şer GB RAM’e karşılık gelir. İkinci proxy aynı zamanda yedekliliktir: tek proxy tek arıza noktasıdır.

Repository tarafında eşzamanlı görev sayısını diskin rastgele yazma kapasitesine göre sınırlayın. Proxy 12 görevle veri gönderirken depo 4 görevi kaldırabiliyorsa darboğaz yalnızca yer değiştirir. Sorun çözülmez, taşınır. Depo kapasitesinin kendisi ayrı bir hesap konusudur ve yedek depolama kapasite hesabı yazısında anlatılıyor. Yeni depolarda VM başına ayrı yedek dosyası (per-machine backup files) kullanın; paralel yazma hızlanır, tek VM’lik taşıma ve silme işlemleri kolaylaşır.

Scale-Out Backup Repository

Scale-Out Backup Repository (SOBR), birden çok depoyu tek mantıksal hedef olarak sunar ve katmanlara ayırır. Depo dolduğunda işleri tek tek yeni hedefe taşımak yerine uzantı eklersiniz.

• Performance tier: Blok depolama üzerindeki uzantılar (extent). Yerleşim politikası iki seçenek sunar: Data locality bir zincirin tüm dosyalarını aynı uzantıda tutar ve ReFS/XFS blok klonlama ile uyumludur; Performance tam ve artımlı dosyaları farklı uzantılara dağıtır, ancak bir uzantının kaybı zincirin tamamını etkiler.
• Capacity tier: S3 uyumlu veya Azure Blob gibi nesne depolama. Kopyalama modunda her yedek oluşur oluşmaz nesne depolamaya da yazılır; taşıma modunda belirlenen süreden eski, kapanmış zincir dosyaları taşınır ve yerel alan boşalır.
• Archive tier: Uzun süreli GFS noktaları için Amazon S3 Glacier veya Azure Archive gibi düşük maliyetli ama geri çağırma süresi uzun katmanlar.

Bir uzantı bakıma alınacaksa “maintenance mode” ile yeni yazmalar durdurulur, gerekirse “evacuate” ile içindeki yedekler diğer uzantılara taşınır. Fidye yazılımı önce yedek konsoluna ve depoya gider. Nesne depolama katmanında değiştirilemezlik (immutability) ayarını bu yüzden baştan açın; seçenekler değiştirilemez yedek seçenekleri yazısında karşılaştırılıyor.

Görev istatistiğinde darboğaz okuma

Veeam her iş oturumunun istatistiğinde veri yolundaki dört aşamanın ne kadar meşgul olduğunu gösterir. Tahmin yürütmeden önce bu satırı okuyun:

Load: Source 92% > Proxy 35% > Network 18% > Target 9%
Primary bottleneck: Source

Her veri yolunda bir darboğaz vardır. Bu normaldir. Asıl soru, darboğazın yedek penceresini veya geri yükleme süresini aşıp aşmadığıdır. Source oranı yüksek ama iş süresi hedef içindeyse dokunmayın. Artımlı yedeklerde düşük toplam hızla birlikte Source’un yüksek görünmesi ise ayrı bir alarmdır: CBT/RCT çalışmıyor ve tüm disk baştan okunuyor olabilir. Sahada bunu çoğunlukla VM taşıma veya host güncellemesi sonrasında görüyoruz.

Tasarım kontrol listesi

• Backup server veri yolunun dışında, ayrı ve korunan bir sunucuda mı? Yapılandırma yedeği farklı bir depoya şifreli alınıyor mu?
• Her kümede en az iki proxy var mı? Kullanılan transport modu iş kayıtlarından doğrulandı mı?
• Hyper-V’de on-host proxy’nin üretim host’larına etkisi ölçüldü mü?
• Proxy ve repository eşzamanlı görev sayıları birbiriyle uyumlu mu?
• Repository biçimlendirmesi blok klonlamayı destekliyor ve SOBR yerleşim politikası buna uygun mu?
• İkinci kopya farklı konuma, en az bir kopya değiştirilemez depoya gidiyor mu?
• Darboğaz istatistikleri haftalık olarak gözden geçiriliyor mu?

Küçük ortamlar için başlangıç noktası Veeam Community Edition ile ücretsiz yedekleme, ikinci siteye replikasyon tasarımı için Hyper-V Replica ve Veeam replikasyonu yazılarına bakabilirsiniz. Veeam mimarisini nasıl tasarlayıp kurduğumuzu yedekleme ve felaket kurtarma ile sanallaştırma ve veri yönetimi sayfalarımızda bulabilirsiniz. Bileşenlerin güncel gereksinimleri için Veeam Help Center, tasarım önerileri için Veeam Best Practices kaynaklarını kullanın.

Sık sorulan sorular

Veeam proxy ile repository aynı sunucuda olabilir mi?

Olabilir; küçük ve orta ortamlarda yaygındır ve ağ trafiğini azaltır. Kaynaklar paylaşıldığı için eşzamanlı görev sayılarını birlikte boyutlandırın. Büyük ortamlarda proxy’leri kaynak depolamaya, repository’yi depoya yakın ayrı sunuculara yerleştirmek ölçeklenmeyi kolaylaştırır.

VMware ortamında hangi transport modu seçilmeli?

Fiziksel proxy ve SAN erişimi varsa Direct SAN, tamamen sanal ortamlarda hot-add proxy VM’leri, uzak şube ve küçük ortamlarda network modu uygundur. Otomatik seçimde hangi modun kullanıldığını iş oturum kaydından doğrulayın.

Hyper-V’de off-host proxy ne zaman gerekir?

Yedek penceresinde üretim host’larında belirgin CPU ve bellek baskısı oluşuyorsa veya ortam büyüdükçe pencere yetmiyorsa off-host proxy değerlendirilir. Depolama sisteminin transportable shadow copy destekleyen bir donanım VSS sağlayıcısı sunması gerekir.

Darboğaz istatistiğinde Source yüksekse ne anlama gelir?

Verinin üretim depolamasından okunması en yavaş aşamadır. Transport modunu, depolama gecikmesini ve artımlı yedeklerde değişen blok takibinin çalışıp çalışmadığını kontrol edin. İş süresi hedef içindeyse müdahale gerekmez.