В апреле этого года мы, команда производительности из Postgres Professional, совместно с коллегами из Selectel решили протестировать несколько дистрибутивов PostgreSQL и узнать, как они себя поведут на разных архитектурах. С результатами можно ознакомиться в этой статье, но, как сразу было верно отмечено читателями, там был один важный косяк –  мы не сравнили производительность ванильного PostgreSQL с применением всем известных настроек по улучшению производительности и Postgres Pro Enterprise из коробки as is. Терпеть такое не было решительно никакой возможности, поэтому сегодня будет продолжение истории и ответ на важный для многих вопрос: «А есть ли у нашего форка хоть какое-то преимущество перед бесплатной ваниллой?» Или мы просто накатили общеизвестный конфиг и занимаемся импортозаместительным переклеиванием наклеек?

СУБД Postgres Pro – сложный механизм, который можно гибко настраивать под конкретный тип нагрузки. Для этого в нём имеется множество параметров и инструментов. Например, одним из главных потребителей ресурсов CPU является оптимизатор/планировщик запросов, который отвечает за построение оптимального плана выполнения. Существует большое количество параметров, которые прямо или косвенно влияют на работу планировщика, но к их изменению надо подходить очень осторожно, т. к. возможен обратный эффект. Например, параметры _collapse_limit могут и помочь оптимизатору рассмотреть большее количество вариантов планов, и негативно повлиять на время планирования.

Сегодня я расскажу, как мы решали реальную проблему производительности и высокой (> 90%) утилизации ресурсов CPU на промышленном «боевом» сервере с СУБД Postgres Pro Enterprise 15, обслуживающем запросы бизнес-приложения, какие для этого использовали инструменты и что мы изменили в настройках СУБД.

Сейчас мы, в Postgres Professional, разрабатываем новый интересный продукт — DataBase as a Service, и в этой статье хочется немного рассказать о наших успехах, узнать ваше мнение и послушать возможные пожелания. 

В СУБД-строении есть не новая, но не теряющая актуальности задача. Сформулировать её можно примерно так: как убрать возможность суперпользователя взаимодействовать с данными, но оставить ему все возможности по управлению СУБД? Эта функция затребована не только большими компаниями с жёсткими требованиями к информационной безопасности, но и крайне нужна всем, кто попадает под различного вида государственные регуляции, вроде приказа ФСТЭК №64 или страшного GDPR.

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

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

В начале ноября так сложились обстоятельства, что мне с коллегой довелось поучаствовать в качестве судей на мероприятии под строгим названием «Отборочный этап чемпионата России по спортивному программированию» в дисциплине «Продуктовое программирование». Или, говоря более простым языком — студенческий трехдневный онлайн-хакатон, победители которого поедут на финал чемпионата страны в Москву.

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

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

Так что да, эта статья скорее для тех, кто начинает - о том, как может быть на самом деле (нежели для прошедших горнило замены картриджей и теперь пугающих этим молодёжь).

Снятие снапшота - именно с этого начинается любой бекап. До тех пор, пока мы не знаем, как сбросить все буфера на диск и привести файлы с данными в консистентное состояние, мы не бекапы делаем, а занимаемся копированием файлов с непредсказуемым содержимым внутри. Понимая важность снапшотов, все вендоры стараются дать нам если не полностью готовую функцию (типа Time Mashine в MacOS), то хотя бы набор ручек, за которые можно подёргать (вроде модуля dm-snap в ядре Linux). 

Но сегодня речь пойдёт про самую распространённую ОС - Microsoft Windows, где эта задача решается с помощью Volume Shadow Copy сервиса, известного в народе под аббревиатурой VSS (Volume Snapshot Service). А нашего внимания он удостоился из-за того, что, несмотря на всю популярность своего материнского корабля, сам он окутан вуалью из тайн и мистических слухов. Давайте уже как-то разберёмся с этой штукой.

По мнению абсолютного большинства жителей этой планеты, разработчики это - какие-то зажравшиеся люди, которые сидят в своих уютных креслах, занимаются какой-то фигнёй и получают за это непомерные деньги. Эталонные тепличные условия и голубая мечта, которая выродилась в пренебрежительное “Войти в айти”. Но если предположить, что всё действительно так, как принято считать - и стул удобный, и денег платят много, и работа интересная - то почему же программисты, как и все остальные люди, иногда меняют место работы? Может быть, недостаточно платили? Или кресло было не такое удобное? Что-то же должно побудить человека, у которого всё хорошо (по мнению окружающих), выйти из зоны комфорта и пойти искать новое место работы. И что именно он ищет на этом новом месте? Давайте поговорим об этом. И да, многое здесь может показаться банальным, но почему-то достаточное количество людей предпочитают не брать в расчёт и половину из этих банальностей. Или делают вид, что им всё равно.

Функция CDP (она же Continuous Data Protection) для многих сейчас видится манной небесной. Ведь она позволяет свести риски потери данных к около-нулевым значениям (RTO и RPO - единицы секунд), при этом не используя тормозящие всё вокруг себя снапшоты, и не зависеть от ограничений классических вариантов репликации. 

Вот об этом мы сегодня и поговорим: что это за магия такая, как она работает и как мы её реализовали в Veeam Backup & Replication v11.

VTL (они же Virtual Tape Library, если по паспорту) можно назвать одним из самых странных порождений IT индустрии. Родившись в эпоху расцвета ленточных накопителей как классический софтовый эмулятор настоящего железа, многими они были восприняты как ответ на главный вопрос жизни (Вселенной и всего такого), и теперь одни умудряются продавать их за деньги, а другие использовать в проде и считать, что всё нормально.

Я не буду кричать что первые плохие, а вторых надо гнать из профессии. Нет. Я только лишь предлагаю трезво взглянуть на суть VTL.

Помните, как во второй половине 90-х один известный тогда профессор хрипло пел “Бегут года, и грусть, печаль в твоих глазах, а я не знаю что тебе сказать”. Так вот, года действительно бегут, а грусть-печаль в глазах из-за того, что гонка технологий уже достигла таких скоростей, что успеть за ними не может даже самый ловкий мангуст. Правда, некоторые вещи категорически отказываются меняться, и раз уж эта статья из блога компании, занимающейся бекапами, видимо, что-то не меняется в бекапах. А проблема, о которой хочется поговорить сегодня - это выбор сервера, который эти бекапы и будет делать. Все как-то привыкли думать только о размере стораджа, куда их предстоит складывать, а то, что процесс бекапа - это типичная задача обработки большого массива данных, которая жрёт RAM и CPU как не в себя, многие то ли забывают учесть, то ли по неопытности упускают этот момент. Так что сегодня учимся подбирать сервера для бекапов не только по размеру дисков. Или, как говорят зарубежные коллеги: backup server sizing best practices.

И да, в посте будет математика. Целых две формулы. Я предупредил.

Уже, наверное, только ленивый не повторил десять раз, что ковид послужил катализатором взрывного роста как самих облаков, так и разного рода облачных сервисов. Словом, всё, что как-то относится к облачной теме, стало резко расти и увеличиваться в объёмах. Причина банальная: всех разогнали по домам, и для многих возросшие нагрузки на их сервисы послужили тем самым громом, после которого надо перекреститься и начинать уже что-то делать. Вот все и начали срочно мигрировать. У кого-то процесс перехода прошёл гладко, у кого-то не очень, однако все мы как-то научились жить в новой реальности и теперь, когда вау-эффект прошёл, многие компании стали переключаться с чисто инфраструктурных вопросов на вопрос сохранности данных. Когда твои сервера у тебя под боком, ты сам себе хозяин и молодец. А что делать, когда твои продукты крутятся не пойми где? Довериться надежности облака? Бекапить облачные сервисы другими сервисами этого же облака? Бекапить из облака на землю? Бекапить одного облако в другое? Вопрос важный, ответ не ясен, давайте разбираться.

Казалось бы, такое простое действие: взять да восстановиться из бекапа, если где-то сломалось. Текущий уровень развития софта позволяет это cделать буквально в несколько кликов - и вы восхитительны. Возможно, даже никто не заметит, что была какая-то авария.

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

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

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

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

Но сегодня не об этом =)

Сегодня мы поговорим про тех, кому сейчас только предстоит пойти в школу. Кому вот прямо сейчас лет 5-6. И почему большая ошибка учить их так же, как учили тебя тридцать лет назад. Почему это бесполезно, зачастую вредно и даже не похоже на учёбу в нашем понимании этого слова.

Скажите честно, в своей практике вам чаще приходилось сталкиваться с логами, напоминающими чей-то поток сознания, или всё же это были красивые структурированные файлы, на которые любо-дорого смотреть? Надеюсь, что второе. В наших продуктах, само собой, мы тоже стремимся идти по второму пути, однако необходимость зафиксировать большое количество процессов накладывает свой отпечаток. Так что сегодня мы научимся не “читать книгу и видеть фигу”, а бесстрашно открывать любой лог Veeam Backup & Replication и видеть его внутреннюю красоту.

Перед прочтением этой статьи настоятельно рекомендую предварительно ознакомиться со статьёй-глоссарием, дабы понимать используемую терминологию. Затем прочитать эту и вот эту статью про источники данных для логов, а затем ещё и эту, дабы понимать, в какой лог ради чего следует залезать.

Наверняка я вам не открою Америки рассказом о том, что логи назвали логами из-за судовых журналов, куда записывали всякое интересное (и не очень), что происходило на корабле во время плавания. (Возможно, некоторые из вас не знают, но по воде ходят именно корабли, а судно — это в больнице. Хотя тут показания расходятся)))

Но не об этом мы сегодня. Сегодня мы поговорим о структуре логов в Veeam Backup & Replication, об их названиях и ожидаемом содержимом. Список будет большим, но не исчерпывающим, ибо всё описать — задача практически невозможная.

Как и у каждой уважающей себя техподдержки, у инженеров Veeam есть свой список самых популярных поводов позвонить им в любое время дня и ночи. Это и вечно молодое “У вас неправильно работает ретенш”, и никогда не стареющее “У меня место на дисках кончилось, что делать?”, и прорва других. 

Однако среди них есть простой, казалось бы, вопрос. Он объясняется за 5 минут, но вот парадокс: его объяснение вылетает из головы в течение следующих тридцати секунд. Звучит этот чудо-вопрос примерно так: “После бекапа Veeam нарисовал мне непонятный график и написал, что у меня загрузка сорса 63%, прокси 48%, сети 99%, а таргета 0! А потом ещё и обозвал этот сорс ботлнеком, а у меня там ого-го какая железяка! И что вообще означают эти проценты?”

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

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

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

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