Aracılığıyla paylaş

Azure Dosyalar'da güvenilirlik

Bu makalede Azure Dosyalar'daki güvenilirlik desteği açıklanmaktadır. Azure Dosyalar, bulutta endüstri standardı Sunucu İleti Bloğu (SMB) ve Ağ Dosya Sistemi (NFS) protokolleri aracılığıyla erişilebilen tam olarak yönetilen dosya paylaşımları 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, Azure Dosyaları'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 Azure Dosyalar hizmet düzeyi sözleşmesi (SLA) hakkında bazı önemli bilgileri vurgular.

Uyarı

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

Üretim dağıtımı önerileri

Çözümünüzün güvenilirlik gereksinimlerini desteklemek üzere Azure Dosyaları dağıtmayı ve güvenilirliğin mimarinizin diğer yönlerini nasıl etkilediğini öğrenmek için bkz. Azure Well-Architected Framework'te Azure Dosyalar için en iyi mimari yöntemleri .

Güvenilirlik mimarisine genel bakış

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.

Azure Dosyalar iki medya katmanında kullanılabilir:

  • Premium katmanı, yüksek performans için katı hal sürücüleri (SSD) kullanır. Bu katman, düşük gecikme süresi gerektiren iş yükleri için önerilir.

  • Standart katman sabit disk sürücülerini (HDD) destekler. HDD dosya paylaşımları, genel amaçlı dosya paylaşımları için uygun maliyetli bir depolama seçeneği sağlar.

Daha fazla bilgi için bkz. Azure Dosyalar - Depolama katmanlarını dağıtmayı planlama.

Azure Dosyalar depolama hesabı düzeyinde yedeklilik uygular ve dosya paylaşımları bu yedeklilik yapılandırmasını otomatik olarak devralır. Hizmet, veri koruma yaklaşımında farklılık gösteren birden çok yedeklilik modelini destekler.

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.

Azure Dosyalar kullanırken geçici hataları etkili bir şekilde yönetmek için, dosya boyutuna ve ağ koşullarına göre dosya işlemleriniz için uygun zaman aşımı değerlerini yapılandırın. Daha büyük dosyalar daha uzun zaman aşımları gerektirirken, daha küçük işlemler hataları hızla algılamak için daha kısa değerler kullanabilir.

NFS paylaşımınıza yalnızca güvenli bağlantıların kurulmasını sağlamak için depolama hesabınız için özel bir uç nokta yapılandırmanızı öneririz. Özel uç nokta, sanal ağınızın özel adres alanının içinden depolama hesabınıza statik bir IP adresi atamak için Azure Özel Bağlantı'yı kullanır. Özel uç nokta, dinamik IP adresi değişikliklerinden kaynaklanan bağlantı kesintilerini önlemeye yardımcı olur. NFS paylaşımlarınızın güvenliği hakkında daha fazla bilgi için bkz. NFS dosya paylaşımları - Güvenlik ve ağ.

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 Dosyalar iki tür kullanılabilirlik alanı desteği sağlar:

Gereksinimler

  • Bölge desteği:

  • Dosya paylaşımı türleri:

    • ZRS: ZRS tüm dosya paylaşımı türleri tarafından desteklenir.

    • Bölgesel yerleştirme ile LRS: Bölgesel yerleştirmeye sahip LRS, aşağıdaki gereksinimleri karşılayan depolama hesapları için kullanılabilir:

      • Premium depolama katmanını (SSD medya katmanı) kullanmalıdır.
      • Yalnızca klasik Azure dosya paylaşımları (Microsoft.Storage kaynak sağlayıcısı kullanılarak). Microsoft.FileShares kaynak sağlayıcısı (önizleme) ile oluşturulan dosya paylaşımları için bölgesel yerleştirme şu anda mümkün değildir.

Maliyet

