0
Items : 0
Subtotal : 0,00 
View CartCheck Out
0
Items : 0
Subtotal : 0,00 
View CartCheck Out

Poprzednie odcinki naszego poradnika dot. VMware NSX dotyczyły w głównej mierze przygotowania środowiska do obsługi wirtualizacji sieci, kontrolerów itp. Nuda. Kończymy zatem z nudą i zabieramy się w końcu za coś pełnokrwistego.

NSX-cables

Dzisiaj zaczynamy poważny temat – zajmiemy się stworzeniem pierwszego VXLAN-a i uruchomimy komunikację przy jego pomocy w naszym środowisku. Zaczynajmy!

Każdy z VXLAN-ów, jaki powstaje w sieci overaly z poziomu GUI NSX-a jest traktowany, jako autonomiczny przełącznik logiczny.

nsx-3-1

Dodajemy, zatem przełącznik. Zalecane jest, aby rodzaj transportu był zgodny z transportem obowiązujmy w całym środowisku (w naszym przypadku unicast). Każdy z przełączników należy do strefy transportowej odpowiedzialnej za tranzyt w obrębie jak i między klastrami VMware. Wybranie opcji związanych z uczeniem się adresów zarówno MAC jak i IP definiuje czy chcemy aby switch zachowywał się jak fizyczny przełącznik czy jak HUB.

nsx-3-2

Dodany VXLAN przedstawia się jak na zrzucie ekranu poniżej.

nsx-3-3

Kolejny krok to przeniesienie wirtualnej maszyny do sieci overlay. Można to zrealizować na kilka sposobów. Pierwszy najwygodniejszy to użycie kreatora analogicznego, jakiego można spotkać w vDS

nsx-3-4

W którym wskazujemy, jakie wirtualne maszyny chcemy przenieść.

nsx-3-5

Następnie należy określić, które wirtualne karty sieciowe z poszczególnych maszyn chcemy przenieść.

nsx-3-6

Dalej, dalej, zakończ 🙂

nsx-3-7

VXLAN jest również dostępny na liście port grup, jakie mamy dostępne w klastrze VMware. Jest on reprezentowany, jako port z dystrybułowanego przełącznika poprzedzony prefiksem: vxw-dvs-49-virtualwire-1-sid.

nsx-3-8

Po połączniu się do vCenter klientem Windows, który w obliczu nadchodzącego vSphere 6 będzie już legacy otrzymujemy możliwość przyłączenia się do overlay-owej port grupy.

nsx-3-9

Ponieważ środowisko NSX-a jest zaprojektowane by działało pomimo przeciwności losu. Oczywiste jest to, że po utracie vCenter tracimy możliwość edycji dystrybułowanych przełączników, ale możemy się posiłkować KB VMware i za pomocą poleceń wyciągnąć niezbędne informacje i wyedytować plik vmx maszyny.

# esxcli network vswitch dvs vmware list
DSwitch
Name: DSwitch
VDS ID: 66 53 11 50 c5 94 d8 3b-f6 b6 4d 1e 91 09 0d 6a
Class: etherswitch
Num Ports: 1536
Used Ports: 8
Configured Ports: 512
MTU: 1600
CDP Status: both
Beacon Timeout: -1
Uplinks: vmnic0
VMware Branded: true
DVPort:
Client: vmnic0
DVPortgroup ID: dvportgroup-50
In Use: true

Port ID: 8
Client: vmk0
DVPortgroup ID: dvportgroup-51
In Use: true

Port ID: 1
Client: vmk2
DVPortgroup ID: dvportgroup-67
In Use: true

Port ID: 34
Client: vmk1
DVPortgroup ID: dvportgroup-169
In Use: true
Port ID: 86

         Client:
         DVPortgroup ID: dvportgroup-170
         In Use: false
         Port ID: 102

Client:
DVPortgroup ID: dvportgroup-170
In Use: false

Port ID: 103
Client: NSX_Controller_79c13024-3977-42b5-a8ee-1e54f5ea28be.eth0
DVPortgroup ID: dvportgroup-67
In Use: true
Port ID: 39

Dostarczenie sieci do tego vnic-a wymaga kolejnego zestawu poleceń oraz odrobine cierpliwości, ale w przypadku braku komunikacji z systemem i mając wizje odtwarzania całości z backupu, jesteśmy zmuszeni edytować linie:

ethernet0.dvs.switchId = „66 53 11 50 c5 94 d8 3b-f6 b6 4d 1e 91 09 0d 6a”
ethernet0.dvs.portId = „102”
ethernet0.dvs.portgroupId = „dvportgroup-170”
ethernet0.dvs.connectionId = „1956006238”

To oczywiście w ostateczności 🙂 Nam udało się całość zrobić z GUI więc pozostaje sprawdzenie osiągalności hosta vAdm8 w sieci VXLAN.

nsx-3-10

Tym sposobem mamy pierwszy VLXAN w naszej sieci overaly. W kolejnym odcinku przeniesiemy kilka VLAN-ów do sieci VXLAN. Następnie przejdziemy do usług warstw wyższych.

About the author

Leave a Reply