TÓM TẮT
Tôi phát triển chương trình giả lập mạng
kể từ năm 2011, và thậm chí nếu tôi không phải là lập trình viên, tôi có thể
nói tôi đã làm một công việc tốt, đặt iou-web (lúc đầu) và UNetLab (cuối cùng) là
một đối thủ cạnh tranh tốt của GNS3 và VIRL mà không Bất kỳ ngân sách nào.
Dưới đây bạn có thể đọc một bản tóm tắt
ngắn gọn về phần mềm của tôi và kiến trúc của UNetLabv2.
Về cơ bản UNetLabv2 có các tính năng
giống UNetLab và cải tiến:
- Hàng ngàn nodes cho mỗi phòng thí nghiệm;
- Phòng thí nghiệm phân bố giữa hàng chục nodes vật lý hoặc
ảo;
- Phòng thí nghiệm chạy không giới hạn cho mỗi người
dùng;
- Hỗ trợ cho Ansible / NAPALM / ... các công cụ tự động
hóa
CÁC WEBIOL / IOU-WEB / UNL / UNETLAB / EVE-NG TRƯỚC ĐÂY
Vào cuối năm 2011, tôi cần một công cụ
để mô phỏng mạng. Điều kiện tiên quyết là:
- Tính di động: phòng thí nghiệm phải được exportable và
importable;
- Sự ổn định: chạy lab phải ổn định, tránh va chạm;
- Hiệu suất: các phòng thí nghiệm phải có khả năng chạy
vào một máy tính xách tay giá rẻ hoặc vào máy ảo.
GNS3 là lựa chọn duy nhất có sẵn, và nó
không thể đáp ứng tất cả các điều kiện tiên quyết. Tôi quyết định phát triển
một phần mềm mô phỏng mạng mới dựa trên IOL (IOS trên Linux, bởi
Cisco). Tôi biết nhiều người của Cisco, và tôi muôn trở thành thành viên của
gia đình Cisco, sớm hay muộn. Trong thời gian chờ đợi tôi nhận ra Cisco
phát triển nội bộ một phần mềm tương tự, được gọi là WebIOL.
WebIOL được phát triển trong Perl và chỉ
dành cho các nhà tuyển dụng của Cisco. Nó chứa một số phòng thí nghiệm cơ
bản từ chương trình Cisco 360.
Sau một vài phiên bản alpha, vào ngày
23 tháng 1 năm 2012 iou-web đã được phát hành ra công chúng. Iou-web
(không phải webiou hoặc web-iou) được phát triển bằng PHP và chỉ trong vài
tháng đã đếm được hàng trăm người dùng trên toàn thế giới. Nếu GNS3 hỗ trợ
thực IOSes chỉ (thông qua Dynamips), iou-web được hỗ trợ IOL chỉ. Nhưng vì
IOL nhanh hơn Dynamips nên nhiều người sử dụng đã thích iou-web.
Trong năm 2013 tôi nhận ra iou-web quá
hạn chế, tôi cần một cách "thống nhất" để mô phỏng mạng, bao gồm tường
lửa, cân bằng tải và vân vân. Hơn nữa multicasting sử dụng IOL đã được
nghe trộm. Tôi đã có nhiều điều kiện tiên quyết hơn:
- Bao gồm các thiết bị ảo của nhà cung cấp trong phòng
thí nghiệm;
- Bao gồm IOS thực trong phòng thí nghiệm;
- Bao gồm (có thể) giả lập từ các nhà cung cấp khác nhau;
- Đa người dùng.
Tôi đã viết lại iou-web để tạo một hệ
thống mô phỏng mạng mở rộng. Ý tưởng là:
- Mỗi nút (thiết bị mô phỏng) phải được gắn vào một lớp
chung;
- Một lớp phổ biến tốt đẹp có thể là một cầu Ethernet
Ethernet (OVS cũng được hỗ trợ). Vào ngày 06 tháng 10 (2014) UNetLab
đã được phát hành ra công chúng. Được phát triển trong PHP bằng cách
sử dụng khuôn khổ API REST và ứng dụng một trang (jQuery). Trong vài
tháng tôi đã có thể tính từ 5-6 trăm người dùng hàng ngày. Tôi sẽ đặt
tên nó là UNL, nhưng trang web không phải là miễn phí.
Ban đầu tôi đã có ý tưởng bao gồm
Huawei eNSP, nhưng vì các nút eNSP mong đợi một chuỗi cụ thể, không ai có thể
chạy các nút eNSP bên ngoài eNSP.
Từ năm 2015, tôi đã không có thời gian
rảnh rỗi cho UNetLab, vì vậy một nhóm những người đã chia UNetLab và EVE-NG vào
ngày 5 tháng 1 năm 2017 đã được công bố rộng rãi nhưng đó là một câu chuyện
khác vì tôi không thuộc EVE- Đội NG.
TẠI SAO CẦN CÓ UNETLABV2
Trong hai năm qua, trọng tâm của tôi
chuyển sang tự động hóa mạng, và bây giờ tôi vẫn cần một nền tảng mô phỏng mạng
thống nhất nhưng các điều kiện tiên quyết đã thay đổi. Nhưng trước đó, hãy
để tôi chỉ ra giới hạn UNetLab:
- Mỗi giới hạn máy chủ lưu trữ: hiện tại mỗi máy chủ có
thể chạy đến 256 phụ độc lập, vì giới hạn cổng điều khiển;
- Mỗi nút thí nghiệm giới hạn: hiện tại mỗi pod / lab có
thể chạy đến 128-1 nút, bởi vì giới hạn cổng console;
- Mỗi giới hạn của người dùng: hiện tại mỗi người dùng có
thể chạy lên đến một pod / lab một thời gian, bởi vì giới hạn cổng
console;
- Chỉ một máy chủ: hiện tại không có cách nào để thực hiện
cài đặt phân phối UNetLab (OVS có thể được sử dụng nhưng nhiều loại khung
được lọc theo mặc định);
- Config quản lý: nhận và đặt cấu hình khởi động được thực
hiện thông qua các kịch bản mong đợi, chúng chậm, không tiên đoán, và
không thể bao gồm tất cả các loại nút;
- Các giao diện nối tiếp Dynamips không được hỗ trợ;
- Không được phép thay đổi tô pô được phép trong khi
phòng thí nghiệm đang chạy, theo thiết kế.
Giới hạn cổng điều khiển xảy ra bởi vì
mỗi nút điều khiển đều có cổng cố định, được tính như sau: ts_port = 32768 +
128 * tenant_id + device_id. Hơn nữa, không có hơn 512 nút IOL có thể chạy
bên trong cùng phòng thí nghiệm vì device_id phải là duy nhất cho mỗi người
thuê.
Vì vậy, UNetLab v2 phải có khả năng:
- Chạy một phòng thí nghiệm phân tán (giữa các nút cục bộ
hoặc vùng địa lý);
- Chạy thử nghiệm với một số không giới hạn các nút;
- Cho phép mỗi người dùng tuỳ chỉnh một phòng thí nghiệm
mà không ảnh hưởng đến bản gốc;
- Liên kết giao diện nối tiếp giữa IOL và Dynamips;
- Cấu hình các nút thông qua Ansible / NAPALM / bất cứ điều
gì.
Tôi biết làm thế nào để thực hiện một
mô phỏng mạng phân phối, nhưng tôi nhớ một chút: làm thế nào để dễ dàng chạy
các nút trong một không gian tên chuyên dụng? Tôi nhận câu trả lời từ
vrnetlab: sử dụng Docker.
Do các giới hạn của UNetLab, tôi lại muốn
viết lại UNetLab từ đầu. Ngay cả khi EVE-NG là một nĩa UNetLab, đội EVE-NG
đang nỗ lực để khắc phục những giới hạn được mô tả trước đây.
KIẾN TRÚC UNETLABV2
Kiến trúc có thể có vẻ phức tạp một
chút, nhưng điều đó không đúng, tôi đã có thể thực hiện nó một mình và trong một
khoảng thời gian tương đối ngắn.
UNetLabv2 dựa trên:
- Docker: bộ điều khiển, bộ định tuyến và các nút thí
nghiệm chạy bên trong một container Docker;
- Python: không còn C, PHP hay Bash, chỉ Python 3;
- Python-Flask + NGINX triển khai và trình bày các API;
- Kiểm chứng lưu trữ đã lưu trong Memcached cho trải nghiệm
người dùng tốt hơn;
- Celery + Redis quản lý các tác vụ dài không đồng bộ
trong nền;
- MariaDB lưu trữ tất cả các dữ liệu / người sử dụng và
chạy các phòng thí nghiệm;
- Git lưu trữ các phòng thí nghiệm ban đầu với một điều
khiển phiên bản;
- JQuery + Bootstrap sẽ triển khai UI như một ứng dụng
trang đơn;
- Iptables + Linux bridge cho phép kết nối với các nút
lab chỉ bắt đầu bằng SSH;
- IOL, QEMU và Dynamips chạy các nút trong phòng thí nghiệm.
Một cụm UNetLabv2 phải có ít nhất một
nút: nó có thể là một hệ thống vật lý hoặc một ảo. Mỗi nút UNetLabv2 chạy
Docker: nút UNetLabv2 đầu tiên là master và chứa một bộ điều khiển và một
router, mỗi nút UNetLabv2 bổ sung chỉ có một router. Mỗi nút UNetLabv2 chạy
nhiều nút trong phòng thí nghiệm. Bộ điều khiển, bộ định tuyến và các nút
trong phòng thí nghiệm là các trường hợp Docker.
Bộ điều khiển container:
- Trình bày giao diện người dùng và API cho khách hàng, bộ
định tuyến và các nút trong phòng thí nghiệm;
- Nhận yêu cầu đăng ký từ các bộ định tuyến và các nút
trong phòng thí nghiệm;
- Cung cấp và quản lý các nút thí nghiệm thông qua các bộ
định tuyến;
- Liên lạc các nút thí nghiệm thông qua Ansible / NAPALM
/ ... qua các bộ định tuyến;
- Cung cấp bảng định tuyến cho các bộ định tuyến;
- Có thể đạt được thông qua SSH sử dụng cổng 2222.
Các bộ định tuyến router:
- Đăng ký chống lại bộ điều khiển;
- Phơi bày Docker Remote API;
- Phơi bày API phòng thí nghiệm;
- Lấy router và bảng định tuyến từ bộ điều khiển;
- Định tuyến các gói tin phòng thí nghiệm giữa các nút và
bộ định tuyến;
- Cho phép truy cập giữa bộ điều khiển và các nút thí
nghiệm từ xa thông qua OpenVPN.
Các nút chứa:
- Đăng ký chống lại bộ điều khiển;
- Chạy nút giả lập (IOL, Dynamips hoặc QEMU);
- Gắn một giao diện quản lý của lưu ý mô phỏng với một
cây cầu địa phương;
- Tuyến đường và các gói tin sNAT / dNAT đến giao diện quản
lý của nút giả lập;
- Các gói tin tuyến đường giữa router cục bộ và nút mô phỏng
cho các giao diện không quản lý;
- Quản lý liên kết mô phỏng (lên / xuống).
Bởi vì bộ điều khiển và bộ định tuyến
biết địa chỉ IP bên trong và bên ngoài; Người dùng có thể triển khai các
nút UNetLabv2 bất cứ nơi nào họ muốn (trong cùng một mạng LAN, trong AWS,
Google Compute Engine, Azure, sau tường lửa ...). Như sơ đồ trên giải
thích, mỗi cụm UNetLabv2 cần các cổng sau:
- TCP: 2222 để kết nối với bộ điều khiển thông qua SSH;
- TCP: 80/443 cho yêu cầu HTTP / HTTPS đến bộ điều khiển;
- TCP: 5443 cho yêu cầu HTTPS đến router;
- UDP: 5005 cho các gói tin định tuyến giữa các nút
UNetLabv2 khác nhau;
- UDP: 1194 cho khả năng truy cập mạng giữa bộ điều khiển
và các nút phòng thí nghiệm từ xa.
UNetLabv2 hiện đã gần
như đã sẵn sàng, ngoại trừ giao diện web và OpenVPN. Nó không có sẵn cho
công chúng, nó không dùng cho mục đích thương mại và nó không phải là đối thủ của
GNS3, VIRL hay EVE-NG. Nó chỉ là một công cụ tôi phát triển cho bản thân
mình, cũng có sẵn cho những người dùng được bầu và bạn bè.
Nguồn : http://www.routereflector.com/unetlab/
)
