Cloud resource management basics

BMC Cloud Lifecycle Management uses the concept of network pods and containers to enable networking configurations that support a variety of use cases for cloud deployments. Network containers are used to build isolated networking environments, enabling tenant isolation, workload isolation, and data security zones. BMC Cloud Lifecycle Management supports out-of-the-box network container blueprints based on cloud network topologies jointly developed with Cisco.

This topic contains the following sections:

Networking rules in BMC Cloud Lifecycle Management

The following rules govern network management in BMC Cloud Lifecycle Management:

• A cloud is composed of one or more locations.
• Each location contains one or more pods.
• Each pod contains one or more network containers. A cloud tenant can be assigned one or more network containers. Through policy, a network container is selected based on the end user requesting a service.
• Each network container contains one or more network zones. Each Zone can contain a load balancer and firewall to create security and balancing of workloads that exist within the Zone.
• Each network zone contains one or more networks, which can span network zones, network containers, and pods.

Cloud tiers

Logically, a cloud network is organized into the following tiers:

• Control tier — Represents a set of infrastructure resources required to operate, administer and maintain the cloud infrastructure and the applications hosted in the cloud.
• Workload tier — Represents a set of infrastructure resources used for application hosting.

Infrastructure resources within the tiers can be physical or virtual. Typically, physical resources are dedicated for use within a single tier. Virtual resources can be either dedicated for use within a single tier or shared between tiers, depending on the level of availability and security required of the cloud. Physically, each tier is composed of one or more network pods. The tiers and their pods can be co-located or span multiple geographic locations.

Cloud tiers

Role-based access

BMC Cloud Lifecycle Management users have access to networking capabilities based on their role:

• Cloud administrators have full access to all network containers within the cloud environment.
• Cloud organization administrators can request service instances, and can manage their own deployed service instances and the service instances belonging to users in that organization.

• Cloud end users can manage the addition and removal of load balancers on a per-compute basis, and manage firewall rules on a per-server basis. By default, cloud end users cannot select the following things, all of which are based on policies configured by the cloud administrator:
  • Specific network containers for provisioning
  • Specific zones
  • Specific networks

Provisioning to network containers

BMC Cloud Lifecycle Management uses cloud-administrator defined policies and object tags to help make placement decisions per service instance. Using service blueprints, a cloud administrator can define multi-tier application environments composed of one or more functional components and the connections between them. From a deployment model perspective, a cloud administrator can define policies that allow a multi-tier application to:

• Deploy individual functional components across multiple zones in a network container.
• Deploy functional components into one or more networks within each zone.

This gives the cloud administrator flexibility in creating their networking environment to support simple, single server deployments or more complex application deployments. For example, a cloud administrator could use BMC Cloud Lifecycle Management networking capabilities to support the deployment of a multi-tier app in the following ways:

• Deploy using multiple zones — A cloud administrator could configure a multi-tier application with isolation between application components by using multiple zones. For example, a 3-tier application could be provisioned into a network container with each component going into 1 of 3 zones that each have their own firewalls.
• Deploy using multiple networks — Another way to solve the same use case is to have a network container with only a single zone, with the zone itself mapped to more than one network. In this case, each application component would be provisioned to a different network within the zone.
• Deploy using a combination of multiple zones and multiple networks.

Related topics

Tenant management overview
Network resources overview
User roles
Resource provider overview
Resource types