Хотел как лучше, надежнее, масшабируемо, а получилось плохо

izhyrnyy · January 31, 2020, 1:41pm

Будет большой пост с трех частей

Расскажу, что есть и что хочу использовать
Раскажу, что случилось
Спрошу, как сделать максимально правильно

--------------------------1111111111111111111------------------------------------
Имею автоматизированный сервер виртуализации, он делает свою работу. Есть бессперебойник, мягкое выключение, 3 WAN с wanfailover и d-dns
Офлайн, через падения WAN, остаться нереально
Скачки напряжения - не страшны

Захотел отдать часть мошьностей проекту storj

Одна из виртуалок данного сервера - NAS на freebsd с проброшенными аппаратно на него контроллерами дисков (и оперативкой 128гиг)
Диски собраны в массив с !избыточностью! ZFS с контроллем контрольных сумм, потому не страна смерть диска или сбойные сектора на нем (если вовремя сменить диск)

Данный NAS имеет “лишнее” пространство
Подумал и решил отдать его storj

Бросать в виртуалку физический диск - ИМХО, не правильно ибо нет избыточности… а диски смертны
Делать зеркало - не оптимально ибо тратится двойная цена за место + увеличенный расход светы

Создал на NAS том поверх ZFS на 3Тб и отдал его iSCSI

Взял чистую виртуалку с дебиан, подключил iSCSI диск (/dev/sdb), отформатировал его в ext4 (без создания GPT таблицы, поверх на сырой диск), включил автомаунт через fstab

UUID=55dd5277-67f7-4594-958d-56111173d758 /mnt/storj1 ext4 _netdev,discard,noatime 0 0

Производительность такого решения великолепная

Для надежности и отсуствия глюков написал скрипт на случай выключения, включения и ребута

При включении стартуют все виртуалки, что не завязанны на НАС и сам НАС
Сразу после загрузки, сам НАС запускает скрипт и включает виртуалку storj, та подключает iSCSI, маунтит и все РАБОТАЛО!

При ребуте или выключении первой тушу виртуалку storj

Данное решение показалось оптимальным ибо надежное хранение, легкость увеличения обьема (сейчас в массиве меняю диски 3Тб на 8Тб), потом ДУМАЛ просто увеличить размер тома iSCSI и со стороны ноды сделать resizeFS

Все это великолепно работало почти 2 месяца, прошто проверки и пережило штук 8 выключений сервера и ребутов

-------------------------------------------------2222222222222222222222222--------------------------------
Сегодня, ребутнул сервак, а оно на вебморде показало, ПУСТЫЕ ГРАФИКИ

Я так понял, по какой-то причине диски не примаунтились и сабж запустился как новая нода впустой папке с “нуля”
ребутнул виртуалку - все стало ок

Уже пару спутников не прошли аудит по разу

Вот, что вижу в логах

Blockquote
Jan 31 12:50:22 storj1 kernel: [ Jan 31 12:50:23 storj1 kernel: [ Jan 31 12:50:23 storj1 kernel: [ Jan 31 12:50:23 storj1 kernel: [ Jan 31 12:50:23 storj1 kernel: [ Jan 31 12:50:23 storj1 kernel: [ Jan 31 12:50:23 storj1 kernel: [ Jan 31 12:50:23 storj1 kernel: [ Jan 31 12:50:23 storj1 kernel: [ Jan 31 12:50:25 storj1 kernel: [ Jan 31 12:50:25 storj1 kernel: [ Jan 31 12:50:25 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:26 storj1 kernel: [ Jan 31 12:50:27 storj1 kernel: [ Jan 31 12:50:27 storj1 kernel: [ Jan 31 12:50:27 storj1 kernel: [ Jan 31 12:50:27 storj1 kernel: [ Jan 31 12:50:27 storj1 kernel: [ Jan 31 12:50:27 storj1 kernel: [ Jan 31 12:50:27 storj1 kernel: [ Jan 31 12:50:27 storj1 kernel: [ Jan 31 12:50:32 storj1 kernel: [ Jan 31 12:50:32 storj1 kernel: [ Jan 31 12:50:32 storj1 kernel: [ Blockquote 5.250722] scsi host3: iSCSI Initiator over TCP/IP
6.293923] scsi 3:0:0:0: Direct-Access FreeBSD iSCSI DISK 0001 PQ: 0 ANSI: 5
6.295330] sd 3:0:0:0: Attached scsi generic sg1 type 0
6.295526] sd 3:0:0:0: Power-on or device reset occurred
6.297656] sd 3:0:0:0: [sdb] 941621248 4096-byte logical blocks: (3.86 TB/3.51 TiB)
6.297983] sd 3:0:0:0: [sdb] Write Protect is off
6.298742] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
6.299541] sd 3:0:0:0: [sdb] Optimal transfer size 1048576 bytes
6.308682] sd 3:0:0:0: [sdb] Attached SCSI disk
8.187187] random: crng init done
8.187207] random: 7 urandom warning(s) missed due to ratelimiting
8.336199] audit: type=1400 audit(1580467825.871:5): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“docker-default” pi$
8.479830] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need thi$
8.485432] Bridge firewalling registered
8.752070] Initializing XFRM netlink socket
8.947377] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
9.229893] docker0: port 1(veth2a56afb) entered blocking state
9.229895] docker0: port 1(veth2a56afb) entered disabled state
9.229954] device veth2a56afb entered promiscuous mode
9.230088] IPv6: ADDRCONF(NETDEV_UP): veth2a56afb: link is not ready
9.230091] docker0: port 1(veth2a56afb) entered blocking state
9.230092] docker0: port 1(veth2a56afb) entered forwarding state
9.230144] docker0: port 1(veth2a56afb) entered disabled state
9.234340] docker0: port 2(veth4d096c4) entered blocking state
9.234341] docker0: port 2(veth4d096c4) entered disabled state
9.234372] device veth4d096c4 entered promiscuous mode
9.234414] IPv6: ADDRCONF(NETDEV_UP): veth4d096c4: link is not ready
9.234416] docker0: port 2(veth4d096c4) entered blocking state
9.234417] docker0: port 2(veth4d096c4) entered forwarding state
9.234431] IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready
9.235325] docker0: port 2(veth4d096c4) entered disabled state
9.651650] eth0: renamed from vethc6a5907
9.666533] IPv6: ADDRCONF(NETDEV_CHANGE): veth2a56afb: link becomes ready
9.666573] docker0: port 1(veth2a56afb) entered blocking state
9.666575] docker0: port 1(veth2a56afb) entered forwarding state
9.682542] eth0: renamed from veth9487869
9.698807] IPv6: ADDRCONF(NETDEV_CHANGE): veth4d096c4: link becomes ready
9.698844] docker0: port 2(veth4d096c4) entered blocking state
9.698845] docker0: port 2(veth4d096c4) entered forwarding state
14.073328] EXT4-fs (sdb): recovery complete
14.074487] EXT4-fs (sdb): mounting with “discard” option, but the device does not support discard
14.074489] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: discard

Вот еще, почему-то контейнер_д загрузился намного раньше чем iSCSI…
Потом что-то не то творится с сетью, докер колбасит
Дальше

Blockquote
Jan 31 12:50:27 storj1 systemd[1]: Started Docker Application Container Engine.
Blockquote

И ТОЛЬКО ЧЕРЕЗ 5 сек ЯДРО ПРОВЕРИЛО И ПРИМАУНТИЛО ДИСК

Blockquote
Jan 31 12:50:20 storj1 containerd[409]: time=“2020-01-31T12:50:20.327688662+02:00” level=info msg=“containerd successfully booted in 0.029096s”
Jan 31 12:50:20 storj1 iscsid: iSCSI daemon with pid=315 started!
Jan 31 12:50:20 storj1 iscsid: cannot make a connection to 10.1.1.3:3260 (-1,101)
Jan 31 12:50:20 storj1 ntpd[406]: bind(24) AF_INET6 fe80::10c7:ccff:fe4e:7a76%2#123 flags 0x11 failed: Cannot assign requested address
Jan 31 12:50:20 storj1 ntpd[406]: unable to create socket on ens18 (6) for fe80::10c7:ccff:fe4e:7a76%2#123
Jan 31 12:50:20 storj1 ntpd[406]: failed to init interface for address fe80::10c7:ccff:fe4e:7a76%2
Jan 31 12:50:20 storj1 ntpd[406]: Soliciting pool server 79.142.192.130
Jan 31 12:50:21 storj1 ntpd[406]: Soliciting pool server 194.40.240.24
Jan 31 12:50:22 storj1 ntpd[406]: Soliciting pool server 134.249.140.99
Jan 31 12:50:22 storj1 kernel: [ 5.250722] scsi host3: iSCSI Initiator over TCP/IP
Jan 31 12:50:22 storj1 ntpd[406]: Soliciting pool server 91.236.251.12
Jan 31 12:50:22 storj1 ntpd[406]: Soliciting pool server 91.236.251.11
Jan 31 12:50:22 storj1 ntpd[406]: Listen normally on 7 ens18 [fe80::10c7:ccff:fe4e:7a76%2]:123
Jan 31 12:50:22 storj1 ntpd[406]: new interface(s) found: waking up resolver
Jan 31 12:50:22 storj1 ntpd[406]: Soliciting pool server 185.102.185.102
Jan 31 12:50:23 storj1 kernel: [ 6.293923] scsi 3:0:0:0: Direct-Access FreeBSD iSCSI DISK 0001 PQ: 0 ANSI: 5
Jan 31 12:50:23 storj1 kernel: [ 6.295330] sd 3:0:0:0: Attached scsi generic sg1 type 0
Jan 31 12:50:23 storj1 kernel: [ 6.295526] sd 3:0:0:0: Power-on or device reset occurred
Jan 31 12:50:23 storj1 kernel: [ 6.297656] sd 3:0:0:0: [sdb] 941621248 4096-byte logical blocks: (3.86 TB/3.51 TiB)
Jan 31 12:50:23 storj1 kernel: [ 6.297983] sd 3:0:0:0: [sdb] Write Protect is off
Jan 31 12:50:23 storj1 kernel: [ 6.297985] sd 3:0:0:0: [sdb] Mode Sense: 83 00 00 08
Jan 31 12:50:23 storj1 iscsiadm[319]: Logging in to [iface: default, target: iqn.cloud.zhyr.nas:storj1, portal: 10.1.1.3,3260] (multiple)
Jan 31 12:50:23 storj1 iscsiadm[319]: Login to [iface: default, target: iqn.cloud.zhyr.nas:storj1, portal: 10.1.1.3,3260] successful.
Jan 31 12:50:23 storj1 kernel: [ 6.298742] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
Jan 31 12:50:23 storj1 kernel: [ 6.299541] sd 3:0:0:0: [sdb] Optimal transfer size 1048576 bytes
Jan 31 12:50:23 storj1 systemd[1]: Started Login to default iSCSI targets.
Jan 31 12:50:23 storj1 systemd[1]: Reached target Remote File Systems (Pre).
Jan 31 12:50:23 storj1 kernel: [ 6.308682] sd 3:0:0:0: [sdb] Attached SCSI disk
Jan 31 12:50:23 storj1 ntpd[406]: Soliciting pool server 195.34.204.246
Jan 31 12:50:23 storj1 ntpd[406]: Soliciting pool server 195.34.204.246
Jan 31 12:50:23 storj1 ntpd[406]: Soliciting pool server 91.236.251.58
Jan 31 12:50:24 storj1 systemd[1]: Found device iSCSI_DISK.
Jan 31 12:50:24 storj1 systemd[1]: mnt-storj1.mount: Directory /mnt/storj1 to mount over is not empty, mounting anyway.
Jan 31 12:50:24 storj1 systemd[1]: Mounting /mnt/storj1…
Jan 31 12:50:24 storj1 iscsid: Connection1:0 to [target: iqn.cloud.zhyr.nas:storj1, portal: 10.1.1.3,3260] through [iface: default] is operational now
Jan 31 12:50:24 storj1 ntpd[406]: Soliciting pool server 195.78.244.50
Jan 31 12:50:24 storj1 ntpd[406]: Soliciting pool server 193.27.208.100
Jan 31 12:50:24 storj1 ntpd[406]: Soliciting pool server 162.159.200.1
Jan 31 12:50:25 storj1 kernel: [ 8.187187] random: crng init done
Jan 31 12:50:25 storj1 kernel: [ 8.187207] random: 7 urandom warning(s) missed due to ratelimiting
Jan 31 12:50:25 storj1 systemd[1]: Started OpenBSD Secure Shell server.
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.841790940+02:00” level=info msg=“Starting up”
Jan 31 12:50:25 storj1 kernel: [ 8.336199] audit: type=1400 audit(1580467825.871:5): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“docker-default” pi$
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.878570067+02:00” level=info msg=“parsed scheme: “unix”” module=grpc
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.878749682+02:00” level=info msg=“scheme “unix” not registered, fallback to default scheme” module=grpc
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.878912122+02:00” level=info msg=“ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.so$
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.878951093+02:00” level=info msg=“ClientConn switching balancer to “pick_first”” module=grpc
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.888748753+02:00” level=info msg=“parsed scheme: “unix”” module=grpc
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.888957063+02:00” level=info msg=“scheme “unix” not registered, fallback to default scheme” module=grpc
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.889173100+02:00” level=info msg=“ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.so$
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.889380865+02:00” level=info msg=“ClientConn switching balancer to “pick_first”” module=grpc
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.897960462+02:00” level=info msg=”[graphdriver] using prior storage driver: overlay2”
Jan 31 12:50:25 storj1 ntpd[406]: Soliciting pool server 193.106.144.7
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.970241272+02:00” level=warning msg=“Your kernel does not support swap memory limit”
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.970286250+02:00” level=warning msg=“Your kernel does not support cgroup rt period”
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.970309005+02:00” level=warning msg=“Your kernel does not support cgroup rt runtime”
Jan 31 12:50:25 storj1 dockerd[411]: time=“2020-01-31T12:50:25.970583240+02:00” level=info msg=“Loading containers: start.”
Jan 31 12:50:26 storj1 kernel: [ 8.479830] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need thi$
Jan 31 12:50:26 storj1 kernel: [ 8.485432] Bridge firewalling registered
Jan 31 12:50:26 storj1 kernel: [ 8.752070] Initializing XFRM netlink socket
Jan 31 12:50:26 storj1 systemd-udevd[250]: Using default interface naming scheme ‘v240’.
Jan 31 12:50:26 storj1 systemd-udevd[250]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan 31 12:50:26 storj1 kernel: [ 8.947377] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
Jan 31 12:50:26 storj1 dockerd[411]: time=“2020-01-31T12:50:26.686203383+02:00” level=info msg=“Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon op$
Jan 31 12:50:26 storj1 kernel: [ 9.229893] docker0: port 1(veth2a56afb) entered blocking state
Jan 31 12:50:26 storj1 kernel: [ 9.229895] docker0: port 1(veth2a56afb) entered disabled state
Jan 31 12:50:26 storj1 kernel: [ 9.229954] device veth2a56afb entered promiscuous mode
Jan 31 12:50:26 storj1 kernel: [ 9.230088] IPv6: ADDRCONF(NETDEV_UP): veth2a56afb: link is not ready
Jan 31 12:50:26 storj1 kernel: [ 9.230091] docker0: port 1(veth2a56afb) entered blocking state
Jan 31 12:50:26 storj1 kernel: [ 9.230092] docker0: port 1(veth2a56afb) entered forwarding state
Jan 31 12:50:26 storj1 kernel: [ 9.230144] docker0: port 1(veth2a56afb) entered disabled state
Jan 31 12:50:26 storj1 systemd-udevd[250]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan 31 12:50:26 storj1 systemd-udevd[250]: Could not generate persistent MAC address for vethc6a5907: No such file or directory
Jan 31 12:50:26 storj1 systemd-udevd[273]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan 31 12:50:26 storj1 systemd-udevd[273]: Using default interface naming scheme ‘v240’.
Jan 31 12:50:26 storj1 systemd-udevd[273]: Could not generate persistent MAC address for veth2a56afb: No such file or directory
Jan 31 12:50:26 storj1 systemd-udevd[251]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan 31 12:50:26 storj1 systemd-udevd[264]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan 31 12:50:26 storj1 systemd-udevd[264]: Using default interface naming scheme ‘v240’.
Jan 31 12:50:26 storj1 systemd-udevd[251]: Using default interface naming scheme ‘v240’.
Jan 31 12:50:26 storj1 systemd-udevd[264]: Could not generate persistent MAC address for veth9487869: No such file or directory
Jan 31 12:50:26 storj1 systemd-udevd[251]: Could not generate persistent MAC address for veth4d096c4: No such file or directory
Jan 31 12:50:26 storj1 kernel: [ 9.234340] docker0: port 2(veth4d096c4) entered blocking state
Jan 31 12:50:26 storj1 kernel: [ 9.234341] docker0: port 2(veth4d096c4) entered disabled state
Jan 31 12:50:26 storj1 kernel: [ 9.234372] device veth4d096c4 entered promiscuous mode
Jan 31 12:50:26 storj1 kernel: [ 9.234414] IPv6: ADDRCONF(NETDEV_UP): veth4d096c4: link is not ready
Jan 31 12:50:26 storj1 kernel: [ 9.234416] docker0: port 2(veth4d096c4) entered blocking state
Jan 31 12:50:26 storj1 kernel: [ 9.234417] docker0: port 2(veth4d096c4) entered forwarding state
Jan 31 12:50:26 storj1 kernel: [ 9.234431] IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready
Jan 31 12:50:26 storj1 kernel: [ 9.235325] docker0: port 2(veth4d096c4) entered disabled state
Jan 31 12:50:26 storj1 containerd[409]: time=“2020-01-31T12:50:26.847243700+02:00” level=info msg=“shim containerd-shim started” address=”/containerd-shim/moby/8ce66e8aed33eea5$
Jan 31 12:50:26 storj1 ntpd[406]: Soliciting pool server 2606:4700:f1::1
Jan 31 12:50:26 storj1 containerd[409]: time=“2020-01-31T12:50:26.959133935+02:00” level=info msg=“shim containerd-shim started” address="/containerd-shim/moby/ec788144db039d47$
Jan 31 12:50:27 storj1 kernel: [ 9.651650] eth0: renamed from vethc6a5907
Jan 31 12:50:27 storj1 kernel: [ 9.666533] IPv6: ADDRCONF(NETDEV_CHANGE): veth2a56afb: link becomes ready
Jan 31 12:50:27 storj1 kernel: [ 9.666573] docker0: port 1(veth2a56afb) entered blocking state
Jan 31 12:50:27 storj1 kernel: [ 9.666575] docker0: port 1(veth2a56afb) entered forwarding state
Jan 31 12:50:27 storj1 kernel: [ 9.682542] eth0: renamed from veth9487869
Jan 31 12:50:27 storj1 kernel: [ 9.698807] IPv6: ADDRCONF(NETDEV_CHANGE): veth4d096c4: link becomes ready
Jan 31 12:50:27 storj1 kernel: [ 9.698844] docker0: port 2(veth4d096c4) entered blocking state
Jan 31 12:50:27 storj1 kernel: [ 9.698845] docker0: port 2(veth4d096c4) entered forwarding state
Jan 31 12:50:27 storj1 dockerd[411]: time=“2020-01-31T12:50:27.365641344+02:00” level=info msg=“Loading containers: done.”
Jan 31 12:50:27 storj1 dockerd[411]: time=“2020-01-31T12:50:27.432509362+02:00” level=info msg=“Docker daemon” commit=633a0ea838 graphdriver(s)=overlay2 version=19.03.5
Jan 31 12:50:27 storj1 dockerd[411]: time=“2020-01-31T12:50:27.432844236+02:00” level=info msg=“Daemon has completed initialization”
Jan 31 12:50:27 storj1 dockerd[411]: time=“2020-01-31T12:50:27.459208529+02:00” level=info msg=“API listen on /var/run/docker.sock”
Jan 31 12:50:27 storj1 systemd[1]: Started Docker Application Container Engine.
Jan 31 12:50:29 storj1 ntpd[406]: receive: Unexpected origin timestamp 0xe1de84f4.e917f489 does not match aorg 0000000000.00000000 from server@193.106.144.7 xmt 0xe1de84f5.7b35$
Jan 31 12:50:31 storj1 ntpd[406]: Listen normally on 8 docker0 172.17.0.1:123
Jan 31 12:50:31 storj1 ntpd[406]: Listen normally on 9 docker0 [fe80::42:22ff:fe13:dcf6%3]:123
Jan 31 12:50:31 storj1 ntpd[406]: Listen normally on 10 veth2a56afb [fe80::58e3:41ff:fe40:baec%5]:123
Jan 31 12:50:31 storj1 ntpd[406]: Listen normally on 11 veth4d096c4 [fe80::24ea:b6ff:fed9:99c1%7]:123
Jan 31 12:50:31 storj1 ntpd[406]: new interface(s) found: waking up resolver
Jan 31 12:50:32 storj1 kernel: [ 14.073328] EXT4-fs (sdb): recovery complete
Jan 31 12:50:32 storj1 kernel: [ 14.074487] EXT4-fs (sdb): mounting with “discard” option, but the device does not support discard
Jan 31 12:50:32 storj1 kernel: [ 14.074489] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: discard
Jan 31 12:50:32 storj1 systemd[1]: Mounted /mnt/storj1.
Jan 31 12:50:32 storj1 systemd[1]: Reached target Remote File Systems.
Jan 31 12:50:32 storj1 systemd[1]: Starting Permit User Sessions…
Jan 31 12:50:32 storj1 systemd[1]: Starting LSB: disk temperature monitoring daemon…
Jan 31 12:50:32 storj1 cron[859]: (CRON) INFO (pidfile fd = 3)
Jan 31 12:50:32 storj1 systemd[1]: Started Regular background program processing daemon.
Jan 31 12:50:32 storj1 systemd[1]: Started Permit User Sessions.
Jan 31 12:50:32 storj1 systemd[1]: Started Getty on tty1.
Jan 31 12:50:32 storj1 systemd[1]: Reached target Login Prompts.
Jan 31 12:50:32 storj1 cron[859]: (CRON) INFO (Running @reboot jobs)
Jan 31 12:50:32 storj1 systemd[1]: Started LSB: disk temperature monitoring daemon.
Jan 31 12:50:32 storj1 systemd[1]: Reached target Multi-User System.
Jan 31 12:50:32 storj1 systemd[1]: Reached target Graphical Interface.
Jan 31 12:50:32 storj1 systemd[1]: Starting Update UTMP about System Runlevel Changes…
Jan 31 12:50:32 storj1 systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Jan 31 12:50:32 storj1 systemd[1]: Started Update UTMP about System Runlevel Changes.
Jan 31 12:50:32 storj1 systemd[1]: Startup finished in 1.695s (kernel) + 12.402s (userspace) = 14.097s.
Jan 31 12:50:38 storj1 systemd[1]: Created slice User Slice of UID 0.
Jan 31 12:50:38 storj1 systemd[1]: Starting User Runtime Directory /run/user/0…
Jan 31 12:50:38 storj1 systemd[1]: Started User Runtime Directory /run/user/0.
Jan 31 12:50:38 storj1 systemd[1]: Starting User Manager for UID 0…
Jan 31 12:50:38 storj1 systemd[937]: Reached target Paths.
Jan 31 12:50:38 storj1 systemd[937]: Reached target Timers.
Jan 31 12:50:38 storj1 systemd[937]: Listening on GnuPG cryptographic agent and passphrase cache.
Jan 31 12:50:38 storj1 systemd[937]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jan 31 12:50:38 storj1 systemd[937]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Jan 31 12:50:38 storj1 systemd[937]: Listening on GnuPG network certificate management daemon.
Jan 31 12:50:38 storj1 systemd[937]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jan 31 12:50:38 storj1 systemd[937]: Reached target Sockets.
Jan 31 12:50:38 storj1 systemd[937]: Reached target Basic System.
Jan 31 12:50:38 storj1 systemd[937]: Reached target Default.
Jan 31 12:50:38 storj1 systemd[937]: Startup finished in 76ms.
Blockquote

Вопросы

Почему оно до этого работало ок?
Нода 3 недели как прошла ветинг… Убивать ее, она уже смысла не имеет?

----------------------------------------------------------------------333333333333333333-----------------------------------
На практике данное решение оказалось не надежным и не важно, будет жить эта нода дальше или нет хочу ухнать

Есть у разработчиков “рецепт” правилього варианта разворачивания ноды, дабы раз настроил и забыл почти навсегда… пришел, когда захотел мягко и безкровно дать больше места? Желательно, что б оно не просило допресурсов, а жило на существующем с МАКСИМАЛЬНОЙ НАДЕЖНОСТЬЮ, как сохранности данных, так и работоспособности?
Прошу поделится ним
Если мне оставлять все как есть, может есть мысли у кого, что сделать что б не поймать такой глюк в будущем?
Можно не запускать докер, пока при загрузке не проверится и примаунтится iSCSI?
Или как-то скриптом стартовать докер только после проверки, примонтировался ли том?
Или что б загрузка системы становилась колом пока не примаунтится iSCSI?
Как правильнее?
storj впринципе можно в заданных условиях первой части сапоортить надежно?
Собираю советы, как правильнее все перестроить, дабы и данные не терять в случае смерти ОДНОГО диска… и не выделять дополнительную вереницу дисков ТОЛЬКО для storj.

