블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

 

Elastic Load Balancer

 조대협

ELB는 아마존에서 제공하는 일종의 L4와 같은 로드 밸런서이다. 내부적으로 VM위에서 동작하는 소프트웨어 로드밸런서이고, 아마존 환경에 맞춰서 최적화 되어 있다.

 



Multiple zone support

ELB는 기본적으로 multiple zone을 지원한다. ELB 생성시, ELB를 배포할 Amazon Availability Zone을 지정할 수 있다. 여러 개의 zone multiple ELB instance가 배포 되기 때문에 ELB 인스턴스는 기본적으로 ip 주소를 가지지 않는다. 대신 DNS 주소를 가지는데, 테스트를 해보면 알겠지만, ELB DNS 주소는 경우에 따라서 1개 이상의 주소를 리턴하게 된다.

이는 multiple zone을 지원하기 위해서 뿐만 아니라, ELB의 용량이 모자르게 되면 내부적으로 자동으로 scaling을 하는데, 먼저 ELB scale up을 해서 인스턴스 크기를 키우고, 모자르다면 다른 ELB 인스턴스를 만들어서 추가 하는 scaling out 작업을 수행한다.

여러개의 ELB를 하나의 end point로 묶기 위해서 DNS 리스트 방식을 사용하게 된다.

SSL Termination

ELB SSL 기반의 HTTPS 프로토콜을 지원할 수 있다.ELB 설정에 SSL 인증서를 세팅해놓으면 Client --> ELB SSL, ELB --> 백엔드 EC2까지는 HTTP로 통신을 하게 된다.

X-forwarded for Header

ELB EC2 인스턴스 앞에서 로드밸런싱을 하게 되면 EC2 입장에서 incoming address ELB의 주소로 인식하게 된다. 애플리케이션에 따라서 client ip를 알아야 할 경우가 있는데, EC2 입장에서는 ELB request를 하는 주체가 되기 때문인데, 이러한 문제를 해결하기 위해서 ELB는 원래의 client ip X-forwarded-for (XFF) 헤더 안에 실어서 보내준다. EC2에서는 이 XFF HTTP Header를 열어 봄으로써 원본 client ip를 알아낼 수 있다.

Sticky Session

ELB가 추가적으로 제공하는 기능중에 하나가 sticky session이라는 기능이다. 이 기능은 client로 부터 들어오는 http request를 항상 같은 ec2 인스턴스로 라우팅을 해주는 기능인데, ELB sticky session의 원리는 cookie를 사용한다.

Sticky session 기능을 on 해놓으면, http response cookie를 세팅하여, 해당 client가 가는 ec2 instance에 대한 정보를 저장해 놓는 방식이다.

몇 가지 추가 설정이 필요한데, 애플리케이션이 이미 http cookie를 사용하고 있으면, 해당 cookie 명을 넣어서 사용중인 애플리케이션 cookie를 사용하게 하고, 만약에 애플리케이션이 cookie를 사용하지 않으면, 별도로 ELB cookie를 만들도록 한다.



위의 그림과 같이 sticky session 기능은 cookie를 사용하기 때문에, multiple ELB 상황에서도 항상 같은 request를 같은 ec2 인스턴스로 라우팅할 수 있게 해준다.

Health Check

ELB ELB에 연결된 EC2 인스턴스에 대한 자체적인 Health Check 기능을 가지고 있다. 사용자 설정에서 정해진 옵션에 따라서 주기적으로 EC2 인스턴스에 Health Check 메세지를 보내고, 만약에 EC2 인스턴스가 장애로 판단되면, 해당 인스턴스를 로드밸런싱 리스트에서 제외한다.

반대로, 제외되었던 인스턴스라도, 주기적으로 체크해서 정상화가 되면 다시 로드 밸런싱 대상에 추가하게 된다.

DNS Fail Over

다음으로 ELB 간의 HA이다. Load Balancing은 앞에서 언급한 바와 같이 DNS Round Robin 을 사용한다. 마찬가지로 HA 역시 DNS 방식을 사용하는데, Amazon DNS ELB 인스턴스들의 상태를 감시하다가 문제가 생기면, DNS 리스트에서 제외를 한다.

DNS 방식이기 때문에, TTL 시간을 가지고 있고, TTL 시간이 지나야 리스트가 클라이언트에 업데이트 되기 때문에, TTL 시간이 지나기 전까지는 client가 계속 장애가 난 인스턴스로 로드가 밸런스 될 수 있다. 그래서 Load Balancer 기반의 Fail Over 보다는 넘어가는 시간이 느리다.

VPC & ELB

