Automation Isn’t Just About Speed
In talking with folks about automation, the conversation almost always come around to “speed, speed, speed”. It’s easy to see why this is the first benefit that pops into mind - we’ve all spent gratuitous amounts of time doing repetitive, time-consuming tasks. It’s obvious why the prospect of automating these tasks and getting the time back is such an attractive one, even though most of us that have tried know that this is an absolute reality:Automation Isn’t Just About Speed
In talking with folks about automation, the conversation almost always come around to “speed, speed, speed”. It’s easy to see why this is the first benefit that pops into mind - we’ve all spent gratuitous amounts of time doing repetitive, time-consuming tasks. It’s obvious why the prospect of automating these tasks and getting the time back is such an attractive one, even though most of us that have tried know that this is an absolute reality:Automating SAN Zoning with Schprokits
I’m always on the lookout for ways to simplify the configuration of integrated systems through automation. I also currently work for a systems integrator, and I take any opportunity I can get to automate a process, a la “assembly line”, creating a consistent, predictable outcome.
One particular task that both integrators and customers alike are having to do manually is the act of Fibre Channel Zoning. For those that aren’t familiar, Fibre Channel doesn’t work in the same way that Ethernet does (i.e. Flood and Learn). In order to get two nodes to communicate over a SAN fabric, a configuration must be put into place to allow them to talk – roughly equivalent to a Layer 2 ACL. Each server’s HBA must be given permission to access a storage target on the fabric, which means that any time compute power is added or removed, this configuration needs to be revisited. This is a prime candidate for automation.
This article will show how I am using Schprokits to simplify zoning configuration. I am tightly adhering to the idea that this kind of information should be pulled directly from live infrastructure (in this example, I’m using Cisco UCS), not a (usually) stagnant spreadsheet, or Continue reading
Automating SAN Zoning with Schprokits
Since this post was written, the company behind Schprokits has unfortunately gone out of business. Though this approach is no longer something that you can read and follow along with, I have left this post active as an academic exercise in network automation. I hope it is useful in some way. I recorded an in-depth explanation of the process (~42 mins), and it can be found here, as well as at the end of this post.Automating SAN Zoning with Schprokits
Since this post was written, the company behind Schprokits has unfortunately gone out of business. Though this approach is no longer something that you can read and follow along with, I have left this post active as an academic exercise in network automation. I hope it is useful in some way. I recorded an in-depth explanation of the process (~42 mins), and it can be found here, as well as at the end of this post.Source-Driven Configuration for NetOps
I mentioned in a previous post that version control is an important component of efficiently managing network infrastructure. I’m going to take is a step further than what most are doing with RANCID, which is traditionally used at the end of a workflow (gathering running config diffs) and show you what it’s like to start with version controlled configuration artifacts, specifically using Ansible’s “template” module.
I’m not going to discuss how you get the resulting configurations actually running on your network devices – that is best saved for another post. This is more focused on using version control and review workflows to initiate what will eventually turn into a networking-centric CI pipeline.
Config Review and Versioning with Gerrit
Let’s say you are the Senior Network Engineer for your entire company, which boasts a huge network. You don’t have time to touch every device, so you have a team of junior-level network engineers that help you out with move/add/change kinds of tasks. You’ve already moved your configurations into Jinja2 templates, and have created an Ansible role that takes care of moving configuration variables into a rendered Continue reading
Source-Driven Configuration for NetOps
I mentioned in a previous post that version control is an important component of efficiently managing network infrastructure. I’m going to take is a step further than what most are doing with RANCID, which is traditionally used at the end of a workflow (gathering running config diffs) and show you what it’s like to start with version controlled configuration artifacts, specifically using Ansible’s “template” module. I’m not going to discuss how you get the resulting configurations actually running on your network devices - that is best saved for another post.Source-Driven Configuration for NetOps
I mentioned in a previous post that version control is an important component of efficiently managing network infrastructure. I’m going to take is a step further than what most are doing with RANCID, which is traditionally used at the end of a workflow (gathering running config diffs) and show you what it’s like to start with version controlled configuration artifacts, specifically using Ansible’s “template” module. I’m not going to discuss how you get the resulting configurations actually running on your network devices - that is best saved for another post.Storage Traffic Magic with OpenFlow
I am in the Bay Area this week, working on some network automation stuff, and I was fortunate to be able to stop by and say hello to the Storage Field Day 6 folks over drinks.
I was told by several impressed delegates about a talk by Andy Warfield of Coho Data, where he described how they used OpenFlow to steer storage traffic intelligently to and from various nodes in a distributed storage array.
For the majority of the discussion, he talks at length about how NICs have long been able to push more data than a single CPU core is able to process, and as a result, they have to be intelligent about the distribution of packet processing onto the cores within a multicore system.
In summary, a big problem with file-based storage systems is dealing with load sharing. NFS clients have to point to an IP address where the exports are located, and if this IP address was available only on a single NIC on a storage array, this pretty severely limits your options – that port becomes a big bottleneck. I’ve seen some customers assign IP addresses to several ports on an array, and use them in rotations Continue reading
Storage Traffic Magic with OpenFlow
I am in the Bay Area this week, working on some network automation stuff, and I was fortunate to be able to stop by and say hello to the Storage Field Day 6 folks over drinks. I was told by several impressed delegates about a talk by Andy Warfield of Coho Data, where he described how they used OpenFlow to steer storage traffic intelligently to and from various nodes in a distributed storage array.Storage Traffic Magic with OpenFlow
I am in the Bay Area this week, working on some network automation stuff, and I was fortunate to be able to stop by and say hello to the Storage Field Day 6 folks over drinks. I was told by several impressed delegates about a talk by Andy Warfield of Coho Data, where he described how they used OpenFlow to steer storage traffic intelligently to and from various nodes in a distributed storage array.Mass Customization
I’ve mentioned in past articles about my belief that networking – both as a discipline and a technology – needs to be more consumable to other disciplines. But what does this mean? I was reminded of a few great examples today that I think are relevant to this idea, and might help explain my point a little more clearly.
Mass Production Meets Customization
The assembly line revolutionized the auto industry. Prior to this, vehicle production was very slow, and extremely costly. The introduction of the assembly line for creating automobiles allowed cars to be created in a predictable, repeatable way. However, Ford famously required all Model T’s to be painted black. Even before the introduction of the assembly line, the Model T was available in other colors, but with the move to mass production, this option was taken away.
The term “mass customization” is essentially the idea that mass production can co-habitate with customization, resulting in a customer experience that is personal and custom-built, but that also gets to experience the low unit cost that comes with mass production.
A great example of mass customization is the Moto X phone, whose commercials famously offer all kinds of customization options Continue reading
Mass Customization
I’ve mentioned in past articles about my belief that networking - both as a discipline and a technology - needs to be more consumable to other disciplines. But what does this mean? I was reminded of a few great examples today that I think are relevant to this idea, and might help explain my point a little more clearly. Mass Production Meets Customization The assembly line revolutionized the auto industry.Mass Customization
I’ve mentioned in past articles about my belief that networking - both as a discipline and a technology - needs to be more consumable to other disciplines. But what does this mean? I was reminded of a few great examples today that I think are relevant to this idea, and might help explain my point a little more clearly. Mass Production Meets Customization The assembly line revolutionized the auto industry.5 Dev Tools for Network Engineers
I’d like to write about five things that you as a hardcore, operations-focused network engineer can do to evolve your skillsets, and take advantage of some of the methodologies that have for so long given huge benefits to the software development community. I won’t be showing you how to write code – this is less about programming, and more about the tools that software developers use every day to work more efficiently. I believe in this, there is a lot of potential benefit to network engineering and operations.
I’m of the opinion that “once you know what you don’t know, you’re halfway there”. After all, if you don’t know what you don’t know, then you can’t very well learn what you don’t know, can you? In that spirit, this article will introduce a few concepts briefly, and every single one will require a lot of hands-on practice and research to really understand thoroughly. However, it’s a good starting point, and I think if you can add even a few of these skills, your marketability as a network engineer will increase dramatically.
Proper Version Control
As a developer, version Continue reading
5 Dev Tools for Network Engineers
I’d like to write about five things that you as a hardcore, operations-focused network engineer can do to evolve your skillsets, and take advantage of some of the methodologies that have for so long given huge benefits to the software development community. I won’t be showing you how to write code - this is less about programming, and more about the tools that software developers use every day to work more efficiently.5 Dev Tools for Network Engineers
I’d like to write about five things that you as a hardcore, operations-focused network engineer can do to evolve your skillsets, and take advantage of some of the methodologies that have for so long given huge benefits to the software development community. I won’t be showing you how to write code - this is less about programming, and more about the tools that software developers use every day to work more efficiently.Why Network Automation Won’t Kill Your Job
I’ve been focusing lately on shortening the gap between traditional automation teams and network engineering. This week I was fortunate enough to attend the DevOps 4 Networks event, and though I’d like to save most of my thoughts for a post dedicated to the event, I will say I was super pleased to spend the time with the legends of this industry. There are a lot of bright people looking at this space right now, and I am really enjoying the community that is emerging.
I’ve heard plenty of excuses for NOT automating network tasks. These range from “the network is too crucial, automation too risky” to “automating the network means I, as a network engineer, will be put out of a job”.
To address the former, check out Ivan Pepelnjak’s podcast with Jeremy Schulman of Schprokits, where they discuss blast radius (regarding network automation).
I’d like to talk about that second excuse for a little bit, because I think there’s an important point to consider.
A Recent Example
A few years back, I was working for a small reseller helping small companies consolidate their old physical servers into a cheap cluster of virtual hosts. For every sizing discussion that Continue reading