Kümeyi kullanarak Service Fabric kümeyi Küme Kaynak Yöneticisi

Azure Küme Kaynak Yöneticisi'nin Service Fabric özelliği, kümeyi açıklamaya yardımcı olacak çeşitli mekanizmalar sağlar:

• Hata etki alanları
• Etki alanlarını yükseltme
• Düğüm özellikleri
• Düğüm kapasiteleri

Çalışma zamanı Küme Kaynak Yöneticisi, kümede çalışan hizmetlerin yüksek kullanılabilirliğini sağlamak için bu bilgileri kullanır. Bu önemli kuralları zorlarken, küme içindeki kaynak tüketimini iyileştirmeye de çalışır.

Hata etki alanları

Hata etki alanı, eşgüdümli hatanın herhangi bir alanıdır. Tek bir makine bir hata etki alanıdır. Güç kaynağı hatalarından sürücü hatalarına ve hatalı NIC üretici yazılımına kadar çeşitli nedenlerle kendi kendine başarısız olabilir.

Aynı Ethernet anahtarına bağlı makineler aynı hata etki alanındadır. Aynı şekilde, tek bir güç kaynağını veya tek bir konumdaki makineleri de paylaşır.

Donanım hatalarının çakışması doğal olduğundan, hata etki alanları doğal olarak hiyerarşiktir. Bunlar, Service Fabric'de URI olarak Service Fabric.

Hata etki alanlarının doğru şekilde ayarlanmış olması önemlidir çünkü Service Fabric hizmetleri güvenli bir şekilde kurmak için bu bilgileri kullanır. Service Fabric bir hata etki alanının kaybının (bazı bileşenin hatasından kaynaklanan) hizmetin kesintiye neden olması gibi hizmetlere yer vermemektedir.

Azure ortamında, Service Fabric kümedeki düğümleri sizin adına doğru şekilde yapılandırmak için ortam tarafından sağlanan hata etki alanı bilgilerini kullanır. Kümenin tek başına Service Fabric, hata etki alanları kümenin ayarlandığı anda tanımlanır.

Aşağıdaki grafikte, hata etki alanlarına katkıda bulunan tüm varlıkların yanı sıra sonuçlanan tüm farklı hata etki alanlarını da listeliyoruz. Bu örnekte, veri merkezlerimiz ("DC"), raflar ("R") ve dikey pencereler ("B") vardır. Her dikey pencere birden fazla sanal makine barındırıyorsa, hata etki alanı hiyerarşisinde başka bir katman olabilir.

Çalışma zamanı sırasında Service Fabric Küme Kaynak Yöneticisi, küme ve plan düzenlerindeki hata etki alanlarını dikkate alır. Durum bilgisi olan çoğaltmalar veya bir hizmetin durum bilgisiz örnekleri ayrı hata etki alanlarında olacak şekilde dağıtılır. Hizmeti hata etki alanları arasında dağıtmak, hiyerarşinin herhangi bir düzeyinde hata etki alanı başarısız olduğunda hizmetin kullanılabilirliğini tehlikeye atmaz.

Küme Kaynak Yöneticisi, hata etki alanı hiyerarşisinde kaç katman olduğunu önemser. Hiyerarşinin bir kısmının kaybının içinde çalışan hizmetleri etkilemesini sağlamaya çalışır.

Hata etki alanı hiyerarşisinde her derinlik düzeyinde aynı sayıda düğüm olması en iyisidir. Hata etki alanlarının "ağacı" kümenize dengesizse, en iyi hizmet ayırmayı Küme Kaynak Yöneticisi daha zordur. Dengesiz hata etki alanı düzenleri, bazı etki alanlarının kaybının hizmetlerin diğer etki alanlarından daha fazla kullanılabilirliğini etkilediği anlamına geliyor. Sonuç olarak, Küme Kaynak Yöneticisi iki hedef arasında ayrım yapılan bir durum ortaya çıkan:

• Bu "ağır" etki alanındaki makinelerin üzerine hizmetler yerleştirerek kullanmak istiyor.
• Bir etki alanının kaybının sorunlara neden olması için hizmetleri diğer etki alanlarına da yer almak istiyor.

Dengesiz etki alanları nasıl görünüyor? Aşağıdaki diyagramda iki farklı küme düzeni yer almaktadır. İlk örnekte düğümler hata etki alanları arasında eşit olarak dağıtılır. İkinci örnekte, bir hata etki alanının diğer hata etki alanlarından çok daha fazla düğümü vardır.

Azure'da düğüm içeren hata etki alanı seçimi sizin için yönetilir. Ancak, sağlanan düğüm sayısına bağlı olarak, yine de içinde diğerlerine göre daha fazla düğüme sahip hata etki alanları olabilir.

Örneğin, kümede beş hata etki alanınız olduğunu ancak bir düğüm türü için yedi düğüm (NodeType) sağlarsınız. Bu durumda, ilk iki hata etki alanı daha fazla düğüme sahip olur. Yalnızca birkaç örnekle daha fazla NodeType örneği dağıtmaya devam edersiniz, sorun daha da kötüleşir. Bu nedenle, her düğüm türünde düğüm sayısının hata etki alanı sayısının katları olması önerilir.

Yükseltme etki alanları

Yükseltme etki alanları, kümenin yerleşimini anlamasına Kaynak Yöneticisi Service Fabric kümesine yardımcı olan başka bir özelliktir. Yükseltme etki alanları, aynı anda yükseltilen düğüm kümelerini tanımlar. Yükseltme etki alanları, yükseltmeler gibi yönetim işlemlerini anlamak ve yönetmek Kaynak Yöneticisi Yardım kümesi sağlar.

Yükseltme etki alanları, hata etki alanları gibi birçok önemli fark ile aynıdır. İlk olarak, Eşgüdümlü donanım hatalarının alanları hata etki alanlarını tanımlar. Diğer yandan yükseltme etki alanları, ilke tarafından tanımlanmıştır. Ortamın numarayı dikte etmek yerine kaç tane istediğinize karar verirsiniz. Düğümleri yaptığınız kadar çok yükseltme etki alanına sahip olabilirsiniz. Hata etki alanları ve yükseltme etki alanları arasındaki diğer bir farklılık, yükseltme etki alanlarının hiyerarşik olmaması. Bunun yerine, basit bir etiket gibi daha fazla şey vardır.

Aşağıdaki diyagramda, üç hata etki alanı üzerinde dizili üç yükseltme etki alanı gösterilmektedir. Ayrıca, her biri farklı hata ve yükseltme etki alanlarında biten, durum bilgisi olan bir hizmetin üç farklı çoğaltması için olası bir yerleşimi gösterir. Bu yerleştirme, bir hizmet yükseltmenin ortasında bir hata etki alanının kaybedilmesine ve kod ve verilerin bir kopyasına sahip olmaya devam etmesine izin verir.

Çok sayıda yükseltme etki alanı sağlamak için olumlu ve olumsuz yönleri vardır. Daha fazla yükseltme etki alanı, yükseltmenin her bir adımının daha ayrıntılı olduğu ve daha az sayıda düğüm veya hizmeti etkilediği anlamına gelir. Aynı anda, sisteme daha az dalgalanmaya yönelik daha az sayıda hizmetin taşınması gerekir. Bu, hizmetin daha az bir yükseltme sırasında tanıtılan herhangi bir sorundan etkilenmemesi nedeniyle güvenilirliği artırmaya eğilimindedir. Daha fazla yükseltme etki alanı, yükseltmenin etkisini işlemek için diğer düğümlerde daha az kullanılabilir arabelleğe ihtiyacınız olduğu anlamına da gelir.

Örneğin, beş yükseltme etki alanınız varsa, her düğüm trafiğinizin yaklaşık yüzde 20'sinde işlemdedir. Yükseltme için bu yükseltme etki alanını aşağı taşımanız gerekirse, bu yükün genellikle bir yere gitmeleri gerekir. Dört yükseltme etki alanınız olduğu için her biri toplam trafiğin yaklaşık yüzde 25'ine yer olmalıdır. Daha fazla yükseltme etki alanı, kümedeki düğümlerde daha az arabelleğe ihtiyacınız olduğu anlamına geliyor.

Bunun yerine 10 yükseltme etki alanınız olduğunu düşünün. Bu durumda, her yükseltme etki alanı toplam trafiğin yalnızca yaklaşık yüzde 10'larını işler. Bir yükseltme işlemi küme boyunca adım attığında, her etki alanının toplam trafiğin yaklaşık yüzde 11'i için yer olmalıdır. Daha fazla yükseltme etki alanı genellikle daha az ayrılmış kapasiteye ihtiyacınız olduğundan düğümlerinizi daha yüksek kullanımla çalıştırmanıza olanak sağlar. Hata etki alanları için de aynı durum aynıdır.

Birçok yükseltme etki alanına sahip olmak, yükseltmelerin daha uzun süre devam ediyor olmasıdır. Service Fabric bir yükseltme etki alanı tamamlandıktan sonra kısa bir süre bekler ve sonrakini yükseltmeye başlamadan önce denetimler gerçekleştirir. Bu gecikmeler yükseltme devammeden önce yükseltme tarafından ortaya konu olan sorunların algılanabilir. Kötü değişikliklerin aynı anda çok fazla hizmeti etkilemesini önlediği için takas kabul edilebilir.

Çok az yükseltme etki alanının olması birçok olumsuz yan etki alanına sahiptir. Her yükseltme etki alanı kullanım dışı ve yükseltiliyorken, genel kapasitenizin büyük bir bölümü kullanılamaz. Örneğin, yalnızca üç yükseltme etki alanınız varsa, genel hizmet veya küme kapasitenizin yaklaşık üçte birini aynı anda kapatabilirsiniz. Kümenizin geri kalanında iş yükünü işlemek için yeterli kapasiteye ihtiyacınız olduğundan, hizmetinizin aynı anda çok büyük bir kapasiteye sahip olması tercih edilmez. Bu arabelleği korumak, normal işlem sırasında bu düğümlerin normalden daha az yükleniyor olduğu anlamına gelir. Bu, hizmetinizi çalıştırmanın maliyetini artırır.

Bir ortamdaki toplam hata veya yükseltme etki alanı sayısı veya bunların çakışması ile ilgili gerçek bir sınır yoktur. Ancak yaygın desenler vardır:

• Hata etki alanları ve yükseltme etki alanları 1:1
• Düğüm başına bir yükseltme etki alanı (fiziksel veya sanal işletim sistemi örneği)
• Hata etki alanları ve yükseltme etki alanlarının genellikle köşegenler altında çalışan makinelerle matris oluşturmakta olduğu bir "şeritli" veya "matris" modeli

Hangi düzen arasından seçim yapabileceğiniz en iyi yanıt yok. Her birinin profesyonelleri ve dezavantajları vardır. Örneğin, 1FD: 1UD modelinin ayarlanması basittir. Düğüm modeli başına bir yükseltme etki alanının modeli, çoğu kişinin hangi kişilerin kullanıldığı gibidir. Yükseltmeler sırasında her düğüm bağımsız olarak güncelleştirilir. Bu, geçmişte küçük makine kümelerinin el ile yükseltilme biçimine benzer.

En yaygın model, hata etki alanları ve yükseltme etki alanları bir tablo ve düğümlerin köşegen bir şekilde başlayarak yerleştirildiği FD/UD matrisini oluşturur. Bu, varsayılan olarak Azure 'daki Service Fabric kümelerinde kullanılan modeldir. Birçok düğümü olan kümeler için her şey yoğun matris düzenine benzer şekilde çalışır.

Hata ve yükseltme etki alanı kısıtlamaları ve sonuç davranışı

Varsayılan yaklaşım

Varsayılan olarak, Cluster Kaynak Yöneticisi, Hizmetleri hata ve yükseltme etki alanlarında dengeleyerek tutar. Bu, kısıtlamaolarak modellenir. Hata ve yükseltme etki alanları için kısıtlama durumları: "Belirli bir hizmet bölümü için, aynı hiyerarşi düzeyindeki herhangi iki etki alanı arasında hizmet nesneleri (durum bilgisiz hizmet örnekleri veya durum bilgisi olan hizmet çoğaltmaları) sayısından büyük bir fark asla olmayacaktır."

Bu kısıtlamanın "maksimum fark" garantisi sağladığını söylemek gerekir. Hata ve yükseltme etki alanları kısıtlaması, kuralı ihlal eden bazı hareket veya düzenlemeleri önler.

Örneğin, beş hata etki alanı ve beş yükseltme etki alanı ile yapılandırılmış altı düğüme sahip bir kümemiz olduğunu diyelim.

Şimdi, bir Targetreplicasetsize (veya durum bilgisiz hizmeti, InstanceCount) değeri için beş olan bir hizmet oluşturduğunuzu varsayalım. Çoğaltmalar, N1-N5 düğümünde üzerinde yer alır. Aslında, bunun gibi kaç hizmetin oluşturulduğuna bakılmaksızın N6 hiçbir şekilde kullanılmaz. Ancak neden? Geçerli düzen arasındaki farka ve N6 seçilirse ne olacağını inceleyelim.

Hata ve yükseltme etki alanı başına aldığımız düzen ve toplam çoğaltma sayısı aşağıda verilmiştir:

Bu düzen, hata etki alanı ve yükseltme etki alanı başına düğümler açısından dengelidir. Ayrıca hata ve yükseltme etki alanı başına çoğaltma sayısı açısından da dengelidir. Her etki alanı aynı sayıda düğüme ve aynı sayıda çoğaltmaya sahip.

Şimdi N2 yerine N6'yi kullandıy olsaydık neler olacağını bir bakalım. Çoğaltmalar nasıl dağıtılabilir?

Bu düzen, hata etki alanı kısıtlaması için "en yüksek fark" garantisi tanımımızı ihlal eder. FD0 iki çoğaltmaya sahipken FD1 sıfıra sahip. FD0 ile FD1 arasındaki fark toplam ikidir ve bu, bir arasındaki en büyük farktan büyüktür. Kısıtlama ihlal edilmiş olduğundan Küme Kaynak Yöneticisi düzenlemeye izin vermez.

Benzer şekilde, N2 ve N6'yi (N1 ve N2 yerine) seçtiğimiz zaman şu olur:

Bu düzen hata etki alanları açısından dağıtılır. Ancak artık yükseltme etki alanı kısıtlamasını ihlal ediyor, çünkü UD0 sıfır çoğaltmalar ve UD1 iki sahip. Bu düzen ayrıca geçersiz ve Küme Kaynak Yöneticisi tarafından çekilmeyecektir.

Durum bilgisi olan çoğaltmaların veya durum bilgisiz örneklerin dağıtımına yönelik bu yaklaşım, olası en iyi hataya dayanıklılık sağlar. Bir etki alanı aşağı gittiğinde, en az sayıda çoğaltma/örnek kaybolur.

Öte yandan, bu yaklaşım çok katı olabilir ve kümenin tüm kaynakları kullanmasına izin vermez. Belirli küme yapılandırmalarında bazı düğümler kullanılamaz. Bu, Service Fabric ve uyarı iletilerine neden olan hizmetlerinizi yerleştiremez. Önceki örnekte, bazı küme düğümleri kullanılamaz (örnekte N6). Düğümleri bu kümeye (N7-N10) ekleseniz bile çoğaltmalar/örnekler yalnızca, hata ve yükseltme etki alanlarındaki kısıtlamalar nedeniyle N1 – N5 düğümünde üzerine yerleştirilir.

Alternatif yaklaşım

Küme Kaynak Yöneticisi, hata ve yükseltme etki alanları için kısıtlamanın başka bir sürümünü destekler. En düşük güvenlik düzeyini garanti ederken yerleştirmeye izin verir. Alternatif kısıtlama şu şekilde belirtebilirsiniz: "Belirtilen hizmet bölümü için etki alanları arasında çoğaltma dağıtımı, bölümün çekirdek kaybıyla karşı karşıya olmadığını garantilemektedir." Bu kısıtlamanın "çekirdek güvenli" garantisi sağladığını kabul etmek gerekir.

Önceki örneğe geri gidelim. Kısıtlamanın "çekirdek güvenli" sürümü ile üç düzen de geçerli olur. FD0 ikinci düzen içinde başarısız olsa veya UD1 üçüncü düzende başarısız olduysa, bölüm yine de çekirdeğe sahip olur. (Çoğaltmaların büyük bölümü yine de devam edebilir.) Kısıtlamasının bu sürümü ile, N6 neredeyse her zaman kullanılabilir.

"Çekirdek güvenli" yaklaşımı, "en yüksek fark" yaklaşımına göre daha fazla esneklik sağlar. Bunun nedeni, neredeyse tüm küme topolojisinde geçerli olan çoğaltma dağıtımlarını bulmayı daha kolay hale getirir. Ancak, bazı hatalardan bazıları diğerlerinden daha kötü olduğundan bu yaklaşım en iyi hata toleransı özelliklerini garanti edemez.

En kötü durum senaryosunda, çoğaltmaların bir çoğunluğu bir etki alanı ve bir ek çoğaltma hatasıyla kaybolabilir. Örneğin, beş çoğaltma veya örnek ile çekirdekte olması gereken üç başarısızlık yerine, artık yalnızca iki başarısızıza sahip bir büyük bölümü kaybedebilirsiniz.

Uyarlamalı yaklaşım

Her iki yaklaşımın de güçlü ve zayıf yönleri olduğundan, bu iki stratejiyi birleştiren bir uyarlamalı yaklaşım sunuyoruz.

Önceki örneğine geri dönüp bir kümede artık sekiz düğüm olduğunu varsayalım. Küme beş hata etki alanı ve beş yükseltme etki alanıyla yapılandırılmaya devam eder ve bu kümede barındırılan bir hizmetin TargetReplicaSetSize değeri beş kalır.

Tüm gerekli koşullar karşılandığından, Küme Kaynak Yöneticisi hizmeti dağıtırken "çekirdek tabanlı" mantığını kullanacaktır. Bu, N6-N8 kullanımını mümkün bir şekilde sunar. Bu durumda olası bir hizmet dağıtımı şöyle görünebilir:

Hizmetinizin TargetReplicaSetSize değeri dörte düşürülse (örneğin), Küme Kaynak Yöneticisi değişikliği fark etmez. TargetReplicaSetSize artık hata etki alanı ve yükseltme etki alanı sayısına bölünemiyoruz. Sonuç olarak, N1-N5 düğümlerinde kalan dört çoğaltmayı dağıtmak için bazı çoğaltma taşımaları gerçekleşir. Bu şekilde, hata etki alanı ve yükseltme etki alanı mantığının "en yüksek fark" sürümü ihlal olmaz.

Önceki düzende TargetReplicaSetSize değeri beş ise ve N1 kümeden kaldırılırsa, yükseltme etki alanlarının sayısı dörte eşit olur. Yine Küme Kaynak Yöneticisi etki alanlarının sayısı hizmetin TargetReplicaSetSize değerini artık eşit olarak bölmey olduğundan "maksimum fark" mantığını kullanmaya başlar. Sonuç olarak, yeniden 1 çoğaltması 4 üzerine iner, böylece hata ve yükseltme etki alanı kısıtlaması ihlal olmaz.

Hata ve yükseltme etki alanlarını yapılandırma

Azure'da barındırılan Service Fabric dağıtımları, hata etki alanları ve yükseltme etki alanları otomatik olarak tanımlanır. Service Fabric Azure'dan ortam bilgilerini alır ve kullanır.

Kendi kümenizi oluşturuyorsanız (veya geliştirme sırasında belirli bir topolojiyi çalıştırmak) hata etki alanını silebilir ve etki alanı bilgilerini kendiniz yükseltebilirsiniz. Bu örnekte, üç veri merkezinden (her biri üç rafa sahip) yayılan dokuz düğümlü bir yerel geliştirme kümesi tanımlayacağız. Bu kümede ayrıca bu üç veri merkezinde şeritlenmiş üç yükseltme etki alanı vardır. Aşağıdaki örnekte ClusterManifest.xml:

  <Infrastructure>
    <!-- IsScaleMin indicates that this cluster runs on one box/one single server -->
    <WindowsServer IsScaleMin="true">
      <NodeList>
        <Node NodeName="Node01" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType01" FaultDomain="fd:/DC01/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node02" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType02" FaultDomain="fd:/DC01/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node03" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType03" FaultDomain="fd:/DC01/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
        <Node NodeName="Node04" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType04" FaultDomain="fd:/DC02/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node05" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType05" FaultDomain="fd:/DC02/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node06" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType06" FaultDomain="fd:/DC02/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
        <Node NodeName="Node07" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType07" FaultDomain="fd:/DC03/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node08" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType08" FaultDomain="fd:/DC03/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node09" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType09" FaultDomain="fd:/DC03/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
      </NodeList>
    </WindowsServer>
  </Infrastructure>

Bu örnekte, ClusterConfig.jsdağıtımlar için aşağıdakiler 2010'da 200'den fazladır:

"nodes": [
  {
    "nodeName": "vm1",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm2",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm3",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD3"
  },
  {
    "nodeName": "vm4",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm5",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm6",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD3"
  },
  {
    "nodeName": "vm7",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm8",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm9",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD3"
  }
],

