Overview

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 Ussuri.

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 except CentOS are unmodified from the official vendor cloud image. For CentOS we have changed out xfs file system to ext4 for stability reasons. You can find source code for our CentOS build process here.
• Barbican - Secret store service which is powered by physical HSM appliances by Fortanix HSM and KMS solution for OpenStack
• 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.

• VCPUs: 20
• Memory (RAM) 51200MB
• Volumes: 1000
• Volume snapshots: 1000
• Total size of volumes and snapshots: 1000 GiB
• Security groups: 50
• Security group rules: 1000
• Floating IPs: 10
• Routers: 1
• Networks: 10
• Subnets: 100
• Ports: 500

Differencies and limitations

As every OpenStack cloud has it’s own unique set of features and underlying infrastructure, there are some things that might differentiate in our cluster from others. Down below is a list of what we believe is good to know when working in our OpenStack cloud.

Compute

• Live migration is not supported.
• An instance with volumes attached cannot be migrated to another Availability Zone.
• Machines booting from ephemeral storage cannot use an image larger than 64GiB, especially important if booting from snapshot.

Dashboard

• Objects in Object store cannot be listed in Horizon once an account has >1000 buckets or >10000 objects in it.

Load Balancing

• It’s not possible to limit access to a Load Balancer instance with a Floating IP attached to it.
• A Load Balancer cannot be referenced by ID as a source in a Security Group.

Network

• Maximum of one router per project. We only support a single router due to how resources are allocated in our network infrastructure.
• An instance cannot connect to its own Floating IP. Best practice is to use internal IP when communicating internally (e.g. clustering).
• The network elx-public1 is provided by the platform and cannot be removed from a project. You can attach an interface on your router on this network for internet access. This is also used as a pool for requesting Floating IP addresses.

Object store

• To upload objects larger than 5GiB, use of DLO/SLO is necessary to split the object in multiple smaller parts. See https://docs.openstack.org/swift/latest/overview_large_objects.html.
• python-swiftclient is not correctly adding headers to segmented files which cause fragments to remain when using ‘X-Delete-After’ header to automatically delete objects after a certain time has passed. This isn’t unique to our cloud but we feel that it’s important to know. See https://bugs.launchpad.net/python-swiftclient/+bug/1159951.

Secrets

• Secrets can only be deleted by the user that created them.

Storage

• Volumes cannot be attached nor migrated across Availability Zones.
• Encrypted volumes can only be deleted by the user that created them.
• It’s not supported to snapshot the ephemeral volume of dedicated instances (flavour with dedicated in name).
• Encrypted volumes need to be detached and attached manually for instances to discover the new volume size when resizing.
• When making a backup use only single line for description. There is a bug that fails the process if you use more than one line.

Windows

Due to the large size of Windows images, there’s a limitation when creating a Windows instance with a volume as a boot disk.
The size of windows images requires more time during creation which tend to lead to timeouts when the volume is being created.
We recommend to use the disk included in the flavor as a boot disk and then create volumes as secondary storage if needed.