Định cỡ VMware VMFS5 và LUN - nhiều kho dữ liệu nhỏ hơn hoặc 1 kho dữ liệu lớn?

Với VMFS5 không còn giới hạn 2TB cho khối lượng VMFS, tôi đang xem xét kịch bản nào sẽ có lợi hơn về tổng thể: -

• Ít LUN có kích thước lớn hơn, hoặc
• Nhiều LUN có kích thước nhỏ hơn.

Trong trường hợp của tôi, tôi có một mảng lưu trữ 24 đĩa mới với 600GB đĩa. Tôi sẽ sử dụng RAID10, khoảng 7.2TB và cố gắng quyết định xem có nên sử dụng 1 kho dữ liệu lớn 7TB hay nhiều cửa hàng mỗi ổ 1TB.

Những ưu và nhược điểm của từng phương pháp là gì?

Cập nhật : Tất nhiên, tôi đã bỏ qua việc đưa các phụ tùng nóng vào tính toán của mình, vì vậy nó sẽ chỉ dưới 7.2TB, nhưng ý tưởng chung là như vậy. :-)

Cập nhật 2 : Có 60 VM và 3 host. Không có máy ảo nào của chúng tôi đặc biệt là I / O chuyên sâu. Hầu hết trong số họ là máy chủ web / ứng dụng và những thứ như giám sát (munin / nagios), 2 DC Windows với tải tối thiểu, v.v. Các máy chủ DB hiếm khi được ảo hóa trừ khi chúng có các yêu cầu I / O RẤT thấp. Ngay bây giờ tôi nghĩ rằng máy chủ DB ảo duy nhất chúng tôi có là hộp MSSQL và DB trên hộp đó là <1GB.

Cập nhật 3 : Một số thông tin thêm về kết nối mảng và FC. Mảng là một bộ điều khiển IBM DS3524, 2 bộ điều khiển với bộ nhớ cache 2GB mỗi bộ. Cổng 4x 8Gbit FC trên mỗi bộ điều khiển. Mỗi máy chủ ESXi có gấp đôi HBA 4Gbit.

Bạn đã không chỉ định có bao nhiêu máy ảo bạn có hoặc chúng sẽ làm gì. Ngay cả khi không có thông tin đó, tôi vẫn tránh một người tạo ra một LUN lớn vì lý do chặn / hiệu suất, sự tranh chấp và tính linh hoạt.

Tôi sẽ cho rằng bạn sẽ ảo hóa máy chủ, không phải máy tính để bàn, phải không? Tiếp theo tôi sẽ giả định rằng bạn sẽ sử dụng một số máy chủ ESX / ESXi để truy cập vào bộ lưu trữ của bạn và được quản lý bởi vCenter Server.

Khi quyết định kích thước LUN và số lượng VMFS bạn đang cân bằng một số yếu tố: hiệu suất, tính linh hoạt cấu hình và sử dụng tài nguyên, trong khi bị ràng buộc bởi cấu hình tối đa được hỗ trợ của cơ sở hạ tầng của bạn.

Bạn có thể có được hiệu suất tốt nhất với ánh xạ 1 VM đến 1 LUN / VMFS. Không có sự cạnh tranh giữa các máy trên cùng một VMFS, không có sự tranh chấp khóa, mỗi tải được tách ra và tất cả đều là goood. Vấn đề là bạn sẽ quản lý một lượng LUN vô duyên, có thể đạt giới hạn tối đa được hỗ trợ, phải đối mặt với việc thay đổi kích thước và di chuyển VMFS, đã sử dụng hết tài nguyên (không gian trống phần trăm duy nhất trên VMFS) và nói chung tạo ra một thứ quản lý không tốt

Một thái cực khác là một VMFS lớn được chỉ định để lưu trữ mọi thứ. Bạn sẽ có được việc sử dụng tài nguyên tốt nhất theo cách đó, sẽ không có vấn đề gì khi quyết định triển khai ở đâu và vấn đề với VMFS X là một điểm nóng, trong khi VMFS Y không hoạt động. Chi phí sẽ là hiệu suất tổng hợp. Tại sao? Vì khóa. Khi một ESX đang ghi vào một VMFS nhất định, các ESX khác sẽ bị khóa trong thời gian cần thiết để hoàn thành IO và phải thử lại. Chi phí này hiệu suất. Môi trường sân chơi / thử nghiệm và phát triển bên ngoài, đó là cách tiếp cận sai đối với cấu hình lưu trữ.

Thực tiễn được chấp nhận là tạo ra các kho dữ liệu đủ lớn để lưu trữ một số máy ảo và chia không gian lưu trữ có sẵn thành các khối có kích thước phù hợp. Số lượng máy ảo phụ thuộc vào máy ảo. Bạn có thể muốn một hoặc một vài cơ sở dữ liệu sản xuất quan trọng trên VMFS, nhưng cho phép ba hoặc bốn tá máy thử nghiệm và phát triển trên cùng một kho dữ liệu. Số lượng VM trên mỗi kho dữ liệu cũng phụ thuộc vào phần cứng của bạn (kích thước ổ đĩa, vòng / phút, bộ đệm của bộ điều khiển, v.v.) và các mẫu truy cập (đối với bất kỳ mức hiệu suất cụ thể nào, bạn có thể lưu trữ nhiều máy chủ web hơn trên cùng một VMFS so với máy chủ thư).

Kho dữ liệu nhỏ hơn cũng có một lợi thế nữa: chúng ngăn bạn vật lý nhồi nhét quá nhiều máy ảo trên mỗi kho dữ liệu. Không có áp lực quản lý sẽ phù hợp với một terabyte đĩa ảo bổ sung trên bộ lưu trữ nửa terabyte (ít nhất là cho đến khi họ nghe về việc cung cấp mỏng và sao chép).

Một điều nữa: Khi tạo các kho dữ liệu đó chuẩn hóa trên một kích thước khối duy nhất. Nó đơn giản hóa rất nhiều thứ sau này, khi bạn muốn làm một cái gì đó trên kho dữ liệu và thấy các lỗi "không tương thích" xấu xí.

Cập nhật : DS3k sẽ có các bộ điều khiển hoạt động / thụ động (nghĩa là mọi LUN đã cho đều có thể được phục vụ bởi bộ điều khiển A hoặc B, truy cập LUN thông qua bộ điều khiển không sở hữu phải chịu hình phạt hiệu suất), do đó, nó sẽ trả hết để có số lượng LUN chẵn , phân bố đồng đều giữa các bộ điều khiển.

Tôi có thể tưởng tượng bắt đầu với 15 VM / LUN với không gian để tăng lên 20 hoặc hơn.

Câu trả lời ngắn cho câu hỏi của bạn là: tất cả phụ thuộc vào mẫu IO của bạn là gì và điều này sẽ là duy nhất cho môi trường của bạn.

Tôi đề nghị bạn nên xem tại đây http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/ vì điều này có thể giúp bạn xem xét IOPS dự đoán của bạn và có bao nhiêu LUNS phù hợp. Điều đó nói rằng, nếu bạn nhầm lẫn về mặt thận trọng, một số người sẽ khuyên bạn nên có nhiều LUNS (Nếu sự điều chỉnh của tôi đối với câu trả lời trước được chấp thuận, hãy xem nhận xét của tôi về hàng đợi LUN IO ở phía mảng). Tôi có xu hướng đồng ý, nhưng sẽ đi xa hơn để chia chúng thành một / vài tập VMFS (không tin FUD về phạm vi và các giới hạn VMFS khác http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-c gặp-fud.html). Điều này sẽ có lợi ích trong việc quản lý một / một vài kho dữ liệu trong vSphere và, vì vSphere tự động cân bằng VM trên các phạm vi có sẵn bắt đầu từ khối đầu tiên của mỗi phạm vi, lợi ích hiệu suất lan truyền IO của bạn qua nhiều LUN.

Một cái gì đó khác để xem xét ... Bạn nói rằng không có máy ảo nào đặc biệt IO. Vì điều này, bạn có thể muốn xem xét sự kết hợp của RAID5 và RAID10, để tận dụng tốt nhất cả hai thế giới (không gian và tốc độ).

Hơn nữa, nếu bạn có các VM được cấu hình với nhiều VMDK, với các mẫu IO của hệ điều hành và ứng dụng trải đều trên các đĩa ảo đó (ví dụ: OS, web, DB, log, v.v. trên mỗi VMDK riêng biệt), thì bạn có thể định vị từng VMDK trên một kho dữ liệu khác để phù hợp với khả năng IO của LUN vật lý đó (ví dụ: HĐH trên RAID5, Đăng nhập trên RAID10). Tất cả là về việc giữ các mẫu IO tương tự với nhau để tận dụng hành vi cơ học của các đĩa bên dưới, ví dụ, ghi nhật ký trong một VM không ảnh hưởng đến tốc độ đọc web của bạn trong một VM khác.

FYI ... bạn có thể ảo hóa thành công các máy chủ DB, bạn chỉ cần phân tích các mẫu IO & tỷ lệ IOPS và nhắm mục tiêu IO đến LUN phù hợp; tất cả trong khi nhận thức được các mẫu IO và IOPS mà LUN đang thực hiện. Đây là lý do tại sao nhiều quản trị viên đổ lỗi cho ảo hóa vì hiệu suất DB kém ... vì họ đã không tính toán cẩn thận IO / IOPS mà nhiều máy chủ sẽ tạo khi họ đưa chúng vào LUN được chia sẻ (nghĩa là lỗi của quản trị viên, không phải lỗi của ảo hóa ).

Mỗi tập (LUN) có độ sâu hàng đợi riêng, vì vậy để tránh sự tranh chấp IO, rất nhiều triển khai sử dụng các LUN nhỏ hơn. Điều đó nói rằng, bạn có thể thực hiện một LUNs kho dữ liệu khá dễ dàng. Nhược điểm của kho dữ liệu VMWare lớn hơn (và ít hơn) là, theo như tôi biết, bạn có thể gặp phải một số giới hạn về số lượng VM có thể được bật đồng thời.

Một xem xét khác là hiệu suất điều khiển. Tôi không biết cụ thể về SAN của bạn, nhưng hầu hết nếu không phải tất cả các SAN đều yêu cầu LUN được sở hữu bởi một bộ điều khiển tại một thời điểm. Bạn muốn có đủ LUN trên hệ thống để có thể cân bằng khối lượng công việc giữa các bộ điều khiển.

Ví dụ: nếu bạn chỉ có một LUN, bạn chỉ được sử dụng một bộ điều khiển hoạt động tại một thời điểm. Người kia sẽ ngồi không vì nó sẽ không có gì để làm.

Nếu bạn có hai LUN, nhưng một cái bận hơn nhiều so với cái kia, bạn sẽ sử dụng cả hai bộ điều khiển nhưng không bằng nhau. Khi bạn thêm nhiều LUN, bộ điều khiển chia sẻ khối lượng công việc đồng đều hơn.

Lời khuyên cụ thể cho bạn:

Máy ảo của bạn tương đối giống nhau về các yêu cầu về hiệu suất. Tôi sẽ tạo hai LUN, một cho mỗi bộ điều khiển. Bắt đầu đặt VM trên LUN đầu tiên và đo độ trễ I / O của bạn và độ sâu hàng đợi theo thời gian khi các VM ổn định. Đừng sử dụng LUN thứ hai. Tiếp tục điền LUN 1. Bạn sẽ đạt đến điểm bắt đầu thấy các chỉ số hiệu suất mà LUN đã đầy hoặc bạn sẽ di chuyển một nửa số VM của mình sang LUN đó và vẫn duy trì hiệu suất.

Nếu bạn thấy các vấn đề về hiệu năng, tôi sẽ xóa 30% máy ảo khỏi LUN 1 và chuyển chúng sang LUN 2. Sau đó bắt đầu điền LUN 2 theo cách tương tự. Chuyển đến LUN 3 nếu cần thiết ... điều đó có hợp lý không? Ý tưởng là để đạt được mật độ VM tối đa trên một LUN nhất định cùng với khoảng 30% chi phí cho phòng fudge.

Tôi cũng sẽ tạo một cặp LUN "hiệu suất cao" cho bất kỳ máy ảo nào bị ảnh hưởng nặng. Một lần nữa, một cho mỗi bộ điều khiển để chia sẻ khối lượng công việc.

Dựa trên những giải thích của bạn ở trên, bạn sẽ ổn với 1 kho dữ liệu. 60 vm trên 3 máy chủ không tệ lắm (20: 1). Tuy nhiên, tôi sẽ khuyên bạn nên nâng cấp HBA lên 8Gb nếu có thể có tài chính trên ít nhất một máy chủ với điều kiện công tắc sợi của bạn là công tắc 8Gb ở mức tối thiểu.

Điều đó đang được nói, tôi sẽ tạo ra ít nhất 2 nếu không phải là 3 kho dữ liệu trên mảng. 1 kho dữ liệu trên mỗi máy chủ, với tất cả các máy chủ truy cập vào các máy chủ khác cho vMotion. Tôi không biết nhiều về mảng IBM; với EMC tôi sẽ tạo một nhóm RAID10 với 3 LUN cho mỗi kho dữ liệu. Với thiết lập này, máy chủ lưu trữ với HBA 8Gb sẽ rất phù hợp cho các hệ thống I / O cao hơn của bạn.

Bạn có thể thực hiện 1 kho dữ liệu / máy chủ và có một số trường hợp tôi tự làm điều đó, nhưng tôi chỉ làm điều đó với bản sao SAN trên các máy chủ đặc biệt. Việc quản lý 87 kho dữ liệu khác nhau trên 9 máy chủ cho vMotion trở nên khó hiểu khi bạn thiết lập nó! Phần lớn các vm của tôi nằm trong kho dữ liệu dùng chung với 5-10 máy chủ trên đó tùy thuộc vào dung lượng họ cần.

Một lưu ý cuối cùng. Nếu bạn có bất kỳ loại máy chủ nào trong cặp / cụm chuyển đổi dự phòng hoặc tải cân bằng, bạn sẽ muốn chúng ở các kho dữ liệu khác nhau. Bạn không muốn kho dữ liệu bị lỗi, và sau đó không còn máy chủ. Phải thừa nhận rằng, nếu bạn mất mảng, bạn đã mất tất cả, nhưng đây là lý do tại sao chúng tôi sao lưu, phải không?