Привет, Хабр! Меня зовут Евгений Мартынов, я директор по информационным технологиям в Рег.ру. В декабре 2024 года мы запустили сервис объектного хранилища S3, построенный на Ceph. Тогда это был MVP с минимально необходимым функционалом — сейчас мы вышли из беты, добавили ключевые возможности, расширили хранилище и накопили первые 130+ ТБ пользовательских данных.

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

Во 2 части этой серии мы рассмотрели практическое развертывание кластера Ceph на двух площадках с отдельной tie-breaker локацией, с использованием пользовательского файла спецификации для компонентов Ceph, CRUSH-правил и мест размещения компонентов.

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

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

В этой статье поговорю о том, как компании выбирают системы хранения данных. Кто-то строит IT-инфраструктуру на классических аппаратных СХД, а кто-то уходит в кластерные решения на базе Ceph и других open-source решений. Сравню подходы и покажу, в чем плюсы и минусы каждого из них. Также поделюсь практическими кейсами переноса кластеров SSD на гибрид и добавления Ceph смешанного пула. 

Продолжаем серию статей о растянутом кластере Ceph. В первой части мы представили концепции, лежащие в основе стратегий репликации Ceph и подчеркнули преимущества растянутого кластера для достижения нулевой потери данных (RPO=0).

Во второй части мы сосредоточимся на практических шагах — развертывании растянутого кластера на двух локациях + монитора в качестве tie-breaker с использованием cephadm.

Привет, Хабр! На связи вновь Кирилл Савин, архитектор SDN в Облаке Рег.ру. Недавно мы с командой взвесили все риски и приняли волевое решение — переехать на OVN. В процессе думали над архитектурой, решали возникающие вопросы и набивали шишки. Я решил поделиться нашим опытом и подходами.

В первой статье рассказали, как устроен OVN изнутри, рассмотрели особенности архитектуры. Теперь готовы перейти к практике! Во второй части опишу ручной подход для миграции облака с сетевым даунтаймом для перестроения сети, но без миграции, собственно, виртуальных машин. Для «переезда» я осознанно выбрал ручной подход — объясню, почему и что из этого получилось. Внутри — по шагам рассказываю о переезде и делюсь полезными конфигурациями, которые делают это возможным.

Привет, Хабр! На связи Кирилл Савин, я — архитектор SDN в Облаке Рег.ру. Недавно мы с командой начали большой переезд OpenStack облака на OVN, который идет и сейчас. Это непростое путешествие, в котором мы пробовали разные решения, извлекали уроки из ошибок и продолжали двигаться вперед. Так появилась идея рассказать о рабочих кейсах и идеях, которые мы почерпнули. 

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

При планировании репликации, аварийного восстановления, резервного копирования и восстановления данных мы выбираем из нескольких стратегий — в зависимости от требований к уровню SLA по восстановлению данных и приложений. Ключевые факторы при выборе включают в себя целевое время восстановления (RTO) и целевую точку восстановления (RPO). Синхронная репликация дает минимальную RPO, что означает невозможность потери данных. Ceph может реализовать синхронную репликацию между локациями, «растянув» свой кластер на несколько дата-центров.  

Асинхронная репликация по своей сути подразумевает ненулевое значение RPO. В Ceph асинхронная multi-site репликация подразумевает репликацию данных в другой кластер Ceph. Каждый метод доступа к хранилищу (объект, блок и файл) обладает собственным методом асинхронной репликации, реализованным на уровне конкретного компонента Ceph.

Облако — большой и сложный продукт, поэтому и процесс тестирования может растянуться… Всем привет! На связи Галина Чупрова, главный инженер по тестированию Облака Рег.ру. В какой-то момент мы с командой поняли, что чем раньше начать тестирование — тем меньше багов получим на выходе. В статье расскажу про этапы, которые помогут устранить «узкие горлышки» в процессе проверки качества продукта и подключить команду с первых шагов проекта. Будет полезно тем, кто начинает путь в тестировании или хочет по-новому взглянуть на процессы в своих командах. Поехали проходить этот квест!

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

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

Привет, Хабр! Меня зовут Владимир Раду, я Backend-разработчик в Рунити. Однажды мы с командой встали перед дилеммой: как навести порядок внутри монолита. Админка одного из сайтов нашей группы компаний — большой и довольно возрастной проект. Он охватывает множество задач и сценариев: от управления ценами до редактирования контента. Со временем стало очевидно, что нужно снижать связанность компонентов и разводить бизнес-части. Так появилась идея перейти к модульной архитектуре.

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

