Merge "Copy-edits for ch_arch_network_design"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
2821befbd7
|
|
@ -17,10 +17,10 @@
|
|||
chapter details the requirements and options to deliberate
|
||||
when designing your cloud.</para>
|
||||
<warning><para>If this is the first time you are deploying a cloud
|
||||
infrastructure in your organisation, after reading this
|
||||
infrastructure in your organization, after reading this
|
||||
section, your first conversations should be with your
|
||||
networking team. Network usage in a running cloud is vastly
|
||||
different from traditional network deployments, and has the
|
||||
different from traditional network deployments and has the
|
||||
potential to be disruptive at both a connectivity and a policy
|
||||
level.</para></warning>
|
||||
<para>For example, you must plan the number of IP addresses that
|
||||
|
|
@ -28,23 +28,23 @@
|
|||
infrastructure. Additionally, you must research and discuss
|
||||
cloud network connectivity through proxy servers and
|
||||
firewalls.</para>
|
||||
<para>In this chapter we'll give some examples of network implementations to
|
||||
consider, and provide some information about some of the network layouts
|
||||
<para>In this chapter, we'll give some examples of network implementations to
|
||||
consider and provide information about some of the network layouts
|
||||
that OpenStack uses. Finally, we have some brief notes on the networking
|
||||
services that are essential for stable operation.</para>
|
||||
<section xml:id="mgmt_network">
|
||||
<title>Management Network</title>
|
||||
<para>A <glossterm>management network</glossterm> (a separate network for use by your
|
||||
cloud operators), typically consisting of a separate
|
||||
switch and separate NICs (Network Interface Cards), is a
|
||||
switch and separate NICs (network interface cards), is a
|
||||
recommended option. This
|
||||
segregation prevents system administration and monitoring
|
||||
system access from being disrupted by traffic generated by
|
||||
the guests.</para>
|
||||
segregation prevents system administration and the monitoring
|
||||
of system access from being disrupted by traffic generated by
|
||||
guests.</para>
|
||||
<para>Consider creating other private networks for
|
||||
communication between internal components of OpenStack,
|
||||
such as the Message Queue and OpenStack Compute. Using a
|
||||
Virtual Local Area Network (VLAN)
|
||||
such as the message queue and OpenStack Compute. Using a
|
||||
virtual local area network (VLAN)
|
||||
works well for these scenarios because it provides
|
||||
a method for creating multiple virtual networks on a
|
||||
physical network.</para>
|
||||
|
|
@ -52,22 +52,22 @@
|
|||
<section xml:id="public_addressing">
|
||||
<title>Public Addressing Options</title>
|
||||
<para>There are two main types of IP addresses for guest
|
||||
virtual machines: Fixed IPs and Floating IPs. Fixed IPs
|
||||
are assigned to instances on boot, whereas Floating IP
|
||||
virtual machines: fixed IPs and floating IPs. Fixed IPs
|
||||
are assigned to instances on boot, whereas floating IP
|
||||
addresses can change their association between instances
|
||||
by action of the user. Both types of IP addresses can
|
||||
either be public or private, depending on your use
|
||||
be either public or private, depending on your use
|
||||
case.</para>
|
||||
<para>Fixed IP addresses are required, whereas it is possible
|
||||
to run OpenStack without Floating IPs. One of the most
|
||||
common use cases for Floating IPs is to provide public IP
|
||||
to run OpenStack without floating IPs. One of the most
|
||||
common use cases for floating IPs is to provide public IP
|
||||
addresses to a private cloud, where there are a limited
|
||||
number of IP addresses available. Another is for a public
|
||||
cloud user to have a "static" IP address that can be
|
||||
reassigned when an instance is upgraded or moved.</para>
|
||||
<para>Fixed IP addresses can be private for private clouds, or
|
||||
public for public clouds. When an instance terminates, its
|
||||
Fixed IP is lost. It is worth noting that newer users of
|
||||
fixed IP is lost. It is worth noting that newer users of
|
||||
cloud computing may find their ephemeral nature
|
||||
frustrating.</para>
|
||||
</section>
|
||||
|
|
@ -79,7 +79,7 @@
|
|||
address plan can assist with a shared understanding of
|
||||
network partition purposes and scalability. Control
|
||||
services can have public and private IP addresses, and as
|
||||
noted above there are a couple of options for instance's
|
||||
noted above there are a couple of options for an instance's
|
||||
public addresses.</para>
|
||||
<para>An IP address plan might be broken down into the
|
||||
following sections:</para>
|
||||
|
|
@ -97,15 +97,15 @@
|
|||
<td><para>Public access to
|
||||
<code>swift-proxy</code>,
|
||||
<code>nova-api</code>,
|
||||
<code>glance-api</code> and horizon
|
||||
<code>glance-api</code>, and horizon
|
||||
come to these addresses, which could be on
|
||||
one side of a load balancer, or pointing
|
||||
one side of a load balancer or pointing
|
||||
at individual machines.</para></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><para><emphasis role="bold">Object Storage cluster internal
|
||||
communications</emphasis></para></td>
|
||||
<td><para>Traffic amongst object/account/container
|
||||
<td><para>Traffic among object/account/container
|
||||
servers and between these and the proxy
|
||||
server's internal interface uses this
|
||||
private network.</para></td>
|
||||
|
|
@ -126,7 +126,7 @@
|
|||
</tr>
|
||||
<tr>
|
||||
<td><para><emphasis role="bold">in-band remote management</emphasis></para></td>
|
||||
<td><para>Often, an extra (such as, 1 GB)
|
||||
<td><para>Often, an extra (such as 1 GB)
|
||||
interface on compute or storage nodes is
|
||||
used for system administrators or
|
||||
monitoring tools to access the host
|
||||
|
|
@ -137,16 +137,16 @@
|
|||
<td><para><emphasis role="bold">spare space for future
|
||||
growth</emphasis></para></td>
|
||||
<td><para>Adding more public-facing control
|
||||
services, or guest instance IPs should
|
||||
services or guest instance IPs should
|
||||
always be part of your plan.</para></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<para>For example, take a deployment which has both OpenStack
|
||||
<para>For example, take a deployment that has both OpenStack
|
||||
Compute and Object Storage, with private ranges
|
||||
172.22.42.0/24 and 172.22.87.0/26 available. One way to
|
||||
segregate the space might be:</para>
|
||||
<programlisting><?db-font-size 55%?>172.22.42.0/24
|
||||
segregate the space might be as follows:</para>
|
||||
<programlisting><?db-font-size 55%?>172.22.42.0/24:
|
||||
172.22.42.1 - 172.22.42.3 - subnet routers
|
||||
172.22.42.4 - 172.22.42.20 - spare for networks
|
||||
172.22.42.21 - 172.22.42.104 - Compute node remote access controllers (inc spare)
|
||||
|
|
@ -170,7 +170,7 @@
|
|||
<section xml:id="network_topology">
|
||||
<title>Network Topology</title>
|
||||
<para>OpenStack Compute with nova-network provides pre-defined network
|
||||
deployment models, each with their own strengths and weaknesses. The
|
||||
deployment models, each with its own strengths and weaknesses. The
|
||||
selection of a network manager changes your network topology, so the
|
||||
choice should be made carefully. You also have a choice between the
|
||||
tried-and-true legacy nova-network settings or the neutron project
|
||||
|
|
@ -181,10 +181,12 @@
|
|||
configure with real hardware you can re-create with a
|
||||
software-defined equivalent. Each tenant can contain typical network
|
||||
elements such as routers and services such as DHCP.</para>
|
||||
<para>This table discusses the networking deployment options for both
|
||||
<para><xref linkend="network_deployment_options"/> discusses the
|
||||
networking deployment options for both
|
||||
legacy nova-network options and an equivalent neutron configuration:
|
||||
</para>
|
||||
<informaltable rules="all" width="729">
|
||||
<table rules="all" width="729" xml:id="network_deployment_options">
|
||||
<caption>Networking Deployment Options</caption>
|
||||
<col width="17%"/>
|
||||
<col width="22%"/>
|
||||
<col width="23%"/>
|
||||
|
|
@ -236,7 +238,7 @@
|
|||
<para>VlanManager</para>
|
||||
</td>
|
||||
<td>
|
||||
<para>Each tenant is isolated to their own VLANs.</para>
|
||||
<para>Each tenant is isolated to its own VLANs.</para>
|
||||
</td>
|
||||
<td>
|
||||
<para>More complex to set up.</para>
|
||||
|
|
@ -251,7 +253,7 @@
|
|||
VLAN tagging is key concept, where traffic is
|
||||
“tagged” with an ordinal identifier for the VLAN.
|
||||
Isolated network implementations may or may not
|
||||
include additional services like DHCP, NAT and
|
||||
include additional services like DHCP, NAT, and
|
||||
routing.</para>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -277,17 +279,17 @@
|
|||
<td>
|
||||
<para>Configure neutron with multiple DHCP and layer 3
|
||||
agents. Network nodes are not able to failover to
|
||||
each other so the Controller runs Networking
|
||||
each other, so the controller runs networking
|
||||
services such as DHCP. Compute nodes run the
|
||||
ML2 plugin with support for agents like Open vSwitch
|
||||
or Linux Bridge.</para>
|
||||
ML2 plug-in with support for agents such as
|
||||
Open vSwitch or Linux Bridge.</para>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
</table>
|
||||
<para>Both nova-network and neutron services provide similar capabilities,
|
||||
such as VLAN between VMs. You also can provide multiple NICs (Network
|
||||
Interface Cards) on VMs with either service. Further discussion
|
||||
such as VLAN between VMs. You also can provide multiple NICs
|
||||
on VMs with either service. Further discussion
|
||||
follows.</para>
|
||||
<section xml:id="vlans">
|
||||
<title>VLAN Configuration within OpenStack VMs</title>
|
||||
|
|
@ -299,10 +301,10 @@
|
|||
a VLAN range (one for each project) and turn each
|
||||
compute node switch port into a trunk port.</para>
|
||||
<para>For example, if you estimate that your cloud must
|
||||
support a max of 100 projects, pick a free VLAN range
|
||||
support a maximum of 100 projects, pick a free VLAN range
|
||||
that your network infrastructure is currently not
|
||||
using (such as, VLAN 200 - 299). You must configure
|
||||
OpenStack with this range as well as configure your
|
||||
using (such as VLAN 200–299). You must configure
|
||||
OpenStack with this range and also configure your
|
||||
switch ports to allow VLAN traffic from that
|
||||
range.</para>
|
||||
</section>
|
||||
|
|
@ -318,20 +320,20 @@
|
|||
total number of supported projects by one.</para>
|
||||
</section>
|
||||
<section xml:id="multi_host_single_host_networks">
|
||||
<title>Multi-host and Single-host Networking</title>
|
||||
<title>Multi-Host and Single-Host Networking</title>
|
||||
<para>The nova-network service has the ability to operate
|
||||
in a multi-host or single-host mode. Multi-host is
|
||||
when each compute node runs a copy of nova-network and
|
||||
the instances on that compute node use the compute
|
||||
node as a gateway to the Internet. The compute nodes
|
||||
also host the Floating IPs and Security Groups for
|
||||
also host the floating IPs and security groups for
|
||||
instances on that node. Single-host is when a central
|
||||
server, for example, the cloud controller, runs the
|
||||
server—for example, the cloud controller—runs the
|
||||
<code>nova-network</code> service. All compute
|
||||
nodes forward traffic from the instances to the cloud
|
||||
controller. The cloud controller then forwards traffic
|
||||
to the Internet. The cloud controller hosts the
|
||||
Floating IPs and Security Groups for all instances on
|
||||
floating IPs and security groups for all instances on
|
||||
all compute nodes in the cloud.</para>
|
||||
<para>There are benefits to both modes. Single-node has
|
||||
the downside of a single point of failure. If the
|
||||
|
|
@ -351,7 +353,7 @@
|
|||
DNS.</para>
|
||||
<section xml:id="ntp">
|
||||
<title>NTP</title>
|
||||
<para>Time synchronisation is a critical element to ensure
|
||||
<para>Time synchronization is a critical element to ensure
|
||||
continued operation of OpenStack components. Correct
|
||||
time is necessary to avoid errors in instance
|
||||
scheduling, replication of objects in the object
|
||||
|
|
@ -359,7 +361,7 @@
|
|||
debugging.</para>
|
||||
<para>All servers running OpenStack components should be
|
||||
able to access an appropriate NTP server. You may
|
||||
decide to set one up locally, or use the public pools
|
||||
decide to set up one locally or use the public pools
|
||||
available from the <link xlink:href="http://www.pool.ntp.org">
|
||||
Network Time Protocol project</link>
|
||||
(http://www.pool.ntp.org/)</para>
|
||||
|
|
@ -367,20 +369,20 @@
|
|||
<section xml:id="dns">
|
||||
<title>DNS</title>
|
||||
<para>OpenStack does not currently provide DNS
|
||||
services, aside from the dnsmasq daemon which
|
||||
services, aside from the dnsmasq daemon, which
|
||||
resides on <code>nova-network</code> hosts. You
|
||||
could consider providing a dynamic DNS service to
|
||||
allow instances to update a DNS entry with new IP
|
||||
addresses. You can also consider making a generic
|
||||
forward and reverse DNS mapping for instance's IP
|
||||
forward and reverse DNS mapping for instances' IP
|
||||
addresses, such as
|
||||
vm-203-0-113-123.example.com.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="ops-network-conclusion">
|
||||
<title>Conclusion</title>
|
||||
<para>Armed with your IP address layout and numbers, knowledge
|
||||
about topologies and services you can use, it's now time to prepare
|
||||
<para>Armed with your IP address layout and numbers and knowledge
|
||||
about the topologies and services you can use, it's now time to prepare
|
||||
the network for your installation. Be sure to also check out
|
||||
the <citetitle>OpenStack Security Guide</citetitle> for tips on
|
||||
securing your network. We wish you a good
|
||||
|
|
|
|||
Loading…
Reference in New Issue