Azure Premium SSD v2 Disk Storage in preview

We are excited to announce the preview of Premium SSD v2, the next generation of Microsoft Azure Premium SSD Disk Storage. This new disk offering provides the most advanced block storage solution designed for a broad range of input/output (IO)-intensive enterprise production workloads that require sub-millisecond disk latencies as well as high input/output operations per second (IOPS) and throughput—at a low cost. With Premium SSD v2, you can now provision up to 64TiBs of storage capacity, 80,000 IOPS, and 1,200 MBPS throughput on a single disk. With best-in-class IOPS and bandwidth, Premium SSD v2 provides the most flexible and scalable general-purpose block storage in the cloud, enabling you to meet the ever-growing demands of your production workloads such as—SQL Server, Oracle, MariaDB, SAP, Cassandra, Mongo DB, big data, analytics, gaming, on virtual machines, or stateful containers. Moreover, with Premium SSD v2, you can provision granular disk sizes, IOPS, and throughput independently based on your workload needs, providing you more flexibility in managing performance and costs.

With the launch of Premium SSD v2, our Azure Disk Storage portfolio now includes one of the most comprehensive sets of disk storage offerings to satisfy workloads ranging from Tier-1 IOPS intensive workloads such as SAP HANA to general purpose workloads such as RDMS and NoSQL databases and cost-sensitive Dev/Test workloads.

Benefits of Premium SSD v2

As customers transition their production workloads to the cloud or deploy new cloud-native applications, balancing performance and cost is top of mind. For example, transaction-intensive database workloads may require high IOPS on a small disk size or a gaming application may need very high IOPS during peak hours. Similarly, big data applications like Cloudera/Hadoop may require very high throughput at a low cost. Hence, customers need the flexibility to scale their IOPS and throughput independent of the disk size. With Premium SSD v2, you can customize disk performance to precisely meet your workload requirements or seasonal demands, without the need to provision additional storage capacity.

Premium SSD v2 also enables you to provision storage capacity ranging from 1 GiB up to 64 TiB with GiB increments. All Premium SSD v2 disks provide a baseline performance of 3,000 IOPS and 125 MB/sec. If your disk requires higher performance, you can provision the required IOPS and throughput at a low cost, up to the max limits shown below. You can dynamically scale up or scale down the IOPS and throughput as needed without downtime, allowing you to manage disk performance cost-effectively while avoiding the maintenance overhead of striping multiple disks to achieve more performance. Summarizing the key benefits:

◉ Granular disk size in 1 GiB increments.

◉ Independent provisioning of IOPS, throughput, and GiB.

◉ Consistent sub-millisecond latency.

◉ Easier maintenance with scaling performance up and down without downtime.

Premium SSD v2, like all other Azure Disk Storage offerings, will provide our industry-leading data durability and high availability at general availability.

Following is a summary comparing Premium SSD v2 with the current Premium SSD and Ultra Disk.

	Ultra Disk	Premium SSD v2	Premium SSD
Disk Size	4 GiB - 64 TiB	1 GiB - 64 TiB	4 GiB - 32 TiB
Baseline IOPS	Varies by disk size	3,000 IOPS free	Varies by disk size
Baseline throughput	Varies by disk size	125 MBPS free	Varies by disk size
Peak IOPS	160,000 IOPS	80,000 IOPS	20,000 IOPS
Peak Throughput	4,000 MBPS	1,200 MBPS	900 MBPS
Durability	99.999999999% durability (~0% annual failure rate)	99.999999999% durability (~0% annual failure rate)	99.999999999% durability (~0% annual failure rate)

Supported Azure Virtual Machines

Premium SSD v2 can be used with any premium storage-enabled virtual machines sizes enabling you to leverage a diverse set of virtual machine sizes. Currently, Premium SSD v2 can only be used as data disks. Premium SSDs and Standard SSDs can be used as OS disks for virtual machines using Premium SSD v2 data disks.

Pricing

Premium SSD v2 disks are billed hourly based on the provisioned capacity, IOPS, and MBPS. Let’s take an example of a disk that you provision with 100 GiB capacity, 5000 IOPS, and 150 MB/sec throughput.

◉ The disks are billed per GiB of the provisioned capacity. Hence, you will be charged for 100 GiB of the provisioned capacity.

◉ The disks are billed for any additional IOPS provisioned over the free baseline of 3,000 IOPS. In this case, since you provisioned 5000 IOPS, you will be billed for the additional 2,000 IOPS.

