Walidacja i testy systemu DRAS (Dynamic Resource Allocation System).

Autor: Damian Lemiech, Karol Grzywacz, Radosław Kościołek
Afiliacja: Small Business System Damian Lemiech
Data wydania: 2024
Seria/numer raportu: 02/2024/DRAS
Typ: artykuł
Licencja Creative Commons: CC BY-NC 4.0

Część I: Testy bazowe i przekrojowe oraz badanie bezpośredniego wpływu zmian alokacji zasobów na możliwości oszczędności energii.

Opracowanie dotyczy uzupełniających prac badawczo-rozwojowych, wykorzystujących wcześniejszą realizację etapu przygotowawczego (TRL 1) i fazy eksploracyjnej (TRL 2, TRL 3), modyfikujących jednak etap projektowania rozwiązań (TRL 4, TRL 5).

Streszczenie: Alokacja zasobów dla usług chmurowych zazwyczaj ma charakter statyczny lub możliwe jest automatyczne zwiększenie zasobów przy pewnych warunkach. Celem jest wtedy utrzymanie stabilności realizacji usługi, a nie oszczędności. Zasadne jest pytanie: czy automatyzacja dostosowania ilości zasobów do bieżącego zapotrzebowania przez usługi, może przynieść korzyści lub oszczędności? Wykonano w tym zakresie prace B+R, których rezultatem jest prototyp Systemu Dynamicznej Alokacji Zasobów. Poszczególne elementy systemu zostały przetestowane, tworząc serię badań przedstawioną w cyklu trzech krótkich publikacji, skupiających się na konkretnych aspektach. Pierwsza część przedstawia wyniki badań, które scharakteryzowano jako bazowe i przekrojowe, ze względu na ich metodologię i próbę ukazania ewentualnych korelacji, przy maksymalnie ograniczonym wpływie czynników pobocznych. Przedstawione wyniki badań obrazują proste korelacje, które pozwalają myśleć o możliwych optymalizacjach. Przedstawiono również wyniki badania wpływu zmiany alokacji zasobów wirtualnych maszyn na pobór mocy przez serwer. Badanie stanowi bardzo dobrą ilustrację typowych sytuacji, w których zmiana alokacji zasobów jest zasadna i wpływa na ograniczenie zużycia energii elektrycznej przez serwer. Pozwala to pozytywnie odpowiedź na pytanie zadane powyżej i doprowadziło realizację prac B+R to zamierzonego celu, czyli opracowania koncepcji i prototypu Systemy Dynamicznej Alokacji Zasobów. Wszystkie badania zostały przeprowadzone w środowisku laboratoryjnym w warunkach symulujących rzeczywiste.

Wstęp

Dynamika współczesnego rynku hostingowego i wirtualizacji serwerów wymaga ciągłego doskonalenia strategii zarządzania zasobami w celu zapewnienia optymalnej wydajności i elastyczności usług. Współczesne usługi hostingowe i wirtualizacji serwerów narażone są na zmienne obciążenie, wynikające z dynamicznych potrzeb użytkowników oraz zmiennych warunków działania aplikacji, serwisów internetowych i serwerów. W związku z tym postawiono pytania:

· Czy automatyzacja dostosowania ilości zasobów do bieżącego zapotrzebowania przez usługi, może przynieść korzyści lub oszczędności?

· W jakich obszarach można poszukiwać zalet i przewag automatycznego zarządzania alokacją zasobów?

· Czy można skutecznie prognozować wykorzystanie zasobów przez usługi serwerowe, np. przy zastosowaniu modeli uczenia maszynowego?

Prace badawczo-rozwojowe

W ramach prac przygotowawczych zebrano wiedzę w zakresie charakterystyki procesu zmiany alokacji zasobów przydzielonych usługom i rozwiązań automatyzujących ten proces. Poszerzono również wiedzę w zakresie narzędzi monitorujących wykorzystanie zasobów serwera i usług oraz w zakresie modeli uczenia maszynowego dedykowanych prognozowaniu wyników. Dokonano przeglądu dostępnych technologii i narzędzi do monitorowania serwera i usług. Opracowano wstępne koncepcje architektury Systemu Dynamicznej Alokacji Zasobów, uwzględniające zdobytą wiedzę. Zidentyfikowano kluczowe problemy technologiczne i potencjalne ryzyka.

Prace eksploracyjne objęły pogłębione analizy i testy laboratoryjne technologii zidentyfikowanych jako potencjalnie przydatne do zastosowania w projektowaniu rozwiązania. Dopracowano koncepcję architektury Systemu Dynamicznej Alokacji Zasobów. Przeprowadzono wstępne testy implementacyjne poszczególnych procesów i funkcjonalności.

W ramach projektowania rozwiązań opracowano prototyp Systemu Dynamicznej Alokacji Zasobów, realizujący 4 główne procesy: akwizycji danych, analizy danych, diagnostyki usług, automatycznej modyfikacji usług. Do implementacji wykorzystano m.in. technologie: Python, TensorFlow, PHP, Laravel, PostgreSQL, oraz API źródeł danych: Proxmox i Redfish. Wykonano testy w środowisku laboratoryjnym, również w warunkach symulujących rzeczywiste.

Bazą do badań był serwer modelu Lenovo ThinkSystem SR665, w którym zainstalowano jeden procesor AMD EPYC 7402 (z możliwością dołożenia drugiego procesora w przyszłości), 4 kości pamięci RAM DDR4 po 64GB każda, 6 dysków twardych o łącznej pojemności około 9TB, 10 wentylatorów, 2 zasilacze (o mocy znamionowej 750W każdy) oraz 6 adapterów PCI, w których skład wchodzi np. adapter sieciowy Lenovo ThinkSystem Broadcom 57454 i kontrolery SATA/NVMe/RAID. Do zarządzania serwerem zainstalowano Lenovo XClarity Controller (XCC), który zastępuje kontroler zarządzania płytą główną (BMC) w serwerach Lenovo ThinkSystem. W skład XCC wchodzi serwer Redfish, który udostępnia dane pomiarowe i ogólne informacje sprzętowe głównego serwera.

Wizualizacje wyników badań i ilustracje niektórych testów (część I)

Na podstawie danych zbieranych w procesie akwizycji wykonane zostały testy bazowe, mające na celu zobrazowanie intuicyjnych zależności między poziomem wykorzystania zasobów procesora i pamięci RAM jednej wirtualnej maszyny, a całkowitym zużyciem energii przez serwer.

Test 1:

Badanie poziomu zużycia energii przez serwer podczas obciążania zasobów procesora przypisanych wirtualnej maszynie, na kolejnych poziomach: 100, 75, 50 i 25%, zwiększając ilość przydzielonych rdzeni procesora po każdej serii ustawień poziomów.

Metodologia: Testy zostały wykonane na maszynie wirtualnej z zainstalowanym systemem operacyjnym Ubuntu (Linux), przy zastosowaniu programu stress-ng. Komenda uruchamiająca procesy: stress-ng --cpu x --cpu-load y --cpu-method cdouble --timeout 30m –metrics, gdzie: x - ilość wątków (workerów) obciążających procesor, y - procentowe obciążenie na instancję (workera). Przykładowe działanie procesu:

Streszczenie: Alokacja zasobów dla usług chmurowych zazwyczaj ma charakter statyczny lub możliwe jest automatyczne zwiększenie zasobów przy pewnych warunkach. Celem jest wtedy utrzymanie stabilności realizacji usługi, a nie oszczędności. Zasadne jest pytanie: czy automatyzacja dostosowania ilości zasobów do bieżącego zapotrzebowania przez usługi, może przynieść korzyści lub oszczędności? Wykonano w tym zakresie prace B+R, których rezultatem jest prototyp Systemu Dynamicznej Alokacji Zasobów. Poszczególne elementy systemu zostały przetestowane, tworząc serię badań przedstawioną w cyklu trzech krótkich publikacji, skupiających się na konkretnych aspektach. Pierwsza część przedstawia wyniki badań, które scharakteryzowano jako bazowe i przekrojowe, ze względu na ich metodologię i próbę ukazania ewentualnych korelacji, przy maksymalnie ograniczonym wpływie czynników pobocznych. Przedstawione wyniki badań obrazują proste korelacje, które pozwalają myśleć o możliwych optymalizacjach. Przedstawiono również wyniki badania wpływu zmiany alokacji zasobów wirtualnych maszyn na pobór mocy przez serwer. Badanie stanowi bardzo dobrą ilustrację typowych sytuacji, w których zmiana alokacji zasobów jest zasadna i wpływa na ograniczenie zużycia energii elektrycznej przez serwer. Pozwala to pozytywnie odpowiedź na pytanie zadane powyżej i doprowadziło realizację prac B+R to zamierzonego celu, czyli opracowania koncepcji i prototypu Systemy Dynamicznej Alokacji Zasobów. Wszystkie badania zostały przeprowadzone w środowisku laboratoryjnym w warunkach symulujących rzeczywiste.

Wstęp

Dynamika współczesnego rynku hostingowego i wirtualizacji serwerów wymaga ciągłego doskonalenia strategii zarządzania zasobami w celu zapewnienia optymalnej wydajności i elastyczności usług. Współczesne usługi hostingowe i wirtualizacji serwerów narażone są na zmienne obciążenie, wynikające z dynamicznych potrzeb użytkowników oraz zmiennych warunków działania aplikacji, serwisów internetowych i serwerów. W związku z tym postawiono pytania:

· Czy automatyzacja dostosowania ilości zasobów do bieżącego zapotrzebowania przez usługi, może przynieść korzyści lub oszczędności?

· W jakich obszarach można poszukiwać zalet i przewag automatycznego zarządzania alokacją zasobów?

· Czy można skutecznie prognozować wykorzystanie zasobów przez usługi serwerowe, np. przy zastosowaniu modeli uczenia maszynowego?

Prace badawczo-rozwojowe

W ramach prac przygotowawczych zebrano wiedzę w zakresie charakterystyki procesu zmiany alokacji zasobów przydzielonych usługom i rozwiązań automatyzujących ten proces. Poszerzono również wiedzę w zakresie narzędzi monitorujących wykorzystanie zasobów serwera i usług oraz w zakresie modeli uczenia maszynowego dedykowanych prognozowaniu wyników. Dokonano przeglądu dostępnych technologii i narzędzi do monitorowania serwera i usług. Opracowano wstępne koncepcje architektury Systemu Dynamicznej Alokacji Zasobów, uwzględniające zdobytą wiedzę. Zidentyfikowano kluczowe problemy technologiczne i potencjalne ryzyka.

Prace eksploracyjne objęły pogłębione analizy i testy laboratoryjne technologii zidentyfikowanych jako potencjalnie przydatne do zastosowania w projektowaniu rozwiązania. Dopracowano koncepcję architektury Systemu Dynamicznej Alokacji Zasobów. Przeprowadzono wstępne testy implementacyjne poszczególnych procesów i funkcjonalności.

W ramach projektowania rozwiązań opracowano prototyp Systemu Dynamicznej Alokacji Zasobów, realizujący 4 główne procesy: akwizycji danych, analizy danych, diagnostyki usług, automatycznej modyfikacji usług. Do implementacji wykorzystano m.in. technologie: Python, TensorFlow, PHP, Laravel, PostgreSQL, oraz API źródeł danych: Proxmox i Redfish. Wykonano testy w środowisku laboratoryjnym, również w warunkach symulujących rzeczywiste.

Bazą do badań był serwer modelu Lenovo ThinkSystem SR665, w którym zainstalowano jeden procesor AMD EPYC 7402 (z możliwością dołożenia drugiego procesora w przyszłości), 4 kości pamięci RAM DDR4 po 64GB każda, 6 dysków twardych o łącznej pojemności około 9TB, 10 wentylatorów, 2 zasilacze (o mocy znamionowej 750W każdy) oraz 6 adapterów PCI, w których skład wchodzi np. adapter sieciowy Lenovo ThinkSystem Broadcom 57454 i kontrolery SATA/NVMe/RAID. Do zarządzania serwerem zainstalowano Lenovo XClarity Controller (XCC), który zastępuje kontroler zarządzania płytą główną (BMC) w serwerach Lenovo ThinkSystem. W skład XCC wchodzi serwer Redfish, który udostępnia dane pomiarowe i ogólne informacje sprzętowe głównego serwera.

Wizualizacje wyników badań i ilustracje niektórych testów (część I)

Na podstawie danych zbieranych w procesie akwizycji wykonane zostały testy bazowe, mające na celu zobrazowanie intuicyjnych zależności między poziomem wykorzystania zasobów procesora i pamięci RAM jednej wirtualnej maszyny, a całkowitym zużyciem energii przez serwer.

Test 1:

Badanie poziomu zużycia energii przez serwer podczas obciążania zasobów procesora przypisanych wirtualnej maszynie, na kolejnych poziomach: 100, 75, 50 i 25%, zwiększając ilość przydzielonych rdzeni procesora po każdej serii ustawień poziomów.

Metodologia: Testy zostały wykonane na maszynie wirtualnej z zainstalowanym systemem operacyjnym Ubuntu (Linux), przy zastosowaniu programu stress-ng. Komenda uruchamiająca procesy: stress-ng --cpu x --cpu-load y --cpu-method cdouble --timeout 30m –metrics, gdzie: x - ilość wątków (workerów) obciążających procesor, y - procentowe obciążenie na instancję (workera). Przykładowe działanie procesu:

a) Seria nr 1:

· VM nr 110,

· 4 GB pamięci RAM,

· 2 rdzenie CPU,

· 2 wątki CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Można zauważyć różnicę między poborem energii przy obciążeniu procesora na 100% i 40%. Średnia różnica wynosi około 10W, co oznacza zmniejszenie o około 6,5% (10/155). Zużycie energii przy obciążeniu procesora na poziomie 60% i 40% jest podobne, a przy 80% jest mniej więcej pośrednie między 100% i 40%. W tym scenariuszu zadane obciążenie jest procentowo nieco wyższe od oczekiwanego, ze względu na niskie zasoby i duży wpływ procesów systemowych, szczególnie powłoki graficznej.

b) Seria nr 2:

· VM nr 110,

· 4 GB pamięci RAM,

· 4 rdzenie CPU,

· 4 wątki CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Dwukrotne zwiększenie przydzielonych rdzeni CPU (z 2 do 4) i obciążenie zasobów procesora na poziomie 100%, zwiększyło zapotrzebowanie energetyczne do około 161W, czyli o około 5W więcej niż przy poprzednich ustawieniach. Obniżenie obciążenia CPU do poziomu 80% spowodowało znaczny spadek zużycia energii, do poziomu podobnego jak przy mniejszych poziomach obciążenia CPU. Średnia różnica między poborem mocy przy 100% i 40% wynosi około 11W, co oznacza zmniejszenie o około 6,8% (11/161). Pobór energii na niższych poziomach zużycia CPU jest większy o około 5W względem poprzednich ustawień. Również w tym scenariuszu zadane obciążenie jest procentowo nieco wyższe od oczekiwanego, ze względu na niskie zasoby i duży wpływ procesów systemowych, szczególnie powłoki graficznej.

