Müşteri tarafından yönetilen planlı yük devretme (önizleme) nasıl çalışır?

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 kesintilerle 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ı yük devretmenin başlatılabilmesi için önce depolama hesabının hem birincil hem de ikincil bölgelerde kullanılabilir olması gerekir.

Bu makalede, sürecin her aşamasında müşteri tarafından yönetilen planlı yük devretme ve yeniden çalışma sırasında ne olacağı açıklanmaktadır. Beklenmeyen bir depolama uç noktası kesintisi nedeniyle yük devretmenin nasıl çalıştığını anlamak için bkz . Müşteri tarafından yönetilen (planlanmamış) yük devretme.


Ö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.

Planlı yük devretme ve yeniden çalışma sırasında yedeklilik yönetimi

İpucu

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, kalan güncelleştirmeler ikincil bölgeye çoğaltmayı tamamlarken birincil bölgenin 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.

Planlı yeniden çalışma işlemi temelde planlanan yük devretme işlemiyle aynıdır, ancak tek bir özel durum 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, hem birincil hem de ikincil bölgeler işlem boyunca kullanılabilir olduğu sürece planlı yük devretme veya yeniden çalışma sırasında veri kaybı beklenmez.

Yük devretme başlatma

Yük devretme başlatmayı öğrenmek için bkz . Hesap yük devretmesi başlatma.

Planlanan yük devretme ve yeniden çalışma işlemi

Aşağıdaki diyagramlarda, bir depolama hesabının müşteri tarafından yönetilen planlı yük devretme ve yeniden çalışma 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:

İstemcilerin birincil bölgedeki depolama hesabına nasıl veri yazdığını gösteren diyagram.

Planlanan yük devretme işlemi (GRS/RA-GRS)

Depolama hesabınızın ikincil bölgeye yük devretmesini başlatarak olağanüstü durum kurtarma testine başlayın. Aşağıdaki adımlar yük devretme işlemini açıklar ve sonraki görüntüde çizim sağlanır:

  1. Özgün birincil bölge salt okunur olur.
  2. Birincil bölgeden ikincil bölgeye tüm verilerin çoğaltması tamamlar.
  3. İ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.

Müşterinin ikincil uç noktaya hesap yük devretmesini nasıl başlattığını gösteren diyagram.

Yük devretme tamamlandıktan sonra özgün birincil bölge yeni ikincil bölge (1) olur ve özgün ikincil bölge yeni birincil (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:

İkincil bölgeye yük devretme sonrasında depolama hesabı durumunu gösteren diyagram.

Yük devretme durumundayken olağanüstü durum kurtarma testinizi gerçekleştirin.

Planlanan yeniden çalışma işlemi (GRS/RA-GRS)

Test tamamlandıktan sonra, özgün birincil bölgeye yeniden çalışma için başka bir yük devretme gerçekleştirin. Yük devretme işlemi sırasında, aşağıdaki görüntüde gösterildiği gibi:

  1. Özgün birincil bölge salt okunur olur.
  2. Tüm veriler geçerli birincil bölgeden geçerli ikincil bölgeye çoğaltılıyor.
  3. Depolama hizmeti uç noktalarının DNS girişleri, ilk yük devretme gerçekleştirilmeden önce birincil olan bölgeye işaret eden şekilde değiştirilir.

Yeniden çalışma genellikle yaklaşık bir saat sürer.

Müşterinin özgün birincil bölgeye hesap yeniden çalışma işlemini nasıl başlattığını gösteren diyagram.

Yeniden çalışma tamamlandıktan sonra depolama hesabı özgün yedeklilik yapılandırmasına geri yüklenir. Kullanıcılar özgün birincil bölgedeki (1) depolama hesabına veri yazmaya devam edebilir ve özgün ikincil (2) çoğaltma yük devretmeden önce olduğu gibi devam eder:

İstemcilerin özgün birincil bölgedeki depolama hesabına okuma ve yazma işlemleri gerçekleştirmeye nasıl devam ettiğini gösteren diyagram.

Ayrıca bkz.