Website Developers eCommerce eMarketing
For a free consultation 787 -557-3109
.
 
Web Developers Knowledge Center
 
  PR Market Web Developers, Inc. "We make it happen, always and on time"
 
 

Cloud Servers

Jan 26

 


Windows 2008 IIS and Database Migration using the Web Farm Framework

he following article will document the process used to perform an application level migration of t

he IIS 7.X running configuration, MSSQL and all associated data to another server. 

Please note that some elements like custom .DLLs and third party modules may need to be migrated manually. 

Let's take a look at how to perform this: 

Contents:

  • Requirements
  • Install the Web Farm Framework
  • Configure the Windows Firewall
  • Configure the Webfarm Service
  • Migrating SQL using the Web Farm Framework
  • Removing the Destination Server from the Web Farm Service

Requirements

Both source and destination servers should be running Windows 2008. 

The revision level is not as important. 

The destination server size is not important so long as it has enough 

free space to hold all the custom data.

Install the Web Farm Framework

Install the Microsoft Web Platform installer on both the source and 

destination servers. Here is the link to the 

Web Platform Installer 3.0: http://www.microsoft.com/web/downloads/v3/platform.aspx

Install the Microsoft Web Farm Framework v2.2 

available here: http://www.iis.net/download/webfarmframework

Configure the Windows Firewall

The Windows Firewall on both the source and destination 

servers will need to be properly configured in order to allow 

communication between both instances of IIS. 

This can be done by either setting up an admin IP on both servers, or by opening up specific ports.

Run the following command from the command line:


netsh advfirewall firewall add rule name="Web Farm" dir=in action=allow remoteip ="IPADDRESS" enable=yes


You will need to run this rule once on each server replacing the word IPADDRESS with the 

correct IP address of the REMOTE server. Optionally, you could open up the SMB, 

Remote Administration (RPC), and Web Farm Agentservice (8172 and 8173) ports on 

both servers instead of creating the Admin IPs. 

Configure the Web Farm Service

You will need to create an administrative account on both servers that will be 

used by the Web Farm Framework to synchronize the configuration settings 

and data between servers. 

  • Run the following commands from a command prompt to create the accounts and 
  • add them to the administrators group. You will need to replace the word PASSWORD with something valid:
Net user webfarmuser PASSWORD /add
Net localgroup administrators webfarmuser /add
  • Launch the IIS Manager.
  • Expand out the Server Node.
  • Right click on the Server Farms Node and select the Create Server Farm option.
  • Enter the Server Farm name in the appropriate field.
  • Check the box labeled Provision Server Farm.
  • Enter the authentication credentials that were created earlier into the Server Farm Administrator section.
  • Click Next.
  • Enter the SOURCE servers IP address or Server Name in the appropriate field. 
  • This can be the private IP if both servers are in the same Data Center.
  • Uncheck the box in front of "Server is available for load balancing".
  • Check the box labeled "Primary Server”.
  • Click the Add button.
  • Enter the DESTINATION servers IP address or Server Name in the appropriate field. 
  • This can be the private IP if both servers are in the same Data Center.
  • Check the box labeled "Server is available for load balancing.
  • Click on the Add button.
  • Click the finish button.

The server farm framework will now begin copying over all of the IIS c

onfiguration settings, data, and SSL certificates over to the destination server. 

You can view the progress by doing the following:

  1. From within IIS, expand out the Server Farms Node. Expand out the Farm Node.

Note: The name will vary depending on what you named it during the creation process.

  1. Next, select Servers and you'll be able to see the current actions listed in the Trace Messages section.
  2. The destination server should have received all of the IIS data when the Secondary shows 
  3. Yes under the Ready For Load column.

Migrating SQL using the Web Farm Framework

There are numerous methods of migrating MSSQL databases over to the 

destination server and what method you select should be decided upon by 

you and your developers based on your unique needs.  In addition to the traditional 

methods of migrating databases, you can also use MSDEPLOY 

which was installed during the installation, and is a key component, of the Web Farm Framework.

   Here are the steps you can follow if you want to use MSDEPLOY to migrate your databases:

Bring up the MSDEPLOY command console on the SOURCE server by performing the following:

  1. Start
  2. IIS 7.0 Extensions
  3. Web Deploy Command Line and the modify the following line to match 
  4. your environment and then paste it into the MS deploy command prompt 
  5. (The private IP can be used if both servers are in the same Data Center):


msdeploy.exe -verb:sync -source:dbFullSql="Data Source=SOURCEIPADDRESS;User Id=USERNAME;password=PASSWORD;Initial Catalog=DBTOBEMOVED" -dest:dbFullSql="Data Source=DESTIPADDRESS;User Id=USERNAME;password=PASSWORD;initial catalog=DBTOBEMOVED;" 



Removing the Destination Server from the Web Farm Service

It is not necessary to remove the Web Farm 

Framework once the migration has been completed, 

but the individual servers can be removed by doing the following: 

  1. From within IIS, expand out the Server Farms Node.
  2. Expand out the Farm Node and the select Servers.

Note: The name will vary depending on what you named it during the creation process.

  1. Right click on the destination server and select Remove Server.


 
 
Let us know
 
 
comments (0)
 
 
Jan 26

 

Migrating your data to a Performance Cloud Server from a standard PRMWD Cloud Server can be a straightforward process with some planning and preparation.

Preparation

For detailed advice on preparing a server for a smooth migration, please see the recommendations in this article on migration preparation. In particular, you can reduce the amount of data to be migrated by cleaning out old installers, rotating logs, and removing old cache and session files.

You can also find a good list of items to keep in mind before migrating in this Before You Move to Performance Cloud Servers checklist.

If you do plan to remove files from your server to help a migration go more quickly, we strongly recommend making a backup first to ensure that no essential data is inadvertently lost.

Image-based migration

A server image can only be restored to the system disk of a Performance server (and similarly, images can only be taken of the system disk of a Performance server, not of any data disks attached).

Image-based migration to a Performance server will not be possible for standard servers with more than 1GB of memory due to the larger disk allotment on those servers. Some 1GB and smaller servers may also be ineligible for image migration (if a server has been resized in the past it can affect an image's minimum disk size requirement, for example). First-generation server images cannot be used to create a Performance server.

Images are restricted to the region in which they were created. Performance servers can only be created in the IAD, ORD, DFW, and LON regions at this time. Support for other regions will be added in the first half of 2014.

The simplest way to find out if you can migrate in this fashion is to try it out. Make an image of your server (you can use the steps in this article for guidance) then try restoring it to a new server. You won't have the option of creating a Performance server if the image size is too large for a Performance server system disk.

If an image-based migration will work, that's the easiest approach you can take. For a reliable migration we recommend stopping any running applications before creating the image you'll restore to the new server.

If you were able to use an image to migrate you're all set. If you're unable to use image-based migration, read on to prepare for a manual migration of your data.

Check the size of the original server

To determine the minimum disk space you need on the new server, check how much disk space you're currently using.

To check disk space used on Windows, check the properties for the C: drive.

To check disk space used on Linux, run:


df -h


If you require more space than is provided by the system disk, you will need to use data disks or Cloud Block Storage volumes on the new server to accommodate all of your data.

Identify directory requirements

When setting up data disks or Cloud Block Storage volumes, you should check the sizes of the directories on your origin server. This information can help you plan your data's organization on the new server - what will go on the system disk, and what will be stored on the additional volumes.

You can also specify a directory or file name, as in:

du -hs *

On Linux, you can determine the disk space used by files and directories in the current directory by running:


du -hs directoryname

On Windows, right-click the directory you wish to check and select Properties.

Once you know which data will be copied to your system disk and which will be copied to an attached disk, plan the size of the new server and its additional volumes (if any) accordingly.

Create the destination server

When creating the destination server, keep your storage requirements in mind as well as memory, CPU, and network requirements.

If you have more data than will fit on the new server's system disk, you'll need to decide where you want to store the additional data. The flavor of server you've selected might include one or more data disks. You can also attach Cloud Block Storage volumes to the server.

When choosing the size of your server, consider your current needs and any scaling you might need to do in the future.

Performance servers can't be resized, so adding and removing storage space via Cloud Block Storage are the only changes you can make to their capabilities. For a single-server environment, you will need to migrate to a new server if your RAM or CPU requirements change.

Alternately, you might plan your environment to use horizontal scaling - where more than one server runs your application, with a load balancer in front managing traffic to the different servers. Horizontal scaling may not work with all applications, but once set up it makes it easy to add or remove servers to account for fluctuating load requirements.

Some example environments can be found in our article on open cloud reference architectures.

Note that you can't take a snapshot of a Performance server data disk, so to back up data disks you will need to rely on Rackspace Cloud Backup or a similar file-based backup approach. If you want your additional storage to be more portable or need to be able to take data snapshots, consider adding one or more Cloud Block Storage volumes to the new server.

Format and configure any data disks

With your server created, prepare any attached data disks or Cloud Block Storage volumes by formatting them and configuring the system to use them.

If you've attached Cloud Block Storage volumes, see this article for instructions on preparing those volumes.

For instructions on formatting and mounting data disks on Performance servers, see the appropriate article for your server's operating system:

  • Preparing a data disk on a Windows Performance Server
  • Preparing a data disk on a Linux Performance Server

If you are setting up attached volumes in a software RAID on Linux, see the Linux Software RAID HOW TO for instructions.

With your attached disks ready to go, it's time to migrate your data.

Migration options

You have several options for a manual migration, including Rackspace Cloud Backup, Rackspace Cloud Block Storage, or rsync on Linux, and Web Deploy or the Web Farm Framework on Windows.

Cloud Backup

To use Cloud Backup to migrate particular directories, take a backup of your data from the origin server then restore it to the destination server.

Cloud Block Storage

To migrate specific data using Cloud Block Storage, attach the drive to your origin server first and copy your data to it. Next detach the server, attach it to the destination server, and copy your data from the drive.

Using rsync on Linux for a directory

On Linux you can use rsync to copy a directory over the network directly. For example, from the origin server you can run the following to copy /var/lib/mysql:


rsync -e 'ssh' -avl --stats --progress /var/lib/mysql username@123.45.67.89:/var/lib/mysql


For more details on rsync, see this article.

Full Linux migration with rsync

If you want to migrate the entirety of a Linux server to a new Performance server, you can follow the directions in this article series detailing a full rsync-based migration.

Web Farm Framework on Windows 2008

To migrate IIS and MSSQL data on Windows 2008, you can use Microsoft's Web Farm Framework per the instructions in this article.

Web Deploy on Windows 2012

To migrate IIS and MSSQL data on Windows 2012, you can use Microsoft's Web Deploy tool.

Application-specific options

Other applications may have their own means of facilitating data migration. For example, to migrate a database you could make the new server a slave of the original database to automatically replicate your data to the new server.

Post-migration

Once all your data is on the new server, make sure you test your application thoroughly to make sure it works as expected in the new environment.

If you haven't already, put a backup plan in place to prevent significant data loss in the event of a catastrophe.




 
 
Let us know
 
 
comments (0)
 
 

  •  
     
    Categories

     
     
    Search