OpenStack IaaS on Documentation

Announcements

Mon, 01 Jan 0001 00:00:00 +0000

2026-02-04 ECP OpenStack IaaS

Mandatory idp for OpenStack IaaS

For a better and more secure user experience we will require all users in OpenStack IaaS to authenticate against the Elastx identity provider (IdP). Multi Factor Authentication (MFA) is required and you can use either TOTP or hardware keys in combination with a password. This is also a preparation for the launch of the Elastx Cloud Console (ECC). With the Elastx IdP you will have one account to access all ECP services.

Overview

Mon, 01 Jan 0001 00:00:00 +0000

ELASTX OpenStack IaaS consists of a fully redundant installation spread over three different physical locations (openstack availability zones) in Stockholm, Sweden. Managed and monitored by us 24x7. You also have access to our support at any time.

The current setup is based on the OpenStack version Yoga.

Services

Our OpenStack environment currently runs the following services:

Keystone - Authentication service
Nova - Compute service
Neutron - Network service
Heat - Orchestration service
Horizon - Dashboard
Glance - Image store. We provide images for the most popular operating systems. All Linux images are unmodified from the official vendor cloud image.
Barbican - Secret store service which is powered by physical HSM appliances
Octavia - Load balancer service, barbican integration for SSL termination
Cinder - Block storage with SSD based block storage and guaranteed IOPS reservations which is integrated with Barbican for optional encrypted volumes.
Swift - Object storage
Ceilometer - Metric storage, stores key metrics for the services like cpu and memory utilization
CloudKitty - Rating service

Quotas

These are our default project quotas, let us know if you wish to change these upon ordering. Contact support to have quotas changed on an existing project.

Network

Mon, 01 Jan 0001 00:00:00 +0000

Overview

The OpenStack tenant networks is implemented as a shared L2 between all availability zones and is tightly integrated with our network infrastructure. Routing is handled by anycast routing in the switch infrastruture which makes the network extremely performant with low consistent latency.

Special considerations

Router Egress NAT

Egress NAT is distributed and handled by the local hypervisor which means that unless a floating ip is associated with a instance it will utilize the public ip-address of the hypervisor where the instance is currently running. If the public ip-address of the instance needs to be known, e.g. needs to be provided to a 3rd party for firewall rules or likewise a floating ip needs to be associated with the instance.