Applications’ infrastructure migrations are a vital area of DevOps field. So many times, we need to migrate the applications from one cloud platform to the other. In order to carry out the migrations in an appropriate way, we should have some set of standards defined which make migrations smooth. In this blog, I’ll be discussing some important points which we need to take care while migrating the infrastructure.
1. Document everything and prepare a migration plan: Documentation is a very important part of the activity and is always helpful. It is the first step of migration. The documentation includes all the below points:
– Existing server performance capacity
– Operating system with version
– List of installed packages on the server with their versions
– Crontab entries of all the users (if any)
– User accounts
– Configuration files of important utilities like MySQL, Mongo configuration, httpd/Nginx configuration
– Enabled modules in web server
– List of websites running on the server (if a static site, you should also document their document root with the size)
– Processes running on the server with ports. You can also document output of the commands like (sudo netstat -ntlp or ps -aux)
– Prepare a one line description of all the processes
– Firewall rules of the server
– All the databases with their users (Database credentials of each user from the code base)
– Existing traffic on the server
– Time of peak traffic and low traffic
– Prepare a migration plan according to the documentation and list down the possible challenges which can occur during this activity
2. Choosing the right server: It is very important to choose the right capacity of the server in terms of CPU, Memory, Disk, Network performance. One can take this decision on the basis of the htop/top command on the existing server. The parameters like the load average, memory usage and network in/out can really benefit us in choosing the right server capacity on the platform to which we want to migrate.
3. Choosing the right OS: The choice of using right OS plays a vital role here. If you’re comfortable in many versions of existing OS and if you are familiar with the application architecture then you can choose the best one according to your knowledge. However, if the application architecture is bit more complex and you are new to the migrations, then I recommend, to move forward with the existing OS. It helps you in migration and setting up the same configurations on the new server.
If you have chosen to keep the OS same. In such a case, keep the versions of all the utilities same as the existing server. If you are doing an OS upgrade then its very important to keep the utilities compatible as the previous ones otherwise it can lead to the breakage of some important functionalities at the application level. It can also make your migration process bit tricky. For eg. enabled modules in httpd can function differently in different versions or there might be some code which gets depreciated into the newer version of utilities.
4. Use standard and managed tools for DB migrations: We should always look for managed and standard tools for migrating the database. AWS provides a set of some database migration tools like DMS(Database migration service), Schema Conversion Tool etc which can make the database migration task easy. Tools like MySQL workbench and MongoDB cloud manager are also helpful in database migrations.
5. Tuning the server: The server and utilities optimization is a necessary step in migration. We should always keep in mind that everything needs to be tuned. There are so many ways by which you can tune the Linux servers. You should tune the server on the basis of network throughput, I/O operations, CPU and Memory performance. Java processes, Database, Php, Apache/Nginx tuning are also important part of this process. Also, configure any important crontab entry which also existed on the previous servers (like cron entries to clear the database cache). Ignore the ones related to backup as we’ll be configuring the backups as per the new platform.
6. Test the applications and look for errors: We should always test out the application in all the possible aspects. An important step here to keep in mind is that while testing, we should open all the possible log files(web server logs, application server logs, PHP logs, database logs, syslog) and the output of top/htop commands to get an insight of the server. Document all the issues/errors/unexpected behaviors at the server level while accessing the application and tune it accordingly.
7. Perform Load Test: One should always try to perform the load test and gather actual insights about the overall performance of the application infrastructure. If possible, try to get the actual insights of the existing server during low traffic and compare the results with the new server. We should always try to perform load test with a JMeter JMX which can relate to existing load. Keep tuning the appropriate server till the time you achieve best results. You can also configure some monitoring agent like Newrelic to get the insights of the application calls during the load test by which you can optimize the code base at a later stage.You can refer to the blogs 7 things you must know about load testing using JMeter and JMeter master-slave setup in multiple AWS regions for load testing.
8. Prepare a quick checklist for all the above steps and review: We should keep in mind that the above steps have been performed and the server is ready to tolerate the real time load. Review all the steps and ensure all the errors/issues have been resolved. It is always good to plan for rollback. So we should be well prepared for the rollback strategy.
9. Sync the Database and code files before migrating the DNS: This step is very important. We should always switch the DNS only after the database and code base is exactly same as the existing server. We should always try to keep the data consistent in the best way possible.
10. Continuously monitor the performance of the server: The step includes all the below steps:
– Configure all the important alarms (CPU, Network IN/OUT, Memory, Disk, Status Checks, Database connections, Database health Checks, Application up/down alerts, Newrelic error rates alerts).
– The above alarms must be integrated with any incident management tool which will alert the whole support team so that a quick action can be taken to each unexpected activity.
By following the above steps, you can make the migration process a bit smoother and efficient.