◉ The disks are billed for any additional throughput over the free baseline throughput of 125 MB/s. In this case, since you provisioned 150 MB/sec throughput, you will be billed for the additional 25 MB/s throughput.

Source: microsoft.com

Continue reading

Updates to Azure Files: NFS v4.1, higher performance limits, and reserved instance pricing

Azure Files offers fully managed, simple, secure, and serverless enterprise-grade cloud file shares. On the Azure Files team, our mission is to expand Azure Files to more platforms and workloads. We recently took a huge step in workload expansion by announcing the general availability of our NFS v4.1 shares. This greatly expands the workloads you can run on Azure file shares by providing POSIX compatible file systems for Linux virtual machines and container-based workloads. This blog provides information on the general availability of NFS v4.1 shares, increased performance for all premium file shares, and reserved instance pricing for premium file shares to lower your costs.

NFS v4.1 shares are now generally available

In November we announced the general availability of Azure Files support for NFS v4.1. Now you can deploy these fully POSIX compliant, distributed NFS file shares in your production environments for a wide variety of Linux and container-based workloads.

We saw strong interest in the preview with participation from companies of all sizes, ranging from emerging startups to Fortune 100s, running a plethora of workloads. Some examples of workloads include SAP application layer, enterprise messaging, user home directories, custom line-of-business applications, database backups, database replication, AI and machine learning user directories, DevOps pipelines, and many more industry-specific workloads such as the solution from EDF Energy below.

EDF Energy uses Azure file shares as part of its asset management solution:

“At EDF Energy, Nuclear Safety is our overriding priority. As part of our Asset Management solution used to control work, maintenance, and defect resolution to support site license conditions, we needed a performant shared file system between multiple Linux Application Servers—such as an NFS share. We used NFS v4.1 on Azure Files in the preview and have now taken full dependency on it. The NFS system is working very well for us, persisting our files and keeping our IaaS requirements to a minimum.”

—Cathy Handley, AMS Upgrade Programme Manager, EDF Energy—Helping Britain Achieve Net Zero

Customers running critical systems such as SAP have told us that synchronous zonal redundancy is a game-changer for them to achieve high availability for their application layer. With Azure premium file shares you can choose between Locally redundant storage (LRS) or Zonal Redundant Storage (ZRS) redundancy. With ZRS, data is synchronously replicated to three different availability zones within an Azure region. This means your applications’ access to the data will not be disrupted, even in the unlikely event of an entire zone failure. SAP storage administrators gave us great feedback including: “easy to use”, “good performance”, and “better cost optimization.”

Unlike the lower versions of NFS, locking is inbuilt into NFS v4.1. Hence, software like IBM MQ relies on locking support from NFS v4.1 to keep data consistent within a distributed system. While in preview, we enhanced our locking support and implemented locking upgrades and downgrades.

The Azure Files CSI driver (now generally available) makes it easy to access your Azure File shares from Azure Kubernetes Service (AKS). The fast attach-detach times of Azure Files have been appealing to applications that require rapid scale up and scale down.

NFS v4.1 is available in all regions where the premium tier of Azure Files exists. For the full list, see the Azure service availability page. You can now get started using NFS by following these simple step-by-step instructions.

Improved performance

Today, we are announcing more IOPS and throughput for all premium file shares (SMB and NFS).

All shares now provide a minimum of 3000 IOPS, up from the previous 400 IOPS baseline. We are also increasing the minimum burst IOPS such that even the smallest shares can burst up to 10,000 IOPS. Just as before, you will continue to linearly scale IOPS up to 100,000 as the share size increases.

You can now use 100 percent of the provisioned throughput towards either reads or writes. This means you can get up to 10GB/s of read or write traffic. Previously, premium shares used allocated throughput with a 40:60 write:read ratio resulting in max write of 4GB/s and max read of 6GB/s.

These performance enhancements will apply to all existing and new shares across all regions including public and sovereign cloud at no extra cost.

Lower cost with Reserved Instances

All premium file shares (SMB and NFS) now support capacity reservations which provide up to 36 percent discount, by pre-committing to storage utilization.

Reserved instances are also supported for the hot and cool Azure file shares (SMB only).

Get involved

You can put all the updates mentioned in this blog together for NFS v4.1 shares with higher throughput and more IOPS at a lower price. Of course, the performance improvements and reserved instances apply to both NFS and SMB shares. We continue to increase investments in Azure Files and look forward to getting the next wave of updates released.

Source: microsoft.com

Continue reading

Modernize alerting using Azure Resource Manager storage accounts

Classic alerts in Azure Monitor will reach retirement this coming June. We recommend that you migrate your classic alert rules defined on your storage accounts, especially if you want to retain alerting functionality with the new alerting platform. If you have classic alert rules configured on classic storage accounts, you will need to upgrade your accounts to Azure Resource Manager (ARM) storage accounts before you migrate alert rules.

Identify classic alert rules

You should first find all classic alert rules before you migrate. The following screenshot shows how you can identify classic alert rules in the Azure portal. Please note, you can filter by subscription so you can find all classic alert rules without checking on each resource separately.

Migrate classic storage accounts to ARM

New alerts do not support classic storage accounts, only ARM storage accounts. If you configured classic alert rules on a classic storage account you will need to migrate to an ARM storage account.

You can use "Migrate to ARM" to migrate using the storage menu on your classic storage account. The screenshot below shows an example of this.

Re-create alert rules in new alerting platform

After you have migrated the storage account to ARM, you then need to re-create your alert rules. The new alerting platform supports alerting on ARM storage accounts using new storage metrics. In the storage blade, the menu is named "Alert" for the new alerting platform.

Before you re-create alert rules as a new alert for your storage accounts, you may want to understand the difference between classic metrics and new metrics and how they are mapped. 

The following screenshot shows how to create an alert based on “UsedCapacity.”

Some metrics include dimension, which allows you to see and use different dimension value types. For example, the transactions metric has a dimension named “ResponseType” and the values represent different type of errors and success. You can create an alert to monitor transactions on a particular error such as “ServerBusyError” or “ClientOtherError” with “ResponseType”.

The following screenshot shows how to create an alert based on Transactions with “ClientOtherError.”

In the list of dimension values, you won't see all supported values by default. You will only see values that have been triggered by actual requests. If you want to monitor conditions that have not happened, you can add a custom dimension value during alert creation. For example, when you have not had anonymous requests to your storage account yet, you can still setup alerts in advance to monitor such activity from upcoming requests.

The following screenshot shows how to add a custom dimension value to monitor upcoming anonymous transactions.

We recommend creating the new alert rules first, verify they work as intended, then remove the classic alerts.

Azure Monitor is a unified monitoring service that includes alerting and other monitor capabilities.

Continue reading

Azure Blob Storage lifecycle management in public preview

We released Blob-Level Tiering which allows you to transition blobs between the Hot, Cool, and Archive tiers without moving data between accounts. Both Blob-Level Tiering and Archive Storage help you optimize storage performance and cost. You asked us to make it easier to manage and automate, so we did. Today we are excited to announce the public preview of Blob Storage lifecycle management so that you can automate blob tiering and retention with lifecycle management policies.

Lifecycle management

Data sets have unique lifecycles. Some data is accessed often early in the lifecycle, but the need for access drops drastically as the data ages. Some data remain idle in the cloud and is rarely accessed once stored. Some data expire days or months after creation while other data sets are actively read and modified throughout their lifetimes. Azure Blob Storage lifecycle management offers a rich, rule-based policy which you can use to transition your data to the best access tier and to expire data at the end of its lifecycle.

Lifecycle management policy helps you:

◈ Transition blobs to a cooler storage tier (Hot to Cool, Hot to Archive, or Cool to Archive) to optimize for performance and cost

◈ Delete blobs at the end of their lifecycles

◈ Define rules to be executed once a day at the storage account level (it supports both GPv2 and Blob storage accounts)

◈ Apply rules to containers or a subset of blobs (using prefixes as filters)

Example

Consider a data set that is accessed frequently during the first month, is needed only occasionally for the next two months, is rarely accessed afterward, and is required to be expired after seven years. In this scenario, Hot storage is the best tier to use initially, Cool storage is appropriate for occasional access, and Archive storage is the best tier option after several months before it is deleted seven years later.

The following sample policy manages the lifecycle for such data. It applies to block blobs with prefix “foo”:

◈ Tier blobs to Cool storage 30 days after last modification

◈ Tier blobs to Archive storage 90 days after last modification

◈ Delete blobs 2,555 days (seven years) after last modification

◈ Delete blob snapshots 90 days after snapshot creation

{
   "version": "0.5",
   "rules": [
     {
       "name": "ruleFoo",
       "type": "Lifecycle",
       "definition": {
         "filters": {
           "blobTypes": [ "blockBlob" ],
           "prefixMatch": [ "foo" ]
         },
         "actions": {
           "baseBlob": {
             "tierToCool": { "daysAfterModificationGreaterThan": 30 },
             "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
             "delete": { "daysAfterModificationGreaterThan": 2555 }
           },
           "snapshot": {
             "delete": { "daysAfterCreationGreaterThan": 90 }
           }
         }
       }
     }
   ]
}

Azure portal

How to get started

To enroll in public preview, you will need to submit a request to register this feature to your subscription. After your request is approved (within a few days), any existing and new GPv2 or Blob Storage account in West US 2 and West Central US will have the feature enabled. During preview, only block blob is supported. As with most previews, this feature should not be used for production workloads until it reaches GA.

To submit a request, run the following PowerShell or CLI commands.

PowerShell

Register-AzureRmProviderFeature -FeatureName DLM -ProviderNamespace Microsoft.Storage

CLI 2.0

az feature register –-namespace Microsoft.Storage –-name DLM

Cost

Lifecycle management feature is free of charge in preview. Customers are charged the regular operation cost for the List Blobs and Set Blob Tier API calls.

Continue reading

Soft delete for Azure Storage Blobs generally available

Today we are excited to announce general availability of soft delete for Azure Storage Blobs! The feature is available in all regions for public, government and sovereign clouds.

When turned on, soft delete enables you to save and recover your data where blobs or blob snapshots are deleted. This protection extends to blob data that is erased as the result of an overwrite.

How does it work?

When data is deleted, it transitions to a soft deleted state instead of being permanently erased. When soft delete is on and you overwrite data, a soft deleted snapshot is generated to save the state of the overwritten data. Soft deleted objects are invisible unless explicitly listed. You can configure the amount of time soft deleted data is recoverable before it is permanently expired.

Soft deleted data is grey, while active data is blue. More recently written data appears beneath older data. When B0 is overwritten with B1, a soft deleted snapshot of B0 is generated. When the blob is deleted, the root (B1) also moves into a soft deleted state.

Soft delete is 100 percent backwards compatible; you don’t have to make changes to your applications to take advantage of the protections this feature affords. With this GA announcement, we have added support for tiering blobs with soft deleted snapshots. When Set Blob Tier is called on a blob with soft deleted snapshots, the snapshots will remain in the original storage tier and expire based on the retention period you configured.

When you create a new account, soft delete is off by default. Soft delete is also off by default for existing storage accounts. You can toggle the feature on and off at any time during the life of a storage account. Object-level soft delete is available for all storage account types and all storage tiers. It does not protect against container or account deletions.

Soft deleted data is billed at the same rate as active data.

Getting started

Soft delete is supported by Azure Portal, .NET Client Library (version 9.0.0), Java Client Library (version 7.0.0), Python Client Library (version 1.1.0), Node.js Client Library (version 2.8.0), PowerShell (version 5.3.0) and CLI 2.0 (version 2.0.27). You can also directly use the Storage Services REST API as always. Soft delete is supported by REST API version 2017-07-29 and greater. In general, we always recommend using the latest version regardless of whether you are using this feature.

To enable soft delete using the Azure Portal, navigate to the "Soft delete" option under "Blob Service." Then, click "Enabled" and enter the number of days you want to retain soft deleted data.

If there is a chance that your data is accidentally modified or deleted by an application or other storage account user, we recommend turning on soft delete. Soft delete is one part of a data protection strategy and can help prevent inadvertent data loss.

Soft delete helps ensure that you can recover accidentally deleted or modified blob data. Soft delete is a key part of an overall data protection strategy that includes Azure Resource Manager locks as well as the ZRS, GRS, and RA-GRS replication tiers.

Continue reading

SQL Database: Long-term backup retention preview includes major updates

The preview for long-term backup retention in Azure SQL Database was announced in October 2016, providing you with a way to easily manage long-term retention for your databases – up to 10 years – with backups stored in your own Azure Backup Service Vault.

Based upon feedback gathered during the preview, we are happy to announce a set of major enhancements to the long-term backup retention solution. With this update we have eliminated the need for you to deploy and manage a separate Backup Service Vault. Instead, SQL Database will utilize Azure Blob Storage under the covers to store and manage your long-term backups. This new design will enable flexibility for your backup strategy, and overall more control over costs.

This update brings you the following additional benefits:

◈ More regional support – Long-term retention will be supported in all Azure regions and national clouds.
◈ More flexible backup policies – You can customize the frequency of long-term backups for each database with policies covering weekly, monthly, yearly, and specific week-within-a-year backups.
◈ Management of individual backups – You can delete backups that are not critical for compliance.
◈ Streamlined configuration – No need to provision a separate backup service vault.

What happens with your existing long-term backup retention policies?

Your existing backups will be automatically transitioned to the SQL Database managed RA-GRS storage containers.

◈ All existing long-term backups are already copied from your recovery vaults to the new storage containers free of charge.

◈ The new API that supports the enhanced feature set will be available in parallel with the existing API until May 31, 2018. You are expected to update your configuration scripts to the new API by that deadline.

Note, backups associated with servers that are already dropped are not migrated.

The portal experience is updated to support the additional LTR capabilities as illustrated by the following image. If you configured your long-term retention policy using the portal no actions are expected from you. ­

The following diagram illustrates how you can configure a new long-term retention policy for a database.

The long-term policies for individual databases are shown in a single table as illustrated by the next diagram.

The next diagram illustrates how you can restore a specific long-term backup.

How will this impact your bill?

If you are using the existing LTR preview you will notice a new charge on your bill with the name LTR backup storage. At the same time, you no longer will be billed for the backups in recovery vaults. The new LTR solution is more cost efficient, which can mean lower overall long-term backup retention storage costs. In addition, the added flexibility in the backup retention policy helps you reduce costs even further by letting you select less frequent backups, e.g. once a month or once a year, or by deleting individual backups that you don’t need. If you are new to LTR and just configured your first LTR policy, your next monthly bill will include the LTR backup storage charges.

Does long-term retention impact my GDPR compliance?

If the backup contains personal data that is subject to General Data Protection Regulation (GDPR), you are required to apply enhanced security measures to protect the data from unauthorized access. In order to comply with GDPR, you need a way to manage the data requests of data owners without having to access backups. This layer of protection to the personal data stored in backups can be achieved by storing only "pseudonymized" data in backups. For example, if data about a person needs to be deleted or updated, it will not require deleting or updating the existing backups.

Continue reading

Announcing Virtual Network integration for Azure Storage and Azure SQL

We are glad to announce the public preview of Virtual Network (VNet) Service Endpoints for Azure Storage and Azure SQL.

For many of our customers moving their business-critical data to the cloud, data breaches remain a top concern. Various Azure services that store or process the business data have Internet-reachable IP addresses. Leaked credentials or malicious insiders with administrative privileges gaining access to the data, from anywhere in the world, is an increasing concern to our customers.

To protect against these threats, private connectivity to Azure services is becoming essential to moving more critical workloads to the cloud. Most customers want to limit access to their critical resources to only their private environments, i.e. their Azure Virtual Networks and on-premises.

While some of the Azure services can be directly deployed into VNets, many others still remain public. With VNet service endpoints, we are expanding Virtual Network support to more multi-tenant Azure services.

Service endpoints extend your VNet private address space and identity to the Azure services, over a direct connection. This allows you to secure your critical service resources to only your virtual networks, providing private connectivity to these resources and fully removing Internet access.

Configuring service endpoints is very simple with a single click on a subnet in your VNet. Direct route to the services is auto-configured for you. There are no NAT or gateway devices required to set up the endpoints. You also no longer need reserved, public IP addresses in your VNets to secure Azure resources through IP firewall. Service endpoints makes it easy to configure and maintain network security for your critical resources.

Step1: Set up service endpoints once on your Virtual Network. Network administrators can turn this setting independently, allowing for separation of duties.

Step 2: Secure your new or existing Azure service resources to the VNet, with a simple click. Set up once for the Storage account or SQL server and automatically applies to any access to child resources. Data administrators can set up independently (optional).

Service endpoints is available in preview for below services and regions:

Azure Storage: WestUS, EastUS, WestCentralUS, WestUS2, AustraliaEast, and AustraliaSouthEast

Azure SQ: EastUS, WestCentralUS, WestUS2

We will be expanding the feature to more regions soon.

We are very excited to bring enhanced network security for your Azure service resources. This is only a beginning for our roadmap for tightening security for Azure services. We will expand the service endpoints to more Azure services. In addition to service endpoints, we are also very committed to giving you private connectivity to your Azure resources, from your firewalls and on-premises. Service tags is yet another investment in this direction, for your Network Security Groups (NSGs) to selectively open access only to Azure services from your VNets. Service tags is also available in preview now.

Continue reading

OMS Monitoring solution for Azure Backup using Azure Log analytics

We are pleased to let you know that you can leverage the same workflow to build your own Microsoft Operations Management Suite (OMS) monitoring solution for Azure Backup in the upgraded OMS workspace. The OMS monitoring solution allows you to monitor key backup parameters such as backup and restore jobs, backup alerts, and cloud storage usage across Recovery Services vaults and subscriptions. You can then utilize OMS log analytics capabilities to raise further alerts for events that you deem important for the business to be notified of. You could even open tickets through webhooks or ITSM integration using the OMS log analytics capabilities.

Here’s how you do it…

Configuring Diagnostic settings

You can open the diagnostic setting window from the Azure Recovery services vault, or you can open the diagnostic setting window by logging into Azure portal. First, click “Monitor” service followed by “Diagnostic settings” in settings section. You can then specify the relevant Subscription, Resource Group, and Recovery Services Vault. In the Diagnostic settings window, as shown below, you can select “Send data to log analytics” and then select the relevant OMS workspace. You can choose any existing log analytics workspace, such that all vaults pump the data to the same workspace

Please select the relevant log, “AzureBackupReport” in this case, to be sent to the log analytics workspace. Click “Save” to save the setting.

After you have completed the configuration, you should wait for 24 hours for initial data push to complete.

Deploying solution to Azure OMS

The OMS monitoring solution template for Azure Backup is a community driven project where you can deploy the base template to Azure and then customize it to fit your needs.

Monitoring Azure Backup data

The overview tile in the dashboard reflects the key parameter, which is the backup jobs and their status.

Clicking on the overview tile will take you to the dashboard where the solution has information categorized into jobs and alerts status, and active machines and their storage usage.

MAKE SURE YOU SELECT THE RIGHT DATE RANGE AT THE TOP OF THE SCREEN to filter the data for the required time interval.

Log search capabilities

You can click on each tile to get more details about the queries used to create the tile and configure it to meet your requirement. Clicking further on values appearing in the tiles will lead you to the Log Analytics screen where you can raise alerts for configurable event thresholds and automate actions to be performed when those thresholds are met/crossed.

Continue reading

Virtual Network Service Endpoints and Firewalls for Azure Storage now generally available

Today we are announcing the general availability of Firewalls and Virtual Networks (VNets) for Azure Storage along with Virtual Network Service Endpoints. Azure Storage Firewalls and Virtual Networks uses Virtual Network Service Endpoints to allow administrators to create network rules that allow traffic only from selected VNets and subnets, creating a secure network boundary for their data. These features are now available in all Azure public cloud regions and Azure Government. As part of moving to general availability it is now backed by the standard SLAs. There is no additional billing for virtual network access through service endpoints. The current pricing model for Azure Storage applies as is today.

Customers often prefer multiple layers of security to help protect their data. This includes network-based access control protections as well as authentication and authorization-based protections. As part of the general availability of Firewalls and Virtual Networks for Storage and VNet Service Endpoints we enable network-based access control. These new network focused features allow the customer to define network access-based security ensuring that only requests coming from approved Azure VNets or specified public IP ranges will be allowed to a specific storage account. Customers can combine existing authorization mechanisms with the new network boundaries to better secure their data.

To enable VNet protection, first enable service endpoints for storage in the VNet. Virtual Network Service Endpoints allow you to secure your critical Azure service resource to only your virtual network. Service endpoints also provide optimal routing for Azure traffic over the Azure backbone in scenarios where Internet traffic is routed through virtual appliances or on-premises.

On the storage account you can select to allow access to one or more VNets. You may also configure to allow access to one or more public IP ranges. A detailed explanation on how to enable the network functionality can be found at Configure Azure Storage Firewalls and Virtual Networks.

Continue reading

Azure Site Recovery now supports Ubuntu

Azure Site Recovery makes business continuity accessible for all your IT applications by letting you use Azure as your recovery site. This offers a solution where you only pay for the resources you consume, alleviating the need to spend on upfront capital investments for a recovery location or resources.

We recognize our customer’s need to have flexibility in the choice of platforms and application stacks they use. That is why Azure Site Recovery supports a wide variety of platforms and operating systems. We’ve now added support for another very popular Linux distribution. Azure Site Recovery now supports disaster recovery and migration to Azure for servers running Ubuntu on Azure virtual machines or in a VMware virtualized environment. Azure Site Recovery currently supports disaster recovery and migration to Azure for applications on Ubuntu Server 14.04 LTS.

Let’s see how easy it is to achieve business continuity objectives for your Ubuntu workloads in the context of the fictional Bellows College.

A business continuity plan for Bellows College

Bellows College’s Moodle learning management system(LMS) is configured in a standard two-tier deployment, with a web server and a MySQL database running on VMware virtual machines running Ubuntu server 14.04 LTS.

Last year, a faulty surge protector in their datacenter caused an outage to their learning management system. Bellows College’s application and infrastructure administrators scampered to bring the system back up on an alternate storage unit by restoring data from their database backup. This experience taught them a costly lesson and left them with the realization that periodic backups are not a replacement for a business continuity plan.

Realizing they needed a reliable business continuity plan, Bellows College’s CIO decided to use Azure Site Recovery. Going to Azure was an easy choice for them, as they were already planning on migrating some of their applications to Azure to consolidate their datacenter costs.

With a few simple steps, Bellows College setup Azure Site Recovery and got their learning management system protected to Azure.

Bellows College built a recovery plan to sequence the order in which the various application tiers are brought up during a failover. For example, they specified that the database tier would be brought up before the web tier so that the web server could start serving requests immediately post failover. Within the recovery plan, Bellows College used Azure Automation runbooks to automate some of the common post-failover steps, like assigning an IP address to the failed over web server. By using automation, they were able to achieve a better RTO by avoiding the need to perform this step manually.

With their Moodle servers protected and the recovery plan setup, it was time to test their recovery plan. They did this using the test failover feature of ASR that lets them test failing over their applications without impacting production workloads or end users.

The test failover brought the application up in a test network in Azure with all the latest changes, and let them connect to the application in the test environment and validate that the application was working in a few minutes.

Being able to test the failover of the application to Azure without impacting production gave Bellows College the confidence that their business continuity plan gives them the necessary protection from unplanned events.

Having experienced how simple and cost-effective it is to use Azure Site Recovery to achieve business continuity, Bellows College is now planning to onboard some of their other supporting applications running on Ubuntu.

Azure Site Recovery is an all-encompassing service for your migration and disaster recovery needs. Our mission is to democratize disaster recovery with the power of Microsoft Azure so that you have a disaster recovery plan that covers all of you organization's IT applications.

Continue reading

Announcing Azure Files share snapshots public preview

Azure Files offers fully managed cloud file shares, and extends the ability of organizations to share files across on-premises and the cloud. With support for industry standard SMB protocol, this service is truly cross-platform and can support mounting as file share from any client that implements SMB 3.0 with encryption. Some examples are Windows, Mac, and Linux. In addition to native mount, it exposes REST APIs for programmability. With Azure Files, organizations get the added benefit of a storage infrastructure that is highly secure, massively scalable, and globally available. Even with all of these capabilities, what would you do if a user or application accidentally deletes or corrupts files or folders that are stored in Azure Files share?

Today, we are very excited to introduce the public preview of Azure Files share snapshots. Azure Files share snapshots allows you to periodically store read-only versions of your file shares. It also allows you to copy an older version of your content from anywhere for further modification and use.

When a share snapshot is created, the contents of the file share and the share snapshot are exactly the same. However, only the incremental changes are written to the snapshot. This makes snapshot creation faster, space-efficient, and cost-effective.

On Windows, you can leverage the familiar Previous Versions functionality, as shown below in Figure 1, where sharesnapshotdefs is a mounted Azure file share and each entry in the Previous Versions tab is a share snapshot. You can browse the content of the snapshot, right there in your explorer, by selecting “Open” or by copying the contents of that share snapshot back to its original location by selecting “Restore”. The same Previous Versions experience is available for individual directories or files. This means that while snapshots are taken at the share level, data retrieval can be done at both the file share and individual directory/file level.

Figure 1: Azure Files share snapshot experience on Windows – Integrated with “Previous Versions”

On Linux, you can use Azure CLI 2.0 for Azure Files, as shown below in Figure 2. All the same capabilities, including creation of snapshots, are available in Azure CLI 2.0.

Figure 2: Azure Files share snapshot experience on Azure CLI – List Snapshots

In addition to Azure CLI 2.0, snapshots are fully supported by REST and client libraries such as .Net and Python programmatic access. Also, PowerShell support is coming soon. To quickly get started, you can go directly to the Azure Portal today and start creating snapshot.

Figure 3: Azure Files share snapshot experience on Azure Portal

And what more - During our public preview, capacity consumed by snapshots will not be charged!

Azure Files share snapshots will be a key addition to your cloud storage management toolkit. To learn more about snapshots, please visit our documentation.

Continue reading

Hardening Azure Analysis Services with the new firewall capability

Azure Analysis Services (Azure AS) is designed with security in mind and takes advantage of the security features available on the Azure platform. For example, integration with Azure Active Directory (Azure AD) provides a solid foundation for access control. Any user creating, managing, or connecting to an Azure Analysis Services server must have a valid Azure AD user identity. Object-level security within a model enables you to define permissions at the table, row, and column levels. Moreover, Azure AS uses encryption to help safeguard data at rest and in transit within the local data center, across data centers, between data centers and on-premises networks, as well as across public Internet connections. The combination of Transport Layer Security (TLS), Perfect Forward Secrecy (PFS), and RSA-based 2,048-bit encryption keys provides strong protection against would-be eavesdroppers.

However, keeping in mind that Azure Analysis Services is a multi-tenant cloud service, it is important to note that the service accepts network traffic from any client by default. Do not forget to harden your servers by taking advantage of basic firewall support. In the Azure Portal, you can find the firewall settings when you display the properties of your Azure AS server. Click on the Firewall tab, as the following screenshot illustrates. You must be a member of the Analysis Services Admins group to configure the firewall.

Enabling the firewall without providing any client IP address ranges effectively closes the Azure AS server to all inbound traffic—except traffic from the Power BI cloud service. The Power BI service is whitelisted in the default "Firewall on" state, but you can disable this rule if desired. Click Save to apply the changes.

With the firewall enabled, the Azure AS server responds to blocked traffic with a 401 error code. The corresponding error message informs you about the IP address that the client was using. This can be helpful if you want to grant this IP address access to your Azure AS server. This error handling is different from a network firewall in stealth mode not responding to blocked traffic at all. Although the Azure AS firewall does not operate in stealth mode, it enables you to lock down your servers effectively. You can quickly verify the firewall behavior in SQL Server Management Studio (SSMS), as shown in the following screenshot.

You can also discover the client IP address of your workstation in the Azure Portal. On the Firewall page, click on Add client IP to add the current workstation IP address to the list of allowed IP addresses. Please note that the IP address is typically a public address, most likely assigned dynamically at your network access point to the Internet. Your client computer might not always use the same IP address. For this reason, it is usually advantageous to configure an IP range instead of an individual address. See the following table for examples. Note that you must specify addresses in IPv4 format.

Name	Start IP Address	End IP Address	Comments
ClientIPAddress	192.168.1.1	192.168.1.1	Grants access to exactly one IP address.
ClientIPAddresses	192.168.1.0	192.168.1.254	Grants access to all IP addresses in the 192.168.1.x subnet.
US East 2 Data Center	23.100.64.1	23.100.71.254	This is the address range 23.100.64.0/21 from the US East 2 data center.

Besides Power BI and client computers in on-premises networks, you might also want to grant specific Azure-based solutions access to your Azure AS server. For example, you could be using a solution based on Azure Functions to perform automated processing or other actions against Azure AS. If the Azure AS firewall blocks your solution, you will encounter the error message, “System.Net.WebException: The remote server returned an error: (401) Unauthorized.” The following screenshot illustrates the error condition.

In order to grant the Azure App Service access to your Azure AS server, you must determine the IP address that your function app uses. In the properties of your function app, copy the outbound IP addresses (see the following screenshot) and add them to the list of allowed client IP addresses in your firewall rules.

Perhaps you are wondering at this point how to open an Azure AS server to an entire data center. This is slightly more complicated because the Azure data center address ranges are dynamic. You can download an XML file with the list of IP address ranges for all Azure data centers from the Microsoft Download Center. This list is updated on a weekly basis, so make sure you check for updates periodically.

Note that the XML file uses the classless inter-domain routing (CIDR) notation, while the Azure AS Firewall settings expect the ranges to be specified with start and end IP address. To convert the CIDR format into start and end IP addresses, you can use any of the publicly available IP converter tools. Alternatively, you can process the XML file by using Power Query, as the following screenshot illustrates.

Download the Excel workbook and make sure you update the XmlFilePath parameter to point to the XML file you downloaded. For your convenience, the workbook includes a column called Firewall Rule Added, which concatenates the data center information into firewall rules as they would be defined in an Azure Resource Manager (ARM) template. The following screenshot shows an ARM template with several rules that grant IP address ranges from the US East 2 data center access to an Azure AS server.

The ARM template makes it easy to apply a large list of rules programmatically by using Azure PowerShell, Azure Command Line Interface (CLI), Azure portal, or the Resource Manager REST API. However, an excessively long list of IP addresses is hard to manage. Moreover, the Azure AS firewall must evaluate each rule for every incoming request. For this reason, it is recommended to limit the number of rules to the absolute necessary. For example, avoid adding approximately 3,500 rules for all IP ranges across all Azure data centers. Even if you limit the rules to your server’s local data center, there still may be more than 400 subnets. As a best practice, build your Azure AS business solutions using technologies that support static IP addresses, or at least a small set of dynamic IP addresses, as is the case with the Azure App Service. The smaller the surface area, the more effective the hardening of your Azure AS server.

Continue reading