Azure Dosyalar için olağanüstü durum kurtarma ve yük devretme

Microsoft, Azure hizmetlerinin her zaman kullanılabilir olmasını sağlamaya çalışır. Ancak planlanmamış hizmet kesintileri oluşabilir ve bölgesel hizmet kesintisini işlemek için bir olağanüstü durum kurtarma (DR) planınız olmalıdır. Olağanüstü durum kurtarma planının önemli bir parçası, birincil uç noktanın kullanılamaz duruma gelmesi durumunda ikincil uç noktaya yük devretmeye hazırlanmaktır. Bu makalede olağanüstü durum kurtarma (DR) ve depolama hesabı yük devretme ile ilgili kavramlar ve işlemler açıklanmaktadır.

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

Müşteri tarafından yönetilen 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 depolamayla ilgili olmayan kesintilerden kurtarmak gibi birden çok senaryoda da 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?

Kurtarma ölçümleri ve maliyetleri

Etkili bir DR stratejisini formüle etmek için bir kuruluşun şunları anlaması gerekir:

• Kesinti durumunda ne kadar veri kaybedebileceğini (kurtarma noktası hedefi veya RPO)
• İş işlevlerini ve verilerini geri yükleyebilmesi için gereken süre (kurtarma süresi hedefi veya RTO)

DR'nin maliyeti genellikle daha düşük veya sıfır RPO/RTO ile artar. Olağanüstü durumdan sonra birkaç saniye içinde çalışır durumda olması gereken ve veri kaybını sürdüremeyen şirketler DR için daha fazla ödeme yaparken, daha yüksek RPO/RTO numaralarına sahip olan şirketler daha az ödeme yapar. Azure, çeşitli RPO ve RTO gereksinimleriyle çalışabilen çözümler sağlar.

Doğru yedeklilik seçeneğini belirleyin

Azure Dosyalar, verilerinizi geçici donanım arızalarından, ağ ve güç kesintilerinden doğal afetlere kadar planlı ve plansız olaylardan korumak için farklı yedeklilik seçenekleri sunar. Tüm Azure dosya paylaşımları yerel olarak yedekli (LRS) veya alanlar arası yedekli depolama (ZRS) kullanabilir. Daha fazla bilgi için bkz. Azure Dosyalar yedeklilik.

Azure Dosyalar, bölgesel kesintilere karşı koruma için coğrafi olarak yedekli depolama (GRS) ve coğrafi alanlar arası yedekli depolama (GZRS) ile yapılandırılmış standart depolama hesapları için hesap yük devretmesini destekler. Hesap yük devretmesi ile, birincil uç nokta kullanılamaz duruma gelirse depolama hesabınız için yük devretme işlemini başlatabilirsiniz. Yük devretme, ikincil uç noktayı depolama hesabınız için birincil uç nokta olacak şekilde güncelleştirir. Yük devretme tamamlandıktan sonra istemciler yeni birincil uç noktaya yazmaya başlayabilir.

Veriler ikincil bölgeye zaman uyumsuz olarak kopyalandığından GRS ve GZRS yine de veri kaybı riski taşır. Bu, birincil bölgeye yazma işleminin ikincil bölgeye kopyalanıp kopyalanmadığı anlamına gelir. Kesinti durumunda, birincil uç noktaya henüz ikincil uç noktaya kopyalanmamış yazma işlemleri kaybolur. Bu, birincil bölgeyi etkileyen bir hatanın, birincil bölge kurtarılamazsa veri kaybına neden olabileceği anlamına gelir. Birincil bölgeye yapılan en son yazma işlemleri ile ikincil bölgeye son yazma arasındaki aralık RPO'dur. Azure Dosyalar genellikle 15 dakika veya daha kısa bir RPO'ya sahiptir, ancak şu anda verileri ikincil bölgeye çoğaltmanın ne kadar sürdüğünü gösteren bir SLA yoktur.

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: SMB dosya paylaşımları için coğrafi olarak yedekli depolamadan yararlanmak üzere uygulama oluşturmaya yönelik tasarım kılavuzu.

Ayrıca uygulamanızı yazma hataları olasılığına karşı hazırlıklı olacak şekilde tasarlamanızı öneririz. Uygulamanız, yazma hatalarını birincil bölgede kesinti olasılığına karşı sizi uyaracak şekilde göstermelidir.

