Optimize for internet traffic with Peering Service and the routing preference option

Last week at the Microsoft Build conference, we announced that Azure Peering Service is now generally available. We also introduced “routing preference,” a new option for our customers to further architect and optimize their traffic to and from Azure over the “public Internet.”

Networking is a critical enabler of the cloud. The experience when accessing your applications and data depends on the performance of your network connection and the global network powering your applications and services in the cloud.

For the best experience, data should travel the shortest path and enter and exit the Microsoft network as close as possible to you or your users. Microsoft runs the Microsoft global network, one of the world's largest wide area networks (WANs). Stretching across all continents through hundreds of thousands of miles of fiber and hundreds of network points of presence (PoP), it powers all the Microsoft cloud services such as Azure, Microsoft 365, LinkedIn, and their millions of users.

A growing number of our customers are adopting an "Internet-first" approach. Driven by accelerated cloud adoption and the current global situation, and the need to quickly adjust and provide optimal access to users is a main priority. Cloud-centric architectures with virtual private networks (VPNs) and technologies such as SD-WAN are applied to optimize for cost, security, and performance.

Peering Service

Microsoft is always optimizing customer traffic within our network, from ingestion close to the user and carrying it as far as possible to its destination, avoiding the public Internet, to returning it the same way. Peering Service extends the optimized path to your doorstep or, in industry terms, to the last mile.

Concept diagram of Peering Service.

We have partnered with internet service providers (ISPs), internet exchange providers (IXPs), and software-defined cloud interconnect (SDCI) providers worldwide to provide reliable and performant public connectivity.

When connecting using a partner provider, you can take advantage of business-class internet connectivity with high availability and low latency. Using the optimal path and least amount of network hops, Peering Service improves the user experience in Microsoft apps, such as Microsoft Teams, SharePoint, and Outlook. Also, you will have access to optional advanced performance telemetry and security features such as route hijacking monitoring and prevention.

Prefix events in the portal showing an origin autonomous system number (ASN) change for a Peering Service customer's prefix.

Routing preference

While optimal consumption of apps is critical, so is the ability to architect the delivery. I am excited to introduce the new routing preference option in Azure. The option brings a new second network service tier and enables customers to select how traffic routes between their Azure resources and clients accessing them from the internet. The Microsoft global network is well provisioned with multiple redundant fiber paths to ensure exceptionally high reliability and availability. We do traffic engineering using a unique software-defined WAN controller that provides optimal path selection and high performance for your traffic.

Default routing of traffic for best performance in Azure.

While Microsoft will always default to the best performing and most secure option of carrying the traffic across our backbone from source to destination, the new competitive egress tier adds a secondary option for solutions that do not require the premium predictability and performance of Microsoft's global network. Instead, it will allow the routing of traffic directly to the public Internet.

Traffic routed with the new network service tier in Azure.

You can select your preferred routing when creating a public IP address and associating it to resources such as virtual machines (VMs), internet-facing load balancers, and more. You can also add the secondary routing preference, "Internet routing" for storage accounts that gives an additional endpoint to access services such as blobs, files, web, and Azure Data Lake over the public Internet.

Creation of an additional endpoint for internet routing option.

Let us look at how the two options compare. We did a performance comparison using ThousandEyes monitoring across multiple global locations, accessing Azure Virtual Machines. The average round-trip latency was measured over a period of 30 days. As expected, routing via Microsoft's network provides the best latency, with the gap between the two further widening with cross-continent traffic. The choice of best scheme, price, and performance is ultimately yours.

Performance between the Microsoft network and the public Internet.

Learn more

We continue to be fully committed to helping you connect to Azure in the best possible way, protect your workloads, and deliver a great networking experience. We will continue to provide innovative networking services and guidance to help you take full advantage of the cloud and are always interested in learning more about your new scenarios enabled by our networking services. As always, we welcome your feedback.

Learn more about Peering Service.
Learn more about routing preference.

Quelle: Azure

Fast, simple Docker Enterprise deployments with the Mirantis Launchpad CLI Tool

