Urgently moving to the "cloud": frequent errors

Now we will transfer the physical and virtual servers with all the services and application software running on them. I consider the most efficient and imperceptible option for end-users migration, which is based on the principle of scaling to the cloud infrastructure with the subsequent rejection of physical equipment.

But this is an ideal option, so we will talk about instant or very short-term relocation . Simple ways to "screw up" it - the sea, for example, the replacement or update component of the system without preliminary tests.

Each transfer of infrastructure to the “cloud” is an individual event. Considering how to carry out the transfer in each case simply does not make sense, we are talking about typical errors that lead to prolonged full or partial downtime of IT systems, services and components. Errors are a little bit at the level of educational program, but I see too often how they are made time after time.
')

Inventory

First of all, before making a decision on migration, it is necessary to make an inventory of the infrastructure in order to clearly understand what components your system consists of and how they are connected to each other. This will help you put all current infrastructure documentation in order. And, perhaps, in especially neglected cases - to create one. But the most important thing is to save time when debugging inevitable operational errors. Skip the inventory - get ready for deadlines and incidents from the support service.

Test stand

Suppose that a decision on migration was made for one reason or another, and a number of potential cloud providers were selected. At this stage it is important to take time to test both the cloud provider and partially work out the transfer mechanism. Evaluate everything, especially paying attention to the convenience and intuitiveness of the virtual data center management interface, prices, adequacy and responsiveness of the support service, the ability to migrate not only to a specific cloud environment, but also the ability to migrate from it (retreat paths must also be available), backup methods , as well as the timing of the restoration of your infrastructure that the provider offers and defines for you. Pay attention to specific features of working with each particular provider, for example, ways to create virtual server clones, disks, ways to increase the performance of your virtual servers (do they allow it? Or do you have to scale horizontally each time?), Don't forget to work with virtual networks.

If you do not test, you may get the feeling that everything can be transferred without difficulty. Often this feeling is wrong, and the scale of the “drawn” difficulties may unpleasantly surprise.

Security

At a minimum, it is necessary to clarify the possibility of protection against DDOS attacks, assess the bandwidth of communication channels and the presence of an intrusion detection system. For a number of customers, these options can save a lot of time and nerves. I and my colleagues will talk more about security in a corporate blog, like, for example, in this checklist .

Good plan

The last step before starting the migration process will be to write the migration plan, where it should be described, what sequence should be transferred and at what time. There is one recommendation - the plan should be sufficiently accurate to reflect all the migration steps, and the features of the transfer of specific components identified at the inventory stage. There is no need to go far behind the illustration - in a large company, when organizing the migration of infrastructure consisting of separate services dependent on each other, it was necessary to transfer them in several stages in a certain sequence. The lack of a clear plan of action cost one and a half weeks of additional work.

Right time

Of course, I repeat, the ideal option is to scale into a virtual infrastructure, but if it is impossible for some reason to do this, the best option would be to transfer the hard disk casts. Further, it is possible to transfer via backup physical systems with the subsequent restoration of the latter in a virtual environment, and finally, if the system allows, a clean installation on the newly launched virtual servers. The answer to the question "When?" Is quite obvious - at the moments of minimal infrastructure load. The infrastructure is determined by specific services that are running and functioning in it, which means that it is most convenient to keep in mind the so-called “average hospital temperature” when several of the most critical services are selected, information on their loading is analyzed and specific information is selected based on this information. migration intervals.

Migration process

Do not change the software components of information systems during the migration process. For example, in the relatively recent past, replacing Apache with Nginx caused four hours of downtime for a single visited portal - not all rewrite rules worked correctly even after a test migration. Generally, IMHO, if the migration is not done by scaling the IT infrastructure or the information system to the cloud, it is best not to change anything until the end of the procedure. This statement is controversial, because, of course, there have been migrations when updating one or another component of information systems helped to solve technical difficulties. Ultimately, the latter choice is made by a specific engineer on the part of the customer, who weighs all the “pros” and “forgive”, based on the knowledge of the system or service transferred by him, as well as the risks communicated to him.

A separate sub-item can highlight the issue of compatibility. It often happens that not all operating systems can be “easily” transferred to the cloud environment, for example, because the cloud provider does not support the licensing scheme of the components of your solution.

I hope this will help to transfer the infrastructure in case of urgent transfers in a more organized way. If you had a "rake" during the moves, please share in the comments.