Distributed Architecture - aemadrid/orientdb GitHub Wiki

Distributed Servers and High Availability

Introduction

OrientDB can be distributed across different servers and used in different ways to achieve the maximum of performance, scalability and robustness.

OrientDB uses the Hazelcast Open Source project to manage the clustering. Many of the references in this page are linked to the Hazelcast official documentation to get more information about such topic.

Main topics

how to manage Replication of databases
how the requests are routed in the cluster
how to configuration the cluster

How does it work?

Joining a cluster

Auto discovering

At startup each Server Node sends an IP Multicast message in broadcast to discover if an existent cluster is available to join it. If available the Server Node will connect to it, otherwise create a new cluster

http://www.orientdb.org/images/cluster-autodiscovering.png

Security

To join a cluster the Server Node has to configure the cluster name and password. Broadcast messages are encrypted using the password. Password doesn't cross the network: it's stored in the configuration file.

http://www.orientdb.org/images/cluster-security.png

Join to an existent cluster

You can have multiple OrientDB clusters in the same network, what identifies a cluster is it’s name that must be unique in the network. In this case Server #2 joins the existent cluster.

http://www.orientdb.org/images/cluster-join.png

Multiple clusters

Multiple clusters can coexist in the same network. Clusters can't see each others because are isolated black boxes.

http://www.orientdb.org/images/cluster-multiple.png

Distribute the configuration to the clients

Every time a new Server Node joins or leaves the Cluster, the new Cluster configuration is broadcasted to all the connected clients. Everybody knows the cluster layout and who has a database!

http://www.orientdb.org/images/cluster-cfg.png

Fail over management

When a node is unreachable

When a Server Node becomes unreachable (because it’s crashed, network problems, high load, etc.) the Cluster treats this event as if the Server Node left the cluster.

http://www.orientdb.org/images/cluster-crash.png

Automatic switch of servers

All the clients connected to the unreachable node will switch to another server transparently without raising errors to the Application User Application doesn’t know what is happening!

http://www.orientdb.org/images/cluster-clientswitch.png

Re-distribute the updated configuration again

After the Server #2 left the Cluster the updated configuration is sent again to all the connected clients.

http://www.orientdb.org/images/cluster-recfg.png

Distributed transactions

Today transactions can't be distributed across multiple servers. The transaction semantic is not guarantee if the involved records come from different server nodes.