Aracılığıyla paylaş

Azure Service Fabric'te olağanüstü durum kurtarma

  • Makale

Yüksek kullanılabilirlik sağlamanın kritik bir kısmı, hizmetlerin tüm farklı hata türlerinden kurtulabilmesini sağlamaktır. Bu özellikle planlanmamış ve denetiminizin dışında olan hatalar için önemlidir.

Bu makalede, doğru modellenmediği ve yönetilmediği takdirde olağanüstü durumlara neden olabilecek bazı yaygın hata modları açıklanmaktadır. Ayrıca, bir olağanüstü durum oluştuğunda gerçekleştirilmesi gereken risk azaltmaları ve eylemleri de ele alır. Amaç, planlanan veya başka bir şekilde hatalar oluştuğunda kapalı kalma süresi veya veri kaybı riskini sınırlamak veya ortadan kaldırmaktır.

Olağanüstü durumdan kaçınma

Azure Service Fabric'in temel amacı, hem ortamınızı hem de hizmetlerinizi yaygın hata türleri olağanüstü durum olmayacak şekilde modellemenize yardımcı olmaktır.

Genel olarak iki tür olağanüstü durum/hata 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. Hatalardan kurtulmanın en kolay yolu, donanım veya yazılım hata sınırları arasında hizmetin daha fazla kopyasını çalıştırmaktır.

Örneğin, hizmetiniz yalnızca bir makinede çalışıyorsa, bu makinenin başarısız olması söz konusu hizmet için olağanüstü bir durumdur. Bu olağanüstü durumdan kaçınmanın basit yolu, hizmetin birden çok makinede çalıştığından emin olmaktır. Test, bir makine hatasının çalışan hizmeti kesintiye uğratmadığından emin olmak için de gereklidir. Kapasite planlaması, değiştirme örneğinin başka bir yerde oluşturulabilmesini ve kapasitenin azaltılmasının kalan hizmetleri aşırı yüklememesini sağlar.

Hatasını önlemeye çalıştığınız şey ne olursa olsun aynı desen çalışır. Örneğin, SAN'ın başarısızlığıyla ilgileniyorsanız, birden çok SAN'da çalışırsınız. Bir sunucu rafının kaybıyla ilgileniyorsanız, birden çok raf arasında koşarsınız. Veri merkezlerinin kaybından endişeleniyorsanız hizmetinizin birden çok Azure bölgesinde, birden çok Azure Kullanılabilirlik Alanları veya kendi veri merkezlerinizde çalışması gerekir.

Bir hizmet birden çok fiziksel örneğe (makineler, raflar, veri merkezleri, bölgeler) yayıldığında, yine de bazı eşzamanlı hata türlerine maruz kalırsınız. Ancak belirli bir türe ait tek ve hatta birden çok hata (örneğin, tek bir sanal makine veya ağ bağlantısının başarısız olması) otomatik olarak işlenir ve artık bir "olağanüstü durum" değildir.

Service Fabric, kümeyi genişletmek için mekanizmalar sağlar ve başarısız düğümleri ve hizmetleri geri getirmeyi işler. Service Fabric ayrıca planlanmamış hataların gerçek olağanüstü durumlara dönüşmesini önlemek için hizmetlerinizin birçok örneğini çalıştırmanıza olanak tanır.

Hataları yaymak için yeterince büyük bir dağıtımı çalıştırmanın uygun olmamasının nedenleri olabilir. Örneğin, hata olasılığına göre ödeme yapmak istediğinizden daha fazla donanım kaynağı gerekebilir. Dağıtılmış uygulamalarla ilgilenirken, coğrafi uzaklıklar arasında ek iletişim atlamaları veya durum çoğaltma maliyetleri kabul edilemez gecikmeye neden olabilir. Bu çizginin çizildiği yer, her uygulama için farklılık gösterir.

