Cluster Feature Code Generation for OpenStack Node Changes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In large-scale OpenStack deployments, changes to physical nodes, such as storage expansion, configuration changes, or fault replacements, lead to changes in the cluster feature code, causing software authorization failures, and existing methods either require manual planning of control nodes or result in significant changes to the system when the number of control nodes changes.
Innovation Solution
A method using consistent hashing to determine key nodes within a cluster, obtaining plaintext feature codes, encrypting them with a first-level public key, calculating a check code using a digest algorithm, and then using a second-level public key to derive the cluster feature code, reducing the impact of node changes on the system.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If manual planning of control nodes is used to generate cluster feature codes, then authorization security is maintained, but system complexity increases and adaptability to node changes deteriorates
Solution Approach 1:
The system automatically selects control nodes and generates feature codes through consistent hashing algorithms without requiring manual intervention. The cluster members self-organize into control nodes based on their identifiers, enabling automatic adaptation to node changes while maintaining authorization security
Solution Approach 2:
The system changes the parameter of control node selection from fixed manual assignment to dynamic algorithmic selection based on cluster member identifiers. This allows the control node set to automatically adapt when cluster members change, reducing system complexity while maintaining security
2Adaptability or versatility
If the number of control nodes changes, then system flexibility improves, but feature code stability deteriorates causing authorization failures
Solution Approach 1:
The system segments the cluster into multiple control nodes that independently contribute to the feature code. When control nodes change, only their individual contributions change while the overall feature code structure remains stable, allowing flexibility without authorization failures
Solution Approach 2:
Instead of changing the entire feature code when control nodes change, the system inverts the approach by having each control node contribute a segmented portion to the overall feature code. This allows individual control nodes to change while the aggregate feature code remains valid
3Ease of repair
If physical nodes are changed for storage expansion or fault replacement, then system maintainability improves, but cluster feature code changes causing authorization failures
Solution Approach 1:
The system changes the parameter of node identification from hardware-based to identifier-based consistent hashing. This allows physical nodes to be replaced or modified without changing their logical identifier's contribution to the feature code, maintaining authorization continuity while improving maintainability
Data Source
AI summary
A method for obtaining a cluster feature code includes: determining a plurality of key nodes from respective nodes in a cluster; obtaining plaintexts of feature codes of the respective key nodes; according to the plaintexts of the feature codes of the respective key nodes, obtaining ciphertexts of the feature codes of the respective key nodes, by utilizing a first-level public key; calculating a check code according to the ciphertexts of the feature codes of the respective key nodes; and according to the check code, obtaining the cluster feature code, by utilizing a second-level public key. By means of the present application, the scope of influence on the entire system when system nodes change is reduced.