303 lines
12 KiB
YAML
303 lines
12 KiB
YAML
# KloudBuster Default configuration file
|
|
#
|
|
# This file can be copied and used as a template to specify different settings,
|
|
# then passed to KloudBuster using the '--config-file <path>' option.
|
|
#
|
|
# NOTE: In the copy, properties that are unchanged (same as default) can be simply
|
|
# removed from the file.
|
|
|
|
# =====================================================
|
|
# COMMON CONFIG OPTIONS FOR BOTH SERVER AND CLIENT SIDE
|
|
# =====================================================
|
|
|
|
# Name of the image to use for all test VMs (client, server and proxy)
|
|
# The image name must exist in OpenStack and built with appropriate packages.
|
|
# The default test VM image is named "kloudbuster_v<version>" where
|
|
# <version> is the KloudBuster test VM image version (e.g. "kloudbuster_v3")
|
|
# Leave empty to use the default test VM image (recommended).
|
|
# If non empty use quotes if there are space characters in the name (e.g. 'my image')
|
|
image_name:
|
|
|
|
# Keystone admin role name (default should work in most deployments)
|
|
keystone_admin_role: "admin"
|
|
|
|
# Cleanup all kloudbuster resources upon exit
|
|
# If set to False, resources created will not be deleted on exit and the user
|
|
# will have to execute the cleanup script later to remove all these resources
|
|
cleanup_resources: True
|
|
|
|
# VM creation concurrency
|
|
# Specifies how many VMs will be created at a time. Larger numbers can be used
|
|
# but will not necessarily shorten the overall staging time (this will largely
|
|
# depend on the scalability of the OpenStack control plane).
|
|
# Well tuned control planes with multiple instances of NOVA have shown to
|
|
# support a concurrency level of up to around 50
|
|
vm_creation_concurrency: 5
|
|
|
|
# Public key to use to access all test VMs
|
|
# If empty will default to the user's public key (~/.ssh/id_rsa.pub) if it
|
|
# exists, otherwise will not provision any public key.
|
|
#
|
|
# NOTE: SSH access to the test VMs launched by kloudbuster is not required,
|
|
# but can be handy if the user wants to ssh manually to any of them (for
|
|
# example to debug)
|
|
public_key_file:
|
|
|
|
# ==========================
|
|
# SERVER SIDE CONFIG OPTIONS
|
|
# ==========================
|
|
server:
|
|
# Flavor to use for the test images
|
|
flavor:
|
|
# Number of vCPUs for the flavor
|
|
vcpus: 1
|
|
# Memory for the flavor in MB
|
|
ram: 2048
|
|
# Size of local disk in GB
|
|
disk: 20
|
|
|
|
# Number of tenants to be created on the cloud
|
|
# KloudBuster will also create 1 user automatically for each tenant
|
|
number_tenants: 1
|
|
|
|
# Number of routers to be created within the context of each User
|
|
routers_per_tenant: 1
|
|
|
|
# Number of networks to be created within the context of each Router
|
|
# Assumes 1 subnet per network
|
|
# Note that you will need as many available floating IPs as routers
|
|
networks_per_router: 1
|
|
|
|
# Number of VM instances to be created within the context of each Network
|
|
vms_per_network: 1
|
|
|
|
# Number of security groups per network
|
|
secgroups_per_network: 1
|
|
|
|
# Assign floating IP for every server side test VM
|
|
# Default: no floating IP (only assign internal fixed IP)
|
|
use_floatingip: False
|
|
|
|
# Traffic shaping - VM Placement hint
|
|
# Availability zone to use for servers in the server cloud
|
|
# Leave empty if you prefer to have the Nova scheduler place the server VMs
|
|
# If you want to pick a particular AZ, put that AZ name (e.g. nova)
|
|
# If you want a paticular compute host, put the AZ and compute host names
|
|
# separated by ':' (e.g. nova:tme100)
|
|
# Note that this is ignored/overriden if you specify a topology file (-t)
|
|
availability_zone:
|
|
|
|
# HTTP Server specific configs (per VM)
|
|
http_server_configs:
|
|
# The size of HTML page in Bytes
|
|
html_size: 32768
|
|
|
|
|
|
# ==========================
|
|
# CLIENT SIDE CONFIG OPTIONS
|
|
# ==========================
|
|
client:
|
|
# Progression testing configuration
|
|
# If enabled, KloudBuster will give multiple runs (progression) on the cloud,
|
|
# unless it reaches the scale defined in the upper sections, or the stop limit.
|
|
progression:
|
|
# Enable/Disable the progression
|
|
enabled: False
|
|
# The starting count of VMs:
|
|
# 0: Start directly from vm_multiple;
|
|
# 1: Start from 1 VM;
|
|
vm_start: 1
|
|
# The steping for the VM count for each stage
|
|
# e.g. KloudBuster will run iterations on below sequences:
|
|
# {'vm_start': 1, 'vm_multiple': 2}: 1, 2, 4, 6, 8... [DEFAULT]
|
|
# {'vm_start': 1, 'vm_multiple': 5}: 1, 5, 10, 15, 20...
|
|
# {'vm_start': 0, 'vm_multiple': 1}: 1, 2, 3, 4, 5...
|
|
# {'vm_start': 0, 'vm_multiple': 5}: 5, 10, 15, 20...
|
|
vm_multiple: 2
|
|
# The stop condition for HTTP benchmarking, it is used for KloudBuster to
|
|
# determine when to stop the progression, and do the cleanup if needed.
|
|
# It defines as:
|
|
# [number_of_socket_errs, percentile_of_requests_not_timeout(%%)]
|
|
#
|
|
# e.g. [50, 99.99] means, KloudBuster will continue the progression run
|
|
# only if *ALL* below conditions are satisfied:
|
|
# (1) The socket error count (including errors and timeouts) is less
|
|
# or equal than 50;
|
|
# (2) 99.99%% of the requests are within the timeout range;
|
|
#
|
|
# Note:
|
|
# (1) The HTTP request timeout value is defined in the
|
|
# client:http_tool_config section;
|
|
# (2) The percentile of requests must be in the below list:
|
|
# [50, 75, 90, 99, 99.9, 99.99, 99.999]
|
|
# (3) Sets percentile to 0 to disable HTTP request timeout checks;
|
|
http_stop_limit: [50, 0]
|
|
# The stop condition for storage benchmarking, it is used for KloudBuster
|
|
# to determine when to stop the progression, and do the cleanup if needed.
|
|
# In the mode of random read and random write, this value indicates the
|
|
# percentile of degrading on IOPS, while in the mode of sequential read
|
|
# and sequential write, this value indicates the percentile of degrading
|
|
# on throughput.
|
|
#
|
|
# Assume the IOPS or throughput per VM is a fixed value, usually we are
|
|
# expecting higher values when the VM count grows. At certain point where
|
|
# the capacity of storage is reached, the overall performance will start
|
|
# to degrade.
|
|
#
|
|
# e.g. In the randread and randwrite mode, for example the IOPS is limited
|
|
# to 100 IOPS/VM. In the iteration of 10 VMs, the requested IOPS for the
|
|
# system is 100 * 10 = 1000. However, the measured IOPS is degraded to
|
|
# only 800 IOPS. So the degraded percentile is calculated as 800/1000=20%
|
|
# for this set of data.
|
|
#
|
|
# KloudBuster will continue the progression run if the degrading percentile
|
|
# is within (less or equal) the range defined below.
|
|
storage_stop_limit: 20
|
|
|
|
# Assign floating IP for every client side test VM
|
|
# Default: no floating IP (only assign internal fixed IP)
|
|
use_floatingip: False
|
|
|
|
# Flavor to use for the test images
|
|
flavor:
|
|
# Number of vCPUs for the flavor
|
|
vcpus: 1
|
|
# Memory for the flavor in MB
|
|
ram: 2048
|
|
# Size of local disk in GB
|
|
disk: 20
|
|
|
|
# Traffic shaping - VM Placement hint
|
|
# Availability zone to use for clients in the client cloud
|
|
# Leave empty if you prefer to have the Nova scheduler place the server VMs
|
|
# If you want to pick a particular AZ, put that AZ name (e.g. nova)
|
|
# If you want a paticular compute host, put the AZ and compute host names
|
|
# separated by ':' (e.g. nova:tme100)
|
|
# Note that this is ignored/overriden if you specify a topology file (-t)
|
|
availability_zone:
|
|
|
|
# Interval for polling status from all VMs in seconds
|
|
polling_interval: 5
|
|
|
|
# HTTP tool specific configs (per VM)
|
|
# Every HTTP server VM is paired to 1 HTTP traffic generator VM
|
|
# KloudBuster will take care of setting up the proper static routes
|
|
# to allow connectivity between all pairs of VMs.
|
|
# For example, if 1000 HTTP servers are configured, KloudBuster will
|
|
# instantiate 1000 HTTP traffic generators and match them 1:1, for a total
|
|
# of 2000 VM instances.
|
|
http_tool_configs:
|
|
# Threads to run tests
|
|
threads: 1
|
|
# Connections to be kept concurrently per VM
|
|
# This number also corresponds to the number of HTTP users
|
|
# connected at any time to the matching HTTP server
|
|
connections: 1000
|
|
# Rate limit in RPS per client (0 for unlimited)
|
|
rate_limit: 1000
|
|
# Timeout for socket connections
|
|
timeout: 5
|
|
# Connection Type: "Keep-alive", "New"
|
|
# Keep-alive: the TCP connection is reused across requests
|
|
# New: create a new TCP connection for every request (and close it after receiving the reply)
|
|
# NOTE: "New" is not currently supported.
|
|
connection_type: 'Keep-alive'
|
|
# Interval for periodical report in seconds
|
|
# Use 0 if you only need 1 final aggregated report for the entire run duration
|
|
# Otherwise will provide results at every interval (results are reset
|
|
# at the start of each period and are not cumulative across periods)
|
|
report_interval: 0
|
|
# Duration of testing tools (seconds)
|
|
duration: 30
|
|
|
|
# Storage tool specific configs (per VM)
|
|
# Multiple factors can impact the storage performance numbers, and KloudBuster is defining
|
|
# a default profile which consists of six testing scenarios:
|
|
# (1) Random read
|
|
# (2) Random write
|
|
# (3) Random mixed read/write
|
|
# (4) Sequential read
|
|
# (5) Sequential write
|
|
# (6) Sequential mixed read/write
|
|
#
|
|
# Accepted testing parameters for each scenario:
|
|
# description: (Required)
|
|
# A string describing the test case
|
|
# mode: (Required)
|
|
# Self-explained with the name, must be one of the below:
|
|
# ['randread', 'randwrite', 'randrw', 'read', 'write', 'rw']
|
|
# runtime: (Required)
|
|
# Test duration in seconds
|
|
# block_size: (Required, default=4k)
|
|
# Block size for I/O units
|
|
# iodepth: (Required, default=1)
|
|
# Number of I/O units to keep in flight against the file
|
|
# rate_iops: (Optional, default=unlimited)
|
|
# Cap the bandwidth to this number of IOPS
|
|
# rate: (Optional, default=unlimited)
|
|
# Cap the bandwidth to this number of bytes/sec, normal postfix rules apply
|
|
# rwmixread: (Required when mode is 'randrw' or 'rw')
|
|
# Percentage of a mixed workload that should be reads
|
|
# extra_opts: (Optional, default=None)
|
|
# Extra options that will be added to the FIO client
|
|
storage_tool_configs:
|
|
- description: 'Random Read'
|
|
mode: 'randread'
|
|
runtime: 30
|
|
block_size: '4k'
|
|
iodepth: 4
|
|
rate_iops: 100
|
|
- description: 'Random Write'
|
|
mode: 'randwrite'
|
|
runtime: 30
|
|
block_size: '4k'
|
|
iodepth: 4
|
|
rate_iops: 100
|
|
- description: 'Random Read/Write'
|
|
mode: 'randrw'
|
|
runtime: 30
|
|
block_size: '4k'
|
|
iodepth: 4
|
|
rate_iops: 100
|
|
rwmixread: 70
|
|
- description: 'Sequential Read'
|
|
mode: 'read'
|
|
runtime: 30
|
|
block_size: '64k'
|
|
iodepth: 64
|
|
rate: '60M'
|
|
- description: 'Sequential Write'
|
|
mode: 'write'
|
|
runtime: 30
|
|
block_size: '64k'
|
|
iodepth: 64
|
|
rate: '60M'
|
|
- description: 'Sequential Read/Write'
|
|
mode: 'rw'
|
|
runtime: 30
|
|
block_size: '64k'
|
|
iodepth: 64
|
|
rate: '60M'
|
|
rwmixread: 70
|
|
|
|
# KloudBuster supports to run storage tests on Cinder Volumes or Ephemeral
|
|
# Disks. Available options to be configured: ['volume', 'ephemeral'].
|
|
storage_target: 'volume'
|
|
|
|
# Volumes size in GB for each VM
|
|
#
|
|
# Note: Will effect only in storage testing.
|
|
disk_size: 20
|
|
|
|
# The size of the test file for running IO tests in GB. Must be less or
|
|
# equal than disk_size.
|
|
#
|
|
# Note: Due to the unit calculation difference and the overhead of the
|
|
# filesystem, the actual available space for data will be smaller than the
|
|
# volume size. So we picked GiB as the unit for laying out the test file,
|
|
# which normally should be fine.
|
|
io_file_size: 1
|
|
|
|
# Prompt before running benchmarking tools
|
|
prompt_before_run: False
|