Рейтинг
0.00

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

33 читателя, 1165 топиков

Инфраструктура внутренних баз данных OVHcloud

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


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

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

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

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

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

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

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



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

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


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

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

Это позволило нам автоматизировать его более эффективно и абстрагировать сложность различных программ.

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

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

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



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

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

Discover IOStream, the new OVHcloud Lab



Мы рады объявить о выпуске бета — версии нашего первого «I/O» ориентированной полностью управляемых услуг: IOStream, теперь часть OVHcloud Public Cloud.

IOStream это услуга Асинхронных очередей сообщений. Он основан на с открытым исходным кодом протокола Apache Software Foundation, Pulsar и также скоро выставить протокол Кафка!

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

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

Особенности уже доступны:
  • Создать, как вы много тем, как вам нужно
  • Создать как много производителей и абонентов, как вам нужно
  • Использование Apache Pulsar протокола нажать и получение сообщений
  • Управление и визуализировать ваши подписки в режиме реального времени
  • Настройте сохранение и ваш дросселирования на уровне тематического

  • И в ближайшее время:
  • Включить данные многоуровневых для более долговечности по Вашей тематике, эта функция разгружает очередь для хранения объектов
  • Доступ к данным эффективно с низкой латентностью, где бы вы ни находились.
  • Используйте стандартные интерфейсы, такие как Кафка, MQTT, HTTP и SMTP WebSocket

Итак, как пользоваться ей бесплатно?
labs.ovh.com/iostream
gitter.im/ovh/ioStream

Облачные игры: союзники Blade с OVH




Два французских чемпиона по облачным технологиям только что создали партнерство. Blade, который разрабатывает игровой сервис для виртуальных ПК в облаке, объединяет усилия с OVHcloud, чтобы встретиться с гигантами индустрии облачных игр в США. В рамках этого альянса служба Blade Shadow будет использовать серверы OVH в основном для зарубежных заказчиков. Кроме того, Blade привлекла 30 миллионов евро для развертывания своего сервиса облачных игр. Интервью с Эммануэлем Фрейндом, соучредителем Blade. — Tech & Co, во вторник, 29 октября 2019 года, представленный Себастьеном Куасноном на BFM Business.

Tech & Co — это место встречи цифровых новостей о BFM Business. Себастьян Куаснон, его обозреватели и его гости комментируют основные тенденции, которые встряхивают игроков в экономике и технологиях.

IOT: отправка данных в серию метрик OVHcloud от Arduino



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



После удаления углей, я должен расставить приоритеты для посуды, которую я хочу приготовить, так как температура падает:
  • Пицца: 280 C
  • Хлеб: 250 С
  • Рисовый пудинг: 180 C
  • Безе: 100 C
Я построил первую версию термометра с Arduino, чтобы иметь возможность проверить температуру. Этот термометр, изготовленный из термопары (то есть датчика, который измеряет высокие температуры), отображает внутреннюю температуру на небольшом ЖК-экране.



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

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

Это требует некоторой автоматизации. К счастью, у OVHcloud есть решение: Metrics Data Platform: www.ovh.com/fr/data-platforms/metrics/

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

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

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


Реализация: Wemos
ESP8266 не так прост в использовании:

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


Вот почему для нас лучше использовать решение, которое реализует ESP8266. Вот этот Вемос!
  • Питание от 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 и откройте окно «Настройки» («Файл»> «Настройки»).

Введите arduino.esp8266.com/stable/package_esp8266com_index.json в поле «Дополнительные URL-адреса менеджера доски объявлений». Вы можете добавить несколько URL, разделяя их запятыми.


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

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

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


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

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

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

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


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

Получить хост платформы Metrics Data


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

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

Попробуй подключить к тебе сеть wifi
В случае успеха отправьте данные на платформу данных OVHcloud Metrics.
Весь исходный код доступен на моем github: github.com/landru29/ovh_metrics_wemos

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

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

Скопируйте config.h.sample в config.h
Скопируйте токен записи, который вы получили в пункте 5.1 (#define TOKEN «xxxxxx»)
Скопируйте хост, который вы получили в пункте 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
Откройте файл .ino в IDE Arduino (у вас должно быть шесть вкладок в проекте)
Подключите Wemos к вашему компьютеру
Выберите порт из Сервис> Порт
В верхнем левом углу нажмите на стрелку, чтобы загрузить программу
После загрузки вы можете открыть последовательный монитор: Инструменты> Последовательный монитор
Прямо сейчас программа должна выйти из строя, так как Wemos не сможет подключиться к вашей сети Wi-Fi.

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

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

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

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 Metrics
Теперь Wemos размещает запрос на сервере OVHcloud. Последовательная консоль показывает вам JSON, который она отправит:
------------------------------------------------
POST opentsdb.gra1.metrics.ovh.net/api/put
[{"metric": "universe","value":42,"tags":{}}]
------------------------------------------------
beginResult: 0
http: 204
response: xxxx


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

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

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

Настроить Графана


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

Настройте источник данных
Нажмите «Добавить источник данных».



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

Создайте свой первый график
Вернитесь на grafana.metrics.ovh.net/ и нажмите «Новая панель».




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

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

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


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

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

www.ovh.com/blog/iot-pushing-data-to-ovhcloud-metrics-timeseries-from-arduino/

Мы решили пожертвовать все оборудование, использованное во время саммита OVHcloud



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

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



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

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



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