저는 오래된 Redhat(5) 서버를 가지고 있으며 9개의 어레이 파일 시스템을 새 어레이로 이동해야 합니다. 이를 수행하는 가장 좋은 방법과 프로세스 작동 방식에 대한 도움을 찾고 있습니다.
데이터는 배열 수준 복사본으로 직접 복사됩니다. 기존 서버에서 9개의 LUNid(WWN)를 얻었고 이를 multipath -ll의 출력에서 확인했습니다. 또한 이전 스토리지에 해당하는 새 스토리지에도 LUNid가 있습니다. 새 스토리지로 마이그레이션하는 방법을 잘 모르겠습니다. pvscan과 같은 LVM 명령의 기능을 완전히 이해하지 못합니다. 프로세스는 어레이 파일 시스템을 정지하고 마운트 해제한 후 /etc/fstab에서 제거하여 부팅 시 마운트를 시도하지 않도록 하는 것이라고 생각합니다. 그런 다음 서버를 종료하고 새 어레이 LUNid를 연결한 다음 시작합니다. 이 단계에서는 multipath -ll의 새 LUNid를 확인하고 싶습니다. 맞습니까? 사용자 정의 장치 이름 지정을 지정하지 않았으므로 각 장치에 대한 장치 이름의 mpathX 형식도 표시됩니까? 각 PV에는 UUID가 있고 VG와 LV도 마찬가지라는 것을 알고 있습니다. LVM이 각 PV, 볼륨 그룹 및 논리 볼륨을 재구축하여 모두 동일한 데이터를 포함하도록 하는 데 필요한 이것이 중요한 정보입니까? 즉, 새 LUNid 디스크 중 하나의 /dev/mapper/mpath24에 대한 PV는 해당 디스크의 UUID로 식별되므로 동일한 데이터가 됩니다.
이것이 작동할까요? 재부팅 및 멀티패스가 경로와 장치를 검색하고 열거한 후(그리고 /etc/multipath/bounds 업데이트) LVM이 시작되고 자동으로 디스크를 요청하며 기본적으로 작동합니다. 그러면 이전처럼 파일 시스템을 계속 마운트할 수 있나요?
그렇지 않다면 어떤 조치를 취해야 합니까? pv/vg/lv 스캔을 실행해야 합니까? 다중 경로가 시작될 때 어떤 일이 발생하고 LVM이 시작될 때 어떤 일이 발생하는지 이해하는 것이 도움이 됩니다.
마지막으로, 재시작을 피하는 것이 가능합니까, 아니면 프로세스의 질서를 위해 그렇게 하는 것이 가장 안전한가요? 재부팅하지 않고 이 작업을 수행할 수 있다면 파일 시스템을 마운트 해제하고 새 LUNid를 연결한 후 어떤 단계를 수행해야 합니까? 재부팅 프로세스와 동일한 작업을 수행하는 일련의 다중 경로 지정 및 후속 LVM 명령이 있습니까? 두 경우 모두 추가 조치를 취해야 합니까?
감사해요.
강
답변1
명확히 하자면, lvm으로 미러를 만든 다음 분리할 계획인가요? 아니면 어레이 간에 데이터가 복사되었습니까?
데이터가 한 어레이에서 다른 어레이로 복사되고 있는지 여부입니다. 과정은 간단합니다. 동기화되었을 때. IO를 중지하고 VG를 내보냅니다. 현재 디스크 호스트의 가시성을 제거합니다. 복사를 중지합니다. 복사본을 분할합니다. 이 옵션을 사용하면 프로세스가 올바르게 완료되지 않은 경우 돌아갈 수 있습니다.
호스트에 새 디스크를 제공합니다. 이것은 새로운 UUID를 갖게 됩니다. LUN/볼륨의 UUID는 해당 LUN/볼륨이 상주하는 어레이에 따라 다릅니다. 새 운전실에서 VG를 가져옵니다.
이제 끝났습니다.
물론 호스트의 새 디스크는 다중 경로를 미리 올바르게 구성해야 합니다.
어쨌든, 프로덕션 데이터로 이 작업을 수행하기 전에. 테스트 테스트는 매우 적은 테스트 데이터를 사용하여 소스에서 대상까지 전체 방법을 테스트합니다.
LVM을 사용하여 모든 작업을 수행하려면 어떻게 해야 합니까?
이것은 광범위하고 아마도 그다지 구체적이지 않은 질문입니다.
결론적으로. LVM을 미리 알지 못한다면 이것은 어려운 작업입니다.
단계는 다음과 같습니다: 1.- 소유자에게 새 객실을 보여줍니다. 1.a 어레이 제조업체(HP, DELL, IBM...)는 해당 어레이 모델에 대한 특정 구성이 포함된 multipath.conf를 제공합니다. 검색 및 신청
1.b 그러면 새 디스크가 호스트에 표시됩니다.
mpathX는 옵션 중 하나입니다. 아마도 최고는 아닐 것입니다.
1.c multipath.conf에서 디스크 이름을 정의할 수 있습니다.
- 새 디스크를 스캔합니다.
3.- 디스크 포맷
3.a 제조업체에서 특별한 정렬을 요구하는지 확인합니다. 전체 디스크 또는 파티션의 PV인 경우 일반적으로 다릅니다.
4.- 물리 볼륨 생성
5.- 여기에는 몇 가지 옵션이 있습니다.
5.a VG에 디스크를 추가하고 각 어레이의 각 볼륨에 대한 미러를 생성합니다.
5.a1 stop service.
5.a2 Separate the mirrors of each array --split-mirrors
5.a3 export old disks
완료되면 각 어레이에 1개의 전체 복사본이 있게 됩니다.
서비스를 시작합니다.
LVM에 대한 사전 지식 없이 프로덕션 데이터를 사용하여 이 작업을 수행합니다.매우 위험할 수 있다.
시험 새로운 작은 VG와 여러 볼륨을 만들고 파일 시스템에 데이터를 추가할 수 있습니다. 새 스탠드에서 충분한 크기의 디스크를 추가합니다. 전체 작업을 보려면 동일한 VG 및 미러 및 --split-mirror에 배치하세요.
시험 결과
답변2
파일 시스템을 새 어레이로 이동하는 프로세스가 완료되었습니다. 다음은 단계입니다.
어레이 파일 시스템이 정지된 후 마운트 해제됩니다.
파일 시스템이 /etc/fstab에서 제거되었으므로 부팅 시 마운트되지 않습니다. 데이터의 어레이 수준 복사본을 새 스토리지 어레이에 복사합니다. LUN은 이전 어레이에서 연결이 끊어지고 새 어레이에 연결됩니다. 호스트가 다시 시작되었습니다. "multipath -ll" 명령을 사용하면 새 LUN이 연결되어 있고 scsi 장치(/dev/sd*)에 대한 경로도 명확하다는 것을 확인할 수 있습니다(4개의 경로는 이중 포트 HBA 쌍에 해당함). LVM 사용: "pvs"는 물리적 장치를 예상대로 표시합니다. 그러나 "vgs"에는 볼륨 그룹이 표시되지 않습니다.
"vgscan"을 실행하면 모든 볼륨 그룹이 표시되므로 "vgs"도 표시됩니다. 그러나 파일 시스템 마운트가 실패하고 /dev/mapper/vg_name/lv_name 경로에 대해 '해당 파일 또는 디렉터리가 없습니다'라고 보고됩니다. /dev의 이 경로에는 볼륨 그룹 이름이 표시되지 않습니다. "vgchange -ay"를 실행하여 볼륨 그룹을 "활성화"하면 경로가 /dev에 표시됩니다. 그런 다음 파일 시스템을 마운트하기만 하면 됩니다.
데이터가 존재하고 올바른지 확인하십시오. 파일 시스템을 포함하도록 /etc/fstab을 복원합니다. 모든 것이 원활하게 진행되는지 확인하기 위해 테스트 재부팅이 수행되었습니다. 충분히.
LVM이 디스크 시작 부분에 UUID를 포함하는 헤더를 쓴다는 것을 아는 것이 많은 도움이 됩니다. 이는 기본 스토리지 경로 및 장치가 변경될 때 디스크를 식별하고 이를 올바른 LVM 개체(pv, vg, lv)에 유지하는 메커니즘입니다.
마지막으로 "vgs" 대신 "vgdisplay"를 사용하면 초기에 "vgs"에서 볼륨 그룹 정보가 부족하고 /dev에 경로가 표시되지 않을 때 진단하기가 더 쉽습니다. "vgdisplay"는 볼륨 그룹의 상태를 표시하고 해당 단계에서 유용한 단서를 제공합니다.
새 LUN 연결부터 머신 부팅까지 전체 프로세스는 약 15분 정도 소요되며, 볼륨 그룹 상태가 즉시 진단되면 훨씬 더 빨라질 수 있습니다.
준비하는 동안 모든 관련 파일과 데이터의 백업 복사본이 별도로 만들어지고 저장되는지 확인합니다(/etc/fstab, /etc/lvm/, /etc/multipath.conf /etc/multipathd/bindings 등). 또한 pvdisplay, vgdisplay, lvdisplay, multipath -ll, fdisk -l 등에서 출력을 캡처했습니다(각 파일 시스템에서 일부 샘플 데이터의 생성된 해시도 검사로 사용되었지만 실제로 사용되지는 않음). 또한 변경 프로세스 전반에 걸쳐 콘솔에 액세스할 수 있고 세션이 활성 상태를 유지하는지 확인했습니다.