«‎Не могу поверить, что они догадались до этого первыми». Именно такая мысль пронеслась у меня в голове в середине декабря после нескольких недель работы по 12 часов в день, когда я отлаживал причины медленной работы кластера. Это был, пожалуй, самый интенсивный анализ производительности, который я проводил со времен Inktank. 

В моем сознании промелькнули полузабытые суеверия из 90-х о том, как получить благосклонность богов SCSI. 90-х? Блин, я старею. Мы прошли примерно две трети пути, который позволил бы нам начать с самого начала. Кстати говоря, я начну с самого начала.

В 2023 (я почти написал «в начале года», пока не вспомнил, что уже 2024) году в компанию Clyso обратилась довольно популярная и передовая компания, которая хотела перевести свой Ceph-кластер с HDD на NVMe-диски объемом 10 петабайт. Они сразу же заинтересовали нас. У них не было особых потребностей в RBD, RGW или CephFS. У них было свое представление, о том какое оборудование необходимо, но, к моей радости, обратились к нам, прежде чем что-то покупать. 

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

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

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

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

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

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

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

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

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

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

Введение

Под Новый Год мы с женой пересматриваем одну популярную магическую сагу — хочется знаете ли в жизни волшебства. В IT волшебства тоже хватает — от танцев с бубнами до самых современных технологий, принцип работы которых проще объяснить тёмной магией. Так, например, бытует мнение, что настройка service mesh — это магия, подвластная лишь волшебникам DevOps. Но у нас в Альфа-Банке разработчики исторически не маглы, а, как минимум, полукровки, поэтому имеют право приобщиться к волшебному миру.

В этой серии статей я хочу поделиться опытом изучения технологии service mesh, а именно Istio, на примере практической задачи, возникшей какое то время назад в одной из систем Альфа Банка, системным архитектором которой я являюсь.

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

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

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

Мы упёрлись в то, что в документации Keycloak описано как создать кластер используя UDP мультикаст. И это работает, если у вас все ноды будут находиться в пределах одного сегмента сети (например ЦОДа). Если с этим сегментом что‑то случится, то мы лишимся Keycloak. Нас это не устраивало.

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

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

Бонусом приложу shell скрипт, написанный для Consul, который предназначен для снятия анонсов путём выключения bird и попытки восстановления приложения.

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

Введение

Я делала много вещей с компьютерами, но в моих знаниях всегда был пробел: что конкретно происходит при запуске программы на компьютере? Я думала об этом пробеле — у меня было много низкоуровневых знаний, но не было цельной картины. Программы действительно выполняются прямо в центральном процессоре (central processing unit, CPU)? Я использовала системные вызовы (syscalls), но как они работают? Чем они являются на самом деле? Как несколько программ выполняются одновременно?

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

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

Более удобный формат статьи.

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

Что конкретно разберём:

— расчёт количества консьюмеров по формуле Эрланга;

— шардирование — различные способы балансировки;

— дедупликацию сообщений в очереди;

— многоуровневую очередь повторных попыток;

— приоритеты сообщений.

Думаю, как и я, очень многие задавались вопросом: «Почему несмотря на хорошее образование, любознательность, способности и трудолюбие, они зарабатывают меньше, чем им хочется. Где баг, который мешает зарабатывать больше?»

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

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

Мы будем рассматривать только файлы кучи (heap). Heap-файл — это просто файл записей. Не путайте heap-файл с heap-памятью. Хотя их использование очень похоже: хранение динамических данных.

Привет, Хабр! На связи СберТех — мы создаём Platform V, цифровую платформу Сбера для разработки бизнес-приложений.

В платформу входит более 60 продуктов на базе собственных сборок open source, доработанных до уровня enterprise по функциональности, безопасности, производительности и отказоустойчивости.

В этой статье расскажем про реализацию паттерна Change Data Capture и межкластерной репликации данных в продукте Platform V DataGrid, распределённой in-memory базе данных для высокопроизводительных вычислений. А также об особенностях внедрения функции и вариантах репликации. Написать материал помог наш коллега Николай Ижиков из команды по развитию баз данных на стеке open source.

Меня зовут Сергей Петренко, вот уже четыре года я работаю над репликацией в Tarantool, и сегодня хочу рассказать про слабые места алгоритма Raft и способы их преодоления. Эта статья — вольный пересказ нашего с Борисом Степаненко доклада на Hydra 2022. Если читатель не знаком с Raft, то предлагаю ознакомиться с моей статьёй о нём.

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

Мы в Quadcode любим Golang и можем рассказать о языке и его преимуществах много интересного. Все это неспроста - не так давно мы переписали некоторые наши продукты или отдельные их модули именно на Go, чему радуемся до сих пор. Подробности самых интересных кейсов вскоре планируем раскрыть на Хабре, а пока что поделимся подборкой любимых книг, которые посвящены этому языку. Некоторые из них подходят для начинающих разработчиков, другие - для программистов с опытом. Объединяет все представленные в подборке книги одно - они могут оказаться ну очень полезными для тех, кто так или иначе связан с Go. Подборка - под катом, и, кстати, если вы уже читали какую-то из рекомендованных нами книг, расскажите о своих впечатлениях в комментариях. Поехали!

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

DRBD (Distributed Replicated Block Device — распределённое реплицируемое блочное устройство) представляет собой распределенное, гибкое и универсально реплицируемое решение хранения данных для Linux. 

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

В этой статье я поделюсь опытом как создать репликацию drbd локально, не используя drbdadm, а используя drbdsetup и drbdmeta.

• Роли и привилегии;
• Безопасность на уровне строк (мы сейчас здесь);
• Производительность безопасности на уровне строк (coming soon!);