본문 바로가기
Development(Web, Server, Cloud)/Cloud : 실습

HAPROXY를 써보자

by tonyhan18 2022. 1. 18.
728x90

HAProxy

이제 HAProxy 구성을 해보자

 

이번에도 putty를 이용해 ssh>kex에서 Diffie-Hellman group 14,1을 최상위로 올리어 사용하자

```

vi /etc/haproxy/haproxy.cfg

```

 

lb

```

명령어 모드에서 d G  # 내용이 모두 삭제되었다.

```

global
   log /dev/log local0
   log /dev/log local1 notice
   chroot /var/lib/haproxy
   stats timeout 30s
   user haproxy
   group haproxy
   daemon

defaults
    log global
    mode http  #http에 대해서 트래픽 분배예정 -> FE와 BE 설정 필요
    option httplog
    option dontlognull
    timeout connect 5000  # 서버한테 생존여부를 물어본다. 5초마다(5000)
    timeout client 50000
    timeout server 50000

frontend http_front
    bind *:80  # 80번 포트로 접속하면 
    stats uri /haproxy?stats  
    default_backend http_back  # 이걸 http_back 으로 보내겠다.

backend http_back
    balance roundrobin  # 이 트래픽을 roundrobin으로 처리하겠다.
    server web1 192.168.1.101:80 check   # 여기에다가 서버 ip 입력 # 서버한테 생존여부를 물어본다.
    server web2 192.168.1.102:80 check #"backup"이 붙으면 대기상태로 남는다. 서버1이 죽으면 active로 바뀐다.
    # 만약 죽으면 제외시킨다. 나중에 생존 여부를 받으면 다시 보낸다.

 

저장하고 그 다음 일을 수행하자

 

고가용성 : 클라이언트가 필요로 하는 서비스, 리소스등을 적절한 시간에 즉시 제공해 줄 수 있는가? -> 고가용성은 일반적으로 Active/Standby(Active/Active)를 준비하여 Active가 처리하고 문제가 발생하면 대기중이던 Standby가 이를 이어바3아 Active가 된다. 클라이언트는 Active가 활성화, 비활성화 된 것에는 관심을 둘 필요 없이 서비스를 이용하기만 하면 된다.

 

standby는 두가지가 있다.1. cold standby : 죽었을때 부팅된다.2. hot standby : 전원키고 상시 대기

 

```

systemctl restart haproxy

systemctl enable haproxy

```

lb

주의할 점!!!

LB는 80번 포트로 들어온 웹접속 요청을 자신이 처리하는 것이 아니라 Backend로 포워딩해서 넘겨주어야 한다. 따라서 LB가 웹서비스(tcp/80)를 제공하고 있다면 자신이 그냥 처리를 해 버리므로 절대 웹서비스를 실행해서는 안된다.

 

HAProxy란? (tistory.com)

 

HAProxy란?

HAProxy HAProxy를 공부하기 앞서 로드밸런싱(Load Balancing)을 알아야한다. 로드밸런싱이란? 하나의 서비스에 대한 부하를 여러 서버로 분산하는 것 왜 로드밸런서가 필요할까 위 사진처럼 클라이언트

dev-youngjun.tistory.com

10.5 Load Balancer 만들기 - TheKoguryo's 기술 블로그

 

10.5 Load Balancer 만들기 - TheKoguryo's 기술 블로그

10.5 Load Balancer 만들기 Load Balancer 만들기 OCI 콘솔에서 내비게이션 메뉴를 엽니다. [Core Infrastructure] >> [Networking] >> [Load Balancers] 항목으로 이동합니다. Load Balancers를 생성할 Region과 Compartment를 확인

thekoguryo.github.io

 

보다시피 LB로 접속했는데 서버1 또는 서버2 중 하나가 동작했다.

 

서버에 접속해서 다음을 입력해서

```

tail -1f /var/log/httpd/access_log

```

web1, web2

위와같이 마지막 한줄짜리 접속 로그를 실시간 확인할 수 있다.

 

web1

재접속해보니 첫번쨰 서버에 반응이 왔다.

 

전체 동작 원리

1. 클라이언트가 http://www.test.com 에 접속

2. 클라이언트의 NIC에 저장된 DNS 서버인 8.8.8.8에게 www.test.com  의 주소를 물어본다.

3. DNS 서버는 www.test.com의  의 주소가 192.168.8.100이라고 알려준다.

4. 클라이언트는 192.168.8.100으로 웹접속하면 Load Balancer는 해당 연결을 일시적으로 대기시킨다.

5. backend 서버쪽으로 LB가 연결한다. 첫번째 연결은 BE의 첫번째 서버로 두번째 연결은 두번째 BE 서버로 연결된다.

6. BE에 있는 웹서버에게 index.html 파일을 요청하고 해당 내용을 lb에게 대기하고 있는 클라이언트에게 제공한다.

7. lb로 부터 index.html 내용을 전달받은 클라이언트는 해당 내용을 자신의 브라우저에 띄운다.

 

가용성 동작 상태 확인하기

1. web1의 192.168.1.101을 down 시킨다. ifdown ens33

2. 브라우저에서 웹접속을 계속해서 시도해 본다. 페이지는 정상적으로 연결되어야 한다.

3. 192.168.8.100/haproxy?stats 로 접속하여 session 수를 확인하며 한쪽만 올라가는 것을 확인할 수 있다.

 

 

위와같이 해당 주소로 가보니 접속 세션등의 정보를 확인할 수 있다.

 

그런데 우리는 NFS 가 없을때 서버를 어떻게 업데이트 할 것인가? 이건 git을 이용하면 된다.

 

자 이걸 AWS에 이 짓거리를 해보자

 

728x90