На Хабре и в нашем блоге о корпоративном IaaS мы много пишем о развитии облачных технологий, и публикуем конкретные примеры их использования компаниями. Напрмиер, мы рассказывали о том, как российские проекты Hotels.ru и PickPoint перенесли свою инфраструктуру в облако, однако такие ИТ-проекты — не единственные пользователи IaaS-технологий.
Облака помогают решать инфраструктурные задачи и организациям из неожиданных отраслей — например, сферы прогноза погоды или даже гонок «Формулы 1».
The Weather Channel: «облака» для сбора информации об облаках
Издание Computerworld опубликовало материал, в котором один из сотрудников компании The Weather Channel, занимающейся сбором и предоставлением информации о погоде во всем мире, рассказал о том, как новые технологии помогли повысить качество ее работы.
Компания постоянно сталкивалась с необходимостью обработки большого количества данных, объём которых мог серьезно возрастать в дни различных погодных катаклизмов, которые вызывали серьезный интерес аудитории. К примеру, возникновение шторма могло увеличить трафик сразу в 20 раз, а прогноз приближающейся бури сопровождался постоянно растущим числом запросов, которые нужно как-то обрабатывать.
Как правило, сайт компании посещают 12 млн уникальных посетителей в месяц, но при возникновении природных катаклизмов это число может возрастать и до 30 млн пользователей в час. Изначально компания содержала свой парк железа — за годы работы число дата-центров составило 13 штук — несколько лет назад это было выгоднее работы с облачными технологиями. Однако впоследствии облачные провайдеры смогли предложить более гибкие условия, а администрирование и масштабирование инфраструктуры в таком случае значительно проще.
The Weather Channel использует «страховочную» стратегию, согласно которой все ресурсы не размещаются на площадке одного провайдера. Максимальный объём ресурсов у одного провайдера не превышает 70%, на данный момент 20% инфраструктуры сохраняется в собственном дата-центре, а еще 10% ресурсов обрабатывает второй провайдер. При этом некоторые приложения и сервисы работают только на одной площадке поставщика, а наиболее критичные, к примеру SUN (Storage Utility Network), запущены на обеих сторонах. И если вдруг какая-то из площадок окажется недоступной, трафик The Weather Channel автоматически перенаправится на доступную площадку.
Представители команды The Weather Channel также отметили и некоторые сложности, связанные с переездом:
- Серьезно изменилась роль ИТ-службы. Переход в облако всегда меняет роль внутренней ИТ-службы (мы писали об этом здесь). В команде компании было около 400 технических специалистов, и им пришлось осваивать новые технологии, в частности DevOps. Не всем это пришлось по нраву — около 10 инженеров предпочли уволиться из компании.
- Необходимость разбираться с оставшимся устаревшим железом. После переезда в облако у компании все равно осталось определенное количество устаревшего железа, с которым нужно было разобраться. Какие-то из них пришлось полностью вывести из строя, какие-то удалось модернизировать для работы с облачными сервисами, но на это ушло немало сил.
- Проблема устаревших приложений. При миграции возникла и другая проблема — в ИТ-экосистеме работали некоторые приложения, заточенные на старую конфигурацию инфраструктуры. С такими приложениями могли взаимодействовать небольшие группы сотрудников, но для них это был важный инструмент. Предстояло решить, стоит ли адаптировать эти приложения для работы с облаком, или нужно полностью от них отказаться.
Sauber F1: Инфраструктура «Королевских гонок»
Швейцарская команда Sauber Motorsport AG выступает в серии «Формула-1». В ней работают порядка 300 специалистов, которые занимаются созданием гоночных автомобилей. Организация включает головной офис в городе Хинвиль, где также расположен завод и здание с аэротрубами для тестирования новых автомобилей.
Еще в 2007 году организация столкнулась с необходимостью организации мобильного дата-центра для запуска приложений, помогающих анализировать гоночную информацию, который присутствовал бы на гонках, а затем мог передавать данные в хранилища стационарных ЦОД. Для этого проекта были выбрана платформа FlexPod, созданная на базе решений NetApp и Cisco.
С помощью этой платформы происходит сбор данных с болидов, причем в любой момент времени. Данные, включающие информацию об использовании топлива, температуры, информацию о двигателях и другие параметры с датчиков обратной связи, передаются в FlexPod. Команда использует телеметрические показатели вместе с данными о состоянии трассы, запуская новые симуляции в FlexPod как до, так и в процессе самой гонки, сравнивая, как виртуальная модель соотносится с актуальными настройками автомобиля. Согласно результатам, полученным с трассы, специалисты Sauber F1 выполняют корректировку на лету, производя тонкую настройку автомобиля и повышая его производительность. Вносятся изменения, касающиеся охлаждения, в том числе оборудуются пит-стопы, что позволяет проводить замену шин с минимальными рисками. Выполняется сбор данных более чем со 100 сенсоров, расположенных на болидах.
FlexPod представляет из себя двухузловой кластер NetApp FAS2040 и NetApp SyncMirror для репликации данных. Мобильный центр данных состоит из 8 блейд-серверов Cisco Unified Computing System и свитча Cisco Nexus.
Данные, полученные во время заездов и гонок, с помощью NetApp SnapMirror реплицируются на MetroCluster, расположенный в два ЦОД города Хинвиль.Информация передается через MPLS-линки со скоростью 4 Мбит/с. Средняя задержка при передаче данных с гоночной трассы в головной офис составляет около 15 минут.
Вот как выглядит облачная инфраструктура дата-центров в Хинвиле:
В офисе гоночной команды работает узел NetApp MetroCluster, который представляет собой хранилище для производственных и офисных ситсем. Инфраструктура виртуализована на 90% — на пяти серверах VMware ESX запущено более 55 экземпляров виртуальных машин.
Кроме этого, Sauber планирует использовать дополнительный кластер, необходимый для поддержания 100 виртуальных рабочих станций, которые позволят избавиться от 80 физических устаревших рабочих узлов, так что отдельные инженеры смогут работать с несколькими настольными средами.
Возможность гибкого масштабирования хранилищ и увеличения производительности при необходимости помогают инженерам команды реагировать на изменения в ходе гонок. Добиться этого помогает, в том числе, использование технологии интеллектуального кеширования NetApp Flash Cache.
Также использование SATA-дисков позволяет снизить стоимость инфраструктуры без ущерба для скорости работы. В окружении виртуального сервера, где используется дедупликация в сочетании с Flash Cache, удается сохранить имеющийся потенциал и увеличить производительность в три раза. Поскольку 40 виртуальных машин попадают под процесс дедупликации, только одна из них считывается с диска, а остальные 39 загружаются из кеша.
При подготовке материала использовался отчет NetApp Technical Case Study.
На сегодня все, спасибо за внимание! Не забывайте подписываться на наш блог на Хабре и читать материалы в первом блоге о корпоративном IaaS.
alexpp
Насколько известно, уже несколько лет регламентом Ф1 запрещено изменение ключевых параметров двигателя/коробки передач/шасси/аэродинамики.
freylis
До начала квалификации есть области, где можно шаманить, иначе необходимость в свободных заездах отпадает. Непосредственно в гонке очень часто меняют угол атаки переднего антикрыла. Да и с этим *плохое_слово* вводом ограничений по топливу в гонке пилоты получают много распоряжений с командного мостика о том какие настройки по расходу топлива включить.
По поводу коробки — в начале сезона каждая команда выбирает себе несколько «пачек настроек» и по ходу сезона может использовать только их, правда я не в курсе, могут ли они сменить пачку перед началом квалификации
Wernisag
Регламент регулирует основные характеристики болида и запрещает выход за эти пределы. В Ф1 есть такое понятие как «закрытый парк», он действует с первого выезда в квалификации и до начала гонки. В это время все изменения происходят под контролем технической делегации ФИА. Список разрешенных работ строго регламентирован, но в случае вмешательства и изменения, замены, настройки, то болид покидает «закрытый парк» и стартует с пит-лейна, игнорируя результаты квалификации.
Однако Ф1 не была бы большим цирком если бы им не являлась в действительности. Перед тем как команда получит разрешение на использование двигателя, он проходит омологацию. После этого любые изменения запрещены. Кроме изменений связанных с безопасностью. Так же с сезона 2015 введены специальные «жетоны», в обмен на которые производитель двигателя может изменять и улучшать омологированный двигатель. Аналогично и с КПП.
Аэродинамика же ни как не попадает под эти правила. Её можно менять и в квалификации и в гонке. Даже возможны случаи, как квалификация и гонка проходит с разными передними крыльями.
TimID
«Запрещено изменение ключевых параметров» — это фраза, которую можно трактовать (особенно неспециалисту) как угодно.
На самом деле ограничения касаются изменения конструкции после «омологации» — утверждения этой самой конструкции технической комиссией F1. Если в конструкции будет предусмотрена возможность перемещения каких-нибудь элементов — то такие изменения остаются доступными, конечно.
Например, тот же регулятор угла атаки переднего антикрыла или возможность установки щитков на тормоза (для уменьшения потока воздуха) — это «огромные поля» для точных настроек. Просто нужно понимать, что в ситуациях, когда «важен каждый процент» (а зачастую именно такова цена «правильной настройки» — одна секунда с полутораминутного круга), даже небольшие изменения являются значимыми.