How to try out the experimental windows 2016 support in the Rancher 1.3.0 release candidate?

Introduction

Yesterday Rancher commented on my github request for windows support ;

Tested with rancher-server version – v1.3.0-rc1 with catalog “library” set to vnext branch in https://github.com/rancher/rancher-catalog

Able to add “Windows Server 2016 Standard Evaluation” hosts successfully to rancher environment with orchestration set to “windows”.

Able to launch containers in “nat” network and “transparent” network.

@kvaes , Windows 2016 support will be available as experimental feature in rancher-server 1.3.0 release.

Great news! Let’s take it out for a spin… 😀

 

Rancher Host

Installing the host(s) is the same as any other time…  Though the host will still be a Linux machine off course ;

sudo docker run -d –restart=unless-stopped -p 8080:8080 rancher/server:v1.3.0-rc1

Though notice that I specified the v1.3.0-rc1 tag… And let the system do its magic!

(Update : For the stable, release you can omit the -rc1 part!)

Note ; Be aware that this is an early release candidate. Do not use this for your production! There is for instance a bug with the GUI, where the “Auto”-theme is malfunctioning. So switch to light or dark to get that one fixed. 😉

Continue reading “How to try out the experimental windows 2016 support in the Rancher 1.3.0 release candidate?”

Advertisements

Behind the scenes : Creating a Microsoft SQL Server as a Windows / Docker Container

Introduction

This post is the first of a series in my journey to build a flexible / production ready MSSQL windows container. I thought this would have been a breeze with my experience on Docker for Linux, though I must admit running into multiple issues… This post will not provide you with a working container, as I’m still developing that one.

2016-07-06 14_23_15-kvaeschost01 - 104.45.23.120_3389 - Remote Desktop Connection

Once I deem it as production ready, it’ll be released to the community to be used freely. Though I want it to meet my personal quality standards, being that it should be stable and flexible enough to run in production mode.

 

Blueprint Braindump

For those who have been following me for a while (real life, twitter, yammer, linkedin, …); you probably know I’ve been preaching about MSSQL as a container for way too long. My personal vision was to have a MSSQL run in a container. The data should be located outside of the container, which would enable a (more/relative) easy path for the changes you want to implement.

kvaes-mssql-container-blueprint-docker-persistent-storage-identity-repository

So where volume mapping would be an option… I was also considering an integration with an external storage service. As an Azure fanatic, I (also) want to leverage the option of storing my data/temp files on Azure storage. This would provide my with total host independent storage persistence on Docker! For those who have been playing with Docker for a while, this is truly a powerful combination.

As a long term goal, I would like to see this running on a “serverless” platform. From what I have seen in the market, this is still an unreachable utopia/Walhalla at this point. So my current objective in that areas is to investigate the option of deploying this setup on a Service Fabric or to leverage the power of Rancher with Windows containers.

Continue reading “Behind the scenes : Creating a Microsoft SQL Server as a Windows / Docker Container”

Issue : Exposing ports with Windows Containers on TP5

A brief post today, so assist people who are probably going to “enjoy” the same networking issue. When coming from docker on linux and working with docker on windows, the first thing you’ll probably run into is the port exposing…

I built a MSSQL 2016 container with the default port (1433) exposed.

PS C:\Users\kvaes> docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
efc7a981f6b9 kvaessql2016 “cmd /S /C ‘powershel” 6 minutes go Up 6 minutes 1433/tcp

Though I was unable to connect from the container host to this port…

PS C:\Users\kvaes> Test-NetConnection -Port 1433 -ComputerName Localhost
WARNING: TCP connect to Localhost:1433 failed

ComputerName : Localhost
RemoteAddress : ::1
RemotePort : 1433
InterfaceAlias : Loopback Pseudo-Interface 1
SourceAddress : ::1
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False

Now let’s try that directly from the container…

PS C:\Users\kvaes> docker exec -ti efc7a981f6b9 powershell Test-NetConnection -Port 1433 -ComputerName Localhost

ComputerName : Localhost
RemoteAddress : ::1
RemotePort : 1433
InterfaceAlias : Loopback Pseudo-Interface 2
SourceAddress : ::1
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : True

This had me totally flabbergasted! After searching for a solution, I ran into the following github issue ; https://github.com/Microsoft/Virtualization-Documentation/issues/253 

Which pointed me to the following statement ;

This is a known limitation in our Windows NAT implementation (WinNAT) that you cannot access the external port in a static port mapping directly from the container (NAT) host.

The following github issue showed a workaround ; https://github.com/docker/docker/issues/15740

So let’s check the IP of our container…

PS C:\Users\kvaes> docker exec -ti efc7a981f6b9 ipconfig

Windows IP Configuration

Ethernet adapter vEthernet (Temp Nic Name):

Connection-specific DNS Suffix . : 404nupum1doencwb55jgqiwlph.ax.internal.cloudapp.net
Link-local IPv6 Address . . . . . : fe80::3077:b4b4:3a8c:5d83%31
IPv4 Address. . . . . . . . . . . : 172.27.75.141
Subnet Mask . . . . . . . . . . . : 255.240.0.0
Default Gateway . . . . . . . . . : 172.16.0.1

And then setup a proxy to reroute the traffic ;

PS C:\Users\kvaes> netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=1433 connectaddress=172.27.75
.141 connectport=1433

What does the test from our container host say now?

PS C:\Users\kvaes> Test-NetConnection -Port 1433 -ComputerName Localhost

ComputerName : Localhost
RemoteAddress : ::1
RemotePort : 1433
InterfaceAlias : Loopback Pseudo-Interface 1
SourceAddress : ::1
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : True

And now it works! In all honesty, I find this a serious flaw in the Windows implementation and truly annoying to anyone making the shift from containers in the Linux ecosystem to the Windows ecosystem.

Azure : Benchmarking SQL Database Setups – To measure is to know, and being able to improve…

Introduction

To measure is to know. If you can not measure it, you cannot improve it!

Today’s post will go more in-depth on what performance to expect from different SQL implementations in Azure. We’ll be focussing on two kind of benchmarks ; the storage subsystem and an industry benchmark for SQL. This so that we can compare the different scenario’s to each other in the most neutral way possible.

to-measure-is-to-know-storage-database-performance-kvaes

Test Setup

As a test bed I started from one of my previous posts

kvaes-azure-sql-cluster-sios-datakeeper-high-availability-ha

The machines I used were DS1 v2 machines when using single disks and a DS2 v2 machines when using multiple disks. In terms of OS, I’ll be using Windows 2012 R2 and MSSQL 2014 (12.04100.1) as database.

Continue reading “Azure : Benchmarking SQL Database Setups – To measure is to know, and being able to improve…”

Docker – Windows Containers 101 – Using Windows 2016 Technical Preview 4

Introduction

Container-Ecosystem

With this post, I’m assuming you are already familiar with the basics of Docker & Windows 2016. If not, check out Thomas Maurer’s introduction post to Windows Containers.

Containers

Deploying a Test Host

A quick way to start testing is to use search for “Container” in the images repository on Azure. You’ll notice a “Windows Server 2016 Core with Containers” image in there…

2016-01-07 10_15_36-Foto's

After that, you can connect to it via RemoteDesktop and have access to your trustworthy console.

First things first… (Interactive)

Continue reading “Docker – Windows Containers 101 – Using Windows 2016 Technical Preview 4”

Storage Performance Benchmarker 0.3 – DISKSPD option!

With this, I’m happy to announce the new release of the “Storage Performance Benchmarker“! The previous version was heavily relying on “SQLIO”, where this version offers you the ability to choose between “DISKSPD” (default) and “SQLIO”. The output will still be aggregated in the same manner towards the backend web interface, though the individual output locally will be in the format of the relative output.

2015-08-31 15_42_15-Administrator_ Windows PowerShell

Parameters added ;

  • -TestMethod : Either “DISKSPD” or “SQLIO”, depending on your preference
  • -TestWarmup : The warmup time used if you use “DISKSPD”

If you have any suggestions/comments, feel free to let me know!

chart-55e45a286e95b

Is Windows Failover Cluster supported on Azure? YES!

Is WSFC (Windows Server Failover Cluster) supported on Azure?

 YES

You can find the official support statement at the following location : https://support.microsoft.com/en-us/kb/2721672

BUT

Though be aware that there are some considerations…

Requirements for Windows Server Failover Cluster:

  • Must Run Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2
  • For Windows Server 2012 and Windows Server 2008 R2, KB2854082 is required on all nodes
  • Must use a single-cluster IP address resource
  • Must use Azure hosted storage using one of the following options:
      Application-level replication for non-shared storage
      Volume-level replication for non-shared storage
      ExpressRoute for remote iSCSI Target shared block storage
      Azure Files for shared file storage
  • High availability and disaster recovery for SQL Server in Azure virtual machines
  • Can be a third-party clustered role
    Note Third-party clustered roles are supported by the vendor

 

HOWTO

Now how do we do this in reality? (Thanks to Thomas for the links)

So what will your challenges be? First of all the storage replication, as it is not possible to share disks between VMs in a read/write manner. After that you should be carefull with your network design due to the different types/levels of IP.

Anyhow, I hope this article helped you on track for your first WSFC deployment on Azure!