projects / mirror_ovs.git / blame
| Commit | Line | Data |
|---|---|---|
| fe36184b BP |
1 | * ovn-controller |
| 2 | ||
| fe36184b BP |
3 | ** ovn-controller parameters and configuration. |
| 4 | ||
| fe36184b BP |
5 | *** SSL configuration. |
| 6 | ||
| 7 | Can probably get this from Open_vSwitch database. | |
| 8 | ||
| fe36184b BP |
9 | * ovsdb-server |
| 10 | ||
| 11 | ovsdb-server should have adequate features for OVN but it probably | |
| 12 | needs work for scale and possibly for availability as deployments | |
| 13 | grow. Here are some thoughts. | |
| 14 | ||
| 15 | Andy Zhou is looking at these issues. | |
| 16 | ||
| fe36184b BP |
17 | *** Reducing amount of data sent to clients. |
| 18 | ||
| 19 | Currently, whenever a row monitored by a client changes, | |
| 20 | ovsdb-server sends the client every monitored column in the row, | |
| 21 | even if only one column changes. It might be valuable to reduce | |
| 22 | this only to the columns that changes. | |
| 23 | ||
| 24 | Also, whenever a column changes, ovsdb-server sends the entire | |
| 25 | contents of the column. It might be valuable, for columns that | |
| 26 | are sets or maps, to send only added or removed values or | |
| 27 | key-values pairs. | |
| 28 | ||
| 29 | Currently, clients monitor the entire contents of a table. It | |
| 30 | might make sense to allow clients to monitor only rows that | |
| 31 | satisfy specific criteria, e.g. to allow an ovn-controller to | |
| 48605550 | 32 | receive only Logical_Flow rows for logical networks on its hypervisor. |
| fe36184b BP |
33 | |
| 34 | *** Reducing redundant data and code within ovsdb-server. | |
| 35 | ||
| 36 | Currently, ovsdb-server separately composes database update | |
| 37 | information to send to each of its clients. This is fine for a | |
| 38 | small number of clients, but it wastes time and memory when | |
| 39 | hundreds of clients all want the same updates (as will be in the | |
| 40 | case in OVN). | |
| 41 | ||
| 42 | (This is somewhat opposed to the idea of letting a client monitor | |
| 43 | only some rows in a table, since that would increase the diversity | |
| 44 | among clients.) | |
| 45 | ||
| 46 | *** Multithreading. | |
| 47 | ||
| 48 | If it turns out that other changes don't let ovsdb-server scale | |
| 49 | adequately, we can multithread ovsdb-server. Initially one might | |
| 50 | only break protocol handling into separate threads, leaving the | |
| 51 | actual database work serialized through a lock. | |
| 52 | ||
| 53 | ** Increasing availability. | |
| 54 | ||
| 55 | Database availability might become an issue. The OVN system | |
| 56 | shouldn't grind to a halt if the database becomes unavailable, but | |
| 57 | it would become impossible to bring VIFs up or down, etc. | |
| 58 | ||
| 59 | My current thought on how to increase availability is to add | |
| 60 | clustering to ovsdb-server, probably via the Raft consensus | |
| 61 | algorithm. As an experiment, I wrote an implementation of Raft | |
| 62 | for Open vSwitch that you can clone from: | |
| 63 | ||
| 64 | https://github.com/blp/ovs-reviews.git raft | |
| 65 | ||
| 66 | ** Reducing startup time. | |
| 67 | ||
| 68 | As-is, if ovsdb-server restarts, every client will fetch a fresh | |
| 69 | copy of the part of the database that it cares about. With | |
| 70 | hundreds of clients, this could cause heavy CPU load on | |
| 71 | ovsdb-server and use excessive network bandwidth. It would be | |
| 72 | better to allow incremental updates even across connection loss. | |
| 73 | One way might be to use "Difference Digests" as described in | |
| 74 | Epstein et al., "What's the Difference? Efficient Set | |
| 75 | Reconciliation Without Prior Context". (I'm not yet aware of | |
| 76 | previous non-academic use of this technique.) |