Automation
Automation

Best Practices Series: Considerations for On-Box Data Storage and Access

by Cordelia on ‎08-11-2015 02:54 PM - edited on ‎09-18-2017 03:25 PM by Administrator Administrator (426 Views)

Written by Douglas McPherson
Solutions Consultant at Juniper


This is part 1 of 6 of On-Box Storage.

 

Previous Article: Best Practices Series: Make Your Junos Automation Scripts More Robust

Next Article: On Box Storage: Option 1 - Flat Files as a Data Store

 

This applies to SLAX version 1.0 and higher.


Overview


This is the third in a series of articles intended to guide you as you design and implement your own JUNOS automations. Feedback and questions are welcome on the here on the JUNOS Automation Forum.

 

Introduction


During the course of developing an on-box JUNOS automation, you may eventually need to store some data locally. You will have some data that needs to persist on the box so that it can be accessed later – either by a subsequent instance of your script, a completely different JUNOS automation, or even a remote application.

You have several options for persisting and accessing your data on JUNOS -- each with its own set of strengths, weaknesses and consequences. The purpose of this article is to:

 

  • Provide an overview of some of the options you have available for persisting your data
  • Summarize pros and cons for each option
  • Note some “gotchas” that a particular data persistence approach may have


This is not a specific “how-to” article. This article focuses more on advising than providing detailed step-by-step instructions for a specific approach. The overarching goal of this article is to present and describe the approaches available to you, the developer, so that you can make an informed design decision.

 

After reading this article, you may have a specific use case in mind that you would like explained more in-depth. Please do provide feedback on this article in the JUNOS Automation forum, and indicate what use cases you’d be interested in. (There may be extant examples that we can simply link to.) Your feedback will also help us prioritize which “how-to” articles for specific data persistence technique will follow this article. So speak up and stay tuned.

 

When and why might you need to store data locally on your JUNOS device?

 

You may ask yourself, “Well, how did I get here?”

-- David Byrne


You will arrive at the need to store, read or update data on your JUNOS device from any number of vectors. For instance, you might find that your script needs to be able to do one or more of the following:

 

  • Compare some current state to a previous state
  • Calculate a delta value based on previous data
  • Save some current output so that it can be analyzed by some other person (or application)
  • Determine which interface(s) need to be monitored/reported on
  • Save a regular time-series of data for subsequent analysis
  • Calculate a “rolling window” statistic for (something) based on stored time-series data


… and the list goes on. The above are fairly common challenges and can be met with using any of a few basic techniques at your disposal.

 

What options do you have for storing data locally on your JUNOS device?
There’s a large variety of situations that can create the need to store/update/access data on a JUNOS device. However, there are essentially four basic techniques available to you for persisting/accessing your script’s private data:

 

Option 1: Flat Files as a Data Store (e.g. XML or other files)
Option 2: JUNOS Device Configuration as a Data Store
Option 3: Utility MIB as a Data Store
Option 4: JUNOS Accounting Files as a Data Store


Click the next button to proceed to a description of option 1, or click one of the links above to jump to the option that interests you. In these articles, we’ll describe each of those four options in enough detail that you can choose the one that best addresses your data persistence/retrieval requirements.