클라우드 네이티브를 위한 데이터 센터 네트워크 구축: 데이터 센터 네트워킹을 위한 아키텍처, 프로토콜, 도구

179

6

장

네트워크 가상화

위치가 이 정보를 한 리프에서 다른 리프로 전달하기 때문이다. 이는 제어 프로토콜에 추가 부담

을 주지만 일반적으로 주요 제한 요인은 아니다.

이러한 제한 외에도 제어 프로토콜의 구현이나 소프트웨어 상태를 하드웨어와 동기화하는 등의

소프트웨어 규모 문제도 존재한다. 여기서 공급 업체에 검증을 요구하거나 지원 가능 한계를 물

어보는 것이 중요하다.

6.7.4

배치 모델

네트워크 배치가 모든 가상 네트워크와 관련된 정보를 엔드포인트로 몰아놓고, 첫 번째 홉 라우

터조차 가상 네트워킹을 다루지 않는다면 제어 평면의 확장성이 가상 네트워크 수 제한을 관장

하는 유일한 요인이 된다. 물론 터널 헤더의 가상 네트워크

ID

의 크기가 여전히 상한이 된다.

자동화도 배치할 수 있는 가상 네트워크 수를 바꿀 수 있다. 필자가 아는 고객 중에 오버레이 모

델을 사용하지 않지만 네트워크 자동화의 도움으로

128

개의 인라인 가상 네트워크를 운영하는

경우도 있다.

iBGP

를 사용하면 네트워크 내에

iBGP

경로 리플렉터

route

reflector

를 코어 라우터 대신 서버에서

사용한다면 한계를 상향 조정할 수 있다.

소프트웨어나 하드웨어 제한과 관련이 없는 또 다른 중요한 요인은 촘촘한 장애 도메인이다. 성

공적인 퍼블릭 클라우드 사업자들은 장애 도메인을 가능한 한 제한하길 원한다. 장애가 발생하

면 어떤 가상 네트워크가 영향을 받는지 쉽게 식별하고 싶어 한다. 따라서 실제 생각보다 많은

가상 네트워크를 배치하지 않는다.

필자가 경험한 모던 데이터 ...