Azure Site Recovery available in five new regions

To increase our service global footprint, we recently announced the expansion of Azure Site Recovery to Canada and UK regions. Apart from these two new countries, we have also deployed our service in West US2, making it available to all non-government Azure regions in the United States.

With this expansion, Azure Site Recovery is now available in 27 regions worldwide including Australia East, Australia Southeast, Brazil South, Central US, East Asia, East US, East US2, Japan East, Japan West, North Europe, North Central US, Southeast Asia, South Central US, West Central US, West US2, US Gov Virginia, US Gov Iowa, West Europe, West US, North East China, East China, South India,Central India, UK South, UK West, Canada East, and Canada Central​.

Customers can now select any of the above regions to deploy ASR. Irrespective of the region you choose to deploy in, ASR guarantees the same reliability and performance levels as set forth in the ASR SLA. To learn more about Azure Site Recovery visit Getting started with Azure Site Recovery. For more information about the regional availability of our services, visit the Azure Regions page.
Quelle: Azure

40TiB of advanced in-memory analytics with Azure and ActivePivot

In-memory computing has accelerated the big compute capabilities and enabled customers to extend its experience beyond just the monte carlo simulation and into the analytics. This is of note within Financial Services where business users wish to move away from pre-canned reports and instead directly interact with data. With Azure, banks can analyze in real-time and make the right decisions intraday and be more equipped to meet the regulatory standards. This blog will look to explore the new possibilities of a scale out architecture for in-memory analytics in Azure through ActivePivot. ActivePivot is part of the ActiveViam platform that brings big compute and big data closer together.

ActivePivot is an in-memory database that aggregates large amounts of fast-moving data through incremental, transactional, and analytical processing to enable customers to make the right decisions in a short amount of time. ActivePivot computes sophisticated metrics on data that is updated on the fly without the need for any pre-aggregation and allows the customer to explore metrics across hundreds of dimensions, analyze live data at its most granular level, and perform what-if simulations at unparalleled speed.

For customers to enable this on-premise, purchasing servers with enough memory can be expensive and is often saved for mission critical workloads. However, the public cloud opens this up to more workloads for research and experimentation, and taking this scenario to Azure is compelling. Utilizing Azure blob storage to collect and store the historical datasets generated over a period of time allows the customer to use the compute only when the user requires it. Starting from scratch to being fully deployed in less than 30 minutes drastically reduces the total cost of ownership and provides enormous business agility.

For our testing, we collectively processed 400 days of historical data to show how 40TB can be loaded onto 128 node cluster in 15 minutes to query 200Bn records in less than 10 seconds. For this we used the G5 instance with 32 cores and 448GiB of RAM running a Linux image with Java and ActivePivot and 40 storage accounts with 10 days of data, roughly 1TB in each.

The graph above shows the rate of data transfer over a five minute period.

 

Utilizing a special cloud connector, ActivePivot pulls from several storage accounts to transfer at 50 GiB per second. This ActiveViam cloud connector opens several HTTP connections to help fully saturate the bandwidth of the VM and storage and is tailored towards large files.

In parallel to the data fetching, ActivePivot indexes this data in-memory so to accelerate the analytical workloads. The ActivePivot query nodes distribute the calculations automatically across the data nodes and does not require any cross-node transfer. We expected to see performance near linear scale as we double the CPU, memory, and data size and we were very pleased to see it track with our expectation.

As you can see on the graph below, when we multiplied the dataset by 64, from 600 GiB up to 37.5 TiB, the throughput has increased 54 times.

This test proved to be very successful for us as we were able to execute extensive queries over the entire dataset in less than 10 seconds, but to see more detail and a step-by-step process, please visit the ActiveViam blog. We will also be following up with further scale-up testing later in the year so watch this space.

 For more information on Big Compute within Financial Services, please visit HPC Financial Services page or HPC on Azure.
Quelle: Azure

Azure Data Factory offer SAP HANA and Business Warehouse data integration

Azure Data Factory is a cloud-based data integration service that orchestrates and automates the movement and transformation of data, which support copying data from 25+ data stores on-premises and in the cloud easily and performantly. Today, we are excited to announce that Azure Data Factory newly enable loading data from SAP HANA and SAP Business Warehouse (BW) into various Azure data stores for advanced analytics and reporting, including Azure Blob, Azure Data Lake, Azure SQL DW, etc.

What’s new

SAP is one of the most widely-used enterprise software in the world. We hear you that it’s crucial for Microsoft to empower customers to integrate their existing SAP system with Azure to unblock business insights. Azure Data Factory start the SAP data integration support with SAP HANA and SAP BW, which are the most popular ones in the SAP stack used by enterprise customers.

With this release, you can easily ingest data from the existing SAP HANA and SAP BW to Azure, so as to build your own intelligent solutions by leveraging Azure’s first-class information management services, big data stores, advanced analytics tools, and intelligence toolkits to transform data into intelligent action. More specifically:

The SAP HANA connector supports copying data from HANA information models (such as Analytic and Calculation views) as well as Row and Column tables using SQL queries. To establish the connectivity, you need to install the latest Data Management Gateway (version 2.8) and the SAP HANA ODBC driver. Refer to SAP HANA supported versions and installation on more details.
The SAP BW connector supports copying data from SAP Business Warehouse version 7.x InfoCubes and QueryCubes (including BEx queries) using MDX queries. To establish the connectivity, you need to install the latest Data Management Gateway (version 2.8) and the SAP NetWeaver library. Refer to SAP BW supported versions and installation on more details.

What’s next

Beyond SAP HANA and SAP BW support, we also want to learn from you what other services in SAP stack you are using and looking to integrate. Go vote and comment on Azure feedback site.

Get started

To try out the new capabilities, provision a Data Factory from the Azure portal if you don’t have one, then click Copy Data to launch the intuitive copy wizard which will guide you through the configurations. In the source data store gallery, you will find SAP HANA and SAP BW as follows:

SAP HANA

After selecting SAP HANA from the gallery, specify the connection info on Data Management Gateway name, HANA server, user name and password. 

Then you will see a page with navigator and query editor. Browse and pick the measures and dimensions, a base SQL query will be auto generated in the Query Editor as reference according to your selection, and you can review and further customize there. Click Validate Query to see the preview data and schema. 

SAP BW

After selecting SAP BW from the gallery, specify the connection info on Data Management Gateway name, BW server, system number, client ID, user name and password. 

Then you will see a page with navigator and query editor. Browse and pick the measures and dimensions, a base MDX query will be auto generated in the Query Editor as reference according to your selection, and you can review and further customize there. Click Validate Query to see the preview data and schema.

Once you finish your settings on SAP source, continue following the wizard to configure the destination.

Reference

Learn more on Azure Data Factory from Introduction to Azure Data Factory and Move data by using Copy Activity
Refer to SAP HANA support and SAP Business Warehouse support respectively on connector details

Quelle: Azure

Data Simulator For Machine Learning

Virtually any data science experiment that uses a new machine learning algorithm requires testing across different scenarios. Simulated data allows one to do this in a controlled and systematic way that is usually not possible with real data.

A convenient way to implement and re-use data simulation in Azure Machine Learning (AML) Studio is through a custom R module. Custom R modules combine the convenience of having an R script packaged inside a drag and drop module, with the flexibility of custom code where the user has the freedom of adding and removing functionality parameters, seen as module inputs in the AML Studio GUI, as needed. A custom R module has identical behavior to native AML Studio modules. Its input and output can be connected to other modules or be set manually, and they can process data of arbitrary schema, if the underlying R code allows it, inside AML experiments. An added benefit is that they provide a convenient way of deploying code without revealing the source, which may be convenient for IP sensitive scenarios. By publishing it in Cortana Intelligence Gallery one can easily expose to the world any algorithm functionality without worrying about classical software deployment process.

Data simulator

We present here an AML Studio custom R module implementation of a data simulator for binary classification. Current version is simple enough to have the complete code inside Cortana Intelligence Gallery item page. It allows one to generate custom feature dimensionality datasets with both label relevant and irrelevant columns. Relevant features are univariately correlated with the label column. Correlation directionality (i.e. positive or negative correlation coefficient) is controlled by correlationDirectionality parameter(s). All features are generated using separate runif calls. In the future, the module functionality can be further extended to allow the user to choose other distributions by adding and exposing ellipsis/three dots argument feature in R. Last module parameter (seedValue) can be used to control results reproducibility. Figure 1 shows all module parameters exposed in AML Studio.

 

Figure 1. Data Simulator Custom R module in an AML Experiment. 1000000 samples are simulated, with 1000 irrelevant and 10 label relevant columns. Data is highly imbalanced since only 20 samples are of “FALSE” class. 2 values (.03 and 5) long array value for the “noiseAmplitude” property is reused for all relevant columns. Similarly, the sign of the 4 values (1, -1, 0, 3.5) “label-features correlation” property is reused for all 10 relevant columns to control the correlation directionality (i.e. positive or negative) with the label column.​

By visualizing, as shown below in Figure 2, the module output (right click and then “Visualize”), we can check basic properties of the data. This includes data matrix size and univariate statistics like range and missing values.

 

Figure 2. Visualization of simulated data. Data has 1,000,000 rows and 1011 columns (10 relevant and 1000 irrelevant feature columns, plus label). Histogram of the label column (right graph) indicate large class imbalance chosen for this simulation.​

Univariate Feature Importance Analysis of simulated data

Note: Depending on the size chosen for simulated data, it may take some time to generate them: e.g. 1 hour for a 1e6 rows x 2000 feature columns (2001 total columns) dataset. However, new modules can be added to the experiment even after data were generated, and the cashed data can be processed as described below without having to simulate them again.

Univariate Feature Importance Analysis (FIA) measures similarity between each feature column and label values using metrics like Pearsonian Correlation and Mutual Information (MI). MI is more generic than Pearsonian Correlation since it has the nice property that it does not depend of directionality of data dependence: a feature that has labels of one class (say “TRUE”) for all middle values, and the other class (“FALSE”) for all small and large values will still have a large MI value although its Pearsonian Correlation may be close to zero.

Although feature-wise univariate FIA does not capture multivariate dependencies, it provides a simple to understand picture of the relationship between features and classification target (labels). An easy way to perform univariate FIA in AML Studio is by employing existing AML module for Filter Based Feature Selection for similarity computation and Execute R Script module(s) for results concatenation. To do this, we extend the default experiment deployed though CIS gallery page by adding several AML Studio modules as described below.

We first add a second Filter Based Feature Selection module, and we choose Mutual Information value for its “Feature scoring method” property. The original Filter Based Feature Selection module, with “Feature scoring method” property set to Pearson Correlation should be left unchanged. For both Filter Based Feature Selection modules, the setting for “Number of desired features” property is irrelevant. since we will use the similarity metrics computed for all data columns, available by connecting to the second (right) output of each Filter Based Feature Selection module. The “Target column” property for both modules needs to point to the label column name in the data. Figure 3 shows the settings chosen for the second Filter Based Feature Selection module.

Figure 3. Property settings for the Filter Based Feature Selection AML Studio module added for Mutual Information computation. By connecting to the right side output of the module we get the MI values for all data columns (features and label).​

The next two Execute R Script module(s) added to the experiment are used for results concatenation. Their scripts are listed below.

First module (rbind with different column order):

dataset1 <- maml.mapInputPort(1) # class: data.frame
dataset2 <- maml.mapInputPort(2) # class: data.frame

dataset2 <- dataset2[,colnames(dataset1)]
data.set = rbind(dataset1, dataset2)

maml.mapOutputPort("data.set")

Second module (add row names):

dataset <- maml.mapInputPort(1) # class: data.frame

myRowNames <- c("PearsCorrel", "MI")
data.set <- cbind(myRowNames, dataset)
names(data.set)[1] <- c("Algorithms")

maml.mapOutputPort("data.set")

The last module, Convert to CSV, added to experiment allows one to download the results in a convenient format (csv) if needed. The results file is in plain text and can be opened in any text editor or Excel (Figure 4):

Figure 4. Downloaded results file visualized in Excel.

Simulated data properties

