Как правильно установить и настроить файловый сервер на Windows Server

В качестве примера используется Windows Server 2012 R2 (2016, 2019). Инструкция разбита на несколько шагов и представляет из себя полный цикл настройки файлового хранилища для использования в малых и средних компаниях.

Шаг 1. Выбор оборудования и подготовка сервера

В качестве сервера, желательно, выбрать профессиональное оборудование. Системные требования для файлового сервера не высокие:

• Процессор может быть самый простой;
• Оперативная память также не сильно используется;
• Дисковая система — самый основной компонент. Ее объем зависит от специфики бизнеса. Примерная формула — не менее 15 Гб на пользователя и не менее 1 Тб на сервер. До 50 пользователей можно рассматривать диски SATA, после — SAS или SSD.

Например, для компании в 300 пользователей подойдет сервер с процессором Xeon E3, 8 Гб ОЗУ и 5 Тб дискового пространства на дисках SAS 10K.

Дополнительные требования

1. Для обеспечения сохранности информации при выходе из строя жесткого диска, необходим RAID-контроллер. Настройка последнего выполняется из специального встроенного программного обеспечения, которое запускается при загрузке сервера;
2. Сервер должен быть подключен к источнику бесперебойного питания;
3. Необходимо предусмотреть резервное копирование. Для этого нужен дисковый накопитель (внешний жесткий диск) или другой сервер.

Подробнее о выборе оборудования читайте статью Как выбрать сервер.

Шаг 2. Установка Windows и настройка системы

Установка системы

На этом шаге все стандартно, за исключением одного нюанса: разбивая во время установки Windows жесткий диск, стараемся выделить небольшую часть (70 — 120 Гб) для системы и все остальное под данные. Если выделить много дискового пространства для системного раздела, увеличится время его обслуживания и фрагментация, что негативно скажется на производительности и надежности системы в целом.

Настройка системы

1. Проверяем правильность настройки времени и часового пояса;
2. Задаем понятное имя для сервера и, при необходимости, вводим его в домен;
3. Если сервер не подключен напрямую к сети Интернет, стоит отключить брандмауэр;
4. Для удаленного администрирования, включаем удаленный рабочий стол;
5. Устанавливаем все обновления системы.

Шаг 3. Базовые настройки файлового сервера

Это стандартные действия, которые выполняются при настройке обычного файлового сервера.

Установка роли и вспомогательных компонентов

Как правило, данная роль устанавливается вместе с Windows. Остается только это проверить и доустановить компоненты, которые нужны для полноценной эксплуатации сервиса.

Открываем Диспетчер серверов. Он может быть запущен из панели быстрого запуска.

Нажимаем Управление — Добавить роли и компоненты.

В открывшемся окне оставляем Установка ролей и компонентов и нажимаем Далее.

В следующем окне выбираем нужный сервер (выбран по умолчанию, если работаем на сервере, а не через удаленную консоль) и нажимаем Далее.

Среди ролей находим Файловые службы и службы хранилища, раскрываем ее и проверяем, что установлены галочки напротив следующих компонентов:

• Службы хранения;
• Файловый сервер;

Если данные службы не установлены, выбираем их и нажимаем Далее.

В окне Выбор компонентов просто нажимаем Далее.

Откроется окно Подтверждение установки компонентов. Нажимаем Установить и после окончания процесса перезагружаем сервер.

Настройка шары (общей папки)

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

В открывшемся окне переходим на вкладку Доступ и нажимаем Расширенная настройка:

Ставим галочку Открыть общий доступ к этой папке и нажимаем кнопку Разрешения:

Предоставляем полный доступ всем пользователям:

* конечно же, мы не будем давать доступ всем пользователям, но для этого есть вкладка безопасность (см. ниже).

Нажимаем OK и еще раз OK.

Теперь переходим на вкладку Безопасность и нажимаем Дополнительно:

В открывшемся окне нажимаем Отключение наследования и Преобразовать унаследованные разрешения в явные разрешения этого объекта.

Выставляем необходимые права на папку, например:

Совет: старайтесь управлять правами на ресурсы только при помощи групп. Даже если доступ необходимо предоставить только одному человеку!

Теперь нажимаем OK два раза. Папка настроена для общего использования и в нашем примере доступна по сетевому пути \\fs1\Общая папка.

Шаг 4. Тюнинг файлового сервера или профессиональные советы

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

С самого начала стоит создавать общие папки в пространстве имен DFS. На это есть две основные причины:

1. При наличии или появлении нескольких файловых серверов пользователям будет удобнее находить общие папки в одном месте.
2. Администратор легко сможет создать отказоустойчивую систему при необходимости.

Теневые копии

Позволят вернуться к предыдущим версиям файлов. Это очень полезная функция позволит не только восстановить некорректно отредактированный документ, но и вернуть случайно удаленный файл или папку.

Как настроить и пользоваться данной возможностью, читайте подробнее в инструкции Как включить и настроить теневые копии.

Аудит

Аудит позволит вести протокол доступа к данным — понять, кто и когда удалил важные данные или внес в них изменения.

О том, как настроить данную возможность читайте статью Как включить аудит доступа к файлам Windows.

Анализатор соответствия рекомендациям

В диспетчер управления серверами Windows встроен инструмент для проверки конфигурации сервера — анализатор соответствия рекомендациям. Чтобы им воспользоваться переходим в диспетчере в Локальный сервер:

Находим раздел «Анализатор соответствия рекомендациям» и справа кликаем по ЗАДАЧИ — Начать проверку BPA:

Рассмотрим решения некоторых рекомендаций.

1. Для XXX должно быть задано рекомендованное значение.

Это набор однотипных рекомендаций, для выполнения которых нужно обратить внимание на описание и задать значение параметро, которое в нем указано. Например, для CachedOpenLimit в описании проблемы есть описание решения — «Задайте для CachedOpenLimit рекомендуемое значение 5». Чтобы это сделать, открываем Powershell от администратора и вводим команду:

Set-SmbServerConfiguration -CachedOpenLimit 5

* мы задаем параметру CachedOpenLimit значение 5, как это и рекомендовано анализатором.

На запрос, уверены ли мы, что хотим выполнить команду, отвечаем утвердительно.

Остальные параметры задаем аналогичными действиями.

2. Файл Srv.sys должен быть настроен на запуск по требованию.

В командной строке от имени администратора вводим:

sc config srv start= demand

3. Создание коротких имен файлов должно быть отключено.

В командной строке от имени администратора вводим:

fsutil 8dot3name set 1

Шаг 5. Настройка средств обслуживания

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

Резервное копирование

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

Мониторинг

1. Сетевую доступность сервера;
2. Свободное дисковое пространство;
3. Состояние жестких дисков.

Шаг 6. Тестирование

Тестирование состоит из 3-х основных действий:

1. Проверить журналы Windows и убедиться в отсутствие ошибок. В случае их обнаружения, необходимо устранить все проблемы.
2. Выполнить действия анализатора соответствий рекомендациям.
3. Провести живой тест работы сервиса с компьютера пользователя.

Принцип работы и отслеживание повторной синхронизации хранилища Understand and monitor storage resync

Область применения: Windows Server 2019 Applies to: Windows Server 2019

Оповещения о повторной синхронизации хранилища — это новая возможность Локальные дисковые пространства в Windows Server 2019, которая позволяет служба работоспособности вызывать ошибку при повторной синхронизации хранилища. Storage resync alerts are a new capability of Storage Spaces Direct in Windows Server 2019 that allows the Health Service to throw a fault when your storage is resyncing. Оповещение полезно при уведомлении о том, что происходит повторная синхронизация, чтобы вы не затронули больше серверов (что может привести к появлению нескольких доменов сбоя, в результате чего кластер будет отключен). The alert is useful in notifying you when resync is happening, so that you don’t accidentally take more servers down (which could cause multiple fault domains to be affected, resulting in your cluster going down).

В этом разделе приводятся общие сведения и действия для понимания и просмотра повторной синхронизации хранилища в отказоустойчивом кластере Windows Server с Локальные дисковые пространства. This topic provides background and steps to understand and see storage resync in a Windows Server failover cluster with Storage Spaces Direct.

Основные сведения о повторной синхронизации Understanding resync

