Deckhouse поддерживает возможность установки на разную инфраструктуру; ЯО — один из вариантов такой инфраструктуры. Инсталлятору передается конфиг с настройки по облаку, а дальше уже идёт управление ресурсами в рамках Kubernetes. Сайт проекта (с документацией) совсем скоро станет публичным (анонс будет у нас в блоге). Я отправил тебе ключ c инструкцией -- как попасть в документацию. В ней будет более подробно рассказано про Deckhouse и там ты сможешь узнать, как поставить себе для тестирования.
Восстановление БД с помощью функционала ЯО тестировали, но пока что недостаточно данных, чтобы дать точную оценку. В целом, проблем не наблюдаем. Если говорить о размерах, то в каждом проекте по разному, в основном мы говорим о БД с размером больше 250Гб и до нескольких терабайт.
В планах внедрить pgBouncer в рамках данного проекта, но пока что до реализации не дошли из-за некоторых ограничений со стороны приложения.
Говоря о мотивации переезда — экономия была одной из основных целей, но не единственной. В целом, о таких целях я говорил в начале статьи — для этого проекта это тоже было актуально.
Привет. Касательно Deckhouse — тут сравнение некорректное, так как в рамках данной цены рассматривается не стоимость инфраструктуры в AWS, а ее поддержка со стороны Фланта: мы берем на себя ответственность за работоспособность кластера, клиент получает полный доступ к модулям Deckhouse из EE версии так далее. Это в целом отдельный вопрос для диалога и я не хотел бы на нем останавливаться сейчас.
Стоимость миграции в данном случае не оценивали, так как клиент использовал программу https://cloud.yandex.ru/cloud-boost. Поэтому для клиента стоимость переезда из AWS в ЯО была если не бесплатной, то намного более дешевой по сравнению с вариантом без гранта со стороны ЯО с необходимостью оплачивать обе инфраструктуры.
И я видел несколько вопросов по поводу ре-инвентаризации и удалении лишних хостов/сервисов — хотел бы и на них ответить в этом комментарии. Перед моим разбором отмечу, что у меня нет на руках детального сравнения инвойсов от AWS и ЯО, поэтому я сейчас в большей степени рассказываю свои воспоминания и предположения:
Мы не могли использовать некоторые Managed решения от самого ЯО (в статье я рассказывал про Redis), в процессе переезда они были либо заменены на self-managed решения, что несомненно повлияло на стоимость в меньшую сторону — использовались ресурсы текущего кластера.
В AWS использовался Amazon CloudFront, после переезда мы начали использовать другое аналогичное решение — расходы тоже сократились.
Одна из задач переезда — не потерять в производительности приложения. Поэтому мы мигрировали 90% ресурсов в аналогичной конфигурации: ВИ, Managed решения, диски и так далее.
Клиент принципиально не рассматривал долгосрочную резервацию, не использовал Spot-инстансы. Поэтому для примера можем посчитать стоимость одинаковых виртуальных машин в Amazon и Яндексе с гарантированным CPU:
AWS:
Регион — Europe (Frankfurt)
Instance type — GP
Name — m5.xlarge (4 vCPU, 16 Gib RAM)
Pricing — $0.23/h.
Следовательно, в месяц получается ~$165.6 (12,159 рублей).
У нас есть своя собственная система интеграции с другими системами мониторинга — Madison. Okmeter был одним из источников данных, которые поступали в данную систему, а дальше обрабатывались на нашей стороне (имею ввиду именно процесс эскалации, severity и так далее).
Когда Okmeter перестал работать, мы, естественно, перестали получать от него данные. Времянка в виде баш скриптов повторяла логику тех алертов, которые были настроены на серверах, отправляя данные в Madison. Мы еще для поддержки «обратной совместимости» добавляли нужные лейблы и другую метадату в алерт, чтобы Madison думал, что алерт приходит из Okmeter. Это позволило не тратить дополнительное время на редактирование процесса эскалации со стороны дежурных инженеров.
Нам нужно, чтобы на момент повторного деплоя ревью с нуля (как пример можно взять ситуацию, когда мы перед данным деплоем полностью остановили ревью окружение) у нас гарантированно не было объектов (базы данных, vhost и так далее) из предыдущего деплоя. Именно это и является главной проблемой при реализации — если БД уже существует, то в момент деплоя мы получим ошибку/некорректно созданное окружение. В «обычном» варианте ревью это не проблема — объекты релиза находятся в одном namespace, достаточно полностью удалить namespace. В нашем варианте сложнее, так как еще есть база данных в PostgreSQL и MongoDB + vhost в RabbitMQ на отдельном хосте. Поэтому при повторном деплое должно гарантированно удаляться/создаваться по необходимости.
Привет! В первом кейсе мы полностью выводим сервер из обслуживания, поэтому монитор тоже удаляется. Конечно, для удаления OSD не нужно удалять монитор на самой ноде.
Касательно ситуации с количеством мониторов: мы всегда стараемся добавлять их в большем количестве, устанавливая на системные ноды для большей отказоустойчивости. В этой же статье все было сделано в рамках проекта-песочницы — он не боевой, поэтому нет необходимости в добавлении дополнительных мониторов.
Когда в последний раз смотрел Dockerfile у NGINX видел, что там также используется SIGQUIT в качестве сигнала, насколько помню, был даже issue на эту тему. Нюанс в том, что на стопсигнале проблема не заканчивается и как раз в статье представлены другие проблемы, которые также нужно решить
В этом и «фишка» данного рецепта. Он использует традиционные утилиты и предлагает довольно универсальное решение, которое хорошо ложится на k8s, но легко распространяется и на другие контейнеры, и не только на них, конечно.
С kubectl port-forward есть проблема: он не поддерживает forward-proxy (с компьютера на под). Также в разделе «Другие идеи» есть другие примеры использования tcpserver в рамках k8s
Да, а ещё бывают целые приложения для решения той же задачи. В какой-то мере это костыль, но поскольку он собран по частям из разных утилит, позволяет делать и другие «обходные» вещи (вроде тех, что описаны в «других идеях»).
Отвечая на вопрос с Deckhouse - и да, и нет :)
Deckhouse поддерживает возможность установки на разную инфраструктуру; ЯО — один из вариантов такой инфраструктуры. Инсталлятору передается конфиг с настройки по облаку, а дальше уже идёт управление ресурсами в рамках Kubernetes. Сайт проекта (с документацией) совсем скоро станет публичным (анонс будет у нас в блоге). Я отправил тебе ключ c инструкцией -- как попасть в документацию. В ней будет более подробно рассказано про Deckhouse и там ты сможешь узнать, как поставить себе для тестирования.
Восстановление БД с помощью функционала ЯО тестировали, но пока что недостаточно данных, чтобы дать точную оценку. В целом, проблем не наблюдаем. Если говорить о размерах, то в каждом проекте по разному, в основном мы говорим о БД с размером больше 250Гб и до нескольких терабайт.
В планах внедрить pgBouncer в рамках данного проекта, но пока что до реализации не дошли из-за некоторых ограничений со стороны приложения.
Говоря о мотивации переезда — экономия была одной из основных целей, но не единственной. В целом, о таких целях я говорил в начале статьи — для этого проекта это тоже было актуально.
Привет. Касательно Deckhouse — тут сравнение некорректное, так как в рамках данной цены рассматривается не стоимость инфраструктуры в AWS, а ее поддержка со стороны Фланта: мы берем на себя ответственность за работоспособность кластера, клиент получает полный доступ к модулям Deckhouse из EE версии так далее. Это в целом отдельный вопрос для диалога и я не хотел бы на нем останавливаться сейчас.
Стоимость миграции в данном случае не оценивали, так как клиент использовал программу https://cloud.yandex.ru/cloud-boost. Поэтому для клиента стоимость переезда из AWS в ЯО была если не бесплатной, то намного более дешевой по сравнению с вариантом без гранта со стороны ЯО с необходимостью оплачивать обе инфраструктуры.
И я видел несколько вопросов по поводу ре-инвентаризации и удалении лишних хостов/сервисов — хотел бы и на них ответить в этом комментарии. Перед моим разбором отмечу, что у меня нет на руках детального сравнения инвойсов от AWS и ЯО, поэтому я сейчас в большей степени рассказываю свои воспоминания и предположения:
Мы не могли использовать некоторые Managed решения от самого ЯО (в статье я рассказывал про Redis), в процессе переезда они были либо заменены на self-managed решения, что несомненно повлияло на стоимость в меньшую сторону — использовались ресурсы текущего кластера.
В AWS использовался Amazon CloudFront, после переезда мы начали использовать другое аналогичное решение — расходы тоже сократились.
Одна из задач переезда — не потерять в производительности приложения. Поэтому мы мигрировали 90% ресурсов в аналогичной конфигурации: ВИ, Managed решения, диски и так далее.
Клиент принципиально не рассматривал долгосрочную резервацию, не использовал Spot-инстансы. Поэтому для примера можем посчитать стоимость одинаковых виртуальных машин в Amazon и Яндексе с гарантированным CPU:
AWS:
Регион — Europe (Frankfurt)
Instance type — GP
Name — m5.xlarge (4 vCPU, 16 Gib RAM)
Pricing — $0.23/h.
Следовательно, в месяц получается ~$165.6 (12,159 рублей).
ЯО:
Гарантированная доля vCPU — 100%
vCPU — 4
RAM — 16 Gib
Публичный адрес — добавлен в стоимость
Исходящий трафик — 100Гб
Диск — SSD, включен в стоимость, 100Gb
В месяц выходит 5374,59 рублей.
У нас есть своя собственная система интеграции с другими системами мониторинга — Madison. Okmeter был одним из источников данных, которые поступали в данную систему, а дальше обрабатывались на нашей стороне (имею ввиду именно процесс эскалации, severity и так далее).
Когда Okmeter перестал работать, мы, естественно, перестали получать от него данные. Времянка в виде баш скриптов повторяла логику тех алертов, которые были настроены на серверах, отправляя данные в Madison. Мы еще для поддержки «обратной совместимости» добавляли нужные лейблы и другую метадату в алерт, чтобы Madison думал, что алерт приходит из Okmeter. Это позволило не тратить дополнительное время на редактирование процесса эскалации со стороны дежурных инженеров.
Нам нужно, чтобы на момент повторного деплоя ревью с нуля (как пример можно взять ситуацию, когда мы перед данным деплоем полностью остановили ревью окружение) у нас гарантированно не было объектов (базы данных, vhost и так далее) из предыдущего деплоя. Именно это и является главной проблемой при реализации — если БД уже существует, то в момент деплоя мы получим ошибку/некорректно созданное окружение. В «обычном» варианте ревью это не проблема — объекты релиза находятся в одном namespace, достаточно полностью удалить namespace. В нашем варианте сложнее, так как еще есть база данных в PostgreSQL и MongoDB + vhost в RabbitMQ на отдельном хосте. Поэтому при повторном деплое должно гарантированно удаляться/создаваться по необходимости.
Касательно ситуации с количеством мониторов: мы всегда стараемся добавлять их в большем количестве, устанавливая на системные ноды для большей отказоустойчивости. В этой же статье все было сделано в рамках проекта-песочницы — он не боевой, поэтому нет необходимости в добавлении дополнительных мониторов.
Когда в последний раз смотрел Dockerfile у NGINX видел, что там также используется SIGQUIT в качестве сигнала, насколько помню, был даже issue на эту тему. Нюанс в том, что на стопсигнале проблема не заканчивается и как раз в статье представлены другие проблемы, которые также нужно решить