PGConfRu2019 Павел Молявин — «Готовим PostgreSQL в эпоху DevOps. Опыт 2ГИС»**

Всем привет! Меня зовут Павел! Я работаю в компании 2ГИС. Наша компания – это городской информационный справочник, навигационный сервис. Это очень хорошая штука, которая помогает жить в городе.

Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.

Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

Puppet — это система управления конфигурацией. Он используется для приведения хостов к нужному состоянию и поддержания этого состояния.

Я работаю с Puppet уже больше пяти лет. На мой взгляд, его официальная документация хороша для тех, кто уже знаком с Puppet, а для новичка она сложна — сразу даётся много новых терминов; непонятно, в каком порядке читать. Эта статья — по сути переведённая компиляция ключевых моментов из официальной документации, которая позволит новичкам быстро вникнуть в суть Puppet. Я переупорядочил информацию, чтобы постепенно рассказать про все сущности и термины.

В предыдущей статье «Zabbix — расширяем макро границы» я рассказал как получать сессию авторизации и подставлять ее в локальный макрос хоста. В этой статье я расскажу как подружить Zabbix с Asterisk без внешних скриптов и ПО.

Идея «подружить» эти две системы родилась давно, причем без установки дополнительного софта и скриптов. Быстрое гугление выдавало множество вариантов решений, все сводилось к тому, что закиньте скрипты (на пыхе, баше, питоне и т. п.) на сервер, и будет вам счастье. Мне же хотелось реализовать мониторинг «из коробки» — без внешних скриптов и установки дополнительного софта на сервер с мониторингом и АТС.

Провозился я с этим в сумме 4 рабочих дня, но результат стоил того. Работа через интерфейс AMI, низкоуровневое обнаружение, триггеры, а главное, на подключение АТС и все остальные настройки теперь уходит минут 15.

В наличии заббикс 4.4, около 100 штук Астерисков 13 версии. Какие-то АТС идут с веб интерфейсом FreePBX, какие-то с голой консолью, кучей хитростей и интеграцией через диалплан.

Делая решение для клиента, возникло 2 задачи, которые хотелось решить красиво и штатным функционалом Zabbix.

Задача 1. Отслеживание актуальной версии прошивки на роутерах Mikrotik.

Задача решается легко — добавлением в шаблон HTTP агента. Агент получает актуальную версию с сайта Mikrotik, а триггер сравнивает актуальную версию с текущей и в случае расхождения выдает алерт.

Когда у вас 10 роутеров, такой алгоритм не критичен, а что делать с 3000 роутеров? Слать 3000 запросов на сервер? Работать, конечно, такая схема будет, но сама идея 3000 запросов меня не устраивала, хотелось найти другое решение. К тому же, недостаток в подобном алгоритме все-таки был: другая сторона может посчитать такое количество запросов с одного IP за DoS атаку, могут просто забанить.

Задача 2. Использование сессии авторизации в разных HTTP агентах.

Когда через HTTP агент нужно получать информацию с «закрытых» страниц, нужна кука авторизации. Для этого обычно существует стандартная форма авторизации с парой «логин/пароль» и установкой ID сессии в куку.

Но есть проблема, нельзя из одного айтема HTTP агента обратиться к данным другого айтема для подстановки этого значение в Header.

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

Немного поразмыслив над этими задачами, решил использовать макросы, которые отлично видны в любой части системы мониторинга: в шаблонах, хостах, триггерах или айтемах. А обновлять макросы можно через API веб интерфейса.

Привет, Хабр! Встала передо мной недавно задача: настроить максимально надежный кластер серверов PostgreSQL версии 9.6.

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

Планируя кластер я проштудировал много статей, как из основной документации к PostgreSQL, так и различных howto, в том числе с Хабра, и пробовал настроить стандартный кластер с RepMgr, эксперементировал с pgpool.

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

В итоге где-то (уже не вспомню точно где) нашел ссылку на прекрасный проект Zalando Patroni, и все заверте…

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

Современный мир дает возможность многим работать из дома. Особенно сейчас, в «короновирусную» эпоху еще больше людей работают удаленно и перестали ездить на работу. Это значит, что в домашней обстановке в основном сидят, долго сидят и смотрят в монитор. Справедливости ради, надо сказать, что и офисная жизнь не располагает к подвижности. Про вред долгого смотрения в монитор я пока не готова рассказать, а вот долгое сидение точно приводит к проблемам с ЖКТ (желудочно-кишечный тракт). Плюс многие не пьют достаточное количество воды, не едят клетчатку, стрессуют, а это все приводит к некоторым проблемам, которые могут длиться годами. Рано или поздно многие приходят к необходимости сделать колоноскопию. Если хотите узнать про это деликатное исследование подробнее – добро пожаловать под кат. В статье есть описание многих физиологических тем, которых принято стесняться, кому-то может быть просто неприятно, также есть немного ужастиков, так что впечатлительным особам лучше воздержаться от чтения.

Hello Planets by Augustinas Raginskis

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

