Centralized Database Versioning for In-Service Software Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional in-service software upgrade (ISSU) models require multiple service copies and different data models, leading to cumbersome and error-prone user experiences, as they often necessitate shutting down services or reading complex release notes to manage versioning and API call ordering.
Innovation Solution
A centralized database system is implemented, allowing bidirectional connections to a state database for seamless migration of state and configuration information from an origin to a target state, enabling software upgrades without impacting services by detaching the control plane from the data plane and using a schema migration proxy to translate and migrate data.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional ISSU models use multiple service copies and different data models, then software version upgrading is enabled, but device complexity and operational difficulty increase
Solution Approach 1:
The patent merges multiple service copies and different data models into a single unified database instance that supports versioning. Instead of maintaining separate database copies for different software versions, the system uses one database that can serve multiple versions simultaneously through versioning mechanisms, thereby reducing system complexity while enabling software upgrading.
Solution Approach 2:
The unified database is designed to be universal, serving multiple software versions and services simultaneously. The database instance can handle queries from different software versions through versioned schemas and migration proxies, eliminating the need for version-specific database copies and reducing overall system complexity.
2Ease of manufacture
If traditional ISSU models require service shutdowns, then database schema migration is simplified, but service continuity is interrupted
Solution Approach 1:
The system performs preliminary actions by establishing migration proxies and versioning mechanisms before actual schema changes are needed. The unified database is pre-configured to handle multiple versions, allowing migrations to occur incrementally without service interruption. The migration proxy is set up in advance to translate queries between old and new schemas.
Solution Approach 2:
The migration proxy acts as an intermediary between the unified database and software services during schema migration. It translates queries from services using old schemas to the new schema format, enabling seamless migration without service shutdowns. The proxy mediates all database interactions during the transition period, maintaining service continuity while enabling schema evolution.
3Reliability
If traditional ISSU models use versioned connections for each service-database interaction, then API compatibility is maintained, but operational complexity increases
Solution Approach 1:
The unified database provides a universal connection interface that serves all services regardless of their software version. Instead of requiring each service to have versioned connections, the single database instance handles all connections through its versioning capability and migration proxy, greatly simplifying operations while maintaining API compatibility through schema translation.
Solution Approach 2:
The migration proxy serves as an intermediary that handles version compatibility transparently. It receives queries from services running on any version and translates them to the appropriate schema format, eliminating the need for services to manage versioned connections themselves. This mediates the complexity of API compatibility while maintaining simplicity for end users.
Data Source
AI summary
Systems and methods are provided for in-service software upgrades using centralize database versioning and migrations. The systems and methods described herein can intercept protocol messages between a client and a network device and run a first control plane comprising an origin state database and a plurality of un-migrated services. The system can generate a target state data model, wherein an origin state data model associated with the origin state database migrates to the target state data model, and copy the origin state database. The system can migrate second control plane software to the target state database and operate un-migrated services in accordance with the first control plane software and the copied origin state database while operating migrated services in accordance with the second control plane software and the target state database.