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

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

Короткий рассказ

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

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

Инструменты и оркестровка

FIO, vdbench, I / O Meter, (dd!) — это лишь некоторые из широко используемых и проверенных инструментов для тестирования хранилища. Они дают вам обзор чистой производительности для данного типа хранилища. Но что, если вы хотите протестировать всю инфраструктуру от начала до конца? Это может включать 1, 10, 100, 1000 виртуальных машин или более, с несколькими настройками диска / рейда, несколькими размерами дисков, несколькими размерами блоков. И все это с различными типичными рабочими нагрузками, состоящими из определенного процента операций чтения / записи, последовательных или случайных, и выполняемых таким количеством потоков. Вам также нужно будет использовать рабочие нагрузки, соответствующие вашим производственным рабочим нагрузкам. На самом деле комбинации бесконечны.

Имея все это в виду, для нашей первой итерации мы начали использовать HCIbench для автоматизации наших тестов.

Тест гиперконвергентной инфраструктуры

HCibench ( flings.vmware.com/hcibench ) — это бесплатный инструмент автоматизации тестов с открытым исходным кодом. Он определяет себя как «Тест гиперконвергентной инфраструктуры». По сути, это оболочка для автоматизации популярных и проверенных инструментов тестирования производительности с открытым исходным кодом: Vdbench и Fio, упрощающая автоматизацию тестирования в кластере HCI. HCIBench стремится упростить и ускорить тестирование производительности клиентских POC последовательным и контролируемым образом. Этот инструмент полностью автоматизирует сквозной процесс развертывания тестовых виртуальных машин, координации выполнения рабочих нагрузок, агрегирования результатов тестирования, анализа производительности и сбора необходимых данных для устранения неполадок.



HCIbench так же просто установить, как развернуть OVA (Open Virtual Appliance) в вашей инфраструктуре VMware:



После настройки HCIbench просто укажите в браузере адрес https: // IP: 8483, и вы готовы приступить к тестированию:





После того, как вы ввели свои учетные данные vCenter и некоторую дополнительную информацию (центр обработки данных, кластер, сеть, хранилище данных и т. Д.), Вы сможете установить настройки гостевых виртуальных машин:

• Количество виртуальных машин для развертывания
• Количество дисков для каждой ВМ
• Размер диска
• Инструмент тестирования (FIO или vdbench)
• Файл параметров ввода-вывода (подробности см. Ниже)
• Продолжительность
• И более …

Затем HCIbench возьмет на себя все операции по развертыванию / утилизации виртуальных машин и выполнит ваш тест. Результаты доступны в различных формах, от интерфейсов Grafana до файлов Excel или просто текстовых файлов для дальнейшего внешнего анализа…

Файлы параметров рабочей нагрузки, моделирование операций ввода-вывода

Файлы параметров рабочей нагрузки (здесь используются vdbench) лежат в основе всех операций тестирования. Они описывают модель ввода-вывода, которую вы хотите использовать для данной конечной точки хранилища. Доступны проценты чтения / записи, случайные / последовательные, размер блока, потоки и многие другие параметры.

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

«Общие» рабочие нагрузки

Под «общими» рабочими нагрузками мы понимаем все рабочие нагрузки, которые выглядят как «ТОЛЬКО СЛУЧАЙНОЕ ЧТЕНИЕ» или «ТОЛЬКО ПОСЛЕДОВАТЕЛЬНЫЕ ЗАПИСИ». Они позволяют нам проверить, как тип хранилища реагирует на линейные случаи и как он работает с «крайними» случаями.



Пример «универсального» файла параметров рабочей нагрузки vdbench

root@photon-HCIBench [ /opt/automation/vdbench-param-files ]# cat 
GENERIC-ONLY-READS-RANDOM-16K-vdb-1vmdk-80ws-16k-100rdpct-100randompct-4threads
*SD:    Storage Definition
*WD:    Workload Definition
*RD:    Run Definitionsd=sd1,
        lun=/dev/sda,openflags=o_direct,
        hitarea=0,range=(0,80),
        threads=4,
        wd=wd1,
        sd=sd1,
        rd=run1,
        xfersize=16k,
        rdpct=100,
        seekpct=100,
        iorate=max,
        elapsed=120,
        interval=1

«Приложения»

Под «прикладными» рабочими нагрузками мы понимаем рабочие нагрузки, которые соответствуют типичным производственным сценариям использования, таким как «РАБОЧАЯ ЗАГРУЗКА БАЗЫ ДАННЫХ», «РАБОЧАЯ ЗАГРУЗКА VDI», «РЕЗЕРВНАЯ РАБОЧАЯ ЗАГРУЗКА» и т. Д. отлично.



Пример файла параметров рабочей нагрузки vdbench «Приложение»

root@photon-HCIBench [ /opt/automation/vdbench-param-files ]# cat 
OLTP-SQL-Oracle-Exchange-vdb-1vmdk-80ws-16k-100random-70rdpct-4threads
*SD:    Storage Definition
*WD:    Workload Definition
*RD:    Run Definitionsd=sd1,
        lun=/dev/sda,
        openflags=o_direct,
        hitarea=0,range=(0,80),
        threads=4wd=wd1,
        sd=(sd1),
        xfersize=16k,
        rdpct=70,
        seekpct=100,
        rd=run1,
        wd=wd1,
        iorate=max,
        elapsed=120,
        interval=1

«Производственные» нагрузки.

Наконец, еще один подход, над которым мы работаем, — это возможность «записывать» производственную рабочую нагрузку и «воспроизводить» ее на другой конечной точке хранилища, чтобы оценить, как целевое хранилище работает с вашей производственной рабочей нагрузкой,  без  необходимости запускать на нем реальное производство. Хитрость здесь в том, чтобы использовать сочетание 3 инструментов: blktrace, btrecord и btreplay, чтобы отслеживать и отслеживать вызовы ввода-вывода низкого уровня и иметь возможность воспроизвести эти следы на другой платформе хранения. 

В следующих статьях блога мы поделимся с вами этой функцией, следите за обновлениями!

Индустриализация HCIbench работает с планировщиком Rundeck

