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ürlerinde hayatta kalabilmesini 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 yapılması 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ü 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 kapasitedeki azalmanın kalan hizmetleri aşırı yüklememesini sağlar.

Başarısızlığı önlemeye çalıştığınız şey ne olursa olsun aynı desen çalışır. Örneğin, SAN'ın başarısızlığıyla ilgili endişeniz varsa birden çok SAN'da çalışırsınız. Bir sunucu rafının kaybından endişeleniyorsanız, birden çok raf arasında çalışırsı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ı başarısız oluyor) otomatik olarak işlenir ve bu nedenle artık "olağanüstü durum" olmaz.

Service Fabric, kümeyi genişletmek için mekanizmalar sağlar ve başarısız düğümleri ve hizmetleri geri getirme işlemini gerçekleştirir. 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 mesafeler arasında ek iletişim atlamaları veya durum çoğaltma maliyetleri kabul edilemez gecikme süresine 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 bağıntılı olduğundan daha fazla kopya olağanüstü durumu engellemez.

İşletimsel hatalar

Hizmetiniz birçok yedeklilikle dünya çapında yayılmış olsa bile, yine de felaket olaylarla karşılaşabilir. Örneğin, birisi hizmetin DNS adını yanlışlıkla yeniden yapılandırabilir veya bu adı silip atabilir.

Ö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, o hizmet ve sahip olduğu tüm eyaletler artık yok. Bu tür operasyonel olağanüstü durumlar ("oops"), normal planlanmamış hatalardan farklı azaltmalar ve kurtarma 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 kesin olarak denetle.
  • 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 etkili olmaz 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 sistemleri gerektirir. Service Fabric, özellikle durum bilgisi olan hizmetler için yedekleme ve geri yükleme gibi operasyonel hataların hayatta kalma 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 sisteminin ve hizmetin kendisinin hatalarıdır. Service Fabric, makinenin ağ sorunları nedeniyle diğer makinelerden yalıtıldığı durumlar da dahil olmak üzere bu tür hataları otomatik olarak algılar.

Hizmet türünden bağımsız olarak, 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 şudur TargetReplicaSetSize : ve 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şleyebilmesini sağlar.

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

Kümedeki eşgüdümlü hatalar, planlanan 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.

Service Fabric, hizmetlerinizin nerede çalıştırılması gerektiğini planlarken varsayılan olarak 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ıyla çalıştığından emin olmaya çalışır.

Örneğin, bir güç kaynağının başarısız olması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ı yönetmek, 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. İstenmeyen değişikliklerin kümeyi ve hizmetinizi etkilemesini önlemeye yardımcı olan sıralı yükseltmeler, yükseltme etki alanları ve Service Fabric sistem durumu modeli hakkında daha fazla bilgi için bkz:

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

Service Fabric Explorer'da 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ında çalıştığından emin olmak için yerleştirme kuralları ve yerleşik sistem durumu izleme, Service Fabric'in normal işletimsel 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 bahsediyoruz. Gördüğünüz gibi, yalnızca 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 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ısı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 olan 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 durum bilgisi olan 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 sahip olduğu çoğaltma sayısına 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şten ikisi gibi), kurtarıp kurtaramadığını hesaplamak için çekirdek değerini kullanabiliriz. (Beş çoğaltmadan kalan üç tanesi hala çalışır durumda olduğundan, en az bir çoğaltmanın tam veriye sahip olacağı garanti edilir.)

Bir çoğaltma çekirdeği başarısız olduğunda, bölüm çekirdek kaybı durumunda olarak bildirilir. Bir bölümün beş çoğaltması olduğunu varsayalım; bu da en az üç çoğaltmanın tam veriye sahip olması garanti edilir. Ç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ğaltmaların bir ç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 işlemi üç aşamadan sonra gerçekleşir:

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

    Durum bilgisi olan bir hizmetin çoğaltmalarının çoğunluğu aynı anda az 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ı olur. Hataların kalıcı olup olmaması, durum bilgisi olan hizmetin durumunu devam ettirip saklamadığına veya yalnızca bellekte saklamasına 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, (olası) veri kaybı bildirerek hemen 3. adıma geçer. 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 bir ç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çeceği anlamına gelir.

  3. Veri kaybı olup olmadığını belirleme ve yedeklerden 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ülmesini beklemeyi bıraktığımızda aldığımız karar da bu oldu. Hizmet için en iyi eylem 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 kaybolduğunda birincil çoğaltmayla aynı duruma sahip olma olasılığı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. Uygulama, tetiklenen 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 önemsediğinden emin olmak için bu yedeklemelerin değiştirilmesi gerekebilir.

    3. Genellikle hizmetten başka telemetri veya egzoz da olur. 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ükleme gerçekleştirilmeden önce bu çağrıların yeniden oynatılması veya yedeklemeye eklenmesi gerekebilir.

    4. Uygulama, kalan çoğaltmanın durumunu kullanılabilir yedeklemelerin içerdiği 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 olup olmadığını 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. Bu çoğaltmadan bırakılacak ve yeniden oluşturulacaktır. false değeri, durum değişikliği yapılmadığını gösterir, bu nedenle diğer çoğaltmalar sahip oldukları şeyi koruyabilir.

