К слову об nvme namespaces - берем одну nvme и делим на много неймспейсов, обходя ограничение по процессам на дисковую группу.

Помнится micron на своих nvme под миллион iops выжали на всане

nvme namespaces - прикольно, да. только немного муторно

Но развитие продукта строится чуть иначе. Есть X ресурсов. Их надо либо распределить по feature request, либо увеличить. Для этого делается простая штука - сначала формируется беклог из всех идей. "Надо увеличить максимальный теоритеческий perfomance", например, там есть. Дальше анализируется, а какой процент от X нам требуется, чтобы это сделать и что будет, если A) - это сделать,  B) - этого не сделать в разрезе новых заработанных или утеряных денег. Отдельно идут так называемые EPIC - фичи, которые нужны для стратегического (качественного, а не количественного) развития продукта.  А потом проводят ранжирование по эффективности. Когда кто угодно (я, партнёр, заказчик) приходит с новой идей, то его анализируют именно по этим критериям. Уверяю вас, что так строится разработка абсолютно любого продукта.

Только история в том, что производительность lsom, не является реальным ограничением.

Я готов (в том числе это моя работа) доносить фидбек с полей до PM. Но мне нужно понимать, как это сделать

Пример с nvme namespaces

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

Так никто вроде и не спорит) Сам работаю в софтостроительной компании, отлично понимаю

вот голимый нутаникс только-только родили правый клик мыши или только-только родили UEFI, но только для AHV

всё это давным-давно было на ESXi

Давайте не будем про нутаникс, пожалуйста

не то, чтобы правый клик - это show stopper для бизнеса 😄

Решили мы, что нам нужны жирные новые ноды от aws для vmc. Потому что это улучшает экономику, а значит повышает экономическую эффективность. Супер. Только вот выяснилось, что в тех узлах стоят мало, но здоровых ssd. Если ничего не менять, то мы потеряем 16TB capacity, что фигово. Стали думать что делать и выяснилось, что самый быстрый и простой способ получить много perfomance и эффективное место - нарезать namespaces на дисках, которые это поддерживают. Profit! И фича ушла в релиз

ну вот это хорошо, когда нашли такой выход. через год-полтора увидим и на on-prem версии явно 🙂

аяяй:)

Теперь кейс ( реальный, потому что я, честное слово, с этим приходил к PM). Хотим nvme namespace для обычных узлов. Они такие - зачем? Я говорю, ну чтобы емкость больших ssd не терять. - так возьми сразу маленький optane и в путь. А под capacity большие ri/tlc. - ну чтобы параллелизм больше сделать. - так сделай несколько DG. Это уменьшает домен отказа, упрощает масштабирование, просто управляется и эксплуатируется.

Шансы, разумеется, есть и они резко выросли, потому что если до этого трудрзатраты были x, то теперь x/y, ибо все равно для vmc уже сделали. Но я делаю ставку не на onprem даже, а для других гиперскейлеров типа azure, Google, ibm и Oracle - им тоже сильно проще одинаковые ssd пихать к хосты. Но так, как у них обычная версия esxi/vSAN, то сделают как нибуть в рамках rpq обычных билдов. А если вдруг для этого найдётся кейс в широком мире, то и без rpq сделают

Ну вот например твой кейс, что при vmotion место на целевой не vsan datastore  считается с ftt - приняли без вопросов и обещали скоро поправить, ибо косяк

о! я про это уже забыл. приятно слышать 🙂