Monthly Archives: May 2017

Speaking at SQL Saturday Pensacola!

I’m proud to announce that I will be speaking at SQL Saturday Pensacola on June 3rd 2017! Check out the amazing schedule!

If you don’t know what SQLSaturday is, it’s a whole day of free SQL Server training available to you at no cost!

If you haven’t been to a SQLSaturday, what are you waiting for! Sign up now!

My presentation is Designing High Availability Database Systems using AlwaysOn Availability Groups” 

Abstract:

Are you looking for a high availability solution for your business critical application? You’re heard about AlwaysOn Availability Groups and they seem like a good solution, but you don’t know where to start. It all starts with a solid design. In this session we introduce the core concepts needed to design a Availability Group based system. Covering topics such as recovery objectives, replica placement, failover requirements, synchronization models, quorum, backup and recovery and monitoring. This session is modeled after real world client engagements conducted by Centino Systems that have lead to many successful Availability Groups based systems supporting tier 1 business critical applications.

Learning Objectives: 

This session highlights the importance of doing thorough design work up front. Attendees will learn core concepts needed for successful Availability Group based systems. This includes, recovery objectives, replica placement, failover requirements, synchronization models, quorum, backup and recovery and monitoring. From this session attendees will have a firm footing on where to start when they start designing their AlwaysOn Availability Group based systems.

PowerShell Remoting in Multi-Platform Environments using OpenSSH

So in my last post I told you about how I started my journey on learning PowerShell, let’s keep going down that path together. In this post I’m going to introduce PowerShell Remoting in Multi-Platform Environments, specifically using OpenSSH. We’ll discuss WinRM in multi-platform systems in an upcoming post.

Have you ever had to execute a command against one system or a collection of systems? Have you ever wanted a remote shell on a Windows system? Using Remoting you can you can do all of these things, very, very easily.

The Plumbing

So for our first stop, let’s talk about how remoting works. Essentially what’s occurring under the hood is a PowerShell process on one system is sending commands to a PowerShell process on another system then the remote system sends the output back. Easy enough, right? Let’s dig into to how it exchanges information.

The PowerShell processes exchange messaged defined in the PowerShell Remoting Protocol (PSRP). PSRP defines semantics of the communication and types of message being exchanged. Now these messages need a transport layer, for that we have WinRM and OpenSSH. Let’s look at both.

By default, Windows PowerShell systems Remoting connections communicate using WinRM which uses HTTP/S endpoints. WinRM is an implementation of the WS-Management industry standard. WS-Man defines the semantics of the interactions between the systems and data transfer. PowerShell encapsulates its PSRP messages and uses WinRM to transport them between systems.

On Linux systems, well…they don’t communicate with WinRM, by default, so we need something else…that’s where OpenSSH comes in. PowerShell encapsulates it’s inputs and outputs as PSRP messages and it uses SSH to securely exchange the messages between systems.

The PowerShell team has implemented WinRM over HTTP remoting on Linux and already has a port of OpenSSH on Windows. The key idea going forward is…we will have a choice, we can use WinRM (HTTPS) or we can use SSH regardless of OS. For the rest of this post, we’re going to talk remoting over OpenSSH, even on the Windows side of things. We’ll discuss WinRM in multi-platform systems in an upcoming post.

The Installation

For starters, go ahead and install PowerShell Core your systems if you haven’t already, its pretty straightforward check out this link here.

Next, on Windows we need to install OpenSSH and the PowerShell team has developed a Win32 port of OpenSSH. So go check that out here. I’m going to be honest, the installation isn’t easy. But I’m going to let you in on a secret, Darwin Savoy wrote a killer Chocolatey package that does the hard work for you. Check that out here. You’ll want to use the following syntax to install OpenSSH as a service.

If you’re on Windows verify OpenSSH is up and running

Now on Linux, just about every distribution includes an OpenSSH installation their default setup…so we’re not going to cover that here.

The Configuration

Wether it’s Windows or Linux, we need to tell OpenSSH about PowerShell and we can do that with a subsystem configuration.

On a Windows system we’ll need a line like this in SSH daemon configuration file C:\Program Files\OpenSSH\sshd_config. Find the subsystem section and add this line.