c) Seria nr 3:

· VM nr 110,

· 4 GB pamięci RAM,

· 8 rdzeni CPU,

· 8 wątków CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

LKomentarz: Dwukrotne zwiększenie przydzielonych rdzeni CPU (z 4 do 8) i obciążenie zasobów procesora na poziomie 100%, zwiększyło zapotrzebowanie energetyczne do około 185W, czyli o około 24W więcej niż przy poprzednich ustawieniach. Obniżenie obciążenia CPU do poziomu 80% spowodowało znaczny spadek zużycia energii, do poziomu niewiele większego niż przy mniejszych poziomach obciążenia CPU. Średnia różnica między poborem mocy przy 100% i 30% wynosi około 37W, co oznacza zmniejszenie o około 20% (37/185). Pobór energii na niższych poziomach zużycia CPU jest podobny względem poprzednich ustawień. Również w tym scenariuszu zadane obciążenie jest procentowo nieco wyższe od oczekiwanego, ze względu na niskie zasoby i duży wpływ procesów systemowych, szczególnie powłoki graficznej.

d) Seria nr 4:

· VM nr 110,

· 4 GB pamięci RAM,

· 16 rdzeni CPU,

· 16 wątków CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Dwukrotne zwiększenie przydzielonych rdzeni CPU (z 8 do 16) i obciążenie zasobów procesora na poziomie 100%, zwiększyło zapotrzebowanie energetyczne do około 215W, czyli o około 30W więcej niż przy poprzednich ustawieniach. Obniżenie obciążenia CPU do poziomu 75% spowodowało znaczny spadek zużycia energii, do poziomu niewiele większego niż przy mniejszych poziomach obciążenia CPU. Średnia różnica między poborem mocy przy 100% i 28% wynosi około 65W, co oznacza zmniejszenie o około 30,2% (65/215). Pobór energii na niższych poziomach zużycia CPU jest podobny względem poprzednich ustawień.

e) Seria nr 5:

· VM nr 110,

· 4 GB pamięci RAM,

· 32 rdzenie CPU,

· 32 wątki CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Dwukrotne zwiększenie przydzielonych rdzeni CPU (z 16 do 32) i obciążenie zasobów procesora na poziomie 100%, zwiększyło zapotrzebowanie energetyczne do około 245W, czyli o około 30W więcej niż przy poprzednich ustawieniach. Obniżenie obciążenia CPU do poziomu 75% spowodowało spadek zużycia energii, ale do poziomu niewiele mniejszego niż przy 100% CPU. Znacząca różnica w poborze energii jest na poziomie 50% CPU. Średnia różnica między poborem mocy przy 100% i 28% wynosi około 90W, co oznacza zmniejszenie o około 36,7% (90/245). Pobór energii na niższych poziomach zużycia CPU jest większy o około 5W względem poprzednich ustawień.

f) Seria nr 6:

· VM nr 110,

· 4 GB pamięci RAM,

· 48 rdzeni CPU,

· 48 wątków CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Zwiększenie przydzielonych rdzeni CPU (z 32 do 48) i obciążenie zasobów procesora na poziomie 100%, zwiększyło zapotrzebowanie energetyczne do około 255W, czyli o około 10W więcej niż przy poprzednich ustawieniach. Obniżenie obciążenia CPU do poziomu 75% spowodowało prawie niezauważalny spadek zużycia energii. Znacząca różnica w poborze energii jest na poziomie 50% CPU. Średnia różnica między poborem mocy przy 100% i 25% wynosi około 95W, co oznacza zmniejszenie o około 37,3% (95/255). Pobór energii na niższych poziomach zużycia CPU jest większy o około 5W względem poprzednich ustawień.

Podsumowanie: Na podstawie serii testów, z różną ilością rdzeni przydzielanych wirtualnej maszynie, można zauważyć, że największe zapotrzebowanie na energię jest przy maksymalnym obciążeniu CPU. Przydział mniejszej ilości rdzeni (2-16) wskazuje, że ilość pobieranej energii jest prawie na najniższym możliwym poziomie, nawet przy spadku obciążenia CPU do 75%. Natomiast przydział znacznej części dostępnych rdzeni procesora (32-48) wskazuje, że przy obciążeniu 75% CPU, ilość pobieranej energii zmniejsza się w niewielkim stopniu, w porównaniu do obciążenia 100% CPU. Niezależnie od ilości przydzielonych rdzeni, obniżenie obciążenia CPU poniżej 50% wskazuje na znaczne zmniejszenie poboru energii przez serwer. Zatem zwiększenie ilości rdzeni dla wirtualnej maszyny powinno dążyć do obniżenia obciążenia jej zasobów CPU do poziomu około 50%. Dzięki temu oszczędność energii powinna duża, a dalsze obniżanie obciążenia nie będzie dawało już znaczących korzyści. Znalezienie odpowiedniego balansu wymaga wzięcia pod uwagę wielu czynników i wykorzystania odpowiedniego algorytmu do analizy danych.

Test 2:

Badanie poziomu zużycia energii przez serwer podczas obciążania zasobów pamięci RAM przypisanej wirtualnej maszynie, na kolejnych poziomach: 100, 75, 50 i 25%, zwiększając ilość pamięci po każdej serii ustawień poziomów.

Metodologia: Testy zostały wykonane na maszynie wirtualnej z zainstalowanym systemem operacyjnym Ubuntu (Linux), przy zastosowaniu programu stress-ng. Komenda uruchamiająca procesy: stress-ng --vm 1 --vm-bytes x --vm-method all --timeout 30m --vm-keep --metrics, gdzie: x - procentowe wykorzystanie przydzielonej pamięci. Sposób działania procesu jest analogiczny jak podczas testów obciążeniowych procesora.

a) Serie nr 1, 2, 3:

· VM nr 110,

· 8/16/32 GB pamięci RAM,

· 4 rdzenie CPU,

· 4 wątki CPU,

· zadanie RAM: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Przydział stosunkowo niedużych zasobów i obciążanie pamięci w różnym stopniu pokazuje, że ma to niewielki wpływ na poziom zużywanej energii przez serwer. Dla lepszego zobrazowania wyników zestawiono 3 kolejne serie testów na jednym wykresie. Można zauważyć dużą niestabilność przebiegu mocy pobieranej przez serwer, ale generalnie średnie wartości utrzymują się na podobnym poziomie, około 155W.

b) Serie nr 4, 5, 6:

· VM nr 110,

· 64/128/180 GB pamięci RAM,

· 4 rdzenie CPU,

· 4 wątki CPU,

· zadanie RAM: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Przydział większych zasobów pamięciowych i obciążanie pamięci w różnym stopniu, wskazuje na niewielki wpływ względem poziomu zużywanej energii przez serwer. Dla lepszego zobrazowania wyników zestawiono 3 kolejne serie testów na jednym wykresie. Można zauważyć jeszcze większą niestabilność przebiegu mocy pobieranej przez serwer, ale generalnie średnie wartości utrzymują się na podobnym poziomie, około 160W, czyli tylko 5W więcej niż przy małych zasobach.

Podsumowanie: Na podstawie serii testów, z różną ilością pamięci RAM przydzielanej wirtualnej maszynie, można zauważyć, że zapotrzebowanie na energię utrzymuje się na podobnym poziomie niezależnie od obciążenia pamięci RAM. Test miał charakter bazowy, dlatego przydzielono ilość rdzeni procesora typową dla standardowych usług wirtualnych maszyn. Dalsze testy o charakterze przekrojowym wskażą na ewentualne korelacje między większą ilością przydzielonych rdzeni procesora, a różnym obciążeniem pamięci RAM. Wstępnie można wyciągnąć wniosek, że zmiany alokacji zasobów procesora powinny mieć zdecydowanie wyższy priorytet niż zmiany alokacji zasobów pamięci, bo pozwolą uzyskać realne oszczędności energii.

Test 3:

Badanie poziomu zużycia energii przez serwer podczas jednoczesnego obciążania zasobów procesora i pamięci RAM, przypisanych wirtualnej maszynie, na kolejnych poziomach: 100, 75, 50 i 25%, zwiększając ilość przydzielonych zasobów po każdej serii ustawień poziomów.

Metodologia: Testy zostały wykonane na maszynie wirtualnej z zainstalowanym systemem operacyjnym Ubuntu (Linux), przy zastosowaniu programu stress-ng. Komenda uruchamiająca procesy obciążające jednocześnie zasoby procesora i pamięci: stress-ng --cpu x --cpu-load y --cpu-method cdouble --vm 1 --vm-bytes z --vm-method all --timeout 30m --vm-keep --metrics, gdzie: x - ilość wątków (workerów) obciążających procesor, y - procentowe obciążenie CPU, z – procentowe obciążenie pamięci RAM. Sposób działania procesu jest analogiczny jak podczas testów obciążeniowych procesora.

a) Seria nr 1:

· VM nr 110,

· 8 GB pamięci RAM,

· 4 rdzenie CPU,

· 4 wątki CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· zadanie RAM: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Zadane obciążenie jest procentowo nieco wyższe od oczekiwanego, ze względu na niskie zasoby i duży wpływ procesów systemowych, szczególnie powłoki graficznej. Różnica w poborze mocy między najwyższym i najniższym obciążeniem wynosi około 5W (165 - 160), co oznacza zmniejszenie o około 3% (5/165). Wykresy można porównywać z testem nr 1b, ze względu na taką samą ilość rdzeni procesora. W zasadzie podczas tamtego testu pamięć również była obciążona w około 60%, ale znaczenie ma sposób jej obciążania. Stąd lekkie podbicie poboru mocy w analizowanej serii i nieco mniejsze potencjalne oszczędności energii.

b) Seria nr 2:

· VM nr 110,

· 16 GB pamięci RAM,

· 8 rdzeni CPU,

