Piszki Lab

Analiza przypadku w języku przodków…

Trend Micro Deep Security: Upgrade vCNS 5.5 do NSX 6.1

| 0 comments

Posiadacze licencji vCloud Suite 6.0 mogą się już naocznie przekonać, że w skład tej licencji nie wchodzi już komponent vCloud Networking and Security. Jeśli dodatkowo używają (tak jak my) Trend Micro Deep Security, który wymaga do działania (agentless) vShield Endpoint (i App). To staje się jasne, że migracja środowiska do vSphere 6.0 musi być poprzedzona migracją vCNS do NSX. Licensja vCloud Suite 5.8 zawiera vCNS w wersji 5.5.3.1 który nie wspiera vSphere 6.0. W przypadku gdy jesteśmy posiadaczami licencji typu standalone, to dostępna jest wersja vCNS 5.5.4.1 która wspiera vSphere 6.0 (z adnotacją, że nowe “ficzery” vSphere 6.0 nie były testowane z vCNS!). Wybór rozwiązania problemu należy do Was, ale wyraźnie widać, że to już jest koniec vCNS. Najnowszy NSX 6.1.3 wspiera vSphere 6.0. Opisany poniżej upgrade został wykonany w vSphere 5.5 z vCNS 5.5.4 do NSX 6.1.2.

nsx

Jeśli już staliśmy się posiadaczami VMware NSX, to sam proces migracji obecnego środowiska nie jest zbyt skomplikowany. Pamiętajmy, że główna nowość NSX, czyli ruch północ południe i wschód zachód i wszystkie związane z tym wymagania co do architektury środowiska, to tak naprawdę zalecenia. W wersji podstawowej, czyli NSX Manager –> Guest Introspection (Endpoint) –> Deep Security nie musimy stawiać osobnego klastra pod NSX. Po wykonaniu upgrade, przemyśleniu i sprawdzeniu wszystkich nowości jakie niesie NSX, możemy przystąpić do modyfikacji architektury naszego środowiska lub zostawić wszystko tak jak jest.

nsx0

Po przeczytaniu w dokumentacji VMware NSX 6 odpowiedniej sekcji dotyczącej upgrade vShield Manager do NSX można odnieść wrażenie, że jest to trywialny proces. Generalnie tak jest, ale jak zwykle, diabeł tkwi w szczegółach. Aby wszystko zakończyło się poprawnie i bez większych stresów, należy w pierwszej kolejności wykonać migawki vCenter i vShield Manager. W kroku drugim należy odinstalować plugin vShield Manager z vCenter. Po wykonaniu upgrade, jednym z kroków obowiązkowych jest rejestracja NSX w vCenter, w trakcie tego procesu usuwany jest stary plugin i instalowany nowy. Procedura ta często kończy się niepowodzeniem, dlatego najbezpieczniej jest usunąć stary plugin ręcznie zanim cokolwiek innego zrobimy. Wchodzimy na adres https://vcenter/mob i usuwamy plugin com.vmware.vShieldManager.

nsx1

Po wykonaniu tego kroku logujemy się do vShield Manager i przechodzimy do sekcji Settings –> Updates gdzie ładujemy plik zawierający dane NSX. Pamiętajmy też, że jednym z warunków jakie musimy spełnić to podniesienie vShield Manger i Edge do wersji minimum 5.5 przed wykonaniem upgrade do NSX.

nsx2

Po zakończeniu procesu upgrade, który trwa bardzo szybko, musimy wykonać kolejne dwa kroki. Po pierwsze zamykamy wszystkie aktywne sesje vSphere Web Client i opróżniamy cache przeglądarki, po drugie wyłączamy NSX Manager i zwiększamy RAM do 12GB i liczbę CPU do 4 (minimum). Uruchamiamy ponownie i czekamy aż wszystko się uruchomi do końca (polecam kontrolowanie obciążenia CPU w maszynie). Wchodzimy na dawny adres vShield Manager i logujemy się do NSX:

nsx4

Zaletą wykonania upgrade jest to, że większość konfiguracji jest przejmowana przez NSX (NTP, Syslog, uprawnienia i ustawienia sieci, certyfikaty SSL). Logujemy się teraz do vSphere Web Client i sprawdzamy czy poprawnie zainstalował się plugin Networking & Security.

nsx5

