Tweet
Kiến trúc aci
KIẾN TRÚC ACI
Application Centric Infrastructure (ACI) là giải pháp dựa trên kiến trúc SDN của Cisco cho các quá trình triển khai, quản lý và giám sát các hạ tầng mạng của các trung tâm dữ liệu. Giải pháp ACI này dựa trên hai thành phần: dòng switch Nexus và APIC Controller.
Dòng switch Nexus 9000 có thể chạy trong hai chế độ hoạt động riêng biệt, phụ thuộc vào các phần mềm nạp trên chúng. Chế độ đầu tiên gọi là chế độ chạy độc lập (standalone) hay còn gọi là chế độ NX-OS. Trong chế độ này, switch hoạt động như là một switch L2/L3 được quản lý riêng lẻ. Trong chế độ thứ hai, chế độ ACI, các switch Nexus là các thành phần của mạng trục ACI và được quản lý theo kiểu tập trung. APIC là controller của ACI fabric. Controller này là thành phần chính trong kiến trúc ACI của Cisco và cung cấp một đầu mối cho việc tự động và quản lý của ACI fabric, là nơi áp đặt các chính sách và giám sát tình trạng hệ thống. APIC được xây dựng với khái niệm API là trên hết. Trên cơ sở của các API, một giao diện dòng lệnh CLI và giao diện đồ họa GUI được phát triển. API sử dụng kiến trúc REST và được truy cập thông qua các giao tiếp northbound cho người dùng và các nhà phát triển để họ tích hợp các giải pháp của họ trên APIC và ACI fabric.
APIC tương tác và quản lý các Nexus switch thông qua giao thức OpFlex, được xem như một southbound interface. Từ góc nhìn của một controller, một northbound API là một tập hợp các giao thức mà một người dùng có thể dùng để tương tác và lập trình cho controller. Southbound interface được dùng để tương tác với thiết bị.
Một vài đặc điểm của APIC là:
Kiến trúc ACI fabric được xây dựng theo mô hình leaf-and-spine (thân và lá). Như cái tên đã mô tả, một vài switch Nexus là một phần của kiến trúc ACI được gọi là lá và thực hiện chức năng như một switch lớp truy cập. Các đầu cuối kết nối vào switch này có thể là thiết bị vật lý hoặc thiết bị ảo. Một vài thiết bị sẽ đóng vai trò như thân cây và thực hiện chức năng tương tự như distribution switch, trong đó tất cả các switch lớp truy cập sẽ kết nối vào. Hình bên dưới cho thấy một mô tả của tất cả các thành phần của kiến trúc ACI fabric.
Do không phải loại switch Nexus 9000 nào cũng hỗ trợ tất cả các chức năng của spine hay leaf, chúng ta phải nhớ một điều rất quan trọng là chọn đúng loại switch cho từng chức năng. Các switch ở leaf kết nối đến tất cả các spine switches và đến các thiết bị đầu cuối, bao gồm cả APIC controller. APIC không bao giờ kết nối đến spine switches. Spine switch chỉ có thể kết nối đến leaf switches và không bao giờ kết nối với nhau. Kiến trúc ACI cung cấp khả năng chuyển gói có độ trễ thấp trên các băng thông 40Gbps, 100 Gbps và 400Gbps. Các lưu lượng dữ liệu với cùng nguồn và đích trên cùng leaf switch được quản lý cục bộ. Khi các lưu lượng nguồn và đích trên các leaf switch riêng lẻ, nó chỉ cách nhau một spine switch. Toàn bộ kiến trúc ACI fabric hoạt động như một switch L3, vì vậy giữa nguồn và đích chỉ có cách nhau một chặng L3 (L3 hop).
Cấu hình của ACI fabric được lưu trữ bên trong APIC theo một sơ đồ hướng đối tượng. Cấu hình này tượng trưng cho mô hình luận lý. APIC sẽ diễn dịch các một hình luận lý của fabric và diễn tả các chính sách theo một mô hình cụ thể để chạy trên hạ tầng vật lý. Hình bên dưới mô tả mối quan hệ giữa mô hình luận lý, mô hình cụ thể và hệ điều hành trên từng switches.
Mỗi loại switch chứa một bảng đầy đủ của mô hình cụ thể. Khi một chính sách đại diện cho một cấu hình được tạo ra trong APIC, controller sẽ cập nhật mô hình luận lý. Sau đó nó sẽ thực thi các bước trung gian để tạo ra một chính sách đầy đủ để đẩy xuống tất cả các switches, ở đó các mô hình cụ thể sẽ được cập nhật.
Các dòng switch Nexus 9000 có thể chỉ thực thi mô hình cụ thể khi chạy trong chế độ ACI. Từng switch sẽ có một bảng sao của mô hình cụ thể. Nếu vì lý do nào đó mà các APIC controller trong một cluster không hoạt động, fabric vẫn duy trì hoạt động nhưng các thay đổi đến fabric là không thể. Chính sách ACI cho phép các đặc tả của các yêu cầu của một ứng dụng. Khi có một thay đổi được kích hoạt vào trong một đối tượng của fabric, APIC sẽ áp dụng các thay đổi vào trong mô hình chính sách. Các mô hình chính sách này kích hoạt các thay đổi đến mô hình cụ thể và các đầu cuối được quản lý. Mô hình quản lý này được gọi là quản lý hướng theo mô hình model-driven framework.
Trong mô hình này, người quản trị hệ thống định nghĩa các trạng thái mong muốn của mạng fabric nhưng để phần triển khai và hiện thực cho APIC thực hiện. Điều này có nghĩa là các hạ tầng trung tâm dữ liệu không còn quản lý đơn lẻ nữa mà là một cách nhất quán, có liên kết và hoàn toàn tự động. Trong kiểu hạ tầng mạng này, các dịch vụ mạng có thể dễ dàng được triển khai khi APIC cung cấp một cơ chế tự động để quản lý toàn bộ chu kỳ của các dịch vụ này. Khi các workload di chuyển và các thay đổi xảy ra, controller sẽ cấu hình lại các hạ tầng bên dưới để đảm bảo rằng các chính sách vẫn hoạt động đúng cho từng đầu cuối.
Kiến trúc ACI bao gồm các thành phần ảo và vật lý. Các thành phần này được lưu trữ trong các mô hình thông tin quản trị Management Information Model (MIM) và có thể được mô tả bằng một dạng cây thông tin quản trị management information tree (MIT). Từng node trong MIT sẽ được mô tả bằng một đối tượng. Một đối tượng được quản lý (managed object) có thể tượng trưng cho một switch, một adapter, một bộ cung cấp nguồn hoặc một đối tượng luận lý, chẳng hạn như một hồ sơ của một ứng dụng, một nhóm thiết bị đầu cuối, hoặc một thông điệp lỗi. Tất cả các thành phần của ACI có thể được mô tả bằng những đối tượng được quản lý.
Cấu trúc cấp bậc MIT này bắt đầu ở phần đỉnh với đối tượng root và nó chứa các nốt cha và các nốt con. Mỗi nốt trong cây này là một đối tượng được quản lý MO và mỗi đối tượng trong fabric này có một tên riêng (distinguished name – DN). DN mô tả đối tượng và xác định vị trí của nó trong cây. Các đối tượng sau chứa các chính sách điều khiển hoạt động của fabric.
APIC: đây là các controller giúp quản lý, áp dụng và triển khai các chính sách cho fabric.
Tenant: tượng trưng cho các container cho các chính sách được phân nhóm theo các vùng truy cập cụ thể. Có bốn kiểu tenant được hỗ trợ bởi hệ thống.
Người dùng user: người quản trị sẽ dùng loại user tenant để giải quyết nhu cầu quản lý người dùng fabric.
Common tenant: common tenant chứa các chính sách và các tài nguyên có thể được chia sẻ bởi tất cả các tenant. Ví dụ của các tài nguyên dạng này là các loại tường lửa, các thiết bị cân bằng tải, các hệ thống phát hiện xâm nhập.
Infra: loại infra tenant được cung cấp bởi hệ thống và có thể được cấu hình bởi người quản trị hệ thống. Loại này chứa các chính sách quản lý các hoạt động của tài nguyên hạ tầng mạng.
Quản trị: loại tenant này chứa các chính sách và các tài nguyên được dùng cho cấu hình các nốt trong fabric theo kiểu in-band và out-of-band.
Các chính sách truy cập: các chính sách này kiểm soát các hoạt động của các leaf switch access port, cung cấp kết nối đến các tài nguyên chẳng hạn như các máy ảo, các thiết bị tính toán, các thiết bị lưu trữ…Có vài chính sách truy cập được xây dựng sẵn trong ACI fabric. Người quản trị fabric có thể tối ưu các chính sách này hay tạo mới nếu cần thiết.
Fabric policies: Các chính sách này kiểm soát các hoạt động của các cổng switch fabric. Các cấu hình cho các hoạt động đồng bộ thời gian, các giao thức định tuyến và các cơ chế phân giải tên được quản lý với các chính sách này.
VM domains: Các VM domain nhóm các máy ảo có chung cấu hình cho các chính sách mạng. APIC giao tiếp với các VM Controller để đẩy các cấu hình mạng xuống đến mức máy VM.
Tích hợp các framework tự động hóa: Các kỹ thuật giúp tích hợp tự động các dịch vụ ở mức L4 đến L7 cho phép một hệ thống có thể nhanh chóng triển khai trực tuyến hay ngoại tuyến.
Các chính sách AAA: Các chính sách về truy cập, xác thực và tính cước để kiểm soát các phân quyền người dùng, các vai trò và các domain bảo mật cho ACI fabric.
Mô hình chính sách theo cấp bậc tương đồng rất tốt với REST API. Khi ACI fabric thực hiện các chức năng của nó, API sẽ đọc và viết đến các đối tượng vào cây MIT. Tài nguyên API tượng trưng bởi URL được chuyển đổi trực tiếp sang các tên DN giúp xác định các đối tượng trong cây MIT. Bước kế tiếp, chúng ta hãy khảo sát các khối chức năng của ACI fabric policy.
Application Centric Infrastructure (ACI) là giải pháp dựa trên kiến trúc SDN của Cisco cho các quá trình triển khai, quản lý và giám sát các hạ tầng mạng của các trung tâm dữ liệu. Giải pháp ACI này dựa trên hai thành phần: dòng switch Nexus và APIC Controller.
Dòng switch Nexus 9000 có thể chạy trong hai chế độ hoạt động riêng biệt, phụ thuộc vào các phần mềm nạp trên chúng. Chế độ đầu tiên gọi là chế độ chạy độc lập (standalone) hay còn gọi là chế độ NX-OS. Trong chế độ này, switch hoạt động như là một switch L2/L3 được quản lý riêng lẻ. Trong chế độ thứ hai, chế độ ACI, các switch Nexus là các thành phần của mạng trục ACI và được quản lý theo kiểu tập trung. APIC là controller của ACI fabric. Controller này là thành phần chính trong kiến trúc ACI của Cisco và cung cấp một đầu mối cho việc tự động và quản lý của ACI fabric, là nơi áp đặt các chính sách và giám sát tình trạng hệ thống. APIC được xây dựng với khái niệm API là trên hết. Trên cơ sở của các API, một giao diện dòng lệnh CLI và giao diện đồ họa GUI được phát triển. API sử dụng kiến trúc REST và được truy cập thông qua các giao tiếp northbound cho người dùng và các nhà phát triển để họ tích hợp các giải pháp của họ trên APIC và ACI fabric.
APIC tương tác và quản lý các Nexus switch thông qua giao thức OpFlex, được xem như một southbound interface. Từ góc nhìn của một controller, một northbound API là một tập hợp các giao thức mà một người dùng có thể dùng để tương tác và lập trình cho controller. Southbound interface được dùng để tương tác với thiết bị.
Một vài đặc điểm của APIC là:
- Sử dụng các chính sách mạng để hướng về các ứng dụng cho các hạ tầng vật lý, ảo hóa và các kiến trúc điện toán đám mây.
- Khai báo, cài đặt các thiết bị hoạt động theo các mô hình dữ liệu.
- Thiết kế dựa trên các chuẩn mở và các OpenAPI.
- Quản lý phần thiết bị và các cấu hình.
- Quản lý các file hệ điều hành.
- Quản lý lỗi, các sự kiện, giám sát các hiệu năng và quản lý.
- Tích hợp với các sản phẩm quản lý của bên thứ ba chẳng hạn như VMWare, Microsoft và OpenStack.
- Sản phẩm Cloud APIC cho các triển khai trên cloud.
- Để tăng tính dự phòng, một cluster cần có tối thiểu 3 APIC.
Kiến trúc ACI fabric được xây dựng theo mô hình leaf-and-spine (thân và lá). Như cái tên đã mô tả, một vài switch Nexus là một phần của kiến trúc ACI được gọi là lá và thực hiện chức năng như một switch lớp truy cập. Các đầu cuối kết nối vào switch này có thể là thiết bị vật lý hoặc thiết bị ảo. Một vài thiết bị sẽ đóng vai trò như thân cây và thực hiện chức năng tương tự như distribution switch, trong đó tất cả các switch lớp truy cập sẽ kết nối vào. Hình bên dưới cho thấy một mô tả của tất cả các thành phần của kiến trúc ACI fabric.
Do không phải loại switch Nexus 9000 nào cũng hỗ trợ tất cả các chức năng của spine hay leaf, chúng ta phải nhớ một điều rất quan trọng là chọn đúng loại switch cho từng chức năng. Các switch ở leaf kết nối đến tất cả các spine switches và đến các thiết bị đầu cuối, bao gồm cả APIC controller. APIC không bao giờ kết nối đến spine switches. Spine switch chỉ có thể kết nối đến leaf switches và không bao giờ kết nối với nhau. Kiến trúc ACI cung cấp khả năng chuyển gói có độ trễ thấp trên các băng thông 40Gbps, 100 Gbps và 400Gbps. Các lưu lượng dữ liệu với cùng nguồn và đích trên cùng leaf switch được quản lý cục bộ. Khi các lưu lượng nguồn và đích trên các leaf switch riêng lẻ, nó chỉ cách nhau một spine switch. Toàn bộ kiến trúc ACI fabric hoạt động như một switch L3, vì vậy giữa nguồn và đích chỉ có cách nhau một chặng L3 (L3 hop).
Cấu hình của ACI fabric được lưu trữ bên trong APIC theo một sơ đồ hướng đối tượng. Cấu hình này tượng trưng cho mô hình luận lý. APIC sẽ diễn dịch các một hình luận lý của fabric và diễn tả các chính sách theo một mô hình cụ thể để chạy trên hạ tầng vật lý. Hình bên dưới mô tả mối quan hệ giữa mô hình luận lý, mô hình cụ thể và hệ điều hành trên từng switches.
Mỗi loại switch chứa một bảng đầy đủ của mô hình cụ thể. Khi một chính sách đại diện cho một cấu hình được tạo ra trong APIC, controller sẽ cập nhật mô hình luận lý. Sau đó nó sẽ thực thi các bước trung gian để tạo ra một chính sách đầy đủ để đẩy xuống tất cả các switches, ở đó các mô hình cụ thể sẽ được cập nhật.
Các dòng switch Nexus 9000 có thể chỉ thực thi mô hình cụ thể khi chạy trong chế độ ACI. Từng switch sẽ có một bảng sao của mô hình cụ thể. Nếu vì lý do nào đó mà các APIC controller trong một cluster không hoạt động, fabric vẫn duy trì hoạt động nhưng các thay đổi đến fabric là không thể. Chính sách ACI cho phép các đặc tả của các yêu cầu của một ứng dụng. Khi có một thay đổi được kích hoạt vào trong một đối tượng của fabric, APIC sẽ áp dụng các thay đổi vào trong mô hình chính sách. Các mô hình chính sách này kích hoạt các thay đổi đến mô hình cụ thể và các đầu cuối được quản lý. Mô hình quản lý này được gọi là quản lý hướng theo mô hình model-driven framework.
Trong mô hình này, người quản trị hệ thống định nghĩa các trạng thái mong muốn của mạng fabric nhưng để phần triển khai và hiện thực cho APIC thực hiện. Điều này có nghĩa là các hạ tầng trung tâm dữ liệu không còn quản lý đơn lẻ nữa mà là một cách nhất quán, có liên kết và hoàn toàn tự động. Trong kiểu hạ tầng mạng này, các dịch vụ mạng có thể dễ dàng được triển khai khi APIC cung cấp một cơ chế tự động để quản lý toàn bộ chu kỳ của các dịch vụ này. Khi các workload di chuyển và các thay đổi xảy ra, controller sẽ cấu hình lại các hạ tầng bên dưới để đảm bảo rằng các chính sách vẫn hoạt động đúng cho từng đầu cuối.
Kiến trúc ACI bao gồm các thành phần ảo và vật lý. Các thành phần này được lưu trữ trong các mô hình thông tin quản trị Management Information Model (MIM) và có thể được mô tả bằng một dạng cây thông tin quản trị management information tree (MIT). Từng node trong MIT sẽ được mô tả bằng một đối tượng. Một đối tượng được quản lý (managed object) có thể tượng trưng cho một switch, một adapter, một bộ cung cấp nguồn hoặc một đối tượng luận lý, chẳng hạn như một hồ sơ của một ứng dụng, một nhóm thiết bị đầu cuối, hoặc một thông điệp lỗi. Tất cả các thành phần của ACI có thể được mô tả bằng những đối tượng được quản lý.
Cấu trúc cấp bậc MIT này bắt đầu ở phần đỉnh với đối tượng root và nó chứa các nốt cha và các nốt con. Mỗi nốt trong cây này là một đối tượng được quản lý MO và mỗi đối tượng trong fabric này có một tên riêng (distinguished name – DN). DN mô tả đối tượng và xác định vị trí của nó trong cây. Các đối tượng sau chứa các chính sách điều khiển hoạt động của fabric.
APIC: đây là các controller giúp quản lý, áp dụng và triển khai các chính sách cho fabric.
Tenant: tượng trưng cho các container cho các chính sách được phân nhóm theo các vùng truy cập cụ thể. Có bốn kiểu tenant được hỗ trợ bởi hệ thống.
Người dùng user: người quản trị sẽ dùng loại user tenant để giải quyết nhu cầu quản lý người dùng fabric.
Common tenant: common tenant chứa các chính sách và các tài nguyên có thể được chia sẻ bởi tất cả các tenant. Ví dụ của các tài nguyên dạng này là các loại tường lửa, các thiết bị cân bằng tải, các hệ thống phát hiện xâm nhập.
Infra: loại infra tenant được cung cấp bởi hệ thống và có thể được cấu hình bởi người quản trị hệ thống. Loại này chứa các chính sách quản lý các hoạt động của tài nguyên hạ tầng mạng.
Quản trị: loại tenant này chứa các chính sách và các tài nguyên được dùng cho cấu hình các nốt trong fabric theo kiểu in-band và out-of-band.
Các chính sách truy cập: các chính sách này kiểm soát các hoạt động của các leaf switch access port, cung cấp kết nối đến các tài nguyên chẳng hạn như các máy ảo, các thiết bị tính toán, các thiết bị lưu trữ…Có vài chính sách truy cập được xây dựng sẵn trong ACI fabric. Người quản trị fabric có thể tối ưu các chính sách này hay tạo mới nếu cần thiết.
Fabric policies: Các chính sách này kiểm soát các hoạt động của các cổng switch fabric. Các cấu hình cho các hoạt động đồng bộ thời gian, các giao thức định tuyến và các cơ chế phân giải tên được quản lý với các chính sách này.
VM domains: Các VM domain nhóm các máy ảo có chung cấu hình cho các chính sách mạng. APIC giao tiếp với các VM Controller để đẩy các cấu hình mạng xuống đến mức máy VM.
Tích hợp các framework tự động hóa: Các kỹ thuật giúp tích hợp tự động các dịch vụ ở mức L4 đến L7 cho phép một hệ thống có thể nhanh chóng triển khai trực tuyến hay ngoại tuyến.
Các chính sách AAA: Các chính sách về truy cập, xác thực và tính cước để kiểm soát các phân quyền người dùng, các vai trò và các domain bảo mật cho ACI fabric.
Mô hình chính sách theo cấp bậc tương đồng rất tốt với REST API. Khi ACI fabric thực hiện các chức năng của nó, API sẽ đọc và viết đến các đối tượng vào cây MIT. Tài nguyên API tượng trưng bởi URL được chuyển đổi trực tiếp sang các tên DN giúp xác định các đối tượng trong cây MIT. Bước kế tiếp, chúng ta hãy khảo sát các khối chức năng của ACI fabric policy.