в тестах ипосы нечемпионские

тот же DDN показывает более интересные результаты, в своих кейсах

фишка не только же в иопсах. доп. функциональность.

У нас видимо слишком разные понимание о том, что такое базовое технические описание и принципов работы (и, поверьте, это я ещё не самый большой зануда), ровно как описание use cases, потому что, когда я вижу общие слова про "оптимизацию tco" без указания чего именно (вот vmware тоже по сокетно лицензируется и как эта штука мне поможет?) и каким образом, мне хочется или спросить ещё раз (как? Почему? Пример?) или просто уйти. В данном случае, я воспользуюсь вторым вариантом.

Поможет распилить в два раза больше денег 🤗

Кстати на тему лицензирования. Может мне кто-то объяснить (пожалуйста), мелкософты реально проверяют все ли ядра были залицензированы, когда винда крутится внутри ВМ которой отданы 4 vcpu?

Николай вы ставите очень правильные вопросы, и суть в том, что вот такой Технический Маркетинг в виде чёрного ящика, без детализации отлично завоевывает Энтерпрайз  и прочих Лохов, которые ведутся на маркетинговые крючки. И таких заказчиков великое множество потому что у них технари слабые и не умеют системно, разумно и последовательно мыслить.

В Enterprise (если мы про тот самый кровавый) ОГРОМНЫЙ консерватизм и лозунг "мой дед так делал, мой отец так делал и я так делать буду". Плюс требования в каждом первом проекте привести референс из той же отрасли, из той же страны и на масштабе в пару раз (если не на порядок) превышающий целевое значение для заказчика. Плюс ЖЁСТКИЕ требования к совместимости и до тех пор пока некая штука не будет в списке совместимости Microsoft/Oracle/RedHat/etc это никто купить не сможет. Плюс требования по интеграции с системами автоматизации, безопасности, мониторинга, etc. ИМХО, средний бизнес, у которого, с одной стороны, уже чуть-чуть денег есть, но компетенций и требований нет - более подходящий случай. Ещё более часто такие штуки делают под конкретного заказчика уровня fortune-500 с конкретным (очень вырожденным и странным) кейсом, в после этого пытаются масштабировать, но смотри пункт 1. Ну и плюс в enterprise - очень даже достаточно грамотных технарей. Неграмотные тоже встречаются, но это как и везде.

По не проверчет, проверчющий может :)

Доброго времени суток.
Подскажите пожалуйста существуют ли какие-то файловые системы позволяющие одновременно нескольким серверам дозаписывать один и тот же файл? (речь про голосовые прокси-сервера VoIP, записывающие в некий промежуточный файл чанки голоса по 125 мс, а после завершения разговора одна из нод немного доделывает файл до wav-формата и перекладывает в некий общий сторадж)

Сначала думал в сторону GlusterFS, но про него пишут что не рекомендуется к применению при необходимости "высоких показателей IOPS и прогнозируемой задержкой IO". Я не знаю как это оценить, в том плане, что не знаю свыше каких показателей в потребностях IOPS и IO для глюстера уже много и лучше не надо. Есть информация по действующей хранилке с другой системой записи, которая позволяет примерно прикинуть сколько может потребоваться IOPS и IO на новой системе.

мы можете легко проверить свой кейс с гластером. Его развернуть - дело 10 минут.

NFS/SMB + любая ФС, CephFS если хочется отказоустойчивости и "родной" кластерности

>CephFS если хочется отказоустойчивости и "родной" кластерности
и секеся не хватает )

Ой, да нет там особого секса если не упарываться спидами (то есть не создавать 50K файлов в одном каталоге)

OCFS2 еще можно.

у меня лет 10 назад на OCFS2 смотрело штук 30 серверов в одни и те же LUN’ы на больших файлах(виртуализация) проблем не было.

что-то вспомнился срачик, про атомарность записи сектора на диск
https://www.ixbt.com/storage/hdd-smart-testing.shtml#n24

А где там про атомарность

ну просто был вопрос, что будет в секторе, если во время записи выключить питание.

В любой s3 писать чанки, потом качать и клеить. И туда же результат