Podkast 21T48 Aruba Mobility Controller 8.9.0 [Aktualizacja TFTP]

WERSJA TEKSTOWA

Cześć, witam Cię w dzisiejszym odcinku mojego podcastu – temat aktualizacja oprogramowania na kontrolerze bezprzewodowym Aruby. Mamy tutaj na myśli głównie rozwiązania duże, gdzie mamy Mobility Conductora – czyli najnowszą wersję takiego nadrzędnego kontrolera w wydaniu Aruby, i chcemy aktualizować oprogramowanie na całej grupie umieszczonej w podfolderach konfiguracyjnych kontrolerów bezprzewodowych, jeżeli chodzi o wersje 8.9 mamy możliwość zrobienia aktualizacji z poziomu Mobility Conductora. Jest to proces zautomatyzowany – możemy podać, z jakiego serwera będziemy ściągać ten plik. Tu mamy kilka opcji: serwer TFTP – historycznie popularniejszy, ja jestem zwolennikiem serwera SCP (jest taka możliwość, aby podać mu serwer SCP i pobrać dany plik). Ważne jest to, że jeżeli chcemy robić grupowo taką konfiguracje to powinien to być zewnętrzny serwer, na którym ten plik jest dostępny. Po podanym protokole.

Jeżeli chodzi o aktualizacje jednego tylko wybranego kontrolera, to można to alternatywnie wykonać z interface www, czyli można wysłać ten plik przez przeglądarkę, do urządzenia (zapisać go we flashu urządzenia) a następnie go zrestartować. Tyle tylko, że jeśli chodzi o większe instalacje, gdzie tych kontrolerów jest dużo to ten model się sprawdza w zasadzie tylko przy Mobility Conductorze. Przy wszystkich podrzędnych kontrolerach, które chcemy aktualizować, lepiej jest jednak pójść w stronę serwera plików, z którego serwujemy dla wszystkich kontrolerów, z jednego miejsca dany plik firmware’u. Możemy też oczywiście zobaczyć jakie wersje oprogramowania mamy na różnych kontrolerach, z punktu widzenia centralnej konsoli, czyli Mobility Conductora i sprawdzenia, które kontrolery powinny być zaktualizowane. Tutaj, jeśli chodzi o wersję 8.9, został rozbudowany ten mechanizm w przypadku Mobility Conductora, więc cały proces jest łatwiejszy do wykonania. Co więcej, można sprawdzać, bardziej z linii poleceń, z terminalu Mobility Conductora, jaki jest etap realizacji tego procesu. Z punktu widzenia interface www też pewne rzeczy widać. Można zauważyć np, że jest teraz etap wysyłania pliku od serwera plików, do Mobility Conductora, a jeżeli już się zrestartuje urządzenie, to w interface www widzimy, że urządzenie jest down (tu widzimy troszeczkę mniej). Natomiast z punktu widzenia linii poleceń, możemy zobaczyć jakie polecenie zostało wydane do kontrolera podrzędnego, z punktu widzenia Mobility Conductora, tak, żeby wykonać tą aktualizację.

Jak zwykle, mamy trochę więcej szczegółów z linii poleceń, główne informacje mamy w interface www, więc w zależności od tego, co potrzebujemy i czym się czujemy lepiej, możemy jeden lub drugi interface wykorzystać. Jeżeli chodzi o cały proces aktualizacji, to oczywiście on wymaga restartu. Najpierw trzeba ten plik wysłać na flash danego urządzenia a następnie urządzenie zrestartować, żeby mogło się uruchomić z daną wersją oprogramowania.

Opowiem kilka słów o bezprzerwowym upgrade, bo jest to ciekawa rzecz. Jeżeli mamy klaster kontrolerów, zarządzany przez Mobility Conductora i chcemy wykonać bezprzerwowy upgrade to wystarczy, że albo użyjemy funkcji live upgrade, albo będziemy wybierać ręcznie urządzenia do aktualizacji w tym klastrze, tak, żeby zapewnić odpowiednią spójność świadczenia usługi. Tu jest jedna rzecz do przemyślenia, zanim się rozpocznie taki upgrade, z założeniem, że on będzie bezprzerwowy, musi być odpowiednio zaplanowana sieć radiowa. Jeśli aktualizujemy oprogramowanie na kontrolerze, to oznacza, że muszą być również zaktualizowane wszystkie punkty dostępowe, które z tym kontrolerem współpracują. Przypomnę, że podstawowym założeniem, jest to, że punkt dostępowy musi mieć odpowiedni poziom firmware’u, który jest zainstalowany na Mobility Controllerze. Czyli, jeśli aktualizujemy Mobility Controller, to automatycznie musi być też firmware na wszystkich access pointach zaktualizowany. Jeżeli mamy tą sieć dużą, mamy tych kontrolerów sporo i jeszcze do tego mamy dużo access pointów i chcemy to zrobić bezprzerwowo, to w zasadzie tylko procesem live-upgrade możemy to zrobić. Ponieważ jest kwestia, jak będą przełączane punkty dostępowe pomiędzy członkami klastra, tak, żeby zapewnić spójność działania, przy czym nie da się pojedynczego punktu dostępowego zaktualizować bezprzerwowo. W związku z tym całe planowanie radiowe powinno być wykonane tak, aby jeżeli restartujemy daną grupę punktów dostępowych, to inne punkty dostępowe, które są w danym obszarze powinny pokrywać radiowo daną przestrzeń. Czyli jeżeli chciałbyś wykonywać bezprzerwowy upgrade, masz taką sytuację, to musisz zaplanować odpowiednio więcej access pointów i trzeba je zaplanować gęściej. To jest aspekt ekonomiczny, który się tutaj pojawia, warto go brać pod uwagę, jeżeli chodzi o wersje aktualizacji.

Jeżeli masz do tego jakieś pytania to oczywiście pisz w komentarzu. Konfiguracje będziesz mógł obejrzeć w poniedziałkowym odcinku, zobaczysz jak to wykonać na Mobility Conductorze i Mobility Controllerze. Dziękuję Ci za dziś i do usłyszenia już za tydzień.