OpenStack's Swift installation notes

In the smooth installation of the deployment of Keystone, the original thought of Swift installation and commissioning will be like Keystone general, but the process is full of frustrations, in combination with some of the source code functions, finally successfully completed the installation of Swift, and experimented with uploading and downloading files and other functions, The following is an overview of Swift's installation process and a summary of the problems encountered, hoping to enlighten or help people who are experiencing the same problems. The installation process continues to refer to the official installation manual for OpenStack, but adds some details. Before installing, let's briefly describe what Swift is and what its main functions are. OpenStack Object Storage (Swift) is a multi-tenant, highly scalable object storage system that manages a large amount of unstructured data through the RESTful HTTP API and must have at least identity services (KeyStone) installed before the object store is deployed. Swift includes components such as:
Proxy Server (Swift-proxy-server): accepts object storage APIs and HTTP requests to pass files, modifies metadata, and creates containers, and also provides a list of files or containers to the browser.  To improve performance, the proxy server can use an optional cache, typically selecting memcache to deploy with the proxy server. Account Service (Account-server): Manages the accounts in the object store. Container Service (Container-server): Manages the mapping of containers or folders in object storage.  Object Services (Object-server): Manages the actual objects on the storage node, such as files. WSGI Intermediate Layer: Process authentication, usually identity service (KeyStone). Periodic processes: Performing various maintenance tasks in the cluster, such as replication (replicator) services to ensure consistency and availability of data in the cluster, among others: Auditor, Updater, and Reaper.

The proxy service relies on authentication and authorization mechanisms, and if the identity service is used to complete authentication and authorization, the first step is to create Swift's authentication information and endpoint in the Keystone before you configure management Swift. The object is stored on the control node and does not work with SQL databases. Since the Keystone has been successfully deployed, this is not the time to repeat the Keystone installation process and go directly to Swift's installation. This installation is in a single node of the virtual machine, that is, control nodes and storage nodes deployed in the same host, operating system for CentOS7.1. First, create Swift's users, services, and endpoint in Keystone, with specific commands and results as follows:

[Openstack@localhost ~]$ Keystone user-create--name Swift--pass 123456 +----------+--------------------------------- -+
|              Property |
Value |  +----------+----------------------------------+
|                                  email | |
|               Enabled |    True | | ID |   ED4F45AC3E8A4AC683D54B642E61AC04 | |              name | Swift | |              Username |
Swift | +----------+----------------------------------+ Keystone User-role-add--user Swift--role admin--tenant service [ Openstack@localhost ~]$ Keystone service-create--name Swift--type Object-store +-------------+----------------------   ------------+
|              Property |
Value | +-------------+----------------------------------+
|                                  Description |   |
|               Enabled |      True | | ID |     094cc0da43e348f8b792f77ef99f8e7e | |              name |       Swift        |
|           Type |
Object-store | +-------------+----------------------------------+ [openstack@localhost ~]$ Keystone Endpoint-create--region Regionone--service Swift--publicurl ' http://localhost:8080/v1/AUTH_% (tenant_id) s '--internalurl ' http://localhost : 8080/v1/auth_% (tenant_id) s '--adminurl ' http://localhost:8080/v1/AUTH_% (tenant_id) s ' +-------------+------------   -----------------------------------------------------+
|                              Property |
Value |   +-------------+-----------------------------------------------------------------+
|                    Adminurl |      http://locoalhost:8080/v1/| |                 ID | C0DA7D196E204E038766740E405DBBCE | | InternalUrl |  http://locoalhost:8080/v1/AUTH_2835009c452b4d408f95ff5a920fc877 | | Publicurl |    http://locoalhost:8080/v1/AUTH_2835009c452b4d408f95ff5a920fc877 | |                            Region |  Regionone                          |
|                 service_id |
094cc0da43e348f8b792f77ef99f8e7e |
 +-------------+-----------------------------------------------------------------+

Then install the Proxy-server,swift client, memcached, and so on: Yum install Openstack-swift-proxy python-swiftclient Python-keystone-auth-token python-keystonemiddleware memcached. The Python-keystone-auth-token in the above command is not installed and will be reported as an exception message when using Yum Installation: No package python-keystone-auth-token available.  After confirming on the website of OpenStack, this problem belongs to the error in the document, ignore this problem directly or execute yum install openstack-swift-proxy python-swiftclient Python-keystonemiddleware memcached. After the installation is complete, execute the following command to download the proxy-server.conf file:

Curl-o/etc/swift/proxy-server.conf https://raw.githubusercontent.com/openstack/swift/stable/juno/etc/ Proxyserver.conf-sample

After downloading, you need to modify the configuration parameters in the file, the specific contents are as follows:

Specify the port number, user name, and configuration file directory in [DEFAULT]:

[DEFAULT]
...
Bind_port = 8080
user = Swift
swift_dir =/etc/swift

In [Pipeline:main], enable the appropriate modules:

[Pipeline:main]
Pipeline = Authtoken Cache Healthcheck Keystoneauth proxy-logging proxy-server

In [App:proxy-server], enable the user management feature:

[App:proxy-server]
...
Allow_account_management = True
Account_autocreate = True

Configure the appropriate action role in [Filter:keystoneauth];

[Filter:keystoneauth]
Use = Egg:swift#keystoneauth ...
Operator_roles = Admin,_member_

Configure information about the authentication service in [Filter:authtoken]:

[Filter:authtoken]
Paste.filter_factory = Keystonemiddleware.auth_token:filter_factory
...
Auth_uri = http://localhost:5000/v2.0
Identity_uri = http://localhost:35357
admin_tenant_name = Service
admin_user = Swift
Admin_password = Swift_pass #指定为使用keystone创建swift用户时设置的密码, such as 123456
delay_auth_ Decision = True

In [Filter:cache], configure the location of the memcached:

[Filter:cache]
...
Memcache_servers = 127.0.0.1:11211

This completes the installation and deployment of Proxy-server and can be started with Systemctl, but the service is not started until the Configuration Storage service is deployed. Before installing the storage service, specify the storage directory for the storage service, which requires the disk partition to be mounted to the storage directory. According to the official installation manual, the mounted disk must have a partitioned table, that is, the disk has been partitioned. After testing, the disk has several partitions that are not important, but you must perform partitions and you can use the FDISK command for disk partitioning. Although Swift supports a variety of file systems, but according to the test XFS file system has the best performance and stability, so after partitioning the disk, such as/DEV/SDB1, you need to use the command MKFS.XFS to format the/DEV/SDB1: MKFS.XFS/DEV/SDB1. When the format is complete, create the Mount directory: Mkdir-p/srv/node/, and then edit/etc/fstab to add the following statement:

/DEV/SDB1/SRV/NODE/XFS noatime,nodiratime,nobarrier,logbufs=8 0 2

Finally mount the storage directory for the device: Mount/srv/node and modify the owner of the directory for users who are running Swift: Chown-r swift:swift/srv/. The Mount directory is a potentially problematic place for swift, possibly a permission issue, and may be related to the configuration file described later, followed by a detailed description of the specific issues. After you mount the device, you will also need to modify the/etc/rsyncd.conf file as follows:

UID = Swift
gid = Swift
log file =/var/log/rsyncd.log
pid file =/var/run/rsyncd.pid Address
= MANAGEMENT _interface_ip_address
[Account]
max connections = 2
path =/srv/
Read Only = False
lock file =/var/l Ock/account.lock
[container]
max connections = 2
path =/srv/
Read Only = False
lock file =/var/ Lock/container.lock
[Object]
max connections = 2
path =/srv/
Read Only = False
lock file =/var /lock/object.lock

After you have completed your preparations, perform the following command to install the storage service, including Account-server, Container-server, and Object-server:yum install Openstack-swift-account Openstack-swift-container Openstack-swift-object. After the installation is complete, perform the following command to download the account-server.conf, container-server.conf, and object-server.conf files:

Curl-o/etc/swift/account-server.conf https://raw.githubusercontent.com/openstack/swift/stable/juno/etc/ Account-server.conf-sample

Curl-o/etc/swift/container-server.conf https://raw.githubusercontent.com/ Openstack/swift/stable/juno/etc/container-server.conf-sample

Curl-o/etc/swift/object-server.conf https:// Raw.githubusercontent.com/openstack/swift/stable/juno/etc/object-server.conf-sample

Three profiles are similar in content to be modified so that only the account-server.conf is described, and the other two files will be flagged in different places.
In [DEFAULT], configure IP address, port number, user, profile directory, and Mount directory, where you need to take note is the Mount directory, which is the parent directory of the mount point, such as/DEV/SDB1 mount to the directory/srv/node directory, in which the Mount directory should be /srv, not/srv/node.

[DEFAULT]
...
BIND_IP = 127.0.0.1
bind_port = 6002 #不同的服务使用不同的端口
user = Swift
swift_dir =/etc/swift devices
=/srv/#设备 The parent directory of the Mount directory

In [Pipeline:main], set the appropriate module:

[Pipeline:main]
Pipeline = Healthcheck Recon Account-server#account-server should be changed to Container-server, object-server in other configuration files

In [Filter:recon], configure the recon cache directory:

[Filter:recon]
...
Recon_cache_path =/var/cache/swift

Container-server.conf and object-server.conf only need to revise the notes above, and the rest of the place is exactly the same. After modifying all the configuration files, change the owner of the/var/cache/swift to run Swift's users, such as Swift users: Chown-r swift:swift/var/cache/swift. After performing all of the above steps, the next step is to generate the ring file, the exact meaning of the command will not be explained in depth, you can enter Swift-ring-builder in the command directly to view the detailed instructions. First go to the/etc/swift directory, which is set in several of these configuration files, and then generate the ring file for account, container, and object, respectively, because all storage services are deployed on a single node, so the number of replicas is set to 1, with the specific command:

Swift-ring-builder Account.builder Create 8 1 1
swift-ring-builder container.builder Create 8 1 1
Swift-ring-builder Object.builder Create 8 1 1

The first parameter specifies the number of partition to generate, such as 2^8=256, the second parameter executes the number of replicas, here is 1, and the third parameter means the number of hours at which the partition is moved at least one interval at a time. Once you have created the ring file, you need to add a storage node or directory to the ring:

Swift-ring-builder account.builder Add R1z1-127.0.0.1:6002/node
swift-ring-builder container.builder Add R1z1-127.0.0.1:6001/node
swift-ring-builder object.builder add r1z1-127.0.0.1:6000/node 100

The port number must match the port number set in the corresponding configuration file. The slash/rear content is matched to the last level of the mount point, such as/DEV/SDB1 mount to/srv/node, then/node, and the devices value in the configuration file is/srv/ , if you set a mismatch or do not match the mounted directory, the following error occurs:

Object-replicator:node is not mounted
proxy-server:error insufficient Storage 127.0.0.1:6002/node

You can also enter the following statement under the Python command line to verify that the settings are mounted correctly, that the configuration is correct, and that if everything is correct, return TRUE or false:

From swift.common.constraints import check_mount
check_mount ('/srv ', ' node ') #第一个参数为配置文件中devices的值, The second parameter is to add the device to the ring/back value

Then run the following command to rebalance the ring:

Swift-ring-builder account.builder rebalance
swift-ring-builder container.builder
Rebalance Swift-ring-builder Object.builder Rebalance

Note that the above generation ring file, adding storage nodes to the ring steps are implemented in the control Section shop. Download and modify the swift.conf file:

Curl-o/etc/swift/swift.conf Https://raw.githubusercontent.com/openstack/swift/stable/juno/etc/swift.conf-sample

Configure the prefix and suffix of the hash path in [Swift-hash]:

[Swift-hash]
...
Swift_hash_path_suffix = hash_path_prefix
Swift_hash_path_prefix = Hash_path_suffix

To configure the default storage policy in [storage-policy:0]:

[storage-policy:0]
...
Name = Policy-0
default = yes

If you are a multi-node deployment of Swift, you will also need to copy the ring files, swift.conf files generated by the above steps to all nodes, and modify the/etc/swift owner as Swift User: Chown-r swift:swift/etc/swift. Once the deployment configuration is complete, all services need to be started. In addition to Proxy-server, Account-server, Container-server and Object-server, Swift includes many other cyclical processes that, if each time you start, stop, and restart these services, is going to be a tedious and boring process, so it is recommended that all startup, stop, or restart commands be scripted so that you can just execute the script, such as:

[Openstack@localhost ~]$ cat swift-stop.sh 
#!/bin/bash systemctl
Stop Openstack-swift-account.service Openstack-swift-account-auditor.service Openstack-swift-account-reaper.service Openstack-swift-account-replicator.service
systemctl Stop Openstack-swift-container.service Openstack-swift-container-auditor.service Openstack-swift-container-replicator.service Openstack-swift-container-updater.service
systemctl Stop Openstack-swift-object.service Openstack-swift-object-auditor.service Openstack-swift-object-replicator.service Openstack-swift-object-updater.service

Once all the services have been started, you can check the ability to upload the download files to Swift:

[Openstack@localhost ~]$ source demo-openrc.sh 
[openstack@localhost ~]$ Swift stat
        account:auth_ 1928446a6c364ace8a40043b5318bd9f
     containers:0
        objects:0
          bytes:0
x-put-timestamp: 1434681204.28622
     connection:keep-alive
    x-timestamp:1434681204.28622
     X-trans-id: Tx60e7648bf53f4365a2c84-0055837f72
   Content-type:text/plain; charset=utf-8

[Openstack@localhost ~]$ Swift upload demo swift-stop.sh--object-name stop
stop
[Openstack@localhost ~]$ Swift List
demo
[openstack@localhost ~]$ Swift list demo
stop

This completes the one-node deployment of Swift, and from the test results, everything is working. A successful deployment of Swift does not mean that all of Swift's functions and processes are familiar, but there is much to learn, such as the detailed use of the SWIFT Client command, the specific process for uploading the download file, the specific meaning of the ring file, how to adjust the number of partition, etc. Further study is needed.