Назад | Перейти на главную страницу

C: \ для ОС, D: \ для данных?

«Раньше» мы всегда отделяли диски нашей ОС (в Windows) от дисков с данными. В мире Linux, хотя я гораздо менее знаком с ним, я знаю, что мудрость подсказывает, что еще больше томов будет определено и использовано в наилучшей конфигурации.

Теперь, когда серверное хранилище с такой же вероятностью будет находиться в сети SAN (где дисковые ресурсы совместно используются многими отдельными операционными системами и приложениями), действительно ли имеет значение, чтобы разделы ОС и данных были разделены на уровне тома?

Что ты думаешь?

Да, безусловно, отделите ОС от данных. Я видел это снова и снова, когда с общим разделом раздел в конечном итоге заполняется и делает невозможным исправление ОС, невозможность расширения раздела (по разным причинам) и т. Д.

ИМО, накладные расходы на управление двумя разделами - небольшая цена за предоставленную изоляцию.

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

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

  1. Космос. Как указывает ErikA, вы действительно ДЕЙСТВИТЕЛЬНО не хотите, чтобы на томе вашей ОС закончилось место. Может случиться всякое плохое. Разделение этих двух методов роста
  2. Требования к доступу к вводу / выводу. Тип ввода-вывода, используемый на томе вашей ОС, обычно сильно отличается от того, который используется вашими томами данных. Разделение типов ввода-вывода - очень хорошая идея на многих уровнях.
  3. Переносимость хранилища. Когда придет время обновить операционную систему сервера, вы можете отключить том ОС и сохранить все данные. Или в средах SAN или VM вы можете просто переместить том данных на новый, только что установленный сервер и сэкономить время на обновлениях.

Кроме того, некоторые операционные системы (среди них Windows) не слишком любят изменять размер тома ОС, что означает, что вам обычно нужно отдавать столько, сколько потребуется в течение его срока службы при форматировании сервера. Сравните это с объемами данных, размер которых может и часто изменяется много раз в течение срока службы сервера. Даже в полностью виртуализированных средах, где ОС и сами тома данных размещаются в одном и том же фактическом хранилище, невозможность изменить размер тома ОС может стать серьезным препятствием. В настоящее время Windows 2008+ рекомендует 30 ГБ для диска C: \, что намного меньше тех 10 ГБ, которые мы использовали в Server 2003; это то, что понравится многим администраторам Windows при переходе с 2003 на 2008 год.

Я бы сказал, это зависит от того, что вы делаете с системой. Если вам может потребоваться переустановка ОС, вы можете избавить себя от лишних хлопот, поместив все свои данные в отдельный раздел. В противном случае я больше не вижу необходимости. Мои два цента.

В общем, я думаю, что разделение пространства ОС по умолчанию (например, C :) от данных (D :) - хорошая идея, но я бы также рекомендовал создать меньший раздел для файлов журнала (L :), чтобы они немного оставались более безопасным и предотвращающим некоторые типы атак типа «отказ в обслуживании».

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

Я бы посмотрел на:

  1. Какие подкаталоги могут заполнить их диск и вызвать проблемы с пространством для других каталогов (например, раздел вне / home и / var / log).
  2. Требуются ли для разных частей вашей структуры каталогов разные файловые системы по соображениям производительности (например, XFS для стабильности, Ext3 для универсального использования и т. Д.)
  3. Какие каталоги, возможно, потребуется расширить в будущем - это хорошие кандидаты для разделения, потому что вы можете просто переименовать каталог, раздел и смонтировать новый набор дискового пространства в расположение каталога и скопировать данные из старого в новый расположение.

Исторические рекомендации по разделению Linux (ну, на самом деле Unix) частично связаны с его происхождением как (сетевой) серверной ОС для мэйнфреймов, на которую, в свою очередь, я подозреваю, повлияла (тогда) относительная ненадежность оборудования. Например, журналы и временные данные обычно разделялись, потому что эти области хранения сильно изнашивались, но если они были потеряны, это не было большой проблемой.

Если вы создаете настольную систему, я бы выбрал разделение данных / без данных / подкачки. Если вы не создаете сервер, который ожидает серьезного отказа, такие вещи, как отдельные / usr / local и / var / tmp, просто становятся головной болью при распределении пространства.

Я бы сказал, что это все еще хорошо - у вас есть 100 ГБ данных (слишком много pr0n, чувак :)), и вам нужно переустановить ОС (или, в соответствии с историей Windows, регулярно переустанавливать ее, чтобы удалить накопившиеся cruft), то сохранить его нетронутым очень просто, чем если бы он тоже был в разделе C.

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

Кроме того, есть еще один фактор - помимо действительно больших вещей (да, это снова pr0n), существует множество инструментов онлайн-резервного копирования (или локальных утилит резервного копирования), которые выполняют непрерывное резервное копирование. Учитывая это, разделение данных не является таким приоритетом, поскольку вы можете легко восстановить их из хранилища резервной копии.

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

Я буду адвокатом дьявола другой школы мысли.

Предположим, из соображений производительности ваш поставщик рекомендует, чтобы раздел ОС не был «разреженным», и хочет, чтобы вы заранее выделили весь раздел ОС. В результате на диске SAN остается от 10 до 20 ГБ (или более) неиспользуемого пространства.

Это нормально для одной виртуальной машины, но есть вероятность, что у вас будет несколько серверов, «критичных к производительности», каждый со своими собственными накладными расходами от 10 до 20 ГБ. В нашей среде это пустое пространство составляло 20% нашего диска SAN. Имейте в виду, что существуют пределы, до которых мы должны заполнять диск SAN (но это уже другая история).

У руководства был выбор

1) Поглотите 20% потраченного впустую места на SAN, что в дополнение к другим требованиям «пустого пространства», и изолируйте любой сценарий «полного диска», который может произойти.

2) Поместите все на диск C: \ и рискуете переполниться диском из-за логов приложений.

Что они сделали?

Учитывая, что Windows 2008R2 может динамически расширять диск C: \ основной ОС и может расширять диск при заполнении, руководство взяло на себя «экономию» средств и реинвестировало их в инструменты мониторинга, такие как SCOM.

Теперь мы получаем больше, чем просто защиту заполнения диска C: \, но у нас есть более полный мониторинг системы для решения других проблем до того, как это произойдет.