LINUX.ORG.RU
Форум — Admin  

DRBD Самопроизвольный Split Brain

 


0

1

Сегодня на ровном месте, развалился DRBD Nov 30 00:36:18 h10-g04 kernel: [196445.905240] d-con r0: BAD! BarrierAck #166000 received, expected #165997! Nov 30 00:36:18 h10-g04 kernel: [196445.905297] d-con r0: peer( Primary -> Unknown ) conn( Connected -> ProtocolError ) pdsk( UpToDate -> DUnknown ) Nov 30 00:36:18 h10-g04 kernel: [196445.905407] d-con r0: asender terminated Nov 30 00:36:18 h10-g04 kernel: [196445.905411] d-con r0: Terminating drbd_a_r0 Nov 30 00:36:18 h10-g04 kernel: [196445.906535] block drbd0: new current UUID 58B737EB6BD012D7:82D45032D4CE03F3:2060162711238649:205F162711238649 Nov 30 00:36:18 h10-g04 kernel: [196446.534078] d-con r0: Connection closed Nov 30 00:36:18 h10-g04 kernel: [196446.534133] d-con r0: conn( ProtocolError -> Unconnected ) Nov 30 00:36:18 h10-g04 kernel: [196446.534136] d-con r0: receiver terminated Nov 30 00:36:18 h10-g04 kernel: [196446.534138] d-con r0: Restarting receiver thread Nov 30 00:36:18 h10-g04 kernel: [196446.534140] d-con r0: receiver (re)started Nov 30 00:36:18 h10-g04 kernel: [196446.534150] d-con r0: conn( Unconnected -> WFConnection ) Nov 30 00:36:19 h10-g04 kernel: [196447.034442] d-con r0: Handshake successful: Agreed network protocol version 101 Nov 30 00:36:19 h10-g04 kernel: [196447.034506] d-con r0: conn( WFConnection -> WFReportParams ) Nov 30 00:36:19 h10-g04 kernel: [196447.034510] d-con r0: Starting asender thread (from drbd_r_r0 [4017]) Nov 30 00:36:19 h10-g04 kernel: [196447.430809] block drbd0: drbd_sync_handshake: Nov 30 00:36:19 h10-g04 kernel: [196447.430816] block drbd0: self 58B737EB6BD012D7:82D45032D4CE03F3:2060162711238649:205F162711238649 bits:76940 flags:0 Nov 30 00:36:19 h10-g04 kernel: [196447.430820] block drbd0: peer 61135D796A0E51C1:82D45032D4CE03F3:2060162711238648:205F162711238649 bits:77052 flags:0 Nov 30 00:36:19 h10-g04 kernel: [196447.430823] block drbd0: uuid_compare()=100 by rule 90 Nov 30 00:36:19 h10-g04 kernel: [196447.430829] block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0 Nov 30 00:36:19 h10-g04 kernel: [196447.433782] block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0 exit code 0 (0x0) Nov 30 00:36:19 h10-g04 kernel: [196447.433803] block drbd0: Split-Brain detected but unresolved, dropping connection! Nov 30 00:36:19 h10-g04 kernel: [196447.433818] block drbd0: helper command: /sbin/drbdadm split-brain minor-0 Nov 30 00:36:19 h10-g04 kernel: [196447.436545] block drbd0: helper command: /sbin/drbdadm split-brain minor-0 exit code 0 (0x0) Nov 30 00:36:19 h10-g04 kernel: [196447.436586] d-con r0: conn( WFReportParams -> Disconnecting ) Nov 30 00:36:19 h10-g04 kernel: [196447.436590] d-con r0: error receiving ReportState, e: -5 l: 0! Nov 30 00:36:19 h10-g04 kernel: [196447.436629] d-con r0: asender terminated Nov 30 00:36:19 h10-g04 kernel: [196447.436640] d-con r0: Terminating drbd_a_r0 Nov 30 00:36:19 h10-g04 kernel: [196447.436763] d-con r0: Connection closed Nov 30 00:36:19 h10-g04 kernel: [196447.436809] d-con r0: conn( Disconnecting -> StandAlone ) Nov 30 00:36:19 h10-g04 kernel: [196447.436812] d-con r0: receiver terminated Nov 30 00:36:19 h10-g04 kernel: [196447.436814] d-con r0: Terminating drbd_r_r0



