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 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, genel olarak yedekli depolama hesapları (GRS, GZRS ve RA-GZRS) için yük devretme ve kesinti ve sonraki yük devretme durumlarında uygulamalarınızın yüksek oranda kullanılabilir olacak şekilde tasarlanması ele alınmaktadır.

Doğru yedeklilik seçeneğini belirleyin

Azure Depolama, dayanıklılık ve yüksek kullanılabilirlik sağlamak için depolama hesabınızın birden çok kopyasını tutar. Hesabınız için hangi yedeklilik seçeneğini belirlediğiniz, uygulamalarınız için ihtiyacınız olan dayanıklılık derecesine bağlıdır.

Yerel olarak yedekli depolama (LRS) ile depolama hesabınızın üç kopyası otomatik olarak tek bir veri merkezinde depolanır ve çoğaltılır. Alanlar arası yedekli depolama (ZRS) ile, aynı bölgedeki üç ayrı kullanılabilirlik alanının her birinde bir kopya depolanır ve çoğaltılır. Kullanılabilirlik alanları hakkında daha fazla bilgi için bkz . Azure kullanılabilirlik alanları.

Depolama hesabının tek bir kopyasının kurtarılması LRS ve ZRS ile otomatik olarak gerçekleşir.

Genel olarak yedekli depolama ve yük devretme

Küresel olarak yedekli depolama (GRS, GZRS ve RA-GZRS) ile Azure, verilerinizi zaman uyumsuz olarak en az yüzlerce kilometre uzaktaki ikincil bir coğrafi bölgeye kopyalar. Bu, birincil bölgede bir kesinti olduğunda verilerinizi kurtarmanıza olanak tanır. Genel olarak yedekli depolamayı LRS ve ZRS'den ayıran bir özellik, birincil bölgede kesinti olması durumunda ikincil bölgeye yük devretme olanağıdır. Yük devretme işlemi, depolama hesabı hizmet uç noktalarınız için DNS girişlerini güncelleştirir; böylece ikincil bölgenin uç noktaları depolama hesabınız için yeni birincil uç noktalar haline gelir. Yük devretme tamamlandıktan sonra istemciler yeni birincil uç noktalara yazmaya başlayabilir.

RA-GRS ve RA-GZRS yedeklilik yapılandırmaları, birincil bölgede kesinti olması durumunda ikincil uç noktaya okuma erişiminin ek avantajıyla coğrafi olarak yedekli depolama sağlar. Birincil uç noktada bir kesinti oluşursa, ikincil bölgeye okuma erişimi için yapılandırılmış ve yüksek kullanılabilirlik için tasarlanmış uygulamalar ikincil uç noktadan okumaya devam edebilir. Microsoft, depolama hesaplarınızın maksimum kullanılabilirliği ve dayanıklılığı için RA-GZRS önerir.

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

Depolama hesabı yük devretmesini planlama

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

1Microsoft tarafından yönetilen yük devretme tek tek depolama hesapları, abonelikler veya kiracılar için başlatılamaz. Daha fazla ayrıntı için bkz . Microsoft tarafından yönetilen yük devretme.
2 Olağanüstü durum kurtarma planınız müşteri tarafından yönetilen yük devretmeyi temel almalıdır. 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ü benzersiz bir kullanım örnekleri kümesine, buna karşılık gelen veri kaybı beklentilerine ve hiyerarşik ad alanı etkinleştirilmiş (Azure Data Lake Storage 2. Nesil) hesaplara yönelik desteğe sahiptir. Bu tablo, her yük devretme türünün bu yönlerini özetler:

Tür Yük Devretme Kapsamı Kullanım örneği Beklenen veri kaybı Desteklenen HNS
Müşteri tarafından yönetilen 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 veya ölçek birimi Önemli bir olağanüstü durum nedeniyle birincil bölge tamamen kullanılamaz hale gelir, ancak ikincil bölge kullanılabilir. Evet Evet

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

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

