2

Exchange Server 2010 ile tanıştıgımız yüksek çalışabilirlik (HA) çözümü olarak sunulan DAG (Database Availability Goups) yapısı Exchange 2013 ile de devam ediyor. DAG çözümü Database yedeklememiz dısında sunucu yedekleme tarafında da bir çözüm olarak karsımıza çıktıgı için, çoğu yapıda tercih edilen bir süreklilik çözümüdür. Cluster yapıda planlanan sanallaştırma mimarilerinde dahi, çözüm olarak DAG yapılarını konumlandırıyoruz.

Exchange Server 2013 ile, Exchange mimarisi tamamen değişmiş olmasına rağmen, DAG yapısında herhangi bir değişiklik yok aslında. Performans ve kolaylık sağlayacak iyileştirmeler yapılmış sadece.

Microsft un önerisi; DAG yapısını minimum 3 Sunucu ile yapmaktır. Ancak destek; 2 ile 16 member sunucu arasında DAG yapısını oluşturabilmemiz yönündedir.

DAG üyesi herbir sunucu maksimum 50 Mailbox Database ine sahip olabilir. Bu MB DB leri içerisinde aktif ya da pasip DB içerebilir.

Basit Bir DAG yapısı aşağıdaki gibi olabilir.

Örnek de EXMB1 sunucusu aktif olarak hizmet veren sunucudur. Diğer EXMB2 ve EXMB3 isimli üye sunucular pasif modda, aktif DB nin kopyasını barındırmaktadır. EXMB1 herhangi bir şekilde durursa, diğer üyelerden biri devreye girecektir ve DB aktif konuma geçer. Bu şekilde mailbox lara baglanmak mumkun olur.


Resim-1


Resim-2

Yazımızın başında DB den ziyade sunucuyuda yedeklemiş oldugumuzu vurgulamıstım. Bu durum master bir sunucunuz oldugunu ve ona bagımlı kalacagınızı anlatmaz.

Her bir dag üyesinde aktif DB ler olabilir. Bu durum için aşağıdaki görseli incelememiz faydalı olacaktır.


Resim-3

Bu örnekte 3 adet DAG üyesi sunucu bulunuyor ve her sunucuda aktif database ler bulunuyor.

EXCHANGE SERVER 2013 İÇİN QUORUM YAPISI

Microsoft Exchange 2013 Server DAG yapısı, Windows Failover Clustering ve Quorum yapısını kullanır. Bu kümeleme yapısı, Exchange tarafından sizin için yönetilir. Yani Failover Cluster tarafında teferruatlı bir yapılandırma işine soyunmamıza gerek yok. Bu mimariyi; DAG üyelerinin görevlerini ya da aktif/pasif olan üyenin takibini yapmak için kullandığını düşünebiliriz.

Quorum; da üyelerini, hangisinin aktif olduğunu ve felaket anında hangisinin aktif olacağı gibi seviyeleri/kararları tutmak için vardır.

Bu yapı içinde iki tip Quorum metodu mevcuttur.

Tek sayılı DAG üyeleri mevcut olması durumunda Node Majority Quorum modeli kullanılır.

Bu metotta; sunuculardan biri durduğunda, çoğunluk sağlanır, diğer sunucular devam edebilir. Ancak iki sunucu hata alırsa, yeterlilik sağlanamaz.


Resim-4

Eğer üye sayısı çift ise  Node and File Share Majority Quorum metodu kullanılır.

Bu mod ek bir sunucu barındırır ve bu sunucu File Share Witness olarak adlandırılır. Bu metot da ki DAG üyeleri genelde aynı site da bulunur.

Bu metot da ki örnek ile 4 üye kullanılıyor. İki sunucu durduğunda yeterlilik korunur ancak 3 sunucu durursa yine yeterlilik sağlanamaz.


Resim-5

EXCHANGE 2013 DAG YAPISINDA, SUREKLI REPLIKASYON (CONTINUOUNS REPLICATION)

Herbir DAG üyesi, belirli bir Database in kopyasını tutar. Bu işlem sürekli replikasyon (CONTINUOUNS REPLICATION) olarak geçer.

Ve bu replikasyonun iki farklı metodu vardır:

  • File Mode Replication
  • Block Mode Replication

File Mode Replication

Her transaction log tam olarak yazılır. Her işlem logo 1MB dır. Ve sonra aktif Database ‘i barındıran DAG üyesinden, herbir pasiv Databaseleri barındıran DAG üyelerine kopyalanır. Diğer DAG üyeleri daha sonra tekrar transaction log kendi pasif database kopyası içeriğini günceller.

File Mode Replication ‘ın tek dez avantajı; aktif DAG üyesi durdugunda, işlem logları henuz diğerlerine yazılmamıs olabilir. Ve bu durumda işlem log u güvencellenmemiş olur ve veritabanı kullanılamaz hale gelir.

Bu senaryodaki kurtarma mekanizmasını kuvvetlendirmek ve riski minimuma indirmek için initial seeding işlemini inceleyebilir ve uygylayabiliriz.

