Windows server

Ошибка упоминается за разные годы и по разным причинам. Видимо тут какой-то косяк с работой с серверами Microsoft.

Соответственно, тут пригодился чужой совет с просторов интернета.

Идём в ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata
и проверяем ссылку в параметре DeviceMetadataServiceURL - она не рабочая. Это именно та ссылка, куда явно ломился сервер для "общения" с мелкомягкими.
Там же находим параметр PreventDeviceMetadataFromNetwork и устанавливаем ему значение "1", чтоб сервер перестал туда ломиться. Сервер для порядка перезагружаем, конечно же.

После этой манипуляции запросы пропадали и сервера виснуть переставали.

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

Плюс нигде не встречал упоминаний, что именно из-за этой ошибки могли виснуть сервера. Хотя были упоминания, что ошибка не вполне безобидна, т.к. всё-таки даёт лишнюю нагрузку на систему. Хотя никакой перегрузки по использованию процессора или памяти высмотреть не удалось. А вот какие-то программные сбои вызывать вполне могла.

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

Всю эту хню делаем на свой страх и риск, конечно же.

Примерно в то же время, а точнее в Microsoft Windows Server 2012 появилась поддержка динамических рейдов в виде Storage Spaces, плюс появился SMB Direct и SMB Multichannel, к R2 Добавились local reconstruction codes, в 2016 Server появилась новая функция – S2D, storage space direct, но это уже старая история, а там и ReFS подоспел, с своей защитой данных от почти чего угодно, кроме своей дедупликации и своего же патча на новый год (January 2022 Patch Tuesday KB5009624 for Windows Server 2012 R2, KB5009557 for Windows Server 2019, and KB5009555 for Windows Server 2022.)

Все бы было хорошо и там, и тут, НО.

Но. S2D поддерживается только в редакции Datacenter, а это не просто дорого, а очень дорого. На то, чтобы закрыть этими лицензиями небольшой кластер серверов на 20 – уйдет столько денег, что проще купить классическую СХД.

Но. Если у вас в кластере работает хотя бы 1 (одна) виртуальная машина с Windows Server, вы все равно обязаны лицензировать все ядра всех узлов кластера лицензиями Windows Server. Тут уже надо считать, что выгоднее – попробовать закрыть все узлы лицензиями STD, с их лимитом в 2 виртуальные машины на лицензию, или лицензировать Datacenter.

Но. При этом все равно можно НЕ иметь нормальной дедупликации и компрессии (DECO) на Datacenter, НО иметь вечные проблемы со скоростью, если ваша система настроена криворукими интеграторами или таким же своим же персоналом, набранным за 5 копеек, и который тестирует скорость СХД путем копирования файла. Или путем запуска Crystal Disk mark с настройками по умолчанию.

Попутно получая проблемы с резервным копированием, если вы DECO включили, а руководство по резервному копированию с DECO Windows Server не прочитали.

Все очень просто: если экономим на кадрах, то покупаем классический выделенный СХД, в нем в разы меньше настроек и ручек, которые может крутить пользователь в GUI. Масштабируем емкость покупкой новых полок. Скорость так просто не масштабируется, как у вас стоит 2 или 4 или 8 контроллеров, так они и стоят (до 16 контроллеров, если вам очень надо).

Это не уменьшает проблем с обслуживанием, на классической СХД тоже очень желательно проводить обновление и прошивки СХД, и прошивки дисков. На некоторых СХД раньше (10-15 лет назад) обновление прошивки вполне могло привести к потере разметки и потере данных (ds4800). Но там порой и замена дисков вела к факапам, как на ds3500. Но и наоборот, в IBM была версия прошивки, которая работала 1.5, чтоли, года. Но и не прошиваться нельзя – как недавно вышло с дисками HPE и не только, которые работали ровно 40.000 часов (Dell & HPE Issue Updates to Fix 40K Hour Runtime Flaw, update to SSD Firmware Version HPD8 will result in drive failure and data loss at 32,768 hours of operation, FN70545 - SSD Will Fail at 40,000 Power-On Hours и так далее).
С как-бы всеядными MSA (старых версий) можно было сделать самому себе больно иначе – купить саму СХД, а диски туда поставить подешевле, даже SATA с их надежностью (Latent Sector Error (LSE) rate) в «1/10(-16)», и получить проблемы при ребилде даже в Raid 6. Прошиваться страшно, не прошиваться тоже страшно, зато использовать левые диски не страшно.

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

