RAID Yapısı

RAID yapısını seçerken ya da storage’ı dizayn ederken kesinlikle uzakta durmamanızı tavsiye ederim. Bu işlemler direkt olarak veritabanı performansına önemli ölçüde etki ediyor. Kurumunuzdaki sistem sorumlusu ya da storage sorumlusu sizin read ve write oranınızı ya da hangi uygulamanın daha çok IO yaptığını sizin kadar bilemez. Bu yüzden disk isterken ona bazı parametreler vermeniz gerekir. Bu parametreleri verebilmek için RAID yapısını ve storage’ın arka planda nasıl çalıştığını biliyor olmanız gerekir. Bu konuları bir DBA’in bilmesi gerektiği kadarıyla ele alalım. Bu makaleyi okumadan önce “SQL Server Sunucuların Kullandığı SAN Altyapısı ve Uygulama Sunucusundan Gelen Bir Query’nin Hikayesi” ve “Veritabanı Sunucunuzun Yaptığı IOPS ve Throughput’u Data Collector Kullanarak Bulmak” isimli makalelerimi okumanızı tavsiye ederim.

RAID(Redundant Array of Independent Disk Drives):

Kısaca, disklerin daha performanslı ve/veya daha güvenli(veri kaybına karşı) çalışmasını sağlayan teknolojidir. Çeşitli RAID türleri vardır. Bazılarında performans daha üst seviyelerdeyken veri kaybetme olasılığı daha fazla, bazılarında veri kaybetme olasılığı azken performans daha alt seviyelerdedir. Bazılarında ise hem performans yüksek hem veri kaybı ihtimali daha azdır. Tabi kullanılan disk adedi ve bununla doğru orantılı olarak maliyette bu türlere göre değişecektir. Şimdi en çok kullanılan RAID türlerine değinelim.

RAID 0: Performans açısından çok hızlıdır ama veri kaybetme olasılığı fazladır. En az iki disk ile yapılabilir. Veri yazılırken bölünerek disklere aynı anda yazılır ve okunurken bu bölünmüş parçalar farklı disklerden aynı anda okunur.  Bu yapıyı oluşturabilmek için ekstra disk kullanmak gerekmez. Örneğin 2 TB veri için 1 er TB iki disk yeterli olacaktır. 2 TB’lık veriyi 1 er TB halinde 2 diske yazacaktır. Mission Critical sistemlerde kullanılmaz. Veri kaybının önemli olmadığı ve performansın önemli olduğu sistemlerde kullanılabilir. Aşağıdaki resimde RAID 0 yapısını görebilirsiniz.

RAID 1: Performans açısından yavaştır ama veri kaybetme olasılığı daha azdır.  En az iki disk ile yapılabilir. Verileri kopya halinde 2 diske yazar. Bu yüzden hem performans azalır hem de ekstradan disk kullanmak gerekir. Örneğin 2 TB veri için 2 şer TB 2 adet diske ihtiyaç duyulacaktır. Performans olarak yavaş olduğu için mission critical sistemlerde çok tercih edilmez. İşletim sisteminin kurulacağı disk için bu yapıyı kullanabilirsiniz. Aşağıdaki resimde RAID 1 yapısını görebilirsiniz.

RAID 10: En az 4 disk ile yapılabilir. Adından da anlaşılacağı gibi RAID 0 ve RAID 1 ‘in bir karışımıdır. İki adet RAID 1 grubunun RAID 0 şeklinde birleştirilmesi ile oluşur. RAID 0’ın performansını ve RAID 1 ‘in veri güvenliğini bir arada sunar. Disk maliyeti RAID 1 deki gibidir. 4 TB’lık bir diske 2 TB’lık bir veri yazılabilir. Eğer kurumunuzda disk ile ilgili bir kısıtlama yoksa veritabanlarınız için bu RAID yapısını kullanmanızı tavsiye ederim. Aşağıdaki resimde RAID 10 da nasıl yazıldığını görebilirsiniz.

