Наши партнёры и друзья из FirstVDS недавно запустили новый сервис CLO. Это отличная новость для тех, кто ищет удобное и надёжное решение для размещения своих проектов и сайтов по приятной цене.

Что такое CLO
CLO — это универсальный инструмент и хорошая альтернатива как виртуальным, так и выделенным серверам. С его помощью можно легко и быстро оптимизировать работу интернет-магазина, гибко управляя ресурсами в дни сезонных спадов или Чёрную пятницу. Или создать безопасную среду для разработки и тестирования, настроить удобную систему хранения или обработки данных, поднять сервисы для удаленной работы.

По своей сути, это обычные виртуальные серверы, но с расширенными облачными возможностями.

Сервис CLO — готовое и доступное по цене решение, с помощью которого легко создавать собственную отказоустойчивую IT-инфраструктуру.


В вашем распоряжении серверы на виртуализации KVM, объединённые в виртуальную локальную сеть (для узлов сети предусмотрена приватная адресация RFC1918), переключаемые диски и плавающие IP, которые можно «перебрасывать» с одного сервера на другой. Можно использовать и статический IP-адрес. На выбор предлагаются три операционных системы: Ubuntu, Centos и Debian.

Экономит время
Удобный Личный кабинет, в котором легко разобраться. Управление ресурсами централизованно.

Сокращает расходы
Платите только за те ресурсы, которыми пользуетесь. Оплата считается по часам.

Повышает надёжность
Узлы кластера зарезервированы, а пользовательские данные дублируются, поэтому информация не потеряется.

Сервис построен на базе проверенных технологий: OpenStack, Tungsten Fabric, Ceph, которые позволяют создавать гибкие и отказоустойчивые облачные решения.

Посмотреть тарифы и зарегистрироваться в сервисе можно на сайте clo.ru

С ростом стажа работы в IT начинаешь замечать, что системы имеют свой характер. Они могут быть покладистыми, молчаливыми, взбалмошными, суровыми. Могут располагать к себе или отталкивать. Так или иначе, приходится «договариваться» с ними, лавировать между «подводными камнями» и выстраивать цепочки их взаимодействия.

Вот и нам выпала честь построить облачную платформу, а для этого потребовалось «уговорить» пару подсистем работать с нами. Благо, у нас есть «язык API», прямые руки и куча энтузиазма.

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

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

Был также и ряд требований:

• сервису нужен удобный личный кабинет;
• платформа должна быть интегрирована в существующую систему биллинга;
• программно-аппаратная часть: OpenStack + Tungsten Fabric (Open Contrail), которые наши инженеры научились достаточно хорошо «готовить».

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

• Python + Flask + Swagger + SQLAlchemy — вполне стандартный Python набор;
• Vue.js для фронтенда;
• взаимодействие между компонентами и сервисами решили делать с помощью Celery поверх AMQP.

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

Итак, начнем наше знакомство.

Молчаливый Билл — биллинг
С этим парнем мы были знакомы давно. Он всегда сидел рядом и что-то молча считал. Иногда переправлял нам запросы пользователей, выставлял клиентские счета, управлял услугами. Обычный работящий парень. Правда, были сложности. Он молчалив, иногда задумчив и часто — себе на уме.


Биллинг — это первая система, с которой мы попытались подружиться. И первая же трудность встретилась нам при обработке услуг.

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


Судя по описанию программного API, решить эту задачу все же можно, но времени заниматься реверс-инжинирингом у нас не было, поэтому мы вынесли логику наружу и организовали очередь задач поверх RabbitMQ. Операция над услугой инициируется клиентом из личного кабинета, оборачивается в «задачу» Celery на бэкенде и выполняется на стороне биллинга и OpenStack’a. Celery позволяет достаточно удобно управлять задачами, организовывать повторы и следить за состоянием. Подробнее про «сельдерей» можно почитать, например, здесь.

Также биллинг не останавливал проект, на котором закончились деньги. Общаясь с разработчиками, мы выяснили, что при подсчете по статистике (а нам нужно реализовать именно такую логику) есть сложная взаимосвязь правил остановки. Но эти модели плохо ложатся под наши реалии. Также реализовали через задачи на Celery, забирая на сторону бэкенда логику управления услугами.

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

Еще одна проблема — молчаливость.

На часть запросов к API Билли молча отвечает «Ок». Так, например, было, когда мы делали зачисления обещанных платежей на время теста (о нем позже). Запросы корректно выполнялись и мы не видели ошибок.


Пришлось изучать логи, работая с системой через UI. Оказалось, что сам биллинг выполняет подобные запросы, изменяя scope на конкретного пользователя, например, admin, передавая его в параметре su.

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

Итак, подводя итоги, основные проблемы, которые у нас возникли на этапе взаимодействия, связаны с особенностями реализации конкретной системы:

• недокументированные «фичи», которые так или иначе нас затрагивали;
• закрытые исходники (биллинг написан на C++), как следствие — невозможность решить проблему 1 никак, кроме «метода проб и ошибок».

К счастью, у продукта есть достаточно развесистый API и мы интегрировали в свой личный кабинет следующие подсистемы:

• модуль технической поддержки — запросы из личного кабинета «проксируются» в биллинг прозрачно для клиентов сервиса;
• финансовый модуль — позволяет выставлять счета текущим клиентам, производить списания и формировать платежные документы;
• модуль управления услугами — для него нам пришлось реализовать свой обработчик. Расширяемость системы сыграла нам на руку и мы «обучили» Билли новому типу услуг.

Пришлось повозиться, но так или иначе, думаю, с Билли мы поладим.

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


Это вотчина второй системы, с которой нам пришлось подружиться — Tungsten Fabric (TF), бывший OpenContrail. Ее задача — управлять сетевым оборудованием, предоставляя программную абстракцию нам, как пользователям. TF — SDN, инкапсулирует в себе сложную логику работы с сетевым оборудованием. Про саму технологию есть неплохая статья, например, тут.

Система интегрирована с OpenStack (о нём речь пойдет ниже) через плагин Neutron’a.


Взаимодействие сервисов OpenStack.

С этой системой нас познакомили ребята из отдела эксплуатации. Мы используем API системы для управления сетевым стеком наших услуг. Серьезных проблем или неудобств она нам пока не доставляет (за ребят из ОЭ говорить не возьмусь), однако были и некоторые курьезы взаимодействия.

Первый выглядел так: команды, требующие вывода большого количества данных на консоль инстанса при подключении по SSH просто «вешали» подключение, при этом по VNC все работало корректно.


Для тех, кто не знаком с проблемой, это выглядит достаточно забавно: ls /root отрабатывает корректно, тогда как, например, top «зависает» наглухо. К счастью, мы уже сталкивались с подобными проблемами. Решилось тюнингом MTU на маршруте от compute-нод до маршрутизаторов. К слову сказать, это и не проблема TF.

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


Мы работали с Openstack с уровня admin и после этого переходили на уровень нужного пользователя. SDN, похоже, «перехватывает» скоуп пользователя, которым выполняются действия. Дело в том, что этот же админский аккаунт используется для связи TF и OpenStack. На шаге переключения под пользователя «магия» пропадала. Решено было завести отдельный аккаунт для работы с системой. Это позволило работать, не ломая функционал интеграции.

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


OpenStack — ядро нашей платформы.

OpenStack имеет несколько подсистем, из которых активнее всего мы пока используем Nova, Glance и Cinder. Каждая из них имеет свой API. Nova отвечает за compute-ресурсы и создание instance’ов, Cinder — управление volume’ами и их снимками, Glance — image service, который управляет шаблонами ОС и метаинформацией по ним.

Каждый сервис запускается в контейнере, а брокером сообщений выступает «белый кролик» — RabbitMQ.

Эта система доставила нам больше всего неожиданных хлопот.

И первая проблема не заставила себя ждать, когда мы пытались подключить дополнительный volume к серверу. Cinder API наотрез отказывался выполнять эту задачу. Точнее, если верить самому OpenStack’у связь устанавливается, однако внутри виртуального сервера устройство диска отсутствует


