Вы, пожалуйста, еще раз внимательно прочитайте заголовок статьи и скажите как это связано с тем, что клиентом к дропбоксу тот скрипт не является? Плюс ко всему этот скрипт одноразовый, это не скрипт демона (демоны на баше пишутся по-другому) и find там вызывается только 1 раз, до следующего перезапуска скрипта…
Только я один ожидал увидеть здесь какую-то лютую магию на С, где прям действительно будет клиент, с авторизацией, файл-хендлингом и остальным реализован? Здесь же по факту клиентом dropbox является rclone, а не скрипт на баше, который его вызывает. Таким же образом можно написать статью о однострочном видеоплерее (где будет в баше вызываться VLC) или куда дальше — однострочном 3D шутере…
Мой голос за HAL9000, т.е. по сути без лица вообще, но с огромным обьективом и светящимся красным диодом, смотрится на столько жутко, что прям реально нравится.
ну здесь все очень относительно
1) vMotion у VMware иногда может фризиться и на полторы минуты, особенно если у виртуалки много дисков и много снапшотов или очень медленная сеть, все зависит от ситуации
2) vMotion катает виртуальный машины, CRIU катает standalone процессы, это разные подходы для решения одной задачи, каждый имеет свои плюсы и минусы: к примеру, вероятность успешной миграции VM гораздо ниже чем вероятность успешного переезда одного лишь процесса, переезд виртуальной машины в общем занимает больше времени
все верно, при этом есть приложения, которые относительно безопасно мигрировать в 99% случаев, такие как:
— большинство веб-приложений (за исключением случаев когда браузер что-то очень оперативно в реалтайме обрабатывает и запоздание на секунду-вторую есть критичным)
— streaming servers (какие как Red5)
— слейвы баз данных с асинхронной репликацией (т.к. догнать свое состояние они могут уже после переезда, пару секунд не решают ничего)
— MQS (сервера очереди сообщений)
и т.д.
живая миграция не есть панацеей абсолютно от всех проблем, но если применять эту технологию там, где это возможно, то это может очень здорово упростить жизнь
технически возможно, но все, что будет видно — это время сколько клиент «не видел» сервер, т.к. пакеты при echo-запросе с TTL в 1с и окном больше 1с будут пропадать в никуда, ну а время окна само будет зависеть от того, что изменяется за определенный промежуток времени в RAM, если скажем минимальный ванильный контейнер с данными в RAM 6mb (на примере Jelastic), которые практически не меняются, то и фризтайм будет порядка той секунды, за которую мы на этом примере ничего не увидим, в том числе и разницы между pre/post copy режимами, более того, нельзя сказать, что один из режимов лучше другого (pre/post), все зависит от конкретного приложения и его данных, иногда быстрее срабывает при одном режиме, иногда при другом…
верю, я тоже когда-то пересобирал и сервер и клиент для тестов через mc-dev, Вы сейчас говорите о ReadTimeout, который и правда стоит в 30 секунд, но вылетает оно не по нему, еще есть SocketTimeout и IdleTimeout, т.е. Вы можете выставить ReadTimeout по обе стороны хоть в пару минут, это не спасет, клиент будет плевать ConnectionLost по истечении нескольких секунд от которых сервер ему не ответит (возможно еще и зависит от действий клиента, о которых писал izzholtik)
После миграции контейнера, где живет процесс серверного приложения, IP-адреc остается такой же точно как бы до миграции (даже если этот адрес внутренний), в случае если миграция происходила в другое облако, то между облаками тянется оверлейная сеть (грубо говоря внутри физической внешней сети делается другая, уже логическая сеть, инкапсулированная в физическую), таким образом между облаками контейнеры существуют в одном домене коллизий и чувствуют себя как бы в одной сети. Что касается «точки входа» в этом случае (ноды, где будет прибит уже белый IP), то это может быть обычный шлюз, который включен в эту же самую «логическую» оверлейную сеть.
в ядре Linux есть tcp-rapair режим, он позволяет разморозить процесс с уже установленными сетевыми соединениями в таком виде, в котором они были до заморозки, перед моментом фриза контейнер перестает отвечать «TCP-квитанциями» о получении пакетов новых, потом dst-контейнер делает ARP-реанаунс, после чего получает повторно отправленные клиентом пакеты и уже отвечает нормально на них, таким образом при TCP-соединении пакеты не теряются если не умирают по таймауту (в случае если freezetime окно оказалось слишком большим, к примеру в RAM были частоизменяющиеся данные)
есть особенности, которые надо соблюдать при живой миграции:
— общий домен коллизий в сети, где жил src контейнер и где будет жить dst контейнер (решается оверлейной сетью если разные провайдеры железа)
— чем реже данные будут изменяться в памяти — тем меньше freezetime, который в любом случае неизбежен во время синка последней дельты изменяющихся данных, тем лучше, ну и приложение должно быть готово к этому маленькому окну (хорошая новость в том, что пакеты сетевые при TCP-соединении не потеряются, и эстеблишить новый конект клиенту не нужно, работает фича ядра linux — tcp-rapair режим)
— важна целостность данные при переезде процесса (именно данных, на которые дескрипторы были отрыты т.е. файл на сорс ноде до заморозки должен быть такой же точно и на dst-ноде после разморозки процесса)
на этом ролике играю я, дело в том, что намеренно я ничего не выполнял т.к. совершенно НЕ умею играть в майнкрафт, что касается таймаутов, то они не такие уж и большие, мы проводили много тестов по результатам которых увидели, что если сервер у клиента забрать больше чем на 3 секунды (вне зависимости от того, что происходит в игре), то игра вываливается с сообщением «Connection Lost», можете сами попробовать
Действительно, изнутри работает все очень интересно, когда-то в руки мне попала диссертация Павла Емильянова как-раз по этому проекту, CRIU, еще немало усилий вложил Кирилл Колышкин, сейчас оба работают в компании Virtuozzo. Если у Вас есть какие-то конкретные вопросы относительно нюансов — буду рад на них дать ответ, в рамках своего понимания конечно же.
Оркестратор так и называется — Jelastic. Есть бесплатный триал на 14 дней почти у всех хостинг-сервис провайдеров, через которые продается сервис. Детали есть на сайте компании.
в случае LXC еще вариант замонтировать cgroup ресурс из хоста внутрь контейнера на RO и почитывать его значение сразу с приложения, но это ugly, по-хорошему нужно ждать пока в LXC допилят виртуальный /proc/meminfo
шикарно! спасибо за интересный проект!
если есть результаты перформанс тестов / сравнение по перформансу с другими балансировщиками — не стесняйтесь публиковать ;)
человечество будет "mankind", это немного другой термин
Это все открытые ОС для сетевого оборудования.
1) vMotion у VMware иногда может фризиться и на полторы минуты, особенно если у виртуалки много дисков и много снапшотов или очень медленная сеть, все зависит от ситуации
2) vMotion катает виртуальный машины, CRIU катает standalone процессы, это разные подходы для решения одной задачи, каждый имеет свои плюсы и минусы: к примеру, вероятность успешной миграции VM гораздо ниже чем вероятность успешного переезда одного лишь процесса, переезд виртуальной машины в общем занимает больше времени
— большинство веб-приложений (за исключением случаев когда браузер что-то очень оперативно в реалтайме обрабатывает и запоздание на секунду-вторую есть критичным)
— streaming servers (какие как Red5)
— слейвы баз данных с асинхронной репликацией (т.к. догнать свое состояние они могут уже после переезда, пару секунд не решают ничего)
— MQS (сервера очереди сообщений)
и т.д.
живая миграция не есть панацеей абсолютно от всех проблем, но если применять эту технологию там, где это возможно, то это может очень здорово упростить жизнь
— общий домен коллизий в сети, где жил src контейнер и где будет жить dst контейнер (решается оверлейной сетью если разные провайдеры железа)
— чем реже данные будут изменяться в памяти — тем меньше freezetime, который в любом случае неизбежен во время синка последней дельты изменяющихся данных, тем лучше, ну и приложение должно быть готово к этому маленькому окну (хорошая новость в том, что пакеты сетевые при TCP-соединении не потеряются, и эстеблишить новый конект клиенту не нужно, работает фича ядра linux — tcp-rapair режим)
— важна целостность данные при переезде процесса (именно данных, на которые дескрипторы были отрыты т.е. файл на сорс ноде до заморозки должен быть такой же точно и на dst-ноде после разморозки процесса)
если есть результаты перформанс тестов / сравнение по перформансу с другими балансировщиками — не стесняйтесь публиковать ;)