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?
linux
virtualization
hard-drive
storage
partition
Savoche
źródło
źródło
Odpowiedzi:
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.
źródło
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.
źródło
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!
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.
źródło
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.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.
źródło
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:
Są jednak zalety napędu wielodyskowego.
źródło
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.
źródło
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.
źródło
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.
źródło
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:
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.
źródło
Dzielę z dwóch powodów:
źródło