T> тот что в репозитории не совпадает с версией drbd в новом ядре T> https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1103656 так T> что были два варианта - собирать новые утилиты или откатывать ядро. T> Я сначала собрал новые утилиты, но в итоге откатил ядро. Я когда ставил все это у меня тоже при загрузке сообщалось о том что разные версии ядра и утилит, однако работать это не мешало.
>> T> 1. Да, после обновления ядра собирал userland-утилиты вручную и в скрипты >> их не добавил. >> а чем плох тот что из репозитария ? >> >> T> 2. Через 0, т.е. было написано что она начата, 0%, скорость 0, потом >> теряется. >> T> 3. Только drbd >> T> 4. Пересоздать - как я понимаю затерание метаданных это аналогично >> T> пересозданию диска - я пробовал, но в целом сотни гигабайт копировать >> дело не быстрое. >> >> T> В итоге диски и синхронизацию починил, вариантов и попыток было >> T> много, приведу окончательную последовательность действий, которые решили >> проблему. >> T> Возможно можно было обойтись без отката ядра/drbd, и начать с >> T> пункта 5 или но я на тот момент его уже сделал. >> можно и обратно сделать - зато будут достоверные данные. >> и если его не удаляли как я понял оно должно быть в списке загрузки. >> >> ПО ходу вопрос о ядрах. что за пакеты ? linux-headers-generic-lts-quantal linux-image-generic-lts-quantal >> вроде не они грузятся, но есть... а тогда зачем >> можно ли убрать их ? >> >> >> T> 1. drbdadm down all - выключить все диски на какой машине выполнялись эти команды ? осн. или дублер ? >> >> T> 2. drbdadm apply-al all - применить изменения из журналов >> T> 3. apt-get install linux-image-3.2.0-54-generic >> T> 4. Перезагрузиться с новым ядром, проверить что загрузилось 3.5 >> T> 5. Поменял secret в настройках, он у меня был со спец. символами, >> T> предположительно из-за этого команды могли выполняться неправильно >> T> если параметры спец. образом не экранировались, а судя по >> T> сообщениям об ошибках при повторным drbdadm connect они не >> T> экранируются. Оставил только буквы и цифры. >> T> 6. На сервере со вторичными дисками drbdadm down all для выключения дисков >> T> 7. На сервере с первичными дисками drbdadm disconnect all; drbdadm >> connect all >> T> 8. На сервере со вторичными дисками drbdadm up all >> >> T> После этого синхронизация пошла. В этот момент на сервере с >> T> первичными дисками работал drbd 8.4 на сервере со вторичными 8.3 >> T> Затем переключил все сервисы на запасной сервер и сделал downgrade ядра и >> drbd на первом сервере. >> >>>> 1. а почему надо делать вручную поднятия дисков для зеркала ? >>>> автомат не прописан ? >>>> >>>> 2. Синхр начиначется и через сколько процентов теряется? >>>> >>>> 3. У вас только DrBD или HB еще ? >>>> >>>> 4. Есть ли резон возиться с дисками дублерами, если их можно >>>> пересоздать и заполнить заново с основных? >>>> >>>> >>>> >>>> T> DRBD вошел в странное состояние >>>> >>>> T> Есть два сервера, на них настроено несколько дисков, >>>> T> синхронизирующихся по DRBD (в основном 10-50Гб), диски поверх LVM. >>>> T> Всё работало хорошо, пока я не перезагрузил сервер с secondary-дисками. >>>> >>>> T> Перезагружаю вторичный сервер. делаю drbdadm up all >>>> >>>> T> По моим представлениям он должен за несколько секунд всё >>>> T> синхронизировать и войти в обычное состояние (операций записи не много). >>>> T> Что получается на практике: >>>> T> 1. Для дисков на которы запись не идет вообще синхронизация >>>> T> занимает 5-10 минут. (очень медленное переключение между состояниями >>>> синхронизации) >>>> T> 2. Для дисков на которые идет запись синхронизация не проходит: >>>> T> сначала она вроде как начинается, но скорость синхронизации >>>> T> показывается 0, затем она обрывается как бы по ошибке сети и через >>>> T> несколько минут ситуация повторяется и зацикливается. >>>> >>>> T> Вот так жто выглядит со стороны Primary >>>> T> SyncSource Primary/Secondary UpToDate/Inconsistent C r---n- >>>> T> [>....................] sync'ed: 0.1% >>>> T> (32764/32764)Mfinish: 652:25:36 speed: 0 (0) K/sec >>>> >>>> T> Через пару минут связь теряется с переходит в WFConnection >>>> >>>> T> Со стороны Secondary связь теряется после WFSyncUUID и вместо >>>> T> SyncTarget переходит в NetworkFailure. >>>> >>>> T> Связь между серверами хорошая (iperf показывает 600Мбит, ping >>>> T> показывает задержку 0.2-0.3 милисекунды и 0% потерь). >>>> >>>> T> Перезагрузка обоих серверов не помогла. >>>> T> Кроме перезагрузки пробовал вручную выставлять скорость >>>> T> синхронизации, пересоздавать метаданные на одном из вторичных дисков. >>>> >>>> T> Попробовал создать новый диск, он синхронизируется хорошо, за >>>> T> несколько секунд как и должно быть. >>>> >>>> T> Система: Ubuntu 12.04 64-bit >>>> T> cat /proc/drbd >>>> T> version: 8.4.2 (api:1/proto:86-101) >>>> T> srcversion: 18C7EBE1B3F8CCCB5CF512C >>>> >>>> T> Ввиду того бага что ядро в ubuntu обновилось, а userspace-утилиты >>>> T> нет - утилиты собраны вручную, модуль из дистрибутива. >>>> >>>> T> Как заставить синхронизироваться старые диски и/или включить >>>> T> какие-то подробные логи откуда будет понятно что происходит. >>>> >>>> >>>> >>>> -- >>>> С уважением, >>>> Роман mailto:idi...@rambler.ru >>>> >>>> >>>> -- >>>> ubuntu-ru mailing list >>>> ubuntu-ru@lists.ubuntu.com >>>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-ru >> >> >> >> >> -- >> С уважением, >> Роман mailto:idi...@rambler.ru >> >> >> -- >> ubuntu-ru mailing list >> ubuntu-ru@lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-ru -- С уважением, Роман mailto:idi...@rambler.ru -- ubuntu-ru mailing list ubuntu-ru@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-ru
