[따라하며 배우는 서버 부하분산 입문] 서버 부하분산 2번째

NAT

• IP 주소를 변환하는 기술

가장 흔한 NAT 예시

•  내부에서는 사설 IP를 쓰고, 외부랑 통신할 때 NAT를 해서 공인 IP로 통신

 

NAT의 종류

1. 표준 NAT

1-1. 정적 NAT

내부 : 외부 = 1:1 변환

1-2. 동적 NAT

IT 엔지니어릉 위한 네트워크 입문에 따르면,,,, 

출발지나 목적지 어느 경우든 사전에 정해지지 않고 NAT를 수행하는 것을 동적 NAT라고 함

-> 최소한 출발지나 목적지 중 한 곳이 다수의 IP로 구성됨

-> NAT가 필요할 때 IP 풀에서 어떤 IP로 매핑될 것인지 판단해 NAT를 수행하는 시점에 NAT 테이블을 만들어 관리

참고 : https://zigispace.net/1122

따라하며 배우는 서버 부하분산에서는,,,,,,

source ip 가 여러 개 인 것..

-> 외부 IP 주소를 5개 준비해뒀다면 5대의 클라이언트만이 외부에 접속할 수 있음.????

2. NAPT(Network Address Port Translation) == IP Masquerade  / PAT(Port Address Translation)

내부와 외부 ip 주소를 n:1로 변환
내부에서 외부로 접속할 때, 출발지 IP 주소 뿐만 아니라 포트도 변환

3. Twice NAT

출발지 뿐만 아니라 목적지 주소도 변환

 

NAT를 활용한 서버 부하분산 기술

- 그림에서 부하분산 장치 == virtual server

F5 장비의 virtual server 메뉴

- 클라이언트는 virtual server로 request를 보냄

- 부하분산 장치의 virtual server가 request를 받으면 VIP로 설정된 destination IP가 대상 서버의 실제 IP 주소로 변환하게 됨

--> 반대방향 통신은?

책에서 기본 게이트웨이인 부하분산 장치로 돌려보낸다...?

--> proxy : source ip를 vip로 변경 (inline)

 

---

부하분산 방식

- 어떤 리얼 서버에 연결할 것인가?

부하분산 방식 정리 표(따라하며 배우는 서버 부하분산 입문)

1. 정적 부하방식

- 서버 상태와 상관 없이 서버가 가지고 있는 설정을 기준으로 할당

1-1. 라운드 로빈

- 클라이언트로부터 받은 리퀘스트를 부하분산되는 리얼 서버에 순서대로 할당하는 것
- 처리 시간이 짧은 경우, 아무 서버에 접근해도 됨
- 처리 시간이 길 경우(FTP 등), 하나의 real server에 연결되면 계속 그 서버에만 연결되어야 함
  --> 이때는 persistence(세션 유지 기능)을 사용해야 함
  --> 라운드 로빈 방식이 적합하지 않음

1-2. 가중치 

- 서버 별로 비율을 설정해두고, 그 가중치에 따라 request를 서버에 할당
- real server의 성능이 동일하지 않을 때 사용

1-3. active-standby(priority group acivation)

- 서버를 액티브와 스탠바이로 상태로 나누어 평상시에는 액티브 장치만 사용
- 액티브 장치에 장애가 발생하면 스탠바이 장치로 할당
- 서버 이중화

 

2. 동적 부하분산 방식

- 클라이언트로부터 request를 받으면, 서버 상태에 따라 할당할 대상 서버를 결정하는 방식

2-1. 최소 연결 수(Least Connection)

- 연결이 적은 서버에 request를 할당하는 방식
- persistence를 사용하는 경우에 적합?!!!

2-2. 최단 응답 시간

- 가장 빨리 응답하는 서버에 request를 할당
- 서버가 처리 가능량을 넘기면 처리 대기 시간이 길어지고, 반응 속도가 느려짐 <- 이 점을 활용

2-3. 최소 부하(Least Loaded)

- SNMP 에서 취득한 정보를 기준으로 할당할 서버를 결정하는 방식
- CPU 사용률이나 메모리 사용량 등 서버 부하에 관한 정보를 정기적으로 수집
- 실시간 정보가 아님

---

서버 감시 기능

- health check

- LoadBalancer에서 서버의 상태도 항상 확인함

- check 주기 : 감시간격을 짧게 할수록 장애 인식 시간이 빨라지지만 서버 부하가 높아짐

BIG-IP에서 health Monitor 메뉴

1. L3 health check

- IP ping check로 서버가 살아있는지 확인

2. L4 health check

- TCP, UDP port 확인

- telnet으로 접속하는 것과 비슷

3. L7 healch check 

- 어플리케이션까지 감시하는 기능

- ex. http를 사용한다면, http 상태 코드로 health check

- https의 경우, ssl 인증까지 이루어져야 하기 때문에 https로 health check하는 것은 추천하지 않음