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

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 veri yazmaya başlayabilirler.

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 devretme planı yapın

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 Microsoft tarafından yönetilen yük devretme'ye bakın.
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, çünkü bu yalnızca istisnai durumlarda kullanılır.

Her failover türünün benzersiz bir kullanım senaryoları kümesi, ilgili veri kaybı beklentileri ve hiyerarşik ad alanı etkin hesaplar için destek (Azure Data Lake Storage) vardır. 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 Depolama hesabı Birincil ve ikincil bölgeler için depolama hizmeti uç noktaları kullanılabilir durumda ve siz 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
Müşteri tarafından yönetilen (planlanmamış) yük devretme Depolama hesabı 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
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:

Bir yük devretme işleminin sonucu... Müşteri tarafından yönetilen planlı yük devretme 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
geri yükleme		 Yeniden etkinleştirdikten sonra
coğrafi yedeklilik
Müşteri tarafından yönetilen planlı yük devretme
GRS GRS Yok 1 GRS Yok 1
GZRS GRS Yok 1 GZRS Yok 1
Müşteri tarafından yönetilen (planlanmamış) yük devretme
GRS LRS (Öğrenme Kayıt Deposu) GRS LRS (Öğrenme Kayıt Deposu) GRS
GZRS LRS (Öğrenme Kayıt Deposu) 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

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

Planlanan yük devretme işlemi sırasında birincil ve ikincil bölgeler yer değiştirir. Ö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. Planlanan yük devretmenin başlatılabilmesi için, depolama hesabının hem birincil hem de ikincil bölgelerde kullanılabilir durumda 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 Müşteri tarafından yönetilen (planlı) yük devretme işleminin nasıl çalıştığını görün.

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 Müşteri tarafından yönetilen (planlanmamış) yük devretme nasıl çalışır? başlıklı makaleye bakın.

Microsoft tarafından yönetilen yük devretme

Microsoft, bir coğrafi bölgenin tamamını etkileyen yıkıcı bir felaket gibi aşırı 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. Microsoft'un yönettiği yük devretmesine güvenmeyin, sadece aşırı durumlarda kullanılabilir. 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. Eğer bireysel depolama hesaplarınız için seçmeli 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. Failover 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 veri ve meta veriler henüz ikincil sisteme kopyalanmamış olabilir ve bu veriler 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.

İyi bir uygulama pratiği olarak, uygulamanızı beklenen veri kaybını değerlendirmek için Son Eşitleme Zamanı'ndan yararlanabilecek şekilde tasarlayın. Ö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 yazılanların henüz ikincille 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 Depolama hesabı için Son Eşitleme Zamanı özelliğini denetleme bkz.

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 kayıt dosyalarına yazı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 Azure Blob Depolama'nın işletimsel yedeklemesi, Nesne çoğaltma ve blok blobları için belirli bir noktaya geri yükleme yer alır.

Anlık 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, bir depolama hesabında müşteri tarafından yönetilen bir kapalı devre işlemi 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 daha erken 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.

Failover işleminin 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ı bir yük devretme, yük devretme ve ardından yeniden yük devretme sonrasında coğrafi yedekliliğini kaybetmez; ancak planlanmamış bir müşteri tarafından yönetilen yük devretme bu yedekliği kaybeder.

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 yedeklilik için yeniden yapılandırılabilmesi için arşivlenmiş blobların çevrimiçi erişim katmanına yeniden etkinleştirilmesi gerekir. Bu yeniden sulandırma ek bir ücrete tabidir. 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.
  • Mevcut kaynaklar, CPU, bellek, disk ve WAN kapasitesi gibi arka plan kopyalama için kullanılan kaynaklardır. Canlı trafik coğrafi çoğaltmaya göre öncelik taşır.
  • Uygulanabilir olduğunda, blob başına düşen 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 hizmetler, Microsoft tarafından yönetilen yük devretmeyi desteklemektedir. Ayrıca, aşağıdaki tabloda gösterildiği gibi bazı hesap türleri, müşteri tarafından yönetilen hesap devretmesini destekler.

Yük devretme türü GRS/RA-GRS GZRS/RA-GZRS
Müşteri tarafından yönetilen planlı yük devretme 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ı

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 bir hesap için yük devretmeyi desteklemez. Azure Dosya Eşitleme için bulut uç noktası olarak kullanılan depolama hesapları devre dışı bırakılmamalıdır. Yük devretme, dosya eşitlemesini kesintiye uğratır ve yeni katmanlanan dosyaların veri kaybına uğramasına neden olabilir, bu da beklenmedik bir durum yaratabilir. Detaylı bilgi için Azure Dosya Eşitleme ile olağanüstü durum kurtarma için en iyi yöntemler kısmına bakın.
  • Premium blok blobları içeren depolama hesapları 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 devretme işlemi 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 Desteklenir Desteklenir
Değişiklik Akışı Desteklenmeyen Desteklenir
Nesne Çoğaltma Desteklenmeyen Desteklenir
SFTP (İngilizce) Desteklenir Desteklenir
NFSv3 GRS desteklenmiyor GRS desteklenmiyor
Depolama Eylemleri Desteklenen1 Desteklenen1
Anlık 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.

Hesap geçişi için yük devretme kullanılmaz.

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 devretmesine destek verir. Ancak, müşteri tarafından yönetilen bir hizmet devretme tamamlandıktan sonra, hesabın coğrafi yedeklilik için yapılandırılabilmesi için önce arşivlenen tüm blobların çevrimiçi bir katmana rehidrate edilmesi 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 yapmadığından, 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. Bir kesinti durumunda başka bir bölgeye devredilen tüm VM'lerin devretme işlemi 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 blob üzerinde kiralama olduğunda hesap yük devretme işlemi devam edemez. 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 devri tamamlanana ve ikincil bölge yeni birincil bölge haline gelene 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ölgedeki bir kesinti sırasında yük devretmemeyi tercih ederseniz, alternatif olarak verilerinizi manuel olarak 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.

  • Son güncelleştirme: