New INFv2 AI
- 1 server with 1 CPU with 3x Nvidia GPU and the waterclick
- 850W per server
- 48 servers per rack
- 40KW per rack
Waterblock 1800W (6x 300W)
От 15 000 подключений к базам данных до 100: история о долговых обязательствах DigitalOcean
Недавно за обедом меня попросил новый сотрудник: «Как выглядит технический долг DigitalOcean?»
Я не мог удержаться от улыбки, когда услышал вопрос. Инженеры-программисты, спрашивающие о техническом долге компании, равносильны задаче о кредитном балле. Это их способ оценить сомнительное прошлое компании и то, какой багаж они несут. И DigitalOcean не привыкать к техническому багажу.
Как поставщик облачных услуг, который управляет нашими собственными серверами и оборудованием, мы столкнулись с трудностями, с которыми многие другие стартапы не сталкивались в эту новую эру облачных вычислений. Эти сложные ситуации в конечном итоге привели к компромиссам, которые мы должны были сделать в самом начале нашего существования. И, как известно любой быстро растущей компании, технические решения, которые вы принимаете на раннем этапе, как правило, догоняют вас позже.
Глядя на новый прокат через стол, я глубоко вздохнул и начал. «Позвольте мне рассказать вам о времени, когда у нас было 15 000 прямых подключений к нашей базе данных…»
История, которую я рассказал нашему новобранцу, — это история крупнейшей на сегодняшний день технической реархитектуры DigitalOcean. Это было усилие всей компании, которое длилось несколько лет и преподало нам много уроков. Надеюсь, что это поможет будущим разработчикам DigitalOcean — или любым разработчикам, попавшим в непростую головоломку с техническими проблемами.
С чего все началось
DigitalOcean был одержим простотой с самого начала. Это одна из наших основных ценностей: стремиться к простым и элегантным решениям. Это относится не только к нашей продукции, но и к нашим техническим решениям. Нигде это так заметно, как в нашей первоначальной конструкции системы.
Как и GitHub, Shopify и Airbnb, DigitalOcean была запущена как приложение Rails в 2011 году. Приложение Rails, внутренне известное как Cloud, управляло всеми взаимодействиями пользователей как в пользовательском интерфейсе, так и в открытом API. В оказании помощи Rails работали две службы Perl: планировщик и DOBE (DigitalOcean BackEnd). Планировщик планировал и назначал Droplets гипервизорам, а DOBE отвечал за создание реальных виртуальных машин Droplet. В то время как облако и планировщик работали как отдельные службы, DOBE работал на каждом сервере в парке.
Ни Cloud, ни Scheduler, ни DOBE не общались напрямую друг с другом. Они общались через базу данных MySQL. Эта база данных выполняла две функции: хранение данных и посредничество в общении. Все три службы использовали одну таблицу базы данных в качестве очереди сообщений для передачи информации.
Каждый раз, когда пользователь создавал новую каплю, Cloud вставлял новую запись события в очередь. Планировщик непрерывно опрашивает базу данных каждую секунду на предмет новых событий Droplet и планирует их создание на доступном гипервизоре. Наконец, каждый экземпляр DOBE будет ожидать создания новых запланированных капель и выполнения задачи. Чтобы эти серверы могли обнаружить какие-либо новые изменения, каждый из них должен будет опросить базу данных на предмет новых записей в таблице.
Хотя бесконечные циклы и предоставление каждому серверу прямого подключения к базе данных, возможно, были элементарными с точки зрения проектирования системы, это было просто, и это работало — особенно для технической команды с небольшим персоналом, работающей в сжатые сроки и быстро растущей пользовательской базы.
В течение четырех лет очередь сообщений базы данных составляла основу технологического стека DigitalOcean. В течение этого периода мы приняли микросервисную архитектуру, заменили HTTPS на gRPC для внутреннего трафика и вытеснили Perl в пользу Golang для внутренних сервисов. Однако все дороги все еще вели к этой базе данных MySQL.
Важно отметить, что просто потому, что что-то является «наследием», не означает, что оно не функционирует и должно быть заменено. Bloomberg и IBM имеют устаревшие сервисы, написанные на Fortran и COBOL, которые приносят больший доход, чем целые компании. С другой стороны, каждая система имеет предел масштабирования. И мы собирались ударить наших.
С 2012 по 2016 год пользовательский трафик DigitalOcean вырос более чем на 10 000%. Мы добавили больше продуктов в наш каталог и услуг для нашей инфраструктуры. Это увеличило вход событий в очередь сообщений базы данных. Повышенный спрос на Droplets означал, что планировщик работал сверхурочно, чтобы назначить их всем серверам. И, к сожалению, для Планировщика, количество доступных серверов не было статичным.
Чтобы не отставать от возросшего спроса на капли, мы добавляли все больше и больше серверов для обработки трафика. Каждый новый гипервизор означал другое постоянное соединение с базой данных. К началу 2016 года база данных имела более 15 000 прямых соединений, каждое из которых запрашивало новые события каждые одну-пять секунд. Если это было не так уж плохо, SQL-запрос, который каждый гипервизор использовал для извлечения новых событий Droplet, также усложнялся. Он стал колоссом длиной более 150 строк и присоединился к 18 столам. Это было столь же внушительно, как это было ненадежно и трудно поддержать.
Неудивительно, что именно в этот период начали появляться трещины. Единственная точка отказа с тысячами зависимостей, захваченных общими ресурсами, неизбежно приводила к периодам хаоса. Блокировки таблиц и задержки запросов привели к сбоям и снижению производительности.
И из-за тесной связи в системе не было четкого или простого решения проблем. Облако, планировщик и DOBE — узкие места. Исправление только одного или двух компонентов только сместит нагрузку на оставшиеся узкие места. Поэтому после долгих размышлений инженерный персонал разработал трехэтапный план исправления ситуации:
После запуска Event Router количество подключений к базе данных сократилось с 15 000 до менее 100.
Далее инженеры нацеливаются на следующую цель: планировщик. Как упоминалось ранее, Scheduler был Perl-скриптом, который определял, какой гипервизор будет содержать созданную каплю. Это было сделано с помощью ряда запросов для ранжирования и сортировки серверов. Каждый раз, когда пользователь создавал дроплет, планировщик обновлял строку таблицы, выбирая лучший компьютер.
Хотя это звучит достаточно просто, у Scheduler было несколько недостатков. Его логика была сложной и сложной для работы. Он был однопоточным, и его производительность пострадала во время пиковой нагрузки. Наконец, был только один экземпляр планировщика — и он должен был обслуживать весь флот. Это было неизбежное узкое место. Чтобы решить эти проблемы, команда разработчиков создала Scheduler V2.
Обновленный планировщик полностью обновил систему ранжирования. Вместо того, чтобы запрашивать базу данных для метрик сервера, он собирал их из гипервизоров и сохранял их в своей собственной базе данных. Кроме того, команда планировщика использовала параллелизм и репликацию, чтобы сделать свою новую службу эффективной под нагрузкой.
Event Router и Scheduler v2 были большими достижениями, которые устраняли многие архитектурные недостатки. Несмотря на это, было явное препятствие. Централизованная очередь сообщений MySQL все еще использовалась — даже суетливо — к началу 2017 года. Она обрабатывала до 400 000 новых записей в день и 20 обновлений в секунду.
К сожалению, удаление очереди сообщений базы данных было нелегким делом. Первым шагом было предотвращение прямого доступа к сервисам. База данных нуждалась в уровне абстракции. И ему нужен API для агрегирования запросов и выполнения запросов от его имени. Если какой-либо сервис хочет создать новое событие, он должен сделать это через API. И вот, Гарпун родился.
Однако создание интерфейса для очереди событий было легкой задачей. Получить бай-ин от других команд оказалось сложнее. Интеграция с Harpoon означала, что командам придется отказаться от доступа к базе данных, переписать части своей кодовой базы и в конечном итоге изменить то, как они всегда делали что-то. Это было нелегко продать.
Команда за командой и сервис за сервисом, инженеры Harpoon смогли перенести всю кодовую базу на свою новую платформу. Это заняло лучшую часть года, но к концу 2017 года Harpoon стал единственным издателем в очереди сообщений базы данных.
Теперь настоящая работа началась. Полный контроль над системой событий означал, что у Harpoon была возможность заново изобрести рабочий процесс Droplet.
Первая задача Гарпуна состояла в том, чтобы извлечь из базы данных обязанности очереди сообщений. Для этого Harpoon создал собственную внутреннюю очередь сообщений, состоящую из RabbitMQ и асинхронных рабочих. Когда Гарпун выдвинул новые события в очередь с одной стороны, рабочие вытянули их с другой. И так как RabbitMQ заменил очередь базы данных, работники могли свободно общаться непосредственно с Планировщиком и Маршрутизатором событий. Таким образом, вместо того, чтобы Scheduler V2 и Event Router опрашивали новые изменения в базе данных, Harpoon отправлял обновления прямо в них. На момент написания статьи в 2019 году именно здесь находится архитектура событий Droplet.
За последние семь лет DigitalOcean выросла из корней гаражных групп в признанного поставщика облачных услуг, которым она является сегодня. Как и другие переходные технологические компании, DigitalOcean регулярно занимается устаревшим кодом и техническими долгами. Независимо от того, разбиваете ли вы монолиты, создаете многорегиональные сервисы или устраняете отдельные точки отказа, мы, инженеры DigitalOcean, всегда работаем над созданием элегантных и простых решений.
Я надеюсь, что эта история о том, как наша инфраструктура масштабировалась с нашей базой пользователей, была интересной и яркой. Я хотел бы услышать ваши мысли в комментариях ниже!
Я не мог удержаться от улыбки, когда услышал вопрос. Инженеры-программисты, спрашивающие о техническом долге компании, равносильны задаче о кредитном балле. Это их способ оценить сомнительное прошлое компании и то, какой багаж они несут. И DigitalOcean не привыкать к техническому багажу.
Как поставщик облачных услуг, который управляет нашими собственными серверами и оборудованием, мы столкнулись с трудностями, с которыми многие другие стартапы не сталкивались в эту новую эру облачных вычислений. Эти сложные ситуации в конечном итоге привели к компромиссам, которые мы должны были сделать в самом начале нашего существования. И, как известно любой быстро растущей компании, технические решения, которые вы принимаете на раннем этапе, как правило, догоняют вас позже.
Глядя на новый прокат через стол, я глубоко вздохнул и начал. «Позвольте мне рассказать вам о времени, когда у нас было 15 000 прямых подключений к нашей базе данных…»
История, которую я рассказал нашему новобранцу, — это история крупнейшей на сегодняшний день технической реархитектуры DigitalOcean. Это было усилие всей компании, которое длилось несколько лет и преподало нам много уроков. Надеюсь, что это поможет будущим разработчикам DigitalOcean — или любым разработчикам, попавшим в непростую головоломку с техническими проблемами.
С чего все началось
DigitalOcean был одержим простотой с самого начала. Это одна из наших основных ценностей: стремиться к простым и элегантным решениям. Это относится не только к нашей продукции, но и к нашим техническим решениям. Нигде это так заметно, как в нашей первоначальной конструкции системы.
Как и GitHub, Shopify и Airbnb, DigitalOcean была запущена как приложение Rails в 2011 году. Приложение Rails, внутренне известное как Cloud, управляло всеми взаимодействиями пользователей как в пользовательском интерфейсе, так и в открытом API. В оказании помощи Rails работали две службы Perl: планировщик и DOBE (DigitalOcean BackEnd). Планировщик планировал и назначал Droplets гипервизорам, а DOBE отвечал за создание реальных виртуальных машин Droplet. В то время как облако и планировщик работали как отдельные службы, DOBE работал на каждом сервере в парке.
Ни Cloud, ни Scheduler, ни DOBE не общались напрямую друг с другом. Они общались через базу данных MySQL. Эта база данных выполняла две функции: хранение данных и посредничество в общении. Все три службы использовали одну таблицу базы данных в качестве очереди сообщений для передачи информации.
Каждый раз, когда пользователь создавал новую каплю, Cloud вставлял новую запись события в очередь. Планировщик непрерывно опрашивает базу данных каждую секунду на предмет новых событий Droplet и планирует их создание на доступном гипервизоре. Наконец, каждый экземпляр DOBE будет ожидать создания новых запланированных капель и выполнения задачи. Чтобы эти серверы могли обнаружить какие-либо новые изменения, каждый из них должен будет опросить базу данных на предмет новых записей в таблице.
Хотя бесконечные циклы и предоставление каждому серверу прямого подключения к базе данных, возможно, были элементарными с точки зрения проектирования системы, это было просто, и это работало — особенно для технической команды с небольшим персоналом, работающей в сжатые сроки и быстро растущей пользовательской базы.
В течение четырех лет очередь сообщений базы данных составляла основу технологического стека DigitalOcean. В течение этого периода мы приняли микросервисную архитектуру, заменили HTTPS на gRPC для внутреннего трафика и вытеснили Perl в пользу Golang для внутренних сервисов. Однако все дороги все еще вели к этой базе данных MySQL.
Важно отметить, что просто потому, что что-то является «наследием», не означает, что оно не функционирует и должно быть заменено. Bloomberg и IBM имеют устаревшие сервисы, написанные на Fortran и COBOL, которые приносят больший доход, чем целые компании. С другой стороны, каждая система имеет предел масштабирования. И мы собирались ударить наших.
С 2012 по 2016 год пользовательский трафик DigitalOcean вырос более чем на 10 000%. Мы добавили больше продуктов в наш каталог и услуг для нашей инфраструктуры. Это увеличило вход событий в очередь сообщений базы данных. Повышенный спрос на Droplets означал, что планировщик работал сверхурочно, чтобы назначить их всем серверам. И, к сожалению, для Планировщика, количество доступных серверов не было статичным.
Чтобы не отставать от возросшего спроса на капли, мы добавляли все больше и больше серверов для обработки трафика. Каждый новый гипервизор означал другое постоянное соединение с базой данных. К началу 2016 года база данных имела более 15 000 прямых соединений, каждое из которых запрашивало новые события каждые одну-пять секунд. Если это было не так уж плохо, SQL-запрос, который каждый гипервизор использовал для извлечения новых событий Droplet, также усложнялся. Он стал колоссом длиной более 150 строк и присоединился к 18 столам. Это было столь же внушительно, как это было ненадежно и трудно поддержать.
Неудивительно, что именно в этот период начали появляться трещины. Единственная точка отказа с тысячами зависимостей, захваченных общими ресурсами, неизбежно приводила к периодам хаоса. Блокировки таблиц и задержки запросов привели к сбоям и снижению производительности.
И из-за тесной связи в системе не было четкого или простого решения проблем. Облако, планировщик и DOBE — узкие места. Исправление только одного или двух компонентов только сместит нагрузку на оставшиеся узкие места. Поэтому после долгих размышлений инженерный персонал разработал трехэтапный план исправления ситуации:
- Уменьшить количество прямых соединений с базой данных
- Алгоритм ранжирования Refactor Scheduler для повышения доступности
- Освободить базу данных от своих обязанностей в очереди сообщений
- Рефакторинг начинается
После запуска Event Router количество подключений к базе данных сократилось с 15 000 до менее 100.
Далее инженеры нацеливаются на следующую цель: планировщик. Как упоминалось ранее, Scheduler был Perl-скриптом, который определял, какой гипервизор будет содержать созданную каплю. Это было сделано с помощью ряда запросов для ранжирования и сортировки серверов. Каждый раз, когда пользователь создавал дроплет, планировщик обновлял строку таблицы, выбирая лучший компьютер.
Хотя это звучит достаточно просто, у Scheduler было несколько недостатков. Его логика была сложной и сложной для работы. Он был однопоточным, и его производительность пострадала во время пиковой нагрузки. Наконец, был только один экземпляр планировщика — и он должен был обслуживать весь флот. Это было неизбежное узкое место. Чтобы решить эти проблемы, команда разработчиков создала Scheduler V2.
Обновленный планировщик полностью обновил систему ранжирования. Вместо того, чтобы запрашивать базу данных для метрик сервера, он собирал их из гипервизоров и сохранял их в своей собственной базе данных. Кроме того, команда планировщика использовала параллелизм и репликацию, чтобы сделать свою новую службу эффективной под нагрузкой.
Event Router и Scheduler v2 были большими достижениями, которые устраняли многие архитектурные недостатки. Несмотря на это, было явное препятствие. Централизованная очередь сообщений MySQL все еще использовалась — даже суетливо — к началу 2017 года. Она обрабатывала до 400 000 новых записей в день и 20 обновлений в секунду.
К сожалению, удаление очереди сообщений базы данных было нелегким делом. Первым шагом было предотвращение прямого доступа к сервисам. База данных нуждалась в уровне абстракции. И ему нужен API для агрегирования запросов и выполнения запросов от его имени. Если какой-либо сервис хочет создать новое событие, он должен сделать это через API. И вот, Гарпун родился.
Однако создание интерфейса для очереди событий было легкой задачей. Получить бай-ин от других команд оказалось сложнее. Интеграция с Harpoon означала, что командам придется отказаться от доступа к базе данных, переписать части своей кодовой базы и в конечном итоге изменить то, как они всегда делали что-то. Это было нелегко продать.
Команда за командой и сервис за сервисом, инженеры Harpoon смогли перенести всю кодовую базу на свою новую платформу. Это заняло лучшую часть года, но к концу 2017 года Harpoon стал единственным издателем в очереди сообщений базы данных.
Теперь настоящая работа началась. Полный контроль над системой событий означал, что у Harpoon была возможность заново изобрести рабочий процесс Droplet.
Первая задача Гарпуна состояла в том, чтобы извлечь из базы данных обязанности очереди сообщений. Для этого Harpoon создал собственную внутреннюю очередь сообщений, состоящую из RabbitMQ и асинхронных рабочих. Когда Гарпун выдвинул новые события в очередь с одной стороны, рабочие вытянули их с другой. И так как RabbitMQ заменил очередь базы данных, работники могли свободно общаться непосредственно с Планировщиком и Маршрутизатором событий. Таким образом, вместо того, чтобы Scheduler V2 и Event Router опрашивали новые изменения в базе данных, Harpoon отправлял обновления прямо в них. На момент написания статьи в 2019 году именно здесь находится архитектура событий Droplet.
За последние семь лет DigitalOcean выросла из корней гаражных групп в признанного поставщика облачных услуг, которым она является сегодня. Как и другие переходные технологические компании, DigitalOcean регулярно занимается устаревшим кодом и техническими долгами. Независимо от того, разбиваете ли вы монолиты, создаете многорегиональные сервисы или устраняете отдельные точки отказа, мы, инженеры DigitalOcean, всегда работаем над созданием элегантных и простых решений.
Я надеюсь, что эта история о том, как наша инфраструктура масштабировалась с нашей базой пользователей, была интересной и яркой. Я хотел бы услышать ваши мысли в комментариях ниже!
https://www.digitalocean.com
Повышение производительности с помощью балансировщиков нагрузки Vultr
Мы рады сообщить, что Vultr Load Balancers доступны с сегодняшнего дня. Доступно во всех 16 регионах центров обработки данных, добавление высокой доступности и масштабирование ваших приложений по всему миру стало еще проще с Vultr Load Balancers! Используя наше полностью сконфигурированное решение, вы можете упростить управление растущими приложениями, не управляя собственной инфраструктурой балансировки нагрузки.
Избыточная архитектура обеспечивает гибкий способ добавления мониторинга работоспособности и высокой доступности ваших приложений с легкостью. Вы также можете легко масштабировать свои приложения и услуги по горизонтали и удовлетворять растущие потребности всего несколькими щелчками мыши. Самое главное, что все ваши кластеры балансировки нагрузки могут легко управляться с помощью нашего удобного пользовательского портала и API Vultr.
Балансировщики нагрузки Vultr предоставляют множество функций в одном удобном пакете, в том числе:
- Несколько алгоритмов балансировки трафика
- Поддержка TCP, HTTP и HTTPS.
- Проверка работоспособности, чтобы убедиться, что трафик направляется только на исправные узлы.
- Автоматическое аварийное переключение, поэтому вам не нужно беспокоиться о простоях
- Подробные метрики кластера
Хотя мы включили много функций в наш первоначальный выпуск, дополнительные обновления будут добавлены в ближайшее время. В ближайшие недели мы добавим поддержку IPv6, SSL через Lets Encrypt, поддержку нашего клиента Go и JavaScript, а также terraform и vultr-cli, дополнительные протоколы и многое другое!
Готовы начать? Посетите страницу балансировщиков нагрузки, чтобы развернуть свою собственную. Вы также можете ознакомиться с нашей документацией по балансировщикам нагрузки, в которой объясняется, как работают балансировщики нагрузки.
www.vultr.com/products/load-balancers/
www.vultr.com/docs/vultr-load-balancers
http://www.vultr.com
Managed Databases в Selectel: приглашаем в бету
Сегодня мы представляем открытую для тестирования бета-версию Managed Databases для PostgreSQL, использование которой будет бесплатным на период бета-тестирования.
Базы данных — один из наиболее значимых и сложных компонентов любой информационной системы или приложения. Процессы создания, конфигурации баз данных и управления ими, выполняемые вручную, могут занимать недели или даже месяцы.
С ростом бизнеса, что ведет за собой рост инфраструктуры, требуется обеспечивать масштабируемость баз данных. При этом, их надежность и отказоустойчивость ставятся на первое место, ведь от этого зависит доступность оказываемого сервиса. Реализация этих требований отнимает драгоценное время на решение бизнес-задач и развитие ваших приложений. К тому же, у компании не всегда есть время, деньги и квалифицированные специалисты для решения этих задач.
Вот почему мы решили создать полностью автоматизированный сервис по управлению базами данных Managed Databases, благодаря которому вы сможете сфокусироваться на развитии вашего бизнеса, а не на обслуживании инфраструктуры.
selectel.ru/blog/dbaas-beta/
Серверы от 2 500 руб
Они уже здесь. Лучшие предложения января в этом письме. Даже если в данный момент вам не нужен сервер, он может внезапно понадобиться. Да, такое бывает. Знайте, что у нас всегда есть что предложить. Мы подберем нужное железо или облако по выгодной цене, соберем индивидуальную конфигурацию и организуем сервер под выкуп. Смело обращайтесь, мы любим подбирать и собирать сервера.
Специальные предложения января:
- HP Proliant DL160 G6 2хIntel Xeon E5620 2,4 Ггц (8 ядер) с оперативной памятью 8 Гб и дисками 2 x 1000 Гб SATA → 4 100 ₽
- Supermicro 2х Intel Xeon X5660 2,8 Ггц (12 ядер) с оперативной памятью 16 Гб и диском 256 Гб SSD → 6 280 ₽
- HP DL360p Gen8 Intel Xeon E5-2680v2 2,8 Ггц (10 ядер) с оперативной памятью 32 Гб и дисками 2 x 500 Гб SSD + RAID P420i → 11 500 ₽
В стоимость сервера уже входит:
- ✔️ Установка и первичная настройка,
- ✔️ Безлимитный интернет 100 Мбит/сек.,
- ✔️Адрес IPv4, предоставление IPMI на первые 3 дня.
- ⏱ Выделим сервер за 2 часа.
- ⚠️ Количество серверов по акции ограничено.
- ✔️ Улучшим выбранную конфигурацию.
- ✔️ Организуем сервер под выкуп.
Новая метрика на StatOnline.ru для хостинг-провайдеров: оценка скорости отклика сайтов
REG.RU представляет новую метрику аналитического сервиса StatOnline.ru. На сайте впервые систематизирован сбор данных о скорости загрузки сайтов клиентов хостинг-провайдеров, работающих в России. Метрика обновляется ежемесячно. Кроме того, дополнена метрика Uptime: появилась информация о времени простоя хостинг-провайдеров.
Среднее суммарное время отклика сайтов, размещённых у хостинг-провайдера, — важный параметр, который влияет на удобство использования интернет-ресурса. Например, отклик в 0,1 сек можно считать идеальным показателем загрузки. Значения от 0,1 до 1 сек считаются приемлемыми. Однако более долгая загрузка страницы приводит к тому, что пользователь теряет ощущение непрерывной и стабильной работы сайта, а поисковые системы не дают такому ресурсу максимальную оценку и пессимизируют в поисковой выдаче. Пределом удержания внимания считается показатель 10 сек.
Новая метрика REG.RU на StatOnline.ru показывает ежемесячную оценку скорости загрузки сайтов, размещённых у российских хостинг-провайдеров. Ранее эта статистика собиралась в виде единичных тестов, в которых чаще всего участвовали один-два сайта, что снижает релевантность подобных исследований. Теперь же полноценный обзор становится доступен как пользователям, так и провайдерам, которые смогут отслеживать свои показатели и улучшать работу услуг и сервисов.
Как формируется метрика
Каждый месяц аналитический сервис составляет список из 20 крупнейших хостинг-провайдеров — они определяются исходя из числа находящихся на обслуживании провайдера доменов в зоне .RU. После этого собираются данные IP-адресов, принадлежащих серверам shared-хостинга каждого провайдера. Затем для всех IP-адресов shared-хостинга создаётся список случайно выбранных сайтов: по два сайта на CMS WordPress, Joomla и «1C-Битрикс» (самые популярные CMS для сайтов в .RU). Для всех ресурсов один раз в 20 минут измеряется время отклика с помощью команды curl %{time_total}. Отчёт составляется исходя из накопленной статистики.
Лидеры декабря
В декабре первое место занял провайдер RU-CENTER с показателем скорости 0,262831 сек. REG.RU расположился в рейтинге на третьем месте — 0,346264 сек. Также в топ-5 оказались провайдеры Hc.ru, «Джино» и «Гарант-Парк-Телеком».
Обновление метрики Uptime
В метрике Uptime появились данные о простое хостинг-провайдеров. В минутах указано среднее время недоступности серверов провайдера за месяц. Основываясь на метрике, пользователи смогут выбирать наиболее надёжных поставщиков услуг для устойчивой работы сайтов и сервисов.
statonline.ru/metrics/hosting_uptime?tld=ru&month=2019-12
REG.RU — хостинг-провайдер и аккредитованный регистратор доменных имён №1 в России (по данным StatOnline.ru, занимает первое место по количеству зарегистрированных доменов и размещённых сайтов в национальных зонах .RU и.РФ). Компания обслуживает более 3 300 000 доменов и предлагает регистрацию в 750 международных доменных зонах, а также предоставляет услуги хостинга, SSL, почты, VPS, аренды физических серверов и облачных вычислений на GPU. В 2012 году REG.RU стал аккредитованным ICANN регистратором. Офисы REG.RU расположены в 30 городах России и СНГ.
Среднее суммарное время отклика сайтов, размещённых у хостинг-провайдера, — важный параметр, который влияет на удобство использования интернет-ресурса. Например, отклик в 0,1 сек можно считать идеальным показателем загрузки. Значения от 0,1 до 1 сек считаются приемлемыми. Однако более долгая загрузка страницы приводит к тому, что пользователь теряет ощущение непрерывной и стабильной работы сайта, а поисковые системы не дают такому ресурсу максимальную оценку и пессимизируют в поисковой выдаче. Пределом удержания внимания считается показатель 10 сек.
Новая метрика REG.RU на StatOnline.ru показывает ежемесячную оценку скорости загрузки сайтов, размещённых у российских хостинг-провайдеров. Ранее эта статистика собиралась в виде единичных тестов, в которых чаще всего участвовали один-два сайта, что снижает релевантность подобных исследований. Теперь же полноценный обзор становится доступен как пользователям, так и провайдерам, которые смогут отслеживать свои показатели и улучшать работу услуг и сервисов.
Как формируется метрика
Каждый месяц аналитический сервис составляет список из 20 крупнейших хостинг-провайдеров — они определяются исходя из числа находящихся на обслуживании провайдера доменов в зоне .RU. После этого собираются данные IP-адресов, принадлежащих серверам shared-хостинга каждого провайдера. Затем для всех IP-адресов shared-хостинга создаётся список случайно выбранных сайтов: по два сайта на CMS WordPress, Joomla и «1C-Битрикс» (самые популярные CMS для сайтов в .RU). Для всех ресурсов один раз в 20 минут измеряется время отклика с помощью команды curl %{time_total}. Отчёт составляется исходя из накопленной статистики.
Лидеры декабря
В декабре первое место занял провайдер RU-CENTER с показателем скорости 0,262831 сек. REG.RU расположился в рейтинге на третьем месте — 0,346264 сек. Также в топ-5 оказались провайдеры Hc.ru, «Джино» и «Гарант-Парк-Телеком».
Обновление метрики Uptime
В метрике Uptime появились данные о простое хостинг-провайдеров. В минутах указано среднее время недоступности серверов провайдера за месяц. Основываясь на метрике, пользователи смогут выбирать наиболее надёжных поставщиков услуг для устойчивой работы сайтов и сервисов.
statonline.ru/metrics/hosting_uptime?tld=ru&month=2019-12
Новые метрики StatOnline открывают хостинг-провайдерам перспективы для роста, а клиентам — информацию для ориентации в качестве оказываемых услуг на рынке. Чем дальше мы движемся, тем больше показателей стремимся улучшить — это позволяет постоянно поддерживать качество услуг на высочайшем уровнекомментирует Алексей Королюк, генеральный директор хостинг-провайдера и регистратора доменов REG.RU.
REG.RU — хостинг-провайдер и аккредитованный регистратор доменных имён №1 в России (по данным StatOnline.ru, занимает первое место по количеству зарегистрированных доменов и размещённых сайтов в национальных зонах .RU и.РФ). Компания обслуживает более 3 300 000 доменов и предлагает регистрацию в 750 международных доменных зонах, а также предоставляет услуги хостинга, SSL, почты, VPS, аренды физических серверов и облачных вычислений на GPU. В 2012 году REG.RU стал аккредитованным ICANN регистратором. Офисы REG.RU расположены в 30 городах России и СНГ.
Использование FPGA в рабочем процессе гибкой разработки
OVHcloud недавно получил новое имя, чтобы подчеркнуть его направленность: облако, чтобы дать вам возможность легко выполнять свои рабочие нагрузки, не слишком заботясь о базовом оборудовании. Так зачем говорить о ПЛИС?
FPGA — это аппаратный ускоритель, реконфигурируемая микросхема, которая может вести себя как обычный кремний, разработанная для конкретного применения. Мы используем FPGA в качестве пользовательских сетевых устройств для нашей системы защиты от атак. Но разработка FPGA сильно отличается от разработки программного обеспечения: она требует специализированного проприетарного программного обеспечения и длительных циклов разработки.
В этой статье я хотел бы сосредоточиться на том, как мы интегрируем разработку FPGA в рабочий процесс гибкой разработки программного обеспечения, используемый всеми другими разработчиками в OVHcloud.
Зачем использовать?
ПЛИС являются чрезвычайно общими микросхемами, их можно использовать для построения схем для очень широкого спектра применений:
Для сетевых приложений преимуществами являются:
Чтобы узнать больше о FPGA, электронные книги FPGA For Dummies — это хороший ресурс.
Традиционный рабочий процесс разработки FPGA
Языки, используемые для разработки на ПЛИС, имеют сильную специфику: в отличие от стандартных последовательных языков, все происходит параллельно, чтобы моделировать поведение миллионов транзисторов, работающих параллельно на микросхеме. Используются два основных языка: VHDL и SystemVerilog. Мы используем SystemVerilog. Вот пример модуля SystemVerilog:
Модули можно объединять, соединяя их входы и выходы для создания сложных систем.
Тестирование на симуляторе
Очень важным инструментом при разработке на ПЛИС является симулятор: он сложный и медленный для тестирования кода непосредственно на реальной ПЛИС. Чтобы ускорить процесс, симуляторы могут запускать код без специального оборудования. Они используются как для модульных тестов, для тестирования каждого модуля в отдельности, так и для функциональных тестов, имитирующих всю конструкцию, контролирующих его входы и проверяющих его выходы. Вот результат на счетчик модуля:
Симулятор модуля счетчика
Это волна, показывающая значение каждого сигнала в каждом тактовом цикле. Конечно, симулятор также может работать без головы, а тестовая среда может быть модифицирована для возврата результата «пройдено / не пройдено».
Базовый симулятор предоставлен Xilinx, производителем FPGA. Более продвинутые симуляторы предоставляются Mentor или Synopsys. Эти симуляторы являются коммерческими и требуют дорогих лицензий.
Сборка двоичного файла
После того, как все тесты пройдены, пришло время получить двоичный файл, который можно использовать для настройки FPGA. Крупнейшие поставщики FPGA, Intel и Xilinx, предоставляют собственные инструменты для этого процесса. Первый этап, синтез, преобразует исходный код в схему. Второй этап, «место и маршрут», представляет собой очень сложную задачу оптимизации, позволяющую приспособить схему к ресурсам, предоставляемым ПЛИС, при соблюдении временных ограничений, чтобы схема могла работать на требуемой частоте. Это может длиться несколько часов, даже до одного дня на очень сложных конструкциях. Этот процесс может завершиться ошибкой, если дизайн слишком ограничен, поэтому обычно приходится запускать несколько процессов с разными начальными значениями, чтобы в конце было больше шансов получить рабочий двоичный файл.
Наш текущий рабочий процесс разработки FPGA
Наш текущий процесс разработки очень близок к традиционному. Но обычно разработка FPGA намного медленнее, чем разработка программного обеспечения. В OVHcloud мы можем разработать и отправить небольшую функцию за один день. Мы достигаем этого, используя рабочий процесс, используемый разработчиками программного обеспечения, и используя нашу облачную инфраструктуру. Вот глобальный рабочий процесс:
Весь рабочий процесс контролируется CDS, нашей системой непрерывной доставки с открытым исходным кодом. Все тесты, а также задания по компиляции выполняются в Public Cloud, кроме тестов на борту, которые проводятся в нашей лаборатории.
Используя наше публичное облако
Настройка всех машин выполняется Ansible. Есть несколько важных ролей для установки различных важных компонентов:
Сервер лицензий для симулятора и компиляторов
Сервер лицензий, а также блоки разработки — это долго работающие экземпляры Public Cloud. Сервер лицензий — это наименьший возможный экземпляр, блок разработки — это экземпляр с быстрым ЦП и большим объемом оперативной памяти. Симулятор и компиляторы установлены на блоке разработки. Полномочия на доступ к серверу лицензий управляются с помощью групп безопасности OpenStack.
Экземпляры, используемые для смоделированных тестов и для компиляции, запускаются с использованием API OpenStack, когда это необходимо. Это очень важно, потому что позволяет параллельно запускать несколько наборов тестов для разных разработчиков. Это также очень важно для компиляции. Мы компилируем наши проекты для нескольких целей (FPGA Stratix V для 10G и FPGA Ultrascale + для 100G), поэтому нам необходимо выполнять несколько заданий компиляции параллельно. Кроме того, мы выполняем задания параллельно с несколькими начальными числами, чтобы повысить наши шансы получить правильный двоичный файл. Поскольку в наших проектах задания на сборку могут длиться 12 часов, очень важно начать достаточно параллельно, чтобы быть уверенным, что мы получим хотя бы один работающий двоичный файл.
Запуск тестов
Функциональные тесты очень важны, потому что они проверяют каждую функцию, которую предоставляют наши разработки. Тесты разработаны на Python с использованием scapy для отправки трафика и анализа результатов. Они могут работать с имитацией дизайна или с реальным дизайном на реальных платах ПЛИС. CDS может автоматически запускать тесты на реальных платах, бронируя лабораторные серверы и подключаясь к ним через SSH. Тот же процесс используется для тестирования производительности.
Результатом этой инфраструктуры является то, что разработчики могут добавить новую функцию в ветку нашего репозитория git, и они получат полные результаты модульных и функциональных тестов через 30 минут. Если все в порядке, они могут запустить компиляцию и проверить результат на борту на следующий день. Тогда им просто нужно пометить новую версию пакета, чтобы иметь доступ к новой версии. После этого команда, управляющая производством, может развернуть новую версию с помощью ansible.
Идти дальше
Мы максимально автоматизировали наш процесс и используем инфраструктуру публичного облака для ускорения рабочего процесса. Но в настоящее время мы все еще используем довольно традиционный процесс разработки FPGA. Существует множество различных подходов, и мы хотим продвинуть процесс разработки ПЛИС настолько близко к разработке программного обеспечения, насколько это возможно, мы рассмотрели многие из них.
HLS
Очень распространенным подходом является использование синтеза высокого уровня (HLS). Он заключается в использовании языка высокого уровня для разработки модулей вместо SystemVerilog. С Vivado HLS возможно развитие на C ++. Также можно использовать OpenCL, который мы тестировали на платах Intel. Принцип HLS состоит в том, чтобы извлечь алгоритм из кода высокого уровня, а затем автоматически построить лучшую конвейерную архитектуру на FPGA. Но мы делаем обработку пакетов, наши алгоритмы чрезвычайно просты. Сложность нашего кода заключается в самой архитектуре, позволяющей поддерживать очень высокие скорости передачи данных. Поэтому мы не смогли эффективно использовать HLS, полученный нами код был на самом деле более сложным, чем та же функция в SystemVerilog.
SystemVerilog чрезвычайно низкоуровневый и не позволяет использовать высокий уровень абстракций (по крайней мере, если вы хотите, чтобы код использовался компиляторами Intel и Xilinx). Что нам действительно нужно для упрощения разработки, так это возможность использовать более высокие уровни абстракции. Нам не нужен сложный компилятор, чтобы попытаться угадать лучшую архитектуру. Для этого у нас есть аспирант, в настоящее время работающий над проектом с открытым исходным кодом: Chisel.
Chisel — это язык аппаратного дизайна, основанный на Scala. Его основной интерес заключается в том, что он позволяет использовать весь уровень абстракции, предлагаемый Scala, для описания аппаратного обеспечения. Это также полностью открытый исходный код, что весьма необычно в мире разработки аппаратного обеспечения. Для тестирования он использует Verilator, симулятор с открытым исходным кодом. Это означает, что мы могли бы избавиться от проприетарных симуляторов и иметь полностью открытый набор инструментов, вплоть до компиляции.
В настоящее время не существует инструментов с открытым исходным кодом для этапа и маршрута, по крайней мере, для самых последних ПЛИС Xilinx и Intel. Но Chisel может генерировать Verilog, который может использоваться проприетарными компиляторами.
Мы планируем, чтобы наши первые модули, разработанные в долоте, использовались в производстве в ближайшее время. Это должно помочь нам иметь более многократно используемый код и легче писать код, а также постепенно избавляться от проприетарных инструментов.
Смена парадигмы
Сообщество открытого исходного кода чрезвычайно важно, чтобы продолжать делать разработку ПЛИС все ближе и ближе к разработке программного обеспечения. Признаком улучшения является постепенное появление бюджетных ПЛИС в проектах FabLabs и хобби-электроники. Мы надеемся, что Xilinx и Intel FPGA последуют этому примеру и что они однажды будут использовать открытые исходные коды для своих компиляторов, что может сделать их более эффективными и совместимыми. ПЛИС — это ускорители, которые предлагают невероятную гибкость и могут стать мощной альтернативой процессорам и графическим процессорам, но чтобы демократизировать их использование в облачных средах, сообщество открытого исходного кода должно стать намного сильнее.
FPGA — это аппаратный ускоритель, реконфигурируемая микросхема, которая может вести себя как обычный кремний, разработанная для конкретного применения. Мы используем FPGA в качестве пользовательских сетевых устройств для нашей системы защиты от атак. Но разработка FPGA сильно отличается от разработки программного обеспечения: она требует специализированного проприетарного программного обеспечения и длительных циклов разработки.
В этой статье я хотел бы сосредоточиться на том, как мы интегрируем разработку FPGA в рабочий процесс гибкой разработки программного обеспечения, используемый всеми другими разработчиками в OVHcloud.
Зачем использовать?
ПЛИС являются чрезвычайно общими микросхемами, их можно использовать для построения схем для очень широкого спектра применений:
- обработка сигналов
- финансы
- машинное обучение (классификация)
- сетей
Для сетевых приложений преимуществами являются:
- прямое подключение к каналам 100GbE: нет сетевой карты, нет канала PCIe, пакеты принимаются непосредственно на чипе
- доступ к памяти с чрезвычайно низкой задержкой и очень быстрым произвольным доступом (QDR SRAM: каждый банк обеспечивает около 250 миллионов операций чтения и записи в секунду)
- возможность строить собственные конвейеры обработки пакетов, максимально использовать ресурсы чипа.
Чтобы узнать больше о FPGA, электронные книги FPGA For Dummies — это хороший ресурс.
Традиционный рабочий процесс разработки FPGA
Языки, используемые для разработки на ПЛИС, имеют сильную специфику: в отличие от стандартных последовательных языков, все происходит параллельно, чтобы моделировать поведение миллионов транзисторов, работающих параллельно на микросхеме. Используются два основных языка: VHDL и SystemVerilog. Мы используем SystemVerilog. Вот пример модуля SystemVerilog:
// Simple example module: a counter
// Will clear if clear is 1 during one clock cycle.
// Will increment at each clock cycle when enable is 1.
`timescale 1ns / 1ps
module counter
#(
// Number of bits of counter result
parameter WIDTH = 5
)
(
input clk,
// Control
input enable,
input clear,
// Result
output reg [WIDTH-1:0] count = '0
);
always_ff @(posedge clk) begin
if (clear) begin
count <= '0;
end else if (enable) begin
count <= count + 1;
end
end
endmoduleМодули можно объединять, соединяя их входы и выходы для создания сложных систем.
Тестирование на симуляторе
Очень важным инструментом при разработке на ПЛИС является симулятор: он сложный и медленный для тестирования кода непосредственно на реальной ПЛИС. Чтобы ускорить процесс, симуляторы могут запускать код без специального оборудования. Они используются как для модульных тестов, для тестирования каждого модуля в отдельности, так и для функциональных тестов, имитирующих всю конструкцию, контролирующих его входы и проверяющих его выходы. Вот результат на счетчик модуля:
Симулятор модуля счетчика
Это волна, показывающая значение каждого сигнала в каждом тактовом цикле. Конечно, симулятор также может работать без головы, а тестовая среда может быть модифицирована для возврата результата «пройдено / не пройдено».
Базовый симулятор предоставлен Xilinx, производителем FPGA. Более продвинутые симуляторы предоставляются Mentor или Synopsys. Эти симуляторы являются коммерческими и требуют дорогих лицензий.
Сборка двоичного файла
После того, как все тесты пройдены, пришло время получить двоичный файл, который можно использовать для настройки FPGA. Крупнейшие поставщики FPGA, Intel и Xilinx, предоставляют собственные инструменты для этого процесса. Первый этап, синтез, преобразует исходный код в схему. Второй этап, «место и маршрут», представляет собой очень сложную задачу оптимизации, позволяющую приспособить схему к ресурсам, предоставляемым ПЛИС, при соблюдении временных ограничений, чтобы схема могла работать на требуемой частоте. Это может длиться несколько часов, даже до одного дня на очень сложных конструкциях. Этот процесс может завершиться ошибкой, если дизайн слишком ограничен, поэтому обычно приходится запускать несколько процессов с разными начальными значениями, чтобы в конце было больше шансов получить рабочий двоичный файл.
Наш текущий рабочий процесс разработки FPGA
Наш текущий процесс разработки очень близок к традиционному. Но обычно разработка FPGA намного медленнее, чем разработка программного обеспечения. В OVHcloud мы можем разработать и отправить небольшую функцию за один день. Мы достигаем этого, используя рабочий процесс, используемый разработчиками программного обеспечения, и используя нашу облачную инфраструктуру. Вот глобальный рабочий процесс:
Весь рабочий процесс контролируется CDS, нашей системой непрерывной доставки с открытым исходным кодом. Все тесты, а также задания по компиляции выполняются в Public Cloud, кроме тестов на борту, которые проводятся в нашей лаборатории.
Используя наше публичное облако
Настройка всех машин выполняется Ansible. Есть несколько важных ролей для установки различных важных компонентов:
- симулятор
- компилятор Xilinx, Vivado
- компилятор Intel Quartus
Сервер лицензий для симулятора и компиляторов
Сервер лицензий, а также блоки разработки — это долго работающие экземпляры Public Cloud. Сервер лицензий — это наименьший возможный экземпляр, блок разработки — это экземпляр с быстрым ЦП и большим объемом оперативной памяти. Симулятор и компиляторы установлены на блоке разработки. Полномочия на доступ к серверу лицензий управляются с помощью групп безопасности OpenStack.
Экземпляры, используемые для смоделированных тестов и для компиляции, запускаются с использованием API OpenStack, когда это необходимо. Это очень важно, потому что позволяет параллельно запускать несколько наборов тестов для разных разработчиков. Это также очень важно для компиляции. Мы компилируем наши проекты для нескольких целей (FPGA Stratix V для 10G и FPGA Ultrascale + для 100G), поэтому нам необходимо выполнять несколько заданий компиляции параллельно. Кроме того, мы выполняем задания параллельно с несколькими начальными числами, чтобы повысить наши шансы получить правильный двоичный файл. Поскольку в наших проектах задания на сборку могут длиться 12 часов, очень важно начать достаточно параллельно, чтобы быть уверенным, что мы получим хотя бы один работающий двоичный файл.
Запуск тестов
Функциональные тесты очень важны, потому что они проверяют каждую функцию, которую предоставляют наши разработки. Тесты разработаны на Python с использованием scapy для отправки трафика и анализа результатов. Они могут работать с имитацией дизайна или с реальным дизайном на реальных платах ПЛИС. CDS может автоматически запускать тесты на реальных платах, бронируя лабораторные серверы и подключаясь к ним через SSH. Тот же процесс используется для тестирования производительности.
Результатом этой инфраструктуры является то, что разработчики могут добавить новую функцию в ветку нашего репозитория git, и они получат полные результаты модульных и функциональных тестов через 30 минут. Если все в порядке, они могут запустить компиляцию и проверить результат на борту на следующий день. Тогда им просто нужно пометить новую версию пакета, чтобы иметь доступ к новой версии. После этого команда, управляющая производством, может развернуть новую версию с помощью ansible.
Идти дальше
Мы максимально автоматизировали наш процесс и используем инфраструктуру публичного облака для ускорения рабочего процесса. Но в настоящее время мы все еще используем довольно традиционный процесс разработки FPGA. Существует множество различных подходов, и мы хотим продвинуть процесс разработки ПЛИС настолько близко к разработке программного обеспечения, насколько это возможно, мы рассмотрели многие из них.
HLS
Очень распространенным подходом является использование синтеза высокого уровня (HLS). Он заключается в использовании языка высокого уровня для разработки модулей вместо SystemVerilog. С Vivado HLS возможно развитие на C ++. Также можно использовать OpenCL, который мы тестировали на платах Intel. Принцип HLS состоит в том, чтобы извлечь алгоритм из кода высокого уровня, а затем автоматически построить лучшую конвейерную архитектуру на FPGA. Но мы делаем обработку пакетов, наши алгоритмы чрезвычайно просты. Сложность нашего кода заключается в самой архитектуре, позволяющей поддерживать очень высокие скорости передачи данных. Поэтому мы не смогли эффективно использовать HLS, полученный нами код был на самом деле более сложным, чем та же функция в SystemVerilog.
SystemVerilog чрезвычайно низкоуровневый и не позволяет использовать высокий уровень абстракций (по крайней мере, если вы хотите, чтобы код использовался компиляторами Intel и Xilinx). Что нам действительно нужно для упрощения разработки, так это возможность использовать более высокие уровни абстракции. Нам не нужен сложный компилятор, чтобы попытаться угадать лучшую архитектуру. Для этого у нас есть аспирант, в настоящее время работающий над проектом с открытым исходным кодом: Chisel.
Chisel — это язык аппаратного дизайна, основанный на Scala. Его основной интерес заключается в том, что он позволяет использовать весь уровень абстракции, предлагаемый Scala, для описания аппаратного обеспечения. Это также полностью открытый исходный код, что весьма необычно в мире разработки аппаратного обеспечения. Для тестирования он использует Verilator, симулятор с открытым исходным кодом. Это означает, что мы могли бы избавиться от проприетарных симуляторов и иметь полностью открытый набор инструментов, вплоть до компиляции.
В настоящее время не существует инструментов с открытым исходным кодом для этапа и маршрута, по крайней мере, для самых последних ПЛИС Xilinx и Intel. Но Chisel может генерировать Verilog, который может использоваться проприетарными компиляторами.
Мы планируем, чтобы наши первые модули, разработанные в долоте, использовались в производстве в ближайшее время. Это должно помочь нам иметь более многократно используемый код и легче писать код, а также постепенно избавляться от проприетарных инструментов.
Смена парадигмы
Сообщество открытого исходного кода чрезвычайно важно, чтобы продолжать делать разработку ПЛИС все ближе и ближе к разработке программного обеспечения. Признаком улучшения является постепенное появление бюджетных ПЛИС в проектах FabLabs и хобби-электроники. Мы надеемся, что Xilinx и Intel FPGA последуют этому примеру и что они однажды будут использовать открытые исходные коды для своих компиляторов, что может сделать их более эффективными и совместимыми. ПЛИС — это ускорители, которые предлагают невероятную гибкость и могут стать мощной альтернативой процессорам и графическим процессорам, но чтобы демократизировать их использование в облачных средах, сообщество открытого исходного кода должно стать намного сильнее.
Работа с небольшими файлами с помощью OpenStack Swift (часть 2)
В первой части этих статей мы продемонстрировали, как хранение небольших файлов в Swift может вызвать проблемы с производительностью. Во второй части мы представим решение. Имея это в виду, я предполагаю, что вы прочитали первую часть или что вы знакомы со Swift.
Файлы внутри файлов
Мы остановились на простом подходе: мы будем хранить все эти небольшие фрагменты в больших файлах. Это означает, что использование inode в файловой системе намного ниже.
Эти большие файлы, которые мы называем «томами», имеют три важных характеристики:
Для каждого диска существует один индекс-сервер. Это означает, что его домен сбоя совпадает с данными, которые он индексирует. Он связывается с существующим процессом объект-сервер через локальный сокет UNIX.
Использование на LevelDB
Мы выбрали LevelDB для хранения местоположения фрагмента на индексном сервере:
Наши первоначальные тесты были многообещающими: они показали, что нам нужно около 40 байтов для отслеживания фрагмента, по сравнению с 300 байтами, если мы использовали обычную файловую систему хранения. Мы только отслеживаем местоположение фрагмента, в то время как файловая система хранит много информации, которая нам не нужна (пользователь, группа, разрешения ..). Это означает, что значение ключа будет достаточно маленьким для кэширования в памяти, и список файлов будет не требует чтения с физического диска.
При записи объекта обычная быстрая серверная часть создаст файл для хранения данных. С LOSF вместо этого:
Удаление объектов
Когда клиент удаляет объект, как мы можем на самом деле удалить данные из томов? Помните, что мы добавляем данные только в том, поэтому мы не можем просто пометить пространство как неиспользуемое в томе и попытаться использовать его позже. Мы используем XFS, и она предлагает интересное решение: возможность «пробить дыру» в файле.
Логический размер не изменяется, что означает, что фрагменты, расположенные после отверстия, не меняют смещение. Однако физическое пространство освобождается для файловой системы. Это отличное решение, так как оно означает, что мы можем продолжать добавлять тома, освобождать пространство внутри тома и разрешать файловой системе распределять пространство.
Структура каталогов
Индекс-сервер будет хранить имена объектов в плоском пространстве имен, но Swift использует иерархию каталогов.
Каталог разделов — это раздел, к которому принадлежит объект, а каталог суффиксов — это только три последние буквы контрольной суммы md5. (Это было сделано, чтобы избежать слишком большого количества записей в одном каталоге)
Если вы ранее не использовали Swift, «индекс раздела» объекта указывает, какое устройство в кластере должно хранить объект. Индекс раздела вычисляется путем взятия нескольких битов из пути объекта MD5. Вы можете узнать больше здесь.
Мы не храним эти каталоги явно на сервере индексов, так как они могут быть вычислены из хэша объекта. Помните, что имена объектов хранятся в порядке LevelDB.
Перенос данных
Этот новый подход меняет формат на диске. Однако у нас уже было более 50 ПБ данных. Миграция в автономном режиме была невозможна. Мы написали промежуточную, гибридную версию системы. Он всегда будет записывать новые данные, используя новую разметку диска, но для чтения он сначала будет искать на индексном сервере, а если фрагмент не найден, он будет искать этот фрагмент в обычном внутреннем каталоге.
Между тем, фоновый инструмент будет медленно преобразовывать данные из старой системы в новую. Это заняло несколько месяцев, чтобы обойти все машины.
Результаты
После завершения миграции активность диска в кластере была намного ниже: мы заметили, что данные сервера индексирования будут помещаться в память, поэтому перечисление объектов в кластере или получение местоположения объекта не потребует ввода-вывода физического диска. Задержка улучшилась как для операций PUT, так и для операций GET, и задачи «реконструкции» кластера могли выполняться намного быстрее. (Реконструктор — это процесс, который восстанавливает данные после сбоя диска в кластере)
Будущая работа
В контексте хранения объектов жесткие диски по-прежнему имеют ценовое преимущество перед твердотельными накопителями. Их емкость продолжает расти, однако производительность на диск не улучшилась. При том же объеме используемого пространства, если вы переключаетесь с дисков объемом 6 ТБ на 12 ТБ, вы фактически вдвое снизили производительность.
Планируя следующее поколение кластеров Swift, мы должны найти новые способы использования этих более крупных дисков, сохраняя при этом высокую производительность. Это, вероятно, будет означать использование сочетания SSD и вращающихся дисков. В этой области происходит интересная работа, поскольку мы будем хранить больше данных на выделенных быстрых устройствах для дальнейшей оптимизации времени отклика кластера Swift.
Файлы внутри файлов
Мы остановились на простом подходе: мы будем хранить все эти небольшие фрагменты в больших файлах. Это означает, что использование inode в файловой системе намного ниже.
Эти большие файлы, которые мы называем «томами», имеют три важных характеристики:
- Они посвящены разделу Swift
- Они только добавляются: никогда не перезаписывают данные
- Нет одновременных записей: у нас может быть несколько томов на раздел
Для каждого диска существует один индекс-сервер. Это означает, что его домен сбоя совпадает с данными, которые он индексирует. Он связывается с существующим процессом объект-сервер через локальный сокет UNIX.
Использование на LevelDB
Мы выбрали LevelDB для хранения местоположения фрагмента на индексном сервере:
- Он сортирует данные на диске, что означает, что он эффективен на обычных вращающихся дисках
- Это экономит место благодаря библиотеке сжатия Snappy
Наши первоначальные тесты были многообещающими: они показали, что нам нужно около 40 байтов для отслеживания фрагмента, по сравнению с 300 байтами, если мы использовали обычную файловую систему хранения. Мы только отслеживаем местоположение фрагмента, в то время как файловая система хранит много информации, которая нам не нужна (пользователь, группа, разрешения ..). Это означает, что значение ключа будет достаточно маленьким для кэширования в памяти, и список файлов будет не требует чтения с физического диска.
При записи объекта обычная быстрая серверная часть создаст файл для хранения данных. С LOSF вместо этого:
- Получить блокировку файловой системы на томе
- Добавьте данные объекта в конец тома и вызовите fdatasync ()
- Зарегистрировать местоположение объекта на индексном сервере (номер тома и смещение внутри тома)
- Запросите индекс-сервер, чтобы узнать его местоположение: номер тома и смещение
- Откройте том и найдите смещение для обработки данных.
Удаление объектов
Когда клиент удаляет объект, как мы можем на самом деле удалить данные из томов? Помните, что мы добавляем данные только в том, поэтому мы не можем просто пометить пространство как неиспользуемое в томе и попытаться использовать его позже. Мы используем XFS, и она предлагает интересное решение: возможность «пробить дыру» в файле.
Логический размер не изменяется, что означает, что фрагменты, расположенные после отверстия, не меняют смещение. Однако физическое пространство освобождается для файловой системы. Это отличное решение, так как оно означает, что мы можем продолжать добавлять тома, освобождать пространство внутри тома и разрешать файловой системе распределять пространство.
Структура каталогов
Индекс-сервер будет хранить имена объектов в плоском пространстве имен, но Swift использует иерархию каталогов.
/mnt/objects/<partition>/<suffix>/<checksum>/<timestamp>.data
Каталог разделов — это раздел, к которому принадлежит объект, а каталог суффиксов — это только три последние буквы контрольной суммы md5. (Это было сделано, чтобы избежать слишком большого количества записей в одном каталоге)
Если вы ранее не использовали Swift, «индекс раздела» объекта указывает, какое устройство в кластере должно хранить объект. Индекс раздела вычисляется путем взятия нескольких битов из пути объекта MD5. Вы можете узнать больше здесь.
Мы не храним эти каталоги явно на сервере индексов, так как они могут быть вычислены из хэша объекта. Помните, что имена объектов хранятся в порядке LevelDB.
Перенос данных
Этот новый подход меняет формат на диске. Однако у нас уже было более 50 ПБ данных. Миграция в автономном режиме была невозможна. Мы написали промежуточную, гибридную версию системы. Он всегда будет записывать новые данные, используя новую разметку диска, но для чтения он сначала будет искать на индексном сервере, а если фрагмент не найден, он будет искать этот фрагмент в обычном внутреннем каталоге.
Между тем, фоновый инструмент будет медленно преобразовывать данные из старой системы в новую. Это заняло несколько месяцев, чтобы обойти все машины.
Результаты
После завершения миграции активность диска в кластере была намного ниже: мы заметили, что данные сервера индексирования будут помещаться в память, поэтому перечисление объектов в кластере или получение местоположения объекта не потребует ввода-вывода физического диска. Задержка улучшилась как для операций PUT, так и для операций GET, и задачи «реконструкции» кластера могли выполняться намного быстрее. (Реконструктор — это процесс, который восстанавливает данные после сбоя диска в кластере)
Будущая работа
В контексте хранения объектов жесткие диски по-прежнему имеют ценовое преимущество перед твердотельными накопителями. Их емкость продолжает расти, однако производительность на диск не улучшилась. При том же объеме используемого пространства, если вы переключаетесь с дисков объемом 6 ТБ на 12 ТБ, вы фактически вдвое снизили производительность.
Планируя следующее поколение кластеров Swift, мы должны найти новые способы использования этих более крупных дисков, сохраняя при этом высокую производительность. Это, вероятно, будет означать использование сочетания SSD и вращающихся дисков. В этой области происходит интересная работа, поскольку мы будем хранить больше данных на выделенных быстрых устройствах для дальнейшей оптимизации времени отклика кластера Swift.
REG.RU улучшил позиции по new gTLDs среди мировых регистраторов
Динамика регистраций адресов в новых доменных зонах REG.RU заметно опережает не только аналогичные показатели игроков российского доменного рынка, но и многих участников международного. Компания поднялась в рейтинге и теперь, по данным Ntldstats.com, занимает 13 место в мире.
Менее, чем за полгода REG.RU как прямой регистратор увеличил количество зарегистрированных доменных имён в новых зонах с 350 000 до 435 000. Это позволило обойти ранее опережавшего в рейтинге регистратора eNom и подняться на 13 место (другие российские компании не представлены среди топ-30 участников рейтинга).
Завершают топ-15 регистраторы крупных корпораций Alibaba Group Holding Ltd. и Google, занимая 14 и 15 места. Лидер рейтинга ещё один один из проектов Alibaba Group Holding Ltd, а также регистраторы NameCheap и GoGaddy.
Согласно данным ресурса Ntldstats.com, сегодня общее число адресов в new gTLDs достигает почти 32 млн. Из них на российских регистраторов приходится около 600 тыс.
REG.RU — хостинг-провайдер и аккредитованный регистратор доменных имён №1 в России (по данным StatOnline.ru, занимает первое место по количеству зарегистрированных доменов и размещённых сайтов в национальных зонах .RU и.РФ). Компания обслуживает более 3 300 000 доменов и предлагает регистрацию в 750 международных доменных зонах, а также предоставляет услуги хостинга, SSL, почты, VPS, аренды физических серверов и облачных вычислений на GPU. В 2012 году REG.RU стал аккредитованным ICANN регистратором. Офисы REG.RU расположены в 30 городах России и СНГ.
www.reg.ru
Менее, чем за полгода REG.RU как прямой регистратор увеличил количество зарегистрированных доменных имён в новых зонах с 350 000 до 435 000. Это позволило обойти ранее опережавшего в рейтинге регистратора eNom и подняться на 13 место (другие российские компании не представлены среди топ-30 участников рейтинга).
Завершают топ-15 регистраторы крупных корпораций Alibaba Group Holding Ltd. и Google, занимая 14 и 15 места. Лидер рейтинга ещё один один из проектов Alibaba Group Holding Ltd, а также регистраторы NameCheap и GoGaddy.
Согласно данным ресурса Ntldstats.com, сегодня общее число адресов в new gTLDs достигает почти 32 млн. Из них на российских регистраторов приходится около 600 тыс.
Одновременно с повышением осведомлённости о новых доменных зонах и осознанием их ценности борьба за пользователей между регистраторами будет усиливаться. Клиент будет делать выбор в пользу удобства и развитых экосистем, которые позволяют в одной точке приобрести пул услуг для создания сайта или запуска онлайн-бизнеса. Я уверен, что REG.RU верно развивается в этом направлении, и в перспективе займёт ещё более высокую позицию в мировом рейтинге по показателям new gTLDsкомментирует генеральный директор REG.RU Алексей Королюк
REG.RU — хостинг-провайдер и аккредитованный регистратор доменных имён №1 в России (по данным StatOnline.ru, занимает первое место по количеству зарегистрированных доменов и размещённых сайтов в национальных зонах .RU и.РФ). Компания обслуживает более 3 300 000 доменов и предлагает регистрацию в 750 международных доменных зонах, а также предоставляет услуги хостинга, SSL, почты, VPS, аренды физических серверов и облачных вычислений на GPU. В 2012 году REG.RU стал аккредитованным ICANN регистратором. Офисы REG.RU расположены в 30 городах России и СНГ.
www.reg.ru