Опыт использования есть, но не у меня, а у наших сторадж-мастеров :)

DRBD master-master без кластерной файловой системы смысла не имеет — нужно как-то разруливать проблемы с совместным доступом к файлам, актуальностью данных в кеше ФС на каждой ноде и т.п. В качестве таковой рекомендую использовать GFS либо OCFS.

По поводу линка — зависит прежде всего от преобладающего метода работы с дисками — линейное чтение-запись (тогда действительно нужна большая полоса) либо случайное чтение небольших объемов данных (тогда узким местом будут сами диски и, возможно, программная часть стека, от драйверов ФС до сетевого стека).
Рекомендую в любом случае брать сетевуху с двумя портами — bonding можно настроить не только в режиме балансировки нагрузки, но и в режиме горячего резервирования (mode=1). Из балансирующих решений рекомендую mode=4 (802.3ad), но этот режим требует поддержки свичом.

я знал, что вы заглянете )

Спасибо за инфу. Без кластерной фс действительно никуда, конкурентным доступом ресурс будет «разорван»...

Не уточните еще у коллег - какие контроллеры используются для дисковой подсистемы на нодах и используется ли выделенный линк для реплики между нодами?

Я вообще думаю о квадах на сетевых картах. Слоты штука конечная ... порты на свиче тоже ( Сначала думал сделать кросс между двух портовыми картами и коннектить сервера минуя свичь (для реплики линка), но думается мне что бондинг в такой конфиге работать не будет. Хотя ... Сторона отправляющая, первая нода - пакет налево, пакет направо, первый пакет попал через первый линк в обработку на второй ноде, второй пакет попал через второй линк в обработку на второй ноде. Вторая нода пощелкала процом, и выдает ответ - пакет направо, пакет налево.

Надо попробовать ))

>Не уточните еще у коллег - какие контроллеры используются для дисковой подсистемы на нодах и используется ли выделенный линк для реплики между нодами?

С этим вопросом, к сожалению, есть определенные затруднения. Дело в том, что конкретная аппаратная конфигурация рабочих серверов, а также наши внутренние «ноу-хау» (в частности, особый стек HA-стораджа) не подлежат разглашению. Пожалуйста, поймите правильно. Очень хотелось бы помочь, но не могу.
Единственное, что могу рассказать — обычно на наших площадках сервера соединены через три магистрали. Одна используется для внешних коммуникаций, другая — для внутренних, и третья держится в резерве. У нас обычно в кластере более двух нод, да и состав кластеров не гвоздями приколочен, поэтому прямое соединение всех нод затруднительно :)

Кстати, что касается стека. Насколько принципиально использование primary-primary режима? Не устроит ли вас использование DRBD-устройств (primary-slave) в качестве iSCSI target + heartbeat (переброс таргета на резервную ноду при необходимости)? Например, так: http://www.gossamer-threads.com/lists/linuxha/users/45280
Тот же xen, например, спокойно мигрирует вживую при вынесенном на iSCSI сторадже. У вас, как я понял, вмварь ESX, но тут помочь советом не смогу — в продакшене ее никогда не щупал. Хотя по ссылке выше вроде говорят, что как раз с ней отлично работает.

Хотя ... Сторона отправляющая, первая нода - пакет налево, пакет направо, первый пакет попал через первый линк в обработку на второй ноде, второй пакет попал через второй линк в обработку на второй ноде. Вторая нода пощелкала процом, и выдает ответ - пакет направо, пакет налево.

Ну, это скорее mode=0 (balance-rr). Вообще, если свича пока нет, мысль соединить два сервака напрямую и попробовать разные режимы мне тоже кажется разумной. Вот здесь имхо они неплохо описаны: http://howtoforge.com/nic-bonding-on-debian-lenny

>Единственное, что могу рассказать — обычно на наших площадках сервера соединены через три магистрали. Одна используется для внешних коммуникаций, другая — для внутренних, и третья держится в резерве. У нас обычно в кластере более двух нод, да и состав кластеров не гвоздями приколочен, поэтому прямое соединение всех нод затруднительно :)

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

сколько принципиально использование primary-primary режима? Не устроит ли вас использование DRBD-устройств (primary-slave) в качестве iSCSI target + heartbeat (переброс таргета на резервную ноду при необходимости)?

как я и писал выше, все с кем общался использовали primary-slave и отказались ввиду низкой производительности на запись. возможно это зависит от оборудования и квалификации админа. primary-slave мне кажется более предпочтителен - нет лишних слоев и переключений. надо делать самому, но опять же, может квалификации не хватить. но раз примеры удачных внедрения есть - буду копать :)

спасибо вам за информацию, в остальных местах молчат как рыбы об лед )

Я также интересуюсь данной темой, мне не очень понравилось вот чего:

(при использовании безопасного протокола C)

Почему хотябы не B..? Ладно, чёрт с ним, может рискнуть и A..? Что случится?

Ну хорошо, предположим у нас A вариант, отвалился линк с одной из нод... Ну и..? Подняли линк всё засинхронизировалось. - Всё хорошо.

Сдохла нода slave, остановили на master drbd, подняли ноду slave, всё засинхронизировали.

Самый критичный момент это конечно: упала нода master, мы на ноде slave имеем неконсистентную копию, если не супер критично всё это дело то: операция которая была на машинах во время падения master ноды, так и так прерывается, поднимаемся со slave и просто поднимаем критичные операции снова. Не..? Для пользователей это просто обычная перезагрузка будет. - Ну ведь может же быть такое что физическая нода упадёт... Не падает же прям всё в тар-тарары. Ну это конечно если перезапуск гостевых ОС допустим. - В моём случае в общем то да.

Где подвох..?

Конечно это всё при наличии нормального железа и ИБП.

Все правильно написали. Ответ один - страшно. Вот вы можете предсказать, как точно себя поведут виртуалки после такого финта? У меня как то почтовая база после ребута по питанию на физической машине развалилась, почему на виртуалке такого не произойдет? Восстанавливаться из бэкапа? Зачем тогда нода вторая, для быстрого восстановления доступности «общего» стоража? Проще тогда сразу прицепить бэкапный стораж и зарегестрировать оттуда бэкапную виртуалку (при условии, что виртуалка была забэкаплена с остановкой сервисов или вообще выключена). Хотя если на виртуалки не критичны к перезагрузкам (к примеру терминальные сервера или еще какие калькуляторы) то можно и не бояЦЦо. В варианте А можно наплевать на латентность линка для реплики и на латентность слейв ноды, оговорив, что в случае выхода из строя мастер ноды, производительность понизится (бюджет, млин) Более того, я хочу потестить без железных контроллеров на mdadm с большими write buffers + отключенный disk flush.

Емнип, эффект жесткого выключения виртуальных окружений возникает только в том случае, если выпадает активная worker node (т.е. нода, на которой работают сами виртуалки). Тогда резервная worker node вынуждена поднимать их с нуля.

Если же выпадает drbd master at storage node, heartbeat быстренько перекидывает все концы iSCSI на drbd slave storage node, и виртуалки обычно даже не замечают ничего.

Конечно, если использовать бюджетное решение (совместить ноды стораджа и воркеры), проблема встает в полный рост.

>Вот вы можете предсказать, как точно себя поведут виртуалки после такого финта?

Увы. Очевидно нет.

Опять же в голову приходят такие решения, чтобы не морочиться:

Реплицировать на уровне не блоков а файловой системы, чем либо другим не обязтаельно drbd, но это чисто в теории. Тогда мы получим просто какой-либо битый файл один, что в теории более лучше нежели потерять какой-либо блок и убить целую вирт. машину, а может и не одну. Тогда надёжность будет как у обычного выделенного сервера: не вырубай питание... - Не будет проблем. Но в случае отказа можно переключиться на другую ноду.

Второе решение: если операций записи не настолько много, то к примеру раздел /tmp и spool для принтеров можно вынести в RAM, чтобы не было обращений к HDD лишний раз и тогда использовать протокол C в drbd.

Ну и вообще высоконагруженные сервера всё же по моему скромному мнению должны работать на выделенных серверах. Если бы у меня был к примеру Web портал масштаба LOR я бы не стал полагаться на KVM.

Ну или какая-либо корзина SCSI физически подключенная к узлу master, если та упала, то переключаем на узел slave.

Или как Уважаемый nnz писал iSCSI пользвать корзину, только я сомневаюсь что оно быстрее чем drbd.

Минус моей дискуссии в том, что я всё в теории несу... У меня задача такая: сделать с десяток не высоконагруженных машин. И одну машину для CRM системы на java (alfresco), в ней документооборот и системы круглосуточного мониторинга не очень большого потока данных также на подобии alfresco, на 50-70 человек.

Вот не знаю, как поступить. Не знаю как хранить машины в файлах raw? Или в разделах..? В разделах каких? LVM или обычных..? Всю голову переломал. Если внедрять такое решение это большие деньги, и оно должно работать как надо. На простых машинах всё работает, буду тестировать производительность всего и вся. Но всёж в бою может всплыть подвох.

>и виртуалки обычно даже не замечают ничего.

слово «обычно» - оно какое то расплывчатое и к плану внедрения применяется плохо )) похоже, без полноценного тестирования не обойтись в любом случае. но хоть теории набрался, и пока мне все нравится, думаю что и primary-slave + protocol C подойдет.

в теории я вообще вижу хосты с гипервизором как отдельные, бездисковые машины (pxe или флешка) + общий стораж (две ноды drbd) для хостов с гипервизорами прицепленный по iSCSI более того, у меня есть тестовый стенд где без drbd все это замечательнейшим образом работает, но без резервирования стоража в продакшен такую схему пусть не решусь.

ну чтож, будем посмотреть.

>Реплицировать на уровне не блоков а файловой системы, чем либо другим не обязтаельно drbd, но это чисто в теории.

интересно, чем? в виндовой среде использовал dfs, не шибко удобно и производительно, но репликацию осуществлял. в linux подобного рода сервисов не встречал.

Или как Уважаемый nnz писал iSCSI пользвать корзину, только я сомневаюсь что оно быстрее чем drbd.

не очень понимаю о чем вы. я сам лично планирую 3 хоста с гипервизорами + общий стораж прицепленный к ним посредством iSCSI (общий стораж это две ноды кластера drbd) файлы виртуалных машин хранятся на этом самом общем стораже, но выполняются на хостах с гипервизором. в идеале если выйдет из строя один из хостов с гипервизором можно будет запустить виртуалки которые на нем выполнялись на другом гипервизоре - типа вынужденный ребут. если выйдет из строя мастер нода drbd кластера heartbeat (в теории) переключит незаметно для виртуалок на слейв и виртуалки продолжат выполнятся. соотвественно вопроса о том в чем хранить файлы виртуальных машин для меня не возникает - vmdk хотя можно и rdm, но c vmdk оно как то попроще )

На простых машинах всё работает, буду тестировать производительность всего и вся. Но всёж в бою может всплыть подвох.

в основном узкое место в производительности систем виртуализации именно в дисковых иопсах. ... ну и в управляемости всем этим барахлом ) вы с системой виртуализации определились уже или нет?

> вы с системой виртуализации определились уже или нет?

Пока нет. Я тут уже тоже всем плеш проел. Xen и KVM практически равнозначны, но т.к. Xen не перспективен, решил KVM, тем более что нашёл проект http://www.proxmox.com/ , советую посетить сайт и прочитать документацию - KSM и прочие вещи вызывают интерес. Там даже есть кластеризация, но как она устроена не понял пока, завтра буду пробовать.

В итоге сейчас я рассматриваю либо: KVM, либо продукты от VMvare как платные так и бесплатные, в том числе у них есть в продаже готовые сервера для виртуализации заточенные. - Пропиретарненько и как я понимаю не дёшево, но нам это дело активно навязывают и если я не смогу добиться ничего вменяемого на KVM - буду смотреть в эту сторону. Продукцию от MS начальство сказало даже не рассматривать. Не смотря на то, что эти товарищи предлагают Hyper-V как самостоятельное решение бесплатно.

не очень понимаю о чем вы.

iSCSI как я понимаю это есть SCSI, только бегущую по TCP/IP, а значит это дополнительные ресурсы на инкапсуляцию пакетов и т.д. Drdb по сути тоже самое. Только оно будет крутиться на локальном сторедже и реплецироваться через тот же TCP/IP. В общем не знаю, надо тестировать разницу.

Если рассматривать SCSI - то это можно купить корзину, напихать туда винтов, и проводом подключить к серверу. - К примеру дорогие решения от HP я думаю что очень будут отлично себя вести, у нас такие есть. Горячая замена и другие бонусы. Никаких морок с drdb и прочим трешем бегущим под TCP/IP. Сдохла нода - переткнул кабель к другому серверу, пустил виртуалки. Всё хорошо. - Но понятно дело, что надёжность такой системы равна надёжности корзины, и в случае её поломки трудно будет что-либо придумать на замену «по быстрому» в отличии от drdb.

интересно, чем? в виндовой среде использовал dfs, не шибко удобно и производительно, но репликацию осуществлял. в linux подобного рода сервисов не встречал.

Речь о кластерных файловых системах. Но это опять же в теории. GlusterFS и другие. То есть только её использовать, без всяких там iSCSI и drdb.

не очень понимаю о чем вы. я сам лично планирую 3 хоста с гипервизорами + общий сторадж прицепленный к ним посредством iSCSI (общий стораж это две ноды кластера drbd) файлы виртуалных машин хранятся на этом самом общем стораже, но выполняются на хостах с гипервизором. в идеале если выйдет из строя один из хостов с гипервизором можно будет запустить виртуалки которые на нем выполнялись на другом гипервизоре - типа вынужденный ребут.

Весьма интересно. Право, я до такого не додумался. Только в моём конкретном случае задача примерно такова: избавиться о кучки дедиков, у Вас там я не знаю как, но в Вашем случае получается уже пять машин. Мне шило на мыло менять... Плюс учтите, что все машины будут тянуть файлы через iSCSI, ну то есть это надо между хостами поднимать отдельную сеть, высокоскоростную, да и на каждом дедике крутящим виртуалки потребуется по две карты, одна будет смотреть в Вашу ЛВС, другая в сторону iSCSI массива. - В общем идея Ваша весьма заманчива. Но вот опять же как оно себя поведёт, и стоит ли овчинка выделки. У Вас чего планируется крутить? Объём записи данных велик?

я бы рекомендовал сравнивать «управляемость» виртуальных машин в целом. производительность, фичи, требования к железу - это все важно, но если будут большие административные затраты на поддержании инфраструктуры то все прелести виртуализации будут забыты. только учтите, что за ESX придется платить оч много ) а ESXi это только платформа для виртуализации, без возможности установки допсофта и прочих плюшек доступных для ESX (api управление питанием, мониторинг железок, оповещение)

iSCSI как я понимаю это есть SCSI, только бегущую по TCP/IP, а значит это дополнительные ресурсы на инкапсуляцию пакетов и т.д. Drdb по сути тоже самое. Только оно будет крутиться на локальном сторедже и реплецироваться через тот же TCP/IP. В общем не знаю, надо тестировать разницу.

правильно понимаете. накладные расходы будут ой-ей-ей.

Если рассматривать SCSI - то это можно купить корзину, напихать туда винтов, и проводом подключить к серверу. - К примеру дорогие решения от HP я думаю что очень будут отлично себя вести, у нас такие есть. Горячая замена и другие бонусы. Никаких морок с drdb и прочим трешем бегущим под TCP/IP. Сдохла нода - переткнул кабель к другому серверу, пустил виртуалки. Всё хорошо. - Но понятно дело, что надёжность такой системы равна надёжности корзины, и в случае её поломки трудно будет что-либо придумать на замену «по быстрому» в отличии от drdb.