Вопрос: Можно ли за пару минут «на коленке» создать свою криптографическую хеш-функцию? Чтобы в результате было не подобрать входную строку? Ответ: Можно!

Привет, Хабр! На связи Игорь Батулин — руководитель группы разработки виртуального хостинга в Рунити. Когда-то с удовольствием прочитав книгу «Грокаем алгоритмы» Адитья Бхаргавы, с удивлением обнаружил, что автор не привел пример криптографической хеш-функции. Но стиль подачи материала очень напомнил мне то, как я рассказывал об этом студентам-экономистам во времена преподавания в вузе — просто и наглядно.

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

Привет, Хабр! Меня зовут Никита Ли, я Frontend-разработчик в группе Рунити. Так тяжело бывает удержаться от того, чтобы не усложнить себе жизнь, не так ли? Все любят смотреть на чистый и понятный код, но не все его таким пишут. Сделать его таким помогают наши друзья — форматировщики и линтеры. О них и пойдет речь в этой статье, а конкретно о ESLint Stylistic.

Любой автор хочет, чтобы его кто-то читал, даже на JavaScript, но просматривать читателю хочется грамотный и красивый текст. ESLint анализирует код, выявляя ошибки, чтобы программы выходили из под клавиатуры чистыми и без ошибок. Prettier, в свою очередь, как инструмент форматирования делает текст исходного кода программ единообразным. Оба этих инструмента являются практически стандартом, когда речь заходит о качестве кода. Думаю, что многие сталкивались в проектах с их одновременным применением, что в целом логично — форматирование != линтинг. Однако это решение не всегда обосновано, а зачастую излишне. В качестве альтернативы я предлагаю рассмотреть ESLint Stylistic. В этой статье разберемся, что это, откуда появился инструмент и почему с ним стоит познакомиться.

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

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

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

Привет, Хабр! Меня зовут Игорь Шишкин, я руковожу командой R&D в облачном направлении Рег.ру и являюсь архитектором наших сервисов — в этой статье расскажу, как мы создавали бэкапы в облаке. Далее о том, как выбирали инструменты для реализации, строили архитектуру и что мы делаем, когда пользователи устраивают тот еще квест — дружно решают забэкапиться в одно время.

Привет, Хабр! Меня зовут Анатолий Усов, я инженер дата-центра Рег.ру. В этой статье расскажу, чем обычно занимается инженер в ЦОДе в течение смены, с какими сложностями сталкиваемся и как устроена работа внутри нашего дата-центра.

Привет, Хабр! Мы в Рунити верим, что собеседование — не гонка за правильными ответами, а диалог на равных. В этом интервью расскажем, как мы нанимаем DevOps-инженеров в команду. Внутри о том, что мы предлагаем кандидатам вместо стресс-интервью, замысловатых тестовых и бесконечных этапов отбора. От нас — внимание к глубине опыта и интерес к подходам кандидата. 

Эксперты Рунити — Анна Попова, рекрутмент-партнер, и Тимур Парфенов, директор департамента эксплуатации, поделятся тем, как мы оцениваем инженеров, на что смотрим в резюме и какие навыки стоит подсветить. Приятного «разворачивания» статьи! 

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

С каждым новым спринтом кажется, что ты просто двигаешь тикеты по доске?
Не только тебе. Когда задачи теряют смысл, проект буксует, а мотивация тает где-то между дейликом и очередными «небольшими изменениями — вот здесь, здесь и здесь», возникает закономерный вопрос: где же те самые большие задачи, в которых хочется быть? Где простор для роста, свободы и влияния?

Если честно, мы знаем ответ. Но ведь так неинтересно! Поэтому мы нарисовали комикс о том, как карьерный тупик трёх IT-специалистов — разработчика, аналитика и DevOps-инженера — внезапно превращается в портал, за которым их ждут испытания: Legacy-Хаос, техдолг и поток данных, грозящий поглотить всё живое. Чтобы пройти их, героям понадобятся не суперсилы, а кое-что куда важнее: автоматизация, гибкие подходы и возможность делать то, что имеет значение. Погружаемся в комикс — и проверим, что будет, если карьерным мечтам действительно дать пространство для развития.

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

Привет, Хабр! Меня зовут Игорь Батулин, я руководитель группы разработки виртуального хостинга в Рунити. Эта статья — не просто рассказ о том, как я люблю рогейн, а пример того, как можно за несколько итераций и в условиях ограниченных ресурсов создать полезный инструмент, действительно помогающий команде принимать решения. Мой рассказ также подскажет, как можно применять Agile-подходы в реальных задачах.