Müşteri tarafından yönetilen hesap yük devretmesinin kullanıcılarınız ve uygulamalarınız üzerindeki etkisini tam olarak anlamak için, yük devretme ve yeniden çalışma işleminin her adımında ne olacağını bilmek yararlı olur. İşlemin nasıl çalıştığı hakkında ayrıntılı bilgi için bkz . Müşteri tarafından yönetilen depolama hesabı yük devretme nasıl çalışır?

Microsoft tarafından yönetilen yük devretme

Birincil bölgenin büyük bir olağanüstü durum nedeniyle makul bir süre içinde kurtarılamaz olduğu aşırı durumlarda, Microsoft bölgesel yük devretme başlatabilir . Bu durumda, sizin tarafınıza herhangi bir işlem yapılması gerekmez. Microsoft tarafından yönetilen yük devretme tamamlanana kadar depolama hesabınıza yazma erişiminiz olmaz. Depolama hesabınız RA-GRS veya RA-GZRS için yapılandırılmışsa uygulamalarınız ikincil bölgeden okuyabilir.

Önemli

Olağanüstü durum kurtarma planınız müşteri tarafından yönetilen yük devretmeyi temel almalıdır. Yalnızca aşırı durumlarda kullanılabilecek Microsoft tarafından yönetilen yük devretmeye güvenmeyin. Bölge veya ölçek birimi gibi fiziksel birimin tamamı için Microsoft tarafından yönetilen bir yük devretme başlatılabilir. Tek tek depolama hesapları, abonelikler veya kiracılar için başlatılamaz. Tek tek depolama hesaplarınıza seçmeli yük devretme yapabilmeniz için müşteri tarafından yönetilen hesap yük devretmesini kullanın.

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

Dikkat

Depolama hesap yük devretmesi genellikle bazı veri kayıplarını ve olası dosya ve veri tutarsızlıklarını içerir. 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 kopyalanmamış olabilir.

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 kopyalanan tüm veriler korunur. Ancak, birincil bölgeye yazılan ve ikincil bölgeye de kopyalanmamış 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 yazıldığı garanti edilen en son zamanı gösterir. Hiyerarşik ad alanına sahip hesaplar için aynı Son Eşitleme Zamanı özelliği, ACL'ler de dahil olmak üzere 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ılabilirken, son eşitleme zamanından sonra yazılan veriler ve meta veriler ikincilye yazılmamış olabilir ve kaybolabilir. Hesap yük devretmesi başlatarak oluşabilecek veri kaybı miktarını tahmin etmek için bir kesinti varsa bu özelliği kullanın.

En iyi uygulama olarak, uygulamanızı, beklenen veri kaybını değerlendirmek için son eşitleme zamanını kullanacak şekilde tasarlayabilirsiniz. Örneğin, tüm yazma işlemlerini günlüğe kaydederseniz, hangi yazma işlemlerinin ikincil ile eşitlenmediğini belirlemek için son yazma işlemlerinizin zamanını son eşitleme zamanıyla karşılaştırabilirsiniz.

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 2. Nesil için dosya tutarlılığı

Hiyerarşik ad alanı etkinleştirilmiş (Azure Data Lake Storage 2. Nesil) depolama hesapları için çoğaltma, dosya düzeyinde gerçekleşir. Başka bir deyişle, birincil bölgede bir kesinti oluşursa, kapsayıcı veya dizindeki dosyalardan yalnızca bazılarının ikincil bölgeye başarıyla çoğaltılmış olması mümkündür. Depolama hesabı yük devretme işleminden sonra kapsayıcıdaki veya dizindeki tüm dosyalar için tutarlılık garanti edilmediğinden.

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

Değişiklik akışının etkinleştirildiği coğrafi olarak yedekli depolama hesaplarının Depolama hesap 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, hem değişiklik günlüklerindeki güncelleştirmelerin zaman uyumsuz doğasından hem de blob verilerinin birincil bölgeden ikincil bölgeye çoğaltılmasından kaynaklanabilir. Tutarsızlıkların beklenmediği tek durum, geçerli günlük kayıtlarının tümünün günlük dosyalarına başarıyla boşaltılması ve tüm depolama verilerinin birincil bölgeden ikincil bölgeye başarıyla çoğaltılmasıdır.

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