· 8 wątków CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· zadanie RAM: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Podwojenie przydzielonych zasobów względem poprzedniej serii, zwiększyło zapotrzebowanie na energię do około 185W, przy obciążeniu bliskim 100%. Najmniejszy średni pobór energii jaki udało się uzyskać przy obciążeniu bliskim 25%, wyniósł około 160W. Można doszukiwać się podobieństwa z testem 1c, ze względu na taką samą ilość przydzielonych rdzeni procesora. Mimo mniejszej różnicy poboru mocy między obciążeniem 100% i 25%, potencjalna oszczędność energii jest nadal duża i wynosi około 13,5% (25/185). Podbicie poboru mocy wynikające ze specyfiki testu obciążającego pamięć, widoczne jest głównie przy niższym obciążeniu, co wpływa na nieco mniejsze potencjalne oszczędności energii, w porównaniu z testem 1c.

c) Seria nr 3:

· VM nr 110,

· 32 GB pamięci RAM,

· 16 rdzeni CPU,

· 16 wątków CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· zadanie RAM: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min

Komentarz: Podwojenie przydzielonych zasobów względem poprzedniej serii, zwiększyło zapotrzebowanie na energię do około 215W, przy obciążeniu bliskim 100%. Najmniejszy średni pobór energii jaki udało się uzyskać przy obciążeniu bliskim 25%, wyniósł około 160W. Można doszukiwać się podobieństwa z testem 1d, ze względu na taką samą ilość przydzielonych rdzeni procesora. Mimo mniejszej różnicy poboru mocy między obciążeniem 100% i 25%, potencjalna oszczędność energii jest nadal duża i wynosi około 25,6% (55/215). Podbicie poboru mocy wynikające ze specyfiki testu obciążającego pamięć, widoczne jest głównie przy niższym obciążeniu, co wpływa na nieco mniejsze potencjalne oszczędności energii, w porównaniu z testem 1d.

d) Seria nr 4:

· VM nr 110,

· 64 GB pamięci RAM,

· 32 rdzenie CPU,

· 32 wątki CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· zadanie RAM: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Podwojenie przydzielonych zasobów względem poprzedniej serii, zwiększyło zapotrzebowanie na energię do około 250W, przy obciążeniu bliskim 100%. Najmniejszy średni pobór energii jaki udało się uzyskać przy obciążeniu bliskim 25%, wyniósł około 165W. Można doszukiwać się podobieństwa z testem 1e, ze względu na taką samą ilość przydzielonych rdzeni procesora. Mimo mniejszej różnicy poboru mocy między obciążeniem 100% i 25%, potencjalna oszczędność energii jest nadal duża i wynosi około 34% (85/250). Podbicie poboru mocy wynikające ze specyfiki testu obciążającego pamięć, widoczne jest głównie przy niższym obciążeniu, co wpływa na nieco mniejsze potencjalne oszczędności energii, chociaż różnica jest bardzo mała.

e) Seria nr 5:

· VM nr 110,

· 128 GB pamięci RAM,

· 48 rdzeni CPU,

· 48 wątków CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· zadanie RAM: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Przydzielenie całych zasobów CPU i dwukrotnie większych zasobów pamięci RAM, zwiększyło zapotrzebowanie na energię do około 253W, przy obciążeniu bliskim 100%. Najmniejszy średni pobór energii jaki udało się uzyskać przy obciążeniu bliskim 25%, wyniósł około 168W. Można doszukiwać się podobieństwa z testem 1f, ze względu na taką samą ilość przydzielonych rdzeni procesora. Wyznaczone średnie wartości poboru mocy przy obciążeniu na poziomach 100% i 25%, są prawie takie same jak w poprzedniej serii. Potencjalna oszczędność energii wynosi około 33,6% (85/253). Podbicie poboru mocy wynikające ze specyfiki testu obciążającego pamięć, widoczne jest głównie przy niższym obciążeniu, co wpływa na nieco mniejsze potencjalne oszczędności energii, w porównaniu z testem 1f, chociaż różnica jest bardzo mała.

f) Seria nr 6:

· VM nr 110,

· 180 GB pamięci RAM,

· 48 rdzeni CPU,

· 48 wątków CPU,

· zadanie CPU: 100% -> 75% -> 50% -> 25%,

· zadanie RAM: 100% -> 75% -> 50% -> 25%,

· czas trwania jednego poziomu obciążenia: 30 min.

Komentarz: Przydzielenie całych zasobów CPU i prawie całych zasobów pamięci RAM, nie przyniosło prawie żadnych różnic w stosunku do poprzedniej serii. Wyznaczone średnie wartości poboru mocy przy obciążeniu na poziomach 100% i 25%, są takie same jak w poprzedniej serii. Potencjalna oszczędność energii wynosi około 33,6% (85/253).

