Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Müşteri tarafından yönetilen planlı yük devretme, olağanüstü durum ve kurtarma planlaması ve testi, beklenen büyük ölçekli olağanüstü durumların proaktif olarak düzeltilmesi ve depolamayla ilgili olmayan kesintiler gibi senaryolarda yararlı olabilir.
Planlanan yük devretme işlemi sırasında depolama hesabınızın birincil ve ikincil bölgeleri değiştirilir. Özgün birincil bölge indirgenip yeni ikincil bölge olurken özgün ikincil bölge yükseltilir ve yeni birincil bölge olur. Planlı bir yük devretmenin başlatılabilmesi için depolama hesabının hem birincil hem de ikincil bölgelerde kullanılabilir durumda olması gerekir.
Bu makalede, sürecin her aşamasında müşteri tarafından yönetilen planlı yük devretme ve geri yükleme sırasında ne olacağı açıklanmaktadır. Beklenmedik bir depolama uç noktası kesintisi nedeniyle bir devre sürecinin nasıl çalıştığını anlamak için bkz. Müşteri tarafından yönetilen (planlanmamış) failover nasıl çalışıyor.
Planlı yük devretme ve geri yükleme sırasında yedeklilik yönetimi
Tavsiye
Müşteri tarafından yönetilen yük devretme ve yeniden çalışma işlemi sırasındaki değişen yedeklilik durumlarını ayrıntılı olarak anlamak için her birinin tanımları için bkz . Azure Depolama yedekliliği .
Planlı yük devretme işlemi sırasında, devam eden güncellemeler ikincil bölgeye çoğaltmayı tamamlarken birincil bölgedeki depolama hizmeti uç noktaları salt okunur hale gelir. Ardından, tüm depolama hizmeti uç noktasının etki alanı adı hizmeti (DNS) girdileri değiştirilir. Depolama hesabınızın ikincil uç noktaları yeni birincil uç noktalara, özgün birincil uç noktalar ise yeni ikincil uç noktalara dönüşür. Birincil ve ikincil bölgeler değiştirildiğinde bile her bölge içindeki veri çoğaltma değişmeden kalır.
Planlanmış geri dönüş süreci temelde planlanmış yük devretme süreci ile aynıdır, ancak bir istisna vardır. Planlı yeniden çalışma sırasında Azure, depolama hesabınızın özgün yedeklilik yapılandırmasını depolar ve yeniden çalışma sonrasında özgün durumuna geri yükler. Örneğin, depolama hesabınız başlangıçta GZRS olarak yapılandırılmışsa, yeniden çalışma sonrasında depolama hesabı GZRS olur.
Not
Müşteri tarafından yönetilen (planlanmamış) yük devretmeden farklı olarak, planlı yük devretme sırasında, uç noktaların DNS girişleri yeni ikincil olarak değiştirilmeden önce birincil bölgeden ikincil bölgeye çoğaltmanın tamamlanması gerekir. Bu nedenle, plan edilen devretme veya geri dönüş sırasında hem birincil hem de ikincil bölgeler süreç boyunca kullanılabilir olduğu sürece veri kaybı beklenmez.
Yük devretmeyi nasıl başlatmak
Yük devretmeyi nasıl başlatacağınızı öğrenmek için bkz Hesap yük devretmesi başlatma.
Planlanan yük devretme ve geri yükleme işlemi
Aşağıdaki diyagramlarda, bir depolama hesabının müşteri tarafından yönetilen planlı yük devretme ve geri alma sırasında neler olduğu gösterilmektedir.
Normal koşullarda istemci, depolama hizmeti uç noktaları (1) aracılığıyla birincil bölgedeki bir depolama hesabına veri yazar. Ardından veriler birincil bölgeden ikincil bölgeye (2) zaman uyumsuz olarak kopyalanır. Aşağıdaki görüntüde GRS olarak yapılandırılmış bir depolama hesabının normal durumu gösterilmektedir:
Planlanan yük devretme işlemi (GRS/RA-GRS)
Depolama hesabınızın ikincil bölgeye yük devrini başlatarak felaket kurtarma testine başlayın. Aşağıda, planlanan yük devretme işlemi içindeki adımlar açıklanır ve sonraki görselde bir örnek gösterilir:
Hem birincil hem de ikincil bölgedeki depolama hesabı hem okuma hem de yazma erişiminde geçici bir kayıpla karşılaşır.
Birincil bölgeden ikincil bölgeye tüm verilerin çoğaltılması tamamlandı.
İkincil bölgedeki depolama hizmeti uç noktaları için DNS girişleri yükseltilir ve depolama hesabınız için yeni birincil uç noktalar haline gelir.
Yük devretme genellikle yaklaşık bir saat sürer.
Yük devretme tamamlandıktan sonra, özgün birincil bölge yeni ikincil bölge (1) haline gelir ve özgün ikincil bölge yeni birincil bölge (2) olur. Bloblar, tablolar, kuyruklar ve dosyalar için depolama hizmeti uç noktalarının URI'leri aynı kalır, ancak DNS girişleri yeni birincil bölgeye işaret edecek şekilde değiştirilir (3). Kullanıcılar yeni birincil bölgedeki depolama hesabına veri yazmaya devam edebilir ve veriler aşağıdaki görüntüde gösterildiği gibi zaman uyumsuz olarak yeni ikincil (4) öğesine kopyalanır:
Yedekleme modundayken felaket kurtarma testinizi gerçekleştirin.
Not
Azure Dosyalar durum bilgisi olan bağlantıları korur; bu da uygulamaların verilere erişmeye devam etmek için yük devretme sonrasında dosya paylaşımlarını yeniden bağlaması veya yeniden başlatması gerekebileceği anlamına gelir.
Planlanan geriye dönüş işlemi (GRS/RA-GRS)
Test tamamlandıktan sonra, orijinal birincil bölgeye geri dönmek için başka bir yük devretme gerçekleştirin. Aşağıdaki görüntüde gösterildiği gibi, yük devretme işlemi sırasında:
Hem birincil hem de ikincil bölgedeki depolama hesabı hem okuma hem de yazma erişiminde geçici bir kayıpla karşılaşır.
Tüm verilerin, geçerli birincil bölgeden geçerli ikincil bölgeye çoğaltılması tamamlanıyor.
Depolama hizmeti uç noktalarının DNS girişleri, ilk yük devretmeden önce birincil olan bölgeye tekrar işaret edecek şekilde değiştirilir.
Geri dönüş işlemi genellikle yaklaşık bir saat sürer.
Geri dönüş tamamlandıktan sonra depolama hesabı özgün yedeklilik yapılandırmasına geri yüklenir. Kullanıcılar, orijinal birincil bölgedeki (1) depolama hesabına veri yazmaya devam edebilirler, bu sırada orijinal ikincil (2) bölgeye yapılan çoğaltma, yük devretme öncesinde olduğu gibi devam eder.
