업링크는 얼마나 넓어야 하고, 하나가 끊기면 버틸 수 있을까

접속 포트 속도의 합은 실제로 올라오는 트래픽과 다르다 ↑

집선 비율은 접속 쪽의 최대 연결 속도를 상향 용량과 비교하는 설계값입니다. 지금 사용자가 보내는 트래픽의 양을 나타내는 사용률과는 구분해야 합니다.

A1에 1 Gbps 접속 포트 48개와 동시에 활성인 10 Gbps 업링크 두 개가 있다고 하겠습니다. 모든 접속 포트 속도의 합은 48 Gbps, 상향 링크 속도의 합은 20 Gbps입니다. 이 글에서 사용하는 포트 속도 기준 집선 비율은 48÷20=2.4:1입니다.

이 계산은 모든 단말이 동시에 최대 속도로 업링크를 사용할 수 없다는 구조를 보여 줍니다. 그러나 48개 포트가 항상 48 Gbps를 발생시킨다는 뜻은 아닙니다. 같은 스위치 안에서 끝나는 통신은 해당 업링크를 사용하지 않을 수 있으며, 단말마다 트래픽의 양과 시간도 다릅니다.

실제로 업링크를 얼마나 사용하는지는 트래픽을 측정해서 확인합니다. 교육용으로 상향 수요를 8 Gbps라고 가정하면 총 링크 속도와 비교한 값은 8÷20=40%입니다. 이는 집선 비율을 다시 계산한 것이 아니라, 고정한 수요를 현재 활성 용량과 비교한 값입니다. 여기서 8 Gbps는 실측값이 아니라 계산을 위한 가정입니다.

상향 용량을 계산할 때는 실제로 동시에 데이터를 보낼 수 있는 링크만 더합니다. 한쪽이 차단된 L2 경로라면 연결된 두 선의 속도를 그대로 합산할 수 없습니다. 링크 속도를 합산한 표에도 어떤 경로가 활성 상태인지 적어야 정상과 장애의 비율을 같은 기준으로 비교할 수 있습니다.

측정값에는 어느 지점에서 어느 방향의 트래픽을 쟀는지 적습니다. 송신과 수신을 합쳐 한 방향 링크 속도로 나누거나, IP 데이터양과 선로 오버헤드를 혼합하면 서로 다른 비율이 나옵니다. 같은 구간·방향·시간 기준의 값으로 비교한 뒤 실제 업무 응답까지 대조해야 설계값의 의미가 분명해집니다.

같은 수요를 장애 뒤 남은 업링크에 다시 올려 본다 ↑

장애 뒤의 용량을 계산하려면 무엇이 고장 났고 얼마나 많은 트래픽이 남는지 먼저 정해야 합니다. N-1이라고 적을 때도 장비 한 대인지 링크 한 가닥인지 구체적으로 밝혀야 합니다.

앞의 구성에서 업링크 한 가닥만 끊기고 48개 접속 포트는 그대로 남는다고 하겠습니다. 상향 용량은 20 Gbps에서 10 Gbps로 줄어듭니다. 접속 포트 속도의 합이 같으므로 집선 비율은 48÷10=4.8:1로 바뀝니다. 분자인 접속 포트 속도의 합은 장애 전과 같습니다.

실제 수요를 계속 8 Gbps로 가정하면 총 용량 기준 사용률은 8÷10=80%입니다. 정상 상태의 40%만 보고 여유가 충분하다고 판단했다면 장애 때의 조건을 놓친 것입니다. 다만 80%가 모든 서비스에 허용되거나 금지되는 공통 기준은 아닙니다.

스위치 한 대를 끄는 시험이라면 같은 계산을 그대로 사용할 수 없습니다. 그 스위치에 붙은 단말의 접속도 함께 사라져 남는 수요가 달라질 수 있기 때문입니다. 단말은 계속 연결된 채 업링크만 줄어드는 경우와, 단말·업링크가 함께 줄어드는 경우를 표에서 별도 행으로 나눕니다.

고장 뒤 트래픽이 줄어드는지, 다른 경로로 그대로 몰리는지도 구분합니다. 접속 스위치가 꺼져 사용자가 사라지는 경우와 상향 링크만 끊겨 사용자가 남는 경우는 남은 경로의 부하가 다릅니다. 같은 N-1 시험이라도 남는 트래픽이 다르므로, 각 경우의 수요로 따로 계산해야 합니다.

전환 뒤의 수요에는 재접속이나 대기한 작업의 재시도가 더해질 수도 있습니다. 어느 서비스가 다시 시작하는지, 남은 경로에 순간적으로 얼마나 몰리는지 관찰합니다. 정상 평균뿐 아니라 시험할 장애가 발생한 직후와 통신이 안정된 뒤의 수요를 비교해야 대체 경로가 업무를 감당하는지 판단할 수 있습니다.

이번에는 접속 단말과 8 Gbps의 수요를 그대로 두고 업링크 한 가닥만 끊어 보겠습니다. 아래 두 배치에서 바뀌는 것은 상향 용량입니다. 그에 따라 집선 비율과 총 용량 기준 사용률이 어떻게 달라지는지 함께 적었습니다.

접속 포트와 수요는 그대로 두고 업링크 한 가닥만 끊어 보겠습니다. 집선 비율과 가정한 트래픽의 사용 비율이 각각 어떻게 바뀌는지 비교합니다.

총 용량이 남아도 한 흐름이 느린 이유를 찾는다 ↑

두 링크의 용량을 합할 수 있다는 사실은 한 통신이 그 합계 속도를 사용한다는 뜻이 아닙니다. 흐름을 어떤 링크에 배정하는지에 따라 한 링크의 한계가 먼저 나타납니다.

EtherChannel은 장비가 선택한 주소·포트 등의 필드를 바탕으로 흐름을 멤버 링크에 나눌 수 있습니다. 같은 흐름을 한 링크로 보내 순서를 유지하는 방식에서는 두 개의 10 Gbps 링크가 있어도 단일 흐름이 두 링크를 자유롭게 합쳐 쓰지 못합니다. 실제 해시 필드와 동작은 제품·설정에 따라 확인합니다.

교육용으로 6Gbps 흐름 하나와 4Gbps 흐름 하나가 같은 멤버 링크에 배정되고, 다른 흐름들은 나머지 링크에 배정됐다고 하겠습니다. 총 전송량이 20Gbps보다 작아도 첫 링크는 여유가 거의 없거나 오버헤드와 추가 트래픽 때문에 혼잡할 수 있습니다. 포트별 결과를 보아야 이 차이가 드러납니다.

해시는 빈 링크를 보고 매 패킷마다 가장 여유 있는 곳으로 보내는 기능과 같지 않습니다. 송신과 수신 방향에서 사용하는 필드도 달라질 수 있으므로 양쪽 장비의 분포를 나누어 확인합니다. 해시 설정을 바꾸면 기존 흐름의 경로와 순서에 영향이 있는지도 검토해야 합니다.

한 흐름을 더 빠르게 해야 한다면 링크 자체의 속도를 높이는 방법이나 애플리케이션의 여러 흐름 사용 여부를 검토합니다. 링크 추가는 여러 흐름의 총량을 늘리는 데 도움이 될 수 있지만, 한 흐름의 속도도 빨라지는지는 따로 시험해야 합니다. 자세한 분산 동작은 EtherChannel의 흐름 분산 글로 연결합니다.

평균 사용률에 숨은 짧은 혼잡을 폐기량과 함께 확인한다 ↑

평균 사용률이 낮아도 짧은 시간에 입력이 몰리면 출력 대기열이 차고 패킷이 버려질 수 있습니다. 이때는 긴 구간의 평균값과 순간적인 큐 동작을 구별해야 합니다.

여러 접속 포트가 같은 출력 포트로 한꺼번에 보낸다고 하겠습니다. 출력 속도보다 빠르게 들어온 패킷은 잠시 버퍼에 쌓입니다. 그 시간이 짧으면 분 단위 평균에는 작게 보일 수 있지만, 해당 순간의 지연에 민감한 업무에는 영향을 줄 수 있습니다.