Maliyet etkisi, kullandığınız kullanılabilirlik alanı desteğinin türüne bağlı olarak farklıdır:

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

  • Bölgesel yerleştirme ile LRS: Bölgesel yerleştirmeye sahip LRS, LRS ile aynı oranda ücretlendirilir.

Ayrıntılı fiyatlandırma bilgileri için bkz. Azure Dosyalar fiyatlandırması.

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

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

Bu bölümde, bir dosya depolama hesabı kullanılabilirlik alanı desteği 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:

    • ZRS: 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ölgesel yerleştirme ile LRS: Yerel olarak yedekli depolama (LRS) ile Azure Depolama, istekleri seçtiğiniz 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: 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ölgesel yerleştirme ile LRS: LRS'ye yapılan tüm yazma işlemleri, bölge içindeki birden çok depolama replikası arasında eşzamanlı olarak çoğaltılır. Verileri karşıya yüklediğinizde veya değiştirdiğinizde, veriler tüm çoğaltmalar arasında başarıyla çoğaltılana kadar işlem tamamlanmış olarak kabul edilmez.

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

Bu bölümde, bir dosya depolama hesabı kullanılabilirlik alanı desteği 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:

    • ZRS: 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.

    • Bölgesel yerleştirme ile LRS: Kullanılabilirlik alanı kaybını algılamanız gerekir. Gerektiğinde, başka bir kullanılabilirlik alanında önceden oluşturduğunuz ikincil bir dosya paylaşımına failover başlatabilirsiniz.

  • 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:

    • ZRS: Kurtarma işlemi sırasında uçuş esnasındaki istekler kesilebilir ve yeniden denenmelidir. Uygulamalar bu geçici kesintileri işlemek için yeniden deneme mantığı uygulamalıdır .

    • Bölgesel yerleştirme ile LRS: Uçuş içi istekler bırakılır ve bölge kurtarıldığında yeniden denenmelidir.

  • Beklenen veri kaybı:

    • ZRS: 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.

    • Bölgesel yerleştirme ile LRS: Etkilenen bölgedeki dosya paylaşımlarındaki veriler, bölge kurtarılana kadar kullanılamaz.

  • Beklenen kapalı kalma süresi:

    • ZRS: 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.

    • Bölgesel yerleştirme ile LRS: Etkilenen bölgedeki dosya paylaşımları, kullanılabilirlik bölgesi kurtarana kadar çalışmaz durumda kalır.

  • Trafik yeniden yönlendirme:

    • ZRS: Azure, trafiği otomatik olarak kalan iyi durumdaki kullanılabilirlik alanlarına yeniden yönlendirer. Hizmet, müşteri müdahalesine gerek olmadan hayatta kalan bölgeleri kullanarak tüm işlevleri korur. Azure dosya paylaşımlarının bağlı istemcilerden yeniden monte edilmesi gerekmez.

    • Bölgesel yerleştirme ile LRS: Gerekirse sağlıklı bölgelerdeki diğer dosya depolama hesaplarına geçiş yapmak sizin sorumluluğundadır.

Bölge kurtarma

Bölge kurtarma davranışı, dosya depolama hesabının kullandığı çoğaltma türüne bağlıdır:

  • ZRS: 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ölgesel yerleştirme ile LRS: Bölge iyi durumda olduktan sonra, bölgedeki dosya paylaşımları yeniden kullanılabilir duruma gelir. İş yüklerinizin gerektirdiği tüm bölge kurtarma yordamlarından ve veri eşitlemeden siz sorumlusunuz.

Bölge hataları için test

Bölge aşağı test seçenekleri, dosya depolama hesabının kullandığı çoğaltma türüne bağlıdır:

  • ZRS: 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ölgesel yerleştirme ile LRS: Dosya depolama hesabınızı içeren kullanılabilirlik alanında kesinti simülasyonu yapmak için hiçbir yol yoktur. Ancak yukarı akış uygulamalarını, güvenlik duvarlarını, ağ geçitlerini veya yük dengeleyicileri el ile yapılandırarak trafiği farklı bir kullanılabilirlik alanındaki farklı bir dosya depolama hesabına yönlendirebilirsiniz.

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.

