There is an application developed using Kentico 10 and hosted in Azure.
We recently install azure application gateway for this particular site,
In this site there is a function to add and view items to shopping cart.
So after installing the application gateway, the add and view items to shopping cart function won't work properly, Most of the time added items won't display when go to the view cart so its happening randomly, I suspect this is due to some issue on session state synchronization.
Our site URL is map to gateway and from there its goes to a application, and we do not have web farm as well, and session State mode is "InProc"
Since Azure Application Gateway is a web traffic load balancer
1- Does it required to setup a webfarm since we have azure application gateway?
2- Do i need to use "StateServer", "SQLServer" or "Custom" (e.g. Azure Redis Cache) since we have azure application gateway?
As long as you do not have multiple application connecting to same database, Web Farms are not necessary. However shopping cart is saved in session, cookie and DB and first point of retrieval would be session. Since azure app gateway has its session affinity you could try using that.
In case this does not help, you will need to use other storage (I believe redis cache to be the fastest), but point would be to better tie user with session.
Related
I have a website which is developed using Kentico 10 and hosted on Azure.
It has Azure Application gateway, scaled out to 2 instances and webfarms are also enabled. Its using Azure Redis cache as well
Today I disabled ARRAffinity in the app service (via Azure Portal) and kept Cookies based affinity enabled in the application gateway.
Still, I can see the app is consuming the Redis cache however when I add an item to shopping cart and then click on the view cart it shows the empty shopping cart (randomly) where our shopping cart is stored in a session.
So I believe this is something related to sticky session issue even with the Redis cache.
Since I've disabled the ARRAffinity in the app service does is it required to disable the Cookies based affinity from the app gateway-> https settings?
If not, anything I've missed?
If you are using an App Service and scaling out to 2 instances the Application gateway does not provide load balancing capabilities.
The load balancing is being handled by the app service. If you wanting to control that a traffic manager profile might help.
So you would still need to leave ARR on in the app service.
How can I maintain users to get redirected to the same Server in a Load-Balanced Web Apps
Your answer will be very helpful
Traffic Manager directs the user to the appropriate region, but assuming you have your web app scaled out to at least two instances, ARR (Application Request Routing) is what directs each request to a specific instance of the app.
ARR has a feature called Session Affinity which is enabled by default. It uses an ARRAffinity cookie to attempt to route all requests from a client to the same instance of your application. I say "attempt" because, the cloud being what it is, instances of your app can come and go due to autoscaling or maintenance activities.
Your best bet is to use Azure Traffic manager. When setup correctly it will route users to the proper cloud service in their region and provide them with the best possible experience.
More information can be found here
Azure Traffic Manager
Azure Traffic Manager Documentation
Traffic Routing Methods
I have a custom domain www.abc.com configured for web app webapp-a, and I'd like to transfer it to webapp-b without downtime.
If I try to add the domain to webapp-b, I am getting
The host name www.abc.com is already assigned to another Azure website: webapp-a
It there a way to let webapp-a continues to serve the requests, until the DNS cache expires?
Edit: The domain has IP based SSL binding, and the DNS is caching the virtual IP.
I faced the same issue, and was able to solve it in a tricky way.
I created new App Service Plan (previously known as Web Hosting Plan), and assigned "new" Web App to it (you can do it via new portal, or you can create Service Plan during Web App creation).
Then, I was able to assign the same host name to Web Apps in different hosting plans.
Thinking about this, I feel it logical: most probably Service Plan is mapped to physical IIS machine, and you cannot have two sites with the same host name in the same IIS for the obvious reason.
After migration from one DNS to another is done, you can remove unused Service Plan (as you basically pay for each separately).
According to a blog post by the Azure App Service Team in June 2017, it would appear that Azure now supports adding the same custom domain to multiple web apps:
There are scenarios where a customer would like to add the same hostname to multiple web apps in the same subscription, having a geo distributed website is one example. Our custom hostname feature allows you to bypass validation for hostnames that have already been validated. You only need to verify domain ownership when you add a hostname for the first time. For all other apps in the same subscription, you can add the same hostname without creating any DNS records.
You can read the entire blog post at https://blogs.msdn.microsoft.com/appserviceteam/2017/06/21/custom-hostnames-with-app-service/. The quote above was taken from the Adding the same custom hostname to multiple web apps section.
This should help in scenarios such as this where you want to transfer a custom domain name from one web app to another. You can simply add the same custom domain name to both web apps, add any required SSL bindings, and then change the DNS to point to the new web app. As the DNS change propagates, traffic should gradually move over to the new web app without any downtime.
I've tested this myself in the North Europe region and had no problems. Both web apps were in different App Service Plans. I have not tested this scenario with both web apps in the same App Service Plan. Bear in mind that if you're using IP addresses/A records in your DNS, you'd need both web apps to have different IP addresses for the DNS to be able to differentiate between your web apps.
Try assigning the domain to Azure Traffic Manager and have the traffic manager forward the request to the second site. Azure Traffic Manager and Web Apps are two different systems so you might be able to assign the same domain name to a web app and a traffic manager.
Once the DNS cache has expired remove the domain from the old Azure web app and add it to the new one, then finally delete the Traffic Manager account.
Option 2
Set the TTL to something very small, say 5 seconds (I believe your hostname provider should let you set that up), wait for the new TTL to propagate through all the caches. Then switch the custom domain from one app to another, and set the TTL back to it's original value.
This will result in just a few seconds of downtime for any customers, but if you do it at a low-traffic time the effect shouldn't be too bad.
I'm planning an application that has a mobile app as a front end (and perhaps a web front end also that performs a different purpose). Something like Runkeeper, or Runtastic, if you're familiar with those apps. The mobile device is the primary method of user interaction, and the web site has stats and dashboards that the users can view afterwards.
I would like the main application to reside in Windows Azure. I'm confused about how to architect the application though - should the business logic reside in a web role, or a worker role? If the main user interface is a mobile app, does it connect to the worker role to persist or retrieve data, or to a web role, or neither? I understand a typical scenario where a web role provides a user interface which can persist data directly to storage or pass data to queues or tables to be picked up by worker roles, but the presence of the mobile app throws me off.
Any help? Thanks!
Andy's answer is great, but let me add a different flavor. The only difference between a web role and a worker role is that the web role automatically has IIS turned on and configured. A good rule of thumb is that if you want IIS, use a web role. If you don't want IIS, use a worker role.
For hosting a server component for mobile apps to connect to, I think the simplest thing that would work would be a web role hosting an ASP.NET web application. Web applications can be used for services as well as web front end (HTML) web sites.
ASP.NET MVC and Web API make setting up web services really easy, and it's easy to work with non-HTML data formats, such as JSON or XML. Your mobile app could communicate with the web app using a REST JSON API, or you could use XML/SOAP if you wanted to, or whatever format you want. REST APIs with JSON as the transfer format is probably the most popular at the moment. One way to think about a web app is that it's just a way to send and recieve data from clients. If the client is a web browser, you can serve up your content as HTML pages, or if your client is a mobile app, you can serve up your data as JSON and let the client display it however it needs to. Basically, your web app can be both your web site (HTML), and your "API" for non-web-browser clients.
You can think of worker roles sort of like Windows Services. They are primarily used for doing back-end processing, and things like that. A worker role might provide some capability to host a public facing API, but you would have to manage connections, message pipelines, recycling, and all that yourself; whereas, a web role would have a web server (IIS) provided for you to manage connections, etc. If you are going to introduce things like message queues, it would make sense to have the public facing API be a web role, and the message processing component a worker role. The web app could receive the message from the client via a REST JSON API, and then pass the message off to a queue, where the worker role picks it up. Introducing queues and worker roles makes sense if you have heavy-duty server-side business logic that can be processed in the background without impacting the client.
just starting to explore Azure and I am still a bit confused regarding the purposes of web roles vs worker roles. In the solution I'm working on mobile apps (iPhone, Android, Windows etc) will be accessing our server product via a REST api. So there is really no public facing web site for our service (as in web pages).
This made me think that I don't need a web role but instead have one or worker roles listening on our http endpoints. I have created a prototype along these lines. When from a mobile device I do I an http post to the endpoint, I get no response back. And I see nothing in the Azure logs that indicate that indeed my worker role was started or is running and responding to it.
Is this an appropriate approach? Is there something I need to do in setup code because I don't have a web role? I read in another thread that web roles run in IIS but worker roles don't.
Thanks for bearing with me. I am still getting to grips with Azure and so have a little difficulty formulating the right question.
You don't need to have a web role in your azure deployment. As you read, a web role has IIS, and your web site is hosted in it. A worker role is basically a plain old W2K8 server without IIS. Honestly, I haven't RDP'd to a worker role instance, so I'm not 100% sure that you don't have IIS or not.
But you don't need a web role in order to expose a WCF service. Here's a nice example (although the background color needs some work) that shows you how to do this.
Good luck! I hope this helps.
Adding to what David Hoerster said: You can host up to 25 externally-facing endpoints (each with its own port number) on any role type, with each endpoint being http, https, or tcp. With a Web Role and IIS, a web application typically grabs an endpoint mapped to port 80. In your case, you'll be creating your own endpoints on your specific ports. You're responsible for creating your ServiceHost (or whatever you're using to host your service) and binding it to one of your endpoints. To do this, you'll need to either map each endpoint explicitly to a specific internally-facing port, or inspect the endpoint's properties to discover which port has been dynamically assigned to it, for you to bind to (might this be the issue you're running into with your prototype code?).
If you're looking for the benefits IIS offers when hosting your endpoint, you're better off with a Web Role, as it's going to be much easier for you to do this since a Web Role enables IIS by default (and it's easy to add WCF services to a Web Role from Visual Studio).
Even if you were to self-host your endpoints, you could still use a Web Role, but now you'd be carrying the extra memory baggage of a running, yet unused, IIS service.