액티브-액티브

액티브-액티브(Active-Active)란 다중화 장비가 두 대 모두 활성화되어 동작하는 구성이다. 두 대가 모두 처리를 하기 때문에 액티브-스탠바이에 비하여 처리율이 높지만, 보통 설정 및 구성이 복잡해지며 한 대의 동작이 멈추었을 경우, 두 대의 처리량을 한대로 처리하기 때문에 리소스가 높아져 리소스에 대한 계획도 필요하다.

개요

소프트웨어 개발 호스팅 업체 마이크로소프트 산하 깃허브(GitHub)는 ‘블랙 리브스 매터(Black Lives Matter, 흑인 생명은 소중하다)’ 운동에 발맞춰 ‘마스터(master)’, ‘슬레이브(slave)’와 같은 코딩 언어를 없애는 중이다. 마스터와 슬레이브는 프로그래밍이나 서버 등 개발자들이 사용하는 용어 중 하나로, 주 작업(마스터)에 변형이 생길 때 보조 작업(슬레이브)이 가동되는 방식이다. 액티브와 스탠바이로도 쓰인다. 지난 목요일 냇 프리드먼(Nat Friedman) 깃허브 최고경영자는 유나 크래비츠(Una Kravets) 버슬 디지털 그룹(Bustle Digital Group) 제품 디자인 디렉터가 보낸 트윗에 답했다. 테크 커뮤니티에서 특정 용어를 다른 이름으로 바꾸는 조치를 취하기 시작하자는 제안이다. 특히 브랜치(Branch) 구조를 나타내는 마스터를 ‘메인(Main)’으로 바꾸자는 것이다. 이에 프리드먼은 “훌륭한 생각이며 우린 이미 작업중이다”고 답했다. 한 매체 이메일 인터뷰에서 깃허브 대변인은 "자사 사이트가 기본 브랜치명을 마스터로 하는 것에서 벗어나 새로운 이름을 쓰려고 한다"고 말했다. 그러면서 "사용자가 새로 생성하는 저장소(리파지토리: Repository)에 자기만의 브랜치 이름을 쉽게 선택할 수 있게 만든 것으로, 기존 저장소에서도 기본 브랜치명을 바꿀 수 있게 지침과 툴을 제공할 것"이라고 입장을 밝혔다. 웹서버는 오늘날의 정보 통신과 정보 인프라의 중심에 있으며, DNS 서버와 더불어 인터넷 서비스를 위한 핵심 서버이므로 이의 신뢰성과 무결성 향상을 위한 연구는 중요하다. 시스템의 신뢰성 향상을 위한 방법에는 여러 가지가 있지만 오류 발생을 사전에 완전히 배제하기란 거의 불가능하므로 주로 오류가 발생했을 때 이에 대처하는 결함 내성(fault tolerance)의 방법으로 시스템의 신뢰성을 향상시킨다. 일반적으로 시스템의 결함 내성을 위해서는 시스템의 중요 요소를 중복시켜 하나의 요소에 오류가 발생하더라도 중복된 다른 요소가 이를 대체하여 서비스를 계속 유지시키는 이중화 방식을 채택한다. 이중화(Duplication, Duplex) 방식은 어느 한 쪽만이 동작하다가 장애 발생 시 다른 한쪽이 동작을 이어가는데, 그 방식으로 쓰이는 것이 액티브-스탠바이 이중화와 액티브-액티브이다.

특징

액티브-스탠바이 이중화는 마스터-슬레이브 형태의 이중화로 평상시에는 1차 웹서버가 메인 서버로서 서비스를 제공하고, 2차 웹서버는 1차 서버의 장애를 대비한 보조 서버이다. 2차 웹서버는 평상시에 메인 서버로부터 주기적으로 정보를 받아 1차 웹서버와 동일한 상태를 유지시킨다. 기존의 마스터-슬레이브 형태의 이중화 방식은 마스터와 슬레이브의 설정이 별개이기 때문에 문제 발생 시 서비스 복구가 지연될 수 있고, 파일들의 동기화 지연으로 인한 문제가 잦다. 그래서 1, 2차 웹서버를 동일하게 구성하고 디렉터리 경로 내의 모든 파일을 아르싱크(rsync)로 동기화시키는 액티브-액티브 방식의 이중화가 더 적절하다. 액티브-액티브 방식은 고속의 채널을 통해 동작 계열과 대기 계열이 완전 동일 상태를 유지하고 문제 발생 시 빠른 계열 변경(fail-over)이 가능하고, 빠른 서비스 응답과 로드밸런싱을 지원하는 웹서버 이중화 방법이다. 1, 2차 웹서버는 항상 동일 상태를 유지하며 실행 가능한 상태에 있으며, 임의의 웹서버에 장애가 발생하더라도 또 다른 웹서버에 의해 서비스가 계속 유지되어 사용자는 웹서버 장애를 전혀 인식하지 못한 상태에서 계속 서비스를 받을 수 있게 한다. 액티브-액티브 방식의 이중화는 클라이언트의 서비스 요청 시에 서비스 요청을 받아들이는 로드밸런싱 서버가 다이렉트 라우팅에 의해 1, 2차 웹서버를 교대로 실행하여 부하를 분산하고, 빠른 서비스 응답이 이루어진다. 이는 마스터 형태로 동작하는 2대의 웹서버를 네트워크 적으로 분리된 곳에 분산 배치하여 실행한다.

장단점

액티브-액티브의 장점 중 하나는 시스템 다운 시간이 짧다는 것이다. 복수의 데이터베이스 서버가 동시에 동작하고 있어서 한 대가 다운되어 동작 불능이 되더라도 남은 서버가 처리를 계속하기 때문에 시스템이 정지하는 것을 방지할 수 있다. 이것은 웹서버나 애플리케이션 서버의 클러스터링으로 얻을 수 있는 장점과 같다. 그리고 성능이 좋다는 장점이 있다. 데이터베이스 서버 대수가 증가하면 동시에 가동하는 CPU나 메모리도 증가하기 때문에 성능도 향상될 수 있다. 단, 저장소가 병목(버틀넥)이 되기 때문에 생각한 만큼 성능이 향상되지 않는 경우도 있다. 단점으로는 몇 번씩 저장소가 병목 되는 경우가 발생한다는 점이다. 복수의 노드에서 각 노드는 모두 서비스를 제공하다가 장애 노드가 발생하면 그 서비스를 다른 노드에서 병행 처리해 주는, 독립 서비스 & 상호 대기 방식이다. 예를 들면 노드 1은 웹서버로, 노드 2는 메일 서버로 사용하다가 노드 1에 장애가 발생하면 노드 2는 웹서버와 메일 서버를 함께 수행하다가 노드 1의 장애가 해소되면 서비스를 다시 하나씩 나누어 수행한다. 모든 노드는 서비스 노드이면서 동시에 대기 노드 역할을 겸한다. 모든 노드는 대기 서비스를 실제로 서비스할 경우에 장애 노드가 복구될 때까지 부하를 감당할 수 있는 최소한의 리소스를 확보하여야 한다. 통상 이 방식에서 오토 페일 백 기능은 사용하지 않는다. 모든 노드에서 서비스가 진행되기 때문에 장애 포인트가 많고 절체 후에도 부하를 감당하지 못해 다운될 수 있는 단점이 있지만 모든 시스템을 서비스에 활용할 수 있다는 경제적 장점도 있다. 무거운 서비스(DB)와 가벼운 서비스(웹, DNS)를 묶어서 구성하면 특히 효과적이다.

구성

액티브-액티브(SAN)

액티브-액티브(NFS)

• 액티브-액티브(SAN)

SAN(Storage Area Network)을 이용한 스토리지를 구축한 형태이다. SAN은 공유가 불가능하므로 사용자가 각 서버별로 고루 분산되도록 구성이 되고, 사용자는 자신이 속한 서버에서만 서비스를 이용할 수 있다. L4에 의해 랜덤하게 서버에 접근한 후 사용자 인증 후 자신의 메일 서버로 리다이렉트 되는 형태이다. 사용자의 호스트가 지정되므로 경우에 따라 한쪽 서버로 사용자가 몰리는 경우가 생길 수 있으므로, 사용자 생성 시 고루 분포되도록 유의해야 한다. 장애가 발생하면 클러스터링(Clustering) SW에 의해 감지가 되고 자동으로 서비스 절체 및 이전이 이루어진다. 클러스터링 SW 중 하나인 HACMP(고가용성 솔루션, High Availability Clustering Multi Processing)의 방법을 예로 들자면, 서버#1에 장애가 발생하면 HACMP의 자동 감지에 의해 서버#1의 IP, DISK 등의 정보가 서버#2로 이전되어 서버#2에서 서버#1의 서비스를 대신 수행함으로써 시스템 장애 시간을 최소로 줄일 수 있다. 외부에서 보면 2대로 서비스하는 것처럼 보이지만 실제로는 1대로 서비스하는 것이다. 이 방법은 클러스터링 SW, SAN 관련 장비로 인해 많은 비용이 필요하지만 높은 수준의 안정성을 확보할 수 있으므로 사용자가 많고, 안정성을 우선하는 곳에서 추천하는 방법이다.

• 액티브-액티브(NFS)

NFS(Network File System), NAS(Network Attached Storage)를 이용한 스토리지를 구축한 형태이다. 공유가 가능한 형태로서 모든 서버는 동일 스토리지를 공유하고 동일한 서비스를 제공하므로 사용자는 어느 서버에서든 서비스 이용이 가능하다. L4에 의해 사용자를 로드밸런싱 해주며 사용자 분산은 1/n(서버 대수)에 가깝다. 사용자량이 폭주할 때는 메일 SW가 설치된 서버를 추가하는 것으로 간단히 증설할 수 있다. L4에 의해 서버#1에 장애가 감지되면 L4는 더 이상 사용자를 서버#1로 연결하지 않는다. 서버#1의 장애가 복구되기 전까지 서버#2 또는 다른 메일 서버들에 의해 서비스된다. 이때의 분산은 1/(n-1)에 가까워진다. 서버에 문제가 있어서 며칠 동안 AS를 받아야 하는 상황이라도 문제없이 서비스된다. 좀 더 여유가 된다면 그동안 예비 서버를 추가하므로 예전과 동일한 수준의 서비스를 할 수도 있다. L4에 의해 장애가 감지되므로 즉각적인 페일오버가 이루어지므로 서비스 장애 시간을 매우 작게 줄일 수 있다. SAN에 비해 매우 저렴한 비용으로 높은 수준의 안정성을 얻을 수 있는 방법으로 메일 시스템의 이중화로 적극 추천한다. 네트워크 기반으로 공유하는 방식이기 때문에 보안에 취약해질 수 있으므로, 서비스 네트워크와 NAS 네트워크를 분리하는 것도 좋은 방법이다.

메일 시스템을 이중화하는 방법으로는 매우 저렴한 방법에서부터 값비싼 방법까지 다양한 이중화 방법이 있다. 이중화를 하려는 목적은 단 한 가지이다. 메일 시스템을 안정적으로 운영하여 메일 시스템 장애로 인해 비즈니스가 피해를 입지 않게 하기 위한 것이다. 단 몇 시간 또는 며칠 동안 메일에 문제가 발생하여 비즈니스에 큰 영향을 끼쳐 몇 백만 또는 몇 천만의 손해가 난 후에는 대처할 방법이 없다. 미리 메일 시스템을 이중화하여 아무 걱정 없이 메일을 사용하는 것이 이상적이다. 이중화 방법은 사이트의 규모나 비용에 의해 달라지니, 그 부분을 유의하고 전문가에게 문의를 통하여 해법을 요구하는 것이 가장 효율적인 방법일 것이다.

비교

