Can i use the Autoscaling Application Block for balancing/scaling the Azure VM role instances?
If this is possible, do i need to include Autoscaling Application Block in the service model definition which is for the virtual machine role?
Thanks a lot.
Yes, you should be able to target VM roles as Wasabi goes through the standard Windows Azure Management API. See the Design of Wasabi section for more info.
WASABi uses standard Diagnostics and Management API which are fully supported by the VM Role. However, if you're not able to get WASABi to work with your VM Role, you can try AzureWatch, a third-party SaaS monitoring & auto-scaling service
No WASABI is not supported for VM Role. It is primarily designed and tested with Web/Worker Roles only. The fact is that if you understood WASABI and plan to use WASABI in VM Role, you might be better of using Web/Worker role instead of using VM Role.
Visit link below for more info:
http://blogs.msdn.com/b/agile/archive/2011/08/23/autoscaling-windows-azure-applications.aspx
Related
Noticed Virtual Network and Virtual Network(Classic) in Azure, Wondering what is the difference between them and when to choose what ?
Azure has two different deployment models for creating and working with resources: Resource Manager and classic.
How you create, configure, and manage your Azure resources is different between these two models. In classic mode, each resource provisioned in Azure is a single management unit. You manage all of the resources individually. The classic mode does not allow grouping of resources, which makes managing Azure resources difficult.
Azure resource management mode adds the concept of the resource group, which is a container for resources that share a common lifecycle. In ARM mode, you can deploy, manage, and monitor all the services for your solution as a group, rather than handling these services individually. Also, you can apply tags to resources to logically organize all the resources in your subscription.
When you interact with Classic mode resources from a command line such as Azure PowerShell, you are using Azure Service Management API calls (ASM). ASM is a traditional way of accessing Azure resources. In the Resource Manager mode, you are using Azure Resource Manager Rest API. When a user sends a request from any of the Azure tools, APIs, or SDKs, Resource Manager receives the request. It authenticates and authorizes the request. Resource Manager sends the request to the Azure service, which takes the requested action. See Azure Resource Manager overview.
The Virtual Network(Classic) is used for the classic models. Virtual Network in Azure is created for Resource Manager models. Currently, Microsoft recommends that you use Resource Manager for all new resources. Mostly, the Virtual Network(Classic) is used when you are creating a VNet for cloud services as far as I can tell. For Resource Manager resources, you just need to create Virtual Network in Azure portal.
There are three scenarios to be aware of:
Cloud Services does not support Resource Manager deployment model.
Virtual machines, storage accounts, and virtual networks support both Resource Manager and classic deployment models.
All other Azure services support Resource Manager
Here is a blog about Azure Classic vs Azure Resource Manager
So which one should I use?
Since both modes are viable options at this point, it is necessary to
pay careful attention to the features that each offer and your
specific requirements. ARM cannot simply be assumed to be the best fit
as it simply may not meet all of your or your customer’s needs.
My understanding so far on PaaS deployment using WebRoles or Worker Roles-
Spinning Web roles or Worker roles will create Cloud service to manage it.
However, in ARM resource group, their is no concept of Cloud service, then how are web & worker roles managed in ARM resource group?
Also I tried adding the webroles via JSON Outline in VS 2015, but no option to add webroles. So not sure if you can deploy webroles via JSON template?
Any information will be of great help.
Cloud Services have been around since the beginning of Azure.
To the deploy or manage them, you have to use the old APIs (Azure Service Management).
As far as I know, they won't be migrated to the new APIs (Azure Resource Manager), but you could use Virtual Machine Scale Sets instead.
Azure Resource Manager Web apps rely on the concept of App Service Plans, rather than cloud services. Basically this is the underlying VM(s) that the service runs on. You can specify the size and number of servers that make up the App Service plan, and then deploy on to those as a single unit.
You create an App service plan, then run web / worker roles inside that (as well as Logic, API, Functions)
As far as Web / Worker roles are concerned, App Service Plans do not draw a distinction between the two. You simply deploy code to it and it will run it however it is packaged. See here
The concept of cloud services simply don't exist within the Azure Resource Management model.
You can find a template for deploying a Web App here
I deployed an Azure Worker Role running OWIN into a Cloud Service for very fast HTTP serving. The Cloud Service exists in the "classic" environment at manage.windowsazure.com.
I would like to deploy the same lightweight application using the new ARM bits so it can be fully managed at portal.azure.com. I don't want to use a Web Application because that includes IIS.
What is the correct Platform-as-a-Service object to use in the ARM and the new portal that gives the same performance as an old Cloud Service Worker Role?
Thanks.
There isn't a Platform-as-a-Service object to use for this in ARM. Some Infrastructure-as-a-Service options are:
Create a regular Windows Azure Resource Manager VM in the new portal and set it up as an OWIN host.
Create an Azure Resource Manager template to deploy an OWIN host to a VM or a VM Scale Set. The template would use the custom script extension and/or DSC to do the setup. This would be a good re-usable solution, but someone would need to write the template for the first time.
The lightest weight solution would be to have the server running in a Docker container on Windows. You could then choose use the VM for other purposes running in other containers or purely as a container host. Note this only runs on only runs on Windows Server 2016 Technical Preview 3. See http://anthonychu.ca/post/web-api-owin-self-host-docker-windows-containers/
Edit -
Note that Service Fabric is the recommended PaaS solution in Azure Resource Manager. It is not a direct equivalent of PaaS v1 but a rich service for developing micro-service based applications: https://azure.microsoft.com/en-us/documentation/services/service-fabric/
Not sure what you mean by V2 (new portal? ARM?). The portal is an independent tool, so I'm guessing you mean ARM. ARM doesn't support Cloud Service deployments currently, but you can still deploy either from Visual Studio (using the same interface you've used in the past, in visual studio) or from the portal, as a "classic" resource (which, underneath, uses the classic Azure management API).
In the portal, you'll find Cloud service (classic):
Now you can add a new cloud service:
And fill out the various parameters:
Microsoft Azure cloud supports three roles Web, Worker and VM with different capabilities to be utilized by application developers.
If I understand correctly when we use Web or Worker role, Azure acts more like PaaS while using VM role puts Azure in IaaS role.
Web, Worker roles has the advantage of OS/Platform being managed by the Fabric Controller (updates to OS etc), where with VM we have to manage those ourselves.
My question is, if we implement a private cloud using solutions provided by Microsoft, Can we still create Web/Worker roles on our private cloud, or is it limited to VM roles?
Cloud Services, which you're describing, are comprised of Web / Worker / VM roles, with Web and Worker OS's maintained by Microsoft and VM Role maintained by you (with multiple instances all based off the baseline image you upload). In all three cases, any type of new image creation is like starting fresh: changes made to the OS while running are not permanently persisted. VM Role does not put Windows Azure into IaaS mode, as the fabric is still using a single baseline image to manage role instances. IaaS, with Virtual Machines, is a bit different, with the Virtual Machines constructable in the cloud (vs. VM Role that requires them to be built locally and then uploaded). Further, any change to a Virtual Machine is persistent. When scaling to multiple instances, you'd need to make VHD copies from your master image, and then each instance would be living on its own (e.g. a change to one Virtual Machine will not show up in the other Virtual Machines).
Having said all that: You have access to Cloud Services (web/worker/vm role) only in Windows Azure today; there's no way to run these locally.
Recently we announced the availability of Windows Azure services for Windows Server. You'll see that there is a subset of Windows Azure features runnable on Windows Server:
Web Sites
Virtual Machines
Service Management Portal and API
The answer is not yet. WebRole and WorkerRole PAAS are relying on Azure Fabric Controller and that thing does not yet run on premise outside of Microsoft's control, as far as I know.
Yea as far as I'm aware you can, I haven't tried it myself, you need to create a VNET and then create your Cloud Services within your VNET, Michael Washam has a good post detailing it: Connecting Web or Worker Roles to a Simple Virtual Network in Windows Azure
How can we configure VM Role on Azure Emulator? Is this possible or do i need to do my testing on Windows Azure Management Portal.
Thanks,
Mrinal Jaiswal
On Azure F&Q its written that Emulator supports VM role but to much dismay it doesn't. I talked to Microsoft Tech team and got this answer.
One good thing they told me was, if i want to use VM on Azure it will be better if i use extra-small deployment it will increase my compute hours and i can host 2 extra-small VM role on azure in free trail account.