Merge "[arch-design-draft] Update compute server hardware content"
This commit is contained in:
commit
25c29751ba
|
@ -17,36 +17,72 @@ Consider the following factors when selecting compute (server) hardware:
|
||||||
reaches capacity.
|
reaches capacity.
|
||||||
|
|
||||||
* Cost
|
* Cost
|
||||||
The relative cost of the hardware weighed against the level of
|
The relative cost of the hardware weighed against the total amount of
|
||||||
design effort needed to build the system.
|
capacity available on the hardware based on predetermined requirements.
|
||||||
|
|
||||||
|
|
||||||
Compute (server) hardware selection
|
Compute (server) hardware selection
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Weigh these considerations against each other to determine the best
|
Weigh these considerations against each other to determine the best design for
|
||||||
design for the desired purpose. For example, increasing server density
|
the desired purpose. For example, increasing server density means sacrificing
|
||||||
means sacrificing resource capacity or expandability. Increasing resource
|
resource capacity or expandability. It also can decrease availability and
|
||||||
capacity and expandability can increase cost but decrease server density.
|
increase the chance of noisy neighbor issues. Increasing resource capacity and
|
||||||
Decreasing cost often means decreasing supportability, server density,
|
expandability can increase cost but decrease server density. Decreasing cost
|
||||||
resource capacity, and expandability.
|
often means decreasing supportability, availability, server density, resource
|
||||||
|
capacity, and expandability.
|
||||||
|
|
||||||
Compute capacity (CPU cores and RAM capacity) is a secondary
|
The primary job of the OpenStack architect is to determine the requirements for
|
||||||
consideration for selecting server hardware. The required
|
the cloud prior to constructing the cloud, and planning for expansion
|
||||||
server hardware must supply adequate CPU sockets, additional CPU cores,
|
and new features that may require different hardware. Planning for hardware
|
||||||
and more RAM. Network connectivity and storage capacity are not as
|
lifecycles is also the job of the architect. However, if the cloud is initially
|
||||||
critical. Your hardware will need to provide enough network connectivity and
|
built with near end of life, but cost effective hardware, then the
|
||||||
storage capacity to meet the user requirements.
|
performance and capacity demand of new workloads will drive the purchase of
|
||||||
|
more modern hardware quicker. With individual harware components changing over
|
||||||
|
time, companies may prefer to manage configurations as stock keeping units
|
||||||
|
(SKU)s. This method provides an enterprise with a standard configuration unit
|
||||||
|
of compute (server) that can be placed in any IT service manager or vendor
|
||||||
|
supplied ordering system that can be triggered manually or through advanced
|
||||||
|
operational automations. This simplifies ordering, provisioning, and
|
||||||
|
activating additional compute resources. For example, there are plug-ins for
|
||||||
|
several commercial service management tools that enable integration with
|
||||||
|
hardware APIs. This configures and activates new compute resources from standby
|
||||||
|
hardware based on a standard configurations. Using this methodology, spare
|
||||||
|
hardware can be ordered for a datacenter and provisioned based on
|
||||||
|
capacity data derived from OpenStack Telemetry.
|
||||||
|
|
||||||
|
Compute capacity (CPU cores and RAM capacity) is a secondary consideration for
|
||||||
|
selecting server hardware. The required server hardware must supply adequate
|
||||||
|
CPU sockets, additional CPU cores, and adequate RAM, and is discussed in detail
|
||||||
|
under the CPU selection secution.
|
||||||
|
|
||||||
|
However, there are also network and storage considerations for any compute
|
||||||
|
server. Network considerations are discussed in the
|
||||||
|
`network section
|
||||||
|
<http://docs.openstack.org/draft/arch-design-draft/design-networking.html>`_
|
||||||
|
of this chapter.
|
||||||
|
|
||||||
|
|
||||||
|
Scaling your cloud
|
||||||
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
For a compute-focused cloud, emphasis should be on server
|
For a compute-focused cloud, emphasis should be on server
|
||||||
hardware that can offer more CPU sockets, more CPU cores, and more RAM.
|
hardware that can offer more CPU sockets, more CPU cores, and more RAM.
|
||||||
Network connectivity and storage capacity are less critical.
|
Network connectivity and storage capacity are less critical.
|
||||||
|
|
||||||
When designing a OpenStack cloud architecture, you must
|
When designing a OpenStack cloud compute server architecture, you must
|
||||||
consider whether you intend to scale up or scale out. Selecting a
|
consider whether you intend to scale up or scale out. Selecting a
|
||||||
smaller number of larger hosts, or a larger number of smaller hosts,
|
smaller number of larger hosts, or a larger number of smaller hosts,
|
||||||
depends on a combination of factors: cost, power, cooling, physical rack
|
depends on a combination of factors: cost, power, cooling, physical rack
|
||||||
and floor space, support-warranty, and manageability.
|
and floor space, support-warranty, and manageability. Typically, the scale out
|
||||||
|
model has been popular for OpenStack because it further reduces the number of
|
||||||
|
possible failure domains by spreading workloads across more infrastructure.
|
||||||
|
However, the downside is the cost of additional servers and the datacenter
|
||||||
|
resources needed to power, network, and cool them.
|
||||||
|
|
||||||
|
|
||||||
|
Hardware selection considerations
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Consider the following in selecting server hardware form factor suited for
|
Consider the following in selecting server hardware form factor suited for
|
||||||
your OpenStack design architecture:
|
your OpenStack design architecture:
|
||||||
|
@ -90,45 +126,56 @@ your OpenStack design architecture:
|
||||||
For example, many sled servers offer four independent dual-socket
|
For example, many sled servers offer four independent dual-socket
|
||||||
nodes in 2U for a total of eight CPU sockets in 2U.
|
nodes in 2U for a total of eight CPU sockets in 2U.
|
||||||
|
|
||||||
Other factors that influence server hardware selection for an OpenStack
|
|
||||||
design architecture include:
|
Other factors to consider
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Here are some other factors to consider when selecting hardware for your
|
||||||
|
compute servers.
|
||||||
|
|
||||||
Instance density
|
Instance density
|
||||||
More hosts are required to support the anticipated scale
|
----------------
|
||||||
if the design architecture uses dual-socket hardware designs.
|
|
||||||
|
|
||||||
For a general purpose OpenStack cloud, sizing is an important consideration.
|
More hosts are required to support the anticipated scale
|
||||||
The expected or anticipated number of instances that each hypervisor can
|
if the design architecture uses dual-socket hardware designs.
|
||||||
host is a common meter used in sizing the deployment. The selected server
|
|
||||||
hardware needs to support the expected or anticipated instance density.
|
For a general purpose OpenStack cloud, sizing is an important consideration.
|
||||||
|
The expected or anticipated number of instances that each hypervisor can
|
||||||
|
host is a common meter used in sizing the deployment. The selected server
|
||||||
|
hardware needs to support the expected or anticipated instance density.
|
||||||
|
|
||||||
Host density
|
Host density
|
||||||
Another option to address the higher host count is to use a
|
------------
|
||||||
quad-socket platform. Taking this approach decreases host density
|
|
||||||
which also increases rack count. This configuration affects the
|
|
||||||
number of power connections and also impacts network and cooling
|
|
||||||
requirements.
|
|
||||||
|
|
||||||
Physical data centers have limited physical space, power, and
|
Another option to address the higher host count is to use a
|
||||||
cooling. The number of hosts (or hypervisors) that can be fitted
|
quad-socket platform. Taking this approach decreases host density
|
||||||
into a given metric (rack, rack unit, or floor tile) is another
|
which also increases rack count. This configuration affects the
|
||||||
important method of sizing. Floor weight is an often overlooked
|
number of power connections and also impacts network and cooling
|
||||||
consideration. The data center floor must be able to support the
|
requirements.
|
||||||
weight of the proposed number of hosts within a rack or set of
|
|
||||||
racks. These factors need to be applied as part of the host density
|
Physical data centers have limited physical space, power, and
|
||||||
calculation and server hardware selection.
|
cooling. The number of hosts (or hypervisors) that can be fitted
|
||||||
|
into a given metric (rack, rack unit, or floor tile) is another
|
||||||
|
important method of sizing. Floor weight is an often overlooked
|
||||||
|
consideration.
|
||||||
|
The data center floor must be able to support the
|
||||||
|
weight of the proposed number of hosts within a rack or set of
|
||||||
|
racks. These factors need to be applied as part of the host density
|
||||||
|
calculation and server hardware selection.
|
||||||
|
|
||||||
Power and cooling density
|
Power and cooling density
|
||||||
The power and cooling density requirements might be lower than with
|
-------------------------
|
||||||
blade, sled, or 1U server designs due to lower host density (by
|
|
||||||
using 2U, 3U or even 4U server designs). For data centers with older
|
|
||||||
infrastructure, this might be a desirable feature.
|
|
||||||
|
|
||||||
Data centers have a specified amount of power fed to a given rack or
|
The power and cooling density requirements might be lower than with
|
||||||
set of racks. Older data centers may have a power density as power
|
blade,sled, or 1U server designs due to lower host density (by
|
||||||
as low as 20 AMPs per rack, while more recent data centers can be
|
using 2U, 3U or even 4U server designs). For data centers with older
|
||||||
architected to support power densities as high as 120 AMP per rack.
|
infrastructure, this might be a desirable feature.
|
||||||
The selected server hardware must take power density into account.
|
|
||||||
|
Data centers have a specified amount of power fed to a given rack or
|
||||||
|
set of racks. Older data centers may have a power density as power
|
||||||
|
as low as 20 AMPs per rack, while more recent data centers can be
|
||||||
|
architected to support power densities as high as 120 AMP per rack.
|
||||||
|
The selected server hardware must take power density into account.
|
||||||
|
|
||||||
Specific hardware concepts
|
Specific hardware concepts
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
Loading…
Reference in New Issue