On 5/5/21 11:40 PM, Ben Pfaff wrote:
> On Sat, May 01, 2021 at 02:55:41AM +0200, Ilya Maximets wrote:
>> Replication can be used to scale out read-only access to the database.
>> But there are clients that are not read-only, but read-mostly.
>> One of the main examples is ovn-controller that mostly monitors
>> updates from the Southbound DB, but needs to claim ports by sending
>> transactions that changes some database tables.
>>
>> Southbound database serves lots of connections: all connections
>> from ovn-controllers and some service connections from cloud
>> infrastructure, e.g. some OpenStack agents are monitoring updates.
>> At a high scale and with a big size of the database ovsdb-server
>> spends too much time processing monitor updates and it's required
>> to move this load somewhere else.  This patch-set aims to introduce
>> required functionality to scale out read-mostly connections by
>> replication.
>>
>> Replication mode natively supports replication of standalone and
>> clustered databases, so it will work for any type of OVN deployment.
> 
> I think that this series has the details that one needs to understand it
> at a high level, but I didn't see a high-level overview of its intended
> use.  I think the idea is that, for a use case like OVN, one would
> deploy a clustered OVS database, and then the second tier would be a
> collection of replicas on top of that cluster.  If that's the case, I
> think that adding a paragraph to an appropriate high-level documentation
> file for OVSDB explaining it would be helpful, and possibly a (ASCII
> art?) diagram.
> 

Yes.  That is the intended use case.   And I agree that current series
has only bare minimum of documentation.  I'll include the patch that
adds a new paragraph to Documentation/topics/ovsdb-replication.rst to
describe how to scale out read access (existing functionality that is
documented with a single sentence in ovsdb(7) "A set of replicas that do  
serve clients could be used to scale out read access to the primary
database.") and how to use the same schema for an OVN deployment with
transaction forwarding enabled (new features).  This could be done in
v2 or as a separate patch.

I have a following ASCII art for the deployment schema:


        +---------------------------------------------------------+
        | RAFT CLUSTER                                            |
        |           +---------+ ovsdb-server-1 +------+           |
        |           |             +                   |           |
        |           +             |                   +           |
        | +--+ovsdb-server-2 +----|----------+ ovsdb-server-3+--+ |
        | |                       |                             | |
        +-|-----------------------|-----------------------------|-+
          |                       |                             |
          |               +-------+------------+      +---------+
          +               |       +            |      |         +
  +- ovsdb-replica-1 -+   2  ovsdb-replica-3   4 ... N-1  ovsdb-replica-N
  |        |          |      |       |     |               |     |     |
  +        +          +                                                +
client-1 client-2 client-3      ....           ....          ....  client-M

For OVN setup: ovsdb-server-{1,2,3} - clustered Southbound DB
               ovsdb-replica-{1..N} - replication servers
               client-{1..M}        - ovn-controller's

This schema also reflects the fact that replica doesn't replicate the
cluster, but a particular server in a cluster (see "missing part #2" in
the cover letter).  This also should be reflected in the high-level doc.

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to