Azure SQL DB SLA’leri ne anlama gelmektedir?

Veriler işletmenizin can damarı olduğunda, veritabanlarınızın tutarlı, güvenli ve gerçekleştirilmesini istediğiniz performans seviyesinde kullanılabilir olmasını sağlamak istersiniz. Hizmet düzeyi sözleşmeleri (SLA), çalışma süresi ve performans beklentisi oluşturur ve iş ihtiyaçlarını karşılayacak sistemleri tasarlamak için önemli bir girdidir. Kısa bir süre önce, ilişkisel veritabanı hizmetleri arasında en yüksek kullanılabilirliği garanti etmenin yanı sıra sektörün ilk iş sürekliliği SLA’inı da sunan SQL Veritabanı SLA’inın yeni bir sürümü Microsoft tarafından yayınlandı. Bu güncellemeler, verilerinizin güvenli olmasını ve işletmenizin yıkıcı bir etkinlik karşısında çalışmaya devam etmesi üzerine güvendiği uygulamaları ve süreçleri sağlama konusundaki kararlılığımızı daha da güçlendirmektedir.

Son hizmet güncellemesinde belirtildiği gibi, SLA’da iki büyük değişiklik yapıldı. İlk olarak, Azure SQL Veritabanı artık Business critic katmanındaki bölge yedekli veritabanları için% 99,995 kullanılabilirlik SLA’i sunuyor. Bu, tüm ilişkisel veritabanı hizmetleri arasında piyasadak, en yüksek SLA’dır. Ayrıca, SLA’nın taahhütü tutulmadığında % 100’e kadar aylık tüketimin geri ödenmesini de içeriyor. İkinci olarak, Business critic katmanındaki iki farklı Azure bölgesi arasında coğrafi olarak çoğaltılmış veritabanları için bir iş sürekliliği SLA’i sunuluyor. Bu SLA, SLA korunmadığında aylık% 100 tüketim geri ödemesi de dahil olmak üzere beş saniyelik bir kurtarma noktası hedefi (RPO) ve 30 saniyelik bir kurtarma süresi hedefi (RTO) için çok güçlü garantilerle birlikte gelir. Azure SQL Veritabanı, iş sürekliliği SLA’si sunan piyasadaki tek ilişkisel veritabanı hizmetidir.

Aşağıdaki tabloda, farklı bulut satıcılarının SLA’larının hızlı bir şekilde yan yana karşılaştırması sunulmaktadır.

Kullanılabilirlik SLA’inı anlama

Kullanılabilirlik SLA’i, SQL Veritabanı’nın her bölgede periyodik olarak meydana gelen yıkıcı olayları otomatik olarak işleme yeteneğini yansıtır. Bilgi işlem ve depolama kaynaklarının bölge içi yedekliliğine, bölge içinde otomatik yük devretme kullanarak sürekli sağlık izleme ve kendi kendini iyileştirme operasyonlarına dayanır. Bu işlemler eşzamanlı olarak çoğaltılmış verilere dayanır ve sıfır veri kaybına neden olur. Bu nedenle, çalışma süresi kullanılabilirlik için en önemli metriktir. Azure SQL Veritabanı, tüm hizmet katmanlarında% 99,99 oranında kullanılabilirlik durumu SLA’i sunmaya devam edecek, ancak şu anda kullanılabilirlik bölgelerini destekleyen bölgelerdeki iş açısından kritik veya premium katmanlar için% 99,995 oranında daha yüksek bir SLA sağlıyor. Business critic katman, adından da anlaşılacağı gibi, hem performans hem de güvenilirlik açısından en zorlu uygulamalar için tasarlanmıştır. Bu hizmet katmanını Azure kullanılabilirlik bölgeleriyle (AZ) entegre ederek, AZ’lerin sağladığı ek hata toleransından ve yalıtımından yararlanırız, bu da AZ’lerde hesaplama ve depolama artıklığını ve aynı kendi kendini iyileştirmeyi kullanarak daha yüksek kullanılabilirlik garantisi sunmamıza olanak tanır. Bilgi işlem ve depolama alanı yedekliliği, iş açısından kritik veritabanları ve elastik havuzlar için oluşturulduğundan, kullanılabilirlik bölgelerini kullanmak sizin için ek bir maliyet getirmez.

% 99,99 kullanılabilirlik, Business critic katman dahil olmak üzere herhangi bir veritabanı için kesinti süresinin yılda 52,56 dakikayı geçmemesi gerektiği anlamına gelir. Bölge yedekliliği, kullanılabilirliği% 99.995’e çıkarır, bu da yılda yalnızca 26.28 dakikalık maksimum kapalı kalma süresi veya % 50 azalma anlamına gelir. Bir dakikalık kesinti süresi, tüm bağlantı kurma girişimlerinin başarısız olduğu dönem olarak tanımlanır. Bu düzeyde kullanılabilirliği sağlamak için, işiniz için kritik bir veritabanı veya elastik havuz oluştururken tek yapmanız gereken bölge yedekli yapılandırmayı seçmektir. Bunu, aşağıdaki diyagramda gösterildiği gibi, bir oluşturma veya güncelleme veritabanı API’sı kullanarak veya Azure portalında programlı olarak yapabilirsiniz.

