Aracılığıyla paylaş

Azure Blob Depolama'da güvenilirlik

Azure Blob Depolama , Microsoft'un bulut için bir nesne depolama çözümüdür. Metin, ikili veriler, belgeler, medya dosyaları ve uygulama yedeklemeleri gibi büyük miktarlarda yapılandırılmamış verileri depolamak için tasarlanmıştır. Temel bir Azure depolama hizmeti olan Blob Depolama, verilerinizin hem planlı hem de plansız olaylar sırasında kullanılabilir ve dayanıklı kalmasını sağlamak için birden çok güvenilirlik özelliği sağlar.

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, Blob 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 Blob Depolama hizmet düzeyi sözleşmesi (SLA) hakkındaki bazı önemli bilgileri vurgular.

Uyarı

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

Üretim dağıtımı önerileri

Çözümünüzün güvenilirlik gereksinimlerini desteklemek için Blob Depolama'nın nasıl dağıtılacağı ve güvenilirliğin mimarinizin diğer yönlerini nasıl etkilediği hakkında bilgi edinmek için bkz. Azure Well-Architected Framework'te Blob Depolama için en iyi mimari yöntemleri .

Güvenilirlik mimarisine genel bakış

Azure Depolama, verilerinizi farklı hata türlerine karşı korumanıza yardımcı olmak için çeşitli yedeklilik seçenekleri sunar. Her seçenek belirli bir veri yedekliliği düzeyi sağlar, böylece uygulamanızın gereksinimlerine en uygun düzeyi seçebilirsiniz.

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.

Blob Depolama'yı kullanırken geçici hataları etkili bir şekilde yönetmek için aşağıdaki önerileri uygulayın:

  • Üstel geri alma ve değişim ile yerleşik yeniden deneme ilkeleri içeren Azure Depolama istemci kitaplıklarını kullanın. .NET, Java, Python ve JavaScript SDK'ları geçici hatalar için yeniden denemeleri otomatik olarak işler. Yapılandırma seçeneklerini yeniden deneme hakkında daha fazla bilgi için bkz. .NET ile yeniden deneme ilkesi uygulama.

  • Blob boyutuna ve ağ koşullarına göre blob işlemleriniz için uygun zaman aşımı değerlerini yapılandırın. Daha büyük bloblar daha uzun zaman aşımları gerektirir, ancak daha küçük işlemler hataları hızla algılamak için daha kısa değerler kullanabilir.

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.

Blob Depolama, verilerinizi bir bölgedeki birden çok kullanılabilirlik alanına otomatik olarak dağıtan ZRS yapılandırmaları aracılığıyla güçlü kullanılabilirlik alanı desteği sağlar. Yerel olarak yedekli depolamadan (LRS) farklı olarak ZRS, Azure'ın blob 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.

Alanlar arası yedeklilik depolama hesabı düzeyinde etkinleştirilir ve bu hesaptaki tüm blob kapsayıcıları için geçerlidir. Tek tek kapsayıcılar için farklı yedeklilik düzeyleri ayarlayamazsınız. Yedeklilik yapılandırması depolama hesabının tamamına uygulanır. Kullanılabilirlik alanında kesinti yaşandığında Azure Depolama, istekleri sizin veya uygulamanızın müdahalesine gerek kalmadan 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: Alanlar arası yedeklilik hem Standart genel amaçlı v2 hem de Premium Blok Blobu depolama hesabı türleri için kullanılabilir. Blok blobları, ekleme blobları ve sayfa bloblarının tümü alanlar arası yedekli yapılandırmaları destekler, ancak hangi özelliklerin kullanılabilir olduğunu kullandığınız depolama hesabı türü belirler. Daha fazla bilgi için bkz . Desteklenen depolama hesabı türleri.

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.

Daha fazla bilgi için bkz. Blob Depolama fiyatlandırması.

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

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

  • Ç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 blob 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ış

Bu bölümde, bir blob depolama hesabı ZRS için yapılandırıldığında ve kullanılabilirlik alanı kesintisi olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • 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: Kullanılabilirlik alanı çevrimdışı olursa Azure, Etki Alanı Adı Sistemi (DNS) yeniden belirleme gibi ağ değişikliklerini başlatır. Bu güncelleştirmeler trafiğin kalan iyi durumdaki kullanılabilirlik alanlarına yeniden yönlendirilmesini sağlar. Hizmet, hayatta kalan 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 Blob Depolama uygularken aşağıdaki temel 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.

