Наша виртуальная среда разделена на виртуальную машину для каждой роли (DNS, DC, System Center CM, File Server, Log Aggregation, IIS и т. Д.). Если производительность диска не критична, действительно ли необходимо логически отделить файлы ОС Windows от файлов / данных / журналов приложения? В качестве предыдущего стандарта для Windows 2000/2003 и NT4 (ах!) Наш магазин разделил бы рабочую нагрузку между дисками C: и D: и т. Д., Даже если бы они обслуживались одним и тем же базовым дисковым массивом.
Предполагая, что вам не нужны отдельные дисковые массивы для производительности, такие как сценарии SQL Server, остается ли это разделение оптимальным или необходимым? Каковы преимущества / недостатки разделения вашей ОС + данные на разные тома в наши дни?
Одно из преимуществ, которое я могу придумать в пользу нескольких томов, заключается в том, что вы можете запускать chkdsk на несистемном диске в интерактивном режиме без перезагрузки (это сэкономило мне некоторое время простоя в прошлом).
Спасибо за вашу помощь - у нас есть ожидающая сборка нескольких новых служебных серверов, и мы не хотим перерабатывать.
Я не думаю, что это когда-либо было стандартом, хотя это широко применялось. Я никогда не видел ценности в этом и до сих пор не понимаю. Я понимаю причины, по которым вы хотите отделить ваши данные от вашей ОС по причинам резервного копирования / восстановления, но отделение вашей ОС от ваших приложений и данных по соображениям производительности путем создания отдельных логических томов на одной и той же подсистеме физического диска является ошибочной попыткой. Если это так, вы собираетесь вызвать большую нагрузку на производительность дискового ввода-вывода, делая это, поскольку ваша ОС и приложения борются за один и тот же базовый физический диск (и). Если вам нужно отделить приложения, интенсивно использующие дисковый ввод-вывод, от ОС (например, SQL или Exchange), вам нужно сделать это, используя отдельные физические диски или дисковые массивы.
Если вы просто спрашиваете, нужен ли вам «системный» раздел и отдельный раздел «приложения», я не вижу в этом смысла, особенно сейчас.
Раньше это было условием для систем типа UNIX, потому что, если системный том переполнялся данными, у вас могли возникнуть ситуации, которые сделают его не загружаемым или непригодным для использования, поэтому разделение разделов было своего рода псевдофизическим способом предотвращения, скажем, автоматические файлы журнала от заполнения загрузочного раздела.
Сегодня вы не увидите особой пользы от этого, если вы правильно обслуживаете системы. У вас могут возникнуть проблемы сейчас, когда обновления огромны, а обновления системы такие большие; то, что когда-то было нормальным в установочном разделе Windows на 10 гигабайт, теперь крошечное. Я также видел проблемы из-за того, как Windows передает файлы по сети и как временные загрузки, когда она заполняет системный раздел и не может копировать вещи туда, где они должны быть позже, и это ужасно увеличивало проблемы фрагментации в файловой системе.
Если вы виртуализируете эту систему, вы даже не станете утверждать, что получаете лучшую производительность, поскольку виртуальная машина абстрагируется от физического уровня диска, независимо от того, сколько разделов / дисков у нее есть.
Если ваше приложение чувствительно ко времени до такой степени, что вы не можете отключить систему для проверки диска (надеюсь, вам это вряд ли когда-нибудь понадобится), у вас, вероятно, должны быть планы, предусматривающие поддержку переключения при отказе, окна обслуживания и В случае с виртуальной машиной у вас, вероятно, будет способ поддерживать ее работоспособность при диагностике проблемы с помощью моментального снимка или копирования в песочнице, если это необходимо. Если операция критична, у вас уже должны быть планы по обеспечению доступности службы в случае отказа машины. Это дает возможность починить виртуальный ящик без прерывания обслуживания. В противном случае вашим пользователям придется переживать период простоя.
Кроме того, Windows, наконец, обретает большую гибкость (а в Linux это уже было) в создании управления томами на лету, которое может увеличивать и уменьшать диски и объединять их в большие тома (например, поддержка Linux LVM). Windows постепенно отходит от модели, ориентированной на диски, и переходит к модели управления томами на серверах.
Упомянутые вами службы уже имеют некоторую встроенную избыточность, если вы используете Windows DC, поэтому время для chkdsk не должно быть проблемой для многих из них.
В целом, если у вас нет прямой необходимости создавать отдельные тома в виде букв дисков, я бы создал один большой диск и оставил его как есть. Это проще, это более гибко в будущем и в целом требует меньше PITA.
Некоторые операции с файловой системой могут быть проще, о чем вы, вероятно, уже знаете (chkdsk). Например, резервные копии, в зависимости от того, как работает ваша система резервного копирования.
Кроме того, планирование может быть проще. Если требования к дискам вашей ОС постоянны, но требования к приложениям различаются, вы можете получить больше гибкости при развертывании виртуальных машин, если просто подключите диск приложения к шаблонной базовой виртуальной машине.
Я уверен, что есть и другие преимущества и недостатки, но актуальность будет зависеть от того, как работают ваши организации.
Эта практика проистекает из почтенного времени, когда в UNIX (система V и ранее) у вас могли закончиться inodes на загрузочном томе, и вы могли сделать систему незагружаемой. В современных UNIX и Windows это уже не так. Администраторы Windows просто имитировали схему разделения. Я знаю, что администраторы Windows ошибочно полагали (на мой взгляд, на основе старой практики), что отделение данных от ОС означает, что вы каким-то образом защитите данные от повреждения, если загрузочный том выйдет из строя. в любом случае единственная причина для разделения данных - переносимость и возможность расширения. Развернуть отдельный раздел гораздо проще, чем загрузочный том.
Несмотря на то, что производительность ОС и данных на отдельных дисках увеличивается, существует удивительно распространенное заблуждение, что это также относится к отдельным разделам для ОС и данных (или приложений, или чего-то еще). Это не могло быть более неправильным.
Несколько разделов на одном физическом диске или массиве вызывают падение производительности. Причина довольно проста. Наибольшее снижение производительности связано с физическим перемещением головки в сборе. Привод не может даже начать чтение или запись, пока головки не окажутся в нужном месте и не перестанут двигаться вбок. При запуске нескольких разделов головам нужно перемещаться намного больше, чем при работе с одним разделом. Среднее пройденное расстояние также намного больше.
Когда диски были довольно маленькими, имело смысл разделить ОС и данные, хотя бы для того, чтобы для каждого было достаточно места. С современными емкостями накопителей это не имеет смысла, если нет более веской причины, которая просто разделяет их ради этого. Конечно, есть много случаев, когда такое разделение имеет смысл, если вы используете физически отдельные диски или массивы. например Серверу баз данных с высокими требованиями вполне могут потребоваться выделенные диски, чтобы справиться с этим.
С точки зрения чистоты я по-прежнему предпочитаю иметь данные конкретно на другом логическом томе. Это означает, что вы можете иметь любую структуру папок в корне диска, не беспокоясь о том, что Windows будет делать с ней.
В виртуализированной среде это также полезно, поскольку это означает, что вы можете легко отсоединить виртуальный жесткий диск, содержащий данные, и повторно подключить его к другой машине без необходимости вручную копировать файлы с виртуального жесткого диска, что, возможно, дает вам гибкость в отношении окон обслуживания или простоев. Вы также можете легко масштабировать размер этого виртуального диска, при этом ОС не будет ломать голову из-за внезапного изменения размера системного раздела.
Что касается приложений, я в целом придерживаюсь мнения (особенно, когда вы используете одну логическую машину для каждой рабочей нагрузки), что двоичные файлы приложения вряд ли представляют собой проблему с точки зрения дискового пространства, поэтому вам никогда не следует слишком беспокоиться о диск с ОС расширяется больше, чем необходимо, и поэтому его можно безопасно установить вместе с ОС.
Еще одна ориентированная на будущее мысль заключается в том, что если по какой-то причине сервер становится очень узким местом ввода-вывода, вы можете легко взять его виртуальный жесткий диск, содержащий его данные, и переместить его на более быстрый сервер хранения, оставив при этом ОС нетронутой на более медленном хранилище.