LEO CDN x FReD
The replication of files within the CDN will heavily rely on FReD, a "distributed middleware for Fog Replicated Data".
FReD several key abstractions, notably Nodes, Keygroups and Keygroup members.
This document will discuss how these abstractions correspond the components of our CDN using LEO satellites.
Nodes are a group of one or more machines within one geographical site including a hosted or embedded storage system (from Fog Computing - 03 Data Management, page 65)
Nodes are interact in the network and replicate data items (stored in keygroups). In our case nodes most likely correspond to satellites.
A keygroup is a group of data items that are replicated together (from Fog Computing - 03 Data Management, page 66)
Keygroups comprise data items that "belong together" (an example from the lecture: "The mails in Jonathan's email inbox").
Keygroups also have their own ACL (Access Control List).
We still have to discuss what would be an appropriate approach to group files in keygroups. One possible way, for example, would be to define keygroups at a level of "files that should be available on satellites above Germany" (or some more/less granular geolocation). This abstraction could help achieving geostationarity on a country level.
The application can "declaratively specify the set of keygroup members" meaning it can dynamically (also at runtime) add and remove nodes as members from a specific keygroup. Each keygroup is automatically replicated at each keygroup member via pub/sub. When removing a node as a keygroup member the corresponding keygroup is deleted by FReD from the node.
All previous references to "keygroups members" actually referred to a specific type of keygroup members: Replica nodes. There are actually two types of keygroup members:
- Replica nodes: "store a data replica serve client requests, and manage keygroup configurations"
- Trigger nodes: "receive all updates as a stream of events and may trigger external systems via an event-based interface"
Replica nodes, as already discussed, are the "usual kind of node" that enables interaction with the data (i.e. keygroups + members).
Trigger nodes on the other hand only listen to updates and can trigger changes in case they detect some event/condition.
For our case, one possible way to define keygroup members would be: "all satellites that are currently roughly above Germany". This way, we could simply assign satellites to key groups based on their current position and data would automatically be replicated in a geostationary fashion.
A smart home system collects and stores data in a keygroup that comprises several nodes. On some event (e.g. sensors detect very bright sun), the trigger node executes e.g. some script to close the blinds.
Additionally, on the intermediary node, a trigger node is responsible for triggering an aggregator (on some arbitrary event) that stores its result in a second keygroup that is replicated in the cloud.
- How granular should the keygroups be?
- Is there a better way of grouping files in keygroups?
- How do ground stations fit into all of this? Are they part of keygroups or are they just clients that interaction with the keygroups via the FReD gRPC interface?
- How do we and who assigns the satellites to keygroups? Are they assigning each other?