Байки облака



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

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

    КРОК Облачные сервисы

    174,00

    Облачная IaaS-платформа собственной разработки

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


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

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


      Вот так запросто грохнули клиентские данные??? Красавцы.
        +4
        Если правильно понял, админ заказчика удалял.
          0
          тоже в первую очереди подумал про стегано. в др.хаусе точно искать небудут)))
            0
            "- Вы храните таблетки в книге про… ?" (с)
          +4
          >Один наш заказчик – агрегатор – почти целиком почти состоит
          Так и хочется добавить «из почти разработчиков»
            +5
            Кто разбирается, выносить АСУ ТП и IoT в облако — это православно? Я б такие инфраструктурные вещи с объекта бы не убирал, чтобы аккуратнее падало.
              +2
              да, интересно было бы послушать аргументы ЗА… да и чем там в пекарне можно и тем более нужно управлять удаленно? врятли там именно асутп, скорее всякая статистика и отчетность…
                0
                Во-первых, инфраструктура облаков размещается в сертифицированных ЦОДах (у нас две площадки уровня Tier 3).
                Во-вторых, есть возможность сделать свои системы катастрофоустойчивыми, настроить кластеры и т.д.
                В таком случае вопрос о падении, даже «аккуратном», вообще стоять не будет.
                  +3
                  Просто я привык к АСУшной традиции, что если физически отвалился провод к датчику (на шахтах и прочих опасных производствах — или к датчику) или не прошла доставка пакета информации в назначенный срок — запускаем процедуру остановки производства, в зависимости от типа неполадки мягкую или срочную. Т.е. нормальная архитектура — пока получаем регулярные подтверждения, живём, но по дефальту умираем. Как это реализовать через Интернет — ума не приложу.
                    0
                    *на шахтах — индикатору
                    +1
                    Неужели про взрыв на макаронной фабрике никогда не слышали? Везде где есть мука — возможен взрыв мелкодисперсной мучной смеси. И её предотвращает автоматика, то есть АСУТП. Могут засориться и упасть от перевеса фильтры — а это довольно тяжелые штуки. И тут опять автоматика. Ну и само собой — противопожарка. Ибо в пекарне печка.

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

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

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

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

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

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

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

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

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

                    Ну а когда люди надеются, что «вопрос о падении вообще стоять не будет», получается примерно так. Почитайте, история очень поучительная.
                      0
                      вы както не на мой вопрос отвечаете. вопрос был о смысле управления пекарней из облака и чем именно там из облака можно управлять. а не про уровни tier выших цодов.
                  +1

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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое