Compute nodes form the resource core of the OpenStack Compute cloud, providing the processing, memory, network and storageresources to run instances.
计算节点组成OpenStack计算云资源的核⼼，为运⾏实例提供计算，内存，⽹络和存储资源。CPU Choice
The type of CPU in your compute node is a very important choice. First, ensure the CPU supports virtualization by way of VT-x for Intelchips andAMD-v for AMD chips.
计算节点CPU的类型是⼀个⾮常重要的选择。⾸先，保证CPU⽀持英特尔芯⽚VT-X和AMD芯⽚AMD-V的虚拟化技术。
The number of cores that the CPU has also affects the decision. It's common for current CPUs to have up to 12 cores. Additionally, if theCPU supports Hyper-threading, those 12 cores are doubled to 24 cores. If you purchase a server that supports multiple CPUs, the numberof cores is further multiplied.
CPU具有的核⼼数也是很重要的。⽬前CPU，通常拥有多达12个核⼼。此外，如果CPU⽀持超线程，12个核⼼意味着24个核⼼。如果您购买了⽀持多个CPU的服务器，核⼼数将成倍增长。
Whether you should enable hyper-threading on your CPUs depends upon your use case. We recommend you do performance testing withyour local workload with both hyper-threading on and off to determine what is more appropriate in your case.
CPU上是否应该启⽤超线程取决于使⽤情况。建议同时开启和关闭超线程的情况下做性能测试⽤以确定那种选择更适合实际的⼯作负载。Hypervisor Choice
OpenStack Compute supports many hypervisors to various degrees, including , , , , , , , .
OpenStack计算⽀持许多不同的虚拟化技术，包括KVM，LXC，QEMU，UML， VMWare ESX / ESXi，Xen，PowerVM，Hyper-V。Probably the most important factor in your choice of hypervisor is your current usage or experience. Aside from that, there are practicalconcerns to do with feature parity, documentation, and the level of community experience.
也许选择的虚拟机管理程序的最重要的因素是您当前使⽤经验。除此之外，特别的功能，⽂档与社区经验也是需要考虑的。
For example, KVM is the most widely adopted hypervisor in the OpenStack community. Besides KVM, more deployments exist runningXen, LXC, VMWare and Hyper-V than the others listed — however, each of these are lacking some feature support or the documentationon how to use them with OpenStack is out of date.
例如，OpenStack社区中KVM是最⼴泛采⽤的的虚拟机管理程序。除了KVM，就是部署Xen，LXC，VMware和Hyper-V，然⽽，这些都缺乏⼀些功能⽀持或⽂档中使它们在OpenStack使⽤会觉得过时。
Note
It is also possible to run multiple hypervisors in a single deployment using Host Aggregates or Cells. However, an individualcompute node can only run a single hypervisor at a time单个部署中也可以使⽤Host Aggregates或Cells运⾏多个虚拟机管理程序。然⽽，⼀个单独的计算节点只能运⾏单个虚拟机管理程序。.
Instance Storage Solutions
As part of the procurement for a compute cluster, you must specify some storage for the disk on which the instantiated instance runs. Thereare three main approaches to providing this temporary-style storage, and it is important to understand the implications of the choice.作为采购计算群集的⼀部分，你必须指定实例运⾏使⽤的磁盘存储。主要有三种⽅法提供temporary-style的存储，理解其含义并作出选择是很重要的。They are:
Off compute node storage – shared file system⾮计算节点存储 - 共享⽂件系统
On compute node storage – shared file system计算节点的存储 - 共享⽂件系统
On compute node storage – non-shared file system在计算节点存储 - ⾮共享⽂件系统
In general, the questions you should be asking when selecting the storage are as follows:
通常，应该通过回答以下问题来选择合适的存储类型：
What is the platter count you can achieve?可以实现的多⼤的盘⽚计数？
Do more spindles result in better I/O despite network access?除开⽹络访问最⼤的I / O？
Which one results in the best cost-performance scenario you're aiming for?符合⽬的场景下哪⼀个最佳的成本性能选择？How do you manage the storage operationally?如何管理存储操作？
Off Compute Node Storage – Shared File System
Many operators use separate compute and storage hosts. Compute services and storage services have different requirements, computehosts typically require more CPU and RAM than storage hosts. Therefore, for a fixed budget, it makes sense to have different configurationsfor your compute nodes and your storage nodes with compute nodes invested in CPU and RAM, and storage nodes invested in blockstorage.
许多运营商使⽤独⽴计算和存储主机。计算服务和存储服务有不同的要求，同存储主机相⽐计算主机通常需要更多的CPU和RAM。因此，对于确定的预算，计算节点和存储节点在CPU与RAM,块存储⽅⾯的花费有不同的配置是有道理的。
Also, if you use separate compute and storage hosts then you can treat your compute hosts as \"stateless\". This simplifies maintenance forthe compute hosts. As long as you don't have any instances currently running on a compute host, you can take it offline or wipe itcompletely without having any effect on the rest of your cloud.
此外，如果使⽤单独的计算和存储主机，可以把计算主机 “stateless”化。这可简化计算主机的维护。只要当前没有任何实例在计算主机上运⾏，你可以将其离线或移除⽽完全不会任何影响云中其余的主机。
However, if you are more restricted in the number of physical hosts you have available for creating your cloud and you want to be able todedicate as many of your hosts as possible to running instances, it makes sense to run compute and storage on the same machines.但是，如果想让主机尽可以多的创建运⾏更多的实例，计算和存储在同⼀机器也是有道理的。
In this option, the disks storing the running instances are hosted in servers outside of the compute nodes. There are also severaladvantages to this approach:
在这个选项中，正在运⾏的实例的磁盘存储托管在计算节点以外的服务器。这种⽅法也有⼀些优势：
If a compute node fails, instances are usually easily recoverable.如果⼀个计算节点失败，实例通常是很容易恢复。
Running a dedicated storage system can be operationally simpler.运⾏⼀个专⽤的存储系统操作更简单。
Being able to scale to any number of spindles.能够扩展到任意数量的主轴。
It may be possible to share the external storage for other purposes.可能是可以共享⽤于其他⽬的的外部存储。The main downsides to this approach are:这种⽅法的主要缺点是：
Depending on design, heavy I/O usage from some instances can affect unrelated instances.这种设计对于⾼I / O实例使⽤在某些情况下会影响与之⽆关的实例。Use of the network can decrease performance.使⽤的⽹络会降低性能。
On Compute Node Storage – Shared File System
In this option, each nova-compute node is specified with a significant amount of disks, but a distributed file system ties the disks from eachcompute node into a single mount. The main advantage of this option is that it scales to external storage when you require additionalstorage.
在此选项中，每个nova-compute节点具有较多的磁盘数量，分布式⽂件系统将每个计算节点的磁盘联接成⼀个统⼀的存储系统。这个选项的主要优点是，当你需要额外的存储空间很容易扩展。However, this option has several downsides:但是，此选项有以下⼏个缺点：
Running a distributed file system can make you lose your data locality compared with non-shared storage.运⾏⼀个分布式⽂件系统，同⾮共享存储相⽐会让你失去你的本地数据局部性。Recovery of instances is complicated by depending on multiple hosts.
实例恢复依靠多个主机上，⾮常复杂。
The chassis size of the compute node can limit the number of spindles able to be used in a compute node.机箱尺⼨计算节点可能限制能够被⽤于计算节点的数量。Use of the network can decrease performance.使⽤的⽹络会降低性能。
On Compute Node Storage – Non-shared File System
In this option, each nova-compute node is specified with enough disks to store the instances it hosts. There are two main reasons why thisis a good idea:
在此选项中，每个nova-compute节点有⾜够的磁盘存储它承载的实例。这是⼀个好主意，主要有两个原因：
Heavy I/O usage on one compute node does not affect instances on other compute nodes.⼤量I / O在⼀个计算节点上，不影响其他计算节点的实例。Direct I/O access can increase performance.直接I / O访问可以提⾼性能。This has several downsides:这有以下⼏个缺点：
If a compute node fails, the instances running on that node are lost.如果⼀个计算节点出现故障时，该节点上运⾏的实例都将丢失。
The chassis size of the compute node can limit the number of spindles able to be used in a compute node.计算节点机箱尺⼨限制能够被⽤于计算节点的磁盘数量。
Migrations of instances from one node to another are more complicated, and rely on features which may not continue to bedeveloped.
从⼀个节点到另⼀个节点的实例迁移更为复杂，相关的功能可能不会被继续开发。If additional storage is required, this option does not to scale.如果需要额外的存储空间，这个选项⽆法扩展。Issues with Live Migration
We consider live migration an integral part of the operations of the cloud. This feature provides the ability to seamlessly move instancesfrom one physical host to another, a necessity for performing upgrades that require reboots of the compute hosts, but only works well withshared storage.
我们认为实时（热）迁移是云服务的⼀个组成部分。它提供了将实例从⼀个物理主机⽆缝地迁移到另⼀个物理主机功能，这在执⾏升级，需要重新启动计算主机时是必要，但这只有在使⽤共享存储的情况下才有效。
Theoretically live migration can be done with non-shared storage, using a feature known as KVM live block migration. However, this is alittle-known feature in OpenStack, with limited testing when compared to live migration, and is slated for deprecation in KVM upstream.理论上⾮共享存储可以做到实时迁移，使⽤的功能被称为KVM live block迁移。然⽽，这是OpenStack的⼀个鲜为⼈知的功能，与实时迁移相⽐它的测试时有限，KVM也不赞成这样做。Choice of File System
If you want to support shared storage live migration, you'll need to configure a distributed file system.Possible options include:
如果想使⽤⽀持共享存储的实时迁移，需要配置⼀个分布式⽂件系统。可能的选择包括：
NFS (default for Linux)GlusterFSMooseFSLustre
We've seen deployments with all, and recommend you choose the one you are most familiar with operating.我们已经看到了所有的部署，建议你选择⼀个你最熟悉的进⾏部署。Overcommitting
OpenStack allows you to overcommit CPU and RAM on compute nodes. This allows you to increase the number of instances you can haverunning on your cloud, at the cost of reducing the performance of the instances. OpenStack Compute uses the following ratios by default:OpenStack允许计算节点上超量使⽤CPU和RAM。在成本相同降低实例性能的情况下，这允许在云上运⾏更多的实例。 OpenStack计算⽐默认情况下，使⽤以下：
CPU allocation ratio: 16
RAM allocation ratio: 1.5
The default CPU allocation ratio of 16 means that the scheduler allocates up to 16 virtual cores on a node per physical cores. For example,if a physical node has 12 cores, and each virtual machine instance uses 4 virtual cores, the scheduler allocates up to 192 virtual cores toinstances (such as, 48 instances, in the case where each instance has 4 virtual cores).
默认的CPU分配⽐为16意味着每个物理核⼼的节点上可调度分配多达16个虚拟内核。例如，如果⼀个物理节点有12个核⼼，每个虚拟机实例使⽤4个虚拟内核，可调度分配192个虚拟内核的实例（如，48个实例，每个实例都有4个虚拟内核的情况下）。
Similarly, the default RAM allocation ratio of 1.5 means that the scheduler allocates instances to a physical node as long as the totalamount of RAM associated with the instances is less than 1.5 times the amount of RAM available on the physical node.
同样地，默认的的RAM分配⽐例1.5装置的调度器分配到物理节点只要与实例相关联的RAM的总量是⼩于1.5倍的物理节点上可⽤的RAM数量的实例。
For example, if a physical node has 48 GB of RAM, the scheduler allocates instances to that node until the sum of the RAM associated withthe instances reaches 72 GB (such as nine instances, in the case where each instance has 8 GB of RAM).
例如，如果⼀个物理节点48 GB的RAM，调度器分配到该节点的实例，直到与实例相关的RAM的总和达到72 GB（如9个实例，每个实例有8GB的RAM ）。
You must select the appropriate CPU and RAM allocation ratio for your particular use case.必须为特定使⽤情况选择合适的CPU和RAM的分配⽐例。Logging
Logging is detailed more fully in . However it is an important design consideration to take into account before commencing operations ofyour cloud.
OpenStack produces a great deal of useful logging information, however, in order for it to be useful for operations purposes you shouldconsider having a central logging server to send logs to, and a log parsing/analysis system (such as logstash).
⽇志有关更充分的描述在“⽇志”⼀节中有详细记录。然⽽，考虑云的运营，这个设计很重要。OpenStack⾥产⽣了⼤量的有⽤的⽇志信息，但是，为了出于业务需要并充分利⽤它，应该考虑发送⽇志到具有中央⽇志解析/分析系统服务器，（如logstash）。Networking
Networking in OpenStack is a complex, multi-faceted challenge. See .OpenStack的⽹络是⼀个复杂的，多⽅位的挑战。请参阅第6章，⽹络设计。
因篇幅问题不能全部显示，请点此查看更多更全内容