К демократизации премиального Bare Metal Cloud

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



Начало революции
OVHcloud предлагает широкий портфель облачных продуктов и решений для четырех вселенных (веб-облако, Bare Metal Cloud, публичное облако и размещенное частное облако). Облако, которое мы предоставляем, всегда проектируется и разрабатывается с учетом потребностей наших клиентов, и мы всегда стараемся понять их бизнес, чтобы иметь лучшее представление об их проблемах.



Мы начали наши обсуждения рынка Premium Bare Metal Cloud еще в 2016 году. В то время мы получили отзывы от нескольких клиентов относительно нашего ценового позиционирования на этот конкретный диапазон мощных серверов, которые соответствуют очень высоким требованиям к хранению. Наши изделия из чистого металла были слишком дорогими по сравнению с тем, за что они были готовы платить. Затем мы работали, в частности, с двумя клиентами. Поскольку они были готовы разделить с нами свои расходы, мы смогли спроецировать их экономическую модель на нашу бизнес-модель. Эти два клиента размещали свои собственные услуги через колокацию, без круглосуточной поддержки местной команды, и у них была небольшая интернет-сеть. Они инвестировали в свои собственные серверы, рассчитав свои цены за 5-летний период. Проведя этот анализ, мы поняли, что можем предложить им эти мощные серверы по более низкой, гораздо более конкурентоспособной цене. Но для решения этой задачи нам потребуется проделать серьезную работу, которая, вероятно, займет несколько лет.

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


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

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

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

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

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

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

Для OVHcloud эти большие суммы являются основой нашей действенной модели — инвестирования в строительство и улучшение наших центров обработки данных, обновление производственного оборудования и приобретение новых производственных помещений. Наша бизнес-модель полностью демистифицирует эти масштабные инвестиции, поскольку она изначально обеспечивает возврат инвестиций. Наша способность инвестировать за счет повышения прибыльности позволила нам привлечь капитал в 2016 году (279 миллионов долларов от KKR и TowerBrook) и даже привлечь долг в конце 2019 года (976 миллионов долларов). CAPEX — это наш основной вектор создания стоимости. Мы должны постоянно инвестировать в будущие инновации и инфраструктуру, чтобы обеспечить нашу устойчивость и конкурентоспособность.

Благодаря всей работе, проделанной за последние три года, мы также смогли внести огромные изменения в нашу бизнес-модель. С помощью сложного анализа, который мы получили, теперь мы можем рассчитать цену сервера на основе нескольких переменных, таких как время выполнения обязательств, объем заказа, тип сервера и инвестиционные затраты на инфраструктуру и сам бизнес. Эта новая финансовая модель внутри компании называется «Джекпот», так как любое сокращение наших капитальных или операционных расходов (операционных расходов), безусловно, снизит цену для наших клиентов. И в случае, если мы не предоставляем ожидаемую цену — а это означает, что наши решения CAPEX или OPEX недостаточно оптимизированы — мы всегда ищем, где мы можем внедрять инновации и на каком уровне нам нужно изменить. Потому что, если мы уменьшим наши затраты, мы снизим наши цены, а не увеличим маржу. Эта постоянная самоанализа через инновации позволяет нам предлагать клиентам более выгодные цены, как мы скоро сделаем это с Premium Bare Metal Cloud.

T3-96-6KW-W
96 серверов на стойку мощностью 6 кВт
при 4 уровнях стоек у нас 384 сервера типа ADV-1/2/3
Все серверы имеют водяное охлаждение.
PUE = 1,07
Это означает лишь 7% потерь энергии!


Новые методы использования ресурсов
Наша цель — стать мировым экспертом в Premium Bare Metal Cloud. Мы хотим встряхнуть рынок с 350 до 2500 долларов в месяц (для серверов премиум-класса высшего класса) и стать эталоном, как мы уже делаем для серверов начального и среднего уровня. Клиенты, которым нужна максимальная мощность и мощность, начнут замечать первые результаты нашей стратегии. Чтобы лучше выполнять свои задачи, к концу 2020 года наши публичные цены упадут. Но мы сохраним такую же высокую производительность. В дополнение к нашей промышленной модели, которая уникальна в плане полного контроля и позволяет нам постоянно адаптироваться, в последние месяцы именно наша новая бизнес-модель «Джекпот» помогла нам пойти еще дальше. И на основе этой новой модели мы рассмотрели все — серверы, сеть, энергоснабжение и водяное охлаждение. Сейчас, более чем когда-либо, мы являемся лидером по цене по своему замыслу.

POC HGv2 / FSv2 T5 2U 2x25G+2x50G


Новая финансовая модель, позволяющая нам более точно отслеживать жизненный цикл продуктов, также позволяет нам пересмотреть наши модели обязательств. До конца года мы предложим более конкурентоспособные цены по долгосрочным обязательствам. В дополнение к уже доступным моделям ежемесячной оплаты, то есть без обязательств или с обязательством на 6, 12 или 24 месяца, мы также предложим планы с обязательствами на 3, 4 или 5 лет. Наши цены будут еще лучше для клиентов, которые могут использовать как объем (3 или 12 стоек с 48 или 96 серверами), так и продолжительность (3, 4 или 5 лет). В будущем наши клиенты также смогут получать почасовые расценки на Bare Metal с посекундной оплатой.

Наконец, для клиентов, которым требуется много серверных стоек и которые не хотят управлять своей инфраструктурой, мы уже можем предоставить частные помещения в наших центрах обработки данных с 12, 24 или 48 стойками *, оборудованными камерами, значками и журналами. Этот вариант использования удовлетворяет потребности не только клиентов Bare Metal Cloud, но также клиентов Public Cloud и Hosted Private Cloud в режиме «частного региона». Начиная со 100 стоек, мы можем поставить настоящие частные центры обработки данных в зданиях третьих сторон (в помещениях клиентов) *, где бы они ни находились. Это значительно снижает их затраты. Для этих центров обработки данных мы применяем наш промышленный и технический опыт, в том числе нашу эксклюзивную технологию водяного охлаждения, и все наши аппаратные инновации, включая самые последние технологии на рынке. Мы также управляем всеми уровнями программного обеспечения и их жизненными циклами.

Глобальное воздействие
Цель этого сообщения в блоге — не детализировать наши будущие предложения, а объяснить долгий путь, который привел к снижению цен на Premium Bare Metal Cloud. Но если вы подписаны на мою учетную запись в Twitter (@olesovhcom), вы, возможно, видели некоторые их превью, потому что я регулярно делюсь информацией о нашей работе.

«We need GPUs. Lot of GPUs.»
New POC: AI Training, Inference, (Software in VDI)aaS.
OVHcloud will offer a large range of the products AI/DL+ML based on GPU/CPU/FPGA/Optical.




Всего OVHcloud скоро предложит около 300 моделей Bare Metal Cloud! Это очень широкий диапазон, и наши маркетинговые команды взяли на себя впечатляющую задачу, предложив упрощенный просмотр, чтобы вы могли найти именно то, что вам нужно. В конце октября 2020 года название меню изменится с «Сервер» на «Bare Metal Cloud». Это будет первым шагом в переходе, который произойдет в ближайшие месяцы, с гораздо более ориентированным на использование подходом, таким как виртуализация, хранение, глубокое обучение, базы данных и т. Д. Цель состоит в том, чтобы упростить ваше путешествие, и поможет вам легко выбрать модели, наиболее соответствующие вашим потребностям.

Как внутренние клиенты, наши три других облачных юниверса (веб-облако, общедоступное облако, размещенное частное облако), которые все полагаются на наши инфраструктуры Bare Metal Cloud, также получат выгоду от этих инноваций и новых цен. Прежде чем оказывать такое глобальное влияние, нам нужно было изучить основы облака. Ожидайте отличных анонсов в 2020-2021 годах!

working on BETA Public Cloud IAaaS Deep Learning for training and inference… deploying 2 clusters (> 5M cores each) in FR and CA… the technology PaaS will allow to reduce the cost by 50% vs hyperscalers and change the mindset: run the jobs, not VMs



Чтобы узнать больше, отправляйтесь на OVHcloud EcosystemExperience, наше новое виртуальное мероприятие, которое состоится 3, 4 и 5 ноября.

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

Бастион OVHcloud SSH - Часть 2: головокружение от делегирования

Это вторая часть серии блогов, вот и первая. Ранее мы обнаружили, что бастион не является вашим обычным SSH-хостом jumphost (на самом деле, мы обнаружили, что это вообще не Jumphost), и обсудили, как делегирование было одной из основных функций, которые нам изначально нужны. Итак, давайте углубимся в эти концепции. На бастионе есть две совместимые модели доступа: персональный и групповой.


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

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

Спросите ИТ-специалистов
Другой способ справиться с этим может заключаться в предоставлении ограниченному количеству людей, например службам безопасности, право добавлять личные доступы другим лицам. Таким образом, люди становятся менее автономными, но это может быть полезно, если добавление доступа должно осуществляться через нормализованные процессы. Это также дает некоторые приятные эффекты: как системный администратор, вы можете создать 3 отдельные учетные записи на удаленном компьютере и сопоставить их с каждой добавляемой учетной записью бастиона. Это хороший метод для достижения сквозного отслеживания; в том числе на удаленном сервере; где вы, возможно, захотите установить auditd или аналогичные инструменты. Это также можно сделать в режиме помощи самому себе, но это может быть сложнее обеспечить.

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

Групповой доступ — Let's Rock
Группа состоит из трех компонентов:
  • Список участников (аккаунты, представляющие отдельных людей)
  • По крайней мере, один набор групповых выходных ключей
  • Список серверов (фактически IP)


