Cách mở rộng cụm Slurm HPC lên production với Ansible

Trong Phần 1, chúng ta đã tìm hiểu các kiến thức nền tảng bằng cách xây dựng một cụm Slurm đơn node. Giờ là lúc mở rộng lên một cụm đa node sẵn sàng cho production với triển khai tự động, giám sát và cảnh báo.

Trong bài viết này, chúng ta sẽ dùng Ansible để tự động hóa toàn bộ quá trình triển khai, giúp nó có thể tái lặp và dễ bảo trì.

Tổng quan chuỗi bài

• Phần 1: Giới thiệu, kiến trúc và thiết lập đơn node
• Phần 2 (bài này): Mở rộng lên production với Ansible
• Phần 3: Quản trị và các best practice

Chuyển từ thiết lập đơn node sang một cụm production đa node bao gồm:

• Cấu hình nhiều máy giống hệt nhau
• Quản lý các dependency và thứ tự cài đặt
• Giữ các cấu hình đồng bộ với nhau
• Xử lý quản lý người dùng trên nhiều node
• Thiết lập hạ tầng giám sát và logging

Làm thủ công những việc này dễ sai sót và tốn thời gian. Các công cụ tự động hóa hạ tầng như Ansible, Puppet hay Terraform giải quyết vấn đề này. Chúng tôi chọn Ansible vì:

• Agentless: Không cần cài phần mềm trên các node được quản lý
• Khai báo (Declarative): Mô tả trạng thái mong muốn, không phải các bước
• Idempotent: An toàn khi chạy nhiều lần
• Dựa trên YAML: Dễ đọc và dễ quản lý phiên bản
• Hệ sinh thái lớn: Nhiều role dựng sẵn

Để xem nhanh Ansible là gì, hãy xem video này https://www.youtube.com/watch?v=xRMPKQweySE

Kiến trúc cụm production

Hình 1: Kiến trúc chuẩn của một cụm Slurm đa node

Hình 1 ở trên cho thấy cách nhiều node có thể được thiết lập chỉ liên quan đến kiến trúc cụm Slurm. Tuy nhiên, trong production thực tế, có một số bước bổ sung cần thiết cho các dịch vụ bioinformatics, bao gồm: Lưu trữ chia sẻ và Giám sát. Nội dung sẽ được giải thích chi tiết hơn như bên dưới

Hệ thống lưu trữ chia sẻ

Hình 2: Hệ thống lưu trữ chia sẻ chuẩn giữa nhiều node

Tại sao chúng ta cần hệ thống lưu trữ chia sẻ? Ý tưởng đơn giản là khi chúng ta chạy một job trên worker, nó cần truy cập dữ liệu. Sau đó, khi chúng ta ngừng làm việc hoặc yêu cầu một hệ thống tài nguyên cao hơn, chúng ta vẫn có thể truy cập dữ liệu. Trong các tác vụ nâng cao, chúng ta cần phân tích trên nhiều compute node, chúng ta cần dữ liệu thô, các tệp trung gian có thể được chia sẻ và lưu trữ để phân tích trên nhiều máy.

Thông thường, thiết lập chuẩn có thể được biểu diễn như trong Hình 2, với:

• Network File System (NFS): Với Local Area Network (LAN) cùng các router mạng tốc độ cao giữa các node, nó có thể được cấu hình để chia sẻ các thư mục cụ thể từ một máy đến nhiều node. Nó thường được cấu hình trên controller node, nơi nó chia sẻ thư mục HOME, sau đó thư mục home của người dùng bạn sẽ khả dụng trên các node đích.
• Network Attached Storage (NAS) (Tùy chọn): Tương tự NFS, nó có thể được cấu hình để chia sẻ tệp. Thông thường, chúng được cấu hình bằng một thiết bị riêng có phần mềm NAS liên quan để quản lý và giám sát. Cuối cùng, nó có thể được chia sẻ qua mạng công cộng. Nó cũng có thể đảm bảo khả năng truy cập đọc/ghi cao giữa các node và đảm bảo sao lưu dữ liệu bằng nhiều bản sao dữ liệu. Tuy nhiên, chi phí vận hành NAS có thể được cân nhắc khi người dùng có thể dùng trực tiếp cloud storage. Họ có thể tải dữ liệu thô về NFS trước, tải các tệp cần thiết lên cloud khi hoàn tất
• Cloud storage: Mặc dù HPC được thiết kế để dùng cục bộ, việc dùng cloud storage là cần thiết khi người dùng có thể lưu trữ dữ liệu. Trong bioinformatics, có một điểm khá đặc biệt là dữ liệu có thể được tái sử dụng để khai thác thông tin mới khi các công cụ mới được phát triển. Trong khi HPC mạnh về tính toán để khảo sát, thì sau này, việc cấu hình cloud computing có thể được dùng để tối ưu chi phí production.

