Azure SQL Managed Instance nedir? Ne işe yarar?
Kurumsal uygulamaların belki de en kritik bileşenlerinden biri olan veri tabanı için bir yapılandırma dizayn ederken saatlerce mesai harcamak gerekebilir. Bu dizayn tercihleri arasında lokasyon ve veri tabanı motoru da büyük önem teşkil ediyor. Şayet veri tabanlarınızı public cloud arenasında barındırmak isterseniz Microsoft, Amazon ve Google gibi devlerin sunduğu birçok opsiyon var ve hangisini tercih etmeniz gerektiği konusu da yine başlı başına karar süreci gerektiriyor.
Duruma genel olarak baktığımızda buluttaki üç ana servis modeliden ikisi olan IaaS ve PaaS’ı ele almamız lazım. Veri tabanınızı buluttaki bir sanal makine üzerine kuracağınız veri tabanı motoru şeklinde mi yönetmek istiyorsunuz yoksa yönetim yükünden kurtulup sadece işinize mi odaklanmak istiyorsunuz? Tahmin edeceğiniz üzere ikinci opsiyon PaaS model fakat her uygulama, veri tabanı ve üzerinde çalıştığı instace’ın kontrolünün sizde olmadığı bu modeli desteklemeyebilir. Microsoft örneği üzerinden gidip Azure SQL Database’i ele alırsak Microsoft, bu PaaS veri tabanı hizmetini “cloud born” (bulutta doğmuş) uygulamalar için tavsiye ediyor. Dünya üzerindeki kurumlarının birçoğunun kendine has, terzi usulü uygulamalar kullandığını göz önünde bulundurursak bulutta doğmuş tabiri bu ihtiyacı karşılamıyor. Tabi bu, hiçbir kurum içi uygulamanın Azure SQL ile çalışmayacağı anlamına gelmiyor; instance seviyesinde özelliklere erişim ihtyacı olmayan, her işleminde “sa yetkisi” istemeyen, kafasına göre yeni veri tabanı veya kullanıcı oluşturmayan her uygulamanın veri tabanı elbette Azure SQL’de barındırılabilir. Lakin bu şartları sağlamayan bir uygulamanız olduğunda tek çözümünüz sanal makinede SQL Server yönetmek olmamalı. İşte Azure SQL Managed Instance (kısaca Azure SQL MI) buradaki ihtiyacı karşılıyor.
İlk başlarda Microsoft, Azure SQL’in ilişkisel veri tabanının geleceği olduğu konusunda çok ısrarcıydı fakat özellikle en dişli rakibi Amazon, servis modelleri konusunda esnekliği maksimum seviyeye çıkardığı ve benzer bir hizmeti yıllardır sunduğu için mecburen cevap vermek durumunda kaldı. Rekabetin ürünü olarak da Azure SQL MI ortaya çıktı. Temelde PaaS bir hizmet, fakat Azure SQL’de sunulmayan instance seviyesinde kontrol bu hizmette sunuluyor. Artık master, model gibi sistem veri tabanlarının kontrolü ve sa yetkisi sizde. Veri tabanının altında çalışan işletim sistemi, network, güncelleştirmeler ve bunların güvenliği yine Microsoft’un sorumluluğunda. Daha fazla kontrol ama yine daha az sorumluluk; mükemmel birleşim diyebiliriz.
Microsoft’un tabiriyle Azure SQL MI, standart SQL Server’ın uyumlu olduğu uygulamaların neredeyse %100'üyle uyumlu olan, Azure’daki VNet’inize entegre olabilen, isterseniz public endpoint de ekleyebileceğiniz, PaaS altyapı üzerinde çalışan bir hizmet. Resmi Microsoft dokümantasyonuna göre Azure SQL MI’nin buluttaki konumunu ve izolasyonunu şu şekil ile açıklamak mümkün:
Resmi kısaca özetlersek Azure SQL MI, VNet entegrasyonu sayesinde her türlü kaynaktan kolayca erişilebiliyor; buradaki tek kıstas kaynağınız ile MI arasındaki network gecikme süresi. Coğrafi olarak kabul edilebilir uzaklıkta olduğu takdirde uygulamanız lokal sistem odasında da bulunabilir. Aynı Azure üyeliği içerisindeki diğer kaynaklardan erişim süresi seçeceğiniz altyapı tipine göre 5–10 ms ve 1–2 ms arasında değişiyor.
Azure SQL MI, bir PaaS çözümden beklenecek şekilde instance auditing, data encryption in motion, threat detection, dynamic data masking ve transparent data encryption gibi birçok güvenlik özelliğini de destekliyor.
Yüksek erişilebilirlik tarafında Microsoft’un tabiriyle AlwaysOn’a benzer bir yöntem kullanılıyor; coğrafi yedeklilik opsiyonu ayriyeten mevcut.
Kimlik doğrulamaya geldiğimizde SQL Auhentication ve Azure Active Directory Authentication destekleniyor. Arkada çalışan sunucu/işletim sistemi altyapısı sizin lokal etki alanınıza katılmış bir makine olmadığı için Active Directory kimlik doğrulama desteği beklemek doğru olmaz, fakat lokal AD’nizi ADConnect aracıyla Azure AD ile federe ettiyseniz lokal AD objelerinizi de kullanabilirsiniz.
Donanım altyapısı tarafında size Gen4 ve Gen5 olarak iki opsiyon sunuluyor. Bu makalenin yazıldığı tarih itibariyle Gen4 konfigürasyon Intel E5–2673 v3 ve SSD; Gen5 konfigürasyon ise Intel E5–2673 v4 ve NVMe SSD sunuyor. Seçtiğiniz sanal çekirdek adedine göre Gen4'te çekirdek başına 7 GB RAM, Gen5'te ise 5.1 GB RAM sunuluyor. Donanım konfigürasyonlarının diğer detaylarını en ince ayrıntısına kadar buradan ulaşabilirsiniz.
Azure hesabımız üzerinde örnek bir Azure SQL MI kurulumu yaparak ilerleyelim:
MI kurulumundan önce Azure portalda ilk yapacağımız iş mevcut VNet’imiz içerisinde sadece MI’ye atanmış bir subnet oluşturmak olacak. Bunu yaptıktan sonra “Create a resource” butonu üzerinden “Azure SQL Managed Instance” yazarak ilgili servisi bulalım ve oluşturma sürecine başlayalım.
Gördüğünüz üzere Instance ismi, yetkili admin kullanıcı bilgileri, zaman dilimi ve collation bilgilerini girmeniz isteniyor. Burada belirleyeceğiniz server collation, MI oluşturulduktan sonra değiştirilemiyor. Connection type tarafında “Redirect”in seçili olmasına ve “Allow access from Azure services”in seçili olmasına dikkat edelim. Public endpoint’i aktif hale getirip intance’ı internete açabiliriz fakat test/lab senaryoları dışında bunu açmanızı tavsiye etmiyorum. Coğrafi yedekliliği Failover Group oluşturarak yapabiliriz ama şimdilik es geçiyoruz.
MI oluşturma süreci iki buçuk ila üç saat arasında sürüyor. İşlem bittikten sonra panelde şu şekilde yerini alacak:
Artık bir sanal makineye SSMS kurup Azure SQL MI’ye bağlanabiliriz. Bağlanmak için “Host” kısmındaki ismi ve yetkili kullanıcı hesabını girmeniz yeterli:
Vaat edildiği gibi instance’ın yönetimi sizde. Azure SQL’den farklı olarak sistem veri tabanlarını (master, model vb.) ve SQL Server Agent’ı görebiliyoruz. İşletim sistemi olarak Windows Server 2016'nın kullanıldığını, SQL’in kendisi ise “SQL Server Azure” olarak tanımladığını görüyoruz. Microsoft’a göre MI, her daim en güncel SQL Server motorunu kullanacak, yani bu durumda arka tarafta SQL Server 2017'nin çalıştığını söyleyebiliriz; tabi Azure SQL MI için özelleştirilmiş bir sürüm.
Active Directory admin menüsünden Azure AD’mizdeki objelerden (ADConnect senkronize edilmiş objeler dahil) birine admin yetkisi verebiliyoruz:
Instance Failover menüsünde olası bir Azure veri merkezi kesintisinden etkilenmemek için başka bir veri merkezinde oluşturduğunuz MI ile failover group oluşturabiliyorsunuz.
Güvenlik kısmında Advanced Data Security’yi etkinleştirelim ve bir storage account’a bağlayalım. Zaafiyet değerlendirme rapolarının mail adresimize gönderilmesi için mail adresimizi yazalım. Advanced Threat Protection’da da haberdar edilmeyi istediğimiz zararlı tiplerini seçip ayarlarımızı “Save” ile kaydedelim.
Veri şifreleme için TDE (Transparent Data Encryption) kullanmak istersek burada Microsoft, kendi şifreleme anahtarımızı kullanma imkanı sunuyor:
MI’deki bütün veri tabanlarınız PaaS özellikler gereği 35 güne kadar sürekli olarak yedekleniyor ve bu 35 gün içerisinde istediğiniz andaki bir yedeğe geri dönebiliyorsunuz. Olur da SSMS ile bir yedeği dışarı aktarmak isterseniz SSMS üzerinden storage account’a yedek alma seçeneği sunuluyor:
MI’nin bulunduğu resource group’a göz atarsak Virtual Cluster, Route Table ve NSG (Network Security Gorup) oluşturulduğunu görebiliriz. NSG’ye göz attığımızda MI’nin Azure’daki sanal makineleriniz ve diğer Azure hizmetleriyle iletişimi için gerekli portların otomatikman açıldığını görebilirsiniz:
Microsoft, Azure SQL MI’nin, standart SQL Server ile neredeyse aynı uyumluluğu sunduğunu söylüyor. Bu iddiayı test etmek için standart Azure SQL desteği sunmayan Atlassian Jira Core uygulaması MI ile beraber kuralım. Jira, güncel sürümünde SQL Server 2017 desteği veriyor ve bu bizim için yeterli. Aşağıdaki linkten Jira Core’un deneme sürümünü indirelim:
Burada amacımız Jira’nın kurulumunu anlatmak olmadığı için kurulum detaylarına girmiyorum. Azure’da Windows Server 2019 tabanlı bir VM açıp Jira’yı kuralım ve kurulduktan sonra web konfigürasyon arayüzü üzerinden “I’ll set it up myself” opsiyonunu seçelim:
Bir sonraki aşamada veri tabanı bilgilerinizi girmeniz istenir. Burada duraklayalım, zira Jira için Azure SQL MI’de bazır objeler oluşturmamız gerek. SSMS kullanarak MI üzerinde Jira için “jiradb” isminde boş bir veri tabanı açalım ve “jirauser” isimli bir SQL kullanıcısı oluşturarak “jiradb” veri tabanında “db_owner” yetkisi verelim. Tekrar Jira konfigürasyonuna dönelim ve “hostname” kısmına MI host ismini, “database” kısmına veri tabanı ismini ve yetkili kullanıcı bilgilerini yazdıktan sonra “Test Connection” butonuna basalım.
Görmek istediğimiz sonuç buydu. Jira arka tarafta MI’nin çalışıp çalışmadığından haberdar olmaksızın kurulumu bitiriyor ve kullanıma hazır hale geliyor.
Böylece Azure SQL Server MI’yi yapılandırarak örnek bir uygulamayı bu veri tabanı motoruna bağlamış olduk. Aklınıza Azure SQL desteklemeyen bütün Microsoft uygulamalarını Azure SQL MI’ye bağlamak gelebilir lakin acele etmeyin: Microsoft uygulamalarının çoğu sadece Windows Authentication kullandığı için MI ile çalışmayacaktır. Yakın zamanda SharePoint 2016/2019 ve Dynamics 365 Business Central’in desteklenen MS uygulamaları arasına girdi. Şu an için SQL Authentication destekleyen uygulamaları MI ile bağlayabiliriz demek doğru olur ki üçüncü parti uygulamaların genelinde hem Windows hem de SQL auhtentication sunuluyor.
Bir sonraki makalede görüşmek üzere.
