시스템 이중화 HA클러스터 구성 기본 지식에 참고 할만한 좋은 글이 있어 구글 번역 옮깁니다.
1화만 옮겨드리니(※) 혹시 HA클러스터링(시스템 이중화 구성 클러스터)에 관심 있으신분은 한번 살펴 보는것도 좋을 것 같습니다.
※예상보다 반응이 좋아서, 최대한 옮겨보고자 합니다.
HA 클러스터 입문 - 제 1 회 서버가 다운되는 것? ~
https://jpn.nec.com/clusterpro/blog/20170403.html
HA 클러스터 입문 - 제 2 회 모든 것을 중복? ~
https://jpn.nec.com/clusterpro/blog/20170417.html
HA 클러스터 입문 ~ 제 3 회 이상의 서버에서 클러스터링? ~
https://jpn.nec.com/clusterpro/blog/20170515.html
HA 클러스터 입문 - 제 4 회 장애에 의한 업무의 인계 란? ~
https://jpn.nec.com/clusterpro/blog/20170601.html
https://kr.nec.com/ko_KR/file/NEC_EXPRESSCLUSTER.pdf
NEC Express5800 Fault Tolerant Servers
https://kr.nec.com/ko_KR/file/NEC_FT_Server.pdf
HA 클러스터 입문 - 제 1회 서버가 다운 된다는 것? ~
시작하기
"design for failure"라는 생각을 알고 있습니까? 장애는 반드시 발생한다는 전제에 입각 한 시스템 설계의 생각입니다. 오류가 반드시 발생하는 것은 무엇을 의미할까요? 이것은 시스템을 구성하는 모든 것을 "언젠가는 고장 것"으로 취급하는 것입니다. 이야기가 조금 추상적이므로 구체적 예로 생각해 봅시다.
1 대의 서버에서 Web 사이트를 운영하는 경우 어떤 부분의 고장이 상정 할 수 있을까요? "서버가 다운됐다"고해도 그 원인이되는 고장 부위는 다양합니다. 우선 하드웨어의 관점에서 살펴 보자.
하드웨어
서버를 구성하는 요소로서 CPU나 메모리, 디스크뿐만 아니라 마더 보드와 전원 공급 장치, 냉각 팬이 포함됩니다. 또한 LAN 및 FC(Fibre Channel), RAID(*) 확장 보드를 추가하는 경우에 그것도 서버 구성 요소입니다. 고장 빈도(내구성)에 차이는 있지만 "design for failure"의 관점으로는 이들 전부는 "언젠가는 고장 나는 것"으로 처리합니다.
*RAID는 여러 개의 디스크를 조합하여 복원력과 성능 향상 기술이지만, RAID 컨트롤러 자체의 고장 발생을 상정 해야 합니다.
소프트웨어
다음 소프트웨어 측면에서는 어떨까요. 우선 OS (Operating System) 자체의 오류입니다. OS의 버그(프로그램 문제)와 보안 취약점으로 인한 장애 등이 발생할 수 있습니다. 또한 Web 사이트의 기능을 제공하는 어플리케이션도 버그와 보안 취약점 등 유사한 장애는있을 수 있습니다. 다른 관점으로 Web 사이트에 급격한 트래픽 증가에 따른 높은 부하 상태의 장애도 가정 할 필요가 있습니다.
네트워크
그런데 하나의 서버에 하드웨어, 소프트웨어 각각의 관점에서 어떤 문제가 일어날 수 있는지살펴 봤습니다만, 이것으로 끝이 아닙니다. 이번 예시에서는 "Web 사이트를 운용"하고 있기 때문에, Web 사이트가 실행중인 서버와 Web 사이트에 액세스 해 오는 사용자를 연결하는 네트워크 주변에 대한 시야를 넓힐 필요가 있습니다.
우선 서버와 연결된 네트워크 장치와 케이블의 장애입니다. 케이블의 장애는 종종 케이블의 단선을 의미합니다. 또한 고성능 네트워크 장비쯤 되면 전용 OS를 실행하기 때문에 OS의 버그와 보안 취약점으로 인한 장애도 가미 해야 합니다. "Web 사이트"로 상정하고 있기 때문에 이번에는 인터넷 회선을 제공하는 회선 회사 측의 네트워크 장애도 상정 해 둘 필요가 있습니다.
정리
어떻습니까. 1대의 서버에서 Web 사이트를 운영하는 단순한 구성에도 이만큼의 많은 장애를 상정하고 시스템을 설계 해야 합니다. 그리고 그 생각을 나타낸 것이 "design for failure"이며, 시스템을 설계 할 때의 원칙이라고도 합니다. 언제 일어날 지 모르는 장애에 불안 해 하는 것이 아니라 반드시 장애가 발생 한다고 가정 하여 대비할 수 있도록 신뢰성있는 시스템을 설계 해야 겠네요.
게다가... 사실 서버를 설치하고 있는 건물 자체의 장애 대규모 재해에 의한 정전이나 붕괴 등도 상정 할 필요가 있는데, 그것은 다음 기회에..
HA 클러스터 입문 - 제 2 회 모든 것을 중복? ~
HA 클러스터 입문 ~ 3 회 이상의 서버에서 클러스터링? ~
HA 클러스터 입문 - 제 4 회 장애에 의한 업무의 인계 란? ~
본문 내용이 처음 작성된 내용과 다를 수 있습니다.
21개의 댓글이 있습니다.
감사합니다
구글 번역이 조금 어색하긴하지만...
내용이 짤막짤막해서 읽는데 부담은 없네요~
지난 HA 관련 글 : https://www.sharedit.co.kr/posts/53
이중화 하고 다중화 하면서 그 1번의 리스크를 커버해야 한다고 생각하면 설득하기 너무 어렵습니다. ㅠㅠ
그 한번의 장애시에 얼마의 비용손실이 될지 예측도 해야 하고 ㅠㅠ
실제로는 전환조차안되도록 하고 납품한 경우도 봤구요;;;
이런걸 컨설팅 받으시지 라고 말하고 싶을때가 많습니다.ㅜ
좋은 자료 감사합니다.