SMP: Solving The Lock Problem Part 4

SMP: Solving The Lock Problem Part 4

My last three blog posts have presented the SMP (Symmetric Multi Processor scaling problem, Performance Solution as presented by Pyramid Technology, and the user space SMP problem. Now, I’d like to delve into the locks themselves.  What actually is a lock?

There are essentually two types of SMP locks: mutexes and semaphores.

SMP Mutex Lock

A mutex (short for mutual exclusion), is a lock that waits for a field to be released before proceeding.  In its simplist incantation, a mutex constantly checks the field in question.  This type of lock thus uses the following alorithm:

SMP: Symmetric Multi-Processor User Processes (Part 3)

SMP: Symmetric Multi-Processor User Processes (Part 3)

Continuing on the information presented in Part 1:  The Symmetric Multi Processor (SMP) scaling problem and Part 2: The Performance Solution as presented by Pyramid Technology, my comments were addressed at the kernel.  But what about user processes?  Do they also need to use locking?

The answer is yes, if multiple processes share the same physical memory.  This can occur with Shared Memory. User space proccesses use Shared Memory so that proccesses can easily and quickly share data.  Shared Memory is the fastest Inter Process Communication(IPC) mechanism that can be employed.  But it does have a cost (alas nothing is free): lack of synchronization.

SMP: Solving The Performance Problem (Part 2)

SMP: Solving The Performance Problem (Part 2)

In my last blog post, I described the SMP problem.  How adding cpus to an SMP system does not necessarily reliably increase performance.

Pyramid Technology solved this problem by decreasing the granularity of the lock.  This means that the amount of real estate that was controlled by the lock, was decreased.  Thus instead of a single lock for the entire kernel, multiple locks were added for the kernel.  That is, locks were added for each major data structure: Process Table, Schedular, File Systems, etc.

SMP: Symmetric Multi-Processor Explained (Part 1)

SMP: Symmetric Multi-Processor Explained (Part 1)

As a software engineer at Pyramid Technology, Symmetric Multi-Processors (SMPs) served as a technology backbone. An SMP system essentually consists of multiple cpus that all use the same physical memory.

Each cpu ran some flavor of the Unix operating system.  In Unix, user spaces processes have seperate physical address spaces, so user processes are not a problem in SMP.  But the kernel maps to hard-wired physical addresses; thus multiple cpus, running the same kernel in SMP, is a problem.

Openstack Swift TempAuth Module

Openstack Swift TempAuth Module

Last time I presented a Swift REST API example. Now I’ll explain the Openstack Swift Test Authentication and Authorization System (tempauth). This is an excellent authentication module for Swift All In One (SAIO) and for development work.

Add Tempauth to Openstack Swift Proxy Server

The first thing that you will need to do is to add tempauth to the Proxy Server configuration. So make sure that the following is in proxy-server.conf:

Swift REST API Example

Swift REST API Example

Last post I explained REST interfaces, and promised to use a Swift REST API as an example.   This application programming interface (API) supports the following operations.

1)  Swift REST API Authorization

GET AUTHORIZATION

This operation is used to obtain an authorization token and URL for agiven user login and password.   This token and URL are then used in any subsequent operations.

  • URL Data: None.
  • Required Request Headers:
    • X-Auth-User = user login.
    • X-Auth-Key = user password.
  • Optional Request Headers: None.
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Date = current date.
    • X-Auth-Token = authorization token, input for subsequent operations.
    • X-Storage-Token = storage token, input for subsequent operations.
    • X-Storage-Url = storage URL, input for subsequent operations.
  • HTTP Data: None.

2) Swift REST API Account

DELETE ACCOUNT

Mark an account as deleted.   Swift REST API will clean up the account as time permits.

  • URL Data: None.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers: None.
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
  • HTTP Data: None.

GET ACCOUNT

Get the list of containers in an account.

  • URL Data: None.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers: None.
  • Parameters:
    • format=type : return http data in “json” or “xml” format.
    • limit=number : limit the number of returned containers.
    • marker=filter : provide a filter. The returned list of containers will start after “filter”.
  • Response Headers:
    • Accept-Ranges = always “bytes”. This header will eventually comply with the http “range” header.
    • Content-Length = the number of bytes in http data.
    • Content-Type = http data content type.
    • Date = current date.
    • X-Account-Bytes-Used = the number of bytes used in the account. Keep in mind that this field is updated in a lazy fashion.
    • X-Account-Container-Count = the number of containers in the account.
    • X-Account-Object-Count = the number of objects in the account. Keep in mind that this field is updated in a lazy fashion.
  • HTTP Data: The list of containers for the account.

HEAD ACCOUNT

Get account statistics.

  • URL Data: None.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers: None.
  • Parameters: None.
  • Response Headers:
    • Accept-Ranges = always “bytes”. This header will eventually comply with the http “range” header.
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
    • X-Account-Bytes-Used = the number of bytes used in the account. Keep in mind that this field is updated in a lazy fashion.
    • X-Account-Container-Count = the number of containers in the account.
    • X-Account-Object-Count = the number of objects in the account. Keep in mind that this field is updated in a lazy fashion.
  • HTTP Data: None.

POST ACCOUNT

  • Post meta-data to an account.
  • URL Data: None.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers:
    • X-Account-Meta-* = the user can create a account meta-data header. Such headers are of the form: “key value”.   The resulting account header will be: “X-Account-Meta-key: value”
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
  • HTTP Data: None.

PUT ACCOUNT

Create an account.

  • URL Data: None.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers:
    • X-Account-Meta-* = the user can create a account meta-data header. Such headers are of the form: “key value”.   The resulting account header will be: “X-Account-Meta-key: value”
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
  • HTTP Data: None.

3) Swift REST API Container

DELETE CONTAINER

Mark a container as deleted. Swift will clean up the container as time permits.

  • URL Data: Container name.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers: None.
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
  • HTTP Data: None.

GET CONTAINER

Get the list of objects in a container.

  • URL Data: Container name.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers: None.
  • Parameters:
    • delimiter=char: apply a character as a “delimiter” to the list of objects.
    • format=type : return http data in “json” or “xml” format.
    • limit=number : limit the number of returned objects.
    • marker=filter : provide a filter. The returned list of objects will start after “filter”.
    • path=string : for object names with embedded slashes (/).
    • prefix=string : The returned list of objects will start with “string”.
  • Response Headers:
    • Accept-Ranges = always “bytes”. This header will eventually comply with the http “range” eader.
    • Content-Length = the number of bytes in http data.
    • Content-Type = http data content type.
    • Date = current date.
    • X-Container-Bytes-Used = the number of bytes used in the container.
    • X-Container-Object-Count = the number of objects in the container.
  • HTTP Data: The list of objects for the container.

HEAD CONTAINER

Get container statistics.

  • URL Data: Container name.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers: None.
  • Parameters: None.
  • Response Headers:
    • Accept-Ranges = always “bytes”. This header will eventually comply with the http “range” header.
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
    • X-Container-Bytes-Used = the number of bytes used in the container.
    • X-Container-Object-Count = the number of objects in the container.
  • HTTP Data: None.

POST CONTAINER

  • Post meta-data to a container.
  • URL Data: Container name.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers:
    • X-Container-Meta-* = the user can create a container meta-data header. Such headers are of the form: “key value”. The resulting container header will be: “X-Container-Meta-key: value”
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
  • HTTP Data: None.

PUT CONTAINER

Create a container.

  • URL Data: Container name.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers:
    • X-Account-Meta-* = the user can create a account meta-data header. Such headers are of the form: “key value”.   The resulting account header will be: “X-Account-Meta-key: value”
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
  • HTTP Data: None.

4) Swift REST API Object

COPY OBJECT

Copy an object from one container to another.

  • URL Data: src_container/src_object.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
    • Destination = /<dest_container>/<dest_object>
  • Optional Request Headers: None.
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
    • Etag = checksum of new object data.
    • Last-Modified = the data that the source object was last changed.
    • X-Copied-From = source container and object.
    • X-Object-Meta-* = user defined meta data.
  • HTTP Data: None.

DELETE OBJECT

Delete an object from a container.

  • URL Data: container/object.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers: None.
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
  • HTTP Data: None.

GET OBJECT

Get an object from a container.

  • URL Data: container/object.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers:
    • If-Match: etag = return the object data if there is an etag match.
    • If-Modified-Since: date = return the object data if it was modified since “data”.
    • If-None-Match: etag = return the object data if there is no etag match.
    • If-Unmodified-Since: date = return the object data if it was unmodified since “data”.
    • Range: bytes = return the specified object byte range.
  • Parameters: None.
  • Response Headers:
    • Content-Length = number of bytes in http data.
    • Content-Type = http data content type.
    • Date = current date.
    • Etag = checksum of object data.
    • Last-Modified = the data that the object was last changed.
    • X-Object-Meta-* = user defined meta data.
  • HTTP Data: Object data.

POST OBJECT

Post meta-data to an object.

  • URL Data: container/object.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers:
    • X-Object-Meta-* = the user can create an object meta-data header. Such headers are of the form: “key value”.   The resulting object header will be: “X-Object-Meta-key: value”
    • X-Delete-After: seconds = delete the object after “seconds”.
    • X-Delete-At: seconds = delete the object after current time + “seconds”.
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
  • HTTP Data: None.

PUT OBJECT

Create an object in a container.

  • URL Data: container/object.
  • Required Request Headers:
    • X-Auth-Token = authorization token.
  • Optional Request Headers:
    • X-Object-Manifest = indicates that this object is a manifest, that is, contains an ordered list of data objects.   This header is used to support objects larger than4GB.
    • X-Object-Meta-* = the user can create an object meta-data header. Such headers are of the form: “key value”.   The resulting object header will be: “X-Object-Meta-key: value”
    • Transfer-Encoding = use transfer encoding.
  • Parameters: None.
  • Response Headers:
    • Content-Length = always zero.
    • Content-Type = http data content type.
    • Date = current date.
    • Etag = checksum of object data.
    • Last-Modified = the data that the object was last changed.
    • X-Object-Meta-* = user defined meta data.
  • HTTP Data: None.

What would you add to this Swift REST API example?

Swift Storage Devices

Swift Storage Devices

In a previous blog, I presented the topology of Openstack Swift Object Storage.   That is, how Swift uses XFS  to store Accounts, Containers, and Objects.

A separate Account Database is created for each Account and an Account Database is a SQLite  instantiation in the file system. An Account Database consists of a Account Stat Table and a Container Table. The Account Stat Table contains meta-data for that specific account.   The Container Table contains an entry for each container in that account.

Database Performance with Openstack Swift Improvements – Part 3

Database Performance with Openstack Swift Improvements – Part 3

In Part 2 of this blog post series, I proposed replacing SQLite with MySQL as a database engine and changing the database schema to use chunking. These changes ensure that database performance is consistent for Account and Container Databases.  But what about Objects? As previously stated, Object data is stored in files. Are there problems with this?

Yes. Storing Object data in files is nice in that it is simple and Object data is easy to find – just look in the file system. But what about performance?

Openstack Swift Database Performance Improvements Part 2

Openstack Swift Database Performance Improvements Part 2

In my previous Openstack post I established the groundwork for my proposed solution to improve the performance of Openstack Swift Database that consists of two parts: MySQL and Database Chunking.

Database Performance with Openstack Improvement: MySQL

For the first part of the solution, I propose replacing SQLite with MySQL as a database engine. As the name implies, SQLite is fine for small databases, but has performance problems with larger Openstack databases. MySQL is perfect for this problem, since a database is represented as a file system directory, and database tables are represented as files.

Openstack Swift Database Performance Part 1

Openstack Swift Database Performance Part 1

In my last two posts (Python’s Strengths & Weaknesses) I have been describing the operation of Openstack Swift Storage. Swift storage basically consists of four components: Ring, Database, Zones, and File system. I’m proposing some performance improvements to this design. But first we need to understand the Swift database schema. An Openstack Account Database consists of two tables: Account Stat and Container. And a Container Database consists of two tables: Container Stat and Object.

Python: It’s Programming Weaknesses

Python: It’s Programming Weaknesses

In my last post, I presented Python and it’s strengths. To be fair, I’d like to continue and share my thoughts about some its weaknesses.

Python’s Weaknesses

1. DOCUMENTATION REVISITED

Python programs are poorly documented. On of the goals of Python is that the code should be self-documenting; programs are thus written in such a way that you don’t need comments.  This is a wonderful little theory that doesn’t work so well in the  real world. For anyone who has had to scroll through code, good luck trying to understand it. A little judicious documentation goes a long way in explaining algorithms and finding bugs.

Python: It’s Programming Strengths

Python: It’s Programming Strengths

Python is a relatively new programming language. It can be thought of an extension of Perl. Essentially Python is an interpreter. In my current position as a Cloud Architect at Internap, I have been exclusively using it on the OpenStack project.

Though I am not an expert in Python (been using it for less than a year), I am an accomplished programmer in other languages like C. With this experience I bring a different viewpoint to the Python discussion. As a Python newbie, I understand that it has a different perspective than C. I am not opposed to change. I am not stuck in the past. I embrace the rapid progress in the computer engineering community.