SLO Power
Second release
Le but de cette page est de fournir des étapes et des codes pour reproduire les résultats du document suivant:
M. Savasci, et al., «Slo-Power: SLO et élastique élastique pour les services Web», en 2024 IEEE / ACM 24RD International Symposium on Cluster, Cloud and Internet Computing (CCGRID), Philadelphia, USA, 2024.
Ci-dessous, nous décrivons en détail:
Nous exécutons Ubuntu Ubuntu 20.04 LTS sur nos serveurs physiques. La configuration décrite ci-dessous a été testée uniquement pour cette version particulière du système d'exploitation.
Nous avons utilisé Python version 3.8.10 dans notre configuration. Par conséquent, nous vous suggérons d'utiliser la même version.
Slo-Power nécessite les modules Python suivants:
Nous avons généré des exigences.txt pour les modules Python requis sauf le module RAPL car il est un module externe obtenu à partir d'ici.
Nous vous suggérons de créer un environnement virtuel Python et d'installer des modules à l'intérieur de cet environnement virtuel. Pour installer à partir de requirements.txt , exécutez la commande suivante:
pip install -r /path/to/requirements.txt
Pour installer le module RAPL, clonez d'abord le repo
git clone https://github.com/wkatsak/py-rapl.git
Ensuite, allez à l'intérieur du répertoire et courez
pip install .
Cette commande utilisera setup.py pour installer le module RAPL.
Nous avons utilisé LXD version 5.19 pour le clustering et donc le déploiement des applications. LXD peut être installé à l'aide de Snap Package Manager. Pour l'installer,
sudo snap install lxd --channel=5.19/stable
Si vous avez déjà LXD dans votre machine, vous pouvez passer à la version 5.19 en utilisant la commande suivante
sudo snap refresh lxd --channel=5.19/stable
Nous fournissons un fichier json pour permettre à Slo-Power Manager de connaître les machines du cluster. À cette fin, veuillez consulter et mettre à jour le fichier Cluster_Machines.json ou Single_Machine.json.
Pour nos expériences, nous avons utilisé des médias allemands avec Memcached. Vous pouvez télécharger l'image d'ici:
Alternativement, vous pouvez le télécharger à l'aide de la commande gdown suivante:
gdown 1nZ0pMFGASFhaA4tthHhLlgdFP-RGt5tH
Pour les détails de l'installation de gdown , veuillez consulter GitHub Repo.
Après avoir téléchargé l'image de conteneur Tarball, vous devez restaurer et créer un conteneur à partir de celui-ci. Pour ce faire, exécutez les commandes suivantes:
PS Avant d'exécuter les commandes ci-dessus, vous devez vous assurer que vous exécutez lxd init à des fins d'initialisation.
lxc image import mediawiki_german_with_memcached.tar.gz --alias {IMAGE_NAME}
lxc launch {IMAGE_NAME} {CONTAINER_NAME}
Pour voir si le conteneur est en place, veuillez courir
lxc list
Commmand et assurez-vous que le conteneur fonctionne.
En plus des étapes ci-dessus, nous ajoutons un proxy au conteneur pour recevoir les demandes du Haproxy. Nous faisons essentiellement un transfert de port ici.
Pour ajouter un proxy, veuillez exécuter la commande suivante.
lxc config device add {CONTAINER_NAME} {PROXY_NAME} proxy listen=tcp:0.0.0.0:{PORT_NUMBER} connect=tcp:127.0.0.1:80
Nous utilisons Haproxy v2.7.10 devant les serveurs backend pour l'équilibrage de charge. Vous devez d'abord installer Haproxy. Il peut être installé
sudo apt install haproxy=2.7.10-1ppa1~bionic
Pour vérifier qu'il est installé, exécutez:
haproxy -v
Cette commande doit afficher le numéro de version du haproxy installé.
Une fois Haproxy installé, son fichier de configuration situé sur /etc/haproxy/haproxy.cfg doit être modifié. Pour plus de commodité, nous avons prouvé ce fichier de configuration comme haproxy.cfg. Dans ce fichier, les paramètres de CONTAINER_NAME , IP_ADDRESS_OF_MACHINE_HOSTING_CONTAINER et PORT_NUMBER_OF_CONTAINER doivent être fournis. Ici, CONTAINER_NAME est le conteneur que nous avons créé précédemment quelle application MediaWiki hôte. De plus, PORT_NUMBER_OF_CONTAINER doit être la même que celle lors de la création du proxy du conteneur.
Nous avons initialisé les paramètres ci-dessus avec certaines valeurs dans cette image. Par conséquent, vous devez les définir avec des valeurs correctes.
Nous fournissons également une image Haproxy LXC pour votre commodité. Il peut être téléchargé à partir d'ici
Alternativement, vous pouvez le télécharger à l'aide de la commande gdown suivante:
gdown 1KtDZeMU-2enfnRhV5l147G-VW8CjHJHE
Après avoir téléchargé l'image de conteneur Tarball, vous devez restaurer et créer un conteneur à partir de celui-ci. Pour ce faire, exécutez les commandes suivantes:
lxc image import haproxy_container.tar.gz --alias {IMAGE_NAME}
lxc launch {IMAGE_NAME} {CONTAINER_NAME}
Le générateur de charge de travail est fourni dans le répertoire de la charge de travail. Notre générateur de charge de travail est basé sur le générateur de charge de travail HTTPMON. Pour les détails de l'installation, veuillez consulter ici. L'utilisation du générateur de charge de travail est la suivante (supposons qu'elle s'appelle dans le répertoire workload-generator ):
./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
Par exemple, la commande suivante
./generator.sh /workspace/httpmon 0.0.0.0 /SLO-Power/workload-traces/single_node_level_scaled_wikipedia_traces.out v1
initie un générateur de charge de travail HTTPMON, en utilisant le binaire situé sur /workspace Directory, en utilisant des traces de single_node_level_scaled_wikipedia_traces.out , en envoyant des demandes à l'hébergement de Haproxy sur IP de 0.0.0.0 (modifiez-le selon la configuration de votre réseau), et de l'enregistrement du générateur de charge de travail avec v1 postfix. Par défaut, la sortie du générateur de charge de travail est enregistrée sous /tmp Directory.
Nous avons utilisé deux vraies traces de charge de travail: Wikipedia et Azure Traces. Nous avons mis à l'échelle les traces Wikipedia et Azure compte tenu de la taille de notre cluster. Pour Wikipedia, nous avons mis à l'échelle des traces entre 60 et 240, tandis que nous avons évolué entre 100 et 240 pour des traces azur. Toutes ces traces sont sous le répertoire des traces de charge de travail. En plus des traces de charge de travail au niveau du cluster, nous avons également fourni des traces de charge de travail de niveau de nœud unique dans le même dossier. Vous devez les choisir en conséquence en fonction de votre configuration.
Les codes source de SLO-Power sont situés dans le répertoire SRC. Dans ce qui suit, nous montrerons comment exécuter Slo-Power.
Notre Agent SLO a deux modules: Power Capper et Core Allocator.
sudo ) 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)
Nous avons également développé deux services pour fournir une mesure de puissance via l'interface Intel RAPL et des informations sur les conteneurs telles que sa mesure d'utilisation du processeur. Ces deux services peuvent être exécutés comme suit.
sudo ) 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)
AVERTISSEMENT: Avant d'exécuter le gestionnaire SLO-Power, assurez-vous que l'application est réchauffée en envoyant des demandes du générateur de charge de travail. Par exemple, la commande suivante
/workspace/httpmon --url http://0.0.0.0/gw/index.php/Mehmed_II. --concurrency 40 --thinktime 1 --open
initie un générateur de charge de travail HTTPMON, en utilisant le répertoire binaire situé sur /workspace , envoyant des demandes à l'hébergement Haproxy sur IP de 0.0.0.0 avec le chemin d'application de gw/index.php/ , et demandant Mehmed_II. Page 40 times per second . Plus de détails sur cette commande peuvent être trouvés ici.
Nous fournissons un script bash pour exécuter le fichier Python Slo-Power Manager. L'utilisation du script est la suivante:
./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)
Dans le run_slo_power_manager , vous devrez peut-être modifier la commande python à la ligne 31 en fonction de votre configuration. Par exemple, si votre appel python est comme python3 , remplacez python par python3 . Assurez-vous également que vous exécutez le script run_slo_power_manager.sh dans le répertoire src .
Par exemple, les deux commandes suivantes
cd SLO-Power/src/
./run_slo_power_manager.sh artifact_eval/test2/ 250 1 /var/log/haproxy.log
Modifie le répertoire de travail actuel en SLO-Power/src , initie une expérience, enregistrant les résultats dans le répertoire artifact_eval/test2/ , tout en configurant la cible à 250 ms avec des résultats à une granularité de 1 s. Un échantillon de sortie produirait:
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).
Notez que notre IP est définie sur 192.168.245.51 et diffère entre les machines.
Enfin, nous fournissons deux fichiers de configuration qui sont nécessaires pour définir si l'expérience s'exécute au niveau unique ou au niveau du cluster. Ces fichiers de configuration sont single_machine.json et cluster_machines.json. Ces fichiers doivent être modifiés en fonction de votre propre configuration. Nous avons codé en dur ce fichier de configuration dans slo_power_manager.py à line 28 en tant que machines_config_file = "./single_machine.json" . Cette ligne doit être mise à jour avec le fichier de configuration qui est basé sur votre configuration de configuration, c'est-à-dire une configuration de nœud unique ou une configuration de cluster. Le chemin d'accès de ce fichier de configuration peut être modifié en cas d'erreur de fichier de cas.
De plus, SLO-Power a des paramètres à configurer. Ces paramètres peuvent être configurés dans le fichier de configuration. À partir de ce fichier de configuration, quelques paramètres sont spécifiques à la configuration (niveau unique ou au niveau du cluster). Ces paramètres sont donnés ci-dessous et doivent être définis en conséquence.
cluster_size est de mentionner le nombre de machines utilisées dans l'expérience (nombre total de machines mentionnées dans single_machine.json , c'est-à-dire 1 ou dans cluster_machines.json )
service_rate conserve le taux de service de l'application sous la configuration.
PS Power_Manager_Config.json est codé en dur à line 29 en tant que config_file = "./power_manager_config.json . Vous devrez peut-être mettre à jour son chemin en fonction de votre répertoire de travail actuel si vous avez une erreur de fichier.
