Everybody Likes Ninjas

Working with Azure 10 tip for day to day work part II

Sunday, 6 February 2011 09:47 by Guy

Guy

In the last six months many new features, improvements and changes have accorded in the Azure platform most are from the technology side, as the system matures new lessons are learned and new features are created as the result of a feed cycle between the Azure development team and the user community. Below are three issues we have dealt with in the last three months.

Technology

6) Disaster recovery for web services requires 2 instances

Part of hosting in cloud platform is receiving the 99.9… uptime, without the extra cost of expensive network gear, redundant hardware and an on the payroll IT employees. Azure solution promises the 99.5 uptime for it services, it is a built in function for Azure CDN, Storage and SQL, yet to achieve the same for a web role you have to upload at least to instances. Apparently the issue was not so clear to many, so a new warning massage was added in the management and development interface.

Image 1 : mutipal instances

7) Improve your availability

Using more than one instance is not enough, I would strongly suggest putting to usage the “Upgrade Domains and Fault Domains” settings. A “Fault Domain” is a physical allocation of hardware serving your application, for instance two different server racks. If you have uploaded two instances or more the app fabric is responsible to use at least two “Fault Domains”. That way if hardware unit fails at least one instance will keep on running.
“Upgrade Domains” is a logical grouping of your instances, the default is 5 domains the Azure app fabric will make sure these domains are located on more than one “Fault Domain”. Why would you need an “Upgrade Domain? Well when Microsoft is upgrading the servers it will upgrade one upgrade domain at a time if your servers are divided to several “Upgrade Domain” there will not be a point in time when all your instances are down.
To learn more check the following blog post "Service Runtime in Windows Azure" .

-There is one catch hidden in this process; let’s say you have 3 live instances all working in the capacity of 70%, your total used capacity is 210% out of 300%. Now one of the servers is undergoing maintenance which leaves you with a total capacity of 200% where will the remaining 10% go to?

8) Place your services close together

As ambiguous as the cloud platform is the servers are located at a physical location and network has an impact on your application performance and your client user experience. Obviously you should select a physical hosting solution as close as you can to the majority of your clients, but that is not enough placing your application modules that communicate with each other is even more important. If you are using SQL Azure or Azure Storage solution with collaboration of Azure Hosted services, place the services at the same physical location ( and no the regions Anywhere US and South Central US are not the same) if you decide to place services in multiple location closer to your client don’t rely on network connection across sits, consider duplicating your SQL Azure DB and using the sync service to replicate data across the different DB instances, that way your application and DB services will be located in the same place.

New features - Missing a feature you are probably not the only one

9) DB instance can be scaled

Web or business edition that was hard decision when we started our SQL Azure project leaving business edition performance advantage aside, size was a big factor. To increase your DB size from 1GB to 10 GB required a new instance and the coping of the data to the new instance while keeping some kind of sync process going on while the application servers are being rerouted to the new DB server. Now multiple that by the number of your clients !!! and try to explain the downtime or why you have to change their in-house ETL process.
Well the new version of SQL Azure allows you to change the DB size on the fly both for the web edition and the business edition.
Farther more having a 50GB combining with the new SSRS reporting system brings new possibilities for a mini datamarts in the cloud.

10) You can host multiple subdomain on one web roll

Filling we are not getting all we can from our instances (remember the multiple instances issue) we decided to upload more than one web site on our instances. Sadly you can upload only one web role per instance and there is no way around it. Yet from Azure documentation we knew you can host multiple web sites on the same web role using endpoint on different ports, but who will ever want to host his web site on a port other than 80? After looking for a solution, we approached Microsoft Azure support center; within 24 hours a blog post was published with a solution tailored for our needs.

How does it work ? the web role imitates the behavior of an IIS by setting a different host header entries the web-roll diverts the traffic to a different “website”.

Up until now if you had three clients each requires two instances (web-servers) and use a constant of 120% computing power, you had to upload each client on a three server group and only one server in the group could be down at a time. By uploading all three client applications to 6 servers instead of 9, utilizing 360% out of 600% available computing power, the new setting increases your availability and redundancy and at any point in time you can have two servers down and still have more the 360% CPU power, not to mention saving the cost of 3 instances!!!

