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 = 6000
|
2012-11-26 12:39:46 -08:00
|
|
|
# bind_timeout = 30
|
2010-10-13 21:24:30 +00:00
|
|
|
# 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
|
2012-08-29 19:57:26 +00:00
|
|
|
# disable_fallocate = false
|
2011-10-26 21:42:24 +00:00
|
|
|
# expiring_objects_container_divisor = 86400
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2013-07-11 17:00:57 -07:00
|
|
|
# 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
|
|
|
|
|
#
|
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
|
2012-05-17 15:46:38 -07:00
|
|
|
# log_address = /dev/log
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2012-10-05 15:56:34 -05:00
|
|
|
# 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 =
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
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
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
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
|
2013-01-19 15:25:27 -08:00
|
|
|
# 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 =
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2012-12-06 15:09:53 -06:00
|
|
|
# eventlet_debug = false
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
Added fallocate_reserve option
Some systems behave badly when they completely run out of space. To
alleviate this problem, you can set the fallocate_reserve conf value
to a number of bytes to "reserve" on each disk. When the disk free
space falls at or below this amount, fallocate calls will fail, even
if the underlying OS fallocate call would succeed. For example, a
fallocate_reserve of 5368709120 (5G) would make all fallocate calls
fail, even for zero-byte files, when the disk free space falls under
5G.
The default fallocate_reserve is 0, meaning "no reserve", and so the
software behaves exactly as it always has unless you set this conf
value to something non-zero.
Also fixed ring builder's search_devs doc bugs.
Related: To get rsync to do the same, see
https://github.com/rackspace/cloudfiles-rsync
Specifically, see this patch:
https://github.com/rackspace/cloudfiles-rsync/blob/master/debian/patches/limit-fs-fullness.diff
DocImpact
Change-Id: I8db176ae0ca5b41c9bcfeb7cb8abb31c2e614527
2013-01-25 02:11:19 +00:00
|
|
|
# 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
|
Object replication ssync (an rsync alternative)
For this commit, ssync is just a direct replacement for how
we use rsync. Assuming we switch over to ssync completely
someday and drop rsync, we will then be able to improve the
algorithms even further (removing local objects as we
successfully transfer each one rather than waiting for whole
partitions, using an index.db with hash-trees, etc., etc.)
For easier review, this commit can be thought of in distinct
parts:
1) New global_conf_callback functionality for allowing
services to perform setup code before workers, etc. are
launched. (This is then used by ssync in the object
server to create a cross-worker semaphore to restrict
concurrent incoming replication.)
2) A bit of shifting of items up from object server and
replicator to diskfile or DEFAULT conf sections for
better sharing of the same settings. conn_timeout,
node_timeout, client_timeout, network_chunk_size,
disk_chunk_size.
3) Modifications to the object server and replicator to
optionally use ssync in place of rsync. This is done in
a generic enough way that switching to FutureSync should
be easy someday.
4) The biggest part, and (at least for now) completely
optional part, are the new ssync_sender and
ssync_receiver files. Nice and isolated for easier
testing and visibility into test coverage, etc.
All the usual logging, statsd, recon, etc. instrumentation
is still there when using ssync, just as it is when using
rsync.
Beyond the essential error and exceptional condition
logging, I have not added any additional instrumentation at
this time. Unless there is something someone finds super
pressing to have added to the logging, I think such
additions would be better as separate change reviews.
FOR NOW, IT IS NOT RECOMMENDED TO USE SSYNC ON PRODUCTION
CLUSTERS. Some of us will be in a limited fashion to look
for any subtle issues, tuning, etc. but generally ssync is
an experimental feature. In its current implementation it is
probably going to be a bit slower than rsync, but if all
goes according to plan it will end up much faster.
There are no comparisions yet between ssync and rsync other
than some raw virtual machine testing I've done to show it
should compete well enough once we can put it in use in the
real world.
If you Tweet, Google+, or whatever, be sure to indicate it's
experimental. It'd be best to keep it out of deployment
guides, howtos, etc. until we all figure out if we like it,
find it to be stable, etc.
Change-Id: If003dcc6f4109e2d2a42f4873a0779110fff16d6
2013-08-28 16:10:43 +00:00
|
|
|
#
|
|
|
|
|
# Time to wait while attempting to connect to another backend node.
|
|
|
|
|
# conn_timeout = 0.5
|
|
|
|
|
# Time to wait while sending each chunk of data to another backend node.
|
|
|
|
|
# node_timeout = 3
|
|
|
|
|
# Time to wait while receiving each chunk of data from a client or another
|
|
|
|
|
# backend node.
|
|
|
|
|
# client_timeout = 60
|
|
|
|
|
#
|
|
|
|
|
# network_chunk_size = 65536
|
|
|
|
|
# disk_chunk_size = 65536
|
2010-08-20 00:42:38 +00:00
|
|
|
|
|
|
|
|
[pipeline:main]
|
2012-12-03 16:05:44 -08:00
|
|
|
pipeline = healthcheck recon object-server
|
2010-08-20 00:42:38 +00:00
|
|
|
|
|
|
|
|
[app:object-server]
|
|
|
|
|
use = egg:swift#object
|
2011-01-23 13:18:28 -08:00
|
|
|
# You can override the default log routing for this app here:
|
|
|
|
|
# set log_name = object-server
|
|
|
|
|
# set log_facility = LOG_LOCAL0
|
|
|
|
|
# set log_level = INFO
|
2013-07-21 12:18:24 +08:00
|
|
|
# set log_requests = true
|
2012-05-17 15:46:38 -07:00
|
|
|
# set log_address = /dev/log
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2010-07-12 17:03:45 -05:00
|
|
|
# max_upload_time = 86400
|
2012-04-28 16:31:00 +10:00
|
|
|
# slow = 0
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2012-06-07 16:39:56 -07:00
|
|
|
# Objects smaller than this are not evicted from the buffercache once read
|
|
|
|
|
# keep_cache_size = 5424880
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2012-06-07 16:39:56 -07:00
|
|
|
# If true, objects for authenticated GET requests may be kept in buffer cache
|
|
|
|
|
# if small enough
|
2013-07-21 12:18:24 +08:00
|
|
|
# keep_cache_private = false
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2010-10-13 21:29:58 +00:00
|
|
|
# on PUTs, sync data every n MB
|
|
|
|
|
# mb_per_sync = 512
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2011-03-22 20:05:44 -05:00
|
|
|
# Comma separated list of headers that can be set in metadata on an object.
|
|
|
|
|
# This list is in addition to X-Object-Meta-* headers and cannot include
|
|
|
|
|
# Content-Type, etag, Content-Length, or deleted
|
2013-02-13 12:31:55 -08:00
|
|
|
# allowed_headers = Content-Disposition, Content-Encoding, X-Delete-At, X-Object-Manifest, X-Static-Large-Object
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2012-04-28 16:31:00 +10:00
|
|
|
# auto_create_account_prefix = .
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
Object replication ssync (an rsync alternative)
For this commit, ssync is just a direct replacement for how
we use rsync. Assuming we switch over to ssync completely
someday and drop rsync, we will then be able to improve the
algorithms even further (removing local objects as we
successfully transfer each one rather than waiting for whole
partitions, using an index.db with hash-trees, etc., etc.)
For easier review, this commit can be thought of in distinct
parts:
1) New global_conf_callback functionality for allowing
services to perform setup code before workers, etc. are
launched. (This is then used by ssync in the object
server to create a cross-worker semaphore to restrict
concurrent incoming replication.)
2) A bit of shifting of items up from object server and
replicator to diskfile or DEFAULT conf sections for
better sharing of the same settings. conn_timeout,
node_timeout, client_timeout, network_chunk_size,
disk_chunk_size.
3) Modifications to the object server and replicator to
optionally use ssync in place of rsync. This is done in
a generic enough way that switching to FutureSync should
be easy someday.
4) The biggest part, and (at least for now) completely
optional part, are the new ssync_sender and
ssync_receiver files. Nice and isolated for easier
testing and visibility into test coverage, etc.
All the usual logging, statsd, recon, etc. instrumentation
is still there when using ssync, just as it is when using
rsync.
Beyond the essential error and exceptional condition
logging, I have not added any additional instrumentation at
this time. Unless there is something someone finds super
pressing to have added to the logging, I think such
additions would be better as separate change reviews.
FOR NOW, IT IS NOT RECOMMENDED TO USE SSYNC ON PRODUCTION
CLUSTERS. Some of us will be in a limited fashion to look
for any subtle issues, tuning, etc. but generally ssync is
an experimental feature. In its current implementation it is
probably going to be a bit slower than rsync, but if all
goes according to plan it will end up much faster.
There are no comparisions yet between ssync and rsync other
than some raw virtual machine testing I've done to show it
should compete well enough once we can put it in use in the
real world.
If you Tweet, Google+, or whatever, be sure to indicate it's
experimental. It'd be best to keep it out of deployment
guides, howtos, etc. until we all figure out if we like it,
find it to be stable, etc.
Change-Id: If003dcc6f4109e2d2a42f4873a0779110fff16d6
2013-08-28 16:10:43 +00:00
|
|
|
# A value of 0 means "don't use thread pools". A reasonable starting point is
|
|
|
|
|
# 4.
|
|
|
|
|
# threads_per_disk = 0
|
|
|
|
|
#
|
2012-12-17 06:39:25 -05:00
|
|
|
# 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".
|
2013-07-21 12:18:24 +08:00
|
|
|
# replication_server = false
|
Object replication ssync (an rsync alternative)
For this commit, ssync is just a direct replacement for how
we use rsync. Assuming we switch over to ssync completely
someday and drop rsync, we will then be able to improve the
algorithms even further (removing local objects as we
successfully transfer each one rather than waiting for whole
partitions, using an index.db with hash-trees, etc., etc.)
For easier review, this commit can be thought of in distinct
parts:
1) New global_conf_callback functionality for allowing
services to perform setup code before workers, etc. are
launched. (This is then used by ssync in the object
server to create a cross-worker semaphore to restrict
concurrent incoming replication.)
2) A bit of shifting of items up from object server and
replicator to diskfile or DEFAULT conf sections for
better sharing of the same settings. conn_timeout,
node_timeout, client_timeout, network_chunk_size,
disk_chunk_size.
3) Modifications to the object server and replicator to
optionally use ssync in place of rsync. This is done in
a generic enough way that switching to FutureSync should
be easy someday.
4) The biggest part, and (at least for now) completely
optional part, are the new ssync_sender and
ssync_receiver files. Nice and isolated for easier
testing and visibility into test coverage, etc.
All the usual logging, statsd, recon, etc. instrumentation
is still there when using ssync, just as it is when using
rsync.
Beyond the essential error and exceptional condition
logging, I have not added any additional instrumentation at
this time. Unless there is something someone finds super
pressing to have added to the logging, I think such
additions would be better as separate change reviews.
FOR NOW, IT IS NOT RECOMMENDED TO USE SSYNC ON PRODUCTION
CLUSTERS. Some of us will be in a limited fashion to look
for any subtle issues, tuning, etc. but generally ssync is
an experimental feature. In its current implementation it is
probably going to be a bit slower than rsync, but if all
goes according to plan it will end up much faster.
There are no comparisions yet between ssync and rsync other
than some raw virtual machine testing I've done to show it
should compete well enough once we can put it in use in the
real world.
If you Tweet, Google+, or whatever, be sure to indicate it's
experimental. It'd be best to keep it out of deployment
guides, howtos, etc. until we all figure out if we like it,
find it to be stable, etc.
Change-Id: If003dcc6f4109e2d2a42f4873a0779110fff16d6
2013-08-28 16:10:43 +00:00
|
|
|
#
|
|
|
|
|
# Set to restrict the number of concurrent incoming REPLICATION requests
|
|
|
|
|
# Set to 0 for unlimited
|
|
|
|
|
# Note that REPLICATION is currently an ssync only item
|
|
|
|
|
# replication_concurrency = 4
|
|
|
|
|
#
|
2013-11-09 03:18:11 +00:00
|
|
|
# Restricts incoming REPLICATION requests to one per device,
|
|
|
|
|
# replication_currency above allowing. This can help control I/O to each
|
|
|
|
|
# device, but you may wish to set this to False to allow multiple REPLICATION
|
|
|
|
|
# requests (up to the above replication_concurrency setting) per device.
|
|
|
|
|
# replication_one_per_device = True
|
|
|
|
|
#
|
|
|
|
|
# Number of seconds to wait for an existing replication device lock before
|
|
|
|
|
# giving up.
|
|
|
|
|
# replication_lock_timeout = 15
|
|
|
|
|
#
|
Object replication ssync (an rsync alternative)
For this commit, ssync is just a direct replacement for how
we use rsync. Assuming we switch over to ssync completely
someday and drop rsync, we will then be able to improve the
algorithms even further (removing local objects as we
successfully transfer each one rather than waiting for whole
partitions, using an index.db with hash-trees, etc., etc.)
For easier review, this commit can be thought of in distinct
parts:
1) New global_conf_callback functionality for allowing
services to perform setup code before workers, etc. are
launched. (This is then used by ssync in the object
server to create a cross-worker semaphore to restrict
concurrent incoming replication.)
2) A bit of shifting of items up from object server and
replicator to diskfile or DEFAULT conf sections for
better sharing of the same settings. conn_timeout,
node_timeout, client_timeout, network_chunk_size,
disk_chunk_size.
3) Modifications to the object server and replicator to
optionally use ssync in place of rsync. This is done in
a generic enough way that switching to FutureSync should
be easy someday.
4) The biggest part, and (at least for now) completely
optional part, are the new ssync_sender and
ssync_receiver files. Nice and isolated for easier
testing and visibility into test coverage, etc.
All the usual logging, statsd, recon, etc. instrumentation
is still there when using ssync, just as it is when using
rsync.
Beyond the essential error and exceptional condition
logging, I have not added any additional instrumentation at
this time. Unless there is something someone finds super
pressing to have added to the logging, I think such
additions would be better as separate change reviews.
FOR NOW, IT IS NOT RECOMMENDED TO USE SSYNC ON PRODUCTION
CLUSTERS. Some of us will be in a limited fashion to look
for any subtle issues, tuning, etc. but generally ssync is
an experimental feature. In its current implementation it is
probably going to be a bit slower than rsync, but if all
goes according to plan it will end up much faster.
There are no comparisions yet between ssync and rsync other
than some raw virtual machine testing I've done to show it
should compete well enough once we can put it in use in the
real world.
If you Tweet, Google+, or whatever, be sure to indicate it's
experimental. It'd be best to keep it out of deployment
guides, howtos, etc. until we all figure out if we like it,
find it to be stable, etc.
Change-Id: If003dcc6f4109e2d2a42f4873a0779110fff16d6
2013-08-28 16:10:43 +00:00
|
|
|
# These next two settings control when the REPLICATION subrequest handler will
|
|
|
|
|
# abort an incoming REPLICATION attempt. An abort will occur if there are at
|
|
|
|
|
# least threshold number of failures and the value of failures / successes
|
|
|
|
|
# exceeds the ratio. The defaults of 100 and 1.0 means that at least 100
|
|
|
|
|
# failures have to occur and there have to be more failures than successes for
|
|
|
|
|
# an abort to occur.
|
|
|
|
|
# replication_failure_threshold = 100
|
|
|
|
|
# replication_failure_ratio = 1.0
|
2010-07-12 17:03:45 -05:00
|
|
|
|
2012-12-03 16:05:44 -08: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 =
|
|
|
|
|
|
2011-10-18 21:10:50 +00:00
|
|
|
[filter:recon]
|
|
|
|
|
use = egg:swift#recon
|
2012-05-14 18:01:48 -05:00
|
|
|
#recon_cache_path = /var/cache/swift
|
|
|
|
|
#recon_lock_path = /var/lock
|
2011-10-18 21:10:50 +00:00
|
|
|
|
2010-07-12 17:03:45 -05:00
|
|
|
[object-replicator]
|
2011-01-23 13:18:28 -08:00
|
|
|
# You can override the default log routing for this app here (don't use set!):
|
2010-08-24 13:41:58 +00:00
|
|
|
# log_name = object-replicator
|
2011-01-23 13:18:28 -08:00
|
|
|
# log_facility = LOG_LOCAL0
|
|
|
|
|
# log_level = INFO
|
2012-05-17 15:46:38 -07:00
|
|
|
# log_address = /dev/log
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2010-08-24 14:10:36 +00:00
|
|
|
# vm_test_mode = no
|
2010-07-12 17:03:45 -05:00
|
|
|
# daemonize = on
|
|
|
|
|
# run_pause = 30
|
|
|
|
|
# concurrency = 1
|
2010-10-19 01:05:54 +00:00
|
|
|
# stats_interval = 300
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
Object replication ssync (an rsync alternative)
For this commit, ssync is just a direct replacement for how
we use rsync. Assuming we switch over to ssync completely
someday and drop rsync, we will then be able to improve the
algorithms even further (removing local objects as we
successfully transfer each one rather than waiting for whole
partitions, using an index.db with hash-trees, etc., etc.)
For easier review, this commit can be thought of in distinct
parts:
1) New global_conf_callback functionality for allowing
services to perform setup code before workers, etc. are
launched. (This is then used by ssync in the object
server to create a cross-worker semaphore to restrict
concurrent incoming replication.)
2) A bit of shifting of items up from object server and
replicator to diskfile or DEFAULT conf sections for
better sharing of the same settings. conn_timeout,
node_timeout, client_timeout, network_chunk_size,
disk_chunk_size.
3) Modifications to the object server and replicator to
optionally use ssync in place of rsync. This is done in
a generic enough way that switching to FutureSync should
be easy someday.
4) The biggest part, and (at least for now) completely
optional part, are the new ssync_sender and
ssync_receiver files. Nice and isolated for easier
testing and visibility into test coverage, etc.
All the usual logging, statsd, recon, etc. instrumentation
is still there when using ssync, just as it is when using
rsync.
Beyond the essential error and exceptional condition
logging, I have not added any additional instrumentation at
this time. Unless there is something someone finds super
pressing to have added to the logging, I think such
additions would be better as separate change reviews.
FOR NOW, IT IS NOT RECOMMENDED TO USE SSYNC ON PRODUCTION
CLUSTERS. Some of us will be in a limited fashion to look
for any subtle issues, tuning, etc. but generally ssync is
an experimental feature. In its current implementation it is
probably going to be a bit slower than rsync, but if all
goes according to plan it will end up much faster.
There are no comparisions yet between ssync and rsync other
than some raw virtual machine testing I've done to show it
should compete well enough once we can put it in use in the
real world.
If you Tweet, Google+, or whatever, be sure to indicate it's
experimental. It'd be best to keep it out of deployment
guides, howtos, etc. until we all figure out if we like it,
find it to be stable, etc.
Change-Id: If003dcc6f4109e2d2a42f4873a0779110fff16d6
2013-08-28 16:10:43 +00:00
|
|
|
# The sync method to use; default is rsync but you can use ssync to try the
|
|
|
|
|
# EXPERIMENTAL all-swift-code-no-rsync-callouts method. Once verified as stable
|
|
|
|
|
# and nearly as efficient (or moreso) than rsync, we plan to deprecate rsync so
|
|
|
|
|
# we can move on with more features for replication.
|
|
|
|
|
# sync_method = rsync
|
|
|
|
|
#
|
2010-10-19 01:05:54 +00:00
|
|
|
# max duration of a partition rsync
|
2011-01-27 21:02:53 +00:00
|
|
|
# rsync_timeout = 900
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2013-03-11 11:15:41 -04:00
|
|
|
# bandwith limit for rsync in kB/s. 0 means unlimited
|
|
|
|
|
# rsync_bwlimit = 0
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2010-10-19 01:05:54 +00:00
|
|
|
# passed to rsync for io op timeout
|
2011-01-27 21:02:53 +00:00
|
|
|
# rsync_io_timeout = 30
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
Object replication ssync (an rsync alternative)
For this commit, ssync is just a direct replacement for how
we use rsync. Assuming we switch over to ssync completely
someday and drop rsync, we will then be able to improve the
algorithms even further (removing local objects as we
successfully transfer each one rather than waiting for whole
partitions, using an index.db with hash-trees, etc., etc.)
For easier review, this commit can be thought of in distinct
parts:
1) New global_conf_callback functionality for allowing
services to perform setup code before workers, etc. are
launched. (This is then used by ssync in the object
server to create a cross-worker semaphore to restrict
concurrent incoming replication.)
2) A bit of shifting of items up from object server and
replicator to diskfile or DEFAULT conf sections for
better sharing of the same settings. conn_timeout,
node_timeout, client_timeout, network_chunk_size,
disk_chunk_size.
3) Modifications to the object server and replicator to
optionally use ssync in place of rsync. This is done in
a generic enough way that switching to FutureSync should
be easy someday.
4) The biggest part, and (at least for now) completely
optional part, are the new ssync_sender and
ssync_receiver files. Nice and isolated for easier
testing and visibility into test coverage, etc.
All the usual logging, statsd, recon, etc. instrumentation
is still there when using ssync, just as it is when using
rsync.
Beyond the essential error and exceptional condition
logging, I have not added any additional instrumentation at
this time. Unless there is something someone finds super
pressing to have added to the logging, I think such
additions would be better as separate change reviews.
FOR NOW, IT IS NOT RECOMMENDED TO USE SSYNC ON PRODUCTION
CLUSTERS. Some of us will be in a limited fashion to look
for any subtle issues, tuning, etc. but generally ssync is
an experimental feature. In its current implementation it is
probably going to be a bit slower than rsync, but if all
goes according to plan it will end up much faster.
There are no comparisions yet between ssync and rsync other
than some raw virtual machine testing I've done to show it
should compete well enough once we can put it in use in the
real world.
If you Tweet, Google+, or whatever, be sure to indicate it's
experimental. It'd be best to keep it out of deployment
guides, howtos, etc. until we all figure out if we like it,
find it to be stable, etc.
Change-Id: If003dcc6f4109e2d2a42f4873a0779110fff16d6
2013-08-28 16:10:43 +00:00
|
|
|
# node_timeout = <whatever's in the DEFAULT section or 10>
|
|
|
|
|
# max duration of an http request; this is for REPLICATE finalization calls and
|
|
|
|
|
# so should be longer than node_timeout
|
2010-10-19 01:05:54 +00:00
|
|
|
# http_timeout = 60
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2010-10-19 01:05:54 +00:00
|
|
|
# attempts to kill all workers if nothing replicates for lockup_timeout seconds
|
2011-01-27 21:02:53 +00:00
|
|
|
# lockup_timeout = 1800
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2010-07-12 17:03:45 -05:00
|
|
|
# The replicator also performs reclamation
|
|
|
|
|
# reclaim_age = 604800
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2012-04-28 16:31:00 +10:00
|
|
|
# ring_check_interval = 15
|
2012-05-14 18:01:48 -05:00
|
|
|
# recon_cache_path = /var/cache/swift
|
2013-07-22 22:09:40 +00:00
|
|
|
#
|
|
|
|
|
# limits how long rsync error log lines are
|
|
|
|
|
# 0 means to log the entire line
|
|
|
|
|
# rsync_error_log_line_length = 0
|
2010-07-12 17:03:45 -05:00
|
|
|
|
|
|
|
|
[object-updater]
|
2011-01-23 13:18:28 -08:00
|
|
|
# You can override the default log routing for this app here (don't use set!):
|
2010-08-24 13:41:58 +00:00
|
|
|
# log_name = object-updater
|
2011-01-23 13:18:28 -08:00
|
|
|
# log_facility = LOG_LOCAL0
|
|
|
|
|
# log_level = INFO
|
2012-05-17 15:46:38 -07:00
|
|
|
# log_address = /dev/log
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2010-07-12 17:03:45 -05:00
|
|
|
# interval = 300
|
|
|
|
|
# concurrency = 1
|
Object replication ssync (an rsync alternative)
For this commit, ssync is just a direct replacement for how
we use rsync. Assuming we switch over to ssync completely
someday and drop rsync, we will then be able to improve the
algorithms even further (removing local objects as we
successfully transfer each one rather than waiting for whole
partitions, using an index.db with hash-trees, etc., etc.)
For easier review, this commit can be thought of in distinct
parts:
1) New global_conf_callback functionality for allowing
services to perform setup code before workers, etc. are
launched. (This is then used by ssync in the object
server to create a cross-worker semaphore to restrict
concurrent incoming replication.)
2) A bit of shifting of items up from object server and
replicator to diskfile or DEFAULT conf sections for
better sharing of the same settings. conn_timeout,
node_timeout, client_timeout, network_chunk_size,
disk_chunk_size.
3) Modifications to the object server and replicator to
optionally use ssync in place of rsync. This is done in
a generic enough way that switching to FutureSync should
be easy someday.
4) The biggest part, and (at least for now) completely
optional part, are the new ssync_sender and
ssync_receiver files. Nice and isolated for easier
testing and visibility into test coverage, etc.
All the usual logging, statsd, recon, etc. instrumentation
is still there when using ssync, just as it is when using
rsync.
Beyond the essential error and exceptional condition
logging, I have not added any additional instrumentation at
this time. Unless there is something someone finds super
pressing to have added to the logging, I think such
additions would be better as separate change reviews.
FOR NOW, IT IS NOT RECOMMENDED TO USE SSYNC ON PRODUCTION
CLUSTERS. Some of us will be in a limited fashion to look
for any subtle issues, tuning, etc. but generally ssync is
an experimental feature. In its current implementation it is
probably going to be a bit slower than rsync, but if all
goes according to plan it will end up much faster.
There are no comparisions yet between ssync and rsync other
than some raw virtual machine testing I've done to show it
should compete well enough once we can put it in use in the
real world.
If you Tweet, Google+, or whatever, be sure to indicate it's
experimental. It'd be best to keep it out of deployment
guides, howtos, etc. until we all figure out if we like it,
find it to be stable, etc.
Change-Id: If003dcc6f4109e2d2a42f4873a0779110fff16d6
2013-08-28 16:10:43 +00:00
|
|
|
# node_timeout = <whatever's in the DEFAULT section or 10>
|
2010-07-12 17:03:45 -05:00
|
|
|
# slowdown will sleep that amount between objects
|
|
|
|
|
# slowdown = 0.01
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2012-05-14 18:01:48 -05:00
|
|
|
# recon_cache_path = /var/cache/swift
|
2010-07-12 17:03:45 -05:00
|
|
|
|
|
|
|
|
[object-auditor]
|
2011-01-23 13:18:28 -08:00
|
|
|
# You can override the default log routing for this app here (don't use set!):
|
2010-08-24 13:41:58 +00:00
|
|
|
# log_name = object-auditor
|
2011-01-23 13:18:28 -08:00
|
|
|
# log_facility = LOG_LOCAL0
|
|
|
|
|
# log_level = INFO
|
2012-05-17 15:46:38 -07:00
|
|
|
# log_address = /dev/log
|
2013-06-06 15:35:19 -07:00
|
|
|
#
|
2010-12-28 14:54:00 -08:00
|
|
|
# files_per_second = 20
|
|
|
|
|
# bytes_per_second = 10000000
|
2011-01-27 21:02:53 +00:00
|
|
|
# log_time = 3600
|
2011-02-21 16:37:12 -08:00
|
|
|
# zero_byte_files_per_second = 50
|
2012-05-14 18:01:48 -05:00
|
|
|
# recon_cache_path = /var/cache/swift
|
2013-07-01 14:58:35 -07:00
|
|
|
|
|
|
|
|
# Takes a comma separated list of ints. If set, the object auditor will
|
|
|
|
|
# increment a counter for every object whose size is <= to the given break
|
|
|
|
|
# points and report the result after a full scan.
|
|
|
|
|
# object_size_stats =
|