Azure Blob Depolama işletimsel yedeklemesi, Nesne çoğaltması ve blok blobları için belirli bir noktaya geri yükleme gibi diğer depolama hesabı özelliklerinin değişiklik akışının etkinleştirilmesini gerektirdiğini unutmayın.

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'da depolama hesabınızın yedeklilik sekmesinden yük devretme tamamlanma süresini de kontrol edebilirsiniz.

Örneğin, bekletme süresini 30 gün olarak ayarladığınızı varsayalım. Yük devretmeden bu yana 30 günden fazla zaman geçtiyse, bu 30 gün içinde herhangi bir noktaya geri yükleyebilirsiniz. Ancak, yük devretmeden bu yana 30 günden az bir süre geçtiyse, saklama süresinden bağımsız olarak yük devretmeden önceki bir noktaya geri yükleyemezsiniz. Örneğin, yük devretmenin üzerinden 10 gün geçtiyse, mümkün olan en erken geri yükleme noktası geçmişte 30 gün değil, geçmişte 10 gündür.

Yük devretmenin süresi ve maliyeti

Yük devretmenin 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 yük devretme, yük devretme (ve yeniden çalışma) sonrasında coğrafi olarak yedekliliğini kaybeder. Depolama hesabınız, yük devretme sırasında yeni birincil bölgedeki yerel olarak yedekli depolamaya (LRS) otomatik olarak dönüştürülür ve özgün birincil bölgedeki depolama hesabı silinir.

Hesap için coğrafi olarak yedekli depolamayı (GRS) veya okuma erişimli coğrafi olarak yedekli depolamayı (RA-GRS) yeniden etkinleştirebilirsiniz, ancak LRS'den GRS veya RA-GRS'ye dönüştürmenin ek maliyet doğurduğunu unutmayın. Maliyet, verileri yeni ikincil bölgeye yeniden çoğaltmak için ağ çıkış ücretlerinden kaynaklanır. Ayrıca, hesabın coğrafi olarak yedeklilik için yapılandırılabilmesi için önce arşivlenen tüm blobların bir çevrimiçi katmanda yeniden doldurularak maliyete neden olması gerekir. 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ğaltma süresi, aşağıdakileri içeren birçok faktöre bağlıdı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.
  • Depolama hesabınızda bloblar varsa blob başına anlık görüntü sayısı.
  • Depolama hesabınız tablolar içeriyorsa, 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 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 hesap yük devretmesi yalnızca Azure Resource Manager (ARM) dağıtım modeli kullanılarak dağıtılan depolama hesapları için desteklenir. Klasik 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 varsa, Klasik depolama hesapları için yük devretmeyi Microsoft yönetir. Daha fazla bilgi için bkz. Microsoft tarafından yönetilen yük devretme.

Azure Data Lake Storage 2. Nesil

Önemli

Hiyerarşik ad alanına (Azure Data Lake Storage 2. Nesil) sahip hesaplar için müşteri tarafından yönetilen hesap yük devretmesi ş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 varsa, Microsoft hiyerarşik ad alanına sahip hesaplar için yük devretmeyi yönetir. Daha fazla bilgi için bkz. Microsoft tarafından yönetilen yük devretme.

Desteklenmeyen özellikler ve hizmetler

