Skip to content

Introduction

The core element of the customer oriented Infrastructure as a Service (IaaS) provided by STACKIT is the STACKIT Server. This provides the generic and adaptive platform for demanding customers to intuitively deploy and use IT infrastructure according to individual needs.

The STACKIT IaaS team follows the guiding principle “Simplex - simplifying complex IT infrastructure” on behalf of customers. This enables customers to focus on their core business, while STACKIT manages the cloud - simply, securely, and reliably.

The STACKIT virtual machine consists of a processor (vCPU), memory (RAM), storage (Block Storage) and an operating system (OS Image). The customer can choose the optimum server for its application from a wide range of prefabricated variations (machine types). The provisioning of the STACKIT virtual machine is fully automated. As a customer, you have the choice between provisioning via Portal or via application programming interface (API).

You can find the related step-by-step instructions here: Creating a new STACKIT Server

Start managing your STACKIT Server with confidence - use the portal or API to create, update, or remove them as needed.

The creation of a Server requires the selection of

  • a host name
  • an image
  • a machine type

You can define additional IP settings, additional storage devices or security groups. You can define additional IP settings, storage devices, or security groups during creation and modify them later.

If you no longer need one or more servers, you can easily delete them at any time.

You can also change the server’s settings at any time. You can always bypass restrictions in the modification options (for example an image used in the context of an existing STACKIT Server can’t be changed afterwards). This can be achieved by creating a new STACKIT Server and deleting the old STACKIT Server (you may have to transfer data from the old system to the new one).

The administration of existing STACKIT Servers is straightforward. This means that starting, stopping and restarting servers can easily be done via the Portal. These and other functions (for example pausing servers) can also be automated via API.

When stopping or pausing servers, resources are still reserved for immediate use. Therefore, the offsetting also takes place for the entire period from the creation of the STACKIT Server to the deletion of the STACKIT Server. It’s advised to delete unneeded servers to reduce costs.

When a STACKIT Server is created, it will be allocated on physical hardware. Stopping the STACKIT Server won’t remove the allocation and keep all its resources reserved for faster startup. Deallocating corresponds to stopping the STACKIT Server and removing its allocation. In this case, the resources for a STACKIT Server are no longer reserved and therefore not billed. Deallocating doesn’t delete the STACKIT Server or its resources.

Deallocating will first send a shutdown signal to the STACKIT Server to enable a graceful shutdown within a short period of time before the STACKIT Server is powered off.

As with the straightforward creation and management of servers, access is also seamless. The system can be activated for access via the internet using security groups. For example via SSH, VPN on this server, encrypted connections or similar, well-protected access protocols.

If access to the system from the internet is necessary, this can be achieved by using public IP addresses (Public IP Address).

You can find the related step-by-step instructions here: How to access your server using the web console

Systems that aren’t to be accessed via the internet can best be managed via other systems in the same project or network. You can alternatively use the available web console by means of an internet browser to log in with a user name and password. It’s an emulated remote console that can be compared to a keyboard directly on the server.

By default, STACKIT virtual machines only receive internal IP addresses. If required, you can add public IP addresses at any time (see Public IP Address). In this case, pay special attention to the correct firewall settings (Create and manage Security Groups).

More information about the network can be found here: Virtual Network

Snapshots of volumes/datastores and servers (incl. cloning)

Section titled “Snapshots of volumes/datastores and servers (incl. cloning)”

The backups and snapshots feature is currently being integrated into the Portal and will be available soon (see FAQ).

Snapshots can be created for existing volumes/datastores – but also for entire servers with STACKIT. However, these snapshots can’t be restored in-place, but can for example be used with a new STACKIT Server or new volumes. This makes it possible to restore a previous status from a snapshot without losing the current status of the STACKIT Server/volumes. If the current status is no longer needed, the STACKIT Server or volume can be deleted in a separate step afterwards. The same applies to snapshots that are no longer needed – these can also be deleted at any time.

From a technical standpoint, snapshots always refer to volumes/datastores. If snapshots are created for servers, then a snapshot is automatically created for each of the attached volumes/datastores. The snapshot is stored in the same primary storage system as the original volume. To achieve a high-performance recovery of the snapshots, the snapshots are created with the same size as the original volume.

If snapshots are no longer needed after creation, they can be deleted. Any dependencies between the snapshots (snapshot from snapshot, etc.) are automatically resolved by the system.

It’s also possible to download or upload snapshots via the IaaS-API. Details can be found on the IaaS-API page.

You can also create backups for volumes. These backups can be created either as a full backup or as an incremental backup. This section refers to the full backup. Full backups contain the entire data of the original volume. Unlike snapshots, backups can be restored in-place - that is, restored overwriting the original volume. But it’s also possible to restore a backup to a new volume (of the same size) and continue to use the original volume unchanged.

The recommendation is that the STACKIT Server with the volume is switched off or the volume isn’t connected to create backups. Otherwise, the backup is merely crash-consistent and possibly in an undesirable status.

Due to the separation of primary and backup storage, the backups are automatically located on a separate backup storage system. Check Regions and AZs Block Storage for more details. This is different to the storage of snapshots. Thus, the backups are secured independently of the primary storage. To achieve a high-performance recovery of the backups, the backups are created with the same size as the original volume.

The creation of full backups requires a relatively high effort depending on the original volume. This can be reduced by creating incremental backups when backups are created frequently. Incremental backups always refer to a full backup, so a full backup must be performed before incremental backups can be created.

Incremental backups contain only data changes compared to the last (full or incremental) backup created before the backup. On the other hand, a full backup can be restored in a smaller period of time, because there is no need to match all incremental backups.

Security groups (local firewalls for hosts)

Section titled “Security groups (local firewalls for hosts)”

You can find the related information under Virtual Network.

To protect its systems, the customer must define and set up security groups. With these security groups, the customer can independently implement firewall-based network security. Security groups consist of a set of security rules (e.g firewall rules) and can be defined for each virtual machine. The default set of rules is that all outgoing traffic is allowed and all incoming traffic is prohibited. The prohibition of incoming traffic doesn’t apply to traffic from systems in the same security group. This means that incoming traffic must always be explicitly allowed before it’s possible. This prevents possible access from outside if someone forgets to set security groups.

The traffic is configurable with respect to the different protocols. Specific ports (or port ranges) and the communication direction (incoming/outgoing) can be configured too. Furthermore, the communication direction can be restricted to specific hosts/networks via IPv4 or IPv6.

The security groups aren’t visible on the hosts themselves, but they apply to the traffic coming from and going to the STACKIT Server via the gateway.

Also, security groups can be used for different servers at the same time, with changes to the security group affecting all servers using them at the same time. In this way, for example, Security Groups for all WebServers can be controlled globally and used multiple times.

Changing, deleting and modifying security groups

Section titled “Changing, deleting and modifying security groups”

You can find the related step-by-step instructions here: Create and manage security groups

The previously mentioned security groups can be created, modified or deleted as separate objects independently of the server creation. If a security group is subsequently modified, this modification immediately affects all systems to which this security group was assigned.