Зачем иметь несколько разделов на сервере Windows?
==================================================

С моим ИТ-оборудованием у нас есть шаблоны для развертывания серверов с диском / диском C размером 10 ГБ и диском / разделом большего размера. Зачем это делать? Windows (*по крайней мере, до недавнего времени и даже как минимум*) не использует реальные точки динамического монтирования в общих развертываниях серверов.

**редактировать**

Итак, со многими комментариями ниже краткий обзор:

1. Это быстрее, чтобы восстановить меньший раздел. Это включает в себя повреждение NTFS, которое будет храниться в частичном разделе вместо того, чтобы портить систему enitre.
2. Вы получаете некоторую защиту от запущенных процессов. Это включает в себя возможность устанавливать квоты.
3. Обеспечивает некоторую экономию средств для конфигурации Raid
4. Религиозная традиция сохранилась со времен до виртуализации, рейдов и сетей с высокой пропускной способностью.

Помимо #3 (*который, я думаю, является аргументом против разделов*), я до сих пор не вижу причин иметь отдельные разделы. Если вы хотите защитить свои данные, разве вы не просто поместите их на другой набор реальных или виртуальных дисков или иным образом сопоставите их с общим ресурсом где-то еще (NAS, SAN и т. Д.)?

Чтобы остановить данные, заполняющие объем вашей операционной системы и сбой сервера.

Файловые серверы получают выгоду от отдельных томов, если вы используете квоты, так как они обычно устанавливаются на том. (Например, поместите домашние каталоги вашего пользователя на один том, профили на другой, данные компании на другой и т. д.)

ps 10Gb звучит слишком мало для системной громкости. После нескольких лет обновлений Windows и пакетов обновлений, которые скоро будут заполнены.

 .detail-content-adblock { width: 336px; height: 280px; }
 @media(min-width: 768px) { .detail-content-adblock { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .detail-content-adblock { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .detail-content-adblock { width: 728px; height: 90px; } }
 

 (adsbygoogle = window.adsbygoogle || []).push({});
 



Восстановление из резервной копии становится проще, когда файлы программы / данных отделены от установки ОС. Я хотел бы выделить по крайней мере 25 ГБ на раздел ОС, но суть остается той же.

 .detail-content-adblock { width: 336px; height: 280px; }
 @media(min-width: 768px) { .detail-content-adblock { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .detail-content-adblock { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .detail-content-adblock { width: 728px; height: 90px; } }
 

 (adsbygoogle = window.adsbygoogle || []).push({});
 



Обычно я не нахожу преимущества в создании разделов.

Приложения (Microsoft и другие) печально известны тем, что занимают много места в%SystemDrive%, даже если они позволяют выбрать каталог назначения. Поскольку служба автоматического обновления Windows не может сохранять резервные копии исправленных файлов, размер каталогов "$Uninstall$" в папке%SystemRoot% увеличивается и увеличивается. Наличие искусственно ограниченного%SystemDrive% было для меня лишь поделкой.

 .detail-content-adblock { width: 336px; height: 280px; }
 @media(min-width: 768px) { .detail-content-adblock { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .detail-content-adblock { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .detail-content-adblock { width: 728px; height: 90px; } }
 

 (adsbygoogle = window.adsbygoogle || []).push({});
 

Обычно я помещаю общие каталоги и данные в один подкаталог корневого уровня. Это удовлетворяет мои потребности хранить приложения и данные отдельно.

Сказав все это, как правило, это "религиозный" вопрос, и я не спорю с людьми об этом. Делай что хочешь со своими серверами. Отсутствие разделов с данными мне очень помогло.

(Теперь, имея отдельные физические тома / шпиндели... это другая история.)

 .detail-content-adblock { width: 336px; height: 280px; }
 @media(min-width: 768px) { .detail-content-adblock { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .detail-content-adblock { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .detail-content-adblock { width: 728px; height: 90px; } }
 

 (adsbygoogle = window.adsbygoogle || []).push({});
 



Одна из причин, по которой мы это делаем, заключается в том, что если у вас есть какой-то сбойный процесс, который заполняет диск, Windows не падает на землю, когда на диске заканчивается свободное место.

Вторая причина, по которой мы это делаем, - это использование дисков разных размеров / разных уровней для нашей ОС и разделов данных. Например, мы получили бы (я округляю числа и вытаскиваю их отсюда): диск SAS 2x100 ГБ для раздела OS Mirror, а затем диск SAS 6x700 ГБ для раздела данных RAID 10. это может легко сэкономить 1000 долларов США на стоимости системы в конце дня.

Третья причина на самом деле довольно проста: тот, кто собирал сервер с компакт-диска dell, не обращал на это внимания, и по умолчанию он создает дисковод для операционной системы объемом 10 ГБ (я полагаю, 20 для новых версий).

Теперь, как сказал Эван, это действительно личное предпочтение, которое граничит с "религиозными" убеждениями. Честно говоря, с размером сегодняшних дисков, в любом случае будет работать нормально. Делайте то, что вам удобно... или что диктуют ваши корпоративные стандарты.

 .detail-content-adblock { width: 336px; height: 280px; }
 @media(min-width: 768px) { .detail-content-adblock { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .detail-content-adblock { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .detail-content-adblock { width: 728px; height: 90px; } }
 

 (adsbygoogle = window.adsbygoogle || []).push({});
 

---

 РЕДАКТИРОВАТЬ (на основе оригинального asker воспитания виртуализации):.

 .detail-content-adblock { width: 336px; height: 280px; }
 @media(min-width: 768px) { .detail-content-adblock { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .detail-content-adblock { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .detail-content-adblock { width: 728px; height: 90px; } }
 

 (adsbygoogle = window.adsbygoogle || []).push({});
 

Мысль о виртуализации поднимает интересную тему. Как указал Эван, большинство из того, что я должен был сказать, говорило о различных RAID-контейнерах. Тем не менее, в моей среде VMWare у меня есть базовый шаблон 20 ГБ. Теперь начинается интересная часть: все мои серверы размещены в сети SAN, и у меня есть два тома.

1. 20 ГБ диск, который является частью моего шаблона и
2. переменный размер данных Диск с данными, который я присоединяю в соответствии с требованиями систем.

90% времени эти два диска находятся в одном наборе RAID, но это два разных "физических" диска для машины. Как обычно, виртуализация вносит слой неясности в "стандартный" мыслительный процесс ИТ.



У меня нет точного ответа на ваш вопрос, но у меня есть несколько анекдотов, которые могут оказаться полезными при разработке настроек вашего диска / раздела.

(1) Поврежденная NTFS  
У меня был сервер с двумя разделами, один для ОС и один для данных. В какой-то момент за эти годы что-то пошло не так с разделом данных, и один файл, вложенный примерно в 6 уровней, стало невозможно удалить или переименовать. В конце концов, единственным решением было стереть раздел и снова загрузить данные. Очевидно, было бы гораздо более болезненным без перегородок.

(2) Полный раздел данных  
Тот же сервер, что и выше, в другой момент своей жизни сумел создать полностью заполненный раздел данных, в то время как в разделе ОС были доступны десятки ГБ. В качестве меры ограничения я использовал точку соединения для временного хранения данных в разделе ОС до прибытия нового сервера. Это было некрасиво, но это сработало. Избегать разделов означало бы избегать безобразных исправлений.

(3) Сервер 2008 UAC  
На более новом сервере я обнаружил, что у вас могут возникнуть проблемы с администрированием любого диска, кроме диска C:, если вы не являетесь локальным администратором или администратором домена. Быть в группе администраторов недостаточно. Это из-за странности с UAC, которую я пока отключил.

(4) Объемная теневая копия  
 Теневое копирование (также известные как предыдущие версии) включается / выключается для каждого раздела. Если вы не хотите тратить пространство на хранение предыдущих версий для определенного набора данных, разделы - ваш лучший союзник.

Я предпочитаю полностью разделять ОС и данные, используя отдельный массив RAID 1 только для операционной системы. Это обеспечивает большую гибкость. Например, я мог бы обновить все жесткие диски, используемые для хранения данных, не меняя установки ОС вообще.



Конечно, это зависит от сервиса, но в этом есть ценность. Как упоминалось в другом месте, разные разделы могут иметь разные базовые характеристики хранения. Таким образом, разные буквы дисков должны представлять разные лежащие в основе *диски,* а не разделы. Когда-то это был мудрый шаг - поместить ваш файл подкачки в отдельный раздел, но это уже не так выгодно, как раньше. В противном случае сохраните ваш диск C: для ОС и непристойных приложений, которые отказываются идти куда-либо еще, и ваших перемещаемых приложений в другом месте.

С помощью виртуализации вы можете сделать свой диск C: хранилищем с файловой поддержкой, а ваши диски D:, E:, F: и т. Д. Действительно будут NPIV прямым представлением хранилища на уровне блоков. Или ваш диск ОС должен быть зеркальной парой дисков (которая может быть 72 ГБ или 144 ГБ в этом случае), а ваши диски не ОС должны быть набором RAID10 или даже чем-то еще целиком.



Мы используем несколько разделов на наших серверах с диском C:, выделенным для ОС. Другие наши разделы мы используем в основном для хранения данных, таких как базы данных, пользовательские файлы / папки, общие файлы / папки и т. Д.



Я не видел упоминания о коротком поглаживании, поэтому добавлю его сюда.

Меньшие тома / разделы на механических приводах сокращают время доступа / задержку. Это может заметно увеличить производительность в некоторых случаях.

Загрузочные разделы на 10 ГБ кажутся слишком маленькими, в настоящее время объемы от 25 до 80 ГБ кажутся мне более удобными. Независимо от фактического размера, я не форматирую диски на полную емкость по многим причинам, большинство из которых связаны с проблемами производительности.

Если раздел D на том же физическом диске предназначен для редко используемых данных или только для экстренного использования, то C: по-прежнему получает эффект короткого хода. Ключ к тому, чтобы другие не использовали это пространство, как если бы оно было основным хранилищем. Любое регулярное использование вторичного раздела теряет это преимущество.

Я также хотел бы добавить, что небольшие разделы могут позволить вам использовать запасной диск 36 ГБ или 73 ГБ в качестве запасного для поврежденного RAID 1, в отличие от необходимости оставлять массив поврежденным до появления нового диска. Вы также можете использовать твердотельные накопители, которые могут располагаться на меньшей стороне, чтобы захватить небольшой раздел, если вы не выбрали себе размер этой опции.



По моему опыту, наиболее важный момент - это плохие блоки и скандик: вы действительно никогда не хотите, чтобы том объемом 10 ТБ получал плохие блоки и нуждался в скандике, особенно на важном сервере, поскольку это может занять несколько (или много)!) до конца, пока ваши пользователи сначала просят свои файлы, затем обвиняют ИТ-персонал и, наконец, кричат на вас.

Если у вас есть разделы, плохие блоки будут на маленьком диске (по крайней мере, те, которые мешают вашему серверу работать), который будет сканироваться и исправляться достаточно быстро, чтобы ваши пользователи не кричали на вас (потому что, давайте посмотрим правде в глаза, они все равно буду винить айтишников).



**Обновление / восстановление**

При обновлении или восстановлении ОС гораздо проще и понятнее, когда операционная система находится на выделенном томе. В виртуальных средах можно просто скопировать данные ".VHD" на новый сервер для восстановления / обновления службы.

**Служба теневого копирования томов**

Эта функция может быть включена / выключена только для каждого тома. Наиболее эффективно выделить отдельный том, поскольку эта технология работает путем распределения точек восстановления на основе доступного свободного места. Чем больше свободного места, тем дальше назад можно выполнить восстановление. Диск ОС будет занимать место для установленных обновлений, временных программных файлов и т. Д. Выделение предыдущей версии просто означает, что точки восстановления будут сокращены и нецелесообразно используют технологию.

**Сжатие против EFS**

Только одна из этих технологий может использоваться на томе, поэтому использование выделенных томов предотвращает конфликты.

**администрация**

Это скорее предпочтение, чем техническая причина, так как мне гораздо проще перейти на другой том в отличие от вложенной подпапки на томе ОС.

То же самое касается применения разрешений, так как проще управлять этим для отдельных томов, а не для вложенных подпапок.

**Объем ОС - 0 свободного места**

Это не случалось со мной довольно давно, но когда это случилось, происходят очень странные вещи. Если пользователям разрешено изменять содержимое тома ОС (через общий файловый ресурс, загружать большие файлы в базу данных и т. Д.), Вы получите сценарий отказа в обслуживании. Разрешение **намного** проще, когда это происходит с другим томом, а не с той, где находится ОС.



Если системный раздел небольшой, выполнение диагностики и ремонта этого раздела занимает меньше времени, что приводит к сокращению времени простоя. Например, если у вас возникла непредвиденная проблема с диском или файловой системой, и вам необходимо перезагрузить компьютер, чтобы запустить chkdsk в комбинированном разделе системы + 2 ТБ, возможно, сервер не будет подключен к сети до завтрашнего дня. Если этот раздел занимает всего 20 ГБ, резервная копия может быть запущена менее чем за полчаса. Вы также можете сделать резервную копию или создать образ раздела за меньшее время.

Тем не менее, упомянутый вами предел в 10 ГБ кажется пугающе маленьким, поскольку вы быстро займете это пространство с помощью пакетов обновления и исправлений. 20-30 ГБ было бы более подходящим.



При запуске сервера Windows IIS мы отделяли диск ОС от того, куда вы помещали файлы размещенного веб-сайта, чтобы предотвратить обратный путь в каталогах.

Это была проблема Windows 2000 в основном, хотя.



Не забывайте также и о фрагментации файлов: диск с данными на сервере обычно заполняется файлами журналов и постоянно расширяющимися базами данных. Системный раздел также страдает от той же проблемы с обновлениями и внутренними журналами для окон. Но проблема фрагментации в системном разделе приведет к остановке всей системы, поскольку такая же проблема на диске с данными повлияет только на производительность приложения.

Существует также проблема таблицы разделов накопителей, и, хотя она имеет малый размер, чем больше таблица, тем медленнее будет возможность индексировать и искать ее, особенно если у вас огромное количество файлов.