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

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



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

На свой 7-й саммит OVHcloud собрал все свое сообщество на ежегодную встречу в Порт-де-Версаль, Париж. На вступительной речи, представленной основателем и председателем OVHcloud Октавом Клаба и генеральным директором Мишелем Поленом, за мероприятием следили почти 10 000 человек, посетив выставку Paris Expo или воспользовавшись видеопотоком по всему миру.

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

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

Постоянные инновации для облака SMARTer

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

Поддержка лиц, принимающих решения в сфере ИТ, в переходе на цифровые технологии с помощью Enterprise

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

Поддержка лиц, принимающих решения в сфере ИТ, в переходе на цифровые технологии с помощью Enterprise

С помощью корпоративных продуктов и решений лица, принимающие решения в области ИТ, имеют возможность защитить свои проекты цифрового перехода на основе прозрачного, обратимого, прогнозирующего и мульти-локального облака. В этом году портфель Bare Metal будет пополнен кластерами выделенных серверов на основе частной сети с гарантированной производительностью через стандартные API-интерфейсы для лучшей автоматизации. Компания будет в ближайшее время обновить свою линейку премиум настраиваемым выделенных серверов HG с последнего поколения Intel® Cascade Lake ™ и 2 - ^го поколения AMD EPYC ™ процессоров, чтобы предложить пользователям еще больше производительности и надежности. Наконец, группа реализует свою глобальную стратегию сертификации и проходит процесс квалификации SecNumCloud . 

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

С линейкой продуктов Public Cloud разработчики могут начать свою деятельность мгновенно, с гибкостью ресурсов по запросу, которые позволяют им легко и быстро регулировать использование ресурсов в соответствии со своими потребностями. Компания также остается верна своим обязательствам, используя открытые и совместимые стандарты: теперь доступно публичное облачное хранилище с поддержкой S3 API, и скоро будет завершено согласование общедоступного облака с инструментами RefStack.

Услуги общедоступного облака также расширяются во всем мире: платформа аналитических данных (ADP) теперь позволяет развертывать предварительно настроенные кластеры больших данных менее чем за час в регионах общедоступного облака в Европе, Канаде и Азиатско-Тихоокеанском регионе. Наконец, OVHcloud недавно запустила ряд частных баз данных на основе PostgreSQL, которые полностью управляются и адаптированы к производственным потребностям, чтобы пользователи могли сосредоточиться на своей основной деятельности.

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

Системные администраторы могут использовать серверные решения для построения своей инфраструктуры по лучшей цене и производительности, доступным на рынке. В этом году OVHcloud полностью изменил дизайн выделенных серверов, стремясь упростить его и сделать более универсальным. Чтобы удовлетворить требования средних предприятий, государственных учреждений и университетов к масштабируемости и производительности, OVHcloud недавно выпустила новую линейку  выделенных серверов для инфраструктуры . Вы можете использовать их для построения серверных архитектур в кластерах и управления большими базами данных. Все серверы в линейке Infrastructure оснащены новейшей технологией OVHcloud Link Aggregation (OLA )., который позволяет пользователям объединять сетевые интерфейсы каждого сервера для повышения его доступности, одновременно изолируя его от общедоступной сети и возможных угроз. Некоторые серверы в линейке Infrastructure также предоставляют расширенные функции безопасности с помощью технологии Intel® Software Guard Extensions (SGX), которая полностью изолирует код, который выполняется, и данные, которые обрабатываются. 

OVHCloud также запустит в начале 2020 года свое совершенно новое предложение виртуального частного сервера. Просто и легко масштабируется, от STARTER до ELITE. Он поставляется с такими опциями, как автоматическое резервное копирование и 99,9% SLA.

Расширение присутствия владельцев бизнеса в Интернете и делового общения с помощью решений Market

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

Наконец, как чистый игрок в инфраструктуре как услуги (IaaS), OVHcloud полагается на обширную сеть партнеров, обладающих всеми навыками, необходимыми для развертывания и обслуживания услуг для своих клиентов. Чтобы инвестировать в это, компания переработала партнерскую программу OVHcloud, чтобы лучше поддерживать цифровые преобразования компаний. Это также еще один способ, которым компания фокусируется на своей интернационализации. Программа открыта и соответствует ДНК OVHcloud, и в ее первые участники уже входят такие компании, как Thales, Capgemini и Deloitte.

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

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



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

Как Swift хранит файлы?

Узлы, отвечающие за хранение данных в кластере Swift, являются «объектными серверами». Чтобы выбрать серверы объектов, которые будут содержать определенный объект, Swift полагается на согласованное хеширование:

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

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

Давайте посмотрим на пример. В этом случае мы будем использовать только 2 бита из контрольной суммы md5 (слишком мало, но рисовать гораздо проще! Всего 4 раздела)



При загрузке файла, от его имени и других элементов, мы получаем контрольную сумму md5, 72acded3acd45e4c8b6ed680854b8ab1. Если мы возьмем 2 старших бита, мы получим раздел 1.

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

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

Политика Swift

Мы только что видели, как наиболее распространенная политика Swift — хранить идентичные копии объекта.

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

Давайте сравним их сейчас.

«Политика реплик», которую мы только что описали. Вы можете выбрать, сколько копий объектов вы хотите сохранить.



Тип политики «кодирование стирания»



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

В OVHcloud мы используем политику 12 + 3 (12 частей от объекта и 3 вычисляемых части)

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

Почему это проблема?

В кластерах, где у нас есть комбинация политики кодирования стирания и среднего размера объекта 32 КБ, мы получим более 70 миллионов файлов * на диск *.

На сервере с 36 дисками это 2,5 миллиарда файлов.

Кластеру Swift необходимо регулярно перечислять эти файлы, чтобы:

• Подавать объект покупателям
• Обнаружение битовой гнили
• Реконструировать объект, если фрагмент был потерян из-за сбоя диска

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

В следующем посте мы увидим, как мы это решили.

В нашей серии статей о переносе инфраструктуры веб-хостинга из Парижа на Gravelines (первая из которых находится здесь ) мы не упомянули базы данных. Однако это очень важная часть, так как необходимо перенести 800 000 баз данных!

В этой новой серии публикаций мы расскажем вам о нашем опыте работы с базами данных веб-хостинга.

Как обрабатывать 800 тыс. Баз данных?

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

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

OVH предлагает два типа баз данных:

• Общие базы данных (которые мы называем SharedSQL )

• Частные базы данных (которые мы называем, как вы уже догадались, PrivateSQL)

Что такое SharedSQL?

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

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

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

Что такое PrivateSQL?

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

У каждого пользователя есть свой сервер? На самом деле, нет! Несколько лет назад мы использовали технологию Docker для контейнеризации наших баз данных, мы уже обсуждали это в этом посте: www.ovh.com/en/blog/docker-administration-databases-a-flying-ideas/. В PrivateSQL закрыто не только пространство базы данных, но и гарантировано выделенное службе ОЗУ. Это означает, что в любых обстоятельствах производительность остается неизменной.

Семь отличий!

При рассмотрении вопроса о миграции нам пришлось изучить разницу в архитектуре между Paris и Gravelines.

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

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

Вот упрощенная схема PrivateSQL



Напротив, базы данных SharedSQL на самом деле не были согласованы. Когда мы настраивали центр обработки данных Gravelines в 2016 году, мы воспользовались гибкостью Docker, чтобы пересмотреть нашу технологию баз данных и, следовательно, адаптировать наше прежнее решение.

Небольшая сравнительная схема SharedSQL в Париже и Gravelines:

SharedSQL на Paris P19 и Gravelines:



С одной стороны (в Париже) у нас есть серверы с единой системой управления базами данных (MySQL), на которых размещено 2500 баз данных на одной машине.

С другой стороны (в Gravelines) мы добавили уровень: контейнеры Docker имеют одну и ту же систему баз данных (MySQL), на которой размещается до 250 баз данных. На каждой машине размещается по 10 контейнеров.

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

Вот что он дает:



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

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

И вдруг у нас возникла еще одна проблема миграции.

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