Changes between Version 2 and Version 3 of SuperHost
- Timestamp:
- Sep 24, 2007, 8:55:03 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SuperHost
v2 v3 5 5 The superhost idea has been proposed numerous times, but has not yet been implemented. This document discusses concrete design ideas. 6 6 7 == Problem == 7 == Problem == #problem 8 8 Large organisations wishing to run BOINC often don't want to open up their entire network to BOINC project servers, or allow unmanaged BOINC clients running on the network, potentially attached to unauthorised projects. 9 9 10 == Solution == 10 == Solution == #solution 11 11 Promote one of the hosts to "superhost". All other hosts will only communicate with the superhost, and only the superhost requires Internet access. 12 12 13 == Additional Benefits == 13 == Additional Benefits == #additional-benefits 14 14 * Internet traffic is reduced, since the superhost can communicate more efficiently with the project servers, and only needs to download a single copy of any file. 15 15 * Hosts can be controlled more tightly, since the superhost will have more information than is normally available to project schedulers. 16 16 * The superhost can manage a single work queue, improving turn around times. 17 17 * Normal work unit copy rules can be ignored, allowing a single work unit download to be run on multiple computers within the cluster. (See "security" below.) 18 * Validation can be delegated to the superhost, reducing uploads and server load. (See "security" below.)18 * Validation can be delegated to the superhost, reducing uploads and server load. (See [#security security section].) 19 19 * A company can run internal BOINC projects, and fall back on an external project if no work is available from the internal projects. 20 20 21 == Topology == 21 == Topology == #topology 22 22 [[Image(superhost.png)]] 23 23 24 == Security == 24 == Security == #security 25 25 For an untrusted cluster, the project must treat the superhost exactly the same as a single host. However, if there is a trust relationship between the project and the superhost, then the superhost can be treated as the sum of its hosts, with the capability to manage work unit redundancy on the project's behalf. Validation offers some technical challenges, but simple bitwise validation using homogeneous redundancy can be achieved easily. 26 26 27 == Implementation == 27 == Implementation == #implementation 28 28 This design requires major server and client changes, in addition to the superhost application. A simplified design could start by treating the superhost as a project from the point of view of the clients, and as a client from the point of view of the projects.
