살아있는 리눅스 서비스 핫 클론

리부팅이나 다른 것 때문에가 아니라 Linux 서비스가 활성 상태 일 때 핫 복제해야합니다. 그것은 우리의 특별한 시나리오 때문입니다 (예, 이미이 답변을 읽었지만 작동중인 Linux 서버 인 Clone 과 약간 다릅니다 ).

우리는 계산 노드를 가지고 있습니다. NLP 계산 노드를 말할 수 있습니다. 서비스를 제공하면서 노드를 시작하면 여러 번 피드를 제공 할 때까지 계산 속도가 느려집니다. 우리는 그것을 워밍업이라고 불렀습니다.

불행하게도 워밍업 작업은 대기하는 데 시간이 오래 걸립니다 (노드가 워밍업되기 전에 계산이 완료되었을 수 있음).

문제는 Linux 서버를 핫 클로닝하여 노드를 최상의 성능으로 유지하여 더 짧은 시간 안에 온라인으로 복제하고 온라인으로 만들 수있는 안정적인 방법이 있습니까?

전체 서버를 "핫 클론"할 수는 없지만 (가상 머신 인 경우에만 가능), criu , Checkpoint / Restore in Userspace를 사용 하여 단일 프로세스를 동결하고 복원 할 수 있습니다 .

이를 통해 프로그램의 내부 상태를 디스크에 저장하고 프로그램을 중지 한 다음 나중에 저장된 파일에서 해당 상태로 프로그램을 복원 할 수 있습니다.

원하는 작업을 지원하기 위해 저장된 프로그램을 나타내는 파일을 다른 서버에 복사하여 복원 할 수 있습니다.

criu에는 다양한 기능이 컴파일 된 최신 커널이 필요하므로 이전 Linux 배포판이 작동하지 않을 수 있습니다. criu check특정 시스템에서 실행 하여 criu의 전제 조건이 있는지 판별 할 수 있습니다 .

현재 환경의 범위를 벗어난 것일 수도 있지만이를 수행하는 업계 표준 방법은 서버를 가상화하는 것입니다. 많은 가상화 호스트 (VMware, virtualbox 등)는“스냅 샷”을 허용하여 서버의 상태를 저장 한 다음 새 인스턴스로 복제 할 수 있습니다. 이러한 새 인스턴스는 원래 프로세스와 동일한 프로세스 상태를 유지합니다. 물론 실행중인 소프트웨어가 가상 환경에서 계속 올바르게 작동하는지 확인해야합니다 (CUDA / GPU 계산이 필요합니다).

언급 한 질문은 http://www.linuxfocus.org/English/March2005/article370.shtml 링크를 참조 하며 요청을 수행하는 것으로 상상했던 모든 방법을 설명합니다.

옵션이 있다는 것은 서버에서 실행되는 것에 많은 의미가 없습니다. 복제 프로세스에서 변경 될 수있는 모든 파일이 대상 시스템의 파일과 일치하지 않을 수 있음을 고려해야합니다. 이 게시물에서 데이터베이스에 대해 이야기하고 데이터 무결성을 보장하지 않는 것처럼 복제합니다.

"여러 번 먹일 때까지"라는 말의 의미가 명확하지 않습니다 .

그러나 요청한 내용을 잘 이해했다면 시스템을 복제하려면 리소스를 복사하고 계산하는 데 시간이 필요하다는 점을 고려해야합니다.

"ON / OF"또는 더 나은 활성 / 백업 환경을 수행하려면 서버가 서버에서 올바르게 구성되어 있어야합니다.

당신이 기대하는 대답이 아니라면 미안하지만 당신이 얻는 옵션은 그 것입니다.

수행하려는 작업에 많은 잠재적 인 문제가 있으며 물론 데이터가 동적으로 저장되지 않는 동안 서버를 오프라인으로 전환하여 복제하는 것이 가장 좋습니다.

그러나 이전에했던 것처럼 당신이하려는 것은 전적으로 그럴듯합니다. 사용하는 경우 dd전체 서버를 블록 수준에서 다른 드라이브 나 다른 서버로 복제 할 수 있습니다. 그러나 새 서버에서 일부 추가 설정이 필요하며 다른 서버와 새 서버를 단순히 켤 수는 없습니다. 이를 이해하려면 서버 하드웨어 및 소프트웨어에 대한 몇 가지 사항을 알아야합니다.

첫째, 최상의 데이터 전략을 결정하려면 정기적으로 업데이트되는 내용을 아는 것이 도움이 될 것입니다. 동적으로 업데이트되지만 정적 컨텐츠가있는 SQL 서버가 있습니까? 또는 git이 콘텐츠에 지속적인 데이터 업데이트를 보내는 것과 같은 하위 버전 시스템을 사용하는 개발자 팀이 있습니까? 업데이트 내용에 따라 최선의 전체 행동 과정이 결정됩니다.

예를 들어, 정기적으로 업데이트되는 것이 SQL 인 경우 해당 서버가 다음과 같은 방식으로 작동하는 동안 새 서버로 마이그레이션 할 수 있습니다.

• dd 새 서버의 모든 데이터를 복제합니다.
• 새 서버 설정을 시작하십시오. 특히 다른 하드웨어 인 경우 약간의 작업이 필요할 수 있지만 처음부터 설정하는 것보다 여전히 빠를 수 있습니다.
• 첫 번째 서버가 활성 상태 인 동안 두 번째 서버를 라이브로 작업해야하는 경우 다른 서버에서 동일한 DNS를 사용할 수 없으므로 DNS 변경이 필요할 수도 있습니다.
• 새 서버가 완료되어 독립적으로 실행 된 후 원래 서버에서 SQL Server의 최종 백업을 수행하여 새 서버로 가져 오십시오.

데이터를 놓치지 않도록 원래 서버를 일시적으로 오프라인 상태로 만들어야 할 수도 있습니다. 또는 가동 중지 시간을 없애기 위해 두 번째 가동을 설정하고 dns를 새 서버를 가리킨 다음 새 서버에서 수동으로 dns 항목을 업데이트하면 작동 중단 시간이 사실상 없습니다. SQL을 백업하고 새 서버로 복원하는 데 몇 분의 다운 타임이 더 번거롭지 만 다운 타임이 0 일 때 필요할 수 있습니다 .

물론 이것은 하나의 유스 케이스 예제 일 뿐이며 구성 및 여러 변수에 따라 특정 사례를 기반으로 마이그레이션 전략을 작성해야 할 수도 있습니다.

다른 문제는 서버 하드웨어 구성과 관련이 있습니다. 새 서버는 기존 서버와 하드웨어가 100 % 동일합니까? 그렇다면 설정이 더 쉽습니다. 그러나 다른 한편으로는 완전히 다른 하드웨어 구성 인 경우 미리 두 번째 서버를 미리 설정 한 다음 모든 데이터 및 SQL 데이터베이스를 백업하는 다른 전략을 구현해야 할 수도 있습니다. 첫 번째 서버를 수동으로 마이그레이션하여 원하는대로 구성을 변경합니다.

서버 마이그레이션은 결코 쉬운 일이 아니며, 성공적인 이동을 위해서는 서버 또는 직원이 동일한 직원에 대한 깊은 지식이 있어야합니다. 어쨌든 전체 백업을 즉시 가져와 로컬 컴퓨터에서도 세 번째 소스에 저장하는 것이 좋습니다. 최악의 시나리오 (서버 충돌 및 돌이킬 수없는 죽음)가 발생하더라도 여전히 서버를 재 구축하기위한 데이터 사본.

이것이 도움이되기를 바랍니다. 서버 이동과 함께 행운을 빕니다!