11HyperFlowHyperFlow

Elephant flow 는 TCP 또는 UDP가 맺는, 전체 바이트 수가 큰 연속 연결 을 말합니다. 예를 들어 HTTP·HTTPS·FTP·NFS 프로토콜로 리눅스 ISO 같은 큰 파일을 내려받는 연결이 여기에 해당합니다. 이런 큰 연속 연결은 다른 종류의 데이터 세션에 비해 네트워크 용량을 훨씬 많이 잡아먹습니다.

문제는 HyperFlow 가 없을 때 생깁니다. 이 기능이 없으면 Security Gateway는 하나의 elephant 연결을 CPU 코어 하나(= CoreXL Firewall 인스턴스 하나)로만 검사 합니다. 게다가 Security Gateway의 CPU 사용률이 올라갈수록 트래픽 처리량은 점점 떨어 집니다. 한 코어가 큰 연결 하나를 떠맡은 채 한계에 다다르기 때문입니다.

R81.20 이상의 HyperFlow 는 이런 elephant 연결을 한 코어가 아니라 여러 CPU 코어에서 동시에 검사 해 이 문제를 해결합니다. 핵심 아이디어는 하나의 큰 검사 작업을 작은 작업으로 잘게 쪼개, 사용 가능한 여러 CPU 코어로 흩뿌리는 것입니다.

작업이 나뉘는 방식

HyperFlow가 없을 때와 있을 때, 검사 작업이 어떻게 처리되는지를 비교하면 그 차이가 분명해집니다.

HyperFlow가 없을 때 — 아래 작업이 모두 하나의 흐름으로, 한 코어 위에서 차례로 처리됩니다.

HyperFlow가 있을 때 — 같은 작업을 세 단계로 나누고, 그중 무거운 패턴 매칭 부분을 여러 코어로 분산 합니다.

가장 무거운 패턴 매칭·해시 계산을 여러 코어로 떼어 내 동시에 돌리는 것이 HyperFlow의 성능 비결입니다. 여기서 PPE(Packet Processing Engine, 작업을 분배하는 Job Dispatcher와 실제로 일하는 Working Thread들)가 핵심 역할을 합니다.

그 결과 얻는 것

이렇게 작업을 쪼개 분산하면 HyperFlow는 다음 세 가지를 이룹니다.

꼭 알아 둘 동작 원칙

HyperFlow는 무거운(heavy) 연결이 감지되면 트리거되어 활성(active) 상태 가 되고, 그 무거운 연결이 닫히면 다시 비활성(passive) 상태 로 돌아갑니다.

HyperFlow를 쓰려면 아래 조건을 모두 갖춰야 합니다.

   dynamic_split –o enable
   

HyperFlow는 connection_pipelining 명령으로 다룹니다. Scalable Platform에서는 접두사 g 가 붙은 g_connection_pipelining 을 씁니다.

명령의 전체 구조는 다음과 같습니다.

{connection_pipelining | g_connection_pipelining}
      advanced
      on
      off
      heaviest_conn
      pipelined
      status
{connection_pipelining | g_connection_pipelining} advanced
      allow_accelerated_pipeline
      async
      default
      prevent_accelerated_pipeline
      sleep
      sync
      wake_up

기본 파라미터

아무 파라미터 없이 명령만 입력하면 내장 도움말이 표시됩니다. 명령 이름 자체는 환경에 따라 갈립니다.

status 의 출력에는 다음 줄들이 해당 값과 함께 표시됩니다.

- Status of connection pipelining: <Status>
- Flow mode: <Mode>
- Status of PPE_MGR and PPE_WT: <Status>
- Status of accelerated pipeline: <Status>

고급(advanced) 파라미터

advanced 뒤에 붙이는 옵션들입니다. 대부분 문제 해결(troubleshooting) 용도이므로 평상시에는 손대지 않습니다.

각 고급 옵션에는 적용 범위와 재부팅 여부에 대한 다음 규칙이 따라붙습니다.

HyperFlow가 Security Gateway에서 어떻게 동작하는지는 CPView로 들여다볼 수 있습니다. 목적별로 살펴볼 경로가 정해져 있습니다.

HyperFlow가 켜졌는지 / 꺼졌는지 확인

HyperFlow가 활성인지 / 잠들었는지 확인

CPU 코어 할당 상태 확인

특정 elephant 연결이 주는 CPU 부하 확인

먼저 Security Gateway에서 지난 24시간 동안의 elephant 연결과, 어느 CoreXL Firewall 인스턴스가 그 연결을 검사하는지 를 확인합니다. 각 줄 앞머리의 [fw_<번호>] 가 인스턴스 번호입니다.

fw ctl multik print_heavy_conn

출력 예시는 다음과 같습니다.

;[fw_5]: Conn: 192.168.10.20:60478 -> 172.30.40.50:80 IPP:
6; Instance load: 63%; Connection instance load: 99%;
...<생략>...

다음으로 CPView에서 CPU > Top-Connections > Instances<X>-<Y>(예: Instances0-5) > Instance<Z>(예: Instance5)로 이동합니다. 마지막 Top Connections 섹션에서 % out of CPU 열과 % out of WT CPU 열 을 살펴봅니다.

PPE 상태 확인

방화벽에서 온 PPE 메시지 확인

마지막으로 Messages received in a single read loop (Histogram) 섹션이 있습니다. 매 루프마다 PPE_MGR 는 수신 큐에서 최대 32개 항목 을 읽을 수 있는데, 이 섹션은 PPE_MGR가 큐에서 항목을 읽은 횟수와, 큐에서 "대기 중"이던 항목 수(최대 32) 를 히스토그램으로 보여 줍니다.

작업(Job) 수와 실행 시간 확인

큐 사용률 확인

Worker Thread 수와 상태 확인

HyperFlow에는 다음과 같은 제약이 있습니다.

HyperFlow를 켜도 다음 경우에는 elephant flow의 속도가 빨라지지 않을 수 있습니다.

또한 Security Gateway 객체에서 Firewall 소프트웨어 블레이드만 켠 경우 HyperFlow는 성능을 개선하지 못 합니다. 이는 SecureXL이 검사를 거치지 않는 연결을 가속 하는 반면, HyperFlow는 여러 소프트웨어 블레이드의 검사를 거치는 연결을 가속 하기 때문입니다.

문제를 분석할 때 살펴볼 로그 파일 은 다음과 같습니다(메인 파일은 10MB마다 순환(rotate) 됩니다).

다음은 HyperFlow의 내부 구성 파일 입니다.

명령줄 레퍼런스는 R82 CLI Reference Guide 를 참고하고, 그 밖의 추가 정보는 sk178070을 참고하세요.