Service Fabric küme kaynak yöneticisine giriş
Geleneksel olarak BT sistemlerini veya çevrimiçi hizmetler yönetmek, belirli fiziksel veya sanal makineleri bu hizmetlere veya sistemlere ayırmak anlamına geliyordu. Hizmetler katman olarak tasarlandı. "Web" katmanı ve "veri" veya "depolama" katmanı olabilir. Uygulamaların, isteklerin içeri ve dışarı akışının yanı sıra önbelleğe almaya ayrılmış bir makine kümesine sahip olduğu bir mesajlaşma katmanı olacaktır. Her katman veya iş yükü türü, ona ayrılmış belirli makinelere sahipti: veritabanı, ona ayrılmış birkaç makine, web sunucuları ise birkaç makineye sahip. Belirli bir iş yükü türü üzerindeki makinelerin çok sıcak çalışmasına neden olduysa, bu katmana aynı yapılandırmaya sahip daha fazla makine eklediniz. Ancak tüm iş yüklerinin ölçeği bu kadar kolay genişletilemedi; özellikle de genellikle makineleri daha büyük makinelerle değiştirirsiniz. Kolay. 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ı. Yine de oldukça kolay (mutlaka eğlenceli değilse).
Ancak şimdi hizmet ve yazılım mimarisi dünyası değişti. Uygulamaların ölçeği genişletme tasarımını benimsemiş olması daha yaygın bir durum. Kapsayıcılarla veya mikro hizmetlerle (veya her ikisiyle de) uygulama oluşturmak 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. Hatta aynı anda birden çok farklı iş yükü çalıştırıyor olabilirler. Artık onlarca farklı hizmet türüne (hiçbir makineye ait tam kaynak tüketmiyor), belki de 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.
Birden ortamınızı 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 beyin kümeleri değiştirdiniz). Yapılandırma, makineler ve hizmetler hakkında daha azdır. Bir iş yükünün tek bir örneğine ayrılmış donanımlar büyük ölçüde geçmişte kaldı. Hizmetlerin kendileri, 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 dizi monolit olmadığından, artık ilgilenmeniz gereken çok daha fazla kombinasyon var. Hangi tür iş yüklerinin hangi donanımda veya kaç iş yükünde çalışabileceğine kim karar verir? Aynı donanımda hangi iş yükleri düzgün çalışır ve hangi çakışmalar? Bir makine battığında 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 gören geliştiriciler ve operatörler olarak bu karmaşıklığı yönetme konusunda yardım istiyoruz. İşe alma ve insanların karmaşıklığını gizlemeye çalışmak muhtemelen doğru cevap değil, 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ıştırılması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 iş yükü beklenmedik bir nedenle sonlandırıldığında düzenleyiciler (insanlar değil) eylemde bulunur. Ç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 idaresi ile ilgilenmektir. Tüm düzenleyiciler temelde ortamda istenen yapılandırma durumunu korumakla ilgilidir. Bir düzenleyiciye ne istediğinizi söyleyebilmek ve ağır işi yapmalarını sağlamak istiyorsunuz. Mesos, Docker Datacenter/Docker Swarm, Kubernetes ve Service Fabric'in üzerindeki Aurora, düzenleyicilere örnek olarak verilebilir. Bu düzenleyiciler, üretim ortamlarındaki gerçek iş yüklerinin ihtiyaçlarını karşılamak için etkin bir şekilde geliştiriliyor.
Hizmet olarak düzenleme
Küme Kaynak Yöneticisi, Service Fabric'te düzenlemeyi işleyen sistem bileşenidir. Küme Kaynak Yöneticisi'nin işi üç bölüme ayrılmıştır:
- Kuralları Zorunlu Tutma
- Ortamınızı İyileştirir
- Diğer İşlemlere Yardımcı Olma
Olmayan şey
Geleneksel N katmanı uygulamalarında her zaman bir Load Balancer vardır. Bu genellikle ağ yığınının neresinde bulunduğuna bağlı olarak bir Ağ Yük Dengeleyici (NLB) veya Uygulama Yük Dengeleyici (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 dengelemenin görevi, durum bilgisi olmayan iş yüklerinin aynı miktarda iş almasını (kabaca) sağlamaktır. Yük dengeleme stratejileri çeşitlidir. Bazı dengeleyiciler her farklı çağrıyı farklı bir sunucuya gönderir. Diğerleri oturum sabitleme/süreklilik sağladı. Daha gelişmiş dengeleyiciler, bir çağrıyı beklenen maliyetine ve geçerli makine yüküne göre yönlendirmek için gerçek yük tahmini veya raporlama 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 Kaynak Yöneticisi ağ yük dengeleyici veya önbellek gibi bir şey değildir. Ağ Yük Dengeleyici, trafiği ön uçlara yayarak ön uçları dengeler. Service Fabric Kümesi Kaynak Yöneticisi'nin farklı bir stratejisi vardır. Temel olarak, Service Fabric hizmetleri en anlamlı olduğu yere taşır ve takip etmek için trafik veya yük bekler. Örneğin, orada bulunan 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 Kaynak Yöneticisi bir hizmeti makineden uzağa da taşıyabilir. Belki de makine yükseltilecek veya üzerinde çalışan hizmetlerin tüketimindeki ani 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 Kaynak Yöneticisi 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 bulunduğu konuma ağ trafiği sağlamasıdır. Service Fabric Kümesi Kaynak Yöneticisi, kümedeki kaynakların verimli bir şekilde kullanılmasını sağlamak için temel olarak farklı stratejiler kullanır.
Sonraki adımlar
- Küme Kaynak Yöneticisi içindeki mimari ve bilgi akışı hakkında bilgi için bu makaleye göz atın
- Küme Kaynak Yöneticisi'nin kümeyi açıklamaya yönelik birçok seçeneği vardır. Ölçümler hakkında daha fazla bilgi edinmek için Service Fabric kümesini açıklama hakkındaki bu makaleye 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 Kaynak Yöneticisi, 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'ın kümedeki yükü nasıl yönettiği ve dengelediğinden haberdar olmak için yükü dengeleme makalesine göz atın