Сразу предупрежу: это не те байки, где крысу разорвало в хлам. Просто разные мелкие истории «как люди делают», которые могут быть полезны администраторам. А могут и не быть. У нас много довольно крупных заказчиков, и у них, соответственно, компетентные админы. По опыту скажу: часто опытнее там, где есть строгие ограничения по бюджету.

У нас есть заказчик, который перепродаёт наше облако (как оказалось), есть управление выпеканием хлеба из облака, есть даже развёрнутый 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 в облаке.

Комментарии (13)


  1. JC_IIB
    14.06.2018 10:24
    +2

    На файлшаре с важными документами, которых, собственно, почти 9 Тб насобиралось, лежит сериал «Доктор Хаус».


    Я бы, для начала, вспомнил, что существует такая вещь, как стеганография. А потом, какая разница, что там лежит, хоть полное собрание сочинений Браззерс за 2000й год. Это не ваши данные, к ним должно относиться, как к raw — лежит на старой СХД что-то — переливайте.

    Естественно, потом почистили, что в спешке заказчик не удалил.


    Вот так запросто грохнули клиентские данные??? Красавцы.


    1. lokkiuni
      14.06.2018 10:38
      +1

      Если правильно понял, админ заказчика удалял.


    1. StasTukalo
      14.06.2018 12:44

      тоже в первую очереди подумал про стегано. в др.хаусе точно искать небудут)))


      1. gx2
        15.06.2018 13:59

        "- Вы храните таблетки в книге про… ?" (с)


  1. Morgan_iv
    14.06.2018 11:28
    +2

    >Один наш заказчик – агрегатор – почти целиком почти состоит
    Так и хочется добавить «из почти разработчиков»


  1. Gryphon88
    14.06.2018 12:42

    Кто разбирается, выносить АСУ ТП и IoT в облако — это православно? Я б такие инфраструктурные вещи с объекта бы не убирал, чтобы аккуратнее падало.


    1. StasTukalo
      14.06.2018 12:47

      да, интересно было бы послушать аргументы ЗА… да и чем там в пекарне можно и тем более нужно управлять удаленно? врятли там именно асутп, скорее всякая статистика и отчетность…


      1. RenatS Автор
        14.06.2018 13:56

        Во-первых, инфраструктура облаков размещается в сертифицированных ЦОДах (у нас две площадки уровня Tier 3).
        Во-вторых, есть возможность сделать свои системы катастрофоустойчивыми, настроить кластеры и т.д.
        В таком случае вопрос о падении, даже «аккуратном», вообще стоять не будет.


        1. Gryphon88
          14.06.2018 15:06

          Просто я привык к АСУшной традиции, что если физически отвалился провод к датчику (на шахтах и прочих опасных производствах — или к датчику) или не прошла доставка пакета информации в назначенный срок — запускаем процедуру остановки производства, в зависимости от типа неполадки мягкую или срочную. Т.е. нормальная архитектура — пока получаем регулярные подтверждения, живём, но по дефальту умираем. Как это реализовать через Интернет — ума не приложу.


          1. Gryphon88
            14.06.2018 19:48

            *на шахтах — индикатору


        1. Jef239
          14.06.2018 23:18
          +1

          Неужели про взрыв на макаронной фабрике никогда не слышали? Везде где есть мука — возможен взрыв мелкодисперсной мучной смеси. И её предотвращает автоматика, то есть АСУТП. Могут засориться и упасть от перевеса фильтры — а это довольно тяжелые штуки. И тут опять автоматика. Ну и само собой — противопожарка. Ибо в пекарне печка.

          А облако… Клиенты в пекарне как, тоже по Tier-3 сертифицированы? Что будет, если в пекарне инет за неуплату отключат? :-) А при пожаре как, будет у горящей пекарни связь с инетом?

          Если (а вдруг?) пекарня сертифицирована по Tier-3 — так зачем ей облако. Если нет — общая надежность определяется надежностью связи пекарни с инетом, а не облака.

          Ещё. Пинг меньше 1 мс вы гарантируете? А это обычные требования к скорости срабатывания защит.

          Поэтому АСУТП делается на релейных схемах. Или на контроллерах, эмулирующих тупые релейные схемы. И только не критичные вещи — можно и на Дельфи/C/C++.

          А в облаке у вас АСУ. Скорее всего технологические рецептуры, логистика и так далее. То есть то, отчего безопасность людей не зависит. Но это не АСУ ТП, это АСУ.

          А падать оно должно. Если на 30 лет эксплуатации есть хоть один процент аварии — оно должно уметь упасть безопасно. Поэтому куча исполнительных устройств имеют «безопасное» состояние. По принципу мертвой руки. Оборвалась связь с контроллером — и клапана сами переходят в безопасное состояние (обычно закрываются). Это первый слой безопасности.

          На втором слое — отказ контроллера. Если контроллер сломался (завис), то выходы туда же — в безопасное состояние.

          На третьем слое — отказ датчиков. Любые датчики — ломаются. Хоть разок за 30 лет — но сломается. Контроллер, видя отказ датчика или несогласованность показаний делает что? Правильно, весь агрегат в безопасное состояние. То есть, как правило, выключает.

          Четвертый слой — самопроверки работы программы контроллера и проверка команд оператора. Что не так — туда же, в безопасное.

          Ну а когда люди надеются, что «вопрос о падении вообще стоять не будет», получается примерно так. Почитайте, история очень поучительная.


        1. StasTukalo
          15.06.2018 13:32

          вы както не на мой вопрос отвечаете. вопрос был о смысле управления пекарней из облака и чем именно там из облака можно управлять. а не про уровни tier выших цодов.


  1. igor_suhorukov
    14.06.2018 22:53
    +1

    Пир после блокировки подсетей AWS, Google, Microsoft!