Strategies for Network Administration in Oracle^® Solaris 11.4

Combining Network Virtualization With Oracle VM Server for SPARC

The following scenario combines network virtualization features with Oracle VM Server for SPARC to create a multilevel virtual network that parallels a cloud environment. This deployment method provides highly efficient, enterprise-class virtualization capabilities for Oracle's SPARC T-Series servers and supported M-Series servers.

This scenario assumes that you are running an Oracle VM Server for SPARC version that supports Oracle Solaris 11.4.

At a high level, the objective of this scenario is to set up a SPARC based system into multiple Oracle Solaris VM Server guest domains, where each domain corresponds to a node within a cloud environment. You can deploy per-tenant workloads as zones within these Oracle VM Server for SPARC guest domains.

Configuring network virtualization features in this way enables you to build an entire cloud within a single SPARC based system. You can also use this type of configuration to integrate a SPARC based system into a larger cloud environment, where the system appears as a set of nodes within that environment.

Combining network virtualization features with Oracle VM Server for SPARC parallels a traditional cloud in the following ways:

• Compute nodes are implemented as Oracle VM Server for SPARC guest domains

• Compute nodes communicate with each other through the virtual network infrastructure that is provided by Oracle VM Server for SPARC, and Oracle Solaris running on the service domain

• The vnet driver instances (a private virtual network assigned to one of the tenants of a shared infrastructure) that are within each guest domain correspond to a physical NIC within a physical compute node

This type of configuration has the following benefits:

• Provides more flexibility by enabling you to run smaller domains that you can upgrade individually without affecting other workloads that are running on the system

• Takes advantage of SPARC Reliability, Availability, and Serviceability (RAS) features

• Uses a faster virtual network for communication between nodes instead of relying on a physical infrastructure

The following figure illustrates the two distinct levels of network virtualization that you create with this configuration.

Figure 4  Network Virtualization Configured on Oracle VM Server for SPARC

On the first level, you configure network virtualization features that are supported by Oracle VM Server for SPARC. This part of the network virtualization combines Oracle VM Server for SPARC configuration with the Oracle Solaris OS that is running on the service domain. The vnet configuration takes place at this first level of virtualization. Because the configuration only relies upon IP connectivity from the guest domains, no additional support from Oracle VM Server for SPARC is required for the configuration on the second network virtualization level to work.

On the second level, EVS is used to create elastic virtual switches across the guest domains. EVS is configured to use the vnet interfaces as uplinks. VXLAN datalinks are automatically created by EVS from each guest domain and then used to encapsulate the traffic of the individual elastic virtual switches.

The figure represents the following configuration details:

• Two physical NICs, nxge0 and ixgbe0, which are directly assigned to the service domain where they are represented by datalinks net0 and net1

• To provide high availability in case of failure of the physical NICs, net0 and net1 in the service domain are grouped into the DLMP aggregation, aggr0

• The aggregation, aggr0, is then connected to an Oracle VM Server for SPARC virtual switch in the service domain named vsw0

  Two VNICs, ldoms-vsw.vport0 and ldoms-vsw.vport1, are automatically created by vsw0, with each VNIC corresponding to the Oracle VM Server for SPARC vnet instances within the guest domains

• The vsw0 and the vnet instances communicate with each other through the hypervisor by using Logical Domain Channels (LDCs)

• Each guest uses its instance of the vnet0 driver, which appears in the guest domain as a datalink, net0, for the purpose of communicating with other guest domains and the physical network

• In each guest domain, the vnet datalinks for net0 are configured with the IP interface net0/v4

• Each guest domain is an EVS compute node, with three EVS switches, vswitch_a, vswitch_b, and vswitch_c, that are configured from the EVS controller (not shown in the figure)

• EVS is configured to use a VXLAN as its underlying protocol. For each guest domain that uses an elastic virtual switch, EVS automatically configures a VXLAN datalink. These VXLAN datalinks are named evs-vxlanid, where id is the VXLAN ID that is assigned to the virtual switch

• In the guest domains, Oracle Solaris Zones are configured to run the tenants' workload. Each zone is connected through a VNIC and a virtual port (not shown in the figure) to one of the EVS switches

• The zones, Zone-B-1 and Zone-B-2, belong to the same user and are running on two different guest domains. The EVS switch, vswitch_b, is instantiated on both guest domains. From the two zones' perspective, it appears as if each zone is connected to a single Ethernet segment that is represented by vswitch_b and isolated from the other virtual switches

• EVS automatically creates the VXLAN datalinks that are needed by the various elastic virtual switches. For example, for vswitch_b, EVS automatically creates a VXLAN datalink named evs-vxlan201 on each of the guest domains

For reference, see the following resources:

• Managing Network Virtualization and Network Resources in Oracle Solaris 11.4

• Creating and Using Oracle Solaris Zones

• Oracle VM Server for SPARC (https://docs.oracle.com/en/virtualization/oracle-vm-server-sparc/)