소개

IBM® AIX ® 시스템 관리나 SAN 관리를 어느 정도 수행해 왔으면 아마도 디스크 오류, 파일 시스템 문제점 및 LVM(Logical Volume Manager) 장애에 익숙할 것이다. 이러한 상황이 발생하면 어떻게 해야 할까? 또는, 이러한 상황이 발행하지 않도록 하려면 우선 어떻게 해야 할까?

이 기사에서는 디스크의 성능이 저하되어 여러 가지 장애가 발생하는 상황을 살펴본다. 우선, 디스크 오류와 이러한 오류의 범주를 간략히 살펴본다. 그런 다음, 제대로 설계된 중복 환경을 구축하는 방법과 하드웨어 개념을 알아본다. 그 다음에는 위험한 상황에서 필요한 솔루션을 검토한다.

위로

디스크 오류 범주화

필자는 두 가지 기본적인 영역(영향 및 기간)을 사용하여 AIX 시스템의 디스크 오류를 범주화한다. 영향은 디스크 오류가 발생할 가능성과 디스크 오류가 서버에 어떻게 영향을 미치는지를 측정한 것이다. 다시 말해서, "디스크 오류의 심각성"을 측정한 것이다. 기간은 디스크 오류가 지속되는 기간과 복구 시간, 즉 "디스크 오류가 발생하는 기간"을 측정한 것이다.

영향은 다음과 같은 네 가지 기본 레벨로 나눌 수 있다.

• 가용성 손실 - 스토리지 자원이 오프라인 상태가 되거나 관리 서버와 연결이 끊길 때 발생하는 가용성의 손실이다. 디스크에 있는 데이터는 손실되지 않지만, 디스크에 액세스할 수는 없다. 파일 시스템이 마운트되지 않거나 광 채널 어댑터가 연결이 끊어진 경우가 이에 해당된다.
• 데이터 손실 - 논리적 문제점 또는 물리적 문제점으로 인해 디스크에서 데이터를 읽거나 디스크에 데이터를 쓸 수 없다. LVM 쓰기 오류가 이에 해당된다.
• 다중 디스크 전체에서 데이터 손실 - 이 경우에는 데이터 손실이 단지 디스크 하나가 아니라 여러 개의 디스크에서 발생한다. 일반적으로 이러한 상황은 전체 디스크에서 논리적 볼륨이 제거되어 디스크가 실패할 때 발생한다.
• 다중 서버 전체에서 데이터 손실 - SAN 기술이 널리 보급되면서 다중 서버에서 데이터 손실이 발생하는 시점에서 단일 디스크 하드웨어가 손상될 가능성이 있다.

마찬가지로 기간도 네 가지 기본 레벨로 나눌 수 있다.

• 일시적 - 이러한 디스크 오류 유형은 진정한 위협이 되지 않는 일회성 오류이며 거의 발생하지 않는다. 이 오류는 서버의 errpt 기능에서 표시되고 나면 사라진다. 잘못된 블록 재할당이 이에 해당한다.
• 간헐적 - 간헐적 오류는 불규칙하게 나타나며 하드 디스크가 일련의 쓰기 오류(드라이브에 장애가 발생할 수 있음을 나타냄)를 로그할 때와 같이, 초기 문제점을 암시할 수 있다.
• 정기적 - 마치 cron 작업으로 스케줄링한 것처럼 문제점이 매주, 매일, 매시간 또는 시시각각으로 발생하면 서버에 일련의 위험이 존재할 수 있으며 좋지 않은 영향이 확산될 수 있다.
• 영구적 - 이 오류 유형이 발생하는 경우에는 복원할 수 있는 손쉽고 유연한 방법이 없다. 하드웨어를 바꾸는 것 외에는 이러한 상황을 복구할 수 있는 방법은 없다.

표에서 이러한 두 가지 메트릭을 교차 참조하면, 디스크 오류의 심각성과 이러한 오류가 서버에 미치는 영향을 명확하게 확인할 수 있다. 그림 1에는 이러한 테이블의 예가 표시되어 있다.

그림 1에는 행과 열이 각각 4개씩 있는 표가 표시되어 있다. 열은 문제점이 발생한 기간을 나타내며 왼쪽에서 오른쪽으로 갈수록 시간이 증가한다. 행은 문제점의 영향을 나타내며 아래에서 위로 갈수록 심각성이 증가한다. 이 표에 있는 셀은 스펙트럼에 따라 색상으로 구분되어 있으며, 문제점 정도가 낮다는 것(가용성의 일시적 손실)을 나타내는 왼쪽 하단 모서리의 파란색과 녹색에서, 문제점 정도가 더 높은 것(다중 서버 전체에서 영구적 데이터 손실)을 나타내는 오른쪽 상단 모서리의 주황색과 빨간색으로 이동한다.

경험상, 녹색 영역을 벗어나면 심각한 문제점이 있는 것이며 생산성이나 비즈니스에 손상을 입을 수 있다. 서버가 노란색 영역으로 들어가는 상황을 단지 몇 번만 보았을 뿐이지만, 이러한 상황은 매우 심각한 결과를 초래했다.

위로

예방 수단

중요한 것은 디스크에 장애가 발생할 것인지의 여부가 아니라 디스크에 장애가 발생하는 시점이다. 무한정 작동이 보장되는 디스크는 없다. 우수한 시스템 관리자의 목표는 하드웨어 평균 장애 간격의 희생자가 되지 않으면서 디스크 장애의 위험을 완화할 수 있는 방법을 찾는 데 있다.

AIX나 SAN 관리자의 세 가지 기본적인 목표는 가용성, 성능 및 중복을 최대화하는 데 있다. 독자는 요청 시 데이터에 액세스할 수 있고 모든 데이터를 저장할 수 있을 정도로 충분한 디스크 공간이 있는 스토리지 환경을 원할 것이다. 디스크는 I/O 대기로 인해 애플리케이션이 지연되지 않을 정도로 성능이 우수해야 한다. 그리고 디스크는 자원의 장애로 인해 서버의 작동 기능이 손상되지 않도록 중복되어 있어야 한다.

일반적으로 각 목표 간에는 상충관계가 있어서 각각의 목표를 최대화하려면 다른 영역을 하나 이상 희생해야 한다. 디스크 자원은 속도를 위해 최적화되고 사용 가능한 마지막 바이트를 모두 사용하기 때문에 가용성과 성능을 최대화하는 스토리지 환경에서는 일반적으로 중복이 많이 되어 있지 않다. 가용성과 중복에 초점을 맞추고 있는 스토리지 환경에서는 장기간의 안정성이 목표이기 때문에 읽기와 쓰기 속도가 더 늦다. 그리고 성능과 중복에 비중을 두고 있는 솔루션은 I/O 성능을 강화하고 읽기와 쓰기 속도를 배가하기 위해 더 많은 공간을 필요로 하기 때문에 사용 가능한 공간의 관점에서는 가용성이 감소한다.

AIX에는 예방 수단을 시행할 수 있는 더 실용적인 방법이 있다. 모든 관리자가 알아야 하는 몇 가지 일반적인 개념은 다음과 같다.

• 단일 장애점을 회피한다. 단일 자원의 손상으로 해당 환경에 문제가 발생하게 되는 환경을 구축하지 않는다. 이러한 아키텍처는 단일 하드 디스크, 단일 광 채널 어댑터 또는 단일 전원(임의의 장비용)으로 구성되어 있다. 필연적으로 이러한 자원은 가장 나쁜 시기에 문제가 발생한다.
• RAID 기술은 자원을 최대화할 수 있는 우수한 방법이다. 여러 해 전에는 저렴한 스토리지 디바이스를 모아서 RAID 기술을 사용하여 대규모로 그룹화하는 방법을 엔지니어들이 개발했었다. AIX에는 다양한 레벨의 RAID 기술이 추가 비용 없이 통합되어 있으며, 이러한 기술은 스트라이핑(RAID 0) 및 미러링(RAID 1)과 같은 소프트웨어 레벨에서 사용할 수 있다. 사용 중인 디스크 서브시스템의 유형에 따라, 패리티가 있는 스트라이핑(RAID 5), 스트라이핑 미러(RAID 0 + 1) 또는 미러링된 스트라이프(RAID 1 + 0/RAID 10)를 사용할 수도 있다.
• 효과적인 LVM 전략을 사용하여 데이터를 분리한다. 관리자들이 저지르는 최악의 실수는 서버의 모든 자원(운영 체제, 써드파티 애플리케이션, 페이징 공간 및 애플리케이션 데이터)을 하나의 볼륨 그룹에 배치하는 것이다. 이렇게 하면 성능 저하, 대량 시스템 백업, 관리 효율성 저해 및 장애 가능성 증가와 같은 모든 종류의 나쁜 결과가 발생할 수 있다. 서버의 각 패싯을 평가하고 분리하여 고유한 볼륨 그룹과 스토리지 유형에 삽입해야 한다. 예를 들면, 대용량 데이터베이스 서버는 미러링된 rootvg 디스크, 애플리케이션 스토리지 및 페이징 공간용 SAN 스토리지, 로깅 및 고성능 I/O 트랜잭션을 위한 일부 솔리드 스테이트 디스크가 내부에 있도록 설계된다.

AIX 서버에서 사용되는 다양한 유형의 스토리지 전략을 살펴보도록 하자.

내부 하드 드라이브

AIX의 가장 일반적인 유형의 스토리지인 내부 하드 드라이브는 일반적으로, 소규모 풋프린트가 있는 서버와 루트 볼륨 그룹 디스크용으로 사용된다. 내부 하드 드라이브를 사용할 경우에는 우선, 언제나 볼륨 그룹당 두 개 이상의 디스크가 있어야 하고 mirrorvg 명령을 사용하여 하드 드라이브를 미러링해야 한다. 서버가 대형 IBM System p® 시스템인 경우에는 다중 드로어 전체에서 디스크를 선택하여 백플레인과 같은 하드웨어에 장애가 발생하는 경우에 중복이 최대화되도록 한다. 또한, 성능을 최적화하려면 lspv –l 및 lspv –p 명령을 사용하여 디스크에 있는 논리적 볼륨의 레이아웃을 시험하여 디스크와 논리적 볼륨의 가장자리에 있는 영역의 I/O 성능이 계속 유지되도록 하는 것이 좋다.

소형 SAN 스토리지

직접 연결형 IBM FAStT 디스크 드로어나 이전의 소형 SAN 기술과 같은 소형 스토리지 서브시스템은 대용량 데이터를 유지하기 위해 내부 디스크 공간보다 더 많은 공간이 필요한 환경에 적합하다. 이러한 환경에는 경로에 단일 장애점이 일부 있을 수 있으므로 환경 구성을 철저하게 관리해야 한다. 예비 디스크(Hot spare disk)가 있는 RAID 5 설정과 같은 적당한 RAID 구성을 이용하여 스토리지를 최적화해야 한다. 여기에는 서버측에서 가용성과 중복을 유지하기 위해 드로어에 액세스할 수 있는 어댑터가 두 개 있어야 한다. 그리고 디스크가 분명하게 서버에 제시되도록 다중 경로 I/O나 서브시스템 디바이스 드라이버 경로 제어 모듈과 같은 적당한 소프트웨어 드라이버를 설치하여 최신 상태로 유지해야 한다.

대형 SAN 스토리지

다수의 서버가 디렉터급 스위치를 통해 IBM System Storage® DS8300 디바이스와 같은 많은 스토리지 디바이스를 액세스하는 대형 SAN 스토리지 환경에는 일반적으로 디스크 자원을 전담해서 관리하는 SAN 관리자가 있다. 그러나 AIX 관점에서 보면 시스템 관리자는 다수의 이중 포트 광 채널 카드를 선택하여 다양한 패브릭과 통신하고 처리량을 개선함으로써 도움을 줄 수 있다. VIO(Virtual Infrastructure Optimization) 기술을 사용 중인 경우, NPIV(N_Port ID Virtualization)를 이용하면 I/O 요구가 낮은 다중 서버가 동일한 어댑터를 통해 통신할 수 있어서 LPAR에 지정되는 슬롯의 수를 줄일 수 있다. SAN 부트 기술은 LPAR에 배우 빠른 빌드 및 부트 시간을 제공하며, 특히 NIM(Network Installation Manager)과 함께 수행되는 경우에는 더욱 그러하다.

위로

복구 단계

디스크 장애의 효과는 일시적인 중단에서부터 완전한 서버 장애에 이르기까지 다양하다. 그러면 장애가 발생하면 어떻게 해야 할까?

첫 번째 단계에서는 가능한 한, errpt를 사용하여 가장 높은 사용 가능 레벨에서 아래쪽으로 이동해 가면서 디스크 자원의 가용성을 확인한다. 계속해서 서버가 실행 중인 경우, df나 mount 명령으로 확인하면 파일 시스템이 여전히 마운트되어 있을까? 그렇지 않은 경우, lsvg나 varyonvg로 이 볼륨 그룹에 액세스할 수 있을까? 아니면 이 볼륨 그룹에서 쿼럼이 손실되었을까? 디스크 자체는 여전히 사용 가능한 상태에 있을까? 아니면 lsdev –Ccdisk에서 디스크가 정의된 상태에 있다고 표시될까? lspath나 pcmpath query adapter와 같은 SAN 스토리지 명령에서 광 채널 디바이스가 오프라인 상태에 있거나 누락되었다고 표시되나? 하드웨어 관리 콘솔을 통해 보았을 때 서버가 단순히 중지되어 비활성 상태에 있는가? 아니면 대형 System p 시스템이나 SAN 서브시스템의 전원이 꺼져있는가? 단순히 한 가지 자원 유형만 액세스 가능하기 때문이라고 생각하지 않는다. 비슷한 모든 자원은 액세스 가능하므로 철저하게 조사한다.

두 번째 단계에서는 가장 낮은 사용 가능 레벨에서 위쪽으로 이동하면서 자원의 무결성을 확인한다. 서버가 성공적으로 부팅했는가? 아니면 시스템이 시작했을 때 552, 554, 556과 같은 숫자가 붙은 LED 메시지와 같은 오류(손상된 파일 시스템, JFS 또는 Object Data Manager[ODM])가 발생했나? 시스템이 실행 중인 경우, cfgmgr 명령을 실행하면 디스크 자원이 사용 가능한 온라인 상태로 돌아오나? varyonvg 명령을 사용하여 볼륨 그룹을 활성화할 수 있나? 파일 시스템이 분명하게 마운트되나? 파일 시스템 내에 있을 것으로 예상되는 데이터나 파일이 누락되는가?

세 번째 단계에서는 사례별로 자원으로 인한 문제점을 해결한다. 필자가 수년 동안 문제점을 해결하기 위해 사용한 팁은 다음과 같다.

• 파일 시스템. 경험상, 스토리지 환경에서 발생할 수 있는 디스크 오류의 가장 일반적인 유형은 파일 시스템이다. 수퍼블록 오염, 단편화 발생, inode 혼란 또는 errpt에서 JFS 오류 반복 현상이 발생하는 데는 많은 시간이 걸리지 않는다. 완전한 파일 시스템에서도 여러 가지 혼란이 생길 수 있다. 그리고 파일 시스템 문제점을 수정하는 데 가장 좋은 전략은 파일 시스템 검사 명령(fsck)을 사용하는 것이다. 이러한 상황에서 필자는 파일 시스템을 마운트 해제한 후, 파일 시스템을 다시 마운트하기 전에 파일 시스템이 오류가 없는 상태로 돌아갈 때까지 파일 시스템을 대상으로 fsck –y를 실행한다. 때로는 볼륨 그룹에 있는 파일 시스템을 모두 마운트 해제하여 철저히 검사하고 잠재적인 문제점이 있는 경우에는 쉘 스크립트에서 작은 루프로 이러한 작업을 수행한다.
• 볼륨 그룹. 문제점이 파일 시스템 영역을 벗어나 볼륨 그룹 레벨로 이동하는 경우가 많다. 때로는 문제점이 ODM 레벨에서 발생하며 이런 경우에는 syncvg나 synclvodm 명령을 사용하여 문제점을 해결할 수 있다. 위급한 상황에서 필자는 varyoffvg를 사용하여 볼륨 그룹을 껐으며, exportvg를 사용하여 이 볼륨 그룹을 내보낸 후, importvg를 사용하여 이 그룹을 다시 가져와서 적절하게 인식되도록 했다. 그러나 필자는 /etc/filesystems 파일을 언제나 백업하고 마운트 순서가 유지되도록 사전에 디스크 포트 VLAN ID(PVID)를 기록해 둔다.
• 실제 볼륨. PVID에 관해 말하자면 디스크가 사라졌다가 나중에 해당 서버에서 다른 PVID로 나타나는 것을 확인한 적이 있다. 이러한 현상이 발생하면 비교하기 위해 어디인가에 디스크 정보를 주기적으로 기록해 두는 것이 좋다. 이러한 현상이 발생하면 필자는 일반적으로 rmdev –dl을 사용하여 서버에서 해당 디스크를 삭제하고 cfgmgr을 사용하여 디스크를 다시 발견한 다음 해당 볼륨 그룹을 내보낸 후 다시 가져온다.
• SAN 연결. VIO 서버에서 NPIV를 사용할 때와 마찬가지로 WWN(Worldwide Number)이 SAN 패브릭 전체의 엔드투엔드에서 통신되지 않는 경우가 있다. 때로는 pcmpath set adapter offline을 실행하여 광 채널 어댑터를 비활성화하거나 수동으로 WWN을 정의하거나 검사한 후, 이 어댑터를 다시 켠다. 또한, 물리적인 문제점이 존재하는지 확인하기 위해 케이블을 추적하고 반대 쪽 끝에서 빛을 확인하는 극단적 수단을 취하기도 했다.
• 부팅 문제점. 디스크에 장애가 발생하고 나서 서버가 부팅되지 않는 이유를 판별하려고 시도할 경우, 필자는 가장 먼저 서버에서 루트 볼륨 그룹을 제외한 모든 디스크의 연결을 끊거나 맵핑을 제거한다. SMS(Software Management System)가 하나 또는 두 개의 rootvg 디스크를 찾기 위해 수백 개의 디스크를 조사해야 하는 경우에는 부팅하는 데 상당히 많은 시간이 걸린다. 필자는 NIM 서버에서 유지보수 모드로 시스템을 부팅하여 파일 시스템을 선별하여 수정하고, bosboot 명령을 사용하여 부트 논리적 볼륨을 다시 작성하거나 루트 볼륨 그룹에 액세스하여 /etc/filesystems와 같은 구성 파일을 수정한다. 또한, 서버가 시작되고 나면 문제가 있는 파일 시스템은 일반적으로 이 파일 시스템 주변에 있는 다른 파일 시스템이 제대로 마운트되는 동안 닫힌 상태에 있는 파일 시스템이 된다.
• 복구. 마지막으로 무엇인가가 손상되어 분명히 수정할 필요가 있는 경우에는 교환할 부품이 원래의 장비와 최대한 가까이 있어야 한다. 이런식으로 시스템이 다시 작동하는 데 걸리는 시간을 지연시킬 수 있는, 소프트웨어 드라이버나 파일 시스템 크기와 같은 것을 조작해야 할 필요성을 최소화한다. 필자는 데이터가 손실되는 최악의 상황에서 복구할 수 없는 경우에는 mksysb 이미지와 IBM Tivoli® Storage Manager와 같은 제품을 사용하여 완전한 시스템을 백업할 것을 언제나 권장한다.

위로

결론

디스크의 성능이 저하되는 문제점이 발생하는 기간을 줄이고 손상을 피할 수 있는 가장 좋은 방법은 문제점이 발생할 때 반응적으로 대처하기보다는 AIX 환경의 가용성, 성능 및 중복을 최대화하여 처음부터 오류가 발생하지 않도록 하는 것이다. 그러나 피할 수 없는 장애로 인해 오류가 발생하는 경우에는 접근성과 무결성을 검증하고 점진적인 계획을 수립하여 이러한 오류를 수정하고 서버가 한 번 더 완전히 실행되도록 한다.

참고자료

교육

• LVM에 관한 자세한 정보는 AIX Logical Volume Manager from A to Z: Introduction and Concepts를 확인하자.
  
  
• LVM의 문제점 해결에 관한 자세한 정보는 AIX Logical Volume Manager from A to Z: Troubleshooting and Commands 및 IBM eServer Certification Study Guide AIX 5L Problem Determination Tools and Techniques를 참조하자.
  
  
• AIX Logical Volume Manager를 사용하여 SAN 스토리지 마이그레이션을 수행하는 방법(Chris Gibson, developerWorks, 2010년 7월)을 배우자.
  
  
• IBM Redbook Problem Solving and Troubleshooting in AIX 5L을 확인하자.
  
  
• AIX와 UNIX developerWorks 영역: AIX와 UNIX 영역에서는 AIX 시스템 관리와 UNIX 스킬 확장의 모든 측면과 관련된 풍부한 정보를 제공한다.
  
  
• AIX와 UNIX 입문 AIX와 UNIX 입문 페이지에서 자세한 정보를 볼 수 있다.
  
  

제품 및 기술

• 무료로 IBM 소프트웨어를 체험해보자. 평가판을 다운로드하고 온라인 평가판에 로그인한 후 샌드박스 환경에서 제품을 사용하거나 클라우드를 통해 제품에 액세스해 보자. 100개 이상의 IBM 제품 체험판에서 선택하자.
  
  

토론

• Twitter의 developerWorks 페이지를 팔로우하자.
  
  
• developerWorks 블로그: 블로그를 읽어 보고 developerWorks community에 참여하자.
  
  
• AIX 및 UNIX® 포럼에 참여하자.
  • AIX Forum
  • AIX Forum for developers
  • Cluster Systems Management
  • Performance Tools Forum
  • PowerVM Forum
  • 기타 AIX and UNIX Forums
  
  

필자소개

아티클 순위

의견

위로

목차

• 소개
• 디스크 오류 범주화
• 예방 수단
• 복구 단계
• 결론
• 참고자료
• 필자소개
• 의견