Как стать автором
Обновить

Комментарии 19

Спасибо за статью. Как раз скоро с vSphere возиться прийдется
Работаем уж на ESXi, хорошая система, а по поводу виртуализации один вопрос. Тут говориться о поддержке 32- и 64-разрядные версии SUSE Linux Enterprise Server 10 и выше, а поддерживаеться ли OpenSUSE 12.X?
В списке совместимости open SUSE совсем не заявлена, но в сети есть отзывы, что работает, хоть и не с полпинка.
Спасибо за статью!
Имхо, «тонкие» диски допустимо использовать в промышленной среде, если машина не требует большого количества iops. И это единственная опция при использовании NFS без поддержки VAAI. Если верить документации вендора, то снижение производительности при работе с тонкими дисками незначительно.
Если нужно максимум скорости дисковой подсистемы, то может быть имеет смысл использовать RDM?
RDM диски хорошо использовать, к примеру когда вы кладете на LUN СХД базу данных, а сама СХД умеет делать снепшоты данной БД, данная фича будет вам полезна. Или вы можете использовать RDM, если надо перецеплять ту же БД от одной ВМ к другой.
Что мешает перецеплять vmfs-том от одной ВМ к другой?

По поводу производительности нашел сравнение от VMware, там сравнивается VMFS и RDM еще на ESX 3.0, старовато, но хоть что-то. Так вот, производительность примерно равна, плюс-минус 5 процентов примерно.
Так что особого выигрыша тут тоже не получишь.
Ну, и посвежее, сравнение RDM и VMFS на ESXi 4.1, результат примерно равный.

Conclusion: VMFS and RDM have similar performance. Don’t choose RDM for performance.
Мы все любим и уважаем наших вендоров. Но, увы, из практики следует, что в подавляющем большинстве случаев использовать тонкие диски нерационально. Если свести минусы «тонких дисков», то это:

1. Если уж тонкий диск расширился, обратно его «прозрачно» не сожмешь.
2. Расширение тонкого диска — процесс трудно управляемый. Часты случаи, когда случайно расширившийся тонкий диск забивал весь том VMFS и, соответственно, вызывал сбои соседних машин.
3. Тонкие диски в момент расширения снижают производительность тома (хотя бы затраты на изменение метаданных, описывающих размер и расположение файлов машин). Причем заранее предсказать изменение быстродействия на конкретной производственной среде, опять же, сложно.
Кстати, в Hyper-V у тонких дисков есть еще один огромный минус, но это мы узнаем в следующей серии. :)
По-идее, в пятой версии vSphere с расширением тонких дисков на массивах с VAAI ситуация стала лучше благодаря использованию не классических SCSI блокировок, а механизма ATS. К тому же, в версии 4.x ESX(i) старался прогнозировать блокировки и лочить лун для одного хоста сразу на несколько его операций, тем самым снижая общее количество локов.

Да и при правильном сайзинге хранилища разрастание одного-двух тонких дисков никак не должно выбирать всё свободное место. Реальные проблемы скорее можно получить при неожиданном массовом расширении дисков нескольких вм на одном датасторе.

Просто применяя тонкие диски не следует ждать чудес, а грамотно использовать их возможности. В нашем облаке они используются без каких-то серьёзных проблем с производительностью.
«Если нужно максимум скорости дисковой подсистемы, то может быть имеет смысл использовать RDM?»

Как правильно заметил коллега, RDM почти не отличается по производительности от VMFS (по личному опыту разница составляет в среднем 5-7%). Использовать RDM есть смысл, только когда машине нужно отдать огромный, непрерывный объем дискового пространства (более 2 терабайт неразделяемых данных). Или для случаев, когда без RDM никак не обойтись (приложения, требующие прямого доступа к диску, например, некоторые варианты кластеров).
Хорошая статья, вот бы такую же про Hyper-V — мы на ней всю свою «тучу» строим).
Если уже строите, так может сами готовы такое по Hyper-V написать, нет?
Я, наверное, не совсем корректно высказался, не строим, а уже год как эксплуатируем. Но сам написать такое не готов, т.к. тему производительности не копали еще, но точно могу сказать, что проблемы с ней есть и через некоторое время будем их решать. Если будет положительный опыт и время+желание поделиться, тогда обязательно это сделаю).
А какие проблемы, если не секрет? Как ни странно, в некотором смысле Hyper-V «сложнее», чем vSphere – чтобы добиться от нее максимальной отдачи, приходится прикладывать гораздо больше усилий.
Ну мы глубокую диагностику не проводили еще, а предварительно грешим на дисковую подсистему.
А можно чуть подробней? Как много физических хостов в кластере? Используете ли CSV (который Cluster Storage Volume)?
«Кластер» маленький (я тучка, тучка, тучка, а вовсе не медведьоблако) — три физических сервера. СХД еще нет, все на винтах физических хостов живет. Про CSV вот сейчас от Вас узнал).
Я так понимаю единого кластера в том виде, в каком он представлен в Hyper-V у вас пока еще нет за неимением общего хранилища. В этом случае на «проблемных» хостах стоит провести классический мониторинг нагрузки средствами ОС — нагрузка на ЦП, длинна очереди диска, длинна сетевой очереди. Из специфических для виртуальной среды параметров обратите внимание на время ожидания виртуальной машиной процессора — если оно будет слишком большим имеет смысл «развести» машины с большим количеством виртуальных процессорных ядер между разными хостами. Если соберетесь строить полноценный кластер, то можем помочь уже более конкретными советами — выбором хранилища, настройкой хостов под ваши нужды.
Да, Вы правы. За советы спасибо — помониторим данные показатели. Ну и буду иметь в виду у кого можно проконсультироваться.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий