(Ping! Zine Issue 61) – There comes a time when many ventures decide to expand horizons, but, like a nestling looking to make its first flight, the task can be intimidating. Many questions arise when looking over that edge. Perhaps the most important is, “What am I not prepared for?”. In this article, these areas will be explored as they apply to growing your server capacity by migrating to a new environment.
Three steps are recommended for a successful migration. These are server preparation, a trial-run migration, and strategizing DNS switchover.
“What about setting up the customizations that are implemented on my original server?” I am glad you asked. In preparation to move to a new server, you may not want to utilize all the same configuration settings. Point of fact, in some cases, this may have negative results. A common case would be that you are moving an old, dedicated hardware server to a VPS. Or you are moving to a more powerful server. You may want to use more permissive mail per hour allowances, or tighter PHP allowances, depending on the new environment and new needs. That decision will need to be made after some review of your current environment and the needs that are to be resolved by migrating. However, if you do want a baseline to start from, the following list provides many of the typical needs and opens up what should be considered for configuration before beginning to migrate accounts. Following are the most common settings that will be desired.
You can replicate your EasyApache (Apache and PHP module) compilation by copying the build profile from the original source server to your new server. The currently running EasyApache profile is located at /var/cpanel/easy/apache/profile/_last_success.yaml on the original server. This can be copied to /var/cpanel/easy/apache/profile/custom/original_server.yaml. This profile will now be available in WHM or command line ( /scripts/easyapache ) for selection on the next EasyApache run.
If there are other custom profiles that you have saved on the original server and would like to retain, they are available on the source server at /var/cpanel/easy/apache/profile/custom.
The PHP configuration is located at /usr/local/lib/php.ini. If you had additional server wide configuration to what EasyApache sets, you may want to copy this over as well. PHP values a client has set within their .htaccess files, or php.ini files if using suPHP, will be included in their account transfer packages, as long as those files are located in the client’s account directory.
While copying over the MySQL settings may provide a good baseline value if moving to a similar environment, one will want to continue monitor the MySQL utilization and update the configuration as traffic is added or use changes. A utility called mysqltuner can provide some insight for recommended changes. If desired, the configuration is located at /etc/my.cnf.
Exim configuration modifications, as well as custom ACLs, can be downloaded from the source server. This is available in the WHM -> Exim Configuration Manager. The file provided can be uploaded to a new server for configuration replication. This is important if you have set up Smart Hosts, custom ACLs, or other advanced Exim configuration.
Locales allow you to change the language displayed in the customers interface. If you have custom created locales, they can be downloaded in XML format for upload onto the new server. This is available via WHM -> Locales. Custom Branding is available via WHM as well under the Branding section.
Server wide settings, such as those available in Tweak Settings, can be copied by duplicating the /var/cpanel/cpanel.config file. After copying, activate them on the new server by running the following from command line.
# /usr/local/cpanel/whostmgr/bin/whostmgr2 –updatetweaksettings
Additional settings should be considered on a case by case basis. As always, the cPanel Technical Support team can assist with any questions one may have about this preparation phase.
Now I would suggest to perform a test run of the migration. Additionally, I recommend doing so in groups or phases of sites with similar environments. Some examples would be static data only websites, sites with similar CMS implementations, email only accounts, etc. This will prepare you with knowledge about any kinks that prevent your site from running in your new environment.
The simplest part of the migration is transferring the accounts. The tools provided in the cPanel WHM Transfer suite will automate transferring over everything necessary to create the accounts themselves. Those included are account limits, site data, databases, email accounts and settings, ftp accounts, Ruby on Rails applications, DNS Zones, etc, as they apply to the accounts. Reseller package limits and privileges are also included. The transfer utility can also facilitate transferring a reseller along with all of their accounts while maintaining the reseller – account association.
All that is needed is to log into the WHM Copy Multiple Accounts interface on the destination server, connect to the original source server by providing the root login details, and selecting the appropriate accounts to transfer.
To test server preparation and site readiness, first set your local workstation to resolve domains to your new server. This can be done by setting your workstation’s /etc/hosts file up to resolve domains to the IP of your new server, forcing requests to be made there. You can find your operating systems /etc/hosts files with the following table
Your operating system’s /etc/hosts file should have examples of the format to follow.
Once resolution is forced to the new server, you can browse the sites via domain to find and resolve any issues that may be shown. Issues are typically caused by not having proper Apache or PHP settings. The initial preparation should resolve a large majority of these. Once the new server setup is confirmed to accommodate the sites, it is time to move to the DNS Strategy.
Now that the new server is set up, an important question to ask is, “What will DNS updates affect and am I prepared to mitigate those issues.” The most common issues involve dynamic data. These will typically affect:
Each of these services require their own approach, but the first step is to lower the TTL for the records in your zone files. This alerts DNS Caches, also known as the resolvers that ISPs provide their clients, to check your nameservers for updates more often. If you do not have control of your own nameservers, you will need to alert your provider.
Lowering your TTL will prevent DNS updates from taking longer than necessary when you are ready, to forwarding the domain resolution to your new server. Lowering the value to 300 will alert the DNS Caches to lower to their lowest value. Note, that their lowest value may be higher than this.
Now that this is complete, you need to mitigate people contacting your server to send new dynamic data. To assist with email, you can add a secondary MX record with a lower MX priority which points to your new server. This way, once you are prepared to make the final migration of accounts, email can be disabled on the original server and the mail will redirect to the new server per the MX records. If you are using a third party mail service, you can work them to coordinate this.
If for some reason mail does become out of sync between the two servers, an application such as imapsync can be found on the web. Imapsync will log into the source server with your clients IMAP login details and place the out of sync mail onto the new server. Additionally, mail files can be directly transferred server to server using rsync.
To avoid site content and database uploads, it is easiest to suspend the accounts just prior to migration. This can be done via manual suspension at WHM – Manage Account Suspension. Another option is using the “Express Transfer” in the WHM Transfer tools. This will update the Zone Files in your server’s control to the new server and place a “Site Transfer” place holder page on the original server. Please note, that your server must be an authoritative nameserver for this to be successful. If your accounts use their own nameserver service, the clients will need to be included in the DNS switch discussion.
In the event that web files or databases become out of sync, rsync can be used to update static files between the two servers. Databases can be dumped and imported with MySQL or PostgreSQL utilities directly or via phpMyAdmin and phppgAdmin respectively.
With this information, expanding your server into multiple servers should be less daunting. As always, the cPanel Technical Support Team is hear to assist with any further inquiries that come to mind.
Good News. cPanel offers free migration services and consultation from the following *nix based panels.
Ensim / Parallels Pro
The cPanel migration team, established in 2009, includes over 20 years of experience to assist you with planning, performing, and validating a successful migration. We will verify software compatibility, assist in resolution of known problems, consult about the mitigation of DNS transfer as it applies to dynamic data updates, migrate data, and provide assistance after the migration has completed. The team is here to create a supportive environment throughout the process, offering:
Free complimentary 24x7x365 ticket support to all of our clients.
Measured, but frequent release cycles, monitored and supported from Level 1 techs up to the CEO, founder and developer.
Frequently updated technology blogs covering new technologies and how cPanel & WHM software integrates with them at http://blog.cpanel.net
A user driven Forum discussion that is frequented by all levels of cPanel staff. You will engage firsthand with subject matter experts including technicians, QA analysts, developers, and the CEO, founder and developer himself, at http://forums.cpanel.net
For more information or to contact cPanel for migration services, please visit: go.cpanel.net/migrate