On a Linux system we’ll need a line like this one in /etc/ssh/sshd_config. Find the subsystem section and add this line.

Basically what’s going on here is we’re telling OpenSSH to invoke a PowerShell process when it receives a message from a remote system that’s says it’s going to use the PowerShell subsystem. So SSH is just the conduit for these two PowerShell processes to communicate their inputs and outputs.

When you’re finished editing these files, you’ll want to restart the SSH daemons on your system…Windows or Linux.

On Windows that’s Restart-Service -name sshd on Linux that’s systemctl restart sshd

Now here’s the thing…before you move on…test your SSH connections. You will absolutely go crazy if there’s an issue with your SSH configuration and you try using PowerShell Remoting right away. If there’s an issue, PowerShell will happily swallow OpenSSH’s errors and you’ll get no feedback. Simply grab your favorite SSH client and try to connect to the systems right now and verify you can connect and get a command line. Things will be a lot easier for you before you try to use remoting.

Up next in this series we’ll look at some remoting use cases, specifically using a command line interface, executing commands against remote a remote system and executing commands against a collection of remote systems.

Why PowerShell?

Why do I use PowerShell?

Well, here’s a little back story…last year I was involved in a Pluralsight Play by Play with Jason Helmick and Jeffrey Snover for launch of Open PowerShell on Linux and Mac. Before this video, I didn’t take PowerShell seriously. Basically, if I Google’d a problem and found a solution in PowerShell I would grind my teeth and copy and paste the text into the foreign blue console and cross my fingers.

Fast forward a bit to PowerShell Summit this year, Jason and I were slated to do a session together on…PowerShell on Linux. I had to miss the trip to Seattle this year, but during the session Jason told a story a story about me learning PowerShell…check it out here around 28:27. Its pretty funny. 

Pipelines similar but different

If you don’t want to listen to Jason’s story, it goes like this. I needed to learn PowerShell…FAST. I had only a few weeks to build my skills enough so that I could sit at a table with the inventor of PowerShell and an industry recognized expert and have a meaningful conversation and oh yea, record a 5 hour training video. So as Jason says I “did the Don Jones/Jeff Hicks thing” (there’s a newer version available now) .

Well, having a UNIX background I understood the concepts of a pipeline. UNIX processes have had pipelines for a long time. Byte streams can move data from one command to the next allowing you to build more complicated commands. PowerShell can do the same, but it moves objects…rather than text/byte streams. 

Well, while learning PowerShell I built a PowerShell cmdlet pipeline to get the top 10 processes on a system sorted by CPU.

And to do the same in bash, we need to do something like this…

So, I worked through these examples and I fired up my email client and sent an email to Jason and said hey Jason…here’s two commands that do the same thing. One in PowerShell and one in native bash commands. I asked…hey, which one do you think I like better? 

As we learned in the PowerShell Summit video, he expected me to answer with my crotchety, suspenders wearing UNIX guy answer…well he was in for a surprise. I told him I liked the first one better…the PowerShell version.

I actually don't own suspenders...neckbeards are another story

Now hear me out, I’ve been using Linux/UNIX since 1997, I manage large internet commerce sites through the holiday season, I’ve done PhD level research on topics like IO, CPU scheduling and memory management…literally my fingers can type the bash commands to get the top 10 processes without even thinking…muscle memory to the max. BUT, the PowerShell version of this literally reads like a sentence. Get-Process, Sort-Object, Select-Object, pretty straight forward stuff here. No surprises. the commands do exactly what they say. This means, I can put stuff like this in a script, and other people can read it without 20 years of experience. 

What’s next?

Well, since the Play By Play, PowerShell isn’t the Google the answer…copy/paste solution anymore for me…I’ve decided to really take this seriously and PowerShell is now a go to tool in my toolbox. I’m not telling you this because I’m a Microsoft MVP, I’m not telling you this because I did a video with THE PowerShell gurus…I’m telling you this because I really use PowerShell now…every day.

This post is the first post in a series I plan on bring to you that will document my discovery process of using PowerShell on Linux. We’ll discuss the techniques and technologies I use to solve some real world problems in a multi-platform world!

Now, there’s two things I really consider special about my first go with PowerShell…asynchronous job posting via Remoting and Desired State Configuration (DSC). We’ll cover these topics in this series.