Bare metal за 5 минут: как мы из андерклауда сделали облачный сервис для аренды выделенных серверов

Хоть мы тогда и сами об этом не знали, но создавать сервис для аренды выделенных серверов мы начали два года назад. При запуске новых регионов публичного облака нам требовалось оперативно развернуть множество серверов разных конфигураций по всему миру, но целыми днями заниматься этим вручную никто не хотел. Вместо людей со стальными нервами мы нашли более изящное решение в лице Ironic — сервиса OpenStack для провижининга «голого железа». Совместно с другими инструментами он позволял и раскатывать образ, и настраивать систему, и на тот момент этого уже было достаточно. Позже в Ironic появились такие возможности, что это решение начало закрывать вообще все наши задачи по управлению инфраструктурой в облаке. А раз уж мы справились с этим, то почему бы не сделать на основе служебного инструмента публичный сервис с автоматической подготовкой выделенных серверов?

Шёл 2014 год…
Серверы мы деплоили на коленке через PXE boot и kickstart. Это решение хоть и работало, но имело недостатки:
  • Сети переключались вручную;
  • Выбор сервера и его перевод в загрузку по PXE выполнялся вручную;
  • Сборка рейда и обновление прошивок — тоже manual mode.

Сначала для решения проблемы мы хотели просто написать свой bash-скрипт, который и будет всё делать. К счастью, руки до этого так и не дошли, и мы рассмотрели все существующие на тот момент варианты:
  • MaaS — предлагался как коробочное решение от одной очень солидной компании за не менее солидную сумму;
  • Cobbler — тут нам сказать особо нечего, так как в команде не нашлось инженеров с необходимым знанием технологии;
  • Foreman — казался неплохим решением, тем более что мы использовали Puppet;
  • OpenStack Ironic — хоть инженеров с опытом по этому продукту в команде тогда и не нашлось, но у нас уже был опыт работы с Openstack по виртуализации. Так что ставка была сделана на то, что в будущем мы сможем красиво всё собрать в один OpenStack. Понятное дело, в этом мы глубоко заблуждались, но об этом позже.

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

Шаг 1: автоматизируем управление внутренней инфраструктурой облака
Наши решения работают на основе разных технологий Intel: облачные сервисы — на процессорах Intel Xeon Gold 6152, 6252 и 5220, кеш-серверы CDN — на Intel Xeon Platinum, а в апреле 2021 мы также одними из первых в мире начали интеграцию Intel Xeon Scalable 3-го поколения (Ice Lake) в серверную инфраструктуру своих облачных сервисов. Чтобы вручную управлять всем этим пулом железа для сервисных целей облака, ежедневно разворачивать по всему миру серверы с разными конфигурациями и всё это ещё и как-то поддерживать, нам требовался либо целый штат специалистов, либо инструменты автоматизации, которые бы обеспечили высокий темп экспансии в регионы и облегчили жизнь нашим админам. Как уже говорилось, для этих целей мы решили использовать Ironic. На момент внедрения — два года назад — это был уже достаточно зрелый сервис со следующими возможностями:
  • Удалённое управление серверами;
  • Сбор информации о конфигурациях и коммутации ещё не запущенных серверов;
  • Установка ОС на произвольном сервере;
  • Настройка сети с использованием протоколов 802.1q и 802.3ad.

Нас такое решение вполне устраивало, поэтому на нём мы и остановились, а для настройки операционной системы на сервере решили использовать cloud-init. Рабочий процесс был простым и прозрачным:
  • Сначала формировался загрузочный ISO-диск с информацией о настройках сервера, пакетах и сетевых интерфейсах.
  • На физическом сервере запускался процесс исследования с помощью компонента Ironic Inspect.
  • Затем этот сервер Ironic загружал с конфигурационным образом.
  • Начинался процесс автоматической установки CentOS, настраивались сетевые интерфейсы, ставились пакеты.

Подробней весь жизненный цикл можно увидеть на следующей схеме:


Так всё и продолжалось, пока Ironic становился более зрелым продуктом. Со скрипом, но всё же в нём появились новые возможности, в том числе и всё необходимое для автоматизированного управления RAID-контроллерами, обновления прошивок и развёртывания образов системы с произвольных HTTP-ресурсов через интернет. Так что со временем у нас появилось полноценное решение для автоматизации вообще всех задач по управлению инфраструктурой в облаке — им стала связка Ironic с cloud-init и используемой нами CI/CD. Чем не задел на что-то большее?

Шаг 2: планируем создание новой услуги из андерклауда
Сначала мы использовали инструмент только для служебных целей. Он хорошо справлялся с автоматизацией задач по управлению инфраструктурой облака, но этим наши планы не ограничивались: нам также требовалось подготовить решение для провижининга арендуемых заказчиками выделенных серверов. Оно бы пришлось как нельзя кстати, так как упрощало аренду серверов bare metal для потенциальных клиентов, а сомнений в их наличии у нас не было. На тот момент пользователи и без того часто заказывали у нас выделенные серверы — обычно они разворачивали на них продакшн-среды для высоконагруженных приложений, так как «голое железо» оказывалось производительней и безопасней виртуальных машин, к тому же на нём не было «шумных соседей». Вот только времени на подготовку каждого физического сервера у нас уходило в разы больше, ведь для этого всё требовалось делать вручную:
  • Сначала выбирать из пула доступных наиболее подходящий сервер;
  • Затем применять определённую конфигурацию для оборудования (настроить сетевые интерфейсы, RAID-контроллеры);
  • Постоянно поддерживать в актуальной версии системное ПО (firmware или версию BIOS);
  • Загружать и устанавливать операционную систему, выполнять пост-инстал скрипты.

Автоматический провижининг избавил бы нас от лишних сложностей. К тому же его потенциал не ограничивался упрощением подготовки серверов: он вполне мог лечь в основу полноценного облачного сервиса, с помощью которого пользователи будут за несколько минут разворачивать узлы bare metal, а арендовать выделенный сервер будет не сложней виртуального. Так из внутреннего компонента мы решили развивать новую услугу для пользователей облака — Bare-Metal-as-a-Service.

Шаг 3: автоматизируем провижининг выделенных серверов в публичном облаке
С помощью автоматизации мы планировали решить несколько задач: ускорить подготовку выделенных серверов, сделать возможной одновременную работу сразу с несколькими из них, сократить простой между операциями и исключить человеческий фактор. Добиться этого нам удалось с помощью общедоступных инструментов и пары собственных доработок. Объяснить, как всё работает, проще всего на конкретном примере — теперь для того, чтобы сервер стал доступен для заказа клиентом, мы выполняем следующие действия:
  • Заносим сервер в CMDB (сейчас для этого у нас уже есть NetBox).
  • Через Redfish выполняем преднастройку BIOS — активируем загрузку по PXE и настраиваем её режимы, — а также создаём пользователей для удалённого управления.
  • Проверяем работоспособность сервера и передаём управление Ironic.
  • Инженер добавляет сервер в нужную плайсмент-группу.
  • Убеждаемся, что данные в CMDB и Ironic совпадают — в противном случае на этом этапе требуется ручное вмешательство оператора.
  • После успешной проверки данных Ironic выполняет настройку RAID и BIOS, а также первоначальную очистку сервера с помощью ATA Secure Erase или shred в зависимости от того, что поддерживает RAID-контроллер.

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

