forum.lissyara.su

Добавлено: **2010-11-28 3:25:51**

я недавно создавал 2 темы http://forum.lissyara.su/viewtopic.php?f=5&t=29897 и http://forum.lissyara.su/viewtopic.php?f=5&t=29862.
Дабы убрать необходимость делать ссылки из одной в другую я решил создать эту тему

Есть задача по организации высокой доступности(по возожности отказоустойчивости): домена контроллера на 100 пользователей(win2008r2), терминального сервера 1с 8 на 30-50 активных пользователей(win2008r2) и пары машин поддерживающих не требовательные, но критичные сервисы типа админкита каспера и почты.
Бюджет 240тыс. р. в этом году и столько же в следующем.
В этом году необходимо приобрести оборудование и запустить на нём вышеописанные сервисы с учётом необходимости организации высокой доступности в следующем году..
Я определил требования к
ОЗУ - 16гб на каждый гипервизор
дисковой подсистеме - 1,2ТБ(4 диска по 600гб в 1+0 массиве) с 15000rpm. И ещё 2 диска sata по 2Тб в зеркале для бэкапов.
процессорам - пара xeon 5650.

Продукты типа ESXi не рассматриваются из-за того что в бюджет они не влезут точно. Все современные системы виртуализации подразумевают наличие хотя бы двух отдельных хранилищ данных и гипевизоров. Два хранилища для данного бюджета тоже накладный вариант. В поисках хранилища я набрёл на такое решение: http://www.supermicro.com/products/nfo/sbb.cfm. В описании фигурирует fault tolerance. Попытки выяснить что это такое у поддержки supermicro ни к чему не привели. Тогда я решил создать соответствующую тему на форуме по поиску RAID контроллера. Я предполагаю что существуют SAS контроллеры, которые будучи подключенными к разным серврам(или одному серверу с двумя мат. платами) и одним и тем же дискам могут заменять друг друга в случае сбоя. На данную мысль меня натолкнула упомянутая ссылка.
Помимо хранилища не ясен вопрос и с сетевыми адаптерами. Сразу ясно что для решения задачи максимум, т.е. организации полной отказоустойчивости виртуализируемых сервисов необходимо обеспечить высокую пропускную способность между гипервизорами и СХД. Т.е. гигабитные линки отпадают сразу. В поисках оборудования я набрёл на два варианта:
1)10g ethernet. http://www.supermicro.com/products/acce ... UTG-i2.cfm стоимость в районе 13т.р. в Москве за 2 порта.
2) infiniband http://www.supermicro.com/products/acce ... IBQ-M2.cfm стоимостью 23т.р. за два порта по 40Gb/s каждый!
Вроде бы и первый вариант не плох, но задел на будущее должен быть. Вобщем не могу выбрать, скорее всего остановлюсь 1ом варианте.

В результате я хочу получить решение из двух серверов каждый из которых будет выполнять функции и гипервизора и СХД.
В качестве ПО хочу использовать:
1) гипервизор на базе centos (kvm или xen, не особо важно, но 1ый предпочтительнее).
2) для синхронизации данных DRBD.

Хотелось бы услышать ваши мысли и предложения.

Модераторов прошу удалить/закрыть 2 родителькие темы на форуме, найти их можно в самом начале поста.

Добавлено: **2010-11-28 3:41:46**

Сорри, повторюсь. У вас в корне неверное понимание системы высокой доступности и понимание того как это работает.
Советую почитать литературу и выяснить что то что вы желаете при вашем бюджете невыполнимо.
Даже не так выразился... даже в упрощенном варианте даже при общем бюджете в 10кОйро то что вы хотите не получиться.
Могу в упрощенном варианте рассказать где вы заблуждаетесь и что неверное понимаете а так же выяснить почему бюджет не соответствует
вашим хотелкам.

Добавлено: **2010-11-28 15:51:16**

Fastman писал(а): Могу в упрощенном варианте рассказать где вы заблуждаетесь и что неверное понимаете а так же выяснить почему бюджет не соответствует
вашим хотелкам.

было бы замечательно!

Добавлено: **2010-11-28 16:45:06**

Ок. По порядку.
Вы перестаньте фантазировать и поглядите в прайс листы.
На вскидку ваши хотелки в виде:

Я определил требования к
ОЗУ - 16гб на каждый гипервизор
дисковой подсистеме - 1,2ТБ(4 диска по 600гб в 1+0 массиве) с 15000rpm. И ещё 2 диска sata по 2Тб в зеркале для бэкапов.
процессорам - пара xeon 5650.

Будут вам стоит в виде обычной 2U супермикры без дополнительных плюшек и операционных систем около 8-9к$
То есть все. Бюджет ваш кончился. То есть один сервер с вашими хотелками уже пожрал ваш бюджет.

Допустим выше я не писал ничего. Тогда в ваших хотелках куча несуразицы:
По порядку:

Есть задача по организации высокой доступности(по возожности отказоустойчивости): домена контроллера на 100 пользователей(win2008r2), терминального сервера 1с 8 на 30-50 активных пользователей(win2008r2) и пары машин поддерживающих не требовательные, но критичные сервисы типа админкита каспера и почты.

и

1) гипервизор на базе centos (kvm или xen, не особо важно, но 1ый предпочтительнее)

Я один вижу размазывание разных вендорных технологий толстым слоем пенопласта по стеклу ?
Если у вас инфраструктура в основном MS, зачем вы тащите линукс с ее KVM/XEN ? Вам честно хочется стойко все это поддерживать ?
У Вас есть офф поддержка систем гипервизора и возможность дурить голову саппорту если что то не работает ? А... да.. увидел - centos, вопрос отпадает.
Я не против и верю в вашу квалификацию. Но вашему начальству вряд ли будет интересно выслушивать причины простоя.

Есть неплохой выбор ESXi/Hyper-V.

В описании фигурирует fault tolerance. Попытки выяснить что это такое у поддержки supermicro ни к чему не привели. Тогда я решил создать соответствующую тему на форуме по поиску RAID контроллера. Я предполагаю что существуют SAS контроллеры, которые будучи подключенными к разным серврам(или одному серверу с двумя мат. платами) и одним и тем же дискам могут заменять друг друга в случае сбоя. На данную мысль меня натолкнула упомянутая ссылка.

fault tolerance в случае выше это значит что ценой небольшой просадки производительности контроллеры обслуживающие дисковый массив работают в режиме обеспечения отказоустойчивости. То есть если один вылетает - значит всю работу берет на себя один контроллер. Не более того. То есть мы просто ценой удвоения контроллеров и линий связи с сервером получаем
отказоустойчивость. Но это не значит что можно подключить 2 сервера к одному дисковому массиву напрямую и получить профит.
Я уже задолбался объяснять что для этого нужна кластерная файловая система(gpfs/gfs/ocfs*/etc) либо программное обеспечение которое является надстройкой и обеспечивает кластерный режим ФС.

Сразу ясно что для решения задачи максимум, т.е. организации полной отказоустойчивости виртуализируемых сервисов необходимо обеспечить высокую пропускную способность между гипервизорами и СХД. Т.е. гигабитные линки отпадают сразу. В поисках оборудования я набрёл на два варианта:

Вообще не понял сначала. Извините - набор слов.
Пропускную способность между гипервизорами и СХД по сети ??? Это как...
Вроде выше диски SAS в сервак как хотите...
Вы простите хоть раз щупали все это руками а не в википедии ??? Если нет - советую.
По этому пункту даже объяснить трудно если нет минимальных основ.

И да... вы мне покажите задачу которая в вашем случае загрузит 10G линк между серверами
хотя бы на 50%. Нет.. тут ж даже не надо умным быть... диски SAS 15к в спецификации
имеют цифру 6Gb/s. Это, пропускная спсобность вообще шины

В нормальных условиях вы никогда в жизни
на 10RAID Не получите при 4-х дисках на линейных потоках(а у вас они вовсе не линейные) больше 500-600Mbit/s это идеале !.
Мысль понятна ? Вы хотите IB 40Gb/s, но в ближайшем обозримом будущем то что вы хотите не сможет забить 10G и на половину
близко. Народ.. ну научитесь в калькуляторе кнопки тискать....

Хотелось бы услышать ваши мысли и предложения.

Мое предложение или разобраться/много читать и пробовать(за счет работодателя который выступит тестовой площадкой).
Либо обратиться к специалистам.
Не обижайтесь если где то перегнул палку. Но реально плохо все это выглядит со стороны.

Добавлено: **2010-11-28 19:14:08**

Fastman писал(а): Будут вам стоит в виде обычной 2U супермикры без дополнительных плюшек и операционных систем около 8-9к$
То есть все. Бюджет ваш кончился. То есть один сервер с вашими хотелками уже пожрал ваш бюджет.

ОСи уже куплены, вопрос по железу. Cервер (включая проц, платформу, контроллер, ОЗУ, диски, сеть 10g) действительно выйдет 8к, потому что я хотелки подогнал под бюджет.

fault tolerance в случае выше это значит что ценой небольшой просадки производительности контроллеры обслуживающие дисковый массив работают в режиме обеспечения отказоустойчивости. То есть если один вылетает - значит всю работу берет на себя один контроллер. Не более того. То есть мы просто ценой удвоения контроллеров и линий связи с сервером получаем
отказоустойчивость. Но это не значит что можно подключить 2 сервера к одному дисковому массиву напрямую и получить профит.

я вам верю, но разве поссылке не 2 мат. платы в одном корпусе?

Я уже задолбался объяснять что для этого нужна кластерная файловая система(gpfs/gfs/ocfs*/etc) либо программное обеспечение которое является надстройкой и обеспечивает кластерный режим ФС.

понял, я пока остановился на DRDB.

Вообще не понял сначала. Извините - набор слов.
Пропускную способность между гипервизорами и СХД по сети ??? Это как...
Вроде выше диски SAS в сервак как хотите...
Вы простите хоть раз щупали все это руками а не в википедии ??? Если нет - советую.
По этому пункту даже объяснить трудно если нет минимальных основ.

И да... вы мне покажите задачу которая в вашем случае загрузит 10G линк между серверами
хотя бы на 50%. Нет.. тут ж даже не надо умным быть... диски SAS 15к в спецификации
имеют цифру 6Gb/s. Это, пропускная спсобность вообще шины В нормальных условиях вы никогда в жизни
на 10RAID Не получите при 4-х дисках на линейных потоках(а у вас они вовсе не линейные) больше 500-600Mbit/s это идеале !.
Мысль понятна ? Вы хотите IB 40Gb/s, но в ближайшем обозримом будущем то что вы хотите не сможет забить 10G и на половину
близко. Народ.. ну научитесь в калькуляторе кнопки тискать....

Вобщем то на счёт дисков вы правы. Для них действительно 10g за глаза. Но я писал про задачу максимум - fault tolerance, что предполагает синхронизацию ОП между гипервизорами и накладывает большие требования на пропускную способность между ними.
Вобщем то на калькуляторе я всё прочитал, теорию тоже. Но в теории не всегда всё как на практике, поэтому к вам обратился. Вобщем решил завтра заказать домой кампутер, будет возможность опробовать всё "вживую".

Не обижайтесь если где то перегнул палку. Но реально плохо все это выглядит со стороны.

мне задачу решить надо, обижаться некогда.

Добавлено: **2010-11-28 19:44:56**

ОСи уже куплены, вопрос по железу. Cервер (включая проц, платформу, контроллер, ОЗУ, диски, сеть 10g) действительно выйдет 8к, потому что я хотелки подогнал под бюджет.

Просто советую не подгонять так близко. Если при планировании IT инфраструктуры вы не закладываете +20-30% вы изначально попадете в глупое положение.

я вам верю, но разве поссылке не 2 мат. платы в одном корпусе?

Да, и что ? Вы же почитайте. Там английским по белому написано что это платформа для построения кластера и HA.
То есть там все за 3 копейки заменяемое хот сваповое и прочая фигня.
Но нигде не написано что вы это получите без доп. софта который и сделает этот набор "cделай кластер дома за 21 день" рабочим

понял, я пока остановился на DRDB.

Неплохая технология. Но не все так вкусно в вашем случае. DRBD поразительно хреново ведет себя при работе мелкими блоками на запись.
А у вас таки 1С терминал... я не удивлюсь если у вас все станет колом. Терминальный сервак 1С выносить надо бы из всего этого хозяйства...
По крайней мере мои тесты показывали замедление работы от 2.5-4 раз примерно при юзании DRDB. Бухи вас пристрелят

Я вряд ли ошибусь если скажу что вы не получите скорости даже 30-40Мб/c при юзании актив-пассив DRDB.
Чудес не бывает... затраты на виртуализацию и IO убьет нафиг все ваши наполеоновские задумки и планы.

Посмотрите еще раз на ESXi+дополнительные плюшки. Чудес не произойдет конечно же, но там есть рабочие варианты за адекватные деньги.

Добавлено: **2010-11-29 14:02:38**

http://crunchtools.com/kvm-cluster-with-drbd-gfs2/

Results from Bonnie++ showed that we could achieve sequential reads of almost 300MB/s and writes of almost 90MB/s. This is with GFS over DRBD connected thorugh 3 bonded 1Gb ethernet interfaces.

это не тролинга ради, просто для размышления.
Решили купить просто сервер и "жить как жили". А там видно будет.

Добавлено: **2010-11-29 14:29:53**

opt1k писал(а):http://crunchtools.com/kvm-cluster-with-drbd-gfs2/
Results from Bonnie++ showed that we could achieve sequential reads of almost 300MB/s and writes of almost 90MB/s. This is with GFS over DRBD connected thorugh 3 bonded 1Gb ethernet interfaces.
это не тролинга ради, просто для размышления.
Решили купить просто сервер и "жить как жили". А там видно будет.

Да... на линейных потоках можно и такое получить. Но тут фишка в том что юзается GFS over DRBD.
Плюс как я уже сказал меряли поток линейный(sequential) о чем честно написали

Вообще я бы в вашем случае сделал дешево и сердито

Купил бы хранилку с iSCSI. Два сервера с ESXi флэшками.
Все виртуалки подымаем на хранилке. И пускаем с первого сервака.
Второй сервак выполняет роль бэкапа с LTO стримером к примеру + резерв в виде 1-2Тб веников если упадет хранилка а виртуалки со стриммера нужно куда то развернуть.
В случае падения основного сервака - перекидываем линк iSCSI и пускаем виртуалки с хранилки. Если упала хранилка берем стриммер разворачиваем локально виртуалки и пускаем их.
Простой в этом случае 2-3 часа потерпеть можно при вашем бюджете

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

Добавлено: **2010-11-29 15:26:09**

вариант имеет место быть. Но как вы и сказали хотелось именно автоматизировать. Что бы я мог на время отпуска выключить телефон. Ну, нет так нет.

Добавлено: **2010-11-29 15:37:12**

если все будет нормально настроено, то будет работать

Добавлено: **2010-11-29 16:56:21**

opt1k писал(а):вариант имеет место быть. Но как вы и сказали хотелось именно автоматизировать. Что бы я мог на время отпуска выключить телефон. Ну, нет так нет.

Просто чудес не бывает

И работа системы без вашего обслуживания просто потребует других денег

Руководство сэкономило на железе и софте, но будет вынужденно оплачивать дополнительного работника в ваше отсутствие

Возможно им это выгодней

Добавлено: **2010-11-29 22:15:39**

им выгодней позвонить мне и подавить на мозг

по-началу было проблемным и сотку на сервант выклянчить. По мере появления проблем у меня увеличиваются аппетиты, а рук-во поневоле увеличивает бюджет(ибо когда что то не так фраза "а я вам говорил" делает своё чёрное дело на белом листе служебки). Я буду терпелив и хладнокровен. И пусть в 2011 году бюджет под мои проекты взлетит хотя бы на порядок

Добавлено: **2010-12-01 1:23:58**

Fastman писал(а): И да... вы мне покажите задачу которая в вашем случае загрузит 10G линк между серверами
хотя бы на 50%. Нет.. тут ж даже не надо умным быть... диски SAS 15к в спецификации
имеют цифру 6Gb/s. Это, пропускная спсобность вообще шины В нормальных условиях вы никогда в жизни
на 10RAID Не получите при 4-х дисках на линейных потоках(а у вас они вовсе не линейные) больше 500-600Mbit/s это идеале !.

один диск сам по себе вполне спокойно линейно даёт сотню мегабайт в секунду. 4 диска в RAID10 дадут больше. Не в 2 раза, но в полтора - наверняка. Так что на 150 мегабайт ( 1.2 гигабита ) расчитывать вполне можно. Другое дело, что полтора гигабита и 10Г сетка - это все равно очень большая разница

Но просто меня сильно смутила оценка в 600 мегабит, как верхний предел.

Добавлено: **2010-12-01 5:07:59**

FiL писал(а):. Так что на 150 мегабайт ( 1.2 гигабита ) расчитывать вполне можно. Другое дело, что полтора гигабита и 10Г сетка - это все равно очень большая разница Но просто меня сильно смутила оценка в 600 мегабит, как верхний предел.

Рассчитывать можно конечно

Но реальность она другая.
По крайней мере я не верю что контроллер среднего ценового уровня типа адаптека вытащит это дело.
Утилиты которыми обычно юзеры меряют скорость - в лучшем случае говорят мне работает массив или нет

Возьмите реальную коробку и iometer, сделайте пресет линейного потока и покажите мне.
Я не говорю что ваши цифры невозможны. Но практика мне подсказала мои цифры

Зависит все это дело иногда чуть ли не от фазы луны,
а точнее от дров и прошивок контроллера/файловой системы/настроек OS/размерность блока копирования/стостыщпиццот рычажков,
и обязательно в BBU контроллера должны входить порошок сушеной жабы и кровь девственницы. Но это крайности.. редко такое бывает

Добавлено: **2010-12-01 23:31:02**

у меня дома софтовый рейд на линуксе дает 140 мегабайт на чтение. На 4-х зеленых дисках от WD. На нормальных дисках и нормальном контроллере...

Добавлено: **2010-12-01 23:36:20**

FiL писал(а):у меня дома софтовый рейд на линуксе дает 140 мегабайт на чтение. На 4-х зеленых дисках от WD. На нормальных дисках и нормальном контроллере...

Оффтоп развели.. но... я признаю цифры. iometer в руки, цифры сюда

Добавлено: **2010-12-02 1:54:23**

Fastman писал(а): Оффтоп развели.. но... я признаю цифры. iometer в руки, цифры сюда

Никогда иометером не пользовался... ну вот чего он мне намерял -

Код: Выделить всё

'Test Type,Test Description
0,
'Version
1.1.0
'Time Stamp
2010-12-01 17:40:31:852
'Access specifications
'Access specification name,default assignment
16K; 100% Read; 0% random,0
'size,% of size,% reads,% random,delay,burst,align,reply
16384,100,100,0,0,1,0,0
'End access specifications
'Results
'Target Type,Target Name,Access Specification Name,# Managers,# Workers,# Disks,IOps,Read IOps,Write IOps,MBps (Binary),Read MBps (Binary),Write MBps (Binary),MBps (Decimal),Read MBps (Decimal),Write MBps (Decimal),Transactions per Second,Connections per Second,Average Response Time,Average Read Response Time,Average Write Response Time,Average Transaction Time,Average Connection Time,Maximum Response Time,Maximum Read Response Time,Maximum Write Response Time,Maximum Transaction Time,Maximum Connection Time,Errors,Read Errors,Write Errors,Bytes Read,Bytes Written,Read I/Os,Write I/Os,Connections,Transactions per Connection,Total Raw Read Response Time,Total Raw Write Response Time,Total Raw Transaction Time,Total Raw Connection Time,Maximum Raw Read Response Time,Maximum Raw Write Response Time,Maximum Raw Transaction Time,Maximum Raw Connection Time,Total Raw Run Time,Starting Sector,Maximum Size,Queue Depth,% CPU Utilization,% User Time,% Privileged Time,% DPC Time,% Interrupt Time,Processor Speed,Interrupts per Second,CPU Effectiveness,Packets/Second,Packet Errors,Segments Retransmitted/Second
ALL,All,,1,1,1,8964.323878,8964.323878,0.000000,140.067561,140.067561,0.000000,146.871482,146.871482,0.000000,8964.323878,0.000000,0.110758,0.110758,0.000000,0.110758,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0,0,0,113319198720,0,6916455,0,0,-1,,,,,,,,,,0,0,1,42.141496,3.253017,38.888479,0.000000,0.000000,,15191.446426,212.719641,671.675703,0.000000,0.000000
MANAGER,centos.home,16K; 100% Read; 0% random,,1,1,8964.323878,8964.323878,0.000000,140.067561,140.067561,0.000000,146.871482,146.871482,0.000000,8964.323878,0.000000,0.110758,0.110758,0.000000,0.110758,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0,0,0,113319198720,0,6916455,0,0,-1,766055451620,0,766055451620,0,0,0,0,0,771553448370,0,0,1,42.141496,3.253017,38.888479,0.000000,0.000000,1000000000.000000,15191.446426,212.719641,671.675703,0.000000,0.000000
PROCESSOR,CPU 0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,61.250388,4.948959,56.301429,0.000000,0.000000,1000000000.000000,15191.446426,,,,
PROCESSOR,CPU 1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,23.032604,1.557076,21.475529,0.000000,0.000000,1000000000.000000,0.000000,,,,
WORKER,Worker 1,16K; 100% Read; 0% random,,,1,8964.323878,8964.323878,0.000000,140.067561,140.067561,0.000000,146.871482,146.871482,0.000000,8964.323878,0.000000,0.110758,0.110758,0.000000,0.110758,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0,0,0,113319198720,0,6916455,0,0,-1,766055451620,0,766055451620,0,0,0,0,0,771553448370,0,0,1,,,,,,1000000000.000000,,,,,
DISK,/mnt/1 [xfs],,,,,8964.323878,8964.323878,0.000000,140.067561,140.067561,0.000000,146.871482,146.871482,0.000000,8964.323878,0.000000,0.110758,0.110758,0.000000,0.110758,0.000000,0.000000,-8.400626,0.000000,-8.400626,0.000000,0,0,0,113319198720,0,6916455,0,0,-1,766055451620,0,766055451620,0,0,0,0,0,771553448370,0,0,1,,,,,,1000000000.000000,,,,,
'Time Stamp
2010-12-01 17:52:02:291
'End Test

софтовый RAID10 на линуксе.

Добавлено: **2010-12-02 2:13:44**

FiL писал(а): софтовый RAID10 на линуксе.

Да вижу. 16K block*(~9K IOPS) = ~140MBps
Только вот одно замечание:

Код: Выделить всё

% CPU Utilization	% User Time      % Privileged Time
42.141496  	        3.253017	         38.888479
42.141496	          3.253017	          38.88847

Ваш софтовый рэйд обслуживают 2 ядра со всей дури.
На контроллерах процессоры не такие сильные

Ваш PC при этом занят тем что выполняет задачу контроллера. Больше он ничем занят не будет.
А если будет скорость упадет.
Спасибо за тест

Можете поиграться с парой парралельных воркеров на которые разнесите несколько типов нагрузки.
Занимательная штука

Добавлено: **2010-12-02 5:11:36**

ну ясен пень, что параллельные воркеры, да еще и с разной нагрузкой на софтовом райде из непредназначенных для этого дисков дадут результаты где-то ниже плинтуса.

А вот то, что специализированный процессор на железном контроллере будет медленнее, чем CPU - это я не согласен. Совсем не согласен. И если будет время, то таки приведу результаты с подобного теста на каком-нить из не сильно нагруженных серверов на работе.

Добавлено: **2010-12-02 5:19:15**

FiL писал(а): И если будет время, то таки приведу результаты с подобного теста на каком-нить из не сильно нагруженных серверов на работе.

А собственно... что мне мешает это сделать прямо сейчас?

Машина - 2-головый серверок от супермикры с двумя ксеонами L5420 на 2.5ГГц
Диски - 8 SATA дисков (сигейты полуторатерабайтные) в 10-м рейде на 3ware 9550

Код: Выделить всё

'Test Type,Test Description
0,
'Version
1.1.0
'Time Stamp
2010-12-01 21:10:25:315
'Access specifications
'Access specification name,default assignment
16K; 100% Read; 0% random,0
'size,% of size,% reads,% random,delay,burst,align,reply
16384,100,100,0,0,1,0,0
'End access specifications
'Results
'Target Type,Target Name,Access Specification Name,# Managers,# Workers,# Disks,IOps,Read IOps,Write IOps,MBps (Binary),Read MBps (Binary),Write MBps (Binary),MBps (Decimal),Read MBps (Decimal),Write MBps (Decimal),Transactions per Second,Connections per Second,Average Response Time,Average Read Response Time,Average Write Response Time,Average Transaction Time,Average Connection Time,Maximum Response Time,Maximum Read Response Time,Maximum Write Response Time,Maximum Transaction Time,Maximum Connection Time,Errors,Read Errors,Write Errors,Bytes Read,Bytes Written,Read I/Os,Write I/Os,Connections,Transactions per Connection,Total Raw Read Response Time,Total Raw Write Response Time,Total Raw Transaction Time,Total Raw Connection Time,Maximum Raw Read Response Time,Maximum Raw Write Response Time,Maximum Raw Transaction Time,Maximum Raw Connection Time,Total Raw Run Time,Starting Sector,Maximum Size,Queue Depth,% CPU Utilization,% User Time,% Privileged Time,% DPC Time,% Interrupt Time,Processor Speed,Interrupts per Second,CPU Effectiveness,Packets/Second,Packet Errors,Segments Retransmitted/Second
ALL,All,,1,1,1,15854.990333,15854.990333,0.000000,247.734224,247.734224,0.000000,259.768162,259.768162,0.000000,15854.990333,0.000000,0.062726,0.062726,0.000000,0.062726,0.000000,196.921925,196.921925,0.000000,196.921925,0.000000,0,0,0,41626157056,0,2540659,0,0,-1,,,,,,,,,,0,0,1,5.632528,0.817575,4.814954,0.000000,0.000000,,3832.247394,2814.897619,982.194346,0.000000,0.000000
MANAGER,pogue.tch.harvard.edu,16K; 100% Read; 0% random,,1,1,15854.990333,15854.990333,0.000000,247.734224,247.734224,0.000000,259.768162,259.768162,0.000000,15854.990333,0.000000,0.062726,0.062726,0.000000,0.062726,0.000000,196.921925,196.921925,0.000000,196.921925,0.000000,0,0,0,41626157056,0,2540659,0,0,-1,398431932452,0,398431932452,0,492324307,0,492324307,0,400624591492,0,0,1,5.632528,0.817575,4.814954,0.000000,0.000000,2500099000.000000,3832.247394,2814.897619,982.194346,0.000000,0.000000
PROCESSOR,CPU 0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,5.978905,2.009611,3.969294,0.000000,0.000000,2500099000.000000,3832.247394,,,,
PROCESSOR,CPU 1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,14.554079,1.597703,12.956375,0.000000,0.000000,2500099000.000000,0.000000,,,,
PROCESSOR,CPU 2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,1.341821,0.012482,1.329339,0.000000,0.000000,2500099000.000000,0.000000,,,,
PROCESSOR,CPU 3,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,7.326967,1.179554,6.147413,0.000000,0.000000,2500099000.000000,0.000000,,,,
PROCESSOR,CPU 4,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0.056169,0.006241,0.049928,0.000000,0.000000,2500099000.000000,0.000000,,,,
PROCESSOR,CPU 5,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,11.371154,1.266929,10.104225,0.000000,0.000000,2500099000.000000,0.000000,,,,
PROCESSOR,CPU 6,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0.093615,0.006241,0.087374,0.000000,0.000000,2500099000.000000,0.000000,,,,
PROCESSOR,CPU 7,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,4.337515,0.461836,3.875679,0.000000,0.000000,2500099000.000000,0.000000,,,,
WORKER,Worker 1,16K; 100% Read; 0% random,,,1,15854.990333,15854.990333,0.000000,247.734224,247.734224,0.000000,259.768162,259.768162,0.000000,15854.990333,0.000000,0.062726,0.062726,0.000000,0.062726,0.000000,196.921925,196.921925,0.000000,196.921925,0.000000,0,0,0,41626157056,0,2540659,0,0,-1,398431932452,0,398431932452,0,492324307,0,492324307,0,400624591492,0,0,1,,,,,,2500099000.000000,,,,,
DISK,/RAID10 [xfs],,,,,15854.990333,15854.990333,0.000000,247.734224,247.734224,0.000000,259.768162,259.768162,0.000000,15854.990333,0.000000,0.062726,0.062726,0.000000,0.062726,0.000000,196.921925,196.921925,0.000000,196.921925,0.000000,0,0,0,41626157056,0,2540659,0,0,-1,398431932452,0,398431932452,0,492324307,0,492324307,0,400624591492,0,0,1,,,,,,2500099000.000000,,,,,
'Time Stamp
2010-12-01 21:13:10:568
'End Test

