C: \ dotyczy systemu operacyjnego, D: \ dotyczy danych?

„Z powrotem za dnia” zawsze segregowaliśmy dyski z systemem operacyjnym (w systemie Windows) od dysków z danymi. W świecie Linuksa, choć jestem go znacznie mniej obeznany, mam świadomość, że mądrość dyktuje jeszcze więcej woluminów zdefiniowanych i wykorzystywanych w konfiguracji najlepszych praktyk.

Teraz, gdy miejsce na serwerze jest równie prawdopodobne w sieci SAN (gdzie zasoby dyskowe są współużytkowane przez wiele pojedynczych systemów operacyjnych i aplikacji), czy naprawdę nie ma już znaczenia oddzielenie systemu operacyjnego i partycji danych na poziomie woluminów?

Jakie są Twoje myśli?

Istnieją trzy główne sterowniki do utrzymania oddzielnego systemu operacyjnego i danych pod względem pamięci.

1. Przestrzeń . Jak wskazuje ErikA, naprawdę NAPRAWDĘ nie chcesz, aby na woluminie systemu zabrakło miejsca. Mogą się zdarzyć wszelkiego rodzaju złe rzeczy. Rozdzielenie tych dwóch metod wzrostu
2. Wymagania dostępu we / wy . Rodzaj operacji we / wy używanych w woluminie systemu operacyjnego jest zasadniczo bardzo różny od rodzaju używanego w woluminach danych. Rozdzielanie typów we / wy jest bardzo dobrym pomysłem na wielu poziomach.
3. Przenośność pamięci masowej . Kiedy przyjdzie czas na aktualizację systemu operacyjnego serwera, możesz nuke wolumin systemu operacyjnego i zachować wszystkie dane. Lub w środowiskach SAN lub VM możesz po prostu przenieść wolumen danych na nowy, świeżo zainstalowany serwer i zaoszczędzić czas na aktualizacjach.

Ponadto niektóre systemy operacyjne (wśród nich Windows) nie podejmują zbyt łagodnych zmian rozmiaru woluminu systemu operacyjnego, co oznacza, że ​​zazwyczaj musisz podać tyle, ile będzie potrzebne podczas jego życia podczas formatowania serwera. Porównaj to z woluminami danych, które mogą i często są wielokrotnie zmieniane przez cały okres istnienia serwera. Nawet w całkowicie zwirtualizowanych środowiskach, w których sam system operacyjny i Datavvolumes są przechowywane w tym samym magazynie, niemożność zmiany wielkości woluminu systemu operacyjnego może być poważnym utrudnieniem. Windows 2008+ zaleca obecnie 30 GB na dysk C: \, co jest dalekie od 10 GB, którego używaliśmy na serwerze 2003; jest to coś, co przykuje uwagę wielu administratorów Windows podczas konwersji z 2003 na 2008 rok.

Tak, z pewnością oddzielają system operacyjny od danych. Widziałem to wielokrotnie, gdy partycja współdzielona kończy się zapełnianiem i uniemożliwianiem łatania systemu operacyjnego, niemożliwości rozszerzenia partycji (z różnych powodów) itp.

IMO, koszty zarządzania dwiema partycjami to niewielka cena za zapłaconą izolację.

W odniesieniu do systemów wspieranych przez SAN, o których wspomniałeś, nadal nie ochronią cię przed zapełnieniem partycji systemu operacyjnego. Dzięki w pełni zwirtualizowanej pamięci masowej nie musisz się martwić o to, aby system operacyjny i dane działały na osobnych wrzecionach.

Powiedziałbym, że to zależy od tego, co robisz z systemem. Jeśli będziesz musiał ponownie zainstalować system operacyjny, możesz zaoszczędzić sobie czasu, umieszczając wszystkie dane na osobnej partycji. W przeciwnym razie nie widzę już potrzeby. Moje dwa centy.

Ogólnie rzecz biorąc, myślę, że oddzielenie domyślnej przestrzeni systemu operacyjnego (np. C :) od danych (D :) jest dobrym pomysłem, ale zaleciłbym również utworzenie mniejszej partycji dla plików dziennika (L :), aby zachować trochę bardziej bezpieczne i zapobiegać niektórym rodzajom ataków typu „odmowa usługi”

Linux jest bardzo fajny, ponieważ system plików pozostaje hierarchicznie w jednym katalogu głównym, bez względu na liczbę używanych dysków fizycznych lub wirtualnych. Zdecydowanie podzieliłbym dysk na partycje, ale niekoniecznie w celu oddzielenia danych od systemu operacyjnego (ponieważ bardzo często te dwa pomieszały się i tak).

