Windows

Windows storage server 2019 что это: Новые возможности хранилища в Windows Server

11.12.2004

Содержание

Windows Storage Server

Windows Storage Server 2016 — специальная редакция ОС Windows Server 2016, которую используют в файловых хранилищах. Эту редакцию распространяют только Embedded/IoT дистрибьюторы Майкрософт, а приобрести могут производители и сборщики систем хранения и других специализированных систем.  

В отличие от «классических» редакций Standard и Datacenter, этому продукту не нужны лицензии клиентского доступа CAL, поэтому это более экономный вариант для использования на файловых серверах хранения.

Значимые нововведения в Storage Server 2016

Удаление дублирующихся данных — дедупликация файлов

Операционная система может искать и удалять дублирующийся данные, чтобы уменьшить занимаемый на диске объём. Этот процесс называется дедупликацией. В версии 2016 Windows Storage Server удалять дублирующиеся данные можно с дисков объёмом до 64 Тб, а размер одного файла может достигать 1 Тб.

Синхронизация рабочих папок с клиентскими устройствами на Windows 10

Рабочие папки Work Folders — один из способов синхронизации рабочих файлов на разных устройствах.

Рабочие папки сконфигурированы на локальном файловом сервере, а данные в этих папках синхронизируются с другими устройствами. В Windows Storage Server 2012 синхронизация изменений между сервером и клиентским устройством происходила с задержкой до 10 минут. В версии 2016 все изменения на сервере мгновенно синхронизируются с клиентами на ОС Windows 10.

ReFS — The Resilient File System

ReFS — локальная файловая система, которорую Майкрософт представила с выходом Windows Server 2012. В Windows Storage Server 2016 на дисках с файловой системой ReFS можно хранить форматы файлов VHDX, которые используются для описания виртуальных жёстких дисков. Это увеличивает производительность при подготовке и слиянию контрольных точек. Подробнее о ReFS и формате VHDX на сайте Майкрософт.

Качество обслуживания QoS хранилища

Теперь можно использовать QoS хранилища для централизованного отслеживания производительности сквозного хранилища и создавать политики с использованием Hyper-V в Windows Storage Server 2016. Создавайте политики хранения QoS и присваивайте одному или нескольким виртуальным дискам в Hyper-V. Производительность хранилища автоматически перенастраивается в соответствии с политиками.

Подробнее о нововведениях в Windows Storage Server 2016 в анонсе продукта на TechNet.

Доступные редакции

Для приобретения доступны две редакции. Сравнение ниже.

Windows Storage Server 2016-2019 Comparison

netberg | Главная

ИНФОРМАЦИЯ

Storage Spaces в Windows Server 2012

Storage Spaces или Пространства Данных — новая функция, которая появилась в Windows Server 2012, представляет собой механизм виртуализации дисковой подсистемы, что в свою очередь обеспечивает высокую доступность и масштабируемость решений хранения данных, как для отдельного сервера, так и кластера северов. Storage Spaces позволяет объединить несколько физических дисков в один логический, упрощая администрирование и обеспечивая защиту от потерь информации.

Схематично процесс создания Storage Spaces можно представить следующим образом:

  1. Создание одного или нескольких пулов (Pools).
  2. Создание одного или нескольких виртуальных дисков (Storage Spaces).
  3. Создание одного или нескольких логических томов.

Из возможностей Storage Spaces можно отметить следующие:

  • Упорядочивание физических дисков в пулы, которые можно легко расширять. При этом логический размер пула может быть больше чем суммарный объем всех физических дисков благодаря использованию технологии thin provisioning, которая позволяет выделить столько места на виртуальном томе, сколько необходимо, а физические диски добавлять по мере необходимости без каких-либо дополнительных настроек. Причем, типы и размер дисков в одном пуле могут быть разными.
  • Обеспечения отказоустойчивости за счет использования технологий зеркалирования и хранения информации о четности по аналогии RAID1 и RAID5, а также поддержка горячего резервирования «Hot Spare».

Для организации Storage Spaces необходимо выполнить ряд требований:

  • Операционная система Windows Server 2012 или Windows 8.
  • Диски SATA или SAS, можно в массиве JBOD. На адаптерах RAID (если используются) все функции RAID должны быть отключены.

Некоторые ограничения, с которыми придется столкнуться при настройке Storage Spaces:

  • Storage Spaces не могут использоваться для загрузки операционной системы.
  • Не поддерживаются iSCSI и Fibre-chanel.

Характеристики типов обеспечения отказоустойчивости.

Простой (Simple)

  • Данные чередуются на физических дисках.
  • Увеличивается емкость диска и пропускная способность.
  • Данный тип не дает отказоустойчивости.

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

Зеркалирование (Mirror)

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

Используется технология Dirty Region Tracking (DRT) для отслеживания изменений на дисках в пуле. Когда система возобновляет работу после внеплановой остановки, DRT приводит данные на дисках в соответствие относительно дуг друга.

Контроль четности (Parity)

  • Повышение надежности по сравнению с простой (Simple) реализацией.
  • Отказоустойчивость повышается благодаря ведению журнала.
  • Необходимо минимум три диска для защиты выхода из стоя хотя бы одного диска.

Настройка Storage Spaces

Далее рассмотрим настройку Storage Spaces на примере. В качестве исходных данных, у нас есть сервер с установленной Windows Server 2012 и четыре физических диска. На одном из дисков установлена операционная система. Для обеспечения отказоустойчивости выберем тип зеркалирование на двух дисках, третий диск назначим Hot Spare.

  1. В навигационной панели Server Manager выберите File and Storage Services.
  2. Далее в панели выберите Storage Pools.
  3. В панели STORAGE POOLS выберите TASKS и затем выберите New Storage Pool.
  4. В окне Before you begin нажмите Next.
  5. В окне Specify a storage pool name and subsystem введите название пула, так же можно добавить описание. Выберите группу доступных физических дисков и нажмите Next.
  6. В окне Select physical disks for the storage pool выберете три диска для включения в storage pool, третий диск назначим в качестве Hot Spare.
  7. В окне Confirm selections проверьте правильность настроек и нажмете Create.
  8. По окончании процесса отобразиться окно View results. Нажмите Close.
  9. В панели VIRTUAL DISKS выберите TASKS, затем нажмите New Virtual Disk.
  10. В окне Before you begin нажмите Next.
  11. В окне Select the storage pool выберите нужный storage pool и нажмите Next.
  12. В окне Specify the virtual disk name введите название виртуального диска и при желании его описание и нажмите Next.
  13. В окне Select the storage layout выберете тип Mirror.
  14. Далее предлагается выбрать тип виртуального диска Thin или Fixed. При выборе Thin Provisioning пространство выделяется по мере необходимости, размер диска можно выбрать больше, чем доступно на физических дисках. При выборе Fixed размер виртуального диска остается фиксированным. Выберем тип Fixed.
  15. В окне Specify the size of the virtual disk выберете Maximum size.
  16. В окне Confirm selections проверьте правильность настроек и нажмете Create.
  17. По окончании процесса отобразиться окно View results. Нажмите Close. После создания виртуального диска он будет представлен в диспетчере устройств на равне с обычными дисками.
  18. Далее создадим новый том. Для этого в панели VIRTUAL DISKS выберете правой кнопкой нужный виртуальный диск,далее выберете меню New Volume.
  19. В окне Before you begin нажмите Next.
  20. В окне Select the server and disk выберете нужный сервер и диск и нажмите Next.
  21. В окне Specify the size of the volume выберите размер нового тома и нажмите Next.
  22. В окне Assign to a drive letter or folder назначьте букву тома и нажмите Next.
  23. В окне Select file system settings оставьте все по умолчанию.
  24. В окне Confirm selections проверьте правильность настроек и нажмете Create.
  25. По окончании процесса отобразиться окно View results. Нажмите Close.
  26. Для того, что бы убедиться, что логический том создан, в Server Manager откройте окно Volumes.

Представим ситуацию, когда один из физических дисков вышел из строя. В окне VIRTUAL DISKS напротив виртуального диска появляется восклицательный знак в желтом треугольнике.

Если в системе присутствует физический диск, отмеченный под горячую замену (Hot Spare), система помечет вышедший из строя диск как Failed и заменяет его на диск Hot Spare. Диск Hot Spare становиться частью виртуального диска, сам виртуальный диск в момент восстановления находится в статусе In Service.

Глава 9. Избыточность в Windows Server 2019 — Windows Server 2019 Полное руководство

Помножай это на два. Эту фразу я слышу постоянно когда планирую массовую раскрутку для работы. Я уверен, что вы поступаете так же. Всякий раз когда вы массово раскручиваете новую технологию, вы желаете спланировать такую раскрутку очень тщательно. Определяйте какие серверы вам нужны, где они должны быть размещены и как должна быть настроена сетевая среда для этих парней. А потом, когда всё сказано и сделано по планированию — о да, мне нужно всего этого по два, на случай если что- то сломается. Мы живём в мире постоянно работающих технологий. Падение служб неприемлемо, особенно если мы размещаем облачные или частные облачные службы. На самом деле, любое приложение или служба, от которых зависит выполнение своей работы пользователями, являются критически важными и требуют 100% времени работы, либо чертовски близко к тому. Проблема с избыточностью состоит в том, что это

быстро сказывается, да не просто делается. Возможно когда-то наступит день когда нам явится магическая кнопка Нажмите сюда, чтобы сделать ваш сервер избыточным — но это будет не сегодня {Прим. пер.: и не в нашем районе}. Нам необходимо понимать доступные нам технологии, которые предоставляют избыточность в наших системах. Эта глава расскажет нам кое-что об этих технологиях. Данная книга сосредоточена на Server 2019, применяемом на вашей площадке, поэтому те технологии, которые мы обсуждаем здесь и сейчас будут теми технологиями, которые мы сможем применять в своих локальных центрах обработки данных на всамделишных (физических или виртуальных) серверах, за которые вы несёте ответственность при их построении, настройке и сопровождении. Да, облака могут предоставить нам некие магические варианты масштабируемости и избыточности, однако это слишком просто и нам даже не нужно знать как это работает. Когда же мы используем свои собственные серверы в своих собственных стенах, как мы можем добавить некое увеличение надёжности в свои собственные системы?

В данной главе мы рассмотрим следующие темы:

Балансировка сетевой нагрузки

Очень часто, когда я слышу как люди обсуждают избыточность своих серверов, обсуждение содержит множество экземпляров слова кластер. Например, «Если мы настроим некий кластер для предоставления избыточности для этих серверов…» или «Наш основной вебсайт выполняется в кластере…». Хотя это и замечательно, что имеется некоторый вид применяемой в нашей системе эластичности, к которой имеет отношение данное обсуждение, зачастую это тот случай, когда кластеризация вовсе не вовлечена в процесс на самом деле. Когда мы углубляемся в подробности того как настроены их системы, мы обнаруживаем, что всю работу за них осуществляет NLB (Network Load Balancing, Балансировка сетевой нагрузки). Далее в этой главе мы обсудим действительную кластеризацию, но вначале я бы хотел начать с более общего подхода, которые делает множество служб избыточными. NLB распределяет обмен вашего уровня TCP/IP, что означает, что сами операционные системы сервера не полностью не имеют информации о том, что могут полагаться друг на друга, а избыточность собственно предоставляется на самом сетевом уровне. Это — NLB против кластеризации — может определённо вводить в заблуждение, так как даже сам Microsoft иногда ссылается на что- то как на кластер, хотя на самом деле применяется NLB для возможности осуществления таких соединений. Прекрасным примером является DirectAccess. Когда у вас есть два или более сервера DA соединённых в один массив, имеются документы TechNet и даже места внутри самой консоли, которые называют это кластером. Однако в действительности здесь нет отказоустойчивой кластеризации, та технология под капотом, которая осуществляет поток соединений к обоим этим узлам, в действительности Балансировка сетевой нагрузки Windows (Windows NLB, Windows Network Load Balancing).

Скорее всего вы слышали некоторые имена на рынке аппаратной балансировки нагрузок — F5, Cisco, Kemp, Barracuda. Это выделенные коробки, которые могут брать направленный к определённому имени или получателю обмен и интеллектуально расщеплять этот обмен между двумя или более серверами приложений. Хотя это обычно наиболее надёжный способ, которым вы можете устанавливать NLB, он также и наиболее затратный и делающий всё окружение более сложным. Одна из функциональностей, предлагаемых этими парнями, которую не может предоставлять Балансировка сетевой нагрузки Windows, это прекращение SSL или разгрузка SSL, как мы порой называем её. Такое специализированное приспособление способно принимать обмен вебсайта от применяющего SSL компьютера пользователя и расшифровывать пакеты прежде чем отправлять их по своему пути на соответствующий веб сервер. Таким образом сам веб сервер выполняет меньшую работу, так как ему нет необходимости тратить циклы ЦПУ на шифрование и дешифрование пакетов. Однако, сегодня мы совсем не собираемся говорить об аппаратной балансировке сетевой нагрузки, вместо этого мы обсудим те же самые возможности NLB, которые предоставляются прямо из самого Windows Server 2019. {Прим. пер.: рекомендуем также ознакомится с наш переводом Книги рецептов NGINX Дерека ДеДжонге.}

Не то же самое что карусельный DNS

На протяжении многих лет я обнаруживаю, что для некоторых людей идея Балансировки сетевой нагрузки на самом деле является карусельным (round- robin) DNS. Позвольте мне привести пример этого. Скажем, у вас имеется работающий вебсайт корпоративной сети (интранета), к которому все ваши пользователи осуществляют повседневные запросы. Это делает существенным то, что вы бы хотели предоставлять некоторую избыточность такой системе и по этой причине вы настраиваете два веб сервера, на тот случай, если один из них упадёт. Однако в случае падения одного из них вы не желаете чтобы требовались выполняемые вручную шаги по отсечению отказавшего сервера в пользу дополнительного, вы хотите чтобы это происходило автоматически. На уровне DNS это возможно путём создания двух DNS записей хоста (A), которые имеют одно и то же имя, однако указывают на два различных IP адреса. Если Server01 выполняется на 10.10.10.5, а Server02 исполняется на 10.10.10.6, вы можете создать две DNS записи, причём обе с именем INTRANET так, чтобы одна запись хоста указывала на 10.10.10.5, а вторая запись хоста на 10.10.10.6. Это предоставит карусельный DNS, однако никакую не балансировку нагрузки в действительности. То, что по существу будет происходить когда компьютер клиента будет запрашиватьINTRANET, DNS будет предоставлять им один или другой IP адрес для соединения. DNS не заботится о том, работает ли в действительности этот вебсайт, он просто выдаёт ответ с неким IP адресом. Так что вы даже могли бы настроить это для работы и оно выглядит работающим без сбоев, потому что вы можете обнаружить, что клиенты соединяются с обоими серверами, и с Server01, и с Server02, которые заблаговременно предупреждены. Если возникает событие отказа какого- либо сервера, у вас будет всё ещё достаточное число всё ещё работающих клиентов, а также большое число клиентов, которые несомненно получат сообщение Page cannot be displayed (Страница не может быть отображена), когда DNS решит отправить их к IP адресу того сервера, который в настоящий момент не работает.

Балансировка сетевой нагрузки намного умнее данного варианта. В случае падения одного из узлов в некотором массиве NLB, обмен осуществляемый на совместно используемый IP адрес будет направляться только на тот узел, который всё ещё включён. Вскоре мы получим возможность увидеть это воочию, когда мы настроим NLB в корпоративном вебсайте для наших собственных нужд.

Какую роль может применять NLB?

