[DRBD-user] drbd usage

2017-12-12 Thread Sebastian Blajszczak 
Hello,

I´m running proxmox 5.1 with drbd 9.0.9-1 on two nodes with drbdmanage 0.99.14.
I have the problem that drbd shows me a full usage of 8.74TiB. But I only have 
on each server 4.36t and when I´m calculating the VM volumes I have only 2.4t 
in use.

My drbdmanage:
# cat /etc/drbdmanaged.cfg
[LOCAL]
storage-plugin = drbdmanage.storage.lvm_thinlv.LvmThinLv
force=1

# lvm version
  LVM version: 2.02.168(2) (2016-11-30)
  Library version: 1.02.137 (2016-11-30)
  Driver version:  4.37.0

I think drbd is calculating wrong with 8.74TiB and showing 100% usage.

How can I fix this?

Which one of global_common.conf should I use?
This one:
global {
usage-count yes;
# minor-count dialog-refresh disable-ip-verification
# cmd-timeout-short 5; cmd-timeout-medium 121; cmd-timeout-long 600;
}

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 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

c-plan-ahead 5;
c-max-rate 1900M;
c-fill-target 2M;

c-min-rate 500M;

disk-barrier no;
disk-flushes no;
}

   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
# 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
sndbuf-size 0;

max-buffers8000;
max-epoch-size 8000;
}
}

Or this one?

# DRBD is the result of over a decade of development by LINBIT.
# In case you need professional services for DRBD or have
# feature requests visit http://www.linbit.com

global {
usage-count no;
# minor-count dialog-refresh disable-ip-verification
# cmd-timeout-short 5; cmd-timeout-medium 121; cmd-timeout-long 600;
}

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 {

[DRBD-user] Slow sync on DRBD home setup

2017-12-12 Thread Poulpatine 
Hi, 

   

I'm facing extremely slow DRBD sync (inital and re-sync) on my home lab setup.  
  
I've tried many tuning parameters but nothing seems to really improve 
performances.
Moreover, in my Primary/Primary setup I'm also having some split-brains under 
certains circumstances.

   
Setup :   
   
2 HP Proliant Microservers GEN 8 :
pcsrv01 :
CPU : Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz : 2 cores / 4 
threads
RAM : 16GB ECC  
Disk : 1 SSD Crucial CT250MX200SSD1
pcsrv02 :  
CPU : Intel(R) Celeron(R) CPU G1610T @ 2.30GHz
RAM : 16GB ECC  
Disk : 1 SSD Kingston SUV400S37240G

Disks :
On the SSD, only one partition is created and DRBD is using it directly.
System is installed on a MicroSD directly on the mobo of the server.

# fdisk -l /dev/sda
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x503aad21

Device Boot Start   End   Sectors  Size Id Type
/dev/sda12048 461375487 461373440  220G 8e Linux LVM


Network :
Both servers have 2 gigabit interfaces
One for access to network
One dedicated to DRBD sync with a MTU of 9000 <= direct
link between interfaces, no switch

Configuration :

r0.res :
resource r0 {
startup {
become-primary-on both;
}

net {
protocol C;
allow-two-primaries;
sndbuf-size 0;
max-buffers 8000;
max-epoch-size 8000;
sndbuf-size 512k;
rcvbuf-size 1024k;
}

on pcsrv01 {
device /dev/drbd0;
disk /dev/sda1;
address 192.168.1.10:7788;
meta-disk internal;
}

on pcsrv02 {
device /dev/drbd0;
disk /dev/sda1;
address 192.168.1.11:7788;
meta-disk internal;
}

disk {
on-io-error detach;
c-plan-ahead 0;
c-fill-target 24M;
c-min-rate 33M;
c-max-rate 110M;
}
}

1. With this setup, I'm facing horrible performances during syncing :
# cat /proc/drbd
version: 8.4.7 (api:1/proto:86-101)
srcversion: 2DCC561E7F1E3D63526E90D
 0: cs:SyncSource ro:Primary/Primary ds:UpToDate/Inconsistent C r---b-
ns:5504329 nr:480 dw:5112648 dr:4092323 al:654 bm:0 lo:244 pe:132 ua:12 
ap:234 ep:1 wo:f oos:222119720
[>] sync'ed:  1.2% (216912/219472)M
finish: 2:16:11 speed: 27,160 (1,824) K/sec




What can I do to improve that ?

2. On top of DRBD disk, I've created a physical volume used in Primary/Primary 
VG (shared between 2 Proxmox instances). When I'm creating a LV (and it's FS) 
on the remote note, I'm facing split brain due to this error :

block drbd0: Remote failed to finish a request within 42008ms > ko-count (7) * 
timeout (60 * 0.1s)


I've performed a full smartctl test and a full badblocks (in write mode) on my 
disks and no problems have been noticed.

Do you have some suggestions for me ?

Many thanks.
-- 
\o/ Sent from my tty \o/
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] multiple pools

2017-12-12 Thread Roland Kammerer 
On Mon, Dec 11, 2017 at 08:24:26PM +, Henning Svane wrote:
> Hi
> Is it possible in version 9 to have multiple pools.
> 
> I would like to make a configuration with 2 pools.