Как можешь видеть - более 250 мегабайт/с. И это не SAS. Просто относительно толковый железный рейд.
Гонять сложные задачи с параллельными воркерами мне сейчас откровенно лень. Лично для себя я и разницу между софтовым и железным рейдом увидел и примеры скоростей тоже.

Добавлено: **2010-12-02 5:37:35**

Как можешь видеть - более 250 мегабайт/с. И это не SAS. Просто относительно толковый железный рейд.

На линейном потоке выигрыш SAS не такой большой... Они на мелких блоках себя получше ведут. Там электроника и прошивка поумнее.

Гонять сложные задачи с параллельными воркерами мне сейчас откровенно лень.
Лично для себя я и разницу между софтовым и железным рейдом увидел и примеры скоростей тоже.

Так для того и копья ломаем чтобы цифры руками пощупать

Это же полезно.

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

Последнее время мало кому верю пока сам не пощупаю.

Добавлено: **2010-12-02 17:02:14**

не, давай таки отделим мух от котлет. Одно дело пиковая производительность дискового массива и необходимая сетевая инфраструктура, которая должна эти пики выдерживать. И совершенно другое - среднестатистические нагрузки в данном конкретном случае.
Я таки на своем опыте могу сказать, что обычного гигабита хватает в 99% случаев. Ибо очень редко когда данные таки реально идут быстрее. Но если строишь систему с нуля, то все-таки надо расчитывать на то, что в пике (например одна нода отваливалась и надо полностью реплицировать ноду с другой) поток данных может быть бОльшим. И если есть возможность поставить 10G (или мультилинк из 4-х гигабитов), то это будет весьма в плюс).

Добавлено: **2011-03-23 17:47:56**

Добрый день!

Я проводил тесты на следующем оборудовании:
2 - 4х ядерных сервера с 16Гб и с винтами по 2х1Тб (raid0) соединены по 10Гб карточки
Стоит ESX, на нем крутится DRBD - отдает в каждый ESX диск по iSCSI. На этих iSCSI дисках крутятся виртуалки.

Работает! И отказоустойчивость и FT и HA,
Но если что то происходит с DRBD на одном из серверов (плановая или не плановая остановка) - то для полной синхронизации DRBD нужно около 4х часов. Во время синхнонизации не работает ни одна виртуалка. Вы готовы жертвовать этим временем?

Добавлено: **2011-03-25 10:29:16**

добрый день, спасибо за ваш ответ!
я с DRBD игрался некоторое время назад, 4 часа - выглядит странно. В моих экспериментах на офисных машинах синхронизация шла не более минуты. Диски гостевых ОС были по 10Гб.
Поэтому делаю предположение что время синхронизации сильно зависит от организации дискового пространства.
Например:
у вас есть АД, почта, файлопомойка, терминалка, помойка под базы 1с.
на АД у вас завязано 80% инфраструктуры(кассовые аппараты, удалённые филиалы и т.д.)
В таком случае возможно достаточно сделать отказоустойчивым именно АД, выделив, допустим 100гб дискового пространства. В таком случае синхронизация явно будет менее 4х часов. Т.е. чем то придётся жертвовать, главное что бы оправданно.
Так же нельзя забывать о том что:
1) синхронизация это не плановое событие и направлено оно на сокращение времени возможных простоев (если у вас нету 2ого сервера, то время и без синхронизации может исчисляться днями, либо большими $)
2) в случае сбоя синхронизацию не обязательно выполнять сразу после его устранения, ведь ваша система продолжает работать. Можно это сделать после рабочих часов.
3) если правильно всё организовать, то синхронизацию можно делать поэтапно, это будет полезно если ваша организация разбросана географически или работает в несколько смен и нет больших перерывов времени.

FT в том виде, в котором оно реализовано в ESXi достаточно сомнительная штука, слишком много ограничения.
Очень жду kemari для kvm, раз в неделю захожу в рассылку и всегда вижу новые патчи. Дело идёт к тому что может в этом году увидим релиз проекта.

Добавлено: **2011-03-25 10:43:50**

Не бейте ногами... но на фоне кластера на Win2008+Hyper-V(с живой миграцией) выглядит извините подъ*бкой....

forum.lissyara.su

железо для виртуализации

железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации

Re: железо для виртуализации