[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
8 likes6,407 views
네트워크 모니터링 시스템(nms)을 지탱하는 기술
![[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술](https://image.slidesharecdn.com/244nms-171017030833/85/244-nms-2-320.jpg)
![[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술](https://image.slidesharecdn.com/244nms-171017030833/85/244-nms-3-320.jpg)
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
- 1. 네트워크 모니터링 시스템(NMS) 을 지탱하는 기술 강영상 IT Platform Dev
- 5. NCP Region
- 6. 네트워크 모니터링
- 7. 발생된 문제 • 망 간의 거리 • 네트워크 장비 수 • 네트워크 장비 종류 수 • 배포시 수집 누락
- 8. 1. 망 간의 거리
- 9. SNMP (Simple Network Management Protocol) Network 장비 모니터링 방법의 de facto standard • UDP • <Key, Value> 형태로 성능값을 조회 Router GET Request ResponseNMS
- 10. 망 간의 거리 수집시 고려할 점 • 라우터의 SNMP 처리 성능 • 패킷당 요청 개수 : 최대 10여개 (Router 성능, 패킷 크기에 따른 제한) • 수집항목 개수 : 한 Router당 1,000 ~ 10,000개 Router GET Request Response NMS GET Request Response
- 11. 망 간의 거리 수집 시간이 1분을 초과할 수 있음 • Data 누락 • 이벤트 처리 오류 RTT 수집 시간 KR - CN 90ms 90s KR - US 220ms 220s KR - DE 290ms 290s
- 12. 망 간의 거리 Router의 리소스를 고려하여 수집시간을 줄일 수 있는 방법 필요 • 수집 서버를 Router 근처에 배치 • Multi-threading Data 누락을 없애고, 성능 수집으로 인해 Router에 주어지는 성능상 부담을 최소화 Router GET Request ResponseNMS
- 13. 2. 네트워크 장비 수
- 14. 네트워크 장비 수
- 15. 네트워크 장비 수 Scale-out 검토 필요 • Router 개수가 수 천 대씩 증가하기도 함 • 관련한 다양한 기술 검토 필요 : Kafka, Zookeeper, Hbase, Redis, Spark, Storm, … Scale-out이 안 된다면 • 갑작스러운 규모 증가에 대응이 어려움 • Global view 지원이 어려움
- 16. 네트워크 장비 수 Region #2 (유럽) Region #1 (한국) Region #3 (미국) Router Router Router Router Region 구분
- 17. 네트워크 장비 수 Region #2 (유럽) Region #1 (한국) Region #3 (미국) Router Router Router Router NMS Region별로 NMS 구축
- 18. 네트워크 장비 수 Region #2 (유럽) Region #1 (한국) Region #3 (미국) Router Router Router Router Collector Collector Region별로 Collector 구축
- 19. 네트워크 장비 수 Region #2 (유럽) Region #1 (한국) Region #3 (미국) Router Router Router Router Collector Collector Region별로 Collector 구축 Queue Consumer Hbase MySQL Consumer Event Processor FrontEnd Web API Performance Discovery Event Aggregator
- 20. 네트워크 장비 수 Region #2 (유럽) Region #1 (한국) Region #3 (미국) Router Router Router Router Collector Collector Queue Consumer Hbase MySQL Consumer Event Processor FrontEnd Web API Performance Discovery Event Aggregator Zookeeper Redis Batch
- 21. 네트워크 장비 수 Scale-out을 위해 • Region별 수집기 구축 • Kafka, Zookeeper, Redis, Hbase 사용 대규모 Router 증설에도 간단히 대응 가능 Global view 지원
- 22. 3. 네트워크 장비 종류 수
- 23. 네트워크 장비 종류 수
- 24. 네트워크 장비 종류 수 100
- 25. 네트워크 장비 종류 수 SNMP MIB 종류 : 100 Router GET 1.3.6.1.4.1.9.9.109.1.1.1.1.4 CPU 사용률 NMS GET 1.3.6.1.4.1.9.9.13.1.3.1.3.2 #2 센서 온도
- 26. 네트워크 장비 종류 수 장비 모델별 MIB 형식에 일관성이 없음 • A 모델 : 𝟏.𝟑.𝟔.𝟏.𝟒.𝟏.𝟑𝟑𝟕𝟓.𝟐.𝟏.𝟏.𝟐.𝟏.𝟒𝟓.𝟎 의 값 𝟏.𝟑.𝟔.𝟏.𝟒.𝟏.𝟑𝟑𝟕𝟓.𝟐.𝟏.𝟏.𝟐.𝟏.𝟒𝟒.𝟎 의 값 * 100 • B 모델 : 1.3.6.1.4.1.5951.4.1.1.41.2.0의 값 모델별로 수집기를 개발할 경우 100가지의 실행 코드가 생산됨
- 27. 네트워크 장비 종류 수 Performance Template CPU Used Memory Used Packets In Temperature Router Model A CPU Used #1.3.6.1.4.1.9.9.109.1.1.1.1.4.1# Memory Used #1.3.6.1.4.1.2636.3.1.13.1.11.9.1.0.0# Packets In #1.3.6.1.2.1.31.1.1.1.6.$indexNum$#*8 Temperature #1.3.6.1.4.1.9.9.13.1.3.1.3.$indexNum$# Router Model B CPU Used #1.3.6.1.4.1.5951.4.1.1.41.6.1.2.$indexNum$ # Memory Used #1.3.6.1.4.1.3224.16.2.1.0#/(#1.3.6.1.4.1.32 24.16.2.1.0#+#1.3.6.1.4.1.3224.16.2.2.0#)*1 00 Packets In #1.3.6.1.2.1.31.1.1.1.6.$indexNum$#*8 Temperature #1.3.6.1.4.1.3224.21.4.1.3.$indexNum$# • 추상화 • MIB 표현식
- 28. 네트워크 장비 종류 수 운영/개발 리소스 최소화 • Performance Template에 대해 동작하는 수집기 1개 • 수집기는 모델별 MIB 정보 분석(Parsing)하여 Data 수집 • Network 담당자가 신규 모델에 대한 MIB 정보 입력
- 29. 4. 배포시 수집 누락
- 30. 배포시 수집 누락 수집 서버 추가/제거, 수집기 배포 • 수집기 재시작 필요 • 수집기별 수집 대상 장비 변경됨 수집기 재시작 • 수집에 필요한 정보(Meta Data) loading • 새로운 목록에 대해 수집 시작 Data 누락 • 수집기별 loading 속도가 다름 • 수집 주기(1분) 내에 loading이 어려울 수 있음 : 원거리, data size
- 31. 배포시 수집 누락 최초 배포 시나리오 • Collector 종료 시 Membership에서 Leave 후 즉시 종료 • Master는 수집 대상 장비를 Reassign(1)하고 각 Collector는 새로운 수집 대 상 정보(1)를 읽음 • 배포 및 실행 후 즉시 Membership에 Join • Master는 수집 대상 장비를 Reassign(2)하고 각 Collector는 새로운 수집 대 상 정보(2)를 읽음 Leave ReassignJoin 11분 12분
- 32. 배포시 수집 누락 결과 • 11분의 수집 보장 안 됨 • 12분에 일부 Collector는 (1) 할당 정보로, 일부는 신규 설정(2)로 수집해서 누 락 및 중복 수집 • Leave 후에 다른 Collector가 준비할 때까지는 계속 수집을 해줘야 Loss가 없음 Leave ReassignJoin 11분 12분
- 33. 배포시 수집 누락 개선된 배포 시나리오 • 종료하는 Collector는 11분에 Membership에서 Leave (zk의 member 노드만 제거하고 실제 프로세스는 살아있음) • Master가 Reassign 하고, 14분에 모든 Collector가 Redis로부터 새로운 수집 대상 정보를 읽음 ==> 모든 Collector가 감지 • 15분이 되기 전까지는 기존 할당 정보로 수집 • 15분부터는 새로 Assign된 정보로 수집 11분 12분 13분 14분 15분 Leave 신규 수집 대상 정보 ReloadJoin
- 34. 배포시 수집 누락 결과 • 정상 수집 11분 12분 13분 14분 15분 Leave 신규 수집 대상 정보 ReloadJoin
- 35. 배포시 수집 누락 Coordinator를 이용한 구현 • Collector Leave시 Master는 수집 대상 정보 Reassign • Master는 Coordinator로써 Collector에게 Barrier를 시작하는 Alarm을 보냄 (Prepare) • Collector는 새로운 할당 정보를 읽고 Barrier에 참여하여 Barrier 완료를 기다림 (I’m ready) • Collector는 Barrier가 완료되기 전에는 기존 할당 정보로, 완료 후에는 새로운 할당 정보로 동작함 • Barrier가 완료되면 Master는 You may leave Alarm을 보냄 • Leave 하던 Collector는 Master로부터 You may leave를 받고 종료 Prepare I’m ready You may leave 11분 12분 13분 14분 15분 Leave Join
- 36. 해결책과 결과 • Router 근거리에 Collector 배치 • Scale-out • 장비 모델별 수집항목을 템플릿화 • 배포 시나리오 조정 Router에 Data 수집으로 인한 부담 최소화 운영 비용 최소화 Data 누락 최소화
- 37. Q & A
- 38. Thank you