Stack giám sát

Hình 3: Hệ thống giám sát được thiết kế cho nhiều node để thu thập các chỉ số hệ thống và Slurm

Với vai trò quản trị viên của HPC, bạn không nên đăng nhập vào HPC rồi kiểm tra trạng thái của cụm. Theo Hình 3, thông thường, với HPC, quản trị viên sẽ:

• Giám sát hệ thống: Đơn giản là kiểm tra xem người dùng có thể sử dụng HPC một cách hiệu quả và tối ưu hay không. Có thể kiểm tra đơn giản qua mức sử dụng disk, memory và cpu. Nếu disk đầy, đó có thể là tín hiệu để tăng kích thước node HPC. Nếu phân tích không thể được tối ưu, đã đến lúc nâng cấp hệ thống. Nó có thể phát hiện người dùng có dùng HPC đúng cách hay không. Ví dụ, chạy pipeline bioinformatics với Nextflow có thể dùng với executor=slurm nó sẽ giúp tự động submit và giám sát các tác vụ, trong khi submit một job đơn với tài nguyên tính toán cao và chạy pipeline với executor=local sẽ lãng phí tài nguyên khi một vài bước không cần quá nhiều tài nguyên mà lại tốn thời gian chạy.
• Giám sát Slurm: Nếu các node luôn bận (>80%) và dự kiến sẽ dùng nhiều hơn, có thể cân nhắc nâng cấp HPC. Đặc biệt, quản trị viên có thể khuyến khích và hướng dẫn người dùng submit job vào ban đêm cho các tác vụ lớn, khi vào thời điểm đó không có nhiều người dùng

Các chỉ số có thể được thu thập như thế nào:

• Chỉ số hệ thống: Có thể được cấu hình qua promethus-node-exporter trên mỗi node, nó thu thập các chỉ số hệ thống và expose dưới dạng web api service tại https://<node name>:3000. Sau đó, head node có thể gửi request để thu thập các chỉ số này.
• Chỉ số Slurm: Có thể được cấu hình qua promethus-slurm-exporter trên node trong cụm Slurm. Nó thường là controller node.
• Chỉ số thu thập và dashboard: Sau đó prometheus sẽ thu thập các chỉ số này và có thể là nguồn cho Grafana với dashboard được cấu hình để phân tích tương tác

• Prometheus: Cơ sở dữ liệu chỉ số chuỗi thời gian
• Grafana: Dashboard đẹp mắt để trực quan hóa
• Alertmanager: Gửi cảnh báo đến Slack khi có sự cố
• Node Exporter: Các chỉ số cấp hệ thống (CPU, memory, disk)
• Slurm Exporter: Các chỉ số đặc thù của Slurm (job, partition, node)

Hệ thống cảnh báo

HPC không phải lúc nào cũng hoạt động đúng. Nếu một worker không hoạt động, quản trị viên nên nhận thông báo càng sớm càng tốt thay vì chờ người dùng báo sự cố. Vì vậy, prometheus có thể được tích hợp với alertmanager. Đơn giản, chúng ta có thể cấu hình quy tắc: Nếu chỉ số hệ thống không thể thu thập từ một node, nó không phản hồi, thì nên đánh dấu là node down và dứt khoát gửi tin nhắn cảnh báo đến ứng dụng chat. Có thể là Slack hoặc Zalo (khu vực Việt Nam) để nhanh chóng khắc phục sự cố.

Mở rộng lên HPC nhiều node

Có thể được thực hiện từng bước, qua:

• Bước 1: Clone repo
• Bước 2: Cài đặt Ansible - công cụ sẽ kết nối và chạy lệnh command line để thiết lập trên máy từ xa (các node)
• Bước 3: Tạo ứng dụng Slack có API để Promethus, khi nó thấy điều kiện healthy bị thất bại, sẽ gọi API để cảnh báo quản trị viên và người dùng
• Bước 4: Kết nối máy của bạn để có thể kết nối với các node, tạo inventories lưu thông tin về cách máy bạn có thể kết nối và thiết lập trên các node, quyết định node nào nên được cấu hình làm controller, login, worker để cài các dịch vụ tương ứng.
• Bước 5: Giờ bạn có thể xây dựng cụm, dùng Ansible, đọc tệp inventories và cài đặt/cấu hình phần mềm trên máy từ xa một cách tự động thay vì đăng nhập thủ công vào từng node và cài phần mềm
• Bước 6: Giờ cụm đã sẵn sàng chạy, bạn cần thêm người dùng khớp đúng với các Linux user trên các node để có quyền hạn phù hợp làm việc trên cụm.
• Bước 7: Dùng Slurm user đã tạo, xác minh cụm có thể submit job và chạy phân tích đơn giản
• Bước 8: Kiểm tra lại dashboard để thấy chỉ số hệ thống của từng node và chỉ số Slurm HPC được Grafana trực quan hóa

Điều kiện tiên quyết

• Nhiều máy Ubuntu 20.04 hoặc 24.04 (hoặc VM)
• Quyền truy cập SSH đến tất cả các node
• Quyền sudo trên tất cả các node
• Một Slack workspace (để nhận cảnh báo)

Bước 1: Clone Repository

1
git clone https://github.com/vieomics/omicslab-hpc -b 1.0.0
2
cd omicslab-hpc

Bước 2: Cài đặt Ansible và các dependency

1
# pixi is similar to conda
2
# install pixi
3
make ${HOME}/.pixi/bin/pixi
4

5
# activate environment
6
pixi shell
7

8
# install dependencies, start up example instances with cluster os, support multiple version
9
# bash scripts/setup.sh 22.04
10
# bash scripts/setup.sh 20.04
11
bash scripts/setup.sh 24.04
12
# or
13
make vm-start

Script này cài đặt:

• Các collection Community Ansible
• Các Galaxy role (geerlingguy.docker, v.v.)

Bước 3: Thiết lập cảnh báo Slack

Tạo một Slack App

1. Truy cập Slack API và tạo một ứng dụng mới
2. Chọn "From scratch"
3. Đặt tên cho nó (ví dụ: "Slurm Cluster Monitor")
4. Chọn workspace của bạn

Bật Incoming Webhooks

1. Điều hướng đến "Incoming Webhooks" trong cài đặt ứng dụng của bạn
2. Kích hoạt incoming webhooks
3. Nhấn "Add New Webhook to Workspace"
4. Chọn kênh nhận thông báo (ví dụ: #cluster-alerts)
5. Sao chép URL webhook

Kiểm tra Webhook thủ công

1
curl -X POST -H 'Content-type: application/json' \
2
  --data '{"text":"Hello from Slurm cluster!"}' \
3
  https://hooks.slack.com/services/YOUR/WEBHOOK/URL

Bạn sẽ thấy tin nhắn xuất hiện trong kênh Slack của mình!

Bước 4: Cấu hình Inventory của bạn

Tạo inventories/hosts (hoặc sao chép từ inventories/hosts.example):

1
[slurm_master]
2
controller-01 ansible_host=192.168.58.10
3

4
[slurm_worker]
5
worker-01 ansible_host=192.168.58.11
6
worker-02 ansible_host=192.168.58.12
7

8
[slurm:children]
9
slurm_master
10
slurm_worker
11

12
\[all:vars] # remove the backflash that html turbopack failed to render as code block
13
ansible_user=your_username
14
slurm_password=secure_munge_password
15
slurm_account_db_pass=secure_db_password
16
slack_api_url=https://hooks.slack.com/services/YOUR/WEBHOOK/URL
17
slack_channel=#cluster-alerts
18
admin_user=admin
19
admin_password=secure_grafana_password

1
# create encrypted vault, add your vault password,  content, then exit with vim key :wq
2
ansible-vault create inventories/hosts.prod
3

4
# edit exisiting files, add your vault password to work directly inside
5
ansible-vault edit inventories/hosts.prod