위키원
액티브-스탠바이
액티브-스탠바이(active-stand_by)란 기존의 마스터-슬레이브의 의미를 대체한 것으로, 하나의 장치가 여러대의 장치를 제어하고 통신하는 허브의 역할을 가지고 있는 것을 의미한다. 보통 프로그램 명령어나 통신, 서버분야에서 널리 사용되고 있다.
개요[편집]
마스터(Master)는 주인, 주국이라는 의미를 슬레이브(slave)의 사전적 의미는 노예, 종국이라는 뜻을 가지고 있다. 마스터-슬레이브는 기존의 IT 분야에서 많이 쓰이는 명령어, 기술이었다. 하지만 최근 미국의 경찰이 흑인을 과잉진압하는 사건과 더불어 기존의 마스터-슬레이브라는 단어가 흑인 노예를 상징한다는 차원에서 마스터-슬레이브 단어를 폐지하라는 주장이 나오게 되었다. 이를 받아들인 IT업계가 해당 명령어와 단어를 바꾸고 있다. 많은 IT기업 회사와 프로그램 개발자들이 마스터-슬레이브 대신 액티브(활성)-스탠바이(대기) 또는 메인(Main)으로 바꾸고 있다. 미국의 소프트웨어 개발 호스팅 업체 마이크로소프트 산하 깃허브(GitHub)는 ‘블랙 리브스 매터(Black Lives Matter, 흑인 생명은 소중하다)’ 운동에 발맞춰 마스터, 슬레이브와 같은 코딩 언어를 없애는 중이다. 마스터와 슬레이브는 프로그래밍이나 서버 등 개발자들이 사용하는 용어 중 하나로, 주 작업(마스터)에 변형이 생길 때 보조 작업(슬레이브)이 가동되는 방식이다. 이는 액티브와 스탠바이로도 쓰인다. 2020년 7월말 냇 프리드먼(Nat Friedman) 깃허브 최고경영자는 한 회사와의 트위터 내용을 공개했다. 기술 커뮤니티에서 특정 용어를 다른 이름으로 바꾸는 조치를 취하기 시작하자는 제안이다. 특히 브랜치(Branch) 구조를 나타내는 마스터를 ‘메인(Main)’으로 바꾸자는 것이다. 이에 프리드먼은 “훌륭한 생각이며 우린 이미 작업중이다”고 답했다. 조지 플로이드(George Floyd), 브리오나 테일러(Breonna Tayler) 등 미국 사회에서 흑인 시민이 사망한 사건에 대한 항변이 세계적으로 이어지는 가운데 애플, 구글, 마이크로소프트 등 대형 IT기업들이 인종차별에 반대하고 정의 구현에 대해 목소리를 높이고 있다. 이밖에 ‘화이트리스트’, ‘블랙리스트’와 같은 용어도 변경하려는 업계 움직임이 포착되고 있다.[1]
종류[편집]
- 액티브
- 액티브는 다른 장치 나 프로세스를 제어하는 장치 또는 프로세스이다. 제어 방향은 항상 액티브에서 스탠바이로 흐른다. 예를 들어, 데이터베이스 복제에서 액티브 데이터베이스는 모든 권한을 가진 당사자, 주권으로 간주한다. 액티브 데이터베이스는 데이터에 대한 모든 업데이트를 기록하고 다른 모든 데이터베이스는 나중에 액티브와 동기화된다. 액티브라는 용어는 PATA (Parallel Advanced Technology Attachment)를 사용하는 하드 디스크 드라이브 배열에도 사용된다. 그러나 이 상황에서 액티브는 장치 0의 다른 이름으로 사용되며 액티브(장치 0)는 스탠바이로 정의된 장치를 제어할 수 없다. 그러나 액티브로 지정된 장치가 BIOS 또는 운영 체제에 먼저 나타난다. 하드 디스크 드라이브를 액티브로 지정하는 것은 일반적으로 특정 점퍼 설정을 통해 수행된다.
- 스탠바이
- 스탠바이는 다른 장치 또는 프로세스 (액티브)에 의해 제어되는 장치 또는 프로세스이다. 예를 들어, 데이터베이스 복제에서 스탠바이로 간주하는 데이터베이스는 마스터 데이터베이스에 기록된 업데이트를 사용하여 해당 데이터를 액티브와 동기화한다. 스탠바이는 액티브로부터 업데이트를 성공적으로 수신하면 메시지를 출력하여 액티브에 알린다. 이를 통해 액티브는 스탠바이에 더 많은 업데이트를 보낼 수 있다. 또한, PATA 하드 디스크 드라이브 배열에서 스탠바이라는 용어는 장치 1의 동의어로 사용된다. 그러나 이 경우 액티브(장치 0)는 스탠바이로 지정된 장치를 제어할 수 없다. 그러나 SATA (Serial Advanced Technology Attachment)가 기존 PATA 드라이브를 대체 할 때 하드 디스크 드라이브를 액티브 및 스탠바이로 지정하는 것은 더 이상 사용되지 않았다.
- 차이점
- 액티브-스탠바이 통신 모델에서 액티브는 다른 장치 또는 프로세스를 제어하는 장치 또는 프로세스인 반면 스탠바이는 다른 장치 (액티브)에 의해 제어되는 장치 또는 프로세스이다. 데이터베이스 복제에서 액티브 데이터베이스는 데이터의 모든 업데이트를 기록하고 스탠바이로 지정된 데이터베이스로 보내게 된다. 스탠바이는 업데이트를 성공적으로 받았는지 액티브에만 알려줄 수 있으며 업데이트가 오는 것을 중지할 수 있는 권한이 없다. 그러나 PATA 하드 디스크 드라이브 배열에서 액티브 / 스탠바이 사용에는 차이가 있다. 여기서 액티브로 지정된 장치는 스탠바이로 지정된 장치를 제어할 수 없다.[2]
기술[편집]
액티브-스탠바이 방식은 여려 분야에서 사용되고 있다. 리눅스, 파이썬, MySQL 등에서 사용하고 있고 통신 망이나 데이터베이스 서버 관리, 고가용성 이중화 방식, 철도 제어 시스템에서도 액티브-스탠바이 속도와 효율성 면에서 두각을 나타낸다. 기본적인 구조는 옆의 그림과 같다. 데이터 통신, 서버 관리 제어 방법으로, 액티브는 한 번의 명령 송출에 의해 다수의 스탠바이들을 독립적으로 제어하고 그들로부터의 요구정보를 독립적으로 획득할 수다. 흔히 액티브-스탠바이 간의 이중화 프로토콜 방법이라 말한다. 이중화 프로토콜 방법은 하나의 액티브 장치와 이에 접속된 다수의 스탠바이 장치들 사이에서 데이터 통신 간에 효율적으로 사용된다. 다수의 스탠바이의 상태와 처리 요구에 관한 정보를 액티브가 전송받는 단계, 스탠바이들의 상태와 처리요구정보에 대응하는 다수의 명령 데이터를 이중화하여 공통주소를 가지는 데이터 프레임으로 전송하는 액티브 데이터 프레임 전송단계와 스탠바이들에게 공통 주소가 설정되며, 공통 주소를 가지는 데이터 프레임을 수신하여 미리 설정된 위치에 대응하는 자기 데이터를 수신하여 명령을 수행하는 스탠바이 수신단계와 자기 데이터의 수신에 의한 명령을 수행한 후 자신의 공통 주소를 고유 주소로 변경하여 자신의 상태 및 요구사항의 정보를 설정하고, 공통 주소로 천이하는 스탠바이 주소 변경단계를 포함하여 이루어진다.[3] 말 그대로 액티브는 입력, 출력이 두 가지가 가능하지만, 스탠바이는 입력만 가능하다. 액티브에서 특정 데이터값을 스탠바이에 요청하면 스탠바이는 액티브의 요구에 따라 데이터 프레임을 설정하고 액티브에만 전달하는 입장이다. 하나의 액티브에 여러 개의 스탠바이를 붙여 사용할 수 있다. 이러한 규칙에 맞추어 작동하는데 이러한 액티브-스탠바이 구조가 고가용성을 위한 구조가 되는 이유는 바로 센티넬(Sentinel)의 역할 때문이다. 센티넬은 액티브와 스탠바이가 제대로 동작하는지 지속해서 감시(모니터링)한다. 만약 시스템 운영 중에 액티브가 다운됐을 경우, 스탠바이만 작동하게 되어 입력 동작만 수행할 수 있다. 따라서 다운 타임이 증가하게 되고 가용성은 떨어지게 된다. 이때, 액티브가 복구되지 않은 경우 관리자의 간섭 없이 스탠바이를 액티브로 승격시켜주고 기존의 액티브는 스탠바이로 강등되어 복구 후에 새로운 액티브에 대한 스탠바이의 기능을 수행하게 된다. 센타넬은 감시하고 있는 객체들이 페일오버 되었을 때 사용자에게 알리거나 관리자에게 이메일 또는 SMS로 알린다.[4]
- 고가용성
- 고가용성(high availability) 또는 약자로 'HA'란 정보기술에서 아주 오랜 시간 동안 지속해서 운영이 가능한 시스템이나 재활용 가능성을 가리킨다. 가용성이란 흔히 "100% 가용" 등과 같이 상대적으로 측정되거나 또는 "절대 고장 나지 않음" 등과 같이 표현될 수 있다. 널리 쓰이고 있지만 달성하기 결코 쉽지 않은 시스템 및 제품에 대한 가용성 표준에 흔히 "파이브 나인" (five 9) 이라고 부르는 99.999%의 가용성을 들 수 있다. 하나의 컴퓨터 시스템이나 네트워크는 전체의 운영을 위해 모두가 사용 가능한 상태로 있어야만 하는 가능한 수많은 부품으로 구성되었기 때문에, 고가용성에 대한 많은 계획이 백업이나 장애 극복 처리 및 데이터 저장 및 접근 등에 집중되어 있다. 저장장치의 경우에는 레이드가 그중 하나의 접근 방법이며, 보다 최근에는 SAN(storage area network) 과 같은 방법을 이용한다. 일부 가용성 전문가들은, 만약 어떤 시스템에 고가용성이 요구된다면 그 시스템의 모든 부품이 잘 설계되고 실제로 사용되기 전에 완전하게 시험 되어야 한다고 강조한다. 예를 들어, 완전히 시험 되지 않은 새로운 응용프로그램은 실제 사용 현장에서 자주 문제를 일으키는 주요인이 될 가능성이 매우 높다.
- 서버 클러스터(cluster)
- 서버 클러스터란 각기 다른 서버(Server Enterprise or server Data center)들을 하나로 묶어서 하나의 시스템같이 동작하게 함으로써, 클라이언트들에게 고가용성의 서비스를 제공하는 것을 말한다. 클러스터로 묶인 한 시스템에 장애가 발생하면, 정보의 제공 포인트는 클러스터로 묶인 다른 정상적인 서버로 이동한다. 서버 클러스터는 사용자로 하여금 서버 기반 정보를 지속적이고, 끊기지 않도록 제공한다. 예를 들면 사용자 폭주에 대비해서, 웹서버를 10대로 운영하는 방법이 있다. 클러스터링은 하드웨어, 소프트웨어 모두 구성 가능하다. 서버 장비 한 대에 포트를 달리해서, 아파치를 여러 개 띄운다면 소프트웨어 클러스터링이 된다. 클러스터는 높은 수준의 가용성, 안정성, 확장성을 제공하기 위해 하나의 시스템을 이용하는 것보다, 두 개 또는 그 이상의 시스템을 이용한다.[5][6]
- 다중화(Duplex) 방식 : 데이터의 정합성을 얻기위 한 방법으로 액티브-스탠바이와 액티브-액티브가 있고 스토리지를 공유하는 공유 디스크(shared disk)방식과 스토리지를 공유하지 않는(shared nothing) 방식으로 나뉜다.
- 액티브-스탠바이
- 다중화 방식을 활용한 가장 기본적인 기술이 액티브-스탠바이 기법이다. 한 서버가 액티브 상태로 서비스하고 있을 때, 스탠바이 서버는 전원은 켜져 있고 운영체제까지만 올라와 있는 상태이다. 액티브 서버에 하드웨어 장애나 네트워크 장애, 혹은 프로세스 장애 등이 발생해 서비스를 못 하게 되면, 스탠바이 서버에 있는 다중화 기술이 운영 서버의 장애 발생을 감지한다. 그리고 다중화 기술을 사용하여 자동으로 대기 서버에 모든 서비스를 올려준다. 즉, 단방향 페일 오버를 구현하는 구성이다. 기존 액티브 서버에 접속했던 사용자는 접속이 끊어지겠지만, 재접속 시 바로 서비스를 받을 수 있다. 왜냐하면, 스탠바이 서버가 모든 서비스를 대신하기 때문이다. 사용자 입장에서 보면 두 대의 서버들 중에 어떤 서버가 서비스하는지 보다는 올바른 서비스를 받기 원할 것이다. 서버 다중화를 구현하는 가장 큰 이유는 중단 없는 서비스를 공급하는 데 있다. 액티브-스탠바이의 가장 큰 장점은 단순함이라 할 수 있다. 구성하기도 쉽고, 관리자 입장에서도 운영하기 쉽다. 그래서 지금도 많은 기업의 시스템들이 이러한 구성으로 구현되고 있다. 활성과 대기 시스템의 사양을 동일하게 구성하는 경우도 있지만, 때에 따라서는 대기 시스템의 사양을 약간 낮게 구성하는 경우도 있다. 액티브 서버의 장애 발생 시, 스탠바이 서버가 서비스하면서 몇 시간 정도만 버텨 준다면, 이 시간에 원래의 액티브 서버를 수리할 수 있다. 그리고 서비스를 원래의 액티브 서버로 돌려놓을 수 있기 때문이다. 액티브-스탠바이 방식은 스탠바이의 구성에 따라 역활이 달라진다.[7]
[8]액티브-스탠바이 방식 구성단계 상세내용 핫(Hot) 스탠바이 스탠바이를 가동 후 즉시 이용가능한 구성 웜(Warm) 스탠바이 스탠바이를 가동 후 이용가능하게 하기 위해서 나름대로의 준비가 필요한 구성 콜드(Cold) 스탠바이 스탠바이 측을 정지 시켜 두는 구성
- 액티브-액티브 구성
- 기업의 운영자 입장에서 봤을 때, 스탠바이 서버는 보통 때 아무 일도 안 하니 투자한 비용이 아깝다고 생각하게 된다. 어떠한 방식으로든지 스탠바이 사바도 보통 때 다른 업무를 서비스하기를 원한다. 그래서 나온 방식이 액티브-액티브 구성이다. 액티브-액티브 구성에서는 한 서버가 데이터베이스 서비스를 하고, 다른 서버는 웹 서비스를 제공하게 된다. 두 대의 서버가 각기 다른 서비스를 제공하는 것이다. 그러다가 데이터베이스 서버에 장애가 발생할 경우, 다중화 방식을 사용하여 웹 서버에서 데이터베이스 서비스를 할 수 있도록 한다. 즉, 웹 서버는 원래 자신이 하던 웹 서비스뿐만 아니라 데이터베이스 서비스까지 두 가지 일을 수행하게 된다. 이 경우에는 데이터베이스의 기본 구성만 설정하고 이루어진다. 반대로 웹 서비스에 장애가 발생했을 경우, 데이터베이스 서버에서 데이터베이스 서비스뿐만 아니라 웹 서비스까지 같이 수행하게 된다. 상호 대기 서버가 되는 구성이다. 그런데 이런 구성을 하고자 한다면 몇 가지 고려해야 할 사항이 있다. 우선 하나의 서버에서 데이터베이스와 웹 서비스 두 가지를 할 수 있도록 시스템 사양을 설계해야만 한다. 이렇게 설계하지 않고 하나의 서버에서 두 가지 서비스가 실행될 경우 서버가 부하를 견디지 못해 다운될 수도 있다. 그러면 두 가지 서비스 모두 장애가 발생해, 고가용성 클러스터를 구축한 효과를 볼 수가 없다. 또, 하나의 서버에서 두 가지 서비스가 모두 실행될 수 있도록 환경 설정도 해줘야 한다. 액티브-액티브보다는 구성상 약간 복잡해지지만, 활용도나 가용성면에서는 가장 좋다.[7]
기능[편집]
액티브-스탠바이 기술의 고가용성은 가용성을 높이기 위한 문제해결 방안으로 다음과 같은 기능을 반드시 갖추어야 한다. 첫째, 데이터 복제 기능은 기본적으로 고가용성으로 구성된 서버 중 1번 서버가 장애가 발생 시, 2번 서버가 대상 서비스를 바로 서비스를 하기 위해서는 양쪽의 데이터는 항상 100% 동일 해야 하는 무결성을 보장해야 한다. 이렇게 데이터를 동일하게 맞추기 위해서는 데이터 복제 즉, 데이터 레플리케이션 기능이 반드시 필요하다. 두 번째로 장애 감시 기능은 앞에서 설명한 서버 고가용성 구성 시 1번 서버는 서비스 운영을 맞게 되며, 2번 서버는 1번 서버가 장애 발생 시 서비스를 운영하기 위한 대기 생태로 구성이 된다. 이러한 구성은 액티브-스탠바이 고가용성 구성이라고 한다. 그렇다면, 장애 발생을 감지하기 위한 논리적인 소프트웨어 구성이 필요하다. 장애 발생은, 네트워크 장애, 운영체제 및 서비스 프로그램(프로세스) 장애, 서버 하드웨어 장애로 보통 나뉜다. 상기와 같은 장애를 감시할 수 있는 장애 감시 에이전트는 각 서버에 설치가 되며 이러한 에이전트는 1번 서버와 2번 서버에 각각 설치되어, 자기 자신의 서버의 장애 포인트 감시 및 크로스로 1번 서버는 2번 서버를 감시, 2번 서버는 1번 서버를 상호 감시(Heartbeat Check)하여 고가용성을 유지하게 된다. 이러한 논리적인 구성은 서비스의 고가용성을 유지하기 위해 반드시 필요하며, 현재 운영 중인 서비스 중인 1번 서버의 상기 문제 발생 시 2번 서버로 서비스가 페일오버(자동전환) 되기 위해 필수적인 기능이다.[9]
- 리눅스 설치 방법
- 리눅스에서 액티브-스탠바이 기술을 참조하여서 도메인 주소를 설정할 수 있다. 도메인 네임 서버는 도메인 존(zone) 데이터 관리 측면에서 원본 존(zone) 데이터를 관리하는 액티브 네임 서버와 이를 동기화해서 사용하는 스탠바이 네임서버로 구분된다. 존 데이터는 관리하는 도메인 영역 정보로 다양한 레코드 유형에 따른 데이터를 가지고 있으며 일반적으로 관리자가 설정한 존 파일을 읽어 들여 존 데이터를 구성한다. 액티브에 있는 원본 존 데이터를 스탠바이가 동기화하는 작업을 존 전송이라 한다. 존 전송은 일반적으로 많은 존 데이터를 이동해야 하므로 신뢰성 있는 전송을 보장하는 TCP 53번 포트를 이용한다. 액티브와 스탠바이 네임 서버는 서로 동일한 기능을 수행하며 부하 분산을 통해 안전성을 높이는 역할을 한다.[10]
- 액티브 서버 설정[11]
도메인 네임 서버 액티브 서버 구축-192.168.100.100 서버 #>yum -y install bind.x86_64 // 도메인 네임 서버를 위한 bind파일설치 #>vi /etc/named.conf //설정파일에 들어가서 클라이언트 allow 설정
#> vi /etc/named.rfc1912.zones //서비스할 임의의 zone 파일 등록. allow-update { 192.168.100.100; }; 를 입력 (스탠바이IP)
#>vi /var/named/nirsa.com //서비스할 zone 파일 생성, ns1=액티브IP 입력 ns2=스탠바이IP 입력 #>cp -p named.localhost nirsa.com #>systemctl restart named //시스템 재시작
- 스탠바이 서버 설정[11]
#>yum -y install bind.x86_64 #>vi /etc/named.conf // 액티브 서버설정과 같이 클라이언트 접근설정하기 #>vi/etc/named.rfc1912.zones //allow-update 대신 masters를 입력하고 액티브 IP 설정
#>systemctl restart named //시스템 재시작 #>ls -lh /var/named/nirsa.com.zone // zone 파일 송수신 현황 확인
활용[편집]
- 서비스의 복구
- 서비스 노드에서 장애가 발생하면 대기 노드가 서비스를 수행할 것이다. 장애 노드의 문제가 모두 해소되면 어떻게 원복할 것인가도 중요한 문제가 될 수 있다. 왜냐하면 계획된 절체라 하더라도 볼륨 처리와 IP 회수와 부여, 프로세스의 종료와 기동 등을 수행하면서 길 경우 몇 분, 빨라도 몇 초 정도의 다운 타임 발생은 피할 수 없기 때문이다. 따라서 서비스 특성에 따라 곧바로 원복할 수도 있지만 대개 서비스가 쉬거나 사용자가 거의 없는 새벽 시간대 등을 활용해야 한다.
- 액티브 서버의 업그레이드 작업
- 시스템을 운영하다 보면 업그레이드나 구성을 변경해야 할 때가 있을 수밖에 없게 된다. 단일 시스템으로 운영할 경우라면 그런 작업을 위해 어쩔 수 없이 서비스 다운을 사용자에게 공지하고 사용자가 적은 야간 시간대에 작업해야만 한다. 고가용성 클러스터 기술로 구성된 환경이라면 스탠바이 노드로 서비스를 절체하고 액티브 서버의 점검이나 업그레이드 작업을 수행할 수 있다. 액티브 서버의 구성 목적은 장애 발생 시의 가용성을 확보하는 것이지만 계획된 시스템다운 시에도 클러스터는 유용하게 활용될 수 있다.
- 액티브-스탠바이를 이용한 기술
- 데이터베이스가 고가용성 기술을 사용하여 이중화 서버로 구성되고 다수의 데이터베이스 서버를 준비한 상태에서 액티브-액티브 또는 액티브-스탠바이로 동작시키면서 이 중 일부의 서버에게 문제가 발생하더라도 전체 서비스가 멈추는 사고를 방지하기 위해서 이루어진다. 로드 밸런싱은 데이터는 전체 데이터베이스 클러스터에 반영되어야 한다. 데이터베이스 서버가 몇 개이건 모두 공통된 최신 데이터를 가져야 한다는 것이고 이것은 데이터베이스 레플리케이션 을 통해 이루어진다. 데이터베이스에 전달되는 각종 요청이 데이터베이스 클러스터 내에 존재하는 여러 데이터베이스 서버에 골고루 전달되어서 실행되게 하는 분산 환경이 구성되어야 한다. 이를 로드밸런싱(Load-Balancing)이라 한다. 액티브-스탠바이로 구성된 데이터베이스 클러스터에서 액티브로 있던 데이터베이스 서버에 문제가 생겼을 때 스탠바이 서버들 중 1대가 액티브 서버의 역할을 해야 한다. 이것을 페일오버(Failover) 라 한다. 이외에도 데이터베이스에 전달되는 각종 요청을 데이터베이스 서버 1대가 처리하게 되면 처리 속도가 늦어지거나, 심한 경우에는 데이터베이스에 장애가 발생할 수도 있기 때문에 이런 요청을 데이터베이스 클러스터 전체가 나누어서 처리하게 됨으로써 전체적인 데이터베이스의 성능 향상과 안정화를 가져올 수 있다.[12]또한 네트워크 이중화 기술에서는 L4 로 드밸런싱 환경에서 각 노드를 액티브, 스탠바이로 설정하여 이중화를 구성할 수 있다.
문제점[편집]
- 다운 타임
- 절체가 수행되기 위해서는 장애 노드에서 서비스가 종료되어야 한다. 예를 들어 장애 노드의 IP주소를 회수하지 못한다면 대기 노드에서 그 IP를 서비스를 위해 부여해 줄 수가 없게 된다. 절체 진행 중 장애 노드에서 서비스를 내리고 자원을 회수하고, 스탠바이 서버에서 서비스를 올리는 동안의 서비스 다운 타임은 피할 수 없게 된다.
- 연쇄 장애
- 강력한 외부의 공격으로 웹서버가 다운되었다고 가정해 보자. 웹 서비스가 메일서버로 절체되었다면, 외부의 공격이 멈추지 않는 한 액티브-스탠바이 서버의 셧다운은 강제적으로 진행된다. 또다시 웹 서비스와 메일 서비스가 도메인 네임 서버로 절체된다면 도메인 네임 서비스의 장애를 피할 수 없게 되고 종국에는 모든 서비스가 중단되는 최악의 사태로 진행된다. 따라서 고가용성 클러스터로 서비스를 제공할 경우에는 이와 같은 연쇄 장애에 대비하여 대규모 서버 서비스시설 앞에 콘텐츠 필터링을 할 수 있는 장치를 우선적으로 설치하여야 한다. [13] 또한 데이터가 실시간 복제가 되는데 만약 실수로 반영된 데이터 또는 바이러스 감염된 파일도 복제가 되어 2번 서버의 시스템 또한 감염 및 전이 될 수 있다는 것이다. 이러한 단점을 보완하기 위해서는 백업 솔루션을 추가 도입을 해야 할 수 있다. 즉, 최종적으로 데이터 나 시스템이 훼손되었을 때는 해당 문제가 2대의 서버에서 동일하게 발생하므로, 시스템 및 데이터를 최종 보존을 하고 싶다면 백업을 고려 해야 한다. 서비스의 연속성을 보장하고 동시에 바이러스나 서버 오류의 데이터를 복제할 수도 있다.[9]
각주[편집]
- ↑ 김나래 기자, 〈마이크로소프트 깃허브, '마스터·슬레이브' 용어 없앤다〉, 《씨넷 코리아》, 2020-07-28
- ↑ , 〈마스터와 슬레이브의 차이점〉, 《bccrwp》, 2020-02-20
- ↑ 김석원, 〈액티브-슬레이브간의 멀티플렉싱 프로토콜〉, 《구글》, 1997-05-17
- ↑ 권택현, 〈고가용성을 위한 Master-Slave Architecture〉, 《미디엄》, 2020-01-31
- ↑ 알토란 , 〈HA 란?〉, 《네이버 블로그》, 2012-12-07
- ↑ pranker, 〈서버 클러스터,클러스터링,Active-standby 구조〉, 《티스토리》, 2017-03-09
- ↑ 7.0 7.1 Gunny, 〈HA(High Availability)란 무엇인가?〉, 《이글루스》, 2008-02-07
- ↑ 불곰, 〈서버 다중화(Active-Active, Active-Standby〉, 《티스토리》, 2016-08-25
- ↑ 9.0 9.1 jbyoon, 〈서버 이중화(HA) 솔루션에 대하여 (RoseHA)〉, 《쉐어드아이티》, 2017-07-24
- ↑ Steady_sp , 〈Linux_리눅스 DNS - 마스터 / 슬레이브〉, 《티스토리》, 2018-08-07
- ↑ 11.0 11.1 Nirsa, 〈(DNS) Master & Slave 개념 및 구축 방법〉, 《티스토리》, 2020-02-12
- ↑ 갈색왜성 , 〈PostgreSQL HA 구성 -1. Streaming Replication〉, 《티스토리》, 2018-09-27
- ↑ 에이원네트윅스 , 〈(AoneNetwork_ IDC Service) 이중화의 종류〉, 《에이윈네트윅스》, 2016-03-21
참고자료[편집]
- Gunny, 〈HA(High Availability)란 무엇인가?〉, 《이글루스》, 2008-02-07
- 알토란 , 〈HA 란?〉, 《네이버 블로그》, 2012-12-07
- 에이원네트윅스 , 〈(AoneNetwork_ IDC Service) 이중화의 종류〉, 《에이윈네트윅스》, 2016-03-21
- jbyoon, 〈서버 이중화(HA) 솔루션에 대하여 (RoseHA)〉, 《쉐어드아이티》, 2017-07-24
- 불곰, 〈서버 다중화(Active-Active, Active-Standby〉, 《티스토리》, 2016-08-25
- Steady_sp , 〈Linux_리눅스 DNS - 마스터 / 슬레이브〉, 《티스토리》, 2018-08-07
- 갈색왜성 , 〈PostgreSQL HA 구성 -1. Streaming Replication〉, 《티스토리》, 2018-09-27
- 권택현, 〈고가용성을 위한 Master-Slave Architecture〉, 《미디엄》, 2020-01-31
- Nirsa, 〈(DNS) Master & Slave 개념 및 구축 방법〉, 《티스토리》, 2020-02-12
- 〈마스터와 슬레이브의 차이점〉, 《bccrwp》, 2020-02-20
- 김나래 기자, 〈마이크로소프트 깃허브, '마스터·슬레이브' 용어 없앤다〉, 《씨넷 코리아》, 2020-07-28
같이 보기[편집]