Önemli

Azure Dosyalar yalnızca standart (HDD) dosya paylaşımları için coğrafi olarak yedekliliği (GRS veya GZRS) destekler.

Azure Dosyalar okuma erişimli coğrafi yedeklilik (RA-GRS) veya okuma erişimli coğrafi alan yedekliliği (RA-GZRS) desteklemez. Depolama hesabı RA-GRS veya RA-GZRS kullanacak şekilde yapılandırılmışsa, standart (HDD) dosya paylaşımları GRS veya GZRS olarak yapılandırılır ve faturalandırılır.

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.

  • Yalnızca standart dosya paylaşımları: Azure Dosyalar yalnızca standart (HDD) dosya paylaşımları için coğrafi olarak yedekliliği (GRS veya GZRS) destekler. Premium (SSD) dosya paylaşımları LRS veya ZRS kullanmalıdır. Premium dosya paylaşımlarınız varsa ve daha yüksek dayanıklılık için verileri bölgeler arasında çoğaltmak istiyorsanız bkz. Dayanıklılık için özel çok bölgeli çözümler.

  • Yalnızca GRS ve GZRS: Azure Dosyalar okuma erişimli coğrafi olarak yedekli depolamayı (RA-GRS) veya okuma erişimli coğrafi alanlar arası yedekli depolamayı (RA-GZRS) desteklemez. Depolama hesabı RA-GRS veya RA-GZRS kullanacak şekilde yapılandırılmışsa, standart (HDD) dosya paylaşımları GRS veya GZRS olarak yapılandırılır ve faturalandırılır.

Değerlendirmeler

Çok bölgeli Azure Dosyaları 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.

  • Son Eşitleme Zamanı: Azure Dosyalar için Son Eşitleme Zamanı, ikincil bölgedeki en son sistem anlık görüntüsünü temel alır.

    Depolama hesabında 100'den fazla dosya paylaşımı varsa Son Eşitleme Zamanı hesaplaması zaman aşımına neden olabilir. Zaman aşımlarını önlemek için her depolama hesabı için 100 veya daha az dosya paylaşımı dağıtmanızı öneririz.

  • İkincil bölge erişimi: Yük devretme gerçekleşene kadar ikincil bölge okuma işlemleri için erişilebilir değildir.

  • Özellik sınırlamaları: GRS veya müşteri tarafından yönetilen yük devretme kullandığınızda bazı Azure Dosyalar özellikleri desteklenmez veya sınırlamalara sahiptir. Bu sınırlamalar belirli dosya paylaşımı türlerini, erişim katmanlarını ve yönetim araçlarını ve işlemlerini içerir. Coğrafi olarak yedeklilik uygulamadan önce özellik uyumluluğu belgelerini 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. Azure Dosyalar 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 dosya depolama hesabında coğrafi yedekliliği etkinleştirin. Mevcut bir dosya depolama hesabını GRS'ye dönüştürmek için bkz. Azure Dosyalar için yedeklilik yapılandırmasını 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şlemi aracılığıyla GRS hesaplarını tek bölgeli yapılandırmalara (LRS veya ZRS) geri 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 Dosyalar, tüm okuma ve yazma işlemlerinin birincil bölgeye yönlendirildiği etkin-pasif bir yaklaşım kullanır.

  • Bölgeler arasında veri çoğaltma: Yazma işlemleri ilk olarak yapılandırılmış yedeklilik türü (GRS için LRS veya GZRS için ZRS) kullanılarak birincil bölgeye işlenir. 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

GRS hesapları için, tam yük devretme ve geri yükleme işlemini test etmek amacıyla bakım sürelerinde planlı yük devretme işlemleri gerçekleştirebilirsiniz. Planlı yük devretme veri kaybı gerektirmez, ancak hem yük devretme hem de geri yükleme sırasında kapalı kalma süresi gerektirir.

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.

  • Coğrafi olarak yedekliliği desteklemeyen dosya paylaşımı türlerini kullanırsınız.

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.

