Installing Object Storage (Swift)
You can provide cloud-based object storage for archival backups, content delivery networks (CDN), and more scalable, high-availability, high-performing storage use cases. Here's how to install it.
Contents
Pre-requisites for Swift
Object Storage (Swift) is intended to run on commodity hardware, meaning any computers that run Linux or Windows typically will do. Generally we do not recommend RAID due to performance degradation since it doesn't match Swift's design well.
You can install Swift with an all-in-one virtual machine by following instructions here: http://swift.openstack.org/development_saio.html.
Installing Swift (packaged release)
Step 1: Downloading the Swift packaged software
Download the released package at http://launchpad.net/swift/1.1/1.1.0-rc/+download/swift-1.1.0-rc1.tar.gz.
Extract the file to the server where you want to install and run Swift. For a multi-server installation you can copy the files where you need them.
tar xvzf swift-1.1.0-rc1.tar.gz
Step 2: Compile the code Switch to the directory where you extracted the Swift code and then run this python install command.
sudo python setup.py install
Step 3: Generate the ring files, add devices to the ring, and rebalance
You use the swift-ring-builder command line tool to build the ring. Here are scripts to ready Swift for action.
~/bin/resetswift.
swift-init all stop sleep 5 sudo umount /mnt/sdb1 sudo mkfs.xfs -f -i size=1024 /dev/sdb1 sudo mount /mnt/sdb1 sudo mkdir /mnt/sdb1/1 /mnt/sdb1/2 /mnt/sdb1/3 /mnt/sdb1/4 /mnt/sdb1/test sudo chown <your-user-name>:<your-group-name> /mnt/sdb1/* mkdir -p /srv/1/node/sdb1 /srv/2/node/sdb2 /srv/3/node/sdb3 /srv/4/node/sdb4 sudo rm -f /var/log/debug /var/log/messages /var/log/rsyncd.log /var/log/syslog sudo service rsyslog restart sudo service memcached restart
~/bin/remakerings:
cd /etc/swift rm -f *.builder *.ring.gz backups/*.builder backups/*.ring.gz swift-ring-builder object.builder create 18 3 1 swift-ring-builder object.builder add z1-127.0.0.1:6010/sdb1 1 swift-ring-builder object.builder add z2-127.0.0.1:6020/sdb2 1 swift-ring-builder object.builder add z3-127.0.0.1:6030/sdb3 1 swift-ring-builder object.builder add z4-127.0.0.1:6040/sdb4 1 swift-ring-builder object.builder rebalance swift-ring-builder container.builder create 18 3 1 swift-ring-builder container.builder add z1-127.0.0.1:6011/sdb1 1 swift-ring-builder container.builder add z2-127.0.0.1:6021/sdb2 1 swift-ring-builder container.builder add z3-127.0.0.1:6031/sdb3 1 swift-ring-builder container.builder add z4-127.0.0.1:6041/sdb4 1 swift-ring-builder container.builder rebalance swift-ring-builder account.builder create 18 3 1 swift-ring-builder account.builder add z1-127.0.0.1:6012/sdb1 1 swift-ring-builder account.builder add z2-127.0.0.1:6022/sdb2 1 swift-ring-builder account.builder add z3-127.0.0.1:6032/sdb3 1 swift-ring-builder account.builder add z4-127.0.0.1:6042/sdb4 1 swift-ring-builder account.builder rebalance
- ~/bin/startmain:
swift-init auth-server start swift-init proxy-server start swift-init account-server start swift-init container-server start swift-init object-server start
~/bin/startrest:
# Replace devauth with whatever your super_admin key is (recorded in # /etc/swift/auth-server.conf). swift-auth-recreate-accounts -K devauth swift-init object-updater start swift-init container-updater start swift-init object-replicator start swift-init container-replicator start swift-init account-replicator start swift-init object-auditor start swift-init container-auditor start swift-init account-auditor start swift-init account-reaper start
Step 4: Create configuration files for each server
Swift uses paste.deploy to manage server configurations, which is a Python-based system for finding and configuring WSGI applications and servers.
Default configuration options are set in the [DEFAULT] section, and any options specified there can be overridden in any of the other sections.
These are the files that are included in the source code repository. Some have been added with the Austin release for stats logging and a swift.conf that maintains the hash.
- etc/rsyncd.conf-sample
- etc/drive-audit.conf-sample
- etc/stats.conf-sample
- etc/log-processing.conf-sample
- etc/swift.conf-sample
- etc/auth-server.conf-sample
- etc/object-server.conf-sample
- etc/container-server.conf-sample
- etc/account-server.conf-sample
- etc/proxy-server.conf-sample
Here are the basic steps. Configuration options are documented in the Swift developer documentation.
- Create /etc/swift/auth-server.conf.
- Create /etc/swift/proxy-server.conf.
- Create /etc/swift/account-server/1.conf, 2.conf, 3.conf, 4.conf, and so on until each account server has a conf file.
- Create /etc/swift/container-server/1.conf, 2.conf, 3.conf, 4.conf, and so on for each container server.
For these configuration files, set devices= to a directory where a set of mount points can be found. The system is set up to allow many drives per server. For instance, at Rackspace we often have systems with devices=/srv/node. If you do ls /srv/node you'd see:
sda sdc sde sdg sdi sdk sdm sdo sdq sds sdu sdw sdb sdd sdf sdh sdj sdl sdn sdp sdr sdt sdv sdx
Each one of those being a separate mount point and therefore device.
One possible convention is to create an /srv/node directory and mount sdb1 at /srv/node/sdb1 and set devices=/srv/node.
Step 4: Start Swift
- Create a startup script, such as:
swift-init auth-server start swift-init proxy-server start swift-init account-server start swift-init container-server start swift-init object-server start
- Give execute permissions for the files in /bin.