Od dłuższego czasu zajmuje się NSX-v, ale stwierdziłem, że czas poznać wersję multi platform NSX-T. Gdy grudniu 2017 pojawiła się wersja 2.1 można powiedzieć, że wersja już jest w miarę wygrzana. Poczułem, że przyszedł czas aby rozwiązanie to pojawiło się w mym labie. Ten wpis otwiera serię wpisów na temat NSX-t, poniżej plan działania przy poznawaniu tego rozwiązania.
Plan Działania
Poniżej plan działania oraz odnośniki wcześniejszych wpisów o NSX-T.
- Instalacja NSX Managera
- Instalacja NSX-t Controller
- podłączenie ich do NSX Mangera
- utworzenie klastra
- dodanie pozostałym NSX Controllerów do klastra
- Instalacje NSX Edge
- dodanie do NSX Managera
- dodanie workloadu do NSX Managera
- vCenter
- instalacja modułów NSX-t na hostach
- Konfiguracja NSX-t Transport Node i Transport Zone
- IP pool
- Uplink profile
- Transport zone
- Transport node
- Edge cluster
- switche
- Utworzenie połączenie ze światem (NSX-t Routing)
- architektura
- utworzenie routera Tier 0
- utworzenie routera Tier 1
- Konfiguracja redystrybucji sieci z Tier 1 do Tier 0
- Konfiguracja BGP
- Konfiguracja redystrybucji routingu z Tier 0 w kierunku świata
- Weryfikacja od strony NSX-t
- Weryfikacja od strony Hosta
- Load Balancer
- …
Wstęp
W ramach wstępu opiszę różnice pomiędzy wersjami NSX-t a NSX-v, skupiając się na NSX-t
- nie potrzebujemy do działania NSX-t vCenter, rozwiązanie działa niezależnie, możemy połączyć się do vCenter, ale tylko po to aby dostać się do hostów które będą realizowały workload
- multipatform, managera możemy uruchomić na vSphere i jak na KVM, Edge możemy uruchomić na serwerze fizycznym
- Wsparcie dla KVM na Ubuntu i RedHat
- interfejs w HTML5 przyjemny do pracy
- Edge pełni rolę jednocześnie DLR (Control Machine) i EDGE z NSX-v
- przejście z VXLAN na GENVE
- brak na chwilę obecną wsparcia dla rozwiązań firm trzecich np. Palo czy Forti.
- Na poziomie EDGE mamy do dyspozycji Load Balancer
- większe możliwości konfiguracji logicznych switchy, nakładanie różnych profili pod względem security, QOS, ARP itp.
- wsparcie tylko dla BGP jako routingu dynamicznego
- możliwość wykorzystania BFD
- możliwość szyfrowania ruchu pomiędzy wirtualnymi maszynami z wykorzystanie serwera kluczy
Lab
Mój lab został uruchomiony jako środowisko zagnieżdżone, można powiedzieć, że do 2 poziomu. Poziom 1 jest uruchomiony jak wirtualne maszyny na klastrze fizycznym, a poziom 2 już został uruchomiony na klastrze który został uruchomiony na poziomie 1. Rysunek poniżej przedstawia moje środowisko.
schemat uproszczony połączeń pomiędzy hostami, edgem oraz światem
Potrzebujemy ściągnąć pliki potrzebne do instalacji naszego środowiska, w mym przypadku są to:
- NSX Menager – nsx-unified-appliance-2.1.0.0.0.7395503.ova
- NSX Controller – nsx-controller-2.1.0.0.0.7395493.ova
- NSX EDGE – nsx-edge-2.1.0.0.0.7395502.ova
Instalacja Managera
Pokazana instalacja NSX Managera jest z przykładowymi danymi.
- Wybieramy nasz plik OVA który wcześniej pobraliśmy z VMware,com
2. Nadajemy nazwę wirtualnej maszynie
3. wybieramy hosta lub klaster gdzie ma zostać uruchomiona wirtualna maszyna.
4. okno informacyjne
5. Wybieramy wielkość naszego Managera
6. wskazujemy miejsce zapisania plików wirtualnej maszyny
7. konfigurujemy dostęp do sieci
8. w Tym kroku nadajemy hasła dla użytkowników root, admin, audit. Możemy zmienić domyślne nazwy tych użytkowników. Zaadresujemy interfejs sieciowy naszego NSX Managera oraz zezwolimy na dostęp po SSH.
9. Podsumowanie, możemy nacisnąć FINISH
10. Po zakończeniu wgrywania wirtualnej maszyny, możemy ją uruchomić oraz zalogować się do niej po www https://ip_nsx_managera, dane do logowania ustawiliśmy 2 kroki wcześniej.
W kolejnym wpisie skupimy się na kontrolerach.
