В моем ИТ-отделе у нас есть шаблоны для развертывания серверов с изящным диском / разделом C (10 ГБ) и диском / разделом D. Зачем это делать? Окна (по крайней мере, до недавнего времени и притом минимально) не имеет реального использования динамических точек монтирования в обычных развертываниях серверов.
редактировать
Итак, со многими комментариями ниже синопсис:
Помимо №3 ( что, я думаю, является аргументом против перегородок), Я по-прежнему не вижу смысла иметь отдельные разделы. Если вы хотите защитить свои данные, не могли бы вы просто поместить их на другой набор реальных или виртуальных дисков или иным образом сопоставить с общим ресурсом где-то еще (NAS, SAN, что угодно)?
Чтобы остановить данные, заполняющие объем вашей операционной системы и сбой сервера.
Файловые серверы выигрывают от использования отдельных томов, если вы используете квоты, поскольку они обычно устанавливаются для каждого тома. (например, поместите домашние каталоги пользователя на один том, профили на другой, данные компании на другой и т. д.)
p.s. 10 Гб звучит слишком мало для системного объема. После нескольких лет обновлений Windows и пакетов обновлений они скоро заполнятся.
Восстановление из резервной копии становится проще, если файлы программы / данных отделены от установки ОС. Я люблю отдавать разделу ОС хотя бы 25Гб, но суть остается прежней.
Обычно я не вижу преимущества в создании перегородок.
Приложения (Microsoft и другие) печально известны тем, что требуют места на% SystemDrive%, даже если они позволяют выбрать каталог назначения. Поскольку служба автоматического обновления Windows Update не может не сохранять резервные копии исправленных файлов, размер «$УдалитьКаталоги $ "в% SystemRoot% растут и растут. Для меня наличие искусственно ограниченного% SystemDrive% было всего лишь надстройкой.
Я обычно помещаю общие каталоги и данные в один подкаталог корневого уровня. Это удовлетворяет мои потребности в разделении приложений и данных.
Сказав все это, в целом это «религиозный» вопрос, и я не спорю с людьми по этому поводу. Делайте со своими серверами что хотите. Отсутствие разделов для данных сослужило мне хорошую службу.
(Теперь, имея отдельные физические тома / шпиндели ... это уже другая история.)
Частично причина, по которой мы это делаем, заключается в том, что если у вас есть какой-то неконтролируемый процесс, который заполняет диск, Windows не падает на землю, когда на диске заканчивается место.
Вторая причина, по которой мы делаем это, заключается в том, чтобы разрешить использование дисков разного размера / разных уровней рейдов для нашей ОС и разделов данных. Например, мы бы получили (я округляю числа и вытаскиваю их из воздуха) 2 диска SAS по 100 ГБ для раздела OS Mirror, а затем 6 дисков SAS по 700 ГБ для раздела данных RAID 10. это может легко сэкономить вам 1000 долларов на стоимости системы в конце дня.
Третья причина на самом деле довольно проста: тот, кто построил сервер с компакт-диском dell, не обратил на это внимания и по умолчанию он создает диск ОС на 10 ГБ (я думаю, 20 в более новых выпусках).
Как сказал Эван, это действительно личное предпочтение, граничащее с "религиозной" верой. Честно говоря, с размером сегодняшних дисков все будет нормально. Делайте то, что вам удобно ... или то, что диктует ваши корпоративные стандарты.
Мысль о виртуализации поднимает интересную тему. Как заметил Эван, большая часть того, что я хотел сказать, касалась различных контейнеров RAID. Однако в моей среде VMWare у меня есть базовый шаблон размером 20 ГБ. Теперь самое интересное: все мои серверы размещены в сети SAN, и у меня представлены два тома.
диск 20 ГБ, который является частью моего шаблона и
диск с данными переменного размера, который я подключаю в соответствии с требованиями системы.
В 90% случаев эти два диска находятся в одном наборе RAID, но являются двумя разными «физическими» дисками для машины. Как обычно, виртуализация вносит некую непонятность в «стандартный» мыслительный процесс ИТ.
У меня нет точного ответа на ваш вопрос, но у меня есть несколько анекдотов, которые могут вам пригодиться при проектировании настройки диска / раздела.
(1) Поврежденная NTFS
У меня был сервер с двумя разделами, один для ОС и один для данных. В какой-то момент с разделом данных что-то пошло не так, и один файл, вложенный примерно на 6 уровней в глубину, стало невозможно удалить или переименовать. В конце концов, единственным решением было стереть раздел и снова загрузить данные. Очевидно, без перегородок было бы намного больнее.
(2) Полный раздел данных
Тот же сервер, что и выше, в другой момент своей жизни сумел получить полностью полный раздел данных, в то время как в разделе ОС были доступны десятки ГБ. В качестве временной меры я использовал точку соединения для временного хранения данных в разделе ОС до прибытия нового сервера. Это было некрасиво, но сработало. Избегать разделов означало бы избегать уродливых исправлений.
(3) Сервер 2008 UAC
На более новом сервере я обнаружил, что у вас могут возникнуть проблемы с администрированием любого диска, кроме диска C :, если вы не являетесь локальным администратором или администратором домена. Недостаточно быть в группе администраторов. Это из-за странности с UAC, который я пока отключил.
(4) Теневая копия тома
Теневое копирование (также известное как предыдущие версии) включается / выключается для каждого раздела. Если вы не хотите тратить место на хранение предыдущих версий для определенного набора данных, разделы - ваш лучший союзник.
Я предпочитаю полностью разделить ОС и данные с помощью отдельного массива RAID 1 только для операционной системы. Это дает большую гибкость. Например, я мог бы обновить все жесткие диски, используемые для хранения данных, без необходимости вообще менять установку ОС.
Мы используем несколько разделов на наших серверах с диском C:, выделенным для ОС. Другие наши разделы мы используем в основном для хранения данных, таких как базы данных, пользовательские файлы / папки, общие файлы / папки и т. Д.
Это, конечно, зависит от сервиса, но в этом есть ценность. Как упоминалось в другом месте, разные разделы могут иметь разные характеристики базового хранилища. Таким образом, разные буквы дисков должны означать разные подложки. диски а не перегородки. Когда-то было разумным шагом поместить файл подкачки в отдельный раздел, но теперь это уже не так полезно, как раньше. В противном случае оставьте диск C: для ОС и проблемных приложений, которые отказываются перемещаться в другое место, а также для перемещаемых приложений в другом месте.
С виртуализацией вы можете сделать свой диск C: файловым хранилищем, а диски D :, E :, F: и т. Д. Действительно будут представлять собой NPIV-прямые представления хранилища на уровне блоков. Или пусть ваш диск с ОС будет зеркальной парой дисков (это может быть 72 ГБ или 144 ГБ), а ваши диски, не относящиеся к ОС, будут набором RAID10 или даже чем-то совершенно другим.
При запуске сервера Windows IIS мы отделили диск ОС, на который вы помещаете файлы размещенного веб-сайта, чтобы предотвратить обход каталогов.
В основном это была проблема Windows 2000.
Если ваш системный раздел небольшой, на выполнение диагностики и восстановления в этом разделе уходит меньше времени, что сокращает время простоя. Например, если у вас возникла непредвиденная проблема с диском или файловой системой и вам необходимо перезагрузить компьютер, чтобы запустить chkdsk на комбинированном разделе система + данные объемом 2 ТБ, возможно, у вас не будет сервер снова в сети до завтра. Если размер этого раздела составляет всего 20 ГБ, вы сможете создать резервную копию менее чем за полчаса. Вы также можете сделать резервную копию или создать образ раздела за меньшее время.
Тем не менее, упомянутый вами предел в 10 ГБ кажется тревожно маленьким, поскольку вы быстро займете это пространство с помощью пакетов обновления и исправлений. 20-30 ГБ было бы больше.
Я не видел упоминания о Short Stroking, поэтому добавлю его сюда.
Меньшие тома / разделы на механических дисках сокращают время доступа / задержку. В некоторых случаях это может заметно повысить производительность.
Загрузочные разделы 10 ГБ кажутся слишком маленькими, в настоящее время мне кажутся более удобными тома от 25 до 80 ГБ. Независимо от фактического размера, я не форматирую диски до их полной емкости по нескольким причинам, большинство из которых связано с проблемами производительности.
Если раздел D на том же физическом диске предназначен для редко используемых данных или только для аварийного использования, то C: все равно получает преимущество эффекта короткого хода. Ключевым моментом здесь является удержание других от использования этого пространства, как если бы оно было основным хранилищем. Любое регулярное использование вторичной перегородки приводит к потере этого преимущества.
Я бы также добавил, что небольшие разделы могут позволить вам использовать запасной диск емкостью 36 или 73 Гбайт в качестве запасного для деградированного RAID 1 вместо того, чтобы оставлять массив в неисправном состоянии до тех пор, пока не появится новый диск. Вы также можете использовать твердотельные накопители, которые могут быть меньше по размеру, чтобы занять небольшой раздел, если вы не выбрали этот вариант.
Не забывайте и о фрагментации файлов: диск данных на сервере обычно заполняется файлами журналов и постоянно расширяющимися базами данных. Системный раздел также страдает той же проблемой с обновлениями и внутренними журналами для Windows. Но проблема фрагментации в системном разделе приведет к остановке всей системы, тогда как та же проблема на диске с данными повлияет только на производительность приложения.
Также существует проблема с таблицей разделов дисков, и, хотя это небольшая проблема, чем больше таблица, тем медленнее возможность индексировать и искать в ней, особенно если у вас огромное количество файлов.
По моему опыту, наиболее важным моментом являются плохие блоки и сканирование: вы действительно никогда не захотите, чтобы том 10 ТБ получал плохие блоки и нуждался в сканировании, особенно на важном сервере, так как это может занять несколько (или много !) часов до конца, пока ваши пользователи сначала просят свои файлы, затем обвиняют ИТ-персонал и, наконец, кричат на вас.
Если у вас есть разделы, плохие блоки будут на небольшом диске (по крайней мере, те, которые мешают работе вашего сервера), которые будут сканироваться и исправляться достаточно быстро, чтобы ваши пользователи не кричали на вас (потому что, давайте посмотрим правде в глаза, они все равно буду винить айтишников).
Обновление / Восстановление
Выполнять обновление или восстановление ОС намного проще и чище, когда операционная система находится на выделенном томе. В виртуальных средах можно просто скопировать данные «.VHD» на новый сервер для восстановления / обновления службы.
Служба теневого копирования тома
Эта функция может быть включена / выключена только для каждого тома. Наиболее эффективно выделить отдельный том, поскольку эта технология работает, выделяя точки восстановления на основе доступного свободного места. Чем больше свободного места доступно, тем дальше назад можно выполнить восстановление. Диск ОС будет занимать место для установленных обновлений, временных программных файлов и т. Д. Выделение предыдущей версии просто означает, что точки восстановления будут сокращены, и использование этой технологии неэффективно.
Сжатие против EFS
На томе можно использовать только одну из этих технологий, поэтому использование выделенных томов предотвращает конфликты.
Администрация
Это скорее предпочтение, чем техническая причина, поскольку мне намного проще перейти к другому тому, в отличие от вложенной подпапки на томе ОС.
То же самое и с применением разрешений, так как это легче управлять для каждого тома, а не вложенных вложенных папок.
Том ОС - 0 свободного места
Некоторое время со мной этого не случалось, но когда это произошло, происходят очень странные вещи. Если пользователям разрешено изменять содержимое тома ОС (через файловый ресурс, загружать большие файлы в базу данных и т. Д.), Вы получите сценарий отказа в обслуживании. Разрешение много проще, когда это происходит с томом, отличным от того, где находится ОС.