Partycjonowanie serwera Unix i układ systemu plików

W Internecie jest wiele sprzecznych informacji na temat partycjonowania serwera Unix, więc potrzebuję porady, jak postępować.

Do tej pory na serwerach, które w naszym środowisku testowym tak naprawdę nie dbałem o partycjonowanie, skonfigurowałem pojedynczą monolityczną /partycję plus swap. Ten schemat partycjonowania nie wydaje się dobrym pomysłem dla naszych serwerów produkcyjnych. Znalazłem dobry punkt wyjścia tutaj , ale wydaje się bardzo niejasne w sprawie szczegółów.

Zasadniczo mam serwer, na którym będę obsługiwał podstawowy stos LAMP (Apache, PHP i MySQL). Będzie musiał obsługiwać przesyłanie plików (do 2 GB). System ma macierz RAID 1 o pojemności 2 TB.

Planuję ustawić:

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

Czy to brzmi rozsądnie, czy też nadmiernie komplikuję?

Podczas układania partycji należy pamiętać o trybach awaryjnych. Zazwyczaj to pytanie ma postać: „Co się stanie, gdy partycja x zapełni się?” Najdroższy voretaq7 przywołał sytuację z pełną /przyczyną wielu trudnych do zdiagnozowania problemów. Spójrzmy na bardziej konkretne sytuacje.

Co się stanie, jeśli Twoja partycja przechowująca dzienniki jest pełna? Tracisz dane audytu / raportowania i czasami są wykorzystywane przez atakujących w celu ukrycia ich aktywności. W niektórych przypadkach system nie uwierzytelni nowych użytkowników, jeśli nie będzie mógł zarejestrować ich zdarzenia logowania.

Co dzieje się w systemie opartym na RPM, kiedy /varjest pełny? Menedżer pakietów nie będzie instalował ani aktualizował pakietów i, w zależności od konfiguracji, może zawieść cicho.

Wypełnianie partycji jest łatwe, szczególnie gdy użytkownik jest w stanie do niej pisać. Dla zabawy, uruchom polecenie i zobacz jak szybko można zrobić dość duży plik: cat /dev/zero > zerofile.

Wykracza to także poza wypełnianie partycji, gdy umieszczasz lokalizacje w różnych punktach montażu, możesz również dostosować ich opcje montażu.

Co się stanie, gdy /dev/nie zostanie zamontowany noexec? Ponieważ /devzwykle zakłada się, że jest obsługiwany przez system operacyjny i zawiera tylko urządzenia, był często (a czasem nadal) używany do ukrywania złośliwych programów. Opuszczenie noexecpozwala uruchamiać przechowywane tam pliki binarne.

Z tych wszystkich i wielu innych powodów wskazówki dotyczące hartowania będą omawiać partycjonowanie jako jeden z pierwszych kroków, które należy wykonać. W rzeczywistości, jeśli budujesz nowy serwer, sposób partycjonowania dysku jest prawie dokładnie pierwszą rzeczą, którą musisz podjąć decyzję, a często najtrudniejszą do późniejszej zmiany. Istnieje grupa o nazwie Center for Internet Security, która produkuje mnóstwo łatwych do odczytania przewodników konfiguracji. Prawdopodobnie możesz znaleźć przewodnik dla konkretnego systemu operacyjnego i zobaczyć wszelkie szczegóły, które mogą powiedzieć.

Jeśli spojrzymy na RedHat Enterprise Linux 6, zalecany schemat partycjonowania jest następujący:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

Zasadą stojącą za wszystkimi tymi zmianami jest zapobieganie sobie wzajemnego wpływu i / lub ograniczenie tego, co można zrobić na określonej partycji. Weźmy /tmpna przykład opcje . Mówi to, że nie można tam utworzyć żadnych węzłów urządzeń, nie można stamtąd uruchamiać programów, a bitu set-uid nie można ustawić na niczym. Z samej swojej natury /tmpjest prawie zawsze dostępny do zapisu na świecie i często jest specjalnym typem systemu plików, który istnieje tylko w pamięci. Oznacza to, że osoba atakująca może użyć go jako łatwego punktu przejściowego do upuszczenia i wykonania złośliwego kodu, a następnie awarii (lub po prostu ponownego uruchomienia) system wyczyści wszystkie dowody. Ponieważ funkcja /tmpnie wymaga żadnej z tych funkcji, możemy łatwo wyłączyć funkcje i zapobiec takiej sytuacji.

