블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


장애 대응 단계별 하드웨어 설계 방안

클라우드를 구축하는데 비용상의 문제점은 SAN을 구축하는데 소요되는 비용이다. SAN Controller Switch에 많은 비용이 소요되는데, 서버별 사용 시나리오별로 SAN 사용 여부를 판단함으로써 전체 하드웨어 구축 비용을 절약할 수 있다.


소프트웨어를 이용한 장애 대응

Tuxedo와 같은 TP Monitor Tomcat과 같은 Web Application Server 등은 소프트웨어 자체적으로 Cluster 구축을 통해서 Fail Over를 지원하거나 장애가 났을 때 일시적으로 Transaction이 중단되는 것을 허용하는 경우가 많다. 이런 경우에는 SAN을 구성하지 않고 Server에 직접 연결된 DAS를 이용해서 서비스를 제공한다.

권장 시나리오 : Application Server VM, Oracle RAC를 지원하는 DB 시나리오

Live Migration을 이용한 서버 장애 대응


하드웨어 장애가 났을 때에도 무 정지 상태로 Migration이 가능하다. VM 이미지를 저장하기 위해서 SAN이 필요하다. 이 경우에는 소프트웨어가 제공하는 Fail Over Mechanism을 사용하지 않는다. DISK에 대한 FailOver RAID 구성을 통해서 지원을 하지만, SAN Controller 장애시에는 전사 장애로 발전한다.

참고 : Linux VM의 경우 Hyper-V에서 Live Migration 지원이 불가능하다.

권장 시나리오 : MS SQL

SAN Cluster 구축을 통한 장애 대응


바로 위의 시나리오의 SAN Controller 장애에 대응하기 위한 아키텍쳐로 SAN Controller를 이중화 하고, 앞단에 SAN Switch를 넣어서 SAN Controller에 대해서 장애 대응을 한다. 모든 서버 하드웨어 장애 시나리오에 대해서 대응이 가능하다.

권장 시나리오 : 무정지 시스템, 무정지 MS SQL

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요