Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Онлайн-форум hostobzor.ru _ Виртуальный сервер и Виртуальный Выделенный Сервер _ Выравнивание дисков гостевых систем и LV просроек.

Автор: iwant2beahoster 11.12.2011, 01:47

А скажите-ка уважаемые господа хостеры.
Кто нибудь заморачивается с выравниванием разделов гостевых систем на уровень страйпов raid?

Насколько я могу судить такое выравнивание поможет избежать проблем увеличения количества IOPs на одну операцию чтения.

Допустим у нас есть RAID на котором размер stripe равен 64kb. Поверх него мы кладём Logical Volume с размером блока 64kb. И поверх него лежит гостевая файловая система с размером кластера в самом критическом варианте 64kb.

Теперь давайте предположим, что все три слоя никак не выровняли и они лежат с небольшим смещением друг от друга.

Что теперь произойдёт при чтении или записи одного кластера файловой системы? Будет прочитано/записано 2 блока LV и 3 stripe с дисков. Колчество операций в 5 раз превышает требуемое. Или я что-то недопонимаю и путаю?

Ситуация чисто гипотетическая, но это самый плохой сценарий.

Если выровнять LV это в силах хостера то что делать с гостевой файловой системой не совсем понятно.
Делает ли кто-то из хостеров самостоятельное предразбитие гостевой файловой системы?

Второй вопрос касается дефрагментации. Помогает ли дефрагментация гостевой ОС снизить нагрузку на дисковую систему в условиях активной эксплуатации хранилища данных?

Автор: eSupport.org.ua 11.12.2011, 10:24

Использую SAS и SSD для таких случаев, проблем с IO не замечал.

Автор: iwant2beahoster 11.12.2011, 17:38

Цитата(eSupport.org.ua @ 11.12.2011, 10:24) *
Использую SAS и SSD для таких случаев, проблем с IO не замечал.
Для случаев каких? Получается, что ответ на первый вопрос - нет. Не выравниваете партишины гостевых систем.
И на второй с дефрагментацией - тоже нет.

Возможно, либо я излишне мнителен, либо вы не сталвикаетесь с ней по причине достаточной производительности ваших дисковых подсистем. Вы сами говорите, что используете SAS и SSD.
Я думаю начать с SATA дисков, а у них производительность пониже. Поэтому не очень хочется терять производительность, которой и так не много.

Проблема о которой я написал будет проявляться наиболее ярко если гостевая операционка будет читать данные блоками по 64 килобайта. Вернее блоками размер которых совпадает с размером stripe блока RAID контроллера.

А на счёт SSD у меня странное чувство, что с виртуалками (если не отдавать SSD как физическое устройство) возникнут проблемы. Речь о том, что по мере эксплуатации SSD "страдают" деградацией производительности. И тут я не понимаю, как пользовательская виртуалка отдаст команду TRIM виртуальному диску чтобы тот в свою очередь транслировал её в команду RAID контроллеру и далее SSD диску.

Автор: eSupport.org.ua 14.12.2011, 10:48

Как запорожец не тюнингуй, камаза из него не сделаешь.

Автор: freehoster 18.12.2011, 18:00

я думаю SATA в вашем случае подойдет
пока не стоит заморачиваться SAS и SSD

Автор: iwant2beahoster 19.12.2011, 01:09

Цитата(freehoster @ 18.12.2011, 18:00) *
я думаю SATA в вашем случае подойдет
пока не стоит заморачиваться SAS и SSD
Я в этом почти уверен, что для начала SATA мне достаточно. wink.gif

Но вопрос который интересовал меня - заморачивается ли кто-то выравниваем разных слоёв [Stripe - LV - гостевая файловая система] друг относительно друга чтобы минимизировать количество IOPs.

Но как я вижу никто не обращает на это внимания. А многие даже не догадываются о такой проблеме.

А использование RAID на SSD в качестве хранилища дисков виртуальных машин, я пока не вижу. Причины я описал выше. Единственное чем может помочь SSD - это кеширование между стораджем и реальными дисками. Но только тогда когда сам RAID контроллер сможет TRIM-ать неиспользованные блоки.

Автор: eSupport.org.ua 19.12.2011, 11:45

Цитата(iwant2beahoster @ 19.12.2011, 02:09) *

Но как я вижу никто не обращает на это внимания. А многие даже не догадываются о такой проблеме.


Водители камазов действительно не думают о грузоподъемности запорожца и способах ее повышения. Извините, что подвели.

Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)