처음 두 기사에서는 자동화 문제를 제기하고 해당 프레임워크를 개략적으로 설명했으며, 두 번째 기사에서는 서비스 구성 자동화를 위한 첫 번째 접근 방식인 네트워크 가상화로 후퇴했습니다.
이제 물리적 네트워크의 다이어그램을 그릴 차례입니다.

데이터 센터 네트워크 설정에 익숙하지 않다면 다음부터 시작하는 것이 좋습니다. 그들에 관한 기사.

모든 문제:

• 0. ADSM. 파트 제로. 계획
• 1. ADSM. XNUMX부(XNUMX 이후) 네트워크 가상화
• 2. ADSM. 두 번째 부분. 네트워크 설계

이 시리즈에서 설명하는 사례는 모든 유형, 모든 규모, 다양한 공급업체(아님)에 적용 가능해야 합니다. 그러나 이러한 접근법을 적용한 보편적인 예를 설명하는 것은 불가능합니다. 따라서 저는 DC 네트워크의 최신 아키텍처에 중점을 둘 것입니다. 클로즈팩토리.
MPLS L3VPN에서 DCI를 수행하겠습니다.

오버레이 네트워크는 호스트의 물리적 네트워크 위에서 실행됩니다(OpenStack의 VXLAN, Tungsten Fabric 또는 네트워크에서 기본 IP 연결만 필요한 기타 네트워크일 수 있음).

이 경우 동일한 방식으로 구성된 장비가 많기 때문에 자동화에 대한 비교적 간단한 시나리오를 얻습니다.

진공 상태에서 구형 DC를 선택하겠습니다.

• 어디서나 하나의 디자인 버전.
• 두 공급업체가 두 개의 네트워크 플레인을 형성합니다.
• 하나의 DC는 꼬투리에 있는 두 개의 완두콩과 같습니다.

내용

• 물리적 토폴로지
• 라우팅
• IP 계획
• 라바
• 결론
• 유용한 링크

예를 들어 서비스 제공업체인 LAN_DC는 갇힌 엘리베이터에서 생존하는 방법에 대한 교육 비디오를 호스팅합니다.

대도시에서는 이것이 매우 인기가 있으므로 많은 물리적 기계가 필요합니다.

먼저, 내가 원하는 대로 네트워크를 대략적으로 설명하겠습니다. 그런 다음 실습을 위해 단순화하겠습니다.

물리적 토폴로지

위치

LAN_DC에는 6개의 DC가 있습니다.

• 러시아 (RU):
  • 모스크바(MSK)
  • 카잔(kzn)

• 스페인(SP):
  • 바르셀로나(BCN)
  • 말라가(MLG)

• 중국 (CN):
  • 상하이(SHA)
  • 시안(시아)

내부 DC(DC 내부)

모든 DC에는 Clos 토폴로지를 기반으로 하는 동일한 내부 연결 네트워크가 있습니다.
Clos 네트워크는 어떤 종류이며 왜 별도의 네트워크에 있습니까? 기사.

각 DC에는 머신이 포함된 10개의 랙이 있으며 번호는 다음과 같습니다. A, B, C 등등.

각 랙에는 30개의 머신이 있습니다. 그들은 우리에게 관심이 없을 것입니다.

또한 각 랙에는 모든 기계가 연결되는 스위치가 있습니다. 랙 상단 스위치 - ToR 그렇지 않으면 Clos 공장이라고 부르겠습니다. 잎.

공장의 일반 다이어그램입니다.

우리가 전화할게 트리플 엑스-잎Y어디에서 트리플 엑스 - XNUMX자리 약어 DC Y - 일련번호. 예를 들어, kzn-leaf11.

내 기사에서 나는 Leaf와 ToR이라는 용어를 동의어로 다소 경솔하게 사용하도록 허용할 것입니다. 그러나 우리는 그렇지 않다는 것을 기억해야 합니다.
ToR은 기계가 연결된 랙에 설치되는 스위치입니다.
리프는 Cloes 토폴로지 측면에서 물리적 네트워크 또는 XNUMX차 스위치의 장치 역할입니다.
즉, Leaf != ToR입니다.
예를 들어 Leaf는 EndofRaw 스위치가 될 수 있습니다.
그러나 이 기사의 틀 내에서는 이들을 동의어로 취급할 것입니다.

각 ToR 스위치는 차례로 XNUMX개의 상위 수준 집계 스위치에 연결됩니다. 등뼈. DC의 랙 하나가 Spines용으로 할당됩니다. 비슷하게 이름을 지정하겠습니다. 트리플 엑스-척추Y.

동일한 랙에는 MPLS가 탑재된 DC-2 라우터 간의 연결을 위한 네트워크 장비가 포함됩니다. 그러나 대체로 이는 동일한 ToR입니다. 즉, Spine 스위치의 관점에서 보면 연결된 시스템이 있는 일반적인 ToR이나 DCI용 라우터는 전혀 중요하지 않습니다. 단지 전달만 하면 됩니다.

이러한 특별한 ToR을 호출합니다. 엣지리프. 우리가 전화할게 트리플 엑스-가장자리Y.

다음과 같이 보일 것입니다.

위의 다이어그램에서는 실제로 가장자리와 잎을 같은 수준에 배치했습니다. 클래식 XNUMX계층 네트워크 그들은 우리에게 업링크(이 용어의 유래)를 업링크로 간주하도록 가르쳤습니다. 그리고 여기에서 DCI "업링크"가 다시 다운되는 것으로 밝혀졌으며, 이는 일부의 경우 일반적인 논리를 약간 깨뜨립니다. 대규모 네트워크의 경우 데이터 센터를 더 작은 단위로 분할하는 경우 - 현물 상환 지불'(Point Of Delivery), 개별 강조 표시 엣지-PODDCI 및 외부 네트워크에 대한 액세스용입니다.

앞으로도 쉽게 인식할 수 있도록 Spine 위에 Edge를 그릴 것입니다. 반면 Spine에는 지능이 없으며 일반 Leaf 및 Edge-leaf로 작업할 때 차이가 없다는 점을 염두에 둘 것입니다(여기에는 뉘앙스가 있을 수 있음). , 그러나 일반적으로 이것은 사실입니다).

Edge-leafs를 갖춘 공장 계획.

Leaf, Spine 및 Edge의 삼위일체는 Underlay 네트워크 또는 팩토리를 형성합니다.

이미 정의한 대로 네트워크 팩토리(Underlay 읽기)의 작업 지난 호, 매우 간단합니다. 동일한 DC 내의 머신과 머신 사이에 IP 연결을 제공합니다.
이것이 바로 모듈형 네트워크 상자 내부의 스위칭 공장과 마찬가지로 네트워크를 공장이라고 부르는 이유입니다. SDSM14.

일반적으로 이러한 토폴로지를 팩토리라고 합니다. 왜냐하면 번역에서 패브릭은 패브릭을 의미하기 때문입니다. 동의하지 않는 것이 어렵습니다.

공장은 완전히 L3입니다. VLAN 없음, 브로드캐스트 없음 - LAN_DC에는 훌륭한 프로그래머가 있습니다. 그들은 L3 패러다임에 있는 애플리케이션을 작성하는 방법을 알고 있으며, 가상 머신에는 IP 주소를 보존하는 실시간 마이그레이션이 필요하지 않습니다.

그리고 다시 한 번: 왜 공장이 있고 L3가 별도의 공장에 있는 이유에 대한 대답입니다. 기사.

DCI - 데이터 센터 상호 연결(Inter-DC)

DCI는 Edge-Leaf를 사용하여 구성됩니다. 즉, DCI는 고속도로의 출구 지점입니다.
단순화를 위해 DC가 직접 링크로 서로 연결되어 있다고 가정합니다.
외부 연결을 고려 대상에서 제외하겠습니다.

나는 구성 요소를 제거할 때마다 네트워크가 크게 단순화된다는 것을 알고 있습니다. 그리고 추상 네트워크를 자동화하면 모든 것이 괜찮을 것이지만 실제 네트워크에는 목발이 있을 것입니다.
이것은 사실이다. 그럼에도 불구하고 이 시리즈의 요점은 상상의 문제를 영웅적으로 해결하는 것이 아니라 접근 방식에 대해 생각하고 작업하는 것입니다.

Edge-Leafs에서 언더레이는 VPN에 배치되고 MPLS 백본(동일한 직접 링크)을 통해 전송됩니다.

이것이 우리가 얻는 최상위 다이어그램입니다.

라우팅

DC 내 라우팅에는 BGP를 사용합니다.
MPLS 트렁크 OSPF+LDP에서.
DCI의 경우 지하에서 연결을 구성합니다(MPLS를 통한 BGP L3VPN).

일반 라우팅 방식

공장에는 OSPF 또는 ISIS(러시아 연방에서 금지된 라우팅 프로토콜)가 없습니다.

즉, 자동 검색이나 최단 경로 계산은 없으며 프로토콜, 네이버후드 및 정책을 수동으로 설정하는 것(실제로는 자동 - 여기서는 자동화에 대해 이야기하고 있음)만 수행됩니다.

DC 내의 BGP 라우팅 방식

왜 BGP인가?

이 주제에는 전체 RFC 빌드 방법을 알려주는 Facebook과 Arista의 이름을 따서 명명되었습니다. 매우 큰 BGP를 사용하는 데이터 센터 네트워크. 거의 소설처럼 읽혀서 나른한 저녁에 적극 추천합니다.

그리고 내 기사에는 이에 대한 전체 섹션도 있습니다. 나는 당신을 어디로 데려가나요? 나는 보내는 중이다.

그러나 간단히 말해서 네트워크 장치 수가 수천 개에 달하는 대규모 데이터 센터의 네트워크에는 적합한 IGP가 없습니다.

또한 어디에서나 BGP를 사용하면 여러 가지 프로토콜을 지원하고 프로토콜 간 동기화에 시간을 낭비하지 않아도 됩니다.

높은 확률로 빠르게 성장하지 않을 가능성이 높은 우리 공장에서는 OSPF만으로도 눈에 충분할 것입니다. 이것은 실제로 거대 규모 기업과 클라우드 타이탄의 문제입니다. 하지만 우리에게 필요한 몇 가지 릴리스에만 BGP를 사용한다고 가정해 보겠습니다. 표트르 라푸호프(Pyotr Lapukhov)가 물려준 것처럼 우리는 BGP를 사용할 것입니다.

라우팅 정책

리프 스위치에서는 Underlay 네트워크 인터페이스의 접두사를 BGP로 가져옵니다.
우리는 다음 사이에 BGP 세션을 가질 것입니다. 각각의 이러한 Underlay 접두사가 네트워크를 통해 여기저기서 발표되는 리프-스파인 쌍입니다.

하나의 데이터 센터 내에서 ToRe로 가져온 사양을 배포합니다. Edge-Leafs에서는 이를 집계하여 원격 DC에 알리고 TOR로 보냅니다. 즉, 각 ToR은 동일한 DC의 다른 ToR에 도달하는 방법과 다른 DC의 ToR에 도달하는 진입점이 어디인지 정확히 알 수 있습니다.

DCI에서는 경로가 VPNv4로 전송됩니다. 이를 위해 Edge-Leaf에서 공장을 향한 인터페이스가 VRF에 배치되고 이를 UNDERLAY라고 부르며 Edge-Leaf의 Spine이 있는 이웃은 VRF 내에서 VPNv4의 Edge-Leaf 사이에서 상승합니다. 가족.

또한 Spine에서 수신한 경로를 다시 발표하는 것을 금지합니다.

Leaf 및 Spine에서는 루프백을 가져오지 않습니다. 라우터 ID를 결정하는 데만 필요합니다.

그러나 Edge-Leafs에서는 이를 Global BGP로 가져옵니다. 루프백 주소 사이에서 Edge-Leafs는 IPv4 VPN 제품군에서 서로 BGP 세션을 설정합니다.

EDGE 장치 사이에는 OSPF+LDP 백본이 있습니다. 모든 것이 하나의 영역에 있습니다. 매우 간단한 구성.

라우팅을 적용한 사진입니다.

BGP ASN

에지-리프 ASN

Edge-Leaf에는 모든 DC에 하나의 ASN이 있습니다. Edge-Leaf 사이에 iBGP가 있는 것이 중요하며 eBGP의 뉘앙스에 얽매이지 않습니다. 65535라고 합시다. 실제로는 공개 AS의 번호일 수 있습니다.

척추 ASN

Spine에서는 DC당 하나의 ASN을 갖습니다. 여기서는 개인 AS 범위(64512, 64513 등)의 첫 번째 숫자부터 시작하겠습니다.

왜 DC에 ASN이 있나요?

이 질문을 두 가지로 나누어 보겠습니다.

• 한 DC의 모든 스파인에서 ASN이 동일한 이유는 무엇입니까?
• DC마다 다른 이유는 무엇입니까?

하나의 DC의 모든 스파인에 동일한 ASN이 있는 이유는 무엇입니까?

Edge-Leaf에 있는 Underlay 경로의 AS-Path는 다음과 같습니다.
[leafX_ASN, spine_ASN, edge_ASN]
Spine에 다시 광고하려고 하면 해당 AS(Spine_AS)가 이미 목록에 있기 때문에 삭제됩니다.

그러나 DC 내에서는 Edge로 올라가는 Underlay 경로가 내려갈 수 없다는 점에 완전히 만족합니다. DC 내의 호스트 간의 모든 통신은 스파인 수준 내에서 이루어져야 합니다.

이 경우 다른 DC의 집계된 경로는 어떤 경우에도 쉽게 ToR에 도달합니다. 해당 AS-Path에는 AS Edge-Leaf의 수인 ASN 65535만 포함됩니다. 왜냐하면 그곳에서 생성되었기 때문입니다.

DC마다 다른 이유는 무엇입니까?

이론적으로는 루프백과 일부 서비스 가상 머신을 DC 간에 끌어야 할 수도 있습니다.

예를 들어 호스트에서 Route Reflector를 실행하거나 같은 VNGW (가상 네트워크 게이트웨이)는 BGP를 통해 TopR과 잠그고 모든 DC에서 액세스할 수 있는 루프백을 알립니다.

따라서 AS-Path는 다음과 같습니다.
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

그리고 어디에도 중복된 ASN이 있어서는 안 됩니다.

즉, Spine_DC1과 Spine_DC2는 leafX_DC1과 leafY_DC2처럼 달라야 합니다. 이것이 바로 우리가 접근하고 있는 것입니다.

아시다시피 루프 방지 메커니즘(Cisco에서는 허용)에도 불구하고 중복된 ASN이 있는 경로를 허용하는 해킹이 있습니다. 그리고 심지어 합법적인 용도도 있습니다. 그러나 이는 네트워크 안정성에 있어서 잠재적인 격차입니다. 그리고 저는 개인적으로 그것에 몇 번 빠졌습니다.

그리고 위험한 것을 사용하지 않을 기회가 있다면 우리는 그것을 활용할 것입니다.

리프 ASN

네트워크 전체의 각 리프 스위치에는 개별 ASN이 있습니다.
위에서 설명한 이유 때문에 이 작업을 수행합니다. 루프가 없는 AS-Path, 북마크가 없는 BGP 구성.

Leaf 사이의 경로가 원활하게 전달되려면 AS-Path가 다음과 같아야 합니다.
[leafX_ASN, spine_ASN, leafY_ASN]
여기서 leafX_ASN과 leafY_ASN은 달라야 합니다.

이는 DC 간 VNF 루프백이 발표되는 상황에도 필요합니다.
[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

4바이트 ASN을 사용하고 Spine의 ASN과 Leaf 스위치 번호를 기반으로 다음과 같이 생성합니다. Spine_ASN.0000X.

ASN을 사용한 사진입니다.

IP 계획

기본적으로 다음 연결에 주소를 할당해야 합니다.

1. ToR과 시스템 간의 기본 네트워크 주소입니다. 모든 시스템이 다른 시스템과 통신할 수 있도록 전체 네트워크 내에서 고유해야 합니다. 핏이 좋음 10/8. 각 랙에는 예비 공간이 있는 /26이 있습니다. DC당 /19, 지역당 /17을 할당합니다.
2. Leaf/Tor와 Spine 간의 주소를 연결합니다.

   이를 알고리즘적으로 할당하고 싶습니다. 즉, 연결해야 하는 장치의 이름에서 계산합니다.

   놔두세요... 169.254.0.0/16.
   즉 169.254.00X.Y/31어디에서 X - 척추 번호, Y — P2P 네트워크 /31.
   이를 통해 DC에서 최대 128개의 랙과 최대 10개의 Spine을 실행할 수 있습니다. 링크 주소는 DC에서 DC로 반복될 수 있습니다.

3. 서브넷에서 Spine-Edge-Leaf 접합을 구성합니다. 169.254.10X.Y/31, 정확히 같은 곳 X - 척추 번호, Y — P2P 네트워크 /31.
4. Edge-Leaf에서 MPLS 백본으로 주소를 연결합니다. 여기에서는 상황이 다소 다릅니다. 모든 조각이 하나의 파이로 연결되어 있으므로 동일한 주소를 재사용하면 작동하지 않습니다. 다음 무료 서브넷을 선택해야 합니다. 그러므로 기준으로 삼자 192.168.0.0/16 그리고 우리는 그것으로부터 자유로운 자들을 긁어낼 것입니다.
5. 루프백 주소. 우리는 그들을 위해 전체 범위를 제공할 것입니다 172.16.0.0/12.
   • 리프 - DC당 /25 - 동일한 128개 랙. 지역별로 /23을 할당하겠습니다.
   • 척추 - DC당 /28 - 최대 16개의 척추. 지역별로 /26을 할당해 보겠습니다.
   • Edge-Leaf - DC당 /29 - 최대 8개 상자. 지역별로 /27을 할당해보자.

DC에 할당된 범위가 충분하지 않은 경우(아무것도 없을 경우 - 우리는 하이퍼스케일러라고 주장함) 다음 블록을 선택하기만 하면 됩니다.

IP 주소가 있는 사진입니다.

루프백:

접두사
장치 역할
지방
DC

172.16.0.0/23
가장자리
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
MSK

172.16.0.8/29
kzn

172.16.0.32/27
sp
 

172.16.0.32/29
BCN

172.16.0.40/29
MLG

172.16.0.64/27
cn
 

172.16.0.64/29
SHA

172.16.0.72/29
시아

172.16.2.0/23
등뼈
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
MSK

172.16.2.16/28
kzn

172.16.2.64/26
sp
 

172.16.2.64/28
BCN

172.16.2.80/28
MLG

172.16.2.128/26
cn
 

172.16.2.128/28
SHA

172.16.2.144/28
시아

172.16.8.0/21
잎
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
MSK

172.16.8.128/25
kzn

172.16.10.0/23
sp
 

172.16.10.0/25
BCN

172.16.10.128/25
MLG

172.16.12.0/23
cn
 

172.16.12.0/25
SHA

172.16.12.128/25
시아

밑받침:

접두사
지방
DC

10.0.0.0/17
ru
 

10.0.0.0/19
MSK

10.0.32.0/19
kzn

10.0.128.0/17
sp
 

10.0.128.0/19
BCN

10.0.160.0/19
MLG

10.1.0.0/17
cn
 

10.1.0.0/19
SHA

10.1.32.0/19
시아

라바

두 개의 공급 업체. 하나의 네트워크. ADSM.

주니퍼 + 아리스타. 우분투. 좋은 이브.

Mirana에 있는 가상 서버의 리소스 양은 여전히 ​​제한되어 있으므로 연습을 위해 최대한 단순화된 네트워크를 사용하겠습니다.

두 개의 데이터 센터: 카잔과 바르셀로나.

• 두 개의 척추가 각각 Juniper와 Arista입니다.
• 각각 하나의 토러스(리프) - Juniper 및 Arista, 하나의 연결된 호스트(이를 위해 경량 Cisco IOL을 사용하겠습니다).
• 각각 하나의 Edge-Leaf 노드(현재는 Juniper에만 해당)
• 하나의 Cisco 스위치로 모든 것을 관리할 수 있습니다.
• 네트워크 박스 외에도 가상 제어 머신이 실행됩니다. 우분투를 실행 중입니다.
  모든 장치에 액세스할 수 있으며 IPAM/DCIM 시스템, 여러 Python 스크립트, Ansible 및 기타 필요할 수 있는 모든 것을 실행합니다.

전체 구성 모든 네트워크 장치의 자동화를 사용하여 재현하려고 노력할 것입니다.

결론

그것도 받아들여지나요? 각 기사 아래에 짧은 결론을 써야 합니까?

그래서 우리는 선택했다 XNUMX단계 많은 동서 트래픽이 예상되고 ECMP가 필요하기 때문에 DC 내부에 Kloz 네트워크가 있습니다.

네트워크는 물리적(언더레이)과 가상(오버레이)으로 구분되었습니다. 동시에 오버레이는 호스트에서 시작되므로 언더레이에 대한 요구 사항이 단순화됩니다.

우리는 확장성과 정책 유연성을 위해 네트워크 네트워크의 라우팅 프로토콜로 BGP를 선택했습니다.

DCI(Edge-leaf)를 구성하기 위한 별도의 노드가 있습니다.
백본에는 OSPF+LDP가 있습니다.
DCI는 MPLS L3VPN을 기반으로 구현됩니다.
P2P 링크의 경우 장치 이름을 기반으로 알고리즘적으로 IP 주소를 계산합니다.
장치의 역할과 위치에 따라 루프백을 순차적으로 할당합니다.
언더레이 접두사 - 위치에 따라 순차적으로 리프 스위치에만 해당됩니다.

지금 당장 장비가 아직 설치되지 않았다고 가정해 보겠습니다.
따라서 다음 단계는 이를 시스템(IPAM, 인벤토리)에 추가하고, 액세스를 구성하고, 구성을 생성하고 배포하는 것입니다.

다음 기사에서는 DC의 IP 공간에 대한 인벤토리 및 관리 시스템인 Netbox를 다루겠습니다.

감사합니다

• 교정 및 수정을 담당한 @glazgoo라고도 불리는 Andrey Glazkov
• 교정 및 편집을 담당한 Alexander Klimenko(@v00lk)
• KDPV의 아르템 체르노바이

출처 : habr.com