Drbd настройка

Подскажите пожалуйста, не получается настроить drbd на 2 нодах. На каждой ноде имеется 1 жесткий диск /dev/sda, который разбит на 3 раздела: sda1 под /, sda2 под drbd, sda3 под своп.

После настройки drbd.conf и создания ресурса с помощью drbdadm create пытаюсь запустить drbd и в результате получаю след.ошибку: Lower device is already claimed. This usually means it is mounted.

Т.е. получается, что нельзя использовать раздел диска, а нужен отдельный диск? Если нет, то как это можно победить?
Вот настройка drbd.conf:

<code>

global { usage-count yes; }
common { syncer { rate 150M; } }
resource r0 {
protocol C;
startup {
}
disk {
on-io-error detach;
}
net {
}
on drbd1 {
device /dev/drbd0;
disk /dev/sda2;
address 192.168.0.1:7789;
meta-disk internal;
}
on drbd2 {
device /dev/drbd0;
disk /dev/sda2;
address 192.168.0.2:7789;
meta-disk internal;
}
}
<code>

safronowmax написал:

Подскажите пожалуйста, не получается настроить drbd на 2 нодах. На каждой ноде имеется 1 жесткий диск /dev/sda, который разбит на 3 раздела: sda1 под /, sda2 под drbd, sda3 под своп.

В конфиге я ошибок не увидел. А вот ответь на простой вопрос - форматировал ли ты /dev/sda2? Смонтировал ли этот девайс?
Обязательное условие для создания drbd-кластера - это надо иметь сырой, неформатированный и несмонтированный раздел|диск. Хотя, можно и форматированный раздел|диск иметь, но нельзя его монтировать в файловую систему. Тогда drbdadm форматирование сам порушит (с небольшой ругачкой, создаст и проинициализирует кластер, а затем уже можно будет на девайсе /dev/drbd0 создать нужную файловую систему и смотировать его в нужное место.

И еще: drbd - достаточно хрустальная система. Часто в ней расщепление мозга возникает. А синхронизация - достаточно тормозная. Не рекомендую создавать drbd-диски больше 32 гигабайт. Восстанавливаются за достаточно разумное время на гигабитной сетке.
Есть альтернатива - glusterfs. Ставится и настраивается много проще. Но... На гластере очень плохо 1С сетевая живет, проблемы с блокировками. А на drbd - идеально.

Cruiser78, спасибо большое

В двух словах можно. Что за зверь? ФС которая синхронизируется с такой же удаленной ФС? Т.е. например база 1С на одном конце поработала, то пользователи на другом получают тот же эффект? А в реальном времени как?

--=XliN=-- написал:

В двух словах можно. Что за зверь? ФС которая синхронизируется с такой же удаленной ФС? Т.е. например база 1С на одном конце поработала, то пользователи на другом получают тот же эффект? А в реальном времени как?

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

Слово второе - остальные вопросы тоже не совсем в тему. Здесь - иное. И drbd и glusterfs это средства создания кластерной отказоустойчивой файловой системы. То есть разнесенной на несколько физических серверов и в on-line синхронизирующих их.
Вот только смонтировать drbd-том можно только на том сервере, на котором он объявлен как primary-том. На secondary-сервере drbd-том не виден. Сервер только поддерживает актуальную копию. А вот с glusterfs - иначе. Кластерные тома гластера можно монтировать где угодно и сколько угодно (правда, безопасность только на уровне ip-адресов). То есть под файловое хранилище можно отвести одни компьютеры, а раздавать файловую систему юзерям - с другого компьютера, где эти гластерные тома смонтировать. Но работать с данными, хранящимися в томах glusterfs, надо только через смонтированную точку. Напрямую лезть к этим файлам нельзя. Хотя они прекрано видны. Хотя соврал немного, я антивирусный монитор как раз не на glusterfs напускаю, а под него. И только по результатам анализа - скрипт работает над гластером. Так эффективнее.
С drbd будешь эффективно раздавать только с primary-сервера. Или надо будет прокидывать эту файловую систему раздающему серверу.

Далее: drbd - организует только (если мне склероз не изменяет) зеркало, а на glusterfs организовать можно и зеркало, и стрип и многое иное. Принцип работы этих кластеров - разный. drbd синхронизирует тома "посекторно", он не знает ничего про файловые системы, он работает на уровне тома. И будет полностью поддерживать в отказоустойчивом кластере ту файловую систему, которую на него накатишь. Со всеми её плюшками. Именно поэтому великая и ужасная 1С работоспособна на кластере, построенном на drbd. Работоспособна так же, как и на обычном локальном диске. Ибо нет там для неё разницы никакой.
А вот glusterfs построен иначе - он есть надстройка над файловой системой (ext3, ext4) синхронизирует не тома, а файлы на них. Однако некоторые вещи, например, блокировки, отрабатывает криво. Настолько криво, что если раздать такой том через самбу, то великий и ужасный 1С спотыкается на нём. А если еще этот 1С живет в wine@etersoft, то тот wine путается в дисках и пишет, что задача не может одноврененно работать с сетевыми и локальными данными...
--------------
Уточнение - данное замечание справедиво для etercifs версии 4.8.0 с дефолтным содержанием /etc/security/limits.conf. На версии 4.8.2 с большим количеством открывемых файлов такого не наблюдаю.
-------------
А из виндов - так просто молча индексы рушатся... Ну и MS-Office, один из последних, при открытии гластерных файлов зависает напрочь. Хотя - Office XP на это состояние кладет с прибором...

Отсюда - если делаем отказоустойчивую файлопомойку большого объема, то glusterfs - то что доктор прописал. А вот если наша задача - совместная работа в офисных (от MS) приложениях, работа 1С 7.7, то под это дело надо ставить небольшой диск drbd. Большой не надо, иначе будешь часами его синхронизировать, когда ему brian split придет. А он придет обязательно. В гластере же эта проблема решается не синхронизацией целого тома, а только синхронизацией отдельного проблемного файла. Что на порядки быстрее.

Ну и еще, про ремутную систему. Последние версии guster'а поддерживают уже не локальную репликацию данных, а гео-репликацию. То есть позволяют реплицировать данные уже на ремутные сервера через интернет. Делают это, как я понял - через rsync. Как оно работает - не скажу, еще не пробовал.