I am new to Azure and website deployment, and I am trying to make sure I understand how things work. As far as I understand, once I create a website, a web application is created and begins to run in the cloud before publishing my own site even.
I know that the cloud provides scalability, load-balancing (among multiple datacenters), ease of publishing/testing, etc...things that don't exist in traditional web hosting.
So my question is since my website is in the cloud/Azure now, would my website be replicated globally in MS datacenters? If yes, is it something different from load-balancing? in other words, is the idea behind it is to get my site replicated to provide faster access from all over the world. And if all these are correct, I suppose traditional web hosting doesn't support replication.
Sorry for the simple questions, but I really need to understand, and I would appreciate any details you could provide.
Q: So my question is since my website is in the cloud/Azure now, would my website be replicated globally in MS datacenters?
A: Your website won't be automatically replicated globally to all MS datacenters. Each azure service, whether it is an cloud-service, sql-azure, storage, website or VM is located at a location of your choice. Within a location you can scale some of the services to run in multiple instances. If you spawn a new instance your website gets replicated. But it still runs at the same geo-location.
Q: If yes, is it something different from load-balancing?
A: In Azure you need to distinguish between load-balancing and traffic-management. If you run multiple instances within one location, there is only one external URL to reach it. The load-balancer distributes traffic equally to every running service instance.
The Traffic Manager allows you to control the distribution of user traffic to Windows Azure hosted services. The hosted services can be running in the same data center or in different centers across the world. Traffic Manager works by applying an policy engine to the Domain Name Service (DNS) queries on your domain name(s).
So in general, if you want to spread your application all over the world, you have to do it by yourself.
Create your service on all the location of your choice and use Traffic Manager to connect them.
Related
I'm currently developing a mobile app which will be pushed world-wide across the app stores. This app uses a WebAPI REST service as the backend which I currently have running on MS Azure in Europe (which backs onto a database also in Europe).
My problem is, I'd like to create multiple Azure WebApi endpoints (i.e. Australia, US, etc for latency reasons), each with their own database which has geo-replication enabled.
Does anyone know a method/product/service I could use which allows me from the app to either:
Connect to a single domain which behind the scenes picks the closest server to the user.
OR
The app itself is able to determine based on a given list the closest server and connect to that?
I've looked at Azure CDN but this is for static content which is great but I need something for dynamic content.
What you're looking at is Traffic Manager. Traffic manager enables that exact scenario, of finding the closest service that hosts your REST API.
Keep in mind though, that the database replication is (for the time being) a thing you have to do yourself, although we do provide you with the tooling and guidance on how.
We have a client that we have setup two webservers running about a dozen different websites spread over each webserver for each site (so site 1 is running on both webservers, site 2 is running on both ect).
We want to setup load balancing (presumably with Traffic Manager) so that it will spread the load and monitor the sites availability across both the web servers per site and not per virtual machine like the regular Azure load balanced sets do.
It seems that traffic manager might be able to do this but we don't know how it works and the documentation is not clear to us about if we can setup the TM per website and not per web server (as we understand it).
Can we setup any load balancing in Azure that will monitor the website itself and not the virtual machine? Because we want to run multiple sites on these two web servers, how do we setup TM do allow this to happen? Do we make a new TM service for each website?
thanks in advance.
UPDATE: do we even need to setup the regular load balancing set at all? Can I not just create a TM and click on the cloud services of each of the web servers and then add the port and relative path to one of the websites? and just repeat this for each website on the two servers? would that be how it should be setup?
Thanks again.
The available endpoints you can define in your Traffic Manager definition is only as granular as your cloud service URLs. So, the quick answer to your question is no.
You may want to look into using Application Request Routing in front of your two servers instead. It does introduce additional server(s) in your configuration but will give you a way to load balance across the sites.
http://www.iis.net/downloads/microsoft/application-request-routing
The answer to this question was custom end points from traffic manager. This will allow Azure to be able to monitor the service for each service or website on a web server within Azure.
I have a azure cloud service (a server) where i host a Redis database. I also have a web site hosted in azure web sites. I want the web site to be able to talk to the Redis DB on port 6379. I know I can configure a public endpoint for that port on my server but that would open it for whole Internet. I want it opened only for azure web sites (or even better, only for my web site). How can i do this?
Windows Azure Web Sites is in an isolation bubble separate from your Cloud Services and there's no way to bridge that gap. Ideally you'd do this by connecting the web site machine to other Azure services via a Virtual Network, but this FAQ confirms you can't do that right now:
Can I use Windows Azure websites with Virtual Network?
No. We do not support websites with virtual networks.
Opening Redis up over the internet shouldn't even be considered as it doesn't have the kind of security you'd want out of the box to be opening up its port publicly as it is meant to be co-located with your application, so you really wouldn't want to do that. Never mind the added network overhead which will eat into the performance you expect to get by leveraging something like Redis anyway.
I believe your best bet given your current configuration is to add a Web Role that's part of the same Azure Cloud Service and run your web based application out of that so that it can communicate with worker role. It only requires a little bit of configuration to get this going (i.e. adding an InternalEndpoint to the Redis Worker Role). While I realize Web Roles don't offer as frictionless a development model as Web Sites, you have to choose the right tool for the job.
Another option, if you want to setup your Redis on a VM instead of tying it to the Cloud Service directly, is that you can setup a Virtual Network, put the Redis VM on the virtual network and then configure the Cloud Service so that it's part of the same affinity group and add the NetworkConfiguration/VirtualNetworkSite configuration section to the Cloud Service's .cscfg.
Which approach makes more sense all depends on how you leverage your Redis instance, but the main benefit of the latter approach is that the Redis instance is not recreated each time you deploy your Cloud Service and, so, any data that's in it will stay available between deployments. Another benefit is if you want to build and leverage a Redis cluster across multiple Cloud Services this enables you to do that.
I'm looking to set up two web roles or websites on my Azure Cloud Service.
The websites need to share the same database schema. I use NHibernate ORM, so I have to make sure that both projects are always using the same data model, or else it will cause major problems.
I've researched setting up multiple websites on a single web role (which seems odd to me, can't I just run multiple web roles, each with a single site)?
http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx
Like any good developer, I use a staging server. If I have to manually set the domain name is configuration files, how will azure know not to be sending people who visit that domain to the staging server?! I.E. If they visit blah.foo.com and I have two deployments (staging and production), is IIS going to be able to know only to send people to the production environment?
Please advise on the best way to go about doing this.
First, you can certainly have multiple web roles, each with a single site; however, each role instance will be deployed to different virtual machines. For example, if you do set up two web roles when you deploy this with one instance each then there are two virtual machines you'll be paying for. If you want the SLA to apply to your deployment you'd need to actually set the instance count to 2 for each web role, which now means you have four virtual machines running. By combining web sites onto the same web role you'll cut down on the number of instances you need to run and still get the SLA; however, that option is not without some considersations. The link you provided is how you can set up multiple websites to run on the same virtual machine when deployed. Note that there are some gotchas with using that method. I'd suggest reading Michael Collier's Tips for Publishing Multiple Sites in a Web Role.
Second, if you do NOT need to have a lot of control over the virtual machine (such as registering special components, etc.) you might want to look at Windows Azure Web Sites as an option. You can elect to take one of the paid levels of Web Sites and still have dedicated machines, but you can deploy the websites separately. I will say though, that your requirement of having both sites in lock step because they share the underlying database schema means that it will be less likely you will want to deploy separate changes, but it is still possible.
Finally, regarding the staging server. If you are testing locally you'll want to modify your hosts file to get the host names to point to your local address. Wade Wegner has a post on Running Multiple Websites in a Windows Azure Web Role. Once you deploy to Windows Azure you'd want to change your hosts file back, or comment them out. If you are using the actual idea of the Staging deployment slot you can use the same trick with the hosts file to point to the IP address of the staging deployment when testing.
We are looking to host a website (some css,js, one html file but not aspx, one generic handler).
We deployed in as:
1) Azure Web Site
2) Azure Cloud Service
Both solutions work. There is a question though: which way of hosting it is better and why? Second thing: as there might be a lot of traffic - which solution would be cheaper?
Thanks in advance,
Krzysztofuncjusz
You may want to review this article that explains the primary differences. Web Sites are best for running web applications that are relatively isolated (that do not require elevated security, remote desktop, network isolation...). Cloud services are more advanced because they give you more control over web sites while still remaining flexible. And VMs are for full control over applications that need to be installed and configured (like running SQL Server for example).
I think that main difference in abilities to modify VM and possibility to configure scalability. Web sites is something like classic hosting, without ability to login by rdp. Cloud Services allows you to configure VM and if necessary setup scalability and availability.