Daha fazla bilgi için bkz. Blob 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.

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.

Nesne çoğaltma , depolama hesapları arasında blok bloblarının zaman uyumsuz olarak kopyalanmasını sağlayan bölgeler arası veri çoğaltma için ek bir seçenek sağlar. Sabit eşleştirilmiş bölgeleri kullanan yerleşik coğrafi olarak yedekli depolama seçeneklerinden farklı olarak, nesne çoğaltma, herhangi bir Azure bölgesindeki depolama hesapları arasında (istenmeyen bölgeler de dahil) verileri çoğaltmanıza olanak tanır. Bu yaklaşım, kaynak ve hedef bölgeler, çoğaltma ilkeleri ve çoğaltılması gereken belirli kapsayıcılar ve blob ön ekleri üzerinde tam denetim sağlar.

Nesne çoğaltmayı, blob ön eklerine ve etiketlerine göre bir kapsayıcı içindeki tüm blobları veya belirli alt kümeleri çoğaltacak şekilde yapılandırabilirsiniz. Çoğaltma zaman uyumsuzdur ve arka planda gerçekleşir. Karmaşık çok bölgeli topolojiler oluşturmak için birden çok çoğaltma ilkesi yapılandırabilir ve hatta birden çok depolama hesabı arasında çoğaltmayı zincirleyebilirsiniz.

Nesne çoğaltma tüm depolama hesaplarıyla uyumlu değildir. Örneğin, hiyerarşik ad alanları ( Azure Data Lake Storage 2. Nesil hesapları olarak da bilinir) kullanan depolama hesaplarıyla çalışmaz.

Daha fazla bilgi için bkz . Blok blobları için nesne çoğaltma ve Nesne çoğaltmayı yapılandırma.

Yedekleme ve kurtarma

Blob Depolama, kapsamlı yedekleme stratejileri için yedekliliği tamamlayan birden çok veri koruma mekanizması sağlar. Hizmetin yerleşik yedekliliği altyapı hatalarına karşı koruma sağlar ve ek yedekleme özellikleri yanlışlıkla silme, bozulma ve kötü amaçlı etkinliklere karşı koruma sağlar.

Belirli bir noktaya geri yükleme (PITR), blok blobu verilerini 365 güne kadar yapılandırılmış saklama süresi içinde önceki bir duruma geri yüklemenize olanak tanır. Microsoft bu özelliği tamamen yönetir. Ayrıca kapsayıcı veya blob düzeyinde ayrıntılı kurtarma özellikleri sağlar. PITR verileri kaynak hesapla aynı bölgede depolanır ve coğrafi olarak yedekli yapılandırmalar kullanıyorsanız bölgesel kesintiler sırasında bile erişilebilir.

Blob sürümü oluşturma , değiştirildiğinde veya silindiğinde blobların önceki sürümlerini otomatik olarak korur. Her sürüm ayrı bir nesne olarak depolanır ve bağımsız olarak erişilebilir. Sürümler geçerli blobla aynı bölgede depolanır ve depolama hesabıyla aynı yedeklilik yapılandırmasını izler.

Geçici silme , silinen verileri yapılandırılabilir bir süre boyunca tutarak yanlışlıkla silinen bloblar ve kapsayıcılar için bir güvenlik ağı sağlar. Geçici olarak silinen veriler aynı depolama hesabında ve bölgede kalır ve bu da kurtarma için hemen kullanılabilir olmasını sağlar. Coğrafi olarak yedekli hesaplar için geçici olarak silinen veriler de ikincil bölgeye çoğaltılır.

Blob anlık görüntüleri , yedekleme ve kurtarma senaryoları için kullanabileceğiniz blobların salt okunur, belirli bir noktaya kopyalarını oluşturur. Anlık görüntüler aynı depolama hesabında depolanır ve temel blob ile aynı yedeklilik ve coğrafi çoğaltma ayarlarını izler.

Bölgeler arası yedekleme gereksinimleri için, merkezi yedekleme yönetimi sağlayan ve yedekleme verilerini kaynak verilerden farklı bölgelerde depolayan bloblar için Azure Backup'ı kullanmayı göz önünde bulundurun. Bu hizmet, yapılandırılabilir bekletme ilkeleri ve geri yükleme özelliklerine sahip operasyonel ve kasalı yedekleme seçenekleri sağlar. Daha fazla bilgi için bkz . Bloblar için yedeklemeye genel bakış.

Ç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