Aracılığıyla paylaş

Azure Tablo Depolama'da güvenilirlik

Azure Tablo Depolama , yapılandırılmış NoSQL verilerini bulutta depolayan bir hizmettir. Her bir varlığa bir anahtar aracılığıyla erişildiği ve bir dizi öznitelik içeren şemasız bir depo sağlar. Tek bir tablo, farklı özellik kümelerine sahip varlıklar içerebilir ve özellikler çeşitli veri türlerinden oluşabilir.

Azure'ı kullandığınızda güvenilirlik paylaşılan bir sorumluluktır. Microsoft, dayanıklılık ve kurtarmayı desteklemek için çeşitli özellikler sunar. Bu özelliklerin kullandığınız tüm hizmetler içinde nasıl çalıştığını anlamak ve iş hedeflerinize ve çalışma süresi hedeflerinize ulaşmak için ihtiyacınız olan özellikleri seçmek sizin sorumluluğunuzdadır.

Bu makalede, Tablo Depolama'nın geçici hatalar, kullanılabilirlik alanı kesintileri ve bölge kesintileri gibi çeşitli olası kesintilere ve sorunlara karşı nasıl dayanıklı hale getirilmeye başlandığı açıklanmaktadır. Ayrıca, diğer sorun türlerinden kurtarmak için yedeklemeleri nasıl kullanabileceğinizi açıklar ve Tablo Depolama hizmet düzeyi sözleşmesi (SLA) hakkındaki bazı önemli bilgileri vurgular.

Uyarı

Tablo Depolama, Azure Depolama platformunun bir parçasıdır. Tablo Depolama'nın bazı özellikleri birçok Azure Depolama hizmetinde ortaktır. Bu makalede, bu yaygın özelliklere başvurmak için Azure Depolama'yı veya Depolama'yı kullanacağız.

Güvenilirlik için üretim dağıtımı önerileri

Üretim ortamları için aşağıdaki eylemleri gerçekleştirin:

  • Tablo Depolama kaynaklarını içeren depolama hesapları için alanlar arası yedekli depolamayı (ZRS) etkinleştirin. ZRS, verilerinizi birincil bölgedeki birden çok kullanılabilirlik alanına zaman uyumlu olarak çoğaltarak daha yüksek kullanılabilirlik sağlar. Bu çoğaltma kullanılabilirlik alanı hatalarına karşı koruma sağlar.

  • Bölge kesintilerine karşı dayanıklı olmanız gerekiyorsa ve depolama hesabınızın birincil bölgesi eşleştirildiyse, eşleştirilmiş bölgeye zaman uyumsuz olarak verileri çoğaltmak için coğrafi olarak yedekli depolamayı (GRS) etkinleştirmeyi göz önünde bulundurun. Desteklenen bölgelerde, coğrafi alanlar arası yedekli depolama (GZRS) kullanarak coğrafi yedekliliği bölge yedekliliğiyle birleştirebilirsiniz.

  • Yüksek ölçekli üretim iş yükleri için veya yüksek dayanıklılık gereksinimleriniz varsa Tablo için Azure Cosmos DB'yi kullanmayı göz önünde bulundurun. Tablo için Azure Cosmos DB, Tablo Depolama için yazılmış uygulamalarla uyumludur. Yüksek ölçekte düşük gecikme süreli okuma ve yazma işlemlerini destekler ve esnek tutarlılık modelleriyle birden çok bölgede güçlü bir genel dağıtım sağlar. Ayrıca uygulamanızın dayanıklılığını ve performansını geliştiren yerleşik yedekleme ve diğer özellikleri de sağlar.

Güvenilirlik mimarisine genel bakış

Tablo Depolama, Azure Depolama platformu altyapısı içinde dağıtılmış bir NoSQL veritabanı olarak çalışır. Hizmet, tablo verilerinizin birden çok kopyası aracılığıyla yedeklilik sağlar ve belirli yedeklilik modeli depolama hesabı yapılandırmanıza bağlıdır.

Yerel olarak yedekli depolama (LRS), depolama hesaplarınızdaki verileri seçtiğiniz birincil bölgede bulunan bir veya daha fazla Azure kullanılabilirlik alanına çoğaltır. Tercih ettiğiniz kullanılabilirlik alanını seçme seçeneği olmasa da Azure, yük dengelemeyi geliştirmek için LRS hesaplarını bölgeler arasında taşıyabilir veya genişletebilir. Verilerinizin bölgelere yayılacağının garantisi yoktur. Kullanılabilirlik alanları hakkında daha fazla bilgi için bkz. Kullanılabilirlik Alanları nelerdir?.

Kullanılabilirlik alanlarında verilerin LRS kullanılarak nasıl çoğaltıldığını gösteren diyagram.

Alanlar arası yedekli depolama (ZRS), coğrafi olarak yedekli depolama (GRS) ve coğrafi alanlar arası yedekli depolama (GZRS) ek korumalar sağlar. Bu makalede bu seçenekler ayrıntılı olarak açıklanmaktadır.

Geçici hatalara dayanıklılık

Geçici hatalar, bileşenlerde kısa ve aralıklı hatalardır. Bunlar genellikle bulut gibi dağıtılmış bir ortamda gerçekleşir ve işlemlerin normal bir parçasıdır. Geçici hatalar kısa bir süre sonra kendilerini düzeltmektedir. Uygulamalarınızın genellikle etkilenen istekleri yeniden deneyerek geçici hataları işleyebileceği önemlidir.

Bulutta barındırılan tüm uygulamalar, bulutta barındırılan API'ler, veritabanları ve diğer bileşenlerle iletişim kurarken Azure geçici hata işleme yönergelerini izlemelidir. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

Tablo Depolama istemci kitaplıkları ve SDK'ları ağ zaman aşımları, geçici hizmet kullanılamaması (HTTP 503), azaltma yanıtları (HTTP 429) ve bölüm sunucusu aşırı yükleme koşulları gibi yaygın geçici hataları otomatik olarak işleyen yerleşik yeniden deneme ilkeleri içerir. Uygulamanız bu geçici koşullarla karşılaştığında, istemci kitaplıkları üstel geri alma stratejilerini kullanarak işlemleri otomatik olarak yeniden dener.

Tablo Depolama'yı kullanırken geçici hataları etkili bir şekilde yönetmek için aşağıdaki eylemleri gerçekleştirin:

  • Yanıt hızını geçici yavaşlamalara dayanıklılıkla dengelemek için Tablo Depolama istemcinizde uygun zaman aşımlarını yapılandırın. Azure Depolama istemci kitaplıklarındaki varsayılan zaman aşımları genellikle çoğu senaryo için uygundur.

  • Özellikle uygulamanız HTTP 503 sunucusu meşgul veya HTTP 500 işlem zaman aşımı hatalarıyla karşılaştığında, yeniden deneme ilkeleri için üstel geri alma uygulayın. Tablo Depolama, tek tek bölümler sık olduğunda veya depolama hesabı sınırlarına yaklaşıldığında istekleri kısıtlayabilir.

  • Yüksek ölçekli uygulamalarda bölüme duyarlı yeniden deneme mantığı tasarlama. Bölüme duyarlı yeniden deneme mantığı, Tablo Depolama'da bölümlenmiş mimariyi dikkate alan ve tek tek bölüm sunucularında azaltmayla karşılaşma olasılığını azaltmak için işlemleri birden çok bölüme dağıtan daha gelişmiş bir yaklaşımdır.

Tablo Depolama mimarisi ve dayanıklı ve yüksek ölçekli uygulamalar tasarlama hakkında daha fazla bilgi edinmek için bkz. Tablo Depolama için performans ve ölçeklenebilirlik denetim listesi.

Kullanılabilirlik alanı hatalarına dayanıklılık

Kullanılabilirlik alanları , bir Azure bölgesi içindeki veri merkezlerinin fiziksel olarak ayrı gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.

Tablo Depolama, ZRS yapılandırmasıyla dağıttığınızda alanlar arası yedeklidir. Yerel olarak yedekli depolamanın (LRS) aksine ZRS, Azure'ın tablo verilerinizi birden çok kullanılabilirlik alanında zaman uyumlu bir şekilde çoğaltmasını garanti eder. Bu yapılandırma, kullanılabilirlik bölgesinin tamamı kullanılamaz duruma gelse bile tablolarınızın erişilebilir kalmasını sağlar. Hizmet yazma işlemini tamamlamadan önce tüm yazma işlemlerinin birden çok bölgede kabul edilmesi gerekir ve bu da güçlü tutarlılık garantileri sağlar.

Alanlar arası yedeklilik, depolama hesabı düzeyinde etkinleştirilir ve bu hesaptaki tüm Tablo Depolama kaynakları için geçerlidir. Ayar tüm depolama hesabı için geçerli olduğundan, farklı yedeklilik düzeyleri için tek tek varlıkları yapılandıramazsınız. Kullanılabilirlik alanında kesinti yaşandığında, Azure Depolama sizin veya uygulamanızın herhangi bir müdahalesine gerek kalmadan istekleri otomatik olarak sağlıklı bölgelere yönlendirir.

Verilerin birincil bölgede alanlar arası yedekli depolama (ZRS) ile nasıl çoğaltıldığını gösteren diyagram.

Gereksinimler

  • Depolama hesabı türleri: Tablo Depolama için ZRS'yi etkinleştirmek için Standart genel amaçlı v2 depolama hesabı kullanmanız gerekir. Premium depolama hesapları Tablo Depolama'yı desteklemez.

Maliyet

Alanlar arası yedekli depolamayı (ZRS) etkinleştirdiğinizde, ek çoğaltma ve depolama yükü nedeniyle yerel olarak yedekli depolamadan (LRS) farklı bir ücretlendirilirsiniz.

Ayrıntılı fiyatlandırma bilgileri için bkz. Tablo Depolama fiyatlandırması.

Kullanılabilirlik alanı desteğini yapılandırma

  • Alanlar arası yedekli depolama hesabı ve tablosu oluşturun:

    1. Depolama hesabı oluşturun. Yedeklilik seçeneği olarak ZRS, GZRS veya okuma erişimli coğrafi olarak yedekli depolama (RA-GZRS) seçeneğini belirlediğinizden emin olun.

    2. Tablo oluşturun.

  • Çoğaltma türünü değiştirin. Mevcut depolama hesabını alanlar arası yedekli depolama (ZRS) olarak değiştirme ve yapılandırma seçenekleri ve gereksinimleri hakkında bilgi edinmek için bkz. Depolama hesabının çoğaltılması şeklini değiştirme.

  • Alanlar arası yedekliliği devre dışı bırakın. Aynı yedeklilik yapılandırma değişikliği işlemini kullanarak ZRS hesaplarını yerel olarak yedekli depolama (LRS) gibi bölgesel olmayan bir yapılandırmaya dönüştürün.

Tüm bölgeler sağlıklı olduğunda davranış

Bu bölümde, bir Tablo Depolama hesabı alanlar arası yedeklilik için yapılandırıldığında ve tüm kullanılabilirlik alanları çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Bölgeler arasında trafik yönlendirme: Alanlar arası yedekli depolama (ZRS) ile Azure Depolama, istekleri birden çok kullanılabilirlik alanındaki depolama kümelerine otomatik olarak dağıtır. Trafik dağıtımı uygulamalar için saydamdır ve istemci tarafı yapılandırması gerektirmez.

  • Bölgeler arasında veri çoğaltma: ZRS'ye yapılan tüm yazma işlemleri, bölgedeki tüm kullanılabilirlik alanlarında zaman uyumlu olarak çoğaltılır. Verileri karşıya yüklediğinizde veya değiştirdiğinizde, veriler tüm kullanılabilirlik alanlarında başarıyla çoğaltılana kadar işlem tamamlanmış olarak kabul edilmez. Bu senkron replikasyon, bölge hataları sırasında güçlü tutarlılık ve sıfır veri kaybı sağlar.

Bölge hatası sırasındaki davranış

Kullanılabilirlik alanı kullanılamaz duruma geldiğinde, Tablo Depolama aşağıdaki davranışlarla yanıt vererek yük devretme işlemini otomatik olarak işler:

  • Algılama ve yanıt: Microsoft, bölge hatalarını otomatik olarak algılar ve kurtarma işlemlerini başlatır. Alanlar arası yedekli depolama (ZRS) hesapları için müşteri eylemi gerekmez. Bir bölge kullanılamaz duruma gelirse Azure, Etki Alanı Adı Sistemi (DNS) yeniden noktası oluşturma gibi ağ güncelleştirmelerini üstlenir.
  • Bildirim: Bir bölge kapatıldığında Microsoft sizi otomatik olarak bilgilendirmez. Ancak, tek bir kaynağın durumunu izlemek için Azure Kaynak Durumu'nı kullanabilir ve sorunları size bildirmek için Kaynak Durumu uyarıları ayarlayabilirsiniz. Azure Hizmet Durumu'nı , bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için de kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

  • Etkin istekler: Kurtarma işlemi sırasında uçuş içi istekler bırakılabilir ve yeniden denenmelidir. Uygulamalar bu geçici kesintileri işlemek için yeniden deneme mantığı uygulamalıdır .

  • Beklenen veri kaybı: Yazma işlemleri tamamlanmadan önce veriler birden çok bölgede zaman uyumlu olarak çoğaltıldığı için bölge hataları sırasında veri kaybı olmaz.

  • Beklenen kapalı kalma süresi: Trafik iyi durumdaki bölgelere yönlendirildiğinden otomatik kurtarma sırasında genellikle birkaç saniyelik kısa bir kapalı kalma süresi oluşabilir. ZRS için uygulamalar tasarlarken, üstel geri alma ile yeniden deneme ilkeleri uygulama da dahil olmak üzere geçici hata işleme uygulamalarını izleyin.

  • Trafik yeniden yönlendirme: Bir bölge kullanılamaz duruma gelirse Azure, isteklerin kalan iyi durumdaki kullanılabilirlik alanlarına yönlendirilmesi için Etki Alanı Adı Sistemi (DNS) yeniden noktası oluşturma gibi ağ güncelleştirmelerini üstlenir. Hizmet, iyi durumdaki bölgeleri kullanarak tüm işlevleri korur ve müşteri müdahalesi gerektirmez.

Bölge kurtarma

Başarısız kullanılabilirlik alanı kurtarıldığında, Azure Depolama tüm kullanılabilirlik alanlarındaki normal işlemleri otomatik olarak geri yükler. Hizmet, kesinti süresi boyunca gerçekleşen tüm işlemleri eşitleyerek veri tutarlılığını otomatik olarak güvence altına alır.

Bölge hataları için test

Alanlar arası yedekli depolama (ZRS) kullandığınızda, Azure Depolama çoğaltma, trafik yönlendirme ve bölge aşağı yanıtlarını otomatik olarak yönetir. Bu özellik tam olarak yönetildiği için kullanılabilirlik alanı hata işlemlerini başlatmanız veya doğrulamanız gerekmez.

Bölge genelindeki hatalara dayanıklılık

Azure Blob Depolama, Azure Dosyalar, Azure Tablo Depolama ve Azure Kuyruk Depolama dahil olmak üzere Azure Depolama, farklı gereksinimlere uygun bir dizi coğrafi yedeklilik ve yük devretme özelliği sağlar.

Önemli

Coğrafi olarak yedekli depolama (GRS) yalnızca Eşleştirilmiş Azure bölgelerinde çalışır. Depolama hesabınızın bölgesi eşleştirilmezse dayanıklılık için özel çok bölgeli çözümleri kullanmayı göz önünde bulundurun.

Eşleştirilmiş bölgeler için coğrafi olarak yedekli depolama

Azure Depolama, eşleştirilmiş bölgelerde çeşitli grs türleri sağlar. Hangi GRS türünü kullanırsanız kullanın, ikincil bölgedeki veriler her zaman yerel olarak yedekli depolama (LRS) kullanılarak çoğaltılır. Bu yaklaşım, ikincil bölge içindeki donanım hatalarına karşı koruma sağlar.

Yük devretme türleri

Azure Depolama, farklı senaryolar için üç tür yük devretmeyi destekler.

  • Müşteri tarafından yönetilen planlanmamış yük devretme: Birincil bölgenizde bölge genelinde bir depolama hatası varsa kurtarma başlatma sizin sorumluluğunuzdadır.

  • Müşteri tarafından yönetilen planlı yük devretme: Çözümünüzün başka bir bölümünde birincil bölgenizde bir hata varsa ve tüm çözümünüzü ikincil bölgeye geçmeniz gerekiyorsa kurtarmayı başlatma sorumluluğu size aittir. Depolama birincil bölgede hala çalışıyorken, ancak siz tüm çözümünüzü bir ikincil bölgeye devretmelisiniz, uyumluluk ve denetim gereksinimlerini sağlamak için tasarlanmış olağanüstü durum kurtarma tatbikatları gibi çözümünüzün tamamını bir ikincil bölgeye devretmeniz gerektiğinde planlı yük devretmeyi kullanın.

  • Microsoft tarafından yönetilen yük devretme: Olağanüstü durumlarda, Microsoft bir bölgedeki tüm coğrafi olarak yedekli depolama (GRS) hesapları için yük devretme başlatabilir. Ancak, Microsoft tarafından yönetilen yük devretme son çaredir ve yalnızca uzun bir kesinti süresinden sonra gerçekleştirilmesi beklenir. Microsoft tarafından yönetilen yedekleme sistemine güvenmemelisiniz.

GRS hesapları bu yük devretme türlerinden herhangi birini kullanabilir. Önceden yük devretme türlerinden herhangi birini kullanmak için bir depolama hesabını önceden yapılandırmanız gerekmez.

Gereksinimler

  • Bölge desteği: Azure Depolama coğrafi olarak yedekli yapılandırmalar, ikincil bölge çoğaltması için Azure eşleştirilmiş bölgeleri kullanır. İkincil bölge, birincil bölge seçiminize göre otomatik olarak belirlenir ve özelleştirilemiyor. Eşleştirilmiş Azure bölgelerinin tam listesi için bkz. Azure bölgeleri listesi.

    Depolama hesabınızın bölgesi eşleştirilmezse dayanıklılık için özel çok bölgeli çözümleri kullanmayı göz önünde bulundurun.

  • Depolama hesabı türleri: Coğrafi olarak yedekli depolama (GRS) ve müşteri tarafından başlatılan yük devretme ve yeniden çalışma, genel amaçlı v2 Azure Depolama hesaplarını destekleyen tüm Azure eşleştirilmiş bölgelerinde kullanılabilir.

Değerlendirmeler

Çok bölgeli Tablo Depolama'yı uygularken aşağıdaki önemli faktörleri göz önünde bulundurun:

  • Zaman uyumsuz çoğaltma gecikme süresi: İkincil bölgeye veri çoğaltma zaman uyumsuzdur; bu da verilerin birincil bölgeye yazıldığı zaman ile ikincil bölgede kullanılabilir duruma gelmesi arasında bir gecikme olduğu anlamına gelir. Bu gecikme, son veriler çoğaltılmadan önce birincil bölge hatası oluşursa olası veri kaybına neden olabilir. Veri kaybı, kurtarma noktası hedefi (RPO) tarafından ölçülür. Çoğaltma gecikmesinin 15 dakikadan kısa olmasını bekleyebilirsiniz, ancak bu süre bir tahmindir ve garanti değildir.

    Depolama hesabınızın planlanmamış bir yük devretmesi varsa ne kadar verinin kaybedilebileceğini anlamak için Son Eşitleme Zamanı özelliğini de kontrol edebilirsiniz.

  • İkincil bölge erişimi: Coğrafi olarak yedekli depolama (GRS) ve coğrafi alanlar arası yedekli depolama (GZRS) yapılandırmalarıyla, yük devretme gerçekleşene kadar ikincil bölgeye okuma için erişilemez.

    okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) ve okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) yapılandırmaları normal işlemler sırasında ikincil bölgeye okuma erişimi sağlar, ancak zaman uyumsuz çoğaltma gecikme süresi nedeniyle biraz eski veriler döndürebilir.

  • Özellik sınırlamaları: Coğrafi olarak yedekli depolama (GRS) veya müşteri tarafından yönetilen yük devretme kullandığınızda bazı Azure Depolama özellikleri desteklenmez veya sınırlamalara sahiptir. Coğrafi yedeklilik uygulamadan önce özellik uyumluluğunu gözden geçirin.

Maliyet

Çok bölgeli Azure Depolama hesabı yapılandırmaları, bölgeler arası çoğaltma ve ikincil bölgedeki depolama için ek maliyetler doğurabilir. Azure bölgeleri arasında veri aktarımı, standart bölgeler arası bant genişliği oranlarına göre ücretlendirilir.

Ayrıntılı fiyatlandırma bilgileri için bkz. Tablo Depolama fiyatlandırması.

Çok bölgeli desteği yapılandırma

  • Yeni bir coğrafi olarak yedekli depolama (GRS) hesabı oluşturun. GRS hesabı oluşturmak için bkz . Depolama hesabı oluşturma ve hesap oluşturma sırasında GRS, okuma erişimli coğrafi olarak yedekli depolama (RA-GRS), coğrafi alanlar arası yedekli depolama (GZRS) veya okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) seçeneğini belirleyin.

  • Mevcut bir depolama hesabında coğrafi yedekliliği etkinleştirin. Mevcut depolama hesabını coğrafi olarak yedekli depolamaya (GRS) dönüştürmek için bkz. Depolama hesabının çoğaltılması şeklini değiştirme.

    Uyarı

    Hesabınız coğrafi olarak yedeklilik için yeniden yapılandırıldıktan sonra, yeni birincil bölgedeki mevcut verilerin yeni ikincil bölgeye tam olarak kopyalanmış olması önemli ölçüde zaman alabilir.

    Büyük bir veri kaybını önlemek için planlanmamış bir yük devretme başlatmadan önce Son Eşitleme Zamanı özelliğinin değerini denetleyin. Olası veri kaybını değerlendirmek için, son eşitleme zamanını verilerin yeni birincil bölgeye yazıldığı son zamanla karşılaştırın.

  • Coğrafi yedekliliği devre dışı bırakın. Aynı yedeklilik yapılandırması değişiklik işlemini kullanarak GRS hesaplarını yerel olarak yedekli depolama (LRS) veya alanlar arası yedekli depolama (ZRS) gibi tek bölgeli yapılandırmalara dönüştürün.

Tüm bölgeler iyi durumda olduğunda davranış

Bu bölümde, bir depolama hesabı coğrafi olarak yedeklilik için yapılandırıldığında ve tüm bölgeler çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Bölgeler arasında trafik yönlendirme: Azure Depolama, tüm yazma işlemlerinin ve çoğu okuma işleminin birincil bölgeye yönlendirildiği etkin-pasif bir yaklaşım kullanır.

    Okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) ve okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) yapılandırmaları için, uygulamalar ikincil uç noktaya erişerek isteğe bağlı olarak ikincil bölgeden okuyabilir. Bu yaklaşım açık uygulama yapılandırması gerektirir ve otomatik değildir. Ayrıca, zaman uyumsuz çoğaltma gecikmesi nedeniyle ikincil bölgedeki veriler biraz eski olabilir.

  • Bölgeler arasında veri çoğaltma: Yazma işlemleri ilk olarak aşağıdaki yapılandırılmış yedeklilik türleri kullanılarak birincil bölgeye işlenir:

    • Coğrafi olarak yedekli depolama (GRS) ve RA-GRS için yerel olarak yedekli depolama (LRS)
    • Coğrafi alanlar arası yedekli depolama (GZRS) ve RA-GZRS için alanlar arası yedekli depolama (ZRS)

    Birincil bölgede başarıyla tamamlandıktan sonra veriler, LRS kullanılarak depolandığı ikincil bölgeye zaman uyumsuz olarak çoğaltılır.

    Bölgeler arası çoğaltmanın zaman uyumsuz yapısı, verilerin birincil bölgeye yazıldığında ve ikincil bölgede kullanılabilir olması arasında genellikle bir gecikme süresi olduğu anlamına gelir. Son Eşitleme Zamanı özelliğini kullanarak çoğaltma süresini izleyebilirsiniz.

Bölge hatası sırasındaki davranış

