끔찍한 상황-여러 독립 OS 인스턴스에 의해 동시에 마운트 된 파일 시스템

이 상황을 안전하게 벗어나려면 어떻게해야합니까?

세부 내용은 다음과 같습니다.

xen 서버에는 VM에 할당 된 블록 장치가 있습니다. 그러나 이러한 장치는 Xen 내부에도 마운트되었습니다.

실제로 이러한 블록 장치 중 44 개가 이와 같이 마운트되었습니다. 설상가상으로, 각 물리적 장치는 4 개 이상의 경로에서 볼 수 있으며 각 경로는 별도의 마운트 지점에 마운트됩니다. 다시 말해, 장치는 실제로 각각 5 번 장착됩니다.

VM 게스트 OS는 PowerPath 의사 장치 (phy : 블록 장치를 domU에 할당)를 통해 경로를 확인합니다.

일부 장치는 ext2 및 reiserf로 형식화됩니다.

여기에 관련된 파일 시스템 손상 위험을 설명 할 필요가 없습니다.

파일 시스템을 마운트 해제하는 것만으로도 손상이 발생할 수 있으며이 시점에서 호스트에서 전원을 공급받는 것이 가장 안전한 옵션이라고 생각 합니다.

모든 VM에서 대부분의 Oracle 데이터베이스 애플리케이션이 여전히 실행 중이며 사용 중입니다.

dom0에서 높은 CPU 사용량을 조사 할 때 이것을 발견했습니다. / dev / emcpowerr에 속하는 / dev / sdf1에서 마운트 된 cwd-> / media / disk-12와 함께 처리 할 수없는 "찾기"프로세스가 있습니다.

누군가가 묻기 전에 프로세스를 죽일 수 없으며 CPU 및 RAM을 계속 사용하지 않는 경우 (소모 함 / 좀비 프로세스와 달리), 커밋 된 I / O가있을 때입니다. . 더 일반적으로 이것은 테이프 I / O에서 발생합니다.

제안!?

추신 : 나는 이런 종류의 것을 막기 위해 일단 장치가 마운트되면 "예약"될 것으로 예상 했습니까? 아니면 리눅스에서는 불가능합니까?

편집 : 먼저 하이퍼 바이저 내의 KDE가 범인이라고 확신합니다. KDE가 데스크탑 아이콘을 작성하기 위해 로깅 할 수있는 장치를 마운트하고있는 것 같습니다. 그러나 다른 Xen 서버에서도 같은 일이 일어나지 않지만 다른 모든 서버는 훨씬 더 오래된 버전의 SLES 및 KDE를 실행하고 있습니다.

또한 두 개의 중요하지 않은 VM이 중단되었습니다. 종료 한 후에는 파일 시스템 손상으로 인해 다시 부팅되지 않습니다. 메인 / 프로덕션 VM이 여전히 실행 중이고 그에 대한 데이터베이스가 여전히 작동하지만 분명히 이것은 시한 폭탄입니다. 고객이 다른 서버의 다른 VM에서 환경을 재 구축하려고하지만 일부 구성 요소를 구성 할 때 문제가 발생하여 대기 중입니다 ...

어쨌든 나는 지금까지 어떤 대답도 "모범 사례가 항상 정상적으로 종료되지 않았다"고 생각하지 않았고 더 구체적인 것을 얻고 자합니다. 생각. 시스템을 종료하면 뛰어난 IO, 특히 하이퍼 바이저의 파일 시스템 메타 데이터 업데이트가 동기화되어 잠재적으로 심각한 파일 시스템 손상이 발생합니까?

디스크가 단일 마운트 지점에서 기록되는 경우 아무런 피해가 없습니다. 마운트를 수정하십시오 (정지 된 상태에서 백업). Dom0에서 필요한 앱 외에는 아무것도 실행하지 마십시오. OTOH, 파티션이 여러 경로에서 작성되는 경우 이는 불량이며 두 번째로 나빠집니다. 코드를 뽑다.

구체적인 이유는 없지만 다음과 같은 것이 가장 좋은 방법이라고 생각합니다.

1. 응용 프로그램을 종료하십시오.
2. 네트워크를 통해 VM의 모든 데이터를 백업 위치로 복사하십시오.
3. VM 내에서 파일 시스템을 마운트 해제하십시오.
4. VM을 종료하십시오. 현재이 호스트에는 하나의 VM 만 실행 중입니다.
5. domU가 자동으로 시작되도록 설정되어 있지 않은지 확인하십시오.
6. 하이퍼 바이저가 "닫기"작업, 미처리 I / O 동기화 등을 수행하지 않도록 호스트의 전원을 빼십시오.
7. 하이퍼 바이저 자체가 전원 공급 장치에서 살아남기를 바라면서 VM을 부팅합니다.
8. 실패하면 환경을 다시 빌드하십시오. VM 부팅 디스크는 파일 기반이지만 데이터 마운트 지점은 블록 장치로 할당 된 외부 디스크에 있습니다.
9. 하이퍼 바이저가 domU에 속하는 파일 시스템을 마운트하고 있는지 확인하십시오. domU가 시작되기 전에 마운트 해제하십시오.)
10. KDE 자동 마운팅을 끕니다.
11. VM을 시작하고 전체 FS 검사를 수행하십시오.

11 : 대안으로 VM을 시작하고 전체 fsck없이 파일 시스템을 마운트하십시오.

추론은 Xen 하이퍼 바이저가 domU 파일 시스템에 손상을 입히는 데 절대적으로 필요한 기회를 더 이상 갖기를 원하지 않기 때문입니다.

나는 Xen 전문가가 아니며 아직 경험이 없습니다. 그러나 내가 당신의 자리에 있었다면 나의 접근 방식은 다음과 같습니다. 먼저 데이터를 잃을 수도 있습니다 (아마도 모두). 두 번째로 스냅 샷을 생성 한 다음 VM을 일시 중단하고 안전한 다른 환경에서 복원하려고합니다.
나는 당신에게 잘못된 희망을주고 싶지 않지만, 당신이 무엇이든 회복 할 수 있다면 운이 좋을 것이라고 생각합니다.

경고 :이 조언을 따르면 모든 데이터가 손실 될 수 있습니다 . 위험의 가치가 있는지 여부는 귀하에게 달려 있습니다.

운이 좋으면 응용 프로그램이 사용하는 데이터가 모두 휘발성 메모리에 있기 때문에 응용 프로그램이 계속 작동합니다. 응용 프로그램에서 이러한 기능을 제공하는 경우이 상황을 활용하고 (앱별로 상황이 가능한지 평가하려고 시도) 라이브 데이터를 네트워크 공유로 내보내십시오. 데이터가 디스크에 있으면이 내보내기 기능은 find변경 / 손상된 디스크 데이터로 인해 명령문 과 같은 "잠금" 또는 충돌 (및 응용 프로그램 또는 OS 충돌)이 될 수 있습니다 .

그런 다음 Xen에서 스냅 샷 생성 문서의 지침에 따라 라이브 스냅 샷을 만들 수 있습니다. 나는 당신의 find명령 과 많이 멈출 수 있지만 바이트 단위 스냅 샷을 원할 것입니다 ... 그러나 나는 많은 희망을주지 않을 것입니다.

이전 명령을 수행하기 전에 Citrix에서이 문서를 읽어 Xen의 스냅 샷 이해 (PDF)를 이해해야 합니다.

행운을 빌어.