New version of Azure Backup Server introduces Modern Backup Storage technology

WOW! What a day for me! Microsoft Azure just announces new and improved features on the new version Azure Backup Server. Let’s start!

They announce with Azure Backup Server v2 (MABSv2) you can protect your VMWARE and Windows Server 2016 environment. That is really important feature (in my opinion). Now I don’t need to rely on third party backup software vendors to backup the workloads into Azure, special if the workload is running on ESXi.

Microsoft introduces now thought MABSv2 the Modern Backup Storage technology, based on the features available o Windows Server 2016.

With Windows Server 2016 broth enormous enhancements like ReFS cloning. MABSv2, now leverage these modern technologies, like ReFS cloning and Dynamic VHDX to reduce the overall TCO of backup. MABSv2 also introduces workload infinity technology, that helps to optimize storage utilization.

One of the features that Windows Server 2016 intruded was resilience change checking that improved virtual machine backup resiliency. MABSv2 are now resilient with Resilient Check Technology (RCT) and organizations don’t need to go with painful consistency checks scenarios like virtual machine storage migrations.

MABSv2 can detect and protect VMs that are store on Storage Spaces Direct (S2D), ReFS based cluster seemly without any manual steps. Windows Server 2016 VMs are more secure with shield VM technology and MABSv2 can protect and recovery them securely.

Windows Server 2012 R2 cluster can be upgraded to Windows Server 2016 using rolling cluster upgrade technology without bring down the production environment. MABSv2 will continue to backup the VMs and so there no miss of the SLA while the cluster upgrade is in progress.

You can also auto protect SQL workloads and VMware VMs to cloud using MABSv2. MABSv2, now also comes with the support to protect SQL 2016, SharePoint 2016 and Exchange 2016 workloads as well.

MABSv2 can protect VMware VMs, although the support is in test for MABSv2 running on Windows Server 2016.

MABSv1 deployments can be upgraded to MABSv2 with a few simple steps. MABSv2 will continue to backup data sources without rebooting production servers. So, you don’t need to worry about rebooting production servers or backup interruption with the upgrade to MABSv2.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Bigger disks on Azure Storage

If you follow the announcements during the Microsoft Build 2017 conference on the beginning of the month, one of the announcements was the increase of the size of the disks in Azure. Azure had a hard limit of a 1TB size disks. But those days are almost over. Oh Yeah Baby!

During one session at the Build 2017 about Big data workloads with Azure Blob Storage, they announce the increase of those disk limits. Today, Microsoft announce the preview of those disks.

So, what is that means? Beside the increase of the size, they are increasing the performance of the disks as well. Be able to have more space and IOPS is always nice.

New Disk Sizes Details

This table provides more details on the exact capabilities of the new disk sizes in Azure:

Disk Type P40 (Premium) P50 (Premium) S40 (Standard) S50 (Standard)
Disk Size 2048 GB 4095 GB 2048 GB 4095 GB
Disk IOPS 7,500 IOPS 7,500 IOPS Up to 500 IOPS Up to 500 IOPS
Disk Bandwidth 250 MBps 250 MBps Up to 60 MBps Up to 60 MBps

To see the session for further details

 

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Options to connect your datacenter to Azure Virtual Networks – Part 3 – Site-to-Site VPN

On the one of the previous post (see here) I briefly describe the options that you have to cross-premise connections to Azure. On this post, I want to explore more one of the options: Site-to-Site VPN.

Site-to-site VPNs rely on static routes to direct traffic between on-premises networks and Azure virtual networks. The Azure platform generates these routes when you create the site-to-site VPN connection based on two pieces of data: the IP address space that you assigned to the Azure virtual network and the local network, which you define in the process of setting up the VPN connection. The local network represents the IP address space of your on-premises networks.

Keep in mind that Azure implements the routing configuration of Azure virtual network. For cross-premises connectivity to function, you must update the on-premises routing configuration.

The site-to-site VPN method employs the IPSec protocol with a pre-shared key to provide authentication between the on-premises VPN gateway and the Azure VPN gateway. The key is an alphanumeric string between 1 and 128 characters.

