Forum

Exchange Server 201...
 
Bildirimler
Hepsini Temizle

Exchange Server 2013 multiple databases per volume

1 Yazılar
1 Üyeler
0 Likes
389 Görüntüleme
Hakan Uzuner
(@hakanuzuner)
Gönderiler: 32996
Illustrious Member Yönetici
Konu başlatıcı
 

1

Merhaba, bu konuda aslında bazı makalelerimin içerisinde paylaşımda
bulundum, ancak gördüm ki internet aramalarında göze çarpmıyor ve gelen
sorulara cevap olması için ayrıca hızlı bir şekilde özetlemek istedim.

Buradaki amaç öncelikle bizlere verilen büyük boyutlardaki disk
alanlarını daha düzgün kullanmaktadır. Örneğin bize 8TB’ lık bir LUN
verildiği zaman biz bir veri tabanı için önerilen maksimum boyut olan
2TB’ ı kullandığımızı düşünürsek geriye kalan 6TB alan boşa harcanmış
olacaktır. Tabiki daha küçük boyutlu diskler kullanabiliriz. Ancak bizim
amacımız host sayımız kadar tek bir lun almak ve bu LUN’ u oluşturacak
maksimum disk ile bu işi yapmak.

Başka bir ifade ile 2TB’ lık 4 ayrı LUN demek aslında elinizdeki
toplam diskleri bölmeniz demektir. Biz ise elimizde ne kadar disk var
ise bir sunucu için ayrılmış ondan bir LUN yapıyoruz. Bu sayede
öncelikle tüm disklerin yazma okuma gücünü birleştirmiş olduk. Ancak
elimizde büyük bir alan oldu. Bu alanı node sayımız kadar LUN ile aktif
bir şekilde kullanmamız gerekiyor. Yukarıdaki şekildeki senaryoya göre
anlatmak gerekir ise 4 node için 4 LUN yeterli, ve 4 NODE Olduğu için 4
veri tabanı oluşturuyoruz. ( buna symmetrical design deniyor).

Her sunucuda aynı boyutta LUN ve bir aktif mailbox databases var.
Bunun en büyük yararı olası bir disk sorununda yeni bir disk eklediğiniz
zaman o disk’ e diğer mailbox veri tabanlarının hemen pasif kopyaları
atılmalı.Eğer siz yapıyı bu şekilde değil de örneğin iki node üzerinde
ikişer db olacak şekilde yaptığınız  zaman disk sorunlarında iki veri
tabanı pasif kopyası oluşması için tek bir LUN çalışacak bu da süreyi
bir hayli uzatacaktı. Örneğin normal şartlarda 2TB’ lık bir aktif
kopyanın pasif kopyasının oluşması 23 saat sürer, eğer bu senaryoda
sizin iki veri tabanınız bir disk üzerinde olduğunda tüm okuma yükü ona
bineceği için süre uzayacaktır.

Peki bizim senaryomuza dönelim. MBX1 in bağlı olduğu storage gitti.
Bu durumda DB1 bir kere önceliğe göre hemen diğer bir kopyadan hizmet
vermeye devam edecektir. Bir süre sonra disk sisteminde sorun giderildi
ve yeni bir disk bağlandı MBX1 makinesine. Bu durumda siz tekrar seeding
işlemi başlatacaksınız ki MBX1 de DAG içerisinde aktif bir oyuncu
olsun. İşte tam bu noktada her DB nin aktif kopyası farklı disklerde
olduğu için bunlardan kopyalama yapılacak ve bir LUN – disk havuzu
yerine ayrı ayrı 3 LUN ve ona hizmet eden diskler bu sürece hizmet
vereceği için daha hızlı çalışacaktır.

Danışman - ITSTACK Bilgi Sistemleri
****************************************************************
Probleminiz Çözüldüğünde Sonucu Burada Paylaşırsanız.
Sizde Aynı Problemi Yaşayanlar İçin Yardım Etmiş Olursunuz.
Eğer sorununuz çözüldü ise lütfen "çözüldü" olarak işaretlerseniz diğer üyeler için çok büyük kolaylık sağlayacaktır.
*****************************************************************

 
Gönderildi : 10/03/2015 19:11

Paylaş: