Resumable Online Index Rebuild is in public preview for Azure SQL DB

We are delighted to announce that Resumable Online Index Rebuild (ROIR) is now available for public preview in Azure SQL DB. With this feature, you can resume a paused index rebuild operation from where the rebuild operation was paused rather than having to restart the operation at the beginning. Additionally, this feature rebuilds indexes using only a small amount of log space. You can use the new feature in the following scenarios:

Resume an index rebuild operation after an index rebuild failure (such as after a database failover or after running out of disk space). There is no need to restart the operation from the beginning. This can save a significant amount of time when rebuilding indexes for large tables.
Pause an ongoing index rebuild operation and resume it later. For example, you may need to temporarily free up system resources in order to execute a high priority task or you may have a single maintenance window that is too short to complete the operation for a large index. Instead of aborting the index rebuild process, you can pause the index rebuild operation and resume it later without losing prior progress.
Rebuild large indexes without using a lot of log space and have a long-running transaction that blocks other maintenance activities. This helps log truncation and avoid out of log errors that are possible for long running index rebuild operations.

For more information about ROIR please review the following documents

Guidelines for Online Index Operations
ALTER INDEX (Transact-SQL)
sys.index_resumable_operations

For public preview communication on this topic please contact the ResumableIDXPreview@microsoft.com alias.
Quelle: Azure

Database Scoped Global Temporary Tables in public preview for Azure SQL DB

We are delighted to announce that Database Scoped Global Temporary Tables are in public preview for Azure SQL DB. Similar to global temporary tables for SQL Server, tables prefixed with ##table_name, global temporary tables for Azure SQL DB are stored in tempdb and follow the same semantics. However, rather than being shared across all databases on the server, they are scoped to a specific database and are shared among all users’ sessions within that same database. User sessions from other Azure SQL databases cannot access global temporary tables created as part of running sessions connected to a given database.  Any user can create global temporary objects.

Example

Session A creates a global temp table ##test in Azure SQL Database testdb1 and adds 1 row

     T-SQL command

CREATE TABLE ##test ( a int, b int);
INSERT INTO ##test values (1,1);

Session B connects to Azure SQL Database testdb1 and can access table ##test created by session A

     T-SQL command

SELECT * FROM ##test
—Results
1,1

For more information on Database Scoped Global Temporary Tables for Azure SQL DB see  CREATE TABLE (Transact-SQL).
Quelle: Azure

Azure Data Lake Tools for Visual Studio Code (VSCode) July updates

We are pleased to announce the July updates of Azure Data Lake Tools for VSCode. This is a quality milestone and we added local debug capability for C# code behind for window users, refined Azure Data Lake (ADLA & ADLS) integration experiences, and focused on refactoring the components and fixing bugs. Azure Data Lake Tools for VSCode is an extension for developing U-SQL projects against Microsoft Azure Data Lake! This extension provides you a cross-platform, light-weight, and keyboard-focused authoring experience for U-SQL while maintaining a rich set of development functions. Summary of key updates Local Run for Windows Users This update allows you to perform local run to test your local data. Execute your script locally before publishing your production ready code to ADLA. Use command ADL: Start Local Run Service to start local run service. The cmd console shows up. For first time users, enter 3 and set up your data root. Use command ADL: Submit Job to submit your job to your local account. After job submission, you can view the submission details by clicking jobUrl in the output window, or view the job submission status from the CMD console. Local Debug for Window Users Local Debug enables you to debug your C# code behind, step through the code, and validate your script locally before submitting to ADLA. Use command ADL: Start Local Run Service to start local run service and set a breakpoint in your code behind, then click command ADL: Local Debug to start local debug service. You can debug through the debug console and view parameter, variable, and call stack information. Register assemblies through configuration Register assemblies through configuration provides you more flexibility to register your dependency and upload your resources. Use command ADL: Register Assembly through Configuration to register your assembly, register the assembly dependencies, and upload resources through a simple configuration. Upload file through configuration Upload file through configuration boosts your productivity and offers you the capability to upload multiple files at the same time. Use command ADL: Upload File through Configuration to upload multiple files through a simple configuration. How do I get started? First, install Visual Studio Code and download the prerequisite files including JRE 1.8.x, Mono 4.2.x (Linux and Mac), and .Net Core (Linux and Mac). Then get the latest ADL Tools by going to the VSCode Extension repository or VSCode Marketplace and searching “Azure Data Lake Tools for VSCode”. For more information about Azure Data Lake Tool for VSCode, please see: Get more information on using Data Lake Tools for VSCode. Watch the ADL Tools for VSCode User instructions video. Learn more about how to get started on Data Lake Analytics. Learn how to Develop U-SQL assemblies for Azure Data Lake Analytics jobs.   If you encounter any issues, please submit it to:  https://github.com/Microsoft/AzureDatalakeToolsForVSCode/issues Want to make this extension even more awesome? Share your feedback
Quelle: Azure

Azure Stream Analytics now available in UK West, Canada Central and East

As a part of our ongoing commitment to enable higher performance, and support customer requirements around data location, we’re pleased to announce that Azure Stream Analytics is now available in 3 additional regions: UK West, Canada Central, and Canada East.

With this announcement, Stream Analytics is now available in 26 Azure regions worldwide. For more information about local pricing, please visit Azure Stream Analytics pricing webpage.

Azure Stream Analytics is a serverless, scale-out job service built to help customers easily develop and run massively parallel real-time analytics across multiple streams of data using simple SQL like language. For example, a recent case study demonstrates how SkyAlert leveraged Azure Stream Analytics in conjunction with other Azure services to build an early-warning system that alerts citizens about an impending earthquake up to 2 minutes before it is felt, that could potentially save many precious lives in case of a natural disaster.

New to Azure Stream Analytics? Learn to build your first Stream Analytics application by following this step-by-step guide.
Quelle: Azure

Introducing the new Dv3 and Ev3 VM sizes

We are excited to announce the general availability of our new Dv3 VM sizes. We are also changing the naming for the high memory D sizes (D11-D14) to become the Ev3 family. These new sizes introduce Hyper-Threading Technology running on the Intel® Broadwell E5-2673 v4 2.3GHz processor, and the Intel® Haswell 2.4 GHz E5-2673 v3. The shift from physical cores to virtual CPU’s (vCPU) is a key architectural change that enables us to unlock the full potential of the latest processors to support even larger VM sizes. By unlocking more power from the underlying hardware, we are able to harness better performance and efficiency, resulting in cost savings that we are passing on to our customers. These new Hyper-Threaded sizes will be priced up to 28% lower than the previous Dv2 sizes. 

The Dv3 and Ev3 sizes are also some of the first VM’s to be running on Windows Server 2016 hosts.  Windows 2016 hosts enable Nested Virtualization and Hyper-V Containers for these new VM sizes.  Nested virtualization allows you to run a Hyper-V server on an Azure virtual machine. With nested virtualization you can run a Hyper-V Container in a virtualized container host, set-up a Hyper-V lab in a virtualized environment, or to test multi-machine scenarios. You can find more information on Nested Virtualization on Azure. 

Our new Dv3 VM sizes are a good balance of memory to vCPU performance, with up to 64 vCPU’s and 256GiB of RAM. Our newly named Ev3 sizes provide you with more memory to vCPU than the Dv3, so you can run larger workloads on sizes up to our largest E64 size,  with 64 vCPUs and 432GiB of RAM.

The current Dv2, DSv2, F, Fs and Av2 sizes, with the exception of our DS15v2 and the D15v2,  will also be available on our new Intel® Broadwell processors. The D15v2 and DS15v2 sizes are dedicated to our Intel® Haswell processors.

 

Size
vCPU’s
Memory:
GiB
Local SSD:
GiB
Max data disks
Max local disk throughput:
IOPS / Read MBps / Write MBps
Max NICs / Network bandwidth

Standard_D2_v3
2
8
50
4
3000/46/23
2 / moderate

Standard_D4_v3
4
16
100
8
6000/93/46
2 / moderate

Standard_D8_v3
8
32
200
16
12000/187/93
4 / high

Standard_D16_v3
16
64
400
32
24000/375/187
8 / high

Standard_E2_v3
2
16
50
4
3000/46/23
2 / moderate

Standard_E4_v3
4
32
100
8
6000/93/46
2 / moderate

Standard_E8_v3
8
64
200
16
12000/187/93
4 / high

Standard_E16_v3
16
128
400
32
24000/375/187
8 / high

Standard_E32_v3
32
256
800
32
48000/750/375
8 / extremely high

Standard_E64_v3
64
432
1600
32
96000/1000/500
8 / extremely high

 

Size
vCPU's   
Memory: GiB
Local SSD: GiB
Max data disks
Max cached and local disk throughput: IOPS / MBps (cache size in GiB)
Max uncached disk throughput: IOPS / MBps
Max NICs / Expected network performance (Mbps)

Standard_D2s_v3
2
8
16
4
4,000 / 32 (50)
3,200 / 48
2 / moderate

Standard_D4s_v3
4
16
32
8
8,000 / 64 (100)
6,400 / 96
2 / moderate

Standard_D8s_v3
8
32
64
16
16,000 / 128 (200)
12,800 / 192
4 / high

Standard_D16s_v3
16
64
128
32
32,000 / 256 (400)
25,600 / 384
8 / high

Standard_E2s_v3
2
16
32
4
4,000 / 32 (50)
3,200 / 48
2 / moderate

Standard_E4s_v3
4
32
64
8
8,000 / 64 (100)
6,400 / 96
2 / moderate

Standard_E8s_v3
8
64
128
16
16,000 / 128 (200)
12,800 / 192
4 / high

Standard_E16s_v3
16
128
256
32
32,000 / 256 (400)
25,600 / 384
8 / high

Standard_E32s_v3
32
256
512
32
64,000 / 512 (800)
51,200 / 768
8 / extremely high

Standard_E64s_v3
64
132
64
132
128,000/1024 (1600)
80,000 / 1200
8 / extremely

Geographic Availability

US

West 2
East 2

Europe

West

Asia Pacific

Southeast

We will be rapidly adding the other regions and we will provide more updates as these regions become available.

Update on Dv2 Promo

With the launch of Dv3 and Ev3, we will be winding down our Dv2 Promo offer in the regions noted above where Dv3 and Ev3 are available. During the transition in these regions, customers will continue to be able to deploy new instances of Dv2_promo VMs until 8/15/2017. In regions where Dv3 and Ev3 are not yet available, Dv2 Promo VMs will continue to be available for at least one month after the availability of Ev3 and Dv3 in that region.
 
All deployed Dv2_promo VMs will benefit from their promotional pricing until 6/30/2018 at which point prices will revert to match Dv2 pricing.
Quelle: Azure

Nested Virtualization in Azure

We announced nested virtualization support coming to Azure with Dv3 or Ev3 series at //build session last month.

Today we are excited to announce that you can now enable nested virtualization using the Dv3 and Ev3 VM sizes. We will continue to expand support to more VM sizes in the coming months.

For software and hardware prerequisites, configuration steps and limitations for nested virtualization please see the document here. In this blog we will discuss a couple interesting use cases and provide a short video demo for enabling a nested VM.

Now not only you can create a Hyper-V container with Docker (see instructions here), but also by running nested virtualization, you can create a VM inside a VM. Such nested environment provides great flexibility in supporting your needs in various areas such as development, testing, customer training, demo, etc. For example, suppose you have a testing team using Hyper-V hosts on-prem today. They can now easily move their workloads to Azure by using nested VMs as virtualized test machines. The nested VM hosts will be used to replace physical Hyper-V hosts, individual testing engineer will have full control over the Hyper-V functionality on their own assigned VM Host in Azure.

Let’s look at another example, suppose you want to run your development code, tests or applications on a machine with multiple users on it without impacting them, you can use the nested virtualization technology to spin up independent environments on demand to do that. Within nested VMs, even if you are running a chaos environment your users will not be impacted.

Ready to try it? Please see the video below with my engineer Charles Ding setting up nested VM (here is the link to the power shell script he created and used in the video).

We hope you enjoy using nested virtualization in Azure!
Quelle: Azure

Running Azure Batch jobs using the Azure CLI – no code required

When we introduced Azure Batch the target audience was the developer producing SaaS or client solutions where there was the need to run applications or algorithms at scale. Developers use the Batch APIs to integrate with Batch and utilize it as a component within their solution.

Since launch, we have been adding further capabilities that make it easier to use Batch without code and therefore expanding the audience that can take advantage of Batch. We are pleased to announce the recent addition of new Azure CLI capabilities that make it possible to define and run jobs end-to-end. Users can directly, or via scripting, create pools, upload data, run jobs at scale, and download output data – all using the Azure CLI, no code required.

Batch templates

Batch templates build on the existing Batch support in the Azure CLI that allows JSON files to specify property names and values for the creation of pools, jobs, tasks, and other items. With Batch templates, the following capabilities are available compared to what is possible with the JSON files:

Parameters can be defined. When the template is used, only the parameter values are specified to create the item, with other item property values being specified in the template body. A user who understands Batch and the applications to be run by Batch can create the templates, specifying pool, job, and task property values. A user less familiar with Batch and/or the applications simply needs to specify the values for the defined parameters.
Job task factories create the one or more tasks associated with a job, avoiding the need for many task definitions to be created and drastically simplifying job submission.

Upload and download of input and output files

Input data files need to be supplied for jobs and output data files are often produced. A storage account is associated, by default, with each Batch account; using the Azure CLI, files can now be easily transferred between a client and this storage account, with no coding required. Additionally, files are referenced by pool and job templates for transfer to and from pool nodes.

Example – transcoding video files using ffmpeg

ffmpeg is a popular application that processes audio and video files. The Azure Batch CLI can be used to invoke ffmpeg to transcode multiple video files in parallel, converting source video files to different resolutions.

Create a pool template

A pool of VM nodes will be required on which the ffmpeg application will need to be installed and on which individual transcodes will be run. Someone with knowledge of Batch and ffmpeg defines a pool template. The template is written so that when it is used to create the pool, only a pool id and number of nodes need to be specified.

The template defines:

Two parameters whose values need to be supplied when the template is used to create a pool – the pool id and the number of pool nodes.
The template body specifies the OS, VM sizes, the ffmpeg package, and other pool properties.

An example pool template would be:

{
      "parameters": {
          "nodeCount": {
              "type": "int",
              "metadata": { "description": "The number of pool nodes" }
          },
          "poolId": {
              "type": "string",
              "metadata": { "description": "The pool id " }
          }
      },
      "pool": {
          "type": "Microsoft.Batch/batchAccounts/pools",
          "apiVersion": "2016-12-01",
          "properties": {
              "id": "[parameters('poolId')]",
              "virtualMachineConfiguration": {
                  "imageReference": {
                      "publisher": "Canonical",
                      "offer": "UbuntuServer",
                      "sku": "16.04.0-LTS",
                      "version": "latest"
                  },
                  "nodeAgentSKUId": "batch.node.ubuntu 16.04"
              },
              "vmSize": "STANDARD_D3_V2",
              "targetDedicatedNodes": "[parameters('nodeCount')]",
              "enableAutoScale": false,
              "maxTasksPerNode": 1,
              "packageReferences": [
                  {
                      "type": "aptPackage",
                      "id": "ffmpeg"
                  }
              ]
} } }

Create a job template

To transcode the video files, a job will be created with one task per video file. Each task needs to invoke the ffmpeg application with parameters specifying the source video file that will be copied onto the node, the target resolution, the output file name and location, as well as other task properties.

Someone with knowledge of Batch and ffmpeg defines a job template. This template has been written so that when it is used only the pool id and job id need to be specified. For simplicity, it is assumed that source files will be uploaded to a fixed location, the output files will be written to a fixed location, and the output resolution is set to a specific value.

{
      "parameters": {
          "poolId": {
              "type": "string",
              "metadata": {
                  "description": "The pool id which runs the job"
              }
          },
          "jobId": {
              "type": "string",
              "metadata": {
                  "description": "The job id"
              }
          },
          "resolution": {
              "type": "string",
              "defaultValue": "428×240",
              "allowedValues": [
                  "428×240",
                  "854×480"
              ],
              "metadata": {
                  "description": "Target video resolution"
              }
          }
      },
      "job": {
          "type": "Microsoft.Batch/batchAccounts/jobs",
          "apiVersion": "2016-12-01",
          "properties": {
              "id": "[parameters('jobId')]",
              "constraints": {
                  "maxWallClockTime": "PT5H",
                  "maxTaskRetryCount": 1
              },
              "poolInfo": {
                  "poolId": "[parameters('poolId')]"
              },
              "taskFactory": {
                  "type": "taskPerFile",
                  "source": {
                      "fileGroup": "ffmpeg-input"
                  },
                  "repeatTask": {
                      "commandLine": "ffmpeg -i {fileName} -y -s [parameters('resolution')] -strict -2 {fileNameWithoutExtension}_[parameters('resolution')].mp4",
                      "resourceFiles": [
                          {
                              "blobSource": "{url}",
                              "filePath": "{fileName}"
                          }
                      ],
                      "outputFiles": [
                          {
                              "filePattern": "{fileNameWithoutExtension}_[parameters('resolution')].mp4",
                              "destination": {
                                  "autoStorage": {
                                      "path": "{fileNameWithoutExtension}_[parameters('resolution')].mp4",
                                      "fileGroup": "ffmpeg-output"
                                  }
                              },
                            "uploadOptions": {
                                 "uploadCondition": "TaskSuccess"
                             }
                          }
                      ]
                  }
              },
              "onAllTasksComplete": "terminatejob"
} } }

 

Create a pool using the pool template

A user with files to transcode can first create a pool containing the nodes which will perform the transcodes. If scripted, the parameter values can be passed in the command line; if invoked directly the user will be prompted for the parameter values.

C:BatchCliTemplates>az batch pool create –template pool-ffmpeg.json
You are using an experimental feature {Pool Template}.
nodeCount (The number of pool nodes): 20
poolId (The pool id): MyFfmpegPool

As a user of the template, I haven’t had to understand Azure VM sizes, pool properties, and how to install ffmpeg.

Upload source files to transcode

I need to upload the files to be transcoded to Azure. I was supplied the name of the file group to use, which equates to a container created on the Azure Storage account associated with the Batch account.

az batch file upload –local-path c:source_videos*.mp4 –file-group ffmpeg-input

Run a job to transcode the source files using the job template

A job needs to be created that will have one task per input file that was uploaded. If scripted, the parameter values can be passed in the command line; if invoked directly the user will be prompted for the parameter values.

az batch job create –template job-ffmpeg.json

As a user of the template, I haven’t had to understand how to invoke ffmpeg, specifying the appropriate parameters to perform transcoding, plus I haven’t had to specify the Batch properties for jobs and tasks.

Download the transcoded files

If the transcoded output files are required on the client then they can easily be downloaded.

az batch file download –file-group ffmpeg-output –local-path c:output_lowres_videos

Summary

This example has shown how a user has been able to create a Batch pool and job template to perform video transcoding using ffmpeg. The user has not needed to use the Batch APIs; they have needed knowledge of the ffmpeg application and Azure Batch. To use the templates, an end-user simply has to use the Azure CLI to upload the files to transcode, download the output files, and supply the pool and job template parameter values.

More information

More detailed information is available:

Azure Batch CLI documentation
Detailed documentation, samples, and source code in the Azure GitHub repository for the Batch extension.

Quelle: Azure

Mesosphere DCOS, Azure, Docker, VMware & Everything Between – Deploying DC/OS on VMware vSphere

This post is part of the “Mesosphere DC/OS, Azure, Docker, VMware & Everything Between” multiple blog post series. In the previous posta for this series, I looked at the following topics:

Mesosphere DCOS, Azure, Docker, VMware and everything between – Architecture and CI/CD Flow

Mesosphere DCOS, Azure, Docker, VMware and everything between – Security & Docker Engine Installation

Mesosphere DCOS, Azure, Docker, VMware & Everything Between – SSH Authorized Keys

Now that we have the Docker engine up and running and all of our network & security related configurations in place, it’s time to get the DC/OS cluster rolling on top of VMware vSphere. This is the first major milestone in our entire platform setup. Let’s get moving…

Since this is not a “DC/OS Deep Dive” series, I will not go into much details on DCOS components, but I will provide relevant info on why things the way they are.

Before diving into the installation steps, I highly recommend going over to DCOS Node Types and Network KBs.

For our vSphere DCOS cluster deployment, I will not deploy public agent nodes. To understand why, we need to go back and review the CI/CD flow.

As you remember, in our flow, the “production containers” stops at the DCOS cluster deployed on vSphere. The reason for not deploying public nodes (think of them as your DMZ deployed hosts) is customer requirement to have the production containers available only from corporate LAN or via VPN. Later on, the plan is to provide internet access via the corporate load balancer but to keep things nice and simple, we will deploy only the private agents.

The agent nodes are responsible for hosting your Docker containers and for this deployment, we will have 3 of those.

 

Read more about all the details around DC/OS 1.9 deployment on top of VMware vSphere on my blog.
Quelle: Azure

Service Fabric Community Q&A 14th Edition

We will host our 14th monthly community Q&A call Thursday, July 20th at 10 AM Pacific Time.

The Service Fabric Community Q&A is hosted on the third Thursday of every month by the Azure Service Fabric engineering team. The session provides an opportunity for you to ask any questions you have about Service Fabric.

This is an open event. As always, there is no need to RSVP. Just navigate to http://aka.ms/sfcommunityqa at 10 AM Thursday and you are in!

ICS calendar link: service-fabric-community-qa-14

Talk to you then!

The Service Fabric Team
Quelle: Azure

Azure Container Registry adds individual identity, webhooks, and delete capabilities

The Azure Container Registry team is excited to share a preview of new Container Registry SKUs with more capabilities and features.

The new preview of Azure Container Registry managed tier is available in 3 options including Basic, Standard, and Premium.

These new container registries are available in preview within 3 regions including East US, West Europe, and West Central US. Support for other regions will roll out over the course of the following weeks based on feedback.

The new features available include:

AAD authentication for repositories
Delete operations
Webhook support

Managed SKUs

The images in these SKUs will be stored in Storage Accounts managed by the ACR service, rather than relying on a storage account specified for the user. This change improves reliability and enables new features that weren't possible in the original offering. It will still be possible to create and use registries that rely on your own storage account if you wish to continue using this model.

Individual AAD authentication

Previously, there were only two ways to authenticate access to a registry, by enabling the single admin account or by setting up a service principal. Now with managed registries you can sign in to a registry using your AAD credentials. This automatically works for any managed registry you create. When you sign in via the portal or the az cli, you will have access to all the registries under your AAD account. Moreover, if you sign in with your AAD credentials you won't have to pass in credentials again when pushing images to your repositories.

To authenticate with AAD using the command line, sign in to your Azure account using "az login" in the Azure CLI 2.0. Once logged in, use the command "az acr login" and it will automatically pick up the credentials you used to sign in to your Azure account.

Delete functionality

The new registry SKUs allow you to execute one of our most requested features, repository delete. You can delete specific repositories, images, or tags from your registry without having to delete the entire registry. The feature is available as a context menu in the Azure portal, or via the az acr repository delete api.

Webhook support

To enable cloud connected workflows, we’ve added webhook notifications for registries. You can configure these webhooks to get triggered by push and/or delete actions. Additionally, you can modify the scope of the webhook so that it gets triggered by these actions occurring for any repositories in the registry, a specific repository, or a specific tag.

You can also easily test out the webhook by pinging it and then viewing events of when the webhook was triggered. For a specific event, you can see the request and the responses to help further test or diagnose issues. Webhook support is available both in the Portal and the az acr webhook cli.

Pricing

Please see the ACR pricing page for details. During preview these SKUs will have a 50% discount.

Summary

Individual AAD support, delete, and Webhook functionality were designed with the goal of enabling you to do even more with your container registries. We hope you enjoy the new features available for the Azure Container Registry. You can try them out today by creating a new registry in East US, West Europe, or Central US EUAP and selecting Managed Registries as your SKU.

If you have any feedback or questions, please leave a comment below or reach out through our GitHub or StackOverflow.

– The Azure Container Registry Team
Quelle: Azure