openstack/swift
Code Issues Proposed changes

Moved proxy server section to top, and encompassed suggested changes from cthier

Browse Source
This commit is contained in:
Brian K. Jones 2010-07-23 10:51:24 -04:00
parent e0c666df62
commit 164914dc1b
1 changed files with 35 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
doc/source/overview_architecture.rst
View File

@ -2,23 +2,40 @@
Swift Architectural Overview Swift Architectural Overview
============================ ============================
------------
Proxy Server
------------
The Proxy Server is responsible for tying together the rest of the Swift
architecture. For each request, it will look up the location of the account,
container, or object in the ring (see below) and route the request accordingly.
The public API is also exposed through the Proxy Server.
A large number of failures are also handled in the Proxy Server. For
example, if a server is unavailable for an object PUT, it will ask the
ring for a handoff server, and route there instead.
When objects are streamed to or from an object server, they are streamed
directly through the proxy server to of from the user -- the proxy server
does not spool them.
For more detailed information about the proxy server, see :doc:`proxy`
-------- --------
The Ring The Ring
-------- --------
The available storage in a Swift deployment is organized into separate rings A ring represents a mapping between the names of entities stored on disk, and
for accounts, containers, and objects. When other components need to handle their physical location. There are separate rings for accounts, containers, and
requests to find, create, destroy, or perform any operation on any object, objects. When other components need to perform any operation on an object,
container, or account, they interact with the appropriate ring to accomplish container, or account, they need to interact with the appropriate ring to
that. determine its location in the cluster.
The Ring manages the available storage using zones, devices, partitions, and
replicas.
The Ring maintains this mapping using zones, devices, partitions, and replicas.
Each partition in the ring is replicated, by default, 3 times accross the Each partition in the ring is replicated, by default, 3 times accross the
cluster, and the locations for a partition are stored in the mapping cluster, and the locations for a partition are stored in the mapping maintained
maintained by the ring. The ring is also responsible for determining which by the ring. The ring is also responsible for determining which devices are
devices are used for handoff in failure scenarios. used for handoff in failure scenarios.
Data can be isolated with the concept of zones in the ring. Each replica Data can be isolated with the concept of zones in the ring. Each replica
of a partition is guaranteed to reside in a different zone. A zone could of a partition is guaranteed to reside in a different zone. A zone could
@ -57,6 +74,8 @@ version of the file (a 0 byte file ending with ".ts", which stands for
tombstone). This ensures that deleted files are replicated correctly and tombstone). This ensures that deleted files are replicated correctly and
older versions don't magically reappear due to failure scenarios. older versions don't magically reappear due to failure scenarios.
For more detailed information about the object server, see :doc:`object`
---------------- ----------------
Container Server Container Server
---------------- ----------------
@ -68,6 +87,8 @@ across the cluster similar to how objects are. Statistics are also tracked
that include the total number of objects, and total storage usage for that that include the total number of objects, and total storage usage for that
container. container.
For more detailed information about the container server, see :doc:`container`
-------------- --------------
Account Server Account Server
-------------- --------------
@ -75,22 +96,7 @@ Account Server
The Account Server is very similar to the Container Server, excepting that The Account Server is very similar to the Container Server, excepting that
it is responsible for listings of containers rather than objects. it is responsible for listings of containers rather than objects.
------------ For more detailed information about the account server see :doc:`account`
Proxy Server
------------
The Proxy Server is responsible for tying the above servers together. For
each request, it will look up the location of the account, container, or
object in the ring and route the request accordingly. The public API is
also exposed through the Proxy Server.
A large number of failures are also handled in the Proxy Server. For
example, if a server is unavailable for an object PUT, it will ask the
ring for a handoff server, and route there instead.
When objects are streamed to or from an object server, they are streamed
directly through the proxy server to of from the user -- the proxy server
does not spool them.
----------- -----------
Replication Replication