Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Дата-центры

Huawei DCN. Сети ЦОД на основе намерений новые решения по управлению сетями

14.07.2020 14:04:30 | Автор: admin
Постоянное усложнение сетевой инфраструктуры современных ЦОДов ведёт к лавинообразному росту количества параметров, которые нужно контролировать ради оптимальных производительности и надёжности. Повысить уровень информированности администраторов о происходящих в сети процессах и помочь быстро выявлять зарождающиеся проблемы призвана концепция Huawei, воплотившаяся в решениях типа Intent-Driven Network: они предназначены для создания саморегулирующихся и самоуправляемых сетей, отвечающих принципу от автоматизации к автономности.



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



Четыре этапа развития ЦОДа


Определяя вектор развития сетей центров обработки данных, нетрудно заметить, как традиционные архитектуры ЦОДов постепенно пали под натиском систем виртуализации, затем пережили массовую миграцию ресурсов и сервисов в облака, а теперь вплотную подошли к широкому внедрению систем искусственного интеллекта и скоростных интерфейсов 400 Гбит/с. Возможности ИИ необходимы для построения сетей Ethernet без потерь и создания приложений, полностью невосприимчивых к задержкам.

Ещё одна сфера применения ИИ анализ и мониторинг работы ЦОДа. Нам предстоит перейти от идеологии, подразумевающей функционально ограниченный мониторинг состояния неких чёрных ящиков, к концепции полностью прозрачных сетей, о которых известно всё.



В качестве основных инфраструктурных сетевых единиц для построения сетей ЦОД Huawei предлагает сейчас линейку четырёх-, восьми- и шестнадцатислотовых коммутаторов CloudEngine 16800 с аплинками 400 Гбит/с; их выпуск намечен на текущий год. Также среди новинок отметим построенные на нашей собственной элементной базе ToR-свитчи CloudEngine 6881 и 6863 с интерфейсами 10 и 25 Гбит/с соответственно.



На иллюстрации показаны модели коммутаторов из линейки CloudEngine 16800 с классической ортогональной архитектурой, которые оснащены системой охлаждения front-to-back, а также совместимые с ними линейные карты, снабжённые интерфейсами 10, 40 и 100 Гбит/с.

Из важных базовых функций CloudEngine 16800 выделим его умение работать с NSH (Network Service Header), что позволяет реализовать в ЦОДе распределённую по нескольким свитчам микросегментацию (изоляцию на уровне виртуальных машин), обеспечить широкие возможности телеметрии и проводить анализ трафика на границе сети (edge intelligence) с применением технологий искусственного интеллекта на базе AI-чипов Huawei.

По-настоящему революционной станет модель V1R19C10. Именно в ней должны быть реализованы многие давно ожидаемые функции, в том числе EVPN Multihoming без перемычки в виде M-LAG (Multi-Switch Link Aggregation) на основании первого и четвертого типов маршрутов в EVPN-роутинге VXLAN.



Знакомая архитектура и новые возможности


На схеме видна привычная ортогональная архитектура трёхуровневой фабрики Non-blocking Switching. К её первоочередным достоинствам стоит отнести оптимальное расположение плат фабрики, линейных карт, коннекторов и системы обдува, основанной на вентиляторах с переменной скоростью вращения.



Важно, что на новых моделях коммутаторов аппаратно реализован протокол BFD (Bidirectional Forwarding Detection) и есть возможность настройки VXLAN в адресном пространстве IPv6. Базовая архитектура осталась прежней и строится на процессоре, сопроцессоре и forwarding chip. Функциональность каждого из узлов представлена на схеме. Главное же изменение 2020 года переход на собственные чипы Huawei во флагманских коммутаторах, полноценно конкурирующие с аналогами от Broadcom.



Поддержка операций с Network Service Header позволяет новым коммутаторам менять дефолтные маршруты пакетов VXLAN и подключать такие сервисы, как межсетевые экраны (FW), системы обнаружения вторжений (IDS), балансировщики нагрузки (SLB) и NAT.



Вернёмся ненадолго к ранее упомянутой разделённой микросегментации. Новые ToR-коммутаторы Huawei с помощью всё тех же NSH позволяют изолировать рабочие нагрузки на уровне имён виртуальных машин. Эти машины можно дополнительно группировать на уровне подсетей, на основании номеров портов, вышестоящих протоколов и пр., таким образом формируя группы приложений.



Полный спектр телеметрических данных


Информация с устройств собирается в реальном времени с использованием нескольких основных протоколов. Задачей ERSPAN+ является сбор TCP-заголовков для последующего детального анализа TCP-потоков в ЦОДе. Дополнительные данные добываются с помощью протокола gRPC и таблицы переадресации (Flow table). Всё это собирается с Protobuf over UDP.



Основное направление развития средств O&M в Huawei переход от ручного или полуавтоматического контроля сети к полностью автоматическому, основанному на технологиях искусственного интеллекта. Всеохватная система телеметрии достаточно крупной площадки производит огромные объёмы данных, анализ которых в сжатые сроки возможен только с применением ИИ. Особенно это важно в тех ЦОДах, где сбои и простои просто недопустимы.



К превентивным мерам, призванным не допустить возникновения неполадок в работе сети, прежде всего стоит отнести мониторинг здоровья сети: контроль загрузки каналов, выявление причин потери пакетов (допустим, поиск корреляции с временем суток или периодами работы какого-либо приложения), обнаружение узких мест (capacity forecasting) и пр.

Если неполадки всё же наблюдаются, минимизировать время диагностики и восстановления помогает выдвинутый Huawei принцип 1-3-5: минута на поиск, три минуты на локализацию, пять минут на ликвидацию проблемы. Для того чтобы укладываться в эти рамки, продукты Huawei поддерживают постоянно расширяющийся список типовых неисправностей, которые определяются автоматически.



Модель V100R019C10 для небольших ЦОДов


Одним из главных нововведений в V100R019C10 стала поддержка визуализации на основе телеметрических данных во всех типах сценариев. По сути, речь идёт о наглядном отображении любых изменений в сети. Кроме того, устройство теперь умеет определять более 75 первопричин возникновения тех или иных проблем и помогает наметить действия для их устранения (запуск скриптов и пр.).

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



Изменения в системе лицензирования


Для лучшего понимания функциональных особенностей FabricInsight следует пояснить, какие изменения произошли в бизнес-модели распространения сетевых продуктов Huawei. Если количество коммутаторов не достигает сотни, такой вариант классифицируется как standalone edition и подразумевает наличие лицензии N1. Кластер из трёх и более серверов уже поставляется в комплекте с платформой аналитики больших данных. Решение Advanced solution, включающее в себя несколько сотен свитчей, рекомендуется использовать совместно с инструментарием для анализа сетевых потоков. Все три варианта допускают использование возможностей FabricInsight при наличии лицензии N1.



Любая лицензия подразумевает применение всего набора телеметрических инструментов и сценариев 1-3-5, за исключением средств анализа TCP-потоков, доступных только в Advanced solution.



Осталось рассказать о конфигурациях серверов, предназначенных для решений Standard и Advanced solution. На сегодняшний день standalone node (один узел) доступен только на сервере Taishan 200. Для работы кластера из трёх узлов необходимо 16 или более вычислительных ядер, 128 Гбайт оперативной памяти и т. д. (см. схему). Объём дата-диска напрямую зависит от того, как долго должна храниться статистика.



KPI-мониторинг


Чуть подробнее остановимся на KPI-мониторинге. Для его применения достаточно задать временной интервал и конкретные пороговые значения, достижение которых будет проверяться на основании полученных телеметрических данных. Доступно много типов метрик, среди которых:

  • использование ЦПУ и памяти;
  • использование FIB / MAC;
  • использование троичной ассоциативной памяти (TCAM) чипа;
  • параметры портов;
  • размер буфера для очереди;
  • разные метрики AI Fabric;
  • уровень сигнала, температура и другие параметры работы оптического модуля;
  • потеря пакетов.




Предварительная проверка


Инструмент предварительной проверки также оперирует данными, получаемыми с помощью телеметрии. CT scanner позволяет понять, происходили ли в сети те или иные нежелательные события. Часть метрик совпадает с метриками KPI-мониторинга фабрики (главным образом касающиеся ёмкости и производительности). Остальные основываются на результатах анализа верхнего уровня (VXLAN, BGP и др.) и анализа конфигурации. После запуска CT scanner собирает необходимые сведения и формирует исчерпывающий отчёт о состоянии сети.



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



Неполадки устройств


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

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



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



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



Неполадки сети


Посредством FabricInsight с опорой на 18 доступных для анализа метрик удаётся выявлять 10 типов сетевых неполадок. На схеме приведён их полный перечень, а также как и в случае с неполадками устройств модели коммутаторов, позволяющих FabricInsight обнаружить проблему, используемые функции и доступные автоматические действия.



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



Средствами сетевой диагностики FabricInsight можно своевременно выявить и проблемы с буфером, часто возникающие в системах с большим количеством серверов, которые отведены под обработку big data. Традиционная NMS (Network Management System) проверяет связанные с буфером параметры каждые пять минут. Возможности телеметрии FabricInsight позволяют уменьшить эти интервалы вплоть до 100 мс и выявить даже самые короткие микроинциденты.



Неполадки на уровне протоколов


Здесь FabricInsight умеет определять шесть типов неполадок, включая конфликт двух мастер-свитчей в M-LAG; проблемы взаимодействия соседних коммутаторов и пр. Эта функциональность доступна при использовании коммутаторов V200R005C00 и более новых.



Рассмотрим конфликт мастер-свитчей. При всех достоинствах технологии M-LAG в случае обрыва линка и неисправности одноранговой сети в системе появляются два мастер-свитча. FabricInsight умеет проактивно реагировать на подобную ситуацию благодаря постоянному контролю состояния peer-линка и DFS.



Неполадки оверлейной сети


Семь типов неполадок оверлейной сети могут быть выявлены благодаря контролю десяти различных метрик. FabricInsight умеет проверять статус лицензии VXLAN, находить ошибки в конфигурациях, определять падение sub-интерфейса и т. д. Опции реагирования аналогичны описанным ранее.



Неполадки сервисов


Для выявления шести типов неполадок на уровне сервисов используется контроль семи метрик. Обнаружению поддаются конфликты IP-адресов, проблемы с установлением соединения, флуд-атака TCP SYN и др. Обратим внимание на то, что для поддержки этих возможностей FabricInsight может понадобиться наличие анализатора TCP-потоков.

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



От автоматизации к автономности


В качестве резюме скажем, что в основе идеологии Intent-Driven Network лежит трёхступенчатая модель реагирования, которая включает в себя сбор информации, её анализ с привлечением средств ИИ и предложения по изменению состояния сети, в том числе в автоматическом режиме.

***


Напоминаем о том, что наши эксперты регулярно проводят вебинары по продуктам Huawei и по технологиям, которые в них используются. Список вебинаров на ближайшие недели доступен по ссылке.
Подробнее..
Категории: It-инфраструктура , Сетевые технологии , Сетевое оборудование , Дата-центры , Блог компании huawei , Huawei , Huawei enterprise , Cloud fabric , Cloudengine , Cloudengine 16800 , Fabricinsight , Intent-driven network , Bfd , Nsh , 1-3-5

Фрикулинг в дата-центрах Selectel как все устроено

13.08.2020 18:07:06 | Автор: admin

Привет, Хабр! Пару недель назад выдался жаркий денек, который мы обсуждали в курилке рабочего чата. Буквально через несколько минут разговор о погоде перерос в беседу о системах охлаждения дата-центров. Для технарей, тем более сотрудников Selectel, в этом нет ничего удивительного, мы постоянно говорим на подобные темы.

В процессе обсуждения мы решили опубликовать статью о системах охлаждения в дата-центрах Selectel. Сегодняшняя статья о фрикулинге, технологии, применяющейся в двух наших дата-центрах. Под катом подробный рассказ о наших решениях и их особенностях. Техническими деталями поделились руководитель отдела сервисного обслуживания систем кондиционирования и вентиляции Леонид Лупандин и старший технический писатель Николай Рубанов.

Системы охлаждения в Selectel



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

Вот список ДЦ с используемой системой охлаждения:

  • Берзарина фрикулинг.
  • Цветочная 1 фреон, классические промышленные кондиционеры для ЦОД.
  • Цветочная 2 чиллеры.
  • Дубровка 1 чиллеры.
  • Дубровка 2 фреон, классические промышленные кондиционеры для ЦОД.
  • Дубровка 3 фрикулинг.

В своих дата-центрах мы стремимся поддерживать температуру воздуха у нижней границы рекомендованного по ASHRAE диапазона. Это 23C.

О фрикулинге


В двух дата-центрах, Дубровка 3 и Берзарина, мы установили системы фрикулинга, причем разные.

Система фрикулинга в ДЦ Берзарина

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

Регулируемые воздушные заслонки

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

Схема прямого фрикулинга с доохлаждением без фальшпола

Важный момент: фрикулинг используется в наших дата-центрах вместе с системами доохлаждения. Зимой проблем с забором внешнего холодного воздуха нет за окном прохладно, иногда даже очень, поэтому дополнительные системы охлаждения не нужны. А вот летом температура воздуха повышается. Если бы мы использовали чистый фрикулинг, то температура внутри составляла бы около 27 C. Напомним, что температурный стандарт у Selectel составляет 23C.

В Ленинградской области многолетняя среднесуточная температура даже в июле находится у отметки 20C. И все бы ничего, но в некоторые дни очень жарко. В 2010 году в области был зафиксирован температурный рекорд в +37.8C. Учитывая это обстоятельство, полностью рассчитывать на фрикулинг нельзя одного жаркого дня в году с лихвой хватит для выхода температуры за границы стандарта.

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

Воздушные фильтры

Дубровка 3 и Берзарина фрикулинг, но разный


По ряду причин мы используем разные системы фрикулинга в этих дата-центрах.

Дубровка 3


Первым ДЦ с фрикулингом была Дубровка 3. Здесь используется прямой фрикулинг, дополненный АБХМ, абсорбционной холодильной машиной, которая работает на природном газе. Машина применяется как доохлаждение на случай летней жары.

Охлаждение дата-центра по схеме фрикулинга с фальшполом

Такое гибридное решение позволило добиться PUE ~1.25.

Почему АБХМ? Это эффективная система, где вместо фреона используется вода. АБХМ оказывает минимальное воздействие на окружающую среду.

В качестве источника энергии АБХМ-машина использует природный газ, который подведен к ней трубопроводом. Зимой, когда машина не нужна, газ можно сжигать для подогрева переохлажденного наружного воздуха. Это намного дешевле, чем использовать электричество.

Вид на АБХМ

Идея использовать АБХМ в качестве системы доохлаждения принадлежит одному из наших сотрудников, инженеру, который увидел подобное решение и предложил применить в Selectel. Мы сделали модель, протестировали ее, получили отличный результат и решили его масштабировать.

Строилась машина около полутора лет, вместе с системой вентиляции и самим ЦОД. В 2013 году она была введена в эксплуатацию. Проблем с ней практически нет, но для работы нужно пройти дообучение. Одна из особенностей АБХМ в том, что машина поддерживает разность давлений внутри и снаружи помещения ДЦ. Это нужно для того, чтобы горячий воздух выходил через клапанную систему.

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

Расходы на техническое обслуживание системы, возможно, чуть выше, чем в случае обычного охлаждения. Но АБХМ позволяет экономить за счет снижения расхода электричества на нагрев воздуха и его доохлаждение.

Берзарина


Схема движения воздушного потока внутри серверного помещения

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

Принцип работы адиабатического охлаждения

Здесь фрикулинг решили использовать, потому что дата-центр расположен на последнем этаже здания. А значит, выбрасываемый наружу нагретый воздух сразу уходит вверх, а не подавляет другие системы, как это могло бы случиться, будь ДЦ размещен на нижних этажах. Благодаря этому показатель PUE ~1.20

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

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

Щиты управления

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

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

Если хотите узнать подробности о других системах охлаждения в наших ДЦ, то вот статья со всей информацией.

В комментариях задавайте вопросы, постараемся ответить на все, что сможем.
Подробнее..
Категории: It-инфраструктура , It-стандарты , Инженерные системы , Блог компании selectel , Дата-центры , Фрикулинг , Системы охлаждения , Selectel

Сравнение услуг colocation

09.10.2020 16:18:18 | Автор: admin

Мы регулярно проводим исследование рынка, составляем таблицы с ценами и кучей параметров по десяткам дата-центров. Вот подумалось, что не стоит пропадать добру. Кому-то может пригодятся сами данные, а другие могут взять за основу структуру. Втаблицахпредставлены данные с 2016 года. Но таблиц было мало и сделали ещё графики икалькулятор тарифов на размещение серверов, плюс дополнили открытыми данными из налоговой по оборотам налогам и сотрудникам, данными из RIPE (статус LIR, подсети и общее количество IPv4) и данным из рейтинга ping-admin (Uptime и аварии).

Кто попал в выборку

В таблицу за сентябрь 2020 года попали все кто находится в ТОП-20 в Яндекс и Google, присутствует там же на рекламных местах, и у кого есть цены на сайте. Если компании нет в эфире или цены по запросу, то она точно никому не конкурент на открытом рынке. Такая компания может даже иметь хорошие заказы, например, государственные, но это отдельная кормушка, там можно быть даже лидером, но это не имеет отношения к конкуренции на рынке.

Если часть цен закрыта, то данные не выводятся в этом диапазоне. Например, если сказано, что в тариф включено 350Вт или 100Мбит/c или 1 IP-адрес и ниже нет цен дополнительную мощность, расширение канала или дополнительные IPv4.

Проблемы ценообразования

В ценах на услуги colocation клиентов больше всего бесили скрытые платежи. Это было огромной проблемой в нулевых с трафиком. Никто же не знал заранее какой у него будет трафик и все боялись залететь. Но в тоже время чудес не бывает. Стоимость 100Мбит тогда была порядка 50 000р. Сейчас гигабит уже дешевле стоит. Время идёт, а ценообразование до сих пор у многих очень мутное, и на сайтах провайдеров нет исчерпывающего прайс-листа. Тарифы строятся по-разному, при определённых параметрах выгодно по цене у одного поставщика, при увеличении параметров, уже выгоднее у другого.

И, конечно, не надо забывать, цена далеко не единственный показатель. Смотреть нужно и другие параметры, хотя и сложнее сравнить. ihor почему-то попал в нашу таблицу. Не хотел его даже в базу добавлять. Но потом подумал, что как раз, будет отрицательный пример, компания одним сотрудником, 22 тысячами налогов и 43 тысячами взносов, вполне показательна. А ведь people хавает.

Общие тенденции и проблемы рынка

На графиках видно визуально общую тенденцию рынка.

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

При этом с одной стороны, деньги берутся за воздух, так как считается по номинальной мощности, а не по потребляемой. По потребляемой мощности отдельный сервер посчитать сложно и дорого, нужно счётчик ставить на каждую розетку. Но с другой стороны, потенциально сервер же может работать почти на полную мощность блока питания. А ещё нужно учитывать, что к потребляемой мощности сервера нужно добавить 30% на охлаждение, 10% на промышленные ИБП, и ещё 10% на свет и офисные нужды. Но открою секрет, в среднем один сервер потребляет 100Вт, так как на стойку подводят 5кВт и этого хватает.

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

У некоторых из тех, кто не берёт деньги за мощность на сайтах встречаются оговорки, что GPU-сервера, блейды и прочие печки размещают по отдельным тарифам.

Второй график показывает зависимость стоимости от скорости порта. Скорость каналов ещё более нетривиальная тема, чем электричество. У электричества нет понятия качества. Оно может мигать, но для этого есть ИБП+ДГУ. А вот два гигабитных канала могут быть очень и очень разного качества. Один может сливать всё в обменник, иметь плохую видимость, большие пинги, ограничения на заграничный трафик. И для каналов нет ни ИБП, ни ДГУ для подобных случаев. Поэтому цены на каналы сравнивать дело практически бесполезное.

Когда мы проводили исследования рынка по стоимости гигабита в Москве, то нам задавали вопросы: а что за трафик будет?, а какие пики?.

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

На что имеет смысл обращать внимание

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

На наш взгляд сертификация по Tier III играет роль. И это не только на наш взгляд, так как реклама пестрит Tier III. Вы можете набрать в Яндексе: размещение сервера в дата-центре, нажать Ctrl+F и посчитать сколько раз встречается слово Tier.

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

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

Заключение

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

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

Подробнее..
Категории: It-инфраструктура , Хостинг , It-компании , Хранение данных , Дата-центры , Исследования и прогнозы в it , Цоды , Цены , Colocation , Размещение серверов , Сравнение цен

Хорошо плывут плавучий ЦОД из Сингапура на водороде и завершенный дата-центр от Nautilus Data Technologies

17.11.2020 10:12:56 | Автор: admin

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

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

Плавучий дата-центр на водороде из Сингапура


Бизнес-конгломерат из Сингапура Keppel Corp предложил разместить ЦОД на плавучей платформе, вернее, сразу нескольких платформах. Отводить тепло предлагается при помощи морской воды прямо на месте. А электричество вырабатывать из водорода. Что касается последнего, то речь идет о топливных ячейках согласно подсчетам, в ряде случаев использование водорода экономически выгоднее, чем дизеля.

Конечно, не везде и не всегда. Как правило, водородные ячейки используют в том случае, если рядом с дата-центром есть источники зеленой энергии фотоэлементы, ветроэлектростанции, гидроэлектростанции. Излишки электричества в солнечные и ветреные дни используются для электролиза воды. Затем водород запасается в специальных резервуарах. А потом, когда энергии не хватает, его используют в топливных ячейках для получения электричества.


Как именно поступит Keppel Corp, пока неясно, но контракт на поставку топливных ячеек и другого оборудования уже заключен с японскими компаниями Mitsubishi Heavy Industries и Osaka Gas.

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

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


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

Что касается компании Keppel, то она начинала с ремонта танкеров и грузовых судов в Сингапуре. С 2000 года она начала работать в отрасли строительства дата-центров. Сейчас на ее счету уже 27 ЦОД в Азии и Европе.

Плавучий дата-центр от Nautilus Data Technologies



В июне мы писали о еще одном наводном дата-центре, который разрабатывается компанией Nautilus Data Technologies. Он получил название Stockton I, строительство его велось в порту Стоктон в северной части штата Калифорния. Кроме того, еще один дата-центр эта же компания строит в доках Лимерика в Ирландии. Стоимость такого объекта составляет около $35 млн.

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

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

Благодаря тому, что воду не нужно качать по трубопроводам издалека, энергопотребление ДЦ ниже, чем у стандартного объекта аналогичной мощности. У тестового дата-центра компании PUE составил 1,045, на реальном объекте он чуть выше 1,15. По расчетам, проведенным специалистами по охране окружающей среды, негативное влияние на окружающую среду будет минимальным. Локальная и тем более глобальная экосистемы не пострадают.


Cистема охлаждения серверов на базе теплообменников в задней дверце серверной стойки (производитель ColdLogik)

Мощность дата-центра 6 МВт. Средний расход забортной воды 17 тысяч литров в минуту. Максимум 45 тысяч литров в минуту. Этот метод охлаждения, по словам представителей самой компании, дает возможность в пять раз увеличить удельную мощность IT-оборудования на стойку.

Осенью этого года дата-центр был наконец достроен. Скорее всего, в конце года он направится все в тот же Сингапур. На этот и остальные свои проекты компания получила около $100 млн.

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

Зачем все это нужно?


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

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

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

Подробнее..
Категории: It-инфраструктура , Сетевое оборудование , Блог компании selectel , Будущее здесь , Дата-центры , Строительство , Мобильность

Гуляем по новому дата-центру Ростелеком-ЦОД в Санкт-Петербурге

25.02.2021 12:15:55 | Автор: admin

Сегодня отправимся в Калининский район Санкт-Петербурга и со всех сторон посмотрим на дата-центр "Ростелеком-ЦОД", который запустился в декабре 2020 года. Новый ЦОД построили "с нуля" недалеко от корпусов завода ЛОМО по адресу: ул. Жукова, 43 (не путать с проспектом Маршала Жукова!).

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

Несколько фактов про ЦОД

  • Общая площадь: 4 266 кв м.

  • Общая емкость: 792 стойко-мест.

  • 4 машинных зала, до 198 стоек каждый.

  • Проектная мощность: 7 400 кВт.

  • Соответствует стандарту Tier III.

Из истории

Перспективную территорию в Санкт-Петербурге заметили еще в 2016 году. Когда-то давно здесь хотели построить мазутохранилище для ТЭЦ, но в конце 1980-х строительство забросили, и площадка так и оставалась невостребованной.

Зато этим местом интересовались киношники. В огромных резервуарах стояла вода, в них проходили подводные съемки для петербургских фильмов.

В 2018 году здесь начался демонтаж.

Хроники расчистки площадки.Хроники расчистки площадки.

Затем площадку дренировали и подготовили почву к строительству. Так как местность оказалась болотистой, фундамент дополнительно укрепили с помощью бетонной плиты на глубине 8 метров.

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

Посмотрим, что появилось на месте стройплощадки.

Так эта же площадка выглядела в июле и в октябре 2020 года. Так эта же площадка выглядела в июле и в октябре 2020 года.

Физическая безопасность

Добраться до дата-центра в Санкт-Петербурге удобнее всего по улице Чугунной. На общественном транспорте можно доехать до ст. м. "Выборгская" и сесть на маршрутку К-283 до остановки "Чугунная, 46". Вход и въезд через ворота со стороны ул. Чугунной.

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

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

Вся прилегающая территория хорошо просматривается благодаря видеокамерам.

Нас уже заметили.Нас уже заметили.

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

Машинные залы

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

Так на схеме выглядит половина дата-центра. Вторая половина такая же.Так на схеме выглядит половина дата-центра. Вторая половина такая же.

Нужный машзал легко найти по навигации на стенах. Залы назвали в честь островов Санкт-Петербурга:

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

Внутри каждого машинного зала можно разместить до 198 стоек от 5 кВт. Например, этот зал пока пустой, но скоро стойки отправятся на свои места.

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

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

Приоткроем плитку фальшпола в холодном коридоре.Приоткроем плитку фальшпола в холодном коридоре.

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

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

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

Энергоснабжение

Cистема энергоснабжения в дата-центре зарезервирована по схеме 2N. В ЦОДе 2 отдельных энергоцентра в каждом модуле.

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

Каждый модуль оборудован источниками бесперебойного питания (ИБП) и дизельными генераторными установками (ДГУ). Все ИБП тоже зарезервированы по схеме 2N. То есть к каждой стойке подходят 2 независимых ввода бесперебойного электропитания.

Ряд ИБП Vertiv (ex-Liebert) в энергоцентре.Ряд ИБП Vertiv (ex-Liebert) в энергоцентре.

Если питание от одного городского ввода пропадает, ИБП автоматически передадут его нагрузку на аккумуляторные батареи (АКБ).

Стеллажи c батареями в помещении АКБ.Стеллажи c батареями в помещении АКБ.

Дата-центр может работать от АКБ до 10 минут. Этого времени хватает для запуска ДГУ. Именно ДГУ отвечают за гарантированное энергоснабжение: даже если весь город обесточен, ДГУ обеспечивают бесперебойную работу оборудования в ЦОДе.

ДГУ марки MTU 16V4000 DS2250 мощностью 1965 кВт.ДГУ марки MTU 16V4000 DS2250 мощностью 1965 кВт.

Установки тоже зарезервированы по схеме 2N: трех ДГУ уже достаточно для питания четырех машзалов, а в дата-центре их 6. Система спроектирована таким образом, что зарезервированы не только ДГУ, но и трассы.

Во время работы ДГУ довольно сильно вибрируют. Чтобы вибрация не влияла на основной фундамент, все ДГУ установлены на отдельное бетонное основание.

Каждый дизельный двигатель потребляет примерно 300 литров в час. Топливохранилище ДГУ рассчитано на 25,2 куб. м. При максимальной проектной загрузке ЦОДа ДГУ могут работать в аварийном режиме 12 часов без дозаправки. В рабочем режиме и при нормальной загрузке гораздо больше.

Один бак топливохранилища вмещает 12,6 куб. м, всего таких баков два.Один бак топливохранилища вмещает 12,6 куб. м, всего таких баков два.

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

Если же запасы начнут истощаться, топливо для дозаправки подвезут за 6 часов. Все сроки прописаны в контракте с поставщиком, предусмотрены премии за быстрое выполнение заказа. Заправка на работу дизеля не влияет.

Для топливозаправщика на территории ЦОДа оборудована специальная площадка. На месте заправки поставщик подключается к трубопроводу, открывает задвижки и насосы автоматически начинают работу.

Холодоснабжение

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

Все элементы зарезервированы по схеме N+1. Это значит, что выход из строя любого из элементов не повлияет на работу системы: нагрузка распределится между оставшимся оборудованием.

Общая схема системы холодоснабжения.Общая схема системы холодоснабжения.

В каждом машинном зале установлено 8 прецизионных кондиционеров Vertiv PCW PH136EL. 4 из 8 кондиционеров в зале с функцией пароувлажнения.

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

К обратной магистрали подключены расширительные баки: они ограничивают колебания давления из-за разницы температур.

Бак оборудован манометром: если давление выходит за рабочие пределы, срабатывает предохранительный клапан.Бак оборудован манометром: если давление выходит за рабочие пределы, срабатывает предохранительный клапан.

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

Циркуляционные насосы в одном из хладоцентров.Циркуляционные насосы в одном из хладоцентров.

Трубы на крышу идут через вентиляционные камеры на втором этаже.

Отличить "горячий" и "холодный" контур можно по цвету стрелок.Отличить "горячий" и "холодный" контур можно по цвету стрелок.

На крыше установлены 6 чиллеров Vertiv FD4130-LN. Чиллеры окружены звукоизолирующими панелями. Дата-центр расположен в стороне от жилых кварталов, но так мы точно уверены, что шум не выйдет за пределы промзоны.

Таких секций на крыше две.Таких секций на крыше две.

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

Аккумулирующие баки и трубы оклеены теплоизоляционным материалом K-Flex и защищены от физического воздействия металлическим кожухом. Аккумулирующие баки и трубы оклеены теплоизоляционным материалом K-Flex и защищены от физического воздействия металлическим кожухом.

Пожарная безопасность

Дата-центр оборудован газовой станцией пожаротушения. Отсюда трубы расходятся по всему дата-центру: в нашей системе пожаротушения 16 направлений. Система зарезервирована по схеме 2N. Всего здесь стоит 24 баллона, на каждое направление тушения предусмотрен основной и резервный запас огнетушащего вещества. Внутри баллонов находится хладон-227еа, этот газ безопасен для ИТ-оборудования в ЦОДе.

Если в помещении возникает дым, система автоматической пожарной сигнализации отправляет сигнал от датчиков пожарообнаружения. Сигналы поступают в диспетчерскую, где сидят дежурные инженеры. Здесь расположен контрольно-индикационный блок, где сразу загорается табло "ТРЕВОГА" или "ПОЖАР". Если сработали оба датчика, в дата-центре запустится система оповещения.

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

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

Такие же кнопки есть и около эвакуационных выходов.Такие же кнопки есть и около эвакуационных выходов.

Мониторинг

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

Все показатели систем мониторинга со всех площадок сводятся в единый ситуационный центр в Москве.

Телеком

В дата-центр независимыми маршрутами заведены 2 телеком-ввода от магистралей "Ростелекома".

Также на площадке есть операторы со своей оптикой: Северен-Телеком, ОБИТ, Комфортел. Еще здесь работает Филанко и скоро появится Авантел. Дата-центр готов принять любого телеком-провайдера, удобного клиенту.

Одна из кроссовых.Одна из кроссовых.

На площадке обеспечивается надежная сетевая связность с другими дата-центрами группы "Ростелеком-ЦОД".

Вспомогательная инфраструктура и быт

Для транспортировки оборудования предусмотрено несколько зон погрузки и разгрузки. Вот один из заездов с пандусом:

Так выглядит зона разгрузки внутри:

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

Команда дата-центра весь 2020 год готовила новую площадку для комфортной работы коллег и клиентов, несмотря на пандемию.Строительство и эксплуатация дата-центра организованы по нашим единым стандартам, за качество отвечала петербургская часть большой команды "Ростелеком-ЦОД".

Будем рады видеть вас в гостях! Приезжайте в Санкт-Петербург знакомиться и на экскурсию.

Подробнее..
Категории: It-инфраструктура , Инженерные системы , Ибп , Цод , Хранение данных , Хранилища данных , Дата-центры , Кондиционирование , Дата-центр , Блог компании dataline , Цоды , Центр обработки данных , Дгу , Чиллеры , Стойки

Статистика и ЦОД откуда берутся 5 кВт на стойку и почему это немало

04.03.2021 12:16:30 | Автор: admin

В новостях про запуск дата-центров вы обязательно встретите упоминание мощности в киловаттах на стойку. За последний год наша объединенная команда DataLine и Ростелеком-ЦОД запустила 4 дата-центра, и мы каждый раз сталкивались с комментариями в соцсетях и вопросами в чатах:

Суть всех вопросов: Почему средняя мощность 5 кВт на стойку? Как так, 21-й век, 21-й год, а цифра не меняется? Это слишком мало.Суть всех вопросов: Почему средняя мощность 5 кВт на стойку? Как так, 21-й век, 21-й год, а цифра не меняется? Это слишком мало.

Сегодня по порядку ответим: как мы считаем мощность на стойку, почему эта цифра не ограничивает заказчика, а наоборот, экономит его ресурсы. Объясню с точки зрения статистики и возьму пару наглядных аналогий из популярной книги Статистика и котики (очень классного пособия для обновления забытых знаний).

Представим, что у нас 10 котиков (а мы знаем примеры, когда и 100 котиков бывает). Самый маленький котик ест 1 кг корма, средний 3, а самый крупный вообще 10. Мы не покупаем каждому по 10, а подсчитываем общий расход корма на всех и планируем покупки из среднего значения. Так же, ну или почти так же со стойками.

Как мы считаем киловатты на стойку и причем тут котики

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

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

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

Так выглядит план на этом этапе: пока все стойки одинаковые. Так выглядит план на этом этапе: пока все стойки одинаковые.

Чтобы подвести достаточно электричества к каждой запланированной стойке, нужно знать ее потребление. Возникает вопрос, как предсказать мощность стоек. Тут есть 2 варианта дата-центров:

  • Если это корпоративный ЦОД, то требования компании могут включать любое количество высоконагруженных стоек. Например, недавно мы спроектировали для заказчика зал со стойками более 15 кВт.

  • Если это коммерческий ЦОД с множеством независимых заказчиков, нужно оценить реальные потребности рынка.

Во втором случае нам помогает наша статистика. Вот уже 13 лет мы ежеминутно собираем данные по потреблению наших 5000 стоек.

График среднего потребления всех стоек DataLine за год.График среднего потребления всех стоек DataLine за год.

В статистику входят компании из разных отраслей. У кого-то уходит 7 кВт на стойку, у кого-то 3 кВт. Мы считаем среднее арифметическое по потреблению и смотрим динамику за последние годы. Сейчас в среднем получаем 4 кВт на стойку. Рост потребления с 2010 года составляет не больше 100 ватт на стойку в год. Так что для нового дата-центра мы закладываем небольшой запас и получаем те самые 5 кВт на стойку.

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

Как статистика учитывает исключения из правила

Основной контраргумент в споре про 5 киловатт примерно такой: Если я поставлю в стойку 3 блейд-корзины, они будут потреблять существенно больше 5 кВт, и что тогда? Давайте разбираться с точки зрения статистики и реальной практики.

Начну с теоретической статистики. Прожорливые стойки намного больше среднестатистической называют выбросом. Для статистики это выглядит так:

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

Значит, при проектировании мы всегда должны учитывать долю нестандартных стоек у заказчиков. Сейчас кажется, что мы все чаще видим в наших дата-центрах оборудование для high-performance computing с потреблением в районе 25 кВт. Но, по сухой статистике, это все еще пара десятков серверов на зал: как раз вписываются в те самые 10 % выброса.

Допустим, у нас в машинном зале стоит 198 стоек со средним потреблением 5 кВт. Добавим пару стоек в 25 кВт и посчитаем среднее:

(1985+225)/200 = 5,2

5,2 кВт, совсем небольшая разница. Но если таких мощных стоек будет уже 10 (около 5 %), то среднее значение отклонится на целый киловатт:

(1985+1025)/208 =5,96

При этом типичная стойка в этом зале по-прежнему будет потреблять 5 кВт.

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

Что будет, если планировать стойки с большим запасом

Теперь посмотрим внимательнее на проектирование 3 ресурсов в дата-центре. Что будет на каждом этапе планирования, если мы решим сделать запас больше одного кВт на стойку?

Итак, мы начали проектировать ЦОД от здания: берем общую площадь, вычитаем место под офисную часть и вспомогательные помещения. Понимаем размер машинных залов и прикидываем количество стоек: с учетом всей инфраструктуры исходим из 6 кв. м на стойку. Получившиеся стойки умножаем на планируемую среднюю мощность. Допустим, берем на стойку 6 кВт.

Если мы строим ЦОД в столице, его емкость составит не меньше 1 0002 000 стоек. Итого, 9 000 кВт вместо 7 500 для усредненных 1,5 тысяч стоек. Добавим к этому 30 % на тепло. Уже 11 700 кВт, а не 9 750. Смотрим, есть ли у нас столько подведенной мощности, или нужно докинуть электричества.

Дальше распределяем электричество по нескольким точкам отсечки на схеме электроснабжения:

Стандартная схема энергоснабжения дата-центров DataLine.Стандартная схема энергоснабжения дата-центров DataLine.

Посмотрим на мощность самой стойки, которая определена PDU (справа). Дальше по схеме справа налево идет мощность зального щита ЩР. Затем следует мощность щита распределения от ИБП (ЩИБП). Дальше ИБП, и так доходим до ГРЩ. Каждое из этих устройств имеет свою мощность, необходимо распределять нашу нагрузку в этих пределах. Для стоек помощнее нам понадобятся дополнительные ИБП и вообще оборудование помощнее это снова дополнительные расходы.

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

Итого, каждый лишний киловатт приведет к дополнительным затратам на электричество, оборудование для электроснабжения и холодоснабжения. Вся лишняя стоимость по нескольким статьям размажется по всем стойкам нового дата-центра. Но цена за киловатт для заказчика растет не линейно. На каких-то масштабах каждый новый киловатт в 2 раза дороже предыдущего из-за дополнительных затрат на инфраструктуру. Стоимость инфраструктуры растет пропорционально росту мощности, эффекта масштаба здесь уже нет. Зачастую дешевле взять две стойки по 5 кВт, чем одну на 10 кВт.

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

Всегда ли заказчику нужно больше 5 кВт в стойке

Когда к нам приходит новый заказчик со стойками больше 5 кВт, наш дизайн-центр должен подготовить проект. Задача ответственного инженера согласовать проект с точки зрения соответствия запросам заказчика. В идеальном сценарии заказчик берет свои требования из реальной статистики: У меня на другой площадке работает точно такое же оборудование и оно потребляет те самые 7-8 заявленных киловатт. Но такое бывает нечасто. Чаще есть примерный список оборудования, которое будет установлено в дата-центре.

Нередко бывает, что в спецификации на серверное оборудование мощность считают по мощности блоков питания и затем закладывают запас 30 %. Получается, что нагрузку рассчитали на бумаге. Но в реальности инженеры никогда не грузят свою систему на 100 %. Реальный коэффициент спроса с сервера будет максимум 80 %, так что искусственный запас будет лишним. Такие расчеты мы корректируем, обсуждаем и согласовываем с заказчиком.

Для понимания общей картины наши инженеры копают еще глубже и анализируют нагрузку с точки зрения задач системы. В сервере несколько потребителей электричества: процессор, память, диски, кулеры. Больше всего ресурсов требует CPU. Например, у сервера со средним потреблением 11,2 кВт на процессор уходит 800900 Вт. При этом далеко не все нагрузки требуют максимальной утилизации процессора. Если мы говорим о среднестатистических задачах вроде файловых шар, почты, системы хранения данных, терминальных серверов или веб-серверов, то загрузка CPU составит 2030 %. Серьезную нагрузку на процессор стоит планировать в случае баз данных: там мы легко можем дойти до 8090 %.

Про 5 кВт с точки зрения ИТ мы говорили с моим коллегой Андреем Будреевым в нашем последнем выпуске подкаста Разговоры из-под фальшпола. Заодно обсудили будущее процессоров с точки зрения экологии заглядывайте на огонек и делитесь своими прогнозами.

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

Подробнее..
Категории: It-инфраструктура , Хранение данных , Хранилища данных , Дата-центры , Блог компании dataline , Цоды , Стойки , Capacity management , 5 квт

Проверка двигателя на прочность как мы тестируем динамические ИБП

11.03.2021 12:11:09 | Автор: admin

Привет, Хабр! Меня зовут Виктор, я главный инженер-энергетик в мегаЦОДе "Удомля". Мои коллеги уже показывали, как мы организуем гарантированное электропитание дата-центра с помощью ДГУ и регулярно проверяем их работоспособность. Но кроме ДГУ есть другое оборудование, которое может одновременно обеспечить гарантированное электроснабжение и бесперебойное питание. Речь о дизельных динамических ИБП (ДИБП). Такие установки стоят в нашем мегаЦОДе, и мы уже немного рассказывали про их устройство в экскурсии по дата-центру.

Сегодня покажу, как мы проводим тестирование дизельных двигателей ДИБП, чтобы быть уверенными в их надежности.

Немного про устройство ДИБП

ДИБП совмещает функции нескольких устройств в одном: один блок заменяет систему из ДГУ, статических ИБП и аккумуляторных батарей. Правда, и ревут они сильнее: уровень шума от классических ДИБП сравним с шумом от перфоратора.

Помещение ДИБП. Не рекомендую появляться здесь без средств защиты слуха.Помещение ДИБП. Не рекомендую появляться здесь без средств защиты слуха.

Схема электроснабжения с ДИБП строится немного по-другому. Городское электропитание с понижающих трансформаторов идет двумя независимыми маршрутами в распределительное устройство низкого напряжения (РУНН). А оттуда через ДИБП электричество поступает сразу на ИТ- и инженерное оборудование. Если питание от города пропадет, ДИБП мгновенно примет всю нагрузку на себя.

Cхема электроснабжения мегаЦОДа Удомля.Cхема электроснабжения мегаЦОДа Удомля.

У нас в Удомле стоят дизель-роторные источники бесперебойного питания Euro Diesel. В таких ДИБП дизельный двигатель с помощью электромагнитного сцепления соединяется со статогенератором переменного тока. Этот генератор состоит из аккумулятора кинетической энергии и синхронной обратимой электрической машины.

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

Вот так вкратце выглядит схема переключения:

Годовое техническое обслуживание ДИБП на ЦОДе "Удомля" разделено на этапы и проводится несколько раз в течение года. Такой поэтапный график помогает нам сократить простой ДИБП на время обслуживания. Отдельно обслуживаем электрическую часть: проверяем электромагнитное сцепление, проводим обслуживание аккумулятора кинетической энергии и обратимой синхронной электрической машины. Отдельно проверяем и тестируем дизельный двигатель ДИБП. Такое годовое ТО дизеля мы провели в феврале, расскажу о нем подробнее.

План тестирования дизельного двигателя

В тестировании дизеля участвуют наши инженеры службы эксплуатации и инженеры вендора. Во время ТО мы контролируем несколько параметров:

  • проверяем резиновые шланги и натяжение ремней генератора,

  • проверяем температуру замерзания и уровень охлаждающей жидкости,

  • контролируем исправность работы предпусковых подогревателей и состояние радиатора охлаждения двигателя,

  • проверяем напряжение заряда батарей, уровень и плотность электролита,

  • замеряем остаточную емкость и напряжение АКБ,

  • меняем фильтры и масло в двигателе,

  • проводим тест дизельного двигателя ДИБП при нагрузке мощностью 100 %.

Благодаря такой программе теста мы не только гарантируем, что ДИБП не подведет в критический момент, но и параллельно контролируем работу систем вентиляции и топливоснабжения.

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

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

Подготовка к тестированию

Оповещение. За 7 календарных дней до начала ТО служба технической поддержки предупреждает о работах клиентов ЦОДа и службу эксплуатации. Обязательно указываем время и последовательность тестирования. На 6 установленных ДИБП у нас отводится 6 дней.

Заказ нагрузочных модулей. До начала ТО в ЦОД поставляются расходные материалы и нагрузочные модули. Мы используем 2 модуля, по 1 мВт каждый.

Переключение ДИБП и подключение нагрузки. Мы начинаем ТО с остановки ДИБП и подключения модулей. Все переключения производятся на двух щитах ДИБП: управления и силовом.

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

Сенсорная панель на щите управления ДИБП. Сенсорная панель на щите управления ДИБП.

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

Регламентные работы перед тестовым пуском

Первые этапы по плану ТО нужно выполнить при выключенном генераторе. Поэтому сначала выведем установку в ремонт.

  1. Перейдем к панели управления ДИБП. На дисплее слева мы видим, чтопитание ИТ-оборудования и инженерных систем ЦОДа идет по стандартной схеме. На схеме обозначены автоматические выключатели в цепи: QD1, QD2 включены, QD3 отключен.

    Справа видим ключ в положении "Нагрузка защищена". Это означает, что бесперебойная работа всего оборудования под защитой ИБП. Электромашина работает в режиме электродвигателя, аккумулятор накапливает кинетическую энергию, все хорошо:

  2. Справа при помощи верхнего ключа переводим режим работы на механизм обходного пути, или байпас (о нем уже рассказывали в одной из статей). С его помощью запитанное от ДИБП оборудование сразу переводится на питание от города в обход установки, а генератор отключается от сети. Теперь на схеме мы видим, что выключатели QD1 и QD2 отключены, QD3 включен:

  3. Чтобы никто случайно не включил установку и не поставил под угрозу выполнение регламентных работ, мы переводим выключатели QD1, QD2 в ремонтное положение на силовой панели ДИБП:

После остановки накопителя и генератора проводим регламентные работы по плану тестирования: проверяем ремни, жидкости, фильтры, все системы и агрегаты.

Панель управления остановленного ДИБП.Панель управления остановленного ДИБП.

Тестовый пуск двигателя ДИБП под нагрузкой

После всех манипуляций по плану ТО переходим к заключительной стадии тесту дизельного двигателя под нагрузкой 100 %.

  1. На силовом щите ставим выключатели QD1, QD2 обратно в рабочее положение. Ключ управления переводим в положение "УПРАВЛ. ЧЕРЕЗ HMI". Кнопки на сенсорной панели станут активны.

  2. Включаем машину в режиме "БАЙПАС-RUN". Видим на схеме, что QD1 включен, QD2 выключен.

    Теперь генератор получает питание от городской сети и работает как электродвигатель, раскручивая аккумулятор кинетической энергии. ИТ-оборудование и инженерные системы ЦОДа получают питание по байпасу через QD3.

  3. Переводим ДИБП в режим тестирования: открываем щит управления и устанавливаем переключатель "TEST KS" в положение 1.

    В режиме теста выключатель QD2 блокируется. На экране панели появляется надпись "РЕЖИМ ТЕСТА KS".

  4. Следующий шаг подключение нагрузочных модулей к шинам генератора.

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

  5. Чтобы запустить двигатель ДИБП, проводим тестовый отказ сети. Нажимаем кнопки "ОТКАЗ СЕТИ" и "FORCE" на панели управления.

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

    ДИБП работает в режиме генератора. ДИБП работает в режиме генератора.

  7. Теперь поднимаем нагрузку до необходимых значений. Для этого используем переключатели на панелях нагрузочных модулей. На панели управления ДИБП видим, что этот параметр достиг 1764,1 кВт.

    Смотрим на работу ДИБП под нагрузкой.Смотрим на работу ДИБП под нагрузкой.

Двигатель работает в этом режиме около 2 часов. Во время теста мы контролируем несколько параметров ДИБП:

  • температуру подшипников,

  • скорость вращения валов,

  • давление масла,

  • воздух в помещении и температуру жидкостей,

  • заряд батареи.

Все параметры отображаются на дисплее. Все параметры отображаются на дисплее.

Также контролируются электрические параметры: частота, мощность и напряжение.

Фиксация результатов и переключение обратно

После испытаний мы в обратной последовательности отключаем нагрузочные модули, выводим ДИБП из тестового режима и переводим ключ на панели управления в положение "НАГРУЗКА ЗАЩИЩЕНА". Сценарий переключения отработан, никакие перебои в электроснабжении помешать работе дата-центра не должны.

По результатам испытаний в протоколах указываем все полученные параметры. ДИБП переходит на следующий круг проведения ТО по годовому графику.

Подробнее..
Категории: It-инфраструктура , Инженерные системы , Ибп , Цод , Хранение данных , Хранилища данных , Дата-центры , Дата-центр , Блог компании dataline , Цоды , Дизель-генератор , Дгу , Дибп , Динамические ибп , Дизельный двигатель

Возможно ли сделать ЦОД эффективнее и экономичнее одновременно?

30.03.2021 18:20:32 | Автор: admin

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

С начала массового строительства центров обработки данных минуло 25 лет, а рынок очень далек от насыщения ежегодно мировые вложения в строительство дата-центров растут на 15%. При этом ЦОДы становятся всё более мощными и дорогими. Стоимость строительства и эксплуатации напрямую влияет на цену цифровых услуг, например, хостинга, облачных хранилищ и вычислений, поэтому все заинтересованы в повышении эффективности и экономичности дата-центров во всём мире. Какие меры для снижения стоимости услуг ЦОДов можно предпринять?

Высокие технологии с высоким энергопотреблением


По оценкам журнала Nature, в год на снабжение дата-центров во всём мире уходит порядка 200 ТВтч, причем 140 ТВтч приходится на ЦОДы США. Еще шесть лет назад дата-центры потребляли только 91 ТВтч, то есть рост составил внушительные 220% Сейчас ЦОДы потребляют больше, чем вся Украина (122 ТВтч), Аргентина (129 ТВтч), Швеция (134 ТВтч) или Польша (150 ТВтч).

Несмотря на то, что дата-центры это не дымящие трубы и вредные отходы, а облачные вычисления, они тоже оставляют серьезный углеродный след в мировой экологии примерно 0,3% от общемировых выбросов, что немало. Всё потому, что доля зеленой энергетики в главных странах-держателях ЦОДов очень мала (11% в США, 26% в Китае, всё с учетом гидроэлектростанций), поэтому на электроснабжение дата-центров работают газовые и угольные электростанции. В итоге экологи и европейские правительства недовольны ростом выбросов парниковых газов, операторы электросетей недовольны растущей нагрузкой и необходимостью модернизировать сети, владельцы ЦОДов недовольны затратами на обслуживание.

Главная после операционных расходов статья содержания дата-центра электричество, на которое может прийтись до половины расходов. Для оценки энергоэффективности ЦОДов применяется коэффициент PUE (Power usage effectiveness эффективность использования энергии), выражающий отношение всего потребляемого электричества к потреблению ИТ-оборудования. PUE, равный 1,0, идеален и недостижим, к нему можно только стремиться, так как к серверам непременно прилагаются системы охлаждения и мониторинга, тоже требующие электропитания. На охлаждение может приходится 50-80% от потребления ИТ-оборудования, а то и больше, поэтому средний PUE в мире сейчас составляет 1,67 (1 единица энергии уходит серверам и 0,67 единицы другому оборудованию). Благодаря комплексному подходу в лучших случаях PUE можно снизить до 1,051,10, а это выливается в колоссальную экономию на электроснабжении.

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


Согласно опросу владельцев ЦОД, многие хотели бы улучшить энергоэффективность, охлаждение, планировку или местоположение дата-центров. Источник: Solar Thermal Magazine

Обновление ИБП для минимизации потерь


Для обеспечения резервирования электропитания, а также для защиты дорогостоящего оборудования дата-центров от скачков напряжения и других проблем питающей электросети применяются онлайн-ИБП с нулевым временем переключения на батарею. За бессбойную работу серверов приходится платить повышенным энергопотреблением при двойном преобразовании напряжения в целях повышения его характеристик неизбежны потери, которые тоже приходится оплачивать. КПД ИБП напрямую зависит от нагрузки чем она выше (в рамках характеристик ИБП), тем больше коэффициент полезного действия. КПД актуальных онлайн-ИБП в режиме двойного преобразовния при высокой нагрузке может составлять 85-95%, а сильно устаревших моделей пугающие 40-50%. То есть от 15% до 50% электроэнергии исчезают в ходе преобразования, но не исчезают из суммы затрат. Для старых ИБП особенно остро стоит проблема низкого КПД при невысокой загрузке.

Самые современные специализированные онлайн-ИБП могут достигать КПД до 99% при штатной работе. Вот поэтому обновление парка ИБП может круто снизить затраты на обслуживание ЦОДа и заметно повысить PUE. Пример ИБП от Eaton, недавно попались на глаза. Для маленьких ЦОДов компактные Eaton 9SX/9PX на 5/6/8/11 кВА (серия 9PX оснащена портом DB15 для организации параллельной работы двух ИБП). Эти ИБП имеют КПД до 98% в высокоэффективном режиме работы и до 95% при двойном преобразовании. Каждый модуль полностью автономен и может устанавливаться как вертикально, так и в 19-дюймовую стойку. Для снижения затрат на обслуживание батареи в 9SX/9PX используется технология управления зарядом Eaton ABM, которая увеличивает срок службы аккумуляторов на 50%. Вместо постоянной подзарядки малым током ABM следит за уровнем заряда и подзаряжает батареи только тогда, когда это нужно.

А вот для современных больших ЦОД, владельцы которых больше заинтересованы в бесперебойной работе оборудования, чем в экономии каждого рубля, лучше обратить внимание на башенные ИБП Power Xpert 9395P. В режиме сохранения энергии ESS они обладают КПД 99%. Топовая модель серии 9395Pрассчитана на 1200 кВА.

Обновляем распределители питания


Такая, казалось бы, банальная вещь, как распределители питания (PDU, или Power distribution unit), тоже могут быть причиной повышенного расхода электроэнергии. Предназначение и функциональность PDU просты контроль напряжения и его подведение к оборудованию. Хотя на этапе планирования ЦОД велик соблазн отдать предпочтение дешевым розеточным блокам без возможности удаленного управления, возможные перегрузки фазы могут привести к отключению электроснабжения, и тут даже ИБП не помогут.

А еще дешевые PDU имеют невысокий КПД. Современные дорогие интеллектуальные модели поставляются с добротным трансформатором, отвечающим высоким требованиям стандарта энергоэффективности TP-1. Сертификация TP1 подразумевает повышение КПД PDU примерно на 2-3% относительно обычных моделей, что вроде бы немного, но при пересчете на годовые затраты выливается в приятную экономию. Помимо этого, современные PDU упрощают кабель-менеджмент, помогают уменьшить количество проводов и тем самым улучшить обдув компонентов. Да, PDU с сертификатом TP-1 закономерно дороги, но затраты на них отбиваются примерно за 6 лет, тогда как срок службы таких PDU составляет не менее 20 лет.

Заменяем освещение на светодиодное


В сравнении с энергопотреблением серверов или систем охлаждения на освещение ЦОД приходится около 1% от всей необходимой дата-центру электроэнергии. Скромно, но при обновлении освещения экономия будет отражаться не только в счетах за электричество, но и в сметах на замену ламп.

Немало устаревших ЦОД продолжают освещаться энергосберегающими ртутными лампами, которые уступают светодиодам во всём, кроме, разве что, цены. Но ресурс ртутных ламп примерно в 5 раз ниже, чем у светодиодных. Яркость LED-светильника снизится до критических 70% от изначальной за 50 000 часов, после чего его придется менять. Энергосберегающая лампа деградирует до того же уровня всего за 10 000 часов, то есть чуть больше чем за год. Таким образом на одну замену LED-источников придется до пяти замен ртутных ламп!

Ещё яркость светодиодов можно легко менять, снижая энергопотребление в зависимости от времени суток. А для получения того же уровня освещенности при применении LED-ламп требуется на треть меньше, чем нужно энергосберегающих светильников.

Используем free cooling


Лучший ресурс бесплатный и возобновляемый. В деле охлаждения серверов таким ресурсом являются уличный воздух и грунтовые воды. Вместо того, чтобы тратить огромные средства на работу чиллеров, куда как экономичней будет охлаждать оборудование забортным холодом. Подход free cooling, при котором в систему охлаждения поступает холодный отфильтрованный воздух или вода, заслуженно считается одним из лучших способов снизить затраты на содержание дата-центра. За счёт отказа от кондиционеров в пользу free cooling можно гарантированно снизить PUE с 1,8 до 1,1.

В вопросе free cooling вне конкуренции находятся скандинавские страны. В увлеченной экологичностью всего и вся Швеции тепло в дата-центрах используют для нагрева воды в системе отопления жилья. Ирландцы поставили на службу free cooling пронизывающие страну даже летом островные ветра, а датчане пускают в систему охлаждения ледяные грунтовые воды, имеющие одинаково низкую температуру и зимой, и летом.


Google особенно гордится тем, что за счет free cooling в своих европейских дата-центрах компания экономит воду, которая могла пойти на работу электростанций для выработки электричества для чиллеров (если бы они были). Источник: Google

Климат обжитой центральной части России, не говоря уже про северо-западный регион, радует сторонников free cooling (и не радует всех остальных) исключительно малым количеством жарких дней. По статистике Росгидрометцентра, в средней полосе страны только 3,8% времени в году наблюдается температура выше +22 C, а среднегодовая температура в Санкт-Петербурге всего +5,6 C. Для сравнения, в американском штате Аризона, где построен огромный ЦОД Apple, тоже использующий free cooling, даже в январе температура редко опускается ниже +6 C, ее среднегодовой уровень держится выше +16 C. Поэтому как минимум четверть времени в году Apple вынуждены использовать прожорливые чиллеры для охлаждения 120 тыс. кв. м площадей своего ЦОДа.

Это не значит, что пришло время осваивать сибирскую целину. Хоть климат России и располагает к самому эффективному использованию free cooling, на этом преимущества севера страны для строительства ЦОДов заканчиваются. Зато недостатков хватает: низкая транспортная доступность, дефицит высококвалифицированных кадров, плохое состояние телекоммуникационных и энергосетей.

Тем не менее, первые шаги по созданию новых ЦОДов на севере уже сделаны: Петрозаводский государственный университет приступил к развертыванию весьма серьезного дата-центра, который претендует на 20% российского рынка облачных хранилищ. При этом карельская погода должна снизить стоимость эксплуатации примерно на 40%. Университетские сотрудники и выпускники, а также близость к Санкт-Петербургу прекрасно решают и проблему кадров, и вопрос подключения к точке обмена трафиком.


Один из дата-центров Яндекса расположен в холодной Финляндии. За счет free cooling его коэффициент PUE удалось снизить до 1,1

Призываем на помощь ИИ


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

В 2014 году Google приобрела компанию DeepMind, известную своим продуктом AlphaGo, впервые обыгравшим профессионального игрока в го. На основе наработок DeepMind был создан программный комплекс для ЦОД Google, который может не только следить за показаниями датчиков и нагрузкой, но и делать выводы на основании накопленной истории наблюдений и полученных погодных прогнозах. С внедрением ИИ энергозатраты на охлаждение ЦОД Google снизились на впечатляющие 40%, при этом всё оборудование осталось прежним.


Результат работы ИИ DeepMind в ЦОД Google при включении машинного обучения, система снижала потребление электроэнергии на охлаждение. Источник: DeepMind

Отдельные решения на базе ИИ нашли своё место в ЦОД Сбербанка в Сколково. Так как дата-центр 330 дней в году использует free cooling, система отслеживает внешнюю температуру и прогноз погоды и на основании этого оптимизирует энергозатраты на охлаждение и даже принимает решение о запасе холодного воздуха на случай потепления.

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

Используем модульные дата-центры


Строительство или расширение ЦОД процесс не только дорогой, но и долгий во многом из-за необходимости проектировать капитальное строение и проводить проект по всей цепочке необходимых согласований. От заключения контракта до сдачи в эксплуатацию компактного дата-центра с площадью 200-300 кв. м проходит 9-12 месяцев, и это при условии, что документы не подвиснут ни в одной из инстанций, выдающей своё разрешение на строительство.

Концепция модульных дата-центров, эдаких кирпичиков, из которых, как из конструктора, можно было бы быстро собирать ЦОДы, родилась в середине 2000-х годов. Первопроходцами в этом считается Sun со своим Sun Modular Datacenter модульным ЦОД внутри стандартного морского грузового контейнера, в котором уместились восемь 40-юнитовых стоек, серверы и сетевое оборудование и система охлаждения. Развертывание модульного Sun Modular Datacenter обходилось примерно в 1% от строительства традиционного дата-центра, его можно было легко перевозить с места на место, а подключение ограничивалось подводом электричества, водоснабжения и сети.


В 2009 году небезызвестный архив интернета archive.org переехал в один Sun Modular Datacenter. Впрочем, хранился он там недолго за десять лет объем archive.org вырос с 3 до 50 петабайт. Источник: NapoliRoma / Wikimedia Commons
Сейчас рынок предлагает модульные дата-центры в самом различном исполнении, а не только в виде контейнеров. Модули считаются самым эффективным способом быстрого строительства или расширения ЦОД без лишних затрат и долгих согласований. Модули занимают меньше места и эффективнее используют площадь за счет заранее продуманной компоновки, имеют меньшее энергопотребление и зачастую лучшее охлаждение, их легко можно переместить ближе к месту с дешевым электричеством (рядом с крупными электростанциями). Так что прежде чем думать о строительстве или расширении дата-центра, стоит обратить внимание на готовые модули.

Запитываем ЦОД от возобновляемых источников энергии


В сравнении с Европой у России есть важное экономическое преимущество, которое делает размещение ЦОД на ее территории весьма привлекательным, исключительно низкая стоимость электроэнергии. В некоторых регионах страны она доходит до 3 руб. за кВтч, тогда как в Германии около 23 руб. за кВтч, а в США в среднем 9 руб. за кВтч. Плюс в России власти пока не относятся к экологии так же щепетильно, как в скандинавских странах. Поэтому у нас вопрос перехода ЦОД на автономное электроснабжение из возобновляемых источников энергии пока не стоит.

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

Так Apple, один из передовиков по использованию зеленых технологий, первой перевела свои ЦОДы на электричество от собственных солнечных и ветровых электростанций. Дошло до того, что в 2016 году компания подала заявку о желании начать продажу излишков выработки со своих американских солнечных электростанций мощностью 90 и 130 МВт.

Автономное электроснабжение будет полезным в областях, далеких от мощный электросетей. Например, исландский ЦОД Verne Global построен рядом геотермальными электростанциями. Хоть они и не принадлежат компании, зато являются экологичными, возобновляемыми и очень стабильными источниками энергии.

В Германии на зеленую энергию приходится уже больше половины всей выработки. К сожалению, в России доля возобновляемой энергетики колеблется на уровне 4%, две трети из которых гидроэнергетика. Но для новых ЦОД в качестве задела на будущее подумать об автономном питании от солнечной или ветряной электростанции не помешает.

Экономия лишней не бывает


Самый крупный и дорогой дата-центр в мире принадлежит телекоммуникационному гиганту China Telecom. Он занимает площадь 994 тыс. кв. м, а строительство обошлось в 3 млрд долларов. Самый большой российский ЦОД построен Сбербанком в Сколково. Он в 30 раз меньше китайского гиганта всего 33 тыс. кв. м. Но благодаря грамотному внедрению фрикулинга, ИИ и отопления помещений теплом оборудования удалось достичь экономии на обслуживании около 100 млн рублей в год. Учитывая размеры дата-центра China Telecom, можно быть уверенным, что там тоже были применены все возможные способы снижения затрат. Какой бы абсурдной и малозначимой не казалась мера по удешевлению обслуживания ЦОД, в годовом эквиваленте она может принести очень заметную экономию, пропорциональную размеру ЦОД.
Подробнее..
Категории: It-инфраструктура , It-компании , Сетевое оборудование , Дата-центры , Google , Яндекс , Энергия

Huawei ADN первая в индустрии сеть с автономным управлением третьего уровня

28.04.2021 16:12:49 | Автор: admin
Что такое автономно управляемая сеть и чем она отличается от SDN? Huawei совместно с консалтинговой компанией IDC изучила критерии оценки сетевой инфраструктуры по уровню её способности поддерживать собственную работу без помощи администратора.



Какой заказчики хотят видеть сетевую инфраструктуру ЦОДа? Она, конечно, должна быть эффективной, надёжной и простой в обслуживании. Совсем чудесно было бы, если бы сеть настраивала и обслуживала себя сама. Современные SDN-контроллеры умеют всё больше, но как оценить уровень их автоматизации? Как классифицировать эту автономность?

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



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

Между тем не следует рассматривать облако просто как место выполнения рабочих нагрузок. Это ещё и особые подходы к работе, подразумевающие высокий уровень автоматизации. По мнению аналитиков IDC, мы вступаем в эпоху множества инноваций. Компании инвестируют в такие технологии, как искусственный интеллект, интернет вещей, блокчейн и интерфейсы естественного взаимодействия. Но конечная цель это именно автономность систем и инфраструктур. В таком контексте и следует оценивать перспективы развития сетей ЦОД.



На схеме изображён процесс автоматизации сетей, который делится на несколько последовательных этапов. Он начинается с интерфейса командной строки и создания скриптов. На следующем этапе появляются сетевые фабрики, позволяющие повысить скорость и производительность. Далее наступает пора SDN-контроллеров и средств виртуализации. На этом этапе также внедряются инструменты оркестрации и автоматизации сетей ЦОД.

Качественно новым уровнем является переход к сетям, управляемым на основе намерений (intent-based networking). Но целью этого прогресса является создание полностью автономной сети, управляемой искусственным интеллектом. Все участники рынка так или иначе рассматривают эту задачу.

Что же такое автономность сети и как её оценить? Компания IDC предложила шестиуровневую модель, позволяющую точно отнести конкретное решение к тому или иному уровню автономности.

  • Level 0. На этом этапе управление сетью осуществляется только через ручные процессы на протяжении всего жизненного цикла сети. Сеть не является автоматизированной.
  • Level 1. Управление сетью всё ещё преимущественно ручное на протяжении всего жизненного цикла сети.
  • Level 2. В некоторых сценариях появляется частичная автоматизация, которая сочетается со стандартными инструментами анализа и управления политиками.
  • Level 3. Условная автоматизация. Система уже умеет выдавать рекомендации и указания, принимаемые или отклоняемые оператором.
  • Level 4. Сеть в значительной мере автоматизирована и автономна. Управляется она декларативными методами на основе намерений. Оператор лишь получает уведомления о событиях и принимает решения о принятии или отклонении рекомендаций сети.
  • Level 5. Сеть полностью автоматизирована и автономна на протяжении всего жизненного цикла. Она способна самостоятельно применять политики, устранять неисправности и восстанавливать сервисы.




С какими же основными вызовами сталкивается компания, внедряющая инновации в сетях ЦОД? По данным IDC, собранным на основе опросов IT-экспертов, на первом и втором местах находятся согласование уровня автоматизации сети с уровнем автоматизации систем вычисления и хранения, а также обеспечение гибкости, то есть способности сети поддерживать смешанные рабочие нагрузки и среды.

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

Исследование IDC показывает, что автономное управление сетью является остроактуальным трендом, в который так или иначе вовлечено до половины всех компаний, занимающихся развитием своей IT-инфраструктуры.



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

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



Вместе с тем инновации в работе с клиентами повлекли за собой повышение сложности IT-инфраструктуры и увеличение частоты вносимых в неё изменений. До 50% сложных проблем, регистрируемых сейчас в ЦОДах, в той или иной мере обусловлены ограниченностью как самих сетевых ресурсов, так и ресурсов команды администраторов.

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

Пожалуй, это объясняет следующую цифру: до 40% сложных проблем в ЦОДах вызваны человеческими ошибками. Любые изменения в сети, как то: запуски новых приложений, развёртывание сервисов и т. д., требуют большого внимания и многочисленных проверок, на которые далеко не всегда хватает рабочего времени. Итогом может стать серьёзная авария в ЦОДе.

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

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



Вернёмся к классификации уровней автономности, предложенной IDC. Перед вами перечень возможностей, которые сеть должна демонстрировать на каждом из этих уровней. Решение Huawei Autonomous Driving Network отвечает всем требованиям третьего уровня. Она умеет в полностью автоматическом режиме поддерживать свою работу, включая запуск и остановку процессов, настройку оборудования и пр. Кроме того, наша ADN в полной мере соответствует критерию осведомлённости, в реальном времени получая информацию о состоянии устройств, процессов, приложений и сервисов.

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

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

В соответствии со своим roadmap к 2028 году мы будем располагать системой, полностью соответствующей пятому уровню автономности.



Каким же будет эффект от внедрения автономного управления сетью? Начнём с проектирования сети. В случае использования Huawei Autonomous Driving Network заказчику нет необходимости вручную создавать архитектуру или дизайн, а также настраивать устройства. Система лишь просит указать, какое количество устройств и линков определенной пропускной способности должно быть задействовано. Затем она автоматически собирает сетевую инфраструктуру и предлагает её в виде готового решения. Заказчик сразу же получает полностью работоспособную фабрику дата-центра.

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

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

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

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



Сила Huawei Autonomous Driving Network в том, что это не просто программное обеспечение, которое можно проинсталлировать и получать сервис. В системе реализована трёхуровневая модель, базовый уровень которой расположен уже на уровне процессоров конечных устройств коммутации и маршрутизации. Эти программно-аппаратные элементы выполняют задачи по сбору и анализу данных, а также коммутации потоков и кадров. Оснащённый таким процессором коммутатор в режиме реального времени передаёт информацию в направлении программной платформы, в качестве которой в нашем случае выступает iMaster NCE.

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

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

Подходы, использованные при создании ADN, позволяют в очередной раз вспомнить наш принцип 1-3-5: любая проблема в сети должна быть выявлена за одну минуту, локализована за три минуты и исправлена за пять минут.



Подведём итог. Конечно, ADN является преемницей решений, заложенных в SDN. Это был необходимый этап развития технологии, но в нём крылись некоторые недостатки. Во-первых, использование программно-определяемых сетей подразумевало ручную первичную настройку устройств. Во-вторых, выявление ошибок также ложилось на плечи специалистов по поддержке сети. В-третьих, в случае с SDN, конечно, не шла речь об автоматическом применении сценариев восстановления, полученных из облачной базы знаний. Создавая своё ADN-решение, Huawei стремилась к тому, чтобы наши клиенты освободились от этих задач, сосредоточившись на том, что действительно требует внимания.
Подробнее..
Категории: It-инфраструктура , Цод , Сетевые технологии , Сетевое оборудование , Дата-центры , Блог компании huawei , Huawei , Huawei enterprise , Sdn , 1-3-5 , Adn , Imaster nce , Autonomous driving network , Сети цод , Idc

Монтажный шкаф для ЦОД. Критерии выбора. Часть 2 оптимальная комплектация и возможности кастомизации

11.05.2021 12:14:21 | Автор: admin

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

Нужна ли шкафу дверь?

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

Перфорировать или нет?

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

Какая несущая способность шкафа вам нужна?

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

Что такое оптимальная комплектация?

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

  • Одностворчатую переднюю дверь и двухстворчатую заднюю (чтобы уменьшить зону обслуживания сзади);

  • Регулируемые ножки (установить шкаф на нужную высоту) и ролики в комплекте (чтобы отвезти до места установки);

  • Изоляцию переднего фронта шкафа по периметру (чтоб избежать утечек воздуха);

  • Кабельные вводы в крыше со щеточным краем или другой защитой от утечки воздуха (в задней части для установки БРП, в передней или средней для слаботочной коммутации);

  • Вертикальные монтажные панели (для установки БРП и аксессуаров);

  • Комплект объединения в ряд;

  • Поставку в сборе на паллете (чтобы не отнимать у заказчика время на сборку!).

Кастомизация и аксессуары

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

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

Хорошим тоном со стороны поставщика считается добавление к поставке крепежа и инструментов для установки оборудования.

Сервис

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

  • разгрузка;

  • распаковка;

  • транспортировка до машзала;

  • расстановка и сборка в ряды;

  • утилизация упаковки;

  • установка 19профилей на нужной глубине;

  • монтаж аксессуаров на определённый юнит;

  • закрепление блоков распределения питания и т. д.

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

Подробнее..
Категории: It-инфраструктура , It-стандарты , Big data , It-компании , Dc , Дата-центры , Серверные шкафы , Шкафы

Китай начал строить первый коммерческий дата-центр на дне моря

29.05.2021 02:13:41 | Автор: admin

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

А вот Китай, похоже, настроен очень серьезно. Представители администрации провинции Хайнань заявили о начале работ по созданию подводного центра обработки данных. Успешное тестирование в полевых условиях завершено. Теперь началось строительство полноценного ЦОД силами компании Highlander и нескольких других партнеров.

Что это за проект?


Согласно плану, на дне моря будет установлено около 100 специализированных герметичных резервуаров. Внутри них будет находиться серверное оборудование. О старте проекта было объявлено на крупном мероприятии с участием представителей правительства и таких компаний, как Highlander, Sinnet, Hainan Telecom и Lenovo.

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

Главным инициатором проекта является компания Highlander. Ее руководство считает подводные дата-центры весьма перспективным направлением работы в телекоммуникациях. Компания сообщала, что вдохновилась примером Microsoft, которая тестировала подводный ЦОД в течение двух лет, заявив о вполне удовлетворительных результатах. Но вот Microsoft пока что ничего не говорила о коммерциализации своего проекта, а китайская компания занимается этим прямо сейчас.


21 мая Highlander, предствители администрации и инвестиционная компания порта Хайнань заявили о пятилетнем плане строительства подводного центра. Резервуары располагаются на дне моря вокруг центрального коммуникационного модуля, который является как бы ядром всей системы. Главное достоинство такого дата-центра экономия электроэнергии благодаря отсутствию необходимости разворачивать сложную систему охлаждения.

Кстати, ЦОД размещается рядом с АЭС, так что проблемы в снабжении энергией нет станция будет поставлять столько электричества, сколько понадобится.

Тестовый дата-центр, к слову, был немного поврежден очень сильным штормом, так что организаторы проекта сделали выводы. Следующий ЦОД будет размещен в таком регионе морского дна, где повреждение штормом исключено, либо очень маловероятно.

Все идет по плану?


Вроде бы да. Проект будет реализован в три этапа. В 2021 году установят всего 5 резервуаров, которые начнут работу сразу же после установки. Еще 45 таких же резервуаров компания подключит с 2022 по 2023 год. И если все пройдет хорошо, то в строй введут еще 50 единиц уже с 2024 по 2025 год. На этом этапе к проекту подключат заинтересованные компании, которые станут клиентами Highlander. Еще одно достоинство дата-центра такого типа возможность его масштабирования. По словам представителей компании, масштабирование может быть сколь угодно большим, развернуть полноценный дата-центр при условии готовности модулей можно очень быстро.

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


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

С другой стороны, климат Хайнаня тропический. Здесь достаточно высокая среднегодовая температура. В ходе преобразования зоны в экономически свободную здесь понадобятся значительные вычислительные мощности, что приведет к строительству ЦОД. На их охлаждение понадобится огромное количество энергии, так что, возможно, выгоднее все же пустить дата-центр на дно, если так можно выразиться.

Что дальше?


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


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

Главное это вода, которая в случае плавучих дата-центров частично или полностью бесплатна, причем забирать ее можно из любой точки.
Еще одно достоинство мобильность. Плавучий ЦОД от Nautilus можно развернуть практически в любой точке мира, где есть необходимая инфраструктура. Таких мест не так уж и мало.
Экономия. Для плавучего дата-центра не нужна земля, которая во многих регионах очень дорогая. Кроме того, благодаря особенностям системы охлаждения расходы на отвод тепла снижаются минимум на треть.

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

Подробнее..
Категории: It-инфраструктура , It-компании , Сетевое оборудование , Блог компании selectel , Дата-центры , Сеть , Higlander

Microsoft отчиталась об успешном проведении эксперимента по созданию подводного дата-центра

15.09.2020 14:04:30 | Автор: admin
Летом 2018 года в рамках второй фазы испытаний проекта Natick по производству и эксплуатации экологичных и автономных сетевых систем, команда инженеров затопила в прибрежных водах Шотландии контейнер с небольшим дата-центром внутри.



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

Microsoft Project Natick это многолетние исследование по изучению методов производства и эксплуатации экологически устойчивых предварительно укомплектованных ЦОД стандартизированного формата и размера, которые можно быстро развернуть и оставить на годы с выключенным светом на морском дне.

Официальный блог проекта

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

Проект Natick начался еще в 2015 году. Тогда команда инженеров Microsoft разработала концепцию дата-центра в затопленном контейнере и провела испытания первого прототипа, названного Leona Philpot.


Leona Philpot пробный дата-центр в контейнере разработки Microsoft, август 2015 года

Именно на Leona Philpot инженеры Microsoft опробовали систему охлаждения оборудования за счет естественной внешней среды морской воды. Испытания проводились в Тихом океане, в 1 километре от побережья США. Конкретные локации не упоминаются, но, судя по пейзажам на фотографиях, слишком далеко на север инженеры тогда не забрались: вполне вероятно, первые испытания проводились вблизи побережья Калифорнии.

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


Сборка Leona Philpot на берегу перед погружением

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

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

В 2018 году эксперимент повторился. На этот раз инженеры собрали конфигурацию, близкую к коммерческой: выросло число серверов внутри контейнера, да и сам контейнер стал по размерам больше похож на железнодорожную цистерну, чем на бочку. Если быть точным, то это и есть цистерна. За основу корпуса взяли доработанный транспортный контейнер стандарта ISO, который активно используется по всему миру в грузоперевозках. Такое решение сняло вопрос не только по производству корпусов дата-центра, но и по его транспортировке стандартной логистикой к месту погружения. Планируемый ресурс бесперебойной работы итогового продукта пять лет под водой. Прототип получил название Northern Isles Северные острова.


Основные разработчики проекта Natick, слева направо: Майк Шепперд, старший инженер по исследованиям и разработкам, Сэм Огден, старший инженер-программист, Спенсер Фауэрс, старший технический специалист, Эрик Петерсон, исследователь и Бен Катлер, менеджер проекта

Теперь дата-центр затопили в холодных водах Шотландии, недалеко от Оркнейских островов. Контейнер опустили на морское дно, на глубину 35 метров, а подключался он к земле силовым и оптоволоконным кабелем.

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

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



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


Фото загруженной в контейнер мегастойки из 12 серверных стоек, в общей сложности на 864 сервера, 2018 год

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


Дата-центр после двух лет нахождения на морском дне

И вот, вчера, 14 сентября, Microsoft отчиталась о результатах своего эксперимента после подъема дата-центра.

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

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



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



Разработкой команды проекта Natick еще два года назад очень заинтересовались коллеги из Azure. Как признался их директор, возможность развертывания мобильных и автономных дата-центров, не требующих участия человека это мечта. Подобное решение точно будет востребовано в Юго-Восточной Азии, Африке, ряде регионов Европы.

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


На правах рекламы


Виртуальные серверы с защитой от DDoS-атак и новейшим железом, серверы размещены в одном из лучших российских дата-центров DataPro. Всё это про наши эпичные серверы. Максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe! Поспешите заказать.

Подробнее..
Категории: Экология , Сетевые технологии , Microsoft , Сетевое оборудование , Дата-центры , Серверное администрирование , Блог компании vdsina.ru — хостинг серверов , Natick , Underwater , Морской дата-центр , Погружной дата-центр , Дата-центр в контейнере , Зеленые технологии

Ресайклинг по-норвежски ЦОДам предложили направлять излишки тепла на обогрев помещений

25.02.2021 20:10:38 | Автор: admin

В Норвегии изучают вопрос вторичного использования тепла, выделяемого ЦОД. Предполагается, что тепло можно направить на бытовые и общественные нужды обогрев зданий, производств, для рыбных хозяйств.

Предложение поступило от Министра энергетики Норвегии Тины Бру (Tina Bru). Инициатива распространяется на все компании с установленными крупными энергетическими установками.

Как появилась такая инициатива?


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

  • суммарная мощность >20 МВт;
  • в качестве топлива используют газ, масло, отходы.

Бру предлагает расширить требования для Норвегии и включить в него дата-центры, суммарной мощностью более 2 МВт.

Министр отмечает, что ЦОДы за пределами больших городов помогут в обеспечении теплоэнергией промышленности, рыбным фермам и бассейнам.

Почему именно ЦОДы?



ЦОДы генерируют большие объемы тепловой энергии, охлаждая находящиеся внутри серверы и другое оборудование. Сейчас предполагается, что в будущем дата-центры будут регистрироваться в системе добровольно, находя в этом определенные преимущества.

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

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

Страна ЦОДов



Норвегия несколько лет назад объявила о стратегии, согласно которой планомерно превращается в страну ЦОДов. Она предлагает и налоговые льготы, и разного рода плюшки IT-компаниям, которые соглашаются сотрудничать. Так, в качестве налогов за электроэнергию ЦОДы платят около $0,005 за 1 кВт/ч, а потребители только $0,02.

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

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

Согретые ЦОДом


Помимо Норвегии, в сторону зеленых инициатив ЦОДов смотрит Дания. Мы рассказывали, что компания Facebook расширяет свой европейский дата-центр в датском городе Оденсе. На старте проекта мощности системы было достаточно для обогрева около 6,9 тыс. домов, но его планируют увеличить и довести количество обогреваемых домов до 11 тысяч.

А в Нидерландах серверы ЦОД обогреют фермы. Производитель ОСР-систем ITRenew намерен объединиться с голландским хостинг-провайдером Blockheating, чтобы обеспечить теплом от дата-центров тысячи гектаров теплиц, где выращивают томаты.

Подробнее..
Категории: Экология , Блог компании selectel , Будущее здесь , Дата-центры , Дата-центр , Энергия и элементы питания , Будущее , Тепловая энергия , Повторное использование

Envoy как универсальный сетевой примитив

05.02.2021 00:16:03 | Автор: admin

В октябре прошлого года мои коллеги представили на EnvoyCon доклад "Построение гибкой подсистемы компрессии в Envoy". Вот он ниже



Судя по статистике сегодняшней статьи от SergeAx, тема компрессии сетевого трафика оказалась интересной многим. В связи с чем я немедленно возжелал вселенской славы и решил кратко пересказать содержание доклада. Тем более, что он не только о компрессии, но и том, как можно упростить сопровождение сетевой подсистемы как backend'а, так и мобильного frontend'а.


Я не стал полностью "новелизировать" видео доклада, а только ту часть, которую озвучил Хосе Ниньо. Она заинтересует больше людей.


Для начала о том, что такое Envoy.


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



Принцип работы прокси-сервера очень прост: клиент устанавливает сетевое соединение не напрямую с сервисом, а через прокси-сервер, который в случае необходимости, например, сжимает проходящий через него сетевой трафик. Или оконечивает TLS. Или, не разрывая соединения с клиентом, пытается повторно соединиться с временно недоступным сервисом. Или, если совсем всё плохо, соединиться с резервным сервисом. И так далее.
Главное в том, что подобная схема заметно снижает сложность кода и клиента, и сервиса. Особенно сервиса.



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



Таким образом общая архитектура в очень многих компаниях всё чаще начинает выглядеть примерно вот так.



Мобильный клиент общается с граничным прокси (Edge), который решает, куда отправлять клиентские запросы дальше, попутно балансируя нагрузку на сервера. Сервисы получают запросы от Edge не напрямую, а через вспомогательные прокси (Sidecar). Далее, сервисы формируют ответы, опционально пообщавшись друг с другом, и отсылают их к Edge.


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



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



Так появился проект Envoy Mobile, который представляет собой байндинги на Java, Kotlin, Swift, Objective-C к Envoy. А тот уже линкуется к мобильному приложению как нативная библиотека.


Тогда задача уменьшения объёма трафика описанная в статье от FunCorp, могла бы быть решена примерно как на картинке ниже (если поменять местами компрессор и декомпрессор, и заменить response на request). То есть даже без необходимости установки обновлений на телефонах.



Можно пойти дальше, и ввести двустороннюю компрессию



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

Подробнее..
Категории: Микросервисы , Разработка мобильных приложений , Разработка под android , Разработка под ios , Высокая производительность , Android , Backend , Microservices , Service mesh , Ios , Дата-центры , Трафик , Compression , Envoy proxy

Перевод В чём главные проблемы Intel

29.01.2021 14:10:10 | Автор: admin


Оглядываясь назад, моя статья по поводу назначения нового исполнительного директора Intel в 2013 году оказалась чрезмерно оптимистичной. Одно название чего стоит: Возможность для Intel. В реальности вышло не так за эти годы у Intel ничего не получилось, никакими возможностями она не воспользовалась.

Откуда мы знаем, что не получилось? Во-первых, спустя восемь лет Intel опять назначает нового директора (Пэт Гелсингер), но не вместо того, о котором я писал (Брайан Кржанич), а вместо его преемника (Боб Свон). Очевидно, в то самое окно возможностей компания на самом деле не попала. И теперь уже встаёт вопрос выживания компании. И даже вопрос национальной безопасности Соединённых Штатов Америки.

Проблема 1: мобильные устройства


Вторая причина, по которой заголовок 2013 года был чрезмерно оптимистичным, заключается в том, что к тому моменту Intel уже попала в серьёзную беду. Вопреки своим заявлениям, компания слишком сосредоточилась на скорости CPU и слишком пренебрежительно отнеслась к энергопотреблению, поэтому не смогла сделать процессор для iPhone, и, несмотря на годы попыток, не смогла попасть на Android.

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

Когда речь идёт о миллиардных инвестициях в строительство фабрик следующего поколения, то вы или преуспеваете на рынке, или банкрот. Intel смогла сохранить миллиардные доходы благодаря революции в другой отрасли: облачных вычислениях.

Проблема 2: успех на серверах


Intel захватила этот рынок не так давно. Изначально на нём доминировали интегрированные компании, такие как Sun, с соответствующими ценами, но благодаря взрыву продаж персональных компьютеров Intel быстро улучшала производительность и снижала цены CPU, особенно по отношению к производительности. Конечно, ПК не дотягивали до надёжности интегрированных серверов, но на рубеже веков Google поняла, что масштаб и сложность услуг делают невозможным создание действительно надёжного стека. Решением стали отказоустойчивые серверы с горячей заменой вышедших из строя компонентов. Это позволило строить дата-центры на относительно дешёвых процессорах x86.



В течение двух следующих десятилетий подход Google приняли все крупные ЦОДы, так что x86 стала архитектурой по умолчанию для серверов. Основную выгоду из этого извлекла Intel, поскольку именно она делала лучшие процессоры x86, особенно для серверных приложений. Это связано как с собственным дизайном Intel, так и с её великолепными фабриками. AMD иногда угрожала действующему лидеру, но только в ноутбуках низкого уровня, а вовсе не в дата-центрах.

Таким образом, Intel избежала судьбы Microsoft в постдесктопную эпоху: Microsoft пролетела не только мимо мобильных устройств, но и мимо серверов, которые работают под управлением Linux, а не Windows. Конечно, компания как может поддерживает Windows и на компьютерах (через Office), и на серверах (через Azure). Однако всё выходит наоборот: то, что недавно подпитывало рост компании, становится концом Windows, поскольку Office переходит в облако с работой на всех устройствах, а Azure переходит на Linux. В обоих случаях Microsoft пришлось признать, что их власть теперь не в контроле над API, а в обслуживании уже существующих клиентов в новом масштабе.

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

Большинство компаний сами не выпускают чипы. Они создают дизайн и отдают на завод. AMD, Nvidia, Qualcomm, MediaTek, Apple ни у кого нет собственных заводов. Безусловно, это имеет смысл: производство полупроводников, возможно, самая капиталоёмкая отрасль в мире, так что AMD, Qualcomm и другие хотят заниматься более прибыльными проектами с более высокой маржой.

Однако проектирование микросхем становится всё более стандартным. Почти все чипы основаны на архитектуре ARM. Оплатив лицензию, компании вроде Apple могут создавать собственные модификации и заказывать их производство. Дизайн немножко уникален, но в мобильных устройствах это не самое принципиальное. Здесь никогда не будет доминировать единый дизайн от одного разработчика, как Intel доминировала на десктопном рынке.

С другой стороны, именно производственные мощности становятся более дефицитными и, следовательно, более ценными. На самом деле в мире только четыре крупных производственных компании: Samsung, GlobalFoundries, Taiwan Semiconductor Manufacturing Company (TSMC) и Intel. Только четыре компании могут создавать чипы, которые сегодня установлены в каждом мобильном устройстве, а завтра будут установлены вообще везде.

Огромный спрос, дефицит компонентов, высочайшие барьеры для входа. Получается, сейчас отличное время для производства микросхем. Это потенциально отличное время для Intel. Ведь из этих четырёх компаний она самая продвинутая, со значительным отрывом. Единственная проблема заключается в том, что Intel всегда видит себя дизайнерской компанией.

Кстати, моя рекомендация не означает отказ от x86, я добавил в сноске:

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

На самом деле, бизнес x86 оказался слишком прибыльным, чтобы пойти на такой радикальный шаг. Это именно та проблема, которая ведёт к разрушению. Да, Intel избежала судьбы Microsoft, но при этом не испытала сильнейшей финансовой боли, которая необходима как стимул для такой кардинальной трансформации бизнеса (например, только после краха рынка памяти в 1984 году Энди Гроув в Intel решил полностью сосредоточиться на производстве процессоров).

Проблема 3: производство




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

Это угрожает Intel по нескольким фронтам:

  • Intel окончательно потеряла рынок маков, в том числе из-за выдающейся производительности нового чипа M1. Но важно отметить причины такой производительности это не только дизайн Apple, но и 5-нм техпроцесс TSMC.
  • Десктопные процессоры AMD теперь быстрее, чем у Intel, и чрезвычайно конкурентоспособны на серверах. Опять же, преимущество AMD отчасти связано с улучшением дизайна, но не менее важным является производство по 7-нм процессу TSMC.
  • Крупные облачные провайдеры всё больше инвестируют в разработку собственных чипов. Например, Amazon уже выпустила вторую версию процессора Graviton ARM, на котором будет работать таймлайн твиттера. Одно из преимуществ Graviton его архитектура, а другое ну, вы уже поняли производство компанией TSMC по тому же 7-нм техпроцессу (который конкурирует с наконец-то запущенным 10-нм техпроцессом Intel).

Короче говоря, Intel теряет долю на рынке, ей угрожает AMD на x86-серверах и облачные компании типа Amazon с собственными процессорами. И я даже не упомянул других специализированных решений, таких как приложения на GPU для машинного обучения, которые разрабатывает Nvidia и производит Samsung.

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

Проблема 4: TSMC


К сожалению, это ещё не самое худшее. На следующий день после назначения нового директора Intel компания TSMC объявила впечатляющие финансовые результаты и, что более важно, прогнозы капитальных инвестиций на 2021 год, от Bloomberg:

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

Это огромная сумма инвестиций, которая только упрочит лидерство TSMC.

Предполагаемый рост финансирования привёл к тому, что производители оборудования для производства микросхем хлынули из Нью-Йорка в Токио. Капитальные расходы TSMC от 25 до 28 миллиардов долларов в 2021 году гораздо выше прошлогодних 17,2 миллиардов. Около 80% вложений направят на передовые технологии производства CPU, то есть TSMC ожидает резкого роста бизнеса по производству передовых микросхем. Аналитики предполагают, что после серии внутренних технологических сбоев Intel передаст производство на аутсорсинг таким компаниям, как TSMC.

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

Проблема 4: геополитика


Уязвимости Intel не единственное, о чём стоит беспокоиться. В прошлом году я писал о чипах и геополитике:

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

Ну а география, напротив, простая и понятная:



Как видите, Тайвань находится недалеко от китайского побережья. Рядом Южная Корея, родина Samsung, которая тоже производит чипы самого высокого класса. Соединённые Штаты по другую сторону Тихого океана. Есть передовые фабрики Intel в Орегоне, Нью-Мексико и Аризоне, но Intel производит чипы только для собственных интегрированных вариантов использования.

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

Если вы занимаетесь военным стратегическим планированием в США, это большая проблема. Ваша задача не предсказывать войны, а планировать действия, которые могут произойти при неудачном стечении обстоятельств, то есть если вдруг случится война между США и Китаем. И в этом планировании серьёзной проблемой является размещение заводов TSMC и Samsung в пределах лёгкой досягаемости китайских ракет.

Буквально несколько дней назад компания TSMC официально объявила о строительстве 5-нм завода в Аризоне. Да, сегодня это передовые технологии, но завод откроется только в 2024 году. Тем не менее это почти наверняка будет самая передовая фабрика в США, которая выполняет сторонние заказы. Надеюсь, к моменту открытия Intel превзойдёт её возможности.

Однако заметим, что интересы Intel и США не совпадают. Первая заботится о платформе x86, а США нужны передовые фабрики общего назначения на её территории. Иными словами, у Intel всегда в приоритете дизайн, а у США производство.

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

Решение 1: раздел


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

Главное, что нужно понять о микроэлектронике что маржа в дизайне гораздо выше. Например, у Nvidia валовая маржа 60-65%, в то время как у TSMC, которая производит для неё микросхемы, ближе к 50%. Как я уже отмечал выше, маржа Intel традиционно ближе к Nvidia благодаря интеграции дизайна и производства, поэтому собственные чипы всегда будут приоритетом для её производственного подразделения. От этого пострадает обслуживание потенциальных клиентов и гибкость в выполнении сторонних заказов, а также эффективность привлечения лучших поставщиков (что ещё больше снизит маржу). Здесь ещё и вопрос доверия: готовы ли конкуренты делиться своими разработками, особенно если Intel уделяет приоритетное внимание собственному дизайну?

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

Решение 2: субсидии


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

Вот почему федеральная программа субсидирования должна действовать как гарантия покупки. Государство закупает определённое количество произведённых в США 5-нм процессоров по такой-то цене; определённое количество произведённых в США 3-нм процессоров по такой-то цене; определённое количество 2-нм процессоров и так далее. Это не только установит цели для производства Intel, но и подтолкнёт другие компании зайти на этот рынок. Возможно, вернутся в игру глобальные производственные компании или TSMC построит больше фабрик в США, а возможно, в нашем мире почти свободного капитала наконец появится стартап, готовый совершить революцию.

Безусловно, мы чрезмерно упрощаем проблему. В производстве электроники очень много факторов. Например, упаковка интегральных схем (сборка кристалла в корпус) давным-давно переехала за границу в погоне за снижением затрат и теперь полностью автоматизирована. Вернуть её проще. Однако крайне важно понять, что восстановление конкурентоспособности, а тем более лидерства США, займёт много лет. Определённую роль играет федеральное правительство, но и Intel должна принять реальность, что её интегрированная модель больше не работает.
Подробнее..
Категории: Linux , Iphone , Производство и разработка электроники , Процессоры , Intel , It-компании , Arm , Дата-центры , Google , Блог компании дата-центр «миран» , Miran , Миран , Дата-центр "миран" , Tsmc , Интеллектуальная собственность , Серверные процессоры , X86 , Конец windows , Производство микросхем , Субсидирование , Упаковка интегральных схем , Сборка кристалла в корпус

Как мы просто сократили объем входящего в дата-центр трафика на 70

03.02.2021 22:16:57 | Автор: admin

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

Единственное, о чем мы пожалели что не применили это решение раньше.

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

Два года назад, когда мы переходили с RedShift на ClickHouse, количество собираемых аналитических событий (приложение открылось, приложение запросило ленту контента, пользователь просмотрел контент, пользователь поставил смайл (лайк) и так далее) составляло около 5 млрд в сутки. Сегодня это число приближается к 14 млрд.

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

Но перед тем, как агрегировать, сохранить и обработать столько данных, их надо сначала принять и с этим есть свои проблемы. Часть описана в статье о переходе на ClickHouse (ссылка на неё была выше), но есть и другие.

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

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

Но ближе к лету непростого 2020 года ей нашлось применение.

Протокол HTTP, помимо сжатия ответов (о котором знают все, кто когда-либо оптимизировал скорость работы сайтов), позволяет использовать аналогичный механизм для сжатия тела POST/PUT-запросов, объявив об этом в заголовке Content-Encoding. В качестве входящего обратного прокси и балансировщика нагрузки мы используем nginx, проверенное и надёжное решение. Мы настолько были уверены, что он сумеет ко всему прочему ещё и на лету распаковать тело POST-запроса, что поначалу даже не поверили, что из коробки он этого не умеет. И нет, готовых модулей для этого тоже нет, надо было как-то решать проблему самостоятельно или использовать скрипт на Lua. Идея с Lua нам особенно не понравилась, зато это знание развязало руки в части выбора алгоритма компрессии.

Дело в том, что давно стандартизированные алгоритмы сжатия типа gzip, deflate или LZW были изобретены в 70-х годах XX века, когда каналы связи и носители были узким горлышком, и коэффициент сжатия был важнее, чем потраченное на сжатие время. Сегодня же в кармане каждого из нас лежит универсальный микрокомпьютер первой четверти XXI века, оборудованный подчас четырёх- и более ядерным процессором, способный на куда большее, а значит алгоритм можно выбрать более современный.

Выбор алгоритма

Требования к алгоритму были простыми:

  1. Высокая скорость сжатия. Мы не хотим, чтобы приложения тормозили из-за второстепенной функции.

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

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

  4. Permissive лицензия.

Сразу отбросили Brotli, предназначенный для одноразового сжатия статического контента на стороне сервера. По схожей причине решили отказаться от bzip, также ориентированного на статику и большие архивы.

В итоге остановились на алгоритме Zstandard, по следующим причинам:

  • Высокая скорость сжатия (на порядок больше, чем у zlib), заточенность на небольшие объёмы данных.

  • Хороший коэффициент сжатия при щадящем уровне потребления CPU.

  • За алгоритмом стоит Facebook, разрабатывавший его для себя.

  • Открытый исходный код, двойная лицензия GPLv2/BSD.

Когда мы увидели первым же в списке поддерживаемых языков JNI, интерфейс вызова нативного кода для JVM, доступный из Kotlin мы поняли, что это судьба. Ведь Kotlin является у нас основным языком разработки как на Android, так и бэкенде. Обёртка для Swift (наш основной язык разработки на iOS) завершила процесс выбора.

Решение на бэкенде

На стороне бэкенда задача была тривиальная: увидев заголовок Content-encoding: zstd, сервис должен получить поток, содержащий сжатое тело запроса, отправить его в декомпрессор zstd, и получить в ответ поток с распакованными данными. То есть буквально (используя JAX-RS container):

// Обёртка над Zstd JNIimport org.apache.commons.compress.compressors.zstandard.ZstdCompressorInputStream;// ...if (  containerRequestContext    .getHeaders()    .getFirst("Content-Encoding")    .equals("zstd")) {  containerRequestContext    .setEntityStream(ZstdCompressorInputStream(      containerRequestContext.getEntityStream()    ))}

Решение на iOS

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

import Foundationimport ZSTDfinal class ZSTDRequestSerializer {    private let compressionLevel: Int32    init(compressionLevel: Int32) {        self.compressionLevel = compressionLevel    }    func requestBySerializing(request: URLRequest, parameters: [String: Any]?) throws -> URLRequest? {        guard let mutableRequest = (request as NSURLRequest).mutableCopy() as? NSMutableURLRequest else {            return nil        }        // ...        mutableRequest.addValue("zstd", forHTTPHeaderField: "Content-Encoding")        if let parameters = parameters {            let jsonData = try JSONSerialization.data(withJSONObject: parameters, options: [])            let processor = ZSTDProcessor(useContext: true)            let compressedData = try processor.compressBuffer(jsonData, compressionLevel: compressionLevel)            mutableRequest.httpBody = compressedData        }        return mutableRequest as URLRequest    }}

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

Впрочем, и снижение объёма трафика было не сильно заметно. Дождавшись, пока новая версия клиента раскатится пошире, мы врубили сжатие на 100% аудитории.

Результат нас, мягко говоря, удовлетворил:

График падения трафика на iOSГрафик падения трафика на iOS

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

То есть мы на четверть сократили весь объём.

Решение на Android

Воодушевлённые, мы запилили сжатие для второй платформы.

// Тут перехватываем отправку события через interceptor и подменяем оригинальный body на сжатый если это запрос к eventsoverride fun intercept(chain: Interceptor.Chain): Response {   val originalRequest = chain.request()   return if (originalRequest.url.toString()               .endsWith("/events")) {      val compressed = originalRequest.newBuilder()            .header("Content-Encoding", "zstd")            .method(originalRequest.method, zstd(originalRequest.body))            .build()      chain.proceed(compressed)   } else {      chain.proceed(chain.request())   }}// Метод сжатия, берет requestBody и возвращает сжатыйprivate fun zstd(requestBody: RequestBody?): RequestBody {   return object : RequestBody() {      override fun contentType(): MediaType? = requestBody?.contentType()      override fun contentLength(): Long = -1 //We don't know the compressed length in advance!      override fun writeTo(sink: BufferedSink) {         val buffer = Buffer()         requestBody?.writeTo(buffer)         sink.write(Zstd.compress(buffer.readByteArray(), compressLevel))      }   }}

И тут нас ждал шок:

График падения на AndroidГрафик падения на Android

Так как доля Android среди нашей аудитории больше, чем iOS, падение составило ещё 45%. Итого, если считать от исходного уровня, мы выиграли суммарно 70% от, напомню, всего входящего трафика в ДЦ.

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

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

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

Два слова, что ещё можно улучшить

У Zstandard есть очень интересная возможность использования предобученного словаря. Если взять достаточно большой объём типичных данных и прогнать по нему сжатие, то можно получить на выходе словарь наиболее высокочастотных вхождений, который затем использовать и при сжатии, и при распаковке.

При этом коэффициент сжатия увеличивается от 10-15% на текстах до 50% на однообразных наборах строк, как у нас. А скорость сжатия даже несколько увеличивается при размере словаря порядка 16 килобайт. Это, конечно, уже не приведёт к такому впечатляющему результату, но всё равно будет приятно и полезно.

Подробнее..
Категории: Разработка мобильных приложений , Разработка под android , Разработка под ios , Аналитика мобильных приложений , Android , Backend , Аналитика , Ios , Дата-центры , Мобильная разработка , Блог компании funcorp , Трафик , Compression , Андройд , Бекенд

Рокировка в стиле ORNL на арену лаборатории выходит суперкомпьютер мощностью 1,5 экзафлопс

23.12.2020 20:04:15 | Автор: admin
Источник

На территории Национальной лаборатории Ок-Ридж (ORNL) ведутся работы по монтажу американского суперкомпьютера Frontier. Мощность новой системы составит 1,5 экзафлопс. Проект будет частично введен в работу весной 2021 года. Затем суперкомпьютер достроят уже после того, как система начнет работу. Frontier разместят в бывшем центре обработки данных суперкомпьютера Titan, который вывели из эксплуатации год назад.

Систему Frontier разрабатывают в рамках сотрудничества AMD и Cray. Впервые об этом проекте стало известно в мае 2019 года. Сейчас ORNL говорит об успешном процессе модернизации помещений бывшего Titan.


Frontier поместят в помещение E102, его площадь >1800 кв.метров. Однако для новой системе понадобились модификации:

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

Монтаж Frontier. Источник

Характеристики Frontier:

  • производительность 1,5 экзафлопс ;
  • энергопотребление 30 Мвт;
  • мощность отвода системы охлаждения 40 Мвт;
  • >100 стоек Cray Shasta;
  • масса нового фальшпола в комнате Е102 110 тонн;
  • 24-дюймовый трубопровод системы охлаждения. Через него проходит 19 тыс. литров жидкости в минуту.

Из-за пандемии в работе ORNL произошли некоторые изменения. Так, введено обязательное тестирование на коронавирус для всех сотрудников. Запуск суперкомпьютера в эксплуатацию перенесен на 2022 год.

Главная цель, которая стоит перед разработчиками Frontier, способствовать ускорению в развитии науки, технологий и искусственного интеллекта. Общая стоимость контракта на разработку системы $600 млн.

Год назад в лаборатории ORNL заявили, что Frontier в 50 раз производительнее любого современного суперкомпьютера. Предполагается, что Frontier улучшит и откроет новые возможности в машинном обучении и анализе данных для различных приложений.

Эволюция суперкомпьютеров ORNL. Источник

ORNL уже несколько лет развивает и запускает самые мощные суперкомпьютеры в мире, включая Jaguar, Titan и Summit. Их мощности используют для разных целей. Например, в мае 2020 года силы американских суперкомпьютеров направили на борьбу с коронавирусом. Они проводили важные для врачей вычисления, чтобы получить информацию о генетическом коде и молекулярной структуре вируса.

Прощание с Титаном


Источник

Полтора года назад в помещении, где сейчас монтируют Frontier, располагался суперкомпьютер Titan. Полное название системы Cray XK7 Titan. Суперкомпьютер занимал 200 серверных шкафов и имел гибридную инфраструктуру.

Его характеристики:

  • 700 Тбайт оперативной памяти;
  • 40 Пбайт дискового хранилища;
  • AMD Opteron 6274 16-ядерные процессоры ;
  • графические ускорители NVIDIA Tesla K20;
  • от 4 до 6 МВт уровень энергопотребления.

Национальная лаборатория Ок-Ридж (ORNL). Источник

На момент вывода из строя в августе 2019 года Titan занимал 12 место в списке самых мощных суперкомпьютеров мира.

Общая площадь помещений, отданных под Titan, составляла 836 кв. метров. Особых усилий потребовал демонтаж оборудования. В системах охлаждения Titan находилось 4,5 тонны хладагента R134a. На его слив ушло 3 дня.


Демонтаж проходил в три этапа:

  1. Отключение всех цепей. Блокировка контуров охлаждения в помещении.
  2. Отключение подпольной кабельной инфраструктуры.
  3. Снятие со шкафов теплообменников систем охлаждения.

Подробнее..
Категории: Высокая производительность , Процессоры , Блог компании selectel , Будущее здесь , Дата-центры , Суперкомпьютеры , Будущее , Суперкомпьютер , Высокая нагрузка

Microsoft затопит в море новый дата-центр семейства Natick

14.07.2020 20:14:29 | Автор: admin


Первый прототип подводного дата-центра компания Microsoft разработала и погрузила под воду еще в 2015 году. Его нарекли Leona Philpot, а сам проект получил название Natick.

Первая модель подводного центра была небольшой, все необходимое оборудование поместили в контейнер габаритами 3*2 метра. Управление дистанционное, поскольку людей внутри по понятным причинам не было. Прототип проработал без проблем в течение 105 дней. Компания Microsoft признала эксперимент успешным. Энергоэффективность ДЦ очень высокая. Шутка ли, показатель PUE составил всего 1,07. После того, как дата-центр разобрали и проанализировали его состояние, проект решили продолжать.


Участники проекта называют каждый новый прототип Natick N, где N его порядковое число.


Источник: Microsoft

Соответственно, первый дата-центр, описанный выше, назвали Natick 1. Его погрузили под воду на глубину 10 метров неподалеку от тихоокеанского побережья США.


Источник: Microsoft

Natick 2 разработали и погрузили в воду в 2018 году. Цель прототипа была иной, чем у предшественника. Первый Natick должен был доказать, что дата-центры могут работать под водой с максимальной энергоэффективностью. В 2018 году Microsoft решила показать, что подводный дата-центр, выполняющий реальные задачи, можно развернуть всего за три месяца с момента подписания проекта.


Утопить второй прототип решили на северо-востоке Шотландии, около Оркнейских островов. Место выбрали, чтобы, во-первых, погрузить ДЦ в холодные воды, а во-вторых использовать электричество, вырабатываемое местной приливной электростанцией.

Характеристики Natick:

  • Энергопотребление на уровне 240 кВт.
  • Потребление исключительно зеленой энергии.
  • Длина 12,2 м, диаметр 2,8 м.
  • Количество стоек 12, с 864 серверами.
  • Постоянная температура внутри без особых колебаний.

Дата-центры проекта Natick рассматриваются в качестве вспомогательных объектов, так что полноразмерный ДЦ и не нужен. Несомненным плюсом является продолжительность работы без сбоев и физического обслуживания расчетный показатель составляет 5 лет.

Natick 3 полноценный подводный ДЦ, который включает 12 контейнеров с характеристиками Natick 2. Новый дата-центр представляет собой стальную раму, которая погружается на глубину в 200 метров (для сохранения постоянной температуры внутри контейнеров). На раме закрепляются контейнеры и необходимая инфраструктура.

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


Источник

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

Кстати, на Natick 2 установлены подводные камеры. По задумке с помощью них можно посмотреть, что происходит под водой, снаружи ДЦ. Иногда камеры залепляет местная флора, поэтому не всегда по ссылке вы увидите морские глубины.
Подробнее..
Категории: Сетевые технологии , Microsoft , Сетевое оборудование , Компьютерное железо , Блог компании selectel , Будущее здесь , Дата-центры , Natick

Huawei CloudFabric 2.0 какими должны быть сетевые решения для ЦОДов в умном цифровом банкинге

24.07.2020 16:16:55 | Автор: admin
На прошедшей в онлайн-режиме Huawei FSI Week 2020 технический директор линейки продуктов Huawei для передачи данных Дэниел Тан (Daniel Tang) доступным языком рассказал про новейшие достижения компании по части сетевых решений для дата-центров, которые обеспечивают превращение ЦОДа из просто облачного в по-настоящему интеллектуальный. А заодно сделал короткий экскурс в предысторию этого превращения.



Что изменилось в банкинге для потребителя


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

К 2020 году эта процедура упростилась разительно. Недавно я провёл маленький эксперимент попробовал получить кредит с помощью мобильного приложения своего банка. Несколько тапов по экрану смартфона и система обещает дать мне ответ самое позднее через четверть часа. Но уже меньше чем через пять минут мне падает push-уведомление с указанием того, на заём какого размера я вправе рассчитывать. Согласитесь, впечатляющий прогресс в сравнении с ситуацией пятилетней давности. Любопытно, на что требовались целые дни и недели в недавнем прошлом.



Так вот, раньше большая часть времени уходила на проверку данных и скоринг вручную. Все сведения из анкет и прочих бумаг нужно было внести в IT-систему банка. Но это было лишь началом мытарств: сотрудники банка лично проверяли вашу кредитную историю, после чего принимали итоговое решение. Покидали офис они в 17:00 или 18:00, на выходных отдыхали, и процесс, как следствие, мог затянуться надолго.

В наши дни всё иначе. Человеческий фактор во многих задачах цифрового банкинга вообще вынесен за скобки. Оценка, включая антифрод- и AML-проверки, выполняется автоматически, с применением умных алгоритмов. Машинам отдых ни к чему, поэтому функционируют они без выходных и круглосуточно. Кроме того, изрядный объём сведений, необходимых для принятия решений, уже хранится в банковских базах данных. А значит, вынесение вердикта осуществляется за гораздо более короткий период, чем в айтишной древности.

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



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

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

Каким должен быть умный ЦОД





Мы в Huawei выделили три главных вызова для дата-центров в эпоху интеллектуальных ЦОДов.

Во-первых, для работы с неиссякающими потоками новых данных необходима экстраординарная пропускная способность. По нашим наблюдениям, за последние пять лет объём хранимых в дата-центрах данных вырос вдесятеро. Но что ещё больше впечатляет, так это какой трафик генерируется при обращении к таким данным. В дата-центрах регистрационного типа вся эта информация использовалась для решения задач учётного характера и нередко лежала мёртвым грузом, а в ЦОДах нового типа она работает нам необходимо обеспечивать постоянный data mining. Как следствие, при доступе к единице хранимых данных производится в 101000 раз больше итераций, чем прежде. Скажем, при обучении ИИ-моделей практически нон-стоп фоново выполняются вычислительные задачи с постоянным функционированием алгоритмов нейросети, ради того чтобы повысить интеллектуальность системы. Таким образом, растут не только объёмы хранимых данных, но и трафик, который формируется при обращении к ним. Так что вовсе не по прихоти телеком-вендоров на новых моделях цодовских серверах всё больше сто- и двухсотгигабитных портов.

Во-вторых, отсутствие потерь пакетов данных в 2020 году абсолютный the must. Во всяком случае, с нашей точки зрения. Раньше такие потери не были головной болью для инженеров банковских ЦОДов. Узкими местами были вычислительная мощность и эффективность хранения данных. Но средние по индустрии значения и того и другого показателя за минувшие пять лет в мировом масштабе существенно повысились. Закономерно, что бутылочным горлышком в работе дата-центров оказалась эффективность сетевой инфраструктуры. При работе с одним из наших ведущих клиентов мы установили, что каждый процент, добавляющийся к показателю потери пакетов данных, грозит снизить эффективность обучения ИИ-моделей вдвое. Отсюда огромное влияние на продуктивность и результативность использования вычислительных ресурсов и систем хранения данных. Вот что необходимо преодолеть, чтобы поддержать превращение простого дата-центра в дата-центр интеллектуальной эпохи.

В-третьих, важно предоставлять сервис бесшовно и беспрерывно. Современный цифровой банкинг приучил, и приучил совершенно правильно, людей к тому, что услуги финансовых организаций могут, вернее, даже должны быть доступны 24/7. Обычная ситуация: замотавшийся предприниматель со сбитым распорядком дня, остро нуждающийся в дополнительных средствах, просыпается ближе к полночи и хочет выяснить, на какую кредитную линию ему рассчитывать. Пути назад отрезаны: у банка больше нет возможности планово приостановить работу ДЦ, чтобы что-то починить или провести апгрейд.

Наше решение CloudFabric 2.0 как раз и предназначено для того, чтобы справляться с перечисленными вызовами. Оно поддерживает высочайшую пропускную способность, интеллектуальное управление сетями ЦОД и безукоризненное функционирование сетей с автономным управлением (англ. autonomous driving networks ADN).

Что есть в CloudFabric 2.0 для умных ЦОДов





Что касается высокой пропускной способности, мы закладываемся не только на масштабирование своих сетевых решений, но и на гибкость в работе с ними. Например, цодовские коммутаторы Huawei линейки CloudEngine стали первыми в индустрии устройствами такого класса со встроенным процессором для нейросетевых вычислений в режиме реального времени, помогающим в том числе решать проблемы внутри сетевой инфраструктуры и не допускать потери пакетов данных (это достигается применением алгоритма iLossless, в том числе для сценария iNOF RoCE). Но, разумеется, имеет значение и собственно пропускная способность. В том числе важна поддержка интерфейсов 400 Гбит/с, равно как и обратная совместимость с распространёнными на текущий момент десяти-, сорока- и стогигабитными подключениями.

Опорным узлам инфраструктуры должна быть под силу и работа с высокой плотностью подключений (так называемые high-density-сценарии), при возможности значительного масштабирования решения. В нашей флагманской цодовской модели CloudEngine 16800 реализована поддержка до 48 портов по 400 Гбит/с на слот втрое больше, чем у ближайшего к ней аналога от наших конкурентов.

Что касается системы в целом, возможности по расширению пропускной способности в расчёте на шасси (per chassis scalability) тоже впечатляющие 768 портов по 400 Гбит/с на одно шасси, или вшестеро больше, чем позволяют решения других игроков рынка. Это даёт нам основания называть CloudEngine 16800 самым производительным коммутатором для ЦОДа в эпоху победившего ИИ.



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

Первый обучение ИИ-моделей. Оно требуется постоянного обращения к данным и вычислений по огромным матрицам или тяжеловесных операций с TensorFlow. Наш iLossless способен увеличивать производительность обучения ИИ-моделей на 27% процентов доказано на реальных кейсах и подтверждено тестом лаборатории The Tolly Group. Второй сценарий повышение эффективности систем хранения данных. Её, в свою очередь, применение наших разработок способно поднять приблизительно на 30%.

Помимо всего прочего, вместе со своими заказчиками мы стремимся опробовать новые возможности, которые открывают наши разработки. Уверены, посредством улучшения завязанной на Ethernet коммутационной фабрики (switching fabric) для дата-центра нам под силу преобразовать высокопроизводительную цодовскую фабрику с сетью хранения данных в единую, целостную основанную на Ethernet инфраструктуру. Так, чтобы не только поднять производительность процессов обучения ИИ-моделей и улучшить доступ к программно-определяемым хранилищам данных, но и ощутимо оптимизировать совокупную стоимость владения дата-центром путём взаимной интеграции и объединения вертикальных, независимых на физическом уровней сетей.



Многим нашим клиентам нравится обкатывать эти новые возможности. И один из таких клиентов сама Huawei. В частности, входящая в состав нашей группы компаний Huawei Cloud. Тесно сотрудничая с нашими коллегами из этого подразделения, мы удостоверились в том, что, гарантировав им отсутствие потерь пакетов данных, дали импульс к заметному улучшению их бизнес-процессов. Наконец, среди своих внутренних достижений отметим тот факт, что в Atlas 900, самом крупном ИИ-кластере в мире, мы в состоянии обеспечивать вычислительную мощность, задействуемую под обучение искусственного интеллекта, на отметке выше 1 тыс. петафлопс высочайший показатель в компьютерной индустрии на сегодняшний день.

Другой остроактуальный сценарий облачное хранение данных с использованием All-Flash-систем. По меркам отрасли это очень трендовый сервис. При наращивании вычислительных ресурсов и расширении хранилищ естественным образом требуются и передовые технологии из сферы цодовских сетевых решений. Так что мы продолжаем работать с Huawei Cloud и воплощаем всё новые и новые прикладные сценарии с применением своих сетевых решений.

Что умеют сегодня ADN-сети





Обратимся к сетям с автономным управлением (ADN). Спору нет, программно-определяемые сети (software-defined networks) с точки зрения технологий уверенный шаг вперёд в управлении сетевой составляющей дата-центра. Прикладное воплощение концепции SDN значительно ускоряет инициализацию и конфигурирование сетевого слоя ЦОДа. Но, конечно, предоставляемых ею возможностей недостаточно для того, чтобы полностью автоматизировать O&M дата-центра. Чтобы пойти дальше, нужно справиться с тремя первоочередными вызовами.

Во-первых, в сетевой инфраструктуре дата-центров всё больше возможностей, связанных с предоставлением сервисов и настройками их функционирования, в финансовом секторе особенно. Важно иметь возможность автоматически переводить запрос сервисного уровня (service-level intent) на сетевой уровень.

Во-вторых, дело упирается и в верификацию таких инкрементальных команд (incremental provisioning commands). Понятное дело, в сетях ЦОДов многое сконфигурировано давным-давно, на базе крепко укоренившихся или даже устаревших подходов. Как убедиться в том, что дополнительная настройка не нарушит отлаженных процедур? Без автоматической верификации новых дополнительных настроек не обойтись. Именно автоматической, поскольку совокупность существующих настроек в ЦОДе обычно непомерно велика. Вручную с ней практически не совладать.

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

Сети класса ADN могут помочь нам ответить на эти вызовы, которые сопряжены с переходом к подлинно умным дата-центрам. И идеология сетей с автономным управлением (она перекочевала в мир дата-центров из соседней индустрии на стыке IoT и V2X, в частности) позволяет пересмотреть подходы к автоматизации на разных уровнях сети ЦОДа.



На текущий момент в автономности управлении сетей для дата-центров мы достигли уровня L3 (conditional automation). Это означает высокую степень автоматизации ЦОДа, при которой вмешательство человека требуется точечно и лишь при определённых условиях.

Между тем в ряде сценариев возможна и полная автоматизация. С нашими клиентами мы уже работаем в рамках совместной программы по реализации инноваций для всесторонней автоматизации сетей ЦОДов в соответствии с концепцией ADN, прежде всего в разрезе устранения проблем в сети, и применительно к самым злободневным и трудоёмким из них добились успехов: так, с помощью наших интеллектуальных технологий автоматически удаётся закрыть около 85% наиболее часто развивающихся сценариев сбоев в сетях дата-центров.

Эта функциональность реализуется в рамках нашей концепции O&M 1-3-5: минута на установление того факта, что сбой произошёл, или на обнаружение риска сбоя, три минуты на то, чтобы определить его первопричину, и пять минут на то, чтобы предложить, как его ликвидировать. Само собой, пока для принятия окончательных решений необходимо человеческое участие в частности, выбрать одно из возможных решений и отдать команду на его исполнение. Кто-то должен брать на себя ответственность за выбор. Однако, отталкиваясь от практики, мы полагаем, что система и в нынешнем её исполнении предлагает весьма квалифицированные и уместные решения.

Вот вкратце наиболее сложные вызовы, которые стоят перед архитекторами умных ЦОДов в 2020 году, и мы с ними уже фактически справились. Например, функциональность для перевода запросов с сервисного уровня на сетевой и для автоматической верификации настроек уже входит в CloudFabric 2.0.



Нам приятно, что наши достижения были оценены и в этом году мы получили награду Выбор клиентов в рамках рейтинга Gartner Peer Insights, а также F&S Global Data Center Switch Technology Leadership Award за коммутатор CloudEngine 16800, который был отмечен за выдающуюся пропускную способность, высочайшую плотность 400-гигабитных интерфейсов и общую масштабируемость системы, а также за интеллектуальные технологии, позволяющие, в частности, свести к нулю уровень потери пакетов данных.
Подробнее..
Категории: Сетевые технологии , Сетевое оборудование , Дата-центры , Блог компании huawei , Huawei , Huawei enterprise , Cloud fabric , Cloudengine , Cloudengine 16800 , Цоды , Cloud fabric 2.0 , Adn , Ilossless

Самые известные за последние годы аварии в дата-центрах разных компаний и их причины

09.06.2021 18:07:37 | Автор: admin


Дата-центры становятся всё более важными объектами, ведь от их нормальной работы зависит как нормальный ход работы многих крупных и мелких компаний, так и сохранность данных обычных пользователей. Всего минута простоя крупного дата-центра может стать причиной миллионных убытков для клиентов оператора ЦОДа. Ну, а многочасовые или тем более многодневные простои приводят к убыткам, которые вообще иногда невозможно оценить. Под катом наиболее известные аварии последнего времени с описанием причин их возникновения.

Пожар в дата-центре OVH




В марте 2021 года почти полностью сгорел один из дата-центров OVH. Это самая крупная авария последних лет, ведь OVH один из крупнейших хостинг-провайдеров Европы. Пожар был настолько сильным, что практически уничтожил дата-центр SBG2. Основной подозреваемый одна из систем бесперебойного питания, с внутренним порядковым номером UPS7. Накануне пожара эта система проходила техническое обслуживание, в ходе которого в ней поменяли большое количество компонентов. По завершении процедуры UPS7 запустили вновь, и работа ее вроде как была штатной. Но вскоре случился пожар.

К слову, пожары в дата-центрах, тем более такого масштаба, происходят крайне редко. Учет подобных случаев ведёт Uptime Institute по словам его представителей, в среднем пожары случаются реже раза в год. В большинстве случаев инциденты удалось прервать в самом начале развития, но в некоторых случаях огонь всё же выходил из-под контроля.

В случае OVH с перебоями в работе, вызванными последствиями пожара в SBG2, столкнулись около 3,6 млн веб-сайтов.

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

  • Конструкция дата-центра. Он башенного типа (Tower design). Здесь используется схема конвекционного охлаждения, когда нагретый воздух поднимается по башне в самом центре здания. В целом такая конструкция считается надежной и экологичной, но последние данные о распространении пожара говорят о том, что огонь, попав в конвекционную систему, быстро разошёлся по зданию.
  • Возможное отсутствие в дата-центре, где произошло возгорание, системы сверхраннего обнаружения пожара. Более того, есть информация, что там не было ни систем газового, ни систем водяного пожаротушения. Вместо этого использовались датчики дыма и огнетушители.

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

Пожар в дата-центре WebNX




В апреле 2021 года произошел пожар в дата-центре Ogden американской компании WebNX. Загорелся генератор, после чего пожар распространился на прилегающие помещения. В результате произошло полное отключение энергоснабжения, пострадало серверное оборудование. Некоторые серверы, сильнее всего поврежденные огнем, вряд ли удастся восстановить.

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

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

В этом дата-центре размещались и серверы компании Gorilla Servers. Правда, оборудование этой организации не пострадало, но в результате отключения энергии прекратили работу сервисы и сайты клиентов. Дата-центр оказался обесточенным на несколько часов, восстановление работы всех систем потребовало около 20 часов. Убытки оператора дата-центра в этом случае превысили $25 млн.

Сбой в работе дата-центра банка TSB


В сентябре 2018 года британский банк TSB решил провести обширную миграцию IT-оборудования, не проведя перед этим тестирование нового дата-центра. Самое обидное для компании то, что поставщик IT-услуг Sabis, которого наняли для проведения миграции, протестировал все дата-центры, затронутые в ходе миграции, кроме одного. При этом факт того, что тестирование не проведено, был скрыт от руководства.

Итог плачевен: два миллиона клиентов банка одномоментно лишились доступа к счетам. Банку пришлось потратить около $480 млн на устранение последствий сбоя в работе ЦОД, включая сборы за расследование инцидента в размере примерно $35 млн.

Пожар в лондонском дата-центре Telstra


В августе 2020 года пострадал дата-центр Telstra, крупнейшей телекоммуникационной компании Австралии. Как и в случае с OVH, проблема возникла из-за неисправного ИБП. Несмотря на то, что огонь удалось локализовать, в отличие от OVH, инцидент затронул большую часть площади дата-центра, а это 11 000 квадратных метров. Внутри помещений, где возникло возгорание, находилось около 1800 серверных стоек.

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

Тем не менее, несколько десятков серверов оказались в офлайне, их работу удалось восстановить лишь через несколько часов. Соответственно, не работали сервисы и сайты клиентов Telstra. Общие убытки компании превысили $10 млн, не говоря уже о репутационных потерях.

Поломка ИБП в дата-центре Equinix LD8


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

Авария случилась в ЦОД на территории лондонского района Доклендс, причем сотрудники поддержки смогли понять причину проблему почти сразу после ее появления. Как оказалось, отключившийся ИБП обесточил главный кластер маршрутизаторов Juniper MX и Cisco LNS. Именно этот кластер обеспечивал работу большей части оборудования дата-центра.

После того, как кластер обесточился, отключились сервисы крупнейших компаний клиентов Equinix. В их число входят международные телекоммуникационные компании Epsilon, SiPalto, EX Networks, Fast2Host, ICUK.net и Evoke Telecom. Повлияла авария и на работу других дата-центров.

В качестве вывода скажу, что это далеко не все аварии, которые случились за последние несколько лет. Но, вероятно, эти инциденты можно назвать наиболее показательными, поскольку их можно было предотвратить. Непрофессионализм сотрудников, проблемы с ИБП, отключение питания достаточно распространенные проблемы. А с какими сложными инцидентами в дата-центрах сталкивались вы? Если есть что рассказать давайте обсудим в комментариях.

Бонус: отключение энергии из-за технических работ


Есть и ситуации, которые достаточно сложно (хотя и можно) предусмотреть. Например, в The Register как-то пересказали историю, присланную в редакцию одним из читателей. Жила-была серверная ферма с тремя ИБП на 220 кВА, работала себе вполне нормально довольно долго. С течением времени потребность в одном из ИБП отпала, и его решили переместить в недавно открытый новый ЦОД. Руководство планировало сэкономить на покупке нового ИБП но вышло иначе.

Стоит отметить, что ЦОД, о котором идёт речь, немаленький, его площадь составляла около 2500 квадратных метров. Оборудования было много, несколько сотен серверов, так что допустить какие-то либо проблемы было смерти подобно.

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

Я сидел за рабочим столом, когда электрики начали отключение блока ИБП от сети. Они перевели систему в режим байпаса без проблем. Затем они обрезали автомат защиты на выходе и еще несколько проводов для ускорения демонтажа. И тут дата-центр площадью 2500 квадратных метров вдруг затих. Я побежал в машзал, ожидая обнаружить пораженных током электриков. Но они просто спокойно отсоединяли провода. Я закричал, что ЦОД ушел в офлайн, на что электрики ответили, что оборудование запитывается в режиме байпаса. Я повторил. Они остановились, подумали секунд десять, а затем их глаза открылись по-настоящему широко, рассказал очевидец.

Восстанавливать работоспособность дата-центра пришлось 36 часов, хотя изначально электрики заявили о часовом простое.
Подробнее..
Категории: Сетевое оборудование , Дата-центры , Исследования и прогнозы в it , Аварии , Пожары , Инциденты

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru