İş sürekliliğine ve olağanüstü durum kurtarmaya genel bakış
Azure Veri Gezgini'da iş sürekliliği ve olağanüstü durum kurtarma, işletmenizin kesintiler karşısında çalışmaya devam etmelerini sağlar. Bu makalede kullanılabilirlik (bölge içi) ve olağanüstü durum kurtarma ele alınmaktadır. Dayanıklı bir Azure Veri Gezgini dağıtımı için yerel özellikleri ve mimari konuları ayrıntılı olarak açıklar. İnsan hatalarından kurtarmayı, yüksek kullanılabilirliği ve ardından birden çok olağanüstü durum kurtarma yapılandırmasının ayrıntılarını sağlar. Bu yapılandırmalar Kurtarma Noktası Hedefi (RPO) ve Kurtarma Süresi Hedefi (RTO), gerekli çaba ve maliyet gibi dayanıklılık gereksinimlerine bağlıdır.
Kesintiye neden olan olayları azaltma
- İnsan hatası
- Azure Veri Gezgini yüksek kullanılabilirliği
- Azure kullanılabilirlik alanında kesinti
- Azure veri merkezinde kesinti
- Azure bölgesinde kesinti
İnsan hatası
İnsan hataları kaçınılmazdır. Kullanıcılar yanlışlıkla bir kümeyi, veritabanını veya tabloyu bırakabilir.
Yanlışlıkla küme veya veritabanı silme
Yanlışlıkla küme veya veritabanı silme işlemi kurtarılamaz bir eylemdir. Azure Veri Gezgini kaynağı sahibi olarak, Azure kaynak düzeyinde kullanılabilen silme kilidi özelliğini etkinleştirerek veri kaybını önleyebilirsiniz.
Yanlışlıkla tablo silme
Tablo yöneticisi izinleri veya üzeri olan kullanıcıların tabloları bırakmasına izin verilir. Bu kullanıcılardan biri yanlışlıkla bir tablo bırakırsa, komutunu kullanarak .undo drop table tabloyu kurtarabilirsiniz. Bu komutun başarılı olması için önce bekletme ilkesindekurtarılabilirlik özelliğini etkinleştirmeniz gerekir.
Yanlışlıkla dış tablo silme
Dış tablolar , veritabanının dışında depolanan verilere başvuran Kusto sorgu şeması varlıklarıdır. Dış tablonun silinmesi yalnızca tablo meta verilerini siler. Tablo oluşturma komutunu yeniden yürüterek kurtarabilirsiniz. Geçici silme özelliğini kullanarak kullanıcı tarafından yapılandırılan bir süre boyunca bir dosyanın/blobun yanlışlıkla silinmesine veya üzerine yazılmasını önleyin.
Azure Veri Gezgini yüksek kullanılabilirliği
Yüksek kullanılabilirlik Azure Veri Gezgini, bileşenlerinin ve bir Azure bölgesindeki temel bağımlılıkların hataya dayanıklılığını ifade eder. Bu hataya dayanıklılık, uygulamada tek hata noktalarını (SPOF) önler. Azure Veri Gezgini'da yüksek kullanılabilirlik kalıcılık katmanını, işlem katmanını ve öncü-takip yapılandırması içerir.
Kalıcılık katmanı
Azure Veri Gezgini, dayanıklı kalıcılık katmanı olarak Azure Depolama'yı kullanır. Azure Depolama otomatik olarak hataya dayanıklılık sağlar ve varsayılan ayar bir veri merkezinde Yerel Olarak Yedekli Depolama (LRS) sunar. Üç çoğaltma kalıcıdır. Bir çoğaltma kullanımdayken kaybolursa, başka bir çoğaltma kesinti olmadan dağıtılır. Ek maliyetle maksimum hataya dayanıklılık için çoğaltmaları Azure bölgesel kullanılabilirlik alanları arasında akıllı bir şekilde yerleştiren Alanlar Arası Yedekli Depolama (ZRS) ile daha fazla dayanıklılık mümkündür. ZRS özellikli depolama, Azure Veri Gezgini kümesi Kullanılabilirlik Alanları dağıtıldığında otomatik olarak yapılandırılır.
İşlem katmanı
Azure Veri Gezgini dağıtılmış bir bilgi işlem platformudur ve ölçek ve düğüm rol türüne bağlı olarak iki veya çok düğüme sahip olabilir. Sağlama zamanında, en yüksek bölge içi dayanıklılık için düğüm dağıtımını bölgeler arasında dağıtmak için kullanılabilirlik alanlarını seçin. Kullanılabilirlik alanı hatası tam bir kesintiye neden olmaz, bunun yerine bölgenin kurtarılmasının ardından performans düşüşüyle sonuçlanır.
Öncü-takipçi kümesi yapılandırması
Azure Veri Gezgini, öncü kümenin verilerine ve meta verilerine salt okunur erişim için diğer takipçi kümeleri tarafından takip edilmesi için isteğe bağlı bir takipçi özelliği sağlar. Öncüdeki , appendve drop gibi createdeğişiklikler otomatik olarak takipçiyle eşitlenir. Liderler Azure bölgelerine yayılabilse de, takip eden kümelerin öncüyle aynı bölgelerde barındırılması gerekir. Öncü küme çalışmıyorsa veya veritabanları ya da tablolar yanlışlıkla bırakılırsa, öncüde erişim kurtarılana kadar takipçi kümeleri erişimi kaybeder.
Azure kullanılabilirlik alanında kesinti
Azure kullanılabilirlik alanları, aynı Azure bölgesindeki benzersiz fiziksel konumlardır. Azure Veri Gezgini kümesinin işlem ve verilerini kısmi bölge hatasına karşı koruyabilir. Bölge içi olduğu için bölge hatası bir kullanılabilirlik senaryosudur.
Bir Azure Veri Gezgini kümesini diğer bağlı Azure kaynaklarıyla aynı bölgeye sabitleyin. Kullanılabilirlik alanlarını etkinleştirme hakkında daha fazla bilgi için bkz. Küme oluşturma.
Not
Kullanılabilirlik alanlarına dağıtım, küme oluşturulurken mümkündür veya daha sonra geçirilebilir.
Azure veri merkezinde kesinti
Azure kullanılabilirlik alanları bir maliyetle gelir ve bazı müşteriler bölgesel yedeklilik olmadan dağıtım yapmayı tercih eder. Bu tür bir Azure Veri Gezgini dağıtımıyla, Azure veri merkezi kesintisi küme kesintisine neden olur. Bu nedenle Azure veri merkezi kesintisini işleme, Azure bölgesi kesintisi ile aynıdır.
Azure bölgesinde kesinti
Azure Veri Gezgini, azure bölgesinin tamamının kesintisine karşı otomatik koruma sağlamaz. Böyle bir kesinti olduğunda iş etkisini en aza indirmek için, eşleştirilmiş Azure bölgelerinde birden çok Azure Veri Gezgini kümesi. Kurtarma süresi hedefinize (RTO), kurtarma noktası hedefinize (RPO) ve çaba ve maliyetle ilgili önemli noktalara bağlı olarak , birden çok olağanüstü durum kurtarma yapılandırması vardır. Azure Danışmanı önerileri ve otomatik ölçeklendirme yapılandırması ile maliyet ve performans iyileştirmeleri yapılabilir.
Olağanüstü durum kurtarma yapılandırmaları
Bu bölümde, dayanıklılık gereksinimlerine (RPO ve RTO), gerekli çabaya ve maliyete bağlı olarak birden çok olağanüstü durum kurtarma yapılandırması ayrıntılı olarak açıklanmıştır.
Kurtarma süresi hedefi (RTO), bir kesintiden kurtulma süresini ifade eder. Örneğin, 2 saatlik RTO, uygulamanın kesintiden sonraki iki saat içinde çalışır durumda olması gerektiğini gösterir. Kurtarma noktası hedefi (RPO), söz konusu süre boyunca kaybedilen verilerin miktarı izin verilebilen eşikten fazla olmadan önce kesinti sırasında geçebilecek zaman aralığını ifade eder. Örneğin, RPO 24 saatse ve bir uygulamanın verileri 15 yıl öncesinden başlıyorsa, bunlar hala üzerinde anlaşmaya varılan RPO'nun parametreleri içindedir.
Veri alımı, işleme ve kürasyon süreçleri, olağanüstü durum kurtarma planlaması yaparken dikkatli bir tasarıma ihtiyaç duyar. Veri alımı çeşitli kaynaklardan Azure Veri Gezgini ile tümleştirilmiş verileri ifade eder; işleme dönüştürmeleri ve benzer etkinlikleri ifade eder; seçme işlemi gerçekleştirilmiş görünümleri, veri gölüne dışarı aktarmaları vb. ifade eder.
Popüler olağanüstü durum kurtarma yapılandırmaları aşağıda ve her biri aşağıda ayrıntılı olarak açıklanmıştır.
- Etkin-Etkin-Etkin (her zaman açık) yapılandırma
- Etkin-Etkin yapılandırma
- Etkin-Etkin bekleme yapılandırması
- İsteğe bağlı veri kurtarma kümesi yapılandırması
Etkin-etkin-etkin yapılandırması
Bu yapılandırma "always-on" olarak da adlandırılır. Kesintilere toleransı olmayan kritik uygulama dağıtımlarında, eşleştirilmiş Azure bölgelerinde birden çok Azure Veri Gezgini kümesi kullanmanız gerekir. Tüm kümelere paralel olarak alımı, işlemeyi ve kürasyonu ayarlayın. Küme SKU'su bölgeler arasında aynı olmalıdır. Azure, güncelleştirmelerin eşleştirilmiş Azure bölgelerinde dağıtılmasını ve aşamalı olarak dağıtılmasını sağlar. Azure bölgesi kesintisi uygulama kesintisine neden olmaz. Biraz gecikme veya performans düşüşü yaşayabilirsiniz.
| Yapılandırma | RPO | RTO | Efor | Maliyet |
|---|---|---|---|---|
| Etkin-Etkin-Etkin-n | 0 saat | 0 saat | Daha az | Yüksek |
Active-Active yapılandırması
Bu yapılandırma , etkin-etkin-etkin yapılandırmasıyla aynıdır, ancak yalnızca iki Azure eşleştirilmiş bölgesi içerir. İkili alımı, işlemeyi ve kürasyonu yapılandırın. Kullanıcılar en yakın bölgeye yönlendirilir. Küme SKU'su bölgeler arasında aynı olmalıdır.
| Yapılandırma | RPO | RTO | Efor | Maliyet |
|---|---|---|---|---|
| Etkin-Etkin | 0 saat | 0 saat | Daha az | Yüksek |
Bekleme yapılandırması Active-Hot
Active-Hot yapılandırması çift alma, işleme ve kürasyondaki Active-Active yapılandırmasına benzer. Hazır bekleyen küme alım, işlem ve kürasyon için çevrimiçi olsa da sorgu için kullanılamaz. Hazır bekleyen kümenin birincil kümeyle aynı SKU'da olması gerekmez. Daha küçük bir SKU ve ölçek olabilir ve bu da daha az performanslı olmasına neden olabilir. Olağanüstü durum senaryosunda kullanıcılar bekleme kümesine yönlendirilir ve bu küme isteğe bağlı olarak performansı artırmak için ölçeği artırılabilir.
| Yapılandırma | RPO | RTO | Efor | Maliyet |
|---|---|---|---|---|
| Etkin-Etkin Bekleme | 0 saat | Düşük | Orta | Orta |
İsteğe bağlı veri kurtarma yapılandırması
Bu çözüm, en düşük dayanıklılık (en yüksek RPO ve RTO), en düşük maliyet ve en yüksek efor sunar. Bu yapılandırmada veri kurtarma kümesi yoktur. GrS (Coğrafi Olarak Yedekli Depolama) yapılandırılmış bir depolama hesabına özel olarak seçilmiş verilerin sürekli dışarı aktarılmasını (ham ve ara veriler gerekli olmadığı sürece) yapılandırın. Bir olağanüstü durum kurtarma senaryosu varsa bir veri kurtarma kümesi çalışır durumdadır. Bu sırada DLL'ler, yapılandırma, ilkeler ve işlemler uygulanır. Veriler kustoCreationTime alım özelliğiyle depolama alanından alınarak varsayılan olarak sistem saati olan alım süresine fazla binilir.
| Yapılandırma | RPO | RTO | Efor | Maliyet |
|---|---|---|---|---|
| İsteğe bağlı veri kurtarma kümesi | Yüksek | Yüksek | Yüksek | En düşük |
Olağanüstü durum kurtarma yapılandırma seçeneklerinin özeti
| Yapılandırma | Dayanıklılık | RPO | RTO | Efor | Maliyet |
|---|---|---|---|---|---|
| Etkin-Etkin-Etkin-n | Yüksek | 0 saat | 0 saat | Daha az | Yüksek |
| Etkin-Etkin | Yüksek | 0 saat | 0 saat | Daha az | Yüksek |
| Etkin-Etkin Bekleme | Orta | 0 saat | Düşük | Orta | Orta |
| İsteğe bağlı veri kurtarma kümesi | En düşük | Yüksek | Yüksek | Yüksek | En düşük |
En iyi yöntemler
Hangi olağanüstü durum kurtarma yapılandırmasının seçildiğine bakılmaksızın aşağıdaki en iyi yöntemleri izleyin:
- Tüm veritabanı nesneleri, ilkeleri ve yapılandırmaları, yayın otomasyon aracınızdan kümeye bırakılabilmesi için kaynak denetiminde kalıcı olmalıdır. Daha fazla bilgi için bkz. Azure Veri Gezgini için Azure DevOps desteği.
- Tüm kümelerin veri açısından eşitlenmiş olduğundan emin olmak için doğrulama yordamları tasarlayıp geliştirin ve uygulayın. Azure Veri Gezgini, kümeler arası birleştirmeleri destekler. Tablolar arasında basit bir sayı veya satır doğrulamaya yardımcı olabilir.
- Sürüm yordamları, kümelerin yansıtılmasını sağlayan idare denetimleri ve dengeleri içermelidir.
- Sıfırdan küme oluşturmak için gerekenlerden tam olarak daha iyi anlayın.
- Dağıtım birimleri için bir denetim listesi oluşturun. Listenize ihtiyaçlarınıza özel bir liste olacaktır ancak şunları içermelidir: dağıtım betikleri, alım bağlantıları, BI araçları ve diğer önemli yapılandırmalar.