Azure Service Fabric olağanüstü durum kurtarma

Yüksek kullanılabilirlik sunmaya yönelik kritik bir bölüm, hizmetlerin tüm farklı türdeki hataların varlığını sürdürmesini sağlamaktır. Bu özellikle, planlanmamış ve denetiminizin dışından oluşan hatalarda önemlidir.

Bu makalede, doğru Modellenmemiş ve yönetilmiyorsa olağanüstü durumlar olabilecek bazı yaygın hata modları açıklanmaktadır. Ayrıca, bir olağanüstü durum yine de gerçekleşse de hafifletmede gerçekleştirilecek işlemler açıklanmaktadır. Amaç, gerçekleşen veya aksi takdirde meydana gelme durumunda kapalı kalma süresi veya veri kaybı riskini sınırlandırmaktır veya ortadan kaldırır.

Olağanüstü durumdan kaçınma

Azure Service Fabric 'nin ana amacı, hem ortamınızı hem de hizmetlerinizi ortak hata türleri olağanüstü durumlar olmayan bir şekilde modeletmenize yardımcı olmaktır.

Genel olarak, iki tür olağanüstü durum/başarısızlık senaryosu vardır:

• Donanım ve yazılım hataları
• İşletimsel hatalar

Donanım ve yazılım hataları

Donanım ve yazılım hataları tahmin edilemez. Arızaların en kolay yolu, hizmetin donanım veya yazılım hatası sınırları genelinde daha fazla kopyasını çalıştırıyor.

Örneğin, hizmetiniz yalnızca bir makine üzerinde çalışıyorsa, söz konusu hizmet için bu makinenin bir olağanüstü durum olması gerekir. Bu olağanüstü durumdan kaçınmanın basit yolu, hizmetin birden fazla makinede çalıştığından emin olmak. Test, bir makinenin başarısızlığının çalışan hizmeti kesintiye uğramasını sağlamak için de gereklidir. Kapasite planlaması, bir değiştirme örneğinin başka bir yerde oluşturulmasını ve kapasiteden azaltmanın kalan Hizmetleri aşırı yükmesini sağlar.

Aynı model, arızasından kaçınmak için ne olursa olsun, işe yarar. Örneğin, bir SAN hatası hakkında endişeleriniz varsa, birden çok San arasında çalıştırırsınız. Bir sunucu rafı kaybı hakkında endişeleriniz varsa, birden çok rafta çalıştırılırsınız. Veri merkezlerinin kaybedilmesi konusunda endişeli varsa, hizmetiniz birden fazla Azure bölgesinde, birden çok Azure Kullanılabilirlik Alanları veya kendi veri merkezlerinizde çalışmalıdır.

Bir hizmet birden çok fiziksel örneğe (makineler, raflar, veri merkezi, bölge) yayıldığınızda, yine de bazı eşzamanlı arızalara tabi olursunuz. Ancak, belirli bir türdeki (örneğin, tek bir sanal makine veya ağ bağlantısı başarısız) birden çok hata, otomatik olarak işlenir ve bu nedenle artık "olağanüstü durum" olmaz.

Service Fabric, kümeyi genişletmeye yönelik mekanizmalar sağlar ve başarısız olan düğümleri ve hizmetleri geri getiren işler. Service Fabric Ayrıca, planlanmamış hataların gerçek felaketlere dönmesini engellemek için hizmetlerinizin birçok örneğinin çalıştırılmasına izin verir.

Dağıtım başarısızlıklar için yeterince büyük bir dağıtımı çalıştırmanın olası nedenleri olabilir. Örneğin, hata ihtimaline göre ödeme yapmayı amaçlamadan daha fazla donanım kaynağı alabilir. Dağıtılmış uygulamalarla ilgilenirken, coğrafi uzaklıklarda ek iletişim atlamaları veya durum çoğaltma maliyetleri kabul edilemez gecikmeye neden olabilir. Bu çizginin her bir uygulama için farklı çizilir.

Özellikle yazılım hatalarında hata, ölçeklendirmeye çalıştığınız hizmette olabilir. Bu durumda, hata koşulu tüm örneklerde bağıntılı olduğundan, çok sayıda kopya olağanüstü durum oluşmasını engellemez.

İşletimsel hatalar

Hizmetiniz birçok artıklıkları sahip dünya genelinde yayılsa bile, felaket olayları yaşamaya devam edebilir. Örneğin, birisi hizmetin DNS adını yanlışlıkla yeniden yapılandırabilir veya onu silebilir.

Örnek olarak, durum bilgisi olan bir Service Fabric hizmetiniz olduğunu ve birisi bu hizmeti yanlışlıkla silmiş olduğunu varsayalım. Başka bir risk azaltma, bu hizmet ve sahip olduğu tüm durumlar dışında. Bu tür işlemsel olağanüstü durumlar ("Yani"), düzenli plansız hatalardan farklı azaltmaları ve işlemler gerektirir.

Bu tür işletimsel hataların oluşmaması için en iyi yollar şunlardır:

• Ortama işlemsel erişimi kısıtlayın.
• Tehlikeli işlemleri kesinlikle denetleyin.
• Otomasyon yapın, el ile veya bant dışı değişiklikleri önleyin ve ortama göre belirli değişiklikleri ortama göre doğrular.
• Bozucu işlemlerin "Soft" olduğundan emin olun. Geçici işlemler hemen etkili olmaz veya bir zaman penceresi içinde geri alınamaz.

Service Fabric, küme işlemleri için rol tabanlı erişim denetimi sağlama gibi işletimsel hataların önlenmesi için mekanizmalar sağlar. Ancak, bu işletimsel hataların çoğu kuruluş çalışmalarını ve diğer sistemleri gerektirir. Service Fabric, işlem hatalarının büyük bir şekilde yedekleme ve durum bilgisi olan hizmetler için geri yüklememekanizmaları sağlar.

Sorunları yönetme

Service Fabric amacı, hataların otomatik olarak yönetimi olur. Ancak bazı başarısızlık türlerini işlemek için hizmetlerin ek kodu olmalıdır. Diğer başarısızlık türleri, güvenlik ve iş sürekliliği nedenleriyle otomatik olarak değinmemelidir.

Tek başarısızlık işleme

Tek makineler, tüm nedenlerden dolayı başarısız olabilir. Bazen güç kaynakları ve ağ donanım arızaları gibi donanım nedenleridir. Diğer sorunlar yazılımda bulunur. Bunlar, işletim sistemi ve hizmetin arızalarını içerir. Service Fabric, ağ sorunları nedeniyle makinenin diğer makinelerden yalıtıldığı durumlar da dahil olmak üzere bu tür hataları otomatik olarak algılar.

Hizmetin türü ne olursa olsun, tek bir örnek çalıştırıldığında kodun tek bir kopyası herhangi bir nedenle başarısız olursa, bu hizmet için kapalı kalma süresi oluşur.

Tek bir hatayı işlemek için, yapabileceğiniz en basit şey, hizmetlerinizin varsayılan olarak birden fazla düğüm üzerinde çalışmasını sağlamaktır. Durum bilgisi olmayan hizmetler için 1 ' InstanceCount den büyük olduğundan emin olun. Durum bilgisi olan hizmetler için en düşük öneri, TargetReplicaSetSize MinReplicaSetSize her ikisi de 3 olarak ayarlanmıştır. Hizmet kodunuzun daha fazla kopyasını çalıştırmak, hizmetinizin tek bir hatayı otomatik olarak işlemesini sağlar.

Eşgüdümlü sorunları işleme

Küme içindeki Eşgüdümlü hatalara, planlı veya planlanmamış altyapı hatalarından ve değişikliklerden veya planlı yazılım değişikliklerinden kaynaklanabilir. Service Fabric, hata etki alanları olarak Eşgüdümlü hatalarla karşılaşan altyapı bölgelerini modelleyin. Koordine edilen yazılım değişikliklerini deneyime yönelik alanlara yükseltme etki alanları olarak modellenir. Hata etki alanları, yükseltme etki alanları ve küme topolojisi hakkında daha fazla bilgi için bkz. küme kaynak yöneticisi kullanarak Service Fabric kümesi tanımlama.

Service Fabric, hizmetlerinizin nerede çalışacağını planlarken, hata ve yükseltme etki alanlarını varsayılan olarak değerlendirir. Service Fabric, varsayılan olarak, hizmetlerinizin birkaç hata ve yükseltme etki alanında çalıştığından emin olmaya çalışır, böylece planlanmış veya planlanmamış değişiklikler meydana geliyorsa, hizmetleriniz kullanılabilir kalır.

Örneğin, bir güç kaynağı hatasının, bir rafa ait tüm makinelerin aynı anda başarısız olmasına neden olduğunu varsayalım. Hizmetin birden fazla kopyası çalışırken, hata etki alanı hatasında çok sayıda makinenin kaybolması, bir hizmet için tek bir başarısızlığın yalnızca başka bir örneğini döndürür. Bu, hizmetlerinizin yüksek kullanılabilirlik sağlamak için hata ve yükseltme etki alanlarının yönetilmesine neden önemlidir.

Azure 'da Service Fabric çalıştırırken, hata etki alanları ve yükseltme etki alanları otomatik olarak yönetilir. Diğer ortamlarda, bu olmayabilir. Şirket içinde kendi kümelerinizi oluşturuyorsanız, hata etki alanı düzeninizi doğru şekilde eşleştirdiğinizden ve planladığınızdan emin olun.

Yükseltme etki alanları, yazılımın aynı anda yükseltilebileceği modelleme alanları için faydalıdır. Bu nedenle, yükseltme etki alanları da genellikle planlanan yükseltmeler sırasında yazılımın kapatıldığı sınırları tanımlar. Hem Service Fabric hem de hizmetlerinizin yükseltmeleri aynı modeli izler. Sıralı yükseltmeler, yükseltme etki alanları ve istenmeyen değişikliklerin kümeyi ve hizmetinizi etkilemesini önlemeye yardımcı olan Service Fabric sistem durumu modeli hakkında daha fazla bilgi için, bkz.:

• Uygulama yükseltme
• Uygulama yükseltme öğreticisi
• Service Fabric sistem durumu modeli

Service Fabric Explorer' de belirtilen küme eşlemesini kullanarak kümenizin yerleşimini görselleştirebilirsiniz:

Eşzamanlı donanım veya yazılım başarısızlıklarını işleme

Tek hatalardan bahsetik. Gördüğünüz gibi, hata ve yükseltme etki alanlarında çalışan kodun (ve durumun) daha fazla kopyasını tutarak hem durum bilgisi olmayan hem de durum bilgisi olan hizmetler için kolayca idare edilebilir.

Birden çok eşzamanlı rastgele başarısızlık da oluşabilir. Bunlar, kapalı kalma süresine veya gerçek bir olağanüstü duruma neden olabilir.

Durum bilgisi olmayan hizmetler

Durum bilgisi olmayan bir hizmetin örnek sayısı, çalışması gereken birkaç örnek sayısını gösterir. Örneklerin herhangi biri (veya tümü) başarısız olduğunda, Service Fabric diğer düğümlerde otomatik olarak değiştirme örnekleri oluşturarak yanıt verir. Service Fabric, hizmet istenen örnek sayısına geri alınana kadar değişiklik oluşturmaya devam eder.

Örneğin, durum bilgisi olmayan hizmetin InstanceCount -1 değerine sahip olduğunu varsayalım. Bu değer, kümedeki her düğümde bir örnek çalıştırılması gereken anlamına gelir. Bu örneklerden bazıları başarısız olursa, Service Fabric hizmetin istenen durumunda olmadığını algılar ve örnekleri eksik oldukları düğümlerde oluşturmaya çalışır.

Durum bilgisi olan hizmetler

Durum bilgisi olan iki tür hizmet vardır:

• Kalıcı durumu olan durumlu.
• Kalıcı olmayan durumla durumlu. (Durum bellekte depolanır.)

Durum bilgili bir hizmetin hatasından kurtarma, durum bilgisi olan hizmetin türüne, hizmetin kaç çoğaltması olduğuna ve kaç çoğaltmanın başarısız olduğuna bağlıdır.

Durum bilgili bir hizmette, gelen veriler çoğaltmalar (birincil ve etkin ikinciller) arasında çoğaltılır. Çoğaltmaların büyük bir çoğunluğu verileri alırsa, veriler çekirdek olarak kabul edilir. (Beş çoğaltma için üç çoğaltma bir çekirdek olur.) Bu, herhangi bir noktada en son verilere sahip en az bir çoğaltma çekirdekleri olduğu anlamına gelir. Çoğaltmalar başarısız olursa (örneğin beşte iki), kurtarılabilir olup olamaysak hesaplamak için çekirdek değerini kullanabiliriz. (Kalan beş çoğaltmadan üçü hala kullanılabilir olduğundan, en az bir çoğaltmanın tam veriye sahip olduğu garantidir.)

Çoğaltmalardan bir çekirdek başarısız olduğunda, bölümün çekirdek kaybı durumda olduğu bildirildi. Bir bölümün beş çoğaltması olduğunu, yani en az üç çoğaltmanın eksiksiz veriye sahip olduğu garantisini içerir. Bir çekirdek (beşten üç) çoğaltma başarısız olursa, Service Fabric kalan çoğaltmaların (beşten iki) bölümü geri yüklemek için yeterli veriye sahip olup olmadığını belirleyemiyordur. Çekirdek Service Fabric algılayan durumlarda, varsayılan davranışı bölüme ek yazmaları önlemek, çekirdek kaybı bildir geçmek ve çoğaltmaların bir çekirdek geri yüklenecek şekilde beklemektir.

Durum bilgisi olan bir hizmet için olağanüstü durum olup olmadığını belirleme ve ardından bunu yönetme üç aşamadan oluşur:

1. Çekirdek kaybı olup olmadığını belirleme.

   Durum durumuna sahip bir hizmetin çoğaltmalarının büyük bir çoğunluğu aynı anda kapatıldı olduğunda çekirdek kaybı bildirildi.

2. Çekirdek kaybının kalıcı olup olmadığını belirleme.

   Çoğu zaman hatalar geçicidir. İşlemler yeniden başlatılır, düğümler yeniden başlatılır, sanal makineler yeniden başlatılır ve ağ bölümleri iyileşir. Ancak bazen hatalar kalıcıdır. Hataların kalıcı olup olmadığı, durum bilgili hizmetin durumunun kalıcı olup olmadığı veya yalnızca bellekte mi tutar?

   • Kalıcı durumu olmayan hizmetler için, bir çekirdek veya daha fazla çoğaltma hatası hemen kalıcı çekirdek kaybına neden olur. Durum Service Fabric olmayan bir hizmette çekirdek kaybı algılandığı zaman, hemen (olası) veri kaybı bildirerek 3. adıma ilerler. Veri kaybına devam etmek mantıklıdır Service Fabric çoğaltmaların geri dönmelerini beklemenin bir anlamı olmadığını bilir. Kurtarılsalar bile, hizmetin kalıcı olmayan doğası nedeniyle veriler kaybolur.
   • Durum bilgisi olan kalıcı hizmetler için, bir çekirdek veya daha fazla çoğaltmanın Service Fabric çoğaltmaların geri gelip çekirdek geri yüklemesini beklemesi gerekir. Bu, hizmetin etkilenen bölüme (veya "çoğaltma kümesine") yapılan yazmalar için hizmet kesintisi ile sonuç verir. Ancak, okumalar daha düşük tutarlılık garantileriyle yine de mümkün olabilir. Devam etmek bir (olası) veri kaybı Service Fabric ve diğer riskleri taşıdığından, çekirdek için geri yüklenen varsayılan süre sonsuzdur. Başka bir Service Fabric, yönetici veri kaybı bildirecek bir eylemde olmadığı sürece bir sonraki adıma geçilamayacak anlamına gelir.

3. Verilerin kaybedilip kaybedil olmadığını belirleme ve yedeklemelerden geri yükleme.

   Çekirdek kaybı bildirilirse (otomatik olarak veya yönetim eylemi aracılığıyla), Service Fabric ve hizmetler verilerin gerçekten kaybedilip kaybedil olmadığını belirlemeye devam eder. Bu noktada, Service Fabric diğer çoğaltmaların geri dön olmadığını da bilir. Çekirdek kaybının kendisini çözümlemesini beklemeyi durdurmuştuk. Hizmet için en iyi eylem planı genellikle donmak ve belirli bir yönetim müdahalesi için beklemektir.

   Bu Service Fabric yöntemini OnDataLossAsync çağırsa, bunun nedeni her zaman şüpheli veri kaybıdır. Service Fabric, bu çağrının kalan en iyi çoğaltmaya teslim edilir. Bu, en fazla ilerlemeyi hangi çoğaltmanın yaptığıdır.

   Veri kaybı şüphesi olduğunu her zaman söylemenin nedeni, kalan çoğaltmanın çekirdek kaybedilirken birincil çoğaltmayla aynı durumla aynı olması mümkündür. Ancak, bu durum olmadan karşılaştırma yapmak için, Service Fabric operatörlerin emin olmak için iyi bir yolu yoktur.

   Peki yöntemin tipik bir uygulaması OnDataLossAsync ne yapar?

   1. Tetiklenen OnDataLossAsync uygulama günlükleri ve gerekli yönetim uyarılarını tetikler.

   2. Genellikle, uygulama duraklatılır ve daha fazla karar ve el ile ileriye doğru eylemlerin uygulanması için bekler. Bunun nedeni, yedeklemeler kullanılabilir olsa bile bunların hazırlıklı olması gerektir.

      Örneğin, iki farklı hizmet bilgileri koordine ediyorsa, geri yükleme yapıldıktan sonra bu iki hizmetle ilgili bilgilerin tutarlı olmasını sağlamak için bu yedeklemelerin değiştirilmiş olması gerekir.

   3. Genellikle hizmetten başka telemetri verileri veya tükenmeler olur. Bu meta veriler diğer hizmetlerde veya günlüklerde yer alan veriler olabilir. Bu bilgiler, yedeklemede mevcut olmayan veya bu çoğaltmaya çoğaltılmış birincilde alınan ve işlenen çağrılar olup olmadığını belirlemek için gerektiğinde kullanılabilir. Geri yüklemenin uygulanabilir olması için bu çağrıların yeniden oynatılabilir veya yedeklemeye ekleniyor olması gerekir.

   4. Uygulama, kalan çoğaltmanın durumunu kullanılabilir yedeklemelerde bulunanla karşılaştırıldığında. Güvenilir koleksiyonlar Service Fabric, bunu yapmak için araçlar ve işlemler vardır. Amaç, çoğaltma içindeki durumun yeterli olup olmadığını ve yedeklemenin eksik olup olmadığını görmektir.

   5. Karşılaştırma yapıldıktan sonra ve geri yükleme tamamlandıktan sonra (gerekirse), herhangi bir durum değişikliği yapıldıysa hizmet kodu true dönüş yapar. Çoğaltma, durumunun kullanılabilir en iyi kopyası olduğunu belirledi ve hiçbir değişiklik yaptı, kod false döndürür.

      true değeri, kalan diğer çoğaltmaların artık bu çoğaltmayla tutarsız olabileceğini gösterir. Bunlar bu çoğaltmadan bırakılır ve yeniden oluşturulur. false değeri, durum değişikliği olmadığını gösterir, bu nedenle diğer çoğaltmalar sahip olduklarını tutsalar.

Hizmet yazarlarının, hizmetler üretime dağıtılamadan önce olası veri kaybı ve hata senaryolarını uygulaması kritik öneme sahiptir. Veri kaybı olasılığını önlemek için, durum bilgili hizmetlerinizin durumunu coğrafi olarak yedekli bir depoya düzenli aralıklarla yedeklemeniz önemlidir.

Ayrıca durumu geri yükleyebilme özelliğine sahip olduğundan da emin olmak gerekir. Birçok farklı hizmet farklı zamanlarda yedekli olduğundan, bir geri yüklemeden sonra hizmetlerinizin birbirinin tutarlı bir görünümünün olduğundan emin olun.

Örneğin, bir hizmetin bir sayı oluşturarak depolarak, sonra da bunu depo eden başka bir hizmete gönderdiği bir durumu düşünün. Geri yüklemeden sonra, ikinci hizmetin numaraya sahip olduğunu ancak ilk hizmetin bu numaraya sahip olmadığını keşfedersiniz çünkü yedekleme işlemi bu işlemi içermez.

Bir veri kaybı senaryosunda devam etmek için kalan çoğaltmaların yetersiz olduğunu ve hizmet durumunu telemetriden veya tükenmeden yeniden oluşturalamayabilirsiniz, yedekleme sıklığınız olası en iyi kurtarma noktası hedefinizi (RPO) belirler. Service Fabric, kalıcı çekirdek ve yedekten geri yükleme gerektiren veri kaybı gibi çeşitli hata senaryolarını test etmek için birçok araç sağlar. Bu senaryolar, Hata Analizi Hizmeti tarafından yönetilen Service Fabric testlanabilirlik araçlarının bir parçası olarak dahil edilir. Bu araçlar ve desenler hakkında daha fazla bilgi için bkz. Hata Analizi Hizmetine Giriş.

Çekirdek kaybı sorunlarını giderme

Geçici bir hata nedeniyle çoğaltmalar aralıklı olarak kesintiye neden olabilir. Bu tür bir Service Fabric kadar bekleyin. Çoğaltmalar beklenenden uzun bir süre boyunca kullanımdan açıksa şu sorun giderme eylemlerini izleyin:

• Çoğaltmalar kilitlenmeye neden olabilir. Çoğaltma düzeyinde sistem durumu raporlarını ve uygulama günlüklerinizi kontrol edin. Kilitlenme dökümlerini toplayın ve kurtarmak için gerekli eylemleri gerçekleştirin.
• Çoğaltma işlemi yanıt vermemeye başladı. Bunu doğrulamak için uygulama günlüklerinizi inceleyebilirsiniz. İşlem dökümlerini toplayın ve ardından yanıt vermemeye devam etmeyi durdurun. Service Fabric bir değiştirme işlemi oluşturacağız ve çoğaltmayı geri getirmeyi deneyecek.
• Çoğaltmaları barındıran düğümler kapatılabilir. Düğümleri yukarı getirmek için temel alınan sanal makineyi yeniden başlatın.

Bazen çoğaltmaları kurtarmak mümkün olmayacaktır. Örneğin, sürücüler başarısız oldu veya makineler fiziksel olarak yanıt vermiyor. Bu gibi durumlarda Service Fabric kurtarma için beklememeleri gerektiğinin söylenmektedir.

Hizmeti çevrimiçi hale getirmek için olası veri kaybı kabul edilemezse bu yöntemleri kullanmayın. Bu durumda, fiziksel makineleri kurtarmak için tüm çabalar gerekir.

Aşağıdaki eylemler veri kaybına neden olabilir. Bunları izlemeden önce kontrol edin.

• veya Repair-ServiceFabricPartition -PartitionId API'sini System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) kullanın. Bu API, çekirdek kaybından ve olası veri kaybına taşımak için bölümün kimliğini belirtmeye olanak sağlar.
• Kümeniz hizmetlerin çekirdek kaybı durumuna gitmelerine neden olan sık hatalarla karşılaşırsa ve olası veri kaybı kabul edilebilirse, uygun bir QuorumLossWaitDuration değeri belirterek hizmetinizin otomatik olarak kurtarılabilir. Service Fabric kurtarma gerçekleştirmeden önce QuorumLossWaitDuration sağlanan değeri bekler (varsayılan değer sonsuzdur). Beklenmedik veri kayıplarının oluşmasına neden olabileceğinden, bu yöntemi önermiyoruz.

Service Fabric kümesinin kullanılabilirliği

Genel olarak Service Fabric kümesi, tek hata noktası olmayan, yüksek oranda dağıtılmış bir ortamdır. Birincil olarak, Service Fabric sistem hizmetleri daha önce sunulan yönergeleri izlediğinden, herhangi bir düğüm, kümede kullanılabilirlik veya güvenilirlik sorunlarına yol açmaz. Diğer bir deyişle, her zaman varsayılan olarak üç veya daha fazla çoğaltma ve durum bilgisiz olmayan sistem hizmetleri tüm düğümlerde çalışır.

Temel Service Fabric ağ oluşturma ve hata algılama katmanları tamamen dağıtılır. Çoğu sistem hizmeti kümedeki meta verilerden yeniden oluşturulabilir veya durumlarını diğer yerlerden yeniden eşitleme yapabilir. Sistem Hizmetleri daha önce açıklananlar gibi çekirdek kaybı durumlarına geldiğinde kümenin kullanılabilirliği tehlikeye girebilir. Bu gibi durumlarda, küme üzerinde belirli işlemler gerçekleştiremeyebilirsiniz (yükseltme başlatma veya yeni hizmetleri dağıtma gibi), ancak kümenin kendisi hala çalışıyor olabilir.

Çalışan bir kümedeki hizmetler, çalışmaya devam etmek için sistem hizmetlerine yazma gerektirmedikleri takdirde bu koşullarda çalışmaya devam edecektir. Örneğin, Yük Devretme Yöneticisi çekirdek kaybolduysa, tüm hizmetler çalışmaya devam edecektir. Ancak, Yük Devretme Yöneticisi katılımına ihtiyaç duyduğundan, başarısız olan tüm hizmetler otomatik olarak yeniden başlatılamaz.

Veri merkezi veya Azure bölgesi sorunları

Nadir durumlarda, fiziksel bir veri merkezi güç veya ağ bağlantısı kaybından geçici olarak kullanılamaz hale gelebilir. Bu gibi durumlarda, bu veri merkezinde veya Azure bölgesindeki Service Fabric kümeleriniz ve hizmetleriniz kullanılamaz olur. Ancak verileriniz korunur.

Azure 'da çalışan kümeler için, Azure durum sayfasındakesintiler üzerinde güncelleştirmeleri görüntüleyebilirsiniz. Fiziksel bir veri merkezinin kısmen veya tamamen yok edildiği çok önemli olmayan bir olayda, orada barındırılan Service Fabric kümeleri veya bunların içindeki hizmetler kaybolabilir. Bu kayıp, bu veri merkezinin veya bölgenin dışında yedeklenen tüm durumları içerir.

Tek bir veri merkezinde veya bölgede kalıcı veya sürekli arızası olması için birkaç farklı strateji vardır:

• Birden çok bölgede ayrı Service Fabric kümelerini çalıştırın ve bu ortamlar arasında yük devretme ve yeniden çalışma için bazı mekanizmayı kullanın. Birden çok küme etkin/etkin ya da etkin/Pasif modelin bu sıralaması ek yönetim ve operasyon kodu gerektirir. Bu model aynı zamanda bir veri merkezinde veya bölgede hizmetlerden, bir hata olduğunda diğer veri merkezlerinde veya bölgelerde kullanılabilir olmaları için yedeklemelerin koordine edilmesini gerektirir.

• Birden çok veri merkezine yayılan tek bir Service Fabric kümesi çalıştırın. Bu strateji için desteklenen en düşük yapılandırma üç veri merkezidir. Daha fazla bilgi için bkz. kullanılabilirlik alanları üzerinde Service Fabric kümesi dağıtma.

  Bu model ek kurulum gerektirir. Bununla birlikte, bir veri merkezinde başarısızlığın bir olağanüstü durumdan normal bir hataya dönüştürülmesi avantajıdır. Bu arızalar, tek bir bölgedeki kümeler için çalışan mekanizmalar tarafından işlenebilir. Hata etki alanları, yükseltme etki alanları ve Service Fabric yerleştirme kuralları, iş yüklerinin normal hatalara neden olacak şekilde dağıtılmasını güvence altına alırlar.

  Bu tür kümede Hizmetleri çalıştırabilmek için ilkeler hakkında daha fazla bilgi için bkz. Service Fabric Hizmetleri Için yerleştirme ilkeleri.

• Tek başına modeli kullanarak birden çok bölgeye yayılan tek bir Service Fabric kümesi çalıştırın. Önerilen bölge sayısı üç. Tek başına Service Fabric Kurulum hakkındaki ayrıntılar için bkz. tek başına küme oluşturma .

Küme hatalarına neden olan rastgele sorunlar

Service Fabric çekirdek düğümleri kavramıdır. Bunlar, temel alınan kümenin kullanılabilirliğini sürdürdüğüm olan düğümlerdir.

Çekirdek düğümleri, diğer düğümlerle Kiralama kurarak ve belirli başarısızlık türleri sırasında tiebreaklikler gören kümenin açık kalmasını sağlamaya yardımcı olur. Rastgele arızalar kümedeki çekirdek düğümlerin çoğunu kaldırlarsa ve hızlı bir şekilde geri getirilmezse kümeniz otomatik olarak kapanır. Küme daha sonra başarısız olur.

Azure 'da Service Fabric kaynak sağlayıcısı Service Fabric küme yapılandırmasını yönetir. Varsayılan olarak, kaynak sağlayıcısı çekirdek düğümlerini hata ve yükseltme etki alanlarına birincil düğüm türü boyunca dağıtır. Birincil düğüm türü gümüş veya altın dayanıklılık olarak işaretlenmişse, bir çekirdek düğümünü kaldırdığınızda (birincil düğüm türünde ölçeklendirerek veya el ile kaldırarak), küme, birincil düğüm türünün kullanılabilir kapasitesinden başka çekirdek olmayan bir düğümü yükseltmeye çalışır. Bu deneme, küme güvenilirlik düzeyinden daha az kullanılabilir kapasiteye sahipseniz, birincil düğüm türü için gerekli olduğundan başarısız olur.

Tek başına Service Fabric kümelerinde ve Azure 'da, birincil düğüm türü, Seeds 'yi çalıştıran bir ektir. Birincil düğüm türünü tanımlarken Service Fabric, en fazla dokuz temel düğüm ve her sistem hizmeti için yedi çoğaltma oluşturarak, belirtilen düğüm sayısından otomatik olarak yararlanır. Rastgele bir başarısızlık kümesi bu çoğaltmaların büyük bir bölümünü aynı anda alırsa, sistem hizmetleri çekirdek kaybına girer. Çekirdek düğümlerin çoğunluğu kaybolmuşsa, küme yakında kapatılacak.

Sonraki adımlar

• Test edilebilirlik çerçevesinikullanarak çeşitli hataların benzetimini yapmayı öğrenin.
• Diğer olağanüstü durum kurtarma ve yüksek kullanılabilirlik kaynaklarını okuyun. Microsoft bu konularda büyük miktarda kılavuz yayımlamıştır. Bu kaynakların bazıları diğer ürünlerde kullanılmak üzere belirli tekniklerin başvurmakla birlikte, Service Fabric bağlamına uygulayabileceğiniz birçok genel en iyi yöntem içerirler:
  • Kullanılabilirlik denetim listesi
  • Olağanüstü durum kurtarma detayına gitme
  • Azure uygulamaları için olağanüstü durum kurtarma ve yüksek kullanılabilirlik
• Service Fabric destek seçeneklerihakkında bilgi edinin.