diff --git a/figures.pptx b/figures.pptx index dbee33a..223cc33 100644 Binary files a/figures.pptx and b/figures.pptx differ diff --git a/figures/Slide42.png b/figures/Slide42.png new file mode 100644 index 0000000..f2083e9 Binary files /dev/null and b/figures/Slide42.png differ diff --git a/onos.rst b/onos.rst index ec0f612..1060ab9 100644 --- a/onos.rst +++ b/onos.rst @@ -147,7 +147,7 @@ are in turn implemented using a distributed key/value store. The store itself will be familiar to anyone that has looked at how modern cloud services are designed—it scales across a distributed set of servers, and implements the Raft consensus algorithm to achieve fault-tolerance -in the face of failures. If you are unfamiliar with Raft, a good +in the event of failures. If you are unfamiliar with Raft, a good introduction is available at: .. _reading_p4: @@ -671,6 +671,22 @@ The bundle also includes Atomix, although ONOS supports an optional configuration that scales the key/value store independently from the rest of ONOS. +.. _fig-ha: +.. figure:: figures/Slide42.png + :width: 600px + :align: center + + Multiple ONOS instances, all sharing network state via Atomix, + provides scalable performance and high availability. + +:numref:`Figure %s ` illustrates ONOS scaled across multiple +instances, where the set of instances share network state via Atomix +Maps. The figure also shows each instance being responsible for a +subset of the underlying hardware switches. Should a given instance +fail, the remaining instances use the Atomix leader-election primitive +to select a new instance to take its place, thereby assuring high +availability. + A refactoring of ONOS to more closely adhere to a microservice architecture is also underway. The new version, called µONOS, leverages ONOS’s existing modularity, but packages and scales diff --git a/preface.rst b/preface.rst index 2076f0c..e821b05 100644 --- a/preface.rst +++ b/preface.rst @@ -21,10 +21,10 @@ organized accordingly. SDN suggests a completely different world-view, one that comes with a new software stack. This book is organized around that new stack, with the goal of presenting a top-to-bottom tour of SDN without leaving any significant gaps that the reader might -suspect can only be filled with magic or proprietary code. *In fact, we -invite you do the hands-on programming exercises included at the end -of the book to prove to yourself that the software stack is both real -and complete.* +suspect can only be filled with magic or proprietary code. *We invite +you do the hands-on programming exercises included at the end of the +book to prove to yourself that the software stack is both real and +complete.* An important aspect of meeting this goal is to use open source. We do this in large part by taking advantage of two community-based