Unifi Network Application i brak miejsca na dysku

Administruję 40-kilkoma access pointami Ubiquiti Unifi rozmieszczonymi w 20 lokalizacjach (20 odrębnych sieci WiFi). Całość jest zarządzana z poziomu kontrolera Unifi Network Application zainstalowanego na Debianie. Sam kontroler działa dokładnie od 19 listopada 2015 i jest cyklicznie aktualizowany. Prócz mniejszych i większych problemów (jak to z Ubiquiti) pojawił się jeden, któremu postanowiłem bliżej się przyjrzeć.

Unifi Network Application nie działa

Wspomniany wyżej problem, to brak działania. Nie można wejść na stronę www aplikacji. Szybki rzut okiem na maszynę wirtualną z linuksem, na której jest zainstalowany kontroler i maszyna działa, ale nie można się do niej zalogować (ssh). Powód? – prozaiczny – brak miejsca na dysku. Na szybko wyłączyłem maszynę, zamontowałem obraz iso z narzędziami do partycjonowania dysków (GParted) jako wirtualny cd-rom. Uruchomiłem maszynę z bootowaniem z cd-romu, powiększyłem dysk dla Debiana na którym działa kontroler i restart. Wszystko zadziałało, można się zalogować do kontrolera. Profilaktycznie zrobiłem aktualizację systemu, usunięcie starych pakietów i bez głębszego wnikania uznałem temat za zamknięty.

Problem niestety powrócił po około 2 latach. Tym razem dysk był prawie pełny i wszystko jeszcze funkcjonowało prawidłowo. Tym razem zajrzałem głębiej, by znaleźć przyczynę.

Kontroler Unifi na linuksie i brak miejsca dysku

Naturalnym krokiem były poszukiwania co zajmuje aż tyle miejsca. Standardowo w linuksie (tu Debian) w shellu polecenie:

df -h

Co dało wynik:

No i widzę, że partycja z systemem plików (/dev/sda1), która ma 24GB jest zajęta w 87%. Sprawdzam dalej, najpierw przechodzę do z katalogu domowego do głównego:

cd /

i wyświetlenie zawartości z rozmiarem:

du -sh *

Problem leży w katalogu /var który zajmuje aż 17GB. Wchodzę głębiej (podejrzewam, że sterta danych leży w katalogu unifi):

cd /var/lib/unifi

I znowu sprawdzam zajętość:

du -sh *

No i folder db z bazą zajmuje 14GB. Wiem na pewno, że nie potrzebuję danych aż o takim rozmiarze. Szukam więc możliwości odchudzenia bazy.

mongo_prune_js lekiem na rozmiar bazy w Unifi Controller

Kilka minut z googlami dało rozwiązanie problemu olbrzymiej (jak na moje potrzeby) bazy danych Unifi Network Application. Na stronie https://help.ui.com/hc/en-us/articles/204911424-UniFi-How-to-Remove-Prune-Older-Data-and-Adjust-Mongo-Database-Size jest opisana procedura przycięcia bazy z zachowaniem zdarzeń z określonej liczby dni. Na początek trzeba pobrać skrypt, najlepiej do katalogu domowego:

curl -k0 https://help.ui.com/hc/article_attachments/115024095828/mongo_prune_js.js

Obecnie artykuł jak i skrypt nie są dostępne na stronach ubiquiti, można go pobrać tutaj: >> mongo_prune_js.zip <<.

Skrypt standardowo wykonuje próbę (nie usuwa danych) ze zdarzeniami starszymi niż 7 dni. Uruchomienie wygląda tak:

mongo --port 27117 < mongo_prune_js.js

Sam test (próba) nie rozwiąże problemu. 7 dni to trochę krótko. Edytując skrypt zmieniam zmienną days z 7 na 365 i dryrun z true na false:

Czyli usuwamy dane starsze niż 365 dni i nie robimy próby, tylko tniemy na serio. U mnie Unifi Controller to maszyna wirtualna na vmware, więc przed spruciem danych, zrobiłem sobie klon maszyny, żeby mieć do czego wracać w przypadku rozsypania się bazy. Odpalenie zmodyfikowanego skryptu:

I teraz tak wygląda zajętość miejsca:

Ślicznie. 4,6GB wygląda dużo lepiej od 14GB.

Podsumowanie

Po siedmiu latach administrowania kontrolerem Unifi z kilkudziesięcioma urządzeniami, miałem kilka takich przygód jak wyżej. Jedyny plus taki, że awaria kontrolera nie stopowała działania sieci WiFi. Na szczęście forum użytkowników, które udostępnia Ubiquiti jest dość obszerne, wiele przypadków się powtarza i dość łatwo znaleźć rozwiązanie problemu.

Dla mnie skrypt mongo_prune_js stał się jednym z podstawowych narzędzi w administrowaniu kontrolerem Unifi :). Oczyszczenie bazy z 10GB zbędnych danych piechotą nie chodzi :).