d958d8e82c
This functionallity seems to get via AMQP (after some authentication) a private (wihtout need of authentication) url to an artifact assigned to the controller. By default, DDI or DMF shall provide proper urls (for direct download) to devices and if they have to be without authentication this shall be solved in different ways - for instance separate download server providing dedicated private / signed urls. This functinallity is not a real hawkBit part but more like something intended to solve some edge cases. Since it is complicated, heeds support, doesn't solve wide spread use cases, and could be achieved with other means - better to be removed. Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
2.8 KiB
title, parent, weight
| title | parent | weight |
|---|---|---|
| Clustering | Guides | 33 |
hawkBit is able to run in a cluster with some constraints. This guide provides insights in the basic concepts and how to setup your own cluster. You can find additional information in the hawkBit runtimes's README.
Big picture
Events
Event communication between nodes is based on Spring Cloud Bus and Spring Cloud Stream. There are different binder implementations available. The hawkbit Update Server uses RabbitMQ binder. Every node gets his own queue to receive cluster events, the default payload is JSON. If an event is thrown locally at one node, it will be automatically delivered to all other available nodes via the Spring Cloud Bus's topic exchange:
Via the ServiceMatcher you can check whether an event happened locally at one node or on a different node.
serviceMatcher.isFromSelf(event)
Caching
Every node is maintaining its own caches independent from other nodes. So there is no globally shared/synchronized cache instance within the cluster. In order to keep nodes in sync a TTL (time to live) can be set for all caches to ensure that after some time the cache is refreshed from the database. To enable the TTL just set the property "hawkbit.cache.global.ttl" (value in milliseconds). Of course you can implement a shared cache, e.g. Redis. See CacheAutoConfiguration
Schedulers
Every node has multiple schedulers which run after a defined period of time. All schedulers always run on every node. This has to be kept in mind e.g. if the scheduler executes critical code which has to be executed only once.
Known constraints
Denial-of-Service (DoS) filter
hawkBit owns the feature of guarding itself from DoS attacks, a DoS filter. It reduces the maximum number of requests per seconds which can be configured for read and write requests. This mechanism is only working for every node separately, i.e. in a cluster environment the worst-case behaviour would be that the maximum number of requests per seconds will be increased to its product if every request is handled by a different node. The same constraint exists with the validator to check if a user tried too many logins within a defined period of time.