Exchange 2019 Preferred Architecture PA – Tercih Edilen Mimari
Exchange Server 2019 çıkışı ile beraber ignite öncesi, ignite ve sonrasındaki tecrübelerimi sizler ile paylaşmaya devam ediyorum. Pek çok konuda olduğu gibi bu konuda da makale, Webcast ve benzeri paylaşımlarımı ÇözümPark Bilişim Portalı veya kendi kişisel blog sayfam üzerinden takip edebilirsiniz.
Bu yeni makalemde ise Exchange Server 2019 projelerimde de kullandığım ve Microsoft tarafından önerilen mimari hakkında bilgi vereceğim.
PA olarak kısaltacağımız tercih edilen, tavsiye edilen mimari Microsoft mühendisleri tarafından bizim gibi kurulum yapacak sistem mühendislerine nelere dikkat etmemiz gerektiğini ve başarılı yaygınlaştırma, kurma işlemleri için dikkat edeceğimiz balıkları paylaştıkları bir dokümandır.
Burada herşeyi Türkçe ye çevirmeyeceğim bunun temel sebebi ise örneğin “autodiscover” veya “MAPI over http” gibi aslında bu konunun özünde olan ve temel olarak üretici, danışman, müşteri üçlüsü arasındaki ortak dili koruyan terimleri olduğu gibi işleyeceğim.
Peki bu doküman hangi başlıklarda önerilerde bulunuyor?
· Namespace design
· Site resilient datacenter pair design
· Server design
· Database availability group design
Eğer Exchange Server 2016 ile çok yakından ilgileniyorsanız burada size güzel bir haber verebilirim. Mevcut 4 başlığın 3 için neredeyse tavsiye edilen yapılandırma aynı. Zaten temel olarak mimari aynı olduğu için çok ciddi değişiklikler yok.
Exchange Server 2019 da neler yeni yi merak ediyorsanız aşağıdaki makalemi inceleyebilirsiniz;
Özetle namespace, data center design ve DAG için ciddi değişiklikler olmamasına karşın asıl değişiklikler Server tasarımında kendini göstermektedir.
Öncelikle namespace kavramı değişiklikleri ile başlayalım;
Burada mevcut kavramları iyi biliyor olmanız lazım, bu nedenle hala geçerli olan aşağıdaki iki makaleyi okumanızı tavsiye ederim;
https://blogs.technet.microsoft.com/exchange/2015/10/06/namespace-planning-in-exchange-2016/
https://blogs.technet.microsoft.com/exchange/2015/10/08/load-balancing-in-exchange-2016/
Exchange Server 2019 için de her şeyin temeli bound veya Unbound name space modeli belirlemek ile başlıyoruz.
http://sozluk.cozumpark.com/goster.aspx?id=4480&kelime=Bound-Model
http://sozluk.cozumpark.com/goster.aspx?id=4479&kelime=Unbound-Model
Burada önerilen Unbound model olup name space için örnekler aşağıdaki gibidir;
Autodiscover service: autodiscover.contoso.com
HTTP clients: mail.contoso.com
IMAP clients: imap.contoso.com
SMTP clients: smtp.contoso.com
Tabiki sizlerin iş ihtiyaçlarına göre bu model değişiklik gösterebilir özellikle bir birinden çok uzak ve network anlamında gecikme olan senaryolar için.
Eğer imkanınız var ise her bir URL için NLB kullanımı ve eğer yine veri merkezlerinin dağılımı eşit ise NLB tarafında da %50 – %50 yük dağılımı önerilmektedir. Ancak pek çok müşterimde tek bir veri merkezinde bile bazen 3-1-1 kuralı ile ilerlediğimiz oluyor. Bu da zaten sizin veya danışmanınızın uzmanlığı ile ortaya çıkan bir sonuç.
Böyle bir yapılandırma daki diğer önemli konu ise olası kesintilere karşı DNS kayıtlarının tazelenme süresi olan TTL’ in ayarlanmasıdır. Varsayılan olarak 24 saat veya üzeri TTL kullanımlarında eğer DNS temelli bir yük dengeleme yapıyorsanız ciddi kesinti süreleri ile karşı karşıya kalabilirsiniz. Burada önerilen değerler eğer mevcut sistemlerinizin compute gücü yetiyor ise 1 saat’ lik bir TTL süresidir.
Olası güncellemeler için geçici olarak bu süreler daha kısa zamanlar ile güncellenebilir.
Çok yaygın olmamak ile beraber son dönemde giderek artan Office Online Server kullanımı sayesinde bilgisayarında ofis yazılımı olmayan kullanıcılarınız da online olarak Word, excel vb ofis programlarını kullanarak kendilerine gönderilen ekleri anında değiştirip tekrar iletebiliyorlar.
Bu tarafta ne yazık ki bound model önerilmektedir. Yani veri merkezi seviyesinde onbound olarak ilerlediğiniz bölüm burada name space olarak bound modeline dönüyor.
İkinci başlığımız Site resilient datacenter pair design;
Çok temel olarak yüksek erişilebilir bir alt yapı için iki veya daha çok bir birine sağlıklı bir şekilde bağlanmış veri merkezlerine ihtiyacınız vardır. Özellikle bu veri merkezlerinin bir birine bağlandığı network alt yapıları mutlaka yedekli olmalıdır.
Burada tasarım olarak en önemli tavsiye her bir veri merkezi AD tarafında da ayrı bir site olarak tanımlanmalıdır.
Transport seviyesinde HA sunan Shadow redundancy ve Safety Net’ in gerçek manada çalışması için en az farklı bir site içerisinde transport servis çalıştıran bir exchange sunucusuna ihtiyacı vardır.
Burada unutulmaması gereken konu, eğer bir network ayrı site olarak tanımlanacak ise en az 10ms ve üstü gecikme yaşanmalıdır. Bu tavsiye edilen değer olup yine iş ihtiyacınız gereği örneğin aynı binada olan networkler için bile ayrı site tanımı bile yapabilirsiniz.
En çok değişiklik olan bölüm Server design;
Çok ilginç gelecek ama Microsoft tüm donanımların fiziksel ve disklerin de local olarak bağlanmasını tavsiye ediyor. Aslında SQL kullananlar bilir SQL için de benzer öneriler bilinmektedir. Ancak ne bundan önceki ne de bundan sonraki tüm önerileri yapmamız şart değil. Danışman olarak veya sektör çalışanları olarak zaten şirketimizin iş ihtiyacı için en iyi yapılandırmaları bilip bunu iş ihtiyacımız doğrultusunda güncelleyebiliyor olmamız gerekmektedir.
Az da olsa bir performans kaybı ve gereksiz yönetim işletme katmanlarına sahiptir. Özellikle HA için gereksiz yapılan ayarlamalar. Exchange Server hali hazırda zaten donanım katmanındaki sorunlar için HA özellikleri ile gelen bir ürün.
Donanım olarak aşağıdaki isterleri karşılayan Commodity herhangi bir sunucu olabilir;
http://sozluk.cozumpark.com/goster.aspx?id=4481&kelime=commodity-server
2U, dual socket servers with up to 48 physical processor cores (an increase from 24 cores in Exchange 2016)
Up to 256GB of memory (an increase from 192GB in Exchange 2016)
A battery-backed write cache controller
12 or more drive bays within the server chassis
The ability to mix traditional rotating platter storage (HDD) and solid-state storage (SSD) within the same chassis.
Burada tabiki daha kesin kararlar vermek için bundan öncede yaptığımız gibi
Exchange Server Role Requirements Calculator
Kullanmanızı şiddetle tavsiye ediyorum.
Disk tarafında ise OS için mutlaka RAID1 kalan DB ve loglar için ise SATA, SAS veya SSD önerilmektedir.
Aslında bu kısımda iş ihtiyacı ile orantılıdır. Örneğin geçenlerde bir müşterimde exchange server veri tabanları SSD disklerde duruyordu. Müşterimi bildiğim için bir sorun oldu ve node’ lardan birisine SSD den lun veremediğini söyledi, bende ona mevcut iş ihtiyaçlarını bildiğim için SAS diskler ile sorunsuz bir şekilde hizmet verebileceğimizi söyledim, önce pek inanmak istemedi ama SAS üzerinde de sorunsuz bir şekilde sistemin çalıştığını ve kullanıcıları rahatsız edecek ya da yedekleme politikalarını değiştirecek bir yavaşlamanın olmadığını gözlemledik. Tabiki full flash, ssd daha hızlıdır ancak gereksiz disk yatırımı da şirketlere ek maliyet olarak yansımaktadır.
Peki Exchange Server 2019 da hangi durumlarda SSD kullanmalıyız.
Aslında tüm veri tabanları SATA veya SAS disklerde tutabiliriz ancak yeni gelen MetaCache Database (MCDB) özelliğini kullanacaksanız mevcut kapasitenin % 5 ila 10 arasında SSD barındırmanız önerilmektedir.
Basit bir örnek ile 28TB’ lık full SAS veya SATA diskleri veri tabanı için ayırıyorsanız eğer 1.4TB ila 2.8TB arasında da SSD havuzunuz olmalıdır.
Yukarıda da bahsettiğim gibi fiziksel mantık ile gidildiğinden birde burada SATA/SAS – SSD oranı söz konusu. Yani DB için ayırdığınız her SATA/SAS disk’ in 3 te 1 oranında SSD disk istenmektedir.
Ama unutmayın SSD de sorun olması demek veri kaybı demek değildir, sadece cache için kullanıldığında veriler SATA/SAS disklerden biraz daha yavaş olsa da gelmesi demektir.
Daha basit bir örnek ile;
20 HDD den oluşan bir kurulum aşağıdaki gibi paylaştırılabilir;
2 HDD İşletim sistemi için
12 HDD Exchange Database storage
1 HDD AutoReseed spare için ki bu Opsiyonel
Bu durumda 4 SSD de MCDB için kullanılabilir. SSD Boyutlar yine DB için ayrılan disklerin boyutlarının %5 ila %10’ u arasında seçilebilir. Ek olarak RAID için spare disk ayrımak gerekli olduğunu unutmayın lütfen.
Dosya sistemi olarak ise ReFS tercih etmeniz önerilmektedir ancak integrity özelliği kapalı olmalıdır. Benzer şekilde DAG için eğer Autoreseed yapacak iseniz onun da dosya formatının ReFS olması gereklidir. Bunun için aşağıdaki komutu kullanabilirsiniz.
Set-DatabaseAvailabilityGroup -Identity< DAGIdentity> -FileSystem ReFS
Bilgi güvenliğinin önemli olduğu noktalarda örneğin sunucularınızın bir veri merkezinde tutulması veya public cloud üzerinde olması durumunda bitlocker önerilen güvenlik önlemlerindendir.
https://blogs.technet.microsoft.com/exchange/2015/10/20/enabling-bitlocker-on-exchange-servers/
Evet gelelim son başlığımıza, Database availability group design;
Öncelikle bunu pek çok müşterime söylememe rağmen yine de inatla kurmaya çalıştırmaya çalışanlar oluyor, hatta bazıları beni de alet ediyor. Her türlü ben çalıştırırım ancak doğru değil.
Neyden bahsediyorum?
DAG üyesi sunucuların birden çok veri merkezinde olmasına karşın bu veri merkezlerinin tek bir Active Directory site olarak tanımlı olduğu durumlara verilen isimdir.
Tavsiye edilen yöntem her bir DAG için minimum iki veri merkezinde üyesi bulunan ve her bir veri merkezinin ayrı bir Active Directory site olduğu mimarilerdir.
Böyle bir senaryoda Unbound model tercih ediliyor ve tüm veri merkezleri arasında eşit yük dağıtımı yapılacak şekilde yapılandırma tamamlanıyor.
Ancak Türkiye şartlarında pek bu durum böyle olmuyor çünkü özellikle network hatlarının pahalı olması nedeni ile Exchange sunucuları kullanıcıların olduğu veri merkezine kurulup diğer veri merkezi disaster site olarak yapılandırılıyor. Ancak büyük yapılarda tabiki ülke genelinde bir den çok veri merkezi eşit yük dağılımı şeklinde çalışan örneklerde yok değil.
Buradaki bir önemli konuda yine Türkiye de pek göremediğimiz tüm veri merkezlerindeki node sayılarının eşit olması ve bu sayede Witness, quorum, config gibi yapılandırma ayarlarının da eş olması anlamına gelmektedir.
DAG network tasarımında ise kritik nokta team yapılandırılması istenmemesi. Her zaman ek bir config veya driver bağımlılığı olduğu için daha basit modelleme yapabilmek adına team olmayan ancak iş ihtiyacınız karşılayacak 1gigabit veya 10gigabit veya 40gigabit’ lik iki ayrı Ethernet bağlantısı istenmektedir. Bir hat MAPI yani istemci trafiği için, diğer hat ise replikasyon ve yedekleme trafiği için kullanılır. Ancak eğer mevcut örneğin 10Gigabit’ lik hattınız hem MAPI, hem replika hem de yedekleme için yeterli ve bu hat aslında arka tarafta iki ayrı switch ve benzeri yedekli ise illaki iki hatlı bir yapı kullanmanız gerekmez.
Buradaki mantık yedeklilik ve performans. Hat yedekli ve yeterince performanslı ise tek hat ile DAG kurulumu yapabilirsiniz.
Witness server lokasyonu da DAG yapılandırmasında büyük önem taşımaktadır. Örneğin iki veri merkezli bir yapıda eğer 3. Bir veri merkezi veya lokasyonunuz var ise Witness sunucuların burada olması önerilmektedir. Eğer bu yok ise Azure üzerine konumlandırabilirsiniz.
Yine müşteri ihtiyaçlarına göre değişmek ile beraber Microsoft en iyi veri bütünlüğü ve koruması için 4 node DAG ve her bir veri tabanı için 1 asıl 3 kopya şeklinde yapılandırma önermektedir.
Veri bütünlüğü ve güvenliği noktasında DAG içerisindeki her bir veri tabanının mutlaka bir den çok kopyası olmasını sağlayın. Ancak bu ek sunucu, OS, storage ve benzeri maliyetlere neden olacağı için gerekli olmaması durumunda kullanmanız lüks olacaktır.
Özelikle büyük yapılarda veri bütünlüğündeki sorunlar kopya veri merkezlerine de sıçrayacağı için ya daha sık yedekleme yapmanız veya lag site yapılandırmanız önerilmektedir.
http://sozluk.cozumpark.com/goster.aspx?id=1253&kelime=lag-site
Aynı mantık ile DAG için replikasyon süresini esnetebilirsiniz.
Son olarak eğer office online server yapılandırması da düşünüyorsanız 8 core 32GB Ram ve 40GB boş alana sahip bir makine yeterli olacaktır. Eğer yapı büyük ise tabiki Farm kurabilirsiniz ancak buradaki en kritik nokta OOS ile exchange sunucuların arasındaki network gecikmesi en düşük seviyede olacak şekilde konumlandırılmalıdır.
Umarım faydalı bir makale olmuştur, bir sonraki makalemde görüşmek üzere.
Kaynak
Stretched DAG resmini aldığım link
https://4sysops.com/wp-content/uploads/2013/12/Stretched-Active-Directory-site.png
