-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ S
SQ1: What do I need in order to start using CBTOOL?
SA1: Three things.
a) Access to an IaaS (public or private) cloud (see the list of clouds supported [here] (https://github.com/maugustosilva/cbtool/wiki/DOC:-Supported-Clouds).
b) One or more images that are prepared to be used with CBTOOL (see how to do it [here] (https://github.com/maugustosilva/cbtool/wiki/HOWTO:-Preparing-a-VM-to-be-used-with-CBTOOL-on-a-real-cloud)).
c) A VM or HOST (with network access to the cloud), were CBTOOL can be installed (see how to do it [here] (https://github.com/maugustosilva/cbtool/wiki/HOWTO:-Initial-Installation)).
SQ2: What is my "private" cloud configuration file? Where is it located?
SA2: Your "private" configuration file contains configuration changes made on CBTOOL when running on your environment, as explained here. By the default, CBTOOL looks for a file called (your username)_cloud_definitions.txt in ~/cbtool/configs, but you can indicate any other file by just running the tool's CLI with the --config option (e.g. ~/cbtool/cb --config <another cloud configuration file>.txt).
SQ3: I have an external Redis/MongoDB node (or set of nodes) that I would like to use as Object Store/Metric Store for CBTOOL. Which configurations do I need to change to "point" CBTOOL to these?
SA3: UPDATE: The "shared" attribute is now the default for Object and Metric Stores.
Assuming that the Object and Metric Stores are reachable through IP address "ABC", add the following line to your [private configuration file] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2):
...
[OBJECTSTORE]
HOST = ABC
USAGE = shared
...
[METRICSTORE]
HOST = ABC
USAGE = shared
```
...
...
[LOGSTORE] HOST = ABC USAGE = shared
....
Please note the "shared" attribute means that CBTOOL will stop controlling the Stores' state (i.e., it will stop trying to automatically start it every time the CLI is run). Also keep in mind that it is important for the network latency between the CBTOOL orchestrator node, this external node that houses the _Object Store_/_Metric Store_ and the instantiated VMs might play an important role, specially when performance data is being collected at a high frequency.
[Back](https://github.com/maugustosilva/cbtool/wiki/FAQ#sq)
***
**SQ4**: <a name="sq4"/>Do you have any sizing guidelines for the CBTOOL orchestrator node?
SA4: The CBTOOL code is being constantly optimized, so expect these guidelines to change frequently. The sizing of the orchestrator node is closely related to the size of the experiment (in numbers of simultaneously active VMs) to be executed. In CBTOOL the primary source of resources consumption is the _Object Store_ and _Metric Store_. The resource amount consumed by this source is closely related to the number of running VMs, since each VM keeps updating/accessing both stores continuously. A second source of resource consumption are the _Virtual Application Submitters_. Since each VAppS is managed by a pair of python daemons running on the orchestrator node, the resource amount is directly related to the number of simultaneously running VAppS on a given experiment.
A good rule of thumb for processing power sizing is two cores for all CBTOOL daemons (list of daemons [here](https://github.com/maugustosilva/cbtool/wiki/DOC:-Detailed-Architecture)), plus 1 core for every 2000 VMs (again, simultaneously active VMs), plus 1 core for every 200 VAppS. For memory, the rule of thumb is 2 GB of RAM for all daemons, plus 5 MB for every VM, plus 100 MB for every VAppS.
An alternative deployment architecture, where an external Redis server is used as the _Object Store_ and an external MongoDB is used as the _Metric Store_, is recommended in order to make CBTOOL much more scalable (both Redis and MongoDB can be scaled-out). [Please check the details on how to configure CBTOOL to use external servers](https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq3). Evidently, in this particular case, the CBTOOL orchestration node sizing requirements can be greatly reduced.
[Back](https://github.com/maugustosilva/cbtool/wiki/FAQ#sq)
***
**SQ5**: <a name="sq5"/> Can I run multiple instances of CBTOOL on the same orchestrator node?
SA5: Yes, **as long as each instance is ran under a different user** (this is extremely important). For each user, change the following parameters on your [private configuration file] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2), picking different values for each user:
[OBJECTSTORE] DBID = 10
[LOGSTORE] PORT = 5137
[FILESTORE] PORT = 10037
[VPN] SERVER_PORT = 11037
[API_DEFAULTS] PORT = 7037
[GUI_DEFAULTS] PORT = 8037
[Back](https://github.com/maugustosilva/cbtool/wiki/FAQ#sq)
***
**SQ6**: <a name="sq6"/> I want to run the CBTOOL Orchestrator Node (ON) outside the cloud/I want to run a single large CBTOOL ON that benchmarks multiple clouds. How should I configure CBTOOL?
SA6: First of all, please keep in mind that for Public clouds (e.g., Amazon EC2, Digital Ocean), it is possible to instruct CBTOOL to configure the instances through the public network, while letting the actual load generating processes on the _Virtual Application_ (VApp) to be executed over the private network. For instance, adding the following parameters to your [private configuration file] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2) will allow you to run the ON locally
[VM_DEFAULTS : EC2_CLOUDCONFIG] RUN_NETNAME = private PROV_NETNAME = public
Please note that this configuration assumes that actual instances that form a VApp can send data back to the Orchestrator Node outside of the cloud. For private clouds, such as OpenStack and CloudStack, there is a whole gamut of options described on this [how to](https://github.com/maugustosilva/cbtool/wiki/HOWTO:-Run-the-CloudBench-orchestrator-outside-of-the-cloud-%28or-with-multiple-tenant-networks%29) will show you how to do this.
[Back](https://github.com/maugustosilva/cbtool/wiki/FAQ#sq)