SLO Power
Second release
Ziel dieser Seite ist es, Schritte und Codes zur Reproduktion der Ergebnisse für das folgende Papier bereitzustellen:
M. Savasci et al., "Slo-Power: SLO- und Power-Aware-Elastizitätsskalierung für Webdienste", 2024 IEEE/ACM 24. Internationales Symposium für Cluster, Cloud und Internet Computing (CCGRID), Philadelphia, USA, 2024.
Im Folgenden beschreiben wir im Detail:
Wir leiten Ubuntu Ubuntu 20.04 LTS auf unseren physischen Servern. Die nachstehend beschriebene Konfiguration wurde nur für diese bestimmte Version des Betriebssystems getestet.
Wir haben Python Version 3.8.10 in unserem Setup verwendet. Daher empfehlen wir Ihnen, die gleiche Version zu verwenden.
Slo-Power benötigt die folgenden Python-Module:
Wir haben Anforderungen erzeugt.
Wir empfehlen Ihnen, eine virtuelle Python -Umgebung zu erstellen und Module in dieser virtuellen Umgebung zu installieren. Aus den requirements.txt Befehl aus fördern Sie den folgenden Befehl aus:
pip install -r /path/to/requirements.txt
Zum Installieren von RAPL -Modul zuerst das Repo klonen
git clone https://github.com/wkatsak/py-rapl.git
Gehen Sie dann zum Inneren des Verzeichnisses und rennen Sie
pip install .
Mit diesem Befehl verwendet setup.py , um das Rapl -Modul zu installieren.
Wir haben LXD Version 5.19 für die Clusterbildung und damit für die Anwendungsbereitstellung verwendet. LXD kann mit Snap Package Manager installiert werden. Um es zu installieren,
sudo snap install lxd --channel=5.19/stable
Wenn Sie bereits LXD in Ihrem Computer haben, können Sie mit dem folgenden Befehl zu Version 5.19 wechseln
sudo snap refresh lxd --channel=5.19/stable
Wir stellen eine json Datei zur Verfügung, mit der Slo-Power Manager die Maschinen im Cluster kennenlernen können. Zu diesem Zweck sehen und aktualisieren Sie die Datei cluster_Machines.json oder Single_maachine.json.
Für unsere Experimente haben wir deutsche Medienwiki mit Memcached verwendet. Sie können Bild von hier herunterladen:
Alternativ können Sie es mit dem folgenden gdown -Befehl herunterladen:
gdown 1nZ0pMFGASFhaA4tthHhLlgdFP-RGt5tH
Für Installationsdetails zu gdown finden Sie in GitHub Repo GitHub.
Nachdem Sie den Containerbild -Tarball heruntergeladen haben, müssen Sie einen Container wiederherstellen und daraus erstellen. Führen Sie dazu die folgenden Befehle aus:
PS Bevor Sie über die Befehle ausgeführt werden, müssen Sie sicherstellen, dass Sie lxd init für den Initialisierungszweck ausführen.
lxc image import mediawiki_german_with_memcached.tar.gz --alias {IMAGE_NAME}
lxc launch {IMAGE_NAME} {CONTAINER_NAME}
Um zu sehen, ob der Container abgelaufen ist, rennen Sie bitte
lxc list
Commmand und stellen Sie sicher, dass Container läuft.
Zusätzlich zu den oben genannten Schritten fügen wir dem Container einen Proxy hinzu, um Anfragen von der Haproxy zu erhalten. Wir machen hier im Grunde die Portweiterleitung.
Um einen Proxy hinzuzufügen, führen Sie bitte den folgenden Befehl aus.
lxc config device add {CONTAINER_NAME} {PROXY_NAME} proxy listen=tcp:0.0.0.0:{PORT_NUMBER} connect=tcp:127.0.0.1:80
Wir verwenden Haproxy v2.7.10 vor Backend -Servern zum Ausgleich von Ladungen. Sie müssen zuerst Haproxy installieren. Es kann installiert werden
sudo apt install haproxy=2.7.10-1ppa1~bionic
Um zu überprüfen, ob es installiert ist, führen Sie aus:
haproxy -v
In diesem Befehl sollte die Versionsnummer der installierten Haproxy angezeigt werden.
Nach der Installation von Haproxy muss die Konfigurationsdatei unter /etc/haproxy/haproxy.cfg bearbeitet werden. Für den Einfachheit halber haben wir diese Konfigurationsdatei als haproxy.cfg bewährt. In dieser Datei müssen Parameter von CONTAINER_NAME , IP_ADDRESS_OF_MACHINE_HOSTING_CONTAINER und PORT_NUMBER_OF_CONTAINER bereitgestellt werden. Hier ist CONTAINER_NAME der Container, den wir zuvor erstellt haben. Zusätzlich muss PORT_NUMBER_OF_CONTAINER das gleiche wie das mit dem Erstellen des Proxy für den Container.
Wir haben die oben genannten Parameter mit einigen Werten in diesem Bild initialisiert. Daher müssen Sie sie mit korrekten Werten festlegen.
Wir bieten auch Haproxy LXC -Image für Ihre Bequemlichkeit an. Es kann von hier heruntergeladen werden
Alternativ können Sie es mit dem folgenden gdown -Befehl herunterladen:
gdown 1KtDZeMU-2enfnRhV5l147G-VW8CjHJHE
Nachdem Sie den Containerbild -Tarball heruntergeladen haben, müssen Sie einen Container wiederherstellen und daraus erstellen. Führen Sie dazu die folgenden Befehle aus:
lxc image import haproxy_container.tar.gz --alias {IMAGE_NAME}
lxc launch {IMAGE_NAME} {CONTAINER_NAME}
Der Arbeitsload-Generator wird im Verzeichnis der Arbeitsbelastungsgenerator bereitgestellt. Unser Workload -Generator basiert auf dem HTTPMON -Workload -Generator. Für Installationsdetails finden Sie hier hier. Die Verwendung des Workload-Generators lautet wie folgt (davon aus, dass es im Verzeichnis workload-generator bezeichnet wird):
./generator $1 $2 $3 $4 where
$1 --> path to the binary of the httpmon
$2 --> IP address of HAProxy server (Listening port number can be provided as `IP_address:port_number`)
$3 --> workload trace file
$4 --> version of the workload generator's output that is logged
Zum Beispiel der folgende Befehl
./generator.sh /workspace/httpmon 0.0.0.0 /SLO-Power/workload-traces/single_node_level_scaled_wikipedia_traces.out v1
Initiiert v1 HTTPMON -Workload -Generator unter Verwendung von Binary im Verzeichnis 0.0.0.0 /workspace unter Verwendung von Spuren von single_node_level_scaled_wikipedia_traces.out . Standardmäßig wird die Ausgabe des Workload -Generators unter /tmp -Verzeichnis gespeichert.
Wir haben zwei echte Workload -Spuren verwendet: Wikipedia- und Azure -Spuren. Wir haben sowohl Wikipedia- als auch Azure -Spuren unter Berücksichtigung unserer Clustergröße skaliert. Für Wikipedia skalierten wir Spuren zwischen 60 und 240, während wir zwischen 100 und 240 nach Azurspuren skaliert wurden. Alle diese Spuren stehen im Verzeichnis der Workload-Traces. Zusätzlich zu den Workload -Spuren der Clusterebene haben wir auch die Workload -Spuren der Knotenebene im selben Ordner bereitgestellt. Sie sollten sie basierend auf Ihrem Setup entsprechend auswählen.
Die Quellcodes von Slo-Power befinden sich im SRC-Verzeichnis. Im Folgenden werden wir zeigen, wie man Slo-Power ausführt.
Unser Slo-Agent hat zwei Module: Power Capper und Core Allocator.
sudo ausführen) usage: power_capper_server.py [-h] [-p PORT] [-w WORKERS] [-e POWER]
Power Capping Server
optional arguments:
-h, --help show this help message and exit
-p PORT, --port PORT Network port (default: 8088)
-w WORKERS, --workers WORKERS
Max Number of workers (default: 10)
-e POWER, --power POWER
Default power (default: 85000000)
usage: dynamic_core_allocator.py [-h] [-H HOST] [-p PORT] [-w WORKERS] [-d DOMAIN] [-c CORES]
Dynamic Core Allocator
optional arguments:
-h, --help show this help message and exit
-H HOST, --host HOST Network host (default: 0.0.0.0)
-p PORT, --port PORT Network port (default: 8090)
-w WORKERS, --workers WORKERS
Max number of workers (default: 10)
-d DOMAIN, --domain DOMAIN
Default container (default: mediawiki-51-1)
-c CORES, --cores CORES
Default number of cores (default: 16)
Wir haben außerdem zwei Dienste entwickelt, um eine Strommessung über die Intel RapL -Schnittstelle und Containerinformationen wie die Messung der CPU -Nutzungsmessung bereitzustellen. Diese beiden Dienste können wie folgt ausgeführt werden.
sudo ausführen) usage: rapl_power_monitor_server.py [-h] [-p PORT] [-w WORKERS]
Container Service Server
optional arguments:
-h, --help show this help message and exit
-p PORT, --port PORT Network port (default: 8091)
-w WORKERS, --workers WORKERS
Max Number of workers (default: 10)
usage: container_service_server.py [-h] [-H HOST] [-p PORT] [-w WORKERS]
Container Service Server
optional arguments:
-h, --help show this help message and exit
-H HOST, --host HOST Network host (default: 0.0.0.0)
-p PORT, --port PORT Network port (default: 8089)
-w WORKERS, --workers WORKERS
Max Number of workers (default: 10)
Warnung: Bevor Sie den Slo-Power-Manager ausführen, stellen Sie sicher, dass die Anwendung aufgewärmt wird, indem Anfragen vom Workload-Generator gesendet werden. Zum Beispiel der folgende Befehl
/workspace/httpmon --url http://0.0.0.0/gw/index.php/Mehmed_II. --concurrency 40 --thinktime 1 --open
Initiiert einen HTTPMON -Workload -Generator unter Verwendung von Binary im Verzeichnis /workspace , sendet Anforderungen an das Hosting von Haproxy auf IP von 0.0.0.0 mit dem Anwendungspfad von gw/index.php/ und Anforderung von Mehmed_II. Seite 40 times per second . Weitere Details dieses Befehls finden Sie hier.
Wir bieten ein Bash-Skript, um die Python-Datei Slo-Power Manager auszuführen. Die Verwendung des Skripts ist wie folgt:
./run_slo_power_manager $1 $2 $3 $4 where
$1 --> filepath where experiment files are saved to
$2 --> target SLO (in terms of ms)
$3 --> time granularity that SLO-Power works (1s in our experiments)
$4 --> filepath where HAProxy log file is (Default is /var/log/haproxy.log)
In der run_slo_power_manager müssen Sie möglicherweise den Befehl python in Zeile 31 basierend auf Ihrem Setup ändern. Wenn Ihr python -Anruf beispielsweise als python3 ist, ersetzen Sie python durch python3 . Stellen Sie außerdem sicher, dass Sie run_slo_power_manager.sh -Skript im src -Verzeichnis ausführen.
Zum Beispiel die folgenden zwei Befehle
cd SLO-Power/src/
./run_slo_power_manager.sh artifact_eval/test2/ 250 1 /var/log/haproxy.log
Ändert das aktuelle Arbeitsverzeichnis in SLO-Power/src , initiiert ein Experiment, speichert die Ergebnisse im Verzeichnis artifact_eval/test2/ und konfiguriert das Ziel auf 250 ms mit Ergebnissen bei einer Granularität von 1 s. Ein Probenausgang würde erzeugen:
Min core: 2, Max core: 16
Current core info of containers: {('192.168.245.51', 'mediawiki-51-1'): 3}
Controller max power limit for node: {('192.168.245.51', 'mediawiki-51-1'): 55}
Target response time of the application: 250 ms
Ref_input: 250
slo_guard: 0.8
Guarded SLO target: 200.0
HAProxy log file is cleared for the initialization purpose.
Initial resource calibration is in progress...
Arrival rate: 41, service rate: 9, expected response time: 0.2 s
Proactive estimated number of core is 11.
Proactively estimated number of core for cluster: 11
{('192.168.245.51', 'mediawiki-51-1'): 0.06}
{('192.168.245.51', 'mediawiki-51-1'): 11}
11 core(s) has been allocated to mediawiki-51-1 hosted on 192.168.245.51.
Power has been set to 77 Watts on 192.168.245.51 due to change in number of core by the proactive scaler.
Initial resource calibration is done :)
Iteration: 1, Estimated number of request: 41, Average response time: 125.66666666666667, Tail response time: 140.9
Proactively scaling up decision is gonna be taken...
To be increased # cores: 0
12 core(s) has been allocated to mediawiki-51-1 hosted on 192.168.245.51.
Power is being set to 80 Watts (increase)
Power has been set to 80 Watts on 192.168.245.51 (Due to inner power scaler loop).
Beachten Sie, dass unsere IP auf 192.168.245.51 eingestellt ist und sich zwischen Maschinen unterscheidet.
Schließlich stellen wir zwei Konfigurationsdateien bereit, die festgelegt werden müssen, wenn das Experiment auf der Ebene der einzelnen Maschine oder Cluster ausgeführt wird. Diese Konfigurationsdateien sind Single_Machine.json und cluster_Machines.json. Diese Dateien sollten basierend auf Ihrem eigenen Setup geändert werden. Wir haben diese Konfigurationsdatei in SLO_POWER_MANAGER.PY in line 28 als machines_config_file = "./single_machine.json" fest codiert. Diese Zeile sollte mit der Konfigurationsdatei aktualisiert werden, die auf Ihrem Setup, dh, einzelner Knoten -Setup oder Cluster -Setup basiert. Der Pfad dieser Konfigurationsdatei kann geändert werden, wenn der Fall keine Fehlerdatei gefunden hat.
Darüber hinaus verfügt die SLO-Power für die Einrichtung von Parametern. Diese Parameter können in der Konfigurationsdatei eingerichtet werden. Aus dieser Konfigurationsdatei sind einige Parameter spezifisch für die Einrichtung (Einzelmaschinenebene oder Clusterebene). Diese Parameter sind unten angegeben und sollten entsprechend festgelegt werden.
cluster_size ist zu erwähnen, wie viele Maschinen im Experiment verwendet werden (Gesamtzahl der in single_machine.json , dh 1 oder in cluster_machines.json ) erwähnten Maschinen)
service_rate hält die Service -Rate der Anwendung unter dem Setup.
PS power_manager_config.json ist in line 29 als config_file = "./power_manager_config.json festcodiert. Möglicherweise müssen Sie seinen Pfad basierend auf Ihrem aktuellen Arbeitsverzeichnis aktualisieren, wenn Sie keine Datei haben, die keinen Fehler gefunden haben.
