Цод

Наш первый ЦОД в советском бомбоубежище особенности вычислений в бункере

10.11.2020 14:15:42 |

Автор: admin

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

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

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

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

Что это за бомбоубежище?

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

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

На фото наш первый модуль, где сейчас сконцентрированы серверы для предоставления VDS-услуг. Ещё есть выделенные серверы с аттестацией ФСТЭК и немного другого оборудования в других модулях убежища, но в целом они отличаются разве что размером.

Что нужно было сделать

В 2009 году мы получили помещение в долговременную аренду (это тоже очень важно для ЦОДа!). Все помещения были сухими: если была бы хоть капля влаги, то брать это место мы категорически не стали бы. Закачали раствор в стены, сделали дополнительную гидроизоляцию сверху в общем, довольно сильно провозились, но получили базовые гарантии, что стены герметичны. Сейчас мы поддерживаем стабильную влажность на уровне от 40 до 50 %, и скачков почти нет.

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

После поворота спуск к комнате для сборки оборудования к рабочему месту дежурного и админов заказчика:

Сама комната выглядит так:

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

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

Для входа внешних трасс очень подходила старая шахта лифта (лифт не ходил ещё со времён СССР). Когда-то он использовался для загрузки оборудования, но с первого взгляда стало понятно, что это будет шахта для коммуникаций, а не что-то для заноса серверов внутрь.

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

Пришлось сделать дополнительные отверстия в стенах и продолжить использовать шахту лифта.

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

Первый дизель прямо на входе:

Ещё два дизеля в контейнерах снаружи:

Есть топливо (часто ЦОДы нашего размера не хранят собственное, а надеются на подвоз):

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

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

Под фальшполом тоже:

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

Оптика

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

Разумеется, имеющиеся коммуникации мы никак не использовали. А они были, конечно.

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

Серверы

Оборудование моно-Хуавей, я уже писал, почему так.

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

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

Серверы Хуавея очень удобны для администрирования на месте: они показывают коды ошибок прямо на панелях. Вот этот работает хорошо:

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

Питание в каждую стойку приходит независимо с двух векторов.

Админская в шаге от машзала, можно сразу же попасть к стойкам. На фото дежурный админ Костя, про него есть вот здесь:

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

Ещё у нас там остатки фермы из одного из подземных модулей:

Куча кабелей:

Продолжение трасс:

И нечто особенное. Вот оно:

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

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

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

Администрирование серверов при пропадании доступа можно делать вот с такой консоли:

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

Итого

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

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

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

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

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

Подробнее..

Категории: Блог компании ruvds.com , It-инфраструктура , Инженерные системы , Цод , Управление проектами , Хостинг , Инфраструктура , Дата-центр

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

08.12.2020 14:22:23 |

Автор: admin

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

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

Это, пожалуй, главное.

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

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

Мониторинг

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

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

Мониторинг инфраструктуры делается где-то Заббиксом, но по большей части данные сводятся в нашу кастомную самописную систему. Мониторинг физических нод выполняется из учёта интересов бизнеса. Например, нам постоянно нужно знать количество свободных IP-адресов. Если они кончаются, нужно успеть заказать новые, чтобы клиент не жал кнопку впустую в интерфейсе. Есть служба, которая следит за свободными ресурсами серверов: одно применение нужно для того, чтобы мы не объявляли акцию там, где ресурсов не очень много иначе клиенты не смогут завести VPS в этом ЦОДе. Другое приложение квотирование в конфигураторе сайта ресурсов для создания новой машины или сайзинг, имеющейся в конкретном дата-центре. Если осталось 10 Гб диска, то интерфейс в данном ЦОДе не позволит создать машину на 20 Гб. Личный кабинет на сайте напрямую связан с мониторингом и при каждом создании сервера получает актуальные данные. По факту это означает отсутствие множества тикетов в поддержку на ручное создание машин и разруливание таких случаев.

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

Пример работы конфигуратора, когда в датацентре нет возможности создать сервер максимальной конфигурации 16 GB RAM, 600 GB; для серверов с 9-16 GB доступно лишь 20 GB диска, для серверов с 4-8 GB доступно 430 GB, диск 600 GB доступен для серверов с 1-3 GB памяти

Полное отсутствие серверов, доступных для создания

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

Отчёт о количестве обработанных тикетов

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

Отчёт о количестве прочтенных тикетов: здесь не только поддержка, но и команды маркетинга

Боты шлют SMS, уведомления в почту и в Слаку. Первым корпоративным мессенджером у нас был Скайп ещё где-то в районе 2012 года (это тоже традиция из мира финансов), но он так тормозил, что мы перешли на Слак ( с Ромеро он рассказал мне про удобство Слака, и мы решили попробовать) не в последнюю очередь благодаря его крутым API. Например, маркетинг получает уведомления об упоминании нас в СМИ, о выходе постов на Хабре на интересующие нас темы и так далее.

Бот, который сообщает о дежурных админах и сотрудниках поддержки

Бот, присылающий статистику из дата-центра

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

Бизнес-модель с минимальными издержками

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

Мы решили, что у нас будет ровно два типа железа и одинаковые цены по всему миру.

Это сразу означает очень простые интерфейсы, где человек не путается. Это означает упрощение автоматизации со стороны хостинга. Это гораздо более простая поддержка на уровне железа. Если бы было четыре типа железа, то пришлось бы вдвое увеличить те же ЗИПы на площадках, что сказалось бы на тарифах (да, у нас есть next business day-гарантия от Хуавея, но мы держим свой ЗИП, чтобы реагировать сразу).

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

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

Когда мы только заходили на рынок, то немного демпинговали, то есть были в сегменте самый дешёвый VDS-хостинг. Финансово-разумно находиться чуть выше: это позволяет не срезать качество там, где это аукается на клиенте. Дальше было важно выстроить продукт так, чтобы туда входило только необходимое, это предоставлялось с достаточным качеством и не создавало издержек. Хотите извращений есть дорогие хостинги. Хотите на 5 % дешевле есть менее надёжные хостинги с поддержкой, возможно, чуть хуже. Цены мы поднимали за всё это время ровно два раза: на 5 и на 10 % в кризисы, когда рубль открывал нам новые горизонты падений. И не посреди года, а в конце года. То есть за время работы хостинга мы индексировали цены даже медленнее инфляции. Так вот, при первом поднятии цен мы обнаружили, что аудитория самого дешёвого хостинга сильно отличается от аудитории нормального фастфуда на рынке хостингов. Буквально за несколько месяцев поддержка отметила, как качественно поменялась аудитория: тогда пришло много опытных админов, которые точно знали, что хотели.

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

Открытие нового ЦОДа

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

Выбираем интересующий регион, в нём весь список доступных ЦОДов, смотрим на требования по физическому доступу, близости к узлам обмена магистральным трафиком и так далее.
Смотрим, есть ли там два наших провайдера. Сначала у нас были разные провайдеры, но оказалось, что гораздо выгоднее договариваться с одним основным и одним резервным. На наших объёмах один ЦОД не высасывает полосу, поэтому нужно шерить её между разными точками. Плюс для этого одного провайдера мы крупный клиент, и он делает так, как мы любим. Поэтому в итоге если раньше мы плясали от ЦОДа и разговаривали с ним, то теперь переговоры с площадкой ведёт фактически провайдер. Мы общаемся удалённо, самая главная часть ЦОД заполняет бриф на стабильность бизнеса. Это экономит море времени на переговорах: мы берём параметры и просто загоняем в оценку бизнес-модели.
Проверяем качество работы поддержки. Это одна из тех вещей, которые надо делать вручную: нам очень важно, чтобы в субботу в 18:15 нам не сказали: Ну давайте в понедельник решим. Это нормальная картина для ряда даже дорогих ЦОДов Европы.
Проверяем возможность арендовать гермозону и расширяться по мере роста бизнеса. От пары отличных вариантов пришлось отказаться, поскольку не было возможности воткнуть через некоторое время дополнительные серверы (по нашей оценке).
Проверяем стабильность бизнеса ЦОДа. Мы хотим вставать надолго, и переезды нам не нужны, как и изменение условий из-за смены владельца. Наш второй ЦОД в Швейцарии был ошибкой: он был прекрасен всем, в него даже подземная река заходила для охлаждения. Но мы не учли, что цены были слишком низкими для такой сказки. Он был слишком хорош. В итоге инвесторы решили, что он генерирует слишком мало денег и преобразовали его в майнинг-ферму. Река холодной воды тут очень пригодилась. С тех пор мы используем свой опыт оценки бизнеса для оценки того, сколько проживёт ЦОД. Началось это со вторых грабель на самом деле: сначала мы уезжали из внезапно закрывающегося Каравана в России. . Но двух ударов нам обычно хватает, чтобы больше так не делать.
Заказываем железо у своего проверенного поставщика в Амстердаме или у другого проверенного поставщика для другой географии. Оказалось, что возить железо из Голландии по Европе выгоднее, чем заключать десять контрактов на местах. Такой же принцип: у нас большой объём, который даёт не только скидку, но и особое отношение.

Швейцария как второй ЦОД была на самом деле риск-манёвром. Когда мы его открывали, расположение было очень важным для ряда наших заказчиков. Для многих Швейцария означало надёжность сейфа. Нам было очень тяжело объяснить некоторым из них, что мы везём железо в другое место. Но мы не могли поступить так, поскольку было крайне важно уйти от модели одного ЦОДа (тогда у нас было только бомбоубежище в Королёве) даже в таком надёжном месте нельзя складывать все яйца в одну корзину. Мы видели, как пожар перенёс пару ЦОДов в облако. Вместе с бизнесом владельцев. С тех пор у нас застраховано ВСЁ железо от пожаров, наводнений и цунами.

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

Сейчас вот рассматриваем ещё один нестандартный ЦОД. Можно развернуть площадку в Останкино, где стоят телевизионщики. У них самый высокий аптайм 100 % без перерывов с 1991 года. Кстати, есть примета, что если про такое написать на Хабре, что-то сразу упадёт. Посмотрим)

Ещё одно место, где мы ушли от переговоров это работа с клиентами-юрлицами.

Работа с юрлицами

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

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

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

Пока всё

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

Подробнее..

Категории: Блог компании ruvds.com , It-инфраструктура , Цод , Управление проектами , Автоматизация , Серверное администрирование , Мониторинг , Дата-центр , Vps , Ruvds_статьи , Управление

Выше облаков а не построить ли сервер в космосе?

12.04.2021 20:16:10 |

Автор: admin

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

Для начала, зачем вообще запускать дата-центры в космос? С одной стороны, это совсем не рентабельно, ведь даже запуск обыкновенной стойки в 700 кг обойдется в несколько миллионов долларов. С другой в космосе имеется безграничный источник энергии солнечный свет, а в тени можно сбрасывать тепло излучением. Впрочем, холод космоса не сравнится с Сибирью или Антарктидой где есть холодный ветер и вода, а солнечным батареям остается только мечтать об эффективности угольной ТЭЦ. Поэтому даже проекты глобального спутникового интернета Starlink и OneWeb обходятся без космических центров обработки данных, и спутники выступают только ретрансляторами.

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

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

Компания Cloud Constellation разрабатывает программу Space Belt размещение низкоорбитальных спутников для хранения, обработки данных и передачи через ретрансляторы на высокой геостационарной орбите. Компания привлекла более $100 млн инвестиций и уже заказала у Virgin Orbit запуск 12 спутников в этом году.

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

Фактически сегодня единственным космическим дата-центром может считаться только Международная космическая станция. Она практически постоянно связана с Землёй через геостационарные спутники NASA TDRS и "Роскосмоса" "Луч".

Несколько лет назад NASA использовало МКС для испытания протокола космической связи DTN, устойчивой к сбоям и задержкам связи.

Структура сети DTN Международной космической станции и его наземного сегмента. Илл.: NASA

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

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

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

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

Карта распределения освещенности и тени в течение полных лунных суток у лунных полюсов. Илл. NASA

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

Кто "мы"? С одной стороны это один из ведущих российских хостинг-провайдеров VPS/VDS серверов, основное направление деятельности которого является оказание услуг IAAS корпоративного класса.

С другой российская частная компания, основанная группой инженеров, ранее работавших в НПО им. С.А. Лавочкина, а позже в компании "Даурия Аэроспейс", и участниками проекта лунного микроспутника. При участии блогера

Суть эксперимента запуск наноспутника класса CubeSat (10х10х30 см), на борту которого будет развернут маленький центр обработки данных. Связь с ним будет поддерживаться по радиоканалу, длительностью около 7 минут в сутки со скоростью 9,6 Кбит/с. Эксперимент планируется проводить три месяца, и, при необходимости он будет продлён, для получения большей информации.

