For this post, we’d like to make two announcements right off the bat. Firstly, we are now offering a new service which is currently one-of-a-kind in Russia: Remote Points of Presence. This service shortens the route your online project takes to an Internet exchange point to just a few clicks in our control panel. Secondly, we’ve rolled back the prices for additional guaranteed bandwidth; these savings of up to 30% should help ease anyone’s spring fever!
The market today is flooded with offers from different cloud service providers. It’s not just a question of just choosing one service over another; clients firstly consider their business requirements and the relevant tasks.
In this post, we’ve compiled a list of the most important features individuals should look for when choosing their cloud service provider. If the best solution for your business is cloud-based, then please feel free to refer to this checklist before making your final decision.
Today we’ll be continuing our post series on containerization mechanisms. In our last article on containerization, we talked about isolating processes using the namespaces mechanism. For containerization though, isolating resources isn’t enough. If we launch an application in an isolated environment, we should be sure it has been allocated enough resources and not use an inordinate amount, interrupting the rest of the system. For this task, the Linux kernel has a special mechanism, cgroups (short for control groups), which we will talk about today.
Any individual or company looking to utilize a data center’s services needs a guaranteed level of quality. There has to be some assurance that their equipment will not fail and that their data will always be available (or that in the worst case scenario, their project will quickly be restored).
When it comes to data centers, the most commonly recognized guarantee is certification. Certification asserts that the center complies with a predetermined list of standards. Although issues of standardization have gained particular interest over the past few years, the number of relevant publications on the topic remains low.
In this article, we’ll be looking at the primary regulatory documents for data center certification.
Linux container solutions have gained quite a bit of popularity over the last few years. A lot of people have written or spoken about how containers can be used and what for, but little attention has been paid to the mechanisms behind containerization.
All containerization tools, like Docker, LXC, or systemd-nspawn, are built on two Linux kernel subsystems: namespaces and cgroups. In this article, we’ll be taking an in-depth look at namespaces.
For many of our services, we have to provide clients with various statistics. Clients who rent dedicated servers need information on the traffic they’ve used, VPC users need stats on hardware and network resources, and Cloud Storage users need information on file transfers.
The simplest and most direct way to present statistics is in charts. There are many programs specifically designed for analyzing statistical data with subsequent visuals. We’ve looked for an appropriate tool with performance as our main criterion. As a result… well, let’s go through this step by step. We’ll start some theory.
Today we’re publishing a guest post written by our client Alexey Vakhov. Alexey is the CTO of Uchi.ru, a company that develops an educational platform under the same name and also hosts interactive competitions (olympiads) for schoolchildren. The entire Uchi.ru infrastructure is built on our Virtual Private Cloud.
Alexey Vakhov gives a detailed account of how he and his colleagues use the utility Terraform for automating the setup and support of a virtual infrastructure. We hope his experience will be interesting for our other VPC users.
Containerization has become an increasingly relevant topic. There are already thousands, if not tens of thousands, of articles and posts written about popular solutions like LXC and Docker.
In today’s article, we’d like to discuss systemd-nspawn, a systemd component for creating isolated environments. Systemd is already a standard in the world of Linux and in light of this, it wouldn’t be unfounded to suggest that the potential for systemd-nspawn will significantly expand in the near future. For this reason, we think now would be a good time to better acquaint ourselves with this tool.
The initialization daemon systemd has become the de facto standard in modern Linux systems and is already used in many popular distributions: Debian, RHEL/CentOS, and Ubuntu (as of ver. 15.04). Compared to the traditional syslog, systemd offers an entirely different approach to logging.
At its base you’ll find centralization; the journal component collects all of the system messages (messages from the kernel and from various services and applications). In this case, there’s no need to configure log distribution, instead the applications can just write to stdout and stderr, and journal automatically saves these messages. This setup is possible with Upstart, but Upstart saves all logs to a separate file, whereas systemd saves them in a binary base, greatly simplifying systemization and searches. Read more
Back in 2014, the best (if not only) option for patching the Linux kernel without rebooting was KernelCare, a tool developed by our partners at Cloud Linux.
The situation has since changed quite a bit as live patching has officially been included in the kernel as of version 4.0. The tools kpatch and kGraft, which were still in development in 2014, have also been massively improved. Kpatch was even added to the official repository and in Ubutnu 16.04, it can be installed from the default package manager. Canonical has also recently released their Canonical Livepatch Service, which can be used to patch the Ubuntu kernel without rebooting.