Unterstützung für Ablaufobjekte
swift-object-expirerBietet die Funktion zum regelmäßigen Löschen von Objekten. Der Swift-Client verwendet X-Delete-Atden X-Delete-AfterHeader „or“ während des PUT- oder POST-Vorgangs eines Objekts, und der Cluster stellt das Objekt zum angegebenen Zeitpunkt automatisch außer Betrieb und löscht das Objekt kurz danach aus dem System.
X-Delete-AtDer Header nimmt einen Unix Epoch-Zeitstempel in ganzzahliger Form an ; 1317070737z. B.Mon Sep 26 20:58:57 2011 UTC
X-Delete-AfterDer Header erfordert eine positive Ganzzahl in Sekunden. Der Proxyserver, der die Anfrage empfängt, konvertiert diesen Header unter Verwendung des Zeitstempels der Anfrage und des angegebenen Werts X-Delete-At.
Wenn X-Delete-Atbeide X-Delete-AfterHeader mit der Anfrage gesendet werden, X-Delete-Afterhaben die Header Vorrang.
Wenn dem System ein abgelaufenes Objekt hinzugefügt wird, protokolliert der Objektserver .expiring_objectsden Ablauf zur späteren Verarbeitung in einem versteckten Konto swift-object-expirer.
swift-object-expirerNormalerweise muss ein Cluster nur eine Instanz des Daemons ausführen . Dabei handelt es sich zwar nicht gerade um eine automatische Failover-Hochverfügbarkeit, aber wenn dieser Daemon einige Stunden lang nicht ausgeführt wird, treten keine wirklichen Probleme auf. GETWenn jemand versucht, Objekte zu ORen , die abgelaufen, aber noch nicht gelöscht sind HEAD, werden diese Objekte 404 Not Foundspäter beim Neustart des Daemons trotzdem gelöscht.
Standardmäßig swift-object-expirerwird der Daemon mit der Parallelität 1 ausgeführt. Erhöhen Sie diesen Wert, um mehr Parallelität zu erreichen. Für einen bestimmten Swift-Cluster reicht eine Parallelität von 1 möglicherweise nicht aus, um abgelaufene Objekte rechtzeitig zu entfernen.
Wenn ein einzelner Prozess mit mehr als einer Parallelität nicht ausreicht, können Sie mehrere Daemon-Prozesse ausführen, um verschiedene Teile des Auftrags abzuschließen (Einzelheiten finden Sie in der Beispielkonfigurationsdatei).
Um swift-object-expirerals mehrere Prozesse auszuführen, processeslegen Sie die Anzahl der Prozesse fest (in der Konfigurationsdatei oder in der Befehlszeile). Führen Sie dann für jedes Teil einen Prozess aus. Verwendung Geben Sie processden Teil der Arbeit an, der von einem Prozess über die Befehlszeile oder Konfiguration ausgeführt werden soll. Wenn Sie beispielsweise drei Prozesse ausführen möchten, processesstellen Sie den Wert auf 3 und processdie Werte 0, 1 und 2 ein, um drei Prozesse auszuführen. Wenn Sie mehrere Prozesse verwenden, ist es notwendig, für jeden Teil des Jobs einen Prozess auszuführen, andernfalls wird dieser Teil des Jobs nicht abgeschlossen.
Standardmäßig sucht der Daemon nach zwei verschiedenen Konfigurationsdateien. Beim Start sucht der Prozess /etc/swift/object-server.confnach Teilen der Konfiguration [object-expirer]. Wenn der Abschnitt oder die Konfiguration fehlt, wird nach /etc/swift/object-expirer.confder Konfiguration gesucht und diese verwendet. Die letztgenannte Konfigurationsdatei gilt als veraltet und wird derzeit durchsucht, um Cluster-Upgrades zu unterstützen.
Auswirkungen des Upgrades: Universelle Aufgabenwarteschlange und herkömmliche Warteschlange
Der Ablaufdämon wird zu einem neuen, auf gemeinsamen Aufgabenwarteschlangen basierenden Design umgestellt, das die Arbeit auf alle Objektserver verteilt, sodass nur in der Objektserverkonfiguration definierte Ablaufprogramme das neue System verwenden können. Die Parameter in beiden Dateien sind die gleichen, mit Ausnahme [object-expirer]einer neuen Option im Objektserverabschnitt, dequeue_from_legacydie, wenn sie Trueauf , Expirer anweist, zusätzlich zur Verwendung des neuen Aufgabenwarteschlangensystems auch die alte (bald veraltete) Warteschlange zu überprüfen .
veranschaulichen
Das neue Aufgabenwarteschlangensystem ist noch nicht vollständig. Daher hat
dequeue_from_legacydie Einstellung des Ablaufdatums derzeit keine Auswirkung.False
Der Standardwert dequeue_from_legacyist False, der bei der Migration aus der alten Ablaufwarteschlange explizit festgelegt werden muss True.
Jeder Ablaufrechner, der die alte Konfiguration verwendet, /etc/swift/object-expirer.confverwendet nicht die neue universelle Aufgabenwarteschlange. Es wird es ignorieren dequeue_from_legacyund nur die alte Warteschlange überprüfen. Dies bedeutet, dass es als Legacy-Ablaufprogramm ausgeführt wird.
Warum ist das wichtig? Wenn aktuell Objektabläufe auf einem Knoten laufen, der kein Objektspeicherknoten ist, funktionieren diese vorerst noch, werden aber nur aus der alten Warteschlange ausgeworfen. Wenn eine neue universelle Aufgabenwarteschlange eingeführt wird, muss Expirer auf dem Objektserver ausgeführt werden, damit alle neu hinzugefügten Objekte gelöscht werden können. Wenn Sie sich in dieser Situation befinden, können Sie sicher object-server.confeinen neuen Ablaufabschnitt einrichten, um die neue Warteschlange zu verwalten, und die alten Ablaufabschnitte an anderer Stelle laufen lassen.
Wenn der alte Expirer jedoch auf Objektservern ausgeführt wird (die häufigste Topologie), werden allen Objektservern neue Teile hinzugefügt, um die neuen Warteschlangen zu verarbeiten. Um die gleiche Anzahl von Abläufen beizubehalten, die die alte Warteschlange überprüfen, wählen Sie dieselbe Anzahl von Knoten wie zuvor aus und aktivieren Sie die Funktion nur auf diesen Knoten dequeue_from_legacy. Beachten Sie außerdem, dass auf diesen Knoten das Legacy processund processesdie Optionen beibehalten werden müssen, um die Parallelitätsebenen der Legacy-Warteschlangen aufrechtzuerhalten.
veranschaulichen
Achten Sie darauf, es nicht bei zu vielen Abläufen zu aktivieren
dequeue_from_legacy, da alle Legacy-Aufgaben in einem versteckten Konto und demselben versteckten Container gespeichert werden. Bei großen Clustern ist es möglich, dass Konto-/Containerserver, die veraltete Ablaufwarteschlangen verarbeiten, unbeabsichtigt überlastet werden.
Hier ist ein kurzes Beispiel des object-expirererforderlichen Abschnitts object-server.conf:
Hier ist ein kurzes Beispiel der object-server.confbenötigten Teile in 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
Der Vollständigkeit halber hier ein object-expirer.confkurzes Beispiel einer herkömmlichen Datei:
[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
veranschaulichen
Beim Ausführen von Legacy-Expirer muss der Daemon auf einem Computer ausgeführt werden, der Zugriff auf alle Backend-Server im Cluster hat, jedoch keinen Proxyserver oder öffentlichen Zugriff benötigt. Der Daemon verwendet seine eigene Instanz des internen Proxy-Codes, um auf den Backend-Server zuzugreifen.