Part 2 — IBM Turbonomic (ARM) Çalışma Prensibi
Selamlar,
IBM Turbonomic yazı serimizin ikincisi olan “IBM Turbonomic Çalışma Prensibi” başlıkli yazı ile tekrar karşınızdayım.
Part 1 — IBM Turbonomic ile Verimlilik ve Performans Dengesini Sağlayın.. başlık yazıyı okumak için,
Bu yazıda ise biraz daha teknik konulara girerek, IBM Turbonomic’in çalışma prensibine odaklanacağız.
Uygulama Kaynak Yönetimi, uygulamaların kaynak ihtiyaçlarını sürekli olarak analiz eden ve uygulamaların herhangi bir performans problemine karşı eyleme geçirelebilir aksiyonlar geliştiren, top-down olarak tüm uygulama mimarisini çıkaran uygulama odaklı bir yaklaşımdır. Sürekli çalışır bir modda olması sebebi ile en karmaşık ortamlarda da 7/24/365 gün olarak ölçeklenebilmektedir.
IBM Turbonomic platformu ortamınızın istenilen durumda (Desired State) tutmak için aşağıdaki iki önemli konuya dikkat eder.
- Assure Application Performance
- Efficient use of Resources
IBM Turbonomic Platformu nasıl çalışır?
Alt yapınızı istenilen durumda (Desired State) tutmak bir çok açıdan çok kritik ve önemlidir. IBM Turbonomic, uygulama performansını garanti ederken diğer yandan kaynakların en verimli kullanımını sağlamayı hedefleyen bir yazılım olarak karşımıza çıkıyor. Uygulama Kaynak Yönetimi (ARM) ilk bakışta çok kolay gibi görünsede bir çok farklı parametriyi analiz ederek karar vermek zorundadır. Altyapılar büyüdükçe, farklı katmanlar için farklı ekiplerin karar alma süreçleri devreye girer. Bunun üzerine ise dinamik-değişken bir yapınız var ise sürekli olarak uygulamalarınızı ve kaynaklarınızı izleyerek bir karar almanız gerekiyor.
IBM Turbonomic hem alıcı (kaynağı talep eden) hem de satıcı (kaynak tahsisi yapan) bir model oluşturur ve bu modeli kullanmaktadır. Bu modelin adına Tedarik Zinciri (Supply Chain) de diyoruz. Yukarıda örnek tedarik zinciri yapısını görebilirsiniz.
Tedarik zinciri, veri merkezinden, fiziksel katmanlara, sanallaştırma ortamlarına, bulut hizmetlerine kadar farklı teknoloji ve ürünleri desteklemektedir.
Daha fazla ve güncel bilgiye aşağıdaki bağlantıdan ulaşabilirsiniz.
The Desired State — İstenilen Durum
IBM Turbonomic platformunun amacı, kaynakların verimli kullanımını sürdürürken uygulama performansını güvenve altına alır. Performans ve Verimliliği aynı anda sürdürdüğünüzde, ortam istenilen durumdadır, yani Desire State..
Aşağıdaki grafiği inceleyecek olursak, Performansı, gecikme/delay fonksiyonu olarak ölçebilirsiniz. QoS- Hizmet için ideal gecikme süresini verir. Efficiency-Max Utilization ise bir kaynağın %100 kullanımının en verimli kullanım için ideal olduğu bir kullanım fonksiyonudur.
Gecikme/Delay ile Utilization/Kullanım oranı için bir grafik çizdiğinizde her ikisi arasında bir eğri oluşacaktır. Belirli bir noktaya kadar kullanımı artırdıkça, gecikme yine benzer şekilde hafif bir artış göstermektedir. T anında çok fazla kaynak kullanımı gerçekleşirse o zaman gecikme süresinin önüne geçilemez. Desired State ise her iki paremetrenin ortak birleştiği yeri gösterir.
The Market — Virtual Currency / Pazar — Sanal Para
IBM Turbonomic platformu, Uygulama Kaynak Yönetimi yapabilmek için ortamı bir pazar yeri olarak modellemektedir ve kaynak arzı — talebini yönetmek için pazar analizi motoru kullanmaktadır.
IBM Turbonomic ortamı modellemek için iki tür soyutlama kullanır;
- Fiziksel-Sanal IT yapısını bir hizmet tedarik zinciri olarak modellemesidir. Uygulamalar, Sanal sunucular, fiziksel sunucular, depolama üniteleri, konteynerler, bulut hizmet sağlayıcıları ve veri merkezlerini içermektedir.
- Gecikme/Delay ve QoS problemlerini temsil etmek ve tedarik zinciri boyunca hizmet arz-talebini yönetmek için sanal para kullanır. Sistem kaynakların alınıp-satılma işlemlerine değer atamak için sanal paralar kullanır. Her yönetilen kaynak ise bir bütçeye sahiptir ve kaynaklar, tüketicilere kaynak sağlayarak bütçesine katkıda bulunur ve tükettiği kaynaklar için bütçeden düşer.
Risk Index — Risk Endeksi
IBM Turbonomic kaynakların fiyatlarını bir Risk Endeksi olarak izlemektedir. Bu endeks ne kadar yüksek ise o kaynağın o kadar yoğun kullanıldığı, bu kaynağın daha fazla performans ve gecikmeye sebep olacağını öngörerek bir risk taşıdığını ifade etmektedir. Risk endeksi bir kaynağın maliyeti olarak düşünebiliriz. Turbonomic, maliyeti rekabetçi bir seviyede tutmayı hedeflemektedir. Turbonomic tüm kaynakları ilişkisini analiz eder ve sürekli mevcut olan en ekonomik işlemi aramaktadır.
Turbonomic’in çalışma mantığını anlamak için Risk endeksi çok önemlidir. Dinamik bir mimaride hangi uygulama ne kadar kaynak talep ediyor, kaynak tahsisi olarak ne kadar kaynak havuzumuz var bunu sürekli bir şekilde yapmak imkansızdır. Turbonomic uygulamalarınızı sürekli Desired State e uygun olarak önerilerde bulunur.
IBM Turbonomic Teknoloji Mimarisi
IBM Turbonomic Platformu, Kubernetes üzerinde çalışan mikro servis olarak geliştirilmiştir. Dinamik uygulamalar için gerekli tüm özellikleri Kubernetes’ten sağlayan IBM Turbonomic platformu kurumsal ölçekli firmalar için de hızlıca ölçeklenebilmektedir. Turbonomic hybrid cloud mimarileri desteklemektedir, yani hem on-premises, hem de genel bulut (SaaS) olarak kullanılabilir.
IBM Turbonomic platformu, Communication, UI, Presentation, Automation, Analysis, Abstraction, Management, Persistence ve 3rd party integration modüllerinden oluşmaktadır.
Kısa kısa hangi modül ne iş yapıyor bakalım;
1-Abstraction : Bu katmanda 4 farklı bileşen yer almaktadır. Mediation probes, Topology Processor, Repository,History..
Mediation probe’lar, farklı hedeflerde verileri toplama görevini üstlenir. Verilerin toplandıkran sonra bu verileri Topology Processor’e iletir. Mediation probes ayrıca işlemleri gerçekleştirme görevini de üstlenir. Mediation probes hedefleriyle etkileşimde bulunduktan sonra, Topology Processor Mediation probe’lardan keşif yanıtlarını alır. Ardıdan keşfedilen her varlık için bir nesne kimliği (OID) atanır. Repository bileşeni, TP (Topology Processor) tarafından oluşturulan kaynak topolojilerini depolamaktan sorumludur. Repository bileşeni için veriler MariaDB’de saklanır. History bileşeni ise geçmeşe yönelik verilerle ilgili olaraki geçmişteki herhangi bir tarihte VM kullanımını nasıl bileceğini veya son yedi gündeki vMEM kullanımını ait verilerin saklandığı bileşendir.
2- Analysis: Analiz katmanı, Market ve Cost bileşenlerinden oluşur.
Market bileşeni, canlı topolojileri almak ve bu topolojiler üzerinde analizler yapmakla sorumludur. Cost bileşeni ise, Bulut hedeflerine, maliyet bilgisi sağlar ve Reserve Instance satın alma algoritmasını uygular. Sonuç olarak elde edilen işlemler, Otomasyon katmanındaki Action Orchestrator’e gönderilir.
3- Automation: Otomasyon katmanında, Action orchestrator, Group ve Plan Orchestrator’dan oluşmaktadır. Grup bileşeni, gruplar, politikalar ve ayarlar için tüm muhasebe işlemlerini yapar. Gruplar, Turbonomic tarafından otomatik olarak oluşturanlar ve kullanıcı tarafından oluşturulanlar dahil edilir. Politikalar, varsayılan politikalar ve kullanıcılar tarafından oluşturulan politikaları içerir. Plan Orchestrator, planlar ve şablonlar için muhasebe işlemlerini yapar. Ayrıca başlangıç yerleştirme önerileri ve rezervasyonlarını, plan ilerlemesini /durumlarını takip ederi. Aynı zamanda kullanıların oluşturduğu planlar ve gece planı yapılandırmaları da sorumluluğundadır.
4- Presentation: Bu katmanda ise 3 temel bileşen bulunmaktadır. API bileşeni, Turbo’nun API uç noktaları için hizmetler uygular, sorguları iç bileşenlere yönlendirir verilen müşteriye tüketilebilir bir formatta tekrar geri bırakır.
Auth bileşeni ise, kullanıcı erişim doğrulaması, kullanıcı kimlik veritabanının yönetimi, denetim kayıtları, lisans yönetimi sağlayan kimlik doğrulama bileşenidir. Tüm veriler Rsyslog’ a gönderilir. Denetim kaydı, hangi kullanıcın giriş yaptığını ve kullanıcın ne yaptığını izler.
5- Management: Bu katmanda 3 temel bileşen yer almaktadır. Consul, ClusterMgr ve Rsyslog.
Rsyslog bileşeni, günlük toplayıcı olarak düşünülebilir. Operator hariç, her bir bileşenden günlükleri toplar Bireysel günlüklerle çalışmak yerine, bu bileşen size tüm bileşemlerin günlüklerini tek bir merkezi konumdan erişim olanağı sunar. Bir bileşenin günlüklerini görmek isterseniz, her zaman o bileşene gidilir ve bileşenin günlüklerini kontrol edebilirsiniz.
Consul bileşeni ise, öncelikle hizmet yapılandırma verilerini kalıcı hale getirmek için kullanılır. Consul, hedefi, hedef kimlik bilgilerini ve hedef türünü bilecektir. Cluster yöneticisi bileşeni ise, tüm işlemker için teşhis kimlik bilgilerini ve hedef türünü bilecektir.
6- Communication: Bu katmanda ise Turbonomic Platformunda yer alan iletişim teknolojilerinden sorumludur. Nginx, Kafka ve Zookeper tarafından ele alınır. Nginx, gelen istek yük dengelemesi sağlayan bir web sunucusudur. Tüm gelen istekler Nginx üzerinden geçer. Kafka bileşenler arasında iletişim kurulmasını sağlar. Zookeper ise yalnızca Kafka tarafından kullanılan bir key-value bilgilerini tutar.
7- Persistence: Bu katmanda ise , MariaDB pek çok bileşenin kullandığı ilişkisel veri tabanı olarak kullanılır.
Burada yazıyı sonlandırıyorum, bir sonraki yazıda görüşmek dileğiyle!
Teşekkürler
