2.16.3.1.21. Yardstick Test Case Description TC092¶
SDN Controller resilience in HA configuration |
|
test case id |
OPNFV_YARDSTICK_TC092: SDN controller resilience and high availability HA configuration |
test purpose |
This test validates SDN controller node high availability by verifying there is no impact on the data plane connectivity when one SDN controller fails in a HA configuration, i.e. all existing configured network services DHCP, ARP, L2, L3VPN, Security Groups should continue to operate between the existing VMs while one SDN controller instance is offline and rebooting. The test also validates that network service operations such as creating a new VM in an existing or new L2 network network remain operational while one instance of the SDN controller is offline and recovers from the failure. |
test method |
|
attackers |
In this test case, an attacker called “kill-process” is needed. This attacker includes three parameters:
|
monitors |
|
operations |
|
metrics |
|
test tool |
Developed by the project. Please see folder: “yardstick/benchmark/scenarios/availability/ha_tools” |
references |
TBD |
configuration |
This test case needs two configuration files: 1. test case file: opnfv_yardstick_tc092.yaml
|
test sequence |
Description and expected result |
pre-action |
|
step 1 |
Each monitor runs in an independent process. Result: The monitor info will be collected. |
step 2 |
Start attacker: SSH to the VIM node and kill the SDN controller process determined in step 2. Result: One SDN controller service will be shut down |
step 3 |
Restart the SDN controller. |
step 4 |
Create a new VM in the existing Neutron network while the SDN controller is offline or still recovering. |
step 5 |
Stop IP connectivity monitors after a period of time specified by “waiting_time” Result: The monitor info will be aggregated |
step 6 |
Verify the IP connectivity monitor result Result: IP connectivity monitor should not have any packet drop failures reported |
step 7 |
Verify process_recover_time, which indicates the maximun time (seconds) from the process being killed to recovered, is within the SLA. This step blocks until either the process has recovered or a timeout occurred. Result: process_recover_time is within SLA limits, if not, test case failed and stopped. |
step 8 |
Start IP connectivity monitors for the new VM:
Result: The monitor info will be collected. |
step 9 |
Stop IP connectivity monitors after a period of time specified by “waiting_time” Result: The monitor info will be aggregated |
step 10 |
Verify the IP connectivity monitor result Result: IP connectivity monitor should not have any packet drop failures reported |
test verdict |
Fails only if SLA is not passed, or if there is a test case execution problem. |