Linux di VMware - mengapa menggunakan partisi?

Ketika menginstal Linux VM di lingkungan tervirtualisasi (ESXi dalam kasus saya), apakah ada alasan kuat untuk mempartisi disk (saat menggunakan ext4) daripada hanya menambahkan disk terpisah untuk setiap titik pemasangan?

Satu-satunya yang dapat saya lihat adalah membuatnya agak lebih mudah untuk melihat apakah ada data pada disk dengan misalnya fdisk.

Di sisi lain, saya bisa melihat beberapa alasan bagus untuk tidak menggunakan partisi (untuk selain / boot, jelas).

• Jauh lebih mudah untuk memperpanjang disk. Hanya untuk meningkatkan ukuran disk untuk VM (biasanya di VCenter), kemudian memindai ulang perangkat di VM, dan mengubah ukuran sistem file online.
• Tidak ada lagi masalah dengan menyelaraskan partisi dengan LUN yang mendasarinya.

Saya belum menemukan banyak tentang topik ini. Apakah saya melewatkan sesuatu yang penting?

Ini pertanyaan yang menarik ...

Saya tidak berpikir ada jawaban yang pasti, tetapi saya dapat memberikan beberapa konteks historis tentang bagaimana praktik terbaik seputar topik ini mungkin telah berubah dari waktu ke waktu.

Saya harus mendukung ribuan VM Linux yang digunakan dalam berbagai bentuk di lingkungan VMware sejak 2007. Pendekatan saya untuk penyebaran telah berkembang, dan saya memiliki pengalaman unik ( kadang-kadang disayangkan ) dari sistem pewarisan dan refactoring yang dibangun oleh insinyur lain.

Dulu ...

Kembali pada hari (2007), sistem VMware awal saya dipartisi seperti sistem bare metal saya. Di sisi VMware, saya menggunakan split 2GB file tebal untuk terdiri dari data VM, dan bahkan tidak memikirkan gagasan beberapa VMDK, karena saya senang bahwa virtualisasi bahkan dapat bekerja!

Infrastruktur Virtual ...

Dengan ESX 3.5 dan rilis ESX / ESXi 4.x awal (2009-2011), saya menggunakan Linux, dipartisi seperti biasanya di atas file VMDK yang disediakan monolitik Tebal . Setelah melakukan pra-alokasi penyimpanan memaksa saya untuk berpikir tentang desain Linux dengan cara yang sama seperti yang saya lakukan dengan perangkat keras nyata. Saya sedang membuat VMDK 36GB, 72GB, 146GB untuk sistem operasi, mempartisi biasa /, / boot, / usr, / var, / tmp, kemudian menambahkan VMDK lain untuk partisi "data" atau "pertumbuhan" (apakah itu / rumah, / opt atau sesuatu yang spesifik aplikasi). Sekali lagi, sweet-spot dalam ukuran hard disk fisik selama era ini adalah 146GB, dan karena preallokasi adalah persyaratan (kecuali menggunakan NFS), saya harus konservatif dengan ruang.

Munculnya provisi tipis

VMware mengembangkan fitur-fitur yang lebih baik di sekitar Thin provisioning dalam rilis ESXi 4.x yang lebih baru, dan ini mengubah cara saya mulai menginstal sistem baru. Dengan set fitur lengkap yang ditambahkan pada 5.0 / 5.1, jenis fleksibilitas baru memungkinkan desain yang lebih kreatif. Pikiran Anda, ini sejalan dengan peningkatan kemampuan pada mesin virtual, dalam hal berapa banyak vCPUS dan berapa banyak RAM yang dapat dilakukan untuk masing-masing VM. Lebih banyak jenis server dan aplikasi dapat divirtualisasi daripada di masa lalu. Ini benar karena lingkungan komputasi mulai berjalan sepenuhnya virtual.

LVM mengerikan ...

Pada saat fungsionalitas hot-add penuh di tingkat VM sudah ada dan umum (2011-2012), saya bekerja dengan perusahaan yang berusaha untuk menjaga waktu kerja untuk VM klien mereka dengan biaya berapa pun ( bodoh ). Jadi ini termasuk secara online VMware CPU / meningkat RAM dan berisiko LVM disk yang mengubah ukuran pada VMDKs yang ada. Sebagian besar sistem Linux dalam lingkungan ini adalah setup VMDK tunggal dengan partisi ext3 di atas LVM. Ini mengerikan karena lapisan LVM menambah kompleksitas dan risiko yang tidak perlu untuk operasi. Kehabisan ruang di / usr, misalnya, dapat mengakibatkan rantai keputusan buruk yang akhirnya berarti memulihkan sistem dari cadangan ... Ini sebagian proses dan terkait budaya, tetapi masih ...

Keangkuhan partisi ...

Saya mengambil kesempatan ini untuk mencoba mengubah ini. Saya sedikit sombong partisi di Linux dan merasa bahwa sistem file harus dipisahkan untuk pemantauan dan kebutuhan operasional. Saya juga tidak menyukai LVM, terutama dengan VMware dan kemampuan untuk melakukan apa yang Anda minta. Jadi saya memperluas penambahan file VMDK ke partisi yang berpotensi tumbuh. / opt, / var, / home bisa mendapatkan file mesin virtual sendiri jika diperlukan. Dan itu akan menjadi disk mentah. Kadang-kadang ini adalah metode yang lebih mudah untuk memperluas partisi yang terlalu kecil dengan cepat.

Obamacare ...

Dengan onboarding dari klien profil yang sangat tinggi , saya ditugaskan dengan desain template referensi Linux VM yang akan digunakan untuk membuat lingkungan aplikasi yang sangat terlihat. Persyaratan keamanan aplikasi memerlukan satu set mount yang unik , sehingga bekerja dengan para pengembang untuk mencoba menjejalkan partisi non-pertumbuhan ke satu VMDK, dan kemudian menambahkan VMDK terpisah untuk setiap mount yang memiliki potensi pertumbuhan atau memiliki persyaratan khusus (enkripsi, audit, dll.) Jadi, pada akhirnya, VM ini terdiri dari 5 atau lebih VMDK, tetapi memberikan fleksibilitas terbaik untuk mengubah ukuran dan melindungi data di masa depan.

Apa yang saya lakukan hari ini ...

Hari ini, desain umum saya untuk Linux dan sistem file tradisional adalah OS pada satu VMDK tipis (dipartisi), dan VMDK diskrit untuk hal lain. Saya akan menambahkan panas jika diperlukan. Untuk filesystem canggih seperti ZFS, ini adalah satu VMDK untuk OS, dan VMDK lain yang berfungsi sebagai zpool ZFS dan dapat diubah ukurannya, dipahat menjadi filesystem ZFS tambahan, dll.

Anda benar dalam banyak hal, saya bisa melihat argumennya - ada satu masalah yang bisa membuktikan rumit. Jika Anda menggunakan Resource Pools (dan saya tahu saya tidak, hal-hal yang penuh kebencian) maka VMs bisa mendapatkan lebih banyak waktu IO jika mereka memiliki lebih banyak disk - dalam situasi sumber daya yang terbatas seorang VM dengan dua disk bisa mendapatkan sumber daya IO dua kali lebih banyak dibandingkan satu dengan satu disk. Ini mungkin bukan masalah bagi Anda, tetapi saya pikir saya akan menunjukkannya.

Sunting - oh dan itu akan membuat gertakan sedikit lebih lambat juga, tapi sekali lagi itu mungkin tidak menjadi masalah.

Ketika saya bekerja di infrastruktur di "perusahaan perangkat lunak virtualisasi besar", kami sering kali perlu menambah ukuran sistem file vm. Kami menggunakan ext3 / 4 saat itu.

Meningkatkan disk virtual sangat mudah, mengambil ukuran perangkat baru dalam OS live relatif mudah (mencari-cari di / sys), mengubah ukuran filesystem ext3 / 4 itu mudah, tetapi apa yang selalu tampak mustahil (untuk live) adalah mengubah ukuran partisi.

Anda harus menggunakan gparted atau menulis ulang / mengubah ukuran tabel partisi menggunakan fdisk - tetapi selalu dikunci oleh kernel dan membutuhkan reboot untuk mendapatkan kernel untuk mengambil tata letak baru (partprobe tidak melakukannya juga.)

Saya memindahkan banyak sistem ke LVM dan mengubah ukuran sistem file menjadi pengalaman yang mudah, hampir menyenangkan,!

• Meningkatkan image disk virtual di luar VM
• Di dalam VM,
  • Poke / sys untuk memindai ulang metrik disk (gema "1"> / sys / class / scsi_device // perangkat / pindai ulang)
  • pvresize / dev / sdX (mengubah ukuran volume fisik dalam LVM)
  • lvresize --extents + 100% GRATIS / dev / VG / lvolXX (mengubah ukuran volume logis dalam LVM)
  • resize2fs (mengubah ukuran sistem file)

Semua ini dapat dilakukan dengan aman di sistem live - dan tidak perlu reboot!

Mengapa bukan disk kosong? Itu membuat saya gugup - saya tidak merasa bahwa disk kosong sudah cukup diterima, tetapi saya pikir kita berada di ambang penerimaan yang jauh lebih luas. Ada utas di milis btrf yang terkait dengan ini:

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

Tapi disk kosong hanya akan membutuhkan rescan dan resize2fs.

Jadi, secara ringkas, ya, hindari tabel partisi jika Anda bisa.

Sementara pertanyaan Anda seperti yang ditulis adalah tentang VMWare (ESXi), saya ingin menambahkan situasi di mana saya kembali menggunakan tabel partisi setelah memiliki ide yang sama pada KVM.

Ternyata jika Anda memiliki volume LVM sebagai disk untuk VM dan membuat grup volume LVM di dalam VM tanpa menggunakan partisi (menggunakan seluruh disk virtual sebagai PV), VG ini akan terlihat di luar VM pada mesin host. Ini tidak terjadi jika Anda menggunakan partisi sebagai PV.

Memang, ini adalah kasus sudut tetapi layak dipertimbangkan jika Anda memerlukan pengaturan seperti itu.

Lebih baik melakukan ini atau tidak tergantung pada sistem Anda.

Ada pro dan kontra dari setiap pengaturan.

Namun, keuntungan utama dari satu drive adalah sebagai berikut:

1. Kesederhanaan: Satu drive memiliki satu file, yang dapat dengan mudah didistribusikan dan direplikasi.
2. Petunjuk untuk OS Host: Satu file akan diperlakukan sebagai satu blok data, dan karenanya OS host akan tahu bahwa urutan akses mesin tamu semua akan berada dalam satu file itu. Ini dapat dicapai pada beberapa konfigurasi OS host dengan hanya menempatkan semua gambar drive dalam file yang sama, tetapi tidak harus demikian.

Namun, ada kelebihan untuk multi-drive.

1. Afinitas / lokasi manual logam kosong: Dengan satu drive Anda dikunci ke afinitas logam-telanjang tunggal pada drive.
2. Batasan ukuran: Jika sistem Anda memiliki batasan pada ukuran drive atau file, Anda dapat menekannya pada sistem yang sangat besar.
3. Volume Hanya Baca untuk keamanan: Ini adalah keuntungan besar. Jika volume master Anda untuk OS dibaca hanya pada sisi VM itu memberikan keuntungan keamanan utama, pada dasarnya mengunci kemampuan program di dalam VM dari mengedit OS dasar tamu. Menggunakan drive data yang terpisah memungkinkan Anda untuk membuat drive read-only, yang dapat di-boot read-write untuk pemeliharaan dan pembaruan tanpa hanya data template cleanroom, mencegah modifikasi direktori OS vital dari dalam server sama sekali.

ada opsi lain: pasang data aplikasi pada volume NFS. Anda memerlukan filer yang baik (tidak semua implementasi NFS adalah sama).

Ketika volume NFS terisi, perluas volume, klien linux akan segera melihat ruang ekstra.

Aplikasi dan vendor Anda harus mendukung memiliki data pada NFS, dan Anda memerlukan desain NAS yang hati-hati tetapi Anda melakukannya dengan setiap solusi penyimpanan untuk lingkungan tervirtualisasi Anda.

Poin bonus lain untuk pendekatan ini adalah jika vendor penyimpanan Anda memiliki teknologi snapshotting / kloning (seperti zfs atau Netapp) mencadangkan data dan membuat lingkungan uji / dev sangat mudah.

Alasan mengapa Anda masih perlu melakukan partisi disk untuk beberapa distribusi Linux adalah karena fakta bahwa ada bootloader dan semua potongan warisan untuk pergi dengannya, yaitu ditiru BIOS. Ini membuatnya lebih sulit untuk mengubah ukuran disk dan banyak yang akhirnya akan menggunakan LVM atau yang tidak masuk akal lainnya.

Seseorang dapat dengan mudah membuat sistem file pada seluruh volume dan me-mount-nya /, yang akan bekerja dengan distribusi Linux yang sangat khusus (atau dapat dikustomisasi / tidak dikritik). Terakhir kali saya mencoba ini dengan Ubuntu 12.04, installer tidak tahu bagaimana menanganinya karena harus menginstal tabel partisi bodoh mereka semua jazz. Ini adalah salah satu masalah distribusi tujuan umum di dunia tervirtualisasi.

Di lain pihak, satu sebenarnya dapat menempatkan partisi untuk penggunaan yang kurang tradisional, misalnya ChromeOS dan CoreOS memiliki dua partisi root read-only untuk peningkatan sistem.

Salah satu alasan yang belum disebutkan sejauh ini adalah bahwa dalam beberapa infrastruktur seperti Google Compute, kinerja IO disk meningkat secara linier dengan ukuran disk . Dengan kata lain, satu drive dipartisi besar akan memiliki kinerja IO yang lebih baik daripada beberapa drive kecil.

Perhatikan bahwa ini umumnya tidak demikian. Seperti yang disebutkan oleh Chopper3 paling sering beberapa drive akan memiliki kinerja IO yang lebih baik. Pada akhirnya jika semua drive virtual Anda dipetakan ke drive fisik tunggal, seharusnya tidak ada perbedaan.

Dalam pengalaman saya pendekatan yang lebih baik adalah menggunakan 1 VMDK untuk OS dan saya biasanya mempartisi dengan cara berikut:

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

Saya menemukan 8GB sudah cukup untuk /, karena saya biasanya menginstal distribusi Linux minimal (~ 800MB) + perangkat lunak yang saya butuhkan. Log juga masuk ke partisi itu, tetapi jika diatur dengan benar (logrotate selama seminggu), dan dikirim ke tempat lain (syslog / elasticsearch) mereka biasanya tidak berpangku tangan untuk mengisi partisi.

Data ditambahkan sebagai VMDK lain, dan saya biasanya memformat sistem file secara langsung melalui disk kosong (mis. / Dev / sdb). Ini memungkinkan saya untuk mengubah ukuran volume di VmWare, dan mengubah ukurannya langsung di VM tanpa perlu partisi ulang / umount / reboot.

Saya mempartisi karena dua alasan:

1. Dokumentasi - Saya pernah memiliki seorang administrator EMC "terlatih" mencuri LUN langsung dari bawah saya karena mereka tidak berdokumen dan baginya tidak teralokasi, dan di tengah malam, dipetakan untuk database Oracle yang tiba-tiba menjadi offline. Dia telah menyediakan kembali LUN saya untuk volume lain untuk aplikasi yang tidak terkait. Sejak itu saya paranoid tentang dokumentasi.
2. Menyediakan disk saya secara berlebihan. Dengan piring-piring itu menjaga data dari silinder yang lebih lambat dan dengan SSD, itu memperpanjang masa pakai / MTBF.