Azure depolama olağanüstü durum kurtarma planlaması ve yük devretme

  • Makale

Microsoft, Azure hizmetlerinin her zaman kullanılabilir olmasını sağlamaya çalışır. Ancak zaman zaman planlanmamış hizmet kesintileri oluşabilir. İyi bir olağanüstü durum kurtarma planının temel bileşenleri şunlara yönelik stratejileri içerir:

Bu makalede coğrafi olarak yedekli depolama hesapları için kullanılabilen seçenekler açıklanır ve yüksek oranda kullanılabilir uygulamalar geliştirmeye ve olağanüstü durum kurtarma planınızı test etme önerileri sağlanır.

Doğru yedeklilik seçeneğini belirleyin

Azure Depolama, hatalar karşısında bile kullanılabilirlik ve dayanıklılık hedeflerinin karşılandığından emin olmak için depolama hesabınızın birden çok kopyasını tutar. Verilerin çoğaltılması farklı koruma düzeyleri sağlar. Her seçeneğin kendi avantajları vardır, bu nedenle seçtiğiniz seçenek, uygulamalarınızın gerektirdiği dayanıklılık derecesine bağlıdır.

En düşük maliyetli yedeklilik seçeneği olan yerel olarak yedekli depolama (LRS), depolama hesabınızın üç kopyasını tek bir veri merkezinde otomatik olarak depolar ve çoğaltır. LRS, verilerinizi sunucu rafı ve sürücü hatalarına karşı korusa da, bir veri merkezinde yangın veya sel gibi olağanüstü durumları hesaba katmıyor. Bu tür olağanüstü durumlar karşısında, LRS kullanmak üzere yapılandırılmış bir depolama hesabının tüm çoğaltmaları kaybolabilir veya kurtarılamaz.

Buna karşılık, alanlar arası yedekli depolama (ZRS) bir depolama hesabının kopyasını tutar ve aynı bölgedeki üç ayrı kullanılabilirlik alanının her birinde çoğaltır. Kullanılabilirlik alanları hakkında daha fazla bilgi için bkz . Azure kullanılabilirlik alanları.

Coğrafi olarak yedekli depolama ve yük devretme

Coğrafi olarak yedekli depolama (GRS), coğrafi alanlar arası yedekli depolama (GZRS) ve okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) coğrafi olarak yedekli depolama seçeneklerine örnek olarak verilebilir. Coğrafi olarak yedekli depolama (GRS, GZRS ve RA-GZRS) kullanmak üzere yapılandırıldığında Azure, verilerinizi zaman uyumsuz olarak ikincil bir coğrafi bölgeye kopyalar. Bu bölgeler yüzlerce, hatta binlerce kilometre uzaklıktadır. Bu yedeklilik düzeyi, birincil bölgenin tamamında bir kesinti olduğunda verilerinizi kurtarmanıza olanak tanır.

LRS ve ZRS'nin aksine coğrafi olarak yedekli depolama, birincil bölgede kesinti olması durumunda ikincil bölgeye planlanmamış yük devretme desteği de sağlar. Yük devretme işlemi sırasında, depolama hesabı hizmet uç noktalarınız için DNS (Etki Alanı Adı Sistemi) girişleri otomatik olarak güncelleştirilir ve böylece ikincil bölgenin uç noktaları yeni birincil uç noktalar haline gelir. Planlanmamış yük devretme tamamlandıktan sonra istemciler yeni birincil uç noktalara yazmaya başlayabilir.

Okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) ve okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) coğrafi olarak yedekli depolama da sağlar, ancak ikincil uç noktaya okuma erişimi avantajı sunar. Bu seçenekler, yüksek kullanılabilirlik açısından iş açısından kritik uygulamalar için tasarlanmış uygulamalar için idealdir. Birincil uç nokta bir kesintiyle karşılaşırsa, ikincil bölgeye okuma erişimi için yapılandırılmış uygulamalar çalışmaya devam edebilir. Microsoft, depolama hesaplarınızın maksimum kullanılabilirliği ve dayanıklılığı için RA-GZRS önerir.

Azure Depolama için yedeklilik hakkında daha fazla bilgi için bkz . Azure Depolama yedekliliği.

Yük devretmeyi planlama

Azure Depolama hesapları üç yük devretme türünü destekler:

1 Microsoft tarafından yönetilen yük devretme tek tek depolama hesapları, abonelikler veya kiracılar için başlatılamaz. Daha fazla bilgi için bkz. Microsoft tarafından yönetilen yük devretme.
2 Olağanüstü durum kurtarma planlarınızı geliştirmek, test etmek ve uygulamak için müşteri tarafından yönetilen yük devretme seçeneklerini kullanın. Microsoft tarafından yönetilen yük devretmeye güvenmeyin ; bu yalnızca aşırı durumlarda kullanılır.