Patrzyłbym na:

1. Które podkatalogi prawdopodobnie zapełnią dysk i spowodują problemy z miejscem dla innych katalogów (np. Partycja off / home i / var / log).
2. Czy różne części struktury katalogów wymagają różnych systemów plików ze względu na wydajność (np. XFS dla stabilności, Ext3 dla ogólnego zastosowania itp.)
3. Które katalogi mogą wymagać rozszerzenia w przyszłości - są dobrymi kandydatami do partycjonowania, ponieważ możesz po prostu zmienić nazwę katalogu, podzielić na partycje i zamontować nowy zestaw miejsca na dysku w lokalizacji katalogu oraz skopiować dane ze starego do nowego Lokalizacja.

Historyczne zalecenia dotyczące partycjonowania w Linuksie (cóż, naprawdę w Uniksie) są częściowo spowodowane jego początkami jako (sieciowego) systemu operacyjnego serwera mainframe, na który, jak podejrzewam, miał wpływ (wtedy) względna zawodność sprzętu. Na przykład dzienniki i dane tymczasowe były zwykle oddzielone, ponieważ te obszary pamięci były bardzo zużyte, ale nie było wielkiego problemu, jeśli zostały utracone.

Jeśli budujesz system stacjonarny, wybrałbym podział danych / brak danych / zamiana. O ile nie budujesz serwera, który spodziewa się poważnego nadużycia, rzeczy takie jak oddzielne / usr / local i / var / tmp stają się tylko kłopotem z alokacją przestrzeni.

Powiedziałbym, że nadal miło jest mieć - masz 100 GB danych (za dużo pr0n koleś :)) i musisz ponownie zainstalować system operacyjny (lub, zgodnie z historią systemu Windows, regularnie go instalować, aby usunąć nagromadzone cruft) to bardzo prosta sprawa, aby utrzymać go w nienaruszonym stanie, niż gdyby był on również na partycji C.

Powiedziałbym jednak, że jest tam problem, ponieważ Windows szczególnie lubi upychać wszelkiego rodzaju rzeczy w katalogach na dysku C - to nie tylko katalog „users”, ale wszystkie dane aplikacji i różne bity, które w końcu utknęły również w ProgramData.

Jest jeszcze jeden czynnik - oprócz naprawdę dużych rzeczy (tak, to znowu pr0n) istnieje wiele narzędzi do tworzenia kopii zapasowych online (lub lokalnych narzędzi do tworzenia kopii zapasowych), które wykonują ciągłe kopie zapasowe. Biorąc to pod uwagę, oddzielenie danych nie jest priorytetem, ponieważ można je łatwo przywrócić z lokalizacji kopii zapasowej.

Osobiście staram się dzielić dane + system operacyjny. Próbuję również umieścić aplikacje na innej partycji, aby kopie zapasowe systemu operacyjnego były znacznie mniejsze.

Będę orędownikiem diabła za inną szkołą myślenia.

Załóżmy, że ze względu na wydajność sprzedawca zaleca, aby partycja systemu operacyjnego nie była „rzadka” i chce, abyś przydzielił pełną partycję systemu operacyjnego z góry. Powoduje to, że 10 Gb do 20 Gb (lub więcej) nieużywanego miejsca na dysku SAN.

Jest to w porządku dla pojedynczej maszyny wirtualnej, ale są szanse, że będziesz mieć kilka serwerów „krytycznych pod względem wydajności”, z których każdy ma własne 10 do 20 Gb narzutów. W naszym środowisku ta biała przestrzeń stanowiła 20% naszego dysku SAN. Pamiętaj, że istnieją ograniczenia, do których powinniśmy zapełnić dysk SAN (ale to już inna historia).

Kierownictwo miało wybór

1) Zaabsorbuj 20% zmarnowanego miejsca w sieci SAN, co jest dodatkiem do innych wymagań dotyczących „białej przestrzeni” i izoluj wszelkie scenariusze „pełnego dysku”, które mogą wystąpić

2) Umieść wszystko na dysku C: \ i ryzykuj, że dysk zapełni się z powodu dzienników aplikacji.

Co oni zrobili?

Biorąc pod uwagę, że Windows 2008R2 może dynamicznie rozszerzać dysk C: \ systemu operacyjnego hosta i może powiększać dysk po zapełnieniu, zarząd wziął „oszczędności” kosztów i ponownie zainwestował w narzędzia monitorowania takie jak SCOM.

Teraz otrzymujemy coś więcej niż zwykłą ochronę napełnienia dysku C: \, ale mamy bardziej kompletne monitorowanie systemów w celu rozwiązania innych problemów, zanim to nastąpi.