Балансировка сетевой нагрузки изначально разрабатывалась для приложений stateless (без состояния), другими словами, приложения, которые не требуют долговременно хранимого положения или состояния соединения. В приложении без состояния каждый выполняемый данным приложением запрос может цепляться Server01, а затем переключаться на Server02 без прерывания самого приложения. Некоторые приложения (такие как вебсайты) обрабатываются так очень хорошо, а некоторые нет.

Веб службы (IIS) определённо получают большинство преимуществ от такой избыточности, предоставляемой Балансировкой сетевых соединений. NLB достаточно просто настраивается и предоставляет полную избыточность для вебсайтов, которые вы должны исполнять на своих Windows Servers, причём без необходимости в каких- либо дополнительных затратах.

Другая роль, которая обычно взаимодействует с NLB — это роль удалённого доступа. В особенности, DirectAccess может применять встроенную в Windows Балансировку сетевой нагрузки для предоставления вам избыточной среды терминальных серверов удалённого доступа. При настройке применения балансировки нагрузки для DirectAccess, сразу не является очевидным что вы применяете встроенное в вашу операционную систему свойство NLB, так как вы настраиваете все установки балансировки нагрузки изнутри Консоли управления Удалённым доступом (Remote Access Management Console) вместо имеющейся консоли NLB. Когда вы проходите через мастер Управления Удалённым доступом для установления балансировки нагрузки, данная консоль Удалённого доступа на самом деле обращается к механизму NLB внутри данной операционной системы и выполняет её настройку, таким образом именно её алгоритмы и транспортные механизмы являются используемыми DirectAccess частями для расщепления обмена между множеством серверов.

Одна из лучших частей использования NLB состоит в том, что вы можете вносить изменения в среду без воздействия на существующие узлы. Хотите добавить новый сервер в имеющийся массив NLB? Нет проблем. Накатите его без какого- либо времени простоя. Необходимо выполнить работы по сопровождению какого- либо сервера? Даже здесь нет проблем. NLB может быть остановлен на определённом узле, на самом деле он действительно предназначен для NIC, поэтому вы можете исполнять различные режимы NLB на различных NIC на определённом сервере. Вы можете запросить NLB остановиться на определённом NIC, удаляя этот сервер из массива на это время. А что ещё лучше, если вам требуется какое- то время перед остановкой этого сервера, вы можете выполнить команду drain-stop (дренажирования, осушающего останова) вместо немедленной остановки. Это позволяет завершится обычным образов всем имеющимся в настоящий момент сеансам сетевых соединений на данном сервере. Никакие новые сеансы при этом не будут протекать через данный NIC, который вы останавливаете дренажным способом, а старые сеансы испарятся своим чередом со временем. Как только все сеансы на данном сервере завершатся, вы сможете выдернуть его и проводить на нём работы по сопровождению.

Виртуальные и выделенные адреса IP

Тот способ, которым NLB применяет IP адресацию, является важной для понимания концепцией. Прежде всего, все NIC в сервере, которые готовятся под то чтобы они стали частью массима балансировки сетевых нагрузок обязаны иметь назначпенными им статические IP адреса. NLB не работает с адресацией DHCP. В мире NLB некий статический адрес в NIC имеют название DIP (Dedicated IP Address, Выделенного IP адреса). Такие DIP являются уникальными для NIC, что очевидно означает, что каждый сервер имеет свой собственный DIP. Например, в моей среде WEB1 работает с DIP адресом 10.10.10.40, а мой сервер WEB2 имеет DIP 10.10.10.41.

Каждый сервер размещает один и тот же вебсайт, причём со своим установленным в настоящий момент соответствующим DIP. Что важно понимать, так это то, что когда между этими двумя серверами устанавливается NLB, я должен удерживать эти персональные DIP для каждой из коробок, но я буду также создавать совершенно новые IP адреса, которые будут совместно использоваться этими двумя серверами. Эти IP адреса называются VIP (Virtual IP Address, Виртуальными IP адресами). Когда мы через какое- то время будем знакомиться с настройкой NLB, я воспользуюсь для своего VIP IP адресом 10.10.10.42, который до этого момента не применялся в моеё сетевой среде. Вот краткая хема IP адресов, которые я собираюсь применять при настройке своей Балансировки сетевой нагрузки:

  • WEB1 DIP = 10.10.10.40

  • WEB2 DIP = 10.10.10.41

  • Shared VIP = 10.10.10.42

При настройке моей записи DNS для intranet.contoso.local, которая является именем моего вебсайта, я создам только единственную запись хоста (A), и она укажет на мой VIP 10.110.0.42.

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

Unicast

Здесь мы начинаем проникать в сердцевину того, как NLB распределяет пакеты по различным хостам. Так как у нас нет физического балансировщика нагрузки, который вначале принимает весь обмен, а затем принимает решение куда его отправлять, как наши серверы балансировки нагрузки принимают решение кто какой пакет потока получит?

Чтобы ответить на этот вопрос, нам необходимо вернуться слегка назад и обсудить то, как на самом деле протекает обмен внутри вашей сетевой среды. Когда вы открываете браузер на своём компьютере и посещаете HTTP://WEB1, DNS определяет, например, IP адресу значение 10.10.10.40. Когда обмен попадает на ваш коммутатор и нуждается в последующей отправки куда- то, коммутатор должен принять решение о том, куда должен проследовать обмен с 10.10.10.40. Вы можете быть знакомы с MAC адресами.

Каждый NIC имеет некий MAC адрес, и когда вы назначаете некий IP адрес для какого- то NIC, он регистрирует свой собственный MAC адрес и IP в своём собственном сетевом оборудовании. Эти MAC адреса сохраняются внутри некоторой таблицы ARP, которая является расположенной в большинстве коммутаторов, маршрутизаторов и межсетевых экранов таблицей. Когда моему серверу WEB1 был назначен IP адрес 10.10.10.40, он регистрирует свой MAC адрес, как соответствующий 10.10.10.40. Когда обмену необходимо протекать на WEB1, имеющийся коммутатор учитывает, что тому обмену, который предназначен для 10.10.10.40, следует идти на такой- то NIC с определённым MAC адресом и выстреливает его соответствующим образом.

Поэтому в мире NLB, когда вы отправляете обмен на отдельный IP адрес, который разделяется между множеством NIC, как это обрабатывается на уровне MAC? Ответ для одноадресного NLB состоит в том, что данные физические адреса MAC подменяются неким виртуальным MAC адресом, а этот MAC назначается всем NIC внутри массива NLB. Это означает, что пакеты, протекающие на этот MAC адрес должны доставляться на все такие NIC, тем самым, на все эти серверы, которые содержатся в данном массиве. Если вы думаете об этом, как о звучащем как о том, что производится большой объём работы бесполезного сетевого обмена по его перемещению внутри коммутатора, вы будете правы.

Самое лучшее в одноадресном режиме состоит в том, что в большинстве случаев он работает без необходимости выполнять некие специальные настройки в ваших коммутаторах или прочем сетевом оборудовании. Вы настраиваете эту установку NLB и она обрабатывает всё остальное. Обратной стороной одноадресного режима является то, что из- за существования одного и того же MAC адреса на всех этих узлах это может вызывать некие проблемы взаимодействия между узлами. Другими словами, сервера, в которых включён NLB будут иметь сложности во взаимодействии с IP адресами друг друга. Если вам на самом деле требуется, чтобы эти веб- серверы имели возможность общаться друг с другом непрерывно и надёжно, самое простое решение состоит в установке отдельного NIC на каждый из таких серверов и применение такого NIC для данного взаимодействия внутри массива при том, что первичные NIC остаются настроенными на NLB обмен.

Другой обратной стороной для одноадресного режима является то, что он создаёт некоторое неуправляемое заполнение коммутатора. Коммутаторы не способны изучать постоянный маршрут для виртуального адреса MAC, так как он нам необходим для доставки на все узлы в нашем массиве. Так как каждый перемещаемый в такой виртуальный MAC пакет отправляется вниз по всем проспектам коммутатора с тем, чтобы он мог достичь все свои NIC, в которых требуется эта доставка, они имеют потенциал переполнить ваши коммутаторы. Если вы беспокоитесь об этом или имеете жалобы от ваших сетевых парней о переполнении коммутаторов, вы должны захотеть проверить режимы со множеством адресов (multicast) для своего кластера NLB.

Некий альтернативный метод для управления переключением потоков unicast состоит в получении креативности при помощи VLAN в ваших коммутаторах. Если вы планируете некий NLB массив серверов и желаете гарантировать что коммутируемый обмен, вырабатываемый этим массивом не будет воздействовать на прочие системы в вашей сетевой среде, вы несомненно можете создать некую небольшую VLAN в своём коммутаторе и подключать в такую VLAN лишь свои NIC с включённым NLB. Тем самым, при возниконовении планируемого потока, он будет ударяться лишь в небольшое число портов внутри вашей VLAN, вместо того чтобы сегментировать свой путь по всему коммутатору целиком.

Multicast

Выбор multicast (многоадресного) режима для вашего NLB приносит некий положителный эффект и некую головную боль. Положительная сторона состоит в том, что он добавляет дополнительные MAC адреса для каждого NIC. Каждый участник NLB затем имеет два MAC адреса, первоначальный и ещё один, создаваемый механизмом NLB. Это позволяет коммутаторам и сетевому оборудованию более простые заания по изучению всех маршрутов и отправлять обмен их правильным получателям без переполнения пакетами потока. Чтобы выполнить это, вам необходимо сообщить своим коммутаторам какой MAC адрес должен получать этот обмен NLB, в противном случае вы вызовете переполнение коммутатора, как и в случае с одноадресным режимом. Сообщение вашим коммутаторам какие MAC нуждаются в таком подключении требует регистрации в ваших коммутаторах и создании некоторых статических записей ARP для улаживания этого. Для любой компании с выделенными сетевым парнями, как правило экспертами в оборудовании Cisco, это не вызовет проблем. Если вы не знакомы с изменением таблиц ARP и добавлением статических маршрутов, это может быть слегка неприятным выполнить их правильную настройку. В конце концов, многоадресный режим в целом лучше одноадресного, однако он может быть приносящим больше административной головной боли. Моё предпочтение всё ещё склоняется к одноадресному режиму, в особенности в малом бизнесе. Я видел его применяемым во множестве различных сетевых сред без каких- либо проблем, и к тому же следование одноадресным режимом означает, что вы можете оставить программирование коммутаторов в стороне.

Multicast IGMP

Самым лучшим, но не всегда доступным, является многоадресный режим с IGMP (Multicast with Internet Group Membership Protocol). Многоадресный IGMP действительно помогает создавать множество шлюзов коммутируемого потока, но он работает только в коммутаторах, поддерживающих отслеживание IGMP. Это означает, что такой коммутатор имеет возможность заглядывать вовнутрь пакетов с множественными адресами для определения куда он в точности должен следовать. Таким образом, когда одноадресный режим создаёт по своей природе некоторое дополнительное наполнение коммутаторов, многоадресный режим может помочь уменьшать этот объём, а IGMP может подготовить такое снижение к ещё меньшим значениям.

Тот режим NLB, который вы выбираете, во многом зависит от имеющегося у вас сетевого оборудования. Если ваши серверы имеют только один NIC, попробуйте воспользоваться многоадресным режимом, иначе вы получите проблемы внутри массива. С другой стороны, если ваши коммутаторы и маршрутизаторы не поддерживают многоадресные таблицы, у вас нет выбора — одноадресный режим будет вашей единственной возможностью для настройки Балансировки сетевой нагрузки Windows.

Настройка и балансировка нагрузки веб- сайта

Хватит болтовни, самое время настроить это для себя и попробовать. У меня имеются два веб сервера, работающие в моей лаборатории, WEB1 и WEB2. Оба они применяют IIS для размещения корпоративного вебсайта. Моя цель состоит в предоставлении их своим пользователям с единой записью DNS для взаимодействия с ними, однако заставляя весь этот обмен расщепляться между этими двумя серверами при помощи некоторой реальной балансировки нагрузки. Последуйте совместно с приводимыми ниже шагами и сделайте это возможным.

Перво- наперво нам необходимо убедиться, что WEB1 и WEB2 готовы к выполнению Балансировки сетевой нагрузки (NLB), так как оно не устанавливается по умолчанию. NLB является свойством, доступным в Windows Server 2019, и вы добавляете в точности так же как и остальные свойства, выполняя это при помощи мастера Добавления ролей и свойств (Add roles and features). Добавьте это свойство на все сервера, которые вы желаете сделать частями своего массива NLB:


Включение поддержки MAC адресов в ВМ

Помните, когда мы обсуждали одноадресный NLB, как физические MAC адреса имеющихся NIC подменялись виртуальными MAC адресами, которые применялись для взаимодействия массива NLB? Да, виртуальным машинам это не нравится. Если вы осуществляете балансировку нагрузок физических серверов с физическими NIC, вы можете пропустить этот раздел. Однако многие из вас будут исполнять веб сервера, которые являются ВМ. Будут ли они размещаться под Hyper-V, VMware или какой- либо другой технологией виртуализации, существуют дополнительные опции в настройках самих этих виртуальных машин, которые вам придётся выполнить, чтобы эта ваша ВМ успешно соглашалась с такой подменой адресации MAC.

Название таких настроек будет как- то созвучно строке Enable MAC Address Spoofing (Включение подстановки MAC адреса), хотя определённое имя этой функции может отличаться в зависимости от применяемой вами технологии виртуализации. Эта настройка должна выглядеть как простая флаговая кнопка, которую вы должны включить чтобы заставить работать подстановку MAC надлежащим образом. Убедитесь, что вы сделали это для всех виртуальных NIC, на которых вы будете применять NLB. Имейте ввиду, что эта настройка выполняется для установки каждой NIC индивидуально. Если у вас в некой ВМ множество NIC, убедитесь, что вы сделали это для всех NIC, если вы планируете их все в балансировке нагрузки.

Чтобы сделать эти изменения, вам необходимо остановить эти ВМ, поэтому я сейчас остановлю свои серверы WEB1 и WEB2. Теперь найдите необходимую флаговую кнопку и включите её. Так всё используемое мной основывается на технологии Microsoft, я, конечно же, применяю в качестве своей платформы Hyper-V для своих виртуальных машин в моей лаборатории. Внутри Hyper-V, если я кликну правой кнопкой по своему серверу WEB1 и проследую в настройки его ВМ, я могу кликнуть по своему сетевому адаптеру чтобы увидеть различные части, которые можно изменять в виртуальном NIC WEB1. И там имеется флаговая кнопка Enable spoofing of MAC addresses (Включение подстановки MAC адреса). Просто кликните по ней чтобы включить, и это все ваши настройки:

Если Enable spoofing of MAC addresses выделена серым цветом, помните, что данная машина должна быть полностью остановлена, прежде чем появится данная опция. Остановите её, затем откройте соответствующие Settings и посмотрите ещё раз. теперь эта опция должна быть доступна для выбора.

Давайте суммируем где мы находимся на текущий момент. У меня имеются два веб сервера, WEB1 и WEB2, причём они оба в настоящее время имеют один и тот же IP адрес. Каждый сервер имеет установленный IIS, который размещает отдельный вебсайт. Я включил на каждом из них подстановку MAC адреса и я только что завершил настройку свойства Балансировки сетевой нагрузки на каждом из веб серверов. Теперь у нас имеются все необходимые части для того чтобы сделать возможной настройку NLB и получения расщепления такого веб обмена между обоими серверами.

Я буду работать с WEB1 для реального осуществления настройки Балансировки сетевой нагрузки. Зарегистрируемся на нём и теперь мы получаем уведомление, что у нас имеется новый инструмент в данном перечне Средств (Tools), которые доступны в Диспетчере сервера под названием Network Load Balancing Manager (Диспетчер Балансировки сетевой нагрузки). Пройдём далее и откроем эту консоль. Когда у вас имеется открытый Диспетчер NLB, кликните правой кнопкой по Network Load Balancing Clusters (Балансировка сетевой нагрузки кластеров) и выберите New Cluster (Новый кластер), как это показано ниже на снимке экрана:

Когда вы создадите новый кластер, важно отметить, что в настоящий момент в этом кластере не имеется ни одной машины. Даже сам сервер, на котором мы выполняем эту консоль не добавился автоматически в этот кластер, мы должны не забыть поместить его вручную в данный экран. Поэтому вначале я собираюсь набрать в поле имени свой сервер WEB1 и кликнуть Connect. После осуществления этого Диспетчер NLB опросит WEB1 на предмет NIC и выдаст мне перечень доступных NIC из которых я могу потенциально настроить NLB:

Так как в этом сервере у меня имеется только один NIC, я просто оставляю его выбранным и кликаю по Next. Следующий экран предоставляет мне возможность ввода дополнительных IP адресов для WEB1, однако так как мы исполняем только один IP адрес, я оставляю этот экран как есть и снова кликаю Next.

Теперь мы перемещаемся к экрану, запрашиваещему у нас ввод IP адресов Кластера. Это уже Виртуальные IP адреса (VIP, Virtual IP Addresses), которые мы собираемся прменять для взаимодействия с таким кластером NLB. Как было постулирвано ранее, мой VIP для данного вебсайта должен быть 10.10.10.42, поэтому я кликаю по кнопке Add… и ввожу этот IPv4 адрес вместе с соответствующей маской подсети:

Ещё один клик по кнопке Next и мы можем теперь увидеть опцию, для которой мы хотим выполнить Cluster operation mode (Режим работы кластера). В зависимости от ваших настроек сетевой среды выберите, соотвественно, между Unicast, Multicast и IGMP multicast:

Следующий экран вашего мастера NLB предоставит вам настройку Port Rules (Правил порта). По умолчанию имеется единственное правило, которое сообщает NLB о необходимости выполнять балансировку нагрузки дюбого входящего обмена для любого порта, однако вы можете изменить это по своему желанию. Я не видел большого числа людей, определяющих здесь в данном поле правила для распределения по определённым получателям, однако одним отличным свойством в данном экране является возможность запрещать определённые диапазоны портов.

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

Завершите этот мастер и вы создали теперь некий NLB кластер! Однако, на данный момент времениу нас имеется заданной только информация о нашем VIP и о сервере WEB1. Мы пока не установили ничего для WEB2. Пройдите далее и кликните правой кнопкой по своему новому кластеру и выберите Add Host To Cluster (Добавить хост к кластер):

Введите имя нашего сервера WEB2 и кликните по Connect и прогуляйтесь по данному мастеру чтобы добавить второй узел NLB WEB2 в ваш кластер. Когда оба узла добавлены в этот кластер, наш массив балансировки сетевой нагрузки, или кластер, включён и готов к применению. Если вы заглянете вовнутрь имеющихся свойств NIC своих веб серверов и кликните по имеющейся там кнопке Advanced внутри свойств TCP/IP v4, вы можете увидеть, что наш новый адрес IP кластера 10.10.10.42 был добавлен к этим NIC:

Весь обмен, который предназначен для IP адреса 10.10.10.42, теперь начинает расщепляться между этими двумя узлами, однако прямо сейчас имеющиеся вебсайты, которые работают на наших серверах WEB1 и WEB2 настроены на работу только с выделенными IP адресами 10.10.10.40 и 10.10.10.41, поэтому нам необходимо проверить и отрегулировать это далее.

Настройка IIS и DNS

Всего лишь один быстрый шаг внутри IIS в каждом из наших веб серверов должен настроить данный вебсайт отвечать по соответствующему IP адресу. Теперь, когда настройка данного NLB была осуществлена и мы получили подтвержение, что наш новый VIP адрес 10.10.10.42 был добавлен в соответствующие NIC, мы можем использовать этот IP адрес для связывания вебсайта. Откройте консоль управления IIS и раскройте папку Sites так, чтобы вы могли видеть свойства своего вебсайта. Кликните правой кнопкой по имени этого сайта и выберите Edit Bindings…:

Находясь внутри Site Bindings, выберите ту связь, которую вы желаете обрабатывать и кликните кнопку Edit…. Этот корпоративный вебсайт всего лишь простой сайт HTTP, поэтому я собираюсь выбрать своё связыванеи HTTP для данного изменения. Связывание в настоящий момент настроено на 10.10.10.40 для WEB1 и на 10.10.10.41 для WEB2. Это означает, что данный вебсайт отвечает только на обмен, который поступает на данные IP адреса. Всё что мне нужно сделать, это развернуть вниз IP address для данного нового VIP, который установлен в значение 10.10.10.42. После выполнения этого изменения и нажатия на OK, данный вебсайт моментально начинает отвечать на обмен, приходящий на данный IP адрес 10.10.10.42:

Теперь мы переходим к самому последнему фрагменту всей мозаики — DNS. Помните, мы хотим чтобы пользователи имели возможность просто вводить http://intranet в своих веб- браузерах чтобы переходить на этот новый NLB вебсайт, поэтому нам необходимо настроить соответствующим образом запись Host (A) DNS. Этот процесс в точности тот же, что и для любой другой записи хост DNS, просто создайте её и укажите intranet.contoso.local на 10.10.10.42:


Проверьте это

NLB настроен? — Проверьте.

Связывание IIS изменено? — Проверьте.

Запись DNS создана? — Проверьте.

Мы готовы проверить все эти моменты. Если я открою браузер Интернет на каком- либо компьютере клиента и просмотрю http://intranet, я могу увидеть этот вебсайт:

Однако как мы можем определить, что данная балансировка нагрузки в реальности выполняется? Если я продолжу обновлять данную страницу, или выполню просмотр с другого клиента, я продолжу доступ к http://intranet и имеющийся механизм NLB от случая к случаю будет принимать решение что новый запрос следует отправлять к WEB2 вместо WEB1. Когда это произойдёт, я тогда получу вместо предыдущей такую страницу:

Как вы можете видеть, я изменил содержимое на WEB1 и WEB2 чтобы иметь возможность делать отличие между различными узлами, исключительно для целей данной проверки. Если это реальный промышленный корпоративный вебсайт, я бы хотел быть уверенным, что содержимое обоих сайтов было в точности одни и тем же, чтобы у пользователей не было возможности иметь информацию о наличии NLB — всё что им нужно знать, это то, что данный вебсайт является доступным и работающим, причём постоянно.

Ранее у нас имелось небольшое обсуждение о том, как коммутаторы хранят кэшируемую информацию ARP, что уменьшает то время, которое требуется данным коммутаторам при принятии решения куда должны протекать пакеты. Когда вы назначаете некому NIC какой- то адрес IP, имеющийся MAC адрес данного NIC связывается с соответствующим IP адресом внутри таблицы ARP в определённом фрагменте сетевого оборудования. Коммутаторы, маршрутизаторы, межсетевые экраны — все эти инструменты имеют то, что мы называем некоторой таблицей ARP, следовательно, и они имеют набор данных в этой таблице, который называется кэшем ARP.

При настройке NLB, в особенности в режиме одного адреса (unicast), MAC адрес ваших NIC замещается новым, виртуальным MAC адресом. Иногда имеющиеся коммутаторы и сетевое оборудование очень быстро захватывают данное изменение и они связывают такой новый MAC адрес с его новым IP адресом и всё работает просто великолепно. Однако я полагаю, что при настройке NLB следующее правило в целом верно: Чем умнее и более дорогостояще ваше оборудование, тем тупее оно становится при настройке NLB. Что я имею ввиду под этим, так это то, что сетевое оборудование может продолжать сохранять всю имеющуюся старую информацию MAC адресов, которая имеется в его таблице ARP, и при этом не проводить обновления для отражения имеющейся новой MAC адресации.

Как это выглядит в реальной жизни? Сетевой обмен перестаёт следовать к- или от- этих NIC. Иногда, когда вы устанавливаете NLB и она включает себя, весь сетевой обмен вдруг замерзает и останавливается к- или от- этих сетевых интерфейсов. Что необходимо делать для исправления данной ситуации? Иногда вы можете подождать её разрешения, в пределах нескольких минут, часов, а порой и дней, пока ваши коммутаторы сбросят старую информацию ARP и позволят новым MAC зарегистрировать себя здесь. Что можно сделать чтобы ускорить этот процесс? Сбросить имеющийся ARP кэш.

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

Я просто хочу обратить внимание на это событие при настройке вами NLB, только если обнаружится прекращение поступления обмена на ваш сервер. Скорее всего это вызвано тем, что кэш ARP застрял в одном или большем числе фрагментов сетевого оборудования, которое пытается направлять весь обмен к- и от- вашего сервера.

Отказоустойчивая кластеризация

Мы установили, что Балансировка сетевой нагрузки является великолепным решением для приложений, не запоминающих состояния и при этом первичным примером были вебсайты, которые вы пожелаете сделать высокодоступными. А что с остальными ролями или свойствами серверов, которые вы пожелаете сделать избыточными? Да, противоположностью для не запоминания состояний (stateless) является учёт состояния соединения (statefull), поэтому что мы можем предоставить для высокой доступности фрагментов технологий с запоминанием состояния соединения?

Отказоустойчивая кластеризация (Failover clustering) предоставляет такой уровень возможностей и может применяться в случаях, когда узлы внутри этого кластера осуществляют доступ к совместно используемым данным. Именно это является ключевым фактором для способа разработки отказоустойчивой кластеризации, что имеющееся применяемое всеми узлами кластера хранилище должно совместно использоваться и предоставлять доступ всем узлам, которым это требуется. Существует множество различных ролей и служб, которые могут получить преимущества от отказоустойчивой кластеризации, однако имеется четыре определённые технологии, которые составляют основу кластеров, исполняющихся в современных центрах обработки данных — Hyper-V, файловые службы, Exchange и SQL. Если вы работаете с любой из этих технологий, а имеется шанс что вы работаете сразу со всеми ними, вам необходимо изучить возможности высокой доступности, которые могут быть предоставлены вам инфраструктурой, использующей отказоустойчивую кластеризацию.

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

Кластеризация хостов Hyper-V

Один из самых мощных примеров отказоустойчивой кластеризации высвечивается при объединении кластеризации с Hyper-V. Существует возможность построить два или более серверов Hyper-V, соединить их все вместе в кластер и предоставить им возможность каждому размещать все имеющиеся виртуальные машины, которые хранятся в этой виртуальной среде. Предоставляя всем этим серверам хоста Hyper-V доступ к одному и тому же совместно используемому хранилищу, в котором сохраняются все виртуальные жёсткие диски, и настраивая отказоустойчивую кластеризацию между всеми этими узлами, вы можете создавать невероятно мощные и отказоустойчивые решения виртуализации для своей компании. Если сервер Hyper-V отключается, все ВМ, которые работали на этом хосте Hyper-V перенесутся на другой сервер хоста Hyper-V и раскрутят себя вместо этого там.

После минимального прерывания в обслуживании на время раскрутки этих ВМ, всё возвращается назад в рабочее состояние автоматически, без какого бы то ни было административного вмешательства. Что ещё лучше, как насчёт тех случаев, когда вам надо внести исправления или ещё как- нибудь вывести некий сервер хоста из рабочего состояния для работ по его обслуживанию? Вы можете легко заставить свои ВМ работать на другом сервере участнике данного кластера, причём они осуществят миграцию в реальном масштабе времени на этот сервер, так что будет нулевой простой, а затем вы вольны удалить данный узел для работ по его техническому обслуживанию и закончить работу на нём в свободное время до последующего его ввода в данный кластер. Раз мы применяем виртуальные машины и серверы для всех видов рабочих нагрузок, разве не было бы замечательно, если бы вы имели возможность избавить себя от любых единых точек отказа внутри такой среды виртуализации? Это именно то, что может предоставить отказоустойчивая кластеризация.

Балансировка нагрузки виртуальных машин

На практике кластер Hyper-V не только имеет возможность быстрого самостоятельного восстановления в случае отказа некого узла сервера Hyper-V, но теперь у нас также имеется некая логика интеллектуальной балансировки нагрузки, работающей совместно с такими кластерными службами. Если ваш кластер Hyper-V испытывает перегрузку виртуальными машинами, имеет смысл добавить ещё узел в этот кластер, предоставив данному кластеру больше возможностей и вычислительной мощности. Но после того как такой узел добавлен, сколько работы потребуется для сдвига части имеющихся ВМ на этот новый узел кластера?

Нисколько! Поскольку у вас имеется включённой балансировка нагрузки ВМ, веса данного кластера будут вычисляться автоматически, а рабочие нагрузки ВМ будут мигрировать в реальном масштабе времени, причём без времени простоя, на лету, с целью лучшего распределения имеющейся работы по всем узлам кластера, включая и полученный новый сервер. Балансировка нагрузки ВМ может исполняться и оцениваться по запросу, всякий раз когда вы посчитаете это необходимым, или же может быть настроена на автоматический запуск, выполняя анализ среды каждые 30 минут, автоматически принимая решение следует ли перемещать какие- либо рабочие нагрузки.

Кластеры для файловых служб

Кластеризация файловых серверов была доступна достаточно давно; это было одним из изначальных намерений, стоящим за выпуском кластеризации. Первоначально была полезна только применительно к документам и обычным файлам, другими словами, когда обладающим знаниями сотрудникам требуется повседневный доступ к файлам и папкам, а вам желателен доступ к этим файлам с высокой доступностью. На сегодняшний день такая кластеризация файловых серверов общего назначения работают в активно- пассивном сценарии. Когда несколько серверов сгруппированы сообща кластером для файлового доступа общего назначения, только один из этих узлов файловых серверов выступает активным и предоставляется в некий момент ролзователю. Только при возникновении времени его простоя данного узла его роль перекидывается прочим участникам кластера.

Горизонтальное масштабирование файлового сервера

В то время как кластеризации файлового сервера и великолепна при обычном доступе к файлам и папкам, она не была достаточно всеобъемлющей в плане обработки открытых или непрерывно изменяемых файлов. Первейшим примером таких файлов выступают файлы виртуальных жёстких дисков. К счастью, размещение рабочих нагрузок прикладных данных подобных этим именно то, для чего разработан Горизонтально масштабируемый файловый сервер (SOFS, Scale-Out File Server). Если вы планируете размещать виртуальные машины при помощи Hyper-V, вы определённо пожелаете ознакомиться с возможностями отказоустойчивой кластеризации, которые доступны для применения со службами Hyper-V. Более того, если вы собираетесь использовать кластеризованный хостинг Hyper-V, тогда вы несомненно пожелаете ознакомиться с Горизонтально масштабируемым файловым сервером как с технологией инфраструктуры для поддержки такой среды Hyper-V с высокой доступностью. Горизонтально масштабируемый файловый сервер (SOFS) помогает поддерживать отказоустойчивую кластеризацию, предоставляя файловые серверы с возможностью наличия работающими множества узлов (активный — активный), которые продолжают оставаться постоянно соединёнными друг с другом. Таким образом, что в случае отказа одного из серверов остальные немедленно доступны перекрыть возникающий зазор, причём без процесса отсекания, который приводит к времени простоя. Это важно при рассмотрении различий между хранением статических данных, таких как документы, и хранением файлов виртуальных жёстких дисков для доступа к ним со стороны ВМ. Ваши ВМ имеют возможность оставаться в рабочем состоянии в процессе выхода из строя некоторого файлового сервера при применении Горизонтально масштабируемого файлового сервера, что достаточно невероятно!

Уровни кластера

