• Tweet
• Email
• Sumo

• Tweet
• Email

Exchange DAG Yapısı

Merhaba günümüzde exchange server’ın yeri ve önemi çok büyük çünkü haberleşme insanlık için en önemli gereksinimdir. Teknoloji ile birlikte çeşitli iletişim araçları kullanılmakta  gün geçtikçe de yenileri eklenmektedir. Mektup telgraf fax derken zaman geçtikçe ihtiyaçlar farklı boyut kazanmış bunlara göre de yeni teknolojik gelişmeler yapılarak haberleşmeyi kolaylıştırma da büyük bir yol kat edilmiştir. Mektup haberleşme de en önemli ilk adım olsa da insanlığa bu yeterli olmamıştır. Mektup ile haberleşme zaman açısından büyük bir sorun olmaktaydı. Bu duruma bilim ve teknolojinin ilerlemesiyle Fax ile çözüm bulundu. Fax Mektuba göre çok hızlı bir iletişim aracı olmasına rağmen bu sefer de bu hızlı bilgi akışının içinde bu bilgileri saklama arşivleme gerekliliği önemli ve büyük bir sorun haline geldi. Çünkü zaman içerisinde alınan fax ların kağıtları  gerek saklama koşullarından dolayı gerek başka sebeplerden kağıt üzerindeki bilgiler zamanla soluklaşabiliyor veya taşınma gibi özel durumlarda kaybedilebiliyor bulunamıyor. Bu tip durumları en aza indirgemek digital ortamda daha kolay bir hal oluyor. Aslında en güzel tarafı bu saydıklarımızla beraber dataya bilgiye hemen ulaşabiliyor olmak, herhangi bir fax’ın hangi klasörde nerde olduğunu bulmak hem zahmetli hemde emek gerektiren bir iş hele de arşive gönderilmişse tamamen işin içinden çıkılmaz bir hal alıyor.İşşte bizde tam burada insanların bu ihtiyaçlarını karşılamak için geliştirilen mail sistemi ve bu sistemin yapı taşı olan Exchange server’ın bir kaç özelliğinden bahsedeğiz.

Exchange server da tüm kullanıcılara ait E- posta kutuları veri tabanlarında ‘mailbox databases’ saklanır. Bu dosyalar ‘edb’ uzantılıdır, ve bu dosyalar kurulum aşamasında belirttiğimiz klasörde tutulur. Burada kısa bir bilgi vermeliyim, genel olarak Exchange kurulum esnasında default olarak system diskinin olduğu klasörü kurulum için önerir. Ancak biz databasemizi bir storage’e yönlendirirsek mail trafiğinin yoğun olduğu yerlerde ileri ki zamanlarda başımızın ağrımaması için önlem almış oluruz. Çünkü bu database şiştikçe sistemi yavaşlatacak haliyle ilerleyen zamanlarda mail trafiğinizle beraber sunucu üzerinde kullanılan diğer hizmetlerde sorun yaşamaya başlıyabilirisiniz. Yeterli kaynak bulamadıkça sunucu üzerinde çalışan servisler hata verecektir bu istenmeyen bir durumdur. Bu nedenle databasemizi sistem diskinden ayrı mümkünse bir storage’ e yönlendirmemiz daha doğru olacaktır. Bunun yanı sıra log ve database dosyalarının farklı partitionlarda olmasınında performans tarafında verimli olduğu gözlemlenmiştir. Gelelim DAG yapısına ve çalışma mantığına önce DAG yapısının olmadığı bir sistemi ele alalım ve inceleyelim.

Yukarıda ki şekilde de görüldüğü gibi her exchange sunucusunun üzerinde çalışan bir database’i vardır. Bu sistem de yani DAG olmayan yapıda her sunucu kendi üzerindeki database ‘den sorumludur. Yani her kullanıcı bağlı olduğu database üzerinden maillerini alır işler. Ancak bu sistemin en kötü yanı kullanıcının bağlı olduğu sunucunun off olması çalışmaması herhangi bir sebepten dolayı arızalanmasıdır.  Bu durumda hangi sunucuda sorun olursa o sunucu da bulunan database ‘i kullanan kullanıcı maillerine erişemeyecektir. Bu durum büyük yapılarda maddi kayba neden olabilir. Bununla birlikte maillerine erişemeyen kullanıcıların tarafımıza nasıl bir baskı kuracaklarını da tahmin edebilirsiniz. İşte tam da burada DAG sistemcilerin yardımına koşuyor. Öncelikle DAG yapısını inceleyelim.

Yukarıdaki topolojide görüldüğü gibi 3 adet Exchange sunucumuz ve her sunucu üzerinde birer adet databaselerimiz mevcut, Fakat görüldüğü üzere DAG olmayan yapıdan biraz farklı bir topoloji ile resmedilmiş.  Her database ‘în diğer sunucu içerisinde ‘Passive’ bir kopyası bulunuyor. Her sunucu kendi üzerindeki aktif kopyası ile çalışıyor, ve her sunucu aynı anda ‘passive’ kopyasını diğer sunucuya replication yapıyor.  Aslında sistem her saniye kendini diğer sunucuya yedekliyor diye de düşünebilirsiniz. Herhangi bir felaket anında hangi sunucuya erişilemez ise diğer sunucu üzerinde bulunan’ Passive’ kopya üzerinden sistem çalışmaya devam ediyor. Tabi kopaynın hangi sunucu da aktif olacağına DAG yapısın yapılandırırken kurulum aşamasında yaptığımız ayarlar ile karar verebiliyoruz.  Sistemin çalışma mantığını kısaca özetlemek gerekirse çalışan sunuculardan birine erişilemez ise o sunucu üzerinde bulunan database’i başka bir sunucu üzerindeki yedeğini çalıştırıyor diyebiliriz. Bunu kullanıcılar kısa süreli bir kesinti olarak hissedeceklerdir. Kısaca DAG özelliklerinden bahsederek maddeliyecek olursak ;

DAG ‘ın temel özellikleri ;

• DAG ( Database Availability Groups ) larda bir veritabanının en fazla 16 kopyası
• DAG içindeki kopyalar birbirleriyle sürekli sekronize çalışıp eşlenerek arka planda(Replication) yapar. Ancak Group dışındaki mailboxlar eşlenmez, Replication yapamaz.
• Exchange serverlarda versiyon farkı önemli bir rol oynamaktadır. Hangi versiyonda kullanılıyorsa veritabanı  Örneğin. Exchange server 2010 da bulunan bir veritabanını yine Exchange server 2010 ile DAG yapabilirsiniz.
• Bir posta sunucusu üzerinde birden fazla aktif veya pasif veritabanı bulunabilir. Ancak aynı veritabanın iki kopyasını aynı sunucu üzerinde bulunduramazsınız.
• Bir DAG içerisinde bulunan posta sunucuları aynı Active Directory etki alanında bulunmalıdır. Önerilen bu şekilde olmasıyla birlikte farklı bir Active Directory etki alanında veya alt ağlarında (subnet Mask) bulunmalarında da bir sakınca bulunmuyor.

WİTNESS SERVER ( TANIK SUNUCU)

DAG üyeleri ile sürekli iletişim halinde bulunur,  Ancak DAG yapısına dahil değildir. Adından da anlaşılacağı üzere tanık sunucudur. Ortamda ki sunucular arasında bir iletişim kopukluğu olduğunda kesinti durumunda sunucular arasında veri tabanının hangi sunucuda aktif edileceğine dair bir oylama yapılır. DAG yapısı çift sunucudan oluşuyor ise oylama beraberlikle bitebilir. İşte tam bu aşamada oluşacak beraberlik durumunda oylamaya katılara eşitliği bozar. Witness server DAG üye sunucuları ile aynı sürümü kullanmak zorunda değildir. Örnek vermek gerekirse Windows Server 2012 kullanıyorsa üyeler Witness Serverınızı Windows Server 2008 yapabilirisiniz. Witness server üzerinde hangi sunucuların DAG üyesi olduğu, üyelerin aktif olup olmadığı cluster kaynak  bilgilerinin tutulduğu  ‘quorum resource’ ve ‘Quorum.log’ dosyaları  tutulur

ACTİVE MANAGER

DAG ı kurduktan sonra yönetimini sağladığımız bir bileşendir. Sunucuları yöneten veri tabanlarının  devrede olup olmadığını sürekli kontrol eden, kesinti anında hangi veri tabanının aktif edileceğine karar veren bir mekanizmadır. Aslında  Exchange Replication servisinin bir parçasıdır. Tüm posta sunucularında bulunur. Ancak aldığı göreve göre iki çeşidi vardır.

Primary Active Manager (PAM) : DAG’ın yönetiminden sorumludur kesinti durumunda hangi sunucuda hangi kopyanın devreye gireceğine karar veren roldür.

Stanby Active Manager (SAM) : Veri tabanının sağlıklı çalışıp çalışmadığını Active manager ile paylaşan rolümüzdür. PAM rolü olmayan sunucularda SAM bulunur.  SAM bulunan sunucuda veri tabanının kopyasında bir sorun olursa ne yapılması gerektiğine SAM karar vermez. Bu durumu Active Manager a bildirir ne yapılması gerektiğine PAM karar verir.

İlk makalem olduğundan gözden kaçırdığım yerleri ve hataları yorumlarınızda iletirseniz sevinirim. Kendimi geliştirmem ve hatalarımı düzeltmemde yapılacak eleştirilerin önemi büyük dolayısıyla yorumlarınızı esirgemeyin. Bu ilk makalem ile birlikte bende büyük emeği bulunan değerli kişilik Sevgili Hocam Bülent GÜR ‘e öğrettiği bilgiler ve kendisi gibi bir üstadın öğrenci olma şerefini ve gururunu bize yaşattığı için çok teşekkür ederim. Tabi sınıfımızda bulunan ve tecrübeleriyle bana yardımcı olan değerli arkadaşlarım, Hasan KABA, Şenol ÖZKAYA , Fırat BOYAN ve Ozan Erdem KOÇAK ‘a her daim yanımda olup bilgi birikimlerini hiç çekinmeden paylaştıkları için kendilerine teşekkür ederim.

Saygılarımla….