Привет, Хабр! Меня зовут Антон Клочков, я сетевой архитектор в компании DataLine, а также участник проекта linkmeup. Я занимаюсь сетями более 10 лет и за это время успел поработать в больших и маленьких телеком-операторах, крупных корпорациях и небольших бизнесах. 

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

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

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

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

Теперь умножим количество залов на десять. Появились вопросы логистики. На каком складе что хранить, чтобы не бегать за каждой запчастью? Как вовремя пополнять запасы, чтобы внеплановый ремонт не застал врасплох? Если оборудования много, держать все технические работы в голове невозможно, а на бумаге – сложно. Тут на помощь приходит MMS, или maintenance management system, – система управления техническим обслуживанием оборудования (ТО). 


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

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

Мы уже рассказали, как описывать конфигурацию в Desired State Configuration (DSC) и разобрали встроенный агент Local Configuration Manager (LCM) для применения конфигурации на сервере. В первой части статьи пошагово прошлись по основным особенностям инструмента вместе с Евгением Парфеновым из DataLine.

Здесь же погрузимся в настройку и особенности работы в режимах Push и Pull.

О чём расскажем:

1. Различия режимов Push и Pull
2. Push-режим в деталях
3. Pull-режим в деталях

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

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

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

Что будем делать:

1. Установим OpenLDAP и настроим на нем поддержку STARTTLS. 
2. Опишем структуру LDAP-каталога нашей организации.
3. Включим поддержку OIDC (OpenID Connect) на kube-api-серверах.
   
4. Получим SAN-сертификат для доменов, которые будет использовать Dex.
5. Установим Dex и Dex-auth, где мы опишем LDAP-каталог и статических пользователей. 
6. Сгенерируем kubeconfig нашего пользователя для работы с кластером.
7. Настроим RBAC-авторизацию для групп и пользователей в кластере.

Итак, поехали.



Показывать буду на примере уже готового кластера Kubernetes с Helm версии 3 и Ingress, а также тремя доменными именами.

Привет! В прошлом посте я рассказал о возможностях VMware vCloud Availability (vCAV) и показал, как организовать Disaster Recovery (DR) и миграцию в рамках нескольких площадок облачного провайдера. Сегодня посмотрим, как с помощью vCAV восстановиться или просто смигрировать в облако сервис-провайдера с on-premise-площадки. В нашем примере будем настраивать DR с локальной площадки заказчика в облако в СПб. 



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

Для удобства сделал быструю навигацию по инструкции:

• установка и настройка vCloud Availability Appliance for Tenants;
  
• создание DR-задания;
  
• тестовое восстановление;
  
• аварийное переключение между площадками.
  
• обратное переключение.
  

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

В начале февраля наш самый большой дата-центр Tier III NORD-4 прошел повторную сертификацию Uptime institute (UI) по стандарту Operational Sustainability. Сегодня расскажем, на что смотрят аудиторы и с какими результатами мы финишировали.

Для тех, кто с дата-центрами на «вы», кратко пройдемся по матчасти. Tier Standards оценивает и сертифицирует дата-центры на трех этапах:

• проект (Dеsign): проверяется пакет проектной документации.Тут как раз присваиваются всем известные Tier. Всего их 4: Tier I–IV. Последний, соответственно, самый высокий.
  
• построенный объект (Facility): проверяется инженерная инфраструктура дата-центра и ее соответствие проекту. Дата-центр проверяют под полной проектной загрузкой с помощью множества тестов примерно такого содержания: один из ИБП (ДГУ, чиллеров, прецизионных кондиционеров, распределительных шкафов, шинопроводов и т.п.) выводится из эксплуатации на обслуживание или ремонт, при этом отключается городское энергоснабжение. ЦОД уровня Tier III и выше должен справиться с ситуацией без каких-либо последствий для полезной ИТ-нагрузки.
  
  Facility можно сдавать, если дата-центр уже прошел сертификацию Dеsign.
  NORD-4 получил свой сертификат Design в 2015 году, а Facility —  в 2016.
  