앞서 VPC에 대한 개념에 대해서 설명하였는데, ELB 역시 VPC 안쪽이나 바깥쪽 양쪽에 배포가 가능하다. VPC 바깥쪽에 배포를 하여 public ip를 가지고 VPC 안쪽의 EC 인스턴스에 대해서 로드밸런싱이 가능하며, 또한 VPC 안쪽에 배포를 하여 private ip를 가지고 EC 인스턴스에 대해서 로드 밸런싱이 가능하다.

주의해야할점

마지막으로 ELB 사용 및 테스트시 주의할점을 몇가지 언급해보면 다음과 같다.

ELB로 성능 테스트를 하다 보면, 부하가 일정 수준으로 못 올라가는 경우에 ELB에서 Network In/Out bound 쪽에서 병목이 있는 것을 발견할 수 있는데, 이는 ELB의 용량이 충분하지 않기 때문이다. ELB는 자체적으로 scaling을 하기는 하지만, scaling이 그리 빠르지 않다. 그래서 성능 테스트를 할 경우에는 wramp up 기간을 둬서 충분히 부하를 줘서 인위적으로 ELB scaling하게 해 놓은 후에, 부하 테스트를 해야 ELB 단의 병목을 피할 수 있다.

또는 wramp up 이 되었는지 여부가 확실 하지 않으면 DNS look up으로 몇 개의 ELB 인스턴스가 생성되었는지 확인해보거나, 제일은 Amazon쪽에 부하 테스트 기간을 알려주면 미리 Amazon 쪽에서 ELB scaling 해 준다.

그리고 부하테스트를 하다 보면, 특정 EC2 Instance나 특정 Availability Zone으로 몰리는 현상이 있을 수 가 있다. 특정 Zone으로 부하가 몰리는 현상은 흔히 발생하는 데, ELB 자체가 부하를 골고루 분산해 주지 않는다. 다만 특정 Zone이나 Instance로 몰리는 현상이 아주 심할 경우에는 몇 가지 요인을 생각해볼 수 있는데, 먼저 부하 테스트 쪽의 DNS 캐쉬를 의심해볼 수 있다.

ELB간의 로드밸런싱은 DNS Round Robin을 사용하기 때문에, 클라이언트 쪽의 캐쉬를 지워주지 않으면 그 시간동안 계속해서 특정 ELB 인스턴스에만 부하를 주게 된다.

특정 인스턴스로 몰리는 현상의 경우 Sticky Session을 사용하는 경우, 클라이언트 쪽의 Cookie를 지워 주지 않아서, Cookie를 참조해서 계속 같은 EC2 인스턴스로 부하가 가는 경우가 많다.

 

그래서 ELB 기반의 부하테스트를 할 때에는 고성능 적은 수의 클라이언트 보다는 많은 수의 저성능 클라이언트를 사용하는 것이 부하를 골고루 나눠 지게 할 수 있다.

 

좋은 스위치는 iSCSI SAN의 핵심 부분이다. 그렇다, 어떤 기가비트 스위치도 iSCSI와 잘 어울리지만, 값싼 비관리형 제품에는
몇 가지 아주 중요한 기능들이 없다.
우선, 스위치는 넌블로킹(Non-blocking)이어야만 한다. 즉, 모든 포트에서 회선 속도의 입출력을 동시에 처리할 수 있어야 한다. 모든 스위치가 이렇게 할 수 있는 것이 아니며, 심지어 일부 엔터프라이즈급 스위치도 인접 포트(Adjacent Port) 그룹끼
리는 대역폭을 공유한다 (특히, 시스코 카탈리스트4500 시리즈의 구형 모델처럼 섀시 기반의 스위치,물론 그렇지 않은 모델도 많다).
둘째, 흐름 제어를 지원할 수 있어야 한다. 흐름제어란 수신 호스트가 송신 호스트에게 송신하는 데이터 양을 줄이라고 요청할 수 있게 해주는 2계층 이더넷 프로토콜이다. 이는 서버 혹은 SAN이 상대방이 수신할 수 있는 것보다 더 많은 데이터를
보내는 상황을 방지해준다. 이 기능이 없으면 엄청난 양의 비효율적인 TCP 재전송을 초래해서 전반적으로 열악한 성능을 야기한다.
셋째, 점보 프레이밍(Jumbo Framing)을 지원해야 한다. 보통 이더넷 프레임은 1,500바이트로 제한된다. 점보 프레이밍은 이 제한을 9,000바이트 로 확장시킨다. 회선을 통과해야 하는 프레임 개수 를 줄여줘서 약간 더 높은 회선 효율성과 더 적은
지연편차를 야기한다. 대부분의 최신 스위치는 이 기능을 지원하지만, 모두 그럴 수 있는 건 아니다.끝으로, VLAN을 지원하는 스위치를 확보하라.iSCSI 트래픽이 자체 VLAN에서만 흐르도록 분리하는 것이 좋다. 성능 상의 이유도 있지만, 가장 큰 이유는 승인 받지 않은 호스트가 SAN에 접속하지 못하게 하는 빠르고 쉬운 방법이기 때문이다.

