• i7-4790k / 16 / 240 SSD — 2300р
• i7-4790k / 32 / 240 SSD — 2900р
• E3-1225v2 / 16 / 3x 2ТБ — 2300р
• E3-1245v2 / 32 / 3x 2ТБ — 2700р
• E3-1245v2 / 32 / 2x 480SSD — 2700р
• E3-1231v3 / 32 / 2x 480SSD — 3100р

Писать тикет тут bill.ovh/billmgr

Для того, чтобы предложить Вам самые последние возможности нашего решения Public Cloud, нам нужно будет обновлять API, используемый для заказа ключевой компонент OpenStack: Keystone.

Напомним, что Keystone является аутентификация и авторизация API, который управляет инфраструктурой Public Cloud.

Когда обновление происходит?
С 01 октября 2019 года, все файлы Open-RC будет генерироваться с версией 3.0 API Keystone для панели управления OVHcloud, OpenStack Horizon, и API.

24 марта 2020 года, мы будем отключить версии 2.0, оставив только версии 3.0 включены.

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

Пожалуйста, нажмите на следующую ссылку, чтобы просмотреть список вызовов, которые больше не будут быть поддержаны Keystone 2,0: auth.cloud.ovh.net/v2.0/

Они будут заменены: auth.cloud.ovh.net/v3/

Для получения дополнительной информации о версии 3.0, пожалуйста, прочитайте документацию здесь и рекомендация здесь.
docs.openstack.org/api-ref/identity/v3/index.html
docs.openstack.org/keystone/pike/contributor/http-api.html

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



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


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

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


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

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

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

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

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

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

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

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

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

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

Читать тест
Мы начнем с теста чтения, используя блоки 4k, и, поскольку у нас 32 vCores для этой модели, мы будем использовать 32 задания. Пойдем!

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

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

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

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

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

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

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

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

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


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


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


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

Варианты обложек с 3D-печатью:


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


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


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


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

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

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


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


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


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


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

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


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


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


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



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

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


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

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

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

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


Правила

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

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

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


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

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

migrate-p19

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

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

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

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

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


2. В пункте назначения (Гравелин)
Получить дамп и импортировать его.
Создайте пользователя и разрешения с правами записи.


3. Переключиться на новую базу данных
На данный момент сайт все еще вызывает базу данных в Париже. Таким образом, веб-сайт (независимо от того, находится ли он в Париже или Gravelines) может связываться с новой базой данных, мы будем обновлять DNS, чтобы имя указывало на экземпляр Gravelines MySQL, а не на Париж.
Доступ для чтения к парижской базе данных также удален.
Наконец, мы обновим нашу информационную систему, чтобы вы могли получить дамп с 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: Миграция 800K баз данных
Теперь, когда мы знаем, как переносить одну базу данных децентрализованным способом, давайте заполним CloudDB всеми базами данных, которые мы хотим перенести! Вот как выглядит миграция:

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

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

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

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

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

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);

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

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

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

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



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

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

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

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


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

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


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

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

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


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


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

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

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


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


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


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


Здесь у вас есть параллельное сравнение стандартного, водоблока ЦП и более компактного водоблока графического процессора:


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


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


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

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

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

В настоящее время архитектура распределяет услуги в «специфических» регионах OpenStack (например GRA3). Каждое место может быть идентифицированы два или три буквами (GRA для Гравелин здесь), а затем рядом (3 для третьей области в этом месте).

Мы будем перемещать объект хранения и Cloud Архивные услуги от этих конкретных регионов в «глобальных» регионах.

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

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

Как только эта операция будет завершена, конкретные регионы GRA1, GRA3 и GRA5 больше не хозяин объекта хранения и облака Архивные услуги. Они будут автоматически доступны в проекте с помощью нового глобального GRA региона.

Эта операция будет проводиться во всех местах общественного Облако: Гравлин (GRA), Страсбург (SBG), Beauharnois (BHS), Варшава (WAW), Лондон (Великобритания), Франкфурте (DE), Сингапур (SGP) и Сидней (SYD).

Каковы следующие шаги?
1. Сейчас: Объявляя новые регионы мира.
Новые глобальные регионы будут автоматически добавлены к существующим проектам, и могут быть использованы для объектов хранения и облачных служб архивирования, с помощью конечных точек как для конкретных и регионов мира.

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

Кроме того, стоит модификации конфигурации синхронизации для контейнеров, а также адрес по имени домена (CNAME или TXT DNS записей). Если ваши домены нацелены наш IP — адрес непосредственно (запись), вам необходимо переключиться на запись CNAME.

Все новые проекты Public Cloud будет их объектов хранения и Клауд Архивные услуги однозначно направлены на новые глобальные регионы.

2. 18 февраля 2020: Удаление конечных точек для объектов хранения и облачного Архива в конкретных регионах.

Некоторые конечные точки Swift будут удалены из каталога услуг (объявленного Keystone) для конкретных регионов, а затем будут доступны только для регионов мира.

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

Благодарим Вас за выбор OVH.
Облако команды Public

• 2x2.5G / 4x2.5G for Baremetal Low-End (KS, SYS, RISE, ADV)
• SuperSmartNIC (SSN) with PCIe for 4 servers
• Segment Routing IPv6 (SR6)
• OpenStack Neutron
• Opensource HW/SW

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

Параллельно с этим, мы работаем над инновациями, чтобы включить сервера дешевле 150E которые у нас «чемпион мира». Сегодня у нас есть 4 семейства серверов: KS, SYS, Rise и ADV. Эти четыре линии будет держать их, даже если названия изменится в связи с тем, что наконец-то управляются OVHcloud в одном менеджере и API.

Существует много изменений вокруг сети. Сегодня мы предлагаем 100M на KS, или 1G 2x1G на всех этих серверах. Мы построили линейку инфра, чтобы иметь возможность предложить либо 2x2.5Gbps дешевле чем 150E сервер. После коммерческого, мы можем синхронизировать NIC на 1G или 2.5G и предложить vrack или нет, но по умолчанию, мы соединим все серверы 2x2.5Gbps.

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

Мы решили сделать наш SmartNIC иначе (иначе SmartNIC рынок только бы купил):

• A SmartNIC не для одного, а для серверов 4 серверов. Таким образом, это снижает затраты на сервере и может быть такое же предложение на серверах дешевле 150E. Это много SuperSmartNIC (ПКР).
• Наш SSN не подключен к серверу с помощью кабеля Ethernet, а через PCIe кабели. Это позволяет нам сделать «включение» сервера на водяном охлаждении, не только электрическая мощность, но и в сеть. Сервер запускается в стойке за 1 секунду, и включает его. А так как это PCIe, просто кабель 2x NIC. Это гораздо проще и дешевле.
• Система SSN поддерживает любой сервер, в любом возрасте технологий, так как даже серверы на старых КС, SYS могут быть соединены в этой PCIe SSN и пользоваться сетью 2x2.5G по умолчанию.
• Все это позволит нам развернуть SR6 (сегмент маршрутизации IPv6) и выполнять все типы пакетов в одной сети, в то время как управление простой способ чешуйки и поэтому предлагают все больше и больше возможностей для наших клиентов BareMetal PCI, PCC и хранения. Является ли это 2.5G или 25G или 50G или 100G, все серверы будут пользоваться теми же функциями. NAT, IP-LB, IP FO, частная сеть L3, L2, ACL, QoS, при VLAN под сети, межсетевой экран и т.д.

В течение нескольких месяцев мы завершим прототип и передадим версии альфа/бета. Нам нужно будет протестировать наши прототипы, и мы находим ошибки. В то же время, по-прежнему много работы на HW, но и на SW. Все это вооруженных сил США переписать всю оркестровку наших контроллеров домена.

После того, как стабильная версия будет работать в наших ДЦ, мы будем делать HW и SW с открытым исходным кодом.

искренне
октава

Каждая стойка питается от трехфазных кабелей «32A» — для распределения питания в стойке мы используем этот SmartFuse — каждый сервер контролируется + имеет индивидуальную электробезопасность — связь на основе CPL через Ethernet (зашифрованная) — считывание больше Слава командам!