Как мы видели, за несколько щелчков мышью мы можем определить и запустить тестовый сценарий для конкретной рабочей нагрузки. Развертывание и повторное использование тестовых виртуальных машин полностью автоматизировано. Что, если в следующий раз мы захотим повторить несколько сценариев? Например, в рамках общей проверки новой платформы хранения? На этом этапе мы начали использовать Rundeck ( www.rundeck.com), бесплатный планировщик автоматизации Runbook с открытым исходным кодом, перед HCIbench. Идея состоит в том, чтобы иметь возможность создавать полные коллекции сценариев тестов.



Первым шагом было понять, как HCIbench работает под капотом, чтобы мы могли управлять им через планировщик Rundeck. HCIbench разработан для использования через веб-интерфейс, но все его механизмы выполняются с помощью чистых и отдельных скриптов, таких как start / stop / kill. Все настройки тестов хранятся в чистом плоском файле конфигурации, который легко преобразовать в шаблон…

Создание шаблона файла конфигурации HCIbench

root@photon-HCIBench [ /opt/automation/conf ]# cat template.yaml
vc: '<VCENTER_HOSTIP>'
vc_username: '<USERNAME>'
vc_password: '<PASSWORD>'
datacenter_name: '<DATACENTER>'
cluster_name: '<CLUSTER>'
number_vm: '<NUMBERVM>'
testing_duration: '<DURATION>'
datastore_name:- '<DATASTORE>'
output_path: '<OUTPUT_PATH>'
...

Скамья «корневая работа»

Задание rundeck состоит из последовательности шагов, которые будут выполняться для определенного списка узлов. В нашем контексте узлы — это виртуальные машины, на которых работает HCIbench.

То, что мы называем стендовым «корневым заданием», — это задание rundeck, которое является основной точкой входа в стенд. Его общая роль заключается в том, чтобы вызывать другие рабочие места и запускать один конкретный стенд.

Опции (параметры) этого задания — это все элементы из шаблона конфигурации HCIbench (см. Выше).





Рабочий процесс для этого задания следующий:
— Параметры задания синтаксического анализа
— Подключение SSH к виртуальной машине HCIbench
- Заполнение шаблона конфигурации соответствующими параметрами задания
— Запуск HCIbench 

Скамейка

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

«Супер» вакансии

Наконец-то у нас есть «Супер вакансии». Это коллекции заданий, их рабочие процессы — это серии вызовов стендовых заданий. Мы используем механизм каскадных опций для передачи опций через задания. В приведенном ниже примере мы тестируем кластер vSAN через полную панель моделей ввода-вывода.



Еще одна интересная особенность использования Rundeck в качестве планировщика HCIbench — это возможность хранить все журналы с виртуальных машин HCIbench и время каждого теста в одном месте. Таким образом, можно легко просматривать и искать по всем нашим тестам или ориентироваться на конкретное поведение, показанное на графике.

Результаты и варианты использования

vSAN
Интеграция vSAN в наш продукт Hosted Private Cloud была типичным эталонным проектом, в котором нам нужно было не только проверить, как вся платформа работает в каждой области, но и уточнить дизайн самой платформы. С одной стороны, мы оценили дизайн оборудования с несколькими ссылками на диски, а с другой стороны, мы улучшили дизайн программного обеспечения, оценив различные группы дисков vSAN и конфигурации кеша.

Влияние нового ядра на массивы хранения

Еще один интересный случай использования — это оценка влияния нового ядра на массивы хранения на базе OmniOS ( www.omniosce.org). OmniOS — это бесплатная операционная система с открытым исходным кодом, основанная на OpenSolaris, которая объединяет некоторые замечательные технологии, такие как ZFS, DTrace, Crossbow, SMF, Bhyve, KVM и поддержку зон Linux. Этот случай показывает не только немного лучшие характеристики, но и значительное улучшение обработки операций ввода-вывода.

Действительно, среди множества различных тестов новое ядро ​​(r151022) показывает гораздо более стабильные и линейные операции ввода-вывода. Этот стенд также подтверждает несколько исправлений ZFS / NFS, которые были включены в это ядро, которые устраняют проблемы с задержкой во время отправки / получения снимка ZFS.



Индустриализация наших тестов позволила нам отслеживать производительность нашего хранилища. Прежде всего, поскольку мы создавали их для наших пользователей, мы согласны с тем, что получат наши клиенты. Кроме того, тесты дают нам представление об устранении проблем с хранением, которые очень специфичны и / или видны только с виртуальных машин. Мы планируем расширить это, чтобы мы могли проверить, как работает вычислительная сторона (CPU / RAM /…). Наконец, теперь мы сосредоточены на функции записи / воспроизведения рабочей нагрузки, позволяющей нашим пользователям прогнозировать, как их производственная рабочая нагрузка будет работать на платформах «XYZ», без необходимости фактически запускать на ней свою производственную среду. Мы подробно расскажем об этом в следующих статьях блога, следите за обновлениями!

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

2015 г.

В 2015 году приблизился, наша ключевой целью заключалась в разработке водных блоков с производительностью оптимального по 120W и температурой воды 30 ° С .



Чтобы упростить процесс и снизить затраты, мы заменили металлическую крышку на АБС-пластик.



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



Как и в предыдущих итерациях, мы также производили водоблоки меньшего форм-фактора. Например, вот вам водоблок GPU:

3D-печать водяных блоков

Использование пластиковых крышек для водоблоков также открыло двери для нового процесса прототипирования, включая 3D-печать. Мы начали экспериментировать с 3D-печатными водоблоками из АБС-пластика, тестируя различные типы крышек.

Варианты обложек, напечатанных на 3D-принтере:

CFD моделирование

Впервые в истории OVHcloud мы использовали расширенное моделирование CFD (вычислительная гидродинамика). Это позволило нам оптимизировать теплогидравлику пластин с медным основанием и дополнительно улучшить характеристики водоблока.

Резервирование

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

2017 г.

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



К 2017 году мы были в состоянии использовать водные блоки с оптимальной производительностью от 200Вт и температурой воды 30 ° C , и все было полностью разработано и изготовлено внутри на OVHcloud .

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

Два примера водоблоков: один для стандартных процессоров, другой для графических процессоров, с белыми полиамидными крышками:





Водоблок для процессоров высокой плотности с черной крышкой из полиамидного пластика:



Эксперименты с полиамидным пластиком также позволили нам быстро спроектировать и протестировать различные прототипы для улучшения поддержки ЦП и снижения стоимости.

2018-2019

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

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



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



На этих водоблоках трубопроводы полностью выполнены из медных сварных труб.



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

2020-…

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



Мы работаем над водоблоками следующего поколения tier-4, используя нашу запатентованную технологию. Наши водоблоки 4-го уровня больше не являются прототипами, они готовы к производству, и мы активно работаем над моделированием и тестами для повышения производительности.



Мы стремимся к водоблокам мощностью 400 Вт с температурой воды 30 ° C и полностью резервным водоснабжением.

А кроме водоблоков?

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



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

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



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

libvirt

, которое имеет PCI транзитного особенность , которая оказалась именно то , что нам нужно для этой цели.

Архитектура NVMe для наших экземпляров Public Cloud

Чтобы обеспечить максимальную производительность хранилища, мы работали с рядом наших клиентов над PoC, в котором использовалась та же функция PCI Passthrough, чтобы включить самое быстрое устройство хранения в наши экземпляры Public Cloud: карты NVMe с 1,8 ТБ пространства .

Когда дело доходит до хранения и данных о клиентах, мы должны быть уверены, что, когда клиент удаляет и выпускает экземпляр, мы должным образом очищаем устройство перед тем, как передать его другому экземпляру. В этом случае мы установили патч для OpenStack Nova , чтобы полностью стереть данные с устройства. Вкратце, когда экземпляр IOPS выпущен клиентом, он помещается в карантин, где внутренние инструменты запускают необходимые действия по удалению на устройстве. После завершения и проверки устройство и слот экземпляра возвращаются в Nova как «доступные».



Очистите устройство перед его перераспределением

Вы говорите быстро, но как быстро?

Давайте перейдем к некоторым конкретным примерам и не пожалеем времени, чтобы оценить потрясающую скорость этих новых экземпляров! Мы воспользуемся моделью самого большого экземпляра и запустим тест ввода-вывода на RAID 0. Таким образом, мы увидим, каковы ограничения, когда мы стремимся создать самое быстрое решение для хранения данных на простом экземпляре Public Cloud.

Сначала создайте экземпляр i1-180, используя OpenStack CLI.

$ openstack server create --flavor i1-180 --image "Ubuntu 19.04" \
  --net Ext-Net --key-name mykey db01

Проверьте устройства NVMe на экземпляре.

$ lsblk | grep nvme
nvme2n1 259:0    0  1.8T  0 disk
nvme1n1 259:1    0  1.8T  0 disk
nvme0n1 259:2    0  1.8T  0 disk
nvme3n1 259:3    0  1.8T  0 disk

У нас есть четыре устройства NVMe, поэтому давайте создадим с ними RAID 0.

$ mdadm --create /dev/md1 --level 0 --raid-devices 4 \
  /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started

Теперь отформатируем рейд-устройство.

$ mkfs.xfs /dev/md1
meta-data=/dev/md1               isize=512    agcount=32, agsize=58601344 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=1875243008, imaxpct=5
         =                       sunit=128    swidth=512 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

После монтирования файловой системы на / mnt мы готовы запустить тест.

Прочитать тест

Мы начнем с теста чтения, используя блоки размером 4 КБ, и поскольку у нас 32 виртуальных ядра в этой модели, мы будем использовать 32 задания. Пошли!

