[Ivan Rostovikov]

В качестве PPPoE NAS используется 3 Linux машины (Etch)

rp-pppoe

Нагрузка распределяется неравномерно.

То, какой NAS возьмет сессию зависит от "латентности". У кого она меньше тот и возьмет.

Это не совсем меня устраивает. Нужно, что б сессии равномерно распределялись между NAS-ами.

 

Какие советы ?

[desperado]

сие никак не предусмотрено протоколом. если решения и есть то это костыли. разбейте юзеров на 3 группы и заведите трафик на каждый сервер отдельно если юзеров много то нагрузка распределится статистически относительно равномерно, а за одно бродкастов поубавится.

 

а одна машина не тянет? сколько коннектов?

[Ivan Rostovikov]

Доходит до 1000.

По 500 на каждую еще нормально. Но когда "перекос" - Ксеоны "клеют ласты".

Красивого и легкого решения не нашел. Хочется как у ServPoet.

Вспоминаю молодость, ковыряю исходники pppoe-server.c. Видимо придется дописать обработчик.

Фишка еще в том, что распределять хочется не всегда равномерно а иногда например 60/40 или 70/30

В общем с динамическим коэффициентом ;-)

Изменено 9 января, 2008 пользователем Ivan Rostovikov

[desperado]

1000 pppoe у меня не было, а для 1000 pptp + mppe128 машинка нужна весьма посредственная. pppoe должен быть заметно легче в плане процессора.

[Ivan Rostovikov]

Эта тема (про "посредственные" машинки) уже обсуждалась.

В условиях активного межабонентского трафика не все так гладко.

C PPTP локальный трафик обычно ходит "мимо", А на PPPoE Все через роутер. 500-600 коннектов, из них 10 одновременно качают на скорости 100Mb. И ВСЕ! кончился любой сервер. Поверьте.

[nuclearcat]

А пробовали oprofile гонять и смотреть где затык?

[Ivan Rostovikov]

"oprofile" Эт чего такое ?

[nuclearcat]

Профайлер, может показать какая часть кода или системы загружает больше всего процессор.

[Ivan Rostovikov]

Это не совсем по теме топика. Но интересно.

Прошу ссылку на материал.

[nuclearcat]

http://www.rhd.ru/docs/manuals/enterprise/...yzing-data.html

[Taras]

Доходит до 1000.

По 500 на каждую еще нормально.

А если с опцией -N 500 запустить каждый rp-pppoe?

[Ivan Rostovikov]

>А если с опцией -N 500

 

Попробую обьяснить, что просисходит:

 

ОТ абонента приходит PADI оба роутера его видят и отвечают PADO

У кого "латентность" в этот момент меньше (короче) того PADO придет раньше и соотв. абонент зацепится с ним. Только после этого rp-pppoe сервер начнет проверять -N. И если кол-во сессий уже максимальное абонент получит "отбой" (линия занята).

 

На другой сервер эта сессия не перейдет. т.к. PADO получен от этого сервера. А у абонента на экране появится сообщение об ошибке. Что недопустимо.

 

Короче этот вариант не канает.

[Taras]

>А если с опцией -N 500

 

Попробую обьяснить, что просисходит:

 

ОТ абонента приходит PADI оба роутера его видят и отвечают PADO

У кого "латентность" в этот момент меньше (короче) того PADO придет раньше и соотв. абонент зацепится с ним. Только после этого rp-pppoe сервер начнет проверять -N. И если кол-во сессий уже максимальное абонент получит "отбой" (линия занята).

 

На другой сервер эта сессия не перейдет. т.к. PADO получен от этого сервера. А у абонента на экране появится сообщение об ошибке. Что недопустимо.

 

Короче этот вариант не канает.

Спасибо. Буду знать :)

[nuclearcat]

Теоретически там должно быть легко подпатчить на предмет не отвечать на PADI если нет слотов.

Чтото типа

diff -Naur rp-pppoe-3.8-new/src/pppoe-server.c rp-pppoe-3.8-new2/src/pppoe-server.c
--- rp-pppoe-3.8-new/src/pppoe-server.c 2008-01-05 17:19:56.000000000 +0200
+++ rp-pppoe-3.8-new2/src/pppoe-server.c        2008-01-11 14:25:02.000000000 +0200
@@ -576,18 +576,22 @@
     size_t acname_len;
     unsigned char *cursor = pado.payload;
     UINT16_t plen;
+    ClientSession *ses = FreeSessions;

     int sock = ethif->sock;
     int i;
     int ok = 0;
     unsigned char *myAddr = ethif->mac;

+    if (!ses) return;
+
     /* Ignore PADI's which don't come from a unicast address */
     if (NOT_UNICAST(packet->ethHdr.h_source)) {
        syslog(LOG_ERR, "PADI packet from non-unicast source address");
        return;
     }

[Ivan Rostovikov]

Точно ! Так и делаю.

Только вот для распределения сесий по серверам надо добавить реакцию на внешние условия.

[nuclearcat]

Для распределения сессий можно например сделать функцию:

1)считаем из src mac crc8 (9 бит)

Если два pppoe сервера:

значение от 0 до 255 - первый сервер

от 255 до 511 - второй сервер

ну ессно если сервер видит, что это его клиент - берет на себя.

Для HA добавляем скриптик, где сервера пингуют друг друга и логика, чтоб поднимать упавший сервер на себе.

[EvilShadow]

Если последующая авторизация идет через радиус, можно до отсылки PADI проделывать radclient 'User-Name = _NAS_ID' _server_ip auth _secret, например, popen'ом, а на радиус-сервере разрешать или запрещать доступ для указанного пользователя (_NAS_ID), исходя из текущего кол-ва сессий на этом NAS.

Изменено 12 января, 2008 пользователем EvilShadow

[nuclearcat]

EvilShadow, по производительности это будет не очень хорошо.

Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать.

[desperado]

EvilShadow, по производительности это будет не очень хорошо.

Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать.

да ну, ерунда - это же только на этапе установки соединения. максимум несколько десятков запросов в минуту.

[nuclearcat]

EvilShadow, по производительности это будет не очень хорошо.

Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать.

да ну, ерунда - это же только на этапе установки соединения. максимум несколько десятков запросов в минуту.

А если какой-то дурной Линксис переклинит и он будет слать PAID с частотой 20 запросов в секунду?

 

 

У меня такое случается очень часто, правда чаще Линксисы клинит на PADT.

[EvilShadow]

EvilShadow, по производительности это будет не очень хорошо.

Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать.

Можно не на каждый. Например, делать проверки каждый N-й раз, при запрете от радиуса следующие N - 1 пакетов отбрасывать. Алгоритмов вычисления N можно придумать уйму, в зависимости от структуры сети и количества/плотности расстановки NAS. Например, можно принять N == кол-во NAS, т.е. нечто вроде round-robin. Можно ввести поправку N для исключения ситуации, при которой свободные слоты есть, а все NAS отказывают из-за задержки проверки. Можно разрешать доступ для следующего NAS при исчерпании слотов предыдущего...

На самом же radius-сервере, обладающем сведениями обо всех NAS, удобно реализовать процедуру вычисления распределения нагрузки, причем достаточно сложную.

[desperado]

EvilShadow, по производительности это будет не очень хорошо.

Дополнительный fork, плюс запросы в SQL на каждый PADI - очень сомнительно, что будет быстро работать.

да ну, ерунда - это же только на этапе установки соединения. максимум несколько десятков запросов в минуту.

А если какой-то дурной Линксис переклинит и он будет слать PAID с частотой 20 запросов в секунду?

а он их шлет не дожидаясь ответа? в любом случае, слать ему ответы с такой же периодичностью не совсем правильный выход.

 

можно на отдельный сокет повесить процесс который будет хранить количество запросов с этого адреса за последние N скунд. а я бы вообще отказался от радиуса и написал бы свою прослойку для авторизации и т.п. (как собственно и сделал это для pptp)

[nuclearcat]

Излишняя сложность в большинстве случаев означает меньшую надежность.

 

Я симулировал свою идею с CRC на данных нескольких реальных PPPoE, правда применил CRС32.

1)141/152

2)101/90

в случае CRC16 (данные на pppoe изменились)

1)148/149

2)111/80

 

Т.е. относительный баланс соблюдается. В худшем случае после всех проверок была погрешность около 25%.

Изменено 12 января, 2008 пользователем nuclearcat

[igoriii]

Излишняя сложность в большинстве случаев означает меньшую надежность.

 

Я симулировал свою идею с CRC на данных нескольких реальных PPPoE, правда применил CRС32.

1)141/152

2)101/90

в случае CRC16 (данные на pppoe изменились)

1)148/149

2)111/80

 

Т.е. относительный баланс соблюдается. В худшем случае после всех проверок была погрешность около 25%.

а чётный нечётный не прокатит?

[nuclearcat]

igoriii - Не прокатит на больше чем 2 PPPoE. Т.е. не scalable.