Quản lý cụm hiệu quả và đáng tin cậy ở mọi quy mô với Tupperware
Hôm nay vào ngày chúng tôi đã giới thiệu Tupperware, hệ thống quản lý cụm của chúng tôi giúp điều phối các vùng chứa trên hàng triệu máy chủ chạy hầu hết tất cả các dịch vụ của chúng tôi. Chúng tôi triển khai Tupperware lần đầu tiên vào năm 2011 và kể từ đó cơ sở hạ tầng của chúng tôi đã phát triển từ đến toàn bộ . Trong suốt thời gian qua, Tupperware đã không đứng yên và phát triển cùng chúng tôi. Chúng tôi sẽ chỉ cho bạn cách Tupperware cung cấp khả năng quản lý cụm hạng nhất, bao gồm hỗ trợ thuận tiện cho các dịch vụ có trạng thái, một bảng điều khiển duy nhất cho tất cả các trung tâm dữ liệu và khả năng phân bổ dung lượng giữa các dịch vụ trong thời gian thực. Chúng tôi cũng sẽ chia sẻ những bài học chúng tôi đã học được khi cơ sở hạ tầng của chúng tôi phát triển.
Tupperware thực hiện các nhiệm vụ khác nhau. Các nhà phát triển ứng dụng sử dụng nó để phân phối và quản lý ứng dụng. Nó đóng gói mã ứng dụng và các phần phụ thuộc vào một hình ảnh và gửi nó đến máy chủ dưới dạng vùng chứa. Bộ chứa cung cấp sự cách ly giữa các ứng dụng trên cùng một máy chủ để các nhà phát triển xử lý logic ứng dụng và không phải lo lắng về việc tìm máy chủ hoặc quản lý các bản cập nhật. Tupperware cũng giám sát hiệu suất của máy chủ và nếu phát hiện lỗi, nó sẽ chuyển các container từ máy chủ có vấn đề.
Các kỹ sư lập kế hoạch năng lực sử dụng Tupperware để phân bổ dung lượng máy chủ cho các nhóm dựa trên ngân sách và các ràng buộc. Họ cũng sử dụng nó để cải thiện việc sử dụng máy chủ. Người vận hành trung tâm dữ liệu sử dụng Tupperware để phân phối hợp lý các thùng chứa trên khắp các trung tâm dữ liệu và dừng hoặc di chuyển các thùng chứa trong quá trình bảo trì. Nhờ đó, việc bảo trì máy chủ, mạng và thiết bị cần có sự can thiệp tối thiểu của con người.
Kiến trúc Tupperware
Kiến trúc Tupperware PRN là một trong những khu vực trong trung tâm dữ liệu của chúng tôi. Khu vực này bao gồm một số tòa nhà trung tâm dữ liệu (PRN1 và PRN2) nằm gần đó. Chúng tôi dự định tạo một bảng điều khiển để quản lý tất cả các máy chủ trong một khu vực.
Các nhà phát triển ứng dụng cung cấp dịch vụ dưới dạng công việc Tupperware. Một công việc bao gồm nhiều vùng chứa và tất cả chúng thường chạy cùng một mã ứng dụng.
Tupperware chịu trách nhiệm cung cấp các container và quản lý vòng đời của chúng. Nó bao gồm một số thành phần:
- Giao diện người dùng Tupperware cung cấp các API cho giao diện người dùng, CLI và các công cụ tự động hóa khác mà qua đó bạn có thể tương tác với Tupperware. Họ che giấu toàn bộ cấu trúc nội bộ khỏi chủ sở hữu công việc Tupperware.
- Tupperware Scheduler là bảng điều khiển chịu trách nhiệm quản lý vùng chứa và vòng đời công việc. Nó được triển khai ở cấp độ khu vực và toàn cầu, trong đó bộ lập lịch khu vực quản lý các máy chủ trong một khu vực và bộ lập lịch toàn cầu quản lý các máy chủ từ các khu vực khác nhau. Bộ lập lịch được chia thành các phân đoạn và mỗi phân đoạn quản lý một tập hợp công việc.
- Proxy lập lịch biểu của Tupperware ẩn phần bảo vệ bên trong và cung cấp một ô kính duy nhất thuận tiện cho người dùng Tupperware.
- Bộ cấp phát Tupperware chỉ định các thùng chứa cho máy chủ. Bộ lập lịch xử lý việc dừng, khởi động, cập nhật và chuyển đổi dự phòng của vùng chứa. Hiện tại, một người cấp phát có thể quản lý toàn bộ khu vực mà không cần chia thành các phân đoạn. (Lưu ý sự khác biệt về thuật ngữ. Ví dụ: bộ lập lịch trong Tupperware tương ứng với bảng điều khiển trong và bộ cấp phát Tupperware được gọi là bộ lập lịch trong Kubernetes.)
- Nhà môi giới tài nguyên lưu trữ nguồn sự thật cho các sự kiện máy chủ và dịch vụ. Chúng tôi điều hành một nhà môi giới tài nguyên cho mỗi trung tâm dữ liệu và nó lưu trữ tất cả thông tin về các máy chủ trong trung tâm dữ liệu đó. Nhà môi giới tài nguyên và hệ thống quản lý năng lực hoặc hệ thống cung cấp tài nguyên sẽ tự động quyết định việc phân phối bộ lập lịch nào sẽ kiểm soát máy chủ nào. Dịch vụ kiểm tra tình trạng giám sát các máy chủ và lưu trữ dữ liệu về tình trạng của chúng trong nhà môi giới tài nguyên. Nếu một máy chủ gặp sự cố hoặc cần bảo trì, nhà môi giới tài nguyên sẽ yêu cầu người cấp phát và người lập lịch dừng các vùng chứa hoặc di chuyển chúng sang các máy chủ khác.
- Tác nhân Tupperware là một daemon chạy trên mỗi máy chủ để chuẩn bị và loại bỏ các vùng chứa. Các ứng dụng chạy bên trong một thùng chứa, giúp chúng có khả năng cách ly và tái tạo tốt hơn. TRÊN Chúng tôi đã mô tả cách tạo các thùng chứa Tupperware riêng lẻ bằng cách sử dụng hình ảnh, btrfs, cgroupv2 và systemd.
Tính năng nổi bật của Tupperware
Tupperware có nhiều điểm tương tự với các hệ thống quản lý cụm khác như Kubernetes và , nhưng cũng có những khác biệt:
- Hỗ trợ tích hợp cho các dịch vụ trạng thái.
- Một bảng điều khiển duy nhất dành cho các máy chủ ở các trung tâm dữ liệu khác nhau để tự động hóa việc phân phối các container dựa trên mục đích, ngừng hoạt động các cụm và bảo trì.
- Phân chia rõ ràng bảng điều khiển để phóng to.
- Điện toán đàn hồi cho phép bạn phân phối sức mạnh giữa các dịch vụ trong thời gian thực.
Chúng tôi đã phát triển những tính năng thú vị này để hỗ trợ nhiều ứng dụng có trạng thái và không trạng thái trên một nhóm máy chủ dùng chung toàn cầu khổng lồ.
Hỗ trợ tích hợp cho các dịch vụ trạng thái.
Tupperware vận hành nhiều dịch vụ trạng thái quan trọng lưu trữ dữ liệu sản phẩm cố định cho Facebook, Instagram, Messenger và WhatsApp. Đây có thể là kho lưu trữ lớn các cặp khóa-giá trị (ví dụ: ) và giám sát kho dữ liệu (ví dụ: и ). Việc duy trì các dịch vụ ở trạng thái không hề dễ dàng vì hệ thống phải đảm bảo rằng việc cung cấp container có thể chịu được sự gián đoạn trên quy mô lớn, bao gồm cả sự cố mất mạng hoặc mất điện. Và trong khi các kỹ thuật thông thường, chẳng hạn như phân phối vùng chứa trên các miền lỗi, hoạt động tốt cho các dịch vụ không có trạng thái, thì các dịch vụ có trạng thái cần được hỗ trợ thêm.
Ví dụ: nếu lỗi máy chủ khiến một bản sao cơ sở dữ liệu không khả dụng, bạn có nên bật bảo trì tự động để cập nhật lõi trên 50 máy chủ từ nhóm 10 không? Tùy theo hoàn cảnh. Nếu một trong 50 máy chủ này có một bản sao khác của cùng một cơ sở dữ liệu, tốt hơn hết bạn nên đợi và không để mất 2 bản sao cùng một lúc. Để tự động đưa ra quyết định về hiệu suất và bảo trì hệ thống, chúng tôi cần thông tin về sao chép dữ liệu nội bộ và logic vị trí của từng dịch vụ có trạng thái.
Giao diện TaskControl cho phép các dịch vụ có trạng thái tác động đến các quyết định ảnh hưởng đến tính khả dụng của dữ liệu. Sử dụng giao diện này, bộ lập lịch thông báo cho các ứng dụng bên ngoài về hoạt động của vùng chứa (khởi động lại, cập nhật, di chuyển, bảo trì). Một dịch vụ có trạng thái triển khai một bộ điều khiển để thông báo cho Tupperware khi nào an toàn để thực hiện từng thao tác và các thao tác này có thể bị hoán đổi hoặc trì hoãn tạm thời. Trong ví dụ trên, bộ điều khiển cơ sở dữ liệu có thể yêu cầu Tupperware cập nhật 49 trong số 50 máy chủ, nhưng hiện tại chỉ để lại một máy chủ cụ thể (X). Kết quả là, nếu thời gian cập nhật kernel trôi qua và cơ sở dữ liệu vẫn không thể khôi phục bản sao có vấn đề, Tupperware vẫn sẽ cập nhật máy chủ X.
Nhiều dịch vụ có trạng thái trong Tupperware không sử dụng TaskControl trực tiếp mà thông qua ShardManager, một nền tảng chung để tạo các dịch vụ có trạng thái trên Facebook. Với Tupperware, các nhà phát triển có thể chỉ định mục đích của họ về cách phân phối chính xác các vùng chứa trên các trung tâm dữ liệu. Với ShardManager, các nhà phát triển chỉ định mục đích của họ về cách phân phối các phân đoạn dữ liệu trên các vùng chứa. ShardManager nhận thức được vị trí và sao chép dữ liệu của các ứng dụng của mình, đồng thời liên lạc với Tupperware thông qua giao diện TaskControl để lên lịch các hoạt động của vùng chứa mà không cần sự tham gia trực tiếp của ứng dụng. Sự tích hợp này giúp đơn giản hóa đáng kể việc quản lý các dịch vụ có trạng thái, nhưng TaskControl còn có khả năng làm được nhiều điều hơn thế. Ví dụ: tầng web mở rộng của chúng tôi không có trạng thái và sử dụng TaskControl để tự động điều chỉnh tốc độ cập nhật cho vùng chứa. Sau cùng mỗi ngày mà không ảnh hưởng đến tính khả dụng.
Quản lý máy chủ trong trung tâm dữ liệu
Khi Tupperware ra mắt lần đầu tiên vào năm 2011, mỗi cụm máy chủ được quản lý bởi một bộ lập lịch riêng. Trước đó, cụm Facebook là một nhóm các giá đỡ máy chủ được kết nối với một bộ chuyển mạch mạng và trung tâm dữ liệu chứa một số cụm. Bộ lập lịch chỉ có thể quản lý các máy chủ trong một cụm, nghĩa là công việc không thể trải rộng trên nhiều cụm. Cơ sở hạ tầng của chúng tôi phát triển, chúng tôi ngày càng loại bỏ các cụm. Do Tupperware không thể chuyển công việc từ cụm đã ngừng hoạt động sang cụm khác mà không có thay đổi nên cần rất nhiều nỗ lực và sự phối hợp cẩn thận giữa các nhà phát triển ứng dụng và nhà điều hành trung tâm dữ liệu. Quá trình này dẫn đến lãng phí tài nguyên khi máy chủ không hoạt động trong nhiều tháng do thủ tục ngừng hoạt động.
Chúng tôi đã tạo một nhà môi giới tài nguyên để giải quyết vấn đề ngừng hoạt động của cụm và điều phối các loại nhiệm vụ bảo trì khác. Nhà môi giới tài nguyên theo dõi tất cả thông tin vật lý được liên kết với máy chủ và tự động quyết định bộ lập lịch nào kiểm soát từng máy chủ. Việc liên kết động các máy chủ với bộ lập lịch cho phép bộ lập lịch quản lý các máy chủ ở các trung tâm dữ liệu khác nhau. Vì công việc Tupperware không còn bị giới hạn ở một cụm duy nhất nên người dùng Tupperware có thể chỉ định cách phân phối các vùng chứa trên các miền lỗi. Ví dụ: nhà phát triển có thể tuyên bố ý định của mình (giả sử: "chạy công việc của tôi trên 2 miền lỗi trong vùng PRN") mà không chỉ định vùng sẵn sàng cụ thể. Bản thân Tupperware sẽ tìm các máy chủ phù hợp để thực hiện ý định này, ngay cả khi cụm hoặc dịch vụ ngừng hoạt động.
Có thể mở rộng để hỗ trợ toàn bộ hệ thống toàn cầu
Trong lịch sử, cơ sở hạ tầng của chúng tôi đã được chia thành hàng trăm nhóm máy chủ chuyên dụng cho từng nhóm. Do sự phân mảnh và thiếu tiêu chuẩn, chúng tôi có chi phí vận hành cao và các máy chủ nhàn rỗi khó sử dụng lại hơn. Tại hội nghị năm ngoái chúng tôi đã trình bày , điều này sẽ hợp nhất cơ sở hạ tầng của chúng tôi thành một khu vực máy chủ lớn. Nhưng một khu vực máy chủ duy nhất cũng có những khó khăn riêng. Nó phải đáp ứng một số yêu cầu nhất định:
- Khả năng mở rộng. Cơ sở hạ tầng của chúng tôi phát triển khi chúng tôi bổ sung thêm các trung tâm dữ liệu ở từng khu vực. Máy chủ ngày càng nhỏ hơn và tiết kiệm năng lượng hơn nên số lượng máy chủ ngày càng nhiều ở mỗi khu vực. Kết quả là, một bộ lập lịch cho mỗi vùng không thể xử lý số lượng vùng chứa có thể chạy trên hàng trăm nghìn máy chủ ở mỗi vùng.
- Độ tin cậy. Ngay cả khi bộ lập lịch có thể được mở rộng quy mô đến mức đó, phạm vi lớn của bộ lập lịch có nghĩa là có nguy cơ xảy ra lỗi cao hơn và toàn bộ vùng chứa có thể trở nên không thể quản lý được.
- Khả năng chịu lỗi. Trong trường hợp xảy ra sự cố cơ sở hạ tầng nghiêm trọng (ví dụ: các máy chủ chạy bộ lập lịch bị lỗi do lỗi mạng hoặc mất điện), hậu quả tiêu cực sẽ chỉ ảnh hưởng đến một phần máy chủ trong khu vực.
- Dễ sử dụng. Có vẻ như bạn cần chạy nhiều bộ lập lịch độc lập cho một khu vực. Nhưng từ góc độ thuận tiện, một điểm truy cập duy nhất vào nhóm chung của khu vực giúp quản lý năng lực và công việc dễ dàng hơn.
Chúng tôi đã chia bộ lập lịch thành các phân đoạn để giải quyết vấn đề duy trì một nhóm dùng chung lớn. Mỗi phân đoạn bộ lập lịch quản lý nhóm công việc riêng trong khu vực và điều này giúp giảm rủi ro liên quan đến bộ lập lịch. Khi nhóm chia sẻ phát triển, chúng tôi có thể thêm nhiều phân đoạn lập lịch hơn. Đối với người dùng Tupperware, các phân đoạn và proxy lập lịch trông giống như một bảng điều khiển. Họ không cần phải làm việc với nhiều phân đoạn sắp xếp nhiệm vụ. Phân đoạn bộ lập lịch về cơ bản khác với bộ lập lịch cụm mà chúng tôi đã sử dụng trước đây, trong đó bảng điều khiển được phân vùng mà không phân chia tĩnh nhóm máy chủ dùng chung theo cấu trúc liên kết mạng.
Cải thiện hiệu quả sử dụng với điện toán đàn hồi
Cơ sở hạ tầng của chúng tôi càng lớn thì việc sử dụng máy chủ của chúng tôi một cách hiệu quả càng quan trọng hơn để tối ưu hóa chi phí cơ sở hạ tầng và giảm tải. Có hai cách để tăng hiệu quả sử dụng máy chủ:
- Điện toán linh hoạt - giảm quy mô các dịch vụ trực tuyến trong những giờ yên tĩnh và sử dụng máy chủ rảnh rỗi cho khối lượng công việc ngoại tuyến, chẳng hạn như công việc machine learning và MapReduce.
- Quá tải - Đặt các dịch vụ trực tuyến và khối lượng công việc hàng loạt trên cùng một máy chủ để khối lượng công việc hàng loạt chạy ở mức ưu tiên thấp.
Điểm nghẽn trong trung tâm dữ liệu của chúng tôi là . Do đó, chúng tôi ưu tiên các máy chủ nhỏ, tiết kiệm năng lượng có khả năng cung cấp nhiều sức mạnh xử lý hơn. Thật không may, trên các máy chủ nhỏ có ít CPU và bộ nhớ, tình trạng quá tải sẽ kém hiệu quả hơn. Tất nhiên, chúng ta có thể đặt một số vùng chứa dịch vụ nhỏ trên một máy chủ nhỏ tiết kiệm năng lượng, tiêu tốn ít tài nguyên bộ xử lý và bộ nhớ, nhưng các dịch vụ lớn sẽ có hiệu suất thấp trong tình huống này. Do đó, chúng tôi khuyên các nhà phát triển các dịch vụ lớn của chúng tôi nên tối ưu hóa chúng để họ có thể sử dụng toàn bộ máy chủ.
Về cơ bản, chúng tôi cải thiện hiệu quả sử dụng bằng cách sử dụng tính toán đàn hồi. Nhiều dịch vụ chính của chúng tôi, chẳng hạn như Bảng tin, tính năng Nhắn tin và cấp độ web giao diện người dùng, khác nhau tùy theo thời gian trong ngày. Chúng tôi cố tình giảm quy mô các dịch vụ trực tuyến trong những giờ yên tĩnh và sử dụng các máy chủ rảnh rỗi cho khối lượng công việc ngoại tuyến, chẳng hạn như công việc machine learning và MapReduce.
Theo kinh nghiệm, chúng tôi biết rằng tốt nhất nên cung cấp toàn bộ máy chủ dưới dạng đơn vị có dung lượng linh hoạt vì các dịch vụ lớn vừa là nhà tài trợ chính vừa là người tiêu dùng chính có dung lượng linh hoạt và được tối ưu hóa để sử dụng toàn bộ máy chủ. Khi máy chủ được giải phóng khỏi dịch vụ trực tuyến trong những giờ yên tĩnh, nhà môi giới tài nguyên sẽ cho người lập lịch thuê máy chủ để chạy khối lượng công việc ngoại tuyến trên đó. Nếu dịch vụ trực tuyến gặp phải tải cao điểm, nhà môi giới tài nguyên sẽ nhanh chóng thu hồi máy chủ đã mượn và cùng với bộ lập lịch, trả nó về dịch vụ trực tuyến.
Bài học kinh nghiệm và kế hoạch cho tương lai
Trong 8 năm qua, chúng tôi đã phát triển Tupperware để theo kịp tốc độ phát triển nhanh chóng của Facebook. Chúng tôi chia sẻ những gì mình đã học được và hy vọng nó sẽ giúp những người khác quản lý cơ sở hạ tầng đang phát triển nhanh chóng:
- Thiết lập kết nối linh hoạt giữa bảng điều khiển và máy chủ mà nó quản lý. Tính linh hoạt này cho phép bảng điều khiển quản lý máy chủ ở các trung tâm dữ liệu khác nhau, giúp tự động hóa việc ngừng hoạt động và bảo trì các cụm, đồng thời cho phép phân bổ công suất động bằng cách sử dụng điện toán đàn hồi.
- Với một bảng điều khiển duy nhất trong khu vực, việc xử lý các tác vụ trở nên thuận tiện hơn và dễ dàng quản lý nhóm máy chủ dùng chung lớn hơn. Lưu ý rằng bảng điều khiển duy trì một điểm vào duy nhất, ngay cả khi cấu trúc bên trong của nó bị tách rời vì lý do quy mô hoặc khả năng chịu lỗi.
- Bằng cách sử dụng mô hình plugin, bảng điều khiển có thể thông báo cho các ứng dụng bên ngoài về các hoạt động sắp tới của vùng chứa. Hơn nữa, các dịch vụ có trạng thái có thể sử dụng giao diện plugin để tùy chỉnh việc quản lý vùng chứa. Với mô hình plugin này, bảng điều khiển mang đến sự đơn giản đồng thời phục vụ hiệu quả nhiều dịch vụ trạng thái khác nhau.
- Chúng tôi tin rằng điện toán đàn hồi, trong đó chúng tôi loại bỏ toàn bộ máy chủ khỏi các dịch vụ của nhà tài trợ cho các tác vụ hàng loạt, học máy và các dịch vụ không khẩn cấp khác, là cách tối ưu để cải thiện hiệu quả của các máy chủ nhỏ, tiết kiệm năng lượng.
Chúng tôi mới bắt đầu triển khai . Hiện tại khoảng 20% máy chủ của chúng tôi nằm trong nhóm dùng chung. Để đạt được 100%, nhiều vấn đề cần được giải quyết, bao gồm duy trì nhóm lưu trữ dùng chung, tự động bảo trì, quản lý các yêu cầu của nhiều người thuê, cải thiện việc sử dụng máy chủ và cải thiện khả năng hỗ trợ cho khối lượng công việc học máy. Chúng tôi rất nóng lòng được đón nhận những thử thách này và chia sẻ những thành công của mình.
Nguồn: www.habr.com