웹서버의 이중화를 위한 방법 중 하나로써 리눅스 가상 서버가 존재하며, 이중화 시스템은 로드밸런싱 서버, 웹서버 1, 웹서버 2로 구성된다. 웹서버를 웹서버 1과 웹서버 2로 이중화하고, 로드밸런싱 서버는 사용자의 서비스 요청을 받아들여 라운드로빈 방식으로 스케줄링하여 웹서버 1과 웹서버 2가 교대로 실행되도록 할 수 있다. 액티브-액티브 방식의 웹서버 이중화를 위해 아르싱크와 크론탭(crontab)을 이용하여 웹서버 간에 주기적인 복사가 이루어지도록 하여 동일한 상태를 유지시킨다. 평상시에는 두 대의 웹서버가 동시에 액티브 상태로 부하를 나누어 교대로 실행하고, 두 대의 웹서버 중 임의의 웹서버에 장애가 생겨 서비스가 어렵게 되면 나머지 웹서버가 서비스를 유지하여 이용자는 웹서버 장애를 전혀 인지하지 못한 상태에서 계속 서비스를 받을 수 있다. 웹서버 이중화를 위한 기존 액티브-스탠바이 방식과 본 연구의 액티브-액티브 방식의 비교는 아래와 같다.

웹서버 이중화 방식의 비교

구분 ＼ 방식	액티브-스탠바이	액티브-액티브
동작방식	마스터-슬레이브 형태 장애 대비 보조 서버	동시에 교대로 실행
절체지연	테이크 오버 지연	테이크 오버 지연 없음
부하분산	부하 집중	부하 분산
응답시간	서비스 응답 지연	서비스 응답 빠름
동 기 화	Tar 방식, 동기화 지연	아르싱크 방식, 동기화 지연 없음
연 속 성	서비스 연속성 보통	서비스 연속성 좋음

액티브-스탠바이 구성에서 대기 노드의 가동 시간은 항상 가동되어 있어도 사실상 제로인 반면, 두 노드의 액티브-액티브 구성 용량은 일반적으로 최대 50%까지 사용될 수 있다. 장애 발생 시 한 노드가 전체 로드를 수행할 수 있어야 하기 때문에 각 노드, 즉 액티브-액티브 모드에서 활성 노드에 50 % 이상을 사용하면 한 활성 노드에서 장애가 발생할 경우 성능이 저하된다. 액티브-액티브 구성에서 한 경로의 장애는 서비스 중단으로 이어지지 않지만 액티브-스탠바이 구성의 경우 장애 식별 시간 및 활성 노드에서 대기 노드로의 이동 시간에 따라 다를 수 있다. 예상치 못한 시나리오의 경우 액티브-액티브 구성을 임시 처리량 및 용량 확장으로 사용할 수 있지만 장애 발생 시 성능이 저하된다. 액티브-스탠바이 모드에서는 순간적인 상황에서도 이러한 옵션을 사용할 수 없다. 액티브-액티브 구성에 이러한 용량 확장 이점이 있지만 액티브-스탠바이 구성에서는 필요하지 않은 노드 앞에 로드밸런싱 방법이 있어야 한다. 액티브-스탠바이 방법은 경로와 노드를 동시에 활성 상태로 유지하는 액티브-액티브 방법과 비교하여 항상 하나의 경로 만 활성화되므로 네트워크 문제를 덜 복잡하고 해결하기 쉽다. 액티브-액티브 구성은 일반적으로 로드밸런싱을 지원하는 반면 액티브-스탠바이 구성에서는 그러한 솔루션을 사용할 수 없다. 액티브-액티브 구성은 순간적인 용량 확장을 허용하지만 일반적으로 액티브-스탠바이 구성보다 네트워크에 추가적인 복잡성을 제공한다. 액티브-액티브 구성에서 두 경로가 모두 활성화되어 있기 때문에 장애가 발생한 경우 중단 시간이 거의 0이 되고, 액티브-스탠바이 구성의 경우에는 더 높아질 수 있다.

다중화 구조

다중화한 경우의 주의할 점은 같은 데이터가 여러 개 존재하는 것이므로 어떤 데이터가 올바른 것인지 또는 가장 최신의 것인지를 제대로 관리해야 한다는 것이다. 또한 여러 개의 데이터가 정확하게 일치하고 있는 상태를 유지해야만 한다. 일반적으로 스토리지를 공유하는 공유 디스크 방식은 하나의 스토리지를 공유하며 대개는 전용 스토리지 기기를 이용한다. 공유 디스크 방식은 스토리지를 공유하기 때문에 정합성에 대해 특별히 문제 될 것이 없다. 다만, 공유 디스크 방식 자체를 다중화 해야 한다는 과제가 남는다. 공유 디스크 방식 기능이 있는 스토리지 기기는 대체로 값비싼 기기들이다.

• 공유 디스크(Shared Disk)

액티브-액티브 구성의 데이터베이스는 저장소 부분에 병목 되는 경우가 있다. 이것은 복수의 서버가 1대의 디스크(저장소)를 공유하도록 구성되었기 때문이다. 이렇게 복수의 서버가 1대의 디스크를 사용하는 구성을 공유 디스크라고 한다. 공유 디스크 타입의 액티브-액티브 구성은 데이터베이스 서버를 늘려도 무한으로 처리율이 향상되지 않는다. 이것은 저장소가 공유 자원이라서 쉽게 늘리기 어렵고 데이터베이스 서버 대수가 증가할수록 데이터베이스 서버 간의 정보 공유를 위한 오버헤드가 크기 때문이다. 이 단점을 극복하기 위한 아키텍처로 고안된 것이 'Shared Nothing'이다.

• Shared Nothing

Shared Nothing은 문자 그대로 '아무것도 공유하지 않는다'란 의미로 네트워크 이외의 자원을 모두 분리하는 방식이다. 이 아키텍처는 서버와 저장소의 세트를 늘리면 병렬처리 때문에 선형적으로 성능이 향상되는 장점이 있다. Shared Nothing 구성은 구글이 유효성을 증명했고, 구글은 자사가 개발한 Shared Nothing 구조를 '샤딩(Sharding)'이라고 부른다. Shared Nothing의 장점은 비용 대비 성능이 좋다는 것이다. 같은 구성의 데이터베이스 서버를 횡으로 나열하기 때문에 구조가 간단하며 원칙적으로 데이터베이스 서버 수에 비례해서 저장소가 늘어난다. 단점은 저장소를 공유하지 않는다. 즉, 각각의 데이터베이스 서버가 동일한 1개의 데이터에 접근할 수 것이다. 단점을 해결하기 위한 방법은 데이터베이스 서버 하나가 다운되었을 때 다른 데이터베이스 서버가 이를 이어받아 계속 처리할 수 있게 하는 '커버링(Covering)' 구성 등의 방법을 고려해야 한다. Shared Nothing 방식의 경우는 스토리지 간 통신을 해 데이터 정합성을 확보한다. 이것을 레플리케이션이라 하며, 레플리케이션의 데이터 송신 측을 마스터, 데이터 수신 측을 슬레이브라고 한다. 멀티 마스터(multi-master)라고 하여 각각이 마스터와 슬레이브의 역할을 모두 갖는 방식도 있지만 문제가 많이 발생하기 때문에 잘 사용하지 않는다.

• 레플리케이션(Replication)

액티브-액티브, 액티브-스탠바이 클러스터 구성에서는 서버 부분은 다중화할 수 있어도 저장소 부분은 다중화할 수 없어서 데이터를 다중화하지 않는 공통적인 단점이 있다. 저장소가 부서질 경우에는 데이터를 잃게 된다. 이런 상황에 대응하기 위한 클러스터 구성이 레플리케이션이다. 이는 데이터베이스 서버와 저장소 세트를 복수로 준비하는 것을 말한다. 레플리케이션은 데이터베이스 서버와 저장소가 동시에 사용 불능일 때, 서비스를 계속할 수 있도록 해주는 매우 가용성이 높은 아키텍처이다. 이 견고함 덕택에 재해 대책(재난 복구 계획)으로 이용되는 경우도 있다. 예를 들어, 서울의 데이터 센터가 파괴되어도 부산의 데이터 센터가 무사하다면 처리를 계속할 수 있다. 레플리케이션에서 주의할 점은 액티브 측 저장소의 데이터는 항상 사용자로부터 갱신된다는 점이다. 이 때문에 스탠바이 측 데이터에도 갱신을 반영하여 최신화(동기화) 하지 않으면 액티브 측과의 데이터 정합성을 유지할 수 없다. 동기식 레플리케이션은 오버헤드가 큰(동기 처리에 따른 성능 저하의 정도가 큰) 대신 데이터의 정합성을 확보하기 좋은 반면, 비동기식은 데이터 손실이 발생할 수도 있지만 성능 저하의 정도는 작다. 스토리지에 RDBMS(관계 데이터베이스 관리 시스템)를 사용할 경우, MySQL이나 PostgreSQL은 표준으로서 비동기 레플리케이션에 대응하고 있기 때문에 자주 사용된다. 비동기 방식이라고는 하지만 대부분 수 초에서 수십 초 사이에는 반영이 완료된다. RDBMS에 데이터 손실을 피하는 레플리케이션 방법이 구현되었다. MySQL에서는 5.5 버전부터 준 동기식 레플리케이션이라는 명칭으로, PostgreSQL에서는 9.1 버전부터 동기식 레플리케이션이라는 명칭으로 구현되고 있다. 명칭은 다르지만 구현하고 있는 기능은 거의 동일하다. 이것은 데이터 손실은 없지만 스탠바이 측의 데이터 반영까지는 동기적이지 않은 방식이다. 데이터 보호의 관점에서는 동기식 또는 준 동기식이 필수지만, 부분적으로 비동기식을 조합하여 전체 성능을 높이는 방법이 많다.

전망

DR 환경은 재해나 장애 발생 시에 가장 신속하고 효율적인 방법으로 대처할 수 있어야 한다. 네트워크 인프라 측면에서는 간소화된 방식으로 구성하면서도 서비스 확장이나 축소가 필요할 경우 최대한 신속하고 편리하게 대응할 수 있는 방안이 필요하다. 각 장비는 용도와 용량에 맞게 구성하고 해당 장비의 처리량을 극대화해 장비 자체의 효율성도 최대화할 수 있어야 한다. 다양한 공격·위협에 대응할 수 있는 보안성을 확보해야 하며, 손쉬운 모니터링으로 여러 상황에 대한 인프라 가시성을 보장하는 것도 중요하다. 애플리케이션 서비스의 최적의 성능 구현도 필수적이다. ‘액티브-액티브’ 데이터 센터를 구현하기 위한 인프라 구조 차원에서 제시되는 방식으로는 관리 네트워크를 별도로 운영하고, 서비스존을 1~2차로 구분해 다 계층 아키텍처를 구성하는 것을 꼽을 수 있다. 이 경우 자칫 발생할 수 있는 위험성을 낮추고 분산할 수 있다. 다이내믹 데이터 센터 구축 방안으로 이와 같은 구성을 제안하고 있는 F5네트웍스의 신은수 차장은 “우리나라는 데이터 센터 내 장비를 관리할 때 별도의 관리 네트워크를 사용하지 않고 서비스 망을 통해 수행하고 있다. 이 경우 서비스 장애가 일어나면 관리자조차도 장비에 접속이 불가능한 일이 발생한다”라며, “장비 설정이나 방화벽 정책을 변경하는 전용 관리 네트워크를 별도 구성하면, 장비의 관리 인터페이스에서 취약점이 발생하더라도 이용자들이 접속하는 서비스 망과는 별개여서 안전하다”라고 말했다. 이어 신 차장은 “1~2차 서비스존 구성과 같은 다 계층 구조로 인프라를 설계하게 되면 대용량 공격과 CPU를 고갈하는 다양한 방식의 분산서비스 거부(DDoS) 공격 위협에 효과적으로 대응할 수 있게 된다”라고 설명했다. 예를 들어 1차 서비스존에서는 대용량의 네트워크 DDoS 공격을 걸러내고 이후 2차 서비스존으로 유입되는 애플리케이션 공격이나 악성코드, 지능형 공격을 차단할 수 있다. ‘액티브-액티브’ 데이터 센터 구성에서는 데이터 센터 분산을 수행하는 글로벌 서비스로드밸런싱(GSLB) 구현이 필수적으로 요구된다.

인프라나 시스템의 상태를 확인해 정상적인 데이터 센터나 클라우드 환경으로 사용자 트래픽을 자동 연결해 줘 서비스 장애나 재해 상황에서 신속한 트래픽 처리 및 장애 대응이 가능하다. 만일 GSLB를 사용하지 않을 경우엔 수작업으로 이 같은 기능을 대체하기도 한다. GSLB 장비는 데이터 센터 간 글로벌 서버 부하분산과 더불어 DNS 보호와 안정적인 서비스도 보장하는 기능도 제공한다. 이 같은 GSLB 장비는 주로 애플리케이션 딜리버리 컨트롤러(ADC) 업체들이 관련 장비를 공급하고 있다. 이와 함께 웹, 애플리케이션, 데이터베이스의 3티어 계층별로 네트워크단의 데이터 센터 간 안정적인 우회 및 확장 경로, 트래픽 가속도 보장돼야 한다. 왠(WAN) 경로는 전송망과 전용선으로 쉽게 연결이 가능하지만 데이터베이스나 스토리지 단 ‘액티브-액티브’ 구성에는 네트워크 L2 확장 프로토콜 지원이 필요하다. L2 확장 프로토콜은 VxLAN이나 NVGRE 등이 대표적이다. 이 기능은 L3 스위치나 L4 스위치에서 지원한다. 모든 데이터 센터 스위치가 L2 확장 프로토콜을 기본으로 지원하면 고심할 필요가 없겠지만 주로 대형 장비만 지원되는 등 모든 모델별로 지원하지 않는 상황이다. 이로 인해 필요한 용량을 뛰어넘는 네트워크 장비 투자가 이뤄질 수 있다는 지적도 나온다. 이 경우, 투자 효과나 효율성을 증대시키기 위해 왠 구간 가속 기능과 L2 확장 프로토콜을 이용한 터널링 기능이 동시에 지원되는 L4-L7 ADC 장비를 활용을 고려해보는 것도 방안이다. 이 같은 기능과 더불어 데이터 센터에서 요구가 커지고 있는 자동화된 관리를 구현하기 위해서는 장비에서 REST API 통해 오케스트레이션 툴과 연동하는 것도 중요하다. 네트워크 가상화나 소프트웨어 정의네트워킹(SDN) 기술 도입을 고려해볼 수도 있다. 초기 시장이기 때문에 신기술을 활용하는 것을 꺼리는 경우에는 이들 기능을 지원하는 기존 장비를 찾으면 된다. 신은수 차장은 “‘액티브-액티브’ 데이터 센터를 구현하기 위해서는 여러 데이터 센터를 넘나들면서 인프라 환경 내에서 어떠한 경로로도 사다리를 타고 다닐 수 있어야 한다”라며 “가장 효율적인 방법으로 가용성과 보안, 애플리케이션 성능 가속, 가시성 확보, 자동화까지 구현되면서도 클라우드 확장까지 보장되는 인프라를 구축하는 것이 중요하다”라고 강조했다.

참고자료

• 도전진, 〈이중화 ( Active-Active , Active-Stand_by )〉, 《네이버 블로그》, 2012-07-10
• 〈이중화기술 - 가용성과 경제성〉, 《티스토리》, 2012-12-07
• 최재원, 〈[file:///C:/Users/envy/Downloads/HOJBC0_2014_v18n1_63.pdf 로드 밸런싱 Active-Active 방식의 웹 서버 이중화 구축 및 결함내성 시험]〉, 《한국정보통신학회논문지》, 2014
• 이유지, 〈‘액티브-액티브’ 데이터센터 효과적으로 구축하려면…“네트워크 아키텍처 중요”〉, 《디지털데일리》, 2014-11-03
• 불곰, 〈서버 다중화 (Active-Active, Active-Standby〉, 《티스토리》, 2016-08-25
• Milhouse, 〈데이터베이스(데이터베이스(DB)-클러스터링(Clustering))〉, 《티스토리》, 2017-08-18
• Milhouse, 〈데이터베이스(데이터베이스(DB)의 아키텍처-Shared Disk & Shared Nothing)〉, 《티스토리》, 2017-08-22
• Milhouse, 〈데이터베이스(데이버베이스(DB)의 아키텍처-리플리케이션)〉, 《티스토리》, 2017-08-22
• 〈데이터베이스(데이터베이스(DB)-클러스터링(Clustering))〉, 《bccrwp》, 2020-02-21
• 김나래 기자, 〈마이크로소프트 깃허브, '마스터·슬레이브' 용어 없앤다〉, 《씨넷 코리아》, 2020-07-28

같이 보기

• 액티브
• 스탠바이
• 액티브-스탠바이
• 마스터
• 슬레이브
• 마스터-슬레이브

이 액티브-액티브 문서는 하드웨어에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.

개발 : 프로그래밍, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어 □■⊕, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 하드웨어 L2 스위치 • L3 스위치 • L4 스위치 • L7 스위치 • PTL • VTL • 가상 인터넷데이터센터(VIDC) • 나스(NAS) • 네트워크 스위치 • 다스(DAS) • 라우터 • 랙 • 맥주소 • 모뎀 • 방화벽 • 백본 • 백업장비 • 부대시설 • 브릿지 • 브릿지 테이블 • 샌 • 서버 • 스토리지 • 웹방화벽 • 웹스토리지 • 유니버설 플래시 스토리지 • 유피에스(UPS) • 이더넷 • 인터넷데이터센터(IDC) • 인프라 • 전산실 • 캐리어 이더넷 • 컴퓨터 클러스터 • 컴프레서 • 케이블 • 케이지 • 클라우드 스토리지 • 파이버 채널 • 펌웨어 • 하드웨어 • 항온항습기 하드웨어 관리 CDC • CDN • 가상머신 • 가상화 • 가용성 • 고가용성(HA) • 대역폭 • 라우팅 • 랙 • 레이드 • 레플리케이션 • 로드밸런싱 • 마스터 • 마스터-슬레이브 • 미러링 • 미러사이트 • 백업 • 백업사이트 • 복구 • 볼팅 • 부하 • 비즈니스 연속성(BC) • 서버 가상화 • 소산백업 • 스탠바이 • 스토리지 가상화 • 슬레이브 • 액티브 • 액티브-스탠바이 • 액티브-액티브 • 오프라인 백업 • 웜사이트 • 장애 • 장애복구 • 재해복구(DR) • 재해복구센터 • 지속적 데이터 보호(CDP) • 콜드사이트 • 페일오버 • 프로비저닝 • 프록시 • 핫사이트 • 핫스왑 네트워크 ADSL • AP • DSL • VPN • 게이트웨이 • 경로 • 공유기 • 네트워크 • 네트워크 가상화 • 네트워크 관리 시스템(NMS) • 네트워크 기기 • 네트워크 모니터링 • 네트워크 인터페이스 • 네트워크 장비 • 네트워크 케이블 • 네트워크 트래픽 • 네트워크 트래픽 모니터링 장비 • 라우터 • 랜(LAN) • 랜카드 • 리피터 • 망 • 무선 • 무선공유기 • 무선네트워크 • 무선랜 • 무선랜카드 • 무선브릿지 • 브릿지 • 수동 광통신망 • 아이피(IP) • 왠(WAN) • 유선 • 유선랜 • 유무선 • 인터넷공유기 • 전산망 • 전용회선 • 정보통신망 • 최단경로 • 컴퓨터 네트워크 • 터미널 • 통신 네트워크 • 통신회선 • 허브 • 호스트 • 홉 • 회선 통신 1세대 이동통신 • 2세대 이동통신 • 3세대 이동통신 • 4G(4세대 이동통신) • 5G(5세대 이동통신) • 6G • CDMA • GSM • IMT2000 • LTE • PC통신 • WCDMA • 공중전화 • 광선 • 광섬유 • 광케이블 • 기지국 • 디지털 • 모스부호 • 무선단말기 • 무선전화 • 무선통신 • 문자메시지 • 방송 • 방송통신 • 변조 • 보이스톡 • 브로드밴드 • 비디오폰 • 송신기 • 수신기 • 스마트폰 • 스타링크 • 아날로그 • 영상통화 • 와이맥스 • 와이브로 • 와이파이 • 유무선통신 • 유선전화 • 유선통신 • 음성 • 음성통화 • 이동통신 • 일반전화 • 전기통신번호 • 전기통신사업 • 전달 매개체 • 전신 • 전파 • 전화 • 전화기 • 점대점 통신 • 주파수 • 주파수 간섭 • 채널 • 초고속 인터넷 • 카폰 • 커버리지 • 통신 • 통신장비 • 페이스톡 • 프로토콜 • 헤르츠 • 휴대전화 위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반