AWS SQL Server AlwaysOn Availability Group

Merhaba,

AlwaysOn Availability Group(yazının devamında AAG olarak kısaltılmıştır); SQL Server 2012 ile gelen ve SQL Server 2014 ile geliştirilen, Server Instance Level HA sağlayan veritabanı yüksek erişilebilirlik seçeneklerinden biridir. AAG yapısının ana bileşenleri; SQL Server Node’ları(primary ve secodary replica) ve Listerner(DNS alias) ‘dır. Her replika ayrı bir sanal sunucuda barınır ve otomatik failover yapabilecek şekilde yapılandırılır. Client side uygulama(lar) ise connection string içinde “listener” olarak yapılandırılan DNS alias’ını kullanarak o an için geçerli olan replika’ya bağlanır(lar).

MS SQL Server’da AAG seçeneğini geleneksel veri merkezinizdeki sanallaştırma katmanı üzerinde çalışan SQL Server’larınızdaki Instance’larda yapılandırabileceğiniz gibi AWS,Azure gibi bulut servis sağlayıcıları üzerinde de yapılandırabilirsiniz. Lisanslama ve işletme maliyetini değerlendirerek geleneksel veri merkezinde çalıştırmayı veya bulut servisini kullanmayı tercih edebilirsiniz. Bulut servislerini kullanmak isterseniz pay as you go yerine commitment&upfront ile ilerlemek maliyet açısında avantajlı olabilir!

AWS’de çalıştırdığınız MS SQL AAG instance’ınız için Azure replica’larını oluşturmak; maliyet, single “Cloud” of failure ve vendor management açısında farklı bir yaklaşım olabilir ve test edilebilir 🙂 Tabii ki bu tür servisleri devreye almak için diğer çevresel servislerden faydalanmanız gerekecektir!

Yazımda, Amazon Web Service üzerinde MS SQL Server AAG konfigürasyonundan bahsedeceğim. Azure üzerinde de benzer işlemler için kaynaklar kısmında çeşitli adresler paylaştım. Konu hakkında daha fazla detay incelemek isterseniz kaynak kısmında paylaştığım diğer adresleri inceleyebilirsiniz.

AWS bulutunda demo ortamımdaki yapılandırmanın topolojisi aşağıdaki şekildedir.

clip_image001

Topolojide:

İki farklı availablity zone(AZ)’da çalışıyoruz. Public ve Private subnet’leri yapılandırıyoruz. Public subnet’lerde, dışarıdan AWS VPC’ye güvenli erişim için NAT ve Remote Destop Gateway instance’larını yapılandırıyoruz. Private subnet’lerde yüksek erişilebilirlikli şekilde Active Directory Domain servislerini yapılandırıyoruz. Windows Server Failover(WSFC) servisinin çalıştığı SQL server node’ları üzerinde AAG ‘ı devreye alıyoruz. VPC’den çıkış NAT instance’ı arkasından sağlanmaktadır. VPC’ye yönetimsel erişim ise RDGW ile sağlanmaktadır.

Demo ortamım AWS Oregon bölgesindedir. CloudFormation servisinin sunduğu şablon ile aşağıdaki adımları otomatize şekilde yapılandıracağım.

  • Oregon bölgesinde 10.0.0.0/16 subnet’ini kullanan bir VPC oluşturulması
  • VPC içine farklı avalability zone’larda çalışan Active Directory Domain servislerinin oluşturulması
  • SQL Server AAG replika node’ları için Windows Server Failover Cluster(WSFC) konfigürasyonu
  • Güvenli erişim için NAT ve Remote Desktop Gateway instance’larını yapılandırılması
  • AAG ‘ın devreye alınması
  • Database oluşturulması ve AAG konfigürasyonu(bu adım manual olarak işletilecek)

Tüm adımları manual gerçekleştirmek isterseniz aşağıdaki sırayı takip edebilirsiniz.

  • AD Domain servisleri için iki farklı AZ içinde iki farklı subnet’lerin oluşturulması
  • Public ve Private subnet’lere ait route’ların yapılandırılması
  • Windows Server 2012 AMI ile iki adet sanal instance oluşturulması ve Active Directory Domain servisinin yapılandırılması
  • Domain controller(lar) ve üye sunucular arasındaki erişim için EC2 security group’larının yapılandırılması
  • VPC’ye yönetimsel anlamda güvenli erişim için NAT ve Remote Desktop Gateway instance’larının yapılandırılması
  • WSFC node’ları arasında SQL Server AAG için gerekecek erişimlerin EC2 security group’ları ile yapılandırılması
  • WSFC ‘ın kurulumu
  • AAG ‘ın devreye alınması
  • Database oluşturulması
  • AAG’ın oluşturulması

Daha önce de belirttiğim gibi son iki adım dışındaki işlemleri CloudFormation’ın sunduğu şablon ile otomatize şekilde tamamlayacağım. Şablonun adresi https://s3.amazonaws.com/quickstart-reference/microsoft/sql/latest/templates/SQL_AlwaysOn_Master.template ‘dir. Şablon ile yapılandırılacak parametreler aşağıdaki gibidir.

clip_image003

clip_image005

clip_image007

Üstte belirtilen ön tanımlı parametreleri kişiselleştirebilirsiniz. Üstteki parametlerden domain fqdn’ini ve Domain Netbios ismini barisaws.local/barisaws şeklinde değiştirdim. Kullandığım şablon, işlemi yaklaşık üç saatte tamamlıyor. Stack’ler işlemi aşağıdaki şekilde başlatıyor.

clip_image009

İşlemin tamamlandığını aşağıdaki şekilde gözleyebilirsiniz.Üçüncü stack ~1.5 saat sonra başlamaktadır.

clip_image011

CloudFormation şablonu ile oluşturulan \\dc1\replica isimli network share’ini, AAG sync işlemi için kullanacağım.Şablonun otomatize şekilde tamamlamadığı adımları tamamlayarak yapılandırmayı sonuçlandıralım ve bir kaç test yapalım. MS SQL Server Administration’a dair temel bilgilerin bilinmesi, aşağıdaki adımları anlamayı kolaylaştıracaktır. Ben, SQL Server Instance’ları için çalışan AAG’ı, Exchange Server Database’leri için çalışan DAG’a benzetiyorum 🙂

SQL Server AAG node’larına logon olup bir database oluşturalım, database için AAG’ı yapılandıralım. Node’lardan biri üzerinde bu işlemi yapabiliriz. WSFCNode1 üzerinden devam edeceğim. Node’a barisaws\stackadmin ile giriş yaptım, sql server management studio ile devam ediyorum.

clip_image012

BarisDB isminde bir database oluşturacağım.

clip_image013

Recovery model’ini aşağıdaki şekilde yapılandırınız.

clip_image014

Database’i oluşturdum. Bu arada sql server node’larındaki disk layout aşağıdaki gibidir. Beş adet High IOPS SSD kullandım. Daha yüksek IOPS için AWS’in sunduğu Provisioned IOPS seçeneklerine göz atabilirsiniz.

clip_image016

Database’in yedeğini alınız. Ardından AAG yapılandırma adımına geçiniz.

clip_image017

clip_image019

Sihirbazı, Prod ortamınız için gereken yapılandırma ayarları ile devam ettirebilirsiniz.Demo ortamımda aşağıdaki değerler ile sihirbazı tamamlayacağım.

clip_image020

AAG ismi üstteki şekildedir.

clip_image022

Demo ortamımda olduğum için database boyutunu göz ardı ediyorum 🙂

clip_image024

Üstte görüldüğü üzere Add Replica… butonu ile ikinci node’u ekledim. Add Azure Replica… butonu dikkatinizi çekecektir!

Listerner tab’ına geçiniz ve yapılandırınız. Demo ortamımdaki listener yapılandırmam aşağıdaki gibidir.

clip_image025

clip_image026

Devam ediyorum.

Not: Prod ortamınızda listener ismi,port numarası, ip adresi seçenekleri farklılaşacaktır.

clip_image027

Daha önce belirttiğim üzere DC1 üzerideki paylaşımı kullanıyorum.

clip_image029

Validation ‘da problem görünmüyor. Devam ederek sihirbazı tamamlıyorum.

clip_image031

Sihirbaz yapılandırmayı tamamladı.

clip_image032

AAG oluşturuldu.

clip_image034

clip_image036

TTL değerini düşürebilirsiniz! Listener’ın DNS kayıtlarını da kontrol ediniz!

clip_image038