Поверх концепции отказоустойчивой кластеризации важно понимать, что имеются различные уровни, на которых может приносить вам преимущества кластеризация. Имеются два различных уровня, на которых вы можете применять построение кластеров: чтобы произвести впечатление на своих друзей по HA вы можете тот или иной подход и воспользоваться всего одним из этих уровней отказоустойчивой кластеризации, либо вы можете объединять оба.

Кластеризация уровня приложений

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

Кластеризация уровня хоста

Если кластеризация приложения является представителем микромира, то кластеризация на уровне хоста является представителем макромира. Наилучшие пример, который я могу привести, это именно тот, с которого большинство администраторов начинают в первую очередь при отказоустойчивой кластеризации, Hyper-V. Давайте допустим, что у вас имеются два физических сервера, которые оба размещают в вашей среде виртуальные машины. Вы желаете объединить в совместный кластер эти серверы с тем, чтобы все имеющиеся размещаемые на этих серверах Hyper-V ВМ имели возможность получать избыточность от этих двух физических серверов. Если отказывает сервер Hyper-V целиком, второй из них имеет возможность раскрутить те ВМ, которые исполнялись на своём вышедшем из строя первичном узле, и после минимального прерывания в обслуживании ваши ВМ, которые размещают реальные службы возвращаются в сторй и продолжают свою работу, являясь доступными для пользователей и тех приложений, в которые они проникли.

Комбинация обоих

Оба этих упомянутых выше режима кластеризации несомненно могут объединяться воедино для ещё лучшей и более выразительной истории высокой доступности. Давайте позволим этому примеру рассказать о себе самостоятельно. Если у вас имеются два сервера Hyper-V, причём каждый подготовлен для работы с последовательностями виртуальных машин. Вы применяете кластеризацию хостов между этими серверами, поэтому если физическая коробка отказывает, другая восполняет имеющийся зазор. Это само по себе великолепно, однако вы интенсивно используете SQL, и вы желаете иметь уверенность что SQL сам по себе также имеет высокую доступность. Вы можете исполнять две виртуальные машины, причём каждая из них является SQL сервером, и настроить отказоустойчивую кластеризацию прикладного уровня между этими двумя ВМ специально для имеющихся служб SQL. Таким образом, если что- то происходит с одной из виртуальных машин, вам не придётся выполнять работы по обработке отказа для резервной копии сервера Hyper-V, вместо этого ваша проблема может быть решена вторым физическим сервером. Не имелось никакой необходимости в полномасштабном приобретении Hyper-V второго физического сервера, но вы всё же применяли отказоустойчивую кластеризацию для того чтобы иметь уверенность, что SQL всегда в рабочем состоянии.Это первичный пример кластеризации поверх кластеризации, и рассуждая в таком направлении мы можем начать достаточно созидательно предоставлять различные способы, которыми мы можем применять кластеризацию в вашей сетевой среде.

Как работает отказоустойчивость?

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

Если вам требуется вырезать службы с одного узла на другой в качестве запланированного события, такого как внесение исправлений или технического обслуживания, для этого даже имеется ещё лучшая версия. Применяя процесс, имеющий название Миграции в реальном времени (Live Migration), вы имеете возможность перекидывать ответственность на второй сервер с нулевыми значениями простоя. Таким образом вы можете выводить узлы из своего кластера для их обслуживания или внесения исправлений в их безопасность, либо по какой ещё причине, причём без воздействия на пользователей или время работы системы на всём её пути. Миграция в реальном масштабе времени особенно полезна для кластеров Hyper-V, гда вам часто приходится вручную принимать решение на каком узле размещаются ваши ВМ для выполнения работы на другом узле или узлах.

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

Настройки кворума сообщают данному кластеру сколько отказов узлов может произойти перед тем как предпринять необходимые действия. При том что весь кластер знает настройку кворума, это может помочь в предоставлении ответов на подобные вопросы относительно того какой из разделов данного кластера является первичным при возникновении расщепления кластера. Во многих случаях кластеры предоставляют кворум, который полагается на некого стороннего участника, именуемого Свидетелем (witness). Как и предполагает его название, такой Свидетель отслеживает текущее состояние всего кластера и помогает в принятии решения относительно того когда и где необходимо производить восстановление после отказа. Я упоминаю об этом здесь в предверии обсуждения нами новых кластерных возможностей, встроенных в Server 2019, одна из которых состоит в неком улучшении в том плане, что такие Свидетели работают в средах небольшого размера.

Имеется большой объём информации, которую следует получить и ознакомиться с ней если вы намерены создавать достаточно крупные кластеры для настройки кворума и Свидетелей. Если вы заинтересованы в дополнительном изучении, обратитесь к https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/understand-quorum/

Настройка отказоустойчивого кластера

Мы собираемся потратить несколько минут на настройку небольшого кластера из серверов с тем, чтобы вы могли ознакомиться с инструментами управления и моментами, с которыми следует соприкасаться при осуществлении этого. К текущему моменту я откатил назад все настройки NLB на своих серверах WEB1 и WEB2, которые я устанавливал ранее, так что теперь они опять на данный момент простые веб серверы и опять же нет никакой избыточности между ними. Давайте настроим свой первый отказоустойчивый кластер и добавим оба этих сервера в кластер.

Построение серверов

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

Ещё одно замечание на протяжении данной фазы построения состоит в том, что если это возможно, то наилучшим применением при кластеризации для серверов участников, располагающихся в одном и том же кластере, будет их размещение в одной и той же Организации (OU) из Active Directory. Причина для этого двоякая: во- первых, это обеспечивает вам одни и те же GPO, применяемые к этим множествам серверов при попытке сделать их настройки по возможности идентичными.

Во- вторых, в процессе создания такого кластера будут создаваться автоматически некоторые объекты, причём они будут создаваться в AD, а когда серверы участники расположены в одной и той же OU, эти новые объекты будут создаваться также в этой OU. Очень часто для того, чтобы видеть все связанные с ними объекты в AD, всем работающим в кластере участникам необходимо быть частью одной и той же OU, а самой этой OU быть выделенной для данного кластера:


Установка свойств

Теперь, когда наши серверы включены и работают, мы хотим пройти далее и установить возможности кластеризации на каждый из них. отказоустойчивая кластеризация (Failover Clustering) является свойством внетри Windows Server, поэтому откройте мастер добавления ролей и свойств (Add roles and features) и добавьте его во все свои узлы кластера:


Запуск диспетчера отказоустойчивого кластера

Как и в случае с большинством ролей и свойств, которые могут быть установлены в Windows Serever 2019, после реализации вы обнаружите консоль управления для него внутри меню Средства (Tools) Диспетчера сервера. Теперь загляните вовнутрь WEB1, я могу видеть, что мне стал доступен для нажатия Диспетчер отказоустойчивого кластера Failover Cluster Manager. Я собираюсь открыть этот инструмент и начать работать с настройкой своего первого кластера в этом интерфейсе управления:


Исполнение проверки кластера

Внутри Диспетчера отказоустойчивого кластера (Failover Cluster Manager), вы заметите некий перечень доступных для запуска задач в разделе Управление (Management) данной консоли, рядом с самой серединой вашего экрана:

Прежде чем вы настроите сам этот кластер или добавите в него какие- либо узлы, мы должны для начала выполнить проверку наших настроек оборудования. Отказоустойчивая кластеризация является достаточно сложным набором технологий и имеется множество моментов, при которых их неверная настройка или несовместимость могут криво настроить весь кластер. Очевидно, что вы собираетесь создать кластер для надёжного резервирования, но даже простейшая ошибка в настройке ваших серверов участников может вызвать проблемы, которых будет достаточно чтобы отказ такого узла не приводил в результате к автоматическому восстановлению, что влечёт за собой провал главной цели. Чтобы все ваши «T» пересекались пунктиром с «I», имеется некоторая очень многосторонняя проверка допустимости, встроенная в ваш Диспетчер отказоустойчивого кластера. Это некий вид встроенного анализатора лучших практических приёмов. Эти проверки могут быть выполнены в любой момент, прежде чем данный кластер построен или после того как он проработал в промышленном варианте на протяжении лет. На самом деле, даже если вам придётся открыть вариант поддержки (support case) Microsoft, скорее всего, самое первое что они попросят вас, это будет как раз выполнение инструментария Проверки правильности настроек (Validate Configurations) и просьба просмотреть их вывод.

Чтобы начать наш процесс допустимости, пройдите далее и кликните по ссылке с названием Validate Configurations…. Теперь вы запускаете мастер, который позволит нам выбрать фрагменты, которые являются фрагментами вашей технологии кластера, которые мы собираемся проверить на правильность. Повторим, мы должны заставить нашу централизованную технологию управления Microsoft задуматься и осознать, что данный мастер не имеет представления и не заботится о том, что он исполняется на одном из тех серверов участников, которые я намереваюсь сделать частью общего кластера. Мы должны определить все узлы серверов, которые мы бы хотели просканировать для проверок правильности, поэтому в своём случае я собираюсь сообщить ему что я бы хотел проверить свои серверы WEB1 и WEB2:

Экран Testing Options позволяет вам выбрать радио кнопку Исполнения только выбранных мной тестов (Run only tests I select) и у вас далее будет возможность исполнять только определённые выбираемые вами тесты проверки правильности. Обычно, когда вы настраиваете совершенно новый кластер, вы захотите выполнить все эти тесты чтобы быть уверенным что всё измерено правильно. В промышленных системах, однако, вы можете выбирать ограниченное число тестов для исполнения. Это, в частности, так в отношении тестов Хранилища (Storage), так как они могут временно отключать ваш кластер при работе этих тестов, а вы не хотели бы вмешиваться в ваши промышленные службы, если вы работаете в рамках запланированного окна технического обслуживания:

Так как я настраиваю совершенно новый кластер, я собираюсь позволить исполнение всех имеющихся тестов. Поэтому я оставлю выбранной рекомендуемую опцию для исполнения всех тестов (Run all tests) и продолжить:

Когда все тесты завершатся, вы увидите окончательный вывод их результатов. Вы можете кликнуть по кнопке View Report… чтобы просмотреть дополнительные подробности всего что выполнено. Имейте в виду, что имеются три уровня прохождения/ отказов. Зелёное это хорошо, а красное плохо, однако жёлтое это что-то навроде это будет работать, но оно не является наилучшим вариантом. Например, у меня есть только один NIC в каждом из моих серверов и мой мастер распознает, что несомненно имеется проблема с резервированием во всех отношениях, мне необходимо иметь по крайней мере два. Он позволит такое падение и продолжит работу, но предупредит меня, что я мог бы выполнить улучшение, добавив второй NIC в каждый из своих узлов.

Между прочим, если вам придётся зарегистрироваться как администратору, как и мне, у вас не будет возможности открыть такой отчёт проверки правильности, так как браузер Edge не имеет полномочий для запуска под учётной записью администратора. Это прекрасная встроенная в Windows Server 2016 проверка безопасности, и позор мне делать что- либо с учётной записью администратора, однако, здорово — это же проверочная лаборатория.

Если вы обнаружите, что вы не можете просматривать по какой- то причине данный отчёт, вы сможете обнаружить этот отчёт внутри C:\Windows\Cluster\Reports, скопируйте его на свой локальный компьютер и откройте его там:

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

Запуск мастера создания кластера

Этап проверки правильности может занять некоторое время если у вас имеется множество результатов, которые подлежать исправлению прежде чем процесс будет продложен. Однако когда вы получите своб проверку валидации чистой, вы наконец готовы к построению самого кластера. Для этого кликните следующее действие, которое доступно нам в нашей консоли Диспетчера отказоустойчивого кластера — Создать кластер (Create Cluster…).

Повторим, для начала мы должны определить какие серверы мы хотим иметь частью данного нового кластера, поэтому я собираюсь снова ввести свои серверы WEB1 и WEB2. После этого у нас не так много информации для ввода о находящемся в кластере, но одно из самых ключевых мест информации содержится в экране Точки доступа для администрирования кластером (Access Point for Administering the Cluster). Именно здесь мы определяем уникальное имя, которое будет использоваться нашим кластером и совместно применяться всеми серверами участниками. Оно имеет название Объекта имени кластера (CNO, Cluster Name Object), и по завершению настройки вашего кластера вы будете видеть это имя, отображаемое в виде объекта внутри Active Directory:

После завершения данного мастера, вы теперь сможете видеть новый кластер внутри интерфейса Диспетчера отказоустойчивого кластера, а также иметь возможность углубляться в более спуцифические функции внутри этого кластера. Существует ещё одно действие для вещей таких как Configure Role…, которое будет важным для настройки реальных функций, которые данный кластер собирается выполнять, а также Add Node…, которое является вашим местом для включения дополнительных серверов участников в данный кластер в его дальнейшем пути:


Последние улучшения кластера в Windows Server

Свойство построения кластеров присутствует уже продолжительное время, но постоянно совершенствуется. В двух последних выпусках LTSC, Server 2016 и Server 2019, были внесены некие крупные изменения и добавления в построение отказоутсойчивых кластеров. Некоторые из этих изменений, которые мы будем обсуждать, первоначально были представлены в 2016, а следовательно они не являются совершенно новыми, но они всё ещё значимы для того способа, которым мы обрабатываем кластеры в Server 2019, а следовательно они также упоминаются здесь.

Истинные кластеры из двух узлов с USB свидетельством

При настройке кворума для отказоустойчивого кластера, вплоть до Server 2019, кластер из трёх узлов требовал три сервера, так как Свидетелю для кластера требовалось располагаться в некого вида совместном ресурсе свидетельства, обычно в обособленном файловом сервере.

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

Повышенная безопасность для кластеров

В Windows Server 2019 було выполнено значительное число улучшений для построения отказоустойчивых кластеров. Предыдущие версии для аутентификации обмена внутри кластера полагались на NTLM (New Technology LAN Manager), однако большое число компаний активно предпринимают шаги по отключению применения NTLM (по крайней мере ранних версий) внутри своих сетевых сред. Отказоустойчивое построение кластеров теперь может выполнять взаимодействие внутри кластера с применением Kerberos и сертификатов для удостоверения такого сетевого обмена, что устраняет потребность в NTLM.

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

Кластеризация множества площадок

Могу ли я настраивать отказоустойчивую кластеризацию по подсетям? Иными словами, если у меня имеется первичный центр обработки данных, а я также арендую пространство в CoLo по мере развития, либо у меня имеется другой центр обработки данных в моей стране существуют ли возможности для меня настроить кластеризацию между узлами, которые физически разделены? Здесь имеется быстрый и простой ответ: да, отказоустойчивой кластеризации всё равно! В точности также, как если бы эти серверные узлы располагались прямо рядом друг с другом, кластеризация может получать преимущества от множества площадок, каждая из которых размещает свои собственные узлы кластера, и перемещать службы взад и вперёд по этим площадкам.

Кластеризация по доменам или рабочим группам

Исторически у нас имелась единственная возможность установления отказоустойчивой кластеризации между узлами, которые были объединены в один и тот же домен. Windows Server 2016 привнёс возможность выйти за рамки этого ограничения, и мы можем даже строить кластер без Active Directory замешенного во что бы то ни было. В Server 2016 и Server 2019 вы можете, конечно, всё ещё создавать кластеры, в которых все узлы присоединены к одному и тому же домену, и мы ожидаем, что это всё ещё будет верным для большинства имеющихся установок. Однако, если у вас имеются серверы, которые присоединены к различным доменам, вы можете сейчас устанавливать кластеризацию между такими узлами, более того, серверы- участники в некотором кластере могут теперь быть членами рабочей группы и им даже совсем не нужно присоединяться к какому- нибудь домену.

