Thực tiễn tốt nhất để ảo hóa máy chủ lên SAN?

Được rồi, vì vậy tôi muốn bắt đầu tận dụng SAN của mình nhiều hơn một chút so với trước đây, đồng thời, tận dụng ESXi.

Hiện tại, tôi đã có một loạt các lưỡi Dell PowerEdge 1955 được kết nối với mảng lưu trữ EMC AX4-5 FC một vỏ. Tôi chủ yếu sử dụng SAN là DAS. Tôi đã có các LUN trên SAN đang chỉ vào các máy vật lý cụ thể và các máy đó sử dụng LUN cho bất cứ điều gì (chủ yếu là cơ sở dữ liệu và cổ phiếu Samba / NFS, tùy thuộc vào máy chủ mục tiêu).

Tôi đã có nhiều máy chủ tệp vật lý và mỗi máy chủ có thiết lập cấu hình samba để phục vụ các chia sẻ phù hợp. Vì tôi không bao giờ có RHCS để làm việc, chỉ một trong số các máy chủ tệp có LUN được gắn tại một thời điểm. Trong trường hợp một máy chủ tệp bị chết, tôi rào nó bằng tay (bằng cách ngắt kết nối và không sử dụng ổ đĩa, sử dụng tiện ích điều hướng, hoặc bằng cách tiêu diệt năng lượng qua DRAC), sau đó sử dụng tiện ích điều hướng để hiển thị LUN được trình bày trên ứng cử viên tiếp theo ( sau đó, bắt đầu apache và các daemon khác). Tất cả bằng tay, ngay bây giờ.

Tôi cảm thấy sắp xếp như Ferris Bueller chơi clarinet. Chưa bao giờ có một bài học!

Dù sao, tôi đang cố gắng cải thiện. Những gì tôi muốn làm là cài đặt ESXi trên các máy chủ vật lý, sau đó tạo LUN để giữ hai hình ảnh máy chủ tệp (trong trường hợp một bị hỏng / fubar), một trong số đó sẽ là hoạt động, cái còn lại sẽ ở chế độ chờ. Ít nhất là theo cách này, tôi không cải thiện việc tự động hóa (mặc dù tôi sẽ bắt đầu viết kịch bản để sớm chuyển đổi máy chủ "hoạt động"), nhưng tôi cảm thấy như mình đang thêm linh hoạt, ngoài ra tôi có thể sử dụng máy chủ ESXi chứa các máy ảo khác và phần cứng sẽ không bị lãng phí, như bây giờ.

Câu hỏi của tôi là:

1) Kế hoạch của tôi ngu ngốc đến mức nào?

2) Khi triển khai thực tế, tôi nên tạo một hình ảnh vmdk bình thường trên LUN, hay tôi nên cung cấp cho nó một phân vùng "thô" (nếu điều đó thậm chí có thể với ESXi?)

3) Có cách nào "tốt" để sử dụng các trình tạo tệp không phân cụm không?

Kế hoạch của bạn không phải là hạt dẻ. Như thường lệ, có nhiều cách để tấn công điều này dựa trên những gì bạn đang cố gắng đạt được và cách bảo vệ dữ liệu của bạn.

Trước tiên, bạn có thể trình bày LUN thô cho VM bằng cách sử dụng "Ánh xạ thiết bị thô". Để làm điều này:

• Trình bày LUN cho máy chủ ESXi (hoặc nhóm máy chủ, nếu bạn định sử dụng phân cụm / HA)
• Thêm đĩa vào VM của bạn, chọn Ánh xạ thiết bị thô, trỏ vào LUN
• Quét lại bus SCSI bên trong VM
• fdisk, gắn kết và thêm vào fstab, giống như một đĩa bình thường.

Ưu điểm: nhanh để thiết lập, sử dụng nhanh, dễ dàng, có thể đại diện cho đĩa vào máy chủ vật lý nếu bạn thấy mình cần V2P xuống theo dõi

Nhược điểm: bạn có thể mất một số tùy chọn snapshot / rollback dựa trên VMware, tùy thuộc vào việc bạn sử dụng chế độ tương thích vật lý hay ảo

Một tùy chọn thay thế là tạo VMFS trên LUN để tạo kho dữ liệu, sau đó thêm đĩa VMDK vào VM sống trên kho dữ liệu đó.

• Ưu điểm: đó là Storage vMotion thân thiện nếu bạn từng mua giấy phép sử dụng. Điều này cho phép di chuyển nóng các đĩa VMDK giữa LUN và thậm chí SAN.

Trong cả hai trường hợp, bạn ở một vị trí rủi ro tương tự nên VMware hoặc VM của bạn ăn hệ thống tập tin trong một lỗi; một cái không tốt hơn cái kia mặc dù những tùy chọn khôi phục nào sẽ có sẵn sẽ khá khác nhau.

Tôi không triển khai RDM trừ khi tôi phải; Tôi thấy rằng họ không mua cho tôi sự linh hoạt như một VMDK (và tôi đã bị cắn bởi các lỗi khiến chúng không thực tế khi thực hiện các hoạt động lưu trữ khác (kể từ khi cố định - xem phần RDM trong liên kết đó))

Đối với VM của bạn, cách tốt nhất để linh hoạt là lưu trữ đĩa khởi động của máy chủ tệp của bạn dưới dạng VMDK trên SAN để bạn có thể có các máy chủ khác khởi động nó trong trường hợp máy chủ bị lỗi. Sử dụng chức năng HA của VMware, việc khởi động máy ảo của bạn trên một máy chủ khác là tự động (VM sẽ khởi động trên máy chủ thứ hai như thể nguồn điện đã được kéo, dự kiến ​​sẽ thực hiện phép thuật và fsck thông thường để đưa nó lên như trong trường hợp máy chủ bình thường ). Lưu ý, HA là một tính năng được cấp phép.

Để giảm thiểu lỗi VM, bạn có thể tạo một bản sao nhẹ của máy chủ tệp của mình, chứa mức tối thiểu cần thiết để khởi động và khởi động SAMBA ở trạng thái được định cấu hình và lưu trữ tệp này trên mỗi đĩa cục bộ của máy chủ, chờ bạn thêm ổ đĩa dữ liệu từ VM thất bại và bật nó lên.

Điều này có thể hoặc không thể mua cho bạn các tùy chọn bổ sung trong trường hợp lỗi SAN; trường hợp tốt nhất, bộ lưu trữ dữ liệu của bạn sẽ yêu cầu sửa chữa fsck hoặc sửa chữa khác, nhưng ít nhất bạn không phải sửa chữa, xây dựng lại hoặc định cấu hình VM trên đầu trang. Trường hợp xấu nhất, bạn đã mất dữ liệu và cần quay lại băng ... nhưng dù sao bạn cũng đã ở trong trạng thái đó.

Tôi sẽ gắn bó với hình ảnh vmdk, chỉ cần bạn chuyển sang sử dụng vmotion trong tương lai, bạn sẽ không bao giờ biết mình có thể có ngân sách cho nó.

Nếu máy của bạn không co cụm, thì theo tôi cách tốt nhất để quản lý chúng là thử và trải đều tải hết mức có thể. Tôi có 3 cụm không 2950 trong đó tải từ các vms quan trọng nhất có thể bằng 1/3 trên mỗi. Lý thuyết là tôi không thể mất nhiều hơn một hộp cùng một lúc, vì vậy ít nhất 2/3 sẽ có thể tiếp tục hoạt động mà không bị ảnh hưởng.

Từ quan điểm sức mạnh, có thể sẽ hiệu quả hơn khi tải các máy lên gần 100% như bạn có thể và tắt các máy khác, nhưng có vẻ như đặt tất cả trứng của bạn vào một giỏ cho tôi.

Tôi sẽ không gọi mình là một chuyên gia về điều này, đó chỉ là những gì tôi làm.

Này Matt. Có rất nhiều cách để cắt một giải pháp khi bạn sử dụng giải pháp ảo hóa. Trước hết, đã có rất nhiều điểm chuẩn cho thấy hiệu năng LUN (RDM) so với hiệu suất VMDK và sự khác biệt thường được hiển thị là không đáng kể. Một số điều cần chú ý với RDM: Chỉ một số tình huống phân cụm nhất định yêu cầu sử dụng RDM (phân cụm MS). RDM có giới hạn 2TB nhưng LVM có thể được sử dụng để làm việc xung quanh giới hạn này. RDM là "khó theo dõi" hơn là cung cấp LUN cho ESXi để sử dụng cho VMFS và đưa vmdk vào đó. VMDK (như đã đề cập) có một số lợi ích tốt đẹp: svMotion, Snapshots (không thể chụp nhanh pRDM).

Nếu chạy ESXi miễn phí, đây là cách tôi có thể giải quyết tình huống của bạn. Trước hết, tất cả dữ liệu là trong các tệp vmdk trên VMFS LUNS. Thiết lập 2 VM và sử dụng Heartbeat để chuyển đổi dự phòng IP và Dịch vụ. Heartbeat sẽ chuyển IP dịch vụ qua và có thể xử lý tập lệnh để ngắt kết nối / gắn dữ liệu LUN khi thích hợp. Bạn thậm chí có thể tạo kịch bản cho một số VMware Remote CLI để đảm bảo VM 'xuống' được tắt để tạo hàng rào. Với nhịp tim trực tiếp phối hợp giữa các hệ thống có nguy cơ cả hai truy cập dữ liệu lun / chạy cùng một dịch vụ nên cực kỳ thấp. Chìa khóa ở đây là đảm bảo việc gắn / ngắt kết nối dữ liệu LUN và khởi động / tắt dịch vụ được xử lý bởi Heartbeat, chứ không phải các cơ chế init thông thường.

Một dự phòng thay thế có thể được thực hiện thông qua hệ thống giám sát. Khi phát hiện máy chủ xuống, nó có thể sử dụng VMware Remote CLI để tắt nguồn (để an toàn) và sau đó bật nguồn của bản sao lưu vm. Trong tình huống này thất bại trở lại là khá thủ công.

Trong môi trường "nhỏ bé" của tôi, tôi chưa thấy VMDK bị hỏng. Điều tôi cũng nhận ra là nếu bạn có nhiều hơn 2 máy chủ ESX (i) hoặc một tá VM, bạn sẽ muốn có vCenter để theo dõi mọi thứ. Một số gói Essential / Plus không quá tốn kém khi xem xét các lợi ích.

Matt, bạn biết tôi không sử dụng VMware nhưng tôi đã luôn sử dụng "RAW" với Xen. Chỉ với một vài máy ảo được tải nhẹ, tôi nghi ngờ bạn sẽ thấy nhiều sự khác biệt về hiệu năng. Nhưng khi bạn bắt đầu tiếp cận ngày càng nhiều khách nếu tất cả những khách đó ở trên cùng một hệ thống tệp, bạn sẽ kết thúc với các vấn đề về độ sâu hàng đợi. Điều này đặc biệt đúng với lưu trữ được hỗ trợ NFS. Nó không quá nhiều đến nỗi máy chủ NFS có vấn đề nhưng hầu hết các triển khai máy khách NFS đều tệ.

Tôi không biết một cách hay để đồng bộ hóa vmdks nếu bạn đang tìm kiếm sự dư thừa (thất bại san). Nhưng nếu bạn sử dụng các thiết bị khối, bạn vẫn có khả năng sử dụng DRBD để sao chép chỉ các vms bạn muốn / cần sao chép.

Tôi nghĩ bạn nên tự hỏi mình "Tôi có bao giờ lên kế hoạch quay lại máy chủ vật lý không"

Nếu câu trả lời là có thể thì có lẽ bạn nên bám vào RDM. ESXi với RDM sẽ (tôi nghĩ) yêu cầu bạn phải mua thứ gì đó để sợi của bạn hoạt động (một lần nữa không chắc chắn 100% trên esxi).

Chúng tôi đã có một số máy mà tôi vừa nhanh chóng chuyển từ máy chủ vật lý sang ESX (4.0) bằng RDM. Tôi đã có sự kết hợp giữa máy Linux và Windows (siêu dễ dàng cho cả hai nền tảng). Chúng tôi vẫn còn một số FreeBSD đang hoạt động (6.0 trở lên) trên các máy chủ vật lý mà chúng tôi không thể sử dụng RDM vì hạt nhân FBSD cũ không hỗ trợ điều này. Thật nhanh chóng và yêu cầu tôi không làm gì khác hơn là chỉ LUN của mình và sau đó cài đặt các công cụ VMWare. Não chết dễ dàng .. không chuyển đổi không phiền phức ...

Một điều khác bạn nên tự hỏi mình là "Tôi muốn sử dụng tính năng nào của VMWare?"

Tùy thuộc vào câu trả lời của bạn mà bạn có thể không có lựa chọn nào khác ngoài VMDK. Nếu bạn sử dụng SAN cho ảnh chụp nhanh và không quan tâm đến việc sử dụng vmware cho điều đó chẳng hạn ..

Một số lưu ý Ill chia sẻ với bạn về những gì chúng tôi đã gặp phải cho đến nay .. Vmotion hoạt động tuyệt vời không kém với RDM và VMDK, mặt khác Storage Vmotion chỉ hoạt động chính xác với không phải RDM và cố gắng sử dụng lưu trữ Vmotion để chuyển từ RDM sang VMDK. chỉ sử dụng trình chuyển đổi .. Hầu hết các bản phân phối Linux đều có gói công cụ vmware mã nguồn mở khiến cho việc cài đặt các công cụ không thành vấn đề. Applince sao lưu hoạt động thực sự tốt và không có vmware, nhưng không làm nhiều thứ như chúng ta muốn. Tôi rất khuyến khích tham gia một lớp học từ vmware. Tôi đã nhận được một tuần và đáng giá từng xu hỗ trợ VMWare là tuyệt vời .. Nếu bạn nhận được hợp đồng hỗ trợ và phải gọi họ là hàng đầu .. Tôi cảm thấy thất vọng khi gặp ai đó có thể giúp tôi (với nhiều menu .. ), nhưng một khi tôi nhận được chúng, họ LUÔN LUÔN đến với sự hỗ trợ đáng tin cậy nhanh chóng.