의견.png

액티브-스탠바이

위키원
Asadal (토론 | 기여)님의 2020년 8월 12일 (수) 00:17 판 (Asadal님이 액티브 스탠바이 문서를 액티브-스탠바이 문서로 이동했습니다)
이동: 둘러보기, 검색

액티브-스탠바이(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)과 같은 방법을 이용한다. 일부 가용성 전문가들은, 만약 어떤 시스템에 고 가용성이 요구된다면 그 시스템의 모든 부품들이 잘 설계되고 실제로 사용되기 전에 완전하게 시험되어야 한다고 강조한다. 예를 들어, 완전히 시험되지 않은 새로운 응용프로그램은 실제 사용 현장에서 자주 문제를 일으키는 주 요인이 될 가능성이 매우 높다.
  • 클러스터링(clustering)
클러스터링의 사전적 의미는 여러개가 모여서 하나를 구성하는 것을 뜻한다. 클러스터링은 네트워크 부하로 인한 장애를 대비하기 위한 방법이다. 데이터 통신 간에 장애를 대책하기위한 방법으로 고 가용성 방법에 속한다. 예를 들면 사용자 폭주에 대비해서, 웹서버를 10대로 운영하는 방법이 있다. 클러스터링은 하드웨어,소프트웨어 모두 구성가능하다. 서버장비 한대에 포트를 달리해서, 아파치를 여러개 띄운다면 소프트웨어 클러스터링이 된다. [5]
  • 다중화(Duplex)방식 : 액티브-스탠바이와 액티브-액티브 방식으로 나뉜다.
  • 액티브-스탠바이
    액티브-스탠바이 기술
다중화 방식을 활용한 가장 기본적인 기술이 액티브-스탠바이 기법이다. 한 서버가 액티브 상태로 서비스하고 있을 때, 스탠바이 서버는 전원은 켜 있고 운영체제까지만 올라와 있는 상태이다. 액티브 서버에 하드웨어 장애나 네트워크 장애, 혹은 프로세스 장애 등이 발생해 서비스를 못하게 되면, 스탠바이 서버에 있는 다중화 가술이 운영 서버의 장애 발생을 감지한다. 그리고 다중화 기술을 사용하여 자동으로 대기 서버에 모든 서비스를 올려준다. 즉, 단방향 페일오버를 구현하는 구성이다. 기존 액티브 서버에 접속했던 사용자는 접속이 끊어지겠지만, 재접속 시 바로 서비스를 받을 수 있다. 왜냐하면 스탠바이 서버가 모든 서비스를 대신하기 때문이다. 사용자 입장에서 보면 두 대의 서버 중에 어떤 서버가 서비스를 하는지는 보다느 올바른 서비스를 받기 원할 것이다. 서버 다중화를 구현하는 가장 큰 이유는 중단 없는 서비스를 공급하는 데 있다. 액티브-스탠바이의 가장 큰 장점은 단순함이라 할 수 있다. 구성하기도 쉽고, 관리자 입장에서도 운영하기 쉽다. 그래서 지금도 많은 기업의 시스템들이 이러한 구성으로 구현되고 있다. 활성과 대기 시스템의 사양을 동일하게 구성하는 경우도 있지만, 때에 따라서는 대기 시스템의 사양을 약간 낮게 구성하는 경우도 있다. 액티브 서버의 장애 발생 시, 스탠바이 서버가 서비스를 하면서 몇 시간 정도만 버텨 준다면, 이 시간에 원래의 액티브 서버를 수리할 수 있다. 그리고 서비스를 원래의 액티브 서버로 돌려놓을 수 있기 때문이다. 액티브-스탠바이 방식은 스탠바이의 구성에따라 역활이 달라진다.[6]
액티브-스탠바이 방식
구성단계 상세내용
핫(Hot) 스탠바이 스탠바이를 가동 후 즉시 이용가능한 구성
웜(Warm) 스탠바이 스탠바이를 가동 후 이용가능하게 하기 위해서 나름대로의 준비가 필요한 구성
콜드(Cold) 스탠바이 스탠바이측을 정지시켜 두는 구성
[7]
  • 액티브-액티브 구성
    액티브-액티브 기술
기업의 운영자 입장에서 봤을 때, 스탠바이 서버는 보통 때 아무 일도 안 하니 투자한 비용이 아깝다는 생각을 하게 된다. 어떠한 방식으로든지 스탠바이 사바도 보통 때 다른 업무를 서비스하기를 원한다. 그래서 나온 방식이 액티브-액티브 구성이다. 액티브-액티브 구성에서는 한 서버가 데이터베이스 서비스를 하고, 다른 서버는 웹 서비스를 제공하게 된다. 두 대의 서버가 각기 다른 서비스를 제공하는 것이다. 그러다가 데이터베이스 서버에 장애가 발생할 경우, 다중화 방식을 사용하여 웹 서버에서 데이터베이스 서비스를 할 수 있도록 한다. 즉, 웹 서버는 원래 자신이 하던 웹 서비스뿐만 아니라 데이터베이스 서비스까지 두 가지 일을 수행하게 된다. 이 경우에는 데이터베이스의 기본 구성만 설정하고 이루어진다. 반대로 웹 서비스에 장애가 발생했을 경우, 데이터베이스 서버에서 데이터베이스 서비스뿐만 아니라 웹 서비스까지 같이 수행하게 된다. 상호 대기 서버가 되는 구성이다. 그런데 이런 구성을 하고자 한다면 몇 가지 고려해야 할 사항이 있다. 우선 하나의 서버에서 데이터베이스와 웹 서비스 두 가지를 할 수 있도록 시스템 사양을 설계해야만 한다. 이렇게 설계하지 않고 하나의 서버에서 두 가지 서비스가 실행될 경우 서버가 부하를 견디지 못해 다운될 수도 있다. 그러면 두 가지 서비스 모두 장애가 발생해, 고 가용성 클러스터를 구축한 효과를 볼 수가 없다. 또, 하나의 서버에서 두 가지 서비스가 모두 실행될 수 있도록 환경 설정도 해줘야 한다. 액티브-액티브보다는 구성상 약간 복잡해지지만, 활용도나 가용성면에서는 가장좋다. [6]

기능

액티브-스탠바이 기술의 고 가용성은 가용성을 높이기 위한 문제해결방안으로 다음과 같은 기능을 반드시 갖추어야 한다. 첫째, 데이터 복제 기능은 기본적으로 고가용성으로 구성된 서버 중 1번 서버가 장애가 발생시, 2번 서버가 대상 서비스를 바로 서비스를 하기 위해서는 양쪽의 데이터는 항상 100% 동일 해야 하는 무결성을 보장 해야 한다. 이러게 데이터를 동일하게 맞추기 위해서는 데이터 복제 즉, 데이터 레플리케이션 기능이 반드시 필요하다. 두번째로 장애 감시 기능은 앞에서 설명한 서버 고가용성 구성시 1번 서버는 서비스 운영을 맞게 되며, 2번 서버는 1번 서버가 장애 발생시 서비스를 운영하기 위한 대기 생태로 구성이 된다. 이러한 구성은 액티브-스탠바이 고가용성 구성이라고 한다. 그렇다면, 장애 발생을 감지하기 위한 논리적인 소프트웨어 구성이 필요하다. 장애 발생은, 네트워크 장애, 운영체제 및 서비스 프로그램(프로세스) 장애, 서버 하드웨어 장애로 보통 나뉜다. 상기와 같은 장애를 감시할 수 있는 장애 감시 에이전트는 각 서버에 설치가 되며 이러한 에이전트는 1번 서버와 2번 서버에 각각 설치되어, 자기 자신의 서버의 장애 포인트 감시 및 크로스로 1번 서버는 2번 서버를 감시, 2번 서버는 1번 서버를 상호 감시(Heartbeat Check) 하여 고가용성을 유지하게 된다. 이러한 논리적인 구성은 서비스의 고가용성을 유지하기 위해 반드시 필요하며, 현재 운영중인 서비스 중인 1번 서버의 상기 문제 발생시 2번 서버로 서비스가 페일오버(자동전환) 되기 위해 필수적인 기능이다.[8]

  • 리눅스 설치
리눅스에서 액티브-스탠바이 기술을 참조하여서 도메인주소를 설정할 수있다. 도메인 네임서버는 도메인존 데이터 관리 측면에서 원본 존(zone) 데이터를 관리하는 액티브 네임서버와 이를 동기화해서 사용하는 스탠바이 네임서버로 구분된다. 존 데이터는 관리하는 도메인 영역 정보로 다양한 레코드 유형에 따른 데이터를 가지고 있으며 일반적으로 관리자가 설정한 존파일을 읽어 들여 존 데이터를 구성한다. 액티브에 있는 원본 존 데이터를 스탠바이가 동기화하는 작업을 존 전송이라 한다. 존 전송은 일반적으로 많은 존 데이터를 이동해야 하기 때문에 신뢰성 있는 전송을 보장하는 TCP 53번포트를 이용한다.액티브와 스탠바이 네임서버는 서로 동일한 기능을 수행하며 부하분산을 통해 안전성을 높이는 역할을 한다.
클라이언트 접근 설정
 도메인 네임 서버 액티브 서버 구축-192.168.100.100 서버
 #> yum -y install bind.x86_64 // 도메인 네임서버를 위한 bind파일설치
 vi /etc/named.conf //설정파일 
 #> vi /etc/named.rfc1912.zones //서비스할 zone 파일 등록. allow-update { 192.168.100.100; }; 를 입력 
서비스존 파일
 #>vi /var/named/nirsa.com

활용

  • 서비스의 복구
서비스 노드에서 장애가 발생하면 대기 노드가 서비스를 수행할 것이다. 장애 노드의 문제가 모두 해소되면 어떻게 원복할 것인가도 중요한 문제가 될 수 있다. 왜냐하면 계획된 절체라 하더라도 볼륨 처리와 IP 회수와 부여, 프로세스의 종료와 기동 등을 수행하면서 길 경우 몇 분, 빨라도 몇 초 정도의 다운타임 발생은 피할 수 없기 때문이다. 따라서 서비스 특성에 따라 곧바로 원복할 수도 있지만 대개 서비스가 쉬거나 사용자가 거의 없는 새벽 시간대 등을 활용해야 한다.
  • 액티브 서버의 업그레이드 작업
시스템을 운영하다 보면 업그레이드나 구성을 변경해야 할 때가 있을 수밖에 없게 된다. 단일 시스템으로 운영할 경우라면 그런 작업을 위해 어쩔 수 없이 서비스 다운을 사용자에게 공지하고 사용자가 적은 야간 시간대에 작업을 해야만 한다. 고가용성 클러스터 기술로 구성된 환경이라면 스탠바이 노드로 서비스를 절체하고 액티브 서버의 점검이나 업그레이드 작업을 수행할 수 있다. 고 가용성클러스터의 구성 목적은 장애 발생 시의 가용성을 확보하는 것이지만 계획된 시스템다운 시에도 클러스터는 유용하게 활용될 수 있다.

문제점

  • 다운타임
절체가 수행되기 위해서는 장애 노드에서 서비스가 종료되어야 한다. 예를 들어 장애 노드의 IP주소를를 회수하지 못한다면 대기 노드에서 그 IP를 서비스를 위해 부여해 줄 수가 없게 된다. 절체 진행 중 장애 노드에서 서비스를 내리고 자원을 회수하고, 스탠바이 서버 에서 서비스를 올리는 동안의 서비스 다운타임은 피할 수 없게 된다.
  • 연쇄 장애
강력한 외부의 공격으로 웹서버가 다운되었다고 가정해 보자. 웹 서비스가 메일서버로 절체되었다면, 외부의 공격이 멈추지 않는 한 액티브-스탠바이 서버의 셧다운은 강제적으로 진행 된다. 또다시 웹 서비스와 메일 서비스가 DNS 서버로 절체된다면 DNS 서비스의 장애를 피할 수 없게 되고 종국에는 모든 서비스가 중단되는 최악의 사태로 진행된다. 따라서 고가용성 클러스터로 서비스를 제공할 경우에는 이와 같은 연쇄 장애에 대비하여 서비스 팜 앞에 컨텐츠 필터링을 할 수 있는 장치를 우선적으로 설치하여야 한다. [9]



작동원리

논란

각주

  1. 김나래 기자, 〈마이크로소프트 깃허브, '마스터·슬레이브' 용어 없앤다〉, 《씨넷 코리아》, 2020-07-28
  2. , 〈마스터와 슬레이브의 차이점〉, 《bccrwp》, 2020-02-20
  3. 김석원, 〈액티브-슬레이브간의 멀티플렉싱 프로토콜〉, 《구글》, 1997-05-17
  4. 권택현, 〈고가용성을 위한 Master-Slave Architecture〉, 《미디엄》, 2020-01-31
  5. 알토란 , 〈HA 란?〉, 《네이버 블로그》, 2012-12-07
  6. 6.0 6.1 Gunny, 〈HA(High Availability)란 무엇인가?〉, 《이글루스》, 2008-02-07
  7. 불곰, 〈서버 다중화(Active-Active, Active-Standby〉, 《티스토리》, 2016-08-25
  8. jbyoon, 〈서버 이중화(HA) 솔루션에 대하여 (RoseHA)〉, 《쉐어드아이티》, 2017-07-24
  9. 에이원네트윅스 , 〈(AoneNetwork_ IDC Service) 이중화의 종류〉, 《에이윈네트윅스》, 2016-03-21

참고자료


같이 보기


  의견.png 이 액티브-스탠바이 문서는 하드웨어에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.