Хотя это и расширяет имеющиеся возможности отказоустойчивой кластеризации, это также приводит к паре ограничений. При применении многодоменной кластеризации или кластеризации с рабочей группой, вы будете ограничены исключительно применением в качестве интерфейса PowerShell. Если вы применяете для взаимодействия со своими кластерами один из инструментов GUI, вам необходимо задуматься над этим. Вам также будет необходимо создавать локальные учётные записи пользователей, которые могут применяться кластеризацией и предоставлять их каждому из узлов этого кластера, а эти учётные записи пользователей должны иметь права администраторов для данных серверов.

Междоменная миграция кластеров

Хотя установка кластеризации для множества доменов и была возможна на протяжении ряда лет, миграция кластеров с одного домена AD в другой не являлась неким вариантом. Начиная с Server 2019 это изменилось. При построении кластеров со множеством доменов у нас имеется большая гибкость, которая включает и миграцию кластеров между такими доменами. Данная возможность поможет администраторам продвигать проекты приобретения компаний и консолидации доменов.

Раскрутка обновлений операционной системы кластера

Эта новая возможность, предоставляемая нам в 2016, имеет слегка странное название, но на самом деле очень крутая функция. Это нечто разработанное для того чтобы помочь тем из нас, кто применял отказоустойчивую кластеризацию для того чтобы улучшать своё окружение. Если вы работаете с кластером в настоящее время, и этот кластер является Windows Server 2012 R2, это определённо то, что вы ищете. Круговое обновление операционной системы кластера (Cluster Operating System Rolling Upgrade) делает для вас возможным обновление операционных системы ваших узлов кластера с Server 2012 R2 до Server 2016, а затем и на Server 2019, причём без простоя. Больше нет необходимости останавливать какую- либо из служб в ваших рабочих нагрузках Hyper-V или Горизонтально масштабируемых файловых серверов, которые применяют кластеризацию, вы просто применяете такой процесс кругового обновления и в конце него все ваши узлы кластера работают с новой Windows Server, причём их кластер всё ещё активен и даже никто не знает что же произошло. Конечно, кроме вас.

Это значительно отличается от предыдущего процесса обновления, при котором чтобы перенести ваш кластер на Server 2012 R2, требовалось отключать весь кластер, вводить новые узлы под управлением 2012 R2 и затем повторно устанавливать весь кластер. Это сопровождалось большим временем простоя и значительной головной болью чтобы получить уверенность что всё прошло гладко по возможности.

Хитрость, которая делает возможной такое бесшовное обновление состоит в том, что сам по себе кластер продолжает работать под функциональным уровнем (FL, functional level) 2012 R2 пока вы не выполните команду для его перескока к функциональному уровню Server 2016. Пока вы не выполните эту команду, кластеризация работает под самым старым FL, даже на имеющихся новых узлах, которые вы ввели под управлением операционной системы Server 2016. по мере обновления ваших узлов по одному за раз, все остальные узлы, которые всё ещё активны в остающемся в рабочем состоянии кластере и продолжают обслуживать своих пользователей и приложения, так что все системы работают как обычно с точки зрения рабочих нагрузок как для серверов 2012 R2, однако выполняя это на функциональном уровне 2012 R2. Это называется смешанным режимом. Он позволяет вам снимать даже самую последнюю коробку 2012 R2, изменить её на 2016, а потом повторно ввести её, причём никто не будет знать об этом. Затем, когда все обновления ОС будут завершены, исполняется команда PowerShell Update-ClusterFunctionalLevel для перескока на следующий уровень функционирования и вы получаете кластер Windows Server 2016, который бесшовно обновился с нулевым временем простоя.

Эластичность виртуальной машины

Как вы можете успешно подразумевать из его названия, Эластичность виртуальной машины (Virtual Machine Resiliency является улучшением) в кластеризации, которая предоставляет определённые преимущества кластерам серверов Hyper-V. Во времена кластеризации Server 2012 R2 не было чем- то необычным иметь некоторые проблемы взаимодействия внутри массива или внутри кластера. Это иногда выглядело как отказ перехода, что означало, что кластер полагал, что некий узел перешёл в автономный режим, в то время, как он когда этого на самом деле не было, а также приводило к отказу, который иногда вызывал большее время простоя, чем если бы шаблоны распознавания для реального отказа просто бы оказывались слегка лучшими. Хотя для большей части кластеризации и отказоустойчивости узлов кластера это работало успешно, нет предела для совершенства. Это именно то, чему посвящена Эластичность виртуальной машины. Теперь вы можете настраивать варианты для эластичности, предоставляя возможность более конкретного определения того, какого именно поведения должны придерживаться ваши узлы в процессе отказов узла кластера. Вы можете определять такие вещи, как Уровень эластичности (Resiliency Level), который сообщает данному кластеру как ему обрабатывать отказы. Вы также можете установить свой собственный период эластичности (Resiliency Period), промежуток времени, в течение которого эти ВМ могут работать в изолированном состоянии.

Другое изменение состоит в том, что неработоспособные узлы кластера теперь помещаются в некий карантин на определяемое администратором время. Им теперь не разрешается присоединяться назад в кластер пока они не определены как жизнеспособные и отбывшие свой срок ожидания, что предотвращает ситуации такие как узел, который застрял на цикле перезагрузки неосмотрительно подключается назад в данный кластер и вызывает непрерывные проблемы своими периодическими падениями и подъёмами.

Реплика хранения (SR)

Реплика хранения (SR, Storage Replica) является новым способом синхронизации данных между серверами. Она является технологией репликации данных, которая предоставляет возможность репликации данных между серверами на блочном уровне, даже между различными физическими площадками. Реплики хранения сами по себе являются новой формой резервирования в Windows Server 2016, которую мы ранее не наблюдали в своём мире Microsoft; в прошлом нам приходилось полагаться на инструменты сторонних производителей для такого вида возможностей. Реплика хранения также важна для обсуждения прямо на задах отказоустойчивой кластеризации, потому что SR является секретным соусом, который делает возможным проведение отказоустойчивой кластеризации для множественных площадок. Когда у вас имеется потребность размещать узлы кластера во множестве различных физических мест, вам необходим способ для того, чтобы быть уверенным что все данные, используемые даными узлами кластера непрерывно синхронизуются с тем, чтобы отказоустойчивость действительно была возможной. Такой поток данных предоставляется репликой хранения.

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

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

В Windows Server 2019 теперь обновлён тот момент, что SR теперь доступен внутри Server 2019 редакции Standard! (Изначально он требовал Datacenter, что было запретительным для ряда реализаций.) Администрирование SR теперь доступно изнутри нового WAC (Windows Admin Center, Центра администрирования Windows).

{Прим. пер.: Существует три различных варианта которые вы можете выбрать для осуществления Реплики хранения, вот краткое изложение каждой из них чтобы вы могли определить что будет работать в вашей среде, более подробное изложение см. в Реализация Реплик хранения в нашем переводе Курса подготовки к экзамену 70-740, вышедшей в январе 2017 книги Крейга Заккера.}

S2D (Storage Spaces Direct)

S2D является кластерной технологией, но я привожу её именно здесь, обособленно от общего построения отказоустойчивых кластеров, так как S2D составляет центральный компонент SDDC (software-defined data center, Программно- управляемого центра обработки данных), а за последние несколько лет так много внимания уделялось улучшениям, что он на самом деле достоин собственной категории.

В своей сердцевине S2D являетс неким способом построения чрезвычайно эффективной и надёжной централизованной, основанной на сетевой среде платформы хранения, причём целиком построенной на Windows Server. При обслуживании в точности тех же самых общих целей (файлового хранения), что и традиционные устройства NAS или SAN, S2D применяет совершенно иной подход, при котором он не требует некого специализированного оборудования, ни каких бы то ни было особых кабелей или подключений между имеющимися узлами в своём кластере S2D.

Всё что вам требуется для построения S2D, это Windows Server; чем быстрее, тем лучше, но они могут быть обычными, повседневными серверами. Эти серверы должны соединяться посредством сетевой среды, но здесь нет никаких особых требований; они просто все вместе подключены к некой сетевой среде, в точности как все прочие серверы в вашем окружении. После того как у вас имеются запущенными серверы, вы можете воспользоваться технологиями построения кластера или новым WAC для соединения этих серверов воедино в массивы S2D.

S2D выступает частью общей истории Гиперконвергентной инфраструктуры (HCI, Hyper-Converged Infrastructure) и является великолепным способом предоставления чрезвычайно быстрого и защищённого хранилища для чего угодно, а в особенности для рабочих нагрузок подобных кластерам серверов Hyper-V. Как вы уже знаете, при построении кластера серверов Hyper-V его узлам необходим доступ к совместному хранилищу в котором будут располагаться файлы жёстких дисков виртуальных машин. S2D является наилучшим способом такого централизованного хранилища.

S2D берёт имеющиеся у серверов узлов вашего кластера S2D жёсткие диски и сочетает всё их пространство воедино в программно- определяемые пулы хранения. Такие пулы хранения настраиваются с возможностями кэширования и даже со встроенным равнодушием к отказам. Очевидно что вы не желаете останова отдельного узла S2D или даже отдельного жёсткого диска, вызывающих икоту вашего решения S2D, и Microsoft, естественно, не хочет чтобы такое происходило. Поэтому когда вы группируете серверы и все их жёсткие диски воедино в такие большие пулы хранения S2D, они автоматически настраиваются с избыточностью по всем таким дискам с тем чтобы при отключении отдельных компонентов не приводило в результате к утрате данных или даже к замедлению системы.

S2D является наилучшей платформой хранения как для SOFS, так и для кластеров Hyper-V.

Хотя S2D на основе Server 2016 настраивался в основном через PowerShell (что к сожалению означает, что очень многие администраторы даже и не попробовали её пока), Windows Server 2019 привнёс нам новый набор инструментов WAC, а WAC теперь содержит встроенные параметры для настройки некой среды S2D:

S2D является одной из тех технологий, которая гарантирует свою собственную книгу, однако те кто ищут способа опробовать её или начать работать с этой поразительной технологией долны начать с https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spacesdirect-overview.

{Прим. ещё одной ложкой дёгтя является требование наличия лицензии Datacenter. Тем для кого это является существенным денежным препятствием в освоении данной технологии, рекомедуем рассмотреть возможность применения Ceph в тех же самых серверах узлов. Советуем свой перевод 2 издания Полного руководства Ceph Ника Фиска для знакомства с этой технологией, имеющей возможность установки из кода с открытым исходным кодом. Также готовы предоставить вам услуги по консалтингу, настройке и сопровождению обеих SDDC технологий хранения.}

Новое в 2019 сервере

Для тех, кто уже знаком с основными понятиями S2D и кто желает узнать что же нового или отличного имеется в особенностях Server 2019, вот некоторые улучшения, которые привнесены самой новой версией обсуждаемой операционной системы:

  • Улучшенное применение томов ReFS (File System): теперь у нас имеются функции дедупликации и сжатия располагающихся в S2D томов ReFS.

  • Свидетельство USB: Мы уже обсуждали его кратко, применительно к кластеру S2D использование Свидетельства делает возможным наличие только двух узлов, а вы теперь можете применять некий ключ USB подключённым в часть сетевого оборудования, вместо того чтобы запускать для целей свидетельства третий узел.

  • WAC: WAC теперь содержит инструменты и функциональность для определения и упралвения кластерами S2D. Это упрощает адаптацию того народа, который не переполнен знакомством с PowerShell.

  • Улучшенная ёмкость: Мы теперь имеем возможность размещения в кластере Петабайтов.

  • Улучшенная скорость: Хотя S2D и была достаточно быстрой начиная с самой первой версии, в Server 2019 у нас имеются некие действенные улучшения. На конференции Ignate последнего года microsoft выставил некий кластер S2D из 8 узлов, который имел возможность достигать 13 000 000 IOPS. ХМ!

Избыточность является критически важным компонентом для того способа, которым мы планируем строить серверную инфраструктуру в наши дни. Windows Server 2019 имеет некоторые мощные возможности построения прямо внутри себя, которые вы можете применять в ваших собственных средах, причем уже сегодня! Я надеюсь, что набрав дополнительную информацию как о Балансировке сетевых нагрузок, так и об отказоустойчивой кластеризации, вы получите возможности расширения своей организации применяя эти методы и расширяя пределы бесперебойной работы ваших служб. На мой взгяд, если и имеется какой- либо путь продолжения данной главы, так это начать построение вашего собственного HCI с применением S2D {Ceph} и отказоустойчивой кластеризации для того чтобы создавать собственную элластичность в вашей инфраструктуре Hyper-V. Гиперконвергентность буквально изменит способ вашей работы и предоставит вам некий душевный покой, который вы даже не могли себе представить возможным в некотором мире, имеющим цель работы в течение 99.999% времени. В своей следующей главе мы рассмотрим PowerShell.

  1. Какая из технологий лучше подходит для превращения вашего веб сервера в более устойчивый — Балансировка сетевой нагрузки или Построение отказоустойчивого кластера?

  2. Что означают сокращения DIP и VIP в Балансировке сетевой нагрузки?

  3. Перечислите три режима Баланисровки сетевой нагрузки.

  4. Является ли Балансировка сетевой нагрузки в Windows Server 2019 ролью или свойтсвом?

  5. Какие роли наиболее часто применяются совместно с построением отказоустойчивого кластера?

  6. Какой вид небольшого устройства теперь может применяться в качестве Свидетельства некого кворума (совершенно нового для Server 2019)?

  7. Истина или ложь — Storage Spaces Direct требуют применения жёстких дисков SSD.

IT Pro: Обзор Storage Spaces Direct

В Windows Server 2016 была впервые добавлена новая возможность организации дискового пространства для много-узловых отказоустойчивых систем: Storage Spaces Direct. Пришло время познакомиться с технологией поближе.

Storage Spaces Direct использует стандартные серверы с локально подключенными накопителями для создания высоко доступного, легко масштабируемого программно-определенного хранилища вместо традиционных массивов SAN и NAS. Такая конвергентная (Converged) или гипер-конвергентная (Hyper-converged) архитектура радикальным образом упрощает приобретение и развертывание решений; в то же время такие возможности как кэширование, многоуровневое хранилище и очищающее кодирование, вместе с новейшим оборудованием, таким как сеть RDMA и накопители NVMe обеспечивают непревзойденные эффективность и производительность. 

Storage Spaces Direct входит в состав Windows Server 2016 и Windows Server 2019 в редакции Datacenter.

Опции развертывания.

Storage Spaces Direct разработан для двух независимых опций развертывания:

Конвергентное (Converged) решение.

Конвергентное (Converged) решение – хранилище и вычислительные мощности разнесены в отдельные кластеры. Опция конвергентного развертывания, также известного как «разделенное», предоставляет уровень Scale-out File Server (SoFS) поверх уровня Storage Spaces Direct, для предоставления подключенного к сети хранилища (NAS) через общие ресурсы SMB3. Это позволяет масштабировать вычислительные/рабочие нагрузки независимо от кластера хранилища. В основном подобные решения предназначены для высоко масштабируемых развертываний таких как инфраструктура Hyper-V в качестве сервиса (IaaS) для провайдеров услуг и корпоративных окружений.

Гипер-конвергентное (Hyper-Converged) решение.

Гипер-конвергентное (Hyper-Converged) решение – один кластер для вычисления и хранилища. Опция гипер-конвергентного развертывания запускает виртуальные машины Hyper-V или базы данных SQL напрямую на узлах, которые предоставляют хранилище, сохраняя файлы на локальных томах. Это устраняет необходимость настраивать доступы и права файлового сервера, а также сокращает стоимость для клиентов от малого до среднего бизнеса или для развертываний в удаленных офисах и филиалах. 

Принцип работы Storage Spaces Direct.

