Snapshots for persistent volumes in Kubernetes

Persistent volumes are essential in many Kubernetes setups: they are used to store data that needs to be retained permanently and should not be tied to the lifespan of a pod. Using our CSI driver, it is possible to automatically provision volumes in our cloud infrastructure based on "Persistent Volume Claims" and always attach them to the virtual server where they are currently needed by the corresponding pod.

With the recently released CSI driver 4.0.0 (which includes an additional sidecar component), you can now manage snapshots of your volumes not only manually via our web-based cloud control panel or via API, but also directly from your Kubernetes setup. To do this, the CSI driver uses the standard Kubernetes VolumeSnapshot API and interacts with the cloudscale API to manage your snapshots exactly as your setup requires.

Velero: one of countless use cases

The snapshot support in our CSI driver now makes it even easier for you to create point-in-time copies of persistent volumes in a Kubernetes cluster and restore them should a subsequent operation fail. You can also create new volumes based on snapshots; for example, you can clone a production data set for a test system or mount the new volume to selectively access individual prior data points.

In our engineering blog, Julian walks you through the process step by step, providing all the necessary configurations, to show you how to use Velero and our snapshot feature to save the state of a persistent volume and restore it later. Of course, you can expand on this example as needed and adapt it to your specific use case.

More than just details – please note

Please keep in mind – especially with Velero – that the term "backup" can be used in different ways. At cloudscale, we consider volume snapshots to be ideal for serving as a safety net, enabling a quick and easy rollback to a previous state during database migrations or system upgrades. However, since snapshots are based on "copy-on-write" and are stored in the same storage cluster as their original volume, we do not consider them to be a "backup". For optimal security, we recommend that you always keep a copy of your data at a different geographic location – and ideally on third-party infrastructure.

You will need Kubernetes version 1.28 or later, the Kubernetes Snapshot Controller, and the associated CRDs (which are already present in many setups). Otherwise, the basics are the same as what you are already familiar with from snapshots at cloudscale: Up to 10 snapshots can exist simultaneously per volume, and they are billed – down to the second for the time they exist – based on the volume's size at the time the snapshot was created (at half the per-gigabyte price of a standard NVMe SSD or bulk volume).

At cloudscale, we provide the right tools and interfaces to help you manage your Kubernetes deployments. Our CSI driver with snapshot support has been available as a beta version for some time now, and the feedback has been consistently positive. With the release of version 4.0.0, we now recommend that all customers upgrade; this way, you too can take full advantage of our volume snapshots directly from your Kubernetes setup – using Velero, for example.

Create snapshots using automatic release!
Your cloudscale team

By Matthias Gysi, Presales Engineer, Squirro

Squirro: The AI platform for regulated industries

At first glance, AI looks easy. Type a prompt into a browser, and you immediately get an answer. But when you transfer it to the enterprise, you quickly realize that it isn't that simple. So why are so many businesses hitting a wall as they try to scale experimental PoCs to production? Because most enterprise AI stacks fail to achieve the accuracy, security, and compliance required in real-world, high-stakes deployments.

The Squirro platform provides a secure foundation for generative AI. It lets organizations safely delegate everyday knowledge work, such as writing on-brand content, summarizing dense legal documents, or comparing complex compliance data, while mitigating hallucinations through strict factual grounding. By transforming their disparate data sources into a single source of truth, Squirro helps teams uncover hidden insights and agentically automate entire enterprise workflows, transforming AI into a core business utility that meets the demands of highly regulated industries.

Countering shadow IT with enhanced RAG

By now, we've all seen the value of GenAI in terms of efficiency gains. That's why it's hard to blame those that want to use the technology in their daily activities. But when employees share work-related data with non-approved AI services, so-called shadow IT, they expand the digital attack surface and introduce massive security risks. Data breaches, compliance failures, and the exposure of proprietary IP to third-party model trainers are real threats that can cause lasting reputational damage.

The Squirro enterprise AI platform was built specifically to give organizations a secure, accurate, and permissions-enabled way to integrate GenAI into their operations. Because it uses retrieval augmented generation (RAG) to augment user prompts with data stored in an organization's enterprise platforms, its performance is far beyond what an off-the-shelf large language model can deliver.

But while standard RAG retrieves data from internal and external sources to ground an LLM's outputs, Squirro's enhanced retrieval augmented generation (RAG) stack goes several steps further to enhance accuracy and protect customer data:

• Knowledge Graphs provide deeper deterministic grounding to ensure the AI understands relationships between entities, not just word frequencies.
• Data Virtualization enables real-time integration without needing to constantly ingest fast-changing datasets.
• AI Guardrails ensure that GenAI outputs consistently adhere to corporate policy and regulatory requirements.
• The Privacy Layer automatically masks and scrubs personally identifiable information (PII) before it ever reaches the LLM, enabling the use of state of the art LLMs from US based hosting providers without GDPR violation.
• The Agentic Framework helps users move beyond simple task acceleration to end-to-end workflow execution drawing on your proprietary data.

This provides a compliant alternative to shadow IT, allowing users to leverage generative AI within a secure enterprise framework.

Controlling your destiny with full data sovereignty

Ask business leaders in the DACH region what is holding back AI adoption in their organization, and you'll likely hear a common response: legal anxiety surrounding data privacy. And it goes beyond standard security vulnerabilities. The U.S. Cloud Act, enacted in 2018, creates a jurisdictional gray area by allowing US authorities to request data from any cloud service providers headquartered within its borders, regardless of where that data is physically stored. For the public sector, healthcare, and banking, this isn't just a compliance hurdle, it's a question of data ownership.

Squirro delivers total data sovereignty by giving organizations absolute control over where their data resides. Whether deployed in a Virtual Private Cloud (VPC) or fully on-premises, Squirro ensures sensitive information never leaves your perimeter. Pairing Squirro with cloudscale allows Swiss organizations to scale their AI operations without relying on providers subject to the U.S. Cloud Act.

Scalable data access control management

One of the most overlooked hurdles in Enterprise AI is permissions. If you build a GenAI application that taps into all your corporate data, how do you ensure that a junior analyst doesn't accidentally gain access to the CEO's salary or a confidential M&A memo?

Managing access control lists (ACLs) becomes increasingly complex as organizations scale. Squirro handles this by assigning access-control metadata to each document chunk at the moment of ingestion. Permissions are embedded into the retrievable unit itself. When a user asks a question, the similarity search only returns authorized chunks. If you don't have permission to see the document, the LLM doesn't even know the document exists, preventing unauthorized exposure to third parties.

We have proven this at scale, managing over 10 TB of index data with over 10,000 user groups for a major central bank, proving that security doesn't have to sacrifice performance.

Future-proofing your AI strategy

Combining Squirro and cloudscale provides a turnkey sovereign enterprise AI platform that operates independently of major U.S. hyperscalers. This isn't just about deploying an industry-hardened technology stack; it's about removing the legal and security friction that stalls AI projects in the boardroom.

Ultimately, the choice between AI adoption and sovereignty is a false one. You don't have to trade your data privacy for a productivity boost. By deploying Squirro on cloudscale, you can cut the time it takes to adopt sovereign Enterprise AI, building on a foundation that you, and only you, own.

We've successfully installed Squirro on cloudscale to verify the integration; if you'd like to see how it looks or try a test instance, please get in touch with the Squirro Sales Team.

The next generation

The NVIDIA L40S in our previous GPU servers came with 48 GB of VRAM, and up to four of the GPUs could be used in parallel in a virtual server. The new NVIDIA RTX PRO 6000 Max-Q boasts twice that amount: 96 GB of VRAM per GPU, and here too, you can tap into the power of up to four GPUs in a single server. The physical GPUs are passed through to the virtual server undivided, so that the full performance is dedicated to your use.

Speaking of performance: The RTX PRO 6000 not only offers more VRAM, but also significantly more computing power than the L40S, and we were also impressed by the energy efficiency of the "Max-Q" version. In line with the larger VRAM, we are also equipping our new GPU2 flavors with more memory, which you can combine in various ratios with 16 to 96 dedicated CPU cores. Nothing has changed with the scratch disk: up to 1600 GB of lightning-fast NVMe SSD storage is available locally to minimize latency.

Migrate with care

To switch from a GPU1 server with L40S to a GPU2 server with RTX PRO 6000 Max-Q, in principle, it is sufficient to scale the server to one of the new flavors via the cloud control panel or API. Scaling GPU servers can take a moment, as moving to different physical hardware also requires transferring the contents of your scratch disk.

We recommend, however, that you create a second, new server as a precaution and first make sure that everything works as desired (including the open-source GPU kernel module required for the Blackwell architecture, in Debian/Ubuntu for example the package nvidia-open). You can then migrate the workload to the new server – if you use a Floating IP and/or a load balancer, the IP address will remain the same for your users.

The new, and in some cases considerably cheaper, GPU2 flavors with NVIDIA RTX PRO 6000 Max-Q GPUs have been available for a few days now, and early customer feedback on "real" workloads indicates a significant improvement in performance. We are confident that your application will benefit from our GPU servers too – why not try it out for yourself?

Step it up a notch,
Your cloudscale team

Consolidation of scattered cost data

A virtual server at cloudscale can have up to 128 volumes – this means that PVs in a Kubernetes setup can be provisioned using CSI exactly where the pods need them. In the cloud control panel, the corresponding storage costs used to be displayed together with the server to which the volumes were currently attached. Especially in large setups, however, such a "coupling" did not always seem helpful. In contrast, other costs – such as for snapshots, Floating IPs, or load balancers – were only shown for the respective cloud resources.

For projects in your personal account or in an organization where you are a superuser, there has already been a clearer overview: in the "Billing" area of the control panel, all costs for a project are summarized on a single page. The total costs are broken down into compute, storage, and networking costs and listed individually down to the individual cloud resources. This overview is now also available to all other project participants, e.g. external collaborators or members of a partner organization; you can find it directly in the "Services" area by selecting "Project Costs" from the menu.

An overview of the current situation

The overview under "Project Costs" is not only useful when you need to answer questions from accounting or a customer. For example, take a look at this summary after an automated deployment using Ansible or Terraform; you can see at a glance whether the cloud resources created correspond to what you intended. As a sanity check, you can also quickly see from the costs if, for example, significantly too small or too large compute flavors have sneaked into an "infrastructure-as-code" config.

As usual at cloudscale, costs are shown per day so you can see what the currently present cloud resources would cost if they existed in this form for a full 24 hours. Of course, we continue to bill by the second: resources that you just created or will delete on the same day are only billed on a pro-rata basis. Object storage continues to follow a separate logic here: because these costs are calculated from ongoing usage, a point-in-time view is not possible; instead, you are shown the average costs of the last 7 days.

More useful information for you

With the consolidation of all cost information in "Project Costs," we have also taken a fresh look at other information that would best support our users in their work in the control panel. For example, you will now find a separate total for NVMe SSD and bulk storage above your server and volume views, or the overall object count for object storage.

We also recently introduced the "Balance History" in the "Billing" area. For your own account and for organizations where you are a superuser, you can track the development of your credit balance on a daily basis and see the amount charged for each project. For more information, simply click to view the Billing Report for the relevant project and day, where you will find a list of all billed cloud resources with their individual amounts.

With cloudscale, you only pay for what you need – and you can clearly see what that is at any time. This not only gives you the best possible overview, but also ensures you always have the right answers when communicating with internal and external stakeholders.

Straightforward.
Your cloudscale team

The right protocol for every use case

Compared to TCP, UDP saves a certain amount of overhead; in data transmission using UDP, for example, data packets can be lost without being retransmitted. In a video stream, for example, this may well be desirable; it is better to have a few pixels missing than to have to stop everything and wait for the missing data packets. In a VPN tunnel, on the other hand, the inner, encapsulated connection can respond to transmission errors and, if necessary, request that the data be sent again.

This makes it clear that UDP-based services cover a wide range of use cases that are by no means less demanding in terms of availability and server capacity. If you operate such services at cloudscale, be sure to use our "LBaaS" for them as well. With two or more backend servers – ideally in "anti-affinity" – processing requests in parallel, you not only increase the overall capacity but also the availability of your service as a whole.

Special characteristics of LBaaS with UDP

In the case of TCP, our load balancer distributes individual connections to the available backend servers ("pool members"). UDP does not work with connections like this; instead, the load balancer distinguishes between individual data flows, which are identified by their respective combination of source and destination IPs and ports. Packets with matching values are assigned to the same data flow (and thus the same backend) over several minutes, which already leads to a certain degree of "session stickiness" by default.

Our comprehensive API documentation includes tables showing you the supported protocol combinations. For example, it is possible for pool members to use (TCP) HTTP status codes to signal to the health monitor whether they are ready to process requests, even if the actual requests are then transmitted via UDP.

Please note that the load balancer currently supports UDP for IPv4 traffic only. If your load balancer is accessible from the internet, it will be assigned both an IPv4 and an IPv6 address by default; in this case, simply do not enter any AAAA DNS records for the hostnames on which you (also) operate UDP services.

UDP is ubiquitous, not just when it comes to DNS. Use our load balancer for your UDP-based services too, to make your setup even more robust and elegantly handle maintenance work, for example. And if you do not have any experience with our LBaaS yet, you will find a good overview to get you started in the post about the components of a load balancer.

Reliably,
Your cloudscale team

Have you ever wondered which member of your team set up that server called "test"? Or when you last had to perform a hard reboot of a certain system? You will find the answer in the audit log. Any changes to your cloud resources, irrespective of whether they were carried out in the cloud control panel or via API, are neatly listed and traceable.

If you would like not only to look at these logs in the control panel, but also, for example, to save them on your own log server or search them using a specific tool, you can now retrieve the audit log via our API, too. In the process, you have the option of setting a start and/or end time in order to narrow down extensive logs to the relevant period. In addition, a special poll_more URL enables you to access periodically and precisely any logs that have been added since the last retrieval. This also makes it possible for you to evaluate the logs in a monitoring system and, for example, to nominate somebody automatically to perform an additional manual review of certain operations.

Further details

In addition to the exact time stamp for every change, you will find action and message fields in the audit log that you retrieve via API. The action field lists what type of change it is (e.g. "server_volume_attach"), while the message field describes the whole process, i.e. also indicates which volume was attached to which server. You will also see who initiated the change (usually the e-mail address of an account in the control panel or the API token used) and from which IP address. As always, you will find all the details in our API documentation.

Not every change carried out via the control panel or API will take the same amount of time and actions can run in parallel. As soon as the action has been successfully completed, the log entry is prepared, which determines the time stamp of the log. Shortly afterwards (in a matter of milliseconds), the result of the action and the log entry can be seen. In this short period of time, it is possible for log entries to "overtake" each other, i.e. a log with an earlier time stamp only becomes visible later. When accessing subsequent pages and when "polling", the cursor ensures that you do not miss a log entry. Michi has provided a comprehensive insight into this mechanism in our engineering blog.

Preprepared sample code: start right away

In order to enable you to start quickly, we have prepared a ready-to-use, annotated Python script for you. This will allow you to try retrieving the audit log via API and to become familiar with the approach used. Even if you use different tools and languages, this will provide you with a good overview and a basis for your own implementations.

First of all prepare a Python virtual environment with the required dependency:

mkdir project-log-api-client
cd project-log-api-client/
python3 -m venv venv
source venv/bin/activate
pip install aiohttp

Then create the actual api-log-client.py script with the following content:

import asyncio
import json
from collections.abc import AsyncIterator
from datetime import UTC
from datetime import datetime
from datetime import timedelta
from typing import Any
from urllib.parse import quote

from aiohttp import ClientSession

API_TOKEN = "INSERT_PROJECT_API_TOKEN"
POLL_INTERVAL_SECONDS = 120


async def stream_logs(session: ClientSession, start: datetime) -> AsyncIterator[Any]:
    poll_url = f"https://api.cloudscale.ch/v1/project-logs?start={quote(start.isoformat())}"

    # The outer loop fetches all logs available at the time,
    # then waits for a defined interval.
    while True:
        current_page = poll_url

        # The inner loop fetches individual pages of available logs
        # until the `next` field in the response is `null`.
        while current_page is not None:
            async with session.get(current_page) as response:
                if not response.ok:
                    # The API did not return with status code 200.
                    raise Exception(f"Error {response.status} from API: {await response.text()}")

                obj = await response.json()

            # Return all fetched logs to the caller.
            for log in obj["results"]:
                yield log

            current_page = obj["next"]
            poll_url = obj["poll_more"]

        # Wait for a defined interval before polling for new logs.
        await asyncio.sleep(POLL_INTERVAL_SECONDS)


async def main() -> None:
    # Header to authenticate the API access.
    headers = {"Authorization": f"Bearer {API_TOKEN}"}

    # Retrieve logs from the past hour before streaming new logs.
    start = datetime.now(UTC).astimezone() - timedelta(hours=1)

    print(f"Streaming logs, starting from {start:%F %H:%M:%S}. Use ctrl-C to stop.")

    async with ClientSession(headers=headers) as session:
        # Iterate over logs returned by the API and print them to the console.
        async for log in stream_logs(session, start):
            print(json.dumps(log, indent=4))


if __name__ == "__main__":
    asyncio.run(main())

Now start the script. It will provide you with the audit log of the past 60 minutes on the command line and will then periodically add any new log entries that have been created in the interim.

$ python3 api-log-client.py 
Streaming logs, starting from 2025-12-11 12:21:48. Use ctrl-C to stop.
{
    "ip_address": "172.30.244.1",
    "action": "server_create",
    "message": "Server 'hello' has been created",
    "timestamp": "2025-12-11T12:23:17.460366Z",
    "actor": {
        "user": {
            "email": "johanna@example.com"
        }
    }
}
[...]

With the audit logs of your projects at cloudscale you know at all times who did what when, which means that you can quickly establish the correct links or approach the right person for further inquiries. You can now also use these logs via API for maximum flexibility when archiving and evaluating.

Reliably committed,
Your cloudscale team

Rescue mode as an additional boot option

You can use the VNC console to start your servers from a volume other than the root volume, which will allow you to boot and, if required, install almost any operating system. However, first of all you need to attach an additional volume to your server with the required content for booting (e.g. a USB or ISO image). Although this process offers you complete flexibility, it can cost precious time in an emergency.

Rescue mode now offers you a multifunctional tool that is available at all times in such cases. It takes just two clicks for your server to start a Grml image. This Debian-based distribution can probably be considered as the standard live image for tricky situations.

A live system is particularly helpful when normal access to your server is not working for whatever reason. Whether the server is not booting in the first place (the reason for this can often be seen in the console log), cannot access the network properly, has an excessively restrictive firewall setting, or you have simply lost the login details, Grml (in the same way as the boot diskette used to) offers you a tool to access a faulty configuration and solve the problem.

Activate rescue mode

You activate rescue mode via the blue "emergency suitcase" button in the cloud control panel. When you activate rescue mode, your server automatically restarts or switches on and then boots the Grml live image. You can then use the VNC console to access your server and, if required, open e.g. network access or mount the root volume.

Grml offers you a wealth of options from the outset. If you let the 30-second countdown of the boot loader elapse, it starts with the default settings and then offers you a selection menu via the VNC console where you can, for example, change the keyboard layout or network configuration. By pressing "q", you reach the zsh shell and can decide for yourself what to do next.

More features for faster work

You can work in a more targeted – and convenient – manner if you provide the boot loader with information. Press the Tabulator key during the countdown and add options to the displayed string, e.g. services=networking,cloud-init-main,cloud-config,ssh, followed by the Enter key. This will enable Grml to activate the network while booting (it obtains the settings via DHCP) and to load the SSH daemon.

Most importantly, however, it also starts "cloud-init"; this obtains, among other things, the SSH public keys that you selected when creating the server from our metadata server and stores them for the "grml" live user. This means that you can access the server straight away with ssh grml@<IP address> and will have all the usual SSH options, including copy/paste from your local system and file transfers.

Grml offers you a wide range of aids and short-cuts. In order to obtain an overview, use grml-tips <keyword> directly in the Grml zsh on your server and have a look at the cheat codes on the Grml website.

Back to normal operation

Once you are ready, you deactivate rescue mode again via the control panel. The server restarts and boots from its root volume as usual. If the error was successfully eliminated, you can then access your server as normal, e.g. via SSH with your standard username and SSH key.

While rescue mode is active, you can reboot or switch off the server, e.g. with the shutdown command. Before you do so, be aware that a switched-off server in rescue mode can only be switched on again by deactivating rescue mode (the reason for this is a specific trait of OpenStack, which our cloud infrastructure is based on). The server will then once again try to boot from its root volume, although you still have the option of activating rescue mode again.

We all know that things sometimes get stuck in IT. The new rescue mode for your servers at cloudscale means that you can get to where it matters more quickly, for example to the decisive config that gets everything up and running again.

The right tool when it matters!
Your cloudscale team

Create a snapshot of a volume in a matter of seconds, for example before a major upgrade or any other change to your server. If something goes wrong, you can just as quickly revert the server to the snapshot and thus to a previous, functional state. However, what if you simply want to check the content of a snapshot or only require a single file from it, e.g. the previous version of an important config?

A recent development is that you can also create new volumes from your volume snapshots where the new volume then contains the exact data that were "frozen" in the snapshot. In the above example, you could then attach the new volume to the corresponding server and mount it, which would enable you to access the required config file specifically.

It goes without saying that updates and their potential pitfalls are not the only use case for this new feature. An obvious example is, for instance, a 1:1 copy of a root volume. Previously you would have started your server from a live system and then copied the volume block by block, e.g. with dd. Now you can simply create a snapshot and then turn it into a separate new volume. This allows you to subsequently continue working flexibly, for example by downloading the content of the volume to a local archive. Or you can use it to create an image file for a custom image in "raw" format (however, direct use as a root volume for a new server is not possible at the moment).

Use via an existing API endpoint

To create a new volume from a snapshot, use the same API endpoint that was previously used to create a volume. Specify the volume_snapshot_uuid as a parameter in order to identify the desired snapshot as the basis for the new volume. In addition, the API will accept a name and, as an option, tags for the new volume; the other properties (such as size or cloud location) are based on the indicated snapshot.

The API request could look like this, for example:

curl -i -H "Authorization: Bearer YourApiTokenGoesHere" \
  -F name="my-volume-name" \
  -F volume_snapshot_uuid="351d461c-2333-455f-b788-db11bf0b4aa2" \
  https://api.cloudscale.ch/v1/volumes

As always, you will find all the required details in the extended section "Create a Volume" in our API documentation.

Please note that the snapshots are crash-consistent, also when creating volumes from them. This means that they contain an image of the original volume at exactly the point in time when the snapshot was created, as if the server had crashed at this moment. Depending on the specific circumstances, it may make sense to stop tricky services before creating a snapshot or to shut down the server completely in order to ensure that e.g. write caches are also contained in the volume and thus in the snapshot. When preparing a custom image, please also consider including "cloud-init" and keeping it as small as possible. You will only add any required free space when you create a new server with the image.

Points to note

Be aware that not just snapshots, but also volumes created from them are not a backup. They are not only in the same storage cluster as the original volume and will potentially also be affected in the case of technical issues, but we also use "Copy-On-Write" (COW) for rapid and efficient provision of snapshots and volumes, which means that different volumes and snapshots may depend on the same, shared data fragments. For solid backup, use snapshots and the volumes based on them as an interim step and then copy the data to a separate location, such as an archive that is maintained locally to you.

The COW mechanism that is used in the background does not, however, cause any limitations for handling your volumes and snapshots. Even if you have used a snapshot as the basis for a new volume, you can later delete the snapshot – or even the original volume as a whole – without this affecting the new volume.

Snapshots as the basis of a new volume will also support you when you do not need to revert a whole server. Maintain the content of your root volumes, for example, when you delete virtual servers, create a consistent 1:1 copy as a basis for a download or a custom image, or access previous data versions while leaving everything else in the new state. Simply start with a snapshot and keep all options open for yourself.

For moments that need to be saved,
Your cloudscale team

Separate projects, joint network

You can use private networks to "wire up" virtual servers internally in one cloud location, e.g. a web server that accepts requests from clients with the associated database backend. Where individual servers do not need to be accessible from the internet at all, this means that you can minimize the target area for attacks. You can now also connect your servers and load balancers using a private network if they are not in the same project.

Projects not only provide a clear overview of and bring order to your cloud resources. If different teams within your organization are responsible for the maintenance of, for example, web workers and DB clusters, you can determine their access rights in the control panel for each project separately. With separate projects and a shared private network, you can then clearly map the responsibilities and isolate the databases from the internet, while ensuring that they remain accessible from the web workers.

A further example of a separation of this kind could be, for instance, when management of your firewall has been outsourced to an external service provider (and this partner organization has been granted access rights to the firewall project in the control panel). The filtered traffic can then travel through the private network to the servers in your other projects. Or you may have a centralized log server that you run in a separate project (key word: segregation of duties). Finally, you can also use this to limit the scope of an API token that you have stored in a tool for automation purposes.

Make the most of shared networks

If two projects are to share a private network, first determine which project should be the owner of the network. Details such as the name or MTU of the network can only be changed from within this project at a later stage. For the actual sharing (or to change the circle of participating projects later), notify our support team. You will find the link for this in the control panel under "Network > Sharing".

The properties of the private network are visible to all participating projects, in particular e.g. the name of the network so that it can be identified without doubt when connecting a server. The MAC addresses and – provided they are managed via DHCP – the IP addresses of all devices in this network are also visible under "Network > Ports". While these technical details are accessible to everyone in the network anyway (e.g. by means of ARP requests), they also help you to avoid collisions and any subsequent errors. The names of servers and load balancers in other projects, however, are not visible; devices of this kind are simply displayed as "Other Device".

With regard to IP addresses, you can use any IPs in your private network, which allows you to consider existing address patterns already used by a participating project. You will find further information on the configuration of the desired subnet and other DHCP features in our article on Managed DHCP.

Shared private networks allow you to guarantee internal data flow between the correct systems without all of them having to be in the same project (and thus managed by the same people). This ensures that you can structure access rights more precisely and centralize services that are used by several projects – both within your own organization and with partner organizations.

Network? Go!
Your cloudscale team

The load balancer "as a whole"

In the background, a cloudscale load balancer consists of a redundant pair of virtual servers that we manage for you. Externally, they share an IP address (the so-called VIP, short for "virtual IP address"), which is active on one of the two systems and – similar to a Floating IP – is automatically and almost seamlessly moved to the other system if a problem is detected. In this way, we prevent the load balancer itself from becoming the single point of failure, while you save yourself the effort of having to build and maintain such a setup yourself.

From a logical perspective, the load balancer (or the load balancer object in the API) is like a bracket that "encloses" the components described below behind the VIP mentioned.

As always, you can find additional parameters as well as examples of API requests and responses for all of the objects mentioned in our comprehensive API documentation, so that you can try everything out in practice right away.

The listeners

A listener is the ear, so to speak, with which your load balancer listens for incoming connections. If you want to use your load balancer for HTTPS traffic, for example, you will typically set up a listener on TCP port 443. Particularly convenient: At this point, you can already define which clients are allowed to establish a connection at all. If you enter one or more IP addresses or ranges in allowed_cidrs, then only these, but no other addresses, can connect to your listener.

What happens with the traffic once it has been received is determined by the pool you configure. You will usually specify a separate pool for each listener, but it is also possible to have several listeners point to the same pool.

The pools and their pool members

Essentially, a pool collects all incoming connections that can be handled in the same way. First and foremost, this means distributing the connections to one or more backend servers – the so-called pool members – which then process the requests. Separately for each pool member, you can configure the IP address and port at which it is ready to accept the connections from this pool. In our example, an HTTPS server needs to be running, which does not, however, need to be configured on port 443, but can be configured on any port individually for each pool member.

Directly for the pool itself, you configure the scheme according to which the connections are distributed between two or more pool members. Instead of a simple round_robin, you can use least_connections to route new connections to the pool member that currently has the fewest active connections, or use source_ip to keep routing connections from a specific client to the same pool member, e.g. for persistent sessions on a website.

Also select the protocol for your pool: With tcp, the pool members "see" or log the IP address of the load balancer as the supposed client, as the payload data is forwarded from the load balancer to the backend, but a new TCP connection is established for this. You can work around this using proxy or proxyv2 if your server software supports it (such as nginx): With this protocol, the load balancer can not only pass on the payload data from the original connection to the backend server, but also include information about the original client IP.

The health monitors

You can optionally configure a health monitor for each pool. This allows you to define under which circumstances the pool members are considered "healthy" – for example, if they respond to pings or return the expected HTTP status code in response to a configurable HTTP request. Using the health monitor, the load balancer can periodically check the individual pool members and continuously adjust the balancing so that incoming connections are only forwarded to functioning backend servers.

Last but not least, we would like to point out that a load balancer can either be accessible from the internet or only from one of your private networks, for example for services within a Kubernetes cluster. Publicly accessible load balancers can also be combined with Floating IPs. By the way, a single load balancer can be used for a large number of services/pools, each with its own set of pool members. Having said that, our load balancer "as a service" is not only highly flexible, but also particularly affordable at CHF 1.50 per day – making it the ideal upgrade for setups where availability matters to you.

Servers: Healthy.
Your cloudscale team

By ETH Network Security

The SCION production network has seen significant growth in recent years. Notable examples of its deployment include the Secure Swiss Finance Network (SSFN) and the Secure Swiss Health Network (SSHN), both of which support critical infrastructure and are tailored to members of their respective ecosystems.

Here, we will walk you through the steps we followed to deploy a SCION Autonomous System (AS) in the cloud supported by Cyberlink and cloudscale – exactly as any customer could.

The first step is to get in touch with cloudscale and Cyberlink, who provided us with detailed information about their SCION offering. As of the time of writing, they support two types of SCION connectivity.

Non-managed SCION access

This option provides a direct SCION link to Cyberlink's SCION Border Router at cloudscale within the requested SCION ISolation Domain (ISD). Customers choosing this approach are responsible for deploying and managing their own SCION AS services within their Virtual Data Center (VDC).

Read the full walkthrough for non-managed SCION access at www.scion.org.

Managed SCION access

In this setup, Cyberlink handles the deployment and management of SCION services on behalf of the customer, offering a more hands-off experience. The managed access makes use of the Anapaya EDGE appliance.

Read the full walkthrough for managed SCION access at www.scion.org.

GitLab Fleeting: flexible resources for your tests

GitLab provides you with a comprehensive platform for software development that goes far beyond pure source code management and that you can host yourself, which makes it different to similar products. In the process, GitLab Runners carry out your automated tests and can dynamically request the required computing power from e.g. cloudscale. In the past, GitLab used Docker Machine for this purpose, but this was deprecated quite some time ago, so GitLab "Fleeting" was developed as a modern replacement and we provided the appropriate cloudscale plugin. This means that the required cloud resources are always available for your tests.

The advantages are obvious: with sufficient computing power, it takes less time to run through (or even get to) your pipelines and you receive the feedback required for the next stage of work more quickly. If there is nothing to be tested, the resources can automatically be deleted, thus minimizing costs. By regularly replacing GitLab Runners with new instances, you also reduce the risk of your tests being falsified by accumulated artifacts, configs, and the like.

Try out autoscaling for yourself

The cloudscale plugin for GitLab Fleeting was written in cooperation with Puzzle ITC AG and to a significant extent by Yannik Dällenbach. In his blog post at Puzzle, Yannik takes you through the development process step by step. In our Engineering Blog, Denis Krienbühl additionally provides you with insights into the packaging of the plugin. If you want to try it out immediately, you can set up a GitLab server with Runners and plugin in a few steps using an Ansible playbook and some brief instructions, which will allow you to test autoscaling in a risk-free, hands-on manner.

The best way to do this is to create a new project in the cloud control panel (this makes it clear at all times what is part of your test) and to create an API token with write access within this project. You will also need a Python environment from where you initiate the creation of the setup. Depending on your system, you may also need to add some additional software packages; a virtual server with a fresh Ubuntu 24.04 LTS installation, for example, will be missing python3.12-venv. There is no assumption, however, that you are using Ansible already, as the repository provides everything you need to automatically set up a GitLab server with autoscaling.

Start by cloning the "gitlab-runner" repository and then follow the few required steps in the Readme. After running the playbook, which may take a while, you will find two new virtual servers in your cloudscale project. As the name implies, your GitLab installation will run on the "gitlab" server. You can access it via an HTTPS-protected web interface, and the access data is provided towards the end of the playbook output. There is also an instance of "GitLab Runner" on this server, which is responsible for the dispatching of CI jobs and the creation/deletion of the virtual servers required for them. In addition, you will find a "fleeting-*" virtual server, which is already available for your first CI jobs. Further servers of this kind will be automatically created and deleted again as required.

The Readme also contains a sample CI job so that you can see your Runners in action at once. This job tests whether it can access artifacts in the shared CI cache. If you activated the s3_cache during setup and indicated access data to a bucket in our object storage, the job should notify you that it has found the cache from the second run onwards. Take a look at the configuration behind the scenes, too: you can, for example, choose which flavor and thus which level of performance the servers use for your CI jobs. You can also determine how much spare capacity needs to be available for immediate use at any time – even based on specific days and times.

If you do not yet have a self-hosted GitLab, use our Ansible playbook to create a fully functional setup in a jiffy and start using it at once. If you prefer a manual setup or if you already work with GitLab, have a look at the code of our Fleeting plugin and of the playbook and simply take what is suitable for your use case. Use the full performance when your CI jobs require it – and reduce your costs at other times.

Always exactly what you need.
Your cloudscale team

Safe and flexible with snapshots

You are always wiser in hindsight. That is why with cloudscale you only decide after the fact whether a change has taken place at all: If everything went well and your server runs as expected, you leave it at that; however, if it turns out that the previous state was better, you restore it from the snapshot and let the failed change disappear from the timeline, so to speak. With up to 10 snapshots per volume, you can also "freeze" several intermediate states during an extensive migration and only decide later whether and to which point you want to return.

Snapshots support the security of your servers in several ways: Firstly, you reduce the residual risk associated with changes to practically zero – you always have the functional initial state for sure. This also lowers the barriers to installing available (security) updates and keeping your systems up to date. Snapshots also help you to run through an update process several times or in variants: Reset your lab system as often as you like and find the best approach for your change before you even touch the productive setup.

Tips for use

You can find your volumes with their snapshots in the control panel under "Services > Storage > Volumes"; the volumes connected to virtual servers are also linked on the servers' "Storage" tab.

Each snapshot has a name that you can define when you create it and also change later. For example, name your snapshot "After step 3 DB conversion" so that, if necessary, you can easily find the state you want to return to and do not have to rely solely on the date and time of the snapshot.

Volume snapshots are "crash-consistent", they freeze exactly the content of your virtual hard disk that is present when the snapshot is created (as if the server had "crashed" at that moment). If necessary, clarify how your application will behave if you reset the volume to such a state. It may make sense to shut down services or the entire server to create snapshots, so that caches, for example, are safely written to the volume and are therefore included in the snapshot.

If there are several snapshots of a volume, you can only revert to the most recent one. For an earlier state, simply delete the snapshots you want to skip – as soon as the desired snapshot is the latest, it will be available for revert. To roll back, a non-root volume must also be disconnected from the server or, in the case of a root volume, the virtual server must be switched off.

The fine print: please pay attention

Be aware that snapshots are no substitute for a proper backup. Volumes and the associated snapshots are stored in the same storage cluster, and in the event of a failure, the snapshots are potentially also affected. Furthermore, snapshots can only be used to revert entire volumes; it is not possible to selectively read/restore data.

We would like to warmly recommend the use of volume snapshots. Be it via our API – for example as part of your automated server management – or now also via the web-based control panel: maintain the possibility to try your changes again (and perhaps differently) if necessary or to undo them completely.

Keeps your options open:
Your cloudscale team

Certified for another three years

cloudscale.ch Ltd.'s information security management system has been certified since 2019. We have always been tested in accordance with the ISO/IEC 27001 standard, which deals with "information security" in general and can be implemented by organizations of virtually any size and in virtually any sector, and in accordance with the ISO/IEC 27017 and ISO/IEC 27018 standards, which contain complementary controls for securing cloud services and protecting personal data in public clouds.

Certification is valid for three years and requires annual surveillance audits to maintain its validity. After our initial certification in 2019, we successfully achieved recertification for the first time in 2022 as well as passing a surveillance audit in each intervening year. This meant that recertification was due again in 2025 and we are delighted to have maintained our status seamlessly. The new certificate is valid until 2028 and also available for download.

The new ISO/IEC 27001:2022 standard

The recertification audit was even more comprehensive than usual this year. For the first time, we were tested in accordance with the new ISO/IEC 27001:2022 standard, which provides an even more integrated view of information security than the previously valid ISO/IEC 27001:2013 standard. The new standard prescribes 93 controls that must be taken into account and – unless there are valid reasons to the contrary – also implemented. Although the total number of controls is lower than before, no controls have been removed, but some of them have simply been reworded, streamlined and newly assigned to the categories "Organizational controls", "People controls", "Physical controls" and "Technological controls".

Completely new controls have also been added to the existing, in part reworded controls, for example with regard to "Business continuity" and "Configuration management". Here, once again, it paid off that information security has always been part of cloudscale's DNA. We had already covered many of the standard's new requirements in our day-to-day work. There were no changes in the two other cloud-specific standards (ISO/IEC 27017:2015 and ISO/IEC 27018:2019) whose controls were also tested in the audit.

Continuous improvement included

The unchanged main focus of the new version of the standard – and a given at cloudscale – is continuous improvement. The ISMS processes must be designed in such a way that weaknesses and potentials are identified and improvement measures implemented. This fits perfectly with the way we work at cloudscale and continuously improve information security (e.g. by means of automation, monitoring and redundancies). As a consequence, we can confidently look towards the surveillance audits coming our way during the period of validity of the certificate until 2028.

Every year we are also audited for our ISAE 3000 report, which is totally separate from "ISO". This is not a certification, but a test of specific controls that some customers, in particular in regulated sectors, require for their internal reporting in the case of outsourced processes. If required, we are happy to make this report available to such customers on request.

Audits are a test, which means they are more of an obligation than a pleasure. In this context, we would also like to thank our certification authority, Swiss Safety Center AG, for their support and constructive cooperation since our initial certification. It goes without saying that we are delighted that the seamless renewal of our ISO-27001 certification shows to the outside what really matters to us all year round: the security – comprehensively understood as confidentiality, integrity and availability – of your data.

International standards, Swiss care.
Your cloudscale team

The new cloudscale GPU flavors

Use virtual servers with GPUs at cloudscale, too, with immediate effect by choosing one of our GPU flavors when launching a new server. Just as with the existing Flex and Plus flavors, you can choose between various CPU and RAM configurations. In addition, your server will be allocated one to four physical GPUs depending on the flavor. A local scratch disk is also included in the GPU flavors and you will find more information on this below.

The new GPU flavors are aimed at maximum performance, which is why they are based on the tried-and-tested Plus flavors, where the selected number of CPU cores are exclusively available to your virtual server and you can use them to full capacity 24/7. The same applies to the GPUs, where one or more NVIDIA L40S GPUs supply massive processing power for your workloads and the GPUs are passed to your virtual server "as a whole" as PCI devices.

A new element: the scratch disk

From the outset, your servers' virtual hard drives have been saved in our Ceph-based storage clusters at cloudscale. This means that they are always immediately available, irrespective of the physical machine your virtual server is running on at the time and that these volumes (with the exception of the root volume) can be moved between virtual servers. This comes at the cost of a certain degree of latency. Read and write operations run via network connections, which means that – despite 100 Gbps links – they are on the move for considerably longer than in the case of locally installed NVMe disks.

In everyday situations, most requests tend to affect a small section of the data, which can be kept in a cache if required. As LLMs and similar workloads may be different here, our GPU servers have a local scratch disk. This storage is located on NVMe disks directly in the physical machine the virtual server is running on, thus providing minimal latency. Data are also stored in duplicate in a RAID 1 array as protection against failure.

Operating this setup involves a few particular issues. When moving GPU servers to another physical machine (which is not possible as "live migration" due to the GPUs, but can only occur when the server is switched off), the content of the scratch disk must also be transferred, which takes a certain amount of time. Moving your GPU server may be triggered during e.g. scaling or become necessary when maintenance work is due on our part.

In the event of (hardware) problems, GPU servers are restarted on a different physical machine depending on availability. Please assume, however, that you will be given a new, empty scratch disk in the process. For this reason, you should only use the scratch disk for data where complete loss can be tolerated at any time and ensure that you regularly copy any interim results to a separate storage location.

Development insights

Our GPU servers have been available to selected customers since late February and feedback has been extremely positive. In parallel to gathering initial practical experience, we implemented various improvements, in part also in OpenStack, the open source project our setup is based on. We will, of course, also give our enhancements back "upstream" to the projects in question, in as far as this is possible and feasible.

One of these improvements is the possibility of enlarging the scratch disk at a later point in time – up to 1'600 GB are available to you locally, in addition to the usual volumes in our storage clusters. We have also deactivated data compression when moving the scratch disk between physical machines; our internal 100 Gbps network means we can do without this overhead. And with regard to the SSH connection that is opened for the migration, we ensured that the ciphers used can benefit from the AES support of the CPUs.

Your turn

When creating a new virtual server in our cloud control panel, you will find the GPU flavors in the "Dedicated GPUs" tab. Use the "please contact support" link once and provide us with the key data of your planned use; in addition we will need you to attach a signed copy of the "Addendum for GPU servers". After a manual check we will enable the GPU flavors for the project you specify.

Update: Signing the "Addendum for GPU servers" just got easier! You can now conclude it for your account or organization in the control panel under Contracts > GPU Addendum and start a server immediately — no support ticket required.

If you do not yet have a specific use case, but would like to speak to your own chatbot, Lukas has made it easy for you to get started. In our engineering blog, he shows you step by step how to install Ollama and DeepSeek-R1 70B at cloudscale and make them accessible via the web. A useful tip: our NVIDIA L40S have 48 GB memory per GPU. To ensure that performance does not collapse, take as many GPUs as needed for your selected model to fit completely into the memory of the GPUs.

Our new GPU servers with up-to-date NVIDIA L40S GPUs and a local scratch disk provide maximum performance for your LLM and AI workloads. After one-off activation, you can start, scale and delete GPU servers via the control panel or API at any time using the self-service model. It goes without saying that, as usual at cloudscale, you benefit from to-the-second billing without fixed costs and from a data location in Switzerland. However, the offer is currently limited to a first come, first served basis.

Still here for you personally,
Your cloudscale team

The best as part of your team

If you want to be one of the best, you need a clear focus. Here at cloudscale, for example, our focus is on a rock solid infrastructure, which is carefully thought out in all its details and comes with top support for our customers who can rely on us 24/7. For others, their focus may be the development of specialized apps, data analysis, optimizing business processes, or something completely different that they rely on cloud services for.

Our marketplace exists because nobody can be one of the best in all areas. This is where you will find managed services by our partners for those components that are important to you, but do not form part of your core business. All the services are run by our partners on the cloudscale infrastructure. This ensures that you have a provider with appropriate know-how by your side at every level.

From password manager to complete container infrastructure

The providers in our marketplace cover a wide spectrum of services, which means you can find, for example, solutions relating to personal workspace for you and your team, to collaboration on joint documents, or to a shared password manager. You will also find what you are looking for if you simply want to deploy your containerized applications and need a suitable Kubernetes environment for this (e.g. based on OpenShift or Rancher).

It goes without saying that you can also specifically use individual software components as a managed service. A managed GitLab, for example, is the perfect home for your application's source code; your online shop can rely on a managed database with PostgreSQL or MariaDB in the backend; and with user accounts kept in a managed Keycloak, you benefit from single sign-on in compatible applications (including our cloud control panel).

Suits you

The available managed services are as different as the providers behind them. Select whoever suits you and your team. Whether advice matters to you or you prefer a high degree of automation, whether you like a broad application spectrum from a single place, or if you are looking for a provider who is local to you, the perfect match awaits you in our marketplace.

Even if it previously looked as if you had to do everything yourself at cloudscale, appearances can be deceptive! For years we have maintained close and constructive partnerships, and with the new marketplace you will be able to see more clearly that numerous professionally managed services are available on cloudscale, too. You can currently find a wealth of the most varied offers. We have already initiated discussions with further providers and will continuously add them to our website.

Bring the best into your team! Although you have complete control with the cloudscale infrastructure, this does not mean that you have to handle everything yourself. With the managed services in our marketplace, you will find support exactly where you need it from a partner who is just right for you.

Successful together!
Your cloudscale team

Create a snapshot of your volume before undertaking any – potentially risky – change. If things do not work as you would like them to after the change (and if a specific repair is not an option), you can revert the volume to the snapshot, i.e. restore the content of the volume to where it was before the change. A volume snapshot is a momentary image of a volume as a whole (including all programs and data, as well as boot loader, partitioning, etc.) with the bytes exactly as they are on the virtual hard drive.

It goes without saying that snapshots are not only useful when the horse has already bolted. When testing changes on a lab setup before their productive deployment, you can use snapshots to run through the process as many times as you would like in order to optimize e.g. scripts or other parameters.

All it takes to create a snapshot is a simple HTTPS request to our API, e.g.:

curl -i -H "Authorization: Bearer YourApiTokenGoesHere" -F name="pre-dist-upgrade" -F source_volume="2db69ba3-1864-4608-853a-0771b6885a3a" https://api.cloudscale.ch/v1/volume-snapshots

As always, you will find all the supported requests and attributes in our detailed API documentation.

Technical details and tips

Snapshots are crash-consistent: if you created a snapshot at a time point X and now revert the volume to the snapshot (e.g. after a failed software upgrade), the server will behave as if the volume was unplugged at time point X and only plugged back in again now. Write caches and other data that were not on the volume at time point X cannot be restored in this way. It is probably worth clarifying if and how your setup can handle a state of this kind. It may be advisable to stop tricky services before creating a snapshot, to do a sync, or to shut down the server completely.

In the case of more than one volume, please also note that although volume snapshots are individually crash-consistent, the datasets do not relate to exactly the same time point when two or more volumes are snapshotted during live operations. In order to avoid differences here, create the snapshots when the server is shut down.

By the way, if you have upscaled the volume since creating a snapshot and then return to the snapshot, the volume will automatically be reduced to the size it was when the snapshot was created.

Ultimately, deleting volumes is only possible when there are no more snapshots of them. If a snapshot is still available for a root volume, the corresponding server cannot be deleted either. Therefore, if required, delete any snapshots before you delete volumes or servers.

Two additional points

As usual at cloudscale, snapshots are charged to the second. The storage space costs only half the regular price of NVMe SSD or bulk volumes (depending on the volume to which the snapshot refers). You will find the costs of your snapshots listed separately in the "Billing" area of the cloud control panel.

Snapshots make it possible to restore one or more volumes of a server to an earlier state. However, please be aware that they do not replace a proper backup. On the one hand, snapshots are saved in the same storage cluster as the original volumes here at cloudscale and a potential failure might affect both. For maximum security and independence we recommend that you always keep a copy of your important data outside our infrastructure. On the other hand, snapshots are designed to restore a volume as a whole. It is not possible only to restore selective data from the snapshot.

Volume snapshots are the perfect solution to ensure that you can return to an earlier state within the shortest amount of time after changes – whether for tests, training or as a safety net when upgrading critical servers. Quick to create and inexpensive, a snapshot may be able to save you a great deal of hassle. The "undo button" where it really matters!

Game over? Bonus life!
Your cloudscale team

Cheaper storage space from 2025-02-01

Costs for object storage are taken from your account balance once a day shortly after midnight (in the local time zone of Zurich). These costs are made up of three components, namely number of API requests (CHF 0.005 per 1000 requests), outbound network traffic (CHF 0.02 per GB, inbound traffic is free of charge), and storage space used (here, an average value is worked out over the day).

The storage space component usually makes up the largest proportion of the overall costs. From 2025-02-01, storage space used will only cost CHF 0.001 per GB and day, which is 66% less than previously. This will make our object storage even more attractive, e.g. for off-site backups of your important data. The three cost components will continue to be calculated individually and precisely, then added together and only rounded up to whole Centimes in a final step, before being taken from your credit.

Insight into technical details

At cloudscale, we rely on Ceph for our storage clusters: you can access its S3-compatible HTTPS-API directly on *.objects.rma|lpg.cloudscale.ch, e.g. for uploading and downloading objects. As we could not, however, use Ceph features for billing, we developed our own microservice, which is called "rgw-metrics". rgw-metrics collects usage data from our Ceph storage clusters, thus allowing exact, usage-based billing, on the one hand, and the display of current and past usage data in our cloud control panel and via the API, on the other.

rgw-metrics runs independently of the software providing the control panel and API and saves the collected usage data as a time series dataset. We recently carried out a rgw-metrics rewrite: in addition to switching from Flask to Django, which we also use elsewhere, we have now implemented a containerized setup. A further important aim of this change is enhanced efficiency. Further insights into rgw-metrics are available from Julian in our engineering blog.

Useful object storage features

In the most basic case, you create a bucket and then use one of the numerous S3-compatible tools to upload and download objects and to delete them again at the end. However, our object storage is also suitable for demanding setups, given that Ceph supports a wealth of S3 features such as ACLs, versioning and policies for individual access rights.

Example 1: Additional read-only access to your bucket

To set up read-only access to your bucket (e.g. "my-bucket") for a person or application, create an additional objects user via the control panel or API and make note of the displayed user ID (e.g. "11111111...88888888"). Then create a file as follows and save it locally, e.g. under policy.json:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam:::user/1111111122222222333333334444444455555555666666667777777788888888"},
    "Action": ["s3:ListBucket","s3:GetObject"],
    "Resource": [
      "arn:aws:s3:::my-bucket",
      "arn:aws:s3:::my-bucket/*"
    ]
  }]
}

Now add this policy to your bucket by means of e.g. the s3cmd tool:

s3cmd setpolicy policy.json s3://my-bucket

The additional objects user can now use their own credentials (access key and secret key) to list and read the objects in "my-bucket", but cannot change or delete them.

Example 2: Configuring CORS headers

You can make objects publicly accessible, e.g. by means of:

s3cmd --acl-public setacl s3://my-bucket/my-font.woff2

The object is then directly available (without access key and secret key authentication) at https://my-bucket.objects.lpg.cloudscale.ch/my-font.woff2.

However, when integrating it into a website – e.g. https://www.example.com – the browser may not load the file due to the same-origin policy. In this case, help is available in the form of CORS (cross-origin resource sharing) headers that you configure on your bucket. To do this, create a file as follows and save it locally, e.g. under cors.xml:

<CORSConfiguration>
  <CORSRule>
    <AllowedOrigin>https://www.example.com</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
  </CORSRule>
</CORSConfiguration>

Then transfer this configuration to your bucket by means of e.g. s3cmd:

s3cmd setcors cors.xml s3://my-bucket

When visiting https://www.example.com the browser will access https://my-bucket.objects.lpg.cloudscale.ch/my-font.woff2 in a "preflight" request and send the HTTP header

Origin: https://www.example.com

in the request. If the sent URL matches the one configured on the bucket, the object storage adds the headers

access-control-allow-origin: https://www.example.com
access-control-allow-methods: GET

to its response, thus signalling to the browser that the file may be loaded in the context of this website.

Our object storage covers the most varied use cases, ranging from filing your off-site backups, to serving as a storage backend for your applications, and to sharing files. From 2025-02-01 you will also benefit from significantly cheaper storage space. What more could one ask for?

"Object-oriented" in the best possible sense,
Your cloudscale team

Cyberlink Ltd, a leading Swiss managed service provider for cloud and connectivity solutions, acquires 40 percent of cloudscale.ch Ltd. With this strategic investment, Cyberlink is strengthening its position in the Swiss cloud market and, together with cloudscale, is expanding its offering with innovative, locally rooted cloud solutions.

"The collaboration with cloudscale enables us to strategically expand our cloud services and provide even more comprehensive support to companies with the highest standards of data security and flexibility," explains Thomas Knüsel, CEO of Cyberlink Ltd. "By storing data in Swiss data centers and using customizable solutions, we meet the high compliance standards of industries such as the financial and healthcare sectors."

The partnership allows Cyberlink to access cloudscale's cloud-native technologies. The cloud infrastructures of cloudscale are based on powerful open source software and offer virtual servers, load balancers and object storage for demanding projects. Customers also benefit from seamless integrations with DevOps tools such as Ansible and Terraform or the ability to manage cloud services directly via a user-friendly control panel or APIs.

One example of the technological innovation is the jointly developed SCION Cloud, a revolutionary solution designed specifically for industries with the highest security, availability and compliance requirements. The SCION Cloud combines cloudscale's cutting-edge and top-certified cloud platform with Cyberlink's highly available SCION Internet for the fastest and easiest access to any common isolation domain in Switzerland.

For cloudscale, the partnership means new growth opportunities. "With Cyberlink as a strong partner, we can further expand our market presence and accelerate the ongoing development of our services," emphasizes Manuel Schweizer, CEO of cloudscale.ch Ltd. "Together, we are creating solutions that are specifically tailored to the needs of the Swiss market."

The partnership marks an important step for the future of the Swiss IT sector. By combining technological expertise and local service, both companies are strengthening Switzerland's digital infrastructure and creating added value for companies that depend on high-performance and legally compliant cloud solutions.

Information to meet every need

Communication and transparency are important to us here at cloudscale. This is why, every few weeks, you will find up-to-date information, e.g. the presentation of new features or tips on how to use our service optimally, in the "News" area of our website (and in your inbox, if desired). In addition, we publish upcoming maintenance work and information about any incidents on our https://www.cloudscale-status.net status page. This is also where you can subscribe directly to status notifications on the channel of your choice.

We are now launching the engineering blog as a complement to these announcements from a "company perspective". This is where you can find out first-hand what is on our employees' minds and what matters to them. Written by techies for techies, these posts contain interesting details from our stack, personal evaluations relating to their work, and undoubtedly also valuable inputs for your own projects. The posts are generally available either in German or in English, depending on the language they were written in by our engineers.

Extensive range of reading material

It goes without saying that our engineering blog will not start with an empty list. You will be able to find three very different articles there from the outset.

Actual data storage in our Ceph storage clusters occurs using a large number of OSDs that occasionally, e.g. in the case of maintenance work, need to be restarted. Find out from Denis, whose blog post includes latency graphs and the Python script used, how we have minimized the performance impact of these restarts with a staggered approach (in English).

Lukas has provided you with a very different type of insight. He is the newest member of the cloudscale team and has been with us for a few weeks. In an unusual analogy to a recently completed "fridge project", he describes how he experienced onboarding with us as well as the challenges he has faced and successes he has enjoyed so far (in English).

Our cloud is based on established open-source projects such as OpenStack and Ceph. However, we also write and maintain our own software on a scale where it is important to maintain oversight. Effectively sifting through code and finding specific code locations with precision is an important ability. In his post, Michi explains how he uses pyastgrep when regular expressions are no longer effective (in German).

If you have any questions or input on any of the posts, e-mail engineering-blog@cloudscale.ch, where the engineers behind the posts are looking forward to your feedback.

Find out how varied the people and tasks behind our cloud services are. Discover how our engineers experience their work, what inspires them, and how they find solutions. Even if you do not operate your own cloud, you will find exciting new perspectives in our engineering blog – by techies for techies!

Ready for the deep dive?
Your cloudscale team

From idea to reality

The story of our cloudscale hoodie began by chance: some computer graphics had been produced, meant to illustrate the many ways in which our new logo could be used. One of the images showed a fictitious hoodie that immediately sparked enthusiasm – so much so that we really wanted to have it in reality.

If it says "cloudscale" on it, then of course our usual quality standards should also be behind it. Together with the manufacturer, we managed to get the eyelets and cord ends in green and blue to match our logo. For the zipper, we insisted on YKK, the brand that is generally regarded as the gold standard – after all, putting it on should be a pleasure even in the long term. For the hood, too, we were only happy with the fit in the second iteration.

Now it's your turn

You too can proudly carry a piece of cloudscale with you, with our "circle" logo on the chest and a subtle print on the left upper arm. Write to us at merchandise@cloudscale.ch and tell us the quantity and size (S, M, L, XL) of your desired hoodies as well as the delivery address.

Until the end of December 2024, you can benefit from a special price of CHF 50 instead of 80 per hoodie (plus postage and packaging, CHF 10 flat for up to 3 hoodies). Shipping only in Switzerland and while stocks last, payable by bank transfer within 10 days. The prices quoted include value added tax.

For our fans: well thought-out features, online and offline. Order your cloudscale zip-up hoodie now and in just a few days you can slip it on – we suspect you won't want to take it off again.

Always well dressed,
Your cloudscale team

In compliance-sensitive industries, the system environments are often highly complex and in Switzerland we expect ICT integrators not only to comply with formal regulations, but also to implement them consistently. In order to meet the requirements of industries such as the financial sector, healthcare and insurance, many companies turn to international consulting know-how. This often brings large foreign hyperscalers into play, whose solutions are convincing on paper, but whose data processing often takes place at locations outside Switzerland.

cloudscale.ch and Cyberlink offer a Swiss alternative. With the SCION Cloud, they have jointly developed a solution that keeps all data and workloads entirely in Switzerland while meeting the highest security and compliance requirements. The architecture is specially designed to meet the requirements of financial service providers, healthcare providers and insurance companies and is backed exclusively by Swiss infrastructure.

With the SCION Cloud, developers and DevOps teams can run their workloads in Switzerland without compromising on technology or concerns about data transfers. The regulations in this country exist for good reason – with the SCION Cloud, companies can meet them efficiently and reliably.

Two Swiss pioneers accept the challenge

cloudscale.ch Ltd. (cloudscale.ch) is an Infrastructure-as-a-Service provider with a strong focus on open source technologies and a self-service platform that enables customers, among other things, to configure data center services via API. The close ties to the DevOps and cloud-native community are no coincidence. Many cloudscale.ch employees used to be consumers of such services themselves. "We focus strongly on the user instead of simply developing products that we ourselves think are good," emphasizes Manuel Schweizer, CEO. Having a background in network technology, he became intensively involved with networks and their optimization early on in his career. As a board member of the Swiss Internet Exchange (SwissIX), he gained valuable experience in the Swiss networking scene. From the very beginning, cloudscale.ch has focused on the needs of customers with high requirements in terms of availability and information security. The company consistently focuses on open source technologies.

Cyberlink Ltd (cyberlink.ch), an innovative service provider in the Swiss ICT market for almost three decades, has established itself as a leading provider of connectivity and cloud services. Under the leadership of Thomas Knüsel, CEO, who has been part of the company since 2012, Cyberlink has strengthened its focus on business customers and highly secure network solutions. The implementation of SCION in particular has enabled Cyberlink to further reinforce its role as a pioneer in secure networks. "We emerged as a pioneer in the Internet sector and have specialized in infrastructure services in the cloud and connectivity area. Our goal as a managed service provider is to offer added value by continuously taking care of the infrastructure so that our customers can focus on their core business," says Knüsel. "In addition, we have always believed that synergies are very relevant, which is how we became aware of cloudscale.ch through SCION. Manuel and our lead engineer in the connectivity area, Matthias Schwarzenbach, worked together to develop a solution that integrates SCION into a modern cloud environment. We were convinced of SCION's capabilities right from the start. It offers exactly the security features that many of our customers need, and through our partnership with cloudscale.ch we can also offer this technology in the cloud."

Both companies share a commitment to staying at the cutting edge and using innovative technologies that enable Swiss companies to meet the increasing demands for protection and compliance. The identification of SCION as the next generation of the Internet was the common denominator that got this partnership started.

The discovery of SCION: Technical curiosity and SIX

SCION (Scalability, Control, and Isolation On Next-Generation Networks) represents a fundamental advancement of existing network technologies. Originally developed at ETH Zurich, SCION offers significant advantages over conventional network architectures: SCION is a revolutionary Internet architecture that offers path control, increased protection and improved availability.

Under the umbrella of the SCION Association, the new Internet architecture is being further developed and advanced as an open standard. In practice, the software implementation of Anapaya Systems Ltd – itself an innovative Swiss SME – is used in particular.

For Schweizer, it was personal curiosity to begin with: "What does this thing actually do? Who needs it? As a technician, I wanted to familiarize myself with the technology first." The key stimulus came when Fritz Steinmann from SIX announced the replacement of the old Finance IPNet with a SCION-based network. "This was a great opportunity for us, as the target group for this technology matches the target group of cloudscale.ch very well," Schweizer explains. With existing ISO certification and ISAE reports, the first steps had already been taken towards the financial and healthcare sectors. Schweizer: "I saw the potential of integrating SCION into our cloud and thus creating real added value for our customers."

For companies with high security and compliance requirements, SCION with its benefits is an absolute game changer.

Technical challenges and the partnership with Cyberlink

Implementing SCION in a cloud environment was not a trivial task. "I quickly realized that we couldn't do it alone," Schweizer admits. In addition, customers often had different locations with different providers, which required a consistent solution.

"Together with Matthias, the Network Engineering Lead at Cyberlink, we were able to engineer and thoroughly test everything over a period of six months," Schweizer reports enthusiastically.

The technical implementation in detail

Manuel Schweizer describes the challenge of integrating SCION into the cloudscale.ch platform clearly and pragmatically: "We didn't want to have to install individual hardware for every single customer, let alone keep hardware in stock that might never be used." This meant that, instead of dedicated hardware, an efficient and scalable virtual solution had to be created. In areas that are sensitive from a regulatory perspective, such as the Secure Swiss Finance Network (SSFN), meeting the requirement for provider redundancy was one of the biggest challenges. "It would not be enough to simply connect two ISPs to a redundant SCION core cluster," says Schweizer. Edge provider redundancy is required in order to be admitted to SIC/euroSIC. In a physical world, this would have been implemented with separate connections to two different ISPs. In a virtual world, however, this redundancy for the last mile is provided by the cloud provider of choice. In our case, Cyberlink and cloudscale.ch jointly guarantee the geo-redundant connection of each virtual edge to the two SCION cores. As these are in turn connected to different ISPs, the entire setup is highly available and therefore also fulfills the requirement for provider redundancy at the virtual level. This entire connection remains within the cloudscale.ch infrastructure before the traffic leaves the core. "With this clear communication and preference, we then went to SIX and pitched," Schweizer explains.

The discussions with SIX and ultimately with the Swiss National Bank (SNB) led to a crucial point: the SNB, as the supervisor of the financial sector, had the final say on the definitive architecture. The team quickly realized that core cluster redundancy alone was not enough. "We are establishing provider redundancy from the core upwards," Schweizer explains. The two SCION cores are distributed across different data centers and connected to other SCION participants via different upstream connections as well as the SwissIX Internet Exchange. This architecture corresponds to the best-practice setup, which meets the SNB's requirements and ensures the highest compliance standards.

Matthias Schwarzenbach was delighted with the collaboration with Manuel Schweizer: "There were no reservations. Manuel and I sat together in the meeting room for days on end, exchanging ideas and developing solutions. It was this creative, almost informal atmosphere that kept us going." Thomas Knüsel also remembers: "The two of them virtually outbid each other with ideas and so the solution reached a level that neither Manuel nor Matthias could have achieved on their own."

Today, cloudscale.ch is able to connect any isolation domains (ISDs) such as the SSFN or the SSHN (Secure Swiss Health Network) to its cloud. New SCION edges can be provisioned in less than 24 hours – and soon in under 2 hours. A virtual machine with the Anapaya image is started and connected to the SCION cores with two separate VLANs. Additional fiber optic connections or layer 2 services are not required. The solution is fully multitenant-capable and as close to a cloud-native solution as is currently technically possible.

As part of the conceptual design with SIX and SNB, the question arose as to whether the two cores should be operated in a cluster setup. "The advantages were clear," says Schweizer. In the cluster structure, the two cores share the path information. This interconnection increases redundancy and ensures that maintenance work can be carried out without interrupting the connection of the edge. This solution was ultimately approved and has already proven itself in practice.

Schweizer sums up: "We managed to convince the SNB of our solution. The SCION Cloud from cloudscale.ch and Cyberlink meets the highest compliance requirements and offers a fully compliant and high-performance cloud infrastructure."

Advantages for developers and DevOps engineers

The SCION Cloud offers clear advantages for the technical community: Engineers can use the popular features of cloudscale.ch, at the same time they have all the advantages of SCION and do not have to worry about the network connection.

• Path control and traffic engineering: Developers can explicitly control the data path through the network, opening up new possibilities for optimization and security strategies.
• Integration with DevOps tools: The SCION Cloud is fully API-managed and can be seamlessly integrated with tools such as Terraform or Ansible.
• Security and compliance: The highest security standards are met, which is particularly important for applications in regulated industries.

One specific example is the integration of Kubernetes clusters into a SCION-embedded environment. "From my point of view, we can offer our customers the best technical solution currently available on the market," Schweizer is convinced.

Compatible with any isolation domain

The SCION Cloud is already compatible with every ISD, natively multitenant-capable, flexibly scalable and can be connected as required. The elegant combination with Cyberlink's connectivity services enables users to access applications operated at cloudscale.ch via the appropriate ISD either physically or virtually.

Financial sector: Secure Swiss Finance Network (SSFN)

Since the announcement that the Finance IPNet would be replaced by a SCION-based network in September 2024, it has been clear where developments in the financial sector were heading. In this young but currently best established market, the SCION Cloud is characterized not least by the approval by the SNB. Banks and financial service providers must ensure that their networks meet the highest standards while remaining flexible enough to satisfy new requirements. The SCION Cloud offers a comprehensive solution: it allows control over the data path and enables users to utilize an any-to-any architecture. This means that they are no longer reliant on point-to-point connections such as MPLS. With SCION, financial service providers can establish connections that are not only secure but also flexible – they can decide which partners they want to connect to and which paths they want to use for data transmission. As soon as the new technology is used not only to replace old systems, but also to optimize legacy meshes and consistently reduce superfluous leased lines, this flexibility holds enormous potential for cost savings and significantly simplifies the management of the network infrastructure. The SCION Cloud is the ideal choice, especially for fintechs and banks that want to access cloud services or move their own applications to the cloud.

Healthcare: Secure Swiss Health Network (SSHN)

Cyberlink and cloudscale.ch also see great potential in the healthcare sector in particular: health insurance software providers and other players in the healthcare sector could be integrated into the SSHN to protect the entire infrastructure stack. The SCION Cloud makes it possible to host healthcare applications in a secure, fully compliant and scalable manner. The focus here is on the protected and reliable networking of medical practices, pharmacies and hospitals. However, a key challenge for the Secure Swiss Health Network (SSHN) was user access to the SCION Cloud. How do you get healthcare providers onto this network within a reasonable period of time? How do you equip all practices and clinics in Switzerland with the necessary hardware to connect to the SSHN? As a combination of the best that cloudscale.ch and Cyberlink have to offer, the SCION Cloud opens up two options here: For larger facilities such as hospitals, Cyberlink's Managed SCION Edge is used, which is installed locally and ensures the highest security standards. For smaller practices that may not require the same infrastructure, there is an alternative solution with the "Anapaya Gate". This gate allows access to the SCION world via existing home networks. While it offers a lower level of security, it remains a viable option for less critical applications. This comprehensive connectivity portfolio offers all participants in the ecosystem secure access to sensitive data and a wide range of healthcare applications.

Other compliance-sensitive industries and their ISDs

Other sectors will follow with dedicated ISDs. With its accredited and compliant IT infrastructure, the SCION Cloud is also ready for the strict regulatory requirements of these GRC-sensitive industries, such as the energy and payment sectors, as well as other critical areas. The SCION Cloud ensures that compliance requirements are reliably met while offering the scalability that companies need to grow in the market.

SCION is the Internet of the future

Cyberlink and cloudscale.ch have a clear vision: "SCION is the Internet of the future. With cloudscale.ch as a top Swiss cloud provider and Cyberlink with 30 years of experience in connecting Switzerland, we have the best prerequisites to help shape this future." This team was able to pass one of the strictest auditors in Switzerland with a new technology and do so on time. This would never have been possible without the right partner. A partnership between two top Swiss providers that you can rely on 100%, even in the most challenging crises.

2015: The first weeks after the founding of the company were spent preparing the main tools for our work. Once this was complete, product development itself started. Based on OpenStack and Ceph (open source was important to us from the outset), we built a cloud setup where virtual servers could be created and deleted in a fully automated manner within seconds. We programmed the corresponding control panel ourselves to ensure that using it remained as simple and intuitive as we had imagined – our beta phase users were impressed.

2016: The big moment arrived in early January when we celebrated general availability, aka our grand opening. It was finally possible for anyone to create an account with cloudscale using self-service and start using our virtual servers immediately. It goes without saying that we did not stop there and with a growing team, we prepared the technical basis of our control panel for upcoming further development and added features such as IPv6, private networks and bulk storage to our cloud.

2017: Storage and tooling were two of the main topics of 2017. We progressively added S3-compatible object storage to our cloud offer in order to do justice to a growing need for scalable storage space with purely use-based costs. The switch to NVMe disks resulted in enhanced performance for our SSD volumes. And users of widespread DevOps tools, such as Ansible and Terraform, were now able to manage their infrastructure "as code" and thus automatically provision whole server landscapes in a reproducible manner.

2018: "Meltdown" and "Spectre" made the general public aware of the fact that security vulnerabilities can not only occur in software, but also in hardware. Further CPU vulnerabilities were to follow and at cloudscale, we paid particular attention to always taking the necessary countermeasures quickly. This is why, for example, SMT or Hyper-Threading has been deactivated on all our compute hosts since 2019 in order to pre-empt attacks based on these elements. It goes without saying that our move to a new, considerably more spacious office location was a true highlight of 2018.

2019: The highlights continued into 2019, with many of them coming under the heading of "information security". Among other things, we achieved ISO/IEC 27001, 27017 and 27018 certification, and with the opening of our second cloud location in Lupfig (Canton Aargau), we created the basis for geo-redundant setups. In addition, a good level of power was provided with the introduction of a new generation of compute hosts based on AMD and the launch of our "Plus" flavors, which ensure that dedicated computing power of up to 112 physical CPU cores is permanently available to a virtual server.

2020: Although we were already set up for mobile work, it took a while for the pandemic-enforced model of working from home 24/7 to establish itself. Today we are extremely grateful for the hybrid model we developed, and on Mondays we all meet in person in the office, but other than that everyone can decide for themselves. However, offshoring and nearshoring are not considerations for us. With cloudscale being a completely Swiss cloud provider, you can rely on the fact that the infrastructure is not only located in Switzerland, but that it is also administered from here. In line with this, we have been a partner of the "swiss hosting" label since it was launched in 2020.

2021: The comprehensive redesign of our cloud control panel was a long-awaited milestone for everyone who uses their cloud resources collaboratively. Organizations, projects, teams and various collaboration features support work in the cloud, irrespective of how it is "organized". Single sign-on with GitHub or one's own IDP make logging in simpler and more secure. The collaboration features have also made cloudscale into an ideal partner for larger organizations, too, as well as for everyone looking after projects for their own customers in the cloud.

2022: We can hardly be more central after our 2022 move into our current office right by the main railway station in Zurich – with a team that has grown to more than ten people. A lot happened in terms of our cloud offer, too, with e.g. the expansion of the collaboration features, more flexible management of custom images, and many new compute flavors, which means that you also always have the appropriate infrastructure for CPU- or RAM-heavy workloads. The new completely linear price model means that the price for a certain quantity of CPU and memory resources does not depend on whether it is a single large virtual server or several small virtual servers. In addition, an ISAE 3000 report has been available every year since 2022, if required.

2023: In line with our focus on availability, we provided our customers with a load balancer service as a further feature to enable the creation of resilient setups. While our services continue to be billed to the second, we have fundamentally simplified the underlying mechanism. We have also started accepting payments using the popular Swiss TWINT payment solution. And we prepared for SCION, the network architecture of the next generation that promises enhanced reliability, confidentiality and control of communication in critical areas such as the finance and healthcare sectors.

2024: With enhanced transmission capacity between our cloud locations, increased flexibility when using Kubernetes setups thanks to CCM, an improved overview of costs and private networks, we are continuously improving and expanding the cloud services for our customers in the current year, too. Our new, fresh appearance is particularly eye-catching. We not only completely redesigned and expanded our website, but also subtly adjusted the control panel and API documentation in line with the new design. The clear lines reflect our unambiguous claim: at cloudscale, you are in best hands.

Which further highlights will we encounter on our journey? Let's find out – together with a strong team and, of course, our customers who will be able to continue to count on us as a close and approachable partner in future, too. Speaking of our team: if you think you are a good match for us, please let us know!

On the journey with you,
Your cloudscale team

Two dedicated firewall distributions are available at cloudscale: OPNsense and pfSense CE. Choose one of these images to set up a virtual server as a firewall between the open Internet and a private network. You can then configure this firewall conveniently in a web-based administration interface and adapt it to your requirements.

To ensure that the firewall also processes traffic that arrives via a Floating IP, the Floating IP must be entered in the administration interface. You can find the setting in OPNsense under "Interfaces -> Virtual IPs", in pfSense CE under "Firewall -> Virtual IPs". Enter the Floating IP and the prefix length (/32) here. In most cases, "Type: IP Alias" and the assignment to the "WAN" interface should be the appropriate setting; more details on the individual options can be found in the documentation for OPNsense and pfSense CE. By the way: By default, OPNsense and pfSense CE do not respond to pings; add "ICMP Echo request" to the firewall rules to change this if desired.

If you want to migrate an existing server behind your firewall that already provides a service using a Floating IP, you can – once everything is prepared – simply move the Floating IP from the server to the firewall as the last step. If you are not yet using a Floating IP, we recommend adding it to the existing server first and then adjusting the DNS entries: This way, your service will remain available under the old and new IP addresses in parallel while the new DNS entries are gradually picked up.

Tips for modifying existing setups

If your existing server should no longer be directly accessible from the Internet after the migration, you can remove the "public" interface from the server. To do this, you need an API token with "Write access" as well as the UUID of the server and the private network to which it should be connected. You can then issue the necessary API call via the command line as follows:

curl -i -H "Authorization: Bearer 11112222333344445555666677778888" -H "Content-Type: application/json" -X PATCH --data '{"interfaces": [{"network": "11111111-2222-3333-4444-555555555555"}]}' https://api.cloudscale.ch/v1/servers/11111111-3333-5555-7777-999999999999

NB: It is also possible to add a public interface to the server again later; in this case, the server will be assigned a new public IP address. You can find more information about our API in the API documentation.

After making changes to the interfaces, it is advisable to briefly check the names of the interfaces. If they are not permanently assigned, they could change after a reboot (e.g. the private network from ens4 to ens3) and lead to connectivity issues. The Linux distributions rely on different tools here; keywords are, for example, "netplan" and "udev rules".

If a server is no longer directly accessible from the Internet, you will also need a new way to access it. Choose the solution that suits you best, e.g. a VPN or port forwarding – depending on your firewall strategy. It is also possible to first connect to the firewall via SSH and then continue from its command line to the respective server.

Finally, just in case, we recommend setting a root password on your server with which you can log in "locally", but not via SSH. In the event of boot or connectivity problems, you can then log in to the server via the VNC console in our control panel and resolve the issue. Alternatively (and somewhat more complicated), you can also start the server with a temporarily connected live Linux for troubleshooting purposes.

cloudscale offers a range of features relating to the security and availability of your setups. Use and combine these according to your requirements and preferences. Even with existing setups, you remain flexible and can, for example, replace the direct Internet connection of your servers with a dedicated firewall complete with Floating IP.

Security to suit your taste!
Your cloudscale team

At cloudscale, several popular Linux distributions are available for new servers. Thanks to so-called custom images, even more individual setups are possible: as a customer, you upload a hard disk image, which can be used to fill the root volume of your new virtual servers initially, including any required tools and settings. This is where the security vulnerability was found in OpenStack, the open source project our cloud offer is based on. Uploading specially crafted images in QCOW2 format made it possible to access data in systems that play a part in our import process of custom images.

As an immediate measure, we had temporarily deactivated the import of QCOW2 images. Specifically, this means that all images were treated as "raw". Images that actually were in QCOW2 format could therefore not be used by virtual servers to boot. While we were aware that this causes additional work for some customers, as they need to convert images into raw image format before importing them, we decided to implement this temporary step in the short term in the interest of security for us and our customers.

Timeline:

• December 2020: Introduction of custom images, support for raw format
• May 2022: Additional support for images in QCOW2 format
• February 2023: Specification of image format no longer required for import
• 2024-07-02: OSSA-2024-001 / CVE-2024-32498 security vulnerability disclosed
• 2024-07-03: Import of images in QCOW2 format blocked as an immediate measure
• 2024-07-31: Import of images in QCOW2 format possible again, adaptation of API

Background of the vulnerability

Image files in QCOW2 format have several special features, e.g. the fact that they tend to require less space. In addition, they can not only contain the actual data of a data carrier, but also references to externally located files. The core of the OpenStack security vulnerability was inadequate checks in some OpenStack components that processed references of this kind and their target files when processing QCOW2 images. As custom images are always saved in raw format at cloudscale, the vulnerability affected in particular automatic recognition of the format to be imported and the conversion from QCOW2 to raw. However, according to our analysis, there are no indications that the vulnerability was actually exploited at cloudscale.

The conversion of images where OpenStack uses qemu-img convert has in the meantime been patched so that it is no longer possible to exploit it even using specially crafted images. This means that we can once again enable the import of QCOW2 images here at cloudscale. However, in the OpenStack developer community, there is not (yet) a reliable solution for automatic format recognition using qemu-img info, which is why at cloudscale we will in future no longer attempt automatic image format recognition.

Use of QCOW2 images at cloudscale

Importing QCOW2 images is possible at cloudscale again effective immediately, but the format has to be indicated during imports. When importing via API, the attribute source_format is used for this purpose. After being declared deprecated in February 2023, this has now once again been officially introduced following recent incidents. While the attribute can be left out for images in raw format, source_format is required for QCOW2 images. We are aware that this change in API behavior is not completely non-breaking, but the purpose of the selected solution is to minimize the required adaptations.

The current versions of our modules/plug-ins support the source_format attribute, which means they can be used to import QCOW2 images. You will find answers to all the important questions relating to this topic in the FAQs below.

We are delighted that, after the exclusion of QCOW2, which became necessary at short notice, we can once again enable the import of custom images in this format. Unfortunately, in the process, it was not possible to avoid the reintroduction of an old attribute in the relevant API call. It was important to us not to leave any known vulnerabilities open, while causing as little work as possible in terms of adaptation. We would ask for your understanding where adaptations are nonetheless necessary.

Considerate and pragmatic.
Your cloudscale team

FAQs

What will happen to existing custom images?
Nothing. The change only applies to the import process. Existing images are not affected.

What will change for imports using the web-based control panel (control.cloudscale.ch)?
You now need to specify the format of the image in the "Source Format" drop-down.

My import is showing the error message "Import could not be processed", what do I need to do?
You probably tried to import a file as "QCOW2" that is not a file of this kind. Check the format and the URL.

I only import raw images. Am I affected?
No. However, ensure that the source_format field is either not transmitted or contains "raw". An error will occur for other values.

I use Terraform, what do I need to do?
In order to be able to import QCOW2 images, you need to use the "cloudscale" provider from version v4.4.0 onwards and specify the import_source_format for new images. You can continue to use existing images with no change, the format should not be specified retrospectively.

I use cloudscale_ch.cloud for Ansible, what do I need to do?
Ensure that the correct source_format is transmitted. You do not need to update the Ansible collection.

I use cloudscale-go-sdk in my Go application, what do I need to do?
If you use it to import custom images, you need to ensure that the correct source_format is transmitted. The dependency does not need to be updated.

I use cloudscale-python-sdk in my Python application, what do I need to do?
If you use it to import custom images, you need to ensure that the correct source_format is transmitted. The dependency does not need to be updated.

In the open source environment, plain text files, e.g. in a YAML or JSON format, are frequently used for (software) configurations and other data that are evaluated by means of an automated process. For a long time, our Ansible setups, which we use to automate a majority of our installation and maintenance processes, obtained their data about our inventory from a large number of such YAML files.

Our recent switch to NetBox now explicitly represents connections in the NetBox database that were more or less apparent in these YAML configs, ultimately providing additional protection against errors. You can navigate through the inventory via the web-based interface of NetBox and, for example, see the occupancy of server racks or check which devices share a chassis.

Comprehensive and flexible

NetBox supports a wealth of information about every device. In addition to location, position in rack, device type and network details, it is also possible to record e.g. whether the cooling air flows from the front of the device to the back or vice versa. For cloudscale, the most relevant recorded data are, in particular, the role that a device fulfills, i.e. whether it is a storage server, a switch or a monitoring system, to name but a few.

The tasks that we automated in Ansible then use the API to obtain the hosts they are to be applied on from NetBox; the same goes for host-specific configs, such as MAC addresses. The interfaces required for this are provided by the inventory plugin contained in the NetBox Ansible Collection. We use caching to improve the performance for more complex playbooks, too. The required data are collected once at the beginning of the playbook run, maintained for the whole run and then discarded to ensure that the next run also starts with the most up-to-date data.

In our precisely structured Ansible setups, (physical and virtual) hosts are frequently allocated to more than just a single Ansible group, although NetBox is limited to at most one role per device. This is why, in order to be able to represent the existing structure in NetBox, we decided to only allocate the primary child group (lowest group in the inheritance tree) as a role for the device. Any further child groups are recorded in NetBox using "tags". We then transform these special tags into groups by means of an internally developed Ansible plugin and add these as a variable to the host in question at playbook runtime.

More than networking

NetBox is officially aimed at network engineers. However, its claim to offer "a cohesive, extensive, and accessible data model for all things networked" makes it clear that the area of application is considerably broader. This means that our customers can also represent their virtual servers in NetBox, together with properties, such as the specific cloud location, IP addresses, private networks, etc. In combination with our Ansible Collection, it is even possible to import existing cloud setups into NetBox.

As a "source of truth", NetBox can ultimately also take on a managing role, with new virtual servers being first recorded in NetBox and then, based on this data, automatically created and configured by Ansible.

NetBox represents a powerful tool to further automate tasks surrounding the inventory. Thanks to it being open source, we can also contribute our own improvements back to the community. With NetBox as a "source of truth", everyone involved can rely on correct data about the inventory, both via Ansible playbooks and in the web-based GUI.

A reliable basis.
Your cloudscale team

Private networks for every requirement

The first step to using a private network has been kept intentionally simple at cloudscale: it takes just a few clicks during launch to connect virtual servers to an existing or a new private network. The connection to the private network can either be set up in addition to the direct connection to the Internet or can replace the latter. The private network is exclusively available to you from layer 2, which allows you, for example, to freely configure the IP addresses on the involved servers. Jumbo frames are supported for enhanced efficiency in the private network, but it goes without saying that you can customize the default MTU of 9000 bytes if required.

In a private network, a DHCP service is available as standard, allocating IP addresses from a randomly selected /24 within 172.16.0.0/12 to requesting servers. In addition, there are many other configuration options available. These allow you, for example, to create private networks without a DHCP service or to define any other IP range (at least /24) for the DHCP service. DHCP functionality can also be deactivated for individual servers or the IP address can be allocated in a fixed manner in the private network instead of the DHCP service selecting it at random. Together with the IP address, the DHCP service can also provide servers with a gateway and/or a list of DNS resolvers, thus making local configuration of this information redundant.

Consistently clear layout

The "Networks" area in our cloud control panel ensures that you always maintain an overview, even when there are several private networks. We have expanded this progressively over recent months so that all the relevant details of your private networks are clearly summarized and can, in part, be customized directly.

Under "Settings", in addition to the freely selectable network name, you will also find those details that relate directly to the layer 2 network, in particular the MTU. While this setting determines the packet size that is actually possible in the private network, if the DHCP service is activated, it is also communicated to the servers in the DHCP response.

The "Subnets" tab summarizes the information associated with the DHCP service. This includes the IP address area selected for the network in CIDR notation and the range from which the DHCP service selects the addresses, provided that you do not indicate specific addresses. The "Gateway" and "DNS Servers" values do not affect the behavior of the DHCP service directly, but are part of the DHCP response to configure your servers.

Finally, under "Ports", you will see all the devices involved in your private network, including their MAC address and the IP address that the DHCP may have reserved for the device. It also goes without saying that you can use other IPv4 or IPv6 addresses on your virtual servers. In addition to your virtual servers, the two DHCP servers that manage your subnet are listed as well.

Any load balancers are also included in the list. Due to it being designed for high availability, a load balancer consists of two individual servers, which is why it appears with two ports in your private network. The IP addresses visible here are the same as the ones that can be seen in your backend's logs, unless you are using the proxy(v2) protocol for the load balancer pool in question, which transmits the actual source IP of the client together with the simple TCP packets to your backend. If the VIP address of the load balancer is also located in the private network, it will be listed under the ports, too.

Security considerations mean that it often makes sense only to connect those systems that actually need to communicate with each other. And if your setup develops further over time, "Networks" in our cloud control panel will always allow you to see which networks are available and where which devices are involved. This helps you reduce the risk of errors and makes your life even easier with the centrally managed DHCP options.

Networks made easy.
Your cloudscale team

Complete control over costs

If you want to invoice your customers for the costs of specific cloud projects, compile costs for bookkeeping purposes, or simply maintain an overview, you can use the new billing report in our cloud control panel and pull a report on the costs for the required time period. You can select specific days as the start and end dates.

An initial overview shows the overall costs of each project. A separate page for each project then shows the total for the individual types of resources (e.g. all servers, all volumes, etc.) and the exact costs of the specific cloud resources (i.e. individual virtual servers, volumes, etc.). Projects and resources that no longer exist are also shown.

To the second

The listed cloud resources can be "opened up": if there was a change during the selected time period, you can see the individual to-the-second time segments and the associated costs. Although the most common reason for a change is when servers and volumes are scaled, the price adjustments from the year before last and this year are also shown. For technical reasons, there is also a "cut" in time segments if a project was moved from a personal account to an organization. Time stamps marked in blue/green represent the start or end of the time period shown and do not mean a change relating to service or price.

All time stamps in the billing report refer to the Europe/Zurich time zone, irrespective of your settings. This is due to us switching to billing per calendar day last August, where costs are collected throughout the day and taken in full from your account or organization credit shortly after midnight (in the local time zone of Zurich). It goes without saying that you can also select older time periods in the billing report, but for virtual servers it is not possible in all cases to show the compute flavor that was active at that time.

Two hints

All projects and cloud resources in the billing report are shown using the name they currently have or last had (if they have been deleted in the interim). If you are uncertain, you can use the UUID, which is also shown, to check which resources these are specifically.

The "BGP Announcements" right at the bottom of the billing report are a little known pro feature: if you already have your own IP space, but do not wish to run your own infrastructure, you can have the space configured as Floating Networks at cloudscale, thus making virtual servers accessible under your own IPs. Our support team is happy to advise you if required.

Irrespective of how small or large your cloud project is, at cloudscale we want not only technological administration, but also pricing to be straightforward. The new billing report now allows you to retrospectively reconstruct the development and costs of your project in detail – for the exact time period required and at the level of your choice.

You can count on us.
Your cloudscale team

With our CCM, your K8s cluster now knows even more about the nodes involved. Metadata about the nodes is automatically retrieved from our cloud API, e.g. the IP address(es) of the respective virtual server or its geographical region/zone. It is also possible to distinguish whether a node has been deleted or simply switched off. The compute flavor is equally available; this makes it possible, for example, to place certain workloads specifically on nodes that use a "Plus" flavor and thus have the selected number of CPU cores available for exclusive use at all times.

Our CCM is available on GitHub and supports the three latest minor releases of Kubernetes. The corresponding documentation with examples and a helper to try out the CCM in a test cluster can also be found on GitHub.

K8s services with our LBaaS feature

In addition to more detailed information about the underlying infrastructure, the CCM also enables the automated management of our LBaaS feature. To use this, select the type: LoadBalancer for a Service in Kubernetes. The load balancer can make your service accessible either from the Internet or only in one of your private networks.

The load balancer distributes incoming requests in the private network among the nodes of the K8s cluster, which do not require their own "public" interface. The permitted clients can be restricted to the desired IPs or IP ranges already at the load balancer level. In order to be able to recognize or log the IP addresses of the clients in the backend despite NAT, use the "proxy" or "proxyv2" protocol, which is supported by nginx, among others.

Our load balancer service is designed to support and simplify the operation of highly available services. However, please note that applying configuration changes via CCM may imply some downtime – approximate numbers for the different supported cases can also be found in the documentation.

Thanks to our CCM, tasks can be automated since your K8s cluster can rely on additional information about the infrastructure and on our load balancer service. This way, you not only increase the efficiency of your setup, but also the availability for your users.

Everything under control.
Your cloudscale team

Blue and green. Memorable lettering instead of far-fetched graphics. That is how we have always been known and how we want things to remain. There is, however, a striking difference: the new color tones look significantly fresher, and the clean lines of the font better reflect our identity.

The "o" is particularly eye-catching: it has been simplified from a speedometer logo to a color gradient, which not only represents performance, but also stands for simplicity, scalability and dynamics. With its high recognition factor, it is a design element that can be used in manifold ways in other places. (For those with an eye for detail, the point where blue touches green reflects the angle of the letter "c".)

A unified whole

The completely new design of the website is inspired by the colors and shapes of the lettering, thus creating an unmistakable appearance. The aim is for cloudscale to feel the same, in terms of first impression and ongoing cooperation alike.

It goes without saying that this also applies to daily use and to the engineering of sophisticated setups. It makes perfect sense for us to have adapted our cloud control panel and API documentation to the new design. Needless to say, we have in no way sacrificed the clear overview, and in addition to the new design, we have also further optimized usability.

As approachable as ever

Transparency has always been important to us. One aim of our newly designed website is to make relevant information even more accessible, and it goes without saying that we will continue to keep you updated with regard to new developments and our offers. Our contact options are also unchanged, so if you have any unanswered questions, please get in touch for a personal response. In line with our cloud being so uncomplicated, we will from now on simply call ourselves "cloudscale" without the ".ch" in everyday use.

cloudscale stands for professionalism. Our new, consistent look provides an even better reflection of this standard to the outside, making it clear from the outset that, at cloudscale, your project is not simply in the cloud, but in best hands.

Even more ourselves now,
Your cloudscale team

Just over four years ago, our second cloud site in Lupfig (Canton Aargau) became operational in order to enable geo-redundant setups for our customers. So that virtual servers would be able to communicate directly between the two sites without the data traffic leaving our network, we connected the sites using dark fiber. This means that instead of simply purchasing transmission capacities from a third-party provider, we rent unused "dark" glass fiber lines and use our own transceivers to "illuminate" them ourselves at the endpoints.

To achieve greater total capacity, we use coarse wavelength division multiplexing (CWDM) where laser light with different wavelengths (also known as "colors" in everyday parlance) is transmitted over one and the same glass fiber line. On one of these channels, we connected the core routers of our two sites with 10 Gbps, while two others, bundled together to 20 Gbps, used to connect the locations at switching fabric level.

For maximum availability, we duplicated the physical connection. The sites in Rümlang and Lupfig are connected by separate dark fiber lines on different, non-intersecting routes. This means that the connection remains available even if one of the fiber lines is damaged, e.g. during roadworks. Even within the data centers, we paid attention to detail with our cables entering the buildings via separate entrances, not intersecting after this point either and terminating in different racks. This redundancy allowed us to double the normally available capacity to 2x 10 Gbps between the core routers and to 4x 10 Gbps between the switching fabrics.

Upgrade to 2x 100 Gbps

We recently significantly extended the connection between the switching fabrics: instead of 2x 10 Gbps there are now 100 Gbps available on each of the separate routes. By adapting the data rate to the one used inside the sites, less buffering is required, which further reduces latency of data transmission.

The connections between the sites at switching fabric level are used, among other things, for data traffic between your virtual servers. This means that you automatically benefit from this upgrade if you, for example, periodically save an archive copy of your data off-site.

Outlook

The upgrade of the connections to a total of 2x 100 Gbps will generally benefit all those applications where relatively large quantities of data are exchanged between our cloud sites. In addition to increased "breathing space" for existing setups, the extended capacity also creates a foundation for future features such as off-site back-up of our customers' data.

At cloudscale.ch, we use redundancy at every level to avoid failures whenever possible. However, we nonetheless recommend that our customers make the most of the full potential of both our sites and create their setups in a geo-redundant manner. The recently significantly extended direct connection between our sites has also created a basis for rapid and reliable replication of your data.

A common definition states that the "cloud" is based on the three pillars of compute, storage and network. Although it is often the most inconspicuous of the three, the network is decisive – not only for standard operations, but in particular with regard to geo-redundancy. With our upgrade to 2x 100 Gbps between the two cloud regions Rümlang and Lupfig, you can build on a solid foundation, today as well as tomorrow.

Looking ahead,
Your cloudscale.ch team

The Internet is omnipresent today and has become essential to almost all areas. It becomes particularly apparent how key this infrastructure is to our lives when cyberattacks and large-scale failures occur. Some such problems are facilitated by the fundamental architecture of the Internet, which it inherited from the early days of its 50-year history.

Certain areas have higher requirements in terms of reliability and security of their central communication infrastructure, in particular e.g. the financial and health sectors. SCION was developed with these sectors in mind at ETH Zurich. The full name of the routing protocol "Scalability, Control, and Isolation On Next-generation networks" already shows how it differs from the conventional Internet.

Control and isolation with SCION

The Internet, as a "combination" of many individual networks, really is a net: there are countless possible data transport paths between two communication partners A and B. The path the data actually take arises from a number of influencing factors and decisions by the providers involved, with A and B having little impact.

This is where SCION is completely different. Based on a variety of parameters, such as latency, jitter, packet loss and available bandwidth, network participants can prioritize or exclude certain paths. Thanks to constantly updated metrics, optimal routing can thus be ensured. Complete path control also allows the exclusion of certain path segments and specific providers.

If a network hub fails, data traffic within the Internet automatically finds a new path. This adaptation, however, requires time and in some cases, it may take several minutes for the affected data to flow again. SCION consistently relies on modern concepts to virtually avoid interruptions of this kind. If the currently preferred route fails, immediate diversion to a different route based on the defined specifications takes place.

Authentication of network participants is a further important feature of SCION. In completely separate "isolation domains" (ISDs), participants can rely on the fact that they only receive data traffic from legitimate, verified sources.

SCION at cloudscale.ch

Thanks to its focus on reliability and trust, SCION is ideal for the financial sector. SIX, for example, is currently replacing its "Finance IPNet" with the SCION-based "Secure Swiss Finance Network" (SSFN). SCION is also already in use in the health and energy sectors.

At cloudscale.ch, we are in the process of putting two SCION core routers into operation. This means that in future our customers will be able to participate in these secure networks directly with their cloud setups. If you are interested in SCION access, please contact us to discuss the next steps.

SCION was developed for applications with requirements that can only be partially fulfilled by today's Internet. Complete path control and the available metrics mean that participants regain the upper hand in terms of data flow. They also benefit from minimal down time and authentication of all communication partners. This is why we will soon also be enabling our customers to participate in various SCION-based networks or ISDs.

With the best connections,
Your cloudscale.ch team

Adjustment for compute flavors only

Despite there being no way around a price increase, our aim is to limit it to what is absolutely necessary and to maintain our principle of simplicity and transparency – also in terms of pricing. Specifically, this means that the prices of our compute flavors will be subject to a uniform increase of 10%, i.e. a virtual server with the "Flex-8-2" flavor, for example, will cost CHF 2.20 instead of CHF 2.00 per 24 hours.

The purely linear price structure will be maintained with this increase. Consequently, costs for memory and CPU resources will still be based solely on overall requirements and not on whether you combine your workloads on a single large server or prefer to distribute them across several smaller servers. The other prices, e.g. for volumes, object storage and load balancers, will also remain unchanged and no new price components will be introduced.

Background

Thanks to favorable purchase conditions, we were able to reduce our prices by up to 33% in July 2022. In the meantime, however, the environment has changed and energy prices in particular have increased dramatically – not only in Switzerland. These increased prices have a double effect on the running of a cloud infrastructure: on the one hand, running physical servers uses power directly, and on the other hand, power is essential for the required cooling. In addition, purchasing hardware has also become significantly more expensive.

The new prices will apply from 0:00 h (Swiss time) on 2024-01-01 for the running of existing and newly created servers and will be visible in our cloud control panel from shortly after midnight. Accordingly, account balances will be debited for the first time at the new conditions in the night to 2024-01-02 for the services used on 2024-01-01.

At cloudscale.ch you only pay for what you actually use and it goes without saying that to-the-second billing will continue. This is why, even with the current price increase for compute flavors, we are convinced that this flexibility remains worthwhile, especially in an environment where prices are generally increasing.

As transparent as always,
Your cloudscale.ch team

Terraform enables you to define the required cloud infrastructure in the form of configuration files. Based on this configuration, Terraform then creates the actual cloud resources via the API. In day-to-day operations, if there have been deviations in practice, Terraform can then recreate the state based on the configuration and apply any changes made to the configuration to the real setup. Terraform configs are also often managed in a version control repository, such as Git, and used as part of a CI/CD pipeline.

Projects: order, security and transparency

At cloudscale.ch, cloud resources such as servers and volumes are created in projects. Projects enable resources to be grouped, e.g. for each end client or in order to separate dev and prod environments. If several participants are working with cloud resources, access rights can be determined for individuals and teams on a project-by-project basis. Finally, the costs for each project can be displayed separately and can then be further broken down according to resources.

API tokens for the cloudscale.ch API are also linked to a project and only allow access to resources within that project. In practice, it may therefore be desirable e.g. to create a backup server in its own separate project. This means that an API token in the primary project that is frequently used in day-to-day operations (e.g. to move a Floating IP between servers) cannot be used to make changes to the backup server.

Central management in Terraform

If you want to create all your resources at once with Terraform, you will face the issue of how to use the cloudscale-ch provider with multiple API tokens. The solution consists of creating two provider blocks, i.e. instantiating the provider twice and adding an alias to one instance. You can then assign a separate API token to each instance.

This will look like this:

terraform {
  required_providers {
    cloudscale = {
      source = "cloudscale-ch/cloudscale"
    }
  }
}

# Define variables for the API tokens
variable "cloudscale_api_token" {}
variable "cloudscale_backup_api_token" {}

# Define the provider for the default project
provider "cloudscale" {
  token = var.cloudscale_api_token
}

# Define the provider for the second project with an alias
provider "cloudscale" {
  alias = "backup"
  token = var.cloudscale_backup_api_token
}

You can declare the resources in the first project as usual:

# Create servers using the default provider
# in the first project
resource "cloudscale_server" "demo-server" {
  name               = "demo-server-${count.index + 1}"
  flavor_slug        = "plus-8-4"
  image_slug         = "ubuntu-22.04"
  ssh_keys           = [file("~/.ssh/id_ed25519.pub")]
  zone_slug          = "lpg1"
  count              = 3
}

The resources that belong to the second project are then additionally given the provider keyword as an extension.

# Create a backup server using the aliased provider
# in the second project
resource "cloudscale_server" "backup-server" {
  # Use the aliased provider
  provider           = cloudscale.backup

  name               = "backup-server"
  flavor_slug        = "flex-4-2"
  image_slug         = "ubuntu-22.04"
  ssh_keys           = [file("~/.ssh/id_ed25519.pub")]
  zone_slug          = "rma1"
}

Now all the resources in both projects can be created at once:

terraform apply -var="cloudscale_api_token=$TOKEN1" \
                -var="cloudscale_backup_api_token=$TOKEN2"

Incidentally, as it is a Terraform feature, you can not only use the alias keyword at cloudscale.ch to specify multiple API tokens, but generally whenever you want to use an otherwise identical provider block with different parameters.

Choose the right approach for you to manage your resources at cloudscale.ch, depending on the specific setup, participants and preferred way of working for each case. Even if you spread your cloud resources across multiple projects in the process, you can use alias instances of the cloudscale-ch provider to bring the threads together in a single consolidated Terraform repository.

One goal, many names:
Your cloudscale.ch team

The new Swiss FADP

According to the Swiss Federal Council, transparency, monitoring options and awareness of responsibility associated with the processing of personal data were three of the goals of the revised Federal Act on Data Protection (FADP). A further aim was to align the Swiss FADP more closely with the EU General Data Protection Regulation (GDPR) to ensure continued certification by the European Commission of an adequate level of protection in Switzerland.

Even though the old FADP contained similar regulations, many data protection provisions of recent years were mainly familiar from the GDPR. The revised FADP means that Swiss data protection has now also become a topical issue. This is probably not least due to the new threat of fines of up to CHF 250,000 for non-compliant decision-makers. In the following, however, we do not want to focus on the fines, but on the two main constellations relating to day-to-day data protection and on the question of how cloudscale.ch is involved.

Data subjects and controllers

The new FADP protects natural persons (i.e. individuals, rather than legal persons such as companies or associations) when their data are processed. These data subjects do not need to be known by name: if the subjects can be identified using the data, the data are considered as personal data. A company processing personal data of this kind, thereby determining the purposes for which and the means by which the data are processed, is the "controller". In the context of e.g. an online shop, the owner of the shop is the controller who processes, among other things, the contact details and orders of customers (data subjects).

Certain rights and obligations exist between data subject and controller. This means that, if necessary, data subjects are entitled to have incorrect data that are processed about them rectified or possibly even data completely deleted. The starting point for this is data subjects being informed about the data processing, which is why the controller has an obligation to provide information and to disclose, which often takes the form of a privacy policy on the controller's website.

Here at cloudscale.ch, we have always been economical and, in our role as controller, do not collect unnecessary data in advance. However, in order to conclude contracts and provide our services, a certain minimum level is necessary, including e.g. contact details of our customers or data for invoicing purposes. We also provide information about our data processing as a controller in a privacy policy published on our website.

Data processing

Controllers often not only process personal data themselves, but also involve service providers. In the online shop mentioned as an example above, a credit check could be obtained before orders are shipped to a customer on account. The shop owner is also the controller for this step and remains wholly responsible for data processing. Here, the credit agency is a "processor" because it processes data on behalf of the controller. This kind of data processing is basically permissible, but needs to be regulated in a contract concluded between controller and processor.

As a cloud provider, we here at cloudscale.ch become a processor as soon as our customers use our services to process personal data, e.g. when the afore-mentioned online shop is run on our infrastructure. This is why we already offer the required contract for data processing, the data processing agreement (DPA), which can be concluded with just two clicks of the mouse directly in our cloud control panel.

As opposed to the GDPR with its detailed regulations, even the revised version of the Swiss FADP gives barely any instructions on the content of the DPA. We nonetheless made the most of the opportunity and reviewed our DPA, with the revisions coming into effect on 2023-09-01. While there were almost no essential changes, we revised the structure and a lot of the wording to improve clarity and make things easier to understand, e.g. in the following places:

• The document (in German) is now called "Vertrag zur Auftragsverarbeitung" or "AV-Vertrag" (AVV), which are more common terms nowadays than the previous name.
• We no longer specifically mention GDPR, but simply use "applicable data protection legislation". This clearly refers to the fact that other regulations may also apply, e.g. the Swiss Federal Act on Data Processing (FADP).
• We have continued to use the terms "verarbeiten" and "personenbezogene Daten", as is common in the context of GDPR, whereas the Swiss FADP uses different German synonyms. The consistent choice of wording aims to make it easier to read while it in no way opposes the interpretation of the DPA according to Swiss law.
• We now specify "documented instructions" (a GDPR term). The aim here is to clearly state that the customer, or possibly a third party, independently and directly (and not via correspondence with us) determines how our IaaS services are used and thus how data are processed.
• Previously we referred to other documents for technical and organizational measures (TOMs). On our website, in particular, we provided regular reports on improvements to our security features. Now, a set of TOMs has been explicitly summarized in an Annex to the DPA. NB: the TOMs described represent a point-in-time snapshot. While the level of protection described is binding and may not be undercut, we have the option in future to change and further develop the measures actually taken. The customer will have to assess whether this level is suitable for specifically planned processing. Here at cloudscale.ch, we provide standardized services without getting involved in individual cases.
• In addition to the TOMs that we take on our end, we also have a list of security-relevant features relating to our services, which our customers can use for themselves to support the security of data and their processing.
• The provision regarding deletion of data at the end of the contract has been specified in more detail, in particular in terms of reference to the fact that customers can move their data to a new location independently.

Data protection and data security have always been key for us here at cloudscale.ch. In this process, we not only handle personal data responsibly, but also support our customers as they adhere to the relevant specifications, e.g. by means of the DPA that they can conclude directly in our cloud control panel.

Committed to data protection,
Your cloudscale.ch team

Until now, cloud resources could be "exchanged"

If you created a virtual server or other cloud resources, the relevant costs for 24 hours were taken from your account balance immediately. When this prepaid period expired, a new fee was taken for the next 24 hours – for as long as you kept the resources.

When cloud resources were deleted, a credit note was issued for any remaining unused, but prepaid time in this 24-hour period. When servers and volumes were scaled, the credit note was issued at the old price and then the new price was charged – again for 24 hours. This means that the cloud resources were invoiced individually throughout the day depending on when they were created or scaled for the last time.

Now, only actual costs are charged

The costs are now recorded in the background and taken from your account balance shortly after midnight (in the local time zone of Zurich). This means that for cloud resources that have already been deleted again, you are charged the actual costs directly instead of by means of a "down payment invoice" that is then corrected using a credit note.

While both methods ultimately result in the same costs, the new mechanism is based on what you intuitively expect from to-the-second billing. And in certain constellations this avoids numerous unnecessary debits and payment reversals, e.g. if you use integration tests with dynamically created GitLab runners or if you are simply trying out various flavors to find the one that is right for you.

On a new overview page per project, the costs are further broken down.

Overview of total costs and composition

As previously, you will see the daily total costs of your individual projects in the "Billing" area of our cloud control panel. On a new overview page per project, these costs are now further broken down, which allows you to see at a glance how these costs are distributed across the individual resource types (e.g. compute, storage, etc.) and across the specific resources (individual virtual servers, volumes, etc.). Here, the costs per day are listed for all resources that exist in the project at the time in question.

Our object storage is an exception as it is not calculated per day but based on actual usage. This is why these costs were always taken from your account balance retrospectively, i.e. shortly after midnight. As there is no fixed price per day here given that it is usage-based, the overview shows the average costs of the past seven days.

Flexibility is one of the many advantages of the cloud. You always book and pay for exactly what you need. Billing per calendar day (instead of for each individual cloud resource) means that the "bookkeeping" behind this system has been significantly simplified. And we are already working on other tools to provide you with enhanced support in terms of cost control.

No calculator required.
Your cloudscale.ch team

In a next step, three possible mitigation approaches (BIOS update, "chicken bit" and microcode update) were discussed and the latter two were tested in our lab environment. These two problem-solving approaches have the advantage that they can be used during live operations, although the "chicken bit" option would probably have been associated with a considerable loss of performance, which is why we opted for mitigation by means of a microcode update.

After successful application of the microcode update in our lab, we were able to verify that it was no longer possible to exploit the vulnerability using the proof-of-concept code and that operations remained stable.

After our test suite passed successfully, we decided to roll out the update in batches in the production environment. Given the urgency, we did not set a two-week notice period for the maintenance window, as we usually do, but scheduled it with immediate effect – in both cloud locations at once, despite usually scheduling maintenance for two separate days. We initially applied the microcode update on individual compute hosts and then in batches.

The last compute host was finally patched at 01:33 (CEST) on Tuesday, 2023-07-25.

Setting priorities:
Your cloudscale.ch team

PS: In order to be continuously updated about incidents and planned maintenance work, subscribe to the updates on the channel of your choice on our status page.

The code used in the examples in this article is a somewhat simplified version of the actual code that calculates data for the following React component (this view will be familiar to our users):

The data read from the API is used to generate both the server list and the summary.

The aim is to establish the following information for a given list of servers:

• Number of servers
• Total server memory
• Total storage of all server volumes
• Total daily server costs

To start, here is an overview of the corresponding TypeScript code:

export interface Server {
    name: string
    daily: number
    memory: number
    volumes: Volume[]
}

export interface Volume {
    type: 'ssd' | 'bulk'
    size: number
}

export interface ServerSummary {
    count: number
    totalMemory: number
    totalStorage: number
    totalCost: number
}

export const getServerSummary = (servers: Server[]): ServerSummary => {
    const count = servers.length;
    const totalCost = servers.reduce((accu, s) => accu + s.daily, 0);
    const totalMemory = servers.reduce((accu, s) => accu + s.memory, 0);
    const volumes = servers.reduce<Volume[]>((accu, s) => accu.concat(s.volumes), []);
    const totalStorage = volumes.reduce((accu, v) => accu + v.size, 0);
    return {count, totalCost, totalMemory, totalStorage};
}

The two first interfaces, Server and Volume, are the data types for the input. Next comes the ServerSummary interface, which contains the four values to be calculated. Lastly, we can see the getServerSummary function, which is our test subject. To calculate the totals, we use Array.reduce() here.

In the next step, we will look at the associated unit test, which is also implemented in TypeScript:

test('test getServerSummary', () => {
    // arrange
    const servers: Server[] = [
        {name: 'server1', daily: 1, memory: 4, volumes: [{size: 50, type: 'ssd'}]},
        {name: 'server2', daily: 2, memory: 8, volumes: [{size: 10, type: 'ssd'}, {size: 200, type: 'bulk'}]},
    ]

    // act
    const actual = getServerSummary(servers)

    // assert
    const expected: ServerSummary = {
        count: 2,
        totalCost: 3,
        totalMemory: 12,
        totalStorage: 260,
    };
    expect(actual).toEqual(expected)
});

This is a classic unit test in line with the arrange, act and assert (AAA) pattern:

• Arrange: we define two Server instances with test data.
• Act: we call the getServerSummary function.
• Assert: we compare the actual result with the expected result.

Although this test works perfectly, close observation reveals the following: as we are using TypeScript and the properties Server.name and Volume.type are not optional, we also have to populate them in the test data (see Arrange) even though they are not relevant for this test case. If we remove name and type, the unit test will continue to run, but the TypeScript compiler will issue an error message.

Having to specify the test data that are not required might not be a problem in this small example, but can very quickly become inconvenient in complicated, nested structures.

The following represents an initial naive attempt to solve the problem using TypeScript Type Assertions:

const servers: Server[] = [
    {daily: 1, memory: 4, volumes: [{size: 50}]} as unknown as Server,
    {daily: 2, memory: 8, volumes: [{size: 10, type: 'ssd'}, {size: 200,}]} as unknown as Server,
]

We now no longer need to indicate the superfluous attributes, but we have also sacrificed type safety: if we now incorrectly use a wrong name or type, such as {sizeGb: 'x'}, for {size: 50}, we will get no compiler error and an unintuitive test result.

After several experiments and a range of improvements, we ended up with the following test helper:

function mockPartially<T extends object>(mockedProperties: Partial<T> = {}): T {
  const handler = {
    get(target: T, prop: keyof T & string) {
      if (prop in mockedProperties) {
        return mockedProperties[prop];
      }
      throw new Error(`Mock does not implement property: ${prop}, but it was accessed.`);
    },
  };
  return new Proxy<T>({} as T, handler);
}

mockPartially() sets up a proxy object for any type T. An object with any subset of properties of T can be passed as mockedProperties. This is made possible by the Partial type constructor. Partial<T> creates a new type where all properties of T are set as optional. Using the proxy object, we can implement any behavior when accessing properties of the object. In our case we throw an error if the property in question was not specified in mockedProperties. If the property has been indicated, its value is returned unchanged.

We import mockPartially as mP, which enables us to define the test data as follows:

const servers: Server[] = [
    mP<Server>({daily: 1, memory: 4, volumes: [mP<Volume>({size: 50})]}),
    mP<Server>({daily: 2, memory: 8, volumes: [mP<Volume>({size: 10}), mP<Volume>({size: 200})]}),
]

This solution has the following advantages for us:

• We can omit any unnecessary input data.
• If we forget required data, we receive a clear error message, such as: Mock does not implement property: volumes, but it was accessed.
• In the case of false test data, such as {sizeGb: 50} or {size: 'x'}, we receive error messages from the TypeScript compiler that are easy to understand.

We hope you have found this in-depth insight into the day-to-day life of our software developers interesting and that you might be able to use our mockPartially helper yourself.

(Not) mocking!
Your cloudscale.ch team

Django – a solid basis

Over the years, our cloud control panel has undergone comprehensive development. It was originally written in Lua as a minimum viable product. However, in order to improve maintenance we wanted to use a framework, which is why we decided to re-implement the control panel in Python and Django.

Django describes itself as "the web framework for perfectionists with deadlines." It has proved to be reliable, well-tested and high-performance. Django allowed us to rapidly add new features and improve existing code.

Gradual introduction of React

At the time, the control panel comprised just a few dynamic components. These enable users of our control panel to continuously receive current information, e.g. the power status of servers, without having to reload the page. The aim here was to further improve usability with more direct handling of cloud resources. After significant consideration, we decided to introduce React. In order to guarantee a smooth transition, we opted for a gradual implementation.

We started implementing new features and adapting existing functionality with React, at all times prioritizing those cases where the benefit seemed greatest for our customers. This gradual integration made it possible for us to keep susceptibility to errors as low as possible and at the same time to make the most of all the advantages of dynamic web components.

The displayed information, e.g. the power status of servers, is up-to-date, even without reloading the page.

Switch to single-page application

The switch to a single-page application (SPA) ensued as a logical next step in our increasing use of dynamic web components. This means it is no longer necessary to reload the page within the control panel, thus providing an appealing and interactive web application.

Together with this switch, we also largely replaced the generation of HTML elements using Django templates. Instead an (internal) API now runs on the server side and provides the browser with all the required contents. This clear separation of browser and server technologies also makes cooperation easier in our software development team.

End-to-end type checking

When revising existing software code, in particular, errors are frequently introduced in untyped languages such as JavaScript if it is not consistently clear what type of variables will be used at runtime. This is why we have been using TypeScript for a while now. This language makes it possible to complement JavaScript code with data types and to have them tested by the TypeScript compiler.

Communication between browser and server code via our REST API is a central aspect of our control panel. We therefore also want to ensure that both sides are using the same data types. To this end, we developed a special code generator that automatically generates TypeScript code based on the definitions of our Django REST API. In the process of our continuous integration (CI), checks are then carried out to ensure that the code generated in this way is correct. This end-to-end type checking approach helps us to improve code quality and to reduce potential errors.

We continuously work at further improving our web application based on feedback and iterative steps. Our goal is to develop a user-friendly application that does justice to the requirements of our users, while supporting us in its further development.

On the same page!
Your cloudscale.ch team

Periodic peaks due to integration tests

Automated software tests make sense and are indispensable in many scenarios. At defined times or for defined events, e.g. when pushing code changes, test suites are started that will, ideally, confirm that all test cases are running successfully and might be directly followed by a productive deployment. Any errors found serve as early and meaningful feedback about where corrections are still required.

More complex test configurations may be fairly resource-intensive and require high-performance infrastructure, especially when engineers need the test results in order to continue with their work. In-between test runs, however, the test infrastructure is idle. This is where the cloud offers a way of avoiding unnecessary costs: when required, resources are made available at extremely short notice; once tests have been completed, the infrastructure and the associated costs can immediately be reduced again.

Your own dynamic test setup

Our Ansible playbook will support you as you create your own test setup, which only requires very few resources for day-to-day operation and automatically draws on resources from our cloud during test runs. Even if your tests are extremely demanding and require runners of correspondingly large dimensions, the resources are deleted again after the test run and only incur low costs due to our to-the-second billing.

The Ansible playbook assumes that you want to install the whole setup with all its components from scratch. If you already have, for example, a GitLab instance or a runner or would like to adjust other installation details individually, the accompanying instructions we have provided for a manual setup will help you install the components you want.

Thanks to automatic scaling and billing by the second, you can make the most of the cloud with resources that are available exactly when you need them and that you only pay for during this time. Test setups with GitLab runners and their typically short, but intensive workloads benefit particularly here, and you can install them in a flash with our Ansible playbook and the corresponding instructions.

Test us out!
Your cloudscale.ch team

From fail-over to load balancing

At cloudscale.ch, we have always endeavored to maximize the availability of our infrastructure and thus to guarantee interruption-free operation of your virtual servers. Failures are, however, still possible and, in addition, there are planned interruptions, e.g. when you update the software you use. You already have the option of Floating IPs as a mechanism for keeping your service available from your users' perspective: the IP address that users connect to can be moved, either in an automated manner or manually, from one virtual server to another, thus ensuring that requests can be processed while the original server is offline.

Our new load balancer offer goes even further. As opposed to with just an IP address, it is not only possible to divert incoming traffic from one server to another, but the load balancer can continuously distribute incoming connections – and thus the computing load – to two or more virtual servers. Additional health checks are used to regularly check the state of the virtual servers and if one of them does not respond as expected, it is taken out of rotation and incoming traffic distributed among the remaining correctly functioning servers. As opposed to with a Floating IP, it is also possible to configure separate sets of servers for processing requests to different TCP ports.

Redundancy within the load balancer itself

To ensure that the load balancer itself does not become a single point of failure, it is actually a pair of load balancers that run on separate hardware. The "virtual IP address", which is visible from the outside, is allocated – in a similar way to a Floating IP – to one of the two load balancers, and switches to the other load balancer if a problem is detected with the first one. While it is already possible to build a setup of this kind on your own with two additional virtual servers and a Floating IP, our load balancer service significantly reduces the effort required. Once it has been configured, the load balancer carries out its work without your having to worry about scripting checks and fail-overs or about maintaining additional servers.

Please note that the virtual IP address (VIP) is linked to a specific load balancer and will be deleted if the load balancer is deleted. So that you can offer your users a service with an IP address that remains the same, we recommend that you use a Floating IP in combination with load balancers. Floating IPs (but not Floating Networks) can also be moved between virtual servers and load balancers, which means that you can seamlessly replace an individual server with a load balancer setup.

A few tips

Creating and configuring load balancers is currently only possible via the API. The extensions to our Go SDK, Terraform provider and Ansible collection, which are based on our API, will be published over the next few days. Existing load balancers will also be displayed in our web-based cloud control panel; this method of configuration has been planned for a later date. It goes without saying that the API calls required to use our load balancer service are described in detail in our API documentation. You will also find sample requests and responses for every supported call there. Please note that the API specification is currently still designated as "beta", and we reserve the right to carry out further adjustments that are not fully compatible with the current state.

The virtual servers, which incoming connections are to be distributed between, need to be accessible from the load balancer via a private managed network. Two different use cases are supported for the load balancer itself: it can be created with a public IP address (VIP) and thus accept requests from the Internet; or the VIP may already be located in a private network itself, which means that the load balancer can be used e.g. for services within a Kubernetes cluster.

With load balancers "as a service" you can rely on a tried-and-tested concept with immediate effect without having to worry about the individual components yourself. As incoming traffic is always diverted completely automatically to a functioning system, it is simple for you to optimize the availability of your online services for your users. Reliability – as a service.

Our engineering for your VIP.
Your cloudscale.ch team

A new home for our status page

Over the past five years, you have been able to find information about planned maintenance work and any incidents on https://www.cloudscale-status.net. You also have the option of subscribing to email or the RSS/Atom feed to receive up-to-date information at all times. To ensure that this channel of communication is not affected by interruptions to our normal cloud infrastructure, we run our status page in a separate data center and use a different domain outside our standard ".ch" TLD.

Although the status page proved to be very successful, it was time to re-evaluate the setup. We decided to use a specialist provider to host our status page going forward so that we can not only maintain the service for you but further improve it. We selected the German service provider Statuspal. The switch, which is planned for within the next two weeks, will require status page downtime of about one hour. It goes without saying that this will not affect our cloud services.

Renew and adapt subscription

We will include the history of existing status notifications on the new status page so that you can continue to see all the entries relating to past events. As we ran the previous system ourselves and are now going to rely on an external service provider, we will intentionally not be migrating the list of notification subscribers to the new system. If you would like to be notified immediately of new entries in future, too, please simply subscribe to the desired categories again after the switch.

With the new status page, you also have the possibility of receiving notifications directly in one of the supported chat systems, such as Slack and Teams. In addition, further tools can be connected via webhooks, including Mattermost, Rocket.Chat and – with a little engineering – also other tools that support webhook integration. If you already use a chat channel to coordinate things relating to your cloud resources, our up-to-date service information will appear directly where it is needed.

Same URL, fresh design

Although the address of our status page remains https://www.cloudscale-status.net and will continue to be linked to from our https://www.cloudscale.ch website, we recommend that you save the status page separately in your bookmarks to ensure that you can also find it if our website ever fails.

The service categories from which you select the information that is relevant to you will also remain unchanged. The layout will be even simpler and you will be able to see intuitively which entries and updates belong together.

Make sure not to miss the latest maintenance and service information in future either. Add "https://www.cloudscale-status.net" to your bookmarks and – after the switch – renew your subscription to the desired notifications and channels of communication.

Status: Operational.
Your cloudscale.ch team

Main focus: technology

Our engineers have a great deal of freedom in their choice of work tools, in terms of both hardware and software. It goes without saying that employees also select their own work device. This typically consists of a notebook (in addition to MacBooks, Linux setups are also a popular choice) and a large monitor. In terms of IDE, for example, options include JetBrains products as well as vim and Visual Studio Code. Shared tools currently include GitLab and Confluence.

Broad-based and in-depth skills are not only required but also fostered at cloudscale.ch. There is a further training budget for every employee that consists of a certain number of workdays and a financial element. Given that people's interests vary greatly, each employee can select whether and where to use this budget, with no questions asked. They may choose books to help gain in-depth individual knowledge of a topic, but may also opt for conferences and courses run by specialized providers. It goes without saying that a contribution can also be made towards further training that exceeds this budget, with specific details depending on the individual case. In addition, knowledge is exchanged within the team, e.g. through internal training sessions, mutual code reviews or spontaneous day-to-day discussions.

Open source with a special touch

At cloudscale.ch we rely on existing tools and frameworks as well as on our own developments. Our cloud is based on OpenStack and Ceph, two leading open source projects in their respective fields. While we developed the web-based cloud control panel and the API that our customers use ourselves from scratch, we also use existing elements such as the Django REST framework. Where we feel it is useful, we also contribute to open source projects, e.g. in the form of extensions and bug fixes.

We are committed to quality – in all its facets. In addition to the performance and availability of our cloud services, this also includes the user experience. Our customers' points of contact with our cloud – from the control panel to the API and to the documentation – are carefully prepared to ensure that, wherever possible, stumbling blocks never even develop. This includes tests at all levels, from unit tests to integration tests and to acceptance tests, which we also publish. Further measures comprise code reviews and manual tests. We take the time needed to deliver solid work and to go the metaphorical extra mile if necessary. This is why we do not issue releases according to a fixed schedule but instead when they are ready and have met our quality standards.

Autonomy in terms of working hours and workplace

Many cloudscale.ch employees – parents and non-parents alike – work part-time in order to ensure they have enough time for their personal duties and commitments. We are also flexible in terms of working hours and allow employees as much freedom as possible. With the exception of Mondays, when we all meet at the office, working from home is a popular option, which also facilitates the coordination of the various parts of people's life. Using notebooks and the necessary tools, we have everything required to enjoy the flexibility that this well-established model affords us.

On Mondays, when we are all in the office, we have an all-hands meeting for coordination purposes and to share information that may affect everybody. This is then followed, in alternate weeks, by sprint planning or a bi-weekly meeting for technical matters. In addition, there are retrospectives at longer intervals as well as short dailies. Otherwise, we arrange meetings and calls when they are specifically required, e.g. to discuss details of a planned feature, according to the principle of as much as necessary, as little as possible.

We regularly look for new people to join our System Engineering and Software Engineering team at cloudscale.ch. If you speak German and English and would like to join the team, please send an email to jobs@cloudscale.ch. The application process may differ on a case-by-case basis, but generally involves getting to know you personally in an online meeting followed by a technical interview at our offices in Zurich. You will then have the opportunity to meet the rest of the team over a drink of your choice in an informal setting to see whether the "chemistry" is right. And if everything works out, we will soon be saying:

Welcome on board!
Your cloudscale.ch team

All sorted with prepaid

Prepaid offers are popular and we all know them from mobile SIM cards and prepaid credit cards. The advantages are obvious: you know exactly where you stand at all times and setting your budget in advance means that there are no surprises at the end of the month. Prepaid mode is particularly well suited to services without basic fees, such as those offered by cloudscale.ch.

To use our cloud services, add an amount of your choice to your account or your organization. The minimum payment is just CHF 10, which gives users a risk-free way of seeing whether our services are right for their use case. When you use services, these are deducted from your credit every day; otherwise the credit remains in your account or organization and can be used at a later date.

Increased flexibility, improved usability

With immediate effect you can now also select TWINT to load your credit. This payment system, which is supported by many Swiss banks, can be used in multiple ways both online and offline and has become popular within a very short time. We are delighted to be able to meet a significant need of our Swiss customers with TWINT.

It goes without saying that you can also continue to use the previous payment methods, which consist of Mastercard, Visa, American Express, PostFinance Card and E-Finance as well as PayPal. Our payment service provider is now Datatrans Ltd., which means that the payment process in our cloud control panel has a new look. We particularly like the clear user guidance and the overlay design, which integrates almost seamlessly into the control panel and makes loading your credit even more elegant.

Unchanged general conditions

Nothing has changed in terms of the general conditions pertaining to your credit. With an unchanged maximum balance of CHF 3000, you can decide how long your credit should last. To-the-second billing also remains unchanged. When you delete a service, any costs that were charged for 24-hour use are credited back to your balance on a pro-rata basis. And it goes without saying that, for every payment made, you receive an email with a VAT-compliant invoice, which can also be downloaded from the control panel.

Usability is a top priority for us. The current switch not only entails cosmetic improvements: with TWINT, we are delighted to offer a new and popular Swiss means of payment, which is an ideal complement to established international payment solutions and PostFinance.

Let's twint!
Your cloudscale.ch team

DevOpsDays Zurich has now become a fixed date in our calendar and cloudscale.ch was once again there in 2022 as a sponsor. Prepared and spontaneous topics from the wide field of DevOps were addressed and expanded in different formats, including e.g. classic talks as well as open spaces. Oliver Goetz's talk was particularly relevant from today's perspective, covering the (further) development of a cloud-based smart metering system that coordinates energy suppliers and users. The presentation included MVPs and a small, physically reconstructed model.

OpenInfra Summit

In early June, one of our engineers took the night train to the OpenInfra Summit at the Berlin Congress Center on Alexanderplatz, where the Chaos Communication Congress has also been held in the past. Under the last corona restrictions, about 1000 participants from around the world engaged with OpenStack, Kubernetes, containerization and developments surrounding CSI. Insights were also provided into confidential computing and encrypted workloads. It goes without saying that interpersonal relations were not neglected at the three-day conference with plenty of opportunities to develop and maintain contacts.

OpenStack Ops Meetup

Following the OpenInfra Summit, the one-day OpenStack Ops Meetup also took place in Berlin. The main focus of the moderated sessions were discussions with other operators of private and public OpenStack clouds, which centered on, for example, extremely practical matters that are on the agenda everywhere: from applying the regular upgrades, to challenges associated with growth, and to various deployment approaches. Here again, the closing dinner provided further opportunity for personal discussions, where suddenly you might find yourself talking to a Swedish cloud provider.

Swiss Python Summit

Python plays a key role at cloudscale.ch, as the language that not only most of our own software is written in, but also for example OpenStack. We took an appropriately large delegation to Swiss Python Summit with its wide-ranging program on the OST Campus in Rapperswil-Jona. Memorable talks included "Automating teaching about automation in Python" by Florian Bruhin and, of course, "Rust for Python Developers" by our own Dave Halter. In glorious weather conditions we also met many familiar faces, including some from Coredump Hacker- und Makerspace in Rapperswil-Jona.

Cloud Native Day

On a beautiful autumn day, Cloud Native Day was held on Bern's Mount Gurten, and cloudscale.ch was once again involved as a sponsor. At the two-track event, Kubernetes and cluster APIs were two of several key topics. Florian Forster went beyond pure containers in his talk. Taking the example of ZITADEL, an open source identity provider that can also be used for single sign-on with our cloud control panel, he spoke about his practical experience of switching to "serverless". Cloud Native Day ended with the after-party, which even the onset of rain could not dampen.

Dataspace Switzerland

This year, in addition to these events with a more technical focus, cloudscale.ch was also a partner of Dataspace Switzerland, the series of events by swiss made software. June was all about the Swiss Confederation's National Cyber Security Centre (NCSC), current threats such as ransomware, IoT, the American CLOUD Act and, last but not least, the "human factor". The main focus of November was the new data protection law. It became clear that almost all companies still have things to do before the legislation comes into force on 2023-09-01, and practice-focused talks showed how to make sure the next steps on this journey are successful.

Ansible Zürich Meetup

After a year's break, it was time again in late November for the Zurich Ansible community to get together for the meetup not far from our office. In their presentations, three speakers provided an insight into best practices and offered tips on using Ansible for experienced and less experienced users. Shop talk then continued over American hot dogs, waffles and drinks, also with some employees of Red Hat, the company that has long been behind the popular automation tool.

The wide range of events and the active participation show that IT and cloud are not merely technical matters. Whether you are a user of a complex system or an engineer, personal discussions help you to keep your eye on the ball and to drive technology forwards together. Do you know of an event that should not be missed? Please let us know as we are already looking forward to interesting discussions in 2023.

See you soon!
Your cloudscale.ch team

Onboarding with a broad and practice-focussed perspective

Not all cloudscale.ch engineers are typical cloud users themselves, which is a good thing. Our teams deal with hardware, virtualization and the ongoing maintenance and further development of our whole infrastructure, among other things. This is what makes it possible for you as a user to access the resources you require within seconds, either at the press of a button or in a completely automated manner.

Proximity to our customers and their concerns is a top priority for us here at cloudscale.ch. This is why we have compiled a collection of short exercises for engineers who join our company in order to enable them to get to know our offer and its associated features from a customer perspective, too. The insights gained in this way are useful in manifold ways – and not least when it becomes necessary to recreate our customers' concerns and respond to them competently.

Learning by doing – for our users, too

It was clear to us that guided exercises of this kind, which relate to the features and tools and can be completed independently, are not only useful for our own engineers, but are also beneficial to users at our customers and partners. This is why we have published this little tour of our services on GitHub.

In addition to a short introduction, the cloud exercises also contain links to relevant blog entries for each area. However, there are no actual instructions or a one-size-fits-all solution. The journey is its own reward. By spending time on a previously unknown feature or tool, you develop your own understanding piece by piece. And if you find yourself racking your brain in vain, we here at cloudscale.ch are happy to give you a few pointers – irrespective of whether you are one of our new colleagues or one of our customers.

The cloud exercises also make it clear that several paths frequently lead to the same destination. Use the exercise examples as an opportunity to try out various approaches for yourself. And who knows, maybe you will come across a solution by chance that will soon become indispensable.

Practice makes perfect!
Your cloudscale.ch team

Default project

While many of our users work on several cloud projects at once, these often differ greatly in scope. By setting your most frequently used project as your "default project" in your account settings, you can get going immediately after logging in. It goes without saying that you can continue to access your other projects with just two clicks of your mouse.

Search in the dropdown

You can move intuitively between your projects by selecting them from the dropdown field. And to make things even faster, simply type a few letters from the required project name (even from the middle of the word) into the open field and confirm by pressing Enter. This also works for most other dropdowns in our control panel.

Time zone and format

You will find dates and times in various places in the control panel, which allow you to see immediately when, for example, a server was created or an API token was last used. It goes without saying that time stamps also play a key role in the various logs. In your account settings, select the time zone and format that will best support you in your work.

Two-factor authentication

Protect your cloudscale.ch account with two-factor authentication (2FA). This is where, when logging in, on top of your normal password, you will be asked for a token (also known as a one-time password or OTP), which you generate with your smart phone, for example. Store the corresponding recovery code in a safe place, too, in case your smart phone is ever not available.

Login notification

Under the "Sessions" menu item you can indicate whether you want to be informed of logins to your cloudscale.ch account. Particularly in cases where you take advantage of SSO with your own identity provider to log into our control panel, it is recommended that you have an additional password-based "break glass" account with enabled notifications in case this account is actually used.

Default SSH keys

Upload the public SSH keys of your colleagues into our cloud control panel, too, so that you can grant them access from the outset when creating new servers. You can use the "star" icon to determine which of the keys should be preselected, and it goes without saying that you can adapt your selection when you launch each individual server.

Server groups

Anti-affinity ensures that correspondingly grouped servers (e.g. three web servers in a load-balancing cluster) run on different physical systems at any given time. This enables you to minimize the impact of a potential hardware problem on your overall setup. "Server groups" provides you with an overview of your existing groups, allows you to rename them if required, and to create new groups in advance, e.g. if you then want to reference them in an automated setup.

Default zone

To prepare for improbable but potentially serious events, such as fire and earthquakes, we recommend geo-redundant setups at our two cloud locations. Select the location where you carry out more frequent changes as your default zone for the project in question. When you create new servers in the web-based control panel this zone is preselected; when you launch via API, it is applied whenever a zone is not explicitly indicated in the API call.

Automatically set reverse DNS

If you want to set a specific reverse DNS entry for an IP address, you can make this change at any time via the control panel. If you specify a "Fully Qualified Domain Name" (FQDN) as the host name at the time you create a server, this is automatically used for the reverse DNS. You can, of course, change it again at any time in this case, too.

Console log

Nothing is perfect – and this applies in IT at least as much as anywhere else. If a server has stopped responding, a reboot usually helps, which you can trigger via the control panel if necessary. Have a look at the console log first. You will often find information there that the server has written to the serial console in connection with the system crash, which may help you to resolve the issue.

Host keys

The public SSH keys of the server are also output to the console log when cloud-init generates them during the initial boot-up. Our system collects them from there and displays the corresponding fingerprints in the control panel. This allows you to verify that you are communicating directly with the correct server at the very first SSH connection – even before it can be checked using your known_hosts file.

Everyone has an individual working style and, in many cases, different approaches lead to the desired result. So, make sure you use the defaults and features in a way that suits you and your projects. For collaborative work on cloud resources, you can find even more guidance in Collaboration – the key concepts, and we have compiled a few tips for your optimal cloud setup in How to Make Optimal Use of Our Infrastructure.

Well thought out from all angles,
Your cloudscale.ch team

At cloudscale.ch, we offer our customers IT infrastructure "as a service". Virtual servers ranging from really small to really large can be created in no time at all and can then also be scaled and deleted again at any time. This saves our customers from having to procure and maintain hardware, operate data center infrastructure, and guarantee connectivity. It goes without saying, however, that computing power, storage space and network connections are still based on correspondingly dimensioned physical resources that cannot be moved at the drop of a hat in the case of a power failure.

Data centers have taken precautions

This makes it all the more important to have an energy supply that is as reliable as possible. For this reason, cloudscale.ch was extremely intentional from the outset in its choice of the data centers we use and that we also draw power from. The data centers at both cloud locations have two separate power supply lines into the building, two dedicated power supply lines to our hardware, plus UPS systems and diesel generators that kick in without delay in the case of a power failure. Franz Grüter, Chairman of the Board of Directors of Green Datacenter AG, which our customers know as the "LPG" location, was quoted in the Tagesanzeiger newspaper as saying: "Our data center will continue to work even in the case of a blackout."

The data center operators at both cloud locations are continuously monitoring the situation and taking further optimization measures wherever possible, e.g. with an increased diesel reserve and supply contracts. As far as we know, both our locations have already been officially classified as "critical infrastructure". In addition, the sector is committed to raising awareness among decision-makers of the significance of IT infrastructure for all areas of life.

Risk minimization through redundancy

It goes without saying that, here at cloudscale.ch, we are already committed to minimizing the consequences of isolated incidents, which can never be completely excluded, as far as possible. This means that our Internet connectivity is designed in a redundant manner with several direct connections to various IP transit providers with equipment on their side that is also protected by two circuits, UPS and diesel generators.

With two cloud locations that work independently of each other to the greatest degree possible, we also make it possible for our customers to build geo-redundant setups. This allows you to additionally protect yourself against worst-case scenarios, even though we are convinced that, thanks to the measures already in place, there is no need to fear power failures over the winter.

At the moment, nobody knows what will actually happen this winter given that influencing factors range from international energy markets all the way to the weather. The data center operators at both our cloud locations have, however, always taken precautions, which means that, thanks to UPS systems and diesel generators, they can also cover longer interruptions, thus guaranteeing continuous operation of our servers.

Long-term preparations will prove their worth!
Your cloudscale.ch team

Transition phase for old compute flavors – switch now

The new flavors offer various memory/CPU ratios and thus fit even more precisely for the most varied of workloads. Most of the new flavors are also considerably cheaper than the previous ones with similar specifications. Since 2022-07-01, only the new flavors can be selected in our web-based cloud control panel. The old flavors are, however, still available to a limited extent during a transition phase, with existing virtual servers continuing to run unchanged and the old flavors remaining available via API for automated setups.

This transition phase will run until 2022-08-31. Scale your existing servers to one of our new flavors by this date. This only takes a few seconds and can be carried out when it suits you, e.g. when you have to restart your servers anyway to install security patches. Any servers that are still using an old flavor can be identified by a yellow icon in the cloud control panel.

Adapt any automated setups by 2022-08-31, too, in order to ensure that they are only using our new flavors. In the case of the Docker Machine driver, you can either explicitly specify a new flavor or you can use the latest release, which uses a new default value. For the Rancher UI driver, please ensure that all node templates under "GLOBAL APPS > Cluster Management > RKE1 Configuration > Node Templates" are using one of the new flavors. The same applies to Terraform configurations and Ansible playbooks.

Based on current hardware

A significant advantage of using cloud services lies in the fact that the cloud provider deals with the hardware. In addition to maintenance and troubleshooting, this also includes the ongoing evaluation and procurement of new hardware. At cloudscale.ch, we have relied on AMD-based hardware for quite some time now, e.g. due to the large number of PCIe lanes in the case of our storage hosts with NVMe SSDs.

With a view to launching our "Plus" flavors with dedicated cores, we introduced AMD CPUs for our compute hosts as well, and their percentage has been increasing ever since. Now we are decommissioning the previous Intel-based compute hosts. Virtual servers that have been running with Intel CPUs (identifiable in e.g. /proc/cpuinfo) will automatically be migrated to one of our current high-performance AMD compute hosts as soon as you scale to one of the new flavors.

Further advantages

In terms of price, you have already been benefiting automatically: where the new flavors are cheaper than old flavors with comparable specifications were, we have applied the lower price since 2022-07-01 to existing servers with old flavors as well. There are, however, further reasons to scale now. The new Flex-4-1, for example, offers double the memory of the old Flex-2 for the same price, while the new Flex-16-8 comes with 8 instead of the 6 vCPUs of the old Flex-16.

In the case of numerous workloads, there is additional potential for saving money given that the new "memory-optimized" and "CPU-optimized" flavors allow you to adapt your servers even more precisely to your specific needs without having to pay for underused resources. Or you can take the opportunity to test how your application performs if you switch from "Flex" to "Plus" (or vice versa).

Please note that we will only be running the old flavors (with just one digit in the name) until 2022-08-31. Scale existing servers by this date to any one of our new flavors (with two digits in the name) in order to not only ensure a continued smooth operation, but also benefit from potential improvements to the performance and cost efficiency of your servers. It goes without saying that you will also enjoy the same benefits with automated setups. Simply adapt your tooling to the new compute flavors by 2022-08-31.

Ready when you are!
Your cloudscale.ch team

Cloud server use cases are as individual as our customers. This is why, from the outset, we have offered flavors in various sizes at cloudscale.ch. And in contrast to with your own physical servers, you can scale your virtual servers in no time with us, always matching your current requirements.

With immediate effect, additional compute flavors with different memory/CPU ratios are available to you. This means that you can book a lot of CPU performance for compute-intensive workloads (e.g. batch processing) without having to pay for unused memory. For other applications, such as certain database setups or the delivery of static files, it may be worth keeping all required data in memory. In this case, you can select a flavor with a relatively large quantity of memory compared to the number of vCPUs or dedicated cores.

Details of the new compute flavors

Starting with the best news: In most cases, our new compute flavors are considerably cheaper than the previous flavors with comparable specifications. And thanks to the wider selection of compute flavors that even better covers the requirements of the most varied use cases, costs for your virtual servers can be further optimized.

The familiar flavor names "Flex" (shared vCPUs) and "Plus" (dedicated cores) have been maintained. They are now composed in a uniform manner according to the scheme Flex-<Memory>-<vCPUs> and Plus-<Memory>-<Cores>, which provides immediate clarity in terms of the specifications of the compute flavor in question. We have, however, gone one step further and decided on a purely linear price model:

• Irrespective of whether Flex or Plus, 4 GB of memory now cost CHF 0.5 per day.
• In terms of processing performance, Flex flavors cost an additional CHF 0.5 per vCPU per day, and Plus flavors an additional CHF 1 per dedicated core per day.

This means that a "Flex-4-2" with 4 GB memory (CHF 0.5) and 2 vCPUs (CHF 1) costs CHF 1.5 per day, while a "Plus-32-4" with 32 GB memory (CHF 4) and 4 dedicated cores (CHF 4) costs CHF 8 per day. To make things easier to understand, we will continue to list prices per day (i.e. 24 hours). It goes without saying that you will, however, still benefit from to-the-second billing for your cloud services.

Simply scale to the new flavors

Our new compute flavors are available to you with immediate effect in the cloud control panel and via API. When scaling existing servers, please note that only AMD CPUs will be used for our new flavors, which means that details visible in your server (e.g. in /proc/cpuinfo) may change.

Where the new flavors are cheaper than the corresponding old flavor with similar specifications, we already apply the lower price to the old flavor, which means that you also benefit if you are not immediately able to scale to a new flavor.

During a transition phase until 2022-08-31, servers can still be started with old flavors via our API. This means that for the time being automated setups, e.g. in Ansible and Terraform, will continue to work and you can take your time adapting them. However, we decided against simple "renaming" of flavors; if our API suddenly returned "Flex-4-2" instead of "Flex-4", tools such as Terraform might unexpectedly identify a need for action. Over the coming days, we will publish an update for users of our Docker Machine Driver and Rancher UI Driver, which will be adapted to our new flavors.

Irrespective of your use case, a cloud server is always suitable as it can be adapted to your current requirements at any time. You can now also enjoy this flexibility at cloudscale.ch if your application is particularly memory- or CPU-heavy as our new flavors enable you to book exactly what you need, while also allowing you to benefit from our new and better pricing.

The right flavor for every taste!
Your cloudscale.ch team

External view of our DNS servers

The authoritative name servers of cloudscale.ch are important for our customers in various situations. They make it possible, for example, for our own services to be found and then used. This includes access to our website and the cloud control panel via a browser, as well as sending requests to our API from client-side tools. In addition, the domain names of our Object Storages need to be resolved to IP addresses, also for visitors of third-party websites if static content from our Object Storages is embedded there. Furthermore, our name servers respond to what are known as reverse lookups: our customers can determine a reverse DNS name (PTR record) for their virtual servers and Floating IPs, which is then published via DNS and can be queried from our name servers.

If a DNS query is made for one of our IP addresses or domains, the DNS client (starting from the root zone and following the DNS hierarchy) first identifies our name servers and then asks them for the required information. We currently have three public name servers: we run ns1.cloudscale.ch at our "RMA" cloud location in Rümlang (Canton Zurich) and ns2.cloudscale.ch at our "LPG" location in Lupfig (Canton Aargau). Although we have taken numerous measures to protect our cloud locations against failure, including redundancy in terms of Internet connectivity and hardware, we additionally run ns3.cloudscale.ch outside our own infrastructure. The three name servers are completely independent of each other and can respond to DNS queries directly without having to rely on a central component such as a joint database.

Concealed control infrastructure

The decisive data source for our public name servers is an internal DNS setup that cannot be reached from the Internet. This is also designed in a geo-redundant manner and constantly replicates its dataset between our two cloud locations. Changes to DNS entries are fed into this internal DNS setup in a first step. A special control service then tests, several times a minute, whether new or changed entries are present and initiates zone transfers where necessary, which enables the public name servers to update their copy of the data. Changes to DNS entries – most commonly new reverse DNS entries from the cloud control panel – generally become visible from the Internet within ten seconds.

Tried-and-tested technology

The DNS protocol itself is already designed with a certain degree of fault tolerance. It is common (and in certain cases mandatory) to have two or more authoritative name servers for a zone, such as a domain. If a DNS client does not receive a response to a query, it shortly afterwards automatically tries again with another one of these name servers. However, a delay of this kind may have undesired effects, which is why, for our DNS setup at cloudscale.ch, we not only have a redundantly designed physical infrastructure, but also tried-and-tested software components and configurations to avoid failure wherever possible. And last but not least, the systems involved in the DNS are closely monitored here so that we can intervene in good time if necessary.

By the way, if you specify a "Fully Qualified Domain Name" (FQDN) as the server name when creating a virtual server, it is automatically recorded in our DNS setup as a reverse DNS entry to the IP addresses of this server (IPv4 and possibly IPv6). Floating IPs take over the reverse DNS of the virtual server that they are initially assigned to. You can adapt the reverse DNS of servers and Floating IPs at any time in order to ensure that they match the DNS entries in your own domain.

Even beyond web and email addresses, the Domain Name System is involved practically everywhere. Here at cloudscale.ch, it is important to us that the DNS resolution of our domains and IP addresses functions reliably, as this is essential for our customers to be able to manage their cloud resources via the cloud control panel and API as well as access our Object Storages. With a carefully designed geo-redundant DNS setup without single point of failure, we help to ensure that using our services is not only simple but also smooth.

This is what our (domain) name stands for!
Your cloudscale.ch team

Information is more important than ever today. At the same time, there has been an increasing focus on protecting information, which in turn raises the significance of standards, such as ISO 27001 that covers various aspects relating to information security. ISO 27001 certification is important for many of our customers – not only for selected service providers or data centers, but for the whole data processing supply chain.

For this reason, we already had cloudscale.ch certified in accordance with ISO 27001 as early as 2019, consequently committing ourselves to regular audits. Following our recent successful "recertification audit", our certificate was renewed without interruption. You will find the current certificate, which is valid until 2025, on our website and can download it for your files.

In addition to the universally applicable ISO/IEC 27001:2013 standard, we were also audited in accordance with the ISO/IEC 27017:2015 and 27018:2019 standards. These two standards were developed as extensions to ISO 27001 and define complementary controls that are particularly relevant to cloud services and to processing personally identifiable information in public clouds.

Continuous improvement as an integral component

We only recently announced that an ISAE 3000 report, which also deals with information security, is available if required. Although it is a coincidence that these two announcements are made so close together, it is no coincidence that this topic is consistently relevant for us. While ISO 27001 certificates are valid for three years, the standard mandates annual audits through the accredited certification body. This means that once the certificate has been issued, there are two "surveillance audits" and then a more comprehensive "recertification audit" for the renewal of the certificate.

In addition to this, internal audits also need to be performed every year. To achieve certification, it is not, however, enough for the tested processes to meet the requirements of the standard at the time of the audit. Moreover, the processes themselves need to be continuously further improved.

Useful features for enhanced security

With cloudscale.ch, you are choosing a cloud provider that not only takes data protection and information security extremely seriously, but also monitors this by means of independent audits. As mentioned above, it is essential that information security is implemented at all levels. We therefore provide a range of features that help customers enhance data security in their own areas of responsibility.

These include various options for collaboration in our cloud control panel, which mean that you can use cloud services in a corporate context, too, without needing to share accounts and passwords. Graduated access rights for each project and the use of two-factor authentication (2FA) enable you to add extra protection. And if you already use an "OpenID Connect"-compatible identity provider, such as Keycloak or ZITADEL, you can also benefit from single sign-on when logging into our cloud control panel. This means that you not only control the log-in process yourself, but you make things more convenient for your employees at the same time.

Although standards, processes and audits are sometimes perceived to be a little "dry", information security is not created on paper, but needs to be lived out in day-to-day routines. Our recent recertification audit in accordance with ISO 27001, 27017 and 27018 once again proved that we have our eye on the ball here at cloudscale.ch.

With trust comes responsibility!
Your cloudscale.ch team

Images as the base for new cloud servers

In order for new cloud servers to be available immediately, the operating system is not installed manually (e.g. from a DVD), but instead the root volume is prefilled with an image when a new cloud server is launched and this installation template is then further configured during the initial boot process.

You have been able to import and use your own images for a while now at cloudscale.ch. This enables you to create virtual servers in no time at all using a different operating system to those provided by us or using software and configurations that are completely adapted to your requirements. Where there are several available image files from distributors or third-party providers, it is often the case that one of them has been specifically optimized for OpenStack environments like at cloudscale.ch.

Managing custom images in the cloud control panel

Managing custom images is now also possible in our web-based cloud control panel. Even if you are not using our API, the cloudscale.ch CLI or the DevOps tools we support, such as Terraform and Ansible, you can now import your own images at cloudscale.ch in order to start one or more virtual servers on this base. In addition, it is now possible to import images directly in QCOW2 format without needing to convert them to RAW first. It goes without saying that you also benefit from this simplified process if you continue to import images via API.

We recommend that you use cloud-init for your own images, too. Using cloud-init, virtual servers can apply numerous settings automatically during the boot process, e.g. relating to the name and IP address of the server. You can also hand over many other options to cloud-init as "user data" at the time you create the server. In addition, you can specify for each custom image how our system should handle the user data. This is of particular significance if your image uses Ignition, which serves a similar purpose, rather than cloud-init. You will find further details about this in the documentation.

Whether you are compiling a customized image with your preferred tools and settings or using a comprehensive complete package from a third-party provider, managing and using your custom images has now become even easier at cloudscale.ch.

For the right base,
Your cloudscale.ch team

Most people tend to first think of accounts when they hear the term "audit". However, correct financial statements alone are often not sufficient and other processes, e.g. those relating to IT, may be important for the survival of a company and therefore be included in audits and business reporting. This is where a report based on ISAE 3000 comes in.

The abbreviation "ISAE 3000" stands for "International Standard on Assurance Engagements 3000", which is an international test standard issued by the International Federation of Accountants (IFAC). The standard creates a uniform framework for "assurance engagements other than audits or reviews of historical financial information." In the process, an independent auditor checks the internal control system of a company or specific division and produces a corresponding report.

While ISO 27001 deals specifically with information security and prescribes more than 100 associated controls, ISAE 3000 basically does not include any requirements relating to controls or internal control as such. However, the actual scope of an audit based on ISAE 3000 is disclosed in detail in the resulting audit report, which then allows readers to assess whether the tested controls meet their own requirements. To compare: an ISO 27001 certificate documents that the standard has been adhered to across its whole scope, but does not provide further details about its implementation.

Audit procedure based on ISAE 3000

A theoretical starting point is a worst-case scenario, e.g. "A burglar publishes secret data." To achieve the reassuring sense that this worst case will most probably not occur requires several steps. Once the risk has been identified, the next step is to formulate an objective to prevent it from happening ("Unauthorized persons have no access to secret data"). To achieve the objective, specific controls are in turn defined ("The server room is always locked", "The data are encrypted").

In an audit based on ISAE 3000, an auditor assesses three issues: do the controls seem suitable for achieving the objective? Were the controls actually implemented? Were they also effective?

By answering these questions for all the important processes and objectives of a company, an auditor can provide top management with a statement about whether the objectives have been achieved. It goes without saying that the auditor is not omniscient, but by using professional judgement and auditing a sufficient quantity of random samples, an adequately high level of certainty can be achieved about whether the assessment corresponds to (an ultimately always unknown) reality.

Reporting beyond corporate boundaries

Gaps in audits of one's own company inevitably occur wherever a process has been outsourced, e.g. when cloudscale.ch cloud services are used instead of running one's own servers and data centers. In this case, it makes sense for the outsourcing partner to be audited separately. This audit report enables auditors to close the gaps in their own audit and, once again, obtain a complete overview of processes within the company.

At cloudscale.ch, an audit report based on the ISAE 3000 standard is available to our customers with immediate effect. For a contribution towards the cost of producing the report, we will be happy to provide you with a copy if required. The specific nature of reports of this kind makes this particularly relevant for customers who are themselves audited based on a standard such as ISAE 3000 and who would like to or are obliged to close the above-mentioned gaps that exist in purely internal audits.

No surprises in terms of content

While a company can define its own objectives and controls for internal processes, a service provider such as cloudscale.ch needs to make a selection. This selection aims to cover the typical requirements of many customers, but cannot cater to every individual case. While the format of an ISAE 3000 report was completely new to us here at cloudscale.ch, the selected objectives and controls were tried-and-tested ones. From the outset we have consistently used our customers' requirements as a guide and taken those measures that we believe to be relevant to our customers.

While these include obvious matters such as limited access to our server systems and continuous training of our employees, they also include features such as at-rest data encryption and the option of separate private networks, as we have already reported on. The independent external audit and formal reporting are new; the specific measures that we take to contribute to the security and reliability of your cloud resources are, however, long established.

Our customers know and appreciate the technical focus that we have always had at cloudscale.ch and that we still maintain today. Preparing our first own ISAE 3000 report was a completely new experience for us. Now that we have committed to it, it feels doubly good that the technical foundation we have developed continuously also stood the test of a business audit. And, far more importantly, having an independent auditor's report means that we can help our customers in complying with their own specifications.

Objective achieved!
Your cloudscale.ch team

Use cloudscale.ch – alone or together

Andrea is a committed open source user. She regularly finds and tests new tools for all kinds of tasks. She uses cloudscale.ch in order to ensure that she always has a fresh system that she can play around with and then delete again. This enables her to start virtual servers with just a few clicks and to choose from a selection of the most popular Linux distributions, depending on the tool she wants to look at.

In her work, Andrea is Head of IT at Enjoy AG, a company that runs an online platform for restaurants and delivery services. So far, the platform has been running on a physical server that Enjoy AG set up with a housing provider. In addition, there is an on-premise server in the office that is used for the CRM among other things. Both servers are actually oversized in terms of performance, but they are getting old and Andrea is concerned that a hardware defect may result in business coming to a standstill for a long period of time. Simply buying new devices is not an option for Andrea as this would not resolve her concerns about the lack of redundancy.

Andrea would rather use the benefits of the cloud and, instead of an individual excessively large server, create a geo-redundant failover setup that can be scaled with the growth of her platform. In order to enable her and her employees to work on the new cloud setup together, Andrea creates a new organization "Enjoy AG" in the cloudscale.ch cloud control panel. This means that with just a single login, she has two completely separate areas: a personal one and a business one.

Invite and manage organization members

Andrea then creates invite links for her colleagues so that they can join the "Enjoy AG" organization with their own personal accounts. It comes as no real surprise that her employees Jeremy and Patricia are also already cloudscale.ch customers; the others quickly set up a new account for free via "Signup". Under "Members", Andrea has a constant overview of which colleagues have used the invite link to join the organization. She pays particular attention to the 2FA status and asks those who have not yet activated this feature to do so.

Under "Projects" Andrea first creates three projects called "CRM", "Test" and "Prod" to group the new cloud servers logically. If further projects arise in future, she can add these at any time. She could now add the appropriate employees for each project as project members and specify whether these people only have read access or also permission to make changes, e.g. to create or delete cloud servers. However, in order to make her life easier, Andrea decides to use "teams". In keeping with the established structure of Enjoy AG, she creates teams with the appropriate team members and then adds the teams to the projects. In the team "IntOps", she makes Patricia team leader, which means that Patricia can manage the team members herself in future and, for example, include any colleagues who switch to her team.

Include specialists as external collaborators

Following a request from the marketing department, the "Landing Pages" project is soon added. Susanna is a freelance worker who has been given the task by Enjoy AG of running web pages for various marketing campaigns on a separate cloud server. It is clear to Andrea that Susanna requires full access to the appropriate cloud resources for this, but at the same time, she does not want Susanna to see all the other projects and people involved in the cloud control panel. This is why she generates an invite link for an "external collaborator", which she sends to Susanna. As previously, Andrea could now set up a separate team with Susanna and the internal colleagues as team members. However, in this case, she believes it will be clearer if she allocates the existing "Platform" team plus Susanna to the "Landing Pages" project as project members.

Partnership between two organizations: clear responsibilities

Sven is Andrea's contact partner at Coders GmbH. He and his team developed the online platform for Enjoy AG and also help with maintenance and troubleshooting during live operations. On the old server, the developers at Coders already had SSH access, but without being able to see the server "from the outside", they were sometimes limited in what they could do to help. This will all change with the new cloud setup. Coders GmbH also already uses cloudscale.ch internally and all employees have personal accounts. Andrea does not, however, want to invite every single one of them to be an external collaborator, which is why she and Sven agree on a "partnership" between the two organizations. This means that she can share her "Prod" project with Coders GmbH, and Sven, as a superuser of the "Coders GmbH" organization, can add its teams and members to this project independently.

Unfortunately, Oliver leaves Coders GmbH shortly after this. He wants to take some time out in a peaceful mountain village so he can work on a few personal projects that are important to him. As well as for his work at Coders, Oliver also used his cloudscale.ch account for these projects, which is why he would like to keep his account. It is not a problem to make this wish come true as Sven can simply remove Oliver's account from the organization and thus also from the Enjoy AG "Prod" project.

With a little luck, Sven almost seamlessly finds a replacement in Christina. At the same time, he would like to progressively include Thomas, who is completing his training at Coders, in the collaboration with Enjoy AG. At the moment, as opposed to the other employees, all Thomas needs is read access. Sven is delighted that he can implement all these administrative adjustments himself without having to bother Andrea.

In the meantime, the new platform release is almost finished and both Enjoy AG and Coders GmbH are looking forward to offering the restaurants and delivery services numerous new features. The landing pages for the new campaign are also ready. As everybody has been granted the access required for their contribution, there is nothing more standing in the way of a successful deployment. And once the work has been completed in the various workplaces, there might even be a face-to-face meeting to toast the successful collaboration.

To successful collaboration!
Your cloudscale.ch team

PS: In order to ensure that administration of the organization does not depend solely on her, Andrea plans to make her colleague Jeremy a superuser, too, so that they can stand in for each other if one of them is absent, for instance. In the cloudscale.ch blog, she found the following overview that she forwards onto Jeremy so that he can get started quickly.

Collaboration – the key concepts

Projects: Cloud resources can be grouped in projects, e.g. for separate test and production environments. Access rights – either read only or with permission to make changes – can be defined separately for each project.

Organization: An organization represents a company, a department or any other group of people who work together on cloud resources. Organizations have a separate framework agreement and a separate balance, which makes them suitable for the contractual demarcation of cloud resources from other accounts and/or organizations.

Organization member: Organization members can work on projects of the organization. Irrespective of their rights for individual projects, organization members can – in the same way as employees in a company – see which projects, teams and other members exist within the organization.

External collaborator: Accounts that need to be able to work on one or several projects without having any insight into the organization beyond this can be invited as external collaborators. They will then only see these projects and not the other projects, teams and members of the organization.

Team: To simplify rights management, accounts (i.e. organization members and external collaborators) can be grouped into teams. Access rights for the team automatically apply to all team members.

Team leader: Team leaders can independently add and remove organization members and external collaborators as team members of the relevant team. Team leaders can also make other organization members (but not external collaborators) team leaders within the team and remove this role again.

Superuser: A superuser can manage all aspects of the organization. This includes managing projects, teams and rights as well as inviting and removing organization members and external collaborators.

Partner organization: The superusers of two organizations can agree on a partnership and share projects with the other organization. The superusers in the two partner organizations manage the access rights of their own organization members and external collaborators for the joint projects. As is the case for external collaborators, only the shared projects – and not the other projects, teams and members – of the other organization are visible.

Projects with internal and external participants

Several people often work together on cloud projects. However, sharing user accounts involves various risks and dangers. This is why many cloudscale.ch users work in what are known as "organizations" that represent, for example, a company or department. All organization members have personal login credentials and can enable two-factor authentication (2FA) for their user account. The organization's superusers determine which organization members and external collaborators are authorized to access which of the organization's projects.

A second company or other organization is often also involved when external participants are associated with a project. This is where the new "partner organizations" feature comes into its own: you can grant a partner organization the right to include the appropriate employees for the project independently, without you having to know details about who exactly has the required know-how or desired availability. Every time you share a project, you decide whether the partner organization should only have read access or whether it is given change permissions, too.

Partner organizations: delegate administrative tasks

Partner organization management can be found in the "Organizations" area of our cloud control panel. This is where you can initiate new partnerships as well as check and, if necessary, terminate existing ones. A partnership documents that two organizations know each other; it works both ways and, on its own, does not imply any kind of access rights to the other partner's projects or cloud resources.

As easily as you can add organization members, teams and external collaborators, you can now add partner organizations to your projects. This means that you allow the superusers of the partner organization in question to grant access rights to these projects to their own organization members and external collaborators. These access rights are limited to the access level you grant to the partner for the project in question. External superusers cannot, however, change (or even see) the rights granted to your organization members and external collaborators; you retain sole control of this.

Conversely, if a partner organization has shared one of its projects with your organization, you can add your own organization members, teams and external collaborators to this project as usual. NB: further delegation is not possible. Only the organization that owns the project can add partner organizations to it.

Well thought-out details for every scenario

As is the case for external collaborators, the internal details of your organization remain concealed from individuals in your partner organizations. The latter can only see those projects you share with them, but not other internal structures such as projects, teams, or potential further partner organizations. It is only in the case of changes that the acting account is visible in the corresponding project log, which ensures adherence to possible compliance specifications. It goes without saying that you can remove partner organizations from your projects at any time; all access rights associated with them will expire with immediate effect. Once you have withdrawn access rights, also check any API tokens in the affected projects as some of them may no longer be required.

The "partner organizations" feature is typically used when you need the active contribution of partners (such as customers or service providers) in your projects or when you would like to increase transparency and grant read access to your end customers. However, this is not only for corporate settings, as you can also use organizations and partnerships for associations, with your friends, and anywhere else that you work on a cloud project with different groups.

By the way, in addition to email/password and GitHub, we also support your own "OpenID Connect"-compatible identity provider, such as Keycloak or ZITADEL, for logging into our cloud control panel. The choice is completely yours; it is not necessary for all users to employ the same login mechanism for successful collaboration with partner organizations.

Partner organizations complete our feature set relating to collaboration. In addition to your own organization members and individual external collaborators, you can now also replicate partnerships at an institutional level in our cloud control panel. With every partner determining which of their organization members are the best match in the current phase, your project benefits to the greatest possible degree from the expertise and availability of everyone involved. And at the same time, you also minimize your administrative overheads.

Your partner in every scenario,
Your cloudscale.ch team

IT projects frequently start out small. This approach is often intentional in order to validate certain hypotheses quickly using a process that is as lean as possible and to continuously adapt the project in short iterations. And sometimes supposedly short-term experiments establish themselves and over time grow into an important product or tool. At cloudscale.ch, we make it particularly easy for you: within the shortest amount of time and with just a few clicks of your mouse, your first cloud servers are ready and can be changed just as quickly and easily when required.

It goes without saying that we also support the creation and management of your cloud infrastructure with Terraform. However, the things that provide consistency and efficiency in an established project would often represent nothing more than unnecessary overheads if applied in the initial phase. If the project then grows, you may at some point realize that a tool like Terraform would actually have been worth it. Given that in many cases you will not want to start from scratch again, the import function for existing resources means that, fortunately, you do not have to do so.

Import existing resources into Terraform

The starting point for Terraform is your configuration, which is where you define all the resources, such as the cloud servers that you need for your project along with their properties. Once these resources have been created, Terraform keeps a "state" in order to remember which resources in the real world belong to which definitions. If your specifications or reality change, Terraform can detect this and recreate the desired state during the next terraform apply.

To include an existing resource in your Terraform setup at cloudscale.ch, simply define it as usual in your Terraform config. Instead of then having it newly created with terraform apply, just use terraform import to link your definition to the existing resource, which you specify by means of its unique ID. You will find the details required for each resource in the documentation for our Terraform provider. By then running terraform plan, you can check whether Terraform still detects differences between the definition and the actual resource. Keep adapting the definition, if necessary, until Terraform no longer detects a need for change.

Things are special with regard to SSH keys, which are provided to a newly created cloud server by means of a metadata server and config drive and incorporated by cloud-init during the first boot up. As the handling of SSH keys is limited to this initial configuration, Terraform cannot read them from our API and store them in its state at a later point in time. With regard to importing servers, this means that you must not specify SSH keys; otherwise Terraform would detect a need for change every time, which would result in the server being deleted and newly created.

Additional values with data sources

At cloudscale.ch, you can import almost all your existing resources into your Terraform setup as described above, with the only current exception being "custom images". You may, however, not want an import, for example if the resources in question are already part of another Terraform setup. In order to still be able to access attributes of such resources and to use them e.g. in the definition of further resources, you can use data sources.

Data sources make all the important properties of your cloud resources available in Terraform. This means that servers managed by Terraform can, for example, adopt the flavor of a server outside your Terraform setup or be defined to have an interface in a manually managed private network.

Various "arguments" are available in order for you to access data sources. Use one or several of them to filter for the resource you are looking for. The values that can be used as an argument and other "attributes" of the resource are then available to you for further use in your Terraform setup. You will also find all the important information relating to the use of data sources in our documentation.

Terraform differs from conventional configuration management systems in that it allows an automated setup of your infrastructure as a "greenfield project" without you having to prepare servers or networks. In practice, however, many projects do not develop and evolve in the way that hindsight deems best. At cloudscale.ch, you can now, with the help of imports and data sources, integrate "legacy" resources of this kind into your Terraform setup as if they had always been there. Avoid having to start from scratch again when "tidying up" evolved setups and instead use your energy to advance your project.

Create order without the waste,
Your cloudscale.ch team

Container setups offer numerous advantages. Among other things, container orchestrators such as Kubernetes can ensure that the required containers are started at any time. If a node leaves the cluster (whether for maintenance work or for other reasons), Kubernetes can start the containers in question elsewhere in the cluster, thus re-establishing the target state. In such a case, CSI allows the persistent volumes (PVs) to be immediately available again as well: an appropriate CSI driver not only initially prepares the required volumes on the underlying cloud infrastructure, but afterwards also connects them to the correct node so that the container can access the volume and its data.

To allow a container to use the storage space of a PV in the first place, our CSI driver normally formats the volume with ext4 at the time of creation and then mounts it in the file system of the node from where it is made available to the container. Some workloads, however, are unable to store their data in a file system, but only on entire block devices. Rook is an example of this: In a Kubernetes setup, the Cloud Native Computing Foundation project can install, among other things, a storage cluster with Ceph and provide a storage service for other applications. When operating on physical hardware, Ceph would write directly to the hard disks for actual data storage and use its own optimized "BlueStore" format rather than partitions and file systems. In a Kubernetes setup, the physical disks are replaced by PVs that need to be available as raw block volumes.

Using CSI with raw block volumes

Raw block volumes are officially supported in Kubernetes from version 1.18 onwards. We introduced this option with version 3.1.0 of our CSI driver. To create a raw block volume, simply add volumeMode: Block in the persistent volume claim (PVC) (otherwise the default Filesystem will be used), as shown in the following example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pod-pvc-raw-block
spec:
  volumeMode: Block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: cloudscale-volume-ssd

In the pod definition please indicate the desired device path by using volumeDevices (instead of the mount point with volumeMounts):

apiVersion: v1
kind: Pod
metadata:
  name: my-csi-app-raw-block
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeDevices:
        - devicePath: /dev/xvda
          name: my-cloudscale-volume
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-cloudscale-volume
      persistentVolumeClaim:
        claimName: csi-pod-pvc-raw-block

The volume, which is thus created on our cloud infrastructure and is also visible in our cloud control panel or via API, is passed on "one to one" to the relevant pod and is accessible from the first to the last byte. It goes without saying that it is also possible to encrypt volumes of this kind within the pod, e.g. with LUKS.

As is the case for all volumes at cloudscale.ch, raw block volumes can either be stored on NVMe SSDs or on our bulk storage. You can also, as usual, scale up such volumes during live operation. Please be aware, however, that only the size of the block device is increased via the CSI driver and adjustments of partitions and file systems (if any) need to be performed in the relevant pod.

Different approaches for different use cases

Support for raw block volumes means that a Kubernetes/CSI setup is now also suitable for use cases that are not viable with purely file-based persistent storage. If you are interested in Ceph and would like to run trials, the above-mentioned Rook is an example of this. There are, of course, also reasons for using Rook with Ceph productively, e.g. if you require a CephFS backend for another application. Make sure you avoid potential single points of failure in this case. Where several pods (e.g. "mon" or "osd" in Ceph) guarantee redundancy, place these on Kubernetes nodes that are in anti-affinity to one another, as this means that an isolated hardware issue on one of the physical compute servers does not affect several of these pods at the same time.

Ceph is often used with a replication factor of 3, which is also the case for our own Ceph clusters that the NVMe-SSD and bulk volumes as well as our object storage are based on. If you are running your own Ceph setup on top of this infrastructure, this typically means that every data fragment filed in there is physically stored nine times. Evaluate for your individual use case how much (additional) redundancy you require and what level of overhead you are willing to accept. It might be that, for example, an NFS or database server of your own or, as an alternative, our object storage is also suitable as central data storage for your applications.

Cloud infrastructure and container setups are the method of choice for an increasing number of use cases as they offer maximum flexibility and scalability. Whether for a short test or for a productive HA setup, you can now make the most of these advantages in an even more versatile manner thanks to support for raw block volumes in our CSI driver. If you have any feedback or suggestions for improvement, please contact us via GitHub or directly.

Volumes to your taste, whether ready-formatted or raw!
Your cloudscale.ch team

Thanks to redundancy at all levels, our customers are unaffected by most isolated problems. Irrespective of whether a cable, a hard disk or a load balancer fails, the overall system continues without interruption. It goes without saying that we need to follow up on such cases and, for example, reinstate redundancy in order to ensure that our cloud remains as reliable as it is. Beyond detecting and reporting defective components, our monitoring also covers performance data and the correct functioning of complete end-to-end processes, which enables us to identify any required action in good time.

From the very beginning, we have relied on Zabbix as the linchpin of our monitoring and alerting at cloudscale.ch. Thanks to its versatility and adaptability, we have been able to use this tool to cover most monitoring requirements, which have increased in number and complexity over time. To complement our internal Zabbix, we also added external monitoring early on. On the one hand, this has allowed us to replicate additional use cases and to better include the user perspective. On the other hand, we are able to cover cases where our own monitoring is also affected by a problem and/or the generated alerts cannot be sent out for some reason.

Wide range of optimizations

In addition to our internal Zabbix, two external monitoring services now check the most varied aspects of our cloud that are "visible" from the outside, from object storage to API calls. All of this converges on the Opsgenie platform, which makes it possible to store the specified on-call schedules and to pass on alerts to the correct person. If the responsible engineer is ever unable to respond to a report immediately, it is automatically escalated to defined further persons. It goes without saying that the complexity increases with the number of services involved, which is why we use regular automated dummy alerts to test whether alert processing is working correctly and whether the setup is operational all the way to the mobile of the designated on-call engineer.

Escalating an identified problem correctly is only one part of the process. We also put a great deal of effort into optimizing the database from which the anomalies are extracted. Starting with an already broad set of values that monitoring systems typically read from a running target system, we added further checks that are in part even more hardware-oriented. This means that our monitoring can, for example, recognize if an NVMe disk has not negotiated the usual data rate on the PCIe bus. At the other end of the spectrum, abstracting from the hardware, we have an increasing number of checks that monitor the state of whole clusters without being dependent on a specific host to query. Thanks to a solid baseline of measurements, we can then determine threshold values in such a way that allows problems to be reliably identified without causing a lot of noise.

Why we can sleep at night

Although on-call engineers at cloudscale.ch tend to sleep through the night, the redundancy mentioned above and carefully considered threshold values only provide a partial explanation for this. Wherever an analysis during office hours is adequate, we have allocated a low severity level to the checks and set Opsgenie in such a way that nobody is woken up. Consistent follow-up processing is important here: even low-severity events and anomalies that occur during the day are investigated in a timely manner before they develop into a problem that necessitates getting up at night. If something ever has a greater impact, the same principle applies, and we almost always find a way to identify similar cases earlier or to avoid them completely in future.

On top of all this, there is one further, less technical aspect. Thanks to separate monitoring for our lab, new engineers can take the time they need to settle in without pressure, which enables them to quickly become aware of the things they need to pay attention to. And when resolving problems which cannot be completely avoided despite constant improvements, directly linked runbooks provide the required backing. If on-call engineers are woken at night, which tends to be the exception rather than the rule, it does not take long before they can go back to bed with confidence.

The reliable operation of our cloud infrastructure is key for many of our customers. It is based on the fact that we identify anomalies as early as possible, which allows us to avoid most problems before they have an impact on our customers. Our monitoring setup, which has grown and been consistently improved over the years, serves as our eyes and ears right into the furthest corners of our systems. At the same time, it contains the intelligence required to support and reduce the pressure on our engineers in their work.

You can sleep well (too)!
Your cloudscale.ch team

Since the complete overhaul of our cloud control panel, cloud resources can be used for several different projects. Access rights for these projects can be granted either for whole teams or for individual organization members. However, as is usually the case in companies, there is a certain degree of transparency for employees, which means that all organization members can see which other members, teams and projects are in their organization, even if they themselves are not part of the team or project in question.

This transparency may not be desired when cooperating with external persons. You can now, therefore, invite external persons to join your organization as "external collaborators", which ensures that they will have no insight into the internal structure of your organization. Managing your projects is as easy as it was: you can add external collaborators to your teams or grant them direct read or change access to the desired projects. External collaborators can then only see the projects they are actually authorized to see and have no access to details that refer to other activities or relationships. Irrespective of whether you would like to work with customers or service providers, the external collaborators feature will enable you to achieve the correct degree of transparency in every scenario.

Use tried-and-tested concepts

For maximum security we recommend that you work with personal accounts and do not allow several persons to share login credentials. At the same time, this will ensure that you can use the project logs to trace who performed a certain action if required. You can now also invite external partners to create a personal account at cloudscale.ch and send them an invite link that will allow them to join your organization as external collaborators. If any of your external partners uses an "OpenID Connect"-compatible identity provider and would like to benefit from single sign-on at cloudscale.ch as well, our support team will be happy to help.

Granting read and change access to your projects and adding external collaborators to teams follows the same principles as for organization members. External collaborators do not, however, have access to projects where you have selected "Grant access to all members of the organization". Instead, in order to grant selected external collaborators access to a project, you need to use the option of teams or individual access.

Incidentally, it goes without saying that just as for members of your organization, personal accounts are free of charge for external collaborators. They are, however, free to use cloud services separately from your organization at their own cost.

A few tips

Many companies have internal security guidelines, many of which explicitly require the use of two-factor authentication (2FA). In our control panel, you will therefore not only see the 2FA status for members, but also for the external collaborators in your organization. Any changes to this are also documented in the organization log. As opposed to for members of the organization, all other account-related actions of an external collaborator (e.g. logging in/out, changing the account password) are not included in the organization log.

The details of your organization are basically not visible to external collaborators. As soon as you grant access to a project, this also grants access to the corresponding project log, i.e. information about changes to the project and their initiators. This ensures that external collaborators can actually perform their assigned tasks (e.g. project monitoring or reconstructing a technical problem). External collaborators also see the stored email addresses of your organization (main email address and billing email address, if specified) and can select these as the sender's address for support tickets.

As a concept, external collaborators are predominantly in line with organization members, which means they can be effortlessly integrated into your existing access scheme. The small difference in the detail, however, opens up completely new areas of application: you can now also involve your customers or external specialists in the management of your cloud resources without them finding out about each other or about your internal matters. This means that committed cooperation on your cloud projects can be structured more efficiently than ever.

Better together,
Your cloudscale.ch team

From the outset, cloudscale.ch has relied on separate Ceph-based storage clusters. These store data on dedicated storage servers independently of the compute hardware, distributing the data across multiple storage servers and using triple replicated storage. During the expansion of our bulk and object storage, we also decided to replace the existing servers and, going forward, to exclusively use fast SSDs for the disks.

The new storage servers not only have faster disks, but also significantly higher-performance AMD CPUs and more RAM compared to the previous generation. This means that Ceph, which deals with data distribution and replication in the cluster, can work to its full advantage. Our system engineers also significantly increased the object storage caches. As we have continued to use particularly high-performance NVMe-SSDs for these caches, this provides an additional benefit for write operations and frequently read objects.

The advantages

One of the greatest disadvantages of conventional hard drives is their mechanical way of functioning. To write data onto the drive in a certain location or to read them from there, the read/write head has to be physically moved to the correct position and the magnetic disk turned until the desired location is underneath the read/write head. For many hard drives, this process takes an average of about 8.5 ms, but when multiple access to the disk is required simultaneously, the waiting time for a process that is further back in the queue can be considerably longer. The switch to "all-flash storage" for our bulk and object storages means that mechanical latency is no longer an issue and minimizes the mutual impact on performance when several customers require access at the same time.

A typical advantage of Ceph clusters that store data over multiple storage servers and disks can be seen in the case of simultaneous data access: there is no need for queues and consecutive processing as parallel execution is possible. However, this was not the case previously when two operations had to access the same physical hard drive. Due to the mechanics, only one read or write operation could take place at any one time. Thanks to the SSDs, parallel access is now possible even at the disk level and our customers automatically benefit from the higher overall performance of our bulk and objects clusters.

A few tips

You do not have to do anything to benefit from our all-flash clusters for bulk and object storage. The switch took place in May at the Rümlang (RMA) site and in mid-August at the Lupfig (LPG) site, and included all existing volumes and buckets. Please note that the rate limit of 500 IOPS remains in place for bulk volumes. This is to prevent excessive use of our clusters by individual customers with particularly disk-intensive applications to the detriment of other customers. For database applications, in particular, we still recommend our NVMe-SSD volumes, which have no limit of this kind and are specifically designed for the highest level of performance.

While the new setup means that the typical access time of rotating hard drives is no longer an issue, there is still a certain degree of latency: as our storage clusters are operated separately from the compute servers on different hardware, all disk access takes place via the network. For this reason, we recommend that you enable any caching options that the software you use offers and that you select a flavor with sufficient RAM, which Linux can automatically use as a disk cache.

Even if you only rarely require certain data, access to them should still be as fast as possible. By switching our bulk and object storages to "all flash", we have managed to combine unchanged reasonable costs with considerably higher performance thanks to SSDs – even, and in particular, when multiple access is required simultaneously. See for yourself!

Farewell, mechanical limitations – welcome, all flash!
Your cloudscale.ch team

As opposed to with conventional servers, here at cloudscale.ch we use separate Ceph-based storage clusters. What looks like a single local hard disk to a virtual server, is in fact storage capacity that is distributed across numerous disks and servers and that keeps data in a multiply redundant manner. One of the many advantages consists of the fact that, in the event of a hardware defect on a physical compute host, the affected virtual servers can be restarted on a replacement machine within an extremely short period of time. All data are immediately available again without requiring an engineer to move the hard disks in question from one server at the data center to another. At the same time, however, as all disk access in this setup takes place via the network, latency is significantly higher than the level that can be achieved with local disks, despite dedicated connections of up to 100 Gbit/s. This is why you should use the caching features if the software you use (e.g. a database server) offers this option.

Our tip: It may be worth selecting a slightly larger flavor, given that Linux automatically maintains a disk cache using RAM that is not being otherwise used.

Performance: parallelize workloads

Once data start flowing to or from our storage cluster, a further advantage of this setup becomes discernible: as multiple storage servers and an even greater number of disks work together and can be addressed in parallel, the achievable data transfer rate is considerably higher than what would be possible with an individual local SSD. This means that the more your application's data access can be parallelized, the more you can benefit from the usable overall performance of our storage cluster.

Our tip: Parallelize your workloads wherever possible as, compared to purely sequential processing, this will significantly increase storage performance.

Performance: select the flavor based on the use case

In addition to RAM requirements (including a reasonable reserve as a disk cache), processing power requirements play a key role when selecting the appropriate flavor. Beyond the selectable number of vCPUs/cores, the available "Flex" and "Plus" schemes have been optimized for different use cases. With Flex flavors, you share processing power with other customers while adhering to moderate average utilization in accordance with fair-use regulations. In addition to the low cost, you also benefit from adequate reserve capacity, which ensures that you are always prepared for peak demand periods. With the Plus flavors, on the other hand, the number of physical CPU cores you have booked are always exclusively available to you. You can and may use this capacity at all times; with Plus, there are no bottlenecks caused by overbooking of available processing power.

Our tip: Your virtual servers can be scaled at any time, including from Flex to Plus and vice versa. Take advantage of this option, for example to perform initial tests with various flavors or whenever your requirements change.

Costs: appropriate storage for any application

The first 10 GB of NVMe-SSD root volume storage are included with every virtual server. Containing the base image for the launch of the server, this amount of storage is often already sufficient for its live operation. In addition, further volumes can be added to and deleted from the server at any time. Select NVMe-SSD storage here if you require maximum performance, e.g. for operating a database. The economical bulk volumes, which are limited to a maximum of 500 IOPS, on the other hand, are better suited to larger quantities of stored data that are used less intensively. If you are unsure, try out both options. While bulk volumes are definitely not appropriate for database use, they may be perfectly adequate for other scenarios, thus supporting cost-effective server operation.

Our tip: As an alternative to NVMe-SSD and bulk volumes, which you will see as sdX devices in your server, our S3-compatible Object Storage is also available to you. The particularly interesting aspect here is that – in addition to a utilization-based charge for requests and outgoing data transfers – you do not pay for available storage capacity, but only for the capacity you actually use.

Costs: scale volumes as required

You can increase the root volume as well as additional NVMe-SSD and bulk volumes at any time, even during live operation. Provided there is tooling and appropriate partitioning in the server, this works up to the level of the file system. For this reason you should calculate your volumes based on the capacity you actually require; there is no need to plan for future requirements in advance. Please note that reducing volumes is not supported. Therefore, if you only need additional capacity temporarily, we recommend that you create an additional volume, which you can delete again at any time in future.

Our tip: If you do not want to use multiple additional volumes as separate mount points, you can combine them, e.g. using LVM, into a continuous area. This way, you still have the option of removing individual PVs from the volume group and deleting the respective volumes at a later time.

Resilience: copies in various locations

At cloudscale.ch, we assume that, in their own interest, our customers have backups of their data on a third-party infrastructure, with the simplest scenario, for example, being locally on their own work device. If you also have copies with backup character within our cloud infrastructure, we recommend that you always save these in a different cloud location to their source data. Our two geographically separate cloud regions in Rümlang (Canton Zurich / RMA) and Lupfig (Canton Aargau / LPG) mean that your data are also protected in the best possible way in the case of unlikely, but potentially serious events such as a fire or an earthquake. Incidentally, your data will always take the most direct route possible thanks to our dark fiber ring between the two regions.

Our tip: As an alternative, there is S3-compatible Object Storage available to you in both cloud locations. If you use this option, make sure that you actually create the bucket in the other location.

Resilience: use anti-affinity

Scaling "up" in the case of growing resource requirements, i.e. allocating more resources to an existing server, avoids complexity and thus possible sources of errors. It may, however, make sense to scale "out" instead and to use a (redundantly designed) load balancer to spread the load across several servers. You can use our anti-affinity feature to avoid the issue of several of these servers being simultaneously affected by a potential isolated hardware problem. By placing up to four virtual servers in anti-affinity to each other during their creation, you can ensure that these servers actually run on separate physical hosts.

Our tip: Always combine servers that perform similar tasks and can "stand in" for each other in the case of failure.

Resilience: use of Floating IPs

Today, almost everything takes place via domain names, and with a sufficiently low TTL (time to live) for your DNS entries, you can control which IP address and therefore which server your requests are directed to. This, however, still involves a certain delay, and the behavior of various clients is not always totally consistent. With Floating IPs, you can avoid having to change the IP address: simply move your Floating IPs between your servers, within one region or across regions, in order to direct traffic to the desired server within seconds. To achieve a failover setup, you can also automate this process via our API. Here, two servers – e.g. two load balancers – constantly monitor each other so that they can redirect live traffic almost seamlessly to themselves if their counterpart encounters a problem.

Our tip: Even for simple setups, Floating IPs offer you decisive added value given that, unlike a server's IP addresses, Floating IPs are kept when a server is deleted. This means that, from a user's point of view, services can be resumed unchanged even if you completely replace the server in question in the background.

Security: protect backend servers

In setups with multiple servers, e.g. with a separate web and database server, some of the systems often do not need to be directly accessible from the Internet. Rather, it is actually particularly important to prevent direct access in order to provide optimal protection for these backend systems. At cloudscale.ch, you can connect backend systems of this kind to the frontend servers via a separate, private network, which eliminates the need for a direct connection between the backend systems and the Internet. For more complex setups you can also create multiple separate private networks or specify the settings to be distributed in the private network by the DHCP service.

Our tip: OPNsense and pfSense CE, two dedicated firewall distributions available in our cloud control panel, allow you to use a web interface to conveniently manage a firewall server at the interface between public and private networks.

Security: encryption

This first part is not actually a tip in the true sense of the word. At cloudscale.ch, all data that our customers store on our storage clusters (i.e. all data on NVMe-SSD and bulk volumes and in our Object Storages) are automatically encrypted "at rest". This encryption serves as an additional layer of security, e.g. in the event that a defective disk can no longer be completely erased when it is decommissioned. It goes without saying that users with the appropriate skills can go one step further. Our Object Storage supports server-side encryption using SSE-C. You are also free to set up additional encryption, e.g. with LUKS, for volumes or individual partitions within your virtual servers that is solely under your control. However, please be aware that after an (unplanned) reboot, a manual intervention will normally be required. In addition, the installation and debugging of setups of this kind are not covered by our support.

Our tip: Our CSI (container storage interface) driver supports full disk encryption as well. In Kubernetes setups, this can be used to encrypt even persistent volumes for containers with minimal effort using LUKS.

Security: certification and compliance

At cloudscale.ch, in addition to data encryption, you also benefit from the fact that we are certified as per ISO 27001, 27017 and 27018. The data centers we use are also certified according to ISO 27001 and other international standards. Moreover, cloudscale.ch is a hosting partner of the "swiss hosting" label, which means that we offer you the certainty that all data are exclusively stored and processed in Switzerland. In this way we help you meet your own customers' compliance requirements as effectively as possible.

Our tip: If you process data from EU persons in our cloud, we also offer you the option of concluding a DPA in accordance with EU GDPR. You will find this agreement in our cloud control panel and can conclude it there with just two clicks of your mouse.

These tips do not claim to be exhaustive, and depending on your specific use case, other topics may also be particularly significant, such as efficient processes based on the DevOps tools we support. It goes without saying that we are also constantly improving our offer. We will be glad to answer any questions that arise in your day-to-day work directly, and look forward to any feedback that will help us shape our road map further.

Simply sophisticated,
Your cloudscale.ch team

This post was updated on 2021-08-10.

With the recently introduced "organizations", companies and other groups can manage cooperation around their cloud resources. As a superuser, you can invite any cloudscale.ch accounts into your organization and grant them read-only or full access on a project-by-project basis. People who already have an account at cloudscale.ch – e.g. for private use – can continue to use it and will then additionally see the resources of your organization.

It may be that as a company, you prefer your employees to use a separate account associated with their business email address instead. In this case, you can additionally choose to link your own "OpenID Connect"-compatible identity provider ("IDP"), such as Keycloak or ZITADEL, to our cloud control panel. During a signup or login attempt with an address from your email domain, the user is then redirected to your IDP. Once authenticated in accordance with the specifications of your IDP, they are returned to our control panel, where they are also logged in.

Tips on using your IDP at cloudscale.ch

• Two-factor authentication ("2FA") is an important security feature. In our control panel, you can see for each "member" of your organization whether 2FA is enabled for the account in question or not. By logging your members into our control panel via your own IDP, you can also technically enforce 2FA, if required, which will save you from having to perform periodic checks and give you the certainty that this additional layer of security is in place at all times.
• To simplify onboarding, an email pattern can be stored for every organization on request. Newly created accounts matching this pattern will then be automatically added as a member of the organization in question.
• It is easy for you to define directly in your IDP whether a certain person is actually authorized to log into our control panel. This will also enable you to maintain control when employees join or leave your company.
• If you operate your IDP in our cloud, make sure that you can still take the required repair measures in the case of its failure. This is why we recommend that you include a superuser in your organization that does not depend on the same IDP. Another option is an IDP setup with automatic failover.

Our support team is happy to help if you would like to link your IDP or if you have further questions.

Convenience even without your own IDP – login with GitHub

Even if you do not have your own IDP, there is now also a further login option available. If you would like to log into our control panel with GitHub rather than a password, simply click on "Continue with GitHub" when you sign up and during future logins. The primary email address registered at GitHub is associated with your cloudscale.ch account and serves as the contact address for our communication with you. Please note that, in this case, logging into our control panel depends on the availability of GitHub and your account there.

With existing accounts, it is currently not possible to switch between GitHub-based and password-based logins. Our support team is happy to help if you already have an account and would like to move existing projects to a new account with a different login procedure.

Single sign-on solutions mean that users require fewer different passwords and have to enter them less frequently. This also reduces the temptation to select weak passwords that increase risk exposure. By linking our cloud control panel to your existing IDP, you will make work easier for your employees while simultaneously increasing security for your company and customers.

Creating trust,
Your cloudscale.ch team

Projects: enhanced order for everyone

Several tried-and-tested approaches have been used in the past in order to maintain an overview, from a suitable name scheme and tags to the use of widespread DevOps tools. You can go one step further with our new "projects". Your cloud resources are not only optically grouped and protected against mix-ups, but are also technically separated from each other. This stops you from inadvertently linking a test server into the private network of your productive infrastructure and prevents the API token of one cluster causing issues in another. All cloud resources, such as virtual servers, volumes, private networks, Floating IPs, and Objects Users are part of exactly one project.

Projects also mean that you can easily switch between your different "hats". The clusters of your end customers A and B, your personal experimental setup, and the web server you run as a volunteer are all clearly separated from each other, but can still be reached with just two clicks. Where you may so far have worked with several accounts, the new projects are now your method of choice.

Work together – in organizations

There are numerous projects, both in business and private life, that you do not work on alone. The newly introduced "organizations" represent this kind of collaboration. You can set up organizations for your company, your association, or yourself whenever you want to collaborate on your cloud resources with other people. As a "superuser" in an organization, you can manage its projects, invite "members" and grant permissions. As organizations are each based on a separate framework agreement, they are also suitable for constellations where cloud resources need to be treated separately for accounting purposes.

The advantages of an organization are obvious: every organization member has their own login credentials and can enable two-factor authentication for additional protection. The traceability of changes in organization and project logs means that you will also meet your end customers' compliance requirements. For every project of your organization, you can determine on a case-by-case basis which members and/or teams should have read-only or full access.

Simple use, smooth transition

As usability is in the DNA of cloudscale.ch, it goes without saying that we also placed particular emphasis on ease of use in this evolutionary step. In the completely overhauled cloud control panel, which is now based on single-page application architecture, almost everything is in its usual place and existing functionality has remained unchanged. API specifications are also the same, which means that automated processes and tools do not need to be adapted.

Your existing cloud resources are not affected by the switch, and any API tokens will continue to work. If you have so far shared an account with other people and would like to now run this account as an organization, simply let us know and we will be happy to migrate the account for you. We would, of course, also be delighted to receive any other feedback.

With the most significant overhaul of the cloud control panel in our history, we have managed to bridge the gap: at cloudscale.ch, the cloud will remain simple, fast and intuitive in future, too, and in addition, you now have access to the appropriate tools to maintain an overview and control in larger contexts – both on your own and in teams.

Experience the cloud from a new perspective!
Your cloudscale.ch team

What is tested

We developed the Acceptance Test Suite to allow us to see, as completely as possible, our cloud infrastructure from a customer perspective. This means that these end-to-end tests cover almost every aspect of our cloud offer, including confirmation that a single server really can have up to 128 volumes, that servers can be scaled between Flex and Plus flavors, that a Floating IP can be moved between servers, and that jumbo frames can be used in a private network. During this process, the acceptance tests simulate a power user utilizing all the features of our offer. This provides us with the certainty that our infrastructure works perfectly during intense day-to-day use, too.

The acceptance tests use our public API and thus the same technical interface as our CLI and DevOps tools, such as Ansible and Terraform. As this enables acceptance tests to be fully automated, they can be performed regularly: from GitHub we run them against our two cloud locations every day to ensure that we are constantly aware of what our customers see "from the outside". We also use this to test our lab setups every day as well as to perform targeted test runs before and after major updates. As a complement to our manual verification steps in the lab, the acceptance tests provide additional certainty that planned work on productive systems will not have any negative effects for our customers.

Our S3-compatible Object Storage, which is based on Ceph, is the only thing completely excluded from the acceptance tests we developed. Here, we use the corresponding automated tests that are already publicly available for this open source project.

What the acceptance tests mean for our customers

We use redundancy and extensive monitoring in order to minimize negative effects of isolated events, e.g. hardware defects, for our customers. With the acceptance tests, which simulate a wide range of use cases, we have extended this monitoring so that it also covers cases where all the "cogs" work in isolation, but for some reason still do not mesh together correctly. Typical examples here are configuration errors or version updates that bring with them slightly modified system behavior. Our comprehensive acceptance tests mean that we detect many of the edge cases while still in the lab; regular testing of the productive systems then confirms to us that all features are available to our customers as usual over the long term.

Despite all these precautions, problems can still occur in unexpected places, causing previously correct system behavior to suddenly disappear. Expanding our Acceptance Test Suite is one way to prevent regressions of this kind in future. As a project that has grown and continues to grow, the acceptance tests are developing together with our cloud offer. It goes without saying that all customers automatically benefit from this institutionalized learning process.

How to see for yourself

The main aim of our acceptance tests is, of course, for you to be able to rely on the documented features of our infrastructure in your day-to-day work and life. We, however, go an extra step. On GitHub, you can see the tests we run against our productive cloud infrastructures, including the results. Please remember that, as things sometimes go wrong on the Internet, tests may be repeated one additional time before they are assessed as "failed".

For everyone who would like to look at this in more detail, we have published the source code of our acceptance tests on GitHub. This will enable you to reconstruct exactly which tests we perform and how we perform them. If desired, you can also run the tests against our infrastructure yourself. All you need is a Linux or macOS system with Python (version 3.6 and above) and a cloudscale.ch account (for security reasons, we recommend that you use a separate account where you do not use any productive resources).

Our customers depend on their infrastructure working reliably at cloudscale.ch. Regular tests both in our lab and on the productive infrastructure are a fixed component of our quality assurance process. Releasing our acceptance tests on GitHub provides you with a direct insight into this essential tool that we use to measure ourselves against every day.

Performing the acid test,
Your cloudscale.ch team

Keeping Infrastructure-as-a-Service ("IaaS") simple has always been one of our stated aims at cloudscale.ch: an account has an email address and a password, some credit, and as many or as few virtual servers as required at the time. This is not, however, always ideal for a company using our services and some users would also like to group their cloud resources, e.g. according to the purpose of individual servers. In future, our new cloud control panel will address all scenarios optimally:

• The customer "account" will remain the same as with the current approach, but with additional options, e.g. the ability to separate cloud resources into different projects. This will allow, for example, the clean separation of test and production environments.
• The new "organizations" will be subject to a separate framework agreement and will also be able to book cloud resources; however, instead of a password for logging in, these will have one or several "members" who may have different roles and rights within the organization.

If you would like to find out more about the new options, please make sure you have subscribed to our newsletter or keep an eye on the news section on our website.

The new cloud control panel will go live in the second quarter of 2021. To ensure transparent regulation of the new technical options, we are already publishing our updated ToS, which cover these changes. These new ToS will apply with immediate effect to newly created customer accounts. For existing customers, the new ToS come into effect on 2021-04-26 after a transition period of 30 days in accordance with the current regulations. We will not be invoking the provision about changes to ToS being authorized with immediate effect upon booking additional services and this provision will then be deleted without replacement in the new ToS. This means that an automated cloud setup will not affect the lead time available to you.

There is no need for you to do anything. Any existing services will continue unchanged, also after the new ToS come into effect.

The most important changes

With accounts and organizations, the new ToS explicitly cover both options for a customer relationship and thus of a framework agreement. A customer "account", which is required to log into our cloud control panel, is the typical approach for an individual who would like to use cloudscale.ch services. Once logged in, "organizations" can be created to conclude additional framework agreements, registered in the name of one's company, for example.

The "Introduction" and "Use" sections of the new ToS define which agreement and thus whose responsibility individual actions, e.g. creating a new server, come under. In all cases, the account or organization within the scope of which an action is performed is relevant. As a result, the new option of granting authorization is based on the principles known from e.g. work contracts and proxy assignments.

As cooperation is possible, accounts are no longer always completely independent from each other. The "Transmission of customer data" section now states that when authorization is accepted or granted, certain data may be or become visible to other people, e.g. in the logs of an organization you are a member of.

To make it clear that the person reading the ToS is not necessarily being addressed personally, we have changed the wording from "you" to "customer". Please bear in mind that the English translation of the ToS is provided for the convenience of our non-German-speaking customers, and only the German version is legally binding.

In addition to a few minor changes, we have also been able to meet another customer demand. Already in the past, we announced maintenance work in advance wherever possible and now we have included a corresponding section ("Maintenance work") in our ToS. In the interest of our customers, we nonetheless continue to reserve the right to carry out maintenance work at short notice in urgent cases, e.g. security updates.

Most things will stay the same

The basic principle behind our ToS remains unchanged. We want to be a close and approachable partner for you even in the "small print". This starts with the data location, and we will continue to operate our whole infrastructure exclusively in data centers in Switzerland. We provide individual support for technical issues. Our services and their prices will not change with the new ToS. And because we are convinced that our "overall package" speaks for itself, you still do not need to observe any minimum contractual periods or notice periods at cloudscale.ch.

We look forward to introducing our completely updated cloud control panel to you soon and are convinced that, with the updated ToS, we have laid a balanced foundation for the new options. However, should you have any concerns, please contact us directly so we can discuss your questions.

Full flexibility with full transparency,
Your cloudscale.ch team

Container orchestration: what is it all about?

Many of our customers already use containers in one form or another. A currently widespread approach for isolating containers is the use of Linux namespaces in combination with cgroups. This has been a mainstream approach since about 2013 following the breakthrough of Docker and the ensuing Open Container Initiative (OCI) standardization process. In containers, applications can be separated from each other in a particularly resource-efficient manner as this approach does not use hardware virtualization and – as opposed to in the case of full virtualization – the operating system does not run in multiple parallel instances either.

While it is possible to manage several containers on a few nodes manually without any problems, container orchestrators, such as Kubernetes or "K8s", come into play at the latest when issues of scaling up and container lifecycle management arise. Kubernetes ensures, among other things, that the desired number of instances of each container are running and independently determines the appropriate nodes for them. During the deployment of new container versions, it replaces old instances in accordance with defined deployment strategies, e.g. to ensure that a service is continuously available as a whole. And if persistent storage is required for certain containers, Kubernetes can automatically provision it to the right node via CSI.

Kubernetes exists in various "flavors"

At cloudscale.ch, customers have the choice of how to install and run Kubernetes. If you would like to work directly with the "upstream" Kubernetes, you can deploy your K8s cluster with e.g. Kubespray: this tool is based on Ansible and can be used together with our Ansible collection. This way, it is straightforward for you to set up the cloud infrastructure required for the cluster via our API.

Rancher goes one step further as a higher-level administration tool. Rancher is run on a container basis itself and provides a graphic web frontend and APIs that make it possible to set up and manage complete Kubernetes clusters in just a few steps. Rancher automatically prepares the cloud resources required for a cluster; the cloudscale.ch node driver is already pre-installed in current Rancher releases.

OKD is another powerful tool that we will look at in more detail here. This open source project is also the basis for OpenShift that is sold by Red Hat as a complete software, services and support package. Along the lines of the Linux kernel and the Linux distributions built around it, OKD can be seen as a Kubernetes distribution. In addition to pure container management, OKD also integrates several tools that, for example, monitor the cluster, perform logging functions and route network traffic to the correct containers. The installation of OKD at cloudscale.ch benefits from various features that we have already reported on, e.g. private networks with managed DHCP. For what are known as master and worker nodes, OKD uses Fedora CoreOS, which stems from the previous Core OS and is one of the available options when installing new servers at cloudscale.ch (just like Flatcar Container Linux, by the way, which is a popular Core OS fork).

Create your own OKD cluster step by step

If you are interested in OKD, we have published detailed instructions on GitHub about how to create your own OKD cluster. Relying on Ansible, this tutorial uses a popular DevOps tool to automate the individual steps. In addition, our "how to" guide uses "ocp4-helpernode", which was developed in the OpenShift setting, to make the procedure even more straightforward, in particular for provisioning HAProxy and DNS. The process essentially consists of the following four steps:

Step 1: The required tools are installed on your personal device, e.g. your own laptop or an alternative cloud server, and certain basic variables are defined.

Step 2: The helper node is installed and the services that perform a range of key functions in the cluster are configured on it. API connections, for example, will run via the HAProxy, which also makes it possible to reach your applications on the worker nodes from the Internet at a later stage. The DNS server, in turn, enables resolution of cluster-internal domains and IP addresses, while an Apache HTTP server is used for serving static files. Ignition configs, in particular, are stored on the Apache: in a similar way to "cloud-init", Ignition allows individual settings to be applied on newly created servers on the very first start-up.

Step 3: This is where the master and worker nodes are created. Like with the helper node, starting these virtual servers at cloudscale.ch is automated using our Ansible collection. The new nodes fetch their prepared Ignition configs and thus their specific configuration settings from the Apache server from the previous step, which means they can complete their set-up independently.

Step 4: In a final step where the new nodes are accepted into the cluster, the relevant CSRs need to be signed. This completes the installation of the OKD cluster.

The popularity of container setups continues unabated, not least because of the numerous advantages, such as the clean separation of individual services with simultaneous efficient use of resources. There are a wide range of possible solutions in container management, depending on the specific requirements and preferences. Whether OKD, Rancher or a particularly streamlined approach, at cloudscale.ch you will find the components you need to make it work.

For your favorite tools,
Your cloudscale.ch team

The most frequently mentioned advantage of "infrastructure as a service" (IaaS) is that if IT resources are not purchased as hardware but sourced as a cloud service, there is no initial investment. Instead, expenses are relatively evenly distributed over the whole period of use and unlike a physical system with its fixed dimensions, cloud resources – and therefore costs – can easily be adapted to new requirements even at a later date.

Depending on the constellation, real savings are possible in addition to these evenly distributed costs. For most workloads, utilization rates vary significantly in the course of a day, a week or a year. If, for example, a new system is sized for peak demand periods at the end of each quarter, the expensive capacity bought for one's own hardware will lie dormant for the rest of the year. By contrast, additional cloud infrastructure can be booked as required and only entails costs for as long as it is actually needed.

No hardware management – reduced overheads

However, in addition to purely financial considerations, the cloud primarily excels in practical terms. Handling hardware over its entire life cycle is associated with recurring effort: from evaluation to start-up and replacing defective components, all the way to upgrading to the next system. On top of this, you also need to run a designated server room or drive to an external server housing location and ensure a network connection at the site in question.

A cloud infrastructure on the other hand offers the proverbial all-round carefree package. Professional, carefully selected and certified data centers provide physical data security. Thanks to rolling life cycle management that takes place in the background, customers have access to up-to-date hardware at all times, while its monitoring and maintenance is guaranteed by specialists at the cloud provider. Redundancy and capacity reserves minimize the impact of hardware problems on customer workloads. In contrast to what is frequently the case for one's own servers, cloud systems are also networked via multiple alternative paths in the Internet. This not only guarantees access to your own service in the case of a malfunctioning connection, but often also reduces latency to your own visitors or customers, which helps improve customer satisfaction.

Safer and more agile by the day

Once the first step has been taken in the cloud, numerous other optimization options become possible. As new servers do not need to be purchased in a complex and expensive process, but are available at the push of a button, upgrades and migrations, for example, are possible with almost no downtime: a new system is installed in the background and productive traffic at time X is simply redirected. When several servers are run in parallel, load balancing and failover set-ups are possible, which further increases reliability. Thanks to "anti-affinity" it can also be guaranteed that these servers are actually deployed on separate physical machines at the cloud provider's end. Particularly high standards can be met through geo-redundant set-ups with physically separate server or cloud locations.

Day-to-day flexibility is just as important as the stable operation of productive systems. By creating and deleting new servers as required, engineers can quickly test new tools without risk, reproduce a problem or do a "dry run" of a tricky procedure. When selling technical solutions and during training, it is useful if customers can play around safely on a standalone demonstration system. Thanks to the integration of cloud APIs into current DevOps tools (such as Ansible and Terraform), the provision and cleaning of short-lived instances of this kind can be largely automated.

Five years ago, the cloudscale.ch IaaS offer went live and has enjoyed continuous growth ever since. Our users regularly confirm to us the advantages of a cloud solution compared to a traditional set-up – not only in terms of contributing to a better overall product for their end customers, but also in terms of making their own work processes easier. Given the many reasons in favor of a cloud infrastructure, it is also clear that its full potential has by no means been exploited and that, in future, other and possibly less obvious use cases could benefit from the flexibility of a cloud infrastructure.

Keeping all your options open,
Your cloudscale.ch team

PS: Although we list server prices per 24 hours here at cloudscale.ch, you benefit from to-the-second billing and any unused time is credited to your account as soon as you delete a server. This means that you always have the appropriate resources available even for extremely short applications.

In addition to Terraform, Ansible is one of the most popular IT orchestration tools. At cloudscale.ch, we use Ansible internally to, for example, manage our network components and almost the whole cloud infrastructure. It goes without saying that we also endeavor to make the configuration and operation of cloud resources as simple as possible for our customers, too.

With Ansible 2.10, development and maintenance of community plug-ins were outsourced to what are known as "collections". Many plug-ins found a new home in the "community.general" collection, while for others, such as the cloudscale.ch integration, development was split into separate source code repositories and organizations to allow faster development and individual release cycles. Today, there are already about 75 self-organized collections for Ansible 2.10.

Our own "cloudscale_ch.cloud" Ansible collection provides us with several advantages at once: on the one hand, we are able to replicate extensions to our API in our plug-ins within a short period of time, and on the other hand, it is easier to test our plug-ins in an automated manner independently of the rest of the Ansible project.

The suitable version for any requirement

With releases every three weeks, Ansible 2.10 also contains the latest releases of the collections, which means that the most recent version of "cloudscale_ch.cloud" is always automatically supplied and installed with the official Ansible package. If you would like to use a specific feature scope outside this release cycle, you can take matters into your own hands with ansible-galaxy and use the preferred version of our collection with your existing Ansible version.

For reasons of traceability, we recommend that you create a requirements.yml file to maintain an overview of all external collections and roles:

collections:
  - name: cloudscale_ch.cloud
    version: 1.3.0

The collection can then be installed as usual via ansible-galaxy:

ansible-galaxy collection install -r requirements.yml

Please note that existing playbooks will continue to work without adjustments. It is only essential to use the "fully qualified collection name" (FQCN) for plug-ins that have been newly added since Ansible 2.10. At the same time, there is no reason not to make a general switch to FQCN in existing playbooks, too.

Without FQCN as before:

- cloudscale_server:
    name: web1.example.com
    ...

Or with FQCN:

- cloudscale_ch.cloud.server:
    name: web1.example.com
    ...

Example 1: Network management with subnets

The network API was integrated into version 1.2.0 of our collection. Subnets can now also be managed with the most recent version 1.3.0, which allows the creation of new subnets as well as the adjustment of the gateway IP and DNS servers for existing subnets:

- name: Ensure network exists
  cloudscale_ch.cloud.network:
    name: Private in LPG1
    zone: lpg1
    auto_create_ipv4_subnet: false

- name: Ensure subnet exists
  cloudscale_ch.cloud.subnet:
    cidr: 10.11.0.0/16
    gateway_address: 10.11.0.1
    dns_servers:
      - 10.11.0.2
      - 10.11.0.3
    network:
      name: Private in LPG1
      zone: lpg1

Example 2: Objects Users

The module for Objects Users management was already added with version 1.1.0 of our collection (and therefore also in Ansible 2.10.0), thus enabling, for example, the automated creation of a backup configuration using our Object Storage:

- name: Create a backup user
  cloudscale_ch.cloud.objects_user:
    display_name: backup for ACME
    tags:
      customer: ACME Inc.
  register: res_object_user

- name: Configure S3cfg
  template:
    src: s3cfg.j2
    dest: ~/.s3cfg

In the s3cfg.j2 template, we use the keys returned by the module:

# {{ ansible_managed }}
[default]
access_key = {{ res_object_user.keys.access_key }}
secret_key = {{ res_object_user.keys.secret_key }}
check_ssl_certificate = True
guess_mime_type = True
host_base = objects.lpg.cloudscale.ch
host_bucket = objects.lpg.cloudscale.ch
use_https = True

Example 3: Floating IPs

Existing modules have also undergone improvements, which mean that it is now possible to create Floating IPs idempotently. This was implemented by means of an additional name parameter. To ensure backwards compatibility, this parameter is currently still optional. It will only become mandatory to specify this parameter from the next major version of our collection onwards.

- name: Start cloudscale.ch server
  cloudscale_ch.cloud.server:
    name: mx1.example.com
    image: debian-10
    flavor: flex-2
    ssh_keys: ssh-rsa XXXXXXXXXX...XXXX ansible@cloudscale-ch
    zone: lpg1
  register: server

- name: Request Floating IPs for my server
  cloudscale_ch.cloud.floating_ip:
    name: mx1.example.com
    ip_version: "{{ item }}"
    reverse_ptr: mx1.example.com
    server: "{{ server.uuid }}"
  with_items:
    - 4
    - 6

Ansible and our "cloudscale_ch.cloud" collection provide you with a powerful, yet simple tool to create and operate a larger-scale cloud infrastructure quickly and transparently. And for everyone who (like us) is committed to open source: the source code of our collection is available on GitHub under GPLv3.

Proud to be part of the Ansible universe,
Your cloudscale.ch team

Thanks to a wide range of ready-made images from popular Linux distributions and security appliances, your servers at cloudscale.ch are ready for use in no time. In addition, further operating systems can be installed manually via ISO/USB images. Now, you can combine the best of both worlds: using your own individual images makes it quick and easy for you to create new servers with complete flexibility in terms of pre-installed software and configurations.

Your own images will enable you to handle numerous use cases even more elegantly. You can now integrate tools that you would install on your servers anyway directly into your own image, e.g. packages for monitoring and configuration management, as well as utilities that make your everyday work easier. If you need your server for a specific purpose that already has a specialized distribution or appliance, you can simply import this as a custom image and you are good to go.

Image management via API

You can import your own images into your cloudscale.ch account with a simple API call. Shortly afterwards you will be able to create new servers on this base, referencing your own image e.g. with its specific UUID, which will remain valid for as long as the image exists in your account. Alternatively, you can enter the "slug" that you determined when you added the image, along with the prefix custom:. This is particularly useful if, in future, you want to include more recent versions as seamlessly as possible: if there are several image versions with e.g. the slug "voip-pbx", the most recent image will automatically be used when starting a new server using custom:voip-pbx.

To import an image into your account, simply indicate the HTTP(S) address where the image is available in the API call. Our system will then load this image directly from this URL and make it available to you in the desired cloud locations. If you are creating/editing your image locally and do not have a web server available, you can use our Object Storage. Once you have uploaded the image (e.g. with s3cmd --acl-public put ...) into a bucket of your choice, all you have to indicate in the API call is the resulting URL: https://BUCKET.objects.LOCATION.cloudscale.ch/IMAGE.

Preparation tips

In the simplest case, your desired distribution makes an image file available that you can import one-to-one into cloudscale.ch. If multiple image files are available, a name containing "OpenStack" or "cloud" usually indicates the right version. Please be aware that the image file needs to be in "raw" format; if required, you can convert the image using e.g. qemu-img (often in the qemu-utils or qemu-img-2 package):

qemu-img convert -f qcow2 -O raw my-image.qcow2 my-image.raw

You will, however, gain the greatest benefit by adapting your image specifically to your requirements and pre-installing frequently used tools. One way of doing this is by means of a virtual server, e.g. based on QEMU/KVM, that you install locally and where you put together your sample installation. The file that serves as a virtual hard drive can then be imported as a custom image (after converting it to "raw", if necessary) for your future cloud servers. If you maintain numerous images or update them frequently, this process can be automated with specialized tools such as "Packer".

When creating your images, please ensure that they will also boot up in a slightly changed environment, as every cloud server you create based on your image will be assigned e.g. its own IP and MAC address. If it is not already included in your setup, we recommend cloud-init for this purpose. This useful package is the de facto standard in the cloud setting and can configure numerous parameters automatically when a server first boots up. It also evaluates the "user data" you can specify when starting a server, which allows further automated setting up of your servers during the initial boot process.

For each cloud location, you can store those images that are already perfectly prepared for your future servers – you will only be charged for the space actually required on our SSD storage. Any one-time adjustments you make to your images are an investment that you will benefit from again with every additional server.

Preparation is everything!
Your cloudscale.ch team

Every server at cloudscale.ch has a root volume on NVMe SSDs that contains the selected operating system after the initial start-up. The size of this volume can be determined for almost all images when creating the server to ensure that your data fit into this volume. If your project and the associated space requirements grow at a later point, scaling up the root volume is simple and can be performed on a running system.

In addition, it may make sense to save some of the data on separate volumes. Bulk volumes are a good choice when inexpensive storage space is required and performance is a lesser priority, e.g. for archive data. For a database that needs to remain separate from the rest of the system, on the other hand, an additional SSD volume would be the first-choice solution. Additional volumes can either be created when setting up a server or added to the server at a later date and scaled up as required. It is also possible to move additional volumes to another server or to delete them at any time.

Persistent volumes in container setups

Additional volumes are of particular significance in modern container setups. Containers or pods are volatile by nature, and as soon as they are replaced by a new instance or a new version, the data disappear. If, however, the data need to be maintained, the pod can be allocated a persistent volume, which means an additional volume for permanent data storage. Thanks to the "container storage interface" (CSI), persistent volumes of this kind can be created automatically by a container orchestration system such as Kubernetes and directly attached to the correct node so that the pod running there has access to it.

cloudscale.ch now supports up to 128 volumes per virtual server, thus also offering adequate scope for tightly packed container setups. You can scale up your cluster and migrate workloads between nodes, while the defined "persistent volume claims" (PVCs) are automatically fulfilled via CSI so that storage is available in the correct location. If you have already been using our CSI driver, make sure that you update to the most recent version.

Technical background

Support for up to 128 volumes per virtual server was made possible by changing the background technology. Newly created virtual servers use virtio-scsi for the volumes instead of virtio-blk. This means that the number of volumes is no longer limited by the number of supported PCI devices. We have also patched a bug in OpenStack, on which our cloud is based. This bug meant that – in addition to limited PCI devices – volumes from vda up to at most vdz, i.e. a maximum of 26, could be used.

The only change for you as a user is the change to the name of the volumes: instead of vda, vdb, etc. you will now find the volume sda and possibly further sdX in your virtual server. This also eliminates one of the main differences that needed to be considered when switching from a physical computer to a Linux cloud server. If a large number of volumes are actually being used, numbering after sdz continues with sdaa to sddx, which covers the current maximum of 128 volumes. You may need to check in your tools or scripts that the new names are being used for operations on volumes and partitions.

Example showing two volumes in an Ubuntu server:

ubuntu@my-server:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
[...]
sda       8:0    0   50G  0 disk
├─sda1    8:1    0 49.9G  0 part /
├─sda14   8:14   0    4M  0 part
└─sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0  100G  0 disk
└─sdb1    8:17   0  100G  0 part
sr0      11:0    1  478K  0 rom

With up to 128 volumes per virtual server, you are now also equipped for larger container setups. Using Kubernetes and CSI is not a requirement, though. It goes without saying that the additional flexibility can also be applied to other use cases, from sophisticated LVM configurations to the clean separation of different data sets.

Claim your volumes!
Your cloudscale.ch team

Data location and applicable law

The term "cloud" originates from network diagrams where the cloud symbol is used to represent networks whose details are of no further relevance, e.g. the Internet. However, given that growing quantities of progressively significant data are being processed in this cloud, these details are increasingly coming under the spotlight. Laws and compliance specifications contain growing numbers of provisions relating to cloud utilization. And, last but not least, media reports and daily tracking and influencing attempts are raising awareness of where personal data end up and may be analyzed.

In this process, the geographical location of data processing takes on great significance as it largely determines which legal regulations apply in addition to those applicable to the location of the data owner. This means that, for Swiss companies, it is simplest if their data are also located in Switzerland. It is, however, equally important to be aware of who the data are entrusted to, since service providers abroad are additionally subject to the law in their own countries. During an interview, lawyer Simon Schlauri cites the USA's CLOUD Act as an example: if required to do so by the authorities, American cloud providers must under certain circumstances hand over data stored in a foreign territory.

"swiss hosting" offers guidance

The new "swiss hosting" label provides greater clarity in this area. Bearers of this label are SaaS and cloud providers who are subject to Swiss law and who guarantee that no foreign organizations can access their customers' data. If the actual hosting of these data is outsourced, the provider of the hosting services must adhere to the same rules. For companies who need to handle their own customer data carefully, "swiss hosting" offers invaluable guidance on selecting an SaaS or cloud provider and helps to minimize compliance evaluation efforts.

[…] that data remains entirely in Switzerland and cannot be accessed or claimed by a foreign organization or government, no matter whether directly or indirectly. This also applies to foreign companies within the Group.

Extract from the "swiss hosting" contract pertaining to access protection

As a launch partner, cloudscale.ch has been involved in "swiss hosting" from the outset. As a purely Swiss cloud provider that only uses data centers located in Switzerland, this label applies to all our services. Our clear positioning also makes us the ideal hosting partner for SaaS and managed service providers who want to use the "swiss hosting" label to provide their own customers with the certainty that data are hosted in Switzerland.

"Swissness" as the key idea

As "Swissness" means so much more to us than simply the selection of data centers, cloudscale.ch has consistently relied on Switzerland as a location from the outset. Our customers appreciate the fact, for example, that with us they have a local partner who speaks their language and takes their concerns seriously. In addition, there are tangible technical advantages given that cloudscale.ch is not only outstandingly networked at an international level but also with Swiss network operators, which ensures low latency to and from local Internet users.

For us, "Swiss quality" also means taking one's time and paying attention to details. We developed our cloud control panel with a great deal of love in order to ensure that using our cloud is as straightforward as possible. And last but not least, cooperation with our partners is also important to us here in Switzerland. Using our infrastructure, our partners are able to implement sophisticated setups with a "Swiss finish" based on customer specifications.

While the international legal situation is difficult to understand and continues to give rise to numerous unanswered questions, "swiss hosting" provides a pragmatic solution. By keeping data in Switzerland, you make life easier for yourself and for your customers. Beyond issues of pure compliance, "Swissness" here at cloudscale.ch also makes us a local and approachable partner for our customers.

Committed to close partnerships,
Your cloudscale.ch team

The cloudscale.ch CLI application is written in Python and can be installed in a flash with pip install cloudscale-cli. Following installation, you will find the new command cloudscale that allows you to view, modify, create and remove cloud resources.

The CLI application is also suitable for use in scripts, in particular with the --output json option. You will now be able to elegantly deal with all the usage scenarios that you have wanted to automate for a while now, but where a powerful tool such as Rancher or Terraform was not really suitable.

A list of all the parameters and the supported cloud resources can be found by executing cloudscale --help. Installation and configuration information and instructions are also available online in the project documentation on GitHub.

Sample applications

The following examples show how simple and intuitive it is to manage your cloud resources with our CLI application. You can list your existing servers as follows, for example, and use the optional --filter-tag to additionally limit this to servers you have allocated a certain tag to.

$ cloudscale server list --filter-tag project=gemini --delete
NAME    STATUS    ZONE    TAGS            UUID
------  --------  ------  --------------  ------------------------------------
web4    running   lpg1    project=gemini  5d461dfa-a92a-4c7b-9199-c02ed7b6b570
web3    running   lpg1    project=gemini  54071101-8586-4af7-a5d1-25649fd6b2b2
Do you want to delete? [y/N]

An individual server and several identical servers can be created with the cloudscale create command; you can use the --count option to indicate the number of servers required.

$ cloudscale server create --flavor flex-2 --image debian-10 --ssh-key "$(cat ~/.ssh/id_ed25519.pub)" --tag project=gemini --count 3 --name 'web{counter}' --wait

Please note that {counter} has been added to the name. This makes it possible to give all three servers different names: web1, web2 and web3.

The --wait option means that the command only completes after all the servers that are being created have achieved the final status=running stage.

If you add --action or --delete to the list function, you can stop, start, restart or delete several servers in a single process.

$ cloudscale server list --filter-tag project=gemini --delete
NAME    STATUS    ZONE    TAGS            UUID
------  --------  ------  --------------  ------------------------------------
web4    running   lpg1    project=gemini  5d461dfa-a92a-4c7b-9199-c02ed7b6b570
web3    running   lpg1    project=gemini  54071101-8586-4af7-a5d1-25649fd6b2b2
Do you want to delete? [y/N]

The --verbose option adds additional information to the display.

Good to know

Our CLI application also has a convenient feature that allows a direct SSH connection to be established to your servers: cloudscale server ssh web1. This saves you the additional steps of first having the IP address listed and then laboriously compiling your SSH command by copying and pasting to the console.

Do you have any suggestions or modification requests? The code of our CLI application is open source and covered by the MIT license. We look forward to your feedback.

Usability has been one of our top priorities at cloudscale.ch from the very beginning. While the aim was always for our cloud control panel to be as simple and intuitive to use as possible, the API and integration into various DevOps tools provided maximum efficiency. With the new CLI application, creating individual servers is as streamlined as managing them afterwards, namely on the command line.

Focusing on the essential,
Your cloudscale.ch team

TLS versions 1.0 and 1.1 will be disabled on all cloudscale.ch systems that are accessible from the Internet. This includes the following systems, in particular, that you or your end customers may use:

• Cloud control panel and API for management of your cloud resources
• S3-compatible Object Storage

The changeover will take place in two stages: on 2020-08-11, we will disable these TLS versions on our Object Storage at our "LPG" site. In the following week, on 2020-08-18, the same changeover will take place on the Object Storage at the "RMA" location, and for our cloud control panel and API. The changeovers will take place without interruption to our services.

No disruption expected

TLS (Transport Layer Security) was specified as the successor to SSL encryption in 1999 and is still occasionally called "SSL" in everyday use today. Although certain improvements were introduced with TLS version 1.1 in 2006, there were still fundamental limitations that can only be described as outdated from today's security perspective.

TLS 1.2 was released as early as 2008 and is today supported by all modern applications, i.e. by server software as well as by the associated clients, such as web browsers. For this reason, we do not foresee any problems for our customers. During and after the changeover, access to our systems will continue to operate as expected with TLS 1.2 or the even more recent TLS 1.3.

If in doubt, we recommend that – despite the fact that TLS 1.2 is widely supported – you check the tools you use, in particular in the case of older or less common clients that require access to our API in the event of e.g. a failover scenario.

Old TLS versions barely relevant today

According to an evaluation on our own systems, TLS 1.0 and 1.1 are barely used for access today and, if access occurs at all, it is in the per mille range. These figures are not surprising given the consistent support for TLS 1.2 and in part already 1.3 in all modern client applications. The most common Internet browsers are even dropping support for the old TLS versions this year.

Disabling outdated security protocols that are no longer relevant to practice, is an unremarkable and logical step for us in the interest of general IT security. Should you nonetheless encounter unexpected problems in this context, our support team is here to help.

Kind regards,
Your cloudscale.ch team

Cumulus Linux, the network operating system based on Debian, makes it easy for experienced network engineers to get started. The important settings are accessible through a CLI, and this interface has been aligned with CLIs from major manufacturers, which enables network specialists to find their way around the new environment quickly and to build on knowledge they have acquired elsewhere. Even useful features that are only gradually being adopted in the industry are available by default on network devices running Cumulus Linux; it is, for example, possible to apply – and undo – a block of commands in one go.

However, the fact that Cumulus Linux is based on Debian opens up additional, powerful possibilities. Logging in does not take you into the familiar but limited CLI, but directly into a regular Linux shell. The CLI is just one command away, but above all, thanks to full root access, you can also use all the other tools that prove indispensable in a system engineer's everyday life: from utilities such as htop and watch to config management (e.g. Ansible) and monitoring via Zabbix agent.

Efficiency through config management

The ability to administer network devices using a config management system is a key feature that many Cumulus users will not want to do without. Having relied on Ansible for the management of the cloudscale.ch servers for quite some time, Cumulus Linux now allows us to manage network devices through Ansible as well. In its simplest form, Ansible acts as a client of the CLI named "NCLU" (Network Command Line Utility): using familiar commands, numerous switches and routers can be consistently configured without manual interaction.

Tapping the full potential, however, requires the use of Jinja templates. Instead of long sequences of individual commands, in which the critical variations are easily overlooked, templates are maintained in relatively short and clear files. Thanks to the use of loops and conditionals, extensive and complex configurations can be represented in a better structured way. This greatly reduces the risk of making careless mistakes such as inconsistent MTU or VLAN configurations.

The following excerpts illustrate how we populate /etc/network/interfaces on our switches using the Ansible template module.

Ansible Inventory Variables:

vrfs:
  mgmt:
    description: VRF Mgmt
    ipv4_address: 127.0.0.1/8
  quarantine:
    description: VRF Quarantine (for test purposes)
    ipv4_address: '{{ "10.0.0.0/24" | ipaddr(device_id) | ipaddr("address") }}/32'
  private:
    description: VRF Private (networks without a default gateway)
  public:
    description: VRF Public (networks with a default gateway)
    ipv4_address: '{{ "203.0.113.0/24" | ipaddr(device_id) | ipaddr("address") }}/32'
    ipv6_address: '{{ "2001:db8:bb::/64" | ipaddr(device_id) | ipaddr("address") }}/128'
  dci:
    description: VRF DCI (networks on data center interconnect)
    ipv4_address: '{{ "172.16.16.0/24" | ipaddr(device_id) | ipaddr("address") }}/32'

Jinja2 Template:

{% for name, vrf in vrfs.items() if name != "default" -%}
# {{ vrf.description }}
auto {{ name }}
iface {{ name }}
    {% if vrf.ipv6_address is defined -%}
    address {{ vrf.ipv6_address }}
    {% endif -%}
    {% if vrf.ipv4_address is defined -%}
    address {{ vrf.ipv4_address }}
    {% endif -%}
    vrf-table auto

{% endfor -%}

Fully automated provisioning

That said, ongoing maintenance of the configuration is only half the battle. We have decided to carry out all major upgrades of our switches in the form of a complete reinstall. This ensures a reproducible state, and we can test the upgrade process and other changes as often as we like in the lab beforehand. Cumulus Networks has developed "ONIE" (Open Network Install Environment) for this purpose. In a similar manner to the PXE environment known from servers, this open system allows booting and subsequent installation of the operating system via the network. Thanks to "ZTP" (Zero-Touch Provisioning), any desired settings can be defined in advance, so that the provisioning of the newly installed system can then be finalized by Ansible without the need for a manual intermediate step.

The following excerpt from our ZTP configuration automates the steps that are typically needed after reinstallation of a switch.

Excerpt from our ztp.sh:

[...]

# In order to start switchd, you need to install a valid license
echo 'user@example.com|3DSpMBACDihILepwdy4/5Ecd34jlAg4h+FiE/9zZawtujnk3Fw' > /home/cumulus/license.txt
/usr/cumulus/bin/cl-license -i /home/cumulus/license.txt
systemctl restart switchd.service

# Move the eth0 (management) interface to a separate management VRF
/usr/bin/net add vrf mgmt && /usr/bin/net commit

# Drop SSH keys in order to log in without using a password
{% for key in ssh_keys %}
echo "{{ key }}" >> /home/cumulus/.ssh/authorized_keys
{% endfor %}

# The following line is required somewhere in the script file for execution to occur
# CUMULUS-AUTOPROVISIONING

[...]

For us, reinstalling a switch with Cumulus Linux takes less than 10 minutes. This allows us to run through configuration changes, new versions, or upgrade paths as often as needed. Once we are ready to upgrade the production devices, we simply apply the same process that has been tested many times, virtually eliminating the risk of typos and inconsistencies. Incidentally, ONIE needs to be supported by the hardware in question, which is not produced by Cumulus Networks itself. The fact that virtually all major network manufacturers have integrated ONIE in a very short time demonstrates just how much this elegant solution was missing before.

Having its roots in Debian and open source, Cumulus Linux fits in well with our philosophy. At the same time, the "open source DNA" also applies in the opposite direction. Cumulus Networks has, for example, contributed the implementation of VRF (Virtual Routing and Forwarding) to the Linux kernel. This has moved the "server" and "networking" fields even closer together.

Open and efficient,
Your cloudscale.ch team

Every server should be kept up-to-date – this also applies to our DNS systems. A further aim is to make our name server setup at the Rümlang location more robust and align it with the new Lupfig location, where we were able to implement these optimization measures right from the start. To this end, we are setting up the relevant servers at the "RMA" location from scratch, taking a step-by-step approach to avoid any interruption in service for our customers.

For your servers in the "RMA" region, the following set of IPv4 and IPv6 addresses will be available as DNS resolvers with immediate effect:

• IPv4: 5.102.144.101 and 5.102.144.102
• IPv6: 2a06:c01:f::101 and 2a06:c01:f::102

These DNS resolvers are already available and can be fully used. This DNS configuration is also already assigned via DHCP to servers that request or renew an IP address from our DHCP servers (except for private networks where you have explicitly configured a different set of DNS resolvers via our API).

Please note: the IP address 5.102.148.102 will be taken out of service as a DNS resolver as of 2020-08-15. Please ensure that your servers no longer use this IP for name resolution.

The above-mentioned change-over to the new set of DNS resolvers applies only to servers in the "RMA" (Rümlang) region. Servers in the "LPG" (Lupfig) region use a different set of DNS resolvers, which is not affected by this change.

What you need to check with regard to your servers

By default, new servers at cloudscale.ch use DHCP for their individual network configuration. Servers where you have left this setting unchanged do not, therefore, need any manual configuration changes. However, we recommend to verify that your servers have actually included at least two of these IPs in their DNS configuration.

If you have manually configured the DNS settings of your servers, please change them to the set of DNS resolvers mentioned above. Make sure that the IP 5.102.148.102 is no longer used as a resolver, as we will take this IP out of service by 2020-08-15. It goes without saying that you are also free to use your own DNS resolvers or a third-party DNS service instead of our systems.

No modifications are necessary for servers running a recursing resolver themselves (e.g. firewall systems based on OPNSense).

Further information

In certain firewall configurations, the applicable firewall rules also need to be adapted, e.g. if DNS replies are not automatically accepted after a DNS query has been sent ("stateless" firewalls).

Since the IP address 5.102.144.102 will continue to be available as a DNS resolver, we do not expect name resolution to be interrupted in a standard scenario even without the necessary adjustments. Please note, however, that in a case of this kind, DNS lookups will be delayed if an incorrect DNS server is queried first, and another server is only attempted after some timeout. Examples of delayed processes include SSH (typical symptom: longer login times) and other services if they resolve IP addresses to hostnames for security or logging purposes.

As mentioned, our redundant DNS resolvers are available with immediate effect via the new set of IP addresses. For optimal operation of the name resolution, please change the DNS setting of your servers in the "RMA" region as described above by 2020-08-15, or verify that this change has been applied automatically. Servers in the "LPG" region are not affected by this change and do not require any action. If necessary, our support team will of course be happy to answer your questions.

Kind regards,
Your cloudscale.ch team

Ready to use immediately thanks to cloud-init

In order to be able to start a new cloud server within seconds, the major Linux distributions provide images that essentially contain a snapshot of a hard disk with the fully installed operating system. A new server, which is created as a clone from such an image, is thus almost ready to use. Some details, however, such as the hostname or the authorized SSH keys, are not present in this generic image and still need to be set individually.

The cloud-init package included in many images is activated at system startup and manages these settings in a fully automated way. When detecting that the specific server is starting for the first time, the full-blown process is run; in addition to the name of the server and access credentials, cloud-init also takes care of creating new SSH host keys, among other things. At cloudscale.ch, the public part of these keys is also output to the serial console, which means that we can display the fingerprints in the cloud control panel, allowing you to verify that the connection is trusted right from your first login. On subsequent system boots, cloud-init can, for example, resize the file system for you if you have scaled up your server's virtual volume in the meantime.

Hub for the config: the metadata server

Details such as hostname and SSH key, which you enter when launching a server, are stored on our metadata server. From here cloud-init can retrieve this data to properly configure your server. One way to get to the data is via what is known as the "Magic IP": the server is assigned a special route via DHCP, and cloud-init can then retrieve its config from the URL http://169.254.169.254. We now also make this config available via "Config Drive", with each new server being assigned a virtual CD-ROM drive (e.g. /dev/sr0) that contains its individual configuration.

To get the maximum benefit from cloud-init, you can use this tool for your own setup tasks as well. When launching a server, you can add "User Data" to specify a broad range of settings including any desired commands that will be executed on the new server without further interaction (see also the cloud-init documentation). In this way, your server installs the packages and patches of your choice and integrates itself into your config management or monitoring, before you even log in for the first time.

It goes without saying that you can also read and use the data from the metadata server with your own tools, e.g. get the UUID of your server in order to perform automated actions via our API. If you configure the network options statically, the data pertaining to your server is now still available locally thanks to the new Config Drive. Alternatively, you can also find the information in /run/cloud-init/instance-data.json, where cloud-init stores a copy of the config it has read.

Good to know

As the version and capabilities of the cloud-init package may differ considerably between various Linux distributions, be sure to check for each specific case which of the many features are supported or can be activated with optional modules. When adding User Data, also bear in mind that the metadata can potentially be read by any user or tool on your server.

Incidentally, although widely used, cloud-init is not the only project to automate the setup of new servers; one alternative is Ignition, which is used e.g. in Flatcar Container Linux. Ignition expects its config to be in JSON format, but when launching a server with Flatcar at cloudscale.ch, you can also choose to specify the User Data in the form of a YAML-formatted "cloud-config" as you would for cloud-init.

Irrespective of whether you keep a copy/paste template for use in the control panel or start servers through the API, with cloud-init and Ignition, in addition to creating servers, many setup steps that you used to perform manually can be automated. And even during normal operation, you – or your scripts – can access the relevant metadata of your servers at any time.

For a great start,
Your cloudscale.ch team

The switching infrastructure as a key element

In everyday IT life, the network often receives little attention: once the systems are wired, the focus tends to shift to computing power and storage space for years to come. At cloudscale.ch, on the other hand, the topic is constantly present. Not only does the connection of our cloud servers to the Internet and thus the external availability of your services depend on the network, but with the trend towards microservices and cluster setups, internal networking between cloud servers is also vital for the performance and reliability of the overall system. And finally, our Ceph-based storage cluster can only fully leverage its advantages with a top network infrastructure.

In addition to our general growth and the increasing demand for switch ports, the opening of our second cloud site in Lupfig also had an impact on our choice. While the two locations should be able to operate independently of each other and thus enable geo-redundant setups, connections between services at both locations should, at the same time, be as direct as possible. One of the things we liked about Cumulus Linux was that most of our requirements could be implemented using open standards and without the need for proprietary protocols from any particular vendor.

How the solution with Cumulus Linux stands out

The "Cumulus Linux" distribution maintained by Cumulus Networks is a novelty among network operating systems. Unlike the systems of traditional network vendors, it is based on Debian GNU/Linux and is for the most part open source. In order to ensure the stability and security required in an enterprise setting, certain versions are maintained as "ESR" (Extended Support Release) versions and provided with security updates over a long period of time – a strategy known from Ubuntu's LTS versions that is also being adopted in an increasing number of other software projects. One of the components of Cumulus Linux is FRRouting, which is maintained under the umbrella of the Linux Foundation and which we are already using successfully on our border routers.

We spent considerably more time implementing our new switching infrastructure than we had originally planned. Over the course of several releases, we gained experience with Cumulus Linux in our lab and fed our insights back into the network design in many iterations. We also benefited from the community that has formed around Cumulus Linux. There is, for example, a dedicated Slack channel where you can pick up tips and tricks from other Cumulus users; if an issue cannot be resolved this way in a timely manner, Cumulus's own engineers often join the discussion and actively offer their help. Working directly with Cumulus Networks has also proved to be open and productive. Where we actually found bugs, they were carefully analyzed and fixed – including patches that often found their way back "upstream" into the individual open source projects.

Key technical specs and tangible advantages

Cumulus Linux is a network operating system that can be used on devices from a wide variety of manufacturers. The "Cumulus Express" combination that we chose includes hardware from Edgecore. Our switches feature a Broadcom Trident 3 ASIC that supports line-rate switching on all 32 100 Gbps ports, which provides a total of 3.2 Tbps. In addition, the "breakout" option means that any of the 100 Gbps ports can be split into 4 logical ports with 10 or 25 Gbps each, which provides even more flexibility with regard to the systems that can be connected.

We have built our network following the leaf-spine concept, whereby each switch is configured in a redundant manner. All connections are redundant as well: a leaf pair (two "top-of-rack" switches) is connected to the two spines at a total of 800 Gbps. In addition to the multi-100-Gbps networking of our backbone, the hardware used also allows a gradual transition to a multi-25-Gbps connection for individual physical servers. This not only benefits the private networks between our customers' virtual servers, but also connectivity to the storage cluster. Finally, the dedicated connection between our two cloud locations is also well dimensioned at multi-10-Gbps via CWDM on route-redundant dark fibers.

At cloudscale.ch we are aware that the network is the basis for all other features of the cloud. Accordingly, we place a strong emphasis on the performance, reliability, and support of all components used. However, the atypical approach of Cumulus Linux offers even more advantages, which we will describe in a separate article in order to give you some insights into e.g. how we at cloudscale.ch can benefit from synergies between network engineering and system engineering.

Lightning fast,
Your cloudscale.ch team

As creating order is half the battle, a large number of system engineers have defined not only a naming scheme but also an address scheme to optimally support them in their daily work with their systems. It has already been helpful that cloudscale.ch allows any IP address to be used in private networks, and you can now also use our DHCP systems to assign addresses from your self-defined subnet to your servers.

To define your own subnet, first create a private network via API specifying "auto_create_ipv4_subnet": false; this will result in a fully functional layer 2 private network. Then, in this network, create your subnet and enter the IP range of your choice (at least a /24) as the cidr value. For each subnet you can also define the gateway and DNS servers that our DHCP systems should assign to your servers. An example:

$ curl -i -X POST -H "$AUTH_HEADER" -H "Content-Type: application/json" --data '{"cidr": "192.168.1.0/24", "network": "61fa...10ed", "gateway_address": "192.168.1.1", "dns_servers": ["192.168.1.1", "192.168.1.2"]}' https://api.cloudscale.ch/v1/subnets

With or without DHCP – IPs as needed

When launching a new server with a private network, all options are now available to you. If a subnet is defined in the private network, the server is by default assigned a randomly selected address from the DHCP range of the subnet, along with the gateway (optional) and the DNS servers. You can, however, also specify a fixed IP address if you wish. It goes without saying that it is also possible to completely disable DHCP for a server if you prefer.

As an example, the following API call creates a server that has a public interface as well as one in the private network, where the server should be assigned a fixed IP address via DHCP:

$ curl -i -X POST -H "$AUTH_HEADER" -H "Content-Type: application/json" --data '{"name": "firewall", ..., "interfaces": [{"network": "public"}, {"addresses": [{"subnet": "5b71...2912", "address": "192.168.1.21"}]}]}' https://api.cloudscale.ch/v1/servers

It goes without saying that you have the same options when adding interfaces to an existing server later on. For a complete overview of possible interface definitions, please refer to our API documentation.

DHCP is always enabled on the public interface (if present) and cannot be configured any further. You are, however, still free to configure all relevant settings on your server statically.

Please note that DHCP must be enabled on at least one interface (public or in at least one private network). In this way, the server learns a route to our metadata server to retrieve its configuration for cloud-init.

Consistency and efficiency

The advantage is obvious: when creating servers, you can also structure the private network appropriately. For a central firewall with OPNsense, for example, you can directly define a fixed IP address. The other servers to be located behind this firewall are then assigned the firewall IP via DHCP both as a gateway and as a DNS resolver.

It is also easier to maintain your own DNS resolver because you now know the internal IP addresses of your servers from the beginning and can record them directly in the DNS. And if you are experimenting with current Kubernetes distributions, new nodes can automatically integrate themselves into the cluster thanks to a reverse DNS lookup for their own internal IP address.

Using private networks, you have long been able to "wire" your virtual servers together at cloudscale.ch in the same way as with physical servers. Thanks to configurable IP addresses and subnets as well as DHCP options, you can now also model the logical level to enable your cloud setups to integrate ideally into your overall infrastructure.

The right address, right from the start!
Your cloudscale.ch team

cloudscale.ch is a provider of infrastructure as a service (IaaS) in a self-service model, i.e. our customers launch, scale, extend and delete virtual servers and use services at their own discretion, while we provide the necessary infrastructure. Given the nature of our services, physical presence is thereby only necessary in very few cases.

We consider our office location – not least for reasons of "business continuity" – merely as a kind of Internet Cafe, which we can do without in an emergency situation. Our employees have therefore been able to stay at home and work from their home offices more often in recent days.

Last but not least, thanks to redundancy, our entire infrastructure is designed to ensure that your services are always available. There is also sufficient spare capacity available for further growth of customer demand. This way, we avoid hectic rush and can carefully plan any necessary work.

How we want to play our part in the fight

The top priority with regard to SARS-CoV-2 is currently to delay its spread and thus ease the burden on the health care system worldwide. For this reason, we have introduced the following rules, effective immediately:

1. All our employees work from their home offices wherever possible. As already mentioned, the nature of our service does not require us to work at the office.
2. We ask our employees and customers to refrain from in-person meetings and to hold meetings online or over the phone instead.
3. Our employees are encouraged to stay at home whenever possible and to follow the Self-Quarantine Manifesto at staythefuckhome.com.

Please do not hesitate to contact us if you have any questions or concerns. We would like to take this opportunity to thank all those who are involved in the fight for human life and against the spread of the virus, and our thoughts are with all those affected and their families.

Stay safe!
Your cloudscale.ch team

The appeal of many computer games lies in the fact that the computer's next move is not predictable but apparently random. Apart from this entertaining aspect of "randomness", the security of your data and systems also depends on it: data encryption – e.g. with HTTPS or SSH – is based on mathematical methods that rely on the fact that a potential attacker cannot guess the key or derive it from other data.

Using special algorithms, a so-called "pseudo random number generator" (PRNG) calculates the necessary random values/numbers from input values that are as unpredictable as possible. The PRNG in the Linux kernel obtains this entropy ("disorder") from various sources such as mouse movements and network traffic. The random numbers are output, for example, via /dev/urandom and /dev/random.

Additional entropy sources

A number of possible entropy sources (such as mouse movements) are obviously not available in virtualized cloud servers. Especially during the initial boot it can take a while to collect enough entropy from the few available sources to initialize the PRNG. For this reason, servers at cloudscale.ch can now also use the rdrand command, which is a feature of many modern CPUs to generate random numbers. Also newly available is the virtio device /dev/hwrng, which provides random numbers generated on our physical compute hosts.

Both of these new entropy sources are independent of your server's ability to collect enough entropy on its own, and can help to initialize the server's PRNG more quickly. However, whether the server actually detects and uses rdrand and /dev/hwrng depends on the Linux distribution and kernel you are using; if necessary, check the CONFIG_RANDOM_TRUST_CPU and CONFIG_HW_RANDOM_VIRTIO options of your kernel, e.g. in the /boot/config-* file (depending on the distribution).

Benefit automatically from more entropy

An increasing number of Linux distributions contain software that uses the getrandom() system call. This call, and services such as SSH that depend on it, wait after system startup until the server's PRNG is initialized, which in some cases can lead to long delays. Servers at cloudscale.ch are not affected by such delays: thanks to rdrand and /dev/hwrng, the necessary entropy is available in no time, so that services requiring random numbers can be started right away.

You can also tap into the new entropy sources with existing servers at cloudscale.ch. Simply switch off your server completely and then restart it. After restarting, the rdrand feature of the CPU will be available to you, and you can verify it using the following command:

$ grep rdrand /proc/cpuinfo
flags		: [...] rdrand [...]

If your specific operating system also supports the hwrng virtio device, it will be displayed with the following command:

$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio_rng.0

Although it is hardly ever talked about in everyday IT life, "randomness" is an indispensable ingredient for countless processes, especially in the context of security. At cloudscale.ch we ensure that your servers can generate enough randomness right from the start.

Not just random servers!
Your cloudscale.ch team

Verification of our infrastructure has shown that your virtual servers operated at cloudscale.ch are not affected by the current vulnerabilities: the exact CPU models of our Intel-based compute hosts do not suffer from these flaws. AMD CPUs, such as those in our AMD-based compute hosts, which we introduced in the context of our new flavors featuring dedicated CPU cores, are not affected at all. Based on current information, our storage clusters and the peripheral systems of our cloud infrastructure also only contain CPUs that are not affected.

As early as May 2019, we decided to stop using "simultaneous multithreading" on all compute hosts, a feature that could make it easier to exploit the current gaps. Although our CPUs are not affected by the two current vulnerabilities from the outset, the recent discoveries confirm that our defensive approach is effective in minimizing the risk for our customers.

Therefore, there is currently no need for our customers to take action in connection with the two newly disclosed security vulnerabilities. It goes without saying that we are monitoring the situation closely and will take appropriate measures depending on the latest findings.

Should you have any questions in connection with our security measures, we will be happy to answer them for you.

Best regards,
Your cloudscale.ch team

1. In order to create and access buckets in the new LPG region, please use only the following URLs:

• https://objects.**lpg**.cloudscale.ch resp.
• https://BUCKETNAME.objects.**lpg**.cloudscale.ch or
• https://objects.**lpg**.cloudscale.ch/BUCKETNAME

2. In order to create and access buckets in the existing RMA region, please use the following URLs as of now:

• https://objects.**rma**.cloudscale.ch resp.
• https://BUCKETNAME.objects.**rma**.cloudscale.ch or
• https://objects.**rma**.cloudscale.ch/BUCKETNAME

3. The previous URLs:

• https://objects.cloudscale.ch resp.
• https://BUCKETNAME.objects.cloudscale.ch or
• https://objects.cloudscale.ch/BUCKETNAME

will continue to work for buckets/objects in the RMA region synonymously to the URLs stated in section 2 for a transitional period.
ATTENTION: The transitional period ends on 2020-12-31; please update links to these buckets/objects in time to the URLs specifying the RMA region (see section 2).

4. Requests to existing buckets using the URL of another region are answered by our system with a HTTP status code 301 Moved Permanently, which some tools follow automatically. Such requests are counted like regular requests in the cost calculation. However, we recommend that you do not rely on this redirection, but always use the correct URLs.

If you have any further questions regarding our S3-compatible Object Storage, please do not hesitate to contact us.

Best regards,
Your cloudscale.ch team

Reasons to use your own image

In addition to many popular Linux distributions, cloudscale.ch also offers a choice of two firewall distributions when starting a new server. You may, however, prefer a different distribution, e.g. for personal considerations, or to keep your new system as similar to existing ones as possible. By using your individual ISO/USB image, you can install almost any operating system at cloudscale.ch.

You can, however, do even more when using your own image: even if you choose to use Ubuntu, Debian or one of the other operating systems we offer, you have complete control over the initial setup. You can customize the partitioning, use your preferred file system or set up your own disk encryption (in addition to measures on our side). Furthermore, a live image can help to restore access to a crashed system after a mishap. And if required, you can create a consistent, sector-by-sector copy of your servers on an additional volume.

How to use your own images

As a starting point, you need a working server in the relevant cloudscale.ch account, to which you then attach an additional SSD volume with sufficient space for your ISO/USB image. This can be the server that you are going to reinstall with your favorite system, or just a temporary server that is used for the next step. Next, download your image to this server (e.g. using curl or wget) and subsequently copy the image, block by block, to the additional volume:

sudo dd if=my-own-image.iso of=/dev/vdb bs=1M && sync

Caution: It is important that you make absolutely certain that of (output file) is pointing to your additional volume as this path will be overwritten without further warning!

If you want to use the image to boot a server other than the current one, reattach the volume to the desired server now. Then open the VNC console of the target server and restart it. By pressing "Esc" in the VNC console, you get to the boot menu, where the additional volume with your image appears as an extra "Virtio disk". Select it to start booting from your image. You can now use your image as you would a physical server and a DVD.

NB. If keystrokes appear multiple times in the VNC console, simply change "vnc_lite.html" to "vnc.html" in your browser's address bar (and click "Connect").

Some additional notes

After the target server has been installed or repaired, reboot it normally from its root volume. You can either delete the additional volume containing your image or keep it for future use.

The approach described in this article works with many images provided by the distributions for CDs/DVDs (.iso files) or for USB sticks, e.g. with Ubuntu and CentOS. However, cloudscale.ch cannot guarantee that it will work with a particular image.

Please note that the images provided by us for launching servers contain the "cloud-init" package. This package ensures correct configuration of your servers, e.g. by transferring the specified server name and the authorized SSH keys into the server's configuration. If you (re)install your server via a custom image, you will need to specify these settings manually. For the network details, you can either use DHCP or statically configure the details shown in the control panel.

Irrespective of whether you only have to fix a small mishap or need to build up an individual server farm "from scratch", by using your own ISO/USB images, you have full control over the software and configuration of your servers in all circumstances.

Has the right tools,
Your cloudscale.ch team

Terraform offers "infrastructure as code"

Where a configuration management system often assumes existing an infrastructure on which the software has to be configured, Terraform starts one step earlier: you define your required infrastructure in the form of text files, and changes over time can easily be tracked in your usual versioning system. Based on the current state and defined target situation, Terraform derives the necessary actions and creates your systems via our API, thus turning code into infrastructure.

Terraform is open source and can interact with a large number of cloud providers; the respective interface is implemented as a provider plug-in. We are constantly developing the "cloudscale.ch Provider" plug-in further and have enhanced it several times this year so that you can make the best use of the latest features of our cloud.

Support for the latest features

For some time now, our servers have been supporting not only one SSD and one bulk volume each, but virtually any number of volumes. As early as spring, support in Terraform followed, which means additional volumes are now defined as separate resources and can be dynamically attached to servers as well as scaled up during live operation. A restart is still required when scaling servers, and to avoid this catching you on the wrong foot, Terraform asks for your explicit permission for the restart with a special config argument.

Another new feature is the management of multiple private networks and thus of "tiered" infrastructures in Terraform. Private networks are also defined as separate resources; all networks to which a server requires a connection are then specified via interfaces. An overview of all available resources and arguments, including examples, can be found in the "cloudscale.ch Provider" documentation.

Designed for reliability

It goes without saying that our Terraform plug-in also supports our new data center location in Lupfig. You can select the desired location for each resource with the zone_slug argument. This allows you to define the complete infrastructure required for your geo-redundant setups "as code".

In addition to redundancy, it is also important to quickly identify any problems. Thanks to a test suite, which is executed daily by Terraform developer HashiCorp against our productive infrastructure, we obtain timely feedback from a user's perspective. This allows us to investigate potential anomalies before sporadic errors become a real problem for our customers.

By the way: the Terraform plug-in is based on our Go SDK, which is also available as open source and makes accessing our infrastructure easier for other tools written in Go.

Terraform enables the automated – and therefore reproducible – provision of infrastructure and thus fits perfectly into the workflow of many of our customers. Use our latest features in Terraform and prepare the ground for your next sophisticated projects!

Happy holidays!
Your cloudscale.ch team

Characteristics of our new "Plus" flavors

So far, the most common use case for cloud servers has probably been small VMs with at most short load peaks. By sharing physical resources, cloud offerings help avoid high hardware investments and infrastructure overheads. However, the advantages of the cloud over your own hardware also include the fact that you can remain flexible at all times and that ongoing hardware maintenance is taken care of – even in cases where sharing available computing power is not the main focus.

Our new "Plus" flavors are perfect for servers with high performance requirements. Unlike with the existing "Flex" flavors, the physically available computing power is not overcommitted; the allocated number of CPU cores is dedicated to each virtual server. You can and may make full use of this performance at any time, since the computing power of our "Plus" offers is not subject to so-called fair-use regulations. At the same time you are protected given that "neighbors" with compute-intensive workloads on the same hardware have no impact on the number of cores available to your server.

Based on the latest hardware generation

This offer is made possible by the use of leading-edge hardware. cloudscale.ch is one of the very first IaaS providers to employ compute nodes with the recently launched AMD EPYC "Rome" processors, which feature up to 64 physical cores per socket. This provides capacity to combine all the advantages of a cloud server with the computing power of a dedicated server, which results in the best of both worlds, so to speak.

At cloudscale.ch, we have, incidentally, already successfully relied on AMD systems in the past, namely for our Ceph-based storage cluster. The high number of PCIe lanes, in particular, was key and enabled us to migrate completely from conventional SSDs to even more powerful NVMe SSDs.

In addition, it is good to know that after repeated descriptions of side-channel attacks targeting vulnerabilities in processor designs over the past two years, we have also deactivated simultaneous multithreading (SMT) for our latest generation of compute nodes. This ensures that SMT-based attacks are not possible from the outset.

Take advantage of more power right away

We particularly recommend our new "Plus" flavors for virtual servers that constantly require medium to high computing power. With 2 to 112 dedicated CPU cores, you have packed power at your exclusive service 24/7. This allows you, for example, to further increase the efficiency of Kubernetes clusters or other container setups. Workloads that depend on predictable performance can benefit as well given that, without competition from neighboring servers, the CPU cycles are reliably available to your real-time applications exactly when they are needed.

When creating a new server, simply select the desired "Plus" flavor, or scale existing servers as usual. It goes without saying that you can reconsider and switch to any of our other "Flex" and "Plus" flavors whenever you like. This will allow you to play it safe and, thanks to this flexibility, elegantly handle even short-term load peaks, e.g. during your Black Friday promotion.

Try it out for yourself: cloudscale.ch is offering you all the "Plus" flavors with a 25% discount until the end of 2019, i.e. at the price of the corresponding "Flex" offer with the same amount of RAM. If we are able to convince you of "Plus", you will be charged the regular price from January 2020; if not, you can simply scale to any other flavor.

With dedicated CPU power, cloudscale.ch now also meets the needs of your most demanding workloads. It goes without saying that our new "Plus" flavors are available at both cloud locations and are therefore also suitable for geo-redundant setups. This means that you will be prepared for any run.

Got power,
Your cloudscale.ch team

How you can benefit from our new location

One of the benefits of cloud services is that you do not have to worry about purchasing and maintaining hardware and infrastructure. However, the physical location of "the cloud" often still plays a role, e.g. with regard to data protection and the corresponding legislation. And despite all precautions, even cloud data centers are exposed to certain residual risks, such as nearby construction work or flooding. By using a second location with a different risk profile due to physical distance, you can protect the operation of your applications – even from the consequences of a worst-case scenario of this kind.

True to the old adage of "not putting all your eggs in one basket", we recommend that you also keep your most important data and systems at a second location. This will enable you to resume productive operation within a short time in case of an emergency. Whether it is a hot standby system or an active/active setup with load balancing, the most you will ideally need to do is to point the DNS entry to the second location to ensure that you are back online in no time. Even simple data replication (in addition to the regular backup) may spare you considerable stress – and not only in the unlikely event of a disaster.

Technical background information

In addition to the tried-and-tested location in Rümlang (Canton Zurich), we are now also offering our services from Lupfig (Canton Aargau) – by the way, the abbreviations "RMA" and "LPG" we introduced for this purpose are based on the UN/LOCODE scheme. When setting up the new site, we took care to ensure that, even in the event of a total outage of one data center, all services at the other location can continue to run. Accordingly, we built the infrastructure to the same standards and also rely, for example, on a completely redundant power supply, an independent storage cluster (again with NVMe SSDs and triple replication), as well as on separate connections to the Internet and to peering partners.

For your traffic, we operate a fully redundant network infrastructure with at least 10 Gbps per link at both locations. And even though both sites are designed to work as independently as possible, they are nonetheless interconnected. For optimal and fail-safe networking between your systems in Rümlang and Lupfig, we use two direct fiber-optic lines that connect the two locations on separate routes without intersections.

Practical use of multiple zones

We have been able to offer all our services at our new location in Lupfig right from the start. When creating a new server in the cloud control panel, for example, simply select the preferred location, or include the zone parameter in your API call. It goes without saying that the API is backwards compatible; if no zone is specified, the default location is used, which you can set individually in the control panel. Once created, the resources are bound to their zone. This means that e.g. existing volumes or private networks can only be connected to servers at the same location.

As mentioned, we have also set up a separate Object Storage at the new location. Your objects users are automatically valid for both locations, and buckets are placed at the location where they were created. To enable direct access to the desired Object Storage or bucket, they have separate DNS names and IPs; the previous URL objects.cloudscale.ch is now a synonym for the URL objects.rma.cloudscale.ch of the existing location in Rümlang. Cross requests are answered with a status code 301 Moved Permanently, which is automatically followed by some tools. To ensure optimum efficiency and reliability, however, we recommend that you use the correct URLs wherever possible.

The effort has been worth it! With the new location in Lupfig, we can now also offer you the ideal infrastructure for geo-redundant setups. And no matter which location you choose as your "primary" one, you benefit from sophisticated redundancy, optimum performance and the exclusive storage of your data in Switzerland.

All the best from Zurich and Aargau,
Your cloudscale.ch team

Sample applications with multiple private networks

Private networks are used, for example, if web workers, but not their database backends, should be accessible directly from the Internet. They are also employed to protect servers in the cloud behind a firewall such as OPNsense. With the support of multiple private networks, you can now also combine these proven concepts, with a firewall/load balancer setup acting as the interface to the Internet and forwarding legitimate requests to the web workers via the first private network. These web workers in turn access the database backends via a second, separate private network to ensure proper isolation of the individual security zones.

In addition to your public web application, you may want to run internal services in the cloud, while protecting them from access from less trusted zones. Separate private networks can be used to implement this scenario as well. Traffic for your web application is routed by the firewall via one private network to your web server, while your internal tools are connected to your VPN endpoint via a separate private network. This way, your public and internal servers are safely separated in two independent private networks.

How to set up private networks

The new API endpoint networks acts as the key interface for your private networks. With the request:

$ curl -i -H "$AUTH_HEADER" https://api.cloudscale.ch/v1/networks

you are given an overview of your existing private networks:

HTTP/1.0 200 OK
Allow: GET, POST, HEAD, OPTIONS
Content-Type: application/json

[
  {
    "href": "https://api.cloudscale.ch/v1/networks/2db69ba3-1864-4608-853a-0771b6885a3a",
    "created_at": "2019-05-29T13:18:42.511407Z",
    "uuid": "2db69ba3-1864-4608-853a-0771b6885a3a",
    "name": "my-network-name",
    "mtu": 9000,
    "subnets": [
      {
        "href": "https://api.cloudscale.ch/v1/subnets/33333333-1864-4608-853a-0771b6885a3a",
        "uuid": "33333333-1864-4608-853a-0771b6885a3a",
        "cidr": "172.16.0.0/24"
      }
    ],
    "tags": {}
  }
]

With a POST request to the endpoint networks, you can easily create additional private networks. The only mandatory parameter you need to provide is a name so you can recognize the network later. Using the existing API endpoint servers you can now determine whether and in which private networks a server should have interfaces. This works at the time you create a new server as well as later on.

By default, our system assigns a randomly selected private IPv4 range ("subnet") to the new network and will later assign IP addresses from this range to your servers in this network through DHCP. It goes without saying that you can deactivate both of these if desired. And as before, you can statically configure any IPv4 and IPv6 addresses on servers in your private networks. In the case of a network with a subnet, you simply need to make sure you avoid address conflicts with our DHCP servers. More information about the available options can be found in our API documentation.

Some useful hints

For optimal performance in the private network, the MTU is 9000 bytes ("jumbo frames") by default. You can, of course, change the MTU at any time, e.g. if your specific setup requires the 1500 bytes known from the classic Ethernet.

Please note that a server must be assigned an IPv4 address via our DHCP server in at least one of its networks. The reason for this is that DHCP is also used to set the required route so that cloud-init on your server can reach our metadata server.

In the near future we will also be expanding our cloud control panel so you can directly select existing or new private networks when creating a new server via your browser.

Last but not least, you can set user-defined tags for your private networks and filter for them.

In many cases, a more granular segmentation of the servers used can make sense, either to reflect the logical structure of your setup, or to add another level to your security concept. The latest evolution of our private networks makes it possible for you to build up your server landscape in the way that best suits you and your specific use case.

Connected at all levels,
Your cloudscale.ch team

Tags make it clear at a glance what a particular resource is all about or where it belongs. Such "labels" with key/value pairs can be attached to most of your resources: servers and server groups; volumes; Floating IPs; and Objects Users. This allows you, for example, to differentiate between "prod" and "development" environments, to associate resources with the respective end customer, or to record a comment.

When querying resources, you can filter them directly by tag to display only the relevant objects. Filtering can be done by a specific tag content (e.g. "tag:Env=Prod" for all production servers) or by the presence of a given tag regardless of its content (e.g. "tag:Customer" for all servers assigned to any end customer).

How tags are created and retrieved

Tags are currently implemented for our API. The already existing endpoints of the supported resources now recognize an element "tags", which accepts a JSON object with freely definable key/value pairs. These are automatically included in the output of a GET request, as in the simplified example below:

[
  {
    "href": "https://api.cloudscale.ch/v1/servers/c10...",
    "name": "WebWorker1",
    "created_at": "2019-09-18T17:48:21.547057Z",
    "status": "running",
    "flavor": {
      "slug": "flex-32",
      "name": "Flex-32",
      "vcpu_count": 8,
      "memory_gb": 32
    },
    "server_groups": [],
    "anti_affinity_with": [],
    "tags": {
      "Env": "Prod",
      "Customer": "Cloud Corp.",
      "Lifecycle": "Installing",
      "Comment": "Don't forget the monitoring! (Remove comment when done.)"
    }
  }
]

Tags are set and changed using a PATCH request to the URL of the resource in question:

$ curl -H "$AUTH_HEADER" -H "Content-Type: application/json" -X PATCH --data '{ "tags": { "Env": "Prod", "Customer": "Cloud Corp.", "Lifecycle": "Live" }}' https://api.cloudscale.ch/v1/servers/c10...

If only resources with a certain tag are to be retrieved, the desired criterion is simply appended as a URL parameter:

$ curl -H "$AUTH_HEADER" https://api.cloudscale.ch/v1/servers?tag:Env=Prod

It goes without saying that further information and examples can also be found in our API documentation. In addition, our Ansible Cloud Module supports tags for the most important resources starting with the upcoming Ansible version 2.9.

With tags, we are responding to a request made by several power users among our customers. We are glad that all our users can benefit from this helpful feature, which allows you to navigate even large deployments with ease.

Keeping everything in order with tags,
Your cloudscale.ch team

Docker containers are usually started on Linux servers. Setting up such a Linux server at cloudscale.ch and installing the Docker environment on it now requires just a single command: docker-machine. With the "cloudscale" driver, Docker Machine can interact with our API and define all the required settings. In no time, the new Docker host is ready to start the first container on it.

Docker Machine is a command line tool that can be installed either on your local computer or on a management server/jump host. Additionally, download our open source "cloudscale" driver from GitHub into a directory in the path, and generate an API token via our cloud control panel. A command as shown in the following will then create a ready-made Docker host for your containers:

$ docker-machine create -d cloudscale --cloudscale-token=<API_TOKEN> my-docker-host

A docker-machine env my-docker-host then returns the details required to use the new Docker host immediately.

Managing K8s clusters at cloudscale.ch with Rancher

Not just individual Docker hosts, but entire Kubernetes clusters can be conveniently managed using Rancher. Rancher, which itself runs in a Docker container, provides a web interface you can use to configure your cluster as desired. After this, all the necessary virtual servers are automatically created and completely set up. The deployment of apps and ongoing cluster management also take place via the same GUI.

Rancher can interact with a large number of cloud providers – including cloudscale.ch. Under "Node Drivers", simply enter the details according to GitHub and you will be able to select "Cloudscale" as the infrastructure provider when creating a new cluster. By the way, Rancher is completely open source, and we are in contact with Rancher Labs about including our driver in future versions of Rancher.

With Docker Machine and Rancher, cloudscale.ch supports two essential tools for managing container environments even more easily. Whether via CLI or graphical web interface, you can create the ideal nodes for your workloads in no time at all.

Perfectly integrated,
Your cloudscale.ch team

Solid-state drives (SSDs) are significantly faster than conventional hard disks because they are based exclusively on memory chips instead of moving magnetic disks and read/write heads. This also shifts the bottleneck: current SSDs can store and deliver data faster than the widespread S-ATA connection allows for. Thanks to the NVMe standard, SSDs can be connected directly to the fast PCIe interface of a PC or server instead, thereby leveraging their full potential.

At cloudscale.ch, we have gradually replaced our SSDs by models featuring an NVMe interface, so that today all your SSD volumes are stored on NVMe SSDs entirely, delivering the best possible performance. This was made possible by sourcing new storage systems based on AMD Epyc CPUs that offer the necessary number of PCIe lanes. By the way: even with our bulk and object storage, the Ceph DB and object cache reside on NVMe SSDs for optimal performance.

Why we decided to migrate our Ceph cluster to BlueStore

BlueStore, the recommended storage backend since the Luminous release, was developed specifically for Ceph clusters and a first version was released about three years ago. Instead of storing the data on an XFS file system in the background, Ceph uses BlueStore to completely manage the block device by itself and thus has complete control over the journal, caches, etc. As part of the upgrade of our storage systems to Ubuntu 18.04 LTS, we migrated our Ceph cluster from XFS to BlueStore – not least because of the significant performance gain that BlueStore provides compared to XFS.

An additional advantage of BlueStore are the integrated checksums: these are automatically stored for all data and metadata and validated each time data is read from the storage media. BlueStore thus offers an additional mechanism for maintaining the integrity of your data ‐ one of the three central components of information security in addition to availability and confidentiality.

What benefit disk encryption by the cloud provider offers

Together with the migration to BlueStore, we also implemented the encryption of all data disks in our storage systems. This means that as of now all your volumes and objects are automatically encrypted "at rest". In addition to the already established process that disks are secure-erased by our employees when taken out of service, this encryption provides a further protective layer and thus complements our existing measures to increase information security.

The main purpose of this encryption is to protect your data from third parties, e.g. in case we have to dispose of a defective SSD. It is in the nature of things that we still need to be in possession of the necessary keys in order to operate your servers and volumes as usual. Disk encryption by the cloud provider thus complements your own efforts to protect your data, such as encrypted transmission over the Internet or encryption of your volumes using LUKS.

The security of your data has always been one of our top priorities (see also Certified as per ISO 27001, 27017 and 27018). Furthermore, we always want to offer you the best possible performance. All the more reason for us to be pleased that our storage system has made a further leap forward in both areas.

Pump up the volume(s)!
Your cloudscale.ch team

How the costs for Object Storage are structured

No matter whether you use our Object Storage to keep backups, as a repository for your container images or as a web server for your static assets, the storage space used is averaged over the day and charged to your account at midnight (Zurich local time). The daily costs also comprise a component for outbound network traffic (inbound traffic is free) and an amount for HTTPS requests made to your buckets and objects (also see our pricing).

Past use of your buckets at a glance

The most current data was already reported in our cloud control panel in the past so you could track occupancy and access statistics almost in real time. Now you can also display past usage data for your buckets. Instead of the "Live" view, set a freely selectable time frame to see the total quantity of outbound traffic and requests as well as the storage usage averaged over this period.

Using "Hide Deleted" you determine whether, for the shown Objects Users, the list should include buckets that have been deleted in the meantime. By the way, in order to ensure the best possible clarity of usage and costs, the dates in Objects Metrics always refer to local time in Zurich, regardless of the time zone you have specified for displaying times in your user account.

Even more data available in our API

Of course the Objects Metrics can be accessed via our API, too. The API also reports inbound traffic as well as the number of objects – averaged over the selected period – stored in the corresponding bucket. These two values have no impact on costs for our Object Storage, but can still be helpful for your usage evaluation. Furthermore, through the API you can also see usage by Objects Users that no longer exist.

If you need the metrics for a specific bucket or Objects User only, specify the desired filter directly in the API call:

$ curl -H "$AUTH_HEADER" 'https://api.cloudscale.ch/v1/metrics/buckets?start=2019-06-09&end=2019-06-11&bucket_name=mytestbucket'

{
  "start": "2019-06-08T22:00:00Z",
  "end": "2019-06-11T22:00:00Z",
  "data": [
    {
      "subject": {
        "name": "mytestbucket",
        "objects_user_id": "62c2...ab53"
      },
      "time_series": [
        {
          "start": "2019-06-08T22:00:00Z",
          "end": "2019-06-11T22:00:00Z",
          "usage": {
            "requests": 136,
            "object_count": 157,
            "storage_bytes": 18036937,
            "received_bytes": 10855616,
            "sent_bytes": 14278972
          }
        }
      ]
    }
  ]
}

This ensures that output is limited to data that is actually relevant to you. It goes without saying that you can find all the details about calling the API in our API documentation.

With Objects Metrics, we provide you with a new tool for breaking down usage of our Object Storage by the day – be it spontaneously or in an automated manner, for your accounting team or for profiling a specific setup. Either way, with our Object Storage you only pay for what you actually use.

For the best transparency,
Your cloudscale.ch team

Be it paper formats, light bulbs or food safety: often unnoticed and behind the scenes, standards ensure smooth operation in all areas of life. The standards of the ISO 27000 series are well-known in the field of information security, which encompasses not only the confidentiality of information but also its integrity and availability. Certifications according to these ISO standards do not apply to a specific product, but to a company or its management system which is designed to guarantee information security.

ISO/IEC 27001:2013 defines a set of 114 so-called controls and thus a list of requirements for all possible aspects of information security that have to be implemented. How this is done in concrete terms is up to the company – the standard gives enough leeway so that organizations of all sizes and industries can implement it. As a public cloud provider, we have therefore implemented the standard with a corresponding focus on Infrastructure-as-a-Service (IaaS).

In our case it was evident to implement two more standards at the same time: In contrast to ISO 27001 which is universally applicable, ISO 27017 deals specifically with cloud services and defines a number of additional controls that are relevant for cloud providers and users. ISO 27018 in turn is about the protection of personally identifiable information (PII) in public clouds – a topic that has received increased attention especially due to the EU GDPR. cloudscale.ch Ltd has also been audited successfully according to these two standards (ISO/IEC 27017:2015 and ISO/IEC 27018:2019).

You can find all certificates on our website or directly at:

• https://www.cloudscale.ch/en/iso-27001-certificate.pdf
• https://www.cloudscale.ch/en/iso-27017-27018-certificate.pdf

How our path to certification looked like

Looking back, we can state that the introduction of an Information Security Management System (ISMS) and its certification has not changed our daily work significantly. The security mindset has always been part of our DNA and most of our information security measures have already been in place for years. For quite some time however, it has become apparent that end-to-end certification of the entire supply chain is important to our customers. The decision for the official certification according to ISO 27001 was made about 1.5 years ago. Subsequently, we sought external know-how for this process.

The actual "ISO project" took off in spring 2018 with a series of workshops together with our consultant, Dieter Roth, and a set of templates for the ISMS. The hard work then followed when it came to adapting the generic documents to our reality (and, admittedly, a tiny bit in the opposite direction). After all, our documented ISMS needed to reflect the guidelines and processes that we consider appropriate for our daily work. Of course, it was an advantage that our data centers were already ISO 27001 certified, so we did not need to work out our own regulations in this area.

Finally, the certification audit – sort of an exam situation – was surprisingly pleasant. On three days, we had to answer an independent expert's questions and provide various evidences. We felt that the auditor from Swiss Safety Center understands our business, and it quickly became clear to him why we do things the way we do. We certainly had not dared to hope that not a single deviation would be found in the entire audit. All the more this result confirms our security culture, which has shaped our work right from the start.

Which next steps lie ahead of us

The initial certification is a long-awaited milestone and for many of our customers it is an affirmation for the trust that they put in us right from the start. However, one of the key requirements of the ISO/IEC 27000 standards is continuous improvement, which must be incorporated in the ISMS. Not only the security precautions, but also all processes have to be reviewed and developed over and over. Regular assessments are carried out in annual internal audits as well as in surveillance and recertification audits conducted by the certification authority every year.

Of course, the sense of security also affects all of our future projects. Examples include ramping up another Swiss data center site, which enables our customers to build geo-redundant setups ( availability), the migration of our Ceph cluster to BlueStore, which features integrated checksums ( integrity), and disk encryption of our storage servers ( confidentiality).

Information security has been a key concern of cloudscale.ch from the very beginning, and discussions with our customers confirm its importance time and again. It is not without pride that we see the successful certification according to ISO 27001, ISO 27017 and ISO 27018 as a recognition for our commitment and as a motivation to continue on our chosen path.

Signed and sealed,
Your cloudscale.ch team

The latest CPU vulnerabilities affect all Intel processor models released in the last few years. Processors from other vendors such as AMD and ARM are not affected according to current knowledge. The flaws in the chip design allow one thread to access data that is processed by another thread on the same CPU core via so-called side channel attacks. Various buffers within the CPU retain data fragments, which can then be read by another thread in certain cases. Activated Hyper-Threading additionally facilitates the exploitation of these vulnerabilities.

This is particularly relevant when executing program code that is not trusted from the point of view of a specific process or user. Be it active content on websites you visit, or software in a "neighboring" virtual server in the cloud: malicious code can potentially access parts of your data that have just been processed on the same physical CPU core.

How cloudscale.ch is tackling these security bugs

It is in the nature of public cloud providers to run "untrusted code" on their compute nodes. Intel CPUs of the affected series are used at cloudscale.ch as well. Accordingly, we take this issue seriously and are working on eliminating the known attack vector completely. As a first step, we have applied all available security updates in our lab among other necessary changes. This includes microcode updates provided by Intel for the affected processor series, the deactivation of Hyper-Threading, an updated Linux kernel as well as patches for the virtualization and storage layer. As with every update, tests are currently running to ensure that the security updates do not have any unwanted impact on the stability of our infrastructure.

As soon as our tests confirm that the updated components are working as expected, we will update the productive systems using the same procedure. In order to secure all affected systems as quickly as possible while remaining operational, we have scheduled an emergency maintenance window, which will last from now until (and including) next Tuesday 2019-05-21. We will do our best to minimize the impact on your virtual servers: before we start working on a compute node, we will move all virtual servers to another, already updated node using live migration. However, it is possible that you may notice degraded server performance and/or short interruptions of network connectivity during live migration. We apologize for any inconvenience this may cause.

What you should do in order to secure your servers

The measures that we can take on our side protect your virtual servers' data against access from other virtual servers. In order to protect your data against access from other processes within the same virtual server, please install the security updates released by the respective Linux distribution and other software vendors.

To mitigate the vulnerabilities, Intel recommends flushing the affected buffers in the CPUs when switching between processes with different permissions. Intel's microcode updates for the affected CPUs provide adjusted routines. After our maintenance window, i.e. as of Wednesday 2019-05-22, once you switch your virtual servers completely off and on again (a reboot is not sufficient), the new CPU flag "md_clear" will be visible inside your server. Correspondingly updated versions of your operating system and other software may use this to detect if and how they should flush the CPU buffers to best protect your data from other, potentially less trusted processes within the same virtual server.

Even though – according to current knowledge – the new attack scenarios are relatively difficult to exploit and potential access to data is not possible in a targeted manner, we make every effort to mitigate these vulnerabilities quickly and completely. For the best possible protection, we recommend that you promptly install all available security updates on your server as well. Should you have any questions regarding our current measures, please do not hesitate to contact us.

For secure servers,
Your cloudscale.ch team

There are several reasons to run applications or microservices in containers such as Docker. Examples include proper separation or independent deployments of individual services. Since container virtualization, unlike fully virtualized machines, causes hardly any overhead, even a fine-granular separation of services in containers consumes only marginally more resources.

Kubernetes (or "K8s") is an orchestration solution for managing such containers. It launches all the required containers in the desired number and distributes them across the available nodes. If a container fails, it is automatically restarted on a suitable node. Last but not least, Kubernetes can be controlled using config files and scripts and thus perfectly integrated into configuration management systems.

How CSI enables self-service for storage

By default, such containers have ephemeral storage, i.e. changes in the file system of a container are lost on restarts. Of course, so-called "persistent volumes" can also be created and passed through to a container. Up to now, however, this was typically associated with manual effort as well as coupling to a specific node and therefore did not really fit into the concept of dynamic containers.

With the recently adopted "Container Storage Interface" (CSI), there is now a defined standard for triggering the automatic creation of an according volume from a "Persistent Volume Claim". This volume is then mounted directly in the corresponding container – no matter which node the container is currently running on. Of course, the volume can also be re-attached to another container and deleted right from within Kubernetes if required.

What other advantages CSI offers at cloudscale.ch

Just like the volumes of our virtual machines, persistent volumes for Kubernetes are based on lightning-fast SSD-only storage and can be of virtually any size. For space requirements of 100 GB or more, inexpensive bulk storage is available as well. The selection is made right in the Persistent Volume Claim using the parameter "storageClassName" (cloudscale-volume-ssd or cloudscale-volume-bulk).

As an additional feature, we also offer full disk encryption with LUKS. Encrypted volumes are created easily by providing a special storageClassName and can only be used if a section with the correct encryption key is configured in Kubernetes – a potential attacker without this key will only see data garbage. Whether encrypted or not: at cloudscale.ch persistent volumes for Kubernetes are stored exclusively in data centers located in Switzerland.

For your very first steps we recommend Rancher for the easy installation of a basic setup with Kubernetes. From there, you just need to install the cloudscale.ch CSI driver from GitHub and configure an API token generated in the Cloud Control Panel once. Of course, various configuration examples for containers and volumes are available on GitHub, too.

Cast off!
Your cloudscale.ch team

OPNsense is a popular distribution for operating e.g. routers, firewalls, NAT or VPN gateways. User-friendliness is a top priority: the firewall is set up with the help of a wizard and thereafter configured completely via a graphical web frontend. There is no need to deal with configuration files. However, if you do not want to restrict yourself to the web frontend, you can still enjoy full SSH access to your firewall.

The feature set covers all your needs: in addition to its functionality as a NAT gateway for your private network, the firewall also acts, for example, as a VPN endpoint or as a load balancer for redundant web workers. Plug-ins for virtually every use case complete the package. OPNsense is based on FreeBSD and is an open-source project supported by a strong community. It is very economical in its use of RAM and CPU power, thus enabling cost-efficient operation.

What a simple firewall setup can look like

Private networks have been available at cloudscale.ch for quite some time and are ideal for servers that need to run in a professional data center but must not be directly accessible from the Internet. Instead of connecting servers to the LAN in your office, you can set them up at cloudscale.ch and connect them to your "private network", which is completely invisible to the Internet and other customers. Create a virtual server with OPNsense to serve as a firewall between the private network and the Internet. This gives you full control over which data should flow where – and where it should not flow.

Accessing your data remains really easy as you can use the OPNsense web frontend to configure a VPN and create a user account for each authorized person. As soon as they connect to this VPN, they can access your servers as usual – irrespective their own location. It goes without saying that data traffic in the VPN is encrypted to protect your data from being spied upon. This way, you also provide employees working from home or on the road with optimal access to your internal IT tools.

An OPNsense firewall also provides additional protection for publicly accessible systems such as your website. You can set up another barrier against attackers and prevent many attacks altogether by making services such as database backends unreachable from the Internet. A reverse proxy on your OPNsense firewall (e.g. with the HAProxy plugin) forwards the HTTP(S) requests of your visitors to the web server in your private network and delivers the corresponding web pages via the Internet. A further advantage is that HAProxy also supports setups with multiple web servers, thus allowing you to distribute the load and even keep your website available in the event of a web server failure or during maintenance.

Further tips for you

For optimal security, we recommend the use of strong passwords and the timely installation of any security updates available for your firewall. If you prefer to use keys for SSH access, you can specify them in OPNsense's user management. Like our cloud control panel, OPNsense also supports two-factor authentication via TOTP.

A VPN and a reverse proxy, as described above, are just two of many useful applications. It is also possible to route Floating IPs directly to internal servers and at the same time benefit from the advantages of a dedicated firewall system.

In addition to OPNsense, we also offer you to choose the pfSense CE distribution for your virtual servers. Based on the same roots, the two distributions are fine-tuned to the needs of the respective community. In most scenarios, however, choosing one of the two solutions is primarily a matter of taste.

The OPNsense and pfSense CE distributions offer a great deal more than can be discussed here. Explore the numerous features in the user-friendly web frontends and learn more about the available functions in the extensive documentation of the OPNsense and pfSense CE distribution.

Batten down the hatches!
Your cloudscale.ch team

Even though Ceph does many things automatically, some administrative tasks still remain. Mimic supports our sysadmins with a new dashboard, which summarizes all important information about the current cluster status at a glance. The command line tools of Ceph now consistently format their output as JSON so that this data can be processed in scripts more easily.

Improvements were also made to the upmap mechanism. This feature, which was first introduced in the previous version "Luminous", makes it possible to distribute the data evenly across all OSDs if an imbalance has accumulated during ongoing storage usage. This way, selective space and performance bottlenecks can be avoided. Finally, Mimic receives (security) updates in a timely manner and is supported by the latest Ceph-Ansible playbooks, which already hold a great deal of know-how from the Ceph community.

Three helpful features for objects you should know about

One of the latest features of our S3-compatible object storage is "bucket lifecycle": You can define when objects should expire, e.g. so that backups stored in the object storage are automatically removed after a certain period of time. Using a user-definable prefix, you can specify the set of objects for which a certain lifecycle should apply. The system then processes the defined lifecycles daily between midnight and 6:00 AM (CET/CEST).

"Server-side encryption" ensures that your data is stored encrypted in the object storage. Using the "SSE-C" mode supported by cloudscale.ch, key management remains completely in your hands: you decide which objects are protected by which key. The subsequent retrieval of these objects will then only be possible using the respective key.

Finally, "bucket policies" allow you to set detailed permissions for your buckets and objects. Define which other users should have access and which actions are allowed. If, for example, you want to make objects available to someone for download, simply create an additional objects user and grant them the necessary read rights using a bucket policy.

What further improvements we are planning based on Mimic

In the background, our Ceph storage cluster distributes all data across a series of storage systems, replicated three times. The individual data fragments are stored in an XFS file system on the physical disks. Following the upgrade to Ceph Mimic, we are now planning to switch to the new "BlueStore" storage backend, which had been officially introduced with Luminous. The POSIX file system as an intermediate layer is no longer necessary since BlueStore stores the data directly as objects on the block device. Another advantage of BlueStore are the integrated checksums for all data and metadata. This ensures that retrieved data is actually correct every time it is being read.

We will use the successive re-creation of the Ceph OSDs during the migration to BlueStore to implement one further improvement at the same time: the encryption of all data disks in our storage cluster. This will provide an extra layer of security to protect your data, e.g. in the event that we have to dispose of a defective disk.

At cloudscale.ch you can take full advantage of a distributed and replicated storage cluster. And thanks to the ongoing development of Ceph by its active open-source community, you benefit from new features as well as performance and reliability improvements with every upgrade. Without lifting a finger.

Up to date with Ceph Mimic,
your cloudscale.ch team

Following our high ambition regarding simplicity, the start of a new server remains basically unchanged. For optimal performance, the operating system is installed on an SSD-only volume, whereby the first 10 GB are free as before. However, with a click on "Show more options" you can now add virtually any number of additional volumes to your new server. For example, you can create a separate volume for /var – without changing the existing partitioning of the root volume. Additional SSD and bulk volumes can also be added or removed later as required.

With most available operating system images, a maximum root volume size of 2 TB is viable (due to partitioning scheme and file system, among other things). With additional volumes you can now go beyond this limit and manage larger amounts of data on our high-performance SSD-only storage cluster. And if you want to start small first, scaling volumes up later now even works on the fly: after OpenStack did not support this feature in combination with Ceph in the past, engineers from cloudscale.ch have developed a corresponding solution, which will also be provided upstream to the official OpenStack project.

Which other possibilities are available through our API

The cloudscale.ch API of course offers all the benefits mentioned above as well. It is also possible to detach additional volumes from the respective virtual servers and connect them to other servers later. This allows you to use such volumes to move data from one virtual server to another. Please note that the root volume of a virtual server cannot be detached from the server and/or deleted separately.

In the same way you can "put aside" existing data, e.g. while the respective virtual server is being deleted and reinstalled. In this case, pass an empty list to the API call as the new server UUID – the volume with the data remains in your account and can be reattached to another virtual server at any later time. For more information about the newly available API calls, please refer to our API documentation.

What to look forward to as a Kubernetes user

Support for "CSI" is already in the pipeline: The "Container Storage Interface", whose specification is currently being finalized, is a defined interface for the automatic provisioning of "Persistent Volumes" in Kubernetes. Without manual intervention, persistent volumes of the desired type and size can be created as soon as a container references a corresponding "Persistent Volume Claim". Persistent Volumes created in this way are not bound to a specific node, but available wherever they are needed by a container.

With the support for additional volumes and the extension of our API, we have laid the foundations on which the cloudscale.ch CSI driver will be based. Of course, the enhancements will also benefit all other orchestration solutions, including our Ansible Cloud Module and the Terraform plug-in for the provider "cloudscale".

If in the past you sometimes wished for the flexibility of an external hard drive, additional volumes now offer you just that. They are also the ideal solution if, for example, you need more storage space only temporarily – as soon as you no longer need the space, simply delete the volume again. Or just let the orchestration tool of your choice do the work for you thanks to the new API calls.

The perfect volume for all your data,
Your cloudscale.ch team

The first point of contact when using cloudscale.ch is our cloud control panel, which we developed in-house. This software, which is written in Python, provides you with the web interface and API to manage your servers and handles the billing process for services used. In the background, our control panel relies heavily on OpenStack. As one of the leading open source projects in this area, the cloud platform manages the physically available computing power, allocates IP addresses and configures internal networks between your servers.

Equally fundamental is Ceph, a distributed storage solution that is also maintained as open source and ensures the replicated and performant storage of your volumes and objects. However, the "smaller" building blocks in our setup are also essential, e.g. our DNS system, ExaBGP for the dynamic allocation of Floating IPs, and RabbitMQ, which acts as a kind of glue between our control panel and other involved systems.

Examples of potential sources of error

Much of what appears as one coherent action from a user perspective requires several separate steps in the background. In addition to the actual creation of a new virtual server, for example, a network port is created, an IP address assigned, a volume with the selected operating system provided and a reverse DNS entry set. No matter how well everything is tested, you can never completely rule out the possibility of encountering an unexpected error in any of the integrated software components.

So-called race conditions are another possible source of errors. To avoid inconsistencies, certain actions or parts thereof can only be executed one at a time; if the same step is also required by an action running in parallel, one of the two actions fails. Furthermore, some steps depend on additional conditions, e.g. that certain safety limits ("quotas") are observed.

Pillars of error handling at cloudscale.ch

In the context of error handling at cloudscale.ch, our primary goal is to ensure that every action results in a usable state. We have, therefore, implemented prepared rollbacks where appropriate. If an error in a sub-step would, for example, lead to a server that does not work and that, due to a subsequent error, can possibly not be deleted, the rollback function comes into play. It ensures that already completed sub-steps are reversed, so that – despite the error – a clean state is reached again at the end.

It goes without saying that it is even better to avoid failure as far as possible. This is why we permanently monitor our systems for error messages and check in each individual case whether this can be avoided in the future with a specific patch or other improvements. In addition, we have optimized transactions that could lead to race conditions so as to minimize the probability of actual parallel execution. Should a transaction nevertheless need to be aborted because it coincides with another parallel operation, the case is intercepted and the transaction is retried up to a defined number of times. In this way, the action chosen by the user might still be completed successfully.

User-friendliness has always been a main concern at cloudscale.ch. Even though the systems behind the scenes are complex and there is always potential for something to go wrong, the aim is for actions in our cloud control panel and API to lead to the desired result whenever possible. And even when this is not the case, nothing should prevent you from taking further/other actions.

Well prepared,
Your cloudscale.ch team

Today's users expect websites to respond quickly; the faster a page loads, the fewer visitors click away. This factor that directly impacts revenue in an online store is also important for our customers' workflow in our cloud control panel. This means that in an increasing number of locations in our control panel, we avoid reloading the entire page; instead, individual elements such as the status of your servers are retrieved in the background and simply updated on the page that is already displayed.

This approach is called "Ajax" and is supported by various libraries and frameworks. We chose React (in combination with Redux) because this open-source library is used by a large community and many compatible libraries are available for further functionality. With React, the components of the individual pages are generated in the browser using JavaScript. While a component executes an asynchronous operation (e.g. loading data), the user can keep on working – unlike with a reload of the whole page that would block everything.

Advantages for our software development

The fact that our cloud control panel is no longer delivered as a fully compiled HTML page by our systems also simplifies the work of our software developers. By retrieving a great deal of the information from our servers without any formatting and only displaying it in the browser by using React, the Ajax API can be kept practically identical to the existing public API, thus removing the need to implement the same functionality twice. This leaves more time for the rapid implementation of new features.

Another advantage of this approach is that unit tests can also be utilized for the graphical frontend. This is in contrast to HTML pages generated on the server with additional JavaScript, which can hardly be tested automatically. React is also ideal for a step-by-step transition: wherever React components noticeably improve usability, we have them in place already. Where the benefits are more subtle, we will combine the conversion to React with other improvements, which saves us the effort of dealing with the same item multiple times.

Where our control panel is heading with React

The more components are implemented using React, the closer our cloud control panel gets to a single-page app. Already today, the tabs in the server detail view can be addressed directly with their own URLs, while switching between the tabs does not require a reload of the page. Where useful, this approach will be adopted in other cases as well.

When developing new features, we usually first implement the functionality in our public API in order to allow various DevOps tools to make use of it. From here it is only a small step to make the feature available in the web interface, too. The required Ajax API endpoint is largely defined by the previously created endpoint of the public API, and React takes optimal care of presenting the functionality in the browser using JavaScript.

While we support the integration of cloudscale.ch into an increasing number of orchestration and management tools, the usability of our own cloud control panel remains of particular importance to us. Thanks to React, you can manage your servers in a consistent and smooth workflow, almost as if our cloud control panel were a local app on your computer.

For server management with flow,
Your cloudscale.ch team

Our system design for high availability also serves us well in the case of upgrades. In this setup, all components are present in at least two instances, or at least three if a quorum is required. This not only protects us and our customers from unplanned downtimes in the event of a failing individual system, but also allows us to process the systems sequentially during maintenance work so that the productive operation of the entire service is guaranteed without interruption.

Accordingly, the OpenStack components responsible for creating and managing the virtual servers have been updated system by system. And since at least two instances of each component were always in operation, the management of the virtual servers remained available to our customers via cloud control panel as well as through the API. In the case of the compute nodes on which the virtual servers run, an OpenStack upgrade would even be possible during production operation. However, simultaneous upgrades of the underlying Linux system often require a reboot. Even in such a case your virtual servers remain online without interruption, thanks to prior live migration to another compute node.

How OpenStack supports non-disruptive upgrades

OpenStack is a complex system of different components that interact with each other. It is not entirely self-evident that it is possible to update these components (or, in the case of a redundant structure, only individual instances of them) one after the other: in the course of this process, part of OpenStack's overall system is still in the old state, while the other part is already on the newer level. The OpenStack project therefore consciously makes sure that the individual components also work together with components that are still running the previous version. Only then is it possible to keep the system as a whole functional during the entire upgrade process.

For the recent upgrade to OpenStack "Pike" we started as usual with comprehensive tests in our lab environment. We optimized our Ansible playbooks so that at least two instances of each OpenStack component remain available at all times. In order to make sure that the interaction of the components also across version boundaries works as expected, we continuously created new virtual servers via API – a potential problem would have been detected in the lab at this point.

What we do to reduce the impact even further

In some cases short interruptions (usually less than 5 minutes) of the cloud control panel and the API could not be avoided, e.g. if the configuration of a load balancer had to be adjusted to the new version of the OpenStack component behind it at the same time. While running virtual servers remain unaffected by this, changes are not possible in such a moment ‐ especially not moving a floating IP to another virtual server, which many of our customers use as a failover mechanism for highly available setups.

We are therefore working on limiting necessary downtimes even more by, for example, blocking affected operations while the control panel and API in general remain available. During the upgrade to "Pike", we were already able to use such a mechanism: when major changes in OpenStack's own API temporarily prevented the scaling of volumes, we were able to reflect precisely this in our interfaces and continue to allow all other actions.

Upgrading a system as complex as OpenStack is a matter of several hours. It is not trivial to ensure the best possible availability throughout this process. We are already well positioned here having redundant systems at every level. Where interruptions are unavoidable nevertheless, we try to keep them to a minimum – ideally, only a single operation needs to be temporarily blocked. And as always: test, test, test.

Seriously prepared,
Your cloudscale.ch team

While we obviously are an "infrastructure company", we also write our own software, e.g. for our cloud control panel. Just like many of our customers, we use Git to keep track of the source code that makes our user experience unique. This is where GitLab CI comes into play: GitLab CI detects when new commits are pushed. On every new commit, it runs a "Pipeline" consisting of multiple testing jobs.

In the case of our cloud control panel we have two different sets of tests: Unit tests and integration tests. Unit tests are run isolated against a small piece of code and do not require interaction with other services. Integration tests on the other hand really test the entire infrastructure. For instance, we have tests that actually start servers in our OpenStack-based cloud, or create Buckets in the Object Storage which is backed by our Ceph cluster. This gives us a good indication that the now-changed code still fits the use cases our customers rely on.

How Continuous Integration helps with our quality assurance

To make sure that all of our services are continuing to work, we are also running our tests every night, in addition to the permanent monitoring of all the systems and individual components. This enables us to detect potential problems within our infrastructure early and take action to ensure the best service possible.

In addition, our Terraform implementation is also tested on a daily basis using a special set of acceptance tests. This way we make sure that our Terraform provider interacts seamlessly with our API.

A good test suite is at the core of every good software and should continue to evolve and improve over time. While we keep improving and extending our software, we can be confident that our large and growing set of tests helps us avoid breaking things. Automated testing not only enables us to develop code faster, but also allows for broader test coverage, resulting in higher product quality.

Why we move further towards Continuous Delivery (CD)

While automated integration testing takes a huge load of tedious, manual work off our shoulders, there is still room for improvement: We also plan to use Continuous Delivery with GitLab CI. Continous Delivery will allow us to push to the production branch and just watch that commit being deployed.

We know that you want to use the latest features and improvements as soon as possible – who wouldn't? This is why we empower our engineers by giving them the tools they need to avoid repetition. After all, it is not about repetitive background tasks when creating value for our users, but about building actual solutions – and, of course, getting them delivered.

Testing and delivering,
Your cloudscale.ch team

More and more companies are offering their customers up-to-date information on the status of their systems. However, there is a good reason not to publish this information directly (or at least not exclusively) on the company website, e.g. at example.com/status or status.example.com: Such information is required exactly in the event that central components – potentially including the company website – have failed.

At cloudscale.ch we pay particular attention to preventing potential failures through redundancy at all levels whenever possible. However, we also think through those scenarios in which something fails nevertheless and carefully examine how the effects thereof can be limited in the best ways possible. Especially in case of a malfunction we want to avoid that corresponding information is affected by that malfunction as well – no matter where the exact problem is located.

Hence, we operate our status page not only on separate hardware, but also in a different data center than our cloud infrastructure, including a separate internet uplink. With the same determination, we have chosen the domain name: We decided to go with the address https://www.cloudscale-status.net and corresponding DNS servers so we can continue to inform you even in the event of a failure of the ".ch" name servers.

Which tools and technologies we use

For the operation of our status page we rely on Cachet. This tool is easy to use and adapt and has already proven itself with some of our partners. Nginx is used as the web server and a certificate from "Let's Encrypt" for TLS-protected data transmission.

In addition to displaying the latest maintenance announcements and status information via browser, Cachet also supports querying the corresponding information via RSS and Atom feeds. If you prefer to be informed about new announcements and updates by email, you can subscribe directly on the status page. Of course, these emails are sent independently of our cloud infrastructure, too.

How we use the different channels of communication

Information about the current status of our systems and planned maintenance work can now be found 24/7 on our new status page at https://www.cloudscale-status.net. Of course, we have also placed a link to the status page on our website. However, we recommend that you add the status page directly to your bookmarks so that you still have access to the latest status information even in case of unexpected problems.

Should maintenance work require any action on your part (e.g. the restart of a server), we will continue to send you the respective information directly to the email address of your user account. Please make sure that this address is up-to-date and inform us of any changes.

All systems operational!
Your cloudscale.ch team

Detailed information regarding Meltdown (CVE-2017-5754)

Fixes for the Meltdown vulnerability were available shortly after disclosure. We have applied the Linux kernel update that fixes the Meltdown vulnerability on all of our compute nodes on 2018-01-10. To protect yourself against attacks from inside your cloud servers you need to apply the corresponding security updates provided by your Linux distribution as well.

Detailed information regarding Spectre (CVE-2017-5715, CVE-2017-5753)

The Spectre vulnerability comes in two variants:

Spectre variant 1 can be fully mitigated with updated software. However, all vulnerable parts of the code needed to be identified first.

Fixing Spectre variant 2 is more complicated. The fix that has been proposed initially involved a CPU microcode update. As this update caused system stability issues it was later withdrawn by Intel. Thanks to extensive testing in our lab the flawed microcode update was never applied to our compute nodes in production.

An alternative approach to fix Spectre variant 2 was then developed by Google engineers and the Linux kernel community. This approach uses a technique called retpoline (return trampoline) which offers two main advantages: It does not need a CPU microcode update and the performance penalty is much smaller.

On 2018-02-26 we installed the Linux kernel update which contains the retpoline fix. With this update all known variants of the Spectre vulnerability have been fixed on all of our compute nodes. We expect additional updates to be necessary if further vulnerable parts of the Linux kernel will be identified and will install those updates as they become available.

Security advice for our customers

Please note that you need to apply the relevant security updates on your cloud servers as well in order to fix the Meltdown and Spectre vulnerabilities. Otherwise your cloud servers will remain vulnerable to attacks from within your server. We suggest using the script published by Stéphane Lesimple to check whether your servers are still vulnerable or not.

We will continue to track the availability of CPU microcode updates but no longer consider this a priority as – for most Linux distributions – alternative approaches are available to fix the Spectre variant 2 vulnerability.

We advise all of our customers to install the retpoline enabled Linux kernels provided by their distribution whenever possible. We will inform you if further actions will be required.

Please do not hesitate to contact us if you have any questions.

Best regards from Zurich - Switzerland,
your cloudscale.ch team

Measures taken so far

To ensure these vulnerabilities cannot be exploited at cloudscale.ch, we have already applied Linux kernel updates containing software mitigations for the most severe vulnerability (Meltdown). We will test further updates in our lab as they become available. Once we are confident that no regression occurs, we will apply them to our infrastructure. We will keep you up to date regarding our maintenance schedule and will do our best to minimize the operational impact.

Please note that you need to apply the relevant security updates to your cloud servers as well in order to fix the vulnerabilities.

Detailed information regarding Meltdown (CVE-2017-5754)

We have already applied the Linux kernel update that fixes the Meltdown vulnerability on all of our compute nodes on 2018-01-10. To protect yourself against attacks from inside your cloud servers you need to apply the corresponding security updates provided by your Linux distribution as well.

Detailed information regarding Spectre (CVE-2017-5715, CVE-2017-5753)

Mitigation of the Spectre vulnerability in the Linux kernel is ongoing. Currently, neither the upstream Linux kernel nor the Linux distribution we use on our compute nodes have released updates to fix it. Proposed code changes are under review by the Linux kernel community and we expect those to be released soon. A CPU microcode update and a kernel update will be needed in order to fix this vulnerability on our compute nodes. Furthermore, additional updates to the virtualization layer are required that will update the virtual CPU type of your cloud servers.

Once the relevant patches have been released, an additional Linux kernel upgrade as well as a shutdown and restart of all your cloud servers will be required. We will inform all of our customers as soon as the virtual CPU type has been updated. Only then will you be able to fix the Spectre vulnerability from inside your cloud servers.

If you have any further questions, please do not hesitate to contact us.

Best regards from Zurich - Switzerland,
your cloudscale.ch team

When it comes to high-performance routers for large networks, the names of industry giants such as Brocade, Cisco, or Juniper quickly come to mind. Routing and forwarding usually takes place in specifically designed hardware in combination with proprietary software of the respective manufacturer. However, as a cloud provider that has open-source embedded in its DNA, we wanted to expand the field of potential solutions.

The main requirement for our new border routers was to have 6-8 ports with a throughput of at least 10 Gbps – here we reached the limits of our existing solution, which was one of the main reasons for a replacement. We also needed several 1 Gbps ports to connect the management infrastructure and other network components. Redundant power supplies and the possibility of out-of-band management were of course a prerequisite. With regard to the software, our catalogue of requirements contained the usual protocols: OSPF and BGP.

Thanks to the preceding evaluation of a new leaf-spine setup, we became aware of Free Range Routing (FRRouting): This open-source project is backed by several vendors (including Cumulus Networks) with the goal of developing a stable and scalable routing daemon. Since spring 2017, FRRouting has been under the umbrella of the Linux Foundation.

Thus, with the right hardware, FRRouting could be a promising candidate for our border routers as well. We considered hardware from Intel (our partner for compute and storage nodes) and from Lanner, whose x86-based appliances stand out with their high density of modular network ports.

PoC and migration in two steps

After a proof of concept with FRRouting (first virtualized with Linux KVM and then bare-metal on Lanner hardware) we were convinced: This setup not only covers our performance and reliability needs, but also integrates perfectly into our general architecture, thanks to running on Ubuntu. Ubuntu, the operating system of our choice for the infrastructure at cloudscale.ch, is also FRRouting's reference test platform for Linux.

An important advantage of the new setup is that we can virtualize our entire network topology, including the new border routers, in our lab. This helped us with the planning of the upcoming migration, because that way we were able to test all installation processes and the developed configuration as often as we wanted without disturbing productive operation.

In a second step, we replaced the existing routers with the new devices during a maintenance window and thereby successfully completed the migration.

Advantages and possibilities of the new architecture

Thanks to solid performance, the possibility of expansion by adding interface modules and the active development of FRRouting by its broad community, our new routers are ready for the future. They also fit seamlessly into the aforementioned leaf-spine setup from Cumulus Networks, which we will put into operation in summer 2018. Using an identical software basis not only guarantees best compatibility, but also efficiency in maintenance. Finally, in addition to the completely redundant setup, the attractive price of the new hardware also allowed us to purchase a fully equipped spare device.

With the successful migration, we have also established the basis for integrating our border routers into our configuration management even better – in the future, we will make all changes to the network configuration via this central tool. Once all network components are running on FRRouting, we will be ready for the next milestone: the conversion of our network to BGP unnumbered to reduce its complexity and the consumption of IPv4 addresses.

Open and optimally connected.
Your cloudscale.ch team

PS: On November 9, 2017, our CEO Manuel Schweizer gave a presentation about FRRouting and BGP unnumbered at the SwiNOG-Meeting in Berne.

Terraform is a prominent representative of the term "Infrastructure as Code" and fits perfectly into the DevOps philosophy of today's projects. Where servers were previously commissioned manually, rarely configured identically and often not documented at all, this reverse approach now ensures efficiency and order: a configuration file that is easy to read for both humans and computers describes the required infrastructure – and Terraform does the rest.

Terraform works declaratively: You describe the desired state of your setup and Terraform derives the necessary actions from it. As soon as you apply the configuration you have defined, Terraform will make the respective adjustments via our API until the described state is reached. And because your infrastructure – just like code – changes over time, Terraform configurations are best managed in versioning systems such as Git.

Terraform is an open-source project. The software is available free of charge.

How to use cloudscale.ch with Terraform

If you are already using Terraform and would like to manage your servers at cloudscale.ch, simply include the plugin for the provider "cloudscale". It runs as a separate process and communicates with the main Terraform process via an RPC interface. In addition, you need an API token with read/write access, which you need to create once in our Cloud Control Panel. Using this token, Terraform authenticates itself to our API on every change to your infrastructure.

Starting a server with Terraform is very easy, as the following section shows:

# Create a new Server
resource "cloudscale_server" "web-worker01" {
  name           = "web-worker01"
  flavor_slug    = "flex-4"
  image_slug     = "debian-9"
  volume_size_gb = 50
  ssh_keys       = ["ssh-ed25519 XXXXXXXXXX...XXXX user@example.com"]
}

This is just a simple example for a single server; all available options for more complex setups can be found in our Terraform provider documentation.

Two tips from practice

Automating things saves a lot of time. But what if the automatism does not work as intended? Terraform comes in handy here: with the command terraform plan you can see in detail what changes Terraform would make on the way from the current to the desired configuration. If necessary, you can revise the settings as needed – until the "execution plan" exactly meets your expectations. Only then does a terraform apply actually make changes to your server infrastructure.

Possibly not everyone who has access to your code or configuration repository should also have access to your services at cloudscale.ch. We therefore recommend that you pass your API token as a variable within Terraform and exclude the corresponding source file from versioning. Alternatively, set a shell environment variable called "CLOUDSCALE_TOKEN", which is automatically used by Terraform.

At cloudscale.ch you have always been able to adjust your infrastructure as desired. Terraform now enables you to define your desired configuration and it will make the necessary adjustments for you.

We have the infrastructure for your code!
Your cloudscale.ch team

PS: Terraform is a software written in Go and requires a corresponding Go SDK for each provider. Our Go SDK has been released under the MIT license and allows Go developers (regardless of Terraform) to send HTTPS requests natively from any Go application to our API.

What is OpenShift and why should I use it?

OpenShift itself is described as "the most secure and comprehensive enterprise grade container platform based on the industry standards Docker and Kubernetes". But there is much more to it! OpenShift is a complete Kubernetes cluster with many features that round off the product: Integrated build pipelines, Docker registry, application router (load balancer), top security based on SELinux and a RBAC system (role-based access control system), a web-based console for easy access to the platform, central logging system, metrics for each PoD, configuration management with Ansible, source-to-image builds and much more.

A comparison can be made with the Linux kernel: OpenShift is to Kubernetes what a Linux distribution is to the kernel. Thus, OpenShift is a Kubernetes distribution – one of the first of its kind.

OpenShift comes in two different flavors:

• OpenShift Container Platform: The commercial version from Red Hat for installation in your own data center or in the cloud.
• OpenShift Origin: The open-source upstream project of the commercial version with a very active GitHub repository: https://github.com/openshift/origin

With OpenShift, software developers get the possibility to develop and test in shorter iterations. Each commit in Git can automatically trigger the entire process from development to production. For that purpose, OpenShift offers automatic image builds, memory management, deployment, scaling, monitoring, logging and much more. With this system the so-called "time-to-market" can be shortened significantly – that way, hourly or even more frequent deployments are a breeze.

How do I start with OpenShift?

There are many ways to start with OpenShift. A few hints and examples to get you started:

• With the official Ansible playbooks an OpenShift cluster can be installed and configured, e.g. at cloudscale.ch. With these playbooks all aspects, even the smallest details, can be configured. Furthermore, the playbooks help to maintain and update the cluster. These playbooks are documented both directly in the Git repository as well as on the documentation page.

• A local OpenShift cluster can be started with Minishift (based on Minikube) or with the simple command "oc cluster up" on your own workstation. Simply download the OpenShift client "oc" from GitHub, unpack it and make it executable. This will launch a complete OpenShift cluster on the local Docker daemon:
  

  
  

  % oc cluster up
  Starting OpenShift using openshift/origin:v3.6.0 ...
  Pulling image openshift/origin:v3.6.0
  Pulled 1/4 layers, 28% complete
  Pulled 2/4 layers, 83% complete
  Pulled 3/4 layers, 88% complete
  Pulled 4/4 layers, 100% complete
  Extracting
  Image pull complete
  OpenShift server started.
  
  The server is accessible via web console at:
      https://127.0.0.1:8443
  
  You are logged in as:
      User:     developer
      Password: <any value>
  
  To login as administrator:
      oc login -u system:admin
  
  % oc new-app https://github.com/appuio/example-php-sti-helloworld.git
  [...]
  % oc expose svc example-php-sti-helloworld
  [...]
  % curl -s
  http://example-php-sti-helloworld-myproject.127.0.0.1.nip.io/ | grep title
      <title>APPUiO PHP Demo</title>
  

• The APPUiO techlab on GitHub provides a step-by-step guide that explains how to run applications on OpenShift. If you prefer to receive in-person instructions, APPUiO offers you a free half-day hands-on workshop (see https://appuio.ch/techlabs.html for further information and registration).

• A comprehensive documentation on microservices architecture sheds some light on the development and operation of cloud-native applications which run perfectly on OpenShift: APPUiO Microservices Example

The available documentation for OpenShift is already very comprehensive and is being extended constantly. It can be found at https://docs.openshift.com for the OpenShift Container Platform and at https://docs.openshift.org for OpenShift Origin. APPUiO offers its own specific documentation at http://docs.appuio.ch/, which is maintained by the APPUiO team and the community at GitHub.

Why should I run OpenShift on cloudscale.ch?

After the first attempts with OpenShift on our own hardware more than two years ago, we started looking for a Swiss infrastructure partner to host the APPUiO public platform. With cloudscale.ch we have found the perfect partner. Together with the engineers at cloudscale.ch a tailor-made environment was created to meet the requirements of OpenShift.

Some important features that cloudscale.ch offers (among others) are: a private network between virtual servers for the cluster communication, an S3-compatible object storage e.g. for the Docker registry data, Floating IPs for high availability, additional SSD disks for a suitable node partitioning, native IPv6, and much more.

Today, cloudscale.ch is an important pillar for the stable operation of the APPUiO public platform.

About APPUiO

APPUiO ‐ the Swiss Container Platform – is a managed OpenShift service offered by Puzzle and VSHN. We run OpenShift on any cloud according to customer requirements – particularly on cloudscale.ch.

Having over two years of experience with OpenShift v3, we are the leading provider in Switzerland with a comprehensive knowledge of the operation of OpenShift. We not only operate dozens of private OpenShift clusters but also a public shared plattform. We have been operating the public platform on the infrastructure of cloudscale.ch since the beginning and have found a reliable partner in them who has always met our specific implementation requirements.

The operation of a complex platform such as OpenShift is not easy – there are many components in a large overall system. For this reason we have developed over 120 cluster checks and over 50 checks per server, which ensure the correct operation of the platform. This includes checks that perform a complete end-to-end test (from building the source code to testing the application over HTTPS) to ensure the functionality of a cluster. Many of our tools and scripts can be found on GitHub under the APPUiO organization. For questions you can reach us in the APPUiO forum or in the APPUiO community chat.

In order to try OpenShift for free today, please contact cloudscale.ch or APPUiO.

To use our Object Storage, you need a corresponding user account, which you can create in our Cloud Control Panel with just a few clicks. Transfer the displayed "Access Key" and "Secret Key" together with the hostname objects.cloudscale.ch to an S3-compatible application of your choice, such as a file manager, a backup program or your CMS – that's it.

Via our S3-compatible API you can now create buckets (analogy: directories) and upload objects (analogy: files). Depending on the application, it is advisable to define different access rights: for backups and private data, you should use the "private" ACL; public objects, however, such as the images of your website, can be marked as "public" and then directly integrated and delivered using:

src="https://BUCKETNAME.objects.cloudscale.ch/OBJECTNAME"

Update: The URL has been changed in the meantime. Read more: S3-Compatible Object Storage: New URLs.

Which concepts will help you to structure your objects

Of course, you can set up multiple user accounts for the Object Storage in our Cloud Control Panel. This makes it easy to separate test from production data or different customer projects from each other, for example. All your Objects Users and their buckets are listed in our Cloud Control Panel, each with used space, traffic and requests.

Access control lists (ACLs) go even one step further: Using the S3-compatible API, you can make individual buckets and objects available to other Object Users, either with read-only or write access – allowing for even more complex setups. For example, you can use ACLs to make sure that some objects can only be accessed by scripts, while other objects can only be accessed by certain individuals.

What pricing scheme will be used

The Object Storage of cloudscale.ch will only be billed for effective usage and does not cause any fixed costs. The costs incurred will be charged to your account at midnight every day – so there are no surprises at the end of the month.

After the free introductory phase, the following three components will be included in the daily price calculation starting September 2017:

• Used space at CHF 0.003 per GB
  Space is measured hourly and averaged over the day.
• Outgoing traffic at CHF 0.02 per GB
  Corresponds to the price of additional traffic for our cloud servers.
• Requests at CHF 0.005 per 1'000 requests

Inbound traffic is free of charge.

Update: The price for used space has been lowered by 66% to CHF 0.001 per GB in the meantime.

Whether you are looking for a secure storage location for your off-site backups, want to store your data centrally or need highly available storage for your cluster-capable application: our Object Storage offers exactly that – at a fair price and operated in Swiss data centers exclusively.

For your small and large objects,
Your cloudscale.ch team

One of the advantages of IPv6 is that there are more than enough IPv6 addresses available for every conceivable application. So why not use a separate IPv6 address for each service, customer or project? With our new Floating Networks you can now assign your servers their own "/56" address range. The new IPv6 Floating Networks are free of charge for you – as are the individual IPv6 addresses already available.

Similar to Floating IPs, Floating Networks can be assigned to another server at any time as well. No matter whether you are planning maintenance work or have a hot standby system ready for all cases: With a mouse click or an API call, you can assign the entire address range to another server within seconds, which can then transparently take all requests.

Central stateful firewall without NAT

NAT (Network Address Translation), often used to hide many private IP addresses behind a public IP, has become widespread, especially due to the scarcity of IPv4 addresses – despite a number of disadvantages. IPv6 promises to return to "end-to-end connectivity": source and target systems can address each other directly and unambiguously.

This is precisely why a central firewall that filters incoming connections remains an important component of most security architectures. With cloudscale.ch, such a setup can now be implemented easily:
Create a server with a "public" and a "private network interface" and, in a second step, assign a Floating Network to it – this server is your central firewall. The traffic filtered by the firewall will be forwarded to connected servers via the private network interface. Now you need to configure individual, unique IPv6 addresses from the Floating Network on all these private network interfaces. This allows your servers to be reached via these IPv6 addresses, while you can easily and centrally control traffic on your firewall.

The following diagram illustrates the setup:

                             +-------------+
                             |  Internet   |
                             +------+------+
                                    |
                             +------+------+
                             |  Server 1   |
                             |  "Firewall" |
                             +------+------+
                                    |
       +-----------------+----------+------+---------------------+
       |                 |                 |                     |
+------+------+   +------+------+   +------+------+       +------+------+
|  Server 2   |   |  Server 3   |   |  Server 4   |  ...  |  Server N   |
+-------------+   +-------------+   +-------------+       +-------------+

Migration of your IP space to cloudscale.ch

Many companies already use their own IP addresses, which have been assigned to them in the form of "Provider Independent Space" (PI Space) or in their role as "Local Internet Registry" (LIR). Thanks to Floating Networks it is now also possible to move such IP addresses (both IPv4 and IPv6) to cloudscale.ch. Keep your well-established IP addresses, but spare the effort of having your own physical infrastructure and take advantage of the flexibility of our Swiss cloud instead. Contact us to learn more about the possibilities of such a setup.

Leverage the full potential of IPv6 with our new Floating Networks today and benefit from the same flexibility that we have already introduced with Floating IPs. With our new Floating Networks, you can adapt the network to your individual requirements – or even use your own existing IP addresses.

Ready for your next hop,
your cloudscale.ch team

At cloudscale.ch, high-availability already plays a central role in the design phase of new features and this is no different with our Object Storage. Thus, requests to the Object Storage are distributed to two load balancers using "DNS round robin". These, in turn, can take over each other's IP and with it the entire load in case of a failure or maintenance work. It goes without saying that this does not only apply to IPv4: An ever increasing number of systems worldwide use IPv6 and can thereby access our Object Storage natively.

Behind the two load balancers, redundantly designed RADOS gateways store the data on a Ceph storage cluster. Similar to our SSD-only and bulk storage, we use a replication factor of 3 to ensure maximum protection of your data on our Object Storage.

Maximum speed for typical applications

In addition to high-availability, we also optimized the performance of our Object Storage. This includes the so-called cache tier: frequently used objects are automatically held in a special cache and can thus be accessed at lightning speed. This benefits your customers if you deliver the static files on your website or images in a newsletter directly from our Object Storage.

We also choose our hardware carefully: For our Object Storage, we have chosen a combination of hard drives for optimal storage density and NVMe SSDs for maximum speed. In conjunction with a sophisticated setup of Ceph, we also achieved an additional increase in speed even for rarely used objects.

Free introductory phase

On the occasion of the official launch of our Object Storage, we would like to give all users the opportunity to test this new feature free of charge until the end of August 2017. Evaluate different tools and discover new use cases to find out how you can optimize your application with our Object Storage.

From September 2017 onwards, a moderate pricing for the Object Storage will be introduced, which will take the actual space usage, data traffic and the number of requests into account. We will, of course, inform you in good time about the exact billing mode.

Most certainly, you are already using applications that can benefit from an Object Storage. Take advantage of the free introductory phase and test the opportunities that are opening up to you!

For objects by the bucket,
your cloudscale.ch team

Ansible is a platform for the orchestration and configuration management of applications, servers (especially Unix/Linux) and entire server farms. In addition to numerous other modules, Ansible allows you to interact with different cloud providers with its Cloud Modules – starting with version 2.3.0 it supports managing your servers at cloudscale.ch as well.

Creating a new server is like a walk in the park:

- name: Start cloudscale.ch server
  cloudscale_server:
    name: my-shiny-cloudscale-server
    flavor: flex-4
    image: debian-8
    ssh_keys: ssh-rsa XXXXXXXXXX...XXXX ansible@cloudscale.ch

Apache Libcloud

Apache Libcloud is a Python library which abstracts the APIs of different IaaS providers. Libcloud enables you to access the resources of various cloud providers via a uniform Python syntax. Starting with version 1.5.0 Libcloud also includes a driver for the cloudscale.ch API to manage servers on our infrastructure directly from your source code.

Using Python and Libcloud you can create new servers with just a few lines of code:

from libcloud.compute.types import Provider
from libcloud.compute.providers import get_driver

cls = get_driver('cloudscale')
driver = cls(key='XXXXX')

name = 'my-shiny-cloudscale-server'
size = [ s for s in driver.list_sizes() if s.id == 'flex-4' ][0]
image = [ i for i in driver.list_images() if i.id == 'debian-8' ][0]
ssh_keys = [ open('id_rsa.pub').read().strip() ]

node = driver.create_node(name=name,
                          size=size,
                          image=image,
                          ex_create_attr={'ssh_keys':ssh_keys})

Two tools, different areas of application

Ansible and its so-called playbooks are used to define and execute a sequence of tasks for system management. Therefore, Ansible has cleary defined areas of application: orchestration of IT processes, deployment of applications, or configuration management.

With Ansible and the Cloud Module it is possible to automate the whole process of setting up and operating highly available web services at cloudscale.ch – from creating virtual servers and deploying applications up to non-disruptive maintenance during operating system or application updates.

In contrast, Libcloud is a Python library. With Python as a universal programming language a wide range of applications can be implemented. So, Libcloud comes in handy whenever Python code is used to access cloud services. All of the included cloud providers are supported automatically without the developer having to write code for their specific integration.

Therefore, Libcloud is suitable wherever you use Python already – e.g. when directly integrated into your (web) application for more scalability, or in order to extend existing deployment and monitoring tools.

What the future holds

We are constantly working on new features for our cloud infrastructure and our API. In order to integrate these into Libcloud and Ansible, we are working with the respective open-source communities. For example, an integration into Ansible is planned for the recently introduced "Floating IP" feature.

A common advantage of cloud servers is that they can be deployed with just a few clicks. You can go one step further now: automate your server deployment with Ansible or Libcloud – no need to click at all.

Server setup made easy!
Your cloudscale.ch team

PS: We believe that an integration of the cloudscale.ch API into Terraform would be valuable as well. What's your take on this?

It will happen sooner or later: a process crashes, a limit is reached or there is maintenance work to be done. Therefore, many sysadmins are operating the same service on several servers and change DNS records when needed in order to move requests from one server to another. Even with a short TTL this causes additional overhead or even service interruptions – and it is another source of errors and subsequent problems.

You can move our new Floating IPs between your virtual servers at will; a new server can transparently take all requests giving you time to update, restart, scale or debug the previously active server.

The example of keepalived shows how easy it is to achieve high-availability: Two servers periodically check the state of their respective counterpart. When a problem occurs on the active server, the standby server automatically takes over by assigning itself the Floating IP using our API. Of course, you can also assign Floating IPs to a different server manually by using our cloud control panel.

Update: If you run your servers on Ubuntu 18.04 or 20.04, please also see the revised example of keepalived.

Ideally, you should combine Floating IPs with our Anti-Affinity feature to achieve the highest level of availability. This ensures that two servers, that can cover for each other, always run on separate physical machines. Even though we already have redundancy in place on many different levels, by doing so you can further reduce the risk of a hardware failure.

Which further benefits Floating IPs offer

Even if you do not plan to dynamically move IP addresses between servers, you can still benefit from the new Floating IPs: You now have the possibility to add additional IP addresses to your servers as needed. By adding up to five additional IPv4 and IPv6 addresses you can separate services or customers from each other without having to create or maintain separate servers.

Update: Meanwhile, the limit has been increased from five to a total of fifteen Floating IPs or Floating Networks per server.

Since Floating IPs are not hard-wired to a virtual server, they will be retained in your user account when you delete the server. This prevents your "Service IP" from being lost when replacing servers – given, of course, that your customers are communicating with this Floating IP exclusively.

What happens in the background

From a technical point of view, each Floating IP is representing a separate, small IP range – hence the netmask "/128", "/32" or "255.255.255.255" respectively. When you create a Floating IP or assign it to a new server, our routers receive corresponding instructions: Traffic directed to the Floating IP is to be sent immediately to that server. These instructions are being processed via a separate, redundant setup consisting of two ExaBGP speakers, which communicate with our routers via multiple BGP sessions.

At the SwiNOG meeting in Berne, André Keller from VSHN AG and our CEO Manuel Schweizer presented more detailed background information on this particular approach; the slides can be found at http://www.swinog.ch/meetings/swinog30/. As usual, we hid the technical details behind a self-explanatory user interface – our cloud control panel. To use Floating IPs via API you can find all the needed information in the API documentation at https://www.cloudscale.ch/en/api/v1.

Let it float!
Your cloudscale.ch team

Ceph forms the basis of our distributed storage cluster. The open source solution ensures that your data is stored in a multi-redundant way and by that always available. Distributing read and write operations across a large number of storage nodes increases speed significantly. The physical separation of compute and storage nodes enables high-availability setups and allows storage capacity to be scaled virtually infinitely.

In order to ensure smooth operation, we rely on Ceph's "LTS" releases ("Long Term Stable" releases). Using a widely supported version increases reliability and minimizes the response time in case of an issue. After comprehensive testing in our lab we have updated the storage cluster from "Hammer" to the latest LTS release "Jewel". Impressive fact: Compared to Hammer, a performance increase of up to 35% has been measured using Jewel.

Reinstallation of the storage nodes with Ubuntu 16.04 LTS

Most of our servers are running Ubuntu, and here too we rely on versions with long-term support. While the productive systems were running smoothly with version 14.04 LTS, we have thoroughly tested the newer Ubuntu 16.04 LTS as well as the replacement process in our lab. During the last few days we have reinstalled all of our storage nodes with 16.04 and thus will continue to benefit from current software and long-term support.

Enhancement through super fast NVMe SSDs

When using Ceph, all data is stored in the so-called journal first. In a second step, data gets transferred to its actual storage location. In many cases SSDs are used for the journal to speed up write operations while data is then stored on magnetic hard disks.

At cloudscale.ch however, we use SSDs exclusively (except for bulk storage) to also ensure read access at lightning speed. To further optimize our setup, we have enhanced our storage nodes through NVMe SSDs. These serve as a super fast journal and speed up write access even more compared to the current SSDs. This new configuration also eliminates the "double-write penalty": Thanks to the separate NVMe journal data is written to the SSDs just once, which almost doubles data throughput.

After carefully planning every step, we were able to implement all these improvements in operation – probably without you even noticing. Of course, all customers automatically profit from the increased performance so there is no need to modify or replace your current servers.

At lightning speed,
your cloudscale.ch team

Object storage (or object-based storage) is a modern approach to storing and retrieving data, which is being used more and more often by current applications. A typical use case is storing backups: Backups can, for instance, be created (and optionally encrypted) with Duplicity and then stored outside the respective systems. This way they remain available independent of the primary system.

Since the object storage is being accessed using HTTP/HTTPS calls, this leads to another use case almost automatically: Files flagged as "public" (e.g. images or videos) can be accessed directly via a static URL, and can therefore be incorporated into websites or HTML newsletters without burdening the web server.

If you are already using Docker on your servers, your deployment will become even easier: Entire Docker images can be stored directly on our new object storage using the Docker registry.

Supported tools

Objects stored in the object storage are often files, grouped in "buckets". These in turn can be seen as a simplified version of folders. Hence, usage in the shell or scripts is pretty straightforward: The open source tool s3cmd for example follows familiar concepts to manage objects, similar to SCP or FTP.

Besides the aforementioned Duplicity, an increasing number of modern applications can make use of object storage directly, such as Apache Hadoop or various content management systems such as Drupal and Wordpress.

Participating in closed beta

Before making this new feature accessible to everyone, we would like to invite a limited number of users to test our object storage extensively. Feedback will of course be considered as part of the further development.

Would you like to be among the first to test our object storage? We are looking forward to learning about your experience and are happy to provide you with beta access – a short email will do.

Ready to listen!
Your cloudscale.ch team

We have previously described our approach regarding OpenStack upgrades: We are running a separate test environment using the same hardware components as in our productive setup. There we are able to test every change until we are convinced that it can be rolled out safely into production.

A few weeks ago, another OpenStack upgrade was scheduled: "Mitaka" was going to replace "Liberty". A delicate matter, if one bears in mind that OpenStack is at the very heart of our cloud infrastructure. Thanks to comprehensive tests in advance, we were able to upgrade all of the systems smoothly and without affecting our customers' virtual servers. Only changes through our cloud control panel were not possible for a short period of time – the corresponding announcement to our customers was, of course, already part of the preparatory work.

Faster Live Migration

In addition to major upgrades, regular systems maintenance and improvements are part of our day-to-day routine. Usually, our customers do not notice a thing: we can move all virtual servers to other compute hosts on the fly thus avoiding disruptions to customer systems. We were even able to speed up this process by a factor of 5 by switching from "libvirt tunnelled migration" to "QEMU direct migration" recently. Now maintenance tasks such as kernel upgrades that require a restart of all compute hosts can be completed even faster.

OpenStack Summit in Barcelona

For us as an active member of the OpenStack community, the OpenStack Summit in Barcelona in late October 2016 was more than just a mandatory appearance. In an inspiring environment consisting of thousands of developers and users from around the world, everything revolved around OpenStack and its comprehensive ecosystem. A wide range of presentations provided insights into all possible aspects, including how to manage huge setups, maintaining OpenStack's own open-source code, and a look ahead at future improvements to Ceph. Since 2014, Ceph has been the backbone of our distributed storage cluster and is now being used more and more frequently with OpenStack.

Equally valuable, of course, was the personal exchange with new and familiar faces, whether in numerous sessions with core developers or spontaneous discussions outside the official agenda. And, as far as statistics go, our regular upgrades to new versions of OpenStack make us one of the most modern OpenStack cloud service providers in the world.

Our own past experience as well as the community with its combination of drive and professionalism continue to reinforce our opinion: OpenStack as the technological basis for our self-service cloud was clearly the right choice.

With this conviction we will therefore continue to contribute to further developing the OpenStack source code in the future and are already working on the next features for our own cloud.

First and foremost,
Your cloudscale.ch team

All it takes to use our new API is an API token: A secret string that you need to include in all your calls to our API.

You can create as many tokens as you need in your account settings of our cloud control panel. For reporting-only purposes, creating a "read access" token is a safe choice. If you intend to also make changes through the API (e.g. create or reboot a server), enable "write access" as well.

Make sure to choose a meaningful name so you can tell your tokens apart. This will help you to identify a token in case you need to revoke it later. Please note that we only keep a hashed copy of your tokens in our database. Therefore they cannot be displayed again later on.

How to use our API

Our API is an HTTPS API following the REST paradigm, and therefore compatible with virtually everything you might be working with. As a basic example, you can display a list of your current servers right from your local command line by using:

curl -H 'Authorization: Bearer IhrCloudscaleApiToken' https://api.cloudscale.ch/v1/servers

Any required parameters can be supplied in either JSON- or URL-encoded form. The API returns information in JSON format for easy parsing and further processing. All available functions are documented at https://www.cloudscale.ch/en/api, complete with the correct HTTP method, parameters as well as an example.

Some use cases and hints

The potential use cases enabled by our API are endless: If your coworkers need to set up predefined infrastructures repeatedly, you can now provide them with a script that makes use of our API and the cloud-config feature. Or you might want to automate information retrieval – for your project members, for documentation or a real-time dashboard.

Be aware that all API calls are executed without further confirmation so you can reliably use them in an automated fashion. Since your API tokens can be compared to a password, be careful about where you store them (e.g. public repositories) and who can access them (e.g. script location or bash history), and revoke them quickly if necessary.

When deleting a server, you will now get a pro rata refund for the remainder of our 24-hour billing period. Feel free to test different setups and features, and replace older servers with a fresh installation at no extra cost. If you are using additional, short-lived servers to cover periodical load peaks, this change will obviously benefit you too.

While we keep working on our easy-to-use cloud control panel for humans, we are happy to announce that cloudscale.ch is now equally easy to use for computers.

Happy automating!
Your cloudscale.ch team

PS: As an announcement to our fellow Python users: We are working on being included in an upcoming Libcloud release to further facilitate using our API. Stay tuned!

With the most popular virtualization technologies, a crashing physical compute host inevitably takes down all the servers that were running on it. As a remedy, you may already have "N+1 redundancy" in place by clustering multiple virtual servers (e.g. multiple web workers or a DB cluster) to increase your solution's availability. It is possible, however, that some of those servers are running on the same physical host by coincidence.

With our new Anti-Affinity feature, you can ensure that servers with identical tasks will always be running on separate physical hosts. This effectively protects you against the impact of a single compute host's hardware defects.

What measures we take to maximize availability

Of course, a server failure still is annoying. That is why we at cloudscale.ch only use systems which are designed to always keep running and stay online:

All of our systems are equipped with redundant, hot-swappable power supplies. All physical servers are connected to multiple switches simultaneously and can be administered through a separate out-of-band management network.

In case of a defective compute host, all affected virtual servers are restarted promptly on separate, hot-standby compute hosts. Thanks to our distributed storage cluster based on Ceph, the content of the hard disk will be left intact. Moreover, with a replication factor of 3, your data is well protected against hardware defects – a risk category which we further reduce by using enterprise grade SSDs only.

On the level of supplies we have built-in redundancies, too, aiming for the highest availability: For one thing, we can rely on the data center's redundant cooling as well as two power sources, both of them backed by UPS systems and diesel generators. For another, we maintain multiple Internet connections with different upstream providers and a link to the SwissIX Internet Exchange.
Finally, we run our own critical software (e.g. OpenStack components) following the N+1 principle to operate seamlessly through a possible outage.

Why HA is more than just a reliable server

To us, availability means that your servers are running and reachable. Think about what availability means to you – or your users, for that matter. What could go wrong, and how can you prevent or minimize a negative impact? Choose the approach and tools which suit you and your use case best. In the end it is all about being prepared.

For servers that work!
Your cloudscale.ch team

PS: Matching the topic, André Keller of VSHN AG and our CEO Manuel Schweizer will give a presentation addressing "How to increase availability using ExaBGP". For registration and more information on this event taking place in Berne on November 4, 2016, see http://www.swinog.ch/meetings/swinog30/

Do you use complex passwords? Are you sure that nobody watches you typing? Two-factor authentication (2FA) takes security one step further: Logging in requires an additional token (also known as one-time password or OTP) which changes every 30 seconds and is valid for a short time only.

Safeguard your cloudscale.ch account with 2FA now by enabling this new feature in the security settings. Using the popular "Google Authenticator" or any other TOTP app, you can turn your smartphone into an additional key protecting your cloud. By the way: Generating your tokens happens completely offline.

Session Management

If you close your browser while logged into our cloud control panel, normally your session cookie will automatically be deleted. Next time, you will need to log in again. Now you can choose to "stay signed in" upon login. Of course you can stay logged in with multiple devices simultaneously.

But what if you forgot to log out after using someone else's computer? Just navigate to the new session overview to see all devices currently logged in, complete with IP address and browser. Here you can end any session immediately to make sure nobody tampers with your account.

Host Key Verification

SSH host keys are sort of a server's passport: they guarantee that you are connecting to the right machine and that there is no man-in-the-middle manipulating your traffic. If a server presents a different host key than the one in your known_hosts file, you will immediately get a warning and will probably want to investigate further.

Many people inevitably trust host keys on first use. Now you can actually verify the keys of your newly created servers: Virtual servers generate their unique host keys on first boot and write the public parts to their serial console. There we pick them up and display their fingerprints in our cloud control panel. Go check for yourself!

Trust is good, control is better. Keeping control just got easier with our latest security features. After all, cloud computing is to us what online banking is to others.

Signed, not hashed.
Your cloudscale.ch team

When to best use bulk storage

It does not have to be "big data": Bulk storage is perfect for keeping archived versions of your work or an off-site backup of your local hard disk. Run the free "Seafile" or "ownCloud" software to keep folders synchronized across your devices – the new bulk storage is the cost-efficient place to keep your files in the cloud.

You can also benefit from adding bulk storage in a traditional server setting: Use it to store your website's static assets like images and videos, for your database dumps and ever-growing log files. And it is the easiest way to keep certain files separated from your root file system.

How to use it in practice

Using our cloud control panel you can add bulk storage to your virtual servers at any time. When launching a new server, the additional volume will automatically be ext4 formatted and mounted to /mnt/bulk so you can use the extra space right away.

You can also add bulk storage in the "storage" tab of your existing servers. We provide instructions on how to partition and mount it manually for all of our supported operating systems. And similar to the SSD-only storage, you can always scale up your bulk storage volume in case you need more space.

The technology under the hood

While we use spinning disks to keep costs for bulk storage low, we put in quite some effort to offer the best place for your big chunks of data. To ensure high availability, we use Ceph with a replication factor of 3 which is identical to the configuration of our SSD-only storage cluster. For optimal performance, bulk storage is kept on dedicated storage servers separated from the existing systems. In addition we were able to speed up write operations dramatically by using SSDs for the Ceph journals.

Needless to say that all of your data on our bulk storage cluster is kept exclusively in Swiss data centers – this holds true for all of our systems.

Some of the most valuable data does not require cutting-edge IOPS. Use our new bulk storage feature to cost-efficiently store those files in a safe place, ready whenever you need them.

Move your attic to the cloud!
Your cloudscale.ch team

If setting up new cloud servers is a repetitive task, why not automate it? All of the operating systems that we currently offer have the cloud-init package built-in. By providing so-called "User Data" you can now pass your own settings to cloud-init: your tailor-made cloud-config. The possibilities are endless – we know of people who do not even need to manually SSH into their new servers anymore.

You can give it a try by using the "timezone" or "fqdn" (Fully Qualified Domain Name) parameter to configure your new server right from the launch screen. For more complex operations, the "runcmd" statement will take your commands and run them on first boot. This is an advanced feature: check out the examples and proceed with caution.

Rename your servers to accurately reflect their purpose

While you are optimizing your setup, the number of machines or even the software you are running might change: Once you realize that your DB replica is mainly used to generate reports, you will probably rename the machine with Linux's on-board tools. For a consistent experience you can now adjust server names in our cloud control panel as well.

If you are working on multiple projects or for several different customers, using descriptive server names can support you in keeping track of your assets. Moreover, it will help you to avoid confusion further down the road.

Change PTR records for a coherent appearance

You can now use our cloud control panel to set and update the PTR records of your servers' IP addresses. If you specify the FQDN of your server using cloud-config (as described above), we will automatically set the PTR records of your IPs accordingly. Of course, you can change those entries at any time, should you ever need to. Keep in mind that caching DNS servers might reflect changes with some delay.

For some applications, especially email, it is vital to have matching "forward" and "reverse" DNS entries ("Forward-confirmed reverse DNS"): When setting a new PTR record for a specific IP address, make sure to have an according A/AAAA record pointing back to the same IP. Furthermore, your services should identify themselves using that same string.

Who says that small improvements can not have a huge impact? With the latest additions, you can manage your cloud with a smile on your face.

Keep on optimizing!
Your cloudscale.ch team

A well-known use case for private networks are "tiered architectures": Create a number of frontend servers (e.g. web workers) that directly serve your users over the Internet. Those servers then use a second, private network interface to connect to their backend servers (e.g. DB or business logic) which are not publicly accessible. This design minimizes the number of exposed services, increasing the overall security of your setup.

Thinking beyond common web services, you can now use our cloud for virtually any application that you previously operated on-premises. Be it email, file storage, your wiki, or your virtual PBX: Just use our "private network" feature. With a VM acting as a gateway, central firewall, and/or VPN endpoint, you are in full control over who has access to your (private) machines.

How to set up private networking

Private networking at cloudscale.ch works out of the box: Each server on your private network receives an IP address by DHCP; this address is also displayed in our cloud control panel. You may, of course, statically configure any IPv4 and/or IPv6 address you like – it is your network, after all.

In case of an already running server that has no private network interface yet, you can add one any time later. Config snippets will help you setting up the additional interface in the operating system you chose.

A peek behind the scenes

We allocate a separate VXLAN to each user, tunneling your private network's traffic between our compute nodes and thereby keeping it completely separated from other customers'. Using this setup, we also make sure that packets inside your private network never leave our backbone.

We assign a random /24 subnet out of the private 172.16.0.0/12 address block to each user. By doing so, we try to avoid confusion with private addresses that you might be using elsewhere. In case you prefer the DHCP servers to pick addresses from a different subnet, just let our support team know.

Our self-service cloud platform now offers a solid foundation for an even broader range of applications, thanks to the added support of tiered architectures. Use a private network to protect your valuable data, and only expose the services you actually want to be publicly accessible.

Happy (private) networking!
Your cloudscale.ch team

Why you should use IPv6 now

An increasing number of Internet users and devices are already using IPv6, some of them even without having a "legacy" IPv4 address. Once you enable IPv6 on a server, they can access your services more efficiently: fewer DNS requests, no more NAT, and no bottlenecks imposed by tunneling services which were required to connect both worlds. Did you know that various content providers report application performance improvements of up to 25% when using IPv6?

Let's face it: IPv6 is state of the art.

How to enable IPv6 on your virtual servers

IPv6 can be enabled for both existing and new virtual machines: When creating a new VM, simply check "Enable IPv6" and do not forget to add according AAAA records to your DNS zones – that's it! For existing VMs, click on the "Enable IPv6" button in the "Network" tab of our cloud control panel. You will also find instructions on how to get DHCPv6 up and running for your virtual server's operating system there.

By default, we assign a single IPv6 address per VM. Need more? Our support is happy to route up to a /48 to your VM's IPv6 address on request.

A quick note on security

You will possibly want to add according firewall rules when enabling IPv6 on your servers. Please remember to allow DHCPv6 traffic when sticking with our default way of assigning IPv6 addresses.

Switzerland is one of the world's leaders in IPv6 adoption. With cloudscale.ch, you can be, too.

Happy networking!
Your cloudscale.ch team

PS: Our CEO, Manuel Schweizer, gave a speech at the IPv6 Business Conference in Zurich last week. You can download the slides of all presentations at www.ipv6conference.ch/sessions/

Having access to security updates is vital – what is true for your own devices applies to cloud service providers even more. While OpenStack's Kilo release was reaching end of life, we considered upgrading to a newer release for yet another reason: new and improved capabilities in OpenStack Liberty allow us to provide you with new features faster than before.

We are aware that the even newer OpenStack "Mitaka" has been released recently, so why did we choose Liberty anyway? We are really serious about providing you with a stable cloud infrastructure. Therefore we wanted to gain more experience with Mitaka in our lab before entrusting it with the orchestration of your servers.

How we prepared for the upgrade

Knowing how to proceed in theory is one thing, having tested the procedure is another. That is why we built a lab environment using hardware components identical to our live cloud infrastructure. This allowed us to replicate the then-current setup and go through the whole upgrade process several times, sorting out potential problems and eliminating pitfalls.

In preparation for upcoming features in our cloud control panel, we have also taken this opportunity to adjust and extend our OpenStack settings. We will cover those features in separate posts.

What this means for the future

OpenStack Liberty is a big step forward. It provides continuity and reliability, given the fact that it is well-proven yet supported for quite some time. But more important, it is a cornerstone for the future evolution of our cloud infrastructure, allowing for numerous advanced features which we will release over the next weeks and months.

With a dedicated and independent lab environment, we can now test things in a more efficient way. Be it a new feature, an optimized configuration or the next major upgrade, we have the means to safely do as many dry runs as we want before actually touching a productive system.

After this upgrade, we have an even better technological base to build on. And on top, we gained another powerful tool to meet the quality standards we are committed to.

On your mark, test, go!
Your cloudscale.ch team

Creating a new product is all about priorities. In our case: Harness the available technology and turn it into a self-service cloud offering which is powerful yet easy to use. With a small team and a clear vision of the end result, we focused on delivering what we had promised as quickly as possible.

While our main building blocks, OpenStack and Ceph, were determined quickly, we had to follow a pragmatic approach when it came to implementing our unique cloud control panel. Using the existing knowledge we had on the team was key and therefore the release in January ended up being written in Lua.

Why we decided it was time for a change

Having reached GA, one of the most important milestones in the history of a start-up, it was now time for a re-evaluation. It quickly became clear to us that there was no better way to take full advantage of OpenStack and its evolving ecosystem than to switch to Python ourselves.

With more and more software developers working on our control panel, we decided to establish new processes: Test-driven development helps us move fast while ensuring high quality. Continuous delivery with multiple deployments per day allows you to take advantage of improvements and new features on a regular basis. Using Python and its surrounding frameworks we were able to leverage the power of agile software development.

What benefits you can expect

Following our improved processes, we managed to replace our entire code base without our users even noticing – a seamless rollout. Using newly gained synergies, we are making headway with new features even faster. In about a month's time we will provide full IPv6 support for your virtual machines. And private networks are just a little further down the road, with even more cool stuff in the pipeline to be released this summer.

In retrospect, re-implementing our code base was the right thing to do at this stage. After releasing an initial product and getting positive feedback from our customers, we are now ready to bring it to the next level.

Get ready for (much) more!
Your cloudscale.ch team

With our recently released self-service platform and a growing user base, everything started to look urgent: supporting our customers, adding new features, maintaining and extending our technical infrastructure – and lots of background tasks that you would probably find hard to believe.

It seemed sensible to look mainly for system engineers with programming skills, hoping that they are capable to fill in wherever the most pressing issues would surface. Knowledge in Python was a hard requirement (since we are using OpenStack), along with an open mind as our cloud control panel is currently written in Lua.

How we managed to find the right people

Given the situation we found ourselves in, we just did not have the time and resources to run job ads and sift through hundreds of applications. A job posting in HN's "Who is hiring?" yielded some interesting contacts, but ultimately did not lead to successful hires, either.

It was a well-tried, classical method which lead us to meeting our new team members: know someone who knows someone. We were lucky enough to find two software engineers with a track-record in Python and outstanding Linux skills. Moreover, both make substantial contributions in their field of expertise, and are deeply involved with the open-source community.

Why reaching out paid off for us

Unrelated to growing our staff, we chose to reach out to other OpenStack users (after all, we are the new guys on the block). It turned out one of these specialists was very interested in joining our team, and with his skill set in OpenStack and Linux system engineering he was a perfect addition to the growing cloudscale.ch team.

We would like to welcome the new faces behind cloudscale.ch! And on our current way of growth, we are looking forward to meeting more great people like them.

Cordially,
your (growing) cloudscale.ch team

We have opened free and instant registration to everyone. Having spent more than a year of hard work (with even more to come) creating a simple self-service cloud platform, we are proud to say: Here it is! Welcome to https://www.cloudscale.ch

How we prepared for GA

We recently added some more hardware to our cloud setup to ensure you will always get the capacity and power you need. We implemented internal improvements so we can handle a growing user base, both technologically and as an organization. And we are growing our team to keep up the pace.

What has changed for you

We have adjusted our plans to fit your project size and budget even better by lowering our prices and replacing the previous "Flex-1" offering with the bigger "Flex-2" flavor instead. Simply scale up any existing Flex-1 servers to Flex-2 at no additional cost.

Why this is only the beginning

We are excited to welcome lots of new fans from around the globe and are curious to hear what you have achieved using our services – we love feedback!
Having a fully working cloud infrastructure in place is just a starting point. We are already working on upcoming features like backups and snapshots as well as IPv6 support.

Chances are that your friends want to try us too! Or have they ever launched a server in 10 seconds before? If you pass them our link, they can now sign up immediately and profit from some free credits as well in order to test-drive their first server at cloudscale.ch. Thanks for your support!

Best regards from Zurich – Switzerland,
your cloudscale.ch team