2
votes

Apologies for the noob question, I've never dealt with failover before.

Currently we have a single hardware server running Windows Server, SQL Server, ASP.NET and a single (very large) web application. We are considering migrating this to an Azure VM.

I see in the SLA that Microsoft will only guarantee 99.95% availability if I am running more than one instance of an Azure VM, to allow for failure and reboots etc.

Does this mean I therefore would have two servers to manage and maintain? For example, two versions of SQL with a database on each, and two sets of ASP.NET application files? If correct, this puts the price up dramatically.

I assume there is no way to 'mirror' one server across to the other to reduce this workload?

Also, our hardware server has 25,000 uploaded files on it. Would we need to put these on a VHD then 'link' them to whichever live server was running, or does Azure do this automatically? Or do they have to be mirrored from the live server to the failover server?

Any pointers would be appreciated. I've already read all the Azure documentation but it hasn't really made things much clearer...

1
Just a note - the SLA 99.95% with more than one instance is for Windows Azure Cloud Service (Web Role / Worker Role). If you are targeting Windows Azure VM, it is separate SLA - 99.9%, and it covers single instance. But it will take place once the Azure VM become GA. Currently the Azure VM are in PREVIEW.astaykov

1 Answers

3
votes

Seems like you have multiple topics you should look after.

Let's start with the database. The easiest thing would be, if you could migrate your sql server into the sql azure one. Than you would not have no need to maintain it and to maintain the machines you should use. This would you give the advantage, that you central component can be used by 1 to many applications.

Second one are you uploaded files. I assume that your application allows to upload files for sharing or something else. The best thing would be, if you could just write these files into the windows azure blobstorage. Often this means you have to rewrite a connector, but this would centralize another component. For the first step you could make them available and clients can download it with the help of a link. If not you could load the files from their and deliver them to the customer.

If you don't want to rewrite your component, you should have to use the VHD. One VHD can only have one lease. So only one instance can be used. A common way I have seen is that if the application is starting, it is trying to "recover" the lease. (try-and-error like)

Last but not least your ASP.NET application. If you have such an application I would have a look into cloud instances. Try not to consider the VMs, because than you have to do all the management. VMs are the IaaS. With a .NET application should easily be able to convert it and deploy instances. Than you have not to think about failover and so on. Just deploy 2 instances and the load-balancer will do the rest.

If you are able to "outsource" the SQL server, you could minimize your machine for the ASP.net application. Try to use scale-out and not scale-up. This means use more smaller nodes, than one big one. (if possible)

If you are really going the VM way, you have to manage all the stuff by yourself and yes than you need 2 vms. You are also need 3 vms, because you have no auto-loadbalancer and if you only have 2 just one machine can have the port 80 exported.

HTH