Скорее всего тут имеется ввиду т.н компануемая инфраструктура. Если кратко и грубо говоря, то есть общая высокоскростная фабрика (eth 100G/200G/400G), в которую подключены вычислительные узлы и ресурсы хранения, ресурсы хранения представляют собой EBOF'ы и EBOD'ы (как JBOD'ы, только отдают накопители наружу через NVMe over Fabric) и это все управляется через SDN и SDS.
Пример EBOF'a это например OpenFlex от Western Digital.
Производительность данного теста упирается в скорость работы самих дисков, их микроконтроллеров и подсистемы памяти процессора. Реальная вычислительная производительность процессорного ядра там неважна
Это не совсем так, производительность процессорного ядра имеет значение, т.к. тестируются синдромные рэйды (в данном случае 6й рэйд) и производительность процессорного ядра влияет на расчет синдромов.
На мой взгляд, использование производительности SDS в качестве примера производительности эльбруса несколько нерелевантно, хотя бы тем, что в случае sds код вручную векторизован и оптмизирован под этот самый эльбрус.
Если бы мы включили RAM-кэш, то результаты были бы заметно лучше, но тогда тест был бы не совсем честным.
Тогда бы вы наверное тестировали ваш write-back cache так. Вы не используете параметр offset_increment при seq нагрузке.У вас все потоки пишут\читают одни блоки. Переписывались бы одни сегменты write-back кэша, это дало бы невероятный буст производительности на запись в многопотоке.
Но даже без кэша непонятно насколько считать результаты seq нагрузки релевантными, вы читаете\пишите всеми потоками одни блоки.
Я бы на вашем месте смотрел в сторону Proxmox'a или oVirt'a вместо ESXi (который очень ограничен в бесплатной версии). Proxmox и oVirt являются так же решениями Enterprise уровня, и дадут полное представление о гипервизорах и навыки для работы с гипервизорами.
Почему бы просто не использовать mailcow?
Время для перехода на brave?
Скорее всего тут имеется ввиду т.н компануемая инфраструктура. Если кратко и грубо говоря, то есть общая высокоскростная фабрика (eth 100G/200G/400G), в которую подключены вычислительные узлы и ресурсы хранения, ресурсы хранения представляют собой EBOF'ы и EBOD'ы (как JBOD'ы, только отдают накопители наружу через NVMe over Fabric) и это все управляется через SDN и SDS.
Пример EBOF'a это например OpenFlex от Western Digital.
Я бы к списку популярных TSDB добавил бы еще VictoriaMetrics.
Это не совсем так, производительность процессорного ядра имеет значение, т.к. тестируются синдромные рэйды (в данном случае 6й рэйд) и производительность процессорного ядра влияет на расчет синдромов.
На мой взгляд, использование производительности SDS в качестве примера производительности эльбруса несколько нерелевантно, хотя бы тем, что в случае sds код вручную векторизован и оптмизирован под этот самый эльбрус.
Тогда бы вы наверное тестировали ваш write-back cache так. Вы не используете параметр offset_increment при seq нагрузке. У вас все потоки пишут\читают одни блоки. Переписывались бы одни сегменты write-back кэша, это дало бы невероятный буст производительности на запись в многопотоке.
Но даже без кэша непонятно насколько считать результаты seq нагрузки релевантными, вы читаете\пишите всеми потоками одни блоки.