Is there an equivalent functionality in Azure like AWS Auto Scaling Group or GCP Instance Group? All I can find is Azure Virtual Machine Scale Set which always uses load balancer. The closest resource I found is Azure Automation Runbook which a bit more complex for my use case.
I just need to spin up virtual machines based on current vm's health threshold and/or to use it for vertical scaling by simply change the instance type.
You can create an Azure VMSS without a loadbalancer, you may need to assign a pubic IP addresses to your VM which is now available. In your case it sounds like you just want 1 node in the VMSS so you can use AutoScale.
https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-networking#public-ipv4-per-virtual-machine
The equivalent Azure service for AWS Auto Scaling Group or GCP Instance Group is Azure Autoscale.
I'll provide some basic overview on Azure's Autoscale taken from here.
Azure Autoscale supports the most common scaling scenarios based on a
schedule and, optionally, triggered scaling operations based on
runtime metrics (such as processor utilization, queue length, or
built-in and custom counters). You can configure simple autoscaling
policies for a solution quickly and easily by using the Azure portal.
For more detailed control, you can make use of the Azure Service
Management REST API or the Azure Resource Manager REST API. The Azure
Monitoring Service Management Library and the Microsoft Insights
Library (in preview) are SDKs that allow collecting metrics from
different resources, and perform autoscaling by making use of the REST
APIs. For resources where Azure Resource Manager support isn't
available, or if you are using Azure Cloud Services, the Service
Management REST API can be used for autoscaling. In all other cases,
use Azure Resource Manager.
The mentioned article is a great resource.
It also provides information about:
Types of scaling (Vertical Vs Horizontal).
Configure autoscaling for an Azure solution.
How to use Azure Autoscale.
Application design considerations for implementing autoscaling.
Check out also this resource on How to auto scale a cloud service.
Related
The scenario is as follows:
In company premise, there is a network that consists few machines.
The company has an Azure subscription.
Requirement:
To monitor the company's Network/Machines via Azure
If the company resource goes beyond a threshold limit then trigger alerts. Example, network bandwidth consumption, machine CPU/Memory usage, etc.
When such alerts occur then spin up new virtual machines or VM scale sets in Azure to handle the load.
The purpose is if the machines in on-prem goes above threshold limit then automatically provision VMs in Azure, as there are only few on-prem machines.
Please guide how to implement these use cases?
your question is a little confusing. You mention machines on premises and using Azure to monitor them. You can monitor on premises VMs using Azure but then you mention provisioning new Azure VMs via Scale Sets.
I'm not 100% where your workload is but assuming it is in Azure then if you are using VM Scale Sets it's very easy to scale in and out based on resource utilisation.
This can be configured as described here: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-autoscale-portal
Out of the box, Azure Advisor includes Cost recommendations for the resource type of Virtual Machines, based on resource utilization.
If I look at them under our subscription they have the following information:
Is there any way to get similar advisory for the Virtual Machine Scale Set resource type? Is there any included out of the box?
Or if I want to get average resource consumption, of let's say CPU percentage of all or individual Virtual Machine instances inside of a Virtual Machine Scale set, to be able to aid in the decision if the SKU of the Virtual Machine Scale Set is appropriate, I need to make a query for this inside of Monitor Logs or similar?
Could one create their own custom made advisories (inside of Azure Advisor, if not - anywhere else?), to get this functionaltiy in place (if it isn't already provided)?
Thanks!
Is there any way to get similar advisory for the Virtual Machine Scale Set resource type? Is there any included out of the box?
As per the Azure Advisor documentation, Advisor provides recommendations for the following resource types:
Application Gateway, App Services, availability sets, Azure Cache, Azure Data Factory, Azure Database for MySQL, Azure Database for PostgreSQL, Azure Database for MariaDB, Azure ExpressRoute, Azure Cosmos DB, Azure public IP addresses, Azure Synapse Analytics, SQL servers, storage accounts, Traffic Manager profiles, and Virtual machines.
Although Azure Advisor also includes your recommendations from Azure Security Center which may include recommendations for additional resource types, this list does not cover cost recommendations for VMSS as of today, AFAIK.
I need to make a query for this inside of Monitor Logs or similar?
To monitor your Virtual machine Scale sets, you can leverage Azure Monitor. The performance views in the VM Insights feature are powered using log analytics queries, offering “Top N”, aggregate, and list views to quickly find outliers or issues in your scale set based on guest level metrics for CPU, available memory, bytes sent and received, and logical disk space used.
You can also deploy the Azure Monitor Application Insights Agent on Azure virtual machine scale sets to enable monitoring for your .NET or Java based web applications and get all the benefits of using Application Insights without modifying your code.
Could one create their own custom made advisories (inside of Azure Advisor, if not - anywhere else?), to get this functionaltiy in place (if it isn't already provided)?
Nope, that is not doable as of today. Azure Advisor is a managed offering that analyzes your resource configuration and usage telemetry and then recommends solutions that can help you optimize your Azure resources. Feel free to share your feedback and ideas here for the Advisor team to evaluate and prioritize.
How does a Azure function differ from a ASP.NET Core Worker Service?
Does both of these cover the same use cases?
How do I decide which one to use?
Update:
Azure function is designed for azure. So when you use azure, or other azure services which are integrated with azure function, you should consider azure function, which could simplify your code and logic by the built-in features of azure function. But it will also have charges for azure function. And yes, if you don't use azure, just use asp.net core worker services.
Azure function are totally different from ASP.NET Core Worker Service.
The benefit of Azure function is that it supports a lot of triggers like azure blob trigger / azure event hub trigger, and is integrated with other azure services.
With these built-in features, it's easy to create a proper azure function to complete a proper task. For example, if you upload an image to azure blob storage, and then want to resize the image, you can easily create a blob trigger azure function with less code.
Worker services are the perfect use case for any background processing. And if you want to operation some azure services like azure blob / azure event hub etc. you may achieve this but need to do a lot of work.
At last, it depends on your use case to choose which one should be used, and select the simple / efficient one.
I think the answer Fred was looking for is, why would someone use Azure functions over Asp.net Core hosted service? And the answer isn't only because you have Azure account so everything is easy and integrated. It depends. I.e Traffic, cost, expertise, etc.
Actually, there are guidelines set by Microsoft when to use an Azure Functions versus let's say over a IHosted service running in a linux container hosted in AKS for example. and I'll post the link, but it's basically if your workload is mission critical or not. If you want the best performance, lowest cost, reliability a hosted dotnet core service running in Linux container would be an excellent alternative.
Here is the mission critical guidelines from Microsoft, hope this helps!
Design recommendations
Azure Functions:
Consider Azure Functions for simple business process scenarios which don't have the same stringent business requirements as business-critical system flows.
Low-critical scenarios can also be hosted as separate containers within AKS to drive consistency, provided affinity and anti-affinity requirements are fully considered when collocating containers on nodes.
Excerpt taken from here:
https://learn.microsoft.com/en-us/azure/architecture/framework/mission-critical/mission-critical-application-platform
We have an application built of multiple Logic Apps. We will use Azure API Management to consolidate all those endpoints into a single endpoint.
We need this application to be highly available, so we want to deploy it to 2 regions (eg West Europe and North Europe).
As of Nov 2018, the only API Management plan that supports multi-region is the Premium plan that costs 18x the Basic plan. The Premium plan is way out of our budget.
We had the idea to setup two Basic API Management units, one for each region, having both configurations synchronized, and placing a Traffic Manager in front of both.
Assuming that we will only use the gateway functionality of API Management (not developer/publisher portal, authentication etc), what will we be missing with our "Poor Man's Multi Region" solution instead of going with the "native" multi-region of the Premium plan?
Whatever you will have to build will be missing (as you pointed out):
Configuration synchronization - you will have to make sure that configuration is synchronized between multiple services.
Traffic Manager - you will have to have TM or something else on top of services to reroute traffic in case of DR.
Scale and everything else from this list: https://azure.microsoft.com/en-us/pricing/details/api-management/
It is possible to create multi region DR of Azure API Management in Developer/ Basic/ Standard tier.
High level steps -
Create two API Management in Standard mode. One in primary region and other in secondary region.
Configure APIs and related backend in API Management primary. As you API Management standard is not part of VNET, the backend APIs will require public IP to get imported in API Management.
Create Azure AD Application to have necessary permission to make changes in API Management instances in cross region.
Allow rights on resource groups of both API Management in two regions.
Create two logic apps. One to create backup of primary API Management. Second will be used to restore the same backup in secondary region API Management.
Create traffic manager and add API Management IP address/ domains names as endpoint profiles. Configure Traffic manager in Failover/ Priority mode.
Configure status page of API Management in Traffic manager to know health status of API Management for traffic manager so that it can switch to secondary region in case of DR situation.
Is there a way do do dynamic elasticity in Windows Azure? If my workers begin to get overloaded, or queues start to get too full, or too many workers have no work to do, is there a way to dynamically add or remove workers through code or is that just done manually (requires human intervention) right now? Does anyone know of any plans to add that if its not currently available?
Microsoft shipped the Autoscaling Application Block (Wasabi) to provide dynamic scaling. Some of the supported scenarios:
Autoscaling both web and worker roles in Windows Azure by dynamically changing instance counts or performing application throttling.
Autoscaling Windows Azure roles based on timetables.
Autoscaling Windows Azure roles based on metrics collected from the application and/or Windows Azure but constrained by upper and lower bounds on the instance count per role.
Preventing fast oscillations in the number of role instances with the stabilizer. The stabilizer can also help to optimize costs by limiting scaling up operations to the beginning of the hour and scaling down operations to the end of the hour.
Monitoring and logging autoscaling activity.
Sending notifications to preview any scaling operations before they take place.
Encrypting the rules and other configuration in Windows Azure blob storage or in local file storage.
Managing the autoscaler configuration by using Windows PowerShell.
A comprehensie sample application (Tailspin Surveys) showcasing all these features is provided (installation instructions are available here). Also, check out the Developer's Guide and the Channel9 video walkthrough.
The block is available as standalone download of binaries, source or via NuGet.
Here are a couple of talks/demos showing Wasabi in action:
CloudCover Episode on autoscaling
p&p symposium talk "Windows Azure app scaling to need"
There's a Service Management API, and you can use that to scale your application (from code running in Windows Azure or from code running outside of Windows Azure).
http://msdn.microsoft.com/en-us/library/ee460799.aspx and http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=windowsazuresamples&ReleaseId=3233.
Windows Azure has just added the autoscaling feature built into the platform. Now it's trivially easy to configure your autoscaling rules right in the management portal:
See the announcement and the demo. I've also written a post comparing Windows Azure Autoscale to Wasabi and outlining the path forward.
Create a queue named autoscale.[your_role_name].instance_count
In the Management Portal, set the autoscale to Queue.
Set the Target Count field to 1.
Now you can use standard enqueue and dequeue operations on that queue to control the number of worker role instances. You've got 7 days to process a message before it expires, so you might want to create a worker role that can ensure that the number of messages in the queue is tracking your target instance count.
If you're after dynamic elasticity, you've probably already got a worker-role-based controller in mind already, so that's probably not a problem.
Lokad.Cloud open source project for Windows Azure contains distributed executor framework. Among other things it provides auto-scaling with VM provisioning feature.