В этом и суть учений: вы превентивно и подконтрольно с минимальными и понятными рисками для всех, заранее подготовившись, перепроверив все сервисы и собрав кучу инженеров для максимально быстрой реакции, проводите отключение AZ/DC только для потенциально готовой части инфры, против вы просто “молитесь”
На третью AZ доразвёрнут etcd, на базе которого собирается кворум для обеспечения leader election в кубе и во всех инсталляциях региональных баз данных
Вам 3 etcd ноды достаточно для обеспечения надежности?
Не рассматриваете ситуацию когда одна etcd нода находится под maintenance и недоступна, а вторая тоже недоступна, но уже по своей инициативе? Это далеко не нулевая вероятность
в нашем Cilium DNS-запросы компонентов облака разъезжались round robin’ом по всей группировке DNS-серверов в обеих AZ. Что само по себе звучит сомнительно, но в случае отказа зоны означает, что 50% DNS-запросов проливается на пол, пока мёртвые эндпоинты не выключатся из балансировки.
Кажется, технически, это абсолютно штатная ситуация и через несколько десятков секунд или нескольких минут список эндпоинтов должен был актуализироваться и закрыть проблему с dns.
У вашего кубера это заняло сильно больше времени? Или оно само не разрешилось и пришлось чинить руками?
В общем, исправление странной модели роутинга DNS-трафика добавили к списку других action item’ов инцидента.
Исправили? Какое решение получилось?
Для себя в качестве оптимального решения на будущее мы выбрали учения на препроде как целевую механику
Поправьте, если что. Вы провели учения с отключением AZ/DC один раз. Пришли к выводу что это нужно делать периодически, но только в preprod. Причина, почему вы отказались от учений в prod - несерьезные клиенты, которые живут в одной AZ.
Вы хотите внедрить SLA с пользователем, который покроет риски связанные с учениями?
Или SLA уже имеется, но было принято решение пожертвовать учениями в prod в пользу несерьезных клиентов?
Еще один вопрос: цель учений была выяснить переживет ли выход из строя AZ/DC ваша инфраструктура (сайт, api, management services) или - выяснить переживет ли выход из строя AZ/DC ваша инфраструктура + сервисы клиента? Если второе, то вопросов нет, если первое - мне непонятна логика отказа от учений в prod, ведь инфра от клиента отделена и никаких проблем отключить только сегменты сети инфры нет.
потому что тогдашний HA-proxy не давал нужного функционала
Услышал только что вам не хватило функционала haproxy. Полагаю, что не только функционала, но и производительности
Поэтому кратко: сложно, дорого, долго, хуже результат.
Тут не понял, что и против чего сравнивается
чтобы хорошо отработать изменение состава рилов мы применяем Maglev-хеширование, устойчивое таким вещам. Об этом есть в указанном выпуске реалити. Здесь возможно я, как погружённый в тех детали человек, немного излишне вытащил некоторые вещи наружу
Наоборот, деталей в статье катастрофически не хватает
Про балансировщик.
В клауд ip only сетях у клиента остается еще один способ зарезервировать IP между vm - api клауда, с функцией назначения конкретного IP к конкретной ноде. Далее keepalived ->
Если клауд не предаставляет ни L2, ни динамическую маршрутизацию, ни API функцию назначения IP, то да, у клиента остается только одно - использовать балансировщик клауда
мы готовим к выходу сервис облака под названием ALB
Вижу вы используете терминологию AWS. Если бы в статье были ссылки на AWS сервисы по типу: “Наш L4 балансировщих предоставляет функционал аналогичный/похожий на AWS ELB”, вопросов было бы кратно меньше
Если углубляться в детали, то для этого нужна отдельная статья на тему «В чём преимущество облачного сетевого балансировщика над доморощенными решениями»
Можно тезисно, без деталей?
консистентный пользовательский опыт
Ранее такая формулировка не попадалась. Можно раскрыть смысл?
управление сетевыми сессиями: если установлена клиентская сессия с некоторым рилом, то трафик от того же клиента продолжает ходить туда, в один и тот же рил, до тех пор, пока сессия не закончится. И всё это корректно работает даже в условиях постоянных изменений топологии рилов.
Речь про tcp сессию?
Что значит изменения топологии рилов? Добавление/удаление рилов, которые находятся под VIP?
Tcp сессия не рвется при ее переезде на другой рил? Вы синхронизируете состояния tcp соединений между всеми рилами конкретного VIP?
Или тут речь про что-то совершенно другое?
И уж простите, но, понимая внутреннее устройство нашего балансировщика, я никому не советую делать его самому.
Совет совершенно неоднозначный.
Если вы говорите о клиенте вашего облака и его собственном балансировщике в вашем облаке, то, конечно, вы вне конкуренции, потому как вы имеете доступ к своей внутренней инфраструктуре, а ваш клиент - очевидно нет, и даже теоретически этого не может. Если речь про о L4/L7 LB, то, кажется, клиенту ничего изобретать не нужно, давно существуют рабочие L4/L7 решения. Если вы про балансировщики уровня облачного провайдера, любой более менее крупный cloud не может позволить себе не написать свое решение, как минимум из-за рисков вендорлока и интеграции.
эта тунеллирующая виртуалка служит в нашей архитектуре единой точкой отказа. Она падает, и шифрованный L3-L4-канал до on-prem сети пропадает, а значит, наш сервис финансовых операций прекращает свою работу. Никаких механизмов автоматического восстановления этой конструкции нет.
IPsec поднимает облачный провайдер или клиент?
Если IPsec поднимает провайдер, почему VM нельзя задублировать аналогично облачному LB?
Если IPsec поднимает клиент, почему он не может воспользоваться технологиями VRRP или динамической маршрутизацией? Облако не предоставляет клиенту ни возможность анонсировать IP по одному из динамических протоколов, ни сетевой L2 домен?
НИКОГДА не выполнять команду defrag одновременно на всех нодах etcd кластера. Это, гарантировано, на нагруженном кластере, приведет к отказу в обслуживании; да, скорее всего временно, но тем не менее, может стать триггером к более серьезным проблемам. Почему такое может случиться? Каждый раз перечислять все узлы кластера в аргументе --endpoints= для etcdctl контрпродуктивно, поэтому, как правило, используется env переменная ETCD_ENDPOINTS, где прописаны все участники кластера
Если у вас etcd до версии v3.6.x может быть неожиданностью, что auto compaction mode работает не так как ожидается. В предыдущих версиях много неразберихи: в v3.2.x, например, параметр --auto-compaction-mode отсутствует, в v3.3/4/5.x разные дефолты для cli-флага --auto-compaction-mode и в функции NewConfig() при запуске через --config-file. С версии v3.6.x это все устранили
Это близкое к тому как пишется WAL: etcd преаллоцирует 64MiB файл, последовательно в него пишет, после заполнения текущего открывает новый файл и так далее.
Тут есть нюанс: fio не умеет преаллоцировать файлы во время работы и после заполнения удалять их, поэтому все файлы нужно создать заранее.
Задавайте число файлов (nrfiles) достаточно большим, чтобы тест не завершился за считанные секунды на SSD/NVMe.
Длительность теста по времени (runtime=) нет смысла проводить, потому как после заполнения всех преаллоцированных файлов fio начнет писать в уже заполненные файлы, что провоцирует паттерн readModifyWrite и iops падают на порядок. У меня было так 250k -> 20k.
Block size (bs) не кратен 4k, чтобы было честно, так как etcd при записи в wal никакие границы блока не выравнивает и запись может быть любого размера (разве что ограничена --max-request-bytes).
Можно добавить fio сценарий для bbolt (он, кстати, совершенно другой), но основной паттерн для etcd, все таки WAL
А еще есть режим, когда ноды одного кластера сами друг друга распечатывают.
Вот это интересно.
Нашел схематичное объяснение как устроено распечатывание в блоге вашего продукта.
Только непонятно как это реализовано технически. Полагаю, на сервере, рядом с Stronghold или в самом Stronghold, например в плагине, есть код, который дискаверит узлы кластера и если они в unseal режиме распечатывает их (`vault operator unseal`). И еще не совсем понятно как происходит discovery узлов. Я догадываюсь как это сделать для raft storage backend (просто `vault operator raft list-peers`), а вот для других storage, наверное, придется дополнительно узлы где-то публиковать
Подскажите как у вас организованы процессы доставки unseal ключей ответственным сотрудникам, ротация ключей и распечатка хранилища?
1) Я так понимаю при разворачивании нового vault есть процесс, который каждую из 5-ти частей Шамира шифрует соответствующим открытым ключом "ответственного" и отправляет результат, условно, на почту "ответственного". Так?
2) Чтобы провести ротацию unseal ключей или распечатать хранилище, по прежнему, должна собраться группа из "ответственных" людей?
3) Используете ли вы Auto unseal или что-то подобное?
Я хочу чтобы xbox шел через Турцию. Зачем искать mac xbox, прописывать какие-то неявные правила, когда я могу подключить xbox к "Турецкой" точке доступа? Кажется, проще некуда
Интересно получается, RB4011iGS+5HacQ2HnD-IN в 10 раз быстрее mAP lite на шифровании, в 10 раз производительнее cpu, в 10 раз дороже и ~ в 30 раз тяжелее ;)
Вы плохо читали. 100 профилей это просто загруженный конфиг. Из них только несколько VPN активны. И они не грузят проц. Утилизация проца в 100% когда либо идет реальная работа, т.е. шифруется трафик на 30Mbps, либо когда идет активная запись/чтение конфигурации RouterOS. Именно последняя ситуация является аномалией
цена - скорее всего обошелся бы раза в 2-3 дороже, а если устройство классом выше и современнее - в 5+ раз
и самое главное, я не знаю его возможностей, и как следствие сможет ли оно без прошивки на dd-wrt/openwrt смочь поднять несколько AP с маршрутами через WG? И можно ли их вообще прошить на dd-wrt/openwrt? И будет ли оно потом стабильно работать на этих прошивка?
Что вы пытаетесь сказать используя намеки и смайлики? Если у вас есть конструктивные мысли, идеи, прошу, изложите
В этом и суть учений: вы превентивно и подконтрольно с минимальными и понятными рисками для всех, заранее подготовившись, перепроверив все сервисы и собрав кучу инженеров для максимально быстрой реакции, проводите отключение AZ/DC только для потенциально готовой части инфры, против вы просто “молитесь”
Вопросы как у всех:
какие требования к L4 LB у вас были
какие существующие решения тестировали
почему они не подошли и пришлось написать свое
на какие технологии опирается наш LB: ebpf/xdp, dpdk, …
почему вы используете dnat при доставке пакета до real, а не инкапсуляцию
какие функции уже реализованы в LB
что хотите дополнительно реализовать
Было бы хорошо добавить этот немаловажный факт в статью. Спасибо
Без снятия нагрузки и с отказом в обслуживании?
Вам 3 etcd ноды достаточно для обеспечения надежности?
Не рассматриваете ситуацию когда одна etcd нода находится под maintenance и недоступна, а вторая тоже недоступна, но уже по своей инициативе? Это далеко не нулевая вероятность
Кажется, технически, это абсолютно штатная ситуация и через несколько десятков секунд или нескольких минут список эндпоинтов должен был актуализироваться и закрыть проблему с dns.
У вашего кубера это заняло сильно больше времени? Или оно само не разрешилось и пришлось чинить руками?
Исправили? Какое решение получилось?
Поправьте, если что. Вы провели учения с отключением AZ/DC один раз. Пришли к выводу что это нужно делать периодически, но только в preprod. Причина, почему вы отказались от учений в prod - несерьезные клиенты, которые живут в одной AZ.
Вы хотите внедрить SLA с пользователем, который покроет риски связанные с учениями?
Или SLA уже имеется, но было принято решение пожертвовать учениями в prod в пользу несерьезных клиентов?
Еще один вопрос: цель учений была выяснить переживет ли выход из строя AZ/DC ваша инфраструктура (сайт, api, management services) или - выяснить переживет ли выход из строя AZ/DC ваша инфраструктура + сервисы клиента? Если второе, то вопросов нет, если первое - мне непонятна логика отказа от учений в prod, ведь инфра от клиента отделена и никаких проблем отключить только сегменты сети инфры нет.
Спасибо.
Услышал только что вам не хватило функционала haproxy. Полагаю, что не только функционала, но и производительности
Тут не понял, что и против чего сравнивается
Наоборот, деталей в статье катастрофически не хватает
В клауд ip only сетях у клиента остается еще один способ зарезервировать IP между vm - api клауда, с функцией назначения конкретного IP к конкретной ноде. Далее keepalived ->
Если клауд не предаставляет ни L2, ни динамическую маршрутизацию, ни API функцию назначения IP, то да, у клиента остается только одно - использовать балансировщик клауда
Вижу вы используете терминологию AWS. Если бы в статье были ссылки на AWS сервисы по типу: “Наш L4 балансировщих предоставляет функционал аналогичный/похожий на AWS ELB”, вопросов было бы кратно меньше
Можно тезисно, без деталей?
Ранее такая формулировка не попадалась. Можно раскрыть смысл?
Речь про tcp сессию?
Что значит изменения топологии рилов? Добавление/удаление рилов, которые находятся под VIP?
Tcp сессия не рвется при ее переезде на другой рил? Вы синхронизируете состояния tcp соединений между всеми рилами конкретного VIP?
Или тут речь про что-то совершенно другое?
Совет совершенно неоднозначный.
Если вы говорите о клиенте вашего облака и его собственном балансировщике в вашем облаке, то, конечно, вы вне конкуренции, потому как вы имеете доступ к своей внутренней инфраструктуре, а ваш клиент - очевидно нет, и даже теоретически этого не может. Если речь про о L4/L7 LB, то, кажется, клиенту ничего изобретать не нужно, давно существуют рабочие L4/L7 решения. Если вы про балансировщики уровня облачного провайдера, любой более менее крупный cloud не может позволить себе не написать свое решение, как минимум из-за рисков вендорлока и интеграции.
IPsec поднимает облачный провайдер или клиент?
Если IPsec поднимает провайдер, почему VM нельзя задублировать аналогично облачному LB?
Если IPsec поднимает клиент, почему он не может воспользоваться технологиями VRRP или динамической маршрутизацией? Облако не предоставляет клиенту ни возможность анонсировать IP по одному из динамических протоколов, ни сетевой L2 домен?
Какие еще best practice по etcd можно добавить:
НИКОГДАне выполнять командуdefragодновременно на всех нодах etcd кластера. Это, гарантировано, на нагруженном кластере, приведет к отказу в обслуживании; да, скорее всего временно, но тем не менее, может стать триггером к более серьезным проблемам. Почему такое может случиться? Каждый раз перечислять все узлы кластера в аргументе--endpoints=дляetcdctlконтрпродуктивно, поэтому, как правило, используется env переменнаяETCD_ENDPOINTS, где прописаны все участники кластераЕсли у вас etcd до версии
v3.6.xможет быть неожиданностью, чтоauto compaction modeработает не так как ожидается. В предыдущих версиях много неразберихи: в v3.2.x, например, параметр --auto-compaction-mode отсутствует, в v3.3/4/5.x разные дефолты для cli-флага --auto-compaction-mode и в функции NewConfig() при запуске через--config-file. С версии v3.6.x это все устранилиМожно еще для синтетики прогнать fio:
Это близкое к тому как пишется WAL: etcd преаллоцирует 64MiB файл, последовательно в него пишет, после заполнения текущего открывает новый файл и так далее.
Тут есть нюанс: fio не умеет преаллоцировать файлы во время работы и после заполнения удалять их, поэтому все файлы нужно создать заранее.
Задавайте число файлов (
nrfiles) достаточно большим, чтобы тест не завершился за считанные секунды на SSD/NVMe.Длительность теста по времени (
runtime=) нет смысла проводить, потому как после заполнения всех преаллоцированных файлов fio начнет писать в уже заполненные файлы, что провоцирует паттерн readModifyWrite и iops падают на порядок. У меня было так 250k -> 20k.Block size (bs) не кратен 4k, чтобы было честно, так как etcd при записи в wal никакие границы блока не выравнивает и запись может быть любого размера (разве что ограничена --max-request-bytes).
Можно добавить fio сценарий для bbolt (он, кстати, совершенно другой), но основной паттерн для etcd, все таки WAL
5 миллисекунд на fdatasync?
Такое ощущение, что это HDD, а не NVMe.
20k iops на fdatasync для NVMe хорошо, 2k iops - ну наверное что очень древнее, 200 iops на современном NVMe - не верю.
Правда, не очень реалистично. Может у вас очень сложный datapath, где много слоев виртуализации до диска, не выровненные блоки и все все таком духе.
Можно модель диска?
Полный профиль fio и его вывод?
И какой результат на bare metal покажет команда?
Спасибо.
Вот это интересно.
Нашел схематичное объяснение как устроено распечатывание в блоге вашего продукта.
Только непонятно как это реализовано технически. Полагаю, на сервере, рядом с Stronghold или в самом Stronghold, например в плагине, есть код, который дискаверит узлы кластера и если они в unseal режиме распечатывает их (`vault operator unseal`). И еще не совсем понятно как происходит discovery узлов. Я догадываюсь как это сделать для raft storage backend (просто `vault operator raft list-peers`), а вот для других storage, наверное, придется дополнительно узлы где-то публиковать
fix comment
Спасибо за статью.
Умно, познавательно.
Подскажите как у вас организованы процессы доставки unseal ключей ответственным сотрудникам, ротация ключей и распечатка хранилища?
1) Я так понимаю при разворачивании нового vault есть процесс, который каждую из 5-ти частей Шамира шифрует соответствующим открытым ключом "ответственного" и отправляет результат, условно, на почту "ответственного". Так?
2) Чтобы провести ротацию unseal ключей или распечатать хранилище, по прежнему, должна собраться группа из "ответственных" людей?
3) Используете ли вы Auto unseal или что-то подобное?
Цитата из статьи:
Про производительность ни слова
Можно уточнить в чем экономия времени запрограммировать функционал в статье на RouterOS против OpenWRT?
Я хочу чтобы xbox шел через Турцию. Зачем искать mac xbox, прописывать какие-то неявные правила, когда я могу подключить xbox к "Турецкой" точке доступа? Кажется, проще некуда
Интересно получается, RB4011iGS+5HacQ2HnD-IN в 10 раз быстрее mAP lite на шифровании, в 10 раз производительнее cpu, в 10 раз дороже и ~ в 30 раз тяжелее ;)
Вы плохо читали. 100 профилей это просто загруженный конфиг. Из них только несколько VPN активны. И они не грузят проц. Утилизация проца в 100% когда либо идет реальная работа, т.е. шифруется трафик на 30Mbps, либо когда идет активная запись/чтение конфигурации RouterOS. Именно последняя ситуация является аномалией
Что-то подобное попадалось в интернетах. Правда позже покупки mAP lite.
Есть даже очень похожие девайсы по размерам и железу. Например https://www.gl-inet.com/products/gl-ar300m/
Минусы для меня следующие:
долгое время доставки (из штатов или европы)
цена - скорее всего обошелся бы раза в 2-3 дороже, а если устройство классом выше и современнее - в 5+ раз
и самое главное, я не знаю его возможностей, и как следствие сможет ли оно без прошивки на dd-wrt/openwrt смочь поднять несколько AP с маршрутами через WG? И можно ли их вообще прошить на dd-wrt/openwrt? И будет ли оно потом стабильно работать на этих прошивка?
Да, данная статья больше про менеджмент, чем про "обойти любые блокировки"