Hesap yük devretmesi için aşağıdaki özellikler ve hizmetler desteklenmez:

  • Azure Dosya Eşitleme müşteri tarafından başlatılan depolama hesabı yük devretmeyi desteklemez. Azure Dosya Eşitleme'de bulut uç noktaları olarak kullanılan Azure dosya paylaşımlarını içeren Depolama hesapların yük devretmesi olmamalıdır. Bunun yapılması eşitlemenin çalışmayı durdurmasına neden olur ve yeni katmanlanmış dosyalar söz konusu olduğunda beklenmedik veri kaybına da yol açabilir. 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.
  • SSH Dosya Aktarım Protokolü (SFTP) etkinleştirilmiş bir hesabın yük devretmesini yapmak için önce hesap için SFTP'yi devre dışı bırakmanız gerekir. Yük devretme tamamlandıktan sonra SFTP'yi kullanmaya devam etmek istiyorsanız yeniden etkinleştirmeniz yeterlidir.
  • Ağ Dosya Sistemi (NFS) 3.0 (NFSv3), depolama hesabı yük devretmesi için desteklenmez. NFSv3 etkinken genel yedeklilik için yapılandırılmış bir depolama hesabı oluşturamazsınız.

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

Depolama hesap yük devretmesi, veri geçiş stratejinizin bir parçası olarak kullanılmamalıdır. Yük devretme, hizmet kesintisi için geçici bir çözümdü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 hesapları Depolama

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 doldurulmaları 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 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 yeniden 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şlemleri gerçekleştiremezsiniz.

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

Azure sanal makineleri

Azure sanal makineleri (VM' ler) hesap yük devretmesinin bir parçası olarak yük devretme gerçekleştirmez. Birincil bölge kullanılamaz duruma gelirse ve ikincil bölgeye yük devrederseniz, yük devretmeden sonra tüm VM'leri yeniden oluşturmanız gerekir. Ayrıca, hesap yük devretmesiyle ilişkili olası bir veri kaybı da vardır. Microsoft, Azure'daki sanal makinelere özgü yüksek kullanılabilirlik ve olağanüstü durum kurtarma yönergelerini takip etmenizi önerir.

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

Azure yönetilmeyen diskler

En iyi uygulama olarak, Microsoft yönetilmeyen disklerin yönetilen disklere dönüştürülmesini önerir. Ancak, Azure VM'lerine bağlı yönetilmeyen diskler içeren bir hesabın yükünü devretmeniz gerekiyorsa, yük devretmeyi başlatmadan önce VM'yi kapatmanız gerekir.

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. Yük devretmeyi 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 VHD dosyalarını koruyun. VM'yi sildiğiniz zamanı not edin.
  4. Son Eşitleme Zamanı güncelleştirilene ve VM'yi sildiğiniz zamandan daha sonra olana kadar bekleyin. Bu adım önemlidir, çünkü yük devretme gerçekleştiğinde ikincil uç nokta VHD dosyalarıyla tam olarak güncelleştirilmediyse VM yeni birincil bölgede düzgün çalışmayabilir.
  5. Hesap yük devretmesini başlatın.
  6. Hesap yük devretmesi tamamlanana ve ikincil bölgenin yeni birincil bölge haline gelmesini 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.

Yük devretme alternatifi olarak verileri kopyalama

Depolama hesabınız ikincil bölgeye okuma erişimi için yapılandırılmışsa, uygulamanızı ikincil uç noktadan okuyacak şekilde tasarlayabilirsiniz. Birincil bölgede bir kesinti olduğunda yük devretmeyi tercih ediyorsanız, azCopy veya Azure PowerShell gibi araçları kullanarak ikincil bölgedeki depolama hesabınızdan etkilenmeyen bir bölgedeki başka bir depolama hesabına veri kopyalayabilirsiniz. Daha sonra hem okuma hem de yazma kullanılabilirliği için uygulamalarınızı bu depolama hesabına işaret edebilirsiniz.

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ı tasarlama ve olağanüstü durum kurtarma planlaması konusunda 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 korumaya yönelik şu en iyi yöntemleri göz önünde bulundurun:

  • Diskler: Azure sanal makineleriniz tarafından kullanılan VM disklerini yedeklemek için Azure Backup'ı kullanın. Ayrıca, bölgesel bir olağanüstü durum söz konusu olduğunda VM'lerinizi 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.