FIA results for relevant columns are shown in Figure 5. Although MI and Pearsonian correlation are on different scales, both similarity metrics are well correlated. They are also in sync with the “noiseAmplitude” property of the custom R module described in Figure 1. The 2 noiseAmplitude values (.03 and 5) are reused for all 10 relevant columns, such that relevant features 1, 3, 5, 7, and 9 are much better correlated with the labels dues to their lower noise amplitude.

Figure 5. FIA results for the 10 relevant features simulated before. Although MI (left axis) and Pearsonian correlation (right axis) are on different scales, both similarity metrics are well correlated.​

As expected, for each of the 1000 irrelevant features columns, min, max and average statistics for both MI and Pearsonian Correlation are below 1e-2 (see Table 1).

 

PearsCorrel

MI

min

9.48E-07

3.23E-07

max

3.93E-03

8.31E-06

average

7.67E-04

3.02E-06

stdev

5.84E-04

1.27E-06

Table 1. Statistics of similarity metrics for the 1000 irrelevant columns simulated above.

This result is heavily dependent on sample size (i.e. number of simulated rows). For significantly smaller row sizes than 1e3 used here, the max and average MI and Pearsonian Correlation values for irrelevant columns may be larger due to the probabilistic nature of simulated data.

Conclusion

Data simulation is an important tool for understanding ML algorithms. The Custom R module presented here is available in Cortana Intelligence Gallery and its results can be analyzed using AML module for Filter Based Feature Selection. Future extension of the algorithm should include regression data and multivariate dependencies.
Quelle: Azure

Azure SQL Data Warehouse now generally available in 27 regions worldwide

We are excited to announce the general availability of Azure SQL Data Warehouse in four additional regions—Germany Central, Germany Northeast, Korea Central, and Korea South. This takes the SQL Data Warehouse worldwide availability to 27 regions, more than any other major cloud provider.

SQL Data Warehouse is your go-to SQL-based fully managed, petabyte-scale cloud solution for data warehousing. SQL Data Warehouse is highly elastic, enabling you to provision in minutes and scale capacity in seconds. You can scale compute and storage independently, allowing you to burst compute for complex analytical workloads or scale down your warehouse for archival scenarios, and pay based off what you&;re using instead of being locked into predefined cluster configurations. Unlike other cloud data warehouse services, SQL Data Warehouse offers the unique option to pause compute, giving you even more freedom to better manage your cloud costs.

With general availability, SQL Data Warehouse offers an availability SLA of 99.9%, the only public cloud data warehouse service that offers an availability SLA to customers. Geo-Backups support has also been added to enable geo-resiliency of your data, allowing SQL Data Warehouse Geo-Backup to be restored to any region in Azure. With this feature enabled, backups are available even in the case of a region-wide failure, keeping your data safe. Learn more about the capabilities and features on SQL Data Warehouse with general availability.

Get started with SQL Data Warehouse today and experience the speed, scale, elasticity, security, and ease of use of a cloud-based data warehouse for yourself.

Azure SQL Data Warehouse is generally available across the following regions:

North Europe, North Central US, Central US, East US, East US 2, South Central US, West Central US, West US, West US 2, Canada Central, Canada East, West Europe, Germany Central, Germany Northeast, East Asia, Southeast Asia, Australia Southeast, Central India, South India, China East, China North, Japan East, and Brazil South.

Germany Central, Germany Northeast, Korea Central, Korea South, North Europe, Japan East, Brazil South, Australia Southeast, Central US, East US, East US 2, South Central US, West Central US, West US, West US 2, West Europe, East Asia, Southeast Asia, Central India, South India, Canada Central, and Canada East.

Learn more about Azure services availability across regions.

Learn more

Check out the many resources for learning more about SQL Data Warehouse:

What is Azure SQL Data Warehouse?

SQL Data Warehouse best practices

Videos

MSDN forum

Stack Overflow forum
Quelle: Azure

February 2017 Leaderboard of Database Systems contributors on MSDN

The Leaderboard initiative was started in October last year to recognize the top contributors on MSDN forums related to Database Systems. Many congratulations to the February 2017 top-10 contributors!

Hilary Cotter and Alberto Morillo top the Overall and Cloud database lists this month. The first 7 featured in last month’s Overall Top-10 as well.

The following continues to be the points hierarchy (in decreasing order of points):

For questions related to this leaderboard, please write to leaderboard-sql@microsoft.com
Quelle: Azure

An introduction to Azure Analysis Services on Microsoft Mechanics

Last year in October we released the preview of Azure Analysis Services, which is built on the proven analytics engine in Microsoft SQL Server Analysis Services. With Azure Analysis Services you can host semantic data models in the cloud. Users in your organization can then connect to your data models using tools like Excel, Power BI, and many others to create reports and perform ad-hoc data analysis.

I joined Jeremy Chapman on Microsoft Mechanics to discuss the benefits of Analysis Services in Azure.

 

 

Try the preview of Azure Analysis Services and learn about creating your first data model.
Quelle: Azure

Instant File Recovery from Azure Linux VM backup using Azure Backup – Preview

We earlier announced Instant file recovery from Azure Windows VM backups which enables you to restore files instantly from the Azure Recovery Services Vault with no additional cost or infrastructure. Today, we are excited to announce the same feature for Azure Linux VM backups in preview. If you are new to Azure Backup, you can start backing directly from the Azure IaaS VM blade and start using this feature. Value proposition: Instant recovery of files – Now instantly recover files from the cloud backups of Azure VMs. Whether it’s accidental file deletion or simply validating the backup, instant restore drastically reduces the time to recover your data. Mount application files without restoring them – Our iSCSI-based approach allows you to open/mount application files directly from cloud recovery points to application instances, without having to restore them. For e.g. In case of backup of a Azure Linux VM running mongoDB, you can mount BSON data dumps from the cloud recovery point and quickly validate the backup or retrieve individual items such as tables without having to download the entire data dump. Learn how to instantly recover files from Azure Linux VM backups:     Basic requirements The downloaded recovery script can be run on a machine which meets the following requirements. OS of the machine where the script is run (recovery machine) should support/recognize the underlying file-system of the files present in the backed-up Linux VM. Ensure that the OS of the recovery machine is compatible with the backed up VM and the versions are as mentioned in the following table Linux OS Versions Ubuntu 12.04 and above CentOS 6.5 and above RHEL 6.7 and above Debian 7 and above Oracle Linux 6.4 and above The script requires python and bash components to execute and provide a secure connection to the recovery point. Component Version Python 2.6.6 and above Bash 4 and above Only users with root level access can view the paths mounted by the script.   Advanced configurations Recovering files from LVM/Software RAID Arrays: In case you are using LVM/RAID Arrays in the backed-up Linux VM,  you cannot run the script on the same virtual machine due to disk conflicts. Run the script on any other Recovery machine (meeting the basic requirements as mentioned above) and the script will attach the relevant disks as shown in the output below. The following additional commands need to be run by the user to make LVM/RAID Array partitions visible and online. For LVM Partitions: $ pvs <volume name as shown above in the script output>  –  This will list all the volume groups under this physical volume $ lvdisplay <volume-group-name from the previous command’s result>  –  This will list all logical volumes, names and their paths in a volume group $ mount <LV path> </mountpath> –  Now mount the logical volumes to a path of your choice.   For RAID Arrays: $ mdadm –detail –scan – This will display details about all RAID Disks in this machine. The relevant RAID disk from the backed-up VM will be displayed with its name (</dev/mdm/<RAID array name in the backed up VM>) If the RAID Disk has physical volumes, mount the disk directly to view all the volumes within it. $ mount [RAID Disk Path] [/mounthpath] If the RAID disk was used to configure LVM over and above it, then re-use the process defined for LVM above and supply the volume name as an input.   Related links and additional content Want more details about this feature? Check out Azure Backup Linux Restore documentation Need help? Reach out to Azure Backup forum for support Tell us how we can improve Azure Backup by contributing new ideas and voting up existing ones. Follow us on Twitter @AzureBackup for the latest news and updates New to Azure Backup, sign up for a free Azure trial subscription 
Quelle: Azure

doAzureParallel: Take advantage of Azure’s flexible compute directly from your R session

Users of the R language often require more compute capacity than their local machines can handle. However, scaling up their work to take advantage of cloud capacity can be complex, troublesome, and can often distract R users from focusing on their algorithms.