Storage Spaces Direct – это развитие Storage Spaces, впервые появившегося в Windows Server 2012. Он усиливает множество компонентов Windows Server, таких как отказоустойчивую кластеризацию (Failover Clustering), файловую систему Cluster Shared Volume (CSV), Server Message Block 3 (SMB3) и конечно же Storage Spaces. Также Storage Spaces Direct представляет новую технологию, известную как программная шина хранилища (Software Storage Bus).

Сетевое оборудование (Networking Hardware). Storage Spaces Direct использует SMB3, в том числе SMB Direct и SMB Multichannel over Ethernet для коммуникаций между серверами. Рекомендуется использовать 10+ GbE с удаленным доступом к памяти (RDMA), iWARP или RoCE.

Оборудование хранилища (Storage Hardware). От 2 до 16 серверов с локально подключенными накопителями SATA, SAS или NVMe. Каждый сервер должен иметь как минимум 2 твердотельных накопителя (SSD) и как минимум 4 дополнительных накопителя. Настоятельно рекомендуется использовать оборудование от партнеров поддерживающих данную технологию.

Отказоустойчивая кластеризация (Failover Clustering). Встроенный компонент кластеризации Windows Server используется для объединения серверов.

Программная шина хранилища (Software Storage Bus). Программная шина хранилища — это новинка в Storage Spaces Direct. Она объединяет кластер и связывает программно-определенное хранилище таким образом, чтобы все серверы могли видеть все локальные накопители каждого из серверов. Данная технология позиционируется в качестве замены для более дорогих и строгих решений общего хранилища на базе Faber Channel или SAS.

Кэш уровня шины хранилища (Storage Bus Layer Cache). Программная шина хранилища связывает наиболее быстрые, из представленных накопителей (такие как SSD) c более медленными (такими как HDD), для предоставления на стороне сервера кэширования чтения/записи которое увеличивает ввод/вывод и ускоряет пропускную способность.

Пул хранилища (Storage Pool). Коллекция накопителей, которые формируют базу Storage Spaces называется пулом хранилища. Пул хранилища (Storage Pool) автоматически создается и все подходящие накопители автоматически обнаруживаются и добавляются в него. Настоятельно рекомендуется использовать один пул на кластер с параметрами по умолчанию.

Storage Spaces. Storage Spaces предоставляет механизм обработки отказов виртуальных дисков при помощи зеркалирования, очищающего кодирования (Erase Coding) или обоих сразу. Storage Spaces можно представить как распределенный программно-определенный RAID использующий накопители в пуле. В Storage Spaces Direct виртуальные диски обычно используют устойчивость к одновременному выходу из строя 2 накопителей или серверов (то есть тройное зеркалирование, в котором каждая копия данных находится на разных серверах). Также доступны отказоустойчивость на уровне шасси (Chassis) и стоек (Rack).

Resilient File System (ReFS). ReFS – это основная файловая система предназначенная и разработанная специально для виртуализации. Она включает в себя существенное ускорение операций VHDX, таких как создание, расширение и объединение контрольных точек, встроенную проверку контрольных сумм для обнаружения и исправления ошибок на битовом уровне. Также ReFS представляет разбиение на уровни в реальном времени, которое перемешивает данные между так называемыми «горячим» и «холодным» уровнями хранилища в зависимости от использования.

Cluster Shared Volumes (CSV). Файловая система CSV объединяет все тома в единое пространство имен доступное всем серверам таким образом, что каждый сервер видит каждый том, как будто он смонтирован локально.

Scale-Out File Server (SOFS). Это финальный уровень, он является обязательным при развертывании конвергентного решения. Он предоставляет удаленный доступ к файлам при помощи протокола доступа SMB3 для клиентов, таких как другие кластеры с Hyper-V. Эффективно переключая Storage Spaces Direct в Network Attached Storage (NAS).

PS> Я начал готовить веб-касты по технологии Storage Spaces Direct больше года назад еще на базе Windows Server 2016, несколько раз рассказывал о технологии на вебинарах и вот теперь, уже на базе Windows Server 2019 процесс записи сдвинулся с мертвой точки – самое ближайшее время опубликую первый веб-каст: «Развертывание Storage Spaces Direct в Windows Server 2019».

Стандартная лицензия Microsoft Windows Server 2019

Почему стандартная версия?

• Усовершенствования основных функций Windows Server.
• Предоставьте разработчикам возможность создавать собственные облачные приложения и модернизировать традиционные приложения с помощью контейнеров и микросервисов.
• Повышение безопасности и снижение бизнес-рисков с помощью нескольких уровней защиты, встроенных в операционную систему.

Стандартная версия Основные характеристики:

• Основные функциональные возможности Windows Server.
• Гибридная интеграция.
• До 2 операционных сред/контейнеров Hyper-V.
• Неограниченное количество контейнеров Windows Server.
• Служба защиты узла.
• Реплика хранилища одного тома объемом до 2 ТБ.

Datacenter и Standard Edition Лицензирование по количеству ядер

Редакции Windows Server 2019 Datacenter и Standard лицензируются по количеству физических ядер. Лицензии продаются упаковками по 2 и по 16 штук.

Полный набор функций в Microsoft Server 2019*

 

Уникальные гибридные возможности с Azure

Расширьте свой центр обработки данных до Azure, чтобы максимизировать существующие инвестиции и получить новые гибридные возможности.Переход к облаку — это путешествие, и часто используется гибридный подход, который сочетает в себе локальную и облачную среды. Благодаря своим гибридным облачным возможностям Microsoft использует ориентированный на будущее долгосрочный подход — именно поэтому мы видим, что Microsoft будет играть центральную роль в облачных стратегиях в обозримом будущем. С Windows Server 2019 вы сможете легко интегрировать полный набор служб Azure, таких как Azure Backup, Azure File Sync, аварийное восстановление и многое другое, без нарушения работы ваших приложений и инфраструктуры.

Полностью поддерживает:

• Служба миграции хранилища:  Помогает проводить инвентаризацию и перенос данных, безопасности и конфигураций из устаревших систем в Windows Server 2019 и/или Azure.
• Синхронизация файловых серверов с Azure: Централизуйте файловые ресурсы вашей организации в Azure Files, сохраняя при этом гибкость, производительность и совместимость локального файлового сервера.
• System Insights:  Возможности локальной прогнозной аналитики, встроенные в Windows Server.Эти возможности прогнозирования, каждая из которых опирается на модель машинного обучения, локально анализируют системные данные Windows Server, чтобы обеспечить высокоточные прогнозы, помогающие снизить эксплуатационные расходы, связанные с реактивным управлением экземплярами Windows Server.
• Сетевой адаптер Azure:  Легко подключается к виртуальным сетям Azure. Центр администрирования Windows выполняет сложную работу по настройке VPN для нового сетевого адаптера, который будет подключать Windows Server 2019 к VPN виртуальной сети Azure «точка-сеть».
• Расширенная проверка подлинности Azure AD:  Windows Server 2019 может присоединиться к Azure Active Directory (Azure AD), что позволяет использовать новые сценарии, в которых учетную запись компьютера можно использовать для проверки подлинности в облаке.
• Защита ВМ:  Реплицирует рабочие нагрузки, выполняемые на физических и виртуальных машинах (ВМ), с основного сайта на дополнительный.

Беспрецедентная гиперконвергентная инфраструктура
Развивайте инфраструктуру центра обработки данных для повышения эффективности и безопасности.HCI — одна из последних тенденций в серверной индустрии. По данным IDC, в 2016 году рынок гиперконвергентных сред вырос на 64 %, и Gartner прогнозирует, что к 2019 году рынок достигнет 5 миллиардов долларов. — производительность, рентабельность, легко масштабируемая виртуализация. Корпорация Майкрософт сотрудничает с ведущими в отрасли поставщиками оборудования, чтобы предоставить доступное, но чрезвычайно надежное гиперконвергентное решение с проверенной конструкцией.В Windows Server 2019 Microsoft опирается на эту платформу, добавляя масштабируемость, производительность и надежность, а также возможность управления развертываниями гиперконвергентной инфраструктуры для упрощения управления и повседневных действий.

Полная поддержка:
• Единое управление:  Windows Admin Center — это элегантный интерфейс удаленного управления гиперконвергентной инфраструктурой на основе браузера, который включает программно определяемую настройку сети и мониторинг.
• Дисковые пространства:  Защитите свои данные от сбоев дисков и со временем увеличивайте объем хранилища, добавляя диски на свои серверы.
• Enhanced Storage Spaces Direct (S2D): . Создание программно-определяемого хранилища с использованием стандартных отраслевых серверов с локальным хранилищем, которое может масштабироваться до 1 ПБ на пул хранения в Windows Server 2016 и 4 ПБ на пул хранения и 64 ТБ на том в Windows Server 2019.
• Зеркальное ускорение четности:  Позволяет создавать тома, которые являются частично зеркальным и частично четным для двукратного повышения производительности при прямом развертывании дисковых пространств. Записывает землю сначала в зеркальной части и постепенно перемещается в часть четности.
• Ускоренный контроль четности вложенного зеркала: Позволяет двухузловым кластерам на границе выдерживать множественные одновременные сбои.
• Память класса хранения:  Поддержка нового поколения серверного оборудования, включая память класса хранения, что значительно повышает производительность серверных приложений.
• USB-накопитель (в качестве свидетеля кластера):  Поддержка USB-накопителя в качестве свидетеля кластера позволяет развертывать настоящие гиперконвергентные инфраструктуры с двумя узлами без дополнительных зависимостей.
• Реплика хранилища: . Обеспечивает независимую от хранилища репликацию на уровне блоков, а также асинхронную и синхронную репликацию между серверами для аварийного восстановления и позволяет растягивать отказоустойчивый кластер для обеспечения высокой доступности.
• Качество обслуживания хранилища (QoS):  Использует политики для определения и мониторинга минимальных и максимальных значений ввода/вывода хранилища для виртуальных машин, чтобы обеспечить согласованную производительность всех виртуальных машин.
• Дедупликация данных:  Обеспечивает экономию объема до 90 % за счет однократного сохранения дубликатов файлов на томе с использованием логических указателей. В Windows Server 2019 добавлена ​​поддержка дедупликации с томами ReFS.
• Дедупликация для ReFS:  Дедупликация данных теперь поддерживается в ReFS для оптимизации свободного места на томе путем проверки данных на наличие дублирующихся частей.
• Отказоустойчивость хранилища виртуальных машин:  Предоставляет интеллектуальные средства для сохранения состояний сеансов ВМ, чтобы свести к минимуму влияние незначительных сбоев в работе хранилища.
• Облако-свидетель:  Включает хранилище BLOB-объектов Azure в качестве свидетеля в кворуме для растянутого кластера. Кроме того, в Windows Server 2019 теперь вы можете создать файловый ресурс-свидетель, который не использует объект имени кластера (CNO), а просто использует локальную учетную запись пользователя на сервере, к которому подключен FSW.
• Мониторинг работоспособности хранилища:  Обеспечивает непрерывный мониторинг, отчетность и обслуживание для непосредственной поддержки дискового пространства.
• Мониторинг всего кластера:  Отслеживает использование памяти и ЦП, емкость хранилища, IOPS, пропускную способность и задержку в режиме реального времени с четкими предупреждениями, когда что-то не так.
• Наборы кластеров:  Позволяет создавать большие масштабируемые кластеры с большей гибкостью (развертывание и вывод из эксплуатации кластеров) без ущерба для отказоустойчивости.
• Последовательное обновление ОС кластера: Позволяет администратору беспрепятственно обновлять операционную систему узлов в отказоустойчивом кластере с Windows Server 2012 R2 и Windows Server 2016 до Windows Server 2019 Standard
• Кластер в смешанном режиме ОС: Включает Windows Server Узлы кластера 2012 R2 для работы с узлами Windows Server 2016.
• Отказоустойчивые кластеры Site-Aware:  Группирует узлы в растянутые кластеры на основе физического расположения, улучшая ключевые операции жизненного цикла кластера, такие как отработка отказа, политики размещения, пульсация между узлами и поведение кворума.
• Мягкая перезагрузка ядра:  Обеспечивает более быструю перезагрузку оборудования, проверенного WSSD, что сокращает время простоя приложений.
• Постоянная память:  Поддержка технологии постоянной памяти (PM) обеспечивает доступ к энергонезависимым носителям на уровне байтов, а также значительно снижает задержку при хранении или извлечении данных.
• Рабочие нагрузки Linux и FreeBSD:  Включает большинство функций программно-определяемого центра обработки данных Windows Server для гостевых систем Linux и FreeBSD, работающих на Hyper-V, для повышения функциональности, производительности и управляемости.
• Горячее добавление и удаление для диска, памяти и сети:  Добавление или удаление сетевого адаптера и регулировка объема выделенной памяти во время работы виртуальной машины без каких-либо перерывов. Возможность настройки памяти работает, даже если для хоста Hyper-V включена динамическая память.
• Сетевой контроллер:  Предоставляет централизованную программируемую точку автоматизации для управления, настройки, мониторинга и устранения неполадок в виртуальной сетевой инфраструктуре в вашем центре обработки данных.
• Виртуальная сеть:  Помогает создавать сетевые наложения поверх общей многопользовательской физической структуры.
• Программный балансировщик нагрузки (SLB):  Оптимизированный для облака балансировщик нагрузки уровней 3 и 4, обеспечивающий балансировку нагрузки как север-юг, так и восток-запад.
• Пиринг виртуальных сетей:  Обеспечивает высокоскоростное соединение между двумя виртуальными сетями.Трафик между виртуальными сетями проходит через базовую сеть Fabric без шлюза. Обе виртуальные сети должны быть частью одного штампа центра обработки данных.
• Распределенный брандмауэр и микросегментация:  Динамически сегментируйте сети на основе меняющейся безопасности или потребностей приложений, используя брандмауэр с отслеживанием состояния и группы безопасности сети.
• Гибридные шлюзы SDN:  Мультитенантные, высокодоступные шлюзы, которые соединяют виртуальные сети клиентов с Azure, другими облаками на базе Windows Server, высокоскоростными глобальными сетями и локальными невиртуализированными ресурсами.
• Улучшенный шлюз SDN:  Улучшение до 3-х раз для туннелей GRE и IPSec site-to-site VPN.
• Конвергентное RDMA:  Конвергенция трафика хранилища RDMA и трафика арендатора Ethernet на одной и той же базовой группе сетевых адаптеров для значительной экономии средств, а также получения желаемой пропускной способности и качества обслуживания.
• Протокол точного времени (PTP):  PTP позволяет сетевым устройствам добавлять задержку, вносимую каждым сетевым устройством, к измерениям времени, тем самым обеспечивая гораздо более точную выборку времени, чем протокол сетевого времени (NTP).
• Високосная секунда:  Поддержка дополнительных секунд (иногда 1-секундное добавление к UTC для корректировки по мере замедления вращения Земли) повышает точность, соответствие требованиям и отслеживаемость.
• HTTP/2:  Поддержка HTTP/2 (RFC 7540) на собственном HTTP-сервере. Теперь Windows Server 2019 обеспечивает преимущества производительности и безопасности при развертывании вашего веб-сайта с помощью HTTP/2.
• Фоновый транспорт с оптимизированной задержкой — LEDBAT:  В Windows Server 2019 мы добавили поставщика управления перегрузкой сети с оптимизированной задержкой — фоновую передачу с малой дополнительной задержкой (LEDBAT).LEDBAT предназначен для автоматического предоставления полосы пропускания пользователям и приложениям, используя всю доступную полосу пропускания, когда сеть не используется.
• Управление IP-адресами (IPAM) и DNS:  IPAM теперь поддерживает комплексное управление DNS и DHCP с управлением доступом на основе ролей в нескольких лесах AD. DNS обеспечивает управление трафиком, балансировку нагрузки, развертывание с разделением ресурсов и предотвращение атак с усилением DNS.
• Роль служб MultiPoint:  Обеспечивает низкую стоимость рабочего места, позволяя нескольким пользователям запускать собственные сеансы при подключении к одному компьютеру.
• Высокодоступный посредник соединений RDS: помогает создать отказоустойчивый посредник соединений для сценариев служб удаленных рабочих столов (RDS).
• SDN с IPv4/IPv6: Программно определяемая сеть (SDN) обеспечивает метод централизованной настройки и управления физическими и виртуальными сетевыми устройствами. Кроме того, Windows Server 2019 Standard теперь также поддерживает IPv6 и двухстековую адресацию IPv4/IPv6.

 


 

  • Бренд: Microsoft
  • Дата выпуска: 10.08.2018
  • Тип программы: Windows Server
  • Формат: Розничный лицензионный ключ
  • Совместимость: 32-разрядная и 64-разрядная
  • Язык: EU Многоязычный (после установки можно изменить языковые настройки; дополнительные языковые пакеты также можно загрузить и установить отдельно)
  • Код продукта : P73-07788
  • EAN/UPC : 0889842425611

