Tuesday, September 17, 2024

Replicas dữ liệu trong Ceph

-

1. Tổng quan.
Trong mô hình Ceph, việc triển khai một cluster với nhiều node có thể cung cấp tính linh hoạt và khả năng chịu lỗi, tuy nhiên, để đảm bảo tính an toàn của dữ liệu, bạn cần cân nhắc về cấu hình pool và replica để giảm thiểu nguy cơ mất dữ liệu khi có sự cố xảy ra.

Mặc định, Ceph thường triển khai replica, nghĩa là mỗi đối tượng (object) sẽ được lưu trữ trên nhiều OSD (Object Storage Daemon) để đảm bảo tính toàn vẹn và khả năng chịu lỗi. Tuy nhiên, cấu hình replica cũng ảnh hưởng đến dung lượng lưu trữ và hiệu suất.

Khi sử dụng replica, nếu bạn có một pool với cấu hình osd_pool_default_size=3, nó có nghĩa là mỗi đối tượng sẽ có 3 bản sao trên 3 OSD khác nhau và đối tượng sẽ vẫn khả dụng nếu một hoặc hai OSD bị mất. Tuy nhiên, nếu pool đạt tới dung lượng tối đa và mất nhiều hơn số lượng replica cho một đối tượng cụ thể, bạn có thể mất dữ liệu.

Để tăng tính an toàn, bạn có thể xem xét việc sử dụng Erasure Coding pool thay vì replica, hoặc cân nhắc cấu hình các thông số như osd_pool_default_size và osd_pool_default_min_size một cách thích hợp để đảm bảo tính an toàn và hiệu suất của hệ thống Ceph.

Tham số osd_pool_default_sizeosd_pool_default_min_size xác định số lượng bản sao (replicas) của mỗi đối tượng. Các bản sao này được phân tán trên các OSDs khác nhau để đảm bảo sự an toàn và khả năng chịu lỗi.

2. Hiểu về OSD.

Mỗi OSD (Object Storage Daemon) thường tương ứng với một ổ đĩa vật lý hoặc một phân vùng trên ổ đĩa vật lý. OSD chịu trách nhiệm lưu trữ dữ liệu và thực hiện các thao tác đọc/ghi trong hệ thống Ceph.

Do đó, một OSD thường được liên kết với một ổ đĩa vật lý hoặc một phân vùng trên ổ đĩa vật lý. Trong một cụm OSDs, mỗi OSD có thể tương ứng với một thiết bị lưu trữ vật lý khác nhau như một ổ đĩa cứng. Các OSD này cung cấp không gian lưu trữ và đảm bảo sự phân tán và an toàn của dữ liệu trong hệ thống Ceph.

Tuy nhiên, để tối ưu hóa hiệu suất và đảm bảo sự phân tán, một ổ đĩa có thể được chia thành nhiều phân vùng và mỗi phân vùng này được sử dụng làm OSD. Điều này cho phép tận dụng tối đa tài nguyên lưu trữ có sẵn trên từng ổ đĩa.

3. Hiểu về đối tượng (object) trong Ceph.

Trong Ceph đối tượng (object) thường được hiểu là một đơn vị dữ liệu được lưu trữ trong hệ thống Ceph. Mỗi đối tượng có thể là một file, một phần của file hoặc một đơn vị dữ liệu nhỏ hơn. Trong Ceph, các đối tượng được phân chia thành các “Placement Groups” (PGs) để quản lý việc phân tán trên các OSDs.

