Backward Recovery
1.4.1 Backward Recovery
Recovery 기술은 시스템을 옳거나 에러 없는 상태로 되돌리기 위한 시도를 한다.
Backward recovery는 미리 저장된 상태로 그 시스템을 재저장하거나 rolling back 함으로써 이를 시도한다.
1/ 보통 그 fault가 스스로 명백해지기 전에 그 미리 저장된 상태가 발생한다고 가정한다는 것으로 그 우선상태는 에러가 없다.
2/ "미리 저장된 상태가 fault가 그스스로 명백해지기전에 발생한다는 것은 이전의 상태에 에러가 없었다는 것" 이라고 가정한다.
미리 저장된 상태가 발생한다??
만약 error-free가 아니라면, 같은 에러는 recovery 시도에서 문제를 발생시킬 것이다.
시스템상태는 미리 결정된 recovery point에서 저장된다.
기록되거나 저장된 이 이전 상태는 checkpointing 이라고 부른다.
그 상태는 failure에도 영향을 받지 않는 안정된 저장소에서 체크포인트가 되어야 한다.(should be checkpointed)
덧붙여, checkpointing , 증가하는 checkpointing, 감사추적, 로그들이 사용될 것이다.
Error detection에 의하면 그 시스템 상태는 마지막 저장된 상태로 재저장되고, 기능은 그 상태에서부터 계속 되거나 재시작된다.
만약 checkpoint가 만들어진 다음에 failure가 발생한다면,
그 checkpoint 된상태는 error-free 일 것이고,
rollback 후에 그 시스템 상태 또한 error-free가 될 것이다.
Fig1.3에서 backward recovery를 설명한다.
Backward recovery에는 몇가지 장점이 있다.
. BR은 /에러가 recovery 메커니즘에 영향 받지 않는 다는 전제하에/ residual design faults (잔여디자인폴트?)에 의해 야기된 예상 못한 에러들을 다룰 수 있다.
. BR은 그 상태에 의해 받은 손상에 관계없이 사용 가능하다.
. BR은 일반적인 recovery scheme을 제공한다.
– 에러 탐지와 복구에 일정한(/동일한) 패턴을 갖고 있다.
- 어플과 독립적이다.
- 프로그램에서 프로그램으로 변하지 않는다.
recovery scheme에 대한 설명입니까...?
. BR은 시스템 상태에서의 에러에 대한 지식을 필요로 하지 않는다.
. BR에서 오직 필요로하는 지식은 relevant(적절한? 상대적인?) prior state는 에러가 없다는 것이다.
. BR은 투명(명확한)하거나 영구적인 임의의 faults를 다룰 수 있다.
. BR은 특히 일시적인 faults의 recovery에 알맞다.
Recovery 후에는 그 에러는 없어질 것이고, checkpointed 시스템 상태에서의 재시작은 같은 fault를 발생시키지 않을 것이다.
단점도 있다.
. BR은 checkpointing과 recovery를 수행하기위한 중요한 리소스들이 필요하다.
( 리소스 ; 시간, 계산, 안정적 저장소 )
. BR의 완성(/실행)을 위해서는 종종 그 시스템을 일시적으로 중단해야한다.
. BR을 이용한 상호작용과정의 소통과 조화가 일치(synchronized)되지 않는 다면, 도미노 영향이 발생할 것이다. 이것은 한 프로세스가 그것의 이전의 체크포인트로 롤백할 때 발생하는데, 이것은 또다른 프로세스가 더 멀리(해당프로세스의 체크포인트로) 롤하도록(?) 차례로 발생한다. 계속계속….
Backward recovery 접근은 sw fault tolerance에 있어서 가장 일반적인 적절한 회복 기술이다. 이것은 오버헤드가 있음에도 자주 사용된다.
RcB기술과 (sw fault tolerance로 통합된?) 분산시스템 은 backward recovery를 쓴다.(employ)