Tin tức CÔNG TY CỔ PHẦN DỊCH VỤ CÔNG NGHỆ DATECH
Số 23E4 KĐT Cầu Diễn, Tổ 7, Phú Diễn, Bắc Từ Liêm, Hà Nội
Email: info@datech.vn
Danh mục sản phẩm
CÔNG TY CỔ PHẦN DỊCH VỤ CÔNG NGHỆ DATECH
Số 23E4 KĐT Cầu Diễn, Tổ 7, Phú Diễn, Bắc Từ Liêm, Hà Nội
Danh mục sản phẩm
Router 
Firewall 
Switch 
Wifi - Access Point 
Máy chủ ( Server ) 
Thiết bị lưu trữ NAS 
Networking Accessories 
Video Conference 
Vật tư mạng 
Tổng đài & điện thoại 
Bộ lưu điện UPS 
13/12/2021
13/12/2021
Danh sách nội dung [Ẩn]
Tất cả chúng ta đều biết nên tránh giờ cao điểm bất cứ khi nào có thể, nhưng trong cụm đào tạo AI, luôn là giờ cao điểm. Trong blog trước đây của chúng tôi về thiết kế cụm AI với tối ưu hóa đường ray trong Juniper Apstra, chúng tôi đã xem xét cách NVIDIA quy định cấu trúc liên kết để giảm thiểu độ trễ và tắc nghẽn giữa các đơn vị xử lý đồ họa (GPU). Công nghệ định vị đường ray của họ, cùng với cấu trúc liên kết cáp máy chủ này ở lớp truy cập trung tâm dữ liệu, giúp lưu lượng truy cập nhiều hơn trong “sọc” các máy chủ được kết nối bởi một nhóm thiết bị lá và tránh xa các liên kết kết cấu từ lá đến cột sống.
Giống như việc đi lại trên những con phố nhỏ hơn thường có thể thực hiện được bằng các phương tiện lái xe địa phương, đó không phải là giải pháp cho những khoảng cách xa hơn khi đường cao tốc luôn nhanh hơn. Vì vậy, giao thông liên dải cũng phải băng qua các đường cao tốc lớn của trung tâm dữ liệu Vải cột sống lá Clos. Và trong các cụm đào tạo, lưu lượng này luôn dày đặc.
Trong blog này, chúng tôi xem xét cách Juniper Networks tối ưu hóa lưu lượng truy cập cao luôn hiện hữu trong các phần này của kết cấu Clos để tránh tác động làm chậm của tắc nghẽn và giảm gói sẽ khiến khách hàng của chúng tôi mất thời gian đào tạo GPU và thời gian đưa ra thị trường.
Cấu trúc GPU-to-GPU của máy chủ AI được xây dựng với tốc độ truy cập 200G và 400G. Đây không phải là trung tâm dữ liệu đám mây thông thường của bạn. Các cụm đào tạo đắt tiền được xây dựng để đào tạo và chúng hoạt động không ngừng nghỉ. Các giai đoạn đào tạo và công việc như vậy, khi chúng được chia thành các nhiệm vụ nhỏ hơn, sử dụng nhiều kỹ thuật song song hóa cho phép GPU hoạt động gần như đạt mức sử dụng 100%. Tuy nhiên, họ cũng liên tục điều khiển mạng với mức sử dụng gần 100%.
Các mạng như vậy được xây dựng dưới dạng cấu trúc liên kết Clos với nhiều đường dẫn cách đều nhau từ mỗi nguồn đến đích. Vải gáy lá không được thiết kế với bất kỳ đăng ký vượt mức nào: có tỷ lệ bằng nhau giữa công suất của mỗi lá đối với máy chủ và gai. Trong những thiết kế như vậy, thoạt nhìn, tổng công suất trong kết cấu có đủ để phục vụ nhu cầu truy cập ở tốc độ tối đa. Tuy nhiên, tắc nghẽn vẫn xảy ra với incast khi nhiều nguồn làm quá tải một đích. Nguyên nhân khác gây tắc nghẽn là cân bằng tải.
Không phải là cân bằng từ ngữ tác dụng sao? Về lý thuyết thì có. Trong thực tế, nó có thể làm điều ngược lại.
Cấu hình cân bằng tải phổ biến là đa đường chi phí bằng nhau (ECMP). Đường dẫn từ lá này đến lá khác có thể đi qua bất kỳ thiết bị cột sống nào trong vải Clos, do đó cân bằng tải ECMP phân phối lưu lượng trên tất cả các cột. Nếu đối với mỗi gói, chúng tôi chọn một cột sống và lặp qua các bước nhảy tiếp theo đó trong một vòng lặp thì chúng tôi sẽ phân phối tải lưu lượng truy cập một cách hoàn hảo, không tính đến những khác biệt nhỏ về kích thước gói. Cơ chế tương tự cũng xuất hiện với đa đường có chi phí bằng nhau (ECMP) từ một nhánh xuống đến một lá đích khi có nhiều liên kết. Tuy nhiên, cái gọi là rải gói này chắc chắn sẽ dẫn đến các gói đến đích không theo thứ tự, điều này không thể chấp nhận được đối với các khía cạnh của khối lượng công việc đào tạo AI và hầu hết các Truy cập bộ nhớ trực tiếp từ xa (RDMA) tương tự khác qua lưu lượng Ethernet hội tụ (RoCEv2). Giám đốc quản lý sản phẩm cấp cao của chúng tôi, Dmitry Shokarev đã giải thích và chứng minh với lưu lượng RDMA, các loại lưu lượng phụ dễ tha thứ hơn có thể chấp nhận việc sắp xếp lại khi được thực hiện với sự hỗ trợ phần cứng trên thẻ bộ điều khiển giao diện mạng (NIC).
Để duy trì thứ tự gói, mỗi luồng được băm ngẫu nhiên để chọn một trong các bước nhảy tiếp theo. Và đây chính là lúc rắc rối nảy sinh vì, không giống như các trung tâm dữ liệu đám mây, nơi có nhiều luồng có quy mô và thời lượng khác nhau, việc đào tạo bằng mô hình AI tạo ra một số luồng có thời lượng dài và nhu cầu băng thông lớn.
Việc băm ngẫu nhiên tạo ra phân bố Poisson của các luồng. Đối với hầu hết mọi người, thật khó hiểu rằng một hàm băm ngẫu nhiên trên n liên kết bước nhảy tiếp theo có xác suất bằng nhau của m luồng có thể gây ra các điểm nóng lớn (tắc nghẽn) và các điểm lạnh (không có hoặc có ít lưu lượng truy cập). Hãy tưởng tượng rằng nếu n=m, chúng ta có 36% liên kết hoàn toàn không được sử dụng! May mắn thay, chúng tôi có nhiều luồng hơn liên kết, với số lượng ít nhất bằng GPU ngay cả trong trường hợp xấu nhất về mặt lý thuyết và nhiều lần như vậy trong thực tế. Tuy nhiên, cái gọi là dòng voi là rất lớn, vì vậy khi băm dẫn đến một liên kết không có đủ băng thông để xử lý thêm một con voi… hãy giả sử rằng phần yêu thích của voi trong cây (Clos “fat”) không phải là Thân cây.
Cân bằng tải động hoặc thích ứng (DLB / ALB) là một giải pháp cân bằng tải dựa trên luồng ECMP mới hơn, nhập vào chất lượng đường dẫn bước nhảy tiếp theo để xem xét các luồng đường dẫn. Nó sẽ thích các liên kết lạnh hơn các liên kết nóng hơn. Nói cách khác, nó thực sự có tính đến tải liên kết. Hơn nữa, DLB có thể định tuyến lại các luồng. Để tránh gây ra các gói không theo thứ tự khi định tuyến lại, công cụ chuyển tiếp gói sẽ theo dõi những gì được gọi là luồng nhỏ. Đây là các luồng gói liên tục trong luồng mà không bị ngắt dưới ngưỡng khoảng thời gian được định cấu hình.
Cũng cần lưu ý rằng DLB xử lý nhanh hơn khi xảy ra lỗi liên kết. Nó cũng tạo ra sự đa dạng của hàm băm trên các thiết bị. Sự đa dạng này rất quan trọng vì nếu quá trình băm nhất quán trên các thiết bị có số lượng đường dẫn bước nhảy tiếp theo nhất quán thì một lá gửi các luồng tới một cột sống sẽ dẫn đến việc cột sống băm các luồng tương tự đó sang một đường dẫn bước nhảy tiếp theo thay vì phân phối chúng. Sự phân cực băm này được tránh bằng DLB.
Với DLB, về cơ bản sẽ tránh được tình trạng tắc nghẽn cho đến khi có một luồng xuất hiện không thể vừa với bất kỳ liên kết nào và vào thời điểm đó, có khả năng là vải đã gần đạt đến khả năng chuyên chở tổng thể của nó. Vẫn có khả năng các thiết bị nhiều lá hội tụ lưu lượng truy cập trên một trục phải định tuyến đến một đích chung, nhưng xác suất xảy ra điều này thấp hơn nhiều.
Các cơ chế cân bằng tải toàn diện trong tương lai có và không có bộ điều khiển cũng nhằm mục đích giải quyết thách thức đó. Nhưng nếu việc rải gói với sắp xếp lại đích là khả thi đối với ngày càng nhiều lưu lượng truy cập và NIC, thì kết cấu sẽ được giữ đơn giản hơn trong khi tiến gần hơn đến công suất tối đa theo lý thuyết. Cuối cùng, có các phương pháp cân bằng tải từ đầu đến cuối hoàn toàn dựa trên NIC như SRD của Amazon cũng giúp kết cấu trở nên đơn giản. Một số cách tiếp cận này cho phép có cơ hội hội tụ nhiều kết cấu cụm AI mà không phải hy sinh nguy cơ tắc nghẽn. Không cần phải nói, Juniper Networks đang khám phá tất cả những cách tiếp cận này.
Cuối cùng, hãy xem Apstra có thể giúp định cấu hình DLB như thế nào. Giống như blog trước đây về thiết kế cấu trúc liên kết, chúng tôi cung cấp cách tự động hóa Apstra với cấu hình Terraform trong ví dụ thiết kế Juniper mã nguồn mở cho các cụm AI. Trong trường hợp này, Terraform bổ sung DLB vào bản thiết kế kết cấu GPU và bản thiết kế kết cấu lưu trữ vì cả hai đều được cho là sẽ có tương đối ít luồng lớn để tránh tắc nghẽn. Xem video này để biết bản demo Apstra của chúng tôi với cấu hình Terraform.
Các thiết kế tham chiếu Apstra chưa bao gồm các tùy chọn dựa trên mục đích gốc cho cài đặt DLB, vì vậy chúng tôi áp dụng một cấu hình để đặt cấu hình Junos tương đối đơn giản, cho Apstra biết cách hợp nhất tiện ích mở rộng cấu hình này vào cấu hình tham chiếu vàng cho các thiết bị đã chọn.
Trong blog tiếp theo, chúng ta sẽ xem xét việc giải quyết tắc nghẽn bằng Thông báo tắc nghẽn lượng tử hóa của Trung tâm dữ liệu (DCQCN) trong trường hợp tắc nghẽn trên kết cấu ngày càng khó xảy ra hoặc khi điều đó chắc chắn xảy ra do incast. Sau đó, tôi sẽ đi vào chi tiết về khả năng quan sát của các kết cấu cụm AI: Gợi ý: chúng tôi sẽ sử dụng các đầu dò Phân tích dựa trên ý định (IBA) của Apstra như đầu dò mất cân bằng ECMP, sử dụng băng thông, lưu lượng thiết bị và khoảng trống kết cấu, giao diện nóng/lạnh và sử dụng một số tính năng phân tích đo từ xa tùy chỉnh mới trong bản phát hành Apstra 4.2.0 mới.
Để tìm hiểu thêm về các giải pháp AI của Juniper, hãy liên hệ cho chúng tôi để biết thêm Juniper về mạng AI.
CÔNG TY CỔ PHẦN DỊCH VỤ CÔNG NGHỆ DATECH
