Code migration - 2

프로세스를 migration하는 것은 어렵다.

resource도 타입에 따라서 옮길 수 있을지, 어려울지 정해진다.

 

예를 들어 프로세스가 TCP port를 사용하고 있다고 해보자.

port나 소켓은 로컬에서만 의미가 있는 정보라서 옮길 수 없다.

다른 예로 사용하던 파일은 URL만 있으면 옮기지 않고 접근 가능하다.

 

두가지 관점에서 리소스의 종류를 살펴보자

 

1) process-to-resource

프로세스가 리소스를 어떻게 사용할 수 있을까를 binding으로 표현한 것이다.

identifier, value, type 순으로 강하게 바인딩되어있다.

 

- identifier

: 가장 강한 바인딩으로, unique한 값이여서 resource를 옮겨야한다.

- value

: 옮긴 머신에 값이 있을 수도 있어서 굳이 옮기지 않아도 되는 경우도 있다.

- type

: id도 달라도 되고, value도 달라도 되고, type만 같으면 된다

 

2) resource-to-machine

migration 후에 리소스의 참조 값이 바껴야한다면

해당 리소스를 타겟머신으로 이동할 수 있는지 여부에 따라 다르다.

fixed, Fastened, Unattached순으로 강하게 바인딩되어있다.

 

- Unattached resources

: 쉽게 이동가능하다 ex) 데이터 파일

- Fastened resources

: 이동은 가능하지만 양이 많아서 오래걸리고 높은 cost를 요구한다 -> 실현하기 어렵다 -> 우회적방법 사용

- Fixed resources

: 특정 기계나 머신에 밀접하게 연결되있는 리소스로, 해당 머신을 벗어나면 의미가 없어진다. ex) local devices, 소켓

 

heterogeneous 한 시스템에서 migration을 한다면?

 

heterogeneous한 시스템이란 원래 머신과 타겟 머신의 플랫폼이 다른경우이다.

이 상황에서 migration을 하려면 프로세스 하나만 옮기는 것이 아니라 실행 환경 전체, OS까지 이동해야한다.

 

내가 작업하던 실행 환경을 멈추지 않고 실행 환경 전체를 migration을 하려면 두가지의 문제를 해결해야한다.

1. 가상머신이 사용하는 전체 메모리 이미지를 옮긴다. - 쉽지않다.

2. 가상머신에 연결된 로컬 리소스가 있었다면 -> 위에 나와있음

 

전체 메모리 이미지를 옮기는 3가지 방법이 있다.

 

1) 일단 멈추지않고 원래 머신에서 작업을 계속하고 다 copy한다.
copy가 끝나면 수정된 작업을 다시 받아온다 -> 시간은 좀 걸릴수있다.
2) 원래 작업을 중지하고, 옯긴다. 그 후 다시 시작한다.
-> 멈추려고 했는데 머신 live service를 제공하는 경우 멈추게하는데도 시간이 걸릴수있다.
3) 타겟 머신에서 필요할 때마다 원래머신에서 pull해간다.
-> 시작할 때가 가장빠르다. 한동안 원래머신과 타겟머신을 운영해야해서 오래걸릴 수도있다.