Последнее исправление: valmon (всего исправлений: 2)
← Нормально не работает nfsen.
Каким механизмом подать сигнал при старте демона и обработать его в другом демоне? →

Продолжаем, сегодня вылетело сразу две пары. 

Dec  1 05:47:58 h09-g04 kernel: [297344.071799] d-con r0: PingAck did not arrive in time.
Dec  1 05:47:58 h09-g04 kernel: [297344.071842] d-con r0: peer( Primary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
Dec  1 05:47:58 h09-g04 kernel: [297344.071873] block drbd0: new current UUID B3CFA168127B7883:341E54A0A57780AD:61145D796A0E51C1:61135D796A0E51C1
Dec  1 05:47:58 h09-g04 kernel: [297344.074015] d-con r0: asender terminated
Dec  1 05:47:58 h09-g04 kernel: [297344.074029] d-con r0: Terminating drbd_a_r0
Dec  1 05:47:58 h09-g04 kernel: [297344.075932] d-con r0: ASSERTION FAILED: tconn->current_epoch->list not empty
Dec  1 05:47:58 h09-g04 kernel: [297344.075943] d-con r0: Connection closed
Dec  1 05:47:58 h09-g04 kernel: [297344.076030] d-con r0: conn( NetworkFailure -> Unconnected )
Dec  1 05:47:58 h09-g04 kernel: [297344.076033] d-con r0: receiver terminated
Dec  1 05:47:58 h09-g04 kernel: [297344.076035] d-con r0: Restarting receiver thread
Dec  1 05:47:58 h09-g04 kernel: [297344.076037] d-con r0: receiver (re)started
Dec  1 05:47:58 h09-g04 kernel: [297344.076047] d-con r0: conn( Unconnected -> WFConnection )
Dec  1 05:48:01 h09-g04 kernel: [297346.779736] d-con r0: Handshake successful: Agreed network protocol version 101
Dec  1 05:48:01 h09-g04 kernel: [297346.779804] d-con r0: conn( WFConnection -> WFReportParams )
Dec  1 05:48:01 h09-g04 kernel: [297346.779808] d-con r0: Starting asender thread (from drbd_r_r0 [23119])
Dec  1 05:48:01 h09-g04 kernel: [297346.847718] block drbd0: drbd_sync_handshake:
Dec  1 05:48:01 h09-g04 kernel: [297346.847725] block drbd0: self B3CFA168127B7883:341E54A0A57780AD:61145D796A0E51C1:61135D796A0E51C1 bits:0 flags:0
Dec  1 05:48:01 h09-g04 kernel: [297346.847729] block drbd0: peer EAA2C1244AF095A7:341E54A0A57780AD:61145D796A0E51C0:61135D796A0E51C1 bits:0 flags:0
Dec  1 05:48:01 h09-g04 kernel: [297346.847733] block drbd0: uuid_compare()=100 by rule 90
Dec  1 05:48:01 h09-g04 kernel: [297346.847738] block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0
Dec  1 05:48:01 h09-g04 kernel: [297346.850498] block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0 exit code 0 (0x0)
Dec  1 05:48:01 h09-g04 kernel: [297346.850514] block drbd0: Split-Brain detected but unresolved, dropping connection!
Dec  1 05:48:01 h09-g04 kernel: [297346.850528] block drbd0: helper command: /sbin/drbdadm split-brain minor-0
Dec  1 05:48:01 h09-g04 kernel: [297346.853280] block drbd0: helper command: /sbin/drbdadm split-brain minor-0 exit code 0 (0x0)
Dec  1 05:48:01 h09-g04 kernel: [297346.853313] d-con r0: conn( WFReportParams -> Disconnecting )
Dec  1 05:48:01 h09-g04 kernel: [297346.853317] d-con r0: error receiving ReportState, e: -5 l: 0!
Dec  1 05:48:01 h09-g04 kernel: [297346.853333] d-con r0: asender terminated
Dec  1 05:48:01 h09-g04 kernel: [297346.853336] d-con r0: Terminating drbd_a_r0
Dec  1 05:48:01 h09-g04 kernel: [297346.853479] d-con r0: ASSERTION FAILED: tconn->current_epoch->list not empty
Dec  1 05:48:01 h09-g04 kernel: [297346.853488] d-con r0: Connection closed
Dec  1 05:48:01 h09-g04 kernel: [297346.853570] d-con r0: conn( Disconnecting -> StandAlone )
Dec  1 05:48:01 h09-g04 kernel: [297346.853575] d-con r0: receiver terminated
Dec  1 05:48:01 h09-g04 kernel: [297346.853577] d-con r0: Terminating drbd_r_r0
Dec  1 06:47:09 h09-g04 kernel: [300895.094829] d-con r2: PingAck did not arrive in time.
Dec  1 06:47:09 h09-g04 kernel: [300895.094871] d-con r2: peer( Primary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
Dec  1 06:47:09 h09-g04 kernel: [300895.094905] block drbd2: new current UUID AACD5B59EF7311E9:303804FD3622EF3B:CAA8B3550C2FD812:CAA7B3550C2FD813
Dec  1 06:47:09 h09-g04 kernel: [300895.095649] d-con r2: asender terminated
Dec  1 06:47:09 h09-g04 kernel: [300895.095660] d-con r2: Terminating drbd_a_r2
Dec  1 06:47:09 h09-g04 kernel: [300895.102432] d-con r2: Connection closed
Dec  1 06:47:09 h09-g04 kernel: [300895.102534] d-con r2: conn( NetworkFailure -> Unconnected )
Dec  1 06:47:09 h09-g04 kernel: [300895.102539] d-con r2: receiver terminated
Dec  1 06:47:09 h09-g04 kernel: [300895.102541] d-con r2: Restarting receiver thread
Dec  1 06:47:09 h09-g04 kernel: [300895.102543] d-con r2: receiver (re)started
Dec  1 06:47:09 h09-g04 kernel: [300895.102554] d-con r2: conn( Unconnected -> WFConnection )
Dec  1 06:47:09 h09-g04 kernel: [300895.290271] d-con r2: initial packet S crossed
Dec  1 06:47:10 h09-g04 kernel: [300895.788903] d-con r2: Handshake successful: Agreed network protocol version 101
Dec  1 06:47:10 h09-g04 kernel: [300895.788959] d-con r2: conn( WFConnection -> WFReportParams )
Dec  1 06:47:10 h09-g04 kernel: [300895.788963] d-con r2: Starting asender thread (from drbd_r_r2 [25951])
Dec  1 06:47:10 h09-g04 kernel: [300895.838951] block drbd2: drbd_sync_handshake:
Dec  1 06:47:10 h09-g04 kernel: [300895.838973] block drbd2: self AACD5B59EF7311E9:303804FD3622EF3B:CAA8B3550C2FD812:CAA7B3550C2FD813 bits:0 flags:0
Dec  1 06:47:10 h09-g04 kernel: [300895.838977] block drbd2: peer 7CA83543E05941A1:303804FD3622EF3B:CAA8B3550C2FD813:CAA7B3550C2FD813 bits:0 flags:0
Dec  1 06:47:10 h09-g04 kernel: [300895.838982] block drbd2: uuid_compare()=100 by rule 90
Dec  1 06:47:10 h09-g04 kernel: [300895.839032] block drbd2: helper command: /sbin/drbdadm initial-split-brain minor-2
Dec  1 06:47:10 h09-g04 kernel: [300895.841806] block drbd2: helper command: /sbin/drbdadm initial-split-brain minor-2 exit code 0 (0x0)
Dec  1 06:47:10 h09-g04 kernel: [300895.841824] block drbd2: Split-Brain detected but unresolved, dropping connection!
Dec  1 06:47:10 h09-g04 kernel: [300895.841838] block drbd2: helper command: /sbin/drbdadm split-brain minor-2
Dec  1 06:47:10 h09-g04 kernel: [300895.846004] block drbd2: helper command: /sbin/drbdadm split-brain minor-2 exit code 0 (0x0)
Dec  1 06:47:10 h09-g04 kernel: [300895.846039] d-con r2: conn( WFReportParams -> Disconnecting )
Dec  1 06:47:10 h09-g04 kernel: [300895.846043] d-con r2: error receiving ReportState, e: -5 l: 0!
Dec  1 06:47:10 h09-g04 kernel: [300895.846061] d-con r2: asender terminated
Dec  1 06:47:10 h09-g04 kernel: [300895.846063] d-con r2: Terminating drbd_a_r2
Dec  1 06:47:10 h09-g04 kernel: [300895.846237] d-con r2: Connection closed
Dec  1 06:47:10 h09-g04 kernel: [300895.846370] d-con r2: conn( Disconnecting -> StandAlone )
Dec  1 06:47:10 h09-g04 kernel: [300895.846373] d-con r2: receiver terminated
Dec  1 06:47:10 h09-g04 kernel: [300895.846375] d-con r2: Terminating drbd_r_r2
Это при том, что r0 вообще не использовался, r2 одна виртуалка. В тоже время, на r1 был запущен fio, а с ним все ok 
[root@h09-g04 doc]# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 19422058F8A2D4AC0C8EF09
 0: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r-----
    ns:2082701376 nr:133462312 dw:66239592 dr:1911377524 al:15623941 bm:117962 lo:0 pe:0 ua:0 ap:0 ep:4 wo:f oos:0
 1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:168667536 dw:168667536 dr:652 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 2: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r-----
    ns:0 nr:31329 dw:382313 dr:46796 al:54 bm:11 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

valmon
() автор топика
Ответ на: комментарий от valmon

У тебя dual-primary режим чтоли? Ну тогда ты знал на что идёшь. Решать проблемы сплит брейна нужно руками или скриптами-хендлерами в конфиге.

А по поводу причины - ну тут ясно сказано, что у тебя явные проблемы с сетью (PingAck did not arrive in time) и, возможно, барьеры криво настроены (BarrierAck #166000 received, expected #165997!). Конфиг в студию и схему сети репликации.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Да, оба примари, конфиг самый что не наесть дефолтный 

resource r0 {
        protocol C;
        syncer {
        rate 150M;
        }
        on h10-g04.horttel.ru {
                address 10.10.104.10:7780;
                       device /dev/drbd0;
                       disk /dev/sdd;
                       meta-disk internal;
        }
        on h09-g04.horttel.ru {
                address 10.10.104.9:7780;
                       device /dev/drbd0;
                       disk /dev/sdd;
                       meta-disk internal;
        }
}

[root@h09-g04 ~]# cat /etc/drbd.d/global_common.conf
global {
        usage-count yes;
        # minor-count dialog-refresh disable-ip-verification
}

common {
        handlers {
                # These are EXAMPLE handlers only.
                # They may have severe implications,
                # like hard resetting the node under certain circumstances.
                # Be careful when chosing your poison.

                # pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
                # pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
                # local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
                # fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
                # split-brain "/usr/lib/drbd/notify-split-brain.sh root";
                # out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
                # before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 -- -c 16k";
                # after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh;
        }

        startup {
                # wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb
        }

        options {
                # cpu-mask on-no-data-accessible
        }

        disk {
                # size max-bio-bvecs on-io-error fencing disk-barrier disk-flushes
                # disk-drain md-flushes resync-rate resync-after al-extents
                # c-plan-ahead c-delay-target c-fill-target c-max-rate
                # c-min-rate disk-timeout
        }

        net {
                # protocol timeout max-epoch-size max-buffers unplug-watermark
                # connect-int ping-int sndbuf-size rcvbuf-size ko-count
                # allow-two-primaries cram-hmac-alg shared-secret after-sb-0pri
                allow-two-primaries;
                # after-sb-1pri after-sb-2pri always-asbp rr-conflict
                # ping-timeout data-integrity-alg tcp-cork on-congestion
                # congestion-fill congestion-extents csums-alg verify-alg
                # use-rle
        }
}
Конфиг, сети, пара интерфейсов в бондинг ( lacp ) идет через один коммутатор

valmon
() автор топика
Ответ на: комментарий от blind_oracle

Все это на базе xenserver 6.5 89346c

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

valmon
() автор топика
Ответ на: комментарий от valmon

А зачем тебе вообще dual primary то? С протоколом С ты всё равно упираешься в скорость, да и 2 интерфейса в лакп не дадут выше гигабита вылезть скорее всего.

Сделай primary/secondary и всё будет хорошо, никакой головной боли.

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

Дык эта. Есть в конфиге параметр timeout - по-моему это именно оно 

timeout time
If the partner node fails to send an expected response packet within time tenths of a second, the partner node is considered dead and therefore the TCP/IP connection is abandoned. This must be lower than connect-int and ping-int. The default value is 60 = 6 seconds, the unit 0.1 seconds.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Пока для обкатки, хватает и гигабита, бондинг для отказоустойчивости, если все пройдет нормально, перейдем на 10Gb. А вот с таймаутом, может быть, но если судить по логам, он не блокирует запись, да и по тексту, тоже не упоминается про это.

valmon
() автор топика
Ответ на: комментарий от valmon

Ну как не блокирует. У тебя логика какая:

1. Блок на запись прилетел и встал в очередь

2. Записался локально и ждёт записи на соседнюю ноду

3. Записи на соседнюю ноду не происходит, блок висит в очереди

4. Очередь забивается и новые записи не проходят

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

valmon
() автор топика
Ответ на: комментарий от valmon

PingAck did not arrive in time

Тут тебе нужно 

ping-int time
If the TCP/IP connection linking a DRBD device pair is idle for more than time seconds, DRBD will generate a keep-alive packet to check if its partner is still alive. The default is 10 seconds, the unit is 1 second.

ping-timeout time
The time the peer has time to answer to a keep-alive packet. In case the peer's reply is not received within this time period, it is considered as dead. The default value is 500ms, the default unit are tenths of a second.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Но насчет ping-timeout и ping-int, а для чего его менять, пускай он уходит в дисконект, но чтобы в момент дисконекта, останавливалась запись. Могу конечно ошибаться, но мне кажется лучше приостановить все транзакции, предположим на 10 секунд, в случае восстановления подключения, продолжаем.

valmon
() автор топика
Ответ на: комментарий от valmon

Какой тогда смысл в дрбд? Он должен оказывать услуги даже при смерти второй ноды. А у тебя в таком случае всё залипнет и всё.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Оно залипнет на время таймаута, в нормальной ситуации коннект отваливается не каждый день.

valmon
() автор топика
Ответ на: комментарий от blind_oracle

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

valmon
() автор топика
Ответ на: комментарий от valmon

Но зато вероятность схватить две ноды живущие каздая сама по себе минимальная

Вон у тебя каждый раз сплитбрейн случается я смотрю :) 

Split-Brain detected but unresolved, dropping connection
у меня же его в режиме primary/secondary ни разу не было да дофига лет работы DRBD-ы. Если у тебя качественный канал между нодами и отказоустойчивая heartbeat сеть (для менеджера кластера), то сплитбрейна добиться нужно очень постараться.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Да я же не спорю)), что примари/секондари надежней. Я свою точку зрения говорю, и сказал почему схватываю сплитбрейн, и свои мысли как этого избежать. Разве мои мысли не правильные? Десять секунд suspend-io в момент дисконнекта это много?

valmon
() автор топика
Ответ на: комментарий от valmon

Та не, не много, просто противоречит концепции работы DRBD - доступность при падении другой ноды. Поэтому i/o оно не суспендит, да и зачем.

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

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

В общем - не советую.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Так доступность, она есть, сиспенд ио на 10 секунд раз в месяц это копейки, если концепт DRBD потерять валидную копию при малейшем чихе ( ну мало ли что, по ошибке вытащили патчкорд и снова воткнули ), это очень печально. Весь энтерпрайз живет на таймаутах перед сменой пути, да, в этот момент ввод вывод замирает ,так как бывает что альтернативный путь не работает.

valmon
() автор топика
Ответ на: комментарий от valmon

ну мало ли что, по ошибке вытащили патчкорд и снова воткнули

Как-то это с энтерпрайзом не очень соотносится :) А что у тебя поверх DRBD вертится? Кластерная ФС какая-то?

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

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

Насчет остановки IO в DRBD - такой механизЬм есть: 

fencing resource-and-stonith
...
If a node becomes a disconnected primary, it freezes all its IO operations and calls its fence-peer handler. The fence-peer handler is supposed to reach the peer over alternative communication paths and call 'drbdadm outdate res' there. In case it cannot reach the peer it should stonith the peer. IO is resumed as soon as the situation is resolved. In case your handler fails, you can resume IO with the resume-io command.
Т.е. оно замораживает IO и ждёт ответа от скрипта который должен дать соседу по башке. Можно просто в скрипте сделать sleep 10. Он подождёт и восстановит IO. Можно просто там сделать exit 1 и он посчитает что скрипт не выполнил задачу и оживлять IO нужно будет вручную.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Как-то это с энтерпрайзом не очень соотносится :)

Патчик запутался. надо распутать)

А что у тебя поверх DRBD вертится? Кластерная ФС какая-то?

Поверх iscsi targett и lvm

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

Вот для этого и нужен примари/примари

fencing resource-and-stonith

Я так понимаю это триггер некий?

valmon
() автор топика
Ответ на: комментарий от valmon

Поверх iscsi targett и lvm

Ты, часом, не round-robin используешь доступа к таргетам? А то можно много геморроя обрести т.к. iscsi таргеты не реплицируют всякие SCSI reservations между нодами где у тебя они крутятся.

Вот для этого и нужен примари/примари

Оно для этого совсем не нужно. Для этого нужен менеджер кластера (pacemaker) который через несколько секунд после падения основной ноды переведёт резервную в режим праймари и виртуалки этого даже не заметят. Проверено, рубили по питанию и т.п.

Я так понимаю это триггер некий?

Это просто опция в конфиге. При ее установке будет вызваться скрипт, указанный в опции fence-peer. Подробнее читать http://www.drbd.org/users-guide/re-drbdconf.html

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Ты, часом, не round-robin используешь доступа к таргетам? А то можно много геморроя обрести т.к. iscsi таргеты не реплицируют всякие SCSI reservations между нодами где у тебя они крутятся.

SCSI reservations это из области вмваре, там файловая системы, мы же используем мультипас.

Оно для этого совсем не нужно. Для этого нужен менеджер кластера (pacemaker) который через несколько секунд после падения основной ноды переведёт резервную в режим праймари и виртуалки этого даже не заметят. Проверено, рубили по питанию и т.п.

Я себе это очень трудно представляю, что произойдет с транзакциями ожидающими завершение, в случае примари/примари, мультипас отработает.

valmon
() автор топика
Ответ на: комментарий от valmon

SCSI reservations это из области вмваре, там файловая системы

Это из разных областей. Оно много где используется, в т.ч. в виндовых кластерах встроенных. Плюс есть такие штуки как COMPARE_AND_WRITE (оно же Atomic Test and Set), которые блокируют не весь лун а нужные сектора. Их состояние тоже нужно реплицировать если оно используется.

мы же используем мультипас.

Всмысле? Режешь лун на кусочки в LVM и отдаешь напрямую виртуалкам или как?

Я себе это очень трудно представляю, что произойдет с транзакциями ожидающими завершение, в случае примари/примари, мультипас отработает.

В случае с вмваре он их просто повторяет на другом таргете, никаких проблем.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Всмысле? Режешь лун на кусочки в LVM и отдаешь напрямую виртуалкам или как?

Примерно вот так 

[root@h10-g04 log]# multipath -ll
1IET_00010001 dm-1 VENDOR1,VIRTUAL-DISK
size=1.8T features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=0 status=enabled
| `- 8:0:0:1 sde 8:64 failed faulty running
`-+- policy='round-robin 0' prio=1 status=active
  `- 9:0:0:1 sdf 8:80 active ready  running

valmon
() автор топика
Ответ на: комментарий от valmon 
  --- Physical volume ---
  PV Name               /dev/mapper/1IET_00010001
  VG Name               VG_XenStorage-90b29628-bed4-e669-a921-01984b29e58f
  PV Size               1.80 TB / not usable 10.36 MB
  Allocatable           yes
  PE Size (KByte)       4096
  Total PE              471842
  Free PE               338457
  Allocated PE          133385
  PV UUID               Oq2OgS-A5B5-vStq-SO1J-Xsc3-CYYw-eNH92f

  --- Logical volume ---
  LV Name                /dev/VG_XenStorage-90b29628-bed4-e669-a921-01984b29e58f/VHD-811087c4-9494-43de-9c91-9e4082a33ace
  VG Name                VG_XenStorage-90b29628-bed4-e669-a921-01984b29e58f
  LV UUID                5OpgiE-8jYC-AaFf-xAfX-bPyz-Pby5-pIJads
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                513.01 GB
  Current LE             131330
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

[root@h10-g04 log]# xe vdi-param-list uuid=811087c4-9494-43de-9c91-9e4082a33ace
uuid ( RO)                    : 811087c4-9494-43de-9c91-9e4082a33ace
              name-label ( RW): New virtual disk
        name-description ( RW):
           is-a-snapshot ( RO): false
             snapshot-of ( RO): <not in database>
               snapshots ( RO):
           snapshot-time ( RO): 19700101T00:00:00Z
      allowed-operations (SRO): clone; snapshot
      current-operations (SRO):
                 sr-uuid ( RO): 90b29628-bed4-e669-a921-01984b29e58f
           sr-name-label ( RO): iSCSI virtual disk storage
               vbd-uuids (SRO): 8069f226-bc8f-5aa7-2e8e-3ed4d0f707d1
         crashdump-uuids (SRO):
            virtual-size ( RO): 549755813888
    physical-utilisation ( RO): 550837944320
                location ( RO): 811087c4-9494-43de-9c91-9e4082a33ace
                    type ( RO): User
                sharable ( RO): false
               read-only ( RO): false
            storage-lock ( RO): false
                 managed ( RO): true
                  parent ( RO): <not in database>
                 missing ( RO): false
            other-config (MRW):
           xenstore-data (MRO):
               sm-config (MRO): host_OpaqueRef:5a8da3dc-5e31-5eb1-46f6-1a0c1a29d815: RW; vdi_type: vhd; vmhint: c4969794-27ba-dddf-2ffd-47e149e511f3
                 on-boot ( RW): persist
           allow-caching ( RW): false
         metadata-latest ( RO): false
        metadata-of-pool ( RO): <not in database>
                    tags (SRW):

[root@h10-g04 log]# xe vbd-param-list uuid=8069f226-bc8f-5aa7-2e8e-3ed4d0f707d1
uuid ( RO)                        : 8069f226-bc8f-5aa7-2e8e-3ed4d0f707d1
                     vm-uuid ( RO): c4969794-27ba-dddf-2ffd-47e149e511f3
               vm-name-label ( RO): Debian Wheezy 7.0 (64-bit) (1)
                    vdi-uuid ( RO): 811087c4-9494-43de-9c91-9e4082a33ace
              vdi-name-label ( RO): New virtual disk
          allowed-operations (SRO): pause; unpause; attach; unplug_force; unplug
          current-operations (SRO):
                       empty ( RO): false
                      device ( RO): xvdb
                  userdevice ( RW): 1
                    bootable ( RW): false
                        mode ( RW): RW
                        type ( RW): Disk
                 unpluggable ( RW): true
          currently-attached ( RO): true
                  attachable ( RO): true
                storage-lock ( RO): false
                 status-code ( RO): 0
               status-detail ( RO):
          qos_algorithm_type ( RW):
        qos_algorithm_params (MRW):
    qos_supported_algorithms (SRO):
                other-config (MRW): owner: true
                 io_read_kbs ( RO): 0.000
                io_write_kbs ( RO): 0.000
valmon
() автор топика
Ответ на: комментарий от valmon

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

потому что это идиотизм. в большинстве случаев ноды не одновременно поймут, что потеряли видимость. в более сложных топологиях чем 2 ноды, еще и возможна ситуация с распаданием сети на несколько регионов. что делать при таком раскладе? это не считая того что 10 секунд (почему 10, а не 2 или 20?) это ОГРОМНОЕ КОЛИЧЕСТВО ВРЕМЕНИ с точки зрения БД например. у нас например нода отстреливается после трехсот миллисекунд задержки, иначе много что встанет раком.

нормальный сетап — это фенсинг плюс как можно быстрее «отстреливать» потерянные ноды. почитай уже за теорию дистрибьютед систем.

val-amart ★★★★★
()
Ответ на: комментарий от valmon

SCSI reservations это из области вмваре, там файловая системы, мы же используем мультипас.
Я себе это очень трудно представляю, что произойдет с транзакциями ожидающими завершение, в случае примари/примари, мультипас отработает.

Судя по твоим перлам ты вообще трудно представляешь как работает дисковая подсистема в целом и scsi с мультипасом в частности.

anonymous
()
Ответ на: комментарий от anonymous

Судя по твоим перлам ты вообще трудно представляешь как работает дисковая подсистема в целом и scsi с мультипасом в частности.

Судя по «перлам», вы великий знаток

valmon
() автор топика
Ответ на: комментарий от val-amart

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

Они поймут что потеряли друг друга в пределах одной транзакции. Если конечно очередность записи данных такая как я понимаю.

valmon
() автор топика
Ответ на: комментарий от valmon

если бы я был единственный, кто намекнул тебе об этом в этом треде, поэтому ты всё же пойди, почитай чего по теме.

anonymous
()
Ответ на: комментарий от anonymous

если бы я был единственный, кто намекнул тебе об этом в этом треде, поэтому ты всё же пойди, почитай чего по теме.

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

valmon
() автор топика
Ответ на: комментарий от valmon

Собственно как так получается

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

DonkeyHot ★★★★★
()
Ответ на: Собственно как так получается от DonkeyHot

В этом случае сеть не имеет права сбоить

Всё имеет право сбоить, просто для таких случаев придумали резервирование: bonding, multipath, двойные независимые SAN-фабрики, чтобы ошибка в конфигурировании или проблема в софте у одной из них никак не сказалась на другой.

Вообще совет автору темы - переключить внимание с DRBD на LSI Syncro - кластеризованные RAID-контроллеры, очень интересная штука. Позволяет получать доступ к одному и тому же луну с двух серверов по SAS. Подключаешь к полке по SAS два сервера и с них одновременно экспортируешь один и тот же лун - не нужно геморроиться с репликацией и т.п.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Вообще совет автору темы - переключить внимание с DRBD на LSI Syncro - кластеризованные RAID-контроллеры, очень интересная штука

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

А так да, достойное решение, хотя по сути, кроме зеркалирования кеша нового в нем нет.

valmon
() автор топика
Ответ на: комментарий от valmon

но к сожалению цена, мягко говоря выше маржи в данном случае.

Цена в 5к$, скорее всего, будет ниже цены второго набора жестких дисков и второй полки для репликации. И тем более если это SSD.

хотя по сути, кроме зеркалирования кеша нового в нем нет.

Ну как, новое - это *одновременный* доступ к LUNу с двух хостов и прозрачная для ОС смена контроллера-владельца массива. С обычным контроллером ты не сможешь юзать массив соседнего контроллера в SAS сети. А синхронизация кешей, по сути, тут вторичный фактор, влияющий лишь на производительность записи.

blind_oracle ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Нормально не работает nfsen.
Admin
Каким механизмом подать сигнал при старте демона и обработать его в другом демоне? →