RAID 5:  En az 3 disk ile yapılabilir. RAID 0’ da olduğu gibi verileri eşit olarak disklere yayar. Fakat veriler disklere yazılırken disklerden her hangi biri arızalandığı durumda sistemin veri kaybı olmadan çalışabilmesi için bozulan diskteki verileri geri getirmek için parite adı verilen bir algoritma da disklere yazılır. Aşağıdaki resimde RAID 5 teki verilerin ve paritenin disklere nasıl yazıldığını görebilirsiniz.

3 disk kullanılarak RAID 5 konfigurasyonu yaptığınız takdirde 1 disk arızasına karşı sistem koruma altında olacaktır. Peki performans ve veri güvenliği bakımından RAID 5’in konumu nedir?

Performans anlamında RAID 0 daki gibi bir read performansı elde edilir. Çünkü verileri eşit bir şekilde disklere paylaştırıyor. Ama write konusunda RAID 0 daki gibi bir performans elde etmek mümkün değil. Çünkü burada devreye ekstra olarak parite hesabı giriyor. 3 disk kullanılırsa 2 disk kapasitesini, 5 disk kullanılırsa 4 diski kapasitesini aktif olarak veri için kullanabiliyoruz.

Görüldüğü gibi RAID 5’te read performansı çok iyiyken, write performansı kötüdür. Eğer sisteminizde %80’lere varan bir read oranınız varsa ve kurumunuz disk maliyetinden kaçınıyorsa veritabanlarınız için RAID 5 kullanabilirsiniz.

RAID 6: RAID 5’in biraz daha güvenli halidir. 2 disk kaybına karşı korumalıdır. En az 4 diskle yapılır. Ben genelde 6+2  ya da 8+2’yi tercih ediyorum.

Örneğin 3+2 yaparsanız aşağıdaki gibi veriyi 3’e bölecek ve 2 şer tane de parity bilgisi koyacaktır. Yazma hızı RAID 5’e göre daha yavaş ama veri kaybına karşı daha güvenli bir RAID seviyesidir. 8+2 yaptığınızda veriyi 8 eşit parçaya böleceği için performans anlamında da iyi bir seviyeye geliyor.

Yukarıdaki RAID seviyelerini göz önüne alarak hangi uygulama için nasıl bir RAID yapısı isteyeceğinize karar verebilirsiniz. Bunun için uygulamalarınızın yaptığı IOPS ‘u dikkate almalısınız. Çok write yapmayan diskler için RAID 10 yapısını kullanarak gereksiz yere maliyeti 2 katına çıkarmaya gerek olmadığını düşünüyorum. Hangi uygulamanın(uygulamaların disklerinin ayrı olduğunu düşünerek bunu söylüyorum. Eğer bir diskte farklı iki uygulama varsa bu iki uygulamanın toplamda yaptığı IOPS’u bulabilirsiniz.) ne kadar IOPS yaptığını ölçerek bu uygulama için nasıl bir RAID yapısına ihtiyacınız olduğuna karar verebilirsiniz.

Storage: Storage kısmında pooling kavramı vardır. Birden fazla diski aynı havuza alarak daha sonra bu havuzdan sunucuda kullanmak üzere drive’lar tanımlayabilirsiniz. Birbirinden farklı türde diskleri bir araya getirerek bir pool oluşturabilirsiniz. Mesela 10 adet SSD, 20 adet SAS ve 50 Adet NearLine diski bir araya getirerek bir pool oluşturabilirsiniz. Disk adedi arttıkça alınabilecek maksimum IOPS miktarıda artacaktır. Bu şekilde farklı uygulamalara farklı pool’lar tanımlayarak uygulamalarınızın yaptığı IO’yu birbirinden izole edebilirsiniz. Tabi bu şekilde bütün uygulamalar için farklı pool’lar tanımlamakta mantıksız olacaktır. Çünkü bu şekilde yaptığınızda kullanılmayan ya da az kullanılan uygulamalar için gereksiz yere IO kapasitesi ayırmış olursunuz. Örneğin 10 adet SSD ve 20 adet SAS diski bir pool’a koyduğumuzu düşünelim. 비트 코인 온라인 카지노 Bu 30 diskin toplamda bize sağlayabileceği maksimum IOPS miktarını(bu miktarı storage sorumlunuzdan ya da storage’ı aldığınız firmadan öğrenebilirsiniz), bu pool’dan tanımladığımız her drive paylaşacaktır. Hiç kullanılmayan ama büyüklüğü fazla olan bir veritabanı için böyle özel bir havuz oluşturduğumuz takdirde bu pool’dan alınabilecek IOPS miktarı boşa gitmiş olacaktır. Uygulamaların ihtiyacı olan IOPS miktarı dikkate alınarak, bu IOPS’u sağlayabilecek pool’lar oluşturmak ve bu uygulamara sağlanacak diskleri bu pool’dan vermek en profesyonel davranış olacaktır. “Veritabanı Sunucunuzun Yaptığı IOPS ve Throughput’u Data Collector Kullanarak Bulmak” isimli makalemi okumanızı tavsiye ederim.

