|
금년목표74
|
2004-03-16 13:03:50, 조회 : 1,450, 추천 : 210 |
작성자 : IBM 박재관 님 (2004-03-12 10:40 PM)
안녕하세요.
요즘은 ESS 관련하여 지원할 일이 많아 진 것 같습니다. 그래서.....
아시는 분들은 다 아시겠지만 모르시는 분들을 위해 command 를 공유할까 합니다.
ESS 는 주로 여러 channel 을 통해 서버와 연결이 됩니다. 그러다 보니 하나의 LUN(Logical Unit)이 서버에서는 Path 만큼 많이 보이게 되죠. 그때문에 SDD (Subsystem Device Driver) 를 설치하여 vpath 라는 놈으로 관리를 하게 되죠. 이놈이 dpo (data path optimizer) 역할을 하여 load balancing 을 하게 됩니다.
그렇다면 먼저 vpath 와 hdisk 간의 mapping 정보를 확인 해야 겠죠?
이 때 사용되는 command 는 lsvpcfg 이며, 결과는 아래와 같은 형태로 나오게 됩니다.
vpath0 (Avail pv notesvg) 40016395 = hdisk22 (Avail ) hdisk26 (Avail )
vpath1 (Avail pv notesvg) 10016395 = hdisk23 (Avail ) hdisk27 (Avail )
vpath2 (Avail pv notesvg) 20516395 = hdisk24 (Avail ) hdisk28 (Avail )
vpath3 (Avail pv notesvg) 30216395 = hdisk25 (Avail ) hdisk29 (Avail )
이때 = 앞에 serial 같은 숫자가 나오는게 그놈은 LUN ID(3자리) + ESS Serial(5자리) 의 조합입니다.
그런데 ESS 에 연결된 서버를 reboot 을 하다보면, vpath 에 PVID 와 VG_name 이 올라오지 않고, hdisk 에 올라오는 경우가 자주 있습니다. 그럴때는 다음과 같은 command 를 사용하시면 됩니다.
# dpovgfix vg_name or # hd2vp vg_name
이 두놈의 차이는 별루 없습니다. 단지 hd2vp 는 PVID 가 hdisk에만 존재할때 사용하는 것이며, dpovgfix 는 PVID 가 hdisk 와 vpath 에 산재되어 존재할때 주로 사용하는 것이라고 들은 적이 있습니다. 물론 dpovgfix 는 PVID 가 hdisk 에만 존재할때도 사용가능 합니다. 당연히 dpovgfix 라는 command 를 많이 사용합니다.
그렇다면 dpovgfix 나 hd2vp 를 하면 문제가 쉽게 해결이 될까요?
될 수도 안될 수도 있습니다. 안된다면 주로 vpath 정보 에 문제가 있어서입니다. (경험상)
그럴땐 다시 lsvpcfg 를 사용하여 정보가 맞는지 검사를 해야합니다.
예를 들어 위에서 vpath0 는 hdisk22 와 hdisk26 과 mapping 이 되어야 하나, hdisk22 로만 mapping (1:1) 로 되어 있다면 vpath 정보를 수정해야 합니다. 수정하는 방법은 위와 같은 예라면
# rmdev -dl vpath0
# cfgmgr or # smitty dev --> datapath devices --> configure datapath devices (?)
smitty menu 는 제가 정확히 기억은 못하지만 비슷한 의미의 메뉴가 있습니다. 이와 같은 방식으로 다시 vpath 를 만들어 주시고 dpovgfix 를 사용하시면 대부분 해결이 됩니다. (아직 해결안된 경험이 없음)
물론 이 이외에도,
# datapath query adapter/device (주로 load balancing 이 잘되고 있는지 확인할때...)
# vp2hd vg_name ( Online 중에 Path 를 추가하고자 할때 많이 사용하나... 거의 사용할 일이 없습니다.)
등등이 있습니다.
그리고 Storage 관련하여, PVID 와 VGNAME 이 hdisk, vpath 어느곳에도 올라오지 않는 수도 있습니다. (none none 으로 보일때) ESS 뿐만 아니라 Hitach, EMC Disk 에서도 말이죠.
그런경우는 아마 대부분 Shared disk 로써 다른 서버에서 이미 사용중인 경우일 것입니다. (당연한 결과)
그럴때는 무리할수도 있지만 가능하면 Down Time 을 잡고 작업을 하시는게 좋습니다.
Admin 이 무리를 해서라도 하자고 한다면 먼저 admin 에게 정중히 사안의 중요성을 말하시고... (-.-;;)
해당 volume 을 사용중인 서버에서 varyonvg -b -u vg_name 으로 VG 을 풀어놓고,
복구하려는 서버를 rebooting 또는 rmdev 로 disk 다 날리고 새로 cfgmgr 을 돌리시면
Disk에 PVID 와 VG_name 이 보일것이고 그 정보가 올바르다면 사용중인 서버에서 varyonvg vg_name 을 다시해주면 되겠죠?
이때 VG 의 속성중 autovaryon 은 no 여야 겠죠... (autovaryon 이 yes 라면... ???)
(항상 HACMP 되어 있는 곳에서는 importvg 이후에 # chvg -an -Qn vg_name 을 생활화 합시당..)
위와 같은 방법이 있긴 하지만 어쩔수 없는 상황이 아니라면 하지 않으시는게 좋겠죠?
그리고 또 만약 concurrent access 일 경우는 또 다른 문제니깐.... 주의하셔야 하구요.
이상이 제가 알고있는 간단한 내용입니다.
잘못된 부분을 찾으시면, 정정해 주시길 부탁드립니다.
감사합니다. |
|
|