При создании собственной методики управления резервными копиями на множестве серверов MS-SQL я потратил кучу времени на изучение механизма передачи значений в powershell при удаленных вызовах, поэтому пишу самому себе памятку, а вдруг кому-то еще пригодится.

Итак, возьмем для начала простейший скрипт и запустим его локально:

$exitcode = $args[0]
Write-Host 'Out to host.'
Write-Output 'Out to output.'
Write-Host ('ExitCode: ' + $exitcode)
Write-Output $exitcode
$host.SetShouldExit($exitcode)

Для запуска скриптов я буду пользоваться следующим CMD-файлом, каждый раз его приводить не стану:

@Echo OFF
PowerShell .\TestOutput1.ps1 1
ECHO ERRORLEVEL=%ERRORLEVEL%

На экране мы увидим следующее:

Out to host.
Out to output.
ExitCode: 1
1
ERRORLEVEL=1

Мы уже рассказали, как описывать конфигурацию в Desired State Configuration (DSC) и разобрали встроенный агент Local Configuration Manager (LCM) для применения конфигурации на сервере. В первой части статьи пошагово прошлись по основным особенностям инструмента вместе с Евгением Парфеновым из DataLine.

Здесь же погрузимся в настройку и особенности работы в режимах Push и Pull.

О чём расскажем:

1. Различия режимов Push и Pull
2. Push-режим в деталях
3. Pull-режим в деталях

Вступление

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

Наибольший толчок развития DIY шлюзам дал проект zigbee2mqtt. На момент написания заметки в проекте реализована поддержка 785 устройства от 140 производителей.

Поиск показал наличие интересных конкурентных проектов AqaraHub(написан на с, похоже, что развитие приостановлено, последний коммит был 5 месяцев назад), нативная поддержка в ioBroker (проект ведет наш соотечественник Киров Илья), нативная поддержка в Home-assistant (поддержка появилась после появления библиотеки zigpy, активно развивается, но пока далека от совершенства). Обзор программных шлюзов хорошо разобран в интернете, имеется множество статей, желающий найдет информацию по тэгам в конце статьи.

Предлагаю ознакомиться с расшифровкой доклада 2018 года Андрея Сальникова "Практика обновления версий PostgreSQL"

В большинстве своем, системные администраторы и ДБА бояться как огня делать мажорные обновления версий баз данных (RDBMS), особенно если эта база данных в эксплуатации и имеет достаточно высокую нагрузку. Главной причиной тому некоторый даунтайм базы данных, который всегда подразумевается при планировании таких работ.

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

В Data Egret мы накопили огромный опыт проведения мажорных апгрейдов PostgreSQL в проектах, где нет права на ошибку. Я поделюсь своим опытом и расскажу о следующих шагах процесса: как правильно подготовиться к upgrade-у PostgreSQL? что необходимо сделать на этапе подготовки? как запланировать последовательность действий на сам upgrade? как провести процедуру upgrade-а успешно, без возврата на предыдущую версию бд? как минимизировать или вообще избежать простоя всей системы во время upgrade-а? какие действия необходимо выполнить после успешного upgrade-а PostgreSQL? Я также расскажу про две наиболее популярные процедуры апгрейда PostgreSQL — pg_upgrade и pg_dump/pg_restore, плюсы и минусы каждого из методов и расскажу про все типичные проблемы на всех этапах этой процедуры, и как их избежать.

Доклад будет интересен как новичкам так и тем ДБА которые уже давно работают с PostgreSQL, но хотят побольше узнать о том как правильно планировать и проводить upgrade максимально безболезненно.

Предлагаю ознакомиться с расшифровкой доклада начала 2019 года Андрея Сальникова "Управление нагрузкой на PostgreSQL, когда одного сервера уже мало"

Основные тезисы:
1) Стандартные практики распределения нагрузки в PostgreSQL. Сначала мы обсудим причины возникновения высокой нагрузки на базу данных. Следующим этапом рассмотрим те методы распределения нагрузки.
2) Будут рассмотрены вопросы того, как устроена репликация в PostgreSQL, какие есть различия между синхронными и асинхронными репликами, как правильно настраивать реплики.

Расшифровка доклада 2018 года Алексея Лесовского "Давайте отключим vacuum?!"

Примечание редактора: Любые рекомендации по изменению параметров всегда стоит сравнивать в других докладах

Такой призыв часто возникает, когда в PostgreSQL возникают проблемы, и главным подозреваемым оказывается vacuum (далее по тексту просто "вакуум"). По опыту, многие наступают на эти грабли, и мне с коллегам по Data Egret нередко приходится разгребать последствия, так как потом всё становится ещё хуже. Но если обратить внимание на сам вакуум, то, пожалуй, нет такого человека, который бы использовал Postgres, и при этом ничего не знал про него. Ведь история вакуума начинается относительно давно, и в интернете можно найти массу как старых, так и новых постов про вакуум, объемные дискуссии в списках рассылки. Несмотря на то, что тема вакуума подробно описана в официальной документации к PostgreSQL, новые посты и новые дискуссии будут появляться и дальше. Возможно, поэтому с вакуумом связано очень много мифов, баек, страшилок и заблуждений. Между тем, вакуум является одним из важнейших компонентов PostgreSQL, и его работа напрямую сказывается на производительности. В одном докладе невозможно рассказать про вакуум абсолютно всё, но я бы хотел раскрыть ключевые моменты, связанные с вакуумом, такие как его внутреннее устройство, основные подходы к его настройке, наблюдение за производительностью, мониторинг, и что делать в случае, когда вакуум — главный подозреваемый во всех бедах. Ну и, конечно же, хочется развеять распространенные мифы и заблуждения, связанные с вакуумом.

Я уже рассказывал, как мы «ловим» проблемы PostgreSQL с помощью массового мониторинга логов на сотнях серверов одновременно. Но ведь кроме логов, эта СУБД предоставляет нам еще и множество инструментов для анализа ее состояния — грех ими не воспользоваться.

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


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

Сегодняшняя статья — о том, какие выводы можно сделать, наблюдая в динамике различные метрики баз PostgreSQL-сервера, и где может скрываться проблема.

Главные вопросы работы с базой данных связаны с особенностями устройства операционной системы, на которой работает база. Сейчас Linux — основная операционная система для баз данных. Solaris, Microsoft и даже HPUX все еще применяются в энтерпрайзе, но первое место им больше никогда не занять, даже вместе взятым. Linux уверенно завоевывает позиции, потому что open source баз данных все больше. Поэтому вопрос взаимодействия БД с ОС, очевидно, о базах данных в Linux. На это накладывается вечная проблема БД — производительность IO. Хорошо, что в Linux последние годы идет капитальный ремонт IO-стека и есть надежда на просветление.


Илья Космодемьянский (hydrobiont) работает в компании Data Egret, которая занимается консалтингом и поддержкой PostgreSQL, и про взаимодействие ОС и баз данных знает многое. В докладе на HighLoad++ Илья рассказал о взаимодействии IO и БД на примере PostgreSQL, но и показал, как с IO работают другие БД. Рассмотрел стек Linux IO, что нового и хорошего в нем появилось и почему все не так, как было пару лет назад. В качестве полезной памятки — контрольный список настроек PostgreSQL и Linux для максимальной производительности подсистемы IO в новых ядрах.

Desired State Configuration (DSC) — инструмент управления конфигурацией сервера. С его помощью можно настроить сервер (внести изменения в реестр, копировать файлы, установить и удалить компоненты), проконтролировать текущее состояние настроек и быстро откатиться до базовых настроек.

DSC интересен тем, кто придерживается DevOps-подхода. Этот инструмент хорошо укладывается в парадигму Infrastructure as a Code: разработчики могут вносить свои требования в конфигурацию и включать ее в систему управления версиями, а команды — развертывать код без использования «ручных» процессов.

Совместно со Станиславом Булдаковым из Райффайзенбанка мы объединили наш опыт работы с движком DSC и разделили его на 2 статьи. В первой мы разберем основные принципы работы и познакомимся с особенностями использования на практических примерах:

• «распакуем коробку» с движком DSC, посмотрим, какие ресурсы есть по умолчанию, и покажем, где взять дополнительные ресурсы;
  
• разберем, как описывать  конфигурацию в DSC; 
  
• узнаем, как встроенный агент Local Configuration Manager применяет конфигурации на сервере, покажем, как он настраивается с помощью метаконфигураций;
  
• перейдем к более сложным случаям настройки: частичным конфигурациям и конфигурациям-заглушкам.
  

А про настройку и особенности работы в режимах Push и Pull можно узнать во второй статье.

По мере исчерпания адресов IPv4, многие операторы связи столкнулись с необходимостью организовывать доступ своих клиентов в сеть с помощью трансляции адресов. В этой статье я расскажу, как можно получить производительность уровня Carrier Grade NAT на commodity серверах.

У нас в агрегации локальной сети было шесть пар коммутаторов Arista DCS-7050CX3-32S и одна пара коммутаторов Brocade VDX 6940-36Q. Не то, чтобы нас сильно напрягали коммутаторы Brocade в этой сети, они работают и выполняют свои функции, но мы готовили полную автоматизацию некоторых действий, а этих возможностей мы на этих коммутаторах не имели. А еще хотелось перейти с 40GE интерфейсов на возможность использования 100GE, чтобы сделать запас на следующие 2-3 года. Так мы решили поменять Brocade на Arista.

Хочу поделиться опытом проектирования, монтажа и эксплуатации своей системы приточной вентиляции совмещенной с канальным кондиционером. Система
собиралась в 2012-2013 годах и с тех пор находится в постоянной эксплуатации.

Статью разделил на две части:

• в первой части описана классическая схема приточная вентиляции с использованием электрического канального подогревателя
• во второй части рассказано про неоднозначный опыт переработки системы под водяной калорифер с питанием от общедомовой системы отопления