요약

 

이번 발표를 준비하면서 가장 크게 배운 점은 발표는 단순히 내용을 잘 설명하는 것이 아니라, 분위기와 흐름을 만들어 내용을 듣기 좋게 전달하는 과정이라는 것이다.

발표의 시작부터 마무리까지 작은 요소들이 모여 전체적인 완성도를 결정한다는 것을 직접 경험했다. 특히 아래 다섯 가지가 발표의 퀄리티를 크게 좌우한다고 느꼈다.

  • 시작 멘트 : 첫인상을 결정하고 발표자와 청중 모두의 긴장을 풀어 분위기를 만든다.
  • 스토리 : 장표를 설명하는 것이 아니라 하나의 이야기처럼 자연스러운 흐름을 만들어야 한다.
  • 호흡 : 발표자는 내용을 알고 있지만 청중은 처음 듣기 때문에, 생각보다 더 천천히 말해야 전달력이 높아진다.
  • 강조 : 핵심 내용을 반복하거나 톤과 제스처를 활용해 청중의 집중력을 유지해야 한다.
  • 마지막 분위기 반전 : 발표가 끝나기 직전 분위기를 환기시키는 한마디나 이벤트는 발표의 마지막 인상을 더욱 강하게 남긴다.

이번 글에서는 발표를 준비하며 실제로 느꼈던 점과, 앞으로도 발표를 할 때 계속 활용하고 싶은 방법들을 정리해보려고 한다.


 

회사에 처음 입사했을 때 신입사원 집체교육을 받은 적이 있다.

약 2개월 동안 교육을 받고 마지막에는 교육 내용을 기반으로 발표를 진행했는데, 그때는 발표 방법도 잘 몰랐고 그냥 대본을 전부 외워서 발표했던 기억이 난다.

당시에는 본부장님과 각 팀장님들 앞에서 발표를 했었는데, 대본을 모두 외웠던 덕분인지 긴장은 거의 하지 않았고 나름 잘 마무리했다고 생각했다.

그런데 이번 발표를 준비하면서 문득 이런 생각이 들었다.

'그때는 잘했다고 생각했지만 지금 기준으로 보면 퀄리티가 많이 부족했겠구나.'

벌써 7년 정도가 지났지만 돌이켜보면 내용도 특별하지 않았고, 목소리 톤이나 전달력, 발표의 흐름도 많이 부족했을 것 같다. 그나마 긴장하지 않고 끝냈던 것이 운이 좋았던 것이라는 생각이 들었다.


Cisco AI 인프라 교육

이번에는 Cisco에서 진행한 AI 인프라 교육을 수강하게 되었다.

3차에 걸쳐 장기간 교육을 들었고, 마지막에는 교육 내용을 바탕으로 가상의 고객을 대상으로 제안서를 작성하고 발표하는 시간이 있었다.

발표를 준비하면서 느낀 점과 배운 점을 기록으로 남겨두면, 나중에 다시 발표를 준비할 때 큰 도움이 될 것 같아 정리해본다.


1. 시작 멘트

사람을 평가할 때 첫인상이 중요하듯 발표도 첫 멘트가 굉장히 중요하다고 느꼈다.

'시간 내어 참석해 주셔서 감사합니다.'
'이런 자리를 마련해 주셔서 감사합니다.'

이런 짧은 인사만으로도 내 긴장이 조금 풀리고, 발표장의 분위기 역시 훨씬 부드러워지는 느낌이었다.

그리고 이번 발표에서는 예상하지 못했던 아이스브레이킹도 있었다.

발표를 시작하고 자기소개와 인사를 했는데 평가자분들께서 환영의 의미로 박수를 쳐주셨다.

순간 긴장이 되긴 했지만 웃으면서 이렇게 말했다.

"갑자기 이렇게 환영의 박수를 보내주시니까 긴장이 확 되는데요. 그래도 열심히 준비했으니 잘 한번 시작해보겠습니다."

평가자분들도 함께 웃어주셨고, 시작부터 분위기가 굉장히 좋아졌다.

원래 이런 성격은 아니라 분위기를 전환하는 말을 잘 못하는 편인데, 이번에는 자연스럽게 나왔던 것 같다.

결론적으로,

발표 시작 분위기가 발표 전체의 흐름을 결정하는 데 가장 큰 영향을 주는 것 같다.


2. 발표는 '스토리'가 있어야 한다

이번 발표는 15분 정도였다.

길다고 할 정도는 아니지만 처음 연습할 때는 내가 발표를 하면서도 지루하다는 느낌을 받았다.

말을 하면서도

'내가 지금 무슨 말을 하는 거지?'

라는 생각이 들었고, 내용도 머리에 잘 들어오지 않아 외우기도 어려웠다.

장표 하나하나를 설명하는 것은 잘했지만, 발표 전체를 이어주는 스토리가 없었던 것이다.

그래서 발표의 흐름을 처음부터 다시 만들었다.

이번 발표는 고객 제안 발표였기 때문에 다음과 같은 순서로 구성했다.

  • 인사
  • 사업의 목적
  • 우리가 제안하는 내용 요약
  • 왜 이런 구성을 제안하는지
  • 어떤 방식으로 구현하는지
  • 공식 문서와 레퍼런스를 근거로 신뢰성 확보
  • 마무리

이렇게 전체 흐름을 만들어 놓으니 발표를 하는 나도 훨씬 이해하기 쉬웠고, 듣는 사람도 자연스럽게 따라올 수 있었다.


3. 호흡

나는 발표를 준비하면서 장표뿐만 아니라 대본도 함께 준비했기 때문에 발표 내용을 모두 알고 있다.

하지만 발표를 듣는 사람들은 아무것도 모른다.

사전에 제안서를 읽어본 사람도 있겠지만 그렇지 않은 사람도 많다.

그래서 내가 생각했던 것보다 훨씬 천천히 말하려고 노력했다.

호흡도 여러 번 끊어서 대본을 만들었다.

그렇게 하니

  • 발표 내용이 훨씬 잘 전달됐고
  • 장표의 어느 부분을 설명하는지도 이해하기 쉬웠으며
  • 나 역시 혀가 꼬이지 않아 전달력이 좋아졌다.

4. 강조

호흡을 조절한다고 해도 발표가 계속 같은 톤으로 이어지면 집중력이 떨어질 수 있다.

그래서 중요한 단어나 꼭 전달해야 하는 부분에서는 손동작을 사용하거나 목소리 톤을 높여 강조했다.

솔직히 이 부분이 얼마나 효과가 있었는지는 잘 모르겠다.

하지만 발표가 길어질수록 앞에서 했던 내용을 기억하기 어려운 것은 분명하다.

그래서 꼭 전달해야 하는 핵심 장표를 몇 개 정해두고, 다음 장으로 넘어가기 전에 반드시 핵심을 한 번 더 정리했다.

예를 들면

"그래서 이 슬라이드의 핵심은 ○○입니다."

이렇게 한 번 더 상기시켜 준 뒤 다음 내용으로 넘어갔다.

개인적으로 이 방법은 꽤 괜찮았던 것 같다.


5. 마지막 분위기 반전

이번 발표는 고객 제안 발표였기 때문에 전체적으로 조용하고 정숙한 분위기에서 진행되었다.

물론 이 방법은 발표 장소나 발표 내용, 평가자 성향 등을 고려해서 사용해야겠지만, 이번에는 좋은 효과를 봤기 때문에 기록으로 남겨둔다.

약 10분 동안 평가자분들은 계속 발표를 듣고 계셨다.

그래서 마지막에는 분위기를 조금 바꿔보고 싶었다.

이번 제안과 관련된 키워드를 활용해 삼행시(정확히는 Cisco 5행시)를 준비했다.

결과는 생각보다 훨씬 좋았다.

평가자분들이 웃으셨고, 발표가 끝난 뒤 전체적인 분위기도 상당히 좋아졌던 것으로 기억한다.

그리고 마지막 마무리 인사 역시 시작 인사만큼 중요하다는 것도 느꼈다.


느낀 점

이번 발표를 준비하면서 발표는 단순히 내용을 설명하는 것이 아니라는 것을 많이 느꼈다.

발표를 하려면 장표의 내용을 완전히 이해하고 있어야 하고, 준비가 완벽하게 끝날수록 긴장도 훨씬 줄어든다는 것을 다시 한번 느꼈다.

그리고 이번 경험을 통해 신입사원 시절 했던 발표를 떠올려보니, 그때는 잘했다고 생각했지만 지금 기준으로 보면 많이 부족했겠다는 생각도 들었다.

아직은 주니어라 이렇게 많은 사람들 앞에서 발표할 기회가 많지는 않다.

그래서 이번 경험은 정말 값진 경험이었고, 발표를 준비하면서도 많은 것을 배울 수 있었다.


결과

결과는 2등이었다.

1등을 하지 못한 것은 아쉬웠지만, 발표를 준비하고 발표 자체를 경험하면서 얻은 것이 훨씬 많았다.

다음에 비슷한 기회가 생긴다면 이번 경험을 바탕으로 더 좋은 발표를 해보고 싶다.

 

이부분은 이해가 안가서 번역만한 수준

 

4 가지 NVIDIA 제품 상세 설명

각 제품 의미와 사용 환경, 장/단점

 

1. NVIDIA Base Command Platform

의미

AI 개발 전반을 단일 창 (Single Pane)

클라우드 호스팅 AI 개발 허브로, 온프레미스와 클라우드에서 호스팅되며 여러 사용자/팀에 걸쳐 진행되는 AI 개발 워크플로우를 위해 설계됩니다:

 

Base Command Platform: AI 라이프사이클 허브

사용 환경

항목 내용
주요 환경 entreprise AI 개발팀 (데이터 과학자, IT 팀) 
서버 NVIDIA DGX 플랫폼 지원 
호스팅 온프레미스 + 클라우드 (하이브리드) 
용도 AI 개발 워크플로우 관리 (프로비저닝 → 모니터링 → 리포팅) 

장점

장점 설명
단일 창 관리 통합 모니터링 + 리포팅 대시보드 (GUI + CLI API) 
라이프사이클 관리 AI 개발 전반 (시제품 → 생산) 관리 
자원 최적화 사용자/팀 간 자원 최적화 
워크로드 관리 워크로드 관리 + 자원 공유 

단점

단점 설명
클라우드 의존성 클라우드 호스팅 시 비용 발생 
DGX 의존성 DGX 플랫폼에게 최적화 (다른 플랫폼은 제한적)

 

2. NVIDIA DGX Cloud

의념

AI 슈퍼컴퓨팅 서비스

NVIDIA DGX AI 슈퍼컴퓨팅 전용 클러스터를 클라우드에서 바로 사용할 수 있는 서비스로, 기업들이 생성형 AI와 획기적인 애플리케이션을 위한 고급 모델을 훈련하는 데 필요한 인프라와 소프트웨어에 즉각적인 액세스를 제공합니다:

 

DGX Cloud: NVIDIA DGX AI 슈퍼컴퓨터를 클라우드에서 즉시 액세스

사용 환경

항목 내용
주요 환경 클라우드 기반 AI 개발 (기업) 
서버 NVIDIA DGX AI 슈퍼컴퓨팅 전용 클러스터 
호스팅 클라우드 호스팅 (월 단위 임대) 
용도 대규모 멀티 노드 훈련 워크로드 개발 

장점

장점 설명
즉각 액세스 온프레미스 구축, 배포, 관리 복잡성 제거 
월 단위 임대 수요 증가 시 가속 컴퓨팅 리소스 기다림 없음 
대규모 훈련 대규모 멀티 노드 훈련 워크로드 빠른 확장 
간단 액세스 웹 브라우저로 자체 AI 슈퍼컴퓨터 액세스 

단점

단점 설명
클라우드 비용 월 단위 임대료 지속 발생 
데이터 이전 대규모 데이터 클라우드 업로드 필요

 

3. NVIDIA LaunchPad

의미

NVIDIA 인증 시스템과 DGX 시스템으로 전체 NVIDIA AI 소프트웨어 스택 실행 프로토타이핑

NVIDIA 에서 직접 사용하는 가속화된 인프라에서 실행되는 최적화된 소프트웨어에 대한 즉각적인 액세스를 제공하며, 선별된 랩 세트를 통해 고객 데이터 사이언스와 AI 워크로드 프로토타이핑, 테스트를 지원합니다:

 

LaunchPad: AI 인프라 프로토타이핑 + 테스트 랩

사용 환경

항목 내용
주요 환경 AI 개발 프로토타이핑 (기업) 
서버 NVIDIA 인증 시스템 + DGX 시스템 
호스팅 NVIDIA 랩 기반 (온프레미스) 
용도 AI 워크로드 프로토타이핑 + 테스트 

장점

장점 설명
즉각 액세스 NVIDIA AI 소프트웨어 스택 즉시 사용 
선별된 랩 데이터 사이언스 + AI 워크로드 프로토타이핑
무료 경험 AI 개발/배포 소프트웨어 모두 무료 경험 

단점

단점 설명
제한된 기간 랩 세션 시간 제한 (일정 시간만 사용)
프로토타이핑만 실제 배포는 직접 구축 필요

 

4. NVIDIA DGX SuperPOD

의미

턴키 AI 데이터 센터 솔루션 (전체 주기의 업계 최고의 인프라)

데이터센터 규모의 완벽한 AI 슈퍼컴퓨터로, NVIDIA 인증 파트너의 고성능 스토리지와 통합되어 생성형 AI 워크로드 수요를 충족합니다. 초대형 생성형 AI 훈련과 추론 작업을 위해 일정한 가동 시간 동안 수조 개 파라미터 모델 처리:

 

DGX SuperPOD: 턴키 AI 데이터 센터 인프라

사용 환경

항목 내용
주요 환경 대규모 AI 데이터 센터 (연구 기관, 기업) 
서버 NVIDIA DGX A100 시스템 (20~140 개 클러스터) 
호스팅 온프레미스 데이터 센터 (전체 구축)
용도 대규모 AI 훈련 + 추론 워크로드 

장점

장점 설명
대규모 AI 수조 개 파라미터 생성형 AI 모델 학습 최적화 
고성능 5 페타플롭스 AI 성능 (DGX A100) 
InfiniBand Mellanox HDR InfiniBand (저지연, 고대역폭) 
턴키 솔루션 설치 및 배포 시 추측 배제 가능 
연구 기관 최적화 대규모 AI 혁신을 위한 가장 빠른 길 

단점

단점 설명
초기 비용 온프레미스 구축 비용 매우 높음
규모 제한 대규모 데이터 센터만 적합 (소규모는 비효율)
관리 복잡성 전담 관리 인력 필요

 

4 가지 비교 요약

제품 의미 사용 환경 주요 장점 주요 단점
제품 의미 사용 환경 주요 장점 주요 단점
Base Command AI 개발 워크플로우 관리 엔터프라이즈 AI 개발팀 (하이브리드) 단일 창 관리 + 라이프사이클 클라우드 비용
DGX Cloud 클라우드 AI 슈퍼컴퓨팅 클라우드 기반 AI 개발 (기업) 즉각 액세스 + 월 단위 임대 지속 비용
LaunchPad AI 프로토타이핑 랩 AI 개발 프로토타이핑 (기업) 즉각 액세스 + 무료 경험 제한된 기간
DGX SuperPOD 턴키 AI 데이터 센터 대규모 AI 데이터 센터 (연구 기관) 대규모 AI + 고성능 초기 비용

 

한 줄 요약

Base Command = AI 개발 관리

DGX Cloud = 클라우드 AI 슈퍼컴퓨터

LaunchPad = 프로토타이핑 랩

DGX SuperPOD = 턴키 AI 데이터 센터

BlueField / PXN 정리표

항목 내용
BlueField DPU mode ARM 코어가 NIC data path를 소유하면서 호스트가 DPU OS에 접근 가능.
BlueField Smart NIC mode ARM 코어가 NIC data path를 소유하면서 호스트가 DPU OS에 접근 가능.
PXN NVLink로 연결된 GPU와 NIC 간 통신을 개선.
다른 노드의 다른 GPU와 통신할 때 NVLink를 최대한 활용하여 고속통신 지원

NVIDIA 공식 자료 흐름에서도 NVLink는 intra-node GPU 통신, InfiniBand와 RoCEv2는 inter-node 통신의 역할 분담으로 정의

또 PXN은 GPU-to-NIC 경로를 최적화해 멀티 GPU에서 bandwidth utilization을 높이는 방향으로 정리하면 됩니다.

2) Spectrum-X / NetQ / UFM 정리표

Spectrum-X 핵심

항목 내용
SN5600 / Spectrum-4 64포트 800GbE, 51.2Tb/s급 AI Ethernet 스위치.
RoCE Adaptive Routing 링크 장애나 혼잡 시 최적 경로로 자동 재분산.
Congestion Control egress queue load를 기준으로 혼잡을 평가.
Traffic Isolation 멀티테넌트 환경에서 tenant 간 간섭과 비인가 접근을 줄이는 기능.
Out-of-order handling BlueField-3 SuperNIC이 패킷 재정렬을 담당.

NVIDIA 공식 자료에서도 Spectrum-X는 AI 워크로드용 Ethernet 플랫폼이며, Spectrum-4 스위치와 BlueField 계열 SuperNIC을 결합해 고대역폭, 저지연, 혼잡 제어를 제공하는 구조로 설명됩니다.

NetQ 핵심

항목 내용
주요 역할 패브릭 검증, 실시간 가시성, 문제 분석, 운영 자동화.
Air와 연동 디지털 트윈 환경에서 설정 검증에 활용.
Flow Analysis Cumulus 5.x 이상, Spectrum-2 이상, LCM 활성화 필요.
Behavioral telemetry 서버/애플리케이션 행동과 네트워크 이벤트를 연결해 root cause 분석.


Behavioral Telemetry의 핵심 역할
세부 기능:


서버 동작 패턴 분석: CPU, 메모리, 네트워크 사용량 모니터링


애플리케이션 동작 패턴 분석: 워크로드 패턴, 트래픽 흐름 분석


이상 징후 조기 식별: 정상 패턴과 비정상 패턴 비교


Root Cause 분석: 문제의 근본 원인 파악

 NetQ가 “Fabric validation”과 “digital twin 검증”에 직접 연결되어 나오고, WJH와 DOCA telemetry, behavioral telemetry를 함께 묶는 형태로 더 강조

UFM(Unified Fabric Manager) 핵심

 
항목 내용
UFM Telemetry 실시간 성능/카운터/케이블 정보 수집.
UFM Enterprise InfiniBand fabric 운영/관리 플랫폼.
UFM Cyber-AI 보안 위협, 이상 징후, 네트워크 실패 예측.
Network Traffic Map 혼잡, 지연, 구성 변경 영향 분석에 유용.

UFM Cyber-AI는 NVIDIA 공식 문서에서 AI 기반 분석으로 이상 동작과 실패 가능성을 예측하는 플랫폼으로 설명

 

 

++ NetQ 추가설명

더보기

NetQ?

  • 실시간 네트워크 Visibility(가시성), Validation(검증) 제공하는
  • Advanced 텔레메트리를 활용한 워크플로우 자동화, 다운타임 최소화 목적

 

대상장비

 - Cumulus Linux

 - SONIC

 - DPU ( 주기적인 Health, Data 수집 )

 

Deployment & using

 - NVIDIA Air or On-prem

 - GUI 접근 방식

 

Feature

 - Pre-production -> Production 전체 라이프사이클 최적화

 - 네트워크 유효성검사/오류 방지(MTU Mismatch )

 - WJH 기능을 통한 패킷드롭 실시간 인식

 - Flow telemetry 사용한 패킷 흐름 분석

 - 퍼포먼스 모니터링

 - latency Agents BGP,RoCE 카운터 모니터링

 - Data aggregation

 

Intigrations

 - 스위치, DPU에서 On-premise telemetry aggregator NoSQL DB 데이터를 전송합니다.

 - API Gateway 사용해 오케스트레이션 , Slack 연동 가능

 - Grafana 같은 third party 툴과 연동 가능

++ WJH 추가설명

더보기

WJH 목적

 - What Jus Happened 패킷 드롭, 네트워크 이슈 실시간으로 파악하는 솔루션

 - 트러블슈팅 도움 다운타임 최소화로 생산성 향상

 - 병목 탐지, 느린 구간 발견, 버퍼 오버플로로 인한 추가 드롭 예방에 도움

 - layer 1~3, overlay, ACL, buffer 같은 유형 분석

Layer 1 - optic, CRC, nego

Layer 2 - Vlan Misconfig

Layer 3 - routing, ttl issue

Overlay  - VxLAN, Encap/Decap

ACL - rule, counter

Buffer - tail drop, WRED drop, Alert

 

동작원리

 - 스위치(Specturm only) 내부 상태(internal state) 활용한 이벤트 로그 분석

**WJH Cumulus Linux 4.4.0 이상 버전이 설치된 NVIDIA Spectrum 스위치에서만 지원됩니다. WJH 지연 시간 및 혼잡 모니터링은 NVIDIA Spectrum-2 스위치 이상에서 지원됩니다. SONiC gNMI를 통해서만 WJH 데이터 수집을 지원

 - 실시간 이벤트 분석 기능으로 패킷드롭, 라우팅 이슈, 혼잡, MTU 이슈 확인

 - 드롭이 발생하면 패킷 헤더 정보와 함께 이벤트를 생성

 

NetQ 통합

 - NetQ 통합하여 중앙 집중형 관리 가능

 - NetQ에서 WJH기능을 통해 시각화

 

 

 

 

 

 

Nvidia 공식 아카데미에서 제공하는 무료 강의 공부 후 키워드 위주로 정리한 내용입니다.(AI Network 코스)

 

1. 요약

• InfiniBand 기본 개념 & 툴
• DMA, RDMA, PKey/Partition, Adaptive Routing, IB Router, Subnet Manager 등.
• ibdiagnet, ibnetdiscover, ibping, ib_write_bw, ibstat, ibpathverify, sminfo 등 InfiniBand 유틸리티 사용 목적.
• Spectrum-X (Ethernet AI Fabric)
• SN5600/Spectrum-4, RoCE Adaptive Routing/Performance Isolation, congestion 평가 방식, rail-optimized topology 등.
• NetQ / UFM / Telemetry / WJH
• NetQ의 역할(패브릭 검증, Flow Analysis, Adaptive Routing 모니터링 등).
• UFM Telemetry / Enterprise / Cyber-AI 구분, UFM Traffic Map 사용하는 경우.
• WJH(What Just Happened) 기능, Cumulus 스위치에서 모니터링 가능한 레이어.
• BlueField DPU & DOCA
• BlueField 동작 모드(DPU mode 등), DOCA 업그레이드 절차, BlueField가 담당하는 오프로드(보안·네트워킹·PCC).
• Cumulus Linux / NVUE / MLNX-OS / Ansible
• Cumulus 업그레이드 시 백업해야 하는 디렉터리, bond 설정 명령, EVPN Multi-homing, NVUE ignore 설정 의미.
• MLNX-OS 계정 타입(admin/monitor).
• NVUE Ansible Collection roles.
• NVIDIA Air / CloudAI Benchmark / Network Operator 등 관리·시뮬레이션 도구
• Air에서 링크 정의 문법, Air+NetQ로 digital twin 검증.
• CloudAI Benchmark로 성능 baseline.
• Kubernetes용 Network Operator 역할.
• GPU-accelerated Networking / NVLink / NCCL
• NVLink 목적, NCCL-SHARP, PXN, IB Router 지원 환경 변수, GPU-accelerated networking의 이점.
• Multi-tenancy / 보안 (PKey, VRF, BlueField)
• InfiniBand PKey full/limited membership 조합, UFM RBAC, Spectrum-X에서 L3VNI/VRF로 테넌트 분리.
• BlueField로 보안·프라이버시, dedicated storage fabric 필요성.
이 정도로만 머릿속에 카테고리 만들어두면, 각 문제를 어느 “상자”에 넣어야 할지 정리가 됩니다.



2. 각 주제별 핵심 포인트

 

InfiniBand 기본 & 툴
• 핵심 개념
• DMA: CPU 개입 없이 장치 간 메모리 전송, CPU 오버헤드 감소·지연 감소·대역폭 증가.
• RDMA: 원격 메모리를 직접 읽고 쓰는 기술, CPU 부하 줄이고 전송 지연을 크게 줄여 AI/HPC에 필수.
• PKey(Partition): InfiniBand에서 multi-tenancy와 트래픽 격리를 위한 논리 파티션, full vs limited membership.
• Adaptive Routing: 현재 혼잡 상태에 따라 동적으로 경로를 선택해, 대역폭 활용 극대화.
• IB Router: 여러 InfiniBand 서브넷을 연결해서 서로 통신할 수 있게 하는 장비.
• 대표 툴 & 용도
• ibdiagnet: 패브릭 전체 진단·오류 탐지·리포트, 라우팅 검증까지 수행.
• ibnetdiscover: 패브릭 토폴로지 디스커버리, LID/링크 속도 등 포함한 맵 생성.
• ibping: InfiniBand용 ping, 기본 연결성 테스트.
• ib_write_bw: 두 엔드포인트 간 RDMA write 대역폭 측정 (속도 검증용).
• ibstat -d mlx5_X: InfiniBand 인터페이스 상태/링크 레이어 확인.
• sminfo + smpquery ND <LID>: 현재 마스터 Subnet Manager가 어느 서버인지 LID→호스트명 추적.
• 시험 팁 예시
• “전체 패브릭 헬스/리포트” = ibdiagnet, “토폴로지/포트/LID/속도 맵” = ibnetdiscover, “대역폭 측정” = ib_write_bw, “ICMP 같은 연결성 테스트” = ibping 으로 자동 매핑되게 외우기.

Spectrum-X & RoCE / Congestion Control
• 스위치 & 하드웨어
• SN5600 (Spectrum-4): 64포트 800GbE, 총 51.2Tb/s, Spectrum-X 레퍼런스 아키텍처의 핵심.
• Spectrum-3: 400Gb/s Ethernet 스위칭 제공 (AI 워크로드용 고속 이더넷).
• Adaptive Routing & Congestion
• Spectrum-X에서 혼잡 평가는 “각 포트 egress queue load 분석 → 가장 부하 적은 포트 선택”.
• RoCE Adaptive Routing: 링크 장애나 혼잡시에도 최적 경로로 자동 우회하여 성능 유지.
• Congestion Control 알고리즘 실행 주체는 BlueField-3 SuperNIC (초당 수백만 이벤트 처리).
• Congestion이 발생하는 이유 : microburst, incast, low entropy(트래픽의 다양성이 낮음) 트래픽으로 인한 링크 부하분산
• 레퍼런스 아키텍처 요구사항
• Spectrum-X RA에서 Adaptive Routing: SN5600 + BlueField-3 SuperNIC + DDR(Dynamic Datagram Routing) + RoCE 트래픽 조합.

NetQ / UFM / Telemetry / WJH
• NetQ
• 역할: 패브릭 구성 자동 검증, 실시간 헬스 모니터링, Adaptive Routing 효과 분석, Flow Analysis.
• Flow Analysis 전제조건: Cumulus 5.x 이상 + Spectrum-2 이상 스위치 + LCM 활성화.
• Air와 연동: Air에서 구성한 디지털 트윈에 NetQ로 CI/CD 테스트 & 검증.
• Telemetry 소스: WJH, DOCA Telemetry, Behavioral Telemetry까지 결합해서 서버·애플리케이션 root cause 추적.
• WJH (What Just Happened)
• 목적: “왜 패킷이 드롭됐는지” 맥락 포함해서 알려주는 기능.
• L1/L2/L3, 터널, 버퍼, ACL 관련 문제까지 모니터링·텔레메트리 제공 (Cumulus WJH 서비스).
• UFM (Unified Fabric Manager)
• Telemetry: 실시간 성능·포트 카운터·케이블 정보 수집.
• Enterprise: 전체 InfiniBand 환경 관리·최적화.
• Cyber-AI: AI 기반으로 이상행위 분석, 보안 위협·장애 가능성 예측.
• Network Traffic Map: 혼잡/지연, 설정 변경 후 영향, 작업 분산 최적화에는 유용하지만, 단일 노드 하드웨어 장애에는 덜 유용.

BlueField DPU & DOCA
• BlueField DPU 역할
• 보안·네트워킹·스토리지 처리 offload → CPU는 AI 연산에 집중.
• 데이터 암호화, 방화벽, 침입 탐지 등을 DPU에서 처리해 데이터 프라이버시·보안 강화.
• 모드
• DPU mode: ARM 코어가 NIC 데이터 경로를 소유하지만, 호스트에서 DPU OS 접근 가능.
• DOCA 업그레이드
• 업그레이드 전: /usr/sbin/ofed_uninstall.sh -force 실행해 기존 OFED 제거가 필수.

Cumulus Linux / NVUE / MLNX-OS / Ansible
• Cumulus 업그레이드
• 반드시 마이그레이션/백업할 디렉터리: /etc/network (인터페이스), /etc/cumulus/acl (ACL), 기타 /etc 전체가 중요하지만 시험은 이 둘을 정답으로 요구.
• EVPN Multi-homing
• Cumulus Linux에서 active-active 서버 이중화 제공, 별도 inter-switch 링크 없이 EVPN MH로 구현.
• NVUE
• bond 설정: nv set interface bond1 bond mode lacp (bond1을 LACP로 설정).
• “Linux 파일 무시” 설정 이유: 일부 설정을 NVUE 아닌 flat-file/Ansible로 유지하고 싶을 때, NVUE가 덮어쓰지 못하게 하려는 것.
• MLNX-OS 계정
• admin: 전체 설정 변경 가능, monitor: 조회만 가능한 계정.
• Ansible NVUE Collection
• pre-built roles: 여러 스위치 모델에 공통 설정을 쉽게 적용하도록 미리 만들어 둔 역할 세트.

NVIDIA Air / CloudAI Benchmark / Network Operator
• NVIDIA Air
• 역할: Spectrum-X 네트워크를 디지털 트윈으로 시뮬레이션하는 클라우드 기반 도구.
• 링크 정의 문법 예: "spine-01":"swp01" -- "gpu-leaf-01":"swp41".
• NetQ와 함께 CI/CD 테스트 및 구성을 검증하는 용도.
• CloudAI Benchmark
• Spectrum-X 환경에서 throughput·latency 등 성능 지표 측정해서 baseline 만들 때 사용.
• Network Operator (Kubernetes)
• 역할: Kubernetes 클러스터에서 Spectrum-X 기반 네트워킹 구성 자동화, RDMA·GPUDirect RDMA 활성화 포함.

GPU-accelerated Networking / NVLink / NCCL
• NVLink
• GPU 간 고속, 저전력 인터커넥트, 멀티 GPU AI 워크로드 스케일링에 필수.
• NCCL 관련
• SHARP 사용 시: NCCL_COLLNET_ENABLE=1, NCCL_SHARP_AUTOINIT=1 필요.
• PXN: GPU↔NIC 통신 효율 개선.
• multi-subnet InfiniBand: NCCL_IB_USE_IB_ROUTER 등으로 IB Router 지원 → 서브넷 간 집단 통신 가능.
• GPU-accelerated Networking 효과
• GPU에서 네트워킹 일부를 처리해 지연 감소, 대역폭 향상 → 학습/추론 속도 향상.

Multi-tenancy / 보안 (PKey, VRF, BlueField)
• InfiniBand PKey 멤버십
• full membership: 같은 PKey 내 full 및 limited 모두와 통신 가능.
• limited membership: full 멤버와만 통신, 동일 limited끼리는 통신 불가.
• 스토리지 공유·테넌트 간 격리 시: 스토리지 = full, 각 테넌트 GPU = limited.
• Spectrum-X 네트워크 격리
• L3VNI per VRF: VRF마다 L3 VNI로 테넌트 격리.
• VRF 자체가 테넌트별 네트워크 분리의 핵심 기능.
• BlueField & 보안
데이터 암호화, 방화벽, 마이크로세그멘테이션 등 인프라 작업을 offload해 금융·규제 환경에서 프라이버시·보안 요구를 만족.

 

NicClusterPolicy(NVIDIA NicClusterPolicy Custom Resource)는 Kubernetes 에서 NVIDIA 네트워킹 컴포넌트를 자동화하는 도구입니다:

알고리즘 최단경로 Deadlock-Free 주 사용 환경
MinHop O X 소규모
UPDN X O 일반 Fabric
Fat Tree O O AI/HPC
LASH O O HPC
DOR O O Mesh/Torus
Torus-2QoS O O Torus

토폴로지 정리

더보기

1. MinHop Routing

가장 기본적인 알고리즘입니다.

A → B로 갈 때 홉 수가 가장 적은 경로를 선택합니다.

특징

  • 최단 경로 선택
  • 계산이 매우 빠름
  • OpenSM 기본 알고리즘

단점

  • 트래픽 집중 가능
  • Credit Loop 발생 가능
  • Deadlock-Free 보장 안 함

시험 포인트

 

MinHop = Shortest Path

MinHop ≠ Deadlock Free

 

2. Up/Down (UPDN) Routing

Deadlock 방지를 위해 만들어진 알고리즘입니다.

특징

  • Deadlock-Free
  • Credit Loop 방지

단점

  • 최적 경로가 아닐 수 있음
  • 일부 링크 활용도 감소

시험 포인트

 

UPDN = Deadlock Free

 

3. Fat Tree Routing

AI/HPC에서 가장 많이 사용하는 알고리즘

토폴로지

 

      Spine

    /  |  \

 Leaf Leaf Leaf

특징

  • Fat Tree 전용
  • ECMP 활용
  • Deadlock-Free

장점

  • 대규모 GPU 클러스터 적합
  • 링크 사용률 우수

사용 환경

  • NVIDIA Quantum
  • Quantum-2
  • Quantum-X800

시험 포인트

 

Fat Tree = HPC 표준

 

4. LASH Routing

Layer Assignment Shortest Path

목적

MinHop의 단점 해결

특징

 

Shortest Path

+

Deadlock Free

장점

  • 최단 경로 유지
  • Credit Loop 방지

단점

  • 계산 복잡

 

5. DOR (Dimension Order Routing)

주로 Mesh/Torus 환경

특징

  • Deadlock-Free
  • Mesh/Torus 최적화

 

6. Torus-2QoS Routing

Torus 토폴로지 전용

순환 의존성 제거

목적

Deadlock 방지

 

목차

  1. 테스트 구성
  2. Ansible 플레이북 디렉터리 구조 설정
  3. Ansible NX-OS 변수 개요
  4. Ansible 설정 파일 / 전역 변수 파일 생성
  5. Ansible 호스트 변수 및 역할 변수 파일 생성
  6. 스파인 역할 작업 파일 생성
  7. 리프 역할 작업 파일 생성
  8. Ansible 호스트 파일 생성
  9. 메인 Ansible 플레이북 생성
  10. Ansible 플레이북 실행
  11. 동작 확인

 

 

테스트 구성

이번 실습은 Ansible을 통해서 Cisco Nexus 장비에 설정을 배포하는 실습을 진행하겠습니다.

환경

 - 가상화 장비 (N9K-C9300v)

 - nxos 10.5.2.F

 

설정 범위

- Hostname

- loopback interface

- enable feature

- OSPF

- BGP

 

Ansible 플레이북 디렉터리 구조 설정

 

 

서버에 접속하여 Playbooks 디렉토리를 생성 -> 새로 생성된 Playbooks 디렉토리로 이동 -> NXOS 플레이북을 저장할 Ansible-NXOS라는 디렉토리를 생성하고 해당 디렉토리로 이동 -> group_vars, host_vars, roles 디렉토리 생성

mkdir Playbooks
cd Playbooks
mkdir Ansible-NXOS
cd Ansible-NXOS
mkdir group_vars
mkdir host_vars
mkdir roles

 

 

Ansible Galaxy를 사용하여 roles 디렉터리 내에 역할을 생성할 것입니다. Ansible Galaxy는 역할을 다운로드하거나 생성하기 위한 공식 커뮤니티 도구입니다.

cd roles
ansible-galaxy init spine
ansible-galaxy init leaf

 

 

리프 디렉터리와 스파인 디렉터리가 동일한 구조를 공유하는 것을 확인할 수 있습니다. 

`defaults`와 `vars` 디렉터리에는 tasks에서 사용할 변수들이 저장되고, 태스크 자체는 `tasks` 디렉터리 안에 저장됩니다.
디렉터리 아래에 ".yml" 파일이 있는 것을 볼 수 있습니다 플레이북은 YAML이라는 간단한 마크업 언어로 작성됩니다.

*명령어 "tree"

 

 

Ansible NX-OS 변수 개요

 

 

1) 기존 Ansible 네트워크 모듈인 nxos_config와 nxos_pim_rp_address

2) 변수와 변수 사용 방법.
각 네트워크 모듈에 대한 문서에는 모듈의 기능에 대한 개요와 매개변수 또는 키 표가 포함되어 있습니다. 표로 정리된 매개변수는 사용자가 모듈이 작업을 수행하는 데 필요한 필수 매개변수, 선택 사항 매개변수 및 매개변수의 기본값을 확인할 수 있도록 합니다.

위와 같은 형식이니 알고 넘어가면 좋습니다.

 

Ansible 설정 파일 / 전역 변수 파일 생성

 

 

Ansible 파일 생성을 위해 Ansible-NXOS 디랙토리로 이동합니다.

 

 

호스트 키 검사를 비활성화하는 ansible.cfg 파일을 생성하겠습니다.

touch ansible.cfg
cat <<EOF >> ansible.cfg
[defaults]
host_key_checking = False

EOF

 

 

모든 Node에 동일하게 적용할 내용을 all 파일로 관리합니다. ansible_connection과 nxos_provider에 대한 내용을 생성하겠습니다. 이 파일은 키/값 쌍으로 구성되며, group_vars/all은 모든 장치에 적용되는 범용 변수를 저장하는 위치입니다.

touch group_vars/all
cat <<EOF >> group_vars/all
---

ansible_connection: httpapi
ansible_httpapi_use_ssl: yes
ansible_httpapi_validate_certs: no
ansible_network_os: nxos
ansible_user: admin
ansible_httpapi_pass: admin
EOF

** ansible_connection: httpapi / ansible_httpapi_use_ssl: yes 두 명령어로 인해 SSH가 아닌 HTTPS로 통신

** Cisco 권장사항이 HTTPS를 통한 NX-API를 사용하는 것이기 때문에 api로 실습

 

Ansible 호스트 변수 및 역할 변수 파일 생성

 

 

각 역할에 대해 장치별로 사용할 변수와 해당 역할에 지정된 모든 장치에서 공통으로 사용할 변수를 생성해야 합니다. 장치별 변수는 각 장치의 `host_vars` 디렉터리에 정의됩니다. 

 

# 장치별 변수 생성

Spine1 yaml 파일

더보기

touch host_vars/10.202.32.111.yml
cat <<EOF >> host_vars/10.202.32.111.yml
---
# vars file for Spine1

router_id: 10.202.32.111

loopbacks:
  - { interface: loopback0, addr: 10.0.0.111, mask: 32 }
  - { interface: loopback1, addr: 1.1.1.1, mask: 32 }
EOF

Spine2 yaml 파일

더보기

touch host_vars/10.202.32.112.yml
cat <<EOF >> host_vars/10.202.32.112.yml
---
# vars file for Spine2

router_id: 10.202.32.112

loopbacks:
  - { interface: loopback0, addr: 10.0.0.112, mask: 32 }
  - { interface: loopback1, addr: 1.1.1.1, mask: 32 }
EOF

Leaf1 yaml 파일

더보기

touch host_vars/10.202.32.101.yml
cat <<EOF >> host_vars/10.202.32.101.yml
---
# vars file for Leaf1

router_id: 10.202.32.101

loopbacks:
  - { interface: loopback0, addr: 10.0.0.101, mask: 32 }
  - { interface: loopback1, addr: 2.2.2.1, mask: 32 }
EOF

Leaf2 yaml 파일

더보기

touch host_vars/10.202.32.102.yml
cat <<EOF >> host_vars/10.202.32.102.yml
---
# vars file for Leaf2

router_id: 10.202.32.102

loopbacks:
  - { interface: loopback0, addr: 10.0.0.102, mask: 32 }
  - { interface: loopback1, addr: 2.2.2.2, mask: 32 }
EOF

 

모든 장치에서 공통으로 사용할 변수는 각각 `roles/spine/vars/main.yml`과 `roles/leaf/vars/main.yml`에 정의

 

# 장치 역할 변수 생성

 

Ansible Spine 역할 변수 :

아래 YAML 코드를 Spine 역할 변수 디렉터리의 main.yml 파일로 생성.

이 변수들은 VXLAN, EVPN, OSPF, BGP, PIM와 같은 패브릭 공통 설정에 사용됩니다. 각 변수는 키/값 쌍으로 이루어진 딕셔너리이거나, 딕셔너리 목록을 포함하는 딕셔너리라는 점을 기억하세요.

Ansible Spine 역할 변수

더보기

touch roles/spine/vars/main.yml
cat <<EOF >> roles/spine/vars/main.yml

features:
  - { feature: bgp }
  - { feature: pim }
  - { feature: ospf }

ospf_process_id: UNDERLAY

ospf_area: 0

asn: 65001

address_families:
  - { afi: l2vpn, safi: evpn }

bgp_neighbors:
  - { remote_as: 65001, neighbor: 10.0.0.101, update_source: Loopback0 }
  - { remote_as: 65001, neighbor: 10.0.0.102, update_source: Loopback0 }

rp_address: 1.1.1.1
EOF

 

Ansible 리프 역할 변수 :

아래 YAML 파일을 리프 역할 변수 디렉터리의 main.yml 파일로 생성합니다.

 여기에 있는 변수들은 VXLAN, EVPN, OSPF, BGP, PIM, SVI, VRF와 특정 VNI에 매핑된 VLAN과 같은 VXLAN 매개변수 등 특정 기능에 사용됩니다. 각 변수는 키/값 쌍으로 이루어진 딕셔너리이거나, 딕셔너리 목록을 포함하는 딕셔너리라는 점을 기억하세요.

Ansible 리프 역할 변수

더보기

touch roles/leaf/vars/main.yml
cat <<EOF >>roles/leaf/vars/main.yml

features:
  - { feature: bgp }
  - { feature: interface-vlan }
  - { feature: ospf }
  - { feature: pim }
  - { feature: vnseg_vlan } 

ospf_process_id: UNDERLAY

ospf_area: 0

asn: 65001

address_families:
  - { afi: l2vpn, safi: evpn }
  - { afi: ipv4, safi: unicast }

bgp_neighbors:
  - { remote_as: 65001, neighbor: 10.0.0.111, update_source: Loopback0 }
  - { remote_as: 65001, neighbor: 10.0.0.112, update_source: Loopback0 }

rp_address: 1.1.1.1

vlans_l2vni:
  - { vlan_id: 11, vni_id: 10011, addr: 10.0.11.1, mask: 24, mcast_grp: 239.0.0.11, vrf: Tenant-1 }
  - { vlan_id: 12, vni_id: 10012, addr: 10.0.12.1, mask: 24, mcast_grp: 239.0.0.12, vrf: Tenant-1 }
  - { vlan_id: 13, vni_id: 10013, addr: 10.0.13.1, mask: 24, mcast_grp: 239.0.0.13, vrf: Tenant-1 }
  - { vlan_id: 14, vni_id: 10014, addr: 10.0.14.1, mask: 24, mcast_grp: 239.0.0.14, vrf: Tenant-1 }
  - { vlan_id: 15, vni_id: 10015, addr: 10.0.15.1, mask: 24, mcast_grp: 239.0.0.15, vrf: Tenant-1 }

vlans_l3vni:
  - { vlan_id: 10, vni_id: 10000, vrf: Tenant-1 }

vrfs:
  - { vrf: Tenant-1, vni_id: 10000, afi: ipv4, safi: unicast }
EOF

 

스파인 역할 작업 파일 생성

 

 

아래의 모든 작업을 수행하려면 roles/spine/tasks/에 있는 main.yml 파일을 편집해야 합니다.

시작 전 Ansible의 기능인 루프를 소개합니다. `loop`는 리스트를 순회하는 데 사용됩니다. roles/spine/vars/main.yml 파일에서 변수를 생성할 때, 많은 변수가 리스트로 구성했습니다.

`loop`를 사용하면 리스트를 순회하면서 `item.subkey`를 통해 해당 서브키 위치의 값을 참조하여 키(또는 서브키)를 처리할 수 있습니다.
tasks main.yml 파일을 작성하는 과정에서 타이핑을 줄이고 작업을 반복하기 위해 loop 함수를 자주 사용하게 될 것입니다.

 

아래의 nxos_interfaces 및 nxos_l3_interfaces 태스크를 roles/spine/tasks/main.yml 파일에 추가합니다. 이렇게 하면 host_vars에 정의된 루프백 변수를 사용하여 iBGP EVPN 피어링에 사용되는 루프백과 NVE 인터페이스의 소스를 각각 구성할 수 있습니다.

-   name: CONFIGURE LOOPBACK INTERFACES
    cisco.nxos.nxos_interfaces:
        config:
        -   name: "{{ item.interface }}"
            enabled: true
    loop: "{{ loopbacks }}"

-   name: CONFIGURE INTERFACE IP ADDR
    cisco.nxos.nxos_l3_interfaces:
        config:
        -   name: "{{ item.interface }}"
            ipv4:
            -   address: "{{ item.addr }}/{{ item.mask }}"
    loop: "{{ loopbacks }}"

아래의 nxos_ospf_vrf 및 nxos_ospf_interfaces 태스크를 roles/spine/tasks/main.yml 파일에 추가합니다. 이 태스크는 roles/spine/vars/main.yml에 있는 변수를 사용하며, 이전 태스크에서 생성한 루프백 인터페이스의 OSPF 인터페이스 매개변수를 Python에서 생성한 OSPF 프로세스로 구성하는 데 사용됩니다.

-   name: ASSOCIATE INTERFACES WITH OSPF PROCESS
    cisco.nxos.nxos_ospf_interfaces:
        config:
        -   name: "{{ item.interface }}"
            address_family:
            -   afi: ipv4
                processes:
                -   process_id: "{{ ospf_process_id }}"
                    area:
                        area_id: "{{ ospf_area }}"
    loop: "{{ loopbacks }}"

아래의 nxos_pim_interface 태스크를 roles/spine/tasks/main.yml 파일에 추가합니다. 이렇게 하면 host_vars에 정의된 루프백 변수를 사용하여 PIM 프로세스에 루프백을 구성할 수 있습니다.

-   name: CONFIGURE PIM INTERFACES
    cisco.nxos.nxos_pim_interface:
        interface: "{{ item.interface }}"
        sparse: true
    loop: "{{ loopbacks }}"

아래의 nxos_evpn_global, nxos_bgp_global, nxos_bgp_neighbor_address_family 태스크를 roles/spine/tasks/main.yml 파일에 추가합니다. 이 태스크들은 roles/spine/vars/main.yml에 정의된 BGP 변수를 사용하여 프로세스를 구성합니다.

-   name: ENABLE NV OVERLAY EVPN
    cisco.nxos.nxos_evpn_global:
        nv_overlay_evpn: true

-   name: CONFIGURE BGP ASN AND ROUTER ID
    cisco.nxos.nxos_bgp_global:
        config:
            as_number: "{{ asn }}"
            router_id: "{{ router_id }}"
            neighbors:
            -   neighbor_address: "{{ item.neighbor }}"
                remote_as: "{{ item.remote_as }}"
                update_source: "{{ item.update_source }}"
        state: merged
    loop: "{{ bgp_neighbors }}"

-   name: CONFIGURE BGP NEIGHBORS
    cisco.nxos.nxos_bgp_neighbor_address_family:
        config:
            as_number: "{{ asn }}"
            neighbors:
            -   neighbor_address: "{{ item.neighbor }}"
                address_family:
                -   afi: l2vpn
                    safi: evpn
                    send_community:
                        both: true
                    route_reflector_client: true
    loop: "{{ bgp_neighbors }}"

아래의 nxos_config 태스크를 roles/spine/tasks/main.yml 파일에 추가합니다. 이 태스크는 nxos_config 모듈의 save 매개변수를 사용하여 구성을 저장하는 데 사용됩니다.

-   name: SAVE RUN CONFIG TO STARTUP CONFIG
    cisco.nxos.nxos_config:
        save_when: always

통합 컨피그

더보기

[admin@localhost Ansible-NXOS]$ vi roles/spine/tasks/main.yml
---
#SPDX-License-Identifier: MIT-0
# tasks file for spine


-   name: ENABLE FEATURES
    cisco.nxos.nxos_feature:
        feature: "{{item.feature }}"
    loop: "{{ features }}"

-   name: ENABLE FEATURES
    cisco.nxos.nxos_config:
        lines: "feature nv overlay"

-   name: CONFIGURE LOOPBACK INTERFACES
    cisco.nxos.nxos_interfaces:
        config:
        -   name: "{{ item.interface }}"
            enabled: true
    loop: "{{ loopbacks }}"

-   name: CONFIGURE INTERFACE IP ADDR
    cisco.nxos.nxos_l3_interfaces:
        config:
        -   name: "{{ item.interface }}"
            ipv4:
            -   address: "{{ item.addr }}/{{ item.mask }}"
    loop: "{{ loopbacks }}"

-   name: ASSOCIATE INTERFACES WITH OSPF PROCESS
    cisco.nxos.nxos_ospf_interfaces:
        config:
        -   name: "{{ item.interface }}"
            address_family:
            -   afi: ipv4
                processes:
                -   process_id: "{{ ospf_process_id }}"
                    area:
                        area_id: "{{ ospf_area }}"
    loop: "{{ loopbacks }}"

-   name: CONFIGURE PIM INTERFACES
    cisco.nxos.nxos_pim_interface:
        interface: "{{ item.interface }}"
        sparse: true
    loop: "{{ loopbacks }}"

-   name: ENABLE NV OVERLAY EVPN
    cisco.nxos.nxos_evpn_global:
        nv_overlay_evpn: true

-   name: CONFIGURE BGP ASN AND ROUTER ID
    cisco.nxos.nxos_bgp_global:
        config:
            as_number: "{{ asn }}"
            router_id: "{{ router_id }}"
            neighbors:
            -   neighbor_address: "{{ item.neighbor }}"
                remote_as: "{{ item.remote_as }}"
                update_source: "{{ item.update_source }}"
        state: merged
    loop: "{{ bgp_neighbors }}"

-   name: CONFIGURE BGP NEIGHBORS
    cisco.nxos.nxos_bgp_neighbor_address_family:
        config:
            as_number: "{{ asn }}"
            neighbors:
            -   neighbor_address: "{{ item.neighbor }}"
                address_family:
                -   afi: l2vpn
                    safi: evpn
                    send_community:
                        both: true
                    route_reflector_client: true
    loop: "{{ bgp_neighbors }}"

-   name: SAVE RUN CONFIG TO STARTUP CONFIG
    cisco.nxos.nxos_config:
        save_when: always

[admin@localhost Ansible-NXOS]$

 

리프 역할 작업 파일 생성

 

 

스파인과 동일하게 roles/leaf/tasks/main.yml 파일을 수정하여 VLAN, VRF, VXLAN, EVPN 등과 설정을 생성합니다.

통합 컨피그

더보기

[admin@localhost Ansible-NXOS]$ vi roles/leaf/tasks/main.yml
---
#SPDX-License-Identifier: MIT-0
# tasks file for leaf

-   name: ENABLE FEATURES
    cisco.nxos.nxos_feature:
        feature: "{{item.feature }}"
    loop: "{{ features }}"

-   name: ENABLE FEATURES
    cisco.nxos.nxos_config:
        lines: "feature nv overlay"

-   name: CONFIGURE LOOPBACK INTERFACES
    cisco.nxos.nxos_interfaces:
        config:
        -   name: "{{ item.interface }}"
            enabled: true
    loop: "{{ loopbacks }}"

-   name: CONFIGURE INTERFACE IP ADDR
    cisco.nxos.nxos_l3_interfaces:
        config:
        -   name: "{{ item.interface }}"
            ipv4:
            -   address: "{{ item.addr }}/{{ item.mask }}"
    loop: "{{ loopbacks }}"

-   name: ASSOCIATE INTERFACES WITH OSPF PROCESS
    cisco.nxos.nxos_ospf_interfaces:
        config:
        -   name: "{{ item.interface }}"
            address_family:
            -   afi: ipv4
                processes:
                -   process_id: "{{ ospf_process_id }}"
                    area:
                        area_id: "{{ ospf_area }}"
    loop: "{{ loopbacks }}"

-   name: CONFIGURE PIM INTERFACES
    cisco.nxos.nxos_pim_interface:
        interface: "{{ item.interface }}"
        sparse: true
    loop: "{{ loopbacks }}"

-   name: ENABLE NV OVERLAY EVPN
    cisco.nxos.nxos_evpn_global:
        nv_overlay_evpn: true

-   name: CONFIGURE BGP ASN, ROUTER ID, AND NEIGHBORS
    cisco.nxos.nxos_bgp_global:
        config:
            as_number: "{{ asn }}"
            router_id: "{{ router_id }}"
            neighbors:
            -   neighbor_address: "{{ item.neighbor }}"
                remote_as: "{{ item.remote_as }}"
                update_source: "{{ item.update_source }}"
        state: merged
    loop: "{{ bgp_neighbors }}"

-   name: CONFIGURE BGP NEIGHBOR AFI, SAFI, COMMUNITY, and RR
    cisco.nxos.nxos_bgp_neighbor_address_family:
        config:
            as_number: "{{ asn }}"
            neighbors:
            -   neighbor_address: "{{ item.neighbor }}"
                address_family:
                -   afi: l2vpn
                    safi: evpn
                    send_community:
                        both: true
                    route_reflector_client: true
    loop: "{{ bgp_neighbors }}"

-   name: CONFIGURE VLAN TO VNI MAPPING
    cisco.nxos.nxos_vlans:
        config:
        -   vlan_id: "{{ item.vlan_id }}"
            mapped_vni: "{{ item.vni_id }}"
    with_items:
    - "{{ vlans_l2vni }}"
    - "{{ vlans_l3vni }}"

-   name: CONFIGURE TENANT VRFs
    cisco.nxos.nxos_vrf:
        vrf: "{{ item.vrf }}"
        vni: "{{ item.vni_id }}"
        rd: auto
        state: present
    loop: "{{ vrfs }}"

-   name: CONFIGURE TENANT VRFs (cont'd)
    cisco.nxos.nxos_vrf_af:
        vrf: "{{ item.vrf }}"
        afi: ipv4
        route_target_both_auto_evpn: true
        state: present
    loop: "{{ vrfs }}"

-   name: CONFIGURE VXLAN VTEP NVE INTERFACE
    cisco.nxos.nxos_interfaces:
        config:
        -   name: nve1
            enabled: true
        state: merged

-   name: CONFIGURE VXLAN VTEP NVE INTERFACE FOR EVPN CONTROL PLANE
    cisco.nxos.nxos_vxlan_vtep:
        interface: nve1
        host_reachability: true
        source_interface: Loopback1
        state: present

-   name: CONFIGURE VXLAN VTEP NVE INTERFACE L2VNI MAPPING
    cisco.nxos.nxos_vxlan_vtep_vni:
        interface: nve1
        vni: "{{ item.vni_id }}"
        #ingress_replication: bgp
        multicast_group: "{{ item.mcast_grp }}"
        #suppress_arp: true
    loop: "{{ vlans_l2vni }}"

-   name: CONFIGURE VXLAN VTEP NVE INTERFACE L3VNI MAPPING
    cisco.nxos.nxos_vxlan_vtep_vni:
        interface: nve1
        vni: "{{ item.vni_id }}"
        assoc_vrf: true
    loop: "{{ vlans_l3vni }}"

-   name: CONFIGURE L2 EVPN VRFs
    cisco.nxos.nxos_evpn_vni:
        vni: "{{ item.vni_id }}"
        route_distinguisher: auto
        route_target_both: auto
    loop: "{{ vlans_l2vni }}"

-   name: CONFIGURE TENANT VRFs UNDER BGP PROCESS
    cisco.nxos.nxos_bgp_address_family:
        config:
            as_number: "{{ asn }}"
            address_family:
            -   afi: "{{ item.afi }}"
                safi: "{{ item.safi }}"
                vrf: "{{ item.vrf }}"
                advertise_l2vpn_evpn: true
    loop: "{{ vrfs }}"

-   name: CONFIGURE ANYCAST GW MAC
    cisco.nxos.nxos_overlay_global:
        anycast_gateway_mac: "1234.5678.9000"

-   name: SAVE RUN CONFIG TO STARTUP CONFIG
    cisco.nxos.nxos_config:
        save_when: always

[admin@localhost Ansible-NXOS]$

 

 

Ansible 호스트 파일 생성

 

 

지금까지 Ansible 설치를 완료하고 플레이북 디랙토리를 설정하고 역할(Role), 작업(Task) 구성을 완료했습니다

이제 실제 자동화 배포를 수행하기 위한 마지막 단계로, VXLAN EVPN 패브릭 배포를 위해 Ansible이 관리할 대상 장비를 정의하는 호스트 파일(Inventory) 과 전체 실행 순서를 정의하는 메인 플레이북을 작성해야 합니다.

 

먼저 Ansible이 제어할 Nexus 스위치 정보를 등록하기 위한 호스트 파일을 생성해보겠습니다. 인벤토리 파일에는 Ansible이 관리할 장비(호스트) 목록을 정의합니다. 단순히 장비 목록만 나열할 수도 있으며, 대괄호([])를 사용해 그룹을 생성하고 장비를 그룹별로 분류할 수도 있습니다.

이러한 그룹 기능을 활용하면 Spine, Leaf, Server 등 역할별로 장비를 구분하여 관리할 수 있으며, 특정 그룹에 대해서만 플레이북을 실행하는 등 보다 효율적인 자동화가 가능합니다.

cat <<EOF >> hosts
# hosts file for Ansible playbook

[spine]
10.202.32.111
10.202.32.112

[leaf]
10.202.32.101
10.202.32.102

EOF

 

메인 Ansible 플레이북 생성

 

 

플레이북은 Ansible에서 자동화 작업을 정의하는 핵심 구성 요소로, 하나 이상의 장비에 대한 설정 및 운영 작업을 수행하는 플레이와 작업의 집합입니다. Ansible은 효율적인 관리와 재사용을 위해 역할(Role) 기반의 디렉터리 구조를 사용하는 것을 권장합니다.

cat <<EOF >> site.yml
---
# main playbook

- hosts: spine
  roles:
    - role: spine

- hosts: leaf
  roles:
    - role: leaf
EOF

 

Ansible 플레이북 실행

 

 

드디어 실행입니다. 실행 명령어는 ansible-playbook -i hosts site.yml -vvv 입니다.

-vvv 옵션으로 작업간 상세정보를 보여주는 옵션입니다

정상적으로 실행된 모습이다 ㅎ-ㅎ

사실 중간에 에러가 한번 발생했는데 마지막에 정리하고 다음으로 컨피그가 잘 적용 되었는지 확인해보겠습니다.

 

동작 확인

 

BGP 설정이 잘 들어간 모습

 

작업간 특이로그 없음

 

패킷 덤프 HTTPS로 암호화되어 통신되는 모습 (기본은 SSH 통신)

 

이슈사항

 

플레이북을 처음 실행 시켰을 때 아래 에러가 발생했습니다.

더보기

[admin@localhost Ansible-NXOS]$ ansible-playbook -i hosts site.yml -vvv

ansible-playbook [core 2.21.0]

  config file = /home/admin/Playbooks/Ansible-NXOS/ansible.cfg

  configured module search path = ['/home/admin/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']

  ansible python module location = /usr/local/lib/python3.12/site-packages/ansible

  ansible collection location = /home/admin/.ansible/collections:/usr/share/ansible/collections

  executable location = /usr/local/bin/ansible-playbook

  python version = 3.12.13 (main, Apr 16 2026, 00:00:00) [GCC 14.3.1 20251022 (Red Hat 14.3.1-4)] (/usr/bin/python3)

  jinja version = 3.1.6

  pyyaml version = 6.0.1 (with libyaml v0.2.5)

Using /home/admin/Playbooks/Ansible-NXOS/ansible.cfg as config file

host_list declined parsing /home/admin/Playbooks/Ansible-NXOS/hosts as it did not pass its verify_file() method

script declined parsing /home/admin/Playbooks/Ansible-NXOS/hosts as it did not pass its verify_file() method

auto declined parsing /home/admin/Playbooks/Ansible-NXOS/hosts as it did not pass its verify_file() method

Parsed /home/admin/Playbooks/Ansible-NXOS/hosts inventory source with ini plugin

Skipping callback 'minimal', as we already have a stdout callback.

Skipping callback 'oneline', as we already have a stdout callback.

PLAYBOOK: site.yml ********************************************************************************************************************

2 plays in site.yml

PLAY [spine] **************************************************************************************************************************

TASK [Gathering Facts] ****************************************************************************************************************

task path: /home/admin/Playbooks/Ansible-NXOS/site.yml:4

redirecting (type: connection) ansible.builtin.httpapi to ansible.netcommon.httpapi

redirecting (type: connection) ansible.builtin.httpapi to ansible.netcommon.httpapi

redirecting (type: httpapi) ansible.builtin.nxos to cisco.nxos.nxos

redirecting (type: httpapi) ansible.builtin.nxos to cisco.nxos.nxos

redirecting (type: modules) ansible.builtin.nxos_facts to cisco.nxos.nxos_facts

<10.202.32.111> ESTABLISH LOCAL CONNECTION FOR USER: admin

<10.202.32.111> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e `"&& mkdir "` echo /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.841656-26708-73467771251708 `" && echo ansible-tmp-1781670901.841656-26708-73467771251708="` echo /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.841656-26708-73467771251708 `" )'

redirecting (type: modules) ansible.builtin.nxos_facts to cisco.nxos.nxos_facts

<10.202.32.112> ESTABLISH LOCAL CONNECTION FOR USER: admin

<10.202.32.112> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e `"&& mkdir "` echo /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.8563075-26709-225276323680481 `" && echo ansible-tmp-1781670901.8563075-26709-225276323680481="` echo /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.8563075-26709-225276323680481 `" )'

redirecting (type: modules) ansible.builtin.nxos_facts to cisco.nxos.nxos_facts

redirecting (type: modules) ansible.builtin.nxos_facts to cisco.nxos.nxos_facts

Using module file /usr/local/lib/python3.12/site-packages/ansible_collections/cisco/nxos/plugins/modules/nxos_facts.py

<10.202.32.111> PUT /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/tmpuw8_5z6p TO /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.841656-26708-73467771251708/AnsiballZ_nxos_facts.py

<10.202.32.111> EXEC /bin/sh -c 'chmod u+rwx /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.841656-26708-73467771251708/ /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.841656-26708-73467771251708/AnsiballZ_nxos_facts.py'

Using module file /usr/local/lib/python3.12/site-packages/ansible_collections/cisco/nxos/plugins/modules/nxos_facts.py

<10.202.32.112> PUT /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/tmp124e0zc5 TO /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.8563075-26709-225276323680481/AnsiballZ_nxos_facts.py

<10.202.32.112> EXEC /bin/sh -c 'chmod u+rwx /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.8563075-26709-225276323680481/ /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.8563075-26709-225276323680481/AnsiballZ_nxos_facts.py'

<10.202.32.111> EXEC /bin/sh -c '/usr/bin/python3 /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.841656-26708-73467771251708/AnsiballZ_nxos_facts.py'

<10.202.32.112> EXEC /bin/sh -c '/usr/bin/python3 /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.8563075-26709-225276323680481/AnsiballZ_nxos_facts.py'

<10.202.32.112> EXEC /bin/sh -c 'rm -f -r /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.8563075-26709-225276323680481/ > /dev/null 2>&1'

[WARNING]: Deprecation warnings can be disabled by setting `deprecation_warnings=False` in ansible.cfg.

[DEPRECATION WARNING]: Importing 'to_text' from 'ansible.module_utils._text' is deprecated. This feature will be removed from ansible-core version 2.24. Use ansible.module_utils.common.text.converters instead.

[ERROR]: Task failed: Action failed: The following modules failed to execute: ansible.legacy.nxos_facts.

Task failed: Action failed.

<<< caused by >>>

The following modules failed to execute: ansible.legacy.nxos_facts.

+--[ Sub-Event 1 of 1 ]---

|

| Could not connect to https://10.202.32.112:443/ins: [Errno 111] 연결이 거부됨

|

+--[ End Sub-Event ]---

fatal: [10.202.32.112]: FAILED! => {

    "ansible_facts": {},

    "changed": false,

    "failed_modules": {

        "ansible.legacy.nxos_facts": {

            "changed": false,

            "deprecations": [

                {

                    "collection_name": "ansible.builtin",

                    "deprecator": {

                        "resolved_name": "ansible.builtin",

                        "type": null

                    },

                    "msg": "Importing 'to_text' from 'ansible.module_utils._text' is deprecated.",

                    "version": "2.24"

                }

            ],

            "exception": "(traceback unavailable)",

            "failed": true,

            "warnings": []

        }

    },

    "msg": "The following modules failed to execute: ansible.legacy.nxos_facts."

}

<10.202.32.111> EXEC /bin/sh -c 'rm -f -r /home/admin/.ansible/tmp/ansible-local-26703hyegwp_e/ansible-tmp-1781670901.841656-26708-73467771251708/ > /dev/null 2>&1'

[ERROR]: Task failed: Action failed: The following modules failed to execute: ansible.legacy.nxos_facts.

Task failed: Action failed.

<<< caused by >>>

The following modules failed to execute: ansible.legacy.nxos_facts.

+--[ Sub-Event 1 of 1 ]---

|

| Could not connect to https://10.202.32.111:443/ins: [Errno 111] 연결이 거부됨

|

+--[ End Sub-Event ]---

fatal: [10.202.32.111]: FAILED! => {

    "ansible_facts": {},

    "changed": false,

    "failed_modules": {

        "ansible.legacy.nxos_facts": {

            "changed": false,

            "deprecations": [

                {

                    "collection_name": "ansible.builtin",

                    "deprecator": {

                        "resolved_name": "ansible.builtin",

                        "type": null

                    },

                    "msg": "Importing 'to_text' from 'ansible.module_utils._text' is deprecated.",

                    "version": "2.24"

                }

            ],

            "exception": "(traceback unavailable)",

            "failed": true,

            "warnings": []

        }

    },

    "msg": "The following modules failed to execute: ansible.legacy.nxos_facts."

}

PLAY RECAP ****************************************************************************************************************************

10.202.32.111              : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

10.202.32.112              : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

[admin@localhost Ansible-NXOS]$

 

확인결과 Managed node. 즉, Leaf 스위치에서 nx-api기능이 비활성화 되어있어 TCP RST 메세지가 발생했었고 장비에 접속하여 기능을 활성화한 다음 실행하니 정상 동작했습니다.

 

 

이상입니다.

감사합니다.

목차

  1. 엔서블?
  2. 구성요소
  3. 동작방식
  4. 실습 - 리눅스 서버 pip 설치
  5. 실습 - Ansible 설치
  6. 실습 - Host 통신 확인
더보기

최근 데이터센터 규모가 커지고, 인프라 장비 수가 증가하면서 CLI 기반 수동 작업만으로는 운영 효율을 유지하기 어려워지고 있다.

예를 들어 스위치 100대에 NTP 서버를 변경하거나, 수백 대의 서버에 동일한 패키지를 설치해야 한다면 어떻게 할까?

예전에는 엔지니어가 직접 접속하여 설정을 변경했지만, 현재는 Infrastructure as Code(IaC) 와 자동화 도구를 활용하여 코드로 인프라를 관리하는 것이 일반적인 운영 방식이 되었다.

그 중심에 있는 대표적인 자동화 도구가 바로 Ansible 이다.

 

엔서블?

Ansible은 Red Hat에서 개발 및 관리하는 IT 자동화 플랫폼으로 서버, 네트워크 장비, 클라우드, 보안 장비 등을 대상으로 다음과 같은 작업을 자동화할 수 있습니다.

 

- Management
- Provisioning
- Application Deployment
- Orchestration
- 운영 자동화

 

# Ansible의 특징

 

Agentless : 대상장비에 별도의 Agent를 설치하지 않고 Ansible이 직접 Push하는 방식으로 Puppet, Chef와 같은 기존 자동화 도구들은 대상 장비에 Agent를 설치해야 했지만 Ansible은 SSH를 통해 직접 제어하기 때문에 복잡성이 줄어듭니다.

 

멱등성(Idempotency) : 동일한 설정을 여러 번 실행해도 현재 상태가 목적한 상태라면 아무 일도 일어나지 않아. 즉, 몇번을 실행해도 동일한 결과가 출력되어 안정적입니다.

 

접근성 : 사람이 읽기 쉬운 YAML형식을 사용하여 Python 코드를 직접 작성하는 것보다 훨씬 직관적입니다.

 

표준화 및 일관성: 모든 장비에 동일한 설정을 적용하여 표준화되고 안정적인 인프라 환경을 제공합니다.

휴먼 에러 최소화: 수동 CLI 입력 시 발생하는 오타나 실수로 인한 장애를 차단합니다.

효율성 극대화: 다수의 스위치에 대한 VLAN 설정이나 펌웨어 업데이트를 단 몇 분 만에 실행합니다.

 

 

구성요소

# 구성요소와 역할

Control Node Ansible을 실행시키는 서버
Managed Node Ansible로 관리될 대상 장비
Inventory 프로비저닝,배포등의 제어될 대상을 정의한 파일 (hosts.ini 파일)
Playbook 자동화할 작업 내용을 YAML 형식으로 정의한 파일
Module 각 벤더별(Cisco, Juniper, Arista 등) 장비를 제어하기 위한 실행 단위

 

 

동작방식

 

Ansible은 제어 노드(Control Node)에서 관리 대상(Managed Node)으로 명령을 푸시(Push)하는 구조입니다.

 

 


정리

오늘날 데이터센터와 AI 인프라 환경에서 Ansible은 네트워크 장비, 서버, 보안 장비, 클라우드 자원을 코드로 
관리하여 운영업무에 혁신을 가져온다.

네트워크 엔지니어 관점에서 Ansible의 가장 큰 가치는 다음과 같다.

반복 작업 제거
설정 표준화
작업 시간 단축
운영 실수 감소
대규모 장비 관리 가능

CLI를 잘 다루는 엔지니어가 자동화를 구현할 수 있는 능력을 갖춘다면 생산성 차이는 앞으로 더욱 커질 것이다.


 

실습 - 리눅스 서버 pip 설치

 

실습은 리눅스 환경에서 진행하겠습니다.

Rocky linux 10.2 사용

 

1. pip 모듈 설치

2. Ansible 설치

3. Control node <-> Manage node간 통신 확인

 

# PIP 모듈 설치

참고링크 https://pip.pypa.io/en/stable/installation/#supported-methods

 

Installation - pip documentation v26.1.2

$ chmod +x ./pip.pyz $ ./pip.pyz then the currently active Python interpreter will be used. $ chmod +x ./pip.pyz $ ./pip.pyz then the currently active Python interpreter will be used. then the currently active Python interpreter will be used. You may need

pip.pypa.io

"python get-pip.py" 명령어를 사용하여 설치합니다. get-pip.py는 https://bootstrap.pypa.io/get-pip.py 링크를 통해 다운받을 수 있습니다. pip을 설치하면 Ansible 설치 준비 끝입니다.

* 저의 실습환경에서는 인터넷 연결이 어려워 vi로 get-pip.py파일을 직접 생성했습니다. 

get-pip.py 파일 실행

 

위 방법이 안되면 yum -y install python3-pip 명령어로 설치 가능합니다.

yum -y install python3-pip

 

 

실습 - Ansible 설치

#Ansible 설치

pip install ansible 명령어를 사용하여 엔서블을 설치합니다

 - 앞에 sudo를 사용하여 명령어를 실행하거나 su - 명령어를 통하여 root권한을 획득한 후 명령어 실행

pip   install   ansible

 

ansible --version 명령어를 통해 버전 확인

 

실습 - Host 통신 확인

# Control node <-> Manage node간 통신 확인

Control node가 Manage node에 설정을 Push하는 방식으로 동작하기 때문에 정상적인 통신이 가능해야합니다.

- SSH를 사용하기 때문에 TCP 22 통신이 가능해야합니다.

- 문서에 SSH를 사용한다 되어있는데 테스트해보니까 HTTPS를 사용해서 뭐가 기본동작인지 모르겠음

- 실습환경엔 방화벽이 없어 ping으로 통신 확인

이상으로 Ansible에 대한 학습과 실습환경 구성에 대한 포스팅을 마무리합니다.

 

다음 포스팅은 Ansible을 통해 Cisco nexus 스위치의 자동화를 해보고 VXLAN/EVPN 설정을 넣어보겠습니다.

 

감사합니다.

 

목차

  1. 자료분석
  2. 통계분석
  3.  
  4.  
  5.  

데이터 마트

데이터 웨어하우스에서 특정 부서 또는 사용자들이 필요로하는 데이터만 따로 저장한 저장소 (소규모 데이터 웨어하우스)

특징 : 특정 목적을 위해 최적화 되어있고, 사이즈를 줄여 데이터 쿼리 속도가 빠름 또한 부서 또는 사용자 요구

구분 데이터 웨어하우스 (DW) 데이터 마트 (DM)
범위 기업 전체의 통합 데이터 특정 부서 및 목적용 데이터
데이터 양 수백 GB ~ PB 단위 (대용량) 수십 GB 이하 (상대적으로 적음)
구축 기간 보통 수개월 이상 소요 수 주 내외로 비교적 짧음
데이터 소스 다양한 운영 시스템(ERP, CRM 등) 데이터 웨어하우스 또는 특정 운영 시스템

 

 

요약변수와 파생변수

 

1. 요약변수 : 수집한 데이터를 종합, 요약한 변수 재활용성이 뛰어나다.

예시:
 - 최근 3개월간 총 구매 금액
 - 월평균 결제 횟수

 

2. 파생변수 : 사용자가 논리적 타당성을 근거로 특정한 의미를 부여한 데이터

예시:
근무 시간: (퇴근 시간 - 출근 시간)
고객 등급: 구매 금액에 따라 'VIP', 'Gold', 'Silver'로 분류

** 요약 변수는 "데이터를 어떻게 잘 합칠 것인가"에 집중하며, 파생 변수는 "데이터에서 어떤 새로운 의미를 찾아낼 것인가"에 집중합니다.

 


1. 자료분석


탐색적 자료 분석(EDA / Exploratory Data Analysis )

데이터를 분석하기 전 특징이나 패턴을 파악을 위해 통계, 시각화하는 단계 "데이터와의 첫 대면" 이라고 할 수 있다.

 - EDA의 4가지 주요 주제 (데이터 분석 방법론의 핵심 요소)

1. 저항성의 강조 : 이상값이나 결측치 등 데이터 변동에 민감하지 않음

2. 잔차 계산 : 데이터들이 주경향(데이터는 대표하는 중심값)에서 얼마나 벗어나 있는지 확인

3. 자료변수의 재표현 : 원래의 변수를 척도로 변환시켜 해석,분석을 쉽게하는 과정 (통계화)

4. 그래프를 통한 현시성 : 그래프로 시각화하여 값들을 직관적으로 드러내는 과정 (시각화)

 

 

결측값

결측값이란 데이터가 저장되지 않아 비어있는 상태, Null 또는 N/A로 표시되는 값.

결측값을 데이터 모델링에 그대로 사용할 경우 오류 또는 결과 왜곡이 발생하기 때문에 처리를 해줘야한다.

 

결측값 처리방법

- 단순 대치법 : 하나의 고정된 값으로 대치하는 방식

1. 완전 분석법 : 결측값을 삭제

2. 평균 대치법 : 단순 평균값으로 대치 ( = 비조건부 평균 대치 )

3. 회귀 대치법 : 회귀분석의 결과로 대치 ( = 조건부 평균 대치 )

4. 단순 확률 대치법 : 확률적으로 선택하여 대치

 4.1 Nearest neighbor : 인접한 값으로 응답 대치

 4.2 Hot-Deck : 현재 분석중인 데이터 셋에서 비슷한 값으로 대치 

 4.3 Cold-Deck : 현재 분석중이지 않은 다른 데이터 셋에서 값을 가져와 대치

- 다중 대치법 : 여러 번 대치 (대치 -> 분석 -> 결합)

 

이상값

이상값이란 극단적으로 크거나 작은 데이터. 단, 의미있는 데이터가 포함된 경우도 있어 항상 제거하지는 않음.

이상값 탐지방법

1. ESD (Extreme Studentized Deviation) : 평균으로부터 표준편차의 3배 넘어가는 데이터를 이상값으로 판단.

2. 사분위수(boxplot) : 전체 데이터를 4등분하고 Q1 - 1.5IQR 보다 작거나 Q3 + 1.5IQR보다 크면 이상값으로 판단.

 

MIN : 최솟값

Q1 : 25%

Q2 : 50% (중앙값)

Q3 : 75%

MAX : 최댓값

IQR : Q3 - Q1
** 평균값은 알 수 없다 (데이터의 갯수를 측정할 수 없기때문)

 

3. Z-Score : 데이터를 정규화(평균 0, 표준편차 1)한 후, 임계 값을 초과할 경우 이상값으로 판단.

4. DBScan : 밀도를 이용하여 밀도가 적은 부분의 데이터를 이상값으로 판단.

 

 


2. 통계분석


전수조사와 표본조사

전수조사 : 전체를 다 조사, 시간과 비용 많이 소모

표본조사 : 일부만 추출하여 모집단(전체)를 조사

 

자료의 척도 구분

척도란? 사물이나 현상의 특성을 수치나 기호로 나타내기 위해 사용하는 '측정의 단위'

 

1. 질적 척도

 - 명목척도 : 대상을 구분하거나 분류하기 위해 이름을 붙인 척도 (성별, 혈액형)

 - 순서척도(서열척도) : 순서나 서열이 존재하는 척도 (학년, 직급, 만족도)

 

2. 양적척도

 - 등간척도(구간척도) : 수치간의 간격이 일정하고 간격에 의미가 있는 척도, +/- 만 가능 (온도)

 - 비율척도 : 절대적인 기준 0이 존재하고 사칙연산이 가능한 척도 (무게, 나이, 소득)

 

확률적 표본 추출 방법

* 표본추출이란? 모집단에서 일부 데이터를 표본으로 추출하고 모집단을 예측할 수 있도록 표본집단을 구성 (모집단을 다 조사할 수 없기 때문에 표본화 진행)

 

 

확률적 표본 추출 방법

1. 랜덤 추출법 : 무작위로 표본 추출

2. 계통 추출법 : 데이터에 번호를 부여하여 일정 간격으로 표본을 추출

3. 군집 추출법(집락 추출법) : 군집 내 이질적 특징, 군집 간 동질적 특징

 

 

 

 

 

 

 

 

 

 

 

4. 층화 추출법 : 군집 내 동질적 특징, 군집 간 이질적 특징 / 동일한 비율로 추출하는 방법 "비례 층화 추출법"

 

 

 

 

 

 

 

 

 

5. 복원, 비복원 추출

 5.1 복원 추출 : 추출되었던 데이터를 다시 포함시켜 표본 추출

 5.2 비복원 추출 : 추출되었던 데이터는 제외하고 표본 추출

 

 

비확률적 표본 추출 방법

 

1. 편의 추출법 : 연구자가 쉽게 접근 가능한 대상으로 표본을 추출

2. 의도적 추출법 : 연구자가 특정 기준을 정하고, 이에 맞는 표본을 추출

3. 할당 추출법 : 특정 기준으로 나눈 후, 그 그룹에서 할당된 수 만큼 추출

4. 눈덩이 추출법 : 초기 응답자로부터 새로운 응답자를 추천 받는 방식

5. 자기선택 추출법 :응답자가 스스로 조사에 참여할지 결정

 

 

기초 통계량

기초 통계량이란? 수집된 데이터의 특징을 요약하여 설명해 주는 수치들로, 크게 중심 경향성, 산포도, 분포의 모양으로 구분.

1. 중심경향성 측면 : 데이터가 어디를 중심으로 모여 있는지 표시

 - 산술평균 : 일반적인 평균 개념으로, 모든 값을 더한 후 데이터 개수로 나눈 값

 - 기하평균 : 모든 값들을 곱하고, n 제곱근을 구하는 방식 (비율적 증가율)

 - 조화평균 : 역수의 산술평균을 구한 후, 다시 역수를 취하는 방식 (비율 계산)

 - 중앙값 : 데이터를 크리 순서로 나열했을 때 중간에 위차한 값

 - 최빈값 : 데이터에서 가장 자주 나타나는 값

 

2. 분산 정도 측면 (산포도) : 데이터가 중심으로부터 얼마나 멀리 퍼져 있는지 표시

 - 범위 : 최댓값과 최솟값의 차이.

 - 분산 : 각 데이터가 평균과 얼마나 떨어져 있는지 나타내는 지표

 - 표준편차 : 분산에 제곱근을 취한 값

 - 사분위수 (IQR) : 데이터의 상위 75%와 하위 25%의 차이인 중간 50% 데이터가 얼마나 분산되어있나를 나타내는 지표

 

3. 관계 측면

3.1 공분산 : 두 확률변수의 상관정도

 - 공분산 = 0 : 상관이 전혀 없는 상태

 - 공분산 > 0 : 양의 상관관계

 - 공분산 < 0 : 음의 상관관계

 - 최소, 최대값이 없어 강약 판단 불가능

3.2 상관계수 : 상관정도를 -1 ~ 1 값으로 표현

 - 상관계수 = 1 : 정비례 관계

 - 상관계수 = 0 : 상관없음

 - 상관계수 = -1 : 반비례 관계

3.3 공분산과 독립성의 관계

 - 두 변수가 독립이면 공분산은 0이지만, 공분산이 0이라고 두 변수가 독립이라고 할 수는 없다.

 

첨도와 왜도

 

1. 첨도 : 분포가 중앙심에서 얼마나 뾰족한지, 양 끝에 데이터가 얼마나 모여있는지를 나타내는 척도

- "첨도 = 3" : 정규분포의 뾰족한 정도 ( 계산 방식에 따라 정규분포를 3으로 보기도 하고, 3을 빼서 0으로 맞추기도 합니다. )

- "첨도 > 3" : 정규분포보다 더 뾰족하고 꼬리가 두꺼운 형태의 척도 / 데이터가 중앙에 모여있음

- "첨도 < 3" : 정규분포보다 완만한 척도 / 데이터가 고르게 퍼져있음

 

 

2. 왜도 : 자료 분포의 비대칭 정도

 - "왜도 < 0" 인 경우 : 평균값 < 중앙값 < 최빈값 

 - "왜도 > 0" 인 경우 : 평균값 > 중앙값 > 최빈값

 - "왜도 = 0" 인 경우 : 평균값, 중앙값, 최빈값 모두 동일

 

 

기초 확률 이론

 

1. 확률 : 통계적 현상의 확실함을 나타내는 척도로 수학적 확률과 통계적 확률로 구분

2. 사건 : 여러 반복된 시행을 통해 결과로 나타나는 표본공간의 부분 집합

3. 표본공간 : 통계적 실험에 의하여 일어날 수 있는 모든 가능한 결과

4. 확률변수 : 표본공간의 각 원소에 해당하는 값(확률)을 대응하는 함수

5. 조건부 확률 : 특정 사건 B가 발생했을 때 A가 발생할 확률

6. 독립사건 : A,B가 서로 영향을 주지 않는 사건

7. 배반사건 : A,B가 서로 동시에 일어나지 않는 사건

8. 베이즈 정리 : 두 확률 변수의 사전 확률과 사후 확률 사이의 관계를 나타내는 정리

 

 

 

 

 

목차

  1. POAP란?
  2. POAP 프로세스
  3. 준비사항

안녕하세요? 오늘은 Cisco Nexus 스위치에서 지원하는 POAP기능을 알아보려고 합니다.

파트너사에 근무하며 장비 납품 전 OS 업그레이드 작업을 자주하는데 POAP 기능을 공부하고 실무에 적용할 예정입니다

 

1. POAP란?

 

 POAP(PowerOn Auto Provisioning)는 Cisco Nexus 스위치에서 지원하는 소프트웨어 이미지 업그레이드 및 컨피그 파일 배포 자동화 기능입니다.

 최초 스위치가 부팅하고 저장된 Startup-config 파일이 없으면 DHCP로 IP를 할당받고 DHCP 서버에 설정된 TFTP 서버와 통신해 설정된 OS 파일 및 컨피그 스크립트를 받아옵니다.

 

 

2. POAP 프로세스

 

[Nexus Switch PoAP 과정]

 

 - Nexus 스위치 부팅 후 Startup-config 파일 여부 체크합니다( 초기화 상태에서 PoAP가 동작함 ).

 - DHCP 서버를 통해 IP, Gateway, TFTP Server ip, Script 파일명 정보를 받아옵니다.

 - TFTP 서버와 통신해 Script 파일을 실행시켜 OS 업그레이드 및 컨피그 배포 등의 동작을 자동으로 실행 합니다.

 

3. 준비사항

 

 - Nexus 스위치 : POAP를 지원하는 스위치

 - DHCP 서버 : IP를 할당하고 Script 파일 및 TFTP 서버의 정보를 알려주는 서버

 - Script 서버 : 컨피그 파일이나 OS 설치 정보를 포함한 Script 파일을 가지고 있는 서버

 - Configuration 서버 : 스위치의 구성정보와 업그레이드에 필요한 OS 파일를 가지고있는 서버

 

목차

  1. 목표
  2. 코드 설명

목표

반복작업을 피하기위해 파이썬 스크립트를 작성하고 수집한 결과를 관리하기위해 엑셀파일로 저장

1. 테스트 환경

 - Python 3.14

 - vscode

 - Cisco Nexus switch (OS 9.x 이상)

 - 장비 IP를 관리하는 CSV 파일 준비

 

2. 작업 순서

 - CSV 파일의 A열을 참조하여 장비 IP를 읽기

 - 장비 IP를 참조하여 API(Requests)를 통해 show 명령어 수행 및 json형태로 저장

 - 저장된 json 형식의 데이터에서 hostname, productid, serialnum 데이터 파싱

 - 파싱한 데이터를 CSV 파일의 B,C,D열에 삽입 후 저장

 

코드설명

중간 "*** ***"는 사용자 환경에 맞게 입력

import requests
import json
import os
import pandas as pd
import urllib3

# HTTPS 경고 무시
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

# 1. 파일 경로 설정
file_path = *** 파일 경로 ***

# 인증 정보
login_id = *** 장비 계정 ***
login_pwd = *** 장비 암호 ***

try:
    # 2. 기존 CSV 파일 읽기
    df = pd.read_csv(file_path, encoding='utf-8-sig')
    
    if 'Device IP' not in df.columns:
        print("오류: CSV 파일에 'Device IP' 열이 없습니다.")
        exit()

    # 결과를 담을 리스트 초기화
    hostnames = []
    product_ids = []
    serials = []

    print(f"--- {len(df)}개의 장비 분석 시작 ---")

    # 3. IP 리스트 순회 (행 단위 반복)
    for target_ip in df['Device IP']:
        print(f"\n[접속 중] {target_ip} ...")
        url = f"https://{target_ip}/ins"
        
        payload = json.dumps({
            "ins_api": {
                "version": "1.0", "type": "cli_show", "chunk": "0", "sid": "sid",
                "input": "show inv ;show hostname", "output_format": "json"
            }
        })
        headers = {'Content-Type': 'application/json'}

        # 데이터 초기값 (실패 시 빈값 처리)
        h, p, s = "", "", ""

        try:
            response = requests.request("POST", url, headers=headers, auth=(login_id, login_pwd), 
                                        data=payload, verify=False, timeout=10)
            
            if response.status_code == 200:
                data = response.json()
                output_list = data["ins_api"]["outputs"]["output"]

                # Hostname 파싱
                h_info = next((item for item in output_list if item["input"] == "show hostname"), None)
                h = h_info["body"]["hostname"] if h_info else "Unknown"

                # Chassis 정보 파싱
                inv_info = next((item for item in output_list if item["input"] == "show inv"), None)
                if inv_info:
                    inv_rows = inv_info["body"]["TABLE_inv"]["ROW_inv"]
                    c_info = next((item for item in inv_rows if item["name"] == "\"Chassis\""), None)
                    if c_info:
                        p = c_info.get("productid", "")
                        s = c_info.get("serialnum", "")
                        print(f" > 성공: {h}")
        
        except Exception as e:
            print(f" > 접속 에러: {target_ip} ({e})")

        # 리스트에 결과 추가
        hostnames.append(h)
        product_ids.append(p)
        serials.append(s)

    # 4. 기존 데이터프레임에 새로운 열 추가
    # B열: Hostname, C열: Product ID, D열: Serial Number 순서로 삽입
    df['Hostname'] = hostnames
    df['Product ID'] = product_ids
    df['Serial Number'] = serials

    # 5. 파일 덮어쓰기 (또는 다른 이름으로 저장)
    df.to_csv(file_path, index=False, encoding='utf-8-sig')
    print(f"\n--- 업데이트 완료: {file_path} ---")

except Exception as e:
    print(f"작업 중 오류 발생: {e}")

 

 

-> import requests : Nexus api 사용을 위해 필요

-> import json : json 형식 활용

-> import pandas : CSV 파일 읽기에 활용

-> import urllib3 : https 접근시 인증서 에러 비활성화

 

 

-> Requests 모듈? 사용시 Https 에러 무시

-> CSV 파일 경로 지정

-> 장비 인증정보 지정

 

 

 

-> CSV파일에 Device IP 셀을 읽어 df 변수?로 저장

 

 

-> 마지막에 수집된 정보를 저장하기 위해 리스트 만들기 

 

 

 

 

-> 저장한 df (Device IP)를 사용하여 url 생성

-> show inv / show hostname 명령어를 수행하도록 input을 설정하고 json 형식으로 output 저장하는 payload 저장

 

 

-> requests 모듈?을 사용하여 저장한 url, headers, payload 등 POST

-> 요청 성공시 응답값을 json형태로 저장

-> 저장된 값의 "body" "hostname"에 위치한? 저장된? 값을 파싱

-> 저장된 값의 "body" "TABLE_inv" "ROW_inv"에 저장된 값 중 Chassis의 하위값 productid, resialnum를 저장 

 

 

-> 결과를 리스트에 저장

-> 기존 IP만 있던 CSV파일의 B,C,D열에 각각 Hostname, Product ID, Serial Number를 추가하고 아래 데이터를 저장

 

코드 실행결과 관리하는 장비의 IP목록을 기준으로 필요한 Hostname, Product ID, Serial Number를 자동으로 수집 및 저장

 

정상 실행되는 모습

 

 

+ Recent posts