1.     Giriş

Günümüzde birçok firma için Microsoft Exchange Server sadece e-posta alışverişi için kullanılan bir yazılım değil, çalışanların iş hayatlarını koordine eden ve lokasyon bağımsız sürekli olarak çalışanları işi ile bağlayan çok önemli bir bilişim servisi haline gelmiştir. Kullanıcı sayınız ve müşterileriniz arttıkça, gelişen BT altyapınız ve süreçleriniz ile beraber Exchange Server’ın sağladığı servisler her geçen gün daha kritik öneme sahip olmaktadır.

Firmaların daha büyük BT altyapılarına sahip olması ile birlikte bellek, disk, işlemci takviyesi ile dikey büyüyen sunucu mimarileri yerine kullanıcı profiline ve BT yapılanmasına uygun biçimde, farklı bileşenleri ölçekleyebildiğiniz sunucu mimarilerine ihtiyaç her geçen gün artmaktadır.

Exchange Server 2007’de farklı WAN yapısına, mobil kullanıcı sayısına, mesajlaşma politikalarının sayısına, kullanıcı profillerine, güvenlik ve teknoloji ihtiyaçlarına gore farklı sunucu rollerini ölçekleyerek yükü doğru bileşen üzerinde karşılamak mümkün.

Bu ihtiyaçları karşılayabilmek için Exchange Server 2007, 5 farklı sunucu rolü ile kurulmakta. Her sunucu rolünün yüksek erişilebilirlik opsiyonları da birbirinden farklı olarak ayarlanıyor. Aynı zamanda yedek alma stratejinizi oluştururken de her rol için ayrı ayrı düşünmek ve planlamak zorundasınız.

Exchange 2007 konfigurasyon bilgisi ise Active Directory’de saklanmakta. Dolayısıyla doğru bir Exchange Server yedekleme stratejisinde her zaman Active Directory yedeğinin de alınması şarttır.

2.     Mailbox Server Rolü

Mailbox Server rolüne sahip Exchange Server 2007 sunucuları, ilgili kullanıcıların e-posta kutularındaki tüm verileri (e-postalar, takvim, görevler v.b.) saklayan sunuculardır. Public Folder verileri de yine Mailbox Server rolüne sahip sunucular üzerinde saklanmaktadır. Her Exchange 2007 organizasyonunda en az 1 adet bulunması zorunludur.

Bu role sahip sunucular, tipik veri depolama sunucuları ile hemen hemen aynı donanım kaynağı ihtiyacına sahiptir : yüksek oranda disk I/O. Bu sebepten dolayı yüksek disk I/O ihtiyacına sahip Mailbox Server rollerini tasarlarken başlangıç maliyeti olarak RAM maliyetinden kaçınmamanız çok önemlidir. Daha fazla RAM demek, disk üzerinde bulunan Exchange veritabanındaki page’lerin daha fazla miktarının RAM’de cahce’lenmesi, dolayısıyla daha az disk I/O demektir. Eğer RAM yatırımından kaçınırsanız, disk I/O yüzünden daha fazla maliyetlere girmeniz büyük olasılıktır. Daha fazla RAM’i daha performanslı kullanabilmeniz amacı ile Exchange Server 2007 (deneme sürümleri hariç) sadece 64bit ortama kurulabiliyor.

Tüm kullanıcı verilerinin depolanması ve yönetilmesinden sorumlu sunucu rolü olması sebebiyle, Exchange Server 2007 mimarisinde yüksek erişilebilirliği en iyi tasarlanması gereken rol Mailbox Server rolüdür.

Exchange Server 2007 ile birlikte Mailbox Server rolüne özel 2 yeni yüksek erişilebilirlik özelliği gelmekte : “Local Continuous Replication” ve “Cluster Continuous Replication”.

2.1.       Replikasyon

Exchange 2007 ile beraber gelen yeni bir özellik olan Exchange 2007 mailbox veritabanı replikasyon özelliği,veritabanında veya veritabanı sunucusunda herhangi bir problem olması durumunda pasif replike sunucusunun sorunlu olan sunucunun yerini alması prensibine dayanır.

Local Continuous Replication ve Cluster Continuous Replication olmak üzere 2 tipi vardır.

Her iki replikasyon tipi de benzer mimaride çalışmaktadır, “Exchange Server’ın transaction log’larının bir yerden diğer yere kopyalanıp logdaki değişikliklerin veritabanına okutulması”. (SQL Server’daki log shipping’e benzer mimari).

