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: This opening does not select a product or prove every failure mode.
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.
- 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.
Major section
Start With the Request That Must Survive (continued)
This opening does not select a product or prove every failure mode.
- 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.
- The API contract and cluster design are good only when that trace stays understandable.
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.
- That observation connects this visual to the chapter's running narrative: use it to justify the next design decision and to record what evidence would confirm it in operation.
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
Northbound Contract Design
An SDN northbound API should be designed as a contract, not just as a URL or method name.
- This supports northbound contract design.
- Applications should not need to know every match field, rule priority, or device quirk to request a service outcome.
- The controller owns that translation and must make it traceable.
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 $\lambda=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\mu$ 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.
- With: Leaf Switch 3 included, their combined meaning is: A controller cluster keeps a primary and a hot standby in state sync, so the switch fabric keeps forwarding through a controller failover.
- Strongly coordinated state: policy ownership, topology decisions, rule install records, and rollback gates.
Deck summary
Key takeaways
The ward must stay online while a control computer fails and its partner takes over.
- This opening does not select a product or prove every failure mode.
- 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.
- Northbound and southbound APIs should not be treated as two names for the same interface.
- An SDN northbound API should be designed as a contract, not just as a URL or method name.
Retrieval practice
Recall check
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.
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.
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.