As a result of the current global health crisis, the Global Azure events have moved entirely online. Spread over three days (23rd-25th April) it promises to be an amazing mix of content from contributors from all corners of the world.
Azure ExpressRoute is Microsoft’s recommended method of accessing resources in Azure over a private connection. It is unique to the platform and can offer unparalleled resilience and performance. It also has the capability to allow you connect to Azure Public Resources, such as Storage Accounts, Azure SQL, over the same circuit and therefore, private connection.
With the above being possible, it’s clear that ExpressRoute, once implemented, becomes the key resource in your environment. As such, you would be wise to implement some level of monitoring and alerting for it.
Here, I’m going to show you how to very quickly put in place alerts should either of the required BGP sessions drop for your ExpressRoute circuit.
To add some context to that, each ExpressRoute circuit requires a pair of BGP sessions to meet SLA requirements. They will function with just one, but that’s not fully supported and definitely not recommended! So, presuming you have both active, we’ll base our alert off of that metric. We’re going to look specifically at Private Peering as it’s the most common implementation, but the logic is identical for Microsoft Peering.
If both are active and configured correctly, you should see the same routes being advertised within the circuit if you check your route table from the Peering blade
Next, let’s look at the Metric we will be using for the alert. In your ExpressRoute Circuit blade, choose Metrics. Then we’ll choose the ‘BGP Availability’ Metric and ensure Aggregation is ‘Avg’
Next, to future proof the alert, or if you have a Microsoft Peering, we’re going to apply some filtering. So choose ‘Add filter’ (highlighted above). Then we’re going to select the ‘Peering Type’ Property, and choose ‘private’ from the Values drop down and click the tiny blue tick to the right (You won’t see Microsoft if you don’t have one, but do this anyway to ensure your alert is tightly scoped).
Now, we’re looking at the average BGP availability, for our Private Peering only.
To make life easier, you can now just click ‘New Alert Rule’ on the top right to use this scoped metric for your alert.
This applies the right resource scope and brings the metric across too, you now just have to configure some of the required choices on specifics.
First up, let’s confirm the condition and signal logic. Click on the blue text under Condition. You will see Private is already selected for you. I’m going to change Operator to ‘less than or equal to’ and add a value of 95.
The above settings mean that the BGP Availability metric for my private peering, over the last 5 minutes, will be assessed every minute. Should it drop below or equal to 95%, an alert will fire. You can adjust this as needed to suit your own environment.
Now, we need to define what happens when they alert fires. Click Done on the signal logic pop out, this will bring you back to the alert configuration blade.
Next, define the final details for the alert. Use a descriptive name and the appropriate severity for your environment/system.
Now, the alert itself can take some time to become fully active, so I would recommend waiting about thirty minutes before attempting a test. But, please ensure you test the alert!
And that’s it. Once tested, you have now setup a fully scoped alert rule for your ExpressRoute Private Peering. You can repeat the above, and change the scope to Microsoft Peering to cover that too if you have it.
As always, if there are any questions, get in touch!
At Ignite 2019, Microsoft announced a new service; Azure Arc. It allows you to extend the capabilities of Azure to your on-prem environment, multi-cloud and edge. At launch, it’s only Azure Arc for Servers, but there will also be an option for data services at a later date. Everything is in public preview for now, so careful with those production environments!
Azure Arc for Servers
The basic concept is that with Azure Arc you can manage machines which are outside of Azure. Once connected, a non-Azure VM becomes a Connected Machine resource in Azure. Connected Machines have a Resource ID, and are manageable using the normally supported components such as Policy and Tags.
To register a Connected Machine, an agent needs to be installed on each local VM. The currently supported OS’ are 2012R2 or newer and Ubuntu 16.04 and 18.04. As Connected Machines are an Azure resource, normal resource limits apply (800 resources per RG etc).
The agent has some network requirements, documented here. For onboarding the agent is combined with a script. This process can be done via the Portal or Powershell. Recommendation here would be to follow the option to create a Service Principal if you need to onboard machines at scale.
You will also need to enable a couple of new resource providers in your Azure subcription:
Once you have a VM present in Azure as a Connected Machine, you can start managing it, but only using the following services at this time of the preview:
So for now, the service is quite limited. But you can assume that many more features are on the roadmap. The end goal of Azure Arc is to give you a single tool set to manage all your servers and data services regardless of where they are provisioned. So whether you’re a small company with a hybrid footprint, or an MSP, Azure Arc could make your life a lot easier. One to keep an eye on for GA in 2020!
If you’ve worked with Azure for a while, you would know that one of the most efficient methods of deployment is ARM templates and one of the most powerful services is Azure Policy. What you might not know, is that you can combine the two for efficient, iterative and defined deployments.
A great point I saw recently on Twitter was that a lot of technical posts highlight features and how to use them but rarely go into why you should use them. Conscious of that, here are a couple of points on why I think you should make use of Policy via Template (PvT):
Quick deployment time – hilariously quick.
Repeatable defined structures – the exact policy definition, applied to the exact scope, with no possibility of user error.
Confident flexibility – Templates are idempotent; need to update the definition? Update the template, deploy the update, job done.
So if the “why” makes sense to you, let’s move onto the “how”. If it doesn’t, let me know! I’d love to hear your horror stories/use cases…
Templates can be deployed in several ways, for the sake of simplicity, I’m going to use two tools here. Visual Studio Code and Powershell. Currently you can only deploy subscription scope resources via Powershell or CLI.
There are some other differences to note. The schema for the template must be:
When deploying the template, it must be deployed to a location and given a name (the name of the template will be used if none is specified), that combination is then immutable for that location. So if you need to change location, you need to use a new name etc.
Now, let’s create our template. For this post, I am going to use an existing Template Definition and scope it to my Subscription. While you can pass the Template Parameters via Powershell Variable, for this post I am going to define them as a Template Variable. This is tricky piece of logic as they must be defined as a nested, object array. I also define the policyID via Variable. For existing definitions, you can get this via the Portal, or Powershell command
You should receive a succeeded message within your shell and you can verify via the Portal. As it was a subscription level deployment, head to your Subscription blade and check the Deployments tab. You should see the Template listed as the same name as you ran for the deployment.
You can then confirm your settings via heading to Azure Policy and the Assignments blade. You will see your Policy Definition assigned at the scope you set, using the Parameters you set.
Just to go back to an early point on why you’d use this option. Look at the duration of the deployment in the above screengrab – 1 second. You simply cannot beat that!
This can obviously be used for much more complex deployments, for example, defining your own policy inline and deploying via template. The possibilities are endless with one current exception; Subscription is highest scope you can currently use, hopefully Management Groups are on the roadmap and therefore the scaling capability is excellent.
As always, if there are any questions or suggestions, please get in touch!
When working with Azure, as with many cloud based services, one of the difficulties you may have to deal with is naming standards. Common sense would lead you to applying a single naming convention to all resources. However, in Azure, as the name of the resource can actually be used for many different things, one single convention is quite difficult to achieve. Especially if your convention requires any real degree of complexity.
The most simple reason for having a good naming convention? You cannot rename resources in Azure.
This somewhat explains itself. However there are technical justifications too. For example, a Windows VM name has a maximum character limit of 15. Keeping it simple allows you to re-use the same logic regardless of resource type, location or service.
Affix some affixes
Where possible, make use of a prefix or a suffix to add clarity to your resource names. the most common are based on environment (prod, dev, test) or instance (A, B, C or 01, 02, 03).
Depending on whether your environment is brand new, or you’re trying to implement some control on an existing environment; applying your naming convention via Policy can speed things up. You can choose all of the usual options when it comes to policy, my preferred method is to create several policies scoped to resource types that deny deployment if naming convention doesn’t match. This avoids conflicts with any auto-deployed resources. Then a catch all policy to audit everything for compliance. An example policy for VMs is below:
This checks all of the fields listed, so for Virtual Machines, where Name is Not a Match for “az-????-##” then Deny. The match pattern is defined using standard Azure Policy conditions.
Tags can form a one to many relationship for resources. Tagging all resources that are part of a project, or have a commonality adds additional metadata to resources without adding increased complexity to your naming convention. Tagging should be viewed as a complimentary option to a good naming convention rather than an alternative. They can also be applied via Policy, saving you time and effort!
As always if there are any questions, or suggestions on how you do naming in Azure, get in touch and I’ll add them to this post!