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.
