Yüksek oranda kullanılabilir uygulamalar tasarlamak için coğrafi yedekliliği kullanma

Azure Depolama gibi bulut tabanlı altyapılar, verileri ve uygulamaları barındırmak için yüksek oranda kullanılabilir ve dayanıklı bir platform sağlar. Bulut tabanlı uygulamaların geliştiricileri, kullanıcıları için bu avantajları en üst düzeye çıkarmak için bu platformdan nasıl yararlanacaklarını dikkatle değerlendirmelidir. Azure Depolama, bölgesel bir kesinti sırasında bile yüksek kullanılabilirlik sağlamak için coğrafi olarak yedeklilik seçenekleri sunar. Coğrafi olarak yedekli çoğaltma için yapılandırılan depolama hesapları, birincil bölgede zaman uyumlu olarak çoğaltılır ve zaman uyumsuz olarak yüzlerce kilometre uzaktaki ikincil bir bölgeye çoğaltılır.

Azure Depolama coğrafi olarak yedekli çoğaltma için iki seçenek sunar: Coğrafi olarak yedekli depolama (GRS) ve Coğrafi alanlar arası yedekli depolama (GZRS). Azure Depolama coğrafi olarak yedeklilik seçeneklerini kullanmak için depolama hesabınızın okuma erişimli coğrafi olarak yedekli depolama (RA-GRS) veya okuma erişimli coğrafi alanlar arası yedekli depolama (RA-GZRS) için yapılandırıldığından emin olun. Aksi takdirde depolama hesabı çoğaltma türünüzü değiştirme hakkında daha fazla bilgi edinebilirsiniz.

Bu makalede, birincil bölgede önemli bir kesinti yaşansa bile sınırlı kapasitede olsa da çalışmaya devam edecek bir uygulamanın nasıl tasarlanacağı gösterilmektedir. Birincil bölge kullanılamaz duruma gelirse, birincil bölge yeniden yanıt verene kadar uygulamanız ikincil bölgede okuma işlemleri gerçekleştirmek için sorunsuz bir şekilde geçiş yapabilir.

Uygulama tasarımında dikkat edilmesi gerekenler

Birincil bölgeden okumayı engelleyen bir sorun olduğunda ikincil bölgeden okuyarak uygulamanızı geçici hataları veya önemli kesintileri işleyecek şekilde tasarlayabilirsiniz. Birincil bölge yeniden kullanılabilir olduğunda, uygulamanız birincil bölgeden okumaya geri dönebilir.

Uygulamanızı RA-GRS veya RA-GZRS kullanarak kullanılabilirlik ve dayanıklılık için tasarlarken dikkat edilmesi gereken önemli noktaları aklınızda bulundurun:

  • Birincil bölgede depoladığınız verilerin salt okunur bir kopyası, ikincil bölgede zaman uyumsuz olarak çoğaltılır. Bu zaman uyumsuz çoğaltma, ikincil bölgedeki salt okunur kopyanın sonunda birincil bölgedeki verilerle tutarlı olduğu anlamına gelir. Depolama hizmeti ikincil bölgenin konumunu belirler.

  • Birincil bölge uç noktasında okuma ve güncelleştirme istekleri gerçekleştirmek için Azure Depolama istemci kitaplıklarını kullanabilirsiniz. Birincil bölge kullanılamıyorsa, okuma isteklerini otomatik olarak ikincil bölgeye yönlendirebilirsiniz. Ayrıca uygulamanızı, birincil bölge kullanılabilir olduğunda bile okuma isteklerini doğrudan ikincil bölgeye gönderecek şekilde yapılandırabilirsiniz.

  • Birincil bölge kullanılamaz duruma gelirse, bir hesap yük devretmesi başlatabilirsiniz. İkincil bölgeye yük devreddiğinizde, birincil bölgeyi işaret eden DNS girişleri ikincil bölgeyi işaret eden şekilde değiştirilir. Yük devretme tamamlandıktan sonra GRS ve RA-GRS hesapları için yazma erişimi geri yüklenir. Daha fazla bilgi için bkz . Olağanüstü durum kurtarma ve depolama hesabı yük devretme.

Nihai tutarlı verilerle çalışma

Önerilen çözüm, eski olabilecek verileri çağıran uygulamaya döndürmenin kabul edilebilir olduğunu varsayar. İkincil bölgedeki veriler nihai olarak tutarlı olduğundan, ikincil bölgede yapılan bir güncelleştirme çoğaltmayı tamamlamadan önce birincil bölgeye erişilemez hale gelebilir.

Örneğin, müşterinizin güncelleştirmeyi başarıyla gönderdiğini, ancak birincil bölgenin güncelleştirme ikincil bölgeye yayılmadan önce başarısız olduğunu varsayalım. Müşteri verileri yeniden okumak istediğinde, güncelleştirilmiş veriler yerine ikincil bölgeden eski verileri alır. Uygulamanızı tasarlarken, bu davranışın kabul edilebilir olup olmadığına karar vermeniz gerekir. Bu durumda, kullanıcıya nasıl bildirimde bulunabileceğinizi de göz önünde bulundurmanız gerekir.

Bu makalenin ilerleyen bölümlerinde, nihai tutarlı verileri işleme ve birincil ve ikincil bölgelerdeki veriler arasındaki tutarsızlıkları değerlendirmek için Son Eşitleme Zamanı özelliğini denetleme hakkında daha fazla bilgi edineceksiniz.

Hizmetleri ayrı ayrı veya tümünü birlikte işleme

Olası olmasa da, diğer hizmetler tam olarak çalışır durumdayken bir hizmetin (bloblar, kuyruklar, tablolar veya dosyalar) kullanılamaz duruma gelmesi mümkündür. Her hizmetin yeniden denemelerini ayrı ayrı işleyebilir veya tüm depolama hizmetleri için yeniden denemeleri birlikte genel olarak işleyebilirsiniz.

Örneğin, uygulamanızda kuyruklar ve bloblar kullanıyorsanız, her hizmet için yeniden denenebilir hataları işlemek için ayrı kodlar koymaya karar vekleyebilirsiniz. Bu şekilde, blob hizmeti hatası uygulamanızın yalnızca bloblarla ilgilenen bölümünü etkiler ve kuyrukların normal şekilde çalışmaya devam etmesi için bırakır. Ancak, tüm depolama hizmeti yeniden denemelerini birlikte işlemeye karar verirseniz, hizmetlerden biri yeniden denenebilir bir hata döndürürse hem blob hem de kuyruk hizmetlerine yönelik istekler etkilenir.

Sonuç olarak, bu karar uygulamanızın karmaşıklık düzeyine bağlıdır. Yeniden denemelerin etkisini sınırlamak için hataları hizmete göre işlemeyi tercih edebilirsiniz. Ya da birincil bölgedeki herhangi bir depolama hizmetiyle ilgili bir sorun algıladığınızda tüm depolama hizmetleri için okuma isteklerini ikincil bölgeye yönlendirmeye karar vekleyebilirsiniz.

Uygulamanızı salt okunur modda çalıştırma

Birincil bölgede bir kesintiye etkili bir şekilde hazırlanmak için uygulamanızın hem başarısız okuma isteklerini hem de başarısız güncelleştirme isteklerini işleyebilmesi gerekir. Birincil bölge başarısız olursa, okuma istekleri ikincil bölgeye yeniden yönlendirilebilir. Ancak, ikincil bölgedeki çoğaltılan veriler salt okunur olduğundan güncelleştirme istekleri yeniden yönlendirilemiyor. Bu nedenle, uygulamanızı salt okunur modda çalıştırabilecek şekilde tasarlamanız gerekir.

Örneğin, güncelleştirme istekleri Azure Depolama'ya gönderilmeden önce denetlenen bir bayrak ayarlayabilirsiniz. Bir güncelleştirme isteği geldiğinde, isteği atlayabilir ve kullanıcıya uygun bir yanıt döndürebilirsiniz. Hatta sorun çözülene kadar belirli özellikleri tamamen devre dışı bırakabilir ve kullanıcılara özelliklerin geçici olarak kullanılamadığını bildirebilirsiniz.

Her hizmet için hataları ayrı ayrı işlemeye karar verirseniz, uygulamanızı hizmete göre salt okunur modda çalıştırma özelliğini de işlemeniz gerekir. Örneğin, her hizmet için salt okunur bayraklar ayarlayabilirsiniz. Ardından, gerektiğinde koddaki bayrakları etkinleştirebilir veya devre dışı bırakabilirsiniz.

Uygulamanızı salt okunur modda çalıştırabilmek, büyük bir uygulama yükseltmesi sırasında sınırlı işlevsellik sağlayabilmenizi de sağlar. Uygulamanızı salt okunur modda çalışacak şekilde tetikleyebilir ve ikincil veri merkezine işaret ederek yükseltmeler yaparken birincil bölgedeki verilere kimsenin erişmemesini sağlayabilirsiniz.

Salt okunur modda çalışırken güncelleştirmeleri işleme

Salt okunur modda çalışırken güncelleştirme isteklerini işlemenin birçok yolu vardır. Bu bölümde dikkate alınması gereken birkaç genel desene odaklanılır.

  • Kullanıcıya yanıt verebilir ve güncelleştirme isteklerinin şu anda işlenmediğini bildirebilirsiniz. Örneğin, kişi yönetim sistemi kullanıcıların kişi bilgilerine erişmesine olanak tanıyabilir ancak güncelleştirme yapamaz.

  • Güncelleştirmelerinizi başka bir bölgede sıralayabilirsiniz. Bu durumda bekleyen güncelleştirme isteklerinizi farklı bir bölgedeki kuyruğa yazar ve birincil veri merkezi yeniden çevrimiçi olduktan sonra bu istekleri işlersiniz. Bu senaryoda, kullanıcıya güncelleştirme isteğinin daha sonra işlenmek üzere kuyruğa alındığını bildirmeniz gerekir.

  • Güncelleştirmelerinizi başka bir bölgedeki bir depolama hesabına yazabilirsiniz. Birincil bölge yeniden çevrimiçi olduğunda, verilerin yapısına bağlı olarak bu güncelleştirmeleri birincil verilerle birleştirebilirsiniz. Örneğin, adında tarih/saat damgası bulunan ayrı dosyalar oluşturuyorsanız, bu dosyaları birincil bölgeye geri kopyalayabilirsiniz. Bu çözüm günlük ve IoT verileri gibi iş yükleri için geçerli olabilir.

Yeniden denemeleri işleme

Bulutta çalışan hizmetlerle iletişim kuran uygulamaların, oluşabilecek planlanmamış olaylara ve hatalara duyarlı olması gerekir. Bu hatalar geçici veya kalıcı olabilir ve anlık bağlantı kaybından doğal bir afet nedeniyle önemli bir kesintiye kadar sürebilir. Kullanılabilirliği en üst düzeye çıkarmak ve genel uygulama kararlılığını artırmak için bulut uygulamalarını uygun yeniden deneme işleme ile tasarlamak önemlidir.

okuma istekleri

Birincil bölge kullanılamaz hale gelirse, okuma istekleri ikincil depolamaya yeniden yönlendirilebilir. Daha önce belirtildiği gibi uygulamanızın eski verileri okuması kabul edilebilir olmalıdır. Azure Depolama istemci kitaplığı, yeniden denemeleri işlemeye ve okuma isteklerini ikincil bir bölgeye yönlendirmeye yönelik seçenekler sunar.

Bu örnekte, Blob depolama için yeniden deneme işleme sınıfında yapılandırılır BlobClientOptions ve bu yapılandırma seçeneklerini kullanarak oluşturduğumuz nesneye BlobServiceClient uygulanır. Bu yapılandırma birincil bölgeden okuma isteği yeniden denemelerinin ikincil bölgeye yeniden yönlendirildiği birincil ve ikincil bir yaklaşımdır. Birincil bölgedeki hataların geçici olması beklendiğinde bu yaklaşım en iyisidir.

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob storage
BlobClientOptions blobClientOptions = new BlobClientOptions()
{
    Retry = {
        // The delay between retry attempts for a fixed approach or the delay
        // on which to base calculations for a backoff-based approach
        Delay = TimeSpan.FromSeconds(2),

        // The maximum number of retry attempts before giving up
        MaxRetries = 5,

        // The approach to use for calculating retry delays
        Mode = RetryMode.Exponential,

        // The maximum permissible delay between retry attempts
        MaxDelay = TimeSpan.FromSeconds(10)
    },

    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for 
    // GET or HEAD requests during retries.
    // If the status of the response from the secondary Uri is a 404, then subsequent retries
    // for the request will not use the secondary Uri again, as this indicates that the resource 
    // may not have propagated there yet.
    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
    GeoRedundantSecondaryUri = secondaryAccountUri
};

// Create a BlobServiceClient object using the configuration options above
BlobServiceClient blobServiceClient = new BlobServiceClient(primaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

Birincil bölgenin uzun süre kullanılamayabileceğini belirlerseniz, tüm okuma isteklerini ikincil bölgeyi işaret etmek üzere yapılandırabilirsiniz. Bu yapılandırma yalnızca ikincil bir yaklaşımdır. Daha önce açıklandığı gibi, bu süre boyunca güncelleştirme isteklerini işlemek için bir stratejiye ve kullanıcıları yalnızca okuma isteklerinin işlendiğini bildirmenin bir yoluna ihtiyacınız olacaktır. Bu örnekte, ikincil bölge uç noktasını kullanan yeni bir örneği BlobServiceClient oluşturacağız.

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Create a BlobServiceClient object pointed at the secondary Uri
// Use blobServiceClientSecondary only when issuing read requests, as secondary storage is read-only
BlobServiceClient blobServiceClientSecondary = new BlobServiceClient(secondaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

Salt okunur moda ve yalnızca ikincil isteklere ne zaman geçileceğini bilmek, devre kesici deseni olarak adlandırılan mimari tasarım deseninin bir parçasıdır ve bu desen daha sonraki bir bölümde ele alınacaktır.

güncelleştirme istekleri

Güncelleştirme istekleri salt okunur olan ikincil depolama alanına yönlendirilemiyor. Daha önce açıklandığı gibi, birincil bölge kullanılamadığında uygulamanızın güncelleştirme isteklerini işleyebilmesi gerekir.

Bağlantı Hattı Kesici düzeni, güncelleştirme isteklerine de uygulanabilir. Güncelleştirme isteği hatalarını işlemek için kodda 10 ardışık hata gibi bir eşik ayarlayabilir ve birincil bölgeye yönelik isteklerin hata sayısını izleyebilirsiniz. Eşik karşılandıktan sonra, birincil bölgeye yönelik güncelleştirme isteklerinin artık verilmemesi için uygulamayı salt okunur moda geçirebilirsiniz.

Devre Kesici düzenini uygulama

Kurtarması uzun sürebilecek hataların işlenmesi , Devre Kesici deseni olarak adlandırılan mimari tasarım deseninin bir parçasıdır. Bu düzenin düzgün bir şekilde uygulanması, bir uygulamanın başarısız olma olasılığı olan bir işlemi tekrar tekrar yürütmeye çalışmasını önleyerek uygulama kararlılığını ve dayanıklılığını artırır.

Devre Kesici düzeninin bir yönü, birincil uç noktayla ilgili devam eden bir sorun olup olmadığını belirlemektir. Bu belirlemeyi yapmak için istemcinin yeniden denenebilir hatalarla ne sıklıkta karşılaştığını izleyebilirsiniz. Her senaryo farklı olduğundan, ikincil uç noktaya geçme ve uygulamayı salt okunur modda çalıştırma kararı için kullanılacak uygun eşiği belirlemeniz gerekir.

Örneğin, birincil bölgede ardışık 10 hata varsa anahtarı gerçekleştirmeye karar vekleyebilirsiniz. Koddaki hataların sayısını tutarak bunu izleyebilirsiniz. Eşiğe ulaşmadan önce başarılı olursa sayıyı sıfır olarak ayarlayın. Sayı eşiğe ulaşırsa, uygulamayı okuma istekleri için ikincil bölgeyi kullanacak şekilde değiştirin.

Alternatif bir yaklaşım olarak, uygulamanızda özel bir izleme bileşeni uygulamaya karar vekleyebilirsiniz. Bu bileşen, durumunu belirlemek için birincil depolama uç noktanıza sürekli olarak önemsiz okuma istekleriyle (küçük bir blob okuma gibi) ping yapabilir. Bu yaklaşım bazı kaynakları kapsayabilir ancak önemli bir miktarda almaz. Eşiğinize ulaşan bir sorun bulunduğunda yalnızca ikincil okuma isteklerine ve salt okunur moda geçersiniz. Bu senaryo için, birincil depolama uç noktasına ping işlemi yeniden başarılı olduğunda birincil bölgeye geri dönebilir ve güncelleştirmelere izin verme işlemine devam edebilirsiniz.

Geçişin ne zaman yapılabileceğini belirlemek için kullanılan hata eşiği, uygulamanız içinde hizmetten hizmete farklılık gösterebilir, bu nedenle bunları yapılandırılabilir parametreler yapmayı göz önünde bulundurmalısınız.

Bir diğer önemli nokta da bir uygulamanın birden çok örneğini işleme ve her örnekte yeniden denenebilir hatalar algıladığınızda ne yapmanız gerektiğidir. Örneğin, aynı uygulama yüklenmiş olarak çalışan 20 VM'niz olabilir. Her örneği ayrı ayrı mı işliyebilirsiniz? Bir örnek sorun yaşamaya başlarsa, yanıtı yalnızca bu örnekle sınırlamak istiyor musunuz? Yoksa bir örnek sorun olduğunda tüm örneklerin aynı şekilde yanıt vermesini mi istiyorsunuz? Örnekleri ayrı ayrı işlemek, yanıt üzerinde eşgüdüm sağlamaya çalışmaktan çok daha kolaydır, ancak yaklaşımınız uygulamanızın mimarisine bağlıdır.

Nihai tutarlı verileri işleme

Coğrafi olarak yedekli depolama, işlemleri birincil bölgeden ikincil bölgeye çoğaltarak çalışır. Çoğaltma işlemi, ikincil bölgedeki verilerin sonunda tutarlı olduğunu garanti eder. Bu, birincil bölgedeki tüm işlemlerin sonunda ikincil bölgede görüneceği, ancak görünmeden önce bir gecikme olabileceği anlamına gelir. ayrıca, işlemlerin ilk olarak birincil bölgede uygulandığı sırayla ikincil bölgeye ulaşacağı garanti değildir. İşlemleriniz ikincil bölgeye sıra dışı olarak ulaşırsa, hizmet yetişene kadar ikincil bölgedeki verilerinizin tutarsız durumda olduğunu düşünebilirsiniz .

Aşağıdaki Azure Tablo depolama örneği, bir çalışanı yönetici rolüne üye yapmak için ayrıntılarını güncelleştirdiğinizde neler olabileceğini gösterir. Bu örnekte çalışan varlığını güncelleştirmeniz ve yönetici rolü varlığını toplam yönetici sayısıyla güncelleştirmeniz gerekir. Güncelleştirmelerin ikincil bölgede sıra dışı olarak nasıl uygulandığına dikkat edin.

Saat İşlem Çoğaltma Son Eşitleme Zamanı Sonuç
T0 İşlem A:
Çalışan ekle
birincil varlık
A işlemi birincile eklendi,
henüz çoğaltılmadı.
T1 İşlem A
çoğaltılan
Ikincil
T1 İkincil olarak çoğaltılan A işlemi.
Son Eşitleme Zamanı güncelleştirildi.
T2 İşlem B:
Güncelleştir
çalışan varlığı
birincilde
T1 B işlemi birincile yazılır,
henüz çoğaltılmadı.
T3 İşlem C:
Güncelleştir
yönetici
rol varlığı
Birincil
T1 C işleminin birincile yazıldı,
henüz çoğaltılmadı.
T4 İşlem C
çoğaltılan
Ikincil
T1 C işlemi ikincil değere çoğaltıldı.
LastSyncTime güncelleştirilmedi çünkü
B işlemi henüz çoğaltılmadı.
T5 Varlıkları okuma
ikincil kaynaktan
T1 Çalışan için eski değeri alırsınız
varlık çünkü B işlemi henüz
henüz çoğaltıldı. Için yeni değeri alırsınız
C'de olduğundan yönetici rolü varlığı
Çoğaltılmış. Son Eşitleme Zamanı hala aynı değil
B işlemi nedeniyle güncelleştirildi
çoğaltılmamıştır. Şunu söyleyebilirsiniz:
yönetici rolü varlığı tutarsız
varlık tarihi/saati sonra olduğundan
Son Eşitleme Zamanı' nı seçin.
T6 İşlem B
çoğaltılan
Ikincil
T6 T6 – C üzerinden yapılan tüm işlemler
çoğaltıldı, Son Eşitleme Zamanı
güncelleştirilir.

Bu örnekte, istemcinin T5'teki ikincil bölgeden okumaya geçtiği varsayılır. Şu anda yönetici rolü varlığını başarıyla okuyabilir, ancak varlık şu anda ikincil bölgede yönetici olarak işaretlenmiş çalışan varlıklarının sayısıyla tutarlı olmayan yönetici sayısı için bir değer içerir. İstemciniz, bilgilerin tutarsız olması riskiyle birlikte bu değeri görüntüleyebilir. Alternatif olarak istemci, güncelleştirmeler düzgün gerçekleşmediğinden yönetici rolünün tutarsız durumda olduğunu belirlemeye çalışır ve ardından kullanıcıyı bu olgu hakkında bilgilendirebilir.

Bir depolama hesabının tutarsız olabilecek verileri olup olmadığını belirlemek için istemci , Son Eşitleme Zamanı özelliğinin değerini denetleyebilir. Son Eşitleme Zamanı , ikincil bölgedeki verilerin en son tutarlı olduğu zamanı ve hizmetin bu noktadan önceki tüm işlemleri ne zaman uyguladığını bildirir. Yukarıda gösterilen örnekte, hizmet çalışan varlığını ikincil bölgeye ekledikten sonra son eşitleme zamanı T1 olarak ayarlanır. Hizmet, T6 olarak ayarlandığında ikincil bölgedeki çalışan varlığını güncelleştirene kadar T1'de kalır. İstemci , T5'te varlığı okuduğunda son eşitleme zamanını alırsa, varlığın zaman damgasıyla karşılaştırabilir. Varlıktaki zaman damgası son eşitleme zamanından sonraysa varlık tutarsız durumdadır ve uygun eylemi gerçekleştirebilirsiniz. Bu alanı kullanmak için birincile yapılan son güncelleştirmenin ne zaman tamamlandığını bilmeniz gerekir.

Son eşitleme zamanını denetlemeyi öğrenmek için bkz. Depolama hesabı için Son Eşitleme Zamanı özelliğini denetleme.

Test Etme

Uygulamanızın yeniden denenebilir hatalarla karşılaştığında beklendiği gibi davranıp davranmadığını test etmek önemlidir. Örneğin, uygulamanın bir sorun algıladığında ikincil bölgeye geçiş yapıp birincil bölge yeniden kullanılabilir olduğunda geri döndüğünü test etmeniz gerekir. Bu davranışı düzgün bir şekilde test etmek için yeniden denenebilir hataların benzetimini yapmak ve bunların oluşma sıklıklarını denetlemek için bir yönteme ihtiyacınız vardır.

Bir seçenek, betikteki HTTP yanıtlarını kesmek ve değiştirmek için Fiddler kullanmaktır. Bu betik, birincil uç noktanızdan gelen yanıtları tanımlayabilir ve HTTP durum kodunu Depolama istemci kitaplığının yeniden denenebilir hata olarak tanıdığı yanıtlarla değiştirebilir. Bu kod parçacığı, 502 durumunu döndürmek için employeedata tablosuna yönelik okuma isteklerine verilen yanıtları kesen basit bir Fiddler betiği örneğini gösterir:

static function OnBeforeResponse(oSession: Session) {
    ...
    if ((oSession.hostname == "\[YOURSTORAGEACCOUNTNAME\].table.core.windows.net")
      && (oSession.PathAndQuery.StartsWith("/employeedata?$filter"))) {
        oSession.responseCode = 502;
    }
}

Bu örneği daha geniş bir istek aralığını kesecek şekilde genişletebilir ve gerçek bir senaryonun benzetimini daha iyi yapmak için yalnızca bazılarında responseCode değerini değiştirebilirsiniz. Fiddler betiklerini özelleştirme hakkında daha fazla bilgi için Fiddler belgelerindeki İstek veya Yanıtı Değiştirme bölümüne bakın.

Uygulamanızı salt okunur olarak değiştirmek için yapılandırılabilir eşikler ayarladıysanız, üretim dışı işlem hacimleriyle davranışı test etmek daha kolay olacaktır.


Sonraki adımlar

Birincil ve ikincil uç noktalar arasında geçiş yapmayı gösteren eksiksiz bir örnek için bkz. Azure Örnekleri – RA-GRS depolama ile Devre Kesici Düzenini Kullanma.