분산시스템에서의 프로세스

Process는 분산시스템에서 중요환 관점이 될 수 있다.
클라이언트/서버 구조를 효율적으로 구현하기 위해서는 3가지 관점에서 보아야한다.

1. thread
2. 가상화
3. Client-Server 구성

 

 

Thread Usage in Non-distributed Systems

▲ 비분산시스템에서의 쓰레드사용 (Thread Usage in Non-distributed Systems)
-A에서 작업하던 단일코어가 B로 할당: A에서 작업을 하다가 B로 넘어가기전 기존 A Context를 스택에 저장. 나중에 사용할 때 Restore

기존 프로세스는 서로 다른 Process간 전환 시(또는 정보교환시) Context Switching Overhead가 발생한다.
Process 전환에 따른 PCB의 Load/Store 필요
* PCB(Process Control Block): 프로세스 상태를 보관하는 제어블록

 

스레드 구현 (Thread Implementation)

 

Thread: Process 경량버전
하나의 프로세스는 여러개의 스레드를 갖게 된다.

구현방법
- 실행 권한에 따른 분류: User Level, Kernel Level, Hybrid(User + Kernel) (유저레벨에서도 커널레벨에서도 각각 스레드를 갖을 수 있다. 혼합의 경우 유저 커널 둘다 스레드를 갖는 경우)
- Thread: 경량 Process, Code는 다르지만 자원은 공유

- 자원 사용을 최소화하기 위해 Thread 사용
- 하나의 Process 내에서 여러 Thread 동작
- 한 Process내 Thread 들은 같은 자원을 공유

 

Multithreaded Servers (요청이 많은 Busy Server에 좋음)

- 디스패처 스레드에서 클라이언트 요청을 받는다.
- 디스패처 스레드에서 다른 스레드에도 일을 분배한다.

 

 

 

○ Thread를 이용한 클라이언트/서버 구성
○ Client 요청을 Multithread로 처리하면 WAN 과 같은 RTT가 긴 환경에서 이점을 가짐
⇒ 자원 관리시간 또는 대기시간이 긴 경우
○ Server에서는 매 서비스 요청마다 Dispatcher가 개별 Worker Thread에게 작업을 배분
○ Multithreaded Server Model

- Multi Thread: 병렬처리 가능, Blocking 일부 발생
- 단일 Thread: 병렬처리 없음, Blocking 발생 (다른시스템콜을하게 되면 블락되고 다른시스템의 일을 하게된다.)
- FSM(Finite State Machine): 병렬처리 가능, Blocking 없음.

 

Virtualization(가상화)

○ 기존: SW 개발 시 Platform에 종속됨 (다른 플랫폼으로 개발이되면 동작이 안되는 경우가 발생-따라서 가상화 필요)
○ 개발환경과 다른 Platform이라도 기존 SW가 동작하도록 함
- Platform과 SW계층 사이에 Interface(Virtual Machine)를 두어 다른 Platform이라도 기존 SW 동작
○ Platform에 독립적인 시스템 구현 가능
implementation of mimicking A on B (B에서의 흉내내기 구현)

 

 

 

Architectures of Virtual Machines 

 

Figure 3-6: 컴퓨터 시스템이 제공하는 다양한 인터페이스
Interface: General Instruction, Privileged, Instruction, System Call, Library, Function(API)
Figure 3-7 (a): 프로세스 가상 머신으로, (응용 프로그램, 런타임) 조합의 여러 인스턴스가 있습니다. - API레벨에서 가상화 OS는 하나이며 APPLICATION환경에 맞게 런타임을 이용화하여 가상화 한다.
Figure 3-7 (b): 여러 인스턴스가있는 가상 컴퓨터 모니터 (응용 프로그램, +-운영 체제) 조합 중. - 다양한 OS와 그에 맞는 APPLICATION 가상화 가능

 

 

클라이언트-서버 구성

(a) 특정어플리케이션에 한정적
(b) Appl에 종속되지 않는다.

 

UI처리
- Issue: 서버에서? 클라이언트에서?

Networked User Interfaces