We are excited to announce doAzureParallel – a lightweight R package built on top of Azure Batch, that allows you to easily use Azure’s flexible compute resources right from your R session.

At its core, the doAzureParallel package is a parallel backend, for the widely popular foreach package, that lets you execute multiple processes across a cluster of Azure virtual machines. In just a few lines of code, the package helps you create and manage a cluster in Azure, and register it as a parallel backend to be used with the foreach package.

With doAzureParallel, there’s no need to manually create, configure, and manage a cluster of individual virtual machines. Instead, this package makes running your jobs at scale no more complex than running your algorithms on your local machine. With Azure Batch’s autoscaling capabilities, you can also increase or decrease the size of your cluster to fit your workloads, helping you to save time and/or money.

doAzureParallel also uses the Azure Data Science Virtual Machine (DSVM), allowing Azure Batch to easily and quickly configure the appropriate environment in as little time as possible.

There is no additional cost for these capabilities – you only pay for the Azure VMs you use.

doAzureParallel is ideal for running embarrassingly parallel work such as parametric sweeps or Monte Carlo simulations, making it a great fit for many financial modelling algorithms (back-testing, portfolio scenario modelling, etc).

Installation / Pre-requisites

To use doAzureParallel, you need to have a Batch account and a Storage account set up in Azure. More information on setting up your Azure accounts.

You can install the package directly from Github. More information on install instructions and dependencies.

Getting Started

Once you install the package, getting started is as simple as few lines of code:

Load the package:

library(doAzureParallel)

Set up your parallel backend (which is your pool of virtual machines) with Azure:

# 1. Generate a pool configuration json file.
generateClusterConfig(“pool_config.json”)

# 2. Edit your pool configuration file.
# Enter your Batch account & Storage account information and configure your pool settings

# 3. Create your pool. This will create a new pool if your pool hasn’t already been provisioned.
pool <- makeCluster(“pool_config.json”)

# 4. Register the pool as your parallel backend
registerDoAzureParallel(pool)

# 5. Check that your parallel backend has been registered
getDoParWorkers()

Run your parallel foreach loop with the %dopar% keyword. The foreach function will return the results of your parallel code.

number_of_iterations <- 10
results <- foreach(i = 1:number_of_iterations) %dopar% {
    # This code is executed, in parallel, across your Azure pool.
    myAlgorithm(…)
}

When developing at scale, it is always recommended that you test and debug your code locally first. Switch between %dopar% and %do% to toggle between running in parallel on Azure and running in sequence on your local machine.

# run your code sequentially on your local machine
results <- foreach(i = 1:number_of_iterations) %do% { … }

# use the doAzureParallel backend to run your code in parallel across your Azure pool
results <- foreach(i = 1:number_of_iterations) %dopar% {…}

After you finish running your R code at scale, you may want to shut down your pool of VMs to make sure that you aren’t being charged anymore:

# shut down your pool
stopCluster(pool)

Monte Carlo Pricing Simulation Demo

The following demo will show you a simplified version of predicting a stock price after 5 years by simulating 5 million different outcomes of a single stock.

Let&;s imagine Contoso&039;s stock price gains on average 1.001 times its opening price each day, but has a volatility of 0.01. Given a starting price of $100, we can use a Monte Carlo pricing simulation to figure out what price Contoso&039;s stock will be after 5 years.

First, define the assumptions:

mean_change = 1.001
volatility = 0.01
opening_price = 100

Create a function to simulate the movement of the stock price for one possible outcome over 5 years  by taking the cumulative product from a normal distribution using the variables defined above.

simulateMovement <- function() {
    days <- 1825 # ~ 5 years
    movement <- rnorm(days, mean=mean_change, sd=volatility)
    path <- cumprod(c(opening_price, movement))
    return(path)
}

On our local machine, simulate 30 possible outcomes and graph the results:

simulations <- replicate(30, simulateMovement())
matplot(simulations, type=&039;l&039;) # plots all 30 simulations on a graph

To understand where Contoso&039;s stock price will be in 5 years, we need to understand the distribution of the closing price for each simulation (as represented by the lines). But instead of looking at the distribution of just 30 possible outcomes, lets simulate 5 million outcomes to get a massive sample for the distribution.

Create a function to simulate the movement of the stock price for one possible outcome, but only return the closing price.

getClosingPrice <- function() {
    days <- 1825 # ~ 5 years
    movement <- rnorm(days, mean=mean_change, sd=volatility)
    path <- cumprod(c(opening_price, movement))
    closingPrice <- path[days]
    return(closingPrice)
}

Using the foreach package and doAzureParallel, we can simulate 5 million outcomes in Azure. To parallelize this, lets run 50 iterations of 100,000 outcomes:

closingPrices <- foreach(i = 1:50, .combine=&039;c&039;) %dopar% {
    replicate(100000, getClosingPrice())
}

After running the foreach package against the doAzureParallel backend, you can look at your Azure Batch account in the Azure Portal to see your pool of VMs running the simulation.

As the nodes in the heat map changes color, we can see it busy working on the pricing simulation.

When the simulation finishes, the package will automatically merge the results of each simulation and pull it down from the nodes so that you are ready to use the results in your R session.

Finally, we&039;ll plot the results to get a sense of the distribution of closing prices over the 5 million possible outcomes.

# plot the 5 million closing prices in a histogram
hist(closingPrices)

Based on the distribution above, Contoso&039;s stock price will most likely move from the opening price of $100 to a closing price of roughly $500, after a 5 year period.

 

We look forward to you using these capabilities and hearing your feedback. Please contact us at razurebatch@microsoft.com for feedback or feel free to contribute to our Github repository.

Additional information:

Download and get started with doAzureParallel
For questions related to using the doAzureParallel package, please see our docs, or feel free to reach out to razurebatch@microsoft.com
Please submit issues via Github

Additional Resources:

See Azure Batch, the underlying Azure service used by the doAzureParallel package
More general purpose HPC on Azure

Quelle: Azure

How Microsoft builds its fast and reliable global network

Every day, customers around the world connect to Microsoft Azure, Bing, Dynamics 365, Office 365, OneDrive, Xbox, and many other services through trillions of requests. These requests are for diverse types of data, such as enterprise cloud applications and email, VOIP, streaming video, IoT, search, and cloud storage.

Customers expect instant responsiveness and reliability from our services. The Microsoft global wide-area network (WAN) plays an important part in delivering a great cloud service experience. Connecting hundreds of datacenters in 38 regions around the world, our global network offers near-perfect availability, high capacity, and the flexibility to respond to unpredictable demand spikes.

As we build, expand, and run this world-class network, we rely on three guiding principles:

Be as close as possible to our customers for optimal latency.
Stay in control of capacity and resiliency to guarantee that the network can survive multiple failures.
Proactively manage network traffic at scale via software-defined networking (SDN).

We are as close to customers as possible

You want a fast, reliable response when you use Microsoft services. Data travels over our network at nearly the speed of light; network speed, or latency, is a function of distance from the customer to the datacenter. If your service is far away, say you’re in London and the service is in Tokyo, the network path determines latency. We use innovative software to optimize network routing and to build and deploy network paths that are as direct as possible between customers and their data and services. This reduces latency to the limits imposed by the speed of light.

Customer traffic enters our global network through strategically placed Microsoft edge nodes, our points of presence. These edge nodes are directly interconnected to more than 2,500 unique Internet partners through thousands of connections in more than 120 locations. Our rich interconnection strategy optimizes the paths that data travels on our global network. Customers get a better network experience with less latency, jitter, and packet loss with more throughput. Direct interconnections give customers better quality of service compared to transit links, because there are fewer hops, fewer parties, and better networking paths.

Figure 1. Microsoft Global WAN

Azure traffic between our datacenters stays on our network and does not flow over the Internet. This includes all traffic between Microsoft services anywhere in the world. For example, within Azure, traffic between virtual machines, storage, and SQL communication traverses only the Microsoft network, regardless of the source and destination region. Intra-region VNet-to-VNet traffic, as well as cross-region VNet-to-VNet traffic, stays on the Microsoft network.

