야간작업중이다.
데이타 마이그레이션 및 재구축인데...
RAC 구성과 GFS, IBM iseries 로 되어있는 WAS 시스템이 대략적인 구성이다.
뭐 별거 있나. 그냥 RAC 구성되있던 서버 쭉 밀고 RHEL 4.8 최신버젼으로 설치 한담에,
스토리지 할당 받고 ORACLE 설치하면 되는거지...
GFS 구성도 서버 RHEL5.4 로 쭉 밀고 스토리지 할당 받은담에, GFS 설정하면 되는거지..
그런데 이런... IBM iseries 가 문제가 생겼다.
스토리지를 해제시켜놓고 다시 구성하는 상황이였는데, 행이 걸려있다...
설마설마 했는데, iSeries 를 함부로 다룰 순 없었기에, 게다가 부팅의 방법도 모르기에...
쥐쥐였다......
i 엔지니어가 새벽 두시에 들어와서는 두개 디스크가 미싱 ( os 영역 ) 이 나서 재구성해야 할 수도 있겠단다.
전체 재구성...............쥐쥐다...
이때 역시나 바로 드는 생각은 가상화 였다.
VMware 로 구성하여 DR 을 이루었더라면, 아니 하다못해 FT, HA 라도 구성을 해놨더라면
지금과 같은 상황에서 재해복구는 문제가 되지 않았을 것이다.
iSeries 같은 것에서 가상화로 자원을 나눠 할당했다는 것은, 장애가 발생했을때 큰 문제가 된다.
일단 방금설명했던 대로, iSeries 등 특별한 장비를 다룰 수있는 엔지니어가 필요하다는 것.
그리고 재난 발생시 대체할만한 비슷한 성능의 대체장비의 준비와, 백업,복구 과정이 어렵다는 것.
이래서 VMware 등의 x86 가상화솔루션이 필요한 것이다.
iSeries 에 있는 7개 정도 되는 VM 을 vSphere 4 로 구현 한다고 했을 경우,
IBM x3850_m2 시리즈 두대를 준비 ( 2CPUs nehalem, RAM 16G ) 7개 VM 을
각 서버에 나누거나 이중화를 시켜 ( 양 서버에 각각 7개 동일 VM 이 구동 - Fault Torrence )
충분히 여유롭게 가동이 가능하고, 지금과 같은 스토리지 재구성으로 인한 디스크 missing 현상 같이
디바이스 매칭이 안되서 알아 올 수 없을때, 혹은 메인 OS 의 문제가 발생 했을때,
한쪽의 서버에서 대체 구동이 가능 할 뿐만 아니라, 나눠서 운영중이였다면 한쪽의 서버로 7개의 VM 을
집약시켜 이상없이 구동이 가능하다는 점이였다.
게다가 장비 두대가 모두 문제가 생겼다 하여도 x86 기반이므로 다른 서버들보다 훨씬 빨리
하드웨어 수급이 이루어 질 수 있고, 백업 및 복원도 단지 몇분만으로 동일한 환경이 생성되어
서비스 될 수 있다는 것이다. - 심지어 vSphere 4 서버 솔루션 문제라면 간단히 재설치해주면 된다 !!!!
어쨋든 지금 나와서 작업하고 있는 이곳은 아직도 중국에 가있는 iSeries 엔지니어가 오기를 기다리고 있고,
와서 재구축을 한다고 해도 이틀의 시간을 소요 해야 할 것이다.
확실히 재난복구 상황에 대한 가장 효율적인 해결책은 가상화 시스템이 아닐까 생각된다.
너무 졸려서 두서없이 써버렸는데, 일단 잠좀 간단하게 자고 작업 마친 뒤 정리해야 할듯 하다.
데이타 마이그레이션 및 재구축인데...
RAC 구성과 GFS, IBM iseries 로 되어있는 WAS 시스템이 대략적인 구성이다.
뭐 별거 있나. 그냥 RAC 구성되있던 서버 쭉 밀고 RHEL 4.8 최신버젼으로 설치 한담에,
스토리지 할당 받고 ORACLE 설치하면 되는거지...
GFS 구성도 서버 RHEL5.4 로 쭉 밀고 스토리지 할당 받은담에, GFS 설정하면 되는거지..
그런데 이런... IBM iseries 가 문제가 생겼다.
스토리지를 해제시켜놓고 다시 구성하는 상황이였는데, 행이 걸려있다...
설마설마 했는데, iSeries 를 함부로 다룰 순 없었기에, 게다가 부팅의 방법도 모르기에...
쥐쥐였다......
i 엔지니어가 새벽 두시에 들어와서는 두개 디스크가 미싱 ( os 영역 ) 이 나서 재구성해야 할 수도 있겠단다.
전체 재구성...............쥐쥐다...
이때 역시나 바로 드는 생각은 가상화 였다.
VMware 로 구성하여 DR 을 이루었더라면, 아니 하다못해 FT, HA 라도 구성을 해놨더라면
지금과 같은 상황에서 재해복구는 문제가 되지 않았을 것이다.
iSeries 같은 것에서 가상화로 자원을 나눠 할당했다는 것은, 장애가 발생했을때 큰 문제가 된다.
일단 방금설명했던 대로, iSeries 등 특별한 장비를 다룰 수있는 엔지니어가 필요하다는 것.
그리고 재난 발생시 대체할만한 비슷한 성능의 대체장비의 준비와, 백업,복구 과정이 어렵다는 것.
이래서 VMware 등의 x86 가상화솔루션이 필요한 것이다.
iSeries 에 있는 7개 정도 되는 VM 을 vSphere 4 로 구현 한다고 했을 경우,
IBM x3850_m2 시리즈 두대를 준비 ( 2CPUs nehalem, RAM 16G ) 7개 VM 을
각 서버에 나누거나 이중화를 시켜 ( 양 서버에 각각 7개 동일 VM 이 구동 - Fault Torrence )
충분히 여유롭게 가동이 가능하고, 지금과 같은 스토리지 재구성으로 인한 디스크 missing 현상 같이
디바이스 매칭이 안되서 알아 올 수 없을때, 혹은 메인 OS 의 문제가 발생 했을때,
한쪽의 서버에서 대체 구동이 가능 할 뿐만 아니라, 나눠서 운영중이였다면 한쪽의 서버로 7개의 VM 을
집약시켜 이상없이 구동이 가능하다는 점이였다.
게다가 장비 두대가 모두 문제가 생겼다 하여도 x86 기반이므로 다른 서버들보다 훨씬 빨리
하드웨어 수급이 이루어 질 수 있고, 백업 및 복원도 단지 몇분만으로 동일한 환경이 생성되어
서비스 될 수 있다는 것이다. - 심지어 vSphere 4 서버 솔루션 문제라면 간단히 재설치해주면 된다 !!!!
어쨋든 지금 나와서 작업하고 있는 이곳은 아직도 중국에 가있는 iSeries 엔지니어가 오기를 기다리고 있고,
와서 재구축을 한다고 해도 이틀의 시간을 소요 해야 할 것이다.
확실히 재난복구 상황에 대한 가장 효율적인 해결책은 가상화 시스템이 아닐까 생각된다.
너무 졸려서 두서없이 써버렸는데, 일단 잠좀 간단하게 자고 작업 마친 뒤 정리해야 할듯 하다.
'Skills > 가상화(Hypervisors)' 카테고리의 다른 글
RHEV 이야기 두번째 (1) | 2010.01.12 |
---|---|
RHEV (RedHat Enterprise Virtualization ) (0) | 2009.12.14 |
Xen P2V 관련.. (0) | 2009.09.09 |
kvm 에서 브릿지 모드로 네트워킹을 구성할때 확인. (0) | 2009.08.12 |
레드햇 Virtualization 메일링중 그냥 흥미로운 팁.. (0) | 2009.08.08 |