Управление серверным хранилищем в windows server essentials

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нажимаем OK и Изменить. 

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

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

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

Supported configurations

You can deploy Storage Replica in a stretch cluster, between cluster-to-cluster, and in server-to-server configurations (see Figures 1-3).

Stretch Cluster allows configuration of computers and storage in a single cluster, where some nodes share one set of asymmetric storage and some nodes share another, then synchronously or asynchronously replicate with site awareness. This scenario can utilize Storage Spaces with shared SAS storage, SAN and iSCSI-attached LUNs. It is managed with PowerShell and the Failover Cluster Manager graphical tool, and allows for automated workload failover.

FIGURE 1: Storage replication in a stretch cluster using Storage Replica

Cluster to Cluster allows replication between two separate clusters, where one cluster synchronously or asynchronously replicates with another cluster. This scenario can utilize Storage Spaces Direct, Storage Spaces with shared SAS storage, SAN and iSCSI-attached LUNs. It is managed with Windows Admin Center and PowerShell, and requires manual intervention for failover.

FIGURE 2: Cluster-to-cluster storage replication using Storage Replica

Server to server allows synchronous and asynchronous replication between two standalone servers, using Storage Spaces with shared SAS storage, SAN and iSCSI-attached LUNs, and local drives. It is managed with Windows Admin Center and PowerShell, and requires manual intervention for failover.

FIGURE 3: Server-to-server storage replication using Storage Replica

Note

You can also configure server-to-self replication, using four separate volumes on one computer. However, this guide does not cover this scenario.

Ошибка «Не удалось подключить ресурс «Диск кластера x» к сети». для растянутого кластера

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

Если вы попытаетесь переместить диск или CSV вручную, возникает другая ошибка. Пример:

Эта проблема вызвана тем, что один или несколько неинициализированных дисков подключены к одному или нескольким узлам кластера. Для решения проблемы инициализируйте все подключенные ресурсы хранилища с помощью DiskMgmt.msc, DISKPART.EXE или командлета PowerShell Initialize-Disk.

Мы работаем над обновлением, в котором эта проблема будет полностью устранена. Если вы хотите нам помочь и у вас есть соглашение о поддержке Microsoft Premier, напишите по адресу [email protected], чтобы мы вместе могли создать запрос на применение исправления предыдущей версии.

Не поддерживается

Windows 10 (ОС на клиенте)

Дедупликация данных не поддерживается в Windows 10. Существует несколько популярных записей в блоге сообщества Windows, в которых описано, как удалить двоичные файлы из Windows Server 2016 и установить на Windows 10, но этот сценарий не был проверен как часть процесса разработки дедупликации данных. Проголосовать за этот элемент для Windows 10 vNext на Windows Server Storage UserVoice.

Поиск Windows

Поиск Windows не поддерживает дедупликацию данных. Поскольку дедупликация данных использует точки повторного анализа, которые поиск Windows не может индексировать, он пропускает все дедуплицированные файлы, исключая их из индекса. В итоге результаты поиска для дедуплицированных томов могут быть неполными. Проголосовать за этот элемент для Windows Server vNext на Windows Server Storage UserVoice.

Robocopy

Выполнение Robocopy с дедупликацией данных не рекомендуется, так как выполнение определенных команд Robocopy может привести к повреждению хранилища блоков. Хранилище блоков содержится в информационной папке системного тома. При удалении папки оптимизированные файлы (точки повторной обработки), копируемые из исходного тома, повреждаются, так как порции данных не копируются на конечный том.

Шаг 1. Развертывание Windows Server

Шаг 1,1. Установка операционной системы

первым шагом является установка Windows server на каждом сервере, который будет находиться в кластере. дисковые пространства для Direct требуется Windows Server datacenter Edition. Можно использовать вариант установки Server Core или сервер с возможностями рабочего стола.

при установке Windows server с помощью мастера установки можно выбрать между Windows сервером (который ссылается на ядро сервера) и Windows server (сервер с возможностями рабочего стола), который является аналогом полной установки, доступной в Windows Server 2012 R2. Если вы не выбираете, вы получите вариант установки Server Core. Дополнительные сведения см. в разделе Install Server Core.

