개발 이야기: load balance

20131020

Piranha as Load Balancer (Direct Routing Method)

am currently working on a web cluster project using CentOS. In this project, I have 2 web servers running on Apache and mounted the same document root to serve the HTTP content. I also have 2 servers in front of it to become the load balancer and failover to increase high availability of the two-node web server cluster. The virtual IP will be hold by load balancer #1 with auto failover to load balancer #2.

You may refer to diagram below to get clearer picture:

I am using following variables:

All servers’ OS: CentOS 6.2 64bit
Web server #1: 192.168.0.221
Web server #2: 192.168.0.222
Load balancer #1: 192.168.0.231
Load balancer #2: 192.168.0.232
Virtual IP: 192.168.0.220

Load Balancer Server

1. All steps should be done in both servers unless specified. We will install Piranha and other required packages using yum:

$ yum install piranha ipvsadm -y

2. Open firewall ports as below:

Piranha: 3636
HTTP: 80
Hearbeat: 539

3. Start all required services and make sure they will auto start if server reboot:

$ service piranha-gui start
$ chkconfig piranha-gui on
$ chkconfig pulse on

4. Run following command to set password for user piranha. This will be used when accessing the web-based configuration tools:

$ piranha-passwd

5. Turn on IP forwarding. Open /etc/sysctl.conf and make sure following line has value 1:

net.ipv4.ip_forward = 1

And run following command to activate it:

$ sysctl -p

Load Balancer #1

1. Open Piranha web-based configuration tools at http://192.168.0.231:3636 and login as piranha with respective password. We start with configuring Global Settings as below:

2. Then, go to the Redundancy tab and enter the secondary server IP. In this case, we will put load balancer #2 IP as the redundant server in case load balancer #1 is down:

3. Under Virtual Servers tab, click Add and enter required information as below:

4. Now we need to configure the virtual IP and virtual HTTP server to map into the real HTTP server. Go toVirtual Servers > Real Server and add into the list as below:

Make sure you activate the real server once the adding completed by clicking the (DE)ACTIVATE button.

5. Now copy the configuration file to load balancer #2 to as below:

$ scp /etc/sysconfig/ha/lvs.cf 192.168.0.232:/etc/sysconfig/ha/

6. Restart Pulse service to apply the new configuration:

$ service pulse restart

You can monitor what is happening with Pulse by tailing the /var/log/message output as below:

$ tail -f /var/log/message

Load Balancer #2

No need to configure anything in this server. We just need to restart Pulse service to get affected with the new configuration changes which being copied over from LB1.

$ service pulse restart

If you see the /var/log/message, pulse in this server will report that it will run on BACKUP mode.

Web Servers

1. Since we are using direct-routing method, regards to your Apache installation, we also need to install another package called arptables_jf. Here is some quote from RedHat documentation page:

Using the arptables_jf method, applications may bind to each individual VIP or port that the real server is servicing. For example, the arptables_jf method allows multiple instances of Apache HTTP Server to be running bound explicitly to different VIPs on the system. There are also significant performance advantages to usingarptables_jf over the IPTables option.

However, using the arptables_jf method, VIPs can not be configured to start on boot using standard Red Hat Enterprise Linux system configuration tools.

We will instsall using yum:

$ yum install arptables_jf -y

2. Configure arptables_jf by executing following command:

In web server #1:

$ arptables -A IN -d 192.168.0.220 -j DROP
$ arptables -A OUT -d 192.168.0.220 -j mangle --mangle-ip-s 192.168.0.221

In web server #2:

$ arptables -A IN -d 192.168.0.220 -j DROP
$ arptables -A OUT -d 192.168.0.220 -j mangle --mangle-ip-s 192.168.0.222

3. Save the arptables rules and make sure the service is started on boot:

$ service arptables_jf save
$ chkconfig arptables_jf on

4. Add the virtual IP address in the servers:

$ ip addr add 192.168.0.220 dev eth0

5. Since the IP cannot be started during sysinit (boot time), we can automatically start the IP after sysinit complete. Open /etc/rc.local using text editor:

$ vim /etc/rc.local

And add following line:

/sbin/ip addr add 192.168.0.220 dev eth0

Warning: Every time you restart your network service, please make sure to run step #4 to bring up the virtual IP in real server.

Done. You can now point your website to the virtual IP and you will see that the load balancer #1 will report as below:

$ ipvsadm -L
 
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port       Forward Weight  ActiveConn  InActConn
TCP 192.168.0.220:http lblc
-> 192.168.0.221:http       Route   1       0           34
-> 192.168.0.222:http       Route   1       0           19

출처 : http://blog.secaserver.com/2012/07/centos-configure-piranha-load-balancer-direct-routing-method/

20130613

nginx proxy

음.. 계속 말하겠지만. 난 돈 쓰는걸 많이 싫어하는 편이다.

투자에 인색하다고 하지 말아라.

특별한 투자 없이 처리할 수 있고 비용을 줄일 수 있으면 줄이는 게 당연한 것이다.

비록 난 대표는 아니지만 내 회사라는 마음이 있고 회사 돈을 아낀다면.. 그게 맞다는 것이다.

하지만 고민할 수 있는 위치가 아니거나 고민하다가 시간을 많이 소비한다면 오히려 그건 회사에게 더 실이 될 수 있으니 조심하자. (인건비가 요즘 장난 아닌지라...)

자. 최근 테라급 데이터를 다루다보니 당연히 눈길이 스토리지 서버에 갈 수 밖에 없는 상황이 생기고 스토리지가 생기더라도 아무리비싸고 좋고 훌륭한 raid를 써서 사용하더라도 결국 사고터지만 백업에 의존하는 상황이 생기기 마련이다.

그러다보니 스토리지를 과감히 포기하고 다른 방법을 택해보았다.

역시 돈이 없기 때문에 L4를 사용할 생각 조차 하지 않았다.

그리고 LVS는 몇 번 구축했지만 내가 원하는 성능을 내지를 못 했다.

내 욕구에 충족하는 수준이 nginx proxy이다.

이 놈 멋지다....

단순 i/o라면 발란스 관리하는 놈만 만들면 아주 아주 퍼팩트한 운영이 가능하다.

방법은 아래와 같다.

192.168.0.x
Proxy 1 --monit-> Proxy 2   -monit-> Proxy 3 -monit -> Proxy 1 (cycle 모니터링)

Web 192.168.101.x 대역
Web 192.168.101.1(10TB) <-- sync --> Web 192.168.101.2(10TB) (cycle 모니터링)

Web 192.168.102.x 대역
Web 192.168.102.1(10TB) <-- sync --> Web 192.168.102.2(10TB) (cycle 모니터링)

Web 192.168.103.x 대역
Web 192.168.103.1(10TB) <-- sync --> Web 192.168.103.2(10TB) (cycle 모니터링)

1) Proxy 들은 각자 1명씩의 Proxy를 감시하여 Proxy 장애를 모니터링 하게 된다.
2) 각 Web의 대역은 서로 service 및 모니터링을 관활하게 된다. (실 운영은 2대보다 많아야지?)
3) 외부에서 접속이 할 경우 proxy 에서 rewrite 를 활용하여 서버에서의 응답을 return 처리
4) Proxy 에서는 Web 대역을 모니터링하여 upstream 을 조정 및 발란스 처리

1-4번까지의 기능의 데몬을 만들면... 오픈 소스를 통하여 대용량 스토리지처럼 운영할 수 있게 된다.

음...

좀 이해가 안되나?..

그냥 고민해보면... 디게 쉽다.

이런식으로 현재 운영을 하고 있는데... 물론 100% 동일하지는 않고 부수적인 것들이 좀 있기는 하지만... proxy 상단에 cdn이 있고 뭐 등등...

암튼 기본적인 이런 형태면 트래픽에 따른 proxy 추가와 용량에 따른 Web 대역을 늘리는 것으로 100 * 10TB정도의 용량은 가능해지게 된다. ㅡㅡ;;

물론 현재 초기 시범 서비스라... 이게 정답인지는 모르겠다...

어떤이는 이렇게 말한다.. 아 복잡해 걍 스토리지 몇대 넣고 L4넣죠... 라고 하는...

누군 그게 좋은지 몰라서 그러냐... 돈이 없다. 돈이 없어.