diff --git a/doc/openstack-ops/ch_arch_network_design.xml b/doc/openstack-ops/ch_arch_network_design.xml index de7a9802..f1693201 100644 --- a/doc/openstack-ops/ch_arch_network_design.xml +++ b/doc/openstack-ops/ch_arch_network_design.xml @@ -17,10 +17,10 @@ chapter details the requirements and options to deliberate when designing your cloud. 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. 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. - In this chapter we'll give some examples of network implementations to - consider, and provide some information about some of the network layouts + 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.
Management Network A management network (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. + segregation prevents system administration and the monitoring + of system access from being disrupted by traffic generated by + guests. 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. @@ -52,22 +52,22 @@
Public Addressing Options 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. 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. 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.
@@ -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. An IP address plan might be broken down into the following sections: @@ -97,15 +97,15 @@ Public access to swift-proxy, nova-api, - glance-api and horizon + glance-api, 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. Object Storage cluster internal communications - Traffic amongst object/account/container + Traffic among object/account/container servers and between these and the proxy server's internal interface uses this private network. @@ -126,7 +126,7 @@ in-band remote management - Often, an extra (such as, 1 GB) + 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 @@ spare space for future growth Adding more public-facing control - services, or guest instance IPs should + services or guest instance IPs should always be part of your plan. - For example, take a deployment which has both OpenStack + 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: - 172.22.42.0/24 + segregate the space might be as follows: + 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 @@
Network Topology 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. - This table discusses the networking deployment options for both + discusses the + networking deployment options for both legacy nova-network options and an equivalent neutron configuration: - + + @@ -236,7 +238,7 @@ VlanManager @@ -277,17 +279,17 @@ - +
Networking Deployment Options
- Each tenant is isolated to their own VLANs. + Each tenant is isolated to its own VLANs. More complex to set up. @@ -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.
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. + ML2 plug-in with support for agents such as + Open vSwitch or Linux Bridge.
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.
VLAN Configuration within OpenStack VMs @@ -299,10 +301,10 @@ a VLAN range (one for each project) and turn each compute node switch port into a trunk port. 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.
@@ -318,20 +320,20 @@ total number of supported projects by one.
- Multi-host and Single-host Networking + Multi-Host and Single-Host Networking 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 nova-network 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. There are benefits to both modes. Single-node has the downside of a single point of failure. If the @@ -351,7 +353,7 @@ DNS.
NTP - Time synchronisation is a critical element to ensure + 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. 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 Network Time Protocol project (http://www.pool.ntp.org/) @@ -367,20 +369,20 @@
DNS OpenStack does not currently provide DNS - services, aside from the dnsmasq daemon which + services, aside from the dnsmasq daemon, which resides on nova-network 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.
Conclusion - Armed with your IP address layout and numbers, knowledge - about topologies and services you can use, it's now time to prepare + 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 OpenStack Security Guide for tips on securing your network. We wish you a good