From c3f3c6c8e72edfb84d8d9e09a81d73a366502f87 Mon Sep 17 00:00:00 2001 From: Shilla Saebi Date: Fri, 14 Mar 2014 01:58:42 -0400 Subject: [PATCH] edit to architecture.xml Cinder to Block Storage changed to be ran on to run sql to SQL api to API http to HTTP Change-Id: I1768cf6ac79c77c40641edba1e0c785df7d6754e --- sources/cinder/architecture.xml | 44 ++++++++++++++++++++++----------- 1 file changed, 29 insertions(+), 15 deletions(-) diff --git a/sources/cinder/architecture.xml b/sources/cinder/architecture.xml index 6da7d44e..8368e6c9 100644 --- a/sources/cinder/architecture.xml +++ b/sources/cinder/architecture.xml @@ -8,7 +8,6 @@
Header -.. Copyright 2010-2011 United States Government as represented by the Administrator of the National Aeronautics and Space Administration. All Rights Reserved. @@ -24,19 +23,16 @@
-Cinder-System-Architecture +Block Storage System Architecture -========================== -The Cinder Block Storage Service is intended to be ran on one or more nodes. -Cinder uses a sql-based central database that is shared by all Cinder services in the system. The amount and depth of the data fits into a sql database quite well. For small deployments this seems like an optimal solution. For larger deployments, and especially if security is a concern, cinder will be moving towards multiple data stores with some kind of aggregation system. +The OpenStack Block Storage Service is intended to run on one or more nodes. +Block Storage uses a SQL-based central database that is shared by all Block Storage services in the system. The amount and depth of the data fits into a SQL database quite well. For small deployments this seems like an optimal solution. For larger deployments, and especially if security is a concern, Block Storage will be moving towards multiple data stores with some kind of aggregation system.
Components ----------- Below you will a brief explanation of the different components. -:: /- ( LDAP ) [ Auth Manager ] --- | \- ( DB ) @@ -44,7 +40,7 @@ Below you will a brief explanation of the different components. | cinderclient | / \ | - [ Web Dashboard ]- -[ api ] -- [ AMQP ] -- [ scheduler ] -- [ volume ] -- ( iSCSI ) + [ Web Dashboard ]- -[ API ] -- [ AMQP ] -- [ scheduler ] -- [ volume ] -- ( iSCSI ) \ / | novaclient | | @@ -52,13 +48,31 @@ Below you will a brief explanation of the different components. | [ REST ] -DB: sql database for data storage. Used by all components (LINKS NOT SHOWN) -Web Dashboard: potential external component that talks to the api -api: component that receives http requests, converts commands and communicates with other components via the queue or http -Auth Manager: component responsible for users/projects/and roles. Can backend to DB or LDAP. This is not a separate binary, but rather a python class that is used by most components in the system. -scheduler: decides which host gets each volume -volume: manages dynamically attachable block devices. + + DB: SQL database for data storage. Used by all + components (LINKS NOT SHOWN) + + + Web Dashboard: potential external component that talks to the + API + + + API: component that receives HTTP requests, converts commands + and communicates with other components via the queue or HTTP + + + Auth Manager: component responsible for users/projects/and + roles. Can use as back-end a database or LDAP. This is not a + separate binary, but rather a python class that is used by most + components in the system. + + + scheduler: decides which host gets each volume + + + volume: manages dynamically attachable block devices. +
- \ No newline at end of file +