How to enable SSL for multiple sites on a single VM

If you have multiple website, the last thing that you often want is to spin up a VM for each site.  With Azure this is a problem because unless you are only using port 80, you are stuck.

SLL (Secure Socket Layer) typically runs on port 443 and is IP and port bound.  In order to support SSL for multiple website one of the following needs to be done by the Azure team.  I’m surprised that it’s taking this long to implement a solution (over a year) but perhaps these people might start thinking outside of the box.  I can hardly imagine that this is as big of a problem as it’s made out to be.  Fire someone, hire someone , do something but fix it already.

Solution 1 – Multiple IPs on VM Setup

• Allow me to specify how many VIPs I need for my VM and assign them.

Solution 2 – Multiple IPs on my Virtual Network (VN)

• Let me purchase IPs to assign to my virtual network.
• Then let me map those IPs to the internal addresses via that network.
• If I need more than one on the same machine then I can change the network adapter for that machine to include the additional addresses.

Solution 3 – Multiple Cloud Services with port forwarding

• Cloud services already exist.
• Let me add a VM to MULTIPLE cloud services AFTER it has been created.
• Let me tell the cloud service how to forward requests to which ports on the VM.
• On the VM a client can simply specify a different port number for SSL on a given site, such as 444 instead of 443.
• Because a cloud service gets a VIP already, this would be the fastest solution to implement.
• In fact, even if the cloud service can’t do port forwarding the VM setup can.  If we could add in the source of the forwarded requests to the endpoint rules then this might also be possible.

Solution 4 – Traffic Manager (TF)

• This actually won’t work because all TF does is update DNS records.
• If TF was a real load balancer/firewall then I’d be able to put in port translation rules and it itself would have a VIP.

Those are just a few of my suggestions.  I really don’t understand why this is architecturally difficult but it’s critical that Microsoft address these issues if they expect larger companies to use their services.  This should be a top priority BEFORE ANY other features are released as it has a huge impact on customers and has been an irritant for a while. 

I’d personally make this happen if I could but alas I can’t get a hold of any developer that actually works on these things.  It would be nice to hear from them why this is so problematic.

How to get a reliable and quick DB on Azure

I recently found out that SQL Azure is not a responsive platform for a business to move their database too.  In short, it’s too slow (3+ times longer than on site).  So in light of this I want to recommend to you how you can fix this problem and still get reliability, at least if you have some cash to blow on it.

What you can do is use 3 VMs to create a proper SQL Server mirrored failover scenario.

The advantages are

• Reliability
• Control
• CLR support
• Full text support

You would have 3 machines

VM1. Primary SQL Database

• This should be in the same affinity group as your current primary web machines.

VM2. Secondary SQL Database

• This should be in a different region than your primary system.

VM3. Watch instance.

• Ideally this would be in a third region separate from the other two.
• This is because if the datacenter fails instead of just the machine, the two servers are required for automatic failover to take place.  You would still have your data if that’s the primary concern, but if you need real time reliability then I recommend separating those nodes.

Basically your setup a mirrored failover on your machine to the one in the other datacenter.  If VM1 goes down then VM2 will almost instantly take up the slack and keep processing your requests.

Once setup, you have the advantage of a VM that will respond much more like it would at your current facility, and this is without waiting for every bit to be committed to other datacenters. When it comes to speed that’s a big advantage.  When I benchmarked it the difference was 500ms with a VM running SQL vs. 3,200ms in azure.  Either way you will also be the only tenant on the system and know exactly what resources you are and are not using.  Lastly while you do need to be licensed, you will not incur Microsoft’s charges for SQL which are quite costly as well.  If you were to run this VM for two years then you’d be better off buying your own license and installing that version on the server.

Resizing a Virtual Hard Disk (VHD) in Azure

Recently I need to resize (increase) a VHD on azure.  The following are steps that I used and they worked just fine.  Please keep in mind that this process does take some time but is faster than doing it on your own premises. 

Tools you will need.

• A tool to download your data to a vm such as Cloud Storage Studio
• Be sure to adjust your settings to download and upload large files with 4MB blocks.  Do this before starting the download or upload steps.
• A tool to resize your VM such as VHD Resizer
• A VM that can host the drive and conversion process (probably a small or medium).

Step 1.

• For resizing an OS disks, remove the VM that’s attached to it from your virtual machine list.
• You will still have the disk image to use later.

Step 2.

• Using either a new VM or an existing one, attach a new disk to it that’s large enough to hold at least one copy of your current VHD and a copy of the resized  VHD.  Let’s call this our working volume.
• If your source is 30GB and you want it to be 100GB then provision 150GB to fit them both.
• You can add a disk to a VM under Virtual Machines > [Your VM] > Attach (it’s at the bottom of the page).
• Then set the size of your disk and add it to your VM.  This working volume will be used to temporarily store a copy of the vm to resize as well as the resized version.

Step 2.

• Remote into the working VM and download the vhd to your working volume.
• I did this using Cloud Storage Studio

Step 3.

• Once downloaded, use VHD Resizer to create a new copy of your vhd on the same volume that is the larger size that you wanted.
• This step usually takes a while

Step 4.

• Upload the new VHD back to the cloud as a page blob.
• Unlike a regular blob, page blobs let your specify larger amounts of space to use without being billed for that space unless it’s used.  This is required for a VHD.

Step 5.

• Once uploaded you need to add that disk to your disk list under virtual machines.

Step 6.

• Reattach your disk or recreate your vm using the new disk.
• At this point you no longer require your working disk and can delete it along with any temporary resources that you used to get to this point.

SQL Azure Performance

I originally posted this on stackoverlfow but thoguht htat it would be helpful to post it here too.

Our app is an asp.net app and the DB is about 11 GB in size.

SQL Azure and Performance Tips

1. Never use a pooled connection in the cloud. If you do, you will have your queries dropping left right and center. Instead open one connection and keep it open until you are done.
2. Use caching. You don't have a choice if you have a hope of making this work. I have one site successfully in the cloud but I had to use caching to get any reasonable performance out of it.
3. Realize that it's not your fault! The Azure team needs to fix their end more than you do yours. We have a lean app, we've been upgrading, tweaking and optimizing for 10 years and if we can't make it work then you won't either.

Tests

Tests are done by running a series of queries that access the exact same data and are done in code via a custom function that measures the response time from the creation of an object to the time it's disposed (forced to write to the DB). This object wraps the code that's being tested.

No caching was enabled for the test however I did allow the code and DB to execute it once before and took the best results so that the DB server has the opportunity to optimize the query and so the web server could load the assemblies properly.

Test 1 - Web and DB on same good machine

• Quad core 2.5GHz, 8GB Ram @ 800Mhz with 1300 FSB and SQL 2005
• yields 290 ms response time.

Test 2 - Web and DB on same machine

• SQL and Web on 2 Proc (dual core 3.0GHz), 16GB Ram @ 200Mhz with 200 FSB and SQL 2005 Really old IBM Server.
• Web and SQL both are local to each other
• yields 656 ms response time.

Test 3 - Web separate from DB

• SQL on 2 Proc (dual core 3.0GHz), 16GB Ram @ 200Mhz with 200 FSB and SQL 2005
• Web on 1 Proc dual core 3.0GHz, 8GB Ram @ 200Mhz with 200 FSB
• Really old IBM Server.
• Web on one machine and SQL on the other.
• yields 796 ms response time.

Test 4 - SQL Azure

• Medium VM on Azure
• SQL Azure DB
• yields 3,174 ms response time.

Test 5 - Azure VM with SQL

• Small VM on Azure for Web
• Medium VM on Azure for SQL
• yields 499 ms response time.

Conclusions

• The difference in latency for me when moving from a one server scenario to a two server scenario was 140 ms.
• Moving from that scenario to Azure was 2,518 ms. that's 17.98 times worse performance than on my 8 year old machines.
• While running a VM with SQL had better performance, the cost to run this scenario is absurdly high and not worth doing unless you are really large or already own your own licenses. For fault tolerance you actually need two medium VMs and a watch machine. Either way this would potentially provide better performance than SQL azure and from some of the threads out there perhaps better fault tolerance to.

Don't use SQL Azure until they fix this.

Take the time to let them know that it's an issue for you as well.