Начнем с простого примера, чтобы понять, как хранилище становится несинхронизированным. Следует помнить, что такое поведение характерно для всех общих дисков (только на локальных дисках). Let’s start with a simple example to understand how storage gets out of sync. Keep in mind that any shared-nothing (local drives only) distributed storage solution exhibits this behavior. Как можно увидеть ниже, если один Серверный узел выйдет из строя, то его диски не будут обновлены до тех пор, пока не вернется в режим «в сети». это справедливо для любой архитектуры с согласованием Hyper-in. As you will see below, if one server node goes down, then its drives won’t be updated until it comes back online — this is true for any hyper-converged architecture.

Предположим, что мы хотим сохранить строку «HELLO». Suppose that we want to store the string «HELLO».

Асссуминг, что у нас есть три способа обеспечения отказоустойчивости зеркала, у нас есть три копии этой строки. Asssuming that we have three-way mirror resiliency, we have three copies of this string. Теперь, если мы временно перестали использовать сервер #1 (для маинтаненце), мы не можем получить доступ к #1 копирования. Now, if we take server #1 down temporarily (for maintanence), then we cannot access copy #1.

Предположим, что мы обновляем нашу строку с «HELLO» на «HELP!» Suppose we update our string from «HELLO» to «HELP!» в настоящее время. at this time.

После обновления строки Copy #2 и #3 будут успешно обновлены. Once we update the string, copy #2 and #3 will be successfully updated. Однако копирование #1 по-прежнему недоступно, так как сервер #1 временно отключен (для маинтаненце). However, copy #1 still cannot be accessed because server #1 is down temporarily (for maintanence).

Теперь у нас есть копия #1 с данными, которые не синхронизированы. Операционная система использует детализированное отслеживание «грязного» региона для отслеживания несинхронизированных битов. Таким образом, когда сервер #1 возвращается в режим «в сети», можно синхронизировать изменения, считывая данные из #2 копирования или #3 и перезаписав данные в #1 копирования. Now, we have copy #1 which has data that is out of sync. The operating system uses granular dirty region tracking to keep track of the bits that are out of sync. This way when server #1 comes back online, we can sync the changes by reading the data from copy #2 or #3 and overwriting the data in copy #1. Преимуществом этого подхода является то, что нам нужно только скопировать устаревшие данные вместо повторной синхронизации всех данных с сервера #2 или сервера #3. The advantages of this approach are that we only need to copy over the data that is stale, rather than resyncing all of the data from server #2 or server #3.

Таким образом, объясняется, как данные выходят из синхронизации. Но как это выглядит на высоком уровне? So, this explains how data gets out of sync. But what does this look like at a high level? Предположим, что в этом примере имеется три сервера кластера Hyper-in. Assume for this example that we have a three server hyper-converged cluster. Когда сервер #1 находится в состоянии обслуживания, вы увидите, что он не работает. When server #1 is in maintenance, you will see it as being down. При переводе сервера #1 резервной копии запускается повторная синхронизация всех его хранилищ с помощью детального отслеживания «грязного» региона (см. описание выше). When you bring server #1 back up, it will start resyncing all of its storage using the granular dirty region tracking (explained above). После синхронизации данных все серверы будут отображаться как включенные. Once the data is all back in sync, all servers will be shown as up.

Мониторинг повторной синхронизации хранилища в Windows Server 2019 How to monitor storage resync in Windows Server 2019

Теперь, когда вы понимаете, как работает повторная синхронизация хранилища, давайте посмотрим, как это видно в Windows Server 2019. Now that you understand how storage resync works, let’s look at how this shows up in Windows Server 2019. Мы добавили новую ошибку в Служба работоспособности , которая будет отображаться при повторной синхронизации хранилища. We have added a new fault to the Health Service that will show up when your storage is resyncing.

Чтобы просмотреть эту ошибку в PowerShell, выполните следующую команду: To view this fault in PowerShell, run:

Это новая ошибка в Windows Server 2019, которая появится в PowerShell, в отчете о проверке кластера и в любом другом месте, где происходит сбой. This is a new fault in Windows Server 2019, and will appear in PowerShell, in the cluster validation report, and anywhere else that builds on Health faults.

Чтобы получить более глубокое представление, можно запросить базу данных временных рядов в PowerShell следующим образом: To get a deeper view, you can query the time series database in PowerShell as follows:

Вот пример выходных данных: Here’s some example output:

В частности, центр администрирования Windows использует сбои работоспособности для задания состояния и цвета узлов кластера. Notably, Windows Admin Center uses Health faults to set the status and color of cluster nodes. Таким образом, эта новая ошибка приведет к тому, что узлы кластера будут переходить с красного (вниз) на желтый (повторная синхронизация) в зеленый (вверх), а не с красного на зеленый на панели мониторинга ХЦИ. So, this new fault will cause cluster nodes to transition from red (down) to yellow (resyncing) to green (up), instead of going straight from red to green, on the HCI Dashboard.

Показывая общий ход выполнения повторной синхронизации хранилища, можно точно определить, какой объем данных не синхронизирован, а также о том, выполняется ли пересылка системы. By showing the overall storage resync progress, you can accurately know how much data is out of sync and whether your system is making forward progress. При открытии центра администрирования Windows и переходе на панель мониторингавы увидите новое оповещение следующим образом: When you open Windows Admin Center and go to the Dashboard, you will see the new alert as follows:

Оповещение полезно при уведомлении о том, что происходит повторная синхронизация, чтобы вы не затронули больше серверов (что может привести к появлению нескольких доменов сбоя, в результате чего кластер будет отключен). The alert is useful in notifying you when resync is happening, so that you don’t accidentally take more servers down (which could cause multiple fault domains to be affected, resulting in your cluster going down).

Если перейти на страницу серверы в центре администрирования Windows, щелкнуть Инвентаризация, а затем выбрать конкретный сервер, можно получить более подробное представление о том, как эта повторная синхронизация хранилища будет просматриваться отдельно для каждого сервера. If you navigate to the Servers page in Windows Admin Center, click on Inventory, and then choose a specific server, you can get a more detailed view of how this storage resync looks on a per-server basis. Если вы перейдете на сервер и посмотрите на диаграмму хранилища , то увидите объем данных, которые необходимо исправить, в фиолетовой строке с точным числом справа. If you navigate to your server and look at the Storage chart, you will see the amount of data that needs to be repaired in a purple line with exact number right above. Это значение увеличится при отключении сервера (больше данных необходимо повторно синхронизировать) и постепенно снизится после возвращения сервера в режим «в сети» (синхронизация данных). This amount will increase when the server is down (more data needs to be resynced), and gradually decrease when the server comes back online (data is being synced). Когда объем данных, требующих восстановления, равен 0, выполняется повторная синхронизация хранилища. Теперь вы можете отключить сервер при необходимости. When the amount of data that needs to be repair is 0, your storage is done resyncing — you are now free to take a server down if you need to. Ниже приведен снимок экрана с этим интерфейсом в центре администрирования Windows. A screenshot of this experience in Windows Admin Center is shown below:

Как увидеть повторную синхронизацию хранилища в Windows Server 2016 How to see storage resync in Windows Server 2016

Как видите, это предупреждение особенно полезно для получения целостного представления о том, что происходит на уровне хранилища. As you can see, this alert is particularly helpful in getting a holistic view of what is happening at the storage layer. Он эффективно суммирует сведения, которые можно получить из командлета Get-Сторажежоб, который возвращает сведения о длительных заданиях модуля хранилища, таких как операция восстановления в дисковом пространстве. It effectively summarizes the information that you can get from the Get-StorageJob cmdlet, which returns information about long-running Storage module jobs, such as a repair operation on a storage space. Пример приведен ниже. An example is shown below:

Ниже приведен пример выходных данных: Here’s example output:

Это представление гораздо более детализировано, так как задания хранилища в списке относятся к тому, вы видите список выполняемых заданий и можете отслеживать их отдельный ход выполнения. This view is a lot more granular since the storage jobs listed are per volume, you can see the list of jobs that are running, and you can track their individual progress. Этот командлет работает как с Windows Server 2016, так и с 2019. This cmdlet works on both Windows Server 2016 and 2019.