Azure'un Kilidini Açma: Son Derece Esnek Bir SQL Veritabanı Altyapısı Nasıl Oluşturulur

Son yıllarda Hizmet Olarak Altyapı ve Hizmet Olarak Platformun, başta kaynak verimliliği ve esneklik olmak üzere yetenekleri nedeniyle çeşitli projelerde giderek yaygınlaştığı bir sır değil. Sonuç olarak Microsoft, SQL'in kullanılabileceği kullanıcı dostu bir ortam oluşturmak için çok fazla zaman ve çaba harcadı.

Social Discovery Group ekibi, ürünlerimizi desteklemek için SQL dahil çeşitli veritabanlarını kullanıyor. Dünya çapında buluşmaya ve bağlantı kurmaya yardımcı olan 40'tan fazla küresel hizmet portföyümüzle kullanıcı tabanımız dünya çapında 250 milyondan fazla insanı içermektedir. Kullanıcılara ürünlerimizin güvenilirliğini garanti etmek için temel altyapının bir kısmını bulutta tutuyoruz. Bu, dayanıklılığını, güvenliğini ve esnekliğini artırmaya yardımcı olur.

Sunucu ve hizmet veritabanlarını Kubernetes kümeleri de dahil olmak üzere çeşitli platformlara dağıtma konusunda oldukça deneyimliyiz. Ancak ilgili SQL veritabanları altyapısının bir kısmını Azure bulutunda mümkün olduğunca esnek, verimli ve güvenilir hale getirme ihtiyacıyla karşılaştık. Microsoft Azure bulutunda SQL kullanmanın 3 yolu vardır:

• Azure SQL Veritabanı
• Azure SQL Yönetilen Örneği
• Azure Sanal Makinelerinde SQL Server

Araştırmanın ardından Azure SQL veritabanlarını kullanmaya karar verdik. Azure SQL veritabanlarını hiç duymamış olanlar için açıklığa kavuşturmak gerekirse, bunlar Microsoft Azure'un bir parçası olarak sağlanan yönetilen bulut veritabanlarıdır.

Aşağıdaki faydaları vurguladım:

• Güncellemeler veya kullanım ömrü sonu desteği konusunda endişelenmenize gerek yok;
• Kolay yapılandırma ve dağıtım;
• Dağıtım hızı (ve dolayısıyla geliştirme) ve ölçeklenebilirlik;
• Yüksek kullanılabilirlik;
• Hata toleransı;
• Yedekleme kolaylığı;
• Maliyet optimizasyonu;
• Entegre bir Microsoft Azure izleme sistemi.

Şimdi adım adım olaylardan bahsedelim ve veritabanı dağıtma ve oluşturma sürecine bir göz atalım. Bu, bir Power Shell betiği veya Azure CLI kullanılarak yapılabilir, ancak netlik sağlamak adına, sürece portalın grafik arayüzünü kullanarak bakıyorum. Bunu yapmak için Azure SQL'e gidin, 'Oluştur'a tıklayın ve 'SQL Veritabanları'nı seçin.

Kaynak grubunu belirliyoruz, mevcut bir sunucunun olup olmadığını seçiyoruz veya yeni bir sunucu oluşturup oluşturmadığımızı (yöneticinin adını ve verilerini belirterek) ve veritabanı için bir ad buluyoruz. Ortak iş yüklerimiz için dengeli bir bilgi işlem ve depolama kaynakları karışımına sahip DTU (veritabanı işlem birimi) tabanlı paket paketleri seçmenizi öneririm.

Ayarlar için bazı sekmeler de vardır: Ağ, Güvenlik, Ek ayarlar ve Etiketler; minimum standart konfigürasyon için bunlar varsayılan olarak değiştirilmeden bırakılabilir. Daha sonra veritabanının oluşturulmasını bekliyoruz. Bu minimum kurulumu tamamlar ve temel tamamlanır.

Veritabanı kaynaklarının boyutu, kelimenin tam anlamıyla tek bir tıklamayla süper kolay bir şekilde değiştirilebilir ve kaynakların yetersiz olması durumunda, boyut ve performans açısından ihtiyacımız olan parametreleri ayarlayabiliriz.

Daha sonra IP adresinizi veya alt ağınızı eklemeyi veya bu veritabanının barındırıldığı sunucunun güvenlik duvarındaki tüm bağlantılara izin vermeyi unutmadan veritabanınıza dışarıdan tercih ettiğiniz şekilde bağlanabilirsiniz.

SQL Server Management Studio (SSMS) aracılığıyla bağlanmak ve daha fazla yönetmek kolaydır, ancak bunu diğer araçlar ve Azure portalının kendisi aracılığıyla da yapmak mümkündür.

Genel bağlantı noktasına ek olarak, gerekli alt ağa bir sunucu ekleyerek ve özel DNS bölgelerini yapılandırarak özel bir bağlantı noktası da oluşturabilirsiniz.

Hata toleransından bahsetmişken, burada farklı bölgelerde bulunan bir grup koruma sunucusu olan yük devretmenin çok kullanışlı ve sezgisel bir uygulamasını görüyoruz.

Azure'da, bir yük devretme grubundaki sunuculara veritabanları eklemek ve kaldırmak, zorunlu yük devretme ve otomatik yük devretme modu mümkündür.

Bunu aşağıdaki ekran görüntüsünde görebilirsiniz. Yük devretme grubu için bir isim bulalım ve sunucuyu yük devretmeye koyalım. Belirtilen veritabanlarının senkronizasyonu otomatik olarak başlayacaktır. İkinci sunucu salt okunur modda olacaktır. Arıza durumunda trafik otomatik olarak ikinci bölgeye geçer ve birincil ve ikincil sunucular otomatik olarak yer değiştirir.

Ancak veritabanlarının kendisinde veri düzeyinde bir sorun varsa yük devretme yardımcı olmayacaktır. Elbette bu durumda yedek oluşturmanız gerekir. Yedeklemeleri hem portal içinde hem de üçüncü taraf araçlar aracılığıyla veya örneğin Azure DevOps aracılığıyla yapılandırmak mümkündür (boru hattında SqlAzureDacpacDeployment + AzureFileCopy görevini kullanabilirsiniz). Portal içerisinde Yedeklemeler sekmesinde yedeklemeler yapılandırılır ve gerekli depolama politikaları ayarlanır.

Üçüncü taraf yedekleme araçlarını kullanmayı tercih ediyorsanız Azure DevOps veya SQL paket araçlarını değerlendirmenizi öneririm.

Portaldaki kurtarma süreci bence pek uygun değil. İlk fark ettiğiniz şey, basit test veritabanlarının uzun kurtarma süresidir. Örneğin, 30 MB'lık temel boyutlu bir veritabanını dünkü yedeklemeden geri yüklemem yarım saatten fazla sürdü! Microsoft Azure desteğiyle iletişime geçtikten sonra kurtarma için PowerShell scriptlerini kullanmam önerildi ve kurtarma işlemi için veritabanı boyutunun en az S3 olması gerektiği, daha sonra boyutun küçültülebileceği tarafıma bildirildi. Aşağıda bu konuyla ilgili bazı scriptlerimi ve gelişmeleri sunacağım, geliştirilebilir, geliştirilebilir ama eminim birçoğunuz bunları faydalı bulabilir.

Seni adım adım anlatacağım:

1. Windows'ta PowerShell ISE yüklü değilse buradan indirin: https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. Daha sonra Azure modülünü yüklemeniz gerekir: Install-Module Az
3. AZ modülünü kurduktan sonra AZ modülünü içe aktarın: Import-Module Az
4. İçe aktarıldıktan sonra Azure hesabınıza bağlanabilirsiniz: Connect-AzAccount. Azure hesabınıza giriş yapmak için bir açılır pencere görünecek, ardından bağlanacaksınız
5. PowerShell betiğinin kendisini çalıştırın.

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1 - Bu kod, farklı bir adla veritabanı geri yüklemesini başlatır. Geri yüklenen veritabanının orijinal adı "dbforscript" ise, geri yüklenen veritabanının adı dbforscript_new olacaktır. Geri yüklenen veritabanı SLO sürümü S3 veya üstü olacaktır; bu eylemi gerçekleştirmenin önerilen yolu budur; bunun değişkeni $PITRSLO = "S3"tür, S3 veya üstünü kullanabilirsiniz. Bundan sonra SLO seviyesini orijinal seviyesine sıfırlayacağız, bu yalnızca kurtarma amaçlıdır.

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2 - Bu kod, kaynak veritabanını yük devretme grubundan kaldıracaktır: kaynak veritabanı: dbforscript.

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3 - Bu kod replika veritabanını bulunduğu sunucudan kaldıracaktır: test-serv2 sunucusundaki dbforscript.

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 - Bu kod, orijinal veritabanını farklı bir adla yeniden adlandıracaktır: yeniden adlandırma sonrasında dbforscript, dbforscript_old olacaktır.

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5 - Bu kod, geri yüklenen veritabanını orijinal veritabanı adıyla yeniden adlandıracak ve dbforscript_new'i dbforscript olarak yeniden adlandıracaktır.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6 - Bu kod veritabanınızın SLO seviyesini önceki (orijinal) S0 değerine döndürecektir. Veritabanınız temel ise lütfen portaldan sonra S0'dan temel düzeye yükseltebilirsiniz.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 - Son kod, geri yüklenen veritabanını, zaten orijinal isme sahip olan yük devretme grubuna ekler (önceki kodda değiştirdiğimiz için).

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

Komutun sonrasına - ErrorAction Stop parametresini eklemeyi düşünebilirsiniz. Bu, bir hata durumunda aşağıdaki komutların yürütülmesini önleyecek ve kartopu oluşmayacaktır.

Ayrıca yürütme süresini hesaplamak için betiğin başına ve sonuna Get-Date ekleyebilirsiniz. Benim durumumda, yaklaşık 3,3 GB'lık bir veritabanı böyle bir komut dosyası tarafından 6 dakikadan kısa bir sürede geri yüklendi.

Dilerseniz scripti mutlaka optimize edebilir, Azure DevOps üzerinden ekleyebilir, değişken sayısını azaltabilir veya bir şeyi hardcode edebilirsiniz ama ben mümkün olduğunca detaylı ve herkesin anlayabileceği şekilde anlatmaya çalıştım.

Azure'da veritabanı izleme ve Datadog gibi çeşitli sistemlerle entegrasyon yeteneği özel ilgiyi hak ediyor. İzleme oldukça kullanışlıdır, ancak bazı nüanslar da vardır (örneğin, salt okunur kullanıcılar yalnızca bir veritabanı için izlemeyi görebiliyordu, hepsi aynı anda değil... işte gölgeler).

Sonuç olarak ekibimiz, güncellemeler ve desteğin kesilmesiyle ilgili endişeleri giderirken aynı zamanda harcamaları da başarılı bir şekilde optimize etti. Performans, dayanıklılık, geliştirme hızı ve esneklik konularında iyileştirmeler elde ettik. Ek olarak, komut dosyalarının uygulanması, gerektiğinde hızlı bir şekilde iyileşme yeteneğimizi önemli ölçüde artırdı.

Social Discovery Group'un Baş DevOps Mühendisi Pavel Shapurau tarafından yazılmıştır.