• Caching *may* make significant difference to the apparent performance of the disk subsystem
  • I say apparent, because actual throughput to/from the disk subsystem is unchanged – but cache can reduce the number of IOs that occur.
• Read cache will not necessarily improve performance for any given application – it depends on the application and data profile.
• Write cache should be used with care as data loss is possible in the event of a hardware issue with the physical server holding the cache before it is written to disk.
• Consult any guidance or best practices for the specific application in question

• Premium storage can achieve 10 times the IOPS, 3 times the throughput and 1/3 the latency when compared to standard disks.
• While the raw numbers are better, the same constraints around single threaded IO still apply.

• The local temporary disk can provide high IOPS, high throughput and low latency compared to permanent blob/vhd storage.
• Use with care as the data is transient.
• Using D: for SQL Server tempdb is supported and documented :
  • https://blogs.technet.microsoft.com/dataplatforminsider/2014/09/25/using-ssds-in-azure-vms-to-store-sql-server-tempdb-and-buffer-pool-extensions/
  • https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-windows-classic-sql-perf/

• There is not a solid understanding of how Azure disks work and perform.
• The requirements and characteristics of the application running on the VM is not well known.

• IOPS
• Latency
• Throughput
• Standard vs Premium storage
• Local temporary storage

• Capable of both standard and premium disks (Currently DS and GS series machines)
• Capable of a minimum of 4 data disks
• Capable of a minimum of 5000 or more IOPS.

• A standard disk is expected to handle 500 IOPS or 60MB/s
• A P30 Premium disk is expected to handle 5000 IOPS or 200MB/s

• Any disk will be limited at the lower of IOPS or throughput limits
• The ability for an application can achieve these numbers is also dependant on the manner in which reads/writes are performed. Applications which perform 'single threaded' IO will often hit a latency bottleneck before they hit these other limits.

• Disk Target : E: Drive (no cache)
• Maximum Disk Sectors : 1000
• # outstanding IOs : 100
• Access Specification : 512 B 100% Read

• The results should show a consistent 500 IOPS (Change the update frequency to 1 second in Iometer)
• Throughput is low – because block size is low (500 IOPS * 512 Bytes = 0.26MB/s)
• Average Latency is high – mainly because concurrent outstanding IO's is also high.

• Disk throughput should be much higher.
  • While we commit to 60MB/s, I typically see 100MB/s as shown above.
• IOPS is significantly lower as the larger block size means the throughput limit is hit before the IOPS limit (381 IOPS * 256KB = 100MB/s)

• The latency when writing to a standard disk is around 5 ms.
• The IOPS and throughput are both significantly lower than the maximum capabilities of the disk.

• When outstanding IOs is set to 1, Iometer does a read request, waits for the data to come back, and then issues the next request.
• In this scenario, it is simulating an older style application that is performing single threaded IOs
• If each read request takes 5 ms, then a maximum of 200 read requests will be achieved each second.
  • (5.27 ms * 189.45 IOPS = 999ms)

• Any application that does single threaded IO is likely to suffer reduced IO performance because of latency.
• Caching, local temp storage and/or Premium storage can be used to assist here – see Part 2

Accessing these sites while mobile or working from home has traditionally used one of three approaches:

• Establish a VPN connection to the corporate network.
• Publish the website via some form of reverse proxy hosted in the DMZ
• Access the website via an RDS/VDI session (often using one of the first two mechanisms)

Each of these approaches work, but have complexities or downsides:

• VPN software may not work on mobile, home or BYO devices.
• DMZ networks and reverse proxies are complex and costly if not already in place.
• RDS/VDI requires infrastructure to establish and is a clumsy experience if all that is needed is a website.

Azure Active Directory Application Proxy provides an additional mechanism to allow internally hosted sites to be accessed externally without requiring VPNs, DMZs or RDS/VDI.

Testing App Proxy with MFA

Pre-requisites:

• An Azure AD instance with Basic or Premium features enabled or in trial mode.
• An Azure MFA provider configured and linked to the AAD instance
• The URL of an internal website
• A small Windows 2012R2 virtual machine that can :
  • Access the internal website
  • Access the internet (outbound)

1. Start the Classic Azure management portal, navigate to your Azure AD instance and select the Applications tab

   

2. Select Add and pick Publish an application that will be accessible from outside your network

   

1. Enter the relevant details for the website. Note the internal URL is one you would use on a machine inside your corporate network.

   

2. Click OK
3. The status page for the Azure AD Application will then be shown. Select Download a Connector

   

The connector should be downloaded and installed on the Windows 2012R2 VM

1. Once the connector is installed and tested, select the Configure tab of the application in the classic Azure management portal.

   

2. Scroll down to multi-factor authentication… and click ON

For the purposes of this demo, leave other settings unchanged.

1. Click Save at the bottom of the screen
2. Add user(s) to test with to the application – highlight the use and click Assign

   

3. Copy the external URL from the configure tab :

   

   Note : In a production environment, you would typically use your own DNS suffix rather than the Azure provided one.

4. Paste into a browser. You may need InPrivate/Incognito or similar if you are already logged into Azure AD with different credentials.

A logon screen similar to below should appear. The graphics/text on the left are due to customised branding on the AAD environment itseld

1. Log in with the user that you enabled for the application – in this case lbrown@aecmgmt.com

   

2. We are now being notified that MFA is required

   

   If this is the first time the user has been required to use MFA, an enrolment process will be initiated.

3. Once the MFA approval has gone through the website should be displayed.

   

Notes on this demo :

• Screenshots and steps correct at Sep 9^th 2016 – things change.
• The internal website in this case did not require any explicit authentication itself – if it did additional steps would be required to pass credentials through.