Her yük devretme türünün benzersiz bir kullanım örnekleri kümesi vardır, buna karşılık gelen veri kaybı beklentileri ve hiyerarşik ad alanı etkin olan hesaplar için destek (Azure Data Lake Storage). Bu tabloda her yük devretme türünün özellikleri özetleniyor:

Tür Yük Devretme Kapsamı Kullanım örneği Beklenen veri kaybı Desteklenen Hiyerarşik Ad Alanı (HNS)
Müşteri tarafından yönetilen planlı yük devretme (önizleme) Storage account Birincil ve ikincil bölgeler için depolama hizmeti uç noktaları kullanılabilir ve olağanüstü durum kurtarma testi gerçekleştirmek istiyorsunuz.

Birincil bölge için depolama hizmeti uç noktaları kullanılabilir, ancak başka bir hizmet iş yüklerinizin düzgün çalışmasını engelliyor.

Bir bölgeyi etkileyebilecek kasırga gibi büyük ölçekli felaketlere proaktif olarak hazırlanmak.		 Hayır Evet
(Önizlemede)
Müşteri tarafından yönetilen (planlanmamış) yük devretme Storage account Birincil bölge için depolama hizmeti uç noktaları kullanılamaz duruma gelir, ancak ikincil bölge kullanılabilir.

Microsoft'un kesintiden etkilenmiş olabilecek depolama hesaplarının yük devretme işlemini gerçekleştirmenizi önerdiği bir Azure Önerisi aldınız.		 Evet Evet
(Önizlemede)
Microsoft tarafından yönetilen Tüm bölge Birincil bölge önemli bir olağanüstü durum nedeniyle kullanılamaz duruma gelir, ancak ikincil bölge kullanılabilir. Evet Evet

Aşağıdaki tablo, her yük devretme türünden sonra depolama hesabının yedeklilik durumunu karşılaştırır:

Yük devretmenin sonucu... Müşteri tarafından yönetilen planlı yük devretme (önizleme) Müşteri tarafından yönetilen (planlanmamış) yük devretme
... ikincil bölge İkincil bölge yeni birincil bölge olur İkincil bölge yeni birincil bölge olur
... özgün birincil bölge Özgün birincil bölge yeni ikincil bölge olur Özgün birincil bölgedeki verilerin kopyası silinir
... hesap yedekliliği yapılandırması Depolama hesabı GRS'ye dönüştürülür Depolama hesabı LRS'ye dönüştürülür
... coğrafi yedeklilik yapılandırması Coğrafi yedeklilik korunur Coğrafi yedeklilik kaybedildi

Aşağıdaki tabloda, her yük devretme türü için yük devretme ve yeniden çalışma işleminin her aşamasında elde edilen yedeklilik yapılandırması özetlenmiştir:

Özgün
yapılandırma		 Sonra
yük devretme		 Yeniden etkinleştirdikten sonra
coğrafi yedeklilik		 Sonra
yeniden çalışma		 Yeniden etkinleştirdikten sonra
coğrafi yedeklilik
Müşteri tarafından yönetilen planlı yük devretme
GRS GRS n/a 1 GRS n/a 1
GZRS GRS n/a 1 GZRS n/a 1
Müşteri tarafından yönetilen (planlanmamış) yük devretme
GRS LRS GRS LRS GRS
GZRS LRS GRS ZRS GZRS

1 Coğrafi yedeklilik, planlanan yük devretme sırasında korunur ve el ile yeniden yapılandırılması gerekmez.

Müşteri tarafından yönetilen planlı yük devretme (önizleme)

Planlı yük devretme, planlı olağanüstü durum kurtarma testi, büyük ölçekli olağanüstü durumlara proaktif bir yaklaşım veya kesintilerle ilgili olmayan kesintilerden kurtarmak gibi birden çok senaryoda kullanılabilir.

Planlanan yük devretme işlemi sırasında birincil ve ikincil bölgeler değiştirilir. Özgün birincil bölge indirgenerek yeni ikincil bölge haline gelir. Aynı zamanda özgün ikincil bölge yükseltilir ve yeni birincil bölge olur. Yük devretme tamamlandıktan sonra kullanıcılar yeni birincil bölgedeki verilere erişmeye devam edebilir ve yöneticiler olağanüstü durum kurtarma planlarını doğrulayabilir. Planlı yük devretmenin başlatılabilmesi için önce depolama hesabının hem birincil hem de ikincil bölgelerde kullanılabilir olması gerekir.

Birincil ve ikincil bölgeler tüm işlem boyunca kullanılabilir olduğu sürece planlı yük devretme ve yeniden çalışma işlemi sırasında veri kaybı beklenmez. Daha fazla ayrıntı için Veri kaybı ve tutarsızlıkları bekleme bölümüne bakın.

