분산 시스템 구조(Distributed System Structures) -네트워크 운영체제(Network Operating Systems)

16. 분산 시스템 구조(Distributed System Structures) 16.1 네트워크 운영체제(Network Operating Systems) ▶ 다수의 시스템들에 대해 알고 있는 사용자에게 원격 자원을 접근할 수 있게 하는 환경을 제공 → 원격 로그인, 원격 파일 전송 16.1.1 원격 로그인(Remote Login) ▶ 인터넷의 telnet 기능 제공 ex) 원격 시스템 kcs.kongju.ac.kr에서의 연산 - 먼저, 원격 시스템에 계정을 가지고 있어야 함 - telnet kcs.kongju.ac.kr - 원격 시스템의 프로세스(데몬)가 사용자에게 로그인 이름과 패스워드를 요청 - 원격 로그인이 성공되면, 원격 시스템에서의 연산 가능 16.1.2 원격 파일 전송(Remote File Transfer) ▶ 인터넷의 파일 전송 프로토콜(file transfer protocol: FTP)프로그램 기능 제공 ex) kcs.kongju.ac.kr의 사용자가 cs.utexas.edu에 있는 파일 paper.txt를 my-paper.txt로 복사 - 먼저, 원격 시스템에 계정을 가지고 있어야 하고, 파일의 위치를 알고 있어야 함 - FTP 프로그램 호출: ftp cs.utexas.edu - 원격 시스템의 프로세스(데몬)가 사용자에게 로그인 이름과 패스워드를 요청 - 원격 로그인이 성공되면, 파일 paper.txt이 있는 부디렉토리로 연결: cd 부디렉토리 - 파일 복사: get paper.tex my-paper.tex (파일 공유 아님) ▶ 익명의 FTP(anonymous ftp) - 원격 시스템에 계정을 가지지 않아도 되지만, 원하는 파일 paper.txt는 공용 보호 설정으로 지정된 특정 부디렉토리 ftp에 위치해야 함 - FTP 프로그램 호출: ftp cs.utexas.edu - 원격 시스템의 프로세스(데몬)가 사용자에게 로그인 이름과 패스워드를 요청하면, 이름 “anonymous”와 임의의 패스워드(ex: email 주소)를 입력함 - 파일 복사: get paper.tex my-paper.tex (파일 공유 아님) ▶ FTP는 telnet과 유사하게 구현됨 - 원격 시스템에는 FTP 포트에 연결을 원하는 요청을 감시하는 데몬(demon)이 존재함 - 로그인 인증이 성취되면, 사용자는 원격적으로 명령을 실행할 수 있음 1) telnet 데몬: 모든 명령의 실행을 허용 2) FTP 데몬: 일반 운영체제 명령과는 다른 파일에 관련된 특별한 명령어 집합의 실행을 허용 → get, put, ls/dir, cd, 기타 전송모드나 연결 상태를 결정하는 명령 등 (p.543 참조) 16.2 분산 운영체제(Distributed Operating System) ▶ 분산 운영체제에서는 사용자들이 지역 자원에서와 동일한 방법으로 원격 자원에 접근 가능 16.2.1 자료 이주(Data Migration) ▶ 사이트 A에 있는 사용자가 사이트 B에 있는 파일 등의 자료에 접근하려 할 때, 시스템이 자료를 이동하는 두 가지 기본적인 방법 → 이때, 파일에 대한 모든 접근은 ‘로컬 방식’임 ① 파일 전체를 이동하는 방식 ex) Andrew 파일 시스템(17장) → 비효율적 file(자료) A B 접근요청 전체이동 반환 ② 실제 필요한 파일 일부를 이동하는 방식: 요구 페이징과 유사 ex) SUN Microsystem의 네트워크 파일 시스템(NFS) 프로토콜(17장) → 효율적 file(자료) A B 접근요청 일부이동 반환 ▶ 자료 이주 시, 다른 문자 코드를 사용한다면 번역이 필요할 수도 있음 16.2.2 연산 이주(Computation Migration) ▶ 대용량 파일의 접근이나 분석의 경우, 자료가 아닌 연산을 이동하는 것이 효율적임 → 파일이 위치하는 사이트에 접근하여 연산 후 결과를 반환 받는 것이 바람직 ① 원격 프로시저 호출(remote procedure call; RPC) - 프로세스 P가 원격 사이트 A에 프로시저를 통지하고, - 이 프로시저는 실행 후 결과를 반환 화일 결과 반환 프로세스 P 사이트 A 원격 프로시저 호출 ② 메시지 전송 - 프로세스 P가 원격 사이트 A에 작업에 대한 메시지를 보내면, - 원격 사이트에서는 해당 업무를 위한 프로세스 Q를 생성하고, 결과를 메시지 시스템으로 반환 화일 결과 반환 프로세스 P 사이트 A 메시지 전송 16.2.3 프로세스 이주(Process Migration) ▶ 프로세스의 전체 혹은 일부를 다른 사이트에서 수행 가능 → 연산 이주의 논리적 확장 ▶ 사용 이유 ① 부하 균등화(load balancing): 부하를 균등하게 하기 위해 프로세스를 분산함 ② 연산 속도 향상(computation speedup): 프로세스가 동시에 다른 사이트에서 수행될 수 있는 부분 프로세스들로 분리될 수 있다면, 전체 반환 시간(turnaround time)이 축소됨 ③ 하드웨어 선호성(hardware preference): 특정 프로세스는 특정 프로세서에 의해 수행되는 것이 적합할 수 있음 ④ 소프트웨어 선호성(software preference): 특정 프로세스는 특정 사이트의 소프트웨어에 의해 수행하는 것이 적합할 수 있음 ⑤ 데이터 접근(data access): 데이터의 양이 많은 경우 데이터의 이주보다 프로세스의 이주가 바람직함 ▶ 프로세스 이주를 위한 두 가지 상호보완적인 기법 ① 시스템은 프로세스가 이동되었다는 사실을 사용자로부터 숨김 즉, 사용자가 이주 명령을 명시할 필요 없음 → 주로 부하 균형, 연산 속도 향상 목적 ② 사용자가 프로세스의 이주를 명시하는 경우 → 특정 하드웨어나 소프트웨어의 선호성 목적 16.3 원격 서비스(Remote Services) ▶ 원격 서비스 방식: 접근 요청이 원격 서버에 전해지면, 서버는 접근을 수행하고 그 결과를 사용자에게 반환 16.3.1 원격 프로시저 호출(Remote Procedure Calls; RPC) ▶ 원격 프로시저 호출 - 메시지 기반 통신 기법 사용 - 원격 시스템으로 전송되는 메시지들은 해당 포트(port)에 반응하는 RPC 데몬으로의 주소가 지정되어 있으며, 함수의 식별자와 매개변수를 보유함 - 포트 번호는 메시지 패킷의 첫 부분에 부착됨 - 해당 함수가 수행되고 결과가 요청자에게 반환됨 ▶ RPC 동작에 관한 문제 1) 호출의 의미(semantics): 통상적인 네트워크 에러로 인해 RPC는 실패(fail)나 중복(duplicated)될 수 있음 → 메시지에 타임 스탬프를 부착하여 전송하고, 서버가 수령한 메시지의 모든 타임 스탬프 이력을 보관하고 중복되는 메시지를 무시함으로써 해결 가능 2) 서버와 클라이언트간의 통신에 관한 문제: 클라이언트가 서버의 포트 번호를 파악하는 방법 ① 바인딩 정보가 고정 포트 주소 형태로 사전에 결정되게 하는 방법 → 컴파일시에 RPC 호출은 관련된 고정 포트 번호로 고정됨 ② 바인딩이 랑데부 기법에 의해 동적으로 실행되게 하는 방법 - 운영체제는 특정 RPC 포트에 랑데부 데몬(부합기(matchmaker))을 둠 - 클라이언트는 부합기에 RPC의 이름을 메시지로 보내 해당 RPC의 포트 주소를 요청함 - 포트 번호가 반환되고, RPC 호출이 해당 포트로 전송됨 → 추가적인 부하가 요구되지만, 보다 융통성이 있음 [그림 16.1] 원격 프로시저 호출의 실행 16.3.2 스레드(Threads) ▶ 스레드: 태스크 내부에서 다른 연산들이 비동기적으로 계속 작동되고 있는 동안에 메시지를 보내거나 받기 위해 사용됨 * 팝업 스레드(pop-up-thread): 새로운 RPC에 응답하기 위해 “필요할 때” 만들어지는 스레드 ▶ 동일 기계에서 실행되는 다른 프로세스들에 있는 스레드 간에 공유 기억장치를 통해 매우 효율적인 통신이 가능하다면 RPC는 보다 경량화될 수 있음 * 서버 스레드(Server Threads; ST) ↔ 클라이언트 스레드(Client Thread; CT) ▶ OSF의 DCE(Distributed Computing Environment) → UNIX 및 Microsoft Windows/NT에서 사용 * 호출: p.550의 내용 16.4 견고성(Robustness) ▶ 분산 체제에서 발생 가능한 결함: 링크의 결함, 사이트의 결함, 메시지 분실 등 → 견고한 시스템을 위해, - 결함을 탐지하고, - 시스템을 재구성하여 연산을 계속하고, - 사이트나 링크가 회복되면 복구되어야 함 16.4.1 결함 탐지(Failure Detection) ▶ 일반적으로 링크 결함, 사이트 결함, 메시지 분실을 탐지할 수는 있지만 이를 구별하기는 거의 불가능함 ▶ 핸드 쉐이킹 프로시저(hand shaking procedure): 링크와 사이트의 결함 탐지용 ① 사이트 A와 B가 직접적인 물리적 링크로 연결되어 있다면, 고정된 시간 간격마다 양 사이트는 서로 I-am-up이라는 메시지를 보냄 ② 만일 A가 정해진 시간동안에 이 메시지를 받지 못하면, - 사이트 B가 결함이거나, - A와 B 사이의 링크가 결함이거나, - B로부터의 메시지 분실이라고 가정함 ③ 또 다시 일정 시간동안 B로부터의 I-am-up 메시지를 기다리거나, 혹은 B에게 Are-you-up? 메시지를 보내고 응답을 기다림 → 이 과정을 몇 차례 반복한 후에도 응답이 없으면, 링크나 사이트의 결함으로 단정함 ④ 사이트 A는 Are-you-up? 메시지를 가능한 다른 경로를 통해(존재할 경우) B에게 보내어 링크 결함과 사이트 결함을 구별할 수 있음 → “시간 제한(time-out) 기법” 사용 - 제한 시간내에 응답이 있는 경우, 링크 결함을 단정함 - 제한 시간내에 응답이 없는 경우, 다음 중 어떤 것이 실제로 발생했는지 판단할 수 없음 1) 사이트 B가 다운되었거나, 2) A에서 B로의 (유일한) 직접 경로가 다운되었거나, 3) A에서 B로의 대체 경로도 다운되었거나, 4) 메시지가 분실되었음 16.4.2 재구성(Reconfiguration) ▶ 결함을 탐지한 사이트 A는 시스템을 재구성하고 정상적인 작동을 위한 프로시저를 시작함 ① A에서 B로의 링크 결함인 경우: 체제 내의 다른 모든 사이트에 알려, → 라우팅 테이블을 수정하게 함 ② 사이트의 결함인 경우: 체제 내의 다른 모든 프로세스에 알려, - 고장난 사이트를 이용하지 않게 하고, - 특히, 중앙 조정자의 결함인 경우 새로운 조정자 선출이 요구되고, - 결함이 논리적인 링 부분인 경우 논리적인 링을 재구성함 - 만일, 고장이 아닌 도달될 수 없는 상태라면 네트워크 분할을 의미함 → 이 경우 두 사이트가 조정자 역할을 수행함으로써 두 사이트가 동시에 임계구역에 들어가게 되는 현상 등이 발생할 수 있음 16.4.3 결함 복구(Recovery from Failure) ▶ 결함인 링크나 사이트가 수리되면, 무리 없이 시스템에 통합되어야 함 ① A와 B 사이의 링크 결함이 수리되면, 이 사실을 양 사이트가 인지해야 함 → 계속된 핸드 쉐이킹 프로시저에 의해 해결될 수 있음 ② 사이트 B의 결함이 복구되었을 때, 이 사실을 다른 모든 사이트에 알리고 다른 사이트들로부터 정보를 얻어 지역 테이블을 갱신함 ex) 라우팅 테이블, 다운된 사이트들의 목록, 도달되지 않은 메시지나 메일 등의 정보 16.5 설계시 고려 사항 ▶ 분산 시스템의 설계를 위한 주요 특성 - 투명성(transparency): 사용자들에게 중앙 집중식 시스템으로 보이게 함 → 사용자 이동성(user mobility): 어떤 시스템에서도 로그인 할 수 있음 - 결함 허용(fault tolerance): 어느 정도의 결함으로 기능 저하가 수반되더라도 계속 수행 가능 → 결함 허용 시스템 - 확장성(scalability): 증가하는 서비스 부하에 적응하는 능력 ▶ 대규모 분산 시스템 설계의 문제점 ① 부하 요구가 시스템 크기에 비례하는 서비스 기법은 확장성을 제한함 ② 중앙 집중식 제어 기법과 집중식 자원은 결함 허용 시스템의 구축에 사용될 수 없음 ③ 서버의 프로세스 구조: 경량 프로세스 혹은 스레드가 바람직