Почему SSH ?

Нам нужно выполнять shell и sql команды на серверах с PostgreSQL, например чтение файла лога, снятие статистики, поиск блокировок. Консольный доступ на большинстве серверов уже реализован через SSH, а с доступом к экземплярам PostgreSQL не так просто — нужно устанавливать новые соединения ко всем экземплярам, а для этого открывать сетевые порты и управлять конфигами pg_hba.conf, прописав в них IP‑адреса серверов мониторинга, да и передавать данные по сети в открытом виде нехорошо, а для SSL тоже нужны отдельные настройки.

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

Работаем с модулем SSH2

Об архитектурных решениях подробно написано в этой статье и в продолжении.

При использовании модуля ssh2 и большой нагрузке может возникнуть неприятный побочный эффект, связанный с тем, что модуль написан на Javascript, а значит работает в основном потоке вместе с остальным кодом приложения. Помимо увеличения задержек в event loop это дополнительно нагружает GC и thread pool.

На некоторых серверах задержки event loop в часы пик вырастали до неприличных значений:

Для решения этой проблемы мы решили выгрузить все ssh-операции в отдельный процесс, но вместо модуля ssh2 использовать консольный ssh-клиент из пакета OpenSSH.

Пробуем перейти на OpenSSH

Этот ssh-клиент позволяет выполнять операции в режиме совместного использования одного соединения. Для этого вначале устанавливаем master-соединение и создаем контрольный сокет-файл /tmp/ssh.sock для взаимодействия с slave-процессами:

ssh -M -S /tmp/ssh.sock -i id_rsa -l username pg_hostname

а затем запускаем процесс в режиме slave, например для выполнения консольных команд:

ssh -S /tmp/ssh.sock pg_hostname command

или для установки тоннеля и проброса соединения к локальному сокету на удаленный хост:

ssh -S /tmp/ssh.sock -O forward -L /tmp/postgresql.sock:127.0.0.1:5432 pg_hostname

Запуск процесса ssh выполняем с помощью child_process.spawn , а входящий поток данных получаем из его stdout в виде stream.Readable.

Для унификации создали новый модуль system‑ssh с такими же как у ssh2 методами и параметрами — connect, end, exec, forwardOut и дополнительно forwardOutLocalSocket, и опубликовали его в npm реестре.

Схема работы с новым модулем:

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

При небольшом количестве ssh-соединений такой вариант вполне работоспособен.

Но у нас в мониторинге около 2000 экземпляров PostgreSQL и запускать такое количество дочерних процессов нерационально. Для разгрузки event loop основного процесса достаточно перевести на новую модель только серверы с относительно большим потоком данных. В качестве фильтра для перевода на system‑ssh мы поставили границу 1.25 Mbps, а для возвращения на старую модель inproc — 0.75 Mpbs. Таким образом количество дочерних процессов остается небольшим, при этом большая часть трафика обрабатывается вне основного процесса:

Вот только при запуске spawn в Node.JS появляются задержки из-за синхронных операций с heap, причем чем больше памяти используется процессом, тем они больше:

On Unix-like operating systems, the child_process.spawn() method performs memory operations synchronously before decoupling the event loop from the child. Applications with a large memory footprint may find frequent child_process.spawn() calls to be a bottleneck. For more information, see V8 issue 7381.

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

SSH-прокси

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

Поток данных из stdout процесса перенаправили в Unix domain socket, примерно так:

// sshproxy
const { Client } = require('system-ssh');
const sshConnection = new Client();
const socketPath = '/tmp/host_1/stream_1.sock';

sshConnection.exec('tail -F postgresql.log', (error, stream) => {
    const server = net.createServer({noDelay: true}, (socket) => {
        stream.pipe(socket).pipe(stream);
    })
    server.on('error', (err) => {
        if (err.code === 'EADDRINUSE') {
            // сокет уже есть, пробуем подключиться к нему
            const clientSocket = new net.Socket();
            clientSocket.on('error', (clientError) => {
                if (clientError.code === 'ECONNREFUSED') {
                    // сокет никто не использует, тогда удаляем и пробуем снова
                    fs.unlinkSync(socketPath);
                    server.listen(socketPath);
                }
            });
            clientSocket.connect({path: socketPath}, () => {
                // подключились, значит кто-то уже использует этот сокет
                clientSocket.destroy();
                server.close();
            });
        }
    })
    server.on('listening', () => {
        // сокет готов, можно подключаться со стороны воркера
    })
    server.listen(socketPath);
})

// worker
const clientSocket = new net.Socket();
clientSocket.connect({path: socketPath}, () => {
    // подключились к сокету
    clientSocket.on('data', (data) => {
        // обрабатываем поступившие данные
        // или просто clientSocket.pipe(dataHandler)
    })
})

И получили значительное увеличение задержек на воркере.

Похоже net.Socket здесь нам не подойдет, пробуем заменить на named pipe (FIFO):

Код для FIFO проще, в sshproxy поверх него создаем пишущий поток, а в воркере - читающий

// sshproxy
const { exec } = require('child_process');
const fs = require('fs');
const { Client } = require('system-ssh');
const sshConnection = new Client();

const fifo = '/tmp/host_1/stream_1.fifo'
const cmdFifo = exec(`test -p ${fifo} || mkfifo ${fifo}`, (error, stdout, stderr) => {
    fs.open(fifo, 'w', (error, fd) => {
        sshConnection.exec('tail -F postgresql.log', {stdio: ['pipe', fd, 'pipe']}, (error, stream) => {
            const fifoStream = fs.createWriteStream(fifo, {fd});
            stream.pipe(fifoStream);
        })
    })
})

// worker
let stream = fs.createReadStream(fifo);
stream.on('data', (data) => {
    // обрабатываем поступившие данные
    // или просто stream.pipe(dataHandler)
})

И получаем снижение задержек на загруженных воркерах в 15 раз:

и как следствие - практически полное отсутствие очередей записи в БД:

UV_THREADPOOL

Без ложки дегтя как обычно не обошлось, в данном случае при работе с FIFO надо учитывать, что все асинхронные файловые операции в Node.JS выполняются в uv_threadpool , а его размер ограничен и по умолчанию равен 4. Если все 4 потока в этом пуле будут заняты, то другие операции будут висеть в очереди.

Учитывая то, что в этом же пуле выполняются операции dns.lookup() и асинхронные crypto API, которых у нас в воркере довольно много (так как большая часть серверов осталась работать по старой схеме с модулем ssh2), при большом количестве загруженных FIFO можно получить снижение производительности.

Причиной этого является также то, что файловая обвязка поверх FIFO выполняет блокирующие операции, например fs.open(fifo) будет ждать и занимать поток uv_threadpool до тех пор, пока FIFO не будет открыт с другой стороны. Выходом, как пишут здесь, могло бы быть использование неблокирующего ввода‑вывода, но модуль fs в Node.JS так не умеет, а тот что умеет — net.Socket нам не подходит.

В нашем же случае один sshproxy обслуживает одновременно 20–30 серверов PostgreSQL и негативное влияние на производительность отсутствует.