The post Fast, simple Docker Enterprise deployments with the Mirantis Launchpad CLI Tool appeared first on Mirantis | Pure Play Open Cloud.
Try out Docker Enterprise or generate PoC clusters quickly and confidently with our new deployer
Released in Beta with Docker Enterprise 3.1 comes Mirantis Launchpad, a simple-to-use, robust CLI deployer that works out-of-the-box to let you quickly configure, deploy, tear down, and update clusters for trial, PoCs, labs, and development on almost any infrastructure, and integrates with Terraform and other tools for low-level IaaS provisioning.

Right now, Mirantis Launchpad only deploys Docker Enterprise itself, due to (now changing) limits on how Docker Trusted Registry applies license files. In coming weeks, Mirantis will add the ability to deploy DTR alongside Docker Enterprise, and add layers of custom configurability while preserving sensible defaults. The evolving result will remain the easiest way of deploying demo and (eventually) full production Docker Enterprise clusters: readily integrated with other automation you may be using, and complementary to existing deployment solutions.
Using Mirantis Launchpad
Mirantis Launchpad will run on any laptop (Windows, Mac, or Linux) and can deploy to any collection of target bare-metal or virtual machines that it can reach (via IP address or hostnames), and that can see one another. Depending on your requirements, it’s easy to set up various lab configurations, e.g., on AWS, Azure, or your desktop virtualization solution of choice.
Download the binary
Mirantis Launchpad is written in Go and distributed as binaries for direct execution on Windows, Mac, or Linux. To get started, visit our download page and grab the link for the version you need. 

The binary should be downloaded to a convenient folder, optionally renamed (we renamed it to ‘launchpad’), and made executable. On (Ubuntu) Linux, we did this as follows:
chmod +x launchpad
We could then test the installation by executing launchpad with the ‘version’ argument:
./launchpad version
The ./ simply directs execution to the local file, since we didn’t add launchpad to our execution path.

This produces the output (example only):
version: 0.10.0
commit: 636ce55
Your version details may vary. 
Registering yourself as a user
We’re interested in knowing how people use Mirantis Launchpad, so we ask that you register before using the software. This can be done from the command line:
./launchpad register
This will cause Mirantis Launchpad to ask your name, email, and company name, and transmit these to Mirantis.
Prepare target infrastructure
A small demo deployment can be done on as few as two virtual machines running a supported operating system and configured to comply with Docker Enterprise minimum requirements. Important: Target VMs should be configured for access via .ssh and private key, and login accounts (for Linux nodes) should be part of the sudoers group, with passwordless sudo enabled. This is the default setup for Linux VMs on most public clouds. If you created a new ssh key to use with your deployment, remember to install it on your deployer laptop (on Linux, this would typically be in the .ssh folder in your home directory).

Mirantis Launchpad will deploy Docker Enterprise manager nodes only on Linux (a Docker Enterprise requirement), but can deploy worker nodes optionally on Windows Server, providing these have been set up for access with SSH by the Administrator. 
Networking considerations
Target machines must be able to:

Access the internet, so will require public IP addresses or internet access via a configured gateway.
Access one another on several ports to enable Swarm and Kubernetes networking.
Must be accessible on port 22 (SSH) to the machine Mirantis Launchpad is running on, enabling configuration.

Additional ports must also be open between the deployer laptop and target machines to use docker, kubectl and related clients with your new cluster. And ports 80 and 443 (at minimum) will be required to be open on target machines for access to applications running on the cluster.

For the sake of simplicity, it may be easiest to set up a single security group for all target machines with rules as follows:
Security group “my_security_group”
Inbound rules (IPv4 only):

Port Rule
80 Allow from anywhere
443 Allow from anywhere
All traffic Allow from security group my_security_group
All traffic Allow from <launchpad laptop IP (if laptop is not on same subnet as cluster) or jumpbox IP>
Additionally, on AWS (and perhaps other public clouds), depending on your configuration, it may be necessary to explicitly allow machine to machine communications on private IP addresses. Do this by selecting the machines, then, Actions -> Networking -> Source/destination IP checks -> Disable.
Create a config.yaml file
Next step is to create a config.yaml file for launchpad, representing your cluster’s desired configuration. The command:
./launchpad init > cluster.yaml
… will generate a basic cluster.yaml file for you to modify. Meanwhile, here’s a sample cluster.yaml for deploying a cluster on two Linux nodes, creating a manager and a worker:
apiVersion: launchpad.mirantis.com/v1beta1
kind: UCP
metadata:
 name: ucp-kube
spec:
 ucp:
   installFlags:
     – –admin-username=<username>
     – –admin-password=<password>
     – –default-node-orchestrator=<kubernetes_or_swarm>
 hosts:
 – address: <IP_or_hostname_of_manager_node>
   role: manager
   sshKeyPath: <path_and_name_of_private_keyfile>
   user: ubuntu
 – address: <IP_or_hostname_of_worker_node>
   role: worker
   sshKeyPath: <path_and_name_of_private_keyfile>
   user: ubuntu
As with Kubernetes object definition files, the important stuff begins in the spec: stanza, where (in the ucp: stanza) you specify the cluster administrator’s username and password, and the cluster’s default orchestrator (the orchestration mode to which newly-joined nodes are assigned).

Following the ucp: stanza is an array of maps describing cluster nodes and roles. Mirantis Launchpad requires (at this point) at least one node designated as ‘manager’ and one as ‘worker.’ It can provision multiple manager nodes in a highly-available configuration, and as many workers as you like.

Mirantis Launchpad will default to accessing target nodes as ‘root.’ If this isn’t practical (e.g., on Ubuntu targets, which by default don’t permit root login, preferring instead of designate an administrative user with sudo privileges) you can use the user: parameter to specify a username.

The sshKeyPath: key, as you might expect, takes as its value the full path and filename of the private key it will use to access target servers (e.g., ~/.ssh/id_rsa).

Save cluster.yaml after making changes.
Avoiding complexity
Mirantis Launchpad seeks to avoid unnecessary complexity, so by default, for example, component versions are left unspecified, and Mirantis Launchpad will select automatically among latest compatible versions of Docker Engine – Enterprise and other artifacts. Ability to specify versions and many other details, however, is built in (see documentation). For example, you can specify the Docker Engine – Enterprise version by adding an engine: sub-stanza to the ucp: stanza:
 engine:
   version: 19.03.8-rc2
Note that the most recent compatible version of Docker Engine – Enterprise, at time of writing is 19.03.8-rc3, which Mirantis Launchpad would deploy unless instructed otherwise.

Full documentation of the Mirantis Launchpad YAML specification is here.
Running launchpad to deploy a cluster
At this point, you can deploy your cluster by cd’ing to the directory in which you saved launchpad, and entering:
./launchpad apply
Mirantis Launchpad finds cluster.yaml and begins by testing SSH connectivity to your target machines. As it executes, Mirantis Launchpad tests before performing operations or implementing changes, exposing errors and stopping before anything gets broken. Assuming no configuration, networking, or other errors, it will implement your configuration and terminate execution, telling you the IP address/hostname of your manager node, enabling browser connection using your admin username and password.

Mirantis Launchpad can also tear down your cluster, using the command:
./launchpad reset
… in the process, uninstalling all installed components. This will typically only be used when you no longer need the cluster, however (see below).
Idempotency and updates
More generally, like other mature deployment tools (and Kubernetes itself) Launchpad tries to function idempotently: making changes only in cases where a target system’s actual configuration differs from the configuration requested. You can thus apply (and change, and reapply) cluster.yaml to converge your cluster on a desired state, without repeating steps unnecessarily, or breaking the cluster in the process. For example, if you want to add additional servers, you can add them to the cluster.yaml file.

You can thus perform ‘launchpad apply’ as many times as needed (to fix basic configuration errors such as the wrong path to a private key), add or remove nodes, or update components.
Integrating Mirantis Launchpad with other tools
Users of Terraform will appreciate that Mirantis Launchpad can consume Terraform infrastructure description files to deploy clusters on infrastructure provisioned with this tool. The files need to be converted from JSON to YAML (trivial, using a tool like ‘yq’ or equivalent). An upcoming tutorial will address ways of integrating Mirantis Launchpad with Terraform and other automation.   

Now that you have a working cluster, check out this tutorial showing how to use it, and join us for a webinar on the new features in Docker Enterprise 3.1. 

 The post Fast, simple Docker Enterprise deployments with the Mirantis Launchpad CLI Tool appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis

Mirantis Launches New Docker Enterprise Release, Adds the only production-ready Kubernetes Clusters on Windows Servers and Industry Leading SLAs

The post Mirantis Launches New Docker Enterprise Release, Adds the only production-ready Kubernetes Clusters on Windows Servers and Industry Leading SLAs appeared first on Mirantis | Pure Play Open Cloud.
Docker Enterprise 3.1 is first major release since November’s Docker Enterprise acquisition
Campbell, CA, May 28, 2020 — Mirantis, the open cloud company, today announced the general availability of Docker Enterprise 3.1, the first major release since the company acquired the Docker Enterprise business in November 2019.
Docker Enterprise customers can now further expand their container and Kubernetes adoption to include their most valuable use cases and applications. Now, administrators of a Docker Enterprise cluster can easily join Windows Server 2019 nodes to a Docker Enterprise cluster and enable end users to use Kubernetes to orchestrate Windows containers.
Docker Enterprise 3.1 also adds greater stability and additional features, with an updated version of Kubernetes and Nvidia GPU integration for AI/Machine Learning, IoT, and Big Data applications. It also allows users to easily enable Istio ingress for a Kubernetes cluster with the click of a button.
At the same time, Mirantis is introducing new support options for all Docker Enterprise customers: LabCare, ProdCare, and OpsCare. Previously, the highest level of support available was 24×7 for Severity 1 cases; with Mirantis ProdCare, customers have 24×7 support for all cases. With Mirantis OpsCare, customers get remote managed operations for their environment with enhanced SLAs, a designated customer success manager, proactive monitoring and alerting, and dedicated resources with ongoing health checks and reviews.
“Seven hundred and fifty customers adopted Docker Enterprise as the fastest way to build and run modern apps at enterprise scale,” said Adrian Ionel, co-founder and CEO of Mirantis. “Docker Enterprise 3.1 doubles down on that promise with the only production-ready Kubernetes for Windows capability and SLAs for mission critical applications.”
The latest capabilities of Docker Enterprise 3.1 include:

Certified Kubernetes 1.17

The upstream Kubernetes included in Docker Enterprise has been incremented to the 1.17 release, bringing greater stability and various features introduced after release 1.14, such as Windows support and scheduler improvements.

Kubernetes on Windows
Kubernetes clusters managed by the Universal Control Plane (UCP) in Docker Enterprise can now include nodes running Windows Server. Additionally, pods can interoperate when running on nodes in a mixed cluster consisting of Windows Server and Linux nodes.

GPU Orchestration
Nvidia GPU integration is now included in Docker Enterprise, with a pre-installed device plugin. Users can view GPU nodes inside Docker UCP, request GPUs through standard YAML pod specifications, and create policies for GPUs around access control and shared resources.

Istio Ingress for Kubernetes
Developers can enable Istio Ingress for a Kubernetes cluster with the click of a button. Istio will be automatically added to the cluster with intelligent defaults to get started quickly. Users can additionally configure proxies, add external IPs, and more – all from a simplified, user-friendly interface. Users can also create and review traffic routing rules, with virtual services supported out of the box.

New Mirantis Launchpad CLI Tool for Deployment & Upgrades on any infrastructure (all major public clouds, on-prem operating systems and VMware)
A new Command Line Interface (CLI) tool deploys a cluster in minutes with ready-to-use Docker Engine – Enterprise, Kubernetes, and Universal Control Plane.

“The market leadership of the Docker Enterprise platform combined with Mirantis’ reputation for customer care and technical expertise makes the Docker 3.1 release a compelling fit for our customers in support of their app modernization journey,” said Glen Tindal, Solutions Business unit leader, Capstone IT. “Adding Windows Server support with Kubernetes gives Capstone IT’s customers greater business flexibility and choice based on their use cases.”
Docker Enterprise is the only platform that enables developers to seamlessly build, share and safely run any applications anywhere – from public cloud to hybrid cloud to the edge. One third of Fortune 100 companies use Docker Enterprise as their high-velocity innovation platform.
On June 4th, Mirantis will host a live webinar to walk through the highlights in Docker Enterprise 3.1, and provide a live demonstration of its capabilities. To register for the webinar, sign up here: https://info.mirantis.com/webinar-docker-enterprise-3-1.
 The post Mirantis Launches New Docker Enterprise Release, Adds the only production-ready Kubernetes Clusters on Windows Servers and Industry Leading SLAs appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis