협동분산시스템 (9) 썸네일형 리스트형 Hard Link vs Symbolic Link Hard Link 하나의 파일 시스템 내에서 원본 파일과 동일한 내용의 다른 파일, 즉 이름이 다른 같은 파일을 만드는 것이다. 두 파일은 같은 i-node를 가지기 때문에 내용이 항상 동일하게 유지된다. ex) 수정하면 다른 파일에도 적용된다. 원본 파일이 삭제되어도 문제가 없다. Symbolic Link 서로 다른 파일 시스템의 파일끼리도 링킹이 가능한 방법이다. 링크 파일이 원본 파일의 경로 정보를 가진다. “바로가기” 와 같다. 별도의 i-node를 가지는 파일을 생성하고, 원본 파일을 가르키는 포인터를 가진다. 원본 파일이 삭제되면 무의미한 파일이된다. Middleware Protocol 미들웨어 프로토콜이란? 논리적으로는 application 아래 단에 존재한다. application이 middleware 서비스를 이용하면 분산 시스템을 편하게 이용할 수 있다. middleware가 제공할 수 있는 서비스는 크게 두가지이다. 1) 다양한 middleware 서비스를 구축할 수 있는 protocol 2) high level communication protocol 1) middleware 서비스는 주로 맞춤형 서비스가 아닌 많은 application을 대상으로 하는 범용 서비스이다. 서비스를 예로 들어보겠다. - 인증 : 로그인 서비스 - 권한 : 인증이 된, 로그인이 된 사용자를 대상으로 서로 다른 권한을 부여한다. - 커밋 : operation이 하나일 수도, 여러개일 수 도 있는데 .. Communication application에서 사용할 수 있는 high level 통신이 어떤게 있는지 살펴볼것이다. 분산 시스템에서는 두 프로세스 사이에 메세지 통신을 하는 interprocess communication이 있어야한다. 컴퓨터 네트워크단에서 우리가 생각하는 메세지를 주고 받으려면 소켓 프로그래밍을 해야한다. 하지만 큰 스케일의 분산 applicaiton에서 그런 소켓들만을 사용해 통신하는 것은 어렵다. 그래서 low level에서 소켓을 사용하고, 그 위의 레벨인 high level에서 사용하기 편한 통신 서비스를 이용하게 해주면 분산 시스템을 구축하기 용이해지고, 서비스를 사용하기 편리해진다. 널리 사용되는 communication model로는 -RPC (Remote Procedure call) -MOM.. Code migration - 2 프로세스를 migration하는 것은 어렵다. resource도 타입에 따라서 옮길 수 있을지, 어려울지 정해진다. 예를 들어 프로세스가 TCP port를 사용하고 있다고 해보자. port나 소켓은 로컬에서만 의미가 있는 정보라서 옮길 수 없다. 다른 예로 사용하던 파일은 URL만 있으면 옮기지 않고 접근 가능하다. 두가지 관점에서 리소스의 종류를 살펴보자 1) process-to-resource 프로세스가 리소스를 어떻게 사용할 수 있을까를 binding으로 표현한 것이다. identifier, value, type 순으로 강하게 바인딩되어있다. - identifier : 가장 강한 바인딩으로, unique한 값이여서 resource를 옮겨야한다. - value : 옮긴 머신에 값이 있을 수도 있어서 .. Code migration - 1 서버 모드가 많아질수록, 즉 서버 클러스터의 크기가 커질수록 고장날 확률이 높아져서 지속적인 관리가 필요하다. 하나의 서버 머신이 고장날 확률을 p, 서버 노드의 개수를 N, 고장날 확률이 독립사건이라고 가정하면 서버가 고장없이 잘 돌아갈 확률은 (1-p)^N이다. 이 때, self-manage가 가능한 서버 클러스터 노드가 개발될 수 있으면 관리가 수월해질 것이다. Code migration : 실행 중인 프로세스를 다른 머신으로 옮기기 프로세스 부하가 많은 프로세스에서 놀고 있는 머신쪽으로 부하를 옮기면 성능이 향상되므로 code migration 작업이 필요하다. 분산 시스템에서 용량을 최적화하는 일보다 더 중요한 일은 전체 통신 횟수를 줄이는 일(Communication latency)이다. ex.. Servers : Server clusters-3 서버 클러스터의 마지막 topic은 관리이다. 서버 클러스터를 관리할 때 approach가 크게 두가지로 나뉜다. 1) 서버 관리자가 직접 서버 클러스터 노드에 remote로 연결해서 관리하는 법이다. : 다 해야해서 관리하기에 귀찮다. 2) 관리자 전용 머신(terminal)을 두어 모든 작업을 터미널에서 한다. collective한 명령을 내린다 : 관리하기에 유용해서 많이 사용되는 방법이다. Servers : Server clusters-2 만약 single access point가 fail하면, 전체 클러스터 서비스가 unavailable해진다. (SPF 문제) 그래서 단일이 아닌 여러 access point를 제공하면서, client에게는 static/stable한 하나의 access point만 노출시켜야 한다. 첫번째 방법은 주소를 공개적으로 제공하는 것이다. ex) DNS : 같은 host name에 여러 ip address를 둔다. 하지만 이러한 접근은 client에게 여러 access point가 있다는 점을 노출시키는 것이다. 다음 방법은 flexible한 서버 클러스터를 구성하는 법이다. 하나의 AP가 고장나면 다른 AP를 사용하는 방법이다. 서버 클러스터를 flexible하게 구성이 되게해 확장하면 이를 분산 서버라고 할 .. Servers : Server clusters-1 서버 클러스터 들은 주로 LAN 환경을 통해 연결된 서버 머신들의 집합으로, 높은 대역폭과 낮은 latency를 가진다. -> 서버들 사이에 통신이 빠르다. (?) 서버 머신이 여러개가 있으므로 어떻게 구성하는가의 다양한 방법이 존재한다. 그 중 가장 일반적인 구성은 3가지 티어로 나눠서 관리하는 방법이다. first tier : logical 한 하드웨어 스위치로 구성이 되어있다 .이 스위치는 client에서 들어온 request를 다른 tier로 보낸다. dispatcher thread와 비슷한 맥락이다. second tier : client의 요청을 직접 처리하는 서버를 가진다. processing 하는 부분이기 때문에 고성능을 요구한다. third tier : 데이터를 관리하는 서버로 구성되어있다.. 이전 1 2 다음
