WO2023082537A1 - 一种基于拟态数据库的网络操作系统设计方法 - Google Patents

一种基于拟态数据库的网络操作系统设计方法 Download PDF

Info

Publication number
WO2023082537A1
WO2023082537A1 PCT/CN2022/084973 CN2022084973W WO2023082537A1 WO 2023082537 A1 WO2023082537 A1 WO 2023082537A1 CN 2022084973 W CN2022084973 W CN 2022084973W WO 2023082537 A1 WO2023082537 A1 WO 2023082537A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
mimetic
storage
database
mimic
Prior art date
Application number
PCT/CN2022/084973
Other languages
English (en)
French (fr)
Inventor
王培磊
张汝云
邹涛
黄培龙
Original Assignee
之江实验室
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 之江实验室 filed Critical 之江实验室
Priority to US17/824,349 priority Critical patent/US11934383B2/en
Publication of WO2023082537A1 publication Critical patent/WO2023082537A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275—Synchronous replication

Definitions

  • the present invention claims the priority of the Chinese patent application with the application number 202111416379.0 and the title of the invention "a method for designing a network operating system based on a mimic database” filed with the China Patent Office on November 26, 2021, the entire contents of which are incorporated by reference here.
  • the invention relates to the technical field of network communication and database, in particular to a method for designing a network operating system based on a mimetic database.
  • SONiC network operating system represented by SONiC
  • SDN software-defined network
  • SONiC can realize the decoupling of software operating system and hardware platform, so as to realize a more open network, and is more and more widely used in public cloud data centers and other fields.
  • the network operating system often takes the database as the core, and all modules revolve around the interaction with the database. Therefore, the security of the database is very important, and how to balance the security storage of the database with the speed of reading and writing and version compatibility needs to be solved urgently. .
  • the object of the present invention is to provide a network operating system design method based on a mimetic database to overcome the deficiencies in the prior art.
  • the present invention provides the following technical solutions:
  • the present application discloses a network operating system design method based on a mimetic database, which is characterized in that the network operating system includes a general database and various business modules interacting with the general database, and the general database includes servers from high to low , database, data object, data structure and five levels of data, the specific steps of the design method are as follows:
  • the data structure realizes mimetic isomorphism or mimetic heterogeneous storage of data.
  • the mimetic isomorphic storage is to store the same data in multiple different addresses in the same existing memory. Backing up; the pseudo-heterogeneous storage is based on the heterogeneous memory of the actual hardware platform environment, and the same data is backed up in different memories;
  • the data object realizes the organization and storage of the mimetic data structure; the storage of the mimetic data structure is performed as a choice between ordinary storage and mimetic storage;
  • the database realizes the integration, management and storage of the mimetic data objects; the storage of the mimetic data objects is performed as a choice between ordinary storage and mimetic storage;
  • the synchronization mechanism is used to unify the contents of homogeneous or heterogeneous databases, data objects or data structures;
  • the adjudication mechanism is used in homogeneous or heterogeneous databases Select appropriate data objects, select appropriate data structures among homogeneous or heterogeneous data objects, select appropriate data among homogeneous or heterogeneous data structures;
  • the step S1 specifically includes the following sub-steps:
  • the overall framework and external interface of the mimetic data structure includes mimetic data items;
  • the external interface includes but is not limited to creating, adding, deleting, modifying, obtaining data, obtaining status, etc.;
  • the management module includes homogeneous storage management and heterogeneous storage management; the homogeneous storage management adopts a random memory allocation strategy; the heterogeneous storage management requires hardware heterogeneous support;
  • the mimetic storage detection module is used to detect whether the interface of the mimetic storage management module meets the functional and performance requirements after cross-platform transplantation, and automatically shields the relevant mimetic storage function if it does not meet the requirements;
  • the detection mechanism described in step S13 includes but is not limited to the following methods:
  • S132 After the system is powered on, it performs periodic time detection, divides all detection content into several parts, and detects one of the parts after each time period arrives; during the detection process, the valid data is backed up, and if detection fails at any detection node, then Shield hardware heterogeneous functions, and convert backed-up data into mimetic isomorphic storage;
  • the step S2 specifically includes the following sub-steps:
  • the overall framework and external interface of the mimetic data object includes the mimetic data structure item, and also includes the selection/flag item for ordinary storage or mimetic storage of the mimetic data structure;
  • the external interface includes but does not Limited to creating, adding, deleting, modifying, etc.;
  • the step S3 specifically includes the following sub-steps:
  • the synchronization mechanism in step S4 is executed in the following situations:
  • the safe storage command list in the step S5 includes security level features, and the same safe storage command may have different security levels;
  • the secure storage instruction processor in the step S5 plans the organizational hierarchy according to the security level
  • the classified storage mechanism in the step S6 is specifically divided into the following situations:
  • the present invention provides a network operating system design method based on a mimetic database to solve the existing problems of insufficient security and weak resistance to unknown risks in existing network operating systems.
  • a network operating system design method based on a mimetic database to solve the existing problems of insufficient security and weak resistance to unknown risks in existing network operating systems.
  • vertical classification and horizontal classification the compatibility problem with the network operating system after the database mimicry transformation is solved.
  • the cost caused by the mimetic transformation can be reduced, and the cost can be controlled while improving security.
  • FIG. 1 is a flow chart of a method for designing a network operating system based on a mimetic database provided by an embodiment of the present invention.
  • Figure 2 is a schematic diagram of the SONiC system framework.
  • Figure 3 is a schematic diagram of the Redis hierarchy.
  • Figure 4 is a schematic diagram of the dictionary data structure before and after the skeuomorphic transformation.
  • Fig. 5 is a schematic diagram of the names and functions of the mimicry dictionary interface.
  • FIG. 6 is a schematic diagram of hardware heterogeneous storage functions.
  • Fig. 7 is a schematic diagram of a framework of a mimic hash object.
  • Fig. 8 is a schematic diagram of the framework of the mimetic database.
  • Fig. 9 is a schematic diagram of a security level structure.
  • an embodiment of the present invention provides a method for designing a network operating system based on a mimic database, wherein the network operating system includes a mimic database and various business modules interacting with the database, and the mimic database is derived from From high to low, there are five levels including server, database, data object, data structure and data.
  • the present invention is implemented with the SONiC system as the basic framework.
  • the Redis database is at the center of the SONiC architecture, and each business logic module directly interacts with Redis, thereby realizing data distribution and sharing.
  • Redis is an in-memory database implemented in C language, and the embodiments of the present invention focus on the mimic transformation of Redis. Specifically, referring to Figure 3, Redis itself can be divided into five levels: server, database, data object, data structure, and data. Redis is externally represented as a server, which stores user data through layer-by-layer organization.
  • the design method specifically follows the steps:
  • Step S1 designing a mimetic data structure, the data structure implements mimetic isomorphism or mimetic heterogeneous storage of data, and the mimetic isomorphic storage is to store the same data in multiple different memory in the same existing memory
  • the address is backed up; the pseudo-heterogeneous storage is based on the heterogeneous memory of the actual hardware platform environment, and the same data is backed up in different memories, which specifically includes the following steps:
  • Step S11 designing the overall framework and external interface of the skeuomorphic data structure; the overall framework includes skeuomorphic data items; the external interface includes but not limited to creating, adding, deleting, modifying, obtaining data, obtaining status, etc.
  • the applications of Redis in SONiC are mainly commands such as HSET and HGET, which are operations for hash objects, and the hash objects in Redis have two encoding methods: compressed linked list and hash table.
  • the compressed linked list only saves data that occupies a small space
  • the main data saving work is done through hash table encoding
  • the implementation of hash table encoding depends on the dictionary data structure.
  • the dictionary data structure is also used to realize the key-value space management in the Redis database, so the easiest way to realize mimetic safe storage is to transform the dictionary into mimetic, that is, to design a mimetic dictionary.
  • Redis is developed based on the C language.
  • the C language itself does not have a built-in dictionary as a data structure. It needs to be implemented by itself.
  • the mimetic dictionary can be designed on the basis of the Redis native code implementation. If you need a higher level of security, or have the ability and willingness to maintain more complex code, you can also transform more types of data structures—such as linked lists, collections, compressed collections—and other data structures into mimetic transformations.
  • a simple mimetic transformation of the dictionary data structure is to expand the key and val nodes in the dictionary data structure from one to three, and the memory space pointed to by the newly added key and val pointers must be redesigned Assign, and then copy the original key value and val value respectively. Therefore, although the three keys and vals all point to the same data, they do not point to the same data.
  • three copies are selected for the follow-up judgment module to adopt a majority judgment scheme.
  • a larger number of keys and vals can be copied according to the actual judgment scheme, software and hardware performance and requirements, so as to achieve higher security. performance.
  • the data copying process here can be compared to the behavior of "distributing tasks" to executive bodies in the mimetic defense design system.
  • Step S12 designing a mimetic storage management module
  • the management module includes homogeneous storage management and heterogeneous storage management; the homogeneous storage management adopts a random memory allocation strategy; the heterogeneous storage management needs the support of heterogeneous hardware.
  • isomorphic storage using a random allocation strategy There are many ways to implement isomorphic storage using a random allocation strategy. One is based on the malloc/free function. First, the random number of mallocs is continuous, and one of them is randomly selected to save data, and then the remaining space is released. This method is essentially continuous allocation based on malloc, resulting in insufficient security. Another implementation is to develop a safemalloc function with reference to malloc, and use a random allocation strategy internally. This implementation is more secure and more difficult.
  • Heterogeneous storage management requires the support of hardware heterogeneity. Specifically, refer to Figure 6.
  • the CPU has multiple externally expanded heterogeneous memories that can be accessed. These memories are set as mimic data through customized driver development and other methods.
  • the storage is dedicated to avoid being allocated to different processes by the system as a virtual address space.
  • the data that needs mimetic storage can be sent to the external memory A, B, and C respectively, so as to realize heterogeneous storage and greatly increase the attack cost of the attacker.
  • Step S13 designing a mimetic storage detection module, which is used to detect whether the interface of the mimetic storage management module meets the functional and performance requirements after cross-platform transplantation, and automatically blocks related mimetic storage functions if the requirements are not met.
  • This method is suitable for the design of small-scale mimetic storage modules.
  • the type and quantity of data for mimetic storage are small, so only simple mimetic storage modules and their interfaces need to be developed, and the detection blocking time for these interfaces is relatively short. Blocking detection after power-on can be used.
  • S132 after the system is powered on, it performs time periodical detection, divides all detection content into several parts, and detects one of the parts after each time period arrives; during the detection process, the valid data is backed up, and if any detection node fails to detect, then Shield the hardware heterogeneous function, and convert the backup data into mimic homogeneous storage.
  • the specific implementation of the detection method may use a clock timer to detect once every 10s or 1min. For example, if the storage space to be detected is 100M, the space of 10M can be detected in 10 times each time.
  • the validity of the implementation of the interface in the target space will be tested first, and after the detection is passed, it will be marked, and the next time it will be stored The detection will not be repeated. In this way, after a certain number of commands are executed, most or even all interfaces of the mimetic storage management module can be checked again. This method will hardly block, but the risk of potential program bugs is relatively high, and the maintenance cost is high.
  • the key detection is placed in the power-on initialization stage to block execution, the less important detection is detected step by step in the clock cycle, and the remaining niche interfaces are single-step detection before calling. .
  • Step S2 designing a mimetic data object, the data object realizes the organization and storage of the mimetic data structure; the storage of the mimetic data structure is an alternative between ordinary storage and mimetic storage; specifically, Contains the following substeps:
  • Step S21 designing the overall framework and external interface of the mimetic data object;
  • the overall framework includes the mimetic data structure item, and also includes the selection/flag item for ordinary storage or mimetic storage of the mimetic data structure;
  • the external interface includes but Not limited to creation, addition, deletion, modification, etc.
  • the mimetic data object When designing the overall framework and external interface of the mimetic data object, in principle, it is the same as the mimetic data structure, not all data types of data objects must be mimetic transformation, but according to the actual needs of the network operating system, select The data objects of some data types are skeuomorphically transformed. Taking Redis-based SONiC as an example, it is similar to the fact that we only need to mimic the underlying dictionary data structure. At the data object level, we only need to modify the most widely used hash type objects in SONiC. . In the source code of Redis, the type constants of data objects are REDIS_STRING, REDIS_LIST, REDIS_HASH, REDIS_SET, and REDIS_ZSET, and the REDIS_SAFEHASH type can be added at this time.
  • the structure of the data object in the Redis source code refers to Figure 7, where the encoding field was originally used to mark the encoding format of a specific type of data.
  • the original hash type data object has two encodings: ziplisht and hashtable, and the hashtable encoding format corresponds to
  • the underlying data structure of is the dictionary data structure.
  • This field can be reused for the frame design of skeuomorphic data objects.
  • the type of mimicry data object can be fixed as REDIS_SAFEHASH, and the encoding format can also be fixed as safehashtable, and the corresponding underlying data structure is the mimicry dictionary safeDict data structure designed in step S1. Therefore, the encoding field can be used to mark/control whether to perform mimicry storage on the mimicry dictionary safeDict. This flag/control bit determines whether a copy or multiple copies of the mimic data structure in the mimic data object are saved.
  • the pointer of the Redis mimic hash object pointing to the underlying data structure is ptr, which can be expanded in a similar manner in step S11, from one ptr to prtA, ptrB and ptrC. It is also possible to keep the framework of the structure unchanged, and let the ptr pointer point to another data structure safeDictEntry, which contains three pointers, respectively pointing to safeDictA, safeDictB, and safeDictC of homogeneous or heterogeneous storage. The latter method is adopted as much as possible here, because the coupling between data objects and other modules in Redis is high, and the interface implementation of data objects is relatively complicated, which is consistent with the native framework, which can avoid many bugs.
  • the interface for data objects includes the addition, deletion, modification, and query interfaces of various object types and related business logic interfaces, and we only perform mimetic transformation for hash objects, and only one type of external interface needs to be retained Add, delete, modify and check the interface, which greatly reduces the workload of development and maintenance.
  • Step S22 designing a mimic data structure management module for managing the mimic data structures stored in the mimic data objects.
  • the storage of the mimetic data structure in the mimetic data object you can refer to the data storage of the mimetic data structure in step S12, and choose to adopt the homogeneous or heterogeneous method according to the hardware heterogeneity support.
  • the storage of the mimic dictionary data structure in the mimic hash object can be mimicked It can also be non-mimetic, that is, store only one, so the mimic data structure management module needs to decide whether to use ordinary storage or mimic storage according to the encoding field in the mimic hash object structure.
  • the mimic dictionary data structure management module can be defined as a structure, and the instantiation of the structure is a mimic dictionary data data manager.
  • an associated mimic dictionary data structure manager can be created synchronously.
  • different management functions are registered in the manager, so that the mimic hash object targets data
  • polymorphic features in object-oriented can be realized.
  • Step S3 designing a mimetic database, which realizes the integration, management and storage of mimetic data objects; the storage of mimetic data objects is a choice between ordinary storage and mimetic storage. Specifically, the following sub-steps are included:
  • Step S31 designing the overall framework of the mimetic database, which includes a mimetic health value space and a non-mimetic health value space.
  • step S1 a mimetic hash table designed in step S1 is added as the mimetic health value space for management.
  • Step S32 designing a mimetic data object management module for managing key-value objects in the mimetic key-value space.
  • the database manages the data objects in the health value space by directly calling the interface of the data object module.
  • the database contains a mimic health value space and a common health value space, so it is necessary to design an additional mimic data object management module, which becomes a mimic data object manager after instantiation, and the manager is based on the associated health value
  • the space registers the common data object management interface or the mimetic data object management interface, so as to avoid the need to detect the type of the key value space every time it is called. Similar to the mimic data structure manager in step S22, object-oriented polymorphism can be realized.
  • the skeuomorphic database resides on the server independently of the non-skeuomorphic database.
  • a redisDb item which stores the original data information.
  • a redisSafeDb item is added to the Redis source code, that is, a mimic database item, so as to avoid conflicts with the original database-related data and its business logic, and decouple as much as possible to reduce the difficulty of development and maintenance.
  • Step S4 designing a synchronization and adjudication mechanism, the synchronization mechanism is used to unify the contents of homogeneous or heterogeneous databases, data objects or data structures; the adjudication mechanism is used in homogeneous or heterogeneous databases Select the appropriate data object among them, select the appropriate data structure among the homogeneous or heterogeneous data objects, and select the appropriate data among the homogeneous or heterogeneous data structures.
  • the synchronization mechanism is the process of maintaining data consistency in the ruling pool.
  • the synchronization mechanism plays a role in the following three situations:
  • synchronization is required to update all homogeneous or heterogeneous stored data synchronously.
  • Synchronous actions can be triggered periodically as a time event. Traversing each key-value pair, adjudicating the data of the mimic transformation first, and calling the synchronization mechanism described in step S42 if the data is found to be different.
  • the traversal process here may cause blocking, so synchronization can be performed step by step, that is, only a part of the data will be synchronized after the arrival of a time period, and the synchronization progress will be recorded, and finally all data will be synchronized in several time periods to prevent One-time blocking for too long causes problems with other business logic.
  • Step S5 designing a security storage command processing system for the mimetic database, the processing system includes a security storage command list, a security storage command distributor and a security storage command processor.
  • the secure storage instruction list includes security level features, and the same secure storage instruction may have different security levels.
  • the secure storage instruction processor plans an organizational hierarchy according to security levels.
  • RedisCommandTable In the native Redis code, all commands are instances of the redisCommand structure and are managed in the redisCommandTable. Instructions related to safe storage can reuse the redisCommand structure and expand it in redisCommandTable. In this way, it can be compatible with the process of command transmission and execution between the client and server in Redis.
  • the write instructions (SHSET, SHMSET) of Mimic Redis's secure storage need to increase the security level feature.
  • the security level can be divided into three levels: low, medium, and high.
  • the Redis database includes five levels of server, database, data object, data structure, and data.
  • the low security level corresponds to mimetic storage of data only at the data structure level, namely: 1. In the server In the database, select the key-value space of the ordinary dictionary structure to create key-value pairs; 2.
  • the key is an ordinary string object, and the value is a secure hash object stored in ordinary, that is, redisObject
  • the ptr pointer in only points to one piece of data; 3.
  • the security hash object the data is stored in a mimetic way through the mimetic security dictionary data structure.
  • the medium security level is to carry out mimetic storage at the two levels of data objects and data structures, namely: 1. In the database of the server, select the key-value space of the ordinary dictionary structure to create key-value pairs; 2. The key in the ordinary key-value space In the value pair, the key is an ordinary string object, and the value is a secure hash object stored in mimicry, that is, the ptr pointer in redisObject points to three pieces of data; 3. In each secure hash object, the mimicry The secure dictionary data structure stores data in a mimetic manner.
  • the high security level corresponds to the fact that all nodes adopt mimetic storage, namely: 1. In the database of the server, select the key-value space of the mimetic security dictionary structure to create key-value pairs; 2. Key-value pairs in the mimetic security key-value space Among them, the key is the backed up three string objects, and the value is the secure hash object stored in mimicry, that is, the ptr pointer in redisObject points to three pieces of data; 3. In each secure hash object, it passes mimicry
  • the secure dictionary data structure is optimized to store data in a mimetic manner.
  • Step S6 designing a classified storage mechanism for data exchanged between business modules and databases in the network operating system.
  • Redis-based SONiC there are multiple containers that process business logic running simultaneously in the system, and the Redis server also runs in parallel as a separate container.
  • Typical data with low access rate and high security requirements is the configuration information of each business logic input by the user. The information is forwarded to each destination container through the Redis database container as an intermediate link.
  • Typical data with high access rate and low security requirements is the log information of device operation, and access instructions with low level or even no security requirements can be used.

Abstract

一种基于拟态数据库的网络操作系统设计方法，包括：设计拟态化的数据结构（S101）；设计拟态化的数据对象（S102）；设计拟态化的数据库（S103）；设计同步和裁决机制（S104）；设计拟态数据库安全存储指令处理系统（S105）；设计网络操作系统当中业务模块与数据库交互数据的分类存储机制（S106）。上述方法通过纵向分级和横向分类的方式，解决了数据库拟态化改造后与网络操作系统的兼容性问题。通过内存随机分发存储机制和内存硬件异构存储机制，可以降低拟态化改造所造成的成本，提高安全性的同时实现成本可控。

Description

一种基于拟态数据库的网络操作系统设计方法
交叉引用
本发明要求于2021年11月26日向中国专利局提交的申请号为202111416379.0、发明名称为“一种基于拟态数据库的网络操作系统设计方法”中国专利申请的优先权，其全部内容通过引用，合并于此。
技术领域
本发明涉及网络通信和数据库技术领域，特别涉及一种基于拟态数据库的网络操作系统设计方法。
背景技术
近些年以SONiC为代表的网络操作系统正如火如荼地发展起来，特别是在软件定义网络(SDN)的场景当中。SONiC可以实现软件操作系统与硬件平台的解耦，从而实现更加开放的网络，并越来越广泛地应用到公有云数据中心等领域当中。网络操作系统往往以数据库为核心，所有模块都围绕着跟数据库的交互来进行，因而数据库的安全性就至关重要，而如何兼顾数据库安全存储与读写速率以及版本兼容性等问题也亟待解决。
发明内容
本发明的目的在于提供一种基于拟态数据库的网络操作系统设计方法，以克服现有技术中的不足。
为实现上述目的，本发明提供如下技术方案：
本申请公开了一种基于拟态数据库的网络操作系统设计方法，其特征在于，所述的网络操作系统包括总数据库以及与总数据库交互的各个业务模块，所述的总数据库从高到低包含服务器、数据库、数据对象、数据结构和数据五个层级，所述设计方法具体如下步骤：
S1、设计拟态化的数据结构，所述数据结构实现对数据的拟态同构或拟态异构存储，所述的拟态同构存储是在现有的同一内存当中将同一数据在多个不同的地址进行备份；所述拟态异构存储基于实际硬件平台环境的异构内存，在不同内存当中对同一数据进行备份；；
S2、设计拟态化的数据对象，所述数据对象实现对拟态化数据结构的组织和存储；所述对拟态化数据结构的存储表现为普通存储和拟态存储之间二选一；
S3、设计拟态化的数据库，所述数据库实现对拟态化数据对象的整合、管理和存储；所述对 拟态化数据对象的存储表现为普通存储和拟态存储之间二选一；
S4、设计同步和裁决机制，所述同步机制用于将同构或异构的数据库、数据对象或数据结构当中的内容进行统一；所述的裁决机制用于在同构或异构的数据库当中选择合适的数据对象、在同构或异构的数据对象中选择合适的数据结构、在同构或异构的数据结构中选择合适的数据；
S5、设计拟态数据库安全存储指令处理系统，所述处理系统包含安全存储指令列表，安全存储指令分发器和安全存储指令处理器；
S6、设计网络操作系统当中业务模块与总数据库交互数据的分类存储机制。
作为优选，所述步骤S1具体包括以下子步骤：
S11、设计拟态化数据结构总体框架和对外接口；所述总体框架包含拟态化数据项；所述对外接口包括但不限于创建、增加、删除、修改、获取数据、获取状态等；
S12、设计拟态存储管理模块，所述管理模块包括同构存储管理和异构存储管理；所述同构存储管理采用随机性内存分配策略；所述异构存储管理需要硬件异构的支持；
S13、计拟态存储检测模块，用于跨平台移植后检测拟态存储管理模块接口是否满足功能和性能要求，若不符合要求则自动屏蔽相关的拟态存储功能；
作为优选，所述步骤S13中所述的检测机制包括但不限于以下方法：
S131、系统上电初始化阶段进行阻塞式检测，检测通过后再执行后续业务逻辑；
S132、系统上电后进行时间周期性检测，将所有检测内容分成几个部分，每个时间周期到达后检测其中一个部分；检测过程中对有效数据进行备份，在任意检测节点出现检测失败，则屏蔽硬件异构功能，将备份的数据转换为拟态同构存储；
S133、系统上电后进行单步检测，在每个拟态数据存取处理的过程当中，先对即将调用的拟态存储管理模块的接口进行检测；检测过程中对有效数据进行备份，在任意检测节点出现检测失败，则屏蔽硬件异构功能，将备份的数据转换为拟态同构存储；检测通过后记录检测结果，避免重复检测；
作为优选，所述步骤S2具体包括以下子步骤：
S21、设计拟态化数据对象总体框架和对外接口；所述总体框架当中包含拟态化数据结构项，也包含对拟态数据结构进行普通存储或拟态存储的选择/标志项；所述对外接口包括但不限于创建、增加、删除、修改等；
S22、设计拟态数据结构管理模块，用于管理存储在拟态化数据对象当中的拟态化数据结构；
作为优选，所述步骤S3具体包括以下子步骤：
S31、设计拟态化数据库总体框架，所述总体框架当中包含拟态化的健值空间和非拟态化的健值空间；
S32、设计拟态数据对象管理模块，用于管理拟态化健值空间当中的键值对象；
作为优选，所述步骤S4中的同步机制在以下几种情形当中被执行：
S41、被拟态保护的数据发生修改；
S42、裁决发现数据不统一；
S43、时间周期性触发；
作为优选，所述步骤S5中的安全存储指令列表包含了安全等级特征，相同的安全存储指令可以有不同的安全等级；
作为优选，所述步骤S5中的安全存储指令处理器根据安全等级来规划组织层次结构；
作为优选，所述步骤S6中的分类存储机制具体分为以下几种情形：
S61、无安全性要求数据、高耦合性数据采用原始数据库存储指令或接口；
S62、低耦合性数据中，按照安全性需求和存取速率需求，选择不同安全等级的存取方式。
本发明的有益效果：与现有技术相比，本发明提供一种基于拟态数据库的网络操作系统设计方法，以解决现有存在的网络操作系统安全性不足、未知风险抵御能力较弱的问题。通过纵向分级和横向分类的方式，解决了数据库拟态化改造后与网络操作系统的兼容性问题。通过内存随机分发存储机制和内存硬件异构存储机制，可以降低拟态化改造所造成的成本，提高安全性的同时实现成本可控。
本发明的特征及优点将通过实施例结合附图进行详细说明。
附图说明
图1是本发明实施例提供的一种基于拟态数据库的网络操作系统设计方法的流程图。
图2是SONiC系统框架示意图。
图3是Redis层次结构示意图。
图4是拟态化改造前后的字典数据结构示意图。
图5是拟态字典接口名称以及功能示意图。
图6是硬件异构存储功能示意图。
图7是拟态哈希对象的框架示意图。
图8是拟态数据库框架示意图。
图9是安全等级结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明了，下面通过附图及实施例，对本发明进行进一步详细说明。但是应该理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。
参考图1，本发明实施例提供一种基于拟态数据库的网络操作系统设计方法，其特征在于，所述的网络操作系统包括拟态数据库以及与该数据库交互的各个业务模块，所述的拟态数据库从高到低包含服务器、数据库、数据对象、数据结构和数据五个层级。
具体的，参考图2，以SONiC系统为基本框架实施本发明，处于SONiC架构中心位置的为Redis数据库，各个业务逻辑模块直接跟Redis进行交互，从而实现数据的分发和共享。
Redis是以C语言进行实现的内存数据库，本发明的实施例以Redis的拟态化改造为重点。具体的，参考图3，Redis本身即可以分为服务器、数据库、数据对象、数据结构和数据五个层级，Redis对外表现形式为一台服务器，通过层层组织，将用户数据保存起来。
所述设计方法具体如下步骤：
步骤S1，设计拟态化的数据结构，所述数据结构实现对数据的拟态同构或拟态异构存储，所述的拟态同构存储是在现有的同一内存当中将同一数据在多个不同的地址进行备份；所述拟态异构存储基于实际硬件平台环境的异构内存，在不同内存当中对同一数据进行备份，具体包含以下步骤：
步骤S11，设计拟态化数据结构总体框架和对外接口；所述总体框架包含拟态化数据项；所述对外接口包括但不限于创建、增加、删除、修改、获取数据、获取状态等。
具体的，可以将传统的链表、集合、字典等进行拟态化改造。需要注意的是，此处的拟态化改造并非针对数据库当中的所有数据结构进行，本发明的目的是构造一个安全的网络操作系统而非数据库，因而针对数据结构的拟态化改造要按照网络操作系统的实际需求进行。
以基于Redis的SONiC系统为例，SONiC当中对于Redis的应用主要是HSET、HGET等命令，也就是针对哈希对象的操作，而Redis当中的哈希对象有压缩链表和哈希表两种编码方式，其中压缩链表只保存占用空间较小的数据，主要的数据保存工作是通过哈希表编码完成，而哈希表编码形式的实现则依赖于字典数据结构。同时，字典数据结构还用来 实现Redis数据库中的键值空间管理，因而最简单的实现拟态化安全存储的方法，就是将字典进行拟态化改造，也就是设计一个拟态化的字典。
Redis是基于C语言开发，C语言本身并不内置字典这一数据结构，需要自行实现，拟态化的字典可以在Redis原生代码实现的基础上进行设计。如果需要更高的安全等级，或者有维护更复杂代码的能力和意愿，也可以将更多类型的数据结构——例如链表、集合、压缩集合——等数据结构也进行拟态化改造。
具体的，参考图4，一种简单的将字典数据结构进行拟态化改造是将字典数据结构当中的key和val节点由一个扩展为三个，新增的key和val指针指向的内存空间要重新分配，然后将原先的key值和val值分别拷贝过去。由此，虽然三个key和val都指向相同的数据，但并非指向同一个数据。此处选择拷贝三份，是为了后续裁决模块采用择多裁决的方案，当然也可以根据实际采用的裁决方案以及软硬件性能和需求，拷贝更多数量的key和val，从而实现更高的安全性能。而此处的数据拷贝过程，可以类比为拟态防御设计体系当中的向执行体“分发任务”的行为。
具体的，参考图5，设计并实现该模块的相关接口，对比Redis原有的字典操作相关接口，省略了一些非必要功能的接口，相当于一个定制化的标准字典数据结构的功能子集，从而简化开发和维护的难度。
步骤S12，设计拟态存储管理模块，所述管理模块包括同构存储管理和异构存储管理；所述同构存储管理采用随机性内存分配策略；所述异构存储管理需要硬件异构的支持。
具体的，在拟态数据框架下，当对同一个数据进行存储时，需要重新开辟多个内存空间，最简单的内存分配方法是基于malloc函数，但该函数往往分配的是连续的内存空间，难以达到拟态存储的要求。采用随机性内存分配策略的同构存储或基于硬件异构支持的异构存储，无论是采用哪种策略，整个拟态存储管理模块的对外接口保持一致，内部策略用户不感知。
采用随机性分配策略的同构存储的实现有多种方式，一种是基于malloc/free函数，先连续malloc随机次数，从中随机选择一个用于保存数据，然后将剩余的空间释放掉。这种方式本质上还是基于malloc的连续分配，导致安全性不足。还有一种实现方式是参考malloc开发一个safemalloc函数，内部采用随机分配策略，这种实现方式安全性更高，难度也更大。
异构存储管理需要硬件异构的支持，具体的，参考图6，CPU有多个外扩的异构的内存可以进行存取访问，这些内存通过定制化驱动程序开发等方式，设置成为拟态数据存储专 用，避免被系统作为虚拟地址空间分配给不同的进程。硬件异构支持的情况下，需要拟态化存储的数据可以分别下发给外扩内存A、B、C当中，从而实现异构存储，大大增加攻击者的攻击成本。
步骤S13，设计拟态存储检测模块，用于跨平台移植后检测拟态存储管理模块接口是否满足功能和性能要求，若不符合要求则自动屏蔽相关的拟态存储功能。
由于硬件异构存储不一定能获得硬件上的支持，且跨平台移植后用户实现的驱动也存在功能和性能的不确定性，因而对于硬件异构存储部分的功能需要进行隔离，以防上电以后发现硬件异构不可用的情形。一方面用户可以通过配置文件主动关闭硬件异构的功能；另一方面，即使用户开启了硬件异构功能，系统上电后也要对该部分接口进行功能和性能的检测。具体的，包含以下方法：
S131，系统上电初始化阶段进行阻塞式检测，检测通过后再执行后续业务逻辑。
该方法适用于规模较小的拟态存储模块设计，例如针对拟态存储的数据量种类和数量都较小，因而只需要开发简单的拟态存储模块及其接口，针对这些接口的检测阻塞时间较短，可以采用上电后阻塞式检测。
S132，系统上电后进行时间周期性检测，将所有检测内容分成几个部分，每个时间周期到达后检测其中一个部分；检测过程中对有效数据进行备份，在任意检测节点出现检测失败，则屏蔽硬件异构功能，将备份的数据转换为拟态同构存储。
该检测方法的具体实现，可以采用一个时钟定时器，每10s或者1min左右检测一次。例如待检测的存储空间是100M，则可以分10次每次检测10M的空间。
S133，系统上电后进行单步检测，在每个拟态数据存取处理的过程当中，先对即将调用的拟态存储管理模块的接口进行检测；检测过程中对有效数据进行备份，在任意检测节点出现检测失败，则屏蔽硬件异构功能，将备份的数据转换为拟态同构存储；检测通过后记录检测结果，避免重复检测。
例如某个数据需要在某10M空间上进行存储，则在调用拟态存储管理模块的相关接口之前，先对该接口在目标空间上的执行的有效性进行检测，检测通过后进行标记，下一次存储时不会重复检测。这样，在执行了一定数量的命令后，大部分甚至所有的拟态存储管理模块的接口都可以检测一遍，这种方法几乎不会阻塞，但潜在程序bug的风险较大，维护成本高。
一般情况下可以采用三种方法相结合的方式，例如将关键检测放在上电初始化阶段阻塞执行，次重要的检测分步在时钟周期当中检测，剩余的小众接口进行调用前的单步检 测。
步骤S2，设计拟态化的数据对象，所述数据对象实现对拟态化数据结构的组织和存储；所述对拟态化数据结构的存储表现为普通存储和拟态存储之间二选一；具体的，包含以下子步骤：
步骤S21，设计拟态化数据对象总体框架和对外接口；所述总体框架当中包含拟态化数据结构项，也包含对拟态数据结构进行普通存储或拟态存储的选择/标志项；所述对外接口包括但不限于创建、增加、删除、修改等。
在设计拟态化数据对象的总体框架和对外接口时，原则上与拟态化数据结构一样，并非对所有的数据类型的数据对象都要进行拟态化改造，而是根据网络操作系统的实际需求，选择一部分数据类型的数据对象进行拟态化改造。以基于Redis的SONiC为例，类似于我们只需要对底层的字典数据结构进行拟态化改造，在数据对象这一层，也只需要针对SONiC当中应用最广泛的哈希类型的对象进行改造即可。在Redis的源码当中，数据对象的类型常量分别是REDIS_STRING、REDIS_LIST、REDIS_HASH、REDIS_SET和REDIS_ZSET，此时可以增加REDIS_SAFEHASH类型。
Redis源码当中数据对象的结构体参考图7，其中encoding字段原先是用于标记特定类型的数据的编码格式，例如原生的哈希类型的数据对象有ziplisht和hashtable两种编码，其中hashtable编码格式对应的底层数据结构即为字典数据结构。而针对拟态化的数据对象的框架设计，可以复用该字段。根据前文所描述的，拟态化数据对象的类型可以固定为REDIS_SAFEHASH，编码格式也可以固定为safehashtable这一种编码格式，对应的底层数据结构为步骤S1当中设计的拟态字典safeDict数据结构。因而encoding字段可以用于标记/控制是否对拟态字典safeDict进行拟态化存储。该标记/控制位决定了拟态数据对象当中的拟态数据结构是被保存了一份还是多份。
参考图7，Redis的拟态哈希对象指向底层数据结构的指针为ptr，该指针可以按照步骤S11当中类似的方式进行扩展，由一个ptr扩展为prtA、ptrB和ptrC。也可以保持该结构体框架不变，让ptr指针指向另一个数据结构safeDictEntry，该数据结构当中包含三个指针，分别指向同构或异构存储的safeDictA、safeDictB、safeDictC。此处尽量采用后一种方式，原因在于Redis当中数据对象与其他模块的耦合度较高，并且数据对象的接口实现较为复杂，与原生框架上保持一致，可以避免很多bug的产生。
Redis源代码当中，对于数据对象的接口包含了各种对象类型的增删改查接口及其相关的业务逻辑接口，而我们只针对哈希对象进行拟态化改造，对外接口也只需要保留一种类 型的增删改查接口即可，大大减小开发和维护工作量。
步骤S22，设计拟态数据结构管理模块，用于管理存储在拟态化数据对象当中的拟态化数据结构。
针对拟态数据对象当中拟态数据结构的存储，可以参考步骤S12当中拟态数据结构对数据的存储，根据硬件异构的支持情况，选择采用同构或异构的方式。
以Redis的拟态哈希对象的实现为例，与步骤S12当中描述的拟态字典数据结构针对数据的存储不同的是，参考图7，拟态哈希对象当中对于拟态字典数据结构的存储可以是拟态化的——即存储三个，也可以是非拟态化的——即只存储一个，因而拟态数据结构管理模块需要根据拟态哈希对象结构体当中的encoding字段决定是采用普通存储还是拟态存储。
拟态字典数据结构管理模块可以定义为一个结构体，该结构体的实例化即为一个拟态字典数据数据管理器。当创建一个拟态哈希对象时，可以同步创建一个关联的拟态字典数据结构管理器，根据拟态哈希对象当中encoding的标志，在管理器当中注册不同的管理函数，这样拟态哈希对象当中针对数据结构管理相关的操作，可以直接调用管理器当中的标准化命名的接口，而不必每次进行数据管理时都判断一下encoding类型。由此，可以实现面向对象当中的多态特征。
步骤S3，设计拟态化的数据库，所述数据库实现对拟态化数据对象的整合、管理和存储；所述对拟态化数据对象的存储表现为普通存储和拟态存储之间二选一。具体的，包含以下子步骤：
步骤S31，设计拟态化数据库总体框架，所述总体框架当中包含拟态化的健值空间和非拟态化的健值空间。
具体的，参考图8。Redis的源码当中数据库的结构体当中只有一个作为健值空间的哈希表，二拟态化的数据库框架当中，增加一个步骤S1当中设计的拟态哈希表作为拟态健值空间进行管理。当有新的键值对需要存储时，根据用户的指令选择是放入到普通健值空间当中还是拟态健值空间当中，二者选其一。
步骤S32，设计拟态数据对象管理模块，用于管理拟态化健值空间当中的键值对象。
原生Redis当中，数据库对于健值空间当中的数据对象的管理，是通过直接调用数据对象模块的接口来进行的。而改造后的Redis，数据库当中包含了拟态健值空间和普通健值空间，因而需要额外设计一个拟态数据对象管理模块，实例化后成为一个拟态数据对象管理器，管理器当中根据关联的健值空间注册普通数据对象管理接口或拟态数据对象管理接口，从而避免在每次调用时都需要检测健值空间的类型。类似于步骤S22当中的拟态数据结构管 理器，可以实现面向对象的多态特性。
拟态化的数据库独立于非拟态化的数据库存于服务器当中。在Redis源码的redisServer结构体当中有一项redisDb项，该项当中保存的是原生数据信息。本实施例在Redis源码当中增加一项redisSafeDb项，即拟态化数据库项，从而避免跟原生数据库相关数据及其业务逻辑产生冲突，尽可能解耦从而减小开发和维护的难度。
步骤S4，设计同步和裁决机制，所述同步机制用于将同构或异构的数据库、数据对象或数据结构当中的内容进行统一；所述的裁决机制用于在同构或异构的数据库当中选择合适的数据对象、在同构或异构的数据对象中选择合适的数据结构、在同构或异构的数据结构中选择合适的数据。
拟态同步和裁决机制有多种实现方式，此处由于Redis与SONiC的紧耦合，以及SONiC针对数据库的性能需求，采用较为简单的一种同步和裁决机制。
具体的，此处的裁决采用简单的择多裁决策略，即每次裁决池当中的数据有三个(A、B、C)，当三个数据都相同时(A＝B＝C)，那么最终返回任意数据(A或B或C)；当三个数据中有两个相同时(A＝B≠C)，那么少数服从多数，从相同的数据中任意返回结果(A或B)；若三个数据都不相同，那么判定该数据遭到严重破坏，返回一个错误信号。
同步机制就是保持裁决池当中数据一致性的过程，同步机制在以下三种情形当中发挥作用：
S41，被拟态保护的数据发生修改。
此处指的是用户主动修改，例如更新已有键对应的值，此时要进行同步，将所有同构或异构存储的数据都进行同步更新。
S42，裁决发现数据不统一。
也就是上述当中A＝B≠C的情形。一般情况下，这说明被拟态保护的数据发生了被动修改，极有可能是遭受到了外部的攻击。此时，也要调动同步机制，将同构或异构的数据进行统一，将数据C恢复到A＝B＝C的状态。
S43，时间周期性触发。
可以将同步动作作为一个时间事件进行周期性触发。遍历各个键值对，针对拟态改造的数据先裁决，发现数据不同一则调用步骤S42当中描述的同步机制。
需要注意的是，此处的遍历过程可能造成阻塞，因而可以分步进行同步，即一次时间周期到达后只同步一部分数据，并记录同步进度，最后分几次时间周期完成所有数据的同步，防止一次性阻塞过久导致其他业务逻辑出现问题。
步骤S5，设计拟态数据库安全存储指令处理系统，所述处理系统包含安全存储指令列表，安全存储指令分发器和安全存储指令处理器。
具体的，所述安全存储指令列表包含了安全等级特征，相同的安全存储指令可以有不同的安全等级。所述安全存储指令处理器根据安全等级来规划组织层次结构。
原生的Redis代码当中，所有的指令都是redisCommand结构体的实例，并在redisCommandTable当中进行管理。安全存储相关的指令可以复用redisCommand结构体，并在redisCommandTable当中扩展。通过这种方式，可以兼容Redis当中客户端和服务器之间的指令传输和执行的过程。
拟态Redis的安全存储指令可以参考原生Redis当中的哈希类型相关的命令，分别有HSET、HGET、HMSET、HMGET、HGETALL、HKEYS、HVALS、HLEN等。此处并不一定要将上述所有指令全部实现，可以根据实际SONiC当中的应用情况，选择一部分实现即可。例如可以只实现HSET、HGET、HMSET和HMGET四个指令，并且重新命名为SHSET、SHGET、SHMSET、SHMGET。
相对于原生的哈希类型相关指令，拟态Redis的安全存储的写指令(SHSET、SHMSET)需要增加安全等级特征。根据前述的实现方案，安全等级可以分为低、中、高三级。具体的，参考图9，Redis数据库包含服务器、数据库、数据对象、数据结构和数据五个层级，低安全等级对应的是只在数据结构层级针对数据进行拟态化存储，即：1、在服务器的数据库当中，选择普通字典结构的健值空间创建键值对；2、在普通健值空间的键值对中，键为普通的字符串对象，值为普通存储的安全哈希对象，也就是redisObject中的ptr指针只指向一份数据；3、在安全哈希对象当中，通过拟态化的安全字典数据结构，将数据拟态化存储。
中安全等级是在数据对象和数据结构两个层级进行拟态化存储，即：1、在服务器的数据库当中，选择普通字典结构的健值空间创建键值对；2、在普通健值空间的键值对中，键为普通的字符串对象，值为拟态存储的安全哈希对象，也就是redisObject中的ptr指针指向三份数据；3、在每一份安全哈希对象当中，都通过拟态化的安全字典数据结构，将数据拟态化存储。
高安全等级对应的是所有节点均采用拟态化存储，即：1、在服务器的数据库当中，选择拟态安全字典结构的健值空间创建键值对；2、在拟态安全健值空间的键值对中，键为备份了三个的字符串对象，值为拟态存储的安全哈希对象，也就是redisObject中的ptr指针指向三份数据；3、在每一份安全哈希对象当中，都通过拟态化的安全字典数据结构，将数 据拟态化存储。
由于在进行拟态化改造后，同构或异构存储的数据需要裁决、同步等过程，势必影响服务器的性能，越高安全等级影响越大。通过纵向的安全分级，可以在网络操作系统层面根据自身的实际应用，对读取速率要求高的场景下采用低安全等级(甚至用原生Redis机制来存取)，对数据安全要求高的场景下采用高安全等级，牺牲一定的服务器存取性能，换取更高的安全性能。
步骤S6，设计网络操作系统当中业务模块与数据库交互数据的分类存储机制。
具体的，可以分为以下几种类型：
S61，无安全性要求数据、高耦合性数据采用原始数据库存储指令或接口。
S62，低耦合性数据中，按照安全性需求和存取速率需求，选择不同安全等级的存取方式。
以基于Redis的SONiC系统为例，系统当中有多个处理业务逻辑的容器同时运行，Redis服务器也作为一个单独的容器并行运行。典型的低存取速率、高安全性需求的数据为用户输入的各个业务逻辑的配置信息，这些信息通过Redis数据库容器作为中间环节，转发到各个目的容器当中。典型的高存取速率、低安全性需求的数据为设备运行的日志信息，可以采用低等级甚至无安全性要求的存取指令。
以上所述的一种基于拟态数据库的网络操作系统设计方法的具体实施例，通过纵向分级和横向分类的方式，最大可能性得将数据库拟态化改造的部分与原业务逻辑之间实现松耦合，从而最大程度上避免由于数据库的改动导致的正常业务逻辑无法运行的情况，极大降低开发和维护成本。同时，即使没有硬件异构存储的支持，通过软件同构随机地址的分发存储、裁决读取以及同步机制，也能够有效实现拟态防御的目标，并且能够最大程度上节省设备硬件成本，避免多CPU等硬件架构导致的高成本特征，有利于提高运行了该操作系统的网络设备的市场价值。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换或改进等，均应包含在本发明的保护范围之内。

Claims (9)

  1. 一种基于拟态数据库的网络操作系统设计方法，其特征在于，具体如下步骤：
    S1、设计拟态化的数据结构，所述数据结构实现对数据的拟态同构存储或拟态异构存储；
    S2、设计拟态化的数据对象，所述数据对象实现对数据结构的组织和存储；所述对数据结构的存储表现为普通存储或拟态存储两者中的一种；
    S3、设计拟态化的数据库，所述数据库实现对数据对象的整合、管理和存储；所述对数据对象的存储表现为普通存储或拟态存储两者中的一种；
    S4、设计同步机制和裁决机制，所述同步机制用于将同构或异构的数据库、数据对象或数据结构当中的内容进行统一；所述的裁决机制用于在同构或异构的数据库当中选择合适的数据对象、在同构或异构的数据对象中选择合适的数据结构、在同构或异构的数据结构中选择合适的数据；
    S5、设计拟态数据库安全存储指令的处理系统，所述处理系统包含安全存储指令列表，安全存储指令分发器和安全存储指令处理器；
    S6、设计网络操作系统中业务模块与总数据库交互数据的分类存储机制。
  2. 如权利要求1所述的一种基于拟态数据库的网络操作系统设计方法，其特征在于，所述步骤S1具体包括以下子步骤：
    S11、设计拟态化的数据结构的总体框架和对外接口；所述总体框架包含拟态化数据项；所述对外接口包括但不限于创建、增加、删除、修改、获取数据和获取状态；
    S12、设计拟态存储管理模块，所述拟态存储管理模块包括同构存储管理和异构存储管理；所述同构存储管理采用随机性内存分配策略；所述异构存储管理需要硬件异构的支持；
    S13、设计拟态存储检测模块，用于跨平台移植后检测拟态存储管理模块接口是否满足功能和性能要求，若不符合要求则自动屏蔽相关的拟态存储功能。
  3. 如权利要求2所述的一种基于拟态数据库的网络操作系统设计方法，其特征在于，步骤与S13所述的检测机制包括下述方法中的一种：
    S131、系统上电初始化阶段进行阻塞式检测，检测通过后再执行后续业务逻辑；
    S132、系统上电后进行时间周期性检测，将所有检测内容分成几个部分，每个时间周期到达后检测其中一个部分；检测过程中对有效数据进行备份，在任意检测节点出现检测失败，则屏蔽硬件异构功能，将备份的数据转换为拟态同构存储；
    S133、系统上电后进行单步检测，在每个拟态数据存取处理的过程当中，先对即将调用的拟态存储管理模块的接口进行检测；检测过程中对有效数据进行备份，在任意检测节点出现检测失败，则屏蔽硬件异构功能，将备份的数据转换为拟态同构存储；检测通过后记录检测结 果。
  4. 如权利要求1所述的一种基于拟态数据库的网络操作系统设计方法，其特征在于，所述步骤S2具体包括以下子步骤：
    S21、设计拟态化的数据对象的总体框架和对外接口；所述总体框架中包括数据结构项和对数据结构进行普通存储或拟态存储的选择/标志项；所述对外接口包括但不限于创建、增加、删除、修改；
    S22、设计拟态数据结构管理模块，用于管理存储在拟态化的数据对象中的数据结构。
  5. 如权利要求1所述的一种基于拟态数据库的网络操作系统设计方法，其特征在于，所述步骤S3具体包含以下子步骤：
    S31、设计拟态化的数据库的总体框架，所述总体框架中包含拟态化的健值空间和非拟态化的健值空间；
    S32、设计拟态数据对象管理模块，用于管理拟态化的健值空间中的键值对象。
  6. 如权利要求1所述的一种基于拟态数据库的网络操作系统设计方法，其特征在于，所述步骤S4中的同步机制在以下几种情形当中被执行：
    S41、被拟态保护的数据发生修改；
    S42、裁决发现数据不统一；
    S43、时间周期性触发。
  7. 如权利要求1所述的一种基于拟态数据库的网络操作系统设计方法，其特征在于，所述步骤S5中的安全存储指令列表中包括安全等级特征。
  8. 如权利要求1所述的一种基于拟态数据库的网络操作系统设计方法，其特征在于，所述步骤S5中的安全存储指令处理器根据安全等级来规划组织层次结构；。
  9. 如权利要求1所述的一种基于拟态数据库的网络操作系统设计方法，其特征在于，所述步骤S6中的分类存储机制具体操作如下：
    S61、对于无安全性要求数据、高耦合性数据采用原始数据库存储指令或接口；
    S62、对于低耦合性数据，按照安全性需求和存取速率需求，选择不同安全等级的存取方式。
PCT/CN2022/084973 2021-11-26 2022-04-02 一种基于拟态数据库的网络操作系统设计方法 WO2023082537A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/824,349 US11934383B2 (en) 2021-11-26 2022-05-25 Mimetic database-based network operating system design method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111416379.0 2021-11-26
CN202111416379.0A CN113835685B (zh) 2021-11-26 2021-11-26 一种基于拟态数据库的网络操作系统设计方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/824,349 Continuation US11934383B2 (en) 2021-11-26 2022-05-25 Mimetic database-based network operating system design method

Publications (1)

Publication Number Publication Date
WO2023082537A1 true WO2023082537A1 (zh) 2023-05-19

Family

ID=78971462

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/084973 WO2023082537A1 (zh) 2021-11-26 2022-04-02 一种基于拟态数据库的网络操作系统设计方法

Country Status (3)

Country Link
US (1) US11934383B2 (zh)
CN (1) CN113835685B (zh)
WO (1) WO2023082537A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113835685B (zh) 2021-11-26 2022-02-18 之江实验室 一种基于拟态数据库的网络操作系统设计方法
CN114398683B (zh) * 2022-03-24 2022-06-10 之江实验室 一种基于异构子系统的内生安全数据库存储方法及装置
CN114500114B (zh) * 2022-04-14 2022-07-12 之江实验室 一种网络操作系统中应用的拟态数据库交互方法和装置
CN114780569B (zh) * 2022-06-22 2022-09-16 之江实验室 一种拟态redis数据库的输入输出代理方法和装置
CN115001852B (zh) * 2022-07-18 2022-11-08 之江实验室 一种网络操作系统中应用内生安全数据库存取方法和装置
CN116150280B (zh) * 2023-04-04 2023-07-04 之江实验室 一种拟态redis数据库同步方法、系统、设备和存储介质
CN117573293B (zh) * 2024-01-16 2024-04-12 北京卓翼智能科技有限公司 一种基于Redis的大规模仿真系统数据记录方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10346374B1 (en) * 2014-03-14 2019-07-09 Open Invention Network Llc Optimized data migration application for database compliant data extraction, loading and transformation
CN111031096A (zh) * 2019-11-15 2020-04-17 华东计算技术研究所（中国电子科技集团公司第三十二研究所） 一种基于拟态防御的分布式存储系统构建方法
CN111314214A (zh) * 2020-05-11 2020-06-19 之江实验室 一种拟态工业边缘网关及拟态处理方法
CN112383528A (zh) * 2020-11-09 2021-02-19 浙江大学 一种拟态waf的执行体构建方法
CN113505006A (zh) * 2021-07-08 2021-10-15 上海红阵信息科技有限公司 一种面向拟态数据库的裁决装置及方法
CN113835685A (zh) * 2021-11-26 2021-12-24 之江实验室 一种基于拟态数据库的网络操作系统设计方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7206805B1 (en) * 1999-09-09 2007-04-17 Oracle International Corporation Asynchronous transcription object management system
US7657581B2 (en) * 2004-07-29 2010-02-02 Archivas, Inc. Metadata management for fixed content distributed data storage
US8244913B1 (en) * 2004-10-13 2012-08-14 Progress Software Corporation Replication horizon determination with an independent distributed database system
US7694181B2 (en) * 2005-12-12 2010-04-06 Archivas, Inc. Automated software testing framework
CN102004745B (zh) * 2009-09-02 2013-06-12 中国银联股份有限公司 数据转移系统及方法
US11741380B2 (en) * 2020-01-31 2023-08-29 Oracle International Corporation Machine learning predictions for database migrations
CN111562972A (zh) * 2020-04-24 2020-08-21 西北工业大学 一种面向群智感知的泛在操作系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10346374B1 (en) * 2014-03-14 2019-07-09 Open Invention Network Llc Optimized data migration application for database compliant data extraction, loading and transformation
CN111031096A (zh) * 2019-11-15 2020-04-17 华东计算技术研究所（中国电子科技集团公司第三十二研究所） 一种基于拟态防御的分布式存储系统构建方法
CN111314214A (zh) * 2020-05-11 2020-06-19 之江实验室 一种拟态工业边缘网关及拟态处理方法
CN112383528A (zh) * 2020-11-09 2021-02-19 浙江大学 一种拟态waf的执行体构建方法
CN113505006A (zh) * 2021-07-08 2021-10-15 上海红阵信息科技有限公司 一种面向拟态数据库的裁决装置及方法
CN113835685A (zh) * 2021-11-26 2021-12-24 之江实验室 一种基于拟态数据库的网络操作系统设计方法

Also Published As

Publication number Publication date
US20230169063A1 (en) 2023-06-01
US11934383B2 (en) 2024-03-19
CN113835685A (zh) 2021-12-24
CN113835685B (zh) 2022-02-18

Similar Documents

Publication Publication Date Title
WO2023082537A1 (zh) 一种基于拟态数据库的网络操作系统设计方法
US11176140B2 (en) Updating a table using incremental and batch updates
US9251011B2 (en) Backup of in-memory databases
US10657154B1 (en) Providing access to data within a migrating data partition
US9632944B2 (en) Enhanced transactional cache
CN105159818A (zh) 内存数据管理中日志恢复方法及其仿真系统
US11599514B1 (en) Transactional version sets
US20210182266A1 (en) System and method for use of lock-less techniques with a multidimensional database
US20230401241A1 (en) System for lightweight objects
CN110955655B (zh) 动态cmdb数据库模型存储方法和系统
CN107977446A (zh) 一种基于数据分区的内存网格数据加载方法
US20220269615A1 (en) Cache-based trace logging using tags in system memory
US8898124B2 (en) Controlling database trigger execution with trigger return data
CN106202459A (zh) 虚拟化环境下的关系型数据库存储性能优化方法及系统
US11709809B1 (en) Tree-based approach for transactionally consistent version sets
US9009731B2 (en) Conversion of lightweight object to a heavyweight object
US7987470B1 (en) Converting heavyweight objects to lightwight objects
US11657046B1 (en) Performant dropping of snapshots by converter branch pruning
US20230195747A1 (en) Performant dropping of snapshots by linking converter streams
US11687453B2 (en) Cache-based trace logging using tags in an upper-level cache
US11561896B2 (en) Cache-based trace logging using tags in an upper-level cache
US11886422B1 (en) Transactional protocol for snapshot isolation without synchronized clocks
McNamee Virtual memory alternatives for transaction buffer management in a single-level store
Nuhić et al. AbacusFS integrated storage and computational platform
Lersch A lock-free buffer for WattDB

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22891349

Country of ref document: EP

Kind code of ref document: A1