Understanding “Geodiversity” Between the SSR D Nodes
Being the very core of the system’s reliability, SBRC does not claim support for geodiversity among the SSR D nodes, since the underlying technology (Oracle MySQL NDB) does not claim such support. At the SBRC level, geodiversity can be supported at a split in the RADIUS layer with a second NOC installation with either its own SSR, or a load-balanced series of standalone systems to provide additional, perhaps limited, functionality through an unrelated SSR in a master/failover way.
That disclaimer made, as a matter of prudential and engineering judgment, a pair of single-mode fibers, each end connecting to switches at two different NOCs is a legitimate mechanism of providing LAN-equivalent functionality which should provide a similar level of uptime and supportability as a non-geodiverse solution.
However, in terms of network architecture, the further away from a literal pair of fibers you get, the further from optimal uptime you will achieve: each intervening piece of equipment, no matter on which network layer it operates and even if the device itself reaches 5 9s or greater, actually gives greater risk, from both a technical (99.999% * 99.999% = 99.998%, and that is multiplicative for each device in series) as well as a human point of view. This is due to the possibility of inducing certain types of network latency (for example, when being reconfigured or reprovisioned) that will lead to a temporary outage and require additional recovery time, or an extended outage due to human or system error. It is often difficult to diagnose these transient latency increases, although with SBRC Release 7.4.0, logging within the SSR D nodes has been improved.
In any managed MPLS network, even rigorous SLAs can be written in such a way that jitter, packet loss, and latency might rise above the tolerances of the ndb transport, and as such, cannot be supported.