Почему Windows 2025 и storage space? Ведь есть же ..

Есть. На рынке РФ, кроме storage space и S2D, есть:

VMware by Broadcom vSAN. Есть специалисты, нет возможности купить напрямую нормальную подписку.
Высокие требования к оборудованию – нужны не бытовые дешевые SSD.
Высокие требования к людям - очень нужны умеющие и любящие читать люди.
Нужно планирование перед внедрением.
Нужна вменяемая сетевая команда, которая сможет настроить хотя бы DCB + RDMA и не впадает в священный ужас при виде Mellanox.

Nutanix. Давно ушел и с российского рынка, да и на мировом как-то скатывается в нишевое решение. Ограничения те же, что для vSAN.

Ceph. Есть и такие решения, но. Для его промышленной эксплуатации, а не в варианте «оно сломалось и не чинится, что же делать» нужны отдельные люди. Таких людей в РФ человек.. ну 20 - 40. Один из них – автор статьи Ceph. Анатомия катастрофы. Статью советую прочитать.
И это решение, если вы хотите хоть какой-то скорости, начинается с фразы «если у вас еще нет 200G коммутатора и карт, то вначале хватит и 100G, по два 100G порта на хост». Демо-стенд можно запустить хоть на 1G. Работать даже на 10G будет очень болезненно. Если еще на стадии демо начать задавать неудобные вопросы про RDMA и Active-active, то будет еще больнее. Почти так же больно, как спрашивать, можно ли использовать сервера, на которых развернут Ceph, под Openstack. И как его, Ceph, бекапить на ленты, как обеспечить аналог Veeam Direct SAN Access или Commvault Direct-Attached Shared Libraries или аналог Metro / Replication / Stretched Clusters

Остальные решения, особенно импортозамещающие, не стоят и рассмотрения. Проблема с ними всеми одна и та же – их разработчики имеют очень ограниченное представление о том, как работает ядро, как с ядром и драйверами взаимодействует виртуализация, что может быть намешано в сетевом стеке и как обрабатывать задержки в реальной среде. Наиболее эпичное падение у коллег в РФ было совсем недавно, когда пустой демо-стенд упал сам по себе. Не помню, с разносом данных в не восстановимую кашу или просто умер совсем, вплоть до переустановки всего кластера. И это я не вспоминаю о нагрузке при блоках разного размера, проблемах мониторинга, скорости работы Redundant Array of Independent Nodes (RAIN) и проблемах со скоростью при использовании четности (parity), а точнее при возникновении write amplification. И затем посмотрим, у какого из этих решений есть мониторинг, а у какого – система резервного копирования не на уровне приложений внутри виртуализации.

Альтернатива - иметь сложные интимные отношения с drbd, Patroni (PostgreSQL + Patroni + etcd + HAProxy), Stolon, Corosync, PaceMaker, BDR, bucardo, Watchdog – и постоянный риск split-brain. Рядом еще плавает RAFT и CAP theorem. Так можно докатиться до знаний про global transaction identifier (GTID) и Commit Sequence Number (CSN).

Все упирается в проблему человеков.
Или у вас большая организация с базой знаний, обучением, передачей опыта, и как-то это будет работать.
Или вы рано или поздно получите черный ящик, потому что настраивавший это человек (1 производственная штатная единица) уволился, и как это работает  - никто не знает.

Если вам безразличен вопрос доступности и целостности ваших данных, то ничего страшного не произойдет.

Изначальные проблемы Storage space без direct

Это дорогое решение, необходимо считать что почем, в том числе лицензии.

