I. Designing and Sizing vSAN Storage Components
1. Planning Capacity in vSAN
Tính plan dựa trên dung lượng vm và số lượng các failures and maintenance cần taọ
2. Raw Capacity
– vSAN cần một phần không gian để sử dụng cho các metadata, cấu trúc dữ liệu, và các quy trình quản lý nội bộ khác. Đây được gọi là overhead
– Dung lượng lưu trữ thô (Raw Capacity) được tính bằng cách nhân tổng số nhóm đĩa (disk group) với dung lượng các đĩa trong những nhóm đĩa đó. Sau đó, trừ đi phần chi phí (overhead) yêu cầu bởi định dạng đĩa của vSAN để có được dung lượng khả dụng thực tế.
### Ví dụ minh họa:
– Giả sử bạn có một vSAN cluster với 3 host.
– Mỗi host có 2 nhóm đĩa.
– Mỗi nhóm đĩa có dung lượng đĩa là 10 TB.
Bước 1: Xác định tổng số nhóm đĩa:
– Tổng số nhóm đĩa = Số host x Số nhóm đĩa mỗi host = 3 x 2 = 6 nhóm đĩa.
Bước 2: Xác định kích thước thiết bị dung lượng trong mỗi nhóm đĩa:
– Kích thước thiết bị dung lượng = 10 TB.
Bước 3: Tính dung lượng lưu trữ thô:
– Dung lượng lưu trữ thô = Tổng số nhóm đĩa x Kích thước thiết bị dung lượng = 6 x 10 TB = 60 TB.
Bước 4: Trừ chi phí overhead:
Giả sử overhead của vSAN cần là 5 TB.
Dung lượng khả dụng thực tế = Dung lượng lưu trữ thô – Overhead = 60 TB – 5 TB = 65 TB
3. Primary Level of Failures to Tolerare
- Khi bạn lập kế hoạch dung lượng cho vSAN datastore, ngoài việc tính toán số lượng máy ảo và kích thước các file VMDK của chúng, bạn cần xem xét thêm hai yếu tố quan trọng:
+ Primary level of failures to tolerate (PFTT): Mức độ lỗi chính mà hệ thống cần chịu đựng.
+ Failure tolerance method: Phương pháp chịu lỗi của chính sách lưu trữ máy ảo trong cluster.
– Khi bạn cấu hình dung lượng chịu lỗi, dữ liệu được sao chép và lưu trữ trên nhiều đĩa hoặc nhóm đĩa (disk groups) khác nhau.
– Ví dụ, với RAID 1 (mirroring), dữ liệu được sao chép 1:1, tức là bạn có một bản sao của dữ liệu trên một đĩa khác. Điều này dẫn đến việc dung lượng khả dụng giảm một nửa.
– Mức độ lỗi chính đóng vai trò quan trọng khi bạn lập kế hoạch và định kích thước dung lượng lưu trữ cho vSAN. Dựa trên yêu cầu về độ sẵn sàng của một máy ảo, cài đặt PFTT có thể dẫn đến việc tiêu thụ dung lượng tăng gấp đôi hoặc hơn so với dung lượng mà máy ảo và các thiết bị chia sẻ của nó thực sự sử dụng.
### Ví dụ Biểu Thị:
– Khi Failure tolerance method được đặt với chế độ RAID-1 (Mirroring) – Performance:
* PFTT được đặt là 1 (chịu được một lỗi phần cứng): Chỉ có thể sử dụng khoảng 50% dung lượng thô vì dữ liệu được nhân đôi để đảm bảo an toàn.
* PFTT được đặt là 2 (chịu được hai lỗi phần cứng): Chỉ sử dụng khoảng 33% vì dữ liệu được lưu trữ theo cơ chế sw bộ ba để đảm bảo an toàn
* PFTT được đặt là 3 (chịu được ba lỗi phần cứng): Chỉ sử dụng khoảng 25% vì dữ liệu được nhân bốn lần để đảm bảo an toàn
– Khi Failure tolerance method is RAID-5/6 (Erasure Coding) – Capacity:
* PFTT được đặt là 1 (chịu được một lỗi phần cứng): Máy ảo có thể sử dụng khoảng 75% dung lượng thô.
* PFTT được đặt là 2 (chịu được hai lỗi phần cứng): Dung lượng khả dụng giảm còn khoảng 67%.
*Cụ thể: Disk vm được tạo là 100G với PFTT được đặt là 1 và Failure tolerance method được đặt với chế độ RAID-1 (Mirroring), thì tổng dung lượng thô sẽ sử dụng là 100/50% = 200GB
4. Calculating Required Capacity
Khi bạn lập kế hoạch dung lượng cần thiết cho các máy ảo trong một cluster sử dụng RAID 1 (mirroring), bạn cần dựa trên các tiêu chí sau:
* Tính toán dung lượng lưu trữ dự kiến cho các máy ảo trong vSAN:
– Công thức: Dung lượng tiêu thụ dự kiến = số lượng VMs trong cluster * % tiêu thụ dự kiến mỗi VMDK* dung lượng vmdk thực tế
* Xem xét thuộc tính mức độ lỗi chính (Primary level of failures to tolerate – PFTT):
– Thuộc tính này được cấu hình trong các chính sách lưu trữ cho các máy ảo trong cluster.
– PFTT ảnh hưởng trực tiếp đến số lượng bản sao (replicas) của một tệp VMDK trên các host trong cluster.
– Công thức: Dung lượng datastore = Dung lượng tiêu thụ dự kiến * (PFTT + 1)
– Điều này có nghĩa là dung lượng tiêu thụ tổng thể sẽ được nhân lên với (PFTT + 1) để tính toán dung lượng cần thiết cho việc chịu lỗi.
* Ước tính dung lượng overhead của định dạng vSAN on-disk:
– Phiên bản 3.0 và mới hơn: Thêm overhead khoảng 1-2% dung lượng cho mỗi thiết bị lưu trữ.
– Phiên bản 2.0: Thêm overhead không quá 1-2% dung lượng cho mỗi thiết bị lưu trữ.
– Phiên bản 1.0: Thêm overhead khoảng 1 GB cho mỗi thiết bị lưu trữ.
* Ví dụ cụ thể:
– Giả sử bạn có 10 máy ảo dung lượng 1Gb trong cluster và dự kiến mỗi VMDK sẽ tiêu thụ 50% dung lượng.
– Tính dung lượng tiêu thụ dự kiến:
= 10 VMs * 50% * 1 = 5Gb (dung lượng tiêu thụ dự kiến)
– Nếu PFTT được cài đặt là 1:
– Dung lượng datastore = 5 * (1 + 1) = 10
– Nếu PFTT được cài đặt là 2:
– Dung lượng datastore = 5 * (2 + 1) = 15
5. Capacity Sizing Guidelines
- Giữ ít nhất 30% dung lượng trống: Đảm bảo rằng luôn có ít nhất 30% dung lượng trống trên vSAN để tránh việc tự động cân bằng lại tải lưu trữ. Khi một thiết bị lưu trữ đạt đến 80% dung lượng, vSAN sẽ tự động cân bằng lại (di chuyển dữ liệu) để giảm tải, điều này có thể ảnh hưởng đến hiệu suất của các ứng dụng. Để tránh điều này, hãy giữ mức sử dụng lưu trữ dưới 70%.
- Lên kế hoạch cho dung lượng dự phòng: Chuẩn bị thêm dung lượng để đối phó với các tình huống hỏng hóc hoặc thay thế thiết bị lưu trữ, nhóm đĩa, hoặc host. Khi một thiết bị lưu trữ không sẵn sàng, vSAN sẽ khôi phục dữ liệu từ một thiết bị khác trong cluster.
- Dung lượng dự phòng sau hỏng hóc hoặc bảo trì: Dự phòng thêm dung lượng để đảm bảo rằng vSAN có thể khôi phục dữ liệu sau khi một host bị hỏng hoặc khi host vào chế độ bảo trì. Ví dụ, đảm bảo rằng host có đủ dung lượng để lưu trữ dự phòng và khôi phục dữ liệu cần thiết khi một host khác gặp sự cố. Việc này đặc biệt quan trọng khi bạn có nhiều hơn ba host.
- Dung lượng tạm thời cho thay đổi chính sách lưu trữ VM của vSAN: Cung cấp đủ dung lượng lưu trữ tạm thời cho những thay đổi trong chính sách lưu trữ VM. Khi bạn thay đổi chính sách lưu trữ VM, vSAN có thể tạo ra một cấu trúc RAID mới cho đối tượng. Quá trình này có thể tạm thời sử dụng thêm dung lượng.
- Dung lượng cho tính năng nâng cao: Nếu bạn định sử dụng các tính năng nâng cao như kiểm tra phần mềm hoặc nén và phân loại, hãy dự phòng thêm dung lượng để xử lý các tác vụ này.
- Lên kế hoạch cho dung lượng lưu trữ trong vSAN: Khi lên kế hoạch dung lượng lưu trữ cho vSAN datastore, cần xem xét tất cả không gian cần thiết cho các đối tượng khác nhau như VM home namespace objects, snapshots, và swap files.
6. Design Considerations for Flash Caching Devices in vSAN
- Choosing Between PCIe or SSD Flash Devices
- Flash Devices as vSAN Cache
–> Hybrid configurations
– Thiết bị bộ nhớ đệm flash (flash caching device) phải cung cấp ít nhất 10% dung lượng lưu trữ dự kiến mà các máy ảo sẽ sử dụng, không bao gồm các bản sao như mirrors.
– Mức độ chấp nhận lỗi chính (Primary level of failures to tolerate) từ chính sách lưu trữ của VM không ảnh hưởng đến kích thước của bộ nhớ đệm.
- Design Considerations for Magnetic Disks in vSAN
– Plan a magnetic disk configuration by following these guidelines:
Để cải thiện hiệu suất của vSAN, So với việc dùng một số ít thiết bị có dung lượng lưu trữ lớn nên sử dụng nhiều đĩa từ có dung lượng nhỏ hơn nhằm tối ưu hóa hiệu suất đọc/ghi và quá trình destaging (quá trình di chuyển dữ liệu từ bộ nhớ đệm flash xuống đĩa cứng), cũng như duy trì tính nhất quán trong việc lựa chọn cùng loại đĩa từ và mô hình của các đĩa từ. Đồng thời, cần phải xác định số lượng đĩa đủ để đáp ứng các chính sách lưu trữ (storage pilocy) đã định.
- Design Considerations for Storage Controllers in vSAN
Để có hiệu suất tốt nhất, hãy sử dụng bộ điều khiển ở chế độ passthrough:
– Bộ điều khiển ở chế độ passthrough (hoạt động như một điểm thông qua không làm thay đổi dữ liệu đi vào) mang lại hiệu suất tốt hơn so với việc cấu hình ở chế độ RAID 0. Điều này là do chế độ RAID 0 đòi hỏi nhiều công cụ cấu hình và bảo trì hơn.
7. Designing and Sizing vSAN Hosts
- Memory and CPU
Memory: At least 32-GB memory for fully operational vSAN with 5 disk groups per host and 7 capacity devices per disk group
CPU: 10% CPU overhead for vSAN
- Host Networking: recommend using 10-GbE
- Multiple Disk Groups:
Sử dụng nhiều nhóm đĩa (disk groups):
Lợi ích:
– Hiệu suất được cải thiện: Việc sử dụng nhiều nhóm đĩa đồng nghĩa với việc có nhiều bộ nhớ đệm (cache) hơn được tổng hợp, giúp nâng cao tốc độ xử lý các thao tác I/O.
– Giảm rủi ro sự cố: Khi có nhiều nhóm đĩa, rủi ro sự cố được phân chia, do có ít khả năng một sự cố sẽ ảnh hưởng đến toàn bộ hệ thống.
– Quá trình phục hồi nhanh chóng hơn: Nếu một nhóm đĩa thất bại, vSAN chỉ cần xây dựng lại ít thành phần hơn, giảm thời gian và nâng cao hiệu suất tổng thể trong quá trình phục hồi.
Bất lợi:
– Chi phí tăng lên: Cần có hai hoặc nhiều thiết bị caching hơn, dẫn đến việc tăng chi phí đầu tư ban đầu.
– Đòi hỏi nhiều bộ nhớ RAM hơn: Khi có nhiều nhóm đĩa, bộ nhớ cần thiết để xử lý cũng tăng lên tương ứng.
– Cần nhiều bộ điều khiển lưu trữ (storage controllers): Để giảm thiểu rủi ro từ điểm lỗi đơn (single point of failure), phải sử dụng nhiều bộ điều khiển.
- Drive Bays: hỗ trợ Pcie
- Hot Plug and Swap of Devices: nên config passthrough
8. Design Considerations for a vSAN Cluster
- Sizing the vSAN Cluster for Failures to Tolerate
Cấu hình Primary level of failures to tolerate (PFTT) trong VM storage policies để xử lý trong trường hợp host lỗi, do vậy số host cần cho cluster dduc tính toán như sau: 2 * PFTT + 1
Nếu cluster host kết nối trong racks server, bạn phải tổ chức các host trong fault domain
- Limitations of a Two-Host or Three-Host Cluster Configuration
– Khả năng chịu lỗi chỉ dành cho một host:
– Nếu bạn thiết lập chỉ số “số lỗi để có thể chịu đựng” (number of failures to tolerate) là 1, hệ thống chỉ có thể chịu đựng được khi một máy chủ gặp sự cố. vSAN lưu hai bản sao đòi hỏi của dữ liệu máy ảo trên hai máy chủ riêng biệt, và đối tượng chứng nhân (witness object) trên máy chủ thứ ba.
– Hạn chế do số lượng máy chủ nhỏ:
– Phục hồi dữ liệu: Khi một máy chủ gặp sự cố, vSAN không thể phục hồi dữ liệu trên máy chủ khác để bảo vệ trước một lỗi khác.
– Chế độ bảo trì (maintenance mode): Nếu một máy chủ cần vào chế độ bảo trì, vSAN không thể di tản dữ liệu ra khỏi máy chủ để duy trì tuân thủ chính sách. Trong khi máy chủ đang ở chế độ bảo trì, dữ liệu có nguy cơ gặp phải một sự cố hoặc không thể truy cập nếu có một lỗi bổ sung xảy ra.
– Tùy chọn di tản dữ liệu:
– Bạn chỉ có thể sử dụng tùy chọn “Đảm bảo khả năng truy cập dữ liệu” (Ensure data accessibility). Tùy chọn này đảm bảo rằng đối tượng sẽ vẫn khả dụng trong quá trình di chuyển dữ liệu, mặc dù nó có thể gặp rủi ro nếu có thêm lỗi xảy ra sau đó.
– Không tuân thủ chính sách trong các cluster có hai hoặc ba hosts:
– Các đối tượng vSAN trên cụm có hai hoặc ba máy chủ không tuân thủ chính sách. Khi máy chủ thoát khỏi chế độ bảo trì, các đối tượng sẽ được xây dựng lại để đảm bảo tuân thủ chính sách.
- Balanced and Unbalanced Cluster Configuration
vSAN hoạt động hiệu quả nhất khi các máy chủ trong cụm (cluster) có cấu hình đồng nhất. Nếu sử dụng các máy chủ với cấu hình khác nhau, sẽ có một số bất lợi như sau:
Giảm khả năng dự đoán về hiệu suất lưu trữ:
Các quy trình bảo trì khác nhau:
Hiệu suất giảm trên máy chủ có cấu hình thấp hơn:
- Deploying vCenter Server on vSAN
9. Designing the vSAN Network
9.1. Networking Failover and Load Balancing
- vSAN uses the teaming and failover policy configured on the virtual switch for network redundancy only. vSAN does not use NIC teaming for load balancing
- vSAN hỗ trợ cân bằng tải IP-hash, nhưng không thể đảm bảo cải thiện hiệu suất cho tất cả cấu hình, nên sử dung phương thức này nếu vsan sử dụng nhiều đường network để kết nối.
9.2. Using Unicast in vSAN Network
– Trong những phiên bản sớm hơn của vSAN, multicast cần thiết để kích hoạt các tín hiệu (heartbeat) và trao đổi siêu dữ liệu (metadata) giữa các máy chủ trong cụm. Multicast giúp các host nằm trong cùng một cụm đồng bộ hóa và quản lý thông tin mạng một cách hiệu quả.
– Từ phiên bản 6.6 trở đi, VMware đã loại bỏ yêu cầu về việc sử dụng multicast trên các switch vật lý hỗ trợ cụm vSAN. Điều này có nghĩa là bạn có thể thiết kế một mạng unicast đơn giản cho vSAN mà không cần thiết lập multicast.
9.3. Allocating Bandwidth for vSAN by Using Network I/O Control
– Traffic của vSAN có thể chia sẻ adapter mạng vật lý 10-GbE với các loại traffic khác của hệ thống, như traffic của vSphere vMotion, vSphere HA, và traffic của máy ảo. Để đảm bảo lượng băng thông yêu cầu cho vSAN, hãy sử dụng vSphere Network I/O Control trong vSphere Distributed Switch. Trong vSphere Network I/O Control, bạn có thể cấu hình chia sẻ traffic của vSAN.
– Đặt chia sẻ để khi adapter vật lý được chỉ định cho vSAN bị sử dụng hết công suất, vSAN vẫn có đủ băng thông cần thiết nhằm ngăn vSAN tiêu thụ toàn bộ khả năng của adapter vật lý trong khi thực hiện các hoạt động tái xây dựng và đồng bộ hóa.
– Ví dụ, trên một adapter vật lý 10-GbE xử lý traffic cho vSAN, vSphere vMotion, và các máy ảo, bạn có thể cấu hình băng thông và chia sẻ cụ thể. Nếu bộ điều hợp 10-GbE trở nên bão hòa, Bộ điều khiển I/O Mạng sẽ phân bổ 5 Gbps cho vSAN trên mạng vật ly.
9.4. Marking vSAN Traffic
sử dụng priority tagging – một cơ chế dùng để chỉ dẫn cho các thiết bị mạng kết nối rằng traffic của vSAN yêu cầu một chất lượng dịch vụ (QoS – Quality of Service) cao:
*Priority Tagging:
– Là cách thức xác định mức độ ưu tiên của giao thông mạng vSAN để các thiết bị mạng có thể nhận biết và xử lý nó một cách thích hợp. Điều này giúp quản lý tốt hơn nguồn lực mạng, đặc biệt là khi hệ thống đối mặt với tình trạng quá tải.
*Quality of Service (QoS):
– Đây là yếu tố đảm bảo rằng traffic quan trọng như của vSAN nhận được đủ băng thông và không bị ảnh hưởng bởi các loại traffic khác. QoS quản lý và phân phối tài nguyên mạng để tuân theo yêu cầu về hiệu suất cho các dịch vụ khác nhau.
*Class of Service (CoS):
– CoS là giá trị được sử dụng để đánh dấu gói tin mạng, với mục đích xác định mức độ ưu tiên từ thấp đến cao. CoS có thể được gán với các giá trị từ 0 (ưu tiên thấp) đến 7 (ưu tiên cao). Việc gán giá trị CoS này giúp xác định mức độ ưu tiên trong việc xử lý dữ liệu.
=> Bạn có thể sử dụng traffic filtering and marking policy của vSphere Distributed Switch để cấu hình các mức độ ưu tiên này, từ đó kiểm soát chất lượng dịch vụ của vSAN một cách tinh tế và linh hoạt hơn.
9.5. Jumbo Frames
* Jumbo Frames và vSAN:
– Jumbo frames là các gói dữ liệu có kích thước lớn hơn so với kích thước tiêu chuẩn (thường là 1500 bytes). Việc sử dụng jumbo frames có thể giúp giảm tải cho CPU bằng cách giảm số lượng gói tin cần xử lý mỗi lần truyền dữ liệu. Điều này được xem xét như một cách để cải thiện hiệu suất làm việc của CPU trong môi trường vSAN.
* Kích Hoạt Jumbo Frames:
– Khi bạn quyết định sử dụng jumbo frames, điều quan trọng là cần phải đảm bảo rằng jumbo frames được kích hoạt trên tất cả các thiết bị mạng và host trong cụm. Điều này yêu cầu sự đồng bộ trong cấu hình mạng trên toàn bộ hệ thống, bởi vì bất kỳ thiết bị nào không hỗ trợ hoặc không được kích hoạt có thể gây ra mất mát gói tin hoặc giảm hiệu suất mạng.
* TCP Segmentation Offload (TSO) và Large Receive Offload (LRO):
– TSO và LRO là các tính năng được kích hoạt mặc định trên ESXi để cải thiện hiệu suất chuyển tiếp gói tin. TSO giúp giảm tải CPU bằng cách offload công việc phân mảnh gói tin TCP ra khỏi CPU, trong khi LRO giúp tăng hiệu suất nhận gói dữ liệu bằng cách gộp nhiều gói tin nhỏ thành một gói lớn hơn trước khi xử lý.
Tóm lại, việc sử dụng jumbo frames trong môi trường vSAN có thể là một giải pháp hữu ích để tăng cường hiệu suất CPU bằng cách giảm tải xử lý dữ liệu. Tuy nhiên, quyết định này cần được cân nhắc kỹ lưỡng về mặt lợi ích và chi phí, cũng như sự tương thích giữa tất cả các thiết bị trong cụm.
9.6. Creating Static Routes for vSAN Networking
Bạn có thể cần tạo các định tuyến tĩnh trong môi trường vSAN của mình.
Trong các cấu hình truyền thống, trong đó vSphere sử dụng một cổng mặc định duy nhất, tất cả lưu lượng truy cập được định tuyến đều cố gắng đến đích thông qua cổng này.
Tuy nhiên, một số triển khai vSAN nhất định có thể yêu cầu định tuyến tĩnh.
Ví dụ: các triển khai trong đó witness ở trên một mạng khác hoặc triển khai cụm mở rộng, trong đó cả data sites and the witness host ở các sites khác nhau.
Command: “esxcli network ip route ipv4 add -g gateway-to-use –n remote-network
9.7. Best practice
– Đối với hybrid configurations, hãy dành riêng physical network adapter ít nhất 1 GbE. Khuyến cáo nên Đặt lưu lượng vSAN trên một physical network adapter 10 GbE có thể chuyên dụng hoặc dùng chung để có hiệu suất mạng tốt nhất.
– Đối với cấu hình all-flash, hãy sử dụng physical network adapter 10 GbE chuyên dụng hoặc dùng chung.
– Cung cấp thêm một NIC vật lý làm NIC chuyển đổi dự phòng.
– Nếu bạn sử dụng bộ điều hợp mạng 10 GbE dùng chung, hãy đặt lưu lượng vSAN trên physical network adapter và configure Network I/O Control để đảm bảo băng thông cho vSAN
10. Designing and Sizing vSAN Fault Domains
10.1. Fault Domains trong vSAN:
– vSAN yêu cầu ít nhất phải có ba fault domains để hỗ trợ tỷ lệ bảo vệ lỗi chịu được (PFTT = Primary Failures to Tolerate) bằng 1. Tức là, vSAN có thể chịu được một lỗi không mong muốn mà không mất dữ liệu.
* Cấu trúc của một Fault Domain:
Mỗi fault domain bao gồm một hoặc nhiều máy chủ (hosts). Định nghĩa fault domain phải nhận diện các cấu trúc phần cứng vật lý có thể gây ra rủi ro lỗi, như một chiếc rack tính toán.
* Khuyến nghị Sử Dụng Tối thiểu Bốn Fault Domains:
Việc sử dụng chỉ ba fault domains không hỗ trợ một số chế độ di tản dữ liệu và vSAN sẽ không thể bảo vệ lại dữ liệu sau khi xảy ra lỗi. Do đó, một fault domain thứ tư (hoặc nhiều hơn) thường được khuyến nghị để có đủ khả năng xây dựng lại dữ liệu sau khi một sự cố xảy ra.
* Khả Năng Xây Dựng Lại sau Sự Cố:
Trong trường hợp có một sự cố, bạn sẽ cần một fault domain bổ sung có khả năng dung lượng để có thể tái xây dựng dữ liệu. Điều này không thể được đảm bảo nếu chỉ có ba fault domains.
* Cách vSAN Áp dụng Chính Sách Lưu Trữ:
– Nếu fault domains được kích hoạt, vSAN sẽ áp dụng chính sách lưu trữ của máy ảo (virtual machine storage policy) lên các fault domains thay vì áp dụng cho từng host một. Điều này giúp chính sách lưu trữ phản ánh đúng mức độ chịu đựng lỗi đã được định cấu hình cho một nhóm các host thay vì một host đơn lẻ, nâng cao hiệu suất bảo vệ dữ liệu trong môi trường ảo.
* Cách tính number of fault domains in a cluster based on the Primary level of failures to tolerate (PFTT) attribute from the storage policies:
number of fault domains = 2 * PFTT + 1
10.2. Using Fault Domains Against Failures of Several Hosts
sử dụng fault domains trong một cụm (cluster) với mục đích cải thiện độ tin cậy và khả năng chịu lỗi của hệ thống lưu trữ vSAN:
– Xem xét một cluster chứa bốn server rack, mỗi rack có hai host. Điều này tạo ra một hệ thống với tám host.
– Nếu cấp độ chịu đựng lỗi sơ cấp (Primary level of failures to tolerate – PFTT) được đặt là 1, nghĩa là hệ thống có khả năng chịu đựng ít nhất một lỗi mà không bị mất dữ liệu.
– Nếu fault domains không được kích hoạt, vSAN có thể lưu trữ cả hai bản sao của một đối tượng trên các host trong cùng một rack, gây ra nguy cơ mất dữ liệu do lỗi cấp rack.
– Nếu fault domains được kích hoạt khi cấu hình các host có khả năng lỗi cùng nhau vào các fault domains riêng biệt, vSAN đảm bảo rằng mỗi thành phần bảo vệ (replicas và witnesses) được đặt trong các fault domains khác nhau để giảm thiểu rủi ro và mất mát.
– Khi thêm host và dung lượng, bạn có thể sử dụng cấu hình fault domain hiện có hoặc xác định mới.
=> Hướng Dẫn Sử Dụng Fault Domains:
– Để cân bằng tải lưu trữ và độ chịu lỗi khi sử dụng fault domains, hãy cân nhắc các hướng dẫn sau:
– Tạo đủ số lượng fault domains để đáp ứng mức độ chịu đựng lỗi sơ cấp được cấu hình trong các chính sách lưu trữ.
– Xác định ít nhất ba fault domains, nhưng nên có tối thiểu bốn domains để đạt được mức bảo vệ tốt nhất.
– Phân bổ số lượng host bằng nhau cho mỗi fault domain.
– Sử dụng các host có cấu hình đồng nhất.
– Nếu có thể, dành riêng một fault domain có dung lượng trống để tái xây dựng dữ liệu sau khi xảy ra lỗi.
Tóm lại, việc hiểu rõ và sử dụng đúng cách fault domains trong vSan giúp tối ưu hóa khả năng phục hồi và giảm thiểu rủi ro mất mát dữ liệu do sự cố phần cứng hoặc lỗi hệ thống. Khuyến nghị trên cung cấp một khung cách tiếp cận hợp lý cho việc cấu hình và quản lý các fault domains trong môi trường vSAN.