Сразу предупрежу: это не те байки, где крысу разорвало в хлам. Просто разные мелкие истории «как люди делают», которые могут быть полезны администраторам. А могут и не быть. У нас много довольно крупных заказчиков, и у них, соответственно, компетентные админы. По опыту скажу: часто опытнее там, где есть строгие ограничения по бюджету.
У нас есть заказчик, который перепродаёт наше облако (как оказалось), есть управление выпеканием хлеба из облака, есть даже развёрнутый CTF для обучения хакеров. Но давайте начнём с переездов, в том числе тех, которые возникли из-за перекопанных экскаваторами дорог Москвы.
Самая высокая скорость передачи данных
Переезд из дата-центра в регионе в наше облако. Поскольку данных много, заказчик решил просто погрузить диски в обычный грузовик. Так как с грузовиком срослось не всё как надо, повёз он в результате в купе в поезде. Я прямо представляю: выкупил всё купе, заставил коробками с железом, заперся и параноил. В результате поставил наш рекорд по скорости передачи данных, как в старом анекдоте про фуру с болванками.
Массовые переезды
Когда Москву начали перекапывать, к нам пошла целая волна запросов на переезды. У кого-то кабель питания перерубили, и, пока его починят, люди заехали в облако (благо мы мигрируем быстро по гарантийке до договора). Присмотрелись, остались, потихоньку переносят приложения из своей серверной к нам по мере снятия железа с гарантии.
Самая интересная история была с одной маленькой серверной в Химках. Там финансовый директор не давал денег на модернизацию в принципе, они эксплуатировали железо циклами по 5-6 лет.
Логичное следствие такого подхода — в конце цикла всё дышало на ладан и были проблемы даже с дисками под боевую базу данных. Каждую неделю у них что-то вылетало, они рассматривали наименее критичные приложения и резали их. В итоге раскопки экскаваторами Химок дали админам редкий шанс всё же согласовать переезд в облако.
Похожая история была на реконструкции Калужского шоссе, но там компания переезжала сразу офисом под это дело и решили не делать серверный узел в новом месте, а перейти сразу к нам в дата-центр.
Срочный переезд
Если очень срочно нужно переехать, можно просто привезти физическую СХД. Истории такие есть, и не без курьёзов. Админ заказчика нам отдал железо, говорит: «Перезаливайте». «А что там?» — спрашиваем мы. «Всякие важные документы», — отвечает он. Начали таскать файлы — админ просто читает их названия и сползает по стене от смеха. На файлшаре с важными документами, которых, собственно, почти 9 Тб насобиралось, лежит сериал «Доктор Хаус». Естественно, потом почистили, что в спешке заказчик не удалил.
Забытая флешка
Развернули новую среду после переезда по плану. Поднимаем приложения с админами заказчика, и тут один хлопает себя по лбу. Говорит: «Флешку забыли». Ну забыли и забыли, потом привезёте. Делов-то. Оказывается, это не просто флешка, а ключ авторизации для бизнес-критичного приложения. Пришлось ночью метнуться в старый ЦОД, найти там в одном из серверов флешку, вырвать её и приехать к нам. Вставили в стандартный USB-хаб для облака, презентовали виртуальной машине как воткнутую в физический порт, всё поднялось.
Монитор в облаке
Звонок: «У вас есть монитор в облаке?» Мы: «ЧТО?» Заказчик: «Ну, я тут сервер везу, на нём удалённый доступ не настроен. Нужен монитор в облаке». Как потом оказалось, они купили новый компьютер десктопный (геймерского уровня примерно) и развернули сервисы на нём. По конфигурации действительно почти как сервер, набили они его памятью почти до предела. Вот его и привезли в облако, воткнули в вилан со своими виртуальными машинами и оставили. Когда он самортизируется — избавятся, а пока он просто неуклюже стоит в стойке и соревнуется с серверами в скорости. Монитор у нас был, поэтому настроили просто.
Автоскейлинг
У одного из крупных розничных заказчиков есть автоскейлинг, то есть потребление ресурсов по мере их необходимости. У них есть система мониторинга Zabbix, в ней настроены триггеры на загрузку каждого сервиса. Допустим, веб-ноды. Когда load average доходит до 0,8, Zabbix дёргает внешним скриптом Terraform и через API создаётся новая виртуальная машина. Она провиженится c помощью Ansible, стягиваются пакеты, ставится релиз. Балансировщик её получает и обновляет конфиг. На развёртывание уходит 5–10 минут. Когда суммарная нагрузка падает до определённого уровня, именно эта нода удаляется.
База данных у них сконфигурирована как master-master, поэтому тоже легко масштабируется. Производительность дисков у нас, кстати, вообще штатно скейлится одним запросом к API, они и ряд других клиентов активно пользуются.
В итоге вроде костыль, а красивый. Экономии примерно 25–30% при полной готовности к пикам.
Автоскейлинг для легаси
Государственная компания сделала другой скейлинг. У них архитектура с legacy (читай: кое-что работает на Фортране, кое-что — на полуоси, кое-где надо для совместимости запускать старый гипервизор в новом гипервизоре). Они не могут скейлиться по машинам горизонтально. Зато они отключают свои ВМ по ночам и перезапускают их с лёгким типом ресурсов. Днём — самые мощные машины облака, в 12 ночи они частично останавливаются и вместо них пускаются такие же, но куда более дешёвые, с медленным доступом к дискам и с другими квотами на ядра. Это шедулится на базе Exapark — нашей системы, которая висит извне. В 6-7 утра всё повторяется в обратном порядке. Этот функционал доступен всем заказчикам облака, но именно здесь админы прямо точно знали, что хотят и как. В результате получается неплохая экономия, так как оплата за облачные ресурсы почасовая.
Необычный тип доступа
У нас есть AWS-совместимое объектное хранилище. Как правило, его используют как обычно используют S3. Но один из заказчиков применяет напрямую через мобильное приложение без промежуточных перебросок. Приложение на iOS- и Android-приложения, через него работают тысячи мерчендайзеров. Они выгружают туда все фотографии и отчёты. Прямо с мобилок в объектное хранилище. Приложения, кстати, написаны с использованием AWS SDK, только эндпоинты другие.
Дёргаем рубильник через месяц
Есть компания, которая покупает готовые погибнуть бизнесы и продлевает им жизнь. Была одна французская компания, которая из-за санкций собралась уходить из России. Наши заказчики перекупили бизнес. Вся инфраструктура французов была в Москве в обычном офисе, плотно набитая серверная стойка. За месяц надо было перевести в облако всё сразу. Если не успеть — просто рубанут свет и всё. А там отгрузки со складов, машины ждут. И ещё некоторые вещи нельзя было проверить, пока старую инфраструктуру не выключишь полностью. Естественно, первого числа оставаться без отгрузок не хотелось, поэтому мы договорились с админами, что за воскресенье до конца месяца они гасят офисный серверный узел, мы смотрим, как разворачивается всё новое. Поднялось. Ещё сложность была в том, что головная компания не давала доступ к нативным средствам переноса базы данных, тоже помучились.
Уходя, гасите ВМ
Один наш заказчик – агрегатор – почти целиком почти состоит из разработчиков. Они очень быстрые и очень прошаренные. К нам в облако заехали за тестовыми средами в основном. Раньше у них были проблемы с тем, что много разных команд разработки приходили к админу и дёргали: «Дайте ресурсы». Было непонятно, сколько чего стоит: не было бюджетного деления, считалось вручную. Переехали к нам в облако, покрыли всё скриптами автоматизации и разгулялись. У них после первого дня не было ни одного захода в GUI и всего пара заходов в консоль — всё делают в очень автоматизированной инфраструктуре. Их средства автоматизации в любое время могут развернуть всё, что захотят. Теперь головняк у финансистов — просят, «уходя, гасить машины». Чтобы после тестов каждый за собой убирал. С учётом, что они пишут свою инфраструктуру полностью как код (IaaC), думаю, ещё и это автоматизируют. Если ещё не сделали.
Похожая картина была у другого разработчика — они использовали наш стандартный функционал проектных учёток. Это отдельные роли для каждой группы админов: там понятно, сколько денег на какой тип активности уходит. Проектная учётка — это роль, через которую можно создавать приватные облака по сути, и в них развёртывать ресурсы. Права и доступы нарезаются как угодно, есть верхние ограничения, есть отдельный билинг.
Весёлое использование
Мы обычно не знаем, как используют наше облако заказчики. Но иногда админы сами рассказывают и показывают. Так, у нас блокчейн-нода пилилась, есть CTF от одной компании, занимающейся безопасностью, — прямо симулятор корпоративной сети компании, туда надо подключаться и всё ломать. Используют для обучения сотрудников и конечных клиентов. Ещё один заказчик координирует уборку через облако, есть управление выпеканием хлебушка (АСУ ТП), есть медицинский сервис с видеоконсультациями с пациентами (у них очень сложная история с персональными данными, есть выделенный, специально защищённый сегмент). Ещё есть пара заказчиков — одни продают сервис, а вторые пишут первым софт. Из разных стран. И оба стоят рядом в облаке. Ещё одна розничная компания стоит у нас только ради того, чтобы бороться с рейдерами — им раз в месяц отрубали свет на серверном узле. Были запросы типа сервиса для спамеров: «Мы хотим, чтобы располагалось в России. Слать несколько миллионов писем в час. Надо именно в РФ. И софт русский». Последним отказали. Контроллер света одного из офисов (динамическое освещение от погоды и наличия людей в кабинетах) проброшен напрямую в облако, чтобы туда мог подрядчик для обслуживания заходить. Это наш первый IoT в облаке.
Автор: RenatS
