Дата-центры OVH

www.ovh.ie/dedicated_servers/rise/
www.ovh.ie/dedicated_servers/rise/prices/

Вы перенесли сайт раньше? Если у вас есть или вам потребуется регулярно мигрировать веб-сайты, вы будете знакомы с трудностями, связанными с этим видом операций.
Чтобы выразиться в самых основных терминах, эта операция обычно включает шесть шагов:

• покупка и настройка инфраструктуры назначения
• тестирование новой инфраструктуры путем импорта данных и кода сайта
• закрытие веб-сайта или перевод его в режим только для чтения, чтобы предотвратить сохранение данных в старой инфраструктуре в процессе миграции
• развертывание кода в новой инфраструктуре и импорт данных в новые базы данных
• изменение исходного кода для его адаптации к новой инфраструктуре (идентификаторы базы данных, подключение к внешним API и т.д.)
• когда веб-сайт работает над новой инфраструктурой, перенаправляет трафик, чтобы сделать его снова доступным (изменение зон DNS, обновление серверной части балансировщика нагрузки и т.д.)

В зависимости от исходного кода веб-сайта и сложности инфраструктуры эти шаги могут различаться по сложности. На самом деле, это зависит от доступа вашего сайта к записи данных. Должны ли данные храниться в базе данных? Есть ли у вашего сайта кеш на основе локальных файлов? Все это определено в исходном коде ваших веб-страниц.



Всего год назад, в марте 2018 года, OVH запустил крупный проект: миграция всех веб-хостинга и почтовых клиентов, размещенных в его устаревшем парижском центре обработки данных, в новый центр обработки данных. Для организации проекта процесс миграции был разделен на две части, управляемые двумя отдельными командами: веб-хостинг для первой команды и электронная почта для второй. Сегодня мы сосредоточимся на миграции веб-хостинга, но команда по миграции электронной почты также обсудит их процесс в нашем техническом блоге.

Для веб-хостинга этот проект включает миграцию трех миллионов различных веб-сайтов, размещенных на 7000 серверов в Париже. Некоторые из этих сайтов работают с 1999 года! Это одно из самых продолжительных мероприятий OVH. Так зачем их мигрировать, если они хорошо работают в Париже почти 20 лет? Чтобы понять все проблемы, с которыми мы сталкиваемся, нам нужно углубиться в историю этой службы.

Краткая история нашей веб-хостинговой платформы
Когда в 1999 году Октав основал OVH, доступ к Интернету все еще был ограничен. Первым направлением деятельности компании был хостинг веб-сайтов. То, что кажется простым сейчас, не было таким простым в то время. Вы должны были иметь хорошие сетевые соединения, поддерживать работу веб-серверов и правильно их настраивать. Трудно было найти людей с техническими знаниями или ресурсами, чтобы сделать это.

P19 строительство и расширение
В начале 2000-х годов у OVH была возможность приобрести здание в 19 округе Парижа. Здание P19 имело хороший доступ к электричеству и интернет-сетям, поэтому оно могло предоставлять услуги хостинга через Интернет и электронную почту большому количеству клиентов. Некоторое время это был единственный центр обработки данных OVH.

В P19 OVH не просто предлагал веб-хостинг. В центре обработки данных также размещены выделенные серверы. Оба вида деятельности быстро завоевали популярность, и в конце 2000-х годов OVH начала строить много новых центров обработки данных в Рубе, затем в Страсбурге, Богарном (Канада), Гравелине и за ее пределами.

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

Как сеть развивалась между 1999 и сейчас
Интернет сильно изменился с 1999 года. С нашей точки зрения, как хостинг-провайдера, мы наблюдали три события с течением времени…

• 1999 -> 2005: рождение сети. Статические сайты создавались в формате HTML. Это было, когда блоги начали появляться. Но эта технология была доступна только людям, которые знали, как использовать клиенты HTML и FTP, хотя FrontPage помог многим людям начать работу.
• Для работы эти сайты включали данные прямо в код. Веб-хостинг был довольно прост: пользователю требовалось место для хранения и веб-сервер, единственной целью которого была отправка веб-страницы, которую он будет искать в пространстве для хранения.
• 2006 -> 2013: Web 2.0 — революция в социальных сетях и базах данных. Веб-сайты стали динамичными и могли отображать пользовательские страницы в зависимости от пользователя. Это было, когда впервые начали появляться дискуссионные форумы, блог-платформы и социальные сети, которые все еще так популярны сегодня.
• Динамические сайты были революцией для провайдеров веб-хостинга; код и данные теперь хранятся в двух разных местах. Это означало, что страница должна была быть сгенерирована до того, как она была отправлена ​​конечному пользователю. Роль веб-сервера изменилась и будет генерировать эти страницы по запросу, в основном на языке PHP. Для этих веб-сайтов необходимо добавить серверы баз данных, а также вычислительную мощность для веб-серверов.
• 2014 -> сегодня: мощь JavaScript возросла, помогая разработчикам создавать сложные веб-приложения в браузерах и значительно улучшая работу веб-пользователей. Это изменение стало возможным благодаря развертыванию Интернета на наших смартфонах. В результате может быть запущено большое количество сервисов, требующих веб-доступа.

Технически это означает, что использование меняется, и пользователи чаще посещают веб-сайты, тем самым увеличивая объем создаваемых данных и сложность их обработки. Использование дискового пространства и ресурсов для создания веб-страниц постоянно увеличивается.
Мы очень быстро адаптировали наши решения для реагирования на эти изменения. Мы предложили новые базы данных, увеличили объем хранилища, предоставили услуги CDN и многое другое.

Но быстрый рост числа пользователей и ресурсов для наших планов веб-хостинга пополнил наш центр обработки данных. В связи с естественным ростом сервиса и растущими потребностями веб-сайтов, которые мы размещаем, в 2015 году мы заметили, что наш центр обработки данных в Париже будет заполнен к началу 2017 года.

Развертывание веб-хостинга в Gravelines
Как только мы отметили это, было только одно решение: чтобы избежать нехватки планов веб-хостинга, нам нужно разместить наши сайты в другом центре обработки данных. Мы внедрили наши услуги в Париже, чтобы предоставлять услуги хостинга 24/7, управлять 7 000 серверов и поддерживать их работоспособность на основе самых ранних технологий OVH.

Мы могли бы сохранить эту индустриализацию и применить ее к Gravelines, но мы решили сделать что-то еще. Мы решили создать новую техническую архитектуру, которая будет поддерживать растущие потребности с точки зрения производительности и, прежде всего, позволит нам повторно использовать другие продукты OVH. Это известный подход «съешь свою собачью еду», который применяется и расширяется в соответствии с нашими планами веб-хостинга.

Мы поставили перед нашими собственными командами задачу управлять выделенными серверами, vRack (частной сетью), IP-адресами и балансировщиками нагрузки (IPLB), чтобы они могли поддерживать инфраструктуру и трафик наших клиентов. Став одним из наших крупнейших клиентов, мы смогли выявить и преодолеть множество ограничений — повысить скорость отклика наших API, оптимизировать наши базы данных и многое другое.

Чтобы свести к минимуму задержку и удовлетворить требования географического распределения, мы предлагаем нашим клиентам широкий спектр центров обработки данных по всему миру. Все эти центры обработки данных были потенциальными целями для роста нашей платформы. По логистическим причинам мы решили запустить единый новый центр обработки данных в Европе. И это не влияет на наши веб-сайты: различия в задержке между нашими центрами обработки данных настолько минимальны, что они даже не кажутся размещенными на них сайтами (увеличение составляет всего несколько миллисекунд, и это занимает несколько сотен миллисекунды для создания веб-страниц).

Чтобы выбрать наш новый центр обработки данных, мы проанализировали наш естественный рост, чтобы выработать наши требования к инфраструктуре. Фактически, наша инфраструктура растет каждую неделю с новыми поставками оборудования, и мы рискуем настолько быстро заполнить наши центры обработки данных, что это помешает нашим клиентам арендовать выделенные серверы и другие сервисы OVH. Согласно этим критериям, только два центра обработки данных удовлетворяли наши потребности в плане инфраструктуры в 2016 году: Gravelines на севере Франции и Beauharnois в Канаде. Поскольку наша платформа в настоящее время развернута только в Европе, мы начали работать над Gravelines.

В то же время мы рассмотрели и оптимизировали оборудование, используемое для построения наших кластеров, чтобы мы могли обеспечить более высокую производительность. Инновации, представленные в Gravelines, помогли нам еще больше улучшить доступность нашей платформы.

Самой большой проблемой было не изменение опыта обслуживания — мы сохранили все функции и сохранили все те же графические интерфейсы и API. Нашей целью было просто обновить инфраструктуру, а не сами коммерческие продукты.

Этот центр данных для веб-хостинга был открыт в июле 2016 года. И с ноября того же года все наши новые планы хостинга были доставлены туда.

Каждый год клиенты отменяют свои услуги веб-хостинга, потому что они больше не используют их или переходят на другие продукты, такие как VPS-решения. В результате этого количество веб-сайтов, размещенных в Париже, за последние три года постепенно уменьшалось. Это помогло нам справиться с увеличением мощности, необходимой для остальных веб-сайтов, без увеличения пропускной способности нашей инфраструктуры в Париже.

Учитывая естественное снижение количества веб-сайтов, размещенных в центре обработки данных, мы решили, что лучше дождаться, пока большинство наших клиентов откажутся от своих услуг, прежде чем мы перенесем их. Зачем это делать, когда осталось три миллиона сайтов?

Почему мы решили перенести наш центр обработки данных?
Чтобы дать Парижу новую жизнь?
Есть несколько причин, по которым мы начинаем это грандиозное начинание. Но главная причина — это устаревание.

Наша инфраструктура основана на физических ресурсах, размещенных в этом центре обработки данных: выделенных и виртуализированных серверах (которые основаны на физических машинах), сетевых элементах и ​​контуре охлаждения (водяное охлаждение и кондиционирование воздуха). И чтобы инфраструктура оставалась доступной 24/7, нам необходимо периодически обновлять это оборудование.

Для выделенных серверов это довольно просто. Если сервер становится неисправным, его можно просто заменить новым. Серверы, созданные для Парижа, не имеют тех же технических и материально-технических улучшений, от которых выигрывают другие наши центры обработки данных, и их становится все труднее собирать, поскольку устаревание нашего центра обработки данных требует от нас все большего и большего обновления.

Мы рассмотрели вопрос о замене этих серверов моделями следующего поколения, но нам нужно будет изменить архитектуру целых комнат. И чтобы добиться этого без какого-либо влияния на доступность нашей платформы, нам потребуется пространство для строительства новых комнат перед миграцией серверов один за другим. В здании, которое почти на полную мощность, это потребовало бы опустошения комнат.

Для работы выделенным серверам также требуется питание, сеть и система охлаждения. Все эти элементы также управляются физическим оборудованием: кондиционирование воздуха и водяное охлаждение для охлаждения машин, маршрутизаторов и коммутаторов для сети, электрических трансформаторов, устройств ИБП и аккумуляторов для электричества.

Эти избыточные физические инфраструктуры также должны регулярно заменяться, чтобы избежать простоев. Если один из путей доступа не работает, второй вступит во владение. Кроме того, это обычная операция, выполняемая техническими специалистами, поэтому они могут выполнять незначительные задачи по обслуживанию компонентов оборудования.

Процесс полной замены этих инфраструктур новыми является долгим и сложным. Полагаться на один путь доступа в течение такого длительного периода времени было просто невозможно. Для их замены потребовалось бы установить третий путь, а затем переключиться на него, когда все будет готово. Однако это также будет означать, что в центре обработки данных должно быть место для всех этих операций.

Спустя двадцать лет наш центр обработки данных в Париже достиг конца жизненного цикла. Масштабная работа требуется на всех уровнях, а для этого требуется пространство. Это основная причина миграции.

Чтобы повысить производительность сайта
Благодаря новой инфраструктуре в Gravelines мы можем повысить производительность веб-сайтов наших клиентов. Более того, эти новые технологии помогли нам развернуть некоторые дополнительные функции, которые мы не можем развернуть в Париже без обновления нашей инфраструктуры: HTTP / 2, MySQL 5.6 и другие.

Наши клиенты могут сами перенести свои проекты, но миграция плана веб-хостинга — сложная и деликатная процедура. Многие клиенты отказались от этого.

После завершения миграции мы также сможем упростить наше оперативное обслуживание, используя исключительно стандарты OVH. Это поможет нам избежать выполнения определенных операций в парижском центре обработки данных, сократив время обслуживания и риски определенных повторяющихся ручных операций.

Как мы переносим так много сайтов?
Как провайдер веб-хостинга, мы в основном специализируемся на двух областях — хостинг данных и выполнение кода.

Хостинг данных — сложная операция, если он должен поддерживать свою целостность во времени, но это относительно стандартизированная отрасль. Данные хранятся в файловой системе (это стандарт) или в базе данных, которая использует определенный язык запросов (MySQL 5.5 или MySQL 5.6). Поэтому нам просто нужно воспроизвести архитектуру, которая соответствует тому же стандарту в целевой инфраструктуре, и перенести в нее данные.

Выполнение кода более сложное. Очень трудно определить поведение исходного кода в его среде, по крайней мере, не интерпретируя его. Он может вернуть ошибку в определенной версии расширения PHP, проверить локальную папку и многое другое. Например, многие наши клиенты хранят абсолютный путь к своим файлам в коде. Однако это означает, что мы не можем изменить место хранения файлов, не влияя на их службу.

Когда вы размещаете сервисы для нескольких клиентов, вы можете легко помочь им, обнаружив коды, которые больше не будут работать после миграции. Но в более широком масштабе это сложно. Представьте, что вы делаете это с кодами для более чем трех миллионов сайтов!

Просить наших клиентов изменить их исходный код не было жизнеспособным решением. Даже если предположить, что все наши клиенты прочтут по электронной почте об этом, некоторые из них не внесут изменения из-за нехватки времени, технических знаний или просто забыв сделать это. Мы будем создавать проблемы для наших клиентов с их веб-сайтами, и для нас это просто не вариант.

В течение почти года мы разработали несколько сценариев миграции. Мы экстраполировали их по всем направлениям с двумя целями:

• веб-сайты должны оставаться работоспособными после завершения миграции, и клиентам не нужно вносить какие-либо изменения в свой код
• влияние на доступность услуг в процессе миграции должно быть минимальным

Мы внедрили и протестировали некоторые из этих сценариев в период с марта по июнь 2018 года. Эта первоначальная работа помогла нам выбрать лучший план миграции. Чтобы завершить эту миграцию, не затрагивая службы, нам необходимо было адаптировать часть нашей инфраструктуры и информационной системы: создать сетевой туннель между центрами данных, изменить балансировщики нагрузки, нашу платформу базы данных, добавить прокси-серверы SQL и многое другое.

Мы тщательно протестировали выбранный сценарий. Чтобы гарантировать, что эта процедура будет выполняться с минимальным воздействием, мы много раз повторяли ее в реальных условиях на внутренних кластерах, используя наборы данных на основе производственных платформ.

Хотите узнать больше информации о нашем плане миграции? Мы не можем включить все в эту запись блога, поэтому мы решили рассказать о нашей миграции в серии постов, поскольку эта тема очень обширна.

Следите за нашими будущими публикациями, которые дадут вам возможность заглянуть за кулисы крупнейшей в Европе миграции веб-сайтов, осуществляемой крупнейшим в Европе хостинг-провайдером!

Ожидание окончено! Мы представляем наши самые мощные серверы когда — либо в США! Новые сервера HG идеально подходят для любой нагрузки, требующей высокой производительность и низкую латентность, таких как большой анализ данных, машинного обучение или базы данных в оперативной памяти.

Вот первый взгляд на наших предварительно настроенных серверов премиум — HG.


us.ovhcloud.com/products/servers/infrastructure-servers

Одним из ключевых преимуществ использования Kubernetes является огромная экосистема вокруг него. От Rancher до Istio, от Rook до Fission, от gVisor до KubeDB, экосистема Kubernetes богата, динамична и постоянно растет. Мы подошли к тому, что для большинства потребностей в развертывании мы можем сказать, что для этого существует проект с открытым исходным кодом на основе K8s.

Одним из последних дополнений к этой экосистеме является проект Agones, многопользовательский, выделенный хостинг на игровом сервере с открытым исходным кодом, построенный на Kubernetes, разработанный Google в сотрудничестве с Ubisoft. Проект был анонсирован в марте, и уже наделал немало шума…

В OVH Platform Team мы являемся поклонниками онлайн-игр и Kubernetes, поэтому мы сказали себе, что нам нужно протестировать Agones. И какой лучший способ проверить это, чем развернуть его в нашей службе OVH Managed Kubernetes, установить кластер игровых серверов Xonotic и сыграть в старом классе с коллегами?



Почему агон?
Agones (происходит от греческого слова agōn, конкурсы, проводимые во время публичных фестивалей или, в более широком смысле, «соревнование» или «соревнование в играх»), стремится заменить обычные проприетарные решения для развертывания, масштабирования и управления игровыми серверами.
www.merriam-webster.com/dictionary/agones
kubernetes.io/docs/concepts/api-extension/custom-resources/#custom-controllers
kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions

Agones обогащает Kubernetes пользовательским контроллером и пользовательским определением ресурса. С их помощью вы можете стандартизировать инструменты и API Kubernetes для создания, масштабирования и управления кластерами игровых серверов.

Подождите, о каких игровых серверах вы говорите?
Итак, основное внимание Agones уделяют многопользовательским онлайн-играм, таким как FPS и MOBA, быстрым играм, требующим выделенных игровых серверов с малой задержкой, которые синхронизируют состояние игры между игроками и служат источником правды в игровых ситуациях.

Игры такого типа требуют относительно эфемерных выделенных игровых серверов, причем каждое совпадение выполняется на экземпляре сервера. Серверы должны быть с состоянием (они должны сохранять статус игры), причем состояние обычно хранится в памяти на время матча.

Задержка является ключевой проблемой, поскольку конкурентные аспекты игр в реальном времени требуют быстрого ответа от сервера. Это означает, что подключение от устройства игрока к игровому серверу должно быть максимально прямым, в идеале, в обход любого промежуточного сервера, такого как балансировщик нагрузки.

А как вы подключаете плееры к нужному серверу?
Каждый издатель игр имел свои собственные проприетарные решения, но большинство из них следуют аналогичному потоку, предлагая сервис по подбору игроков, который объединяет игроков в матчи, взаимодействует с менеджером кластера для предоставления выделенного экземпляра игрового сервера и отправки игрокам его IP-адрес и порт, чтобы позволить им напрямую подключаться к серверу и играть в игру.



Agones и его пользовательский контроллер и пользовательское определение ресурса заменяет сложную инфраструктуру управления кластером стандартизированными инструментами и API на основе Kubernetes. Службы сватов взаимодействуют с этими API-интерфейсами для создания новых модулей игровых серверов и передачи их IP-адресов и портов заинтересованным игрокам.



Вишня на торте
Использование Kubernetes для этих задач также дает приятный дополнительный бонус, например, возможность развертывать полную игровую инфраструктуру в среде разработчика (или даже в мини-кубе) или легко клонировать ее для развертывания в новом центре обработки данных или облачной области, но также предлагая целую платформу для размещения всех дополнительных услуг, необходимых для создания игры: управление учетными записями, списки лидеров, инвентарь
github.com/kubernetes/minikube

И, конечно же, простота эксплуатации платформ на базе Kubernetes, особенно когда они динамические, разнородные и распределенные, как большинство игровых онлайн-платформ.

Развертывание Agones на управляемых OVH Kubernetes
Есть несколько способов установить Agones в кластер Kubernetes. Для нашего теста мы выбрали самый простой: установка с помощью Helm.
helm.sh/

Включение создания ресурсов RBAC
Первым шагом для установки Agones является настройка учетной записи службы с достаточными разрешениями для создания некоторых специальных типов ресурсов RBAC.

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin --serviceaccount=kube-system:default

Теперь у нас есть Cluster Role Binding, необходимая для установки.
kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding

Установка диаграммы Agones
Теперь давайте продолжим, добавив хранилище Agones в список хранилищ Helm.

helm repo add agones https://agones.dev/chart/stable

И затем установка стабильной диаграммы Agones:

helm install --name my-agones --namespace agones-system agones/agones

agones.dev/site/docs/installation/helm/

Установка, которую мы только что выполнили, не подходит для производства, так как в официальных инструкциях по установке рекомендуется использовать Agones и игровые серверы в отдельных выделенных пулах узлов. Но для нужд нашего теста достаточно базовой настройки.

Подтверждение Agones началось успешно
Чтобы убедиться, что Agones работает в нашем кластере Kubernetes, мы можем взглянуть на модули в пространстве имен agones-system:

kubectl get --namespace agones-system pods

Если все в порядке, вы должны увидеть модуль контроллера agones со статусом Running:

$ kubectl get --namespace agones-system pods
NAME                                 READY   STATUS    RESTARTS   AGE
agones-controller-5f766fc567-xf4vv   1/1     Running   0          5d15h
agones-ping-889c5954d-6kfj4          1/1     Running   0          5d15h
agones-ping-889c5954d-mtp4g          1/1     Running   0          5d15h

Вы также можете увидеть более подробную информацию, используя:

kubectl describe --namespace agones-system pods

Глядя на описание agones-контроллера, вы должны увидеть что-то вроде:

$ kubectl describe --namespace agones-system pods
Name:               agones-controller-5f766fc567-xf4vv
Namespace:          agones-system
[...]
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True

Где все Условия должны иметь статус True.

Развертывание игрового сервера
Мир Agones Hello довольно скучный, простой эхо-сервер UDP, поэтому мы решили пропустить его и перейти непосредственно к чему-то более интересному: игровому серверу Xonotic.
github.com/GoogleCloudPlatform/agones/tree/release-0.9.0/examples/simple-udp
github.com/GoogleCloudPlatform/agones/blob/release-0.9.0/examples/xonotic
www.xonotic.org/

Xonotic — это многопользовательский FPS с открытым исходным кодом, довольно неплохой, с множеством интересных игровых режимов, карт, оружия и опций настройки.

Развернуть игровой сервер Xonotic поверх Agones довольно просто:

kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/agones/release-0.9.0/examples/xonotic/gameserver.yaml

Развертывание игрового сервера может занять несколько минут, поэтому нам нужно подождать, пока его состояние не станет «Готов», прежде чем использовать его. Мы можем получить статус с:

kubectl get gameserver

Мы ждем, пока извлечение не даст статус Ready на нашем игровом сервере:

$ kubectl get gameserver
NAME      STATE   ADDRESS         PORT   NODE       AGE
xonotic   Ready   51.83.xxx.yyy   7094   node-zzz   5d

Когда игровой сервер готов, мы также получаем адрес и порт, который мы должны использовать для подключения к нашей игре Deathmatch (в моем примере, 51.83.xxx.yyy: 7094).

Время фрагмента
Теперь, когда у нас есть сервер, давайте проверим его!

Мы загрузили клиент Xonotic для наших компьютеров (он работает на Windows, Linux и MacOS, так что оправданий нет) и запустили его:


Затем мы идем в многопользовательское меню и вводим адрес и порт нашего игрового сервера:


И мы готовы играть!


А на стороне сервера?
Со стороны сервера мы можем следить за тем, как идут дела на нашем игровом сервере, используя логи kubectl. Давайте начнем с поиска модуля, на котором запущена игра:

kubectl get pods

Мы видим, что наш игровой сервер работает в модуле под названием xonotic:

$ kubectl get pods 
NAME      READY   STATUS    RESTARTS   AGE
xonotic   2/2     Running   0          5d15h

Затем мы можем использовать логи kubectl. В модуле есть два контейнера, основной ксонотический и колонтитул Agones, поэтому мы должны указать, что нам нужны журналы ксонотического контейнера:

$ kubectl logs xonotic
Error from server (BadRequest): a container name must be specified for pod xonotic, choose one of: [xonotic agones-gameserver-sidecar]
$ kubectl logs xonotic xonotic
>>> Connecting to Agones with the SDK
>>> Starting health checking
>>> Starting wrapper for Xonotic!
>>> Path to Xonotic server script: /home/xonotic/Xonotic/server_linux.sh 
Game is Xonotic using base gamedir data
gamename for server filtering: Xonotic
Xonotic Linux 22:03:50 Mar 31 2017 - release
Current nice level is below the soft limit - cannot use niceness
Skeletal animation uses SSE code path
execing quake.rc
[...]
Authenticated connection to 109.190.xxx.yyy:42475 has been established: client is v6xt9/GlzxBH+xViJCiSf4E/SCn3Kx47aY3EJ+HOmZo=@Xon//Ks, I am /EpGZ8F@~Xon//Ks
LostInBrittany is connecting...
url_fclose: failure in crypto_uri_postbuf
Receiving player stats failed: -1
LostInBrittany connected
LostInBrittany connected
LostInBrittany is now spectating
[BOT]Eureka connected
[BOT]Hellfire connected
[BOT]Lion connected
[BOT]Scorcher connected
unconnected changed name to [BOT]Eureka
unconnected changed name to [BOT]Hellfire
unconnected changed name to [BOT]Lion
unconnected changed name to [BOT]Scorcher
[BOT]Scorcher picked up Strength
[BOT]Scorcher drew first blood! 
[BOT]Hellfire was gunned down by [BOT]Scorcher's Shotgun
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was gunned down by [BOT]Eureka's Shotgun, ending their 2 frag spree
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was shot to death by [BOT]Eureka's Blaster
[BOT]Hellfire slapped [BOT]Eureka around a bit with a large Shotgun, ending their 2 frag spree
[BOT]Eureka slapped [BOT]Scorcher around a bit with a large Shotgun
[BOT]Eureka was gunned down by [BOT]Hellfire's Shotgun
[BOT]Hellfire was shot to death by [BOT]Lion's Blaster, ending their 2 frag spree
[BOT]Scorcher was cooked by [BOT]Lion
[BOT]Eureka turned into hot slag
[...]

Добавьте друзей
Следующий шаг в основном приятен: попросить коллег подключиться к серверу и провести настоящий Deathmatch, как в Quake 2 раза.

И сейчас?
У нас есть работающий игровой сервер, но мы едва раскрыли возможности Agones: развертывание флота (набор теплых GameServer, доступных для распределения), тестирование FleetAutoscaler (для автоматического увеличения и уменьшения флота в ответ на спрос), делая некоторые фиктивные услуги распределителя. В будущих публикациях в блоге мы углубимся в это и рассмотрим эти возможности.
agones.dev/site/docs/tutorials/allocator-service-go/
agones.dev/site/docs/reference/fleet/
agones.dev/site/docs/reference/fleetautoscaler/

И в более широком контексте мы собираемся продолжить наше исследовательское путешествие по Агонесу. Проект еще очень молодой, ранняя альфа, но он показывает некоторые впечатляющие перспективы.

www.soyoustart.com/ie/essential-servers/
или писать тикет мне

Он самый большой путешественник из великих боссов Рубе: только что прибыв из Далласа, где он сейчас живет, он возвращается в полдюжины стран Европы, где базируется его компания OVH. Во время краткого возвращения на родину, в штаб-квартиру крупнейшего в Европе хранилища данных, Октава Клаба поделился с нами своим видением цифровой революции, происходящей на его глазах.

OVH будет 20 лет. Как вы объясните его успех?

Пятнадцать лет я не понимал, почему мы преуспели. Но за последние пять лет мы очень быстро выросли, обосновавшись в Канаде, Соединенных Штатах, много набирая на два или три года. Мы поняли наши различия и почему это работает.

Это должно вернуться к началу. Когда я запустил коробку, на моем счете было 5000 франков. У моих родителей не было денег, чтобы одолжить мне. Я одолжил 25 000 балов, я всех раздражал. Я бросил ящик, где работал пять недель. Когда ты идешь ко дну своей мечты, пусть даже это нелегко каждый день, но оно того стоит.

Почему я создал OVH? Я хотел другую коробку, где человеческие отношения просты, куда вы хотите прийти утром, где вы делаете невероятные вещи, не принимая себя всерьез. Я убежден, что то, как мы работаем, так и будут делать компании в будущем. Это позволило нам выжить в начале, быстро расти с этой культурой и нашими ценностями.

Я также хотел, чтобы он был основан на компьютерах, подключенных к Интернету. Отсюда и наш успех: мы поддерживаем цифровую революцию, изменение общества. «Облако» позволяет управлять данными. Это то, на чем основан новый мир: информация. Все дано, и мы позволяем данным создавать стоимость. Мы внутри этой истории. И это преобразование, мы делаем это отсюда, в Рубе!

Есть ли у компании во Франции средства для роста?

Конечно. И если вам нужно быть предпринимателем, это сейчас. Есть много вещей, чтобы изобрести сегодня. Через пять-десять лет многое будет сделано. Чего не хватает для создания крупных компаний вокруг цифровых технологий? Это рынок. Франции не хватает, как и Европе. Франция маленькая, а Европа сложная! Мы должны стремиться к миру и часто проходить через Соединенные Штаты: он большой и простой! Так мы достигаем критической массы.

Я создал компании примерно в двадцати странах. У каждого свои особенности. Там не идеальная страна. Повсюду существуют юридические, административные и налоговые ограничения. В Соединенных Штатах налоги важны. Там на самом деле страна не легче, чем другие. Некоторые могут свалить как Ирландия, Сингапур. Я не чувствую, что Франция наказана. Меня беспокоит то, что я облагаюсь налогом по ставкам, которые не применяются к моим китайским или американским конкурентам, и что это влияет на наш рост. Я не говорю об этом, чтобы у нас было больше денег, но чтобы у нас была возможность расти быстрее.

Каким вы видите налоговый проект GAFAM?

Вокруг сетевых гигантов существует реальная проблема в отношении их вклада. Это признается, это должно регулироваться. У правительства хороший подход. Когда два человека вступают в деловые отношения, мы облагаем налогом эти отношения. Интересно, мы никогда не делали этого раньше. Правильно ли это предназначено для этой деятельности? Кажется так. Теперь это все еще новый налог, и он эффективен, только если все сделают то же самое, в Европе, США, Китае

Вы смотрите на политиков с расстояния

Я всегда неохотно отношусь к политическому миру и считаю, что компания должна быть надежной и экономически жизнеспособной. Если компания не может платить своим сотрудникам или развиваться, ее нужно «убить», создать что-то лучшее. А бизнес не может жить на капельнице.


Я никогда ничего не спрашивал у политиков. Но у политиков есть инструмент для поддержки деятельности: общественный порядок. Это касается самолетов, военной техники. Но политический мир не является интервенционистом для облака. Многие коробки созданы в цифровом формате, и публичный рынок должен рисковать, используя свои продукты. Эта сила поддержки экономики огромна.

Это вопрос суверенитета?

OVH — единственный игрок в европейском облаке. Мы находимся в первой десятке по всему миру, с оборотом ниже, чем у американцев. Но мы существуем, потому что наши клиенты видят ценность в хранении своих данных здесь, в Рубе, Гравелине, Страсбурге… Мы объясняем компаниям, что они заинтересованы в поддержке нас, покупая такие продукты, как наша, чтобы остаться повелитель!

Мы объясняем им риски, которые могут существовать. Закон об облаке, закон, принятый в Соединенных Штатах, гласит, что если вы размещаете свои электронные письма в Google, в Microsoft, власти могут их прочитать! Это серьезно! Если европейские компании считают обратное, это слишком плохо для них, но это удивительно. Это просто жизненно важно для европейского суверенитета.

Как вы смотрите на Brexit?

Никто не понимает этого, и никто не знает, чем это закончится. Тем не менее интересно посмотреть, как в стране происходят такие «подрывные» решения! Выйти из сообщества — это опыт. Это как Греция, которая, чтобы выйти из банкротства, экспериментировала с разными путями… Что касается Британии, у нас там есть мероприятия, команды, центры обработки данных… Мы бы хотели, чтобы Brexit не не будет сделано, но мы будем адаптироваться.

Со времен Соединенных Штатов вы наблюдали движение желтых жилетов?

Я французские новости. Это новый тип движения, проявления, в котором есть хорошо или нет. Что интересно, так это виртуальное движение, которое происходит в физическом мире и показывает, что его трудно услышать. Правительство слышало претензии… Но есть и головорезы, и это то, что не так, потому что это не позволяет обмен. Мы находимся в упадке общества, что, если не будет обсуждения, мы оставим на стороне людей, которые, естественно, пойдут на крайние меры. Мы должны поощрять все, что позволяет нам общаться, убеждать, слушать

Вебу 30 лет: что вы думаете о том, чем он стал?

Что такое интернет? Технология построена на связи между машинами. Эта технология изменила нашу жизнь и общество. Мы выравниваем отношения, расстояния сокращаются, люди через Твиттер могут бросить вызов любому в мире… Это нарушение отношений между людьми. С годами робототехника, беспилотники, смартфоны открыли много возможностей. Я не особо смотрю в прошлое, но я всегда очень рад будущему.

Но это приносит очень важные проблемы?

Это правда Возьми робототехнику. Здесь, в Круа, мы инвестировали в фабрику по производству наших серверов. Мы потратили 10 миллионов и создали 20 рабочих мест. Это 500 000 евро на создание рабочих мест, а на 2000 рабочих мест требуется один миллиард. Это много? Я не считаю это очень много. Потому что с 2000 роботами, анимированными 2000 людьми, мы можем многое сделать. Роль людей больше не в том, чтобы делать, а в том, чтобы делать это так, как это делают роботы. И это открывает возможность обучать людей выполнять более интересные задачи.

Так что будет завтра?

