Service Fabric kümesi kaynak yöneticisine giriş

Geleneksel olarak BT sistemlerini yönetmek veya çevrimiçi hizmetler belirli fiziksel veya sanal makineleri bu hizmetlere veya sistemlere ayırmak anlamına geliyordu. Hizmetler katman olarak tasarlanmıştı. "Web" katmanı ve "veri" veya "depolama" katmanı olabilir. Uygulamalar, isteklerin içeri ve dışarı akışının yanı sıra önbelleğe almaya ayrılmış bir dizi makine içeren bir mesajlaşma katmanına sahip olacaktır. Her katmanın veya iş yükünün türüne ayrılmış belirli makineler vardı: veritabanı ona ayrılmış birkaç makine, web sunucuları ise birkaç makineye sahip. Belirli bir iş yükü türü üzerinde olduğu makinelerin çok sıcak çalışmasına neden olmuşsa, bu katmana aynı yapılandırmaya sahip daha fazla makine eklemiş olursunuz. Ancak tüm iş yüklerinin ölçeği bu kadar kolay genişletilemedi; özellikle de veri katmanında genellikle makineleri daha büyük makinelerle değiştirirsiniz. Çok basit. Bir makine başarısız olursa, makine geri yüklenene kadar genel uygulamanın bu bölümü daha düşük kapasitede çalıştırılır. Yine de oldukça kolay (eğlenceli olmasa da).

Artık hizmet ve yazılım mimarisi dünyası değişti. Uygulamaların ölçeği genişletme tasarımını benimsemesi daha yaygındır. Kapsayıcılar veya mikro hizmetler (veya her ikisi) ile uygulama derlemek yaygın bir durumdur. Artık yalnızca birkaç makineniz olsa da, bunlar bir iş yükünün yalnızca tek bir örneğini çalıştırmıyor. Aynı anda birden çok farklı iş yükü bile çalıştırıyor olabilirler. Artık onlarca farklı hizmet türünüz (makinenin tüm kaynaklarını tüketmeyen) ve bu hizmetlerin yüzlerce farklı örneğine sahipsiniz. Her adlandırılmış örneğin Yüksek Kullanılabilirlik (HA) için bir veya daha fazla örneği veya çoğaltması vardır. Bu iş yüklerinin boyutlarına ve ne kadar meşgul olduklarına bağlı olarak, kendinizi yüzlerce veya binlerce makineyle bulabilirsiniz.

Ortamınızı aniden yönetmek, tek iş yükü türlerine ayrılmış birkaç makineyi yönetmek kadar basit değildir. Sunucularınız sanaldır ve artık adları yoktur (sonuçta evcil hayvanlardan sığırlara geçmişsiniz). Yapılandırma, makineler hakkında daha az, hizmetlerle ilgili daha fazladır. Bir iş yükünün tek bir örneğine ayrılmış donanım büyük ölçüde geçmişte kaldı. Hizmetler, birden fazla küçük ticari donanım parçasına yayılan küçük dağıtılmış sistemler haline gelmiştir.

Uygulamanız artık birkaç katmana yayılmış bir monolit serisi olmadığından, artık ilgilenmeniz gereken çok daha fazla kombinasyon var. Hangi tür iş yüklerinin hangi donanımda veya kaç tanesinde çalışabileceğine kim karar verir? Aynı donanım üzerinde hangi iş yükleri düzgün çalışır ve hangi çakışmalar? Bir makine çökerken, o makinede ne çalıştırıldığını nereden biliyorsun? İş yükünün yeniden çalışmaya başladığından emin olmak kimin sorumluluğundadır? (sanal?) makinenin geri gelmesini mi bekliyorsunuz yoksa iş yükleriniz otomatik olarak diğer makinelere yük devredip çalışmaya devam mı ediyor? İnsan müdahalesi gerekli mi? Bu ortamdaki yükseltmeler ne olacak?

Bu ortamda işlem yürüten geliştiriciler ve operatörler olarak bu karmaşıklığı yönetme konusunda yardım istiyoruz. bir işe alım kutusu ve insanların karmaşıklığını gizlemeye çalışmak muhtemelen doğru yanıt değildir, yani ne yapacağız?

Düzenleyicilere giriş

"Orchestrator", yöneticilerin bu tür ortamları yönetmesine yardımcı olan bir yazılım parçasının genel terimidir. Orchestrators, "Bu hizmetin beş kopyasının ortamımda çalışmasını istiyorum" gibi istekler alan bileşenlerdir. Ne olursa olsun ortamın istenen durumla eşleşmesini sağlamaya çalışırlar.

Bir makine başarısız olduğunda veya bir iş yükü beklenmedik bir nedenle sonlandırıldığında eyleme geçen düzenleyiciler (insanlar değil) olur. Çoğu düzenleyici hatayla uğraşmaktan fazlasını yapar. Sahip oldukları diğer özellikler yeni dağıtımları yönetmek, yükseltmeleri işlemek ve kaynak tüketimi ve idaresiyle ilgilenmektir. Tüm düzenleyiciler temelde ortamda istenen yapılandırma durumunu korumakla ilgilidir. Bir düzenleyiciye ne istediğini söyleyebilmek ve ağır işi yapmasını sağlamak istiyorsun. Mesos, Docker Datacenter/Docker Swarm, Kubernetes ve Service Fabric üzerindeki Kuzey Işıkları, düzenleyicilere örnek olarak verilebilir. Bu düzenleyiciler üretim ortamlarında gerçek iş yüklerinin ihtiyaçlarını karşılamak için etkin bir şekilde geliştiriliyor.

Hizmet olarak düzenleme

Küme Resource Manager, Service Fabric'te düzenlemeyi işleyen sistem bileşenidir. Küme Resource Manager işi üç bölüme ayrılmıştır:

1. Kuralları Zorunlu Tutma
2. Ortamınızı en iyi duruma getirme
3. Diğer İşlemlere Yardımcı Olma

Küme Resource Manager nasıl çalıştığını anlamak için eğitim videosu için bu sayfayı gözden geçirin:

Olmayan şey

Geleneksel N katmanlı uygulamalarda her zaman bir Load Balancer vardır. Bu genellikle ağ yığınında nerede bulunduğuna bağlı olarak ağ Load Balancer (NLB) veya Uygulama Load Balancer (ALB) idi. Bazı yük dengeleyiciler F5'in BigIP teklifi gibi Donanım tabanlıdır, diğerleri ise Microsoft'un NLB'leri gibi yazılım tabanlıdır. Diğer ortamlarda, bu rolde HAProxy, nginx, Istio veya Envoy gibi bir şey görebilirsiniz. Bu mimarilerde yük dengeleme, durum bilgisi olmayan iş yüklerinin (kabaca) aynı miktarda çalışma aldığından emin olmaktır. Yükü dengeleme stratejileri çeşitlidir. Bazı dengeleyiciler her farklı çağrıyı farklı bir sunucuya gönderir. Diğerleri oturum sabitleme/yapışkanlık sağladı. Daha gelişmiş dengeleyiciler, bir çağrıyı beklenen maliyete ve geçerli makine yüküne göre yönlendirmek için gerçek yük tahminini veya raporlamayı kullanır.

Ağ dengeleyiciler veya ileti yönlendiricileri, web/çalışan katmanının kabaca dengeli kalmasını sağlamaya çalıştı. Veri katmanını dengeleme stratejileri farklıydı ve veri depolama mekanizmasına bağlıydı. Veri katmanını dengeleme, veri parçalama, önbelleğe alma, yönetilen görünümler, saklı yordamlar ve depoya özgü diğer mekanizmalara dayanır.

Bu stratejilerden bazıları ilgi çekici olsa da Service Fabric Kümesi Resource Manager ağ yük dengeleyici veya önbellek gibi bir şey değildir. Ağ Load Balancer, trafiği ön uçlara yayarak ön uçları dengeler. Service Fabric Kümesi Resource Manager farklı bir stratejiye sahiptir. Temel olarak, Service Fabric hizmetleri en anlamlı olduğu yere taşır ve takip etmek için trafik veya yük bekler. Örneğin, mevcut hizmetler çok fazla iş yapmadığından hizmetleri şu anda soğuk olan düğümlere taşıyabilir. Mevcut hizmetler silindiğinden veya başka bir yere taşındığından düğümler soğuk olabilir. Başka bir örnek olarak, Küme Resource Manager bir hizmeti makineden uzağa da taşıyabilir. Belki de makine yükseltilecek veya üzerinde çalışan hizmetler tarafından tüketilen ani bir artış nedeniyle aşırı yüklenmiş olabilir. Alternatif olarak, hizmetin kaynak gereksinimleri artmış olabilir. Sonuç olarak, bu makinede çalıştırmaya devam etmek için yeterli kaynak yok.

Küme Resource Manager hizmetleri taşımakla sorumlu olduğundan, ağ yük dengeleyicide bulabileceğinize kıyasla farklı bir özellik kümesi içerir. Bunun nedeni, ağ yük dengeleyicilerinin hizmetin kendisi için ideal olmasa bile hizmetlerin zaten bulunduğu yere ağ trafiği sunmalarıdır. Service Fabric Kümesi Resource Manager, kümedeki kaynakların verimli bir şekilde kullanılmasını sağlamak için temelden farklı stratejiler kullanır.

Sonraki adımlar

• Küme Resource Manager içindeki mimari ve bilgi akışı hakkında bilgi için bu makaleyi gözden geçirin
• Küme Resource Manager kümeyi açıklamaya yönelik birçok seçenek vardır. Ölçümler hakkında daha fazla bilgi edinmek için Service Fabric kümesini açıklama makalesine göz atın
• Hizmetleri yapılandırma hakkında daha fazla bilgi için Hizmetleri yapılandırma hakkında bilgi edinin
• Ölçümler, Service Fabric Kümesi Kaynak Yöneticisi'nin kümedeki tüketimi ve kapasiteyi yönetme şeklidir. Ölçümler ve bunları yapılandırma hakkında daha fazla bilgi edinmek için bu makaleye göz atın
• Küme Resource Manager Service Fabric'in yönetim özellikleriyle çalışır. Bu tümleştirme hakkında daha fazla bilgi edinmek için bu makaleyi okuyun
• 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