Шаг 4: добавляем новую услугу в облачную экосистему
Сейчас пользователи часто используют услугу Bare-Metal-as-a-Service в сочетании с другими нашими сервисами. Это позволяет им быстро получить готовую и гибкую инфраструктуру с простым управлением выделенными серверами и виртуальными машинами, приватными и публичными сетями, а также другими облачными решениями. Заказчикам такой подход помогает эффективно и экономично использовать ресурсы, а мы в результате успешно развиваем собственную экосистему сервисов, так как клиенты пользуются сразу комплексом наших решений. Помимо прочего, это открывает для заказчиков новые сценарии использования публичного облака — например, можно держать продакшн-среды на выделенных серверах, а при всплесках нагрузки за минуту разворачивать дополнительные мощности на виртуальных машинах, которые затем можно легко удалить. Чтобы новая услуга стала такой важной частью нашей экосистемы сервисов, после работ над автоматическим провижинингом нам предстояло решить ещё много задач.

Для начала, чтобы пользоваться новым сервисом было просто, заказ выделенных серверов мы сделали схожим с деплоем виртуальных машин — теперь для этого достаточно выбрать нужные характеристики, подключить публичную, приватную или сразу несколько сетей и через несколько минут получить готовый к работе сервер. Это решение уже прошло испытание боем: когда одному нашему клиенту не хватало виртуальных машин, он в тот же день оформил заказ и без проблем переехал на bare metal. С некоторыми другими задачами всё оказалось не так просто — остановимся на паре из них.

Избавляемся от «шумных соседей»
Главное отличие публичного сервиса от внутреннего компонента — наличие уникальных пользователей. Несмотря на то что все серверы живут в одном пуле, заказчикам как-то нужно обеспечить их изолированность друг от друга. Мы добились этого с помощью механизма мультитенантности. Готовые SDN-решения для этого не подходили, так как из-за них нам потребовалось бы ответвляться от существующей инфраструктуры. Нам также нужно было предусмотреть мультиплатформенность, поскольку наши облака распределены по всему миру и сетевое оборудование может варьироваться от региона к региону. В поисках подходящих решений нам пришлось досконально изучить вопрос, оптимальным вариантом оказался Networking-Ansible ML2 Driver. Правда, без ложки дёгтя в нём не обошлось — драйвер не умел объединять порты в MLAG, чего нам очень хотелось. Тогда мы сами научили его нужным образом агрегировать каналы на наших коммутаторах, но тут же столкнулись с другой проблемой при настройке интерфейсов внутри самого физического сервера.

Мы ожидали от cloud-init, что при выборе пользователем нескольких сетей они будут настроены с помощью сабинтерфейсов, но этого почему-то не происходило. Как оказалось, проблема была в том, что cloud-init недополучает из config-drive информацию о VLAN-ах, если порт настраивается транком. К счастью, на просторах opendev мы нашли патч, который мог бы исправить эту проблему. Сложность была в том, что он ещё находился в разработке, так что тут нам опять пришлось поработать напильником, чтобы самим довести патч до ума.

Теперь всё работает следующим образом:
  • Сетевые интерфейсы по умолчанию автоматически агрегируются и в транк перебрасываются как публичные, так и приватные сети. Пользователи же могут сконфигурировать свой ландшафт любым удобным образом, объединяя публичные и приватные сети в своём проекте — это позволяет им максимально эффективно использовать ресурсы;
  • По умолчанию все порты сервера находятся в несуществующей сети, но мы уже знаем в какой коммутатор воткнут каждый из них. Когда пользователь заказывает сервер, портам открывается доступ к PXE-серверам, запускается загрузчик, заливается образ, а дальше порты конфигурируются в целевую схему и сервер отдаётся клиенту.

Получается следующая схема потоков трафика:


Ну и заодно мы не забываем про VXLAN для bare metal и сейчас ведём разработку решения, позволяющего работать с сетью, используя эту технологию.

