有効期限オブジェクトのサポート
swift-object-expirerオブジェクトを定期的に削除する機能を提供します。Swift クライアントはオブジェクトの PUT または POST 中にX-Delete-AtまたはX-Delete-Afterヘッダーを使用し、クラスターは指定された時間に自動的にオブジェクトのサービスを停止し、その後すぐにシステムからオブジェクトを削除します。
X-Delete-Atヘッダーは Unix エポック タイムスタンプを整数形式で受け取ります1317070737。Mon Sep 26 20:58:57 2011 UTC
X-Delete-Afterヘッダーには正の整数の秒数が必要です。リクエストを受信するプロキシ サーバーは、リクエストのタイムスタンプと指定された値を使用してこのヘッダーを変換しますX-Delete-At。
X-Delete-AtヘッダーとX-Delete-Afterヘッダーの両方がリクエストとともに送信される場合、X-Delete-Afterヘッダーが優先されます。
期限切れのオブジェクトがシステムに追加されると、オブジェクト サーバーは、後の処理.expiring_objectsのために非表示のアカウントに期限切れを記録しますswift-object-expirer。
通常、クラスターはswift-object-expirerデーモンの 1 つのインスタンスを実行するだけで済みます。これは正確には自動フェイルオーバーの高可用性ではありませんが、このデーモンが数時間実行されていなければ、実際的な問題は発生しません。有効期限が切れているがまだ削除されていないオブジェクトに対して誰かがGETORを試みた場合HEAD、それらのオブジェクトは404 Not Found後でデーモンが再起動されたときに削除されます。
デフォルトでは、swift-object-expirerデーモンは同時実行数 1 で実行されます。同時実行性を高めるには、この値を増やします。特定の Swift クラスターの場合、同時実行数 1 では期限切れのオブジェクトを適時に削除できない場合があります。
複数の同時実行性を持つ単一プロセスでは不十分な場合は、複数のデーモン プロセスを実行してジョブのさまざまな部分を完了できます (詳細については、サンプル構成ファイルを参照してください)。
複数のプロセスとして実行するにはswift-object-expirer、processes(構成ファイルまたはコマンドラインで) プロセスの数を設定します。次に、パーツごとにプロセスを実行します。使用processコマンド ラインまたは構成を通じて、プロセスによって実行される作業の部分を指定します。したがって、たとえば、3 つのプロセスを実行する場合はprocesses3 に設定し、process3 つのプロセスを実行するには 0、1、2 に設定します。複数のプロセスを使用する場合は、ジョブの各部分に対して 1 つのプロセスを実行する必要があります。そうしないと、ジョブのその部分が完了しません。
デフォルトでは、デーモンは 2 つの異なる構成ファイルを検索します。プロセスが開始されると、/etc/swift/object-server.conf構成の一部が検索されます[object-expirer]。セクションまたは構成が欠落している場合は、/etc/swift/object-expirer.confその構成を検索して使用します。後者の構成ファイルは非推奨とみなされ、クラスターのアップグレードを支援するために検索されています。
アップグレードの影響: ユニバーサル タスク キューと従来のキュー
期限切れデーモンは、すべてのオブジェクト サーバー間で作業を分散する新しい共通タスク キュー ベースの設計に移行するため、オブジェクト サーバー構成で定義された期限切れのみが新しいシステムを使用できます。両方のファイルのパラメータは同じですが、[object-expirer]オブジェクト サーバー セクションの新しいオプションを除きdequeue_from_legacy、これTrueを に、新しいタスク キュー システムの使用に加えて、古い (間もなく非推奨になる) キューをチェックするように Expirer に指示します。 。
説明する
新しいタスクキューシステムはまだ完成していません。したがって、有効期限
dequeue_from_legacyを に設定してもFalse、現時点では効果がありません。
デフォルトはdequeue_from_legacyですFalse。これは、古い有効期限キューから移行するときに明示的に設定する必要がありますTrue。
古い構成を使用する期限切れ機能は、/etc/swift/object-expirer.conf新しいユニバーサル タスク キューを使用しません。これは無視されdequeue_from_legacy、古いキューのみがチェックされます。これは、従来の有効期限切れ機能として実行されることを意味します。
何でこれが大切ですか？オブジェクト期限切れ設定がオブジェクト ストレージ ノードではないノードで現在実行されている場合、それらは当面は引き続き機能しますが、古いキューから削除されるだけです。新しいユニバーサル タスク キューが導入されると、追加された新しいオブジェクトを削除できるように、オブジェクト サーバー上で有効期限切れプログラムが実行されている必要があります。この状況に陥った場合は、object-server.conf新しいキューを処理するために新しい有効期限切れセクションを安全に設定し、古い有効期限切れ設定を別の場所で実行することができます。
ただし、古い期限切れがオブジェクト サーバー (最も一般的なトポロジ) で実行されている場合は、新しいキューを処理するために新しい部分がすべてのオブジェクト サーバーに追加されます。古いキューをチェックする有効期限切れの数を同じに保つには、以前と同じ数のノードを選択し、それらのノードでのみ有効にしますdequeue_from_legacy。また、これらのノードでは、レガシー キューの同時実行レベルを維持するために、レガシー キューprocessとprocessesオプションを保持する必要があることにも注意してください。
説明する
dequeue_from_legacyすべての従来のタスクは非表示のアカウントと同じ非表示のコンテナーに保存されるため、有効期限が多すぎないように注意してください。大規模なクラスターでは、従来の有効期限切れキューを処理するアカウント/コンテナー サーバーに誤って過負荷がかかる可能性があります。
object-expirer以下に、 で必要なセクションの簡単なサンプルを示しますobject-server.conf。
object-server.conf以下に、で必要な部品の簡単な例を示しますobject-expirer。
[object-expirer]
# log_name = object-expirer
# log_facility = LOG_LOCAL0
# log_level = INFO
# log_address = /dev/log
#
interval = 300
# If this true, expirer execute tasks in legacy expirer task queue
dequeue_from_legacy = false
# processes can only be used in conjunction with `dequeue_from_legacy`.
# So this option is ignored if dequeue_from_legacy=false.
# processes is how many parts to divide the legacy work into, one part per
# process that will be doing the work
# processes set 0 means that a single legacy process will be doing all the work
# processes can also be specified on the command line and will override the
# config value
# processes = 0
# process can only be used in conjunction with `dequeue_from_legacy`.
# So this option is ignored if dequeue_from_legacy=false.
# process is which of the parts a particular legacy process will work on
# process can also be specified on the command line and will override the config
# value
# process is "zero based", if you want to use 3 processes, you should run
# processes with process set to 0, 1, and 2
# process = 0
report_interval = 300
# request_tries is the number of times the expirer's internal client will
# attempt any given request in the event of failure. The default is 3.
# request_tries = 3
# concurrency is the level of concurrency to use to do the work, this value
# must be set to at least 1
# concurrency = 1
# The expirer will re-attempt expiring if the source object is not available
# up to reclaim_age seconds before it gives up and deletes the entry in the
# queue.
# reclaim_age = 604800
object-expirer.conf完全を期すために、従来のファイルの簡単な例を次に示します。
[DEFAULT]
# swift_dir = /etc/swift
# user = swift
# You can specify default log routing here if you want:
# log_name = swift
# log_facility = LOG_LOCAL0
# log_level = INFO
[object-expirer]
interval = 300
[pipeline:main]
pipeline = catch_errors cache proxy-server
[app:proxy-server]
use = egg:swift#proxy
# See proxy-server.conf-sample for options
[filter:cache]
use = egg:swift#memcache
# See proxy-server.conf-sample for options
[filter:catch_errors]
use = egg:swift#catch_errors
# See proxy-server.conf-sample for options
説明する
レガシー エクスパイラを実行する場合、デーモンはクラスタ内のすべてのバックエンド サーバーにアクセスできるマシン上で実行する必要がありますが、プロキシ サーバーやパブリック アクセスは必要ありません。デーモンは、内部プロキシ コードの独自のインスタンスを使用してバックエンド サーバーにアクセスします。