Size: a a a

SDS и Кластерные FS

2020 September 24

BB

Boriss Borisovich in SDS и Кластерные FS
http://paste.openstack.org/show/798359/ - хотелось бы спросить, это нормально, пойдет, сойдет? к8с кластр на виртуалках в проксмоксе, простые хард диски.
источник

k

kvaps in SDS и Кластерные FS
Хочу поделиться с вами историей с хорошим концом.

В рамках переезда Kubernetes-кластера (стейдж, не прод), я переносил также контрол плен линстора. В качестве бэкенда используется отказоустойчивый PostgreSQL (stolon).

Как это бывает в лучших традициях, что-то пошло не так и я забэкапил не ту базу данных, а оригинал удалил. В общем пришлось востанавливаться из чудом найденного бэкапа двухмесячной давности, в котором половина созданных ресурсов в linstor отсутсвовала.

Не долго думая, я навоял простенький bash-скриптик, которым собрал имена всех LVM-томов созданных в кластере и нагенерил команды для создания одноимённых drbd-ресурсов в linstor. Нумерация tcp-портов как и drbd-девайсов не соблюдалась, информация о размерах томов была взята непосредственно из LVM-томов, то есть совпадала не полностью. Ноды, разумеется, я предварительно перезагрузил, чтобы освободить минорные девайсы drbd, которые могли бы начать конфликтовать друг с другом.

Сгенерил resource-definitions, volume-definitions и ресурсы как есть созданные на нодах.
Ресурсы создались но большитсво из них были Inconsistent / Outdated.

Тогда я прошёлся по ним:

drbdadm down $res
yes yes | drbdadm create-md $res
drbdadm up $res

после пересоздания метаданных ресурсы перешли в Inconsistent на всех репликах, что явно указывало на то, что drbd не знал какую реплику считать более актуальной, что легко пофиксилось:

drbdadm primary --force $res"
drbdadm secondary $res"

Удивительно, но все потерянные ресурсы сейчас работают как и до инциидента.
источник

G

George in SDS и Кластерные FS
kvaps
Хочу поделиться с вами историей с хорошим концом.

В рамках переезда Kubernetes-кластера (стейдж, не прод), я переносил также контрол плен линстора. В качестве бэкенда используется отказоустойчивый PostgreSQL (stolon).

Как это бывает в лучших традициях, что-то пошло не так и я забэкапил не ту базу данных, а оригинал удалил. В общем пришлось востанавливаться из чудом найденного бэкапа двухмесячной давности, в котором половина созданных ресурсов в linstor отсутсвовала.

Не долго думая, я навоял простенький bash-скриптик, которым собрал имена всех LVM-томов созданных в кластере и нагенерил команды для создания одноимённых drbd-ресурсов в linstor. Нумерация tcp-портов как и drbd-девайсов не соблюдалась, информация о размерах томов была взята непосредственно из LVM-томов, то есть совпадала не полностью. Ноды, разумеется, я предварительно перезагрузил, чтобы освободить минорные девайсы drbd, которые могли бы начать конфликтовать друг с другом.

Сгенерил resource-definitions, volume-definitions и ресурсы как есть созданные на нодах.
Ресурсы создались но большитсво из них были Inconsistent / Outdated.

Тогда я прошёлся по ним:

drbdadm down $res
yes yes | drbdadm create-md $res
drbdadm up $res

после пересоздания метаданных ресурсы перешли в Inconsistent на всех репликах, что явно указывало на то, что drbd не знал какую реплику считать более актуальной, что легко пофиксилось:

drbdadm primary --force $res"
drbdadm secondary $res"

Удивительно, но все потерянные ресурсы сейчас работают как и до инциидента.
источник
2020 September 25

KA

Konstantin Aristov in SDS и Кластерные FS
kvaps
Хочу поделиться с вами историей с хорошим концом.

В рамках переезда Kubernetes-кластера (стейдж, не прод), я переносил также контрол плен линстора. В качестве бэкенда используется отказоустойчивый PostgreSQL (stolon).

Как это бывает в лучших традициях, что-то пошло не так и я забэкапил не ту базу данных, а оригинал удалил. В общем пришлось востанавливаться из чудом найденного бэкапа двухмесячной давности, в котором половина созданных ресурсов в linstor отсутсвовала.

Не долго думая, я навоял простенький bash-скриптик, которым собрал имена всех LVM-томов созданных в кластере и нагенерил команды для создания одноимённых drbd-ресурсов в linstor. Нумерация tcp-портов как и drbd-девайсов не соблюдалась, информация о размерах томов была взята непосредственно из LVM-томов, то есть совпадала не полностью. Ноды, разумеется, я предварительно перезагрузил, чтобы освободить минорные девайсы drbd, которые могли бы начать конфликтовать друг с другом.

Сгенерил resource-definitions, volume-definitions и ресурсы как есть созданные на нодах.
Ресурсы создались но большитсво из них были Inconsistent / Outdated.

Тогда я прошёлся по ним:

drbdadm down $res
yes yes | drbdadm create-md $res
drbdadm up $res

после пересоздания метаданных ресурсы перешли в Inconsistent на всех репликах, что явно указывало на то, что drbd не знал какую реплику считать более актуальной, что легко пофиксилось:

drbdadm primary --force $res"
drbdadm secondary $res"

Удивительно, но все потерянные ресурсы сейчас работают как и до инциидента.
пафосное превозмогание, Адептус Астартес смотрят с одобрением!!! 👍👍👍
источник

p

pragus in SDS и Кластерные FS
George
page cache не такой умный как вы думаете
Тут кое-кто утверждал что несложно сделать нотификаций от page cache что страничку подняли с диска
источник

M

Mistique in SDS и Кластерные FS
тут такое выкатили..
https://github.com/Seagate/cortx
источник

S

Sergey in SDS и Кластерные FS
kvaps
Хочу поделиться с вами историей с хорошим концом.

В рамках переезда Kubernetes-кластера (стейдж, не прод), я переносил также контрол плен линстора. В качестве бэкенда используется отказоустойчивый PostgreSQL (stolon).

Как это бывает в лучших традициях, что-то пошло не так и я забэкапил не ту базу данных, а оригинал удалил. В общем пришлось востанавливаться из чудом найденного бэкапа двухмесячной давности, в котором половина созданных ресурсов в linstor отсутсвовала.

Не долго думая, я навоял простенький bash-скриптик, которым собрал имена всех LVM-томов созданных в кластере и нагенерил команды для создания одноимённых drbd-ресурсов в linstor. Нумерация tcp-портов как и drbd-девайсов не соблюдалась, информация о размерах томов была взята непосредственно из LVM-томов, то есть совпадала не полностью. Ноды, разумеется, я предварительно перезагрузил, чтобы освободить минорные девайсы drbd, которые могли бы начать конфликтовать друг с другом.

Сгенерил resource-definitions, volume-definitions и ресурсы как есть созданные на нодах.
Ресурсы создались но большитсво из них были Inconsistent / Outdated.

Тогда я прошёлся по ним:

drbdadm down $res
yes yes | drbdadm create-md $res
drbdadm up $res

после пересоздания метаданных ресурсы перешли в Inconsistent на всех репликах, что явно указывало на то, что drbd не знал какую реплику считать более актуальной, что легко пофиксилось:

drbdadm primary --force $res"
drbdadm secondary $res"

Удивительно, но все потерянные ресурсы сейчас работают как и до инциидента.
Если не на проде, то не считается
источник

S

Sergey in SDS и Кластерные FS
источник

ВН

Виталий На Заборе... in SDS и Кластерные FS
Базвордов дохуя, а что оно умеет - не понятно
источник

M

Mistique in SDS и Кластерные FS
Виталий На Заборе
Базвордов дохуя, а что оно умеет - не понятно
Нада проверять
источник

ВН

Виталий На Заборе... in SDS и Кластерные FS
Mistique
Нада проверять
Вообще когда в продукте первой строчкой идет инклюзивность, говно это, а не продукт
источник

ВН

Виталий На Заборе... in SDS и Кластерные FS
я вот одно тут не понял - а откуда 4 порта если x8?
источник

ВН

Виталий На Заборе... in SDS и Кластерные FS
или там M.2 и U.2 порты подключены к одним и тем же контактикам?
источник

ВН

Виталий На Заборе... in SDS и Кластерные FS
или оно как-то хитро работает и допустим если подключить все 4 то они будут по x2?
источник

ВН

Виталий На Заборе... in SDS и Кластерные FS
или всё будет x4 но просто ПСП делиться будет? =)
источник

DV

Dmitry Vylegzhanin in SDS и Кластерные FS
Виталий На Заборе
или всё будет x4 но просто ПСП делиться будет? =)
Полоса делиться будет, там pci-e switch, как раз для случая, когда прямое деление(бифуркация) не поддерживается
источник

ВН

Виталий На Заборе... in SDS и Кластерные FS
kvaps
Ну нбд такое-себе, как я говорил работает достаточно плохо, по крайней мере тот коиент что в qemu-nbd
а, ой, я чот стал писать NBD прокси, а там оказывается можно тупо сделать так

LD_PRELOAD=./qemu_driver.so qemu-nbd -c /dev/nbd0 'vitastor:etcd_host=10.115.0.10\:2379/v3:pool=1:inode=2:size=21474836480'

и всё работает
источник

k

kvaps in SDS и Кластерные FS
Виталий На Заборе
а, ой, я чот стал писать NBD прокси, а там оказывается можно тупо сделать так

LD_PRELOAD=./qemu_driver.so qemu-nbd -c /dev/nbd0 'vitastor:etcd_host=10.115.0.10\:2379/v3:pool=1:inode=2:size=21474836480'

и всё работает
бгг, я же говорил уже про qemu-nbd :)
источник

ВН

Виталий На Заборе... in SDS и Кластерные FS
kvaps
бгг, я же говорил уже про qemu-nbd :)
ну так и после этого просто можно юзать /dev/nbd0
источник

ВН

Виталий На Заборе... in SDS и Кластерные FS
kvaps
бгг, я же говорил уже про qemu-nbd :)
латенси чуть хуже конечно - fio напрямую получается 0.14мс, а fio через qemu-nbd получается 0.18мс. Q=64 иопсы через qemu-nbd - примерно 45к
источник