Podsumowanie: Na podstawie serii testów, z różną ilością rdzeni procesora i pamięci RAM, przydzielanych wirtualnej maszynie, można zauważyć ogromne podobieństwo do serii testów, w których zmieniała się tylko ilość rdzeni. Obciążanie pamięci RAM dedykowanym procesem testowym, spowodowało jedynie niewielkie podwyższenie dolnych granic zakresu zmienności poboru mocy przez serwer. Zwiększona amplituda zmian na poszczególnych poziomach obciążenia wskazuje, że zastosowano inny rodzaj testu, ale szacunkowe obliczenia potencjalnych oszczędności energii opierają się na średnich wartościach dla każdego poziomu. Test miał charakter przekrojowy, aby ukazać ewentualne obszary korelacji między zmienną ilością przydzielonych rdzeni CPU i pamięci RAM, zmiennym obciążeniem CPU i pamięci RAM, oraz poborem energii dla różnych ustawień. Niezależnie od ilości przydzielonych rdzeni, obniżenie obciążenia CPU poniżej 50% wskazuje na znaczne zmniejszenie poboru energii przez serwer. Zwłaszcza w tym zakresie (100% - 50% CPU), dedykowane obciążenie pamięci RAM ma niewielki wpływ na oszczędności energii uzyskiwane ze zmniejszenia obciążenia procesora. Można jednak zauważyć znaczący wpływ poziomu alokacji dostępnych zasobów serwera, zwłaszcza rdzeni procesora. Alokacja minimum 65-70% rdzeni CPU i ich maksymalne obciążenie powoduje zwiększenie poboru mocy do zbadanego maksimum (około 253W). Jednak zmniejszenie obciążenia zasobów, zwłaszcza procesora, powoduje spadek poboru mocy przez serwer do około 175W. To są sytuacje czysto teoretyczne z punktu widzenia serwera, ale potwierdzają że warto alokować dostępne zasoby, wpływając na ogólne zmniejszenie poboru mocy i oszczędność energii elektrycznej.

Test 4:

Badanie wpływu zmiany alokacji zasobów wirtualnych maszyn na pobór mocy przez serwer, w środowisku laboratoryjnym, w warunkach symulujących rzeczywiste.

Metodologia: Testy zostały wykonane na trzech maszynach wirtualnych z zainstalowanym systemem operacyjnym Ubuntu (Linux), przy zastosowaniu programu stress-ng. Obciążenie procesora generowane było na określonych teoretycznych poziomach, zbliżonych lub wynikających z algorytmu opracowanego w ramach procesu diagnostyki usług w SDAZ. Każda seria składała się z dwóch części po 30 minut i rozpoczynała się inną alokacją zasobów oraz poziomami obciążenia, a kończyła się w oparciu o wartości wyliczone. Zmiany alokacji wykonywane były półautomatycznie, poprzez zgłaszanie odpowiednich zadań dla procesu automatycznej modyfikacji usług.

a) Seria nr 1:

Komentarz: Maszyny wirtualne rozpoczęły test z taką samą, niewielką ilością przydzielonych rdzeni procesora (4 rdzenie), obciążonych na wysokim poziomie 80%. W trakcie zmiany alokacji zasobów, każdej z nich zwiększono zasoby do 6 rdzeni. Dzięki temu w drugiej części testu były obciążone na poziomie około 53%. Na wykresie widać różnicę poboru mocy przez serwer w obu częściach testu. Średni pobór mocy wyznaczony dla obu części wynosił odpowiednio: 165,70 W i 154,36 W. Zatem po alokacji zasobów pobór mocy zmniejszył się średnio o 11,34 W, czyli o 6,84%. W zasadzie, zgodnie z algorytmem, należałoby przydzielić 7 rdzeni, obciążenie zasobów procesora byłoby na poziomie około 46%, a pobór mocy mógłby być jeszcze nieco mniejszy.

b) Seria nr 2:

Komentarz: Maszyny wirtualne rozpoczęły test z różną ilością rdzeni i obciążeniem na różnych poziomach. W trakcie zmiany alokacji zasobów, dwóm maszynom wirtualnym zwiększono ilość rdzeni, a jednej zmniejszono. Dzięki temu w drugiej części testu były obciążone na poziomie około 50%. Na wykresie widać znaczną różnicę poboru mocy przez serwer w obu częściach testu. Średni pobór mocy wyznaczony dla obu części wynosił odpowiednio: 209,66 W i 165,11 W. Zatem po alokacji zasobów pobór mocy zmniejszył się średnio o 44,55 W, czyli o 21,25%. W zasadzie, zgodnie z algorytmem, należałoby pozostawić wirtualną maszynę nr 112 bez zmiany alokacji.

c) Seria nr 3:

Komentarz: Maszyny wirtualne rozpoczęły test z różną ilością rdzeni i obciążeniem na różnych poziomach. W trakcie zmiany alokacji zasobów, dwóm maszynom wirtualnym zwiększono ilość rdzeni, a jednej zmniejszono. Dzięki temu w drugiej części testu były obciążone na poziomie około 50% i 25%. Na wykresie widać różnicę poboru mocy przez serwer w obu częściach testu. Średni pobór mocy wyznaczony dla obu części wynosił odpowiednio: 181,11 W i 164,80 W. Zatem po alokacji zasobów pobór mocy zmniejszył się średnio o 16,31 W, czyli o 9,01%. Zmiany alokacji były zgodne z algorytmem skalowania zasobów.

d) Seria nr 4:

