한 서버의 성능이 모든 요청을 처리하기에 충분하지 않고 소프트웨어 제조업체가 로드 밸런싱을 제공하지 않는 경우 어떻게 해야 합니까? 로드 밸런서 구매부터 요청 수 제한까지 다양한 옵션이 있습니다. 어느 것이 옳은지는 기존 조건을 고려하여 상황에 따라 결정되어야 합니다. 이 글에서는 예산이 제한되어 있고 무료 서버가 있는 경우 무엇을 할 수 있는지 알려드리겠습니다.

서버 중 하나의 부하를 줄여야 하는 시스템으로 InfoWatch의 DLP(정보 유출 방지 시스템)를 선택했습니다. 구현의 특징은 "전투"서버 중 하나에 밸런서 기능을 배치하는 것입니다.

우리가 직면한 문제 중 하나는 소스 NAT(SNAT)를 사용할 수 없다는 것입니다. 이것이 필요한 이유와 문제가 어떻게 해결되었는지 자세히 설명하겠습니다.

따라서 초기에 기존 시스템의 논리 다이어그램은 다음과 같습니다.

사용자 컴퓨터의 ICAP 트래픽, SMTP, 이벤트는 Traffic Monitor(TM) 서버에서 처리되었습니다. 동시에 데이터베이스 서버는 TM에서 이벤트를 처리한 후 부하를 쉽게 처리했지만 TM 자체의 부하가 컸다. 이는 DM(Device Monitor) 서버의 메시지 대기열 모양과 TM의 CPU 및 메모리 로드를 통해 분명해졌습니다.

얼핏 보면 이 방식에 다른 TM 서버를 추가하면 ICAP나 DM 중 하나로 전환할 수 있지만 내결함성이 떨어지기 때문에 이 방법을 사용하지 않기로 결정했습니다.

솔루션 설명

적합한 솔루션을 찾는 과정에서 우리는 무료로 배포되는 소프트웨어를 선택했습니다. 킵얼라이브 와 LVS. Keepalived는 장애 조치 클러스터 생성 문제를 해결하고 LVS 밸런서를 관리할 수도 있기 때문입니다.

우리가 달성하고자 했던 것(TM의 부하를 줄이고 현재 수준의 내결함성 유지)은 다음 구성표에 따라 작동했어야 합니다.

기능을 확인한 결과 서버에 설치된 사용자 정의 RedHat 어셈블리가 SNAT를 지원하지 않는 것으로 나타났습니다. 우리의 경우에는 SNAT를 사용하여 들어오는 패킷과 이에 대한 응답이 동일한 IP 주소에서 전송되는지 확인하려고 계획했습니다. 그렇지 않으면 다음 그림이 표시됩니다.

이것은 용납될 수 없습니다. 예를 들어 VIP(가상 IP) 주소로 패킷을 보낸 프록시 서버는 VIP로부터 응답을 기대하지만 이 경우 백업으로 보낸 세션에 대한 응답은 IP2에서 옵니다. 해결책을 찾았습니다. 아래와 같이 백업에 또 다른 라우팅 테이블을 만들고 두 개의 TM 서버를 별도의 네트워크에 연결해야 했습니다.

설정

우리는 ICAP, SMTP, TCP 9100 서비스를 갖춘 두 대의 서버와 그 중 하나에 로드 밸런서를 설치하는 방식을 구현할 것입니다.

표준 리포지토리와 일부 패키지가 제거된 두 개의 RHEL6 서버가 있습니다.

균형을 맞춰야 하는 서비스:

• ICAP – TCP 1344;

• SMTP – TCP 25.

DM의 트래픽 전송 서비스 – tcp 9100.

먼저 네트워크를 계획해야 합니다.

가상 IP 주소(VIP):

• IP: 10.20.20.105.

서버 TM6_1:

• 외부 IP: 10.20.20.101;

• 내부 IP: 192.168.1.101.

서버 TM6_2:

• 외부 IP: 10.20.20.102;

• 내부 IP: 192.168.1.102.

그런 다음 두 개의 TM 서버에서 IP 전달을 활성화합니다. 이를 수행하는 방법은 RedHat에 설명되어 있습니다. 여기에.

우리는 어떤 서버를 메인 서버로, 어떤 서버를 백업 서버로 사용할 것인지 결정합니다. 마스터는 TM6_1, 백업은 TM6_2로 설정합니다.

백업 시 새로운 밸런서 라우팅 테이블과 라우팅 규칙을 생성합니다.

[root@tm6_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[root@tm6_2 ~]ip rule add from 192.168.1.102 table balancer
[root@tm6_2 ~]ip route add default via 192.168.1.101 table balancer

위 명령은 시스템이 재부팅될 때까지 작동합니다. 재부팅 후에도 경로가 유지되도록 하려면 경로를 입력할 수 있습니다. /etc/rc.d/rc.local., 그러나 설정 파일을 통해 더 좋습니다 /etc/sysconfig/network-scripts/route-eth1 (참고: 여기서는 다른 구문이 사용되었습니다).

두 TM 서버 모두에 keepalived를 설치하십시오. 배포 소스로 rpmfind.net을 사용했습니다.

[root@tm6_1 ~]#yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/keepalived-1.2.13-5.el6_6.x86_64.rpm

Keepalived 설정에서는 서버 중 하나를 마스터로 할당하고 다른 하나를 백업으로 할당합니다. 그런 다음 로드 밸런싱을 위해 VIP와 서비스를 설정합니다. 설정 파일은 일반적으로 다음 위치에 있습니다. /etc/keepalived/keepalived.conf.

TM1 Server 설정

vrrp_sync_group VG1 { 
   group { 
      VI_1 
   } 
} 
vrrp_instance VI_1 { 
        state MASTER 
        interface eth0 

        lvs_sync_daemon_inteface eth0 
        virtual_router_id 51 
        priority 151 
        advert_int 1 
        authentication { 
                auth_type PASS 
                auth_pass example 
        } 

        virtual_ipaddress { 
                10.20.20.105 
        } 
}

virtual_server 10.20.20.105 1344 {
    delay_loop 6
    lb_algo wrr 
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.101 1344 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 1344
        nb_get_retry 3
        delay_before_retry 3
        }
    }

    real_server 192.168.1.102 1344 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 1344
        nb_get_retry 3
        delay_before_retry 3
        }
    }
}

virtual_server 10.20.20.105 25 {
    delay_loop 6
    lb_algo wrr 
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.101 25 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 25
        nb_get_retry 3
        delay_before_retry 3
        }
    }

    real_server 192.168.1.102 25 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 25
        nb_get_retry 3
        delay_before_retry 3
        }
    }
}

virtual_server 10.20.20.105 9100 {
    delay_loop 6
    lb_algo wrr 
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.101 9100 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 9100
        nb_get_retry 3
        delay_before_retry 3
        }
    }

    real_server 192.168.1.102 9100 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 9100
        nb_get_retry 3
        delay_before_retry 3
        }
    }
}

TM2 Server 설정

vrrp_sync_group VG1 { 
   group { 
      VI_1 
   } 
} 
vrrp_instance VI_1 { 
        state BACKUP 
        interface eth0 

        lvs_sync_daemon_inteface eth0 
        virtual_router_id 51 
        priority 100 
        advert_int 1 
        authentication { 
                auth_type PASS 
                auth_pass example 
        } 

        virtual_ipaddress { 
                10.20.20.105 
        } 
}

트래픽 균형을 맞추는 LVS를 마스터에 설치합니다. 구성에 서버가 두 개뿐이므로 두 번째 서버에 밸런서를 설치하는 것은 의미가 없습니다.

[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpm

밸런서는 우리가 이미 구성한 keepalived에 의해 관리됩니다.

그림을 완성하기 위해 두 서버 모두에서 자동 시작을 위해 keepalived를 추가해 보겠습니다.

[root@tm6_1 ~]#chkconfig keepalived on

결론

결과 확인

두 서버 모두에서 keepalived를 실행해 보겠습니다.

service keepalived start

VRRP 가상 주소의 가용성 확인

VIP가 마스터에 있는지 확인합시다.

그리고 백업에는 VIP가 없습니다.

ping 명령을 사용하여 VIP의 가용성을 확인합니다.

이제 마스터를 종료하고 명령을 다시 실행할 수 있습니다 ping.

결과는 동일하게 유지되어야 하며 백업 시 VIP가 표시됩니다.

서비스 밸런싱 확인 중

예를 들어 SMTP를 살펴보겠습니다. 10.20.20.105에 대한 두 개의 연결을 동시에 시작하겠습니다.

telnet 10.20.20.105 25

마스터에서는 두 연결이 모두 활성화되어 있고 다른 서버에 연결되어 있는지 확인해야 합니다.

[root@tm6_1 ~]#watch ipvsadm –Ln

따라서 우리는 TM 서버 중 하나에 밸런서를 설치하여 TM 서비스의 내결함성 구성을 구현했습니다. 우리 시스템의 경우 이를 통해 TM에 대한 부하가 절반으로 줄어들었고, 이를 통해 시스템을 사용하여 수평 확장이 부족했던 문제를 해결할 수 있었습니다.

대부분의 경우 이 솔루션은 추가 비용 없이 신속하게 구현되지만 UDP 트래픽 균형을 조정할 때와 같이 구성에 많은 제한과 어려움이 있는 경우도 있습니다.

출처 : habr.com