News

Performance: use caches

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.