IT-Grad provided to Russian Orthodox Church cloud services for the Prihod.ru project

Since 2014 based on the Prihod.ru project on blessing of the Most Saint Patriarch of Moscow and all Russia Kirill under the direction of Synod information department one of the most large-scale online projects of Russian Orthodox Church "Uniform map of temples and monasteries" in which all dioceses (the fundamental large admin units of Church) take part is implemented.

The official orthodox project has increased requirements to security and stability of work, speed of assistance and qualification of technical support of cloud provider.

As everything began

The mission of Prihod.ru — to expand and increase quality of presence of Russian Orthodox Church at web space. It is a huge complex of tasks which can conditionally be separated into three groups:

• Development and support of a hardware-software part;
• Training of users, far from IT, in net surfing Internet;
• Development planning of the project and implementation of affiliate programs.

In addition to exclusively "IT" tasks we solved also a great number of others. For example, initial expense optimization as the project non-commercial and is limited to own means of the founder was an important condition.

The first version of the designer of the orthodox websites was started in 2009. We purchased own server and placed it in rather known Russian data center. For the highly specialized project at that time it was enough. Problems appeared when after a year of stable work hard drives began to fail and to come to an end server resources.

The maintenance of the server and its software cost much enough as iron quickly became outdated, and problems with search of component parts began. Having sent the veteran to rest, we decided to refuse own equipment and to use ready-made solutions.

Look in clouds and the first test

At that time (2011) cloud computing in Russia was not rather developed and available therefore we moved to more comfortable at the prices and quality the European data center. There collected a small cluster design from several servers of a different configuration depending on the tasks solved by each machine. Several years the scheme successfully worked and now remains in working order for cost reduction on contents of the old version of the project. And for the organization of backup. Technically some time was enough this solution, inconveniences arose only at failure of hard drives (sometimes at once two in RAID-10).

So we for the first time close approached cloud computing.

Moving to clouds was planned along with change of technical base: for the project one of the most popular CMS was selected. As a new system at increase in loading will behave — it was possible to guess only therefore requirements to cloud infrastructure were a little indistinct:

• The maximum flexibility in the resource management plan and infrastructure;
• Big backlog on performance and potentially useful opportunities;
• High rates of availability and reliability;
• Reasonable combination of the price and quality.

We did not request specific digits of availability, and to us there was not essentially a number of "nine" of data center. The choice was influenced by a reasonable combination of speed of recovery of service after failure and the cost of support.

Originally the choice fell on Amazon. Their solutions satisfied our requirements: we made and counted several possible schemes under the tasks, easily configured infrastructure depending on state changes of a system. Though possibilities of a hosting allowed to do many interesting things, in our case it did not lead to serious economy of money. Still so inopportunely there was a crisis and growth of dollar. Because of all this and also specifics of the project there was a need to work completely in Russia.

By then we created classical infrastructure of the web project: the DB server and the server with the website. Performance of Amazon was enough for selecting enough resources to servers and not to think of load distribution clusters, and reliability of the platform provided high availability. All this suited us, and from a new hosting the same was expected approximately.

Moving reefs

After careful selection the majority of the Russian clouds disappeared for various reasons — most often there was not enough power under our requests or proposed solutions worked unstably. Having left two candidates, one of whom was IT-GRAD, we at first made a choice for benefit of other cloud hosting. A role was played by the seeming ponderousness of the alternative solution of IT-GRAD and orientation to enterprise. Then it seemed to us excessive.

Traditionally difficult process of migration in a cloud was the next step. It was necessary to solve typical administrator problems, though with cloud specifics:

1. Raising of new servers, data transfer.

#Настройка proxyings from the old platform on new. #Перевод domain names to the new addresses (our project uses several hundred domain names most of which part belongs to clients).

With deployment of servers in a cloud of particular problems did not arise, and performance of infrastructure and access rate were up to standard. And we decided to move. Moving, contrary to expectations, was quite trivial and did not contain any special tricks. We just disconnected to users an opportunity to change content, stopped base, did snapshot, recovered it in new location, then information rsync on the new platform. Typically and it is even quite boring, but works also without surprises.

On the next stage it became clear that channel capacity between the selected hosting and the Irish DTs Amazon is insufficient. The project saved up about a terabyte of data, and their broadcast became this problem. But the real trouble seemed that the scheme with proxying of traffic from the old platform on new was not repaid. Left all calculations that the channel most likely will not cope. Anyway, we achieved acceptable speeds with old DTs, but questions on an exchange rate with the rest of the world right there appeared — it was absolutely unstable.

Having lost fairly time and money, we returned to the solution of IT-GRAD. Collecting of all this "rake" at least revealed the most critical places of the project. Generally, we already knew what it is necessary to look at, and quickly banished necessary tests:

• Speed of the channel between IT-GRAD and Amazon was measured using iperf;
• Access rate from around the world — loading of the big file from different platforms and ping-admin;
• Speed of reading/record is time dd and time cat;
• Speed of main cores and the general high-speed performance — dragged the website on similar amazonovsky a configuration and watched average/iowaits, response time in Zabbix on one of the hostings; diagrams of high-speed performance — in ping-admin.

Pleasantly the clear advantage of IT-GRAD several times in comparison with the same Amazon surprised. Speed of disk input-output, performance of main cores, speed of network — everything was higher. As a result the amount of support of virtual infrastructure was lower settlement (and is much lower than amazonovsky).

Let's sum up the results

The ponderousness of an environment of IT-GRAD which we mentioned was a little exaggerated: for reliable work of the loaded system it is necessary to use quite complex systems of virtualization and the difficult equipment. Over time their application is repaid as the simplest problems (like failure of pair of modules of memory or disks) do not affect work of service in any way. Alas, we understood it not at once — at first it was necessary to work violent correspondence with technical support of our last hoster.

I do not think that I will tell something original, but the possibility of flexible resource allocation became the greatest advantage of transition to a cloud for us. It was mentioned above that the nature of loading of our project is difficult predictable, and purchase of the equipment "for growth" will hardly please the investor. Therefore an opportunity to throw memory and disk IOPS with a growth of loading was for us this golden mean: the peak of activity on the portal is planned — we pay slightly more, information calm — we return to former consumption.

Do you ask how it is possible not to consider when choosing a cloud availability indicators, a class of certification of DPC and other? Everything is right, it is necessary to consider. But also it is wrong to be focused on digits, nobody guarantees to you that all and will be in case of accident. For ourselves we selected hybrid option — selected cloud providers with an experience, successful projects and the known methods of recovery after accident. Also the efficiency of technical support which we could estimate when testing and moving was important. If competent specialists communicate with you, and reaction to letters does not last for day — logically to assume, as at accident will be also.

Also do not forget about "God helps those who help themselves": do timely backups and plan recovery options in advance. With such approach you will not lose, and the speed and quantitative indices when choosing it is possible it is banal to measure.