Solaris 서버는 미래의 ZFS 풀을 허용합니까?

Solaris 서버는 미래의 ZFS 풀을 허용합니까?

ZFS에 대한 나의 경험은 일반적으로 다음과 같습니다.그냥 작동해요, 따라서 문제가 되지 않는다는 대답이 나올 것으로 예상합니다. 하지만 데이터 풀이 잘못되면 1월을 망칠 수 있으므로 다시 확인하고 싶습니다.

이는 별도의 데이터 풀과 관련된 두 가지 상황에서 실제로 나타날 수 있는 질문입니다. 지금은 첫 번째 문제를 다루고 있지만 두 번째 문제도 궁금합니다.

  • 시스템 디스크(예: 를 보유한 디스크 rpool)의 스토리지에 오류가 발생했지만 데이터 풀의 스토리지는 양호하므로 백업에서 시스템 디스크를 복원하고 데이터 풀의 라이브 스토리지를 계속 사용하려고 합니다.
  • VM에서 Solaris를 실행 중이고 하이퍼바이저가 만든 스냅샷으로 롤백하려고 합니다(~ 아니다) 의 ZFS 스냅샷이지만 rpool데이터 풀은 "독립" 모드인 디스크, RDM 등에 저장되므로 롤백되지 않습니다.

이 두 상황 모두에서 Solaris가 백업으로 부팅되면 알고 있지만 (기억하는 한) 한 번도 넣은 적이 없는 상태에 있는 데이터 풀을 보게 될 것입니다.

나는 주로 시스템 디스크를 되감기 전에 시스템이 완전히 종료된 경우와 되감기되는 이미지 전에 시스템이 완전히 종료된 경우에만 관심이 있습니다. 실행 상태 간 전환이 조금 더 까다로울 것으로 예상됩니다.

또한 내 특별한 경우에는 풀의 저장소 구조와 저장소 경로가 변경되지 않았습니다. 다시 말하지만, 만약 그렇다면 이것이 더 까다로울 것으로 예상합니다.

나는 Windows와 NTFS에 대해 이것을 묻지 않을 것입니다. 왜냐하면 그것은 비교적 단순한 분리 시스템이므로 왜 그런지 알기 어렵기 때문입니다.않을 것이다일하다. 그러나 Solaris는 일종의 풀 메타데이터를 유지하는 것 같습니다.대역 외, 시스템 간에 풀을 이동 해야 한다는 사실과 시기(VMware 덕분에 그런 방식으로 한 번도 해본 적이 없는 작업)에서 알 수 zpool export있습니다 zpool import. 이 메타데이터와 그 목적에 대한 나의 지식은 제한되어 있으므로 이 상황의 영향을 추론하기가 어렵습니다. (이것에 대한 설명이 좋을 것 같습니다!)

실제로 아직 사전 롤백 시스템에 액세스할 수 있습니다. 이는 불운한 예방 유지 관리 디스크 변경(SmartArray가 ZFS보다 멍청하기 때문에 데이터가 손실됨) 후 1716 POST 경고를 던진 HP SmartArray가 지원하는 VMFS 데이터 저장소에 있습니다. 모든 중요한 VM은 여전히 ​​괜찮아 보이고 해당 파일 시스템을 검색한 결과 오류가 발견되지 않았지만 ESXi가 의심되는 이유가 있기 때문에 어쨌든 아주 최근 백업에서 어레이를 복원할 계획입니다.게스트에게 오류를 전달하는 대신 자동으로 불량 섹터를 0으로 만듭니다., 그래서 나중에 어딘가에 숨어 있는 제로 섹터가 나를 괴롭히는 위험을 감수하고 싶지 않습니다.

Solaris VM의 경우 ZFS가 이를 포착하므로 제로화 섹터에 대해 걱정할 필요가 없지만 대부분의 다른 VM은 멍청한 파일 시스템을 사용합니다. 그러나 백업은 전체 VMware 데이터 저장소의 이미지이므로 이를 수정하면 Solaris VM도 롤백됩니다. 실제로 이 VM을 스크러빙했는데 rpool오류가 발견되지 않았습니다. 따라서 원할 경우 해당 VMDK를 다른 곳에 보관하고 롤백 후에 다시 복사할 수 있습니다. 그러면 이 전체 질문은 다음과 같습니다. 무트. 아무도 대답하지 않으면 그렇게 할 것 같아요, ㅋㅋㅋ. 그런데 예전부터 궁금했던 부분이 있어서 여쭤보겠습니다.

그래서 질문은,그냥 시스템 디스크의 저장소를 롤백하고 작업을 완료해도 되나요? 아니면 사전 롤백 시스템에서 풀을 내보내고 롤백하고 스토리지를 연결하기 전에 풀을 삭제한 다음 스토리지를 연결하고 풀을 가져와야 합니까? 후자의 소리가 마음에 들지 않습니다. 그 이유 중 하나는 해당 풀에서 CIFS와 iSCSI가 모두 제공되고 설정 방법이나 설정 방법조차 기억이 나지 않기 때문입니다. 화낼 거야. (우리에게 풀타임 시스템 관리자가 없다고 말할 수 있나요? ㅋㅋㅋ)

VM이 이전 버전인 Solaris 11.0을 실행하고 있습니다.

(덧붙여, 같은 질문 때문에 좀 더 오래됐네요. 혹시라도 업그레이드를 시도하기 전에 VM을 스냅샷으로 찍어두고 싶었는데, 롤백된 시스템이 독립 풀에 어떻게 반응할지 걱정이 되어서 그냥 그리고 예, 스냅샷을 찍을 수도 있다는 것을 알고 있지만 rpool매일 Solaris를 사용하지 않는 사람에게는 같은 수준의 편안함을 제공하지 않습니다.)

답변1

이것은 "zfs가 작동하는" 종류의 답변 중 하나입니다 ...

풀 메타데이터는 실제로 로컬 OS가 아닌 풀에 저장됩니다. 예를 들어 시스템이 충돌하고 완전히 종료되지 않은 경우 풀 내의 메타데이터는 풀이 완전히 "내보내기"되지 않았다는 것을 알고 있습니다. 이 풀을 새 시스템으로 가져오려고 하면 내보내지 않고 다른 시스템에 속하지 않는다는 불만 사항이 표시됩니다. 이 시점에서 zpool import -f(force)를 수행하면 문제가 해결됩니다.

따라서 데이터 풀에 따라 해당 풀의 데이터는 언제/어디서 풀을 다시 가져오려고 했는지에 관계없이 안전합니다. "복원된" rpool로 부팅하려는 경우 해당 rpool의 OS는 가져와야 할 풀에 대해 알고 간단히 데이터 풀을 가져옵니다. 풀을 내보냈는지 여부는 추적하지 않습니다. 단, 풀을 내보낸 후에는 OS가 더 이상 이를 전혀 따라잡지 못합니다.

이제 rpool 질문과 관련하여. VM 스냅샷, 테이프 백업 등에서 복원해도 데이터 풀을 처음 생성하거나 가져오기 전에 백업을 수행하지 않는 한 데이터 풀을 처리하는 방식이 변경되지 않습니다. 그렇다면 OS가 복원된 후 풀을 가져오기만 하면 됩니다. 데이터 풀의 데이터는 rpool의 상태에 관계없이 안전합니다.

도움이 되었기를 바랍니다.

여담이지만, 솔라리스가 데이터 풀에 어떻게 반응할지 확신이 없어서 업그레이드를 꺼린다고 언급하셨습니다. 그것에 대해 걱정하지 마십시오. 업그레이드는 알려진 풀을 보존하고 필요에 따라 가져옵니다.

또한 Solaris OS 업그레이드는 개별 "부트 환경(BE)"에 자체 포함되어 있습니다. 따라서 OS 업그레이드를 수행하면 실제로 OS가 계속 실행되는 동안 새 버전을 포함하는 완전히 독립적인 OS 설치가 생성됩니다. 그런 다음 재부팅하면 새 OS에 나타납니다. 새 OS에 문제가 있는 경우 - 즉. 예상하지 못한 라이브러리 등의 변경 사항 - 다시 재부팅하고 원래 11.0 버전으로 전환하면 업그레이드 전과 똑같은 상태가 됩니다. OS 업그레이드를 수행하는 멋진 방법입니다!

관련 정보