Параметры хранилища Windows Server 2019: давайте выполним детализацию

Заполните форму, чтобы продолжить

Ведущий:
Орест Лесюк, инженер отдела предпродажной подготовки, StarWind

Продолжительность: 37:39

Опубликовано: 17 апреля 2019 г.

Ключевые моменты вебинара:

  • Характеристики вариантов хранения Windows Server 2019
  • Описание службы миграции хранилища: переход со старых серверов Windows на новые
  • Новые возможности реплики хранилища
  • Storage Spaces Direct и новая возможность вложенной устойчивости для S2D
  • Демо-время: дедупликация и сжатие данных для файловой системы ReFS

Вы являетесь пользователем Windows Server или системным администратором, который постоянно следит за обновлениями операционной системы Windows и ищет инновационные решения для своей ИТ-инфраструктуры? Мы хотим помочь вам получить представление о новых возможностях хранилища в Windows Server 2019.Новая версия серверной операционной системы Windows от Microsoft — Windows Server 2019 — уже вышла и активно используется. К нему была добавлена ​​новая технология Storage Migration Service, которая обеспечивает быструю миграцию данных и идентификаторов серверов со старых Windows Server на новые. Кроме того, в Storage Spaces Direct реализовано множество улучшений: новая возможность вложенной устойчивости позволяет поддерживать высокую доступность хранилища даже при множественных сбоях оборудования.Более того, благодаря функционалу дедупликации и сжатия данных для файловой системы ReFS вы можете хранить до 10 раз больше данных на том же томе! И давайте не будем забывать о новых возможностях Storage Replica. Все это нужно знать, чтобы понять, действительно ли Windows Server 2019 дает вам то, что нужно для вашего хранилища. Узнайте из этого видео обо всех обновлениях в хранилище в Windows Server 2019 и решите для себя «быть или не быть» с Windows Server 2019.

Версия Essentials для Windows Server 2019 для малого бизнеса — партнер Redmond Channel

Новости

Выходит версия Windows Server 2019 Essentials для малого бизнеса

  • Курт Маки
  • 5 сентября 2018 г.

Предстоящая версия Windows Server 2019 Essentials для малого бизнеса будет выпущена Microsoft в этом году, сообщила компания в среду.

Есть одна загвоздка: возможно, это последняя версия Essentials, которую когда-либо выпускала Microsoft. «Существует большая вероятность того, что это может быть последний выпуск Windows Server Essentials», — говорится в заявлении Microsoft относительно планов Windows Server 2019 Essentials.

Windows Server 2019 Essentials будет иметь такие же функции, как и стандартная версия Windows Server 2019. Microsoft специально назвала две функции. Например, версия Essentials будет поддерживать службы миграции хранилища, средство инвентаризации и переноса старых настроек сервера на новый целевой сервер.В версии Essentials также можно будет использовать System Insights, службу Microsoft, которая использует машинное обучение для прогнозирования системных событий, таких как оценка ресурсов ЦП и сети, а также потребление хранилища и объема.

Microsoft не будет включать «роль Essentials Experience» в Windows Server 2019 Essentials, как указано в объявлении.

«Essentials Experience в первую очередь упростил общий доступ к файлам и управление устройствами», — говорится в объявлении, предполагающем, что вместо этого организации могут использовать портал управления Windows Admin Center на основе браузера.

Этот момент немного сбивает с толку, поскольку ранее роль Essentials Experience была описана как опция для пользователей выпусков Standard и Datacenter в Windows Server 2016 и Windows Server 2012. Итак, возможно, Microsoft пытается сказать, что отказывается от этой опции роли Essentials Experience. для пользователей выпусков Standard и Datacenter Windows Server 2019. Непонятно.

Microsoft считает, что малые предприятия должны предпочесть использовать пакет лицензирования Microsoft 365 Business для доступа к службам, размещенным в центрах обработки данных Microsoft, вместо того, чтобы размещать свои собственные серверы для запуска своих приложений и хранения своих файлов.Стоимость использования Microsoft 365 Business составляет 20 долларов США на пользователя в месяц, согласно странице с ценами Microsoft, но она включает в себя приложения Office, службы Exchange Online и SharePoint Online, а также другие решения.

Принимая решение о выпуске Essentials версии Windows Server 2019, Microsoft сначала проконсультировалась с сообществом Microsoft Most Valuable Professional (MVP) и «другими влиятельными лицами», чтобы узнать их мнение о потребностях малого бизнеса. После этих обсуждений Microsoft увидела необходимость выпустить еще одну версию Essentials.

«Хотя наши клиенты из малого бизнеса используют облачные сервисы там, где они могут, локальные серверы по-прежнему ценны и востребованы в краткосрочной перспективе по таким причинам, как цена и возможность запускать традиционные приложения, которые могут еще не иметь соответствующей облачной функциональности, — пояснила Microsoft.

Ранее Microsoft заявляла, что Windows Server 2019 появится где-то в этом году, хотя цены обычно объявляются в последнюю очередь. Несмотря на то, что цены на Windows Server 2019 еще не известны публично, цены на Windows Server 2016 могут служить ориентиром.Стоимость Windows Server 2016 Essentials составляет 501 доллар США для организаций с количеством пользователей до 25 и 50 устройств без дополнительных затрат на лицензии клиентского доступа (CAL), согласно странице цен Microsoft. Клиентские лицензии обычно требуются, когда конечные пользователи каким-либо образом подключаются к Windows Server, а также при использовании выпусков Standard и Datacenter сервера.

С помощью Windows Server 2019 Essentials организации смогут запускать «традиционные приложения, такие как общий доступ к файлам и принтерам.«Однако одна опция, касающаяся поддержки нескольких доменов, будет исключена из этого выпуска. Например, хотя Microsoft разрешила пользователям Windows Server 2016 поддерживать несколько доменов и несколько доменных серверов, эта возможность исчезнет с Windows Server 2019 Essentials.

Вот как Microsoft выразилась по этому поводу:

Windows Server 2019 Essentials имеет те же лицензионные и технические характеристики, что и его предшественник, Windows Server 2016 Essentials.При настройке в качестве контроллера домена Windows Server 2019 Essentials должен быть единственным контроллером домена, должен выполнять все роли FSMO с гибкими настройками и не может иметь двусторонние доверительные отношения с другими доменами Active Directory.

Если это ограничение для небольших организаций, Microsoft не объяснила его. Согласно документу Microsoft, существует три роли FSMO, которые теперь называются «ролями мастера операций». Существует основная роль эмулятора контроллера домена для обработки обновлений пароля.Роль операций с относительными идентификаторами используется для поддержки глобальных идентификаторов домена. Наконец, есть роль операций с инфраструктурой для обеспечения безопасности домена. По-видимому, эти три роли должны быть настроены на одном сервере при использовании выпуска Windows Server 2019 Essentials.


Об авторе

Курт Маки — старший новостной продюсер группы Converge360 компании 1105 Media.

Запуск Windows Server 2019 состоится в октябре — Интернет-журнал Microsoft Certified Professional Magazine

Новости

Запуск Windows Server 2019 состоится в октябре

Microsoft готова сделать Windows Server 2019 общедоступной в октябре, объявила компания в понедельник в начале своей конференции Ignite 2018.

В частности, по словам Эрин Чаппл, главы Windows Server в Microsoft, Windows Server 2019 будет доступна в версиях Essentials (для малого бизнеса), Standard и Datacenter, когда она достигнет финальной стадии выпуска. System Center 2019, набор инструментов управления Microsoft, используемый с Windows и Windows Server, станет общедоступным «в первой половине 2019 календарного года», добавила она.

Чаппл предложил общий обзор возможностей Windows Server 2019, который «построен на базе Windows Server 2016.»

Она отметила, что

Windows Server 2019 предназначена для поддержки «гибридных» вычислительных сред. Гибрид означает, что организации используют Windows Server в своих центрах обработки данных в сочетании с общедоступными облачными службами. Гибридная поддержка обеспечивается с помощью Центра администрирования Windows, портала управления Microsoft на основе браузера. Она отметила, что Центр администрирования Windows может использовать такие службы, как Azure Backup и Azure File Sync. Организации могут использовать службу миграции хранилища Майкрософт, которая является частью этого портала, для перемещения файловых серверов в центры обработки данных Azure.

Windows Server 2019 также включает некоторые функции безопасности. Возможность защищенных виртуальных машин предотвращает копирование файлов виртуальных машин. Microsoft также расширила эту возможность на виртуальные машины на базе Linux в Windows Server 2019. Microsoft также интегрировала свои службы Advanced Threat Protection в Защитнике Windows с Windows Server 2019. Microsoft описывает Advanced Threat Protection в Защитнике Windows как «единую платформу для превентивной защиты, обнаружения взлома, автоматического расследования и реагирования».»

Что касается поддержки приложений, Windows Server 2019 имеет упрощенное ядро ​​сервера, чтобы помочь разработчикам, раскручивающим контейнеры. Чаппл упомянул о поддержке сервером контейнеров Linux, которые могут работать «бок о бок с контейнерами Windows». Новый сервер работает с Microsoft Service Fabric для разработки облачных приложений. Он также поддерживает Kubernetes, решение Google для оркестрации контейнеров. Microsoft ранее указывала, что поддержка Kubernetes достигнет стадии общедоступности с выпуском Kubernetes версии 1.13.

Гиперконвергентная инфраструктура и программно-определяемые сети, включая поддержку безопасности, — это другие возможности Windows Server 2019. Эти технологии позволяют масштабировать развертывание от небольших двух узлов до сотен серверов с технологией кластерных наборов, что делает его доступным независимо от масштаба развертывания», — отметил Чаппл. Функция Cluster Sets предназначена для повышения гибкости при использовании виртуальных машин в кластерах. Microsoft определяет наборы кластеров как «слабо связанные федеративные группы из нескольких отказоустойчивых кластеров: вычислительных, систем хранения или гиперконвергентных.Кроме того, у Microsoft есть программа Windows Server Software Defined для OEM-партнеров, которая предназначена для проверки оборудования для гиперконвергентных сценариев и сценариев хранения. видеоприложений Microsoft также упростила быструю настройку подключений к виртуальной частной сети (VPN) Azure с возможностью VPN типа «точка-сеть».

Microsoft обещает улучшить производительность ЦП в Windows Server 2019 благодаря объединению сегментов приема в технологии vSwitch, которая снижает использование ЦП при одновременном повышении пропускной способности.Кроме того, его технология Dynamic Virtual Machine Multi-Queue предназначена для обеспечения автоматической настройки для оптимизации рабочих нагрузок ЦП. В Windows Server 2019 также улучшены программно-определяемые сетевые шлюзы для подключений IPSec и GRE.

Microsoft обещает предоставить улучшенную поддержку веб-сайтов для трафика HTTP/2 с Windows Server 2019. Ожидается, что функция Storage Spaces Direct в Windows Server 2019, которая позволяет ИТ-специалистам объединять ресурсы хранения с использованием дисков в кластере, увеличит емкость хранилища в четыре раза до Пулы 4PB.

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


Об авторе

Курт Маки — старший новостной продюсер группы Converge360 компании 1105 Media.

Разница между Windows Server и Windows Storage Server 2016 на NAS — сравнение NAS

Что такое Windows Storage Server 2016 и чем он лучше Windows Server?

Windows Storage Server 2016 — это программный компонент хранилища, использующий операционную систему Windows Server 2016 и специально оптимизированный для использования с сетевыми устройствами хранения данных (NAS).На первый взгляд, это почти идентичный выпуск программного обеспечения Windows Server 2016, но он поставляется уже установленным для простого развертывания на специализированном устройстве WSS NAS. Существует множество преимуществ (не только стоимость) приобретения NAS Windows Storage Server от таких брендов, как Buffalo и Thecus, по сравнению с отдельной покупкой Windows Server 2016 и NAS-сервера, который его поддерживает. Во-первых, вы не можете приобрести Windows Storage Server 2016, WSS — это версия Windows Server, лицензированная OEM-производителями (опять же, такими как Buffalo или Thecus) для использования в предварительно подготовленных устройствах NAS.

Каковы преимущества Windows Storage Server 2016 NAS?

Как уже упоминалось,

Windows Storage Server 2016 — это серверная версия Windows, оптимизированная для устройств, подключенных к сети. Однако он продается только через избранные и сертифицированные бренды Microsoft в виде полноценного устройства хранения (программное и аппаратное обеспечение в одном пакете), поэтому аппаратное и программное обеспечение оптимизировано для обеспечения наилучших возможностей хранения. WSS 2016 — идеальный выбор, если вы хотите:

  • Интеграция хранилища в существующую инфраструктуру Windows.
  • Иметь неограниченное количество пользователей в службе поддержки Active Directory.
  • Централизованно управлять всеми серверами Windows.
  • Создайте масштабируемое решение.
  • Настройте устройство, которое также может работать в качестве цели iSCSI.

Он также имеет следующие преимущества по сравнению с версиями без хранения:

  • Сокращает работу ИТ-администратора, особенно если в компании работает более 20 сотрудников.
  • Позволяет создавать доменные леса и поддомены.
  • Поставляется с полнофункциональным сервером печати.

  • Работает в известной операционной системе Windows.

  • Беспроблемно работает со всеми продуктами Windows.
  • Развертывание выполняется легко, быстро и просто.
  • Полностью настраиваемый в соответствии с вашими конкретными требованиями.
  • Возможность полной интеграции с Active Directory, включая политики и безопасность.
  • Нет ограничений для пользователей.

Благодаря этим преимуществам WSS 2016 (и WSS 2012) по-прежнему пользуются популярностью среди администраторов ИТ-сетей, и поэтому устройства WSS NAS по-прежнему очень популярны. WSS 2016 — последняя версия. Как и в предыдущих версиях, он не продается напрямую, а доступен только как часть интегрированного аппаратного продукта. Он также поставляется в двух разных версиях, и какая версия вашего NAS WSS 2016 будет зависеть от объема необходимого вам хранилища и аппаратного обеспечения NAS.Ниже приведены различия между версиями WSS ’16 WorkGroup и Standard:

.

Что купить: Thecus или Buffalo WSS 2016 NAS?

Buffalo Windows Storage Server 2016 NAS отлично подходит для малых предприятий или домашних офисов, которым требуется надежное решение для хранения данных с резервированием для защиты данных и предотвращения простоев в сочетании с новейшим программным обеспечением для управления хранением по доступной цене. Кроме того, это лучший выбор по сравнению с другими сетевыми хранилищами WSS Thecus, так как их линейка сетевых хранилищ WSS 2016, которая скоро будет выпущена, не поставляется с лицензиями или опциями 10Gbe в стандартной комплектации.

Что могут сделать Buffalo NAS и Windows Server 2016?

Buffalo NAS можно использовать в качестве устройства хранения данных iSCSI, и они идеально подходят для добавления хранилища в новую или существующую виртуальную среду. Расширенная поддержка Hyper-V включает в себя общие VHD (виртуальные жесткие диски), изменение размера VHD во время работы виртуальной машины, качество обслуживания хранилища (QoS), а также улучшенную производительность для живых миграций и межверсийных живых миграций. Улучшенная цель iSCSI теперь поддерживает VHDX (VHD 2.0) для емкости до 64 ТБ и поддерживает SMI-S для обеспечения сквозной подготовки.

Это возможности и функции, которые также поддерживаются рядом WSS 2016, WSS 2012 и Buffalo NAS не на базе Windows Server. Наконец, поддерживаемый протокол NFS Network-Attached Storage можно использовать для серверного хранилища для виртуальных машин, работающих на VMware ESX или ESXi.

NAS Buffalo WSS 2016 Поступит в продажу в мае 2018 г. — WS5220DN, WS5420DN и WSH5610DN


Что такое аппаратное обеспечение WSS 2016 Buffalo NAS?

Приступая к спецификациям, сетевое хранилище Buffalo WSS 2016 доступно в настольной и стоечной версиях и включает в себя емкости хранения от 4 ТБ до 48 ТБ (постоянно растет), поскольку они поставляются с предварительно заполненными жесткими дисками WD Red NAS. .Они также поставляются со встроенной программной И аппаратной защитой RAID (в зависимости от того, какой NAS BUffalo WSS 2016 вы выберете) с возможностью выбора RAID 0, 1, 5, 6, 10, 50, 60 и JBOD на 2, 4 и 6 отсеков в горячем режиме. -заменяемые конфигурации. NAS Buffalo для сервера хранения Windows 2016 поставляется с двумя внутренними конфигурациями, см. ниже:

.
WS5220DN, 2 отсека

WS5220DN04W6EU — 4 ТБ

WS5220DN08W6EU — 8 ТБ

 

Доступно с мая 2018 г.

WS5420DN, 4 отсека

WS5420DN08W6EU — 8 ТБ

WS5420DN32W6EU — 16 ТБ

WS5420DN16W6EU — 12 ТБ

Доступно с мая 2018 г.

Intel Atom C3338 — двухъядерный 1.5 ГГц

8 ГБ оперативной памяти DDR4

WSS 2016 Workgroup Edition

10Gbe (10GBASE-T) x1

1GbE(RJ45) x2

USB 3.1 Gen 1 x2

Резервное копирование в одно касание через USB

ЖК-дисплей

2 отсека для хранения

Программный RAID 0, 1, JBOD

Доступны версии 4 ТБ и 8 ТБ

Intel Atom C3338 — двухъядерный 1,5 ГГц

8 ГБ оперативной памяти DDR4

WSS 2016 Workgroup Edition

10Gbe (10GBASE-T) x1

1GbE(RJ45) x2

USB 3.1 поколение 1 x2

Резервное копирование в одно касание через USB

ЖК-дисплей

4 отсека для хранения

Программный RAID 0, 1, 5, 6, 10

Доступны модели емкостью 8 ТБ, 16 ТБ и 32 ТБ

WSH5610DN – 6 отсеков

WSH5610DN12S6EU — 12 ТБ

WSH5610DN24S6EU — 24 ТБ

WSH5610DN48S6EU — 48 ТБ

Доступно уточняется 2018

2 х LAN, 1 х USB3.0, 2 х USB2.0

1 x eSATA, 1 x HDMI

1 последовательный разъем D-Sub 9

Резервное копирование в одно касание через USB

ЖК-дисплей

6-секционное хранилище

Аппаратный RAID 0, 1, 5, 6,

Intel® Celeron® J1900 (четырехъядерный)

4 ГБ оперативной памяти DDR3

WSS 2016, стандартная версия

 

Хотите следить за определенной категорией? Следите за тегом2018 WSS 2016 NASЛучший WSS 2016 NASBuffalo NASBuffalo WSS 2016 NASBusiness NASEnterprise NASHyper V NASNASnas ДЕДУПЛИКАЦИЯNAS SMB 3.1.1nas wssNAS WSS 2016Right WSS 2016 NASThecus NASThecus WSS 2016 NASWindows 10 NASWindows Сервер NASWindows хранения ServWS5220DNWS5220DN04W6EUWS5220DN08W6EUWS5420DNWS5420DN08W6EUWS5420DN16W6EUWS5420DN32W6EUWS5420RNWS5420RN16S6EUWS5420RN32S6EUWSH5610DN12S6EUWSH5610DN24S6EUWSH5610DN48S6EUWSS 2012 NASwss 2012 WSS 2016 diWSS 2016 NASWSS 2016 NAS UsersWSS 2016 StandardWSS 2016 WorkgroupWSS NASWSS NAS BusinessWSS NAS LicenseWSS NAS VMWSS SMB 3.1.1Also Read … Synology RS422 + Rackstation NAS Synology DS1522+ NAS Drive RevСовместимый ИБП для Synology NAQNAP TS-664 NAS ReviewКак подключить Synology NAS к Terramaster F2-423 NAS Drive RTerramaster F4-423 NAS Drive RTerramaster F4-423 NAS Drive RСовместимый M.2 NVME SSD HeatsiQNAP TS-464 и TS-453D NAS Com

Это описание содержит ссылки на Amazon. Эти ссылки приведут вас к некоторым продуктам, упомянутым в сегодняшнем материале. Как партнер Amazon, я зарабатываю на соответствующих покупках. Посетите NASCompares Deal Finder, чтобы найти лучшее место для покупки этого устройства в вашем регионе, основываясь на обслуживании, поддержке и репутации — просто найдите свой диск NAS в поле ниже

ПОИСК В КОРОБКЕ НИЖЕ ДЛЯ ЛЮБОГО ДРУГОГО NAS

Нужна консультация эксперта по хранению данных?

Мы хотим сохранить бесплатную консультацию по NASCompares FREE так долго, как это возможно.С тех пор, как эта служба была запущена в январе 18 года, мы каждый месяц помогали сотням пользователей решать проблемы с хранилищем, но мы можем продолжать делать это только с вашей поддержкой. Поэтому, пожалуйста, выберите покупку на Amazon в США и Амазонка Великобритания на статьи при покупке, чтобы обеспечить поддержку доходов от рекламы или пожертвовать / поддержать сайт ниже. Наконец, чтобы получить бесплатную консультацию по настройке, просто оставьте сообщение в комментариях ниже на сайте NASCompares.com, и мы свяжемся с вами. Нужна помощь? Где возможно (и где это уместно), пожалуйста, предоставьте как можно больше информации о ваших требованиях, так как тогда я смогу найти наилучший ответ и решение для ваших нужд.Не беспокойтесь о том, что ваш адрес электронной почты потребуется, он НЕ будет использоваться в списке рассылки и НЕ будет использоваться каким-либо образом, кроме как для ответа на ваш запрос. Условия и положения В качестве альтернативы, почему бы не спросить меня на форуме ASK NASCompares , нажав кнопку ниже. Это центр сообщества, где я могу ответить на ваш вопрос, пожевать жир, поделиться информацией о новых выпусках и даже опубликовать исправления. Я всегда буду отвечать на ВСЕ запросы, но в одиночку я не могу обещать скорость! Поэтому, поделившись своим запросом в разделе ASK NASCompares ниже, вы сможете получить более широкий спектр решений и предложений, наряду с моими собственными.Это описание содержит ссылки на Amazon. Эти ссылки приведут вас к некоторым продуктам, упомянутым в сегодняшнем видео. Являясь партнером Amazon, я зарабатываю на соответствующих покупках.

Родственные

KB450242 — Конфигурация Windows Server 2019 — База знаний 45Drives

В этом документе рассказывается, как 45Drives настраивает Storinator с использованием плат LSI 9361-16i HBA вместе с дисковыми пространствами Windows. Мы рассмотрим создание RAID с помощью MegaRAID Storage Manager, а затем с помощью Windows Storage Spaces объединим эти RAID вместе, чтобы они выглядели как один большой том Storage.

На вашем Storinator должен быть установлен Windows Server, а также карты LSI 9361-16i в режиме RAID. Все Storinator, покидающие объект 45Drives, будут иметь предварительно установленный в ОС MegaRAID Storage Manager.

Сторинаторы

построены таким образом, что каждая строка привязана к плате 16i LSI, в данном случае это аппаратная RAID-карта LSI 9361. Мы будем создавать RAID6 из 15 дисков (с двойной четностью) на каждом из этих контроллеров. Это означает, что AV15 будет иметь 1 контроллер, Q30 — 2 контроллера, S45 — 3 контроллера, а XL60 — 4 контроллера.

Создание рейда с помощью MegaRAID

  1. Войдите в свою учетную запись администратора Windows Server. Назначенный пароль по умолчанию: 45Drives .
  2. После входа в систему откройте MegaRAID Storage Manager, чтобы начать процесс создания томов RAID.
  3. Вы увидите список  удаленных серверов. Когда откроется экран входа в систему, щелкните локальный компьютер, а затем введите имя и пароль администратора сервера Windows.
  4. После входа в систему вы увидите информационную панель с некоторой информацией о каждой карте в системе.Нажмите на вкладку Physical , обведенную красным ниже.
  5. На вкладке «Физические» вы увидите разбивку каждого диска, подключенного к каждому контроллеру. Чтобы создать наш RAID, щелкните правой кнопкой мыши контроллер и выберите Create Virtual Drive
  6. .
  7. Выберите вариант  Дополнительно и нажмите  Далее
  8. Выберите RAID6 в раскрывающемся списке Уровень RAID и выделите все ненастроенные диски в списке слева, затем нажмите Добавить > > , чтобы добавить их в RAID.
  9. Затем вам нужно будет нажать  Создать группу дисков , а затем  Далее .
  10. Далее вам будет предложено настроить некоторые параметры виртуального диска. Единственная настройка, которую мы здесь обычно изменяем, — это Полная инициализация . Нажмите  Создать виртуальный диск , появится всплывающее предупреждение о политике обратной записи, которая допустима, если на вашем компьютере установлена ​​резервная батарея (она является стандартной для наших сторинаторов).Для завершения нажмите Далее .
  11. Затем вам будет представлена ​​сводка. Нажмите  Готово , чтобы завершить создание RAID.
  12. Повторите это для каждого контроллера в системе. Каждый RAID должен иметь одинаковую конфигурацию и размер, так как мы собираемся чередовать их вместе с помощью Storage Spaces.
    Примечание: В зависимости от размера ваших дисков инициализация на ваших RAID-массивах может занять несколько часов, наберитесь терпения.
  13. Если вы перейдете на вкладку Логические, вы увидите список RAID.Если вы нажмете на виртуальный диск, он предоставит свои свойства:

Чередование рейдов в один том и форматирование файловой системы

  1. После завершения всех инициализаций мы готовы использовать дисковые пространства Windows для объединения RAID-массивов, чтобы они выглядели как один большой том. Откройте меню «Пуск» и откройте Server Manager .
  2.  Перейдите на вкладку File and Storage Services в списке справа.
  3.  Ваши RAID будут отображаться как «Физические диски», мы собираемся создать новый пул хранения, состоящий из этих дисков (в этом примере их 4).Для этого перейдите на вкладку Storage Pools и щелкните правой кнопкой мыши в поле Storage Pools — выберите New Storage Pool…
  4. Сначала вас попросят назвать пул хранения, мы решили использовать TANK. Далее вам нужно выбрать Физические диски, как мы упоминали выше — в данном случае у нас их 4. Отметьте их все и нажмите Next . Затем нажмите  Создать .
  5. Теперь, когда у нас создан пул хранения, нам нужно создать виртуальный диск .Для этого используйте Мастер создания виртуального диска, показанный ниже:

    Вам будет предложено выбрать свой пул хранения — выберите тот, который вы только что создали, и нажмите OK .
  6. Сначала вам нужно выбрать имя для вашего виртуального диска, в этом примере мы будем использовать просто VD_1.
  7. Мы не включаем распознавание корпуса, поэтому можем просто нажать кнопку Далее.
  8. В Storage Layout мы хотим выбрать Simple . Это позволит распределить данные по нашим RAID-устройствам, максимально увеличив емкость и пропускную способность.Там, где у нас уже есть защита данных с двойной четностью на каждой карте контроллера, не беспокойтесь, когда дисковые пространства говорят, что простая схема не так надежна.
  9. При подготовке мы выберем Фиксированный для простоты.
  10. В поле Размер выберите Максимальный размер и нажмите Далее
  11. Откроется окно подтверждения – проверьте выбор и нажмите  Создать , если вас все устраивает
  12. После завершения должен автоматически открыться мастер создания нового тома.Обязательно выберите свой виртуальный диск (VD_1 в этом примере)
  13. Для размера по умолчанию используется максимальный размер, поэтому мы просто сохраним его и нажмем Далее .
  14. Вас спросят, хотите ли вы присвоить букву диска новому тому или назначить его папке. У вас также есть возможность не назначать ни того, ни другого.
  15. Далее следует выбор типа файловой системы. NTFS и ReFS — это два варианта, NTFS имеет максимальный размер 256 ТБ, поэтому, если ваш объем больше этого, вам нужно использовать ReFS.Хотя в этом примере наш том находится всего в диапазоне 40 ТБ, я выберу ReFS, поскольку большинство Storinator будет развертываться с томами объемом более 256 ТБ.
  16. Проверьте настройки на вкладке Подтверждение и нажмите  Создать . После завершения том будет смонтирован в выбранном вами месте
  17. .
  18. Ниже приведен быстрый локальный тест тома с использованием CrystalDiskMark

Microsoft Windows Server 2019

%PDF-1.4 % 136 0 объект >/Outlines 131 0 R/Page/UseOutlines/PageLayout/SinglePage/PageMode/UseOutlines/Pages 130 0 R/Type/Catalog/ViewerPreferences>>> эндообъект 138 0 объект >поток Библиотека Adobe PDF 11.02019-04-02T17:67:14. Enterprise Development LP.273560e451411c749c523168eacaf64e1e0c549ecbb177,Pages=14,Words=4639,Images=0Adobe PDF Library 11.0application/pdf2019-04-02T17:17:38.706Z

  • Библиотека маркетинговых документов HPE
  • Hewlett Packard Enterprise Development LP.
  • Microsoft Windows Server 2019
  • страниц=14
  • слов=4639
  • изображений=0
  • Hewlett Packard Enterprise Development LP. конечный поток эндообъект 131 0 объект > эндообъект 130 0 объект > эндообъект 51 0 объект > эндообъект 91 0 объект > эндообъект 89 0 объект >/Шрифт>>>/Поворот 0/StructParents 16/Вкладки/S/Тип/Страница>> эндообъект 92 0 объект >/Шрифт>>>/Поворот 0/StructParents 17/Вкладки/S/Тип/Страница>> эндообъект 97 0 объект >/Шрифт>>>/Поворот 0/StructParents 19/Вкладки/S/Тип/Страница>> эндообъект 108 0 объект >/ExtGState>/Font>/XObject>>>/Rotate 0/StructParents 24/Tabs/S/Type/Page>> эндообъект 109 0 объект [110 0 Ч 112 0 Ч 114 0 Ч 116 0 Ч 118 0 Ч] эндообъект 120 0 объект >поток HW[oF~GhΕC(8)H`yE-5ZJU9HYv»R

    (j%l?xb͗B|n/_n+*+\ml,-S] {kfhֳj?ՕBU2(PZ ]Cc>)H^NK0 {zs1)b:e/D t_I,#_.

    Добавить комментарий

    Ваш адрес email не будет опубликован.