|
|
|
|
Tech Info - 스토리지와 서버 |
 |
2005년 03월 29일 00:00:00 |
|
 |
|
|
“기간 스토리지 교체 이렇게 하라”
다양한 옵션들 선택 가능 … ‘복제·동기화’로 마무리
스토리지 시스템에 더 이상 믿고 일을 맡기기 힘든 때가 다가오고 있다. 마치 오래된 낡은 차를 떠나보낼 때처럼, 싫겠지만 바꿔야 할 때가 온 것이다. 기간 스토리지 시스템을 대체할 때는 단순히 플러그 앤 플레이의 문제가 아니다. 최근의 NWC의 스토리지 프로젝트에 대한 경험을 바탕으로, 스토리지 업그레이딩에 대한 몇 가지 팁을 공유해 보자.
우리는 최근 네트워크 스토리지 솔루션인 NAS(Net-work Attached Storage)가 있는 우리의 생산 네트워크와 NWC 비즈니스 애플리케이션 랩에서 실질적인 문제들을 경험한 바가 있는데, 여기에는 NWC의 모든 지원 파일과 니어라인 백업(nearline back)을 비롯해 위스콘신주 그린베이의 리얼월드랩용 지원 프로그램과 테스트 결과 대부분이 저장돼 있었다.
약 6개월 전, NAS는 특별한 이유없이 가끔씩 백업에 실패를 하기 시작했으며, 디스크가 찼다고 가정을 했다. 10%의 여유 공간이 있었음에도 불구하고 속도는 금방 느려졌으며, NSS NAS 박스는 24×7로 가동이 돼야만 하는 상황이었다. 때문에 어쩔 수 없이 우리는 보다 크고 안정적인 것으로 바꾸기로 결정을 했다.
이번 워크샵에서는 이 프로젝트를 진행하는 동안 얻은 교훈을 이야기하고, 중요한 스토리지 업그레이드를 가능한 한 고통없이 수행할 수 있는 방법에 대해 이야기할 것이다. 물론 각각의 스토리지 환경은 다르겠지만, 공통적으로 고려해야 할 사항이 있으며, 기간 스토리지 시스템을 교체할 때 주의해야 할 함정들도 있다.
선택의 과정
우선 새로운 스토리지 시스템을 선택하라. 다행히도 가격과 품질면에서 다양한 옵션들이 있기 때문에 자기에게 가장 잘 맞는 시스템을 쉽게 고를 수 있을 것이다. 우리는 그 가격과 디자인, 그리고 iSCSI 지원을 감안해 아답텍의 스냅 서버 18000(Snap Server 18000)을 선택했다.
우리는 PC 기반 디자인에 의해 속도를 제한받지 않는 어포더블 솔루션을 찾고 있었다. 스냅 박스의 백플레인은 비록 다른 대부분의 시스템들처럼 아직도 얼마간 PC 컴포넌트를 사용하긴 하지만 일반 PC 어플라이언스보다 더 많은 대역폭을 제공한다. 백플레인에서는 파이버 채널이 이용되기 때문에, 우리는 좋은 가격대에 높은 처리속도를 얻을 수 있었다. 더 저렴한 PC 기반 NAS 제품도 있지만 우리에게는 더 높은 속도가 필요했다. 그리고 지금은 iSCSI 지원이 필요하지 않지만, 이메일과 데이터베이스가 우리 서버에 있는 빈 디스크 용량을 소모하기 시작했기 때문에 마이그레이팅할 준비를 해두는 게 좋을 것 같았다.
제품을 선택한 후에는 공격할 계획을 세워야 하는데, 이는 곧 새 시스템에서 얼마나 많은 스토리지 공간을 제공할 것인지를 파악해 디스크를 파티셔닝하고, 교체하고 있는 시스템의 복제를 뜨고, 그리고 이상적으로는 각 볼륨에서 더 많은 공간이 제공되도록 하기 위해서다.
서로 다른 디스크나 CIFS(Common Internet File System) 쉐어를 사용하기 위해 구성과 심지어 애플리케이션 소스 코드를 변경하는 데는 생산 환경에서 많은 비용이 들어갈 수도 있다는 사실을 명심해야 한다. 오리지널 스토리지 시스템의 구성을 그대로 복제하도록 하라. 우리는 새 스냅 서버에 하나의 파티션을 만들고, 이것을 원래 NSS NAS 서버와 정확히 같은 이름과 디자인인데 공간만 더 많은 형태로 구성했다. 또한 두 번째 볼륨은 iSCSI로 구성함으로써 NWC 영역가 블록 스토리지를 필요로 하는 NAS로 이동하는 것을 수월하게 만들었다.
내 공간은 어디에?
한 가지, 우리가 간과한 부분은 새로운 스토리지 박스에 볼륨의 스냅샷을 유지하기 위해서는 사용 가능한 스토리지 공간의 10~25%가 필요하다는 사실이다. 사용 가능한 공간에서 15%를 잃는다고 문제가 되진 않겠지만, NSS에 있는 디스크와 똑같이 드라이브 크기를 정할 경우 스냅샷 공간이 부족해지는 불상사가 생길 수 있다. 이런 상황을 해결하기 위해서는 전체 스냅을 다시 초기화하고 구성을 다시 하거나, 혹은 SNAP 볼륨의 스냅샷 기능을 끄면 될 것이다. 다행히도 우리는 향후 성장을 고려한 공간을 만들기 위해 각 파티션의 크기를 대폭 늘려잡았기 때문에, 공간 부족을 아쉬워 할 순간이 그리 빨리 닥치지는 않을 것이다.
우리의 공격 계획은 단순했지만, 대부분의 스토리지 서버 설치에서 적용될 수 있는 것이다. 우리는 NSS를 중단시키고 스냅으로 교체할 때가 되기 이전에 새로운 스냅에 NSS의 IP 어드레스와 호스트 이름을 재할당할 수 있도록 구성했다.
동기화시키기
새로운 스토리지를 구성하는 데 있어 최종 단계는 복제와 동기화다. 두 개의 NAS 시스템들간에 기가바이트급 데이터들을 복사하는 일은 전혀 우리가 원하는 일이 아니며, 특히 일부 데이터 파일들은 매일같이 바뀌기까지 한다. 때문에 우리는 CA의 브라이트스토어(BrightStor) 스토리지 관리 소프트웨어를 이용해 복제와 동기화 프로세스를 수행하고 싶었지만, 우리에게 있는 브라이터스토어는 시험판 라이선스뿐이었다. 때문에 우리는 한 주에 불과한 긴박한 시간 압박 아래서 새로운 복제 및 동기화 솔루션을 찾아나서야 했다.
우리는 먼저 스토리지 네트워킹 월드에서 전시 중이던 스냅의 스냅 18000용 복제 소프트웨어를 고려해 보았다. 이 툴은 적당하긴 했지만 우리 시간대에 맞춰 스냅에서 보내줄 수가 없었기 때문에, 선택은 XO소프트의 왠싱크HA (WANSyncHA)로 결정됐다. 왠싱크HA는 매우 간단한 방식으로 복제와 동기화를 처리해 준다. 왠싱크HA 인터페이스는 NSS에서 스냅 서버까지 모든 볼륨의 복제를 약 2분만에 셋업했다.
새로운 스토리지 시스템에 데이터를 복사하는 데 사용할 수 있는 툴이 있는지를 반드시 확인하고, 테스팅을 통해 이것을 최신판으로 유지하라. 정규적으로 벌크 카피가 돌아가도록 셋업하기보다는 이렇게 하는 편이 더 수월하다.
사소한 일들
살다보면 중요한 프로젝트에 접근하지 못하는 것처럼 느껴질 때가 있을 것이다. 우리가 왠싱크HA를 설치했을 때도 바로 이런 기분이 들었다. 이 소프트웨어를 돌리자마자 이것은 스냅 18000에서 허가 에러를 보내기 시작했다.
사용자 인터페이스는 로그인된 사용자처럼 돌아가고 있었기 때문에, 우리는 윈도 익스플로러를 통해 드라이브에 폴더를 만들었으며(처음 스냅을 구성할 때 테스트를 하기는 했지만 안전해서 나쁠 건 없다), 그런 다음 문서에 에러 메시지를 룩업했다. XO소프트에서 왠싱크가 돌려보낸 약 20개의 에러 메시지를 설명해두긴 했지만, 우리 것은 거기에 없었다.
우리는 이 제품이 24×7 파일 동기화를 수행하며, 애플리케이션이 거의 언제나 윈도 서비스나 리눅스 데몬(Linux Daemon)을 이용해 시스템 재부팅과 다운타임에서 24×7 애플리케이션의 가용성을 보장한다는 사실을 깨달았다. 하지만 왠싱크HA를 지원하기 위해 돌아가는 서비스들이 있는지 여부는 조사해보는 번거로움은 피하기로 했다. 결국 이들이 있다는 게 밝혀졌는데, 로그인 된 이름은 ‘로컬시스템(localSystem)’이었다.
XO소프트의 기술지원팀에서는 서비스(디폴트로)가 ‘로컬시스템’ 사용자로서 돌아간다는 사실을 점잖게 상기시켜 주었다. 우리의 스냅 18000은 액티브 디렉토리에서 인증 정보를 받도록 구성되었기 때문에 일단 복제와 동기화 서비스를 중단시키고 여기에 유효 액티브 디렉토리 서비스 사용자 ID를 주고 재시작을 시키자, 에러 메시지는 가라앉았으며 복제가 진행됐다.
여기서 교훈은 한 조각이 아니라 전체 시스템을 고려하라는 것이다. 우리는 스토리지 업그레이드에 너무 치중했기 때문에, 기본적인 윈도 관리 문제를 놓쳐버렸다. 아무쪼록 여러분은 덫에 걸리지 말기를 바란다.
아직 끝이 아니다. 새로운 스토리지 서버와 작동하려면 테이프 백업 시스템에도 얼마간의 조정작업이 필요했다. 그리고 업그레이드의 파도를 계속 타고 있는 한, 우리는 이 부분도 또한 기꺼이 고치기로 했다.
왠싱크가 스냅으로 NSS를 복제하는 동안, 우리는 백업 변경을 만들고 모든 것을 다시 한번 점검했다. 새로운 스냅을 처리하도록 구성된 백업과 늘어난 디스크 용량에 맞게 셋업된 테이프를 이용해 설정했다. 더 많은, 혹은 더 큰 테이프가 분명히 필요할 것이며, 늘어나는 스토리지 크기로 인해 백업 스케줄이 바뀔 가능성이 많기 때문에 백업은 언제나 점검이 필요한 일이다.
마지막 단계는 NWC의 CIO인 로리 맥비티와 실질적인 대체 상황을 조정하는 일이다. 다운타임은 여러분이 NWC 웹 사이트에 접속할 수 없다는 것과 같은 얘기기 때문에 맥비티에게 NWC 안에서 관심이 있는 집단에게 통보를 해줄 시간이 있는지를 확인해야 했으며, 오전 10시를 택했다. 새 스토리지 시스템의 첫 가동 시간은 금요일 오전 10시로 정해졌는데, 그 이유는 이 시간이 우리 독자들이 잠시 휴식을 취하는 시간이거나, 혹은 NWC를 방문하기에는 너무 바쁜 때이기 때문이다. 우리 경우처럼 짧게 끝날 수도 있겠지만, 조직 내에서 다운타임으로 인해 영향을 받게 될 사람들과의 대체 상황을 잘 헤쳐나가야 할 것이다.
열받는 문제?
스위치를 켤 때 사실 우리는 약간 떨고 있었다. 모든 게 다운되면, 그래서 거의 폐쇄된 적이 없었던 우리 NSS가 다시 복구되지 못한다면 어떻게 될까. 하지만 모든 것은 문제없이 진행되었다. 스냅을 재명명하고 IP 어드레스를 업데이트하는 데는 5분이 걸렸는데, 이것은 대부분 스냅용으로 재부팅이 되는 시간이었다. 서버가 다시 가동이 되자 모든 접속이 복구됐다.
스냅 서버는 크기가 더 작아서 전력도 적게 사용하리라 생각했지만, 막상 그 양이 너무나 적어 즐거운 비명이 나올 정도였다. 우리 스토리지와 NWC 대부분을 담고 있는 APC(American Power Conversion) 랙에는 거의 일년 내내 돌아가는(92%) 내장 UPS가 있지만 NSS NAS를 폐쇄하고, 스냅을 켜자 전력 소모량은 74%로 떨어졌다. 이는 아마 온도 제어에서도 또한 도움이 될 것이다.
오래된 NSS 드라이브 어레이는 많은 열을 발산하며, 랩에서 돌리는 기계가 많아서 HVAC를 과열시키기 때문에, 뜨거운 날에는 기계를 식히기 위해 중요하지 않은 것들은 꺼둬야만 한다. NSS가 27U를 차지하는 데 반해 새 스토리지 서버는 5U를 차지하기 때문에 당연히 새 시스템은 더 시원한 곳에서 돌아가야 한다.
스토리지 교체 방법
1. 필요를 충족시키는 스토리지를 물색해 보라. 성장에 대비하려면 필요한 디스크 용량에 적어도 20%를 추가해야 한다.
2. 스토리지에 액세스하는 애플리케이션에서 변경돼야 할 것들을 결정하거나, 혹은 인 플레이스(in-place) 교체로 결정하라. 비즈니스 애플리케이션에서부터 백업에 이르기까지, 공간을 활용하는 각각의 애플리케이션을 조사하라.
3. 새 스토리지를 셋업하라. 예전 시스템의 자유 공간에서 돌아가던 볼륨에 추가 공간을 구성해야 한다.
4. 새로운 스토리지로 복제 혹은 복사를 하라. 몇 기가바이트 이상이 되거나, 혹은 데이터가 계속 바뀌는 것이라면 복제와 동기화 시스템을 사용하라.
5. 늘어난 디스크 용량을 처리하도록 백업 시스템을 구성하라. 최소한 충분한 테이프가 있는지, 그리고 추가된 볼륨이 백업 시스템에 구성이 되었는지는 확인해야 한다.
6. 몇 시간 뒤에 새 스토리지를 테스트해보라. 가장 바람직하지 못한 상황은 테스트 없이 스위치를 켜서 스토리지가 없다는 게 확인되는 순간이다.
7. 사용자들과의 최종 업그레이드 날짜를 염두에 두고 계획하라. 가능한 한 많은 사람들에게서 검토를 받으라. 단 한 명의 비즈니스 매니저나 시스템 관리자가 “잘 모르겠는데, 돈과 생산성에 영향을 미치는 것 같다”는 말에 의존하는 위험은 피해야 한다.
8. 스위치를 켠 다음 일어나는 모든 사소한 문제들을 수정할 만반의 준비를 하라. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