Спутник класса CubeSat размерностью 3U. Фото: Спутникс

Если запуск получится в короткие сроки, а у конкурентов из Cloud Constellation возникнут задержки, то у нас будет шанс развернуть первый беспилотный спутниковый сервер в мире. Запуск предполагается попутный, на одной из ракет "Роскосмоса".

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

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

Поехали!

Подробнее..

Категории: Блог компании ruvds.com , Diy или сделай сам , Цод , Ruvds , Сервер , Космонавтика , Будущее здесь , Дата-центр , Эксперимент , Cubesat , Orbital express

Краткий Best practice построения кластерных решений F5

14.03.2021 02:16:56 |

Автор: admin

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

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

За функцию высокой доступности в F5 BIG-IP отвечает служба Device service clustering (DSC), которая дает возможность:

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

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

зеркалирование сессий (MAC, TCP, SSL, привязку сессий по разным критериям). Сессии на активном устройстве F5 дублируются на standby системе. В случае сбоя standby система может начать обработку соединений немедленно, без прерывания.
синхронизация конфигурации (политик безопасности, политик доступа) обеспечение актуальную конфигурации на всех участниках кластера в любой время.
корректная обработка при сбое сети без перестроения (MAC и IP не изменяются) а также наличие резервных сетевых интерфейсов для корректной работы кластера, в случае сбоя сети.

Существует два сценария построения кластера F5

Active/Standby

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

Active/Active

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

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

Вывод. Для обеспечения гарантированной отказоустойчивости подкрепленной SLA F5 рекомендует построение отказоустойчивых конфигураций минимум из 2-х устройств. В основном используется 2 варианта которые имеют свои преимущества и недостатки:

Подход 1. Построение кластера в двух или трех ЦОД и распределение трафика между ними при помощи DNS. Плюсом данного варианта является малое количество устройств F5 по одному устройству в каждом ЦОД. но низкое время переключение между ЦОД которое варьируется от минут до нескольких часов в зависимости от настроек. Такое время переключение обусловлено особенностями работы протокола DNS но позволяет использовать малое количество устройств F5.

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

В зависимости от особенностей работы приложения и требований к его доступности стоит выбирать между подходом 1 или подходом 2 с учетом особенностей одного или второго варианта. В случае, когда F5 публикует и защищает приложения с требуемым уровнем SLA 99.9 (почти 9 часов простоя в год) и выше необходимо использовать эти подходы вместе. При подборе решения F5 и его внедрении также стоит учитывать режим работы active/active или active/passive. Важно отметить, что эти режимы могут быть реализованы как в одном ЦОД (разные устройства F5 для разных приложений) для максимальной утилизации устройств F5, так и между ЦОД чтобы оба ЦОД обрабатывали трафик приложений (active-active DC) или только один (Disaster DC).

Подробнее..

Категории: Информационная безопасность , It-инфраструктура , Цод , Sla , F5 networks , F5 , F5 big-ip

О том, как мы температуру в ЦОД мерили

21.04.2021 14:19:32 |

Автор: admin

Если у вас большой и серьезный ЦОД, то параметрия температурных режимов не является проблемой. Существуют проверенные решения, например, программируемые контроллеры TAC Xenta, которые работают через LonWorks. Именно так мы собираем данные в московском ЦОД Datahouse. Но непосвящённому смертному весьма непросто собрать правильные показатели из этой связки и выводить их в мониторинг в нужном виде. К тому же решение промышленное и достаточно дорогостоящее. Поэтому при строительстве новой гермозоны
в Екатеринбурге мы решили поэкспериментировать и внедрить альтернативное решение по измерению температуры в холодных и горячих коридорах.

Ничто не предвещало беды

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

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

Из первой партии завелось 15 датчиков. Так как острой потребности в остальных не было, пока работали с ними. К моменту прихода второй партии выявили, что часть уже установленных в шину датчиков имеет поведение новогодней елки: показывают некорректные данные, отдают checksum error или отваливаются по таймауту.

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

Вот так это выглядело:

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

Не ищем легких путей

Вскрыли, посмотрели: микросхемы идентичны. Значит дело в прошивке.

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

Пока разбирались с работоспособностью датчиков поняли, как без особых сложностей обнаружить кривую версию прошивки. Если кроме Modbus работают обычные текстовые команды READ, PARAM, AUTO, STOP значит прошивка хорошая. В мертвых прошивках текст не отдается.

Решили взять прошивку с этих живых 8 датчиков, купили программатор Nu-Link,
но хитрые китайцы заблокировали чтение прошивки. То есть перезалить можно, а считать - нельзя. Запросы правильных прошивок у поставщика потерпели фиаско:
Я продаван, я не разработчик.

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

За основу был взят Keil, пакет С51, позволяющий работать с 8-битными MCU.

В начале я научил читать сенсор SHT 20 (который собственно и снимает температурные данные), потом научил передавать эти данные по Modbus. В виду того, что этот MCU ни что иное как Nuvoton N76E003AT20, то вся база знаний, видимо, сосредоточена в руках наши китайских друзей.

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

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

Так стало:

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

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

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

Программа выложена на GitHub кому интересно, можно забрать и поиграться.
Стоимость датчика всего 300 , правда, нужен программатор.

Подробнее..

Категории: Diy или сделай сам , It-инфраструктура , Инженерные системы , Цод , Программирование , Программирование микроконтроллеров , Микроконтроллеры , Дата-центр , Температура , Измерения , Modbus rtu , Modbus , Датчики

Безопасность и еще раз безопасность это ЦОД Калининский

23.11.2020 16:15:20 |

Автор: admin

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

Мой интерес подогревался информацией о масштабах проекта:

общая площадь объекта 10,3 Га;
первая очередь три здания ЦОД площадью 36 756 м2;
вторая очередь размещение до 30 КЦОД или МЦОД по одному МВт;
общая проектная мощность площадки 80 МВт;
подведенная мощность дата-центра 48 МВт.

Таких дата-центров еще не строили в России, да и по европейским меркам он весьма внушительный.

Первая моя поездка проходила на личном автомобиле по платной дороге М11 Нева. Комфортная скорость 110-130 км/час. С несколькими остановками я проехал расстояние в 390 км приблизительно за 4,5 часа. Когда будет достроен северный обход Твери (по разным данным это случится в конце 2024-го), подлетное время должно сократиться еще на час.

Также до дата-центра можно добраться высокоскоростным поездом Сапсан из Санкт-Петербурга и Москвы до стации Вышний Волочек за 2 часа 12 минут и 1 час 46 минут соответственно. На станции вас встретит корпоративная машина дата-центра, если вы, конечно, заранее предупредили о своем визите. Еще около 70 км (примерно час в пути) и вы на месте.

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

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

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

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

В городе-спутнике Калининской АЭС Удомле есть несколько гостиниц, ресторанов и кафе. Так что с инфраструктурой здесь все более чем в порядке.

За административным зданием в левой части располагается первая очередь дата-центра Калининский, состоящая из трех зданий. Каждое здание это восемь модулей, рассчитанных на размещение до 200 стоек со средним тепловыделение 6 кВт и возможностью увеличения до 20 кВт. Система охлаждения проектировалась исходя из мощности 1 МВт на каждый аппаратный зал. Мы еще вернемся сюда, и я подробнее расскажу обо всех инженерных системах дата-центра.

Справа от административного здания мы видим вторую очередь это первая и в некоторой степени уникальная площадка для размещения контейнерных и модульных дата-центров. На территории площадью 2 гектара с подготовленной производственной и энергетической инфраструктурой можно разместить до 30 КЦОД и МЦОД с подключением до 1 МВт.

Часть II. Энергетическая безопасность

С противоположной стороны от центрального КПП расположена трансформаторная подстанция с прямым подключением двумя линиями по 110 кВ. Это одно из ключевых преимуществ дата-центра. Установленная мощность электроподстанции 80 МВА, все электроснабжение реализовано по схеме 2N, то есть два трансформатора по 80 МВА, 110 на 10 кВ. В каждом здании ЦОД 16 трансформаторов 10 на 0,4 кВ. Они сгруппированы в трансформаторные подстанции и секционируются по стороне 0,4 кВ.

В случае отказа одного трансформатора на 110 кВ всю нагрузку возьмет на себя второй трансформатор. Аналогичная схема и по стороне на 10 кВ. За трансформаторными подстанциями по уровню напряжения 0,4 кВ реализованы по схеме 2N динамические дизель-роторные источники бесперебойного питания производства Hitec. Всего в секции Росэнергоатома установлено семь ДДИБП мощностью по 1970 кВА каждый.

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

В каждом здании есть свое топливохранилище по два бака (объем одного бака 40 м3). При условии работы всех ДДИБП на полную мощность запаса достаточно для работы в течение суток.

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

Часть III. Климатическая безопасность

Шесть холодильных машин производства Stulz холодопроизводительностью 971,5 кВт каждая расположены на кровле здания. Резервирование организовано по аналогии с внутренними блоками по схеме N+1. Все машины с функцией фрикулинга, что существенно снижает энергопотребление в холодное время года.

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

Во всех модулях установлено по 12 прецизионных кондиционеров, четыре из которых оснащены пароувлажнителями, и реализована схема резервирования N+1. К каждому модулю подведены два кольца трубопроводов: они позволяют вывести в сервисный режим любой кондиционер, не влияя при этом на работу системы в целом. Сердцем системы охлаждения является хладоцентр. Здесь расположены все циркуляционные насосы, обеспечивающие циркуляцию 40% раствора этиленгликоля между холодильными машинами и внутренними блоками кондиционеров. Здесь же, в хладоцентре, установлены четыре бака по 5 м3 с запасом холодного теплоносителя для обеспечения работы всей системы при полной нагрузке в случае выхода из строя всех холодильных машин.

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

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

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

Часть V. Эксплуатационная безопасность

Эксплуатацию инженерных и ИТ-систем дата-центра обеспечивает круглосуточная дежурная смена Калининской АЭС, техническую поддержку клиентов и каналов связи осуществляет АО КОНСИСТ-ОС дочерняя компания концерна Росэнергоатом, имеющая сертификат ISO 9000. Энергетика, холод, ИТ все системы дата-центра находятся на круглосуточном мониторинге.

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

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

Не могу не отметить, что команда собрана из профессионалов своего дела, постоянно повышающих свою квалификацию и имеющих большинством профильных сертификатов: CCNA, CCNP, MCSE, MCSA, Juniper Certify Expert, NetApp Certified Data Administrator, ONTAP certificate, NetApp Certified Implementation Engineer, VMware Certified Professional, PMP, IPMA Level B, C, Checkpoint, АПКШ Континент, Positive Technologies, Kaspersky.

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

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

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

Часть VI. Дополнительный рубеж защиты

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

Часть VII. Заключение: вишенка на торте

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

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

Подробнее..

Категории: It-инфраструктура , Инженерные системы , Цод , Хранилища данных , Дата-центр , Росэнергоатом

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

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 года.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мониторинг

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

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

Телеком

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

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

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

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

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

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

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

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

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

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

Подробнее..

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

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

11.03.2021 12:11:09 |

Автор: admin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В самом начале мы подключили нагрузочные модули к щиту. Теперь включаем нагрузку при помощи автоматов QDL в силовых панелях ДИБП. Проводим эту операцию в ручном режиме: закатываем выключатель QDL в рабочее положение, разблокируем его ключом, взводим пружину и включаем.
Чтобы запустить двигатель ДИБП, проводим тестовый отказ сети. Нажимаем кнопки "ОТКАЗ СЕТИ" и "FORCE" на панели управления.
Двигатель в работе, обратимая электрическая машина в режиме генератора питает нагрузочные модули, городская сеть отключена.
ДИБП работает в режиме генератора.
Теперь поднимаем нагрузку до необходимых значений. Для этого используем переключатели на панелях нагрузочных модулей. На панели управления ДИБП видим, что этот параметр достиг 1764,1 кВт.
Смотрим на работу ДИБП под нагрузкой.

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

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

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

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

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

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

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

Подробнее..

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

Мониторинг в ЦОДе как мы меняли старую BMS на новую. Часть 4

20.04.2021 16:13:49 |

Автор: admin

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

Следующей задачей на пути развития системы стал вопрос ее настройки: как сделать так, чтобы работать с новой системой было удобно, а сама она была бы максимально информативной?

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

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

В этой части мы поделимся практическим опытом настройки нашей системы мониторинга работы ЦОДа.

Немного теории

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

А телеизмерение, как нетрудно догадаться, это цифровое значение какого-либо параметра, например 220 Вольт или 10 Ампер.

Состояние или значение, настроенное пользователем, при котором на экране появляется сообщение (авария), называется уставкой. Можно настроить задержку до появления сообщения, то есть авария на экране появляется только через Х секунд (при условии, если аварийная ситуация не прекратилась раньше) или на замораживание сообщения на экране в этом случае авария уже пропала, но сообщение о ней на экране сохраняется еще Х секунд.

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

Для удобства настройки однотипного оборудования переменные в разных устройствах, но с одним именем (например, OutputCurrent) имеют одинаковые настройки на всех устройствах системы. Если мы меняем уставку в одном месте она меняется везде.

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

Дополнительно в самих устройствах есть собственные заводские уставки. Например, в PDU с завода настроено распознавание аварийной ситуации на превышение тока в 32А. В случае ее срабатывания от PDU поступит оповещение о типе аварии Overload Alarm. И это совсем другая переменная, не связанная с переменной OutputCurrent, настроенной в BMS.

Пример заводских настроек уставок внутри PDU:

Итак, мы перечислили основной функционал для настройки системы мониторинга.

Как же правильно настроить это пианино? Давайте рассмотрим задачи по порядку.

Чего мы хотим добиться

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

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

Этап 1. Определение нужных и ненужных переменных у каждого устройства

Обычно к каждому устройству идет так называемая карта переменных, на основании которой инженером-наладчиком создается драйвер. Его задача указать системе мониторинга, в каком именно регистре получаемых данных находится нужная переменная. Например, в регистре 1 протокола опроса устройства находится информация о режиме работы двигателя System_on_fun, а в регистре 2 о режиме работы компрессора Compressor_1.

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

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

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

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

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

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

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

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

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

Этап 2. Минимизация ложных и неинформативных сообщений

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

В этом случае надо разделить оборудование на критическое (например, PDU) и обычное (например, щиты вентиляции ЩУВ). Для обычного оборудования можно установить задержку на сигнал обрыв связи (например, 300 секунд) тогда большинство ложных обрывов будут игнорироваться.

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

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

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

Для оптимизации количества сообщений при переходе на ДГУ следует:

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

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

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

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

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

Например, нам потребовалось наблюдение за 4-5 переходами для приемлемой настройки новой BMS. Чтобы проанализировать внеплановый процесс перехода, мы делали запись экрана системы мониторинга, так как важно наблюдать аварийные сообщения не в архиве событий, а анализировать появление аварий в динамике оперативной сводки.

Этап 3. Дополнительные советы из нашего опыта

1.На экранах дежурной смены не должно быть лишней индикации в цветах аварийных сообщений.

Пример из реальной практики. Один ЦОД заказал карту температурных потоков в серверной. Это 3D модель потоков воздуха с множеством температурных данных с датчиков. Получился вид северной с потоками воздуха где-то воздух был выделен зеленым, где-то желтым и красным (от самого холодного к самому горячему). При этом температуры воздуха везде в пределах нормы, а цвета применены только для наглядности отображения разницы температур в разных точках.

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

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

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

2. С осторожностью используйте SMS-оповещения.

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

3. Настраивайте дублирование сообщений об авариях через мессенджер.

Это можно реализовать, например, через Microsoft Teams или Telegram. Сообщения об авариях будут приходить и вам, и дежурным, при этом телефон будет издавать звуки и вибрировать (чего нет при работе с системой через браузер).

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

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

4. Группируйте сообщения в мессенджерах.

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

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

5. Ярко выделяйте в интерфейсе сообщение о пропадание связи с сервером.

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

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

6.Подключайте к мониторингу как можно больше систем.

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

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

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

Тем самым снижается риск пресловутого человеческого фактора. Пример тестового сигнала ПОЖАР в системе BMS ЦОДа, подключенного через сухие контакты.

Подведем итоги нашей 4-серийной истории

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

Пройдя довольно трудный и длинный путь, мы получили:

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

Подробнее..

Категории: It-инфраструктура , Инженерные системы , Цод , Управление проектами , Мониторинг , Дата-центр , Ит-инфраструктура , Блог компании linxdatacenter , Bms , Инженерная инфраструктура , Система мониторинга , Bms-системы , Эксплуатация

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

Аттестация сотрудников ЦОДа как и зачем ее проводят в Linxdatacenter

25.03.2021 12:22:32 |

Автор: admin

Ранее мы уже рассказывали о том, как проходили аттестацию Uptime Institute Management & Operations Stamp of Approval в 2018 году и подтверждали уровень соответствия его требованиям в 2020.

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

Напомним, о чем идет речь: стандарт Management & Operations отраслевого экспертного института Uptime Institute оценивает качество управления инженерных служб дата-центров и направлен на снижение количества отказов из-за человеческого фактора.

Он появился в результате анализа 6000 эпизодов отказов ЦОДов за 20 лет наблюдений за отраслью и является частью (одной из трех) более емкого отраслевого стандарта Operational Sustainability.

Помимо M&O (управление и эксплуатация) туда входят также Building Characteristics (характеристики здания) и Site Location (расположение площадки). Вопросы управления и эксплуатации ЦОДа в этой иерархии играют главную роль в эксплуатационной устоичивости площадки.

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

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

Аттестация зрелости

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

Обеспечить себя такими сотрудниками стандарт рекомендует через качественный подбор персонала и выработку комплексного подхода к обслуживанию ЦОДа. Такая программа состоит из профилактического обслуживания (PM), политики уборки, системы управления техническим обслуживанием (MMS) для отслеживания работ, а также соглашения об уровне обслуживания (SLA).

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

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

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

Собственно, отсюда и берет начало наша система аттестации.

Вторая ее идеологическая опора стандарт ISO 22301 Security and resilience Business continuity management systems Безопасность и устойчивость Системы управления операционной непрерывностью бизнеса.

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

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

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

Наконец, третий столп нашей программы собственный опыт нескольких лет последовательной работы над повышением скоординированности и эффективности работы инженерных служб. Этот опыт нашел отражение в нашей документации по процедурам аварийной эксплуатации (EOP Emergency Operations Procedures), в том числе в части аттестации персонала.

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

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

Основные виды и главные задачи

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

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

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

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

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

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

Все вопросы сопровождаются подробно разобранными ответами со ссылками на нормативные документы и инструкции.

Процедура по сути

Аттестацию проводит комиссия в составе не менее трех человек, процедура состоит из двух этапов.

На первом проводится тестирование аттестуемого работника в рамках опросников и тестов. Общее количество вопросов 60-70 в зависимости от специализации. Во время аттестации случайным образом выбираются 15. Около 80% вопросов касаются непосредственно профессии, остальные 20% смежных областей знаний и компетенций коллег по ЦОДу.

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

Примеры вопросов для сотрудников различных департаментов

Механики

Раздел Maintenance (Обслуживание)

Когда запланировано следующее ТО систем, за которые вы отвечаете?
Сколько сотрудников указано в списке на доступ от подрядчика, который будет проводить следующее ТО?
Какая текущая версия и дата утверждения документа с контактами и SLA поставщиков?
Что такое Предупредительное обслуживание? (Predictive maintenance)? Дайте ссылку на инструкцию по Predictive maintenance и график его проведения.
Какие виды технического обслуживания проводятся в ЦОД? Чем они отличаются? Где можно увидеть списки такого обслуживания?

Раздел EOP

При какой температуре в помещениях ИБП нужно начинать выполнение EOP?
При каком давлении в системе ХС нужно начинать выполнение EOP?
Укажите действия при неисправности фанкойла Water loss alarm.

ИТ-инженеры

Раздел Оборудование

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

Раздел Работа в системе инцидент-менеджмента

Как определить, какой приоритет нужно поставить обращению?
Если для решения проблемы нужна дополнительная информация от клиента, какой статус нужно выставить в тикете?
Ваши действия при поступлении высокоприоритетных обращений в нерабочее время.
Как правильно запросить дополнительную информацию от клиента?
В чем разница в статусах On Hold и Waiting? Учитываются ли эти статусы при расчете времени решения обращения?

Инженеры-электрики

Раздел Общие инструкции, Приказы (Common Instructions, Orders)

Укажите ваши действия при пожаре в ЦОД и при пожаре в ДГУ.
Укажите ваши действия при появлении неисправностей на пожарной панели ЦОД или ДГУ.
Укажите ваши действия при ложном срабатывании систем пожаротушения ЦОД или ДГУ.
Каким документом регламентируются работы в действующих электроустановках?
Что должен сделать контролирующий системы мониторинга при появлении аварийных и предупредительных сообщений (за исключением периода перехода между источниками энергии)?
Где располагается мастер-ключ для экстренного доступа в стойки клиентов?
В каких инструкциях указаны меры по работе во время пандемии и какие они?

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

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

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

Решение принимается открытым голосованием большинством голосов.

Вердикты

По результатам аттестации выносится заключение:

занимаемой должности соответствует;
соответствует, но не полностью (рекомендуется повторная аттестация); или
не соответствует занимаемой должности.

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

Неполное соответствие чревато переводом с согласия сотрудника на другую работу, а также направлением на курсы повышения квалификации (дополнительного обучения).

Тяжело в учении легко в бою

Большую роль в процессе обучения сотрудников служб эксплуатации дата-центра играет практический аспект тренировки и учения.

В качестве примера приведем выдержки из итогового протокола учений по отработке действий сотрудников дежурной смены и охраны ЦОДа в Санкт-Петербурге.

Хронология событий

10⁵⁰ Произошел пожар (имитация) помещении 107. Сработала пожарная сигнализация и система голосового оповещения.

10⁵⁰ Руководитель смены охраны объекта связался с дежурной сменой ЦОДа, сообщив им о месте пожара и поставил задачу сотруднику охраны по организации эвакуации клиентов ЦОДа.

12⁰⁷ Сотрудник охраны выдвинулся в ЦОД для проверки путей эвакуации, разблокировки калиток на путях эвакуации, проверки разблокировки полноростового турникета, организации эвакуации людей. Сотрудник охраны экипирован электрическим фонарем, изолирующим противогазом и рацией для связи.

12⁰⁷ Звонок сотрудника охраны ЦОДа старшему смены охраны ПСБ СКАЙ-ТРЕЙД с сообщением о происшествии в ЦОДе.

12⁰⁸ Начало эвакуации людей, не задействованных в обнаружении и локализации (ликвидации) пожара, из помещений ЦОДа.

12⁰⁹ Сотрудники дежурной смены ЦОДа выдвинулись для проверки причин срабатывания пожарной сигнализации и организации эвакуации людей из ЦОДа.

12¹¹ Сотрудники дежурной смены ЦОДа подошли к месту предполагаемого пожара. Сотрудники экипированы электрическими фонарями и изолирующими противогазами.

12¹² Доклад сотрудника охраны о том, что все помещения свободны и люди из ЦОДа эвакуированы.

12¹² Эвакуация завершена.

12¹⁵ Перевод системы пожарной сигнализации и голосового оповещения из режима Пожар в дежурный режим. Окончание пожарно-технической тренировки.

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

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

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

Выводы и планы развития

Формализация и документирование процессов помогают обеспечить историчность (отслеживание динамики), а также объективность оценок.

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

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

И люди в этом перечне на первом месте.

Подробнее..

Категории: Инженерные системы , Цод , Управление персоналом , Дата-центр , Сертификация , Блог компании linxdatacenter , Эксплуатация цод , Аттестация персонала , Тренинг , Проверка знаний , Инженерная служба

Из песочницы Из ничего к ЦОД с VXLANEVPN или как готовить Cumulus Linux. Часть 1

01.11.2020 20:22:23 |

Автор: admin

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

Знакомство с Cumulus Linux. Установка оборудования и первоначальная настройка

Вводные к началу работ были следующие:

Закуплено оборудование
Арендованы стойки
Проложены линии к старым ЦОД

Первой порцией оборудования, которое необходимо было поставить, стали 4 х Mellanox SN2410 с предустановленным на них Cumulus Linux. На первых порах еще не было понимания как все должно будет выглядеть (сложится оно только к этапу внедрения VXLAN/EVPN), следовательно, мы решили поднять их как простые L3 коммутаторы с CLAG (Аналог MLAG от Cumulus). Ранее опыта работы с Cumulus ни у меня, ни у коллег сильно не было, так что все в какой-то степени было в новинку, дальше как раз про это.

Нет лицензии нет портов

По умолчанию при включении устройства вам доступны только 2 порта console и eth0(он же Management port). Чтобы разблокировать 25G/100G порты нужно добавить лицензию. И сразу становится понятно, что Linux в названии ПО не просто так, т.к. после установки лицензии надо перезагрузить демона switchd, через systemctl restart switchd.service (по факту отсутствие лицензии как раз и не дает запуститься данному демону).

Следующее, что сразу заставит вас вспомнить что это все-таки Linux, будет обновление устройства используя apt-get upgrade, как в обычном Ubuntu, но обновиться так можно не всегда. При переходе между релизами, например, с 3.1.1 на 4.1.1, нужно устанавливать новый образ, что влечет за собой сброс конфиги в дефолт. Но спасает то, что в конфигурации по умолчанию на Management интерфейсе включен DHCP, что позволяет вернуть управление.

Установка лицензии

cumulus@Switch1:~$ sudo cl-license -i
balagan@telecom.ru|123456789qwerty
^+d
cumulus@Switch1:~$ sudo systemctl restart switchd.service

P.S. Дефолтная конфигурация eth0(mgmt) интерфейса:
cumulus@Switch1:~$ net show configuration commands | grep eth
net add interface eth0 ip address dhcp
net add interface eth0 vrf mgmt

Система commitов

Как человек, много работавший с Juniper, для меня такие вещи как rollbackи, commit confirm и т.д. были не в новинку, но наступить на пару граблей удалось.

Первое, на что я напоролся, была нумерация rollback у cumulus, в силу привычки rollback 1 == последняя рабочая конфигурация. Я с огромной уверенностью вбиваю данную команду, чтобы откатить последние изменения. Но каково было мое удивление, когда железка просто пропала по управлению, и какое-то время я не понимал, что произошло. Потом, прочитав доку от cumulus, стало понятно, что случилось: вбив команду net rollback 1 вместо отката на последнюю конфигурацию, я откатился на ПЕРВУЮ конфигурацию устройства.(И опять же, от фиаско спас DHCP в дефолтной конфигурации)

commit history

cumulus@Switch1:mgmt:~$ net show commit history
# Date Description
2 2020-06-30 13:08:02 nclu net commit (user cumulus)
208 2020-10-17 00:42:11 nclu net commit (user cumulus)
210 2020-10-17 01:13:45 nclu net commit (user cumulus)
212 2020-10-17 01:16:35 nclu net commit (user cumulus)
214 2020-10-17 01:17:24 nclu net commit (user cumulus)
216 2020-10-17 01:24:44 nclu net commit (user cumulus)
218 2020-10-17 12:12:05 nclu net commit (user cumulus)
cumulus@Switch1:mgmt:~$

Второе, с чем пришлось столкнуться, был алгоритм работы commit confirm: в отличие от привычного нам commit confirm 10, где в течении 10 минут нужно еще раз прописать commit, у Cumulus было свое виденье данной фичи. Ваше подтверждение commit confirm это простое нажатие Enter после ввода команды, что может сыграть с вами злую шутку, если связность потеряется не сразу после commit.

net commit confirm 10

cumulus@Switch1:mgmt:~$ net commit confirm 10
/etc/network/interfaces 2020-10-17 12:12:08.603955710 +0300
+++ /run/nclu/ifupdown2/interfaces.tmp 2020-10-29 19:02:33.296628366 +0300
@@ -204,20 +204,21 @@

auto swp49
iface swp49
+ alias Test
link-autoneg on

net add/del commands since the last net commit
================================================

User Timestamp Command
cumulus 2020-10-29 19:02:01.649905 net add interface swp49 alias Test

Press ENTER to confirm connectivity.

Первая топология

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

На данной схеме отображена схема физики + разделение устройств по парам, все линки на схеме работают в режиме Trunk.

Как и говорилось, вся L3 связность сделана через SVI, следовательно, IP адрес в каждом Vlan есть только у 2 устройств из 4, что позволяет сделать своего рода L3 p2p связку.

Основные команды для заинтересованных

Bond(Port-channel)+CLAG(MLAG)

#Используем vrf mgmt согласно всем best-practice
net add interface peerlink.4094 clag backup-ip Х.Х.Х.Х vrf mgmt
#Чем меньше адресов тем лучше(можно вместо linklocal использовать IP адреса)
net add interface peerlink.4094 clag peer-ip linklocal
#Берем из пула указанного в документации 44:38:39:ff:00:00-44:38:39:ff:ff:ff
net add interface peerlink.4094 clag sys-mac Х.X.X.X.X
#Cоздание Bond#Добавляем интерфейсы которые нужно агрегировать
net add bond bond-to-sc bond slaves swp1,swp2
#Выбираем LACP
net add bond bond-to-sc bond mode 802.3ad
#Подаем VLAN в Bond
net add bond bond-to-sc bridge vids 42-43
#Присваиваем уникальный ID
net add bond bond-to-sc clag id 12
P.S. Всю указанную конфигурацию можно реализовать через /etc/network/interfaces

Проверка работоспособности

cumulus@Switch1:mgmt:~$ net show clag
The peer is alive
Our Priority, ID, and Role: 32768 1c:34:da:a5:6a:10 secondary
Peer Priority, ID, and Role: 100 b8:59:9f:70:0e:50 primary
Peer Interface and IP: peerlink.4094 fe80::ba59:9fff:fe70:e50 (linklocal)
VxLAN Anycast IP: 10.223.250.9
Backup IP: 10.1.254.91 vrf mgmt (active)
System MAC: 44:39:39:aa:40:97

Trunk/Access port mode

#Создаем интерфейс Vlan
net add vlan 21 ip address 100.64.232.9/30
#Назначаем ID
net add vlan 21 vlan-id 21
#Подаем в L2 Bridge
net add vlan 21 vlan-raw-device bridge
P.S. На данном этапе VLAN уже будет подан на Bridge порты
#Trunk порт (все bridge vlan)
net add bridge bridge ports swp49
#Trunk порт (ограниченный пул VLAN)
net add interface swp51-52 bridge vids 510-511
#Access порт
net add interface swp1 bridge access 21
P.S. Всю указанную конфигурацию можно реализовать через /etc/network/interfaces

OSPF+Static

#Static route для mgmt
net add routing route 0.0.0.0/0 10.1.255.1 vrf mgmt
#OSPF с включением по принадлежности к Network
net add ospf network 0.0.0.0 area 0.0.0.0
#OSPF на определенном интерфейсе
net add interface lo ospf area 0.0.0.0
P.S. На Cumulus может быть только один Loopback интерфейс
#OSPF редистрибьюции
net add ospf redistribute connected
P.S. Данный функционал так же можно конфигурировать через vtysh(c Cisco like синтаксисом), т.к. в Cumulus используется FRR

Заключение

Надеюсь, кому-нибудь данная статья покажется интересной. Хотелось бы увидеть feedback: что добавить, а что совсем лишнее. В следующей статье уже перейдем к самому интересному к дизайну целевой сети и настройке VXLAN/EVPN. И в будущем возможна статья по автоматизации VXLAN/EVPN средствами Python.

Подробнее..

Категории: Цод , Сетевые технологии , Коммутаторы , Cumulus linux , Mellanox , Mlag , Vlan , Ospf , Цодостроение

Серверы ЦОД согреют помидоры в Нидерландах

24.11.2020 20:17:07 |

Автор: admin

Производитель ОСР-систем (Open Compute Project ) ITRenew объединится с голландским хостинг-провайдером Blockheating, чтобы обеспечить теплом от дата-центров тысячи гектаров теплиц. Полученные от ДЦ излишки тепла будет передаваться на ближайшие фермы, где выращивают помидоры. Полная сингулярность, ага.

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

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

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

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

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

Испытания тестового контейнерного ЦОД в Blockheating провели в 2019 году.

На фото один из прототип контейнерного обогревателя для теплиц, 2019 год

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

Подробнее..

Категории: Цод , Экология , Блог компании selectel , Будущее здесь , Энергия и элементы питания , Экономика , Будущее , Энергоэффективность , Цоды , Зеленая энергетика , Теплицы

20000 петабайт под водой есть ли перспективы у подводных центров обработки данных

07.12.2020 10:20:40 |

Автор: admin

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

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

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

Но пока что подводные ЦОД далеки от того, чтобы стать глобальной реальностью. Более того, главный их аргумент, снижение нагрузки на экологию, перебивается новой идеей: удалением ROT-данных (Redundant, Obsolete or Trivial избыточные, устаревшие или банальные). Некоторые аналитики считают, что за 2020 год в атмосферу будет выброшено шесть миллионов тонн CO2 из-за хранения данных, которые компании не могут идентифицировать и которые могут даже не понадобиться им в будущем. Если бы эта идея стала популярной, то можно было бы увидеть значительное сокращение объёма хранящейся в ЦОД информации, что окажет прямое влияние на выбросы дата-центров, а также на общие расходы компаний.

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

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

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

В примере Microsoft всего восемь из 855 серверов вышли из строя за два года с тех пор, как центр обработки данных был погружен в океан. Это 12,5% от средней частоты отказов оборудования. Весьма достойные показатели, особенно если учесть отсутствие людей в сооружении. Подводный ЦОД выглядит весьма надёжно, представляя собой почти идеальный вариант для резервного копирования данных или Disaster recovery.

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

Что ещё интересного есть в блогеCloud4Y

В тюрьму за приложение

Детям о Кубернете, или приключения Фиппи в космосе

Определённо не Windows 95: какие операционные системы поддерживают работу в космосе?

Рассказываем про государственные защищенные сервисы и сети

Как настроить SSH-Jump Server

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

Подробнее..

Категории: Цод , Microsoft , It-компании , Облачные сервисы , Хранение данных , Хранилища данных , Блог компании cloud4y

OCP Experience Lab как мы строили мини-ЦОД в офисе

06.01.2021 00:04:36 |

Автор: admin

Начиналось всё с создания стенда для тестирования серверов нашей собственной разработки. Потом стенд разросся и мы решили сделать небольшой датацентр для пилотирования различных софтовых решений. Сейчас это единственная в Россси и вторая в Европе лаборатория OCP Experience Lab.

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

Для старта разработки выбрали сервера стандарта OCP. ОСР это Open Compute Project, открытое сообщество, в котором конструкторская документация на все продукты выкладывется в открытый доступ для свободного использования. Настоящий Open Source Hardware, и как следствие, самый прогрессивный, бурно растущий и перспективный стандарт, к тому же продвигаемый преимущественно не поставщиками, а потребителями оборудования. Помимо всех технических преимуществ, открытая документация должна была упростить нам старт разработки и ускорить встраивание в такую тяжелую тему, как серверное железо. Но это, наверное, тема для отдельной статьи.

А компанию, кстати, назвали GAGAR>IN. Скоро вы про неё ещё услышите.

Готовимся

Моё же личное знакомство с ОСР состоялось лет пять назад, когда я участвовал в продвижении решений американской Stack Velocity на российский рынок. Уже тогда у нас была идея локализовать их производство и сделать собранные в России сервера с открытой документацией для нужд госкомпаний и госзаказчиков. Но тогда импотрозамещение было ещё не в тренде, и все потенциальные заказчики в итоге предпочли купить тайваньское оборудование. Именно тогда произошел первый сдвиг в популяризации OCP в России: Яндекс установил в свой новый датацентр как-бы-OCP сервера от небольшого тайваньского вендора AIC, а Сбербанк, РЖД и Mail вовсю тестировали полноценные OCP решения от гиганта Quanta, крупнейшего мирового производителя вычислительной техники.

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

Сборочная линия небольшого тайваньского производителя серверов

Калифорнийское производство серверов крупного азиатского производителя

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

Стойка OCP Experience Center в Амстердаме выглядит очень красиво, но довольно бессмысленно

Стартуем

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

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

Тестирование новейшего сервера в домашних условиях

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

В июне, как только карантин немного ослаб, мы смогли начать сборку лаборатории нашей мечты.

Затащить серверные стойки в неприспособленный под это офис - само по себе нетривиальная задача

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

Монтаж очередного сервера в стойку

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

Три стойки, рабочий стол инженера и большой плакат - так выглядела наша лаборатория в сентябре 2020

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

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

Что и как тестируем

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

Всё началось с базовых тестов производительности железа. Мы прогнали через испытания множество компонент: модули памяти Samsung, Micron, Hynix; SSD от тех же Samsung, Micron и Intel; сетевые карты Mellanox, Broadcom, Emulex и Intel. И даже сравнили между собой процессора Intel SkyLake и AMD EPYC2.

Но понятно, что лаборатория не только место для тестирования новых железок. Потребители не бенчмарки будут мерять, им нужны рабочие программно-аппаратные конфигурации. И поэтому мы стали потихоньку собирать конфигурации различного софта и проверять его работоспособность и производительность. Начали с российских Линуксов: Альт, Астра и Роса. На базовых тестах всё прошло без сюрпризов - возможно стоит делать более глубокие исследования и сравнение в сложных задачах. Потом собрали несколько различных стендов систем виртуализации. Для начала попробовали VmWare, Proxmox, Virtuozzo с ними также всё прошло довольно гладко и скучно. Мы сохранили конфигурации и решили вернуться к этим системам позже, уже с реальными клиентскими задачами.

Так как основная идея OCP оборудование без излишеств, то всё разнообразие функционала перенесено на уровень софта. Фактически, любые конфигурации собираются из двух кирпичиков вычислительного сервера и присоединяемого к нему дискового массива JBOD (Just a Bunch Of Discs). Мы же собрали в лаборатории несколько различных исполнений как серверов, так и дисковых массивов, и следующим логичным шагом было тестирование их совместной работы.

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

Дашборд Zabbix

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

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

Финальный рывок

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

Один из первых вариантов дизайна

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

Лаборатория после ремонта

Теперь можно было проводить официальное открытие и снимать полноценное видео:

В итоге, у нас есть не только лаборитория, шоурум, но и удобная съемочная площадка для производства серии видеороликов про оборудование Open Compute.

Так что продолжение следует!

Самое главное - табличка на входе!

Подробнее..

Категории: Цод , Системное администрирование , Сервер , Компьютерное железо , Серверное администрирование , Дата-центр , Серверная оптимизация , Блог компании gagar>in , Ocp , Open compute

От появления ЭВМ до периферийных вычислений в телекоме

18.01.2021 22:06:54 |

Автор: admin

Edge Computing введение в тему

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

Одним из результатов исторического развития стало появление Edge Computing. Что важно знать об Edge Computing? Это не четкое определение или конкретные механизмы, а концепция, при которой часть обработки данных, критичная к скорости, выполняется на узлах, вынесенных за пределы крупных ЦОДов и размещенных перед последней милей или в минимальном количестве прыжков от конечного устройства-потребителя или поставщика данных. В русскоязычной среде для обозначения Edge Computing распространены два обозначения граничные вычисления и периферийные вычисления.

Рассмотрим, как произошёл переход от огромных машинных залов до периферийных вычислений на смартфонах.

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

Задачей самых первых операционных систем (ОС), появившихся в 50-х годах (например, GM-HAA), была координация запуска пакетов программ и вывод полученных результатов. Более развитые ОС (такие как Unix, RSX, VMS) появились в 70-х и получили много дополнительных функций, в том числе связанных с межкомпьютерным взаимодействием. Если первым пользователям приходилось для работы использовать системы ввода/вывода расположенные непосредственно в центрах обработки данных (ЦОД), то с развитием коммуникационных систем в 60-х годах появилась возможность подключать пользовательские терминалы по выделенным и коммутируемым медным телефонным линиям, а в конце 70-х по волоконно-оптическим. В середине 60-х для организации линий связи стали доступны первые коммерческие спутниковые каналы.

Параллельно с развитием линий связи совершенствовались и протоколы передачи данных. После появления пакетных систем передачи данных канального уровня (в 70-х годах протокола Ethernet и подобных, в 80-х годах протоколов SLIP, Token ring, HDSL и т.д.), а затем в 80-х протоколов для пакетной связи на региональном и на глобальном уровне (сеть Internet на основе стека протоколов TCP/IP), пользователям для обработки и хранения данных стали с рабочего места доступны удаленные компьютерные центры.

С выпуском в 70-х годах первых микропроцессоров начали активно развиваться специализированные вычислительные устройства и персональные компьютеры. Они подключались к мощным ЦОД через глобальную сеть в качестве клиентских периферических устройств для доступа к вычислительным мощностям и хранилищам данных. Как правило рабочее место использовалось в качестве тонкого клиента (например, как терминал подсоединенный по протоколам Telnet, rlogin и т.д.) для запуска вычислительных задач на удаленном сервере или для получения данных по таким протоколам как FTP.

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

Первоначально наиболее распространенный в операционных системах способ организации хранения данных в виде файловых систем оказался не оптимальным для работы со сложными структурами характерными для бизнес-приложений, что привело к созданию в 50-х и 60-х годах специализированных языков программирования для работы с большим количеством разнотипных записей сравнительно небольшого объема (таких как язык Cobol, на котором написаны многие приложения используемые до сих пор), и к возникновению в 70-х годах концепции реляционных баз данных и языка SQL.

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

Развитие сетевых технологий

В 90-х годах произошел кардинальный скачок в количестве пользователей сети Интернет, объеме трафика, производительности рабочих станций и серверов, в развитии сетевых технологий и вычислительных систем обработки данных обусловленный целым набором факторов:

Широкое внедрение высокоскоростных соединений на основе семейства протоколов xDSL.
Развитие волоконно-оптических линий связи (ВОЛС).
Стали более доступны спутниковые системы связи VSAT и дешевый комбинированный доступ.
Появление протоколов распределенного поиска и передачи документов (gopher, http и т.д.).
Появление первых поисковых систем - Archie (90), Wandex (93), Yahoo! (94), Google (96).
Создание универсального протокола канального уровня PPP с автоматизированной настройкой параметров соединения, удобного для клиентского соединение по коммутируемым линиям и поверх xDSL.
Степень интеграции, параметры микропроцессоров и технология SMP позволили использовать микропроцессоры при проектировании серверного оборудования, а центральные процессоры (ЦП) рабочих станции приблизились по производительности к ЦП серверов.
Появление пользовательских операционных систем для персональных компьютеров с интегрированным программным обеспечением для подключения к интернет-провайдерам, простой настройкой сервисов Интернет и предустановленными Web-браузерами (Windows 95).
Появление свободнораспространяемого и юридически чистого программного обеспечения на основе юниксоподобных систем (386BSD, FreeBSD, NetBSD, OpenBSD, ОС на основе ядра Linux и т.д.) портированных для широкой номенклатуры серверного и другого оборудования.

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

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

Облачные технологии

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

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

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

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

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

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

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

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

Edge Computing периферийные вычисления

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

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

Предпосылки для развития периферийных вычислений:

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

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

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

Применимость концепции следует именно из этих трех основополагающих элементов. Фактически, любые системы, работающие в реальном времени, могут требовать использования периферийных вычислений. Развитию рынка периферийных вычислений способствуют IoT (концепция интернет вещей - Internet of Things) и массовый переход на сети 5G первые обеспечивают кратный рост устройств, подключенных к сети, а вторые дают возможность передачи довольно больших объемов данных при росте количества подключенных устройств.

Оборудование для периферических вычислений

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

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

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

2 и 3 пункт фактически может быть приравнен к CDN (Content Delivery Network) - Сеть доставки содержимого. Либо наоборот на базе чьего-то CDN можно строить инфраструктуру для периферийных вычислений.

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

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

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

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

Архитектура

Наиболее распространены двух- и трёхзвенные варианты построения Edge-систем.

Двухзвенная граничное устройство и ЦОД/облако.

Трёхзвенная граничное устройство, туман (микроЦОДы, микрооблака, отдельные сервера), ЦОД/облако.

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

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

Достоинства

С точки зрения бизнеса следование концепции даёт:

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

Примеров использования множество и окружают они нас повсеместно.

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

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

Как всё это работает? Возьмем несколько упрощенных примеров.

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

Аналогично с камерами для фиксации потока автомобильного трафика - фиксируются количество и скорость автомобилей на трассе. На локальном оборудовании транспортные средства распознаются и классифицируются на мототранспорт, легковые авто, грузовые разного тоннажа и длины. Агрегированные данные отправляются в ЦОД. При нарушении скоростного режима, производится дополнительно фото/видеофиксация нарушителя номер ТС (Транспортного средства), фото авто и водителя (если возможно). Эти дополнительные данные также отправляются в ЦОД для формирования штрафа. Так же как с камерами в метро можно дополнительно отслеживать авто по госномерам по базе загруженной на локальное устройство.

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

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

Что еще можно назвать из наиболее востребованных периферийных вычислений?

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

Еще в 2018 году аналитики McKinsey говорили в своём отчете New demand, new markets: What edge computing means for hardware companies о 100 вариантах использования в 11 наиболее перспективных отраслях. А сейчас 2020 год и рынок динамично развивается несмотря на пандемию и экономический кризис.

Законы

Про это надо сказать отдельно. Законы и локальные нормативные акты диктуют свои правила игры. Из-за этого надо хранить данные граждан России на территории России, данные граждан Евросоюза на территории Евросоюза. Таких ограничений достаточно и это вынуждает технологические компании дробить базы и выносить их в CDN в конкретном регионе Земли.

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

Практика

Рассмотрим работу концепции переферических вычислений на примере компании Форвард-Телеком, одним из главных направлений работы которой является автоматизация деятельности операторов связи и интернет-провайдеров. Программное обеспечение Forward во многом является потребителем информации, полученной с edge- и endpoint-устройств. Система Forward BSS/OSS, как комплексная платформа, предназначена для поддержки бизнеса клиента практически при любой существующей модели сети оператора. Платформа Forward имеет логичную модульную структуру, легко масштабируется, поддерживает облачную и гибридную модель развертывания, при этом система позволяет настроить разнообразные внешние интерфейсы для взаимодействия с элементами сети оператора и клиентами.

Система OSS отвечает за правильную работу сетевой инфраструктуры и оборудования, а система BSS за учет оказанных услуг, взаиморасчеты с абонентами, управление ресурсами и проектами (элементы подсистемы ERP), за отношения с абонентами и хранение дополнительных данных (элементы системы CRM).

Для небольших операторов доступ к возможностям Forward BSS/OSS может предоставляться как стандартизованная услуга облачного сервиса по модели SaaS, при этом сеть оператора и его клиенты взаимодействуют с системой в рамках концепции Edge Computing.

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

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

Характерной особенностью многих крупных операторов является наличие исторически сложившегося зоопарка информационных систем. Плохо совместимое программное обеспечение различных вендоров, внедрённое на разных этапах развития компании в каких-то региональных подразделениях или полученное при покупке местных операторов. Быстрая замена такого зоопарка часто не возможна или слишком накладна. Интеграция исторических информационных систем может быть быстрее и дешевле произведена через Forward BSS/OSS через API или специально написанные шлюзы.

Поток обращений по интеграции OSS/BSS систем с мобильными приложениями становится больше. Все операторы связи, банки, ритейлеры, сервисные компании, госорганы постепенно обзаводятся приложениями B2B, B2C или B2B2C класса для коммуникации со своими заказчиками. Самостоятельное управление абонентскими услугами через мобильное приложение подразумевает глубокую интеграцию в бизнес-процессы компании и всё больше приближает нашу работу по автоматизации к endpoint-устройствам конечных пользователей.

Сложности при использования концепции

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

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

Для разработчиков систем автоматизации, 7 пункт является наиболее важным. Именно он входит в сферу ответственности Форвард-Телеком перед заказчиком и разработчики стараются выполнять свою работу хорошо. О том, как идёт у Форвард-Телеком разработка биллинговых систем уже писалось на Хабре в статье Как там биллинг делается: когда заказчик и разработчик говорят на разных языках.

Уменьшение техпроцесса и широкое распространение энергоэффективных многоядерных вычислительных устройств будет способствовать дальнейшему перекладыванию обработки данных на локальные устройства и увеличению собираемой номенклатуры данных. Как минимум, можно ожидать, что будет необходимо готовить платформу Forward OSS/BSS к существенному расширению типов поступающей информации, обработке этих данных в реал-тайме с использованием Edge Computing инфраструктуры. Например, вполне вероятно, что в будущем данные какого-нибудь фитнес-браслета о кардио-ритме носителя могут быть использованы в банковской системе для скоринга рисков, оценки вероятности возврата задолженности и расчета процентной ставки по кредиту.

Так что Prepare yourselves because cyberpunk is coming

Подробнее..

Категории: Цод , Big data , Облачные сервисы , Инфраструктура , Периферия , Облако , Saas / s+s , Периферийные вычисления

Тестируем СХД OceanStor Dorado V6 Hyper и Smart

02.02.2021 16:10:30 |

Автор: admin

Привет, меня зовут Павел. Я работаю ведущим системным инженером группы внедрения в департаменте вычислительных систем компании STEP LOGIC. В этом посте я поделюсь своими наблюдениями о флеш-системе хранения данных Huawei OceanStor Dorado V6, которую мы тестировали ~~в полях~~ в инфраструктуре заказчика.

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

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

Подробно остановлюсь на функциях:

HyperSnap мгновенный виртуальный снимок одна из разновидностей моментальных снимков, фиксация данных в определенный момент времени.
HyperCDP функция создания мгновенных снимков с высокой частотой (через малый промежуток времени).
HyperClone создает полные копии исходных данных с использованием расписания. Механизм применяется для резервного копирования, защиты, анализа и тестирования данных. В отличие от классического моментального снимка, на создание клона требуется определенное время, клон не грузит основной LUN.
SmartQOS позволяет настроить приоритеты ввода-вывода: повысить или понизить приоритет выделенному LUN'у и тем самым управлять скоростью обмена данными.

А о результатах тестирования производительности и отказоустойчивости я напишу во второй части.

О технических параметрах Dorado V6

СХД OceanStor Dorado V6 впервые представлена в сентябре 2019 года. В линейке продуктов пять моделей, условно распределенных на три класса low-end (Dorado 3000), mid-end (Dorado 5000/6000) и hi-end (Dorado 8000/18000). Модели в линейке объединяет схожая архитектура, интерфейс управления и набор функций. Основные различия в максимальной емкости и производительности.

Из отличительных особенностей OceanStor Dorado V6 базируется на процессорах и контроллерах производства компании Huawei. Из-за санкций США Huawei вынуждены были отказаться от процессоров Intel для своих СХД, перейдя на ARM-чипы собственного производства. У флагманских моделей Dorado 8000 V6 и 18000 V6 количество ядер на контроллер переваливает за сотню, а точнее 128 и 192 ядра соответственно. Если быть точным сам чип Kunpeng 920 на архитектуре ARMv8.2 может иметь от 24 до 64 ядер. Такое высокое суммарное количество ядер получается путем установки нескольких подобных процессоров в 1 контроллер.

Ниже речь пойдет о Huawei OceanStor Dorado 3000 V6 (24 ядра на контроллер), которая может применяться как для вспомогательных систем и сервисов, так и в качестве основной СХД для небольших компаний.

Почему выбрана именно Dorado 3000 V6?

Как это часто бывает младшие модели оборудования выглядят не так ярко на фоне представителей hi-end из этой же линейки и незаслуженно получают меньше внимания. Поэтому после 21 миллиона IOPS, которые были достигнуты Huawei на своей OceanStor Dorado 18000 V6, хотелось посмотреть, на что годится самая бюджетная All-flash СХД от Huawei.

Заказчик, совместно с которым проводилось тестирование, планировал купить аналогичную модель СХД, но с увеличенным суммарным сырым объемом и дополнительной полкой расширения (Disk Enclosure). У компании были опасения в части производительности системы, которые мы и постарались преодолеть в процессе тестирования.

Коротко о стенде для тестирования

В тесте мы использовали следующую конфигурацию Huawei OceanStor Dorado 3000 V6:

пара контроллеров Active-Active с единым кэшем 192 Гб;
48 процессорных ядер, по 24 ядра на каждый контроллер;
восемь SSD-дисков 7,68 Тб;
две карты расширения Smart-IO 4х16Gb FC;
две карты расширения Smart-IO 4х10Gb Ethernet.

Примечание. Dorado V6 3000, в отличие от более мощных моделей в этой же линейке, поддерживает установку только накопителей SAS 3.0. NVMe формата Palm доступны начиная с модели 5000 V6.

Рисунок 1. Фронтальная панель установленной в стойку Huawei OceanStor Dorado V6 3000.

Для чистоты эксперимента, чтобы абстрагироваться от нюансов существующей инфраструктуры, уже используемой заказчиком для рабочих целей (и не нагружать лишний раз production SAN), было принято решение подключить СХД к серверу виртуализации (VMware ESXi 6.5) напрямую двумя FC-интерфейсами. Сервер виртуализации обеспечивал работу двух виртуальных машин, в которых мы запускали утилиту генерации и измерения нагрузки VDBench (Oracle), также был установлен драйвер multipath (Huawei Ultrapath).

На СХД мы создали дисковое пространство Storage Pool (далее SP), включающее в себя все восемь SSD дисков, с параметром отказоустойчивости RAID-6 и двумя резервными дисками Hot Spare. Диски LUN, созданные на данном SP, были подключены к виртуальным машинам как RDM-диски.

HyperSnap

HyperSnap представляет собой ни что иное, как Snapshot, созданный на LUN'е. Используется для резервного копирования, тестирования и других задач.

Важно отметить, что такой Snapshot работает по принципу ROW (redirect-on-write), вместо ранее считавшимся классическим COW (copy-on-write). Согласно этому алгоритму, новые данные не заменяют на старые, а записываются на свободное место. Такой Snapshot по сути является таблицей со ссылками. При создании снимка HyperSnap СХД записывает все сведения об изменениях в специально выделенную часть виртуального диска LUN Metadata. Снимок HyperSnap не является полной копией данных и поэтому не занимает много места.

Собственно, алгоритм ROW уже своего рода классика для Flash-массивов.

Рисунок 2. Отличия алгоритмов COW и ROW.

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

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

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

Рисунок 3. Мгновенный снимок HyperSnap с именем LUNGroup006.

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

Рисунок 4. Консоль управления фирменного драйвера MultiPath от Huawei UltraPath.

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

Кроме того, LUN'ы можно добавлять в так называемые Consistency Groups, что позволяет делать снимки указанных данных в один и тот же момент данных. Это крайне важно, если вы придерживаетесь рекомендаций вендоров и раскладываете файлы и логи тех же баз данных по разным LUN'ам.

HyperCDP

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

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

Помимо функции защиты, HyperCDP имеет еще одно важное преимущество. При использовании данной функции практически не страдает производительность. Это мы и проверим в процессе тестирования.

Для теста заведем на нашей СХД 16 LUN по 512 Гб, подключим их к одной ВМ и дадим нагрузку с помощью бенчмарка VDBench.

Примечание. VDBench сам по себе довольно прост, Oracle распространяет его бесплатно, из сопутствующего ПО требуется лишь установленный JRE.

В вызываемом файле конфигурации необходимо задать параметры, которые будут использоваться при тестировании. Допустим, VDBench будет писать блоком 8 килобайт с 70% полностью рандомного чтения и параметрами дедупликации и компрессии 2 к 1.

На СХД мы также настроим HyperCDP-план, который позволит в процессе делать снимки каждого из 16 LUN'ов с интервалом в 10 секунд. Ограничим эту задачу 500 объектами (для каждого LUN'а). Максимальное же количество в рамках одного плана может быть 60000.

Рисунок 5. Веб-интерфейс с примером созданного HyperCDP-плана.

Остается запустить VDBench с указанными ранее параметрами и наблюдать за текущей производительностью.

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

Рисунок 6. Результаты теста HyperCDP.

Подождем еще немного, пока количество HyperCDP-объектов всех LUN'ов не перевалит за сотню, и проверим еще раз.

Рисунок 7. Результаты теста HyperCDP с количеством объектов более 100.

Подводя промежуточные итоги, стоит отметить, что эмулируемый в рамках теста сервис не испытал каких-либо воздействий в плане деградации производительности, и за полтора часа мы получили 500 снимков 16-ти LUN'ов, что в сумме составляет 8000 объектов.

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

HyperClone

Из названия HyperClone становится очевидно, что эта функция делает точную копию указанного LUN'а.

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

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

В отличие от снимков HyperCDP клон не грузит основной LUN. В веб-интерфейсе соответствующего раздела доступна синхронизация в обе стороны: Synchronize и Reversе Sync. Если данные на первичном LUN'е были изменены и должны быть перенесены на вторичный, используется инкрементальная синхронизация, т.к. СХД отслеживает изменения созданных пар.

Примечание. Ранее рассмотренные варианты создания снимков HyperSnap и HyperCDP занимают намного меньше дополнительного пространства на хранилище, т.к. не являются полной копией данных

Рисунок 8. Настройка HyperClone.

Для разрыва связи достаточно удалить созданную пару в разделе веб-интерфейса Data Protection, в закладке Clone Pairs.

Рисунок 9. Удаление клон-пары.

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

SmartQOS

В принципе, сервис SmartQoS штука не новая. Системы, которые обеспечивают нужную полосу пропускания для критичных сервисов за счет приоритизации, существовали и ранее. Использовать разные LUN'ы под различные сервисы совершенно нормальная практика. В этом случае иногда возникает необходимость выставить максимальные показатели производительности по IOPS или Bandwidth на те или иные объекты.

Рисунок 10. Настройка политики SmartQoS.

Такой подход бывает необходим в определенных ситуациях, например, утренний Boot Storm у VDI. Инженеры Huawei учли этот факт есть возможность включать нужный режим QoS по расписанию.

Функция прячется под кнопкой Advanced.

Рисунок 11. Настройка расписания (раздел Advanced).

Выполнить проверку просто необходимо создать политику SmartQOS для одного из LUN'ов с параметрами ниже.

Рисунок 12. Созданная политика SmartQoS001.

Далее снова обратимся к помощи бенчмарка VDBench (в тестировании он встретится еще не раз). СХД с точностью как в аптеке отмеряет нашей эмуляции сервиса предоставляемые IOPS'ы. Для наглядности ниже привожу показания со стороны тестового ПО и со стороны Dorado.

Рисунок 13. Результат выполнения политики SmartQOS.

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

Для последних также важно наличие такой настройки как Burst, когда политика позволяет превысить максимальные значения на определенный срок, задаваемый администратором. Это поможет проще пережить уже упоминаемый ранее Boot Storm. Если у Dorado будет возможность не жертвовать другими сервисами, она спокойно перейдет в режим Burst в политике и обеспечит требуемые параметры производительности.

Подведение итогов для первой части

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

Что касается результатов тестов они говорят сами за себя. Dorado V6 в реальной жизни выглядит достаточно неплохо, даже в начальной своей конфигурации. По цене младшая Dorado V6 соперничает со многими гибридными СХД, которые показывают куда более скромные результаты в тестах производительности. Ее можно рассматривать к покупке практически под любые сервисы. Разве что для резервного копирования All-flash массивы все еще слишком дороги.

Подробнее..

Категории: Цод , Системное администрирование , Хранение данных , Системы хранения данных , Хранилища данных , Серверная оптимизация , Серверная , Блог компании step logic , Системная интеграция

Успеть за 24 часа история переезда оборудования между ЦОДами

29.03.2021 10:21:19 |

Автор: admin

Переезд сродни пожару. Накал страстей нужно умножить на 10, когда речь идет о перевозке целого ЦОДа крупного банка. Сомневаетесь, что за 24 часа можно перевести 25 стоек, которые содержали 150 единиц оборудования, включая СХД, высокопроизводительные серверы HP Superdome и целый набор разных систем от Sun, Huawei, Lenovo, Quantum и IBM? Берите попкорн, кота на колени, вязание (нужное подчеркнуть), а мы расскажем, как это было и поделимся лайфхаками, как пережить подобные проекты.

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

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

Хорошая подготовка половина успеха

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

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

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

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

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

Три. Начинаем разбирать

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

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

Два. Переезжаем

Отставание от графика уже перевалило 5 часов, когда оборудование было готово. Начали работать. Нужно было погрузить 25 стоек со 150 единицами оборудования. Чтобы уложить переезд в сутки, мы выставили приоритеты, разделив системы на 3 категории. Сначала перевозились наиболее критичные системы, потом средней важности и наименее приоритетные.

В числе переезжавших устройств оказались не только серверы переселялось также хранилище high-end класса Huawei Ocean Store и уникальная для России система защиты Hitachi Protection Platform. Это оборудование курировали профильные специалисты с соответствующей сертификацией. Тонкость заключалась в том, что нам нужно было подобрать по 3 инженера на каждый вид специализированного оборудования, чтобы в каждую смену кто-то знающий отвечал за соответствующие устройства.

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

Один. Собираем и запускаем

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

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

К подключению сложных устройств мы тщательно подготовились заранее и вовлекли в проект вендоров. Например, для отключения и подключения HP Superdome приехал инженер HPE. Hitachi Protection Platform мы запускали на новом месте при поддержке российского представительства. То же самое касалось и Huawei Oceanstor нам потребовалось практически непрерывно поддерживать связь с техподдержкой производителя, пока шла настройка и конфигурирование на целевой площадке.

Можно ли успеть за 24 часа?

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

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

Драгоценная мораль

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

