Merge "[arch-guide] Convert network focus chapter to RST part 2"

doc/arch-design-rst/source/network-focus-architecture.rst

@@ -0,0 +1,184 @@
+Architecture
+~~~~~~~~~~~~
+
+Network-focused OpenStack architectures have many similarities to other
+OpenStack architecture use cases. There are several factors to consider
+when designing for a network-centric or network-heavy application
+environment.
+
+Networks exist to serve as a medium of transporting data between
+systems. It is inevitable that an OpenStack design has
+inter-dependencies with non-network portions of OpenStack as well as on
+external systems. Depending on the specific workload, there may be major
+interactions with storage systems both within and external to the
+OpenStack environment. For example, in the case of content delivery
+network, there is twofold interaction with storage. Traffic flows to and
+from the storage array for ingesting and serving content in a
+north-south direction. In addition, there is replication traffic flowing
+in an east-west direction.
+
+Compute-heavy workloads may also induce interactions with the network.
+Some high performance compute applications require network-based memory
+mapping and data sharing and, as a result, induce a higher network load
+when they transfer results and data sets. Others may be highly
+transactional and issue transaction locks, perform their functions, and
+revoke transaction locks at high rates. This also has an impact on the
+network performance.
+
+Some network dependencies are external to OpenStack. While OpenStack
+Networking is capable of providing network ports, IP addresses, some
+level of routing, and overlay networks, there are some other functions
+that it cannot provide. For many of these, you may require external
+systems or equipment to fill in the functional gaps. Hardware load
+balancers are an example of equipment that may be necessary to
+distribute workloads or offload certain functions. OpenStack Networking
+provides a tunneling feature, however it is constrained to a
+Networking-managed region. If the need arises to extend a tunnel beyond
+the OpenStack region to either another region or an external system,
+implement the tunnel itself outside OpenStack or use a tunnel management
+system to map the tunnel or overlay to an external tunnel.
+
+Depending on the selected design, Networking itself might not support
+the required :term:`layer-3 network<Layer-3 network>` functionality. If
+you choose to use the provider networking mode without running the layer-3
+agent, you must install an external router to provide layer-3 connectivity
+to outside systems.
+
+Interaction with orchestration services is inevitable in larger-scale
+deployments. The Orchestration service is capable of allocating network
+resource defined in templates to map to tenant networks and for port
+creation, as well as allocating floating IPs. If there is a requirement
+to define and manage network resources when using orchestration, we
+recommend that the design include the Orchestration service to meet the
+demands of users.
+
+Design impacts
+--------------
+
+A wide variety of factors can affect a network-focused OpenStack
+architecture. While there are some considerations shared with a general
+use case, specific workloads related to network requirements influence
+network design decisions.
+
+One decision includes whether or not to use Network Address Translation
+(NAT) and where to implement it. If there is a requirement for floating
+IPs instead of public fixed addresses then you must use NAT. An example
+of this is a DHCP relay that must know the IP of the DHCP server. In
+these cases it is easier to automate the infrastructure to apply the
+target IP to a new instance rather than to reconfigure legacy or
+external systems for each new instance.
+
+NAT for floating IPs managed by Networking resides within the hypervisor
+but there are also versions of NAT that may be running elsewhere. If
+there is a shortage of IPv4 addresses there are two common methods to
+mitigate this externally to OpenStack. The first is to run a load
+balancer either within OpenStack as an instance, or use an external load
+balancing solution. In the internal scenario, Networking's
+Load-Balancer-as-a-Service (LBaaS) can manage load balancing software,
+for example HAproxy. This is specifically to manage the Virtual IP (VIP)
+while a dual-homed connection from the HAproxy instance connects the
+public network with the tenant private network that hosts all of the
+content servers. In the external scenario, a load balancer needs to
+serve the VIP and also connect to the tenant overlay network through
+external means or through private addresses.
+
+Another kind of NAT that may be useful is protocol NAT. In some cases it
+may be desirable to use only IPv6 addresses on instances and operate
+either an instance or an external service to provide a NAT-based
+transition technology such as NAT64 and DNS64. This provides the ability
+to have a globally routable IPv6 address while only consuming IPv4
+addresses as necessary or in a shared manner.
+
+Application workloads affect the design of the underlying network
+architecture. If a workload requires network-level redundancy, the
+routing and switching architecture have to accommodate this. There are
+differing methods for providing this that are dependent on the selected
+network hardware, the performance of the hardware, and which networking
+model you deploy. Examples include Link aggregation (LAG) and Hot
+Standby Router Protocol (HSRP). Also consider whether to deploy
+OpenStack Networking or legacy networking (nova-network), and which
+plug-in to select for OpenStack Networking. If using an external system,
+configure Networking to run :term:`layer-2<Layer-2 network>` with a provider
+network configuration. For example, implement HSRP to terminate layer-3
+connectivity.
+
+Depending on the workload, overlay networks may not be the best
+solution. Where application network connections are small, short lived,
+or bursty, running a dynamic overlay can generate as much bandwidth as
+the packets it carries. It also can induce enough latency to cause
+issues with certain applications. There is an impact to the device
+generating the overlay which, in most installations, is the hypervisor.
+This causes performance degradation on packet per second and connection
+per second rates.
+
+Overlays also come with a secondary option that may not be appropriate
+to a specific workload. While all of them operate in full mesh by
+default, there might be good reasons to disable this function because it
+may cause excessive overhead for some workloads. Conversely, other
+workloads operate without issue. For example, most web services
+applications do not have major issues with a full mesh overlay network,
+while some network monitoring tools or storage replication workloads
+have performance issues with throughput or excessive broadcast traffic.
+
+Many people overlook an important design decision: The choice of layer-3
+protocols. While OpenStack was initially built with only IPv4 support,
+Networking now supports IPv6 and dual-stacked networks. Some workloads
+are possible through the use of IPv6 and IPv6 to IPv4 reverse transition
+mechanisms such as NAT64 and DNS64 or :term:`6to4`. This alters the
+requirements for any address plan as single-stacked and transitional IPv6
+deployments can alleviate the need for IPv4 addresses.
+
+OpenStack has limited support for dynamic routing, however there are a
+number of options available by incorporating third party solutions to
+implement routing within the cloud including network equipment, hardware
+nodes, and instances. Some workloads perform well with nothing more than
+static routes and default gateways configured at the layer-3 termination
+point. In most cases this is sufficient, however some cases require the
+addition of at least one type of dynamic routing protocol if not
+multiple protocols. Having a form of interior gateway protocol (IGP)
+available to the instances inside an OpenStack installation opens up the
+possibility of use cases for anycast route injection for services that
+need to use it as a geographic location or failover mechanism. Other
+applications may wish to directly participate in a routing protocol,
+either as a passive observer, as in the case of a looking glass, or as
+an active participant in the form of a route reflector. Since an
+instance might have a large amount of compute and memory resources, it
+is trivial to hold an entire unpartitioned routing table and use it to
+provide services such as network path visibility to other applications
+or as a monitoring tool.
+
+Path maximum transmission unit (MTU) failures are lesser known but
+harder to diagnose. The MTU must be large enough to handle normal
+traffic, overhead from an overlay network, and the desired layer-3
+protocol. Adding externally built tunnels reduces the MTU packet size.
+In this case, you must pay attention to the fully calculated MTU size
+because some systems ignore or drop path MTU discovery packets.
+
+Tunable networking components
+-----------------------------
+
+Consider configurable networking components related to an OpenStack
+architecture design when designing for network intensive workloads that
+include MTU and QoS. Some workloads require a larger MTU than normal due
+to the transfer of large blocks of data. When providing network service
+for applications such as video streaming or storage replication, we
+recommend that you configure both OpenStack hardware nodes and the
+supporting network equipment for jumbo frames where possible. This
+allows for better use of available bandwidth. Configure jumbo frames
+across the complete path the packets traverse. If one network component
+is not capable of handling jumbo frames then the entire path reverts to
+the default MTU.
+
+Quality of Service (QoS) also has a great impact on network intensive
+workloads as it provides instant service to packets which have a higher
+priority due to the impact of poor network performance. In applications
+such as Voice over IP (VoIP), differentiated services code points are a
+near requirement for proper operation. You can also use QoS in the
+opposite direction for mixed workloads to prevent low priority but high
+bandwidth applications, for example backup services, video conferencing,
+or file sharing, from blocking bandwidth that is needed for the proper
+operation of other workloads. It is possible to tag file storage traffic
+as a lower class, such as best effort or scavenger, to allow the higher
+priority traffic through. In cases where regions within a cloud might be
+geographically distributed it may also be necessary to plan accordingly
+to implement WAN optimization to combat latency or packet loss.

