The Open-Beta Test will ask you to deploy MiCADOscale in your cloud environment. Once MiCADOscale is fully deployed, you will be asked to run a test-application within the MiCADOscale framework. This test-application will clarify the potential of multi-level scaling. Therefore, you will need access to at least one of the currently supported infrastructures.
Following prerequisites must be met:
- You will need access to at least one of the supported infrastructures of MiCADOscale.
- EC2 (tested on Amazon and OpenNebula)
- Nova (tested on OpenStack)
- We recommend machines equipped with Ubuntu OS (16.04 or higher) - MiCADOscale is developed for linux-machines.
- The master-node needs to be equipped with the following applications:
Once you completed the test, a valid google account is needed to fill out a survey. This survey is needed to collect the feedback for our product.
Deployment of the Master-node:
Deploy the latest version of MiCADOscale on your local (or a remote) machine. The deployment guide will show you how to do so.
- If you ran into trouble during the initial deployment of the MiCADO-masternode, please contact us at firstname.lastname@example.org, and we will try to support you as good as possible. If you are still unable to deploy MiCADOscale, please let us know in the survey. As already said, we would like to improve the usability of our product as well as in the documentation of it.
You deployed MiCADOscale!
Check installation integrity
Open the MiCADOscale Dashboard in your browser to check if all needed ports for the communication have been opened. Every item in the menu should be displayed correct. If it does not, you have to find your configuration issue by hand, or restart the whole deployment process.
Your installallation works!
Deploy a test application
Inside of the cloned git-repository, there is a sub-folder called “testing“. In this folder, you will find various applications which will utilize the features of MiCADOscale. In our open-beta, we will use a simple stress test application called “stress-ng“.
- Stress-ng requires "jq".
- This application will initially deploy the minimum amount of specified slaves – called “worker-nodes“ and stress their hardware until the point, where the defined scaling logic orders MiCADOscale to scale up the amount of containers inside the worker-nodes. Once the maximum amount of containers reaches their „hardware“ limits, MiCADOscale will command to increase the amount of virtual-machines in the cluster.
- To use stress-ng, you will need to adapt the existing application-description-template (ADT) of stress-ng according to your execution environment. ADT‘s will specify the application, the scaling logic, and the environment for the execution. Different infrastructures will need different parameters.
- Once you adapt the parameters in the ADT, you have to submit your application to the master-node. In the stress-ng package, there is a script for that called “1-submit-toscastressng.sh“
You've successfully deployed an application!
Add stress to the worker-nodes
Once the application has been submitted to the master-node, you can watch the initial state of stress-ng in your MiCADO-Dashboard. When you execute the script "3-stress-cpu-stressng.sh 85" stress-ng will increase the CPU load. After a few minutes, you will see the system respond by scaling up virtual machines and containers to the specified maximum.
You've stressed your application!
Relief the stress of the worker-nodes
While we were simulating the peak of stress with the 3rd script, we also have to simulate a significant drop of stress. This drop should allow MiCADOscale to scale down the ammount of worker-nodes and containers to run as cost efficient as possible. To simulate the reduced stress, use the script "3-stress-cpu-stressng.sh 10". The "10" in the arugment will reduce the stress of the application down to 10%. You will see a decrease of workernodes and containers down to the minimum in the Dashboard.
You've successfully reliefed the stress!
Finish the test application
Undeploy all of the running services by executing "4-undeploy-stressng.sh", This is an important step, because it is the only way to directly tell all running vm's to shut down. If you miss this step, you have to manually shut down each machine within your chosen infrastructure. take some notes of the things you did like ( and as well things that we could improve) & fill out the mentioned survey to give us feedback of your experience.
You've successfully finished the test!
Anyone who wants to participate in the open-beta test can choose if he wants to take part in the raffle. Therefore, we will split the groups of testers into "registered" and "unregistered". An unregistered tester will not be able to take part in the raffle. To register, you choose the corresponding option within the feedback survey.