Servers : Server clusters-1

서버 클러스터 들은 주로 LAN 환경을 통해 연결된 서버 머신들의 집합으로,

높은 대역폭과 낮은 latency를 가진다. -> 서버들 사이에 통신이 빠르다. (?)

 

서버 머신이 여러개가 있으므로 어떻게 구성하는가의 다양한 방법이 존재한다.

그 중 가장 일반적인 구성은 3가지 티어로 나눠서 관리하는 방법이다.

 

first tier

: logical 한 하드웨어 스위치로 구성이 되어있다 .이 스위치는 client에서 들어온 request를 다른 tier로 보낸다. dispatcher thread와 비슷한 맥락이다.

 

second tier

: client의 요청을 직접 처리하는 서버를 가진다. processing 하는 부분이기 때문에 고성능을 요구한다.

 

third tier

: 데이터를 관리하는 서버로 구성되어있다. file and DB servers

 

모든 server cluster가 위처럼 구성되진 않는다.

 

단순한 클러스터인 경우에는 단일 서비스를 제공할 수도 있지만,

경우에 따라서는 서로 다른 서비스를 제공하는 서버로 이루어져 있을수도 있다.

단순한 클러스터는 스위치의 역할도 단순하다. ( ex. first tier에서 RR방식으로 넘겨준다)

복잡한 클러스터는 스위치가 서비스를 적절한 서버 머신에 보내도록 어떤 서비스를 제공하는지 구분할 수 있어야한다.

 

서버 클러스터에서 중요하게 여기는 설계 부분은 access transparency이다.

분산 투명성 관점에서 보면 client 입장에서 서버단에 여러 서버가 있다는 것을 숨겨야한다.

access는 좀 더 구체적으로, 서버가 클라이언트에게 single access point를 제공해야한다.

client 입장에서 single access point는 first tier이다.

서버 입장에서 확장성과 이용성을 위해 서버클러스터가 multiple access point인 것이 성능면에서 single보다 좋다.

 

서버 클러스터에 클라이언트가 연결할 때

서버-클라이언트 연결이 TCP connection이라고 가정,

first tier에 있는 switch가 client로 부터 들어오는 connection request를 받아

second tiers 중 그 request를 처리할 best 서버를 선택한 뒤 그 second tier에게 넘긴다(hand-off).

second tier의 서버가 client에게 ACK 메세지로 응답한다.

그 메세지 헤더에 ip address를 자신의 ip가 아닌 switch ip address를 보내준다. (access transparency 유지)

이런 TCP handoff는 OS level에서 지원되어야한다.

 

서버 클러스터의 퍼포먼스를 유지하기 위해서 second tier server간의 load를 적절히 분산시켜야한다.

간단한 방법은 RR(Round Robin)이다. 하지만 이 방법은 서버 클러스터가 단일 서비스를 제공하는 경우 가능하다.

여러 서비스를 제공하는 경우엔 스위치가 여러 서비스를 구별하고, 거기에 따라서 서버 선택을 해야한다.

더 나아가서, 스위치는 실제로 client가 보내는 request의 종류 뿐만아니라 내용까지 본다 .! (syntax -> semantic 확장)