Универсальный доход не может быть ерундой. Но если у всех есть деньги, почему я встаю утром? Эти мутации общества очень интересны, и в политическом плане есть ответы, которые нужно найти. Вопрос сложный. Если больше нет необходимости работать для выполнения работы, что мы будем делать с нашей жизнью? Вот что будет через десять или двадцать лет. Мы должны придавать значение людям. Мы привезли некоторые с работой. Если работа и компенсация меняют форму, вам придется много чего изобретать. Мы живем невероятный период. У компаний есть ответ, и я надеюсь сделать это с OVH.

Маршрут блестящего подростка
Карьера Октавы Клабы — это карьера 16-летнего подростка, который не говорит по-французски, когда он приезжает в Рубе в 1990 году. Семья возвращается по стопам польского деда, который пришел работать в ямы деревни. шахтный бассейн. Студент великолепен, интегрирует ICAM в Лилле и, сумасшедший компьютер, преследует американский веб-сайт, который не следует темпам. Это триггер для создания OVH.

Компания предлагает хостинг данных и приложений в Интернете и, в более общем смысле, то, что называется «облаком», вычислительным удалением до сотен тысяч серверов.

С тех пор OVH была основана во всем мире: в 130 странах с 2000 сотрудников (одна тысяча в Рубе, ее штаб-квартира) работает тридцать центров обработки данных, таких как Gravelines.

Цифровой актер, он также промышленник, способный производить 400 000 серверов в год на своей фабрике в Круа. OVH объявляет об обороте в 500 миллионов евро и все еще надеется достичь миллиарда через два года.

ИТ-аналитики могут быть иногда циничными, закаленными. Мы услышали все тонкие маркетинговые новости, увидели безупречные, глянцевые центры обработки данных и рассказали, как их люди и культура являются их ключевыми отличиями. В большинстве случаев это не оставляет нас равнодушным, и мы должны копать глубоко, чтобы найти какие-либо драгоценные камни. Но наш недавний визит в дом OVH в Рубе, на севере Франции, стал настоящим откровением.

Помимо очень красивого старого города, город Лилль / Рубе / Туркуэн — это скудная промышленная зона с небольшим отставанием, типичная для многих городов, пытающихся справиться с последствиями постиндустриальной Европы. Это не то место, где вы ожидаете найти современную успешную облачную компанию. Тем не менее, OVH добились успеха в этой среде и создали совершенно другой тип организации, который мы можем легко увидеть, основываясь на инновациях, энтузиазме, сильной интеграции цепочки поставок и большой доле галльской самостоятельности.

Никогда первые впечатления не были более обманчивыми. От работы со складом, которую я бы узнал со времени работы в логистике в 1970-х годах, до центров обработки данных, переброшенных в старые промышленные помещения на уставших промышленных площадках, казалось, что OVH изо всех сил старается нас оттолкнуть. И тем не менее, он отлично сочетается.

Давайте начнем с инноваций. OVH проектирует и строит свои собственные серверы и стойки, в которых они находятся. У них концептуальный подход, основанный на «1-100-1000». OVH показал нам место, где рождаются новые идеи: семинар, в котором доктор Эммет Браун («Назад в будущее») был бы дома. Здесь они придумали уникальную интегрированную систему водяного охлаждения, встроенную в стойки, стойки со встроенными теплообменниками и распределительными блоками, а также стойки, уложенные по бокам и сложенные по три в высоту. Это обеспечивает гораздо более высокую плотность, а конструкция также обеспечивает очень гибкие конфигурации. Затем, переходя в следующую комнату, вы попадаете в макет зала обработки данных, где инновации в дизайне стоек и серверов встроены в реалистичную среду для тестирования, 100. Оттуда это был короткий шаг к успеху. область, где роботы взяли листы металла и согнули их в различные формы для стеллажей, которые затем перемещаются в производственный цех, где собраны настоящие серверы — 1000.

Что это означает на практике, становится очень очевидным, когда вы входите в один из их центров обработки данных. С одной стороны, они тише, с отсутствием шума вентилятора. Там нет горячего прохода прохода. Любая высокая температура от задней части серверов минимальна, и воздушные дымоходы забирают высокую температуру, такую, какая она есть, вверх и вниз. Есть несколько резервных блоков CRAC на случай, если погода станет очень жаркой, но в северной Франции это довольно редко. Результатом являются ЧУЭ менее 1,1 на старых заводах, которые традиционно не склонны к эффективному использованию энергии. OVH не тратили время и деньги, пытаясь улучшить структуру здания, чтобы повысить ее энергоэффективность. По сути, они устанавливают серверные стойки в большие металлические контейнеры, опять же собственной конструкции. Все выглядит немного утилитарно, но в этом подходе есть элегантная простота.

Наличие собственной производственной базы также позволяет OVH перераспределять и перерабатывать старые серверные компоненты в новые конфигурации, поддерживающие услуги с низким потреблением ресурсов, обеспечивая быстрое и эффективное обновление «передовых» серверов высокой спецификации.

Этот высоко вертикально интегрированный промышленный процесс инноваций, проектирования, тестирования, сборки, развертывания и повторного использования / повторного назначения является ключом к неизменно высоким рейтингам OVH в показателях соотношения цена / производительность от организаций, таких как Cloud Spectator. Эти критерии особенно очевидны, когда превращаются в реальные расходы, которые платят клиенты, по сравнению с аналогами AWS и Microsoft Azure. OVH выходят явные победители здесь.

Если вы не видели эту операцию, вы можете опасаться, что огромная экономия от масштаба, доступная AWS и Microsoft Azure, может оказать серьезное влияние на их пользу в любой ценовой борьбе. Но ясно, что в их цепочке поставок и ИТ-операциях все еще есть много возможностей для повышения эффективности, например, за счет повышения автоматизации. OVH также недавно присоединились к Open Compute Project (OCP). Я подозреваю, что в настоящее время они могут научить ОСР столько же, сколько они могут получить от них, но наличие доступа к этому улей-уму может быть не плохой вещью для будущей конкурентоспособности.

Суть в том, что если вы ищете неизменно хорошую глобально масштабируемую производительность IaaS по низкой цене, OVH — одно из первых мест, куда вам следует обратить внимание. Но OVH превращаются в нечто большее, чем провайдер IaaS. В следующем блоге я расскажу о быстрых разработках OVH в PaaS и других конкретных сервисных предложениях, которые делают их безопасным и зрелым предложением для предприятий, которые хотят перейти на гибридную облачную среду безопасным и поддерживаемым способом.

Мы все знакомы с этим небольшим фрагментом кода, который добавляет разумную ценность вашему бизнес-подразделению. Он может материализоваться как сценарий, программа, строка кода… и он будет создавать отчет, новые метрики, KPI или создавать новые составные данные. Этот код предназначен для периодического запуска, чтобы удовлетворить требования к актуальной информации.

