Yerel ve bölge yedekliliği ile kullanılabilirlik - Azure SQL Yönetilen Örneği

Şunlar için geçerlidir:Azure SQL Yönetilen Örnek

Bu makalede, yerel yedeklilik aracılığıyla kullanılabilirlik ve alanlar arası yedeklilik aracılığıyla yüksek kullanılabilirlik elde eden Azure SQL Yönetilen Örneği mimarisi açıklanmaktadır.

Genel bakış

SQL Yönetilen Örneği, windows işletim sistemindeki SQL Server veritabanı altyapısının en son kararlı sürümünde ve tüm geçerli düzeltme ekleriyle çalışır. SQL Yönetilen Örneği, düzeltme uygulama, yedekleme, Windows ve SQL veritabanı altyapısı yükseltmeleri gibi kritik bakım görevlerinin yanı sıra, altyapıdaki donanım, yazılım veya ağ arızaları gibi planlanmamış olayları da otomatik olarak yönetir. Bir örneğe yama uygulandığında veya yük devri olduğunda, uygulamanızda yeniden deneme mantığı kullanırsanız kesinti süresi önemli bir etki yaratmaz. SQL Yönetilen Örneği, verilerinizin her zaman erişilebilir olmasını sağlayarak en kritik durumlarda bile hızla kurtarılabilir. Kullanıcıların çoğu yükseltmelerin sürekli olarak gerçekleştirildiğini fark etmez.

Varsayılan olarak, Azure SQL Yönetilen Örneği yerel yedeklilik aracılığıyla kullanılabilirlik elde eder ve örneğinizin aşağıdaki gibi kesintileri işlediğinden emin olur:

  • Kısa süreli bir kesintiye neden olan müşterinin başlattığı yönetim işlemleri
  • Hizmet bakım işlemleri
  • Aşağıdakilerle ilgili sorunlar ve veri merkezi kesintileri:
    • Hizmetinizi destekleyen makinelerin çalıştığı raf.
    • SQL veritabanı altyapısını çalıştıran VM'yi barındıran fiziksel makine.
    • SQL veritabanı altyapısını çalıştıran sanal makine
  • SQL veritabanı altyapısıyla ilgili diğer sorunlar
  • Diğer olası planlanmamış yerel kesintiler

Varsayılan kullanılabilirlik çözümü, işlenen verilerin hatalar nedeniyle hiçbir zaman kaybolmamasını, bakım işlemlerinin iş yükünüz üzerinde en az etkiye sahip olmasını ve örneğin yazılım mimarinizde tek bir hata noktası olmamasını sağlamak için tasarlanmıştır.

Ancak, bir bölgenin tamamında kesinti olması durumunda verileriniz üzerindeki etkiyi en aza indirmek için, alanlar arası yedekliliği etkinleştirerek yüksek kullanılabilirlik elde edebilirsiniz. Alanlar arası yedeklilik olmadan, yük devretmeler aynı veri merkezinde yerel olarak gerçekleşir ve bu da kesinti çözülene kadar örneğinizin kullanılamamasına neden olabilir. Kurtarmanın tek yolu yük devretme grubu veya coğrafi olarak yedekli yedeklemenin coğrafi geri yüklemesi gibi bir olağanüstü durum kurtarma çözümünden geçer. Daha fazla bilgi edinmek için iş sürekliliğine genel bakışı gözden geçirin.

Yüksek kullanılabilirlik, aşağıdakiler üzerindeki etkilerden sizi koruyarak hizmetinizin güvenilirliğini artırır:

  • Veri merkezini oluşturan kullanılabilirlik alanı

Hizmet katmanını temel alan iki farklı kullanılabilirlik mimari modeli vardır:

  • Uzak depolama modeli, Uzak depolamanın kullanılabilirliğine ve güvenilirliğine ve Azure Service Fabric tarafından yönetilen işlem kümelerinin kullanılabilirliğine dayanan Genel Amaçlı ve Sonraki Nesil Genel Amaçlı hizmet katmanlarında işlem ve depolama ayrımını temel alır. Bu kullanılabilirlik modeli, bakım etkinlikleri sırasında bazı performans düşüşlerine dayanabilen bütçe odaklı iş uygulamalarını hedefler.
  • Yerel depolama modeli, yerel depolamaya sahip İş Açısından Kritik hizmet katmanındaki kullanılabilir veritabanı altyapısı düğümlerinin çoğunluğuna dayanan bir veritabanı altyapısı süreçleri kümesine dayanır. Bu yerel depolama modeli, yüksek işlem hızına sahip ve yüksek GÇ performansı gerektiren görev açısından kritik uygulamaları hedefler. Yüksek kullanılabilirlik mimarisi, bakım etkinlikleri sırasında iş yükünüz üzerinde minimum performans etkisi sağlar.

