Итак, вы наконец-то стали счастливым обладателем k8s-кластера: получили его в наследство, в подарок на Новый год, заказали в DataLine) и т. п. У новых клиентов и даже у опытных пользователей часто возникает вопрос, как оценить кластер и проверить его работоспособность? 

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

Привет, Хабр! Меня зовут Даниил Воложинок, я инженер в группе виртуализации. Представьте себе ситуацию. У вас есть сервер с комплексом приложений и настроек, который несколько лет обслуживает админ — ”золотые руки”. Однажды “золотой” админ увольняется или уходит на длительный больничный. На его смену приходит новый и выясняет, что разобраться в наследстве невозможно: большинство сведений его предшественник держал в голове. 

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

В статье поделюсь наработанным списком для документирования сервера, который мы собрали внутри компании и теперь высылаем в качестве рекомендации и крупным клиентам DataLine, и небольшим клиентам Cloudlite. Ресурсы Cloudlite нередко используются для стартапов и pet-проектов. А когда стартап вдруг резко взлетает, становится некогда думать о документировании. Так что привычка сразу все фиксировать помогает нашим клиентам не запутаться. 

В ноябре Nature опубликовал работу учёных Женевского университета (UNIGE) и канадского Университета Макгилла, которые решили заменить привычную систему PIN-кодов на более безопасную. В поисках сверхнадежной аутентификации исследователи предложили пересмотреть фактор владения и опираться на метод математического доказательства с нулевым разглашением в связке со специальной теорией относительности. 

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

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

- какие есть варианты для связи независимых дата-центров по России;

- какие трудности появляются на больших расстояниях и как их преодолеть;

- где между телеком-операторами возникают серые зоны, за которые никто не отвечает.

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

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

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

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

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

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

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

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

Привет! На связи Алексей Волков, и я опять про «Сервисдеск» в DataLine. На сей раз покажу его мобильную реинкарнацию.

Три года назад мы создали десктопную систему для работы с заявками в техподдержку и дали ей говорящее название «Сервисдеск». Сейчас это решение работает во всех дата-центрах объединенной команды DataLine и «Ростелеком-ЦОД» и охватывает около 700 ежедневно активных пользователей. Мобильная версия «Сервисдеска» была лишь вопросом времени: доступность любых внутренних систем с портативных устройств сразу ускоряет цикл обработки запросов. А для клиентских заявок в техподдержку это особенно важно.

Под катом — краткая предыстория разработки мобильного клиента для «Сервисдеска» и демонстрация сценариев его работы.

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

В прошлом году наша сеть дата-центров расширилась: команды «Ростелеком-ЦОД» и DataLine объединились, да еще и начали вместе строить новые ЦОДы. К московским площадкам добавились региональные: в Удомле, Санкт-Петербурге, Екатеринбурге, Новосибирске. Стало важно выстроить единую систему обучения дежурных, при этом сохранить гибкость и учесть особенности подготовки на местах.

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

Hystax — подходящее решение для миграции, если нужно перенести ВМ с Linux или Windows между разными платформами: VMware, OpenStack, AWS и так далее. C его помощью можно переехать на любую из этих платформ даже с bare-metal. Мы уже не раз использовали Hystax для переезда наших клиентов с VMware в OpenStack. Также Hystax можно использовать для послеаварийного восстановления (DR).

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

В статье расскажу, где настройки могут не подняться автоматически и как с этим бороться. Показывать буду на версии Hystax DR 3.7.1701.

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

Vault от HashiСorp — довольно известное open-source-решение для хранения секретов и неплохая альтернатива реализации секретов в Kubernetes. Vault использует свой сайдкар-контейнер на каждом поде, который получает секреты из хранилища и доставляет их в под или же реализует доступ к секретам через csi-драйвер.

Но как быть, если необходимо положить секреты из Vault в секреты Kubernetes? Например, мы хотим хранить и обновлять свой tls-сертификат для ингресса из Vault. Или мы решили использовать gitops и хотим, чтобы в репозитории безопасно хранилось все описание инфраструктуры, в том числе и секретов Kubernetes?

Разберем этот сценарий на практике и реализуем его с помощью vault-secrets-operator.

В этом году мы обновили сервис облачного мониторинга и представили клиентам более удобное и понятное решение для отслеживания статуса их ИТ-инфраструктуры. Сервис вырос из нашей системы мониторинга дата-центра, где мы отслеживаем сотни тысяч метрик в работе оборудования. Какие-то из них очевидные, а какие-то вызывают у клиентов реакцию: “А что, так можно было?!”

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

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

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

Где кончается базовая ИБ-гигиена для небольшого бизнеса и начинается киберзащита для продвинутых? Центр интернет-безопасности (CIS) обновил рекомендации по внедрению ИБ для компаний разного масштаба в свежем гайде CIS Controls 8.

Предыдущие рекомендации CIS Controls 7.1 вышли в 2019 году. В версии 7.1 сделали упор на список практик для внедрения: что именно бизнес должен сделать для защиты. В восьмой версии этот подход сохранили и учли угрозы, связанные с “пандемийными” изменениями ИТ-ландшафта: массовой работой из дома, ростом мобильных пользователей, миграцией в облака. Например, появился отдельный раздел ― контроль безопасности сервис-провайдера (мимо такого пройти не cмогли). 

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

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

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

Уже 7 лет я занимаюсь в DataLine искусством capacity-менеджмента — управляю основными ресурсами дата-центра. Проще говоря, обеспечиваю каждому клиенту необходимое и достаточное место, электричество и холод для решения его задач. Мы уже рассказывали, как ведем статистику по потреблению оборудования и определяем стандартную мощность. Но что насчет самих стоек, которые отвечают за место?

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

Эта статья — итог нашего эфира в Телеграме. Можно заодно послушать запись эфира в Салатовой телеге.     

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

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

Когда клиент размещает свой сайт, почту или другой сервис в нашем облаке на базе VMware, то в 90% случаев в качестве граничного устройства используется виртуальный маршрутизатор NSX Edge. Это решение выполняет для виртуального дата-центра функции межсетевого экрана, NAT, DHCP, VPN и так далее.

Но если, например, клиент привык получать на межсетевом экране расширенную аналитику по трафику и более детальный мониторинг, то в облаке ему может понадобиться межсетевой экран нового поколения (Next Generation Firewall, NGFW). К тому же, такие решения предоставляют модули IPS и IDS, антивирус и другие фишки. Для клиентов c такими запросами в качестве одного из решений мы предлагаем NGFW как сервис на базе FortiGate. В статье покажу, как и для чего мы организуем переезд в этот сервис.

(Если позвать грузчиков за бутылку, может получиться вот так)

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

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

Привет, Хабр! Меня зовут Сергей, и в DataLine я занимаюсь совершенствованием систем мониторинга. Мы уже много рассказывали про мониторинг инженерной и сетевой инфраструктуры. Но помимо него есть еще и задача отслеживания ИТ-оборудования. 

Когда мы осуществляем мониторинг в дата-центре, важно знать, где находится каждый сервер и кому он принадлежит. Эта информация хранится в специальной системе для учета компонентов информационных систем, или Configuration management database (CMDB). Важно сразу обновлять данные по местонахождению серверов, иначе возникает проблема “серверов-призраков”, за которые никто не отвечает. 

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