Özellikle yazılım hataları için hata, ölçeklendirmeye çalıştığınız hizmette olabilir. Bu durumda, hata koşulu tüm örnekler arasında ilişkilendirildiğinden daha fazla kopya olağanüstü durumu engellemez.

İşletimsel hatalar

Hizmetiniz birçok yedeklilikle tüm dünyaya yayılmış olsa bile, yine de felaket olaylarla karşılaşabilir. Örneğin, birisi yanlışlıkla hizmetin DNS adını yeniden yapılandırabilir veya bunu hemen silebilir.

Örneğin durum bilgisi olan bir Service Fabric hizmetiniz olduğunu ve birinin bu hizmeti yanlışlıkla sildiğini varsayalım. Başka bir risk azaltma yoksa bu hizmet ve sahip olduğu tüm eyaletler artık yok. Bu tür operasyonel olağanüstü durumlar ("oops"), kurtarma için normal planlanmamış hatalardan farklı risk azaltmalar ve adımlar gerektirir.

Bu tür işletimsel hatalardan kaçınmanın en iyi yolları şunlardır:

  • Ortama operasyonel erişimi kısıtlayın.
  • Tehlikeli işlemleri sıkı bir şekilde denetleme.
  • Otomasyon uygulama, el ile veya bant dışı değişiklikleri önleme ve bunları uygulamadan önce belirli değişiklikleri ortamda doğrulama.
  • Yıkıcı işlemlerin "yumuşak" olduğundan emin olun. Geçici işlemler hemen uygulanmaz veya bir zaman penceresi içinde geri alınabilir.

Service Fabric, küme işlemleri için rol tabanlı erişim denetimi sağlama gibi işletimsel hataları önlemeye yönelik mekanizmalar sağlar. Ancak, bu operasyonel hataların çoğu kurumsal çaba ve diğer sistemler gerektirir. Service Fabric, özellikle durum bilgisi olan hizmetler için yedekleme ve geri yükleme gibi operasyonel hataların atlatılması için mekanizmalar sağlar.

Hataları yönetme

Service Fabric'in amacı hataların otomatik olarak yönetilmesidir. Ancak bazı hata türlerini işlemek için hizmetlerin ek kodu olmalıdır. Güvenlik ve iş sürekliliği nedeniyle diğer hata türleri otomatik olarak ele alınmamalıdır .

Tek hataları işleme

Tek makineler her türlü nedenden dolayı başarısız olabilir. Bazen güç kaynakları ve ağ donanımı hataları gibi donanım nedenleri olabilir. Diğer hatalar yazılımdadır. Bunlar işletim sistemi ve hizmetin kendi hatalarıdır. 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, kodun tek bir kopyası herhangi bir nedenle başarısız olursa, tek bir örneğin çalıştırılması bu hizmet için kapalı kalma süresine neden olur.

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

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

Kümedeki eşgüdümlü hatalar planlı veya planlanmamış altyapı hataları ve değişiklikleri ya da 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 modeller. Eşgüdümlü yazılım değişiklikleriyle karşılaşacak alanlar 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 Resource Manager kullanarak Service Fabric kümesini açıklama.

Varsayılan olarak Service Fabric, hizmetlerinizin nerede çalıştırılması gerektiğini planlarken hata ve yükseltme etki alanlarını dikkate alır. Varsayılan olarak Service Fabric, planlı veya plansız değişiklikler olursa hizmetlerinizin kullanılabilir durumda kalması için hizmetlerinizin çeşitli hata ve yükseltme etki alanlarında çalıştığından emin olmaya çalışır.

Örneğin, bir güç kaynağı hatasının bir raf üzerindeki tüm makinelerin aynı anda başarısız olmasına neden olduğunu düşünelim. Hizmetin birden çok kopyası çalışırken, hata etki alanı hatasında çok sayıda makinenin kaybı, bir hizmet için tek bir hatanın yalnızca başka bir örneğine dönüşür. Bu nedenle, hata ve yükseltme etki alanlarının yönetimi, hizmetlerinizin yüksek kullanılabilirliğini sağlamak için kritik öneme sahiptir.

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

Yükseltme etki alanları, yazılımın aynı anda yükseltileceği modelleme alanları için kullanışlıdır. Bu nedenle, yükseltme etki alanları genellikle planlı yükseltmeler sırasında yazılımın kaldırıldığı sınırları da tanımlar. Hem Service Fabric'in 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:

Service Fabric Explorer'de sağlanan küme eşlemesini kullanarak kümenizin düzenini görselleştirebilirsiniz:

Service Fabric Explorer'de hata etki alanlarına yayılmış düğümler

Not

Hata alanlarını modelleme, sıralı yükseltmeler, hizmet kodunuzun ve durumunuzun birçok örneğini çalıştırma, hizmetlerinizin hata ve yükseltme etki alanları arasında çalıştığından emin olmak için yerleştirme kuralları ve yerleşik sistem durumu izleme, Service Fabric'in normal operasyonel sorunları ve hataların olağanüstü durumlara dönüşmesini sağlamak için sağladığı özelliklerden yalnızca bazılarıdır .

Eşzamanlı donanım veya yazılım hatalarını işleme

Tek hatalardan söz ediyoruz. Gördüğünüz gibi, hata ve yükseltme etki alanlarında kodun (ve durumun) daha fazla kopyasının çalışmasını sağlayarak hem durum bilgisi olmayan hem de durum bilgisi olan hizmetler için kolayca işlenebilir.

Aynı anda birden çok rastgele hata da oluşabilir. Bunlar kapalı kalma süresine veya gerçek bir olağanüstü durumla sonuçlanma olasılığı daha yüksektir.

Durum bilgisi olmayan hizmetler

Durum bilgisi olmayan bir hizmetin örnek sayısı, çalışması gereken istenen ö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 yedek örnekler oluşturarak yanıt verir. Service Fabric, hizmet istenen örnek sayımına dönene kadar değişiklik oluşturmaya devam eder.

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

Durum bilgisi olan hizmetler

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

  • Kalıcı duruma sahip durum bilgisi.
  • Kalıcı olmayan durumla durum bilgisi. (Durum bellekte depolanır.)

Durum bilgisi olan bir hizmetin başarısızlığı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 bilgisi olan bir hizmette, gelen veriler çoğaltmalar (birincil ve tüm etkin ikinciller) arasında çoğaltılır. Çoğaltmaların çoğunluğu verileri alırsa veriler çekirdek olarak kabul edilir. (Beş çoğaltma için üç çekirdek olur.) Bu, herhangi bir noktada en son verilerle en az bir çoğaltma çekirdeği olacağı anlamına gelir. Çoğaltmalar başarısız olursa (beşte iki gibi), kurtarıp kurtaramadığını hesaplamak için çekirdek değerini kullanabiliriz. (Beş çoğaltmadan kalan üçünün hala çalışır durumda olması, en az bir çoğaltmanın tam veriye sahip olacağı garanti edilir.)

Çoğaltma çekirdeği başarısız olduğunda, bölüm çekirdek kaybı durumunda bildirilir. Bir bölümün beş çoğaltması olduğunu varsayalım, bu da en az üç bölümün tam veriye sahip olduğu anlamına gelir. Çoğaltmalardan oluşan bir çekirdek (beşten üçü) başarısız olursa, Service Fabric kalan çoğaltmaların (beşten ikisi) bölümü geri yüklemek için yeterli veriye sahip olup olmadığını belirleyemez. Service Fabric'in çekirdek kaybı algıladığı durumlarda, varsayılan davranışı bölüme ek yazmaları önlemek, çekirdek kaybı bildirmek ve çoğaltma çekirdeğinin geri yüklenmesini beklemektir.

Durum bilgisi olan bir hizmet için olağanüstü durum oluşup oluşmadığını belirleme ve ardından bunu yönetme üç aşamayı izler:

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

    Durum bilgisi olan bir hizmetin çoğaltmalarının çoğunluğu aynı anda kapalı olduğunda çekirdek kaybı bildirilir.

  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 bilgisi olan hizmetin durumunun devam edip etmediğine veya yalnızca bellekte mi tuttuğuna bağlıdır:

    • Kalıcı duruma sahip olmayan hizmetler için çekirdek veya daha fazla çoğaltma hatası anında kalıcı çekirdek kaybıyla sonuçlanır. Service Fabric, durum bilgisi olan kalıcı olmayan bir hizmette çekirdek kaybı algıladığında, veri kaybı bildirerek (olası) 3. adıma hemen devam eder. Service Fabric, çoğaltmaların geri gelmesini beklemenin bir anlamı olmadığını bildiği için veri kaybına devam etmek mantıklıdır. Kurtarılsalar bile, hizmetin kalıcı olmayan yapısı nedeniyle veriler kaybolur.
    • Durum bilgisi olan kalıcı hizmetler için çekirdek veya daha fazla çoğaltma hatası Service Fabric'in çoğaltmaların geri gelmesini beklemesine ve çekirdeği geri yüklemesine neden olur. Bu, hizmetin etkilenen bölümüne (veya "çoğaltma kümesine") yapılan tüm yazma işlemleri için hizmet kesintisine neden olur. Ancak, daha düşük tutarlılık garantileriyle okuma işlemleri yine de mümkün olabilir. Service Fabric'in çekirdeğin geri yüklenmesini beklediği varsayılan süre sonsuzdur çünkü devam etmek (olası) bir veri kaybı olayıdır ve başka riskler taşır. Bu, bir yönetici veri kaybını bildirmek için eylemde bulunmadığı sürece Service Fabric'in bir sonraki adıma geçmeyeceğini gösterir.

  3. Veri kaybı olup olmadığını belirleme ve yedeklemelerden geri yükleme.

    Çekirdek kaybı bildirilmişse (otomatik olarak veya yönetim eylemi aracılığıyla), Service Fabric ve hizmetler verilerin gerçekten kaybedilip kaybolmadığını belirlemeye devam eder. Bu noktada Service Fabric, diğer çoğaltmaların geri gelmeyeceğini de bilir. Çekirdek kaybının kendi kendine çözüme kavuşturulmasını beklemeyi bıraktığımızda bu karar verildi. Hizmet için en iyi eylem yöntemi genellikle dondurmak ve belirli bir yönetim müdahalesini beklemektir.

    Service Fabric yöntemini çağırdığında OnDataLossAsync , bunun nedeni her zaman şüpheli veri kaybıdır. Service Fabric, bu çağrının kalan en iyi çoğaltmaya teslim edilmesini sağlar. Bu, en çok ilerleme kaydeden çoğaltmadır.

    Her zaman şüpheli veri kaybı demenin nedeni, kalan çoğaltmanın çekirdek kaybedildiğinde birincil çoğaltmayla aynı duruma sahip olmasıdır. Ancak, karşılaştırmak için bu durum olmadan Service Fabric'in veya işleçlerin emin olması için iyi bir yol yoktur.

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

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

    2. Genellikle uygulama duraklatılır ve daha fazla karar alınmasını ve el ile gerçekleştirilmesini bekler. Bunun nedeni, yedeklemeler kullanılabilir olsa bile hazırlıklı olmaları gerekebileceğidir.

      Örneğin, iki farklı hizmet bilgileri koordine ederse, geri yükleme gerçekleştirildikten sonra bu iki hizmetin önem duyduğu bilgilerin tutarlı olduğundan emin olmak için bu yedeklemelerin değiştirilmesi gerekebilir.

    3. Genellikle hizmetten başka telemetri veya egzoz da vardır. Bu meta veriler diğer hizmetlerde veya günlüklerde bulunabilir. Bu bilgiler, yedeklemede mevcut olmayan veya bu çoğaltmaya çoğaltılan birincil öğede alınan ve işlenen herhangi bir çağrı olup olmadığını belirlemek için gerektiğinde kullanılabilir. Geri yüklemenin mümkün olması için bu çağrıların yeniden oynatılması veya yedeklemeye eklenmesi gerekebilir.

    4. Uygulama, kalan çoğaltmanın durumunu kullanılabilir yedeklemelerde bulunan durumla karşılaştırır. Service Fabric güvenilir koleksiyonlarını kullanıyorsanız, bunu yapmak için kullanabileceğiniz araçlar ve işlemler vardır. Amaç, çoğaltma içindeki durumun yeterli olup olmadığını görmek ve yedeklemenin eksik olabileceğini görmektir.

    5. Karşılaştırma yapıldıktan ve geri yükleme tamamlandıktan sonra (gerekirse), durum değişiklikleri yapıldıysa hizmet kodu true döndürmelidir. Çoğaltma, durumun kullanılabilir en iyi kopyası olduğunu belirlediyse ve hiçbir değişiklik yapılmadıysa, 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ılacak ve yeniden oluşturulacak. false değeri, durum değişikliği yapılmadığını gösterir, bu nedenle diğer çoğaltmalar sahip oldukları şeyi tutabilir.