Farklı hizmet katmanları için belirli SLA'lar hakkında daha fazla bilgi için Azure SQL Yönetilen Örneği için SLA'yı gözden geçirin.

Yerel yedeklilik aracılığıyla kullanılabilirlik

Yerel olarak yedekli kullanılabilirlik, işlem düğümlerinizi ve verilerinizi birincil bölgedeki tek bir veri merkezinde depolamayı temel alır ve küçük ölçekli ağ veya güç kesintisi gibi yerel bir hata durumunda verilerinizi korur. Bir bölgede yangın veya sel gibi büyük ölçekli bir olağanüstü durum oluşursa, bir depolama hesabının veya işlem düğümlerindeki verilerin tüm çoğaltmaları kaybolabilir veya kurtarılamaz. Bu nedenle, yerel olarak yedekli kullanılabilirlik seçeneğini kullanırken verilerinizi daha fazla korumak için veritabanı yedeklemeleriniz için daha dayanıklı bir depolama seçeneği kullanmayı göz önünde bulundurun.

Genel Amaçlı hizmet katmanı

Genel Amaçlı hizmet katmanı, uzak depolama kullanılabilirlik mimarisini kullanır. Aşağıdaki şekil, ayrılmış işlem ve depolama katmanlarıyla dört farklı düğümü gösterir.

İşlem ve depolama ayrımını gösteren diyagram.

Uzak depolama kullanılabilirlik modeli iki katman içerir:

  • Veritabanı altyapı sürecini çalıştıran ve yalnızca ekli SSD üzerindeki tempdb ve model veritabanları ile bellekteki plan önbelleği, arabellek havuzu ve columnstore havuzu gibi geçici ve önbelleğe alınmış verileri içeren durum tutmayan bir işlem katmanı. Bu durum bilgisi olmayan düğüm, veritabanı motorunu başlatan, düğümün sistem durumunu denetleyen ve gerekirse başka bir düğüme yük devretmeyi gerçekleştiren Azure Service Fabric tarafından çalıştırılır.
  • Veritabanı dosyalarının (.mdf ve .ldf) Azure Blob Depolama'da depolandığı, durum bilgisi tutan bir veri katmanı. Azure Blob Depolama yerleşik veri kullanılabilirliği ve yedeklilik özelliklerine sahiptir. Yerel olarak yedekli kullanılabilirlik, verilerinizi birincil bölgedeki tek bir veri merkezinde üç kez kopyalayan yerel olarak yedekli depolamada (LRS) depolamayı temel alır. Veritabanı motoru işlemi çökse bile, günlük dosyasındaki her kaydın veya veri dosyasındaki her sayfanın korunacağını garanti eder.

Veritabanı altyapısı veya işletim sistemi yükseltildiğinde veya bir hata algılandığında, Azure Service Fabric durum bilgisi olmayan veritabanı altyapısı işlemini yeterli boş kapasiteye sahip başka bir durum bilgisi olmayan işlem düğümüne taşır. Azure Blob depolamadaki veriler taşıma işleminden etkilenmez ve veri/günlük dosyaları yeni başlatılan veritabanı altyapısı işlemine eklenir. Bu işlem yüksek kullanılabilirliği garanti eder, ancak yeni veritabanı altyapısı işlemi soğuk önbellekle başladığından geçiş sırasında ağır bir iş yükü biraz performans düşüşü yaşayabilir.

Yeni nesil Genel Amaçlı hizmet katmanı

Yeni nesil Genel Amaçlı, mevcut Genel Amaçlı hizmet katmanına mimari bir yükseltmedir ve sayfa blobları yerine Elastik SAN'da instance verilerini ve log dosyalarını depolamak için yükseltilmiş bir uzak depolama katmanı kullanır.

