![\"nsx\"](\"https:\/\/vm.piszki.pl\/wp-content\/uploads\/2015\/05\/nsx.png\" "\\"nsx\\"")
<\/a><\/p>\n<\/p>\n
Je\u015bli ju\u017c stali\u015bmy si\u0119 posiadaczami VMware NSX, to sam proces migracji obecnego \u015brodowiska nie jest zbyt skomplikowany. Pami\u0119tajmy, \u017ce g\u0142\u00f3wna nowo\u015b\u0107 NSX, czyli ruch p\u00f3\u0142noc po\u0142udnie i wsch\u00f3d zach\u00f3d i wszystkie zwi\u0105zane z tym wymagania co do architektury \u015brodowiska, to tak naprawd\u0119 zalecenia. W wersji podstawowej, czyli NSX Manager \u2013> Guest Introspection (Endpoint) \u2013> Deep Security nie musimy stawia\u0107 osobnego klastra pod NSX. Po wykonaniu upgrade, przemy\u015bleniu i sprawdzeniu wszystkich nowo\u015bci jakie niesie NSX, mo\u017cemy przyst\u0105pi\u0107 do modyfikacji architektury naszego \u015brodowiska lub zostawi\u0107 wszystko tak jak jest.<\/p>\n
Po przeczytaniu w dokumentacji VMware NSX 6 odpowiedniej sekcji dotycz\u0105cej upgrade vShield Manager do NSX mo\u017cna odnie\u015b\u0107 wra\u017cenie, \u017ce jest to trywialny proces. Generalnie tak jest, ale jak zwykle, diabe\u0142 tkwi w szczeg\u00f3\u0142ach. Aby wszystko zako\u0144czy\u0142o si\u0119 poprawnie i bez wi\u0119kszych stres\u00f3w, nale\u017cy w pierwszej kolejno\u015bci wykona\u0107 migawki vCenter i vShield Manager. W kroku drugim nale\u017cy odinstalowa\u0107 plugin vShield Manager z vCenter. Po wykonaniu upgrade, jednym z krok\u00f3w obowi\u0105zkowych jest rejestracja NSX w vCenter, w trakcie tego procesu usuwany jest stary plugin i instalowany nowy. Procedura ta cz\u0119sto ko\u0144czy si\u0119 niepowodzeniem, dlatego najbezpieczniej jest usun\u0105\u0107 stary plugin r\u0119cznie zanim cokolwiek innego zrobimy. Wchodzimy na adres https:\/\/vcenter\/mob i usuwamy plugin Po wykonaniu tego kroku logujemy si\u0119 do vShield Manager i przechodzimy do sekcji Settings \u2013> Updates gdzie \u0142adujemy plik zawieraj\u0105cy dane NSX. Pami\u0119tajmy te\u017c, \u017ce jednym z warunk\u00f3w jakie musimy spe\u0142ni\u0107 to podniesienie vShield Manger i Edge do wersji minimum 5.5 przed wykonaniem upgrade do NSX.<\/p>\n Po zako\u0144czeniu procesu upgrade, kt\u00f3ry trwa bardzo szybko, musimy wykona\u0107 kolejne dwa kroki. Po pierwsze zamykamy wszystkie aktywne sesje vSphere Web Client i opr\u00f3\u017cniamy cache przegl\u0105darki, po drugie wy\u0142\u0105czamy NSX Manager i zwi\u0119kszamy RAM do 12GB i liczb\u0119 CPU do 4 (minimum). Uruchamiamy ponownie i czekamy a\u017c wszystko si\u0119 uruchomi do ko\u0144ca (polecam kontrolowanie obci\u0105\u017cenia CPU w maszynie). Wchodzimy na dawny adres vShield Manager i logujemy si\u0119 do NSX:<\/p>\n Zalet\u0105 wykonania upgrade jest to, \u017ce wi\u0119kszo\u015b\u0107 konfiguracji jest przejmowana przez NSX (NTP, Syslog, uprawnienia i ustawienia sieci, certyfikaty SSL). Logujemy si\u0119 teraz do vSphere Web Client i sprawdzamy czy poprawnie zainstalowa\u0142 si\u0119 plugin Networking & Security.<\/p>\n Je\u015bli tak, to przechodzimy do kolejnego kroku. Je\u015bli nie, to wracamy do kroku pierwszego, sprawdzamy w https:\/\/vcenter\/mob czy pojawi\u0142 si\u0119 plugin vShield Manager (tak tak). Je\u015bli tak, usuwamy go, je\u015bli 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:<\/p>\n Procedura zako\u0144czy si\u0119 niepowodzeniem, wymagany jest restart host\u00f3w:<\/p>\n Po restarcie, zanim wykonamy ponownie procedur\u0119 \u201cResolve\u201d nale\u017cy wy\u0142\u0105czy\u0107 vShield App na ka\u017cdym z ESXi (oraz DSVA je\u015bli u\u017cywamy Deep Security), unikniemy dzi\u0119ki temu wielu problem\u00f3w polegaj\u0105cych na przypadkowym odcinaniu host\u00f3w od sieci (i co za tym idzie, us\u0142ug, w tym vCenter). Klikamy w \u201cResolve\u201d i czekamy na zako\u0144czenie procedury instalacji agenta NSX Manager na ka\u017cdym z host\u00f3w. Jak wida\u0107 na obrazku poni\u017cej, ta procedura to tak naprawd\u0119 w\u0142\u0105czenie nowego agenta w trybie zgodno\u015bci. B\u0105d\u017acie jednak ostro\u017cni, klikni\u0119cie w \u201cUpdate\u201d spowoduje automatyczny DRS na ca\u0142ym \u015brodowisku, w\u0142\u0105czaj\u0105c w to przynajmniej dwa restarty ka\u017cdego hosta. Jest to d\u0142ugotrwa\u0142a procedura i znacz\u0105co wp\u0142ywa na nasze \u015brodowisko!<\/p>\n Po wykonaniu \u201cUpdate\u201d wygl\u0105da to tak (w tym momencie mo\u017cemy bezpiecznie w\u0142\u0105czy\u0107 ponownie stare vShield App):<\/p>\n Przechodzimy do sekcji \u201cService Deployements\u201d i w sekcji vShield-App klikamy w \u201cResolve\u201d. Ta procedura pod\u0142\u0105czy stare vShield App do NSX Manager. W przypadku gdy potrzebowali\u015bmy vShield App i Endpoint jedynie do obs\u0142ugi Trend Micro Deep Security, mo\u017cemy w tym momencie bezpiecznie odinstalowa\u0107 vShield App (jego funkcje zosta\u0142y przeniesione poziom wy\u017cej).<\/p>\n W kolejnym kroku wykonujemy upgrade vShield Endpoint. Pami\u0119tajmy, \u017ce w vCNS na ESXi instalowany by\u0142 vShield App i Endpoint ale tylko App mia\u0142 posta\u0107 virtualnej maszyny.<\/p>\n Wykonuj\u0105c upgrade vShield Endpoint doinstalujemy na ka\u017cdym ESXi now\u0105 maszyn\u0119 wirtualn\u0105 o nazwie Guest Introspection. Dodatkowo nale\u017cy zwr\u00f3ci\u0107 uwag\u0119, \u017ce na wszystkich maszynach musz\u0105 by\u0107 zainstalowane najnowsze VMware Tools (te zawieraj\u0105ce sterownik Guest Introspection).<\/p>\n Na tym etapie podstawowa funkcjonalno\u015b\u0107 Trend Micro Deep Security, czyli ochrona bez agentowa, zosta\u0142a przywr\u00f3cona. DSM wykrywa, \u017ce jest pod\u0142\u0105czony do NSX co wida\u0107 w ustawieniach:<\/p>\n Mimo \u017ce ustawienia zosta\u0142y przej\u0119te z vShield Managera to w tej sekcji musimy wykona\u0107 \u201cRemove Manager\u201d i ponownie go zarejestrowa\u0107. Bez tego kroku DSM nie skonfiguruje NSX tak aby pokaza\u0142 w \u201cService Deployments\u201d Trend Micro Deep Security. Us\u0142uga Trend Micro Deep Security to tak naprawd\u0119 DSVA, jej zainstalowanie spowoduje zainstalowanie na ka\u017cdym ESXi nowej maszyny wirtualnej o nazwie Trend Micro Deep Security. W DSM \u201cstare\u201d DSVA zostan\u0105 automatycznie zdezaktywowane a nowe aktywowane (i przejm\u0105 rol\u0119 starych). Stare DSVA mo\u017cna w tym momencie wy\u0142\u0105czy\u0107 i usun\u0105\u0107 z vCenter.<\/p>\n Efekt ko\u0144cowy wygl\u0105da tak:<\/p>\n Dok\u0142adna instrukcja konfiguracji Trend Micro Deep Security z VMware NSX znajduje si\u0119 tutaj.<\/a>\u00a0I tak, czyta\u0142em ten fragment o upgrade (zaoraj wszystko), ale si\u0119 z nim nie zgadzam. Chod\u017a wykonanie upgrade vShield Manager do NSX Manager trwa par\u0119 minut, to podniesienie ca\u0142ego \u015brodowiska (ESXi, vShield App) wymaga sporo czasu i mo\u017ce powodowa\u0107 fluktuacje sieci. Ca\u0142\u0105 procedur\u0119 nale\u017cy zaplanowa\u0107 odpowiednio i uwzgl\u0119dni\u0107, \u017ce NSX sam zarz\u0105dza procesem upgrade ESXi (nie mo\u017cna r\u0119cznie podnosi\u0107 pojedynczych host\u00f3w). Powstaje pytanie, upgrade czy instalacja NSX od zera? Je\u015bli korzystamy z EPSEC to upgrade, je\u015bli planujemy wykorzystanie NSX na pe\u0142n\u0105 skal\u0119, to instalacja od zera (moim zdaniem), wyb\u00f3r oczywi\u015bcie zale\u017cy od Was.<\/p>\n Posiadacze licencji vCloud Suite 6.0 mog\u0105 si\u0119 ju\u017c naocznie przekona\u0107, \u017ce w sk\u0142ad tej licencji nie wchodzi ju\u017c komponent vCloud Networking and Security. Je\u015bli dodatkowo u\u017cywaj\u0105 (tak jak my) Trend Micro Deep Security, kt\u00f3ry wymaga do dzia\u0142ania (agentless) vShield Endpoint … Continue reading <\/a><\/p>\ncom.vmware.vShieldManager.<\/code><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n