Комментарии 23
очень интересно
Хорошая, годная статья. Спасибо подрочил прочитал с интересом, хоть и не всё понял.
Что-то я глупенький, то что такую standalone точку отказа разобрали на микросервисы это конечно хорошо, но во первых, почему изначально отошли от unixway 1 приложение 1 сервис, а устроили из линукс виртуалки вендопк начинающего форнтэндера, во вторых kvm прекрасно умеет migrate доже в моем локалхосте на 7 гипервизоров и 60 витруалок, да и нормальный raid задолго до смерти диска весь заббикс загадит, подменный фонд дисков это как по мне мастхев, а дальше рейд контроллер сам все сделает.
Помимо базовой эксплуатации, наличие ЗИП, возможность миграции ВМ как минимум между этими же хостами виртуализации на момент восстановления сервера сбойного, добавлю вопрос, а как же бэкап? Как минимум снэпшот\клон ВМ отложенный на сервер\схд\облачное хранилище после каждого изменения, отдельно бэкап БД. Переход на микросервисы никаким образом не решает проблем эксплуатации инфраструктуры, перекладывает их на мозолистые руки компетентных специалистов только по сути.
Дело не напрямую в переходе на микросервисы, а в том, что мы перешли к парадигме IaaS - освободили себя от необходимости обслуживать железо, реализовывать его мониторинги итд.
А микросервисы позволяют полагаться не на бэкапы, а на то, что в случае чего мы выкатываем последнюю стабильную версию контейнера
Так ведь об этом и история - на тот момент все скромные силы и помыслы нашей команды в 4 человека были направлены на сеть - Датацентры, магистраль, внешняя связность, Cloud InterConnect, всё остальное было по почти остаточному принципу - чтобы нашу рутину сгладить и оптимизировать.
Не было ни мониторингов, ни снапшотов этих машин, ни плейбуков. Притом, что, я повторюсь, мы понимали, что это яма, что мы сами себе копаем.
Спасибо за познавательную статью, узнал парочку новых технологий, которые мне, возможно, неплохо было бы рассмотреть в условиях лабы
В облаке может умереть виртуалка и у нее нет бэкапа? Это антиреклама Яндекса такая изощрённая?
Что ж там за список зависимостей для системы мониторинга серверов, который собирается 30 минут? o_O
Для референса, у меня на ноутбуке полноценные сборки Debian + Python + Postgresql с 20+ сторонними apt-пакетами и 20+ pip-пакетами билдятся с нуля минуты за 4 максимум с учётом времени загрузки бинарников по сети
Кажется, мы разный смысл вкладываем в слова "сборка" и "полноценный" :)
Ну я без сарказма и предъявы, мне правда интересно что (и зачем) можно напихать в условный compose, чтобы он полчаса билдился.
Просто на схеме сервиса не видно ничего такого, что очевидно требовало бы таких объёмов, поэтому и зацепился глаз :)
Если не секрет, то хотя бы в общих чертах поделитесь, пожалуйста
Спасибо Марат. Мало стало на Хабре подобных текстов. Какой стиль !
И дальше началась первая фаза «исторически сложилось».
Присказка - великолепна. Да и сама сказка хороша.
Очень много англоязычных терминов транслитерированно в кириллицу, от этого иногда сложновато читать. В остальном интересно, спасибо)
Спасибо за статью! Звучит, как: я все сделал правильно и не о чем не жалею, ну, почти. :)
Полезно и познавательно!
Вопрос один возник - почему вы сразу не делали в Яндекс.Облаке, если работаете в Яндексе? К чему железо в 202x году (если вы работает в Яндексе опять-же)?
Очень крутые подписи к иллюстрациям)))
лет 15 назад выбирал систему хранения и выбор встал между EMC и NetApp. У EMC подход был следующий - 2 головы кластера работают, а 3-я стоит под "парами" и готова заменить отлетевшую ноду. У NetApp обе ноды активные и вслучае отключения одной (на профилактику например) вторая тащит все запросы. И вот когда одна голова NetApp сдохла, а вторая пыталась работать за двоих, я понял, что три значительно лучше двух -) и запас точно лишним не будет...
Не очень понял зачем делать снимки OS, если вы уже пользуетесь контейнерами? В свое время как раз docker смог заменить эту тяжелую технологию. В этом был бы еще смысл если у вас был auto scaling group, но я так понял у вас нет. И вам вроде как и не надо, можно в ручную создать новую vm и пролить на нее все необходимое.
Не сочтите за вброс, я рад что вы разбираетесь в новых технологиях и успешно их внедряете, даря людям стабильность и простоту. Но с точки наблюдателя кажется что вы дорвались да разных модных игрушек :-)
Как пример ваше желание запрыгнуть на kubernetes. Он не рассчитан на пару тройку машин. Выгода от него есть когда у вас есть четкое разделение на отдел поддержки этого kubernetes и много отделов разработки.
Сказ о том, как два сервера изменили судьбу сетевой команды