kloudbuster/kloudbuster/cfg.scale.yaml

362 lines
15 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
# =====================================================
# The openrc file - can be overridden at the cli with the --rc argument
openrc_file:
# Name of the image to use for all test VMs (client, server and proxy)
# without the qcow2 extension
#
# 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')
# The default test VM image is named "kloudbuster-<version>" where
# <version> is the KloudBuster version (e.g. "kloudbuster-7.0.0")
image_name:
# KloudBuster can automatically upload a VM image if the image named by
# image_name is missing, for that you need to specify a file location where
# the image can be retrieved
#
# To upload the image, download it first to a local file system before running kloudbuster
# Fill with the full pathname of the image with qcow2 extension
# e.g.
# vm_image_file: /kloudbuster/kloudbuster-7.0.0.qcow2
# If empty, KloudBuster will attempt to locate that file (with the default name)
# under the following directories:
# - root of the kloudbuster package
# - current directory
vm_image_file:
# 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:
# Name of Provider network used for multicast tests.
multicast_provider_network_name: '' # Leave blank to use first available (default) network.
# ==================================================
# SERVER SIDE CONFIG OPTIONS (HTTP SERVER SIDE ONLY)
# ==================================================
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: 0
# 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/overridden if you specify a topology file (-t)
availability_zone:
# 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
# HTTP Server specific configs (per VM)
http_server_configs:
# The size of HTML page in Bytes
html_size: 32768
# ====================================================
# CLIENT SIDE CONFIG OPTIONS (HTTP CLIENT AND STORAGE)
# ====================================================
client:
# 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: 0
# metadata are supported and can be added if needed
# example:
#extra_specs:
#"hw:cpu_policy": dedicated
# Assign floating IP for every client 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 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/overridden if you specify a topology file (-t)
availability_zone:
# 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
# HTTP ONLY
# 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]
# STORAGE ONLY
# 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
# 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
# Multicast Test Mode Configurations.
multicast_tool_configs:
multicast_address_start: '231.0.0.1' # No need to change this.
# Two main test modes: 1) Internal sender -> Internal receivers (default)
# 2) External Sender -> Internal Receivers (specified by setting external_sender_test_mode: True)
# Requires a reachable external host with nuttcp installed in server mode at external_sender
# listening at external_sender_port. It should sync with the same ntp_clocks if possible.
external_sender_test_mode: False
external_sender: '0.0.0.0'
external_sender_port: 5200
# Configs for both test modes
receivers: [1] # Number of multicast listener VMs to create.
addresses: [1,2] # Number of multicast groups to test.
ports: [1,5] # Number of multicast ports to use per address.
pktsizes: [64, 1316, 4096, 9000] # in kb
bitrates: [ 0.1, 1, 10, 100, 270, 500, 1000, 1500, 3000, 10000] #in Mbps
# The below patterns define the address : port relationship in the tests.
# Each entry is a test case. Test_i: (address_test_pattern[i],port_test_pattern[i])
# Make sure len(address_test_pattern) == len(port_test_pattern)
address_test_pattern: [1,1,2,2]
port_test_pattern: [1,5,1,5]
# NTP clocks close to the cloud are required for precise latency results.
# Any machine running NTP in server mode can be used.
ntp_clocks: ["0.north-america.pool.ntp.org", "1.north-america.pool.ntp.org"] # The closer the better.
# Time in seconds for each test case. Best kept between 4-8 seconds.
duration: 4
# Storage specific configs during staging phase
# Will effect only in storage testing mode.
storage_stage_configs:
# The number of VMs for running storage tests
vm_count: 1
# KloudBuster supports to run storage tests on Cinder Volumes or Ephemeral
# Disks. Available options to be configured: ['volume', 'ephemeral'].
target: 'volume'
# Volumes size in GB for each VM
disk_size: 10
# The size of the test file for running IO tests in GB. Must be less or
# equal than disk_size. Defaults to 1 GB
io_file_size: 1
# 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 (70% read, 30% write)
# (4) Sequential read
# (5) Sequential write
# (6) Sequential mixed read/write (70% read, 30% 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)
# Maximum test duration in seconds or 0 if unlimited
# block_size: (Required, default=4k)
# Block size for I/O operations
# iodepth: (Required, default=1)
# Number of I/O operations to keep in flight against the file
# rate_iops: (Optional, default=unlimited)
# Cap the bandwidth to this number of IOPS for each VM
# This is a per VM cap.
# Omit or use 0 for unrestricted iops
# rate: (Optional, default=unlimited)
# Cap the bandwidth to this number of bytes/sec for each VM, normal postfix rules apply
# This is a per VM cap.
# Omit or use 0 for unrestricted rate
# rwmixread: (Required when mode is 'randrw' or 'rw')
# Percentage of a mixed workload that should be reads (a value between 0 and 100)
# extra_opts: (Optional, default=None)
# Extra options that will be added verbatim 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
# Prompt before running benchmarking tools
prompt_before_run: False