Bài viết này được viết bởi Mark Rogers, SDE II – Kỹ sư khách hàng AWS.

Trong phần 1, tôi đã hướng dẫn bạn cách chạy Apache CloudStack với KVM trên một máy chủ Amazon Elastic Compute Cloud (Amazon EC2) đơn lẻ. Thiết lập đơn giản này rất phù hợp để thử nghiệm và tải trọng nhẹ. Trong bài đăng này, mọi thứ sẽ trở nên thú vị hơn nhiều. Tôi sẽ chỉ cho bạn cách tạo một mạng chồng lên trong Amazon Virtual Private Cloud (Amazon VPC) của bạn, cho phép CloudStack mở rộng theo chiều ngang trên nhiều instance EC2. Phương pháp này cũng có thể hoạt động với các hypervisor khác.

Nếu bạn chưa đọc phần 1, hãy bắt đầu với phần 1. Nó giải thích tại sao cấu hình mạng này là cần thiết. Các tiên quyết giống nhau cho cả hai phần.

Làm cho việc trở nên dễ dàng hơn

Tôi đã viết một số script để tự động hóa cài đặt CloudStack và cấu hình hệ điều hành trên CentOS 7. Bạn có thể tùy chỉnh chúng để đáp ứng nhu cầu của mình. Tôi cũng đã viết một số mẫu AWS CloudFormation để bạn có thể sao chép để tạo một môi trường demo. Tệp README có thêm chi tiết.

Phương pháp có khả năng mở rộng

Nhóm của chúng tôi đã bắt đầu sử dụng một trường hợp EC2 đơn, như đã mô tả trong bài viết trước đó của tôi. Nó đã hoạt động ban đầu, nhưng không có khả năng chúng tôi cần. Chúng tôi bị giới hạn trong vài chục máy ảo (VMs), nhưng chúng tôi cần hàng trăm. Chúng tôi cũng cần mở rộng lên và thu hẹp khi nhu cầu thay đổi của chúng tôi. Điều này có nghĩa là chúng tôi cần có khả năng thêm và xóa các máy chủ CloudStack. Sử dụng một Linux bridge làm mạng con ảo không còn đủ.

Để hỗ trợ việc thêm máy chủ, chúng ta cần một mạng con mà trải dài trên nhiều trường hợp. Giải pháp mà tôi tìm thấy là Virtual Extensible LAN (VXLAN). Nó nhẹ, dễ cấu hình và được bao gồm trong kernel Linux. VXLAN tạo ra một mạng chồng lớp 2 trừu tượng hóa chi tiết của mạng dưới. Nó cho phép các máy tính ở các phần khác nhau của mạng giao tiếp như thể tất cả đều được kết nối với một công tắc mạng đơn giản giống nhau.

Một ví dụ khác về mạng chồng lớp là Amazon VPC. Nó hoạt động giống như một mạng vật lý, nhưng thực tế là một lớp trên các mạng khác. Có tới mức mạng. VXLAN cung cấp một lớp trên cùng mà CloudStack có thể ngồi thoải mái, xử lý tất cả nhu cầu VM của bạn, một cách không cần biết về thế giới bên dưới nó.

Mạng chồng giúp cải thiện nhiều điểm mạnh. Cải tiến lớn nhất là bạn có thể có nhiều máy chủ, cho phép mở rộng theo chiều ngang. Có nhiều máy chủ không chỉ mang lại cho bạn sức mạnh tính toán hơn, mà còn cho phép bạn thực hiện bảo trì theo cách cuộn. Thay vì đặt cơ sở dữ liệu và lưu trữ tập tin trên máy chủ quản lý, tôi sẽ chỉ cho bạn cách sử dụng Amazon Elastic File System (Amazon EFS) và Amazon Relational Database Service (Amazon RDS) để có được bộ nhớ lưu trữ mở rộng và đáng tin cậy.

Các Instance EC2

Chúng ta bắt đầu với ba Instance Amazon EC2. Một Instance sẽ làm tường lửa giữa mạng overlay và Amazon VPC của bạn, Instance thứ hai sẽ là máy chủ quản lý CloudStack của bạn, và Instance thứ ba sẽ là máy chủ chứa các máy ảo của bạn. Bạn cũng cần một cách để kết nối với các Instance của bạn, chẳng hạn như một bastion host hoặc một điểm kết nối VPN.

VXLAN phải gửi và nhận multicast. Chỉ các instance Nitro mới có thể là người gửi multicast. Khi bạn lên kế hoạch, hãy xem danh sách các loại instance Nitro.

Bộ định tuyến sẽ không cần quá nhiều năng lượng tính toán, nhưng nó sẽ cần đủ băng thông mạng để đáp ứng nhu cầu của bạn. Nếu bạn đặt Amazon EFS trong cùng một mạng con như các instance của bạn, thì chúng sẽ trực tiếp giao tiếp với nó, giảm tải cho bộ định tuyến. Hãy quyết định bao nhiêu băng thông mạng bạn muốn và chọn loại instance Nitro phù hợp.

Sau khi tạo instance định tuyến, cấu hình AWS để sử dụng nó như một bộ định tuyến. Ngừng kiểm tra nguồn/đích trong các thiết lập mạng của instance. Sau đó, cập nhật các bảng định tuyến AWS tương ứng để sử dụng bộ định tuyến làm mục tiêu cho mạng chồng lên. Bảng an ninh của bộ định tuyến cần cho phép khối đầu vào đến CloudStack UI (cổng TCP 8080) và bất kỳ dịch vụ nào bạn định cung cấp từ các VM.

Đối với máy chủ quản lý, bạn sẽ muốn sử dụng một loại instance Nitro. Nó sẽ sử dụng nhiều CPU hơn bộ định tuyến của bạn, vì vậy hãy lên kế hoạch cho phù hợp.

Ngoài việc là loại Nitro, instance máy chủ còn phải là metal type. Các instance metal có hỗ trợ ảo hóa phần cứng, điều này là cần thiết cho KVM. Nếu bạn có một tài khoản AWS mới với giới hạn vCPU trên-demand thấp, hãy xem xét bắt đầu với m5zn.metal, có 48 vCPU. Nếu không, tôi đề xuất điều đó trực tiếp đến c5.metal vì nó cung cấp 96 vCPU với giá tương tự. Có các loại lớn hơn tùy thuộc vào nhu cầu tính toán, ngân sách và giới hạn vCPU của bạn. Nếu giới hạn vCPU trên-demand của tài khoản của bạn quá thấp, thì bạn có thể gửi yêu cầu hỗ trợ để nó được tăng lên.

Mạng

Tất cả các instances nên được đặt trên một subnet riêng. Chia sẻ subnet với các instances khác có thể gây ra các vấn đề giao tiếp. Ví dụ, tham khảo hình sau đây. Subnet có một instance có tên TroubleMaker không nằm trên mạng overlay. Nếu TroubleMaker gửi yêu cầu đến địa chỉ mạng overlay của instance quản lý, thì sau đây là những gì xảy ra:

1. Yêu cầu đi qua subnet AWS đến router.
2. Router chuyển tiếp yêu cầu thông qua mạng overlay.
3. Instance quản lý CloudStack có kết nối với cùng subnet AWS mà TroubleMaker đang sử dụng. Do đó, nó trả lời trực tiếp thay vì sử dụng router. Đây không phải là đường trả lời mà AWS mong đợi, vì vậy phản hồi sẽ bị loại bỏ.

Nếu bạn di chuyển TroubleMaker sang một subnet khác, thì các yêu cầu và phản hồi sẽ đi qua router. Điều đó sẽ khắc phục các vấn đề giao tiếp.

Các instance trong mạng chồng lớp sẽ sử dụng các giao diện đặc biệt làm điểm cuối đầu cuối VXLAN tunnel (VTEP). Các VTEP phải biết cách liên lạc với nhau thông qua mạng chồng lớp dưới. Bạn có thể thủ công cung cấp cho mỗi instance một danh sách của tất cả các instance khác, nhưng đó là một cơn ác mộng về bảo trì. Tốt hơn hết là để các VTEP phát hiện lẫn nhau, điều đó có thể được thực hiện bằng cách sử dụng multicast. Bạn có thể thêm hỗ trợ multicast bằng AWS Transit Gateway.

Sau đây là các bước để làm cho multicasts của VXLAN hoạt động:

1. Kích hoạt hỗ trợ multicast khi tạo cổng thông tuyến.
2. Gắn cổng thông tuyến vào mạng con của bạn.
3. Tạo miền multicast cổng thông tuyến với hỗ trợ IGMPv2 được kích hoạt.
4. Liên kết miền multicast với mạng con của bạn.
5. Cấu hình giao diện eth0 trên mỗi trường hợp để sử dụng IGMPv2. Đoạn mã mẫu sau đây cho thấy cách thực hiện điều này.
6. Đảm bảo các nhóm bảo mật của trường hợp của bạn cho phép tiến trình truy vấn IGMP (giao thức 2 lưu lượng từ 0.0.0.0/32) và lưu lượng VXLAN (UDP cổng 4789 từ các trường hợp khác) đi vào.

Các máy ảo CloudStack phải kết nối với cùng một bridge như giao diện VXLAN. Như đã đề cập trong bài trước, CloudStack quan tâm đến tên. Tôi khuyên bạn nên đặt tên cho giao diện bắt đầu bằng “eth”. Hơn nữa, quy ước đặt tên này cho biết với CloudStack cần sử dụng bridge nào, do đó tránh cần phải sử dụng một giao diện giả như trong thiết lập đơn giản.

Đoạn mã sau cho thấy cách tôi cấu hình mạng trong CentOS 7. Bạn phải cung cấp các giá trị cho các biến sau:

• $ overlay_host_ip_address, $ overlay_netmask và $ overlay_gateway_ip: Sử dụng các giá trị cho mạng overlay mà bạn đang tạo.
• $ dns_address: Tôi khuyên nên sử dụng cơ sở của phạm vi mạng IPv4 VPC, plus two. Bạn không nên sử dụng 169.654.169.253 vì CloudStack dành địa chỉ link-local cho việc sử dụng của riêng mình.
• $ multicast_address: Địa chỉ multicast mà bạn muốn VXLAN sử dụng. Chọn một cái gì đó trong phạm vi multicast mà không xung đột với bất cứ thứ gì khác. Tôi khuyên chọn từ dải phạm vi cục bộ IPv4 (239.255.0.0/16).
• $ interface_name: Tên giao diện mà VXLAN nên sử dụng để giao tiếp với mạng vật lý. Thông thường đây là eth0.

Một vài bước khác nhau đối với instance định tuyến so với các instance khác. Chú ý đến các comment!

yum install -y bridge-utils net-tools

# IMPORTANT: Omit the GATEWAY setting on the router instance!

cat << EOF > /etc/sysconfig/network-scripts/ifcfg-cloudbr0

DEVICE=cloudbr0

TYPE=Bridge

ONBOOT=yes

BOOTPROTO=none

IPV6INIT=no

IPV6_AUTOCONF=no

DELAY=5

STP=no

USERCTL=no

NM_CONTROLLED=no

IPADDR=$overlay_host_ip_address

NETMASK=$overlay_netmask

DNS1=$dns_address

GATEWAY=$overlay_gateway_ip

EOF

cat << EOF > /sbin/ifup-local

#!/bin/bash

# Set up VXLAN once cloudbr0 is available.

if [[ \$1 == “cloudbr0” ]]

then

    ip link add ethvxlan0 type vxlan id 100 dstport 4789 group “$multicast_address” dev “$interface_name”

    brctl addif cloudbr0 ethvxlan0

    ip link set up dev ethvxlan0

fi

EOF

chmod +x /sbin/ifup-local

# Transit Gateway requires IGMP version 2

echo “net.ipv4.conf.$interface_name.force_igmp_version=2” >> /etc/sysctl.conf

sysctl -p

# Enable IPv4 forwarding

# IMPORTANT: Only do this on the router instance!

echo ‘net.ipv4.ip_forward=1’ >> /etc/sysctl.conf

sysctl -p

# Restart the network service to make the changes take effect.

systemctl restart network

Lưu trữ

Hãy xem xét về lưu trữ. Tạo cơ sở dữ liệu Amazon RDS bằng cách sử dụng động cơ MySQL 8.0 và đặt mật khẩu chính cho công cụ cài đặt cơ sở dữ liệu CloudStack sử dụng. Tham khảo tài liệu CloudStack để tìm các thiết lập MySQL mà bạn sẽ cần. Bạn có thể đặt các thiết lập trong một nhóm tham số RDS. Trong trường hợp bạn đang tự hỏi tại sao tôi không sử dụng Amazon Aurora, đó là bởi CloudStack cần động cơ lưu trữ MyISAM, không có sẵn trong Aurora.

Tôi đề xuất sử dụng Amazon EFS cho lưu trữ tệp. Để hiệu quả, hãy tạo một mục tiêu gắn kết trong mạng con với các thể hiện EC2 của bạn. Điều đó sẽ cho phép chúng trực tiếp giao tiếp với mục tiêu gắn kết, qua đó bỏ qua mạng chồng và bộ định tuyến. Lưu ý rằng các VM hệ thống sẽ sử dụng Amazon EFS qua bộ định tuyến.

Nếu bạn muốn, bạn có thể tổng hợp các hệ thống tệp CloudStack của mình. Chỉ cần tạo một hệ thống tệp đơn với các thư mục cho từng khu vực và loại lưu trữ. Ví dụ, tôi sử dụng các thư mục có tên /zone1/primary, /zone1/secondary, /zone2/primary, v.v. Bạn cũng nên xem xét cho phép thực hiện thông lượng được cung cấp trên hệ thống tệp, hoặc bạn có thể hết tín dụng nổ sau khi khởi động một vài máy ảo.

Một hậu quả của khả năng mở rộng của hệ thống tệp là lượng không gian trống (8 exabyte) sẽ gây ra tràn số nguyên trong CloudStack! Để tránh vấn đề này, giảm giá trị storage.overprovisioning.factor trong các thiết lập toàn cầu của CloudStack từ 2 xuống 1.

Khi môi trường của bạn đã sẵn sàng, hãy cài đặt CloudStack. Khi yêu cầu một cổng mặc định, hãy nhớ sử dụng địa chỉ mạng chồng lớp của bộ định tuyến. Khi bạn thêm một máy chủ, hãy đảm bảo rằng bạn sử dụng địa chỉ IP mạng chồng lớp của máy chủ.

Dọn dẹp

Nếu bạn đã sử dụng mẫu CloudFormation của tôi, hãy xóa ngăn xếp và loại bỏ bất kỳ mục nhập bảng định tuyến nào bạn đã thêm.

Nếu bạn không sử dụng CloudFormation, đây là những thứ cần xóa:

1. Các trường hợp Amazon EC2 CloudStack
2. Cơ sở dữ liệu Amazon RDS và nhóm tham số
3. Hệ thống tập tin Amazon EFS
4. Liên kết mạng con của lĩnh vực đa điểm trung tâm dịch vụ (Transit Gateway Multicast Domain) với các mạng con.
5. Multicast domain của cổng thông tin trung chuyển
6. Đính kèm VPC của cổng thông tin trung chuyển
7. Cổng thông tin trung chuyển
8. Các mục nhập bảng định tuyến mà bạn đã tạo
9. Các nhóm bảo mật mà bạn đã tạo cho các trường hợp, cơ sở dữ liệu và hệ thống tập tin

Kết luận

Phương pháp mà tôi chia sẻ có nhiều bước, nhưng chúng không khó khi bạn có một kế hoạch. Cho dù bạn cần một thiết lập đơn giản cho các thí nghiệm, hoặc bạn cần một môi trường có khả năng mở rộng cho việc di chuyển trung tâm dữ liệu, bạn hiện đã có một con đường phía trước. Hãy thử nó và bình luận ở đây về những điều bạn đã học được. Tôi hy vọng bạn sẽ thấy nó hữu ích và thú vị!

“Apache”, “Apache CloudStack” và “CloudStack” là nhãn hiệu của Quỹ phần mềm Apache.