OpenStack is designed to be massively horizontally scalable, which allows all services to be distributed widely. However, to simplify this guide we have decided to discuss services of a more central nature using the concept of a single cloud controller.
OpenStack可大规模水平扩展的设计，这使得一切服务于分布式部署。然而，为了简化，在指南中，我们商量后决定服务使用更为核心的性质一个单一的云控制器的概念。
For more details about the overall architecture, see the Chapter 7, Example Architecture.
对于整体架构的更多细节，请参阅第7章，“范例架构”。
As described in this guide, the cloud controller is a single node that hosts the databases, message queue service, authentication and authorization service, image management service, user dashboard, and API endpoints.
本指南中描述，云控制器是一个单一的包括数据库，消息队列服务，身份验证和授权服务，镜像管理服务，用户面板，和API接口的节点主机。
The cloud controller provides the central management system for multi-node OpenStack deployments. Typically the cloud controller manages authentication and sends messaging to all the systems through a message queue.
云控制器为多节点OpenStack的部署提供了中央管理系统。通常情况下，云控制器管理认证，并把消息通过消息队列传送到所有的系统中。
For our example, the cloud controller has a collection of nova-* components that represent the global state of the cloud, talks to services such as authentication, maintains information about the cloud in a database, communicates to all compute nodes and storage workers through a queue, and provides API access. Each service running on a designated cloud controller may be broken out into separate nodes for scalability or availability.
在我们的例子中，云控制器中的nova-*组件集合代表云中的全局状态，如认证，在维护信息云数据库，通信，所有计算节点和存储工作通过队列与服务通信，并提供API访问。每个运行在云控制器上的服务可以分解成单独的节点从而提高可扩展性和可用性。
Hardware Considerations
A cloud controller's hardware can be the same as a compute node, though you may want to further specify based on the size and type of cloud that you run.
云控制器的硬件可以和计算节点相同，但这需要考虑你运营的云的大小与类型。
It's also possible to use virtual machines for all or some of the services that the cloud controller manages, such as the message queuing. In this guide, we assume that all services are running directly on the cloud controller.
也可以使用虚拟机管理云控制器的全部或部分的服务，如消息队列。在本指南中，我们假设，所有的服务都直接运行于云控制器。
To size the server correctly, and determine whether to virtualize any part of it, you should estimate:
确定正确配置的服务器，并确定是否要虚拟化运行其中的某些服务，你应该考虑以下几个方面的问题：
· The number of instances that you expect to run
将运行的实例数
· The number of compute nodes that you have
计算节点的数量
· The number of users who will access the compute or storage services
将访问计算或存储服务的用户数
· Whether users interact with your cloud through the REST API or the dashboard
用户是否通过REST API或与你的云仪表盘访问云
· Whether users authenticate against an external system (such as, LDAP or Active Directory)
用户是否使用对外部认证系统（如LDAP或AD）
· How long you expect single instances to run
单个实例将运行多久
| Consideration | Ramification |
| How many instances will run at once? | Size your database server accordingly, and scale out beyond one cloud controller if many instances will report status at the same time and scheduling where a new instance starts up needs computing power. |
| How many compute nodes will run at once? | Ensure that your messaging queue handles requests successfully and size accordingly. |
| How many users will access the API? | If many users will make multiple requests, make sure that the CPU load for the cloud controller can handle. it. |
| How many users will access thedashboard? | The dashboard makes many requests, even more than the API access, so add even more CPU if your dashboard is the main interface for your users. |
| How many | You need to size the controller with a core per service. |
| How long does a single instance run? | Starting instances and deleting instances is demanding on the compute node but also demanding on the controller node because of all the API queries and scheduling needs. |
| Does your authentication system also verify externally? | Ensure network connectivity between the cloud controller and external authentication system are good and that the cloud controller has the CPU power to keep up with requests. |
| 考虑 | 衍生物 |
| 许多情况下，如何将运行一次？ | 大小你的数据库服务器，并向外扩展一个云控制器之外，许多情况下，将一个新的实例启动时需要的计算能力在相同的时间和调度报告状态。 |
| 立即将运行在计算节点多少？ | 确保你的消息队列处理请求成功大小。 |
| 有多少用户将访问API？ | 如果许多用户将多个请求，确保为云控制器CPU可以处理负载。。 |
| 有多少用户将访问 仪表盘？ | 仪表板有很多访问请求，甚至超过API访问，所以如果仪表板将有很多用户访问，将需增加更多的CPU。 |
| 云中运行的nova-API服务有多少个？ | 为每个服务配置合迁大小的控制器。 |
| 单虚机运行多久？ | 启动虚机和删除虚机取决于计算节点，但也要求，因为所有的API查询和调度都取决于控制器节点。 |
| 身份验证系统是否使用外部身份验证服务？ | 确保云控制器和外部认证系统之间的网络连接是好的，且云控制器CPU足够处理这些请求。 |
Separation of Services
While our example contains all central services in a single location, it is possible and indeed often a good idea to separate services onto different physical servers. The following is a list of deployment scenarios we've seen, and their justifications.
虽然我们的例子是一个计算节点中集中所有的核心服务，如果可能，事实上分开到不同的物理服务服务器往往是一个好主意。下面是我们看到的一个部署方案的列表，其中有他们的理由。
| Run | This deployment felt the spare I/O on the Object Storage proxy server was sufficient, and the Image Delivery portion of Glance benefited from being on physical hardware and having good connectivity to the Object Storage back-end it was using. |
| Run a central dedicated database server | This deployment made a central dedicated server to provide the databases for all services. This simplified operations by isolating database server updates, and allowed for the simple creation of slave database servers for failover. |
| Run one VM per service | This deployment ran central services on a set of servers running KVM. A dedicated VM was created for each service (nova-scheduler, rabbitmq, database etc). This assisted the deployment with scaling as they could tune the resources given to each virtual machine based on the load they received (something that was not well understood during installation). |
| Use an external load balancer | This deployment had an expensive hardware load balancer in their organisation. They ran multiple |
| 在 | Object Storage代理服务器上空余I / O足够的，具有良好的Object Storage服务后端使用的镜像传输服务Glanc也将受益。 |
| 专用的数据库服务器 | 部署专用的服务器提供数据库的所有服务。这可以隔离并简化的数据库服务器的更新操作，并允许简单的创建数据库服务器的故障转移服务器。 |
| 每个服务一个VM | 部署一组服务器运行KVM在上运行中心服务。为每个服务创建一个专用的虚拟机（nova-scheduler,，RabbitMQ消息服务，数据库等）。在虚机上可以根据需求动态调整调整资源（在安装时这些这些是不一定能确定的）。 |
| 使用硬件负载平衡器 | 部署昂贵的硬件负载平衡器。使用负载平衡器可以快速切换在不同的物理服务器上运行的多个 nova-API和 |
One choice that always comes up is whether to virtualize or not. Some services, such as nova-compute, swift-proxy and swift-object servers, should not be virtualized. However, control servers can often be happily virtualized - the performance penalty can usually be offset by simply running more of the service.
总是需要在虚拟化或不虚拟化中作一个选择。如nova-compute，swift-proxy和swift-object的服务器，不应该被虚拟化。然而，控制服务器往往可以虚拟化 – 虚拟性能损失通常可以通过运行多个服务而被简单地抵消。
Database
Most OpenStack Compute central services, and currently also the nova-compute nodes, use the database for stateful information. Loss of this ability leads to errors. As a result, we recommend that you cluster your databases in some way to make them failure tolerant.
大多数OpenStack的计算服务中心，包括nova-compute节点，使用的数据库保存状态信息。数据库服务故障会导致错误。因此，我们建议您建立数据库集群采用某种方式使可以允许单点故障。
Message Queue
Most OpenStack Compute services communicate with each other using the Message Queue. In general, if the message queue fails or becomes inaccessible, the cluster grinds to a halt and ends up in a "read only" state, with information stuck at the point where the last message was sent. Accordingly, we recommend that you cluster the message queue - and RabbitMQ has in-build abilities to do this.
大多数OpenStack的计算服务使用Message Queue沟通。在一般情况下，如果消息队列失败或无法存取，集群就当机了，处在“只读”状态，停止在发送的最后一条消息的地状态。因此，我们建议您建立消息队列集群 – 使用RabbitMQ可以做到这一点。
Application Programming Interface (API)
All public access, whether direct, through a command line client, or through the web-based dashboard, uses the API service. Find the API reference athttp://api.openstack.org/.
所有公共访问，无论是直接通过命令行客户端，或通过Web的仪表板，使用API服务。有关API请参考http://api.openstack.org。
You must choose whether you want to support the Amazon EC2 compatibility APIs, or just the OpenStack APIs. One issue you might encounter when running both APIs is an inconsistent experience when referring to images and instances.
必须选择是否要支持与Amazon EC2兼容的API，或只是OpenStack的API。同时运行时，可能会遇到镜像和虚拟化实例API两者不一致的问题。
For example, the EC2 API refers to instances using IDs that contain hexadecimal whereas the OpenStack API uses names and digits. Similarly, the EC2 API tends to rely on DNS aliases for contacting virtual machines, as opposed to OpenStack which typically lists IP addresses.
例如，EC2 API是使用包含十六进制ID的实例，而OpenStack的API使用的名称和数字的实例。同样，EC2 API往往依靠DNS别名连接虚拟机，而OpenStack通常是使用IP地址。
If OpenStack is not set up in the right way, it is simple to have scenarios where users are unable to contact their instances due to only having an incorrect DNS alias. Despite this, EC2 compatibility can assist users migrating to your cloud.
如果OpenStack的设置不正确，简单的时候就是由于设置了一个不正确的DNS别名，用户是连接虚机。尽管这样，使用EC2兼容性可以帮助用户迁移云。
Like databases and message queues, having more than one API server is a good thing. Traditional HTTP load balancing techniques can be used to achieve a highly available nova-api service.
和数据库和消息队列一样，有多个API服务器是一件好事。可以使用传统的HTTP负载平衡技术，实现高可用的nova-API服务。
Extensions
The API Specifications (http://docs.openstack.org/api/api-specs.html) define the core actions, capabilities, and media-types of the OpenStack API. A client can always depend on the availability of this core API and implementers are always required to support it in its entirety. Requiring strict adherence to the core API allows clients to rely upon a minimal level of functionality when interacting with multiple implementations of the same API.
API标准（http://docs.openstack.org/api/api-specs.html）定义了核心操作，能力，和OpenStack的媒体类型API。客户端可以始终依赖于这些核心API的可用性和实施者总是需要全程支持。需要严格遵守的核心API，这样允许客户使用不同的多个实现相同功能API交互时依赖于最小化功能。
The OpenStack Compute API is extensible. An extension adds capabilities to an API beyond those defined in the core. The introduction of new features, MIME types, actions, states, headers, parameters, and resources can all be accomplished by means of extensions to the core API. This allows the introduction of new features in the API without requiring a version change and allows the introduction of vendor-specific niche functionality.
OpenStack Compute API是可扩展的。扩展功能超出核心定义的API。引入的新功能，MIME类型，动作，状态，标题，参数，和资源都可以扩展核心API。这允许在API中引入的新功能，而不需要改变整个版本，并允许供应商引入特定的利基功能。
Scheduler
Fitting various sized virtual machines (different flavors) into different sized physical nova-compute nodes is a challenging problem - researched generically in Computer Science as a packing problem.
在不同的大小的物理nova-compute节点（different flavors）配置各种大小的虚拟机，是一个具有挑战性的问题 - 笼统的研究在计算机科学作为一个问题集合。
You can use various techniques to handle this problem, one of which is to have flavor sizes scale linearly, be a proportional fraction of your physical node capacity, though solving this problem is out of the scope of this book. To support your scheduling choices, OpenStack Compute provides several different types of scheduling drivers, a full discussion of which is found in the reference manual (http://docs.openstack.org/folsom/openstack-compute/admin/content/ch_scheduling.html).
可以使用各种技术来处理这个问题，其中之一就是使用合适的比例调整物理节点容量，但解决这个问题超出这本书的范围。为了支持你的调度选择，OpenStack计算提供了几种不同类型的调度机制，可以参考完整的调度参考手册（http://docs.openstack.org/folsom/openstack-compute/admin/content/ch_scheduling.html）。
For availability purposes, or for very large or high-schedule frequency installations, you should consider running multiple nova-scheduler services. No special load balancing is required, as the nova-scheduler communicates entirely using the message queue.
出于高可用性目的，或非常大或高频率安装，你应该考虑运行多个nova-scheduler服务。无特殊的负载均衡，因为nova-scheduler通信完全使用消息队列。
Images
The OpenStack Image Catalog and Delivery service consists of two parts - glance-api and glance-registry. The former is responsible for the delivery of images and the compute node uses it to download images from the back-end. The latter maintains the metadata information associated with virtual machine images and requires a database.
OpenStack Image Catalog和Delivery服务由两部分组成 - glance-api和glance-registry。前者负责镜像交付发布和计算节点使用它下载镜像。后者维护元数据与虚拟机映像相关的信息，这需要一个数据库。
The glance-api part is an abstraction layer that allows a choice of back-end. Currently, it supports:
glance-api是一个抽象层，允许选择不同的后端实现。目前，它支持：
· OpenStack Object Storage. Allows you to store images as objects.
· OpenStack对象存储。允许作为对象来存储镜像。
· File system. Uses any traditional file system to store the images as files.
· 文件系统。使用任何传统的文件系统来存储镜像文件。
· S3. Allows you to fetch images from Amazon S3. You cannot write images by using this mode.
· S3。允许您从Amazon S3获取镜像。你使用此模式时不能修改镜像。
· HTTP. Allows you to fetch images from a web server. You cannot write images by using this mode.
· HTTP协议。允许您从Web服务器获取镜像。你使用此模式时不能修改镜像。
If you have an OpenStack Object Storage service, we recommend using this as a scalable place to store your images. Failing that, a file system with sufficient performance is the only real option - unless you do not need the ability to upload new images through OpenStack.
如果你有一个OpenStack Object Storage服务，我们建议使用它作为一个可扩展位置来存储镜像。做不到这一点，一个具有足够的性能的文件系统是唯一正确的选择 - 除非你不需要通过OpenStack上传新的镜像。
Dashboard
The OpenStack Dashboard is implemented as a Python web application that runs in Apache httpd. Therefore, you may treat it the same as any other web application, provided it can reach the API servers (including their admin endpoints) over the network.
OpenStack的仪表板是运行在Apache httpd使用Python实现的Web应用程序。因此，可以同其它任何其他Web应用程序一样，通过网络，就可以与API服务器交互（包括其管理接口）。
Authentication and Authorization
The concepts supporting OpenStack's authentication and authorization are derived from well understood and widely used systems of a similar nature. Users have credentials they can use to authenticate, and they can be a member of one or more groups (known as projects or tenants interchangeably).
支持OpenStack的身份验证和授权的概念都源于类似性质被充分理解和广泛使用的系统。用户可以用它来进行身份验证的凭据，他们可以是一个或多个组的成员（被称为项目或租户）。
For example, a cloud administrator might be able to list all instances in the cloud, whereas a user can only see those in their current group. Resources quotas, such as the number of cores that can be used, disk space, and so on, are associated with a project.
例如，云管理员可能可以看到云中的所有虚拟实例，而用户只能看到其当前工作组中的所有实例。资源配额，例如可以使用的内核，磁盘空间等的数量，与项目相关联。
The OpenStack Identity Service (Keystone) is the point that provides the authentication decisions and user attribute information, which is then used by the other OpenStack services to perform authorization. Policy is set in the policy.json file. For information on how to configure these, seeChapter 10, Managing Projects and Users.
OpenStack Identity Service服务（KeyStone），能够提供用户的认证和用户属性信息，然后将对用户使用的其它OpenStack的服务进行授权。策略设置在policy.json文件中。对于如何配置这些信息，请参阅第10章，管理项目和用户。
The Identity Service supports different plugins for back-end authentication decisions, and storing information. These range from pure storage choices to external systems and currently include:
Identity Service服务后端支持使用不同的插件进行身份验证认证，和存储信息。这可以是纯粹的存储到外部系统，目前包括：
· In-memory Key-Value Store
· SQL database
· PAM
· LDAP
Many deployments use the SQL database, however LDAP is also a popular choice for those with existing authentication infrastructure that needs to be integrated.
大部分部署都使用SQL数据库，为了与现有的认证架构集成LDAP也是热门选择。
Network Considerations
Because the cloud controller handles so many different services, it must be able to handle the amount of traffic that hits it. For example, if you choose to host the OpenStack Imaging Service on the cloud controller, the cloud controller should be able to support the transferring of the images at an acceptable speed.
因为云控制器处理这么多不同的服务，它必须有足够带度来处理这些流量。例如，如果您选择OpenStack云控制器上的镜像服务，云控制器应该有一个可接受的速度，能够支持镜像的转移。
As another example, if you choose to use single-host networking where the cloud controller is the network gateway for all instances, then the Cloud Controller must support the total amount of traffic that travels between your cloud and the public Internet.
再举一个例子，如果你选择使用单个主机联网，云控制器是所有实例的网络网关，那么云控制器必须支持云和公共互联网之间总的网络流程。
We recommend that you use a fast NIC, such as 10 GB. You can also choose to use two 10 GB NICs and bond them together. While you might not be able to get a full bonded 20 GB speed, different transmission streams use different NICs. For example, if the Cloud Controller transfers two images, each image uses a different NIC and gets a full 10 GB of bandwidth.
建议使用一个快速的网卡，如10 GB。还可以选择使用两个10 GB网卡并将它们绑定在一起。虽然你可能无法得到20 GB的速度，但不同的传输流可以使用不同的NIC。例如，如果云控制器传输2个镜像，每个镜像使用不同的NIC，就可以得到10 GB的带宽。