В команде Observability мы встречаем эти фрагменты как запросы в базе данных временных рядов (TSDB), чтобы выразить непрерывные запросы, которые отвечают за автоматизацию различных вариантов использования, таких как: удаление, свертка или любая бизнес-логика, которая должна манипулировать данными временных рядов.

Мы уже представляли TSL в предыдущем сообщении в блоге, в котором демонстрировалось, как наши клиенты используют доступные протоколы OVH Metrics, такие как Graphite, OpenTSDB, PromQL и WarpScript ™, но когда дело доходит до манипулирования или даже создания новых данных, у вас нет много вариантов, хотя вы можете использовать WarpScript ™ или TSL в качестве языка сценариев вместо запроса.

В большинстве случаев эта бизнес-логика требует создания приложения, которое требует больше времени, чем выражение логики в виде запроса, ориентированного на TSDB. Создание базового кода приложения — это первый шаг, за которым следует CI / CD (или любой процесс доставки) и настройка его мониторинга. Однако управление сотнями небольших приложений, подобных этим, увеличит органические затраты из-за необходимости поддерживать их вместе с базовой инфраструктурой.

Мы хотели, чтобы эти ценные задачи не возлагались на головы немногих разработчиков, которым затем нужно было бы нести ответственность за владение данными и вычислительные ресурсы, поэтому нам было интересно, как мы можем автоматизировать работу, не полагаясь на команду по настройке. вычислять работу каждый раз, когда кому-то нужно что-то.

Мы хотели найти решение, которое сфокусировалось бы на бизнес-логике, без необходимости запуска всего приложения. Таким образом, кому-то, желающему сгенерировать файл JSON с ежедневным отчетом о данных (например), нужно будет только выразить соответствующий запрос.



Вы не должны FaaS!
Планирование работы — старая, привычная рутина. Будь то bash cron, runner или специализированные планировщики, когда дело доходит до упаковки фрагмента кода и его периодической работы, существует имя для него: FaaS.

FaaS родился с простой целью: сократить время разработки. Мы могли бы найти реализацию с открытым исходным кодом для оценки (например, OpenFaas), но большинство из них полагались на управляемый стек контейнеров. Наличие одного контейнера на запрос было бы очень дорогостоящим, плюс разогрев контейнера для выполнения функции и последующее его замораживание было бы очень контрпродуктивным.

Это потребовало бы большего планирования и автоматизации, чем мы хотели для нашей конечной цели, привело бы к неоптимальной производительности и ввело бы новое требование для управления пропускной способностью кластера. Существует также время сборки, необходимое для развертывания новой функции в контейнере, которая, следовательно, не является бесплатной.

def Loops
Именно тогда мы решили создать «Loops»: платформу приложений, в которой вы можете запустить код, который хотите запустить. Это все. Цель состоит в том, чтобы выдвинуть функцию (буквально!), А не модуль, как это делают все текущие решения FaaS:

function dailyReport (event) {
    return Promise.resolve («Сегодня все хорошо!»)
}

Затем вы можете выполнить его вручную с помощью HTTP-вызова или Cron-подобного планировщика.
Оба эти аспекта необходимы, поскольку вы можете (например) иметь ежемесячный отчет, но для одного дня потребуется дополнительный, через 15 дней после последнего отчета. Циклы упростят создание вашего нового отчета вручную, в дополнение к ежемесячному.

Были некоторые необходимые ограничения, когда мы начали строить Loops:

• Эта платформа должна легко масштабироваться для поддержки производственной нагрузки OVH
• Это должно быть очень доступно
• Он должен быть независимым от языка, потому что некоторые из нас предпочитают Python, а другие JavaScript
• Это должно быть надежно
• Часть планирования не должна коррелировать с частью исполнения (культура µService)
• Он должен быть безопасным и изолированным, чтобы любой мог вставить неизвестный код на платформу.

Реализация циклов
Мы решили построить нашу первую версию на V8. Мы выбрали JavaScript в качестве первого языка, потому что он прост в изучении, а асинхронные потоки данных легко управляются с помощью Promises. Кроме того, он очень хорошо подходит для FaaS, так как функции Javascript очень выразительны. Мы создали его вокруг нового модуля VM NodeJS, который позволяет выполнять код в выделенном контексте V8.

Контекст V8 подобен объекту (JSON), изолированному от вашего исполнения. В контексте вы можете найти собственные функции и объекты. Однако, если вы создадите новый контекст V8, вы увидите, что некоторые переменные или функции не доступны изначально (например, setTimeout (), setInterval () или Buffer). Если вы хотите использовать их, вам придется добавить их в ваш новый контекст. Последнее, что нужно помнить, это то, что когда у вас есть новый контекст, вы можете легко выполнить сценарий JavaScript в строковой форме.

Контексты выполняют самую важную часть нашего первоначального списка требований: изоляция. Каждый контекст V8 изолирован, поэтому он не может общаться с другим контекстом. Это означает, что глобальная переменная, определенная в одном контексте, недоступна в другом. Вам нужно будет построить мост между ними, если вы хотите, чтобы это было так.

Мы не хотели выполнять сценарии с помощью eval (), поскольку вызов этой функции позволяет вам выполнять код JS в основном общем контексте с кодом, вызывающим его. После этого вы можете получить доступ к тем же объектам, константам, переменным и т. Д. Эта проблема безопасности стала нарушением условий для новой платформы.

Теперь мы знаем, как выполнять наши скрипты, давайте реализуем некоторое управление для них. Чтобы быть без сохранения состояния, каждый рабочий экземпляр Loops (то есть механизм JavaScript, способный выполнять код в контексте виртуальной машины) должен иметь последнюю версию каждого цикла (цикл — это скрипт для выполнения). Это означает, что когда пользователь запускает новый цикл, мы должны синхронизировать его с каждым рабочим цикла. Эта модель хорошо согласуется с парадигмой pub / sub, и, поскольку мы уже используем Kafka в качестве инфраструктуры pub / sub, нужно было просто создать отдельную тему и использовать ее у рабочих. В этом случае публикация включает API, где пользователь отправляет свои циклы, которые генерируют событие Kafka, содержащее тело функции. Поскольку у каждого работника есть своя собственная группа потребителей Kafka, они все получают одинаковые сообщения.

Рабочие подписываются на обновления Loops как потребители Kafka и поддерживают хранилище Loop, которое является встроенным ключом (хэш Loop) / Value (текущая версия функции). В части API хеши циклов используются в качестве параметров URL для определения того, какой цикл следует выполнить. После вызова цикл извлекается из карты, затем вводится в контексте V8, выполняется и удаляется. Этот механизм перезагрузки горячего кода гарантирует, что каждый цикл может выполняться на каждом работнике. Мы также можем использовать возможности наших балансировщиков нагрузки для распределения нагрузки на работников. Эта простая модель распределения позволяет избежать сложного планирования и облегчает обслуживание всей инфраструктуры.

