Büyük bulut sistemlerinde, bilgi işlem kaynakları üzerindeki yükün otomatik olarak dengelenmesi veya dengelenmesi sorunu özellikle ciddidir. Tionix (Rostelecom şirketler grubunun bir parçası olan bulut hizmetlerinin geliştiricisi ve operatörü) de bu konuyla ilgilendi.
Ve ana geliştirme platformumuz Openstack olduğundan ve biz de tüm insanlar gibi tembel olduğumuzdan, platformda halihazırda bulunan bazı hazır modülleri seçmeye karar verildi. Seçimimiz ihtiyaçlarımız için kullanmaya karar verdiğimiz Watcher'a düştü.
Öncelikle terimlere ve tanımlara bakalım.
Terimler ve tanımlar
Gol elde edilmesi gereken, insan tarafından okunabilen, gözlemlenebilir ve ölçülebilir bir sonuçtur. Her hedefe ulaşmak için bir veya daha fazla strateji vardır. Strateji, belirli bir amaç için çözüm bulma yeteneğine sahip bir algoritmanın uygulanmasıdır.
Aksiyon OpenStack kümesinin hedef yönetilen kaynağının mevcut durumunu değiştiren temel bir görevdir, örneğin: bir sanal makinenin taşınması (geçiş), bir düğümün güç durumunun değiştirilmesi (change_node_power_state), nova hizmetinin durumunun değiştirilmesi (change_nova_service_state) ), tadı değiştirme (yeniden boyutlandırma), NOP mesajlarını kaydetme (nop), belirli bir süre boyunca işlem yapılmaması - duraklatma (uyku), disk aktarımı (volume_migrate).
Hareket planı - Belirli bir Hedefe ulaşmak için belirli bir sırayla gerçekleştirilen belirli bir eylem akışı. Eylem Planı ayrıca bir dizi performans göstergesiyle ölçülen küresel performansı da içeriyor. Başarılı bir denetim sonrasında Watcher tarafından bir aksiyon planı oluşturulur ve bunun sonucunda kullanılan strateji hedefe ulaşmak için çözüm bulur. Bir eylem planı ardışık eylemlerin bir listesinden oluşur.
Denetim kümeyi optimize etme isteğidir. Optimizasyon, belirli bir kümede bir Hedefe ulaşmak için gerçekleştirilir. Her başarılı denetim için Watcher bir Eylem Planı oluşturur.
Denetim Kapsamı denetimin gerçekleştirildiği bir dizi kaynaktır (kullanılabilirlik bölgeleri, düğüm toplayıcıları, bireysel bilgi işlem düğümleri veya depolama düğümleri vb.). Denetim kapsamı her şablonda tanımlanır. Denetim kapsamı belirtilmemişse kümenin tamamı denetlenir.
Denetim Şablonu — bir denetimi başlatmak için kaydedilmiş bir dizi ayar. Denetimleri aynı ayarlarla birden çok kez yürütmek için şablonlara ihtiyaç vardır. Şablon mutlaka denetimin amacını içermelidir; stratejiler belirtilmemişse mevcut stratejilerden en uygun olanı seçilir.
Küme bilgi işlem, depolama ve ağ kaynakları sağlayan ve aynı OpenStack yönetim düğümü tarafından yönetilen fiziksel makinelerin bir koleksiyonudur.
Küme Veri Modeli (CDM) küme tarafından yönetilen kaynakların mevcut durumunun ve topolojisinin mantıksal bir temsilidir.
Verimlilik Göstergesi - Bu strateji kullanılarak oluşturulan çözümün nasıl gerçekleştirildiğini gösteren bir gösterge. Performans göstergeleri belirli bir hedefe özeldir ve genellikle ortaya çıkan eylem planının küresel etkinliğini hesaplamak için kullanılır.
Etkinlik Spesifikasyonu İlgili Hedefe ulaşmak için bir stratejinin kendi çözümünde başarması gereken çeşitli performans göstergelerini tanımlayan, her Hedefle ilişkili bir dizi spesifik özelliktir. Aslında, strateji tarafından önerilen her çözüm, küresel etkililiği hesaplanmadan önce spesifikasyona göre kontrol edilecektir.
Puanlama Motoru iyi tanımlanmış girdilere ve iyi tanımlanmış çıktılara sahip olan ve tamamen matematiksel bir görevi gerçekleştiren yürütülebilir bir dosyadır. Bu şekilde hesaplama, yapıldığı ortamdan bağımsız olur; her yerde aynı sonucu verir.
İzleyici Planlayıcı - Watcher karar verme motorunun bir parçası. Bu modül, bir strateji tarafından oluşturulan bir dizi eylemi alır ve bu farklı eylemlerin zamanında nasıl planlanacağını ve her eylem için ön koşulların neler olduğunu belirten bir iş akışı planı oluşturur.
İzleyicinin Hedefleri ve Stratejileri
Gol
strateji
Sahte gol
Kukla Strateji
Örnek Puanlama Motorlarını kullanan Sahte Strateji
Yeniden boyutlandırmayla sahte strateji
Enerji tasarrufu
Enerji Tasarrufu Stratejisi
Sunucu Konsolidasyonu
Temel Çevrimdışı Sunucu Konsolidasyonu
VM İş Yükü Konsolidasyon Stratejisi
İş Yükü Dengeleme
İş Yükü Dengesi Geçiş Stratejisi
Depolama Kapasitesi Denge Stratejisi
İş yükü stabilizasyonu
Gürültülü Komşu
Gürültülü Komşu
Termal Optimizasyon
Çıkış sıcaklığına dayalı strateji
Hava Akışı Optimizasyonu
Tek tip hava akışı geçiş stratejisi
Donanım bakımı
Bölge geçişi
sınıflandırılmamış
Çalıştırıcı
Sahte gol — test amacıyla kullanılan ayrılmış hedef.
İlgili stratejiler: Sahte Strateji, Örnek Puanlama Motorlarını kullanan Yapay Strateji ve yeniden boyutlandırmalı Yapay strateji. Kukla strateji, Tempest aracılığıyla entegrasyon testi için kullanılan sahte bir stratejidir. Bu strateji herhangi bir yararlı optimizasyon sağlamaz, tek amacı Tempest testlerini kullanmaktır.
Örnek Puanlama Motorlarını kullanan kukla strateji - strateji öncekine benzer, tek fark, makine öğrenimi yöntemlerini kullanarak hesaplamalar yapan örnek bir "puanlama motorunun" kullanılmasıdır.
Yeniden boyutlandırma ile kukla strateji - strateji öncekine benzer, tek fark, tadı değiştirmenin kullanılmasıdır (geçiş ve yeniden boyutlandırma).
Üretimde kullanılmaz.
Enerji tasarrufu — enerji tüketimini en aza indirin. Bu hedefin Enerji Tasarrufu Stratejisi, VM İş Yükü Birleştirme Stratejisi (Sunucu Birleştirme) ile birlikte, düşük kaynak kullanımının olduğu dönemlerde bile iş yüklerini dinamik olarak birleştirerek enerji tasarrufu sağlayan dinamik güç yönetimi (DPM) özelliklerine sahiptir: sanal makineler daha az düğüme taşınır ve gereksiz düğümler devre dışı bırakılır. Konsolidasyondan sonra strateji, belirtilen parametrelere uygun olarak düğümleri açma/kapama konusunda bir karar sunar: "min_free_hosts_num" - yüklenmeyi bekleyen ücretsiz etkin düğümlerin sayısı ve "free_used_percent" - ücretsiz etkin ana bilgisayarların yüzdesi Makinelerin işgal ettiği düğüm sayısı. Stratejinin işe yaraması için olması gerekenler Ironic'i düğümlerdeki güç döngüsünü yönetecek şekilde etkinleştirdi ve yapılandırdı.
Strateji parametreleri
parametre
tip
Varsayılan olarak
описание
free_used_percent
Numara
10.0
serbest bilgi işlem düğümlerinin sayısının sanal makinelere sahip bilgi işlem düğümlerinin sayısına oranı
min_free_hosts_num
Int
1
minimum sayıda ücretsiz bilgi işlem düğümü
Bulutta en az iki düğüm bulunmalıdır. Kullanılan yöntem, düğümün güç durumunu değiştirmektir (change_node_power_state). Strateji, metriklerin toplanmasını gerektirmez.
Sunucu Konsolidasyonu - bilgi işlem düğümlerinin sayısını en aza indirin (konsolidasyon). İki stratejisi vardır: Temel Çevrimdışı Sunucu Birleştirme ve VM İş Yükü Birleştirme Stratejisi.
Temel Çevrimdışı Sunucu Birleştirme stratejisi, kullanılan toplam sunucu sayısını en aza indirir ve ayrıca geçiş sayısını da en aza indirir.
Temel strateji aşağıdaki ölçümleri gerektirir:
metrik
ofis
eklentiler
yorum
compute.node.cpu.percent
Yok
cpu_util
Yok
Strateji parametreleri: migrasyon_attempts - potansiyel kapatma adaylarını aramak için kullanılan kombinasyon sayısı (varsayılan, 0, kısıtlama yok), dönem - metrik veri kaynağından statik toplama elde etmek için saniye cinsinden zaman aralığı (varsayılan, 700).
Kullanılan yöntemler: geçiş, nova hizmet durumunun değiştirilmesi (change_nova_service_state).
VM İş Yükü Konsolidasyon Stratejisi, ölçülen CPU yüküne odaklanan ve kaynak kapasitesi kısıtlamaları göz önüne alındığında çok fazla veya çok az yüke sahip düğümleri en aza indirmeye çalışan ilk uygun buluşsal yöntemi temel alır. Bu strateji, aşağıdaki dört adımı kullanarak küme kaynaklarının daha verimli kullanılmasıyla sonuçlanan bir çözüm sağlar:
- Boşaltma aşaması - aşırı kullanılan kaynakların işlenmesi;
- Konsolidasyon aşaması - az kullanılan kaynakların yönetimi;
- Çözümün optimizasyonu - geçiş sayısının azaltılması;
- Kullanılmayan bilgi işlem düğümleri devre dışı bırakılıyor.
Strateji aşağıdaki ölçümleri gerektirir:
metrik
ofis
eklentiler
yorum
bellek
Yok
disk.root.size
Yok
Aşağıdaki metrikler isteğe bağlıdır ancak mevcutsa strateji doğruluğunu artıracaktır:
metrik
ofis
eklentiler
yorum
bellek.yerleşik
Yok
cpu_util
Yok
Strateji parametreleri: dönem — metrik veri kaynağından statik toplama elde etmek için saniye cinsinden zaman aralığı (varsayılan, 3600).
Önceki stratejiyle aynı yöntemleri kullanır. Daha fazla detay .
İş Yükü Dengeleme — bilgi işlem düğümleri arasındaki iş yükünü dengeleyin. Hedefin üç stratejisi var: İş Yükü Dengesi Geçiş Stratejisi, İş Yükü stabilizasyonu, Depolama Kapasitesi Denge Stratejisi.
İş Yükü Dengesi Geçiş Stratejisi, sanal makine geçişlerini ana bilgisayar sanal makinesinin iş yüküne göre çalıştırır. Bir düğümün CPU veya RAM kullanım yüzdesi belirtilen eşiği aştığında geçiş kararı verilir. Bu durumda, taşınan sanal makinenin, düğümü tüm düğümlerin ortalama iş yüküne yaklaştırması gerekir.
Gereksinimler
- Fiziksel işlemcilerin kullanımı;
- En az iki fiziksel bilgi işlem düğümü;
- Her hesaplama düğümünde çalışan Ceilometer bileşeni - ceilometer-agent-compute ve Ceilometer API'si yüklenip yapılandırıldı ve ayrıca aşağıdaki ölçümler toplandı:
metrik
ofis
eklentiler
yorum
cpu_util
Yok
bellek.yerleşik
Yok
Strateji parametreleri:
parametre
tip
Varsayılan olarak
описание
metrikleri
dizi
'cpu_util'
Temel ölçümler şunlardır: 'cpu_util', 'memory.resident'.
eşik
Numara
25.0
Geçiş için iş yükü eşiği.
dönem
Numara
300
Kümülatif zaman dilimi Ceilometer.
Kullanılan yöntem göçtür.
İş yükü stabilizasyonu, canlı geçiş kullanarak iş yükünü stabil hale getirmeyi amaçlayan bir stratejidir. Strateji, standart sapma algoritmasına dayanmaktadır ve kümede tıkanıklık olup olmadığını belirler ve kümeyi stabilize etmek için makine geçişini tetikleyerek buna yanıt verir.
Gereksinimler
- Fiziksel işlemcilerin kullanımı;
- En az iki fiziksel bilgi işlem düğümü;
- Her hesaplama düğümünde çalışan Ceilometer bileşeni - ceilometer-agent-compute ve Ceilometer API'si yüklenip yapılandırıldı ve ayrıca aşağıdaki ölçümler toplandı:
metrik
ofis
eklentiler
yorum
cpu_util
Yok
bellek.yerleşik
Yok
Depolama Kapasitesi Denge Stratejisi (Queens'ten başlayarak uygulanan strateji) - strateji, Kül havuzlarındaki yüke bağlı olarak diskleri aktarır. Havuz kullanım oranı belirlenen eşiği aştığında transfer kararı verilir. Taşınan disk, havuzu tüm Kül havuzlarının ortalama yüküne yaklaştırmalıdır.
Gereksinimler ve kısıtlamalar
- Minimum iki Kül havuzu;
- Disk taşıma olanağı.
- Küme veri modeli - Kül kümesi veri modeli toplayıcı.
Strateji parametreleri:
parametre
tip
Varsayılan olarak
описание
hacim_threshold
Numara
80.0
Birimleri dengelemek için disklerin eşik değeri.
Kullanılan yöntem disk geçişidir (volume_migrate).
Gürültülü Komşu - Son Düzey Önbelleği aşırı kullanarak IPC açısından yüksek öncelikli bir sanal makinenin performansını olumsuz yönde etkileyen düşük öncelikli bir sanal makine olan "gürültülü bir komşuyu" tanımlayın ve taşıyın. Kendi stratejisi: Gürültülü Komşu (kullanılan strateji parametresi önbellek_threshold'dur (varsayılan değer 35'tir), performans belirtilen değere düştüğünde geçiş başlatılır. Stratejinin çalışması için etkinleştirilir LLC (Son Seviye Önbellek) metrikleri, CMT destekli en yeni Intel sunucusuve aşağıdaki metrikleri toplamanın yanı sıra:
metrik
ofis
eklentiler
yorum
cpu_l3_cache
Yok
Intel gerekli .
Küme veri modeli (varsayılan): Nova küme veri modeli toplayıcı. Kullanılan yöntem göçtür.
Kontrol Paneli aracılığıyla bu hedef doğrultusunda çalışmak Queens'te tam olarak uygulanmamaktadır.
Termal Optimizasyon — sıcaklık rejimini optimize edin. Çıkış (egzoz havası) sıcaklığı, bir sunucunun termal/iş yükü durumunu ölçmek için önemli termal telemetri sistemlerinden biridir. Hedefin, kaynak ana bilgisayarların çıkış sıcaklığı yapılandırılabilir bir eşiğe ulaştığında iş yüklerini termal olarak uygun ana bilgisayarlara (en düşük çıkış sıcaklığı) geçirmeye karar veren Çıkış sıcaklığına dayalı strateji olan bir stratejisi vardır.
Stratejinin çalışması için Intel Power Node Manager'ın kurulu ve yapılandırılmış olduğu bir sunucuya ihtiyacınız var ve aşağıdaki metrikleri toplamanın yanı sıra:
metrik
ofis
eklentiler
yorum
hardware.ipmi.node.outlet_temperature
IPMI
Strateji parametreleri:
parametre
tip
Varsayılan olarak
описание
eşik
Numara
35.0
Göç için sıcaklık eşiği.
dönem
Numara
30
Metrik veri kaynağından istatistiksel toplamanın elde edilmesi için saniye cinsinden zaman aralığı.
Kullanılan yöntem göçtür.
Hava Akışı Optimizasyonu — havalandırma modunu optimize edin. Kendi stratejisi - Canlı geçişi kullanan Tekdüzen Hava Akışı. Bu strateji, sunucu fanından gelen hava akışı belirli bir eşiği aştığında sanal makine geçişini tetikler.
Stratejinin işe yaraması için şunlara ihtiyacınız var:
- Donanım: bilgi işlem düğümleri < NodeManager 3.0'ı destekler;
- En az iki bilgi işlem düğümü;
- Hava akışı, sistem gücü, giriş sıcaklığı gibi ölçümleri başarıyla raporlayabilen, her bilgi işlem düğümünde kurulu ve yapılandırılmış Ceilometer-agent-compute ve Ceilometer API bileşeni:
metrik
ofis
eklentiler
yorum
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Stratejinin işe yaraması için Intel Power Node Manager 3.0 veya sonraki sürümünün yüklü ve yapılandırılmış olduğu bir sunucuya ihtiyacınız var.
Sınırlamalar: Konsept üretim amaçlı değildir.
Her yinelemede yalnızca bir sanal makinenin taşınması planlandığından bu algoritmanın sürekli denetimlerle kullanılması önerilmektedir.
Canlı göçler mümkündür.
Strateji parametreleri:
parametre
tip
Varsayılan olarak
описание
eşik_hava akışı
Numara
400.0
Birim geçişi için hava akışı eşiği 0.1 CFM'dir
eşik_inlet_t
Numara
28.0
Geçiş kararı için giriş sıcaklığı eşiği
eşik_gücü
Numara
350.0
Geçiş kararı için sistem güç eşiği
dönem
Numara
30
Metrik veri kaynağından istatistiksel toplamanın elde edilmesi için saniye cinsinden zaman aralığı.
Kullanılan yöntem göçtür.
Donanım Bakımı — donanım bakımı. Bu hedefle ilgili strateji ise Bölge göçüdür. Strateji, donanım bakımına ihtiyaç duyulması durumunda sanal makinelerin ve disklerin etkili, otomatik ve minimum düzeyde geçişini sağlayan bir araçtır. Strateji, ağırlıklara uygun bir eylem planı oluşturur: Daha fazla ağırlığa sahip bir dizi eylem diğerlerinden önce planlanacaktır. İki yapılandırma seçeneği vardır: action_weights ve paralelleştirme.
Sınırlamalar: eylem ağırlıkları ve paralelleştirmenin yapılandırılması gerekir.
Strateji parametreleri:
parametre
tip
Varsayılan olarak
описание
hesaplama_node'ları
dizi
Hayır
Geçiş için bilgi işlem düğümleri.
depolama_havuzları
dizi
Hayır
Geçiş için depolama düğümleri.
paralel_toplam
tamsayı
6
Paralel olarak yürütülmesi gereken toplam aktivite sayısı.
paralel_per_node
tamsayı
2
Her hesaplama düğümü için paralel olarak gerçekleştirilen eylemlerin sayısı.
paralel_per_pool
tamsayı
2
Her depolama havuzu için paralel olarak gerçekleştirilen eylemlerin sayısı.
öncelik
nesne
Hayır
Sanal makineler ve diskler için öncelik listesi.
with_attached_volume
boole
Yanlış
Yanlış—sanal makineler, tüm diskler taşındıktan sonra taşınacaktır. Doğru—sanal makineler, bağlı tüm diskler taşındıktan sonra taşınacaktır.
Bilgi işlem düğümleri dizisinin öğeleri:
parametre
tip
Varsayılan olarak
описание
kaynak_node
dizi
Hayır
Sanal makinelerin geçirildiği işlem düğümü (gerekli).
dst_node
dizi
Hayır
Sanal makinelerin taşınacağı düğümü hesaplayın.
Depolama düğümü dizisi öğeleri:
parametre
tip
Varsayılan olarak
описание
kaynak_pool
dizi
Hayır
Disklerin geçirildiği depolama havuzu (gerekli).
dst_pool
dizi
Hayır
Disklerin taşındığı depolama havuzu.
kaynak_tipi
dizi
Hayır
Orijinal disk türü (gerekli).
dst_type
dizi
Hayır
Ortaya çıkan disk türü (gerekli).
Nesne öncelik öğeleri:
parametre
tip
Varsayılan olarak
описание
proje
dizi
Hayır
Proje adları.
hesaplama_nodeu
dizi
Hayır
Düğüm adlarını hesaplayın.
depolama_havuzu
dizi
Hayır
Depolama havuzu adları.
hesaplamak
enum
Hayır
Sanal makine parametreleri [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
hafızası
enum
Hayır
Disk parametreleri [“size”, “created_at”].
Kullanılan yöntemler sanal makine geçişi, disk geçişidir.
sınıflandırılmamış - strateji geliştirme sürecini kolaylaştırmak için kullanılan yardımcı bir hedef. Hiçbir spesifikasyon içermez ve stratejinin henüz mevcut bir hedefle ilişkilendirilmediği durumlarda kullanılabilir. Bu hedef aynı zamanda bir geçiş noktası olarak da kullanılabilir. Bu hedefle ilgili bir strateji de Aktüatördür.
Yeni bir hedef oluşturmak
İzleyici Karar Motoru bir strateji kullanılarak ulaşılabilecek harici bir hedefi entegre etmeyi mümkün kılan bir "harici hedef" eklenti arayüzüne sahiptir.
Yeni bir hedef oluşturmadan önce mevcut hedeflerden hiçbirinin ihtiyaçlarınızı karşılamadığından emin olmalısınız.
Yeni bir eklenti oluşturma
Yeni bir hedef oluşturmak için şunları yapmalısınız: hedef sınıfı genişletmeli, bir sınıf yöntemi uygulamalı get_name() oluşturmak istediğiniz yeni hedefin benzersiz kimliğini döndürmek için. Bu benzersiz tanımlayıcının daha sonra bildireceğiniz giriş noktası adıyla eşleşmesi gerekir.
Daha sonra sınıf yöntemini uygulamanız gerekir get_display_name() oluşturmak istediğiniz hedefin çevrilmiş görünen adını döndürmek için (çevrilmiş dizeyi döndürmek için bir değişken kullanmayın, böylece çeviri aracı tarafından otomatik olarak toplanabilsin.).
Bir sınıf yöntemini uygulama get_translatable_display_name()yeni hedefinizin çeviri anahtarını (aslında İngilizce görünen adı) döndürmek için. Dönüş değeri get_display_name() işlevine çevrilen dizeyle eşleşmelidir.
Onun yöntemini uygula get_efficacy_specation()hedefinize yönelik verimlilik spesifikasyonunu döndürmek için. get_efficacy_specation() yöntemi, Watcher tarafından sağlanan Unclassified() örneğini döndürür. Bu performans spesifikasyonu, boş spesifikasyona karşılık geldiğinden hedefinizi geliştirme sürecinde faydalıdır.
→
İzleyici mimarisi (daha fazla ayrıntı) ).
Bileşenleri
İzleyici API'si - Watcher tarafından sağlanan REST API'yi uygulayan bir bileşen. Etkileşim mekanizmaları: CLI, Horizon eklentisi, Python SDK.
İzleyici Veritabanı — İzleyici veritabanı.
İzleyici Uygulayıcı — Watcher Decision Engine bileşeni tarafından oluşturulan bir eylem planının uygulanmasını uygulayan bir bileşen.
İzleyici Karar Motoru - Denetim hedefine ulaşmak için bir dizi potansiyel optimizasyon eyleminin hesaplanmasından sorumlu bileşen. Bir strateji belirtilmemişse bileşen bağımsız olarak en uygun olanı seçer.
İzleyici Metrikleri Yayıncısı - Bazı metrikleri veya olayları toplayıp hesaplayan ve bunları CEP uç noktasında yayınlayan bir bileşen. Bileşenin işlevselliği Ceilometer yayıncısı tarafından da sağlanabilir.
Karmaşık Olay İşleme (CEP) Motoru — karmaşık olay işlemeye yönelik motor. Performans nedenleriyle, her biri belirli bir ölçüm/olay türünü işleyen, aynı anda çalışan birden fazla CEP Motoru örneği olabilir. Watcher sisteminde CEP iki tür eylemi tetikler: - ilgili olayları/metrikleri zaman serisi veritabanına kaydedin; - Openstack kümesi statik bir sistem olmadığından, bu olay mevcut optimizasyon stratejisinin sonucunu etkileyebileceğinde uygun olayları Watcher Decision Engine'e gönderin.
Bileşenler AMQP protokolünü kullanarak etkileşime girer.
→
Watcher ile etkileşim şeması
İzleyici testi sonuçları
- Optimizasyon - Eylem planları 500 sayfasında (hem saf Queens'te hem de Tionix modülleri içeren bir standda), yalnızca denetim başlatıldıktan ve bir eylem planı oluşturulduktan sonra görünür; boş olan normal şekilde açılır.
- Eylem ayrıntıları sekmesinde hatalar var, denetim hedefini ve stratejisini elde etmek mümkün değil (hem saf Queens'te hem de Tionix modülleri bulunan bir standda).
- Dummy (test) amaçlı denetimler normal şekilde oluşturulup başlatılır, aksiyon planları oluşturulur.
- Sınıflandırılmamış hedefe yönelik denetimler, hedefin işlevsel olmaması ve yeni stratejiler oluşturulurken ara yapılandırmaya yönelik olması nedeniyle oluşturulmaz.
- İş Yükü Dengeleme (Depolama Kapasitesi dengeleme stratejisi) amacıyla yapılan denetimler başarıyla oluşturuldu ancak aksiyon planı oluşturulamadı. Depolama havuzu optimizasyonuna gerek yoktur.
- İş Yükü Dengeleme hedefine (İş Yükü Dengesi Geçiş Stratejisi) yönelik denetimler başarıyla oluşturuldu ancak bir eylem planı oluşturulmuyor.
- İş Yükü Dengeleme Denetimleri (İş Yükü Dengeleme Stratejisi) başarısız oluyor.
- Gürültülü Komşu hedefine yönelik denetimler başarıyla oluşturuldu ancak eylem planı oluşturulamadı.
- Donanım bakımı amacıyla yapılan denetimler başarıyla oluşturuluyor, eylem planı tam olarak oluşturulamıyor (performans göstergeleri oluşturuluyor ancak eylemlerin listesi oluşturulamıyor).
- Bilgi işlem ve kontrol düğümlerindeki nova.conf yapılandırmalarında (varsayılan bölümde compute_monitors = cpu.virt_driver) yapılan düzenlemeler hataları düzeltmez.
- Sunucu Birleştirmesini (Temel strateji) hedefleyen denetimler de başarısız olur.
- Sunucu Birleştirme (VM iş yükü birleştirme stratejisi) amacıyla yapılan denetimler bir hatayla başarısız olur. Günlüklerde kaynak verilerin alınmasında bir hata var. Özellikle hatanın tartışılması .
Config dosyasında Watcher'ı belirtmeye çalıştık (yardım etmedi - tüm Optimizasyon sayfalarındaki bir hatanın sonucu olarak, konfigürasyon dosyasının orijinal içeriğine geri dönmek durumu düzeltmedi): [watcher_strategies.basic] veri kaynağı = seilometre, gnocchi - Enerji Tasarrufuna yönelik denetimler başarısız oluyor. Günlüklere bakılırsa sorun hala Ironic'in olmaması; çıplak metal hizmeti olmadan çalışmayacak.
- Termal Optimizasyon denetimleri başarısız olur. Geri izleme, Sunucu Birleştirme (VM iş yükü birleştirme stratejisi) ile aynıdır (kaynak veri hatası)
- Hava Akışı Optimizasyonu amacıyla yapılan denetimler bir hatayla başarısız olur.
Aşağıdaki denetim tamamlama hatalarıyla da karşılaşılır. Decision-engine.log günlüklerinde geri izleme (küme durumu tanımlanmamıştır).
→ Hatanın tartışılması
Sonuç
İki aylık araştırmamızın sonucu, tam teşekküllü, çalışan bir yük dengeleme sistemi elde etmek için bu bölümde Openstack platformuna yönelik araçları geliştirmek üzere yakın çalışmamız gerektiği yönünde kesin bir sonuçtu.
Watcher, tam kullanımı çok ciddi çalışma gerektirecek, muazzam potansiyele sahip, ciddi ve hızla gelişen bir ürün olduğunu kanıtladı.
Ancak serinin sonraki makalelerinde bu konuda daha fazla bilgi bulacaksınız.
Kaynak: habr.com