Linux na VMware - po co korzystać z partycjonowania?

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.