Listener’ı kullanarak bağlanmayı test edebilirsiniz.

clip_image039

Node’ler üzerinde birden fazla SQL instance’ları kuracaksanız, port konfigürasyonuna dikkat etmeniz gerekecektir. Şimdi de HA testi yapabiliriz. Mevcut durum aşağıdaki gibiydi.

clip_image040

clip_image042

Sync State’e dikkat ediniz. Sync’ed durumdadır. Aktif replica’yı çalıştıran sanal sunucuyu(instance’ı) AWS management console’dan shutdown edeceğim.

clip_image044

SQL AAG’ın dashboard’undaki değişim aşağıdaki gibidir.

clip_image046

Kapattığım node’u AWS management console’dan tekrar power-on duruma getireceğim.

clip_image048

Primary replica’yı çalıştıran sunucu değişmiş olmakla birlikte sync işlemi tekrar sağlandı! SQL Server AAG servisi konusunda ihtiyaçlarınıza en uygun yapılandırmayı(ek node’lar eklemek, readable 2ndary replica yapılandırmak vs.) elde etmek için SQL Server dokumantasyonu incelemeniz ve/veya üstte takip ettiğimiz adımları değiştirmeniz gerekecektir.

Özet:

Multi-AZ ve automatic failover’a sahip SQL AAG yapısını AWS ‘nin sunduğu servisler ile incelemiş olduk. AWS bulutunda yapılandırdığınız SQL Server AAG Instance’ına şirket ağınızdan erişebilmeniz için farklı servislerden faydalanarak AWS VPC’niz ile şirket ağınızı bağlamanız gerekecektir. Bu konuda farklı senaryolar mevcut olup işletme maliyeti ve yapınıza uygunluk açısından dizayn edilmesi gerekir!

Önemli detaylar:

Demo ortamını hazırlamak için CloudFormation şablonu ile gelen instance type’larını kullanırsanız tüm stack’lerin saatlik maliyeti ~$5.5 ‘dır. Demo ortamının hazırlanması ~3 saat sürmektedir. CloudFormation şablonunu prod ortamına kurulum için de kullanabilirsiniz. CloudFormation, deployment sırasında 34 adet değiştirilebilir parametre sunmaktadır. Hazırladığınız ortamı test amaçlı deploy ettiyseniz, testiniz bitikten sonra aşağıdaki görüldüğü gibi siliniz 🙂

clip_image050

Aksi durumda aylık faturanıza ek olarak, sadece bu ortam için $3600 yansıyacaktır!

Bulut servislerini kullanmak isterseniz, farklı alanlarda konusunda uzman kişilerden oluşan bir ekibiniz olması gerektiğini unutmayınız!

Herkese sorunsuz ve neşeli günler dilerim.

Kaynaklar:

https://msdn.microsoft.com/en-us/library/dn463980.aspx

http://aws.amazon.com/microsoft/

http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/

http://aws.amazon.com/net

http://aws.amazon.com/windows/mslicensemobility

https://s3.amazonaws.com/quickstart-reference/microsoft/activedirectory/latest/doc/Microsoft_Active_Directory_Quick_Start.pdf

https://s3.amazonaws.com/quickstart-reference/microsoft/sharepoint/latest/doc/Microsoft_SharePoint_2013_on_AWS.pdf

http://media.amazonwebservices.com/AWS_SharePoint_Reference_Implementation_Guide.pdf

http://awsmedia.s3.amazonaws.com/SharePoint_on_AWS_Reference_Architecture_White_Paper.pdf

http://media.amazonwebservices.com/AWS_Microsoft_Platform_Security.pdf

https://s3.amazonaws.com/quickstart-reference/microsoft/sql/latest/doc/Microsoft_WSFC_and_SQL_AlwaysOn_Quick_Start.pdf

http://blogs.technet.com/b/dataplatforminsider/archive/2014/08/25/sql-server-alwayson-offering-in-microsoft-azure-portal-gallery.aspx

http://blogs.technet.com/b/dataplatforminsider/archive/2014/08/25/sql-server-alwayson-offering-in-microsoft-azure-portal-gallery.aspx

https://msdn.microsoft.com/en-us/library/hh213080.aspx

https://msdn.microsoft.com/en-us/library/ms190202.aspx

Leave a Reply

Your email address will not be published. Required fields are marked *