Aşağıdaki yaygın üst düzey yaklaşımları göz önünde bulundurun:

  • Birden çok depolama hesabı: Azure Dosyalar, her bölgede ayrı depolama hesapları kullanılarak birden çok bölgeye dağıtılabilir. 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.

  • Uygulama düzeyinde çoğaltma: Farklı bölgelerdeki dosya paylaşımları arasında verileri eşitlemek için Azure Data Factory veya AzCopy kullanarak özel çoğaltma mantığı uygulayın. Bu yaklaşım özel geliştirme ve çakışma çözümleme mekanizmaları gerektirir.

  • Dosyaları başka bir Azure bölgesindeki bir dosya paylaşımına çoğaltmak için Azure Dosya Eşitleme'yi kullanın. SMB Azure dosya paylaşımı (bulut uç noktası), şirket içi Windows dosya sunucusu ve başka bir Azure bölgesindeki (DR sunucu uç noktası) bir sanal makinede (VM) çalışan bağlı bir dosya paylaşımı arasında eşitleme yapmak için Azure Dosya Eşitleme'yi kullanabilirsiniz.

    Bu yaklaşım, eşitleme işlemini koordine etmek için birden çok dosya paylaşımı ve vm dağıtmanızı gerektirir.

    Çok bölgeli dosya çoğaltma için bu yaklaşımı kullanırsanız:

    • Tüm verilerin dosya sunucusunda yerel olarak mevcut olduğundan emin olmak için bulut katmanlama özelliğini devre dışı bırakın.

    • Azure VM'de veri kümesinin tamamını barındıracak kadar depolama alanı sağlayın.

    • Değişikliklerin ikincil bölgeye hızla çoğaltılmasını sağlamak için Azure'da değil sunucu uç noktasındaki dosyalara erişin ve dosyaları değiştirin.

Yedekleme ve geri yükleme

Azure Dosyalar yedeklemesi , Verileri yanlışlıkla silme, bozulma ve fidye yazılımı saldırılarına karşı korumak için tasarlanan Azure Dosyalar ile Azure Backup arasında yerel bir tümleştirmedir.

Azure Dosyalar yedeklemesi, aynı depolama hesabında depolanan paylaşım düzeyinde anlık görüntüler oluşturur. Bu özellik hem tek tek dosyaların hem de tüm dosya paylaşımlarının hızlı bir şekilde kurtarılmasını sağlar. Ayrıca, özelleştirilebilir yedekleme sıklığıyla uzun saklama süreleri sağlamak için yedekleme ilkelerini de kullanabilirsiniz.

Anlık görüntülerinizi oluşturabilir ve iki farklı yolla depolayabilirsiniz:

  • Paylaşım düzeyi depolama: İşletimsel ve kısa vadeli kurtarma senaryoları için paylaşım düzeyinde anlık görüntüler oluşturabilir ve bunları aynı depolama hesabında depolayabilirsiniz. Paylaşım düzeyi anlık görüntüler, tek tek dosyaların veya dosya paylaşımlarının tamamının özgün veya alternatif bir konuma hızlı bir şekilde kurtarılmasını sağlar.

  • Kasalı yedekleme depolama alanı: Kasalı yedeklemeyi kullanarak günlük anlık görüntülerinizi bir Azure Kurtarma Hizmetleri kasasına kopyalayabilirsiniz. Güvenliği artırmak için bu kasa yalıtılmış ve birincil depolama hesabından fiziksel ve elektronik olarak izole edilmiştir.

    Eşleştirilmiş bir Azure bölgesi kullandığınızda ve kasayı GRS kullanacak şekilde yapılandırdığınızda, kasa verileri eşleştirilmiş bölgeye çoğaltır. Bu çoğaltma bölgeler arası kurtarma ve DR iş akışlarını destekler.

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