Наши файлы проекта хранятся на Windows 2008R2. Теперь пространство на этом диске емкостью 4 ТБ быстро заполняется, и вскоре мы вынуждены либо расширить диск, либо удалить старый файл с диска. Вопрос в том (это утверждал кто-то из нашей ИТ-команды), возникнут ли проблемы с некоторыми приложениями, если мы расширим общий ресурс до более 4 ТБ. Наша организация использует некоторые старые приложения, которые, как утверждается, имеют проблемы, но никто не может сказать наверняка, будут ли проблемы или нет.
Итак, вызывает ли превышение порога 4 ТБ проблемы со старыми приложениями на общих дисках? 4 ТБ было проблемой на локальных дисках на старых компьютерах, но будет ли проблема на общем диске в клиентских приложениях?
Техническая информация: Сервер виртуальный VMware ESXi 5.1. Диск емкостью 4 ТБ является прямым iSCSI-приводом (не через VMware) от Dell Equallogic.
Они мощь быть проблемами. Вопрос в том, насколько низко расположено ваше приложение при доступе к файловой системе. Обычно они не должны быть проблемой, если Windows может обрабатывать их как ваши приложения. должен используйте Windows API для доступа к файловой системе на более низком уровне.
Конечно, лучше перестраховаться, чем сожалеть, поэтому проверьте это перед тем, как перейти к производству.
Единственное, что меня беспокоит, это то, что 4 ТБ - это, по моему опыту, довольно большой том NTFS. CHKDSK стал намного лучше в последних нескольких выпусках Windows, но у вас, вероятно, все равно будет многочасовой сбой, если вы устраните повреждение файловой системы на таком большом томе. (Меньшее количество больших файлов приведет к более быстрому запуску CHKDSK по сравнению с большим количеством маленьких файлов.)
Если такое отключение приемлемо, я думаю, вы можете увеличить объем. Windows определенно справится с этим.
Вы можете подумать о перемещении важных файлов, для которых вы, возможно, захотите сохранить большую доступность, на другой, меньший том NTFS и использовать точку монтирования или DFS-N, чтобы «приклеить» их к большему тому.
Увидев многочасовые запуски CHKDSK, я несколько сдержан в использовании томов NTFS, которые настолько велики в производстве. По крайней мере, я стараюсь использовать их для «архивных» данных, которые могут выдержать некоторую потерю доступности.
Изменить: я не слишком беспокоюсь о приложениях. Microsoft Набор средств обеспечения совместимости приложений (ACT) содержит множество функций для «принуждения» нежелательных приложений к работе. Например, Исправление EmulateGetDiskFreeSpace может привести к тому, что Windows создаст номер свободного пространства, позволяющий работать устаревшим приложениям с целочисленным переполнением и> 2 ГБ свободного дискового пространства.
У меня был много успеха в получении привередливых приложений в работу с помощью ACT.
Меня больше беспокоит прямое сопоставление хранилища iSCSI (по сравнению с чем-то, что находится в кластере vSphere и имеет такую защиту).
Вы можете увеличить размер LUN на Dell, чтобы вам было доступно больше ресурсов хранения. Но на данном этапе было бы разумнее создать новый LUN и переместить на него файлы? Если это вариант и вашему приложению (-ям) не требуется один непрерывный раздел, я бы поступил именно так. Это скорее предложение руководства, а не техническое ограничение. Это уже GPT-диск, и волшебный барьер для размера раздела составлял 2,2 ТБ.
Мне лично не нравятся такие огромные тома NTFS из-за проблем с chkdsk. См. Ответ Эвана Андерсона на этот вопрос.
Также имейте в виду, что chkdsk не только займет много времени, если он вступит в силу, но ТАКЖЕ может потребоваться больше оперативной памяти, чем доступно виртуальной машине.
Эмпирическое правило - примерно 1 ГБ ОЗУ на каждый 1 ТБ дискового пространства, на всякий случай. (Особенно на томах с большим количеством маленьких файлов.)
Большая проблема с устаревшими приложениями заключается в том, что они не справляются с проверками свободного дискового пространства.
Просто чтение / запись файлов обычно нормально, потому что это происходит через системные вызовы Windows, и само приложение не будет создавать ничего большего, чем оно может обработать (надеюсь ...).
Но если он спросит Windows, «сколько на диске свободного места?» (обычная практика перед записью нового файла) он может получить ответ, к которому не готов.
Например. Старые программы Borland C / C ++, Pascal, Object-Pascal и Delphi несколько печально известны этим. Библиотеки времени выполнения Borland, которые используются в этих программах, немного нестабильны в этом отношении. И их по-прежнему много. Visual Basic 4 также является хорошо известным проблемным случаем.
Конечно, также может быть, что ваши устаревшие приложения никогда не вызывают этого поведения. Невозможно предсказать, что произойдет.
Я бы установил на этой виртуальной машине дополнительный отдельный диск размером менее 1 ТБ. Переместите на этот диск папки с устаревшими материалами. Тогда вы можете безопасно расширить исходный диск, не беспокоясь об этом.
Если устаревшие приложения обращаются к данным через общие ресурсы, они даже не заметят, что теперь обращаются к другому диску.
Если устаревший материал работает на самом сервере, зависит от определенной разметки диска и плохо справляется с изменением пути, вы всегда можете смонтировать дополнительный том поверх исходной папки на большом диске. Немного беспорядочно, но это работает.
Хотя у вас не должно быть проблем с дисками размером более 4 ТБ, у вас всегда есть возможность просто переместить целые каталоги на другие диски и создать жесткие ссылки на них. Это будет работать, только если у вас есть каталоги файлов, а не один огромный файл размером 4 ТБ. Если у вас есть несколько каталогов, вы можете переместить любой из них на другой диск и освободить место на этом другом диске. Инструмент для этого - mklink.