Aracılığıyla paylaş

Ölçümlerle Service Fabric'te kaynak tüketimini ve yükünü yönetme

  • Makale

Ölçümler , hizmetlerinizin önem verdiği ve kümedeki düğümler tarafından sağlanan kaynaklardır. Ölçüm, hizmetlerinizin performansını geliştirmek veya izlemek için yönetmek istediğiniz her şeydir. Örneğin, hizmetinizin aşırı yüklenip yüklenmediğini öğrenmek için bellek tüketimini izleyebilirsiniz. Başka bir kullanım, hizmetin daha iyi performans elde etmek için belleğin daha az kısıtlandığı başka bir yere taşınıp taşınamayacağını anlamaktır.

Bellek, Disk ve CPU kullanımı gibi öğeler ölçümlere örnek olarak verilebilir. Bu ölçümler, yönetilen düğümdeki fiziksel kaynaklara karşılık gelen fiziksel ölçümlerdir. Ölçümler mantıksal ölçümler de (ve genellikle bunlardır) olabilir. Mantıksal ölçümler "MyWorkQueueDepth" veya "MessagesToProcess" veya "TotalRecords" gibi öğelerdir. Mantıksal ölçümler uygulama tanımlıdır ve dolaylı olarak bazı fiziksel kaynak tüketimine karşılık gelir. Mantıksal ölçümler yaygın olarak görülür çünkü fiziksel kaynakların tüketimini her hizmet temelinde ölçmek ve raporlamak zor olabilir. Kendi fiziksel ölçümlerinizi ölçmenin ve raporlamanın karmaşıklığı, Service Fabric'in bazı varsayılan ölçümleri sağlamasının da nedenidir.

Varsayılan ölçümler

Hizmetinizi yazmaya ve dağıtmaya başlamak istediğinizi varsayalım. Bu noktada, hangi fiziksel veya mantıksal kaynakları tükettiği hakkında bilginiz yoktur. Sorun değil! Service Fabric Kümesi Resource Manager başka ölçüm belirtilmediğinde bazı varsayılan ölçümleri kullanır. Bunlar:

  • PrimaryCount - düğümdeki Birincil çoğaltmaların sayısı
  • ReplicaCount - düğümdeki durum bilgisi olan toplam çoğaltma sayısı
  • Count - düğümdeki tüm hizmet nesnelerinin (durum bilgisi olmayan ve durum bilgisi olan) sayısı
Ölçüm Durum Bilgisi Olmayan Örnek Yükü Durum Bilgisi Olan İkincil Yük Durum Bilgisi Olan Birincil Yük Ağırlık
PrimaryCount 0 0 1 Yüksek
ReplicaCount 0 1 1 Orta
Count 1 1 1 Düşük

Temel iş yükleri için varsayılan ölçümler, kümedeki çalışmanın düzgün bir dağıtımını sağlar. Aşağıdaki örnekte, iki hizmet oluşturduğumuz ve dengeleme için varsayılan ölçümlere güvendiğimizde ne olacağını görelim. İlk hizmet, üç bölümü ve hedef çoğaltma kümesi boyutu üç olan durum bilgisi olan bir hizmettir. İkinci hizmet, bir bölümü ve üç örnek sayısı olan durum bilgisi olmayan bir hizmettir.

Elde edeceğiniz sonuç şu:

Varsayılan Ölçümlerle Küme Düzeni

Dikkat edilecek bazı noktalar:

  • Durum bilgisi olan hizmet için birincil çoğaltmalar birkaç düğüme dağıtılır
  • Aynı bölüm için çoğaltmalar farklı düğümlerdedir
  • Kümede birincil ve ikincillerin toplam sayısı dağıtılır
  • Her düğümde eşit olarak ayrılan toplam hizmet nesnesi sayısı

Iyi!

Varsayılan ölçümler başlangıç olarak harika çalışır. Ancak varsayılan ölçümler sizi yalnızca şu ana kadar taşıyacaktır. Örneğin: Seçtiğiniz bölümleme düzeninin tüm bölümler tarafından mükemmel bir şekilde hatta kullanıma neden olma olasılığı nedir? Belirli bir hizmetin yükünün zaman içinde sabit olma olasılığı nedir, hatta şu anda birden çok bölümde aynı olabilir mi?

Yalnızca varsayılan ölçümlerle çalıştırabilirsiniz. Ancak bunu yapmak genellikle küme kullanımınızın istediğinizden daha düşük ve daha eşit olmadığı anlamına gelir. Bunun nedeni varsayılan ölçümlerin uyarlamalı olmadığından ve her şeyin eşdeğer olduğunu varsaydığındandır. Örneğin, meşgul olan ve her ikisi de PrimaryCount ölçümüne "1" katkıda bulunmayan bir Birincil. En kötü durumda, yalnızca varsayılan ölçümlerin kullanılması da fazla zamanlanmış düğümlerin performans sorunlarına neden olmasıyla sonuçlanabilir. Kümenizden en iyi şekilde yararlanmak ve performans sorunlarından kaçınmak istiyorsanız özel ölçümleri ve dinamik yük raporlamayı kullanmanız gerekir.

Özel ölçümler

Ölçümler, hizmeti oluştururken adlandırılmış hizmet örneği temelinde yapılandırılır.

Herhangi bir ölçümün bunu açıklayan bazı özellikleri vardır: ad, ağırlık ve varsayılan yük.

  • Ölçüm Adı: Ölçümün adı. Ölçüm adı, Resource Manager perspektifinden küme içindeki ölçüm için benzersiz bir tanımlayıcıdır.

Not

Özel ölçüm Adı, tanımlanmamış davranışa yol açabileceği için sistem ölçüm adlarından herhangi biri (servicefabric:/_CpuCores veya servicefabric:/_MemoryInMB) olmamalıdır. Service Fabric sürüm 9.1'den başlayarak, bu özel ölçüm adlarına sahip mevcut hizmetler için ölçüm adının yanlış olduğunu belirten bir sistem durumu uyarısı verilir.

  • Ağırlık: Ölçüm ağırlığı, bu ölçümün bu hizmet için diğer ölçümlere göre ne kadar önemli olduğunu tanımlar.
  • Varsayılan Yük: Varsayılan yük, hizmetin durum bilgisi olmayan veya durum bilgisi olan hizmetlere bağlı olarak farklı şekilde temsil edilir.
    • Durum bilgisi olmayan hizmetler için her ölçümün DefaultLoad adlı tek bir özelliği vardır
    • Durum bilgisi olan hizmetler için tanımladığınız:
      • PrimaryDefaultLoad: Bu hizmetin Birincil olduğunda tükettiği varsayılan ölçüm miktarı
      • SecondaryDefaultLoad: Bu hizmetin İkincil olduğunda tükettiği varsayılan ölçüm miktarı

Not

Özel ölçümler tanımlıyorsanız ve varsayılan ölçümleri de kullanmak istiyorsanız, varsayılan ölçümleri açıkça geri eklemeniz ve bunlar için ağırlıkları ve değerleri tanımlamanız gerekir. Bunun nedeni, varsayılan ölçümlerle özel ölçümleriniz arasındaki ilişkiyi tanımlamanız gerekir. Örneğin, ConnectionCount veya WorkQueueDepth'i Birincil dağıtımdan daha fazla önemsiyor olabilirsiniz. Varsayılan olarak PrimaryCount ölçümünün ağırlığı Yüksek'tir, bu nedenle öncelikli olduklarından emin olmak için diğer ölçümlerinizi eklerken bunu Orta olarak azaltmak istersiniz.

Hizmetiniz için ölçüm tanımlama - örnek

Aşağıdaki yapılandırmayı istediğinizi varsayalım:

  • Hizmetiniz "ConnectionCount" adlı bir ölçüm bildirir
  • Varsayılan ölçümleri de kullanmak istiyorsunuz
  • Bazı ölçümler yaptınız ve normalde bu hizmetin Birincil çoğaltmasının 20 birim "ConnectionCount" aldığını biliyorsunuz
  • İkinciller 5 birim "ConnectionCount" kullanır
  • Bu hizmetin performansını yönetme açısından en önemli ölçümün "ConnectionCount" olduğunu biliyorsunuz
  • Yine de Birincil çoğaltmaların dengelenmiş olmasını istiyorsunuz. Birincil çoğaltmaları dengelemek genellikle ne olursa olsun iyi bir fikirdir. Bu, bazı düğüm veya hata etki alanının kaybının birincil çoğaltmaların çoğunu da etkilemesini önlemeye yardımcı olur.
  • Aksi takdirde, varsayılan ölçümler normaldir

Bu ölçüm yapılandırmasına sahip bir hizmet oluşturmak için yazacağınız kod aşağıdadır:

Kod:

StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
StatefulServiceLoadMetricDescription connectionMetric = new StatefulServiceLoadMetricDescription();
connectionMetric.Name = "ConnectionCount";
connectionMetric.PrimaryDefaultLoad = 20;
connectionMetric.SecondaryDefaultLoad = 5;
connectionMetric.Weight = ServiceLoadMetricWeight.High;

StatefulServiceLoadMetricDescription primaryCountMetric = new StatefulServiceLoadMetricDescription();
primaryCountMetric.Name = "PrimaryCount";
primaryCountMetric.PrimaryDefaultLoad = 1;
primaryCountMetric.SecondaryDefaultLoad = 0;
primaryCountMetric.Weight = ServiceLoadMetricWeight.Medium;

StatefulServiceLoadMetricDescription replicaCountMetric = new StatefulServiceLoadMetricDescription();
replicaCountMetric.Name = "ReplicaCount";
replicaCountMetric.PrimaryDefaultLoad = 1;
replicaCountMetric.SecondaryDefaultLoad = 1;
replicaCountMetric.Weight = ServiceLoadMetricWeight.Low;

StatefulServiceLoadMetricDescription totalCountMetric = new StatefulServiceLoadMetricDescription();
totalCountMetric.Name = "Count";
totalCountMetric.PrimaryDefaultLoad = 1;
totalCountMetric.SecondaryDefaultLoad = 1;
totalCountMetric.Weight = ServiceLoadMetricWeight.Low;

serviceDescription.Metrics.Add(connectionMetric);
serviceDescription.Metrics.Add(primaryCountMetric);
serviceDescription.Metrics.Add(replicaCountMetric);
serviceDescription.Metrics.Add(totalCountMetric);

await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ConnectionCount,High,20,5”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

Not

Yukarıdaki örnekler ve bu belgenin geri kalanında ölçümlerin adlandırılmış hizmet temelinde yönetilmesi açıklanmaktadır. Hizmetleriniz için hizmet türü düzeyinde ölçümler tanımlamak da mümkündür. Bu, bunları hizmet bildirimlerinizde belirterek gerçekleştirilir. Tür düzeyi ölçümlerin tanımlanması birkaç nedenden dolayı önerilmez. İlk neden, ölçüm adlarının sıklıkla ortama özgü olmasıdır. Kesin bir sözleşme olmadığı sürece, bir ortamdaki "Çekirdekler" ölçümlerinin diğer ortamlarda "MiliCores" veya "CoReS" olmadığından emin olamazsınız. Ölçümleriniz bildiriminizde tanımlanıyorsa ortam başına yeni bildirimler oluşturmanız gerekir. Bu genellikle farklı bildirimlerin yalnızca küçük farklılıklarla çoğalmasına yol açar ve bu da yönetim güçlüklerine yol açabilir.

Ölçüm yükleri genellikle adlandırılmış hizmet örneği başına atanır. Örneğin, CustomerA için hizmetin yalnızca az kullanmayı planlayan bir örneğini oluşturduğunuzu varsayalım. Daha büyük bir iş yüküne sahip CustomerB için başka bir tane oluşturduğunuzu da varsayalım. Bu durumda, bu hizmetler için varsayılan yükleri değiştirmek isteyebilirsiniz. Bildirimler aracılığıyla tanımlanan ölçümleriniz ve yükleriniz varsa ve bu senaryoyu desteklemek istiyorsanız, her müşteri için farklı uygulama ve hizmet türleri gerekir. Hizmet oluşturma zamanında tanımlanan değerler bildirimde tanımlanan değerleri geçersiz kılar, böylece bunu kullanarak belirli varsayılanları ayarlayabilirsiniz. Ancak, bunu yapmak bildirimlerde bildirilen değerlerin hizmetin gerçekte çalıştığı değerlerle eşleşmesine neden olur. Bu, kafa karışıklığına neden olabilir.

Anımsatıcı olarak: Yalnızca varsayılan ölçümleri kullanmak istiyorsanız ölçüm koleksiyonuna dokunmanız veya hizmetinizi oluştururken özel bir şey yapmanız gerekmez. Varsayılan ölçümler, başka hiçbir ölçüm tanımlanmadığında otomatik olarak kullanılır.

Şimdi bu ayarların her birini daha ayrıntılı bir şekilde inceleyelim ve etkilediği davranışlardan bahsedelim.

Yükleme

