swift/etc/container-server.conf-sample

203 lines
6.3 KiB
Plaintext
Raw Normal View History

2010-08-20 00:42:38 +00:00
[DEFAULT]
2010-07-12 17:03:45 -05:00
# bind_ip = 0.0.0.0
bind_port = 6001
# bind_timeout = 30
# backlog = 4096
2010-07-12 17:03:45 -05:00
# user = swift
2010-08-20 00:42:38 +00:00
# swift_dir = /etc/swift
# devices = /srv/node
# mount_check = true
# disable_fallocate = false
#
# Use an integer to override the number of pre-forked processes that will
# accept connections.
# workers = auto
#
# Maximum concurrent requests per worker
# max_clients = 1024
#
# This is a comma separated list of hosts allowed in the X-Container-Sync-To
New container sync configuration option Summary of the new configuration option: The cluster operators add the container_sync middleware to their proxy pipeline and create a container-sync-realms.conf for their cluster and copy this out to all their proxy and container servers. This file specifies the available container sync "realms". A container sync realm is a group of clusters with a shared key that have agreed to provide container syncing to one another. The end user can then set the X-Container-Sync-To value on a container to //realm/cluster/account/container instead of the previously required URL. The allowed hosts list is not used with this configuration and instead every container sync request sent is signed using the realm key and user key. This offers better security as source hosts can be faked much more easily than faking per request signatures. Replaying signed requests, assuming it could easily be done, shouldn't be an issue as the X-Timestamp is part of the signature and so would just short-circuit as already current or as superceded. This also makes configuration easier for the end user, especially with difficult networking situations where a different host might need to be used for the container sync daemon since it's connecting from within a cluster. With this new configuration option, the end user just specifies the realm and cluster names and that is resolved to the proper endpoint configured by the operator. If the operator changes their configuration (key or endpoint), the end user does not need to change theirs. DocImpact Change-Id: Ie1704990b66d0434e4991e26ed1da8b08cb05a37
2013-12-08 09:13:59 +00:00
# field for containers. This is the old-style of using container sync. It is
# strongly recommended to use the new style of a separate
# container-sync-realms.conf -- see container-sync-realms.conf-sample
# allowed_sync_hosts = 127.0.0.1
#
2011-01-23 13:18:28 -08:00
# You can specify default log routing here if you want:
# log_name = swift
# log_facility = LOG_LOCAL0
# log_level = INFO
# log_address = /dev/log
# The following caps the length of log lines to the value given; no limit if
# set to 0, the default.
# log_max_line_length = 0
#
# comma separated list of functions to call to setup custom log handlers.
# functions get passed: conf, name, log_to_console, log_route, fmt, logger,
# adapted_logger
# log_custom_handlers =
#
Upating proxy-server StatsD logging. Removed many StatsD logging calls in proxy-server and added swift-informant-style catch-all logging in the proxy-logger middleware. Many errors previously rolled into the "proxy-server.<type>.errors" counter will now appear broken down by response code and with timing data at: "proxy-server.<type>.<verb>.<status>.timing". Also, bytes transferred (sum of in + out) will be at: "proxy-server.<type>.<verb>.<status>.xfer". The proxy-logging middleware can get its StatsD config from standard vars in [DEFAULT] or from access_log_statsd_* config vars in its config section. Similarly to Swift Informant, request methods ("verbs") are filtered using the new proxy-logging config var, "log_statsd_valid_http_methods" which defaults to GET, HEAD, POST, PUT, DELETE, and COPY. Requests with methods not in this list use "BAD_METHOD" for <verb> in the metric name. To avoid user error, access_log_statsd_valid_http_methods is also accepted. Previously, proxy-server metrics used "Account", "Container", and "Object" for the <type>, but these are now all lowercase. Updated the admin guide's StatsD docs to reflect the above changes and also include the "proxy-server.<type>.handoff_count" and "proxy-server.<type>.handoff_all_count" metrics. The proxy server now saves off the original req.method and proxy_logging will use this if it can (both for request logging and as the "<verb>" in the statsd timing metric). This fixes bug 1025433. Removed some stale access_log_* related code in proxy/server.py. Also removed the BaseApplication/Application distinction as it's no longer necessary. Fixed up the sample config files a bit (logging lines, mostly). Fixed typo in SAIO development guide. Got proxy_logging.py test coverage to 100%. Fixed proxy_logging.py for PEP8 v1.3.2. Enhanced test.unit.FakeLogger to track more calls to enable testing StatsD metric calls. Change-Id: I45d94cb76450be96d66fcfab56359bdfdc3a2576
2012-08-19 17:44:43 -07:00
# If set, log_udp_host will override log_address
# log_udp_host =
# log_udp_port = 514
#
Upating proxy-server StatsD logging. Removed many StatsD logging calls in proxy-server and added swift-informant-style catch-all logging in the proxy-logger middleware. Many errors previously rolled into the "proxy-server.<type>.errors" counter will now appear broken down by response code and with timing data at: "proxy-server.<type>.<verb>.<status>.timing". Also, bytes transferred (sum of in + out) will be at: "proxy-server.<type>.<verb>.<status>.xfer". The proxy-logging middleware can get its StatsD config from standard vars in [DEFAULT] or from access_log_statsd_* config vars in its config section. Similarly to Swift Informant, request methods ("verbs") are filtered using the new proxy-logging config var, "log_statsd_valid_http_methods" which defaults to GET, HEAD, POST, PUT, DELETE, and COPY. Requests with methods not in this list use "BAD_METHOD" for <verb> in the metric name. To avoid user error, access_log_statsd_valid_http_methods is also accepted. Previously, proxy-server metrics used "Account", "Container", and "Object" for the <type>, but these are now all lowercase. Updated the admin guide's StatsD docs to reflect the above changes and also include the "proxy-server.<type>.handoff_count" and "proxy-server.<type>.handoff_all_count" metrics. The proxy server now saves off the original req.method and proxy_logging will use this if it can (both for request logging and as the "<verb>" in the statsd timing metric). This fixes bug 1025433. Removed some stale access_log_* related code in proxy/server.py. Also removed the BaseApplication/Application distinction as it's no longer necessary. Fixed up the sample config files a bit (logging lines, mostly). Fixed typo in SAIO development guide. Got proxy_logging.py test coverage to 100%. Fixed proxy_logging.py for PEP8 v1.3.2. Enhanced test.unit.FakeLogger to track more calls to enable testing StatsD metric calls. Change-Id: I45d94cb76450be96d66fcfab56359bdfdc3a2576
2012-08-19 17:44:43 -07:00
# You can enable StatsD logging here:
Adding StatsD logging to Swift. Documentation, including a list of metrics reported and their semantics, is in the Admin Guide in a new section, "Reporting Metrics to StatsD". An optional "metric prefix" may be configured which will be prepended to every metric name sent to StatsD. Here is the rationale for doing a deep integration like this versus only sending metrics to StatsD in middleware. It's the only way to report some internal activities of Swift in a real-time manner. So to have one way of reporting to StatsD and one place/style of configuration, even some things (like, say, timing of PUT requests into the proxy-server) which could be logged via middleware are consistently logged the same way (deep integration via the logger delegate methods). When log_statsd_host is configured, get_logger() injects a swift.common.utils.StatsdClient object into the logger as logger.statsd_client. Then a set of delegate methods on LogAdapter either pass through to the StatsdClient object or become no-ops. This allows StatsD logging to look like: self.logger.increment('some.metric.here') and do the right thing in all cases and with no messy conditional logic. I wanted to use the pystatsd module for the StatsD client, but the version on PyPi is lagging the git repo (and is missing both the prefix functionality and timing_since() method). So I wrote my swift.common.utils.StatsdClient. The interface is the same as pystatsd.Client, but the code was written from scratch. It's pretty simple, and the tests I added cover it. This also frees Swift from an optional dependency on the pystatsd module, making this feature easier to enable. There's test coverage for the new code and all existing tests continue to pass. Refactored out _one_audit_pass() method in swift/account/auditor.py and swift/container/auditor.py. Fixed some misc. PEP8 violations. Misc test cleanups and refactorings (particularly the way "fake logging" is handled). Change-Id: Ie968a9ae8771f59ee7591e2ae11999c44bfe33b2
2012-04-01 16:47:08 -07:00
# log_statsd_host = localhost
# log_statsd_port = 8125
# log_statsd_default_sample_rate = 1.0
# log_statsd_sample_rate_factor = 1.0
Adding StatsD logging to Swift. Documentation, including a list of metrics reported and their semantics, is in the Admin Guide in a new section, "Reporting Metrics to StatsD". An optional "metric prefix" may be configured which will be prepended to every metric name sent to StatsD. Here is the rationale for doing a deep integration like this versus only sending metrics to StatsD in middleware. It's the only way to report some internal activities of Swift in a real-time manner. So to have one way of reporting to StatsD and one place/style of configuration, even some things (like, say, timing of PUT requests into the proxy-server) which could be logged via middleware are consistently logged the same way (deep integration via the logger delegate methods). When log_statsd_host is configured, get_logger() injects a swift.common.utils.StatsdClient object into the logger as logger.statsd_client. Then a set of delegate methods on LogAdapter either pass through to the StatsdClient object or become no-ops. This allows StatsD logging to look like: self.logger.increment('some.metric.here') and do the right thing in all cases and with no messy conditional logic. I wanted to use the pystatsd module for the StatsD client, but the version on PyPi is lagging the git repo (and is missing both the prefix functionality and timing_since() method). So I wrote my swift.common.utils.StatsdClient. The interface is the same as pystatsd.Client, but the code was written from scratch. It's pretty simple, and the tests I added cover it. This also frees Swift from an optional dependency on the pystatsd module, making this feature easier to enable. There's test coverage for the new code and all existing tests continue to pass. Refactored out _one_audit_pass() method in swift/account/auditor.py and swift/container/auditor.py. Fixed some misc. PEP8 violations. Misc test cleanups and refactorings (particularly the way "fake logging" is handled). Change-Id: Ie968a9ae8771f59ee7591e2ae11999c44bfe33b2
2012-04-01 16:47:08 -07:00
# log_statsd_metric_prefix =
#
!! Changed db_preallocation to False Long explanation, but hopefully answers any questions. We don't like changing the default behavior of Swift unless there's a really good reason and, up until now, I've tried doing this with this new db_preallocation setting. For clusters with dedicated account/container servers that usually have fewer disks overall but SSD for speed, having db_preallocation on will gobble up disk space quite quickly and the fragmentation it's designed to fight isn't that big a speed impact to SSDs anyway. For clusters with account/container servers spread across all servers along with object servers usually having standard disks for cost, having db_preallocation off will cause very fragmented database files impacting speed, sometimes dramatically. Weighing these two negatives, it seems the second is the lesser evil. The first can cause disks to fill up and disable the cluster. The second will cause performance degradation, but the cluster will still function. Furthermore, if just one piece of code that touches all databases runs with db_preallocation on, it's effectively on for the whole cluster. We discovered this most recently when we finally configured everything within the Swift codebase to have db_preallocation off, only to find out Slogging didn't know about the new setting and so ran with it on and starting filling up SSDs. So that's why I'm proposing this change to the default behavior. We will definitely need to post a prominent notice of this change with the next release. Change-Id: I48a43439264cff5d03c14ec8787f718ee44e78ea
2012-05-22 00:30:47 +00:00
# If you don't mind the extra disk space usage in overhead, you can turn this
# on to preallocate disk space with SQLite databases to decrease fragmentation.
# db_preallocation = off
#
# eventlet_debug = false
#
# You can set fallocate_reserve to the number of bytes you'd like fallocate to
# reserve, whether there is space for the given file size or not.
# fallocate_reserve = 0
2010-08-20 00:42:38 +00:00
[pipeline:main]
pipeline = healthcheck recon container-server
2010-08-20 00:42:38 +00:00
[app:container-server]
use = egg:swift#container
2011-01-23 13:18:28 -08:00
# You can override the default log routing for this app here:
# set log_name = container-server
# set log_facility = LOG_LOCAL0
# set log_level = INFO
# set log_requests = true
# set log_address = /dev/log
#
2010-07-12 17:03:45 -05:00
# node_timeout = 3
# conn_timeout = 0.5
# allow_versions = false
# auto_create_account_prefix = .
#
# Configure parameter for creating specific server
# To handle all verbs, including replication verbs, do not specify
# "replication_server" (this is the default). To only handle replication,
# set to a True value (e.g. "True" or "1"). To handle only non-replication
# verbs, set to "False". Unless you have a separate replication network, you
# should not specify any value for "replication_server".
# replication_server = false
2010-07-12 17:03:45 -05:00
[filter:healthcheck]
use = egg:swift#healthcheck
# An optional filesystem path, which if present, will cause the healthcheck
# URL to return "503 Service Unavailable" with a body of "DISABLED BY FILE"
# disable_path =
[filter:recon]
use = egg:swift#recon
#recon_cache_path = /var/cache/swift
2010-07-12 17:03:45 -05:00
[container-replicator]
2011-01-23 13:18:28 -08:00
# You can override the default log routing for this app here (don't use set!):
# log_name = container-replicator
2011-01-23 13:18:28 -08:00
# log_facility = LOG_LOCAL0
# log_level = INFO
# log_address = /dev/log
#
# vm_test_mode = no
2010-07-12 17:03:45 -05:00
# per_diff = 1000
# max_diffs = 100
2010-07-12 17:03:45 -05:00
# concurrency = 8
# interval = 30
2010-07-12 17:03:45 -05:00
# node_timeout = 10
# conn_timeout = 0.5
#
2010-07-12 17:03:45 -05:00
# The replicator also performs reclamation
# reclaim_age = 604800
#
# Time in seconds to wait between replication passes
Swift configuration parameter audit This change is the result of an audit through the config parameters provided by swift and how/if they are addressed in the swift documentation. The documentation being the sample config files in the /etc directory or the documentation. This change is only concerned with the config files in etc/ next I will look at the documentation in the doc/ folder. This change makes the following assumptions: - Unless stated otherwise, the commented out parameter in the sample configuration is the default for swift. - When the default in the code differs from that of the sample configuration, the default in the code is correct. Container reconciler: Parameter: interval - code: 30 - config: 300 Result: config = 30 Object Expirer: Parameter: recon_cache_path - code: /var/cache/swift - config: Parameter missing Result: Add parameter swift-dispersion-populate && swift-dispersion-report Parameter: auth_version - code: 1.0 - config: 2.0 (due to being a confusing example of how to setup version 2.0). Result: Added 'auth_version = 1.0' to the right section (showing default and make the sample configuration for auth version 2.0 easier to understand. swift-drive-audit: Parameter: log_file_pattern - code: /var/log/kern.*[!.][!g][!z] - config: /var/log/kern* Result: config = /var/log/kern.*[!.][!g][!z] NOTE: swift-drive-audit uses a parameter called device_dir which defaults to '/srv/node'. In all other swift binaries/services there is a similar parameter called devices which stores the same thing. This is an inconsistency which I haven't fixed as this could break existing swift clusters out in the wild. Proxy Server: Parameter: object_chunk_size - code: 65536 - config: 8192 Result: config = 65536 Parameter: client_chunk_size - code: 65536 - config: 8192 Result: config = 65536 Parameter: strict_cors_mode - code: True - config: No parameter Result: config = True Account and Container replicator configuration confusion: NOTES: The account and container replicators have parameters: - interval - run_pause Both of these are loaded into the same variable in code: self.interval = int(conf.get('interval') or conf.get('run_pause') or 30) If a user sets both to different values then interval is used. Result: Update the configuration to make this more clear. DocImpact Change-Id: Iaadbb1a6284f8b3e0801bc343b29772f70f4bf6e
2014-07-04 15:56:45 +10:00
# Note: if the parameter 'interval' is defined then it will be used in place
# of run_pause.
# run_pause = 30
#
# recon_cache_path = /var/cache/swift
2010-07-12 17:03:45 -05:00
[container-updater]
2011-01-23 13:18:28 -08:00
# You can override the default log routing for this app here (don't use set!):
# log_name = container-updater
2011-01-23 13:18:28 -08:00
# log_facility = LOG_LOCAL0
# log_level = INFO
# log_address = /dev/log
#
2010-07-12 17:03:45 -05:00
# interval = 300
# concurrency = 4
# node_timeout = 3
# conn_timeout = 0.5
#
2010-07-12 17:03:45 -05:00
# slowdown will sleep that amount between containers
# slowdown = 0.01
#
# Seconds to suppress updating an account that has generated an error
# account_suppression_time = 60
#
# recon_cache_path = /var/cache/swift
2010-07-12 17:03:45 -05:00
[container-auditor]
2011-01-23 13:18:28 -08:00
# You can override the default log routing for this app here (don't use set!):
# log_name = container-auditor
2011-01-23 13:18:28 -08:00
# log_facility = LOG_LOCAL0
# log_level = INFO
# log_address = /dev/log
#
# Will audit each container at most once per interval
2010-07-12 17:03:45 -05:00
# interval = 1800
#
# containers_per_second = 200
# recon_cache_path = /var/cache/swift
2011-02-23 23:26:05 -08:00
[container-sync]
# You can override the default log routing for this app here (don't use set!):
# log_name = container-sync
# log_facility = LOG_LOCAL0
# log_level = INFO
# log_address = /dev/log
#
2011-06-06 16:12:54 +00:00
# If you need to use an HTTP Proxy, set it here; defaults to no proxy.
# You can also set this to a comma separated list of HTTP Proxies and they will
# be randomly used (simple load balancing).
# sync_proxy = http://10.1.1.1:8888,http://10.1.1.2:8888
#
# Will sync each container at most once per interval
2011-02-23 23:26:05 -08:00
# interval = 300
#
2011-06-22 15:05:23 +00:00
# Maximum amount of time to spend syncing each container per pass
2011-02-23 23:26:05 -08:00
# container_time = 60
# Note: Put it at the beginning of the pipleline to profile all middleware. But
# it is safer to put this after healthcheck.
[filter:xprofile]
use = egg:swift#xprofile
# This option enable you to switch profilers which should inherit from python
# standard profiler. Currently the supported value can be 'cProfile',
# 'eventlet.green.profile' etc.
# profile_module = eventlet.green.profile
#
# This prefix will be used to combine process ID and timestamp to name the
# profile data file. Make sure the executing user has permission to write
# into this path (missing path segments will be created, if necessary).
# If you enable profiling in more than one type of daemon, you must override
# it with an unique value like: /var/log/swift/profile/container.profile
# log_filename_prefix = /tmp/log/swift/profile/default.profile
#
# the profile data will be dumped to local disk based on above naming rule
# in this interval.
# dump_interval = 5.0
#
# Be careful, this option will enable profiler to dump data into the file with
# time stamp which means there will be lots of files piled up in the directory.
# dump_timestamp = false
#
# This is the path of the URL to access the mini web UI.
# path = /__profile__
#
# Clear the data when the wsgi server shutdown.
# flush_at_shutdown = false
#
# unwind the iterator of applications
# unwind = false