어떻게 구현할 것인가?
- 특정한 Protocol을 통해 통신 및 구현
* Application Level Protocol: 특정 Application에 한정적임
* Application 독립적 Protocol: Middleware Level
Ex. XWindow 시스템 ▼

 

 

 

Client-Side Software for Distribution Transparency

당시 서버의 상태에 따라서 3개의 서버중에 하나와 연결 - 그러나 유저는 서버가 3개라는 사실을 모르게 한다 
1장에나오는 Transparent replication

 

 

Client-Server Binding 방법 (Demon / Super-Server)

○ Daemon 방식

 

- 모든 서비스 서버가 동작
- Background에서 Daemon이 구동
- Daemon은 Endpoint(주소개념) Table을 가지고 있음. (demon은 주소록 개념)
- 클라이언트에서 서비스 요청 시 Daemon이 해당 서비스에 맞는 Endpoint를 연결

○ Super-Server

- 서비스 요청에 대응하는 Super-Server 존재
- Super-Server는 요청에 따라 실제 서버를 Binding (ex: 메일을 쓰고싶을 경우 그 때만 메일서버를 바인딩한다.)
- 요청에 따라 필요한 Server만 동작하기때문에 자원소모가 절약 (기존 Demon방식은 서버가 모두 동작하여 살아있어야함. 자원소모가 큼)

 

Server Clusters

○ 동일 서비스를 제공하는 여러 개의 서버를 사용

○ 개별 서버보다 Computing 능력이 Powerful함

○ 클라이언트의 요청을 각 서버로 배분할 수있는 Switch 필요

▲ 3 Tier Model
- 1st: Dispatcher, 요청을 서버로 분배
- 2nd: Server Cluster, 서비스 서버
- 3rd: DB Cluster, 데이터 서버

 

 

▲ TCP Handoff 기술

- 서비스 요청 시 Switch가 부하가 적은 서버로 Binding
- TCP Network 사용
- 응답은 단일 Connection(클라이언트로 직접 전송)
- 구성이 복잡함

Distributed Servers
○ 서버 Clustering 시 Switch가 Fail(고장/실패)일 때 전체 시스템이 Down 되는 것을 서버를 분산시켜 보완
ex) 분산서버- 스위치 개념이 없음: 서버1이 죽으면 서버2로 간다.
○ 각 서버의 실제 IP 주소는 다르지만 공통 Home Address(HA)를 갖는 서버 Cluster를 구성
○ Application Level에서는 서비스를 HA로 요청하지만, MIPv6 Level에서 실제 서비스 서버 IP로 Binding
- MIP(MobileIP)는 HA와 CoA(Core of Address, 실제주소) 정보를 가짐

 

▲ Home Address : 대표주소 / CA1, CA2: 실제주소이며 둘은 주소가 다름
ex) MIP (Mobile IP): HA(Home Address: 대표주소 / COA(care of Address) 이동 IP 실제IP

 

Managing Server Clusters

 

○ 가상화를 이용 Server Cluster를 관리
○ 원래 O/S에 VMMonitor를 추가하여 필요한 환경 제공

 

Code Migration

○ 오래된 방법이나, 실제로 많이 활용하는 편은 아님
○ 서버에 따라 클라이언트 SW Code를 변경
○ 변경할 SW Code를 보관하는 DB Repository 구성
○ 서버에서 따라 구성이 달라질 경우 응용

 

▲ 서버와 통신하도록 클라이언트를 동적으로 구성하는 원리. 클라이언트는 먼저 필요한 소프트웨어를 가져온 다음 서버를 호출합니다.

 

 

WHY? ex) 서버의 서비스에 따라 클라이언트 구성이 달라질 필요가 있을 때, 해당 코드를 가져와서 이용한다.

- Weak: 단편 Code만 이동
* Sender, Receiver 모두 이미 Process 실행 및 존재

- Strong; 전체 Code 변경, Process 재생성
* Sender, Receiver 모두 새로운 Process 실행
* Migration/Clone 수행

 

Migration & Level Resources(Binding)
- 아직 활성화 되지 않음, 활용도 떨어짐