Miejsc składowania dziennika, /var/logi /var/log/auditsą rzeźbione przy pomocy buforu do nich z wyczerpaniem zasobów. Dodatkowo, skontrolowany może wykonywać pewne specjalne czynności (zwykle w środowiskach o wyższym poziomie bezpieczeństwa), gdy jego magazyn danych zaczyna się zapełniać. Po umieszczeniu go na partycji wykrywanie zasobów działa lepiej.

Aby być bardziej szczegółowym i zacytować mount(8), to są dokładnie to, co powyżej używane opcje:

noexec Nie zezwalaj na bezpośrednie wykonywanie żadnych plików binarnych w podłączonym systemie plików. (Do niedawna można było mimo wszystko uruchamiać pliki binarne za pomocą polecenia takiego jak /lib/ld*.so / mnt / binary. Ta sztuczka kończy się niepowodzeniem od Linuksa 2.4.25 / 2.6.0.)

nodev Nie interpretuj znaków ani nie blokuj urządzeń specjalnych w systemie plików.

nosuid Nie zezwalaj na działanie bitów identyfikatora użytkownika lub identyfikatora grupy. (Wydaje się to bezpieczne, ale w rzeczywistości jest raczej niebezpieczne, jeśli masz zainstalowany program suidperl (1).)

Z punktu widzenia bezpieczeństwa są to bardzo dobre opcje do poznania, ponieważ pozwolą ci na ochronę samego systemu plików. W wysoce bezpiecznym środowisku możesz nawet dodać tę noexecopcję /home. Utrudni to zwykłemu użytkownikowi pisanie skryptów powłoki do przetwarzania danych, powiedzmy analizowanie plików dziennika, ale także uniemożliwi im wykonanie pliku binarnego, który podniesie uprawnienia.

Należy również pamiętać, że domyślnym katalogiem głównym użytkownika root jest /root. Oznacza to, że będzie w /systemie plików, a nie w /home.

Dokładnie ile dajesz każdej partycji może się znacznie różnić w zależności od obciążenia systemu. Typowy serwer, którym zarządzam, rzadko wymaga interakcji użytkownika i dlatego /homepartycja wcale nie musi być bardzo duża. To samo dotyczy, /varponieważ ma tendencję do przechowywania raczej ulotnych danych, które są często tworzone i usuwane. Jednak serwer WWW zwykle używa /var/wwwjako swojego placu zabaw, co oznacza, że ​​albo musi on znajdować się na osobnej partycji, albo /var/musi być duży.

W przeszłości zalecałem następujące wartości podstawowe.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

Należy je przejrzeć i dostosować zgodnie z celem systemu i sposobem działania środowiska. Poleciłbym również korzystanie z LVM i nie przydzielanie całego dysku. Umożliwi to łatwe powiększanie lub dodawanie partycji, jeśli takie rzeczy są wymagane.

Ignorując leżącą u podstaw macierz RAID ( zobacz to pytanie, aby uzyskać więcej informacji na temat poziomów macierzy RAID i kiedy chcesz ich użyć ), skoncentrujmy się na głównym pytaniu, jakie zadajesz :
„Jak mam rozplanować systemy plików mojego serwera Unix?”

Co jest nie tak z jedną wielką /partycją?

Jak zauważyłeś w swoim pytaniu, wiele dystrybucji Linuksa (szczególnie dystrybucji „Desktop”, takich jak Ubuntu) używa bardzo prostego układu systemu plików: /i [swap].

Ten schemat ma tę zaletę, że jest prosty - jest świetny dla użytkowników DOS / Windows, którzy są przyzwyczajeni do swojego domowego komputera z „dyskiem twardym” jako jednym dużym monolitycznym pojemnikiem ( C:\), do którego wrzucasz rzeczy i nie musisz się martwić na temat braku miejsca w systemach plików - upewnij się, że nie masz dostępu do pojemności dysku i wszystko jest (przynajmniej teoretycznie) w porządku.

Schemat pojedynczego systemu plików ma jednak kilka wad - najczęściej wymienianą wadą jest to, że systemy uniksowe reagują bardzo źle, gdy główny system plików zapełnia się (do momentu odmowy uruchomienia) i jeśli wszystko pisze do /(root) jeden niepoprawny program lub użytkownik może zdjąć cały system.
Pojedynczy duży system plików jest również podatny na całkowitą utratę w przypadku awarii systemu i późniejszego uszkodzenia systemu plików.

Powyższe problemy oraz silne poczucie organizacji powodują, że serwery Unix zwykle mają wiele systemów plików.

Jak rozkładasz system plików Unix?

Mam nadzieję, że jesteś przekonany, że posiadanie wielu systemów plików ma sens. Pytanie brzmi: w jaki sposób dzielisz system na logiczne części i jak decydujesz, ile miejsca dostaniesz?
Odpowiedź brzmi: wiesz i rozumiesz, co twój system operacyjny zamierza umieścić. Punktem wyjścia do tego zrozumienia jest hierstrona man. Większość systemów uniksowych pochodzi ( man hierz systemu Linux i man hierBSD ), a to plus twoja lokalna wiedza na temat tego, co zrobisz instalowany kod , poprowadzi cię w tworzeniu rozsądnego układu partycjonowania.

Mam zamiar opisać tutaj ogólny schemat partycjonowania, ale ten schemat powinien zawsze być modyfikowany, aby spełnić Twoje specyficzne potrzeby.

Ogólny schemat partycjonowania Unixa

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

Specjalne systemy plików

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

Praktyka tworzenia takiego systemu plików pochodzi z dni, w których nie było nalotu na oprogramowanie, a dyski były małe, więc trzeba było użyć kilku z nich, a zatem jedynym sposobem na to było rozbicie systemu plików i umieść różne katalogi na różnych dyskach. Innym historycznym powodem było to, że można łatwo odmontować partycję i dumpwykonać kopię zapasową, czego nie można zrobić z rootem. To narzędzie w większości wypadło obecnie z faworyzowania i zamiast tego można go używać w migawce LVM nawet w katalogu głównym.

Nie ma już żadnego powodu, aby to robić. Jedynym powodem, dla którego warto to zrobić, jest na przykład zapobieganie /tmpzapełnieniu całego dysku.

Ten powód jest obecnie w dużej mierze nieistotny, ponieważ udowadnianie użytkownikom ogólnego dostępu do powłoki poszło na marne, a dziś serwery obsługują dedykowane usługi, takie jak serwery sieciowe lub pocztowe. Ponieważ nie masz losowych użytkowników zdolnych do uruchamiania dowolnych poleceń, zazwyczaj nie musisz się martwić, że próbują zapełnić system plików (a nawet wtedy, gdy to zrobiłeś, miałeś przydziały dysku, aby to zatrzymać).

Jeśli chodzi o to, jakiego poziomu rajdu użyć, musisz pamiętać, że głównym celem rajdu nie jest ochrona danych (do tego służą kopie zapasowe), ale utrzymanie czasu sprawności. Jeśli włączysz /tmpraid0, twój serwer nadal będzie działać i będziesz musiał go naprawić, jeśli jeden z dysków ulegnie awarii. Możesz także użyć raid10 zamiast raid1, aby uzyskać lepszą wydajność.

Bardzo dobrym powodem, aby NIE rozbijać systemu plików, jest to, że jeśli źle przydzielisz alokacje, możesz skończyć z zapełnieniem części systemu plików, pomimo dużej ilości wolnego miejsca w innym miejscu. Korekta tego może być trudna, chyba że użyjesz LVM i nie pozostawisz trochę nieprzydzielonego miejsca.

Wiele informacji o partycjonowaniu zostało wygenerowanych, gdy brakowało miejsca na dysku. W rezultacie zobaczysz stosunkowo małe partycje dla wielu przypadków. Wymagane rozmiary partycji różnią się w zależności od użycia serwera. Najbardziej zmienna bywają /tmp, /var, home, /opt, i /srv. /usrma zwykle rozsądny i stabilny rozmiar. Miejsce na /może obejmować dowolną lub wszystkie inne partycje i ich wymagania dotyczące miejsca. Rozmiar jest naprawdę zależny od tego, co robisz w systemie.

Chciałbym zwiększyć swapi zamontować /tmpna tmpfs. Państwo /tmpużyje swap sklepie podkładu, ale pamięć użycia jako dostępne. Twój rozmiar /tmpwygląda na bardzo wysoki, ale poradzi sobie z przerwanym przesyłaniem, które nie zostało wyczyszczone.

Rozważałbym przeniesienie plików MySQL do /srv. Jest to stosunkowo nowy poziom w hierarchii dysków.

Jeśli nie znasz swoich ostatecznych wymagań, rozważ użycie LVM i rozszerzenie partycji jako uzupełnienie.

W zależności od architektury - możesz nie chcieć używać / tmp, ponieważ jest usuwane po każdym ponownym uruchomieniu. Jeśli Twoja witryna zajmuje się ostatecznym przetwarzaniem przesłanych plików, pomysłem może być zmiana jej na inną lokalizację (za pośrednictwem php.ini); w którym możesz ustawić dowolny punkt montowania.

Jak sugerowano wcześniej, zdecydowanie zaleca się stosowanie LVM i zwiększanie w razie potrzeby.

Gorąco polecam także dedykowaną partycję dla danych MySQL (nadal możesz ją zamontować w katalogu / var / lib / mysql).