4.4. Пример практических расчетов

Рассмотрим возможности применения предложенной методики для МСС, которая является частным случаем распределенных систем, в случае, когда для балансировки нагрузки используется сервис Microsoft Azure.

Microsoft Azure предлагает сервис балансировщика нагрузки для виртуальных машин (Iaas) и облачных служб (Paas), запущенных в облаке Microsoft Azure [105].

Балансировщик нагрузки позволяет распределять между серверами текущий трафик приложений, а так же контролировать и изменять его характеристики. Кроме того, он предоставляет возможность мониторинга работоспособности различных серверов и удаления нездоровых экземпляров из ротации балансировки.

Чтобы иметь возможность управлять общей функцией риска всей системы, необходимо знать используемые параметры и их возможные значения. При использовании системы балансировки нагрузки можно получать информацию о текущей загрузке каждого сервера, включенного в МСС. Без использования системы балансировки нагрузки распределение клиентских запросов между отдельными серверами было непрогнозируемым, так как такой информации не было. Это вынуждало компанию приобретать более производительное оборудование, чем это было необходимо, что приводило к увеличению затрат.

Рассмотрим МСС, включающую четыре рабочих сервера (рис. 4.12). Приложение, расположенное в Microsoft Azure, использующего балансировщик нагрузки для адресации входящего трафика (по адресу/порту 1.2.3.4:80) на четыре виртуальных сервера, слушающих 80-й порт.

Рис. 4.12. МСС с четырьмя рабочими серверами

Настроить балансировку нагрузки можно с помощью сервис-модели приложения или используя настройки на портале управления Microsoft Azure [105, 116, 118].

Будем конфигурировать сервис с помощью сервис-модели. В этом случае можно внести необходимые критерии для управления риском всей МСС. Для дальнейшего накопления статистики числа отказов настроим собственный мониторинг производительности. Используя возможность мониторинга рабочих серверов, определим тип тестирования производительности, который должен использовать балансировщик для проверки работоспособности сервиса следующим образом:

<LoadBalancerProbes>

<LoadBalancerProbe name=”MyProbe” protocol=”http” path=”Prbe.aspx” intervalIn Seconds=”15” timeoutInSeconds=”30” />

</LoadBalancerProbes>

Этим задается тестирование через HTTP, используя относительный путь =”Probe.aspx”. Настройка тестирования задает также периодичность опросов. В данном случае балансировщик опрашивает каждые 15 секунд. Если ответ не получен через 30 секунд, результат теста считается отрицательным, и виртуальный сервер выводится из ротации. Если виртуальная машина выведена из ротации, но от нее начал приходить положительный ответ, этот сервис возвращается в ротацию.

До тех пор, пока не настроен собственный мониторинг производительности, тестирование на работоспособность проводится с помощью гостевого агента, но моет быть изменен сервисом с помощью события StatusCheck.

Определим дополнительную конечную току для 80-го порта, который использует собственный тест (”MyProbe”), следующим образом:

<InputEndPoint name=”HTTP_Prob”> protocol=”http” port=”80”

LoadBalancerProbe==”MyProbe” />

Сервис должен ответить с HTTP кодом 200, чтобы балансировщик считал его работоспособным, иначе виртуальный сервер выводится из ротации.

Будем теперь рассматривать сценарий I, то есть, когда DDoS-атаки проводятся на серверы МСС асинхронно. Настроим параметры контроля работоспособности сервиса: число открытых TCP-соединений ( ), максимальный коэффициент загрузки центрального процессора ( ). Если значения этих параметров близки для разных серверов, то общий риск МСС будет большим. Текущие значения этих параметров отслеживаются балансировщиком и используются для оптимального выбора севера для поступившего клиентского запроса.

Настроим эти параметры таким образом, чтобы суммарный риск колебался в заданной полосе неравномерности, используя условие уравнивания пиковых значений функций риска. В дальнейшем их значения будут использованы сервисами виртуальных машин для определения их работоспособности. При этом максимальное значение риска не должно превышать значения 5,35 ( ).

Настроим параметры первого сервиса , , используя заданное значение и формулу (3.4). Для выбора параметров второго сервиса и , соответствующие параметрам его функции риска, используем формулу (3.6). Значения остальных параметров ( ) вычислим, используя формулу (3.16). Значения полученных параметров приведены на рисунке 4.13 . Вычисления проводились в табличном процессоре EXCEL.

Рис. 4.13. Значения рассчитанных параметров

Функции рисков рабочих серверов, полученные по найденным параметрам, и общая функция риска представлены на рис. 4.14.

Рис. 4.14. Оценка и регулирование риска МСС

Используя формулы (3.7), (3.9) найдем значения аргумента, при которых общая функция риска имеет локальные экстремумы. Они необходимы для регулирования риска всей МСС. В результате получены следующие значения:

; ; ; ;

; ; .

Используя эти значения и методику пункта 4.2, можно уменьшать диапазон неравномерности и даже уменьшить значение порогового риска. Кроме того, можно уменьшить значение полученного ущерба от реализации DDOS-атак, сдвигая значения экстремумов влево по оси ущербов.