OpenVZ Forum


Home » International » Russian » Предпочтительная схема использования физических диск
Предпочтительная схема использования физических диск [message #40594] Sat, 04 September 2010 12:26 Go to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: *static.corbina.ru
Сейчас есть N отдельных физических серверов. Стоит задача перенести их в виртуальное окружение (не важно какое).

На текущих серверах стоит 3 нагруженные СУБД, почтовый сервер и куча задач, на много реже использующих диск. Большинство серверов однодисковые, за исключением СУБД, где используется по два диска для разделения нагрузки по IO.

Новое железо будет представлять из себя кластер из двух физических серверов, а диски будут синхронизироваться посредством DRBD. На каждом будет 8 SAS 15k rpm дисков. Встал вопрос, как их использовать для лучшей производительности.

Что будет лучше?
1. Выделять для нагруженных задач по 1-2 физическому диску без RAID.
2. Собрать диски в 4 RAID1, выделить по одному на каждую нагруженную задачу и "досыпать" к ним мелких.
3. Собрать все диски в один RAID 10 для общего использования.
4. Есть идеи получше?


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Re: Предпочтительная схема использования физических ди [message #40597 is a reply to message #40594] Sat, 04 September 2010 17:36 Go to previous messageGo to next message
sHaggY_caT is currently offline  sHaggY_caT
Messages: 144
Registered: August 2008
Location: Moscow, Russian Federatio...
Senior Member

From: *shaggy-cat.ru
RXL_ wrote on Sat, 04 September 2010 08:26

4. Есть идеи получше?



Если серверов <=4, взять "четыреххвостовый" DAS, на нем развернуть raid60 из SAS, а может и SATA, если "голова" достаточно мощная, и кэш большой.

DAS не так уж и дорого стоят, да и SAN начального уровня тоже(если на iscsi), а при наличии двух голов, вероятность выхода DAS/SAN из строя очень мала.
При наличии некоторого бюджета, можно взять две полочки, и настроить репликацию (не средствами полочки - low end железки такого не умеют, а средствами того же drbd (резервная в пассивном режиме), mdraid, или вообще rsync

drbd же с локальными дисками страшный тормоз


IT-outsource for UNIX servers,
http://ha-systems.ru

[Updated on: Sat, 04 September 2010 17:37]

Report message to a moderator

Re: Предпочтительная схема использования физических ди [message #40599 is a reply to message #40597] Sat, 04 September 2010 18:04 Go to previous messageGo to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: *static.corbina.ru
sHaggY_caT, к сожалению, взять ничего не получится - бюджет минимальный (около 400к руб.) и одобрено (и уже включено в бюджет на следующий год) только эти два сервера под кластер. По этому ищу оптимальное решение в этих рамках.

N ~10.

DRBD не такой уж тормоз, если переключить его на протокол B или даже A. Потом, операции чтения там локальные.


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

[Updated on: Sat, 04 September 2010 18:17]

Report message to a moderator

Re: Предпочтительная схема использования физических ди [message #40604 is a reply to message #40594] Sun, 05 September 2010 06:45 Go to previous messageGo to next message
esetnod is currently offline  esetnod
Messages: 27
Registered: July 2010
Junior Member
From: *kuzbass.net
Недавно тестировал на бюджетке, i7 975, 12 ram, 4 x sata на адаптеке.

2 x raid1 на 2 раздела, и по ним динамически распределять VE дает прирост при большом количестве контейнеров.

4 x raid10 в 1 раздел, подойдет под малое кол-во vds, будет прирост производительности в дисковой подсистеме.

А когда куча контейнеров буробит 1 массив, планировщик захлебывается временами.

--
4 sata под такую конфу всё равно мало, по моим расчетам, чтобы дать процессору с рамой открыть весь потенциал, на вышеописанный конфиг надо 8 x sata в 2 массива по raid10, или около того Smile

p.s. не совсем по теме, но вдруг будет полезной инфа.

[Updated on: Sun, 05 September 2010 06:46]

Report message to a moderator

Re: Предпочтительная схема использования физических ди [message #40606 is a reply to message #40604] Sun, 05 September 2010 07:08 Go to previous messageGo to next message
sHaggY_caT is currently offline  sHaggY_caT
Messages: 144
Registered: August 2008
Location: Moscow, Russian Federatio...
Senior Member

From: *shaggy-cat.ru
esetnod wrote on Sun, 05 September 2010 02:45
Недавно тестировал на бюджетке, i7 975, 12 ram, 4 x sata на адаптеке.

2 x raid1 на 2 раздела, и по ним динамически распределять VE дает прирост при большом количестве контейнеров.

4 x raid10 в 1 раздел, подойдет под малое кол-во vds, будет прирост производительности в дисковой подсистеме.

А когда куча контейнеров буробит 1 массив, планировщик захлебывается временами.

--
4 sata под такую конфу всё равно мало, по моим расчетам, чтобы дать процессору с рамой открыть весь потенциал, на вышеописанный конфиг надо 8 x sata в 2 массива по raid10, или около того Smile

p.s. не совсем по теме, но вдруг будет полезной инфа.


Контейнеры контейнерам рознь Smile У нас есть OVZ-ноды с Soft-зеркалом из двух SATA-дисков(офисные клиенты + часть своих сервисов), на одной из них почти 60 VE..
Вся эта конструкция дико тормозит по i/o при старте ноды и всех контейнеров, потом работает почти превосходно (две VE на этой ноде немного дергают диск)

Есть нода с 4 SATA в софт-зеркале raid10 и Core i7(Hetzner с его серверами из "писюков"), с хостинговыми VPS-ками(25 штук), она тормозит по i/o хронически и перманентно, а клиент (которому принадлежит сервер) до сих пор не понимает, что SAS рулит, клиенты как-то живут, и не уходят (там цены достаточно низкие)

Есть несколько нод с софт-зеркалом SAS(или рапторами), и несколько нод с raid10 SAS (хостинговые либо под тяжелые сервисы в офисах, вроде 1с-а): мы уже давно сделали вывод, чем дисковая быстрее, тем сервис работает устойчивее, быстрее, и тем больше "тяжелых" VE помещается на ноду, а SATA-диски лучше бы вообще не использовать нигде, кроме ультра-бюджетных конфигураций(лучше на CPU сэкономить!) но, имхо, хороший DAS/SAN все-таки может дать возможность их использовать за счет кэша под гигабайт и крутого контроллера.


IT-outsource for UNIX servers,
http://ha-systems.ru
Re: Предпочтительная схема использования физических ди [message #40607 is a reply to message #40604] Sun, 05 September 2010 07:14 Go to previous messageGo to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: *static.corbina.ru
esetnod, за информацию спасибо!

У вас планировщик очереди по умолчанию стоял - cfq? Попробуйте сменить. На локальных дисках с большими объемами перемещаемых файлов deadline дал меньше тормозов системы и более высокую среднюю скорость.

sHaggY_caT, мы SATA использовать не собираемся - только SAS. Разница заметна во всем, начиная от разницы между временами доступа и поиска для 7200 и 15000, не говоря уже о более совершенном протоколе SCSI и большей надежности SAS как электрического интерфейса.


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

[Updated on: Sun, 05 September 2010 07:22]

Report message to a moderator

Re: Предпочтительная схема использования физических ди [message #40608 is a reply to message #40606] Sun, 05 September 2010 07:16 Go to previous messageGo to next message
esetnod is currently offline  esetnod
Messages: 27
Registered: July 2010
Junior Member
From: *kuzbass.net
Quote:

Есть нода с 4 SATA в софт-зеркале raid10 и Core i7(Hetzner с его серверами из "писюков"), с хостинговыми VPS-ками(25 штук), она тормозит по i/o хронически и перманентно, а клиент (которому принадлежит сервер) до сих пор не понимает, что SAS рулит, клиенты как-то живут, и не уходят (там цены достаточно низкие)


Может быть по шине тормоза, из-за софтового? Возможности небыло сравнить на такой-же конфе хардверный и софтовый рейд.
Quote:

Есть несколько нод с софт-зеркалом SAS(или рапторами), и несколько нод с raid10 SAS (хостинговые либо под тяжелые сервисы в офисах, вроде 1с-а): мы уже давно сделали вывод, чем дисковая быстрее, тем сервис работает устойчивее, быстрее, и тем больше "тяжелых" VE помещается на ноду, а SATA-диски лучше бы вообще не использовать нигде, кроме ультра-бюджетных конфигураций(лучше на CPU сэкономить!) но, имхо, хороший DAS/SAN все-таки может дать возможность их использовать за счет кэша под гигабайт и крутого контроллера.



Быстроходные дороговаты, особенно для мелких компаний, вроде нашей Smile Пока довольствуемся рейдами из сата, с кешем на ssd Smile
Re: Предпочтительная схема использования физических ди [message #40609 is a reply to message #40607] Sun, 05 September 2010 07:19 Go to previous messageGo to next message
esetnod is currently offline  esetnod
Messages: 27
Registered: July 2010
Junior Member
From: *kuzbass.net
RXL_ wrote on Sun, 05 September 2010 03:14
esetnod, за информацию спасибо!

У вас планировщик очереди по умолчанию стоял - cfq? Попробуйте сменить. На локальных дисках с большими объемами перемещаемых файлов deadline дал меньше тормозов системы и более высокую среднюю скорость.




Благодарю, попробую.
Просто как-то так сложилось, что deadline использую только когда диск помирать начинает Smile
Re: Предпочтительная схема использования физических ди [message #40612 is a reply to message #40608] Mon, 06 September 2010 06:25 Go to previous messageGo to next message
sHaggY_caT is currently offline  sHaggY_caT
Messages: 144
Registered: August 2008
Location: Moscow, Russian Federatio...
Senior Member

From: *shaggy-cat.ru
mdraid часто быстрее low-end аппаратных контроллеров Smile

по шине (SATA?) тормозов быть вообще не может, может возникнуть ситуация нехватки CPU (но вообще, такое бывает редко, если диски SATA)

У mdraid есть другой недостаток: у него нет батарейки и, соотвественно, write-back кэша, защищенного от сбоя, поэтому полностью безопасно и производительно его использовать только в конфигурации зеркала, так как в случае отличия метаданных в двух половинках зеркала, вторая из них(в BIOS вторая) засинкается о другую.

Что касается экономии на всем, я Вас прекрасно понимаю, но, имхо, лучше сэкономить, в сервере под OVZ, на CPU (так как с медленной дисковой он все равно будет молотить воздух в iowait), чем на дисковой.

Для совсем ультра-бюджета, да еще и ненагруженного (офисные SOHO-юзеры без тяжелых сервисов) мы сами используем софт-зеркало на SATA, но если есть хоть что-то тяжелое, имхо, SATA в /dev/null


IT-outsource for UNIX servers,
http://ha-systems.ru
Re: Предпочтительная схема использования физических ди [message #40614 is a reply to message #40612] Mon, 06 September 2010 07:10 Go to previous messageGo to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: 82.204.178*
Если все таки вернуться к начальному вопросы и пунктам 1-3. Что лучше?

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Re: Предпочтительная схема использования физических ди [message #40617 is a reply to message #40614] Mon, 06 September 2010 09:22 Go to previous messageGo to next message
sHaggY_caT is currently offline  sHaggY_caT
Messages: 144
Registered: August 2008
Location: Moscow, Russian Federatio...
Senior Member

From: *shaggy-cat.ru
имхо, raid10, но без drbd.
Лучше делать регулярно бэкап, а запасную платформу положить на полочку


IT-outsource for UNIX servers,
http://ha-systems.ru
Re: Предпочтительная схема использования физических ди [message #40618 is a reply to message #40617] Mon, 06 September 2010 10:23 Go to previous messageGo to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: 82.204.178*
Бекап не обеспечит быстрого переключения сервисов (в идеале вообще хотелось бы автоматизировать что можно). Как показала практика, выход из строя оборудования (в основном - диски и БП) происходит в 90% случаев либо в нерабочее время, либо вообще в выходные. Админы тоже люди - им отдыхать надо, а не бекапы заливать по ночам в свои выходные.

SAN не будет. Ну нету денег. Т.ч. давайте не будем выходить за рамки имеющегося. Се ля ви...

Недостатки DRBD (если рассматривать протокол C) я вижу в том, что операция записи совершается после подтверждения записи на удаленных узлах - так сказано в документации.
Задержка удаленной записи составит: прохождение большого пакета с блоком данных, запись блока удаленном диске, прохождение короткого блока с подтверждением. Также есть параллельная локальная запись. Фактическая задержка составит максимум из двух этих задержек. Т.е. возможны две ситуации в каждом конкретном случае записи: либо разницы между DRBD и локальным диском нет, либо есть - не в пользу DRBD. В среднем, это время передачи двух пакетов по сети. Без учета внутриядерных задержек (которые зависят от множества причин) это составит порядка 5 мкс.
Если же рассматривать ненадежные формы DRBD - протоколы B и A, то тормоза начнутся не раньше, чем позволит ширина выделенного под DRBD трафик канала.
Хочу заметить, что вышесказанное о RDBD для меня пока только теория. Надеюсь проверить на практике. Постараюсь сделать это заранее на какой-нибудь модели.

Потестил на двух машинах с SATA и 100 Mbit интерфейсами.
[root@test]# dd bs=1024k count=64 if=/dev/zero of=/dev/drbd0 oflag=direct
64+0 records in
64+0 records out
67108864 bytes (67 MB) copied, 7.00015 seconds, 9.6 MB/s

[root@test]# dd bs=256k count=256 if=/dev/zero of=/dev/drbd0 oflag=direct
256+0 records in
256+0 records out
67108864 bytes (67 MB) copied, 9.46926 seconds, 7.1 MB/s

[root@test]# dd bs=64k count=1024 if=/dev/zero of=/dev/drbd0 oflag=direct
1024+0 records in
1024+0 records out
67108864 bytes (67 MB) copied, 12.7353 seconds, 5.3 MB/s

[root@test]# dd bs=16k count=4096 if=/dev/zero of=/dev/drbd0 oflag=direct
4096+0 records in
4096+0 records out
67108864 bytes (67 MB) copied, 38.7679 seconds, 1.7 MB/s


Вполне ожидаемый результат - локальные диски также себя ведут при понижении копируемого блока - снижают скорость.
В общем, думаю, для нормальной скорости стоит собрать пару гигабитных интерфейсов в bonding rr и выставить для них MTU 9000.

Создал на drbd0 ext4, смонтировал и проверил время копирования с синхронизацией буферов 273 разномастных файлов (4к..10М) на общий объем 385899008: 11 МБ/с. Если не синхронизировать и оставить эту заботу системе, то процесс копирования происходит со скоростью чтения с источника.

Продолжение эксперимента. Переключил интерфейсы в гигабитный режим. Сразу скажу, что локальные диски на одной из машин офисного класса, да еще и необходимые для DRBD девайсы создавались через losetup, а второй сервер нагружен задачами.
Скорость записи ~670 МБ в ~500 файлах (в МБ/с):
на локальный диск напрямую - 66;
на DRBD с отключенным пиром - 52;
на DRBD в полной сборке - 44;
на DRBD в режиме primary diskless - 33.


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

[Updated on: Tue, 07 September 2010 06:00]

Report message to a moderator

Re: Предпочтительная схема использования физических ди [message #40625 is a reply to message #40618] Tue, 07 September 2010 11:21 Go to previous messageGo to next message
sHaggY_caT is currently offline  sHaggY_caT
Messages: 144
Registered: August 2008
Location: Moscow, Russian Federatio...
Senior Member

From: *shaggy-cat.ru
линейная запись/чтение != не равны случайной записи/чтению соотвествующим реальной нагрузке...



IT-outsource for UNIX servers,
http://ha-systems.ru
Re: Предпочтительная схема использования физических ди [message #40626 is a reply to message #40625] Tue, 07 September 2010 13:25 Go to previous messageGo to next message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: 82.204.178*
Естественно. Равно как не стоит ожидать от диска, дающего 100 МБ/с на линейной записи, такой же скорости на случайной.
Я лишь показал, что схема работает и не на столько хуже, чем хотелось бы Smile


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Re: Предпочтительная схема использования физических ди [message #40627 is a reply to message #40626] Tue, 07 September 2010 13:39 Go to previous messageGo to next message
sHaggY_caT is currently offline  sHaggY_caT
Messages: 144
Registered: August 2008
Location: Moscow, Russian Federatio...
Senior Member

From: *shaggy-cat.ru
Просто Ваш тест, это, имхо, сферический тест в вакууме Smile

Попробуйте лучше тот же dbench


IT-outsource for UNIX servers,
http://ha-systems.ru
Re: Предпочтительная схема использования физических ди [message #40633 is a reply to message #40627] Tue, 07 September 2010 18:06 Go to previous message
RXL_ is currently offline  RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
Senior Member
From: *static.corbina.ru
Уже тестирую Smile
Пробую со штатным патерном и 1, 4, 8, 16 и 32 активных процесса. Тест сперва на DRBD в полной сборке, а потом только на локальном диске.
Это на пару часов...

UPD: наивно было полагать, что это на пару часов. Smile
Сервера, которые я использую для тестов, можно освободить от прочих задач только с 21 до полуночи. Но от тестов не отказываюсь и потихоньку их продолжаю. Параметров для тестирования оказалось прилично. Чего только стоит no-md-flush и no-disk-flush.

Кстати, если я правильно понимаю, эти параметры не такие уж опасные: обе ноды получили свою копию данных, но только не сбросили их на диск. Я прав?


... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

[Updated on: Sat, 11 September 2010 08:08]

Report message to a moderator

Previous Topic: AMD vs Intel
Next Topic: Opevz, во время остановки контейнера пропадает сеть
Goto Forum:
  


Current Time: Fri Aug 23 19:34:22 GMT 2019