Mẹo & thủ thuật để làm việc với Ceph trong các dự án bận rộn

Sử dụng Ceph làm bộ lưu trữ mạng trong các dự án có tải khác nhau, chúng ta có thể gặp phải nhiều tác vụ khác nhau mà thoạt nhìn có vẻ không đơn giản hoặc tầm thường. Ví dụ:

• di chuyển dữ liệu từ Ceph cũ sang Ceph mới với việc sử dụng một phần các máy chủ trước đó trong cụm mới;
• giải pháp cho vấn đề phân bổ không gian đĩa trong Ceph.

Đối mặt với những vấn đề như vậy, chúng tôi phải đối mặt với nhu cầu loại bỏ OSD một cách chính xác mà không làm mất dữ liệu, điều này đặc biệt quan trọng khi xử lý lượng lớn dữ liệu. Điều này sẽ được thảo luận trong bài viết.

Các phương pháp được mô tả dưới đây phù hợp với mọi phiên bản Ceph. Ngoài ra, việc Ceph có thể lưu trữ một lượng lớn dữ liệu cũng sẽ được tính đến: để tránh mất dữ liệu và các vấn đề khác, một số hành động sẽ được “chia” thành nhiều hành động khác.

Lời nói đầu về OSD

Vì hai trong số ba công thức được thảo luận được dành riêng cho OSD (Daemon lưu trữ đối tượng), trước khi đi sâu vào phần thực hành - nói ngắn gọn về nó là gì trong Ceph và tại sao nó lại quan trọng đến vậy.

Trước hết, cần phải nói rằng toàn bộ cụm Ceph bao gồm nhiều OSD. Càng có nhiều thì khối lượng dữ liệu miễn phí trong Ceph càng lớn. Thật dễ hiểu từ đây chức năng OSD chính: Nó lưu trữ dữ liệu đối tượng Ceph trên hệ thống tệp của tất cả các nút cụm và cung cấp quyền truy cập mạng vào dữ liệu đó (để đọc, ghi và các yêu cầu khác).

Ở cùng cấp độ, các tham số sao chép được thiết lập bằng cách sao chép các đối tượng giữa các OSD khác nhau. Và ở đây bạn có thể gặp phải nhiều vấn đề khác nhau, các giải pháp sẽ được thảo luận dưới đây.

Trường hợp số 1. Xóa OSD khỏi cụm Ceph một cách an toàn mà không làm mất dữ liệu

Nhu cầu xóa OSD có thể xảy ra do việc xóa máy chủ khỏi cụm - ví dụ: thay thế nó bằng một máy chủ khác - đó là điều đã xảy ra với chúng tôi, dẫn đến việc viết bài viết này. Vì vậy, mục tiêu cuối cùng của thao tác là trích xuất tất cả OSD và mons trên một máy chủ nhất định để có thể dừng nó lại.

Để thuận tiện và tránh trường hợp trong khi thực hiện lệnh, chúng tôi mắc lỗi khi chỉ ra OSD được yêu cầu, chúng tôi sẽ đặt một biến riêng, giá trị của biến này sẽ là số OSD cần xóa. Hãy gọi cho cô ấy ${ID} — ở đây và bên dưới, một biến như vậy sẽ thay thế số OSD mà chúng ta đang làm việc.

Hãy xem xét tình trạng trước khi bắt đầu công việc:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

Để bắt đầu gỡ bỏ OSD, bạn cần thực hiện trơn tru reweight trên đó về không. Bằng cách này, chúng tôi giảm lượng dữ liệu trong OSD bằng cách cân bằng nó với các OSD khác. Để thực hiện việc này, hãy chạy các lệnh sau:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

... và cứ thế cho đến khi bằng không.

Yêu cầu cân bằng mượt màđể không bị mất dữ liệu. Điều này đặc biệt đúng nếu OSD chứa một lượng lớn dữ liệu. Để chắc chắn rằng sau khi thực hiện lệnh reweight mọi thứ đều ổn, bạn có thể hoàn thành nó ceph -s hoặc trong một cửa sổ đầu cuối riêng biệt chạy ceph -w để quan sát những thay đổi trong thời gian thực.

Khi OSD bị “làm trống”, bạn có thể tiến hành thao tác tiêu chuẩn để xóa nó. Để thực hiện việc này, hãy chuyển OSD mong muốn sang trạng thái down:

ceph osd down osd.${ID}

Hãy “kéo” OSD ra khỏi cụm:

ceph osd out osd.${ID}

Hãy dừng dịch vụ OSD và ngắt kết nối phân vùng của nó trong FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Xóa OSD khỏi Bản đồ đè bẹp:

ceph osd crush remove osd.${ID}

Hãy xóa người dùng OSD:

ceph auth del osd.${ID}

Và cuối cùng, hãy xóa OSD:

ceph osd rm osd.${ID}

Ghi: Nếu bạn đang sử dụng phiên bản Ceph Luminous trở lên thì các bước gỡ bỏ OSD ở trên có thể rút gọn thành hai lệnh:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Nếu sau khi hoàn thành các bước được mô tả ở trên, bạn chạy lệnh ceph osd tree, thì cần phải rõ ràng rằng trên máy chủ nơi công việc được thực hiện không còn OSD nào để thực hiện các thao tác trên:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

Trong quá trình thực hiện, hãy lưu ý rằng trạng thái của cụm Ceph sẽ chuyển sang HEALTH_WARN, và chúng ta cũng sẽ thấy số lượng OSD và dung lượng ổ đĩa trống giảm đi.

Phần sau đây sẽ mô tả các bước cần thiết nếu bạn muốn dừng hoàn toàn máy chủ và xóa nó khỏi Ceph. Trong trường hợp này, điều quan trọng cần nhớ là Trước khi tắt máy chủ, bạn phải xóa tất cả OSD trên máy chủ này.

Nếu không còn OSD nào trên máy chủ này thì sau khi xóa chúng, bạn cần loại trừ máy chủ khỏi bản đồ OSD hv-2bằng cách chạy lệnh sau:

ceph osd crush rm hv-2

Xóa bỏ mon từ máy chủ hv-2bằng cách chạy lệnh bên dưới trên một máy chủ khác (tức là trong trường hợp này là trên hv-1):

ceph-deploy mon destroy hv-2

Sau đó, bạn có thể dừng máy chủ và bắt đầu các hành động tiếp theo (triển khai lại nó, v.v.).

Trường hợp số 2. Phân phối không gian đĩa trong cụm Ceph đã được tạo

Tôi sẽ bắt đầu câu chuyện thứ hai bằng lời nói đầu về PG (Nhóm vị trí). Vai trò chính của PG trong Ceph chủ yếu là tổng hợp các đối tượng Ceph và tái tạo chúng trong OSD. Công thức mà bạn có thể tính toán lượng PG cần thiết có trong phần có liên quan Tài liệu Ceph. Vấn đề này cũng được thảo luận ở đó với các ví dụ cụ thể.

Vì vậy: một trong những vấn đề thường gặp khi sử dụng Ceph là số lượng OSD và PG không cân bằng giữa các pool trong Ceph.

Thứ nhất, vì điều này, một tình huống có thể phát sinh khi có quá nhiều PG được chỉ định trong một nhóm nhỏ, về cơ bản là việc sử dụng không gian đĩa trong cụm một cách không hợp lý. Thứ hai, trên thực tế có một vấn đề nghiêm trọng hơn: tràn dữ liệu trên một trong các OSD. Điều này đòi hỏi cụm đầu tiên chuyển sang trạng thái HEALTH_WARN, và sau đó HEALTH_ERR. Nguyên nhân là do Ceph khi tính toán lượng dữ liệu có sẵn (bạn có thể tìm ra bằng cách MAX AVAIL trong đầu ra lệnh ceph df cho từng nhóm riêng biệt) dựa trên lượng dữ liệu có sẵn trong OSD. Nếu không có đủ dung lượng trong ít nhất một OSD thì không thể ghi thêm dữ liệu cho đến khi dữ liệu được phân phối hợp lý giữa tất cả các OSD.

Điều đáng làm rõ là những vấn đề này phần lớn được quyết định ở giai đoạn cấu hình cụm Ceph. Một trong những công cụ bạn có thể sử dụng là Ceph PGCalc. Với sự trợ giúp của nó, số lượng PG cần thiết được tính toán rõ ràng. Tuy nhiên, bạn cũng có thể sử dụng nó trong trường hợp cụm Ceph đã được cấu hình không chính xác. Cần phải làm rõ ở đây rằng là một phần của công việc sửa lỗi, rất có thể bạn sẽ cần phải giảm số lượng PG và tính năng này không có sẵn trong các phiên bản Ceph cũ hơn (nó chỉ xuất hiện trong phiên bản Ceph). Ốc anh vu).

