"To zależy."
Jeśli pracujesz w środowisku, które kontrolujesz (vmware, kvm lub cokolwiek innego) i możesz podejmować własne decyzje dotyczące QoS wydajności dysku, odradzam używanie LVM wewnątrz maszyn wirtualnych. Nie zapewnia ci dużej elastyczności, której nie można uzyskać na poziomie hiperwizora.
Pamiętaj, że hiperwizor już skutecznie wykonuje te zadania. Jeśli chcesz dowolnie zmieniać rozmiar systemów plików (dobry pomysł), po prostu utwórz oddzielny dysk wirtualny dla każdego systemu plików.
Jedną rzecz, o której możesz pomyśleć idąc tą drogą. Nie musisz nawet umieszczać partycji na dyskach wirtualnych w ten sposób. Na przykład możesz utworzyć dysk wirtualny dla /home
; jest /dev/vdc
w twoim vm. Tworząc system plików, po prostu zrób coś takiego, mke2fs -j /dev/vdc
zamiast określać partycję.
To świetny pomysł, ale ... większość narzędzi (i inni administratorzy, którzy przyszli po ciebie) będą oczekiwać, że zobaczą partycje na każdym dysku. Polecam po prostu umieszczenie jednej partycji na dysku i gotowe. Jednak oznacza to jeszcze jeden krok podczas zmiany rozmiaru systemu plików. I nie zapomnij odpowiednio wyrównać partycji - dobrym pomysłem jest rozpoczęcie pierwszej partycji o wielkości 1 MB.
Wszystko, co powiedziane - Wykonanie tego wszystkiego na poziomie hiperwizora oznacza, że prawdopodobnie musisz ponownie uruchomić maszynę wirtualną, aby zmienić rozmiar partycji. Użycie LVM umożliwiłoby dodanie dysku wirtualnego na gorąco (zakładając, że kombinacja hiperwizora / systemu operacyjnego na to pozwala) i rozwinięcie systemu plików bez ponownego uruchamiania. To zdecydowanie plus.
Tymczasem jeśli używasz dostawcy chmury, jest to bardziej subtelne.
Nie wiem dużo o platformie Azure, GCP ani żadnym z mniejszych graczy, więc nie mogę nic na to poradzić.
Dzięki AWS możesz postępować zgodnie z moimi wskazówkami powyżej i często nic ci nie będzie. Możesz (teraz) zwiększać rozmiar woluminów EBS (dysków wirtualnych) w locie, zmieniać rozmiar partycji itp.
Jednak w ogólnym przypadku sensowne może być umieszczenie wszystkiego na jednym dużym woluminie EBS i użycie LVM (lub, jak sądzę, zwykłych partycji). Amazon daje limit IOPS dla każdego woluminu. Domyślnie ten limit jest skalowany wraz z rozmiarem woluminu. np. w przypadku gp2
woluminów dostajesz 3 IOPS na GiB (minimum 100 IOPS). Zobacz https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html
W przypadku większości obciążeń będziesz chciał, aby wszystkie dostępne IOPS były dostępne dla dowolnego systemu plików, w zależności od potrzeb w danym momencie. Dlatego sensowne jest utworzenie jednego dużego woluminu EBS, zebranie wszystkich IOPS w jednym segmencie i podzielenie go na partycje / LVM.
Przykład:
3 dyski z niezależnymi systemami plików / obszarami wymiany, każdy o wielkości 100 GB. Każdy dostaje 300 IOPS. Wydajność jest ograniczona do 300 IOPS na każdym dysku.
1 dysk o rozmiarze 300 GB. Partycje LVM na dysku o pojemności 100 GB każda. Dysk otrzymuje 900 IOPS. Każda z partycji może korzystać ze wszystkich 900 IOPS.