Network

The HPC Cloud supports virtual network resources such as routers, floating ips, and security groups, which, together with the physical and virtual networks themselves form the communication infrastructure needed by compute instances.

Hint

Networking topics can become quite complex, but many use cases are already covered by local networks combined with the appropriate security group rules. Thus, you may want to skip directly to those sections.

Shared Networks

The HPC Cloud offers multiple shared networks, summarized in the table below. These networks allow communication between projects (only if explicitly allowed by security group rules) as well as traffic to and from the HPC Cloud (subject to some restrictions explained below). IP addresses are assigned randomly from the pool but typically won’t change over the lifetime of the port, i.e. as long as the instance or floating ip is not deleted or released, respectively.

Network	Address Range	Routing	Availability	Supported Port Types
cloud-local-1	10.186.1.XX	mpcdf campus/vpn	all projects	instances
cloud-local-2	10.186.2.XX	mpcdf campus/vpn	all projects	instances
cloud-local-float	10.186.7.XX	mpcdf campus/vpn	all projects	floating ips, routers
cloud-public	130.183.217.XX	global	on request	floating ips, routers, instances 1

Local Networks

The cloud-local networks provide each server with an IP address in the 10.186.XX.XX range and support connections from internal MPCDF networks without the need for a project-specific gateway or jumphost. Note that the reverse is not the case; in general servers on these networks can connect to publicly-available services such as gitlab and datashare, as well as the public internet 2, but not Raven, local clusters, etc. The cloud-local-float network has similar properties but is normally used in combination with private networks.

Public Network

The HPC Cloud includes a single globally-routed network cloud-public for the purpose of hosting internet-accessible services. Access is granted per-project, based on requirements and a discussion between the responsible local admins and MPCDF. In practice this network is normally used via floating ips which are attached to an instance running on a local (or private) network. 1

Automated domain name service (DNS)

Hostnames are now automatically generated for most devices attached to the public or local cloud networks, including virtual machines and floating IP addresses. The system works like this:

1. Each virtual machine is assigned a hostname of the following form:

   VM_NAME.PROJECT_NAME.hpccloud.mpg.de

   If the name of the virtual machine is invalid according to the requirements of DNS, then a unique hostname based on the fixed IP address will be substituted automatically.

2. Each floating IP is assigned a hostname of the following form:

   FIP_DESCRIPTION.PROJECT_NAME.hpccloud.mpg.de

   If the description field is empty or invalid, then a unique hostname based on the floating IP address will be substituted automatically.

3. Hostnames are synchronized with the MPCDF DNS servers every five minutes. For devices on the public cloud network, both forward and reverse entries are propagated to the global DNS, whereas on local networks only the forward (i.e. hostname->IP address) entries are published.

Thus, within the framework described above it is possible to deploy and configure many applications on the HPC-Cloud without tracking individual IP addresses.

Private Networks and Routers

Private networking is available to meet more complex requirements, as well conserve IP addresses on the shared networks. The following steps correspond to a typical use case, but by no means cover all the possibilities.

1. Create a new network and associated subnet via on Project / Network / Networks, specifying 192.168.0.0/24 as the network address and 130.183.9.32, 130.183.1.21 (one per line) as the DNS name servers.

2. Create a new router via on Project / Network / Routers, choosing either cloud-local-float or cloud-public (if available) as the external network.

3. Select the router, switch to the “Interfaces” tab, and click to add a port in the newly-created subnet.

CLI Example

openstack network create NETWORK
openstack subnet create SUBNET --network NETWORK --subnet-range 192.168.0.0/24 --dns-nameserver 130.183.9.32 --dns-nameserver 130.183.1.21
openstack router create ROUTER
openstack router set ROUTER --external-gateway cloud-local-float
openstack router add subnet ROUTER SUBNET

You can now launch instances on the private network, but there is no way to reach the network from outside, and therefore no way to login! 3 To get around this limitation, attach a floating ip to at least one of the servers in the private network.

Floating IPs

Floating ips give a server an alternate ip address without reconfiguring the server itself. This works because the software-defined networking layer implements a one-to-one translation between the fixed address that the operating system “sees” and the floating address. Note that the fixed address will continue to be usable inside the local (or private) subnet, while all other hosts must use the floating ip. 4

1. Reserve a floating ip via on Project / Network / Floating IPs, selecting either cloud-local-float or cloud-public (if available) as the pool.

2. Select the floating ip, click , and then choose the primary port of the target instance.

Attention

The floating ip’s pool must match the router gateway to successfully associate with a server:

• For servers on local networks, only floating ips from cloud-public can be used.

• For servers on private networks, it depends on which external network was chosen for the private router – see step 2 above.

CLI Example

openstack floating ip create cloud-local-float
openstack server add floating ip SERVER 10.186.7.XX

Security Groups

The HPC Cloud provides a flexible per-instance, network-based access control mechanism in the form of security groups. The default security group allows connections between instances in the same project (and network), plus SSH from internal MPCDF networks and ping from anywhere.

Attention

The default security group allows SSH ingress from all other hosts in the cloud networks and from other machines at MPCDF. While this is convenient you may want to limit access by using your own security groups.

The recommended way to “open” additional ports is as follows:

1. Create a new group via on Project / Network / Security Groups.

2. Select the group, choose , followed by , and then add one or more rules, e.g.:

   • Rule: Custom TCP Rule

   • Direction: Ingress

   • Port: 80

   • CIDR: 0.0.0.0/0

3. Select the desired instance on Project / Compute / Instances, choose , and then add the newly created security group. In most cases you should keep, rather than replace, the default security group, unless your new security group includes rules for all necessary ingress and egress traffic.

CLI Example

openstack security group create SECGROUP
openstack security group rule create SECGROUP --protocol tcp --dst-port 80
openstack server add security group SERVER SECGROUP

One thing to keep in mind is that what traffic unlimately reaches the server is determined by the properties of the network and the security group rules. For example, since cloud-local networks are not globally routed, opening a port to all sources only affects traffic from other MPCDF networks. Adding a public floating ip, however, changes the situation dramatically. Thus, it is good practice to choose the CIDR carefully, rather than relying exclusively on the network topology for security.

1(1,2)

Certain applications do not support floating ips, since the operating system detects only the fixed address. On request, it is technically possible to place an instance directly on the public network.

2

Internet access is provided via a NAT gateway. The external address of the gateway (currently 130.183.254.22) may change and should not be used for access control.

3

Unlike many routers used for home internet service, the software-defined routers in the HPC Cloud do not support port forwarding, i.e. directing incoming traffic on a particular port to particular local “behind” the router.

4

One might wonder if local peers can communicate with the floating ip as well. For private networks the answer is yes; for local networks the answer is no.