« Rev
@openstack_ru   33
Fwd »


Mike
Для вас смерть вм и потеря данных - это норма. Ок.
Смотря какая VM. Не уверен, что сейчас кто-то сможет сделать FT VM с 16 CPU и 256RAM
Sergei
Можно все, что угодно. Только зачем? Fail домен опускать на уровень дисков? А NF выставлять в 0.45? И зачем это надо?
в смысле зачем? из двух машин вы просто не сможете собрать кворум. никак. никогда. кворум либо собран и 100% в апе, либо кворума нет. с тремя мониторами и двумя нодами с osd можно использовать RF=2 и уметь терять одну машину.
Mike
Ох как нравятся мне сферические теоретики
Ну VMware, так не может. Так как смысла нет.
Sergei
и не уметь терять по диску из разных нод?)
сеф и так не умеет терять по диску из трех разных нод в плоском кластере.
Mike
Ну VMware, так не может. Так как смысла нет.
Т.е. вы можете убрать данное ограничение, но вот вопрос, а не упретесь ли в канал синхронизации двух VM? Надо же все изменения в памяти, флагов CPU синхронизировать.
Mike
failure domain в описанном мной сетапе - 1 хост.
Т.е. сервер вылетел, случайно выключен, выдернули сеть - и данных нет?
Mike
Тогда поясни подробнее.
Sergei
два сервера с n дисков в каждом. один дополнительный сервер (виртуалка, контейнер, что угодно) для кворума мониторов. size = 2, копии размазываются между серверами (одна - на один, другая - на другой). min size = 1, чтобы работало в деградировавшем режиме. можно потерять любой из серверов без потери кворума и данных, кластер останется работать, кворум сохранится. фактически получится DRBD, только с кворумом мониторов.
Sergei
нет, не рекомендую это в продакшн. впрочем, DRBD тоже не рекомендую. и вообще не рекомендую задумываться о shared block storage, пока у вас нет 3+ серверов.
Sergei
Смотря какая VM. Не уверен, что сейчас кто-то сможет сделать FT VM с 16 CPU и 256RAM
кстати мне всегда было интересно (никогда не пробовал, нужды не было). ну вот беру я эту маленькую виртуалочку, в которой там 2 cpu и 4 gb ram и начинаю из /dev/urandom заполнять память с космической скоростью. потом захочу вырубить, чтобы сработал чудо-FT. что произойдет-то? канал в память шире канала в другой сервер в дохрена раз. как оно с этим справится?
Mike
два сервера с n дисков в каждом. один дополнительный сервер (виртуалка, контейнер, что угодно) для кворума мониторов. size = 2, копии размазываются между серверами (одна - на один, другая - на другой). min size = 1, чтобы работало в деградировавшем режиме. можно потерять любой из серверов без потери кворума и данных, кластер останется работать, кворум сохранится. фактически получится DRBD, только с кворумом мониторов.
При выходе сервера, кластер остается в деградированном режиме. Что чревато, т.к. если в решениях drbd ставят всегда hw raid, с хотспаре, то в ceph часто без него. И при вылете диска или появлении битых блоков на втором сервере - с данными печально. Если сервера толстые, то и балансировка кластера после возвращения сервера будет идти долго.
Mike
Решение да, возможно, но не комильфо.
Mike
Кто "вы"?
Разработчики FT в VMware или ваши в вашем KVM на стеройдах.
Sergei
ну да. ты первый раз чтоль такую аргументацию видишь?
да :( о том что с DRBD связь порвалась, у нас split-brain и трахайся потом как хочешь, чтобы данные восстановить скромно умолчим? :)
Sergei
>и балансировка кластера после возвращения сервера будет идти долго. интересно, в случае DRBD ей почему-то нужно будет идти быстрее?
Mike
пруф?
А самому подумать почему?
Sergei
А самому подумать почему?
бремя доказательства на вас. я тестировал. правда в 8-й ветке DRBD еще. и производительность - боль.
Sergei
https://toster.ru/q/39291
Anton
Разработчики FT в VMware или ваши в вашем KVM на стеройдах.
Ключевой вопрос. RPO/RTO в деньгах кто считал? Кто вообще слова эти слышал?
Mike
Ключевой вопрос. RPO/RTO в деньгах кто считал? Кто вообще слова эти слышал?
И? Ч вам техническое, вы мне деньги. Если есть FT для жирных VM - покажи, без проседания производительности. Для уменьшения RTO/RPO есть масса других технологий.
Mike
https://toster.ru/q/39291
Почитал. Взял гигабитный линк с кодированием 8/10 и drbd синхронизируется по TCP. Так же если drbd делает fsync при записи блоков, тогда упрешся в однопоточный mdraid, который metadata записывает в один поток.
Sergei
mdraid не однопоточный.
Sergei
и там есть измерения производительности mdraid.
Mike
mdraid не однопоточный.
Т.е. соскочил с техники в деньги. Он не однопоточный на блоки, а я про другое.
Sergei
что? какие деньги?
Sergei
мы с @antonvirtual - разные люди.
Sergei
direct=1 buffered=0
Sergei
а, ну ок.
Sergei
я, пожалуй, не буду продолжать дискуссию :)
Михаил
зря) хоть чат оживили)
Mike
я, пожалуй, не буду продолжать дискуссию :)
Правильно, открой консоль и man fio почитай
Mike
Вбей в тест на mdraid fsync=1
Mike
Проблема с однопоточной записью метаданных в mdraid - известна, описана в рассылке. Сам столкнулся с этим, когда был mdraid10 c 36 дисками. По fio c direct=1 хорошо, а c fsync - печаль
Sergei
я помню, я после этого вопроса вынес метаданные drbd на рамдиск. но картина не изменилась.
Mike
Техника делается ради денег. Внезапно
Если сейчас взять RDMA/Infiniband или OP от Intel можно снизить латенси и поднять планку. Можно, вопрос спроса.
Mike
AFK
Artem
Для вас смерть вм и потеря данных - это норма. Ок.
Не коверкайте чужие слова в той манере- так как это видете Вы. Если нет иснтуремнтов для обеспечения HA - значит его нет.
Anton
Вот вообще ничего не понял. Артем, как вы написали - так я и понял
Anton
Если вы считаете, что вас поняли неправильно, то задайте вопрос себе - может вы просто мысль плохо выразили?
Anton
Первое правило публичных дискуссий и выступлений. Если спикера не поняла аудитория - это проблема спикера
Artem
Первое правило публичных дискуссий и выступлений. Если спикера не поняла аудитория - это проблема спикера
OK. Я не собирался "выступать публично" и сообщение не вам было- вы взяли тему- развили так как это видется вам- имхо это проблема вашей фантазии, а не моих высказываний. Хорошего дня.
Anton
Теперь забавно, вы еще и обиделись :)
Igor
👍
Igor
> Теперь забавно, вы еще и обиделись :) 2 боярышника этому господину!
Anton
> Теперь забавно, вы еще и обиделись :) 2 боярышника этому господину!
Право, оставьте себе, не отрывайте от сердца. Я пью Гиннесс
Михаил
@Lumen_Ratio а ты расскажешь что-нибудь интересное про iscsi модуль от редхата?
Mike
на просторах sladeshare есть из презентация по этому поводу
Mike
Есть такое от 2015 https://www.susecon.com/doc/2015/sessions/TUT16512.pdf
Mike
Сейчас, возможно, они переходят на вариант userspace, как было описано в посте Себастьяна.
Mike
Suse и RH сейчас тестно сотрудничают по Ceph.
Mark ☢️
А правильноли я понял, что айскайзи таргет всеравно будет в ядре, но за rbd он будет обращаться не к ядрёной части а к юзерспейсу ?
Mike
А правильноли я понял, что айскайзи таргет всеравно будет в ядре, но за rbd он будет обращаться не к ядрёной части а к юзерспейсу ?
Себа писал, что хотят сделать именно usespace таргет. Что подтверждается тут: http://www.slideshare.net/esimone74/tut18972-unleash-the-power-of-ceph-across-the-data-center 44 слайд
Михаил
А что сейчас есть уже готовое?
Михаил
Production ready
Mike
от редхата это: https://github.com/pcuzner/ceph-iscsi-ansible
Mike
от Suse это SLES: https://www.suse.com/documentation/ses-2/book_storage_admin/data/cha_ceph_iscsi.html
Mike
т.е. SES2
Михаил
А сусе модуль насколько корректно запихнуть в центос?
« Rev
@openstack_ru   33
Fwd »