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.
