Enterprise СХД крайне редко работают только на одну нагрузку (если мы не говорим про отдельные кейсы, когда СХД целиком отдается под один приклад типа АБС или mission-critical СУБД), обычно источником нагрузки является множество клиентов/приложений и т.д. Поэтому и тестировать их надо под такой же смешанной нагрузкой, ибо это обычно намного релевантнее и ближе к действительности.
А насчет HCIBench - это просто обвязка по автоматизации и GUI над теми же vdbench и FIO. Сам по себе он не генерирует никакую нагрузку - он просто деплоит worker'ы, создает конфигурационный файл в зависимости от того, что вы накликали в интерфейсе, разливает его воркеры, а потом собирает результаты. Ровно то же самое вы можете сделать в fio/vdbench руками. Я об этом тоже упоминал, но в первой части статьи :)
При этом вам абсолютно ничего не мешает развернуть хоть только одну ВМ через него и тестировать обычный datastore c SAN/NAS СХД. Сам профиль тестирования может быть тоже абсолютно любой - просто создайте конфигурационный файл fio/vdbench руками и загрузите в HCIBench. Но надо отметить, что работает он только с vSphere.
У большинства вендоров есть калькуляторы - вы забиваете (или отправляете) требуемые характеристики СХД (емкость, производительность, интерфейсы и т.д.), а в ответ получаете какую модель и в какой конфигурации надо купить для этого.
К тому же многие публикуют результаты тестов (сами или кто-то другой тестирует и публикует). Но вопрос в том - какое отношение имеют тесты, проведенные кем-то другим, по их методике, под их нагрузкой и в их конфигурации для конкретно вашего случая и ваших задач? В общем случае, никакого. Поэтому и берут (точнее должны брать) системы на тесты, чтобы проверить не коня в вакууме, а провести релевантный для конкретно вашего случая тест.
А чтобы не было "ой, да вы неправильно всё протестировали" согласуйте методику тестирования ДО её проведения и всё.
"болевые точки VMware" в 95% случаев — это отсутствие базовых знаний по работе с продуктом и отсутствие навыков чтения документации и Best Practices. Если прям очень-очень надо полностью исключить переподписку и все прочее связанное с виртуализацией (обычно не надо), то для получения 99%+ процентов производительности ВМ по CPU/RAM по сравнению с bare-metal достаточно нажать несколько кнопок в GUI, которые, по сути, выключают scheduler и переключение контекста (см. настройки Latency Sensitivity). Для тюнинга вывода-вывода делает еще несколько настроек (см. pvSCSI, HPP, LRO, InterruptThrottle, Coalescing), которые обычно описаны в документах под названием "Best Practices for XXX". Принципы работы гипервизора с ресурсами, а также многое другое, подробно объяснено и разжёвано в замечательной книге VMware Host Resources Deep Dive (которая доступна в том числе бесплатно вот тут - https://www.rubrik.com/resources/white-papers/19/host-resources-deep-dive-ebook)
COSTOP у вас возникнет в таком случае, только если на одном хосте работает несколько таких больших ВМ, и поэтому они поочередно ждут выполнения друг друга (точнее высвобождения нужного числа ядер). Если же у вас ВМ одна, то ничего не мешает сделать её больше одного физического CPU (да, понятно, что там возникнут задержки из-за NUMA, но они ровно так же возникнут и на физике). Тут скорее рекомендация несколько другая - не надо делать ВМ больше, чем её реально требуется (например, выдавая 36 ядер при том, что приклад реально потребляет, скажем, 12, в надежде, что "ну так мы точно узкого места в CPU сможем избежать") + не надо делать ВМ размером во весь хост, ибо на части ядер работает сам гипервизор и его ядерные процессы, а на другой части ядер обрабатывается ввод-вывод самой ВМ (vNIC, pvSCSI, etc).
Подписочная модель и наличие облачных серверов лицензирования - принципиально разные вещи. У того же VMware, подавляющее большинство продуктов (которые лицензировались, как подпиской, так и бессрочными лицензиями) работали без доступа в интернет (dark site). Просто, потому что нет облачных серверов лицензирования, а ключи (в том числе, на ограниченное время, т.е. на подписку) проверялись в самом продукте онпрем.
Ну как обычно "it depends", но в среднем если сравнивать опции сервера+vSphere+СХД и сервера+vSphere+vSAN, то зачастую получается, как минимум, сравнимые величины при доп. плюшках со стороны HCI и/или несколько дешевле, но это при учете, что мы говорим про MidRange сегмент внешних СХД, а не LowEnd и Synology/QNAP/etc. Если мы сравниваем чисто "полки", то тут все раньше действительно было не особо, но с появлением HCI Mesh в 7.0U2, где больше не требуется покрывать vSAN лицензиями compute-only кластера, то вполне себе может сложится экономика. Берем 4-8 (в зависимости от требований) 2U серверов, забиваем их SSD, ставим по 1 процессору в каждый и подключаем их к текущей vSphere инфраструктуре. Но это, как обычно, надо брать и аккуратно считать.
Да дело то даже не в 100%. А в том, что вы заменили компонент от которого зависит 95% результата при нагрузочных тестах. И зачем то провели это самое нагрузочное тестирование. Если вы на "не 100% поддерживаемой конфигурации" проводили функциональные тесты или тесты на отказы - я бы ещё понял, но не в этом случае.
Основная проблема данной статьи, что вы взяли unsupported конфигурацию, которая концептуально не подходит для vSAN, а так же которую вы не планируете (по вашим словам) использовать в проде и получили какие-то результаты (которые, очевидно, сильно ниже хуже, которые будут в целевой конфигурации). Какой в них смысл, если это нельзя и никто не будет использовать? Ну и во-вторых тут много концептуальных огрехов в самом тесте, которые приводят к странным результатам и совершенно не корректным выводам типа "падения производительности после заполнения на 80%" (что у vSAN вовсе не так, и вы, скорее всего, просто путаете active workload set и % заполнения datastore).
Enterprise СХД крайне редко работают только на одну нагрузку (если мы не говорим про отдельные кейсы, когда СХД целиком отдается под один приклад типа АБС или mission-critical СУБД), обычно источником нагрузки является множество клиентов/приложений и т.д. Поэтому и тестировать их надо под такой же смешанной нагрузкой, ибо это обычно намного релевантнее и ближе к действительности.
А насчет HCIBench - это просто обвязка по автоматизации и GUI над теми же vdbench и FIO. Сам по себе он не генерирует никакую нагрузку - он просто деплоит worker'ы, создает конфигурационный файл в зависимости от того, что вы накликали в интерфейсе, разливает его воркеры, а потом собирает результаты. Ровно то же самое вы можете сделать в fio/vdbench руками. Я об этом тоже упоминал, но в первой части статьи :)
При этом вам абсолютно ничего не мешает развернуть хоть только одну ВМ через него и тестировать обычный datastore c SAN/NAS СХД. Сам профиль тестирования может быть тоже абсолютно любой - просто создайте конфигурационный файл fio/vdbench руками и загрузите в HCIBench. Но надо отметить, что работает он только с vSphere.
У большинства вендоров есть калькуляторы - вы забиваете (или отправляете) требуемые характеристики СХД (емкость, производительность, интерфейсы и т.д.), а в ответ получаете какую модель и в какой конфигурации надо купить для этого.
К тому же многие публикуют результаты тестов (сами или кто-то другой тестирует и публикует). Но вопрос в том - какое отношение имеют тесты, проведенные кем-то другим, по их методике, под их нагрузкой и в их конфигурации для конкретно вашего случая и ваших задач? В общем случае, никакого. Поэтому и берут (точнее должны брать) системы на тесты, чтобы проверить не коня в вакууме, а провести релевантный для конкретно вашего случая тест.
А чтобы не было "ой, да вы неправильно всё протестировали" согласуйте методику тестирования ДО её проведения и всё.
Я вот тут не много писал об этом Enterprise Storage Synthetic Benchmarking Guide and Best Practices. Part 2. Success Criteria and Benchmarking Parameters.
Недавно опубликовали прекрасный инструмент для мониторинга и управления сертификатами (включая Solution Users) - vCert (virtham.us)
"болевые точки VMware" в 95% случаев — это отсутствие базовых знаний по работе с продуктом и отсутствие навыков чтения документации и Best Practices. Если прям очень-очень надо полностью исключить переподписку и все прочее связанное с виртуализацией (обычно не надо), то для получения 99%+ процентов производительности ВМ по CPU/RAM по сравнению с bare-metal достаточно нажать несколько кнопок в GUI, которые, по сути, выключают scheduler и переключение контекста (см. настройки Latency Sensitivity). Для тюнинга вывода-вывода делает еще несколько настроек (см. pvSCSI, HPP, LRO, InterruptThrottle, Coalescing), которые обычно описаны в документах под названием "Best Practices for XXX". Принципы работы гипервизора с ресурсами, а также многое другое, подробно объяснено и разжёвано в замечательной книге VMware Host Resources Deep Dive (которая доступна в том числе бесплатно вот тут - https://www.rubrik.com/resources/white-papers/19/host-resources-deep-dive-ebook)
COSTOP у вас возникнет в таком случае, только если на одном хосте работает несколько таких больших ВМ, и поэтому они поочередно ждут выполнения друг друга (точнее высвобождения нужного числа ядер). Если же у вас ВМ одна, то ничего не мешает сделать её больше одного физического CPU (да, понятно, что там возникнут задержки из-за NUMA, но они ровно так же возникнут и на физике). Тут скорее рекомендация несколько другая - не надо делать ВМ больше, чем её реально требуется (например, выдавая 36 ядер при том, что приклад реально потребляет, скажем, 12, в надежде, что "ну так мы точно узкого места в CPU сможем избежать") + не надо делать ВМ размером во весь хост, ибо на части ядер работает сам гипервизор и его ядерные процессы, а на другой части ядер обрабатывается ввод-вывод самой ВМ (vNIC, pvSCSI, etc).
Подписочная модель и наличие облачных серверов лицензирования - принципиально разные вещи. У того же VMware, подавляющее большинство продуктов (которые лицензировались, как подпиской, так и бессрочными лицензиями) работали без доступа в интернет (dark site). Просто, потому что нет облачных серверов лицензирования, а ключи (в том числе, на ограниченное время, т.е. на подписку) проверялись в самом продукте онпрем.
Ну как обычно "it depends", но в среднем если сравнивать опции сервера+vSphere+СХД и сервера+vSphere+vSAN, то зачастую получается, как минимум, сравнимые величины при доп. плюшках со стороны HCI и/или несколько дешевле, но это при учете, что мы говорим про MidRange сегмент внешних СХД, а не LowEnd и Synology/QNAP/etc. Если мы сравниваем чисто "полки", то тут все раньше действительно было не особо, но с появлением HCI Mesh в 7.0U2, где больше не требуется покрывать vSAN лицензиями compute-only кластера, то вполне себе может сложится экономика. Берем 4-8 (в зависимости от требований) 2U серверов, забиваем их SSD, ставим по 1 процессору в каждый и подключаем их к текущей vSphere инфраструктуре. Но это, как обычно, надо брать и аккуратно считать.
Да дело то даже не в 100%. А в том, что вы заменили компонент от которого зависит 95% результата при нагрузочных тестах. И зачем то провели это самое нагрузочное тестирование. Если вы на "не 100% поддерживаемой конфигурации" проводили функциональные тесты или тесты на отказы - я бы ещё понял, но не в этом случае.
Основная проблема данной статьи, что вы взяли unsupported конфигурацию, которая концептуально не подходит для vSAN, а так же которую вы не планируете (по вашим словам) использовать в проде и получили какие-то результаты (которые, очевидно, сильно ниже хуже, которые будут в целевой конфигурации). Какой в них смысл, если это нельзя и никто не будет использовать? Ну и во-вторых тут много концептуальных огрехов в самом тесте, которые приводят к странным результатам и совершенно не корректным выводам типа "падения производительности после заполнения на 80%" (что у vSAN вовсе не так, и вы, скорее всего, просто путаете active workload set и % заполнения datastore).