이 상황에서 어떻게 안전하게 벗어날 수 있나요?
세부사항은 다음과 같습니다:
Xen 서버가 블록 장치를 VM에 할당했습니다. 그러나 이러한 장치는 Xen 내부에도 설치됩니다.
실제로 이러한 블록 장치가 44개 탑재되어 있습니다. 설상가상으로 각 물리적 장치는 4개의 경로를 통해 표시되며 각 경로는 별도의 마운트 지점에 마운트됩니다. 즉, 각 장치는 실제로 5번 설치됩니다.
VM 게스트 OS는 PowerPath 유사 장치(domU에 할당된 phy: 블록 장치)를 통해 경로를 확인합니다.
일부 장치는 ext2 및 reiserfs로 포맷됩니다.
여기에 관련된 파일 시스템 손상의 위험을 나에게 설명할 필요가 없습니다.
파일 시스템을 마운트 해제하는 것만으로도 손상이 발생할 수 있다는 느낌이 듭니다.이 시점에서는 호스트에서 전원 공급 장치를 분리하는 것이 가장 안전한 옵션입니다..
모든 가상 머신(주로 Oracle 데이터베이스)의 애플리케이션은 여전히 실행 중이며 사용 중입니다.
dom0에서 높은 CPU 사용량을 조사하는 동안 이 사실을 발견했습니다. 종료할 수 없는 "찾기" 프로세스가 있습니다. cwd -> /media/disk-12는 /dev/sdf1에서 마운트되고 /dev/emcpowerr에 속합니다.
누군가 묻기 전에 프로세스가 종료될 수 없고 CPU와 RAM을 계속 사용하는 것을 처음 본 것은(죽은/좀비 프로세스와 달리) 뛰어난 커밋된 I/O가 있었을 때였습니다(예: 동기화가 반환되었지만 물리적으로 디스크에 없음). 아직. 보다 일반적으로 이는 테이프 I/O에서 발생합니다.
제안! ?
추신: 이런 일이 발생하지 않도록 설치한 후 장치를 "예약"하기를 원합니까? 아니면 Linux에서는 불가능합니까?
편집: 첫째, 하이퍼바이저의 KDE가 범인이라고 확신합니다. KDE가 데스크탑 아이콘을 생성하기 위해 기록할 수 있는 장치를 설치하고 있는 것 같습니다. 그러나 다른 Xen 서버에서는 같은 일이 발생하지 않지만 다른 모든 서버는 이전 버전의 SLES 및 KDE를 실행하고 있습니다...V4가 문제가 있는 버전인 것 같습니다. 3.4가 더 나은 성능을 발휘합니다.
또한 중요하지 않은 두 개의 가상 머신이 일시 중단되었습니다. 종료한 후에는 파일 시스템 손상으로 인해 다시 시작할 수 없습니다. 마스터/프로덕션 VM은 계속 실행 중이고 해당 VM의 데이터베이스도 계속 작동하고 있지만 이는 분명 시한폭탄입니다. 고객이 다른 서버의 다른 VM에서 환경을 재구축하려고 하지만 일부 구성 요소를 구성하는 데 문제가 있어 기다리고 있습니다...
아무튼, 지금까지 "항상 우아하게 닫히는 모범 사례"를 넘어서는 답이 없었던 것 같아서 좀 더 구체적인 내용을 바랐는데... 아무튼 이번 사태는 좀 더 신중한 생각이 필요할 수도 있겠다는 생각이 듭니다. 종료하면 처리되지 않은 IO(특히 하이퍼바이저의 파일 시스템 메타데이터 업데이트)가 동기화되어 잠재적으로 심각한 파일 시스템 손상이 발생할 수 있습니까?
답변1
단일 마운트 지점에서 디스크에 쓰는 경우 손상이 발생하지 않습니다. 완전히 종료하고(원하는 경우 일시 중지 상태에서 백업) 마운트를 수리하십시오. Dom0에서 필수 응용 프로그램 이외의 다른 응용 프로그램을 실행하지 마십시오. OTOH, 파티션이 여러 경로에서 기록되면 좋지 않으며 더욱 악화됩니다. 코드를 뽑다.
답변2
특별한 이유는 없지만 내 직감에 따르면 다음이 아마도 최선의 접근 방식일 것입니다.
- 응용 프로그램을 닫습니다.
- 네트워크를 통해 가상 머신의 모든 데이터를 백업 위치로 복사합니다.
- VM 내에서 파일 시스템을 마운트 해제합니다.
- 가상 머신을 종료합니다. (이제 이 호스트에서는 가상 머신이 하나만 실행됩니다.)
- domU가 자동으로 시작되도록 설정되어 있지 않은지 확인하세요.
- 하이퍼바이저가 "종료" 작업을 수행하거나 미해결 I/O 등을 동기화하는 것을 방지하려면 호스트에서 전원을 분리하세요.
- 가상 머신을 시작하고 하이퍼바이저 자체가 정전에서 살아남기를 바랍니다.
- 실패하면 환경을 다시 구축하세요. (가상 머신 부팅 디스크는 파일 기반이지만 데이터 마운트 지점은 블록 장치로 할당된 외부 디스크에 있습니다.)
- 하이퍼바이저가 domU에 속한 파일 시스템을 마운트하고 있는지 확인하세요. domU를 시작하기 전에 이러한 파일 시스템을 마운트 해제하세요.)
- KDE 자동 설치를 끄십시오.
- VM을 시작하고 전체 FS 검사를 강제 실행합니다.
11의 대안: 전체 fsck를 수행하지 않고 VM을 시작하고 파일 시스템을 마운트합니다.
그 이유는 Xen 하이퍼바이저가 domU 파일 시스템 손상을 일으키는 데 절대적으로 필요한 것보다 더 많은 기회를 갖는 것을 원하지 않기 때문입니다.
답변3
저는 Xen 전문가가 아니며 이 분야에 대한 경험이 없습니다. 하지만 제가 귀하의 입장이라면 다음과 같이 할 것입니다. 먼저 데이터(아마도 전부)가 손실될 수 있다는 것을 알고 있습니다. 둘째, 스냅샷을 생성한 다음 VM을 일시 중단하여 안전한 다른 위치로 복원하려고 합니다. 환경.
나는 당신에게 헛된 희망을 주고 싶지 않지만, 당신이 무엇이든 회복할 수 있다면 운이 좋을 것이라고 생각합니다.
경고하다: 다음 제안 사항을 따르면 실패할 수 있습니다.모두데이터. 위험을 감수할 가치가 있는지 여부는 귀하에게 달려 있습니다.
다행히도 애플리케이션에서 사용하는 데이터가 휘발성 메모리에 있기 때문에 애플리케이션을 계속 실행할 수 있습니다. 이 상황을 활용하고(각 응용 프로그램이 가능한지 평가해 보고) 실시간 데이터를 네트워크 공유로 내보내야 합니다(응용 프로그램이 해당 기능을 제공하는 경우). 디스크에 데이터가 있는 경우 내보낸 이 함수는 귀하의 find명령문처럼 "잠겨" 있거나 디스크의 변경/손상된 데이터로 인해 충돌(애플리케이션이나 OS 충돌을 일으킬 수 있음)이 발생할 수 있습니다.
그런 다음 다음 문서에 설명된 대로 라이브 스냅샷을 찍어볼 수 있습니다.Xen에서 스냅샷 만들기. 비록 귀하의 명령처럼 중단될 수도 있지만 바이트 단위 스냅샷을 찍고 싶습니다. find그러나 그렇게 큰 기대를 걸지는 않을 것입니다.
이전 명령을 실행하기 전에 Citrix에서 제공하는 이 설명서를 읽어야 합니다.Xen의 스냅샷 이해(PDF).
행운을 빌어요.