шаг 1,2. Подключение на серверах

В этом руководство основное внимание уделяется варианту установки Server Core и удаленному развертыванию и управлению из отдельной системы управления, которая должна иметь:

• версия Windows Server или Windows 10 по крайней мере новые, как серверы, которыми он управляет, и с последними обновлениями.
• Сетевое подключение к управляемым им серверам
• Присоединение к тому же домену или полностью доверенному домену
• На нем должны быть установлены средства удаленного администрирования сервера (RSAT) и модули PowerShell для Hyper-V и отказоустойчивой кластеризации. средства RSAT и модули PowerShell доступны на Windows сервере и могут быть установлены без установки других компонентов. вы также можете установить средства удаленного администрирования сервера на пк, на котором выполняется управление Windows 10.

В системе управления установите отказоустойчивый кластер и средства управления Hyper-V. Это можно сделать в диспетчере сервера с помощью мастера добавления ролей и компонентов. На странице Компоненты щелкните Средства удаленного администрирования сервера и выберите средства, которые требуется установить.

Войдите в сеанс PowerShell и используйте имя сервера или IP-адрес узла, к которому хотите подключиться. После выполнения этой команды появится запрос на ввод пароля. Введите пароль администратора, указанный при настройке Windows.

Ниже приведен пример того, как сделать то же самое, что более полезно в сценариях, если это необходимо сделать более одного раза:

Совет

Если развертывание выполняется удаленно из системы управления, может возникнуть ошибка, например WinRM не может обработать запрос. чтобы устранить эту проблему, используйте Windows PowerShell, чтобы добавить каждый сервер в список надежных узлов на компьютере управления:

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

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

Чтобы очистить список, введите .

Шаг 1,3. присоединение к домену и добавление учетных записей домена

Пока вы настроили отдельные серверы с учетной записью локального администратора, .

для управления дисковые пространства Direct необходимо присоединить серверы к домену и использовать учетную запись домена домен Active Directory Services, которая входит в группу администраторов на каждом сервере.

В системе управления откройте консоль PowerShell с правами администратора. Используйте для подключения к каждому серверу и выполните следующий командлет, заменив свое имя компьютера, доменное имя и учетные данные домена:

Если ваша учетная запись администратора хранилища не является членом группы «Администраторы домена», добавьте учетную запись администратора хранилища в локальную группу администраторов на каждом узле или еще лучше, добавьте группу, используемую для администраторов хранилища. для этого можно использовать следующую команду (или написать функцию Windows PowerShell. дополнительные сведения см. в статье использование PowerShell для добавления пользователей домена в локальную группу ):

Шаг 1,4. Установка ролей и компонентов

Следующим шагом является установка ролей сервера на каждом сервере. это можно сделать с помощью Windows центра администрирования, диспетчер сервера) или PowerShell. Ниже перечислены устанавливаемые роли.

• Отказоустойчивая кластеризация
• Hyper-V
• Файловый сервер (если требуется разместить любые общие файловые ресурсы, например для согласованного развертывания);
• Мост для центра обработки данных (если вы используете RoCEv2 вместо сетевых адаптеров iWARP)
• PowerShell для кластеризации RSAT
• PowerShell для Hyper-V

Чтобы установить с помощью PowerShell, используйте командлет Install-WindowsFeature . Его можно использовать на одном сервере следующим образом:

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

What are the key features?

• Block level replication with zero data loss.
• Simple deployment and management with the creation of a replication link between servers needing only one PowerShell command.
• Virtualized guest- and host-based deployments available, which means that guests can replicate data volumes even if running in public clouds or on non-Windows virtualization platforms.
• Support for industry-leading security standards including AES-128, packet signing, and man-in-the-middle attack prevention.
• Seeded initial sync is supported, whereby a small subset of the data can be loaded from backups or older copies. Only the differing blocks are copied during the initial replication, thus shortening sync time and reducing bandwidth usage.

Так что же лучше?

	Блочная репликация СХД	Блочная репликация агентом	Физическая репликация	Логическая репликация СУБД	Репликация триггерами	CDC	Прикладная репликация