Vì vậy, hãy tưởng tượng hình ảnh sau: cụm có trạng thái HEALTH_WARN do một trong các OSD hết dung lượng. Điều này sẽ được biểu thị bằng một lỗi HEALTH_WARN: 1 near full osd. Dưới đây là một thuật toán để thoát khỏi tình huống này.

Trước hết, bạn cần phân phối dữ liệu có sẵn giữa các OSD còn lại. Chúng tôi đã thực hiện một thao tác tương tự trong trường hợp đầu tiên, khi chúng tôi "rút cạn" nút - với điểm khác biệt duy nhất là bây giờ chúng tôi sẽ cần giảm bớt một chút reweight. Ví dụ: lên tới 0.95:

ceph osd reweight osd.${ID} 0.95

Điều này giải phóng không gian đĩa trong OSD và sửa lỗi về tình trạng ceph. Tuy nhiên, như đã đề cập, vấn đề này chủ yếu xảy ra do cấu hình Ceph không chính xác ở giai đoạn đầu: điều rất quan trọng là phải cấu hình lại để nó không xuất hiện trong tương lai.

Trong trường hợp cụ thể của chúng tôi, tất cả đều thuộc về:

• giá trị quá cao replication_count ở một trong những hồ bơi,
• quá nhiều PG trong một nhóm và quá ít ở nhóm khác.

Hãy sử dụng máy tính đã được đề cập. Nó hiển thị rõ ràng những gì cần phải nhập và về nguyên tắc, không có gì phức tạp. Sau khi thiết lập các tham số cần thiết, chúng tôi nhận được các khuyến nghị sau:

Ghi: Nếu bạn đang thiết lập một cụm Ceph từ đầu, một chức năng hữu ích khác của máy tính là tạo ra các lệnh sẽ tạo các nhóm từ đầu với các tham số được chỉ định trong bảng.

Cột cuối cùng giúp bạn điều hướng - Số lượng PG được đề xuất. Trong trường hợp của chúng tôi, cái thứ hai cũng hữu ích, trong đó tham số sao chép được chỉ định, vì chúng tôi đã quyết định thay đổi hệ số nhân bản.

Vì vậy, trước tiên bạn cần thay đổi các tham số sao chép - điều này đáng làm trước tiên, vì bằng cách giảm hệ số nhân, chúng ta sẽ giải phóng dung lượng ổ đĩa. Khi lệnh thực thi, bạn sẽ nhận thấy dung lượng đĩa trống sẽ tăng lên:

ceph osd pool $pool_name set $replication_size

Và sau khi hoàn thành, chúng ta thay đổi các giá trị tham số pg_num и pgp_num như sau:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Điều quan trọng là: chúng ta phải thay đổi số lượng PG một cách tuần tự trong mỗi nhóm và không thay đổi giá trị trong các nhóm khác cho đến khi cảnh báo biến mất "Dự phòng dữ liệu xuống cấp" и "n-số lượng pss bị xuống cấp".

Bạn cũng có thể kiểm tra xem mọi thứ có ổn không bằng cách sử dụng đầu ra lệnh ceph health detail и ceph -s.

Trường hợp số 3. Di chuyển máy ảo từ LVM sang Ceph RBD

Trong tình huống dự án sử dụng máy ảo được cài đặt trên các máy chủ cơ bản được thuê, vấn đề về khả năng lưu trữ có khả năng chịu lỗi thường phát sinh. Điều cũng rất mong muốn là có đủ dung lượng trong bộ lưu trữ này... Một tình huống phổ biến khác: có một máy ảo có bộ nhớ cục bộ trên máy chủ và bạn cần mở rộng đĩa, nhưng không có nơi nào để đi, vì không có dung lượng đĩa trống còn lại trên máy chủ.

Vấn đề có thể được giải quyết theo nhiều cách khác nhau - ví dụ: bằng cách di chuyển sang máy chủ khác (nếu có) hoặc thêm đĩa mới vào máy chủ. Nhưng không phải lúc nào cũng có thể thực hiện được điều này, vì vậy việc chuyển từ LVM sang Ceph có thể là một giải pháp tuyệt vời cho vấn đề này. Bằng cách chọn tùy chọn này, chúng tôi cũng đơn giản hóa quá trình di chuyển tiếp theo giữa các máy chủ, vì sẽ không cần phải di chuyển bộ nhớ cục bộ từ bộ ảo hóa này sang bộ ảo hóa khác. Điều khó khăn duy nhất là bạn sẽ phải dừng VM trong khi công việc đang được thực hiện.

Công thức sau đây được lấy từ bài viết từ blog này, các hướng dẫn đã được thử nghiệm trong thực tế. Nhân tiện, phương pháp di chuyển không rắc rối cũng được mô tả ở đó, tuy nhiên, trong trường hợp của chúng tôi, nó đơn giản là không cần thiết nên chúng tôi đã không kiểm tra nó. Nếu điều này quan trọng đối với dự án của bạn, chúng tôi sẽ rất vui khi biết về kết quả trong phần nhận xét.

Hãy chuyển sang phần thực tế. Trong ví dụ này, chúng tôi sử dụng virsh và theo đó là libvirt. Trước tiên, hãy đảm bảo rằng nhóm Ceph mà dữ liệu sẽ được di chuyển đến được kết nối với libvirt:

virsh pool-dumpxml $ceph_pool

Mô tả nhóm phải chứa dữ liệu kết nối tới Ceph cùng với dữ liệu ủy quyền.

Bước tiếp theo là hình ảnh LVM được chuyển đổi thành Ceph RBD. Thời gian thực hiện phụ thuộc chủ yếu vào kích thước của hình ảnh:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Sau khi chuyển đổi, hình ảnh LVM sẽ vẫn còn, điều này sẽ hữu ích nếu việc di chuyển VM sang RBD không thành công và bạn phải khôi phục các thay đổi. Ngoài ra, để có thể nhanh chóng khôi phục các thay đổi, hãy tạo bản sao lưu tệp cấu hình máy ảo:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... và chỉnh sửa bản gốc (vm_name.xml). Hãy tìm một khối có mô tả về đĩa (bắt đầu bằng dòng <disk type='file' device='disk'> và kết thúc bằng </disk>) và rút gọn về dạng sau:

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

Chúng ta hãy xem xét một số chi tiết:

1. Đến giao thức source địa chỉ lưu trữ trong Ceph RBD được chỉ định (đây là địa chỉ cho biết tên của nhóm Ceph và hình ảnh RBD, được xác định ở giai đoạn đầu tiên).
2. Trong khối secret loại được chỉ định ceph, cũng như UUID của bí mật để kết nối với nó. uuid của nó có thể được tìm thấy bằng lệnh virsh secret-list.
3. Trong khối host địa chỉ tới màn hình Ceph được chỉ định.

Sau khi chỉnh sửa tệp cấu hình và hoàn tất chuyển đổi LVM sang RBD, bạn có thể áp dụng tệp cấu hình đã sửa đổi và khởi động máy ảo:

virsh define $vm_name.xml
virsh start $vm_name

Đã đến lúc kiểm tra xem máy ảo đã khởi động đúng chưa: ví dụ: bạn có thể tìm hiểu bằng cách kết nối với nó qua SSH hoặc qua virsh.

Nếu máy ảo hoạt động bình thường và bạn không tìm thấy bất kỳ vấn đề nào khác thì bạn có thể xóa hình ảnh LVM không còn được sử dụng:

lvremove main/$vm_image_name

Kết luận

Chúng tôi đã gặp tất cả các trường hợp được mô tả trong thực tế - chúng tôi hy vọng rằng hướng dẫn sẽ giúp các quản trị viên khác giải quyết các vấn đề tương tự. Nếu bạn có nhận xét hoặc câu chuyện tương tự khác từ trải nghiệm sử dụng Ceph của bạn, chúng tôi sẽ rất vui khi thấy chúng trong phần nhận xét!

PS

Đọc thêm trên blog của chúng tôi:

• «Ra tay không nhàm chán: khôi phục cụm Xe trong K8s»;
• «Rook hay không Rook - đó là câu hỏi»;
• «Rook - kho dữ liệu “tự phục vụ” cho Kubernetes»;
• «Tạo bộ lưu trữ liên tục với việc cung cấp trong Kubernetes dựa trên Ceph'.

Nguồn: www.habr.com