Linux na VMware - po co korzystać z partycjonowania?

46

Czy instalując maszyny wirtualne z systemem Linux w środowisku zwirtualizowanym (w moim przypadku ESXi), istnieją jakieś ważne powody do partycjonowania dysków (przy użyciu ext4) zamiast dodawania osobnych dysków dla każdego punktu montowania?

Jedyne, co widzę, to to, że nieco łatwiej jest sprawdzić, czy na dysku znajdują się dane z np. Fdisk.

Z drugiej strony widzę dobre powody, dla których nie używam partycji (oczywiście inne niż / boot).

  • Znacznie łatwiejsze rozszerzanie dysków. Wystarczy zwiększyć rozmiar dysku dla maszyny wirtualnej (zwykle w VCenter), a następnie ponownie przeskanować urządzenie na maszynie wirtualnej i zmienić rozmiar systemu plików online.
  • Nigdy więcej problemów z wyrównywaniem partycji do bazowych jednostek LUN.

Nie znalazłem wiele na ten temat. Czy przegapiłem coś ważnego?

Savoche
źródło
16
Aha, chciałem tylko skomentować, jak byłem pod wrażeniem siebie i niektórych innych użytkowników SF o wysokim współczynniku odpowiedzi na twoje pierwsze pytanie. Czasami jesteśmy oskarżani o pobijanie nowych facetów, ale tak naprawdę wielu nowych użytkowników nie czyta, o czym jesteśmy, a czym nie jesteśmy - dlatego pomyślałem, że powinienem podziękować za zadawanie odpowiednich pytań w dobrze napisany i
przemyślany
5
Mam jednak dwie uwagi: 1) VMWare to nie produkt, ale firma. VMWare ESXi byłby produktem. 2) Zredagowałbym to pytanie, aby dotyczyło ogólnie środowisk zwirtualizowanych, ponieważ jest to równie istotne dla np. KVM, Xen i HyperV.
Sven
1
Dzięki. Zredagowałem to sformułowanie, aby było nieco bardziej ogólne.
savoche
@savoche powinieneś zaznaczyć odpowiedź.
ewwhite

Odpowiedzi:

27

To interesujące pytanie ...

Nie wydaje mi się, że istnieje ostateczna odpowiedź, ale mogę podać kontekst historyczny, w jaki sposób najlepsze praktyki dotyczące tego tematu mogły się zmieniać w czasie.

Od 2007 roku musiałem obsługiwać tysiące maszyn wirtualnych z systemem Linux wdrożonych w różnych formach w środowiskach VMware. Moje podejście do wdrażania ewoluowało i miałem unikalne ( czasem niefortunne ) doświadczenie w dziedziczeniu i refaktoryzacji systemów zbudowanych przez innych inżynierów.

Dawne czasy...

Wcześniej (2007) moje wczesne systemy VMware były podzielone na partycje, tak jak moje systemy bez systemu operacyjnego. Po stronie VMware korzystałem z podzielonych plików o grubości 2 GB, aby utworzyć dane maszyny wirtualnej, i nawet nie myślałem o wielu VMDK, ponieważ cieszyłem się, że wirtualizacja może nawet działać!

Infrastruktura wirtualna ...

W ESX 3.5 i we wcześniejszych wydaniach ESX / ESXi 4.x (2009-2011) korzystałem z Linuksa, podzielonego na partycje jak zwykle na monolitycznych plikach VMDK wyposażonych w Thick . Konieczność wstępnej alokacji pamięci zmusiła mnie do myślenia o projektowaniu Linuksa w podobny sposób, jak w przypadku prawdziwego sprzętu. Tworzyłem 36 GB, 72 GB, 146 GB VMDK dla systemu operacyjnego, partycjonując zwykłe /, / boot, / usr, / var, / tmp, a następnie dodałem kolejny VMDK dla partycji „dane” lub „wzrost” (czy to / dom, / opt lub coś specyficznego dla aplikacji). Znów najsłabszy punkt w rozmiarach fizycznych dysków twardych w tej erze wynosił 146 GB, a ponieważ wstępna alokacja była wymagana (chyba że korzystałem z NFS), musiałem zachować ostrożność w kwestii miejsca.

Nadejście cienkiego zaopatrzenia

VMware opracowało lepsze funkcje w zakresie obsługi administracyjnej Thin w późniejszych wydaniach ESXi 4.x, a to zmieniło sposób, w jaki zacząłem instalować nowe systemy. Po dodaniu pełnego zestawu funkcji w wersji 5.0 / 5.1 nowy rodzaj elastyczności pozwolił na bardziej kreatywne projekty. Pamiętaj, że nadążało to za zwiększonymi możliwościami na maszynach wirtualnych, pod względem liczby vCPUS i ilości pamięci RAM, którą można było przypisać do poszczególnych maszyn wirtualnych. Więcej typów serwerów i aplikacji można wirtualizować niż w przeszłości. Ma to rację, ponieważ środowiska komputerowe zaczęły być całkowicie wirtualne.

LVM jest okropny ...

Kiedy pełna funkcjonalność dodawania na gorąco na poziomie maszyn wirtualnych była już dostępna i powszechna (2011-2012), pracowałem z firmą, która dążyła do utrzymania dyspozycyjności maszyn wirtualnych swoich klientów za wszelką cenę ( głupio ). Tak więc objęło to wzrost CPU / RAM VMware online i ryzykowne zmiany rozmiaru dysku LVM na istniejących VMDK. Większość systemów Linux w tym środowisku to pojedyncze konfiguracje VMDK z partycjami ext3 na szczycie LVM. Było to okropne, ponieważ warstwa LVM dodawała złożoności i niepotrzebnego ryzyka dla operacji. Na przykład brak miejsca w / usr może spowodować łańcuch złych decyzji, które ostatecznie oznaczały przywrócenie systemu z kopii zapasowych ... Było to częściowo związane z procesem i kulturą, ale nadal ...

Snobizm partycji ...

Skorzystałem z okazji, aby spróbować to zmienić. Jestem trochę snobem partycji w Linuksie i uważam, że systemy plików powinny być oddzielone na potrzeby monitorowania i potrzeb operacyjnych. Nie lubię także LVM, szczególnie w przypadku VMware i możliwości robienia tego, o co prosisz. Rozszerzyłem więc dodawanie plików VMDK na partycje, które potencjalnie mogą się powiększać. / opt, / var, / home mogą w razie potrzeby uzyskać własne pliki maszyn wirtualnych. I to byłyby surowe dyski. Czasami była to łatwiejsza metoda rozwijania konkretnej partycji niewymiarowej w locie.

Obamacare ...

Wraz z wdrożeniem bardzo głośnego klienta miałem za zadanie zaprojektować szablon referencyjny maszyny wirtualnej Linux, który zostałby użyty do stworzenia ich bardzo widocznego środowiska aplikacji. Wymagania bezpieczeństwa aplikacji wymagały unikalnego zestawu montowań , dlatego współpracowaliśmy z programistami, aby spróbować upchnąć partycje nierozwojowe w jednym VMDK, a następnie dodać osobne VMDK dla każdego montowania, który miał potencjał wzrostu lub miał określone wymagania (szyfrowanie, audyt itp.) Tak więc ostatecznie te maszyny wirtualne składały się z 5 lub więcej VMDK, ale zapewniały najlepszą elastyczność w zakresie przyszłej zmiany rozmiaru i ochrony danych.

Co robię dzisiaj ...

Dzisiaj moim ogólnym projektem dla systemu Linux i tradycyjnych systemów plików jest system operacyjny na jednym cienkim VMDK (podzielonym na partycje) i dyskretnym VMDK na cokolwiek innego. W razie potrzeby dodam na gorąco. W przypadku zaawansowanych systemów plików, takich jak ZFS, jest to jeden VMDK dla systemu operacyjnego, a drugi VMDK, który służy jako zpool ZFS i można go zmienić, wyrzeźbić w dodatkowych systemach plików ZFS itp.

ewwhite
źródło
2
O rany, dzięki, że poczułem się super stary. Dla mnie rok 2007 jest wciąż „prawie aktualny”. :-)
Brian Knoblauch
1
Dodatkowe VMDK dodawane jako punkty montowania nie są dzielone na partycje.
ewwhite
1
Każda technologia ma swoje ograniczenia i nic na tej stronie nie potwierdza twojego twierdzenia, że ​​LVM jest okropny. Zalecam zmodyfikowanie tej części odpowiedzi, ponieważ jest to bardziej FUD niż przydatne informacje. PS. przepraszam, jeśli którykolwiek z moich komentarzy brzmiał ostro, zwykle piszę pomiędzy faktyczną pracą, więc często nie myślę o tym, jak moje słowa mogą brzmieć dla innych.
Jakov Sosic
5
„Z powrotem za dnia” był rok 2007? Byłem darmowym odbiorcą licencji w IBM w 1999 roku, kiedy dostarczono wersję 1. Jestem dinozaurem VM: D (macha @BrianKnoblauch). Zgodnie z komentarzami LVM brzmi to tak, jakbyś oceniał to w kontekście Linuksa. Dojrzała technologia LVM w komercyjnych systemach UNIX przez wiele lat przed Linuksem. Jeśli zarządzałeś najwyższej klasy Solaris / Sparc / EMC Symmetrix, Linux był jakby krokiem w dół (i nadal jest na wiele sposobów). W czasach małych dysków LVM zarządzał wielotabajtowymi bazami danych. Nigdy nie miałem problemów, które opisujesz, które naprawdę brzmią jak problemy ludzi, choć z pewnością mogę je odnieść.
codenheim,
1
+1 pomimo walenia LVM. Reszta odpowiedzi to dobre rzeczy z oczywistych doświadczeń.
codenheim,
7

Masz rację na wiele sposobów, rozumiem argument - jest jedna kwestia, która może okazać się trudna. Jeśli korzystasz z pul zasobów (a wiem, że nie, nienawistne rzeczy), wówczas maszyny wirtualne mogą uzyskać więcej czasu operacji we / wy, jeśli mają więcej dysków - w sytuacjach ekstremalnie ograniczonych zasobów maszyna wirtualna z dwoma dyskami może uzyskać dwa razy więcej zasobów we / wy niż jedna z pojedynczy dysk. To może nie być dla ciebie problem, ale pomyślałem, że zwrócę na to uwagę.

Edycja - och, i to spowodowałoby również nieco wolniejsze przyciąganie, ale znowu to nie może być problem.

Siekacz 3
źródło
6

Kiedy pracowałem w infrastrukturze w konkretnej „dużej firmie zajmującej się oprogramowaniem do wirtualizacji”, często potrzebowaliśmy zwiększać rozmiar systemu plików VM. W tym czasie korzystaliśmy z ext3 / 4.

Zwiększenie wirtualnego dysku jest bardzo łatwe, wybranie nowego rozmiaru urządzenia w systemie operacyjnym na żywo jest stosunkowo łatwe (szperanie w / sys), zmiana rozmiaru systemu plików ext3 / 4 na żywo była łatwa, ale to, co zawsze wydawało się niemożliwe (na żywo) było zmiana rozmiaru partycji.

Trzeba było użyć gparted lub przepisać / zmienić rozmiar tablicy partycji za pomocą fdisk - ale zawsze była ona zablokowana przez jądro i wymagała ponownego uruchomienia, aby jądro mogło pobrać nowy układ (partprobe też tego nie zrobił).

Przeniosłem wiele systemów do LVM, a zmiana rozmiaru systemów plików stała się łatwym, prawie przyjemnym doświadczeniem!

  • Zwiększ obraz dysku wirtualnego poza maszyną wirtualną
  • Na maszynie wirtualnej
    • Poke / sys, aby ponownie przeskanować metryki dysku (echo „1”> / sys / class / scsi_device // device / rescan)
    • pvresize / dev / sdX (zmiana rozmiaru woluminu fizycznego w LVM)
    • lvresize - textents + 100% FREE / dev / VG / lvolXX (zmiana rozmiaru woluminu logicznego w LVM)
    • resize2fs (zmiana rozmiaru systemu plików)

Wszystko to można bezpiecznie wykonać w systemie na żywo - i nie jest wymagane ponowne uruchomienie!

Dlaczego nie nagi dysk? Denerwuje mnie to - nie wydaje mi się, aby nagie dyski były wystarczająco powszechnie akceptowane, ale myślę, że zbliżamy się do szerszej akceptacji. Na liście mailingowej btrfs był wątek związany z tym:

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

Ale sam dysk wymagałby tylko ponownego skanowania i resize2fs.

Podsumowując, tak, unikaj tabel partycji, jeśli możesz.

rrauenza
źródło
1
Nie potrzebujesz restartu, aby jądro ponownie odczytało tablicę partycji. Ale będzie trzeba odłączyć system plików (y) na urządzeniu zmienionym rozmiarze (co jest trudne, jeśli jest to partycja /). Poza tym tablice partycji służą raczej do celów dokumentacyjnych - każdy i jego wujek uruchomiliby fdisk -l(lub odpowiedni odpowiednik), aby zobaczyć, o co chodzi z nieznanym dyskiem. Jeśli jest niepodzielony na partycje, łatwo można go pomylić z „pustym” i nadpisanym. To jest powód, dla którego zawsze tworzę tablicę partycji dla dysków. LVM jest jednak zły.
the-wabbit
To nie jest moje doświadczenie na tych konkretnych maszynach wirtualnych, chociaż działało w przeszłości na innych. Odmontowanie fs nie zwolniło blokady. Może to tylko Centos5, nie wiem. Byłem zakłopotany. W świecie partycji LVM jest niesamowity. W nowym świecie btrfs / zfs jest przestarzały. Oczywiście IMHO.
rrauenza
Minęło trochę czasu, zanim zdałem sobie sprawę, że faktycznie używasz lvm w maszynie wirtualnej ... Czy istnieje powód, dla którego nie używasz LVM na hoście i po prostu dajesz gościowi lv do użycia jako dysku? Kroki zmiany rozmiaru byłyby następujące: zmiana rozmiaru woluminu na hoście, ponowne skanowanie na gościu, resize2fs na gościu.
GnP
Tak, w vm. Ponieważ jest to pod esx, dysk wirtualny musi być plikiem vmdk. Tak, teoretycznie moglibyśmy użyć surowego dysku w gościu.
rrauenza
Korzystanie z nagiego dysku jest o wiele prostsze - usuwa 2 kroki z 5, bez potrzeby znajomości LVM. Zmiana rozmiaru FS w LVM jest ryzykowna, choć staje się coraz lepsza: niebezpieczeństwa i zastrzeżenia LVM .
RichVel
1

Chociaż twoje pytanie, jak napisano, dotyczy VMWare (ESXi), chciałbym dodać sytuację, w której wróciłem do korzystania z tabel partycji po tym samym pomyśle na KVM.

Okazało się, że jeśli masz woluminy LVM jako dyski dla maszyn wirtualnych i utworzysz grupę woluminów LVM w maszynie wirtualnej bez użycia partycji (używając całego dysku wirtualnego jako PV), ta maszyna wirtualna będzie widoczna poza maszyną wirtualną na maszynie hosta. Nie dzieje się tak, jeśli używasz partycji jako PV.

To prawda, że ​​jest to przypadek narożny, ale warto rozważyć, czy potrzebujesz takiej konfiguracji.

Sven
źródło
Dlaczego potrzebujesz VG na LV w maszynie wirtualnej? (uwaga: jestem raczej nowy w LVM, nie oceniam twojej drogi, po prostu próbuję pojąć zastosowanie takiej konfiguracji)
GnP
Możesz użyć filtra LVM na hoście, aby odfiltrować zagnieżdżone LV.
Mircea Vutcovici
1

To, czy lepiej to zrobić, czy nie, zależy od twojego systemu.

Istnieją zalety i wady każdej konfiguracji.

Jednak główne zalety pojedynczego napędu są następujące:

  1. Prostota: pojedynczy dysk ma jeden plik, który można łatwo dystrybuować i replikować.
  2. Wskazówki dla systemu operacyjnego hosta: pojedynczy plik będzie traktowany jako pojedynczy blok danych, a zatem system operacyjny hosta będzie wiedział, że wszystkie sekwencje dostępu do maszyny gościa będą w tym jednym pliku. Można to osiągnąć w niektórych konfiguracjach systemu operacyjnego hosta, po prostu umieszczając wszystkie obrazy dysków w tym samym pliku, ale niekoniecznie tak będzie.

Są jednak zalety napędu wielodyskowego.

  1. Koligacja z gołym metalem / lokalizacja ręczna: za pomocą pojedynczego dysku można zablokować pojedyncze koligacje z gołym metalem.
  2. Ograniczenia rozmiaru: jeśli twój system ma ograniczenia rozmiaru dysku lub plików, możesz trafić je na bardzo dużych systemach.
  3. Woluminy tylko do odczytu dla bezpieczeństwa: to duża zaleta. Jeśli wolumin główny dla systemu operacyjnego jest odczytywany tylko po stronie maszyny Wirtualnej, zapewnia on znaczące korzyści w zakresie bezpieczeństwa, zasadniczo blokując możliwości programów w maszynie Wirtualnej przed edycją podstawowego systemu operacyjnego gościa. Korzystanie z osobnego napędu danych pozwala tworzyć dyski tylko do odczytu, które można uruchamiać w trybie odczytu i zapisu w celu konserwacji i aktualizacji bez danych szablonów w pomieszczeniu czystym, co zapobiega modyfikacji istotnych katalogów systemu operacyjnego z poziomu serwera.
Robert Wm Ruedisueli
źródło
Multi-drive pozwala także mieć (przynajmniej ESXi) niektóre pliki dyskowe w trybie niezależnym. W ten sposób można uniknąć uwzględnienia np. Danych tymczasowych w snapach i kopiach zapasowych opartych na snapach.
savoche
1

jest jeszcze jedna opcja: zamontować dane aplikacji na woluminach NFS. Potrzebujesz dobrych filtrów (nie wszystkie implementacje NFS są takie same).

Po wypełnieniu woluminów NFS rozwiń wolumin, klient systemu Linux natychmiast zobaczy dodatkową przestrzeń.

Twoja aplikacja i dostawca muszą obsługiwać posiadanie danych w systemie plików NFS i potrzebujesz starannego projektu serwera NAS, ale robisz to z każdym rozwiązaniem pamięci masowej w środowisku zwirtualizowanym.

Kolejną zaletą tego podejścia jest to, że jeśli twój dostawca pamięci ma technologię tworzenia migawek / klonowania (jak ZFS lub Netapp), tworzenie kopii zapasowych danych i tworzenie środowisk testowych / deweloperskich jest naprawdę łatwe.

natxo asenjo
źródło
0

Powodem, dla którego nadal musisz wykonać partycjonowanie dysku dla niektórych dystrybucji Linuksa, jest fakt, że istnieje bootloader i wszystkie starsze elementy, które go dotyczą, tj. Emulowany BIOS. To sprawia, że ​​trudniej jest zmienić rozmiar dysku, a wiele z nich skończyłoby się użyciem LVM lub innego podobnego bezsensownego.

Można po prostu stworzyć system plików na całym woluminie i zamontować go /, który będzie działał z bardzo niestandardową (lub konfigurowalną / nieocenioną) dystrybucją Linuksa. Ostatnim razem, gdy próbowałem tego z Ubuntu 12.04, instalator nie wiedział, jak sobie z tym poradzić, ponieważ musi zainstalować ich głupią tablicę partycji i cały jazz. Jest to jeden z problemów ogólnych dystrybucji w zwirtualizowanym świecie.

Z drugiej strony partycjonowanie może być mniej tradycyjne, na przykład ChromeOS i CoreOS mają dwie partycje główne tylko do odczytu do aktualizacji systemu.

programista błędów
źródło
0

Jednym z powodów, o których dotychczas nie wspomniano, jest to, że w niektórych infrastrukturach, takich jak Google Compute, wydajność operacji we / wy dysku rośnie liniowo wraz z rozmiarem dysku . Innymi słowy, jeden duży dysk podzielony na partycje będzie miał lepszą wydajność IO niż wiele małych dysków.

Pamiętaj jednak, że zazwyczaj tak nie jest. Jak wspomniano w Chopper3, najczęściej wiele dysków będzie miało lepszą wydajność IO. Ostatecznie, jeśli wszystkie dyski wirtualne zostaną zamapowane na jednym dysku fizycznym, nie powinno być różnicy.

Calimo
źródło
0

Z mojego doświadczenia wynika, że ​​lepszym rozwiązaniem jest użycie 1 VMDK dla systemu operacyjnego i zwykle dzielę go na partycje w następujący sposób:

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

Znalazłem 8 GB wystarczających na /, ponieważ zwykle instaluję minimalną dystrybucję Linuksa (~ 800 MB) + potrzebne mi oprogramowanie. Dzienniki również przechodzą do tej partycji, ale jeśli są poprawnie skonfigurowane (logrotują przez tydzień) i wysłane w inne miejsce (syslog / elasticsearch), zwykle nie stanowią uczty do wypełnienia partycji.

Dane są dodawane jako kolejny VMDK i zwykle formatuję system plików bezpośrednio na nagim dysku (np. / Dev / sdb). To pozwala mi zmieniać rozmiar woluminu w VmWare i zmieniać go bezpośrednio na maszynie wirtualnej bez konieczności ponownego partycjonowania / umount / restartu.

Jakov Sosic
źródło
Podoba mi się sposób, w jaki konkretnie podzieliłeś swap na partycję po / boot, coś, co dopiero niedawno wymyśliłem (około 2008 roku). Utrzymywanie nawet jednego starego rozdętego obrazu jądra powoduje rozciąganie się skromnych części / boot, a karmienie sda2 do / boot często daje mu wystarczająco dużo miejsca. Posiadanie go tam, gdzie jest, oznacza brak przeniesienia korzenia przechowującego PV, co oszczędza trudnej operacji, którą czasami trzeba wykonać zdalnie. :-)
user2066657
0

Dzielę z dwóch powodów:

  1. Dokumentacja - kiedyś miałem „wyszkolonego” administratora EMC, który wykradł spod mnie jednostki LUN, ponieważ były one nieudokumentowane i wydawały mu się nieprzydzielone, a w środku nocy został przywołany do bazy danych Oracle, która nagle przeszła w tryb offline. Ponownie przygotował moje jednostki LUN na inny wolumin dla niepowiązanej aplikacji. Od tego czasu mam paranoję na punkcie dokumentacji.
  2. Nadmiarowe przydzielanie mojego dysku. Dzięki talerzom chroni dane z wolniejszych cylindrów, a dzięki dyskowi SSD wydłuża żywotność / MTBF.
codenheim
źródło