ab93e636b8
Brief Summary:
Added Modules and Lab Sections of Aptira's Existing
OpenStack Training Docs. Please do refer Full Summary
for more details.
For those who want to review this and save some time on
building it, I have hosted the content on
http://office.aptira.in
Please talk to Sean Robetrs if you are concerened about
repetition of Doc Content or similar issues like short URLs
etc., this is supposed to be a rough patch and not final.
Full Summary:
Added the following modules.
1. Module001 - Introduction To OpenStack.
- Brief Overview of OpenStack.
- Basic Concepts
- Detailed Description of Core
Projects (Grizzly) under OpenStack.
- All But Networking and Swift.
2. Module002 - OpenStack Networking In detail.
3. Module003 - OpenStack Object Storage In detail.
4. Lab001 - OpenStack Control Node and Compute Node.
5. Lab002 - OpenStack Network Node.
Full Summary added due to the size of the commit. I Apologize
for the size of this commit and will try not to commit huge
content like in this patch. The reason for the size of this
commit is to meet OpenStack Training Sprint day.
bp/training-manuals
Change-Id: Ie3c44527992868b4d9571b66cc1c048e558ec669
58 lines
3.5 KiB
XML
58 lines
3.5 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||
version="5.0"
|
||
xml:id="module003-ch008-account-reaper">
|
||
<title>Account Reaper</title>
|
||
<para>The Account Reaper removes data from deleted accounts in the
|
||
background.</para>
|
||
<para>An account is marked for deletion by a reseller issuing a
|
||
DELETE request on the account’s storage URL. This simply puts
|
||
the value DELETED into the status column of the account_stat
|
||
table in the account database (and replicas), indicating the
|
||
data for the account should be deleted later.</para>
|
||
<para>There is normally no set retention time and no undelete; it
|
||
is assumed the reseller will implement such features and only
|
||
call DELETE on the account once it is truly desired the
|
||
account’s data be removed. However, in order to protect the
|
||
Swift cluster accounts from an improper or mistaken delete
|
||
request, you can set a delay_reaping value in the
|
||
[account-reaper] section of the account-server.conf to delay
|
||
the actual deletion of data. At this time, there is no utility
|
||
to undelete an account; one would have to update the account
|
||
database replicas directly, setting the status column to an
|
||
empty string and updating the put_timestamp to be greater than
|
||
the delete_timestamp. (On the TODO list is writing a utility
|
||
to perform this task, preferably through a ReST call.)</para>
|
||
<para>The account reaper runs on each account server and scans the
|
||
server occasionally for account databases marked for deletion.
|
||
It will only trigger on accounts that server is the primary
|
||
node for, so that multiple account servers aren’t all trying
|
||
to do the same work at the same time. Using multiple servers
|
||
to delete one account might improve deletion speed, but
|
||
requires coordination so they aren’t duplicating effort. Speed
|
||
really isn’t as much of a concern with data deletion and large
|
||
accounts aren’t deleted that often.</para>
|
||
<para>The deletion process for an account itself is pretty
|
||
straightforward. For each container in the account, each
|
||
object is deleted and then the container is deleted. Any
|
||
deletion requests that fail won’t stop the overall process,
|
||
but will cause the overall process to fail eventually (for
|
||
example, if an object delete times out, the container won’t be
|
||
able to be deleted later and therefore the account won’t be
|
||
deleted either). The overall process continues even on a
|
||
failure so that it doesn’t get hung up reclaiming cluster
|
||
space because of one troublesome spot. The account reaper will
|
||
keep trying to delete an account until it eventually becomes
|
||
empty, at which point the database reclaim process within the
|
||
db_replicator will eventually remove the database
|
||
files.</para>
|
||
<para>Sometimes a persistent error state can prevent some object
|
||
or container from being deleted. If this happens, you will see
|
||
a message such as “Account <name> has not been reaped
|
||
since <date>” in the log. You can control when this is
|
||
logged with the reap_warn_after value in the [account-reaper]
|
||
section of the account-server.conf file. By default this is 30
|
||
days.</para>
|
||
</chapter> |