본문 바로가기
서버인프라/엔진엑스

[ 제4강 TCP&UDP부하 분산 ] NGINX 로드 벨런서

by techwold ted 2021. 1. 22.

TCP & UDP 부하분산을 위한 전제조건

  •  NGINX 오픈소스 --with-stream 활성
  •  TCP 또는UDP를 통해 통신하는 애플리케이션 데이터베이스 또는 서비스

역방향 프록시 구성

1. 최상위 stream {} 블록 만들기

stream {

}

2. server {} 최상위 stream {}  각 가상 서버에 대해 하나 이상의 구성 블록을 정의 합니다.

3. server {} 각 서버의 구성 블록 내에 서버가 수신 listen 하는 IP 주소 및 / 또는 포트를 정의하는 지시문을 포함 합니다. UDP 트래픽의 경우 udp 매개 변수도 포함 합니다., TCP 가 stream  컨텍스트의 기본 프로토콜 이므로 지시문에 대한 tcp 매개 변수가 없습니다. 

stream {

    server {
        listen 12345;
        # ...
    }

    server {
        listen 53 udp;
        # ...
    }
    # ...
}

4. proxy_pass 프록시 서버 또는 서버가 트래픽을 전달하는 업스트림 그룹을 정의하는 지시문을 포함합니다.

stream {

    server {
        listen     12345;
        #TCP traffic will be forwarded to the "stream_backend" upstream group
        proxy_pass stream_backend;
    }

    server {
        listen     12346;
        #TCP traffic will be forwarded to the specified server
        proxy_pass backend.example.com:12346;
    }

    server {
        listen     53 udp;
        #UDP traffic will be forwarded to the "dns_servers" upstream group
        proxy_pass dns_servers;
    }
    # ...
}

5. 프록시 서버에 여러 네트워크 인터페이스가 있을 경우 업스트림 서버에 연결할 때 특정 소스 IP 주소를 사용하도록 선택적으로 NGINX를 구성 할 수 있습니다. 이는 NGINX뒤의 프록시 서버가 특정 IP 네트워크 도는 IP주소범위의 연결을 수락하도록 구성된 경우 유용 할 수 있습니다. proxy_bind 적절한 네트워크 인터페이스의 지시문과 IP주소를 포함 합니다.

stream  { 
    # ... 
    server  { 
        listen      127.0.0.1 : 12345 ; 
        proxy_pass  backend.example.com : 12345 ; 
        proxy_bind  127.0.0.1 : 12345 ; 
    } 
}

6. 선택적으로 NGINX가 클라이언트 및 업스트림 연결 모두에서 데이터를 넣을 수 있는 두개의 인 메모리 버퍼크기를 조정할 수 있습니다. 데이터 양이 적으면 버퍼를 줄여 메모리 리소스를 절약 할 수 있습니다. 많은 양의 데이터가 있는 경우 버퍼 크기를 늘려 소켓 읽기 / 쓰기 작업 수를 줄일 수 있습니다. 한 연결에서 데이터가 수신되는 즉시 NGINX는 데이터를 읽고 다른연결을 통해 전달합니다. 버퍼는 다음 proxy_buffer_size 지시문으로 제어됩니다.

stream  { 
    # ... 
    server  { 
        listen             127.0.0.1 : 12345 ; 
        proxy_pass         backend.example.com : 12345 ; 
        proxy_buffer_size  16k ; 
    } 
}

TCP 또는 UDP 부하 분산 구성

1. 트래픽 부하가 분산 될 서버 그룹 또는 업스트림 그룹을 만듭니다.

   upstream {} 최상위 stream{} 컨텍스트에서 하나 이상의 구성 블록을 정의 하고 업스트림 그룹의 이름

   (예:   stream_backend TCP서버 및 dns_servers UDP 서버)를 설정합니다.

stream {

    upstream stream_backend {
        # ...
    }

    upstream dns_servers {
        # ...
    }

    # ...
}

역방향 프록시에 대해 위에서 proxy_pass 구성된 것과 같이 지시문에 업스트림 그룹의 이름을 참조하는지 확인하십시오

 

2. 업스트림 그룹을 업스트림 서버로 채웁니다. upstream{} 블록 내에서 server 각 업스트림 서버에 대한 지시문을 추가하여  IP주소 또는 호스트이름 (여러 IP주소로 해석 될 수 있음) 및 필수포트 번호를 지정합니다. 각 서버에 대해 프로토콜을 정의하지 마십시오, 이전에 생성 한 블록의 listen지시문을 포함 된 매개변수에 의해 전체 업스트림 그룹에 대해 정의되기 때문 입니다. 

stream {

    upstream stream_backend {
        server backend1.example.com:12345;
        server backend2.example.com:12345;
        server backend3.example.com:12346;
        # ...
    }

    upstream dns_servers {
        server 192.168.136.130:53;
        server 192.168.136.131:53;
        # ...
    }

    # ...
}

 

3. 업스트림 그룹에서 사용하는 부하분산 방법을 구성합니다. 다음 방법 중 하나를 지정할 수 있습니다.

   - 라운드 로빈 : 기본적으로 NGINX는 라운드 로빈 알고리즘을 사용하여 트래픽 부하를 분산하고 구성된 업스트림 그

                       룹의 서버로 순차적 전달 합니다. 기본 방법이기 때문에 round-robin 지시문이 없습니다.

   - 최소연결 : NGINX는 현재 활성 연결 수가 적은 서버를 선택합니다.

upstream stream_backend {
    hash $remote_addr;
    server backend1.example.com:12345;
    server backend2.example.com:12345;
    server backend3.example.com:12346;
}

4. 선택적으로 각 업스트림 서버에 대해 최대 연결 수, 서버 가중치 등을 포함한 서버 별 매개 변수를 지정합니다.

upstream stream_backend {
    hash   $remote_addr consistent;
    server backend1.example.com:12345 weight=5;
    server backend2.example.com:12345;
    server backend3.example.com:12346 max_conns=3;
}
upstream dns_servers {
    least_conn;
    server 192.168.136.130:53;
    server 192.168.136.131:53;
    # ...
}

다른 방법은 트래픽을 업스트림 그룹 대신 단일 서버로 프록시하는 것입니다.

호스트 이름으로 서버를 식별하고 여러 IP주소로 확인되도록 호스트 이름을 구성하면 NGINX는 Round Robin 알고리즘을 사용하여, IP주소에서 트래픽 부하를 분산 합니다. 이 경우 서버의 포트번호를 지정 proxy_pass 지침 및 IP주소 또는 호스트 이름 앞에 프로토콜을 지정합니다.

stream {
    # ...
    server {
        listen     12345;
        proxy_pass backend.example.com:12345;
    }
}

댓글