Jak to mówią jeśli czegoś nie widzimy nie znaczy to że tego nie ma. Jakiś czas temu opisywałem mój proces podejścia do upgrejdów w artykule Upgrade VMware vCloud Director z 8.20 na 9.5 | Dobre praktyki | Checklista.
Po tym etapie intensywne używania pewnego EDGa odsłoniło to przed nami pewne problemy z komunikacją z NSXem a dokładniej z parametrami NATu zapisanego w bazie NSX managera. U mnie to wyglądało tak. Tworzyliśmy dokumentacje na potrzeby nowej wersji i dużo operacji było związanych przykładowo z NATami. Nie wiadomo na dzień dzisiejszy, dlaczego ale pomimo tego, iż wcześniej było dobrze to przy tworzeniu sieci typu “Routed” poprzez GUI vCloud Directora 9.5 otrzymywaliśmy błąd typu “Number must not be null”:
Wspomnę tylko tyle że efekt był taki sam na NSX managerze 6.3.5, jak i na 6.4.3. (NSX edga jeszcze nie podnosiłem do 6.4.3 ani nie robiłem re-deploy)
Mogliśmy zrobić deployment nowego edga w tym przypadku ale postanowiliśmy zbadać temat, aby wiedzieć na przyszłość. Oczywiście nie obyło się bez SR (19074323302) do VMware.
Po pewnym czasie debugowania dostaliśmy namiary na KB67193 ,który swoją drogą został stworzony dzień po założeniu mojej sprawy 🙂 Wersja offline poniżej, gdyby kiedyś KBek zniknął:
Zgodnie z KBkiem trzeba użyć do tego narzędzia do rozmowy po REST-API. Można użyć przykładowo Postmana
UWAGA:
Do wykonywania poniższych czynności potrzebna będzie umiejętność pracy na narzędziu Postman lub innym sofcie do zapytań REST-API.
Zapytanie:
- “GET https://NSX_FQDN/api/4.0/edges”
listuje tylko 256 EDGY co w naszym przypadku Service Providera był to tylko mały odsetek infrastruktury i to stanowiło problem. Niestety w dokumentacji API od NSXa na dzień dzisiejszy nie znalazłem sposobu jak to zmienić. Taki sam efekt miałem używając komendy “show edge all” łącząc się do NSX managera poprzez SSH. Pokazywało tylko 256 pozycji.
Odpowiedz z NSX Managera poprzez CLI:
Odpowiedz po wysłaniu zapytania o wszystkie EDGE w środowisku. W tym miejscu widać jaki limit odpowiedzi jest ustawiony.
Operacja naprawy wpisów w NSX Managerze:
- Wysyłamy zapytanie GET API bardziej szczegółowe niż w samym KBku:
https://NSX-Manager/api/4.0/edges/edge-id/nat/config
edge-id: jest numerem EDGA. Można go wziąć z paru miejsc (np. NSX manager GUI lub poprzez zapytanie powercli):
GUI:
Powercli:
Get-NsxEdge | select name,id
Interesuje nas identyfikator:
<ruleId>196611</ruleId> oraz <ruleTag>196611</ruleTag> a właściwie jego brak. Jeśli mamy taką sytuację powinniśmy go dopisać kolejnym “requestem PUT.
Kopiujemy wynik do notatnika w ramach kopii zapasowej oraz w drugim oknie wklejamy tę samą zawartość i tam właśnie będziemy wykonywać modyfikacje.
Dalej na ten sam adres https://NSX-Manager/api/4.0/edges/edge-id/nat/config wysyłamy zmodyfikowanego XMLa sposobem PUT.
Jeśli żądanie zostało poprawnie wykonane w Postmanie powinniśmy otrzymać odpowiedz o kodzie 204:
Dalej nie zostało nam nic innego jak sprawdzenie wyników naszej pracy poprzez próbę stworzenia ponownie sieci typu routed.
Tak tego typu problem rozwiązałem w naszym środowisku. Możliwe, że są jeszcze inne metody. Jeśli miałbyś jeszcze coś do dania pisz śmiało jakie miałeś doświadczenia z tego typu problemami. Dodatkowo, jeśli będę mógł Ci jakoś pomóc daj znać..
Dodam Cię do listy mailowej, z której możesz wypisać się w dowolnym momencie (jeden klik.) | Polityka Prywatności