izhyrnyy · January 31, 2020, 4:20pm

Ну и в догонку
Подскажите по стате плз
На UPLOADS все как-то плохо… значит ли это, что через iSCSI raid-z1 слижком медленная скорость доступа?
Это через “виртуальную сеть”, тормоза RAID-Z?
Но там оперативы 128гиг и оно в кеше там висит очень многое

========== AUDIT =============
Successful:           254
Recoverable failed:   2
Unrecoverable failed: 0
Success Rate Min:     99.219%
Success Rate Max:     100.000%
========== DOWNLOAD ==========
Successful:           2196
Failed:               106
Success Rate:         95.395%
========== UPLOAD ============
Successful:           399
Rejected:             0
Failed:               1032
Acceptance Rate:      100.000%
Success Rate:         27.883%
========== REPAIR DOWNLOAD ===
Successful:           0
Failed:               0
Success Rate:         0.000%
========== REPAIR UPLOAD =====
Successful:           212
Failed:               536
Success Rate:         28.342%

Вот за месяц

N O D E S S U M M A R Y
storagenode version 0.31.12 (latest)

Node Ping Audit Uptime [ Used Disk Free ] Egress Ingress Delete [ Bandwidth Free ]
---- ---- ----- ------ -------- ---------------------- ------ ------ ------- ------ ----------- ------
storj1 (12hE-9q) 3 97,3 0 425 GiB [--- ] 2,68 TiB [===-------] (630 GiB) [===-------] (402 GiB) [ ] (0) [ ] 26,3 TiB

При занятом 400гигах, отдали по 600гиг… значит ли это если я дам виртуалке диск напрямую, ОДИН… то могу на 400гиг места отдавать по 2Тб в месяц?

Alexey · January 31, 2020, 11:36pm

Да. Любое сетевое хранилище будет заведомо медленнее, чем локальное.
Постарайтесь не использовать сеть для подключения хранилища. В частности, SMB/NFS не работают вообще.

любой мини-ПК с одним диском. Скоро год, как RPi3 в диване лежит и работает.
Рекомендация - 1 диск - 1 нода. Просто и надёжно.
Если у вас уже есть RAID для чего-то другого - тогда можете использовать его.

я бы проголосовал за этот вариант:

Вы же уже знаете ответ , Если бы оно было надёжно, вы бы тему не создали, верно?

Проверьте аудиты: Интересует параметр + Аудит
если рейтинг ниже 0.6 на сателлите, нода дисквалифицирована.
Если дисквалифицирована на всех, то да, удалять и создавать новую с новой identity.

Нет никакой зависимости. Место и трафик используется реальными людьми, так что математика не поможет. В этом месяце был тест на скачивание данных. Рассчитывать на проведение тестов не стоит. Использование непредсказуемо.

izhyrnyy · February 1, 2020, 8:49am

Даже если это Linux vBridge 10Gb?
Понял, переведу ноду на локальный диск, а папку отдам в контейнер линукс - сравгю статистику

Но у меня возникла ПРОБЛЕМА в идентификации, что такое в скрипте UPLOAD
По логике - это то, что я ОТДАЮ… но по статиские REPAIR DOWNLOAD - это как раз та мелочь, что я два раза Repair Egress

Выходит со стороны моей ноды UPLOAD - это сколько нода всосала… и это значит, что я не успеваю сохранять данные… как раз по причине записи на диск черех виртсеть и iSCSI
Пономаю, что нужно лечиться, но не понимаю реакцию на закачку или отдачу…

Blockquote
========== UPLOAD ============
Successful: 647
Rejected: 0
Failed: 2175
Acceptance Rate: 100.000%
Success Rate: 22.927%
========== REPAIR DOWNLOAD ===
Successful: 2
Failed: 0
Success Rate: 100.000%
Blockquote

До первого ремапа, верно
А дальше тормоза, потеря данных…
Я так понимаю за 1 не пройденный аудит, я навсегда лишился половины ескроу через невозможность мягкого выхода в будущем?
Тогда ненадежность и полутопорность - может быть политикой компании ибо она на этом зарабатывать может в будущем

Один диск - одна нода, еще кривее… кабель отошел и все, дис кне примаунтится… тем не менее на форуме ниразу не видел, что б вы не советовали систему держать на одном диске, а сторж ложить в приманченую папку
С другой стороны… каждая такая ошибка работает на вас и против оператора ибо ескроу

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

“118UWpMCHzs6CvSgWd9BfFVjw5K9pZbJjkfZJexMtSkmKxvvAW”
{
“totalCount”: 559,
“successCount”: 558,
“alpha”: 19.83391661600568,
“beta”: 0.16608338398760714,
“score”: 0.9916958308006169
}
“121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6”
{
“totalCount”: 2681,
“successCount”: 2680,
“alpha”: 19.998180284683542,
“beta”: 0.0018197153164363333,
“score”: 0.9999090142341782
}
“12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S”
{
“totalCount”: 2406,
“successCount”: 2406,
“alpha”: 19.99999999999995,
“beta”: 0,
“score”: 1
}
“12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs”
{
“totalCount”: 1604,
“successCount”: 1604,
“alpha”: 19.99999999999995,
“beta”: 0,
“score”: 1
}

Спасибо за ответы!

Alexey · February 1, 2020, 10:37am

Направление трафика всегда с точки зрения клиента. Upload - заливка в сеть, Download - скачивание из сети. Для определения направления трафика на ноде используются термины: ingress - трафик на ноду, egress - трафик с ноды.

За один проваленный аудит escrow не трогается. А вот если рейтинг упадёт ниже 0.6 - нода дисквалифицируется. Но да, лучше вернуть данные на место, они же не потеряны, а скрыты в папке для mountpoint.
Остановите ноду, отмонтируйте, примонтируйте хранилище в другую и перенесите blobs из mountpoint в хранилище, потом отмонтируйте от временной папки и примонтируйте на “родное” место. Тогда и GE выполнить будет возможно.

Это древний спор, можете почитать тут:

И проблемы в случае RAID:

Кратко суть можно описать так: если у вас ещё нет RAID, то смысла связываться нет, по деньгам будет дешевле держать каждую ноду на своём диске, даже в случае выхода из строя одного из них за 15 месяцев (когда вы получаете полные выплаты и вам вернут 50% escrow) за счёт того, что вы не тратите один или два диска на parity (они в любом случае потеряны).
Просто из практики - RAID дороже простых конфигураций compute + HDD.
Наиболее выгодный вариант - мини ПК типа Raspberry Pi3/4, odroid HC2, rock64 и один диск. Таких можно запустить сколько угодно. Затраты энергии и денег заметно меньше NAS или ПК с RAID.

С другой стороны, если у вас уже есть NAS и RAID - используйте их.

