Nguy hiểm và cảnh báo LVM

Gần đây tôi đã bắt đầu sử dụng LVM trên một số máy chủ cho các ổ đĩa cứng lớn hơn 1 TB. Chúng hữu ích, có thể mở rộng và khá dễ cài đặt. Tuy nhiên, tôi không thể tìm thấy bất kỳ dữ liệu nào về sự nguy hiểm và cảnh giác của LVM.

Nhược điểm của việc sử dụng LVM là gì?

Tóm lược

Rủi ro khi sử dụng LVM:

• Dễ bị tổn thương khi ghi các vấn đề về bộ nhớ đệm với SSD hoặc trình ảo hóa VM
• Khó phục hồi dữ liệu hơn do cấu trúc trên đĩa phức tạp hơn
• Khó thay đổi kích thước hệ thống tập tin một cách chính xác
• Ảnh chụp khó sử dụng, chậm và lỗi
• Yêu cầu một số kỹ năng để cấu hình chính xác các vấn đề này

Hai vấn đề LVM đầu tiên kết hợp: nếu bộ nhớ đệm ghi không hoạt động chính xác và bạn bị mất điện (ví dụ: PSU hoặc UPS không thành công), bạn có thể phải khôi phục từ bản sao lưu, nghĩa là thời gian chết đáng kể. Một lý do chính để sử dụng LVM là thời gian hoạt động cao hơn (khi thêm đĩa, thay đổi kích thước hệ thống tập tin, v.v.), nhưng điều quan trọng là phải thiết lập bộ đệm ghi đúng để tránh LVM thực sự giảm thời gian hoạt động.

- Cập nhật tháng 12 năm 2018: tài liệu ảnh chụp nhanh được cập nhật, bao gồm tính ổn định của ZFS và btrfs dưới dạng thay thế cho ảnh chụp nhanh LVM

Giảm thiểu rủi ro

LVM vẫn có thể hoạt động tốt nếu bạn:

• Nhận thiết lập bộ đệm ghi của bạn ngay trong hypanneror, kernel và SSD
• Tránh ảnh chụp nhanh LVM
• Sử dụng các phiên bản LVM gần đây để thay đổi kích thước hệ thống tập tin
• Có bản sao lưu tốt

Chi tiết

Tôi đã nghiên cứu điều này khá nhiều trong quá khứ đã trải qua một số mất dữ liệu liên quan đến LVM. Các rủi ro và vấn đề chính của LVM mà tôi biết là:

Dễ bị tổn thương khi ghi đĩa cứng do bộ ảo hóa VM, bộ nhớ đệm đĩa hoặc nhân Linux cũ và khiến việc khôi phục dữ liệu khó khăn hơn do cấu trúc trên đĩa phức tạp hơn - xem chi tiết bên dưới. Tôi đã thấy các thiết lập LVM hoàn chỉnh trên một số đĩa bị hỏng mà không có bất kỳ cơ hội phục hồi nào và LVM cộng với bộ nhớ đệm ghi đĩa cứng là một sự kết hợp nguy hiểm.

• Ghi bộ nhớ đệm và ghi thứ tự lại bằng ổ cứng rất quan trọng để có hiệu năng tốt, nhưng có thể thất bại trong việc xóa các khối vào đĩa một cách chính xác do các trình ảo hóa VM, bộ nhớ đệm ghi ổ cứng, các nhân Linux cũ, v.v.
  • Rào chắn ghi có nghĩa là hạt nhân đảm bảo rằng nó sẽ hoàn thành việc ghi đĩa nhất định trước khi ghi đĩa "rào cản", để đảm bảo rằng các hệ thống tập tin và RAID có thể phục hồi trong trường hợp mất điện đột ngột hoặc gặp sự cố. Các rào cản như vậy có thể sử dụng thao tác FUA (Force Unit Access) để ghi ngay lập tức các khối nhất định vào đĩa, hiệu quả hơn so với xóa toàn bộ bộ đệm. Các rào cản có thể được kết hợp với hàng đợi lệnh được gắn thẻ / lệnh gốc hiệu quả (phát hành nhiều yêu cầu I / O đĩa cùng một lúc) để cho phép ổ cứng thực hiện sắp xếp lại ghi thông minh mà không làm tăng nguy cơ mất dữ liệu.
• Các trình ảo hóa VM có thể có các vấn đề tương tự: chạy LVM trong máy khách Linux trên đầu trình ảo hóa VM như VMware, Xen , KVM, Hyper-V hoặc VirtualBox có thể tạo ra các vấn đề tương tự với kernel mà không cần ghi rào cản, do ghi bộ đệm và ghi lại - sắp xếp Kiểm tra tài liệu hypanneror của bạn một cách cẩn thận để biết tùy chọn "tuôn ra đĩa" hoặc ghi vào bộ đệm (có trong KVM , VMware , Xen , VirtualBox và các tùy chọn khác) - và kiểm tra nó với thiết lập của bạn. Một số trình ảo hóa như VirtualBox có cài đặt mặc định bỏ qua mọi lần xóa đĩa từ khách.
• Các máy chủ doanh nghiệp có LVM phải luôn luôn sử dụng bộ điều khiển RAID được hỗ trợ bằng pin và vô hiệu hóa bộ đệm ghi đĩa cứng (bộ điều khiển có bộ đệm ghi được sao lưu bằng pin nhanh và an toàn) - xem nhận xét này của tác giả của mục Câu hỏi thường gặp về XFS này . Cũng có thể an toàn để tắt các rào cản ghi trong kernel, nhưng nên thử nghiệm.
• Nếu bạn không có bộ điều khiển RAID hỗ trợ pin, việc vô hiệu hóa bộ nhớ đệm ghi vào ổ cứng sẽ ghi chậm đáng kể nhưng giúp LVM an toàn. Bạn cũng nên sử dụng data=orderedtùy chọn tương đương của ext3 (hoặc data=journalđể đảm bảo an toàn hơn), cộng với barrier=1để đảm bảo rằng bộ đệm kernel không ảnh hưởng đến tính toàn vẹn. (Hoặc sử dụng ext4 cho phép các rào cản theo mặc định .) Đây là tùy chọn đơn giản nhất và cung cấp tính toàn vẹn dữ liệu tốt với chi phí hiệu suất. (Linux đã thay đổi tùy chọn ext3 mặc địnhdata=writeback trở lại nguy hiểm hơn một thời gian trước, vì vậy đừng dựa vào các cài đặt mặc định cho FS.)
• Để vô hiệu hóa bộ nhớ đệm ghi ổ cứng : thêm hdparm -q -W0 /dev/sdXcho tất cả các ổ đĩa trong /etc/rc.local(cho SATA) hoặc sử dụng sdparm cho SCSI / SAS. Tuy nhiên, theo mục này trong Câu hỏi thường gặp về XFS (rất tốt về chủ đề này), ổ đĩa SATA có thể quên cài đặt này sau khi khôi phục lỗi ổ đĩa - vì vậy bạn nên sử dụng SCSI / SAS hoặc nếu bạn phải sử dụng SATA thì hãy đặt Lệnh hdparm trong một công việc định kỳ chạy mỗi phút hoặc lâu hơn.
• Để giữ cho SSD / ổ cứng ghi bộ nhớ đệm được kích hoạt để có hiệu suất tốt hơn: đây là một khu vực phức tạp - xem phần bên dưới.
• Nếu bạn đang sử dụng ổ đĩa Định dạng Nâng cao, tức là các lĩnh vực vật lý 4 KB, hãy xem bên dưới - việc vô hiệu hóa bộ đệm ghi có thể có các vấn đề khác.
• UPS rất quan trọng đối với cả doanh nghiệp và SOHO nhưng không đủ để làm cho LVM an toàn: mọi thứ gây ra sự cố cứng hoặc mất điện (ví dụ như lỗi UPS, lỗi PSU hoặc cạn kiệt pin máy tính xách tay) có thể mất dữ liệu trong bộ nhớ cache ổ cứng.
• Các hạt nhân Linux rất cũ (2.6.x từ 2009) : Có hỗ trợ rào cản ghi không hoàn chỉnh trong các phiên bản kernel rất cũ, 2.6.32 trở về trước ( 2.6.31 có một số hỗ trợ , trong khi 2.6.33 hoạt động cho tất cả các loại mục tiêu của thiết bị) - RHEL 6 sử dụng 2.6.32 với nhiều bản vá. Nếu các hạt nhân 2.6 cũ này không được khắc phục cho các vấn đề này, một lượng lớn siêu dữ liệu FS (bao gồm cả tạp chí) có thể bị mất do sự cố cứng khiến dữ liệu trong bộ đệm ghi của ổ cứng (giả sử là 32 MB cho mỗi ổ đĩa cho các ổ đĩa SATA thông thường). Mất 32 MB dữ liệu nhật ký và dữ liệu nhật ký FS gần đây nhất, mà hạt nhân cho rằng đã có trên đĩa, thường có nghĩa là rất nhiều tham nhũng của FS và do đó mất dữ liệu.
• Tóm tắt: bạn phải cẩn thận trong hệ thống tập tin, RAID, bộ ảo hóa VM và thiết lập ổ cứng / SSD được sử dụng với LVM. Bạn phải có các bản sao lưu rất tốt nếu bạn đang sử dụng LVM và chắc chắn sao lưu cụ thể siêu dữ liệu LVM, thiết lập phân vùng vật lý, MBR và các phần khởi động âm lượng. Bạn cũng nên sử dụng các ổ đĩa SCSI / SAS vì chúng ít có khả năng nói dối về cách chúng ghi bộ nhớ đệm - cần phải cẩn thận hơn khi sử dụng ổ đĩa SATA.

Tiếp tục ghi bộ nhớ đệm cho hiệu suất (và đối phó với các ổ nằm)

Một tùy chọn phức tạp hơn nhưng hiệu quả hơn là giữ cho bộ nhớ đệm ghi SSD / ổ cứng được bật và dựa vào các rào cản ghi kernel làm việc với LVM trên kernel 2.6.33+ (kiểm tra kỹ bằng cách tìm kiếm các thông báo "rào cản" trong nhật ký).

Bạn cũng nên đảm bảo rằng thiết lập RAID, VM hypanneror và hệ thống tập tin sử dụng các rào cản ghi (nghĩa là yêu cầu ổ đĩa để xóa ghi đang chờ xử lý trước và sau khi ghi siêu dữ liệu / nhật ký khóa). XFS mặc định sử dụng các rào cản, nhưng ext3 thì không , vì vậy với ext3 bạn nên sử dụng barrier=1trong các tùy chọn gắn kết và vẫn sử dụng data=orderedhoặc data=journalnhư trên.

• Thật không may, một số ổ đĩa cứng và SSD nói dối về việc chúng có thực sự xóa bộ nhớ cache của chúng vào ổ đĩa hay không (đặc biệt là các ổ đĩa cũ, nhưng bao gồm một số ổ đĩa SATA và một số ổ SSD doanh nghiệp ) - chi tiết tại đây . Có một bản tóm tắt tuyệt vời từ một nhà phát triển XFS .
• Có một công cụ kiểm tra đơn giản cho các ổ đĩa nằm (tập lệnh Perl) hoặc xem nền này với một công cụ kiểm tra khác để ghi lại thứ tự do kết quả của bộ đệm ổ đĩa. Câu trả lời này bao gồm việc kiểm tra các ổ đĩa SATA tương tự phát hiện ra vấn đề về rào cản ghi trong phần mềm RAID - những thử nghiệm này thực sự thực hiện toàn bộ ngăn xếp lưu trữ.
• Các ổ đĩa SATA gần đây hỗ trợ Hàng đợi lệnh gốc (NCQ) có thể ít nói dối hơn - hoặc có lẽ chúng hoạt động tốt mà không cần ghi bộ đệm do NCQ và rất ít ổ đĩa không thể vô hiệu hóa ghi bộ đệm.
• Các ổ đĩa SCSI / SAS thường ổn vì chúng không cần ghi bộ đệm để hoạt động tốt (thông qua Hàng đợi lệnh được gắn thẻ SCSI , tương tự như NCQ của SATA).
• Nếu ổ cứng hoặc SSD của bạn nói dối về việc xóa bộ nhớ cache của chúng vào đĩa, bạn thực sự không thể dựa vào các rào cản ghi và phải vô hiệu hóa ghi bộ đệm. Đây là một vấn đề đối với tất cả các hệ thống tệp, cơ sở dữ liệu, trình quản lý khối lượng và RAID phần mềm , không chỉ LVM.

SSD có vấn đề vì việc sử dụng bộ đệm ghi là rất quan trọng đối với tuổi thọ của SSD. Tốt nhất là sử dụng ổ SSD có siêu tụ điện (để cho phép xóa bộ nhớ cache khi mất điện và do đó cho phép bộ đệm được ghi lại không ghi lại).

• Hầu hết các ổ SSD doanh nghiệp đều ổn khi ghi kiểm soát bộ đệm và một số bao gồm các siêu tụ điện.
• Một số ổ SSD rẻ hơn có vấn đề không thể khắc phục với cấu hình ghi bộ đệm - danh sách gửi thư của dự án PostgreQuery và trang wiki đáng tin cậy là nguồn thông tin tốt. SSD tiêu dùng có thể có các vấn đề bộ nhớ đệm ghi lớn sẽ gây mất dữ liệu và không bao gồm các siêu tụ điện nên dễ bị mất điện gây ra tham nhũng.

Thiết lập ổ đĩa định dạng nâng cao - ghi bộ nhớ đệm, căn chỉnh, RAID, GPT

• Với các ổ đĩa Định dạng Nâng cao mới hơn sử dụng 4 cung vật lý KiB, điều quan trọng là phải duy trì kích hoạt ghi bộ đệm ghi ổ đĩa, vì hầu hết các ổ đĩa này hiện đang mô phỏng các vùng logic 512 byte ( "mô phỏng 512" ) và một số thậm chí còn cho rằng có vật lý 512 byte các ngành trong khi thực sự sử dụng 4 KiB.
• Tắt bộ đệm ghi của ổ đĩa Định dạng Nâng cao có thể gây ra tác động hiệu suất rất lớn nếu ứng dụng / nhân đang thực hiện ghi 512 byte, vì các ổ đó dựa vào bộ đệm để tích lũy ghi 8 x 512 byte trước khi thực hiện một vật lý 4 KiB duy nhất viết. Kiểm tra được khuyến nghị để xác nhận bất kỳ tác động nếu bạn vô hiệu hóa bộ đệm.
• Việc căn chỉnh LV trên ranh giới 4 KiB rất quan trọng đối với hiệu suất nhưng sẽ tự động xảy ra miễn là các phân vùng cơ bản cho các PV được căn chỉnh, vì LVM Phys Extents (PE) theo mặc định là 4 MiB. RAID phải được xem xét ở đây - trang cài đặt RAID LVM và phần mềm này đề nghị đặt siêu khối RAID ở cuối âm lượng và (nếu cần) sử dụng tùy chọn pvcreateđể căn chỉnh các PV. Chủ đề danh sách email LVM này chỉ ra công việc được thực hiện trong các hạt nhân trong năm 2011 và vấn đề ghi khối một phần khi trộn các đĩa với các cung 512 byte và 4 KiB trong một LV.
• Phân vùng GPT với Định dạng Nâng cao cần được chăm sóc, đặc biệt đối với các đĩa khởi động + gốc, để đảm bảo phân vùng LVM (PV) đầu tiên bắt đầu trên ranh giới 4 KiB.

Khó phục hồi dữ liệu hơn do cấu trúc trên đĩa phức tạp hơn :

• Bất kỳ sự phục hồi dữ liệu LVM nào được yêu cầu sau khi gặp sự cố cứng hoặc mất điện (do bộ nhớ đệm ghi không chính xác) là một quy trình thủ công tốt nhất, vì rõ ràng không có công cụ phù hợp. LVM rất giỏi trong việc sao lưu siêu dữ liệu của nó /etc/lvm, điều này có thể giúp khôi phục cấu trúc cơ bản của LV, VG và PV, nhưng sẽ không giúp siêu dữ liệu hệ thống tập tin bị mất.
• Do đó, một khôi phục đầy đủ từ sao lưu có khả năng được yêu cầu. Điều này liên quan đến thời gian chết nhiều hơn rất nhiều so với một fsck dựa trên tạp chí nhanh khi không sử dụng LVM và dữ liệu được ghi từ lần sao lưu cuối cùng sẽ bị mất.
• TestDisk , ext3grep , ext3undel và các công cụ khác có thể phục hồi phân vùng và các tập tin từ đĩa phi LVM nhưng họ không trực tiếp hỗ trợ phục hồi dữ liệu LVM. TestDisk có thể phát hiện ra rằng một phân vùng vật lý bị mất có chứa LVM PV, nhưng không có công cụ nào trong số này hiểu được khối lượng logic LVM. Các công cụ khắc tệp như PhotoRec và nhiều công cụ khác sẽ hoạt động khi chúng bỏ qua hệ thống tệp để lắp ráp lại các tệp từ các khối dữ liệu, nhưng đây là phương pháp cuối cùng, cấp thấp cho dữ liệu có giá trị và hoạt động kém hơn với các tệp bị phân mảnh.
• Có thể phục hồi LVM thủ công trong một số trường hợp, nhưng rất phức tạp và tốn thời gian - xem ví dụ này và cái này , cái này và cái này để biết cách phục hồi.

Khó thay đổi kích thước hệ thống tệp một cách chính xác - thay đổi kích thước hệ thống tệp dễ dàng thường được cung cấp vì lợi ích của LVM, nhưng bạn cần chạy nửa tá lệnh shell để thay đổi kích thước FS dựa trên LVM - điều này có thể được thực hiện với toàn bộ máy chủ và trong một số trường hợp với FS được gắn, nhưng tôi sẽ không bao giờ gặp rủi ro sau mà không cập nhật các bản sao lưu và sử dụng các lệnh được thử nghiệm trước trên một máy chủ tương đương (ví dụ: bản sao phục hồi thảm họa của máy chủ sản xuất).

• Cập nhật: Các phiên bản gần đây hơn lvextendhỗ trợ tùy chọn -r( --resizefs) - nếu có sẵn, đây là cách an toàn và nhanh chóng hơn để thay đổi kích thước LV và hệ thống tệp, đặc biệt nếu bạn đang thu hẹp FS và bạn có thể bỏ qua phần này.
• Hầu hết các hướng dẫn để thay đổi kích thước các FS dựa trên LVM không tính đến thực tế là FS phải nhỏ hơn một chút so với kích thước của LV: giải thích chi tiết tại đây . Khi thu nhỏ một hệ thống tệp, bạn sẽ cần chỉ định kích thước mới cho công cụ thay đổi kích thước FS, ví dụ như resize2fscho ext3 và đến lvextendhoặc lvreduce. Nếu không có sự quan tâm lớn, kích thước có thể hơi khác nhau do sự khác biệt giữa 1 GB (10 ^ 9) và 1 GiB (2 ^ 30) hoặc cách các công cụ khác nhau làm tròn kích thước lên hoặc xuống.
• Nếu bạn không thực hiện các phép tính chính xác (hoặc sử dụng một số bước bổ sung ngoài các bước rõ ràng nhất), bạn có thể kết thúc với một FS quá lớn so với LV. Mọi thứ sẽ có vẻ ổn trong nhiều tháng hoặc nhiều năm, cho đến khi bạn hoàn toàn điền vào FS, tại thời điểm đó bạn sẽ bị tham nhũng nghiêm trọng - và trừ khi bạn nhận thức được vấn đề này, thật khó để tìm hiểu tại sao, vì lúc đó bạn cũng có thể có lỗi đĩa thật đám mây đó tình hình. (Có thể sự cố này chỉ ảnh hưởng đến việc giảm kích thước của hệ thống tệp - tuy nhiên, rõ ràng việc thay đổi kích thước hệ thống tệp theo một trong hai hướng sẽ làm tăng nguy cơ mất dữ liệu, có thể do lỗi người dùng.)

• Có vẻ như kích thước LV phải lớn hơn kích thước FS gấp 2 lần kích thước phạm vi vật lý (PE) của LVM - nhưng hãy kiểm tra liên kết ở trên để biết chi tiết vì nguồn này không có thẩm quyền. Thường thì cho phép 8 MiB là đủ, nhưng có thể tốt hơn là cho phép nhiều hơn, ví dụ 100 MiB hoặc 1 GiB, chỉ để an toàn. Để kiểm tra kích thước PE và khối lượng logic + kích thước FS của bạn, sử dụng 4 khối KiB = 4096 byte:

  Hiển thị kích thước PE trong KiB:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Kích thước của tất cả LV:
  lvs --units 4096b
  
  Kích thước của (ext3) FS, giả sử kích thước 4 khối KiB FS:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Ngược lại, thiết lập không phải LVM làm cho việc thay đổi kích thước của FS rất đáng tin cậy và dễ dàng - chạy Gparted và thay đổi kích thước các FS cần thiết, sau đó nó sẽ làm mọi thứ cho bạn. Trên máy chủ, bạn có thể sử dụng partedtừ shell.

  • Cách tốt nhất là sử dụng Gparted Live CD hoặc Parted Magic , vì chúng có Gparted & kernel gần đây và thường không có lỗi hơn phiên bản phân phối - Tôi đã từng mất toàn bộ FS do Gparted của distro không cập nhật phân vùng đúng cách khi chạy nhân. Nếu sử dụng Gparted của distro, hãy đảm bảo khởi động lại ngay sau khi thay đổi phân vùng để chế độ xem của kernel là chính xác.

Ảnh chụp nhanh khó sử dụng, chậm và lỗi - nếu ảnh chụp nhanh hết dung lượng được phân bổ trước, nó sẽ tự động bị hủy . Mỗi ảnh chụp nhanh của một LV nhất định là một delta so với LV đó (không phải so với các ảnh chụp nhanh trước đó) có thể cần nhiều không gian khi chụp nhanh các hệ thống tệp có hoạt động ghi đáng kể (mỗi ảnh chụp lớn hơn so với trước đó). Thật an toàn khi tạo một ảnh chụp nhanh LV có cùng kích thước với LV gốc, vì ảnh chụp nhanh sẽ không bao giờ hết dung lượng trống.

Ảnh chụp nhanh cũng có thể rất chậm (có nghĩa là chậm hơn 3 đến 6 lần so với không có LVM cho các bài kiểm tra MySQL này ) - xem câu trả lời này bao gồm nhiều vấn đề về ảnh chụp nhanh khác nhau . Sự chậm chạp một phần là do ảnh chụp nhanh đòi hỏi nhiều cách ghi đồng bộ .

Ảnh chụp nhanh đã có một số lỗi đáng kể, ví dụ: trong một số trường hợp, chúng có thể khiến việc khởi động rất chậm hoặc khiến boot bị lỗi hoàn toàn (vì kernel có thể hết thời gian chờ đợi root FS khi đó là ảnh chụp nhanh LVM [đã sửa trong bản initramfs-toolscập nhật Debian , Mar 2015] ).

• Tuy nhiên, nhiều lỗi tình trạng cuộc đua chụp nhanh đã được sửa chữa vào năm 2015.
• LVM không có ảnh chụp nhanh thường có vẻ được gỡ lỗi khá tốt, có lẽ vì ảnh chụp nhanh không được sử dụng nhiều như các tính năng cốt lõi.

Ảnh chụp thay thế - hệ thống tập tin và trình ảo hóa VM

Ảnh chụp nhanh VM / đám mây:

• Nếu bạn đang sử dụng trình ảo hóa VM hoặc nhà cung cấp đám mây IaaS (ví dụ: VMware, VirtualBox hoặc Amazon EC2 / EBS), ảnh chụp nhanh của họ thường là sự thay thế tốt hơn nhiều cho ảnh chụp nhanh LVM. Bạn hoàn toàn có thể dễ dàng chụp ảnh nhanh cho mục đích sao lưu (nhưng hãy xem xét việc đóng băng FS trước khi thực hiện).

Ảnh chụp nhanh hệ thống tập tin:

• Ảnh chụp nhanh cấp hệ thống tệp với ZFS hoặc btrfs rất dễ sử dụng và thường tốt hơn LVM, nếu bạn sử dụng kim loại trần (nhưng ZFS có vẻ chín chắn hơn rất nhiều, chỉ cần cài đặt rắc rối hơn):

  • ZFS: hiện đã có triển khai ZFS kernel , đã được sử dụng trong một số năm
  • btrfs : vẫn chưa sẵn sàng để sử dụng sản xuất ( ngay cả trên openSUSE , mặc định vận chuyển nó và có đội ngũ dành riêng cho btrfs), trong khi RHEL đã ngừng hỗ trợ nó), và các công cụ sửa chữa và fsck của nó vẫn đang được phát triển.

Ảnh chụp nhanh để sao lưu trực tuyến và fsck

Ảnh chụp nhanh có thể được sử dụng để cung cấp một nguồn nhất quán cho các bản sao lưu, miễn là bạn cẩn thận với không gian được phân bổ (lý tưởng là ảnh chụp có cùng kích thước với LV được sao lưu). Rsnapshot tuyệt vời (kể từ 1.3.1) thậm chí còn quản lý việc tạo / xóa ảnh chụp nhanh LVM cho bạn - hãy xem HOWTO này trên rsnapshot bằng LVM . Tuy nhiên, lưu ý các vấn đề chung với ảnh chụp nhanh và bản thân ảnh chụp không nên được coi là bản sao lưu.

Bạn cũng có thể sử dụng ảnh chụp nhanh LVM để thực hiện fsck trực tuyến: chụp nhanh LV và fsck ảnh chụp nhanh, trong khi vẫn sử dụng FS không chụp nhanh chính - được mô tả ở đây - tuy nhiên, không hoàn toàn đơn giản vì vậy tốt nhất nên sử dụng e2croncheck như được mô tả bởi Ted Ts 'o , duy trì ext3.

Bạn nên "đóng băng" hệ thống tệp tạm thời trong khi chụp ảnh nhanh - một số hệ thống tệp như ext3 và XFS sẽ tự động thực hiện việc này khi LVM tạo ảnh chụp nhanh.

Kết luận

Mặc dù tất cả điều này, tôi vẫn sử dụng LVM trên một số hệ thống, nhưng đối với thiết lập máy tính để bàn, tôi thích các phân vùng thô. Lợi ích chính mà tôi có thể thấy từ LVM là tính linh hoạt của việc di chuyển và thay đổi kích thước các FS khi bạn phải có thời gian hoạt động cao trên máy chủ - nếu bạn không cần điều đó, gparted sẽ dễ dàng hơn và ít rủi ro mất dữ liệu hơn.

LVM yêu cầu rất cẩn thận về thiết lập bộ đệm ghi do bộ ảo hóa VM, bộ nhớ đệm ghi ổ cứng / SSD, v.v. - nhưng áp dụng tương tự cho việc sử dụng Linux làm máy chủ DB. Việc thiếu sự hỗ trợ từ hầu hết các công cụ ( gpartedbao gồm các tính toán kích thước tới hạn, testdiskv.v.) khiến nó khó sử dụng hơn mức cần thiết.

Nếu sử dụng LVM, hãy hết sức cẩn thận với ảnh chụp nhanh: sử dụng ảnh chụp nhanh VM / đám mây nếu có thể hoặc điều tra ZFS / btrfs để tránh LVM hoàn toàn - bạn có thể thấy ZFS hoặc btrs đủ trưởng thành so với LVM với ảnh chụp nhanh.

Điểm mấu chốt: Nếu bạn không biết về các vấn đề được liệt kê ở trên và cách giải quyết chúng, tốt nhất không nên sử dụng LVM.

Tôi [+1] bài đăng đó, và ít nhất là đối với tôi, tôi nghĩ rằng hầu hết các vấn đề đều tồn tại. Nhìn thấy chúng trong khi chạy một vài máy chủ 100 và một vài 100TB dữ liệu. Đối với tôi LVM2 trong Linux có cảm giác như một "ý tưởng thông minh" mà ai đó đã có. Giống như một số trong số này, đôi khi chúng trở nên "không thông minh". Tức là không có các trạng thái kernel và không gian người dùng (lvmtab) tách biệt có thể cảm thấy thực sự thông minh để giải quyết, bởi vì có thể có các vấn đề tham nhũng (nếu bạn không hiểu đúng về mã)

Chà, chỉ vì sự tách biệt này là có lý do - sự khác biệt thể hiện với việc xử lý mất PV và kích hoạt lại trực tuyến một VG với các PV bị thiếu để đưa chúng trở lại hoạt động - Thật là một làn gió trên "LVMs gốc" (AIX , HP-UX) biến thành crap trên LVM2 do việc xử lý trạng thái không đủ tốt. Và thậm chí đừng để tôi nói về phát hiện mất đại biểu (haha) hoặc xử lý trạng thái (nếu tôi xóa đĩa, điều đó sẽ không được gắn cờ là không khả dụng. Nó thậm chí không có cột trạng thái chết tiệt)

Re: pvmove ổn định ... tại sao là

mất dữ liệu pvmove

một bài viết xếp hạng hàng đầu như vậy trên blog của tôi, hmmm? Ngay bây giờ tôi nhìn vào một đĩa mà dữ liệu lvm phy vẫn còn được treo trên trạng thái từ giữa pvmove. Tôi đã có một số memleaks tôi nghĩ, và ý tưởng chung đó là một điều tốt để sao chép xung quanh dữ liệu khối trực tiếp từ không gian người dùng chỉ là buồn. Câu nói hay từ danh sách lvm "có vẻ như vgreduce --missing không xử lý pvmove" Có nghĩa là trên thực tế nếu một đĩa tách ra trong pvmove thì công cụ quản lý lvm thay đổi từ lvm sang vi. Oh và cũng đã có một lỗi trong đó pvmove tiếp tục sau một lỗi đọc / ghi khối và trên thực tế không còn ghi dữ liệu vào thiết bị đích. WTF?

Re: Snapshots CoW được thực hiện một cách không an toàn, bằng cách cập nhật dữ liệu MỚI vào khu vực lv snapshot và sau đó hợp nhất trở lại sau khi bạn xóa snap. Điều này có nghĩa là bạn có các đột biến IO nặng trong quá trình hợp nhất dữ liệu mới vào LV gốc và quan trọng hơn, tất nhiên, bạn cũng có nguy cơ tham nhũng dữ liệu cao hơn nhiều, vì không ảnh chụp nhanh sẽ bị phá vỡ khi bạn nhấn tường, nhưng bản gốc.

Ưu điểm là về hiệu năng, thực hiện 1 lần viết thay vì 3. Chọn thuật toán nhanh nhưng không gây khó chịu là điều mà rõ ràng người ta mong đợi từ những người như VMware và MS, trên "Unix" Tôi muốn đoán mọi thứ sẽ được "thực hiện đúng". Tôi không thấy nhiều vấn đề về hiệu năng miễn là tôi có kho lưu trữ sao lưu trên một ổ đĩa khác với dữ liệu chính (và tất nhiên là sao lưu vào một cái khác)

Re: Rào cản Tôi không chắc người ta có thể đổ lỗi cho LVM không. Đó là một vấn đề sai lệch, theo như tôi biết. Nhưng có thể có một số lỗi cho việc không thực sự quan tâm đến vấn đề này từ ít nhất là kernel 2.6 cho đến 2.6.33 AFAIK Xen là trình ảo hóa duy nhất sử dụng O_DIRECT cho các máy ảo, vấn đề được sử dụng là khi "loop" được sử dụng vì kernel vẫn sẽ lưu trữ bằng cách sử dụng đó. Virtualbox ít nhất có một số cài đặt để vô hiệu hóa những thứ như thế này và Qemu / KVM thường dường như cho phép lưu vào bộ đệm. Tất cả FUSE FS cũng gặp sự cố ở đó (không có O_DIRECT)

Re: Kích thước Tôi nghĩ LVM "làm tròn" kích thước được hiển thị. Hoặc nó sử dụng GiB. Dù sao, bạn cần sử dụng kích thước VG Pe và nhân nó với số LE của LV. Điều đó sẽ cho kích thước mạng chính xác, và vấn đề đó luôn luôn là vấn đề sử dụng. Nó trở nên tồi tệ hơn bởi các hệ thống tập tin không nhận thấy điều đó trong fsck / mount (xin chào, ext3) hoặc không có "fsck -n" trực tuyến hoạt động (xin chào, ext3)

Tất nhiên, nó nói rằng bạn không thể tìm thấy nguồn tốt cho thông tin đó. "có bao nhiêu LE cho VRA?" "phần bù phy tài chính cho PVRA, VGDA, ... vv là gì"

So với bản gốc LVM2 là ví dụ điển hình của "Những người không hiểu UNIX bị kết án để phát minh lại nó, thật tệ."

Cập nhật một vài tháng sau: Tôi đã đạt được kịch bản "ảnh chụp nhanh" cho một thử nghiệm cho đến bây giờ. Nếu chúng đầy đủ, các khối ảnh chụp nhanh, không phải LV gốc. Tôi đã sai ở đó khi lần đầu tiên tôi đăng bài này. Tôi đã chọn thông tin sai từ một số tài liệu, hoặc có thể tôi đã hiểu nó. Trong các thiết lập của tôi, tôi luôn rất hoang tưởng khi không để chúng lấp đầy và vì vậy tôi không bao giờ kết thúc việc sửa chữa. Cũng có thể mở rộng / thu nhỏ ảnh chụp nhanh, đây là một điều trị.

Điều tôi vẫn chưa thể giải quyết là làm thế nào để xác định tuổi của ảnh chụp. Về hiệu suất của chúng, có một ghi chú trên trang dự án fedora "mỏng" cho biết kỹ thuật chụp nhanh đang được sửa đổi để chúng sẽ không bị chậm hơn với mỗi ảnh chụp. Tôi không biết họ đang thực hiện nó như thế nào.

nếu bạn có kế hoạch sử dụng ảnh chụp nhanh để sao lưu - hãy chuẩn bị cho cú đánh hiệu suất lớn khi có ảnh chụp nhanh. đọc thêm ở đây . nếu không thì tất cả đều tốt. Tôi đã sử dụng lvm trong sản xuất trong vài năm trên hàng chục máy chủ, mặc dù lý do chính của tôi để sử dụng nó là ảnh chụp nguyên tử không có khả năng mở rộng âm lượng dễ dàng.

btw nếu bạn sẽ sử dụng ổ 1TB, hãy nhớ về căn chỉnh phân vùng - ổ đĩa này rất có thể có các thành phần vật lý 4kB.

Ađam

Một ưu điểm khác: bạn có thể thêm một khối vật lý mới (PV), di chuyển tất cả dữ liệu sang PV đó và sau đó xóa PV cũ mà không có bất kỳ gián đoạn dịch vụ nào. Tôi đã sử dụng khả năng đó ít nhất bốn lần trong năm năm qua.

Một nhược điểm tôi chưa thấy rõ đã chỉ ra rõ ràng: Có một đường cong học tập hơi dốc cho LVM2. Chủ yếu là sự trừu tượng mà nó tạo ra giữa các tệp của bạn và phương tiện truyền thông cơ bản. Nếu bạn làm việc với chỉ một vài người chia sẻ công việc trên một bộ máy chủ, bạn có thể thấy sự phức tạp thêm áp đảo cho toàn bộ nhóm của bạn. Các nhóm lớn hơn dành riêng cho công việc CNTT thường sẽ không gặp vấn đề như vậy.

Ví dụ, chúng tôi sử dụng nó rộng rãi ở đây trong công việc của tôi và đã dành thời gian để dạy cho cả nhóm những điều cơ bản, ngôn ngữ và các yếu tố cần thiết về việc khôi phục các hệ thống không khởi động chính xác.

Một lưu ý đặc biệt cần chỉ ra: nếu bạn khởi động từ khối lượng logic LVM2, bạn đã gặp khó khăn trong việc phục hồi khi máy chủ gặp sự cố. Knoppix và bạn bè không phải lúc nào cũng có những thứ phù hợp cho việc đó. Vì vậy, chúng tôi đã quyết định rằng thư mục / boot của chúng tôi sẽ nằm trên phân vùng riêng của nó và sẽ luôn nhỏ và tự nhiên.

Nhìn chung, tôi là một fan hâm mộ của LVM2.