VMware 실습/ㄴ NSX-T

7월 6일 (KVM, NSX-MGR, T1 G/W)

깜자왕 2022. 7. 6. 17:27
반응형

KVM

- Linux를 하이퍼바이저로 전환하는 오픈소스 가상화 기술

- Container (Linux Kernel)

- 가상화 / 애뮬레이션 (QEMU)

- Compute Manager x -> Openstack (kvm에 대한 opensource로 구성된 애플리케이션)

 

 

하이퍼바이저, 리눅스 기반 애플리케이션

-> 하이퍼바이저 기반일 때

    - 가상머신의 핵심은 vHW(가상 하드웨어)이다. 이게 존재해야 os가 존재하기 때문.

    - 다양한 vHW를 지원한다는 것은 다양한 os를 지원한다는 뜻

    - 애플리케이션은 os에 의존적이다.

    - 사용자는 원하는 애플리케이션을 언제 어디서든 이용할 수 있다.

 

-> 리눅스 기반일 때

    - 컨테이너는 다양한 애플리케이션을 실행시키기 보다 리눅스 기반 애플리케이션 구동에 장점이 특출나다.

    - 최대 단점은 HW를 관리해야 하는 이슈가 생기지만, 전체를 VM으로 묶어버리면 이슈가 적어진다.


KVM 구성하기

 

-> 접속 후 virsh 로 가상쉘 접근

 

 

푸티로 접속하기 위한 사전설정

-> Username : vmware

-> Password : VMware1!

-> Password in command line : 패스워드 입력 자동화

 

 

푸티로는 root 권한으로 접속할 수 없어서 vmware로 접속한 후 root 권한 부여

list는 활성화 되어 있는 도메인

-> list 는 활성화 되어 있는 도메인을 확인할 수 있다


* nsx 자동 로그아웃 해제

-> set service http session-timeout 0

-> set cli-timeout 0

-> restart service ui-service


KVM 전송노드 추가

-> 사용자 이름 : root

-> 암호 :  VMware1!

 

 

 

위 구성에서 계정 권한 오류가 난다면 아래와 같이 한다

-> kvm 접속

-> vi /etc/ssh/sshd_config

-> 밑줄 부분으로 수정한 후 esc - :wq!

-> SSH start


NSX-T Data Center 구성하는 순서

vSphere

-> 현재 진행중인 과정. 지금 시점은 6번까지 완료

 

1. NXS 매니저를 구성하기 위한 OVF 템플릿 배포

2. NSX UI에 접근

3. vCenter 서버와 NSX 매니저를 등록

4. 클러스터 구성을 위해 추가 NSX 매니저 인스턴스를 배포

5. 전송노드 구성

6. 하이퍼바이저를 전송노드로써 사용하도록 준비

7. NSX 엣지 노드를 배포

8. NSX 엣지 클러스터 생성


App 01, DB 01 네트워크 설정

 

-> App-Segment 선택

-> DB-Segment 선택

 

 

도메인 실행시키기

랜카드 id 확인

 

 

Web-Segment와 연결하기

-> Web-Segment 안에 web 01, 02, 04 연결에 대한 포트를 생성해 3개가 포함됨을 확인할 수 있다

 

 

현재 구성도

-> 웹 세그먼트 구성 완료 (중앙 네모)

 

 

-> Web 01에서 Web 02, 04에 대한 Ping Test


세그먼트 VNI 할당 기준

- 만들었던 Pool 범위 안에서 자동으로 세그먼트에 VNI 부여됨.

 

 

논리 스위치에 대한 정보 확인

-> 스위치 정보 확인, 스위치를 식별하는 UUID 값도 확인할 수 있다

-> VTEP IP, MAC 주소 등 확인 가능 

 

 

Esxi Shell에서 nsx 명령어 사용

* Shell 접속방법

-> ssh 서비스를 On 시켜 Putty로 접속하는 방법 (:5480으로 접속해 on, 또는 DCUI(direct console user interface)의 F2 접속으로 활성화)

-> 다른 하나는 DCUI 화면에서 Alt + F1 누르기

 

-> Esxi에서 NSX 명령어 사용 가능

-> NSX에서 보는것과 같이 VNI, UUID 등 확인 가능

 

 

다시 nsx-mgr에서 정보 확인

-> esxi 03, 04, kvm01의 vtep ip 주소 확인

 

 

esxi04 -> web-segment의 mac-table 확인


현재 구성도

 

-> 3개의 esxi host가 있다. (하나는 리눅스를 하이퍼바이저처럼 바꾼 kvm)

이 각 호스트 안에는 VNDS라는 가상스위치가 있고, 포트그룹이라고 볼 수 있는 Segment가 연결되어 있다 (Web, App, DB)

이 구성도 안에서 말하자면, Web-Segment에 VM인 Web-01, 02, 04가 세그먼트 포트로 연결되어 있고, NVDS는 VMNIC4라는 물리어댑터와 연결된 VTEP이 있다. (VTEP은 Underlay로 보자면 VMKernel 인 셈)

Overlay2(vSwitch에 구성했던 포트그룹)는 하나의 포트그룹이고, 이 포트그룹으로 세 esxi host가 통신이 되고 있는 것이다.

