Storage Networks

Time to move beyond Send-Expect

by Chip Copper on ‎04-24-2018 08:30 AM - last edited on ‎04-24-2018 08:53 AM by Community Manager (2,263 Views)

In the early days of computing, people figured out pretty quickly that there are some operations that need to be performed over and trs-80.pngover. I used to have a TRS-80 Model I that I used to log into CompuShare over a 110 baud modem. The login process was repetitive and tedious. One command in the wrong order or a mistyped character and you had to hang up and start over. If you typed in “+++” too quickly, you ran the risk of hanging up halfway through your session, and since you paid by the hour for both long distance and service time, it added up. Long distance charges from Wheeling, WV to Columbus, OH were not cheap.


Then came Send/Expect scripting. It was fantastic! You could set up a script that included a dialog as to what was to be sent, and then what you expected to get back. For example, the script would send a carriage return and wait for “Username”. It would then send your credentials and you were off to the races! You never made a typo and the login process took a lot less time. Then came tragedy. CompuServe changed their prompts. They included verbiage that was not included in my script. Everything broke. I probably ended up spending more time keeping my scripts up to date than had I just taken the time to log in.


The funny thing is that Send/Expect scripting stuck. Many SAN administrators have repetitive tasks that they do on a regular basis. They have tried to automate processes by setting up elaborate scripts that send commands and parse the results. Unfortunately, NVMethey have faced problems not unlike the ones that I had back in the 1970s. Command formats, flags, and results have changed as a result of new innovations. Consider NVMe performance counters. They did not exist until recently, and now the newly introduced Brocade® G630 and the 64 port blade for the Brocade X6 Director both have special sensors that can give information on that type of traffic specifically. Those counters are now a column in the standard command output. If you have a Send/Expect script that is expecting a certain value in column 5 that has now been moved to column 6, the script will either break or could yield the wrong values. Even something as seemingly mundane as the changing of the format of an error message can cause problems.

 


In Brocade’s Fabric Operating System version 8.2, we can say goodbye to Send/Expect scripting and hello to a much better implementation of automation. FOS 8.2 now includes a RESTful API that allows for the well-defined exchange of commands, results, and information from SAN fabrics and switches. Through the RESTful API, the fabric and switches can be inventoried, ports and flows can be monitored, and resources can be provisioned. Information is exchanged as XML structures using rules and disciplines already well established in the IT world. Because it is a standard RESTful API, any language (including CLI) that supports REST transactions will be able to access the SAN. Naturally, these transactions are secure.


Python has gained popularity as being the scripting language of choice recently, and so Brocade has made an open source library rest_api.pngavailable which wraps FOS RESTful API calls into more programmer-friendly function definitions. The open source library called PyFOS also includes a number of utilities that can be run directly from the command line on a client. As a programmer, I find that the best part of these utilities is that I can tear them apart to figure out how they work and I can use them as modules in my own automations.


As an even higher level of abstraction, Brocade is also making Ansible playbooks and modules available. Ansible is an easily-learned orchestration suite that allows you to define automations and run them against a set of resources. One of the most attractive features of Ansible is that it does not require a client to be installed on the target resource. Because of the number of platforms that are currently supported by Ansible, it will be easy to craft automations that have a scope much larger than just the SAN. Storage arrays, storage fabrics, servers, and VMs can now all be part of the same administrative operation. Oh yeah, and it’s free.


This is the time to get started with your automation project. Visit the Brocade repositories on GitHub (https://www.github.com/brocade) and download PyFOS and the Ansible content. Find a Gen 6 or Gen 5 Brocade switch, install FOS 8.2, and you are ready to get started! There are a lot of things I miss about my TRS-80, but having to face the annoyances of repetitive, error-prone tasks is not one of them. It shouldn’t be for your SAN either!


If you like to hear more about Brocade Automation, join me for the webinar happening today, April 24th at 9 am PST. Here is the link to quickly register and attend the Automate and Accelerate Your SAN with Brocade webinar.


If you missed it, you can catch the replay here: https://community.brocade.com/t5/Fibre-Channel-SAN/tkb-p/FibreChannel


If you are attending Dell Technologies World in Vegas next week, come see me at the Brocade Booth # 843 for a signed copy of the SAN_Automation_Cover_web.pngBrocade Special Edition SAN Automation for Dummies book. Book signing will be on Tues, May 1st and Wed, May 2nd, between 1pm to 3pm both days. Also, please be sure to catch my presentation “Automate the SAN, Transform the Data Center with Brocade GEN 6”, on Tuesday, May 1st at 12:40pm.


Here are some additional resources to check out:

 

 

Comments
by Scott Shimomura
on ‎04-24-2018 10:56 AM

Great blog Chip!

 

Labels