스위치와 라우터는 장애에 대비해 어떻게 이중화할까

한 대가 멈춰도 어떤 업무는 계속되어야 할까 ↑

이중화는 장비 고장이나 정비 중에도 필요한 업무를 계속하기 위해 구성합니다. 장비를 두 대 두기에 앞서, 무엇이 고장 나도 어떤 업무를 유지할지 먼저 정해야 합니다.

작은 사무실에서는 예비 장비를 교체하는 시간을 허용할 수 있었습니다. 반면 PC-A가 내부 서버 App-S와 계속 거래해야 한다면 교체를 기다리는 방식이 맞지 않을 수 있습니다. 새 연결의 짧은 실패를 허용하는지, 진행 중인 작업을 잃으면 안 되는지도 업무 담당자와 구별해서 정합니다.

어떤 장애에 대비할지도 나누어 봅니다. 케이블 한 가닥이 끊기는 경우, 스위치 한 대의 전원이 꺼지는 경우, 라우터의 상향 경로가 끊기는 경우는 사용할 수 없게 되는 기능과 경로가 다릅니다. 장비가 고장 난 때뿐 아니라 계획된 소프트웨어 정비 중에도 업무를 계속해야 할 수 있습니다. 설계서에는 장애별로 멈추는 기능과 계속 동작해야 할 기능을 나란히 적습니다.

두 계층 사례의 A1은 D1·D2에 각각 L3로 연결됩니다. D1이 사라져도 D2를 통해 서버로 갈 수 있도록 설계하지만, PC-A가 A1에만 연결돼 있다면 A1 고장 때의 접속 단절은 막을 수 없습니다. 도면에는 D1 고장 때 남는 경로와 A1 고장 때 끊기는 단말을 함께 표시합니다. 그래야 두 업링크로 어느 장애까지 대비할 수 있는지 알 수 있습니다.

두 장비가 같은 전원과 관로에 의존하면 전원 중단이나 관로 손상 때 함께 멈출 수 있습니다. 장애 범위 설계에서 확인한 의존성을 여기에서도 유지합니다. 개별 장비의 대체와 공통 원인의 분리는 서로 다른 준비이며, 한쪽을 시험했다고 다른 쪽까지 확인한 것은 아닙니다.

같은 이중 상향 구성에서도 고장 난 위치에 따라 결과가 다릅니다. 왼쪽은 D1이 멈춘 경우이고, 오른쪽은 PC-A가 유일하게 연결된 A1이 멈춘 경우입니다. 상위에 장비가 남아 있다는 사실만으로 PC-A의 접속까지 유지되지는 않습니다.

스위치 두 대와 케이블 두 개는 무엇이 다를까 ↑

링크 이중화는 연결 하나의 실패를, 장비 이중화는 장비가 제공하던 기능의 실패를 다룹니다. 두 케이블을 같은 스위치에 연결했다면 그 스위치가 꺼질 때 두 경로를 모두 사용할 수 없게 됩니다.

두 스위치 사이의 여러 링크를 EtherChannel로 묶으면 구성 링크 하나가 끊겨도 남은 링크로 데이터를 보낼 수 있습니다. 그러나 남는 용량은 줄고, 어떤 흐름이 어느 링크를 쓰는지도 달라집니다. 링크의 합계와 단일 흐름의 속도는 링크 집성 글에서 설명한 조건 그대로입니다.

연결 상대가 독립된 두 스위치라면 이야기가 달라집니다. 두 장비가 하나의 논리 상대처럼 동작하도록 지원되는 스택이나 멀티섀시 방식이 있어야 그 조건에 맞는 링크 집성을 설계할 수 있습니다. 아무 스위치 두 대에 케이블을 나눠 꽂고 LACP를 켠다고 자동으로 하나의 묶음이 되지는 않습니다.

독립 장비를 L2 경로로 연결한 구성에서는 STP가 루프를 막기 위해 일부 경로의 전달을 막을 수 있습니다. 대체 경로가 있다는 사실과 평상시 두 링크를 모두 이용한다는 사실을 구별합니다. 반면 두 계층 사례의 L3 업링크는 STP가 아니라 라우팅으로 경로를 선택합니다. 같은 대체 경로라도 L2 구성과 L3 구성의 동작을 구분해서 보아야 합니다.

스택도 끊어진 단말 케이블을 다른 포트로 옮겨 주지는 않습니다. A1에만 연결된 PC-A는 A1 전원을 잃으면 물리 접속을 잃습니다. A2에 연결된 단말과 업링크가 정상이어도 PC-A는 통신할 수 없는 것입니다. 중요한 단말 자체의 대체 접속이 필요한지도 별도 요구로 정해야 합니다.