Yeni nesil Genel Amaçlı hizmet katmanı için bölge yedekliliği şu anda önizlemededir. Önizleme ayrıca Premium serisi donanımda bölge yedekli örnekler için esnek belleği destekler.

İş Açısından Kritik hizmet katmanı

İş Açısından Kritik hizmet katmanı, işlem kaynaklarını (veritabanı altyapısı işlemi) ve depolamayı (yerel olarak bağlı SSD) tek bir düğümde tümleştiren yerel depolama kullanılabilirlik modelini kullanır. Kullanılabilirlik, hem işlem hem de depolama ek düğümlere çoğaltılarak elde edilir.

Veritabanı altyapısı düğümleri kümesinin diyagramı.

Altyapıdaki veritabanı dosyaları (.mdf/.ldf), iş yükünüz için çok düşük gecikmeli G/Ç sağlamak üzere ekli SSD depolamasına yerleştirilir. Kullanılabilirlik, SQL Server Always On kullanılabilirlik gruplarına benzer bir teknoloji kullanılarak uygulanır. Küme, okuma-yazma müşteri iş yükleri için erişilebilen tek bir birincil çoğaltma ve veri kopyaları içeren en fazla üç ikincil çoğaltma (işlem ve depolama) içerir. Birincil çoğaltma, her işlemi kesinleştirmeden önce verilerin yeterli sayıda ikincil çoğaltmada kalıcı olmasını sağlamak için değişiklikleri sürekli olarak ikincil çoğaltmalara ardışık olarak gönderir. Bu işlem, birincil çoğaltmanın veya okunabilir bir ikincil çoğaltmanın herhangi bir nedenle kullanılamaz duruma gelmesi durumunda, yük devretme için her zaman tam olarak eşitlenmiş bir çoğaltmanın kullanılabilir olmasını garanti eder. Yük devretme, Azure Service Fabric tarafından başlatılır. Bir ikincil replika yeni birincil replika olduğunda, kümenin quorum’u korumak için yeterli sayıda replikaya sahip olmasını sağlamak amacıyla başka bir ikincil replika oluşturulur. Yük devretme tamamlandıktan sonra Azure SQL bağlantıları otomatik olarak yeni birincil replikaya (veya bağlantı dizesine bağlı olarak okunabilir ikincil replikaya) yönlendirilir.

Ek bir avantaj olarak, yerel depolama kullanılabilirlik modeli salt okunur Azure SQL bağlantılarını ikincil çoğaltmalardan birine yeniden yönlendirme özelliğini içerir. Bu özelliğe Okuma Ölçeği Genişletme adı verilir. Birincil çoğaltmadan analitik iş yükleri gibi salt okunur yük dışı işlemlere ek ücret ödemeden %100 ek işlem kapasitesi sağlar.

Bölge yedekliliği ile yüksek kullanılabilirlik

Alanlar arası yedekli kullanılabilirlik, çoğaltmaların birincil bölgedeki üç Azure kullanılabilirlik alanına yerleştirilmesine dayanır. Her kullanılabilirlik alanı bağımsız enerji, soğutma ve ağ altyapısına sahip olan ayrı bir fiziksel konumu ifade eder.

Varsayılan olarak, yerel depolama kullanılabilirlik modeli için düğüm kümesi aynı veri merkezinde oluşturulur. Azure Kullanılabilirlik Alanları'nin kullanıma sunulmasıyla SQL Yönetilen Örneği farklı çoğaltmaları aynı bölgedeki farklı kullanılabilirlik alanlarına yerleştirir. Tek bir hata noktasını ortadan kaldırmak için denetim halkası da birden çok bölgede çoğaltılır. Denetim düzlemi trafiği daha sonra, aynı şekilde birden çok erişilebilirlik alanına dağıtılmış bir yük dengeleyiciye yönlendirilir. Denetim düzleminden yük dengeleyiciye trafik yönlendirme, Azure Traffic Manager (ATM) tarafından denetlenilir.

Bölge-yedekli bir yapılandırma kullanarak, İş Kritik, Genel Amaçlı veya Yeni nesil Genel Amaçlı örneklerinizi uygulama mantığında herhangi bir değişiklik olmadan çok daha büyük bir arıza setine, özellikle felaket veri merkezi kesintilerine karşı dayanıklı hale getirebilirsiniz. Mevcut örnekleri bölge yedekli yapılandırmasına dönüştürebilirsiniz. Yeni nesil Genel Amaçlı hizmet seviyesi için bölge yedekliği şu anda ön izleme aşamasında.

Bölge-yedekli örneklerin farklı veri merkezlerinde replikaları olması ve aralarında belli bir mesafe olması nedeniyle, artan ağ gecikmesi işlem taahhüt süresini artırabilir ve dolayısıyla bazı OLTP iş yüklerinin performansını etkileyebilir. Alanlar arası yedeklilik ayarını devre dışı bırakarak her zaman tek bölgeli yapılandırmaya dönebilirsiniz. Bu işlem, normal hizmet katmanı hedef yükseltmesine benzer çevrimiçi bir işlemdir. İşlemin sonunda örnek, bölgeler arası yedekli bir halkadan tek bölgeli bir halkaya veya tersine taşınır.

SQL yönetilen örneğiniz için alanlar arası yedekliliği kullanmaya başlamak için Alanlar arası yedekliliği yapılandırma'yı gözden geçirin. Azure SQL Yönetilen Örneği için bölgeye göre bölge yedekliliği kullanılabilirliğini gözden geçirin.

Genel Amaçlı hizmet katmanı

Genel Amaçlı hizmet katmanında alan yedekliliği, durum bilgisi olmayan işlem düğümlerinin farklı kullanılabilirlik alanlarına yerleştirilmesiyle sağlanır ve ardından, o anda etkin SQL Veritabanı Altyapısı işlemini barındıran düğüme bağlanan durum bilgisi içeren alan yedekli depolamaya (ZRS) dayanır. Kesinti durumunda, durum bilgisi olmayan düğümlerden birinde SQL Veritabanı Altyapısı işlemi etkin hale gelir ve ardından durum bilgisi olan depolamadaki verilere erişir.

Aşağıdaki diyagramda, Genel Amaçlı hizmet katmanı için alanlar arası yedeklilik mimarisi gösterilmektedir:

Genel Amaçlı hizmet katmanındaki alanlar arası yedeklilik mimarisinin diyagramı.

Yeni nesil Genel Amaçlı hizmet katmanı

Yeni nesil Genel Amaçlı hizmet katmanı için bölge yedekliliği şu anda önizlemededir. Bölge yedekli bir yapılandırma, hizmet bileşenlerini kullanılabilirlik bölgeleri arasında dağıtır ve yükseltilmiş Elastik SAN uzak depolama katmanını kullanır. Önizleme, Premium serisi donanımda esnek belleği destekliyor, böylece vcore sayısından bağımsız olarak belleği ayarlayabilirsiniz.

İş Açısından Kritik hizmet katmanı

İş Açısından Kritik hizmet katmanında, işlem ve depolama çoğaltmaları farklı kullanılabilirlik alanlarına yerleştirilerek ve ardından birincil örnekteki veri değişikliklerini diğer kullanılabilirlik alanlarındaki bekleme çoğaltmalarına çoğaltmak için temel Always On kullanılabilirlik grubu teknolojisi kullanılarak alanlar arası yedeklilik elde edilir. Bir kesinti durumunda, beklemedeki çoğaltmalardan birini sorunsuz bir şekilde birincil duruma getiren otomatik bir yük devralma gerçekleşir.

Aşağıdaki diyagramda, İş Açısından Kritik hizmet katmanı için alanlar arası yedeklilik mimarisi gösterilmektedir:

İş Açısından Kritik hizmet katmanındaki alanlar arası yedeklilik mimarisinin diyagramı.

Uygulama hata dayanıklılığını test edin

Kullanılabilirlik, veritabanı uygulamanız için saydam bir şekilde çalışan SQL Yönetilen Örneği platformunun temel bir parçasıdır. Ancak, planlı veya plansız olaylar sırasında başlatılan otomatik yedekleme işlemlerinin bir uygulamayı üretime yüklemeden önce nasıl etkileyeceğini test etmek isteyebileceğinizi kabul ediyoruz. Yönetilen bir örneği yeniden başlatmak için özel bir API’yi çağırarak yük devretmeyi manuel olarak tetikleyebilirsiniz. Yeniden başlatma işlemi müdahaleci olduğundan ve bunların çok büyük bir kısmı platformu strese atabileceğinden, her yönetilen örnek için her 15 dakikada bir yalnızca bir yük devretme çağrısına izin verilir.