Bu yük devretme türünün kullanıcılarınız ve uygulamalarınız üzerindeki etkisini anlamak için, planlanan yük devretme ve yeniden çalışma işlemlerinin her adımında neler olduğunu bilmek yararlı olur. Bu işlemin nasıl çalıştığı hakkında ayrıntılı bilgi için bkz . Müşteri tarafından yönetilen (planlı) yük devretme nasıl çalışır?

Önemli

Müşteri tarafından yönetilen planlı yük devretme şu anda ÖNİzLEME aşamasındadır ve aşağıdaki bölgeler ile sınırlıdır:

  • Orta Fransa
  • Güney Fransa
  • Hindistan Orta
  • Hindistan Batı
  • Doğu Asya
  • Güneydoğu Asya

Beta veya önizleme aşamasında olan ya da başka bir şekilde henüz genel kullanıma sunulmamış olan Azure özelliklerinde geçerli olan yasal koşullar için bkz. Microsoft Azure Önizlemeleri için Ek Kullanım Koşulları.

Önizlemeyi kabul etmek için bkz . Azure aboneliğinde önizleme özelliklerini ayarlama ve özellik adı olarak belirtme AllowSoftFailover . Bu önizleme özelliğinin sağlayıcı adı Microsoft.Storage'dır.

Önemli

Planlı bir yük devretme işleminden sonra, depolama hesabının Son Eşitleme Zamanı (LST) değeri eski görünebilir veya Azure Dosyalar veriler mevcut olduğunda NULL olarak bildirilebilir.

Sistem anlık görüntüleri, yük devretme ve yeniden çalışma sırasında kullanılan tutarlı kurtarma noktalarını korumak için düzenli aralıklarla depolama hesabının ikincil bölgesinde oluşturulur. Müşteri tarafından yönetilen planlı yük devretmenin başlatılması, özgün birincil bölgenin yeni ikincil bölge olmasına neden olur. Bazı durumlarda, planlanan yük devretme tamamlandıktan sonra yeni ikincilde sistem anlık görüntüleri yoktur ve bu da hesabın genel LST değerinin eski görünmesine veya olarak Nullgörüntülenmesine neden olur.

Nesneleri oluşturma, değiştirme veya silme gibi kullanıcı etkinlikleri anlık görüntü oluşturmayı tetikleyebileceğinden, planlı yük devretmeden sonra bu etkinliklerin gerçekleştiği herhangi bir hesap ek dikkat gerektirmez. Ancak, anlık görüntüleri veya kullanıcı etkinliği olmayan hesaplar, sistem anlık görüntüsü oluşturma tetiklenene kadar bir Null LST değeri görüntülemeye devam edebilir.

Gerekirse, anlık görüntü oluşturmayı tetikleme amacıyla bir depolama hesabı içindeki her paylaşım için aşağıdaki etkinliklerden birini gerçekleştirin. İşlem tamamlandıktan sonra hesabınızın 30 dakika içinde geçerli bir LST değeri görüntülemesi gerekir.

  • Paylaşımı bağlayın ve okumak için herhangi bir dosyayı açın.
  • Paylaşıma bir test veya örnek dosya yükleyin.

Müşteri tarafından yönetilen (planlanmamış) yük devretme

Depolama hesabınızdaki depolama hizmetlerinin veri uç noktaları birincil bölgede kullanılamaz duruma gelirse, ikincil bölgeye planlanmamış bir yük devretme başlatabilirsiniz. Yük devretme tamamlandıktan sonra ikincil bölge yeni birincil bölge olur ve kullanıcılar verilere orada erişmeye devam edebilir.

Bu tür bir yük devretmenin kullanıcılarınız ve uygulamalarınız üzerindeki etkisini anlamak için planlanmamış yük devretme ve yeniden çalışma işleminin her adımında neler olduğunu bilmek yararlı olur. İşlemin nasıl çalıştığı hakkında ayrıntılı bilgi için bkz . Müşteri tarafından yönetilen (planlanmamış) yük devretme nasıl çalışır?

Microsoft tarafından yönetilen yük devretme

Microsoft, coğrafi bölgenin tamamını etkileyen yıkıcı bir olağanüstü durum gibi olağanüstü durumlarda bölgesel yük devretme başlatabilir. Bu olaylar sırasında sizin için herhangi bir işlem yapmanız gerekmez. Depolama hesabınız RA-GRS veya RA-GZRS için yapılandırılmışsa, uygulamalarınız Microsoft tarafından yönetilen bir yük devretme sırasında ikincil bölgeden okuyabilir. Ancak, yük devretme işlemi tamamlanana kadar depolama hesabınıza yazma erişiminiz olmaz.

