Friday, September 29, 2017

Microsoft Ignite 2017: High Availability for your Azure VMs

The idea with Cloud is that each layer is responsible for its own availability and by combining these loosely coupled layers you get higher availability. It should be a consideration before you begin deployment. For example if you start by considering maintenance and how and when you would take a planned outage it informs your design. You should predict the types of failures you can experience so you are mitigating it in your architecture.

There is an emerging concept on Hyper-scale Cloud platforms called grey failures. A grey failure is when your VM, workloads or applications are not down but are not getting the resources they need.

“Grey Failure: The Achilles Heel of Cloud Scale Systems”

Monitoring and Alerting should be on for any VMs running in IaaS. When you open a ticket in Azure any known issues are surfaced as part of the support request process. This is part of Azure’s automated analytics engine providing support before you input the ticket.

Backup and DR plans should be applied to your VM. Azure allows you to create granular retention policies. When you recover VMs you can restore over the existing or create a new VM. For DR you can leverage ASR to replicate VMs outside another region. ASR is not multi-target however so you could not replicate VMs from the enterprise to an Azure region and then replicate them to a different one. It would be two distinct steps, first replicate and failover the VM to Azure and then you can setup replication between two regions.

Maintenance Microsoft now provides a local endpoint in a region with a simple REST API that provides information on upcoming maintenance events. These can be surfaced within the VM so you can trigger soft shutdowns of your virtual instance. For example, if you have a single VM (outside an availability set) and the host is being patched the VM can complete a graceful shutdown.

Azure uses VM preserving technology when they do underlying host maintenance. For updates that do not require a reboot of the host the VM is frozen for a few seconds while the host files are updated. For most applications this is seamless however if it is impactful you can use the REST API to create a reaction.

Microsoft collects all host reboot requirements so that they are applied at once vs. periodically throughout the year to improve platform availability. You are preemptively notified 30 days out for these events. One notification is sent per subscription to the administrator. The customer can add additional recipients.

Availability Sets  is a logical grouping of VMs within a datacenter that allows Azure to understand how your application is built to provide for redundancy and availability. Microsoft recommends that two or more VMs are created within an availability set. To have a 99.95% SLA you need to deploy your VMs in an Availability Sets. Availability Sets provide you fault isolation for your compute.

An Availability Set with Managed Disks is call a Managed Availability Set. With Managed Availability Set you get fault isolation for compute and storage. Essentially it ensures that the managed VM Disks are not on the same storage.

Microsoft Ignite 2017: Tips & Tricks with Azure Resource Manager with @rjmax

The AzureRM vision is to capture everything you might do or envision in Cloud. This should extend from infrastructure, configuration to governance and security.

Azure is seeing about 200 ARM templates deployed per second. The session will focus on some of the template enhancements and how Microsoft is more closely integrating identity management and delivering new features.

You now have the ability to deploy ARM deployments across subscriptions (service providers pay attention!). You can also deploy across resource groups. The two declaratives within the ARM template are that enable this are:

“resourceGroup”

“subscriptionId”

You may be wondering how you share your templates, increase the reliability and support them after a deployment?

Managed Applications

Managed applications is the ability to simplify template sharing. Managed applications can be shared or sold, they are meant to be simple to deploy, they are contained so they cannot be broken and they can be connected. Connected means you define what level of access you need to it after it has been deployed for ongoing management and support.

For additional details on Managed applications please see https://docs.microsoft.com/en-us/azure/azure-resource-manager/managed-application-overview .

Managed applications are available in West US and West US Central but will be global by the end of the year. When you define a managed application through the Azure portal you determine if it is locked or unlocked. If it is locked you need to define who is authorized to write to it.

image

By default Managed Applications are deployed within your subscription. From within the access pane of the Managed Application you can share it to other users and subscriptions. Delivering Managed Applications to the Azure marketplace is in Public Preview at this moment.

Managed Identity

With Managed Identity you can now create virtual machines with a service principal provided by Azure active directory. This allows the VM to get a token to enable service access to avoid having passwords and credentials in code. To learn more have a look here

https://docs.microsoft.com/en-us/azure/active-directory/msi-overview 

ARM Templates & Event Grid

You can use Event Grid to collect all ARM events and requests which can be pushed to an end point or listener. To learn more on Event Grid read here

https://buildazure.com/2017/08/24/what-is-azure-event-grid/

Resource Policies

You can use Resource Policies to do Location Ringfencing. Location Ringfencing allows you to define a policy to ensure your data does not leave a certain location.

image

You can also restrict which VM Classes that people can use. For example to prevent your developers from deploying extremely expensive classes of VMs.

Policies can be used to limit the access to all the marketplace images to just a few. You can find many starting point policies on GitHub

https://github.com/azure/azure-policy-samples

Azure Policies are in Preview and additional information can be found here:

https://azure.microsoft.com/en-us/services/azure-policy/

Microsoft MSIgnite 2017:How to get Office 365 to the next level with Brjann Brekkan

It is important that customers are configured with a single Identity or Tenant. You should look at the Identity as the Control Plane or the single source of truth. Azure Active Director “AD” has grow 30% in Year-over-Year growth to 12.8 million customers. In addition there are now 272,000 Apps in Azure AD. Ironically the most used application in Azure AD is Google Apps. Customers are using Azure AD to authenticate Google Services.

Azure AD is included with O365 so there is no additional cost. Identity in O365 consists of three different types of users:

  1. Cloud Identity: accounts live in O365 only
  2. Synchronized Identity: accounts sync with a local AD Server
  3. Federated Identity: Certificate based authentication based on an on premises deployment of AD Federation Service.

The Identity can be managed using several methods.

Password Hash Sync ensures you have the same password on-premises as in the cloud. The con to Hash sync is that disabled or user edits are not updated until the sync cycle is complete. In hash sync the hashes on-prem are not identical to those in the cloud but the passwords are the same.

Pass-through Authentication You still have the same password but passwords remain on-premises. There is a Pass-through Agent “PTA” agent that gets installed on your enterprise AD server. THE PTA Agent handles the queuing of requests from Azure AD and sends the validations back once authenticated.

Seamless Single Sign-On works with both Password Hash Sync and Pass-through Authentication. This is done with no additional requirement onsite. SSO is enabled during the installation of AD Connect.

You do not need more than on Azure AD if you have more than one AD on premises. One Azure AD can support hundreds of unique domain names. You can also mix cloud only accounts and on prem synchronized accounts. You can use PowerShell Graph API vs. AD Connect to synchronize and manage users and groups but it is much more difficult. AD Connect is necessary for Hybrid Exchange however.

There are six general use cases for Azure AD:

  1. Employee Secure Access to Applications
  2. To leverage Dynamic Groups for automated application deployment. Dynamic groups allow move, join and leave workflow processes
  3. To federate access for Business-to-Business communication and collaboration (included in Azure AD, 1 license enables 5 collaborations)
  4. Advanced threat and Identity protection. This is enabled through conditional access based on device compliance.
  5. To Abide by Governance and Compliance industry regulations. Access Review is in public review which identifies accounts that have not accessed the system for a while and prompts the administrator to review them.
  6. To leverage O365 as an application development platform

With AD Premium you get AD Connect Health, Dynamic Group memberships, Multi-Factor Authentication for all objects that can be applied when needed vs always on. In addition there is a better overall end user experience.