Linux trên VMware - tại sao sử dụng phân vùng?

Khi cài đặt máy ảo Linux trong môi trường ảo hóa (ESXi trong trường hợp của tôi), có bất kỳ lý do thuyết phục nào để phân vùng đĩa (khi sử dụng ext4) thay vì chỉ thêm các đĩa riêng biệt cho mỗi điểm gắn kết không?

Điều duy nhất tôi có thể thấy là nó giúp dễ dàng hơn để xem liệu có dữ liệu trên đĩa với ví dụ fdisk hay không.

Mặt khác, tôi có thể thấy một số lý do chính đáng cho việc không sử dụng phân vùng (rõ ràng không phải là / boot).

• Dễ dàng hơn nhiều để mở rộng đĩa. Đó chỉ là để tăng kích thước đĩa cho VM (thường là trong VCenter), sau đó quét lại thiết bị trong VM và thay đổi kích thước hệ thống tệp trực tuyến.
• Không còn vấn đề với việc căn chỉnh các phân vùng với các LUN bên dưới.

Tôi đã không tìm thấy nhiều về chủ đề này xung quanh. Tôi đã bỏ lỡ một cái gì đó quan trọng?

Đây là một câu hỏi thú vị...

Tôi không nghĩ rằng có một câu trả lời dứt khoát, nhưng tôi có thể đưa ra một số bối cảnh lịch sử về cách thực hành tốt nhất xung quanh chủ đề này có thể đã thay đổi theo thời gian.

Tôi đã phải hỗ trợ hàng ngàn máy ảo Linux được triển khai ở nhiều dạng khác nhau trên các môi trường VMware kể từ năm 2007. Cách tiếp cận triển khai của tôi đã phát triển và tôi đã có kinh nghiệm ( đôi khi không may ) duy nhất là kế thừa và tái cấu trúc các hệ thống được xây dựng bởi các kỹ sư khác.

Những ngày cũ...

Ngày trước (2007), các hệ thống VMware đầu tiên của tôi được phân vùng giống như các hệ thống kim loại trần của tôi. Về phía VMware, tôi đã sử dụng các tệp dày 2 GB để chia dữ liệu của VM và thậm chí không nghĩ về khái niệm nhiều VMDK, vì tôi rất vui vì ảo hóa thậm chí có thể hoạt động!

Cơ sở hạ tầng ảo ...

Bởi ESX 3.5 và đầu ESX / ESXi 4.x phát hành (2009-2011), tôi đã sử dụng Linux, phân vùng như bình thường trên đỉnh khối Dày được cung cấp file VMDK. Phải lưu trữ lưu trữ buộc tôi phải suy nghĩ về thiết kế Linux theo cách tương tự như tôi làm với phần cứng thực sự. Tôi đã tạo 36 GB, 72 GB, 146 GB VMDK cho hệ điều hành, phân vùng thông thường /, / boot, / usr, / var, / tmp, sau đó thêm một VMDK khác cho phân vùng "dữ liệu" hoặc "tăng trưởng" (cho dù đó là / nhà, / opt hoặc một cái gì đó ứng dụng cụ thể). Một lần nữa, điểm ngọt trong kích thước đĩa cứng vật lý trong thời đại này là 146GB và vì việc đặt trước là một yêu cầu (trừ khi sử dụng NFS), tôi cần phải thận trọng với không gian.

Sự ra đời của cung cấp mỏng

VMware đã phát triển các tính năng tốt hơn xung quanh việc cung cấp Thin trong các bản phát hành ESXi 4.x sau này và điều này đã thay đổi cách tôi bắt đầu cài đặt các hệ thống mới. Với bộ tính năng đầy đủ được thêm vào 5.0 / 5.1, một loại linh hoạt mới cho phép thiết kế sáng tạo hơn. Xin lưu ý bạn, điều này đã bắt kịp với các khả năng gia tăng trên các máy ảo, về số lượng vCPUS và bao nhiêu RAM có thể được cam kết cho từng máy ảo. Nhiều loại máy chủ và ứng dụng có thể được ảo hóa hơn so với trước đây. Điều này đúng khi môi trường điện toán bắt đầu hoàn toàn ảo.

LVM thật kinh khủng ...

Vào thời điểm chức năng bổ sung đầy đủ ở cấp VM đã có và phổ biến (2011-2012), tôi đã làm việc với một công ty cố gắng duy trì thời gian hoạt động cho máy ảo của khách hàng của họ bằng mọi giá ( ngu ngốc ). Vì vậy, điều này bao gồm tăng CPU / RAM trực tuyến của VMware và thay đổi kích thước đĩa LVM rủi ro trên các VMDK hiện có. Hầu hết các hệ thống Linux trong môi trường này là các thiết lập VMDK đơn lẻ với các phân vùng ext3 trên LVM. Điều này thật tồi tệ vì lớp LVM đã tăng thêm độ phức tạp và rủi ro không cần thiết cho hoạt động. Chẳng hạn, hết dung lượng trong / usr, có thể dẫn đến một chuỗi các quyết định tồi tệ cuối cùng có nghĩa là khôi phục hệ thống từ các bản sao lưu ... Đây là một phần của quá trình và liên quan đến văn hóa, nhưng vẫn ...

Phân vùng hợm hĩnh ...

Tôi đã nhân cơ hội này để cố gắng thay đổi điều này. Tôi là một kẻ hợm hĩnh phân vùng trong Linux và cảm thấy rằng các hệ thống tập tin nên được tách ra để theo dõi và vận hành. Tôi cũng không thích LVM, đặc biệt là với VMware và khả năng thực hiện những gì bạn yêu cầu. Vì vậy, tôi đã mở rộng việc bổ sung các tệp VMDK vào các phân vùng có khả năng phát triển. / opt, / var, / home có thể lấy các tệp máy ảo của riêng họ nếu cần. Và đó sẽ là những đĩa thô. Đôi khi, đây là một phương pháp dễ dàng hơn để mở rộng phân vùng dưới mức cụ thể một cách nhanh chóng.

Obamacare ...

Với việc đưa lên máy khách cấu hình rất cao , tôi được giao nhiệm vụ thiết kế mẫu tham chiếu Linux VM sẽ được sử dụng để tạo môi trường ứng dụng cực kỳ rõ ràng của chúng . Các yêu cầu bảo mật của ứng dụng yêu cầu một bộ gắn kết duy nhất , do đó, đã làm việc với các nhà phát triển để cố gắng nhồi nhét các phân vùng không tăng trưởng vào một VMDK, sau đó thêm các VMDK riêng cho mỗi mount có tiềm năng tăng trưởng hoặc có các yêu cầu cụ thể (mã hóa, kiểm toán, v.v.) Vì vậy, cuối cùng, các VM này bao gồm 5 VMDK trở lên, nhưng cung cấp sự linh hoạt tốt nhất để thay đổi kích thước và bảo vệ dữ liệu trong tương lai.

Những gì tôi làm hôm nay ...

Ngày nay, thiết kế chung của tôi cho Linux và các hệ thống tập tin truyền thống là HĐH trên một VMDK mỏng (được phân vùng) và VMDK rời rạc cho mọi thứ khác. Tôi sẽ thêm nóng khi cần thiết. Đối với các hệ thống tệp nâng cao như ZFS, đó là một VMDK cho HĐH và một VMDK khác hoạt động như một zpool ZFS và có thể được thay đổi kích thước, khắc vào các hệ thống tệp ZFS bổ sung, v.v.

Bạn đúng theo nhiều cách, tôi có thể thấy lập luận - mặc dù có một vấn đề có thể chứng minh sự khó khăn. Nếu bạn sử dụng Resource Pools (và tôi biết là tôi không biết, những thứ đáng ghét) thì VM có thể nhận được nhiều thời gian IO hơn nếu chúng có nhiều đĩa hơn - trong các tình huống bị hạn chế tài nguyên cực độ, một VM có hai đĩa có thể nhận được gấp đôi tài nguyên IO so với một một đĩa đơn. Điều này có thể không phải là một vấn đề với bạn nhưng tôi nghĩ tôi đã chỉ ra điều đó.

Chỉnh sửa - oh và nó sẽ làm cho chụp nhanh chậm hơn một chút, nhưng một lần nữa đó có thể không phải là một vấn đề.

Khi tôi làm việc trong cơ sở hạ tầng tại một "công ty phần mềm ảo hóa lớn", chúng tôi thường cần tăng kích thước của hệ thống tập tin của vm. Chúng tôi đã sử dụng ext3 / 4 tại thời điểm đó.

Việc tăng đĩa ảo rất dễ dàng, chọn kích thước thiết bị mới trong HĐH trực tiếp tương đối dễ dàng (chọc vào / sys), thay đổi kích thước hệ thống tập tin ext3 / 4 là dễ dàng, nhưng điều luôn luôn dường như là không thể (để thực hiện) Thay đổi kích thước phân vùng.

Bạn phải sử dụng gparted hoặc viết lại / thay đổi kích thước bảng phân vùng bằng fdisk - nhưng nó luôn bị khóa bởi kernel và yêu cầu khởi động lại để lấy kernel để chọn bố cục mới (partprobe cũng không làm điều đó.)

Tôi đã chuyển nhiều hệ thống sang LVM và thay đổi kích thước hệ thống tập tin trở thành một trải nghiệm dễ dàng, gần như dễ chịu!

• Tăng hình ảnh đĩa ảo bên ngoài VM
• Trong máy ảo,
  • Chọc / sys để quét lại các số liệu của đĩa (echo "1"> / sys / class / scsi_device // device / rescan)
  • pvresize / dev / sdX (thay đổi kích thước âm lượng vật lý trong LVM)
  • lvresize --extents + MIỄN PHÍ 100% / dev / VG / lvolXX (thay đổi kích thước âm lượng logic trong LVM)
  • resize2fs (thay đổi kích thước hệ thống tập tin)

Tất cả điều này có thể được thực hiện một cách an toàn trên một hệ thống trực tiếp - và không cần khởi động lại!

Tại sao không phải là một đĩa trần? Điều này khiến tôi lo lắng - Tôi không cảm thấy rằng các đĩa trống đã được chấp nhận rộng rãi đủ, nhưng tôi nghĩ chúng ta đang trên bờ vực chấp nhận rộng hơn nhiều. Có một chủ đề trong danh sách gửi thư btrfs liên quan đến điều này:

http://www.spinics.net/lists/linux-btrfs/msg24730.html

Nhưng một đĩa trống sẽ chỉ cần quét lại và thay đổi kích thước2fs.

Vì vậy, tóm lại, yeah, tránh các bảng phân vùng nếu bạn có thể.

Trong khi câu hỏi của bạn như được viết là về VMWare (ESXi), tôi muốn thêm một tình huống khi tôi quay lại sử dụng các bảng phân vùng sau khi có cùng ý tưởng về KVM.

Hóa ra nếu bạn có khối lượng LVM dưới dạng đĩa cho máy ảo và tạo nhóm âm lượng LVM bên trong máy ảo mà không sử dụng phân vùng (sử dụng toàn bộ đĩa ảo làm PV), VG này sẽ hiển thị bên ngoài máy ảo trên máy chủ. Đây không phải là trường hợp nếu bạn sử dụng phân vùng như PV.

Cấp, đó là một trường hợp góc nhưng đáng xem xét nếu bạn cần một thiết lập như vậy.

Việc làm điều này tốt hơn hay không phụ thuộc vào hệ thống của bạn.

Có những ưu và nhược điểm của từng thiết lập.

Tuy nhiên, những ưu điểm chính của một ổ đĩa như sau:

1. Tính đơn giản: Một ổ đĩa có một tệp duy nhất, có thể dễ dàng phân phối và nhân rộng.
2. Liên kết với hệ điều hành máy chủ: Một tệp duy nhất sẽ được coi là một khối dữ liệu duy nhất và do đó, hệ điều hành máy chủ sẽ biết rằng tất cả các chuỗi truy cập của máy khách sẽ nằm trong một tệp đó. Điều này có thể đạt được trên một số cấu hình hệ điều hành máy chủ bằng cách chỉ cần đặt tất cả các hình ảnh ổ đĩa trong cùng một tệp, nhưng nó sẽ không nhất thiết phải như vậy.

Tuy nhiên, có những lợi thế cho đa ổ đĩa.

1. Mối quan hệ / vị trí thủ công bằng kim loại trần: Với một ổ đĩa duy nhất, bạn bị khóa với một mối quan hệ kim loại trần duy nhất của ổ đĩa.
2. Giới hạn kích thước: Nếu hệ thống của bạn có giới hạn về kích thước của ổ đĩa hoặc trên các tệp, bạn có thể đánh chúng trên các hệ thống rất lớn.
3. Khối lượng chỉ đọc để bảo mật: Đây là lợi thế lớn. Nếu âm lượng chính của bạn cho HĐH chỉ được đọc ở phía VM thì nó cung cấp các lợi thế bảo mật lớn, về cơ bản là khóa khả năng của các chương trình bên trong VM khỏi việc chỉnh sửa HĐH cơ sở của khách. Sử dụng một ổ dữ liệu riêng biệt cho phép bạn tạo các ổ đĩa chỉ đọc, có thể được khởi động đọc-ghi để bảo trì và cập nhật mà không chỉ có dữ liệu mẫu phòng sạch, ngăn chặn sửa đổi các thư mục hệ điều hành quan trọng từ bên trong máy chủ.

có một tùy chọn khác: gắn dữ liệu ứng dụng vào khối lượng NFS. Bạn yêu cầu trình quay tốt (không phải tất cả các triển khai NFS đều giống nhau).

Khi khối lượng NFS lấp đầy, mở rộng âm lượng, máy khách linux sẽ thấy không gian thêm ngay lập tức.

Ứng dụng và nhà cung cấp của bạn phải hỗ trợ có dữ liệu trên NFS và bạn cần một thiết kế NAS cẩn thận nhưng bạn cũng làm như vậy với mọi giải pháp lưu trữ cho môi trường ảo hóa của mình.

Một điểm thưởng khác cho phương pháp này là nếu nhà cung cấp lưu trữ của bạn có công nghệ sao chép / sao chép (như zfs hoặc Netapp) sao lưu dữ liệu và tạo môi trường test / dev thực sự dễ dàng.

Lý do tại sao bạn vẫn cần phân vùng đĩa cho một số bản phân phối Linux là do thực tế là có bộ tải khởi động và tất cả các phần kế thừa đi kèm với nó, tức là BIOS được mô phỏng. Điều này làm cho việc thay đổi kích thước đĩa trở nên khó khăn hơn và nhiều người cuối cùng sẽ sử dụng LVM hoặc không có ý nghĩa tương tự khác.

Người ta có thể chỉ cần tạo một hệ thống tập tin trên toàn bộ ổ đĩa và gắn nó vào /, nó sẽ hoạt động với một bản phân phối Linux rất tùy chỉnh (hoặc có thể tùy chỉnh / không liên quan). Lần cuối cùng tôi thử điều này với Ubuntu 12.04, trình cài đặt không biết cách xử lý vì nó phải cài đặt bảng phân vùng ngu ngốc của họ một bản nhạc jazz. Đây là một trong những vấn đề của phân phối mục đích chung trong thế giới ảo.

Mặt khác, người ta thực sự có thể đưa phân vùng vào sử dụng ít truyền thống hơn, ví dụ ChromeOS và CoreOS có hai phân vùng gốc chỉ đọc để nâng cấp hệ thống.

Một lý do chưa được đề cập cho đến nay là trong một số cơ sở hạ tầng như Google Compute, hiệu suất IO của đĩa tăng tuyến tính theo kích thước của đĩa . Nói cách khác, một ổ đĩa được phân vùng lớn sẽ có hiệu suất IO tốt hơn nhiều ổ đĩa nhỏ.

Lưu ý rằng điều này thường không phải là trường hợp mặc dù. Như Chopper3 đã đề cập, hầu hết các ổ đĩa sẽ có hiệu suất IO tốt hơn. Cuối cùng, nếu tất cả các ổ đĩa ảo của bạn được ánh xạ vào một ổ đĩa vật lý duy nhất, sẽ không có sự khác biệt.

Theo kinh nghiệm của tôi, cách tiếp cận tốt hơn là sử dụng 1 VMDK cho HĐH và tôi thường phân vùng nó theo cách sau:

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

Tôi đã tìm thấy 8GB là đủ cho /, vì tôi thường cài đặt phần mềm phân phối Linux tối thiểu (~ 800 MB) + tôi cần. Nhật ký cũng đi đến phân vùng đó, nhưng nếu được thiết lập chính xác (logrotate trong một tuần) và được chuyển đi nơi khác (syslog / elaticsearch), chúng thường không đặt ra một điều trị để lấp đầy phân vùng.

Dữ liệu được thêm dưới dạng VMDK khác và tôi thường định dạng hệ thống tệp trực tiếp trên đĩa trống (ví dụ: / dev / sdb). Điều này cho phép tôi thay đổi kích thước âm lượng trong VmWare và thay đổi kích thước trực tiếp trong VM mà không cần phải phân vùng lại / umount / khởi động lại.

Tôi phân vùng vì hai lý do:

1. Tài liệu - Tôi đã từng có một quản trị viên EMC "được đào tạo" đánh cắp các LUN ngay từ dưới tôi vì chúng không có giấy tờ và dường như anh ta không được phân bổ, và vào giữa đêm, đã được phân trang cho một cơ sở dữ liệu Oracle đột nhiên ngoại tuyến. Anh ấy đã cung cấp lại LUN của tôi cho một tập khác cho một ứng dụng không liên quan. Từ đó tôi hoang tưởng về tài liệu.
2. Cung cấp quá mức đĩa của tôi. Với các đĩa, nó giữ dữ liệu khỏi các xi lanh chậm hơn và với SSD, nó giúp kéo dài tuổi thọ / MTBF.