OSTEP과 함께 가상화에 대해 알아보자 (7)

About this offer

Data Integrity and Protection 디스크 오류 모델 RAID 구현이 어렵지 않았던 것은 디스크의 fail-stop 모델 덕. 현대의 디스크에서는 정상적으로 동작하는 것처럼 보이지만 read 등에 실패하는 경우가 있음. 숨어있는 섹터 에러 (LSE) 디스크 섹터가 손상되었을 때 발생. 디스크 헤드가 표면에 닿아 (헤드 크래시) 표면을 망가뜨려 비트를 읽을 수 없게 만들거나, 강한 방사선;에 의해 비트가 반전되어 내용이 부정확하게 되거나. 에러 정정 코드(ECC)를 이용해 판단, 고칠 수 있음. 블럭 손상 디스크가 손상 여부를 일식할 수 없게 내용이 손상된 경우. 블럭의 내용은 읽어지며 ECC는 내용이 정상이라고 하지만, 추후 해당 블럭을 읽었을 때 잘못된 블럭이 리턴 됨. 전송 버스 상의 오류로 인해 호스트에서 디스크로 전송되는 도중 블럭 손상 가능. 조용한 오류이기 때문에 디스크가 문제를 알지 못함. 이러한 fail-partial 디스크 오류 모델은 전체적으로 보면 불량이지만 일부분만 손상이 있는 경우이기 때문에 디스크가 동작하는 것처럼 보여 위험. 숨어있는 섹터 에러 (LSE) LSE는 쉽게 발견할 수 있기에 해결이 쉬움. 미러링 RAID의 경우, 사본을 보관하며, 패리티 기반 RAID-4/5의 경우 다른 블럭들을 이용해 해당 블럭 재생성이 가능. 이러한 기법을 이용해 복구 가능. 하나의 디스크가 완전히 고장나며, 동시에 다른 디스크에서 LSE가 발생하는 경우. RAID는 패리티 그룹 내의 모든 다른 디스크를 읽어 빠진 값을 다시 계산하여 고장난 디스크에 대한 디스크 재구성을 시도. 재구성하는 도중 LSE를 만나면, 재구성 실패. 위 문제 해결을 위해 추가적인 기법 도입. RAID-DP : 두 개의 패리티 디스크 사용. 추가적인 공간적 비용과 연산 비용 발생. 손상 검출: 체크섬 손상을 발견해내기 위해 체크섬 사용. 체크섬 : 데이터 청크를 입력으로 하여 함수 값을 계산. 이 결과는 데이터에 대한 작은 요약 정보가 됨. 데이터 손상/변경 여부 확인을 위해 계산 값을 확인. 널리 사용되는 체크섬 함수 XOR 기반 체크섬 함수 간단하게 각 데이터 블럭의 청크를 XOR 연산. 각 열에서 두 개의 값이 변하면 XOR 값이 동일하여 손상 검출 불가. 덧셈 기반 빠름. 각 데이터의 청크에 대해 2의 보수 덧셈을 하고, 오버플로우 발생 시 무시. 대부분의 경우에 변경을 검출할 수 있지만, 데이터 시프트의 경우 발견하지 못할 수도 있음. Fletcher Checksum 두 개의 체크 바이트에 mod 255를 하여 계산. CRC와 유사하게 강력. 모든 한 비트, 두 비트, 동시다발적 에러의 경우에 검출 가능. Cyclic Redundancy Check (CRC) 데이터 블럭을 사전에 합의한 값으로 나누고, 나머지 값을 CRC 값으로 함. 이진 나머지 연산은 효율적으로 처리가 가능하기 때문에 네트워크 분야에서도 사용 됨. 어떤 방식에서든 완벽한 체크섬은 없음. 전혀 다른 데이터 블럭이 동일한 체크섬을 가질 수 있음. 이러한 '충돌' 확률을 최소화하며 계산은 간단하게 만드는 것이 효율적인 체크섬 계산. 체크섬의 배치도 디스크는 512 byte일 때, 체크섬을 8 byte, 드라이브의 섹터를 520 byte로 포맷하여 체크섬-데이터-체크섬-데이터 순서로 배치하는 경우. 위와 같은 배치 기능이 없는 디스크의 경우, 파일 시스템이 체크섬을 512 byte 블럭에 저장할 수 있는 방법을 고안해야 함. n개의 체크섬을 모아 한 섹터에 저장하고, 그 뒤에 해당하는 n개의 블럭을 배치하는 방식. 모든 디스크에 적용 가능하지만, 갱신을 위해 체크섬 섹터를 읽고 데이터 블럭과 체크섬을 써야 해서 한 번의 읽기와 두 번의 쓰기가 필요하므로 덜 효율적. 체크섬의 활용 저장된 체크섬과 계산된 체크섬을 비교하여 손상이 있는지 판단. 블럭이 손상되었다면 복사본을 사용하거나 에러 리턴. 새로운 문제: 잘못된 위치에 기록 디스크에 데이터를 올바르게 썼지만, 잘못된 위치에 쓰는 현상. 각 체크섬에 물리적 식별자 정보를 더해 완화. 예를들어 체크섬과 디스크 번호와 섹터 번호를 포함하여 저장해, 해당 블럭에 정확한 정보가 저장되었는지 판단. 마지막 문제: 기록 작업의 손실 상위 계층에는 쓰기가 완료되었다고 알리지만, 실제로는 저장되지 않은 경우. 디스크의 블럭은 새로운 내용으로 갱신되지 않고, 예전의 블럭 내용이 남겨져있는 상황. 저장된 블럭은 정상적인 체크섬과 물리적 ID를 갖고 있을 것이기에 이전의 내용들로는 판단 불가능. 쓰기 검증 또는 쓰기 후 읽기 수행 쓰기 수행 직후에 그 값을 다시 읽어서 데이터가 디스크 표면에 제대로 도착했음을 알 수 있음. But 느린 쓰기 동작에 대해 I/O 수를 두 배로 늘리게 됨. 체크섬을 시스템의 다른 위치에 기록하여 잃어버린 쓰기를 검출 ZFS의 경우. 체크섬을 아이노드와 간접 블럭에 저장. 데이터 블럭에 대한 쓰기는 손실되어도, 아이노드 내의 체크섬은 갱신되었을 것이므로, 이전 데이터와 체크섬이 일치하지 않게 되어 판단 가능. But 아이노드와 데이터 쓰기 둘 다 손실 시 실패. Scrubbing 일반적으로 체크섬은 데이터를 읽을 때 검사. 접근되지 않는 데이터들은 검사가 되지 않은 채 오래 남아있게 됨. 디스크 다시 읽기 기법을 사용. 주기적으로 시스템 모든 블럭들을 읽어 체크섬이 유효한지 검사. 특정 데이터의 모든 사본이 손상되는 것을 방지. 체크섬 오버헤드 공간 오버헤드 (작은 편) 디스크 자체의 오버헤드. 디스크 상에 체크섬을 저장하기 위한 공간이 필요. 시스템 메모리 오버헤드. 데이터 접근 시, 메모리에 데이터와 체크섬을 읽어둘 공간이 필요. 시간 오버헤드 (큰 편) CPU는 데이터를 저장할 때와 접근할 때 체크섬을 연산해야 함. CPU 오버레드를 줄이기 위해 (어차피 데이터 복사는 불가피하기에) 체크섬 연산과 데이터 복사를 하나의 연속적인 작업으로 처리. 체크섬 기법에 따라 추가적인 I/O 유발 가능. Distributed Systems 분산 시스템의 핵심 사안은 실패와 고장 극복, 그리고 시스템 성능, 보안. 통신의 기본 기본적으로 네트워킹은 신뢰 불가능. 패킷 손실, 손상, 유실이 발생하기 때문. 또한, 네트워크 장비나 종단점에서 충분히 버퍼링 하지 못할 수 있음. 신뢰할 수 없는 통신 계층 UDP/IP 네트워크 스택은 기본적으로 신뢰하지 않는 계층. - 소켓 API를 이용해 통신 지점을 생성. - UDP 데이터그램을 전송. - 패킷 유실/손실이 발생하는 경우, 메시지가 목적지에 도착하지 못함. - UDP는 손실에 대해 알 수 없지만, 체크섬 등을 포함해 일부 손상 검출 가능. 신뢰할 수 있는 통신 계층 TCP/IP ack num을 이용하여 메시지 수신 확인이 가능. 발신자가 ack을 못 받으면 timeout을 발생시켜 재전송. ack 메시지가 손실된 경우에는 재전송하여 똑같은 메시지를 두 번 전송할 수 있음. 수신측에서도 메시지를 딱 한 번만 받는다는 보장 필요. 이러한 중복 문제를 위해 seq num 사용. ack가 손실된 경우, 발신자는 타임아웃으로 인해 메시지를 재전송. 이때 수신자의 카운터가 n+1로 커지므로 발신자는 이미 메시지를 받았음을 인지함으로써 중복 수신을 피함. 통신 추상화 분산 공유 메모리 (DSM) 하나의 프로세스가 서로 다른 기기들 위에서 하나의 가상 주소 공간을 공유하여, 분산된 연산이 마치 멀티 스레드 응용 프로그램처럼 보이게 함. 대부분 운영체제의 가상 메모리 시스템 기반으로 동작. 페이지가 접근되었을 때. 최선의 경우. 페이지가 이미 기기 내에 있어 빠르게 데이터 가져옴. 페이지가 다른 기기에 있어, 페이지 폴트 핸들러가 다른 기기에 메시지를 보내 페이지를 달라고 요청. 가장 큰 문제는 실패를 처리하는 방식. 만약 주소 공간의 일부가 사라진다면 분산 연산의 자료 구조를 사용 불가하게 됨. 특정 메모리 접근은 굉장히 느려 성능 문제 존재. 현재는 사용하지 않음. Remote Procedure Call RPC 원격 기계에서의 코드 실행을 로컬 내의 함수를 부르는 것처럼 간단하게 만드는 것이 목적. 클라이언트는 프로시저 호출을 하고, 후에 결과를 리턴 받음. 서버는 공지할 루틴을 정의. 나머지는 스텁 생성기(프로토콜 컴파일러)와 런타임 라이브러리 두 부분으로 나누어 담당. 스텁 생성기 함수의 인자들을 묶는 불편함을 없애고 자동으로 메시지를 만듦. 실수를 막고 최적화가 가능하여 성능 개선. 서버가 클라이언트에게 공지할 프로시저 집합을 컴파일러에 입력으로 전달. 클라이언트 용으로 인터페이스에 명시된 함수들로 구성된 클라이언트 스텁을 생성하여 호출. 클라이언트 스텁의 각 함수들이 원격 프로시저 호출을 위한 일을 처리. 메시지 버퍼 생성. 메시지 버퍼에 필요 정보를 병합. RPC 서버에 메시지 전송. 응답 대기. 리턴 코드와 인자 풀기. 호출자에게 리턴. 메시지 풀기. 실제 함수 호출. 결과 통합 및 응답 전송. 런타임 라이브러리 성능과 신뢰성에 관한 문제들 처리. 원격 서비스의 위치를 찾는 문제. 가장 간단한 방법 : 기존 시스템 활용. 호스트명과 포트 번호를 활용하여 통신 작업 구별. 패킷이 특정 주소로부터 시스템에 있는 임의의 다른 기계로 전달될 수 있는 메커니즘 제공. 어떤 전송 계층 프로토콜 위에 만들지. 요청이 확실히 전달, 응답 확실히 수신을 원하면 TCP 고려 가능. But, 신뢰할 수 있는 통신 계층 상에 RPC를 구현하면 성능이 굉장히 떨어짐. 그래서 UDP 같은 신뢰할 수 없는 통신 계층 사용. 순서 번호 등을 사용하여 각 RPC가 한 번만 발생할 수 있도록 보장. 다른 문제들 원격 호출 완료까지 오랜 시간이 걸린다면? 응답이 즉시 생성되지 않는 경우 먼저 ack를 보내도록 하면 클라이언트는 서버가 요청을 받았는지, 처리 중인지 확인 가능. 한 패킷에 담을 수 있는 양보다 더 많은 수의 인자를 갖는 프로시저 호출들을 처리할 수 있어야. 단편화와 재조합을 이용하여 구현 가능. 그렇지 않은 RPC 런타임은 그런 기능을 자체적으로 구현 필요. 바이트 순서 표시. 빅 엔디안과 리틀 엔디안과 같이 서로 다른 저장 방식을 사용하는 기계들끼리 통신을 하느냐가 중요. RPC에서는 메시지 포맷에 잘 정의되어 있는 엔디안을 사용하는 것으로 문제를 해결. XDR의 엔디안을 준수하여 송수신 가능. 만약 기계가 다른 엔디안을 사용하여 통신한다면, 메시지의 각 정보는 변환되어야 하므로 성능 비용 지불이 필요. 클라이언트에게 비동기적 실행을 허가할 것인가. 어떤 RPC는 동기적으로 동작하여, 결과가 리턴될 때까지 대기하므로 대기 시간이 길어짐. 어떤 경우에는 비동기적으로 호출하여 호출 도중에 다른 작업을 자유롭게 진행 가능. Network File System 분산 파일 시스템 다수의 클라이언트 기계와 하나의 서버가 있으며, 서버는 데이터를 디스크에 저장하고 클라이언트는 약속된 포맷에 따라 메시지를 보내 데이터를 요청. 데이터 공유가 쉬우며, 중앙 집중형 관리라서 보안적 이점이 있음. 기본적인 분산 파일 시스템 서버의 파일에 접근하려면 클라이언트 측 파일 시스템에 시스템 콜을 호출. 분산 파일 시스템의 목표는 파일들에 로컬 파일 시스템과 동일하게 접근할 수 있게 하는 것. 만약 클라이언트가 read() 요청을 내리면 클라이언트 파일 시스템은 서버 측 파일 시스템에 메시지를 전송해서 해당 블럭을 읽도록 함. 파일 서버는 디스크에서 블럭을 읽어 클라이언트가 요청한 데이터와 함께 메시지를 전송. 시스템 콜은 사용자 버퍼에 데이터를 복사하는 것으로 요청 완료. NFS에 대하여 클라이언트-서버 통신 메시지 형식을 정의하고 공개한 오픈 프로토콜. 핵심: 단순하고 빠른 서버 크래시 복구 여러 클라이언트/단일 서버 환경일 때, 서버가 다운되면 모든 클라이언트들은 일을 할 수 없게 되므로 서버의 간단하고 빠른 크래시 복구가 목표. 빠른 크래시 복구의 열쇠: 상태를 유지하지 않음 stateless 프로토콜을 설계. 서버는 각 클라이언트에서 서버에서 발생하고 있는 일에 관해 어떤 정보도 저장하지 않음. 즉, 서버는 클라이언트가 무엇을 하든 전형 상관하지 않고, 대신 각 요청에 필요 정보들을 담아 전송하게 함. NFSv2 프로토콜 파일 핸들 특정 연산을 수행할 파일이나 디렉터리를 고유하게 설명하는데 사용. 볼륨 식별자, 아이노드 번호, 생성 번호로 구성되며, 서버는 이 정보를 조합하여 원하는 파일/디렉터리를 식별. 루트 디렉터리 정보는 NFS 마운트 프로토콜을 통해 얻을 수 있음. 파일 핸들이 준비되었다면 클라이언트는 각 파일을 읽거나 쓰기 위해 프로토콜 메시지 전송 가능. 프로토콜에서 분산 파일 시스템으로 클라이언트가 파일 연산의 상태를 관리하는 방법. 정수형으로 표현되는 파일 디스크립터와 이에 연결된 NFS 파일 핸들에 대한 정보, 현재의 파일 오프셋 등을 저장. 클라이언트는 각 읽기 요청을 포맷된 읽기 프로토콜 메시지로 변환하여 서버가 파일의 정확히 어느 부분의 바이트를 읽어야 할지를 알 수 있도록 함. 읽기가 처리되면 현재 파일 위치를 갱신. 서버가 언제 사용하는지. 파일이 처음 열렸다면 클라이언트 파일 시스템은 LOOKUP 요청 메시지 전송. 서버에 보내는 요청은 요청을 완료하는 데 필요한 모든 정보가 담겨있음. 그래서 서버가 상태 정보가 없이도 요청에 응답 가능. 서버의 고장을 멱등연산으로 처리하기 NFSv2에서 고장들을 요청 재전송으로 처리. 재시도를 통해 문제를 쉽게 해결할 수 있는 이유는 연산의 멱등성 덕분. 연산을 여러 차례 수행해서 얻는 결과가 동일하므로 재시도 가능. LOOKUP이나 READ 요청은 파일 서버에서 정보를 읽기만 하고 갱신하지 않기 때문에 멱등 연산. WRITE 또한 정확한 오프셋을 이용하므로 여러 번 쓰기 연산 해도 동일한 결과를 내는 멱등 연산. mkdir 등은 멱등하게 처리하기 어려움. 성능 개선하기: 클라이언트 측 캐싱 클라이언트가 서버에서 읽은 파일 데이터를 클라이언트 메모리에 캐싱하여 성능을 개선할 수 있음. 캐시 일관성 문제를 생각해야 함. 캐시 일관성 문제 갱신 가시성 문제와 오래된 캐시 문제가 존재. flush-on-close(close-to-open) 파일을 갱신하여 파일을 닫는 시점에 갱신 내용을 서버로 보냄으로써, 다른 노드에서 파일을 열면 닫힌 시점의 최신 내용을 읽을 수 있음. 캐시에 보관된 내용을 사용하기 전에 파일의 변경 여부를 미리 검사. 파일을 열 때 GETATTR 요청을 서버로 전송하여 파일의 속성 정보를 가져옴. 만약 갱신 시점이 파일이 클라이언트에 캐싱된 이후라면 클라이언트는 캐시된 파일을 무효화. 속성 정보 캐시를 클라이언트에 추가. 파일 접근 전에 최신본인지를 검사할 때 캐시되어 있는 속성 정보를 사용. NFS의 캐시 일관성 기법에 대한 평가 flush-on-close 방식의 성능상 문제 클라이언트에서 파일을 일시적으로 생성/삭제해도 내용이 무조건 서버로 전달. 짧은 수명의 파일은 메모리에만 유지하고 서버와 통신하지 않도록 하여 성능 개선 가능. 속성 정보 캐시로 인해 사용자가 어떤 버전의 파일을 읽고 있는지 파악이 더욱 어려움. 서버 측 쓰기 버퍼링의 의미 요청을 받으면 서버는 저장 장치에 완전히 쓴 후 리턴. 이떄 데이터를 서버의 메모리에만 저장하고 클라이언트에 알리면 크래시에 의해 문제가 발생할 수 있음. 따라서 서버는 클라이언트에 성공을 알리기 전에 각 쓰기를 안정적인 저장 장치에 커밋해야 함. Andrew File System 핵심 목적은 확장성. AFS 버전 1 기본 원칙 중 하나 : 로컬 디스크에 파일 전체를 캐싱. 네트워크 통신이 발생하지 않으므로 매우 빠름. 클라이언트의 메모리에 로컬 디스크의 블럭들의 사본을 캐싱. 작업 종료 시, 클라이언트는 파일의 변경 여부를 검사하고, 변경되었다면 새로운 버전을 서버로 Store. 파일 변경 여부 검사 -> 파일의 stat 정보를 얻어옴 -> 파일의 내용을 로컬 디스크로 가져옴 -> 파일을 서버에 저장 -> 파일의 stat 정보 설정 -> 디렉터리의 내용을 보여줌 버전 1의 문제점 경로명을 따라가는 것은 매우 비싼 작업. 원하는 파일을 찾을 때까지 경로명 전체를 따라가야 함. 클라이언트가 TestAuth 프로토콜 메시지를 너무 많이 요청. 서버들은 클라이언트 캐시에 저장되어 있는 파일 사본의 사용 여부를 알려주느라 대부분의 시간을 낭비. 서버들 간의 오버헤드가 적절히 분산되지 않았으며, 문백 교환 등 다른 오버헤드를 유발. AFS 버전 2 클라이언트-서버 간의 상호작용 횟수를 줄이기 위해 콜백 개념 도입. 클라이언트에 캐쉬된 파일들에 상태 정보가 추가. 캐싱된 파일의 변경 사실을 알려주게 됨. 경로명 대신 파일 식별자를 이용하여 파일의 위치를 표현. 파일을 가져오는 과정에서 클라이언트가 서버에 콜백을 설정하여 서버와의 상호작용을 없앰. 캐시 일관성 다른 기계/같은 기계 내의 프로세스들 간의 일관성 고려가 필요. 서버는 캐시된 사본을 갖고 있는 클라이언트들과 콜백을 끊어 더이상 오래된 파일 사본을 캐시에 갖고 있지 않도록 함. last writer wins close()를 마지막으로 부르는 클라이언트가 서버에 마지막으로 파일 전체 갱신. AFSv2의 확장성과 성능 하나의 서버가 약 50개의 클라이언트를 지원할 수 있음. 성능이 거의 로컬 성능에 가깝게 나옴. 큰 파일을 순차적으로 다시 읽기를 시도할 때 NFS는 원격 접속이 로컬 디스크보다 느린 반면 AFS는 빠르며 서버의 오버헤드가 낮음. 순차 쓰기 동작은 양쪽이 비슷한 성능을 보임. AFS는 파일 순차 덮어쓰기에서 성능이 매우 안 좋음. 클라이언트가 파일 전체를 먼저 가져온 후, 덮어쓰기를 수행하기 때문. 큰 파일의 일부 작은 데이터를 접근하는 워크로드에서는 NFS가 AFS보다 훨씬 더 좋은 성능 보임.