Comments 13
Главное достоинство централизованной СХД состоит в том, что надёжность хостов становится второстепенным фактором. Отказ хоста означает всего лишь перезагрузку виртуальных машин, даже если конкретный хост умер.
Если же в хосты ставить что-то, связанное с кешированием, возникает проблема: вы не можете сказать host-forget, потому что на хосте SSD, а на SSD остатки write-back кеша, без которых диск виртуальной машины превращается в тыкву.
Если же в хосты ставить что-то, связанное с кешированием, возникает проблема: вы не можете сказать host-forget, потому что на хосте SSD, а на SSD остатки write-back кеша, без которых диск виртуальной машины превращается в тыкву.
Я не очень понял тезис про тыкву, по тому что отключали мы «в принудительном порядке» ioDrive и виртуалки продолжали работать, скорость конечно падала, но на работоспособности в целом это никак не сказывалось.
Если я правильно понимаю, данное устройство схоже с ReadyBoost от Microsoft — кешируются данные на более быстрый накопитель, с которого затем происходит чтение. Запись же новых данных ведётся одновременно на СХД и устройство, без использования write-back кеша, что позволяет в любой момент отключать это решение.
А, пардон, значит не так понял. Если это wt-кеш, то ок, молодцы, правильное решение. Единственный вопрос, переживает ли оно дурную смерть кеширующего устройства (то есть не тупит ли подолгу). Если не тупит, то вообще замечательно.
Нет, «пропадание» кэша виртуалка переживает совершенно спокойно и не требует дополнительно вмешательства для нормализации её работы.
Если бы каждый раз, когда после заверения вендоров «оно переживает смерть оборудования без последствий для пользователей» и последующих проблем, давали денег, я бы уже миллионером был.
Не просто «отключили штатной командой». Что будет, если воткнуть туда «умирающее» устройство?
Впрочем, на самом деле, даже если всё свалится, то да, это будут минорные проблемы для VM, в этом смысле всё ок.
Не просто «отключили штатной командой». Что будет, если воткнуть туда «умирающее» устройство?
Впрочем, на самом деле, даже если всё свалится, то да, это будут минорные проблемы для VM, в этом смысле всё ок.
Я прекрасно понимаю о чём вы говорите, но я не вендор и тут они меня, к сожалению оставили наедине с манами и софтом, отказавшись отвечать на дополнительные вопросы о том как всё это устроено. Скажу даже больше, в данном случае есть ещё одна «точка отказа» работы кэша, т.к. сам ioTurbine является прослойкой между esxi и vm и представляет из себя виртуальную машину и если она падает — хосты знать не знают ни о кэше, ни о чём. У нас ioTurbine был развёрный на отделной от хостов, физической машине и было несколько случаев когда сервер с хостами загражлся быстрее чем машина с ioTurbine в итоге приходилось ребутить весь сервер, по тому что кэш к виртуалкам никак не хотел цепляться корректно, либо вообще хостовая машина не знала ни о какой ioTurbine (небыло соответствующей вкладки). Так что подводных камней хватает, как тоже развёртывание всего этого дела. Вот мы и интересуемся — есть ли потребители на данный продукт и стоит ли с ним работать плотнее, либо же работать в основном с железом.
read cache на большинстве СХД и так раздутый по максимуму (у нас, например, средний cached read ниже 80% не падает, а в нормальном режиме болтается в районе 96%).
Я могу сказать, какой вид IO самый ужасный и необоримый. Это ice read. Когда виртуалка раз в сутки что-то там читает. Или когда 30000 виртуалок раз в сутки (одновременно) начинают что-то читать.
Я могу сказать, какой вид IO самый ужасный и необоримый. Это ice read. Когда виртуалка раз в сутки что-то там читает. Или когда 30000 виртуалок раз в сутки (одновременно) начинают что-то читать.
Ээх… а под kvm такой штуки нет?
Очень бы пригодилось…
Очень бы пригодилось…
Используются карты ioDrive, т.е. блейдам не светит? Или есть варианты с обычными SATA/SAS SSD?
Sign up to leave a comment.
ioTurbine: повышение производительности систем виртуализации