여러 통신실의 스위치는 어떻게 묶어 설계할까

통신실의 위치와 서비스 경로를 먼저 그린다 ↑

통신실이 세 곳이면 스위치를 세 묶음으로 나눌 수 있습니다. 그러나 통신실의 수만으로 네트워크 구조가 결정되지는 않습니다. 각 통신실에서 어떤 사용자가 어느 서비스로 통신하는지 알아야 상향 연결의 역할을 정할 수 있습니다.

이 사례에서는 각 통신실의 Access를 A1·A2·A3로 부릅니다. 사용자는 해당 Access에 접속하고, 공통 서버와 외부 연결은 D1·D2 쪽의 서비스 구간에 있습니다. 같은 Access 안에서 끝나는 통신과 공통 서비스까지 올라가는 통신을 구별해 주소와 수요를 기록합니다.

D1·D2는 여러 Access를 집계하고 다른 구간으로 전달하는 역할을 함께 맡습니다. Access 위에 별도의 Core 장비를 두지 않은 이 배치를 Two-Tier, 또는 집계와 코어 역할을 합친 Collapsed Core 구성으로 설명할 수 있습니다. 장비 두 대만 있다는 뜻은 아닙니다.

도면을 그릴 때 실제 통신실과 광 경로도 함께 표시합니다. A1에서 D1·D2로 각각 선이 이어져 있어도 같은 배관에서 함께 절단될 수 있습니다. 서비스 구간으로 가는 연결 역시 같은 장비나 전원에 의존한다면 그 공통 고장을 별도 제약으로 남겨야 합니다.

서비스가 모두 한 위치에 모여 있는지도 확인합니다. 통신실 안에서 사용하는 로컬 서버와 외부 공통 서버는 상향 수요가 다릅니다. 어떤 트래픽을 D1·D2 연결의 용량 계산에 포함했는지 서비스 위치와 함께 적어야 이후 서버를 옮겼을 때 용량 계획도 같은 변경으로 갱신할 수 있습니다.

이제 각 Access가 라우팅을 맡는 것으로 사례를 고정합니다. L2 Access도 가능한 대안이지만, 두 방식을 한 도면에서 섞으면 VLAN이 어디까지 이어지는지 불분명해집니다. L2/L3 경계 비교에서 선택한 방식 하나를 실제 건물 배치에 적용하는 순서입니다.

세 통신실을 아래처럼 한 배치에 놓겠습니다. A1·A2·A3는 각각 D1·D2에 L3로 연결되고, 두 집계 장비 위에 별도의 Core는 없습니다. 어느 통신이 통신실 안에서 끝나고 어느 통신이 공통 서비스로 올라가는지 이 그림을 기준으로 살펴봅니다.

단말의 게이트웨이와 상위 라우팅 경로를 구분한다 ↑

A1의 업무 단말이 사용하는 게이트웨이는 A1에 있습니다. 업무 VLAN은 A1의 접속 구간에서 끝나고, A1에서 D1·D2로 향하는 두 링크는 각각 별도의 L3 연결입니다. 단말의 VLAN을 두 집계 장비까지 그대로 늘인 사례가 아닙니다.

PC-A가 공통 서버로 통신하면 먼저 A1의 게이트웨이 MAC 주소로 프레임을 보냅니다. A1은 목적지 IP 주소에 맞는 경로를 찾아 D1 또는 D2 방향으로 전달합니다. 이후 각 라우터는 자신이 내보낼 링크의 다음 홉에 맞게 프레임을 새로 구성합니다.

두 경로를 동시에 사용할 수 있는지는 라우팅 설계와 실제 설치된 경로에 따라 확인합니다. 두 케이블이 연결되어 있다는 사실만으로 부하가 정확히 절반씩 나뉜다고 가정하지 않습니다. 같은 비용의 경로가 있어도 실제 흐름의 분산은 장비의 전달 방식과 트래픽 구성에 영향을 받습니다.

여기서 D1과 D2는 독립된 L3 이웃입니다. 두 장비가 하나의 논리 시스템으로 동작하도록 구성된 별도 기술 조건이 없다면, 서로 다른 장비로 향하는 링크를 하나의 EtherChannel로 묶을 수 없습니다. 이 사례는 링크 집성이 아니라 두 라우팅 경로로 설명합니다.

