пятница, 4 февраля 2011 г.

Автоматический рубильник сетевой карты

Для стресс-тестирования распределенных систем мне, как тестировщику, приходится проверять поведение системы в случае, когда один из компонентов периодически недоступен. Постоянно отключать сеть вручную не совсем удобно, особенно когда используешь технику Exploratory testing. А нельзя ли процесс отключения и включения сети автоматизировать?


Итак, в миссии «Работа в условиях плохой связи между компонентами» стоит задача организовать эту самую “плохую связь”. Один из случаев “плохой связи” я и организовал: постоянно отключается/включается сетевая карта.
Возможно, существует много способов это сделать, но я знаю три.

Способ А: Использование утилиты DevCon.
DevCon — это программа с интерфейсом командной строки, которая используется в качестве альтернативы диспетчеру устройств. С ее помощью можно включать, выключать, перезапускать, обновлять, удалять и опрашивать отдельные устройства или группы устройств. В итоге у меня получился PowerShell скрипт, который делает недоступной/доступной сетевую карту. (Не спорю, скрипт можно написать и на батнике, но PowerShell мне как то ближе. :) )
Cкрипт положить в одну папку с devcon.exe. Итак, вот листинг скрипта:

$deviceName = “*VEN_1022&DEV_2000”
do {
.\devcon.exe disable $deviceName
.\devcon.exe enable $deviceName
Sleep -Seconds 10
} while($true)

Бесконечный цикл постоянно отключает “.\devcon.exe disable $deviceName” и включает “.\devcon.exe enable $deviceName” сетевую карту. Потом дает поработать 10 секунд и снова отключает и включает. В скрипт можно внести элемент случайности, ставить разные задержки, в общем, “затачивать” под себя.
Нужное устройство легко можно найти с помощью ключа к devcon, а именно -find.

Способ Б: Использование VM-server 2.0 + PowerShell.
Если вы используете VM-server 2.0 и знакомы с Powershell, то вам, возможно, подойдет второй способ работы с сетевой картой. Как настроить эту связку вы можете найти в интернете. Если вам лень искать, то начать можете с этой статьи.
Итак, ниже приведен листинг скрипта на PowerShell:

Connect-VIServer ServerName -Port PortNumber
$vmMachine = Get-VM VMname
$vmAdapter = $vmMachine .NetworkAdapters
do {
$vmAdapter | Set-NetworkAdapter -Connected 0 -Confirm:$false
$vmAdapter | Set-NetworkAdapter -Connected 1 -Confirm:$false
Sleep -Seconds 10
} while($true)

Скрипт делает то же самое, что и первый, но управление идет со стороны настроек самой виртуальной машины. Кстати, этот скрипт не зависит от системы, установленной на виртуальной машине.

Способ В: Использование WMI.
И наконец, третий из используемых мной способов. А помогать нам будет вновь PowerShell, со своим командлетом Get-WMIObject. Получается скрипт:

$vmAdapterName = "Name = 'Имя вашей сетевой карты'"
$vmAdapter = Get-WmiObject -Class Win32_NetworkAdapter -Filter $vmAdapterName
do {
$vmAdapter.Disable()
$vmAdapter.Enable()
Sleep -Seconds 10
} while($true)

В Get-WmiObject -Class Win32_NetworkAdapter -Filter $vmAdapterName, мы обращаемся к классу WMI Win32_NetworkAdapter и получаем свойства для нашей сетевой карты. Потом мы, с помощью методов Disable() и Enable(), включаем и выключаем ее.
Все скрипты опробованы на деле и уже принесли свои результаты - найден баг, который мог проявиться у клиента с плохим, например, соединением “кабель-сетевая карта”.

P.S. Cамое прекрасное во всем этом то, что отключение/включение сетевой карты можно сделать “по событию”. Например, создался у вас файл, готовый к отправке, бац... отключили сетевую карту. :) И смотрим на поведение системы.

5 комментариев:

  1. Такой 'натуральный' вариант:
    ipconfig /release "Local Area Connection"
    ipconfig /renew "Local Area Connection"

    ОтветитьУдалить
  2. до кучи
    netsh interface set interface "Подключение по локальной сети" disabled(enabled)

    ОтветитьУдалить
  3. Привет.
    Отлично! спасибо, что добавляете новые способы. Думаю, это очень полезная инфа для всех, кто сталкивался с этой проблемой.

    ОтветитьУдалить
  4. Всем привет,
    Отключение интерфейса подобным образом, можно сравнить с плохим сетевым кабелем.
    Мне кажется более интересным, рассмотреть вариант с большим временем отклика. Часто такое поведение наблюдается в мобильных сетях.

    ОтветитьУдалить