Ultra M’s VIM is based on the OpenStack project TripleO (“OpenStack-On-OpenStack") which is the core of the OpenStack Platform Director (OSP-D). TripleO allows OpenStack components to install a fully operational OpenStack environment.

Two cloud concepts are introduced through TripleO:

• VIM Orchestrator (Undercloud): The VIM Orchestrator is used to bring up and manage the VIM. Though OSP-D and Undercloud are sometimes referred to synonymously, the OSP-D bootstraps the Undercloud deployment and provides the underlying components (e.g. Ironic, Nova, Glance, Neutron, etc.) leveraged by the Undercloud to deploy the VIM. Within the Ultra M Solution, OSP-D and the Undercloud are hosted on the same server.

• VIM (Overcloud): The VIM consists of the compute, controller, and storage nodes on which the VNFs are deployed.

Some considerations for VIM Orchestrator and VIM deployment are as follows:

• External network access (e.g. Internet access) can be configured in one of the following ways:

  • Across all node types: A single subnet is configured on the Controller HA, VIP address, floating IP addresses and OSP-D/Staging server’s external interface provided that this network is data-center routable as well as it is able to reach the internet.

  • Limited to OSP-D: The External IP network is used by Controllers for HA and Horizon dashboard as well as later on for Tenant Floating IP address requirements. This network must be data-center routable. In addition, the External IP network is used only by OSP-D/Staging Server node’s external interface that has a single IP address. The External IP network must be lab/data-center routable must also have internet access to Red Hat cloud. It is used by OSP-D/Staging Server for subscription purposes and also acts as an external gateway for all controllers, computes and Ceph-storage nodes.

• IPMI must be enabled on all nodes.

• Two networks are needed to deploy the VIM Orchestrator:

  • IPMI/CIMC Network

  • Provisioning Network

• The OSP-D/Staging Server must have reachability to both IPMI/CIMC and Provisioning Networks. (VIM Orchestrator networks need to be routable between each other or have to be in one subnet.)

• DHCP-based IP address assignment for Introspection PXE from Provisioning Network (Range A)

• DHCP based IP address assignment for VIM PXE from Provisioning Network (Range B) must be separate from Introspection.

• The Ultra M Manager Node/Staging Server acts as a gateway for Controller, Ceph and Computes. Therefore, the external interface of this node/server needs to be able to access the Internet. In addition, this interface needs to be routable with the Data-center network. This allows the External interface IP-address of the Ultra M Manager Node/Staging Server to reach Data-center routable Floating IP addresses as well as the VIP addresses of Controllers in HA Mode.

• Prior to assigning floating and virtual IP addresses, make sure that they are not already allocated through OpenStack. If the addresses are already allocated, then they must be freed up for use or you must assign a new IP address that is available in the VIM.

• Multiple VLANs are required in order to deploy OpenStack VIM:

  • 1 for the Management and Provisioning networks interconnecting all the nodes regardless of type

  • 1 for the Staging Server/OSP-D Node external network

  • 1 for Compute, Controller, and Ceph Storage or OSD Compute Nodes

  • 1 for Management network interconnecting the Leafs and Spines

• Login to individual Compute nodes will be from OSP-D/Staging Server using heat user login credentials.

  The OSP-D/Staging Server acts as a “jump server” where the br-ctlplane interface address is used to login to the Controller, Ceph or OSD Computes, and Computes post VIM deployment using heat-admin credentials.

Layer 1 networking guidelines for the VIM network are provided in Layer 1 Leaf and Spine Topology. In addition, a template is provided in Network Definitions (Layer 2 and 3) to assist you with your Layer 2 and Layer 3 network planning.

The interfaces used by the VNF are based on the PCIe architecture. Single root input/output virtualization (SR-IOV) is used on these interfaces to allow multiple VMs on a single server node to use the same network interface as shown in Figure 1. SR-IOV Networking is network type Flat under OpenStack configuration. NIC Bonding is used to ensure port level redundancy for PCIe Cards involved in SR-IOV Tenant Networks as shown in Figure 2.

While specific VNF network requirements are described in the documentation corresponding to the VNF, Figure 1 displays the types of networks typically required by USP-based VNFs.

In this release, a cluster of UEM supports multiple VNF instances deployed in different tenants in a single “site” leveraging a single VIM.

The USP-based VNF networking requirements and the specific roles are described here:

• Public: External public network. The router has an external gateway to the public network. All other networks (except DI-Internal and ServiceA-n) have an internal gateway pointing to the router. And the router performs secure network address translation (SNAT).

• DI-Internal: This is the DI-internal network which serves as a ‘backplane’ for CF-SF and CF-CF communications. Since this network is internal to the UGP, it does not have a gateway interface to the router in the OpenStack network topology. A unique DI internal network must be created for each instance of the UGP. The interfaces attached to these networks use performance optimizations.

• Management: This is the local management network between the CFs and other management elements like the UEM and VNFM. This network is also used by OSP-D to deploy the VNFM and AutoVNF. To allow external access, an OpenStack floating IP address from the Public network must be associated with the UGP VIP (CF) address.

  You can ensure that the same floating IP address can assigned to the CF, UEM, and VNFM after a VM restart by configuring parameters in the AutoDeploy configuration file or the UWS service delivery configuration file.

  Note	Prior to assigning floating and virtual IP addresses, make sure that they are not already allocated through OpenStack. If the addresses are already allocated, then they must be freed up for use or you must assign a new IP address that is available in the VIM.

• Orchestration: This is the network used for VNF deployment and monitoring. It is used by the VNFM to onboard the USP-based VNF.

• ServiceA-n: These are the service interfaces to the SF. Up to 12 service interfaces can be provisioned for the SF with this release. The interfaces attached to these networks use performance optimizations.

  Layer 1 networking guidelines for the VNF network are provided in Layer 1 Leaf and Spine Topology. In addition, a template is provided in Network Definitions (Layer 2 and 3) to assist you with your Layer 2 and Layer 3 network planning.

Ultra M implements a Leaf and Spine network topology. Topology details differ between Ultra M models based on the scale and number of nodes.

Note	When connecting component network ports, ensure that the destination ports are rated at the same speed as the source port (e.g. connect a 10G port to a 10G port). Additionally, the source and destination ports must support the same physical medium (e.g. Ethernet) for interconnectivity.