Seeding işlemi bittikden sonra replikasyon otomatik olarak block mode a geçer.

Block Mode Replication

Bu metod da; aktif Database in işlem logu etkin sunucu uzerinde buffer edilir ve aynı zamanda pasif Database barındıran DAG uyelerine buffer edilmiş log dosyalarını gönderir. Ayrıca bu metoda; pasif DAG üyesi aktif oldugunda, kendi işlem logunu üretebilir. Block Mode Replication metodu ile muhtemel bir veri kaybı minimum seviyededir.

DAG – Network Yapısı

Exchange Server 2013 DAG yapısını oluştururken, Cluster mimarilerinde yaptığımız gibi replikasyon için gerekli trafiğe ait dedike bir network yaratmak performans ve yönetilebilirlik için en doğru olan, önerilen yapıdır.

Ancak biz konuya iki metot ile yapılabileceğini söyleyerek devam edelim.

İlk metot aklınızdan geçtiği gibi; sunucu üzerindeki fiziksel network üzerinde farklı IP grubu oluşturarak, trafiği sağlamaktır.


Resim-6

Diğeri ise, replikasyon ve istemci trafiğini izole bir şekilde oluşturmaktır. Bu şekilde istediğimiz network için gerekli ayarlamaları yapabilir, trafiği yönetebiliriz.

Ayrıca özel network interface ler ile devam etmek, yapıdaki performansı arttıracaktır.


Resim-7

Çoklu Site Konumlandırmaları ve HA

Exchange 2013 DAG yapısı farklı lokasyonlar arasında planlanabilir, projelendirilebilir.

Bu yapı genellikle var olan tek bir Active Directory Site yapısına ya da Veri Merkezi içerisinde geliştirilir.


Resim-8

Ancak esneklik diyorsak, fiziksel lokasyonları da yedeklememiz gerekir (SR – Site Resilience). Gerçek bir felaket anında, DAG yapısı farklı bir veri merkezinden devam edebilme yeteneğine de sahiptir.


Resim-9

Tabi ki birden fazla veri merkezi arasında replikasyon ve HA ortamını yaratabilmemiz için daha detaylı bir projelendirme gerekecektir. Ve yönetim de bununla doğru orantılı olarak hassaslaşır/önemlileşir. Genelde kaynaklar ve anlatımlar, aynı ortamda DAG yapısının oluşturulması üzerine senarize edilmiştir.

Genel olarak Exchange 2013 ‘un DAG yapısı her ne kadar değişmemiş olsa da, HA mimarisinin üzerinden geçmiş ve hatırlamış olduk. Yazının devamında kurulum aşamaları ile devam edeceğiz.

Bu konuyla ilgili sorularınızı  alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.

Referanslar

www.mshowto.org

Bu İçeriğe Tepkin Ne Oldu?
  • 1
    harika_
    Harika!!
  • 0
    be_enmedim
    Beğenmedim
  • 0
    _ok_iyi
    Çok iyi
  • 0
    sevdim_
    Sevdim!
  • 0
    bilemedim_
    Bilemedim!
  • 0
    olmad_
    Olmadı!
  • 0
    k_zd_m_
    Kızdım!

Güven Yıldız, 1987 İstanbul doğumluyum. Sektördeki çeşitli iş ortaklarında; Sistem Uzmanı, Proje Mühendisi unvanları ile saha deneyimi kazandım. şu anda Kurumsal Bir Şirketin Proje Yöneticisi olarak görev almaktayım. Satış öncesi ve satış sonrası proje yönetimini sağlayarak, teknoloji danışmanlığı yapmaktayım. Sektörün Lider Markalarında çeşitli sertifikasyonlara sahibim.

Yazarın Profili
İlginizi Çekebilir

Bültenimize Katılın

Tıklayın, üyemiz olun ve yeni güncellemelerden haberdar olan ilk kişi siz olun.

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Yorumlar (2)

  1. Ellinee sağlık çok güzel olmuş,

    Bir sorum olacak benim yapımda , 5 serverlı yapım var bunlardan

    2 tanesi cas ve hub
    3 tanesi dag üzerinde

    bunlar esx üzerinde , test için 2 cas, dag dahil 2 serverıda hyper v üzerine aktardım
    dag mimarıisnde bulunan mailbox database lerin bir kısmı mount oldu bir kısmında da mount
    aktif değil , sadece active mailbox database seçeneği aktif onu yaptığım da da hiç br şekilde
    aktif edemedim. Çalışmasına bakıyorrum cas,failower witness server probleme rastlayamadım. Gözden kaçırdığım bir şey var ama ne , eğer vaktiniz olurda sizden bir yorum rica ediceğim

    Saygılarımla

    • ESX’den Hyper-V üzerine aktarırken network kartları ile ilgili bir sorun yaşanmış olabilir. Bu yapı ESX ortamında bu işlemi sağlıklı olarak yapabiliyor mu?

      Emre Aydın

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir