Załóżmy tak, że masz np. 1500 sesji w szczycie podniesionych i chcesz żeby to w miarę rozkładało się po równo na oba koncentratory.

Zabawa polega na tym, żeby ustawić odpowiednie opóźnienie, po którym odpowiada koncentrator, w zależności od tego ile ma zaterminowanych sesji w danym momencie.

Accel umożliwia dokładną definicję opóźnień, dla konkretnej ilości podniesionych sesji.
Odpowiedzialna jest za to opcja pado-delay, znajdująca się w sekcji [pppoe] (tam gdzie masz dodane na sztywno interfejsy, gdzie jest nazwa koncentratora i service-name).

Opcja pado-delay może przyjmować jedną wartość (np. pado-delay=100) - wtedy nie jest ważne ile jest podniesionych sesji, koncentrator odpowiada (pakiet z PADO - PPPoE Active Discovery Offer) po 100ms.
Oczywiście powyższe 100ms to w sytuacji, kiedy zasoby na to pozwalają - jak jest maszyna mocno obciążona, czas odpowiedzi jest wyższy - ale to chyba oczywiste :)

Z tym jednym parametrem można sobie fajnie zrobić kilka koncentratorów, gdzie np. jest jeden główny, który terminuje sesje, ale kiedy przestaje wyrabiać albo ilość zaterminowanych sesji osiągnie jakąś określoną wartość, część nowych sesji zaczyna terminować kolejny...

Drugi przypadek to pado-delay z kilkoma opcjami, np. na obu koncentratorach to samo: pado-delay=0,500:500,600:700,-1:1500
Można wyczytać to w dokumentacji, ale opiszę to na podstawie własnego doświadczenia - może dla niektórych wyda się to bardziej przystępne.

Pierwszy parametr (0) oznacza ogólne opóźnienie, tu się nic nie zmienia w stosunku do pierwszej wersji (tej z jednym parametrem), jednak tutaj zostawiamy 0.
Kolejne parametry po przecinku definiują opóźnienia przy konkretnych ilościach podniesionych sesji, w takim formacie opóźnienie:ilość sesji
Czyli mamy 500:500 - oznacza to, że przy osiągnięciu 500 podniesionych sesji, koncentrator czeka 500ms z odpowiedzią (PADO) i dopiero wysyła.
Kolejny 600:700 - czyli po osiągnięciu 700 podniesionych sesji, czeka 600ms z PADO.

Na koniec -1:1500. Oznacza, że przy osiągnięciu 1500 sesji ma nie odpowiadać na żądania nawiązania nowych sesji. Warto się zastanowić ile mamy maksymalnie sesji podniesionych w sumie i ustawić taką wartość, żeby w razie padu jednego koncentratora, drugi mógł przejąć całość (jeżeli mamy dwa, lub ustawić 2/3 maksymalnej wartości jeżeli mamy np. 3, ale to już wedle uznania).

Jak to w praktyce działa ??

Do 500 sesji nie ma praktycznie opóźnień, więc maszyny obydwie odpowiadają w tym samym czasie i liczą się ułamki sekund, z którym się połączy...
Jeżeli na jednej z nich "wskoczy" te 500 sesji podniesionych, zaczyna wprowadzać 500ms opóźnienia z odpowiedzią... czyli mamy sytuację taką, że ten drugi, który jeszcze nie osiągnął 500 sesji, odpowiada szybciej, przez co z nim nawiązywana jest nowa sesja.
Jeżeli na obu osiągnięte jest po 500 sesji, sytuacja wygląda podobnie jak przed osiągnięciem 500 sesji / koncentrator - z tą różnicą, że minimalny czas odpowiedzi obu to te zdefiniowane 500ms...
I tak w kółko....

W praktyce, jak zapewne widzieliście na wykresie, który wcześniej wysłałem, rozkłada się to w miarę równo. Fajnie jest, jak ma się podobne maszyny, w innym przypadku trzeba z tymi opóźnieniami trochę inaczej kombinować...

O co na koniec należy się jeszcze zatroszczyć?

Na pewno >1 koncentrator umożliwia połączenie się tym samym loginem więcej jak 1 raz w tym samym czasie. Chyba że w konfiguracji radiusa postaramy się o to, żeby sprawdzać ile w danym momencie razy zalogowany jest dany użytkownik.
Dzieje się tak dlatego, że w accelu opcja single-session działa tylko w ramach jednego koncentratora.

Drugą sprawą o którą warto zadbać jeżeli mamy tylko jednego radiusa, to to, ile jednoczesnych połączeń może obsłużyć. Przy większej ilości koncentratorów dobrze by było, aby to nie stanowiło wąskiego gardła.

To chyba tyle... ale gdyby się zdarzyło, że czegoś nie napisałem, dajcie znać.

Na koniec dodam, że zdaję sobie sprawę z tego, że mocno się rozpisałem. Może opisane to tak jak dla laika, może zbyt łopatologicznie... więc ci bardziej PRO niech mi wybaczą :)
ale zostanie to w archiwach, dla potomnych ;)

Pozdrawiam




W dniu 11 października 2013 16:16 użytkownik Kamil Kordas <k0rdi@interblock.pl> napisał:
Możesz napisać coś więcej, jak masz ustawione delay i na jakiej zasadzie rozkladasz połączenia

"Piotrek S." <komuch@gmail.com> napisał:
Tak to wygląda mniej-więcej...


komuch@PPPoE1:~$ ps ax | grep accel

 3451 ?        Ssl  2070:18 /usr/sbin/accel-pppd -d -p /var/run/accel-pppd.pid -c /etc/accel-ppp.conf
 8341 ?        Ssl    233:45 /usr/sbin/accel-pppd -d -p /var/run/accel2-pppd.pid -c /etc/accel-ppp2.conf


W dniu 10 października 2013 13:26 użytkownik Piotrek S. <komuch@gmail.com> napisał:
Witam

Jeżeli temat nie jest "na już" - czyli możesz poczekać na efekty działania chwilę, to można zrobić to w ten sposób, że odpalasz drugiego accela na tej samej maszynie, już z nowymi ustawieniami i koniecznie słuchającego na innym porcie (MGMT), żeby się nie gryzły.

Na starym robisz shutdown soft i czekasz aż userki się porozłączają i wtedy się wyłącza proces. Nowe połączenia terminuje drugi accel... Działa to ładnie.

Ogólnie ładnie też działa rozkładanie na >=2 maszyny poprzez delay, ale to tak trochę OT

Pozdrawiam



W dniu 9 października 2013 10:10 użytkownik Marcin <marcin@nicram.net> napisał:


9 paź 2013 09:44 "Piotrek S." <komuch@gmail.com> napisał(a):


>
> Dokładnie. 
> Cześć ważnych rzeczy przeładowuje się po zabiciu procesu.
> Ja sobie z tym problemem skutecznie poradziłem, tylko wymaga trochę cierpliwości ;)
>

Powiesz coś więcej jak sobie z tym poradziłeś?


_______________________________________________
lms mailing list
lms@lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms





lms mailing list
lms@lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms

--
Wysłane za pomocą K-9 Mail.

_______________________________________________
lms mailing list
lms@lists.lms.org.pl
http://lists.lms.org.pl/mailman/listinfo/lms