Tabi birde tiering dive bir kavram varki, çok kullanılan drive’ları otomarik olarak SSD ye, az kullanılan drive’ları otomatik ve online olarak SAS ya da Nearline disklere aktarabiliyor. Eğer storage altyapınızda böyle bir imkanınız varsa işinizi çok kolaylaştıracaktır. Tiering işlemi hangi verinin sıcak veri(sürekli erişilen), hangi verinin soğuk veri(erişim gerçekleştirilmeyen) olduğu ile ilgili istatistik toplar ve daha sonra bu istatistikleri kullanarak arka planda verileri SSD-SAS-NEARLINE katmanları arasında taşır. Hangi zaman dilimlerinde istatistik toplayacağı ve hangi zaman dilimlerinde veriyi bu katmanlar arasında taşıyacağını siz belirleyebiliyorsunuz. Storage uzmanınıza mesai saatleri içersinde istatistik toplamasını, gece de online aktarım(SSD-SAS-NEARLINE katmanları arasında) yapmasını sağlayacak şekilde schedule etmesini söylemelisiniz.

Veritabanı Sunucunuzun Yaptığı IOPS ve Throughput’u Data Collector Kullanarak Bulmak

Özellikle veritabanı sunucunuz için yeni storage alacağınız zaman alacağınız storage’ın sizin ihtiyaçlarınızı karşılayıp karşılamayacağını bilmeniz gerekir. Yada ihtiyacınızdan fazla bir storage almak istemezsiniz. Bu yüzden veritabanı sunucunuzun yaptığı IOPS’u ve throughput’u hesaplamanız gerekir.

IOPS(Input/Output Operations Per Second): Saniye yapılan okuma ve yazma sayısı

Throughput: Saniyede kaç mb okuma veya yazma yapılabildiğini gösterir. IOPS ve BlockSize(Allocation Unit Size) parametreleri kullanarak hesaplanır.

Throughput=IOPSxBlockSize/1024

BlockSize ile ilgili “Diskimizi maksimum performansta kullanabiliyor muyuz?” isimli makalemi okumanızı tavsiye ederim.

Üreticiler genelde stograge’ın throughput’unu hesaplarken BlockSize’ı 4K olacak şekilde hesaplarlar. Ama SQL Server için tavsiye edilen througput 64K’dır. Çünkü SQL Server okuma ve yazma işlemlerini genelde 64K olacak şekilde yapar.

Peki veritabanı sunucumuzun yaptığı IOPS’u nasıl hesaplayacağız?

Veritabanı Sunucunuzun Yaptığı IOPS’u hesaplamak için bir çok yöntem var. Ama bunlardan en doğrusu bu testi mevcut storage’ınızın üreticilerinden yapmasını istemek. Üreticiler mevcut storage’ınıza bir server bağlayarak 1 ay boyunca bu server’a bağlı uygulamaların yaptığı IOPS’u hesaplayarak size ihtiyacınız olan IOPS değerine sahip bir storage önerebilirler.

Çoğu kurum ve firma storage alırken bu işlemi yapmıyor. Biz bu makalede sadece sunucumuza bakarak ne kadar IOPS yaptığımızı ve storage tarafında ne kadar IOPS’a ihtiyacımız olacağını hesaplayacağız. Yöneticiniz ya da kurumunuzdaki storage uzmanınız size veritabanı sunucusu için ne kadar IOPS kapasitesine sahip bir storage gerekir diye sorduğunda bu makaledeki adımları takip ederek cevap verebilirsiniz.

IOPS deyince akla Frontend IOPS ve Backend IOPS gelmelidir.

