SDSM은 끝났지만 통제할 수 없는 글쓰기 욕구는 남아있습니다.

수년 동안 우리 형제는 일상적인 일을 하고, 약속하기 전에 손가락을 꼬고, 야간 롤백으로 인해 잠이 부족하여 고통을 겪었습니다.
그러나 어두운 시대가 끝나고 있습니다.

이 기사를 통해 나는 방법에 대한 시리즈를 시작할 것입니다. 나를 자동화가 보입니다.
그 과정에서 자동화, 변수 저장, 디자인 형식화, RestAPI, NETCONF, YANG, YDK의 단계를 이해하고 많은 프로그래밍을 수행하게 됩니다.
나를 a) 객관적인 진실이 아님 b) 무조건적으로 최선의 접근 방식이 아님 c) 내 의견은 첫 번째 기사에서 마지막 기사로 이동하는 동안에도 바뀔 수 있습니다. 솔직히 말하면 초안 단계에서 출판 후 나는 모든 것을 완전히 두 번 다시 썼습니다.

내용

1. 대상
   1. 네트워크는 하나의 유기체와 같습니다.
   2. 구성 테스트
   3. 버전 관리
   4. 서비스 모니터링 및 자가 복구

2. 자금
   1. 인벤토리 시스템
   2. IP 공간 관리 시스템
   3. 네트워크 서비스 설명 시스템
   4. 장치 초기화 메커니즘
   5. 공급업체에 구애받지 않는 구성 모델
   6. 공급업체별 드라이버 인터페이스
   7. 장치에 구성을 전달하는 메커니즘
   8. CI / CD
   9. 백업 및 편차 검색 메커니즘
   10. 감시 체계

3. 결론

SDSM과는 조금 다른 형식으로 ADSM을 진행해보도록 하겠습니다. 크고 상세하며 번호가 매겨진 기사가 계속해서 나올 것이며, 그 사이에 일상 경험에서 얻은 작은 메모를 게시할 것입니다. 나는 여기서 완벽주의에 맞서 싸우고 그들 모두를 핥지는 않을 것입니다.

두 번째로 같은 길을 거쳐야 한다는 게 얼마나 웃기는지요.

처음에는 네트워크가 RuNet에 없기 때문에 네트워크에 대한 기사를 직접 작성해야했습니다.

이제 자동화에 대한 접근 방식을 체계화하고 간단한 실제 사례를 사용하여 위의 기술을 분석하는 포괄적인 문서를 찾을 수 없었습니다.

제가 틀렸을 수도 있으니 유용한 자료에 대한 링크를 제공해 주세요. 그러나 이것이 글을 쓰겠다는 나의 결심을 바꾸지는 않을 것입니다. 주된 목표는 스스로 무언가를 배우는 것이고, 다른 사람들의 삶을 더 쉽게 만드는 것은 경험을 공유하기 위한 유전자를 애무하는 즐거운 보너스이기 때문입니다.

우리는 중간 규모의 LAN DC 데이터 센터를 활용하여 전체 자동화 계획을 수립하려고 노력할 것입니다.
나는 당신과 거의 처음으로 몇 가지 일을 할 것입니다.

여기서 설명하는 아이디어와 도구는 독창적이지 않습니다. 드미트리 피골(Dmitry Figol)은 훌륭합니다. 이 주제에 대한 스트림이 있는 채널.
기사들은 여러 면에서 그들과 겹칠 것입니다.

LAN DC에는 4개의 DC, 약 250개의 스위치, XNUMX개의 라우터 및 두 개의 방화벽이 있습니다.
Facebook은 아니지만 자동화에 대해 깊이 생각하게 만들기에는 충분합니다.
하지만 기기가 1개 이상이라면 자동화가 이미 필요하다는 의견도 있다.
사실 이제 누구든 무릎 대본 한 갑 없이도 살아갈 수 있다는 것을 상상하기 어렵습니다.
IP 주소가 Excel에 보관되어 있고 수천 개의 네트워크 장치 각각이 수동으로 구성되어 고유한 구성을 가지고 있는 사무실이 있다고 들었습니다. 물론 이것은 현대미술로 치부될 수도 있겠지만, 엔지니어의 감정은 분명 불쾌할 것입니다.

대상

이제 가장 추상적인 목표를 설정하겠습니다.

• 네트워크는 하나의 유기체와 같습니다.
• 구성 테스트
• 네트워크 상태 버전 관리
• 서비스 모니터링 및 자가 복구

이 글의 뒷부분에서 우리가 어떤 수단을 사용할 것인지 살펴보고, 다음에서는 목표와 수단을 자세히 살펴보겠습니다.

네트워크는 하나의 유기체와 같습니다.

이 시리즈를 정의하는 문구는 언뜻 보기에는 그다지 중요해 보이지 않을 수도 있습니다. 개별 장치가 아닌 네트워크를 구성하겠습니다..
최근 몇 년 동안 우리는 네트워크를 단일 개체로 취급하는 쪽으로 강조점이 바뀌는 것을 보았습니다. 소프트웨어 정의 네트워킹, 의도 기반 네트워크 и 자율 네트워크.
결국 네트워크에서 전 세계적으로 애플리케이션에 필요한 것은 무엇입니까? 지점 A와 B(때로는 +B-Z) 간의 연결과 다른 애플리케이션 및 사용자로부터의 격리입니다.

따라서 이 시리즈의 우리 임무는 다음과 같습니다. 시스템을 구축하다, 현재 구성 유지 전체 네트워크, 이는 역할과 위치에 따라 각 장치의 실제 구성으로 이미 분해되어 있습니다.
체계 네트워크 관리는 변경을 위해 네트워크에 연결하고 각 장치에 대해 원하는 상태를 계산하고 구성한다는 것을 의미합니다.
이러한 방식으로 우리는 CLI에 대한 수동 액세스를 거의 XNUMX으로 최소화합니다. 장치 설정이나 네트워크 설계의 모든 변경 사항은 공식화하고 문서화해야 하며 그런 다음 필요한 네트워크 요소에 적용해야 합니다.

예를 들어 지금부터 Kazan의 랙 스위치가 하나가 아닌 두 개의 네트워크를 발표해야 한다고 결정했다면

1. 먼저 시스템의 변경 사항을 문서화합니다.
2. 모든 네트워크 장치의 대상 구성 생성
3. 우리는 각 노드에서 제거해야 할 것과 추가해야 할 것을 계산하고 노드를 원하는 상태로 만드는 네트워크 구성 업데이트 프로그램을 시작합니다.

동시에 첫 번째 단계에서만 수동으로 변경합니다.

구성 테스트

알려져있다구성 변경 중에 문제의 80%가 발생합니다. 이에 대한 간접적인 증거는 새해 연휴 동안 모든 것이 일반적으로 조용하다는 것입니다.
저는 개인적으로 사람의 실수로 인해 글로벌 다운타임이 수십 번 발생하는 것을 목격했습니다. 잘못된 명령, 잘못된 브랜치에서 구성이 실행됨, 커뮤니티에서 잊어버렸음, MPLS가 라우터에서 전역적으로 철거됨, XNUMX개의 하드웨어가 구성되었으나 오류가 발생하지 않음 XNUMX번째에 다른 사람이 변경한 이전 내용이 커밋된 것으로 나타났습니다. 수많은 시나리오가 있습니다.

자동화를 통해 실수를 줄일 수 있지만 규모는 더 커집니다. 이렇게 하면 하나의 장치뿐만 아니라 전체 네트워크를 한 번에 차단할 수 있습니다.

옛날부터 우리 할아버지들은 네트워크 출시 후 예리한 눈, 강철 공 및 네트워크 기능으로 변경 사항의 정확성을 확인했습니다.
작업 중단 시간과 치명적인 손실을 초래한 할아버지는 더 적은 수의 자손을 남기고 시간이 지남에 따라 죽어야 하지만 진화는 느린 과정이므로 모든 사람이 여전히 실험실에서 변화를 먼저 테스트하는 것은 아닙니다.
그러나 발전의 최전선에는 구성 테스트 프로세스와 네트워크에 대한 추가 적용을 자동화한 사람들이 있습니다. 즉, CI/CD 절차를 빌려왔습니다(지속적인 통합, 지속적인 배포) 개발자로부터.
파트 중 하나에서는 Github과 같은 버전 제어 시스템을 사용하여 이를 구현하는 방법을 살펴보겠습니다.

네트워크 CI/CD라는 개념에 익숙해지면 하룻밤 사이에 이를 프로덕션 네트워크에 적용하여 구성을 확인하는 방법은 중세 초기의 무지처럼 보일 것입니다. 마치 망치로 탄두를 때리는 것과 같습니다.

에 대한 아이디어의 유기적 연속 체계 네트워크 관리 및 CI/CD는 구성의 전체 버전 관리가 됩니다.

버전 관리

눈에 띄지 않는 하나의 장치에서도 가장 사소한 변경 사항이라도 변경하면 전체 네트워크가 한 상태에서 다른 상태로 이동한다고 가정합니다.
그리고 우리는 항상 장치에서 명령을 실행하지 않고 네트워크 상태를 변경합니다.
그러면 이러한 상태 버전을 호출해 볼까요?

현재 버전이 1.0.0이라고 가정해 보겠습니다.
ToR 중 하나에 있는 루프백 인터페이스의 IP 주소가 변경되었습니까? 이것은 마이너 버전이며 번호는 1.0.1입니다.
우리는 경로를 BGP로 가져오기 위한 정책을 좀 더 심각하게 개정했습니다. 이미 1.1.0입니다.
우리는 IGP를 제거하고 BGP로만 전환하기로 결정했습니다. 이는 이미 획기적인 디자인 변경인 2.0.0입니다.

동시에, 서로 다른 DC는 서로 다른 버전을 가질 수 있습니다. 즉, 네트워크가 개발 중이고, 새로운 장비가 설치되고, 새로운 수준의 스파인이 다른 곳이 아닌 어딘가에 추가되고 있습니다.

약 의미론적 버전 관리 별도의 기사에서 이야기하겠습니다.

반복합니다. 모든 변경 사항(디버깅 명령 제외)은 버전 업데이트입니다. 현재 버전과의 차이점이 있으면 관리자에게 알려야 합니다.

변경 사항 롤백에도 동일하게 적용됩니다. 이는 마지막 명령을 취소하는 것이 아니며 장치 운영 체제를 사용하는 롤백이 아닙니다. 이는 전체 네트워크를 새(이전) 버전으로 가져오는 것입니다.

서비스 모니터링 및 자가 복구

이 자명한 작업은 현대 네트워크에서 새로운 수준에 도달했습니다.
대규모 서비스 제공업체에서는 무슨 일이 일어났는지 파악하는 대신 실패한 서비스를 매우 신속하게 수정하고 새 서비스를 제기해야 한다는 접근 방식을 취하는 경우가 많습니다.
"매우"는 모니터링을 통해 모든 면을 넉넉하게 코팅해야 함을 의미하며, 이는 몇 초 안에 표준에서 가장 작은 편차를 감지합니다.
그리고 여기서는 인터페이스 로딩이나 노드 가용성과 같은 일반적인 지표로는 더 이상 충분하지 않습니다. 담당관이 수동으로 모니터링하는 것만으로는 충분하지 않습니다.
많은 것들이 있어야합니다 자가 치유 — 모니터링 표시등이 빨간색으로 바뀌었고 우리는 아픈 곳에 질경이를 직접 발랐습니다.

그리고 여기에서는 개별 장치뿐만 아니라 상대적으로 이해하기 쉬운 화이트박스와 더 복잡한 블랙박스 등 전체 네트워크의 상태도 모니터링합니다.

그러한 야심찬 계획을 실행하려면 무엇이 필요합니까?

• 네트워크의 모든 장치 목록, 위치, 역할, 모델, 소프트웨어 버전이 있습니다.
  kazan-leaf-1.lmu.net, 카잔, 리프, 주니퍼 QFX 5120, R18.3.
• 네트워크 서비스를 설명하는 시스템을 갖추고 있습니다.
  IGP, BGP, L2/3VPN, 정책, ACL, NTP, SSH.
• 장치를 초기화할 수 있습니다.
  호스트 이름, 관리 IP, 관리 경로, 사용자, RSA 키, LLDP, NETCONF
• 장치를 구성하고 구성을 원하는(이전 포함) 버전으로 가져옵니다.
• 테스트 구성
• 정기적으로 모든 장치의 상태를 현재 장치와 다른지 확인하고 누구에게 보고해야 하는지 확인하십시오.
  하룻밤 사이에 누군가 조용히 ACL에 규칙을 추가했습니다..
• 성능을 모니터링합니다.

자금

프로젝트를 구성 요소로 분해하기 시작하는 것은 충분히 복잡해 보입니다.

그리고 그 중 XNUMX개가 있을 것입니다:

1. 인벤토리 시스템
2. IP 공간 관리 시스템
3. 네트워크 서비스 설명 시스템
4. 장치 초기화 메커니즘
5. 공급업체에 구애받지 않는 구성 모델
6. 공급업체별 드라이버 인터페이스
7. 장치에 구성을 전달하는 메커니즘
8. CI / CD
9. 백업 및 편차 검색 메커니즘
10. 감시 체계

그건 그렇고, 이것은주기의 목표에 대한 견해가 어떻게 바뀌 었는지 보여주는 예입니다. 초안에는 4 가지 구성 요소가 있습니다.

그림에서는 모든 구성 요소와 장치 자체를 묘사했습니다.
교차하는 구성 요소는 서로 상호 작용합니다.
블록이 클수록 이 구성요소에 더 많은 주의를 기울여야 합니다.

구성요소 1: 재고 시스템

분명히 우리는 어떤 장비가 어디에 있는지, 무엇이 연결되어 있는지 알고 싶습니다.
재고 시스템은 모든 기업의 필수적인 부분입니다.
대부분의 경우 기업은 네트워크 장치에 대한 별도의 인벤토리 시스템을 보유하여 보다 구체적인 문제를 해결합니다.
이 기사 시리즈의 일부로 이를 DCIM(데이터 센터 인프라 관리)이라고 부르겠습니다. 엄밀히 말하면 DCIM이라는 용어 자체에는 훨씬 더 많은 내용이 포함되어 있습니다.

당사의 목적을 위해 당사는 장치에 대한 다음 정보를 저장합니다.

• 재고 번호
• 제목 설명
• 모델 (화웨이 CE12800, 주니퍼 QFX5120 등)
• 특성 매개변수(보드, 인터페이스 등)
• 역할 (리프, 스파인, 보더 라우터 등)
• 위치 (지역, 도시, 데이터 센터, 랙, 장치)
• 장치 간 상호 연결
• 네트워크 토폴로지

우리 자신도 이 모든 것을 알고 싶어한다는 것은 아주 분명합니다.
하지만 이것이 자동화 목적에 도움이 될까요?
물론.
예를 들어, Leaf 스위치의 특정 데이터 센터에서 Huawei라면 특정 트래픽을 필터링하는 ACL을 VLAN에 적용해야 하고, Juniper라면 물리적 인터페이스의 유닛 0에 적용해야 한다는 것을 알고 있습니다.
또는 해당 지역의 모든 경계에 새로운 Syslog 서버를 출시해야 합니다.

여기에는 가상 라우터나 루트 리플렉터와 같은 가상 네트워크 장치를 저장합니다. DNS 서버, NTP, Syslog 및 일반적으로 네트워크와 관련된 모든 것을 추가할 수 있습니다.

구성요소 2: IP 공간 관리 시스템

그렇습니다. 요즘에는 Excel 파일의 접두어와 IP 주소를 추적하는 사람들로 구성된 팀이 있습니다. 그러나 현대적인 접근 방식은 여전히 ​​nginx/apache의 프런트 엔드, API 및 IP 주소와 VRF로 분할된 네트워크를 기록하기 위한 광범위한 기능을 갖춘 데이터베이스입니다.
IPAM - IP 주소 관리.

당사의 목적을 위해 당사는 다음 정보를 여기에 저장합니다.

• VLAN
• VRF
• 네트워크/서브넷
• IP 주소
• 장치에 주소 바인딩, 위치에 네트워크 바인딩 및 VLAN 번호

다시 말하지만, ToR 루프백을 위해 새 IP 주소를 할당할 때 해당 IP 주소가 이미 누군가에게 할당되었다는 사실을 발견하지 않도록 해야 한다는 점은 분명합니다. 또는 네트워크의 서로 다른 끝에서 동일한 접두사를 두 번 사용했습니다.
하지만 이것이 자동화에 어떻게 도움이 될까요?
쉬운
할당에 사용할 수 있는 IP 주소가 포함된 루프백 역할이 있는 시스템에서 접두사를 요청합니다. 발견되면 주소를 할당하고, 그렇지 않으면 새 접두사 생성을 요청합니다.
또는 장치 구성을 생성할 때 VRF 인터페이스가 위치해야 하는 동일한 시스템에서 찾을 수 있습니다.
그리고 새 서버를 시작할 때 스크립트는 시스템에 로그인하여 서버가 어느 스위치에 있는지, 어느 포트와 어느 서브넷이 인터페이스에 할당되어 있는지 확인하고 여기에서 서버 주소를 할당합니다.

이는 기능을 중복하지 않고 두 개의 유사한 엔터티를 제공하지 않도록 DCIM과 IPAM을 하나의 시스템으로 결합하려는 욕구를 나타냅니다.
그것이 우리가 할 일입니다.

구성요소 3. 네트워크 서비스 설명 시스템

처음 두 시스템이 어떻게든 사용해야 하는 변수를 저장하는 경우 세 번째 시스템은 각 장치 역할에 대해 구성 방법을 설명합니다.
두 가지 유형의 네트워크 서비스를 구별하는 것이 좋습니다.

• 하부 구조
• 고객.

전자는 기본적인 연결과 장치 제어를 제공하도록 설계되었습니다. 여기에는 VTY, SNMP, NTP, Syslog, AAA, 라우팅 프로토콜, CoPP 등이 포함됩니다.
후자는 MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP 등 클라이언트를 위한 서비스를 구성합니다.
물론 경계선에 있는 경우도 있습니다. MPLS LDP, BGP를 어디에 포함해야 할까요? 예, 클라이언트에 라우팅 프로토콜을 사용할 수 있습니다. 그러나 이것은 중요하지 않습니다.

두 가지 유형의 서비스 모두 구성 기본 요소로 분해됩니다.

• 물리적 및 논리적 인터페이스(태그/anteg, mtu)
• IP 주소 및 VRF(IP, IPv6, VRF)
• ACL 및 트래픽 처리 정책
• 프로토콜(IGP, BGP, MPLS)
• 라우팅 정책(접두사 목록, 커뮤니티, ASN 필터)
• 유틸리티 서비스(SSH, NTP, LLDP, Syslog...)
• 등.

우리가 이것을 정확히 어떻게 할지는 아직 모르겠습니다. 이에 대해서는 별도의 글에서 살펴보겠습니다.

삶에 조금 더 가까우면 다음과 같이 설명할 수 있습니다.
Leaf 스위치에는 연결된 모든 Spine 스위치와의 BGP 세션이 있어야 하고, 연결된 네트워크를 프로세스로 가져오고, Spine 스위치의 특정 접두사의 네트워크만 허용해야 합니다. CoPP IPv6 ND를 10pps 등으로 제한합니다.
차례로 척추는 연결된 모든 리드와 세션을 유지하여 루트 리플렉터 역할을 하며 특정 길이와 특정 커뮤니티의 경로만 허용합니다.

구성요소 4: 장치 초기화 메커니즘

이 제목 아래에는 장치가 레이더에 표시되고 원격으로 액세스되기 위해 발생해야 하는 많은 작업이 결합되어 있습니다.

1. 인벤토리 시스템에 장치를 입력하세요.
2. 관리 IP 주소를 선택합니다.
3. 이에 대한 기본 액세스를 설정합니다.
   호스트 이름, 관리 IP 주소, 관리 네트워크 경로, 사용자, SSH 키, 프로토콜 - telnet/SSH/NETCONF

세 가지 접근 방식이 있습니다.

• 모든 것이 완전히 수동입니다. 장치를 스탠드로 가져오면 일반 사람이 시스템에 장치를 입력하고 콘솔에 연결하여 구성합니다. 소규모 정적 네트워크에서 작업할 수 있습니다.
• ZTP - 제로 터치 프로비저닝. 하드웨어가 도착하여 작동하고 DHCP를 통해 주소를 수신한 후 특수 서버로 이동하여 자체적으로 구성되었습니다.
• 자동 모드에서 콘솔 포트를 통해 초기 구성이 이루어지는 콘솔 서버의 인프라입니다.

세 가지 모두에 대해서는 별도의 기사에서 이야기하겠습니다.

구성요소 5: 공급업체에 구애받지 않는 구성 모델

지금까지 모든 시스템은 우리가 네트워크에서 보고자 하는 내용에 대한 선언적 설명과 변수를 제공하는 서로 다른 패치였습니다. 그러나 조만간 구체적인 사항을 다루어야 할 것입니다.
이 단계에서는 각 특정 장치에 대해 기본 요소, 서비스 및 변수가 공급업체 중립적 방식으로만 특정 장치의 전체 구성을 실제로 설명하는 구성 모델로 결합됩니다.
이 단계는 무엇을 합니까? 간단히 업로드할 수 있는 장치 구성을 즉시 생성해 보는 것은 어떨까요?
실제로 이는 세 가지 문제를 해결합니다.

1. 장치와 상호 작용하기 위해 특정 인터페이스에 적응하지 마십시오. CLI, NETCONF, RESTCONF, SNMP 등 모델은 동일합니다.
2. 네트워크상의 벤더 수에 따라 템플릿/스크립트 수를 유지하지 말고, 디자인이 변경되면 여러 곳에서 동일한 내용을 변경하십시오.
3. 장치에서 구성을 로드(백업)하고 정확히 동일한 모델에 넣은 다음 대상 구성을 기존 구성과 직접 비교하여 델타를 계산하고 필요한 부분만 변경하거나 편차를 식별하는 구성 패치를 준비합니다.

이 단계의 결과로 공급업체에 독립적인 구성을 얻게 됩니다.

구성 요소 6. 공급업체별 드라이버 인터페이스

언젠가 ciska에 정확히 동일한 호출을 보내는 것만으로도 Juniper와 정확히 동일한 방식으로 ciska를 구성할 수 있을 것이라는 희망을 품고 자만해서는 안 됩니다. 화이트박스의 인기가 높아지고 NETCONF, RESTCONF, OpenConfig에 대한 지원이 등장함에도 불구하고 이러한 프로토콜이 제공하는 특정 콘텐츠는 공급업체마다 다르며 이는 쉽게 포기하지 않을 경쟁력 있는 차이점 중 하나입니다.
이는 NorthBound 인터페이스로 RestAPI를 사용하는 OpenContrail 및 OpenStack과 거의 동일하며 완전히 다른 호출을 예상합니다.

따라서 다섯 번째 단계에서는 공급업체 독립적 모델이 하드웨어에 적용되는 형태를 취해야 합니다.
그리고 여기에는 CLI, NETCONF, RESTCONF, SNMP 등 모든 수단이 좋습니다.

따라서 이전 단계의 결과를 특정 공급업체의 필수 형식(CLI 명령 세트, XML 구조)으로 전송하는 드라이버가 필요합니다.

구성 요소 7. 장치에 구성을 전달하는 메커니즘

구성을 생성했지만 여전히 장치에 전달해야 하며 손으로 직접 전달해서는 안 됩니다.
첫째로, 우리는 어떤 교통수단을 이용할 것인지에 대한 질문에 직면합니다. 그리고 오늘날 선택의 폭은 더 이상 작지 않습니다.

• CLI(텔넷, SSH)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow(설정이 아니라 FIB를 전달하는 방법이므로 이상치임에도 불구하고)

여기에 t에 점을 찍자. CLI는 레거시입니다. SNMP... 기침 기침.
RESTCONF는 아직 알려지지 않은 동물이므로 REST API를 지원하는 사람은 거의 없습니다. 따라서 시리즈에서는 NETCONF에 중점을 둘 것입니다.

사실, 독자가 이미 이해했듯이, 이 시점에서 우리는 이미 인터페이스를 결정했습니다. 이전 단계의 결과는 이미 선택한 인터페이스의 형식으로 표시됩니다.

둘째로, 그리고 어떤 도구를 사용하여 이를 수행할 것인가?
여기에도 선택의 폭이 넓습니다.

• 자체 작성 스크립트 또는 플랫폼. ncclient와 asyncIO로 무장하고 모든 것을 스스로 해보자. 배포 시스템을 처음부터 구축하는 데 비용이 얼마나 드나요?
• 풍부한 네트워킹 모듈 라이브러리를 갖춘 Ansible.
• 네트워크와의 빈약한 작업 및 Napalm과의 연결이 있는 소금입니다.
• 실제로 몇 개의 공급업체를 알고 있는 Napalm은 이제 안녕입니다.
• 노르니르(Nornir)는 우리가 앞으로 해부할 또 다른 동물입니다.

여기서는 즐겨찾기가 아직 선택되지 않았습니다. 검색하겠습니다.

여기서 또 무엇이 중요합니까? 구성 적용의 결과.
성공 여부. 여전히 하드웨어에 액세스할 수 있나요?
여기에서 커밋이 장치에 다운로드된 내용을 확인하고 검증하는 데 도움이 될 것 같습니다.
이는 NETCONF의 올바른 구현과 결합되어 적합한 장치의 범위를 크게 좁힙니다. 일반 커밋을 지원하는 제조업체는 많지 않습니다. 하지만 이는 전제조건 중 하나일 뿐이다. RFP. 결국, 러시아 벤더 중 단 한 곳도 32*100GE 인터페이스 조건을 준수하지 않을 것이라고 걱정하는 사람은 아무도 없습니다. 아니면 걱정하고 있는 걸까요?

구성요소 8. CI/CD

이 시점에서는 이미 모든 네트워크 장치에 대한 구성이 준비되어 있습니다.
나는 네트워크 상태의 버전 관리에 대해 이야기하고 있기 때문에 "for everything"이라고 씁니다. 그리고 하나의 스위치 설정만 변경해야 하는 경우에도 전체 네트워크에 대한 변경 사항이 계산됩니다. 분명히 대부분의 노드에서는 XNUMX이 될 수 있습니다.

그러나 위에서 이미 말했듯이 우리는 모든 것을 곧바로 생산에 투입하려는 일종의 야만인이 아닙니다.
생성된 구성은 먼저 파이프라인 CI/CD를 거쳐야 합니다.

CI/CD는 지속적인 통합, 지속적인 배포를 의미합니다. 이는 팀이 XNUMX개월마다 새로운 주요 릴리스를 출시하여 이전 릴리스를 완전히 대체할 뿐만 아니라 정기적으로 새로운 기능을 작은 부분씩 점진적으로 구현(배포)하며 각 기능은 호환성, 보안 및 성능에 대해 종합적으로 테스트됩니다. 성능(통합).

이를 위해 우리는 구성 변경을 모니터링하는 버전 제어 시스템, 클라이언트 서비스가 중단되었는지 확인하는 실험실, 이 사실을 확인하는 모니터링 시스템을 갖추고 있으며 마지막 단계는 변경 사항을 프로덕션 네트워크에 롤아웃하는 것입니다.

디버깅 명령을 제외하고 네트워크의 모든 변경 사항은 반드시 CI/CD 파이프라인을 거쳐야 합니다. 이는 조용한 삶과 길고 행복한 경력을 보장합니다.

구성 요소 9. 백업 및 이상 탐지 시스템

글쎄, 백업에 대해 다시 이야기 할 필요가 없습니다.
우리는 크라운이나 구성 변경 사실에 따라 간단히 git에 넣을 것입니다.

그러나 두 번째 부분이 더 흥미롭습니다. 누군가는 이러한 백업을 계속 주시해야 합니다. 그리고 어떤 경우에는 이 누군가가 가서 모든 것을 있는 그대로 돌려야 하고, 다른 경우에는 누군가에게 뭔가 잘못되었다고 야옹야옹해야 합니다.
예를 들어, 변수에 등록되지 않은 새로운 사용자가 나타나면 해당 사용자를 해킹에서 제거해야 합니다. 그리고 새로운 방화벽 규칙을 건드리지 않는 것이 더 낫다면 누군가가 방금 디버깅을 켰거나 새로운 서비스인 벙글러가 규정에 따라 등록되지 않았지만 사람들이 이미 가입했을 수도 있습니다.

자동화 시스템과 강력한 관리의 손길에도 불구하고 우리는 여전히 전체 네트워크 규모의 작은 델타에서 벗어나지 못할 것입니다. 문제를 디버깅하기 위해 누구도 시스템에 구성을 추가하지 않습니다. 또한 구성 모델에 포함되지 않을 수도 있습니다.

예를 들어 문제를 국지화하기 위해 특정 IP당 패킷 수를 계산하는 방화벽 규칙은 완전히 일반적인 임시 구성입니다.

구성요소 10. 모니터링 시스템

처음에는 모니터링이라는 주제를 다루지 않으려고 했습니다. 이는 여전히 방대하고 논란의 여지가 있으며 복잡한 주제입니다. 그러나 일이 진행되면서 이것이 자동화의 필수적인 부분이라는 것이 밝혀졌습니다. 그리고 연습 없이도 그것을 우회하는 것은 불가능합니다.

진화하는 생각은 CI/CD 프로세스의 유기적인 부분입니다. 구성을 네트워크에 적용한 후 이제 모든 것이 괜찮은지 확인할 수 있어야 합니다.
그리고 우리는 인터페이스 사용 일정이나 노드 가용성뿐만 아니라 필요한 경로의 존재, 해당 속성, BGP 세션 수, OSPF 이웃, 엔드투엔드 성능과 같은 더 미묘한 사항에 대해서도 이야기하고 있습니다. 상위 서비스의.
외부 서버에 대한 syslog가 더 이상 추가되지 않았나요, 아니면 SFlow 에이전트가 중단되었나요, 아니면 대기열의 삭제가 증가하기 시작했습니까, 아니면 일부 접두사 쌍 간의 연결이 중단되었습니까?

이에 대해서는 별도의 기사에서 반영하겠습니다.

결론

기본적으로 저는 최신 데이터 센터 네트워크 설계 중 하나인 라우팅 프로토콜로 BGP를 사용하는 L3 Clos Fabric을 선택했습니다.
이제 JunOs 인터페이스가 vanlove이기 때문에 이번에는 Juniper에 네트워크를 구축하겠습니다.

오픈 소스 도구와 멀티 벤더 네트워크만을 사용하여 우리의 삶을 더 어렵게 만들자. 그래서 주니퍼 외에 행운의 사람을 한 명 더 선택하겠습니다.

앞으로의 출판 계획은 다음과 같습니다.
먼저 가상 네트워크에 대해 이야기하겠습니다. 첫째는 내가 원하기 때문이고 둘째는 이것이 없으면 인프라 네트워크의 설계가 그다지 명확하지 않을 것이기 때문입니다.
그런 다음 네트워크 설계 자체(토폴로지, 라우팅, 정책)에 대해 설명합니다.
실험실 스탠드를 조립해 봅시다.
그것에 대해 생각해보고 네트워크에서 장치를 초기화하는 연습을 해 봅시다.
그런 다음 각 구성 요소에 대해 자세히 설명합니다.

그리고 그렇습니다. 저는 기성 솔루션으로 이 주기를 우아하게 끝내겠다고 약속하지 않습니다. 🙂

유용한 링크

• 시리즈를 살펴보기 전에 나타샤 사모일렌코(Natasha Samoilenko)의 책을 읽어볼 가치가 있습니다. 네트워크 엔지니어를 위한 Python. 그리고 어쩌면 통과할지도 코스.
• 읽어보는 것도 도움이 될 거예요 RFC Peter Lapukhov가 Facebook의 데이터 센터 공장 설계에 대해 설명합니다.
• 아키텍처 문서는 오버레이 SDN의 작동 방식에 대한 아이디어를 제공합니다. 텅스텐 직물 (이전의 Open Contrail).

감사합니다

로마 협곡. 의견 및 편집용.
아르템 체르노바이. KDPV의 경우.

출처 : habr.com