소규모 기업 환경에서 다운타임이 발생할 때 가동 시간을 늘리기 위해 DRBD 또는 클러스터 파일 시스템을 사용하는 방법을 살펴봅니다.
현재 우리는 Linux와 Samba를 사용하는 파일 서버용 서버 박스를 사용하고 있으며, VM에서 웹 서버와 데이터베이스를 실행하고 있습니다. 두 번째 서버를 추가하고 파일과 VM을 분산 파일 시스템에 배치하려고 했습니다. 기본 OS는 더욱 정적이고 수동으로 쉽게 관리할 수 있습니다(변경 시 구성 파일 복사, 필요한 경우 전체 백업에서 기본 OS 복사 등).
질문은 수동으로 수행한 경우 장애 조치 시나리오에 관한 것입니다. 서버 1이 다운되어 수동으로 Fail Over를 수행한 경우 서버 2의 고정 IP를 서버 1로 설정하고(역시 서버 1은 다운되었으며 복구가 필요한 상태임) Samba를 시작하고 시작하면 Fail Over가 완료됩니다. 서버 1에서 실행하고 백업 서비스를 시작할 때와 동일한 고정 IP를 갖는 VM은 무엇입니까?
이것은 빠르고 간단한 과정처럼 들리지만 거의 너무 간단합니다. 뭔가 빠졌나요? 이는 실패 시 숙련되지 않은 사람이 실행하도록 지시할 수 있는 스크립트나 무언가를 통해 쉽게 자동화될 수도 있습니다.
하드웨어 장애가 발생하는 경우 대기 시간은 대기 IT 지원과 보조 서버 없이 필요한 부품이 없으면 며칠이 될 수 있지만, 보조 서버를 사용하면 정지 시간은 최대 몇 시간이 됩니다. 하나는 그러한 작업을 수행할 수 있을 만큼 능숙한 사무실입니다(누군가가 있었다면 분).
답변1
설명하는 장애 조치 프로세스는 정확하면서도 간단합니다. DRBD를 사용하는 것은 공유 스토리지와 같은 단일 장애 지점을 제거하므로 중복성을 생성하는 핵심 단계입니다.
언급한 현재 장애 조치는 다음을 통해 쉽게 자동화할 수 있습니다.심박조율기/Corosync수동 개입이 필요하지 않도록 합니다. 나는 자체 작성 스크립트를 선호합니다. 기능하지 않는 노드를 보호하여 분할 두뇌 시나리오(모든 데이터를 망칠 수 있음)에 직면하지 않도록 관리하기 때문입니다.
"실제" HA에는 시스템의 완전한(또는 최소한 최대 보관 가능) 분리(별도의 공간(또는 최소한 랙), 다른 USV, 중복 전환 등)이 필요하다는 점을 명심하십시오. 단일 실패 지점은 일반적으로 가용성을 최적화하기 위한 모든 노력을 망칩니다.