решение: по каким то причинам связка DRBD+HeartBeat при неоднократных перезагрузках компьютера (тесты, однако) вызвало состояние brain-split. Что было отражено в логе. А дальше - дело техники...

Если упали обе ноды и не могут синхронизировать данные (split-brain):

На ноде где есть актуальные данные:
[root@node2 ~]# drbdadm connect r1

На ноде где данные не актуальны:
[root@node1 ~]# drbdadm — --overwrite-data-of-peer primary r1

После удачной синхронизации перевести обе ноды в режим primary:
[root@node1 ~]# drbd primary r1, перемонтировать разделы mount /dev/drbd1 /data

http://zaydencorporation.blogspot.com/2 … 2-tgt.html

Обязательно необходимо дождаться пока оба синхранизируются !!!
[root@node1]# watch cat /proc/drbd

В продакшене все же лучсше CentOS использовать

С середины июня 13я федора стоит. Жалоб на неё нет. А вот с 12й - была фишка, ставил пакет drbd, а в нем нет (даже из сырцов по непонятным мне причинам на поднималась) какой-то .so библиотеки. А к 13й - никаких претензий за исключением блокировок отдельного оффтопичного компьютера на самбовом ресурсе, который сидит на glusterfs. Ну, перенес этот ресурс на drbd и проблема ушла. Знатоки местные мне на эту тему ничего не подсказали... А из Инета самая умная мысль на эту тему, что проблема могла закопаться на сети (в проводах, роутерах...). То есть никто ничего не знает.

Немного поигрался с drbd и то ли он меня в ступор загнал, то ли я его. Одним словом: сервис поднимается, но порт, заданный для синхронизации, не отрывает. В результате служба репликации не работает, хоть тресни.
Вот конфиг drbd:

global {
    usage-count no;
  }
resource res {
  protocol C;
  startup {
      degr-wfc-timeout 120;    # 2 minutes.
      wfc-timeout      10;
  }
  disk {
    on-io-error   detach;
  }
  net {
    }
  syncer {
      rate 100M;
      al-extents 257;
    }
  on test1 {
    device /dev/drbd0;
    disk   /dev/dm-2;
    address 192.168.43.39:7788;
    meta-disk  internal;
    }
  on test2 {
     device /dev/drbd0;
     disk   /dev/dm-1;
     address 192.168.43.10:7788;
     meta-disk  internal;
  }
}

Сервис стартует. Однако, если поставить параметр  wfc-timeout   в 0, то долго ждет ответа от "собеседника". "Собеседник" стоит тоже в аналогичной позиции. Если прервать ожидание, то сервис запускается сам на себя, то есть

# service drbd status
drbd driver loaded OK; device status:
version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757 
m:res  cs          ro                 ds                 p      mounted  fstype
0:res  StandAlone  Secondary/Unknown  UpToDate/DUnknown  r----

А Unknown потому, что на заказанных портах ничего не висит. Telnet отваливается напрочь. netstat -apn молчит как партизан в гестапо на тему порта 7788. В межсетевом экране разрешающая запись на этот порт присутствует.
Наведите на умную мысль...
И ведь работало же вчера и сегодня. Пока я не начал DRBD от лишних слов на стартапе и на выключении отучать...
Кстати, возврат конфига в прежний вид (без секции global) ситуацию не спасает.
===========================================
решение: по каким то причинам связка DRBD+HeartBeat при неоднократных перезагрузках компьютера (тесты, однако) вызвало состояние brain-split. Что было отражено в логе. А дальше - дело техники...
===========================
починил... и снова же завалил... нельзя очень сразу хосты, где drbd живет перезагружать, reboot'ить... "хрустальный" пакет... И как такое в продакшн заводить?