• эксплуатация (Operational Sustainability). По сути, самая главная и сложная сертификация. Она в комплексе оценивает процессы и компетенции оператора по обслуживанию и управлению дата-центром с установленным уровнем Tier (чтобы сдать Operational Sustainability, вы уже должны иметь сертификат Facility). Ведь без правильно выстроенных процессов эксплуатации и квалифицированной команды даже дата-центр Tier IV может превратиться в бесполезное здание с очень дорогим оборудованием.
  

InfiniBox – модерновая система хранения, сразу попавшая в правую часть магического квадрата. В чем ее уникальность?

Краткая предыстория

Что такое InfiniBox? Это система хранения компании Infinidat. Что такое компания Infinidat? Это компания, созданная Моше Янаем (создатель Symmetrix и XIV) для реализации проекта идеальной СХД Enterprise-уровня.

Компания создана как разработчик ПО, которое ставится на проверенное оборудование, то есть это SDS, но поставляется как единый монолитный комплект.

Введение

В этой статье мы рассмотрим систему хранения InfiniBox, ее архитектуру, как она работает и как достигается высокая надежность (99,99999%), производительность, емкость при сравнительно невысокой цене. Поскольку основа системы хранения — это ее ПО, а для этой системы в особенности, то основной упор будет именно на софте, красивых фото железок не будет.

Зачем нужна еще одна система хранения на рынке?

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

В прошлом посте про PDU мы говорили, что в некоторых стойках установлен АВР —  автоматический ввод резерва. Но на самом деле в ЦОДе АВР ставят не только в стойке, но и на всем пути электричества. В разных местах они решают разные задачи:

• в главных распределительных щитах (ГРЩ) АВР переключает нагрузку между вводом от города и резервным питанием от дизель-генераторных установок (ДГУ); 
  
• в источниках бесперебойного питания (ИБП) АВР переключает нагрузку с основного ввода на байпас (об этом чуть ниже); 
  
• в стойках АВР переключает нагрузку с одного ввода на другой в случае возникновения проблем с одним из вводов. 
  

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

О том, какие АВР и где используются, и поговорим сегодня. 

Всем привет!

Сегодня речь пойдет о работе с VMware vCloud Availability (vCAV). Этот продукт помогает организовать Disaster Recovery (DR) и миграцию в рамках нескольких площадок облачного провайдера или переехать/восстановиться в облако сервис-провайдера с on-premise площадок. vCAV встроен в панель vCloud Director, что позволяет клиентам публичных облаков самостоятельно управлять DR и миграцией своих виртуальных машин из привычного интерфейса.

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

Привет, Хабр!

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


СХД катастрофоустойчивого облака на площадке OST.

Осенью 2019 года Check Point прекратил поддержку версий R77.XX, и нужно было обновляться. О разнице между версиями, плюсах и минусах перехода на R80 сказано уже немало. Давайте лучше поговорим о том, как, собственно, обновить виртуальные appliance Check Point (CloudGuard for VMware ESXi, Hyper-V, KVM Gateway NGTP) и что может пойти не так.

Итак, у нас было 2 инженера CCSE, более десятка виртуальных кластеров Check Point R77.30, несколько облаков, немножечко хотфиксов и целое море разнообразных багов, глюков и всего такого, всех цветов и размеров, а еще очень сжатые сроки. Погнали!

Содержание:

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

Так выглядит типичная облачная инфраструктура клиента с виртуальным Check Point

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

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

Такие вакансии можно всячески порицать, но факт остается фактом: их много, и так устроен рынок на данный момент. Мы сделали девопс-конференцию и открыто заявляем: «DevOops — не для DevOps-инженеров». Тут многим покажется странным и диким: почему люди, делающие совершенно коммерческое мероприятие, идут против рынка. Сейчас всё объясним.