Пишем драйвер консоли для iDRAC
Без serial console траблшутинг bare metal был бы неполным, так как для пользователя она остаётся единственным способом подключения к серверу, если привычные варианты — SSH и RDP — вдруг оказываются недоступны. Проблема возникла при имплементации сервиса, когда стало понятно, что в Ironic отсутствует поддержка виртуальной консоли iDRAC. Чтобы всё же получить к ней доступ, нам пришлось самим написать драйвер. Для этого мы изучили имеющиеся драйверы в Ironic для работы с консолями iLo и IPMI, а затем написали собственное решение по схожему принципу. Получившийся драйвер отлично справляется со своими задачами, но только в тех случаях, когда образ пользователя умеет отдавать диагностику в COM-порт — к счастью, в современных версиях Linux и Windows проблем с этим не возникает даже из коробки. Вот только с виртуальной консолью проблемы на этом не кончились.

Следующая сложность возникла с проксированием портов самой консоли. За их работу отвечает компонент Nova — nova-serialproxy — принцип работы которого слегка отличается, но в целом схож с компонентом nova-novncproxy. Проблема обнаружилась на одном из этапов работы serial console, который организован следующим образом:
  • Пользователь запрашивает serial console в личном кабинете — создаётся запрос посредством REST API.
  • Компонент nova-api обращается к nova-compute для получения URL с валидным токеном и открытием веб-сокета на подключение.
  • API нашего личного кабинета получает этот URL и делает по нему обращение уже непосредственно в nova-serialproxy.
  • Затем происходит проксирование запроса nova-serialproxy к ironic-conductor на порт физического сервера для подключения к его виртуальной консоли.

Вот наглядное описание этой цепочки действий:


Проблема возникала на четвёртом этапе — иногда в этот момент пользователи в течение непродолжительного времени получали ошибку «Address already in use». Мы не сразу поняли, с чем связано такое поведение, так как обнаружить порт консоли занятым каким-то другим процессом в списке прослушиваемых портов нам никак не удавалось. Первым делом мы решили изучить socat, с помощью которого осуществлялось взаимодействие с виртуальной консолью от контроллера. Однако, найти корень проблемы так и не получалось, в том числе из-за того, что на момент обращения пользователей в службу поддержки ошибки уже не возникало. Но однажды нам повезло: в тот раз проблема никак не решилась сама собой и ещё была актуальна, когда клиент о ней сообщил.

Тогда нам удалось обнаружить, что HAproxy на контроллерах проксирует соединение к БД, где ему для инициализации подключения назначался порт консоли. Решение оказалось довольно простым: мы стали резервировать порты с помощью параметра ядра net.ipv4.ip_local_reserved_ports и выбрали диапазон в плоскости 48 тысяч, где конечный порт для консоли в момент подготовки сервера для аренды автоматически указывался в соответствии с последним октетом iDRAC-адреса.

Шаг 5: запускаем bare metal во всех регионах публичного облака
В результате этих работ из служебного компонента нам удалось сделать полноценный сервис в составе публичного облака. Останавливаться на этом мы не планируем и первым делом расширяем географию присутствия облака: теперь, помимо виртуальных машин, во всех новых регионах мы сразу будем предоставлять и выделенные серверы. Развиваться будет и сам сервис: в ближайшие полтора года мы планируем создать решения на базе серверов bare metal для работы с большими данными и CaaS-сервисами, в том числе с Managed Kubernetes, а также внедрить возможность разворачивать приложения из нашего маркетплейса на выделенных серверах. Подробней обо всём этом мы ещё расскажем отдельно — stay tuned.
gcorelabs.com/ru/cloud/marketplace/

Proxmox VE 7.0 released



Основные особенности новой основной версии Proxmox Virtual Environment 7.0:
  • Debian 11 «Bullseye», но с более новым ядром Linux 5.11
  • LXC 4.0, QEMU 6.0, OpenZFS 2.0.4
  • Ceph Pacific 16.2 — это новый стандарт по умолчанию; Ceph Octopus 15.2 по-прежнему поддерживается.
  • Технология хранения Btrfs с моментальными снимками под тома, встроенным RAID и самовосстановлением с помощью контрольной суммы для данных и метаданных.
  • Новая панель «Репозитории» для удобного управления репозиториями пакетов с помощью графического интерфейса.
  • Единый вход (SSO) с OpenID Connect
  • QEMU 6.0 с «io_uring», опцией очистки виртуальных дисков, на которые нет ссылок.
  • LXC 4.0 полностью поддерживает cgroups v2.
  • Переработана среда установщика Proxmox.
  • Автономный плагин ACME с улучшенной поддержкой сред с двойным стеком (IPv4 и IPv6)
  • ifupdown2 по умолчанию для новых установок
  • chrony в качестве демона NTP по умолчанию
  • и многие другие улучшения, исправления

