We are in the process of moving our current IAAS solution over to azure where we host asp.net LOB web applications in IIS with an SQL Server backend.
I’m looking into availability sets. I stumbled upon this article at: http://michaelwasham.com/windows-azure-powershell-reference-guide/understanding_configuring_availability_sets_powershell/
This seems like how we want to setup our deployment on Azure where the “Web Servers” are our virtual machines. My question relates to how we setup our virtual machines. Currently we have about 200 separate hosted customers on our IAAS solution which means 200 separate web applications in IIS. With a highly available deployment should the Virtual machines be exact replica’s of each other i.e. 200 customers on box 1 and that again on box 2. Or should we spread them over multiple boxes i.e. 0-50 customers on box 1, 50-100 customers on box 2 and so on.
I cant see how the 2nd option spread would work in a highly available set because if 1 box goes down than all the customers on it go down with it?
Little confused, hoping someone has got advice on this?
Thanks
It would be best to duplicate everything, the azure load balancer (layer 4 balancer) ensures that load is spread across listening endpoints evenly and randomly, so you cannot know which server will answer a request, hence you must have the same configuration on both boxes. Here is some info on the Azure load balancer which you might find interesting, link
Also put them into an availability set so if one of the vm dies for some reason or during updates (which can happen from time to time with vms) you can be sure that at least one of your vms will always be online. You may need more than two vms, it really depends on the amount of traffic each of your clients generate and the load that that creates. But do have atleast two vms.
Just a side note if you haven't used Azure before; it may take you a bit of time to get the cost per vm right over time, but remember to use the schedule to scale up and down to reduce costs and anticipate load on your vms. Also having 4 smaller vms is better than 2 larger vms from a failure point of view and ultimately cost the same over a month. If one large vm dies, you've lost 50% of your capacity to serve your clients, where as if you lost one smaller vm you've only lost 25%.
Related
I have set up an application gateway in almost five different regions in Azure and every time Azure take around 15-20 mins to complete the setup.
Whereas AWS will do it in a couple of minutes, why Azure requires such a long time?
You should try using Application Gateway V2, its a lot faster to create. updates are almost instantaneous (well, at least compared to V1). But I believe V1 is using windows VM's underneath, so it creates a set of vms for you, then it configures them. Each update would be a "sliding window" update, with 1 vm being recreated at a time.
As far as I know.
Application Gateway is a layer 7 load balancer which, as far as I understand, is a Windows VM (or collection of Windows VMs, depending on selected size) under the covers, which take some time to come up and be configured. In my experience, this time is usually around 15-30 minutes, depending on region and local time of day, capacity, etc.
Azure Load balancers on the other hand are layer 4 load balancers, which typically take in the order of 1-2 minutes to come up.
So, yes talking about the load balancer if you say it normally takes less than a minute to get deployed. But coming onto the Application gateway yeah it takes 15-20 minutes every time the reason being:
Configuration Settings: Microsoft has the set of the vacant load balancers ready at their backend and when they receive a request to deploy a particular load balancer in any region, they just assign it an IP as requested by the user and it gets deployed within a minute. But coming onto the Application gateway, azure need to start deploying the load balancer [App Gateway in this case] from the scratch, need to attach it to the VNET so deployed and making it ready for the backend pools IP Address configuration and all, which basically take time about [15-20 minutes]. Now, Azure has brought up the V2 of the Application Gateway, a lot faster to create usually 5 minutes. And also talking about updates they are also really quick and instantaneous.
Subscriptions: Secondly, the reason that it takes time is subscription. Suppose, you have the MSDN, free subscription in your Azure account. And another individual sitting at any different place is using the enterprise applications subscription [basically a pay as you go] in his azure account. Now, both of you raise a request to deploy an Application gateway in the same region at the same time then, Microsoft will give the person request with the enterprise subscription the higher priority than your free subscription request. Which is another reason that it results in a delay. As I am using the enterprise edition so it takes 2 minutes for a VM to deploy which gets deployed in 5-6 minutes if using the free subscription!
Thanks!
I have a Linux Standard B2ms azure virtual machine. I have disabled the autoshutdown feature you see in your dashboard under operations. For some reason this server was still shutdown after running about 8 days.
What reasons are there which could shutdown this server if I haven't changed anything on it the last three days?
What reasons are there which could shutdown this server if I haven't
changed anything on it the last three days?
There are many reasons will shutdown this VM, maybe we should try to find some logs about this.
First, we should check Azure Alerts via Azure portal, try to find some logs about you VM.
Second, we should check this VM's performance, maybe high CPU usage or high memory usage, we can find logs in /var/log/*.
Also we can try to find are there some issue about Azure service, we can check service Health -> Health history to find are there some issues in your region.
By the way, if we just create one VM in Azure, we can't avoid a single point of failure. In Azure, Microsoft recommended that two or more VMs are created within an availability set to provide for a highly available application and to meet the 99.95% Azure SLA.
An availability set is composed of two additional groupings that protect against hardware failures and allow updates to safely be applied - fault domains (FDs) and update domains (UDs).
Fault domains:
A fault domain is a logical group of underlying hardware that share a common power source and network switch, similar to a rack within an on-premises datacenter. As you create VMs within an availability set, the Azure platform automatically distributes your VMs across these fault domains. This approach limits the impact of potential physical hardware failures, network outages, or power interruptions.
Update domains:
An update domain is a logical group of underlying hardware that can undergo maintenance or be rebooted at the same time. As you create VMs within an availability set, the Azure platform automatically distributes your VMs across these update domains. This approach ensures that at least one instance of your application always remains running as the Azure platform undergoes periodic maintenance. The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time.
In your scenario, maybe there are some unplanned maintenance events,when Microsoft update the VM host, they will migrate your VM to another host, they will shutdown your VM then migrate it.
To achieve a highly available, maybe we should create at least two VMs in one availability set.
Background
Our company designs and hosts websites for approx. 500 clients, each client has one website. Each website is built on ASP.net. Our current hosting infrastructure is built on hypervisors with virtual machines running Windows. We have 3 virtual machines all running the same spec (8 cores, 24 GB RAM). The 500 client sites are split over these three web servers, there is no load balancing or fault tolerance – the website exists in only one location.
Therefore, as we accumulate clients each web server’s site count increases. When we max out each server, we bring another one online and start again, then once that one is full we spin another VM up etc.
Goal
We would like to move (eventually) our sites over to Azure, however we do not want to replicate our current set up on Azure, instead we would like to move each website over to Azure Web app instead to take advantage of scaling.
We would also like more fine-grained control over our costs when bringing online additional sites. Currently, we bring online a VM and costs us X (for an empty server), it may take us 3 months to fill this. We would like to steadily add to our hosting hosts, not in big steps.
My question
I have investigated for many days on this and cannot find a tutorial or guide on what the ideal set up looks like on Azure Web apps when hosting 100’s of websites. Almost all tutorials assume you only ever going to have one website, so there is a 1:1 relationship between a site and the underlying resource. They never talk about how you should organise your apps into App Service Plans etc.
I understand the concept of adding a website, choosing the appropriate pricing tier and setting the scale settings, what I do not understand is why people online talk about scaling out Azure Apps – surely if an ASP.net websites consumes a certain amount of RAM on a system, by bringing online another VM all you are doing is immediately consuming that amount of RAM again on another system. So scaling out in this sense is to ONLY improve availability – is this correct?
If someone is able to provide some of their own experiences when dealing with a lot of websites on Azure (even better if they own a web design company who hosts on Azure) it would be very much appreciated.
Think of AppService plan as a VM or pool of VMs (in case you run multiple instances) that runs the same applications simultaneously and share the same data disc. If you scale out, you add a new VM to the pool, if you scale up, you change the size of VMs (actually they aren't VMs, but from the user's point of view it is simmilar).
So basically in case like yours, where you run many applications (potentially) smaller applications, scaling up/down establishes the baseline - how many websites you can run, how many applications you can fit in the memory. And then scaling out gives your better reliability and more CPU power that helps you to cope with high traffic.
Our company is much smaller than yours, we host dozens of websites not hundreds. But there are some points that our experience have taught us:
Use at least S2 instances that have 2 cores, with S1 instances a single app can easily degrade performance of other apps in the same AppService plan
Use TrafficManager. If a need arises (e.g. an outage of the service in your region), you can easily move to another region
Split webistes between more smaller AppService plans and collocate applications with the similar usage patterns to the AppService plans. That way you can run one instance, when the traffic is low and spin up new instances when the traffic spikes up.
You are correct that in all pricing tiers (except free and shared) web apps are scaled to all machines in an app service plan. This is an availability feature from the perspective of a web app. Scaling an app service plan from 1 to 2 machines(or auto-scaling) essentially provisions the same web app on all the machines. This of course is no good for your situation, but all is not lost. Generally, the unit of scaling is the app service plan. You could break down web apps into buckets of app service plans. Say first 100+ web apps in AppServicePlan1, then roll over to the next 100+ in AppServicePlan2. The downside is that you will have to manage tracking what app service plan to place the next web app in.
I have a BizSpark account but I'm struggling to work out what I'm actually entitled to as part of my free Azure package. The package details are listed here:
http://www.windowsazure.com/en-us/offers/details?locale=en-us&offer=ms-azr-0012p&no-rewrite=true
I need to run:
One virtual machine (running Linux) to power the website
One hosted service to provide the client software (Windows Phone and Windows 8) with database access
One hosted service to provide the virtual machine with database access
Two storage accounts (one for images and one for the virtual machine)
One SQL database
Do the hosted services count as VMs and can anybody shed some light on the best configuration (VM sizes etc) to fit all of the above into my subscription please? Multiple instances would be nice but I think I might be getting greedy now!
Thank you.
The most important thing to keep in mind is that you 1500 hours of small compute instances (this includes both Cloud Services and Virtual Machines). 1500 hours per month means you can run 2 small instances full time or choose for an equivalent ratio. So you could go for 4 extra small instances and still have room for 2 extra small instances and 1 small instance to use for something else. To keep the SLA (on the hosted service at least) I would suggest the following:
2 extra small instances of a Linux Virtual Machine
2 extra small instances of a hosted service with a web role. The web role would have 2 tasks:
Provide the client software with database access
Provide the Virtual Machine with database access
This might not be the best solution in terms of performance, but you'll be able to run everything high available without having to pay anything extra.
The 2 storage accounts and the SQL Azure database (you must use the web edition) are also covered by the BizSpark subscription.
Update: 1 small = 4 extra small equivalent ratio isn't right. The ratio is 1 small = 6 extra small.
I run my own uk based hosting and web design company.
We have about 10 physical servers in a DC in the UK and host about 300 or so web sites, email servers and web applications. They are all on a windows server platform with a few linux VM's.
I now have a Windows Azure account, I have set up a medium windows 2008 server within my azure account and want to start using it to maybe host and migrate some of my web sites and services onto my azure account and new server. With the view that maybe I could move ALL my services over and get rid of the need for any of my physical servers in the DC.
My question that I am still really struggling with how much this will really cost me on an ongoing basis.
The billing area, doesnt really tell me much as it simply shows my bill as £0.00. It shows my usage but I am really struggling to compare the resources I am currently using compared to how its billed in azure? It doesnt even show me what it would have cost me if I werent ona trial.
I dont want to move web hosted sites over if its going to cost me more than hosting in my current DC.
I was thinking of moving many sites onto the new server i have set up as its a better spec than a few of my current servers, so would see a big benefit, I even considered setting up a much larger Server in my Azure account but again unsure as to the real cost of that box its hard to compare.
Do I simply need to look at the calculator and select the number of servers i wil deploy, select how much storage I need and bandwidth? Or do I need to look at the items in the billing area as well - such as:
Compute units,Storage Transactions,Data Transfer Out,Data Transfer In
When I set up the server it didnt ask me for how much storage I wanted it just set it up with about 150GB avaialble in the actual server.
Any advice as I really see this as something i want to use over the next 12 months, but not if once i have finally migrated stuff its going to cost me more than my normal hosting and i have to move stuff all back at the end of the 12 months.
Cheers
Because you're using Windows Azure Virtual Machines, you should first use the virtual machine pricing calculator. This calculator only displays the costs that are relevant for your scenario except for the storage transaction cost. Here is a breakdown of the costs you'll have to consider:
Virtual Machines
The Virtual Machine cost appears on the bill as compute units. Throughout the Windows Azure Virtual Machine preview, the cost per core per hour is $0.08. Once VMs reach general availability, the cost will be $0.115 per core per hour for Windows VMs and $0.085 for Linux VMs. Using the calculator, you can see that a medium instance uses two cores and will therefore be billed at $0.16 per hour during the preview period. You will have to use your best judgement to determine how many virtual machines you'll need and how large they should be.
Storage
You will have to pay for the data actually used within your VHDs. Let's assume you have one virtual machine with one VHD attached. If the size of the VHD 200GB, but only 100GB is used, you will have to pay for 100GB per month.
Bandwidth
Microsoft now only charges for egress data transfers (data going out of the data center). With this pricing change, the Data Transfer In section of the billing area will always be 0.00. Hopefully, you already have a good idea about your current outbound data usage. If so, you can calculate your bandwidth cost by simply moving the bandwidth slider to the correct spot.
Storage Transactions
If you scroll down to the Transactions section of this blog post, you'll see how storage transactions are counted. Basically, you count one transaction per write operation and possibly one transaction per read operation depending if the data is cached or not. The cost of storage transactions are negligible because you only have to pay one cent per 100,000 transactions. That's why storage transactions are left out of the calculator.
HTH
To answer such question in an input box has limitation to express in details. The cost calculator is there to give you an estimate of upper limit about what the cost will be if your usage are under selected limit. Based on my personal experiences if you choose higher limits of usage and keep the usages within your forecast limits, there will be no hidden charges. But the reality could be far different because you may not estimate the usages correctly at first and this could change the cost later.
For moving a traditional web hosting solution to Windows Azure, latest release of Windows Azure Virtual Machine is best fit as this requires minimum migration complexity. So the VM size you will choose will have fixed resources (compute, local storage, network bandwidth, disk I/O etc) and the cost will be fixed as long as you are under limit so there will not be unseen charges.
Windows Azure Storage is pay as you go (ranges ~$0.012/GB depend on usage limit) and there is no limit. When moving from traditions web hosting to Cloud environment, due to application architecture design, I have seen less Cloud storage usage and more VM storage so it may not cost a lot.
The place you will see cost variation is data egress/ingress and it is difficult to forecast as it is all depend on application usage, so this is something you will have to account as variable cost.
You can also contact Windows Azure Virtual Machine Forum where dedicated Windows Azure Virtual Machine resources are available to answer your such questions.
Finally One thing I would also add that Windows Azure Virtual Machines are still in preview mode so it would be best to bring some of your business to Windows Azure VM as trial and testing purpose because now matter what you think you may encounter problems (because it is preview release) and this could case service disruption.