В точности наоборот, восстановление потерянных данных очень дорогая операция, escrow недостаточно для оплаты:

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

Как быстрее восстановить рейтинг я написал - верните скрытые данные на родину, переносите только blobs, базы данных перезаписывать нельзя.
Базы данных неплохо было бы объединить, но это трудоёмко - нужно выгрузить данные из обломков баз и загрузить в основные. Если этого не сделать, статистика будет неверная, и трафик repair download будет ниже, потому что нода не будет находить нужные файлы, однако на аудит не влияет.

izhyrnyy · February 1, 2020, 11:27am

Тогда скрипт, который в вашей теме скачал - обманывает
Ибо у меня другим скриптом показывает что я каждый день ingress (ложу себе) много repair… а в вашем скрипте наоборот. Запутали!
========== REPAIR DOWNLOAD ===
Successful: 0
Failed: 0
Success Rate: 0.000%
========== REPAIR UPLOAD =====
Successful: 454
Failed: 1210
Success Rate: 27.284%

Ааааааа!!! вчера как раз очистил ту папку
И да, ноду прийдется убить ибо ОДНА проблема с диском и GE невозможен… а это МНОГО ДЕНЕГ
Понятно, почему вы советуете один комп, один диск… траблы работают на вас

Но там же тормозные процы и SATA через USB разведено…
Странно все это

Аппаратный рейд - это прошлый век
Я за RAID-Z на ZFS

Тогда не понятно, почему все так криво организовано
Почему все лежит в одном мусорнике, если БД можно держать в более удобном месте (на SSD например), а в случае дизконетом стоража - можно НЕ ТУПО НАЧАТЬ СОЗДАВАТЬ НОВЫЙ… а как-то реагировать…
Странно, что дешовые, простые и архиненадежные (которые еще и нужно ПОКУПАТЬ) решения побеждают у сложных, НАДЕЖНЫХ и ГОТОВЫХ… и только потому, что сама нода не выполняет элементарных проверко среды, где находится…

С ваших тарифов
50% евроу выдается через 15месяцв… остальные или никогда или при GE, один не пройденій аудит - закрывает GE, а значит лишает половины GE и смыла саппорта ноды, которой 1.7месяца

На одной сделал (на dторой), с первой вчера удалил
На третей, которая еще не показал не пройденные аудиты - тоже нашел 22мега блобсов и кинул в основное хранилище

Вывод простой
iSCSI под линукс ИСПОЛЬЗОВАТЬ НЕЛЬЗЯ
Думаю и форум нужно подчистить от советов, предпочесть iSCSI против NFS

Остается докер на голом рейде в каком-то датацентре у админа, который рискнет воткнуть инородное в свой продакшн… или малино-виндовые “однодневки”

Серьезное и готовое фактически не удел…

По 25% UPLOADS
Теперь понятно, чо организацию НУЖНО МЕНЯТЬ, и не обделаться в строемом НАС для родителей!
Есть 3 ноды однинаково организованные
Прошу сказать фэ

Для экспериментов

Одну выношу на одноплатник j1900 16гиг оперативы, 2Тб диск - голый дебиан 10 (или что-то другое?) Жить будет там месяц (железка покупалась для pfsense для роутинга родителям), статистику засечу, думаю даже 2 недели ручного подсчета разницы дельты Successful/Failed хватит понять туда ли копаю
Одну ноду вынесу в контейнер дебиан 10 (по логике это ж самая быстрая виртуализация?), диск подсуну как датасет ZFS, что будел лежать НА ЛОКАЛЬНОМ RAID-Z (ARC увеличу до 64гиг)
Одну ноду перенесу в виртуалку чистый дебиан… и тут вилка… или отдать в виртуалку ФИЗИЧЕСКИЙ ДИСК (тут понятно)… или отдать в виртуалку датастор с одного или RAID-Z (тянет ибо могу поставить кеширование Write Back… небезопасно но по логике НА ЗАПИСЬ ОЧЕНЬ БЫСТРО! ЧТо мне нужно и исправить)

Как бы перестроили вы?

Alexey · February 1, 2020, 1:08pm

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

У меня нет сложного оборудования дома, как у многих операторов тут:

простой домашний роутер ZyXel VIVA
гигабитная проводная (cat6) сеть в стенах
домашний сервер (на Windows 10 Pro) для развлечений (из-за них Windows и именно 10…), сетевое хранилище, виртуалки для работы и экспериментов. Это обычный ПК i7 32GB с 16 ТБ (4 диска). RAID нет.
На нём у меня работали 4 ноды v2 (потому что свободное место на разных дисках), а сейчас работает 2 ноды v3, одна - Windows GUI (чтобы иметь возможность помогать операторам на Windows GUI), вторая - docker (Docker desktop это VM Linux + обвязка, чтобы выглядело, как будто docker работает прямо на Windows); в общей сложности 11ТБ. Диски старые, но держатся. Так что честная конфигурация.
Нода на docker работает с июня прошлого года, нода на Windows GUI - с первой версии
Ноды менял местами - бОльшая работает на docker, меньшая на Windows GUI.
БОльшая раньше была на docker в Ubuntu (создана в июле прошлого года), сначала переехала в docker на Windows, потом в Windows GUI. Потом поменял местами, потому что docker версия почему-то работает лучше.
Третья нода построена на Raspberry Pi3 + 2ТБ, лежит в диване (потому что розетки оказались за диваном ) и не отсвечивает , работает с марта прошлого года непрерывно. В начале были проблемы с зависанием, но после исправления настройки (отражено в руководстве) работает стабильно.

Ваша даже первая конфигурация должна была быть рабочей, если бы не сетевое хранилище. Проблема с mount до загрузки решается конфигурацией/скриптами. Могу предложить высказать свой опыт @Odmin относительно практического использования iSCSI.
Остальные сетевые протоколы для хранилищ несовместимы с SQLite. SMB может работать стабильно, но только если сервер - Windows. Linux реализация SMB несовместима полностью.

Тем не менее, практика показывает, что uplink не любит ноды с сетевыми хранилищами, они всегда имеют наибольший процент отмены загрузки: https://forum.storj.io/tags/nfs или проблемы с никогда не завершающимися заливками или с проблемами миграции баз данных. Но все они имеют заметно меньшее количество успешных загрузок и скачиваний.

В моём скрипте всё с точки зрения клиента, как и во всех программах Storj Labs.

Попросите автора чтобы не запутывал и использовал принятое соглашение об именовании.

Они работают против нас. Но доступность и целостность данных клиентов - важнее. Не будет счастливых клиентов - не будет сети.

Все варианты, которые мы обычно предлагаем либо не имеют никаких затрат для операторов - достаточно установить и настроить ПО, либо низкие затраты (одноплатники), если оператор непременно хочет потратить деньги.
Как вы понимаете, под такие требования промышленные датацентры и домашние датацентры не подходят - они значительны по затратам. RAID тоже. Даже программный. И требует значительно больших знаний чем Download - Install - Next - Next - Done.

…И теперь у вас в два раза больше точек отказа. Нужна надёжность, простота и низкие затраты как на установку, так и на обслуживание.

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

Можно, и используется. Просто надо научиться его готовить
@Odmin прошу высказать ваше мнение.

это вообще не виртуализация, это chroot с рюшечками (cgroups, docker hub, etc.).

не рекомендую, если нет управляемого UPS.

с сетевыми хранилищами скорость не та метрика. Там latency. Файлы - мелкие от 1КБ до 4МБ. Для сетевого хранилища - смерти подобно.

izhyrnyy · February 1, 2020, 1:14pm

Это как раз есть, отточено годами, преведен на автоаккумы, держит вечность. тушит все красиво и поочередно

ЗЫ. Спасибо за ответы и терпение

izhyrnyy · February 1, 2020, 1:22pm

Все таки я настаиваю, что онибка у ВАС!

Смотрите, по вашему скрипту я ЯКОБЫ 4000раз загрузил и 1100отдал
Но на ноде еще вчера 600 ОТДАНО и 400 всосано

stefan-benten (118U-AW) storj2 (1TEY-zf) [=-        ]  83,8 GiB [===------ ]  581 GiB  [          ]  0   100      0 -
asia-east-1 (121R-A6)   storj2 (1TEY-zf) [=-        ]  96,2 GiB [          ]  646 MiB  [          ]  0   100      0 -
us-central-1 (12Ea-3S)  storj2 (1TEY-zf) [=--       ]  113 GiB  [          ]  5,72 GiB [          ]  0   100      0 -
europe-west-1 (12L9-Ds) storj2 (1TEY-zf) [=-        ]  99,2 GiB [          ]  806 MiB  [          ]  0 99,42      0 -

Калькулятор дохода показывает такие же цифры
Но скрпит эфективности говорит, что я отдаю в 3 раза меньше, чем получаю

========== AUDIT =============
Successful: 627
Recoverable failed: 1
Unrecoverable failed: 0
Success Rate Min: 99.841%
Success Rate Max: 100.000%
========== DOWNLOAD ==========
Successful: 3917
Failed: 223
Success Rate: 94.613%
========== UPLOAD ============
Successful: 1171
Rejected: 0
Failed: 3990
Acceptance Rate: 100.000%
Success Rate: 22.689%
========== REPAIR DOWNLOAD ===
Successful: 2
Failed: 0
Success Rate: 100.000%
========== REPAIR UPLOAD =====
Successful: 491
Failed: 1385
Success Rate: 26.173%

Alexey · February 1, 2020, 1:24pm

Это только то, что осталось в ваших логах с последнего обновления (если вы не настраивали перенаправление логов, то они удаляются вместе с контейнером). Реальные цифры по загрузкам и скачиваниям лучше смотреть в API или базах данных.

izhyrnyy · February 1, 2020, 1:27pm

Посылаю голову пеплом
Спасибо!

Alexey · February 1, 2020, 5:23pm

A post was merged into an existing topic: Script: Calculate Success Rates for Audit, Download, Upload, Repair

Odmin · February 1, 2020, 7:51pm

Спасибо @Alexey
Действительно, у меня на моей главной локации используется iSCSI хранилище, я работаю с ним с самого начала как получил приглашение в v3 (когда еще был только 1 сателит Стефана и не было Tardigrade сателитов). Из своего опыта могу сказать следующее:

iSCSI можно использовать только тогда, когда вы уверены в вашей сетевой инфраструктуре, 1 отвал сети равносилен краху всех дисков которые были к нету подключены. Нужно использовать резервирование на всех уровнях, iscsi multipath, дублировать линки, дублировать коммутаторы, дублировать питание, дублировать резервное питание для каждого из коммутаторов.
У меня все продублировано, и резервировано, только так можно обеспечить необходимый уровень надежности для iSCSI.
Никогда не используйте виртуальное хранилище ZFS+iSCSI для задач рандомного чтения записли для которых важны задержки (а для Storj это очень важно). Вы не сможете обеспечить низкие задержки без очень глубоких знаний системы визуализации, и даже если у вас получится приемлемый результат, то он будет на несколько порядков хуже того, если бы просто выделили отдельную машину под iscsi хранилище без визуализации, или использовали готовый NAS с такой функцией.
Я использую именно выделенное хранилище с которого я раздаю iSCSI LUN всем машинам.
Необходимо использовать правильное оборудование для iSCSI. далеко не все сетевые карты работают хорошо с iSCSI, и ожидать хорошей производительности от десктопных карт не стоит. Я использую SFP+ карты, и у меня сторедж сеть отделена от общей сети физически.
Необходимо правильно подключать iSCSI таргеты (сервер) к инициаторам (клиенты). Есть два проверенных способа: a) подключать таргет непосредственно к гипервизору и использовать его для размещения виртуальных дисков. б) Подключать таргет внутри виртуальной машины (в линуксе с помощью tgt). Каждый их этих способов имеет свои преимущества и недостатки.
Необходимо контролировать IOPS своего стореджа, и не допускать его перегрузку, так как это чревато отвалом стореджа в целом.
Необходимо правильно монтировать файловую систему с iSCSI дисков. (ZFS+iSCSI не терпит опцию discard это распространенная ошибка, и я тоже на нее наступил, но мне повезло и моя нода выжила )

Я бы не рекомендовал начинать с iSCSI, как видите это весьма не просто, и есть много нюансов. Гораздо проще использовать локальные диски. Переход на iSCSI может быть оправдан только в том случае если у вас больше 2-3 физических серверов виртуализации, или если вы строите отказоустойчивый кластер с выделенным хранилищем.
Лично я прошел весь цикл эволюции SNO и могу поделить его на несколько этапов:

RPI - начальный этап, идеален для начинающих (и не только) SNO.
mini-ITX (встроенный проц) - следующий этап после RPI, когда нужно добавить емкости на туже ноду и при этом сохранить энергоэфективность.
Single server - серверное железо или ATX, когда mini-ITX уже нехватает
Industrial SNO - когда серверов много, и они на разных локациях по всему миру.

Могу с уверенностью сказать, что использовать iSCSI до 4го этапа (если конечно в этом нет необходимости для других задач не связанных со Storj) нет никакого смысла, куда проще (и надежнее) организовать локальные диски.

izhyrnyy · February 10, 2020, 3:37pm

Спасибо большое за большой пост

Много читал, много думал, сделал работу на ошибками

Теперь имеем все те же 3 ноды, которые успешно мигрировали с iSCSI+виртуалка на локальное хранилище
Нодам 2 месяца с разницей в 7 дней
Живут на трех разных провайдерах, провайдеры не нагружены и с Украины РАЗНЫМИ маршрутами имеют идентичный (±10%) пинг в сторону DE-CIX (континентальная точка обмена трафиком)

Ноду1 мигрировал ВРЕМЕННО на “голый” celeron j1900 (ядро имеет 500 попугаев в cpubenchmark) под дебиан10 + 2Тб sata2 ОЧЕНЬ ДРЕВНИЙ wd green на EXT4 (линейно 120мег в сек в начале диска, скорость доступа самая медленная, которая была 5-7лет назад) +16гб памяти

Ноду 2 мигрировал на проксмокс (дебиан10) 24 x Intel® Xeon® CPU E5-2643 v2 @ 3.50GHz (2 Сокеты) ядро имеет 2000 попугаев в cpubenchmark в LXC контейнер. Сам контейнер размещен на локальном отдельном ZFS raid-z1 5 по 4Тб сигейт (линейно 700мег в сек)… если кто не в курсе - в таком случае контейнер ложится тупо в папку без всяких виртуальных дисков

Ноду 3 мигрировал на проксмокс (дебиан10) 24 x Intel® Xeon® CPU E5-2643 v2 @ 3.50GHz (2 Сокеты) ядро имеет 2000 попугаев в cpubenchmark в LXC контейнер. Сам контейнер размещен на локальном ZFS mirror 2 по 1Тб NVME SSD (линейно 2000мег в сек)…

Остановил все 3 ноды
Удалил все три ноды
Бутнулся
Запустил все 3 ноды

Через полтора суток выпал в ШОК

UPLOAD
Нода 1 Success Rate: 70.474%
Нода 2 Success Rate: 23.766%
Нода 3 Success Rate: 38.155%

БОМБИТ!!!
Как так? Как так?
Монстр, на 20000 попугаев на SSD НАЧИСТО проиграл В ДВА РАЗА гонку с овощьным j1900!

Это LXC контейнер так губит производительность процессора? Выходит докер тоже начисто проигрывает виндовым юзверам, которые запускают нативный клиент?

Теперь вопросы, что делать с этой инфой?
Понимаю, что нужно что-то менять.

Хочу одну ноду вытащить с контейнера LXC и запустить сразу на хосте проксмокс
Правда не знаю, куда все это пложить
Одиночный диск на ext4, zfs raid-z, zfs mirror ssd?

Подскажите логику, как запустить 3 ноды на одном линуксе?
Стартую 3 разные докера на разных портах
На роутере все входящее на конкретный порт - бросаю на тот же порт линуха… но не знаю, как быть с исходящими… как разделить траффик с разных нод на одном линухе по своим WAN? На исходящий вы же юзаете рандомные порты?
Ничего плохого не будет, если исходящий траффик я пущу через WANFailover? Или IP ноды на вход и выход железно должно быть идентичным?

Alexey · February 10, 2020, 9:35pm

Пока у меня есть предположение - zfs не сильно удачно настроен. Можно проверить - обменять местами ноду 2 или 3 с 1.
LXC должен работать нормально, но вы, судя по всему, используете docker inside LXC - это плохой вариант и может работать заметно хуже чем просто LXC или просто docker на хосте proxmox. Возможно даже docker в VM debian будет работать заметно лучше.
Это если исключить влияние расстояния (или длины маршрута) от клиента до ваших нод.

Линейная скорость - дело второе, а вот скорость случайного доступа начинает играть роль. При неудачной настройке zfs даже SSD может не спасти.

Клиент (uplink) будет запрашивать вашу ноду по её IP, она должна откликнуться и возвращать трафик туда, откуда запросили. Я не уверен, что клиент будет принимать трафик с другого IP. Я также не уверен, что вам удастся завернуть исходящий ответ на другой маршрут.

Вы можете это проверить с помощью storj-sim, если есть желание потренироваться сначала на тестовой сети.

izhyrnyy · February 12, 2020, 5:02pm

В общем я провел два десятка экспериментов, тестов и имею много данных по ext4, ZFS, тормозов докера, рукатости людей, которые писали софт для нод…

Слышал вы в этом апдейте затюнились в сторону лучших показателе отдачи в сеть
Потому не знаю какую интонацию выбрать… как советующую или раздраженную

Вот тут
https://documentation.storj.io/setup/cli/storage-node

Использование опции -p 28967:28967 там описано через незнание матчасти или это политика компании в доках указывать как сделать вашу ноду МЕДЛЕНЕЕ НА МНОГО ПРОЦЕНТОВ?
Если политика компании - я пойму.
Иначе, грустно все это

Vadim · February 12, 2020, 5:18pm

Mozhet lu4she napishete gde zdes oshibka ili kak sdelat 4toby rabotalo bystree?
Lekgo skazat 4to 4to-to sdelano ploho i ne objasnit sut problemy i kak pravelno.

vanees · February 12, 2020, 5:25pm

Если я верно понимаю, докер создаёт дополнительный nat, который отключается опцией “–network host”. После этого статистика улучшается на порядок. Ждём комментарии @Alexey

izhyrnyy · February 12, 2020, 5:27pm

Ну не на порядок… но до 100%… правда сильно мало опытов… но это ОЧЕНЬ МНОГО

izhyrnyy · February 12, 2020, 5:31pm

Я задал конкретный вопрос и хочу понять…
Меня интересует, с той стороны “ламеры” или это четкое следование корпоративно политики…
Мне нужно сделать выводы… ибо пока я разложил четко 3 вида ЦА компании и я в них или не попадаю или не ХОЧУ ПОПАДАТЬ…
Потому как контора с одной стороны мотивирует нас к догосрочному аптайму, с другой - ей нужны одноразовые ноды на 4-6 месяцев с потерей егресса
Любые виды избыточности сразу присекаются тем, что будут тормоза (и они есть)… правдла сами тормоза компания (вероятно?) закладывает в ноды САМА
И это не за работу с БД пока разговор

Так вот и с гонкою за скоростью… а вдруг они за ней не гонятся, а так изгоняют НЕДОНОРАЗОВЫЕ ноды?