Водяное охлаждение: от инноваций до разрушения - Часть I

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

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



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

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

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

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


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

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


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


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


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


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

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

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


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


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


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


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


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


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


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

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

Management is changing for Public Cloud



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

В настоящее время архитектура распределяет услуги в «специфических» регионах 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

SD < 150E



  • 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"

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



OVHcloud dedicated servers | Rise Limited Edition



Серверы Selected Rise bare metal теперь предлагаются по еще более выгодной цене и без платы за установку, предлагая идеальные хостинговые решения для ваших веб-сайтов и приложений.

Серверы Rise основаны на платформах Intel Xeon, что гарантирует вам высокую производительность. Все серверы Rise включают ряд функций, таких как пропускная способность 500 Мбит/с, пространство для хранения 500 ГБ и широкий спектр операционных систем.
www.ovh.ie/dedicated_servers/rise/

Rise-LE-1
Limited Quantity
From €52.24 ex. VAT/month
No stup fees (€49.99)
www.ovh.ie/dedicated_servers/rise/rise-limited-edition-1/

Rise-LE-2
Limited Quantity
From €61.74 ex. VAT/month
No setup fees (€59.99)
www.ovh.ie/dedicated_servers/rise/rise-limited-edition-2/

Просмотрите все цены на этот диапазон выделенных серверов OVHcloud
www.ovh.ie/dedicated_servers/rise/prices

Акция! Выделенные серверы i7-4790K (-20%)



Выделенные серверы на i7-4790K в Европе (FR) и Канаде доступны уже сейчас для заказа на ABCD.HOST

Прайс-лист

Установка сервера 1580р. (единоразовый платеж). Количество ограниченно.

Прайс-лист с актуальными ценами на все основные конфигурации выделенных серверов.

Сеть 500 Mbps, трафик безлимитный, Anti-DDoS, OS Linux,Windows Server 2012/2016, IPMI 1800₽-24H.

Для заказа создайте тикет в личном кабинете: panel.abcd.host/billmgr
Или пишите на почту: sales@abcd.host

abcd.host/ru/akcziya-vydelennye-servery-i7-4790k

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

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


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

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

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

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

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

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

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



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

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


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

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

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

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

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

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



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

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

i7-4790k - RE RE RE

В очередной раз, случайно, или специально, акция тарифы — стали доступны для заказа в API :)

Спешим заказать бомж дедик с дисками от 2015 года. (по часам, по износу даже 10% не прошло там обычно)

i7-4790k / 16 / 240 SSD — 2300р/мес +1600р активация +1600р 16 IP разово
i7-4790k / 32 / 240 SSD — 3100р/мес +1600р активация +1600р 16 IP разово
Локации

Чтобы заказать нада написать тикет тут, вручную.
bill.ovh/billmgr