2.16.3.1.22. Yardstick Test Case Description TC093¶
SDN Vswitch resilience in non-HA or HA configuration |
|
test case id |
OPNFV_YARDSTICK_TC093: SDN Vswitch resilience in non-HA or HA configuration |
test purpose |
This test validates that network data plane services are resilient in the event of Virtual Switch failure in compute nodes. Specifically, the test verifies that existing data plane connectivity is not permanently impacted i.e. all configured network services such as DHCP, ARP, L2, L3 Security Groups continue to operate between the existing VMs eventually after the Virtual Switches have finished rebooting. The test also validates that new network service operations (creating a new VM in the existing L2/L3 network or in a new network, etc.) are operational after the Virtual Switches have recovered from a failure. |
test method |
This testcase first checks if the already configured DHCP/ARP/L2/L3/SNAT connectivity is proper. After it fails and restarts again the VSwitch services which are running on both OpenStack compute nodes, and then checks if already configured DHCP/ARP/L2/L3/SNAT connectivity is not permanently impacted (even if there are some packet loss events) between VMs and the system is able to execute new virtual network operations once the Vswitch services are restarted and have been fully recovered |
attackers |
In this test case, two attackers called “kill-process” are needed. These attackers include three parameters:
|
monitors |
This test case utilizes two monitors of type “ip-status” and one monitor of type “process” to track the following conditions:
Monitors of type “ip-status” use the “ping” utility to verify reachability of a given target IP. |
operations |
|
metrics |
|
test tool |
Developed by the project. Please see folder: “yardstick/benchmark/scenarios/availability/ha_tools” |
references |
none |
configuration |
|
test sequence |
Description and expected result |
pre-action |
|
step 1 |
Result: The monitor info will be collected. |
step 2 |
Start attackers: SSH connect to the VIM compute nodes and kill the Vswitch processes Result: the SDN Vswitch services will be shutdown |
step 3 |
Verify the results of the IP connectivity monitors. Result: The outage_time metric reported by the monitors is not greater than the max_outage_time. |
step 4 |
Restart the SDN Vswitch services. |
step 5 |
Create a new VM in the existing Neutron network |
step 6 |
|
step 7 |
Stop IP connectivity monitors after a period of time specified by “monitor_time” Result: The monitor info will be aggregated |
step 8 |
Verify the IP connectivity monitor results Result: IP connectivity monitor should not have any packet drop failures reported |
test verdict |
This test fails if the SLAs are not met or if there is a test case execution problem. The SLAs are define as follows for this test: * SDN Vswitch recovery
|