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.
https://sozluk.cozumpark.com/goster.aspx?id=4480&kelime=Bound-Model
https://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;
https://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.
https://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
