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

но цифры не сохранились насколько я помню, как и метода

Я немного про другое, ибо был эпизод. Холодная стори не для паблика.

я к тому, что по моему опыту там все не так очведино - на 4K 100% read и 3-way миррор S2D реально очень быстр (быстрее того же vSAN). Но стоит ему вместо этого подать сложную комбинацию блоков на вход типа большие блоки на чтени + изредка прилетающие большие блоки на запись и т.д., то его преимущество резко снижается и он становится заметно медленее

и я вообще не про то, кто быстрее - vSAN или S2D - это бессмысленный и бестолковый спор. Мне просто не нравится логика - система безумно быстра на синтетических профилях 4К, поэтому она будет безумно быстра под какой-нибуть Oracle.

Цифры сохранились. Мы на том же железе, кстати, vSAN собрали (и он уже в бою под Кубер-как-Сервис). Даже думали померять письками vSAN с S2D на конкретном железе. Но не стали, тк ссориться с вендорами - такое себе (слишком провакационно, да и VMware не отрицает скорость S2D)

ну при встрече обсудим

Заведем кейс в поддержку и (сюрприз!) супермикро оперативно отреагирует. Второй момент (исходя из особенностей решения): да и хуй с ним!

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

мой опыт показывает, что в зависимости от профиля нагрузки и конфигурации стенда можно сделать то или иное решение заметно быстрее другого. Я тоже участвовал в тесте vSAN и S2D на одном железе.

Переслал

С рэндомом самая жопа. Но это всегда и везде так. По vSAN'у мы обломались с отсутствием поддержки pMem и RDMA (в сферу уже подвезли, кстати).

ИМХО, жопа - со смесями блоков. у всех СХД. молотит у вас 64к в среднем, а потом 1% всех запросов 1MB блок на запись. Который запоняет все буферы, вешает очередь обработки запросов и т.д.

толку нет от pMEM под кэш. Разница по цене $/GB с Optane P4800X - огромная, а разница про производительности - нет. Поэтому оно и не поддерживается для vSAN (хотя работает). Аналогично с RDMA - если сравнивать разницу у S2D в вариантах с RDMA и без - там разница огромная. для vSAN - несколько десятков %, потому что стек обработки IO уже очень маленький и в самом ядре.

Да. В тестах все всегда охуенно. Про Оракл не скажу, тк (опять же почему именно под DBaaS MS SQL это пилилось) это целиком МСный стек с вполне внятными рекомендациями (но есть нюансы)

MS SQL - 64k. Но бывает всякое. Повторюсь: весьма специфичное и узкое решение.

Ага. Приехали на то, что оптан натурально большие цифры давал. Разбирались долго - с пМемом проблемы. Второе: vSAN досих пор не поддерживает RDMA (vSphere 7 - да). Тч он там прироста даст примерно нихуя.
Третье - ели с2д вообще без кэша собирать, то при определенных условиях (расположение ВМ на хосте/томе) показатель тоже будут ебейшие, но вопрос возникают как NVMe это будет переживать и сколько прослужат диски!?😉
Но факт: с2д без нвме смысла не имеет от слова совсем. Производительность на порядки проседает.

именно по этому в статье под названием «Как мы разгоняли кластер для нагруженных баз Microsoft SQL и получали заветные 200 000 IOPS»  я ожидал увидеть установку и настройку MS SQL на Hyper-V и S2D согласно  best practices и тесты под каким-нибуть Hummer DB.  Было бы очень и очень интересно почитать и посмотреть (без сарказма). И еще раз, я не пытаюсь тут накидывать на S2D, на результы тестов, на статью в целом - с ними все ок. Вопрос только в заголовке и фразах типа «Я покажу, на каком железе, софте и конфигурации сети мы проводили тесты быстродействия БД». О чем сообственно и тоже говорят в первых комментариях

Ну здесь сову на глобус натянули. Смотри, у меня статья будет по моему выступлению и там как раз это. Мб с Серегой в третьей части про это и напишем вместе.

Так-то согласен. Выглядит, как сова на глобусе.