Jeśli tak, to przechodzimy do kolejnego kroku. Jeśli nie, to wracamy do kroku pierwszego, sprawdzamy w https://vcenter/mob czy pojawił się plugin vShield Manager (tak tak). Jeśli tak, usuwamy go, jeśli nie, to przechodzimy do NSX Management Services i ponownie rejestrujemy NSX w vCenter. Na tym etapie przechodzimy do vSphere Web Client w Networking & Security w sekcji Install przechodzimy do Host Preparation i klikamy Resolve:

nsx6

Procedura zakończy się niepowodzeniem, wymagany jest restart hostów:

nsx8

Po restarcie, zanim wykonamy ponownie procedurę “Resolve” należy wyłączyć vShield App na każdym z ESXi (oraz DSVA jeśli używamy Deep Security), unikniemy dzięki temu wielu problemów polegających na przypadkowym odcinaniu hostów od sieci (i co za tym idzie, usług, w tym vCenter). Klikamy w “Resolve” i czekamy na zakończenie procedury instalacji agenta NSX Manager na każdym z hostów. Jak widać na obrazku poniżej, ta procedura to tak naprawdę włączenie nowego agenta w trybie zgodności. Bądźcie jednak ostrożni, kliknięcie w “Update” spowoduje automatyczny DRS na całym środowisku, włączając w to przynajmniej dwa restarty każdego hosta. Jest to długotrwała procedura i znacząco wpływa na nasze środowisko!

nsx9

Po wykonaniu “Update” wygląda to tak (w tym momencie możemy bezpiecznie włączyć ponownie stare vShield App):

nsx10

Przechodzimy do sekcji “Service Deployements” i w sekcji vShield-App klikamy w “Resolve”. Ta procedura podłączy stare vShield App do NSX Manager. W przypadku gdy potrzebowaliśmy vShield App i Endpoint jedynie do obsługi Trend Micro Deep Security, możemy w tym momencie bezpiecznie odinstalować vShield App (jego funkcje zostały przeniesione poziom wyżej).

nsx11

W kolejnym kroku wykonujemy upgrade vShield Endpoint. Pamiętajmy, że w vCNS na ESXi instalowany był vShield App i Endpoint ale tylko App miał postać virtualnej maszyny.

nsx12

Wykonując upgrade vShield Endpoint doinstalujemy na każdym ESXi nową maszynę wirtualną o nazwie Guest Introspection. Dodatkowo należy zwrócić uwagę, że na wszystkich maszynach muszą być zainstalowane najnowsze VMware Tools (te zawierające sterownik Guest Introspection).

nsx14

Na tym etapie podstawowa funkcjonalność Trend Micro Deep Security, czyli ochrona bez agentowa, została przywrócona. DSM wykrywa, że jest podłączony do NSX co widać w ustawieniach:

nsx15

Mimo że ustawienia zostały przejęte z vShield Managera to w tej sekcji musimy wykonać “Remove Manager” i ponownie go zarejestrować. Bez tego kroku DSM nie skonfiguruje NSX tak aby pokazał w “Service Deployments” Trend Micro Deep Security. Usługa Trend Micro Deep Security to tak naprawdę DSVA, jej zainstalowanie spowoduje zainstalowanie na każdym ESXi nowej maszyny wirtualnej o nazwie Trend Micro Deep Security. W DSM “stare” DSVA zostaną automatycznie zdezaktywowane a nowe aktywowane (i przejmą rolę starych). Stare DSVA można w tym momencie wyłączyć i usunąć z vCenter.

nsx16

nsx17

Efekt końcowy wygląda tak:

nsx18

Dokładna instrukcja konfiguracji Trend Micro Deep Security z VMware NSX znajduje się tutaj. I tak, czytałem ten fragment o upgrade (zaoraj wszystko), ale się z nim nie zgadzam. Chodź wykonanie upgrade vShield Manager do NSX Manager trwa parę minut, to podniesienie całego środowiska (ESXi, vShield App) wymaga sporo czasu i może powodować fluktuacje sieci. Całą procedurę należy zaplanować odpowiednio i uwzględnić, że NSX sam zarządza procesem upgrade ESXi (nie można ręcznie podnosić pojedynczych hostów). Powstaje pytanie, upgrade czy instalacja NSX od zera? Jeśli korzystamy z EPSEC to upgrade, jeśli planujemy wykorzystanie NSX na pełną skalę, to instalacja od zera (moim zdaniem), wybór oczywiście zależy od Was.

Oceń ten artykuł:
[Głosów:0    Średnia:0/5]

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.