Önemli

Olağanüstü durum kurtarma 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 yük devretme, bölge veya veri merkezi gibi fiziksel birimin tamamı için başlatılabilir. Tek tek depolama hesapları, abonelikler veya kiracılar için başlatılamaz. Tek tek depolama hesaplarınızı seçmeli olarak yük devretme olanağına ihtiyacınız varsa, müşteri tarafından yönetilen planlı yük devretmeyi kullanın.

Veri kaybını ve tutarsızlıkları tahmin edin

Dikkat

Müşteri tarafından yönetilen planlanmamış yük devretme genellikle bir miktar veri kaybına neden olur ve ayrıca dosya ve veri tutarsızlıklarına neden olabilir. Olağanüstü durum kurtarma planınızda, hesap yük devretme işlemini başlatmadan önce verileriniz üzerindeki etkisini göz önünde bulundurmanız önemlidir.

Veriler birincil bölgeden ikincil bölgeye zaman uyumsuz olarak yazıldığı için, birincil bölgeye yazma işlemi ikincil bölgeye kopyalanmadan önce her zaman bir gecikme olur. Birincil bölge kullanılamaz duruma gelirse, en son yazma işlemleri henüz ikincil bölgeye kopyalanamayabilir.

Planlanmamış bir yük devretme gerçekleştiğinde, ikincil bölge yeni birincil bölge haline geldiğinde birincil bölgedeki tüm veriler kaybolur. Yük devretme gerçekleştiğinde ikincil bölgeye zaten kopyalanmış olan tüm veriler korunur. Ancak birincil bölgeye yazılan ve ikincil bölgede henüz mevcut olmayan tüm veriler kalıcı olarak kaybolur.

Yeni birincil bölge, yük devretmeden sonra yerel olarak yedekli (LRS) olacak şekilde yapılandırılır.

Depolama hesaplarınızın aşağıdakilerden biri veya daha fazlası etkinleştirildiyse dosya veya veri tutarsızlıkları da yaşayabilirsiniz:

Son eşitleme zamanı

