07. 네트워크 리소스를 제어하는 방법

7.1 네트워크 리소스의 제어를 위한 기본 API

 

7.1.1 클라우드 네트워크의 특징과 기본 사상

 

클라우드 환경이라고 하더라도 네트워크의 기본 >> TCP/IP

네트워크의 기능

* L2 네트워크(데이터링크 계층) : 같은 네트워크에 속한 장비끼리 연결

* L3 네트워크(네트워크 계층) : 서로 다른 L2 네트워크끼리 연결

 

네트워크에서 중요한 포인트는 IP 주소를 얼마나 잘 다루느냐인데

클라우드 환경의 네트워크에는 IP 주소 관리 기능이 기본적으로 포함되어 있음

 

오픈스택이나 AWS와 같은 클라우드 환경의 네트워크에는

IP 주소 관리를 시스템이 자동으로 처리하게 하고,

IP 주소 할당은 DHCP를 통해 받아가도록 만들어져 있음

 

7.1.2 네트워크 리소스의 전체 그림

 

<기능 매핑>

네트워크의 기본 기능들

: L2 네트워크 상에서 만들어지는 서브넷의 기능과 그 서브넷들을 서로 연결하기 위한 라우팅 기능, 그리고 서버를 네트워크에 연결하는 논리 포트 기능

 

기능 비교 (오픈스택 Neutron vs AWS VPC)

* 오픈스택 Neutron

: 비교적 물리적 환경과 유사한 형태, 테넌트 안에 가상 스위치(가상 네트워크), 가상 라우터, 논리 포트로 구성

>> 실제 물리적인 네트워크 장비를 흉내내어 모델로 표현

* AWS VPC

: 가상 네트워크 전체에 해당하는 VPC라는 리소스 먼저 생성, 그 안에 기능적인 요소로 서브넷, 라우팅 테이블, ENI로 구성되는 형태

>> 논리적인 네트워크의 기능을 모델로 표현

 

네트워크 리소스	오픈스택 Neutron	AWS VPC
네트워크 전체	대응하는 리소스 없음 (테넌트 안에 리소스 직접 생성)	VPC(Virtual Private Cloud)
스위치	네트워크	대응하는 리소스 없음 (스위치에 해당하는 리소스는 없는 대신 서브넷에 기능이 포함되어 있음)
서브넷	서브넷	서브넷
라우터	라우터	게이트웨이, 라우팅 테이블
포트	포트	ENI(Elastic Network Interface)
시큐리티 그룹	시큐리티 그룹	시큐리티 그룹
네트워크 접근 제어	(Fwaas 개발 중)	네트워크 액세스 컨트롤 리스트(NACL)

 

7.1.3 스위치와 서브넷

 

스위치

>> 가상 스위치는 물리적인 네트워크 스위치를 흉내낸 것으로 L2 네트워크 기능을 수행.

>> 가상 스위치에는 L3 네트워크에서 사용하는 IP 주소 범위(CIDR, 172.16.1.0/24와 같이 표현)를 '서브넷'이라는 이름으로 할당 받음

 

서브넷

>> 서브넷에 연결된 서버는 기동시 DHCP를 통해 IP 주소를 할당받고, 그 IP 주소로 통신.

>> 서버가 존재하는 한 같은 IP 주소가 고정 >> 고정 IP

>> 할당된 IP 주소에만 통신을 허용한다는 특징

>> 사용자가 서버 안에서 임의로 IP 주소의 설정을 바꾼다고 하더라도 변경된 IP 주소로는 통신 불가.

 

사이더(CIDR)

>> 서브넷을 생성할 때 지정하는 IP 주소의 범위

>> 가변 길이의 서브넷 마스크 결정 방식 도입

>> xxx.yyy.zzz.sss/N 과 같은 표기 방식 사용

>> '/' 뒤에 이어지는 숫자가 서브넷 마스크의 비트 수를 의미

>> IP 주소의 주소 범위를 표기할 때 널리 쓰이고 있음

 

7.1.4 라우터

 

라우터

>> 서로 다른 네트워크를 연결하는 기능

 

1) 내부 > 내부

내부란 클라우드 네트워크를 의미

서로 다른 네트워크에 속한 서버끼리 통신하는 것

기본적으로 테넌트 내부나 VPC 내의 네트워크들을 서로 연결

 

2) 내부 > 외부

가상 네트워크에 연결된 서버가 인터넷을 통해 외부에 접속되는 경우

라우터에서는 내부 네트워크에서 사용되는 Private IP 주소를 Public IP주소로 변환하는 IP 마스커레이드를 수행

 

3) 외부 > 내부

오픈스택에서는 플로팅 IP, AWS의 경우 엘라스틱 IP(EIP)가 사용됨

공인 IP를 어드레스 풀에서 확보한 다음, 서버의 논리 포트에 할당하고 다시 이 공인 IP 주소가 사설 IP 주소로 연결되도록 만듦

이렇게 하면 클라우드 외부에서 클라우드 내부로 접근할 수 있게 되는데, 이런 기능을 NAT(Network Address Translation)라고 부름

실제 리소스

>> Neutron의 리소스 모델은 크게 가상 라우터와 서브넷의 연결 관계로 구성

>> Neutron 내부에서는 서브넷이 할당된 네트워크에 논리 포트를 만들고 라우터에 연결

>> AWS에서는 크게 게이트웨이와 라우팅 테이블로 구성

>> 외부로 연결하기 위해 VPC 안에 게이트 웨이를 만듦

>> 그런 후 서브넷의 라우팅 테이블에서 외부로 통신할 때는 이 게이트웨이를 통과하도록 라우팅 정보를 설정

 

>> AWS에서는 개념적으로 라우터가 VPC에 속하는 형태이지만 실제로 라우터가 리소스 형태로 관리되지는 않음

>> 대신 라우터에 설정하는 라우팅 테이블을 리소스 형태로 사용

* 메인 라우팅 테이블 >> VPC 전체에 적용한 것

* 서브 라우팅 테이블 >> 특정 서브넷에만 적용한 것

 

7.1.5 포트

>> 논리 포트는 가상 네트워크상에 만들어지는 스위치의 포트 같은 개념

>> AWS에서는 서버에서 네트워크에 연결하기 위한 인터페이스 접점이라는 의미가 강하고 'ENI(Elastic Network Interface)'라고 부름

>> 논리 포트는 생성될 때 자신이 소속된 가상 서브넷으로부터 IP주소를 할당 받음

>> 이때 할당된 IP 주소 이외의 통신은 모두 차단시킴

>> 논리 포트에는 IP주소를 여러 개 할당할 수 있기 때문에 가상 서버의 NIC 하나에 여러 개의 IP 주소를 부여하는 것이 가능

>> 또한 하나의 가상 서버에 여러 개의 논리 포트를 할당할 수 있음

>> 이러한 논리 포트는 서버를 가상 네트워크에 연결할 때만 쓰는 것이 아니라 가상 네트워크와 가상 라우터를 연결할 때도 사용

7.1.6 시큐리티 그룹

 

시큐리티 그룹

>> 가상 서버에 들어가고 나가는 트래픽을 필터링하는 역할

 

시큐리티 그룹의 규칙

>> 방화벽 규칙에는 트래픽이 발생하는 방향(입력, 출력)과 프로토콜의 종류, 포트 번호, 통신 상대를 지정할 수 있음

 

방화벽 규칙에 시큐리티 그룹 지정

>> 클라우드에서는 특정 역할을 하는 서버의 대수를 늘리거나 줄여야 하는 경우가 종종 발생

>> 이런 상황에 통신 상대를 시큐리티 그룹으로 지정하는 방식을 사용하면 보다 효율적인 시큐리티 그룹 관리가 가능

 

7.1.7 NACL (네트워크 액세스 컨트롤 리스트)

>> AWS에서는 서브넷에 대해 필터링을 하는 NACL 이라는 기능이 있음

>> 네트워크를 설계할 때, 서브넷에 역할을 부여하게 되는데 명시적으로 패킷 필터링을 하거나 권한을 분리하는 것이 가능

 

7.2 네트워크 리소스와 API

 

7.2.1 네트워크를 구성하기 위한 API의 처리 흐름

 

* Neutron의 API 실행방식

>> 네트워크와 서브넷, 포트 각각에 대응하는 URL ('https://{network}/v2.0/networks.json', 'https://{network}/v2.0/subnets.json', 'https://{network}/v2.0/ports.json') 으로 JSON 데이터를 전달하기만 하면 됨

>> 가상 네트워크를 만들 때는 네트워크의 이름 정보만 전달하면 네트워크가 생성되는 반면, 서브넷을 만들 때는 CIDR과 게이트웨이의 IP주소, 서브넷이 할당될 가상 네트워크의 UUID 정보도 전달해야 함

>> 가상 라우터를 만들 때는 이름 정보만 전달하면 되고 서브넷을 연결할 때는 가상 라우터 리소스에 서브넷 정보를 PUT하면 됨

>> 마지막으로 가상 라우터를 외부 L2 네트워크와 연결하면 됨

>> 외부 L2 네트워크도 다른 일반 가상 네트워크와 마찬가지로 UUID를 가지고 있고 이것을 가상 라우터에 연결함으로써 인터넷과 같은 외부 망과의 통신이 가능하게 됨

 

* AWS의 API 실행방식

>> 가상 네트워크 전체를 의미하는 VPC를 만드는 CreateVPC API를 호출

>> 생성된 VPC에 대해 CreateSubnet이나 CreateNetworkInterface API를 호출

>> 이후 논리 포트를 가상 서버에 연결하면 가상 서버는 그 즉시 통신이 가능한 상태가 됨

 

7.2.2 네트워크 안에 서버를 할당하기 위한 API의 처리 흐름

 

실제로 네트워크 API는 가상 서버를 생성할 때 함께 실행되는 경우가 많은데,

이때 서버와 어떤 식으로 연계가 되는지를 오픈스택을 예로 들어 설명

 

<Nova가 가상 서버를 생성하면서 Neutron과 연계 처리하는 과정>

1) 사용자로부터 Nova에 가상 서버를 생성하라는 API가 전달됨

2) Nova는 요청된 데이터가 유효한지 확인하기 위해 데이터 검증 수행

>> 이때 네트워크나 시큐리티 그룹에 관한 질의는 Neutron에게 보내짐

3) 지정한 플레이버로 기동할 수 있는 서버를 찾았다면 Neutron에 논리 포트를 생성해줄 것을 요청

4) 논리 포트 생성 요청을 받은 Neutron은 논리 포트에 IP 주소, MAC 주소 등을 할당한 후, Nova에게 알려줌

>> IP 주소는 서브넷의 IP 주소 범위 안에서 사용 가능한 것이 할당되며, 가상 서버가 기동될 때 DHCP를 통해 부여 받게 됨

5) Neutron으로부터 논리 포트가 생성되었다는 응답을 Nova가 받게 되면 가상 서버 기동에 필요한 모든 정보들이 준비되었다고 판단함(준비가 된 것일 뿐, 가상 서버가 아직 만들어진 상태는 아님)

6) 가상서버를 기동할 준비 시작

>> Nova가 가상 서버의 인터페이스를 만들고, 하이퍼바이저상의 브릿지에 연결

>> Nova는 대기 상태

7) Neutron은 가상 서버의 인터페이스가 브릿지에 연결되었다는 것을 알게 되고 Neutron API를 통해 전달된 정보를 참고하여 가상 서버의 인터페이스를 적절한 가상 네트워크로 연결

8) 논리 포트에 대해서도 IP 스푸핑(IP 위변조) 방어를 위한 설정을 한 다음, 시큐리티 그룹도 적용

9) 이러한 Neutron 작업이 완료되면 Nova에 논리 포트가 준비되었다고 통보

10) 대기 상태였던 Nova는 이통보를 받은 후에야 실제 가상 서버를 생성하는 수순을 밟게 됨

>> 클라우드 환경의 API는 기능을 호출하는 것뿐만 아니라 현재 상태를 통보하여 다른 리소스와의 연계 처리도 할 수 있음

7.3 네트워크 리소스의 내부 구성

 

클라우드 환경에서 네트워크를 조작할 때 가상 네트워크가 어떻게 만들어지는지 알아보자

 

7.3.1 클라우드에서의 네트워크 분리

 

>> 클라우드 환경은 멀티 테넌트를 지원하기 때문에 여러 사용자들이 같은 서브넷을 사용해도 충돌이 나지 않도록 만들어져 있음

>> 네트워크의 분리

: Neutron >> 사용하는 드라이버에 따라 다양한 네트워크 기기 제어 가능

: 리눅스 오픈소스 OVS(Open vSwitch)를 내부적으로 활용

 

* 가상 네트워크를 제어하는 프로세스

1) 오픈스택에서 사용자가 실행한 API >> 컨트롤러 노드 (nova-api) >> AMQP >> 컴퓨트 노드 (nova-compute : kvm)

2) 오픈스택에서 사용자가 실행한 API >> 컨트롤러 노드 (neutron-server) >> AMQP >> 컴퓨트 노드 (L2-agent : OVS)

 

* 여러 노드를 가진 테넌트의 가상 네트워크

(교재의 예시)

두 개의 테넌트가 있고 각 테넌트의 서브넷이 같은 IP 주소 범위를 갖고 있음

각 테넌트는 두 대의 가상 서버를 기동하고 있음

각각은 서로 다른 컴퓨트 노트에 배치되어 있음

각 테넌트에 배치된 가상 서버는 서로 같은 IP 주소가 할당되어 있음

>> 충돌이 발생하더라도 문제가 되지 않는 구조

 

* 네트워크 식별

>> 가상 서버에서 전송되는 패킷은 연결된 가상 인터페이스를 보고 자신이 어떤 네트워크에 속해 있는지 알 수 있음

>> 해당 패킷이 가상 네트워크에서 나왔다는 것을 알 수 있도록 VLAN ID를 패킷에 할당

>> 같은 컴퓨터 노드 안에서는 서로 다른 가상 네트워크들의 서로 다른 VLAN ID를 가지기 때문에 결과적으로 네트워크를 격리하는 효과

>> 같은 호스트 안에서 같은 IP 주소를 사용하더라도 패킷의 VLAN ID로 구분이 가능하여 충돌 발생 없음

 

7.4 네트워크 리소스의 컴포넌트

 

7.4.1 네트워크 리소스의 컴포넌트

 

네트워크 리소스

: 스위치, 서브넷, 라우터, 포트, 시큐리티 그룹, NACL로 구성

 

클라우드 환경에서 시스템 구축 시, 네트워크 시큐리티 상당히 중요

>> 네트워크 설계와 필터링 정책 검토 필수

 

7.4.2 클라우드 네트워크와 SDN

 

SDN?

: 기존에 물리적인 인프라 환경에서 일체형으로 구성되어 있었던 제어를 담당하는 컨트롤러와 전송을 담당하는 데이터 플랜을 서로 분리한 다음, API를 통해 이들을 제어하겠다는 개념

 

SDN 구성요소

: 클라우드 네트워크 컨트롤러, 네트워크 오케스트레이터, 네트워크 장비

 

* 클라우드 네트워크 컨트롤러

1) 클라우드에서 가상 네트워크를 동작시키기 위해 태스크들을 실행하는 역할

(ex) 컴퓨트 리소스와 비교

네트워크 오케스트레이터 = 가상 서버를 구현하는 하이퍼 바이저

클라우드 네트워크 컨트롤러 = 오픈스택 Nova

2) 사용자에게 일관된 API 모델을 제공하는 역할

>> Neutron 또는 AWS VPC의 API가 여기에 해당