Erasure coding (EC) в GUI в нем (и в S2D) был в 2016 и 2019 сервере реализован на уровне «ну как смогли». Из GUI можно было настроить Mirror и Raid-5 (single parity), настройка Raid-6 (dual parity) требовала, почему-то, толи 7 толи 8 дисков, не понятно зачем, и давала какую-то безумную физическую деградацию, раз в 10 кажется при настройках «всего по умолчанию», а про вынос журнала на отдельный диск никто не пишет, и публично вроде не тестировал.

Схема развертывания

Поскольку мне только посмотреть, то я попробую посмотреть, что будет на домашнем ноутбуке. SSD + Windows 11 + VMware Workstation Pro 17, недавно ставшая бесплатной для домашних пользователей.

Схема тестирования

Для тестов будет выделен отдельный (конечно виртуальный) диск – сначала на 40 Гб, чтобы посмотреть на то, сколько вытянет на нем Atto benchmark, по сравнению с таким же тестом, но без виртуализации.

Там же попробую DiskSPD – с настройками:

Образ для тестов – 10 Гб, тестирование:

1 файл, 1блок, 1 поток, 100% чтения, 50/50, 0/100 % записи. Продолжительность – 30 секунд прогрев – 10 секунд. Блок данных 4 к и 64 к. Форматирование раздела .. хм. Тоже надо посмотреть, конечно, write amplification это не игрушка.

1 файл, 1,2,4, 8 потоков и очереди 4, 8, 16 и 32.

В вариантах Mirror, parity GUI.

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

Или сокращу объем проверок, если надоест.

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

Затем попробую собрать в storage space 4, 6 и 8 дисков – через GUI, и посмотрю, что и как.

Моя глобальная цель – не столько посмотреть на падение скорости, сколько

1) посмотреть на варианты настроек Erasure coding (EC) в GUI и в CLI (это я в виртуальной среде сделать могу)

2) посмотреть, влияет ли, и если влияет то как, размер блока и четность.

Сразу видны подводные камни – у меня виртуализация 2 типа, поэтому приземляемый в файл в реальной ОС блок данных – будет работать в итоге с фактической разметкой NTFS, можно получить порядочный штраф.
В рабочей среде такого, конечно, не будет, но размер блока важен и при создании LUN на классической СХД. Там хотя бы пресеты есть, это иногда помогает.

Сначала посмотрим, что там с диском

Get-WmiObject -Class Win32_Volume | Select-Object Label, BlockSize | Format-Table –AutoSize

Или более классическим путем –

fsutil fsinfo ntfsinfo c:

Ничего интересного,NTFS BlockSize – 4096 (Bytes Per Sector  : 512, Bytes Per Physical Sector :  4096, Bytes Per Cluster :  4096  (4 KB), Bytes Per FileRecord Segment  :  1024

С глубиной очереди 4, Atto дает удручающие для конца 2024 года 100 мб/сек на запись и 170 мб/сек на чтение, 25к IOPS /40k IOPS,  разгоняясь до 750/1300 мб/сек для блока 64 кб (и падая до 10 к/ 20к IOPS). Старый SATA SSD, откуда там чудеса?

Поставлю очередь 8, а тестирование ограничу размерами от 4 до 64. Стало ли лучше? Стало. 25к IOPS на запись, и 55 к IOPS на чтение для 4к блока, 16 и 20 к к IOPS для 64 к блока.

DiskSPD

Где брать: https://github.com/microsoft/diskspd/releases/latest/download/DiskSpd.zip

Что читать: https://github.com/microsoft/diskspd

Что еще читать: https://learn.microsoft.com/ru-ru/azure-stack/hci/manage/diskspd-overview

Качаем DiskSPD с github, распаковываем , кладем в C:\Diskspd\amd64 , делаем папку test, делаем первый тест

.\diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\Diskspd\test\test0001.dat > test0000.txt

И идем читать инструкцию.

-t2: указывает количество потоков для каждого целевого или тестового файла.

-o32: указывает количество невыполненных запросов ввода-вывода для каждого целевого объекта на поток

b4K: указывает размер блока в байтах, КиБ, МиБ или ГиБ. В этом случае размер блока 4K

-r4K: указывает на случайный ввод-вывод

-w0: указывает процент операций, которые являются запросами на запись (-w0 эквивалентно 100 % чтения)

-d120: указывает продолжительность теста

-Suw: отключает кэширование программной и аппаратной записи

И получаем (бадабумс) -  310.39  MiB/s  , 80к  I/O per s - 55000 на первый тред и 25000 на второй (округленно).

На этом месте пока прервусь, надо подумать как сделать удобнее.

Сегодня я начинаю небольшой цикл статей, посвященных операционной системе Microsoft — Azure Stack HCI. Да, именно посвященных ОС, а не решениям Azure, рассматривать я буду именно серверную ОС на базе ядра Windows Server с названием издания Azure Stack HCI, которая вот уже пять лет как ежегодно выходит по программе ежегодного (не долгосрочного) цикла выхода серверных ОС. На данный момент мой план таков:

1) В первой (этой) статье я опишу своё видение того, что такое Azure Stack HCI, чем он отличается от ОС Windows Server Datacenter Azure Edition (Core), что отличает Azure Stack HCI от сервисов Azure Stack, самое главное, для чего вам такая странная ОС в вашем датацентре;

2) Во второй статье я буду рассказывать о том, что такое Hot Patching, — процедура установки обновлений безопасности Microsoft без перезагрузки, какие требования к ОС имеются, — и самое главное, как обойти обязательность наличия подписки Azure, то есть как пользоваться Hot Patching в вашем датацентре без каких-либо Azure Benefits, как создавать виртуальные машины на базе ОС Windows Server и любых её ролей так, чтобы обновления ОС внутри ВМ не требовали их перезагрузки (как вы прекрасно понимаете, обновление хост ОС не требует перезагрузки ВМ в виду живой миграции между узлами кластера). Это весомый аргумент в пользу виртуализации Windows сервисов именно на базе Hyper-V;

3) В третьей статье я расскажу о том, как превратить ОС AzureStackHCI, которая поставляется исключительно в режиме Server Core в ОС с полным рабочим столом, чтобы у вас была возможность полноценно её администрировать. Причем сделать это таким образом, чтобы на ОС все так же продолжали приходить обновления с Windows Update.

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

Итак, что же такое Azure Stack HCI в 2024 году.

На Хабре есть неплохие статьи об Azure Stack (статья Azure Stack: Немного теории / Хабр (habr.com) от 2017 года) и Azure Stack HCI (статья Что такое Azure Stack HCI и как это работает / Хабр (habr.com) от 2020 года), которые в целом дают понимание о том, что такое службы Azure, в том числе и on-premises. За несколько лет, прошедших с тех публикаций основное отличие заключается в том, что AzureStackHCI теперь это издание ОС на Windows Server, выходящее раз в год, предназначенное для создания гиперконвергентной инфраструктуры на вашем оборудовании. Я очень рекомендую для начала тем, кто совсем не в курсе решения Azure Stack HCI прочитать вышеупомянутую статью корпоративного блога Microsoft, ибо я вообще не буду рассматривать ни аппаратные требования, ни процессы создания кластеров и управления имя, я буду говорить сегодня чисто об операционной системе.

Microsoft говорит, что "AzureStackHCI, — это решение гиперконвергентной инфраструктуры (HCI), в котором размещаются виртуальные машины Windows и Linux или контейнерные рабочие нагрузки и их хранилище. Это гибридный продукт, который подключает локальную систему к Azure для облачных служб, мониторинга и управления." Как и любое другое издание Windows Server, вы можете загрузить Azure Stack HCI с сайта Microsoft. Обращу внимание на то, что сейчас там предлагается загрузить версию 23H2, тогда как уже существует и 24H2, доступная на UUP, о которой я и буду вести речь в этом цикле статей. Версия 24H2 основана на базе ядра germanium, того же, что используется в Windows Server 2025 и Windows 11 24H2. Соответственно, и компоненты и обновления у данных ОС общие.

Обычно, отпугивающим фактором для начинающих администраторов является то, что Azure Stack HCI это всегда Server Core. То есть нет кнопки Пуск, Параметров и иже, нет ни MMC ни панели управления, при старте доступен sconfig, дальнейшее управление локально из командной строки или PowerShell или удаленное средствами Azure Arc и Windows Admin Center:

В Azure Stack HCI 24H2 входят лишь те роли, которые требуются для создания гиперконвергентной инфраструктуры, в первую очередь, Hyper-V и файловый сервер (включая Storage Spaces Direct), а также другие компоненты, такие как поддержка высокой доступности средствами Failover Clustering.

Как вы видите, список ролей невелик (точнее список велик, но это в основном Features). Основных ролей, имеющихся в Server Datacenter Core (обычном или Azure Edition) - таких как ADDS, ADCS, ADFS, DHCP, DNS и далее в нем нет. Но в них нет нужды на узле виртуализации, тем более Core. Вы установите полные версии Windows Server в виртуальных машинах, особенно если будет работать Hot Patching и обновления без перезагрузок.

Azure Stack HCI как ОС купить нельзя, она не лицензируется по узлам или процессорам, в отличии от традиционных решений, предполагается, что вы являетесь подписчиком Azure и будете управлять кластером при помощи Azure Arc или других средств, таким образом монетизируя затраты Microsoft. Раз ОС не лицензируется, то и активации, как класса в ней нет, ничего с ней делать не требуется:

Заводите ОС в домен, подключайтесь удалёнными средствами управления, создавайте кластер, хранилище Storage Spaces Direct, виртуальные машины Hyper-V и используйте без покупки серверных лицензий вообще, если внутри гостевых виртуальных машин у вас ОС Linux или клиентские ОС (например ферма Windows Virtual Desktop). Для лицензирования серверных ОС Microsoft внутри виртуальной среды следует как и ранее покупать лицензии Datacenter по ядрам процессоров ваших узлов виртуализации или устанавливать издания с подпиской (доступно только для Azure Stack HCI). Если потребуется, вы можете использовать встроенную в Hyper-V возможность Automatic Virtual Machine Activation (AVMA) и с AzureStack, для этого потребуется Windows Admin Center и ручная привязка ключей Windows Server Datacenter к узлам Azure Stack HCI. Если ваш AVMA ключ имеет Software Assurance или Subscription, то AVMA сможет активировать и виртуальные машины с Windows Server Azure Edition (те самые, в которых работает Hot Patching).

Не путайте Azure Stack HCI (издание ОС Windows Server) с решением Azure Stack (связка ОС Windows Server, OEM железа от какого-либо вендора-партнера и сервисов). Azure Stack это готовое решение, не всегда на базе Azure Stack HCI (чаще на базе Windows Server Datacenter), которое продаётся предустановленным в виде стойки с серверами, хранилищем, коммутаторами. Azure Stack идёт уже настроенным и готовым, - дорого, менее гибко, сложно обновлять. Azure Stack

Отдельно замечу, для виртуальных машин, работающих в Azure Stack HCI бесплатна доставка расширенных обновлений (ESU). То есть, если у вас в виртуальной машине установлен Windows Server 2012/R2 и SQL Server 2012, вы будете получать Extended Security Updates, которых не получат ОС, установленные на железе или любой другой виртуализации (в том числе и Hyper-V на базе Windows Server Datacenter).

Следующей статьей я расскажу о самой интересной возможности Azure Stack HCI — Hot Patching и поделюсь информацией, как установить данный функционал без покупки подписок Azure (в нашей стране их ведь купить невозможно? :)

А после поговорим о том, как довести до ума Azure Stack HCI, добавив ей полноценный рабочий стол, чтобы было комфортно администрировать, — таким образом можно будет использовать Azure Stack HCI как решение для виртуализации в небольшом офисе, где нет других серверов, нет подписок Azure и знатоков управления Server Core, с возможностью использовать Hot Patching.

Подписывайтесь, ставьте лайк, пишите комментарии, чего отдельно хотели бы увидеть в следующих статьях по Azure Stack и другим поделкам Microsoft!

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

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

Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.

📚 Читайте также:

• Как Kodak у Polaroid патенты украл;

• ХрюХрюКар: как перестать беспокоиться, начать создавать сервисы и обзавестись друзьями;

• Предательские фото: две истории о том, как ЦРУ по шакалистым фотографиям раскрывало ядерные секреты СССР.