New feature are being added to the different cloud solution at an amazing rate, and the development community is filling the web with new request and replacements for missing feature, such as fulltext search and comparison tools. If you run into a dead end, you must remember you are probably not the only person out there with this issue Google it or contact the support center, the solution is out there.

Guy

Working with Azure tips on day to day work part I

Wednesday, 26 January 2011 10:33 by Guy

Guy

In the former posts I have been writing about the theory of working with Sql Azure and Azure as part of our introduction in to the Azure beta program, well this month we have uploaded the second version of our application integrating new technology additional computing power and an Sql Azure DB. We have learned a lot in the process, I would like to share the top 10 insight in maintaining, managing, building and uploading a live application to Azure cloud.

Reduce your expenses

1) Select the program best suited your needs

There are many rate programs for Azure it can start with an 87$ for a small server and ends with free for MSDN Premium subscribers After you have selected the program most suitable for you, you can change to another program without any down time by sending a request to Azure support team. By doing so you can to start with one of the free programs and then easily migrate to another program as your requirements change.

2) Delete your staging servers !!

Yes, you pay for your staging servers. You pay for every server even servers that are in the stop state, that is because the resources for that server are still assigned to it. Therefor when you are done with staging server don’t just stop the server - delete it. Microsoft even added a remark in that spirit to their management console and documentation.

3) Scale on demanded

This is the essence of cloud computing, you don’t have to start with the best the biggest servers, you don’t have to buy servers that will accompany you till your next farm upgrade. Start with the Extra Small Server and 1G DB for a soft launch; it takes maximum 15 minutes to add extra servers and 10 to upgrade your DB storage (http://msdn.microsoft.com/en-us/library/ee621788.aspx), and billing for the upgraded resources starts when they are up and running.

Tools provided by Microsoft

4) New cool management interface

Image 1 : Azure Portal

Microsoft has released a silverlight base management portal that supports the management of Azure components from virtual networks to hosted services. The application is slick fast and gathers all the information in one place, you can add new instances or new DBs, change configuration setting or delete existing resources from one interface

5) Support center

Azure support service is amazing, each time I have asked for a support either billing or development issues I got an answer within 24 hours with a follow-up email every 24 asking if I need an additional support and if I approve the closing of the case.. They implemented an escalation process up to the development team level if required, and in more complicated cases I received phone call from the support rep with an automated escalation up the support chain till the issue was resolved.

The service is free and working smoothly, in comparison try amazon AWS support, it cost an organ and the service, god help me, wasn’t even the S of Service.

Next post top 5 tech tips for working with Azure .

Guy

Scaling SQLAzure

Monday, 15 February 2010 08:23 by Guy

Guy

If your company is planning on using the Azure platform and SQL Azure for a high load OLTP application, you should change the way you think about application and database design.

The limitation on SQL Azure described in my former post, will force you to think differently regarding scaling your applications. Application wise, you must take into consideration that long running queries will be disconnected by the SQL Azure server and connections which are open for a long period over the internet, tend to disconnect due to network issues.

To limit the effect of these issues you should implement the following:

  • Connection polling in your application (built-in feature using .Net), will reduce the load on the database server. Connection polling also saves resources on creation and reduces the latency of creating a connection over the internet.
  • Use short transactions\batches, open the connection in the last second, execute the query commit and close the connection as soon as possible.
  • Implement retry mechanism in the events you get disconnected or unable to create the connection over the internet.

When you considering scaling options, since you don’t have any control over the hardware resources, scaling out is your only option. You have several options for scaling out, depending on your application. All of them will require a logic method in your application that will select the appropriate connection string, or in other words: your application must be partition aware.

Let’s review some of the options:

  • One Database per client- if you are a SaaS provider, you can open a database per client. This option has a few advantages: privacy and security wise, each client has its own database. Billing wise, you can bill your client just for SQL Azure recourses their database is using (see below: Master DB).
  • Configuration Database – if your database holds static information, updated once in a long period of time, you can create multiple copies of your database using Sync Framework to synchronies the changes from the primary one. You will also need to add a round robin method on your application side to select the connection string and distribute the load on the different instances.
  • Logical partitioning or Elastic provisioning– what if your application design allows that? You might be able to separate your data according to a natural key. Could be as easy as modulo 10 your client user id or opening a database per country\game\event … in your application. Of course, that too will require changes in the application connection string module logic. One company all ready implementing such a solution is www.ticketdirect.com. You can read more on Microsoft Case Studies.

I just had the privilege to join a closed Microsoft Connect session on SQL Azure . It seems that some new exiting features are on the way, which will help with scaling. Some of the performance execution limitations will be reduced and a new clone feature is being developed to help with instantly creating copies of your database for scale out usage and backup.

To enable the partitioning process, Master DB has changed considerably: it no longer sits at the center of the SQL Server and two new role gateways were added to login operation and logger of usage operations.

The login process uses two tables of sys.sql_logins for the login operation a new table sys.firewall_rules for configuring access to the “DataBase Server”. A successful login must be backed up with valid data in both tables (information about the login process can be found in my former post).

The second role as an activity logger for billing process is back up by two new tables named sys.bandwidth_usage sys.database_usage. By monitoring the values on these tables, you can calculate the operation cost of any single DB and add it to your client billing quote or monitor the operation cost of an event on your system.

Guy

SQL Azure

Monday, 25 January 2010 10:52 by Guy

Guy

Sql Azure is Microsoft’s solution for relational database cloud computing, it comes as part of Azure platform. As with the Azure platform in general, to implement such a solution many limitation were placed on the Azure version of SQL server. The implantation as technical solution is amazing and requires some IT background to figure the complexity of the solution.

The best place to start the explaining SQLAzure is with describing the infrastructure. As a user you are granted with a token, this token is used to create all your databases. First DB to set up is the Master DB, very similar the SQL Server Master DB(more on the functionality of the Master DB in the next post). All traffic to the SqlAzure “Server” is routed through a firewall that allows you to limit the accesses to specific sources using a well design web interface. Then the connection is rerouted to a gateway that diverts the connection to the current server hosting the online copy of your database. All SQL server instances that build the SQLAzure platform are installed on cluster machines to support high availability to improve availability the created database is automatically replicated across different machines . In the case of failure the gateway will automatically point to the current online database instance.

sqlazure

To increase scalability of your application and to maintain overall balances of the SQLAzure platform servers, your databases are placed across multiple servers. I.E. even though it looks like it, physically the your company databases are not placed on one server! What actually happens is that several companies share the same hardware! So how do you reach a specific database? The trick is in the login : the connection string must include the destination database, your connection undergoes authentication using the login setting saved in the Master DB and then diverted to the requested database that will probably be located on a different server.

Farther more to allow a fair resource distribution between the different databases and SQLAzure clients, several limitations are set on the databases settings and resource utilization. A detailed list of the limitation can be found in the following link, I bring the highlights:

  • The major change is that can’t manipulates local resources:
    • There is only one file group per database.

      The following technical resources are a good starting point to understand the SQLAzure platform :

    • No partitioning.
    • No fill factor.
    • No user define data types.
    • No full text indexes.
    • No memory settings or any other server level settings.
  • All tables must include a clustered index.
  • Each connection can only function in the boundaries of the database it is connected to.
    • No Trace or Profiler, due to the fact that when you connect to a specific DB you can interact with the Master DB .
    • Can’t use the USE <database> command.
    • Can’t use distributed transactions or queries.
    • Can’t use global temp tables.
    • No service broker
  • All logins are sql server logins, there is no domain support.
  • Maximum database size of 10G.
  • No SSIS or SSAS support
Connection throttling, to support fair resources distribution, is placed in the form of limitation on
  • Execution time limited to 5 min
  • Maximum open connection time
  • Limiting long running transactions and extensive resource usage CPU and memory.

These limitations will actively disconnect the client connection and STOP QUERY PROCESSING. Selecting the 10 GB (Business Edition) version over the 1 GB (Web Edition) version will grant your database with more resources and raise the limitation settings.

It is evident from the description above that SQLAzure is not a straight forward solution for high load OLTP databases or data warehouse implementation. Working tips scalability design considerations and more on the next blog.

Guy