Hizmet yazarlarının, hizmetler üretimde dağıtılmadan önce olası veri kaybı ve hata senaryolarını uygulaması kritik önem taşır. 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 depolayan başka bir hizmete gönderdiği bir durumu göz önünde bulundurun. Geri yükleme işleminden sonra, ikinci hizmetin numarası olduğunu ancak ilk hizmette 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 fark ederseniz ve telemetri veya egzozdan hizmet durumunu yeniden oluşturamıyorsanız, yedeklemelerinizin sıklığı mümkün olan en iyi kurtarma noktası hedefinizi (RPO) belirler. Service Fabric, yedeklemeden geri yükleme gerektiren kalıcı çekirdek ve 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'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şturmayı 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şımayı denemenizi önermeyiz. Bunun yerine, durumunuz için hedeflenen bir çözüm bulmak için destek istemenizi ö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 çalışmıyor olabilir. Service Fabric bunları ortaya çıkarmaya çalışırken biraz bekleyin. Çoğaltmalar beklenenden uzun süredir çalışmıyorsa şu sorun giderme eylemlerini izleyin:

  • Çoğaltmalar kilitleniyor olabilir. Çoğaltma düzeyi sistem durumu raporlarını ve uygulama günlüklerinizi denetleyin. 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 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 çalışmıyor 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 söylenmesi gerekir.

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 çaba gösterilmelidir.

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

Not

Belirli bölümlere karşı 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ğini belirtmeye olanak tanır.
  • Kümeniz, hizmetlerin çekirdek kaybı durumuna gitmesine neden olan sık hatalarla karşılaşırsa ve olası veri kaybı kabul edilebilirse, uygun bir QuorumLossWaitDuration değeri belirtmek hizmetinizin otomatik olarak kurtarılmasına yardımcı olabilir. Service Fabric, kurtarma işlemi gerçekleştirmeden önce sağlanan QuorumLossWaitDuration değeri (varsayılan değer sonsuzdur) bekler. 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, tek bir düğümün başarısız olması küme için kullanılabilirlik veya güvenilirlik sorunlarına neden olmaz. Diğer bir ifadeyle, her zaman varsayılan olarak üç veya daha fazla çoğaltma ile çalışır ve durum bilgisi olmayan sistem hizmetleri tüm düğümlerde çalıştırılır.

Temel alınan Service Fabric ağ iletişimi ve hata algılama katmanları tamamen dağıtılı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ümede 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ındaysa, 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ından geçici olarak kullanılamaz hale gelebilir. Bu gibi durumlarda, bu veri merkezinde veya Azure bölgesinde 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. Bir fiziksel veri merkezinin kısmen veya tamamen yok edilmesi durumunda, burada barındırılan tüm Service Fabric kümeleri veya içindeki hizmetler kaybolabilir. Bu kayıp, bu 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ığını sürdürmek 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, bir veri merkezi veya bölgedeki hizmetlerden alınan yedeklemelerin eşgüdümünün, başarısız olduğunda diğer veri merkezlerinde veya bölgelerde kullanılabilir olmasını da 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ı arasında Service Fabric kümesi dağıtma.

    Bu model ek kurulum gerektirir. Ancak bunun avantajı, bir veri merkezinin başarısız olmasının olağanüstü durumdan normal bir hataya dönüştürülmesidir. 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 hizmetlerin çalıştırılmasına 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ı üç'tü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,çekirdek düğümleri kavramına sahiptir. 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ürlerinde 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 getirilmezse kümeniz otomatik olarak kapanır. Ardından küme 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 çekirdek düğümleri hata ve yükseltme etki alanları arasında 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üzü ö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ükseltmeyi dener. Küme güvenilirlik düzeyinizin birincil düğüm türünüz için 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ü 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üğümlerin çoğunluğu kaybolursa, küme kısa süre sonra kapanır.

Sonraki adımlar