diff --git a/doc/source/install/cinder-storage-install-obs.rst b/doc/source/install/cinder-storage-install-obs.rst index 8a61de3fe44..9d99c61c2fd 100644 --- a/doc/source/install/cinder-storage-install-obs.rst +++ b/doc/source/install/cinder-storage-install-obs.rst @@ -192,7 +192,7 @@ Install and configure components Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address of the management network interface on your storage node, typically 10.0.0.41 for the first node in the - :ref:`example architecture `. + `example architecture `_. * In the ``[lvm]`` section, configure the LVM back end with the LVM driver, ``cinder-volumes`` volume group, iSCSI protocol, diff --git a/doc/source/install/cinder-storage-install-rdo.rst b/doc/source/install/cinder-storage-install-rdo.rst index 148a3b77b1e..65b5ee92763 100644 --- a/doc/source/install/cinder-storage-install-rdo.rst +++ b/doc/source/install/cinder-storage-install-rdo.rst @@ -201,7 +201,7 @@ Install and configure components Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address of the management network interface on your storage node, typically 10.0.0.41 for the first node in the - :ref:`example architecture `. + `example architecture `_. * In the ``[lvm]`` section, configure the LVM back end with the LVM driver, ``cinder-volumes`` volume group, iSCSI protocol, diff --git a/doc/source/install/cinder-storage-install-ubuntu.rst b/doc/source/install/cinder-storage-install-ubuntu.rst index 8bca3ef22ec..e0997784203 100644 --- a/doc/source/install/cinder-storage-install-ubuntu.rst +++ b/doc/source/install/cinder-storage-install-ubuntu.rst @@ -190,7 +190,7 @@ Install and configure components Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address of the management network interface on your storage node, typically 10.0.0.41 for the first node in the - :ref:`example architecture `. + `example architecture `_. * In the ``[lvm]`` section, configure the LVM back end with the diff --git a/doc/source/install/index.rst b/doc/source/install/index.rst index 2ae54e06d04..83dd13d89ad 100644 --- a/doc/source/install/index.rst +++ b/doc/source/install/index.rst @@ -17,9 +17,25 @@ on controller nodes, compute nodes, or standalone storage nodes. For more information, see the `Configuration Reference `_. + +Prerequisites +~~~~~~~~~~~~~ + +This documentation specifically covers the installation of the Cinder Block Storage service. Before following this +guide you will need to prepare your OpenStack environment using the instructions in the +`OpenStack Installation Tutorial `_. + +Once able to 'Launch an instance' in your OpenStack environment follow the instructions below to add +Cinder to the base environment. + + +Adding Cinder to your OpenStack Environment +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following links describe how to install the Cinder Block Storage Service: + .. toctree:: - overview get-started-block-storage index-obs index-rdo diff --git a/doc/source/install/overview.rst b/doc/source/install/overview.rst deleted file mode 100644 index 8b064dce779..00000000000 --- a/doc/source/install/overview.rst +++ /dev/null @@ -1,182 +0,0 @@ -======== -Overview -======== - -The OpenStack project is an open source cloud computing platform that -supports all types of cloud environments. The project aims for simple -implementation, massive scalability, and a rich set of features. Cloud -computing experts from around the world contribute to the project. - -OpenStack provides an Infrastructure-as-a-Service (IaaS) solution -through a variety of complementary services. Each service offers an -Application Programming Interface (API) that facilitates this -integration. - -This guide covers step-by-step deployment of the major OpenStack -services using a functional example architecture suitable for -new users of OpenStack with sufficient Linux experience. This guide is not -intended to be used for production system installations, but to create a -minimum proof-of-concept for the purpose of learning about OpenStack. - -After becoming familiar with basic installation, configuration, operation, -and troubleshooting of these OpenStack services, you should consider the -following steps toward deployment using a production architecture: - -* Determine and implement the necessary core and optional services to - meet performance and redundancy requirements. - -* Increase security using methods such as firewalls, encryption, and - service policies. - -* Implement a deployment tool such as Ansible, Chef, Puppet, or Salt - to automate deployment and management of the production environment. - -.. _overview-example-architectures: - -Example architecture -~~~~~~~~~~~~~~~~~~~~ - -The example architecture requires at least two nodes (hosts) to launch a basic -virtual machine or instance. Optional -services such as Block Storage and Object Storage require additional nodes. - -.. important:: - - The example architecture used in this guide is a minimum configuration, - and is not intended for production system installations. It is designed to - provide a minimum proof-of-concept for the purpose of learning about - OpenStack. For information on creating architectures for specific - use cases, or how to determine which architecture is required, see the - `Architecture Design Guide `_. - -This example architecture differs from a minimal production architecture as -follows: - -* Networking agents reside on the controller node instead of one or more - dedicated network nodes. - -* Overlay (tunnel) traffic for self-service networks traverses the management - network instead of a dedicated network. - -For more information on production architectures, see the -`Architecture Design Guide `_, -`OpenStack Operations Guide `_, and -`OpenStack Networking Guide `_. - -.. _figure-hwreqs: - -.. figure:: figures/hwreqs.png - :alt: Hardware requirements - - **Hardware requirements** - -Controller ----------- - -The controller node runs the Identity service, Image service, management -portions of Compute, management portion of Networking, various Networking -agents, and the Dashboard. It also includes supporting services such as -an SQL database, message queue, and NTP . - -Optionally, the controller node runs portions of the Block Storage, Object -Storage, Orchestration, and Telemetry services. - -The controller node requires a minimum of two network interfaces. - -Compute -------- - -The compute node runs the hypervisor portion of Compute that -operates instances. By default, Compute uses the -KVM hypervisor. The compute node also -runs a Networking service agent that connects instances to virtual networks -and provides firewalling services to instances via -security groups . - -You can deploy more than one compute node. Each node requires a minimum -of two network interfaces. - -Block Storage -------------- - -The optional Block Storage node contains the disks that the Block -Storage and Shared File System services provision for instances. - -For simplicity, service traffic between compute nodes and this node -uses the management network. Production environments should implement -a separate storage network to increase performance and security. - -You can deploy more than one block storage node. Each node requires a -minimum of one network interface. - -Object Storage --------------- - -The optional Object Storage node contain the disks that the -Object Storage service uses for storing accounts, containers, and -objects. - -For simplicity, service traffic between compute nodes and this node -uses the management network. Production environments should implement -a separate storage network to increase performance and security. - -This service requires two nodes. Each node requires a minimum of one -network interface. You can deploy more than two object storage nodes. - -Networking -~~~~~~~~~~ - -Choose one of the following virtual networking options. - -.. _network1: - -Networking Option 1: Provider networks --------------------------------------- - -The provider networks option deploys the OpenStack Networking service -in the simplest way possible with primarily layer-2 (bridging/switching) -services and VLAN segmentation of networks. Essentially, it bridges virtual -networks to physical networks and relies on physical network infrastructure -for layer-3 (routing) services. Additionally, a DHCP service provides IP address information to -instances. - -The OpenStack user requires more information about the underlying network -infrastructure to create a virtual network to exactly match the -infrastructure. - -.. warning:: - - This option lacks support for self-service (private) networks, layer-3 - (routing) services, and advanced services such as - LBaaS and - FWaaS. - Consider the self-service networks option below if you desire these features. - -.. _figure-network1-services: - -.. figure:: figures/network1-services.png - :alt: Networking Option 1: Provider networks - Service layout - -.. _network2: - -Networking Option 2: Self-service networks ------------------------------------------- - -The self-service networks option augments the provider networks option -with layer-3 (routing) services that enable -self-service networks using overlay segmentation methods such -as VXLAN . Essentially, it routes -virtual networks to physical networks using NAT. Additionally, this option provides the foundation for -advanced services such as LBaaS and FWaaS. - -The OpenStack user can create virtual networks without the knowledge -of underlying infrastructure on the data network. This can also include -VLAN networks if the layer-2 plug-in is configured accordingly. - -.. _figure-network2-services: - -.. figure:: figures/network2-services.png - :alt: Networking Option 2: Self-service networks - Service layout