第一章 sysrepod概述

摘自:https://blog.csdn.net/m0_47413019/article/details/105840288

Sysrepo是Linux/Unix系统下一个基于YANG模型的配置和操作数据库,为应用程序提供统一的操作数据的接口。应用程序使用YANG模型来建模,通过利用YANG模型完成数据合法性的检查,保证的风格的一致,不需要应用程序直接操作配置文件的一种数据管理方式。

  • 基本特性与原则

       1)、sysrepo只是一个库,不是一个独立的进程

       2)、全部的数据始终由Yang模型区分,这就可能造成许多严重的后果,例如,允许同时使用不同的模型进行工作,这将可  导致数据访问时异常。

       2)、在所有有IPC中使用共享内存的方式,取代了之前的UNIX中进程间通信的方式,这样更高效,性能更优,扩展性更强

       3)、在sysrepo中几乎不存在CPU时间浪费,没有活动等待或者定期检查

       4)、完全可定制化的事件处理,从定期检查或者poll/select到自动线程处理

       5)、访问控制严格受制于文件系统的权限

       6)、Sysrepo操作期间可以修改Yang模型

  • 主要特别

     1)、Sysrepo的主要功能是使用YANG模型对数据进行操作并订阅各种事件。但是,在执行任何操作时,都需要创建会话,连接会话,并要install所支持的各类Yang模型。假如设置了日志操作记录,sysrepo在运行时,也可以保留它的行为记录。

    2)、通过Yang的xpath来修改与获取数据,所以要求了解xpath的基础知识。

    3)、最常见的操作订阅事件和修改订阅事件,订阅事件是允许应用程序根据特定的事件回调相应的数据执行,更改操作。操作执行成功后,会将对应配置操作保存,这样sysrepo可以充当更智能的配置文件,从而保证配置的可恢复性。

   4)、也支持Rpc/Action/Notify的订阅,这样可以通过执行特别的Rpc,就可以分别向其他Sysrepo客户端通知各种生成的事件。

  •  访问方法

    应用程序可以通过两种方法来访问sysrepo,一种是直接的方法,即当应用程序需要配置数据或者执行相应的callback来响应配置变化时,可以通过sysrepo自带的应用程序来触发用sysrepo的功能函数来实现。这种方法一般用于开发人员自测或验证某个模块时使用;另一种是间接的方法,即应用程序通过创建Deamon进程的方法,该方法是通过将对sysrepo的调用转化为对应用程序的特定操作,该方法也最容易扩展,也无需为了使用sysrepo数据库而做相应的更改。如果有多个类似的Deamon进程,可以将这些进程合成一个plugind,最后由一个进程统一纳管。可扩展性得到大大的提高。间接方法的使用如图1所示:

第一章 sysrepod概述

                                                              图1  sysrepo使用方法

  • 数据库

          数据库结构大多是遵循NMDA(网络管理数据存储区体)所定义的体系架构。Sysrepo同样也不例外,Sysrepo中定义了四类数据库,分别是startup,running,candidate和operational。

         1)、startup库,是sysrepo中唯一的持久性数据存储库,它包含设备启动时的配置文件,系统启动后创建的第一个Sysrepo连接(共享内存)时,会将配置文件从startup库copy到running库;

        2)、running数据库,是保存当前所运行时系统配置,当一个配置发生变化时并且设备需要重新配置时,running数据库需要修改。系统重启时不会存在,如果需要,可以将配置copy到startup库。

       3)、Candidate数据库,候选库,顾名思义,它是一个准备配置的数据但又不影响实际设备使用。虽然该库中的数据不限制设备的正常使用,可以不必严格按照NETCONF协议的定义,但也是需要遵循一般的数据存储规则。该库正常是无效的,实际使用时,需要将该库mirror到running,由running完成修改和配置下发,最后通过sr_copy_config(),将Candidate库重置。整个会话的过程中可能需要相应的lock操作,来保证操作的一致与完整性。

     4)、operational库,维护当前使用的配置,并且该库只可读。它通常与对应的running库有所不同,而且,只包含任何状态数据结点。在默认的情况下,该库是空的,对于用户来说,全部的订阅数据和操作数据都存储于operational库中。并且Notificationg RPC/Action数据的校验都是在 operational库是完成。

  • 运行模式

    1)、对于连接与会话来说,会话是不同步的,所以不会在多个线程*享一个会话。每个线程都需要建立属于自己的会话,来确保本线程运行的正确。

   2)、对于订阅来说,可以由应用程序对感兴趣的事件通过*_subscribe()函数来做相应的订阅。订阅在原则上是将全部的的事件一并处理,应用程序也可以将根据不同的事件类型拆分成多个不同的订阅,用于保证事件的并发处理。

  3)、每个订阅可以由不同的方式处理,这个由Sysrepo做统一管理。Sysrepo创建一个单独的线程来捕获各种订阅事件的发生,然后通过订阅所注册的回调函数不处理它们。

上一篇:(JAVASE)CSFrameWork详解(communication层及笼统概述)


下一篇:单机 KubeSphere v3.0的安装