Düğüm özellikleri ve yerleştirme kısıtlamaları

Bazen (aslında çoğu zaman) belirli iş yüklerinin yalnızca kümedeki belirli düğüm türlerinde çalıştığından emin olmak istersiniz. Örneğin, bazı iş yükleri GPU'lar veya SSD'ler gerektirse de diğerleri gerektirmeksizin.

Donanımı belirli iş yüklerine hedeflemenin harika bir örneği, neredeyse her n katmanlı mimaridir. Belirli makineler, uygulamanın ön uç veya API'ye hizmet veren tarafı olarak görev yapan ve istemcilere veya İnternet'e açık olan makinelerdir. Genellikle farklı donanım kaynakları olan farklı makineler, işlem veya depolama katmanlarının çalışmalarını işler. Bunlar genellikle doğrudan istemcilere veya İnternet'e açık değildir.

Service Fabric bazı durumlarda belirli iş yüklerinin belirli donanım yapılandırmalarında çalışması gerektirebilir. Örnek:

• Var olan n katmanlı bir uygulama, bir Service Fabric ortamına "yükseltilmemiş ve" kaydırmıştır.
• Performans, ölçek veya güvenlik yalıtımı nedenleriyle belirli bir donanımda iş yükünün çalıştırılması gerekir.
• İlke veya kaynak tüketimi nedeniyle iş yükü diğer iş yüklerinden yalıtılmalıdır.

Bu yapılandırma türlerini desteklemek için Service Fabric düğümlere uygulayabileceğiniz Etiketler içerir. Bu etiketlere düğüm özellikleri denir. Yerleştirme kısıtlamaları , bir veya daha fazla düğüm özelliği için seçtiğiniz ayrı hizmetlere eklenen ifadelerdir. Yerleştirme kısıtlamaları, hizmetlerin nerede çalışacağını tanımlar. Kısıtlama kümesi genişletilebilir. Herhangi bir anahtar/değer çifti çalışabilir. Service Fabric 8,1 ' den başlayarak, düğüm özellikleri, iş yüklerini çalıştırmaya yönelik bir kesinti olmadan dinamik olarak güncellenebilir.

Yerleşik düğüm özellikleri

Service Fabric, otomatik olarak kullanılabilecek bazı varsayılan düğüm özelliklerini tanımlar, böylece bunları tanımlamanız gerekmez. Her düğümde tanımlanan varsayılan Özellikler NodeType ve düğüdir.

Örneğin, olarak bir yerleştirme kısıtlaması yazabilirsiniz "(NodeType == NodeType03)" . NodeType yaygın olarak kullanılan bir özelliktir. Bir makine türü ile 1:1 ' a karşılık geldiği için yararlıdır. Her makine türü geleneksel n katmanlı bir uygulamadaki bir iş yükü türüne karşılık gelir.

Yerleştirme kısıtlamaları ve düğüm özelliği sözdizimi

Node özelliğinde belirtilen değer bir dize, Boole veya imzalı uzun olabilir. Hizmette deyimine yerleştirme kısıtlaması adı verilen bu ifade, hizmetin kümede nerede çalıştırılasa kısıtlar. Kısıtlama, kümedeki düğüm özellikleri üzerinde çalışan herhangi bir Boole deyimi olabilir. Bu Boole deyimleri içinde geçerli seçiciler:

• Belirli deyimleri oluşturmak için koşullu denetimler:

  Deyim	Syntax
  "eşittir"	"=="
  "eşit değildir"	"!="
  "büyüktür"	">"
  "büyüktür veya eşittir"	">="
  "küçükten"	"<"
  "küçük veya eşittir"	"<="

• Gruplama ve mantıksal işlemler için Boole deyimleri:

  Deyim	Syntax
  "and"	"&&"
  "or"	"||"
  başlatılmadı	"!"
  "tek deyimli grupla"	"()"

Temel kısıtlama deyimlerinin bazı örnekleri aşağıda verilmiştir:

• "Value >= 5"
• "NodeColor != green"
• "((OneProperty < 100) || ((AnotherProperty == false) && (OneProperty >= 100)))"

Yalnızca genel yerleştirme kısıtlaması deyiminin "true" olarak değerlendirilen düğümleri hizmetin bu hizmete yerleştirilmesini sağlayabilir. Tanımlı bir özelliği olmayan düğümler, özelliği içeren herhangi bir yerleştirme kısıtlamasına uymuyor.

Aşağıdaki düğüm özelliklerinin ClusterManifest.xml bir düğüm türü için tanımlandığını varsayalım:

    <NodeType Name="NodeType01">
      <PlacementProperties>
        <Property Name="HasSSD" Value="true"/>
        <Property Name="NodeColor" Value="green"/>
        <Property Name="SomeProperty" Value="5"/>
      </PlacementProperties>
    </NodeType>

Aşağıdaki örnek, Azure 'da barındırılan kümeler için tek başına dağıtımlar veya Template.jsüzerinde ClusterConfig.jsaracılığıyla tanımlanan düğüm özelliklerini gösterir.

"nodeTypes": [
    {
        "name": "NodeType01",
        "placementProperties": {
            "HasSSD": "true",
            "NodeColor": "green",
            "SomeProperty": "5"
        },
    }
],

Bir hizmet için hizmet yerleştirme kısıtlamalarını aşağıdaki gibi oluşturabilirsiniz:

FabricClient fabricClient = new FabricClient();
StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
serviceDescription.PlacementConstraints = "(HasSSD == true && SomeProperty >= 4)";
// Add other required ServiceDescription fields
//...
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceType -Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementConstraint "HasSSD == true && SomeProperty >= 4"

Tüm NodeType01 düğümleri geçerliyse, kısıtlama ile bu düğüm türünü de seçebilirsiniz "(NodeType == NodeType01)" .

Hizmetin yerleştirme kısıtlamaları, çalışma zamanı sırasında dinamik olarak güncelleştirilir. Gerekirse, bir hizmeti kümedeki etrafında taşıyabilir, gereksinimleri ekleyebilir ve kaldırabilir ve benzeri devam edebilirsiniz. Service Fabric, bu tür değişiklikler yapıldığında bile hizmetin çalışır durumda kalmasını sağlar.

StatefulServiceUpdateDescription updateDescription = new StatefulServiceUpdateDescription();
updateDescription.PlacementConstraints = "NodeType == NodeType01";
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

Update-ServiceFabricService -Stateful -ServiceName $serviceName -PlacementConstraints "NodeType == NodeType01"

Yerleştirme kısıtlamaları, her bir adlandırılmış hizmet örneği için belirtilir. Güncelleştirmeler, daha önce belirtildiği gibi her zaman (üzerine yazma) yerini alır.

Küme tanımı bir düğümdeki özellikleri tanımlar. Bir düğümün özelliklerini değiştirmenin küme yapılandırmasına yükseltilmesi gerekir. Bir düğümün özelliklerini yükseltmek, etkilenen her düğümün yeni özelliklerini raporlamak için yeniden başlatılmasını gerektirir. Service Fabric bu sıralı yükseltmeleri yönetir.

Küme kaynaklarını açıklama ve yönetme

Herhangi bir orchestrator'ın en önemli işlerinden biri, kümede kaynak tüketimini yönetmeye yardımcı olmaktır. Küme kaynaklarının yönetilmesi birkaç farklı anlama geliyor olabilir.

İlk olarak makinelerin aşırı yüklenmesini sağlamak gerekir. Bu, makinelerin işleyene kadar çok hizmet çalıştırmamalarını sağlar.

İkinci olarak, hizmetleri verimli bir şekilde çalıştırma açısından kritik öneme sahip olan dengeleme ve iyileştirme vardır. Uygun maliyetli veya performansa duyarlı hizmet teklifleri, bazı düğümlerin etkin olmasına izin vermezken diğerleri soğuktur. Yoğun düğümler kaynakta bir baskıya ve düşük performansa neden olur. Soğuk düğümler boşa harcanan kaynakları ve artan maliyetleri temsil ediyor.

Service Fabric, kaynakları ölçüm olarak temsil eder. Ölçümler, ölçümler için açıklamak istediğiniz mantıksal veya fiziksel Service Fabric. Ölçümlere örnek olarak "WorkQueueDepth" veya "MemoryInMb" örnekleri verilmiştir. Düğümler üzerinde yönetilen fiziksel Service Fabric için bkz. Kaynak idaresi. Uygulama tarafından kullanılan varsayılan ölçümler ve özel Küme Kaynak Yöneticisi yapılandırma hakkında bilgi için bu makaleye bakın.

Ölçümler, yerleştirme kısıtlamalarından ve düğüm özelliklerinden farklıdır. Düğüm özellikleri, düğümlerin statik tanımlayıcılarıdır. Ölçümler, düğümlerin sahip olduğu kaynakları ve hizmetlerin bir düğümde çalıştırarak tükettiği kaynakları açıklar. Düğüm özelliği HasSSD olabilir ve true veya false olarak ayarlanmış olabilir. Söz konusu SSD'de kullanılabilir alan miktarı ve hizmetler tarafından ne kadar tüketildiği "DriveSpaceInMb" gibi bir ölçüm olabilir.

Yerleştirme kısıtlamaları ve düğüm özelliklerinde olduğu Service Fabric Küme Kaynak Yöneticisi, ölçümlerin adlarının ne anlama geliyor olduğunu anlamaz. Ölçüm adları yalnızca dizelerdir. Birimleri belirsiz olmaları durumunda oluşturduğunuz ölçüm adlarının bir parçası olarak bildirmek iyi bir uygulamadır.

Kapasite

Tüm kaynak dengelemeyi kapatırsanız Service Fabric küme kaynak yöneticisi kapasitesinin üzerinde hiçbir düğümün kaybolmamasını sağlamaya devam eder. Küme çok dolu olmadığı veya iş yükü herhangi bir düğümden daha büyük olmadığı için kapasite taşmalarının yönetilmesi mümkündür. Kapasite, Küme Kaynak Yöneticisi bir düğümün bir kaynağın ne kadarının olduğunu anlamak için kullandığı başka bir kısıtlamadır . Kalan kapasite Ayrıca küme için bir bütün olarak izlenir. Service Fabric 8,1 ' den başlayarak, düğüm kapasiteleri, iş yüklerini çalıştırmaya yönelik bir kesinti olmadan dinamik olarak güncellenebilir.

Kapasite ve hizmet düzeyindeki tüketim, ölçümler bakımından ifade edilir. Örneğin, ölçüm "ClientConnections" olabilir ve bir düğümde 32.768 'nin "ClientConnections" kapasitesi olabilir. Diğer düğümlerin başka sınırları olabilir. Bu düğümde çalışan bir hizmet, şu anda "ClientConnections" ölçüsünün 32.256 ' i tükettiğini söyleyebilir.

Çalışma zamanı sırasında küme Kaynak Yöneticisi kümedeki ve düğümlerdeki kalan kapasiteyi izler. Küme Kaynak Yöneticisi, kapasiteyi izlemek için her hizmetin kullanımını, bir düğümün hizmetin çalıştığı kapasitesinden çıkartır. Bu bilgilerle, Küme Kaynak Yöneticisi düğümlerin kapasite üzerinde ilerlemez olması için çoğaltmaları nereye yerleştireceğinizi veya taşıyabileceğinizi anlayabilir.

StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
ServiceLoadMetricDescription metric = new ServiceLoadMetricDescription();
metric.Name = "ClientConnections";
metric.PrimaryDefaultLoad = 1024;
metric.SecondaryDefaultLoad = 0;
metric.Weight = ServiceLoadMetricWeight.High;
serviceDescription.Metrics.Add(metric);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ClientConnections,High,1024,0)

Küme bildiriminde tanımlanan kapasiteleri görebilirsiniz. ClusterManifest.xml için bir örnek aşağıda verilmiştir:

    <NodeType Name="NodeType03">
      <Capacities>
        <Capacity Name="ClientConnections" Value="65536"/>
      </Capacities>
    </NodeType>

Azure 'da barındırılan kümeler için tek başına dağıtımlar veya Template.jsClusterConfig.jsaracılığıyla tanımlanan kapasiteye bir örnektir:

"nodeTypes": [
    {
        "name": "NodeType03",
        "capacities": {
            "ClientConnections": "65536",
        }
    }
],

Bir hizmetin yükü genellikle dinamik olarak değişir. Bir çoğaltmanın "ClientConnections" yükünün 1.024 ile 2.048 arasında değiştiğini varsayalım. Daha sonra üzerinde çalışan düğümde bu ölçüm için yalnızca 512 kapasite kaldı. Artık çoğaltma veya örneğin yerleşimi geçersizdir çünkü bu düğümde yeterli alan yok. Küme Kaynak Yöneticisi kapasitenin altına geri almak zorunda. Bir veya daha fazla çoğaltmayı veya örneği bu düğümden diğer düğümlere hareket ettirerek kapasitenin üzerinde olan düğüm üzerindeki yükü azaltır.

Küme Kaynak Yöneticisi, çoğaltmaları taşıma maliyetini en aza indirmeye çalışır. Taşıma maliyeti ve yeniden yapılandırma stratejileri ve kuralları hakkında daha fazla bilgi edinmek için:.

Küme kapasitesi

Küme Service Fabric Küme Kaynak Yöneticisi fazla dolu olmaya nasıl devam ediyor? Dinamik yükte çok fazla şey olmaz. Hizmetlerin yüklerinde ani artışlar olabilir ve bu işlemlerden bağımsız Küme Kaynak Yöneticisi olabilir. Sonuç olarak, yarın ani bir artış olursa, bugün çok fazla yer olan kümeniz yeterli güçte olabilir.

Denetimler Küme Kaynak Yöneticisi önlemeye yardımcı olur. İlk olarak, kümenin dolup dolmasına neden olacak yeni iş yükleri oluşturulmasını önlemektir.

Durum bilgisiz bir hizmet oluşturabilirsiniz ve bu hizmetle ilişkili bir yüke sahip olur. Hizmet, "DiskSpaceInMb" ölçümlerini önemser. Hizmet, hizmetin her örneği için beş birim "DiskSpaceInMb" tüketir. Hizmetin üç örneğini oluşturmak istediğiniz. Bu, bu hizmet örneklerini oluşturmanız için kümede 15 birim "DiskSpaceInMb" olması gerektirmektedir.

Küme Kaynak Yöneticisi, kümede kalan kapasiteyi belirleyecek şekilde her ölçümün kapasitesini ve tüketimini sürekli olarak hesaplar. Yeterli alan yoksa, Küme Kaynak Yöneticisi hizmeti oluşturmak için çağrıyı reddeder.

Gereksinim yalnızca 15 birimin kullanılabilir olacağı için, bu alanı birçok farklı yolla ayırabilirsiniz. Örneğin, 15 farklı düğümde kalan bir kapasite birimi ya da beş farklı düğüm üzerinde kalan üç kapasite birimi olabilir. Küme Kaynak Yöneticisi her şeyi yeniden düzenleyebilir, bu nedenle üç düğümde kullanılabilir beş birim bulunur ve hizmeti koyar. Küme neredeyse tam olmadığı veya mevcut hizmetler bazı nedenlerle birleştirilamadıkça kümeyi yeniden düzenleme işlemi genellikle mümkündür.

Düğüm arabelleği ve fazla kayıt kapasitesi

Ölçüm için bir düğüm kapasitesi belirtilmişse, toplam yük belirtilen düğüm kapasitesini aşacağından, Küme Kaynak Yöneticisi çoğaltmaları hiçbir şekilde bir düğüme yerleştirmez veya taşımaz. Bu, bazen yeni çoğaltmaların yerleşimini engelleyebilir veya küme tam kapasiteye yaklaşmışsa ve büyük bir yüklemeye sahip bir çoğaltmanın yerleştirilmesi, değiştirilmesi veya taşınması gerekir.