Komentarz: Maszyny wirtualne rozpoczęły test ze zbyt dużym przydziałem rdzeni i obciążeniem na bardzo niskich poziomach. W trakcie zmiany alokacji zasobów, wszystkim maszynom wirtualnym zmniejszono ilość rdzeni, zwiększając tym samym obciążenie. Na wykresie widać praktycznie ten sam pobór mocy przez serwer w obu częściach testu. Średni pobór mocy wyznaczony dla obu części wynosił odpowiednio: 149,20 W i 148,88 W. Zatem po alokacji zasobów pobór mocy zmniejszył się średnio o 0,32 W, czyli o 0,21%. W poprzednich seriach sumaryczna ilość rdzeni przydzielonych wirtualnym maszynom wzrastała podczas zmiany alokacji zasobów, co dodatkowo zwiększało wartość wskaźnika oszczędności energii. W analizowanej serii nr 4, zmiana alokacji zasobów zwolniła połowę rdzeni procesora, a mimo tego pobór mocy pozostał praktycznie na tym samym poziomie.

e) Seria nr 5:

Komentarz: Maszyny wirtualne rozpoczęły test z maksymalnym przydziałem rdzeni i obciążeniem na bardzo niskich poziomach. W trakcie zmiany alokacji zasobów, wszystkim maszynom wirtualnym zmniejszono ilość rdzeni, zwiększając tym samym obciążenie. Na wykresie widać praktycznie ten sam pobór mocy przez serwer w obu częściach testu. Średni pobór mocy wyznaczony dla obu części wynosił odpowiednio: 150,10 W i 150,90 W. Zatem po alokacji zasobów pobór mocy zmniejszył się średnio o 0,80 W, czyli o 0,53%. Konfiguracja była bardzo podobna do poprzedniej serii testu, ale sumaryczna ilość rdzeni przydzielonych maszynom obejmowała całą pulę rdzeni procesora. Po zmianie alokacji zwolniła się połowa rdzeni, a mimo tego pobór mocy pozostał praktycznie na tym samym poziomie.

f) Seria nr 6:

Komentarz: Maszyny wirtualne rozpoczęły test z taką samą ilością przydzielonych rdzeni procesora (8 rdzenie), chociaż dwukrotnie większą niż w serii nr 1. Obciążone zostały na wysokim poziomie 80%. W trakcie zmiany alokacji zasobów, każdej z nich zwiększono zasoby do 13 rdzeni. Dzięki temu w drugiej części testu były obciążone na poziomie około 49%. Na wykresie widać różnicę poboru mocy przez serwer w obu częściach testu. Średni pobór mocy wyznaczony dla obu części wynosił odpowiednio: 201,40 W i 163,75 W. Zatem po alokacji zasobów pobór mocy zmniejszył się średnio o 37,65 W, czyli o 18,69%. Zmiany alokacji były zgodne z algorytmem skalowania zasobów.

Podsumowanie: Test nr 4 jasno pokazuje, że jeśli na serwerze są wirtualne maszyny z różnym przydziałem rdzeni, obciążone w różnym stopniu, to zmiany alokacji mogą odbywać się w ramach dostępnej puli rdzeni, a mimo to zostaną uzyskane pewne oszczędności energetyczne. Rdzenie procesora zwolnione ze słabo obciążonych maszyn wirtualnych, mogą być przydzielane maszynom, których obciążenie jest zbyt wysokie. Serie a, b, c i f, to przykłady alokacji dodatkowych rdzeni procesora i osiągniętych dzięki temu zysków energetycznych. Serie d i e, to przykłady zmniejszania alokacji rdzeni procesora i braku wpływu na pobór mocy. Na serwerze z dużą ilością maszyn wirtualnych, przedstawione scenariusze testowe mogą występować równocześnie, dzięki czemu powinno dochodzić do kompensacji w alokacji rdzeni, oraz do kumulacji zysków energetycznych. Taka zmiana alokacji zasobów procesora prowadzi do oszczędności energii elektrycznej pobieranej przez serwer.

Wszystkie scenariusze testu nr 4 można połączyć w jedną statystykę obejmującą 18 hipotetycznych wirtualnych maszyn (6 x 3), będących na hipotetycznym serwerze. Sumując różnice zmian alokacji rdzeni hipotetycznego procesora, dla poszczególnych hipotetycznych wirtualnych maszyn, można zauważyć, że nastąpiła kompensacja w tym zakresie (alokowano tylko 2 rdzenie więcej). Ciężko określić jakie byłyby konkretne poziomy poboru mocy przez taki hipotetyczny serwer, ale można spodziewać się podobnego wpływu procentowego na pobór mocy, przez poszczególne grupy wirtualnych maszyn. Zatem uśredniając wszystkie procentowe zmiany w poborze mocy, uzyskane podczas testu nr 4, można wyznaczyć hipotetyczny wskaźnik oszczędności energii, który wynosi: 9,42%. Wartość mieści się w oczekiwanym zakresie 5-10% i ukazuje szansę na uzyskanie jeszcze lepszego wyniku, chociaż testy należy jeszcze poszerzać i wykonywać w bardziej zaawansowanych środowiskach testowych.

Walidacja i testy systemu DRAS (Dynamic Resource Allocation System).

Rozeznanie rynku – prośba o wycenę przedmiotu zamówienia

Sztuczna Inteligencja w małych i średnich przedsiębiorstwach