Лет 20 назад, в 2004 году, когда я еще ходил в школу, и читал комиксы про всамделишные приключения сексуального вампира, системы хранения данных жили отдельно (за дорого и очень дорого), сервера отдельно. Только-только вышел SQL Server 2000 Service Pack 2 (SP2), кластеризация на уровне сервиса была у SQL (кто хочет, найдет статью Clustering Windows 2000 and SQL Server 2000, Brian Knight, first published: 2002-07-12) , и вроде, в Oracle RAC.
К середине 2010х ситуация постепенно изменилась. Производительность x86 выросла, цена за операцию упала. Со стороны классических СХД еще в 2015 в тех же 3Par стоял отдельный модуль для расчета чего-то-там, в Huawei Oceanstor v2 можно было покупать отдельный модуль LPU4ACCV3 Smart ACC module, но основная нагрузка уже считалась на x86 - HPE 3PAR StoreServ 7000 уже был на Intel Xeon. К 2019 Huawei перешел на Arm, точнее на Kunpeng 920.
Примерно в то же время, а точнее в 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 с 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 на второй (округленно).
На этом месте пока прервусь, надо подумать как сделать удобнее.
