PicOS OvS sFlow Prometheus 연동 - 문제 정의, sFlow 이론

PicOS 측에 문의한 결과

NetFlow - 하드웨어 문제로 사용 불가능

IPFIX - 더이상 사용하지 않음
(가장 최신 메뉴얼엔 마치 지원하는 것처럼 적혀있음

Configuring IPFIX - PICOS-4.4.5_Configuration_Guide - PICOS Documentation)

유일하게 플로우 모니터링할 수 있는 기술이 sFlow인데, sFlow에 대한 자료 찾기가 어렵고 한국어로 된 자료도 많이 없으며 공식 툴인 sFlow-RT는 오픈소스가 아니라 문제를 해결하기 어렵다.

 

문제:

1. PicOS 스위치에서 sFlow 밖에 지원하지않아 sFlow로 정확한 플로우 모니터링을 구성해야한다.

2. sflowtool로 sFlow → NetFlow 전환을 시도해봤지만 부정확한 결과 도출

3. sFlow → sFlow-RT Exporter를 시도했지만 플로우 모니터링에 적합하지 않고 부정확한 결과 도출

---

sFlow

sFlow는 sampled flow의 약자로, 이름처럼 패킷을 샘플링하고 이를 토대로 플로우 내용을 추산한다.

• 활용도: 탐지, 진단, 실시간 혼잡 제어(로드 밸런싱), 요금 청구를 위한 사용량 계산, 이상치 감지, 트래픽 경향 분석
• 특징: 네트워크 뷰 제공,  확장성, 저비용, 업계 표준 (주장), 다양한 벤더 제품 지원, 실시간 링크 모니터링 지원
• 샘플링 역사: 1991년 HP 데모 샘플링 > 1993년 HP Extended RMON 샘플링 > 1997년 Cisco ASIC 활용 샘플링 > 2001년 sFlow 시작
• 구조:

 

스위치/라우터의 ASIC이 패킷 샘플링 수행 > sFlow Agent가 interface counter와 flow sample을 sFlow datagram으로 만들고 sFlow Collector에게 전달

샘플링 되는 순간 바로 Collector에게 전송하는데, 전송하고 polling interval 동안 샘플링하지 않는다고 한다.

또한 특정 장비에서는 polling interval로 샘플링 패킷이 아닌 인터페이스의 statistict 값을 보낸다고 한다.

sFlow agent는 오픈 소스로 C언어 코드를 열어볼 수 있다.

• NetFlow와 기능 비교 (주장): 이것만 보면 sFlow는 모니터링계의 가제트 만능팔이다. 작성 연도가 2003년인 점은 참고

• 버전: 주로 v5을 사용하나 다른 버전도 존재
• 샘플: Datagram에 각 샘플링 데이터가 달려있는데, 종류는 Flow Sample, Counter Sample, Expanded Flow Sample, Expanded Counter Sample 총 4개가 있다.
  • Datagram

 

• Flow Sample: Sample Rate에 따라 샘플링한 플로우 데이터 

아래의 Raw packet header에는 샘플 패킷의 header가 그대로 들어가있다.

128 바이트는 나중에 OvS에서 설정할 Header Parameter 값이다.

• Counter Sample: Interface Counter 라고도 하며 Interface에 대한 MIB 정보를 Polling Interval에 따라 수집한다.
  Sequence Number는 Polling Interval의 몇번째 순서인지를 나타낸다.

아래에 Counter Record로 여러 종류가 있는데 대표격으로 Generic interface counter가 있다.

• 샘플링과 오차: 패킷 샘플링은 임의로 N개 중 1개를 샘플링하여 이뤄진다. 100%는 아니지만 특정한 정확도를 제공한다. 예시를 들어 설명하자면
  • 예시: 1,000,000개의 패킷 중 0.25% (2,500개)의 패킷을 샘플링했을 때 A 클래스(서비스)에 해당하는 패킷이 1,000개라면 모집단의 A 패킷 개수는 몇개인가?
  • 최소 1,000개에서 최대 998,500개일텐데 이 두 값은 가능성이 없고, 2,500개 중 1,000개에 해당하는 비율인 40%를 적용하여 400,000개의 A 패킷 개수를 유추할 수 있다.
    N_c = A 패킷 개수, c = 샘플된 A 패킷 개수, n = 샘플된 패킷 개수, N = 전체 패킷 개수
    \[ N_{c}=\frac{c}{n}*N \]
  • A 패킷 개수가 정확히 400,000개일 가능성은 적다.
  • 신뢰구간 95%를 설정한다면 A 패킷 개수는 381,000 ~ 419,000개이다.
    • 방법 1
      \[\sigma^{2}=N^{2}\cdot\frac{c(1-\frac{c}{n})}{n(n-1)}\]
      \[\left[N_{c}-1.96\sigma,N_{c}+1.96\sigma\right]\]
    • 방법 2
      SE = 표준오차, 정규분포 따른다고 가정
      \[\left[N_{c}-1.96\sigma,N_{c}+1.96\sigma\right]\]
      예시에서 표준오차 SE는 약 0.0098이고 신뢰구간 95% 에 대해 z = 1.96
      \[z*SE=1.96\cdot 0.0098\approx 0.0192\]
      \[z*SE=1.96\cdot 0.0098\approx 0.0192\]
  • 백분율 오차 (c = A 패킷 개수)
    $$  per_{error}\leq 196\cdot\sqrt{\frac{1}{c}} $$
    예시에서는 c가 1,000 이므로, 약 6%이다.
  • 정확도를 높이는 방법:
    1. Sampling Rate 증가: 더 많은 샘플을 취한다.
    2. 모니터링 기간 증가
    c와 오차의 상관관계 그래프:

• 정확한 패킷 집계:
  • Polling Counters: 카운터 정보를 집계한다. 그러나 서비스 종류를 구분할 수 없다.
  • 스위치에서 트래픽 플로우 데이터 집계: NetFlow는 온보드 플로우 캐시에 SrcIP, srcPort, dstIP, dstPort 튜플을 축적한다. 이 방식은 고부하 상황에서 메모리 요구량이 높아지는데, 일례로 DoS 공격을 받으면 초당 30,000 플로우가 생성돼서 스위치는 급속도로 캐시를 비워야한다. 그런 상황에서는 플로우 데이터가 유실될 수 있다. 집계가 Data Collector로 옮겨지기 전에 수행되기 때문에 잘못된 측정 하나가 전체 트래픽의 상당 부분을 차지할 수 있으며, 이 데이터가 포함된 패킷이 손실되면 전체 측정의 정확도에 영향을 미친다. 이럴 경우엔 최종 측정 정확도를 특정할 수 없다.
• Flow Smoothing(평활화)
  • Smoothing (평활화): 통계학과 이미지처리 분야에서 노이즈 현상을 배제하고 데이터의 중요한 패턴을 포착하기 위해 근사 함수를 만드는 것. 과도한 변동을 제거하고 추세적인 부분만 남겨둘 수가 있다.

• • 위 차트는 다른 평활화 레벨에 따른 그래프를 보여준다.
    1.25MB/s로 30초를 전송하고, 30초를 쉬는 식으로 반복했다.
    평활화 시간(t)를 1로 했을 때와 500으로 했을 때의 차이가 극명하다.
    500일 때는 균등하게 625KB/s로 전송한 것 처럼 보여진다.
  • 평활화 수준을 선택할 때, 반응성과 변동성(노이즈)는 상충 관계에 있다.
    변동성이 크면 반응성이 적고 반응성이 높으면 변동성이 적다.
  • 평활화 수준(시간)이 1이면 변동성이 크고 반응속도가 빠르다 (민감). 평활화 수준(시간)이 500이면 변동성이 작고 반응속도가 느리다 (둔감)
  • 낮은 평활화 수준은 빠른 반응속도가 요구되는 상황에 적합하다:
    • DDoS 탐지
    • 세그먼트 라우팅과 SDN을 활용한 leaf and spine 구조 트래픽 엔지니어링
      해당 구조에서 sFlow는 실시간 모니터링 기반 로드밸런싱을 장점으로 함
      https://blog.sflow.com/2015/06/leaf-and-spine-traffic-engineering.html
    • merchant silcon(네트워크 장비에 들어가는 표준화된 반도체 칩)을 활용한 인터넷 라우터
      기존 인터넷 라우터를 대체하는 화이트 박스 스위치. 실시간 데이터를 기반으로 라우팅 경로 수정.
  • 높은 평활화 수준은 적은 변동성이 요구되는 상황에 적합하다:
    • Netflix Vizceral(네트워크 트래픽 흐름을 노드와 엣지의 형태로 시각화하는 오픈소스 도구)을 통한 실시간 트래픽 시각화
    • 실시간 웹 분석: 웹 서비스 구조에서 Flow 사용
    • 캠퍼스 네트워크의 제어와 시각화
• Large Flow 감지와 적정 샘플링 레이트
  • Large Flow: 링크 대역폭의 최소 10% 이상을 소모하는 Flow
  • 감지하는데 소요되는 시간은 1초 ~ 2초이며
    10%보다 더 높은 대역폭을 차지한다면 소요 시간은 1초 이내까지 줄어들 수 있다.
  • 링크 속도별 Large Flow의 조건과 적정 샘플링 레이트
• sFlow-RT의 플로우 레이트는 신속한 탐지나 Large Flow 제어를 위한 것이다. (DDoS 탐지나 로드 밸런싱같은)
• 정확한 Flow Total을 알고싶다면 sFlow-RT를 flow records를 로깅하도록 설정해야한다.
  로그에는 순간 속도가 아닌 flow의 전체 총량이 들어있다. 

잘 찾아보면 토막글 수준의 한국어자료도 있긴 있다.

 

출처

https://inmon.com/technology/index.php

https://inmon.com/technology/papers.php

https://inmon.com/technology/sflowVersion5.php

https://sflow.org/

https://sflow.org/about/index.php

https://sflow.org/about/sampling_theory.php

https://sflow.org/developers/specifications.php

https://sflow.org/developers/tools.php

https://sflow.org/packetSamplingBasics/index.htm

https://blog.sflow.com/2018/04/flow-smoothing.html

https://blog.sflow.com/2013/06/large-flow-detection.html

https://cafe.naver.com/neteg/269374?art=ZXh0ZXJuYWwtc2VydmljZS1uYXZlci1zZWFyY2gtY2FmZS1wcg.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjYWZlVHlwZSI6IkNBRkVfVVJMIiwiY2FmZVVybCI6Im5ldGVnIiwiYXJ0aWNsZUlkIjoyNjkzNzQsImlzc3VlZEF0IjoxNzQyMzUyNDk1NTI1fQ.hbMpBkThFU0RIWgRqw87MoYWoWrPbVhTLD8y5yyqjZw