이 페이지에서
고가용성 페일오버 시나리오 이해하기
다음 섹션에서는 가능한 고가용성 장애 시나리오에 대해 설명합니다. 실패가 감지되는 방법, 취해야 할 복구 작업, 해당하는 경우 장애로 인한 시스템에 미치는 영향.
활성 VIP 노드 충돌
검색
대기 VIP 노드에서 실행되는 하트비트 서비스는 피어로부터 하트비트 메시지를 수신하지 않은 후 10초 이내에 충돌을 감지합니다. JBoss 클러스터링 메커니즘을 사용하면 다른 노드의 JBoss 서버가 실패한 노드의 JBoss 서버가 약 52초 만에 응답하지 않는 것을 감지할 수 있습니다.
복구
대기 노드는 즉시 VIP 주소를 맡습니다.
실패한 노드가 제공하는 디바이스 연결은 클러스터의 나머지 노드로 마이그레이션됩니다. 이 프로세스는 JBoss 클러스터 구성원이 실패한 노드의 JBoss 서버가 중단된 것을 감지한 후 약 1분 후에 시작됩니다. 프로세스가 완료하는 데 걸리는 시간은 마이그레이션할 디바이스 연결 수, 나머지 노드의 로드 등에 따라 다릅니다. 일반적으로 프로세스는 몇 분 내에 완료됩니다.
VIP 주소가 대기 노드에 의해 인계된 후, 네트워크 모니터링 서비스가 대기 노드에서 시작됩니다. 네트워크 모니터링 서비스가 초기화를 완료하는 데는 약 3~5분이 소요됩니다. 유지 관리 중인 FM 및 PM 데이터의 크기에 따라 더 많은 시간이 걸릴 수 있습니다.
영향
VIP 주소는 대기 노드에 의해 점령될 때까지 약 10초 동안 사용할 수 없게 됩니다. 이 기간 동안 GUI 또는 API 클라이언트 액세스에 일시적 오류가 발생합니다. 또한 이 간격 동안 디바이스가 VIP 주소로 전송하는 모든 SNMP 트랩은 손실됩니다.
장애가 있는 노드의 JBoss 서버에서 연결이 제공되고 있는 디바이스의 경우 디바이스 연결이 몇 분 간 중단됩니다.
실패한 노드에서 진행 중인 모든 작업은 실패한 것으로 표시되고 그 이유가 표시됩니다.
사용자는 네트워크 모니터링 서비스가 대기 노드에서 초기화되는 동안 약 3~5분 동안 네트워크 모니터링 기능이 중단되는 것을 경험합니다.
대기 VIP 노드 충돌
검색
JBoss 클러스터링 메커니즘을 사용하면 다른 노드의 JBoss 서버가 실패한 노드의 JBoss 서버가 약 52초 만에 응답하지 않는지 감지할 수 있습니다.
복구
실패한 노드가 제공하는 디바이스 연결은 클러스터의 나머지 노드로 마이그레이션됩니다. 이 프로세스는 JBoss 클러스터 구성원이 실패한 노드의 JBoss 서버가 중단된 것을 감지한 후 약 1분 후에 시작됩니다. 프로세스 완료 시간은 마이그레이션할 디바이스 연결 수, 나머지 노드의 로드 등에 따라 다릅니다. 일반적으로 이 프로세스는 몇 분 내에 완료됩니다.
영향
장애가 있는 노드의 JBoss 서버에서 연결이 제공되고 있는 디바이스의 경우 디바이스 연결이 몇 분 간 중단됩니다.
실패한 노드에서 진행 중인 모든 작업은 실패한 것으로 표시되고 그 이유가 표시됩니다.
활성 VIP 노드의 eth0이 감소합니다.
검색
대기 VIP 노드에서 실행되는 하트비트 서비스는 피어로부터 하트비트 메시지를 수신하지 않은 후 10초 이내에 충돌을 감지합니다. JBoss 클러스터링 메커니즘을 사용하면 다른 노드의 JBoss 서버가 실패한 노드의 JBoss 서버가 약 52초 만에 응답하지 않는 것을 감지할 수 있습니다.
복구
대기 노드는 즉시 VIP 주소를 맡습니다.
실패한 노드가 제공하는 디바이스 연결은 클러스터의 나머지 노드로 마이그레이션됩니다. 이 프로세스는 JBoss 클러스터 구성원이 실패한 노드의 JBoss 서버가 중단된 것을 감지한 후 약 1분 후에 시작됩니다. 프로세스가 완료하는 데 걸리는 시간은 마이그레이션할 디바이스 연결 수, 나머지 노드의 로드 등에 따라 다릅니다. 일반적으로 프로세스는 몇 분 내에 완료됩니다.
VIP 주소가 대기 노드에 의해 인계된 후, 네트워크 모니터링 서비스가 대기 노드에서 시작됩니다. 네트워크 모니터링 서비스가 초기화를 완료하는 데는 약 3~5분이 소요됩니다. 유지 관리 중인 FM 및 PM 데이터의 크기에 따라 더 많은 시간이 걸릴 수 있습니다.
영향
VIP 주소는 대기 노드에 의해 점령될 때까지 약 10초 동안 사용할 수 없게 됩니다. 이 기간 동안 GUI 또는 API 클라이언트 액세스에 일시적 오류가 발생합니다. 또한 이 간격 동안 디바이스가 VIP 주소로 전송하는 모든 SNMP 트랩은 손실됩니다.
장애가 있는 노드의 JBoss 서버에서 연결이 제공되고 있는 디바이스의 경우 디바이스 연결이 몇 분 간 중단됩니다.
실패한 노드에서 진행 중인 모든 작업은 실패한 것으로 표시되고 그 이유가 표시됩니다.
사용자는 네트워크 모니터링 서비스가 대기 노드에서 초기화되는 동안 약 3~5분 동안 네트워크 모니터링 기능이 중단되는 것을 경험합니다.
대기 VIP 노드의 eth0이 다운
검색
JBoss 클러스터링 메커니즘을 사용하면 다른 노드의 JBoss 서버가 실패한 노드의 JBoss 서버가 약 52초 만에 응답하지 않는지 감지할 수 있습니다.
복구
실패한 노드가 제공하는 디바이스 연결은 클러스터의 나머지 노드로 마이그레이션됩니다. 이 프로세스는 JBoss 클러스터 구성원이 실패한 노드의 JBoss 서버가 중단된 것을 감지한 후 약 1분 후에 시작됩니다. 프로세스 완료 시간은 마이그레이션할 디바이스 연결 수, 나머지 노드의 로드 등에 따라 다릅니다. 일반적으로 이 프로세스는 몇 분 내에 완료됩니다.
영향
장애가 있는 노드의 JBoss 서버에서 연결이 제공되고 있는 디바이스의 경우 디바이스 연결이 몇 분 간 중단됩니다.
실패한 노드에서 진행 중인 모든 작업은 실패한 것으로 표시되고 그 이유가 표시됩니다.
비 VIP 노드 충돌
검색
JBoss 클러스터링 메커니즘을 사용하면 다른 노드의 JBoss 서버가 실패한 노드의 JBoss 서버가 약 52초 만에 응답하지 않는지 감지할 수 있습니다.
복구
실패한 노드가 제공하는 디바이스 연결은 클러스터의 나머지 노드로 마이그레이션됩니다. 이 프로세스는 JBoss 클러스터 구성원이 실패한 노드의 JBoss 서버가 중단된 것을 감지한 후 약 1분 후에 시작됩니다. 프로세스가 완료하는 데 걸리는 시간은 마이그레이션할 디바이스 연결 수, 나머지 노드의 로드 등에 따라 다릅니다. 일반적으로 이 프로세스는 몇 분 안에 완료됩니다.
영향
장애가 있는 노드의 JBoss 서버에서 연결이 제공된 디바이스의 경우 디바이스 연결이 몇 분 동안 중단됩니다. 실패한 노드에서 진행 중인 모든 작업은 실패한 것으로 표시되고 그 이유가 표시됩니다.
비 VIP 노드의 eth0이 다운
검색
JBoss 클러스터링 메커니즘을 사용하면 다른 노드의 JBoss 서버가 실패한 노드의 JBoss 서버가 약 52초 만에 응답하지 않는지 감지할 수 있습니다.
복구
실패한 노드가 제공하는 디바이스 연결은 클러스터의 나머지 노드로 마이그레이션됩니다. 이 프로세스는 JBoss 클러스터 구성원이 실패한 노드의 JBoss 서버가 중단된 것을 감지한 후 약 11분 후에 시작됩니다. 프로세스 완료 시간은 마이그레이션할 디바이스 연결 수, 나머지 노드의 로드 등에 따라 다릅니다. 일반적으로 이 프로세스는 몇 분 안에 완료됩니다.
영향
장애가 있는 노드의 JBoss 서버에서 연결이 제공되고 있는 디바이스의 경우 디바이스 연결이 몇 분 간 중단됩니다.
실패한 노드에서 진행 중인 모든 작업은 실패한 것으로 표시되고 그 이유가 표시됩니다.
비 VIP 노드의 eth3은 다운
검색
디바이스 keepalive monitor는 이 노드가 제공하는 모든 디바이스 연결이 15분 만에 중단되는 것을 감지하고 이러한 디바이스의 연결 상태를 Down으로 표시합니다.
복구
Junos Space 시작된 연결의 경우, Junos Space 이러한 디바이스와 다시 연결하려고 시도합니다. 각 시도는 관리하는 디바이스 수 측면에서 로드가 가장 적은 것으로 판단되는 클러스터 노드에서 이루어집니다. 이 로드 밸런싱 검사에 따르면 클러스터의 다른 노드의 로드가 이 노드보다 훨씬 적으면 해당 노드에서 재연결 시도가 이루어지고 성공합니다. 이 경우 이러한 디바이스에 대한 연결이 몇 분 만에 다시 작동합니다. 이 노드가 가장 적게 로드되는 경우, 이 노드에서 모든 재연결 시도가 이루어지고 eth3이 다운된 상태로 유지되는 한 이러한 시도는 계속 실패합니다.
디바이스가 시작된 연결의 경우 디바이스는 약 15분 만에 연결 실패를 감지한 다음 몇 초 안에 클러스터의 다른 노드와 다시 연결됩니다.
영향
이 노드에서 연결이 제공되고 있는 디바이스에 대해 디바이스 연결이 중단됩니다. 연결이 15분(최상의 경우) 또는 eth3이 다시 가동될 때까지(최악의 경우) 중단될 수 있습니다. 또한 중단 시간은 해당 디바이스에 대한 재연결을 시도할 노드에 따라 디바이스마다 다를 수 있습니다. 디바이스가 시작된 연결의 경우 중단은 15분 이상 지속됩니다.
활성 VIP 노드의 eth3이 중단되었습니다.
검색
디바이스 keepalive monitor는 이 노드가 제공하는 모든 디바이스 연결이 15분 만에 중단되는 것을 감지하고 이러한 디바이스의 연결 상태를 Down으로 표시합니다.
복구
Junos Space 시작된 Jconnections의 경우, Junos Space 이러한 디바이스와 다시 연결하려고 시도합니다. 각 시도는 관리하는 디바이스 수 측면에서 로드가 가장 적은 것으로 판단되는 클러스터 노드에서 이루어집니다. 이 로드 밸런싱 검사에 따르면 클러스터의 다른 노드의 로드가 이 노드보다 훨씬 적으면 해당 노드에서 재연결 시도가 이루어지고 성공합니다. 이 경우 이러한 디바이스에 대한 연결이 몇 분 만에 다시 작동합니다. 이 노드가 가장 적게 로드되는 경우, 이 노드에서 모든 재연결 시도가 이루어지고 eth3이 다운된 상태로 유지되는 한 이러한 시도는 계속 실패합니다.
디바이스가 시작된 연결의 경우, 디바이스는 약 15분 만에 연결 실패를 감지한 다음 몇 초 안에 클러스터의 다른 노드와 다시 연결합니다.
영향
이 노드에서 연결이 제공되고 있는 디바이스에 대한 디바이스 연결이 중단됩니다. 연결이 15분(최상의 경우) 또는 eth3이 다시 가동될 때까지(최악의 경우) 중단될 수 있습니다. 또한 중단 시간은 해당 디바이스에 대한 재연결을 시도할 노드에 따라 디바이스마다 다를 수 있습니다. 디바이스가 시작된 연결의 경우 중단은 15분 이상 지속됩니다.
네트워크 모니터링 서비스는 VIP 노드에서만 실행되므로 영향을 받습니다. 모든 디바이스가 VIP 노드의 eth3 IP 주소로 트랩 대상으로 구성되므로 서비스는 매니지드 디바이스로부터 SNMP 트랩을 수신하지 않습니다. 또한 모든 매니지드 디바이스의 모든 성능 및 장애 모니터링은 eth3이 다시 가동될 때까지 실패합니다.
노드의 JBoss Server가 중단됩니다.
검색
노드의 JBoss 서버가 중단되면 JBoss 클러스터의 다른 노드는 실패를 약 2초 만에 감지합니다) 실패한 JBoss 서버에 대한 TCP 연결이 운영 체제에 의해 닫혀 있기 때문입니다.
복구
실패한 JBoss 서버가 제공하는 디바이스 연결은 클러스터의 다른 노드로 마이그레이션됩니다. 이 프로세스는 JBoss 클러스터 구성원이 실패한 노드의 JBoss 서버가 중단된 것을 감지한 후 약 1분 후에 시작됩니다. 프로세스가 완료하는 데 걸리는 시간은 마이그레이션할 디바이스 연결 수, 나머지 노드의 로드 등에 따라 다릅니다. 일반적으로 프로세스는 몇 분 내에 완료됩니다.
노드에서 실행되는 워치독 서비스(jmp-watchdog)는 JBoss 서버가 중단된 것을 감지하고 자동으로 다시 시작합니다. JBoss 서버가 다시 작동하면 다른 클러스터 멤버가 자동으로 검색하고 클러스터에 추가됩니다. 그런 다음 클러스터의 다른 노드에서 캐시를 동기화합니다. JBoss의 일반적인 재시작 시간은 2~5분입니다. 그러나 설치된 애플리케이션 수, 관리되는 디바이스 수, 설치된 DMI 스키마 버전 수 등에 따라 더 많은 시간이 걸릴 수 있습니다.
영향
중단된 JBoss 서버에서 연결을 제공하는 디바이스의 경우 디바이스 연결이 몇 분 동안 중단됩니다.
충돌한 JBoss 서버에서 진행 중인 모든 작업은 실패한 것으로 표시되고 그 이유가 표시됩니다.
활성 VIP 노드의 MySQL 서버가 중단됩니다.
검색
노드의 MySQL 서버가 다운되면 워치독 서비스는 해당 활성 노드에서 다운된 MySQL 서버를 약 1~2초 안에 감지합니다.
복구
워치독 서비스는 노드에서 MySQL 서버를 즉시 다시 시작합니다. 재시작되면 MySQL 서버가 약 20~60초 후에 작동합니다.
영향
VIP 노드의 MySQL 서버는 클러스터의 모든 JBoss 서버의 모든 요청을 제공하는 활성 데이터베이스입니다. 이는 이 기간(20~60초) 동안 모든 노드에서 JBoss가 간단한 데이터베이스 중단을 경험할 수 있음을 의미합니다. 데이터베이스 액세스가 필요한 모든 요청은 이 기간 동안 실패합니다. 이로 인해 요청 시 GUI 또는 API 클라이언트가 실패하게 되며, 이 기간 동안 내부적으로 데이터베이스 액세스가 필요합니다. 또한 이 기간 동안 데이터베이스 액세스가 필요한 작업이 실패하게 됩니다.
대기 VIP 노드의 MySQL 서버가 중단됩니다.
검색
노드의 MySQL 서버가 다운되면 워치독 서비스는 해당 대기 노드의 다운 MySQL 서버를 약 1~2초 안에 감지합니다.
복구
워치독 서비스는 노드에서 MySQL 서버를 즉시 다시 시작합니다. 재시작되면 MySQL 서버가 작동하려면 약 20~60초가 걸립니다. 이 서버가 백업된 후, 이 서버는 백그라운드에서 기본 서버로 재동기화되며, 재동기화 시간은 중단 시 발생하는 변경 사항 수에 따라 달라집니다.
영향
대기 중인 VIP 노드의 MySQL 서버는 JBoss에서 액세스할 수 없기 때문에 다운타임은 시스템의 나머지 시스템 또는 사용자가 알아차리게 되는 부정적인 영향을 일으키지 않습니다.
기본 데이터베이스 노드 충돌
검색
보조 데이터베이스 노드에서 실행되는 Heartbeat 서비스는 기본 데이터베이스 노드에서 하트비트 메시지를 수신하지 않은 후 10초 이내에 충돌을 감지합니다.
복구
데이터베이스 VIP 주소는 10~20초 이내에 보조 데이터베이스 노드로 전송됩니다. 데이터베이스 VIP 주소가 보조 데이터베이스 노드에 의해 인가된 후 다른 노드의 JBoss 서버는 데이터베이스에 액세스할 수 있습니다.
영향
데이터베이스 VIP 주소를 약 10~20초 동안 사용할 수 없게 되고 보조 데이터베이스 노드가 이를 인수합니다. 기본 데이터베이스 노드의 MySQL 서버는 클러스터의 모든 JBoss 서버의 모든 요청을 제공하는 활성 데이터베이스입니다. 이는 이 기간(20~60초) 동안 모든 노드에서 JBoss가 간단한 데이터베이스 중단을 경험할 수 있음을 의미합니다. 데이터베이스 액세스가 필요한 모든 요청은 이 기간 동안 실패합니다. 이로 인해 GUI 및 API 클라이언트가 요청 시 이 기간 동안 내부적으로 데이터베이스 액세스가 필요한 실패가 발생합니다. 또한 이 기간 동안 데이터베이스 액세스가 필요한 작업이 실패하게 됩니다.
보조 데이터베이스 노드 충돌
검색
기본 데이터베이스 노드에서 실행되는 Heartbeat 서비스는 보조 데이터베이스 노드에서 하트비트 메시지를 수신하지 않은 후 10초 이내에 충돌을 감지합니다.
복구
노드는 삭제될 수 있으며, 데이터베이스 고가용성을 유지하기 위해 Junos Space 클러스터에 새로운 노드를 보조 데이터베이스 노드로 추가할 수 있습니다.
영향
보조 데이터베이스 노드의 MySQL 서버는 JBoss에 의해 액세스되지 않기 때문에 다운타임은 시스템의 나머지 시스템 또는 사용자가 발견한 부정적인 영향을 일으키지 않습니다.
기본 데이터베이스 노드의 MySQL 서버가 중단됩니다.
검색
노드의 MySQL 서버가 다운되면 워치독 서비스는 해당 활성 노드에서 다운된 MySQL 서버를 약 1~2초 안에 감지합니다.
복구
워치독 서비스는 노드에서 MySQL 서버를 즉시 다시 시작합니다. 재시작되면 MySQL 서버가 약 20~60초 후에 작동합니다.
영향
기본 데이터베이스 노드의 MySQL 서버는 클러스터의 모든 JBoss 서버의 모든 요청을 제공하는 활성 데이터베이스입니다. 이는 이 기간(20~60초) 동안 모든 노드에서 JBoss가 간단한 데이터베이스 중단을 경험할 수 있음을 의미합니다. 데이터베이스 액세스가 필요한 모든 요청은 이 기간 동안 실패합니다. 이로 인해 GUI 및 API 클라이언트가 요청 시 이 기간 동안 내부적으로 데이터베이스 액세스가 필요한 실패가 발생합니다. 또한 이 기간 동안 데이터베이스 액세스가 필요한 작업이 실패하게 됩니다.
보조 데이터베이스 노드의 MySQL 서버가 중단됩니다.
검색
노드의 MySQL 서버가 다운되면 워치독 서비스는 해당 대기 노드의 다운 MySQL 서버를 약 1~2초 안에 감지합니다.
복구
워치독 서비스는 노드에서 MySQL 서버를 즉시 다시 시작합니다. 재시작되면 MySQL 서버가 작동하려면 약 20~60초가 걸립니다. 이 서버가 백업된 후 이 서버는 백그라운드의 기본 데이터베이스 노드로 재동기화됩니다. 재동기화 시간은 운영 중단 중에 발생한 변경 사항의 수에 따라 다릅니다.
영향
보조 데이터베이스 노드의 MySQL 서버는 JBoss에 의해 액세스되지 않기 때문에 다운타임은 시스템의 나머지 시스템 또는 사용자가 발견한 부정적인 영향을 일으키지 않습니다.
활성 VIP 노드의 아파치 HTTP 서버가 중단됩니다.
검색
노드의 아파치 HTTP 서버가 다운되면 워치독 서비스는 약 1~2초 만에 해당 노드의 다운 HTTP 서버를 감지합니다.
복구
워치독 서비스는 노드에서 Apache HTTP 서버를 즉시 다시 시작하고 1초 후에 서비스를 준비합니다.
영향
Apache HTTP 서버가 다시 시작될 때까지 GUI 및 NBI 클라이언트가 간단한 서비스 중단을 경험할 수 있습니다. 그러나 이 중단은 몇 초(일반적으로 2초)에 불과하며 클라이언트에서 거의 눈치채지 못합니다.
대기 VIP 노드의 아파치 HTTP 서버가 중단됩니다.
검색
노드의 아파치 HTTP 서버가 다운되면 워치독 서비스는 약 1~2초 만에 해당 노드의 다운 HTTP 서버를 감지합니다.
복구
워치독 서비스는 노드에서 Apache HTTP 서버를 즉시 다시 시작하고 1초 후에 서비스를 준비합니다.
영향
영향이 없습니다.
전용 Cassandra Node 충돌
검색
Cassandra 노드가 다운되면 워치독 서비스는 약 1~2초 만에 카산드라 서비스가 해당 노드에서 다운되는 것을 감지합니다.
복구
다운된 Cassandra 노드는 패브릭에서 삭제되어야 합니다.
영향
다운된 노드가 패브릭에서 삭제될 때까지 Cassandra 데이터베이스에 파일을 업로드하거나 삭제할 수 없습니다.
JBoss 노드의 Cassandra 서비스가 중단됩니다.
검색
JBoss 노드의 Cassandra 서비스가 중단되면 워치독 서비스는 약 1~2초 만에 Cassandra 서비스가 해당 노드에서 다운되는 것을 감지합니다.
복구
노드의 Cassandra 서비스는 비활성화되어야 합니다.
영향
Cassandra 서비스가 노드에서 비활성화될 때까지 파일을 Cassandra 데이터베이스에 업로드하거나 삭제할 수 없습니다.