Наш ЦОД «Медведково», о котором мы уже рассказывали, в 2024 году стал кластером, так как рядом был построен еще один дата-центр — «Медведково-2». В этой статье мы покажем, как устроен новый ЦОД.

Здание «Медведково-2» возвели за год, параллельно проводили интеграцию инженерных систем. К 2024 году ЦОД полностью подготовили для проведения аудита и сертификации. Дата-центр успешно прошел испытания Uptime Facility и получил сертификат Tier III.

Выкатили новый проект. База — на PostgreSQL. Все работает. DBA в штате нет, база крутится на виртуалке, обновления никто не трогал, мониторинга нет. И вот ночь, все падает. Начинается экстренный чат, поиск багов, попытки восстановиться из бэкапа… если он вообще был.

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

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

Недавно мы обновили BareMetal 2.0 в составе нашего «Публичного облака». Теперь в инфраструктуре есть выделенные физические серверы с высокопроизводительными GPU-картами. Они позволяют работать с задачами, где критична скорость вычислений.

Расскажем, что именно изменилось и какие задачи можно теперь решать быстрее.

Привет, Хабр! Я Роман Лысенко, начальник отдела систем резервного копирования в РТК-ЦОД. Четыре года назад я пришел в РТК-ЦОД специалистом 1-й линии ТП. Через два года я стал работать уже в отделе СРК, но с теплом вспоминаю период в техподдержке.

Такое начало карьеры — один из самых естественных и эффективных способов роста в IT. Многие молодые айтишники могут сомневаться в этом, задаваясь вопросом: «Зачем начинать с техподдержки, если можно сразу выбрать более интересные и высокооплачиваемые роли?» Для того чтобы разрушить основные мифы и стереотипы о работе в техподдержке и рассказать подробнее о профессии, я решил написать эту статью.

Привет! Меня зовут Олег Рябов, я главный эксперт Управления исследований и разработок новых решений компании «Ростелеком-ЦОД» и автор программы и методики испытаний (ПМИ) серверов.

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

Привет, меня зовут Александр, я руковожу Управлением исследований и разработки новых решений в «Ростелеком-ЦОД», если коротко — лабораторией R&D.

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

Меня зовут Андрей, я работаю в группе резервного копирования в компании «Ростелеком-ЦОД». Мы отвечаем за хранение и целостность резервных копий наших клиентов и поддержку инфраструктуры РК в оптимальном состоянии. В этой статье я хочу рассказать о том, как мы смогли значительно упростить мониторинг статуса заданий в системе резервного копирования Veeam, создав мощный инструмент на основе Grafana. Этот инструмент позволяет нам получать ценные метрики и статистику о производительности и состоянии нашей инфраструктуры резервного копирования.

Мы открыли новый дата-центр «Ростелеком-ЦОД» в Медведково. Строительство началось в июле 2022 года на базе складского комплекса класса А+, первый этап был реализован за 9 месяцев.

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

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

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

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

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

Миграция базы данных 1С с MS SQL на PostgreSQL – по-прежнему насущная тема, особенно в контексте импортозамещения. На наших вебинарах и в беседах с клиентами мы получаем много вопросов по нюансам миграции. Решили собрать основные рекомендации в одну статью.

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

В фоторепортаже из Новосибирска посмотрим, как работает дата-центр сегодня.

Я работаю в центре киберзащиты DataLine и в числе прочего занимаюсь межсетевыми экранами нового поколения (NGFW): тестирую новые решения, внедряю, настраиваю, слежу за работоспособностью. 

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

С этой мыслью мы запустили тесты производительности отечественного UTM UserGate в интересном контексте: мы подняли версию UserGate на программно-аппаратном комплексе от зарубежного вендора NGFW. В статье поделюсь сценариями тестирования и покажу результаты на одном популярном устройстве. При желании такие же тесты можно прогнать на любом другом оборудовании.

В крупных компаниях с развитой ИТ-инфраструктурой нередко есть отдельная роль DBA — администратора или архитектора баз данных. Таким компаниям бывает выгоднее держать базы данных у себя и администрировать ресурсы своими силами.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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