Ölçümleri tanımlamanın tüm noktası, bazı yükleri temsil etmektir. Yük , belirli bir ölçümün belirli bir düğümdeki bir hizmet örneği veya çoğaltma tarafından ne kadarının tüketildiğinden kaynaklanır. Yükleme hemen her noktada yapılandırılabilir. Örnek:

  • Yük, bir hizmet oluşturulduğunda tanımlanabilir. Bu tür bir yük yapılandırması varsayılan yük olarak adlandırılır.
  • Bir hizmetin varsayılan yüklemeleri de dahil olmak üzere ölçüm bilgileri, hizmet oluşturulduktan sonra güncelleştirilebilir. Bu ölçüm güncelleştirmesi bir hizmet güncelleştirilerek gerçekleştirilir.
  • Belirli bir bölümün yükleri bu hizmetin varsayılan değerlerine sıfırlanabilir. Bu ölçüm güncelleştirmesi bölüm yükünü sıfırlama olarak adlandırılır.
  • Yük, çalışma zamanı sırasında dinamik olarak hizmet nesnesi temelinde bildirilebilir. Bu ölçüm güncelleştirmesi raporlama yükü olarak adlandırılır.
  • Bölümün çoğaltmaları veya örnekleri için yükleme, bir Yapı API'si çağrısı aracılığıyla yük değerleri bildirilerek de güncelleştirilebilir. Bu ölçüm güncelleştirmesi , bir bölüm için raporlama yükü olarak adlandırılır.

Bu stratejilerin tümü, kullanım ömrü boyunca aynı hizmet içinde kullanılabilir.

Varsayılan yükleme

Varsayılan yük , bu hizmetin her hizmet nesnesinin (durum bilgisi olmayan örnek veya durum bilgisi olan çoğaltma) ölçümün ne kadarını tükettiğidir. Küme Resource Manager, dinamik yük raporu gibi diğer bilgileri alıncaya kadar hizmet nesnesinin yükü için bu sayıyı kullanır. Daha basit hizmetler için varsayılan yük statik bir tanımdır. Varsayılan yük hiçbir zaman güncelleştirilmez ve hizmetin ömrü boyunca kullanılır. Varsayılan yükler, belirli miktarda kaynağın farklı iş yüklerine ayrılmış olduğu ve değişmediği basit kapasite planlama senaryolarında harika çalışır.

Not

Kümenizdeki düğümler için kapasite yönetimi ve kapasite tanımlama hakkında daha fazla bilgi için lütfen bu makaleye bakın.

Küme Resource Manager durum bilgisi olan hizmetlerin Birincilleri ve İkincilleri için farklı bir varsayılan yük belirtmesine olanak tanır. Durum bilgisi olmayan hizmetler, tüm örnekler için geçerli olan yalnızca bir değer belirtebilir. Durum bilgisi olan hizmetler için, birincil ve ikincil çoğaltmalar için varsayılan yük genellikle farklıdır çünkü çoğaltmalar her rolde farklı türde işler yapar. Örneğin, Birincil değerler genellikle hem okuma hem de yazma işlemlerine hizmet eder ve hesaplama yükünün çoğunu yönetirken ikinciller bunu yapmaz. Birincil çoğaltma için varsayılan yük genellikle ikincil çoğaltmalar için varsayılan yükten daha yüksektir. Gerçek sayılar kendi ölçülerinize bağlı olmalıdır.

Dinamik yük

Hizmetinizi bir süredir çalıştırdığınızı varsayalım. Bazı izlemelerle şunları fark ettiniz:

  1. Belirli bir hizmetin bazı bölümleri veya örnekleri diğerlerinden daha fazla kaynak tüketir
  2. Bazı hizmetlerin zaman içinde değişen yükü vardır.

Bu tür yük dalgalanmalarına neden olabilecek birçok şey vardır. Örneğin, farklı gereksinimlere sahip farklı müşterilerle farklı hizmetler veya bölümler ilişkilendirilir. Hizmetin yaptığı iş miktarı gün içinde değiştiğinden yük de değişebilir. Nedeni ne olursa olsun, genellikle varsayılan olarak kullanabileceğiniz tek bir sayı yoktur. Kümeden en fazla kullanımı elde etmek istiyorsanız bu durum özellikle geçerlidir. Varsayılan yük için seçtiğiniz herhangi bir değer zaman zaman yanlıştır. Yanlış varsayılan yüklemeler Küme Resource Manager kaynak ayırmanın üzerinde veya altında sonuçlanır. Sonuç olarak, Küme Resource Manager kümenin dengeli olduğunu düşünmesine rağmen fazla veya kullanımda olan düğümleriniz vardır. İlk yerleştirme için bazı bilgiler sağladığından varsayılan yükler hala iyidir, ancak gerçek iş yükleri için tam bir hikaye değildir. Küme Resource Manager, değişen kaynak gereksinimlerini doğru bir şekilde yakalamak için her hizmet nesnesinin çalışma zamanı sırasında kendi yükünü güncelleştirmesine izin verir. Buna dinamik yük raporlama denir.