doc/arch-design-rst/source/network-focus-operational-considerations.rst

@@ -0,0 +1,64 @@
+Operational considerations
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Network-focused OpenStack clouds have a number of operational
+considerations that influence the selected design, including:
+
+*  Dynamic routing of static routes
+
+*  Service level agreements (SLAs)
+
+*  Ownership of user management
+
+An initial network consideration is the selection of a telecom company
+or transit provider.
+
+Make additional design decisions about monitoring and alarming. This can
+be an internal responsibility or the responsibility of the external
+provider. In the case of using an external provider, service level
+agreements (SLAs) likely apply. In addition, other operational
+considerations such as bandwidth, latency, and jitter can be part of an
+SLA.
+
+Consider the ability to upgrade the infrastructure. As demand for
+network resources increase, operators add additional IP address blocks
+and add additional bandwidth capacity. In addition, consider managing
+hardware and software life cycle events, for example upgrades,
+decommissioning, and outages, while avoiding service interruptions for
+tenants.
+
+Factor maintainability into the overall network design. This includes
+the ability to manage and maintain IP addresses as well as the use of
+overlay identifiers including VLAN tag IDs, GRE tunnel IDs, and MPLS
+tags. As an example, if you may need to change all of the IP addresses
+on a network, a process known as renumbering, then the design must
+support this function.
+
+Address network-focused applications when considering certain
+operational realities. For example, consider the impending exhaustion of
+IPv4 addresses, the migration to IPv6, and the use of private networks
+to segregate different types of traffic that an application receives or
+generates. In the case of IPv4 to IPv6 migrations, applications should
+follow best practices for storing IP addresses. We recommend you avoid
+relying on IPv4 features that did not carry over to the IPv6 protocol or
+have differences in implementation.
+
+To segregate traffic, allow applications to create a private tenant
+network for database and storage network traffic. Use a public network
+for services that require direct client access from the internet. Upon
+segregating the traffic, consider quality of service (QoS) and security
+to ensure each network has the required level of service.
+
+Finally, consider the routing of network traffic. For some applications,
+develop a complex policy framework for routing. To create a routing
+policy that satisfies business requirements, consider the economic cost
+of transmitting traffic over expensive links versus cheaper links, in
+addition to bandwidth, latency, and jitter requirements.
+
+Additionally, consider how to respond to network events. As an example,
+how load transfers from one link to another during a failure scenario
+could be a factor in the design. If you do not plan network capacity
+correctly, failover traffic could overwhelm other ports or network links
+and create a cascading failure scenario. In this case, traffic that
+fails over to one link overwhelms that link and then moves to the
+subsequent links until all network traffic stops.

doc/arch-design-rst/source/network-focus-prescriptive-examples.rst

@@ -0,0 +1,165 @@
+Prescriptive examples
+~~~~~~~~~~~~~~~~~~~~~
+
+An organization design a large-scale web application with cloud
+principles in mind. The application scales horizontally in a bursting
+fashion and generates a high instance count. The application requires an
+SSL connection to secure data and must not lose connection state to
+individual servers.
+
+The figure below depicts an example design for this workload. In this
+example, a hardware load balancer provides SSL offload functionality and
+connects to tenant networks in order to reduce address consumption. This
+load balancer links to the routing architecture as it services the VIP
+for the application. The router and load balancer use the GRE tunnel ID
+of the application's tenant network and an IP address within the tenant
+subnet but outside of the address pool. This is to ensure that the load
+balancer can communicate with the application's HTTP servers without
+requiring the consumption of a public IP address.
+
+Because sessions persist until closed, the routing and switching
+architecture provides high availability. Switches mesh to each
+hypervisor and each other, and also provide an MLAG implementation to
+ensure that layer-2 connectivity does not fail. Routers use VRRP and
+fully mesh with switches to ensure layer-3 connectivity. Since GRE is
+provides an overlay network, Networking is present and uses the Open
+vSwitch agent in GRE tunnel mode. This ensures all devices can reach all
+other devices and that you can create tenant networks for private
+addressing links to the load balancer.
+
+.. figure:: /figures/Network_Web_Services1.png
+
+A web service architecture has many options and optional components. Due
+to this, it can fit into a large number of other OpenStack designs. A
+few key components, however, need to be in place to handle the nature of
+most web-scale workloads. You require the following components:
+
+*  OpenStack Controller services (Image, Identity, Networking and
+   supporting services such as MariaDB and RabbitMQ)
+
+*  OpenStack Compute running KVM hypervisor
+
+*  OpenStack Object Storage
+
+*  Orchestration service
+
+*  Telemetry service
+
+Beyond the normal Identity, Compute, Image service, and Object Storage
+components, we recommend the Orchestration service component to handle
+the proper scaling of workloads to adjust to demand. Due to the
+requirement for auto-scaling, the design includes the Telemetry service.
+Web services tend to be bursty in load, have very defined peak and
+valley usage patterns and, as a result, benefit from automatic scaling
+of instances based upon traffic. At a network level, a split network
+configuration works well with databases residing on private tenant
+networks since these do not emit a large quantity of broadcast traffic
+and may need to interconnect to some databases for content.
+
+Load balancing
+--------------
+
+Load balancing spreads requests across multiple instances. This workload
+scales well horizontally across large numbers of instances. This enables
+instances to run without publicly routed IP addresses and instead to
+rely on the load balancer to provide a globally reachable service. Many
+of these services do not require direct server return. This aids in
+address planning and utilization at scale since only the virtual IP
+(VIP) must be public.
+
+Overlay networks
+----------------
+
+The overlay functionality design includes OpenStack Networking in Open
+vSwitch GRE tunnel mode. In this case, the layer-3 external routers pair
+with VRRP, and switches pair with an implementation of MLAG to ensure
+that you do not lose connectivity with the upstream routing
+infrastructure.
+
+Performance tuning
+------------------
+
+Network level tuning for this workload is minimal. Quality-of-Service
+(QoS) applies to these workloads for a middle ground Class Selector
+depending on existing policies. It is higher than a best effort queue
+but lower than an Expedited Forwarding or Assured Forwarding queue.
+Since this type of application generates larger packets with
+longer-lived connections, you can optimize bandwidth utilization for
+long duration TCP. Normal bandwidth planning applies here with regards
+to benchmarking a session's usage multiplied by the expected number of
+concurrent sessions with overhead.
+
+Network functions
+-----------------
+
+Network functions is a broad category but encompasses workloads that
+support the rest of a system's network. These workloads tend to consist
+of large amounts of small packets that are very short lived, such as DNS
+queries or SNMP traps. These messages need to arrive quickly and do not
+deal with packet loss as there can be a very large volume of them. There
+are a few extra considerations to take into account for this type of
+workload and this can change a configuration all the way to the
+hypervisor level. For an application that generates 10 TCP sessions per
+user with an average bandwidth of 512 kilobytes per second per flow and
+expected user count of ten thousand concurrent users, the expected
+bandwidth plan is approximately 4.88 gigabits per second.
+
+The supporting network for this type of configuration needs to have a
+low latency and evenly distributed availability. This workload benefits
+from having services local to the consumers of the service. Use a
+multi-site approach as well as deploying many copies of the application
+to handle load as close as possible to consumers. Since these
+applications function independently, they do not warrant running
+overlays to interconnect tenant networks. Overlays also have the
+drawback of performing poorly with rapid flow setup and may incur too
+much overhead with large quantities of small packets and therefore we do
+not recommend them.
+
+QoS is desirable for some workloads to ensure delivery. DNS has a major
+impact on the load times of other services and needs to be reliable and
+provide rapid responses. Configure rules in upstream devices to apply a
+higher Class Selector to DNS to ensure faster delivery or a better spot
+in queuing algorithms.
+
+Cloud storage
+-------------
+
+Another common use case for OpenStack environments is providing a
+cloud-based file storage and sharing service. You might consider this a
+storage-focused use case, but its network-side requirements make it a
+network-focused use case.
+
+For example, consider a cloud backup application. This workload has two
+specific behaviors that impact the network. Because this workload is an
+externally-facing service and an internally-replicating application, it
+has both :term:`north-south<north-south traffic>` and
+:term:`east-west<east-west traffic>` traffic considerations:
+
+north-south traffic
+ When a user uploads and stores content, that content moves into the
+ OpenStack installation. When users download this content, the
+ content moves out from the OpenStack installation. Because this
+ service operates primarily as a backup, most of the traffic moves
+ southbound into the environment. In this situation, it benefits you
+ to configure a network to be asymmetrically downstream because the
+ traffic that enters the OpenStack installation is greater than the
+ traffic that leaves the installation.
+
+east-west traffic
+ Likely to be fully symmetric. Because replication originates from
+ any node and might target multiple other nodes algorithmically, it
+ is less likely for this traffic to have a larger volume in any
+ specific direction. However this traffic might interfere with
+ north-south traffic.
+
+.. figure:: /figures/Network_Cloud_Storage2.png
+
+This application prioritizes the north-south traffic over east-west
+traffic: the north-south traffic involves customer-facing data.
+
+The network design in this case is less dependent on availability and
+more dependent on being able to handle high bandwidth. As a direct
+result, it is beneficial to forgo redundant links in favor of bonding
+those connections. This increases available bandwidth. It is also
+beneficial to configure all devices in the path, including OpenStack, to
+generate and pass jumbo frames.

doc/arch-design-rst/source/network-focus.rst

@@ -7,6 +7,9 @@ Network focused
 
    network-focus-user-requirements.rst
    network-focus-technical-considerations.rst
+   network-focus-operational-considerations.rst
+   network-focus-architecture.rst
+   network-focus-prescriptive-examples.rst
 
 All OpenStack deployments depend on network communication in order to function
 properly due to its service-based nature. In some cases, however, the network