Więcej

    Wstęp do architektury ArubaOS w wersji 8.x

    Przeglądając ostatnie raporty Gartnera dotyczące sieci WLAN można zauważyć, że dookoła Cisco kręci się jeszcze jeden potężny gracz w prawej górnej ćwiartce magicznego kwadrantu. Mowa tu o firmie Aruba, czyli spółce od kilku już lat zależnej od Hewlett Packard Enterprise (HPE). Aruba wychodzi naprzeciw oczekiwaniom współczesnych sieci bezprzewodowych Wi-Fi promując architekturę Mobile First oraz oprogramowanie ArubaOS w wersji 8. Jak wygląda ten koncept? Przyjrzyjmy mu się nieco bliżej.

    Punkt wyjścia – ArubaOS 6

    Kontrolery sieci WLAN i zarządzane z ich poziomu Access Pointy korzystają z systemu operacyjnego o nazwie ArubaOS. System ten ewoluował i kształtował się przez lata przybierając obecną formę w postaci wersji 8. Zanim jednak zajmiemy się teraźniejszością, za konieczne uważam spojrzeć nieco w przeszłość – ArubaOS 6 to poprzednik obecnej wersji. Koncept zmienił się diametralnie i w zasadzie odchodzi się już od wersji 6, jednakże wyjaśnienie zmian będzie dużo łatwiejsze znając poprzednie podejście i wskazując na istotne nowości.

    Tryby działania kontrolera z ArubaOS 6

    Nie zagłębiając się w szczegóły i konkretne podwersje oprogramowania można powiedzieć, że generalnie ArubaOS 6 oferuje cztery tryby działania kontrolera sieci WLAN. Ma to oczywiście wpływ na cały koncept architektury sieci WLAN, ale o tym za chwilę. Zacznijmy od wspomnianych już trybów działania.

    Master Mode

    Kontroler działający w tym trybie można nazwać głównodowodzącym urządzeniem w sieci WLAN. Administrator konfigurując kontroler w trybie Master powinien zadbać o wykonanie na nim wszelkiej potrzebnej konfiguracji. Mam tu na myśli przede wszystkim lokalne ustawienia dotyczące typowo tego kontrolera, jak np. adresacja IP, VLAN-y i konfiguracja fizycznych portów, ale także bardziej globalne wytyczne dotyczące sieci WLAN, grup Access Pointów, ról możliwych do przypisania klientom sieci Wi-Fi i tym podobne.

    Poniższy rysunek przedstawia Master kontroler, który całkowicie musi być skonfigurowany przez Administratora sieci.

    Administrator musi samodzielnie wykonać konfigurację Master kontrolera, źródło: arubanetworks.com
    Administrator musi samodzielnie wykonać konfigurację Master kontrolera, źródło: arubanetworks.com

    Master kontroler jest kluczowym elementem sieci WLAN, ponieważ może on częściowo zarządzać innym kontrolerem działającym w trybie Local, jak i w pełni dbać o konfigurację innego kontrolera działającego w trybie Branch. W tym miejscu warto zaznaczyć, że istnieją pewne ograniczenia dotyczące wykorzystywanego modelu sprzętu. Po wytyczne dotyczące konkretnego kontrolera odsyłam Cię do oficjalnej dokumentacji producenta.

    Local Mode

    Podobnie do kontrolera w trybie Master, na kontrolerze w trybie Local również trzeba przeprowadzić konfigurację lokalnych ustawień dotyczących adresacji IP, VLAN-ów i fizycznych portów. Jednakże pozostała część ustawień zwana konfiguracją globalną jest dziedziczona z nadrzędnego urządzenia, czyli kontrolera działającego w trybie Master. Co ważne, nawet po otrzymaniu konfiguracji globalnej nie ma możliwości jej zmiany na kontrolerze typu Local – te elementy w GUI są po prostu wyszarzone. Wszelkie rekonfiguracje sieci WLAN, grup Access Pointów itp. muszą być wykonywane z poziomu Master kontrolera.

    Poniższy rysunek przedstawia proces konfiguracji Local kontrolera. Część konfiguracji dostarczona jest przez Mastera jako tak zwane ustawienia globalne. Pozostała część musi być skonfigurowana przez Administratora bezpośrednio na Local kontrolerze.

    Kontroler w trybie Local otrzymuje konfigurację z dwóch odrębnych źródeł, źródło: arubanetworks.com
    Kontroler w trybie Local otrzymuje konfigurację z dwóch odrębnych źródeł, źródło: arubanetworks.com

    Branch Mode

    Rozwiązanie typu Branch dedykowane jest dla zdalnych biur i oddziałów firmy. Tryb Branch jest domyślnym trybem i w odróżnieniu od poprzednich opcji taki kontroler nie wymaga żadnej prekonfiguracji. Dwa podstawowe i zarazem kluczowe elementy ustawień mogą być uzyskane automatycznie. Przede wszystkim jest to własny adres IP, który może być uzyskany poprzez domyślnie włączoną funkcjonalność klienta DHCP. W drugim kroku wymagane jest pozyskanie adresu IP Master kontrolera. Można tego dokonać poprzez opcję DHCP numer 43, a także poprzez proces Zero Touch Provisioning (ZTP).

    Poniższy rysunek przedstawia proces konfiguracji kontrolera w trybie Branch, któremu całą konfigurację przekazuje Master kontroler.

    Kontroler w trybie Branch jest całkowicie konfigurowany z poziomu Master kontrolera, źródło: arubanetworks.com
    Kontroler w trybie Branch jest całkowicie konfigurowany z poziomu Master kontrolera, źródło: arubanetworks.com

    Kontroler działający w trybie Branch otrzymuje pełną konfiguracje od Master kontrolera i przez niego jest też zarządzany. Wykonywanie zmian bezpośrednio na kontrolerze Branch jest zablokowane. Ponownie występują pewne ograniczenia dotyczące modelu sprzętu, ale tym razem także i wersji oprogramowania. Po wytyczne dotyczące konkretnego kontrolera odsyłam Cię do oficjalnej dokumentacji producenta.

    Standalone

    Kontrolery działające w trybie Standalone posiadają prawie wszystkie cechy i funkcjonalności kontrolerów Master, z tą potężną różnicą, że nie posiadają możliwości wdrożenia redundancji sprzętowej. Mówiąc wprost, kontrolery Standalone działają pojedynczo, nie są zarządzane z poziomu Mastera i jednocześnie same nie mogą nawiązać interakcji z kontrolerami w trybach Local i Branch. Z tego też powodu jest to wdrożenie raczej rzadko spotykane.

    Poniższy rysunek przedstawia Standalone kontroler, który całkowicie musi być skonfigurowany przez Administratora sieci.

    Administrator musi samodzielnie wykonać konfigurację Standalone kontrolera, źródło: arubanetworks.com
    Administrator musi samodzielnie wykonać konfigurację Standalone kontrolera, źródło: arubanetworks.com

    Architektura ArubaOS 6

    Typowe wdrożenie sieci WLAN rekomendowane przez Arubę składa się z dwóch kontrolerów działających w trybie Master, które zlokalizowane są w głównej lokacji i spięte są protokołem VRRP w celu otrzymania modelu Master-Standby. Redundancja głównego elementu sieci, czyli Master kontrolera, jest niezwykle istotna.

    Dodatkowo Master kontrolery zarządzają wieloma innymi kontrolerami działającymi zarówno w trybie Local, jak i Branch. Warto też nadmienić, że Access Pointy mogą być zaczepione na każdym rodzaju kontrolera spośród przedstawionych dotychczas.

    Poniższy rysunek przedstawia przykładowe wdrożenie zgodne z ArubaOS 6, z użyciem dwóch Master kontrolerów, kilku kontrolerów w trybie Local podłączonych na tej samej lokacji, a także Branch kontrolera umieszczonego w zdalnym biurze.

    Przykład architektury ArubaOS 6, źródło: arubanetworks.com
    Przykład architektury ArubaOS 6, źródło: arubanetworks.com

    ArubaOS 8 – czas na solidne zmiany

    Zgodnie z definicją wspomniana już architektura Mobile First zakłada nieskrępowany dostęp użytkowników i rzeczy (tak, dział sprzedaży wciśnie teraz określenie IoT w co drugie zdanie 🙂 ) do sieci i otrzymanie tych samych uprawnień niezależnie od rodzaju medium dostępowego, czyniąc ten dostęp prawdziwie mobilnym. Oczywiście sieć zgodna z tym konceptem musi być też bezpieczna i nastawiona na automatyzację. W parze z Mobile First idzie oprogramowanie ArubaOS 8, które diametralnie zmienia architekturę w porównaniu do przedstawionych założeń z wersji 6.

    Tryby działania kontrolera z ArubaOS 8

    Pierwsza poważna zmiana dotyczy trybów działania jakie są dostępne dla kontrolerów z zainstalowanym oprogramowaniem ArubaOS 8. Nie licząc trybu przejściowego, do którego wrócimy kiedyś przy okazji omawiania migracji pomiędzy obiema architekturami, ArubaOS 8 oferuje trzy możliwości.

    Mobility Master

    To jeden z nowych elementów w sieci, które oferuje ArubaOS 8. Podobnie do Master kontrolera z ArubaOS 6, Mobility Master (MM) pełni rolę głównodowodzącego urządzenia w sieci WLAN i jego pełna konfiguracja musi być wykonana przez Administratora. Stawiane są jednak przed nim trochę inne priorytety. Do zadań Mobility Mastera należy przede wszystkim udostępnianie centralnego punktu zarządzania konfiguracją i oprogramowaniem w całej sieci WLAN. Do tego dochodzą też skomplikowane obliczenia, których wynikiem jest pełny plan zagospodarowania przestrzeni radiowej. Dzięki temu każdy Access Point w sieci wie, jaki kanał i jaka moc transmisji będą dla niego najlepsze.

    W związku z tak dużą odpowiedzialnością i potężnym już przydziałem zadań Mobility Master nie terminuje Access Pointów. To oznacza dokładnie tyle, że Access Pointy nie mogą być podpinane do MM i potrzebują do tego innego kontrolera, działającego w innym trybie.

    MM dostępny jest w dwóch wariantach wdrożeniowych – jako dedykowany sprzęt oznaczany skrótem MM-Hardware (MM-HW), a także jako maszyna wirtualna MM-Virtual Appliance (MM-VA). Niezależnie od wybranego podejścia możliwości i funkcjonalności są takie same.

    Poniższy rysunek przedstawia MM, który całkowicie musi być skonfigurowany przez Administratora sieci.

    MM musi być całkowicie skonfigurowany przez Administratora sieci, źródło: arubanetworks.com
    MM musi być całkowicie skonfigurowany przez Administratora sieci, źródło: arubanetworks.com

    Mobility Controller

    Mobility Controler (MC) to kolejna nowość, która może przypominać połączenie trybów Local i Branch znanych z ArubaOS 6. Mianowicie, MC jest całkowicie zarządzany z poziomu Mobility Mastera. Co ważne, każdy element konfiguracji wliczając w to ustawienia adresacji IP, VLAN-ów i fizycznych portów, musi być ustawiony z poziomu MM. Mobility Controller staje się zatem w pewnym znaczeniu urządzeniem pasywnym, do którego można podłączać Access Pointy i którego zadaniem jest między innymi przekierowywanie danych z AP do MM oraz przełączanie ruchu użytkowników bezprzewodowych.

    Podobnie do MM, MC dostępny jest w dwóch wariantach – sprzętowym (MC) oraz w postaci maszyny wirtualnej Virtual Mobility Controller (VMC). Dodatkowo MC może być skonfigurowany jako koncentrator tunelów VPN. Dzięki temu może pełnić rolę bramy domyślnej dla tunelów VPN chociażby z Access Pointów Aruba.

    Poniższy rysunek przedstawia Mobility Controller, który może być całkowicie skonfigurowany z poziomu MM, zarówno fizycznego jak i wirtualnego w zależności od wdrożenia.

    MC jest całkowicie konfigurowany z poziomu MM, źródło: arubanetworks.com
    MC jest całkowicie konfigurowany z poziomu MM, źródło: arubanetworks.com

    Standalone

    Tryb standalone jest w zasadzie kopią trybu o tej samej nazwie z ArubaOS 6. Jest to pojedynczy kontroler, który nie może być zarządzany z poziomu MM. Nie może być też łączony z urządzeniami MC. Dodatkowo traci prawie wszystkie nowe funkcjonalności wdrożone wraz z systemem ArubaOS 8. To wszystko sprawia, że jest to wybór naprawdę ostateczny i powinien być stosowany tylko w skrajnych przypadkach.

    Poniższy rysunek przedstawia Standalone kontroler, który musi być całkowicie skonfigurowany przez Administratora sieci.

    Standalone kontroler musi być całkowicie skonfigurowany przez Administratora sieci, źródło: arubanetworks.com
    Standalone kontroler musi być całkowicie skonfigurowany przez Administratora sieci, źródło: arubanetworks.com

    Architektura ArubaOS 8

    Typowe wdrożenie sieci WLAN rekomendowane przez Arubę składa się z dwóch urządzeń Mobility Master, które powinny być umieszczone w środowisku z dostępnością na poziomie stu procent, np. w Data Center. Jak już wspomniałem są to najważniejsze urządzenia w całej sieci WLAN i muszą być stale osiągalne dla pozostałych części sieci. Dodatkowo w celu uzyskania redundancji sprzętowej MM powinny być spięte protokołem VRRP dla otrzymania modelu Master-Standby.

    Oprócz MM potrzebne są też MC, które będą terminować Access Pointy. Mobility Controllery mogą być zainstalowane w okolicach MM, ale równie dobrze mogą też działać na odległych lokacjach i być w pobliżu obsługiwanych Access Pointów. MC również powinny posiadać redundancję, dlatego należy je instalować w liczbie co najmniej dwóch tworząc tak zwany klaster.

    Poniższy rysunek przedstawia przykładowe wdrożenie ArubaOS 8, które składa się z dwóch Mobility Masterów oraz kilku Mobility Controllerów umieszczonych zarówno lokalnie, jak i w zdalnym biurze.

    Przykład architektury ArubaOS 8, źródło: arubanetworks.com
    Przykład architektury ArubaOS 8, źródło: arubanetworks.com

    Zestawienie końcowe

    Nie może zabraknąć zwięzłego podsumowania obu architektur. Poniższa tabela przedstawia tryby działania kontrolerów w wersji ArubaOS 6 oraz odpowiadające im urządzenia ze świata ArubaOS 8.

    Porównanie kontrolerów w ArubaOS 6 i ArubaOS 8
    Porównanie kontrolerów w ArubaOS 6 i ArubaOS 8

    A poniżej znajdziesz najważniejsze różnice w działaniu i funkcjonalnościach przedstawionych rodzajów wdrożeń:

    • Master kontroler (ArubaOS 6) może częściowo zarządzać kontrolerami działającymi w trybie Local oraz w pełni zarządzać kontrolerami w trybie Branch.
    • Mobility Master (ArubaOS 8) zarządza całą konfiguracją spiętych z nim Mobility Controllerów.
    • W ArubaOS 6 Access Pointy mogą być zaterminowane zarówno na kontrolerze Master, jak i Local oraz Branch.
    • W ArubaOS 8 Access Pointy nie mogą być zaczepiane na Mobility Masterze, mogą być natomiast na Mobility Controllerze.
    • W obu architekturach kontroler Standalone działa w taki sam sposób i można do niego podłączać Access Pointy.

    Koncept architektury w systemie ArubaOS 8 jest bardzo ciekawy i przede wszystkim dobrze skalowalny. Będzie on zatem odpowiedni zarówno dla małych wdrożeń, jak i wielkich sieci obejmujących setki oddziałów na całym świecie. Co ważne, rozwiązanie pachnie nowością. Centralizacja zarządzania, znacznie poprawione mechanizmy i algorytmy zarządzania RF, ogólnie masa nowości w porównaniu do poprzedniej wersji.

    A co jeszcze ważniejsze, wstęp do architektury ArubaOS 8 to dopiero początek cyklu artykułów o tej tematyce. Przyjrzymy się bliżej każdemu zakątkowi architektury i poszczególnym funkcjonalnościom. Nie zabraknie też elementów konfiguracji. Będzie się działo!

    Co sądzisz o modelu architektury zaproponowanym w ArubaOS 8? Które elementy są Twoim zdaniem najważniejsze z punktu widzenia Administratora takiej sieci?

    🗳 Jak przydatna była ta publikacja?

    Średnia ocena 5 / 5. Ilość głosów: 2

    Brak ocen. Bądź pierwszy!

    Dziękujemy za ocenę! Zapraszamy Cię do obserwowania NSS w mediach społecznościowych!

    Przykro nam, że ta publikacja okazała się być dla Ciebie nieprzydatna!

    Uwaga: Twój głos będzie liczony tylko jeśli udzielisz feedbacku używając formularza poniżej.

    Jak możemy poprawić tę publikację?

    Łukasz Kowalski
    Network Architect, Współtwórca Na Styku Sieci

    2 KOMENTARZE

    guest
    2 - Ilość komentarzy
    Sortuj wg najstarszych
    Sortuj wg najnowszych Sortuj wg najlepszych
    Inline Feedbacks
    View all comments
    Patryk

    Dobry artykuł, ale to zaledwie skrawek góry lodowej, czekam na więcej i obszerniej 🙂

    Przygotowujesz się do certyfikacji CCNA?

    Zapisz się na nasz NSSletter, a co tydzień we wtorek rano otrzymasz porcję sieciowej wiedzy oraz porady dotyczące certyfikacji.

    Uzupełniając powyższe pole wyrażasz zgodę na otrzymywanie od GetGoodNet Damian Michalak z siedzibą we Wrocławiu newslettera zawierającego treści edukacyjne. Zgodę możesz wycofać w każdym czasie.

    NSS na Social Media

    1,611FaniLubię
    72ObserwującyObserwuj
    133ObserwującyObserwuj
    1,220SubskrybującySubskrybuj

    Najnowsze artykuły

    spot_img

    Może Cię też zainteresować...

    2
    0
    Co sądzisz na temat tej publikacji? Zostaw proszę komentarzx
    ()
    x