Web-moving with minimal downtime

Web-moving with minimal downtimeFriendly TakeoverThe simple at first glance, changing the IP address from web servers may partly due to unpredictable effects of the DNS caching come into a nightmare. Good preparation and a transparent reverse proxy help in the transition.
 Who wants a dedicated server by replacing a more powerful server, or even completely change the provider usually has to deal with changing the IP address. And that poses complications with web servers. Changes in DNA are dependent on the "Time To Live" (TTL) of DNS record, visible only after up to 24 hours for all access providers. As long as requests for a portion of land on the old, the other on the new IP address. While this is to get over static Web sites with a little planning, threaten for dynamic content (say, with many commenting or daily changes using a content management system) inconsistencies. With the right approach and a few tools can be a critical transition period shortened significantly and achieve an almost seamless transition.The central component of this approach forms a transparent reverse proxy on the previous server. The leads from the date of the move all requests to the new server and returns the result to the client browser. Thus the old server works only as a proxy and the actual HTTP requests processed only the new server. Then can change the IP address in DNS, and finally take the old server from the network. The new server must be prepared accordingly and at the time of his conversion to date.Examples are given for a simple "LAMP" root servers (Linux, Apache, MySQL, Perl or PHP) - such as WordPress. But the steps are largely transferable to other situations.Preparatory measuresThe first step is to prepare the new server. After installing the appropriate software packages to include the static files and copy all the MySQL databases. For file transfer, offers rsync, which must be installed on both servers. The following command - running on the old server - transfer the folder / var / www / ssh on the new server with the IP address 192.0.2.1:rsync-az / var / www / user@192.0.2.1: / var / www /The-a option causes the recursive copying the folder along with the acquisition of all properties and permissions of the files. It is therefore advisable to ensure that the relevant users (especially the user under which Apache runs httpd) have the same UIDs on both systems. The-z option switches one compression for transmission.Responsible for transferring the databases of the first sets an SQL dump on the old server and copied it onto the new server:mysqldump-p - add-drop-database-A> ~ / mysql.sqlrsync-z ~ / mysql.sql user@192.0.2.1: ~ /On the prospective host to import the following:mysql-p <~ / mysql.sqlIf eventually the desired Apache configuration in / etc/apache2 on the new server, a test is followed by a restart of Apache and MySQL. A solid entry "192.0.2.1 www.example.com" in the hosts file of your computer (usually in / etc /, on Windows systems in c: \ windows \ system32 \ drivers \ etc \) dangles before this that The new server is already stored in the DNS.Adjust permissionsEspecially for file uploads, it is worthwhile to look more closely, because they show rapidly permissions attributable to difficulties. Changes to the site as part of the tests are completely legal, because the new server shortly before the change gets transferred once the last stand of old.After making sure that the website works on the new server and the hosts file back to its original state, the old server take over his job as a reverse proxy, and that using the Apache module mod_proxy (there for lighttpd is a module of the same name, it says in nginx http proxy module) together with mod_proxy_http. Under Debian Linux is the equivalent command:a2enmod proxyAlso, the configuration can prepare itself. However, it may not yet be active when you restart Apache. This happens only during the actual changeover. The following configuration makes Apache to reverse proxy:ProxyRequests OffProxyPass http://192.0.2.1/On ProxyPreserveHostThese lines can either be the beginning of a VirtualHost block (which will enable migration of individual virtual hosts), or global, instead of the virtual hosts. The first indication ProxyRequests Off prevents the server being built on an open proxy. ProxyPass directive then provides the actual transmission of requests to the new IP address and so the new server is secure. An additional indication ProxyPreserveHost On receiving the host header of requests. This is important so that each may respond to the correct virtual host on the new server managed by the requests.Those who have completed the preparatory work can freely choose the timing of the transition and is independent of the following DNS change. To keep the data consistent, successive steps are necessary. It is a short outage in buying to take, he does not take much longer than reading the MySQL dump and then import the data (solutions for large databases and to minimize downtime see below).The commands for the old server are:apache2ctl stopazu rsync - delete / var / www /user@192.0.2.1: / var / www /mysqldump-p - add-drop-database-A> mysql.sqlrsync-z ~ / mysql.sql user@192.0.2.1: ~ /Then on the new server:mysql-p <~ / mysql.sqlAnd then on the old server:Start apache2ctlFirst stop so apache2ctl stop the Web server. May occur during the transition any more changes. Then the first rsync the files updated to the new server. The-u option ensures that files are only taking into account that have been added since the first transfer, or altered. This saves much time. Using - delete rsync deletes files on the new server, which no longer exists on the old.
 When a server move with changing the IP address of the old host can temporarily work as a proxy, so there are no inconsistencies. Then create the MySQL mysqldump dump, rsync copied to the new server, where it grossed the mysql command. Who created access statistics by analyzing log files, should now also the log files transferred from the old to the new server (note write permissions for the webserver!) And then restart Apache. Last apache2ctl start again starts the Apache on the old server, which acts with the previously modified configuration now exclusively as a reverse proxy.At this point, but still get all the requests from the outside to the old server, but it is passed through to the new turn, and returns the answer to the browser of the requestor. The actual processing takes place exclusively on the new server now. Everything works as desired, then the DNS change (eg in the context of a domain move to the new provider) will take place on the IP address of the new server. Until the change is visible everywhere, the requests to run between access provider either through the reverse proxy on the old server or directly on the new server. When the operation is no longer just disappear on the old server, and it can be turned off.ConclusionFor simple Web server is the LAMP procedure described a convenient way to go long without failure or the risk of inconsistencies a (web) along with host IP address. Minimize to servers with large databases or to the downtime further, would offer a master-slave configuration for the MySQL server. This is directed to the MySQL server on the new host first as a slave to the old server and then makes him during the transition to a master.