commit -m "better"
Мне тут сказали, что я не смогу запилить херобору, которая бы решала эту задачу, за 5 минут. Вызов был принят, и вот результат: Это демон, может быть запущен на нескольких хостах: pg# cat run.sh #!/bin/sh set -xue while true; do sleep 1 etcdctl…
Про пользу #etcd в home #lab.
В качестве роутера я использую коробочку от Xiaomi.
Ну, потому что она мне дает простой в эксплуатации mesh, и потому что, когда-то, дала мне возможность быстро развернуть нормальную сетку в доме за городом.
Нормальную - это значит, что я из любой точки дома получаю заявленный гигабит от провайдера, по воздуху.
Но у этой коробочки есть один небольшой недостаток - она конфигурируется из web gui, и настроек там очень мало.
(openwrt? нет, не хочу, когда руки до этого дойдут, запилю свой роутер, на #stal/ix)
В общем, в форме, которая настраивает port forwarding, можно установить только один адрес на входящий порт.
А я, знаете ли, решил, что в моем home lab будет сколько возможно мало точек отказа.
Поэтому, когда я решил наконец-то настроить edge proxy, который бы занимался тем, что делал ретраи, разбрасывал запросы по бекендам, и делал dispatch по vhost, я приуныл.
Потому что если взгромоздить этот прокси на 1 тачку, то это +1 точка отказа, а если хочется взгромоздить на несколько, то смотри выше пункт про то, что в формочке можно указать только 1 адрес для одного внешнего порта.
У меня в голове закрутились слова IPVS, keepalived, и я, признаться, приуныл еще больше!
Вот, придумал решение, которое мне кажется не очень всратым, решает мою проблему, и не содержит слов ipvs, keepalived, и прочих ноковых приблуд.
У меня на трех хостах крутится скрипт, который в цикле пытается, под etcd lock, запустить прокси. Везунчик, который получил блокировку, вешает на eth0 какой-то заранее известный IP адрес, и запускает на нем proxy. А все остальные, если блокировку взять не удалось, у себя этот IP адрес убирают, чтобы он всегда был только на одном интерфейсе.
В роутере прописываю этот самый IP адрес.
Если хост умирает, то кто-то другой получает блокировку, и цикл повторяется.
Ну, то есть, получился такой автоматический failover, без IP балансировки нагрузки.
У этого решения есть понятные проблемы - что произойдет, если master умер "странно", Ну, вот, блокировку в etcd проебал, а IP адрес с интерфейса снять не получается? Не знаю, расцениваю вероятность этого, как довольно низкую.
В качестве роутера я использую коробочку от Xiaomi.
Ну, потому что она мне дает простой в эксплуатации mesh, и потому что, когда-то, дала мне возможность быстро развернуть нормальную сетку в доме за городом.
Нормальную - это значит, что я из любой точки дома получаю заявленный гигабит от провайдера, по воздуху.
Но у этой коробочки есть один небольшой недостаток - она конфигурируется из web gui, и настроек там очень мало.
(openwrt? нет, не хочу, когда руки до этого дойдут, запилю свой роутер, на #stal/ix)
В общем, в форме, которая настраивает port forwarding, можно установить только один адрес на входящий порт.
А я, знаете ли, решил, что в моем home lab будет сколько возможно мало точек отказа.
Поэтому, когда я решил наконец-то настроить edge proxy, который бы занимался тем, что делал ретраи, разбрасывал запросы по бекендам, и делал dispatch по vhost, я приуныл.
Потому что если взгромоздить этот прокси на 1 тачку, то это +1 точка отказа, а если хочется взгромоздить на несколько, то смотри выше пункт про то, что в формочке можно указать только 1 адрес для одного внешнего порта.
У меня в голове закрутились слова IPVS, keepalived, и я, признаться, приуныл еще больше!
Вот, придумал решение, которое мне кажется не очень всратым, решает мою проблему, и не содержит слов ipvs, keepalived, и прочих ноковых приблуд.
У меня на трех хостах крутится скрипт, который в цикле пытается, под etcd lock, запустить прокси. Везунчик, который получил блокировку, вешает на eth0 какой-то заранее известный IP адрес, и запускает на нем proxy. А все остальные, если блокировку взять не удалось, у себя этот IP адрес убирают, чтобы он всегда был только на одном интерфейсе.
В роутере прописываю этот самый IP адрес.
Если хост умирает, то кто-то другой получает блокировку, и цикл повторяется.
Ну, то есть, получился такой автоматический failover, без IP балансировки нагрузки.
У этого решения есть понятные проблемы - что произойдет, если master умер "странно", Ну, вот, блокировку в etcd проебал, а IP адрес с интерфейса снять не получается? Не знаю, расцениваю вероятность этого, как довольно низкую.
😁10🥴7🤔4👌3❤2🐳2
commit -m "better"
Истории про мою home #lab. И вторая проблема - а как написать правильную конфигурацию GRUB, чтобы не надо было заморачиваться с probe всего и вся? Флешка может использоваться на разном железе, и не всегда она будет hd0. В итоге, решил я это так: * На первой…
Истории про home #lab.
Пока я переводил хосты на новую схему загрузки (с флешкой в качестве /dev/root), мне несколько раз пришлось пошатать #etcd.
Убрать с хоста, переналить хост, вернуть etcd с пустым начальным состоянием на хост, подождать, пока оно догонется с оставшихся реплик.
Два раза все прошло хорошо, на третий раз я осмелел, и решил устроить ученьки с disaster recovery.
Взял, и под живым инстансом etcd забил его базу из /dev/random, дождался, пока это все не дошло до кластера, ребутнул, переналил на новую схему, поднял пустой инстанс etcd.
В общем, провел пару часов за чтением документации, кластер оживил.
Но это было несколько сложнее, чем я ожидал.
Потому что кворум из двух машин перевел этот третий инстанс в состояние "never again", то есть, пометил его id как сломанный навсегда, и отказывался с ним иметь дело даже после переналивки.
Выяснилось, что надо вручную удалить из кластера этот id, и добавить новый инстанс с новым id.
Зачем так сложно, и зачем эта процедура отличается от предыдущей, не очень понятно.
Зато, КМК, теперь я получил некоторый опыт, и уверенность, что, в случае чего, данные в etcd я не проебу, и мне теперь не сташно класть туда какие-то master/original данные, а не только легко восстановимые копии.
Пока я переводил хосты на новую схему загрузки (с флешкой в качестве /dev/root), мне несколько раз пришлось пошатать #etcd.
Убрать с хоста, переналить хост, вернуть etcd с пустым начальным состоянием на хост, подождать, пока оно догонется с оставшихся реплик.
Два раза все прошло хорошо, на третий раз я осмелел, и решил устроить ученьки с disaster recovery.
Взял, и под живым инстансом etcd забил его базу из /dev/random, дождался, пока это все не дошло до кластера, ребутнул, переналил на новую схему, поднял пустой инстанс etcd.
В общем, провел пару часов за чтением документации, кластер оживил.
Но это было несколько сложнее, чем я ожидал.
Потому что кворум из двух машин перевел этот третий инстанс в состояние "never again", то есть, пометил его id как сломанный навсегда, и отказывался с ним иметь дело даже после переналивки.
Выяснилось, что надо вручную удалить из кластера этот id, и добавить новый инстанс с новым id.
Зачем так сложно, и зачем эта процедура отличается от предыдущей, не очень понятно.
Зато, КМК, теперь я получил некоторый опыт, и уверенность, что, в случае чего, данные в etcd я не проебу, и мне теперь не сташно класть туда какие-то master/original данные, а не только легко восстановимые копии.
👍13🔥7🤔2