본 내용은 작성자의 개인적인 정리사항으로 100퍼센트 확실하지 않은 내용으로 구성되어 있습니다. 불명확한 정보가 가득하오니 단순 이해에만 참고를 하되 자세한 사항은 공식적인 문서를 참조해주세요.
0. ACI? SDN?
ACI(Application Centric Infrastructure)란 단어 그대로
어플리케이션 중심의 인프라입니다. 이것이 일반적으로 이야기하는 SDN(Software Defined Network)과 어떠한 차이가 존재하는 지에 대해서 개념을 정리해보겠습니다.
Network Device 내에서 발생하는 Process를 기능별로 구분하여 Plane 단위로 표현할 수 있는데, 각각 Control Plane, Data Plane, Management Plane입니다.
기존의 물리적인 Switch에서는 해당 Plane들이 모두 한 기기에 위치해있는 형태입니다.
Routing Table에 대한 생성과 제어와 같은 데이터의 방향성을 결정짓는 정책에 대한 설정은 Control Plane에서 이루어지고, 각각의 데이터들은 Data Plane에서 실제 이동이 이루어진다고 생각할 수 있습니다. 이 때 이러한 관리자는 CLI나 GUI를 통해서 해당 설정을 시행할 수 있는데 이를 Management Plane이라고 여길 수 있습니다.
이러한 형태는 단일 스위치 내에서의 데이터 흐름 제어에 있어서는 아무런 문제도 발생하지 않습니다. 다만 문제는 시대의 흐름에 따른 네트워크 구성도의 확장에 있습니다.
이제 네트워크 흐름 제어는 단일 기기에서의 처리과정이 주요한 쟁점이 아닙니다. 정확하게는 하드웨어의 발전에 따라 단일 기기에서의 처리과정은 계속해서 발전이 이루어지고 있으니 처리과정, 즉 네트워크 프로세스 전체에 대해 최적화가 필요하게 된 것입니다.
당연하게도 스위치 제조사별 내부 프로세스는 상이할 수밖에 없습니다. 일관된 네트워크 흐름 구성을 위해선 각 기기별 세부사항에 대해 조정을 시행하던지, 혹은 스위치의 제조사를 통일해야만 하는 사항이 발생하기 마련이었습니다.
또한, 네트워크 구성에 따른 특정 계층에 과도한 데이터 처리 사항이 발생하기도, 특정 부분에 데이터 처리양에 비해 잉여 자원이 발생하기도 하였습니다.
이러한 제조사 종속적인 물리적인 디바이스의 한계를 탈피하고자 하는 사용자 중심의 요구사항과 대용량 네트워크 처리의 자원 사용 최적화에 대한 관리자의 요구사항이 계속해서 발생했습니다.
이것을 해결하기 위해선 물리적인 디바이스가 지닌 자원들을 가상화할 필요가 있습니다. 또한 가상화된 자원들을 소프트웨어를 통해서 관리의 용이성을 확보할 필요도 있었지요.
그렇게 제안된 형태가 바로 Software Defined Network입니다.
SDN은 스위치 개개의 Management Plane과 Control Plane을 일원화 함으로써 중앙 집중적인 관리와 조정이 가능한 네트워크 구성입니다. 각 스위치들이 네트워크로 연결이 되어있다면 각 스위치들이 구성하는 네트워크를 통합하여 마치 거대한 하나의 스위치처럼 동작하게 되는 것입니다.
이 때 각 스위치들의 통신을 위한 네트워크 구성을 Underlay Network, 해당 스위치를 통해서 각 단말들의 통신이 이루어지는 네트워크 구성을 Overlay Network라고 칭합니다.
다만 해당 구성은 필연적으로 컨트롤러가 중심이 되는 네트워크입니다. 따라서 컨트롤러, 혹은 그와 연결되는 네트워크가 다운된다면 SDN 전체나 일부에 기능적 이상을 발생시킬 수 있습니다. 또한 데이터의 흐름을 컨트롤러가 모두 제어하고 있기 때문에 네트워크의 확장에 따라 컨트롤러가 부담해야하는 처리양은 증가할 수 밖에 없습니다.
이러한 문제에 대응하기 위해 Cisco에서 제시한 네트워크 구성이 바로 Application Centric Infrastructure입니다.
ACI는 데이터의 흐름을 제어하는 Control Plane이 컨트롤러가 아닌 각 물리적 디바이스에 존재하는 형태입니다. 컨트롤러가 직접 통신 데이터에 대해 그 흐름을 제어하는 형태가 아닌, 제어를 위한 '네트워크 정책'에 대해 배포와 관리를 시행하는 것이지요.
각 스위치에서 통신되는 네트워크 흐름에 대한 정책 설정을 컨트롤러가 시행하되, 실질적으로 발생하는 데이터의 흐름인 트래픽은 각 스위치에서 자체적으로 시행합니다. 따라서 네트워크의 확장이 이루어지더라도 컨트롤러에 가해지는 부하가 거의 없습니다. 확장의 용이성과 대규모 네트워크 구성에 유리함을 지닌다고 설명할 수 있겠습니다.
다만, 해당 구성은 Cisco의 독자 기술이기에 제조사 종속적인 문제가 여전히 존재합니다. Cisco에서 ACI가 적용 가능한 일부 하드웨어 모델(ex:Nexus 9000 Series)에서만 구성이 가능하다는 조건이 충족 되어야 하며, 추가적으로 소프트웨어 상에 이상이 발생하였을 경우 능동적으로 대처하기 어렵다는 문제가 여전히 존재합니다.
1. Fabric
1-1.APIC?
그렇다면 ACI에서의 네트워크 구성은 기존의 네트워크 구성과 동일한 것일까요? 우선적으로 ACI는 Legacy 네트워크의 Core-Distribution-Access로 이루어져있는 3-Tier Network 구성과 다르게, Leaf-Spine으로 2-Tier Network 구성을 이루고 있습니다.
다만, 이는 절대적인 구성 조건이 아니므로 3-Tier 또한 지원한다는 사실을 먼저 말씀드릴 수 있겠습니다.
2-Tier Network 구성의 이점은 무엇일까요? 먼저 STP가 동작하지 않는 네트워크 형태이므로 Blocking Port가 발생하지 않는다는 점이 우선적인 이점일 수 있습니다. 이 외에도 Spine(혹은 Leaf) 스위치의 추가, 제거가 손쉬워 인프라 구성의 변화에 대응하기 용이하다는 점 등을 들 수 있겠습니다.
기본적으로 2-Tier 네트워크로 구성된 ACI는 APIC(Application Policy Infrastructure Controller)를 통하여 정책의 구성 및 관리를 시행합니다.
APIC은 그 이름에서 알 수 있다시피 Policy Controller로서 Control Plane의 역할을 직접 수행하지 않으며 ACI 정책 설정, ACI 내의 장애와 이벤트와 성능 관리, 인벤토리 구성 및 관리, 서드파티 어플리케이션 연결, API를 통한 정보 제공 등의 역할을 수행합니다.
이 때 APIC의 Fabric Membership의 등록은 Manual하게 이루어지지 않으며, LLDP를 통해 APIC와 연결된 Leaf-Spine Switch를 통해 Spine-Leaf Switch 감지 및 등록이 자동으로 이루어집니다.
1-2. 그래서 Fabric이 뭔데?
Fabric이란 쉽게 설명하여서 SDN의 Big Switch와 동일한 개념의 ACI 용어입니다. Spine-Leaf로 이루어진 네트워크가 APIC를 통해서 관리가 이루어지는 것이 ACI라면, ACI를 통해 하나의 거대한 스위치처럼 동작하는 네트워크를 바로 Fabric이라고 칭하는 것이지요.
Fabric은 앞서 설명드린 2-Tier 구조의 LEAF-Switch와 SPINE-Switch로 구성됩니다. Fabric을 구성하기위한 기본 전제조건은 다음과 같습니다.
- SPINE-LEAF 간 Full-Mesh 관계를 구성한다.
- APIC는 Cluster로 구성한다.
- LEAF, SPINE Switch 각각에 모두 Node-ID를 부여한다.
또한, '올바른 Fabric'을 구성하기 위한 전제조건 또한 각각의 계층에도 존재합니다.
SPINE
- SPINE-to-SPINE Inter Link를 생성하지 않는다.
- SPINE Switch에 L4-L7 서버를 직접 연결하지 않는다.
SPINE Switch들은 물리적으로는 분리되어 있어도 논리적으로는 하나의 장비로 동작합니다. 또한, 이름 그대로 LEAF Switch의 Back Plain 역할을 수행합니다.
LEAF
- LEAF-to-LEAF Inter Link를 생성하지 않는다.
- 모든 서비스(외부 포함)는 LEAF Switch를 통해서만 연결돼야 한다.
LEAF Switch 마찬가지로 물리적으로는 분리되어 있어도 논리적으로는 하나의 장비로 동작합니다. 필요에 따라 SPINE Switch와의 Link를 (Virtual)Port Channel을 이용하여 이중화 구성할 수 있습니다.
APIC
- 3대의 물리적인 서버를 1개의 Cluster로 구성한다.(5, 7대의 서버도 구성 가능하나, 4,6의 경우 권장하지 않는다.)
이는 APIC의 DB가 'Sharding'을 통하여 3벌 단위로 복제가 이루어지기 때문입니다. APIC의 정책은 프로파일로 설정되어 DB로 저장되며, Cluster를 이루는 각 APIC끼리 서로 동기화함으로써 Failover 기능을 제공한다고 볼 수 있습니다.
따라서 기초적인 ACI의 Fabric 구성은 다음과 같이 이루진다고 볼 수 있습니다.
내부의 서비스는 Compute Leaf에, 외부로 향하는 서비스는 Border Leaf에 구성하여 분리시킴으로써 정책의 관리 용이성을 확보할 수 있습니다.
1-3. Protocol on Fabric
Fabric은 여러 종류의 Protocol이 동작하며 마치 하나의 스위치처럼 작동합니다. Fabric 내에서 동작하는 Protocol은 다음과 같습니다.
각각의 Protocol에 대해선 이후 다른 페이지를 통해 설명 드리도록 하겠습니다.
1-4. Policy?
자, 이제 우리는 ACI는 하나의 Fabric 단위로 구성이 이루어지며, 해당 Fabric은 APIC에 의해 정책 관리가 이루어진다는 사실을 알 수 있습니다. 그렇다면 'APIC에 의해 이루어지는 정책 관리'란 무엇일까요? Policy와 Profile 입니다. 잘 구성된 ACI Fabric과 Tenant 논리적인 구성도의 예시입니다.
해당 이미지는 직접 제작한 것이 아니므로 삭제 및 수정이 이루어질 수 있습니다.논리적인 흐름을 우선 설명하자면, 각 Domain은 AEP(Attachable Entity Profile)를 통해 그룹화 및 관리가 이루어지는 것을 확인할 수 있습니다 이 때 AEP는 Interface Policy Group을 통하여 정책이 적용되며, 해당 정책은 Interface와 Switch의 Profile을 통해 설정되는 것을 확인할 수 있습니다.
해당 이미지는 직접 제작한 것이 아니므로 삭제 및 수정이 이루어질 수 있습니다.정책을 통해 관리가 이루어지는 상세한 논리적 흐름도는 위와 같습니다. 정책의 설정 및 적용은 위에서 아래로 단방향으로 이루어지는 것이 아닌, 상호 연결되어 동시 적용되는 것이므로 수직 방향의 화살표는 중요하지 않습니다.
각 정책, 프로필, 그룹의 생성 및 관리에 대해서는 이후 다른 페이지를 통해서 설명드리도록 하겠습니다.
결론
'Fabric'이란 APIC를 통해 정책단위로 관리가 이루어지는 ACI의 내부 네트워크를 일컫는 말이라 설명드릴 수 있겠습니다. 그렇다면 논리적인 흐름 제어인 Fabric이 물리적인 스위치에 어떻게 적용되는 것일까요?
Tenant에 대해서 다음 페이지를 통해서 설명드리도록 하겠습니다.
Good~