я много-много считал железки + обслуживание + производительность + скорость восстановления после сбоя + масштабирование и бла бла. прихожу к выводу что SAN инфраструктура для серьезных проектов (где важны иопсы и низкая латентность)это единственный выход.

в реплецируемых кластерах есть своя прелесть (дешевизна) но для того чтобы серьезно поднять производительность нужно много-много доп затрат на сетевые карты, свичи, обслуживание этого барахла ... и все равно SAN будет быстрее ) но если высокие задержки связанные с tcpip не критичны, то стораж организованный drbd + iscsi то это решение вполне конкурнентно способно.

Только в моём конкретном случае задача примерно такова: избавиться о кучки дедиков, у Вас там я не знаю как, но в Вашем случае получается уже пять машин.

думаю, что будет и шестая - бэкапный сервер + еще какие либо обслуживающие функции) для меня это пока все сферический конь в вакууме. конкретной задачи нет, в основном обхожусь двумя хостами ESXi на брендовых железках, виртуалки работают с локальных сторажей, + ESXi на самосборном железе - там поднят виртуальный openfiler для организации бэкапного стоража (прицепил этот стораж по iSCSI к обоим хостам и делаю туда копии виртуалок, в случае необходимости можно будет зарегистрировать их прямо из каталога и пустить в бой, для теста так и сделали, для ненагруженной системы документооборота, там всего 5 пользователей на тот момент было, потому никто даже и не заметил )))) еще на этом виртуальном стораже держу виртуалку для пересборки пакетов под i586 архитектуру. надо бы сравнить как быстро сервер хранимый на локальном стораже core пакеты пересобирает по сравнению с хранением виртуалки на общем стораже прицепленном по iSCSI, но пока недосуг чистое тестирование провести.

> для серьезных проектов Вот понять бы уровень этих проектов.

ИОПСЫ и латентность везде важна, покажите проект в котором она не важна... - Ну это правда только если косынку раскладывать...

Я исхожу из того, что раз drbd кто-то придумал и его уже внедрили в maintain основного ядра Linux значит решение стоящее. — А может я себя просто тешу...

Сейчас поднял две машины с proxmox поднял гигабитный линк чисто между ними, подготовил всё. Надо тестировать. Но надо асиливать drbd - я то думал там гляну sample конфиг и настрою... Но похоже я ошибался, нифига не понятно чего там к чему. - Надо читать документацию.

Ну и это...:

стораж организованный drbd + iscsi то это решение вполне конкурнентно способно.

Я думаю, что в моём случае не стоит такого мутить. Будут диски каждый в своей машине зеркальной (drbd мастер/слайв, протокол С) жить. У меня их пока две. Но Ваше решение значительно более масштабируемое, Вам нужно лишь поднять будет виртуалок а бекап у Вас уже на уровне стораджа, мне же если мощности одной машины не хватит придётся -> застрелиться.

Однако в моём случае насколько я понимаю не требуется iSCSI, а значит производительность должна быть получше.

Ох уж эта виртуализация... Я уже и правда подумываю - а может ну его..? :(

Да и ещё: vdmk образы помоему не возможно расширить. А raw можно. :-)

И вопрос: какой сторадж от SUN Вы рассматривали?

иопсы где не важны? ... хм. был у меня виртуальный сервер отчетности - скрипт его включает в 11 вечера, засосал сервер ночью пару сотен мб таблиц за один присест и ну их считать. посчитал, сложил в хранилище отчетов, разослал по адресам и спать лег, ну посчитал на 8-9 минут дольше, чем если бы локальном стораже, ну и что? ) считал 6-7 часов, к диску практически не обращается, все в кеше сидит, но ночью на хосте он один работает, потому 16 гигов получает (вот и профит от виртуализации, когда я могу оч много оперативки на задачу отдавать) утром на этом же хосте скрипт включает сервер терминалов, где продавцы с удаленных магазинов (латентность канала 2 мбпс по которому они цеплялись к терминалке, загруженого помимо этого всякой фигней, нетрудно представить) запускали аксапту тонкий клиент, где все вычисления проводится на выделенном сервере аксапты, а на клиенте только результат рисует.

серверы - калькуляторы имхо вполне кандидаты на то чтобы по iSCSI работать, терминалки для удаленного доступа. кстати, в теории, сервера баз данных которые транзакции пакетами сливают (2-3 мб за раз) вполне буду жить поверх iSCSI, но нужно вдумчиво тестить. вот если картина такова, что 20-30 одновременных запросов на запись по 2к-8кб + 25 запросов на чтение по 512байт-10кб это обычная ситуация, то будут тормоза (ситуация не утопическая, при локальном стораже было бы решено хорошим контроллером, в ситуации с drbd только контроллерами не обойтись) ... которые можно решить бондингом ... чем больше сетевух тем лучше ) ... но соответсно - больше слотов занято, больше портов на свиче, стойка все больше и больше на джунгли похожа )))

виртуализация избавляет от одних проблем, но приносит другие ))

Ничего, что я Вас называю «вы»? Извините, очень мне неудобно как читать, так и писать обращение к собеседнику с большой буквы в обезличенном виде.

vmdk (если речь идет о виртуализации силами VMWARE)... не помню точно, можно ли на лету изменять размер (вроде как в ESX можно, а ESXi только когда виртуалка выключена) но когда виртуалка выключена - 100 процентов можно расширить. (в винде даже можно на «лету» партицию растянуть c помощью diskpart, в linux lvm такое помоему поддерживает, не доводилось решать такие задачи)

В бесплатной ESXi нельзя добавлять новый диск на ходу. в лицензированной ESXi - можно. можно на ходу еще и сетевую карту и приводы )

И вопрос: какой сторадж от SUN Вы рассматривали?

от SUN ничего не рассматривал. хотя системы хранения данных у них тоже есть. Я имел ввиду технологию построения системы хранения данных - SAN Storage Area Network - http://ru.wikipedia.org/wiki/SAN

Хотя лично мне крайне импонирует Netapp (у них есть netapp raid dp где отсуствует такое понятие как случайная запись мелким блоком - бич любого контроллера и много других плюшек) в пользовании не имел, но оды Netapp от своего знакомого (работает в сименс) выслушиваю регулярно. Работать доводилось с сторажами от HP. Различные версии EVA (4000 4400 8000)и вариации msa2000, остальное только в теории )

SAN от любого вендора это дорого и я бы рекомендовал покупать у интегратора под конкретный проект. Контроллер в каждый сервер, пара оптических свичей, лицензирование портов на свичах, лицензирование плюшек на полках, двухголовая полка, охренеть_как_дорого диски, специфика настройки и использования, специфика прошивок контроллеров на полках, дисках, кузовах - можно очень «больно» удариться с расчетом бюджета и неверным конфигурированием.

DRBD в плане простоты выбора железок более «демократичен» но для того чтобы добится хороших иопсов нужны затраты на сетевую инфраструктуру и хорошие контроллеры и многа-многа дисков-памяти.

Возможно, есть толковые парни которые допиливают drbd до вменяемого состояния на убогом железе, но они могут быть связаны бизнес требованиями или просто не ходят на LOR форумы )))

> виртуализация избавляет от одних проблем, но приносит другие

от SUN ничего не рассматривал. хотя системы хранения данных у них тоже есть. Я имел ввиду технологию построения системы хранения данных - SAN Storage Area Network - http://ru.wikipedia.org/wiki/SAN

Понял, спасибо. Туплю.

SAN от любого вендора это дорого и я бы рекомендовал покупать у интегратора под конкретный проект. Контроллер в каждый сервер, пара оптических свичей, лицензирование портов на свичах, лицензирование плюшек на полках, двухголовая полка, охренеть_как_дорого диски, специфика настройки и использования, специфика прошивок контроллеров на полках, дисках, кузовах - можно очень «больно» удариться с расчетом бюджета и неверным конфигурированием.

Да, страшно. Пока решили не пробовать этот метод.

DRBD в плане простоты выбора железок более «демократичен» но для того чтобы добится хороших иопсов нужны затраты на сетевую инфраструктуру и хорошие контроллеры и многа-многа дисков-памяти.

Это да. Но для 70 человек я думаю, что есть смысл попробовать мне простой способ с одной сетевой картой 1GB и максимально коротким проводом. Будет Mysql. Понятно дело, что запросы там мелкие и рандомные. Но у меня также будет бонус, что чтение (я ведь пока не хочу SAN даже самодельный - точнее такую модель пока начальство отвергло, пока на двух нодах просто пробуем) будет идти с локального стораджа, а запись будет идти уже и на удалённый. Может и прокатит. Да кстати учтите, что в drbd в режиме Master-Slave со Slave ноды не получится даже читать.

Возможно, есть толковые парни которые допиливают drbd до вменяемого состояния на убогом железе

Я документацию прочитаю на оный полностью. Постараюсь что-либо понять и оптимизировать. Но сомневаюсь увидеть чудо, как мы уже с вами говорили TCP/IP, это универсальность, гибкость, но накладные расходы.

Ничего, что я Вас называю «вы»?

А как угодно. Я привык.

Извините, очень мне неудобно как читать

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

В бесплатной ESXi нельзя добавлять новый диск на ходу. в лицензированной ESXi - можно. можно на ходу еще и сетевую карту и приводы )

В KVM особо тоже насколько я понял, но да меня это не страшит. Не нужна прям космическая доступность. Не так часто это всё надо делать, один раз настроил и шурши себе на здоровье.

vmdk (если речь идет о виртуализации силами VMWARE)

Вполне допускаю, но вы вроде как интересуетесь KVM - насколько опять же я понял этого без конвертации образа VM в raw не получится сделать, даже со снапшотом работающей машины не получится ничего особого сделать, если оно в raw или vmdk, только свой формат если qcow. Но там другие заморочки, опять же с невозможностью растянуть без конвертации в raw. Для себя пока выбрал raw, потому как космическая доступность не требуется. И опять же можно попробовать lvm снапшоты.

ESXi как вы уже писали, работает у вас на брендовом железе, в общем то я с тем же столкнулся, что обычное железо трудно подобрать для теста. Особенно cетевую карту. - Поэтому пока плюнул, ибо тормозить реальные сервера для теста ESXi нету возможности. Ну и вообще как вы тут пишете, что бесплатная версия многого не умеет, это я и сам понимаю, но и конечно это ещё один минус в купе с бредновым железом в пользу KVM, ибо у нас уже есть одна контора котоую мы «кормим» и от которой зависим, она же сотрудничает с VMWARE, ребята эти любят большие деньги.

Спасибо вам за ценную беседу, за интересную информацию. Очень много нового от вас узнал.

>Это да. Но для 70 человек я думаю, что есть смысл попробовать мне простой способ с одной сетевой картой 1GB и максимально коротким проводом. Будет Mysql.

расскажите плз потом, если будет время, о результатах теста, выпуска в продакшен, крайне мало кто выкладывает такие интересные штуки (я о drbd в продакшене).

Вполне допускаю, но вы вроде как интересуетесь KVM

я такого не говорил, для меня выбор давно сделан в сторону vmware, kvm мне даже в домашних условиях не подошел (не работает на via nano хотя поддержка процом есть, тот же vmware server2 работает на ура)

в общем то я с тем же столкнулся, что обычное железо трудно подобрать для теста. Особенно cетевую карту.

http://www.vm-help.com/ вам в помощь, там есть списки протестированного десктопного! железа.

что бесплатная версия многого не умеет, это я и сам понимаю

Основные вещи по виртуализации умеет, но когда хостов больше 3 - управлять и обслуживать становится затратно по времени и чем больше хостов с гипервизором, тем больше затрат. Трачу время там, где с ESX нет проблем - мониторинг и управление железками сервера, управление питанием. ... к примеру многие железные контроллеры имеют полноценное управление только из под какойнить оси, в биосе так и написанно - хотите большего? топай в управление утилитой такой то. Приходится задумываться о лицензировании, для того чтобы не тратить время на рутину и держать руку на «пульсе» - если бизнес нуждается в этом и время администратора потраченное на рутину, будет стоить больше чем лицензирование, то почему не заплатить? ничего личного - просто бизнес )))

Спасибо вам за ценную беседу, за интересную информацию. Очень много нового от вас узнал.

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

Спасибо за ссылочку!

для того чтобы не тратить время на рутину и держать руку на «пульсе» - если бизнес нуждается в этом и время администратора потраченное на рутину, будет стоить больше чем лицензирование, то почему не заплатить? ничего личного - просто бизнес

Согласен, если не получится ничего путного из KVM и drbd- будем думать в эту сторону.

Поднял я это дело в самом простом варианте, с дубовой оптимизацией, без тонкого тюнинга - протокол С. Работает отлично в плане синхронизации. В плане скорости -> дискета быстрее пишется. Очень медленно. Буду тюнить, тестировать скорость, выложу конфиги. Но в таком виде, что есть сейчас в продакшн оно точно не годится. Без этой штуки внутри VM, последовательно копирование файлов внутри машины на саму себя показывает такое: 4 файла по 28 мб: 15-22 сек. без drbd, почти минута с drbd.

http://forums.openfiler.com/viewtopic.php?id=4087 - вот тут народ тестит, мои результаты сильно лучше чем у него при этих же командах, но есть мнение, что оно сначало обращается в дисковый кеш, а у него поди отключенно это, в общем эти тесты не одекватны по моему мнению.

Также да, советуют везде бондинг. Не знаю, очень сомневаюсь. В общем буду ковырять. И думать как одекватно протестировать и тюнить.

disk flush для drbd отключали? http://www.drbd.org/users-guide-emb/s-disable-flushes.html

почитал ссылку приведенную вами (openfiler зачетный дистриб... drbd в ядре уже вышел, очень надеюсь, что его скоро включат в openfiler ... и будет много-много тестов на этот предмет ))))) по скоростям очень похоже на то, что пишет минуя кеш на диске.

Рейд контроллеры на lsi1064 очень любят так поступать (disk flush для любой записи), на старых винтах в зеркале вообще по 6-8 мб на запись выходит )))

не пробовали с /proc/sys/vm/dirty_pages играться на нодах? железный конфиг своих нод не напишете?

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

Напишу завтра конфиг. И остальное гляну.

Пока не отключал, как раз уже близко к этому. В общем завтра. :)

Значит железки такие:

МП: MSI G31M3-F V2, что-то вроде такого. - Встроенные Сетевые карты:8111C - используются для репликации drbd, связанны качественным проводом около 15 см. длинны.

RAM: 4GB

PCI сетевые карты, для связи с ЛВС.

Intel(R) Celeron(R) CPU E3300 @ 2.50GHz - Оно с поддержкой VT. drbd практически не грузит это дело.

HDD: 160 GB под систему (инсталлятор что-то себе взял, остальное под LVM сделал для образов VM)

HDD: 80 GB отформатирован просто в ext3. И его использует ТОЛЬКО drbd.

Все HDD простые SATA.

Всё это абсолютно зеркально.

ПО: proxmox на основе Debian Linux, ядро: 2.6.18-2-pve, есть возможность установить 2.6.32 ядро, но пока не делал этого.

Да, я понимаю, что эта конфигурация не лучшая, но обращаю внимание, что это ВЫДЕЛЕННЫЕ машины, и на них больше ничего не крутится. Всё же я считаю, что результаты могут быть и лучше.

Теперь по поводу:

не пробовали с /proc/sys/vm/dirty_pages играться на нодах?

Я в тюнинге ОС Linux не особо силён. Но у меня такого и нету даже.

Вот чего у меня есть:

cat /proc/sys/vm/

block_dump flush_mmap_pages max_writeback_pages nr_pdflush_threads percpu_pagelist_fraction dirty_background_ratio hugetlb_shm_group min_free_kbytes overcommit_memory scale_vcpu_frequency dirty_expire_centisecs laptop_mode min_slab_ratio overcommit_ratio swappiness dirty_ratio legacy_va_layout min_unmapped_ratio pagecache swap_token_timeout dirty_writeback_centisecs lowmem_reserve_ratio mmap_min_addr page-cluster vfs_cache_pressure drop_caches max_map_count nr_hugepages panic_on_oom zone_reclaim_mode

Поэтому не тюнил. Но готов.

Буду сегодня вникать в тюнинг. Ибо в нынешней ситуации: подняты две VM одинаковые: (стоит пока самая банальная WinXP), на разделе LVM который без drbd всё бодро, на разделе с drbd в VM притормаживает даже интерфейс ОС, заметно при том.

Конфиг файлы drbd:

cat /etc/drbd.conf

global {

usage-count no;

}

common { syncer { rate 110M; } }

resource r0 {

protocol C;

on proxmox-52 {

device /dev/drbd1;

disk /dev/sdb1;

address 10.0.0.1:7789;

meta-disk internal;

}

on proxmox-53 {

device /dev/drbd1;

disk /dev/sdb1;

address 10.0.0.2:7789;

meta-disk internal;

}

}

rate 110M позволяет использовать всю ширину канала 1Gb. Если верить документации. Больше ничего не тюнил.

disk flush буду отключать. Но пока больше особо идей то уже и нету. Но буду продолжать читать документацию. Буду рад любым идеям. Ибо всё остальное уже работает, и меня устраивает.

Caution

You should only disable device flushes when running DRBD on devices

with a battery-backed write cache (BBWC). Most storage controllers

allow to automatically disable the write cache when the battery is

depleted, switching to write-through mode when the battery dies. It

is strongly recommended to enable such a feature.

Disabling DRBD's flushes when running without BBWC, or on BBWC with

a depleted battery, is likely to cause data loss and should not be

attempted.

Хм... Получается мне не стоит отключать это дело?

Для тестов отключить можно. это даст возможность посмотреть как быстро будет работать в «чистом» виде - как будто бы у вас есть железный контроллер с производительностью одиночного жесткого диска, write buffer на вашей ноде в районе 400мб (по умолчанию 10 процентов от системы) что очень даже неплохо. у средних контроллеров и того меньше.

Если даст прирост (а я думаю даст) то можно делать хоть какие то оценки по производительности и думать о целесообразности покупки железных контроллеров.

Обратно же думаю, что для небольших решений (надо только учитывать скорость восстановления после сбоя и возможность отката на бэкап) вполне можно сделать софтовый рейд + в обязаловку настроить управление питанием от упса. ну и бэкапы-бэкапы. даже если развалится (файло не консистентное будет) то на бэкап можно откатится. Если такой вариант (откат на бэкап) не годится - нужно думать о контроллере - ибо если бизнесу нужно обеспечить непрерывность процесса - значит он готов за это заплатить, не готов - значит пока не считал убытки во время простоя ))) хотя даже контроллер не гарантирует 100 процентное сохранение данных и потому когда время простоя не столь критично - можно использовать софтовый рейд с отключенным disk flush (а можно и вообще без рейда) Следует только утвердить план восстановления где будут описанны сроки и гарантии.

Есть у контроллера блок данных которые ему нужно записать, помещает данные в кеш и рапартует операционке что все готово, я записал на диск ... и когда диски будут действительно готовы на запись - данные будут записанны. в случае реплики drbd нужно будет еще отправить пакеты на ноду, что и будет сделано после того как контроллер скажет что он «записал!» В случае выключения питания - контроллер данные сохранит в своем кеше (срок хранения данных обусловлен батарейкой) и при подаче питания скинет эти данные на диски. Тобишь если питания не будет подано в течении этого срока - данные ала-улю. Я сталкивался с ситуацией когда выключение не было настроено, питания не было 52 часа, а батарейка (производителем заявленно 72) все равно сдохла, что было очень неприятно, откатились на бэкап ... и рукво наконецто выделило денег на нормальные упсы - потому что простой и откат на бэкап оказался дороже чем упсы.

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

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

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

Конфиг вполне нормален, единственное что меня смущает - пачкорд на 15 см - для коннекта актив-актив оборудования минимальный же 50 см? или я что то путаю? но если работает, значит работает.

о dirty_pages извините, ввел в заблуждение. есть куча параметров которые обуславливают как будут записываться dirty_pages (этакий кеш на запись write buffers) размер buffers используемых прямо сейчас можете посмотреть через top управление dirty pages осуществляется через переменные /proc/sys/vm/dirty ... продолжите табом ))

не буду портить вам понимание о том, что такое dirty pages и как его правильно готовить, своими домыслами (некое понимание у меня сложилось, но я так и не получил ни от кого подтверждения что все действительно так как я думаю, боюсь насоветовать вам неправильно) рекомендую вдумчиво погуглить о управлении виртуальной памятью в линукс, а также почитать http://communities.vmware.com/thread/146002?tstart=15 - некий гайд по оптимизации хоста для vmware server2 думается мне что в разрезе оптимизации виртуальной памяти это будет однаково верно для всех систем виртуализации.

... еще (во избежание проблем с cached страниц) рекомендую выключить своп.

Вы подкинули отличную идею.

Во первых по времени копирования, я конечно излишне расстроился. Если без drbd копирование идёт порядка 15-20 сек, а с drbd идёт порядка 50 - минуты, то я конечно погорячился, ведь очевидно ж было мне дурному, что таки да, если на другом хосте стоит такой же диск, значит уже в два раза время увеличится. + Накладные расходы.

Очень интересные идеи вы говорите, смотрите что я хочу попробовать:

Ведь планируется что слейв хост будет только принимать данные, т.е. вирт. машин на нём не будет, а значит это будет простой бесценной вычислительной мощности,

Отключить disk flush, можно к примеру ТОЛЬКО на ноде slave. И dirty_pages на slave узле можно отдать значительно больше, отключить swap (хорошо, что напомнили), дать под dirty_pages, из 4-х ГБ озу 2,5 gb и тогда ответы от хоста slave будут приходить значительно быстрее. И пропадание питания даже на обоих хостах не будет приводить к потере информации, ведь на ноде А, я не буду disk flush включать. В результате я должен получить производительность примерно за минусом 20 процентов от обычной для такого диска. Потом на ноду A можно конечно и контроллер будет прикупить, дабы ещё поднять производительность :)

Опять же конечно цена вопроса... - Чтобы была приемлемая производительность потребуются более дорогие диски, и возможно бондинг, как бы то на то не вышло, ведь ещё два хоста покупать мастер + слайв... - Я имею ввиду корзину SCSI, с построенным в ней RAID + LVM. Ибо мне думается что вполне разумным решением будет приобретенеие одного сервера + корзины, и делать в ночное время снапшоты LVM, на обычный бекап сервер. Вот и тройная отказоустойчивость, но если чего случится с этим единственным сервером, то каюк... Все машины встанут, хотя корзину можно будет куда-нибудь перебросить и хоть как-то крутить чегото.

И сейчас судя по примерам в документации не возможно отключить disk flush только на одной стороне, буду тестировать.

но скажите когда у вас был последний раз сбой системы?

Никодга uptime некоторых серверов по два года, хотя это не повод для гордости, а скорее для беспокойства, ибо я не отвечаю за успешный reboot. Но HDD летят часто, даже серверные.

В общем всё, что мне наговорили и надавали ссылок буду пробовать завтра, ибо сейчас пока имею представление лишь в теории, как собственно и описал выше.

И ещё: если вы хотите видеть результаты выполнения конкретных тестов, бенчмарки, пишите, давайте ссылки я буду тестить и выкладывать сюда.

>proxmox-52:~# cat /proc/sys/vm/dirty_

dirty_background_ratio dirty_expire_centisecs

dirty_ratio dirty_writeback_centisecs

cat /proc/sys/vm/dirty_background_ratio

10

cat /proc/sys/vm/dirty_expire_centisecs

2999

cat /proc/sys/vm/dirty_ratio

40

cat /proc/sys/vm/dirty_writeback_centisecs

499

Без политра не разобраться... Это вывод на ноде мастер.

Вот вывод с моего 127.0.0.1 у меня 3Gb памяти:

cat /proc/sys/vm/dirty_background_ratio

5

cat /proc/sys/vm/dirty_expire_centisecs

3000

cat /proc/sys/vm/dirty_ratio

10

cat /proc/sys/vm/dirty_writeback_centisecs

500

Надо вникать чего крутить. У меня стоит Ubuntu 8.10, не думаю что принципиально, хотя некоторые параметры сильно отличаются, в общем буду смотреть различия, и искать как и чего подкрутить.

размер buffers используемых прямо сейчас можете посмотреть через top

Не думаю что это оно, смотрите какие отличия! Это скорее всего просто буферизированная оперативная память для ОС и ускоренного запуска программ, не более.

Вывод top на мастер ноде:

Mem: 4028456k total, 3991600k used, 36856k free, 118620k buffers

Вот top с моего 127.0.0.1

Mem: 3111656k total, 1256952k used, 1854704k free, 42984k buffers

Опять же различия большие уж очень... По buffers,

про время затраченное на копирование, вы все верно сказали. и про вторую ноду тоже верно ... нужно только продумать о том, как будет работать вторая нода, если первая нода падет. ибо если и вторая нода падет с отключенным disk flush то будет совсем плохо.

для того, чтобы не простаивала процессорная и дисковая мощность на второй ноде, нужен актив-актив + кластерная фс )) я уже себе мозг сломал, что выгоднее - две «обконтроллерные» ноды в актив-актив или одна сверх-производительная + резервная с софтовым рейдом в примари-слейв. пока думаю, что две ноды актив-актив будут интереснее в плане возвращения вложений. кстати, если будут две ноды актив-актив, можно даже не хотсвап корзины-винты ставить (для замены без остановки), а просто планово гасить одну ноду и менять винт в выключенном состоянии (корзина не нужна, и салазки), вторая пусть за обоих отдувается )

>нужно только продумать о том, как будет работать вторая нода, если первая нода падет. ибо если и вторая нода падет с отключенным disk flush то будет совсем плохо.

Я практически не смог смоделировать такую ситуацию. Даже если на обоих питание пропадает, всё равно мы имеем консистентные данные на мастер ноде, если упадёт нода А, мы подождём пока все данные сольются с буферов - или ускорим это дело, и побежим на этой ноде.

А если молотком две ноды наколбасить, но тут сами понимаете.

Но это опять же всё в теории.

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

Про top я думаю, что был прав?

>а просто планово гасить одну ноду и менять винт в выключенном состоянии (корзина не нужна, и салазки), вторая пусть за обоих отдувается )

Ну да, мы просто слегка разные задачи решить хотим. У меня простой всех вирт. машин допустим в пределах 10-15 минут. Мне проще в этом отношении просто.

http://pve.proxmox.com/wiki/DRBD конечно врядли вам поможет, они тут LVM крутят на кластерах в актив/актив. Ну это так, может будет интересно.

скопипастил у гентушников (там обсуждалось как сэкономить электричество) в целом можно применять, ибо нужно научить ядро максимально эффективно использовать dirty pages

в идеале процесс записи dirty pages должен быть линейной записью блоком при котором дисковая выдает максимальные иопсы. самый поганый размер блока на запись для большинства контроллеров - меньше 8кб, многое конечно зависит от прошивки контроллера, но чаще всего оптимальная величина это либо 64кб либо 128 (256 более оптимален для медиаконтента на дисковых полках) но думается мне, что так тонко с параметрами не поиграться ))

/proc/sys/vm/dirty_writeback_centisecs: Как часто ядро должно проверять есть ли измененные данные для записи на диск (в сантисекундах). (6000 = 1мин) (чем реже, тем лучше, но и разумный предел должен быть, ибо увеличиватся шанс на неконсистент) /proc/sys/vm/dirty_expire_centisecs: Насколько стары должны быть данные, что бы ядро решило что они достаточно стары для записи на диск (надо тестить под нагрузкой, многое будет завить от выставляемых dirty_ratio и dirty_background_ratio и скорости физического винта) /proc/sys/vm/dirty_ratio: Максимальный размер памяти (в процентах), для хранения данных прежде чем процесс, их сгенерировавший, будет принужден записать их. (как я полагаю, именно здесь выставляется размер write buffers) /proc/sys/vm/dirty_background_ratio: Минимальное число памяти (в процентах), где позволено хранить гразные данные вместо записи на диск. Этот параметр должен быть намного меньше чем dirty_ratio что бы позволить записывать куски грязных данных за один проход. (вот тут я буксую в понимании, до тех пор пока минимум не будет достигнут эти данные не запишут на диск?)

>Не думаю что это оно, смотрите какие отличия! Это скорее всего просто буферизированная оперативная память для ОС и ускоренного запуска программ, не более.

Про top я думаю, что был прав?

для ускоренного запуска ранее запущенных программ некоторые экземпляры страниц хранятся в cached

обратите внимание, что на первой ноде, где у вас запускаются виртуалки - свободной памяти почти нет, все сожрано cached а буфферизированная оперативка - это есть буфер перед записью на диск, применяется именно для того, чтобы побыстрее вернуть ответ от дисковой, все записанно! это и преимущество и недостаток linux - более эффективная работа с дисковой подсистемой (по сравнению с той же виндой), но более опасна при ребуте по питанию.

ну а разница такая большая - у вас на нодах выделенно совершенное разное колво мб для буферов, вот и разница.

В общем уныло всё, убрал disk flush, гадость в том, что оно либо на всех нодах либо ни на одной, производительность особо не увеличилась, теже файлы на шесть секундочек шустрее скопировались. - Поиграюсь с параметрами, но что-то я как то разочарован.

Решил попробовать NFS.

попробуйте «чистую» запись на /dev/sda или какой там у вас диск, потом с drbd и включенной второй нодой, и третий тест с оффлайн второй нодой. таким образом можно будет посмотреть «чистую» производительность вашего диска, производительность drbd и второй нодой и развалив кластер можно будет увидеть как работает система с нештатной ситуации. dd if=/dev/zero of=/dev/drbd1 bs=1024k count=1000

может тормозит запись при виртуализации? у меня помнится были постоянные проблемы с kqemu где write-back на диски не работало. вы, как я понимаю kvm используете, не в курсе, чего и как там, но виртуализация дает большие пенальти на дисковую мощщу.

Стоп. В общем тут подсказали таки не поленись и проведи тест сетевой подсистемы, и таки у меня оказалось 100m, вместо гигабита...

То-то я и смотрю drbd не даёт больше 10-ки, хоть лопни. Так, что буду сперва добиваться чёткого гигабита - потом всё остальное.

Вернусь скорее всего снова к drbd. Тогда уже будет интереснее. Очень жалею, что не обратил тогда большего внимания на ваше предположение, о слишком коротком проводе, поведясь на показания ifconfig... Я думал, что если чего и будет не так карта сама перейдёт в 100мб а я увижу это в ifconfig.

>Так, что буду сперва добиваться чёткого гигабита - потом всё остальное.
iperf в помощь, только не забывай ключ --dualtest(а ещё вроде гигабит это в обе стороны)

> iperf в помощь, только не забывай ключ --dualtest(а ещё вроде гигабит это в обе стороны)

Жесть... День открытий на ЛОРе для меня. Понял, ну будет если мегабайтов 40 в секунду ходить, уже не плохо, с этим можно уже хоть что-то ворочать.

Пасибо!

* Ладно, ладно, и 35 хватит.

я гонял бэкапы по iscsi - intel 1000gt с обоих сторон. при это разгонялось до 60мб в секунду, и одно ядро у квада 8200 (на машине куда шла запись)было скушано практически на 100 процентов.

посмотрите на загрузку CPU во время тестирования. может банально не хватает скорострельности проца. если 8111C встроенная, то это тоже повлияет на производительность по записи + винты старые (80 не самые быстрые ... 45-40 мб на запись для них вроде как предел)

CPU не грузится. Смотрел.

В общем cirill, я в Пн. погляжу чего у меня всёж с гигабитом, и продолжим я думаю. :)

>если 8111C встроенная, то это тоже повлияет на производительность по записи

Провода поменял, толку нуль.

Если бы она... При дополнительном ковырянии обнаружилось что это: 8XXX чего то там... От чего я был в шоке. По всем техническим характеристикам всё равно это должен быть гигабит, поковырял, полез на оф. сайт, выгрузил исходники, собрал модуль подгрузил... Фак. Всё равно 100 мб./сек... Пустил Windows LiveCD, 100 мб/сек... Но чип в Windows также гигабитный определяется... Провода проверил... Перепроверил всё. Пошёл смотреть чего там с BIOS, до этого там были баги с RAM, я обновлялся, думаю может опять чего..? - Стянул самый свежий - толку 0. Везде 100 мб/сек, отволок это барахло к свитчу гигабитному, подключил - свитч показал 100 мб/сек. --- ЧЯДНТ? - Не ужто столь короткий кабель выжег гигабитный канал и осталось сотка..? Врядли.

Итог: купил две карточки, D-Link DGE 530-T, гигабитные - они не самые дешёвые. Принёс дамой открываю там блин, гарик лежит - в общем уже из ремонта... Блин... Вот не везёт, проверил на 127.0.0.1 - у меня правда сотка. Вроде работает.

В общем завтра надеюсь наконец то приступить.

Сори за столь длинный тред, просто немного пары спускал.

+ винты старые (80 не самые быстрые ... 45-40 мб на запись для них вроде как предел).

Не, вроде не всё так плохо. Буду тестировать теперь с sync, ну и прочие плюшки.

Буду отписывать.

И так: пока в p/p не игрался.

Значит результат таков: скорость которой мне удалось добиться на этих карточках 50 мегабайт/сек, это максимум. - iperf, в общем то тут мне сказали, что особо большего и не добиться, конечно хотелось купить карточки PCI-E, но как я понял результат был бы одинаков.

Drbd реплецировал данные с этой же скоростью.

И так, - без включения буферов, скорость линейной записи: 27.7 MB/s - мегабайтов в секунду залезает (но это не в VM, а на реальном железе). Я создал файловую систему, чтобы было шустрее, никаких LVM. В p/p конфигурации будет ещё скорее всего медленее. Весь канал гигабита очевидно, что и не используется. Если включить кеш, всё намного лучше, там выходит около 250 мегабайтов в сек. (опять же довольно очевидно, что drbd не будет успевать синхронизировать данные на такой скорости, просто скорости линка не хватит ему, это уже надо мутить бондинг как я понимаю, и очевидно, что куча данных находилось у меня в узле A, если пропадёт питание - неконсистентность получим на обоих нодах, что есть fail полный). Приобретение контроллера, приобретение шустрых ЖД улучшит ситуацию. Но, опять же если рассматривать в контексте KVM которая больше 28 мегабайтов в сек. на диск не пишет, покрайней мере без бубна в виде virtio - но с ним не тестировал ещё.

В общем если требуется что-либо бюджетное, и скорость записи на VM не требуется больше 28 мегабайтов в секунду, это при последовательной записи, при записи мелкими кусочками ИОПСЫ я думаю что ещё понизятся. То это решение подходит, при том имея две машины таких как у меня можно построить реально отказоустойчивый кластер. И использовать как минимум по три гигабайта оперативной памяти на каждой машине под VM, ещё можно включить KMS для более эффективного использования всё той же памяти, если надо крутить Linux виртуальный, то вообще можно OpenVZ позволит создать ещё их больше. В общем то, мои HDD позволяют писать как раз примерно со скоростью около 60 мегабайтов в секунду, у меня получилось около 30, получается, что drbd использует сеть весьма рационально.

В контексте других гипервизоров я не рассматриваю за не имением оных, да и железа.

Чуть позже по ссылке, что я кидал ранее, там они делают в режиме P/P, LVM, мне это не особо надо, т.к. там не стоит хранить ничего более чем файлы образов VM. Так-как они не юзают кластерную ФС, если на это дело накрутить кластерную ФС, ИОПСЫ и прочие пироги ещё упадут, это я думаю очевидно, да и в обслуживании такой системы могут потом возникнут трудности (не всю же жизнь я буду с этим ковыряться, когда то если такое внедрить то это будет обслуживать и кто-то другой, да и самому всё это помнить...).

Спрашивайте! Я если чего ещё буду пробовать, буду отписываться сюда.

Ну по скорости чтения понятно: что она такаяже как на обычном одном HDD, drbd не использует линк для чтения, что разумно.

Опять же ОЧЕНЬ благодарю за всю помощь оказанную мне! Благодаря Вам я очень многое для себя узнал и прояснил.

Да и ещё: можно вынести метаданные drbd в отдельное место, и сказать ему чтобы он её кешировал, но это опять же при некоторых ситуациях опасно, но так или иначе скорость это должно увеличить. Но не думаю, чтобы намного.

Блин, и ещё: mc вестимо показал уже меньшую скорость, т.к. это уже не /dev/zero, а реально другой HDD: и так 23,3 мегабайта, если копирование будет происходить внутри VM (себя на себя же) то вообще будет не более 10-ки ИМХО.

Кластерная ФС (я читал), в общем то надёжная штука, но это ещё минус скорость, в общем думайте сами, решайте сами...

Если надо быстро то ИМХО, нормальный storage с FibreChanel от EMC^2, + VMWARE.

Вкладываясь в OpenSource (KVM + drbd + кластерная фс) быстроты не получите, а денег на контроллеры (два контроллера уже будут стоить 1600 у.е.) и прочее железо потратите не особо меньше.

С учётом того, что KVM ой как сильно проигрывает VMware, и прочих дел, то перспектива потратить на серьёзный проект 20,000 у.е. видится мне много лучше нежели пробовать drbd.

Хотя опять же остаётся вариант: SAN, и гонять это дело по TCP/IP. Тогда я бы получил сейчас скорость 50 мегабайтов в сек. но это уже три машины, кластер из двух смотрится куда прикольнее. Хотя...

Да и ещё: учтите, что drbd имеет в своём составе вкусные плюшки, но они платные и closed source.

Добрый день.

50 мегабайт/сек, это максимум. - iperf, в общем то тут мне сказали, что особо большего и не добиться, конечно хотелось купить карточки PCI-E, но как я понял результат был бы одинаков.

Вовсе нет, PCI шина не «раскачает» полностью гигабит, нужна именно PCI-E (можно PCI-X 133 но такое уже редкость, поддержка со стороны матери опять же) карта ... да еще и jumbo frames и бла бла бла - вообщем чтобы раскачать до максимума tcpip нужно на порядок больше средств чем вложения (вложения в сетевое оборудование) на протестированный вами вариант.

ЗЫ 50 мб это всего 400 мбсп, вообще на PCI можно до 670 мбпс поднятся ... просто dlink и встроенные чипы realtec это SOHO сегмент и больше просто не потянет - для серверного сегмента рекомендую смотреть в сторону сетевых карт на чипах broadcom или intel ... стоит дороже, но проблем меньше, а производительность (и возможности) выше

>Если надо быстро то ИМХО, нормальный storage с FibreChanel от EMC^2, + VMWARE. Вкладываясь в OpenSource (KVM + drbd + кластерная фс) быстроты не получите, а денег на контроллеры (два контроллера уже будут стоить 1600 у.е.) и прочее железо потратите не особо меньше. С учётом того, что KVM ой как сильно проигрывает VMware, и прочих дел, то перспектива потратить на серьёзный проект 20,000 у.е. видится мне много лучше нежели пробовать drbd.

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

а если собирать на «коленке» то и производительность будет соответствующая. но для проектов где требуется доступность 24 на 7 и при этом не требуется много много иопсов, вполне подойдет.

Спрашивайте! Я если чего ещё буду пробовать, буду отписываться сюда.

УХ! реквестирую тест бондинг mode 0 из двух сетевых карт (100 мегабитных) соединенных кросом, без свича, (который round robin) для линка реплики между нодами! Все остальное благодоря вам подверждено практикой )

> ЗЫ 50 мб это всего 400 мбсп

Угу, тоже подсчитал.

PCI 2.1-3.0 — отличались от 2.0 возможностью одновременной работы нескольких bus-master устройств (т. н. конкурентный режим), а также появлением универсальных карт расширения, способных работать как в 5 В, так и в 3,3 В слотах (с частотой 33 и 66 МГц соответственно). Пиковая пропускная способность для 33 МГц — 133 Мбайт/с, а для 66 МГц — 266 Мбайт/с;

Это из Википедии.

Если честно повёлся на это... Решил, что должно хватить. Ну да понятно, что особо большего не добиться, но одна PCI-e карта стоит порядка 1500 руб. так, что признаться честно меня задушила жаба. А так да, была идея, т.к. на мат. платах тех нету, PCI-e X1, думал в PCI-e X8 вставить, видео всё равно не потребуется. Ну понятно дело, что от D-Link за 580 руб. не стоило чудес ждать. Блин, может и зря не потратился...

УХ! реквестирую тест бондинг mode 0 из двух сетевых карт (100 мегабитных) соединенных кросом, без свича, (который round robin) для линка реплики между нодами!

Интересная затея, уж такого добра у меня целая коробка лежит. Если round robin, то как я понимаю я получу теже 100 мб/сек, но с меньшим лайтенси? - Тогда вопрос: как протестировать лейтенси? ping'ом не очень интересно. Как увидеть профит? Трудновато будет, т.к. реплика то конечно будет перекрывать канал в разы. Единственно, что я смогу в этом разрезе увидеть, так это загрузку ЦПУ, насколько я понимаю т.к. bonding будет выполняться на ЦПУ. - Верно?

Да и ещё: планирую всё же перенести meta-data на отдельные винты, думаю, что производительность должна подрости. Насколько? - Думаю, что узнаем как только всё асилю. Сейчас есть ряд проблем специфичных для proxmox дистрибутива в этом отношении. Пока не пойму чего ему надо, и как его пнуть.

А так, в общем не плохо смотрится, из двух офисных ПК можно собрать ОТКАЗОУСТОЙЧИВЫЙ кластер, со скоростью 23 мегабайта в сек. При том использовать ПОЛНЫЕ вычислительные ресурсы КАЖДОЙ машины.

Если начальник даст время (в чём пока немного сомнения есть), я попробую p/p режим (поверх либо LVM пустить, либо кластерную ФС). Но я не планирую его внедрять, так-как профита не много, можно гонять вирт. машины без потери места с узел на узел, но мне это не очень надо, т.к ограничения KVM, c raw файлами такого не сделать, а другие форматы не очень подходят в виду своей ущщербности в плане расширения потомошнего. Да и сложности в сопровождении дальнейшем как я уже говорил, разруливания нештатных ситуаций, и т.д., когда руками при пропадании связи надо будет выяснять чего и где консистентно, а чего нет... Хотя есть мнение, что кластерная файловая система это уже всё рулит, на своём уровне, а не на уровне drbd, но это опять же надо будет очень хорошо повозиться.

В общем напишите по поводу бондинга, как от него профит посмотреть на 100 мегабитах. Уныло конечно, были бы нормальные карточки в МП, я бы замутил гигабитный программный бондинг.

пропускная способность шины pci 2.0 в 266 мбайт в секунду это пропускная способность шины ... а пропускная способность Gigabit Ethernet это уже немного не то. рекомендую прочитать начало статьи http://www.ixbt.com/comm/gig-eth-32bit.shtml о том что такое Gigabit Ethernet, кадры и почему есть нагрузка на проц, кратко и по делу.

bonding Round robin - это агрегация каналов (тоесть для бондинга нужно еще иметь «умные» свичи с агрегацией портов, либо строить два разных физ сегмента, хотя реплик линк думаю можно и напрямую парные карты на нодах коммутировать). тобишь 2 линка по 100 мбпс дадут 2 на 100 + более низкая латентность - согласитесь, что организовать 4 100 мбпс линка на комп много проще чем 4 по 1000, а в плане латентности (два линка в бондинге смотрят в сторону клиентов и обрабатывают запросы, другие два бондинг для реплик линка) это будет лучше чем два адаптера с гигабитом. опять же про стоимость (и доступность) свичей сто мбит и гигабитные свичи вспомнить и сразу захочется извлечь из сто мегабит много-много профита )))

а потестить профит от бондинга на двух сто мегабитах - сделайте реплик-линк на одной карте в 100 мбпс. нагрузите ваш drbd раздел с помощью iomert (50 на 50 чтение-запись блоком в 64кб) и замеряйте иопсы, потом сделать бондинг и снова замерить иопсы.

Да и ещё: планирую всё же перенести meta-data на отдельные винты, думаю, что производительность должна подрости. Насколько? - Думаю, что узнаем как только всё асилю.

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

ну или просто jperf натравите на реплик линк.

100 мегабитах. Уныло конечно, были бы нормальные карточки в МП, я бы замутил гигабитный программный бондинг.

не циклитесь на гигабите, в 80-90 процентов ситуациях, важнее отправить быстро-быстро 10 запросов по 64 кб, чем один но 60 мб.

Ну да понятно, что особо большего не добиться, но одна PCI-e карта стоит порядка 1500 руб. так, что признаться честно меня задушила жаба. А так да, была идея, т.к. на мат. платах тех нету, PCI-e X1, думал в PCI-e X8 вставить, видео всё равно не потребуется. Ну понятно дело, что от D-Link за 580 руб. не стоило чудес ждать. Блин, может и зря не потратился...

стесняюсь спросить, вы свои личные деньги на оборудование для проекта на работе потратили?

> на комп много проще чем 4 по 1000

Если дырок PCI хватит.

стесняюсь спросить, вы свои личные деньги на оборудование для проекта на работе потратили?

Да. Чтобы не ждать пока там счёт оплатят, пока привезут, это порядка двух - трёх недель. Сами понимаете, пока мне загорелось уже довести дело до конца, и хоть чего-то получить. Будем заказ делать очередной, я туда включу карточки поприличнее.

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

Я думаю иначе, профит будет вот в чём: как я понимаю каждое изменение отражается в meta-data области, и получается что головка диска лишний раз «отвлекается». Можно для meta-data включить кеш, но опять же не по соображенем надёжности делать этого не хочется.

Второй профит: упрощённое обслуживание: т.к. не надо мудрить у делать reduce на ФС для метаданных, т.е. восстановление в случае сбоя - много быстрее будет, вынул диск с файлами VM, подцепил куда угодно и крути их там до устранения проблем.

По остальному пока перевариваю. И по немного готовлюсь.