Open Source

In my planned failover walkthrough, I showed what happens when you deliberately move the primary role to another replica. That’s the easy case. Now I want to show what happens when the primary pod just disappears unexpectedly, like during a node failure or a container crash. No graceful shutdown, no demotion, just gone.

I ran two test scenarios, each cycling the primary role across all three pods by force-deleting the current primary three times in a row. First, a 5GB TPC-C database idle. Then, that same 5GB database under sustained HammerDB TPC-C load. Six force-deletes total, six successful automatic failovers. I’ll walk through the error log from the promoted replica, the operator’s detection and recovery behavior, and the full timing data.

When building the sql-on-k8s-operator, I wanted to make sure it could handle both planned and unplanned failovers. The easy case is a planned failover, where you deliberately move the primary role to another replica. The harder case is an unplanned failover, where the primary pod just disappears. The operator needs to handle both.

I recently ran a full planned failover rotation on a three-replica SQL Server Availability Group managed by sql-on-k8s-operator, and I want to show you exactly what happens inside SQL Server and the operator during each hop. If you’ve been following my Introducing the SQL Server on Kubernetes Operator post, this is the logical next step: what does the error log actually look like during a planned failover, what does the operator do in response, and how long does the whole thing take?

Are you considering replatforming your SQL Server workload due to recent vendor changes, but still need high availability and disaster recovery? You’re not alone. One of the challenges with running SQL Server on Kubernetes is that there’s no Kubernetes operator available. That means no automated lifecycle management, no automatic failover, and no standard way to bootstrap an Always On Availability Group on Kubernetes.

I’m excited to share it today as an open-source project: sql-on-k8s-operator. Let’s go.

Had a conversation with a good friend in the SQL Community about OpenSSH and how it fits as a transport layer for PowerShell Remoting. I pointed him towards several resources I have online. So here’s a post aggregating those resources.

If you’re looking to get started with OpenSSH on Linux and Windows Systems check out thisPowerShell Summit presentation I did in 2018. This covers OpenSSH in theory and practice.

Session: OpenSSH Internals for PowerShell Pros

So in yesterday’s post we learned that the OpenSSH client is included with the Windows 10, Update 1803!  Guess, what else is included in this server, an OpenSSH Server! Yes, that’s right…you can now run an OpenSSH server on your Windows 10 system and get a remote terminal! So in this post, let’s check out what we need to do to get OpenSSH Server up and running.

First, we’ll need to ensure we update the system to Windows 10, Update 1803. Do that using your normal update mechanisms.

Today is a big day! The OpenSSH client version 7.6p1 is now part of the Windows 10 operating system! Microsoft released Windows 10 Update 1803 and included in that release is the OpenSSH client, which is installed as part of the update.

That’s right an SSH client as part of the Windows operating system by default! Also included with this update is the OpenSSH Server which is included as an Windows Feature on Demand.

Next week I’ll be speaking at TechMentor in Redmond, I’m doing a 1/2 day workshop on Linux OS Fundamentals for the Windows Admin be sure to come see me!

If you’re there on Monday night (August 7th) and let’s get together for dinner! We’ll talk tech and hopefully make a few new friends and networking connections!

Where – We’ll start at the Hyatt Regency Bellevue, light appetizers will be provided. Then we’ll head on over to Lot No. 3 for dinner. I’ll pick up the first round of drinks and the appetizers!

Open Source PowerShell is available on several operating systems, that really what’s special about the whole project! To get PowerShell to function on these various systems we need to build (compile) the software in that environment. This is what will produce the actual executable program that is powershell.

To facilitate the build process the PowerShell team has documented how to do this for the currently available platforms, Linux, MacOS and Windows. In this post I want to talk about why this is important, point you to the resources available online to help you build Open Source PowerShell and tell you my experiences building PowerShell on the Windows, macOS and Linux!