– SmileServ 에서 고객에게 권유 하며 많이 사용되는 구성은 Raid는 10 입니다.
이 문서는 Raid 10구성된 서버를 토대로 작성되었습니다.
- 본 문서는 메가레이드 컨트롤러와 MSM 이 구성된 환경에서 TEST 한 내용 입니다.
1-2. Raid 10 기본적인 설명
– raid의 기본적인 종류는 0, 1, 3, 4, 5, 6 이 있습니다. Raid 10은 정확히 얘기하면 1+0 의 조합 입니다.
– 먼저 미러링 Raid 인 Raid1을 구성한 후 raid1로 구성된 drive를 다시 raid 0으로 구성하는 방식 입니다.
– 최소 필요한 디스크는 4개이며 구성방식 및 사용 용도 성능에 따라 디스크의 갯수는 늘어날 수 있습니다.
– raid 10은 미러링 방식이 들어가므로 공간 효율성은 50% 밖에 사용할 수 없으나 raid1로 구성된 그룹에 디스크가 2개 동시에 에러가 발생하지 않는 이상 쉽게 복구 할 수 있으므로 안정성은 뛰어 납니다
.
– 또한 raid1 방식 위에 raid 0 방식으로 구성되어 데이터를 그룹마다 저장하므로 신뢰성과 성능이 뛰어 납니다.
2. 단순 물리적인 장애 후 복구
– 500G 디스크 4개를 이용하여 Raid 10을 구성한 상태 입니다. 총 사용된 용량은 약 2TB 이지만 공간 효율성이 50%이기 때문에 인식된느 용량은 약 1TB인 부분을 확인 할 수 있습니다.
1. 고객 또는 근무자가 실수로 디스크를 적출 했다는 가정하에 동시에 2번디스크와 4번 디스크를 물리적으로 강제 제거 하였습니다.
1-2. 0번 그룹과 1번 그룹의 디스크가 1개씩 사라진걸 확인 할 수 있습니다.
2. 서버 에서 확인 결과 서로 다른 그룹의 디스크를 적출 했기 때문에 아무 이상없이 정상 구동 및 파일생성이 가능 합니다.
3. 이전 상태(2번 항목)에서 적출한 디스크 2번이 장애가 있었다는 가정하에 아예 새로운 디스크를 장착 해 보았습니다.
새로운 디스크를 장착 하였는데 다른 절차 없이 자동으로 리빌딩이 동작하고 있었습니다.
4. “4번” 디스크의 경우 일정 시간 지난 후 제거 했던 디스크 그대로 다시 재장착을 진행 하였습니다.
( 0번 그룹 리빌딩 중간에 장착)
5. Unconfiured Drives 항목에 4번디스크가 추가 되었으며 상태는 Unconfigured Bad 상태 입니다.
6. Change to Unconfiured Good 을 클릭 하여 디스크 상태를 변경 한 후
7. ReplaceMissing Drive를 클릭 하여 span1(그룹1)로 다시 추가 하였습니다.
8. 이 부분에서 디스크4번의 경우 다시 start Rebuild 를 진행 하여야 하지만 기존에 데이터가 쌓여 있던 디스크 이므로 단순히 Make Drive Oline을 해보았습니다.
9. 원래 정상작동 하던 디스크 여서 그런지 단순히 online으로 만 변경 해줘도 에러로그 발견되지 않았으며 사진에는 보이지 않지만 status 또한 online 으로 정상 구동중이 였습니다.
3. 동시에 2개의 리빌딩 진행
-8개의 디스크로 구성한 raid 10 의 경우라도 다른 Raid Level의 비해 신뢰성이 높을 뿐이지 무조건 안전 하다고 할 수없습니다. 가끔 고객서버의 raid의 경우 구성만 해놓고 주기적인 모니터링 혹은 디스크 장애가 발생했음에도 즉각적인 대응을 하지 않아 여러개의 디스크가 장애가 난 사례를 여러번 본 적이 있었습니다.
Riad 리빌딩시 기본 원칙은 리빌딩중 다른작업은 하지 않으며 동시에 리빌딩을 진행하지 않는것 입니다.
하지만 그럼에도 불구하고 동시에 2개의 리빌딩을 동시에 진행 해보도록 하겠습니다.
1. 먼저 물리적인 디스크 제거는 하지 않은 상태이며 MSM을 이용하여 논리적으로 2번 4번 디스크를 제거 하였습니다.
2. 현재 상태에서 디스크가 마운트 된 폴더에 데이터를 만들어 변화를 준 후 동시에 리빌딩 작업을 하도록 하겠습니다.
3. 각각 2번과 4번 디스크들을 원래의 그룹으로 할당 하였으며
4. 동시에 리빌딩 실행을 진행 하였습니다.
5. 리빌딩 Tet 진행 중 사실 아무런 데이터 이동 및 복사 작업을 안하려고 하였으나 리빌딩 시간도 길고 지루하며 왠지 정상적으로 잘 되고 있는거 같아 약 3G가 정도 되는 데이터를 이동하였을 때도 정상적으로 완료되는지 Test를 시도 하였습니다.
6. 2개의 리빌딩 작업중 약 3G 되는 데이터를 복사 해 보았으며, 이 Test를 통하여 일단 리빌딩 중에도 데이터를 읽고 쓰는데는 전혀 문제가 없는 부분을 확인 할 수 있었지만 리빌딩이 완료 될때까지 확신 할 수 없으므로 정확한 진단은 리빌딩이 완료 된 후에 내리기로 결정 하였습니다.
7. 약 2시간 정도의 리빌딩 시간 경과 후 정상적으로 리빌딩이 완료 되었으며 mount 된 폴더 내에서도 읽기/쓰기가 정상적으로 이루어 졌습니다.
( 하지만 고객서버 작업시 위험성을 감수하고 동시에 리빌딩 작업을 진행은 하지 않는것이 현명한 판단이라 생각 됩니다. )
4. 1개의 span그룹 제거 후 복구 Test
– 1개 그룹의 디스크를 동시에 제거 하였을때 과연 복구가 가능한지에 대한 Test 입니다.
1. 그룹0번의 속해 있는 디스크 2개를 물리적으로 강제 제거를 해보았습니다.
서버 내에서 마운트가 풀리거나 하지는 않았으며 ls 명령어나 touch 명령어는 정상적으로 입력이 되었으나 mkdir 을 이용한 디렉터리 생성 mv 나 cp 명령어를 이용한 디렉터리 이동 및 복사 작업은 읽기전용으로 변경되어 confg가 거부 된 상태 입니다.
2. 제거한 디스크를 다시 장착 한 후 인식 시켜 보았지만 아무런 데이터 이동작업이 없었음에도 불구하고 읽기전용 파일시스템 이라는 에러문구를 보여 줍니다.
Umount 명령어로 마운트 해제 조차 안되는 상태가 되어서 마지막 희망으로 리부팅을 진행 하였습니다.)
3. 리부팅 진행 후 다행히도 정상적으로 mount가 되었으며 읽기/쓰기/삭제 가 모두 정상적으로 이루어졌습니다.
5. 1개의 span그룹 제거 후 리빌딩
사실 4번 Test 에서 raid가 깨질걸 예상 하였으나 의외로 단순 리부팅 만으로 복구가 되는 걸 보고 Raid controler 의 성능을 체감 하였습니다.
* 장애테스트를 진행 하다 보니 물리적인 장애 외에는 마땅히 테스트 할 만한 시나리오도 찾기 어렵고 raid가 깨질걸 각오하고 진행한 3번 테스트 에서 정상적으로 raid가 작동하는 현상을 보고 테스트를 한 번 더 진행하고 싶어졌습니다.
1개 그룹의 2개 디스크를 모두 제거 후 1개는 기존 사용하던 데이터가 남아 있는 디스크 1개는 전혀 다른 데이터가 쌓여 있는 디스크를 장착 하였을때 그리고 리부팅 까지 완료 하였을때 과연 4번 Test 처럼 정상적으로 리빌딩이 되어 데이터를 보존 하고 있을지 궁금 하여 한 번 진행 하기로 마음을 먹었습니다.
– 왼쪽 사진은 그룹0번의 디스크를 제거한 상태 이며 오른쪽 사진은 디스크 2개를 다시 장착한 상태 입니다.
( 단 2번 디스크는 기존의 사용중이던 (데이터가 존재) 1번 디스크는 사용하지 않은 디스크 입니다.)
1. 먼저 데이터 망실을 최소화 하는 방법으로 Test를 진행하기 위해 데이터가 존재 하는 2번 디스크만 Online 으로 변경 후 고민을 하였습니다.
– (1)리빌딩 진행 후 리부팅, (2) 리부팅 후 리빌딩 사이에서 어떤 방식으로 진행할까 고민 후 어차피 같은 결과를 보여줄거라는 생각에 (1) 리빌딩 후 리부팅을 방식으로 진행 하기로 하였습니다.
( 단 이번 Test 에서는 데이터 복사 및 이동작업은 하지 않았습니다.)
– 리빌딩이 완료 된 후 서버 내에서 확인 시 4번 Test와 같이 읽기전용 에러 메시지가 출력 됩니다.
정상적으로 리빌딩이 완료 되었는지 확인 하기 위해 리부팅 진행 후 확인을 진행 하였습니다.
– 리부팅 완료 후 정상적으로 디스크 인식이 되었으며 데이터 이동 및 복사도 정상적으로 확인이 되었습니다.
[ 이 문서를 작성하기 전에 든 생각은 서버 엔지니어 라면 기본적인 Raid의 Level 종류나 원리 및 동작방식에 대해서는 충분히 이해하고 있을거라 생각이 들었습니다. 하지만 어떠한 장애가 발생 하였을을 경우 혹은 고객이 장애발생시 대처 방법에 대해서 질문 하였을 경우 장애를 겪어보지 않고 대처를 해보지 않는 이상 장애 처리 및 고객응대가 어려운 점을 겪었고 보았습니다. 또한 이론적으로만 알고 있기에 고객에게 “~ 될 수도 있다., “ ~ 하면 될 것 같다.” 등 확신이 없는 응대 등 확신이 없는 고객 응대를 해왔던 것 같습니다. 그래서 이번 문서를 작성 하면서 오직 장애 위주로 Test를 진행 하였으며 이 문서가 저와 같이 아직 다양한 장애를 겪어보지 못한 분들에게 조그마한 도움이 될 수 있었으면 하는 바램 입니다. 추가적인 Test 사항은 개인블로그와 IDCOHWTO 를 통하여 업데이트 하도록 하겠습니다. ]
감사합니다.