Các doanh nghiệp thường bắt đầu hành trình của mình bằng cách lưu trữ lại (nâng và chuyển) khối lượng công việc tại chỗ của họ vào AWS và chạy các phiên bản Amazon Elastic Compute Cloud (Amazon EC2)). Một cách đơn giản hơn để lưu trữ lại là sử dụng AWS Application Migration Service (Application Migration Service), một dịch vụ di chuyển gốc đám mây.
Để sắp xếp hợp lý và đẩy nhanh quá trình di chuyển, hãy tự động hóa các mẫu di chuyển có thể sử dụng lại hoạt động cho nhiều ứng dụng. Application Migration Service là dịch vụ di chuyển được đề xuất để nâng và chuyển các ứng dụng của bạn sang AWS.
Trong bài đăng trên blog này, chúng tôi khám phá các biến chính góp phần vào tốc độ sao chép của máy chủ khi sử dụng Dịch vụ di chuyển ứng dụng. Chúng tôi cũng sẽ xem xét các bài kiểm tra bạn có thể chạy để xác định những tắc nghẽn này và, nếu thích hợp, bao gồm các bước khắc phục.
Tổng quan về quá trình di chuyển bằng Application Migration Service
Hình 1 mô tả luồng sao chép dữ liệu end-to-end từ máy chủ nguồn đến máy đích được lưu trữ trên AWS. Sơ đồ được thiết kế để giúp hình dung các điểm nghẽn tiềm ẩn trong luồng dữ liệu, được biểu thị bằng một viên kim cương đen.
Hình 1. Luồng dữ liệu khi sử dụng AWS Application Migration Service (kim cương đen biểu thị các điểm cạnh tranh tiềm năng)
Thử nghiệm cơ bản
Để xác định tốc độ sao chép đường cơ sở, chúng tôi khuyên bạn nên thực hiện kiểm tra kiểm soát giữa Vùng AWS mục tiêu của bạn và Vùng gần nhất với khối lượng công việc nguồn của bạn. Ví dụ: nếu khối lượng công việc nguồn của bạn nằm trong trung tâm dữ liệu ở Rome và Khu vực mục tiêu của bạn là Paris, hãy chạy thử nghiệm giữa eu-south-1 (Milan) và eu-west-3 (Paris). Điều này sẽ cung cấp giới hạn băng thông trên lý thuyết, vì quá trình sao chép sẽ xảy ra trên đường trục AWS. Nếu Vùng mục tiêu đã là Vùng gần nhất với khối lượng công việc nguồn của bạn, hãy chạy thử nghiệm từ trong cùng Vùng đó.
Kết nối
Có một số cách để thiết lập kết nối giữa vị trí on-premises của bạn và AWS Region:
- Internet công cộng
- VPN
- AWS Direct Connect
Phần này liên quan đến các tùy chọn 1 và 2. Nếu gặp phải các vấn đề về tốc độ sao chép, nơi đầu tiên cần xem xét là băng thông mạng. Từ một máy nguồn trong mạng nội bộ của bạn, hãy chạy kiểm tra tốc độ để tính toán băng thông của bạn ra internet; các nhà cung cấp thử nghiệm phổ biến bao gồm Cloudflare, Ookla, and Google. Đây là băng thông của bạn với internet, không phải AWS.
Tiếp theo, để xác nhận luồng dữ liệu từ bên trong trung tâm dữ liệu của bạn, hãy chạy traceroute (Windows) hoặc tracert (Linux). Xác định bất kỳ bước nhảy mạng nào bất thường hoặc có khả năng làm giảm băng thông (do giới hạn phần cứng hoặc cấu hình).
Để đo băng thông tối đa giữa trung tâm dữ liệu của bạn và mạng con AWS đang được sử dụng để sao chép dữ liệu, đồng thời tính đến việc đóng gói Lớp cổng bảo mật (SSL), hãy sử dụng CloudEndure SSL bandwidth tool (tham khảo Hình 1).
Source storage I/O
Khu vực tiếp theo để tìm các nút thắt về nhân bản là lưu trữ nguồn. Việc lưu trữ cơ bản cho các máy chủ có thể là một điểm gây tranh cãi. Nếu bộ nhớ đạt tốc độ đọc tối đa, điều này sẽ ảnh hưởng đến tốc độ sao chép dữ liệu. Nếu I / O bộ nhớ của bạn được sử dụng nhiều, nó có thể ảnh hưởng đến việc nhân rộng khối bằng Application Migration Service. Để đo tốc độ lưu trữ, bạn có thể sử dụng các công cụ sau:
- Windows: WinSat (hoặc công cụ của bên thứ ba khác, như AS SSD Benchmark)
- Linux: hdparm
Chúng tôi gợi ý bạn nên giảm các thao tác đọc / ghi trên bộ nhớ nguồn khi bắt đầu di chuyển bằng Application Migration Service.
Application Migration Service EC2 replication instance size
Kích thước của phiên bản máy chủ nhân bản EC2 cũng có thể ảnh hưởng đến tốc độ sao chép. Mặc dù bạn nên giữ kích thước phiên bản mặc định (t3.small), nhưng nó có thể được tăng lên nếu có các yêu cầu kinh doanh, chẳng hạn như để tăng tốc độ đồng bộ hóa dữ liệu ban đầu. Lưu ý: việc sử dụng phiên bản lớn hơn có thể dẫn đến tăng chi phí tính toán.
Những thay đổi về phiên bản sao chép phổ biến bao gồm:
- Máy chủ có <26 đĩa: thay đổi kiểu phiên bản thành m5.large. Tăng loại phiên bản lên m5.xlarge hoặc cao hơn, nếu cần.
- Máy chủ có <26 đĩa (hoặc máy chủ trong Khu vực AWS không hỗ trợ loại phiên bản m5): thay đổi loại phiên bản thành m4.large. Tăng lên m4.xlarge hoặc cao hơn, nếu cần.
Lưu ý: Việc thay đổi kiểu phiên bản máy chủ nhân bản sẽ không ảnh hưởng đến việc nhân bản dữ liệu. Sao chép dữ liệu sẽ tự động bắt đầu từ nơi nó dừng lại, bằng cách sử dụng kiểu phiên bản mới mà bạn đã chọn.
Application Migration Service Elastic Block Store replication volume
Bạn có thể tùy chỉnh loại khối lượng Amazon Elastic Block Store (Amazon EBS) được sử dụng bởi từng đĩa trong mỗi máy chủ nguồn trong cài đặt của máy chủ nguồn đó (change staging disk type).
Theo mặc định, các đĩa có dung lượng <500GiB sử dụng Magnetic HDD volumes. Phương pháp hay nhất của AWS khuyên bạn không nên thay đổi kiểu Amazon EBS volume mặc định, trừ khi có nhu cầu kinh doanh. Tuy nhiên, vì chúng tôi muốn tăng tốc độ sao chép, chúng tôi chủ động thay đổi kiểu EBS volume mặc định.
Có hai tùy chọn để lựa chọn:
- Tuỳ chọn lower cost, Throughput Optimized HDD (st1) sử dụng các đĩa chậm hơn, ít tốn kém hơn.
- Hãy xem xét tùy chọn này nếu bạn:
- Muốn giữ chi phí thấp
- Đĩa lớn không thay đổi thường xuyên
- Không quan tâm đến quá trình đồng bộ hóa ban đầu sẽ mất bao lâu
- Tuỳ chọn faster, General Purpose SSD (gp2) sử dụng các đĩa nhanh hơn nhưng đắt hơn.
- Hãy xem xét tùy chọn này nếu bạn:
- Máy chủ nguồn có các đĩa có tốc độ ghi cao hoặc nếu bạn cần hiệu suất nhanh hơn nói chung
- Muốn tăng tốc quá trình đồng bộ ban đầu
- Sẵn sàng trả nhiều hơn cho tốc độ
Source server CPU
The Application Migration Service được cài đặt trên máy nguồn để sao chép dữ liệu sử dụng một lõi trong hầu hết các trường hợp (các luồng tác nhân có thể được lập lịch cho nhiều lõi). Nếu việc sử dụng lõi đạt mức tối đa, đây có thể là một hạn chế đối với tốc độ sao chép. Để kiểm tra việc sử dụng cốt lõi:
- Windows: Khởi chạy ứng dụng Task Manager trong Windows và nhấp vào tab “CPU”. Nhấp chuột phải vào biểu đồ CPU (biểu đồ này hiện đang hiển thị trung bình số lõi) > chọn “Change graph to” > “Logical processors”. Điều này sẽ hiển thị các lõi riêng lẻ và mức sử dụng hiện tại của chúng (Hình 2).
Hình 2. Bộ xử lý logic sử dụng CPU
Linux: Cài đặt htop và chạy từ thiết bị đầu cuối. Lệnh htop sẽ hiển thị quy trình Application Migration Service/CE và cho biết tỷ lệ sử dụng CPU và bộ nhớ (đây là của toàn bộ máy). Bạn có thể kiểm tra các thanh CPU để xác định xem CPU có đang được chạy tối đa hay không (Hình 3).
Hình 3: Quá trình AWS Application Migration Service/CE để đánh giá việc sử dụng CPU
Kết luận
Trong bài đăng này, chúng tôi đã khám phá một số biến chính góp phần vào tốc độ sao chép của máy chủ khi sử dụng Application Migration Service. Chúng tôi khuyến khích bạn khám phá các khu vực chính này trong quá trình di chuyển để xác định xem tốc độ sao chép của bạn có thể được tối ưu hóa hay không.
Thông tin liên quan
Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.
AWS Study Group 