ECMP로 두 경로를 사용한다면 한 경로가 사라진 뒤 어느 흐름이 다시 배정되는지도 관찰합니다. 경로 수가 바뀌면서 흐름의 전달 위치가 달라질 수 있기 때문입니다. 새로운 연결의 성공과 기존 세션의 유지 여부를 구분해 시험해야 전환 뒤 사용자가 재접속해야 하는지도 알 수 있습니다.

서버에서 PC-A로 돌아오는 경로도 같은 도면에 표시합니다. D1을 통해 나갔다는 이유만으로 응답도 반드시 D1을 지난다고 단정할 수 없습니다. 중간에 상태를 추적하는 보안 장비가 있다면 비대칭 경로를 지원하는 구성인지까지 확인해야 요청과 응답이 모두 통과할 수 있습니다.

A1·A2·A3는 각각 D1과 D2에 독립된 L3 링크로 연결됩니다. 단말의 게이트웨이가 어디에 있고, 서버로 가는 상향 경로가 어디에서 갈라지는지 살펴보겠습니다.

Access별 병목과 집계 전체 병목을 따로 계산한다 ↑

각 Access는 D1·D2에 10Gbps 링크를 하나씩 연결합니다. 각 Access에서 상위로 보내는 트래픽을 8Gbps로 가정하겠습니다. 이 수치는 특정 환경에서 측정한 값이 아니라, 정상 상태와 장애 상태를 같은 조건으로 비교하기 위한 예시입니다.

정상 상태에서는 각 Access에 명목상 20Gbps의 상향 연결이 있습니다. 다만 두 라우팅 경로를 실제로 이용할 수 있어야 두 링크의 용량을 더할 수 있고, 개별 흐름의 속도가 20Gbps가 되는 것도 아닙니다. 경로별 분산과 짧은 시간의 집중은 별도 측정 대상입니다.

D1이 고장 나면 각 Access에는 D2로 향하는 10Gbps 링크 하나가 남습니다. 각 8Gbps 수요가 그대로 유지된다는 조건에서 그 링크의 단순 사용 비율은 80%입니다. 여기에 프로토콜 오버헤드와 추가 트래픽이 더해지므로, 실제로 여유가 충분한지는 따로 확인해야 합니다.

세 Access의 수요가 모두 D2의 같은 서비스 연결로 향한다면 합계는 24Gbps입니다. 그 연결을 40Gbps로 가정하면 단순 비율은 60%입니다. 집계 연결의 여유가 있어 보여도 각 Access의 10Gbps 연결이 먼저 제약이 될 수 있다는 점이 두 계산의 차이입니다.

반대로 서비스 연결이 20Gbps라면 24Gbps 수요를 모두 동시에 전달할 수 없습니다. 정상 도면에서 충분해 보인 연결도 장애 시 수요가 한쪽으로 모이면 조건이 달라집니다. 상향 용량 계산에 사용한 방향·관찰 구간·수요 조건을 이 건물 도면에도 그대로 적어야 비교가 성립합니다.

D1이 멈춘 뒤의 용량을 Access별 링크와 D2의 서비스 연결로 나누어 계산했습니다. 집계 쪽에 여유가 남아도 Access 쪽 링크가 먼저 혼잡해질 수 있습니다.

D1을 지운 도면으로 왕복 통신을 다시 따라간다 ↑

장애 검토에서는 D1을 흐리게 표시하는 데서 끝내지 않고, D1에 연결된 링크와 그 장비가 제공하던 기능을 함께 지웁니다. 남은 장비만으로 PC-A에서 서버까지 가는 길과 서버에서 돌아오는 길을 실제로 이어 보아야 합니다.

A1이 D1 방향 경로를 사용할 수 없다고 판단하면 사용 가능한 D2 방향 경로로 전달해야 합니다. 그러나 고장 감지, 경로 선택, 전달 상태 반영이 한순간에 끝나는 것은 아닙니다. 경로 전환 중에 잃을 수 있는 패킷과 애플리케이션 재시도는 이중화와 복구 시간의 기준으로 따로 관찰합니다.

D2가 서버 방향 경로를 가지고 있어도 서버 쪽에서 A1의 업무 서브넷으로 돌아갈 경로가 없으면 통신은 실패합니다. 기본 경로가 있어도 PC-A의 서브넷으로 돌아가는 경로가 맞는지는 별도로 확인해야 합니다. 장애 전후의 양쪽 전달 상태를 기록해야 합니다.

이 사례에서는 단말의 게이트웨이가 A1에 남아 있으므로 D1 고장 자체가 단말의 게이트웨이 장비 교체를 뜻하지 않습니다. 반면 A1이 고장 나면 A1에만 연결된 단말은 D2가 살아 있어도 접속을 잃습니다. 이 구성으로 D1 고장에는 대비할 수 있어도 A1에만 연결된 단말의 접속까지 지킬 수는 없는 것입니다.

계획 정비와 갑작스러운 고장은 경로를 잃는 조건이 다를 수 있습니다. 정비 전에 트래픽을 다른 경로로 옮긴 시험과 예고 없이 장비를 끈 시험은 따로 기록합니다. 어떤 방식으로 장애를 만들었는지 알아야 전환 시간과 패킷 손실을 같은 조건에서 비교할 수 있습니다.

D1이 돌아올 때도 시험이 필요합니다. 경로가 다시 추가되는 동안 수요가 어떻게 나뉘는지, 기존 세션이 유지되는지, 새 정책이나 오래된 설정이 함께 들어오지 않는지 확인합니다. D2가 정상 운영 중이더라도, 수리한 D1의 상태를 확인한 뒤 다시 연결해야 합니다.

도면·주소·정책·시험 결과를 같은 설계로 인계한다 ↑

Two-Tier 설계를 인계할 때는 장비 배치도 외에 운영에 필요한 문서도 준비합니다. 물리 도면, 논리 도면, 주소 계획, 서비스별 정책, 정상과 고장 상태의 검증 결과가 같은 장비 이름과 연결을 가리켜야 운영자가 실제 망을 재구성할 수 있습니다.

물리 도면에는 통신실, 장비, 포트, 회선 경로와 전원 의존성을 남깁니다. 논리 도면에는 각 Access의 게이트웨이와 서브넷, 두 L3 연결, 서버 방향 경로를 적습니다. 어느 VLAN이 어디에서 끝나는지도 표시해야 운영자가 L2/L3 경계를 알 수 있습니다.

설정 문서는 전체 명령을 복사하는 데 앞서 설계 의도를 설명해야 합니다. 왜 게이트웨이를 Access에 두었는지, D1이 빠지면 어떤 연결에 얼마의 수요가 모이는지, 어떤 통신은 허용하고 어떤 통신은 막는지 적습니다. 이후 장비 문법이 바뀌어도 이 판단을 다시 확인할 수 있어야 합니다.

시험 기록에는 D1 고장과 복귀를 유발한 방법, 관찰한 양방향 통신, 실제 측정 시각, 남은 부하, 기대와 다른 결과를 남깁니다. 아직 시험하지 못한 서비스는 정상으로 처리하지 않고 미검증으로 표시합니다. 교육용 계산과 실제 측정값을 같은 칸에 섞지 않습니다.

연결 표에는 현장에서 읽을 수 있는 포트 표기와 장비 식별을 사용합니다. 논리 도면의 A1이 실제 어느 통신실의 어느 장비인지 찾을 수 있어야 합니다. 이름이 다르면 대응표를 두고, 단선이나 교체 뒤 표기와 문서를 함께 갱신하도록 인계합니다.

이제 이 도면을 바탕으로 다음 스위치와 라우터 이중화 글에서 어떤 고장을 감지하고 누가 역할을 이어받는지 자세히 살펴봅니다. 대체 경로가 남아 있어도 업무가 다시 되기까지는 장애 감지와 경로 전환, 재접속이 필요할 수 있습니다. 그 차이를 확인한 뒤 여러 집계 블록 사이에 Core를 둘 필요를 판단하겠습니다.