Cloud, SDN & Production Architectures · Study deck
SDN Resilience: API Availability
Write the request in plain words first.
Cloud Clara is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- define api and availability decision route with explicit inputs, errors, and change rules
- validate controller cluster responsibilities with a concrete scenario and pass criteria
- Explain: The ward must stay online while a control computer fails and its partner takes over.
- Explain: A healthy control screen is not proof that the ward received the intended service.
Major section
Start With the Request That Must Survive
The ward must stay online while a control computer fails and its partner takes over.
- The service owner needs to know that the right request reached the right switches and that no old rule survived by mistake.
- Scope names which ward the change may affect; also name who may ask, what must change, when it must end, and what result proves success.
- This opening does not select a product or prove every failure mode.
Major section
Start With the Request That Must Survive (continued)
A healthy control screen is not proof that the ward received the intended service.
- A change should fail closed or fall back to a known rule when its owner cannot prove current state.
- Under the Hood examines state sharing, leader choice, rule order, and the records needed to explain a change.
- If the request cannot be traced, availability claims are just slogans.
Major section
API and Availability Decision Route
It makes the decision concrete by showing SDN API and availability decision route, so the relationships can be checked before they are turned into a design claim.
- The requester states an authorized service intent, and the contract defines scope and the result it should return.
- This route makes availability a tested property across application and network boundaries.
Major section
API and Availability Decision Route (continued)
The controller must identify the owner and version of its state before translating the request into southbound rules.
- Failover then tests what happens when the preferred controller or path is unavailable.
- The final proof is the service outcome at a receiver, not merely an API success code.
- If that outcome fails, revise the contract or fallback behavior and rerun the request.
Major section
Northbound and Southbound Boundaries
Northbound and southbound APIs should not be treated as two names for the same interface.
- The contract should include identity, scope, reason, and proof expectations.
- The controller validates authorization, checks topology and policy conflicts, computes rule changes, records decisions, and exposes state back to approved clients.
- Switches should not receive unchecked application intent directly.
Major section
Request Lifecycle
A safe API design describes what happens after an application request arrives and before the network is allowed to change.
- Authorization checks who may ask for that change, while validation compares it with current topology, protected traffic, policy, and rollback conditions.
- Translation makes a rule plan before installation sends it to switches.
Major section
Northbound Contract Design
An SDN northbound API should be designed as a contract, not just as a URL or method name.
- Idempotency defines what happens when a timed-out request is retried.
- Accepted, pending, partial, rolled-back, or degraded outcomes need a versioned record so clients can reconcile state and survive later contract changes.
Major section
Controller Cluster Responsibilities
A controller cluster is not automatically safer than one controller.
- An OpenFlow switch is often drawn one line away from its controller.
- The physical path may cross access, aggregation, routed WAN, firewall, load balancer, and encrypted tunnel hops.
- Every hop adds queueing and a failure domain, so placement must be calculated from both request capacity and path behavior.
Major section
Controller Cluster Responsibilities (continued)
Current capacity depends on controller code, policy work, state-store replication, message type, CPU, and transport security; benchmark the exact release path.
- At λ=120/s, mean service-plus-queue time is 1/80=12.5 ms.
- At 180/s it rises to 50 ms even though offered load is still below nominal capacity.
- That nonlinear rise is why “under 200” is not a safe admission rule.
- Not every kind of state needs the same consistency model.
Major section
Controller Cluster Responsibilities (continued)
For k workers, do not assume kμ until shared locks, ordering, and replicated state have been measured.
- For small control frames, serialization may be minor on a fast LAN, while queueing, WAN propagation, retransmission, and TLS/session recovery dominate.
- A local controller may own emergency and gateway rules while a regional controller owns cross-site paths.
- Topology, policy records, active rule records, and ownership leases need clear replication and freshness rules.
Major section
Controller Cluster Responsibilities (continued)
During a partition, prohibit overlapping writers for the same match space; preserve already approved local rules; stop changes that require fresh global policy; and reconcile cookies, versions, counters, and expiries when connectivity returns.
- A placement test should therefore inject a synchronized reconnect storm, link delay/loss, controller failover, stale replicated state, and physical loss of a shared network hop.
- Switches should keep known safe forwarding behavior when possible, but the design must test what actually survives a controller loss.
- Operators need proof of which controller was active, which rules changed, what degraded, and what was rolled back.
Deck summary
Key takeaways
The ward must stay online while a control computer fails and its partner takes over.
- A healthy control screen is not proof that the ward received the intended service.
- It makes the decision concrete by showing SDN API and availability decision route, so the relationships can be checked before they are turned into a design claim.
- The controller must identify the owner and version of its state before translating the request into southbound rules.
- Northbound and southbound APIs should not be treated as two names for the same interface.
Retrieval practice
Recall check 1 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q1An application requests a network change through an SDN API. What should its northbound contract include?
Show answer
Answer: A The route requires a reviewable contract before translating a request into network action.
Retrieval practice
Recall check 2 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q2An application asks SDN to isolate traffic. Which component should validate and translate that intent?
Show answer
Answer: D The controller checks authorization, topology, and policy before computing device rules.
Retrieval practice
Recall check 3 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q3A standby controller takes over after the primary fails. What must the cluster prove before it changes gateway rules?
Show answer
Answer: A Failover must preserve authority, state, and service result.
Print reference
Answers
Answer key.
- A · The route requires a reviewable contract before translating a request into network action.
- D · The controller checks authorization, topology, and policy before computing device rules.
- A · Failover must preserve authority, state, and service result.