활성 복원: 재해 복구가 더 빠르게 이루어질 수 있습니까? 훨씬 더 빨리?

중요한 데이터는 백업해 두는 것이 좋습니다. 하지만 작업을 즉시 계속해야 하고 매 순간이 중요하다면 어떻게 될까요? Acronis에서는 시스템을 최대한 빨리 시작하는 문제를 해결하는 것이 얼마나 가능한지 확인하기로 결정했습니다. 그리고 Active Restore 시리즈의 첫 번째 포스팅으로, 어떻게 이노폴리스대학교와 함께 프로젝트를 시작하게 되었는지, 어떤 솔루션을 찾았는지, 그리고 현재 진행 중인 작업에 대해 말씀드리겠습니다. 자세한 내용은 컷 아래에 있습니다.

안녕하세요! 제 이름은 Daulet Tumbayev입니다. 오늘은 재해 복구 속도를 높이는 시스템을 개발한 경험을 여러분과 공유하고 싶습니다. 프로젝트의 전체 개발 경로에 대해 이야기하려면 멀리서 조금 시작해 보겠습니다. 저는 현재 Acronis에서 일하고 있지만 Innopolis University를 졸업하고 소프트웨어 개발 관리(MSIT-SE라고도 함) 석사 프로그램을 이수했습니다. 이노폴리스는 젊은 대학이고, 커리큘럼도 더 젊습니다. 그러나 그것은 산업 프로젝트와 같은 주제를 포함하는 Carnegie Mellon University의 커리큘럼을 기반으로 구축되었습니다.

산업 프로젝트의 목적은 학생을 실제 개발에 몰입시키고 습득한 지식을 실제로 통합하는 것입니다. 이를 위해 대학은 Yandex, Acronis, MTC 및 기타 수십 개의 회사와 협력합니다(2018년 기준으로 대학에는 총 144개의 파트너가 있습니다). 협력 과정에서 기업은 대학에 업무 영역을 제공하고 학생들은 자신의 관심과 교육 수준에 더 가까운 프로젝트 중 하나를 선택합니다. 문자 그대로 XNUMX년 전만 해도 저는 여전히 "바리케이드 반대편"에 있었고 또 다른 Acronis 프로젝트에서 학생으로 일했습니다. 그런데 이번에 회사 측에서 학생들의 기술 컨설턴트가 되어 이노폴리스에 Active Restore 프로젝트를 제안하게 되었습니다. Active Restore에 대한 아이디어는 Acronis의 커널 팀에서 공식화되었지만 솔루션 개발은 Innopolis University와 함께 시작되었습니다.

활성 복원 – 왜 필요한가요?

전통적으로 재해 복구는 표준 체계에 따라 작동합니다. 컴퓨터에 문제가 발생한 후 Acronis True Image와 같은 일부 백업 시스템의 웹 인터페이스로 이동하여 큰 "복원" 버튼을 클릭합니다. 다음으로 N분을 기다려야 하며 그 후에만 작업을 계속할 수 있습니다.

문제는 허용되는 복구 시간인 RTO(복구 시간 목표)라고도 알려진 이 숫자 N이 상당히 인상적일 수 있다는 것입니다. 이는 연결 속도(복구가 클라우드에서 이루어지는 경우), 머신의 하드 드라이브 크기에 따라 달라집니다. 및 기타 여러 요인이 있습니다. 줄이는 것이 가능한가요? 예, 가능합니다. 작업을 재개하기 위해 항상 전체 컴퓨터 디스크가 필요한 것은 아니기 때문입니다. 동일한 사진과 비디오는 어떤 방식으로든 장치의 기능에 영향을 미치지 않으며 나중에 백그라운드에서 불러올 수 있습니다.

드라이버가 필요합니다...

