Remember a Linux physical server migration summary

Two days ago we did an online migration of two servers in the production system, so we wanted to summarize some of the things that have happened before and after the migration and the lessons learned. In the professional style of doing things, I read about Microsoft and Red Hat Some of the official migration guidelines, but found that the practical part is not particularly much, so after referring to the Microsoft and Red Hat Migration Guide, I decided to a match the current scene of the server Migration "guide" for reference only.
Migration Background:
Two servers because of the need to move it (as can be understood as a server hardware upgrade, the new server hardware than the old server performance, such as more powerful CPU, memory and storage), so the original two servers to migrate to the new two servers. Because the number of active users during the day is higher, each server has a high number of concurrent events, so you have to migrate at night (and how to avoid it later)
Some concepts related to migration:
System migration refers to moving the operating system and applications on the source host to the destination host, and is able to function properly on the destination host. In the absence of virtual machines, migration between physical machines relies on system backup and recovery techniques. Back up the operating system and application status on the source host in real time, then connect the storage media to the target host and finally restore the system on the target host. With the development of virtual machine technology, the system migration is more flexible and diversified, so if it is a virtualized environment, it is much simpler, because the virtual machine can be considered as stateless computing.
Some migration principles:

1. Do not interrupt the business, do not affect the use of users, if the impact of user use, you should inform users to accept and prepare
2. Server hardware resources should be unified, such as hardware architecture, chipset, processor, etc.
3. System software operating environment to be as consistent as possible
4. Use the most suitable person to do this thing, have problems in time to communicate

Some migration metrics:

1. Overall migration time: When the migration starts from the source host to the end of the migration
2. Downtime: The time that the source host and destination host are not available during the migration
3. Performance impact on the application: the extent to which the migration affects the performance of services running on the migrated host.

An excellent migration tool that aims to minimize the time and downtime of overall migrations and minimize the impact of migration on the performance of services running on the migrated host. Of course, these factors affect each other, and implementers need to be measured in terms of the needs of the application being migrated, choosing the right tool software. For the migration of Linux systems, because it is an open source system, it is possible to manually migrate the system with some open source tools and scripts, which requires the administrator responsible for implementing the migration to have relevant experience and familiarity with the Linux systems running in the physical machine.
overall steps and processes for migration:

1. Preparing for Migration

1). Collect the source host hardware information and software environment information, prepare the relevant hardware and software documents with the source host
2). One inning of the above information and documentation configure the target host to the same software environment as the source host (under the conditions of Uniform server hardware resources)
3). Test the above configuration results (test method Reference validation migration)
4). The above work is done before the migration

2. Implementing the Migration

1). Notify the relevant personnel in advance to prepare for migration
2). Switch network parameters, such as switching IP
3). Close the business application on the source host
4). Start the business application on the target host
5). Restart or smooth restart the associated service for the associated host run
6). The day of the migration is complete

3. Verifying the migration

1). Self-Test migration results
2). Ask other people to test the results of the migration, such as the development team or the relevant personnel of the Test team
3). The day of the migration is complete

4. Post-migration tasks

1). Report to the relevant person
2). Reporting notifications to relevant users
3). Update Related documents and records

5. Complete the migration (same as "post-migration Tasks")
6. Rollback

1). Re-switch network parameters, such as switching IP
2). Close the business application on the target host
3). Start the business application on the source host
4). Restart the associated services running by the associated host, etc., by updating the profile of the associated service that the related host is running
5). Fix the problem and prepare for the next migration

note points for applying switchover/migration:

1. There are some applications that need to be tested before they are implemented, but may conflict with some servers in the production environment, such as message processing applications that may compete with other message handlers for messages in Message Queuing, so you need to be careful when testing to eliminate this potential conflict. This also requires the application to be as loosely coupled as possible, so that it can be modularized to make changes.
2. During the migration process, the business application on the target host must be turned off, and the business application on the source host, and vice versa
3. No matter what kind of switch, try to do without omission, everything size

Here are some of the considerations and considerations you need to take into the Linux system migration process:

1. Organize the migration list.

1). including the source host operating system name, version, host name, environment variables, drivers, processes, installed software, installed services, firewall, kernel parameters, security settings, User Configuration, certificate keys, file permissions and other system-based environment
2). Depending on the process name, port number, firewall configuration, or the system Maintenance Management log, locate the service that the current server is providing, the installation manual for the service, the software environment that the service depends on.
3). According to the current network connection status of the document or source host, mainly use the source host's intranet address of the related host, such as find the agent source server related host, pay attention to these agent host configuration, such as fixed write good intranet IP, domain name information, need to change, typical example is Nginx, Haproxy Reverse Proxy
4). Some of the more special file directories, software compiled directories,/etc/profile,~/.bash_profile,/etc/rc.local,~/.profile,~/.ssh,/etc/fstab,/etc/hosts,/etc/ Sysconfig, wait.
5). If there are too many projects or steps to be migrated, you can make the corresponding list, which is easy to reference and prevent omission, refer to Appendix

2. Prepare the target host.

1). The target host is configured to test the target host with the same software environment as the source host, using manual (which can be scripted, etc.)

3. Switch network parameters. If you just switch public IP, do not switch intranet IP, because the intranet IP may do some network internal coupling, so you need to pay attention to other related host

Migration Summary:

1. The implementation of documentation standardization is important, although it may be hard and tiring, but to do as much as possible
2. Changes that have occurred require timely modification of the relevant documentation and informing the relevant person
3. Deployment normalization, such as fixed compiled installation directory, user-friendly soft links, strict reference documents
4. Reasonable use of tools and techniques to reduce operating time
5. The software design process as high as possible in the low-coupling, as far as possible to support horizontal expansion, to achieve a stateless software design is a very idealized design objectives
6. Some hardware manufacturers have provided some migration tools or information gathering tools for reference, such as Dell's Systemmanager, Dset,cisco UCS Manager and other related tools

How to avoid nightly migrations, upgrades, or business changes:

1. To avoid mid-night upgrades, you must use Ha's system architecture (no single point of failure) that has no impact on users when one or more servers are down
2. Software as loosely coupled as possible to support scale-out
3. Rational use of automation, scripting, planning tasks, etc.
4. Write more tests to do more exercises, such as whether the normal rollback, etc.
5. Communicate ahead of time, have a good discussion,;)

Appendix:

such as "Migrating data collection Worksheet" "XXX change Table", etc., the migration Data collection worksheet can be referenced as follows:

#	source server Settings			remarks
1	key1	value1	success	 
2	key2	value1	failed

Other References:
1. Red Hat Document: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/
2. Microsoft Microsoft technet:https://technet.microsoft.com/en-us/library/dd365353 (v=ws.10). aspx
3. Migration topic in Microsoft Forum: https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverMigration
4. Virtual Machine Migration technology: http://www.ibm.com/developerworks/cn/linux/l-cn-mgrtvm1/

--end--

This article is from "Communication, My Favorites" blog, please make sure to keep this source http://dgd2010.blog.51cto.com/1539422/1685184

Remember a Linux physical server migration summary