====== 4.3.5.1 Types of Manageability Functions ====== [[dido:public:ra:1.4_req:2_nonfunc:28_manageability| Return to the Manageability]] ===== About ===== [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:02_types | Return to Top]] NI (formerly National Instruments) defines four basic [[dido:public:ra:xapend:xapend.a_glossary:m:manageability|manageability]] functions (( What is Manageability?, 5 May 2019, National Instruments (NI), Accessed 25 July 2020, [[https://www.ni.com/en-us/innovations/white-papers/13/what-is-manageability-.html]] )) described in the following Table: ^ Kinds of Management ^ Description ^ ^ **Health Monitoring, Logging, and Alerting** | During operations a key part of managing the system is the collection of metrics about the operations that indicate the health of the system. * Monitoring can include usage of [[dido:public:ra:xapend:xapend.a_glossary:c:cpu]], memory, energy, cache, heat, on-line and off-line storage, network connectivity, network loads of particular computers. In a [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed system]], this also includes the metrics associated with the connectivity of the [[dido:public:ra:xapend:xapend.a_glossary:n:node|nodes]] that participate in the distributed system (i.e., the [[dido:public:ra:xapend:xapend.a_glossary:l:latency|latency]], lag, error rates, upload and download speeds, etc). * Information about the overall operations need to be handled. For example, data used to Trace, and Debug; provide Informational context; and alert to warnings, errors and fatal situations. | ^ **Configuration and Control** | During the startup and sometimes during operations, the system needs to obtain configuration details and provide control over the systems as a whole or to the individual components. This becomes even more important in a system that is distributed on a system of nodes. [(notes:>**Note:** The following example of how configuarions can become a manageability issue is from Candea [[dido:public:ra:1.4_req:2_nonfunc:28_manageability#fn__1| 1)]]- //The greatest manageability challenge is posed by stateful systems (e.g., databases, filesystems). By contrast, stateless applications (e.g., Web servers) require little configuration, can be scaled through mere replication, and are reboot-friendly. While one administrator can manage 100s to 1000s of Web servers, it takes approximately one administrator for each TB of data in a database. The number of knobs on stateful systems is overwhelming: the Oracle [[dido:public:ra:xapend:xapend.a_glossary:d:dbms|DBMS]] has 220 initialization parameters and 1,477 tables of system parameters, while its “Administrator's Guide” is 875 pages long.//)] * Typical [[dido:public:ra:xapend:xapend.a_glossary:c:cm|configuration management]] data are [[dido:public:ra:xapend:xapend.a_glossary:i:ipaddr]], network ports, environment paths to files, and maximum usage limits for things like CPU and disk space. * Typical commands are start, pause, resume and stop. Sometimes abort is also used to capture detailed dump files that can be used for analysis. | ^ **Deployment and Updates** | During operations, * There is sometimes a need for the efficient and sometimes automatic deployment of system resources such as web servers, application servers, [[dido:public:ra:xapend:xapend.a_glossary:d:dbms]], backups etc. This is useful when systems are made as a collection of other systems but is critical when managing distributed systems. * In addition, this kind of management needed during first-time installation of systems (i.e., wizards) but also in deployed systems for applying patches, [[dido:public:ra:xapend:xapend.a_glossary:p:performance|performance]], and feature updates. | ^ **Asset Discovery and Inventory** | In remote systems or especially in distributed systems, an accurate and timely [[dido:public:ra:xapend:xapend.a_glossary:d:discovery|discovery]] of the system or component needs to be made. * In truly distributed systems, this discovery needs to be dynamic and should easily adapt to new locations. In a distributed system this must also support the dynamic creation and destruction of nodes in the system network. * In complex systems deployed on a single computer there is a dependency on other components within the node. An inventory needs to be made of the components required as included in a package management description (i.e., manifest). * In a distributed system running on distributed nodes there is a need to understand the resources dedicated to the system. Having an automated inventory helps with asset management, containing cost controls, and scheduling maintenance or replacement of systems. | ~~REFNOTES notes ~~
The kinds of Management Functions needed for Manageability
===== DIDO Specifics ===== [[dido:public:ra:1.4_req:2_nonfunc:28_manageability:02_types | Return to Top]] : To be added/expanded in future revisions of the DIDO RA /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- /* To add a discussion page to this page, comment out the line that says ~~DISCUSSION:off~~ */ ~~DISCUSSION:on|Outstanding Issues~~ ~~DISCUSSION:off~~