Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

resync-after res-name/volume

Define that a device should only resynchronize after the specified other device. By default, no order between devices is defined, and all devices will resynchronize in parallel. Depending on the configuration of the lower-level devices, and the available network and disk bandwidth, this can slow down the overall resync process. This option can be used to form a chain or tree of dependencies among devices.

rs-discard-granularity byte

When rs-discard-granularity is set to a non zero, positive value then DRBD tries to do a resync operation in requests of this size. In case such a block contains only zero bytes on the sync source node, the sync target node will issue a discard/trim/unmap command for the area. The value is constrained by the discard granularity of the backing block device. In case rs-discard-granularity is not a multiplier of the discard granularity of the backing block device DRBD rounds it up. The feature only gets active if the backing block device reads back zeroes after a discard command. The default value of is 0. This option is available since 8.4.7.

discard-zeroes-if-aligned {yes | no}

There are several aspects to discard/trim/unmap support on linux block devices. Even if discard is supported in general, it may fail silently, or may partially ignore discard requests. Devices also announce whether reading from unmapped blocks returns defined data (usually zeroes), or undefined data (possibly old data, possibly garbage). If on different nodes, DRBD is backed by devices with differing discard characteristics, discards may lead to data divergence (old data or garbage left over on one backend, zeroes due to unmapped areas on the other backend). Online verify would now potentially report tons of spurious differences. While probably harmless for most use cases (fstrim on a file system), DRBD cannot have that. To play safe, we have to disable discard support, if our local backend (on a Primary) does not support "discard_zeroes_data=true". We also have to translate discards to explicit zero-out on the receiving side, unless the receiving side (Secondary) supports "discard_zeroes_data=true", thereby allocating areas what were supposed to be unmapped. There are some devices (notably the LVM/DM thin provisioning) that are capable of discard, but announce discard_zeroes_data=false. In the case of DM-thin, discards aligned to the chunk size will be unmapped, and reading from unmapped sectors will return zeroes. However, unaligned partial head or tail areas of discard requests will be silently ignored. If we now add a helper to explicitly zero-out these unaligned partial areas, while passing on the discard of the aligned full chunks, we effectively achieve discard_zeroes_data=true on such devices. Setting discard-zeroes-if-aligned to yes will allow DRBD to use discards, and to announce discard_zeroes_data=true, even on backends that announce discard_zeroes_data=false. Setting discard-zeroes-if-aligned to no will cause DRBD to always fall-back to zero-out on the receiving side, and to not even announce discard capabilities on the Primary, if the respective backend announces discard_zeroes_data=false. We used to ignore the discard_zeroes_data setting completely. To not break established and expected behaviour, and suddenly cause fstrim on thin-provisioned LVs to run out-of-space instead of freeing up space, the default value is yes. This option is available since 8.4.7.

peer-device-options 섹션

Please note that you open the section with the disk keyword.c-delay-target delay_target,

 지정된 다른 장치가 동기화된 이후에만 장치를 재 동기화하도록 정의합니다. 기본적으로 장치간에는 동기화 순서가 정의되어 있지 않으며 모든 장치가 병렬로 재 동기화 됩니다. 하위 장치 구성, 사용 가능한 네트워크 및 디스크 대역폭에 따라 전체 재 동기화 프로세스가 느려질 수 있기 때문에 이 옵션을 사용하여 장치 간의 종속성 체인 또는 트리를 형성 할 수 있습니다.

peer-device-options 섹션

peer-device-options 섹션 이지만 disk 키워드로 이 섹션을 기술합니다.

c-fill-target fill_target,

c-max-rate max_rate,

c-plan-ahead plan_timeDynamically control the

resync speed. This mechanism is enabled by setting the 재 동기화 속도를 동적으로 제어합니다. 이 메카니즘은 c-plan-ahead parameter to a positive value. The goal is to either fill the buffers along the data path with a defined amount of data if c-fill-target is defined, or to have a defined delay along the path if c-delay-target is defined. The maximum bandwidth is limited by the  매개 변수를 양수 값으로 설정하여 사용할 수 있습니다. 목표는 c-fill-target이 정의 된 경우 정의 된 양의 데이터로 데이터 경로를 따라 버퍼를 채우거나 c-delay-target이 정의 된 경우 경로를 따라 정의된 지연을 갖는 것입니다. 최대 대역폭은 c-max-rate parameter 매개 변수에 의해 제한됩니다.  The c-plan-ahead parameter defines how fast drbd adapts to changes in the resync speed. It should be set to five times the network round-trip time or more. Common values for  매개 변수는 bsr이 재 동기화 속도의 변화에 ​​얼마나 빨리 적응 하는지를 정의합니다. 네트워크 왕복 시간(RTT)의 5 배 이상으로 설정해야합니다. "정상"데이터 경로에 대한 c-fill-target for "normal" data paths range from 4K to 100K. If drbd-proxy is used, it is advised to use c-delay-target instead of c-fill-target. The 의 공통 값 범위는 4K ~ 100K입니다. drx를 사용하는 경우 c-fill-target 대신 c-delay-target을 사용하는 것이 좋습니다. c-delay-target parameter is used if the  매개 변수는 c-fill-target parameter is undefined or set to 0. The  매개 변수가 정의되지 않거나 0으로 설정된 경우에 사용됩니다. c-delay-target parameter should be set to five times the network round-trip time or more. The c-max-rate option should be set to either the bandwidth available between the DRBD-hosts and the machines hosting DRBD-proxy, or to the available disk bandwidth. The default values of these parameters are:  매개 변수는 네트워크 왕복 시간의 5 배 이상으로 설정해야합니다. c-max-rate 옵션은 bsr 호스트와 drx 를 호스팅하는 시스템간에 사용 가능한 대역폭 또는 사용 가능한 디스크 대역폭으로 설정해야합니다. 이 매개 변수의 기본값은 다음과 같습니다. c-plan-ahead   = 20 (in units of 0.1 seconds초 단위),   c-fill-target   = 0 (in units of sectors섹터 단위),   c-delay-target   = 1 (in units of 0.1 seconds), and 초 단위) ) 및 c-max-rate   = 102400 (in units of KiB/s 단위).  Dynamic resync speed control is available since DRBD 8.3.9.

c-min-rate min_rateA node

which is primary and sync-source has to schedule application I/O requests and resync I/O requests. The c-min-rate parameter limits how much bandwidth is available for resync I/O; the remaining bandwidth is used for application I/O. A c-min-rate value of 0 means that there is no limit on the resync I/O bandwidth. This can slow down application I/O significantly. Use a value of Primary 이고 동기화 소스 인 노드는 애플리케이션 I/O 요청과 동기화 요청을 스케줄링해야 합니다. c-min-rate 매개 변수는 재 동기화 I/O에 사용할 수있는 대역폭의 양을 제한합니다. 나머지 대역폭은 응용 프로그램 I/O의 복제에 사용됩니다. c-min-rate 값이 0이면 재 동기화 I/O 대역폭에 제한이 없음을 의미합니다. 이로 인해 응용 프로그램 I/O 속도가 크게 느려질 수 있습니다. 가장 낮은 재 동기화 속도를 위해서는 1 (1 KiB/s) for the lowest possible resync rate. The default value of 값을 사용하십시오. c-min-rate is 4096, in units of rate의 기본값은 KiB/ss 단위로 250 입니다.

resync-rate rateDefine how much bandwidth DRBD may use for resynchronizing. DRBD allows "normal" application I/O even during a resync. If the resync takes up too much bandwidth, application I/O can become very slow. This parameter allows to avoid that. Please note this is option only works when the dynamic resync controller is disabled

재 동기화에 bsr이 사용할 수있는 대역폭을 정의합니다. bsr은 재 동기화 중에도 일반적인 응용 프로그램 I/O를 허용합니다. 재 동기화가 너무 많은 대역폭을 차지하면 응용 프로그램 I/O가 매우 느려질 수 있으며 이 매개 변수를 사용하면 이를 피할 수 있습니다. 이 옵션은 동적 재 동기화 컨트롤러가 비활성화 된 경우에만 작동합니다.

global 섹션

dialog-refresh time

...