www.proxmox.com/
pve.proxmox.com/wiki/Roadmap#Proxmox_VE_7.0

Спринтбокс — Деплойми на Спринтбокс



Деплойми – это легкое развертывание веб-приложений без траты времени на настройку сервера. Теперь деплой приложения займет около 15 минут, например, развертывание Wordpress на площадке Спринтбокс прошло всего за 4,5 минуты.

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

Деплойми — русскоязычный аналог Хероку. Он предоставляет пользователю полный контроль над проектами, так как они развертываются на VDS/VPS Спринтбокс. На одной машине можно запустить разные приложения и подключить к ним дополнительные сервисы, например, базы данных и менеджеры очередей.

До 31 июля сервис работает в бесплатном тестовом режиме. Запускайте Деплойми на Спринтбокс и управляйте приложениями!


sprintbox.ru

Выделенный сервер i7-4790K (4,4GHz) / 16 GB DDR3 / 240 GB SSD



Освободились выделенные серверы

i7-4790K [4c-8t] (4,4GHz) / 16 GB DDR3 1600 MHz / 240 GB SSD / Anti-DDoS-GAME / 250-500Mbps — 3300р./месяц, 0р. установка

Франция
Безлимитный трафик
Linux/Windows Server 2019/Windows 10

Пишите на sales@abcd.host или создайте тикет в личном кабинете

abcd.host/all-dedicated-servers

Сегодня открыты два новых региона центров обработки данных в США



Счастливого дня независимости! Сегодня люди в Соединенных Штатах празднуют, и мы в Contabo тоже празднуем.

Мы рады объявить о запуске двух новых центров обработки данных в США — в Нью-Йорке, штат Нью-Йорк, и в Сиэтле, штат Вашингтон. После открытия нашего первого офиса в США в апреле 2020 года мы делаем наши доступные VPS и выделенные серверы еще ближе ко всем пользователям в США. Имея выбор между Востоком США, Центральным регионом США и Западом США, каждый в США и Канаде получает доступ к недорогим серверам с низкой задержкой.

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

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


Знакомые товары по невероятным ценам
В двух наших новых регионах — Востоке США и Западе США — вы можете выбирать товары из того же ассортимента, что и во всех других регионах. Мы предлагаем наши самые продаваемые VPS, наши виртуальные выделенные серверы и наши мощные выделенные серверы.

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

Чтобы сделать вещи еще более удобными для наших нынешних и будущих клиентов из США, мы принимаем платежи в долларах США с помощью кредитной карты или PayPal и предлагаем поддержку на английском языке 365 дней в году.

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

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

Наши новые центры обработки данных в США оснащены восходящими линиями связи от Cogent или Lumen — оба считаются операторами связи уровня 1. Они имеют резервный источник питания и современные функции безопасности. Системы пожаротушения и обнаружения состоят из тепловых извещателей, дымовых головок, аварийных спринклеров и спринклеров с сухими трубами. Охлаждение обеспечивается системой охлажденной воды с резервированием чиллеров и крышными сухими градирнями. Параллельные генераторы обеспечивают бесперебойное и резервное питание.

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

Возможна миграция
Если вы являетесь клиентом Contabo и хотите перенести свой существующий VPS или виртуальный выделенный сервер (без диска) в один из наших новых центров обработки данных в США, обратитесь в нашу службу поддержки, и мы организуем для вас миграцию.

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

Специальное предложение ко Дню независимости — без платы за установку!
Чтобы отпраздновать запуск новых регионов, мы отказываемся от платы за установку для следующих заказов в наших центрах обработки данных в США для:


contabo.com

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



Пересмотр цен на виртуальный хостинг Linux
Наши продукты виртуального хостинга Linux предоставляются с многофункциональной панелью cPanel, которая поможет вам легко управлять своим хостингом. В 2020 году cPanel объявила о повышении цен. Поскольку cPanel — это удобная и производительная панель для управления хостингом, мы хотели бы продолжать предоставлять вам данный сервис. Мы также обновили версию cPanel, чтобы улучшить ее стабильность и производительность.

Из-за изменений в цене cPanel мы также пересмотрели цены на продление хостинга. Вы можете ознакомиться с измененными ценами на продление здесь, которые вступят в силу 3 августа 2021.

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

Пересмотр цен на домены .CLUB
Мы хотели бы обратить ваше внимание на предстоящие изменения цен на доменные имена .CLUB. Пересмотр цен связан с изменением себестоимости доменов. Новая цена составит 1,280.00 ₽ за регистрацию, продление и входящие трансферы, и 6,880.00 ₽ долларов за восстановление. Новые цены вступят в силу 3 августа 2021 года. Новая цена будет применяться для регистрации, продления и входящих трансферов.
Мы рекомендуем вам изменить цены не позднее 3 августа 2021 года, чтобы избежать потерь.

С уважением,
Команда ResellerClub

-50% скидки на vps i9-10900k



Команда MskHost представляет скидки 50% на всю игровую линейку тарифов MSK-GM на базе
процессора i9-10900k (5.3 ГГц)!

До 19.07.2021 у вас есть возможность заказать любой сервер (включая конструктор) из тарифной линейки MSK-GM со скидкой 50% и продлевать его в течение 3-х месяцев также с учетом скидки.

Пример первого тарифа с учетом скидки:
1 ядро 5.3 ГГц
2гб ОЗУ DDR4
30гб NVMe SSD
10 Gbit/s
AntiDDoS Game
Россия, Москва
ВСЕГО за 382р/мес

Не упустите самые дешевые серверы 5.3 ГГц, закажите прямо сейчас: https://my.msk.host

Дата-центр Яндекса в Финляндии перейдёт на возобновляемую энергию

Интернет, 30 июня 2021 года. Дата-центр Яндекса в городе Мянтсяля полностью перейдёт на энергию из возобновляемых источников. Её будет поставлять финская компания Ilmatar Energy, которая управляет сетью ветряных электростанций. Яндекс и Ilmatar подписали соглашение на пять лет.



Переход произойдёт в начале 2022 года. Яндекс будет закупать у Ilmatar энергию ветра в объёме, достаточном, чтобы удовлетворить все потребности дата-центра в Мянтсяля. В 2020 году его энергопотребление составило 68 ГВт·ч. После перехода 20% энергии, потребляемой всеми дата-центрами Яндекса, будет поступать из возобновляемых источников.

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

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

Дата-центр в Мянтсяля — один из пяти дата-центров Яндекса. Он был построен в 2014 году и используется для работы с зарубежными рынками. В Мянтсяля задействована технология естественного охлаждения: серверы круглый год остужают воздухом с улицы. Показатель энергоэффективности (PUE) финского дата-центра составляет 1,1, в то время как среднее значение по миру — 1,591. Чем ближе к единице значение PUE, тем выше энергоэффективность дата-центра.

Царь-дедики AMD EPYC встречайте!

Выделенные физические серверы AMD EPYC с мгновенной активацией и удобным управлением. Процессоры AMD EPYC 240 ядер, частота до 3.4 GHz. Память 1920 ГБ. Хранилище NVMe с тройным резервированием. Скорость интернет-порта до 10 Гбит/сек.


10% скидка через промо