VM Migration: Consideration while using Azure Site Recovery (ASR)

Last few weeks, i spent good amount of time on testing Azure Site Recovery capabilities for performing migration. During testing few of the things, which came across me. Although Microsoft has tried best to document entire process, but sometime we, as human being, has tendency of missing critical part or things are not mentioned clear.

I am going jot down those which would help in planning, testing and using ASR for migration.

  • Configuration server should be as per recommended sizing. You can also perform with slightly lesser configuration also, but be cognizant of fact that you may not get good performance.
    • Save Recovery Vault Credential at secured and known place on Configuration server,
    • If using unmatched configuration, while installing Configuration Server Application (Unified Agent), you would receive compatibility assessment with Warning, Error etc. Warning can be read through and can be ignored.
    • You may require (most probably) machine restart. Please do that.
    • Configuration server set up with either Proxy or Without Proxy based scenario. So, security can be taken care as per enterprise rule.
  • V Imp. straight after installation of Microsoft Azure Site Recovery Configuration Server wizard , you should do two things;
    • Add Account of Target Source Server which you want to migrate. Key here is that those should be either Domain Admin account, who has right to install application on Source Server, OR Local Admin Account of target server.
      • Thus, if you have multiple server in environment and does not domain joined server, you may end up adding many account. Try to Add, user friendly name, which can be later identified easily.
    • After adding account, go to next tab of ‘Vault Registration’ Browser same Vault Registration Credential, which were used during installation. This might sound confusing and may not find in documentation. But, during my testing i found that it have impact. Even if you leave this option, your config server still be visible on ASR. But, discovery and mobility service push may not work as expected. Therefore, it is better to take precaution than rectifying later, which is off-course difficult.
    • Vault Regis
  • If trying to migrate Physical Server, you would need to add Physical Servers manually by their IP. Config server would not do auto-discovery unlike VMware or HyperV migration.
  • Target Source Server should have expected firewall rules enable. Follow Microsoft documentation for detail. Basically, you should have WMI, File/Print sharing necessary things are enabled at Source Protected VM. Failing to do so, neither you would be able to push install Mobility Service or Migrate Server.
  • Since ASR gives you option of perform Test Fail-over, Pre-Check before migration, always use “Test Fail-over” option. This help in checking if target destination server would perform as application behaving at source server.
    • Recommendation is to have ‘test network sub-net’ and test fail-over on it. Keep production separate.
  • If you have application running on Running has some dependency on different environment or source server or intranet application, it is recommended to keep your network layer ready prior initiating migration process. Set up Hybrid Network either using Site-to-Site or Express Route. Create different virtual network sub-net, testing/production etc. Testing should be performed only on Testing Sub-net.

This is for today. I would be collating more information about scenario we can touch base for ASR.

 

Know Your Environment (KYE) First !!!

Stop, Look, then Cross….simple rules to even cross roads. Then, why do we simply decide on going to cloud and start working without even going through basic prerequisite checks.

Cloud is attractive but not every application/architecture/server right fit for cloud based environment (remember IaaS and PaaS work differently). Every cloud vendor has slight different approach towards hybrid connectivity/cloud and hosting platform offerings. Enterprise Application running on Windows Server 2003 migration may not be fit foe lift & sift (simply pick and move to Cloud VM). You may need to check what is pattern of usage, need of application first. Then, explore dependencies of application to different applications/processes. It is good if you have enterprise architecture (which is generally rare, though they claim) or use automated tool (which is generally preferred as it is back by true facts and bring much more value added information on table).

Server Migration is not as straight forward like traditional application migration like Office 365 migration from respective workload running in different environments. I am in opinion that planning play vital role than migration. For migration, every vendor has their offerings or working on some directions. Some of the example: Azure has many things like Migration using PowerShell from VHDX to VHD/Using MVMC tool from VMDK/ASR/Even Back up etc. AWS launched recently AWS Migration Service, Google tying up with Migration vendors. But, bigger question remain same, where to start from???

Similarly database migration possess another threat towards failed move. Azure has interesting offering on DB as a Service known known as Azure SQL Database, Document DB for No SQL which is not only cost effective but also managed DB engine (there no more worries about maintaining uptime/patching/availability) OR even running latest DB edition on Azure VM. But question remains same, what is usage of current DB, what is need, what architecture, what is application usage pattern for this DB, can I really get all features if I’ll move to managed DB service or if my current DB is good enough to move on latest DB edition running on Azure VM.

If enterprise does not do proper due diligence, expect them to fail badly.

Use automated tool rather doing manual approach. As we all know manual approach is prone to human error and based on thoughts. While automated way is based on true facts and prone almost no error. Few of the solution are available in markets like;

  • Azure VM Readiness Assessment Tool: It does analysis on current on premise physical or virtual environment and provide you design level recommendation if there are any changes required. A step-by-step by guidance of using is available here.
  • MAP toolkit for Windows Azure Platform: This has been flagship assessment product for product for assessment Microsoft environment for long time. Be it Core IO workloads, Server Consolidation project, DB migration, Office 365 and even move to Azure. There has been constant enhancement done on this. Make sure you always use latest version of it. Follow this guide to perform action. As I mentioned, this has been flagship Assessment product of Microsoft. While installation or assessment, chose environment which you want to work on.
  • Database Assessment: Database is altogether different animal in enterprise IT environment and most important. It’ll always have separate planning and a most complex and also having so many option in market from different vendors (managed and unmanaged DB engines). Good part is Microsoft has interesting offering such Database Migration Assistance (DMA v3.0). What I like about this tool is that it helps doing assessment of current database and it can assessed with respect to target environment which can be either SQL Server (latest edition) running on VM or Azure SQL Database. Icing on the cake is it can even migrate it to destination environment. What else you need, when it can do the same job for source environment running on Oracle, IBM DB2, MySQL etc. Explore this quick video.
  • Web Application Migration: Azure App Service is very interesting offering from Microsoft Azure for Web Application Hosting. It takes away availability, patching, management part. But, I have my application and DB running on premise and that on outdated (EOL) version. How to move ahead. No worries, just use this tool as per guidance. It’ll not only assess and give your some recommendation but also help your transferring to Azure App Services with required DB engine. All this would happen seamlessly. Best part, if you have environment running on Linux it can handle that also. Follow this guide and learn about it.
  • Apart from all those, there are also 3rd party offering such as BitTitan’s HealthCheck for Azure which is exciting granular level automated assessment. It address ROI/TCO and Migration in single go without much of manual work, which I believe is more important than migration. Migration can be done either way but where to start from is most critical.

In next post I would be talking about few of those assessment tools usage in detail as well as easy way of moving to cloud.

Keep in mind that knowing your environment using such tools would only help you planning for successful transition to cloud. As a service provider organization, it should be must to do activity before you claim any project. Don’t just rely on discussion and build Scope of work on those. Your estimation should be based on facts, else it would be bad experience for customer as well as loss making deal for you.

As a service provider, if you want to be true cloud service provider and make money from happy customer. Following P2M2 would be essential.P2M2