Воспроизведение источника	Побайтно	Побайтно	Побайтно	Логически	Логически	Логически	Логически
Выборочная репликация	На уровне томов	На уровне томов	На уровне файлов	На уровне таблиц и строк	На уровне таблиц и строк	На уровне таблиц и строк	На уровне таблиц и строк
Объём трафика	X	X	X/7..X/5	X/7..X/5	≤X/10	≤X/10	≤X/10
Скорость переключения	5 мин… часы	5 мин… часы	1..10 мин	1..10 мин	1..2 мин	1..2 мин	1..2 мин
Гарантия переключения	+	+	+++	+	∅	∅	∅
Доступность реплики	∅	∅	RO	R/W	R/W	R/W	R/W
Топология репликации	точка-точка	точка-точка broadcast	точка-точка broadcast каскад	точка-точка broadcast каскад встречная* p2p*	точка-точка broadcast каскад встречная* p2p* слияние	точка-точка broadcast каскад встречная* p2p* слияние	точка-точка broadcast каскад встречная* p2p* слияние
Нагрузка на источник	∅	∅	–	– –	– – –	– –	∅
Простота настройки	+ + +	+ +	+ +	+ +	–	+	– – –
Стоимость дополнительного ПО	– –	– –	–	–	∅	– – –	∅
Гетерогенные среды	∅	+	+ +	+ +	+ +	+ + +	+ + +

• Блочная репликация имеет смысл, когда других способов репликации нет; для баз данных её лучше не использовать.
• Физическая репликация хороша, когда требуется обеспечение отказоустойчивости инфраструктуры или перенос части читающих приложений на реплики.
• Логическая репликация подходит для обеспечения отказоустойчивости только в том случае, если приложение знает об этой репликации и умеет в случае аварии ждать синхронизации реплик.
• Логическая репликация идеальна для всевозможных отчётных баз.
• Репликация триггерами имеет смысл в том случае, если база сильно нагружена, а реплицировать нужно крайне ограниченное количество информации.
• Платформы CDC хороши, если у вас большое количество реплицируемых баз и/или есть необходимость сложных преобразований данных.
• Разработка прикладной репликации оправдана только в случае разработки собственной платформы или фреймворка.

Предварительные требования

• Лес служб домен Active Directory (не требуется запускать Windows Server 2016).
• два сервера, на которых работает Windows Server 2019 или Windows Server 2016, datacenter Edition. если вы используете Windows Server 2019, то можете использовать выпуск Standard, если вы нормально реплицируете только один том размером до 2 тб.
• Два набора хранилищ со следующими компонентами: SAS JBOD, SAN на основе протокола Fibre Channel, цели iSCSI и (или) локальные хранилища SCSI или SATA. Хранилище должно включать как жесткие диски, так и твердотельные накопители. Каждой набор хранилищ должен быть доступен только для одного из этих серверов (без возможности общего доступа).
• Каждый набор хранилищ должен допускать создание по меньшей мере двух виртуальных дисков: один для реплицируемых данных и один для журналов. На всех дисках данных в физическом хранилище необходимо использовать одинаковый размер секторов. На всех дисках с журналами в физическом хранилище необходимо использовать одинаковый размер секторов.
• На каждом сервере должно быть создано по меньшей мере одно подключение Ethernet/TCP для синхронной репликации, но желательно использовать RDMA.
• Правила всех задействованных брандмауэров и маршрутизаторов должны разрешать двунаправленный трафик ICMP, SMB (порт 445, а также 5445 для SMB Direct) и WS-MAN (порт 5985) между всеми узлами.
• Сеть между серверами должна иметь достаточную пропускную способность для ваших рабочих нагрузок ввода-вывода, а средняя задержка приема-передачи должна составлять 5 мс для синхронной репликации. Для асинхронной репликации не предусмотрена рекомендация по задержке.
  Если выполняется репликация между локальными серверами и виртуальными машинами Azure, необходимо создать сетевую связь между локальными серверами и виртуальными машинами Azure. Для этого воспользуйтесь , подключением VPN-шлюза типа «сеть — сеть» или установите программное обеспечение VPN на виртуальных машинах Azure, чтобы подключить их к локальной сети.
• Реплицируемое хранилище не может находиться на диске с папкой операционной системы Windows.

Важно!

В этом сценарии каждый сервер должен находиться на отдельном физическом или логическом узле. Для серверов нужно настроить обмен данными через сеть.

Многие из этих требований можно определить с помощью командлета . Это средство будет доступно, если установить реплику хранилища или средства управления репликой хранилища хотя бы на один сервер. Настраивать реплику хранилища не нужно. Для использования инструмента достаточно только установить командлет. Дополнительная информация приведена ниже.

What’s new in storage in Windows Server, version 1709

Windows Server, version 1709 is the first Windows Server release in the Semi-Annual Channel. The Semi-Annual Channel is a Software Assurance benefit and is fully supported in production for 18 months, with a new version every six months.

For more information, see Windows Server Semi-annual Channel Overview.

Storage Replica

The disaster recovery protection added by Storage Replica is now expanded to include:

• Test failover: the option to mount the destination storage is now possible through the test failover feature. You can mount a snapshot of the replicated storage on destination nodes temporarily for testing or backup purposes. For more information, see Frequently Asked Questions about Storage Replica.
• Windows Admin Center support: Support for graphical management of replication is now available in Windows Admin Center via the Server Manager tool. This includes server-to-server replication, cluster-to-cluster, as well as stretch cluster replication.

Storage Replica also contains the following improvements:

• Alters asynchronous stretch cluster behaviors so that automatic failovers now occur
• Multiple bug fixes

SMB

• SMB1 and guest authentication removal: Windows Server, version 1709 no longer installs the SMB1 client and server by default. Additionally, the ability to authenticate as a guest in SMB2 and later is off by default. For more information, review SMBv1 is not installed by default in Windows 10, version 1709 and Windows Server, version 1709.

• SMB2/SMB3 security and compatibility: Additional options for security and application compatibility were added, including the ability to disable oplocks in SMB2+ for legacy applications, as well as require signing or encryption on per-connection basis from a client. For more information, review the SMBShare PowerShell module help.

Data Deduplication

• Data Deduplication now supports ReFS: You no longer must choose between the advantages of a modern file system with ReFS and the Data Deduplication: now, you can enable Data Deduplication wherever you can enable ReFS. Increase storage efficiency by upwards of 95% with ReFS.
• DataPort API for optimized ingress/egress to deduplicated volumes: Developers can now take advantage of the knowledge Data Deduplication has about how to store data efficiently to move data between volumes, servers, and clusters efficiently.

При попытке добавить диски в асимметричный кластер с двумя узлами отображается сообщение «Не найдены диски, подходящие для дисков кластера»

При попытке подготовить кластер только с двумя узлами перед добавлением растянутой репликации для реплики хранилища предпринимается попытка добавить диски в раздел «Доступные диски» на втором сайте. Вы получили следующую ошибку:

Этого не происходит, если в кластере не менее трех узлов. Ошибка возникает из-за намеренного изменения кода в Windows Server 2016 на случай асимметричной кластеризации хранилища.

Чтобы добавить хранилище, необходимо выполнить следующую команду на узле второго сайта:

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

Прежде чем начать

• VMM требуется запускать в System Center 2016 Datacenter Edition.
• Для Hyper-V требуется Windows Server 2016 Datacenter, Server Core или Nano.
• Поддерживается только синхронная репликация. Асинхронная репликация не поддерживается.
• Вам потребуется два набора хранилища — хранилище томов или хранилище файлов. Исходные и целевые расположения должны иметь хранилище одного и того же типа (файлы или тома), но фактическое хранилище может быть смешанным. Например, с одной стороны можно создать сеть SAN Fibre Channel, а с другой — локальные дисковые пространства (с гиперконвергенцией или с разделением).
• Каждый набор хранилища должен быть доступен в каждом кластере. Хранилище кластеров не может быть общим.
• Исходные тома и тома назначения (включая тома журналов) должны иметь одинаковый размер и размер блоков. Это связано с тем, что в реплике хранилища используется блочная репликация.
• На каждом сервере хранения должно быть обеспечено подключение не ниже 1GbE, предпочтительно 10GbE, iWARP или InfiniBand.
• На каждом файловом сервере или узле кластера должны быть заданы правила брандмауэра, обеспечивающие двунаправленный трафик между всеми узлами ICMP, SMB (порт 445 плюс 5445 для SMB Direct) и WS-MAN (порт 5985).
• Вам необходимо быть членом группы «Администраторы» на каждом узле кластера.
• В настоящее время реплику хранилища можно настраивать только с использованием Windows PowerShell.
• Исходным и целевым хранилищем должен управлять один и тот же сервер VMM.
• Интеграция VMM со службой Azure Site Recovery не поддерживается.
• Настройка порядка записи и группы согласованности не поддерживаются.

Storage Replica prerequisites

• Active Directory Domain Services forest.

• Storage Spaces with SAS JBODs, Storage Spaces Direct, fibre channel SAN, shared VHDX, iSCSI Target, or local SAS/SCSI/SATA storage. SSD or faster recommended for replication log drives. Microsoft recommends that the log storage be faster than the data storage. Log volumes must never be used for other workloads.

• At least one ethernet/TCP connection on each server for synchronous replication, but preferably RDMA.

• At least 2GB of RAM and two cores per server.

• A network between servers with enough bandwidth to contain your IO write workload and an average of 5ms round trip latency or lower, for synchronous replication. Asynchronous replication does not have a latency recommendation.

• Windows Server, Datacenter Edition, or Windows Server, Standard Edition. Storage Replica running on Windows Server, Standard Edition, has the following limitations:

  • You must use Windows Server 2019 or later
  • Storage Replica replicates a single volume instead of an unlimited number of volumes.
  • Volumes can have a size of up to 2 TB instead of an unlimited size.

новые возможности хранилища в Windows Server версии 1903

в этом выпуске Windows Server добавлены следующие изменения и технологии.

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

Чтобы использовать эту версию Windows Server для оркестрации переноса, мы добавили следующие возможности:

• Перенос локальных пользователей и групп на новый сервер.
• Перенос хранилища из отказоустойчивых кластеров.
• Перенос хранилища с сервера Linux, использующего Samba.
• Более простая синхронизация перенесенных общих ресурсов в Azure с помощью компонента «Синхронизация файлов Azure».
• Перенос в новые сети, такие как Azure.

Обнаружение аномалий диска с помощью функции системной аналитики

Системная аналитика — это функция прогнозной аналитики, которая локально анализирует системные данные Windows Server и дает представление о функционировании сервера. Она поставляется с рядом встроенных возможностей, но мы добавили возможность устанавливать дополнительные возможности с помощью Windows Admin Center, начиная с обнаружения аномалий диска.

Обнаружение аномалий диска — это новая возможность, которая определяет, когда диски ведут себя иначе, чем обычно. Хотя отличия не обязательно указывают на проблемы, просмотр этих аномальных моментов может быть полезен при устранении неполадок в ваших системах.

Эта возможность также доступна для серверов под управлением Windows Server 2019.

Улучшения Windows Admin Center

Вышел новый выпуск Windows Admin Center, добавляющий новые функции в Windows Server. Дополнительные сведения см. в статье Привет, Windows Admin Center!

Asynchronous replication

See diagram for Synchronous replication, but confirm the write after step 2 – in other words, once the data has been written to the source log disk. The data is written to the destination log disk separately.

How Storage Replica changes your disk IO

On a volume that is being replicated via Storage Replica, all write activity happens to the Log disk. This data is then “destaged” to the Data disk, which thus only ever handles Because the Log disk is a log, the writes to this are sequential. Despite this, it’s recommended that you make the log disk an SSD – writes tend to slower than reads, and Windows (and applications, e.g. SQL Server, Exchange) can cache data for read operations in RAM. Write operations have to be securely written to disk, and so if the write speed of the log disk isn’t fast enough it’ll become the point of contention.

Is it safe to use now?

Probably – Microsoft has had customers running this technology on production systems since 2014. I plan on using it right now.

Want to know more?

Watch Ned Pyle’s excellent, informative, hilarious Ignite session video (where I stole the diagrams above from!). Hipsters beware…!