1 .. This work is licensed under a Creative Commons Attribution 4.0 International
3 .. http://creativecommons.org/licenses/by/4.0
4 .. (c) OPNFV, Intracom Telecom and others.
5 .. mardim@intracom-telecom.com
7 *************************************
8 Yardstick Test Case Description TC093
9 *************************************
11 +-----------------------------------------------------------------------------+
12 |SDN Vswitch resilience in non-HA or HA configuration |
14 +--------------+--------------------------------------------------------------+
15 |test case id | OPNFV_YARDSTICK_TC093: SDN Vswitch resilience in |
16 | | non-HA or HA configuration |
17 +--------------+--------------------------------------------------------------+
18 |test purpose | This test validates that network data plane services are |
19 | | resilient in the event of Virtual Switch failure |
20 | | in compute nodes. Specifically, the test verifies that |
21 | | existing data plane connectivity is not permanently impacted |
22 | | i.e. all configured network services such as DHCP, ARP, L2, |
23 | | L3 Security Groups continue to operate between the existing |
24 | | VMs eventually after the Virtual Switches have finished |
27 | | The test also validates that new network service operations |
28 | | (creating a new VM in the existing L2/L3 network or in a new |
29 | | network, etc.) are operational after the Virtual Switches |
30 | | have recovered from a failure. |
32 +--------------+--------------------------------------------------------------+
33 |test method | This testcase first checks if the already configured |
34 | | DHCP/ARP/L2/L3/SNAT connectivity is proper. After |
35 | | it fails and restarts again the VSwitch services which are |
36 | | running on both OpenStack compute nodes, and then checks if |
37 | | already configured DHCP/ARP/L2/L3/SNAT connectivity is not |
38 | | permanently impacted (even if there are some packet |
39 | | loss events) between VMs and the system is able to execute |
40 | | new virtual network operations once the Vswitch services |
41 | | are restarted and have been fully recovered |
43 +--------------+--------------------------------------------------------------+
44 |attackers | In this test case, two attackers called “kill-process” are |
45 | | needed. These attackers include three parameters: |
46 | | 1. fault_type: which is used for finding the attacker's |
47 | | scripts. It should be set to 'kill-process' in this test |
49 | | 2. process_name: should be set to the name of the Vswitch |
52 | | 3. host: which is the name of the compute node where the |
53 | | Vswitch process is running |
55 | | e.g. -fault_type: "kill-process" |
56 | | -process_name: "openvswitch" |
59 +--------------+--------------------------------------------------------------+
60 |monitors | This test case utilizes two monitors of type "ip-status" |
61 | | and one monitor of type "process" to track the following |
63 | | 1. "ping_same_network_l2": monitor ICMP traffic between |
64 | | VMs in the same Neutron network |
66 | | 2. "ping_external_snat": monitor ICMP traffic from VMs to |
67 | | an external host on the Internet to verify SNAT |
70 | | 3. "Vswitch process monitor": a monitor checking the |
71 | | state of the specified Vswitch process. It measures |
72 | | the recovery time of the given process. |
74 | | Monitors of type "ip-status" use the "ping" utility to |
75 | | verify reachability of a given target IP. |
77 +--------------+--------------------------------------------------------------+
78 |operations | In this test case, the following operations are needed: |
79 | | 1. "nova-create-instance-in_network": create a VM instance |
80 | | in one of the existing Neutron network. |
82 +--------------+--------------------------------------------------------------+
83 |metrics | In this test case, there are two metrics: |
84 | | 1. process_recover_time: which indicates the maximun |
85 | | time (seconds) from the process being killed to |
88 | | 2. outage_time: measures the total time in which |
89 | | monitors were failing in their tasks (e.g. total time of |
92 +--------------+--------------------------------------------------------------+
93 |test tool | Developed by the project. Please see folder: |
94 | | "yardstick/benchmark/scenarios/availability/ha_tools" |
96 +--------------+--------------------------------------------------------------+
99 +--------------+--------------------------------------------------------------+
100 |configuration | This test case needs two configuration files: |
101 | | 1. test case file: opnfv_yardstick_tc093.yaml |
102 | | - Attackers: see above “attackers” description |
103 | | - monitor_time: which is the time (seconds) from |
104 | | starting to stoping the monitors |
105 | | - Monitors: see above “monitors” discription |
106 | | - SLA: see above “metrics” description |
108 | | 2. POD file: pod.yaml The POD configuration should record |
109 | | on pod.yaml first. the “host” item in this test case |
110 | | will use the node name in the pod.yaml. |
112 +--------------+--------------------------------------------------------------+
113 |test sequence | Description and expected result |
115 +--------------+--------------------------------------------------------------+
116 |pre-action | 1. The Vswitches are set up in both compute nodes. |
118 | | 2. One or more Neutron networks are created with two or |
119 | | more VMs attached to each of the Neutron networks. |
121 | | 3. The Neutron networks are attached to a Neutron router |
122 | | which is attached to an external network towards the |
125 +--------------+--------------------------------------------------------------+
126 |step 1 | Start IP connectivity monitors: |
127 | | 1. Check the L2 connectivity between the VMs in the same |
128 | | Neutron network. |
130 | | 2. Check connectivity from one VM to an external host on |
131 | | the Internet to verify SNAT functionality. |
133 | | Result: The monitor info will be collected. |
135 +--------------+--------------------------------------------------------------+
136 |step 2 | Start attackers: |
137 | | SSH connect to the VIM compute nodes and kill the Vswitch |
140 | | Result: the SDN Vswitch services will be shutdown |
142 +--------------+--------------------------------------------------------------+
143 |step 3 | Verify the results of the IP connectivity monitors. |
145 | | Result: The outage_time metric reported by the monitors |
146 | | is not greater than the max_outage_time. |
148 +--------------+--------------------------------------------------------------+
149 |step 4 | Restart the SDN Vswitch services. |
151 +--------------+--------------------------------------------------------------+
152 |step 5 | Create a new VM in the existing Neutron network |
154 +--------------+--------------------------------------------------------------+
155 |step 6 | Verify connectivity between VMs as follows: |
156 | | 1. Check the L2 connectivity between the previously |
157 | | existing VM and the newly created VM on the same |
158 | | Neutron network by sending ICMP messages |
160 +--------------+--------------------------------------------------------------+
161 |step 7 | Stop IP connectivity monitors after a period of time |
162 | | specified by “monitor_time” |
164 | | Result: The monitor info will be aggregated |
166 +--------------+--------------------------------------------------------------+
167 |step 8 | Verify the IP connectivity monitor results |
169 | | Result: IP connectivity monitor should not have any packet |
170 | | drop failures reported |
172 +--------------+--------------------------------------------------------------+
173 |test verdict | This test fails if the SLAs are not met or if there is a |
174 | | test case execution problem. The SLAs are define as follows |
176 | | * SDN Vswitch recovery |
177 | | * process_recover_time <= 30 sec |
179 | | * no impact on data plane connectivity during SDN |
180 | | Vswitch failure and recovery. |
181 | | * packet_drop == 0 |
183 +--------------+--------------------------------------------------------------+
Code Review / yardstick.git / blob