Deployment
Introduction
Just as it is important to decide what to develop and how to develop it it is important to know how to deploy it and what context it executes in. The deployment architecture has great impact on network automation and using the insufficient deployment architecture can lead to an inflexible system that is hard to expand in the future. For this reason it is central to engage with experienced advisors to decide on a suitable deployment architecture. This section gives an overview of the different options that should be considered.
Context
It is important to consider the context in which your automation lives. It will have southbound interfaces towards the network elements that it manages. Northbound interfaces are towards order managers, business and operational support systems and other systems that need to read or write data from the automation system. There are also east/west systems that need to interact with the automation system for things such as inventory and resource management.
It is important to map out these interfaces and decide which protocols are to be used and write down the expectations that system owners have on each other. When introducing automation some new systems might be needed and some old systems might be retired, these consequences are an important part of the automation planning.
Deployment architectures
There are several different ways to deploy NSO. The first important thing to consider is whether or not to use LSA (Layered Services Architecture) where the system is built up by hierarchical NSOs, so that the upper level NSO handles dispatching and the outward facing services and the lower level NSO is more resource facing. Deciding if/when to deploy LSA is an important architectural choice and needs to be decided together with experts early on in the planning. Even if LSA is not deployed it is possible to develop services in a way that makes it easier to move to LSA at a later stage.
The other important factor is High Availability (HA) which allows NSO to have one or more slave nodes that can take over in the case of a failure. It is strongly recommended that all production environments are deployed with at least one backup node.
Operational concerns
It is important to make sure that regular backups are taken of the database and the log files, logs can also be sent over syslog to a dedicated server. The system also needs to be monitored by whatever operational monitoring system is in use.
NSO has extensive logging functionality. Log settings are typically very different for a production system compared to a development system. During development, we typically want to turn on the developer-log. The sample ncs.conf that comes with the NSO release has log settings suitable for development, while the ncs.conf created by a "system install" are suitable for production deployment, but can be customized on a case-by-case bases.
Upgrade procedures have to be thought through carefully during development, it is easiest if upgrades always comply to the upgrade rules specified in RFC7950 but if more advanced upgrades are needed a special piece of software called an upgrade component can be created.
Best Practices
- Deploy with high availability
- Perform regular backups
- Monitor NSO in the same way as your other enterprise applications
- Define which interfaces each consumer will use, and how they will use them
Checklist
- There are tested disaster recovery procedures in place
- We understand how the deployment architecture impacts our automation journey
- Backups are scheduled and stored off-site
- There are defined operational procedures
- Logging is setup appropriately