Aracılığıyla paylaş

Azure Kuyruk Depolama'da güvenilirlik

Azure Kuyruk Depolama , çok sayıda iletiyi depolamaya ve dağıtmaya yönelik bir hizmettir. Kuyruk Depolama genellikle zaman uyumsuz olarak işlenmek üzere bir iş kapsamı oluşturmak için kullanılır. Gevşek bir şekilde bağlanmış uygulama mimarileri için güvenilir ileti teslimi sağlar. Kuyruk iletisinin boyutu 64 KB'a kadar olabilir ve bir kuyruk, depolama hesabının toplam kapasite sınırına kadar milyonlarca ileti içerebilir.

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, Kuyruk 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, yedeklemeleri diğer sorun türlerinden kurtarmak için nasıl kullanabileceğinizi açıklar ve Kuyruk Depolama hizmet düzeyi sözleşmesi (SLA) hakkındaki bazı önemli bilgileri vurgular.

Uyarı

Kuyruk Depolama, Azure Depolama platformunun bir parçasıdır. Kuyruk Depolama'nın bazı özellikleri birçok Azure Depolama hizmetinde ortaktır.

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

Üretim ortamları için:

  • Kuyruk 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. Daha yüksek kullanılabilirlik, depolama hesaplarınızın kullanılabilirlik alanı hatalarına karşı korunmasına yardımcı olur.

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

Gelişmiş mesajlaşma gereksinimleri için Azure Service Bus'ı kullanmayı göz önünde bulundurun. Kuyruk Depolama ile Service Bus arasındaki farklar hakkında bilgi edinmek için bkz. Azure Depolama kuyruklarını ve Service Bus kuyruklarını karşılaştırma.

Güvenilirlik mimarisine genel bakış

Kuyruk Depolama, Azure Depolama platformu altyapısında dağıtılmış bir mesajlaşma hizmeti olarak çalışır. Hizmet, kuyruğunuzun ve ileti verilerinizin birden çok kopyası aracılığıyla yedeklilik sağlar. 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.

Kuyruk Depolama, uygulamalarda yaygın olarak diğer bileşenlerdeki geçici hataları işlemelerine yardımcı olmak için kullanılır. Kuyruk Depolama gibi bir hizmetle zaman uyumsuz mesajlaşmayı kullanarak, uygulamalar iletileri daha sonra yeniden işleyerek geçici hatalardan kurtarılabilir. Daha fazla bilgi edinmek için bkz. Asynchronous Messaging Primer.

Hizmetin içinde Kuyruk Depolama, Azure Depolama platformunun ve istemci kitaplıklarının sağladığı çeşitli mekanizmaları kullanarak geçici hataları otomatik olarak işler. Hizmet, geçici altyapı sorunları sırasında bile dayanıklı ileti kuyruğa alma özellikleri sağlamak için tasarlanmıştır.

Kuyruk Depolama istemci kitaplıkları ağ zaman aşımları, geçici hizmet kullanılamaması (HTTP 503) ve azaltma yanıtları (HTTP 429) 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.

Kuyruk Depolama'yı kullanarak geçici hataları etkili bir şekilde yönetmek için aşağıdaki eylemleri gerçekleştirebilirsiniz:

  • Yanıt hızını geçici yavaşlamalara dayanıklılıkla dengelemek için Kuyruk 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.

  • Kuyruklardan gelen iletileri işlerken uygulamanızda devre kesici desenleri uygulayın. Devre kesici modelleri, alt hizmetlerde sorun olduğunda basamaklı hataları önler.

  • Uygulamanız ileti aldığında görünürlük zaman aşımlarını uygun şekilde kullanın. Görünürlük zaman aşımları, uygulamanız işleme sırasında hatalarla karşılaşırsa iletilerin yeniden deneme için kullanılabilir olmasını sağlar.

Azure Tablo Depolama mimarisi ve dayanıklı ve yüksek ölçekli uygulamalar tasarlama hakkında daha fazla bilgi edinmek için bkz. Kuyruk 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.

Azure Kuyruk Depolama, ZRS yapılandırmasıyla dağıtıldığında alanlar arası yedeklidir. LRS'nin aksine ZRS, Azure'ın kuyruk verilerinizi birden çok kullanılabilirlik alanında zaman uyumlu bir şekilde çoğaltmasını garanti eder. ZRS, bir bölgede kesinti yaşansa bile verilerinizin erişilebilir kalmasını sağlar. ZRS, tüm kullanılabilirlik alanı kullanılamaz duruma gelse bile kuyruklarınızın erişilebilir kalmasını sağlar. Tüm yazma işlemlerinin tamamlanmadan önce 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 Kuyruk Depolama kaynakları için geçerlidir. Farklı yedeklilik düzeyleri için tek tek kuyrukları yapılandıramazsınız. Bu ayar tüm depolama hesabı için geçerlidir. Kullanılabilirlik alanında kesinti yaşandığında Azure Depolama, uygulamanızın 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: Kuyruk Depolama için ZRS'yi etkinleştirmek için Standart genel amaçlı v2 depolama hesabı kullanmanız gerekir. Premium depolama hesapları Kuyruk 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 . Kuyruk Depolama fiyatlandırması.

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

  • Aşağıdaki adımları uygulayarak alanlar arası yedekli bir depolama hesabı ve kuyruğu oluşturun.

    1. Bir depolama hesabı oluşturun ve hesap oluşturma sırasında yedeklilik seçeneği olarak ZRS, GZRS veya okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) seçeneğini belirleyin.

    2. Kuyruk 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 kuyruk 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 Kuyruk Depolama aşağıdaki eylemleri gerçekleştirerek 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önlendiriliyor. 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 belirleme gibi ağ güncelleştirmelerini üstlenir. Hizmet, müşteri müdahalesine gerek olmadan hayatta kalan bölgeleri kullanarak tüm işlevleri korur.

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 Kuyruk 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 . Kuyruk 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ı

Gelişmiş çok bölgeli gereksinimler için bunun yerine, istenmeyen bölgeler için destek içeren Service Bus kullanmayı göz önünde bulundurun.

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.

Bu yaklaşım, ileti dağıtımını yönetmenizi, farklı depolama hesaplarındaki kuyruklar arasında veri eşitlemesini işlemenizi ve özel yük devretme mantığı uygulamanızı gerektirir.

Yedekleme ve geri yükleme

Kuyruk Depolama, belirli bir noktaya geri yükleme (PITR) gibi geleneksel yedekleme özellikleri sağlamaz. Bunun nedeni kuyrukların uzun süreli veri kalıcılığı yerine geçici ileti depolama için tasarlanmış olmasıdır. İletiler genellikle normal uygulama işlemleri sırasında işlenir ve kuyruklardan kaldırılır.

Yerleşik yedeklilik seçeneklerinin ötesinde ileti dayanıklılığı gerektiren senaryolar için, Blob Depolama veya Azure SQL Veritabanı gibi kalıcı bir veri deposuna kendi uygulama düzeyinde ileti günlük kaydınızı veya kalıcılığınızı uygulamayı göz önünde bulundurun. Bu yaklaşım, geçici bir ileti arabelleği ve işleme koordinasyonu amacıyla Kuyruk Depolama Alanı'nı kullanırken ileti geçmişini korumanıza olanak tanır.

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