Aracılığıyla paylaş


Çoğaltmalar ve örnekler

Bu makale, durum bilgisi olan hizmetlerin çoğaltmalarının yaşam döngüsüne ve durum bilgisi olmayan hizmetlerin örneklerine genel bir bakış sağlar.

Durum bilgisi olmayan hizmetlerin örnekleri

Durum bilgisi olmayan bir hizmetin örneği, kümenin düğümlerinden birinde çalışan hizmet mantığının bir kopyasıdır. Bir bölümdeki örnek, InstanceId değeriyle benzersiz olarak tanımlanır. Bir örneğin yaşam döngüsü aşağıdaki diyagramda modellenmiştir:

Örnek yaşam döngüsü

InBuild (IB)

Küme Kaynak Yöneticisi örnek için bir yerleştirme belirledikten sonra bu yaşam döngüsü durumunu girer. Örnek düğümde başlatılır. Uygulama konağı başlatılır, örnek oluşturulur ve sonra açılır. Başlatma tamamlandıktan sonra örnek hazır duruma geçirilmiştir.

Bu örneğin uygulama konağı veya düğümü kilitlenirse bırakılan duruma geçiş yapılır.

Hazır (RD)

Hazır durumda, örnek düğümde çalışır durumdadır. Bu örnek güvenilir bir hizmetse RunAsync çağrıldı.

Bu örneğin uygulama konağı veya düğümü kilitlenirse bırakılan duruma geçiş yapılır.

Kapatma (CL)

Kapatma durumunda, Azure Service Fabric bu düğümdeki örneği kapatma sürecindedir. Bu kapatma işlemi, uygulama yükseltmesi, yük dengeleme veya hizmetin silinmesi gibi birçok nedenden kaynaklanıyor olabilir. Kapatma işlemi tamamlandıktan sonra bırakılan duruma geçiş yapılır.

Bırakılan (DD)

Bırakılan durumda, örnek artık düğümde çalışmıyor. Bu noktada Service Fabric, bu örnekle ilgili meta verileri korur ve sonunda da silinir.

Not

üzerinde Remove-ServiceFabricReplicaForceRemove seçeneğini kullanarak herhangi bir durumdan bırakılan duruma geçiş yapmak mümkündür.

Durum bilgisi olan hizmetlerin çoğaltmaları

Durum bilgisi olan bir hizmetin çoğaltması, kümenin düğümlerinden birinde çalışan hizmet mantığının bir kopyasıdır. Ayrıca, çoğaltma bu hizmetin durumunun bir kopyasını tutar. İlgili iki kavram, durum bilgisi olan çoğaltmaların yaşam döngüsünü ve davranışını açıklar:

  • Çoğaltma yaşam döngüsü
  • Çoğaltma rolü

Aşağıdaki tartışmada kalıcı durum bilgisi olan hizmetler açıklanmaktadır. Geçici (veya bellek içi) durum bilgisi olan hizmetler için aşağı ve bırakılan durumlar eşdeğerdir.

Çoğaltma yaşam döngüsü

InBuild (IB)

InBuild çoğaltması, çoğaltma kümesini birleştirmek için oluşturulmuş veya hazırlanmış bir çoğaltmadır. Çoğaltma rolüne bağlı olarak IB'nin farklı semantiği vardır.

Bir InBuild çoğaltması için uygulama konağı veya düğümü kilitleniyorsa, aşağı duruma geçiş yapılır.

  • Birincil InBuild çoğaltmaları: Birincil InBuild, bir bölümün ilk çoğaltmalarıdır. Bu çoğaltma genellikle bölüm oluşturulurken gerçekleşir. Birincil InBuild çoğaltmaları, bir bölümün tüm çoğaltmaları yeniden başlatıldığında veya bırakıldığında da ortaya çıkar.

  • IdleSecondary InBuild çoğaltmaları: Bunlar, Küme Kaynak Yöneticisi tarafından oluşturulan yeni çoğaltmalar veya devre dışı kalan ve kümeye yeniden eklenmesi gereken mevcut çoğaltmalardır. Bu çoğaltmalar, çoğaltma kümesini ActiveSecondary olarak birleştirmeden ve işlemlerin çekirdek onayına katılmadan önce birincil tarafından dağıtılır veya oluşturulur.

  • ActiveSecondary InBuild çoğaltmaları: Bu durum bazı sorgularda gözlemlenir. Bu, çoğaltma kümesinin değişmediği, ancak bir çoğaltmanın derlenmesi gerektiği bir iyileştirmedir. Çoğaltmanın kendisi normal durum makinesi geçişlerini izler (çoğaltma rolleri bölümünde açıklandığı gibi).

Hazır (RD)

Hazır çoğaltma, çoğaltmaya ve işlemlerin çekirdek onayına katılan bir çoğaltmadır. Hazır durum birincil ve etkin ikincil çoğaltmalar için geçerlidir.

Uygulama konağı veya hazır bir çoğaltmanın düğümü kilitlenirse, aşağı duruma geçiş yapılır.

Kapatma (CL)

Çoğaltma aşağıdaki senaryolarda kapatma durumuna girer:

  • Çoğaltmanın kodu kapatılıyor: Service Fabric'in bir çoğaltma için çalışan kodu kapatması gerekebilir. Bu kapatmanın birçok nedeni olabilir. Örneğin, bir uygulama, doku veya altyapı yükseltmesi veya çoğaltma tarafından bildirilen bir hata nedeniyle oluşabilir. Çoğaltma kapatıldığında, çoğaltma aşağı duruma geçirildi. Diskte depolanan bu çoğaltmayla ilişkili kalıcı durum temizlenmez.

  • Kümeden çoğaltma kaldırılıyor: Service Fabric'in kalıcı durumu kaldırması ve bir çoğaltma için çalışan kodu kapatması gerekebilir. Bu kapatma, yük dengeleme gibi birçok nedenden dolayı olabilir.