При переезде нужно думать за себя и того парня. По возможности нужно наладить сквозную проверку документации между всеми участниками: и теми, кто проектирует, и теми, кто внедряет. Это можно организовать, например, во время совместного осмотра площадки.
К работе с уникальным оборудованием обязательно нужно привлекать вендора. Стоит заранее делать запрос вендору, потому что нужный специалист может оказаться занят на время проекта.
На подобный переезд нужно закладывать дополнительные ресурсы. Во-первых, должно быть как минимум два менеджера. Один человека может энергетически не вытянуть разруливание проблем все 24 часа, если планы начнут сыпаться, как костяшки домино.Во-вторых, нужно предусмотреть скамейку запасных из исполнителей, если работы выйдут за рамки плана и основному составу нужно будет экстренно дать отдых.
Качественная подготовка к переезду прекрасный повод для ревизии имеющегося ИТ-хозяйства. На этом проекте мы сэкономили массу времени и сил, отказавшись от перевоза старых серверов.
Ночные смены = увеличенная нагрузка. К ночным работам стоит относится аккуратнее вдвойне и команды менять вовремя, не рассчитывая на переработки.
Нужен почасовой план с пошаговым описанием действий всех участников. Да, сражение никогда не идет по плану, но, если у вас нет плана вы точно проиграете. Поэтому очень помогает предварительно прогнать всю схему с участниками процесса в настольном режиме и заложить дополнительные резервы на случай сбоев. А еще, готовя такой план, не стоит попадать в ловушку сознания: если я пробегаю 100 метров за 10 секунд, то с марафоном за управлюсь меньше, чем за 1,5 часа. Это не так. Усталость сильно влияет на скорость работ, и это тоже нужно брать в расчет.

А вы участвовали в подобных ИТ-переездах? Какие выводы оказались самыми ценными для вас?

Автор: Нина Пушкарь, менеджер проектов Инфосистемы Джет

Подробнее..

Категории: Цод , Анализ и проектирование систем , Читальный зал , Переезд , Блог компании инфосистемы джет

Перевод CCIE 13 Как сдать экзамен Designing Cisco Enterprise Networks (300-420 ENSLD)

29.03.2021 18:20:06 |

Автор: admin

Современная IT инфраструктура все больше виртуализируется, уплывая в Облака. Модели все как сервис SaaS, PaaS, IaaS используются повсеместно, но все эти решения по-прежнему используют сети передачи данных и машинные ресурсы для их обработки.

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

Также в рамках набора в группу онлайн-курса Дизайн сетей ЦОД подготовили перевод полезного материала.

В данной статье, я затрону тему экзамена CCNP Enterprise specialist, Designing Cisco Enterprise Networks (300-429 ENSLD) и расскажу, как я смог сдать его с первой попытки после примерно 80 часов, потраченных на обучение.

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

Содержание

Дисклеймер (письменный отказ от ответственности)
Предварительные требования к экзамену
Бесплатные ресурсы для обучения
Платные ресурсы для обучения
Впечатления от экзамена
Совет по экзамену
Осмысление моего путешествия

Дисклеймер

Я написал эту статью, придерживаясь NDA (соглашение о неразглашении) по сертификационным экзаменам Cisco.

Пожалуйста, не связывайтесь со мной, касаемо:

Информации об экзамене, которая нарушит соглашение NDA;
Информации о закупке или рекомендации по подсказкам к сертификационному экзамену; или
Несанкционированного обмена платными учебными материалами.

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

Я не просматриваю, не одобряю и не рекомендую лиц, компании или продукты, за которые я лично не платил и не использовал. Сам автор желает сообщить, что они работали с CBT Nuggets в качестве менторов сообщества и экспертов по получению обратной связи UX, поэтому, пожалуйста, учитывайте этот потенциальный конфликт интересов при прочтении обратной связи о CBT Nuggets и их конкурентах.

Предварительные требования к экзамену

Для сдачи экзамена Designing Cisco Enterprise Networks не существует формальных или каких-либо официальных предварительных требований.

Я рекомендую всем тем, кто хочет сдать этот экзамен, выполнить следующие предварительные условия:

Понимание CCNA (Cisco Certified Network Associate) или эквивалентных концепций;
Способность бегло просматривать абзацы с информацией.

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

Я настоятельно рекомендую не-носителям английского языка, сдающим этот экзамен на английском языке, сделать запрос на дополнительное время.

Бесплатные ресурсы для обучения

Cisco Дизайн Презентаций в режиме реального времени

Ознакомление с размещением Wired LAN на кампусе с помощью сертифицированного Cisco проектирования представлено Dana Daum. BRKCRS-1500 @ CiscoLive 2020 Barcelona [Session Link]
Cisco SD-Access Campus Wired и размещение беспроводных сетей с использованием сертифицированного проектирования Cisco представлено Prashanth Davanager Honneshappa. DGTL-BRKCRS-1501 @ CiscoLive 2020 Digital [Session Link]
Упрощенное проектирование QoS кампуса представлено Roland Saville. BRKCRS-2501 @ CiscoLive 2020 Barcelona [Session Link]
WAN архитектуры и принципы представлено David Fusik. BRKRST-2041 @ CiscoLive [Session Link] Первые 20-30 минут являются релевантными, остальные необязательными.

Технические презентации Cisco в режиме реального времени

Протокол маршрутизации промежуточных систем (IS-IS) представлено Elvin Arias Soto. BRKRST-2315 @ CiscoLive 2019 San Diego [Session Link]
Введение в IP Multicast представлено Tim McConnaughy DGTL-BRKIPM-1261 @ CiscoLive 2020 Digital [Session Link]
Многоадресный поиск неисправностей представлено Fish Fishburne DGTL-BRKIPM-2264 @ CiscoLive 2020 Digital [Session Link]
Распознавание IP Multicast в SD-Access представлено Lukasz Ciukaj BRKRST-2820 @ CiscoLive 2020 Barcelona [Session Link]

Комментарий по ресурсам Cisco

Ресурсы Cisco Live позволяют углубиться в темы, которые они охватывают, и дают представление о проектировании сетей предприятия, которые не обязательно описываются в платных материалах. Они могут быть довольно интенсивными, если вы переходите на ENSLD с CCNA, поэтому я рекомендую организовать просмотры выступлений таким образом, чтобы можно было сделать множество заметок.

Multicast и IS-IS это две технологии, которые не были слишком подробно затронуты за пределами предыдущего письменного экзамена CCIE R&S. Если вы, как и я, прошли через трек Routing & Switching, я считаю следующие доклады важными: Элвина Ариаса Сото (Elvin Arias Sot) "Definitive IS-IS" и "Introduction to IP Multicast" Тима МакКоннохи (Tim McConnaughy). Это два отличных доклада, которые я часто пересматривал во время моего обучения в CCIE.

Ресурсы, созданные сообществом

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

Платные ресурсы

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

Все цены указаны в долларах США, если не указано по-другому.

Я сам заплатил за все материалы из своего кармана и получил возврат в размере ~75-85% от стоимости расходов через австралийскую налоговую систему.

Официальные учебные материалы CISCO

Книги:

CCNP Enterprise Design ENSLD 300-420 Официальное Сертификационное Руководство по Designing Cisco Enterprise Network Авторы: Anthony Bruno & Steve Jordan Amazon: $53.66 (kindle) [Amazon link]

Cisco Press: $55.99 (книга или ebook), $80.49 (книга + eBook bundle) [Cisco Press link]

Изучение в OReilly: БЕСПЛАТНО (10 or 30 дней пробный период), $49.95 в/месяц или $499.95 в/год (ежемесячная или годовая подписка), $75-149 в/год через подписку ACM [OReilly link] [ACM Sign Up]

eLearning:

Designing Cisco Enterprise Networks (ENSLD) v1.0 @ $800 (доступен отрывок бесплатного курса) [link]

Обучение у сторонних организаций:

eLearning:

CBT Nuggets: Designing Cisco Enterprise Networks 300-420 ENSLD Cisco Certification Training @ $59 в/месяц или $599 в/год (доступен бесплатный пробный период) [link]

IT Pro TV: Cisco CCNP Enterprise ENSLD (300-420) @ $29-49 в/месяц или $299-499 в/год (доступен бесплатный пробный период) [link]

Комментарий по платным учебным материалам

Я не рекомендую использовать учебник Cisco Press "CCNP Enterprise Design ENSLD 300-420 Official Cert Guide": Designing Cisco Enterprise Networks". Эта книга является хорошим руководством по проектированию концепций, но ограничивается введением и оставляет желать лучшего. В конце разделов, посвященных обзору глав, содержатся вопросы, которые, по моему мнению, способствуют более глубокому изучению, а не пониманию проектирования концепций. Мне кажется, что книга выиграла бы если бы в ней присутствовали бизнес-кейсы по проектированию, которые помогли бы учащимся сравнить и противопоставить технологии в зависимости от конкретного сценария. Разделы о Cisco SD-WAN, Cisco SD-Access и сетевом программировании слишком короткие и не предоставляют достаточно подробной информации для читателя. Я бы не рекомендовал использовать эту книгу, кроме как для ознакомления с концепциями экзаменационных схем и викторин с главой Do I Know This Already? (Знаю ли я это уже?). Этот ресурс не подготовит вас в достаточной степени к экзамену.

Cisco eLearning курс Designing Cisco Enterprise Networks (ENSLD) v1.0 был феноменальным. Это дорогостоящий курс стоимостью 800 долларов (доступен вариант оплаты учебного кредита cisco), но он содержит массу весьма актуальной информации для сдачи экзамена. По окончанию курса вы также получите 40 баллов для дальнейшего обучения ("CE"), которые могут быть использованы для продления сертификата Cisco. Что же делает этот курс настолько фантастическим? Это, безусловно, подробные модули и их завершающий модуль в виде викторины (некоторые из золотых медалей трудно получить!) и проектирование конкретных бизнес-кейсов, которые проводят читателя через бизнес-сценарий, наполненный викторинами по проектированию, которые проверяют ваши знания по предыдущим модулям. Моя единственная проблема с этим курсом была связана с тем, что некоторые из видеозаписей не такие интересные и могли бы быть лучше презентованы. Тем не менее, я настоятельно рекомендую это курс. Этот ресурс подготовит вас к экзамену.

CBT Nuggets Designing Cisco Enterprise Networks eLearning был феноменальным. В нем содержится 26 часов контента, специально подготовленного для экзамена ENSLD. Для меня обучение было превосходным, так как оно познакомило нас с новыми техническими концепциями на высоком уровне, предоставило несколько легких конфигураций и лабораторных примеров того, как может быть реализована та или иная технология (хотя это не требуется для экзамена), а затем позволило нам получить более подробную информацию, которая может быть использована для подготовки к экзамену ENSLD. Вопросы викторины с каждым видеороликом, были великолепны, и мне особенно понравились видеоролики Джеффа Киша (Jeff Kish) Обзор закрепления навыка и викторина ( end of skill review and quiz), которые помогли закрепить мое понимание темы. Этот ресурс подготовит вас к экзамену.

Обучение IT Pro TV "Cisco CCNP Enterprise ENSLD (300-420)" было нормальным, если вы платите $29 в/месяц за базовую Подписку IT Pro.

Это дешевый и быстрый старт для изучения ENSLD, который содержит 5,5 часов контента и предоставляет ссылки на дополнительные ресурсы для самостоятельного изучения, чтобы пользователь мог получить дополнительную консультацию. Энтони Секейра (Anthony Sequeira) предоставляет отличный обзор всех технологий на экзамене в индивидуальном порядке. Тем не менее, при комбинировании нескольких технологий ему необходимо было предоставить дополнительные подробности, связанные с проектированием. Это навык, который требуется на экзамене. Сам по себе этот курс не подготовит вас к экзамену в достаточной степени. Тем не менее, я думаю, что это подходящая альтернатива официальному руководству по сертификации, особенно в сочетании с другими учебными курсами Cisco, предлагаемыми IT Pro TV.

Впечатления от экзамена

Я сдавал экзамен 26 февраля в 14:45 в Центре тестирования Pearson Vue. Экзамен длился 90 минут и состоял из 62 вопросов. Я закончил экзамен примерно за 3 минуты до окончания и должен был "угадать" только 3 вопроса из-за нехватки времени. Экзамен был честным и полностью соответствовал образцу. Был только 1 вопрос, который мне показался неуместным (скорее всего, "бета" вопрос).

Я чувствую себя немного странно из-за этого экзамена. С точки зрения опыта тестирования и соответствию образцу я бы легко оценил этот экзамен на 9/10. Это очень хорошо организованный и приятный экзаменационный опыт, который нуждается только в небольшой поправке с точки зрения количества вопросов и экзаменационного темпа. Этот рейтинг, к сожалению, кардинально меняется, если я рассматриваю ценность сертификации Cisco Certified Enterprise Design Specialist. С точки зрения ценности, я бы оценил эту сертификацию на 3/10, потому что экзамен является в корне ошибочным с точки зрения оценки того, понимает ли кандидат концепции корпоративного проектирования. Эта оценка полностью зависит от экзамена официальные учебные материалы были просто отличными, и я многому из них научился. Так что же мне не понравилось на экзамене? Количество вопросов, типы вопросов, сложность и характер экзамена в его нынешнем состоянии.

Экзамен состоит из тривиальных вопросов и вопросов по примерам с множественными вариантами ответов. Вопросы на основе примеров требуют прочтения примеров, с которым сталкивается сетевой инженер или архитектор сети. Они могут быть достаточно многословными или содержать сетевые диаграммы, требующие интерпретации. Некоторые вопросы могут иметь ограничения, которые заставляют вас задуматься о том, как решить проблему по-другому. Когда я говорю тривиальные вопросы с множественными вариантами ответа, я действительно имею это в виду. Я вспоминаю экзамен ICND1 CCENT, содержащий более сложные вопросы по похожим концепциям. Такая структура экзамена на основе примеров/многосложных вариантов ответов создает своеобразную проблему, потому что невозможно узнать, со сколькими сценариями вы сталкиваетесь. В результате нелегко оценить, сколько времени вы должны потратить на один вопрос, поскольку к концу экзамена у вас может накопиться стопка примеров, что может привести к тому, что у вас не хватит времени! Для сертификации специалиста профессионального уровня этот экзамен покажется слишком простым и, возможно, более легким, чем CCNA. Пожалуйста, имейте в виду, что я могу воспринимать экзамен легким, потому что сетевое проектирование является частью моей работы, и у меня насчитывается более 600 часов обучения в CCIE.

Я считаю, что экзамен по проектированию сетей Cisco Enterprise Networks (300-420 ENSLD) необходимо переписать, чтобы повысить ценность сертификации аналоговых специалистов. На мой взгляд, эта сертификация должна соответствовать или превосходить по сложности 3-часовую секцию по проектированию в тестовой лаборатории CCIE Enterprise Infrastructure. Лично я бы ограничился 30 вопросами и сделал бы весь экзамен 100% ориентированным на примеры. Например, в примерах могли бы участвовать три разные компании, каждая из которых следовала бы разному повествованию, где инженеру нужно было бы решить 10 различных проектных задач на каждую компанию. В качестве альтернативы, он мог бы походить на старый экзамен CCNP TSHOOT и представить проектные задачи как проблемные задачи. Это сделало бы сертификацию более ценной в моих глазах, потому что сетевые инженеры должны учитывать влияние, которое малые и низкоуровневые проектные изменения оказывают на существующую среду предприятия.

Совет по экзамену

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

Описание проблемы: что мы пытаемся решить максимум пару слов.
Ограничения: есть ли какие-то ограничения в нашем решении?
[A] [B] [C] [D] [E]: Перечислите опции, а затем зачеркните все ответы, которые не относятся к делу или явно неправильные.

Это экзамен по проектированию, так что "сфокусируйте свое мышление на высоком уровне" и избегайте слишком быстрого вовлечения в технические аспекты. Это для тех, у кого есть опыт в конфигурировании, внедрении и поддержании технологий на этом экзамене. Это экзамен по проектированию, поэтому постарайтесь не беспокоиться о специфике той или иной технологии. Сфокусируйте свое мышление на главном и на высоком уровне. Думайте о технологиях, описанных в образце экзамена, как об инструментах в вашем ящике для инструментов. Этот экзамен заключается в сравнении и противопоставлении этих инструментов друг другу, чтобы вы могли оценить, какой инструмент лучше всего использовать для конкретного сценария. Этот экзамен НЕ о том, как на самом деле использовать инструмент. Например, давайте рассмотрим поддержку быстрой конвергенции L3 с протоколом маршрутизации. Вы можете получить два варианта: использовать таймеры "subecond hello" и опустить таймер "dead/hold", или использовать BFD для обнаружения сбоя в соединении. Оба они являются "технически" правильными инструментами, которые вы можете использовать. Однако, ограничение таймеров протокола может привести к тому, что он станет хрупким (более восприимчивым к самопроизвольной конвергенции во время нормальной работы) и увеличит загруженность hardware CPU (больше времени будет тратится на поддержание управляющего уровня). Правильным инструментом для этого сценария, скорее всего, является BFD, потому что он обеспечивает быструю конвергенцию L3, но более устойчивым способом. В любом случае, вам не придется беспокоиться о внедрении технологии на сетевых платформах Cisco для предприятий.

Вам не обязательно проводить работу с технологиями, но это настоятельно рекомендуется. Это больше подходит для людей, переходящих от CCNA и к ENSLD. То, что вам не нужно внедрять или применять технологии для этого экзамена, не означает, что вы не должны над ними работать. Проще сохранить информацию и повысить доверие к экзамену, если вы знакомы с той или иной технологией и ее причудами. Я ни в коем случае не рекомендую вам фокусироваться на запоминании команд CLI, но, возможно, стоит поработать над тем, чтобы изучить, как различные протоколы взаимодействуют друг с другом. Например, знаете ли вы наверняка, как Layer 2 может влиять на переадресацию Layer 3? Как несовместимый мануальный транкинг может повлиять на другие протоколы, такие как VTP и STP? Стоит ли применять MST поверх Rapid PVST+ для небольших сайтов? Если да, то с какими административными расходами вы столкнетесь при выборе этого маршрута? Как SD-WAN vBond поддерживает обход NAT? Все это примеры того, как вы можете надеть техническую шляпу и поиграть с технологиями, что поможет вам ответить на вопросы, связанные с проектированием.

Я мог бы набрать 950+, если бы лучше распределил мое время...

Осмысление моего путешествия

Я проходил Cisco Certified Specialist: Enterprise Design certification (ENSLD) для подготовки к экзамену CCIE Enterprise Infrastructure, в частности, к 3-часовой части, посвященной проектированию. Мое отношение к этой сертификации специалиста заключалось в выявлении слабых мест, которыми я обладаю в области проектирования сетей, и получении "вкуса" того, как Cisco любит оценивать концепции проектирования сетей.

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

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

Самой большой ошибкой, которую я совершил при подготовке к этому экзамену, было то, что я слишком быстро освоил технические аспекты обучения. Я должен был в первую очередь сосредоточиться на концепциях проектирования и проблемах, и при необходимости изучать замысловатые детали некоторых протоколов (cough, multicast flavours, cough). Подготовка к экзаменам была излишне сложной и напряженной из-за чрезмерно сложной учебы. Я потратил 80 часов на подготовку к этому экзамену и чувствовал, что мог бы сократить это время в половину, если бы подошел к нему с правильным настроем с первого дня. Я счастлив завершить учебу на ENSLD, теперь зная, как я буду подготавливаться к экзамену the CCIE Enterprise Infrastructure lab по проектированию компонентов, и еще зная, на каких аспектах проектирования сети мне нужно фокусироваться для успешного продвижения вперед.

Узнать подробнее о курсе Дизайн сетей ЦОД.

Смотреть вебинар Эволюция сетевых технологий в ЦОД.

Подробнее..

Категории: Цод , Сетевые технологии , Карьера в it-индустрии , Ethernet , Блог компании otus , Дизайн сети

Часто задаваемые вопросы про Huawei FusionModule2000

08.05.2021 02:17:45 |

Автор: admin

Описание

Huawei FusionModule2000 - интеллектуальный модульный центр обработки данных нового поколения, созданный специально для того, чтобы предоставить заказчикам простое, эффективное и надежное решение для ЦОД. Huawei FusionModule2000 первым в мире получил сертификацию уровня Tier IV Ready от Uptime Institute: он соответствует самым высоким требованиям к доступности.

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

Часто задаваемые вопросы

Вопрос: Каким образом выполняется прокладка кабелей для сильных и слабых токов в FusionModule2000?

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

Ответ: Да. ИБП можно разместить в одном отделении с сервером. В большинстве случаев ИБП занимает не очень много места. Если мощность ИБП превышает 600 кВ-А, его следует разместить в отдельном помещении (необходимо учитывать концентрацию токсичных веществ, выделяемых аккумуляторами, таких как водород и сероводород).
Вопрос: Модульные ЦОД Huawei поддерживают горизонтальный воздушный поток. Можно ли использовать режим с нисходящим воздушным потоком?

Ответ: В режиме нисходящего воздушного потока поддерживается низкая удельная мощность (3-5 кВт на стойку). В горизонтальном режиме поддерживаются более высокие значения (решения Huawei поддерживают до 21 кВт на стойку), что позволяет удовлетворять требования различных сценариев к удельной мощности. Существует тенденция к увеличению удельной мощности и степени интеграции. Таким образом, режим горизонтального воздушного потока соответствует будущим потребностям.
Вопрос: Какие типы кондиционеров можно использовать в модульных центрах обработки данных? Как обеспечить безопасность кондиционеров с водяным охлаждением?

Ответ: Поддерживаются кондиционеры как с воздушным, так и с водяным (внутрирядные) охлаждением. Меры обеспечения безопасности для кондиционеров с водяным охлаждением: 1 - Если используется фальшпол, трубы подачи охлажденной воды можно проложить под полом; в противном случае такие трубы следует прокладывать с верхней части коридора и обеспечить их физическую изоляцию. 2 - Для труб необходимо обеспечить теплоизоляцию. 3 - Сбор и отвод конденсата кондиционеры выполняют автоматически.
Вопрос: Каковы отличия и преимущества внутрирядного охлаждения по сравнению с традиционным режимом нисходящего воздушного потока?

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

Ответ: Изготовление модульного ЦОД занимает 8-12 недель, а установка и ввод в эксплуатацию 1-2 недели.
Вопрос: Какое количество шкафов поддерживает модульный цод?

Ответ: В соответствии с требованиями противопожарной защиты при строительстве, в коридоре длиной более 15 метров необходимо установить дверь. Поэтому максимальная длина модуля Цод не может превышать 15 метров. Таким образом, в коридоре можно разместить не более 24 шкафов шириной 600 мм (до 48 шкафов в двухрядной конфигурации).
Вопрос: Какие внешние установки необходимы для использования модульного ЦОД? Могут ли специалисты Huawei помочь с их подбором?

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

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

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

Ответ: Система управления NetEco предоставляет веб-интерфейс, поддерживающий одновременный вход нескольких пользователей. Для входа в систему и управления ЦОД можно использовать браузер Internet Explorer 11.
Вопрос: Можно ли использовать систему управления NetEco для обслуживания ЦОД, в которых нет оборудования Huawei?

Ответ: Да. Система управления центром обработки данных Huawei NetEco совместима с оборудованием различных поставщиков.

Спасибо!

Пожалуйста, ставьте лайк, если этот пост Вам понравился) Для более подробной информации, об оборудовании Huawei, приглашаем Вас на форум: Huawei ICT Club, ждём Вас в гости)

А если, Вы ещё, захотите оставить комментарий, то: "Как Вы думаете, для каких предприятий подойдёт FusionModule2000?"

Подробнее..

Категории: Цод , Блог компании huawei , Huawei , Чзв , Fusionmodule2000

	Русский
	English

Цод

Что это за бомбоубежище?

Что нужно было сделать

Оптика

Серверы

Итого

Мониторинг

Бизнес-модель с минимальными издержками

Открытие нового ЦОДа

Работа с юрлицами

Пока всё

Active/Standby

Active/Active

Ничто не предвещало беды

Не ищем легких путей

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

Часть II. Энергетическая безопасность

Часть III. Климатическая безопасность

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

Часть V. Эксплуатационная безопасность

Часть VI. Дополнительный рубеж защиты

Часть VII. Заключение: вишенка на торте

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

Из истории

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

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

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

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

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

Мониторинг

Телеком

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

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

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

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

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

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

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

Знакомство с Cumulus Linux. Установка оборудования и первоначальная настройка

Нет лицензии нет портов

Система commitов

Первая топология

Основные команды для заинтересованных

Заключение

Готовимся

Стартуем

Что и как тестируем

Финальный рывок

О технических параметрах Dorado V6

Почему выбрана именно Dorado 3000 V6?

Коротко о стенде для тестирования

HyperSnap

HyperCDP

HyperClone

SmartQOS

Подведение итогов для первой части

Хорошая подготовка половина успеха

Три. Начинаем разбирать

Два. Переезжаем

Один. Собираем и запускаем

Можно ли успеть за 24 часа?

Драгоценная мораль

Содержание

Предварительные требования к экзамену

Бесплатные ресурсы для обучения

Комментарий по ресурсам Cisco

Ресурсы, созданные сообществом

Платные ресурсы

Официальные учебные материалы CISCO

Комментарий по платным учебным материалам

Впечатления от экзамена

Совет по экзамену

Осмысление моего путешествия

Описание

Часто задаваемые вопросы

Категории

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