Replikasyonun temeli Exchange’in logları olması ve Exchange log’larının da Exchange veritabanı değil “Storage Group” ile ilgili olması sebebiyle replikasyon mimarisi aslında “Storage Group’taki verilerin replikasyonu” demektir.

Exchange Server 2007, 1MB’lık log  dosyaları ile çalışır, log dosyası 1MB’a ulaştığında yeni bir log dosyası oluşturur ve yeni dosyadan devam eder. Exchange Server yeni log dosyası açtığında eski dosya diğer replika’ya kopyalanır ve replika veri tabanının üzerine yazılır. Bundan dolayı Exchange Server 2007 replikasyon mimarisi asenkron çalışır.

Local Continuous Replication

Local Continuous Replication (LCR) Exchange veritabanının aynı sunucu üzerindeki farklı bir diske replike edilmesi esasına dayanır. Ekstra bir disk dışında herhangi bir donanıma ihtiyaç duyulmadan gerçekleştirilen bu replikasyon tipi fiziksel sunucuyu değil, veritabanını korumak için geliştirilmiştir.

Çalışan veritabanınızda herhangi bir problem olması durumunda diğer veritabanını devreye alıp işinize kalan yerden sıfır ya da minimum kayıp ile devam edebilirsiniz.

LCR’da, birincil veritabanında problem olduğunda otomatik olarak ikincil veritabanı devreye girmez, fakat çok kısa sure içinde hem Management Console’dan hem Management Shell’den pasif node’u devreye alabilirsiniz.

Şekil1. Local Continuous Replication

Veritabanı seviyesinde yüksek erişilebilirlik çözümüdür, ancak her iki diskteki her iki replikanın’da bozulması durumunda yedekten dönmeye ihtiyaç olacaktır.

Exchange Server’ın yedeği alınırken VSS (Volume Shadow Copy) kullanılarak pasif replika kullanılarak yedek alınabilir, yedek alma yükü kullanıcıların eriştiği aktif veritabanından pasif veritabanına kaydırılabilir.

Cluster Continuous Replication

Cluster Continuous Replication (CCR) Microsoft Exchange Server 2007’nin asenkron log shipping teknolojisi ile Windows Cluster Service’in sunduğu yönetim ve yüksek erişilebilirlik özelliklerini birleştiren, Exchange Serve 2007 ile beraber gelen yüksek erişilebilirlik özelliğidir.

CCR, özel bir donanım veya paylaşılan veri depolama ihtiyacı olmadan uygulanabilmektedir. Microsoft Windows Cluster servisinin yeni bir cluster quarum modeli olan “Mojority Node Set (MNS) quorum with file share witness” ile Exchange Server 2007’nin log shipping teknolojisinin birleşmesi sonucunda oluşan mimarinin temel prensibi, aktif node’daki logların pasif node’a kopyalanarak logların pasif node’da okutulması ve pasif node ile aktif node’un eşitlenmesi esasına dayanır.

Şekil2. Cluster Continuous Replication

İç cluster iletişimini sağlayan ağlarda bir problem olduğunda ve node’lar birbirlerinden “heartbeat” sinyali alamadıklarında problemin ağda mı olduğuna yoksa aktif node’da mı olduğuna karar veremezler, bu duruma “split brain syndrome” adı verilir. İç cluster erişimini sağlayan ağlarda yaşanacak bir problem esnasında cluster node’larının birbirinden haberdar olması için gerekli bilgileri iç cluster iletişiminden farklı bir ağ üzerinden bağlı oldukları ve cluster yapısına dahil olmayan farklı bir sunucuda oluşturulacak “Witness File Share” adı verilen bir paylaşımda tutulan bilgiler kullanılmaktadır. “Witness File Share” için genelde Exchange Hub Transport sunucusu önerilmektedir.

İki node’lu bir CCR mimarisinde birinci (aktif) node (Node1)’un aktif olduğunu ve Witness File Share’ın sahibi olduğunu fakat Node1 ile pasif node arasında ağ iletişim problem olduğunu düşünelim. İkinci (pasif) node (Node2) Node1 ile iletişim kuramadığında, Witness File Share’i sahiplenmeye çalışır ama başarılı olamaz. Bu durumda Node1’in hizmet vermeye devam ettiğini, sadece kendisi ile Node1 arasındaki ağda problem olduğunu anlar ve kendisini aktif hale getirmeye çalışmaz.

CCR’ın log shipping mekanizması da LCR gibi asenkron çalışır. Aktif node’daki 1MB’lık log dosyası dolduğunda ve yeni log dosyası oluşturulur ve eski log pasif node’a kopyalanıp okutulur. Bununla beraber akla şu soru gelir “Eğer 1MB’lık dosya  tamamlanmadan aktif node’da bir problem ortaya çıkarsa pasif node’a kopyalanmayan log dosyasındaki veriler ne olur?”

Asenkron modelde veri kaybını minimize etmek için Exchange Server 2007 Hub Transport sunucusu üzerinde “Transport Dumpster” özelliği kullanılmaktadır. Transport Dumpster özelliği sadece CCR için aktif hale gelir ve CCR için gerekli bileşenlerdendir. CCR’in aktif hale getirilmesi ile birlikte mimarideki tüm Hub Transport sunucularında Transport Dumpster denilen kuyruklama mekanizması oluşturulur, Exchange mimarisinde kullanılan tüm e-posta’lar belirli bir boyut ve zamana kadar Transport Dumpster kuyruğunda saklanır. Herhangi bir problem halinde CCR tüm hub transport sunucularından transport dumpster kuyruğundaki e-postaları tekrar göndermelerini ister ve Information Store eksik mailleri e-posta kutusuna bu kuyruktan gönderir. Böylelikle gönderilemeyen son log dosyasındaki e-postalar büyük ölçüde kurtulabilir.

3.      Hub Transport Rolü

Hub Transport Rolüne sahip Exchange Server 2007 sunucuları, Exchange Server 2003’teki bridgehead sunucularına benzer bir rol üstlenirler. Exchange mimarisinde e-posta kutuları aynı mailbox sunucuda olan iki kullanıcı olsun, farklı sunucular arasında, farklı lokasyonlar arası ve Exchange organizasyonu ile Internet arasında olsun, tüm iletişim Hub  Transport rolü üzerinden geçmektedir. Hub Transport  rolü iletişimin belirli kurallara uyup uymadığını kontrol etmekte ve iletişimi yönetmektedir. Hub Transport rolü aynı zamanda, Edge Transport’un bulunmadığı mimarilerde anti-spam agent’larını ve send connector’leri bulundurarak internet ile iletişimi sağlayan sunucudur. Her Exchange 2007 organizasyonunda en az 1 adet bulunması zorunludur.

Exchange Server 2007 Hub Transport rolünün erişilebilirliğini arttırmak için aynı Active Directory Site’ına birden fazla Hub Transport sunucusu kurmanız yeterlidir, e-posta trafik yükü otomatik olarak Hub Transport sunucuları arasında dağıtılacaktır.

Hub Transport rolünün konfigurasyonu ise Active Directory’de saklanmaktadır. Dolayısıyla bir Hub Transport sunucusunu kaybettiğinizde, aynı isimle ve Active Directory’de aynı (eski) bilgisayar hesabı ile ilişkilendirilmiş yeni bir sunucu kurup Exchange Server’ı Setup /mode:RecoverServer komutu ile çalıştırdığınızda eski sunucunun aynı konfigurasyonu ile kurulacaktır. Unutulmaması gereken çok önemli nokta ise, eski sunucunun Active Directory’deki bilgisayar hesabının kesinlikle silinmemesi gerektiğidir, çünkü Active Directory konfigurasyon verilerini bilgisayar hesabına ilişkili olarak saklar.

Konfigurasyon verileri dışında Hub Transport sunucunuzda transport kuyruğunun veritabanını ve message tracking & protokol (SMTP, POP3 v.b.) loglarını yedek almanız gerekmekte.

Transport kuyruk veritabanı Hub Transport’a ulaşan ve hedefe ulaştırılmayı bekleyen veya anti-spam kontrolü gibi işlemleri bekleyen e-postaların kuyruklandığı veritabanıdır. Bu veritabanı mailbox rolünden tamamen farklı olduğu için normal Exchange yedekleri sırasında yedek alınmaz.

Message Tracking ve protokol logları ise geçmiş e-posta trafiğinizin kayıtlarıdır, opsiyonel olarak dosya sistemi düzeyinde yedek alabilirsiniz. Bu kayıtlar text editörleri ile de okunabilirler.

4.     Client Access Server Rolü

Client Access Server (CAS) rolüne sahip Exchange Server 2007 sunucuları (MAPI harici) istemcilerin Exchange organizasyonuna bağlantı noktasıdır. OWA, ActiveSync gibi internete sunulan servisler de bu sunucu üzerinden sunulur. Her Exchange 2007 organizasyonunda en az 1 adet bulunması zorunludur.

CAS rolünün erişilebilirliğini arttırmak için birden fazla CAS sunucusu kurup donanım veya yazılım tabanlı bir NLB (Network Load Balancing) çözümü kullanmanız gerekmektedir.

CAS sunucusunun da konfigurasyonu Active Directory’de saklanmaktadır ve Active Directory’nin yedek alınması sırasında yedek alınabilinmektedir. Bununla beraber aşağıdaki veriler opsiyonel olarak yedek alınmalıdır :

5.     Edge Transport Server Rolü

Edge Transport Server Exchange Server 2007’nin opsiyonel kurulan rollerindendir. Exchange organizasyonunuzun Internet ile bağlantı noktası olan bu sunucu Internete giden ve Internet’ten gelen e-postalarınızın kurum politikalarına uygunluğu, virüs, spyware gibi zararlı yazılımlara karşı kontrol edilmesi gibi görevleri yerine getirir. Internete direk açık bir sunucu olması sebebiyle, güvenlik kriterleri gereği kurumunuzdaki Active Directory domain’ine dahil olamaz, dolayısıyla konfigurasyon bilgisi Active Directory’de saklanmaz. Active Directory’deki objelerin özelliklerini sorgulaması gerektiğinde ise, üzerine kurulan ADAM (Active Directory Application Mode)’dan faydalanır.

Edge Transport sunucularınızın erişilebilirliğini arttırmak için ortama birden fazla Edge Transport sunucusu kurup, DNS’de MX kayıtlarına her iki sunucuyu da kayıt ederek gerçekleştirebilirsiniz. Sonuç olarak, dışarıdan mail domain’inizin MX kayıtlarını sorgulayan kullanıcılar kayıt ettiğiniz tüm Edge Server rolündeki sunuculara erişebileceklerdir.

Edge Server’ın konfigurasyonunu Exchange Server Management Shell’den çalıştıracağınız ExportEdgeConfig script’i sayesinde export ve import edebilirsiniz.

Edge Server’ın Message Transport kuyruğunu, message tracking loglarını ve protokol loglarını Hub Transport Rolündeki gibi yedek alabilirsiniz.

6.     Unified Messaging Server Rolü

Unified Messaging Server rolü, kullanıcıların Exchange Server’daki bilgilerine telefon servislerini kullanarak erişebilmelerini sağlamaktadır. Unified Messaging rolü Exchange Server’ınızı var olan telefon ağınızla entegre ederek sesli mesajlaşma, fax gibi özellikleri Inbox’unuzla birleştirir, telefon veya bilgisayar ile bu özelliklere erişmenizi sağlar.

Diğer Exchange sunucuları gibi Unified Messaing Server rolünün konfigurasyonun çoğunluğu Active Directory’de saklanmaktadır. 

Unified Messaging Server, ses mesajlarını ve diğer mesajları Hub Transport’a göndermeden once kuyruklar. Bu mesajlar “C:\Program Files\Microsoft\Microsoft Exchange \UnifiedMessaging \temp” klasöründe saklanmaktadır. Eğer Unified Messaging Server’ınızda, kuyrukta bekleyen mesajlar varken sorun yaşarsanız bu klasördeki mesajları Hub Transport rolüne sahip sunucunun Exchange Server\TransportRoles\Pickup klasörüne kopyalayarak hedeflerine ulaşmasını sağlayabilirsiniz.

Unified Messaging Server rolüne sahip sunucuların sakladığı bir diğer önemli bilgi ise otomatik cevap için özelleştirilmiş ses dosyalarıdır. Varsayılan ayarlarda bu dosyalar “C:\Program Files\Microsoft \Microsoft Exchange \UnifiedMessaging \Prompts \Custom” klasöründe saklanmaktadır. Özelleştirilmiş ses dosyalarınızın yedeğini almanız için bu klasörün dosya seviyesi yedeğini almanız gerekmektedir. Bununla beraber, eğer birden fazla Unified Messaging Server rolüne sahip sunucunuz varsa, özelleştirilmiş ses dosyaları File Replication Service (FRS – Dosya Replikasyon Servisi) tarafından tüm Unified Messaging Server sunucularına replike edilecektir.

Sonuç

Exchange 2007’nin 5 farklı sunucu rolünün beraberinde getirdiği güvenlik, ölçeklenebilirlik gibi avantajların yanında her rolün ayrı ayrı yüksek erişilebilirlik, felaketten kurtarma, yedek alma ve geri yükleme senaryolarını çok iyi planlamanız gerekmekte. CCR ile beraber Exchange 2007 kullanıcı verilerini coğrafi olarak farklı lokasyonlara taşıyabilir ve disaster recovery site’lar oluşturabilirsiniz.