운영 체제는 디스크가 완전히 준비된 상태로 시작될 것으로 예상합니다. 따라서 Windows는 일련의 검사를 수행하여 디스크의 무결성을 확인합니다. OS에서 찾을 것으로 예상하는 일부 파일이 누락되거나 손상된 경우 시스템은 정상적인 시작을 허용하지 않습니다. 이 문제를 해결하기 위해 누락되거나 손상된 파일을 대체하지만 실제로는 더미인 소위 리디렉터 파일을 디스크에 배치하기로 결정했습니다. 실제로 콘텐츠가 없기 때문에 이러한 리디렉터를 만드는 데 시간이 오래 걸리지 않습니다.

추가 복원은 다음과 같이 발생합니다. 운영 체제의 작동과 병행하여 백그라운드 프로세스에 의해 "인형"이 데이터로 채워집니다. 백그라운드 복구 프로세스는 디스크 부하를 고려하며 지정된 제한을 초과하지 않습니다. 그러나 사용자나 운영 체제 자체가 갑자기 아직 존재하지 않는 파일을 요구할 수도 있습니다. 여기서 두 번째 복구 모드가 시작됩니다. 요청된 파일의 우선순위를 최대로 높이고, 복구 프로세스를 통해 파일을 디스크에 긴급하게 로드합니다. 운영 체제는 약간의 지연이 있기는 하지만 필요한 파일을 수신합니다.

이것이 이상적인 그림의 모습입니다. 그러나 현실 세계에는 엄청난 수의 함정과 잠재적인 교착 상태가 있습니다. Innopolis 석사 학생들과 함께 우리는 이 복구 시나리오를 탐색하고 RTO의 이점을 평가하고 그러한 접근 방식이 실현 가능한지 이해하기로 결정했습니다. 결국 당시 시장에는 그러한 솔루션이 없었습니다.

그리고 Innopolis 직원에게 서비스 구성 요소를 제공하기로 결정했다면 Acronis 내에서 작업이 시작되었습니다. 파일 시스템 드라이버에 의한 미니 필터. 이 작업은 Windows 커널 팀에서 수행했습니다. 계획은 이랬습니다.

• OS 시작 초기 단계에서 드라이버를 시작하고,
• 근무 중, 언제 사용자 공간 완전히 준비되었습니다. 서비스를 다운로드하세요.
• 이 서비스는 운전자 요청을 처리하고 추가 작업을 조정합니다.

드라이버 엔지니어링의 미묘함

내 동료가 다른 게시물에서 서비스에 대해 이야기한다면 이 텍스트에서 우리는 드라이버 개발의 복잡성을 공개할 것입니다. 이미 개발된 미니 필터 드라이버에는 두 가지 작동 모드가 있습니다. 즉, 시스템이 일반 모드에서 시작된 경우와 시스템에 오류가 발생하여 복원되는 경우입니다. 사용자 라이브러리와 애플리케이션, 그리고 서비스를 로드하기 전에 드라이버는 동일하게 작동합니다. 그는 시스템이 현재 어떤 상태에 있는지 모릅니다. 결과적으로 모든 생성, 읽기 및 쓰기가 기록되고 모든 메타데이터가 기록됩니다. 그리고 서비스가 온라인 상태일 때 운전자는 이 정보를 서비스에 제공합니다.

정상적인 시작의 경우 서비스는 운전자에게 "Relax" 신호를 보내 "긴장을 풀고" 모든 데이터 로깅을 꼼꼼하게 중지합니다. 이 경우 드라이버는 디스크의 변경 사항만 기록하도록 전환하고 이를 서비스에 보고합니다. 서비스는 다른 Acronis 도구를 사용하여 사용자가 지정한 미디어에서 디스크 백업을 가장 최신 상태로 유지합니다. 이는 클라우드, 원격, 점진적 또는 야간 백업이 될 수 있습니다.

복구 모드가 활성화된 경우 서비스는 드라이버에게 "복구" 모드에서 작동해야 한다고 알려줍니다. 시스템은 방금 충돌로부터 복구되었으며, 디스크에 있는 파일을 열어 달라는 요청을 하는 즉시 미니 필터는 이 작업을 가로채서 자체적으로 요청하고 해당 파일이 디스크에 있는지 여부를 확인해야 합니다. 열 수 있습니다.

파일이 누락된 경우 미니 필터는 이 정보를 서비스에 전송하여 파일 복구 우선순위를 높입니다(이때 복구는 백그라운드에서 진행됩니다). 이 파일은 단순히 대기열의 시작 부분으로 이동하는 것으로 나타났습니다. 그런 다음 서비스 자체(또는 다른 Acronis 수단)가 이 파일을 복원하고 드라이버에 모든 것이 정상임을 알려줍니다. 이제 운영 체제는 해당 파일에 액세스할 수 있고 드라이버는 시스템에서 디스크로 원래 요청을 "해제"합니다.

복구가 불가능한 경우 서비스는 해당 파일이 백업에 없음을 드라이버에 알립니다. 우리의 미니 필터 드라이버는 단순히 시스템 요청을 추가로 전달하고 원래 요청자(OS 자체 또는 애플리케이션)는 "파일을 찾을 수 없음" 오류를 수신합니다. 그러나 파일이 실제로 디스크나 백업에 없다면 이는 매우 정상적인 현상입니다.

물론 파일이나 라이브러리 읽기가 원격 리소스에 대한 액세스를 통해 여러 단계로 이루어지기 때문에 운영 체제는 훨씬 느리게 작동합니다. 그러나 복구가 진행되는 동안 사용자는 가능한 한 빨리 작업에 복귀할 수 있습니다.

더 낮고, 더 낮아야 합니다...

프로토타입은 그 기능성을 입증했습니다. 그러나 어떤 경우에는 여전히 교착 상태가 있기 때문에 계속 진행해야 한다는 필요성도 느꼈습니다. 예를 들어 운영 체제는 여러 스레드에서 다양한 라이브러리를 요청할 수 있으며 이로 인해 서비스가 자체적으로 루프백됩니다.

현재 작업 중인 문제는 Active Restore의 속도를 높이고 시스템 보안 수준을 높이는 것입니다. 시스템에 전체 파일이 필요하지 않고 일부만 필요하다고 가정해 보겠습니다. 이를 위해 디스크 필터 드라이버라는 또 다른 드라이버가 개발되었습니다. 더 이상 파일 수준에서는 작동하지 않지만 블록 수준에서는 작동합니다. 작동 원리는 비슷합니다. 일반 작동 모드에서는 드라이버가 단순히 변경된 블록을 디스크에 기록하고, 복구 모드에서는 자체적으로 블록 읽기를 시도하며, 실패할 경우 서비스에 우선 순위를 높이도록 요청합니다. 그러나 시스템의 다른 모든 부분은 동일하게 유지됩니다. 예를 들어, OS 수준 서비스는 다른 드라이버와 통신하라는 요청을 받고 있다는 사실조차 의심하지 않습니다. 왜냐하면 주요 작업은 작동에 필요한 정확한 데이터를 OS에 제공하는 것이기 때문입니다. 이 영역은 서비스가 아직 블록 수준에서 생각하는 방법을 모르기 때문에 상당한 개선이 필요합니다.

다음 단계에서는 서비스 대신 UEFI 드라이버 및 기본 Windows 응용 프로그램 수준으로 내려가 드라이버를 더 깊게, 더 일찍 시작하기로 결정했습니다. 이를 위해 개발된 UEFI 부팅 드라이버 (또는 DXE 드라이버), OS가 시작되기도 전에 시작되고 종료됩니다. 그러나 다음 게시물에서는 UEFI 드라이버의 "역사", 조립 및 설치에 대한 세부 정보, Windows 기본 응용 프로그램의 세부 사항을 살펴보겠습니다. 그러니 저희 블로그를 구독해 주세요. 그동안 다음 작업 단계에 대한 이야기를 준비하겠습니다. 나는 귀하의 의견과 조언을 기쁘게 생각합니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

복구에 극도로 오랜 시간이 걸리는 상황을 겪어본 적이 있습니까?

• 65.1%예28

• 23.2%10

• 11.6%생각도 못했는데 5

43명의 사용자가 투표했습니다. 3명의 사용자가 기권했습니다.

출처 : habr.com