Son Eşitleme Zamanı özelliği, birincil bölgedeki verilerin ikincil bölgeye de yazıldığı en son zamanı gösterir. Hiyerarşik ad alanına sahip hesaplar için aynı Son Eşitleme Zamanı özelliği, erişim denetim listeleri (ACL'ler) dahil hiyerarşik ad alanı tarafından yönetilen meta veriler için de geçerlidir. Son eşitleme zamanından önce yazılan tüm veriler ve meta veriler ikincilde kullanılabilir. Buna karşılık, son eşitleme zamanından sonra yazılan veriler ve meta veriler henüz ikincil değere kopyalanmayabilir ve kaybolabilir. Kesinti sırasında, hesap yük devretmesi başlatırken oluşabilecek veri kaybı miktarını tahmin etmek için bu özelliği kullanın.

En iyi uygulama olarak uygulamanızı, beklenen veri kaybını değerlendirmek için Son Eşitleme Zamanı'na göre tasarlayabilirsiniz. Örneğin, tüm yazma işlemlerini günlüğe kaydetmek, son yazma işleminizin saatlerini son eşitleme zamanıyla karşılaştırmanıza olanak tanır. Bu yöntem, hangi yazmaların henüz ikincil ile eşitlenmediğini ve kaybolma tehlikesiyle karşı karşıya olduğunu belirlemenizi sağlar.

Son Eşitleme Zamanı özelliğini denetleme hakkında daha fazla bilgi için bkz. Depolama hesabı için Son Eşitleme Zamanı özelliğini denetleme.

Azure Data Lake Storage için dosya tutarlılığı

Hiyerarşik ad alanı etkinleştirilmiş depolama hesapları için çoğaltma (Azure Data Lake Storage) dosya düzeyinde gerçekleşir. Çoğaltma bu düzeyde gerçekleştiğinden, birincil bölgedeki bir kesinti kapsayıcı veya dizindeki bazı dosyaların ikincil bölgeye başarıyla çoğaltılmasını engelleyebilir. Depolama hesabı yük devretme işleminden sonra kapsayıcı veya dizin içindeki tüm dosyalar için tutarlılık garanti değildir.

Akış ve blob veri tutarsızlıklarını değiştirme

Değişiklik akışı etkin depolama hesaplarının müşteri tarafından yönetilen (planlanmamış) yük devretmesi, değişiklik akışı günlükleri ile blob verileri ve/veya meta verileri arasında tutarsızlıklara neden olabilir. Bu tür tutarsızlıklar, değişiklik günlüğü güncelleştirmelerinin zaman uyumsuz doğasından ve birincil ve ikincil bölgeler arasında veri çoğaltmasından kaynaklanabilir. Aşağıdaki önlemleri alarak tutarsızlıkları önleyebilirsiniz:

  • Tüm günlük kayıtlarının günlük dosyalarına boşaltıldığından emin olun.
  • Tüm depolama verilerinin birincil bölgeden ikincil bölgeye çoğaltılmasını sağlayın.

Değişiklik akışı hakkında daha fazla bilgi için bkz . Değişiklik akışı nasıl çalışır?

Diğer depolama hesabı özelliklerinin de değişiklik akışının etkinleştirilmesini gerektirdiğini unutmayın. Bu özellikler arasında blok blobları için Azure Blob Depolama işletimsel yedekleme, Nesne çoğaltma ve Belirli bir noktaya geri yükleme yer alır.

Belirli bir noktaya geri yükleme tutarsızlıkları

Müşteri tarafından yönetilen yük devretme, blok blobları içeren genel amaçlı v2 standart katman depolama hesapları için desteklenir. Ancak, depolama hesabında müşteri tarafından yönetilen bir yük devretme gerçekleştirmek, hesap için mümkün olan en erken geri yükleme noktasını sıfırlar. Blok blobları için belirli bir noktaya geri yükleme verileri yalnızca yük devretme tamamlanma süresine kadar tutarlıdır. Sonuç olarak, blok bloblarını yalnızca yük devretme tamamlanma zamanından önce olmayan bir noktaya geri yükleyebilirsiniz. Azure portalında depolama hesabınızın yedeklilik sekmesinden yük devretme tamamlanma süresini de kontrol edebilirsiniz.

Yük devretmenin süresi ve maliyeti

Müşteri tarafından yönetilen yük devretme işleminin başlatıldıktan sonra tamamlanması için gereken süre değişebilir ancak genellikle bir saatten az sürer.

Müşteri tarafından yönetilen planlı yük devretme, yük devretme ve sonraki yeniden çalışma sonrasında coğrafi olarak yedekliliğini kaybetmez, ancak planlanmamış bir müşteri tarafından yönetilen yük devretme işlemi yapar.

Müşteri tarafından yönetilen planlanmamış yük devretmenin başlatılması, depolama hesabınızı otomatik olarak yeni bir birincil bölge içindeki yerel olarak yedekli depolamaya (LRS) dönüştürür ve özgün birincil bölgedeki depolama hesabını siler.

Hesap için coğrafi olarak yedekli depolamayı (GRS) veya okuma erişimli coğrafi olarak yedekli depolamayı (RA-GRS) yeniden etkinleştirebilirsiniz, ancak verileri yeni ikincil bölgeye yeniden çoğaltmak ücrete neden olur. Ayrıca, hesabın coğrafi olarak yedeklilik için yeniden yapılandırılabilmesi için arşivlenmiş blobların çevrimiçi katmanda yeniden doldurulması gerekir. Bu yeniden doldurma işlemi ek ücrete de neden olur. Fiyatlandırma hakkında daha fazla bilgi için bkz:

Depolama hesabınız için GRS'yi yeniden etkinleştirdikten sonra Microsoft, hesabınızdaki verileri yeni ikincil bölgeye çoğaltmaya başlar. Çoğaltmanın tamamlanması için gereken süre çeşitli faktörlere bağlıdır. Bu faktörler şunlardır:

  • Depolama hesabındaki nesnelerin sayısı ve boyutu. Çok sayıda küçük nesnenin çoğaltılması, daha az ve daha büyük nesnelerin çoğaltılmasından daha uzun sürebilir.
  • CPU, bellek, disk ve WAN kapasitesi gibi arka plan çoğaltması için kullanılabilir kaynaklar. Canlı trafik coğrafi çoğaltmaya göre önceliklidir.
  • Varsa blob başına anlık görüntü sayısı.
  • Depolama hesabınızda tablolar varsa veri bölümleme stratejisi. Çoğaltma işlemi, kullandığınız bölüm anahtarı sayısının ötesine ölçeklendirilemez.

Desteklenen depolama hesabı türleri

Coğrafi olarak yedekli tüm teklifler Microsoft tarafından yönetilen yük devretmeyi destekler. Ayrıca, aşağıdaki tabloda gösterildiği gibi bazı hesap türleri müşteri tarafından yönetilen hesap yük devretmeyi destekler:

Yük devretme türü GRS/RA-GRS GZRS/RA-GZRS
Müşteri tarafından yönetilen planlı yük devretme (önizleme) Genel amaçlı v2 hesapları
Genel amaçlı v1 hesapları
Eski Blob Depolama hesapları		 Genel amaçlı v2 hesapları
Müşteri tarafından yönetilen (planlanmamış) yük devretme Genel amaçlı v2 hesapları
Genel amaçlı v1 hesapları
Eski Blob Depolama hesapları		 Genel amaçlı v2 hesapları
Microsoft tarafından yönetilen yük devretme Tüm hesap türleri Genel amaçlı v2 hesapları

Klasik depolama hesapları

Önemli

Müşteri tarafından yönetilen yük devretme yalnızca Azure Resource Manager (ARM) dağıtım modeli kullanılarak dağıtılan depolama hesapları için desteklenir. Klasik model olarak da bilinen Azure Service Manager (ASM) dağıtım modeli desteklenmez. Klasik depolama hesaplarının müşteri tarafından yönetilen hesap yük devretmesi için uygun olmasını sağlamak için önce ARM modeline geçirilmelidir. Yükseltmeyi gerçekleştirmek için depolama hesabınızın erişilebilir olması gerekir, bu nedenle birincil bölge şu anda başarısız durumda olamaz.

Birincil bölgeyi etkileyen bir olağanüstü durum sırasında Microsoft, klasik depolama hesapları için yük devretmeyi yönetir. Daha fazla bilgi için bkz. Microsoft tarafından yönetilen yük devretme.

Hiyerarşik ad alanı (HNS)

Önemli

Azure Data Lake Storage 2. Nesil etkin olan hesaplar için müşteri tarafından yönetilen (planlanmamış) yük devretme şu anda ÖNIZLEME aşamasındadır ve tüm genel GRS/GZRS bölgelerinde desteklenir.

Önizlemeyi kabul etmek için bkz . Azure aboneliğinde önizleme özelliklerini ayarlama ve özellik adı olarak belirtme AllowHNSAccountFailover .

Önemli

SSH Dosya Aktarım Protokolü (SFTP) etkin olan hesaplar için müşteri tarafından yönetilen (planlanmamış) yük devretme şu anda ÖNIZLEME aşamasındadır ve yalnızca aşağıdaki bölgelerde desteklenir:

  • (Asya Pasifik) Orta Hindistan
  • (Asya Pasifik) Güneydoğu Asya
  • (Avrupa) Kuzey Avrupa
  • (Avrupa) Kuzey İsviçre
  • (Avrupa) Batı İsviçre
  • (Avrupa) Batı Avrupa
  • (Kuzey Amerika) Orta Kanada
  • (Kuzey Amerika) Doğu ABD 2
  • (Kuzey Amerika) Orta Güney ABD

Önizlemeyi kabul etmek için bkz . Azure aboneliğinde önizleme özelliklerini ayarlama ve özellik adı olarak belirtme AllowHNSAccountFailover .

Beta veya önizleme aşamasında olan ya da başka bir şekilde henüz genel kullanıma sunulmamış olan Azure özelliklerinde geçerli olan yasal koşullar için bkz. Microsoft Azure Önizlemeleri için Ek Kullanım Koşulları.

Birincil bölgeyi etkileyen önemli bir olağanüstü durum durumunda, Microsoft hiyerarşik ad alanına sahip hesaplar için yük devretmeyi yönetecektir. Daha fazla bilgi için bkz. Microsoft tarafından yönetilen yük devretme.

Desteklenmeyen özellikler ve hizmetler

Müşteri tarafından yönetilen yük devretme için aşağıdaki özellikler ve hizmetler desteklenmez:

  • Azure Dosya Eşitleme müşteri tarafından yönetilen hesap yük devretmeyi desteklemez. Azure Dosya Eşitleme için bulut uç noktası olarak kullanılan depolama hesaplarının yük devretmesi olmamalıdır. Yük devretme dosya eşitlemesini kesintiye uğratır ve yeni katmanlanan dosyaların beklenmeyen veri kaybına neden olabilir. Daha fazla bilgi için ayrıntılar için bkz. Azure Dosya Eşitleme ile olağanüstü durum kurtarma için en iyi yöntemler.
  • Premium blok blobları içeren bir depolama hesabı yük devredemez. Premium blok bloblarını destekleyen depolama hesapları şu anda coğrafi olarak yedekliliği desteklememektedir.
  • Müşteri tarafından yönetilen yük devretme, nesne çoğaltma ilkesindeki kaynak veya hedef hesap için desteklenmez.
  • Ağ Dosya Sistemi (NFS) 3.0 (NFSv3), depolama hesabı yük devretmesi için desteklenmez. NFSv3 etkinken coğrafi yedeklilik için yapılandırılmış bir depolama hesabı oluşturamazsınız.

Özellik desteğine başvurmak için aşağıdaki tablo kullanılabilir.

Planlı yük devretme Planlanmamış yük devretme
Azure Data Lake Storage Desteklenen (önizleme) Desteklenen (önizleme)
Değişiklik Akışı Desteklenmeyen Desteklenir
Nesne Çoğaltma Desteklenmeyen Desteklenmeyen
SFTP Desteklenen (önizleme) Desteklenen (önizleme)
NFSv3 GRS desteklenmiyor GRS desteklenmiyor
Depolama Eylemleri Desteklenen1 Desteklenen1
Belirli bir noktaya geri yükleme (PITR) Desteklenmeyen Desteklenir

1 Müşteri tarafından yönetilen planlı veya planlanmamış bir yük devretme başlatırsanız, depolama görevleri özgün birincil bölgeye geri dönene kadar hesapta çalışamaz. Daha fazla bilgi edinin.

Yük devretme, hesap geçişi için değildir

Depolama hesabı yük devretmeleri, olağanüstü durum kurtarma (DR) planlarınızı geliştirmek ve test etmek veya hizmet kesintisinden kurtarmak için kullanılan geçici bir çözümdür. Yük devretme, veri geçiş stratejinizin bir parçası olarak kullanılmamalıdır. Depolama hesaplarınızı geçirme hakkında bilgi için bkz . Azure Depolama geçişine genel bakış.

Arşivlenmiş bloblar içeren depolama hesapları

Arşivlenmiş bloblar içeren depolama hesapları, hesap yük devretmeyi destekler. Ancak, müşteri tarafından yönetilen yük devretme tamamlandıktan sonra hesabın coğrafi olarak yedeklilik için yapılandırılabilmesi için önce arşivlenen tüm blobların çevrimiçi katmanda yeniden doldurulması gerekir.

Depolama kaynak sağlayıcısı

Microsoft, Azure Depolama kaynaklarıyla çalışmak için iki REST API sağlar. Bu API'ler, Azure Depolama'ya karşı gerçekleştirebileceğiniz tüm eylemlerin temelini oluşturur. Azure Depolama REST API'si blob, kuyruk, dosya ve tablo verileri gibi depolama hesabınızdaki verilerle çalışmanızı sağlar. Azure Depolama kaynak sağlayıcısı REST API'si, depolama hesabını ve ilgili kaynakları yönetmenizi sağlar.

Yük devretme tamamlandıktan sonra, istemciler yeni birincil bölgedeki Azure Depolama verilerini bir kez daha okuyabilir ve yazabilir. Ancak, Azure Depolama kaynak sağlayıcısı yük devretme yapmaz, bu nedenle kaynak yönetimi işlemlerinin birincil bölgede yine de gerçekleşmesi gerekir. Birincil bölge kullanılamıyorsa, depolama hesabında yönetim işlemlerini gerçekleştiremezsiniz.

Azure Depolama kaynak sağlayıcısı yük devretme gerçekleştirmediğinden Konum özelliği, yük devretme tamamlandıktan sonra özgün birincil konumu döndürür.

Azure sanal makineleri

Azure sanal makineleri (VM' ler), depolama hesabı yük devretmesinin bir parçası olarak yük devretme gerçekleştirmez. Kesintiye yanıt olarak ikincil bölgeye yük devreden tüm VM'lerin yük devretme tamamlandıktan sonra yeniden oluşturulması gerekir. Hesap yük devretmesi, sanal makine (VM) kapatıldığında geçici bir diskte depolanan verilerin kaybolmasına neden olabilir. Microsoft, Azure'daki sanal makinelere özgü yüksek kullanılabilirlik ve olağanüstü durum kurtarma yönergelerini takip etmenizi önerir.

Azure yönetilmeyen diskler

Yönetilmeyen diskler Azure Depolama'da sayfa blobları olarak depolanır. Azure'da bir VM çalışırken, VM'ye bağlı tüm yönetilmeyen diskler kiralanır. Bir blobda kira olduğunda hesap yük devretme işlemi devamlenemez. Azure VM'lerine bağlı yönetilmeyen diskler içeren bir hesapta yük devretme başlatılabilmesi için önce disklerin kapatılması gerekir. Bu nedenle, Microsoft'un önerilen en iyi uygulamaları yönetilmeyen diskleri yönetilen disklere dönüştürmektir.

Yönetilmeyen diskler içeren bir hesapta yük devretme gerçekleştirmek için şu adımları izleyin:

  1. Başlamadan önce yönetilmeyen disklerin adlarını, bunların mantıksal birim numaralarını (LUN) ve bağlı oldukları VM'yi not edin. Bunun yapılması, yük devretme sonrasında disklerin yeniden bağlanmasını kolaylaştırır.
  2. VM'yi kapatın.
  3. VM'yi silin, ancak yönetilmeyen diskler için sanal sabit disk (VHD) dosyalarını koruyun. VM'yi sildiğiniz zamanı not edin.
  4. Son Eşitleme Zamanı güncelleştirilene kadar bekleyin ve VM'yi sildiğiniz zamandan daha geç olduğundan emin olun. Bu adım, yük devretme gerçekleştiğinde ikincil uç noktanın VHD dosyalarıyla tam olarak güncelleştirilmesini ve VM'nin yeni birincil bölgede düzgün şekilde çalışmasını sağlar.
  5. Hesap yük devretmesini başlatın.
  6. Hesap yük devretmesi tamamlanana ve ikincil bölge yeni birincil bölgeye dönüşene kadar bekleyin.
  7. Yeni birincil bölgede bir VM oluşturun ve VHD'leri yeniden ekleyin.
  8. Yeni VM'yi başlatın.

VM kapatıldığında geçici diskte depolanan tüm verilerin kaybolduğunu unutmayın.

Verileri yük devretme alternatifi olarak kopyalama

Daha önce açıklandığı gibi, uygulamaları ikincil bölgeye okuma erişimi için yapılandırılmış bir depolama hesabı kullanacak şekilde yapılandırarak yüksek kullanılabilirliği koruyabilirsiniz. Ancak, birincil bölge içindeki bir kesinti sırasında yük devretmeyi tercih ederseniz, verilerinizi alternatif olarak el ile kopyalayabilirsiniz. AzCopy ve Azure PowerShell gibi araçlar, etkilenen bölgedeki depolama hesabınızdan etkilenmemiş bir bölgedeki başka bir depolama hesabına veri kopyalamanızı sağlar. Kopyalama işlemi tamamlandıktan sonra, uygulamalarınızı hem okuma hem de yazma kullanılabilirliği için etkilenmeyen bölgedeki depolama hesabını kullanacak şekilde yeniden yapılandırabilirsiniz.

Yüksek kullanılabilirliğe yönelik tasarım

Uygulamanızı başlangıçtan itibaren yüksek kullanılabilirlik için tasarlamanız önemlidir. Uygulamanızı tasarlarken ve olağanüstü durum kurtarma planlaması yaparken rehberlik için şu Azure kaynaklarına bakın:

  • Azure için dayanıklı uygulamalar tasarlama: Azure'da yüksek oranda kullanılabilir uygulamaların mimarisini oluşturmaya yönelik temel kavramlara genel bakış.
  • Dayanıklılık denetim listesi: Uygulamanızın yüksek kullanılabilirlik için en iyi tasarım uygulamalarını uyguladığını doğrulamaya yönelik bir denetim listesi.
  • Yüksek oranda kullanılabilir uygulamalar tasarlamak için coğrafi yedekliliği kullanın: Coğrafi olarak yedekli depolamadan yararlanmak için uygulama oluşturmaya yönelik tasarım kılavuzu.
  • Öğretici: Blob depolama ile yüksek oranda kullanılabilir bir uygulama oluşturma: Hatalar ve kurtarmalar simülasyonu yapılırken uç noktalar arasında otomatik olarak geçiş yapabilen yüksek oranda kullanılabilir bir uygulamanın nasıl derlendiğini gösteren bir öğretici.

Azure Depolama verileriniz için yüksek kullanılabilirliği korumak için şu en iyi yöntemlere bakın:

  • Diskler: Azure sanal makineleriniz tarafından kullanılan VM disklerini yedeklemek için Azure Backup'ı kullanın. Ayrıca VM'lerinizi bölgesel bir olağanüstü durumdan korumak için Azure Site Recovery'yi kullanmayı da göz önünde bulundurun.
  • Blok blobları: Nesne düzeyinde silme ve üzerine yazma işlemlerine karşı koruma sağlamak için geçici silme özelliğini açın veya AzCopy, Azure PowerShell veya Azure Veri Taşıma kitaplığını kullanarak blok bloblarını farklı bir bölgedeki başka bir depolama hesabına kopyalayın.
  • Dosyalar: Dosya paylaşımlarınızı yedeklemek için Azure Backup'ı kullanın. Ayrıca yanlışlıkla dosya paylaşımı silme işlemlerine karşı korumak için geçici silmeyi etkinleştirin. GRS kullanılamadığında coğrafi olarak yedeklilik için AzCopy veya Azure PowerShell kullanarak dosyalarınızı farklı bir bölgedeki başka bir depolama hesabına kopyalayın.
  • Tablolar: Tablo verilerini farklı bir bölgedeki başka bir depolama hesabına aktarmak için AzCopy kullanın.

Kesintileri izleme

Müşteriler Azure Depolama ve diğer Azure hizmetlerinin durumunu ve durumunu izlemek için Azure Hizmet Durumu Panosu'na abone olabilir.

Microsoft ayrıca uygulamanızı yazma hatası olasılığını dikkate alarak tasarlamanızı önerir. Uygulamanız, yazma hatalarını birincil bölgede kesinti olasılığına karşı sizi uyaracak şekilde göstermelidir.

Ayrıca bkz.