Комментарии 31
Лучшая по полезности статья, прочитанная мною за последнее время. Спасибо, Сергей!
Искренне рад, что статья принесла пользу!
Скол ко человеко-часов потратили? Судя по описанию - я так понял, что стартанули в конце 2021, а уже март 2022, то есть, в общем-то, не так много времени прошло? И о каких масштабах инфры идёт речь? Сотни, тысячи виртуалок? Переезд уже закончился или все ещё в процессе?
Ещё такой вопрос - почему ансибл? Как я понял, Вы доконфигурируете сервера после создания их терраформом? Почему не пошли от обратного - создание своих шаблонов под каждый тип приложений и уже развёртывание готовых к эксплуатации ВМ?
В остальном статья очень подробная и полезная. Большая спасибо. Есть что почерпнуть для своей работы.
Скол ко человеко-часов потратили? Судя по описанию - я так понял, что стартанули в конце 2021, а уже март 2022, то есть, в общем-то, не так много времени прошло? И о каких масштабах инфры идёт речь? Сотни, тысячи виртуалок?
Проект стартовал в декабре 2020, примерно до февраля шла работа по выбору между on-prem и IaaS, затем до августа - выбор конкретного облачного провайдера, это всё в одного техлида параллельно с другими проектами, плюс ~неделя со стороны пары QA и разработчика для тестирования копии продов. С сентября началась подготовка миграции и сама миграция. Подготовка - проработка концепций, сетевая часть, написание модулей и common-ролей, пайплайны и т.п. - примерно 3 месяца работы одного техлида суммарно. Сама миграция - порядка 5-6 месяцев командой из 3-4 человек (параллельно с другими задачами). Масштаб - чуть менее сотни виртуалок.
Переезд уже закончился или все ещё в процессе?
Почти закончился, осталось примерно 7%.
Ещё такой вопрос - почему ансибл? Как я понял, Вы доконфигурируете сервера после создания их терраформом? Почему не пошли от обратного - создание своих шаблонов под каждый тип приложений и уже развёртывание готовых к эксплуатации ВМ?
Я согласен, что это стратегически более правильный подход и это будет следующим этапом развития нашей инфры. Но, во-первых, для этого нужно освоить Packer, обучить команду и вписать его в общий воркфлоу и пайплайны, а у нас был жёсткий дедлайн. Во-вторых, многие наши виртуалки в любом случае, после создания даже из шаблона, нужно доводить до ума - хотя бы вводить в домен Windows-инстансы. А в-третьих, Ansible очень удобен для сложного конфигурирования и даже в Packer мы бы именно его использовали, как провижионер, и текущие плейбуки и роли очень пригодятся.
В остальном статья очень подробная и полезная. Большая спасибо. Есть что почерпнуть для своей работы.
Спасибо на добром слове! Рад, что статья понравилась.
По совокупности критериев мы остановили выбор на VKCS
Фатальная ошибка. Почему? Потому что "single provider". У них проблема - у вас проблема, и быстро её не решить.
Как надо было? Слышали поговорку "cattle, not pets"? Её обычно говорят про виртуалки, но! На самом деле она в первую очередь относится к поставщикам.
Стандартизированные API, минимальный объём отличий, менять провайдеров как перчатки. Упал VKCS? Нагрузка плавно переползла на другого поставщика. Кто-то выкатил условия на 10% дешевле? 30% нагрузки уползло к нему. Без даунтаймов.
Т.е. выбор поставщиков должен начинаться не с заверений в изумрудном SLA, бриллиантовых инженеров саппорта и лазурных персональных менеджеров, а с простейшего тест-драйва API. Можно фигакнуть ансиблом/терраформом сетап или нет?
Если нет, то это ни чем не лучше, чем on-prem, кроме того, что теперь ещё меньше ручек для контроля происходящего.
UPD, если ещё не убедило. Сколько поставщиков электричества должно быть у Tier IV дата-центра? Один, с самым лучшим SLA на рынке? Или всё-таки больше?
Потому что "single provider". У них проблема - у вас проблема, и быстро её не ререшить.
В наших условиях, разделив тот же объем закупки ресурсов на разных провайдеров, мы бы получили существенно худшие условия контракта от каждого. Бизнес ежедневно платил бы больше ради весьма невысокой вероятности того, что все зоны доступности VKCS упадут.
Можно фигакнуть ансиблом/терраформом сетап или нет?
Конечно, почти все публичные облака имеют api и с ними можно работать яерез Терраформ. Но у всех своя специфика - сеть, работа с образами, ключами, свой Терраформ-провайдер со своими конструкциями. Можно писать под два облака, но у нас слишком маленькая для этого команда. Риски и неудобства работы только с одним облаком, конечно, есть, я согласен, но на данном этапе нашего развития и размера они не перевешивают выгоды того же решения.
Если нет, то это ни чем не лучше, чем on-prem, кроме того, что теперь ещё меньше ручек для контроля происходящего.
Меньше ручек - плохо тем, что меньше возможности их крутить. Но меньше ручек - это ещё и хорошо тем, что меньше необходимости их крутить. Решение зависит от условий задачи.
Короче, вы взяли свой on-prem, и сделали из него aas. Чужой aas. Тот же вендор-лок, но который могут рубануть просто в результате конфликта собственников или ещё какой-то внешней фигни.
Вы бы не получили существенно худшие условия в aas'ах порезав объём в 2-3 раза. А реализовав универсальный слой в IaC вы бы смогли в любой момент выворачивать руки сейлзам любого провайдера угрозой съехать.
После того, как вы на оный VKCS переехали с потрошками и завязались на их особенности реализации, теперь они вам могут выкручивать что угодно.
(На практике это означает, что они просто не будут снижать цены или будут индексировать их по курсу, и у вас не будет аргументов возразить).
Но меньше ручек - это ещё и хорошо тем, что меньше необходимости их крутить
это не так. Это скорее необходимость обходить ограничения, связанные с невозможностью их крутить. Коллеги, которые заехали в яндекс, репортили, что там не хватает коннекшенов на один узел. Ну, вот так и сделано. Ответ ТП - заказывайте больше узлов (а, следовательно, и платите нам побольше денег)
Бизнес ежедневно платил бы больше ради весьма невысокой вероятности того, что все зоны доступности VKCS упадут.
т.е. VKCS (амазон, гугл и пр.) никогда целиком не валялся? Валялись и еще как. Но я соглашусь с тем, что реализация кросс-провайдера достаточно дорогая. Если Вы осознанно приняли эти риски - молодцы.
Это скорее необходимость обходить ограничения, связанные с невозможностью их крутить
Я про то, что теперь мы не можем менять коэффициент переподписки, выбирать модель процессора, рейд-контроллера, конфигурацию массива, создавать вланы, выбирать сетевое железо и пр., Но, с другой стороны, мы теперь и не обязаны этого делать, и это на практике пока что перевешивает недостатки.
Подождите, ну два десятка физических серверов и сотня виртуалок - это работа для одного админа. Ну двух-трёх, если ещё надо сопровождать продукты какие-то внутри этих виртуалок и обеспечивать подмены на время отпусков.
Зачем городить вот эту историю с терраформами и прочим всем? Это нужно для случаев в тысячи хостов. А Вашу инфраструктуру один нормальный админ за полгода причешет, замониторит, настроит бэкапы и потом бОльшую часть времени будет сидеть, пить кофе и читать хабр, как и положено админу.
Подождите, ну два десятка физических серверов и сотня виртуалок - это работа для одного админа. Ну двух-трёх, если ещё надо сопровождать продукты какие-то внутри этих виртуалок и обеспечивать подмены на время отпусков.
Один админ совершенно точно не справляется с сотней виртуалок при потребности в относительно частых изменениях. И уж тем более, если это on-prem на солянке из оборудования без полноценных vSphere, кластеров, СХД и пр.
Зачем городить вот эту историю с терраформами и прочим всем? Это нужно для случаев в тысячи хостов. А Вашу инфраструктуру один нормальный админ за полгода причешет, замониторит, настроит бэкапы и потом бОльшую часть времени будет сидеть, пить кофе и читать хабр, как и положено админу.
Нет, это так не работает :) Один, а ещё хуже, несколько админов, которые вручную всё конфигурируют - это путь в хаос и безумие. Невозможно постоянно обеспечивать высокое качество и стандартизацию конфигураций при работе вручную, даже если ты работаешь один. А в команде - тем более.
Даже в наших масштабах мы постоянно, ежедневно, непрерывно спотыкались на необходимость понять, чем и как думал человек, который до тебя настраивал эту ВМ и какого чёрта он напихал скрипты подключения одной NFS-шары в 5 (пять, Карл) разных мест Windows-инстанса. Я не могу здесь приводить другие реальные примеры, касающиеся, например, прода, но это действительно была ежедневная огромная боль.
И я знаю, как бы это стало выглядить, когда мы бы выросли в несколько раз. Я работал раньше во внутреннем it-аутсорсе большого холдинга и знаю, как выглядят несколько сотен серверов-снежинок. Это выглядит, как ад - всё постоянно горит, а десяток админов только тушат пожары и никак не могут потушить. Такого будущего не желаю ни одной компании, и тем более, той, в которой я работаю :)
Я работал раньше во внутреннем it-аутсорсе большого холдинга и знаю, как выглядят несколько сотен серверов-снежинок. Это выглядит, как ад - всё постоянно горит, а десяток админов только тушат пожары и никак не могут потушить.
Пять+ сотен серверов-снежинок. И не десяток, а шесть админов, которые подменяли техсуппортов, если последних не хватало по причине отпуска или болезни.
Невозможно потушить пожар, если ты работаешь в кратере действующего вулкана. ^_^
Ну, Вы решили свою проблему и поделились интересным опытом, за что Вам большое спасибо.
если это on-prem на солянке из оборудования без полноценных vSphere, кластеров, СХД и пр
Вот в том-то и дело, что описанное Вами состояние инфраструктуры выглядит как манифест чьей-то некомпетентности. Видимо, руководство когда-то решило сэкономить на руководителе IT. Про 5 скриптов NFS-шары - очень хорошо ложится в этот же пазл.
Именно потому что нормальный админ даже этот бардак бы причесал и привёл к общему знаменателю. При этом совсем необязательно тратить мегабаксы на VMware и стораджи от EMC, в бюджетных условиях вполне нормально можно собирать кластеры на бесплатном Proxmox и СХД на самосборных серверах имени Supermicro.
Я работал раньше во внутреннем it-аутсорсе большого холдинга и знаю, как выглядят несколько сотен серверов-снежинок
Подозреваю, что именно в этом дело. Аутсорс, даже внутренний - он всё равно работает по тушению пожаров, тогда как для админа в штате этот процесс, по-хорошему, занимает не больше 5% рабочего времени; ещё где-то около 20% - текущие задачи (создать виртуалку, дать доступ и т. п.), а всё остальное рабочее время админа должно уходить как раз на превентивные меры - мониторинги, автоматизации, документирование, написание скриптов. Тогда количество пожаров очень быстро сойдёт на нет.
За 25 лет админства, руководства админами, IT-аудитов и прочего я тоже много разного насмотрелся. И да, филиал ада легко можно устроить не то, что с парой десятков, а и с тремя-четырьмя серверами. Но если процессы выстроены грамотно - то один человек легко может управляться с весьма большими инфраструктурами без всяких пожаров.
Ну, я думаю, мы с вами всё равно каждый при своём мнении останемся :) Исходя из моего опыта и того, что я знаю о чужом опыте - это так не работает и не может работать. Но, видимо, в каких-то условиях возможно.
Да я не спорю. Ваше мнение и опыт весьма интересны, хотя бы уже тем, что они отвечают нынешнему состоянию рынка и такие вещи надо уметь. Большое спасибо за пост.
видимо, в каких-то условиях возможно
Из моего опыта (просто в копилку):
Небольшой хостинг с доп. услугами: пара десятков физических серверов в двух датацентрах, около 400 виртуалок, из них около 30 обеспечивающих собственную инфраструктуру (всякая там IP-телефония, роутеры), около 300 VPN-линков, OSPF и BGP в комплекте и прочее - спокойно обслуживается одним человеком (но без поддержки юзеров).
Инфраструктура среднего банка - 70 физических нод, около 200 виртуалок (далеко не всё было виртуализовано), 100+ филиалов со всякими VPN и телефонией, AD+Exchange на 2000 юзеров - обслуживалось командой в 8 админов (но это уже с делением на сетевиков, виндузятников, юниксоидов, Oracle DBA, MSSQL DBA). Более того, эта инфраструктура бесшовно смигрировала как раз из состояния "целый сугроб снежинок".
Ну то есть оно не требует сверхчеловеков каких-то.
Основная причина, в которой iac нужен, вовсе не экономия сил админов на саппорте, а повышение качества. Чем больше инфры проходит через ci/cd, тем предсказуемее продакшен и тем быстрее и смелее можно что-то менять.
У iac тоже должен быть стейджинг, а его не может быть без автоматизации провиза.
А для какого класса/размера инфраструктур это начинает иметь значение?
Ну, условно, есть инфраструктура средних размеров банка. Сервера виндовой инфраструктуры (AD, Exchange); боевые и тестовые сервера БД, всякие там сервера приложений, телефонии, чёрт знает чего ещё. Скажем, полтыщи разноплановых виртуалок.
Новые - разворачиваются нечасто, только при внедрениях и развитиях новых продуктов и там чаще всего потребные мощности заранее известны. И даже если под некий продукт разворачивается десяток виртуалок в тестовый контур - то потом развернуть аналогичные в боевой вопрос максимум пары часов.
Вот серьёзно, какой класс сервиса может потребовать стэйджинг инфраструктуры, если её планировать заранее и с умом?
Вот серьёзно, какой класс сервиса может потребовать стэйджинг инфраструктуры, если её планировать заранее и с умом?
любой. На почтовики тоже накатываете обновления не глядя? Один раз я чуть актив дайректори не положил неудачным обновлением.
Возможно, если б у ребят был стейджинг, то не было отказов вроде https://blog.cloudflare.com/october-2021-facebook-outage/ https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
Shit happens, но наличие песочницы позволяет снизить требования к персоналу и снизить вероятность ошибки. С другой стороны, да, можно на каждый чих писать план отката и нанимать суперпрофи, которые умеют чуть ли не в ручном режиме производить закат солнца. Но в реальности - это всегда баланс. Да, и денег никто вам не вернет в случае сбоя...
Вендозная инфраструктура стейджингу поддаётся с большим трудом. Я тоже знаю случаи, когда обновлениями клали AD DNS, клали Exchange. В лично моём портфеле достижений такого нет, но у знакомых бывало.
При этом даже иметь рядом копию AD и Exchange особо не помогает, потому что если что-то где-то и спотыкается - то на какой-то неявной и нереплицируемой вещи типа особо хитрой комбинации настроек отдельного ящика.
В общем, откатить всю AD назад при неудачном апдейте раз в несколько лет обычно дешевле, чем постоянные расходы на поддержание синхронизации.
да, можно на каждый чих писать план отката и нанимать суперпрофи, которые умеют чуть ли не в ручном режиме производить закат солнца
Это сейчас считается суперпрофи? Я понял, пойду обратно в заморозку ещё лет на двести :)
Тогда да, проще тратить в три раза больше времени на стейджинги и прочее.
Я обычно делаю стейджинг на второй итерации. Первая - exploratory, пощупать как оно там "вообще". Дальше идёт стейджинг (ephimerial, когда он создаётся/удаляется на каждый прогон), когда на стейджинге работает, то продакшнен становится "как стейджинг, только не ephimerial".
Потом там начинается сегрегация "этот стейджинг люди трогают и его не надо ребилдить, а этот поднимается на каждый коммит в гит, а этот используют workflow для релиза приложений" и т.д.
Я совершенно не понимаю как это можно всё сделать с виндами (кто может развернуть ephimerial active directory, exchange и проверить, что почта ходит, а секретерша не может забанить гендира?), но в мире серверного софта такой подход оказывается
а) примерно в три раза медленее от mvp до продакшена (по сравнению с "настроили руками")
б) оказывается единственным, который позволяет уверенно коммитить изменения и применять их роботом по merge request'у.
в) кратно экономит время во время новых изменений.
Ах, да, польза от всех этих стейджингов оказывается в несколько раз выше, если после накатывания конфигурации её тестировать.
а) примерно в три раза медленее от mvp до продакшена (по сравнению с "настроили руками")
ну, это приемлемо. Главное, что если делать руками - то потом опять делаешь руками, но старое сжигаешь ))) потому что разобраться в старом попросту, ну, нет никакой возможности. Аудит провести? Анрил. А если хочется, чтобы был порядок - приходится так или иначе приходить к IaC, а там все эти чудесные процессы со стейджингами, проверками и всем прочим.
всегда удивляюсь, когда сравниают on prem с облаком без учёта переподписки...
А уж диагностировать, в опеделенные моменты прошлого, производительность paas вообще нереально. Вот и думай, почему висел тот или иной важный сервис.
Ну, мы сравнивали с учётом переподписки. Это было отдельной строкой в рабочей таблице и предполагаемые к закупке on-prem кластера считали именно с переподпиской, сравнивая с чистыми vCPU в облаке. Плюс VKCS обещает 100% времени HT-ядра. Не знаю, насколько это правда, но по тестам производительности всё было достаточно стабильно и нас в итоге устроило.
чистые vcpu в облаке, так не бывает? то что работает сейчас именно так, не гарантирует что не изменится завтра или через месяц. А средств объективного контроля - 0, разве что стилы в top. И это не касается частного случая с VKCS, это общая облачная практика. Плюс DRM может менять ситуацию.
Если вам обещают HT в multi-tenant cloud, то вы полностью в небезопасности. SMT (HT) не возможно защитить от side channel spectre, так что если у ваших данных хоть какая-то ценность, то вы вполне можете получить копию ваших данных у посторонних людей.
Конечно, нейминг!
Hу кто его не знает? (c) Вроде знают все, но почему-то упорно продолжают использовать как бог на душу положит, вплоть до "Коровьев против фамилии "Панаев" написал "Скабичевский", а Бегемот против Скабичевского написал "Панаев"" (с)
Опыт переезда в облако VKCS (IaC, IaC и в продакшн)