1 .. This work is licensed under a Creative Commons Attribution 4.0 International
3 .. http://creativecommons.org/licenses/by/4.0
4 .. (c) OPNFV, Ericsson and others.
6 *************************************
7 Yardstick Test Case Description TC087
8 *************************************
10 +-----------------------------------------------------------------------------+
11 |SDN Controller resilience in non-HA configuration |
13 +--------------+--------------------------------------------------------------+
14 |test case id | OPNFV_YARDSTICK_TC087: SDN controller resilience in |
15 | | non-HA configuration |
17 +--------------+--------------------------------------------------------------+
18 |test purpose | This test validates that network data plane services are |
19 | | highly available in the event of an SDN Controller failure, |
20 | | even if the SDN controller is deployed in a non-HA |
21 | | configuration. Specifically, the test verifies that |
22 | | existing data plane connectivity is not impacted, i.e. all |
23 | | configured network services such as DHCP, ARP, L2, |
24 | | L3 Security Groups should continue to operate |
25 | | between the existing VMs while the SDN controller is |
26 | | offline or rebooting. |
28 | | The test also validates that new network service operations |
29 | | (creating a new VM in the existing L2/L3 network or in a new |
30 | | network, etc.) are operational after the SDN controller |
31 | | has recovered from a failure. |
33 +--------------+--------------------------------------------------------------+
34 |test method | This test case fails the SDN controller service running |
35 | | on the OpenStack controller node, then checks if already |
36 | | configured DHCP/ARP/L2/L3/SNAT connectivity is not |
37 | | impacted between VMs and the system is able to execute |
38 | | new virtual network operations once the SDN controller |
39 | | is restarted and has fully recovered |
41 +--------------+--------------------------------------------------------------+
42 |attackers | In this test case, an attacker called “kill-process” is |
43 | | needed. This attacker includes three parameters: |
44 | | 1. fault_type: which is used for finding the attacker's |
45 | | scripts. It should be set to 'kill-process' in this test |
47 | | 2. process_name: should be set to the name of the SDN |
48 | | controller process |
50 | | 3. host: which is the name of a control node where the |
51 | | SDN controller process is running |
53 | | e.g. -fault_type: "kill-process" |
54 | | -process_name: "opendaylight" |
57 +--------------+--------------------------------------------------------------+
58 |monitors | This test case utilizes two monitors of type "ip-status" |
59 | | and one monitor of type "process" to track the following |
61 | | 1. "ping_same_network_l2": monitor ICMP traffic between |
62 | | VMs in the same Neutron network |
64 | | 2. "ping_external_snat": monitor ICMP traffic from VMs to |
65 | | an external host on the Internet to verify SNAT |
68 | | 3. "SDN controller process monitor": a monitor checking the |
69 | | state of a specified SDN controller process. It measures |
70 | | the recovery time of the given process. |
72 | | Monitors of type "ip-status" use the "ping" utility to |
73 | | verify reachability of a given target IP. |
75 +--------------+--------------------------------------------------------------+
76 |operations | In this test case, the following operations are needed: |
77 | | 1. "nova-create-instance-in_network": create a VM instance |
78 | | in one of the existing Neutron network. |
80 +--------------+--------------------------------------------------------------+
81 |metrics | In this test case, there are two metrics: |
82 | | 1. process_recover_time: which indicates the maximun |
83 | | time (seconds) from the process being killed to |
86 | | 2. packet_drop: measure the packets that have been dropped |
87 | | by the monitors using pktgen. |
89 +--------------+--------------------------------------------------------------+
90 |test tool | Developed by the project. Please see folder: |
91 | | "yardstick/benchmark/scenarios/availability/ha_tools" |
93 +--------------+--------------------------------------------------------------+
96 +--------------+--------------------------------------------------------------+
97 |configuration | This test case needs two configuration files: |
98 | | 1. test case file: opnfv_yardstick_tc087.yaml |
99 | | - Attackers: see above “attackers” discription |
100 | | - waiting_time: which is the time (seconds) from the |
101 | | process being killed to stoping monitors the monitors |
102 | | - Monitors: see above “monitors” discription |
103 | | - SLA: see above “metrics” discription |
105 | | 2. POD file: pod.yaml The POD configuration should record |
106 | | on pod.yaml first. the “host” item in this test case |
107 | | will use the node name in the pod.yaml. |
109 +--------------+--------------------------------------------------------------+
110 |test sequence | Description and expected result |
112 +--------------+--------------------------------------------------------------+
113 |pre-action | 1. The OpenStack cluster is set up with a single SDN |
114 | | controller in a non-HA configuration. |
116 | | 2. One or more Neutron networks are created with two or |
117 | | more VMs attached to each of the Neutron networks. |
119 | | 3. The Neutron networks are attached to a Neutron router |
120 | | which is attached to an external network towards the |
123 +--------------+--------------------------------------------------------------+
124 |step 1 | Start IP connectivity monitors: |
125 | | 1. Check the L2 connectivity between the VMs in the same |
126 | | Neutron network. |
128 | | 2. Check connectivity from one VM to an external host on |
129 | | the Internet to verify SNAT functionality.
131 | | Result: The monitor info will be collected. |
133 +--------------+--------------------------------------------------------------+
134 |step 2 | Start attacker: |
135 | | SSH connect to the VIM node and kill the SDN controller |
138 | | Result: the SDN controller service will be shutdown |
140 +--------------+--------------------------------------------------------------+
141 |step 3 | Verify the results of the IP connectivity monitors. |
143 | | Result: The outage_time metric reported by the monitors |
146 +--------------+--------------------------------------------------------------+
147 |step 4 | Restart the SDN controller. |
149 +--------------+--------------------------------------------------------------+
150 |step 5 | Create a new VM in the existing Neutron network |
152 +--------------+--------------------------------------------------------------+
153 |step 6 | Verify connectivity between VMs as follows: |
154 | | 1. Check the L2 connectivity between the previously |
155 | | existing VM and the newly created VM on the same |
156 | | Neutron network by sending ICMP messages |
158 +--------------+--------------------------------------------------------------+
159 |step 7 | Stop IP connectivity monitors after a period of time |
160 | | specified by “waiting_time” |
162 | | Result: The monitor info will be aggregated |
164 +--------------+--------------------------------------------------------------+
165 |step 8 | Verify the IP connectivity monitor results |
167 | | Result: IP connectivity monitor should not have any packet |
168 | | drop failures reported |
170 +--------------+--------------------------------------------------------------+
171 |test verdict | This test fails if the SLAs are not met or if there is a |
172 | | test case execution problem. The SLAs are define as follows |
174 | | * SDN Controller recovery |
175 | | * process_recover_time <= 30 sec |
177 | | * no impact on data plane connectivity during SDN |
178 | | controller failure and recovery. |
179 | | * packet_drop == 0 |
181 +--------------+--------------------------------------------------------------+
Code Review / yardstick.git / blob