ArubaOS-CX Architecture
The new operating system for the Aruba 8400 and 8320 switches has some special characteristics. The most important is its architecture.
In any legacy OS architecture each software module (or daemon) has and operates its own data and when it needs to interact with another module it makes a call to the other module requesting a piece of information or passing that information. That makes the daemons highly dependent on each other, for example, the development of the modules must be done in synch. Also, if, once the OS is running, a failure or exception in one module can force a reboot of the whole system. Finally, management interfaces are difficult to keep up to date.
In ArubaOS-CX all data, from all modules/daemons, is shared in a central “in-memory” database. That means that every module uses this data repository to ready and write the data used in its own processes. This data repository is called the Current State Database or CSDB. Compared to the legacy architecture, a DB centric OS can be developed faster, its modules are independent from each other, so the system is more resilient, and any management interface only needs to read from and write to the CSDB.
In this OS the configuration is just a “state” in the CSDB, and it can be managed in a simpler way (compared to the legacy “configuration file”).
Because ArubaOS-CX uses this CSDB, the REST API is a natural part of it instead of and add-on like in legacy systems.
In subsequent articles we will explore the CSDB and we will describe how the REST interface and the Network Analytic Engine use this architecture to enable the network administrator to automate operations, gain deeper and faster visibility, monitor in real time and trigger event-based information collection and much more.