Yakında piyasaya çıkacak Veeam Availability Suite v9, diğer birçok yeni ve heyecan verici özelliğinin yanında, büyük işletme ortamları için de daha fazla geliştirme getiriyor. Bu ortamlarda genelde düzgün çözümler gerektiren iki temel özellik öne çıkar: ölçeklenebilirlik ve birden fazla uzak ofis/şubenin yönetimi.

Düzgün yedekleme ve geri yükleme için, korunan sanal makinelerin konuk işletim sistemiyle etkileşim, yazılımımızın son derece gelişmiş bir özelliğidir. Tamamen aracısız bir çözüm olan yedekleme görevlerimiz, "uygulama farkındalı imaj işlemenin" etkin olduğu her sanal makine için geçici bir çalışma zamanı işlemi uygular. Bu işlem VSS işlem düzenlemeden sorumlu olup, hem günlük kesme gibi uygulamaya özel yedekleme adımlarını uygular, hem de konuk dosya sistemi dizini oluşturur.

v9'dan önce tüm konuk etkileşimlerini yedekleme sunucusu gerçekleştiriyordu. Merkezi konsol, her bir korunan sanal makine için, konuk etkileşim işlemini doğrudan sanal makinede kullanıma alıyordu (ya ağ aracılığıyla doğrudan konuk işletim sistemine, ya da bağlantısı kesilmiş ağlardaki konuklar için bir sunucu bağlantısı aracılığıyla VIX API kullanarak). Bu süreç bugüne kadar mükemmel şekilde işledi. Ancak korunan ortamların boyutları ve karmaşıklıkları arttıkça iki engel ortaya çıktı.

İlki ölçeklenebilirlik. Konuk işlemini yedekleme sunucusu yönetmektedir. Ancak tipik bir müşteri ortamındaki korunan sanal makine miktarının zamanla artmasıyla yedekleme sunucusu kaynakları darboğaz haline gelmeye başlamıştır. İşlerden önce, mümkün olan eş zamanlı konuk etkileşimlerinin miktarını kısıtlamak zaman aşımına neden olacaktır.

İkinci engel bir şekilde ilkiyle bağlantılıdır. Büyük işletme ortamlarının genelde birkaç uzak ofisi vardır; buralardaki sanal ortamlar, o şubelerin kullanıcılarına hizmet sunmak için bölgesel olarak kullanıma alınmıştır. Bu tür senaryolarda, VBR sunucusu normalde merkezlerde kullanıma alındığı için, tüm konuk etkileşimleri çoğunlukla yavaş olan WAN bağlantısı üzerinden gerçekleşmek zorundadır.

 

1

 

Bu nedenle, yedekleme ve kurtarma trafiğini yerel tutmak için şubelerde her ne kadar uzaktan proxy ve havuz kullanıma alınsa da, konuk etkileşim trafiğinin WAN'ı geçmesi gerekmektedir; bu da ilgili ortamlar için ölçeklenebilirlik sorunları yaratmaktadır.

v9, performansı artırmak için Konuk Etkileşim Proxy'si tanıtacaktır. Müşteriler bu sanal rolü herhangi bir yönetilen Windows sunucusuna atayabilir (mevcut yedekleme proxy'leri ve havuzları da dâhil olmak üzere). Şubedeki uzaktan yedekleme proxy'si, koruduğu sanal makinelere en yakın olması nedeniyle genelde ideal adaydır:

 

2

 

Konuk Etkileşim Proxy'si varken, yedekleme sunucusu yalnızca WAN linki ile kontrol komutları gönderecektir. Konuk etkileşim işlemini, işlem gören sanal makinelere "yerel" Konuk Etkileşim Proxy'si yükleyecektir. Sonuç olarak yavaş linkten geçen trafik en aza indirilirken, VBR sunucusunun yükü azaltılacaktır. Ayrıca tek bir yedekleme sunucusu birden çok Konuk Etkileşim Proxy'sini kontrol ediyor olacağından, ölçeklenebilirlik önemli ölçüde gelişecektir. Örneğin, 500 uzak site kullanan bir Büyük İşletme kullanıcısını düşünün. Bu işletme, her sitenin yedekleme proxy'sini ayrıca Konuk Etkileşim Proxy'si olarak hareket edecek şekilde belirleyebilir; bunların tümünü merkezi yedekleme sunucusu kontrol eder. Açıkçası, konuk etkileşim etkinliklerinin performans ve ölçeklerini iyileştirmek amacıyla, birden çok konuk etkileşim proxy'si de tek bir büyük veri merkezinde kullanılabilir.

Bu işlevselliğin hemen göze çarpmayan başka bir gizli avantajı da, VIX aracılığıyla ağsız işleme mümkün olmadığında konuk işletim sistemine erişim olanağı sunmasıdır (örneğin gerekli yüksek-öncelikli konuk etkileşimi hesabı, güvenlik hususları nedeniyle sağlanamadığında).  Artık, hem üretim hem de yedekleme ağlarında NIC'leri olan bir Windows bilgisayarı belirleyebilir ve bundan, yedekleme ağından üretim ağına iletişim "iletmek" için bir konuk etkileşim proxy'si olarak yararlanabilirsiniz.

Ancak yedeklemeler hikayenin yalnızca bir kısmıdır. Veri, havuzda güvenli bir şekilde depolanır depolanmaz, geri yükleme gerekebilir. Buna bir kez daha uzak ofis senaryosuyla bakarsak, günümüzde dosya seviyesinde geri yüklemeler, yedekleme dosyalarının doğrudan bağlı olduğu merkezi sunucular tarafından yürütülmek zorundadır:

 

3

 

Dolayısıyla, yedekleme havuzu, uzak sanal ortam için "yerel" olsa bile, dosya seviyesinde yerinde geri yüklemeler sırasında, verinin yavaş WAN bağlantısını iki kere geçmesi gerekir; ilk olarak yedekleme sunucusuna çekilirken, daha sonra da uzak sitedeki sanal makineye geri gönderilirken. Popüler bir geçici çözümde, uzak sitede başlatılan FLR yardımcı gereciyle Çoklu İşletim Sistemi Dosya Seviyesinde Geri Yükleme (FLR) sihirbazı kullanılır.

Tüm yedekleme havuzları için yeni Bağlama Sunucusu (Mount Server) ayarı sayesinde, v9 ile artık bunu yapmanız gerekmez. Temel olarak, Veeam'in yönettiği herhangi bir Windows sunucusu artık Veeam yedeklemeleri için bir FLR bağlama noktası olarak belirlenebilir. Tabii ki, uzak ofis için Windows tabanlı mevcut bir havuzun, kendisi için bağlama sunucusu haline gelmesinden daha iyi bir çözüm olamaz!

 

4

 

Bu yeni sanal rol sayesinde artık, merkezi VBR sunucusu WAN bağlantısından yalnızca kontrol komutları gönderirken, uzak yedekleme, gerekli dosyaları doğrudan uzak sanal makineye geri yüklemek için belirlenen "yerel" bağlama sunucusu tarafından bağlanacaktır; bu sırada tüm veri aktarımları uzak sitede kalacaktır.

Halihazırda "uzak" işlemlerden bahsediyorken, v9'a gelecek önemli eklemelerden bir başkasından da bahsetmeliyiz: tek başına konsol. Evet, Veeam yöneticilerinin yedekleme sunucusundan bağımsız olarak yükleme yapabilecekleri (örneğin, iş istasyonlarında, yedekleme sunucusunun ağ üzerinden uzaktan yönetilebilmesi), uzun süredir beklenen Veeam Backup & Replication konsolundan bahsediyoruz. RDP oturumlarına ve birden çok kullanıcının aynı yedekleme sunucusuna bağlanırken birbirlerini dışarı atmalarına veda edin. Artık her bir operatörün kendi konsolu olabilecek. Ayrıca konsol, yedeklemelerin yerel olarak bağlanması gereken (örneğin, Veeam Explorers için) gelişmiş kurtarma senaryoları için bağlama sunucusu rolünü de üstlenir; bu, ROBO senaryolarında çok faydalı olacak bir özelliktir.

Üstelik bugünlük hepsi bu kadar da değil! v8'de çoktan görebileceğiniz gibi her boyutta müşteri için piyasadaki en iyi teyp desteğini sağlamaya kendimizi adamış bulunuyoruz. v9 ise, büyük işletme istemcilerimizin almaya can attığı, birden çok ek teyp işlevselliği geliştirmesi getirecek. Yalnızca en önemli birkaç tanesinden bahsedeceğim ama daha küçük birçok geliştirme olduğundan emin olabilirsiniz!