Чтобы обеспечить защиту от перезагрузки, мы используем очень удобную функцию сжатия журналов Kafka. Сжатие журнала позволяет Kafka сохранять последнюю версию каждого ключевого сообщения. Когда пользователь создает новый цикл, ему дается уникальный идентификатор, который используется в качестве ключа сообщения Kafka. Когда пользователь обновляет цикл, это новое сообщение будет переслано всем потребителям, но, поскольку ключ уже существует, Kafka сохранит только последнюю ревизию. Когда работник перезапускается, он использует все сообщения для восстановления своего внутреннего KV, поэтому предыдущее состояние будет восстановлено. Кафка используется здесь как постоянный магазин.



Циклы выполнения
Даже если базовый движок способен запускать собственный Javascript, как указано выше, мы хотели, чтобы он выполнял более идиоматические запросы временных рядов, такие как TSL или WarpScript. Чтобы добиться этого, мы создали абстракцию Loops Runtime, которая оборачивает не только Javascript, но также запросы TSL и WarpScript в код Javascript. Пользователи должны объявлять цикл с его временем выполнения, после чего это просто вопрос работы упаковщиков. Например, выполнение цикла WarpScript подразумевает использование простого WarpScript ™ и его отправку через HTTP-вызов по запросу узла.


Петли обратной связи
Безопасное выполнение кода — это начало, но когда дело доходит до выполнения произвольного кода, также полезно получить некоторую обратную связь о состоянии выполнения. Это было успешно или нет? Есть ли ошибка в функции? Если цикл находится в состоянии сбоя, пользователь должен быть немедленно уведомлен.

Это приводит нас к одному особому условию: пользовательские скрипты должны быть в состоянии сказать, все ли в порядке или нет. Есть два способа сделать это в базовом движке JavaScript: обратные вызовы и обещания.
Мы решили использовать Promises, который предлагает лучшее асинхронное управление. Каждый цикл возвращает обещание в конце скрипта. Отклоненное обещание вызовет состояние ошибки HTTP 500, а разрешенное — HTTP 200.

Планирование циклов
При публикации Loops вы можете объявить несколько триггеров, аналогично Cron. Каждый триггер будет выполнять HTTP-вызов вашего цикла с необязательными параметрами.

Исходя из этой семантики, для генерации нескольких отчетов мы можем зарегистрировать одну функцию, которая будет планироваться в разных контекстах, определенных различными параметрами (регион, скорость). Смотрите пример ниже:

functions:
  warp_apps_by_cells:
    handler: apps-by-cells.mc2
    runtime: ws
    timeout: 30
    environment:
    events:
      - agra:
          rate: R/2018-01-01T00:00:00Z/PT5M/ET1M
          params:
            cell: ovh-a-gra
      - abhs:
          rate: R/2018-01-01T00:00:00Z/PT5M/ET1M
          params:
            cell: ovh-a-bhs

Планирование основано на Metronome, который является планировщиком событий с открытым исходным кодом, с особым акцентом на планирование, а не на выполнение. Он идеально подходит для Loops, поскольку Loops управляет выполнением, полагаясь на Metronome для управления вызовами выполнения.

Петли трубопроводов
Проект Loops может иметь несколько циклов. Одним из распространенных случаев использования наших клиентов было использование Loops в качестве платформы данных в режиме потока данных. Поток данных — это способ описать последовательность этапов выполнения. В контексте Loops существует глобальный объект `Loop`, который позволяет сценарию выполнить другой цикл с этим именем. Затем вы можете связать выполнение циклов, которые будут действовать как пошаговые функции.

Болевые точки: масштабирование приложения NodeJS
Рабочие циклов являются приложениями NodeJS. Большинство разработчиков NodeJS знают, что NodeJS использует однопоточный цикл обработки событий. Если вы не позаботитесь о поточной модели вашего приложения nodeJS, вы, скорее всего, пострадаете из-за нехватки производительности, поскольку будет использоваться только один хост-поток.

NodeJS также имеет модуль кластера, который позволяет приложению использовать несколько потоков. Вот почему в Loops-работнике мы начинаем с потока N-1 для обработки вызовов API, где N — общее количество доступных потоков, и один из них остается выделенным для основного потока.

Главный поток отвечает за использование тем Kafka и поддержку хранилища Loops, в то время как рабочий поток запускает сервер API. Для каждого запрошенного выполнения цикла он запрашивает у мастера содержимое скрипта и выполняет его в выделенном потоке.

При такой настройке на каждом сервере запускается одно приложение NodeJS с одним потребителем Kafka, что упрощает масштабирование инфраструктуры, просто добавляя дополнительные серверы или облачные экземпляры.

Заключение
В этой статье мы предварительно ознакомились с Loops, масштабируемым, ориентированным на метрики FaaS с собственной поддержкой JavaScript и расширенной поддержкой WarpScript и TSL.

У нас еще есть несколько вещей, которые нужно улучшить, например, импорт зависимостей в стиле ES5 и предварительный просмотр метрик для проектов Loops наших клиентов. Мы также планируем добавить дополнительные среды выполнения, особенно WASM, которые позволят многим другим языкам, на которые он может ориентироваться, таким как Go, Rust или Python, удовлетворять большинству предпочтений разработчика.

Платформа Loops была частью требования для создания высокоуровневых функций вокруг продуктов OVH Observability. Это первый шаг к предложению более автоматизированных услуг, таких как сведение показателей, конвейеры агрегации или средства извлечения логов в метрики.

Этот инструмент был создан из набора продуктов Observability с учетом более высокого уровня абстракции, но вам также может потребоваться прямой доступ к API, чтобы реализовать собственную автоматизированную логику для ваших метрик. Вы были бы заинтересованы в такой функции? Посетите наш канал Gitter, чтобы обсудить это с нами!

www.ovh.com/fr/blog/v8-hot-code-injection-for-continuous-queries/

Начиная с этой недели, новые облачные базы данных OVH основаны на высокопроизводительном SSD-накопителе NVMe.

Интерес имеет два аспекта:

• Прибыль в выступлениях (чтениях / письмах). После теста FIO мы сделали скачок вперед, и я обнаружил, что около 20 000 IOPS постоянно.
• Что говорит о лучшей производительности, означает больше возможностей для ваших баз для управления запросами. Как правило, это уменьшает потребление оперативной памяти, и, следовательно, уменьшает OOMKill

Мы не забываем существующих клиентов и базы данных! В ближайшие недели мы переходим на новый техно каждый день. Конец оценивается в мае.
Не планирую разглашать. Чтобы выяснить, мигрировали ли вы уже, вы можете посмотреть на своего «Хоста» в клиентской области, он должен быть на 007
Пример: «dbaas002.sql007»

Задача работает: travaux.ovh.net/?do=details&id=37809

Изменений тарифов не ожидается, ни для новостей, ни для существующих.
Облачные базы данных: www.ovh.com/en/cloud/cloud-databases/