Frontend IOPS sizin sunucu tarafında gördüğünüz IOPS’tur. Backend IOPS ise storage tarafında hissedilen IOPS’tur.

Öncelikle sunucudaki veritabanına bağlı tüm disklerin Frontend IOPS’unu hesaplamamız gerekir. Bu hesaplamayı yapmak için perfmon counter’larını kullanacağız.

Araç çubuğuna perfmon yazarak enter’a bastığımızda karşımıza aşağıdaki gibi bir ekran gelmesi gerekir.

Bu ekranda Performance Monitor’e tıklıyoruz. Karşımıza gelen ekranda yukarda artı işaretine tıklıyoruz.

Karşımıza gelen ekranda aşağıdaki counter’ları seçiyoruz ve bu counter’lar seçili iken veritabanımız hangi diskte yada hangi disklerde tutuluyorsa Instance of selected object’in altından o diskleri seçerek Add diyoruz.

Bu seçenekleri ayarladıktan sonra karşımıza aşağıdaki gibi bir ekran gelecek. Bu ekrandan anlık olarak takip edebilirsiniz. Örneğin aşağıdaki resimde Disk Writes/Sec’ın maksimum değeri 1087 olmuş.

Tabi bu şekilde sadece anlık olarak izleyebilirsiniz. Genel bir kanı oluşabilmesi için bu değerleri sürekli inceleyen collector’lar oluşturmanız gerekir. Anlık olarak izlememizi sağlayan biraz önce yaptığımız bu işlemin arka planda sürekli çalışmasını sağlayan iş olarak düşünün.

Peki Data Collector’ları nasıl oluşturuyoruz. IOPS’u izleyen bir data collector oluşturalım. Aşağıdaki gibi Data Collector Sets’in altında User Defined’a sağ tıklıyoruz. New ve ardından Data collector Set seçimlerini yapıyoruz.

Karşımıza gelen ekranda data collector set’imize bir isim veriyoruz ve Create manually seçeneğini seçiyoruz.

Ben IOPS ismini verdim. Next diyerek ilerliyoruz.

Gelen ekranda aşağıdaki gibi Create data logs kısmından Performance counter’ı seçip next diyoruz.

Gelen ekrandan Add diyoruz ve makalenin başında seçtiğimiz counter’ları Add diyerek ekleyerek Next diyoruz.

Aşağıdaki ekrana gelene kadar next diyerek hiçbir değişiklik yapmadan ilerliyoruz. Aşağıdaki ekranda da Start this data collector set now’ı seçerek Finish diyoruz.

Bu collector arka planda 15 saniye bir istenilen değerleri sistemden çekerek logluyor. Normalde doğru sonuçlar almak için bu loglama işlemini en az 1 ay yapmanız gerekir. 1 ay geçtiğini düşünerek aşağıdaki gibi data collector’ı stop diyerek durduruyorum.

Durdurma işleminden sonra sağ tıklayarak Latest Report diyorum.

Açılan rapordaki değerlerin maksimum ve average değerlerini inceliyorum. Şahsen ben storage alacağım zaman maksimum değerleri baz alırım. Çünkü sistemin gerçekten ihtiyacı olan maksimum IOPS’u elde etmek isterim. Tabi bu kurumunuzun bütçesi ile alakalı bir durum. Daha az performans daha az maliyet demektir. Maksimum değerleri alırsanız Read ve Write’ların toplam değeri Disk Transfer/Sec ile uyuşmayacaktır.  Disk Reads/Sec ve Disk Writes/Sec counter’larının average değerlerinin toplamı Disk Transfer/Sec counter’ının average değerine eşit olacaktır.

Bu rapordaki maksimum değerleri alıyoruz. Benim örneğimde bu değerler şu şekilde.

Bu aldığımız değerler Frontend IOPS değerleri

Backend(Storage tarafında hissedilen Gerçek IOPS)’u ise aşağıdaki gibi hesaplıyoruz. RAID yapısının RAID 5 olduğunu düşünelim. Penaltı Değeri, RAID yapısına göre storage tarafında yapılan IOPS’u azaltabilen bir değerdir. Çünkü RAID 0 haricindeki tüm RAID yapılarında veri birden fazla diske yazılır. RAID yapıları ile ilgili “RAID Yapısı” isimli makalemi okumak isteyebilirsiniz.

