Es irrt der Mench, solange er strebt.

Persistence

- 어플리케이션이 사용 중인 세션을 같은 서버에 지속적으로 할당하는 기능.

- 하나의 서버에서 처리하고 있던 것을 처리 도중 다른 서버로 부하분산시키면 처리 자체에 정합성이 맞지 않음.

ex) 쇼핑몰 - '장바구니에 넣고 정산한다' 라는 일련의 동작을 하나의 세션, 하나의 처리로 간주하고 지속적으로 하나의 서버에만 할당하여 처리 정합성을 보장.

* Cookie Persistence 장비에 따라서 Persistence Record를 작성하지 않는 경우가 있음. Persistence Record를 만들지 않는 경우는 Cookie 정보만 보고 Persistence를 실행.

1.  출발지 IP Persistence

접속 클라이언트 IP주소를 사용해 동일한 서버에 지속적으로 할당하는  L3 Persistence. L3 계층으로 서비스를 거치지 않아 알기 쉬운 구성. 일정 시간 사용하지 않으면 해당 레코드를 삭제. 시간은 너무 짧으면 다른 서버에 할당, 너무 길면 장치나 서버에 부하가 걸릴 수 있음. NAPT환경이나 Proxy 서버를 경유하는 환경에서는 한 대의 서버에 수많은 접속이 할당되는 단점. 

2. 목적지 IP Persistence

서버의 IP 주소를 기준으로 같은 서버에 할당하는 L3 Persistence. 서버 부하분산 환경 보다 회선 부하분산 환경에서 많이 사용.

3. Cookie Persistence

HTTPS와 SSL 가속 환경의 HTTPS에서만 유효한 L7 Persistence. 쿠키가 가진 정보를 기준으로 일정 시간 세션을 지속. 클라이언트마다 유연하게 세션을 유지할 수 있어서 HTTP 부하분산 시 자주 사용.

4. HTTP Header Persistence

부하분산 방식 2

3.3 서버 감시 기능 

- 서버 감시 기능에는 'L3 체크', 'L4 체크', 'L7체크' 세 가지 종류가 있고, 계층이 높은수록 유연하고 상세한 서버 상태 감시가 가능.

3.3.1 L3 체크(IP주소 체크)

- IP주소 상태를 감시하는 기능. ICMP 사용

3.3.2 L4 체크(서비스 체크)

- 포트 번호를 감시하는 기능. TCP/UDP 감시

3.3.3 L7 체크(어플리케이션  체크)

- 어플리케이션 감시. 서버 어플리케이션의 특정 응답 여부를 감시.

ex) http 상태 코드

- 웹 어플리케이션이 정상적으로 동작하고 있으며 HTTP 상태 코드'200 OK'로 응답하고, 응답 구문 안에 문자열로 포함 함. 어플리케이션에 문제가 있을 경우 '503'의 500번대 응답이 발생. 웹 페이지 내에 컨텐츠가 존재하지 않는 경우는 '404'와 같이 400번대 응답이 발생. L7 체크는 200번 이외의 상태가 돌아오면 서버를 서비스로 부터 격리.

- 유연한 감시가 가능하나 서버 부하가 올라감. 예를 들면 HTTPS 서버 감시의 경우 외부 침입 방지를 위해 SSL 핸드 쉐이크라는 처리를 사용해 접속. SSL 핸드쉐이크는 SSL키 교환 처리를 포함하고 있어 서버에 큰 부하가 걸림.

부하분산 방식

1. 부하분산 방식 개요

 1.1. 정적 부하분산 방식

 1) 정의

  - 클라이언트로부터 리퀘스트를 받으면 서버 상태와 상관없이 서버가 가지고 있는 설정을 기준으로 할당하는 방식.상시 변하는 서버 상태를 전혀 고려하지 않고 단순히 서버에 할당함으로써 다음 순서로 할당할 서버를 예측하기 쉬움.

  a) 라운드 로빈

  - 클라이언트로부터 받은 리퀘스트를 부하분산 대상 서버에 순대대로 할당하는 방식. 부하분산 대상 서버의 성능이     동일하고 처리 시간이 짧은 어플리케이션의 경우 균등하게 분산이 이루어지기 때문에 이 방식을 사용.

  - 라운드 로빈 방식 

   - 라운드 로빈 방식 단점

      부하분산 대상의 서버의 성능이 다른 경우에 FTP나 Persistence(세션유지기능)가 필요한 어플리케이션의 경우         서버 처리와 관계없이 세션이 할당되는 라운드 로빈 방식은 적합하지 않음.

   b) 가중치(ratio) - 부하분산 대상 서버의 성능에 차이가 있을 때

   - 서버별로 비율을 설정해 두고, 그 가중치에 따라 리퀘스트를 서버에 할당하는 방식. 부하분산 대상 서버의 성능이       동일하지 않으며, 동일한 처리를 한다고 해도 처리 시간에 차이가 발생. 이런 경우 성능이 높은 서버에 높은 가중       치를, 성능이 낮은 서버에 낮은 가중치를 설정하고, 높은 성능의 서버가 많은 처리를 하도록 함. 

   c) 액티브-스탠바이 (Priority Group Activation) - 서버 이중화 개념

   - 서버를 액티브와 스탠바이 상태로 나누어 평상시에는 액티브 장치만 사용. 액티브 장치에 문제가 발생했을 때 스       탠바이 장치로 할당.    

  2.2 동적 부하분산 방식

  1) 정의

  - 클라이언트로부터 리퀘스트를 받으면, 서버 상태에 따라 할당할 대상 서버를 결정하는 방식. 서버나 클라이언트의      상태에 따라 어느 서버에 할당할 것인가를 결정하기 때문에 다양한 프로토콜과 어플리케이션에 유연하게  대처.

   a) 최소 연결 수(Least Connection)

   - 연결이 가장 적은 서버에 리퀘스트를 할당.부하분산 장치는 각 서버에 대한 연결 정보를 가지고 잇고 부하분산 장       치가 리퀘스트를 받는 시점에서 가장 연결 수가 적은 서버를  선택하여 리퀘스트를 할당.

   b) 최소 응답 시간

   - 가장 빨리 응답하는 서버에 리퀘스트를 할당하는 방식. 어떤 서버라도 처리 가능량을 넘게 되면 처리 대기 시간이       길어지고 반응 속도 자체가 느려지게 됨. 부하분산 장치는 클라이언트로부터 전달받은 리퀘스트와 서버 응답 사         이의 시간을 항상 확인있다 리퀘스트를 받으면 가장 빠르게 응답하는 서버를 선택 할당.

   c)  최소 부하

   - Least Loaded 방식은 SNMP에서 취득한 정보를 기준으로 할당한 서버를 결정하는 방식. 부하분산 장치는 SNMP의 매니저가 되어 CPU사용률잉나 메노리 사용량 등 서버 부하에 관한 정보를 정기적으로 수집. 부하분산 장치가 리퀘스트를 받으면 취득한 정보를 바탕으로 부하가 가장 적어 보이는 서버에 할당.

   - 정보 신뢰성은 높지만 실시간 정보가 아님.

** 어떤 부하 분산 방식을 선택할 것인가?

서버 성능과 프로토콜, 어플리케이션 특성 등 여려가지 요소를 고려해서 결정.

단순히 클라이언트 화면을 표시하는 웹사이트이면서 부하분산하는 서버 성능이 동일 -> 라운드 로빈

처리별 tcp 연결 수가 긴 FTP나 세션유지기능이 필요한 웹사이트라면 - 최소 연결 수 방식

등 환경에 따라 적절히 선택이 필요

NAT

NAT (Network Address Translation)

'서버 부하분산 기술의 기본은 목적지 NAT이다'

1. NAT의 정의

 - 패킷의 네트워크 주소(IP)를 변환하는 기술.

2. NAT 종류

 1) 표준 NAT

 - 정적 NAT : 내부와 외부 IP주소를 일대일로 변환.

 - 동적 NAT : 내부에서 외부로 접속할 때 출발지 IP주소를 다수 준비해 두었다가 그 중 하나를 선택.

    정적 NAT가  반드시 같은 IP주소로 변환된다면, 동적 NAT는 변환하는 대상 IP주소가 바뀜.

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

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

    어떤 클라이언트가 어떤 포트 번호를 이용하는가를 확인 후 패킷을 할당하기에 다대일 변환이 가능.

 3) Twice NAT

 - 출발지만이 아니라 목적지까지 한 번에 바꿈. 

 - 회사가 합병된다거나 다른 회사 시스템과 통합되는 등 주소 범위가 중복되어 구성되는 때.

서버부하분산 개요

1. 서버 부하분산의 정의

- 서버 부하란? 서버관리 그 자체. 서버가 어떤 처리를 시작하면 CPU나 디스크 등 수많은 부품들이 동작하게 되고, 그 하나하나가 바로 서버 부하가 됨.

- 분산? 동일한 서비스(HTTP, FTP 등)를 제공하고 있는 복수의 서버에 작업을 분배하는 것을 말함.

   클라이언트 접속으로 서버 부하가 발행하며 클라이언트 접속을 분산함으로써 처리 부하를 복수의 서버에 분산시킴.

2. 서버 부하분산의 이점

 1) 처리 능력 향상

 - Scale-up: 서버 자체의 능력을 향상 시킴.

 - Scale-out : 처리할 수 있는 서버의 수를 증가 시킴.

 2) 장애대처 능력 향상

 - 멈추지 않는 시스템. 한 대의 서버가 다운돼도 그 서버를 격리시켜 다른 서버가 서비스를 제공할 수 있게 됨.

 3) 유지관리 효율 향상

 - 여러 대의 서버를 한 대씩 작업(패치,업데이트 등)이 가능하며, 작업 동안 다른 서버가 서비스를 지속할 수 있음.

3. 서버 부하분산 기술

 1) DNS 라운드 로빈

 - DNS 라운드 로빈(DNS Round Robin)은 DNS 서버 자체 기능으로 부하 분산을 구현.

 하나의 이름에 대한 복수의 IP 주소를 DNS 서버에 등록해 두고, 클라이언트로부터 요청이 오면 등록된 IP주소를 '순서대로'(Round Robin) 전달하는 방식. 전달되는 IP주소가 바뀌기 때문에 개별 클라이언트가 접속하는 서버 IP주소가  달라짐.

- 문제점: 서버 장애가 발생해도 알기 어렵다. DNS 서버는 접속 서버의 장애를 알 수 없음 -> 클라이언트 접속 장애

  균등하게 부하분산을 하지 않는다. (클라이언트의 캐쉬 - 캐쉬가 없어질 때 까지 클라이언트는 동일 서버에 접속) 

 2) OS 타입

 - OS가 가지고 있는 자체 기능(서비스)으로 부하분산 구현. -

 - Windows Server 2008 의 NLB(Network Load Balancing),리눅스 LVS(Linux Virtual Server)

 - 클러스터 서비스의 부속 기능으로 복잡한 부하분산 구현은 어렵고, 적은 비용으로 부하분산 기능 구현 가능.

 - 모드에 상관 없이 서버와도 통신을 하므로 비효율적이지만 작은 규모 사이트에서 사용하기에는 문제 없음.

 3) 어플라이언스 타입

 - 부하분산 장치(로드밸런서)라는 부하분산 전용 장비를 사용해서 구현.

 - F5 Networks의 BIG-IP, Citrix의 NetScale, Cisco의 ACE 4700 시리즈 등

 - 클라이언트로부터 오는 모든 트래픽을 일단 부하분산 장비에 저장해둔 후 그것을 배후에 있는 서버로 흘려 보냄. 

 - 전달받은 연결을 호율화한다거나 암호화된 연결을 복호화하는 기능도 있음.

4. 고급 서버 부하분산 

 1) 회선 부하분산

 - 복수의 인터넷 회선을 전부 사용하고 싶을 때 적용 가능한 기술.

  a. A사 B사, 두 개의 인터넷 회선이 있을 때 라우터와 방화벽만으로 구성하면 Active-Standby 구성만 가능.

  PBR이나 MVRRP(Multiple Virtual Router Redundancy Protocol)와 같은 기술을 사용함으로써 Active-Active 구성이 가능하나 확장성의 문제나 운용 복잡성이 있음.

  b. 라우터 앞단에 부하분산 장비를 둠으로써 양쪽 회선에 트래픽을 분배, 양쪽 인터넷 회선을 Active-Active로 사용.

 2) 광역 부하분산

 - 물리적으로 다른 장소에 있는 서버를 부하분산하는 기술.

 - 부하분산 장치가 DNS  서버가 되어 각 사이트의 상태를 감시하고, 그 결과를 기반으로 IP주소를 변경하여 부하분산. 최근에는 부하분산 기술이라기보다 DR(Disaster Recovery) 목적으로 사용하는 경우가 많아지고 있음.