Introductions

Most universities use visualization today and most of them run their own WMware (or similar) clusters. The next logical step is to outsource the operation of the WMware cluster itself to a hosting provider. There are indications that several universities are thinking about taking this step in the near future and are expecting the NREN to facilitate the transition. The transition from locally managed visualization to remote hosted visualization will take place over the course of several years and may never fully finish - some services may need to reside on locally managed (much smaller) clusters. Hence we need to prepare for a situation where universities sometimes buy visualization service from commercial providers and sometimes use local resources - perhaps shared between collaborating campuses.

In either case a core requirement will be that services can be moved easily between hosting providers, eg between a local to a externally operated cluster as part of a transition process to the commercial vendor or between two commercial vendors when switching vendors. In order for that move to be painless it is imperative to avoid IP renumbering. This in turn implies that the network layer must support private networks on layer 2. Furthermore the number of transitions (eg moves of hosts) will probably be relatively large which means that the provisioning of private layer 2 networks must be available to end-users or at least to university local tech support.

Design Goals

Given the above, the following design-goals follow:

• Support multiple cloud vendors across multiple NRENs
• Easy migration from existing visualization platforms
• Allow for university datacenter networks to be extended to cloud providers
• Low/zero maintenance and end-user tools for provisioning

Network design

• All cloud service providers are connected to the NRENs (eg SUNET) over a transparent MPLS service provided by NORDUNet.
• Private cloud services shared between universities are connected using a similar MPLS service

Service design

The service presented to the end-user should be as simple as possible. There are two basic tools/services

• A tool for network provisioning, i.e setting up a connection between a vlan on the hosting provider to a vlan in the university datacenter
• A tool for host provisioning, i.e setting up resources in the hosting providers clusters

Both tools need to be enabled for federated AAI and integrated into Kalmar2. Procurement of hosting providers must include requirements for AAI integration. Part of the work on the greeqloud PoC involves developing AAI support for OpenStack which is used by greeqloud. In the process we will gather requirements for future RFPs in this field.

The network provisioning tool is basically a (multi-domain) circuit on demand service. We propose to build a simplified single-domain version based on the tail-f configuration management software. Such a tool should be relatively easy to build once we have enough experience working with NCS.