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

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

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

--------------------------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: [ 5.250722] scsi host3: iSCSI Initiator over TCP/IP
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.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 kernel: [ 6.308682] sd 3:0:0:0: [sdb] Attached SCSI disk
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 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: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 kernel: [ 8.947377] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
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 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: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: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
Blockquote

Вот еще, почему-то контейнер_д загрузился намного раньше чем 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

Вопросы

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

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

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

  2. Если мне оставлять все как есть, может есть мысли у кого, что сделать что б не поймать такой глюк в будущем?
    Можно не запускать докер, пока при загрузке не проверится и примаунтится iSCSI?
    Или как-то скриптом стартовать докер только после проверки, примонтировался ли том?
    Или что б загрузка системы становилась колом пока не примаунтится iSCSI?
    Как правильнее?

  3. storj впринципе можно в заданных условиях первой части сапоортить надежно?

  4. Собираю советы, как правильнее все перестроить, дабы и данные не терять в случае смерти ОДНОГО диска… и не выделять дополнительную вереницу дисков ТОЛЬКО для storj.

Ну и в догонку
Подскажите по стате плз
На 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Тб в месяц?

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

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

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

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

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

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

Даже если это 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
}

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

Направление трафика всегда с точки зрения клиента. 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 будет ниже, потому что нода не будет находить нужные файлы, однако на аудит не влияет.

Тогда скрипт, который в вашей теме скачал - обманывает
Ибо у меня другим скриптом показывает что я каждый день 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 ноды однинаково организованные
Прошу сказать фэ

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

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

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

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

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

  • простой домашний роутер 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ТБ, лежит в диване (потому что розетки оказались за диваном :frowning:) и не отсвечивает :slight_smile: , работает с марта прошлого года непрерывно. В начале были проблемы с зависанием, но после исправления настройки (отражено в руководстве) работает стабильно.

Ваша даже первая конфигурация должна была быть рабочей, если бы не сетевое хранилище. Проблема с 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.

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

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

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

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

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

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

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

Смотрите, по вашему скрипту я ЯКОБЫ 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%

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

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

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

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

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

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

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

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

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

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

Теперь имеем все те же 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 ноды на вход и выход железно должно быть идентичным?

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

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

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

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

1 Like

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

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

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

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

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.

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

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

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

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