운영자는 문제 시간대의 출력 폐기량과 큐 관련 카운터, 링크별 트래픽을 함께 봅니다. 누적 카운터에는 과거에 발생한 폐기도 포함되므로, 관찰 구간의 증가량과 사용자 실패 시각을 대조합니다. 카운터가 초기화됐거나 측정 간격이 다르면 그 조건도 기록합니다.

패킷 폐기는 혼잡만으로 생기지 않습니다. 인터페이스 오류, 정책에 의한 거부, 플랫폼의 다른 자원 제한을 같은 “드롭”으로 합치면 원인이 흐려집니다. 공식 문서에서 해당 카운터가 무엇을 어디에서 세는지 확인합니다. 같은 방향의 패킷 캡처와 대조하면 폐기 원인을 좁힐 수 있습니다.

오류 카운터가 증가했다고 모두 혼잡으로 해석하지 않습니다. 물리적 오류와 대기열 폐기는 원인과 조치가 다릅니다. 같은 시각의 링크 오류, 대기열 상태, 서비스 지연을 비교하면 케이블 문제를 증속으로 해결하려 하거나 혼잡을 회선 불량으로 오인하는 일을 줄일 수 있습니다.

QoS를 적용할 때도 전체 용량 부족이 저절로 사라지는 것은 아닙니다. 혼잡 시 어떤 트래픽에 어떤 자원을 배분할지 정하는 일이며, 허용한 손실과 지연의 결과를 업무로 확인해야 합니다. 요구한 총량이 남은 링크를 계속 넘는다면 우선순위 정책과 별개로 용량이나 트래픽 배치를 바꿔야 합니다.

두 큰 흐름이 같은 구성 링크에 배정된 경우입니다. 다른 링크에 여유가 남아 있어도 이 링크에서 혼잡이 생길 수 있습니다.

증속·링크 추가·트래픽 분산 중 실제 병목을 바꾸는 조치를 고른다 ↑

용량 개선은 관찰된 병목을 바꾸는 조치여야 합니다. 같은 느림 증상이라도 단일 흐름 한계, 여러 흐름의 집중, 외부 회선 부족은 필요한 변경이 다릅니다.

한 멤버 링크에 큰 흐름이 묶였다면 총 업링크 숫자만 늘리는 것으로 충분한지 다시 계산합니다. 여러 링크에 고르게 나뉜 수요가 장애 때 남은 용량을 계속 넘는다면 증속이나 통신 경로 분리가 더 직접적인 대안일 수 있습니다. 선택 이유에 어떤 지표를 개선하려는지 적습니다.

내부 서버와 단말 사이의 트래픽이 병목인데 인터넷 회선을 증속하면 해당 내부 경로는 달라지지 않을 수 있습니다. PC-A에서 목적지까지 실제로 지나는 구간을 먼저 표시하고, 어느 출력 포트에서 들어오는 트래픽을 제때 내보내지 못하는지 찾습니다. 측정 위치를 알아야 어느 장비나 회선을 증설할지 판단할 수 있습니다.

변경할 구성을 정했다면 정상 상태와 장애 상태에서 용량을 다시 계산합니다. 정상 상태에서 용량에 여유가 생겨도 장애 때 동일한 한 링크나 전원에 의존한다면 원래의 복구 요구는 그대로 남을 수 있습니다. 반대로 배치만 바꾸어 불필요한 집계를 줄이면 장비를 늘리지 않고 같은 요구를 충족할 가능성도 있습니다.

증설 뒤에도 같은 관찰을 반복해야 선택의 효과를 알 수 있습니다. 링크 속도를 올렸는데 업무 지연이 그대로라면 서버 처리나 다른 경로가 제약이었을 수 있습니다. 변경 전후의 수요와 요청 조건을 맞춰 비교하고, 원래 발견한 병목이 실제로 줄었는지 확인합니다.

최종 기록에는 가정한 수요, 실제 측정값, 시험한 장애, 링크별 결과와 선택한 조치를 나누어 둡니다. 숫자가 바뀌었을 때 어느 가정을 다시 확인할지 알 수 있게 하는 것입니다. 이후 건물과 캠퍼스 설계에서도 이 계산을 같은 기준으로 사용하며, 계층을 추가하더라도 각 링크의 용량은 다시 계산해야 합니다.