fbpx
vshosting~

Whether we like it or not, we live in the cloud era. We have gotten used to easily and almost immediately adding more output and subsequently subtracting it when the demand goes down.

At first glance, everything looks great – we only pay for the capacity we really need and only when we really need it. We don’t need to worry about a spare parts storage space or get up at 3 am to deal with a broken server. However, this “ideal world” also has its drawbacks that might not be obvious at first.

By transferring applications to the cloud, we have given up the option to set up the entire environment according to our wishes, we now have to increase or decrease output via predefined “packages”, we give our data over to a third party thinking that “they won’t give a damn about a Czech mini project’s data”, and we introduce unnecessary vendor lock-in into the application via various SDK and API cloud services. We have sacrificed architectonical freedom and gotten comfort in exchange.

But what if there’s another way? What if we could take the advantages of the cloud and deploy them onto a solution that would be fully under our control? What if we could build our own, private cloud?

Proxmox – the Virtualisation Platform

The first step is always the hardest: as it was when we at vshosting~ were choosing the best platform on which we were going to build the private cloud solution. Several software options made it to our shortlist and in the end, we were choosing between two candidates: OpenNebula and Proxmox. Both of these tools allow for a wide spectrum of use cases. In the end, we have chosen Proxmox, among other things because of the ease of its administration.

Proxmox in and of itself is a distribution built on recent Debian with a few improvements. It includes out-of-the-box KVM virtualisation (full-fledged virtual machines) as well as LXC containerisation (Linux-only containers), high availability, clusterisation, virtual migration between nodes, scaling while the virtual machines are in operation and much more. All that is package in a user-friendly web interface, CLI or REST API. You can find the detailed function description on the Proxmox website.

Proxmox itself is very easily scalable from one node to up to 100 nodes in one cluster. Based on our practical experience, however, we have decided to limit the cluster size to 12 nodes. In any case, any unit bigger than that typically works best when divided into more smaller clusters which can have very high performance on their own.

Putting 12 machines together into one virtualisation cluster where each one of the machines contains 4 powerful Xeon processors with 12 physical cores (24 strings) together with 512 GB RAM provides sufficient output even for the most extensive projects that are running at vshosting~. Although, if you like, we are more than able to create even larger and crazier setups 🙂

Light Containers as well as “Full fat” Virtual Machines

As we’ve already mentioned, Proxmox offers two types of virtualisation – full virtualisation via KVM and containerisation with LXC. The advantage of KVM is full hardware emulation: as a result, it’s no problem to install on it not only Linux but also MS Windows, Mikrotik RouterOS or Android (if you have the necessary license). A disadvantage of KVM is the fact that it shares no parts of the system with the hypervisor. Virtual machines in KVM are then more demanding in terms of storage.

If you’d like to operate Linux applications, using LXC contanerisation is the suitable option. In this case, the kernel is shared with the hypervisor, therefore, the need to account for kernel storage space in the container becomes obsolete. A significant disadvantage of containers, however, is only partial insulation of the environment that not all applications are capable of dealing with. For example, we’ve been unable to properly run GlusterFS servers or NFS exports on LXC.

Both virtualisation technologies can be combined at will in a cluster.

You Provide the App, We Do the Rest

We offer our private cloud in the managed mode. Tha means we take care of everything below the level of virtual machines. Hardware, discs, network, connectivity, electricity, cooling, and even the hypervisor software itself – all of that is on us. Up to this point, there’s no difference between public clouds. Where the first point of significant difference manifests is high performance. Private Proxmox runs on physical machines dedicated only to a specific cluster.

As a result, the client has 100% of the capacity at his disposal. No sharing of resources, no aggregation. The client then divides the performance among single containers and virtual machines, he himself chooses the operation system, applications (and their configuration) that run on them.

Storage, Firewall, and Other Services

In the basic setup, the discs of virtual machines are stored directly on the discs inside the servers. This solution is very powerful but doesn’t allow for live migration of virtual machines between nodes or VM restart on a different node should the original one fail.

This can be solved by network storage, which we offer under the name Cloud Storage. In Proxmox, you’ll see it as basic storage accessible throughout the cluster. Virtual machines and containers that have their discs placed in this storage can be easily migrated between nodes or automatically start them on different machines in the event of failure.

Besides the disc storage, you can also use Cloud Storage as object storage compatible with S3 – but that is a topic for another article. As is the case with each of our managed services, you can add managed firewall Cisco ASA, DDoS Protect protection or up to 10Gbps global connectivity to your Private Cloud.


Damir Špoljarič

Throughout the last few months, the most typical request of vshosting~ clients has unanimously been horizontal scaling. Let’s take a look at what this requirement truly represents and where it comes from.

It’s important to mention right from the start that nowadays, horizontal scaling is often required mostly for business reasons. The technical side typically lags behind. In addition, in more than one instance, horizontal scaling is a requirement that shouldn’t be a priority for the application operator.

Horizontal vs. Vertical Scaling

Scaling can be either vertical or horizontal. Vertical scaling has been here with us for many years and, simply put, concerns increasing the output of a given server (be it physical or virtual) or container. It is the easiest way to provide more computing resources for that given app.

A disadvantage of this method is primarily its limitation (the server output cannot be increased infinitely). The answer to this drawback, at least theoretically, is horizontal scaling. That allows for parallel additions of independent computing capacities and distribution of load among these capacities – infinitely in an ideal case. From the point of view of scaling a business, this sounds amazing. However…

When it comes to extensive applications with the vision of rapid growth, horizontal scaling truly is the only option to ensure maximum scalability. Nonetheless, it is still more advantageous for many services to scale vertically rather than horizontally (e.g. load balancers, etc.). Unfortunately, many platforms (such as AWS) to this day force the user to choose from pre-defined packages of processor and storage capacity. At vshosting~, we consider this to be an anachronism.

Cloud platforms and hosting should be able to dynamically adjust to the real needs of concrete computing resources of each and every client. In other words, every time a client needs to increase their application output, they should have the option of simply adding x amount of storage and y number of processors without having to go through an elaborate investigation into which of the offered “packages” is most appropriate for them at that moment.

Horizontal Scaling Stumbling Blocks: Practical Experience

As we have already mentioned, in some cases, not even the option of dynamic vertical scaling remains sufficient and horizontal scaling thus becomes necessary. However, it pays off to thoroughly consider whether this really is the case. No matter how attractive horizontal scaling may seem in theory, it clashes with multiple conceptual disadvantages in reality.

First of all, horizontal scaling puts pressure on developers to create applications that are prepared for parallel operation and task fulfillment. We know from experience, that writing such applications is much more demanding on developer knowledge, time, and testing (and, as a result, on finances).

Furthermore, the limitations of external services need to be taken into account. Typically, the biggest complication arises in the event that the application meant to operate in a parallel mode uses a shared filesystem. Scalability is then reduced for the entire application simply due to the way this decades-old technology operates (object storage would be a suitable replacement). Even cloud platforms or infrastructure built on a distributed solution (e.g. GlusterFS) sooner or later run into the limitations of the technology used, that tend to be very difficult to overcome during operation.

Another problematic aspect is usually relational databases that also due to their conceptual design don’t account for being clustered. Technology in this area has advanced significantly, for instance, we have a great experience with MariaDB Galera Cluster – we have been successfully operating the Shoptet platform for tens of thousands of e-shops on it. From this point of view, it is a more advanced solution than what Amazon offers with AWS Aurora.

AWS Aurora only allows for horizontal scaling using so-called “replicas”, which are read-only replicas of one database instance. It is, therefore, a very limited form of horizontal scaling that loses its meaning this day and age because by limiting the operation from a relational database (to make the application more horizontally scalable), especially read operations are limited – for the offloading of which, tools such as ElasticSearch are used. These tools, on the other hand, are very easily horizontally scaled but aren’t in principle suitable for storing data of key importance.

Read-only replicas are once again a decades-old mechanism that we don’t consider to be a suitable technology for horizontal scaling. That is the case primarily because this method cannot ensure 1:1 scaling for all operation types. AWS offers no alternatives for horizontal scaling of SQL databases.

Hassle-free Horizontal Scaling Thanks to vshosting~

We see the biggest issue with modern applications built for horizontal scaling in their complexity. This makes it difficult to predict which part of the application or its component will reach its limit.

At vshosting~, we assist our clients’ developers in order to make their applications more easily and quickly scalable. We advise them which elements in their applications are or will become limiting for further growth and prepare individual, robust, and fully scalable infrastructure without compromises.

There is no point in reinventing the wheel: thanks to our unique know-how at vshosting~, we will let you know what to focus on when designing an application. We will prepare your project for global expansion, also thanks to our own CDN, which we’ll soon be launching on a third continent (Asia).

Damir Špoljarič

CEO & Co-Founder


We have successfully assisted with migrations for hundreds of clients over the course of 17 years. Join them.

  1. Schedule a consultation

    Simply leave your details. We’ll get back to you as soon as possible.

  2. Free solution proposal

    A no commitment discussion about how we can help. We’ll propose a tailored solution.

  3. Professional implementation

    We’ll create the environment for a seamless migration according to the agreed proposal.

Leave us your email or telephone number




    Or contact us directly

    +44 3301 900 777 Available 24/7
    consultation@vshosting.co.uk
    Copy
    We'll get back to you right away.