Customers can use Azure ExpressRoute to create private network connections to Azure, Dynamics 365, Office 365, and Skype for Business. ExpressRoute connections bypass the Internet and offer more reliability, faster speeds, and less latency than typical Internet connections. With ExpressRoute, customers connect to Azure at an ExpressRoute location at specific Microsoft edge sites, such as an Internet exchange provider facility, or directly connect to Azure from an existing corporate WAN, such as a Multiprotocol Label Switching (MPLS) VPN provided by a network service provider.

For example, customers can connect to a local ExpressRoute site in Dallas and access virtual machines in Amsterdam, Busan, Dublin, Hong Kong, Osaka, Seoul, Singapore, Sydney, Tokyo, (or any of our datacenters) and the traffic will stay on our global backbone network. We have 37 ExpressRoute sites, and growing, with one near each Azure region, as well as other strategic locations. Every time we announce a new Azure region, like we recently did in Korea, you can expect that ExpressRoute will also be there, along with our global ecosystem of ExpressRoute partners.

Figure 2. A sampling of the Microsoft ExpressRoute partner ecosystem which includes the world’s largest network and co-location providers

Stay in control of capacity and provide resiliency

To give customers a service that works well, our network must be able to handle failures and rapidly respond to demand spikes. To support the tremendous growth of our cloud services and maintain consistent service level agreements, we invest in private fiber (sometimes called dark fiber), for our metro, terrestrial, and submarine paths. Microsoft owns and runs one of the largest backbone networks in the world,connecting our datacenters and customers. Over the last three years, we’ve grown our long-haul WAN capacity by 700 percent. Within a given region, we can support up to 1.6 Pbps of inter-datacenter bandwidth. We continue to increase capacity to meet the strong demand for Microsoft cloud services.

Microsoft owns and runs one of the largest WAN backbones in the world.

Our submarine investments improve resiliency, performance, and reliability across the Pacific and Atlantic Oceans. Our latest investment is the MAREA cable, a 6,600 km submarine cable between Virginia Beach, Virginia, USA, and Bilbao, Spain, which we jointly developed with Facebook. MAREA will be the highest-capacity subsea cable to cross the Atlantic, featuring eight fiber pairs and an initial estimated design capacity of 160 Tbps. This open cable system is an innovation in submarine cable design and delivery, which allows for greater bandwidth capacity thresholds and reduces cost. More importantly, it has given us the ability to introduce SDN principles into cable management, resulting in a better quality of service.

Over the last three years, we’ve grown our long-haul WAN capacity by 700 percent.

Global network infrastructure can be surprisingly vulnerable. For example, fiber optic cables can be cut by ship anchors dragging along the seabed. For an example, see a ship accidentally cut Jersey’s internet cables with its anchor. To provide the reliability our cloud needs, we have many physical networking paths with automatic routing around failures for optimal reliability.

Figure 3. The inter-datacenter backbone connects datacenters globally with fiber optic cables

Controlling operations and managing traffic with software

Delivering traffic to millions, and growing, physical servers isn’t possible with pre-cloud technologies. In partnership with Microsoft Research, we developed a range of SDN technologies to optimally manage routing and centralize control to meet network-wide goals. We use standard switches and routers, and then we manage them with our own software, which is built to handle the enormous volume of traffic on the Microsoft network.

We use an SDN-based architecture called SWAN to manage our WAN, which enables centralized management and control of network infrastructure and improves reliability and efficiency. SWAN controls when and how much traffic each service sends and automatically reconfigures the network’s data plane to match traffic demand. With SWAN, we control every network flow from the very farthest reaches of our network, across our global WAN, all the way down to the network interface card (NIC) on a server in one of our datacenters.

Conclusion

Whether you choose to reach the Microsoft cloud through the Internet or through a private network, we are committed to building the fastest and most reliable global network of any public cloud. We continue innovating and investing in a globally distributed networking platform to enable high performance, low latency, and the world’s most reliable cloud. We will continue to provide you with the best possible network experience, wherever in the world you happen to be.

Read more

To read more posts from this series please visit:

Networking innovations that drive the cloud disruption
SONiC: The networking switch software that powers the Microsoft Global Cloud

Quelle: Azure