search

atlanticwave-sdx / kytos-sdx

MIT License
0 stars 3 forks source link

Database (design review) #49

Closed YufengXin closed 1 month ago

YufengXin commented 6 months ago

There are currently N+2 Mongo DB instances needed for N OXP sites. Then there is internal DB in the NAPP and appeared to have a separate suit of endpoints.

Design review would be healthy to ask:

(1) Why the 2 extra mongo DB are needed? How they are deployed and used in a distributed environment? (2) Is the extra DB layer inside the NAPP necessary?

lmarinve commented 6 months ago

Why are the two extra MongoDB instances needed? How do we deploy and use these in a distributed environment?

The N+2 MongoDB instances are part of the Kytos specification and are essential for each kytos OXPO node. These instances ensure redundancy and high availability, which are crucial in a distributed environment. Specifically, the extra MongoDB instances help manage failover scenarios, ensuring the system can maintain its operations without significant disruptions if one or more instances fail.

Deployment: We simulate deploying these MongoDB instances within each OXPO node to establish a local cluster unique to Kytos. This setup ensures that each node operates independently of the others while maintaining high availability and fault tolerance within the node.

Usage: The extra instances replicate data within the node, ensuring consistency and reliability. Other OXPO implementations, such as OESS, may have different requirements and architectures, making this approach unnecessary for Kytos.

Is the extra DB layer inside the NAPP necessary?

The Kytos specification sets it apart from other OXP sites by including an additional database layer inside the NAPP (Network Application). This unique feature serves simulation purposes within the Kytos environment, enhancing its functionality and value. It's important to note that this feature is not a necessity for other OXP sites, as each will have its own database environment.

The internal DB in the NAPP is not just an extra layer. It provides a local data store for the application’s internal operations and simulations, offering a controlled environment for testing and validation. This setup empowers developers to confidently test and validate the NAPP's functionality before deploying it to the actual OXP sites, ensuring a smooth and error-free transition.

Implementation: While this internal DB layer is helpful for development and testing, in a production environment, each OXP site would manage its database independently. This separation ensures that one site's operations do not impact others, preserving the integrity and autonomy of each OXP site.

Solution: A new OXPO wrapper repository, oxpo-api-wrapper, is currently being developed. We designed this wrapper to abstract the conversion and validation code from the specific Kytos specifications. The oxpo-api-wrapper aims to simplify interactions with various OXPO APIs by providing a unified and simplified programming interface. By abstracting the complexities of direct API calls, the wrapper offers a consistent method to interact with different OXPO services, enhancing code readability and maintainability. We will be taking care of the new issues on this repository from the oxpo-api-wrapper repository

italovalcy commented 5 months ago

There are currently N+2 Mongo DB instances needed for N OXP sites. Then there is internal DB in the NAPP and appeared to have a separate suit of endpoints.

Design review would be healthy to ask:

(1) Why the 2 extra mongo DB are needed? How they are deployed and used in a distributed environment? (2) Is the extra DB layer inside the NAPP necessary?

Hi Yufeng, I will work on the 2nd problem you reported to make the Napp write directly to Mongo, removing this extra layer. If I recall correctly, this was created to facilitate the development by the time (the developer was not comfortable with the MongoDB direct access)

italovalcy commented 1 month ago

Hi,

This issue was already fixed and I will proceed with the it close. In summary:

1) for the DB design, yes the idea is to use MongoDB as the database and both options are fine for development environment: single instance or multiple instances. On the other hand, for production the recommendation from Mongo is to have the distributed setup with replica set: https://www.mongodb.com/resources/products/capabilities/performance-best-practices#replication-and-sharding Thus, in order to validate its configuration when we decided to move to production, we are using distributed setup. Thanks to this decision, we already got problems on the SDX-Controller that was fixed before moving into prod.

2) for the extra layer of DB on the Kytos SDX Napp, this was removed a few commits back. The shelve extra layer implementation was fully removed from Kytos SDX Napp and we are now leveraging MongoDB storage backend directly.