Bırakılan (DD)

Bırakılan durumda, örnek artık düğümde çalışmıyor. Düğümde durum da kalmadı. Bu noktada Service Fabric, bu örnekle ilgili meta verileri korur ve sonunda da silinir.

Aşağı (D)

Aşağı durumda, çoğaltma kodu çalışmıyor, ancak bu çoğaltmanın kalıcı durumu söz konusu düğümde var. Bir çoğaltma, düğümün kapanması, çoğaltma kodunda kilitlenme, uygulama yükseltmesi veya çoğaltma hataları gibi birçok nedenden dolayı kapanabilir.

Bir aşağı çoğaltma, service Fabric tarafından gerektiği gibi açılır; örneğin, düğümde yükseltme tamamlandığında.

Çoğaltma rolü aşağı durumda uygun değil.

Açma (OP)

Service Fabric'in çoğaltmayı yeniden yedeklemesi gerektiğinde aşağı çoğaltma açılış durumuna girer. Örneğin, bu durum bir düğümde uygulama için kod yükseltmesi tamamlandıktan sonra olabilir.

Uygulama konağı veya açılış çoğaltması düğümü kilitleniyorsa, aşağı duruma geçiş yapılır.

Çoğaltma rolü, açılış durumunda ilgili değildir.

Bekleme (SB)

StandBy çoğaltması, kapanıp daha sonra açılan kalıcı bir hizmetin çoğaltmasıdır. Bu çoğaltma, çoğaltma kümesine başka bir çoğaltma eklemesi gerekiyorsa Service Fabric tarafından kullanılabilir (çoğaltmanın durumun bir kısmı zaten olduğundan ve derleme işlemi daha hızlı olduğundan). StandByReplicaKeepDuration süresi dolduktan sonra bekleme çoğaltması atılır.

Bekleyen çoğaltmanın uygulama konağı veya düğümü kilitleniyorsa, aşağı duruma geçiş yapılır.

Çoğaltma rolü bekleme durumunda ilgili değildir.

Not

Kapatılmayan veya bırakılmayan tüm çoğaltmaların çalışır durumda olduğu kabul edilir.

Not

üzerinde Remove-ServiceFabricReplicaForceRemove seçeneğini kullanarak herhangi bir durumdan bırakılan duruma geçiş yapmak mümkündür.

Çoğaltma rolü

Çoğaltmanın rolü, çoğaltma kümesindeki işlevini belirler:

  • Birincil (P): Çoğaltma kümesinde okuma ve yazma işlemlerinin gerçekleştirilmesinden sorumlu olan bir birincil vardır.
  • ActiveSecondary (S):Bunlar birincilden durum güncelleştirmeleri alan, bunları uygulayan ve sonra geri onay gönderen çoğaltmalardır. Çoğaltma kümesinde birden çok etkin ikincil vardır. Bu etkin ikincillerin sayısı, hizmetin işleyebileceği hata sayısını belirler.
  • IdleSecondary (I): Bu çoğaltmalar birincil tarafından oluşturuluyor. Etkin ikincil olarak yükseltilmeden önce birincilden durum alır.
  • Hiçbiri (N): Bu çoğaltmaların çoğaltma kümesinde bir sorumluluğu yoktur.
  • Bilinmiyor (U): Bu, Service Fabric'ten herhangi bir ChangeRole API çağrısı almadan önce çoğaltmanın ilk rolüdür.

Aşağıdaki diyagramda çoğaltma rolü geçişleri ve bunların gerçekleşebileceği bazı örnek senaryolar gösterilmektedir:

Çoğaltma rolü

  • U -> P: Yeni bir birincil çoğaltma oluşturma.
  • U -> I: Yeni boşta çoğaltma oluşturma.
  • U -> N: Bekleyen çoğaltma silindi.
  • I -> S: Onaylarının çekirdekte katkıda bulunabilmesi için boşta olan ikincilin etkin ikincile yükseltılması.
  • I -> P: Boşta olan ikincilin birincile yükseltilme. Bu, boşta olan ikincil birincil olmak için doğru aday olduğunda özel yeniden yapılandırmalar altında gerçekleşebilir.
  • I -> N: Boşta kalan ikincil çoğaltma siliniyor.
  • S -> P: Etkin ikincilin birincile yükseltılması. Bunun nedeni, Küme Resource Manager tarafından başlatılan birincil veya birincil hareketin yük devretmesi olabilir. Örneğin, bir uygulama yükseltmesine veya yük dengelemesine yanıt olarak olabilir.
  • S -> N: Etkin ikincil çoğaltma silindi.
  • P -> S: Birincil çoğaltmanın indirgemesi. Bunun nedeni Küme Kaynak Yöneticisi tarafından başlatılan birincil bir hareket olabilir. Örneğin, bir uygulama yükseltmesine veya yük dengelemesine yanıt olarak olabilir.
  • P -> N: Birincil çoğaltma silindi.

Not

Reliable Actors ve Reliable Services gibi üst düzey programlama modelleri, çoğaltma rolleri kavramını geliştiriciden gizler. Aktörler'de rol diye bir şey olması gereksizdir. Hizmetler'de çoğu senaryo için büyük ölçüde basitleştirilmiştir.

Sonraki adımlar

Service Fabric kavramları hakkında daha fazla bilgi için aşağıdaki makaleye bakın:

Reliable Services yaşam döngüsü - C#