Ich habe mir im Vorgriff auf die Installation von meinen ersten ubnt-Richtfunkern mal einen lxc mit dem unifi controller aufgesetzt. (proxmox 4.4, debian9 im lxc)
Nach dem ersten Start flog mir allerdings sprichwörtlich das Blech weg, da dieses kleine Biest mal eben mehr als 600(!!!) Java threads spawned.
Jetzt ist mir durchaus klar, das bei richtigen large scale Setups mit mehreren 100 Devices etwas mehr Speck an den Controller muss, da mit die Meldungen der Geräte auch verarbeitet werden können. Aber das mus doch für kleine Mickey-Mouse-Setups auch etwas schlanker machbar sein.
I.d. ubiquity-community gibt es dazu zwar auch ein paar Meldungen, aber gelöst ist das Problem doch scheinbar nicht.
Ich habe bereits die i.d. Dokumentation erwähnten Parameter nach unten frisiert, jedoch ohne nennenswerten Erfolg beim thread count.
Für die Ubnt Richtfunkkomponenten (AirMax Serie) benötigst du keinen Controller da die Konfiguration lokal im Webinterface des jeweiligen Gerätes erfolgt.
Zum zentralen Monitoring und FW-Upgrade kannst du dann AirControl 2 nutzen.
Der UniFi Controller ist nur für die UniFi Produktlinie zuständig.
Beide Produktlinien lassen sich ggf später mal per UNMS zentral verwalten, UNMS ist aber noch mitten in der Entwicklung.
Egal was Du tust, LXC-container machen keinen Spass, zumindest nicht unter Proxmox.
Irgendwas im Container läuft Amok, hat Speicherleck (passiert in LXC selbst einem eigentlich rock-solid squid) etc… und der Wirtskernel und damit das ganze Blech gerät ins Taumeln.
Meiner Meinung nach ist entweder LXC inzwischen unbrauchbar (warum auch immer) oder die Einbindung in Proxmox ist seit etwas 2 Jahren buggy.
Mach eine echte (KVM-)VM und das Problem ist gelöst.
Oder anders: Suche die Schuld nicht beim Unifi-Controller. Der kann vermutlich nix dafür.
Ich habe drei Unifi-controller unter Promox zu laufen, als Debian-VM (kvm, wie beschrieben).
Einer hängt per IP-routing (und vlan-tagging) in einer privaten Installation.
Einer hängt per IP-client hinter einem Mapserver (auf dem gleichen Proxmox) für ffdus/Flingern
Einer hängt mit zwei batman-instanzen simultan inzwei verschwiedenen Freifunk-L2-Domains (Neanderfunk Wülfrath und Neanderfunk LVR)
Richtig viele Radios hängen da nicht dahinter, aber ich vermag zu sagen, dass es rock solid läuft.
Wichtig ist in jedem Fall, das man dem/den DHCP-Servern die Optionen mitgibt, dass die neuen Radios ihren Controller auch finden und nicht endlos im ganzen Netzsegment herumscannen.
Ach ja, was die Threads angebt: Diese monodb+tomcat(?) ist schlimm, aber ich habe den VMs nur einen Kern und 1024MB RAM gegeben. Dann schlagen die an einen natürlich Deckel. Vermutlich ginge sogar noch weniger. Es passiert ja nichts, was wirklich zeitkritisch wäre.
In der Tat, mein Container hat auch gewaltige Mengen an Java Threads, läuft aber im LXC Container problemlos.
Ist aber Manuell mit lxc-create und lxc-start gemacht und mir ist nicht aufgefallen, dass hier plötzlich viel mehr Last auf der Kiste ist. In den Statistiken sieht man in KW04 als ich den Controller aufgesetzt und gestartet auch mächtig die Threads steigen:
Load, RAM und CPU sind jetzt aber nicht wirklich verändert:
(Was da im laufe der letzten Woche in den Swap gewandert sollte ich wohl mal schauen)
Dann brauche ich den Controller also erst für einen Unifi-AP, macht ja auch Sinn.
Die Lxcs laufen ansonsten völlig anstandslos, da gibt’s keine Probleme. Bestenfalls das Monitoring ist das des shared-memory etwas hackelig.
Und zu guter letzt kann man auf Maltes Monitoring den Threadcount genauso nachvollziehen.
Es gab hier auch keinerlei echte Probleme beim Betrieb auf meinem hypervisor. Lediglich das threadmeter im Monitoring ging nach start des Controllers auf warning. Ohne unifi liefen 1100threads auf dem Host (5 Lxcs, 4 vms) und mit unifi waren es Mal eben 2000(!).
Das wäre auch mit einem Shift der Parameter wegzufrickeln gewesen. Auch wenn sich alles in mir dagegen sträubt, ne kleine Java-webapp 1000threads rumidlen zu lassen, wird das ggf. Erstmal die Lösung sein müssen.
