IBM Cloud Orchestrator, Version 2.5

Network planning

Public Cloud Gateway scenarios require a set of network configuration to successfully provision resources within the remote cloud. This topic provides an overview about which network configuration is assumed and required.

Access to the remote cloud REST API entry points

During the management lifecycle, the Public Cloud Gateway requires access to the remote cloud REST API entry points for:
  • Amazon AWS EC2 REST API.
  • SoftLayer REST API.
  • EC2 provider running in the non-IBM supplied OpenStack environment.
Public Cloud Gateway provides two scenarios for accessing the remote cloud API REST entry points:
  • Direct connection from the IBM Cloud Orchestrator Server where the Public Cloud Gateway connects to the remote entry point.
  • Indirect connection through a customer provided proxy server. See Remote Cloud API proxy configuration under the common configuration tasks (refer to Remote Cloud API proxy configuration).

Connectivity from IBM Cloud Orchestrator management stack to and from provisioned virtual machines

In addition to the remote cloud REST API entry points, communication several management actions require access to the provisioned virtual machine instances. Examples are:
  • Running of scripts.
  • Actions from the Instance View.
In the Public Cloud Gateway scenarios, it is assumed that the connectivity from and to the IBM Cloud Orchestrator management from the virtual machine instance in the remote clouds is provided by the customer. This is an example list of what might be used to establish the communication requirements:
  • Open VPN
  • Amazon EC2 VPN gateway
  • Vyatta / Fortigate Security Appliance (FSA) in SoftLayer
The following network protocols are used:
  • Protocols that are used by any of the agents running on the provisioned virtual machine to their infrastructure servers. For example, Tivoli® Monitoring.
  • For Windows provisioning, RDP port (3389) must be enabled in the security groups on Amazon EC2, when you create the image, and it must be enabled in the Default security group for deployment.
Note: The network requirements must be in place and working before the first provisioning in the remote cloud by using the Public Cloud Gateway.

Amazon AWS EC2 related network planning

This topic covers Amazon AWS EC2 specific network planning topics like:
  • Supported capabilities
  • Assumptions and limitations
  • VPN

Introduction:

Amazon AWS EC2 provides three different network models depending on when the account was created. An account supports either EC2Classic and non-Default VPC or Default and non-Default VPC.

To use all of the capabilities the Public Cloud Gateway supports, it is required to have an actual account that supports Default and non-Default VPC. All accounts that are created after December 2013 are fine. You can check the account capabilities by using the Amazon AWS EC2 console under Account Attributes on the main EC2 Dashboard. If you see Supported Platforms VPC and Default VPC then your account supports all Public Cloud Gateway capabilities.

Supported capabilities:

Amazon AWS EC2 distinguishes between three types of networking models:
  • EC2Classic
  • Default-VPC
  • non-Default VPC
Each of the three networking models has specific capabilities and limitations. Refer to the Amazon Documentation in the EC2 and VPC user guide to understand the main capabilities and limitations. Public Cloud Gateway supports all the three network models. The following table provides a quick overview about the supported capabilities.
Table 1. Supported capabilities of the networking models
Capability EC2Classic Default-VPC Non-Default VPC
Private IP address Yes Yes Yes
Public IP address Yes Configurable per region Configurable per region/project
Hide Public IP address Yes, it is required for VPN setup No, done by setting privateOnly to true No, done by setting privateOnly to true
Set Private Subnet No, EC2Classic defines subnet No, Default VPC defines subnet Yes, Granularity on project or region
Set Security Group No, only Default security for EC2Classic is used No, Default security of default VPC is used Yes, Single Security group on region per project granularity
Elastic IP address No No No
Config On Amazon account level On Amazon account level "vpc" property in config.json on region definition and VPC definition in the Amazon Management portal

Assumptions and limitations:

  • Each virtual machine that is provisioned by Public Cloud Gateway gets a private IP address. The available networking model of the Amazon EC2 Account defines from which subnet the private IP address is derived.
  • Public IP addresses are derived from a global subnet within Amazon AWS EC2. These IP addresses are only assigned to a virtual machine as long as the virtual machine is running. A Stop/Start sequence assigns a new public IP address to the virtual machine. Public IP addresses are realized through NAT and are not reachable through a VPN. Public IP addresses can only be reached through an internet connectivity.
  • Elastic IP addresses are not supported.
  • Only a single security group can be assigned to a virtual machine controlled by a Public Cloud Gateway.
  • For non-Default VPC, only a single subnet or security group must be tagged with a projectUUID or "*" per availability zone. If either multiple or none of the subnets are tagged, provisioning fails. If no security group is tagged, the default security group of the VPC is used.

VPN setup:

Virtual machines can be accessed through a VPN (virtual private network) on their private IP address. Setting up a VPN is out of scope of this documentation. There are various options to set up a VPN within Amazon AWS EC2. For example, VPN support in VPC, using an OpenVPN or IPSEC gateway. It is required to set up the VPN to the private IP address as the public IP addresses are only reachable through an Internet connectivity.

Parent topic: Public Cloud Gateway overview