Dưới đây là sự phân biệt giữa “object” và “Placement Group (PG)” trong Ceph:

  • Đối tượng (Object):
    • Mỗi đối tượng thường tương ứng với một đơn vị dữ liệu cơ bản, có thể là một file hoặc một phần của file.
    • Đối tượng có thể là một đơn vị lớn hoặc nhỏ của dữ liệu và Ceph quản lý cách phân tán và lưu trữ chúng trên toàn bộ cluster.
  • Placement Group (PG):
    • Mỗi đối tượng được phân chia thành các PGs để quản lý việc phân tán và đồng bộ hóa dữ liệu.
    • PG là một đơn vị cơ bản trong quản lý phân tán. Ceph tổ chức và phân phối PGs trên các OSDs để đảm bảo tính phân tán và khả năng chịu lỗi.
    • PG có một số lượng OSDs được chọn để lưu trữ dữ liệu của nó. Mỗi PG cũng có một số lượng min_size và size để xác định số lượng tối thiểu và tối đa của OSDs cần để PG tiếp tục hoạt động.

Như vậy, mỗi đối tượng sẽ được đưa vào một hoặc nhiều PGs và PGs sẽ được quản lý và phân tán trên toàn bộ cluster để đảm bảo hiệu suất, tính phân tán và khả năng chịu lỗi của hệ thống Ceph.

Chẳng hạn như một file ISO của Windows 10, được chia thành các mảnh nhỏ hơn và mỗi mảnh được gọi là một PG (Placement Group). PGs được phân tán trên các OSDs trong Ceph cluster để đảm bảo hiệu suất, khả năng chịu lỗi và sự phân tán của dữ liệu.

4. Ceph Replicas.

Tham số osd_pool_default_sizeosd_pool_default_min_size xác định số lượng bản sao (replicas) của mỗi đối tượng. Các bản sao này được phân tán trên các OSDs khác nhau để đảm bảo sự an toàn và khả năng chịu lỗi.

  • osd_pool_default_min_size:
    • Điều này xác định số lượng tối thiểu các OSDs cần phải hoạt động để đảm bảo tính an toàn của dữ liệu.
    • Giá trị thường được đặt là 2 để đảm bảo có ít nhất 2 bản sao của mỗi đối tượng, giúp ngăn chặn mất mát dữ liệu khi một OSD bị lỗi.
  • osd_pool_default_size:
    • Điều này xác định số lượng bản sao của mỗi đối tượng (replication level).
    • Giá trị thường được đặt là 3 để đảm bảo có 3 bản sao của mỗi đối tượng. Điều này giúp đảm bảo tính an toàn và khả năng chịu lỗi cao.

Quay lại ví dụ ở phần trên với một file ISO của Windows 10, mỗi mảnh của file đó có thể được coi là một PG hoặc một phần của PG và chúng sẽ được phân tán trên các OSDs trong Ceph cluster.

Với osd_pool_default_size = 3osd_pool_default_min_size = 2, khi một đối tượng (hoặc một phần của nó) được ghi vào Ceph, Ceph sẽ tạo ra 3 bản sao của đối tượng đó và phân tán chúng trên ít nhất 2 OSDs khác nhau.

Windows 10 hoặc một PG của Windows 10 có ít nhất có 1 bản sao 1 lưu trữ trên OSD1, bản sao 2 lưu trữ trên OSD2 và OSD3 hoặc bản sao 1 lưu OSD1, bản sao 2 lưu OSD 2, bản sao 3 lưu OSD 3.

Sự phân tán này giúp đảm bảo rằng nếu một OSD hoặc một node gặp sự cố, dữ liệu vẫn sẽ khả dụng từ các bản sao lưu trữ trên các OSD khác. Điều này tăng khả năng chịu lỗi và tin cậy của hệ thống Ceph.

Nhưng để làm rõ hơn, nếu có 10 đối tượng (ví dụ 10 file ISO cài đặt hệ điều hành), mỗi đối tượng có 3 bản sao, thì có thể tồn tại 30 bản sao trên toàn hệ thống (10 đối tượng * 3 bản sao/đối tượng).

5. Bạn có thể mất dữ liệu nếu không hiểu cách mà dữ liệu phân tán.

Cấu hình osd_pool_default_min_sizeosd_pool_default_size có ảnh hưởng đến sự đảm bảo an toàn dữ liệu trong Ceph cluster khi có các node hoặc OSD bị sự cố.

Giả sử bạn có một Ceph cluster với 10 nodes và cấu hình osd_pool_default_min_size = 2osd_pool_default_size = 3, nó có thể xảy ra một tình huống mất dữ liệu khi có 2 nodes bị down, đặc biệt là nếu một đối tượng chỉ có 2 OSDs và cả hai đều đang lưu trữ trên các nodes đã bị down.

Với cài đặt osd_pool_default_min_sizeosd_pool_default_size mặc định như dưới:

  • osd_pool_default_min_size = 2:
    • Yêu cầu ít nhất 2 OSD khả dụng để mỗi đối tượng có thể được lưu trữ an toàn.
  • osd_pool_default_size = 3:
    • Mặc định, mỗi đối tượng sẽ có 3 bản sao được lưu trữ trên 3 OSD khác nhau.

Ví dụ nếu file cài đặt Windows 10 có 3 bản sao và bản sao 1 lưu trữ trên OSD1, bản sao 2 và 3 lưu trữ trên OSD2 và sau đó OSD2 bị down (hoặc node chứa OSD2 bị down), thì chỉ còn lại OSD1 là hoạt động. Trường hợp nếu bạn đặt osd_pool_default_min_size = 2, điều này yêu cầu ít nhất 2 bản sao còn hoạt động để đảm bảo tính an toàn của dữ liệu. Trong trường hợp này, với chỉ có OSD1 còn hoạt động, bạn không đạt được osd_pool_default_min_size và điều này có thể dẫn đến mất mát dữ liệu cho Windows 10.

Để giảm nguy cơ mất dữ liệu trong trường hợp down các nodes, bạn có thể xem xét các cấu hình như tăng osd_pool_default_size để có nhiều bản sao hơn hoặc sử dụng Erasure Coding (EC) pool, tùy thuộc vào yêu cầu và khả năng của hệ thống.

6. Phân tán trong Ceph.

Trong Ceph, khi bạn cấu hình replicas cho một pool, dữ liệu sẽ được phân tán trên các OSD trên các node. Mục tiêu là đảm bảo tính phân tán và khả năng chịu lỗi của hệ thống. Ceph thường sẽ cố gắng tránh phân tán nhiều bản sao trên cùng một node để đảm bảo rằng nếu một node gặp sự cố, dữ liệu vẫn có sẵn từ các bản sao khác trên các node khác.

Tuy nhiên, việc cụ thể làm thế nào Ceph phân tán replicas có thể phụ thuộc vào nhiều yếu tố, bao gồm cấu hình pool, số lượng OSDs, số lượng Placement Groups (PGs) và các cấu hình liên quan khác. Mặc định, Ceph sẽ cố gắng phân tán dữ liệu một cách đồng đều trên các OSDs và nodes.

  • Phân tán trên các OSD khác nodes:
    • Mỗi bản sao của đối tượng được lưu trữ trên OSD thuộc node khác nhau để đảm bảo tính phân tán và khả năng chịu lỗi.
    • Điều này giúp đảm bảo rằng mất mát của một node không ảnh hưởng nhiều đến tính sẵn sàng của dữ liệu.
  • Phân tán trên cùng một node:
    • Đôi khi, trong một số trường hợp, có thể xảy ra tình huống mà một số bản sao của đối tượng được lưu trữ trên cùng một node.
    • Điều này có thể xảy ra khi có ít OSDs trên các nodes, hoặc khi một số OSDs trên các nodes khác nhau bị lỗi.

Ceph cố gắng cân bằng tải và phân tán đối tượng trên toàn bộ cluster. Sự phân tán trên nhiều nodes giúp tăng khả năng chịu lỗi và đồng thời tối ưu hóa hiệu suất. Tuy nhiên, trong một số tình huống đặc biệt, có thể có sự phân tán đối tượng trên cùng một node, nhưng điều này không phải là ưu tiên mặc định của Ceph.

Nếu bạn có một cluster với 5 nodes và bạn cấu hình replicas, Ceph sẽ cố gắng phân tán replicas trên các OSDs thuộc các node khác nhau để đảm bảo tính phân tán và khả năng chịu lỗi.

Ví dụ 1:

Ví dụ đối với file cài đặt Windows 10 có cấu hình replicas 3 trong một cluster Ceph với 5 nodes, các bản sao của file Windows 10 sẽ được phân tán trên 3 trong số 5 nodes. Mục tiêu là đảm bảo rằng dữ liệu được phân tán và có sẵn trên nhiều node khác nhau để tăng tính khả dụng và khả năng chịu lỗi của hệ thống.

Nếu sau đó 2 trong số 5 nodes bị down và cả 2 bản sao của một đối tượng (ví dụ như file Windows 10) nằm trên các nodes đó, thì có thể dẫn đến mất mát dữ liệu.

Với replicas 3, đối tượng cần ít nhất 3 bản sao để đảm bảo tính an toàn và khả năng chịu lỗi. Trong trường hợp của bạn, nếu 2 trong số 3 bản sao bị mất do các nodes bị down, bạn có thể không còn đủ bản sao để tái tạo đối tượng và dữ liệu có thể bị mất.

Để giảm rủi ro mất dữ liệu trong trường hợp down các nodes, bạn có thể xem xét việc tăng số lượng bản sao (replicas) hoặc sử dụng các cơ chế bảo vệ dữ liệu như Erasure Coding (EC), tùy thuộc vào yêu cầu và khả năng của hệ thống.

Vậy tóm lại là nếu bạn cấu hình replicas 3, điều này có nghĩa là mỗi đối tượng sẽ có 3 bản sao và các bản sao này sẽ được phân tán trên 3 nodes khác nhau trong cụm Ceph. Mục tiêu của replicas là tăng tính khả dụng và khả năng chịu lỗi của hệ thống, đảm bảo rằng dữ liệu vẫn sẽ tồn tại và có thể truy cập được nếu có một hoặc hai nodes gặp sự cố. Nếu bạn muốn dữ liệu phân tán trên 4 nodes, bạn có thể cấu hình replicas là 4.

Ví dụ 2:

Nếu cluster của bạn có 10 nodes và bạn cấu hình pool Ceph với osd_pool_default_min_size = 2osd_pool_default_size = 3 và dữ liệu của Windows 10 và Windows 11 được phân tán trên các OSD khác nhau như ví dụ sau:

  • Windows 10: Dữ liệu phân tán trên OSD1 của Node 1, OSD1 của Node 2 và OSD1 của Node 3.
  • Windows 11: Dữ liệu phân tán trên OSD2 của Node 4, OSD2 của Node 5 và OSD2 của Node 6.

Nếu chỉ có Node 1 và Node 2 bị down, điều này chỉ ảnh hưởng đến OSD1 của Node 1 và OSD1 của Node 2. Do đó, Windows 10 sẽ mất vì dữ liệu của nó nằm trên OSD1 của Node 1 và OSD1 của Node 2. Tuy nhiên, Windows 11 sẽ không bị mất, vì dữ liệu của nó nằm trên OSD2 của Node 4, OSD2 của Node 5 và OSD2 của Node 6, không liên quan đến Node 1 và Node 2.

Do đó, chỉ Windows 10 sẽ bị mất trong trường hợp này, không ảnh hưởng đến Windows 11.

Ví dụ 3:

Nếu bạn cấu hình Ceph với pool có osd_pool_default_min_size = 3osd_pool_default_size = 3, tức là mỗi đối tượng sẽ có ít nhất 3 bản sao và tổng số bản sao là 3, thì việc mất 1 node trong tổng số 3 node có thể ảnh hưởng đến tính khả dụng của dữ liệu. Điều này có nghĩa là mỗi đối tượng sẽ có bản sao lưu trữ trên 3 node khác nhau, và nếu một node chết, có thể làm mất mát một bản sao của mỗi đối tượng.

Tuy nhiên, dữ liệu vẫn sẽ khả dụng với ít nhất 2 bản sao còn lại nếu bạn đảm bảo rằng số lượng bản sao (osd_pool_default_size) không ít hơn số lượng OSD đang hoạt động. Điều này giúp đảm bảo rằng mỗi đối tượng vẫn có ít nhất một bản sao trên mỗi OSD còn lại.

Ví dụ 4:

Trong trường hợp bạn có 10 node với mỗi node có 10 OSD, và bạn chạy replica 3 (nghĩa là mỗi đối tượng có 3 bản sao trên 3 node khác nhau), và dữ liệu trong pool vượt quá 85% dung lượng, nếu mất 1 node, có thể xảy ra nguy cơ mất mát một số dữ liệu. Việc này là do khi mất 1 node, các bản sao của đối tượng trên node đó sẽ bị mất, và nếu dữ liệu trong pool vượt quá 85%, có thể không đảm bảo đủ số bản sao trên các node còn lại để duy trì tính khả dụng.

7. Replica với 1 bản sao.

Đối với một hệ thống Ceph cấu hình osd_pool_default_min_size = 1osd_pool_default_size = 3, nếu bạn đảm bảo luôn có ít nhất 2 bản sao đang hoạt động, bạn đạt được sự linh hoạt trong việc duy trì tính khả dụng của dữ liệu.

  • Ưu điểm của cấu hình này là:
    • Tính an toàn: Dữ liệu vẫn tồn tại ngay cả khi chỉ còn một bản sao đang hoạt động.
    • Khả năng chịu lỗi: Hệ thống vẫn có thể tiếp tục hoạt động mặc dù chỉ còn một bản sao.

Tuy nhiên, cần lưu ý rằng nếu bạn không đảm bảo được ít nhất 2 bản sao đang hoạt động, có rủi ro mất dữ liệu nếu có sự cố xảy ra và chỉ còn một bản sao đang hoạt động. Do đó, quan trọng nhất là đảm bảo rằng số lượng bản sao đang hoạt động luôn đủ để đáp ứng osd_pool_default_min_size.

Nói chung, quyết định giữa sự linh hoạt và tính an toàn là một phần của thiết kế hệ thống và yêu cầu cụ thể của ứng dụng. Cấu hình của bạn có thể phản ánh một cân nhắc tốt giữa hiệu suất và tính an toàn dựa trên tình huống sử dụng cụ thể của bạn.

8. Bảo trì OSD.
Khi bạn muốn thực hiện bảo trì hoặc thêm OSD mới vào cụm Ceph mà không mất dữ liệu, bạn có thể thực hiện các bước sau:

  • Chuẩn bị trước bảo trì:
    • Đảm bảo rằng các OSD đang ở trạng thái làm việc bình thường.
    • Kiểm tra xem tỷ lệ sử dụng dung lượng của OSD có thấp hơn giới hạn không.
    • Kiểm tra xem mỗi đối tượng có đủ số bản sao trên các OSD khác nhau hay không.
  • Chuyển dữ liệu ra khỏi OSD cần bảo trì:
    • Sử dụng công cụ như ceph osd out <osd-id> để chuyển dữ liệu ra khỏi OSD cần bảo trì. Việc này đảm bảo rằng không có dữ liệu mới nào được đẩy vào OSD đó trong quá trình bảo trì.
  • Chờ đến khi OSD không có dữ liệu:
    • Kiểm tra xem OSD đã hết dữ liệu chưa trước khi thực hiện bảo trì. Bạn có thể sử dụng câu lệnh ceph osd df để xem thông tin sử dụng dung lượng của các OSD.
  • Đảm bảo tính khả dụng của dữ liệu:
    • Trước khi thực hiện bảo trì, đảm bảo rằng đối tượng và các bản sao của nó vẫn đảm bảo tính khả dụng trên các OSD khác nhau.
  • Thực hiện bảo trì hoặc thêm OSD mới:
    • Nếu bạn đang thêm OSD mới, sau khi OSD đã được thêm vào và sẵn sàng, bạn có thể chuyển dữ liệu lại vào OSD mới theo cách ngược lại, sử dụng câu lệnh ceph osd in <osd-id>.

Lưu ý rằng mặc dù quá trình này giúp giảm nguy cơ mất dữ liệu trong quá trình bảo trì hoặc thêm OSD mới, nhưng vẫn cần cẩn thận và kiểm soát các bước để đảm bảo tính an toàn của dữ liệu. Nếu có thể, thử nghiệm trước quy trình bảo trì trên môi trường sao lưu để đảm bảo sự tin tưởng trong quy trình của bạn.

9. Rủi ro.

Nếu bạn có một Ceph cluster với 10 nodes và pool đang chứa dữ liệu tới 90%, và đột ngột mất một node, đặc biệt là node chứa các OSD đang lưu trữ dữ liệu quan trọng, có nguy cơ mất dữ liệu. Trong trường hợp này, mất một node đồng nghĩa với việc mất một phần quan trọng của dữ liệu, đặc biệt là khi dung lượng lưu trữ đã tiến sát giới hạn.

Để giảm thiểu nguy cơ mất dữ liệu trong trường hợp mất node, có thể xem xét các phương pháp sau:

  • Tăng Dung Lượng Lưu Trữ:
    • Nâng cấp dung lượng lưu trữ để giảm áp lực và giảm nguy cơ mất dữ liệu.
  • Tăng Số Lượng Replica:
    • Cấu hình pool để sử dụng một số lượng bản sao (replica) lớn hơn (ví dụ, replica 3, 4) để dữ liệu được phân tán rộng hơn.
  • Giảm Dung Lượng Dữ Liệu:
    • Xác định và loại bỏ dữ liệu không cần thiết để giảm dung lượng sử dụng.
  • Dùng Erasure Coding:
    • Xem xét sử dụng Erasure Coding (EC) pool thay vì pool replica để tiết kiệm dung lượng lưu trữ.
  • Quản Lý Bảo Trì:
    • Thực hiện các biện pháp bảo trì đều đặn để giảm nguy cơ hỏng hóc và giữ cho hệ thống hoạt động ổn định.

Lưu ý: Khi pool đạt tới giới hạn dung lượng lưu trữ của nó (đã sử dụng gần hết) và đặc biệt là nếu một node bị mất, nguy cơ mất dữ liệu sẽ tăng lên. Điều này đặc biệt quan trọng với các pool được cấu hình để sử dụng replica, nơi mà mất một node có thể làm mất một phần quan trọng của dữ liệu.

Việc quản lý dung lượng lưu trữ còn lại, tăng số lượng replica, sử dụng Erasure Coding, hoặc thậm chí xem xét việc mở rộng dung lượng lưu trữ có thể là các chiến lược để giảm nguy cơ mất dữ liệu trong trường hợp này. Hãy tùy chỉnh chiến lược của bạn dựa trên yêu cầu cụ thể của hệ thống và tài nguyên có sẵn.

  • Nếu dung lượng lưu trữ của pool tiếp cận 100% và bạn đang chạy replica 3, khi mất một node, có thể dữ liệu sẽ bị mất hoặc không khả dụng nếu đối tượng đó hoặc một số bản sao của nó nằm trên OSD thuộc node bị mất.
    • Chạy replica 3 có nghĩa là mỗi đối tượng sẽ có ba bản sao, phân tán trên ba OSD khác nhau. Nếu dung lượng lưu trữ đang tiếp cận 100%, mất một node có thể làm giảm sức mạnh định chủ của replica, dẫn đến mất dữ liệu.
    • Để giảm rủi ro mất dữ liệu, bạn nên giữ một phần trống trong pool để đảm bảo không gian lưu trữ đủ cho quá trình tái tạo dữ liệu sau khi có sự cố mất mát. Việc giữ khoảng trống này cũng giúp tránh tình trạng tỷ lệ sử dụng 100% và giúp hệ thống có đủ dung lượng để xử lý các quá trình tự động khi có sự cố xảy ra.
  • Trong một mô hình Ceph với 3 nodes và 30 OSDs chia đều cho 3 nodes, nếu pool chạy với cấu hình osd_pool_default_min_size = 3osd_pool_default_size = 3, điều này có nghĩa là pool yêu cầu tối thiểu 3 OSDs hoạt động để đảm bảo tính an toàn.
    • Khi một node (chứa nhiều OSDs) bị down, pool vẫn còn đọc và ghi dữ liệu bình thường, vì còn 2 nodes khác với 20 OSDs hoạt động. Hệ thống Ceph sẽ tự động chuyển dữ liệu cho OSDs hoạt động khi có sự cố xảy ra.
    • Tuy nhiên, cần lưu ý rằng việc mất một node vẫn có thể ảnh hưởng đến hiệu suất và khả năng mở rộng của hệ thống, vì dung lượng và băng thông của hệ thống Ceph sẽ giảm đi. Mức độ ảnh hưởng này phụ thuộc vào cách mà dữ liệu của bạn được phân phối và làm sao các PG (Placement Groups) được triển khai. Một kích thước PG phù hợp có thể giúp giảm thiểu ảnh hưởng từ việc mất một node.
  • Khi một node bị down trong một cụm Ceph, thì không phải cả pool đều bị mất. Dữ liệu trên Ceph được phân phối thành các PG (Placement Groups) và PGs này được triển khai trên các OSDs trong cluster.
    • Nếu một node chứa một số OSDs bị down, các PGs được triển khai trên OSDs đó sẽ bị chuyển đến các OSDs khác trong cluster. Trong trường hợp cấu hình osd_pool_default_size = 3, dữ liệu sẽ vẫn tồn tại trên các OSDs khác (nếu có đủ OSDs hoạt động để đảm bảo osd_pool_default_min_size = 3).
    • Việc mất một node không đồng nghĩa với việc mất toàn bộ pool, nhưng có thể ảnh hưởng đến một số dữ liệu tùy thuộc vào cách mà dữ liệu được phân phối và cấu hình PG. Ceph sẽ cố gắng di chuyển dữ liệu để đảm bảo tính an toàn và sẵn sàng của hệ thống.

1 COMMENT

  1. Great article, but you are missing some details:

    – The main one: The CRUSH algorithm, it is the heart of Ceph! is the one in charge of the placement of the data. As part of the deployment you should choose how to store the data, usually a PG and OSD replicate data beneath the node/chassis, this means that even if you loose a server other 2 copies (min copies set to 2) are beyond the lost server/chassis. Check out the Ceph structure of region/datacenter/rack, etc.

    To clarify on data loss with just one copy:

    – Usually when you setup a Ceph cluster the min replicas = 2, means that when you loose two nodes/chassis and you are in a situation with just 1 osd/copy of the data Ceph will lock that copy as read-only, to prevent you from modify it or lose it. Of course in the event of damage to that only copy you lose it.

    As a general best practice (defaults in Ceph):
    – Keep copies in different chassis;
    – keep at leas 2 min copies, and 3 copies of data;
    – Have an odd number of osds and servers;
    – When you calculate the storage needs keep in mind that the total space available (24TB for 3 disks o 8TB each) should be used at 1/3 (33%) if you are using 3 copies. Beyond that space you are pushing the barriers to dark waters and can get into problems.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

4,956FansLike
256FollowersFollow
223SubscribersSubscribe
spot_img

Related Stories