=====

원문 http://www.itworld.co.kr/techlibrary/75424/%ED%86%B5%ED%95%A9+%EB%8D%B0%EC%9D%B4%ED%84%B0%EC%84%BC%ED%84%B0%EB%A5%BC+%EC%9C%84%ED%95%9C+%EC%B5%9C%EC%A0%81%EC%9D%98+%EC%8A%A4%ED%86%A0%EB%A6%AC%EC%A7%80+%22iSCSI+SAN%22+-+IDG+TechFocus 에서 발췌

L2,L3,L4 스위치

클라우드 컴퓨팅 & NoSQL/IaaS 클라우드 | 2011.05.11 23:44 | Posted by 조대협
한동안 블로그 포스팅이 뜸했습니다.
바뻤습니다.
한동안 클라우드 연구하다가 Storage에서 머리가 아퍼오더니.. Storage 산을 넘으니 이번에는 Network이 저를 괴롭힙니다.

L2 - Dummy Hub 개념으로 보면 된다. Mac Address를 보고 라우팅
L3 - Hub + Router = Subnet 이 다른 네트웍도 라우팅 기능을 이용해서 묶어 줄 수 있다. IP를 보고 라우팅
L4 - IP Layer에서 Load Balancing도 가능

Inter Rack 간 통신을 performance degration없이 묶는 법을 아시는분?

* Load Balancing의 성능 측정 단위
L4 - CPS (Connection Per Second)

언제한번 정리해야지 해야지 하면서...
못써놨던 글....

X.25는 아직도 그 폐쇄성으로 인해서 대외거래에서 많이 사용되는 프로토콜이다.
다시 말하면 X.25는 기관과 기관을 1:1로 연결하는 폐쇄망이다.
요즘이야 TCP 전용망으로 많이 구성을 하기는 하지만 아직도 X.25는 많이 사용되는 대외계 프로토콜중에 하나다.

그런데 이 X.25라는 놈이 문제가 별도의 X.25 카드를 필요로 한다.
API도 X.25 프로토콜에 맞춰서 프로그래밍해야 하는데

개발자를 구하기도 어려울뿐더러 X.25 카드에 대한 지원도 쉽지 않다.
또한 예를 들어 클러스터 환경으로 5개의 BOX로 업무 시스템을 구성할 경우
부하분산이나 클러스터링에 문제가 생긴다.
X.25 카드를 5대에 모두 꼽을 수 없을뿐더러
X.25 회선이 5개가 있지 않는 이상 5개의 BOX에 X.25 부하를 동일하게 분산할 수 없게된다.

이런 문제를 해결해주는 것이 X.25 스위치인데 국내 금융권에서도 몇군데 사용하고 있다.

사용자 삽입 이미지


이 장비의 역할은 X.25연결을 TCP/IP로 변환해주는 역할을 해준다.
그래서 AP 프로그래머는 TCP 소켓으로 프로그래밍을 하면 되고 X.25의 TCP Port당 X.25 회선의 LU를 할당할 수 있다.
(X.25회선은 PU라는 물리회선에 LU라는 논리회선으로 구성된다. 즉 하나의 PU가 들어오더라도 물리적인 회선은 N개를 사용할 수 있다. A사와 B사를 연결할때 1의 PU만 있다 하더라도 업무에 따라서 어느 LU를 사용할지를 정할 수 있는 것이다.)
이게 무엇보다 마음에 드는데, X.25카드가 없는 머신에 LU를 나눠서 배포 함으로써 서버들을 수평적으로 구성하여 어느 서버에서나 X.25 접근이 가능하게 되서 아키텍쳐 구성이 수월해진다. (위에서 설명했듯이, X.25 카드로 구성하면 쉽지는 않은일이다..)

이 장비는 cisco와 캐나다 athena라는 회사에서 제공하는 장비가 있다...

'아키텍쳐' 카테고리의 다른 글

아키텍쳐 설계 프로세스  (1) 2012.09.04
Open source http proxy tool  (0) 2009.12.24
무료 ETL 솔루션  (3) 2009.06.09
재미있는 X.25 관련 장비 (Athena X.25 switch)  (0) 2008.06.17
Velocity & Sitemesh  (1) 2008.03.31
WLS 10.3 진화는 어디까지?  (0) 2007.11.08
TAG Athena, LU, PU, switch, X.25