Dinamik yük raporları, çoğaltmaların veya örneklerin ölçümlerin kullanım ömrü boyunca ayırma/bildirilen yükünü ayarlamasına olanak tanır. Soğuk olan ve hiçbir iş yapmayan bir hizmet çoğaltması veya örneği genellikle düşük miktarda belirli bir ölçümü kullandığını bildirir. Meşgul bir çoğaltma veya örnek daha fazlasını kullandığını bildirir.

Çoğaltma veya örnek başına raporlama yükü, Küme Resource Manager kümedeki tek tek hizmet nesnelerini yeniden düzenlemesine olanak tanır. Hizmetlerin yeniden düzenlenmesi, ihtiyaç duydukları kaynakları almalarını sağlamaya yardımcı olur. Meşgul hizmetler, şu anda soğuk olan veya daha az iş yapan diğer çoğaltmalardan veya örneklerden kaynakları etkili bir şekilde "geri kazanma" elde eder.

Reliable Services içinde yükü dinamik olarak raporlama kodu şöyle görünür:

Kod:

this.Partition.ReportLoad(new List<LoadMetric> { new LoadMetric("CurrentConnectionCount", 1234), new LoadMetric("metric1", 42) });

Bir hizmet, oluşturma zamanında bu hizmet için tanımlanan ölçümlerden herhangi birini raporlayabilir. Bir hizmet, kullanmak üzere yapılandırılmamış bir ölçümün yükünü bildirirse, Service Fabric bu raporu yoksayar. Aynı anda bildirilen ve geçerli olan başka ölçümler varsa bu raporlar kabul edilir. Hizmet kodu, nasıl yapılacağını bildiği tüm ölçümleri ölçebilir ve raporlayabilir ve işleçler hizmet kodunu değiştirmek zorunda kalmadan kullanılacak ölçüm yapılandırmasını belirtebilir.

Bölüm için raporlama yükü

Önceki bölümde hizmet çoğaltmalarının veya örneklerinin kendilerinin nasıl yüklediği açıklanır. Service Fabric API aracılığıyla bir bölümün çoğaltmaları veya örnekleri için yükü dinamik olarak raporlamak için ek bir seçenek vardır. Bir bölümün yükünü bildirirken, aynı anda birden çok bölüm için rapor vekleyebilirsiniz.

Bu raporlar, çoğaltmalardan veya örneklerden gelen yük raporlarıyla tamamen aynı şekilde kullanılır. Bildirilen değerler, çoğaltma veya örnek tarafından veya bir bölüm için yeni bir yük değeri bildirilerek yeni yük değerleri bildirilene kadar geçerli olur.

Bu API ile kümedeki yükü güncelleştirmenin birden çok yolu vardır:

  • Durum bilgisi olan bir hizmet bölümü birincil çoğaltma yükünü güncelleştirebilir.
  • Hem durum bilgisi olmayan hem de durum bilgisi olan hizmetler, tüm ikincil çoğaltmalarının veya örneklerinin yükünü güncelleştirebilir.
  • Durum bilgisi olmayan ve durum bilgisi olan hizmetler düğümdeki belirli bir çoğaltmanın veya örneğin yükünü güncelleştirebilir.

Bölüm başına bu güncelleştirmelerden herhangi birini aynı anda birleştirmek de mümkündür. Belirli bir bölüm için yük güncelleştirmelerinin bileşimi, aşağıdaki örnekte gösterildiği gibi ilgili yük güncelleştirmeleri listesini içerebilen PartitionMetricLoadDescription nesnesi aracılığıyla belirtilmelidir. Yük güncelleştirmeleri, ölçüm adıyla belirtilen bir ölçüm için geçerli veya tahmin edilen yük değerini içerebilen MetricLoadDescription nesnesi aracılığıyla temsil edilir.

Not

Tahmin edilen ölçüm yükü değerleri şu anda bir önizleme özelliğidir. Service Fabric tarafında tahmin edilen yük değerlerinin bildirilmesine ve kullanılmasına izin verir, ancak bu özellik şu anda etkin değildir.

Birden çok bölüm için yüklerin güncelleştirilmesi tek bir API çağrısıyla mümkündür ve bu durumda çıkış bölüm başına bir yanıt içerir. Bölüm güncelleştirmesinin herhangi bir nedenle başarıyla uygulanmaması durumunda, bu bölüme yönelik güncelleştirmeler atlanır ve hedeflenen bölüm için ilgili hata kodu sağlanır:

  • PartitionNotFound - Belirtilen bölüm kimliği yok.
  • ReconfigurationPending - Bölüm şu anda yeniden yapılandırılıyor.
  • InvalidForStatelessServices - Durum bilgisi olmayan bir hizmete ait bölüm için birincil çoğaltmanın yükünü değiştirme girişiminde bulunuldu.
  • ReplicaDoesNotExist - İkincil çoğaltma veya örnek belirtilen bir düğümde yok.
  • InvalidOperation - İki durumda oluşabilir: Sistem uygulamasına ait bir bölümün yükünü güncelleştirme veya tahmini yükü güncelleştirme etkinleştirilmez.

Bu hatalardan bazıları döndürülürse, belirli bir bölüm için girişi güncelleştirebilir ve güncelleştirmeyi yeniden deneyebilirsiniz.

Kod:

Guid partitionId = Guid.Parse("53df3d7f-5471-403b-b736-bde6ad584f42");
string metricName0 = "CustomMetricName0";
List<MetricLoadDescription> newPrimaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 100)
};

string nodeName0 = "NodeName0";
List<MetricLoadDescription> newSpecificSecondaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 200)
};

OperationResult<UpdatePartitionLoadResultList> updatePartitionLoadResults =
    await this.FabricClient.UpdatePartitionLoadAsync(
        new UpdatePartitionLoadQueryDescription
        {
            PartitionMetricLoadDescriptionList = new List<PartitionMetricLoadDescription>()
            {
                new PartitionMetricLoadDescription(
                    partitionId,
                    newPrimaryReplicaLoads,
                    new List<MetricLoadDescription>(),
                    new List<ReplicaMetricLoadDescription>()
                    {
                        new ReplicaMetricLoadDescription(nodeName0, newSpecificSecondaryReplicaLoads)
                    })
            }
        },
        this.Timeout,
        cancellationToken);

Bu örnekle, 53df3d7f-5471-403b-b736-bde6ad584f42 bölümü için bildirilen son yükün güncelleştirmesini gerçekleştirebilirsiniz. CustomMetricName0 ölçümü için birincil çoğaltma yükü 100 değeriyle güncelleştirilir. Aynı zamanda NodeName0 düğümünde bulunan belirli bir ikincil çoğaltma için aynı ölçümün yükü 200 değeriyle güncelleştirilir.

Hizmetin ölçüm yapılandırmasını güncelleştirme

Hizmetle ilişkili ölçümlerin listesi ve bu ölçümlerin özellikleri, hizmet canlıyken dinamik olarak güncelleştirilebilir. Bu, deneme ve esneklik sağlar. Bunun ne zaman yararlı olduğuna dair bazı örnekler şunlardır:

  • belirli bir hizmet için bir buggy raporuyla ölçümü devre dışı bırakma
  • İstenen davranışa göre ölçümlerin ağırlıklarını yeniden yapılandırma
  • yalnızca kod başka mekanizmalar aracılığıyla dağıtıldıktan ve doğrulandıktan sonra yeni bir ölçümü etkinleştirme
  • gözlemlenen davranışa ve tüketime göre hizmet için varsayılan yükü değiştirme

Ölçüm yapılandırmasını değiştirmeye yönelik ana API'ler C# ve Update-ServiceFabricService PowerShell'dedirFabricClient.ServiceManagementClient.UpdateServiceAsync. Bu API'lerle belirttiğiniz bilgiler, hizmetin mevcut ölçüm bilgilerinin yerini hemen alır.

Varsayılan yük değerlerini ve dinamik yük raporlarını karıştırma

Aynı hizmet için varsayılan yük ve dinamik yükler kullanılabilir. Bir hizmet hem varsayılan yük hem de dinamik yük raporlarını kullandığında, dinamik raporlar görünene kadar varsayılan yük bir tahmin görevi görür. Kümeye çalışacak bir şey Resource Manager sağladığından varsayılan yük iyidir. Varsayılan yük, Küme Resource Manager hizmet nesnelerini oluşturulduklarında iyi konumlara yerleştirmesini sağlar. Varsayılan yük bilgisi sağlanmazsa, hizmetlerin yerleştirilmesi etkili bir şekilde rastgele olur. Yük raporları daha sonra geldiğinde ilk rastgele yerleştirme genellikle yanlıştır ve Küme Resource Manager hizmetleri taşıması gerekir.

Önceki örneğimizi ele alalım ve bazı özel ölçümler ve dinamik yük raporlaması eklediğimizde ne olacağını görelim. Bu örnekte örnek ölçüm olarak "MemoryInMb" kullanıyoruz.

Not

Bellek, Service Fabric'in yönetebileceği sistem ölçümlerinden biridir ve bunu kendiniz raporlamak genellikle zordur. Aslında Bellek tüketimi hakkında rapor vermenizi beklemiyoruz; Burada bellek, Küme Resource Manager özellikleri hakkında bilgi edinmede yardımcı olarak kullanılır.

Durum bilgisi olan hizmeti başlangıçta aşağıdaki komutla oluşturduğumuz varsayalım:

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("MemoryInMb,High,21,11”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

Anımsatıcı olarak, bu söz dizimi ("MetricName, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad") şeklindedir.

Olası bir küme düzeninin nasıl görünebileceğine bakalım:

Hem Varsayılan hem de Özel ölçümlerle Küme Dengeli

Dikkate değer bazı şeyler:

  • Bir bölümdeki ikincil çoğaltmaların her biri kendi yüküne sahip olabilir
  • Genel olarak ölçümler dengeli görünür. Bellek için en yüksek ve en düşük yük arasındaki oran 1,75'tir (en çok yüke sahip düğüm N3, en az N2 ve 28/16 = 1,75).

Hala açıklamamız gereken bazı şeyler var:

  • 1,75 oranının makul olup olmadığını belirleyen nedir? Küme Resource Manager bunun yeterli olup olmadığını veya yapılacak daha fazla iş olup olmadığını nasıl anlar?
  • Dengeleme ne zaman gerçekleşir?
  • Memory'nin "High" ağırlıklı olduğu ne anlama gelir?

Ölçüm ağırlıkları

Farklı hizmetlerde aynı ölçümleri izlemek önemlidir. Bu genel görünüm, Küme Resource Manager kümedeki tüketimi izlemesine, düğümler arasında tüketimi dengelemesine ve düğümlerin kapasiteyi aşmamasını sağlamasına olanak tanıyan görünümdür. Ancak, hizmetlerin aynı ölçümün önemine ilişkin farklı görünümleri olabilir. Ayrıca, çok sayıda ölçüme ve çok sayıda hizmete sahip bir kümede, tüm ölçümler için mükemmel dengeli çözümler olmayabilir. Küme Resource Manager bu durumlarla nasıl başa çıkmalıdır?

Ölçüm ağırlıkları, Küme Resource Manager mükemmel bir yanıt olmadığında kümenin nasıl dengelenmesi gerektiğine karar vermesine olanak sağlar. Ölçüm ağırlıkları, Küme Resource Manager belirli hizmetleri farklı şekilde dengelemesine de olanak tanır. Ölçümlerin dört farklı ağırlık düzeyi olabilir: Sıfır, Düşük, Orta ve Yüksek. Ağırlığı Sıfır olan bir ölçüm, öğelerin dengeli olup olmadığı düşünülürken hiçbir katkı sağlamaz. Ancak yükü kapasite yönetimine katkıda bulunmaya devam eder. Sıfır ağırlıklı ölçümler hala yararlıdır ve hizmet davranışı ve performans izlemenin bir parçası olarak sıklıkla kullanılır. Bu makalede , hizmetlerinizin izlenmesi ve tanılaması için ölçümlerin kullanımı hakkında daha fazla bilgi sağlanır.

Kümedeki farklı ölçüm ağırlıklarının gerçek etkisi, Küme Resource Manager farklı çözümler üretmesidir. Ölçüm ağırlıkları, Küme Resource Manager belirli ölçümlerin diğerlerinden daha önemli olduğunu söyler. Mükemmel bir çözüm olmadığında, Küme Resource Manager daha yüksek ağırlıklı ölçümleri daha iyi dengeleyen çözümleri tercih edebilir. Bir hizmet belirli bir ölçümün önemsiz olduğunu düşünüyorsa bu ölçümün kullanımını dengesiz bulabilir. Bu, başka bir hizmetin önemli olan bazı ölçümlerin eşit dağıtımını almasına olanak tanır.

Şimdi bazı yük raporlarına ve farklı ölçüm ağırlıklarının kümede farklı ayırmalara nasıl neden olduğunu gösteren bir örneğe göz atalım. Bu örnekte ölçümlerin göreli ağırlığının değiştirilmesinin Küme Resource Manager farklı hizmet düzenlemeleri oluşturmasına neden olduğunu görüyoruz.

Ölçüm Ağırlığı Örneği ve Dengeleme Çözümleri Üzerindeki Etkisi

Bu örnekte, tümü MetricA ve MetricB gibi iki farklı ölçüm için farklı değerler bildiren dört farklı hizmet vardır. Bir durumda, MetricA'yı tanımlayan tüm hizmetler en önemli hizmettir (Ağırlık = Yüksek) ve ÖlçümB önemsizdir (Ağırlık = Düşük). Sonuç olarak, MetricA'nın MetricB'den daha iyi dengelenmesi için Küme Resource Manager hizmetleri yerleştirdiğini görüyoruz. "Daha iyi dengeli", MetricA'nın standart sapması MetricB'den daha düşük olduğu anlamına gelir. İkinci durumda ölçüm ağırlıklarını tersine çeviririz. Sonuç olarak, Küme Resource Manager A ve B hizmetlerini değiştirerek MetricB'nin MetricA'dan daha iyi dengelendiği bir ayırma oluşturur.

Not

Ölçüm ağırlıkları, Küme Resource Manager nasıl dengelenmesi gerektiğini belirler, ancak dengelemenin ne zaman gerçekleşmeyeceğini belirler. Dengeleme hakkında daha fazla bilgi için bu makaleye göz atın

Genel ölçüm ağırlıkları

ServiceA'nın MetricA'yı Yüksek ağırlık olarak tanımladığı ve ServiceB'nin MetricA için ağırlığı Düşük veya Sıfır olarak belirlediği düşünelim. Kullanılacak gerçek ağırlık nedir?

Her ölçüm için izlenen birden çok ağırlık vardır. İlk ağırlık, hizmet oluşturulduğunda ölçüm için tanımlanan ağırlıktır. Diğer ağırlık ise otomatik olarak hesaplanan genel bir ağırlıktır. Küme Resource Manager, çözümleri puanlarken bu ağırlıkları kullanır. Her iki ağırlığın da dikkate alınması önemlidir. Bu, Küme Resource Manager her hizmeti kendi önceliklerine göre dengelemesine ve kümenin bir bütün olarak doğru ayrılmasını sağlar.

Küme Resource Manager hem genel hem de yerel dengeyi önemsemeseydi ne olurdu? Küresel olarak dengeli çözümler oluşturmak kolaydır, ancak bu da tek tek hizmetler için düşük kaynak dengesine neden olur. Aşağıdaki örnekte, yalnızca varsayılan ölçümlerle yapılandırılmış bir hizmete göz atalım ve yalnızca genel denge dikkate alındığında ne olduğuna bakalım:

Yalnızca Genel Çözümün Etkisi

Yalnızca genel dengeyi temel alan en üst örnekte kümenin bir bütün olarak dengeli olması gerekir. Tüm düğümler aynı sayıda birincil sayıya ve aynı sayıda toplam çoğaltmaya sahiptir. Ancak, bu ayırmanın gerçek etkisine bakarsanız o kadar da iyi değildir: düğüm kaybı belirli bir iş yükünü orantısız bir şekilde etkiler, çünkü tüm temellerini alır. Örneğin, ilk düğüm başarısız olursa Circle hizmetinin üç farklı bölümü için üç öncelik kaybolur. Buna karşılık, Triangle ve Altıgen hizmetlerinin bölümleri bir çoğaltmayı kaybeder. Bu, aşağı çoğaltmayı kurtarmak dışında kesintiye neden olmaz.

Alt örnekte, Küme Resource Manager çoğaltmaları hem genel hem de hizmet başına bakiyeye göre dağıtmıştır. Çözümün puanını hesaplarken, ağırlığın çoğunu genel çözüme, (yapılandırılabilir) kısmı ise tek tek hizmetlere verir. Bir ölçümün genel bakiyesi, her hizmetten alınan ölçüm ağırlıklarının ortalaması temel alınarak hesaplanır. Her hizmet, kendi tanımlı ölçüm ağırlıklarına göre dengelenmiş durumdadır. Bu sayede hizmetlerin kendi ihtiyaçlarına göre kendi içinde dengelenmesi sağlanır. Sonuç olarak, aynı ilk düğüm başarısız olursa hata tüm hizmetlerin tüm bölümlerine dağıtılır. Her biri üzerindeki etki aynıdır.

Sonraki adımlar

  • Hizmetleri yapılandırma hakkında daha fazla bilgi için Hizmetleri yapılandırma hakkında bilgi edinin (service-fabric-cluster-resource-manager-configure-services.md)
  • Birleştirme Ölçümlerini tanımlamak, düğümleri dağıtmak yerine yükü birleştirmenin bir yoludur. Birleştirmeyi yapılandırmayı öğrenmek için bu makaleye bakın
  • Küme Resource Manager kümedeki yükü nasıl yönettiğini ve dengelediğinden haberdar olmak için yük dengeleme makalesine göz atın
  • Baştan başlayın ve Service Fabric Kümesine Giriş Resource Manager
  • Taşıma Maliyeti, Kümeye belirli hizmetlerin taşınmasının diğerlerinden daha pahalı olduğunu Resource Manager bir sinyal yoludur. Taşıma maliyeti hakkında daha fazla bilgi edinmek için bu makaleye bakın