세번째의 드라이브를 교체하면서 상황이 조금씩 꼬이기 시작하였다. 전날 저녁 분명히 패리티 수정이 60% 이상 진행된 것을 보고 퇴근하였었는데 아침에 출근을 하여 확인하니 30% 정도로 오히려 후퇴한 것이 아닌가? 중간에 문제가 있어서 패리티 수정을 다시 시작한 것일까? 마지막 다섯번째 드라이브를 교체할 때까지 같은 현상이 나타났다. 어쨌든 예상한 시간을 초과하여 교체가 다 끝났다고 생각하고 늘어난 저장용량을 적용하려는데 드라이브에 이상이 있다는 메시지가 나온다. NAS를 재부팅을 하였는데 이때부터 문제가 시작된 것이다. 제대로 부팅이 안되는 것이다. 장비 전면의 LED 표시도 이상하고, 웹으로 접속도 안된다.
무엇이 문제일까.
예전에 쓰던 디스크를 하나 꽂아 보았다. 정상적으로 부팅은 된다. NAS에 이상은 없다는 뜻이다. 저장공간 수정을 하지 않고 새 디스크를 하나씩 꽂아가면서 부팅이 잘 됨을 확인한 뒤, 아예 전면적인 저장공간 재설치를 해 버렸다. 즉 일주일에 걸친 교체와 자동 복구는 하나도 소용이 없었던 것이다. 원래 계획대로 5 개 디스크를 한번에 교체하여 새로 설정을 하였다면 하루 정도에 모든 일이 끝났었을 것이다.
이제 리눅스 클라이언트 쪽으로 가 보았다. NAS의 공유 저장소를 NFS로 마운트하는 예전 설정을 그대로 사용하였지만 오직 root가 읽을 수만 있는 권한으로 제한된 상태이다. NAS의 저장공간을 새로 설치하면서 설정을 고쳐야만 하는 상황인 것이다. NFS로 파일시스템을 공유할 때에는 계정명이 아니라 숫자 uid를 기반으로 한다고 하였다. 서버, 즉 NAS쪽에서 이를 건드려야 하는데 어떻게 하는지를 잘 모르겠다. 어림짐작으로 제어판의 NFS 규칙 편집 창에서 Squash 설정을 '매핑 없음'에서 'admin에 root 매핑'으로 바꾼 뒤 NAS를 재부팅하였다. 리눅스 클라이언트로 가니 이제 NAS 공간이 읽고 쓸 수 있게 바뀌었다. 실제로는 drwxrwxrwx 상태라서 하부 디렉토리 수준에서 손을 대야만 했다. 상세한 것은 Synology 지식기반의 로컬 네트워크 내에서 Synology NAS의 파일에 액세스하는 방법(NFS) 항목을 참고하라.
NAS로 ssh 로그인이 되도록 만들면 일반적인 리눅스 기반의 NFS server를 다루듯이 설정을 바꿀 수 있을 것이다. 하지만 아직은 5000번 포트로 NAS에 접속하여 설정을 건드리는 것이 편하다.
이렇게 하여 지난 6월 말부터 계획한 스토리지 증설 '사업'은 마무리되었다. 요약하자면 다음의 일들을 수행한 셈이다.
- Dell PowerVault MD1200(DAS)을 도입하여 Dell PowerEdge R910 서버에 연결하였다.
- 모든 유전체 관련 데이터를 DAS로 옮겼다. Synology DiskStation DS1512+(NAS)에 있던 파일도 마찬가지로 복사하였다.
- NAS의 HDD를 기존의 4 TB에서 6 TB의 것으로 교체하여 저장 용량을 늘렸다. NAS는 만 4년이 조금 넘게 24시간 구동하던 것이다.
댓글 없음:
댓글 쓰기