시험표에는 케이블 단절, 스위치 고장, 스택 연결 단절을 각각 다른 행으로 나눕니다. 각 시험에서 단말 포트, AP 전원, 상향 경로, 관리 접속이 어떻게 되는지 확인합니다. 제품이 제공하는 제어 전환과 상태 유지의 범위는 실제 모델·소프트웨어·연결 방식에서 확인합니다. 한 제품의 시험 결과를 모든 스택에 적용할 수는 없습니다.

같은 스위치로 가는 케이블 두 가닥과 스택 구성원에 나누어 연결한 업링크를 비교합니다. 오른쪽에서도 A1에만 연결된 PC-A는 A1 고장 때 접속을 잃습니다.

게이트웨이 한 대가 멈추면 PC는 누구에게 보낼까 ↑

기본 게이트웨이 장비가 고장 나도 PC가 통신하려면, 다른 장비가 게이트웨이 역할을 이어받아야 합니다. 여기서는 이해를 위해 두 계층 사례와 다른 L2 Access 비교안을 사용합니다. PC의 VLAN이 GW1·GW2까지 이어지는 구성입니다.

PC-A는 10.60.10.21/24이고 기본 게이트웨이는 가상 IP 주소 10.60.10.1이라고 하겠습니다. HSRP나 VRRP처럼 첫 홉 이중화를 제공하는 프로토콜은 여러 라우터가 이 가상 게이트웨이의 역할을 이어 맡도록 합니다. 같은 기능을 지원하는 L3 스위치도 이 자리에서 라우터 역할을 할 수 있습니다.

정상 상태에서는 활성 역할의 GW1이 가상 게이트웨이로 들어온 트래픽을 전달합니다. PC-A는 일반적인 가상 MAC 운용 사례에서 가상 IP에 대응하는 가상 MAC으로 프레임을 보냅니다. 도해의 가상 MAC은 관계를 보여 주는 기호이며, HSRP와 VRRP의 실제 주소 형식이 같다는 뜻이 아닙니다.

GW2가 GW1의 고장을 감지하고 역할을 이어받으면, PC-A는 게이트웨이 IP 설정을 바꾸지 않고 같은 가상 게이트웨이를 계속 사용할 수 있습니다. 이때 스위치의 가상 MAC 전달 위치와 새 활성 장비의 라우팅·정책도 맞아야 합니다. 활성 역할이 바뀐 뒤에도 실제 프레임이 새 장비로 전달되기까지 시간이 걸릴 수 있습니다.

이 전환이 NAT 매핑이나 방화벽 연결 상태, VPN 암호화 상태까지 자동 복사하는 것은 아닙니다. 첫 홉 이중화는 단말이 계속 사용할 게이트웨이를 제공하는 기능입니다. 또한 두 계층 사례에서는 그 게이트웨이가 A1에 있으므로 D1 장애를 곧바로 PC의 HSRP 전환이라고 부르면 안 됩니다. 장애 뒤 대체 경로를 쓰는 것은 같아 보여도, 두 구성은 게이트웨이의 위치와 전환 대상이 다릅니다.

따라서 첫 홉 시험에는 PC의 게이트웨이 정보, 활성 역할, 가상 MAC의 전달 위치, 요청·응답의 실제 경로를 함께 남깁니다. 프로토콜별 용어와 동작은 각각의 문서로 확인합니다. HSRP의 Active·Standby와 VRRP의 역할 명칭은 각 프로토콜의 상태와 전환 절차에 맞춰 구분해서 사용합니다.

이번 도해는 PC의 VLAN을 GW1·GW2까지 이은 별도의 L2 구성입니다. GW1이 멈췄을 때 가상 게이트웨이 역할이 GW2로 넘어가는 과정을 봅니다.

게이트웨이는 살아 있는데 그 위의 길만 끊어지면 어떨까 ↑

장비가 살아 있다는 사실과 목적지에 도달할 수 있다는 사실은 다릅니다. PC가 게이트웨이의 응답을 받아도 그 게이트웨이가 서버 방향으로 보낼 길을 잃었다면 업무는 실패할 수 있습니다.

앞의 L2 비교안에서 GW1의 사용자 쪽 인터페이스는 정상인데 상향 링크만 끊겼다고 하겠습니다. 첫 홉 프로토콜이 관찰하는 조건에 그 링크 단절이 포함되지 않으면 GW1이 계속 활성 역할을 유지할 수 있습니다. 어떤 인터페이스·경로·도달성을 추적하고 그 결과로 역할을 조정할지 해당 구성에서 정해야 합니다.

상향 링크가 끊겨도 다른 경로로 우회할 수 있다면 GW1이 게이트웨이 역할을 계속 맡을 수도 있습니다. 현재 활성 장비가 다른 정상 경로를 선택하는 방식과 게이트웨이 역할 자체를 옮기는 방식을 구별합니다. 추적하는 대상이 실제 업무 경로와 맞지 않으면 정상 장비를 불필요하게 전환하거나 실패를 놓칠 수 있습니다.

두 계층 사례의 Routed Access 사례로 돌아오면 PC-A의 게이트웨이는 계속 A1에 있고, 바뀌는 것은 D1을 거치던 상위 경로입니다. A1이 고장을 감지하고 경로 정보를 바꾼 뒤 실제 전달 정보에 반영해야 D2로 보낼 수 있습니다. RIB의 경로가 바뀌었는지 확인한 뒤에는 FIB에도 반영됐는지, 실제 패킷이 새 경로로 나가는지 따로 확인합니다.

서버가 A1의 서브넷으로 응답을 돌려보낼 경로와 정책도 D2를 통해 동작해야 합니다. 요청이 D2로 나가는 것을 확인했다면 응답이 돌아오는지도 이어서 확인합니다. 경로 추적과 첫 홉 이중화는 서로 보완할 수 있지만, 그 기능을 켜는 것만으로 목적지까지 통신이 되는지는 알 수 없습니다.

두 계층 사례의 Routed Access 구성으로 돌아왔습니다. D1이 멈춰도 PC-A의 게이트웨이는 A1에 남고, A1이 서버로 보내는 상위 경로만 D2 쪽으로 바뀝니다.

새 패킷은 가는데 기존 연결은 왜 끊길까 ↑

대체 경로가 생겨도 기존 연결에 필요한 상태가 없으면 사용자는 다시 접속해야 할 수 있습니다. 패킷이 다시 전달된 시각과 애플리케이션의 작업이 완료된 시각을 따로 기록해야 이 차이를 알 수 있습니다.

PC-A의 인터넷 연결을 경계 E1이 주소와 포트로 변환했다면 응답에는 그 매핑이 필요합니다. 대체 경계 E2가 경로만 알고 매핑을 모르면 기존 흐름의 응답을 원래 단말로 돌려보내지 못할 수 있습니다. 이 매핑 문제는 NAT를 거치는 통신에 해당하며, NAT가 없는 내부 통신과는 구분합니다.

Stateful 방화벽의 연결 정보와 VPN의 보안 연결 상태도 각각 확인해야 합니다. 어떤 상태가 언제 동기화되고 전환 후 어떤 종류의 연결을 유지하는지는 구현별로 다릅니다. HSRP·VRRP나 라우팅 경로 변경만으로 이 상태들이 동기화되지는 않습니다.

교육용 시간축에서 고장을 0ms, 감지를 40ms, 새 경로 선택을 120ms, 시험 패킷 왕복을 180ms, 업무 거래 완료를 900ms로 놓겠습니다. 이는 실제 시험이나 제품 보장 수치가 아닙니다. 한 번의 장애 뒤에도 감지, 경로 선택, 패킷 왕복, 업무 복구가 서로 다른 시점에 끝난다는 것을 보여 주는 가상 값입니다.

업무가 더 늦게 돌아오는 이유는 재전송·새 연결·인증·애플리케이션의 재시도 대기일 수 있습니다. 실제 원인은 측정으로 구분해야 하며 업무 거래가 끝난 시각까지 모두 라우팅 수렴 시간으로 계산하지는 않습니다. 기존 연결을 유지하는 시험과 새 사용자가 시작하는 시험을 따로 수행해야 기존 연결과 신규 연결에 미친 영향을 구분할 수 있습니다.

시험 결과에는 어떤 종류의 연결과 실제 업무를 확인했는지 적습니다. 저장 작업이 성공했는지, 단순 응답만 받았는지도 구별합니다. 일부 패킷이 돌아와도 다른 세션은 끊겨 있을 수 있습니다. 어떤 업무가 유지됐고 어떤 업무는 재접속이 필요했는지 기록해야 이중화의 효과와 남은 문제를 운영자에게 정확히 전달할 수 있습니다.

같은 장애에서 고장 감지, 경로 선택, 패킷 왕복, 업무 완료를 서로 다른 시점에 표시했습니다. 마지막 업무 완료 시각까지 모두 라우팅 수렴 시간으로 계산하면 안 되는 이유를 보여 줍니다.

한쪽만 남아도 수요와 정책을 유지할 수 있을까 ↑

장애 뒤에는 경로의 존재뿐 아니라 남은 자원이 같은 업무를 감당하는지 확인해야 합니다. 정상 때의 여유를 두 장비에 나누어 쓰고 있었다면 한쪽 실패 뒤 그 여유가 사라질 수 있습니다.

두 계층 사례에서 각 Access의 8Gbps 수요가 D2의 10Gbps 링크 하나로 모이면 단순 비율은 80%였습니다. 세 Access의 24Gbps가 D2의 40Gbps 서비스 연결로 모이면 60%였습니다. 같은 고장에서도 접속 링크와 집계 링크의 여유는 다르므로 한쪽의 비율만 보고 전체 용량이 충분하다고 판단하지 않습니다.

연결이 복구되면 재접속과 미뤄졌던 작업이 한꺼번에 몰려 평소보다 트래픽이 많아질 수 있습니다. 링크별 폐기·지연과 업무 완료 시각을 함께 기록하고, CPU 부하·세션 수 제한·회선 병목도 확인합니다. 평균 사용률이 낮아도 짧은 과부하가 있었을 수 있으므로 측정 간격 사이에 놓친 구간은 없는지 살펴봅니다.

보안 장비를 통과하는 경로에서는 정책과 검사 기능이 켜진 조건으로 용량을 봅니다. 검사를 끄거나 방문자 차단을 풀어 처리량이 늘어난 결과는 필요한 보안 조건을 지킨 상태의 처리량으로 볼 수 없습니다. 정상 장비와 대체 장비가 허용·차단할 대표 통신을 같은 조건으로 확인해야 합니다.

업무가 다시 돼도 한쪽 장비나 경로만 남아 있다면 다음 고장에 대비할 여유는 줄어든 상태입니다. 남은 경로의 부하, 추가 고장 때의 영향, 수리와 복귀 계획을 별도로 알립니다. 서비스가 된다는 말과 원래의 이중화가 복원됐다는 말이 다르게 쓰여야 다음 정비의 긴급도도 정확히 판단할 수 있습니다.

수리한 장비를 다시 넣어도 업무가 유지될까 ↑

복귀는 원래 장비에 전원을 넣는 작업만이 아닙니다. 경로와 역할, 상태가 다시 바뀌는 두 번째 전환입니다. 장애 때의 전환이 잘됐더라도 복귀 과정은 따로 시험해야 합니다.

복귀할 D1이나 GW1의 소프트웨어·설정·정책이 현재 운영 기준과 맞는지 먼저 확인합니다. 장애 대응 중 D2에 반영한 변경이 빠져 있을 수 있습니다. 이웃이 생기고 링크가 올라온 사실보다 그 장비가 현재 설정과 정책으로 트래픽을 처리할 준비가 됐는지 확인해야 합니다.

선점이나 자동 경로 복귀가 설정돼 있다면 연결하는 순간 트래픽이 움직일 수 있습니다. 자동 복귀의 조건, 대기 시간과 수동 통제 가능성을 제품 문서와 현재 설정으로 확인합니다. 단순한 케이블 연결이라고 생각한 작업이 사용자에게 또 다른 중단을 만들지 않도록 작업 시간을 정하고 경로와 트래픽을 확인할 담당자를 배치합니다. 기존 세션을 확인할 업무 담당자도 전환 시점에 함께 대기합니다.

복귀 후에는 기존 연결과 신규 요청, 양방향 경로, 부하와 계속 거부할 통신을 다시 확인합니다. 예상과 다른 결과가 나오면 승인된 중단 조건에 따라 대체 상태로 되돌립니다. 되돌릴 관리 경로와 설정을 준비하지 않은 채 복귀를 시험해서는 안 됩니다.

최종 기록에는 정상, 대체 운영, 복귀 준비, 복귀 후 보호 수준을 구별해 남깁니다. 이 기준은 다음 여러 블록의 Core 설계에도 적용됩니다. Core를 추가할 때도 대비할 장애와 다른 장비가 이어받을 기능을 먼저 정하고, 설계 검증에서 실제로 관찰한 범위만 결과로 기록합니다.

D2만으로 업무를 이어가는 상태와 D1까지 복귀해 이중화를 회복한 상태를 나누었습니다. 복귀 중 문제가 생기면 어느 상태로 되돌릴지도 함께 정합니다.