En iyi uygulama olarak, beklenen veri kaybını değerlendirmek için uygulamanızı Son Eşitleme Zamanı özelliğini denetleyecek şekilde tasarlar. Ö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.

Kesintileri izleme

Azure Dosyalar ve diğer Azure hizmetlerinin durumunu ve durumunu izlemek için Azure Hizmet Durumu Panosu'na abone olabilirsiniz.

Hesap yük devretme işlemini anlama

Müşteri tarafından yönetilen hesap yük devretmesi, birincil hesabın herhangi bir nedenle kullanılamaz duruma gelmesi durumunda depolama hesabınızın tamamını ikincil bölgeye devretmenizi sağlar. İkincil bölgeye yük devretmeye zorladığınızda, istemciler yük devretme tamamlandıktan sonra ikincil uç noktaya veri yazmaya başlayabilir. Yük devretme genellikle yaklaşık bir saat sürer. Hesap yük devretmesi başlatmadan önce iş yükünüzü mümkün olduğunca askıya almanızı öneririz.

Hesap yük devretme işleminin nasıl başlatıldığını öğrenmek için bkz . Hesap yük devretmesi başlatma.

Hesap yük devretmesi nasıl çalışır?

Normal koşullarda, istemci birincil bölgedeki bir depolama hesabına veri yazar ve bu veriler ikincil bölgeye zaman uyumsuz olarak kopyalanır. Aşağıdaki görüntüde birincil bölgenin kullanılabilir olduğu senaryo gösterilmektedir:

Birincil uç nokta herhangi bir nedenle kullanılamaz duruma gelirse, istemci artık depolama hesabına yazamaz. Aşağıdaki görüntüde birincilin kullanılamaz duruma geldiği ancak henüz kurtarma gerçekleşmediği senaryo gösterilmektedir:

Müşteri, ikincil uç noktaya hesap yük devretme işlemini başlatır. Yük devretme işlemi, aşağıdaki görüntüde gösterildiği gibi ikincil uç noktanın depolama hesabınız için yeni birincil uç nokta haline gelmesi için Azure Depolama tarafından sağlanan DNS girişini güncelleştirir:

DNS girişi güncelleştirildikten ve istekler yeni birincil uç noktaya yönlendirildikten sonra coğrafi olarak yedekli hesaplar için yazma erişimi geri yüklenir. Mevcut depolama hizmeti uç noktaları yük devretme işleminden sonra aynı kalır. Dosya tanıtıcıları ve kiralar yük devretme sırasında korunmaz, bu nedenle istemcilerin dosya paylaşımlarını çıkarmaları ve yeniden bağlamaları gerekir.

Veri kaybını tahmin edin

Veriler birincil bölgeden ikincil bölgeye zaman uyumsuz olarak yazıldığı için, birincil bölge kullanılamaz duruma gelirse, en son yazma işlemleri henüz ikincil bölgeye kopyalanmamış olabilir.

Yük devretmeye zorladığınızda, ikincil bölge yeni birincil bölge haline geldiğinde birincil bölgedeki tüm veriler kaybolur. Yeni birincil bölge, yük devretmeden sonra yerel olarak yedekli olacak şekilde yapılandırılır.

Yük devretme gerçekleştiğinde ikincil kopyalanan tüm veriler korunur. Ancak, birincil dosyaya yazılan ve ikincil kopyalanmamış tüm veriler kalıcı olarak kaybolur.

Son Eşitleme Zamanı özelliğini denetleme

Son Eşitleme Zamanı (LST) özelliği, birincil bölgedeki verilerin ikincil bölgeye yazıldığı garanti edilen en son zamanı gösterir. Son eşitleme zamanından önce yazılan tüm veriler ikincilde kullanılabilirken, son eşitleme zamanından sonra yazılan veriler ikincile yazılmamış olabilir ve kaybolabilir. Bir hesap yük devretmesi başlatarak oluşabilecek veri kaybı miktarını tahmin etmek için kesinti olması durumunda bu özelliği kullanın.

Yük devretme gerçekleştiğinde dosya paylaşımlarının tutarlı durumda olduğundan emin olmak için, her 15 dakikada bir birincil bölgede bir sistem anlık görüntüsü oluşturulur ve ikincil bölgeye çoğaltılır. İkincil bölgeye yük devretme gerçekleştiğinde, paylaşım durumu ikincil bölgedeki en son sistem anlık görüntüsünü temel alır. Birincil bölgede bir hata olursa, birincil bölgeye yapılan tüm yazma işlemleri henüz ikincil bölgeye çoğaltılmayacağından ikincil bölge büyük olasılıkla birincil bölgenin arkasındadır. Coğrafi gecikme veya diğer sorunlar nedeniyle, ikincil bölgedeki en son sistem anlık görüntüsü 15 dakikadan eski olabilir.

