Raporlama Sunucusu Eklemenin Maliyeti

“Raporlama sorgularımızı ayrı bir SQL Server’a aktarmak istiyoruz.”

İlk maliyetler oldukça açıktır.

Donanım ve depolama – sanal bir makinede çalıştırıyor olsanız bile, örneğin 4 çekirdek ve 32 GB RAM maliyetlerini hesaba katmanız gerekir. Yalnızca veritabanları için depolama alanına ihtiyacınız olmayacak, aynı zamanda bu sunucunun yedeklenip yedeklenmeyeceğine ve bir felaket kurtarma veri merkezine kopyalanıp kopyalanmayacağına da karar vermeniz gerekecek.

Yazılım lisanslama – Standard Edition çekirdek başına ~2 bin dolar, Enterprise Edition ise çekirdek başına ~7 bin dolar. Windows’u (özellikle artık çekirdek başına lisanslandığı için), yönetim/yedekleme/antivirüs araçlarınızı ve izleme yazılımınızı da ekleyin.

Proje planlama – Always On Availability Groups, log shipping ya da transactional replication gibi yöntemlerle verileri üretimden raporlama sunucusuna nasıl aktaracağınızı tasarlamanız gerekecektir.

Uygulama değişiklikleri – raporlama sorgularını çalıştıran uygulamanın yeni bir connection string’e ihtiyacı olacaktır.  SQL Server’dan yalnızca okuma yapacağınız durumda aşağıda belirtilen kodu connection string parametresinde kullanmanız gerekir. Hem okuma hem de yazma yapan tek bir uygulamanız varsa ve yalnızca bazı sorguları devre dışı bırakmak istiyorsanız, bu sorguları yeni connection string’e geçirmek için kodu gözden geçirmeniz gerekecektir.

ApplicationIntent = ReadOnly

Bir sorun giderme süreci eklemek – er ya da geç veri replikasyon süreci bozulacaktır. Yönteme (AGs, log shipping, replication) ve hata türüne bağlı olarak, farklı şekillerde başarısız olacaktır – belki tüm veriler eskidir, belki sadece bir kısmı eskidir veya belki raporlara hiç erişilemez. Arıza yöntemlerini listelemek ve belirtilerin neye benzeyeceğini açıklamak isteyeceksiniz. Bu, iş kullanıcılarının raporlarının ne zaman yanlış olduğunu anlamalarına ve uygun şekilde tepki vermelerine yardımcı olur. Bu adımı atmazsanız, ilk başarısızlıktan sonra insanlar her zaman rapor verilerinde bir hata olduğunu düşüneceklerdir.

Başarısızlığa hazırlanın – bu başarısızlık yöntemlerinin her biri için nasıl tepki vereceğinize karar verin. Örneğin, AG replikasyonu bozulursa ve raporlar güncelliğini yitirirse, sorun çözülene kadar raporları primary sisteme mi yönlendireceksiniz yoksa siz sorun giderirken veya replikaları yeniden senkronize ederken kullanıcılar kullanılamayan raporlarla mı uğraşmak zorunda kalacak? Bu adımı atmazsanız, her seferinde boşa kürek çekmiş olursunuz ve raporlar hatalı veya çalışmaz durumdayken hazırlıksız görünürsünüz.

RPO ve RTO için gerçekçi beklentiler belirleyin – sürecinize ve hazırlığınıza bağlı olarak, iş kullanıcılarının işler bozulduğunda raporlarının ne kadar süre kapalı kalacağını anladıklarından emin olun.

Replikasyonun ek yükünü ölçün – AG’ler ve transactional replication, eskiden raporların maliyetinin ötesinde performans yavaşlamaları ekleyebilir. Örneğin, saatte yalnızca birkaç rapor çalıştırıyorsanız ve yalnızca verilerin bir alt kümesine ulaşıyorsanız, aniden her bir silme/güncelleme/ekleme işlemini çoğaltmak büyük bir ek yük getirebilir.

Monitoring ekleyin – raporlama sunucusunun ne kadar geride olduğunu ve her ikisinde de performansın nasıl gittiğini izlemeye başlamanız gerekir. Performans sorunlarını gidermek de çok daha zor hale gelir – örneğin, dizin ayarlaması yaparken, doğru dizin karışımını bulmak için hem birincil hem de raporlama sunucularındaki verileri birleştirmeniz gerekir.

Raporlamayı gerçekten yapmanız gerektiğinden emin misiniz?

Bu pahalı projeye başlamadan önce şunu sorun:

– Karşılaştığımız primary wait type nedir?

– Bu wait type’ı azaltmanın en ucuz/kolay yolu nedir?

Zaman zaman PAGEIOLATCH beklemeleriyle (bir veri dosyasından veri sayfalarını okumak için beklemek anlamına gelir) karşılaşan insanlar görüyorum ve 16-32GB RAM ile 1TB’lık bir veritabanıyla uğraşıyorlar. Bu sorunu çözmek için on binlerce dolar harcamayın – 1.000 dolarlık RAM satın alın ve dizin ayarlaması yapmak için biraz zaman harcayın.

Sql serverın kaynak kullanımının göz önünde bulundurularak aynı makine üzerine birden çok kurulumun yapılmamasını öneriyoruz. Ancak iş ihtiyaçlarınıza göre bu duruma karar verebilirsiniz.

Instance stacking tekniği, aynı Windows üzerinde birden fazla SQL Server Instance yükleme tekniğidir. Örneğin, SQLPROD1 adında bir sanal makineniz veya sunucunuz olabilir:

• SQLPROD1 – SQL Server’ın varsayılan Instace, örneğin SQL 2016
• SQLPROD1\SQL2014 – eski uygulamalarımız için
• SQLPROD1\SharePoint – çünkü kendi Instance’nın üzerinde olması gerekiyor
• SQLPROD1\development – QA ve testlerimiz için

Instance Stacking Tekniğinin Faydaları

Daha düşük SQL lisanslama maliyetleri – yalnızca bir lisans için ödeme yapmanız gerekir ve Standard Edition bile aynı Windows tabanına düzinelerce Instance yüklemenize izin verir.

Daha düşük Windows lisanslama maliyetleri – yalnızca bir Windows için ödeme yapmanız gerekir.

Daha kolay Windows Patch – yalnızca bir işletim sistemi yüklemeniz gerektiğinden.

Instance Stacking Tekniğinin Dezavantajları

Performans ayarlaması çok daha zordur – tüm Instance’lar aynı CPU, memory, network ve depolama alanını paylaşır. SQL Server ilk ikisini hafifletmek için affinity masking ve bellek ayarları gibi hileler sunsa da, ikinci ikisi için hiçbir cevabı yoktur. Bir Instance üzerindeki backup, ne kadar ayarlama çalışması yaparsanız yapın diğer Instance’ların performansını düşürecektir. Instance’lardan hiçbiri performansa duyarlı değilse, bu önemli değildir – ancak bu ne sıklıkla olur? Ve “doğru” bellek veya CPU ayarlarının ne olduğunu nasıl anlarsınız? O kadar çok insan çalışması ve deneme gerektirir ki, ancak sunucu başına DBA başına bolca boş zamanınız olduğunda gerçekten mantıklıdır.

Çok daha zor reboot planlaması – tüm Instance’ların tüm müşterilerin Windows’u patch geçmek için belirli bir zaman üzerinde anlaşmasını sağlamanız gerekir.

Güvenlik zorlukları – bazen, veritabanlarını barındıran Windows Instance’ına RDP ile girebilmekte ısrar eden korkunç insanlar oluyor. Bu kişiler kutunun tamamında sistem yöneticisi olmakta ısrar ederlerse, çalışan diğer Instance’larına zarar veren değişiklikler yapabilirler.

Alternatif: Sanallaştırma

Tek bir sunucuyu daha küçük parçalara ayırmayı düşündüğünüzde, bunun yerine sanallaştırmayı düşünün. Yeni SQL Sunucuları için harika bir varsayılan yerdir.

Her SQL Server kendi Windows örneğini hak eder. Evet, bu daha yüksek lisans maliyetleri anlamına gelir – SQL Server Enterprise Edition’ı donanım ana bilgisayarı düzeyinde lisanslamanız gerekir ve ardından ana bilgisayara mümkün olduğunca çok sayıda sanal makine yerleştirebilirsiniz.

Ardından, her sanal makine kendi performans yönetimine, yama programlarına ve güvenliğine sahip olur. Artı, sürpriz bonus: her sanal makine, en küçükleri bile Enterprise Edition’ın tüm özelliklerine sahip olur.