What is Azure B-Series Compute?

images

Back in 2017, Microsoft announced the introduction of B-Series compute. Since then, the service offering hasn’t changed a huge amount but it is one of the most consistently misunderstood VM SKUs available.

Part of this is how they are displayed on the portal. Classed alongside the D series as “General purpose” but with a much more attractive price point, the B-Series appears to be a winner for all your workloads.

B and D series in VM size selector

Comparing a B2ms and a D2s_V3, there is a clear saving oper month regardless of your consumption offer. You can see they have the same amount of vCPU and RAM. Which is the most common deciding factor when sizing a VM. However, the B-Series has some unique features.

The B-series VMs are designed to offer “burstable” performance. They leverage flexible CPU usage, suitable for workloads that will run for a long time using as small a fraction of the CPU performance as possible and then spike to needing the full performance of the CPU due to incoming traffic or required work.

There are currently 10 different SKUs available, although not in all regions. yet. I’ve listed the current specs as available below:

SizevCPUMemory: GiBTemp storage (SSD) GiBBase CPU Perf of VMMax CPU Perf of VMInitial CreditsCredits banked / hourMax Banked Credits
Standard_B1ls110.545%100%30372
Standard_B1s11410%100%306144
Standard_B1ms12420%100%3012288
Standard_B2s24840%200%6024576
Standard_B2ms281660%200%6036864
Standard_B4ms4163290%400%120541296
Standard_B8ms83264135%800%240811944
Standard_B12ms 124896202%1200%3601212909
Standard_B16ms 1664128270%1600%4801623888
Standard_B20ms 2080160337%2000%6002034860

So the the ability to burst sounds great for certain workloads, however, it obviously isn’t unlimited. While B-Series VMs are running in the low-points and not fully utilizing the baseline performance of the CPU, your VM instance builds up credits. When the VM has accumulated enough credit, you can burst your usage, up to 100% of the vCPU for the period of time when your application requires the higher CPU performance.

Here is a great example from Microsoft Docs of how credits are accumulated and spent.

I deploy a VM using the B1ms size for my application. This size allows my application to use up to 20% of a vCPU as my baseline, which is .2 credits per minute I can use or bank.

My application is busy at the beginning and end of my employees work day, between 7:00-9:00 AM and 4:00 – 6:00PM. During the other 20 hours of the day, my application is typically at idle, only using 10% of the vCPU. For the non-peak hours I earn 0.2 credits per minute but only consume 0.l credits per minute, so my VM will bank .1 x 60 = 6 credits per hour. For the 20 hours that I am off-peak, I will bank 120 credits.

During peak hours my application averages 60% vCPU utilization, I still earn 0.2 credits per minute but I consume 0.6 credits per minute, for a net cost of .4 credits a minute or .4 x 60 = 24 credits per hour. I have 4 hours per day of peak usage, so it costs 4 x 24 = 96 credits for my peak usage.

If I take the 120 credits I earned off-peak and subtract the 96 credits I used for my peak times, I bank an additional 24 credits per day that I can use for other bursts of activity.”

So, there was quite a bit of maths there, what are the important points?

  • Baseline vCPU performance – This dictates your earn/spend threshold so if current vCPU is under the baseline you’re increasing your credits. If it’s over, your decreasing them. If it’s the same, you will earn and spend credits at an equal rate with no change to credit balance.
  • Peak utilisation consumption – If this is not allowing you to bank credits, you will eventually end up in a situation where you cannot burst so you might need to size up your VM.
  • Automation – Doesn’t work here, you only earn credits when the VM is allocated. Re-allocating your VM will cause you to lose your credits banked and start again from the starting allocation.
  • Starter Credit – You are allocated a starting credit which is (30 x “number of cores”)

You can monitor your credit spend and usage via Azure Monitor using specific Credit metrics. This will allow you to fire metric alerts relative to your VM. Very handy if you want to make sure you’re not pushing the performance consistently by mistake and therefore burning credits accidentally.

B-series compute, once understood correctly, is a great option to maximise cost efficiency in your environment. Once you’ve mastered the different approach required, you can make significant savings with relatively little effort.

There is a Q&A on some common topics here.

Windows Virtual Desktop – First Thoughts – Part 2

A few weeks ago, I published the first part of this post, get to it here.

In the first part, I wrote about the initial setup and config experience for creating and accessing Windows Virtual Desktop (WVD). Overall, I found the experience to be good, but at times, slightly basic. This is to be expected with a brand new service that is in preview, but for the second part of this post, I wanted to explore the more advanced options of configuration that are currently available.

So in this post, I am going to discuss the following:

  • fslogix profiles
  • Load balancing
  • Depolying using a custom image
  • Availabiltiy/configuration of SSO

Starting with fslogix, I think it’s kinda cool that you are given a free license as part of WVD to use the service. The actual install was quick and easy, download the client, run it, set up two reg keys, done. However, I wasn’t overly familiar with fslogix and as such thought it wasn’t working and I have a solid background in desktop virtualisation, so I understand profile redirection explicitly. I found the Microsoft docs for this are light currently, but clicking through to the fslogix docs I spotted the issue, the local profile cannot exist first or fslogix will ignore it. A quick tidy up and my profiles were redirecting, loading quickly and generally behaving as expected. So far so good, I’d like to see how it scales with a tonne of users, but the expectation is similar performance to Citrix UPM. One thing that is perhaps a bit annoying out of the box is, when you choose signout from the web client, it simply disconnects the user from an app group, this can be fixed with some Group Policy, but I would expect sign out to mean sign out.

A little tip, check out the reg key “FlipFlopProfileDirectoryName” for a quick way to make finding your user profiles within your file share a bit easier. There are also more advanced options like “SIDDirNamePattern”, more here.

Next up is load balancing the session hosts. This obviously only applies to non-persistent session hosts, as the persitent relationship is 1:1. You also need to understand two concepts:

  • Breadth-first
    • This distributes sessions evenly across all session hosts, a max session limit is optional.
  • Depth-first
    • This fills up a session host first before distributing sessions, a max session limit is required.

Both options are simple to setup via powershell and behave exactly as outlined. Instructions here.

Third, I created a new host pool. To do this I first needed a custom image. So I deployed a VM to Azure to convert later. I skipped a bit here by using the new W10 image with 365 proplus preinstalled for you, very handy. However, I then realised this wasn’t the multi-user version and even though all is good with image creation, it fails when trying to register with WVD (30 mins later…) So to save you some time, just use the W10 multi-user image instead! I installed my apps, then I made the following changes:

  • fslogix installed and enabled
  • configured session timeout policies
  • Additional language pack and region settings

Once I had this done, to get your custom image, follow the usual docs here.

Then, you can simply specify it as part of the same steps you followed previously to deploy as a host pool

Once your new host pool is deployed, you need to assign users, don’t forget you currently can’t assign a user to more than one App Group at any one time. So I removed one of my test users from it’s previous group and added it to the new one.

Once logged in, everything is as expected. Profiles, custom settings and my newly added apps. For my own terrible fun I added a special app, yes, I’, sorry, that is Windows 95 running in the HTML5 client on WVD!

Windows95 running via HTML5 client on Windows Virtual Desktop

One tip that could save you some time is relevant to SSO. You may notice that when signing in and launching and app/desktop you are prompted for credentials twice. This is the current expected experience. In the comments on docs, I spotted the following response from the program group:

So we’ll just have to wait and see how good/bad SSO functionality will be once released!

If you have any questions or would like to see a third part to this series, let me know!

Windows Virtual Desktop – First Thoughts – Part 1

Last week, Microsoft released Windows Virtual Desktop (WVD) to the public in preview. The service was first announced back at Ignite 2018. Microsoft describe the service as follows:

Windows Virtual Desktop is a desktop and app virtualization service that runs on the cloud.

Here’s what you can do when you run Windows Virtual Desktop on Azure:

  • Set up a multi-session Windows 10 deployment that delivers a full Windows 10 with scalability
  • Virtualize Office 365 ProPlus and optimize it to run in multi-user virtual scenarios
  • Provide Windows 7 virtual desktops with free Extended Security Updates
  • Bring your existing Remote Desktop Services (RDS) and Windows Server desktops and apps to any computer
  • Virtualize both desktops and apps
  • Manage Windows 10, Windows Server, and Windows 7 desktops and apps with a unified management experience

One point not mentioned that is important, Azure is the only public cloud you can run Windows 10 workloads.

There are a couple of pre-requisites to deploying WVD. First up is licensing, below are the requirements for running WVD

OSRequired license
Windows 10 Enterprise multi-session or Windows 10 single-sessionMicrosoft E3, E5, A3, A5, Business
Windows E3, E5, A3, A5
Windows 7Microsoft E3, E5, A3, A5, Business
Windows E3, E5, A3, A5
Windows Server 2012 R2, 2016, 2019RDS Client Access License (CAL) with Software Assurance

Next, you’ll need the following infrastructure components:

  • Azure AD tenant to register the service against
  • AD Domain Services reachable by VMs in WVD pool, so either a domain controller in the vnet or enable AAD DS.
  • An Azure subscription to host and pay for the above 🙂

Once the above is all ready to go, you’ll want to start your deployment. First, you need to register your AAD tenant with the WVD service. This requires Global Admin rights and your tenant ID, full details here. I found the process quick, simple and well documented.

Second, you need to create a host pool. This links the IaaS resources to your domain and your WVD service. I opted for an isolated vnet with AADDS activated to domain join the VMs, using a server pool for applications. Full details for this step here.

After a little time, my host pool was deployed and I could access the service via the web client.

A Windows 10 desktop session running via the HTML5 client right in the browser

The experience was good but I wouldn’t call it seamless. Simple things jumped out straight away from the authentication side of things with the HTML5 client. After logging into the Azure AD app, I then have to login again to the desktop, I would have expected SSO here. The same lack of SSO is present in the RDS client on Windows 10.

However, once connected, performance and latency were good. Exactly as expected in fact. Even via the HTML5 client.

Next, I wanted to test some individual apps. Namely, the powerhouse of app virtualisation, Notepad. I created a new RemoteApp Group, following the instructions here, again they were easy to follow. Although, Notepad didn’t show up in the list of available apps, I just entered the location where I know it is installed and it worked.

Again performance was as expected however the issue I ran into here was the fact that I couldn’t assign the same user to multiple groups, it was one group or the other as I had a “desktop” group and an “app” group. Hopefully this is something that is fixed, or a workaround in place for GA.

Next on my list will be to test the FSlogix option for profiles, load balancing options and creating a pool with a customised image. But so far I am impressed with the simplicity of deployment. I will follow this post up with impressions relative to that next level of customisation required for a production environment.

One final note is that all of the customisation of the Windows Virtual Desktop service is done via Powershell. If you’re not familiar or comfortable with this, you may struggle to get a working POC in place. My advice is to follow the published guides exactly or ask on Twitter for help!

Azure Backup – New! Instant Restore

Azure Backup is a service offered within the platform that allows you to backup and restore your IaaS data both from within Azure and on-premises. The integration out-of-the-box within Azure, and the attractive cost point make it a great option for many deployments. Simplicity is also key, for example, you can enable backup right from within the VM blade, or, for several VMs within your environment from the recovery services vault itself.

Another benefit is the speed and efficiency with which you can test and confirm your required restore processes. This has been recently improved on again by the introduction of Instant Restore. This introduces the ability to use snapshots taken as part of a backup job, which are then available for recovery without waiting for any data transfer to the vault. This greatly reduces the wait time to trigger a restore.

While Instant Restore is the quickest option, it does incur additional cost for the storage required to hold the snapshots. Also, it currently is only available in four regions, West Central US, India South, Australia East, and North Europe.

There are other alternatives included in the cost prices of Azure Backup. They are as follows:

  • Create a new VM
    • This quickly creates a basic VM from a chosen restore point. Configuration options are limited.
  • Restore disk
    • This creates new disks from a restore point. These disks can then be attached manually or via script. You pay for the disks while they are active but this option offers great flexibility.
  • Replace existing
    • This is more automated. Azure Backup takes a snapshot of the currently active VM, powers it off, then detaches current disks. While this is happening, it creates new disks from a restore point. Once restore is complete, it attaches them to the VM and powers it back on. There are some limitations here due to the automation used, it’s not supported for unmanaged disks, generalized VMs, or for VMs created using custom images.

There is also a fourth option that combines some automation for file level recovery. This is well detailed here – Azure Backup File Recovery.

Based on the previous options available, I think the new Instant Restore capability is a welcome addition. It brings Azure Backup more in line with traditional snapshot-as-a-quick-backup solutions people regularly leverage on-premises. If you are running significant IaaS workloads in Azure that require regular changes, I would strongly consider upgrading your Recovery Services Vault to support Instant Restore.

How to – Connect to an Azure VM

If you’ve just created your first Azure VM and are struggling to connect to it, this post should offer some help. I’ll cover connecting to both a Windows VM and a Linux VM, so RDP and SSH.

Connect to a Linux VM in Azure

To connect over SSH, you’ll need a client. A commonly used client is Putty, but you can use whichever you like. The first step is to know the details of your VM that are required to make a connection. When you built your VM, you would have created an administrator username and either a password or SSH key, ensure you have those to hand.

Next, you will need the IP or DNS name of the VM to connect to it. You can get this via the Azure Portal. If you click on the VM you want to connect to, it will by default open the Overview blade. From here, you will be able to copy the IP or DNS as required.

VM Overview settings

Then, using Putty, or a similar client, you can use that IP or DNS name, and port 22, to access SSH

PuTTY terminal settings

Once your session opens, you’ll be prompted for the credentials mentioned earlier.

Connect to a Windows VM in Azure

To connect via RDP, you’ll need to be using a machine that has an RDP client. This comes built into Windows. Next, you need to know the details of your VM that are required to make a connection. When you built your VM, you would have created an administrator username and a password, ensure you have those to hand.

Next, login to the Azure Portal, click the VM you want to connect to. This will open the Overview blade. From here you can click the Connect button. This will generate an RDP file for you to download and use.

Open the RDP file once downloaded. You may see some warnings relative to certificates, these can be ignored. Click connect.

Screenshot of a warning about an unknown publisher.

You will be prompted for credentials, these are the credentials as mentioned earlier. Once entered, you may see some warnings relative to certificates, these can be ignored.

Troubleshooting

If you’re having problems establishing a connection to your VM, first check if there is an NSG assigned to the VM or subnet the VM resides in. If there is, this NSG will require a rule to allow RDP/SSH access. By default, all connections via Public IP are blocked.