Мы решили «пойти в обход» и запросили то же действие у Nova API. Результат — устройство корректно подключается и доступно внутри сервера. Похоже, что проблема возникает, когда block-storage не отвечает Cinder’у.

Очередная сложность ждала нас при работе с дисками. Системный volume не удавалось отсоединить от сервера.

Опять же, сам OpenStack «божится», что связь он уничтожил и теперь можно корректно работать с volume’ом отдельно. Но API категорически не желал производить операции над диском.


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

OpenStack — достаточно сложный комплекс систем со своей логикой взаимодействия и витиеватым API. Нас выручает достаточно подробная документация и, конечно, метод проб и ошибок (куда же без него).

Тестовый запуск
Тестовый запуск мы проводили в декабре прошлого года. Основной задачей ставили проверку в боевом режиме нашего проекта с технической стороны и со стороны UX. Аудиторию приглашали выборочно и тестирование было закрытым. Однако мы также оставили возможность запросить доступ к тестированию на нашем сайте.

Сам тест, разумеется, не обошелся без курьезных моментов, ведь на этом наши приключения только начинаются.

Во-первых, мы несколько некорректно оценили интерес к проекту и пришлось оперативно добавлять compute-ноды прямо во время теста. Обычный кейс для кластера, однако и тут были нюансы. В документации для конкретной версии TF указана конкретная версия ядра, на котором тестировалась работа с vRouter. Мы решили запускать ноды с более свежими ядрами. Как итог — TF не получил маршруты с нод. Пришлось экстренно откатывать ядра.


Другой курьез связан с функционалом кнопки «изменить пароль» в личном кабинете.

Мы решили использовать JWT для организации доступа в личный кабинет, чтобы не работать с сессиями. Так как системы разноплановые и широко разбросаны, мы управляем своим токеном, в который «заворачиваем» сессии от биллинга и токен от OpenStack’a. При изменении пароля токен, разумеется, «протухает», поскольку данные пользователя уже невалидны и его нужно перевыпускать.


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

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

Продолжение следует

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

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

Системы мы уже смогли уговорить. Билл послушно занимается подсчетом, выставлением счетов и запросами пользователей у себя в каморке. «Волшебство» вольфрамовых полей обеспечивает нас стабильной связью. И лишь OpenStack иногда капризничает, выкрикивая что-то вроде «'WSREP has not yet prepared node for application use». Но это совсем другая история…

Совсем недавно мы запустили сервис.
Все подробности вы можете узнать на нашем сайте.
clo.ru



OpenStack
docs.openstack.org/nova/latest/
docs.openstack.org/keystone/latest/
docs.openstack.org/cinder/latest/
docs.openstack.org/glance/latest/

Tungsten Fabric
docs.tungsten.io/en/latest/user/getting-started/index.html
www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html

Доступна версия Fleio 2020.03! Последняя версия была опубликована сегодня, 2020-03-10.


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


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

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

С 2020.03 мы автоматизировали процесс, добавив проверку каждого клиента. Fleio проверит, является ли клиент из ЕС и имеет ли он действительный идентификатор НДС. Если идентификатор НДС действителен, он будет автоматически проверен как освобожденный от НДС.

Конечно, если вы хотите, вы все равно можете превзойти эту опцию, отредактировав клиент вручную и сняв отметку с опции TAX EXEMPT.

Обработка клиентов cron информации
Одной из проблем, которые мы рассмотрели в выпуске 2020.03, является информация, которую мы имеем на информационной панели персонала Fleio. На данный момент мы добавили дату, когда последний процесс клиентов cron успешно запущен. Это отображается в виджете APP SERVICES и будет зеленым, если с момента последнего запуска прошло менее 24 часов. Если будет больше 24 часов, дата будет красной.


Стоит упомянуть изменения и исправления ошибок:

