openstack-manuals/doc/install-guide/section_colocating-services.xml
Diane Fleming 64b6c9261e Folder rename, file rename, flattening of directories
Current folder name	New folder name	        Book title
----------------------------------------------------------
basic-install 	        DELETE
cli-guide	        DELETE
common	                common
NEW	                admin-guide-cloud	Cloud Administrators Guide
docbkx-example	        DELETE
openstack-block-storage-admin 	DELETE
openstack-compute-admin 	DELETE
openstack-config 	config-reference	OpenStack Configuration Reference
openstack-ha 	        high-availability-guide	OpenStack High Availabilty Guide
openstack-image	        image-guide	OpenStack Virtual Machine Image Guide
openstack-install 	install-guide	OpenStack Installation Guide
openstack-network-connectivity-admin 	admin-guide-network 	OpenStack Networking Administration Guide
openstack-object-storage-admin 	DELETE
openstack-security 	security-guide	OpenStack Security Guide
openstack-training 	training-guide	OpenStack Training Guide
openstack-user 	        user-guide	OpenStack End User Guide
openstack-user-admin 	user-guide-admin	OpenStack Admin User Guide
glossary	        NEW        	OpenStack Glossary

bug: #1220407

Change-Id: Id5ffc774b966ba7b9a591743a877aa10ab3094c7
author: diane fleming
2013-09-08 15:15:50 -07:00

34 lines
2.0 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="best-practices-co-locating-services">
<?dbhtml stop-chunking?>
<title>Co-locating services</title>
<para>While for performance reasons you may want OpenStack project's services to live on
different machines, this is not always practical. For example, in small deployments there might be
too few machines available, or a limited number of public IP addresses. Components from different
OpenStack projects are not necessarily engineered to be able to be co-located, although many users
report success with a variety of deployment scenarios.</para>
<para>
The following is a series of pointers to be used when co-location
of services from different OpenStack projects on the same machine
is a must:
<itemizedlist>
<listitem><para>Ensure dependencies aren't in conflict. The OpenStack
Continuous Integration team does attempt to ensure there is no
conflict, so if you see issues during package installation,
consider filing a bug.</para></listitem>
<listitem><para>Monitor your systems and ensure they are not overloaded. Some parts of OpenStack use a lot of
CPU time (such as Object Storage Proxy Servers), while others are I/O focused (such as Object
Storage Object Servers). Try to balance these so they complement each other.</para></listitem>
<listitem><para>Beware of security. Different parts of OpenStack assume different security models. For
example, OpenStack Object Storage (Swift) assumes the storage nodes will be on a private
network and does not provide additional security between nodes in the cluster.</para></listitem>
<listitem><para>Ensure the ports you are running the services on don't
conflict. Most ports used by OpenStack are configurable.</para></listitem>
</itemizedlist>
</para>
</section>