From the infrastructure standpoint, in addition to a reliable connection to the Internet from your on-premises network, a site-to-site VPN requires a VPN gateway on each end of the VPN tunnel. On the Azure side, you provision a VPN gateway as part of creating a site-to-site VPN. Its characteristics depend on a couple of factors:

  • The VPN gateway SKU determines capacity and performance characteristics. There are two SKUs available in this case:
    • The Basic and Standard SKUs offers up to 100 Mbps throughput with maximum of 10 IPSec tunnels.
    • The High Performance SKU offers up to 200 Mbps throughput with maximum of 30 IPSec tunnels.
  • The VPN gateway type determines functional characteristics. The type of the Azure VPN gateway depends directly on the type of the VPN gateway used on premises, because they have to match. There are two types of VPN gateways:
    • Policy-based (formerly known as static).
    • Route-based (formerly known as dynamic).

Note: You can increase or decrease the SKU of a VPN gateway on as needed basis. However, you cannot change the existing gateway type.

Note: The effective throughput of VPN connections might vary, depending on the bandwidth of the Internet connection and impact of encryption associated with the VPN functionality.

Policy-based VPN devices operate according to local IPSec policies that you define. The policies determine whether to encrypt and direct traffic that reaches an IPSec tunnel interface based on the source and target IP address prefixes.

Route-based VPN devices rely on routes in the local routing table that you define to deliver traffic to a specific IPSec tunnel interface, which, at that point, performs encryption and forwards the encrypted network packets. In other words, in this case, any traffic reaching the interface is automatically encrypted and forwarded to the Azure VPN gateway on the other end of the tunnel.

Note: A site-to-site VPN does not support transitive routing between on-premises locations.

The choice of the device type has a number of significant implications:

  • Policy-based VPN devices support only a single site-to-site connection. With route-based VPN devices, that number depends on the Azure VPN gateway SKU, with up to 10 connections in case of the Basic and Standard SKUs and up to 30 connections in case of the High Performance SKU.
  • Policy-based VPN devices do not support point-to-site VPNs. This becomes important when you want to provide shared access to an Azure virtual network to clients connecting via a site-to-site VPN and a point-to-site VPN. Effectively, to implement this functionality, you would have to use a route-based VPN gateway in Azure, which implies the need to have the matching VPN device type on premises.
  • From the encryption standpoint, policy-based VPN devices support the Internet Key Exchange version 1 (IKEv1), AES256 (Advanced Encryption Standard), and AES128 3DES (Data Encryption Stanadrd) encryption algorithms, as well as the SHA1(SHA128) (Secure Hash Algorithm) hashing algorithm. Route-based VPN devices offer support for the IKEv2 and AES256 3DES encryption algorithm (during IKE Phase 1 setup) as well as both the SHA1(SHA128) and the SHA2(SHA256) hashing algorithms (again, during IKE Phase 1 setup). In addition, they also support perfect forward secrecy (DH Group1, 2, 5, 14, and 24).

Specifics of on-premises site-to-site VPN configuration are device specific. Microsoft offers configuration instructions for each of the validated VPN devices. Non-validated VPN devices may support site-to-site VPN, but they require independent testing.

For a list of VPN devices that Microsoft has validated in partnership with their vendors, and their configuration instructions, refer to VPN devices for Site-to-Site VPN Gateway connections

There are additional considerations regarding your on-premises infrastructure. In particular, if your VPN gateway resides on the perimeter network behind a firewall, you must ensure that the following types of traffic are allowed to pass through for both the inbound and outbound directions:

  • IP protocol 50
  • UDP port 500
  • UDP port 4500

The cost of site-to-site VPNs is comprised of two main components. The easiest-to-estimate part is the hourly cost of virtual machines hosting the VPN gateway. This depends on its SKU. There are three pricing tiers: Basic, Standard, or High Performance. In addition, there is a charge for outbound data transfers at standard data transfer rates, which depend on the volume of data and the zone in which Azure datacenter hosting the VPN gateway resides. The first 5 gigabytes (GB) per month are free of charge. There is also no cost associated with inbound data transfers.

There is a 99.9 percent availability Service Level Agreement (SLA) for each VPN gateway. A number of third-party vendors of VPN gateway devices support redundant configurations, which increase the resiliency of the on-premises endpoint of the VPN tunnel.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Options to connect your datacenter to Azure Virtual Networks – Part 2 – Point-to-Site VPN

On the previous post (see here) I briefly describe the options that you have to cross-premise connections to Azure. On this post I want to explore more one of the options: Point-to-Site VPN.

A point-to-site VPN employs SSTP to allow direct connectivity to an Azure virtual network from individual computers running any of the following Windows operating systems:

  • Windows 7 (32-bit and 64-bit versions)
  • Windows 8 (32-bit and 64 bit versions)
  • Windows 8.1 (32-bit and 64 bit versions)
  • Windows 10 (32-bit and 64 bit versions)
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016

SSTP relies on certificates to authenticate and encrypt connections between clients and the Azure VPN gateway. You have the option of using either your internal public key infrastructure (PKI) or generating self-signed certificates. You need to upload the public key of the root (representing your PKI deployment or a self-signed one) to Azure and associated with the target virtual network containing the VPN gateway. You also have to generate client certificates (typically one per each client computer) either by relying on your PKI implementation or by generating self-signed client certificates that reference the self-signed root certificate. You install the client certificates with their respective private keys in the private certificate store on client computers. Effectively, the VPN tunnel relies on the implicit trust between the client certificates on VPN client computers and the root certificate uploaded to the Azure VPN gateway.

This functionality leverages the VPN client software built into the operating system; however, it also requires installation of a VPN software package, which is available in a 32-bit and 64-bit version (the one you choose should match the version of the operating system). The package is customer specific. You can generate and download the package from the Azure portal. Its installation configures the built-in VPN client software and creates a new VPN connection entry on client computers. At that point, users can connect to the Azure virtual network by simply activating the new connection.

From the Azure infrastructure standpoint, a point-to-site VPN requires a VPN gateway associated with the target Azure virtual network, just like a site-to-site VPN or ExpressRoute. However, in this case, there is no need for additional on-premises servers or network circuits. You also need to take into account that there is extra management overhead involved in certificate management. In particular, you need to issue, install, and maintain validity of client certificates. You should also keep track of computers to which you deployed client certificates as well as their users. This allows you to revoke certificates in case a computer gets compromised or stolen or when a user leaves your organization.

When configuring a point-to-site VPN, you will need to designate an IP address range for VPN client computers. As part of the VPN connection establishment process, a VPN client automatically receives an IP address from this range. At that point, the VPN client software automatically updates the local routing table on the client computer so that any connection targeting the IP address space of the Azure virtual network is routed via the VPN connection.

Note: Updates to the local routing tables on the client computer require local Administrator privileges.

The total bandwidth available for the point-to-site connections depends on the SKU of the VPN gateway:

  • Standard is up to 100 Mbps.
  • High Performance is up to 200 Mbps.

All point-to-site VPN clients share that bandwidth, so the user experience depends on the total number of client computers simultaneously accessing the target virtual network. The VPN gateway enforces the limit of 128 concurrent connections.

Just like with a site-to-site VPN, the cost of a point-to-site VPN is comprised of two main components. The easiest-to-estimate part represents the hourly cost of virtual machines hosting the VPN gateway. This depends on its SKU. There are three pricing tiers: Basic, Standard, or High Performance. In addition, there is a charge for outbound data transfers at standard data transfer rates, which depend on the volume of data and the zone in which Azure data center hosting the VPN gateway resides. The first 5 GB per month are free of charge. There is also no cost associated with inbound data transfers.

Note: For up-to-date point-to-site VPN pricing information, refer to VPN Gateway Pricing

There is a 99.9 percent availability SLA for each VPN gateway.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Using PowerShell on Azure Cloud Shell

On the past May 10th, during the keynote of the Microsoft Build 2017 Conference in Seattle (WA), Microsoft announce the Azure Cloud Shell (see post here). Although on the May 4th when I enter at the Azure Portal I saw already the Azure Cloud Shell. Since that day, I was eager to start playing with Azure Cloud Shell, specially using PowerShell.

But it’s not yet available (at least for me). So, if you are like me, and follow the news and all the blogs related, at the Azure Blog they are giving a sneak peak of the power of the PowerShell on Azure Cloud Shell (see the post here).

On the blog post, they said the PowerShell experience will be the same as the Bash experience, where you will:

  • Get authenticated shell access to Azure from virtually anywhere.
  • Use common tools and programming languages in a shell that’s updated and maintained by Microsoft.
  • Persist your files across sessions in attached Azure File storage.

Additionally, the PowerShell experience will provide:

  • Azure namespace capability to let you easily discover and navigate all Azure resources.
  • Interaction with VMs to enable seamless management into the guest VMs.
  • Extensible model to import additional cmdlets and ability to run any executable.

But, on the bottom of that post there the magic gate to have access to this wonderful and Powerful world of using PowerShell on Azure Cloud Shell. So, if you want (like me), to start using Azure Cloud Shell, Sign-up here to participate in a limited preview of PowerShell in Azure Cloud Shell.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga