Вы упоминаете, что используете солвер от google, который выдает решение примерно за полминуты для небольшого числа подов-серверов. Означает ли это, что для размещения нового пода нужно ждать полминуты для выбора оптимального размещения? И что происходит при массовых запусках подов, например, в сценариях включения множества серверов после устранения аварий в ДЦ – делается ли какой-то батчинг при расчете размещений, чтобы ускорить запуск?
Действительно, lockless qdisc был добавлен только в 4.16. Обновление ядра должно немного помочь, все-таки на 2 spinlock будет меньше (при enqueue и dequeue в pfifo_fast).
Насчет mq – блокировка может присутствовать в дочерних qdisc. В __dev_xmit_skb в параметре q передается не сама mq, а дочерняя дисциплина, соответственно, qdisc_lock(q) – блокировка для дочерней дисциплины. Надо смотреть, какая дисциплина стоит под mq. По умолчанию mq настраивается в связке с pfifo_fast, которая lockless – в этом случае блокировка дисциплины не будет браться (сработает проверка q->flags & TCQ_F_NOLOCK).
Но независимо от qdisc есть еще spinlock у буферов сетевой карты, которые берутся при отправке из qdisc в сетевую карту в методе sch_direct_xmit (см. слайд про блокировки). Поэтому от блокировок полностью избавиться не получится, даже если использовать noqueue.
Также стоит проверить, равномерно ли нагружаются очереди сетевой карты. Если, например, весь трафик идет через одну очередь (например, все пакеты принадлежат одному flow), то получится та же глобальная блокировка на уровне отдельной очереди.
Да, действительно, у нас была идея сделать настроить шейпинг на каждый контейнер. В таком случае проблема единой блокировки остается на уровне контейнера. Плюс сильно усложнилась бы конфигурация сети – у нас несколько veth на контейнер (для разных VLAN), которые имеют общий лимит. По результатов предварительных тестов, производительность такого решения была намного хуже, чем вариант с использованием BPF, к которому мы пришли.
Причины те же – избежать взаимного влияния задач вследствие перегрузки сетевой карты. Под входящим трафиком имеется в виду не только внешний трафик, но и внутренний трафик между задачами, которого в наших ДЦ во много раз больше. Без шейпинга какая-то расчетная nonprod задача, например, может забить входящую полосу, повлияв на сетевую задержку соседней prod задачи. Хотя, в случае входящего трафика, мы не можем влиять на его скорость напрямую (пакеты уже прошли сетевую карту), шейпинг позволяет делать это косвенно, влияя на алгоритм congestion control отправителя через увеличение времени round-trip или дропы пакетов при превышении лимита задачей. Разумеется, это возможно только при условии, что congestion control работает правильно. Т.е. трафик внутренний или от правильно настроенных клиентов (от DoS-атаки шейпер конечно не спасет).
В нашем облаке мы запускаем контейнеры на своих собственных железных серверах. VM instances (если вы про них) мы не используем – они медленнее и мы все равно "платим" за весь сервер, а не за instances, как в публичных облаках. Совмещение задач prod и nonprod на одном сервере дает существенную экономию ресурсов – на наших нагрузках она выливается в миллионы долларов. Про причины экономии рассказывалось в разделе про приоритеты задач, также подробнее можно почитать в предыдущей статье про one-cloud.
У нас 99% Java, поэтому сказанное не столь актуально для нас. Но проблемы обновления, разумеется, возможны. Новый базовый образ сначала тестируется на небольшом числе контейнеров, прежде чем применяться ко всем остальным. И это происходит осторожно, так, как описано в разделе «Защитные меры». За 2 года помню только несколько проблем с раскаткой нового базового образа, которые были быстро обнаружены и устранены. На доступность сервисов это не повлияло, т.к. они у нас все резервированы.
Еще можно вспомнить про различные репозитории артефактов, которые имеют свойство меняться при повторных сборках, даже если вы не используете открытые зависимости, а прописываете везде точные версии.
Отличается временем, необходимым на создание образа. В нашем случае это существенная экономия, так как образов много, и изменения в базовые образы вносятся регулярно. Но да, это нестандартный подход, который подойдет скорее крупным сервисам. Например, перед публикацией статьи я узнал, что Google есть библиотека для манипуляции образами, в том числе с возможностью делать rebase.
Насчет формата стораджа – вряд ли его так легко сломают, так как формат манифеста специфицирован и поддерживается не только Docker. Мы, например, в рантайме используем Podman для запуска контейнеров. Что-то менять с хранением манифестов в реестре в ближайшем будущем не планируем.
Если речь про immutability, то мы ее не ломаем, потому что это невозможно: изменить существующий образ в реестре нельзя, это гарантируется уникальностью его digest-а, который есть sha256 от содержимого. Можно только переставить тег на новый образ, что мы и делаем. Но старый образ можно запросить по digest-у. Или вы что-то другое имели в виду под идемпотентностью?
Мульти-стейдж сборку мы не рассматривали, потому что это бы потребовало переделывания механизма сборок всех наших сервисов, а их несколько сотен. И это все-таки — сборка: с запуском Docker, загрузкой слоев из реестра, их распаковкой, т.д. Намного более долгий и сложный для автоматизации процесс, чем отправка нескольких JSON по HTTP, которую можно делать in-process, в тот момент, когда это потребуется.
Считается так: суммируются очки за все верные ответы в соответствие с их ценой в зависимости от сложности (1, 2 или 5 очков) и вычитаются очки за все неверные ответы. Большинство игроков действительно уходят в минус, но это, разумеется, не показатель знаний Java. Результаты сильно улучшаются при второй и последующих попытках. У игры была цель не столько оценивать способности, сколько развлечь участников, дать размять мозги и освежить какие-то знания.
Отлично подмечено, так и есть. Скажу в свое оправдание, что эту ошибку мы случайно добавили, когда готовили тест. Но, в результате, тест получился даже интереснее :).
Стоит еще упомянуть, что в классе Files есть методы, возвращающие Stream, а не DirectoryStream. Эти Stream являются обертками над DirectoryStream, и их также надо закрывать, чтобы не было утечек.
Вы упоминаете, что используете солвер от google, который выдает решение примерно за полминуты для небольшого числа подов-серверов. Означает ли это, что для размещения нового пода нужно ждать полминуты для выбора оптимального размещения? И что происходит при массовых запусках подов, например, в сценариях включения множества серверов после устранения аварий в ДЦ – делается ли какой-то батчинг при расчете размещений, чтобы ускорить запуск?
Действительно, lockless qdisc был добавлен только в 4.16. Обновление ядра должно немного помочь, все-таки на 2 spinlock будет меньше (при enqueue и dequeue в pfifo_fast).
Спасибо за отзыв, рад что статья понравилась :)
Насчет mq – блокировка может присутствовать в дочерних qdisc. В __dev_xmit_skb в параметре q передается не сама mq, а дочерняя дисциплина, соответственно, qdisc_lock(q) – блокировка для дочерней дисциплины. Надо смотреть, какая дисциплина стоит под mq. По умолчанию mq настраивается в связке с pfifo_fast, которая lockless – в этом случае блокировка дисциплины не будет браться (сработает проверка q->flags & TCQ_F_NOLOCK).
Но независимо от qdisc есть еще spinlock у буферов сетевой карты, которые берутся при отправке из qdisc в сетевую карту в методе sch_direct_xmit (см. слайд про блокировки). Поэтому от блокировок полностью избавиться не получится, даже если использовать noqueue.
Также стоит проверить, равномерно ли нагружаются очереди сетевой карты. Если, например, весь трафик идет через одну очередь (например, все пакеты принадлежат одному flow), то получится та же глобальная блокировка на уровне отдельной очереди.
Да, действительно, у нас была идея сделать настроить шейпинг на каждый контейнер. В таком случае проблема единой блокировки остается на уровне контейнера. Плюс сильно усложнилась бы конфигурация сети – у нас несколько veth на контейнер (для разных VLAN), которые имеют общий лимит. По результатов предварительных тестов, производительность такого решения была намного хуже, чем вариант с использованием BPF, к которому мы пришли.
Причины те же – избежать взаимного влияния задач вследствие перегрузки сетевой карты. Под входящим трафиком имеется в виду не только внешний трафик, но и внутренний трафик между задачами, которого в наших ДЦ во много раз больше. Без шейпинга какая-то расчетная nonprod задача, например, может забить входящую полосу, повлияв на сетевую задержку соседней prod задачи. Хотя, в случае входящего трафика, мы не можем влиять на его скорость напрямую (пакеты уже прошли сетевую карту), шейпинг позволяет делать это косвенно, влияя на алгоритм congestion control отправителя через увеличение времени round-trip или дропы пакетов при превышении лимита задачей. Разумеется, это возможно только при условии, что congestion control работает правильно. Т.е. трафик внутренний или от правильно настроенных клиентов (от DoS-атаки шейпер конечно не спасет).
В нашем облаке мы запускаем контейнеры на своих собственных железных серверах. VM instances (если вы про них) мы не используем – они медленнее и мы все равно "платим" за весь сервер, а не за instances, как в публичных облаках. Совмещение задач prod и nonprod на одном сервере дает существенную экономию ресурсов – на наших нагрузках она выливается в миллионы долларов. Про причины экономии рассказывалось в разделе про приоритеты задач, также подробнее можно почитать в предыдущей статье про one-cloud.
Насчет формата стораджа – вряд ли его так легко сломают, так как формат манифеста специфицирован и поддерживается не только Docker. Мы, например, в рантайме используем Podman для запуска контейнеров. Что-то менять с хранением манифестов в реестре в ближайшем будущем не планируем.
Стоит еще упомянуть, что в классе Files есть методы, возвращающие Stream, а не DirectoryStream. Эти Stream являются обертками над DirectoryStream, и их также надо закрывать, чтобы не было утечек.