• Добавьте параметр конфигурации, чтобы не выставлять счета за услуги с нулевой ценой, и установите по умолчанию значение True
• Исправить вкладку моментальных снимков при выдаче экземпляра 404, если клиент ранее прекратил работу служб Openstack
• Исправить загрузку из ISO в панели конечного пользователя
• Исправлена ошибка, при которой уведомления о тикете не используют переведенные шаблоны, если связанный пользователь имеет язык, отличный от языка по умолчанию
• Запретить параллельную работу сценариев сбора нескольких данных трафика

Fleio 2020.03 включает в себя множество других улучшений и исправлений ошибок. Полный список см. В полном списке изменений за 2020.03.
fleio.com/docs/changelog/v2020.03.0.html


fleio.com/
fleio.com/demo

В первой части этих статей мы продемонстрировали, как хранение небольших файлов в Swift может вызвать проблемы с производительностью. Во второй части мы представим решение. Имея это в виду, я предполагаю, что вы прочитали первую часть или что вы знакомы со 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.

Физические серверы организованы OpenStack Ironic
Мы предоставляем ресурсы по требованию через Public Cloud с 2015 года, и мы очень рады пригласить вас первыми опробовать нашу следующую важную функцию: голые экземпляры.

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

Чистый экземпляр — это физический сервер с одним арендатором, предназначенный исключительно для вашего использования. Вы получаете 100% мощности оборудования без гипервизора и уровня виртуализации.

Благодаря OpenStack Ironic теперь в нашем общедоступном облаке на основе OpenStack теперь можно предоставлять экземпляры с нуля вместо виртуальных. Вы можете использовать API с вашими предпочтительными инструментами для управления этими «голыми железными» экземплярами: CLI OpenStack, Horizon или OVH Control Panel.

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

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

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

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


Аппаратные средства
Во время альфа-фазы мы предлагаем один аромат. Основной целью этого этапа является тестирование функций, и нас меньше интересует конкретное оборудование или предложение широкого спектра экземпляров. При этом мы по-прежнему предоставляем высокопроизводительную модель:

• Процессор: Intel 2x Xeon E5-2687Wv4 — 24c / 48t — 3 ГГц / 3,5 ГГц
• Оперативная память: 256 ГБ DDR4 ECC 2133 МГц
• ДИСК: NVMe 450 ГБ x 2
• NET: NIC 10 ГБ

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

• Эта лаборатория бесплатна в течение альфа-периода, а это значит, что для экземпляров с голым металлом плата не взимается.
• Когда альфа-период заканчивается, ресурсы будут возвращены в OVH. Поэтому не следует оставлять важные данные на этих машинах и регулярно выполнять резервное копирование.
• Эта лаборатория расположена в выделенном регионе OpenStack с именем «BHS-IRONIC-LAB», на котором работает версия Queens OpenStack. Этот регион изолирован и будет содержать только голые экземпляры.

Документация
Вот несколько примеров того, как использовать его с CLI OpenStack. Вы заметите, что вы также можете использовать его с графическим интерфейсом OpenStack Horizon или веб-консолью OVH.
horizon.cloud.ovh.net/
www.ovh.com/manager/public-cloud/

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

source openrc
export OS_REGION_NAME=BHS-IRONIC-LAB

Перечислите доступные (только один для альфа-фазы)

openstack flavor list

Список доступных изображений

openstack images list

Запустите голый экземпляр

openstack server create --flavor foobar --image "Debian 9" foobarmetal

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

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

Подробнее
blog.selectel.ru/realizaciya-polzovatelskogo-interfejsa-openstack-lbaas/

Уважаемый клиент, сообщаем вам, что начинаем переход с OpenStack Identity API v2 на v3. Мы уже ввели поддержку OpenStack Identity API v3 во всех облачных регионах. 11 июня изменятся точки доступа Identity API и корректная работа OpenStack Identity API v2 больше не будет гарантирована.

Данный переход повлияет только на клиентов, использующих OpenStack API в своих скриптах и приложениях. Работа облачных серверов не будет затронута.

Пожалуйста, убедитесь, что программное обеспечение, которое вы используете для доступа к сервисам OpenStack, поддерживает OpenStack Identity API v3.

Также обратите внимание на следующую информацию:

• python-keystoneclient не поддерживает Identity API v3, и вместо него необходимо использовать python-openstackclient;
• убедитесь, что любые другие библиотеки, используемые при работе с OpenStack API, поддерживают авторизацию Identity API v3. Обновите библиотеки, если это необходимо;
• используйте новые данные для доступа. Их можно найти по ссылке portal.servers.ru/#/cloud/computing/servers -> Нажмите на кнопку «Показать реквизиты доступа» в правом верхнем углу страницы.

260000 openstack экземпляров в производстве


150PB of Swift storage


3 new regions, up to 50K instances/region, adding nvidia Tesla


Coming next: Ironic bare metal provisioning

Хорошие новости для всех тех, кто интенсивно использует хранилище в Public Cloud: мы приступили к развертыванию как аппаратных, так и программных оптимизаций, которые позволяют нам в долгосрочной перспективе демонстрировать повышенную производительность на всех экземплярах и регионы. Прирост не является анекдотическим: на примере типа B2-7 мы, например, находимся от 2000 IOPS до 20 000 IOPS, что составляет 10!

Прежде чем вдаваться в подробности этих оптимизаций, немного истории. В самом начале виртуальные машины, размещенные в Public Cloud, были связаны с удаленным хранилищем: это было логическое решение с точки зрения объединения, но латентность сети ограничивала производительность в больших масштабах. Поэтому мы быстро решили переключиться на локальное хранилище, а затем настроили избыточность. С этим локальным SSD RAID мы думали, что достигли очень хорошего уровня производительности.

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

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

Параллельно речь шла о файловой системе .LVM дал отличные результаты в синтетических тестах, но производительность оказалась менее привлекательной с применением тестов, соответствующих реальности поля: на практике наши клиенты, которые интенсивно используют Redis, MongoDB или Hadoop, не ограничены для выравнивания блоков 4K. Новый эталонный этап был необходим с более представительными инструментами.


Сравнение различных форматов хранения, сравниваемых командой OVH Metrics. В красном: характеристики PCI Raw с io = native на NVME. В оранжевом цвете, полученные с LVM, и в желтом цвете, сделанные с виртуальными машинами перед оптимизацией. Наконец, зелёным, производительность выделенных серверов, которая является стандартной мерой, которую мы пытаемся подойти, «Нижняя лучше».
Как показано в вышеприведенном тесте, результаты, полученные с помощью RAW, оказались очень близкими к результатам выделенных серверов.

В конце этого процесса мы предложили некоторым клиентам проверить правильную комбинацию, а именно переход из Qcow в RAW и файловую систему на основе оптимизированной версии Ext4. Хорошая новость, она единогласна среди первых клиентов-тестировщиков: они измеряют производительность в IOPS до десяти раз выше, как показано на скамьях ниже.



Миграция
Теперь идет вторая фаза: развертывание в больших масштабах, чтобы сделать эти улучшения доступными как можно большему количеству людей. Сайт займет немного времени: требуемое оборудование и его конфигурация требуют действительно последней версии OpenStack, Newton, по которой все наши инфраструктуры постепенно мигрируют. Хорошей новостью является то, что эти оптимизации не влияют на цену или номенклатуру наших экземпляров Public Cloud: они просто интегрированы в существующее предложение. На самом деле, вы даже можете наслаждаться этим!

Если IOPS является критерием выбора для ваших действий в облаке, мы предлагаем вам получить конкретное представление о производительности, предлагаемой несколькими щелчками мыши: вам просто нужно запустить VM B2 (General Purpose), размещенный в регионе GRA5.

А после?
Мы считаем, что интенсивное использование ввода-вывода имеет место в нашем общедоступном облаке. Параллельно с текущей миграцией мы готовим следующий шаг, который еще больше повысит уровень производительности на 10. Не заходя слишком далеко в детали предложения, все еще находящегося на стадии «незавершенного производства», просто представьте, что ваша виртуальная машина когда-нибудь сможет получить доступ в переходе PCI к кластеру SSD NVMe, установленному в соответствии с выбранным вами RAID и выделенным к вашим потребностям…