11자주 묻는 질문(FAQ)FAQ

Express와 Recommended 중 무엇을? — 정교한 기능·고급 QoS가 필요하면 Recommended, 기본 QoS만 필요하면 Express 입니다. Express는 성능이 더 좋고 CPU·메모리를 덜 씁 니다. Express→Recommended 전환은 되지만 반대는 안 되므로, 확신이 없으면 Express로 시작하세요(자세히는 QoS 소개).

규칙에 줄 수 있는 최대 가중치는? — 가중치는 상대값이라, 유일한 한계는 전역 속성의 Maximum weight of rule(기본 1000, 임의로 변경 가능) 뿐입니다. 다만 초기 가중치를 크게 잡을지 작게 잡을지가 중요 합니다. HTTP·FTP가 각 500인 정책에 SMTP(100)를 더하면 HTTP는 500/1100으로 거의 안 줄 지만, 각 2인 정책에 SMTP(100)를 더하면 2/104로 확 줄 어듭니다. 즉 초기 가중치가 크면 규칙을 더해도 영향이 작 습니다.

QoS를 외부·내부 인터페이스 중 어디에? — 둘 다 되지만 외부 인터페이스에만 두는 것이 강력히 권장 됩니다.

보장과 가중치의 차이는? — 둘 다 매칭 트래픽에 대역폭을 보장한다는 점은 같지만, 보장은 절대값(예: 20000bps), 가중치는 상대값(예: 100) 입니다. 그리고 보장이 가중치보다 먼저 대역폭을 가져갑니다. 예컨대 1.5MB 회선에 HTTP Guarantee 1Mb·FTP Weight 40·SMTP Weight 10이면, 먼저 HTTP에 1MB, 남은 0.5MB를 FTP 0.4·SMTP 0.1 로 나눕니다.

보장은 대역폭을 낭비하나? — 아닙니다. 애플리케이션은 필요한 만큼만 쓰고, 안 쓰는 대역폭은 즉시(패킷 단위로) 다른 연결에 상대 우선순위대로 재분배 됩니다. QoS에는 "빌려준 대역폭"이라는 개념이 없습니다.

TCP 재전송은 어떻게? — 재전송을 감지하면 그 데이터가 이미 QoS 큐에 있는지 확인해, 있으면 패킷을 떨굽 니다(RDED). 이 덕에 WAN 링크의 최대 40%를 잡아먹는 재전송을 없애 고 메모리도 아낍니다.

QoS는 Multi-Domain Security Management와 정교하게 통합 됩니다 — VPN 터널 안 트래픽의 정확한 분류, NAT 트래픽 분류, 네트워크 객체·토폴로지 공유 등. SmartView Monitor는 QoS의 일부가 아니라 함께 번들되는 별도 제품 이고, QoS는 모든 ClusterXL 구성(Load Sharing 포함) 과 NAT 트래픽 을 완전히 지원합니다. 관리 가능한 QoS 게이트웨이 최대 수는 일반 게이트웨이와 동일 하며, QoS 게이트웨이를 관리하려면 Management Server에도 QoS를 설치 해야 합니다.

LLQ는 언제? — VoIP·화상회의 등 멀티미디어 처럼 최소 보장 대역폭이 필요하고 낮은 지연·지터가 중요 한 경우입니다(고급 정책 관리).

Rule Base는 first match인가? — 예. 연결에 처음 맞는 규칙만 적용 됩니다. 그래서 CEO 트래픽 규칙과 HTTP 규칙이 있을 때, CEO를 보장하려면 CEO 규칙을 HTTP 규칙보다 위에 둬야 합니다(아래 두면 CEO의 웹서핑이 HTTP 제한에 걸림).

여러 게이트웨이의 Rule Base 정리법은? — 대역폭이 같고 정책도 같으면 Install On을 All 로, 대역폭이 다른데 정책이 같으면 (절대값 아닌) 가중치를 써서 하나의 정책 을, 대역폭도 정책도 다르면 게이트웨이별 서브 규칙 을 씁니다.

서브 규칙은 언제? — 객체 사이에 위계가 있을 때 — 예컨대 R&D·Marketing·운영 같은 조직 구조대로 대역폭을 나눌 때입니다. 대역폭을 많이 먹는 앱은? — CLI에서 rtmtopsvc 를 실행해 봅니다(CLI 참조).

메모리 요구량은? — 연결 수에 비례합니다. 5,000 연결에 약 32.5MB, 50,000에 약 91MB, 100,000에 약 156MB 가 게이트웨이에 추가로 필요합니다(평균 연결당 ~1300바이트, 기본 연결 테이블 25,000). 하드웨어는? — 성능의 주 요인은 CPU 입니다. 메모리는 값이 싸고 발자국이 작아 보통 병목이 아닙니다.

성능 튜닝 팁 — 최신 QoS 버전으로 업그레이드, 대개 외부 인터페이스에만 설치, inbound 제한을 안 쓰면 outbound 방향에만 설치, 자주 쓰는 규칙을 Rule Base 위로, per-connection 제한·보장을 per-rule로 전환 하는 것입니다. 최대 지원 대역폭은? 10Gbps 입니다.

메일/ERP 서버 성능 보장은? — 해당 트래픽(출발지·목적지 또는 SMTP·POP3, SAP·ORACLE 등 프로토콜)에 매칭되는 규칙을 하나 만들고 가중치나 보장 을 줍니다. VoIP 품질 보장은? — LLQ에 per-connection 보장 을 써서 통화마다 대역폭을 보장하고, 대역폭이 부족하면 추가 통화를 안 받는 입장 정책 을 둡니다(옛 전화의 통화 중 신호와 같은 개념).

QoS로 DoS 공격을 막나? — QoS는 DoS 전용 도구는 아니지만, DoS에 흔히 쓰이는 앱(ICMP·수상한 URL)을 제한 하고 중요 트래픽(ERP·메일·VoIP)에 보장 을 줘 탐지·모니터링·예방에 쓸 수 있습니다. 차단보다 대역폭 제한이 나은 이유는? — 완전 차단은 사용자가 우회로를 찾게 만들 어 법적 문제까지 부를 수 있습니다. 대역폭을 제한하거나 시간대별로 조절 하면 업무를 해치지 않으면서 통제할 수 있습니다.

SmartView Monitor에서 보장/제한이 깨져 보입니다 — 낮은 제한(예: 1000Bps)을 잦은 주기(2초)로 보면 QoS가 패킷을 쪼개지 않아 그렇게 보일 수 있습니다. 샘플링 주기를 8초로 낮추면 제한이 지켜지는 것을 볼 수 있습니다.

정의 대역폭이 실제 물리 대역폭보다 작으면/크면? — 작으면 정의한 만큼만 쓰고 나머지는 안 씁 니다. 크면 물리 한계 이상을 보내려다 다음 홉에서 무작위 드롭 이 생겨 중요한 패킷을 잃을 수 있습니다. 그래서 QoS 관리에서 강조했듯 정의 전송률을 실제 용량에 맞추 는 것이 중요합니다.