다만, 구성 정보들은 NSX-MGR을 통해 esxi 호스트들에게 뿌려주고, 이 뿌려주는 노드가 바로 아래 사진이다 (호스트 전송노드)

KVM과 연결된 노드
esxi03, 04 과 연결된 노드

즉, nsx-mgr이 컨트롤러 역할을 함

nsx-mgr이 정보들을 모두 가지고 있으며, 노드를 통해 뿌려준다.

그리고 NSX-MGR, esxi03, 04, kvm01이 모두 묶여 하나의 스위치로 동작하는 셈이다.


NVDS

SDN 스위치 -> 가상일 수도 있고, 물리 스위치일수도 있다.

SDN Controller은 이 스위치들을 하나로 묶고, 이 전체를 또 묶어서 네트워크 서비스를 만들어낸다.

네트워크서비스 - L2, L3 두 개가 있다

NVDS는 여기서 SDN Switch이며,  DVS와 동일하다고 보면 된다. 하지만 SDN용 스위치이기 때문에 L2를 만들기 위한 오버레이를 지원해야 한다. DVS는 오버레이를 지원하지 않는다.

 

DVS -> 중앙집중화만 되지 오버레이서비스를 제공하지 않는다. 다만 vlan기반의 언더레이를 지원함.


Overlay L3 Routing

 

VXLAN -> SDN Switch Fabric(TZ)안에 두 개의 오버레이 네트워크를 만들고(VNI)(마치 한 스위치 안에 VLAN10,VLAN11 두 개가 있는 것처럼)  이 두 VNI를 통신시키기 위한 L3가 필요하다.

 

이 두 개를 라우팅해줄 수 있는 가상 라우터가 필요하다(vrf). 이 가상 라우터를 각각 VNI에 연결시킨다.

이 vrf를 어떻게 구성할까?

- > NVDS가 구성되어 있다. 만약 두 개의 TN이 있고, 각각 NVDS를 가지고 있다 할때, 이 두 개의 NVDS를 하나처럼 동작시켜야 할 것이다. 두 개의 NVDS의 구성정보는 NSX-MGR이 가지고 있을 것이고, 그 구성정보가 똑같으면 하나의 커다란 스위치처럼 보일 것이다. 

 

라우터는 라우팅 테이블 없이는 제 기능을 못한다. (스위치와 달리 flood&learning이 없다)

이 라우팅 테이블이 두 쪽 모두 똑같아야 한다. (이는 NSX-MGR이 담당해서 뿌려주기 때문에 두 쪽 모두 동일한 값을 가지고 있을 것이다)

 

두 NVDS는 동일한 값을 가지고 있을 거고, NSX-MGR의 컨트롤플레인이 두 DLR에 정보를 뿌리기 때문에 DLR 구성정보가 같다.

NVDS에서 게이트웨이를 봤을 때, 두 게이트웨이 주소가 같기 때문에 어느 방향이든 상관이 없다. 이를 통해 오버레이 라우팅이 가능하다.


T1 G/W <-> T0 G/W <-> 외부 라우터

-> DLR(T1) 외에 다른 라우터(T0)와 외부의 라우터가 통신한다면, MGR을 통해 다른라우터 (T0)와 DLR이 정보를 공유할 수 있을 것이다.

DLR이 외부의 라우터와 직접 연결해 통신하기가 매우 어렵기 때문임

 

즉, T1과 T0를 구성해야 할 것이다. (NSX-MGR에서 구성한다)

Segment 또한 이용할 것임!

 

T1 G/W 생성

-> T1 게이트웨이 생성. 세그먼트 붙여야 한다

-> 이 외에도 app, db 세그먼트도 동일하게 세팅

 

 

-> T1 게이트웨이 정보에서도 세그먼트 확인 가능

 

 

NSX CLI에서 T1 게이트웨이 확인하기

-> DR이라는 분산 라우터 이름이 자동으로 붙여짐

 

인터페이스는 자동으로 생성됨!

-> 인터페이스는 자동으로 생성됨 (세그먼트로 연결된 인터페이스)

 

-> Connected 된 주소들도 확인 가능하다.

-> 16.10 / 16.20 / 16.30 등

 

esxi03 에서의 인터페이스
esxi04 에서의 인터페이스

-> Web Segment 와 연결된 G/W 주소 확인 (172.16.10.1)

 

web01에서의 app, db 로의 ping

-> L3서비스를 갖고 있다고 생각한다.

-> T1 table 을 통해 네트워크 대역이 다른 Host 서로의 ping이 가능한 것이다.

 

 

web01을 esxi03에서 esxi04로 옮겨보자.

-> Hot Migration 이동 확인

옮기는 중에서도 네트워크는 끊어지지 않는다.

-> Hot Migration은 VM이 살아있는 상태에서 옮겨짐을 확인할 수 있다 !

 

내일부터 T0을 구성하고 외부 라우터와 통신하는 작업 해볼거임

* T0 게이트웨이를 구성할 때 필요한 것 -> Edge Node -> 이 노드를 TN으로 바꿔주는 작업도 필요함

* T0쪽은 라우팅 프로토콜이 필요함 (ospf, bgp 필요) - 복잡할 것.