To register your system, provide the E-mail address associated with the SUSE account you or your organization uses to manage subscriptions. In case you do not have a SUSE account yet, go to the SUSE Customer Center home page (https://scc.suse.com/) to create one.

Enter the Registration Code you received with your copy of SUSE Linux Enterprise Server. Proceed with Next to start the registration process.

By default the system is registered with the SUSE Customer Center. However, if your organization provides local registration servers you can either choose one from the list of auto-detected servers or provide the URL at Register System via local SMT Server. Proceed with Next.

During the registration, the online update repositories will be added to your installation setup. When finished, you can choose whether to install the latest available package versions from the update repositories. This ensures that SUSE Linux Enterprise Server is installed with the latest security updates available. If you choose No, all packages will be installed from the installation media. Proceed with Next.

If the system was successfully registered during installation, YaST will disable repositories from local installation media such as CD/DVD or flash disks when the installation has been completed. This prevents problems if the installation source is no longer available and ensures that you always get the latest updates from the online repositories.

If you deploy your instances automatically using AutoYaST, you can register the system during the installation by providing the respective information in the AutoYaST control file. Refer to https://documentation.suse.com/sles/15-SP1/single-html/SLES-autoyast/#CreateProfile-Register for details.

SUSE OpenStack Cloud 9 services have been updated to the OpenStack Rocky release.

SUSE OpenStack Cloud 9 supports hardware that is certified for SLES through the YES certification program. You will find a database of certified hardware at https://www.suse.com/yessearch/.

nova

neutron

glance Supported Features

cinder

swift

keystone

barbican Supported Features

ceilometer

heat Features Not Supported

ironic

The table below shows supported node configurations. UEFI secure is not supported.

SUSE OpenStack Cloud 9 has been tested and qualified with a total of 200 total compute nodes in a single region (Region0).

SUSE OpenStack Cloud 9 has been tested and qualified with a total of 12,000 virtual machines across a total of 200 compute nodes.

Larger configurations are possible, but SUSE has tested and qualified this configuration size. Typically larger configurations are enabled with services and engineering engagements.

Supported ESXi versions

SUSE OpenStack Cloud 9 currently supports the following ESXi versions:

The following are the requirements for your vCenter server:

We have the following recommendations to ensure good performance of your cloud environment:

For a list of the supported VM guests, see https://documentation.suse.com/sles/15-SP1/single-html/SLES-virtualization/#virt-support-guests

For ESX, refer to the VMware Compatibility Guide. The information for SUSE OpenStack Cloud is below the search form.

A Verified Guest OS has been tested by SUSE and appears to function properly as a bare metal instance on SUSE OpenStack Cloud 9.

A Certified Guest OS has been officially tested by the operating system vendor, or by SUSE under the vendor's authorized program, and will be supported by the operating system vendor as a bare metal instance on SUSE OpenStack Cloud 9.

These recommended minimums are based on example configurations included with the installation models (see Chapter 9, Example Configurations). They are suitable only for demo environments. For production systems you will want to consider your capacity and performance requirements when making decisions about your hardware.

Note

The disk requirements detailed below can be met with logical drives, logical volumes, or external storage such as a 3PAR array.

For more details about the supported network requirements, see Chapter 9, Example Configurations.

These recommended minimums are based on example configurations included with the installation models (see Chapter 9, Example Configurations). They are suitable only for demo environments. For production systems you will want to consider your capacity and performance requirements when making decisions about your hardware.

SUSE OpenStack Cloud currently supports the following ESXi versions:

The following are the requirements for your vCenter server:

These recommended minimums are based on example configurations included with the installation models (see Chapter 9, Example Configurations). They are suitable only for demo environments. For production systems you will want to consider your capacity and performance requirements when making decisions about your hardware.

SUSE OpenStack Cloud currently supports the following ESXi versions:

The following are the requirements for your vCenter server:

When using the agent_ilo driver, you should ensure that the most recent iLO controller firmware is installed. A recommended minimum for the iLO4 controller is version 2.30.

The recommended minimum hardware requirements are based on the Chapter 9, Example Configurations included with the base installation and are suitable only for demo environments. For production systems you will want to consider your capacity and performance requirements when making decisions about your hardware.

For more details about the supported network requirements, see Chapter 9, Example Configurations.

These recommended minimums are based on the included Chapter 9, Example Configurations included with the base installation and are suitable only for demo environments. For production systems you will want to consider your capacity and performance requirements when making decisions about your hardware.

The entry-scale-swift example runs the swift proxy, account and container services on the three controller servers. However, it is possible to extend the model to include the swift proxy, account and container services on dedicated servers (typically referred to as the swift proxy servers). If you are using this model, we have included the recommended swift proxy servers specs in the table below.

Note

The disk speeds (RPM) chosen should be consistent within the same ring or storage policy. It is best to not use disks with mixed disk speeds within the same swift ring.

Considerations for your swift object and proxy, account, container servers RAM and disk capacity needs

swift can have a diverse number of hardware configurations. For example, a swift object server may have just a few disks (minimum of 6 for erasure codes) or up to 70 and beyond. The memory requirement needs to be increased as more disks are added. The general rule of thumb for memory needed is 0.5 GB per TB of storage. For example, a system with 24 hard drives at 8TB each, giving a total capacity of 192TB, should use 96GB of RAM. However, this does not work well for a system with a small number of small hard drives or a very large number of very large drives. So, if after calculating the memory given this guideline, if the answer is less than 32GB then go with 32GB of memory minimum and if the answer is over 256GB then use 256GB maximum, no need to use more memory than that.

When considering the capacity needs for the swift proxy, account, and container (PAC) servers, you should calculate 2% of the total raw storage size of your object servers to specify the storage required for the PAC servers. So, for example, if you were using the example we provided earlier and you had an object server setup of 24 hard drives with 8TB each for a total of 192TB and you had a total of 6 object servers, that would give a raw total of 1152TB. So you would take 2% of that, which is 23TB, and ensure that much storage capacity was available on your swift proxy, account, and container (PAC) server cluster. If you had a cluster of three swift PAC servers, that would be ~8TB each.

Another general rule of thumb is that if you are expecting to have more than a million objects in a container then you should consider using SSDs on the swift PAC servers rather than HDDs.

A highly available (HA) cloud ensures that a minimum level of cloud resources are always available on request, which results in uninterrupted operations for users.

In order to achieve this high availability of infrastructure and workloads, we define the scope of HA to be limited to protecting these only against single points of failure (SPOF). Single points of failure include:

By design, SUSE OpenStack Cloud strives to create a system architecture resilient to SPOFs, and does not attempt to automatically protect the system against multiple cascading levels of failures; such cascading failures will result in an unpredictable state. The cloud operator is encouraged to recover and restore any failed component as soon as the first level of failure occurs.

The highly available cloud infrastructure consists of the following:

The SUSE OpenStack Cloud installer deploys highly available configurations of OpenStack cloud services, resilient against single points of failure.

The high availability of the controller components comes in two main forms.

Figure 4.1: HA Architecture #

  

The above diagram illustrates the HA architecture with the focus on VIP management and load balancing. It only shows a subset of active-active API instances and does not show examples of other services such as nova-scheduler, cinder-scheduler, etc.

In the above diagram, requests from an OpenStack client to the API services are sent to VIP and port combination; for example, 192.0.2.26:8774 for a nova request. The load balancer listens for requests on that VIP and port. When it receives a request, it selects one of the controller nodes configured for handling nova requests, in this particular case, and then forwards the request to the IP of the selected controller node on the same port.

The nova-api service, which is listening for requests on the IP of its host machine, then receives the request and deals with it accordingly. The database service is also accessed through the load balancer. RabbitMQ, on the other hand, is not currently accessed through VIP/HA proxy as the clients are configured with the set of nodes in the RabbitMQ cluster and failover between cluster nodes is automatically handled by the clients.

Incorporating High Availability into a system involves implementing redundancies in the component that is being made highly available. In Centralized Virtual Router (CVR), that element is the Layer 3 agent (L3 agent). By making L3 agent highly available, upon failure all HA routers are migrated from the primary L3 agent to a secondary L3 agent. The implementation efficiency of an HA subsystem is measured by the number of packets that are lost when the secondary L3 agent is made the master.

In SUSE OpenStack Cloud, the primary and secondary L3 agents run continuously, and failover involves a rapid switchover of mastership to the secondary agent (IEFT RFC 5798). The failover essentially involves a switchover from an already running master to an already running slave. This substantially reduces the latency of the HA. The mechanism used by the master and the slave to implement a failover is implemented using Linux’s pacemaker HA resource manager. This CRM (Cluster resource manager) uses VRRP (Virtual Router Redundancy Protocol) to implement the HA mechanism. VRRP is a industry standard protocol and defined in RFC 5798.

Figure 4.2: Layer-3 HA #

  

L3 HA uses of VRRP comes with several benefits.

The primary benefit is that the failover mechanism does not involve interprocess communication overhead. Such overhead would be in the order of 10s of seconds. By not using an RPC mechanism to invoke the secondary agent to assume the primary agents role enables VRRP to achieve failover within 1-2 seconds.

In VRRP, the primary and secondary routers are all active. As the routers are running, it is a matter of making the router aware of its primary/master status. This switchover takes less than 2 seconds instead of 60+ seconds it would have taken to start a backup router and failover.

The failover depends upon a heartbeat link between the primary and secondary. That link in SUSE OpenStack Cloud uses keepalived package of the pacemaker resource manager. The heartbeats are sent at a 2 second intervals between the primary and secondary. As per the VRRP protocol, if the secondary does not hear from the master after 3 intervals, it assumes the function of the primary.

Further, all the routable IP addresses, that is the VIPs (virtual IPs) are assigned to the primary agent.

Figure 4.3: Availability Zones #

  

While planning your OpenStack deployment, you should decide on how to zone various types of nodes - such as compute, block storage, and object storage. For example, you may decide to place all servers in the same rack in the same zone. For larger deployments, you may plan more elaborate redundancy schemes for redundant power, network ISP connection, and even physical firewalling between zones (this aspect is outside the scope of this document).

SUSE OpenStack Cloud offers APIs, CLIs and horizon UIs for the administrator to define and user to consume, availability zones for nova, cinder and swift services. This section outlines the process to deploy specific types of nodes to specific physical servers, and makes a statement of available support for these types of availability zones in the current release.

Note

By default, SUSE OpenStack Cloud is deployed in a single availability zone upon installation. Multiple availability zones can be configured by an administrator post-install, if required. Refer to OpenStack Documentation

You can deploy your KVM nova-compute nodes either during initial installation or by adding compute nodes post initial installation.

While adding compute nodes post initial installation, you can specify the target physical servers for deploying the compute nodes.

Learn more about adding compute nodes in Book “Operations Guide CLM”, Chapter 15 “System Maintenance”, Section 15.1 “Planned System Maintenance”, Section 15.1.3 “Planned Compute Maintenance”, Section 15.1.3.4 “Adding Compute Node”.

nova host aggregates and nova availability zones can be used to segregate nova compute nodes across different failure zones.

Compute nodes deployed on ESX Hypervisor can be made highly available using the HA feature of VMware ESX Clusters. For more information on VMware HA, please refer to your VMware ESX documentation.

cinder availability zones are not supported for general consumption in the current release.

High availability in swift is achieved at two levels.

Control Plane

The swift API is served by multiple swift proxy nodes. Client requests are directed to all swift proxy nodes by the HA Proxy load balancer in round-robin fashion. The HA Proxy load balancer regularly checks the node is responding, so that if it fails, traffic is directed to the remaining nodes. The swift service will continue to operate and respond to client requests as long as at least one swift proxy server is running.

If a swift proxy node fails in the middle of a transaction, the transaction fails. However it is standard practice for swift clients to retry operations. This is transparent to applications that use the python-swiftclient library.

The entry-scale example cloud models contain three swift proxy nodes. However, it is possible to add additional clusters with additional swift proxy nodes to handle a larger workload or to provide additional resiliency.

Data

Multiple replicas of all data is stored. This happens for account, container and object data. The example cloud models recommend a replica count of three. However, you may change this to a higher value if needed.

When swift stores different replicas of the same item on disk, it ensures that as far as possible, each replica is stored in a different zone, server or drive. This means that if a single server of disk drives fails, there should be two copies of the item on other servers or disk drives.

If a disk drive is failed, swift will continue to store three replicas. The replicas that would normally be stored on the failed drive are “handed off” to another drive on the system. When the failed drive is replaced, the data on that drive is reconstructed by the replication process. The replication process re-creates the “missing” replicas by copying them to the drive using one of the other remaining replicas. While this is happening, swift can continue to store and retrieve data.

Projects writing applications to be deployed in the cloud must be aware of the cloud architecture and potential points of failure and architect their applications accordingly for high availability.

Some guidelines for consideration:

This document describes how SUSE OpenStack Cloud input models can be used to define and configure the cloud.

SUSE OpenStack Cloud ships with a set of example input models that can be used as starting points for defining a custom cloud. An input model allows you, the cloud administrator, to describe the cloud configuration in terms of:

The input model is consumed by the configuration processor which parses and validates the input model and outputs the effective configuration that will be deployed to each server that makes up your cloud.

The document is structured as follows:

An SUSE OpenStack Cloud 9 cloud is defined by a declarative model that is described in a series of configuration objects. These configuration objects are represented in YAML files which together constitute the various example configurations provided as templates with this release. These examples can be used nearly unchanged, with the exception of necessary changes to IP addresses and other site and hardware-specific identifiers. Alternatively, the examples may be customized to meet site requirements.

The following diagram shows the set of configuration objects and their relationships. All objects have a name that you may set to be something meaningful for your context. In the examples these names are provided in capital letters as a convention. These names have no significance to SUSE OpenStack Cloud, rather it is the relationships between them that define the configuration.

The configuration processor reads and validates the input model described in the YAML files discussed above, combines it with the service definitions provided by SUSE OpenStack Cloud and any persisted state information about the current deployment to produce a set of Ansible variables that can be used to deploy the cloud. It also produces a set of information files that provide details about the configuration.

The relationship between the file systems on the SUSE OpenStack Cloud deployment server and the configuration processor is shown in the following diagram. Below the line are the directories that you, the cloud administrator, edit to declare the cloud configuration. Above the line are the directories that are internal to the Cloud Lifecycle Manager such as Ansible playbooks and variables.

The input model is read from the ~/openstack/my_cloud/definition directory. Although the supplied examples use separate files for each type of object in the model, the names and layout of the files have no significance to the configuration processor, it simply reads all of the .yml files in this directory. Cloud administrators are therefore free to use whatever structure is best for their context. For example, you may decide to maintain separate files or sub-directories for each physical rack of servers.

As mentioned, the examples use the conventional upper casing for object names, but these strings are used only to define the relationship between objects. They have no specific significance to the configuration processor.

5.2.5 Disk Model #

  

Each physical disk device is associated with a device-group or a volume-group.

Device-groups are consumed by services.

Volume-groups are divided into logical-volumes.

Logical-volumes are mounted as file systems or consumed by services.

Disk-models define how local storage is to be configured and presented to services. Disk-models are identified by a name, which you will specify. The SUSE OpenStack Cloud examples provide some typical configurations. As this is an area that varies with respect to the services that are hosted on a server and the number of disks available, it is impossible to cover all possible permutations you may need to express via modifications to the examples.

Within a disk-model, disk devices are assigned to either a device-group or a volume-group.

A device-group is a set of one or more disks that are to be consumed directly by a service. For example, a set of disks to be used by swift. The device-group identifies the list of disk devices, the service, and a few service-specific attributes that tell the service about the intended use (for example, in the case of swift this is the ring names). When a device is assigned to a device-group, the associated service is responsible for the management of the disks. This management includes the creation and mounting of file systems. (swift can provide additional data integrity when it has full control over the file systems and mount points.)

A volume-group is used to present disk devices in a LVM volume group. It also contains details of the logical volumes to be created including the file system type and mount point. Logical volume sizes are expressed as a percentage of the total capacity of the volume group. A logical-volume can also be consumed by a service in the same way as a device-group. This allows services to manage their own devices on configurations that have limited numbers of disk drives.

Disk models also provide disk sizing information for virtual machine servers.

5.2.9 Server Groups #

  

A server is associated with a server-group.

A control-plane can use server-groups as failure zones for server allocation.

A server-group may be associated with a list of networks.

A server-group can contain other server-groups.

The practice of locating physical servers in a number of racks or enclosures in a data center is common. Such racks generally provide a degree of physical isolation that allows for separate power and/or network connectivity.

In the SUSE OpenStack Cloud model we support this configuration by allowing you to define a hierarchy of server-groups. Each server is associated with one server-group, normally at the bottom of the hierarchy.

Server-groups are an optional part of the input model - if you do not define any, then all servers and networks will be allocated as if they are part of the same server-group.

5.2.9.1 Server Groups and Failure Zones #

  

A control-plane defines a list of server-groups as the failure zones from which it wants to use servers. All servers in a server-group listed as a failure zone in the control-plane and any server-groups they contain are considered part of that failure zone for allocation purposes. The following example shows how three levels of server-groups can be used to model a failure zone consisting of multiple racks, each of which in turn contains a number of servers.

When allocating servers, the configuration processor will traverse down the hierarchy of server-groups listed as failure zones until it can find an available server with the required server-role. If the allocation policy is defined to be strict, it will allocate servers equally across each of the failure zones. A cluster or resource-group can also independently specify the failure zones it wants to use if needed.

5.2.9.2 Server Groups and Networks #

  

Each L3 network in a cloud must be associated with all or some of the servers, typically following a physical pattern (such as having separate networks for each rack or set of racks). This is also represented in the SUSE OpenStack Cloud model via server-groups, each group lists zero or more networks to which servers associated with server-groups at or below this point in the hierarchy are connected.

When the configuration processor needs to resolve the specific network a server should be configured to use, it traverses up the hierarchy of server-groups, starting with the group the server is directly associated with, until it finds a server-group that lists a network in the required network group.

The level in the server-group hierarchy at which a network is associated will depend on the span of connectivity it must provide. In the above example there might be networks in some network-groups which are per rack (that is Rack 1 and Rack 2 list different networks from the same network-group) and networks in a different network-group that span failure zones (the network used to provide floating IP addresses to virtual machines for example).

5.2.10 Networking #

  

In addition to the mapping of services to specific clusters and resources we must also be able to define how the services connect to one or more networks.

In a simple cloud there may be a single L3 network but more typically there are functional and physical layers of network separation that need to be expressed.

Functional network separation provides different networks for different types of traffic; for example, it is common practice in even small clouds to separate the External APIs that users will use to access the cloud and the external IP addresses that users will use to access their virtual machines. In more complex clouds it is common to also separate out virtual networking between virtual machines, block storage traffic, and volume traffic onto their own sets of networks. In the input model, this level of separation is represented by network-groups.

Physical separation is required when there are separate L3 network segments providing the same type of traffic; for example, where each rack uses a different subnet. This level of separation is represented in the input model by the networks within each network-group.

5.2.10.1 Network Groups #

  

Service endpoints attach to networks in a specific network-group.

Network-groups can define routes to other networks.

Network-groups encapsulate the configuration for services via network-tags

A network-group defines the traffic separation model and all of the properties that are common to the set of L3 networks that carry each type of traffic. They define where services are attached to the network model and the routing within that model.

In terms of service connectivity, all that has to be captured in the network-groups definition are the same service-component names that are used when defining control-planes. SUSE OpenStack Cloud also allows a default attachment to be used to specify "all service-components" that are not explicitly connected to another network-group. So, for example, to isolate swift traffic, the swift-account, swift-container, and swift-object service components are attached to an "Object" network-group and all other services are connected to "MANAGEMENT" network-group via the default relationship.

Note

The name of the "MANAGEMENT" network-group cannot be changed. It must be upper case. Every SUSE OpenStack Cloud requires this network group in order to be valid.

The details of how each service connects, such as what port it uses, if it should be behind a load balancer, if and how it should be registered in keystone, and so forth, are defined in the service definition files provided by SUSE OpenStack Cloud.

In any configuration with multiple networks, controlling the routing is a major consideration. In SUSE OpenStack Cloud, routing is controlled at the network-group level. First, all networks are configured to provide the route to any other networks in the same network-group. In addition, a network-group may be configured to provide the route any other networks in the same network-group; for example, if the internal APIs are in a dedicated network-group (a common configuration in a complex network because a network group with load balancers cannot be segmented) then other network-groups may need to include a route to the internal API network-group so that services can access the internal API endpoints. Routes may also be required to define how to access an external storage network or to define a general default route.

As part of the SUSE OpenStack Cloud deployment, networks are configured to act as the default route for all traffic that was received via that network (so that response packets always return via the network the request came from).

Note that SUSE OpenStack Cloud will configure the routing rules on the servers it deploys and will validate that the routes between services exist in the model, but ensuring that gateways can provide the required routes is the responsibility of your network configuration. The configuration processor provides information about the routes it is expecting to be configured.

For a detailed description of how the configuration processor validates routes, refer to Section 7.6, “Network Route Validation”.

5.2.10.1.1 Load Balancers #

  

Load-balancers provide a specific type of routing and are defined as a relationship between the virtual IP address (VIP) on a network in one network group and a set of service endpoints (which may be on networks in the same or a different network-group).

As each load-balancer is defined providing a virtual IP on a network-group, it follows that those network-groups can each only have one network associated to them.

The load-balancer definition includes a list of service-components and endpoint roles it will provide a virtual IP for. This model allows service-specific load-balancers to be defined on different network-groups. A "default" value is used to express "all service-components" which require a virtual IP address and are not explicitly configured in another load-balancer configuration. The details of how the load-balancer should be configured for each service, such as which ports to use, how to check for service liveness, etc., are provided in the SUSE OpenStack Cloud supplied service definition files.

Where there are multiple instances of a service (for example, in a cloud with multiple control-planes), each control-plane needs its own set of virtual IP address and different values for some properties such as the external name and security certificate. To accommodate this in SUSE OpenStack Cloud 9, load-balancers are defined as part of the control-plane, with the network groups defining just which load-balancers are attached to them.

Load balancers are always implemented by an ha-proxy service in the same control-plane as the services.

5.2.10.1.2 Separation of Public, Admin, and Internal Endpoints #

  

The list of endpoint roles for a load-balancer make it possible to configure separate load-balancers for public and internal access to services, and the configuration processor uses this information to both ensure the correct registrations in keystone and to make sure the internal traffic is routed to the correct endpoint. SUSE OpenStack Cloud services are configured to only connect to other services via internal virtual IP addresses and endpoints, allowing the name and security certificate of public endpoints to be controlled by the customer and set to values that may not be resolvable/accessible from the servers making up the cloud.

Note that each load-balancer defined in the input model will be allocated a separate virtual IP address even when the load-balancers are part of the same network-group. Because of the need to be able to separate both public and internal access, SUSE OpenStack Cloud will not allow a single load-balancer to provide both public and internal access. Load-balancers in this context are logical entities (sets of rules to transfer traffic from a virtual IP address to one or more endpoints).

The following diagram shows a possible configuration in which the hostname associated with the public URL has been configured to resolve to a firewall controlling external access to the cloud. Within the cloud, SUSE OpenStack Cloud services are configured to use the internal URL to access a separate virtual IP address.

5.2.10.1.3 Network Tags #

  

Network tags are defined by some SUSE OpenStack Cloud service-components and are used to convey information between the network model and the service, allowing the dependent aspects of the service to be automatically configured.

Network tags also convey requirements a service may have for aspects of the server network configuration, for example, that a bridge is required on the corresponding network device on a server where that service-component is installed.

See Section 6.13.2, “Network Tags” for more information on specific tags and their usage.

5.2.10.2 Networks #

  

A network is part of a network-group.

Networks are fairly simple definitions. Each network defines the details of its VLAN, optional address details (CIDR, start and end address, gateway address), and which network-group it is a member of.

5.2.10.3 Interface Model #

  

A server-role identifies an interface-model that describes how its network interfaces are to be configured and used.

Network groups are mapped onto specific network interfaces via an interface-model, which describes the network devices that need to be created (bonds, ovs-bridges, etc.) and their properties.

An interface-model acts like a template; it can define how some or all of the network-groups are to be mapped for a particular combination of physical NICs. However, it is the service-components on each server that determine which network-groups are required and hence which interfaces and networks will be configured. This means that interface-models can be shared between different server-roles. For example, an API role and a database role may share an interface model even though they may have different disk models and they will require a different subset of the network-groups.

Within an interface-model, physical ports are identified by a device name, which in turn is resolved to a physical port on a server basis via a nic-mapping. To allow different physical servers to share an interface-model, the nic-mapping is defined as a property of each server.

The interface-model can also used to describe how network devices are to be configured for use with DPDK, SR-IOV, and PCI Passthrough.

5.2.10.4 NIC Mapping #

  

When a server has more than a single physical network port, a nic-mapping is required to unambiguously identify each port. Standard Linux mapping of ports to interface names at the time of initial discovery (for example, eth0, eth1, eth2, ...) is not uniformly consistent from server to server, so a mapping of PCI bus address to interface name is instead.

NIC mappings are also used to specify the device type for interfaces that are to be used for SR-IOV or PCI Passthrough. Each SUSE OpenStack Cloud release includes the data for the supported device types.

5.2.10.5 Firewall Configuration #

  

The configuration processor uses the details it has about which networks and ports service-components use to create a set of firewall rules for each server. The model allows additional user-defined rules on a per network-group basis.

The top-level cloud configuration file, cloudConfig.yml, defines some global values for SUSE OpenStack Cloud, as described in the table below.

The snippet below shows the start of the control plane definition file.

---
  product:
    version: 2

  cloud:
    name: entry-scale-kvm

    hostname-data:
        host-prefix: ardana
        member-prefix: -m

    ntp-servers:
        - "ntp-server1"

    # dns resolving configuration for your site
    dns-settings:
      nameservers:
        - name-server1

    firewall-settings:
        enable: true
        # log dropped packets
        logging: true

    audit-settings:
       audit-dir: /var/audit
       default: disabled
       enabled-services:
         - keystone

The snippet below shows the start of the control plane definition file.

---
  product:
     version: 2

  control-planes:
     - name: control-plane-1
       control-plane-prefix: cp1
       region-name: region0
       failure-zones:
         - AZ1
         - AZ2
         - AZ3
       configuration-data:
         - NEUTRON-CONFIG-CP1
         - OCTAVIA-CONFIG-CP1
       common-service-components:
         - logging-producer
         - monasca-agent
         - stunnel
         - lifecycle-manager-target
       clusters:
         - name: cluster1
           cluster-prefix: c1
           server-role: CONTROLLER-ROLE
           member-count: 3
           allocation-policy: strict
           service-components:
             - lifecycle-manager
             - ntp-server
             - swift-ring-builder
             - mysql
             - ip-cluster
             ...

       resources:
         - name: compute
           resource-prefix: comp
           server-role: COMPUTE-ROLE
           allocation-policy: any
           min-count: 0
           service-components:
              - ntp-client
              - nova-compute
              - nova-compute-kvm
              - neutron-l3-agent
              ...

control-planes:
    - name: cp-2
      uses:
        - from: cp-shared
          service-components:
            - any

network-groups:
    - name: EXTERNAL-API
      load-balancers:
        - extlb

  control-planes:
    - name: cp1
      load-balancers:
        - provider: ip-cluster
          name: extlb
          external-name:
          tls-components:
            - default
          roles:
            - public
          cert-file: cp1-extlb-cert

Load balancers may be defined as part of a network-group object, or as part of a control-plane object. When a load-balancer is defined in a control-plane, it must be referenced by name only from the associated network-group object.

For clouds consisting of multiple control planes, load balancers must be defined as part of a control-plane object. This allows different load balancer configurations for each control plane.

In either case, a load-balancer definition has the following attributes:

load-balancers:
        - provider: ip-cluster
          name: extlb
          external-name:

          tls-components:
            - default
          roles:
            - public
          cert-file: cp1-extlb-cert

The regions configuration object is used to define how a set of services from one or more control-planes are mapped into Openstack regions (entries within the keystone catalog). In SUSE OpenStack Cloud, multiple regions are not supported. Only Region0 is valid.

Within each region a given service is provided by one control plane, but the set of services in the region may be provided by multiple control planes.

The servers configuration object is used to list the available servers for deploying the cloud.

Optionally, it can be used as an input file to the operating system installation process, in which case some additional fields (identified below) will be necessary.

---
  product:
    version: 2

  baremetal:
    subnet: 192.168.10.0
    netmask: 255.255.255.0

  servers:
    - id: controller1
      ip-addr: 192.168.10.3
      role: CONTROLLER-ROLE
      server-group: RACK1
      nic-mapping: HP-DL360-4PORT
      mac-addr: b2:72:8d:ac:7c:6f
      ilo-ip: 192.168.9.3
      ilo-password: password
      ilo-user: admin

    - id: controller2
      ip-addr: 192.168.10.4
      role: CONTROLLER-ROLE
      server-group: RACK2
      nic-mapping: HP-DL360-4PORT
      mac-addr: 8a:8e:64:55:43:76
      ilo-ip: 192.168.9.4
      ilo-password: password
      ilo-user: admin

The server-groups configuration object provides a mechanism for organizing servers and networks into a hierarchy that can be used for allocation and network resolution.

---
  product:
     version: 2

     - name: CLOUD
        server-groups:
         - AZ1
         - AZ2
         - AZ3
        networks:
         - EXTERNAL-API-NET
         - EXTERNAL-VM-NET
         - GUEST-NET
         - MANAGEMENT-NET

     #
     # Create a group for each failure zone
     #
     - name: AZ1
       server-groups:
         - RACK1

     - name: AZ2
       server-groups:
         - RACK2

     - name: AZ3
       server-groups:
         - RACK3

     #
     # Create a group for each rack
     #
     - name: RACK1
     - name: RACK2
     - name: RACK3

The server-roles configuration object is a list of the various server roles that you can use in your cloud. Each server role is linked to other configuration objects:

Server roles are referenced in the servers (see Section 6.7, “Server Roles”) configuration object above.

---
  product:
     version: 2

  server-roles:

     - name: CONTROLLER-ROLE
       interface-model: CONTROLLER-INTERFACES
       disk-model: CONTROLLER-DISKS

     - name: COMPUTE-ROLE
       interface-model: COMPUTE-INTERFACES
       disk-model: COMPUTE-DISKS
       memory-model: COMPUTE-MEMORY
       cpu-model: COMPUTE-CPU

The disk-models configuration object is used to specify how the directly attached disks on the server should be configured. It can also identify which service or service component consumes the disk, for example, swift object server, and provide service-specific information associated with the disk. It is also used to specify disk sizing information for virtual machine servers.

Disks can be used as raw devices or as logical volumes and the disk model provides a configuration item for each.

If the operating system has been installed by the SUSE OpenStack Cloud installation process then the root disk will already have been set up as a volume-group with a single logical-volume. This logical-volume will have been created on a partition identified, symbolically, in the configuration files as /dev/sda_root. This is due to the fact that different BIOS systems (UEFI, Legacy) will result in different partition numbers on the root disk.

---
  product:
     version: 2

  disk-models:
  - name: SES-DISKS

    volume-groups:
       - ...
    device-groups:
       - ...
    vm-size:
       ...

6.8.1 Volume Groups #

  

The volume-groups configuration object is used to define volume groups and their constituent logical volumes.

Note that volume-groups are not exact analogs of device-groups. A volume-group specifies a set of physical volumes used to make up a volume-group that is then subdivided into multiple logical volumes.

The SUSE OpenStack Cloud operating system installation automatically creates a volume-group name "ardana-vg" on the first drive in the system. It creates a "root" logical volume there. The volume-group can be expanded by adding more physical-volumes (see examples). In addition, it is possible to create more logical-volumes on this volume-group to provide dedicated capacity for different services or file system mounts.

   volume-groups:
     - name: ardana-vg
       physical-volumes:
         - /dev/sda_root

       logical-volumes:
         - name: root
           size: 35%
           fstype: ext4
           mount: /

         - name: log
           size: 50%
           mount: /var/log
           fstype: ext4
           mkfs-opts: -O large_file

         - ...

     - name: vg-comp
       physical-volumes:
         - /dev/sdb
       logical-volumes:
         - name: compute
           size: 95%
           mount: /var/lib/nova
           fstype: ext4
           mkfs-opts: -O large_file

Key	Value Descriptions
name	The name that will be assigned to the volume-group
physical-volumes	A list of physical disks that make up the volume group. As installed by the SUSE OpenStack Cloud operating system install process, the volume group "ardana-vg" will use a large partition (sda_root) on the first disk. This can be expanded by adding additional disk(s).
logical-volumes	A list of logical volume devices to create from the above named volume group.
name	The name to assign to the logical volume.
size	The size, expressed as a percentage of the entire volume group capacity, to assign to the logical volume.
fstype (optional)	The file system type to create on the logical volume. If none specified, the volume is not formatted.
mkfs-opts (optional)	Options, for example, -O large_file to pass to the mkfs command.
mode (optional)	The mode changes the root file system mode bits, which can be either a symbolic representation or an octal number representing the bit pattern for the new mode bits.
mount (optional)	Mount point for the file system.
consumer attributes (optional, consumer dependent)	These will vary according to the service consuming the device group. The examples section provides sample content for the different services.

Important

Multipath storage should be listed as the corresponding /dev/mapper/mpathX

The memory-models configuration object describes details of the optional configuration of Huge Pages. It also describes the amount of memory to be allocated for virtual machine servers.

The memory-model allows the number of pages of a particular size to be configured at the server level or at the numa-node level.

The following example would configure:

memory-models:
    - name: COMPUTE-MEMORY-NUMA
      default-huge-page-size: 2M
      huge-pages:
        - size: 2M
          count: 5
          numa-node: 0
        - size: 2M
          count: 5
          numa-node: 1
        - size: 1G
          count: 3
        - size: 2M
          count: 6
    - name: VIRTUAL-CONTROLLER-MEMORY
      vm-size:
        ram: 6G

The cpu-models configuration object describes how CPUs are assigned for use by service components such as nova (for VMs) and Open vSwitch (for DPDK), and whether or not those CPUs are isolated from the general kernel SMP balancing and scheduling algorithms. It also describes the number of vCPUs for virtual machine servers.

---
  product:
     version: 2

  cpu-models:
    - name: COMPUTE-CPU
      assignments:
        - components:
            - nova-compute-kvm
          cpu:
            - processor-ids: 0-1,3,5-7
              role: vm
        - components:
            - openvswitch
          cpu:
            - processor-ids: 4,12
              isolate: False
              role: eal
            - processor-ids: 2,10
              role: pmd
    - name: VIRTUAL-CONTROLLER-CPU
      vm-size:
         vcpus: 4

cpu-models

The interface-models configuration object describes how network interfaces are bonded and the mapping of network groups onto interfaces. Interface devices are identified by name and mapped to a particular physical port by the nic-mapping (see Section 5.2.10.4, “NIC Mapping”).

---
  product:
     version: 2

  interface-models:
     - name: INTERFACE_SET_CONTROLLER
       network-interfaces:
          - name: BONDED_INTERFACE
            device:
              name: bond0
            bond-data:
              provider: linux
              devices:
                - name: hed3
                - name: hed4
              options:
                mode: active-backup
                miimon: 200
                primary: hed3
            network-groups:
               - EXTERNAL_API
               - EXTERNAL_VM
               - GUEST

          - name: UNBONDED_INTERFACE
            device:
               name: hed0
            network-groups:
               - MGMT


       fcoe-interfaces:
          - name: FCOE_DEVICES
            devices:
              - eth7
              - eth8


     - name: INTERFACE_SET_DPDK
       network-interfaces:
          - name: BONDED_DPDK_INTERFACE
            device:
              name: bond0
            bond-data:
              provider: openvswitch
              devices:
                - name: dpdk0
                - name: dpdk1
              options:
                mode: active-backup
            network-groups:
               - GUEST
          - name: UNBONDED_DPDK_INTERFACE
            device:
               name: dpdk2
            network-groups:
               - PHYSNET2
       dpdk-devices:
         - devices:
             - name: dpdk0
             - name: dpdk1
             - name: dpdk2
               driver: igb_uio
           components:
             - openvswitch
           eal-options:
             - name: socket-mem
               value: 1024,0
             - name: n
               value: 2
           component-options:
             - name: n-dpdk-rxqs
               value: 64

Important

The devices must be “raw” device names, not names controlled via a nic-mapping.

The nic-mappings configuration object is used to ensure that the network device name used by the operating system always maps to the same physical device. A nic-mapping is associated to a server in the server definition file. Devices should be named hedN to avoid name clashes with any other devices configured during the operating system install as well as any interfaces that are not being managed by SUSE OpenStack Cloud, ensuring that all devices on a baremetal machine are specified in the file. An excerpt from nic_mappings.yml illustrates:

---
  product:
    version: 2

  nic-mappings:

    - name: HP-DL360-4PORT
      physical-ports:
        - logical-name: hed1
          type: simple-port
          bus-address: "0000:07:00.0"

        - logical-name: hed2
          type: simple-port
          bus-address: "0000:08:00.0"
          nic-device-type: '8086:10fb'

        - logical-name: hed3
          type: multi-port
          bus-address: "0000:09:00.0"
          port-attributes:
              port-num: 0

        - logical-name: hed4
          type: multi-port
          bus-address: "0000:09:00.0"
          port-attributes:
              port-num: 1

Each entry in the nic-mappings list has the following attributes:

Each entry in the physical-ports list has the following attributes:

Network-groups define the overall network topology, including where service-components connect, what load balancers are to be deployed, which connections use TLS, and network routing. They also provide the data needed to map neutron's network configuration to the physical networking.

Note

The name of the "MANAGEMENT" network-group cannot be changed. It must be upper case. Every SUSE OpenStack Cloud requires this network group in order to be valid.

---
  product:
     version: 2

  network-groups:

     - name: EXTERNAL-API
       hostname-suffix: extapi

       load-balancers:
         - provider: ip-cluster
           name: extlb
           external-name:

           tls-components:
             - default
           roles:
            - public
           cert-file: my-public-entry-scale-kvm-cert

      - name: EXTERNAL-VM
        tags:
          - neutron.l3_agent.external_network_bridge

      - name: GUEST
        hostname-suffix: guest
        tags:
          - neutron.networks.vxlan

      - name: MANAGEMENT
        hostname-suffix: mgmt
        hostname: true

        component-endpoints:
          - default

        routes:
          - default

        load-balancers:
          - provider: ip-cluster
            name: lb
            components:
              - default
            roles:
              - internal
              - admin

        tags:
          - neutron.networks.vlan:
              provider-physical-network: physnet1

Important

hostnamemust be set to true for one, and only one, of your network groups.

A load balancer definition has the following attributes:

network-groups:

     - name: EXTERNAL-API
       hostname-suffix: extapi

       load-balancers:
         - lb-cp1
         - lb-cp2

  tags:
    - neutron.networks.vxlan

  tags:
    - neutron.networks.vxlan:
        tenant-vxlan-id-range: “1:20000”

  tags:
    - neutron.networks.vxlan:
        tenant-vxlan-id-range: “1:2000,3000:4000,5000:6000”

  tags:
    - neutron.networks.vlan:
        provider-physical-network: physnet1

  tags:
    - neutron.networks.vlan:
        provider-physical-network: physnet1
        tenant-vlan-id-range: “30:50,100:200”

  tags:
    - neutron.networks.flat:
        provider-physical-network: flatnet1

  tags:
    - neutron.l3_agent.external_network_bridge

    +eth0 (9000)   <------ this MTU comes from NET-GROUP-1
    | |
    | |----+ vlan201@eth0 (1550)
    \------+ vlan301@eth0 (9000)

    +bond0 (9000)   <------ because of NET-GROUP-3
    | | |
    | | |--+vlan101@bond0 (3000)
    | |----+vlan201@bond0 (1550)
    |------+vlan301@bond0 (9000)

A network definition represents a physical L3 network used by the cloud infrastructure. Note that these are different from the network definitions that are created/configured in neutron, although some of the networks may be used by neutron.

---
   product:
     version: 2

   networks:
     - name: NET_EXTERNAL_VM
       vlanid: 102
       tagged-vlan: true
       network-group: EXTERNAL_VM

     - name: NET_GUEST
       vlanid: 103
       tagged-vlan: true
       cidr: 10.1.1.0/24
       gateway-ip: 10.1.1.1
       network-group: GUEST

     - name: NET_MGMT
       vlanid: 100
       tagged-vlan: false
       cidr: 10.2.1.0/24
       addresses:
       - 10.2.1.10-10.2.1.20
       - 10.2.1.24
       - 10.2.1.30-10.2.1.36
       gateway-ip: 10.2.1.1
       network-group: MGMT

The configuration processor will automatically generate "allow" firewall rules for each server based on the services deployed and block all other ports. The firewall rules in the input model allow the customer to define additional rules for each network group.

Administrator-defined rules are applied after all rules generated by the Configuration Processor.

---
  product:
     version: 2

  firewall-rules:

     - name: PING
       network-groups:
       - MANAGEMENT
       - GUEST
       - EXTERNAL-API
       rules:
       # open ICMP echo request (ping)
       - type: allow
         remote-ip-prefix:  0.0.0.0/0
         # icmp type
         port-range-min: 8
         # icmp code
         port-range-max: 0
         protocol: icmp

Configuration data allows values to be passed into the model to be used in the context of a specific control plane or cluster. The content and format of the data is service specific.

---
  product:
    version: 2

  configuration-data:
    - name:  NEUTRON-CONFIG-CP1
      services:
        - neutron
      data:
        neutron_provider_networks:
        - name: OCTAVIA-MGMT-NET
          provider:
            - network_type: vlan
              physical_network: physnet1
              segmentation_id: 106
          cidr: 172.30.1.0/24
          no_gateway:  True
          enable_dhcp: True
          allocation_pools:
            - start: 172.30.1.10
              end: 172.30.1.250
          host_routes:
            # route to MANAGEMENT-NET-1
            - destination: 192.168.245.0/24
              nexthop:  172.30.1.1

        neutron_external_networks:
        - name: ext-net
          cidr: 172.31.0.0/24
          gateway: 172.31.0.1
          provider:
            - network_type: vlan
              physical_network: physnet1
              segmentation_id: 107
          allocation_pools:
            - start: 172.31.0.2
              end: 172.31.0.254

      network-tags:
        - network-group: MANAGEMENT
          tags:
            - neutron.networks.vxlan
            - neutron.networks.vlan:
                provider-physical-network: physnet1
        - network-group: EXTERNAL-VM
          tags:
            - neutron.l3_agent.external_network_bridge

---
  product:
    version: 2

  configuration-data:
    - name: OCTAVIA-CONFIG-CP1
      services:
        - octavia
      data:
        amp_network_name: OCTAVIA-MGMT-NET

---
  product:
    version: 2

  configuration-data:
    - name:  IRONIC-CONFIG-CP1
      services:
        - ironic
      data:
        cleaning_network: guest-network
        enable_node_cleaning: true
        enable_oneview: false

        oneview_manager_url:
        oneview_username:
        oneview_encrypted_password:
        oneview_allow_insecure_connections:
        tls_cacert_file:
        enable_agent_drivers: true

---
  product:
    version: 2

  configuration-data:
  - name: SWIFT-CONFIG-CP1
    services:
      - swift
    data:
      control_plane_rings:
        swift-zones:
          - id: 1
            server-groups:
              - AZ1
          - id: 2
            server-groups:
              - AZ2
          - id: 3
            server-groups:
              - AZ3
        rings:
          - name: account
            display-name: Account Ring
            min-part-hours: 16
            partition-power: 12
            replication-policy:
              replica-count: 3

          - name: container
            display-name: Container Ring
            min-part-hours: 16
            partition-power: 12
            replication-policy:
              replica-count: 3

          - name: object-0
            display-name: General
            default: yes
            min-part-hours: 16
            partition-power: 12
            replication-policy:
              replica-count: 3

Through pass_through definitions, certain configuration values can be assigned and used.

product:
  version: 2

pass-through:
  global:
    esx_cloud: true
  servers:
      data:
        vmware:
          cert_check: false
          vcenter_cluster: Cluster1
          vcenter_id: BC9DED4E-1639-481D-B190-2B54A2BF5674
          vcenter_ip: 10.1.200.41
          vcenter_port: 443
          vcenter_username: administrator@vsphere.local
          id: 7d8c415b541ca9ecf9608b35b32261e6c0bf275a

Names are generated by the configuration processor for all allocated IP addresses. A server connected to multiple networks will have multiple names associated with it. One of these may be assigned as the hostname for a server via the network-group configuration (see Section 6.12, “NIC Mappings”). Names are generated from data taken from various parts of the input model as described in the following sections.

Names generated for servers in a cluster have the following form:

CLOUD-CONTROL-PLANE-CLUSTERMEMBER-PREFIXMEMBER_ID-NETWORK

Example: ardana-cp1-core-m1-mgmt

Names generated for servers in a resource group have the following form:

CLOUD-CONTROL-PLANE-RESOURCE-PREFIXMEMBER_ID-NETWORK

Example: ardana-cp1-comp0001-mgmt

The configuration processor makes allocation decisions on servers and IP addresses which it needs to remember between successive runs so that if new servers are added to the input model they do not disrupt the previously deployed allocations.

To allow users to make multiple iterations of the input model before deployment SUSE OpenStack Cloud will only persist data when the administrator confirms that they are about to deploy the results via the "ready-deployment" operation. To understand this better, consider the following example:

Imagine you have completed your SUSE OpenStack Cloud deployment with servers A, B, and C and you want to add two new compute nodes by adding servers D and E to the input model.

When you add these to the input model and re-run the configuration processor it will read the persisted data for A, B, and C and allocate D and E as new servers. The configuration processor now has allocation data for A, B, C, D, and E -- which it keeps in a staging area (actually a special branch in Git) until we get confirmation that the configuration processor has done what you intended and you are ready to deploy the revised configuration.

If you notice that the role of E is wrong and it became a swift node instead of a nova node you need to be able to change the input model and re-run the configuration processor. This is fine because the allocations of D and E have not been confirmed, and so the configuration processor will re-read the data about A, B, C and re-allocate D and E now to the correct clusters, updating the persisted data in the staging area.

You can loop though this as many times as needed. Each time, the configuration processor is processing the deltas to what is deployed, not the results of the previous run. When you are ready to use the results of the configuration processor, you run ready-deployment.yml which commits the data in the staging area into the persisted data. The next run of the configuration processor will then start from the persisted data for A, B, C, D, and E.

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml \
-e remove_deleted_servers="y"

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml \
-e free_unused_addresses="y"

The configuration processor allocates servers to a cluster or resource group in the following sequence:

Once the configuration processor has allocated a server to a cluster or resource group it uses the information in the associated interface-model to determine which networks need to be configured. It does this by:

If there is no network available to a server, either because the interface-model does not include the required network-group, or there is no network from that group in the appropriate part of the server-groups hierarchy, then the configuration processor will generate an error.

The configuration processor will also generate an error if the server address does not match any of the networks it will be connected to.

Once the configuration processor has allocated all of the required servers and matched them to the appropriate networks, it validates that all service-components have the required network routes to other service-components.

It does this by using the data in the services section of the input model which provides details of which service-components need to connect to each other. This data is not configurable by the administrator; however, it is provided as part of the SUSE OpenStack Cloud release.

For each server, the configuration processor looks at the list of service-components it runs and determines the network addresses of every other service-component it needs to connect to (depending on the service, this might be a virtual IP address on a load balancer or a set of addresses for the service).

If the target address is on a network that this server is connected to, then there is no routing required. If the target address is on a different network, then the Configuration Processor looks at each network the server is connected to and looks at the routes defined in the corresponding network-group. If the network-group provides a route to the network-group of the target address, then that route is considered valid.

Networks within the same network-group are always considered as routed to each other; networks from different network-groups must have an explicit entry in the routes stanza of the network-group definition. Routes to a named network-group are always considered before a "default" route.

A warning is given for any routes which are using the "default" route since it is possible that the user did not intend to route this traffic. Such warning can be removed by adding the appropriate network-group to the list of routes.

The configuration processor provides details of all routes between networks that it is expecting to be configured in the info/route_info.yml file.

To illustrate how network routing is defined in the input model, consider the following example:

A compute server is configured to run nova-compute which requires access to the neutron API servers and a block storage service. The neutron API servers have a virtual IP address provided by a load balancer in the INTERNAL-API network-group and the storage service is connected to the ISCSI network-group. nova-compute itself is part of the set of components attached by default to the MANAGEMENT network-group. The intention is to have virtual machines on the compute server connect to the block storage via the ISCSI network.

The physical network is shown below:

The corresponding entries in the network-groups are:

  - name: INTERNAL-API
    hostname-suffix: intapi

    load-balancers:
       - provider: ip-cluster
         name: lb
         components:
           - default
         roles:
           - internal
           - admin

       - name: MANAGEMENT
         hostname-suffix: mgmt
         hostname: true

         component-endpoints:
           - default

         routes:
           - INTERNAL-API
           - default

       - name: ISCSI
         hostname-suffix: iscsi

         component-endpoints:
            - storage service

And the interface-model for the compute server looks like this:

  - name: INTERFACE_SET_COMPUTE
    network-interfaces:
      - name: BOND0
        device:
           name: bond0
        bond-data:
           options:
              mode: active-backup
              miimon: 200
              primary: hed5
           provider: linux
           devices:
              - name: hed4
              - name: hed5
        network-groups:
          - MANAGEMENT
          - ISCSI

When validating the route from nova-compute to the neutron API, the configuration processor will detect that the target address is on a network in the INTERNAL-API network group, and that the MANAGEMENT network (which is connected to the compute server) provides a route to this network, and thus considers this route valid.

When validating the route from nova-compute to a storage service, the configuration processor will detect that the target address is on a network in the ISCSInetwork group. However, because there is no service component on the compute server connected to the ISCSI network (according to the network-group definition) the ISCSI network will not have been configured on the compute server (see Section 7.5, “Server Network Selection”. The configuration processor will detect that the MANAGEMENT network-group provides a "default" route and thus considers the route as valid (it is, of course, valid to route ISCSI traffic). However, because this is using the default route, a warning will be issued:

#   route-generator-2.0       WRN: Default routing used between networks
The following networks are using a 'default' route rule. To remove this warning
either add an explicit route in the source network group or force the network to
attach in the interface model used by the servers.
  MANAGEMENT-NET-RACK1 to ISCSI-NET
    ardana-ccp-comp0001
  MANAGEMENT-NET-RACK 2 to ISCSI-NET
    ardana-ccp-comp0002
  MANAGEMENT-NET-RACK 3 to SCSI-NET
    ardana-ccp-comp0003

To remove this warning, you can either add ISCSI to the list of routes in the MANAGEMENT network group (routed ISCSI traffic is still a valid configuration) or force the compute server to attach to the ISCSI network-group by adding it as a forced-network-group in the interface-model, like this:

  - name: INTERFACE_SET_COMPUTE
      network-interfaces:
        - name: BOND0
          device:
            name: bond0
          bond-data:
            options:
               mode: active-backup
               miimon: 200
               primary: hed5
            provider: linux
            devices:
               - name: hed4
               - name: hed5
          network-groups:
             - MANAGEMENT
          forced-network-groups:
             - ISCSI

With the attachment to the ISCSI network group forced, the configuration processor will attach the compute server to a network in that group and validate the route as either being direct or between networks in the same network-group.

The generated route_info.yml file will include entries such as the following, showing the routes that are still expected to be configured between networks in the MANAGEMENT network group and the INTERNAL-API network group.

  MANAGEMENT-NET-RACK1:
     INTERNAL-API-NET:
        default: false
        used_by:
           nova-compute:
              neutron-server:
              - ardana-ccp-comp0001
   MANAGEMENT-NET-RACK2:
     INTERNAL-API-NET:
        default: false
        used_by:
          nova-compute:
            neutron-server:
            - ardana-ccp-comp0003

neutron provider VLANs are networks that map directly to an 802.1Q VLAN in the cloud provider’s physical network infrastructure. There are four aspects to a provider VLAN configuration:

The physical network infrastructure must be configured to convey the provider VLAN traffic as tagged VLANs to the cloud compute nodes and neutron network nodes. Configuration of the physical network infrastructure is outside the scope of the SUSE OpenStack Cloud 9 software.

SUSE OpenStack Cloud 9 automates the server networking configuration and the neutron configuration based on information in the cloud definition. To configure the system for provider VLANs, specify the neutron.networks.vlan tag with a provider-physical-network attribute on one or more network-groups as described in Section 6.13.2, “Network Tags”. For example (some attributes omitted for brevity):

  network-groups:

    - name: NET_GROUP_A
      tags:
        - neutron.networks.vlan:
              provider-physical-network: physnet1

    - name: NET_GROUP_B
      tags:
        - neutron.networks.vlan:
              provider-physical-network: physnet2

A network-group is associated with a server network interface via an interface-model as described in Section 6.11, “Interface Models”. For example (some attributes omitted for brevity):

  interface-models:
     - name: INTERFACE_SET_X
       network-interfaces:
        - device:
              name: bond0
          network-groups:
            - NET_GROUP_A
        - device:
              name: hed3
          network-groups:
            - NET_GROUP_B

A network-group used for provider VLANs may contain only a single SUSE OpenStack Cloud network, because that VLAN must span all compute nodes and any neutron network nodes/controllers (that is, it is a single L2 segment). The SUSE OpenStack Cloud network must be defined with tagged-vlan: false, otherwise a Linux VLAN network interface will be created. For example:

  networks:
     - name: NET_A
       tagged-vlan: false
       network-group: NET_GROUP_A
     - name: NET_B
       tagged-vlan: false
       network-group: NET_GROUP_B

When the cloud is deployed, SUSE OpenStack Cloud 9 will create the appropriate bridges on the servers, and set the appropriate attributes in the neutron configuration files (for example, bridge_mappings).

After the cloud has been deployed, create neutron network objects for each provider VLAN using the OpenStackClient CLI:

tux > sudo openstack network create --provider:network_type vlan \
--provider:physical_network PHYSNET1 --provider:segmentation_id 101 MYNET101

tux > sudo openstack network create --provider:network_type vlan \
--provider:physical_network PHYSNET2 --provider:segmentation_id 234 MYNET234

All the example configurations use a “deployer-in-the-cloud” scenario where the first controller is also the deployer/Cloud Lifecycle Manager. If you want to use a standalone Cloud Lifecycle Manager, you need to add the relevant details in control_plane.yml, servers.yml and related configuration files. Detailed instructions are available at Section 12.1, “Using a Dedicated Cloud Lifecycle Manager Node”.

This file provides details of all the IP addresses allocated by the Configuration Processor:

  NETWORK GROUPS
     LIST OF NETWORKS
        IP ADDRESS
           LIST OF ALIASES

Example:

  EXTERNAL-API:
     EXTERNAL-API-NET:
        10.0.1.2:
           - ardana-cp1-c1-m1-extapi
        10.0.1.3:
           - ardana-cp1-c1-m2-extapi
        10.0.1.4:
           - ardana-cp1-c1-m3-extapi
        10.0.1.5:
           - ardana-cp1-vip-public-SWF-PRX-extapi
           - ardana-cp1-vip-public-FRE-API-extapi
           - ardana-cp1-vip-public-GLA-API-extapi
           - ardana-cp1-vip-public-HEA-ACW-extapi
           - ardana-cp1-vip-public-HEA-ACF-extapi
           - ardana-cp1-vip-public-NEU-SVR-extapi
           - ardana-cp1-vip-public-KEY-API-extapi
           - ardana-cp1-vip-public-MON-API-extapi
           - ardana-cp1-vip-public-HEA-API-extapi
           - ardana-cp1-vip-public-NOV-API-extapi
           - ardana-cp1-vip-public-CND-API-extapi
           - ardana-cp1-vip-public-CEI-API-extapi
           - ardana-cp1-vip-public-SHP-API-extapi
           - ardana-cp1-vip-public-OPS-WEB-extapi
           - ardana-cp1-vip-public-HZN-WEB-extapi
           - ardana-cp1-vip-public-NOV-VNC-extapi
  EXTERNAL-VM:
     EXTERNAL-VM-NET: {}
  GUEST:
     GUEST-NET:
        10.1.1.2:
           - ardana-cp1-c1-m1-guest
        10.1.1.3:
           - ardana-cp1-c1-m2-guest
        10.1.1.4:
           - ardana-cp1-c1-m3-guest
        10.1.1.5:
           - ardana-cp1-comp0001-guest
  MANAGEMENT:
  ...

This file provides details of all the network ports that will be opened on the deployed cloud. Data is ordered by network. If you want to configure an external firewall in front of the External API network, then you would need to open the ports listed in that section.

  NETWORK NAME
     List of:
        PORT
        PROTOCOL
        LIST OF IP ADDRESSES
        LIST OF COMPONENTS

Example:

  EXTERNAL-API:
  -   addresses:
      - 10.0.1.5
      components:
      - horizon
      port: '443'
      protocol: tcp
  -   addresses:
      - 10.0.1.5
      components:
      - keystone-api
      port: '5000'
      protocol: tcp

Port 443 (tcp) is open on network EXTERNAL-API for address 10.0.1.5 because it is used by horizon

Port 5000 (tcp) is open on network EXTERNAL-API for address 10.0.1.5 because it is used by keystone API

This file provides details of routes between networks that need to be configured. Available routes are defined in the input model as part of the network-groups data; this file shows which routes will actually be used. SUSE OpenStack Cloud will reconfigure routing rules on the servers, you must configure the corresponding routes within your physical network. Routes must be configured to be symmetrical -- only the direction in which a connection is initiated is captured in this file.

Note that simple models may not require any routes, with all servers being attached to common L3 networks. The following example is taken from the tech-preview/mid-scale-kvm example.

  SOURCE-NETWORK-NAME
      TARGET-NETWORK-NAME
           default:   TRUE IF THIS IS THIS THE RESULT OF A "DEFAULT" ROUTE RULE
           used_by:
                SOURCE-SERVICE
                     TARGET-SERVICE
                     LIST OF HOSTS USING THIS ROUTE

Example:

MANAGEMENT-NET-RACK1:
    INTERNAL-API-NET:
         default: false
         used_by:
            - ardana-cp1-mtrmon-m1
            keystone-api:
            - ardana-cp1-mtrmon-m1
     MANAGEMENT-NET-RACK2:
         default: false
         used_by:
            cinder-backup:
            rabbitmq:
            - ardana-cp1-core-m1

A route is required from network MANAGEMENT-NET-RACK1 to network MANAGEMENT-NET-RACK2 so that cinder-backup can connect to rabbitmq from server ardana-cp1-core-m1

This file provides details of how servers have been allocated by the Configuration Processor. This provides the easiest way to find where a specific physical server (identified by server-id) is being used.

   SERVER-ID
         failure-zone: FAILURE ZONE THAT THE SERVER WAS ALLOCATED FROM
         hostname: HOSTNAME OF THE SERVER
         net_data: NETWORK CONFIGURATION
         state:  "allocated" | "available" 

Example:

   controller1:
         failure-zone: AZ1
         hostname: ardana-cp1-c1-m1-mgmt
         net_data:
              BOND0:
                   EXTERNAL-API-NET:
                       addr: 10.0.1.2
                       tagged-vlan: true
                       vlan-id: 101
                   EXTERNAL-VM-NET:
                       addr: null
                       tagged-vlan: true
                       vlan-id: 102
                   GUEST-NET:
                       addr: 10.1.1.2
                       tagged-vlan: true
                       vlan-id: 103
                   MANAGEMENT-NET:
                       addr: 192.168.10.3
                       tagged-vlan: false
                       vlan-id: 100
         state: allocated

This file provides details of how services are distributed across the cloud.

  CONTROL-PLANE
      SERVICE
          SERVICE COMPONENT
               LIST OF HOSTS

Example:

  control-plane-1:
        neutron:
             neutron-client:
                - ardana-cp1-c1-m1-mgmt
                - ardana-cp1-c1-m2-mgmt
                - ardana-cp1-c1-m3-mgmt
             neutron-dhcp-agent:
                - ardana-cp1-c1-m1-mgmt
                - ardana-cp1-c1-m2-mgmt
                - ardana-cp1-c1-m3-mgmt
             neutron-l3-agent:
                 - ardana-cp1-comp0001-mgmt
        ...

This file provides details of the topology of the cloud from the perspective of each control plane:

control_planes:
  CONTROL-PLANE-NAME
      load-balancers:
         LOAD-BALANCER-NAME:
             address:  IP ADDRESS OF VIP
             cert-file:  NAME OF CERT FILE
             external-name: NAME TO USED FOR ENDPOINTS
             network: NAME OF THE NETWORK THIS LB IS CONNECTED TO
             network_group: NAME OF THE NETWORK GROUP THIS LB IS CONNECT TO
             provider: SERVICE COMPONENT PROVIDING THE LB
             roles:  LIST OF ROLES OF THIS LB
             services:
                SERVICE-NAME:
                    COMPONENT-NAME:
                        aliases:
                           ROLE:  NAME IN /etc/hosts
                        host-tls:  BOOLEAN, TRUE IF CONNECTION FROM LB USES TLS
                        hosts:  LIST OF HOSTS FOR THIS SERVICE
                        port:  PORT USED FOR THIS COMPONENT
                        vip-tls: BOOLEAN, TRUE IF THE VIP TERMINATES TLS
      clusters:
          CLUSTER-NAME
              failure-zones:
                 FAILURE-ZONE-NAME:
                    LIST OF HOSTS
              services:
                 SERVICE NAME:
                     components:
                        LIST OF SERVICE COMPONENTS
                     regions:
                        LIST OF REGION NAMES
      resources:
         RESOURCE-NAME:
             AS FOR CLUSTERS ABOVE

Example:

    control_planes:
    control-plane-1:
        clusters:
            cluster1:
                failure_zones:
                    AZ1:
                    - ardana-cp1-c1-m1-mgmt
                    AZ2:
                    - ardana-cp1-c1-m2-mgmt
                    AZ3:
                    - ardana-cp1-c1-m3-mgmt
                services:
                    barbican:
                        components:
                        - barbican-api
                        - barbican-worker
                        regions:
                        - region1
                                               …
        load-balancers:
            extlb:
                address: 10.0.1.5
                cert-file: my-public-entry-scale-kvm-cert
                external-name: ''
                network: EXTERNAL-API-NET
                network-group: EXTERNAL-API
                provider: ip-cluster
                roles:
                - public
                services:
                    barbican:
                        barbican-api:
                            aliases:
                                public: ardana-cp1-vip-public-KEYMGR-API-extapi
                            host-tls: true
                            hosts:
                            - ardana-cp1-c1-m1-mgmt
                            - ardana-cp1-c1-m2-mgmt
                            - ardana-cp1-c1-m3-mgmt
                            port: '9311'
                            vip-tls: true

This file provides details of the topology of the cloud from the perspective of each network_group:

network-groups:
  NETWORK-GROUP-NAME:
      NETWORK-NAME:
          control-planes:
              CONTROL-PLANE-NAME:
                  clusters:
                     CLUSTER-NAME:
                         servers:
                            ARDANA-SERVER-NAME: ip address
                         vips:
                            IP ADDRESS: load balancer name
                  resources:
                     RESOURCE-GROUP-NAME:
                         servers:
                            ARDANA-SERVER-NAME: ip address

Example:

   network_groups:
    EXTERNAL-API:
        EXTERNAL-API-NET:
            control_planes:
                control-plane-1:
                    clusters:
                        cluster1:
                            servers:
                                ardana-cp1-c1-m1: 10.0.1.2
                                ardana-cp1-c1-m2: 10.0.1.3
                                ardana-cp1-c1-m3: 10.0.1.4
                            vips:
                                10.0.1.5: extlb
    EXTERNAL-VM:
        EXTERNAL-VM-NET:
            control_planes:
                control-plane-1:
                    clusters:
                        cluster1:
                            servers:
                                ardana-cp1-c1-m1: null
                                ardana-cp1-c1-m2: null
                                ardana-cp1-c1-m3: null
                    resources:
                        compute:
                            servers:
                                ardana-cp1-comp0001: null

This file provides details of the topology of the cloud from the perspective of each region. In SUSE OpenStack Cloud, multiple regions are not supported. Only Region0 is valid.

regions:
  REGION-NAME:
      control-planes:
          CONTROL-PLANE-NAME:
              services:
                 SERVICE-NAME:
                     LIST OF SERVICE COMPONENTS

Example:

regions:
    region0:
        control-planes:
            control-plane-1:
                services:
                    barbican:
                    - barbican-api
                    - barbican-worker
                    ceilometer:
                    - ceilometer-common
                    - ceilometer-agent-notification
                    - ceilometer-polling
                    cinder:
                    - cinder-api
                    - cinder-volume
                    - cinder-scheduler
                    - cinder-backup

This file provides details of the topology of the cloud from the perspective of each service:

services:
    SERVICE-NAME:
        components:
            COMPONENT-NAME:
                control-planes:
                    CONTROL-PLANE-NAME:
                        clusters:
                            CLUSTER-NAME:
                                LIST OF SERVERS
                        resources:
                            RESOURCE-GROUP-NAME:
                                LIST OF SERVERS
                        regions:
                            LIST OF REGIONS

This file provide details of the secrets that are generated by the configuration processor. The details include:

  SECRET
      METADATA
           LIST OF METADATA
               CLUSTERS
                   LIST OF CLUSTERS
               COMPONENT
               CONSUMES
               CONTROL-PLANE
       VERSION

For example:

barbican_admin_password:
    metadata:
    -   clusters:
        - cluster1
        component: barbican-api
        cp: ccp
    version: '2.0'
keystone_swift_password:
    metadata:
    -   clusters:
        - cluster1
        component: swift-proxy
        consumes: keystone-api
        cp: ccp
    version: '2.0'
metadata_proxy_shared_secret:
    metadata:
    -   clusters:
        - cluster1
        component: nova-metadata
        cp: ccp
    -   clusters:
        - cluster1
        - compute
        component: neutron-metadata-agent
        cp: ccp
    version: '2.0'
    …

This file provides details equivalent to those in private_data_metadata_ccp.yml for passwords which have been changed from their original values, using the procedure outlined in the SUSE OpenStack Cloud documentation

This file provides details of the server allocation and network configuration decisions the configuration processor has made. The sequence of information recorded is:

Example:

        Add required services to control plane control-plane-1
        ======================================================
        control-plane-1: Added nova-metadata required by nova-api
        control-plane-1: Added swift-common required by swift-proxy
        control-plane-1: Added swift-rsync required by swift-account

        Allocate Servers for control plane control-plane-1
        ==================================================

        cluster: cluster1
        -----------------
          Persisted allocation for server 'controller1' (AZ1)
          Persisted allocation for server 'controller2' (AZ2)
          Searching for server with role ['CONTROLLER-ROLE'] in zones: set(['AZ3'])
          Allocated server 'controller3' (AZ3)

        resource: compute
        -----------------
          Persisted allocation for server 'compute1' (AZ1)
          Searching for server with role ['COMPUTE-ROLE'] in zones: set(['AZ1', 'AZ2', 'AZ3'])

        Resolve Networks for Servers
        ============================
        server: ardana-cp1-c1-m1
        ------------------------
          add EXTERNAL-API for component ip-cluster
          add MANAGEMENT for component ip-cluster
          add MANAGEMENT for lifecycle-manager (default)
          add MANAGEMENT for ntp-server (default)
          ...
          add MANAGEMENT for swift-rsync (default)
          add GUEST for tag neutron.networks.vxlan (neutron-openvswitch-agent)
          add EXTERNAL-VM for tag neutron.l3_agent.external_network_bridge (neutron-vpn-agent)
          Using persisted address 10.0.1.2 for server ardana-cp1-c1-m1 on network EXTERNAL-API-NET
          Using address 192.168.10.3 for server ardana-cp1-c1-m1 on network MANAGEMENT-NET
          Using persisted address 10.1.1.2 for server ardana-cp1-c1-m1 on network GUEST-NET

        …
        Define load balancers
        =====================

        Load balancer: extlb
        --------------------
          Using persisted address 10.0.1.5 for vip extlb ardana-cp1-vip-extlb-extapi on network EXTERNAL-API-NET
          Add nova-api for roles ['public'] due to 'default'
          Add glance-api for roles ['public'] due to 'default'
          ...

        Map load balancers to providers
        ===============================

        Network EXTERNAL-API-NET
        ------------------------
          10.0.1.5: ip-cluster nova-api roles: ['public'] vip-port: 8774 host-port: 8774
          10.0.1.5: ip-cluster glance-api roles: ['public'] vip-port: 9292 host-port: 9292
          10.0.1.5: ip-cluster keystone-api roles: ['public'] vip-port: 5000 host-port: 5000
          10.0.1.5: ip-cluster swift-proxy roles: ['public'] vip-port: 8080 host-port: 8080
          10.0.1.5: ip-cluster monasca-api roles: ['public'] vip-port: 8070 host-port: 8070
          10.0.1.5: ip-cluster heat-api-cfn roles: ['public'] vip-port: 8000 host-port: 8000
          10.0.1.5: ip-cluster ops-console-web roles: ['public'] vip-port: 9095 host-port: 9095
          10.0.1.5: ip-cluster heat-api roles: ['public'] vip-port: 8004 host-port: 8004
          10.0.1.5: ip-cluster nova-novncproxy roles: ['public'] vip-port: 6080 host-port: 6080
          10.0.1.5: ip-cluster neutron-server roles: ['public'] vip-port: 9696 host-port: 9696
          10.0.1.5: ip-cluster heat-api-cloudwatch roles: ['public'] vip-port: 8003 host-port: 8003
          10.0.1.5: ip-cluster horizon roles: ['public'] vip-port: 443 host-port: 80
          10.0.1.5: ip-cluster cinder-api roles: ['public'] vip-port: 8776 host-port: 8776

This file provides a pictorial representation of the cloud. Although this file is still produced, it is superseded by the HTML output described in the following section.

An HTML representation of the cloud can be found in ~/openstack/my_cloud/html after the first Configuration Processor run. This directory is also rebuilt each time the Configuration Processor is run. These files combine the data in the input model with allocation decisions made by the Configuration processor to allow the configured cloud to be viewed from a number of different perspectives.

Most of the entries on the HTML pages provide either links to other parts of the HTML output or additional details via hover text.