Küme Kaynak Yöneticisi'ni kullanarak Service Fabric kümesini açıklama
Azure Service Fabric'in Küme Resource Manager özelliği, bir kümeyi açıklamaya yönelik çeşitli mekanizmalar sağlar:
- Hata etki alanları
- Etki alanlarını yükseltme
- Düğüm özellikleri
- Düğüm kapasiteleri
Çalışma zamanı sırasında Küme Resource Manager, kümede çalışan hizmetlerin yüksek kullanılabilirliğini sağlamak için bu bilgileri kullanır. Bu önemli kuralları uygularken, küme içindeki kaynak tüketimini iyileştirmeye de çalışır.
Hata etki alanları
Hata etki alanı, eşgüdümlü 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. Tek bir güç kaynağını veya tek bir konumda paylaşan makineler de öyledir.
Donanım hatalarının çakışması doğal olduğundan, hata etki alanları doğal olarak hiyerarşiktir. Bunlar Service Fabric'te URI'ler olarak temsil edilir.
Service Fabric hizmetleri güvenli bir şekilde yerleştirmek için bu bilgileri kullandığından hata etki alanlarının doğru ayarlanması önemlidir. Service Fabric, bir hata etki alanı kaybının (bazı bileşenlerin başarısız olması nedeniyle) bir hizmetin kapanmasına neden olacak hizmetleri yerleştirmek istemez.
Azure ortamında Service Fabric, kümedeki düğümleri sizin adınıza doğru yapılandırmak için ortam tarafından sağlanan hata etki alanı bilgilerini kullanır. Service Fabric'in tek başına örnekleri için hata etki alanları kümenin ayarlandığı sırada tanımlanır.
Uyarı
Service Fabric'e sağlanan hata etki alanı bilgilerinin doğru olması önemlidir. Örneğin, Service Fabric kümenizin düğümlerinin 5 fiziksel konakta çalışan 10 sanal makine içinde çalıştığını düşünelim. Bu durumda, 10 sanal makine olsa bile, yalnızca 5 farklı (üst düzey) hata etki alanı vardır. Aynı fiziksel konağın paylaşılması VM'lerin aynı kök hata etki alanını paylaşmasına neden olur, çünkü vm'ler fiziksel konakları başarısız olursa eşgüdümlü hatayla karşılaşır.
Service Fabric bir düğümün hata etki alanının değişmemesini bekler. HA-VM'ler gibi VM'lerin yüksek kullanılabilirliğini sağlamaya yönelik diğer mekanizmalar Service Fabric ile çakışmalara neden olabilir. Bu mekanizmalar VM'lerin bir konaktan diğerine saydam geçişini kullanır. Vm içinde çalışan kodu yeniden yapılandırmaz veya bildirmez. Bu nedenle, Service Fabric kümelerini çalıştırmak için ortam olarak desteklenmezler .
Service Fabric, kullanılan tek yüksek kullanılabilirlik teknolojisi olmalıdır. Canlı VM geçişi ve SAN'ler gibi mekanizmalar gerekli değildir. Bu mekanizmalar Service Fabric ile birlikte kullanılıyorsa, uygulama kullanılabilirliğini ve güvenilirliğini azaltır . Bunun nedeni, ek karmaşıklık sunmaları, merkezi hata kaynakları eklemeleri ve Service Fabric'tekilerle çakışan güvenilirlik ve kullanılabilirlik stratejilerini kullanmalarıdır.
Aşağıdaki grafikte, hata etki alanlarına katkıda bulunan tüm varlıkları renklendirecek ve sonuçta elde edilen tüm farklı hata etki alanlarını listeleyeceğiz. Bu örnekte veri merkezleri ("DC"), raflar ("R") ve dikey pencerelerimiz ("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ümesi Kaynak Yöneticisi, kümedeki hata etki alanlarını dikkate alır ve düzenleri planlar. Bir hizmetin durum bilgisi olan çoğaltmaları veya durum bilgisi olmayan örnekleri ayrı hata etki alanlarında olmaları için dağıtılır. Hizmetin hata etki alanları arasında dağıtılması, hiyerarşinin herhangi bir düzeyinde hata etki alanı başarısız olduğunda hizmetin kullanılabilirliğinin tehlikeye atılmasını sağlamaz.
Küme Resource Manager, hata etki alanı hiyerarşisinde kaç katman olduğuyla ilgilenmez. Hiyerarşinin herhangi bir bölümünün kaybının, içinde çalışan hizmetleri etkilemediğinden emin olmaya çalışır.
Hata etki alanı hiyerarşisindeki her derinlik düzeyinde aynı sayıda düğüm olması en iyisidir. Kümenizde hata etki alanlarının "ağacı" dengelenmemişse, Küme Resource Manager'ın en iyi hizmet ayırmayı belirlemesi daha zordur. Dengesiz hata etki alanı düzenleri, bazı etki alanlarının kaybının hizmetlerin kullanılabilirliğini diğer etki alanlarından daha fazla etkilediği anlamına gelir. Sonuç olarak, Küme Kaynak Yöneticisi iki hedef arasında ayrılır:
- Bu "ağır" etki alanındaki makineleri, üzerine hizmetler yerleştirerek kullanmak istiyor.
- Bir etki alanı kaybının sorunlara neden olmaması için hizmetleri diğer etki alanlarına yerleştirmek istiyor.
Dengesiz etki alanları nasıl görünür? Aşağıdaki diyagramda iki farklı küme düzeni gösterilmektedir. İ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, hangi hata etki alanının düğüm içerdiği sizin için yönetilir. Ancak sağladığınız düğüm sayısına bağlı olarak, yine de diğer düğümlerden daha fazla düğüm içeren hata etki alanlarıyla sonuçlanabilir.
Örneğin, kümede beş hata etki alanınız olduğunu ancak bir düğüm türü (NodeType) için yedi düğüm sağladığınızı varsayalım. 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 ederseniz sorun daha da kötüleşir. Bu nedenle, her düğüm türündeki düğüm sayısının hata etki alanı sayısının katı olması önerilir.
Etki alanlarını yükseltme
Yükseltme etki alanları, Service Fabric Kümesi Kaynak Yöneticisi'nin küme düzenini anlamasına yardımcı olan bir diğer özellik dedir. Yükseltme etki alanları, aynı anda yükseltilen düğüm kümelerini tanımlar. Yükseltme etki alanları, Küme Resource Manager'ın yükseltmeler gibi yönetim işlemlerini anlamasına ve düzenlemelerine yardımcı olur.
Yükseltme etki alanları hata etki alanlarına çok benzer, ancak birkaç önemli fark vardır. İlk olarak, eşgüdümlü donanım hatalarının alanları hata etki alanlarını tanımlar. Öte yandan yükseltme etki alanları ilke tarafından tanımlanır. Kaç kişi istediğinize, ortamın sayıyı dikte etmesine izin vermek yerine karar verirsiniz. Düğümler kadar yükseltme etki alanınız olabilir. Hata etki alanları ile yükseltme etki alanları arasındaki bir diğer fark, yükseltme etki alanlarının hiyerarşik olmamasıdır. Bunun yerine, bunlar daha çok basit bir etiket gibidir.
Aşağıdaki diyagramda üç hata etki alanı arasında şeritli üç yükseltme etki alanı gösterilmektedir. Ayrıca durum bilgisi olan bir hizmetin üç farklı çoğaltması için her birinin farklı hata ve yükseltme etki alanlarıyla sonuçlandığı bir olası yerleştirme gösterir. Bu yerleştirme, bir hizmet yükseltmesinin ortasındayken hata etki alanının kaybolmasına olanak tanır ve kodun ve verilerin bir kopyasına sahiptir.
Çok sayıda yükseltme etki alanı olmasının avantajları ve dezavantajları vardır. Daha fazla yükseltme etki alanı, yükseltmenin her 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 daha az hizmetin hareket ederek sisteme daha az değişim sıklığı eklemesi gerekir. Hizmetten daha azı yükseltme sırasında ortaya çıkan sorunlardan etkilendiğinden bu durum güvenilirliği artırma 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 gelir.
Örneğin, beş yükseltme etki alanınız varsa, her birindeki düğümler trafiğinizin yaklaşık yüzde 20'sini işler. Yükseltme için bu yükseltme etki alanını kapatmanız gerekiyorsa yükün genellikle bir yere gitmesi gerekir. Kalan dört yükseltme etki alanınız olduğundan, her birinin toplam trafiğin yaklaşık yüzde 25'i için yer olması gerekir. Daha fazla yükseltme etki alanı, kümedeki düğümlerde daha az arabelleğe ihtiyacınız olduğu anlamına gelir.
Bunun yerine 10 yükseltme etki alanınız olup olmadığını düşünün. Bu durumda, her yükseltme etki alanı toplam trafiğin yalnızca yüzde 10'unu işler. Kümede bir yükseltme adımı atıldığında, her etki alanının toplam trafiğin yalnızca yüzde 11'ine yer olması gerekir. Daha fazla yükseltme etki alanı genellikle daha az ayrılmış kapasiteye ihtiyacınız olduğundan düğümlerinizi daha yüksek kullanımda çalıştırmanıza olanak tanır. Aynı durum hata etki alanları için de geçerlidir.
Birçok yükseltme etki alanı olmasının dezavantajı, yükseltmelerin daha uzun sürme eğiliminde olmasıdır. Service Fabric, 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 işlemi devam etmeden önce yükseltme tarafından ortaya sürülen sorunların algılanması sağlar. Hatalı değişikliklerin bir kerede çok fazla hizmeti etkilemesini önlediğinden dengeleme kabul edilebilir.
Çok az yükseltme etki alanının varlığının birçok olumsuz yan etkisi vardır. Her yükseltme etki alanı devre dışı ve yükseltilirken, genel kapasitenizin büyük bir bölümü kullanılamaz. Örneğin, yalnızca üç yükseltme etki alanınız varsa, bir kerede genel hizmet veya küme kapasitenizin yaklaşık üçte birini indirmiş olursunuz. Kümenizin geri kalanında iş yükünü işlemek için yeterli kapasiteye ihtiyacınız olduğundan hizmetinizin bir kerede bu kadar çok kısmının kapanması istenmez. Bu arabelleğin korunması, normal işlem sırasında bu düğümlerin normalden daha az yüklendiği anlamına gelir. Bu, hizmetinizi çalıştırma maliyetini artırır.
Bir ortamdaki toplam hata veya yükseltme etki alanı sayısı ya da bunların nasıl çakıştığıyla ilgili kısıtlamalar için gerçek bir sınır yoktur. Ancak yaygın desenler vardır:
- Hata etki alanları ve yükseltme etki alanları eşlendi 1:1
- Düğüm başına bir yükseltme etki alanı (fiziksel veya sanal işletim sistemi örneği)
- Hata etki alanlarının ve yükseltme etki alanlarının genellikle köşegenlerde çalışan makineler içeren bir matris oluşturduğu "şeritli" veya "matris" modeli
Hangi düzenin seçileceğine ilişkin en iyi yanıt yoktur. Her birinin artıları ve dezavantajları vardır. Örneğin, 1FD:1UD modelini ayarlamak kolaydır. Düğüm modeli başına bir yükseltme etki alanı modeli, en çok insanların alışkın olduğu modele benzer. 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ükseltildiğine benzer.
En yaygın model, hata etki alanlarının ve yükseltme etki alanlarının bir tablo oluşturup düğümlerin çapraz boyunca yerleştirildiği FD/UD matrisidir. Bu, Azure'daki Service Fabric kümelerinde varsayılan olarak kullanılan modeldir. Birçok düğüme sahip kümeler için her şey yoğun matris deseni gibi görünür.
Dekont
Azure'da barındırılan Service Fabric kümeleri varsayılan stratejinin değiştirilmesini desteklemez. Bu özelleştirmeyi yalnızca tek başına kümeler sunar.
Hata ve yükseltme etki alanı kısıtlamaları ve sonuçta ortaya çıkan davranış
Varsayılan yaklaşım
Varsayılan olarak, Küme Resource Manager hizmetlerin hata ve yükseltme etki alanları arasında dengeli kalmasını sağlar. Bu, kısıtlama olarak modellenmiştir. Hata ve yükseltme etki alanları için kısıtlama şöyledir: "Belirli bir hizmet bölümü için, hiçbir zaman aynı hiyerarşi düzeyindeki iki etki alanı arasında hizmet nesneleri (durum bilgisi olmayan hizmet örnekleri veya durum bilgisi olan hizmet çoğaltmaları) sayısından büyük bir fark olmamalıdır."
Bu kısıtlamanın "maksimum fark" garantisi sağladığını varsayalım. Hata ve yükseltme etki alanları kısıtlaması, kuralı ihlal eden belirli taşımaları veya düzenlemeleri engeller.
Örneğin, beş hata etki alanı ve beş yükseltme etki alanıyla yapılandırılmış altı düğümlü bir kümemiz olduğunu varsayalım.
| FD0 | FD1 | FD2 | FD3 | FD4 | |
|---|---|---|---|---|---|
| UD0 | N1 | ||||
| UD1 | N6 | N2 | |||
| UD2 | N3 | ||||
| UD3 | N4 | ||||
| UD4 | N5 |
Şimdi targetReplicaSetSize (veya durum bilgisi olmayan bir hizmet için InstanceCount) değeri beş olan bir hizmet oluşturduğumuz düşünelim. Çoğaltmalar N1-N5 üzerine iner. Aslında N6, bunun gibi kaç hizmet oluşturursanız oluşturun hiçbir zaman kullanılmaz. Ama neden? Şimdi geçerli düzen ile N6 seçilirse ne olacağı arasındaki farka bakalım.
Aldığımız düzen ve hata ve yükseltme etki alanı başına toplam çoğaltma sayısı aşağıdadır:
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | R1 | 1 | ||||
| UD1 | R2 | 1 | ||||
| UD2 | R3 | 1 | ||||
| UD3 | R4 | 1 | ||||
| UD4 | R5 | 1 | ||||
| FDTotal | 1 | 1 | 1 | 1 | 1 | - |
Bu düzen, hata etki alanı başına düğümler ve yükseltme etki alanı açısından dengelenmiş durumdadır. Ayrıca hata ve yükseltme etki alanı başına çoğaltma sayısı açısından da dengelenmiş durumdadır. Her etki alanı aynı sayıda düğüme ve aynı sayıda çoğaltmaya sahiptir.
Şimdi N2 yerine N6 kullansaydık neler olacağına bakalım. O zaman çoğaltmalar nasıl dağıtılır?
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | R1 | 1 | ||||
| UD1 | R5 | 1 | ||||
| UD2 | R2 | 1 | ||||
| UD3 | R3 | 1 | ||||
| UD4 | R4 | 1 | ||||
| FDTotal | 2 | 0 | 1 | 1 | 1 | - |
Bu düzen, hata etki alanı kısıtlaması için "en fazla fark" garantisi tanımımızı ihlal eder. FD0 iki çoğaltmaya sahipken FD1'de sıfır vardır. FD0 ile FD1 arasındaki fark, toplam iki farktır ve bu da en fazla bir farktan büyüktür. Kısıtlama ihlal edildiğinden, Küme Resource Manager bu düzenlemeye izin vermez.
Benzer şekilde, N2 ve N6 'yı (N1 ve N2 yerine) seçersek şunları elde ederiz:
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | 0 | |||||
| UD1 | R5 | R1 | 2 | |||
| UD2 | R2 | 1 | ||||
| UD3 | R3 | 1 | ||||
| UD4 | R4 | 1 | ||||
| FDTotal | 1 | 1 | 1 | 1 | 1 | - |
Bu düzen hata etki alanları açısından dengelenmiş durumdadır. Ancak artık yükseltme etki alanı kısıtlamasını ihlal ediyor çünkü UD0'da sıfır çoğaltma ve UD1'de iki tane var. Bu düzen de geçersiz ve Küme Kaynak Yöneticisi tarafından seçilmeyecek.
Durum bilgisi olan çoğaltmaların veya durum bilgisi olmayan örneklerin dağıtımına yönelik bu yaklaşım, mümkün olan en iyi hataya dayanıklılık sağlar. Bir etki alanı kapanırsa, 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 vermeyebilir. Belirli küme yapılandırmaları için belirli düğümler kullanılamaz. Bu durum Service Fabric'in hizmetlerinizi yerleştirmemesine neden olarak uyarı iletilerine neden olabilir. Önceki örnekte, bazı küme düğümleri kullanılamaz (örnekte N6). Bu kümeye düğüm eklemiş olsanız bile (N7-N10), çoğaltmalar/örnekler hata ve yükseltme etki alanlarındaki kısıtlamalar nedeniyle yalnızca N1–N5'e yerleştirilir.
| FD0 | FD1 | FD2 | FD3 | FD4 | |
|---|---|---|---|---|---|
| UD0 | N1 | N10 | |||
| UD1 | N6 | N2 | |||
| UD2 | N7 | N3 | |||
| UD3 | N8 | N4 | |||
| UD4 | N9 | N5 |
Alternatif yaklaşım
Küme Resource Manager, hata ve yükseltme etki alanları için kısıtlamanın başka bir sürümünü destekler. Minimum güvenlik düzeyini garanti ederken yerleştirmeye izin verir. Alternatif kısıtlama şu şekilde belirtilebilir: "Belirli bir hizmet bölümü için etki alanları arasında çoğaltma dağıtımı, bölümün çekirdek kaybı yaşamamasını sağlamalıdır." Bu kısıtlamanın "çekirdek güvenli" garantisi sağladığını varsayalım.
Dekont
Durum bilgisi olan bir hizmet için bölüm çoğaltmalarının çoğunluğunun aynı anda kapanması durumunda çekirdek kaybı tanımlarız. Örneğin, TargetReplicaSetSize beş ise, üç çoğaltmadan oluşan bir küme çekirdeği temsil eder. Benzer şekilde TargetReplicaSetSize altıysa çekirdek için dört çoğaltma gerekir. Her iki durumda da, bölüm normal çalışmaya devam etmek istiyorsa ikiden fazla çoğaltma aynı anda kapatılamaz.
Durum bilgisi olmayan bir hizmet için çekirdek kaybı diye bir şey yoktur. Durum bilgisi olmayan hizmetler, örneklerin çoğunluğu aynı anda kapansa bile normal şekilde çalışmaya devam eder. Bu nedenle, bu makalenin geri kalanında durum bilgisi olan hizmetlere odaklanacağız.
Önceki örne geri dönelim. Kısıtlamanın "çekirdek güvenli" sürümüyle üç düzen de geçerli olacaktır. FD0 ikinci düzende başarısız olsa veya UD1 üçüncü düzende başarısız olsa bile, bölümün çekirdeği yine de olur. (Çoğaltmaların çoğu yine de çalışır durumda olur.) Kısıtlamanın bu sürümüyle, N6 neredeyse her zaman kullanılabilir.
"Çekirdek güvenli" yaklaşımı, "maksimum fark" yaklaşımından daha fazla esneklik sağlar. Bunun nedeni, neredeyse tüm küme topolojilerinde geçerli olan çoğaltma dağıtımlarını bulmanın daha kolay olmasıdır. Ancak, bazı hatalar diğerlerinden daha kötü olduğundan bu yaklaşım en iyi hataya dayanıklılık özelliklerini garantileyemez.
En kötü durumda, çoğaltmaların çoğu bir etki alanı ve bir ek çoğaltma hatasıyla kaybolabilir. Örneğin, beş çoğaltma veya örnekle çekirdek kaybı için gereken üç hata yerine, artık yalnızca iki hatayla çoğunluğu kaybedebilirsiniz.
Uyarlamalı yaklaşım
Her iki yaklaşımın da güçlü ve zayıf yönleri olduğundan, bu iki stratejiyi birleştiren uyarlamalı bir yaklaşım kullanıma sunulmuştur.
Dekont
Bu, Service Fabric sürüm 6.2 ile başlayan varsayılan davranıştır.
Uyarlamalı yaklaşım varsayılan olarak "maksimum fark" mantığını kullanır ve yalnızca gerektiğinde "çekirdek güvenli" mantığına geçer. Küme Resource Manager, kümenin ve hizmetlerin nasıl yapılandırıldığına bakarak hangi stratejinin gerekli olduğunu otomatik olarak anlar.
Küme Resource Manager, bir hizmet için "çekirdek tabanlı" mantığı kullanmalıdır. Bu koşulların her ikisi de doğrudur:
- Hizmet için TargetReplicaSetSize , hata etki alanı sayısına ve yükseltme etki alanı sayısına göre eşit olarak bölünür.
- Düğüm sayısı, yükseltme etki alanlarının sayısıyla çarpılan hata etki alanı sayısına eşit veya ondan küçüktür.
Çekirdek kaybı durum bilgisi olmayan hizmetlerle ilgili olmasa da Küme Resource Manager'ın hem durum bilgisi olmayan hem de durum bilgisi olan hizmetler için bu yaklaşımı kullanacağını unutmayın.
Önceki örne geri dönelim ve bir kümenin artık sekiz düğümü olduğunu varsayalım. Küme hala beş hata etki alanı ve beş yükseltme etki alanı ile yapılandırılmıştır ve bu kümede barındırılan bir hizmetin TargetReplicaSetSize değeri beş olarak kalır.
| FD0 | FD1 | FD2 | FD3 | FD4 | |
|---|---|---|---|---|---|
| UD0 | N1 | ||||
| UD1 | N6 | N2 | |||
| UD2 | N7 | N3 | |||
| UD3 | N8 | N4 | |||
| UD4 | N5 |
Gerekli tüm koşullar karşılandığından, Küme Kaynak Yöneticisi hizmeti dağıtırken "çekirdek tabanlı" mantığı kullanır. Bu, N6-N8 kullanımını etkinleştirir. Bu durumda olası bir hizmet dağıtımı aşağıdaki gibi görünebilir:
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | R1 | 1 | ||||
| UD1 | R2 | 1 | ||||
| UD2 | R3 | R4 | 2 | |||
| UD3 | 0 | |||||
| UD4 | R5 | 1 | ||||
| FDTotal | 2 | 1 | 1 | 0 | 1 | - |
Hizmetinizin TargetReplicaSetSize değeri dörde düşürülürse (örneğin), Küme Resource Manager bu değişikliği fark eder. TargetReplicaSetSize artık hata etki alanı ve yükseltme etki alanı sayısına bölünebileceğinden "en fazla fark" mantığını kullanmaya devam eder. Sonuç olarak, N1-N5 düğümlerinde kalan dört çoğaltmayı dağıtmak için belirli çoğaltma hareketleri gerçekleşir. Bu şekilde, hata etki alanı ve yükseltme etki alanı mantığının "en fazla fark" sürümü ihlal edilmez.
Önceki düzende TargetReplicaSetSize değeri beş ise ve N1 kümeden kaldırılırsa, yükseltme etki alanı sayısı dörte eşit olur. Yükseltme etki alanlarının sayısı artık hizmetin TargetReplicaSetSize değerini eşit olarak bölmediğinden, Küme Kaynak Yöneticisi "en fazla fark" mantığını kullanmaya başlar. Sonuç olarak, çoğaltma R1 yeniden derlendiğinde hata ve yükseltme etki alanı kısıtlamasının ihlal edilmemesi için N4'e inmesi gerekir.
| FD0 | FD1 | FD2 | FD3 | FD4 | UDTotal | |
|---|---|---|---|---|---|---|
| UD0 | Geçersiz | Yok | Yok | Yok | Yok | Geçersiz |
| UD1 | R2 | 1 | ||||
| UD2 | R3 | R4 | 2 | |||
| UD3 | R1 | 1 | ||||
| UD4 | R5 | 1 | ||||
| FDTotal | 1 | 1 | 1 | 1 | 1 | - |
Hata ve yükseltme etki alanlarını yapılandırma
Azure tarafından barındırılan Service Fabric dağıtımlarında 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 aşamasında belirli bir topolojiyi çalıştırmak istiyorsanız), hata etki alanı sağlayabilir ve etki alanı bilgilerini kendiniz yükseltebilirsiniz. Bu örnekte, üç veri merkezine (her biri üç raflı) yayılan dokuz düğümlü bir yerel geliştirme kümesi tanımlayacağız. Bu kümede ayrıca bu üç veri merkezinde şeritli üç yükseltme etki alanı vardır. Aşağıda ClusterManifest.xml dosyasındaki yapılandırmanın bir örneği verilmişti:
<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 tek başına dağıtımlar için ClusterConfig.json kullanılı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"
}
],
Dekont
Azure Resource Manager aracılığıyla küme tanımlarken, Azure hata etki alanları ve yükseltme etki alanları atar. Bu nedenle Azure Resource Manager şablonunuzdaki düğüm türlerinizin ve sanal makine ölçek kümelerinizin tanımı hata etki alanı veya yükseltme etki alanı hakkında bilgi içermez.
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 gerektirebilirken diğerleri gerekmeyebilir.
Donanımı belirli iş yüklerine hedeflemeye yönelik harika bir örnek, neredeyse her n katmanlı mimaridir. Belirli makineler uygulamanın ön ucu veya API'ye hizmet veren tarafı görevi görür ve istemcilere veya İnternet'e sunulur. Genellikle farklı donanım kaynaklarına sahip farklı makineler, işlem veya depolama katmanlarının çalışmasını işler. Bunlar genellikle istemcilere veya İnternet'e doğrudan açık değildir .
Service Fabric bazı durumlarda belirli iş yüklerinin belirli donanım yapılandırmalarında çalıştırılması gerekebileceğini bekler. Örneğin:
- Mevcut bir n katmanlı uygulama bir Service Fabric ortamına "kaldırıldı ve kaydırıldı".
- Performans, ölçek veya güvenlik yalıtımı nedeniyle iş yükü belirli bir donanımda çalıştırılmalıdır.
- İlke veya kaynak tüketimi nedeniyle bir iş yükü diğer iş yüklerinden yalıtılmalıdır.
Service Fabric, bu tür yapılandırmaları desteklemek için düğümlere uygulayabileceğiniz etiketler içerir. Bu etiketler düğüm özellikleri olarak adlandırılır. Yerleştirme kısıtlamaları , bir veya daha fazla düğüm özelliği için seçtiğiniz tek tek hizmetlere eklenen deyimlerdir. Yerleştirme kısıtlamaları, hizmetlerin nerede çalıştırılacağını tanımlar. Kısıtlamalar kümesi genişletilebilir. Herhangi bir anahtar/değer çifti çalışabilir.
Yerleşik düğüm özellikleri
Service Fabric, otomatik olarak kullanılabilecek bazı varsayılan düğüm özelliklerini tanımlar, bu nedenle bunları tanımlamanız gerekmez. Her düğümde tanımlanan varsayılan özellikler NodeType ve NodeName'tir.
Örneğin, bir yerleştirme kısıtlaması "(NodeType == NodeType03)"olarak yazabilirsiniz. NodeType yaygın olarak kullanılan bir özelliktir. Bir makine türüyle 1:1'e 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öz dizimi
Node özelliğinde belirtilen değer bir dize, Boole veya uzun imzalı olabilir. Hizmetteki deyimi, hizmetin kümede çalıştırılabildiği yeri kısıtladığı için yerleştirme kısıtlaması olarak adlandırılır. Kısıtlama, kümedeki düğüm özellikleri üzerinde çalışan herhangi bir Boole deyimi olabilir. Bu Boole deyimlerindeki geçerli seçiciler şunlardır:
Belirli deyimleri oluşturmak için koşullu denetimler:
Deyim Sözdizimi "eşittir" "==" "eşit değil" "!=" "büyüktür" ">" "büyüktür veya eşittir" ">=" "küçüktür" "<" "küçüktür veya eşittir" "<=" Gruplandırma ve mantıksal işlemler için Boole deyimleri:
Deyim Sözdizimi "ve" "&&" "veya" "||" "not" "!" "group as single deyimi" "()"
Temel kısıtlama deyimlerine bazı örnekler aşağıda verilmiştir:
"Value >= 5""NodeColor != green""((OneProperty < 100) || ((AnotherProperty == false) && (OneProperty >= 100)))"
Yalnızca genel yerleştirme kısıtlama deyiminin "True" olarak değerlendirildiği düğümler, hizmetin üzerine yerleştirilmesini sağlayabilir. Tanımlanmış bir özelliği olmayan düğümler, özelliği içeren hiçbir yerleştirme kısıtlaması ile eşleşmiyor.
ClusterManifest.xml dosyasındaki bir düğüm türü için aşağıdaki düğüm özelliklerinin tanımlandığını düşünelim:
<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, tek başına dağıtımlar için ClusterConfig.json veya Azure tarafından barındırılan kümeler için Template.json aracılığıyla tanımlanan düğüm özelliklerini gösterir.
Dekont
Azure Resource Manager şablonunuzda düğüm türü genellikle parametreli hale getirilir. NodeType01 yerine gibi "[parameters('vmNodeType1Name')]" görünür.
"nodeTypes": [
{
"name": "NodeType01",
"placementProperties": {
"HasSSD": "true",
"NodeColor": "green",
"SomeProperty": "5"
},
}
],
Bir hizmet için aşağıdaki gibi hizmet yerleştirme kısıtlamaları 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"
NodeType01'in tüm düğümleri geçerliyse, kısıtlamasıyla "(NodeType == NodeType01)"bu düğüm türünü de seçebilirsiniz.
Bir hizmetin yerleştirme kısıtlamaları çalışma zamanı sırasında dinamik olarak güncelleştirilebilir. Gerekirse, bir hizmeti küme içinde taşıyabilir, gereksinimleri ekleyip kaldırabilirsiniz. Service Fabric, bu tür değişiklikler yapıldığında bile hizmetin çalışır durumda kalmasını ve kullanılabilir 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"
Her adlandırılmış hizmet örneği için yerleştirme kısıtlamaları belirtilir. Güncelleştirmeler her zaman daha önce belirtilenlerin yerine geçin (üzerine yazın).
Küme tanımı bir düğümdeki özellikleri tanımlar. Bir düğümün özelliklerini değiştirmek için küme yapılandırmasına yükseltme 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 düzenleyicinin en önemli işlerinden biri, kümedeki kaynak tüketimini yönetmeye yardımcı olmaktır. Küme kaynaklarını yönetmek birkaç farklı anlama gelebilir.
İlk olarak, makinelerin aşırı yüklenmediğinden emin olunması gerekir. Bu, makinelerin işleyebileceğinden daha fazla hizmet çalıştırmadığından emin olmak anlamına gelir.
İkinci olarak, hizmetleri verimli bir şekilde çalıştırmak için kritik öneme sahip olan dengeleme ve iyileştirme vardır. Uygun maliyetli veya performansa duyarlı hizmet teklifleri, bazı düğümler soğukken bazı düğümlerin sık erişimli olmasını sağlayamaz. Sık erişimli düğümler kaynak çekişmesine ve düşük performansa yol açar. Soğuk düğümler boşa harcanan kaynakları ve artan maliyetleri temsil eder.
Service Fabric, kaynakları ölçüm olarak temsil eder. Ölçümler, Service Fabric'e açıklamak istediğiniz herhangi bir mantıksal veya fiziksel kaynaktır. Ölçümlere örnek olarak "WorkQueueDepth" veya "MemoryInMb" verilebilir. Service Fabric'in düğümlerde yönetebileceği fiziksel kaynaklar hakkında bilgi için bkz . Kaynak idaresi. Küme Resource Manager tarafından kullanılan varsayılan ölçümler ve özel ölçümleri 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 bir düğümde çalıştırıldığında bu hizmetlerin tükettiği kaynakları açıklar. Düğüm özelliği HasSSD olabilir ve true veya false olarak ayarlanabilir. Bu SSD'de kullanılabilir alan miktarı ve hizmetler tarafından ne kadar alanın tüketilmesi "DriveSpaceInMb" gibi bir ölçüm olabilir.
Yerleştirme kısıtlamaları ve düğüm özelliklerinde olduğu gibi Service Fabric Kümesi Resource Manager da ölçümlerin adlarının ne anlama gelenlerini anlamaz. Ölçüm adları yalnızca dizelerdir. Belirsiz olabilecek durumlarda birimleri oluşturduğunuz ölçüm adlarının bir parçası olarak bildirmek iyi bir uygulamadır.
Kapasite
Tüm kaynak dengelemeyi kapattıysanız Service Fabric Kümesi Kaynak Yöneticisi yine de hiçbir düğümün kapasitesini aşmadığından emin olur. Küme çok dolu değilse veya iş yükü herhangi bir düğümden büyük değilse kapasite taşmalarını yönetmek mümkündür. Kapasite, Küme Kaynak Yöneticisi'nin bir düğümün ne kadar kaynağı olduğunu anlamak için kullandığı bir diğer kısıtlamadır . Kümenin tamamı için kalan kapasite de izlenir.
Hem kapasite hem de hizmet düzeyindeki tüketim, ölçümler açısından ifade edilir. Örneğin, ölçüm "İstemci Bağlan ions" olabilir ve bir düğümün "İstemci Bağlan ions" kapasitesi 32.768 olabilir. Diğer düğümlerin başka sınırları olabilir. Bu düğümde çalışan bir hizmet şu anda "İstemci Bağlan ions" ölçümünün 32.256'sını tüketiyor olduğunu söyleyebilir.
Küme Resource Manager, çalışma zamanı sırasında kümedeki ve düğümlerdeki kalan kapasiteyi izler. Küme Resource Manager, kapasiteyi izlemek için her hizmetin kullanımını hizmetin çalıştığı düğümün kapasitesinden çıkarır. Bu bilgilerle Küme Resource Manager, düğümlerin kapasiteyi aşmaması için çoğaltmaların nereye yerleştirileceği veya taşınacağı konusunda bilgi edinebilir.
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. Aşağıda ClusterManifest.xml için bir örnek verilmişti:
<NodeType Name="NodeType03">
<Capacities>
<Capacity Name="ClientConnections" Value="65536"/>
</Capacities>
</NodeType>
Aşağıda tek başına dağıtımlar için ClusterConfig.json veya Azure tarafından barındırılan kümeler için Template.json aracılığıyla tanımlanan kapasitelerin bir örneği verilmiştir:
"nodeTypes": [
{
"name": "NodeType03",
"capacities": {
"ClientConnections": "65536",
}
}
],
Bir hizmetin yükü genellikle dinamik olarak değişir. Bir çoğaltmanın "İstemci Bağlan ions" yükünün 1.024'ten 2.048'e değiştiğini söyleyin. Üzerinde çalıştığı düğümün bu ölçüm için yalnızca 512 kapasitesi kalmıştır. Artık çoğaltma veya örneğin yerleşimi geçersiz çünkü bu düğümde yeterli alan yok. Küme Resource Manager'ın düğümü kapasitenin altına geri alması gerekir. Bir veya daha fazla çoğaltmayı veya örneği bu düğümden diğer düğümlere taşıyarak kapasitenin üzerindeki düğüm üzerindeki yükü azaltır.
Küme Resource Manager, çoğaltmaları taşıma maliyetini en aza indirmeye çalışır. Hareket maliyeti ve yeniden dengeleme stratejileri ve kuralları hakkında daha fazla bilgi edinebilirsiniz.
Küme kapasitesi
Service Fabric Kümesi Resource Manager, genel kümenin çok dolu olmasına nasıl engel olur? Dinamik yük ile yapabilecek çok fazla şey yoktur. Hizmetler, Küme Resource Manager'ın gerçekleştirdikleri eylemlerden bağımsız olarak yük artışına sahip olabilir. Sonuç olarak, yarın ani bir artış olursa, bugün yeterli sayıda odası olan kümeniz yetersiz güçte olabilir.
Küme Resource Manager'daki denetimler sorunları önlemeye yardımcı olur. Yapabileceğiniz ilk şey, kümenin dolmasına neden olacak yeni iş yüklerinin oluşturulmasını engellemektir.
Durum bilgisi olmayan bir hizmet oluşturduğunuzu ve onunla ilişkilendirilmiş bazı yükleri olduğunu varsayalım. Hizmet "DiskSpaceInMb" ölçümünü önemser. Hizmet, hizmetin her örneği için beş birim "DiskSpaceInMb" tüketir. Hizmetin üç örneğini oluşturmak istiyorsunuz. Bu, bu hizmet örneklerini oluşturabilmeniz için kümede 15 birim "DiskSpaceInMb" bulunması gerektiği anlamına gelir.
Küme Resource Manager, kümedeki kalan kapasiteyi belirleyebilmesi için her ölçümün kapasitesini ve tüketimini sürekli olarak hesaplar. Yeterli alan yoksa, Küme Kaynak Yöneticisi hizmet oluşturma çağrısını reddeder.
Gereksinim yalnızca 15 birimin kullanılabilir olması olduğundan, bu alanı birçok farklı yolla ayırabilirsiniz. Örneğin, 15 farklı düğümde kalan bir kapasite birimi veya beş farklı düğümde kalan üç kapasite birimi olabilir. Küme Kaynak Yöneticisi üç düğümde beş birim olacak şekilde öğeleri yeniden düzenleyebilirse hizmeti yerleştirir. Küme dolmadığı veya mevcut hizmetler bir nedenle birleştirilmediği sürece kümeyi yeniden düzenlemek genellikle mümkündür.
Düğüm arabelleği ve overbooking kapasitesi
Bir ölçüm için düğüm kapasitesi belirtilirse, toplam yük belirtilen düğüm kapasitesinin üzerine çıkacaksa Küme Kaynak Yöneticisi çoğaltmaları hiçbir zaman bir düğüme yerleştirmez veya taşımaz. Küme tam kapasiteye yakınsa ve büyük yüke sahip bir çoğaltmanın yerleştirilmesi, değiştirilmesi veya taşınması gerekiyorsa, bu durum bazen yeni çoğaltmaların yerleştirilmesini veya başarısız çoğaltmaların değiştirilmesini engelleyebilir.
Daha fazla esneklik sağlamak için düğüm arabelleği veya fazla rezervasyon kapasitesi belirtebilirsiniz. Bir ölçüm için düğüm arabelleği veya overbooking kapasitesi belirtildiğinde, Küme Kaynak Yöneticisi çoğaltmaları arabellek veya fazla rezervasyon kapasitesinin kullanılmamış olarak kalmasını sağlayacak şekilde yerleştirmeye veya taşımaya çalışır, ancak aşağıdakiler gibi hizmet kullanılabilirliğini artıran eylemler için gerekirse arabellek veya fazla rezervasyon kapasitesinin kullanılmasına izin verir:
- Yeni çoğaltma yerleştirme veya başarısız çoğaltmaları değiştirme
- Yükseltmeler sırasında yerleştirme
- Yumuşak ve sert kısıtlama ihlallerinin düzeltilmesi
- Birleştirme
Düğüm arabellek kapasitesi, kapasitenin belirtilen düğüm kapasitesinin altındaki ayrılmış bir bölümünü, fazla rezervasyon kapasitesi ise belirtilen düğüm kapasitesinin üzerindeki fazladan kapasitenin bir bölümünü temsil eder. Her iki durumda da Küme Resource Manager bu kapasiteyi boş tutmaya çalışır.
Örneğin, bir düğümün CpuUtilization 100 ölçümü için belirtilen kapasitesi varsa ve bu ölçümün düğüm arabellek yüzdesi %20 olarak ayarlandıysa, toplam ve kaldırılan kapasiteler sırasıyla 100 ve 80 olur ve Normal durumlarda Küme Kaynak Yöneticisi düğüme 80 birimden fazla yük yerleştirmez.
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ı ayırmak istediğinizde kullanılmalıdır.
Öte yandan düğüm overbooking yüzdesi kullanılır ve %20 olarak ayarlanırsa toplam ve genişletilmemiş kapasiteler sırasıyla 120 ve 100 olur.
Küme Resource Manager'ın toplam kaynak kullanımı kapasiteyi aşsa bile çoğaltmaları bir düğüme yerleştirmesine izin vermek istediğinizde overbooking kapasitesi kullanılmalıdır. Bu, performans pahasına hizmetler için ek kullanılabilirlik sağlamak için kullanılabilir. Overbooking kullanılıyorsa, kullanıcı uygulaması mantığının gerektirebileceğinden daha az fiziksel kaynakla çalışabilmesi gerekir.
Düğüm arabelleği veya overbooking kapasiteleri belirtilirse, hedef düğümdeki toplam yük toplam kapasitenin üzerine çıkacaksa Küme Kaynak Yöneticisi çoğaltmaları taşımaz veya yerleştirmez (düğüm arabelleği ve düğüm kapasitesi için düğüm kapasitesi + fazla rezervasyon durumunda fazla rezervasyon kapasitesi).
Fazla rezervasyon kapasitesi de sonsuz olarak belirtilebilir. Bu durumda, Küme Kaynak Yöneticisi düğümdeki toplam yükü belirtilen düğüm kapasitesinin altında tutmaya çalışır, ancak düğümde ciddi performans düşüşlerine yol açabilecek çok daha büyük bir yük yerleştirmesine izin verilir.
Bir ölçüm için aynı anda hem düğüm arabelleği hem de fazla rezervasyon kapasitesi belirtilemez.
Aşağıda ClusterManifest.xml dosyasında düğüm arabelleği veya overbooking kapasitelerinin nasıl belirtileceğini gösteren bir örnek verilmişti:
<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>
Aşağıda tek başına dağıtımlar için ClusterConfig.json veya Azure tarafından barındırılan kümeler için Template.json aracılığıyla düğüm arabelleği veya overbooking kapasitelerinin nasıl belirtileceğini gösteren bir örnek 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 Resource Manager içindeki mimari ve bilgi akışı hakkında bilgi için bkz . Küme Resource Manager mimarisine genel bakış.
- Birleştirme ölçümlerini tanımlamak, yükü dağıtmak yerine düğümlerde birleştirmenin bir yoludur. Birleştirmeyi yapılandırmayı öğrenmek için bkz . Service Fabric'te ölçümleri birleştirme ve yükleme.
- Baştan başlayın ve Service Fabric Kümesi Kaynak Yöneticisi'ne giriş bilgileri edinin.
- Küme Resource Manager'ın kümedeki yükü nasıl yönettiğini ve dengelediğini öğrenmek için bkz . Service Fabric kümenizi dengeleme.