İlk olarak, bana göre bunların en büyüğü, tek bir fiziksel kütüphaneden ayrı olan ve verileri birden çok kütüphaneye dağıtabilen bir Ortam Havuzu yaratma özelliğidir. Bu “genel ortam havuzu”, teyp işlerinde esas hedef haline gelecek ve hem performansı, hem de genel yönetim deneyimini geliştirecektir.

 

5

 

"Genel ortam havuzuna" yönelik bir teyp işi, yapılandırılmış kütüphane arıza yedeği sırasına göre birden çok kütüphaneyi veya tek başına sürücüleri kullanabilir ve herhangi bir arıza yedeği olayının gerçekleşmesi halinde, uygun olan kütüphanelerden birine geçiş yapabilir. Örneğin bir kütüphanenin bağımsız ortamının bittiğini veya tüm teyp sürücülerinin dolu olduğunu düşünün. Genel ortam havuzları sayesinde, teyp işi artık bağımsız ortamı olan veya teyp sürücülerinin uygun olduğu başka bir kütüphaneye geçiş yapabilecektir.

Teyp operasyonel performansa başka hangi harika özellikleri ekliyoruz? Çok talep edilen, birden çok teyp sürücüsü arasında paralel işleme, v9 ile geliyor! Daha önce gereken ve karmaşıklığı arttıran birden çok ortam havuzu kurma ve teyp yedekleme görevleri, artık hazır geliyor!

 

6

 

Bu, aynı ortam havuzuna doğrultulan teyp işlerini eş zamanlı olarak yürütmenizi veya kaynak yedekleme dosyalarının arşivlenmesini birden fazla sürücüye dağıtmanızı sağlayan basit ama güçlü bir seçenektir.

Şimdi de teyp ortamı rotasyonundan bahsedelim. Eminim birçoğunuz v9'da yeni bir tür ortam havuzunun olacağını duymaktan mutlu olacaksınız: tam yedeklemeler için özel DBO Ortam Havuzu v8'de birden çok ortam havuzuyla büyük ölçüde aynı sonucu elde etmek mümkünken, v9, ilgili yönetim karmaşıklığını tamamen ortadan kaldırarak bunu bir adım ileriye taşımıştır.

v8'den mevcut yedek kopyalama işimizin Dede-Baba-Oğul (DBO) rotasyon mekanizmasına aşinaysanız, konsept burada da aynı kaldığı için anlamanız oldukça kolay olacaktır. Tam yedeklemeler, teybe yedekleme işleri düzenindeki DBO Ortam Havuzu'na yöneldiğinde, ilgili teypler belirlenen bekletme planına göre haftalar, aylar ve hatta yıllarca, veri bekletme ilkenizin gerektirdiği kadar saklanacaktır.

DBO ortam havuzuyla, uzun bekletmeler elde etmek için daha az teyp gereklidir. Örneğin, 4 yıllık tam yedekleme koruması için yapılandırılmış DBO rotasyon planı için yalnızca 19 teyp gerekecektir: 4 adet haftalık, 12 adet aylık ve 3 adet yıllık teyp. Kısa dönem tam yedekleme bekletme ve artımlı yedekleme için basit ortam havuzu da hâlâ mevcut olduğundan, hangi ortam havuzunun istediğiniz veri bekletme senaryosuna uyduğuna karar verebileceksiniz.

Sadece bu blog gönderisinden de görebileceğiniz gibi, v9'da, büyük işletmelere özel birçok önemli işlev geliştirmesi vardır. Bana güvenin, duyurularımıza daha yeni başladık; v9'un en etkileyici büyük işletme işlevi henüz açıklanmadı. Umarım çabalarımız, büyük işletme müşterilerimizin benzersiz ihtiyaçlarına büyük önem verdiğimizi ve size, büyük işletme çapında kullanıma %100 hazır olan ve büyüyen işletmeniz için kesintisiz çalışırlığı sürdürmeniz açısından kolayca ölçeklenebilir bir ürün sunmaya kararlı olduğumuzu açıkça gösterebilmiştir.

GD Star Rating
loading...
v9'da Büyük İşletmelerle İlgili Geliştirmeler - ROBO ve Teyp, 5.0 out of 5 based on 1 rating
Veeam Availability Suite — Deneme sürümü indirin

Luca Dell'Oca
Author: Luca Dell'Oca

Posted: August 6, 2015