Gerçek IOPS=(Toplam IOPS x Read Yüzdesi)+(Toplam IOPS x Write Yüzdesi x Penaltı Değeri)

Formüle gerçek değerlerimizi yerleştirelim.

Toplam IOPS=169

Read Yüzdesi=100*11/169=%6,5=0.065

Write Yüzdesi=%93,5=0.935

Penaltı Değeri=4

Gerçek IOPS=(169×0.065)+(169×0.935×4)=10.985+632.06=643.045

Gerçek IOPS’u hesaplayan bir excel’im var. Makaleye yorum yapanların mail adresine bu excel’i gönderebilirim.

Aşağıda RAID yapılarının penaltı değerlerini gösteren tabloyu bulabilirsiniz.

Önemli: Veritabanı sunucunuzun yaptığı toplam IOPS ve throughput’u hesaplamanız için veritaban’larının kullandığı tüm disklerin IOPS ve throughput değerlerini hesaplayıp toplamanız gerekir.

Bu makaleyle ilgili olarak aşağıdaki makaleleri okumanızı tavsiye ederim.

“SQL Server Sunucuların Network Konfigurasyonu ve Always ON Senkronizasyonunu Farklı Bir Ethernet Kartından Yaptırmak“,

“SQL Server Sunucuların Kullandığı SAN Altyapısı ve Uygulama Sunucusundan Gelen Bir Query’nin Hikayesi“,

“RAID Yapısı“

SQL Server Sunucuların Kullandığı SAN Altyapısı ve Uygulama Sunucusundan Gelen Bir Query’nin Hikayesi

Bu makalede SQL Server Sunucuların, Storage’a veri yazarken ve okurken hangi aşamalardan geçtiği ve verinin daha hızlı okunup yazılabilmesi için gerekli altyapının nasıl oluşturulması gerektiğinden bahsedeceğim. Bu makaleyi okumadan önce “SQL Server Sunucuların Network Konfigurasyonu ve Always ON Senkronizasyonunu Farklı Bir Ethernet Kartından Yaptırmak” isimli makalemi okumanızı tavsiye ederim. Network altyapısının nasıl çalıştığını öğrendikten sonra bir hikaye ile client üzerinden gelen bir query’nin nerelerden geçtiğinden bahsedelim.

Uygulama bir Query(Sorgu) ile Client üzerinden veritabanına gitmek için bir istekte bulunur. Bu istek uygulama sunucusunun ethernet kartından kurumun ana networkswitch’ine(omurga) gider. Eğer uygulama ile veritabanı sunucusu aynı vlan’da değilse(veritabanının güvenliği için aynı vlan da olmaması gerekir) gelen istek kurumun güvenlik cihazlarından geçer ve bu güvenlik cihazları gelen sorgunun saldırı yapma amacının olmadığından emin olduktan sonra veritabanı sunucusuna gider. Tabi her uygulama sunucusundan gelen isteğin veritabanına her porttan erişilmesine izin verilmez. Kurumda firewall aktif bir şekilde kullanılıyorsa uygulama sunucusundan veritabanı sunucusuna, veritabanının çalıştığı port üzerinden gelebilmesi için firewall üzerinde gerekli izinler tanımlanır. Uygulama izin verilen bir port dışında başka veritabanına hiçbir port üzerinden erişemez.

Query Firewall’dan çıkıp veritabanı sunucusuna gelir. SQL Server query’yi burada karşılar.

Query insert ise diske veri yazılması gerekir. Eğer SQL Server Sunucusunun kullandığı diskler bir storage üzerindeyse SQL Server Sunucusu üzerindeki FC portlardan SAN Switch’ gider. SAN Switch üzerinden bu diskler hangi storage üzerindeyse o storage’a gider ve veriyi yazar.

Query select ise sql server önce memory’de var mı diye bakar. Varsa memory’den veriyi alıp aynı yoldan geri gönderir. Yoksa diske gidip diskten getirmesi gerekecektir. Yine FC portu üzerinden SAN Switch’e ordan da diskin tanımlı olduğu storage’a giderek veriyi alır ve SQL Server Sunucusu üzerindeki memory’e aktarır. Daha sonra memory üzerinden veriyi alarak network switch üzerinden uygulamaya geri gönderir.

Peki SQL Server’ın disk performansının daha hızlı olması için SAN altyapısını nasıl konfigüre etmeniz gerekir.

Eğer birden fazla storage ve birden fazla SQL Server sunucunuz varsa mutlaka kurumunuzda bir SAN Switch kullanmalısınız. Ve SAN Switch tecrübesiz kişiler tarafından yönetilmemelidir. Ufak bir yanlış diskleri kaybetmenize sebep olabilir.

SQL Server kullanan bir sunucunun örnek SAN altyapısını anlatalım.

Sunucu üzerinde en az 4 adet FC port olmalıdır. Bu portlar en az 8gbps olmalıdır diyeceğim ama şu an 16 gbps fc portlar çıktı. Bundan 5 yıl sonra belki 64 gbps hızında portlar olacak. O yüzden bu rakama çok takılmayın.

En az 2 tane SAN switch olmalıdır ve bu SAN switch’ler birbirinin yedeği olarak konfigüre edilmelidir.

Sunucu üzerindeki 2 FC port birinci SAN Switch’e, diğer 2 FC port’ta yedek olan diğer SAN Switch’e bağlanmalıdır. Normalde SAN Switch üzerinde network tarafındaki gibi teaming yapamazsınız.  Ama Storage uzmanı bir arkadaşın yaptığı test sonucunda bir SAN Switch’e bir sunucu üzerinden 2 tane 8gbps hızında FC port takıldığında aynı anda görülebilecek toplam throughput değerinin 16’ya yaklaştığını söyleyebilirim. Toplam trafik 8gbps’ı geçene kadar sadece 1 tane portu kullanıyor. 8gbps’ı geçtikten sonra diğerini kullanmaya başlıyor. Tabi şunu unutmayın.

Sunucu tarafından SAN Switch’e 2 tane FC port taktınız. SAN Switch üzerinden de storage1 port taktınız. Burda darboğaz SAN Switch’ten Storage’a giderken yaşanacaktır ve throughput değeriniz 8gbps’ı aşamayacaktır. Yada diskleriniz bu IO’yu yapacak kadar hızlı değilse yine bu throughput değerini göremezsiniz. Yani görebileceğiniz toplam throughput değeri(aynı anda transfer edebileceğiniz toplam veri) zincirin en zayıf halkası kadar olacaktır. Storage, SAN Switch ve SQL Server Sunucuların üzerindeki portları alırken bütün bunları dikkate almalısınız.

Çok yoğun konsolide sistemlerde Sunucu başına 2x8gbps FC port günümüz şartlarında yeterli geliyor. Ama uygulamalarınızın yaptığı toplam IOPS ve throughput’u hesaplayarak daha fazlasına ihtiyacınız varsa 4x8gbps ya da 2x16gbps yapabilirsiniz. Sunucunuzun o anda yaptığı toplam IOPS ve throughput değerini hesaplamak için “Veritabanı Sunucunuzun Yaptığı IOPS ve Throughput’u Data Collector Kullanarak Bulmak” isimli makalemi okuyabilirsiniz. Storage’ınızın yapabileceği toplam IOPS ve throughput’u üreticiye sorabilirsiniz. Yada storage alırken en az şu kadar IOPS yapabilmelidir ve maksimum throughput değeri şu olmalıdır diyebilirsiniz. Port kapasitesi ve sayısını da buna göre ayarlamalısınız.

SQL Server Sunucuların Network Konfigurasyonu ve Always ON Senkronizasyonunu Farklı Bir Ethernet Kartından Yaptırmak

Bu makaleyi okumadan önce Always ON’un çalışma mantığını anlamak için “SQL Server Always ON AG(Availability Group) Oluşturmak” isimli makalemi okumanızı tavsiye ederim.

Always ON’da 3 tip network trafiği vardır.

1. Uygulamaların veritabanına eriştiği trafik. Client olarak geçer.
2. Always ON’un primary veritabanından secondary veritabanına senkronizasyonu sağladığı trafik. Endpoint’ler üzerinden geçer. “SQL Server Always ON AG(Availability Group) Oluşturmak” isimli makalemde endpoint’lerin nasıl oluşturulduğundan bahsetmiştim.
3. Heartbeat trafiği. Windows Cluster, Cluster’daki node’ların ayakta olup olmadığı ve connection kabul edip etmediği kontrol eder ve Primary node yanıt vermiyorsa otomatik failover işlemi gerçekleştirilir.

Best Practice olarak Microsoft bu 3 network için 3 ayrı ethernet kartı tavsiye eder. Tabi her ethernet kartı kendi içinde teaming(aşağıda anlattım) ile yedekli olmalıdır ve ethernet omurgasına çıkarken de yedekli olmalıdır(aşağıda anlattım). Yani her sunucuda 3×4=12 tane ethernet portu olması gerekir.

1. Client trafiği için uygulamaların yaptığı trafik yüksekse 10gbps x 4 tane
2. Always On Senkronizasyon trafiği için uygulamaların yaptığı trafik yüksekse 10gbps x 4 tane
3. Heartbeat trafiği için 1gbps x 4 tane

Teaming Nedir?

Sunucu üzerindeki 2 tane ethernet portu üzerinden kurumunuzdaki network switch’e bağlandığınızı düşünün. Bu 2 ethernet portunu teaming yaparsanız biri bozulsa trafik diğerinden devam eder. 2 side çalışıyorsa trafik 10+10=20gbps hızda yapılabilir. Yani hem yedek hem de yapılabilecek trafiğin ikiye katlanması olarak düşünebilirsiniz.

Ethernet omurgasına çıkarken yedekli olmak nedir?

Teaming yaparken kurumunuzdaki network switch’inize(omurga olarak geçer) nasıl bağlanacağınızı yukarda anlattım. Peki bağlandığınız omurga genel olarak bozulursa ne olacak? Bu yüzden kurumlarda birbiri ile yedekli çalışabilen 2 tane network switch vardır. Biri bozulursa diğeri devreye girer. Bu şekilde Teaming ile 1 port 2 ye çıkarken, omurgada da yedekliliği sağlayabilmek için ihtiyacımız olan port 2 iken 4’e çıkar.

SQL Server kullanılacak bir sunucu alacaksanız sunucu üzerindeki ethernet port’larının sayısını ve kapasitesini yukardaki açıklamaları okuduktan sonra belirlemenizi tavsiye ederim.

Failover Cluster Manager’ı açarak sizin cluster’ınızdaki network konfigurasyonuna bakabilirsiniz. Aşağıdaki gibi Failover Cluster Manager üzerinden Networks sekmesine gelirseniz windows cluster’da tanımlı ethernet kartlarını görebilirsiniz. Bizim örneğimizde bir tanesi Cluster Only(heartbeat trafiği için), diğeri Cluster And Client(heartbeat,alwayson senkronizasyon ve client trafiği)

Cluster Only olana sağ tıklayıp properties derseniz aşağıdaki ekran gelecektir.

• Allow cluster network communication on this network derseniz bu ethernet üzerinde heartbeat trafiğinin geçmesini sağlamış olursunuz. Hemen altındaki checkbox’ı işaretlemezseniz ve ok’e basarsanız Cluster only olarak gözükecektir.
• Yukarıdaki maddeyle beraber Allow clients to connect through this network checkbox’ını da işaretlerseniz client ve always on trafiğine de izin vermiş olacaksınız.
• Do not allow cluster network communication on this network’ü seçerseniz heartbeat trafiğini engellemiş olursunuz. Bu seçeneği çok önermiyorum. Heartbeat için Cluster only, client trafiği için Cluster and Client şeklinde ayarlayabilirsiniz.

Normal şartlar altında Always On için farklı bir ethernet kartı ayarlamadıysanız always on’un senkronizasyon trafiği Cluster and Client olarak ayarladığınız ethernet kartı üzerinden yapılacaktır. Ama always on ‘un senkronizasyon trafiğini ayırmak bazı durumlarda daha faydalı olabilir.

• Always On senkronizasyon trafiğini ölçülebilir hale getirirsiniz. Network trafiğini izleyen third party uygulamalarla bu trafiklerin history’sini izleyebilirsiniz. Anlık olarak task manager’da da görebilirsiniz.
• Senkronizasyona özel bir port ayırdığınız için çok yoğun transaction içeren uygulamalarınızın performansı artabilir.(Artabilir diyorum çünkü bu işlemi sadece test ortamında gerçekleştirdim. Gerçek ortamdaki performans artışını henüz ölçme fırsatım olmadı.)

SQL Server Always ON kullanan bir sunucunun örnek network bağlantı şekli nasıl olur?

2 sunucunuz var ve bu 2 sunucu üzerinde always on kullanıyorsunuz.

Heartbeat için her sunucu üzerinde 4 tane 1 gbps kapasitesinde port ayırdınız.(2 si teaming ile primary network switch’e gidiyor. Diğer ikiside teaming ile yedek network switch’e gidiyor.) Heartbeat bağlantısı için yukarda anlattığım gibi Cluster only yapmanız gerekiyor.

Heartbeat ve client trafiği için 4 tane 10 gbps kapasitesinde port ayırdınız.(2 si teaming ile primary network switch’e gidiyor. Diğer ikiside teaming ile yedek network switch’e gidiyor.) Bu ethernet kartı için hem heartbeat hemde client trafiği için Cluster and client yapmanız gerekiyor.

Always On senkronizasyon trafiği için 4 tane 10 gbps kapasitesinde port ayırdınız.(2 si teaming ile primary network switch’e gidiyor. Diğer ikiside teaming ile yedek network switch’e gidiyor.) Bu ethernet kartı için Do not allow cluster network communication on this network’ü seçebilirsiniz. Ama teaming ile verilen IP’yi always on endpoint’lerine göstermelisiniz.

Bu işlem için endpoint’i aşağıdaki script yardımıyla oluştururken LISTENER_IP = ALL kısmındaki ALL yerine teaming ile verilen IP’yi yazmanız gerekiyor. IP’yi yazarken parantez içinde yazmanız gerekiyor. Örnek-> (10.6.132.45)

USE [master]
GO
CREATE ENDPOINT [Hadr_endpoint] 
	STATE=STARTED
	AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
	FOR DATA_MIRRORING (ROLE = ALL, AUTHENTICATION = WINDOWS NEGOTIATE
, ENCRYPTION = REQUIRED ALGORITHM AES)
GO

Eğer endpoint’inizi daha önce oluşturduysanız SSMS üzerinden aşağıdaki gibi endpoint’inizin create script’ini alarak Create ifadesi yerine ALTER yazarak ve ALL kısmına yukarda anlattığım şekilde IP girerek bu işlemi gerçekleştirebilirsiniz.

Eğer endpoint’inizin IP’sini drop create yöntemi ile değiştirirseniz bu işlemi yaptıktan sonra secondary veritabanınız not synchronizing mode’a düşecektir. Tekrar senkronize duruma geçmesi için secondary veritabanınızı aşağıdaki gibi önce suspend mode’a alıp,

Daha sonra da aşağıdaki gibi resume data movement demelisiniz,

Bu işlemleri always on’un primary ve secondary replikalarında yapmalısınız. Her sunucuda always on için tanımladığınız ethernet kartının IP’si neyse o sunucuda çalışacak endpoint için o IP’yi vermelisiniz.

Örneğin;

Primary olacak Test1 sunucunuzda always on için tanımlanan ethernet kartının teaming IP’si(teaming yapmadıysanız IP’si) 10.6.123.41       Bu sunucudaki primary instance’ın endpoint’ini yukarda anlattığım şekilde alter ederken ALL kısmına (10.6.123.41) yazmalısınız.

Secondary olacak Test2 sunucunuzda always on için tanımlanan ethernet kartının teaming IP’si(teaming yapmadıysanız IP’si) 10.6.123.42       Bu sunucudaki secondary instance’ın endpoint’ini yukarda anlattığım şekilde alter ederken ALL kısmına (10.6.123.42) yazmalısınız.

Bu makalede Ethernet Altyapısından bahsettim. “SQL Server Sunucuların Kullandığı SAN Altyapısı” makalemde de SQL Server Sunucuların storage’lar ile arasındaki SAN altyapısından bahsedeceğim.