You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/source/admin_guide.rst
+51-12Lines changed: 51 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,11 @@ Administrator's Guide
6
6
Managing the Rings
7
7
------------------
8
8
9
-
You need to build the storage rings on the proxy server node, and distribute them to all the servers in the cluster. Storage rings contain information about all the Swift storage partitions and how they are distributed between the different nodes and disks. For more information see :doc:`overview_ring`.
9
+
You need to build the storage rings on the proxy server node, and
10
+
distribute them to all the servers in the cluster. Storage rings
11
+
contain information about all the Swift storage partitions and how
12
+
they are distributed between the different nodes and disks. For more
13
+
information see :doc:`overview_ring`.
10
14
11
15
Removing a device from the ring::
12
16
@@ -37,7 +41,8 @@ Scripting Ring Creation
37
41
-----------------------
38
42
You can create scripts to create the account and container rings and rebalance. Here's an example script for the Account ring. Use similar commands to create a make-container-ring.sh script on the proxy server node.
39
43
40
-
1. Create a script file called make-account-ring.sh on the proxy server node with the following content::
44
+
1. Create a script file called make-account-ring.sh on the proxy
45
+
server node with the following content::
41
46
42
47
#!/bin/bash
43
48
cd /etc/swift
@@ -47,14 +52,25 @@ You can create scripts to create the account and container rings and rebalance.
You need to replace the values of <account-server-1>, <account-server-2>, etc. with the IP addresses of the account servers used in your setup. You can have as many account servers as you need. All account servers are assumed to be listening on port 6002, and have a storage device called "sdb1" (this is a directory name created under /drives when we setup the account server). The "z1", "z2", etc. designate zones, and you can choose whether you put devices in the same or different zones.
55
+
You need to replace the values of <account-server-1>,
56
+
<account-server-2>, etc. with the IP addresses of the account
57
+
servers used in your setup. You can have as many account servers as
58
+
you need. All account servers are assumed to be listening on port
59
+
6002, and have a storage device called "sdb1" (this is a directory
60
+
name created under /drives when we setup the account server). The
61
+
"z1", "z2", etc. designate zones, and you can choose whether you
62
+
put devices in the same or different zones.
51
63
52
64
2. Make the script file executable and run it to create the account ring file::
53
65
54
66
chmod +x make-account-ring.sh
55
67
sudo ./make-account-ring.sh
56
68
57
-
3. Copy the resulting ring file /etc/swift/account.ring.gz to all the account server nodes in your Swift environment, and put them in the /etc/swift directory on these nodes. Make sure that every time you change the account ring configuration, you copy the resulting ring file to all the account nodes.
69
+
3. Copy the resulting ring file /etc/swift/account.ring.gz to all the
70
+
account server nodes in your Swift environment, and put them in the
71
+
/etc/swift directory on these nodes. Make sure that every time you
72
+
change the account ring configuration, you copy the resulting ring
73
+
file to all the account nodes.
58
74
59
75
-----------------------
60
76
Handling System Updates
@@ -385,11 +401,26 @@ Swift Orphans
385
401
386
402
Swift Orphans are processes left over after a reload of a Swift server.
387
403
388
-
For example, when upgrading a proxy server you would probaby finish with a `swift-init proxy-server reload` or `/etc/init.d/swift-proxy reload`. This kills the parent proxy server process and leaves the child processes running to finish processing whatever requests they might be handling at the time. It then starts up a new parent proxy server process and its children to handle new incoming requests. This allows zero-downtime upgrades with no impact to existing requests.
389
-
390
-
The orphaned child processes may take a while to exit, depending on the length of the requests they were handling. However, sometimes an old process can be hung up due to some bug or hardware issue. In these cases, these orphaned processes will hang around forever. `swift-orphans` can be used to find and kill these orphans.
391
-
392
-
`swift-orphans` with no arguments will just list the orphans it finds that were started more than 24 hours ago. You shouldn't really check for orphans until 24 hours after you perform a reload, as some requests can take a long time to process. `swift-orphans -k TERM` will send the SIG_TERM signal to the orphans processes, or you can `kill -TERM` the pids yourself if you prefer.
404
+
For example, when upgrading a proxy server you would probaby finish
405
+
with a `swift-init proxy-server reload` or `/etc/init.d/swift-proxy
406
+
reload`. This kills the parent proxy server process and leaves the
407
+
child processes running to finish processing whatever requests they
408
+
might be handling at the time. It then starts up a new parent proxy
409
+
server process and its children to handle new incoming requests. This
410
+
allows zero-downtime upgrades with no impact to existing requests.
411
+
412
+
The orphaned child processes may take a while to exit, depending on
413
+
the length of the requests they were handling. However, sometimes an
414
+
old process can be hung up due to some bug or hardware issue. In these
415
+
cases, these orphaned processes will hang around
416
+
forever. `swift-orphans` can be used to find and kill these orphans.
417
+
418
+
`swift-orphans` with no arguments will just list the orphans it finds
419
+
that were started more than 24 hours ago. You shouldn't really check
420
+
for orphans until 24 hours after you perform a reload, as some
421
+
requests can take a long time to process. `swift-orphans -k TERM` will
422
+
send the SIG_TERM signal to the orphans processes, or you can `kill
423
+
-TERM` the pids yourself if you prefer.
393
424
394
425
You can run `swift-orphans --help` for more options.
395
426
@@ -398,6 +429,14 @@ You can run `swift-orphans --help` for more options.
398
429
Swift Oldies
399
430
------------
400
431
401
-
Swift Oldies are processes that have just been around for a long time. There's nothing necessarily wrong with this, but it might indicate a hung process if you regularly upgrade and reload/restart services. You might have so many servers that you don't notice when a reload/restart fails, `swift-oldies` can help with this.
402
-
403
-
For example, if you upgraded and reloaded/restarted everything 2 days ago, and you've already cleaned up any orphans with `swift-orphans`, you can run `swift-oldies -a 48` to find any Swift processes still around that were started more than 2 days ago and then investigate them accordingly.
432
+
Swift Oldies are processes that have just been around for a long
433
+
time. There's nothing necessarily wrong with this, but it might
434
+
indicate a hung process if you regularly upgrade and reload/restart
435
+
services. You might have so many servers that you don't notice when a
436
+
reload/restart fails, `swift-oldies` can help with this.
437
+
438
+
For example, if you upgraded and reloaded/restarted everything 2 days
439
+
ago, and you've already cleaned up any orphans with `swift-orphans`,
440
+
you can run `swift-oldies -a 48` to find any Swift processes still
441
+
around that were started more than 2 days ago and then investigate
0 commit comments