Założenia i opis projektu abcc

Projekt abcc składa się z demona, napisanego w Pythonie, który czyta plik konfiguracyjny, a następnie na podstawie jego zawartości dokonuje cyklicznej kontroli jakości dostępnych łącz względem określonych w konfiguracji IP docelowych. Przeprowadzane operacje zapisywane są do logu (syslog?), podobnie jak oceny poszczególnych łącz.

Zakładam wykorzystanie Pythona w wersji 3, przestrzeganie PEP8 i programowanie funkcyjne. Całość ma być możliwie prosta koncepcyjnie i możliwie konfigurowalna przy pomocy pliku konfiguracyjnego za pomocą wag poszczególnych wskaźników, wag IP. Rozwiązanie ma też zapewniać użytkownikowi pełną przejrzystość działania, wybór poziomu logowania i możliwość uruchomienia w wersji „na sucho”, w celu przetestowania, jak uruchomienie z daną konfiguracją wpłynęłoby na zmiany routingu.

Aby to osiągnąć, zmienia na czas pomiaru routing do docelowych IP na dane łącze, dokonuje pomiaru jakości łącza, a następnie, po zebraniu danych dla wszystkich łącz, określa, które z nich jest najlepsze i – jeśli zachodzi taka potrzeba, dokonuje zmiany routingu.

Do zmiany routingu wykorzystywane są zewnętrzne skrypty bashowe – pozwala to na dostosowanie działania demona do różnych platform i potrzeb – np. dodanie zmiany NATowanaia, wywołanie zmian na zdalnym systemie (router sprzętowy) – bez zmian w samym silniku.

Teoretycznie można by to napisać w czystym Bashu i wywoływać z crona, ale po pierwsze, chcę potrenować Pythona, po drugie tak będzie łatwiej, bardziej elegancko i będzie otwarta droga np. do zwiększenia częstotliwości próbkowania przez zrównoleglenie pomiarów.

Z racji wymogów konkursowych dotyczących ilości postów, tworzenie projektu będzie trochę przegadane, i spowolnione, przynajmniej na początku. Zaleta jest taka, że będzie lepiej widać sposób rozumowania, gdyby ktoś chciał coś skomentować lub się przyłączyć. Commity kodu i dokumentacji będą się pojawiały w miarę równolegle z wpisami na blogu, pierwszy właśnie poszedł.

Geneza, nazwa i zastosowania

Projekt, który mam zamiar zrealizować w ramach DSP2017 nazywa się abcc (Automatic Best Connection Chooser). Pierwotnie miał się nazywać abpppcc i działać dla połączeń PPP, ale w sumie nie ma to sensu. Pomysł narodził się, gdy kiedyś znajomy z FB napisał, że jest w drodze, ma 2 czy 3 połączenia GSM i przełącza się między nimi, bo raz lepiej działa to, raz tamto. Oczywiście przełącza się ręcznie.

Stwierdziłem, że gdyby miał Linuksa, to uruchomienie wszystkich naraz, sprawdzanie automatem i przełączanie ruchu na najlepsze nie powinno być trudne. Sprawę wstępnie przemyślałem, zacząłem nawet zabawę z dwoma modemami GSM, ale wkrótce pojawiły się ważniejsze sprawy i projekt trafił do szuflady. Znaczy na dysk. Nawet nie tyle projekt, co krótko spisane wstępne założenia i wymyślona nazwa.

Potem stwierdziłem, że rozwiązanie można zastosować też w innych okolicznościach, nie tylko przy laptopie w podróży. Może służyć do przełączania ruchu na łącze zapasowe w przypadku sieci i routera na Linuksie i pogorszeniu parametrów łącza podstawowego, a nawet… do sterowania ruchem operatorskim.

W tym ostatnim zastosowaniu oczywiste jest podobieństwo do rozwiązania firmy Border6 omówionego na PLNOG13, przy czym to co zamierzam napisać jest o wiele bardziej prymitywne, więc mam nadzieję, że klientów nie odbierze. Choć IMO ma szansę być opensource’ową namiastką.

5 powodów do udziału w DSP2017

Nie jestem programistą i nie jest to blog programistyczny[1]. Czemu więc dołączyłem do konkursu Daj Się Poznać 2017?

  • Po pierwsze, uważam, że to świetna inicjatywa, dobra zabawa i doskonały motywator.
  • Po drugie, zawsze lubiłem konkursy programistyczne typu Potyczki Alogrytmiczne.
  • Po trzecie, uważam, że administrator powinien znać przynajmniej podstawy programowania, nawet jeśli nie udziela się programistycznie w większych projektach. Zresztą, devops (modne słowo) way to konfiguracja jako kod i bez przynajmniej podstaw jest… ciężko. Jeśli w ogóle się da. 😉
  • Po czwarte, ostatnio spodobał mi się Python i jest okazja, żeby poćwiczyć.
  • Po piąte, mam pomysł na mały projekt, który trafił do szuflady (czytaj: na dysk) i DSP2017 jest świetną okazją, żeby go zmaterializować. Jak to ładnie ktoś ujął „wizja bez implementacji to halucynacja”.

Największy problem sprawiła mi… platforma bloga czyli sam Blox. Wymogiem uczestnictwa w DSP2017 jest podanie kanału RSS, na którym będą pojawiały się wpisy konkursowe. I tylko one. Niestety, nic takiego tu nie istnieje, przynajmniej nie w nowym szablonie. Zgłosiłem to na forum, mają sprawdzać, ale złudzeń nie mam – muszę radzić sobie sam. Jest plan, szczegóły jutro.

Konkursem zainteresowałem się bliżej 28. lutego i powyższy problem sprawił, że pierwotnie odpuściłem, na szczęście zapisy do DSP2017 zostały przedłużone do 12. marca, więc podobnie jak ja macie jeszcze szansę zdążyć się zarejestrować.

Do całości podchodzę luźno – ma to być głównie motywator do materializacji projektu i okazja do poćwiczenia Pythona. Biorąc pod uwagę ilość wpisów na blogu, głównym problemem mogą być same dwa wpisy tygodniowo, a szczególnie ten drugi, niekoniecznie związany z projektem. A jeszcze trzeba sam projekt realizować… Niemniej, trzeba próbować. 🙂

[1] Mam nadzieję, że to wyznanie nie spowoduje dyskwalifikacji. Postaram się spełnić wymagania konkursowe.