Bu bölümde, depolama hesabı coğrafi olarak yedeklilik için yapılandırıldığında ve birincil bölgede bir kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Müşteri tarafından yönetilen yük devretme (planlanmamış): Birincil bölgedeki depolama kullanılamıyorsa planlanmamış bir yük devretme kullanın.

    • Algılama ve yanıt: Depolama hesabınızın birincil bölgenizdeki kullanılabilir olmama olasılığı düşük durumlarda müşteri yönetimli planlanmamış bir yük devretme gerçekleştirebilirsiniz. Bu kararı vermek için aşağıdaki faktörleri göz önünde bulundurun:

      • Azure Kaynak Durumu'nda birincil bölgenizdeki depolama hesabına erişim sorunlarının gösterilip gösterilmediği

      • Microsoft'un başka bir bölgeye yük devretme gerçekleştirmenizi önerip önermediği

      Uyarı

      Planlanmamış bir yük devretme veri kaybına neden olabilir. Müşteri tarafından yönetilen bir yük devretmeyi başlatmadan önce, hizmetin geri yüklenmesinin veri kaybı riskini gerekçelendirmesine karar verin.

    • Etkin istekler: Yük devretme işlemi sırasında hem birincil hem de ikincil depolama hesabı uç noktaları hem okuma hem de yazma işlemleri için geçici olarak kullanılamaz duruma gelir. Etkin olan istekler düşebilir ve yük devretme tamamlandıktan sonra istemci uygulamalarının tekrar denemeleri gerekir.

    • Beklenen veri kaybı: Zaman uyumsuz çoğaltma gecikmesi nedeniyle planlanmamış bir yük devretme sırasında veri kaybı sık görülür ve bu da son yazmaların çoğaltılmayabileceği anlamına gelir. Planlanmamış yük devretme sırasında ne kadar veri kaybolabileceğini anlamak için Son Eşitleme Zamanı özelliğini de kontrol edebilirsiniz. Beklenen veri kaybı genellikle kurtarma noktası hedefi (RPO) olarak adlandırılır. Genellikle RPO'nun 15 dakikadan kısa olmasını bekleyebilirsiniz, ancak bu süre garanti değildir.

    • Beklenen kapalı kalma süresi: Beklenen kapalı kalma süresi miktarı genellikle kurtarma süresi hedefi (RTO) olarak adlandırılır. Müşteri tarafından yönetilen yük devretme, hesap boyutuna ve karmaşıklığa bağlı olarak genellikle 60 dakika içinde tamamlanır.

    • Trafik yeniden yönlendirme: Yük devretme tamamlandıktan sonra Azure, uygulamaların yeniden yapılandırılmasına gerek kalmaması için depolama hesabı uç noktalarını otomatik olarak güncelleştirir. Uygulamanız Etki Alanı Adı Sistemi (DNS) girdilerini önbelleğe alırsa, uygulamanın trafiği yeni birincil bölgeye gönderdiğinden emin olmak için önbelleği temizlemeniz gerekebilir.

    • Yük devretme sonrası yapılandırma: Planlanmamış bir yük devretme tamamlandıktan sonra hedef bölgedeki depolama hesabınız yerel olarak yedekli depolama (LRS) katmanını kullanır. Yeniden coğrafi çoğaltmanız gerekiyorsa coğrafi olarak yedekli depolamayı (GRS) yeniden etkinleştirmeniz ve verilerin yeni ikincil bölgeye çoğaltılması için beklemeniz gerekir.

    Müşteri tarafından yönetilen yük devretmeyi başlatma hakkında daha fazla bilgi için bkz. Müşteri tarafından yönetilen (planlanmamış) yük devretme nasıl çalışır ve Depolama hesabı yük devretmesi başlatma.

  • Müşteri tarafından yönetilen yük devretme (planlanan): Depolama birincil bölgede çalışır durumda kaldığında planlı yük devretme kullanın, ancak başka bir nedenle çözümünüzün tamamını ikincil bölgeye devretmeniz gerekir. Örneğin, başka bir Azure hizmeti sorun yaşıyor olabilir ve tüm çözümünüz için ikincil bir bölge kullanmaya geçmeniz gerekir. Alternatif olarak, uyumluluk ve denetim amacıyla olağanüstü durum kurtarma (DR) tatbikatı gerçekleştirmek için planlı yük devretme de kullanabilirsiniz.

    • Algılama ve yanıt: Hata devretmeye karar vermek sizin sorumluluğunuzdadır. Depolama hesabınız iyi durumda olsa bile bölgeler arasında yük devretme yapmanız gerekiyorsa genellikle bu kararı alırsınız. Örneğin, birincil bölgede kurtaramayacağınız başka bir uygulama bileşeninde büyük bir kesinti olduğunda yük devretmeyi tetikleyebilirsiniz.

    • Etkin istekler: Yük devretme işlemi sırasında hem birincil hem de ikincil depolama hesabı uç noktaları hem okuma hem de yazma işlemleri için geçici olarak kullanılamaz duruma gelir. Etkin olan istekler düşebilir ve yük devretme tamamlandıktan sonra istemci uygulamalarının tekrar denemeleri gerekir.

    • Beklenen veri kaybı: Tüm veriler eşitlendiği için yük devretme sürecinde veri kaybı beklenmez ve bu da sıfır RPO ile sonuçlanır.

    • Beklenen kapalı kalma süresi: Yük devretme genellikle 60 dakika içinde tamamlanır ve bu da hesap boyutuna ve karmaşıklığa bağlı olarak beklenen RTO'nun 60 dakika olduğu anlamına gelir. Yük devretme işlemi sırasında hem birincil hem de ikincil depolama hesabı uç noktaları hem okuma hem de yazma işlemleri için geçici olarak kullanılamaz duruma gelir.

    • Trafik yeniden yönlendirme: Yük devretme tamamlandıktan sonra Azure, uygulamaların yeniden yapılandırılmasına gerek kalmaması için depolama hesabı uç noktalarını otomatik olarak güncelleştirir. Uygulamanız DNS girdilerini önbelleğe alırsa, uygulamanın trafiği yeni birincil bölgeye gönderdiğinden emin olmak için önbelleği temizlemeniz gerekebilir.

    • Yük devretme sonrası yapılandırma: Planlı yük devretme tamamlandıktan sonra hedef bölgedeki depolama hesabınız coğrafi olarak çoğaltılmaya devam eder ve GRS katmanında kalır.

    Müşteri tarafından yönetilen yük devretmeyi başlatma hakkında daha fazla bilgi için bkz. Müşteri tarafından yönetilen (planlı) yük devretme nasıl çalışır ve Depolama hesabı yük devretmesi başlatma.

  • Microsoft tarafından yönetilen yük devretme: Microsoft'un birincil bölgenin kalıcı olarak kurtarılamaz olduğunu belirlediği büyük bir olağanüstü durum söz konusu olduğunda, ikincil bölgeye otomatik yük devretme başlatılabilir. Microsoft tüm işlemi gerçekleştirir ve müşteri eylemi gerekmez. Yük devretme gerçekleşmeden önce geçen süre, felaketin şiddetine ve durumu değerlendirmek için gereken zamana bağlıdır.

    Önemli

    DR planlarınızı geliştirmek, test etmek ve uygulamak için müşteri tarafından yönetilen yük devretme seçeneklerini kullanın. Yalnızca aşırı durumlarda kullanılabilecek Microsoft tarafından yönetilen yük devretmeye güvenmeyin. Microsoft tarafından yönetilen bir yük devretme büyük olasılıkla tüm bölge için başlatılır. Tek tek depolama hesapları, abonelikler veya müşteriler için başlatılamaz. Farklı Azure hizmetleri için farklı zamanlarda yük devretme gerçekleşebilir. Müşteri tarafından yönetilen yük devretme kullanmanızı öneririz.

Bölge geri kazanımı

Yeniden çalışma işlemi, Microsoft tarafından yönetilen ve müşteri tarafından yönetilen yük devretme senaryoları arasında önemli ölçüde farklılık gösterir.

  • Müşteri tarafından yönetilen yük devretme (planlanmamış): Planlanmamış bir yük devretmeden sonra, depolama hesabı yerel olarak yedekli depolama (LRS) ile yapılandırılır. Yeniden çalışmamak için coğrafi olarak yedekli depolama (GRS) ilişkisini yeniden kurmanız ve verilerin çoğaltılması için beklemeniz gerekir.

  • Müşteri tarafından yönetilen yük devretme (planlanan): Planlı yük devretme işleminden sonra depolama hesabı coğrafi olarak çoğaltılmış olarak kalır. Özgün birincil bölgeye geri dönmek için müşteri tarafından yönetilen başka bir yük devretme başlatabilirsiniz. Yük devretme konusunda da dikkat edilmesi gerekenler aynıdır.

  • Microsoft tarafından yönetilen yük devretme: Microsoft bir yük devretme başlatırsa, büyük olasılıkla birincil bölgede önemli bir olağanüstü durum oluştu ve birincil bölge kurtarılamayabilir. Tüm zaman çizelgeleri veya kurtarma planları bölgesel olağanüstü durum ve kurtarma çalışmalarının kapsamına bağlıdır. Azure Hizmet Durumu iletişimlerini ayrıntılar için izlemeniz önerilir.

Bölge hataları testi

Olağanüstü durum kurtarma yordamlarınızı test etmek için bölgesel hataların simülasyonunu yapabilirsiniz.

  • Planlı yük devretme testi: Coğrafi olarak yedekli depolama (GRS) hesapları için, tam yük devretme ve yeniden çalışma işlemini test etmek için bakım pencereleri sırasında planlı yük devretme işlemleri gerçekleştirebilirsiniz. Planlı yük devretme veri kaybı gerektirmez, ancak hem yük devretme hem de yeniden çalışma sırasında kapalı kalma süresini içerir.

  • İkincil uç nokta testi: Okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) ve okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) yapılandırmaları için, uygulamanızın ikincil bölgeden verileri başarıyla okuya çalıştığından emin olmak için okuma işlemlerini ikincil uç noktaya göre düzenli olarak test edin.

Dayanıklılık için özel çok bölgeli çözümler

Aşağıdaki nedenlerden dolayı Azure Depolama'nın bölgeler arası yük devretme özellikleri uygun olmayabilir:

  • Depolama hesabınız eşleştirilmemiş bir bölgede.

  • İş çalışma süresi hedefleriniz, yerleşik yük devretme seçeneklerinin sağladığı kurtarma süresinden veya veri kaybından memnun değildir.

  • Birincil bölgenizin çifti olmayan bir bölgeye yük devretmelisiniz.

  • Bölgeler arasında aktif/aktif bir yapılandırmaya ihtiyacınız vardır.

Bu bölümde dikkate alınması gereken bazı yaklaşımlara üst düzey bir genel bakış sağlanır. Azure Depolama için çok bölgeli dağıtım topolojilerine kapsamlı bir genel bakış bu makalenin kapsamı dışındadır.

Uyarı

Tablo Depolama kullanmak üzere oluşturulmuş uygulamalar için Tablo için Azure Cosmos DB kullanmayı göz önünde bulundurun. Tablo için Azure Cosmos DB, istenmeyen bölgeler için destek de dahil olmak üzere gelişmiş çok bölgeli gereksinimleri destekler. Tablo Depolama için oluşturulan uygulamalarla uyumluluk için de tasarlanmıştır.

Her bölgede ayrı depolama hesapları kullanarak Azure Depolama'yı birden çok bölgeye dağıtabilirsiniz. Bu yaklaşım bölge seçiminde esneklik, istenmeyen bölgeleri kullanma olanağı ve çoğaltma zamanlaması ve veri tutarlılığı üzerinde daha ayrıntılı denetim sağlar. Bölgeler arasında birden çok depolama hesabı uyguladığınızda bölgeler arası veri çoğaltmayı yapılandırmanız, yük dengeleme ve yük devretme ilkeleri uygulamanız ve bölgeler arasında veri tutarlılığı sağlamanız gerekir.

Tablo Depolama için, birden çok hesaplı bir yaklaşım veri dağıtımını yönetmenizi, çakışma çözümlemesi de dahil olmak üzere bölgeler arasında tablolar arasındaki eşitlemeyi işlemenizi ve özel yük devretme mantığı uygulamanızı gerektirir.

Yedekleme ve geri yükleme

Tablo Depolama, belirli bir noktaya geri yükleme (PITR) gibi geleneksel yedekleme özellikleri sağlamaz. Ancak, tablo verileri için özel yedekleme stratejileri uygulayabilirsiniz.

Yerleşik yedekleme özelliklerine ihtiyacınız varsa, hem düzenli hem de sürekli yedeklemeler için destek sağlayan Tablo için Azure Cosmos DB'ye geçmeyi göz önünde bulundurun. Daha fazla bilgi için bkz . Azure Cosmos DB'de çevrimiçi yedekleme ve isteğe bağlı veri geri yükleme.

Tablo Depolama'dan veri yedeklemesi gerektiren senaryolar için aşağıdaki yaklaşımları göz önünde bulundurun:

  • Azure Data Factory kullanarak dışarı aktarma. Varlıklarınızı başka bir konuma aktarmak için Tablo Depolama için Azure Data Factory bağlayıcısını kullanın. Örneğin, her varlığı Azure Blob Depolama'da depolanan bir JSON dosyasına yedekleyebilirsiniz.

  • Uygulama düzeyinde yedekleme gerçekleştirin. Daha güçlü yedekleme ve geri yükleme özellikleri için kritik tablo varlıklarını Azure SQL Veritabanı veya Azure Cosmos DB gibi diğer depolama hizmetlerine aktarmak için uygulamalarınızda özel yedekleme mantığı uygulayın.

Tablo Depolama için yedekleme stratejileri tasarlarken, verilerin bölümlenmiş doğasını göz önünde bulundurun ve yedekleme işlemlerinizin birden çok bölümü paralel olarak işleyerek büyük tabloları verimli bir şekilde işleyebileceğinden emin olun.

Çoğu çözüm için yalnızca yedeklemelere güvenmemeniz gerekir. Bunun yerine, dayanıklılık gereksinimlerinizi desteklemek için bu kılavuzda açıklanan diğer özellikleri kullanın. Ancak yedeklemeler, diğer yaklaşımların koruma altına almayan bazı risklere karşı koruma sağlar. Daha fazla bilgi için bkz. Yedeklilik, çoğaltma ve yedekleme nedir?

Hizmet düzeyi sözleşmesi

Azure Depolama için hizmet düzeyi sözleşmesi (SLA), hizmetin beklenen kullanılabilirliğini ve bu kullanılabilirlik beklentisini elde etmek için karşılanması gereken koşulları açıklar. Uygun olduğunuz kullanılabilirlik SLA'sı, depolama katmanına ve kullandığınız çoğaltma türüne bağlıdır. Daha fazla bilgi için bkz. Çevrimiçi Hizmetler için SLA'lar.

İlgili içerik

  • Last updated on