LST'den önceki birincil bölgeye yazılan tüm yazma işlemleri, ikincil bölgeye başarıyla çoğaltıldı ve bu da ikincil bölgeden okunabilecekleri anlamına gelir. Son eşitleme zamanından sonra birincil bölgeye yazılan tüm yazma işlemleri ikincil bölgeye çoğaltılmış veya çoğaltılmış olmayabilir; bu da okuma işlemleri için kullanılamayabileceği anlamına gelir.

Azure PowerShell, Azure CLI veya istemci kitaplığını kullanarak Son Eşitleme Zamanı özelliğinin değerini sorgulayabilirsiniz. Son Eşitleme Zamanı özelliği bir GMT tarih/saat değeridir. Daha fazla bilgi için bkz . Depolama hesabı için Son Eşitleme Zamanı özelliğini denetleme.

Özgün birincil birincile geri dönerken dikkatli olun

Daha önce belirtildiği gibi, birincil bölgeden ikincil bölgeye yük devretme yaptıktan sonra depolama hesabınız yeni birincil bölgede yerel olarak yedekli olacak şekilde yapılandırılır. Ardından hesabı coğrafi olarak yedeklilik için yeni birincil bölgede yapılandırabilirsiniz. Hesap yük devretmeden sonra coğrafi olarak yedeklilik için yapılandırıldığında, yeni birincil bölge verileri hemen özgün yük devretmeden önceki birincil bölge olan yeni ikincil bölgeye kopyalamaya başlar. Ancak, yeni birincil birincildeki mevcut verilerin yeni ikincil sunucuya tam olarak kopyalanmış olması biraz zaman alabilir.

Depolama hesabı coğrafi olarak yedeklilik için yeniden yapılandırıldıktan sonra, yeni birincilden yeni ikincile yeniden çalışma başlatmak mümkündür. Bu durumda, yük devretmeden önceki özgün birincil bölge yeniden birincil bölge olur ve özgün birincil yapılandırmanın GRS mi yoksa GZRS mi olduğuna bağlı olarak yerel olarak yedekli veya alanlar arası yedekli olacak şekilde yapılandırılır. Yük devretme sonrası birincil bölgedeki (özgün ikincil) tüm veriler yeniden çalışma sırasında kaybolur. Yeniden çalışmadan önce depolama hesabındaki verilerin çoğu yeni ikincil sunucuya kopyalanmazsa büyük bir veri kaybıyla karşınıza çıkabilir.

Önemli bir veri kaybını önlemek için geri dönmeden önce Son Eşitleme Zamanı özelliğinin değerini denetleyin. Beklenen veri kaybını değerlendirmek için verilerin yeni birincile yazıldığı son eşitleme zamanını karşılaştırın.

Yeniden çalışma işleminden sonra, yeni birincil bölgeyi yeniden coğrafi olarak yedekli olacak şekilde yapılandırabilirsiniz. Özgün birincil LRS için yapılandırılmışsa, BUNU GRS olarak yapılandırabilirsiniz. Özgün birincil ZRS için yapılandırılmışsa, bunu GZRS olacak şekilde yapılandırabilirsiniz. Ek seçenekler için bkz . Depolama hesabının çoğaltılması şeklini değiştirme.

Hesap yük devretmesi başlatma

Azure portalı, PowerShell, Azure CLI veya Azure Depolama kaynak sağlayıcısı API'sinden hesap yük devretmesi başlatabilirsiniz. Yük devretme başlatma hakkında daha fazla bilgi için bkz . Hesap yük devretmesi başlatma.

Microsoft tarafından yönetilen yük devretme

Bir bölgenin önemli bir olağanüstü durum nedeniyle kaybolduğu aşırı durumlarda, Microsoft bölgesel yük devretme başlatabilir. Bu durumda, sizin için herhangi bir eylem gerekmez. Microsoft tarafından yönetilen yük devretme tamamlanana kadar depolama hesabınıza yazma erişiminiz olmaz.

Ayrıca bkz.

• Azure Dosyalar yedeklilik
• Azure Dosyalar veri korumasına genel bakış
• Depolama hesabı yük devretmesi başlatma