Интересно. У нас основной ЦОД в Румынии и мы в топ 20 крупнейших аккаунтов, про диски вообще не задают вопросы, просят TSR в случае с vsan (если реально физика то там SAE автоматом всё заводит и отправляет) и просто отправляют замену

Буду иметь ввиду для проектов в РФ что не все так удобно

сенкс

1. Много доп сервисов, которые можно совмещать там же - журналирование, мониторинг, компоненты интеграции, можно средствами виртуализации бекапить/реплицировать/высокая доступность
2. Разные контуры изолировать вместо отдельного набора железа, возможно нагрузка в разное время типа сбора данных днем hadoop+hdfs, ночью hdfs+spark гонять, тоже самое шарить gpu
3. Абстракция от конфигурации, тк рекомендация все таки одинаковые конфигурации узлов иметь
4. Легче добавить как сервис в какой-нибудь оркестратор

Хотя наверно если реально можешь утилизировать, то смысла меньше, хотя с другой стороны чем больше данных и понимаешь их, находишь закономерности и тд, их становится меньше, куда потом железо девать?)

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

Ну сперва все собирают, потом вон пункт рядом в той же таблице «ИИ» и данных меньше должно стать, но это не точно)

В догонку: https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2852027

🔫 Любовь кикнут — вернуть этого пользователя можно только разбаном в настройках чата.

Проголосовавшие за кик:
@Victor_Konovalov, @Konstantin_t, @ShaulZel
При поддержке Золота Бородача

Ну да. Всан не гарантирует 100% верных данных, потому что ошибки чексумм могли висеть целый год

Судя по статье)

Не так. До 7u1c надо было, чтобы возникли silent error в обоих (или всех трех  для ftt=2) копиях данных одного и того же 4K блока, к которому не обращались целый год. В противном случае, проверка чек-сумм делается при каждом чтении, и когда в одном из блоков она будет обнаружена, то он будет помечен сбойным, чтение пройдёт из второй копии и сбойный блок будет переписан.

Кстати, при задачах типа rebalance, rebuild, data evacuation тоже чек суммы проверяются. Поэтому нужно чтобы их не только приложение/ос/бекап целый год эти данные ни разу не читали, так ещё чтобы служебные операции с ними тоже не проходили.

Ну вот для это чексуммы и нужны, чтобы быть уверенным, что данные всегда корректны на диске

А если это не так даже на пару минут, то возникает вопрос, а зачем такие чексуммы нужны

Всмысле не так на пару минут? Ошибки могут возникать. Они будут обнаружены при чтении (классическая детектируемая, но не корректируемая ошибка), поэтому будут прочитаны корректные данные со второй копии, а эти переписаны. На выходе, приложение получает верные данные, ошибка исправлена.

Ламерский вопрос: в гибридном режиме ёмкость ссд используется чисто как кеш или как быстрый tier? Простым языком, ёмкость ссд добавляется с свободному месту?

Первая половина вопроса не соответствует второй