Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Clustering | High Ability > DRBD, VVR, Lustre > DRBD, VVR, Lustre

Ответ
 
Опции темы Опции просмотра
  #11  
Старый 12.05.2011, 09:44
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию

Connection states

drbdadm cstate r0


A resource may have one of the following connection states:
  • StandAlone. No network configuration available. The resource has not yet been connected, or has been administratively disconnected (using drbdadm disconnect), or has dropped its connection due to failed authentication or split brain.
    Нет доступа к сконфигурированной сети. Данный ресурс не был подключен или был принудительно отключен (использованием команды drbdadm disconnect), или соединение было разорвано в случает ошибки уатентификации или "разрвыва мозга"

  • Disconnecting. Temporary state during disconnection. The next state is StandAlone.
  • Unconnected. Temporary state, prior to a connection attempt. Possible next states: WFConnection and WFReportParams.
  • Timeout. Temporary state following a timeout in the communication with the peer. Next state: Unconnected.
  • BrokenPipe. Temporary state after the connection to the peer was lost. Next state: Unconnected.
  • NetworkFailure. Temporary state after the connection to the partner was lost. Next state: Unconnected.
  • ProtocolError. Temporary state after the connection to the partner was lost. Next state: Unconnected.
  • TearDown. Temporary state. The peer is closing the connection. Next state: Unconnected.
  • WFConnection - This node is waiting until the peer node becomes visible on the network.
    Данный узел ожидает, пока другая нода станет видимой в сети.

  • WFReportParams. TCP connection has been established, this node waits for the first network packet from the peer.
  • Connected. A DRBD connection has been established, data mirroring is now active. This is the normal state.
  • StartingSyncS. Full synchronization, initiated by the administrator, is just starting. The next possible states are: SyncSource or PausedSyncS.
  • StartingSyncT. Full synchronization, initiated by the administrator, is just starting. Next state: WFSyncUUID.
  • WFBitMapS. Partial synchronization is just starting. Next possible states: SyncSource or PausedSyncS.
  • WFBitMapT. Partial synchronization is just starting. Next possible state: WFSyncUUID.
  • WFSyncUUID. Synchronization is about to begin. Next possible states: SyncTarget or PausedSyncT.
  • SyncSource. Synchronization is currently running, with the local node being the source of synchronization.
  • SyncTarget. Synchronization is currently running, with the local node being the target of synchronization.
  • PausedSyncS. The local node is the source of an ongoing synchronization, but synchronization is currently paused. This may be due to a dependency on the completion of another synchronization process, or due to synchronization having been manually interrupted by drbdadm pause-sync.
  • PausedSyncT. The local node is the target of an ongoing synchronization, but synchronization is currently paused. This may be due to a dependency on the completion of another synchronization process, or due to synchronization having been manually interrupted by drbdadm pause-sync.
  • VerifyS. On-line device verification is currently running, with the local node being the source of verification.
  • VerifyT. On-line device verification is currently running, with the local node being the target of verification.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 17.05.2011 в 13:15.
Ответить с цитированием
  #12  
Старый 12.05.2011, 09:46
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию

Resource roles

drbdadm role r0

  • Primary. The resource is currently in the primary role, and may be read from and written to. This role only occurs on one of the two nodes, unless dual-primary node is enabled.
  • Secondary. The resource is currently in the secondary role. It normally receives updates from its peer (unless running in disconnected mode), but may neither be read from nor written to. This role may occur on one node or both nodes.
  • Unknown. The resource's role is currently unknown. The local resource role never has this status. It is only displayed for the peer's resource role, and only in disconnected mode.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 17.05.2011 в 13:15.
Ответить с цитированием
  #13  
Старый 12.05.2011, 10:12
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию

Disk states

drbdadm dstate r0

Both the local and the remote disk state may be one of the following:
  • Diskless. No local block device has been assigned to the DRBD driver. This may mean that the resource has never attached to its backing device, that it has been manually detached using drbdadm detach, or that it automatically detached after a lower-level I/O error.
  • Attaching. Transient state while reading meta data.
  • Failed. Transient state following an I/O failure report by the local block device. Next state: Diskless.
  • Negotiating. Transient state when an Attach is carried out on an already-connected DRBD device.
  • Inconsistent. The data is inconsistent. This status occurs immediately upon creation of a new resource, on both nodes (before the initial full sync). Also, this status is found in one node (the synchronization target) during synchronization.
  • Outdated. Resource data is consistent, but outdated.
  • DUnknown. This state is used for the peer disk if no network connection is available.
  • Consistent. Consistent data of a node without connection. When the connection is established, it is decided whether the data are UpToDate or Outdated.
  • UpToDate. Consistent, up-to-date state of the data. This is the normal state.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 17.05.2011 в 13:18.
Ответить с цитированием
  #14  
Старый 12.05.2011, 11:23
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию

Automatic split brain recovery policies
Автоматические политики восстановления при возникновении split brain

In order to be able to enable and configure DRBD's automatic split brain recovery policies, you must understand that DRBD offers several configuration options for this purpose. DRBD applies its split brain recovery procedures based on the number of nodes in the Primary role at the time the split brain is detected. To that end, DRBD examines the following keywords, all found in the resource's net configuration section:

after-sb-0pri. Split brain has just been detected, but at this time the resource is not in the Primary role on any host. For this option, DRBD understands the following keywords:

Ситуация, когда обнаружен split brain и ресурс не в состоянии Primary ни на одном из хостов. Для этих ситуаций DRBD понимает следующие команды:

  • disconnect. Do not recover automatically, simply invoke the split-brain handler script (if configured), drop the connection and continue in disconnected mode.

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

  • discard-younger-primary. Discard and roll back the modifications made on the host which assumed the Primary role last.

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

  • discard-least-changes. Discard and roll back the modifications on the host where fewer changes occurred.

    Отменить и откатить изменения на хосте, на котором выполнено наименьшее число изменений.

  • discard-zero-changes. If there is any host on which no changes occurred at all, simply apply all modifications made on the other and continue.

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

after-sb-1pri. Split brain has just been detected, and at this time the resource is in the Primary role on one host. For this option, DRBD understands the following keywords:

Ситуация, когда обнаружен split brain и ресурс в состоянии Primary. Для этих ситуаций DRBD понимает следующие команды:
  • disconnect. As with after-sb-0pri, simply invoke the split-brain handler script (if configured), drop the connection and continue in disconnected mode.

    Также, как и при after-sb-0pri, просто вызвать скрипт (если он сконфигурирован), отключиться и продолжить работу в автономном (неподключенном) режиме.

  • consensus. Apply the same recovery policies as specified in after-sb-0pri. If a split brain victim can be selected after applying these policies, automatically resolve. Otherwise, behave exactly as if disconnect were specified.

    Применить теже самые политики восстановления что и при after-sb-0pri. Если жертва расщеплением мозга может быть выбрана после применения данных политик, автоматически выполнить. В противном случае, вести себя так, как если было бы определена потикика отключения (disconnect).

  • call-pri-lost-after-sb. Apply the recovery policies as specified in after-sb-0pri. If a split brain victim can be selected after applying these policies, invoke the pri-lost-after-sb handler on the victim node. This handler must be configured in the handlers section and is expected to forcibly remove the node from the cluster.

    Применить политику восстановления, определенную в after-sb-0pri. Если жертва расщеплением мозга может быть выбрана после применения данных политик, вызвать обработчки pri-lost-after-sb на узле жертвы. Этот обработчик должен быть сконфигурирован в секции для обработчкиов и, принудительно удалить узел из кластера

  • discard-secondary. Whichever host is currently in the Secondary role, make that host the split brain victim.

    Тот хост, что работает сейчас как secondary, сделать его жертвой расщепления мозга. (заменить данными с primary)

after-sb-2pri. Split brain has just been detected, and at this time the resource is in the Primary role on both hosts. This option accepts the same keywords as after-sb-1pri except discard-secondary and consensus.

Ситуация, когда обнаружен split brain и ресурс в состоянии Primary на обоих хостах. В этих случаях применяется теже команды как и при, after-sb-1pri за исключением discard-secondary and consensus.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 17.05.2011 в 13:16.
Ответить с цитированием
  #15  
Старый 12.05.2011, 13:42
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию

handlers

In this section you can define handlers (executables) that are started by the DRBD system in response to certain events. Optional parameters:
  • pri-on-incon-degr - хост работал как primary, произошла деградация (стал secondary) после этого локальные копии данных несовместимы.
  • pri-lost-after-sb
  • pri-lost - текущий узел primary, но алгоритм работы DRBD полагает, что необходима синхронизация и превод работы в режим secondary.
  • fence-peer (formerly oudate-peer)
  • local-io-error
  • initial-split-brain - в случае появления ситуации split-brain
  • split-brain - в случае появления ситуации split-brain, который drbd самостоятельно не сможет решить
  • before-resync-target
  • after-resync-target


http://www.drbd.org/users-guide/re-drbdconf.html
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 17.05.2011 в 13:16.
Ответить с цитированием
  #16  
Старый 16.05.2011, 14:37
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию

Дополнительные опции, которые могут быть использованы при работе с DRBD.

verify-alg hash-alg

Используется для online проверки данных.

По умолчанию этот параметр отключен. Вы, вы должны явно установить эту опцию, в файле /etc/drbd.conf

Во время онлайн проверки, вместо поразрядного сравнения, DRBD применяет хэш-функцию для каждого блока, далее проверяет и сравнивает этот хэш с данными сервера-партнера.


csums-alg hash-alg

Используется при низкой пропускной способности канала, при этом увеличивается нагрузка на процессор.
По умолчанию этот параметр отключен. Вы, вы должны явно установить эту опцию, в файле /etc/drbd.conf
После перезагрузки primary узла, все блоки помечаются как необходимые для синхронизации, хотя на самом деле данные синхронизированы.
При синхронизации происходит обмен хеш значениями помеченных блоков от источника данных к узлу назначения. Передаются значения только тех блоков, у которых разные значения хеш.

Чтобы узнать список алгоритмов шифрования, которые поддерживает операционная система, выполнив команду:

# cat /proc/crypto

Код:
name         : md5
driver       : md5-generic
module       : md5
priority     : 0
type         : digest
blocksize    : 64
digestsize   : 16

name         : crc32c
driver       : crc32c-generic
module       : kernel
priority     : 0
type         : digest
blocksize    : 32
digestsize   : 4

name         : sha1
driver       : sha1-generic
module       : kernel
priority     : 0
type         : digest
blocksize    : 64
digestsize   : 20
Для возможности использовать алгоритмы проверки синхронизированных данных, необходимо задать в конфигурационном файле /etc/drbd.conf
Пример:

Код:
syncer {

*** 
      # set the "on-line device verification" algorithm (should be triggered by a cronjob)
verify-alg md5;

      # set the "checksum-based synchronization" algorithm (used when synchronizing)
csums-alg crc32c;

***
}
Проверка данных:

Verify запускает online проверку данных на обоих узлах. Если несинхронизированные блоки будут найдены, они не будут синхронизироваться автоматически. Чтобы сделать это, отключите и подключите ресурс, когда проверка завершена.
// Результат проверки можно посмотреть командой:
# cat /proc/drbd

Код:
version: 8.3.2 (api:88/proto:86-90)
GIT-hash: dd7985327f146f33b86d4bff5ca8c94234ce840e build by [email protected], 2009-08-29 14:07:55
 0: cs:VerifyS ro:Primary/Primary ds:UpToDate/UpToDate C r----
    ns:1781 nr:204149 dw:205930 dr:13043110 al:7 bm:32 lo:1984 pe:964 ua:2034 ap:0 ep:1 wo:b oos:128240
         17%      3190470/17911911

Пример:
# drbdadm verify r0

invalidate - DRBD предположит, что данные на локальном (или удаленном, в случае с использованием команды invalidate-remote) устройстве хранения несинхронизованны и будет копировать каждый блок от партнера, чтобы привести устройство хранения обратно к состоянию синхронизации.
Пример:
# drbdadm invalidate r0;
# drbdadm invalidate-remote r0;
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 10.06.2011 в 11:16.
Ответить с цитированием
  #17  
Старый 16.05.2011, 16:43
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию

1111111111111111111111111111
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 10.06.2011 в 10:52.
Ответить с цитированием
Ответ

Метки
active/active, clusters, drbd, linux, ocfs2

Опции темы
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 03:12. Часовой пояс GMT +3.


Powered by vBulletin®