$ fio --bs=4k --direct=1 --rw=randread --randrepeat=0 \
  --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting \
  --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randread, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [r(32)][100.0%][r=9238MiB/s][r=2365k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3207: Fri Nov 29 16:00:13 2019
  read: IOPS=2374k, BW=9275MiB/s (9725MB/s)(1087GiB/120002msec)
    slat (usec): min=2, max=16031, avg= 7.39, stdev= 4.90
    clat (usec): min=27, max=16923, avg=419.32, stdev=123.28
     lat (usec): min=31, max=16929, avg=427.64, stdev=124.04
    clat percentiles (usec):
     |  1.00th=[  184],  5.00th=[  233], 10.00th=[  269], 20.00th=[  326],
     | 30.00th=[  363], 40.00th=[  388], 50.00th=[  412], 60.00th=[  437],
     | 70.00th=[  465], 80.00th=[  506], 90.00th=[  570], 95.00th=[  635],
     | 99.00th=[  775], 99.50th=[  832], 99.90th=[  971], 99.95th=[ 1037],
     | 99.99th=[ 1205]
   bw (  KiB/s): min=144568, max=397648, per=3.12%, avg=296776.28, stdev=46580.32, samples=7660
   iops        : min=36142, max=99412, avg=74194.06, stdev=11645.08, samples=7660
  lat (usec)   : 50=0.01%, 100=0.02%, 250=7.41%, 500=71.69%, 750=19.59%
  lat (usec)   : 1000=1.22%
  lat (msec)   : 2=0.07%, 4=0.01%, 10=0.01%, 20=0.01%
  cpu          : usr=37.12%, sys=62.66%, ctx=207950, majf=0, minf=1300
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=284924843,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
   READ: bw=9275MiB/s (9725MB/s), 9275MiB/s-9275MiB/s (9725MB/s-9725MB/s), io=1087GiB (1167GB), run=120002-120002msec
 
Disk stats (read/write):
    md1: ios=284595182/7, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=71231210/1, aggrmerge=0/0, aggrticks=14348879/0, aggrin_queue=120, aggrutil=99.95%
  nvme0n1: ios=71231303/2, merge=0/0, ticks=14260383/0, in_queue=144, util=99.95%
  nvme3n1: ios=71231349/0, merge=0/0, ticks=14361428/0, in_queue=76, util=99.89%
  nvme2n1: ios=71231095/0, merge=0/0, ticks=14504766/0, in_queue=152, util=99.95%
  nvme1n1: ios=71231096/4, merge=0/1, ticks=14268942/0, in_queue=108, util=99.93%

2370 тыс. Операций ввода-вывода в секунду. Потрясающие цифры, не правда ли?

Написать тест

Готовы к тесту записи?

$ fio --bs=4k --direct=1 --rw=randwrite --randrepeat=0 --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randwrite, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [w(32)][100.0%][w=6702MiB/s][w=1716k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3135: Fri Nov 29 15:55:10 2019
  write: IOPS=1710k, BW=6680MiB/s (7004MB/s)(783GiB/120003msec); 0 zone resets
    slat (usec): min=2, max=14920, avg= 6.88, stdev= 6.20
    clat (nsec): min=1152, max=18920k, avg=587644.99, stdev=735945.00
     lat (usec): min=14, max=18955, avg=595.46, stdev=736.00
    clat percentiles (usec):
     |  1.00th=[   21],  5.00th=[   33], 10.00th=[   46], 20.00th=[   74],
     | 30.00th=[  113], 40.00th=[  172], 50.00th=[  255], 60.00th=[  375],
     | 70.00th=[  644], 80.00th=[ 1139], 90.00th=[ 1663], 95.00th=[ 1991],
     | 99.00th=[ 3490], 99.50th=[ 3949], 99.90th=[ 4686], 99.95th=[ 5276],
     | 99.99th=[ 6521]
   bw (  KiB/s): min=97248, max=252248, per=3.12%, avg=213714.71, stdev=32395.61, samples=7680
   iops        : min=24312, max=63062, avg=53428.65, stdev=8098.90, samples=7680
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.86%, 50=11.08%
  lat (usec)   : 100=15.35%, 250=22.16%, 500=16.34%, 750=6.69%, 1000=5.03%
  lat (msec)   : 2=17.66%, 4=4.38%, 10=0.44%, 20=0.01%
  cpu          : usr=20.40%, sys=41.05%, ctx=113183267, majf=0, minf=463
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,205207842,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
  WRITE: bw=6680MiB/s (7004MB/s), 6680MiB/s-6680MiB/s (7004MB/s-7004MB/s), io=783GiB (841GB), run=120003-120003msec
 
Disk stats (read/write):
    md1: ios=0/204947351, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/51301962, aggrmerge=0/0, aggrticks=0/27227774, aggrin_queue=822252, aggrutil=100.00%
  nvme0n1: ios=0/51302106, merge=0/0, ticks=0/29636384, in_queue=865064, util=100.00%
  nvme3n1: ios=0/51301711, merge=0/0, ticks=0/25214532, in_queue=932708, util=100.00%
  nvme2n1: ios=0/51301636, merge=0/0, ticks=0/34347884, in_queue=1089896, util=100.00%
  nvme1n1: ios=0/51302396, merge=0/0, ticks=0/19712296, in_queue=401340, util=100.00%

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

Конечно, для этого примера мы представляем оптимальный сценарий. RAID 0 по своей природе опасен, поэтому любой сбой на одном из устройств NVMe может повредить ваши данные. Это означает, что вы обязательно должны создавать резервные копии критически важных данных, но это само по себе открывает множество новых возможностей. Так что мы на 100% уверены, что ваши базы данных полюбят эти экземпляры! Вы можете найти более подробную информацию о них на нашем  веб-сайте Public Cloud .

Одним из успехов OVHcloud является наша способность разрабатывать и продвигать инновации как в ИТ, так и в промышленных практиках. В течение двух десятилетий мы ставили инновации в центр нашей стратегии, это часть нашей ДНК. Мы постоянно исследуем и разрабатываем новые технологии, чтобы оптимизировать работу наших услуг.

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



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

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

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

2003-2008 гг.

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



Наши первые поколения технологии водоблоков были разработаны нашими командами и изготовлены на стороне. Эти водоблоки имели оптимальную производительность 60 Вт при температуре воды 30 ° C.

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



На следующей итерации наших водоблоков мы добавили некоторые изменения для повышения надежности и снижения затрат:

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

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



На разрезе водоблока показана ранняя структура теплогидравлики, где полностью гладкая поверхность основания образует резервуар с крышкой:

2011 г.

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



В течение этого периода мы по-прежнему разрабатывали наши водоблоки внутри и производили их внешне. Оптимальная мощность для этого поколения водоблоков — 60 Вт при температуре воды 30 ° C.

Наши водоблоки продолжали развиваться. Мы заменили медную выпуклую торцевую опорную пластину простой пластиной. Крест на крышке заменили крестиком внутри водоблока. Это позволило нам еще больше снизить стоимость водоблоков без снижения производительности.

2013-2014 гг.

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



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

Прочие факторы

На этом этапе мы начали делать вариации водоблока, например адаптировать их к меньшим форм-факторам GPU:



Здесь вы можете сравнить стандартный водоблок процессора и более компактный водоблок графического процессора:



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



Хорошим примером является водоблок, который мы разработали для процессоров высокой плотности IBM Power 8. На следующем снимке вы можете увидеть крышку и опорные плиты этого специального водоблока:



Крышка и опорные пластины водяного блока, используемые в процессорах IBM Power8 высокой плотности

2015 и далее

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

В ближайшие недели мы опубликуем следующие статьи в нашей серии о водяном охлаждении. Они расскажут историю развития наших водоблоков с 2015 года. Мы сосредоточимся на нынешнем поколении и дадим вам краткий обзор будущих улучшений.

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

В наших предыдущих статьях мы объяснили, почему нам пришлось перенести 800 000 баз данных из одного центра обработки данных в другой, на расстоянии 300 километров. Итак, мы… Моя команда и я сделали это! Это было настоящей головной болью, поэтому я надеюсь, что наша история поможет вам обратиться к большему количеству крупных технических проектов, с которыми мы любим играть.

Правила

• Чтобы уменьшить задержку, базу данных необходимо переносить одновременно с веб-сайтом, который ее использует.
• Поскольку базы данных распределены по всем доступным серверам MySQL, детализацией миграции должна быть база данных, а не экземпляр MySQL. Другими словами, мы не можем перенести весь сервер MySQL. Мы должны переместить только его часть.
• Поскольку ссылка между веб-сайтом и его базой данных не обязательно указывается, веб-сайт в Gravelines должен иметь возможность связываться с базой данных в Париже (например), и наоборот.
• Чтобы связаться со своей базой данных, веб-сайт использует имя хоста, имя пользователя и пароль. Мы хотим, чтобы миграция была прозрачной, чтобы никому не пришлось изменять какие-либо из этих элементов, чтобы связаться с их новой базой данных.
• Платформы баз данных меняются между Paris и Gravelines, как показано ниже.

Подводя итог, вот что у нас было до миграции веб-кластера:



И это то, что мы хотим после миграции:

Еще несколько вещей…

• Очевидно, что при работе с базами данных мы должны помнить об одном из самых важных моментов: согласованности. Для каждой базы данных нам нужно было определить точку согласованности. До этого момента на временной шкале чтение и запись производились в Париже. После этого чтение / запись производились в Gravelines.
• Мы верим в прозрачность и обратимость. Это обе ключевые части нашего SMART-облака. Вот почему мы хотели предоставить вам доступ к этой точке согласованности в виде дампа на панели управления OVHcloud . Для каждой перенесенной базы данных мы решили предоставить вам доступ к дампу на один месяц.
• Перенос 800 КБ баз данных примерно за 60 ночей означал, что мы должны были быть очень быстрыми и масштабируемыми. Наш рекорд был 1 июля 2019 года, когда мы успешно перенесли 13 502 базы данных за 1 час 13 минут и 31 секунду.
• Если вы привыкли быть на работе, вы знаете, что ночью ваше внимание и работоспособность ниже. Повторение процесса миграции примерно 60 раз в год усилит это, поэтому мы хотели, чтобы все было максимально автоматизировано и как можно проще. Как мы увидим позже, для запуска миграции базы данных нам просто нужно было запустить одну команду на одном хосте:

migrate-p19

Теперь вы знаете правила, пора начинать игру!

1-й уровень

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

1. У источника (Париж)

• Установите режим только для чтения. Нам абсолютно необходимо избегать записи во время миграции, чтобы избежать известного  разделения мозга . Самый простой способ сделать это — перевести базу данных в режим только для чтения. В большинстве случаев веб-сайтам нужно только читать базы данных, но в некоторых случаях им нужно читать и писать, и поэтому они будут сломаны. Это не проблема, потому что сайт сейчас перенесен и закрыт. Мы заблокируем доступ на запись, если база данных используется другим хостом, на который ночная миграция не влияет.
• Дамп базы данных и дамп куда-нибудь положить. Мы решили хранить дампы в публичном облачном хранилище (PCS) OVHcloud , так как мы уже используем это решение для хранения 36 миллионов дампов в месяц. Добавление 800 000 дампов за год — не проблема для этой потрясающей платформы!

2. В пункте назначения (Гравелин)

• Получите дамп и импортируйте его.
• Создайте пользователя и разрешения с правом записи.

3. Переключитесь на новую базу данных.

• На данный момент веб-сайт все еще обращается к базе данных в Париже. Чтобы веб-сайт (независимо от того, размещен ли он в Париже или Gravelines) мог связаться с новой базой данных, мы обновим DNS, чтобы имя указывало на экземпляр Gravelines MySQL, а не на Париж.
• Доступ для чтения к базе данных Paris также удален.
• Наконец, мы обновим нашу информационную систему, чтобы вы могли получить дамп с PCS через панель управления. Это обновление также позволяет нам перенаправить все действия, доступные из Панели управления (например, изменение пароля, создание дампа…), в новую базу данных на Gravelines.

Уровень 2: «Децентрализованный государственный автомат»

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

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



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

• Источник
• Назначение
• Тот, который обновляет DNS

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

Мозг миграции: CloudDB

Нам нравится концепция «ешьте свою собственную еду»! Это лучший контроль качества, который когда-либо был, и ваши отзывы — это наш первый источник запросов на добавление функций. Поэтому неудивительно, что мы использовали наш собственный продукт CloudDB для хранения графов состояний миграций баз данных.

Технически граф состояний — это строка в таблице. Упрощенная структура этой таблицы выглядит так:

- database_name VARCHAR(255) PRIMARY KEY,
- source VARCHAR(255),
- destination VARCHAR(255),
- status VARCHAR(255) NOT NULL DEFAULT 'Waiting',
- dump_url TEXT

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

Мы прошли все испытания этого уровня. Пришло время победить последнего монстра!

Уровень 3. Перенести 800 КБ баз данных.

Теперь, когда мы знаем, как перенести одну базу данных децентрализованно, давайте заполним CloudDB всеми базами данных, которые мы хотим перенести! Вот как теперь выглядит миграция:

В Париже

Примерно раз в минуту * каждый хост из 780 серверов баз данных спрашивает CloudDB, есть ли у них что-то для сброса. В sourceи statusстолбцах таблицы используются для получения этой информации:

SELECT … WHERE source = me AND status = 'To dump';

Если так, они выполняют свои задачи и обновляют CloudDB о том, что они делают. Когда они закончили, они передают эстафету перехода к Gravelines:

UPDATE … SET status = 'To import' WHERE database_name = '…';

В Gravelines

В то же время в 300 километрах сотни серверов баз данных также спрашивают CloudDB, есть ли у них что-то для импорта. Как и в Париже, они запрашивают CloudDB примерно раз в минуту *. В destinationи statusстолбцах таблицы используются для получения этой информации:

SELECT … WHERE destination = me AND status = 'To import';

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

UPDATE … SET status = 'DNS to update' WHERE database_name = '…';

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

Обновление DNS

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

Не все так просто ...

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

• Предотвращение записи в исходную базу данных
• Обновление IS (среди прочего), чтобы вы могли видеть дамп в Панели управления
• Установка пароля в пункте назначения (такого же, как у источника), не зная этого
• И многие другие

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

Чит-код: Итерация!

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

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

Но есть чит-код, чтобы победить этого босса: повторять!

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

Этот способ возможен благодаря двум причинам:

• Волшебная команда
• Большая красная кнопка

Волшебная команда

Как упоминалось выше, для запуска миграции базы данных нам пришлось запустить одну команду на одном хосте:

migrate-p19

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

migrate-p19 --max-procs 400

Это означает, что 400 баз данных выгружаются или импортируются одновременно — ни больше, ни меньше.

Команда migrate-p19- это планировщик. Он обновляет CloudDB каждые 10 секунд, поэтому эти 400 миграций всегда выполняются параллельно:

SELECT COUNT(database_name) … WHERE status in ('To dump', 'Dumping', 'Dump failed', 'To import', …);
42
UPDATE … SET status = 'To dump' WHERE status = 'Waiting' LIMIT (400 - 42);

Пауза в игре: большая красная кнопка

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

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

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

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

Во время саммита OVHcloud в октябре прошлого года мы объявили о недавней регистрации 50 семейств патентов.

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



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

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

Почему патентная регистрация важна

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





Из всех этих причин основными являются:

Защищая себя. Для такой компании, как наша, есть две основные угрозы:

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

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

Более того, пока они остаются небольшими, они могут надеяться не привлекать внимания крупных конкурентов или патентных троллей.

Когда мы начали расти и решили открыть дочернюю компанию в США, на территории по определению патентных троллей и GAFAM с тысячами патентов, мы думали, что скрещивать пальцы в надежде на то, что нас не заметят, явно не правильная стратегия, поэтому Мы засучили рукава, составили проект патентной программы, соответствующую политику вознаграждения, обучили наших сотрудников интеллектуальной собственности и быстро начали видеть преимущества: почти 50 патентных заявок за 18 месяцев! И поверьте, это только начало!

Сохранение свободы действий

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

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

Возможность участвовать в патентных пулах и других сообществах открытых инноваций

Как известно, сила в числах!

Поэтому было естественно, что компании начали объединять усилия для внедрения инноваций.

Либо они хотят работать вместе (совместная разработка, перекрестное лицензирование…), и в этом случае предпочтительнее подавать патенты вверх по потоку, чтобы впоследствии было свободное обсуждение,

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

Благодарим наших сотрудников

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

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

Когда патент способствует открытым инновациям

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

Технологическое партнерство

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

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

Программное обеспечение и патенты с открытым исходным кодом

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

Авторское право защищает только форму (т.е. исходный код, объектный код, документацию и т. Д.), В то время как патент защищает процесс, метод, независимо от используемого языка.

Две программы, производящие строго похожие эффекты, но в разных формах, не нарушают друг друга с точки зрения авторских прав.

В то время как патент, защищающий процесс, запрещает его повторное использование независимо от используемой формы.

Но зачем подавать патент, а потом давать доступ к источникам?

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

«Экономика мира»

Когда Tesla разрешила использовать свои патенты без уплаты лицензионных сборов, Tesla не отказалась от своих патентов, сказал Маск: «Tesla не будет возбуждать патентные иски против тех, кто добросовестно хочет использовать нашу технологию».

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

Этот новый образ мышления и действий соответствует тому, что автор Тьерри Кузе называет «экономикой мира», которую он противопоставляет «экономике хищничества».

Мы в OVHcloud также думаем об этом и поэтому выступаем за SMART Cloud — обратимое, открытое и совместимое облако посредством открытых инноваций.

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

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



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

Асинхронная репликация

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

Полусинхронная репликация

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

Синхронная репликация

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

Пример из реального мира

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

Покупка товара — это запрос на запись, так как вам нужно обновить запас, поэтому вы должны выполнить его на основном узле. Отображение веб-страницы — это запрос на чтение, поэтому вы решаете выполнить его на узле реплики. Что произойдет со вторым покупателем, если он / она отобразит веб-страницу в тот же самый момент, когда первый покупатель получит подтверждение покупки? Он видит товар как в наличии, так и вне его.

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



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

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

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

Как видите, вы выбираете либо пропускную способность и реактивность, либо безопасность. Нет правильного ответа, это в основном зависит от вашего варианта использования . К счастью, некоторые системы управления базами данных (СУБД), такие как PostgreSQL , позволяют вам определять уровень безопасности, который вы хотите для данного запроса. Это означает, что вы можете использовать синхронную репликацию, когда клиент совершает покупку на сумму не менее 1000 долларов, и использовать асинхронную репликацию в противном случае.

И какой метод использует OVHcloud?

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

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



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

В этой новой серии сообщений блога мы более подробно рассмотрим внутреннюю инфраструктуру реляционных баз данных OVHcloud. Этот первый пост про инфраструктуру внутренних баз данных. В OVHcloud мы используем 3 основных СУБД (системы управления базами данных), PostgreSQL MariaDB и MySQL, каждая из которых опирается на одну и ту же кластерную архитектуру.

Но сначала, что такое кластер? Кластер — это группа узлов (физических или виртуальных), работающих вместе для предоставления службы SQL.

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

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

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

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



Поскольку каждый узел в кластере может быть повышен до основного, они должны иметь возможность обрабатывать одну и ту же рабочую нагрузку. Таким образом, у них должны быть точно такие же ресурсы (ЦП, ОЗУ, диск, сеть…). Это особенно важно, когда нам нужно продвинуть реплику, потому что она должна будет обрабатывать ту же рабочую нагрузку. В этом случае наличие неодинакового размера первичной и реплики может иметь катастрофические последствия для вашей рабочей нагрузки. Когда наши кластеры запущены и работают, мы можем начать опрашивать их. Каждый кластер может содержать одну или несколько баз данных в зависимости от нескольких факторов, таких как стоимость инфраструктуры и типы рабочих нагрузок (критически важные для бизнеса или нет, транзакционные или аналитические…).

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



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

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

Это позволило нам автоматизировать его более эффективно и абстрагироваться от сложности, лежащей в основе различного программного обеспечения.

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

Но основная причина наличия отдельного узла резервного копирования заключается в следующем: резервное копирование никак не влияет на кластер. Действительно, резервное копирование полной базы данных может иметь очень заметное влияние на производство (блокировки, потребление ЦП и ОЗУ и т. Д.), А мы не хотим этого на производственных узлах.

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



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

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

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

После того, как угли будут удалены, я должен определить приоритеты блюд, которые я хочу приготовить, когда температура упадет:

• Пицца: 280 ° C
• Хлеб: 250 ° C
• Рисовый пудинг: 180 ° C
• Безе: 100 ° C

Я построил первую версию термометра с Arduino, чтобы иметь возможность проверять температуру. Этот термометр, сделанный из термопары (т. Е. Датчика, который измеряет высокие температуры), отображает внутреннюю температуру на маленьком ЖК-экране.



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



Пожалуйста, дайте мне поспать!

Это требует некоторой автоматизации. К счастью, у OVHcloud есть решение: платформа данных метрик: www.ovh.com/fr/data-platforms/metrics/

Оборудование

Цель проекта — подключить датчик к Arduino, который будет отправлять данные на платформу данных метрик OVHcloud ( www.ovh.com/fr/data-platforms/metrics/ ) по сети. По сути, Arduino будет использовать локальную сеть Wi-Fi для передачи данных о температуре на серверы OVHcloud.

Вы знаете ESP8266? Это недорогой ( менее 2 евро! ) Микрочип Wi-Fi с полным стеком TCP / IP и возможностями микроконтроллера.

Функциональная схема ESP8266

Реализация: Wemos

ESP8266 не так прост в использовании сам по себе:

• Должен быть запитан от 3,3 В (не слишком много, иначе он сгорит)
• Нет USB

Поэтому лучше использовать решение, реализующее для нас ESP8266. Вот Wemos!

• Питание от 5 В (6 В все еще в порядке)
• USB для последовательной связи (для отладки)
• Программирование через USB
• Может быть запрограммирован с помощью Arduino IDE
• Стоит меньше 3 €

Подготовьте свою Arduino IDE

Установите интегрированную среду разработки

Прежде всего вам необходимо установить Arduino IDE. Это бесплатно и доступно для любой платформы (Mac, Windows, Linux). Перейдите на www.arduino.cc/en/main/software и загрузите версию, соответствующую вашей платформе. На момент написания текущая версия — 1.8.10.

Дополнительная конфигурация для ESP8266

Когда вы установите Arduino IDE, она сможет программировать только официальные Arduinos. Добавим прошивку и библиотеки для ESP8266…



Запустите Arduino и откройте окно «Настройки» ( Файл> Настройки ).
Введите

<a href="https://arduino.esp8266.com/stable/package_esp8266com_index.json" target="_blank" rel="nofollow external noopener noreferrer" data-wpel-link="external">https://arduino.esp8266.com/stable/package_esp8266com_index.json</a>

 в поле «Дополнительные URL-адреса Board Manager». Вы можете добавить несколько URL-адресов, разделяя их запятыми.

Теперь откройте «Менеджер плат» в меню « Инструменты»> « Плата» и установите платформу esp8266 (не забудьте выбрать плату ESP8266 в меню « Инструменты»> « Плата» после установки).



Теперь вы готовы!

Заказать платформу данных метрик

Перейдите на веб-сайт платформы данных метрик OVHcloud: www.ovh.com/fr/data-platforms/metrics/. Нажмите на бесплатную пробную версию и завершите свой заказ. Если у вас нет учетной записи, просто создайте ее. В этом испытании у вас будет 12 показателей (т. Е. 12 наборов записей). В этом примере мы будем использовать только один.

Получите свой токен

Перейдите в панель управления OVH: www.ovh.com/manager/cloud/#/. На левой панели у вас должны быть метрики и новый сервис внутри.



Во вкладке «Токены» вы можете скопировать токен записи. Сохраните его, так как он нам понадобится позже.



Обратите внимание, что для настройки Grafana вам понадобится токен чтения.

Получить хост платформы данных метрик

Хост вашей платформы данных метрик указан в описании вашей услуги. На вкладке «Платформы» скопируйте хост opentsdb. Сохраните его, так как он нам понадобится позже.

Глубже в программе

Теперь посмотрим на пример. Вот код, который отправит статические данные на платформу данных метрик OVHcloud. Вы можете использовать его со своим датчиком. Вам просто нужно закодировать измерение датчика. Во время работы Wemos:

• Попробуйте подключиться к вашей сети Wi-Fi
• В случае успеха отправьте данные в платформу данных метрик OVHcloud

Весь исходный код доступен на моем github: https://github.com/landru29/ovh_metrics_wemos .

Есть шесть основных файлов:

• ovh_metrics_wemos.ino : главный файл
• wifi.cpp : класс, который реализует процесс подключения к Wi-Fi через WPS (Wifi Protected Setup)
• wifi.h : заголовочный файл для Wi-Fi
• metrics.cpp : класс, который отправляет данные метрики в платформу данных метрик OVHcloud через HTTPS.
• metrics.h : заголовочный файл для показателей
• config.h.sample : модель для создания файла конфигурации (см. ниже)

Создайте свой файл конфигурации

Если вы попытаетесь скомпилировать программу, вы получите ошибки, так как некоторые определения отсутствуют. Нам нужно объявить их в файле config.h .

1. Скопируйте config.h.sample в config.h
2. Скопируйте токен записи, полученный в пункте 5.1 (#define TOKEN «xxxxxx»)
3. Скопируйте хост, указанный в параграфе 5.2 (#define HOST «xxxxxx»).

Получите отпечаток сертификата

Поскольку Wemos будет запрашивать через HTTPS, нам понадобится отпечаток сертификата. Вам понадобится хост, который вы только что взяли на вкладке «Платформы», а затем:

Пользователи Linux
Просто запустите этот небольшой скрипт:

HOST=opentsdb.gra1.metrics.ovh.net; echo | openssl s_client -showcerts -servername ${HOST} -connect ${HOST}:443 2>/dev/null | openssl x509 -noout -fingerprint -sha1 -inform pem | sed -e "s/.*=//g" | sed -e "s/\:/ /g"

Скопируйте результат в свой

.config.h (#define FINGERPRINT "xx xx ..")

Пользователи MAC
Просто запустите этот небольшой скрипт:

HOST=opentsdb.gra1.metrics.ovh.net; echo | openssl s_client -showcerts -servername ${HOST} -connect ${HOST}:443 2>/dev/null | openssl x509 -noout -fingerprint -sha1 -inform pem | sed -e "s/.*=//g" | sed -e "s/\:/ /g"

Скопируйте результат в свой

.config.h (#define FINGERPRINT "xx xx ..")

Пользователи Windows

В своем браузере перейдите на opentsdb.gra1.metrics.ovh.net. Нажмите на замок рядом с URL-адресом, чтобы отобразить отпечаток сертификата. Замените все ":" одним пробелом.

Скомпилируйте проект и загрузите его в Wemos

1. Откройте

   .ino

    файл в Arduino IDE (у вас в проекте должно быть шесть вкладок)
2. Подключите Wemos к вашему компьютеру
3. Выберите порт из Инструменты> Порт
4. В верхнем левом углу нажмите на стрелку, чтобы загрузить программу.
5. После загрузки вы можете открыть монитор последовательного порта: Инструменты> Монитор последовательного порта

Прямо сейчас программа должна выйти из строя, поскольку Wemos не сможет подключиться к вашей сети Wi-Fi.

Запустите программу

Как мы уже видели, при первом запуске происходит сбой. Это потому, что вам нужно запустить WPS-соединение, поэтому в зависимости от вашего интернет-модема вам нужно будет запустить транзакцию WPS. Это может быть физическая кнопка на модеме или программное действие, запускаемое на консоли ( en.wikipedia.org/wiki/Wi-Fi_Protected_Setup ).

Когда процесс запускается на стороне модема, у вас есть примерно 30 секунд для включения Wemos.

1. Подключите Wemos через USB => программа запущена
2. Выберите порт из  Инструменты> Порт  (возможно, он изменился)
3. Откройте последовательный монитор:  Инструменты> Последовательный монитор.

Теперь вы можете следить за процессом.

Wi-Fi соединение

В последовательном мониторе (установите битрейт 9600) вы должны получить:

Try to connect
 
WPS config start
Trying to connect to <your modem> with saved config ...|SUCCESS
IP address: 192.168.xx.xx

Если соединение Wi-Fi было успешным, последовательная консоль должна отображать локальный IP-адрес (192.168.xx.xx), в противном случае — сбой. Попробуйте еще раз, запустив WPS на модеме и перезапустив Wemos (отключите его и снова подключите).

Отправка данных в платформу данных метрик OVHcloud

Теперь Wemos отправляет запрос на сервер OVHcloud. Последовательная консоль показывает вам отправленный JSON:

------------------------------------------------
POST opentsdb.gra1.metrics.ovh.net/api/put
[{"metric": "universe","value":42,"tags":{}}]
------------------------------------------------
beginResult: 0
http: 204
response: xxxx

Если beginResult отрицательный, соединение с сервером OVHcloud не удалось. Это могло означать, что FINGERPRINT это неправильно.

Если http нет 2xx (должно быть 204), сервер не может обработать ваш запрос. Это может означать, что TOKEN это неправильно.

У вас есть 204? Большой! Это успех. Давайте проверим это на Grafana…

Настроить Grafana

Перейдите на сайт OVHcloud Grafana: grafana.metrics.ovh.net/login. Войдите в свою учетную запись OVHcloud.

Настроить источник данных

Щелкните «Добавить источник данных».

• Имя : выберите одно
• Тип : OpenTSDB
• URL : https: // <хост, полученный от вашего менеджера (см. Ниже)>
• Доступ : прямой
• Установите флажок «Обычная аутентификация»
• Пользователь : метрики
• Пароль : <Прочитать токен у вашего менеджера (см. Ниже)>

Нажмите кнопку «Добавить»…



… И сохраните его.

Создайте свою первую диаграмму

Вернитесь на grafana.metrics.ovh.net/ и нажмите «Новая панель управления».



Щелкните «График».



Щелкните «Заголовок панели», затем «Изменить».



Выберите свой показатель в поле «Название показателя». Программное обеспечение должно предлагать имя Universe (имя, указанное в программе Arduino). Если это не так, это означает, что показатели были отправлены Wemos неправильно. Закройте панель «редактирования» (щелкните крестик справа) и сохраните свою конфигурацию (вверху слева в окне).

Анализ результатов

Повышение температуры

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

1. Между 11:05 и 11:10 есть шаг около 85 ° C. Кажется, это влага сушившей духовки.
2. Затем происходит падение температуры, поэтому я добавил еще дров в духовку (то есть добавил холод).
3. Примерно в 11:20 наклон полегче, и я не знаю почему. Огонь недостаточно сильный? В кирпиче больше влаги?

Выпадающее меню температуры

На этом этапе я переместил все угли в задней части духовки и поместил датчик там, где горел огонь. Вот почему диаграмма начинается с 400 ° C.

1. Падение температуры выглядит как F (t) = A / t
2. Примерно в 15:40 я сменил блок питания с телефона, подключенного к сети 230 В, на автомобильный аккумулятор с регулятором напряжения (что показалось хреновым)
3. С 15:00 до 17:00 температура окружающего воздуха довольно высокая. Был солнечный день, поэтому контур напрямую нагревало солнце.

В этом году OVHcloud отмечает 20-летие своей экосистемы.



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

К 20-летнему юбилею мы хотели провести саммит OVHcloud, похожий на нас, саммит OVHcloud, который окажет положительное влияние на сообщество.



Таким образом, мы решили передать все оборудование, использованное для установки стендов, на благотворительность. Мы выбрали организацию AssoAurore, команды которой принимают, обслуживают и сопровождают более 37 000 человек, оказавшихся в нестабильном или изолированном положении на пути к социальной и профессиональной интеграции.

Ассоциация « Феникс», которая борется с пищевыми отходами, собрала все неоткрытые продукты и распространила их по своей сети.



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