You have to be a bit more specific on that...

- For manual configuration you put in the res files whatever you like.
  One backing device from pool A for resA, one from B for resB.
- drbdmanage does not support multiple pools.
- linstor (the project that will eventually replace drbdmanage) will
  support that.

Regards, rck
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] drbd usage

2017-12-12 Thread Julien Escario 
Le 07/12/2017 à 10:36, Sebastian Blajszczak a écrit :
> Hello,
> 
>  
> 
> I´m running proxmox 5.1 with drbd 9.0.9-1 on two nodes with drbdmanage 
> 0.99.14.
> 
> I have the problem that drbd shows me a full usage of 8.74TiB. But I only have
> on each server 4.36t and when I´m calculating the VM volumes I have only 2.4t 
> in
> use.

Hello,
I can see you're using thinlv. AFAIK usage report is based on percentage
returned by lvdisplay command on each host.

Did you tried to run /usr/bin/drbdmanage update-pool ?

Best regards,
Julien Escario
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] multiple pools

2017-12-12 Thread Julien Escario 
Le 12/12/2017 à 10:06, Roland Kammerer a écrit :
> On Mon, Dec 11, 2017 at 08:24:26PM +, Henning Svane wrote:
>> Hi
>> Is it possible in version 9 to have multiple pools.
>>
>> I would like to make a configuration with 2 pools.
> 
> You have to be a bit more specific on that...
> 
> - For manual configuration you put in the res files whatever you like.
>   One backing device from pool A for resA, one from B for resB.
> - drbdmanage does not support multiple pools.
> - linstor (the project that will eventually replace drbdmanage) will
>   support that.

Hello,
May we have a pointer to linstor informations ? I can't find any info on this
software by googling 5 min.

Best regards,
Julien Escario
<>___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] multiple pools

2017-12-12 Thread Robert Altnoeder 
On 12/12/2017 11:10 AM, Julien Escario wrote:

> Hello,
> May we have a pointer to linstor informations ? I can't find any info on this
> software by googling 5 min.
>
> Best regards,
> Julien Escario
That's because no information about the project has been publicly
released so far.

A very concise overview is:
- It is a completely new design and implementation meant as a
replacement for the existing drbdmanage
- It's a two-component system comprising a controller and a satellite
component
- All communication is through TCP/IP (no control volume, no D-Bus),
plain or encrypted (SSL/TLS)
- It supports multiple storage pools
- It does not keep persistent information on DRBD's state
- Instead, it tracks DRBD state changes and makes decisions based on
what state the external environment is in
- The configuration is kept in an embedded SQL database
- It's a parallelized system (multiple nodes can run multiple actions
concurrently)
- It has very extensive logging and error reporting to make tracking
problems as easy as possible
- It has multiuser-security (different strength levels can be configured
as required)
- The controller and satellite components are implemented in Java
  (currently Java 7 compatible, with plans to move to Java 8 in the future)
- The first command-line client for it is still written in Python
- It's currently still in a very early stage (an experimental version
for LINBIT-internal tests will be ready within a few days)
- There are currently three developers working full-time on it, with a
fourth one joining in 2018

best regards,
-- 
Robert Altnoeder
+43 1 817 82 92 0 
robert.altnoe...@linbit.com 

LIN BIT  | Keeping
The Digital World Running
DRBD - Corosync - Pacemaker
f  /  t
 /  in
 /  g+


DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] multiple pools

2017-12-12 Thread Julien Escario 
Le 12/12/2017 à 11:54, Robert Altnoeder a écrit :
> On 12/12/2017 11:10 AM, Julien Escario wrote:
> 
>> Hello,
>> May we have a pointer to linstor informations ? I can't find any info on this
>> software by googling 5 min.
>>
>> Best regards,
>> Julien Escario
> That's because no information about the project has been publicly
> released so far.
> 
> A very concise overview is:
> - It is a completely new design and implementation meant as a
> replacement for the existing drbdmanage
> - It's a two-component system comprising a controller and a satellite
> component
> - All communication is through TCP/IP (no control volume, no D-Bus),
> plain or encrypted (SSL/TLS)
> - It supports multiple storage pools
> - It does not keep persistent information on DRBD's state
> - Instead, it tracks DRBD state changes and makes decisions based on
> what state the external environment is in
> - The configuration is kept in an embedded SQL database
> - It's a parallelized system (multiple nodes can run multiple actions
> concurrently)
> - It has very extensive logging and error reporting to make tracking
> problems as easy as possible
> - It has multiuser-security (different strength levels can be configured
> as required)
> - The controller and satellite components are implemented in Java
>   (currently Java 7 compatible, with plans to move to Java 8 in the future)
> - The first command-line client for it is still written in Python
> - It's currently still in a very early stage (an experimental version
> for LINBIT-internal tests will be ready within a few days)
> - There are currently three developers working full-time on it, with a
> fourth one joining in 2018

Sounds promising !
I would just have a reserve about using Java as main language : it's always been
a nightmare to get a working version of JRE. There's a lot of versions and
implementations depending upon the running OS.

And it's really heavy RAM consuming, even for an 'hello world'.

>From my point of view, it doesn't really seems to be a wise choice. A modern
language like Go, Python, Ruby, etc ... could have been far more future-proof.

Best regards,
Julien Escario
<>___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] multiple pools

2017-12-12 Thread Robert Altnoeder 
On 12/12/2017 12:09 PM, Julien Escario wrote:

> Sounds promising !
> I would just have a reserve about using Java as main language : it's always 
> been
> a nightmare to get a working version of JRE. There's a lot of versions and
> implementations depending upon the running OS.
There should be a precompiled or even a packaged JRE available on most
platforms, and any standards-compliant JRE will work. We are currently
running our tests on different Linux distributions on amd64 running JRE
7 and JRE 8, on Mac OS X running JRE 8 (controller only) and on Ubuntu
ppc64 running JRE 8, and the behavior is identical on all platforms.
> And it's really heavy RAM consuming, even for an 'hello world'.
The Java virtual machine has a base RAM consumption that obviously uses
lots of memory for just 'hello world', but that does not mean that the
application's data structures will necessarily use more RAM than the
same application written in another language.
And we are talking about a software that is running a complete
implementation of an SQL database in its address space, so I don't think
the base RAM consumption of the Java virtual machine will matter much.
> From my point of view, it doesn't really seems to be a wise choice. A modern
> language like Go, Python, Ruby, etc ... could have been far more future-proof.
I disagree, because the main problems of the current implementation of
drbdmanage were reliability and performance.

While most of the reliability problems were caused by the behavior of
the external environment, like LVM utilities, dm kernel driver, udev,
D-Bus, etc., maintaining the Python project had also become a nightmare,
mostly due to the fact that Python is a dynamically typed programming
language.
We had code breakage between different minor versions of Python because
the input or output type of functions in the standard library changed
subtly and without notice, and it only ever failed during runtime - even
though we performed static checking on the source code (using pylint).
Fixing one thing quite commonly broke two other things. Everyone on the
team had become frustrated enough with Python that noone wanted to work
with it anymore.

I suggested the use of Java because it is one of the strictest
programming languages that is in widespread use. It is strongly
statically typed, it forces you to catch most exceptions (except for
runtime exceptions), so you always know what could go wrong, it does not
hide bugs by performing potentially dangerous conversions between data
types automatically (e.g., any condition _must_ be of type boolean, you
can't just use a non-null reference, a non-empty list or a non-zero
integer to represent a value of 'true'), so it prevents lots of classes
of implementation errors (often really just typos or unexpected
behavior) that frequently broke our previous Python implementation of
drbdmanage. The same classes of implementation errors break projects in
other programming languages on a daily basis - especially those written
in dymanically typed languages like Python, Ruby, Perl, etc.
In this regard, Java does exactly what we want - our primary goal for
the project is improved reliability.

Performance-wise, multithreading with Python is more or less useless
(because inefficient), and Python is generally slower than Java and uses
just as much memory.

Also, regarding the modernness of programming languages - although
modernness is hard to measure anyways, Java is, in every respect, a more
modern programming language than Python, both technically and regarding
the date of its invention.

Go was also considered as a possible candidate, but it is more of a
replacement for procedural programming languages like C than it is a
replacement for any fully object-oriented programming language, and the
linstor project turned out to make extensive use of interfaces,
inheritance, polymorphism and structured exception handling, all of
which Go lacks.
Also, Go tends to use large amounts of RAM, possibly even more than the
Java VM, and Java had similar performance as Go in most tests, sometimes
even outperforming Go (both were typically 5 to 10 percent slower than
equivalent C++ code).

Actually, the final decision was between Go and Java.

Now factor in the extensive standard library and excellent documentation
of it that Java comes with, strong IDE support, and the fact that
finding programmers who have experience with the language is quite easy
(which was actually the final reason to decide in favor of Java and
against Go), because Java is in widespread use and has been around for a
while, and you have a winner.

Looking at the state of the project as it is now, I still believe it was
the right choice. I doubt that we could have developed an equivalent
solution in the same amount of time and in the same quality with any of
the other programming languages.

> Best regards,
> Julien Escario

best regards,
-- 
Robert Altnoeder
+43 1 817 82 92 0
robert.altnoe...@linbit.com

LINBIT | Keepin

Re: [DRBD-user] multiple pools

2017-12-12 Thread Roland Kammerer 
On Tue, Dec 12, 2017 at 12:09:26PM +0100, Julien Escario wrote:
> And it's really heavy RAM consuming, even for an 'hello world'.

The target here are servers anyways, today RAM isn't an argument. Can
you even buy notebooks that don't have 16GB RAM? And linstor is not
particular RAM hungry anyways.

And that is the server part that is written in Java. The client is still
written in Python, because:
- Code reuse from the old client (the client never was the problem).
- Python starts quite fast.
- argparse/argcomplete are one of the nicest libs for handling
  options/arguments, which is basically all the client does.

So you can still run the client on your Raspi gen 1 ;-)

Regards, rck
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user