Hizmetler üretime dağıtılmadan önce hizmet yazarlarının olası veri kaybı ve hata senaryolarını uygulaması kritik öneme sahiptir. Veri kaybı olasılığına karşı koruma sağlamak için, durum bilgisi olan hizmetlerinizin durumunu coğrafi olarak yedekli bir depoya düzenli aralıklarla yedeklemeniz önemlidir.

Ayrıca, durumu geri yükleme yeteneğine sahip olduğunuzdan da emin olmanız gerekir. Birçok farklı hizmetin yedekleri farklı zamanlarda alındığından, geri yükleme işleminden sonra hizmetlerinizin birbirinin tutarlı bir görünümüne sahip olduğundan emin olmanız gerekir.

Örneğin, bir hizmetin bir sayı oluşturup depoladığı ve sonra da onu depolayan başka bir hizmete gönderdiği bir durumu düşünün. Geri yükleme işleminden sonra, ikinci hizmetin numarası olduğunu ancak ilkinin olmadığını fark edebilirsiniz, çünkü yedeklemesi bu işlemi içermez.

Kalan çoğaltmaların veri kaybı senaryosunda devam etmek için yetersiz olduğunu ve telemetri veya tükenmeden hizmet durumunu yeniden oluşturamazsınız, yedeklemelerinizin sıklığı mümkün olan en iyi kurtarma noktası hedefinizi (RPO) belirler. Service Fabric, kalıcı çekirdek ve yedekten geri yükleme gerektiren veri kaybı da dahil olmak üzere ç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'teki test edilebilirlik 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ş.

Not

Sistem hizmetleri çekirdek kaybına da neden olabilir. Etki, söz konusu hizmete özgüdür. Örneğin, adlandırma hizmetindeki çekirdek kaybı ad çözümlemesini etkilerken, Yük Devretme Yöneticisi hizmetindeki çekirdek kaybı yeni hizmet oluşturma ve yük devretmeleri engeller.

Service Fabric sistem hizmetleri, durum yönetimi hizmetlerinizle aynı deseni izler, ancak bunları çekirdek kaybından ve olası veri kaybına taşımaya çalışmanızı önermeyiz. Bunun yerine, durumunuz için hedeflenen bir çözüm bulmak için destek aramanızı öneririz. Genellikle aşağı çoğaltmalar dönene kadar beklemeniz tercih edilir.

Çekirdek kaybı sorunlarını giderme