Список серверов
Список серверов на самом деле представляет собой список IP-адресов или IP-блоков. Они сопоставляются с вашими серверами, сетевыми устройствами или чем-либо еще с поддержкой SSH, имеющим IP-адрес (на котором был установлен ключ исходящей группы). Технически этот список состоит из трех элементов: удаленный пользователь, удаленный IP (или блок IP), удаленный порт. То, что относится к личному доступу, также применимо и здесь: добавление сервера в список не дает ему доступа волшебным образом, сначала необходимо установить открытый ключ исходящей группы. Конечно, управление установкой этих ключей вручную быстро становится непрактичным, но вы можете рассмотреть эту часть конфигурации серверов, поэтому ими следует управлять с помощью той централизованной системы конфигурации, которую вы уже используете (Puppet, Chef, Ansible, / bin / cp… подожди, нет, ударил последний).

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

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

И еще немного
Мы рассмотрели основы группового подхода, но, поскольку нам нужна большая гибкость и делегирование полномочий, нужно охватить еще немного. Помните, я сказал, что в группе 3 компонента? Я соврал. В группе есть больше, чем просто участники. Дополнительные групповые роли включают:
  • Гости
  • Привратники
  • Aclkeepers
  • Владельцы

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

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

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

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


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

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

Головокружение еще не закончилось? Теперь о самой влиятельной роли: админке бастиона. Эта роль должна быть предоставлена ​​только нескольким лицам, поскольку они могут выдавать себя за кого угодно (даже если, конечно, когда они это делают, это регистрируется и заставляет наш SIEM покраснеть), и на практике не следует отдавать никому, кто еще не получил root-права в самой операционной системе бастиона. Помимо прочего, они управляют конфигурацией бастиона, где объявлены супервладельцы. Задержи дыхание. Готов? Им разрешено давать право давать право давать право давать право доступа. Вот почему делегирование лежит в основе системы: у каждого есть свой набор обязанностей и потенциальных действий, без необходимости спрашивать администратора бастиона.

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


Как вы могли заметить на скриншоте выше, версия программного обеспечения Bastion очень близка к 3.00.00! Может быть, приближается интересная веха?

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

OVHcloud приобретает OpenIO

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

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

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

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

Спасибо, что выбрали OVHcloud.
Команда OVHcloud

New dedicated server ranges now available in the US!



Объявляя полное обновление диапазонов продукции выделенного сервера OVHcloud США

OVHcloud объявляет полное обновление своих выделенных диапазонов серверных продуктов в своих центрах обработки данных США по приведению в соответствие описи с мировым каталог OVHcloud.

Обновления обновляет инфраструктуру и игры диапазоны и вводит заранее и Райз диапазоны. Серверы HG и Best Value продолжают быть частью каталога США. Для решения меняющихся потребностей бизнеса, новые диапазоны серверные расширенные функции, такие как:
  • Процессоры AMD
  • Улучшенная скорость сети
  • Горящие цены на краткосрочные обязательства 12- и 24- месяц
Существующая инфраструктура будет продолжать оказывать поддержку OVHcloud США в обозримом будущем, однако, старые диапазоны сервера больше не производятся или на продажу. Мы сообщим вам, в случае, если мы прекратить продукт или услугу, или если ваша инфраструктура достигает конца жизни.

Проверьте наши новые выделенные диапазоны сервера здесь. Пожалуйста, ответьте на это письмо, если у вас есть какие — либо вопросы.
us.ovhcloud.com/dedicated-servers/prices/

Спасибо,
Паскаль Жайон
SVP продукт и цифровой Accounts
OVHcloud

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

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


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

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

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

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

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

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

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



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

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


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

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

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

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

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

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



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

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

Приглашение: OVHcloud Summit



Привет.

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

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

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

Это было 20 лет назад, не было никакого имени для нашего бизнеса. Мы поэтому называется OVH «On You Спит". Сегодня все знают, что OVH предлагает облако. Для того, чтобы прояснить и вновь подтвердить нашу стратегию в этом году «OVH» меняет свое название на «OVHcloud». Саммит OVHcloud также возможность возобновить наши обязательства в качестве европейского лидера, представляющего собой альтернативу во всем мире, мы делаем пункт, чтобы позволить вам контролировать свои данные, обновлять и осуществлять свободно.

Я буду очень рад видеть вас четверг, 10 Октября.

Приходите!
С уважением, октава
@olesovhcom

summit.ovhcloud.com/fr/subscription/

Зарегистрируйтесь сейчас OVHcloud Summit

Обеспечение безопасности и контроля ваших данных


7е издание саммита OVHcloud отметит 20 — летний OVH
Это событие будет возможность поблагодарить нашу экосистему. В этот день мы вновь подтверждаем обязательство, которые делают нам альтернативный плеер в облаке в течение двух десятилетий.
Вы также узнаете наши новейшие решения и инновации. Это позволит вам сохранить полный контроль над вашими данными и максимально свободно.
summit.ovhcloud.com/fr/subscription/
summit.ovhcloud.com/fr/