Ploop를 사용하면 컨테이너 내에서 파일이 추가/삭제되므로 디스크 공간이 손실되고 컨테이너를 수동으로 압축해야 한다는 것을 알고 있습니다. 하지만 재부팅하거나 충돌이 발생하면 컨테이너를 복구할 수 없게 될 수도 있다는 내용도 읽었습니다.
컨테이너 손상을 방지하기 위해 OpenVZ 서버를 올바르게 재부팅하는 방법이 있습니까?
답변1
여러 컨테이너를 비정상적으로 종료하더라도 일반적으로 fsck를 수행하는 것으로 충분합니다. 쓰기 작업 중에 실제 하드웨어를 종료하는 것과 크게 다르지 않습니다. 나는 당신이 해당 플루프에 트랜잭션 로그가 있는 파일 시스템을 사용할 것이라고 추측하므로 더 이상 문제가 발생하지 않아야 합니다.
Brian이 언급했듯이 호스트 노드를 적절하게 종료하면 컨테이너가 깨끗하게 유지되고 해당 플루프가 마운트 해제됩니다.
호스트 노드와 동일한 파일 시스템을 사용하는 디렉터리 기반 컨테이너를 사용하는 경우 이미 손상될 가능성이 적습니다. 실제로는 큰 차이가 없으며 회복 시간을 고려해야 할 수도 있다고 생각합니다. 많은 플루프는 하나의 호스트 노드의 파일 시스템보다 fsck하는 데 시간이 더 오래 걸릴 수 있으며 많은 수동 상호 작용이 필요할 수 있습니다.
반면에 호스트 노드에 매우 큰 파일 시스템이 있는 경우 fscking에는 매우 오랜 시간이 걸릴 수 있으며 fsck 중에 해당 컨테이너가 모두 작동 중지됩니다. ploop를 사용하는 컨테이너는 호스트 노드 자체에 fsck할 항목이 없으면 호스트 노드가 다시 시작된 후 시차를 두고 시작될 수 있습니다.
호스트 노드가 중앙 저장소에서 컨테이너 데이터를 로드하고 오류가 발생할 경우 서로 켜거나 끄는 일종의 고가용성 설정을 통해 이를 완화할 수 있지만 너무 지나친 것 같습니다.
플롭을 고려하는 이유는 무엇입니까? 우리는 컨테이너에 있는 많은 작은 파일로 인해 작업 속도가 느려지는 NFS를 통해 더 빠른 성능을 위해 이를 고려했습니다. 그러나 파일 시스템 손상을 언급하고 있으므로 이는 아마도 귀하의 시나리오가 아닐 것입니다.
답변2
아니요, 각 플루프가 제대로 중지될 때까지 기다려야 합니다.
ploop 컨테이너는 루트 디렉터리를 통해 파일에 액세스하기 시작해야 합니다.
simpfs 컨테이너는 chroot와 유사한 디렉토리 구조이므로 켜짐/꺼짐에 관계없이 액세스할 수 있습니다.
저는 수천 개의 컨테이너를 관리하고 있는데 기다리는 시간을 낭비할 수가 없습니다. ploop 컨테이너가 있는 호스트를 관리하려면 액세스하거나 마이그레이션을 수행해야 할 때마다 ploop 컨테이너가 작동할 때까지 기다려야 합니다. 또는 ploop 컨테이너가 꺼질 때까지 기다려야 합니다. 또한 ploop가 손상되면 처음부터 다시 시작해야 합니다. 이러한 피해를 한두 번 경험하지 못하기 때문에 아무리 좋아도 신뢰할 수 없는 시스템이라고 생각합니다.