Daha fazla esneklik sağlamak için düğüm arabelleği veya fazla kayıt kapasitesi belirtebilirsiniz. Bir ölçüm için düğüm arabelleği veya aşırı kayıt kapasitesi belirtildiğinde, Küme Kaynak Yöneticisi çoğaltmaları, arabellek veya fazla kayıt kapasitesi kullanım dışı kalacak şekilde yerleştirme veya taşıma girişiminde bulunur, ancak bu, hizmet kullanılabilirliğini artıran eylemler için gerektiğinde arabellek veya fazla kayıt kapasitesinin kullanılmasına izin verir:

• Yeni çoğaltma yerleşimi veya başarısız çoğaltmaları değiştirme
• Yükseltmeler sırasında yerleştirme
• Yazılım ve donanım kısıtlama ihlallerinin düzeltilmesi
• Birleştirme

Düğüm arabellek kapasitesi, belirtilen düğüm kapasitesi ve fazla kayıt kapasitesi belirtilen düğüm kapasitesinin üzerinde fazladan kapasitenin bir kısmını temsil eder. Her iki durumda da, Küme Kaynak Yöneticisi bu kapasiteyi ücretsiz tutmaya çalışacaktır.

Örneğin, bir düğümün CpuUtilization ölçümü için belirtilen kapasiteye sahip olması ve bu ölçüm için düğüm arabellek yüzdesinin %20 olarak ayarlanmış olması, toplam ve arabelleğe almamış kapasitelerin toplamının sırasıyla 100 ve 80 olması ve Küme Kaynak Yöneticisi'nin normal koşullarda düğüme 80'den fazla yük birimi eklemez.

Düğüm arabelleği, düğüm kapasitesinin yalnızca yukarıda belirtilen hizmet kullanılabilirliğini artıran eylemler için kullanılacak bir kısmının ayrılacağı zaman kullanılmalıdır.

Öte yandan, düğüm overbooking yüzdesi kullanılır ve %20 olarak ayarlanırsa toplam ve aralıksız kapasiteler sırasıyla 120 ve 100 olur.

Toplam kaynak kullanımı kapasiteyi aşsa bile Küme Kaynak Yöneticisi bir düğüme çoğaltmalar eklemesine izin vermek istediğiniz zaman fazla kullanım kapasitesi kullanılmalıdır. Bu, performans karşılığında hizmetler için ek kullanılabilirlik sağlamak için kullanılabilir. Overbooking kullanılıyorsa, kullanıcı uygulama mantığının gerektirilenden daha az fiziksel kaynakla çalışması gerekir.

Düğüm arabelleği veya fazla kullanım kapasiteleri belirtilirse, Küme Kaynak Yöneticisi hedef düğümdeki toplam yük toplam kapasiteden fazla olursa (düğüm arabelleği ve düğüm kapasitesi + fazla kullanım durumunda düğüm kapasitesi + fazla kullanım kapasitesi) çoğaltmaları taşımaz veya taşımaz.

Overbooking kapasitesi sonsuz olarak da belirtilebilir. Bu durumda, Küme Kaynak Yöneticisi düğümdeki toplam yükü belirtilen düğüm kapasitesinin altında tutmaya çalışsa da düğümde çok daha büyük bir yük eklemesine izin verilir ve bu da ciddi performans düşüşüne yol açabilir.

Bir ölçümün aynı anda hem düğüm arabelleği hem de aşırı kullanım kapasitesi belirtilebilir.

Aşağıdaki örnekte,ClusterManifest.xml'da düğüm arabelleği veya fazla kapasiteleriClusterManifest.xml:

<Section Name="NodeBufferPercentage">
    <Parameter Name="SomeMetric" Value="0.15" />
</Section>
<Section Name="NodeOverbookingPercentage">
    <Parameter Name="SomeOtherMetric" Value="0.2" />
    <Parameter Name=”MetricWithInfiniteOverbooking” Value=”-1.0” />
</Section>

Azure 'da barındırılan kümeler için tek başına dağıtımlar veya Template.js üzerinde ClusterConfig.js aracılığıyla düğüm arabelleğinin veya fazla kayıt kapasitelerinin nasıl belirtilme örneği aşağıda verilmiştir:

"fabricSettings": [
  {
    "name": "NodeBufferPercentage",
    "parameters": [
      {
          "name": "SomeMetric",
          "value": "0.15"
      }
    ]
  },
  {
    "name": "NodeOverbookingPercentage",
    "parameters": [
      {
          "name": "SomeOtherMetric",
          "value": "0.20"
      },
      {
          "name": "MetricWithInfiniteOverbooking",
          "value": "-1.0"
      }
    ]
  }
]

Sonraki adımlar

• Küme Kaynak Yöneticisi içindeki mimari ve bilgi akışı hakkında daha fazla bilgi için bkz. küme kaynak yöneticisi mimarisine genel bakış.
• Birleştirme ölçümlerini tanımlamak yerine düğümlerin yükünü birleştirmek için bir yoldur. Birleştirme yapılandırma hakkında bilgi edinmek için bkz. ölçüm birleştirme ve Service Fabric yük.
• Baştan başlayıp Service Fabric küme kaynak yöneticisi bir giriş alın.
• Küme Kaynak Yöneticisi kümedeki yükü nasıl yönettiğini ve dengeleyeceğinizi öğrenmek için, bkz. Service Fabric kümenizi Dengeleme.