SuperCluster M8 and SuperCluster M7 support a variety of isolation strategies that cloud providers select based upon their security and assurance requirements. This flexibility allows cloud providers to create a customized, secure multitenant architecture that is tailored for their business.
SuperCluster M8 and SuperCluster M7 support a number of workload isolation strategies, each with its own unique set of capabilities. While each implementation strategy can be used independently, they can also be used together in a hybrid approach allowing cloud providers to deploy architectures that can more effectively balance their security, performance, availability needs, and other needs.
Figure 1 Secure Isolation with a Dynamic Tenant Configuration
Cloud providers can use physical domains (also called PDomains) for situations in which their tenant hosts are running applications and databases that must be physically isolated from other workloads. Dedicated physical resources might be required for a deployment due to its criticality to the organization, the sensitivity of the information it contains, compliance mandates, or even simply because the database or application workload will fully utilize the resources of an entire physical system.
For organizations that require hypervisor-mediated isolation, Oracle VM Server for SPARC domains, referred to as dedicated domains, are used to create virtual environments that isolate application and/or database instances. Created as part of the SuperCluster installation, dedicated domains each run their own unique instance of the Oracle Solaris OS. Access to physical resources is mediated by the hardware-assisted hypervisors built into the SPARC processors.
In addition, SuperCluster enables you to create additional domains referred to as root domains, which leverage single root I/O virtualization (SR-IOV) technology. Root domains own one or two IB HCAs and 10 GbE NICs. You can choose to dynamically create additional domains, referred to as I/O domains, on top of root domains. SuperCluster M7 and SuperCluster M7 includes a browser-based tool to create and manage them.
Within each of these domains, however, cloud consumer tenants can leverage Oracle Solaris Zones technology to create additional isolated environments. Using zones, it is possible to deploy individual application or database instances or groups of application or database instances into one or more virtualized containers that collectively run on top of a single OS kernel. This lightweight approach to virtualization is used to create a stronger security boundary around deployed services.
Tenants hosting multiple applications and databases on SuperCluster can also choose to employ a hybrid approach, using a combination of isolation strategies based on Oracle Solaris Zones, I/O domains, and dedicated domains to create flexible yet resilient architectures that align to their cloud infrastructure needs. With a host of virtualization options, SuperCluster enables cloud-hosted tenants to be securely isolated at the hardware layer, and it provides Oracle Solaris Zones for enhanced security and further isolation in the runtime environment.
Ensuring that individual applications, databases, users, and processes are properly isolated on their host OS is a good first step. However, it is equally important to consider the three primary networks used in the SuperCluster and how the network isolation capabilities and communications flowing over the network are protected:
10 GbE Client access network
Private IB service network
Management network
The network traffic flowing over the SuperCluster client access network can be isolated using a variety of techniques. In this figure, one possible configuration is shown in which four database instances are configured to operate on three distinct virtual LANs (VLANs). By configuring the network interfaces of SuperCluster to use VLANs, network traffic can be isolated between Oracle VM Server for SPARC dedicated domains as well as between Oracle Solaris Zones.
Figure 2 Secure Network Isolation Over the Client Access Network
SuperCluster includes a private IB network that is used by database instances to access the information stored on the Exadata storage servers and the ZFS storage appliance,and to perform the internal communications needed for clustering and high availability. This illustration shows secure network isolation on SuperCluster M8 and SuperCluster M7.
Figure 3 Secure Network Isolation on the 40 Gbs IB Network
By default, the SuperCluster IB network is partitioned into six distinct partitions during installation and configuration. While you cannot change the default partitions, Oracle does support the creation and use of additional dedicated partitions in situations where further segmentation of the IB network is required. In addition, the IB network supports the notion of both limited and full partition membership. Limited members can communicate only with full members, whereas full members can communicate with all nodes on the partition. The application I/O domains and Oracle Solaris 11 Zones can be configured as limited members of their respective IB partitions ensuring that they are able to communicate only with the ZFS storage appliance, which is configured as a full member, and not with other limited membership nodes that might exist on that same partition.
SuperCluster also includes a dedicated management network through which all of its core components can be managed and monitored. This strategy keeps sensitive management and monitoring functions isolated from the network paths that are used to process client requests. By keeping the management functions isolated to this management network, SuperCluster can further reduce the network attack surface that is exposed over the client access and IB networks. Cloud providers are strongly encouraged to follow this recommended practice and isolate management, monitoring, and related functions so they are accessible only from the management network.