Sql-server – SQL Server Cluster Performance

A few general things that I've learned over the years:

• See this question for a list of good books on the subject of performance, scaling and high availability sites.
• "Cluster" is the correct term. You're using multiple machines to serve one site in an attempt to increase availability. You can also use cluster to refer to specific portions of your setup: for example servers 2+3+4 would be your application cluster.
• Is there any reasons why you only have redundancy on the application level? What about MySQL and static content? Especially since your static content is relatively large look at how much bandwidth you can serve to N concurrent users if needed. What happens if the MySQL server fails or if server #4 has a bad disk?
• If you're moving everything from one machine start off small unless you don't mind spending more than you need. For example, I found a larger than expected performance gain in a similar situation moving from 1 to 3 servers. After you split into multiple servers you may find the new bottleneck is in a different area.
• As you plan for scaling now don't completely forget about possible future scaling. A little forward thought and design now can save you time in the future. For example, you have one static server now but what you want multiple in a year, or several servers spread out geographically.
• Consider creating scripts to help setup specific types of servers...doing it manually each gets old and you always forget one step. I did this recently and wish I had done it from the start. Running one script that does 50 install steps automatically in a few minutes saves you much time in the long run.
• As you get more servers the likely-hood of experiencing some sort of hardware failure becomes higher. Plan for this and play the what-if game: What if the hard drive failed on server X? What would we lose? How long would the site be out? How long would it take to fix it? etc...

So this turned out to be, as expected, a pretty silly mistake. I had forgotten all the steps required to set up Availability Groups to work with Azure, as outlined here.

Because the de-allocation of the cloud service changed its IP, the SQL-Listener was listening on the wrong IP address. I had thought about that and addressed it by deleting and recreating the listener, but I had totally overlooked all the steps that I, embarrassingly, had personally performed to set up the listener in the first place. So after an hour on the phone with Microsoft Support, we finally got everything set up again. It's all back up and working now.