'load balancing'에 해당되는 글 2건

  1. 2013.01.18 Elasticsearch search load balancer 구성.
  2. 2012.02.28 Tomcat lb 를 이용해서 Weighted 구현하기.

Elasticsearch search load balancer 구성.

Elastic/Elasticsearch 2013.01.18 12:30

그냥 쉽게 가려고 고민하지 않고 L4 신청했는데 오판 이였습니다.
elasticsearch 에서 L4 에서 보내는 syn signal 에 rst 을 던지고 있습니다.
그렇다 보니 binding 이 정상적으로 되지 않고 VIP 로 접속 시 접속이 되지 않는 문제가 있는데요.
요건 검색해 보시면 명쾌한 답이 나옵니다.
ES 를 직접 개발한 사람이 그러더군요.

"There is no need load balancer in elasticsearch."

이유 인 즉,
Java API 를 사용하면 Perfect!! 라고 합니다.

저도 살짝 놓친 부분인데요. (알고 있어도 고민하지 않으면.. 이렇다니까요 ㅡ.ㅡ;;)

client = new TransportClient(settings).addTransportAddress(new InetSocketTransportAddress(host, port));

여기서 search 용 node 를 추가해 주면 됩니다.
어떻게???
이렇게요.. 

client = new TransportClient(settings)
.addTransportAddress(new InetSocketTransportAddress(host1, port))
.addTransportAddress(new InetSocketTransportAddress(host2, port));

혹시라도 L4 랑 붙혀서 사용하려고 고민하시는 분들을 위해서 그냥 올려 봅니다. ;;

신고
Trackback 0 : Comment 0

Tomcat lb 를 이용해서 Weighted 구현하기.

ITWeb/서버관리 2012.02.28 17:36
[Tomcat Load Balancer 로 Weighted 구현]

ps=/

#worker.list=tomcat1, tomcat2, loadBalancer

worker.list=loadBalancer


worker.tomcat1.port=8009

worker.tomcat1.host=10.67.8.113

worker.tomcat1.type=ajp13

worker.tomcat1.lbfactor=2   # tomcat1 이 2번


worker.tomcat2.port=8109

worker.tomcat2.host=10.67.8.113

worker.tomcat2.type=ajp13

worker.tomcat2.lbfactor=1   # tomcat2 가 1번 씩 번갈아 가면서 호출 됩니다.


worker.loadBalancer.type=lb

worker.loadBalancer.method=T

worker.loadBalancer.balance_workers=tomcat1,tomcat2

worker.loadBalancer.sticky_session=0



※ 이전에 작성한 글들 참고하세요.
http://jjeong.tistory.com/581 : httpd mod_proxy 를 이용한 load balancing
http://jjeong.tistory.com/580 : Tomcat Session Clustering

[참고정보]
http://tomcat.apache.org/connectors-doc/generic_howto/workers.html 
http://tomcat.apache.org/connectors-doc/reference/workers.html 

DirectiveDefaultDescription
balance_workers - A comma separated list of workers that the load balancer need to manage.

This directive can be used multiple times for the same load balancer.

This directive replaces old balanced_workers directive and can be used only with mod_jk versions 1.2.7 and up.

As long as these workers should only be used via the load balancer worker, there is no need to also put them into the worker.list property.

sticky_session True Specifies whether requests with SESSION ID's should be routed back to the same Tomcat worker. If sticky_session is set to True or 1sessions are sticky, otherwise sticky_session is set to False. Set sticky_session to False when Tomcat is using a Session Manager which can persist session data across multiple instances of Tomcat.
sticky_session_force False Specifies whether requests with SESSION ID's for workers that are in error state should be rejected. If sticky_session_force is set to True or1 and the worker that matches that SESSION ID is in error state, client will receive 500 (Server Error). If set to False or 0 failover on another worker will be issued with loosing client session. This directive is used only when you set sticky_session=True.

This feature has been added in jk 1.2.9.

method Request Specifies what method load balancer is using for electing the best worker. Please note, that session stickiness and perfect load balancing are conflicting targets, especially when the number of sessions is small, or the usage of sessions is extremely varying For huge numbers of sessions this usually is not a problem.

Some methods note, that they aggregate in a sliding time window. They add up accesses, and on each run of the global maintain method, the load counters get divided by 2. Usually this happens once a minute, depending on the setting of worker.maintain. The value of the load counters can be inspected using the status worker.

If method is set to R[equest] the balancer will use number of requests to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This is the default value and should be working well for most applications.

If method is set to S[ession] the balancer will use number of sessions to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. Because the balancer does not keep any state, it actually does not know the number of sessions. Instead it counts each request without a session cookie or URL encoding as a new session. This method will neither know, when a session is being invalidated, nor will it correct its load numbers according to session timeouts or worker failover. This method should be used, if sessions are your limiting resource, e.g. when you only have limited memory and your sessions need a lot of memory.

If set to T[raffic] the balancer will use the network traffic between JK and Tomcat to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This method should be used, if network to and from the backends is your limiting resource.

If set to B[usyness] the balancer will pick the worker with the lowest current load, based on how many requests the worker is currently serving. This number is divided by the workers lbfactor, and the lowest value (least busy) worker is picked. This method is especially interesting, if your request take a long time to process, like for a download application.

This feature has been added in jk 1.2.9. The Session method has been added in jk 1.2.20.

lock Optimistic Specifies what lock method the load balancer will use for synchronising shared memory runtime data. If lock is set to O[ptimistic] balancer will not use shared memory lock to find the best worker. If set toP[essimistic] balancer will use shared memory lock. The balancer will work more accurately in case of Pessimistic locking, but can slow down the average response time.

This feature has been added in jk 1.2.13.

retries 2

This directive also exists for normal workers. For those it has adifferent meaning.

If the load balancer can not get a valid member worker or in case of failover, it will try again a number of times given by retries. Before each retry, it will make a pause define by retry_interval directive.

Until version 1.2.16 the default value was 3.

 
신고
Trackback 0 : Comment 0