Geçici bir hata nedeniyle çoğaltmalar aralıklı olarak kapalı olabilir. Service Fabric bunları ortaya çıkarmaya çalışırken biraz bekleyin. Çoğaltmalar beklenen sürenin üzerinde kapalıysa şu sorun giderme eylemlerini izleyin:

  • Çoğaltmalar kilitleniyor olabilir. Çoğaltma düzeyi sistem durumu raporlarını ve uygulama günlüklerinizi denetleyin. Kilitlenme bilgi 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 inceleyin. İşlem dökümlerini toplayın ve yanıt vermeyen işlemi durdurun. Service Fabric bir değiştirme işlemi oluşturur ve çoğaltmayı geri getirmeye çalışır.
  • Çoğaltmaları barındıran düğümler kapalı olabilir. Düğümleri yukarı getirmek için temel alınan sanal makineyi yeniden başlatın.

Bazen çoğaltmaları kurtarmak mümkün olmayabilir. Örneğin, sürücüler başarısız oldu veya makineler fiziksel olarak yanıt vermiyor. Böyle durumlarda, Service Fabric'e çoğaltma kurtarmayı beklememesi gerektiğinin söylenmesi gerekir.

Hizmeti çevrimiçi yapmak için olası veri kaybı kabul edilemezse bu yöntemleri kullanmayın. Bu durumda, fiziksel makinelerin kurtarılması için tüm çaba gösterilmelidir.

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

Not

Belirli bölümlerde hedeflenen bir yöntem dışında bu yöntemleri kullanmak hiçbir zaman güvenli olmaz .

  • veya System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) API'sini Repair-ServiceFabricPartition -PartitionId kullanın. Bu API, çekirdek kaybından çıkmak ve olası veri kaybına geçmek için bölümün kimliğinin belirtilmesine olanak tanır.
  • Kümeniz, hizmetlerin çekirdek kaybı durumuna gitmesine neden olan sık hatalarla karşılaşıyorsa ve olası veri kaybı kabul edilebilirse, uygun bir QuorumLossWaitDuration değeri belirtmek hizmetinizin otomatik olarak kurtarılmasına yardımcı olabilir. Service Fabric, kurtarma gerçekleştirmeden önce sağlanan QuorumLossWaitDuration değeri bekler (varsayılan değer sonsuzdur). Beklenmeyen veri kayıplarına neden olabileceği için 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. Service Fabric sistem hizmetleri daha önce sağlanan yönergeleri izlediğinden, herhangi bir düğümün başarısız olması küme için kullanılabilirlik veya güvenilirlik sorunlarına neden olmaz. Başka bir ifadeyle, her zaman varsayılan olarak üç veya daha fazla çoğaltma ile çalışırlar ve durum bilgisi olmayan sistem hizmetleri tüm düğümlerde çalıştırılır.

Temel alınan Service Fabric ağ ve hata algılama katmanları tamamen dağıtılmıştır. Sistem hizmetlerinin çoğu kümedeki meta verilerden yeniden oluşturulabilir veya diğer yerlerden durumlarının nasıl yeniden eşitleneceklerini bilir. Sistem hizmetleri daha önce açıklananlar gibi çekirdek kaybı durumlarına girerse kümenin kullanılabilirliği tehlikeye girebilir. Bu gibi durumlarda, küme üzerinde belirli işlemleri gerçekleştiremeyebilirsiniz (yükseltme başlatma veya yeni hizmetler dağıtma gibi), ancak kümenin kendisi hala çalışır durumdadır.

Çalışan bir kümedeki hizmetler, çalışmaya devam etmek için sistem hizmetlerine yazma gerektirmedikleri sürece bu koşullarda çalışmaya devam eder. Örneğin, Yük Devretme Yöneticisi çekirdek kaybı durumundaysa tüm hizmetler çalışmaya devam eder. Ancak yük devretme yöneticisinin katılımını gerektirdiğinden başarısız olan hizmetler otomatik olarak yeniden başlatılamaz.

Veri merkezi veya Azure bölgesi hataları

Nadir durumlarda, fiziksel bir veri merkezi güç veya ağ bağlantısı kaybı nedeniyle geçici olarak kullanılamaz hale gelebilir. Böyle durumlarda, söz konusu veri merkezi veya Azure bölgesindeki Service Fabric kümeleriniz ve hizmetleriniz kullanılamaz. Ancak verileriniz korunur.

Azure'da çalışan kümeler için kesintilerle ilgili güncelleştirmeleri Azure durum sayfasında görüntüleyebilirsiniz. Fiziksel bir veri merkezinin kısmen veya tamamen yok olması olasılığı yüksek olduğunda, burada barındırılan tüm Service Fabric kümeleri veya içindeki hizmetler kaybolabilir. Bu kayıp, söz konusu veri merkezi veya bölge dışında yedeklenmemiş tüm durumları içerir.

Tek bir veri merkezinin veya bölgenin kalıcı veya sürekli başarısızlığından hayatta kalmak için birkaç farklı strateji vardır:

  • Bu tür birden çok bölgede ayrı Service Fabric kümeleri çalıştırın ve bu ortamlar arasında yük devretme ve yeniden çalışma için bazı mekanizmalar kullanın. Bu tür birden çok kümeli etkin/etkin veya etkin/pasif model ek yönetim ve işlem kodu gerektirir. Bu model ayrıca, bir veri merkezi veya bölgedeki hizmetlerden alınan yedeklemelerin eşgüdümünün yapılmasını gerektirir; böylece bunlar başarısız olduğunda diğer veri merkezlerinde veya bölgelerde kullanılabilir.

  • 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ı arasında Service Fabric kümesi dağıtma.

    Bu model için ek kurulum gerekir. Ancak, tek bir veri merkezinin hatasının olağanüstü durumdan normal bir hataya dönüştürülmesi avantajıdır. Bu hatalar, 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 tolerans göstermeleri için dağıtılmasını sağlar.

    Bu küme türündeki hizmetleri çalıştırmaya yardımcı olabilecek 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ı üçdür. Tek başına Service Fabric kurulumuyla ilgili ayrıntılar için bkz. Tek başına küme oluşturma .

Küme hatalarına yol açan rastgele hatalar

Service Fabric'in çekirdek düğümleri kavramı vardır. Bunlar, temel alınan kümenin kullanılabilirliğini koruyan düğümlerdir.

Çekirdek düğümleri, diğer düğümlerle kiralamalar oluşturarak ve belirli hata türleri sırasında ayırıcı olarak hizmet vererek kümenin çalışır kalmasını sağlamaya yardımcı olur. Rastgele hatalar kümedeki çekirdek düğümlerin çoğunu kaldırırsa ve bunlar hızlı bir şekilde geri getirilmediyse 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ırmalarını yönetir. Varsayılan olarak, Kaynak Sağlayıcısı birincil düğüm türü için hata ve yükseltme etki alanları arasında çekirdek düğümleri 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ünüzde ölçeklendirerek veya el ile kaldırarak), küme birincil düğüm türünün kullanılabilir kapasitesinden başka bir çekirdek olmayan düğümü yükseltmeye çalışır. Birincil düğüm türünüz için küme güvenilirlik düzeyinizin gerektirdiğinden daha az kullanılabilir kapasiteniz varsa bu deneme başarısız olur.

Hem tek başına Service Fabric kümelerinde hem de Azure'da birincil düğüm türü, tohumları çalıştıran düğüm türüdür. Birincil düğüm türünü tanımlarken Service Fabric, en fazla dokuz çekirdek düğümü ve her sistem hizmetinin yedi çoğaltması oluşturarak sağlanan düğüm sayısından otomatik olarak yararlanacaktır. Bir dizi rastgele hata bu çoğaltmaların çoğunluğunu aynı anda çıkarırsa, sistem hizmetleri çekirdek kaybına girer. Çekirdek düğümlerinin çoğunluğu kaybolursa küme kısa süre sonra kapanır.

Sonraki adımlar