С проблемой построения систем учета трафика сталкивается практически каждый суб-провайдер. Если у вышестоящих провайдеров уже обычно работают профессионалы, знающие, что должны получить в результате и умеющие правильно спроектировать и настроить систему учета трафика, то суб-провайдеры обычно ограничены как в средствах, так и не обладают достаточными знаниями для создания функциональных и защищенных систем. К тому же покупка серьезного оборудования обычно не входит в их планы и вместо оборудования Cisco, Juniper или аналогичного, часто приходится использовать завалявшееся железо. К минусам такого подхода относится то, что зачастую оно обычно нестабильно и может выйти из строя.
Производительность
Наверное, для многих будет интересен вопрос производительности операционной системы Mikrotik на вышеназванной платформе и его реальные требования к конфигурации компьютера.
Стоит отметить, что заявленные минимальные требования полностью соответствуют реальным. На 32 мегабайтах оперативной памяти и процессоре Pentium 133 система обслуживала одновременно около 20 подключенных по протоколу PPTP клиентов, динамически ограничивая скорость и фильтруя нежелательный трафик. Общая скорость канала составляла примерно 512/512 Кбит/с. При всём этом загрузка процессора редко когда доходила до 40% и в среднем равнялась 15-25%. В условиях, когда скорости измеряются мегабитами, системные требования заметно возрастают.
Хотелось бы обратить ваше внимание на то, что популярный нынче протокол VPN (PPTP) достаточно ресурсоёмок и во всех возможных случаях вместо него рекомендуется использовать альтернативный и лёгкий PPPOE, клиентская поддержка которого реализована уже в Windows XP. Для более ранних операционных систем его придется устновить отдельно. Так же в целях повышения производительности Mikrotik стоит очень аккуратно отнестись к настройке Firewall и шейпера, по возможности отключить встроенную генерацию графиков загрузки канала и ресурсов системы.
Тесты производительности
Наши заявления по поводу производительности подобных платформ были бы голословными без тестов производительности. Для Mikrotik существует специальная утилита, позволяющая примерно оценить максимальную пропускную способность системы. Из интересующих нас параметров в ней присутствует возможность задлания размера передаваемых пакетов в байтах, скорость входящего/исходящего потоков, направление пакетов. Полученные при тестировании результаты мы оформили в таблицу:
|
Способ тестирования |
Размер пакета в байтах (TX/RX) |
Средний результат |
Рисунок |
|
Поднимаем VPN тоннель и запускаем Btest на TCP both. TX/RX |
80/640 |
27/29 мегабит |
1 |
|
Поднимаем VPN тоннель и запускаем Btest на TCP both. TX/RX |
640/80 |
8/36.5 мегабит |
2 |
|
Поднимаем VPN тоннель и запускаем Btest на TCP both. TX/RX |
1024/1024 |
19/32 мегабит |
3 |
|
Поднимаем VPN тоннель и запускаем Btest на TCP both. Ставим скорость 128/64 и считаем общий канал. TX/RX |
80/640 |
60-80 подключений до 5120/10240 |
|
|
Поднимаем VPN тоннель и запускаем Btest на UDP both. TX/RX |
80/640 |
1/6.9 мегабит |
4 |
|
Поднимаем VPN тоннель и запускаем Btest на UDP both. |
640/80 |
141 кбит/51.1 мегабит (аномалии) |
5 |
|
Поднимаем VPN тоннель и запускаем Btest на UDP both Ставим скорость 128/64 и считаем общий канал. TX/RX |
80/640 |
4.3/5.6 мегабит 60 подключений |
|
|
Поднимаем PPPOE тоннель и запускаем Btest на TCP both. TX/RX |
80/640 |
47.4/17.5 мегабит |
6 |
|
Поднимаем PPPOE тоннель и запускаем Btest на TCP both. TX/RX |
640/80 |
20/29 мегабит |
|
|
Поднимаем PPPOE тоннель и запускаем Btest на TCP both. TX/RX |
1024/1024 |
40/25 мегабит |
|
|
Поднимаем PPPOE тоннель и запускаем Btest на TCP both. Ставим скорость 128/64 и считаем общий канал. TX/RX |
80/640 |
110 подключений 7040 кбит/14080 кбит |
|
|
Поднимаем PPPOE тоннель и запускаем Btest на UDP both. TX/RX |
80/640 |
13/11 мегабит |
|
|
Поднимаем PPPOE тоннель и запускаем Btest на UDP both TX/RX |
640/80 |
381/74.6 мегабит
|
|
|
Поднимаем PPPOE тоннель и запускаем Btest на UDP both. TX/RX |
1024/1024 |
38.2/74.1 мегабит
|
|
Ниже вы можете увидеть как проходило тестирование на примере нескольких скриншотов.
Тест 1
Тест 2
Тест 3
Тест 4
Тест 5
Тест 6
Перекачка болших файлов с FTP сервера
Закачка файлов на сервер
Нельзя учитывать эту информацию как абсолютно точную, так как проводилось синтетическое тестирование и оно кое-где привело к противоречивости информации. На последних двух графиках была показана загрузка системы при перекачке через маршрутизатор больших файлов на файл-сервер, подключенный по PPPOE к этому же серверу доступа. Как видим, загрузка процессора при этом составила около 90%, а реальная пропускная способность сетевых интерфейсов 65-79 Мбит/с, что, согласитесь, не мало. В расчете мощности оборудования, взяв за основу наше тестирование, необходимо учесть, что мы проводили тесты на одном физическом PPTP/PPPOE подключении. В реальных "боевых" условиях при 80-90 виртуальных подключениях значительно больше ресурсов процессора уйдёт на обсчёт служебной информации и пропускная способность окажется меньше указанной.
Рваные кривые на графиках обусловлены высокой загрузкой процессора клиентской программой. На практике такой маршрутизатор способен обслужить около ста одновременных пользователей, разделяя между ними полосу в 5-10 Мбит/с. Для большей устойчивости системы, мы порекомендовали бы использовать два сервера доступа и один резервный для горячей замены в случае проблем.