Gerçek bir yük devretme sırasında, SQL hizmeti farklı bir düğümde birincil hale gelirken örneğe yönelik bağlantılar başarısız olur. Yük devretmeyi simüle etmek için, hizmeti yük devretme gerçekleşmiş gibi başlatmayı simüle eden SQL işlemini yeniden başlatma komutunu çalıştırın. Ancak, gerçek yük devretme sırasında bağlantılar, sanal yük devretme sırasında olduğundan daha uzun süre başarısız olabilir. Bunun nedeni, gerçek yük devretme sırasında SQL işleminin küme içindeki başka bir sanal makinede birincil duruma gelmesidir (yerel olarak ya da bölge yedekliliği etkinse başka bir bölgede), sanal yük devretme sırasında ise SQL işlemi mevcut sanal makinede yeniden başlatılır.

Bu bölümde sunulan el ile yük devretme komutu genellikle hem yerel olarak yedekli hem de alanlar arası yedekli yapılandırmalarda aynı şekilde davranır. Komut genellikle yalnızca SQL işlemini yerel olarak yeniden başlatır ve bazı istisnalar geçerli olsa da başka bir düğüme yük devrini başlatmaz. Bu yerel yük devretme, bir yük devretme grubu için gerçekleşen yük devretme işleminden farklıdır. Ancak, yeni işlemin aynı düğümde başlamasını garanti eden bir kısıtlama yoktur ve aynı düğümde veya farklı bir kullanılabilirlik alanında başlayabilir. PowerShell, REST API veya Azure CLI kullanılarak yerel yük devretme başlatılabilir:

PowerShell REST API Azure Komut Satırı Arayüzü (Azure CLI)
Invoke-AzSqlInstanceFailover SQL Yönetilen Örneği - Yük Devretme az sql mi failover , Azure CLI'dan REST API çağrısı çağırmak için kullanılabilir

Otomatik iç bağlantı testleri

Hizmetinizin kullanılabilirliğini sağlamaya yardımcı olmak için Azure SQL Yönetilen Örneği, hizmet güvenilirliğini izlemek ve sorun algılamayı hızlandırmak için otomatik iç bağlantı testleri çalıştırır. Bu testler, SQL yönetilen örneğin alt ağındaki iç IP adreslerinden 10 saniyede bir çalıştırılır ve ağ aktarım hızı ve hizmet performansı üzerinde göz ardı edilebilir bir performans etkisine sahiptir. Testlerden biri, başarısız olacağı bilinen bir kimlik bilgisiyle (AzureSQLConnectivityChecker) oturum açmayı deneyerek uçtan uca bağlantıyı doğrular; bu işlem, denetim günlüklerinde, Extended Events'te ve SQL hata günlüklerinde beklenen başarısız oturum açma kayıtlarını oluşturur. Bu girişler normaldir ve bir güvenlik sorununa işaret etmemektedir. Günlüklerinizdeki test imzalarını tanımlama da dahil olmak üzere daha fazla bilgi için bkz. Otomatik iç bağlantı testleri.

Sonuç

Azure SQL Yönetilen Örneği, Azure platformuyla tümleşik yerleşik bir yüksek kullanılabilirlik çözümüne sahiptir. Hizmet, hataları algılamak ve kurtarmak için Service Fabric'e, verileri korumak için Azure Blob depolamaya ve daha yüksek hataya dayanıklılık için Kullanılabilirlik Alanları bağlıdır. İş Açısından Kritik hizmet katmanında SQL Yönetilen Örneği, veritabanı çoğaltma ve yük devretme için SQL Server Always On kullanılabilirlik grubu teknolojisini kullanır. Bu teknolojilerin birleşimi, uygulamaların karma depolama modelinin avantajlarını tam olarak gerçekleştirmesini sağlar ve en zorlu SLA'ları destekler.

İlgili içerik

  • Last updated on