Bölge yedek kapasitesi çoğu bölgedeki Gen5’e dayandığından Gen5 hesaplama üretimini kullanmanızı öneririz. Bir bölge yedekli yapılandırmasına dönüştürme, veritabanının hizmet katmanını veya hesaplama boyutunu değiştirdiğinizde gerçekleşene benzer, eşzamansız bir çevrimiçi işlemdir. Uygulamanızı almayı veya çevrimdışına almayı gerektirmez. Bağlantı mantığınız düzgün bir şekilde uygulandığı sürece, uygulamanız bu geçiş sırasında kesintiye uğramaz.

İş sürekliliği SLA’inı anlama

İş sürekliliği, bir hizmetin, bölgedeki kendi kendini iyileştirme operasyonları tarafından hafifletilemeyecek bir etki ile felaket olayları sırasında hızlı bir şekilde iyileşme ve işlevini sürdürme yeteneğidir. Bu tür planlanmamış olaylar nadir olmakla birlikte, etkileri dramatik olabilir. İş sürekliliği, veritabanlarınızın coğrafi olarak ayrılmış iki veya daha fazla konumda yedek kopyalarını sağlayarak gerçekleştirilir. Bu konumlar arasındaki uzun mesafeler nedeniyle, ağ gecikmesinden kaynaklanan performans etkisini önlemek için eşzamansız veri çoğaltması kullanılır. Eşzamansız çoğaltma kullanmanın temel ödünleşimi veri kaybı potansiyelidir. SQL Veritabanı’ndaki etkin coğrafi çoğaltma özelliği, coğrafi olarak gereksiz veritabanları oluşturarak ve yöneterek iş sürekliliğini sağlamak üzere tasarlanmıştır. Birkaç yıldır üretiliyor ve çok agresif garantileri desteklemek için bol miktarda telemetri var.

İş sürekliliği olaylarının etkisini ölçmek için kullanılan iki ortak metrik vardır. Kurtarma süresi hedefi (RTO), uygulamanın kullanılabilirliğinin ne kadar hızlı bir şekilde geri yüklenebileceğini ölçer. Kurtarma noktası hedefi (RPO), kullanılabilirlik geri yüklendikten sonra beklenen maksimum veri kaybını ölçer. Sadece RPO için beş saniyelik ve RTO için 30 saniyelik SLA’lar sağlamakla kalmıyor, aynı zamanda bu SLA’lar karşılanmadığında sektörde bir ilk% 100 hizmet kredisi sunuluyor. Başka bir deyişle, veritabanı yük devretme isteklerinizden herhangi biri 30 saniye içinde tamamlanmazsa veya çoğaltma gecikmesi bir saat içinde 99. persentilde beş saniyeyi aşarsa, ikincil veritabanının aylık maliyetinin% 100’ü için bir hizmet kredisi almaya hak kazanırsınız. Hizmet kredisine hak kazanmak için, ikincil veritabanının birincil bilgi işlem boyutuyla aynı bilgi işlem boyutuna sahip olması gerekir. Ancak, bu metriklerin yıkıcı bir kesintiden otomatik olarak kurtarmanın garantisi olarak yorumlanmaması gerektiğini unutmayın. Verilerinizi senkronize ederken Azure SQL’in güvenilirliğini ve performansını ve uygulamanız istediğinde yük devretme hızını yansıtırlar. Tam otomatik kurtarma işlemini tercih ederseniz, bir saatlik RTO’ya sahip otomatik yük devretme ilkesine sahip otomatik yük devretme gruplarını göz önünde bulundurmalısınız.

Yük devretme isteğinin süresini, yani RTO uyumluluğunu ölçmek için, ikincil sunucudaki ana veritabanındaki sys.dm_operation_status’a karşı aşağıdaki sorguyu kullanabilirsiniz. Lütfen çalışma durumu bilgilerinin sadece 24 saat saklandığını unutmayın.

SELECT datediff(s, start_time, last_modify_time) as [Failover time in seconds] FROM sys.dm_operation_status WHERE major_resource_id = ‘<my_secondary_db_name>’, operation=’ALTER DATABASE FORCE FAILOVER ALLOW DATA LOSS ’, state=2 ORDER BY start_time DESC;

Birincil veritabanındaki sys.dm_replication_link_status’a karşı aşağıdaki sorgu, partner_server üzerinde oluşturulan ikincil veritabanı için saniye cinsinden çoğaltma gecikmesini, yani RPO uyumluluğunu gösterir. Saatte istatistiksel olarak anlamlı bir ölçüm kümesi elde etmek için aynı sorguyu her 30 saniyede bir veya daha az çalıştırmalısınız.

SELECT link_guid, partner_server, replication_lag_sec FROM sys.dm_replication_link_status

Kritik görev uygulamaları oluşturmak için kullanılabilirliği ve iş sürekliliğini birleştirmek

Güncellenmiş SLA sizin için pratikte ne anlama geliyor? Amacımız, SQL Veritabanı tarafından desteklenen Azure üzerinde son derece esnek ve güvenilir hizmetler oluşturmanızı sağlamaktır. Ancak, bazı kritik görev uygulamaları için yılda 26 dakikalık kesinti süresi bile kabul edilemeyebilir. Bir bölge yedekli veritabanı yapılandırmasını iş sürekliliği tasarımıyla birleştirmek, uygulama için kullanılabilirliği daha da artırma fırsatı yaratır. Bu SLA sürümü, bu fırsatı gerçekleştirmenin ilk adımıdır.