Как стать автором
Обновить
35
Карма
0
Рейтинг
Ilya Andreev @IlyaArens

Systems Engineer

  • Подписчики 2
  • Подписки

Опыт миграции инфраструктуры клиента из AWS в Яндекс.Облако

Отвечая на вопрос с Deckhouse - и да, и нет :)

Deckhouse поддерживает возможность установки на разную инфраструктуру; ЯО — один из вариантов такой инфраструктуры. Инсталлятору передается конфиг с настройки по облаку, а дальше уже идёт управление ресурсами в рамках Kubernetes. Сайт проекта (с документацией) совсем скоро станет публичным (анонс будет у нас в блоге). Я отправил тебе ключ c инструкцией -- как попасть в документацию. В ней будет более подробно рассказано про Deckhouse и там ты сможешь узнать, как поставить себе для тестирования.

Восстановление БД с помощью функционала ЯО тестировали, но пока что недостаточно данных, чтобы дать точную оценку. В целом, проблем не наблюдаем. Если говорить о размерах, то в каждом проекте по разному, в основном мы говорим о БД с размером больше 250Гб и до нескольких терабайт.

В планах внедрить pgBouncer в рамках данного проекта, но пока что до реализации не дошли из-за некоторых ограничений со стороны приложения.

Говоря о мотивации переезда — экономия была одной из основных целей, но не единственной. В целом, о таких целях я говорил в начале статьи — для этого проекта это тоже было актуально.

Опыт миграции инфраструктуры клиента из AWS в Яндекс.Облако

Привет. Касательно Deckhouse — тут сравнение некорректное, так как в рамках данной цены рассматривается не стоимость инфраструктуры в AWS, а ее поддержка со стороны Фланта: мы берем на себя ответственность за работоспособность кластера, клиент получает полный доступ к модулям Deckhouse из EE версии так далее. Это в целом отдельный вопрос для диалога и я не хотел бы на нем останавливаться сейчас.

Стоимость миграции в данном случае не оценивали, так как клиент использовал программу https://cloud.yandex.ru/cloud-boost. Поэтому для клиента стоимость переезда из AWS в ЯО была если не бесплатной, то намного более дешевой по сравнению с вариантом без гранта со стороны ЯО с необходимостью оплачивать обе инфраструктуры.

И я видел несколько вопросов по поводу ре-инвентаризации и удалении лишних хостов/сервисов — хотел бы и на них ответить в этом комментарии. Перед моим разбором отмечу, что у меня нет на руках детального сравнения инвойсов от AWS и ЯО, поэтому я сейчас в большей степени рассказываю свои воспоминания и предположения:

  1. Мы не могли использовать некоторые Managed решения от самого ЯО (в статье я рассказывал про Redis), в процессе переезда они были либо заменены на self-managed решения, что несомненно повлияло на стоимость в меньшую сторону — использовались ресурсы текущего кластера.

  2. В AWS использовался Amazon CloudFront, после переезда мы начали использовать другое аналогичное решение — расходы тоже сократились.

  3. Одна из задач переезда — не потерять в производительности приложения. Поэтому мы мигрировали 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 рублей.

Аварии как опыт #3. Как мы спасали свой мониторинг во время аварии в OVH

Привет. Все немного сложнее.

У нас есть своя собственная система интеграции с другими системами мониторинга — Madison. Okmeter был одним из источников данных, которые поступали в данную систему, а дальше обрабатывались на нашей стороне (имею ввиду именно процесс эскалации, severity и так далее).

Когда Okmeter перестал работать, мы, естественно, перестали получать от него данные. Времянка в виде баш скриптов повторяла логику тех алертов, которые были настроены на серверах, отправляя данные в Madison. Мы еще для поддержки «обратной совместимости» добавляли нужные лейблы и другую метадату в алерт, чтобы Madison думал, что алерт приходит из Okmeter. Это позволило не тратить дополнительное время на редактирование процесса эскалации со стороны дежурных инженеров.

Из жизни с Kubernetes: Как мы выносили СУБД (и не только) из review-окружений в статическое

Да, верно.

Нам нужно, чтобы на момент повторного деплоя ревью с нуля (как пример можно взять ситуацию, когда мы перед данным деплоем полностью остановили ревью окружение) у нас гарантированно не было объектов (базы данных, vhost и так далее) из предыдущего деплоя. Именно это и является главной проблемой при реализации — если БД уже существует, то в момент деплоя мы получим ошибку/некорректно созданное окружение. В «обычном» варианте ревью это не проблема — объекты релиза находятся в одном namespace, достаточно полностью удалить namespace. В нашем варианте сложнее, так как еще есть база данных в PostgreSQL и MongoDB + vhost в RabbitMQ на отдельном хосте. Поэтому при повторном деплое должно гарантированно удаляться/создаваться по необходимости.

Tips & tricks в работе с Ceph в нагруженных проектах

Привет! В первом кейсе мы полностью выводим сервер из обслуживания, поэтому монитор тоже удаляется. Конечно, для удаления OSD не нужно удалять монитор на самой ноде.

Касательно ситуации с количеством мониторов: мы всегда стараемся добавлять их в большем количестве, устанавливая на системные ноды для большей отказоустойчивости. В этой же статье все было сделано в рамках проекта-песочницы — он не боевой, поэтому нет необходимости в добавлении дополнительных мониторов.

Kubernetes tips & tricks: особенности выполнения graceful shutdown в NGINX и PHP-FPM

Когда в последний раз смотрел Dockerfile у NGINX видел, что там также используется SIGQUIT в качестве сигнала, насколько помню, был даже issue на эту тему. Нюанс в том, что на стопсигнале проблема не заканчивается и как раз в статье представлены другие проблемы, которые также нужно решить

Как с tcpserver и netcat открыть туннель в Kubernetes pod или контейнер

В этом и «фишка» данного рецепта. Он использует традиционные утилиты и предлагает довольно универсальное решение, которое хорошо ложится на k8s, но легко распространяется и на другие контейнеры, и не только на них, конечно.

Как с tcpserver и netcat открыть туннель в Kubernetes pod или контейнер

С kubectl port-forward есть проблема: он не поддерживает forward-proxy (с компьютера на под). Также в разделе «Другие идеи» есть другие примеры использования tcpserver в рамках k8s

Как с tcpserver и netcat открыть туннель в Kubernetes pod или контейнер

Да, а ещё бывают целые приложения для решения той же задачи. В какой-то мере это костыль, но поскольку он собран по частям из разных утилит, позволяет делать и другие «обходные» вещи (вроде тех, что описаны в «других идеях»).

Информация

В рейтинге
Не участвует
Работает в
Дата рождения
Зарегистрирован
Активность