Điện toán đám mây đang ngày càng thâm nhập sâu hơn vào cuộc sống của chúng ta và có lẽ không một người nào lại chưa từng sử dụng bất kỳ dịch vụ đám mây nào ít nhất một lần. Tuy nhiên, đám mây chính xác là gì và hoạt động như thế nào thì ít người biết, ngay cả ở mức độ ý tưởng. 5G đã trở thành hiện thực và cơ sở hạ tầng viễn thông đang bắt đầu chuyển từ giải pháp cực sang giải pháp đám mây, giống như khi chuyển từ giải pháp phần cứng hoàn chỉnh sang “trụ cột” ảo hóa.
Hôm nay chúng ta sẽ nói về thế giới bên trong của cơ sở hạ tầng đám mây, đặc biệt chúng ta sẽ xem xét những kiến thức cơ bản về phần mạng.
Một đám mây là gì? Ảo hóa giống nhau - xem hồ sơ?
Hơn cả một câu hỏi logic. Không - đây không phải là ảo hóa, mặc dù không thể thực hiện được nếu không có nó. Chúng ta hãy xem xét hai định nghĩa:
Điện toán đám mây (sau đây gọi tắt là Đám mây) là mô hình cung cấp quyền truy cập thân thiện với người dùng vào các tài nguyên điện toán phân tán phải được triển khai và khởi chạy theo yêu cầu với độ trễ thấp nhất có thể và chi phí tối thiểu cho nhà cung cấp dịch vụ.
Ảo hóa - đây là khả năng chia một thực thể vật lý (ví dụ: máy chủ) thành nhiều thực thể ảo, do đó tăng mức sử dụng tài nguyên (ví dụ: bạn có 3 máy chủ được tải với tốc độ 25-30 phần trăm, sau khi ảo hóa, bạn sẽ tải được 1 máy chủ ở mức 80-90%). Đương nhiên, ảo hóa sẽ tiêu tốn một số tài nguyên - bạn cần phải cung cấp cho bộ điều khiển ảo hóa, tuy nhiên, như thực tế đã chỉ ra, trò chơi này rất đáng giá. Một ví dụ lý tưởng về ảo hóa là VMWare, công cụ chuẩn bị hoàn hảo cho các máy ảo, hoặc ví dụ như KVM, loại mà tôi thích hơn, nhưng đây chỉ là vấn đề sở thích.
Chúng tôi sử dụng ảo hóa mà không nhận ra và ngay cả các bộ định tuyến sắt cũng đã sử dụng ảo hóa - ví dụ: trong phiên bản JunOS mới nhất, hệ điều hành được cài đặt dưới dạng máy ảo trên bản phân phối Linux thời gian thực (Wind River 9). Nhưng ảo hóa không phải là đám mây, nhưng đám mây không thể tồn tại nếu không ảo hóa.
Ảo hóa là một trong những khối xây dựng trên đó đám mây được xây dựng.
Tạo một đám mây bằng cách đơn giản là thu thập một số trình ảo hóa vào một miền L2, thêm một số sách hướng dẫn yaml để tự động đăng ký vlan thông qua một số loại Ansible và đặt thứ gì đó giống như hệ thống điều phối lên trên nó để tự động tạo máy ảo sẽ không hoạt động. Nó sẽ chính xác hơn, nhưng Frankenstein tạo ra không phải là đám mây mà chúng ta cần, mặc dù nó có thể là giấc mơ cuối cùng của những người khác. Hơn nữa, nếu bạn lấy cùng một Openstack, thì về cơ bản nó vẫn là Frankenstein, nhưng ồ, tạm thời đừng nói về điều đó.
Nhưng tôi hiểu rằng từ định nghĩa được trình bày ở trên thì không hoàn toàn rõ ràng cái gì thực sự có thể được gọi là đám mây.
Do đó, một tài liệu từ NIST (Viện Tiêu chuẩn và Công nghệ Quốc gia) cung cấp 5 đặc điểm chính mà cơ sở hạ tầng đám mây nên có:
Cung cấp dịch vụ theo yêu cầu. Người dùng phải được cấp quyền truy cập miễn phí vào các tài nguyên máy tính được phân bổ cho mình (chẳng hạn như mạng, đĩa ảo, bộ nhớ, lõi xử lý, v.v.) và các tài nguyên này phải được cung cấp tự động - nghĩa là không có sự can thiệp từ nhà cung cấp dịch vụ.
Sự sẵn có rộng rãi của dịch vụ. Quyền truy cập vào các tài nguyên phải được cung cấp bởi các cơ chế tiêu chuẩn để cho phép sử dụng cả PC tiêu chuẩn, máy khách mỏng và thiết bị di động.
Kết hợp các nguồn lực vào các nhóm. Nhóm tài nguyên phải có khả năng cung cấp tài nguyên cho nhiều khách hàng cùng một lúc, đảm bảo rằng khách hàng bị cô lập và không bị ảnh hưởng lẫn nhau cũng như không bị cạnh tranh về tài nguyên. Các mạng cũng được bao gồm trong nhóm, điều này cho thấy khả năng sử dụng địa chỉ chồng chéo. Các nhóm phải có khả năng mở rộng quy mô theo yêu cầu. Việc sử dụng các nhóm có thể cung cấp mức độ cần thiết về khả năng chịu lỗi tài nguyên và tính trừu tượng của tài nguyên vật lý và ảo - người nhận dịch vụ chỉ được cung cấp tập hợp tài nguyên mà họ yêu cầu (nơi các tài nguyên này nằm trên thực tế, trên bao nhiêu tài nguyên). máy chủ và thiết bị chuyển mạch - nó không quan trọng đối với máy khách). Tuy nhiên, chúng ta phải tính đến thực tế là nhà cung cấp phải đảm bảo việc đặt trước minh bạch các tài nguyên này.
Thích ứng nhanh với các điều kiện khác nhau. Các dịch vụ phải linh hoạt - cung cấp tài nguyên nhanh chóng, phân phối lại chúng, thêm hoặc giảm tài nguyên theo yêu cầu của khách hàng và về phía khách hàng, khách hàng phải có cảm giác rằng tài nguyên đám mây là vô tận. Ví dụ: để dễ hiểu, bạn không thấy cảnh báo rằng một phần dung lượng ổ đĩa của bạn trong Apple iCloud đã biến mất do ổ cứng trên máy chủ bị hỏng và các ổ đĩa cũng bị hỏng. Ngoài ra, về phía bạn, khả năng của dịch vụ này gần như là vô hạn - bạn cần 2 TB - không vấn đề gì, bạn đã thanh toán và nhận được nó. Một ví dụ tương tự có thể được đưa ra với Google.Drive hoặc Yandex.Disk.
Khả năng đo lường dịch vụ được cung cấp. Hệ thống đám mây phải tự động kiểm soát và tối ưu hóa các tài nguyên được tiêu thụ và các cơ chế này phải minh bạch đối với cả người dùng và nhà cung cấp dịch vụ. Nghĩa là, bạn luôn có thể kiểm tra xem bạn và khách hàng của bạn đang tiêu thụ bao nhiêu tài nguyên.
Cần xem xét thực tế rằng những yêu cầu này hầu hết là yêu cầu đối với đám mây công cộng, vì vậy đối với đám mây riêng (nghĩa là đám mây được đưa ra cho nhu cầu nội bộ của công ty), những yêu cầu này có thể được điều chỉnh một chút. Tuy nhiên, chúng vẫn phải được thực hiện, nếu không chúng ta sẽ không nhận được hết lợi ích của điện toán đám mây.
Tại sao chúng ta cần một đám mây?
Tuy nhiên, bất kỳ công nghệ mới hoặc hiện có nào, bất kỳ giao thức mới nào đều được tạo ra cho một mục đích nào đó (tất nhiên là ngoại trừ RIP-ng). Không ai cần một giao thức chỉ vì một giao thức (tất nhiên là ngoại trừ RIP-ng). Điều hợp lý là Đám mây được tạo ra để cung cấp một số loại dịch vụ cho người dùng/khách hàng. Tất cả chúng ta đều quen thuộc với ít nhất một số dịch vụ đám mây, chẳng hạn như Dropbox hoặc Google.Docs và tôi tin rằng hầu hết mọi người đều sử dụng chúng thành công - ví dụ: bài viết này được viết bằng dịch vụ đám mây Google.Docs. Nhưng các dịch vụ đám mây mà chúng ta biết chỉ là một phần khả năng của đám mây—chính xác hơn, chúng chỉ là một dịch vụ kiểu SaaS. Chúng tôi có thể cung cấp dịch vụ đám mây theo ba cách: dưới dạng SaaS, PaaS hoặc IaaS. Dịch vụ nào bạn cần phụ thuộc vào mong muốn và khả năng của bạn.
Chúng ta hãy xem xét từng thứ tự:
Phần mềm như một Dịch vụ (SaaS) là mô hình cung cấp dịch vụ chính thức cho khách hàng, chẳng hạn như dịch vụ email như Yandex.Mail hoặc Gmail. Trong mô hình cung cấp dịch vụ này, bạn, với tư cách là khách hàng, thực sự không làm gì ngoại trừ việc sử dụng dịch vụ - nghĩa là bạn không cần phải suy nghĩ về việc thiết lập dịch vụ, khả năng chịu lỗi hoặc tính dự phòng của dịch vụ đó. Điều chính là không làm lộ mật khẩu của bạn, nhà cung cấp dịch vụ này sẽ làm phần còn lại cho bạn. Từ quan điểm của nhà cung cấp dịch vụ, anh ta chịu trách nhiệm hoàn toàn về toàn bộ dịch vụ - từ phần cứng máy chủ và hệ điều hành máy chủ đến cài đặt cơ sở dữ liệu và phần mềm.
Nền tảng là một Dịch vụ (PaaS) — khi sử dụng mô hình này, nhà cung cấp dịch vụ cung cấp cho khách hàng một phôi cho dịch vụ, ví dụ: hãy lấy một máy chủ Web. Nhà cung cấp dịch vụ đã cung cấp cho khách hàng một máy chủ ảo (trên thực tế là một tập hợp tài nguyên, chẳng hạn như RAM/CPU/Storage/Nets, v.v.) và thậm chí còn cài đặt HĐH và phần mềm cần thiết trên máy chủ này, tuy nhiên, cấu hình của tất cả những công việc này đều do chính khách hàng thực hiện và khách hàng sẽ trả lời về việc thực hiện dịch vụ. Nhà cung cấp dịch vụ, như trong trường hợp trước, chịu trách nhiệm về hiệu suất của thiết bị vật lý, bộ ảo hóa, bản thân máy ảo, tính khả dụng của mạng, v.v., nhưng bản thân dịch vụ không còn nằm trong phạm vi trách nhiệm của họ.
Cơ sở hạ tầng như một dịch vụ (IaaS) - trên thực tế, cách tiếp cận này đã thú vị hơn, nhà cung cấp dịch vụ cung cấp cho khách hàng một cơ sở hạ tầng ảo hóa hoàn chỉnh - nghĩa là, một số bộ (nhóm) tài nguyên, chẳng hạn như lõi CPU, RAM, Mạng, v.v. khách hàng - khách hàng muốn làm gì với những tài nguyên này trong nhóm được phân bổ (hạn ngạch) - điều đó không đặc biệt quan trọng đối với nhà cung cấp. Cho dù khách hàng muốn tạo vEPC của riêng mình hay thậm chí tạo một nhà điều hành nhỏ và cung cấp các dịch vụ liên lạc - không cần thắc mắc - hãy làm điều đó. Trong trường hợp như vậy, nhà cung cấp dịch vụ chịu trách nhiệm cung cấp tài nguyên, khả năng chịu lỗi và tính khả dụng của chúng, cũng như hệ điều hành cho phép họ tập hợp các tài nguyên này và cung cấp chúng cho khách hàng với khả năng tăng hoặc giảm tài nguyên bất kỳ lúc nào. theo yêu cầu của khách hàng. Máy khách tự định cấu hình tất cả các máy ảo và các thiết bị kim tuyến khác thông qua cổng và bảng điều khiển tự phục vụ, bao gồm cả việc thiết lập mạng (ngoại trừ các mạng bên ngoài).
OpenStack là gì?
Trong cả ba tùy chọn, nhà cung cấp dịch vụ đều cần một hệ điều hành cho phép tạo cơ sở hạ tầng đám mây. Trên thực tế, với SaaS, nhiều bộ phận chịu trách nhiệm về toàn bộ nhóm công nghệ - có một bộ phận chịu trách nhiệm về cơ sở hạ tầng - nghĩa là nó cung cấp IaaS cho một bộ phận khác, bộ phận này cung cấp SaaS cho khách hàng. OpenStack là một trong những hệ điều hành đám mây cho phép bạn thu thập một loạt các thiết bị chuyển mạch, máy chủ và hệ thống lưu trữ vào một nhóm tài nguyên duy nhất, chia nhóm chung này thành các nhóm con (đối tượng thuê) và cung cấp các tài nguyên này cho khách hàng qua mạng.
OpenStack là một hệ điều hành đám mây cho phép bạn kiểm soát các nhóm tài nguyên máy tính lớn, lưu trữ dữ liệu và tài nguyên mạng, được cung cấp và quản lý thông qua API bằng các cơ chế xác thực tiêu chuẩn.
Nói cách khác, đây là một tập hợp các dự án phần mềm miễn phí được thiết kế để tạo ra các dịch vụ đám mây (cả công cộng và riêng tư) - tức là một bộ công cụ cho phép bạn kết hợp máy chủ và thiết bị chuyển mạch thành một nhóm tài nguyên duy nhất, quản lý những tài nguyên này, cung cấp mức độ chịu lỗi cần thiết.
Tại thời điểm viết tài liệu này, cấu trúc OpenStack trông như thế này:
Hình ảnh được chụp từ
Mỗi thành phần có trong OpenStack thực hiện một chức năng cụ thể. Kiến trúc phân tán này cho phép bạn đưa vào giải pháp tập hợp các thành phần chức năng mà bạn cần. Tuy nhiên, một số thành phần là thành phần gốc và việc loại bỏ chúng sẽ dẫn đến sự không hoạt động hoàn toàn hoặc một phần của toàn bộ giải pháp. Các thành phần này thường được phân loại là:
- Bảng Điều Khiển (Dashboard) — GUI dựa trên web để quản lý các dịch vụ OpenStack
- Đá xây cửa là một dịch vụ nhận dạng tập trung cung cấp chức năng xác thực và ủy quyền cho các dịch vụ khác, cũng như quản lý thông tin xác thực của người dùng và vai trò của họ.
- neutron - dịch vụ mạng cung cấp khả năng kết nối giữa các giao diện của các dịch vụ OpenStack khác nhau (bao gồm kết nối giữa các máy ảo và quyền truy cập của chúng với thế giới bên ngoài)
- Chất kết dính — cung cấp quyền truy cập vào khối lưu trữ cho máy ảo
- Tân tinh - quản lý vòng đời của máy ảo
- Liếc nhìn - kho lưu trữ hình ảnh và ảnh chụp nhanh của máy ảo
- Nhanh - cung cấp quyền truy cập vào đối tượng lưu trữ
- Máy đo trần nhà — một dịch vụ cung cấp khả năng thu thập dữ liệu từ xa và đo lường các tài nguyên sẵn có và tiêu thụ
- Nhiệt - phối hợp dựa trên các mẫu để tự động tạo và cung cấp tài nguyên
Một danh sách đầy đủ của tất cả các dự án và mục đích của chúng có thể được xem .
Mỗi thành phần OpenStack là một dịch vụ thực hiện một chức năng cụ thể và cung cấp API để quản lý chức năng đó và tương tác với các dịch vụ hệ điều hành đám mây khác để tạo ra một cơ sở hạ tầng thống nhất. Ví dụ: Nova cung cấp tính năng quản lý tài nguyên máy tính và API để truy cập vào việc định cấu hình các tài nguyên này, Glance cung cấp quản lý hình ảnh và API để quản lý chúng, Cinder cung cấp bộ lưu trữ khối và API để quản lý nó, v.v. Tất cả các chức năng được kết nối với nhau một cách rất chặt chẽ.
Tuy nhiên, nếu bạn nhìn vào nó, tất cả các dịch vụ chạy trong OpenStack cuối cùng đều là một loại máy ảo (hoặc vùng chứa) nào đó được kết nối với mạng. Câu hỏi đặt ra - tại sao chúng ta cần nhiều yếu tố như vậy?
Chúng ta hãy xem qua thuật toán tạo một máy ảo và kết nối nó với mạng và bộ lưu trữ liên tục trong Openstack.
- Khi bạn tạo yêu cầu tạo máy, có thể là yêu cầu thông qua Horizon (Trang tổng quan) hoặc yêu cầu thông qua CLI, điều đầu tiên xảy ra là ủy quyền yêu cầu của bạn trên Keystone - bạn có thể tạo máy không, nó có quyền sử dụng mạng này, hạn ngạch dự thảo của bạn, v.v.
- Keystone xác thực yêu cầu của bạn và tạo mã thông báo xác thực trong thông báo phản hồi, mã thông báo này sẽ được sử dụng thêm. Sau khi nhận được phản hồi từ Keystone, yêu cầu sẽ được gửi tới Nova (nova api).
- Nova-api kiểm tra tính hợp lệ của yêu cầu của bạn bằng cách liên hệ với Keystone bằng mã thông báo xác thực được tạo trước đó
- Keystone thực hiện xác thực và cung cấp thông tin về các quyền cũng như hạn chế dựa trên mã thông báo xác thực này.
- Nova-api tạo một mục nhập cho máy ảo mới trong cơ sở dữ liệu nova và chuyển yêu cầu tạo máy tới bộ lập lịch nova.
- Bộ lập lịch Nova chọn máy chủ (nút máy tính) mà VM sẽ được triển khai dựa trên các tham số, trọng số và vùng được chỉ định. Một bản ghi về điều này và ID VM được ghi vào cơ sở dữ liệu nova.
- Tiếp theo, nova-scheduler liên hệ với nova-compute với yêu cầu triển khai một phiên bản. Nova-compute liên hệ với nova-conductor để lấy thông tin về thông số máy (nova-conductor là phần tử nova đóng vai trò là proxy server giữa nova-database và nova-compute, hạn chế số lượng request tới nova-database để tránh các sự cố với cơ sở dữ liệu giảm tải nhất quán).
- Nova-conductor nhận thông tin được yêu cầu từ cơ sở dữ liệu nova và chuyển nó tới nova-compute.
- Tiếp theo, nova-compute gọi lướt qua để lấy ID hình ảnh. Glace xác thực yêu cầu trong Keystone và trả về thông tin được yêu cầu.
- Nova-compute tiếp xúc với neutron để thu được thông tin về các tham số mạng. Tương tự như cái nhìn thoáng qua, neutron xác thực yêu cầu trong Keystone, sau đó nó tạo một mục trong cơ sở dữ liệu (mã định danh cổng, v.v.), tạo yêu cầu tạo cổng và trả về thông tin được yêu cầu cho nova-compute.
- Nova-compute liên hệ với yêu cầu phân bổ ổ đĩa cho máy ảo. Tương tự như cái nhìn thoáng qua, rượu táo xác thực yêu cầu trong Keystone, tạo yêu cầu tạo khối lượng và trả về thông tin được yêu cầu.
- Nova-compute liên hệ với libvirt với yêu cầu triển khai một máy ảo với các tham số được chỉ định.
Trên thực tế, một thao tác tưởng chừng như đơn giản là tạo một máy ảo đơn giản lại biến thành một loạt lệnh gọi API giữa các thành phần của nền tảng đám mây. Hơn nữa, như bạn có thể thấy, ngay cả các dịch vụ được chỉ định trước đó cũng bao gồm các thành phần nhỏ hơn mà giữa đó xảy ra tương tác. Tạo máy chỉ là một phần nhỏ trong những gì nền tảng đám mây cho phép bạn thực hiện - có dịch vụ chịu trách nhiệm cân bằng lưu lượng, dịch vụ chịu trách nhiệm lưu trữ khối, dịch vụ chịu trách nhiệm về DNS, dịch vụ chịu trách nhiệm cung cấp máy chủ kim loại trần, v.v. Đám mây cho phép bạn đối xử với các máy ảo của mình như một đàn cừu (ngược lại với ảo hóa). Nếu có điều gì đó xảy ra với máy của bạn trong môi trường ảo - bạn khôi phục nó từ bản sao lưu, v.v., nhưng các ứng dụng đám mây được xây dựng theo cách mà máy ảo không đóng vai trò quan trọng như vậy - máy ảo “đã chết” - không vấn đề gì - một chiếc mới vừa được tạo ra, chiếc xe này dựa trên mẫu và như người ta nói, đội không nhận thấy việc mất máy bay chiến đấu. Đương nhiên, điều này cung cấp sự hiện diện của các cơ chế điều phối - bằng cách sử dụng các mẫu Heat, bạn có thể dễ dàng triển khai một chức năng phức tạp bao gồm hàng chục mạng và máy ảo.
Điều đáng ghi nhớ là không có cơ sở hạ tầng đám mây nếu không có mạng - mỗi phần tử theo cách này hay cách khác tương tác với các phần tử khác thông qua mạng. Ngoài ra, đám mây còn có một mạng lưới hoàn toàn không tĩnh. Đương nhiên, mạng lớp phủ thậm chí còn ít nhiều tĩnh - các nút và bộ chuyển mạch mới không được thêm vào hàng ngày, nhưng thành phần lớp phủ có thể và chắc chắn sẽ thay đổi liên tục - các mạng mới sẽ được thêm hoặc xóa, các máy ảo mới sẽ xuất hiện và các máy cũ sẽ xuất hiện. chết. Và như bạn còn nhớ từ định nghĩa về đám mây được đưa ra ở đầu bài viết, tài nguyên phải được phân bổ tự động cho người dùng và với ít nhất (hoặc tốt hơn là không có) sự can thiệp từ nhà cung cấp dịch vụ. Nghĩa là, loại cung cấp tài nguyên mạng hiện tồn tại ở dạng giao diện người dùng dưới dạng tài khoản cá nhân của bạn có thể truy cập qua http/https và kỹ sư mạng đang làm nhiệm vụ Vasily làm phụ trợ không phải là đám mây, thậm chí nếu Vasily có tám bàn tay.
Neutron, với tư cách là một dịch vụ mạng, cung cấp API để quản lý phần mạng của cơ sở hạ tầng đám mây. Dịch vụ này hỗ trợ và quản lý phần kết nối mạng của Openstack bằng cách cung cấp lớp trừu tượng được gọi là Network-as-a-Service (NaaS). Nghĩa là, mạng là đơn vị đo lường ảo giống như lõi CPU ảo hoặc dung lượng RAM.
Nhưng trước khi chuyển sang kiến trúc phần mạng của OpenStack, hãy xem xét cách mạng này hoạt động trong OpenStack và tại sao mạng là một phần quan trọng và không thể thiếu của đám mây.
Vì vậy, chúng tôi có hai máy ảo máy khách ĐỎ và hai máy ảo máy khách XANH. Giả sử rằng các máy này được đặt trên hai bộ ảo hóa theo cách này:
Hiện tại, đây chỉ là ảo hóa 4 máy chủ và không có gì hơn, vì cho đến nay tất cả những gì chúng tôi đã làm là ảo hóa 4 máy chủ, đặt chúng trên hai máy chủ vật lý. Và cho đến nay họ thậm chí còn không được kết nối với mạng.
Để tạo một đám mây, chúng ta cần thêm một số thành phần. Đầu tiên, chúng tôi ảo hóa phần mạng - chúng tôi cần kết nối 4 máy này theo cặp và khách hàng muốn có kết nối L2. Bạn có thể sử dụng một công tắc và định cấu hình một đường trục theo hướng của nó và giải quyết mọi thứ bằng cách sử dụng cầu linux hoặc, đối với những người dùng cao cấp hơn, openvswitch (chúng ta sẽ quay lại vấn đề này sau). Nhưng có thể có rất nhiều mạng và việc liên tục đẩy L2 qua một bộ chuyển mạch không phải là ý tưởng hay nhất - có nhiều bộ phận khác nhau, bàn dịch vụ, hàng tháng chờ đợi để hoàn thành ứng dụng, hàng tuần xử lý sự cố - trong thế giới hiện đại, điều này cách tiếp cận không còn hiệu quả nữa. Và công ty càng hiểu điều này sớm thì càng dễ dàng tiến về phía trước. Do đó, giữa các trình ảo hóa, chúng tôi sẽ chọn một mạng L3 mà qua đó các máy ảo của chúng tôi sẽ giao tiếp và trên mạng L3 này, chúng tôi sẽ xây dựng các mạng lớp phủ L2 ảo nơi lưu lượng của các máy ảo của chúng tôi sẽ chạy. Bạn có thể sử dụng GRE, Geneve hoặc VxLAN làm gói đóng gói. Bây giờ hãy tập trung vào phần sau, mặc dù nó không đặc biệt quan trọng.
Chúng ta cần xác định vị trí VTEP ở đâu đó (tôi hy vọng mọi người đều quen thuộc với thuật ngữ VxLAN). Vì chúng tôi có mạng L3 đến thẳng từ máy chủ nên không có gì ngăn cản chúng tôi đặt VTEP trên chính máy chủ và OVS (OpenvSwitch) thực hiện điều này rất xuất sắc. Kết quả là chúng ta có được thiết kế này:
Do lưu lượng giữa các máy ảo phải được phân chia nên các cổng hướng tới máy ảo sẽ có số vlan khác nhau. Số thẻ chỉ đóng vai trò trong một switch ảo, vì khi được gói gọn trong VxLAN chúng ta có thể dễ dàng loại bỏ nó vì chúng ta sẽ có VNI.
Bây giờ chúng ta có thể tạo máy và mạng ảo cho chúng mà không gặp vấn đề gì.
Tuy nhiên, điều gì sẽ xảy ra nếu máy khách có một máy khác nhưng ở trên một mạng khác? Chúng tôi cần root giữa các mạng. Chúng ta sẽ xem xét một tùy chọn đơn giản khi sử dụng định tuyến tập trung - nghĩa là lưu lượng được định tuyến thông qua các nút mạng chuyên dụng đặc biệt (theo quy luật, chúng được kết hợp với các nút điều khiển, vì vậy chúng ta sẽ có điều tương tự).
Có vẻ như không có gì phức tạp - chúng tôi tạo giao diện cầu nối trên nút điều khiển, hướng lưu lượng truy cập đến nút đó và từ đó chúng tôi định tuyến đến nơi chúng tôi cần. Nhưng vấn đề là máy khách RED muốn sử dụng mạng 10.0.0.0/24 và máy khách XANH muốn sử dụng mạng 10.0.0.0/24. Tức là chúng ta bắt đầu giao nhau giữa các không gian địa chỉ. Ngoài ra, khách hàng không muốn các khách hàng khác có thể định tuyến vào mạng nội bộ của họ, điều này có ý nghĩa. Để phân tách mạng và lưu lượng dữ liệu máy khách, chúng tôi sẽ phân bổ một không gian tên riêng cho từng mạng. Trên thực tế, không gian tên là một bản sao của ngăn xếp mạng Linux, nghĩa là các máy khách trong không gian tên RED hoàn toàn tách biệt với các máy khách khỏi không gian tên XANH (tốt, việc định tuyến giữa các mạng máy khách này được cho phép thông qua không gian tên mặc định hoặc trên thiết bị truyền tải ngược dòng).
Tức là ta có sơ đồ sau:
Đường hầm L2 hội tụ từ tất cả các nút tính toán đến nút điều khiển. nút nơi đặt giao diện L3 cho các mạng này, mỗi mạng nằm trong một không gian tên dành riêng để cách ly.
Tuy nhiên, chúng ta đã quên điều quan trọng nhất. Máy ảo phải cung cấp dịch vụ cho máy khách, nghĩa là nó phải có ít nhất một giao diện bên ngoài để có thể truy cập được. Tức là chúng ta cần phải bước ra thế giới bên ngoài. Có nhiều lựa chọn khác nhau ở đây. Hãy thực hiện lựa chọn đơn giản nhất. Chúng tôi sẽ thêm một mạng cho mỗi khách hàng, mạng này sẽ hợp lệ trong mạng của nhà cung cấp và sẽ không trùng lặp với các mạng khác. Các mạng cũng có thể giao nhau và xem xét các VRF khác nhau ở phía mạng của nhà cung cấp. Dữ liệu mạng cũng sẽ nằm trong không gian tên của mỗi khách hàng. Tuy nhiên, chúng vẫn sẽ đi ra thế giới bên ngoài thông qua một giao diện vật lý (hoặc liên kết, hợp lý hơn). Để phân tách lưu lượng máy khách, lưu lượng truy cập đi ra ngoài sẽ được gắn thẻ VLAN được cấp cho máy khách.
Kết quả là chúng ta có sơ đồ này:
Một câu hỏi hợp lý là tại sao không tự tạo cổng trên các nút điện toán? Đây không phải là vấn đề lớn, hơn nữa, nếu bạn bật bộ định tuyến phân tán (DVR), điều này sẽ hoạt động. Trong trường hợp này, chúng tôi đang xem xét tùy chọn đơn giản nhất với cổng tập trung, được sử dụng theo mặc định trong Openstack. Đối với các chức năng tải cao, họ sẽ sử dụng cả bộ định tuyến phân tán và các công nghệ tăng tốc như SR-IOV và Passthrough, nhưng như họ nói, đó lại là một câu chuyện hoàn toàn khác. Đầu tiên chúng ta hãy giải quyết phần cơ bản và sau đó chúng ta sẽ đi vào chi tiết.
Trên thực tế, kế hoạch của chúng tôi đã khả thi, nhưng có một số sắc thái:
- Chúng ta cần bằng cách nào đó bảo vệ máy của mình, tức là đặt một bộ lọc trên giao diện chuyển đổi hướng tới máy khách.
- Giúp máy ảo có thể tự động lấy địa chỉ IP để bạn không phải đăng nhập vào đó thông qua bảng điều khiển mỗi lần và đăng ký địa chỉ.
Hãy bắt đầu với việc bảo vệ máy. Để làm được điều này, bạn có thể sử dụng iptables tầm thường, tại sao không.
Nghĩa là, bây giờ cấu trúc liên kết của chúng tôi đã trở nên phức tạp hơn một chút:
Tiếp tục nào. Chúng ta cần thêm một máy chủ DHCP. Nơi lý tưởng nhất để định vị máy chủ DHCP cho mỗi máy khách sẽ là nút điều khiển đã được đề cập ở trên, nơi đặt các không gian tên:
Tuy nhiên, có một vấn đề nhỏ. Điều gì sẽ xảy ra nếu mọi thứ khởi động lại và mọi thông tin về việc thuê địa chỉ trên DHCP đều biến mất. Điều hợp lý là các máy sẽ được cấp địa chỉ mới, điều này không thuận tiện lắm. Ở đây có hai cách - sử dụng tên miền và thêm máy chủ DNS cho mỗi máy khách, khi đó địa chỉ sẽ không đặc biệt quan trọng đối với chúng tôi (tương tự như phần mạng trong k8s) - nhưng có một vấn đề với mạng bên ngoài, vì địa chỉ cũng có thể được cấp trong đó thông qua DHCP - bạn cần đồng bộ hóa với các máy chủ DNS trên nền tảng đám mây và máy chủ DNS bên ngoài, theo ý kiến của tôi thì không linh hoạt lắm nhưng hoàn toàn có thể. Hoặc tùy chọn thứ hai là sử dụng siêu dữ liệu - tức là lưu thông tin về địa chỉ được cấp cho máy để máy chủ DHCP biết địa chỉ nào sẽ cấp cho máy nếu máy đã nhận được địa chỉ đó. Tùy chọn thứ hai đơn giản và linh hoạt hơn vì nó cho phép bạn lưu thêm thông tin về xe. Bây giờ hãy thêm siêu dữ liệu tác nhân vào sơ đồ:
Một vấn đề khác cũng đáng thảo luận là khả năng sử dụng một mạng bên ngoài cho tất cả các máy khách, vì các mạng bên ngoài, nếu chúng phải hợp lệ trên toàn bộ mạng, sẽ rất khó khăn - bạn cần liên tục phân bổ và kiểm soát việc phân bổ các mạng này. Khả năng sử dụng một mạng bên ngoài được cấu hình sẵn cho tất cả các máy khách sẽ rất hữu ích khi tạo đám mây công cộng. Điều này sẽ giúp triển khai máy dễ dàng hơn vì chúng tôi không phải tham khảo cơ sở dữ liệu địa chỉ và chọn không gian địa chỉ duy nhất cho mạng bên ngoài của mỗi khách hàng. Ngoài ra, chúng ta có thể đăng ký trước một mạng bên ngoài và tại thời điểm triển khai, chúng ta sẽ chỉ cần liên kết các địa chỉ bên ngoài với các máy khách.
Và ở đây NAT hỗ trợ chúng tôi - chúng tôi sẽ giúp khách hàng có thể truy cập vào thế giới bên ngoài thông qua không gian tên mặc định bằng cách sử dụng bản dịch NAT. Vâng, đây là một vấn đề nhỏ. Điều này là tốt nếu máy chủ khách hoạt động như một máy khách chứ không phải máy chủ - nghĩa là nó khởi tạo thay vì chấp nhận các kết nối. Nhưng đối với chúng tôi thì mọi chuyện sẽ ngược lại. Trong trường hợp này, chúng ta cần thực hiện NAT đích để khi nhận lưu lượng, nút điều khiển hiểu rằng lưu lượng này dành cho máy ảo A của máy khách A, nghĩa là chúng ta cần thực hiện dịch NAT từ địa chỉ bên ngoài, ví dụ 100.1.1.1 .10.0.0.1, tới địa chỉ nội bộ 100. Trong trường hợp này, mặc dù tất cả các máy khách sẽ sử dụng cùng một mạng nhưng sự cách ly bên trong vẫn được bảo toàn hoàn toàn. Tức là chúng ta cần thực hiện dNAT và sNAT trên nút điều khiển. Việc sử dụng một mạng duy nhất với địa chỉ nổi hay mạng bên ngoài hay cả hai cùng một lúc, tùy thuộc vào những gì bạn muốn đưa vào đám mây. Chúng tôi sẽ không thêm địa chỉ nổi vào sơ đồ mà sẽ để lại các mạng bên ngoài đã được thêm trước đó - mỗi máy khách có mạng bên ngoài riêng (trong sơ đồ chúng được biểu thị là vlan 200 và XNUMX trên giao diện bên ngoài).
Kết quả là chúng tôi đã nhận được một giải pháp thú vị, đồng thời được cân nhắc kỹ lưỡng, có tính linh hoạt nhất định nhưng chưa có cơ chế chịu lỗi.
Thứ nhất, chúng ta chỉ có một nút điều khiển - nếu nút này bị hỏng sẽ dẫn đến sự sụp đổ của tất cả các hệ thống. Để khắc phục sự cố này, bạn cần tạo ít nhất tối thiểu 3 nút. Hãy thêm phần này vào sơ đồ:
Đương nhiên, tất cả các nút đều được đồng bộ hóa và khi một nút hoạt động rời đi, một nút khác sẽ đảm nhận trách nhiệm của nó.
Vấn đề tiếp theo là đĩa máy ảo. Hiện tại, chúng được lưu trữ trên chính các trình ảo hóa và trong trường hợp có vấn đề với trình ảo hóa, chúng tôi sẽ mất tất cả dữ liệu - và sự hiện diện của một cuộc đột kích sẽ không giúp ích gì ở đây nếu chúng tôi không mất đĩa mà là toàn bộ máy chủ. Để làm điều này, chúng ta cần tạo một dịch vụ đóng vai trò là giao diện người dùng cho một số loại lưu trữ. Loại lưu trữ nào không đặc biệt quan trọng đối với chúng tôi, nhưng nó sẽ bảo vệ dữ liệu của chúng tôi khỏi hỏng cả đĩa và nút, và có thể là toàn bộ tủ. Ở đây có một số lựa chọn - tất nhiên có mạng SAN với Kênh sợi quang, nhưng thành thật mà nói - FC đã là di tích của quá khứ - một dạng tương tự của E1 trong vận tải - vâng, tôi đồng ý, nó vẫn được sử dụng, nhưng chỉ ở nơi hoàn toàn không thể nếu không có nó. Vì vậy, tôi sẽ không tự nguyện triển khai mạng FC vào năm 2020 vì biết rằng có những lựa chọn thay thế khác thú vị hơn. Mặc dù với mỗi người, có thể có những người tin rằng FC với tất cả những hạn chế của nó là tất cả những gì chúng ta cần - tôi sẽ không tranh luận, mọi người đều có quan điểm riêng của mình. Tuy nhiên, theo tôi, giải pháp thú vị nhất là sử dụng SDS, chẳng hạn như Ceph.
Ceph cho phép bạn xây dựng một giải pháp lưu trữ dữ liệu có tính sẵn sàng cao với nhiều tùy chọn sao lưu khả thi, bắt đầu bằng mã có kiểm tra tính chẵn lẻ (tương tự như raid 5 hoặc 6) kết thúc bằng việc sao chép toàn bộ dữ liệu sang các đĩa khác nhau, có tính đến vị trí của các đĩa trong máy chủ và máy chủ trong tủ, v.v.
Để xây dựng Ceph bạn cần thêm 3 nút nữa. Tương tác với bộ lưu trữ cũng sẽ được thực hiện thông qua mạng bằng cách sử dụng các dịch vụ lưu trữ khối, đối tượng và tệp. Hãy thêm bộ nhớ vào lược đồ:
Lưu ý: bạn cũng có thể tạo các nút điện toán siêu hội tụ - đây là khái niệm kết hợp nhiều chức năng trên một nút - ví dụ: lưu trữ+điện toán - mà không cần dành riêng các nút đặc biệt cho bộ lưu trữ ceph. Chúng tôi sẽ có cùng một sơ đồ chịu lỗi - vì SDS sẽ dự trữ dữ liệu với mức dự trữ mà chúng tôi chỉ định. Tuy nhiên, các nút siêu hội tụ luôn là một sự thỏa hiệp - vì nút lưu trữ không chỉ làm nóng không khí như thoạt nhìn (vì không có máy ảo trên đó) - nó tiêu tốn tài nguyên CPU để phục vụ SDS (trên thực tế, nó làm tất cả sao chép và phục hồi sau các lỗi của nút, đĩa, v.v.). Nghĩa là, bạn sẽ mất một phần sức mạnh của nút điện toán nếu kết hợp nó với bộ lưu trữ.
Tất cả những thứ này cần được quản lý bằng cách nào đó - chúng ta cần thứ gì đó mà qua đó chúng ta có thể tạo ra một máy, mạng, bộ định tuyến ảo, v.v. Để thực hiện việc này, chúng ta sẽ thêm một dịch vụ vào nút điều khiển, nút này sẽ hoạt động như một trang tổng quan - khách hàng sẽ có thể kết nối với cổng này thông qua http/ https và làm mọi thứ anh ta cần (à, gần như vậy).
Kết quả là bây giờ chúng ta có một hệ thống có khả năng chịu lỗi. Tất cả các yếu tố của cơ sở hạ tầng này phải được quản lý bằng cách nào đó. Trước đây người ta đã mô tả rằng Openstack là một tập hợp các dự án, mỗi dự án cung cấp một chức năng cụ thể. Như chúng ta thấy, có quá nhiều yếu tố cần được cấu hình và kiểm soát. Hôm nay chúng ta sẽ nói về phần mạng.
Cấu trúc neutron
Trong OpenStack, chính Neutron chịu trách nhiệm kết nối các cổng máy ảo với mạng L2 chung, đảm bảo định tuyến lưu lượng giữa các VM nằm trên các mạng L2 khác nhau, cũng như định tuyến ra bên ngoài, cung cấp các dịch vụ như NAT, Float IP, DHCP, v.v.
Ở mức độ cao, hoạt động của dịch vụ mạng (phần cơ bản) có thể được mô tả như sau.
Khi khởi động VM, dịch vụ mạng:
- Tạo một cổng cho một VM (hoặc các cổng) nhất định và thông báo cho dịch vụ DHCP về nó;
- Một thiết bị mạng ảo mới được tạo (thông qua libvirt);
- VM kết nối với (các) cổng được tạo ở bước 1;
Thật kỳ lạ, công việc của Neutron dựa trên các cơ chế tiêu chuẩn quen thuộc với tất cả những ai đã từng tìm hiểu Linux - không gian tên, iptables, cầu nối linux, openvswitch, conntrack, v.v.
Cần phải làm rõ ngay rằng Neutron không phải là bộ điều khiển SDN.
Neutron bao gồm một số thành phần liên kết với nhau:
Openstack-neutron-máy chủ là một daemon hoạt động với các yêu cầu của người dùng thông qua API. Con quỷ này không liên quan đến việc đăng ký bất kỳ kết nối mạng nào nhưng cung cấp thông tin cần thiết cho việc này cho các plugin của nó, sau đó cấu hình thành phần mạng mong muốn. Các tác nhân neutron trên các nút OpenStack đăng ký với máy chủ Neutron.
Neutron-server thực chất là một ứng dụng được viết bằng python, bao gồm hai phần:
- Dịch vụ REST
- Plugin neutron (lõi/dịch vụ)
Dịch vụ REST được thiết kế để nhận lệnh gọi API từ các thành phần khác (ví dụ: yêu cầu cung cấp một số thông tin, v.v.)
Plugin là các thành phần/mô-đun phần mềm plug-in được gọi trong các yêu cầu API - nghĩa là việc phân bổ dịch vụ xảy ra thông qua chúng. Plugin được chia thành hai loại - dịch vụ và root. Theo quy định, plugin ngựa chịu trách nhiệm chính trong việc quản lý không gian địa chỉ và kết nối L2 giữa các máy ảo và các plugin dịch vụ đã cung cấp chức năng bổ sung như VPN hoặc FW.
Danh sách các plugin có sẵn ngày hôm nay có thể được xem ví dụ
Có thể có một số plugin dịch vụ, nhưng chỉ có thể có một plugin ngựa.
openstack-neutron-ml2 là plugin gốc Openstack tiêu chuẩn. Plugin này có kiến trúc mô-đun (không giống như phiên bản tiền nhiệm của nó) và định cấu hình dịch vụ mạng thông qua các trình điều khiển được kết nối với nó. Chúng ta sẽ xem xét phần bổ trợ này sau, vì trên thực tế, nó mang lại sự linh hoạt mà OpenStack có trong phần mạng. Plugin gốc có thể được thay thế (ví dụ: Contrail Networking thực hiện thay thế như vậy).
Dịch vụ RPC (rabbitmq-server) — một dịch vụ cung cấp khả năng quản lý hàng đợi và tương tác với các dịch vụ OpenStack khác, cũng như tương tác giữa các tác nhân dịch vụ mạng.
Đại lý mạng — các tác nhân được đặt tại mỗi nút, qua đó các dịch vụ mạng được cấu hình.
Có một số loại đại lý.
Đại lý chính là Đại lý L2. Các tác nhân này chạy trên mỗi bộ ảo hóa, bao gồm các nút điều khiển (chính xác hơn là trên tất cả các nút cung cấp bất kỳ dịch vụ nào cho người thuê) và chức năng chính của chúng là kết nối các máy ảo với mạng L2 chung và cũng tạo cảnh báo khi có bất kỳ sự kiện nào xảy ra ( ví dụ: tắt/bật cổng).
Tác nhân tiếp theo không kém phần quan trọng là Đại lý L3. Theo mặc định, tác nhân này chạy độc quyền trên một nút mạng (thường nút mạng được kết hợp với nút điều khiển) và cung cấp định tuyến giữa các mạng của đối tượng thuê (cả giữa mạng của nó và mạng của các đối tượng thuê khác và có thể truy cập được từ thế giới bên ngoài, cung cấp NAT, cũng như dịch vụ DHCP). Tuy nhiên, khi sử dụng DVR (bộ định tuyến phân tán), nhu cầu về plugin L3 cũng xuất hiện trên các nút điện toán.
Tác nhân L3 sử dụng không gian tên Linux để cung cấp cho mỗi đối tượng thuê một tập hợp các mạng riêng biệt và chức năng của bộ định tuyến ảo định tuyến lưu lượng truy cập và cung cấp dịch vụ cổng cho mạng Lớp 2.
Cơ sở dữ liệu - cơ sở dữ liệu về các mã định danh của mạng, mạng con, cổng, nhóm, v.v.
Trên thực tế, Neutron chấp nhận các yêu cầu API từ việc tạo bất kỳ thực thể mạng nào, xác thực yêu cầu và thông qua RPC (nếu nó truy cập vào một số plugin hoặc tác nhân) hoặc API REST (nếu nó giao tiếp trong SDN) truyền tới các tác nhân (thông qua plugin) hướng dẫn cần thiết để tổ chức dịch vụ được yêu cầu.
Bây giờ chúng ta hãy chuyển sang cài đặt thử nghiệm (cách triển khai và những gì được bao gồm trong đó, chúng ta sẽ xem sau trong phần thực tế) và xem vị trí của từng thành phần:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
Thực ra đó là toàn bộ cấu trúc của neutron. Bây giờ, bạn nên dành chút thời gian cho plugin ML2.
Lớp mô-đun 2
Như đã đề cập ở trên, plugin này là plugin gốc OpenStack tiêu chuẩn và có kiến trúc mô-đun.
Tiền thân của plugin ML2 có cấu trúc nguyên khối, chẳng hạn, không cho phép sử dụng kết hợp nhiều công nghệ trong một lần cài đặt. Ví dụ: bạn không thể sử dụng cả openvswitch và linuxbridge cùng lúc - cái đầu tiên hoặc cái thứ hai. Vì lý do này, plugin ML2 với kiến trúc của nó đã được tạo ra.
ML2 có hai thành phần - hai loại trình điều khiển: Trình điều khiển loại và trình điều khiển Cơ chế.
Loại trình điều khiển xác định các công nghệ sẽ được sử dụng để tổ chức các kết nối mạng, ví dụ VxLAN, Vlan, GRE. Đồng thời, trình điều khiển cho phép sử dụng các công nghệ khác nhau. Công nghệ tiêu chuẩn là đóng gói VxLAN cho mạng lớp phủ và mạng bên ngoài vlan.
Loại trình điều khiển bao gồm các loại mạng sau:
Bằng phẳng - mạng không gắn thẻ
VLAN - mạng được gắn thẻ
Địa phương — một loại mạng đặc biệt dành cho các cài đặt tất cả trong một (các cài đặt như vậy là cần thiết cho các nhà phát triển hoặc cho việc đào tạo)
GRE - mạng lớp phủ sử dụng đường hầm GRE
VxLAN - mạng lớp phủ sử dụng đường hầm VxLAN
Trình điều khiển cơ chế xác định các công cụ đảm bảo tổ chức các công nghệ được chỉ định trong trình điều khiển loại - ví dụ: openvswitch, sr-iov, opendaylight, OVN, v.v.
Tùy thuộc vào việc triển khai trình điều khiển này, các tác nhân do Neutron điều khiển sẽ được sử dụng hoặc các kết nối với bộ điều khiển SDN bên ngoài sẽ được sử dụng, xử lý tất cả các vấn đề liên quan đến tổ chức mạng L2, định tuyến, v.v.
Ví dụ: nếu chúng ta sử dụng ML2 cùng với OVS thì tác nhân L2 sẽ được cài đặt trên mỗi nút máy tính quản lý OVS. Tuy nhiên, nếu chúng tôi sử dụng, chẳng hạn như OVN hoặc OpenDayLight, thì quyền kiểm soát OVS sẽ thuộc thẩm quyền của họ - Neutron, thông qua plugin gốc, đưa ra lệnh cho bộ điều khiển và nó đã thực hiện những gì được yêu cầu.
Hãy bắt đầu với Open vSwitch
Hiện tại, một trong những thành phần chính của OpenStack là Open vSwitch.
Khi cài đặt OpenStack mà không có bất kỳ nhà cung cấp SDN bổ sung nào như Juniper Contrail hoặc Nokia Nuage, OVS là thành phần mạng chính của mạng đám mây và cùng với iptables, conntrack, không gian tên, cho phép bạn tổ chức các mạng lớp phủ nhiều bên thuê chính thức. Đương nhiên, thành phần này có thể được thay thế, chẳng hạn như khi sử dụng các giải pháp SDN độc quyền của bên thứ ba (nhà cung cấp).
OVS là một bộ chuyển mạch phần mềm nguồn mở được thiết kế để sử dụng trong môi trường ảo hóa với vai trò là bộ chuyển tiếp lưu lượng ảo.
Hiện tại, OVS có chức năng rất tốt, bao gồm các công nghệ như QoS, LACP, Vlan, VxLAN, GENEVE, OpenFlow, DPDK, v.v.
Lưu ý: OVS ban đầu không được hình thành như một công tắc mềm dành cho các chức năng viễn thông có tải trọng cao mà được thiết kế phù hợp hơn cho các chức năng CNTT đòi hỏi ít băng thông hơn như máy chủ WEB hoặc máy chủ thư. Tuy nhiên, OVS đang được phát triển hơn nữa và việc triển khai OVS hiện tại đã cải thiện đáng kể hiệu suất và khả năng của nó, cho phép nó được sử dụng bởi các nhà khai thác viễn thông với các chức năng được tải cao, ví dụ, có một triển khai OVS có hỗ trợ tăng tốc DPDK.
Có ba thành phần quan trọng của OVS mà bạn cần lưu ý:
- Mô-đun nhân — một thành phần nằm trong không gian hạt nhân xử lý lưu lượng truy cập dựa trên các quy tắc nhận được từ phần tử điều khiển;
- vChuyển đổi daemon (ovs-vswitchd) là một tiến trình được khởi chạy trong không gian người dùng, chịu trách nhiệm lập trình mô-đun hạt nhân - nghĩa là nó trực tiếp thể hiện logic hoạt động của switch
- Máy chủ cơ sở dữ liệu - cơ sở dữ liệu cục bộ nằm trên mỗi máy chủ chạy OVS, trong đó cấu hình được lưu trữ. Bộ điều khiển SDN có thể giao tiếp thông qua mô-đun này bằng giao thức OVSDB.
Tất cả điều này được đi kèm với một bộ tiện ích chẩn đoán và quản lý, chẳng hạn như ovs-vsctl, ovs-appctl, ovs-ofctl, v.v.
Hiện tại, Openstack được các nhà khai thác viễn thông sử dụng rộng rãi để di chuyển các chức năng mạng sang nó, chẳng hạn như EPC, SBC, HLR, v.v. Một số chức năng có thể hoạt động mà không gặp vấn đề gì với OVS, nhưng ví dụ: EPC xử lý lưu lượng thuê bao - sau đó nó đi qua một lượng lưu lượng truy cập khổng lồ (hiện nay lưu lượng truy cập đạt tới vài trăm gigabit mỗi giây). Đương nhiên, điều khiển lưu lượng truy cập như vậy qua không gian kernel (vì trình chuyển tiếp được đặt ở đó theo mặc định) không phải là ý tưởng hay nhất. Do đó, OVS thường được triển khai hoàn toàn trong không gian người dùng bằng công nghệ tăng tốc DPDK để chuyển tiếp lưu lượng từ NIC sang không gian người dùng bỏ qua kernel.
Lưu ý: đối với đám mây được triển khai cho các chức năng viễn thông, có thể xuất lưu lượng truy cập từ nút điện toán đi qua OVS trực tiếp đến thiết bị chuyển mạch. Cơ chế SR-IOV và Passthrough được sử dụng cho mục đích này.
Tính năng này hoạt động như thế nào trên bố cục thực tế?
Bây giờ chúng ta hãy chuyển sang phần thực hành và xem nó hoạt động như thế nào trong thực tế.
Đầu tiên, hãy triển khai cài đặt Openstack đơn giản. Vì tôi không có sẵn bộ máy chủ để thử nghiệm nên chúng tôi sẽ lắp ráp nguyên mẫu trên một máy chủ vật lý từ các máy ảo. Đúng, tất nhiên, giải pháp như vậy không phù hợp cho mục đích thương mại, nhưng để xem ví dụ về cách hoạt động của mạng trong Openstack, việc cài đặt như vậy là đủ cho mắt. Hơn nữa, việc cài đặt như vậy thậm chí còn thú vị hơn cho mục đích đào tạo - vì bạn có thể nắm bắt được lưu lượng truy cập, v.v.
Vì chúng ta chỉ cần xem phần cơ bản nên chúng ta không thể sử dụng một số mạng mà nâng cao mọi thứ chỉ bằng hai mạng và mạng thứ hai trong bố cục này sẽ được sử dụng riêng để truy cập vào máy chủ DNS và đám mây ngầm. Hiện tại chúng tôi sẽ không đề cập đến các mạng bên ngoài - đây là chủ đề cho một bài viết lớn riêng biệt.
Vì vậy, hãy bắt đầu theo thứ tự. Đầu tiên, một chút lý thuyết. Chúng ta sẽ cài đặt Openstack bằng TripleO (Openstack trên Openstack). Bản chất của TripleO là chúng tôi cài đặt Openstack tất cả trong một (nghĩa là trên một nút), được gọi là undercloud, sau đó sử dụng các khả năng của Openstack đã triển khai để cài đặt Openstack dành cho hoạt động, được gọi là overcloud. Undercloud sẽ sử dụng khả năng vốn có của mình để quản lý các máy chủ vật lý (kim loại trần) - dự án Ironic - để cung cấp các bộ ảo hóa sẽ thực hiện các vai trò của các nút tính toán, điều khiển, lưu trữ. Tức là chúng tôi không sử dụng bất kỳ công cụ nào của bên thứ ba để triển khai Openstack - chúng tôi triển khai Openstack bằng Openstack. Nó sẽ trở nên rõ ràng hơn nhiều khi quá trình cài đặt diễn ra, vì vậy chúng tôi sẽ không dừng lại ở đó và tiếp tục.
Lưu ý: Trong bài viết này, để đơn giản, tôi không sử dụng cách ly mạng cho các mạng Openstack nội bộ mà mọi thứ đều được triển khai chỉ bằng một mạng. Tuy nhiên, việc có hay không có tính năng cách ly mạng không ảnh hưởng đến chức năng cơ bản của giải pháp - mọi thứ sẽ hoạt động giống hệt như khi sử dụng tính năng cách ly, nhưng lưu lượng sẽ chảy trên cùng một mạng. Đối với cài đặt thương mại, đương nhiên cần phải sử dụng cách ly bằng các vlan và giao diện khác nhau. Ví dụ: lưu lượng quản lý lưu trữ ceph và chính lưu lượng dữ liệu (truy cập máy vào đĩa, v.v.) khi bị cô lập, hãy sử dụng các mạng con khác nhau (Quản lý lưu trữ và lưu trữ) và điều này cho phép bạn làm cho giải pháp có khả năng chịu lỗi tốt hơn bằng cách chia lưu lượng này, chẳng hạn , trên các cổng khác nhau hoặc sử dụng các cấu hình QoS khác nhau cho các lưu lượng khác nhau để lưu lượng dữ liệu không làm giảm lưu lượng báo hiệu. Trong trường hợp của chúng tôi, họ sẽ truy cập cùng một mạng và trên thực tế, điều này không hạn chế chúng tôi dưới bất kỳ hình thức nào.
Lưu ý: Vì chúng ta sẽ chạy các máy ảo trong môi trường ảo dựa trên máy ảo nên trước tiên chúng ta cần kích hoạt ảo hóa lồng nhau.
Bạn có thể kiểm tra xem ảo hóa lồng nhau có được bật hay không bằng cách này:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Nếu bạn thấy chữ N thì chúng tôi sẽ kích hoạt hỗ trợ ảo hóa lồng nhau theo bất kỳ hướng dẫn nào bạn tìm thấy trên mạng, chẳng hạn .
Chúng ta cần lắp ráp mạch sau từ máy ảo:
Trong trường hợp của tôi, để kết nối các máy ảo nằm trong quá trình cài đặt trong tương lai (và tôi có 7 máy trong số đó, nhưng bạn có thể sử dụng 4 máy nếu không có nhiều tài nguyên), tôi đã sử dụng OpenvSwitch. Tôi đã tạo một cầu nối ovs và kết nối các máy ảo với nó thông qua các nhóm cổng. Để làm điều này, tôi đã tạo một tệp xml như thế này:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Ở đây, ba nhóm cổng được khai báo - hai nhóm cổng truy cập và một nhóm cổng (nhóm cổng sau cần thiết cho máy chủ DNS, nhưng bạn có thể thực hiện mà không cần nó hoặc cài đặt nó trên máy chủ - tùy theo cách nào thuận tiện hơn cho bạn). Tiếp theo, bằng cách sử dụng mẫu này, chúng tôi khai báo mẫu của mình thông qua virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Bây giờ chúng tôi chỉnh sửa cấu hình cổng ảo hóa:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Lưu ý: trong trường hợp này, địa chỉ trên cổng ovs-br1 sẽ không thể truy cập được vì nó không có thẻ vlan. Để khắc phục điều này, bạn cần ra lệnh sudo ovs-vsctl set port ovs-br1 tag=100. Tuy nhiên, sau khi khởi động lại, thẻ này sẽ biến mất (nếu ai biết cách giữ nguyên vị trí thì tôi sẽ rất biết ơn). Nhưng điều này không quá quan trọng, vì chúng ta sẽ chỉ cần địa chỉ này trong quá trình cài đặt và sẽ không cần đến khi Openstack được triển khai đầy đủ.
Tiếp theo, chúng tôi tạo một máy dưới đám mây:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Trong quá trình cài đặt, bạn thiết lập đầy đủ các thông số cần thiết như tên máy, mật khẩu, người dùng, máy chủ ntp, v.v., bạn có thể cấu hình ngay các cổng, nhưng đối với cá nhân tôi, sau khi cài đặt, việc đăng nhập vào máy sẽ dễ dàng hơn thông qua bảng điều khiển và sửa các tập tin cần thiết. Nếu bạn đã có sẵn hình ảnh, bạn có thể sử dụng nó hoặc làm những gì tôi đã làm - tải xuống hình ảnh Centos 7 tối thiểu và sử dụng nó để cài đặt VM.
Sau khi cài đặt thành công, bạn sẽ có một máy ảo để có thể cài đặt undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningĐầu tiên hãy cài đặt các công cụ cần thiết cho quá trình cài đặt:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Cài đặt dưới đám mây
Chúng tôi tạo một người dùng ngăn xếp, đặt mật khẩu, thêm nó vào sudoer và cung cấp cho anh ta khả năng thực thi các lệnh root thông qua sudo mà không cần phải nhập mật khẩu:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackBây giờ chúng tôi chỉ định tên undercloud đầy đủ trong tệp máy chủ:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Tiếp theo, chúng tôi thêm kho lưu trữ và cài đặt phần mềm chúng tôi cần:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleLưu ý: nếu bạn không định cài đặt ceph thì bạn không cần nhập các lệnh liên quan đến ceph. Tôi đã sử dụng bản phát hành Queens, nhưng bạn có thể sử dụng bất kỳ bản nào khác mà bạn thích.
Tiếp theo, sao chép tệp cấu hình undercloud vào ngăn xếp thư mục chính của người dùng:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confBây giờ chúng ta cần sửa tệp này, điều chỉnh nó cho phù hợp với cài đặt của chúng ta.
Bạn cần thêm những dòng này vào đầu tập tin:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Vì vậy, chúng ta hãy đi qua các cài đặt:
undercloud_hostname — tên đầy đủ của máy chủ nền tảng đám mây, phải khớp với mục nhập trên máy chủ DNS
local_ip - địa chỉ nền tảng đám mây cục bộ hướng tới việc cung cấp mạng
mạng_gateway — cùng một địa chỉ cục bộ, sẽ đóng vai trò như một cổng để truy cập vào thế giới bên ngoài trong quá trình cài đặt các nút trên đám mây, cũng trùng với địa chỉ IP cục bộ
undercloud_public_host - địa chỉ API bên ngoài, mọi địa chỉ miễn phí từ mạng cung cấp đều được chỉ định
undercloud_admin_host địa chỉ API nội bộ, mọi địa chỉ miễn phí từ mạng cung cấp đều được chỉ định
máy chủ undercloud_name - Máy chủ DNS
tạo_service_certificate - dòng này rất quan trọng trong ví dụ hiện tại, vì nếu bạn không đặt nó thành false, bạn sẽ gặp lỗi trong quá trình cài đặt, sự cố được mô tả trên trình theo dõi lỗi của Red Hat
giao diện cục bộ giao diện trong việc cung cấp mạng. Giao diện này sẽ được cấu hình lại trong quá trình triển khai dưới đám mây, vì vậy bạn cần có hai giao diện trên đám mây ngầm - một để truy cập, giao diện thứ hai để cung cấp
local_mtu - MTU. Vì chúng tôi có phòng thí nghiệm thử nghiệm và tôi có MTU là 1500 trên các cổng chuyển mạch OVS nên cần đặt thành 1450 để các gói được đóng gói trong VxLAN có thể đi qua
mạng_cidr - mạng cung cấp
giả trang — sử dụng NAT để truy cập mạng bên ngoài
mạng lưới hóa trang - mạng sẽ được NAT
dhcp_start — địa chỉ bắt đầu của nhóm địa chỉ mà từ đó các địa chỉ sẽ được gán cho các nút trong quá trình triển khai trên đám mây
dhcp_end — địa chỉ cuối cùng của nhóm địa chỉ mà từ đó địa chỉ sẽ được gán cho các nút trong quá trình triển khai trên đám mây
kiểm tra_iprange — một nhóm địa chỉ cần thiết cho việc xem xét nội tâm (không được trùng lặp với nhóm địa chỉ trên)
lịch trình_max_attempts — số lần thử cài đặt overcloud tối đa (phải lớn hơn hoặc bằng số nút)
Sau khi tệp được mô tả, bạn có thể ra lệnh triển khai dưới đám mây:
openstack undercloud install
Quy trình này mất từ 10 đến 30 phút tùy thuộc vào bàn ủi của bạn. Cuối cùng, bạn sẽ thấy đầu ra như thế này:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Kết quả này cho biết bạn đã cài đặt thành công undercloud và bây giờ bạn có thể kiểm tra trạng thái của undercloud và tiến hành cài đặt overcloud.
Nếu nhìn vào đầu ra ifconfig, bạn sẽ thấy giao diện bridge mới đã xuất hiện
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Việc triển khai Overcloud bây giờ sẽ được thực hiện thông qua giao diện này.
Từ đầu ra bên dưới, bạn có thể thấy rằng chúng tôi có tất cả các dịch vụ trên một nút:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Dưới đây là cấu hình của phần mạng undercloud:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Cài đặt trên đám mây
Hiện tại, chúng tôi chỉ có đám mây ngầm và chúng tôi không có đủ nút để tập hợp đám mây phủ. Do đó, trước hết hãy triển khai các máy ảo mà chúng ta cần. Trong quá trình triển khai, chính undercloud sẽ cài đặt hệ điều hành và các phần mềm cần thiết trên máy overcloud - tức là chúng ta không cần phải triển khai toàn bộ máy mà chỉ cần tạo một đĩa (hoặc các đĩa) cho nó và xác định các thông số của nó - tức là Trên thực tế, chúng tôi nhận được một máy chủ trống không có hệ điều hành được cài đặt trên đó.
Hãy chuyển đến thư mục chứa các đĩa của máy ảo của chúng ta và tạo các đĩa có kích thước yêu cầu:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GVì chúng tôi đang hoạt động bằng root nên chúng tôi cần thay đổi chủ sở hữu của các đĩa này để không gặp vấn đề về quyền:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Lưu ý: nếu bạn không định cài đặt ceph để nghiên cứu nó, thì các lệnh không tạo ít nhất 3 nút có ít nhất hai đĩa, nhưng trong mẫu chỉ ra rằng các đĩa ảo vda, vdb, v.v. sẽ được sử dụng.
Tuyệt vời, bây giờ chúng ta cần xác định tất cả các máy này:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml Cuối cùng có lệnh -print-xml > /tmp/storage-1.xml, lệnh này tạo một tệp xml có mô tả về từng máy trong thư mục /tmp/, nếu không thêm nó, bạn sẽ không được có thể nhận dạng các máy ảo.
Bây giờ chúng ta cần định nghĩa tất cả các máy này trong virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Bây giờ có một sắc thái nhỏ - tripleO sử dụng IPMI để quản lý máy chủ trong quá trình cài đặt và xem xét nội bộ.
Xem xét nội tâm là quá trình kiểm tra phần cứng để có được các tham số cần thiết cho việc cung cấp thêm các nút. Việc xem xét nội tâm được thực hiện bằng cách sử dụng mỉa mai, một dịch vụ được thiết kế để hoạt động với các máy chủ kim loại trần.
Nhưng đây là vấn đề - trong khi các máy chủ IPMI phần cứng có một cổng riêng (hoặc một cổng chia sẻ, nhưng điều này không quan trọng), thì các máy ảo không có các cổng như vậy. Ở đây chúng tôi có một chiếc nạng tên là vbmc - một tiện ích cho phép bạn mô phỏng cổng IPMI. Sắc thái này đáng được chú ý đặc biệt đối với những ai muốn thiết lập một phòng thí nghiệm như vậy trên ESXI hypervisor - thành thật mà nói, tôi không biết liệu nó có tương tự như vbmc hay không, vì vậy bạn nên cân nhắc về vấn đề này trước khi triển khai mọi thứ .
Cài đặt vbmc:
yum install yum install python2-virtualbmcNếu hệ điều hành của bạn không thể tìm thấy gói, hãy thêm kho lưu trữ:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmBây giờ chúng ta thiết lập tiện ích. Mọi thứ ở đây đều tầm thường đến mức đáng hổ thẹn. Bây giờ điều hợp lý là không có máy chủ nào trong danh sách vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Để chúng xuất hiện, chúng phải được khai báo thủ công như thế này:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Tôi nghĩ cú pháp lệnh rõ ràng mà không cần giải thích. Tuy nhiên, hiện tại tất cả các phiên của chúng tôi đều ở trạng thái XUỐNG. Để chúng chuyển sang trạng thái UP, bạn cần kích hoạt chúng:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Và bước cuối cùng - bạn cần sửa các quy tắc tường lửa (hoặc tắt hoàn toàn nó):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Bây giờ hãy truy cập vào nền tảng đám mây và kiểm tra xem mọi thứ có hoạt động không. Địa chỉ của máy chủ là 192.168.255.200, trên nền tảng đám mây, chúng tôi đã thêm gói ipmitool cần thiết trong quá trình chuẩn bị triển khai:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningNhư bạn có thể thấy, chúng tôi đã khởi chạy thành công nút điều khiển thông qua vbmc. Bây giờ hãy tắt nó đi và tiếp tục:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Bước tiếp theo là xem xét các nút sẽ cài đặt Overcloud trên đó. Để làm điều này, chúng ta cần chuẩn bị một tệp json có mô tả về các nút của chúng ta. Xin lưu ý rằng, không giống như cài đặt trên các máy chủ trống, tệp này cho biết cổng vbmc đang chạy trên mỗi máy.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Lưu ý: nút điều khiển có hai giao diện, nhưng trong trường hợp này điều này không quan trọng, trong quá trình cài đặt này, chúng ta chỉ cần một giao diện là đủ.
Bây giờ chúng ta chuẩn bị tệp json. Chúng ta cần chỉ ra địa chỉ cây thuốc phiện của cổng mà việc cung cấp sẽ được thực hiện, các tham số của các nút, đặt tên cho chúng và cho biết cách truy cập ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Bây giờ chúng ta cần chuẩn bị hình ảnh để mỉa mai. Để thực hiện việc này, hãy tải chúng xuống qua wget và cài đặt:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$Tải hình ảnh lên nền tảng đám mây:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Kiểm tra xem tất cả hình ảnh đã được tải chưa
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Một điều nữa - bạn cần thêm máy chủ DNS:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Bây giờ chúng ta có thể đưa ra mệnh lệnh để xem xét nội tâm:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Như bạn có thể thấy từ kết quả đầu ra, mọi thứ đã hoàn thành mà không có lỗi. Hãy kiểm tra xem tất cả các nút có ở trạng thái khả dụng hay không:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Nếu các nút ở trạng thái khác, thường có thể quản lý được, thì đã xảy ra sự cố và bạn cần xem nhật ký và tìm hiểu lý do tại sao điều này xảy ra. Hãy nhớ rằng trong trường hợp này, chúng tôi đang sử dụng ảo hóa và có thể có lỗi liên quan đến việc sử dụng máy ảo hoặc vbmc.
Tiếp theo, chúng ta cần chỉ ra nút nào sẽ thực hiện chức năng nào - nghĩa là cho biết cấu hình mà nút đó sẽ triển khai:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Chỉ định hồ sơ cho mỗi nút:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Hãy kiểm tra xem chúng tôi đã làm mọi thứ chính xác chưa:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Nếu mọi thứ đều chính xác, chúng tôi sẽ đưa ra lệnh triển khai trên đám mây:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuTrong quá trình cài đặt thực, các mẫu tùy chỉnh sẽ được sử dụng một cách tự nhiên, trong trường hợp của chúng tôi, điều này sẽ làm phức tạp quá trình rất nhiều vì mỗi chỉnh sửa trong mẫu sẽ phải được giải thích. Như đã viết trước đó, ngay cả một cài đặt đơn giản cũng đủ để chúng ta xem nó hoạt động như thế nào.
Lưu ý: biến --libvirt-type qemu là cần thiết trong trường hợp này vì chúng tôi sẽ sử dụng ảo hóa lồng nhau. Nếu không, bạn sẽ không thể chạy máy ảo.
Bây giờ bạn có khoảng một giờ, hoặc có thể nhiều hơn (tùy thuộc vào khả năng của phần cứng) và bạn chỉ có thể hy vọng rằng sau thời gian này bạn sẽ thấy thông báo sau:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Bây giờ bạn đã có một phiên bản openstack gần như hoàn chỉnh, trên đó bạn có thể nghiên cứu, thử nghiệm, v.v.
Hãy kiểm tra xem mọi thứ có hoạt động tốt không. Trong ngăn xếp thư mục chính của người dùng có hai tệp - một tệp stackrc (để quản lý đám mây ngầm) và tệp thứ hai là overcloudrc (để quản lý đám mây ngầm). Các tệp này phải được chỉ định làm nguồn vì chúng chứa thông tin cần thiết để xác thực.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Quá trình cài đặt của tôi vẫn yêu cầu một cú chạm nhỏ - thêm tuyến trên bộ điều khiển, vì máy mà tôi đang làm việc nằm trên một mạng khác. Để thực hiện việc này, hãy truy cập control-1 trong tài khoản heat-admin và đăng ký tuyến đường
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Chà, bây giờ bạn có thể đi vào đường chân trời. Tất cả thông tin - địa chỉ, thông tin đăng nhập và mật khẩu - đều có trong tệp /home/stack/overcloudrc. Sơ đồ cuối cùng trông như thế này:
Nhân tiện, trong quá trình cài đặt của chúng tôi, địa chỉ máy được cấp qua DHCP và như bạn có thể thấy, chúng được cấp “ngẫu nhiên”. Bạn có thể xác định rõ ràng trong mẫu địa chỉ nào sẽ được gắn vào máy nào trong quá trình triển khai, nếu bạn cần.
Lưu lượng truy cập giữa các máy ảo như thế nào?
Trong bài viết này, chúng ta sẽ xem xét ba tùy chọn để vượt qua lưu lượng truy cập
- Hai máy trên một bộ ảo hóa trên một mạng L2
- Hai máy trên các bộ ảo hóa khác nhau trên cùng một mạng L2
- Hai máy trên các mạng khác nhau (root qua mạng)
Các trường hợp có quyền truy cập vào thế giới bên ngoài thông qua mạng bên ngoài, sử dụng địa chỉ nổi cũng như định tuyến phân tán, chúng tôi sẽ xem xét vào lần tới, bây giờ chúng tôi sẽ tập trung vào lưu lượng truy cập nội bộ.
Để kiểm tra, chúng ta hãy ghép sơ đồ sau:
Chúng tôi đã tạo 4 máy ảo - 3 trên một mạng L2 - net-1 và 1 máy khác trên mạng net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Hãy xem những máy ảo được tạo ra nằm trên những bộ ảo hóa nào:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(trên đám mây) [stack@undercloud ~]$
Máy vm-1 và vm-3 được đặt trên máy tính-0, máy vm-2 và vm-4 được đặt trên nút máy tính-1.
Ngoài ra, một bộ định tuyến ảo đã được tạo để cho phép định tuyến giữa các mạng được chỉ định:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Bộ định tuyến có hai cổng ảo đóng vai trò là cổng cho mạng:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Nhưng trước khi xem lưu lượng truy cập như thế nào, hãy xem những gì chúng ta hiện có trên nút điều khiển (cũng là nút mạng) và trên nút điện toán. Hãy bắt đầu với nút tính toán.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Hiện tại, nút có ba cầu ovs - br-int, br-tun, br-ex. Giữa chúng, như chúng ta thấy, có một tập hợp các giao diện. Để dễ hiểu, hãy vẽ tất cả các giao diện này trên sơ đồ và xem điều gì sẽ xảy ra.
Nhìn vào các địa chỉ mà đường hầm VxLAN được nâng lên, có thể thấy rằng một đường hầm được nâng lên tính-1 (192.168.255.26), đường hầm thứ hai trông tới control-1 (192.168.255.15). Nhưng điều thú vị nhất là br-ex không có giao diện vật lý và nếu bạn nhìn vào những luồng nào được cấu hình, bạn có thể thấy rằng cây cầu này hiện chỉ có thể giảm lưu lượng.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Như bạn có thể thấy từ đầu ra, địa chỉ được gắn trực tiếp vào cổng vật lý chứ không phải vào giao diện cầu ảo.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
Theo quy tắc đầu tiên, mọi thứ đến từ cổng phy-br-ex đều phải bị loại bỏ.
Trên thực tế, hiện tại không có nơi nào khác để lưu lượng truy cập vào cây cầu này ngoại trừ từ giao diện này (giao diện với br-int) và xét theo mức độ giảm, lưu lượng BUM đã bay vào cây cầu.
Nghĩa là, lưu lượng truy cập chỉ có thể rời khỏi nút này thông qua đường hầm VxLAN và không có gì khác. Tuy nhiên, nếu bạn bật DVR, tình hình sẽ thay đổi nhưng chúng ta sẽ giải quyết vấn đề đó vào lúc khác. Khi sử dụng cách ly mạng, ví dụ như sử dụng vlans, bạn sẽ không có một giao diện L3 trong vlan 0 mà là một số giao diện. Tuy nhiên, lưu lượng VxLAN sẽ rời khỏi nút theo cách tương tự nhưng cũng được gói gọn trong một số loại vlan chuyên dụng.
Chúng ta đã sắp xếp xong nút tính toán, hãy chuyển sang nút điều khiển.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Trên thực tế, có thể nói mọi thứ đều giống nhau, nhưng địa chỉ IP không còn trên giao diện vật lý mà nằm trên cầu ảo. Điều này được thực hiện vì cổng này là cổng mà qua đó lưu lượng truy cập sẽ thoát ra thế giới bên ngoài.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Cổng này được gắn với cầu br-ex và vì không có thẻ vlan trên đó nên cổng này là cổng trung kế mà trên đó tất cả các vlan đều được phép, bây giờ lưu lượng truy cập đi ra ngoài mà không có thẻ, như được chỉ ra bởi vlan-id 0 trong đầu ra ở trên.
Mọi thứ khác tại thời điểm này đều tương tự như nút điện toán - cùng những cây cầu, cùng những đường hầm dẫn đến hai nút điện toán.
Chúng tôi sẽ không xem xét các nút lưu trữ trong bài viết này, nhưng để hiểu, cần phải nói rằng phần mạng của các nút này là tầm thường đến mức đáng hổ thẹn. Trong trường hợp của chúng tôi, chỉ có một cổng vật lý (eth0) có địa chỉ IP được gán cho nó và thế là xong. Không có đường hầm VxLAN, cầu đường hầm, v.v. - không có ov nào cả, vì không có điểm nào trong đó. Khi sử dụng cách ly mạng, nút này sẽ có hai giao diện (cổng vật lý, thân máy hoặc chỉ hai vlan - không thành vấn đề - tùy thuộc vào những gì bạn muốn) - một dành cho quản lý, giao diện thứ hai dành cho lưu lượng (ghi vào đĩa VM , đọc từ đĩa, v.v.)
Chúng tôi đã tìm ra những gì chúng tôi có trên các nút khi không có bất kỳ dịch vụ nào. Bây giờ, hãy khởi chạy 4 máy ảo và xem sơ đồ được mô tả ở trên thay đổi như thế nào - chúng ta sẽ có cổng, bộ định tuyến ảo, v.v.
Cho đến nay mạng của chúng tôi trông như thế này:
Chúng tôi có hai máy ảo trên mỗi nút máy tính. Sử dụng máy tính-0 làm ví dụ, hãy xem mọi thứ được đưa vào như thế nào.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Máy chỉ có một giao diện ảo - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Giao diện này trông trong cầu linux:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Như bạn có thể thấy từ đầu ra, chỉ có hai giao diện trong cầu nối - tap95d96a75-a0 và qvb95d96a75-a0.
Ở đây, bạn nên tìm hiểu một chút về các loại thiết bị mạng ảo trong OpenStack:
vtap - giao diện ảo được gắn vào một phiên bản (VM)
qbr - Cầu Linux
qvb và qvo - cặp vEth được kết nối với cầu Linux và cầu Open vSwitch
br-int, br-tun, br-vlan — Mở cầu nối vSwitch
patch-, int-br-, phy-br- - Mở các giao diện vá lỗi vSwitch kết nối các cầu nối
qg, qr, ha, fg, sg - Mở các cổng vSwitch được thiết bị ảo sử dụng để kết nối với OVS
Như bạn hiểu, nếu chúng ta có một cổng qvb95d96a75-a0 trong cầu nối, là một cặp vEth, thì ở đâu đó sẽ có đối tác của nó, theo logic này sẽ được gọi là qvo95d96a75-a0. Hãy xem OVS có những cổng nào.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Như chúng ta có thể thấy, cổng ở dạng br-int. Br-int hoạt động như một switch kết thúc các cổng máy ảo. Ngoài qvo95d96a75-a0, cổng qvo5bd37136-47 hiển thị ở đầu ra. Đây là cổng tới máy ảo thứ hai. Kết quả là sơ đồ của chúng ta bây giờ trông như thế này:
Một câu hỏi khiến người đọc chú ý ngay lập tức quan tâm - cầu nối linux giữa cổng máy ảo và cổng OVS là gì? Thực tế là để bảo vệ máy, các nhóm bảo mật được sử dụng, không gì khác hơn là iptables. OVS không hoạt động với iptables nên chiếc nạng này đã được phát minh. Tuy nhiên, nó đang trở nên lỗi thời - nó đang được thay thế bằng conntrack trong các bản phát hành mới.
Nghĩa là, cuối cùng sơ đồ trông như thế này:
Hai máy trên một bộ ảo hóa trên một mạng L2
Vì hai máy ảo này nằm trên cùng một mạng L2 và trên cùng một bộ ảo hóa, nên lưu lượng giữa chúng sẽ chảy cục bộ thông qua br-int một cách hợp lý, vì cả hai máy sẽ nằm trên cùng một VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Hai máy trên các bộ ảo hóa khác nhau trên cùng một mạng L2
Bây giờ hãy xem lưu lượng sẽ diễn ra như thế nào giữa hai máy trên cùng một mạng L2, nhưng nằm trên các bộ ảo hóa khác nhau. Thành thật mà nói, sẽ không có gì thay đổi nhiều, chỉ có lưu lượng giữa các nhà ảo hóa sẽ đi qua đường hầm vxlan. Hãy xem một ví dụ.
Địa chỉ của các máy ảo mà chúng ta sẽ theo dõi lưu lượng truy cập:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Chúng ta xem bảng chuyển tiếp trong br-int trên máy tính-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Lưu lượng truy cập sẽ đi đến cổng 2 - hãy xem đó là loại cổng nào:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Đây là patch-tun - tức là giao diện trong br-tun. Hãy xem điều gì xảy ra với gói trên br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Gói được đóng gói trong VxLAN và gửi đến cổng 2. Hãy xem cổng 2 dẫn đến đâu:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Đây là đường hầm vxlan trên máy tính-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Hãy tới phần tính toán-1 và xem điều gì xảy ra tiếp theo với gói:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac nằm trong bảng chuyển tiếp br-int trên máy tính-1 và như có thể thấy từ kết quả đầu ra ở trên, nó hiển thị qua cổng 2, là cổng hướng tới br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Chà, sau đó chúng ta thấy rằng trong br-int trên máy tính-1 có một cây anh túc đích:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Nghĩa là, gói nhận được sẽ bay đến cổng 3, phía sau đã có phiên bản máy ảo-00000003.
Cái hay của việc triển khai Openstack để học trên cơ sở hạ tầng ảo là chúng ta có thể dễ dàng nắm bắt lưu lượng truy cập giữa các trình ảo hóa và xem điều gì đang xảy ra với nó. Đây là những gì chúng ta sẽ làm bây giờ, chạy tcpdump trên cổng vnet theo hướng tính toán-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Dòng đầu tiên cho thấy Patek từ địa chỉ 10.0.1.85 đi đến địa chỉ 10.0.1.88 (lưu lượng ICMP) và nó được gói trong gói VxLAN với vni 22 và gói đi từ máy chủ 192.168.255.19 (compute-0) đến máy chủ 192.168.255.26 .1 ( tính-XNUMX). Chúng ta có thể kiểm tra xem VNI có khớp với chỉ số được chỉ định trong ovs.
Hãy quay lại dòng này actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 là vni trong hệ thập lục phân. Hãy chuyển đổi số này sang hệ thống thứ 16:
16 = 6*16^0+1*16^1 = 6+16 = 22Tức là vni tương ứng với thực tế.
Dòng thứ hai hiển thị lưu lượng truy cập quay trở lại, à, chẳng ích gì khi giải thích điều đó, mọi thứ đều rõ ràng ở đó.
Hai máy trên các mạng khác nhau (định tuyến liên mạng)
Trường hợp cuối cùng của ngày hôm nay là định tuyến giữa các mạng trong một dự án bằng bộ định tuyến ảo. Chúng tôi đang xem xét một trường hợp không có DVR (chúng tôi sẽ xem xét nó trong một bài viết khác), do đó việc định tuyến diễn ra trên nút mạng. Trong trường hợp của chúng tôi, nút mạng không được đặt trong một thực thể riêng biệt và nằm trên nút điều khiển.
Trước tiên, hãy xem định tuyến hoạt động như thế nào:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msVì trong trường hợp này, gói phải đi đến cổng và được định tuyến ở đó, nên chúng ta cần tìm ra địa chỉ cây thuốc phiện của cổng mà chúng ta xem xét bảng ARP trong ví dụ:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Bây giờ hãy xem lưu lượng truy cập có đích đến (10.0.1.254) fa:16:3e:c4:64:70 sẽ được gửi ở đâu:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Hãy xem cổng 2 dẫn đến đâu:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Mọi thứ đều hợp lý, lưu lượng truy cập vào br-tun. Hãy xem nó sẽ được bọc trong đường hầm vxlan nào:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Cổng thứ ba là đường hầm vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Nhìn vào nút điều khiển:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Lưu lượng đã đến nút điều khiển, vì vậy chúng ta cần đến nút đó và xem việc định tuyến sẽ diễn ra như thế nào.
Như bạn nhớ, nút điều khiển bên trong trông giống hệt như nút tính toán - ba cây cầu giống nhau, chỉ có br-ex có cổng vật lý mà qua đó nút có thể gửi lưu lượng truy cập ra bên ngoài. Việc tạo các phiên bản đã thay đổi cấu hình trên các nút điện toán - cầu nối linux, iptables và giao diện đã được thêm vào các nút. Việc tạo mạng và bộ định tuyến ảo cũng để lại dấu ấn trong cấu hình của nút điều khiển.
Vì vậy, rõ ràng địa chỉ MAC của cổng phải nằm trong bảng chuyển tiếp br-int trên nút điều khiển. Hãy kiểm tra xem nó có ở đó không và nó đang tìm ở đâu:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Máy Mac hiển thị từ cổng qr-0c52b15f-8f. Nếu chúng ta quay lại danh sách các cổng ảo trong Openstack, loại cổng này được sử dụng để kết nối nhiều thiết bị ảo khác nhau với OVS. Nói chính xác hơn, qr là một cổng tới bộ định tuyến ảo, được biểu diễn dưới dạng không gian tên.
Hãy xem không gian tên trên máy chủ là gì:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Nhiều nhất là ba bản. Nhưng nhìn tên thì có thể đoán được mục đích của từng loại. Chúng ta sẽ quay lại các phiên bản có ID 0 và 1 sau, bây giờ chúng ta quan tâm đến không gian tên qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Không gian tên này chứa hai không gian tên nội bộ mà chúng ta đã tạo trước đó. Cả hai cổng ảo đã được thêm vào br-int. Hãy kiểm tra địa chỉ mac của cổng qr-0c52b15f-8f, vì lưu lượng truy cập, đánh giá theo địa chỉ mac đích, đã đi đến giao diện này.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Nghĩa là, trong trường hợp này, mọi thứ đều hoạt động theo quy luật định tuyến tiêu chuẩn. Vì lưu lượng truy cập được dành cho máy chủ 10.0.2.8 nên nó phải thoát qua giao diện thứ hai qr-92fa49b5-54 và đi qua đường hầm vxlan đến nút điện toán:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Mọi thứ đều hợp lý, không có gì bất ngờ. Hãy xem địa chỉ cây thuốc phiện của máy chủ 10.0.2.8 hiển thị ở đâu trong br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Đúng như dự kiến, lưu lượng truy cập sẽ đi đến br-tun, hãy xem lưu lượng truy cập sẽ đi đến đường hầm nào tiếp theo:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Lưu lượng đi vào đường hầm để tính-1. Chà, trên máy tính-1, mọi thứ đều đơn giản - từ br-tun gói chuyển đến br-int và từ đó đến giao diện máy ảo:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Hãy kiểm tra xem đây có thực sự là giao diện chính xác không:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
Trên thực tế, chúng tôi đã xem xét trọn gói. Tôi nghĩ bạn đã nhận thấy rằng lưu lượng truy cập đi qua các đường hầm vxlan khác nhau và thoát ra với các VNI khác nhau. Hãy xem đây là loại VNI gì, sau đó chúng ta sẽ thu thập kết xuất trên cổng điều khiển của nút và đảm bảo rằng lưu lượng truy cập diễn ra chính xác như mô tả ở trên.
Vì vậy, đường hầm tính toán-0 có các hành động sau=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Hãy chuyển đổi 0x16 sang hệ thống số thập phân:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Đường hầm tính toán-1 có VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2 sau đây. Hãy chuyển đổi 0x63 sang hệ thống số thập phân:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Chà, bây giờ chúng ta hãy nhìn vào bãi rác:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Gói đầu tiên là gói vxlan từ máy chủ 192.168.255.19 (compute-0) đến máy chủ 192.168.255.15 (control-1) với vni 22, trong đó gói ICMP được đóng gói từ máy chủ 10.0.1.85 đến máy chủ 10.0.2.8. Như chúng tôi đã tính toán ở trên, vni khớp với những gì chúng tôi thấy ở đầu ra.
Gói thứ hai là gói vxlan từ máy chủ 192.168.255.15 (control-1) đến máy chủ 192.168.255.26 (compute-1) với vni 99, trong đó gói ICMP được đóng gói từ máy chủ 10.0.1.85 đến máy chủ 10.0.2.8. Như chúng tôi đã tính toán ở trên, vni khớp với những gì chúng tôi thấy ở đầu ra.
Hai gói tiếp theo là lưu lượng truy cập trả về từ 10.0.2.8 chứ không phải 10.0.1.85.
Nghĩa là, cuối cùng chúng ta có được sơ đồ nút điều khiển sau:
Nhìn như thế là xong à? Chúng tôi đã quên mất hai không gian tên:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Như chúng ta đã nói về kiến trúc của nền tảng đám mây, sẽ rất tốt nếu máy móc tự động nhận địa chỉ từ máy chủ DHCP. Đây là hai máy chủ DHCP cho hai mạng 10.0.1.0/24 và 10.0.2.0/24 của chúng tôi.
Hãy kiểm tra xem điều này có đúng không. Chỉ có một địa chỉ trong không gian tên này - 10.0.1.1 - địa chỉ của chính máy chủ DHCP và nó cũng được bao gồm trong br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Hãy xem liệu các quy trình có chứa qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 trong tên của chúng trên nút điều khiển hay không:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Có một quy trình như vậy và dựa trên thông tin được trình bày ở đầu ra ở trên, chẳng hạn, chúng tôi có thể xem những gì chúng tôi hiện có cho thuê:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Kết quả là chúng tôi nhận được bộ dịch vụ sau trên nút điều khiển:
Xin lưu ý - đây chỉ là 4 máy, 2 mạng nội bộ và một bộ định tuyến ảo... Hiện tại chúng tôi không có mạng bên ngoài ở đây, một loạt các dự án khác nhau, mỗi dự án có mạng riêng (chồng chéo) và chúng tôi có một bộ định tuyến phân tán đã tắt và cuối cùng, chỉ có một nút điều khiển trong băng ghế thử nghiệm (để có khả năng chịu lỗi phải có số lượng tối thiểu là ba nút). Điều hợp lý là trong thương mại, mọi thứ phức tạp hơn một chút, nhưng trong ví dụ đơn giản này, chúng tôi hiểu cách nó hoạt động - việc bạn có 3 hay 300 không gian tên tất nhiên là quan trọng, nhưng từ quan điểm hoạt động của toàn bộ cấu trúc, sẽ không có gì thay đổi nhiều... mặc dù bạn sẽ không cắm SDN của nhà cung cấp nào đó. Nhưng đó là một câu chuyện hoàn toàn khác.
Tôi hy vọng nó thú vị. Nếu bạn có bất kỳ nhận xét/bổ sung nào hoặc ở đâu đó tôi đã nói dối hoàn toàn (tôi là con người và ý kiến của tôi sẽ luôn chủ quan) - hãy viết những gì cần sửa/bổ sung - chúng tôi sẽ sửa/bổ sung mọi thứ.
Để kết luận, tôi muốn nói vài lời về việc so sánh Openstack (cả vanilla và nhà cung cấp) với giải pháp đám mây từ VMWare - Tôi đã được hỏi câu hỏi này quá thường xuyên trong vài năm qua và thành thật mà nói, tôi đã mệt mỏi với nó, nhưng vẫn còn. Theo tôi, rất khó để so sánh hai giải pháp này, nhưng chúng ta có thể nói chắc chắn rằng cả hai giải pháp đều có những nhược điểm và khi chọn một giải pháp bạn cần cân nhắc ưu và nhược điểm.
Nếu OpenStack là một giải pháp hướng đến cộng đồng, thì VMWare chỉ có quyền làm những gì họ muốn (đọc - điều gì mang lại lợi nhuận cho nó) và điều này là hợp lý - bởi vì đây là một công ty thương mại quen với việc kiếm tiền từ khách hàng của mình. Nhưng có một NHƯNG lớn và béo - chẳng hạn như bạn có thể thoát khỏi OpenStack từ Nokia và với một ít chi phí, hãy chuyển sang giải pháp từ Juniper (Contrail Cloud), nhưng bạn khó có thể thoát khỏi VMWare . Đối với tôi, hai giải pháp này trông như thế này - Openstack (nhà cung cấp) là một cái lồng đơn giản mà bạn được đặt vào đó, nhưng bạn có chìa khóa và bạn có thể rời đi bất cứ lúc nào. VMWare là một chiếc lồng vàng, người chủ có chìa khóa của chiếc lồng và bạn sẽ phải tốn rất nhiều chi phí.
Tôi không quảng cáo sản phẩm đầu tiên hay sản phẩm thứ hai - bạn chọn thứ bạn cần. Nhưng nếu được lựa chọn như vậy, tôi sẽ chọn cả hai giải pháp - VMWare cho đám mây CNTT (tải thấp, quản lý dễ dàng), OpenStack từ một số nhà cung cấp (Nokia và Juniper cung cấp giải pháp chìa khóa trao tay rất tốt) - cho đám mây Viễn thông. Tôi sẽ không sử dụng Openstack cho CNTT thuần túy - nó giống như bắn chim sẻ bằng đại bác, nhưng tôi không thấy bất kỳ chống chỉ định nào đối với việc sử dụng nó ngoài tính dư thừa. Tuy nhiên, sử dụng VMWare trong viễn thông cũng giống như việc vận chuyển đá dăm trên chiếc Ford Raptor - nhìn từ bên ngoài thì đẹp nhưng người lái xe phải thực hiện 10 chuyến thay vì một chuyến.
Theo tôi, nhược điểm lớn nhất của VMWare là tính khép kín hoàn toàn của nó - công ty sẽ không cung cấp cho bạn bất kỳ thông tin nào về cách thức hoạt động của nó, chẳng hạn như vSAN hoặc những gì có trong kernel hypervisor - đơn giản là nó không mang lại lợi nhuận cho nó - tức là bạn sẽ không bao giờ trở thành chuyên gia về VMWare - nếu không có sự hỗ trợ của nhà cung cấp, bạn sẽ thất bại (tôi rất thường xuyên gặp các chuyên gia VMWare, những người bối rối trước những câu hỏi tầm thường). Đối với tôi, VMWare đang mua một chiếc ô tô có khóa mui - vâng, bạn có thể có các chuyên gia có thể thay dây đai thời gian, nhưng chỉ người bán cho bạn giải pháp này mới có thể mở mui xe. Cá nhân tôi không thích những giải pháp mà tôi không thể phù hợp. Bạn sẽ nói rằng bạn có thể không cần phải đi dưới mui xe. Vâng, điều này là có thể, nhưng tôi sẽ xem xét bạn khi bạn cần tập hợp một chức năng lớn trên đám mây từ 20-30 máy ảo, 40-50 mạng, một nửa trong số đó muốn ra ngoài và nửa còn lại yêu cầu Khả năng tăng tốc SR-IOV, nếu không bạn sẽ cần thêm vài chục chiếc xe như vậy - nếu không thì hiệu suất sẽ không đủ.
Có những quan điểm khác, vì vậy chỉ có bạn mới có thể quyết định nên chọn gì và quan trọng nhất là khi đó bạn sẽ phải chịu trách nhiệm về lựa chọn của mình. Đây chỉ là ý kiến của tôi - một người đã từng nhìn và chạm vào ít nhất 4 sản phẩm - Nokia, Juniper, Red Hat và VMWare. Đó là, tôi có một cái gì đó để so sánh.
Nguồn: www.habr.com