Home » International » Russian » Предпочтительная схема использования физических диск
| Предпочтительная схема использования физических диск [message #40594] |
Sat, 04 September 2010 12:26  |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Сейчас есть 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  |
sHaggY_caT
Messages: 144
Registered: August 2008
Location: Moscow, Russian Federatio...
|
Senior Member |
|
|
| 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 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
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 |
esetnod
Messages: 27
Registered: July 2010
|
Junior Member |
|
|
Недавно тестировал на бюджетке, 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, или около того 
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 |
sHaggY_caT
Messages: 144
Registered: August 2008
Location: Moscow, Russian Federatio...
|
Senior Member |
|
|
| 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, или около того
p.s. не совсем по теме, но вдруг будет полезной инфа.
|
Контейнеры контейнерам рознь У нас есть 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 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
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 |
esetnod
Messages: 27
Registered: July 2010
|
Junior Member |
|
|
| Quote: |
Есть нода с 4 SATA в софт-зеркале raid10 и Core i7(Hetzner с его серверами из "писюков"), с хостинговыми VPS-ками(25 штук), она тормозит по i/o хронически и перманентно, а клиент (которому принадлежит сервер) до сих пор не понимает, что SAS рулит, клиенты как-то живут, и не уходят (там цены достаточно низкие)
|
Может быть по шине тормоза, из-за софтового? Возможности небыло сравнить на такой-же конфе хардверный и софтовый рейд.
| Quote: |
Есть несколько нод с софт-зеркалом SAS(или рапторами), и несколько нод с raid10 SAS (хостинговые либо под тяжелые сервисы в офисах, вроде 1с-а): мы уже давно сделали вывод, чем дисковая быстрее, тем сервис работает устойчивее, быстрее, и тем больше "тяжелых" VE помещается на ноду, а SATA-диски лучше бы вообще не использовать нигде, кроме ультра-бюджетных конфигураций(лучше на CPU сэкономить!) но, имхо, хороший DAS/SAN все-таки может дать возможность их использовать за счет кэша под гигабайт и крутого контроллера.
|
Быстроходные дороговаты, особенно для мелких компаний, вроде нашей Пока довольствуемся рейдами из сата, с кешем на ssd
|
|
|
|
|
|
| Re: Предпочтительная схема использования физических ди [message #40612 is a reply to message #40608] |
Mon, 06 September 2010 06:25 |
sHaggY_caT
Messages: 144
Registered: August 2008
Location: Moscow, Russian Federatio...
|
Senior Member |
|
|
mdraid часто быстрее low-end аппаратных контроллеров
по шине (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 #40618 is a reply to message #40617] |
Mon, 06 September 2010 10:23 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Бекап не обеспечит быстрого переключения сервисов (в идеале вообще хотелось бы автоматизировать что можно). Как показала практика, выход из строя оборудования (в основном - диски и БП) происходит в 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 #40633 is a reply to message #40627] |
Tue, 07 September 2010 18:06 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Уже тестирую
Пробую со штатным патерном и 1, 4, 8, 16 и 32 активных процесса. Тест сперва на DRBD в полной сборке, а потом только на локальном диске.
Это на пару часов...
UPD: наивно было полагать, что это на пару часов.
Сервера, которые я использую для тестов, можно освободить от прочих задач только с 21 до полуночи. Но от тестов не отказываюсь и потихоньку их продолжаю. Параметров для тестирования оказалось прилично. Чего только стоит no-md-flush и no-disk-flush.
Кстати, если я правильно понимаю, эти параметры не такие уж опасные: обе ноды получили свою копию данных, но только не сбросили их на диск. Я прав?
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
[Updated on: Sat, 11 September 2010 08:08] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Wed Oct 02 20:26:10 GMT 2024
Total time taken to generate the page: 0.05312 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
