Про «85%» — да, это упрощение для статьи. В реальности граница размыта. Есть вещи, которые однозначно на стороне платформы: установка, патчи, failover, инфраструктурный мониторинг. А есть зона «зависит» — ваш случай с WAL как раз оттуда.
По вашему кейсу с UPDATE и WAL. Managed тут не значит магия. Платформа должна увидеть рост WAL и отставание реплик раньше падения, поднять алерт, дать рекомендации (увеличить диск, поменять retention, посмотреть на паттерн).
Но решить за клиента «это нормальная бизнес-логика или баг в коде» — не может. Троттлить запись автоматически опасно, можем сломать процесс. Молча доводить до падения — тоже плохо.
Получается совместная работа: мы видим метрики и говорим «проблема здесь», клиент решает «это норма, давайте масштабируем» или «да, баг у нас, фиксим».
По «жирный инстанс, но медленно». Согласен, просто «смотрите метрики» недостаточно. Минимум — разобрать, где узкое место: в запросе/индексах или в железе. Если в запросе — показать план, explain, дать рекомендации. Если в инфраструктуре — объяснить конкретно что (IOPS, CPU wait, сеть).
DBaaS не убирает необходимость понимать Postgres. Он убирает рутину (патчи, бэкапы, failover) и берёт первую линию диагностики. Сложные кейсы всё равно требуют диалога, иначе это просто аренда железа с Postgres сверху.
Отдельно отвечу вам, замечания ваши по делу, но в большей степени относятся, если бы статья была как полноценная инструкция к действию "как поднять СУБД руками". По формату статьи - приведены инструменты, которые могут быть задействованы по разному или вообще не использоваться. Это мой опыт. Про split-brain - подправлю текст.
По прочим комментариям, я возьму на доработку в рамках отдельной статьи. Буду рад если её также проревъюите!
Почему сразу "ужас"? Но в любом случае, спасибо за комментарий. Я постараюсь на все ваши вопросы дать ответ. Замечания по делу. Цель статьи — показать декомпозицию трудозатрат, а не пошаговую инструкцию, но понимаю, что некоторые моменты требуют уточнений. Про split-brain — подправлю текст. Остальное возьму на доработку. Буду рад, если проревьюите!
1 По синхронной репликации и latency
Хороший комментарий. В статье действительно не раскрыты конкретные решения. На практике есть несколько вариантов:
Quorum-режим (synchronous_mode: quorum в Patroni) — при 3 репликах достаточно подтверждения от любых 2, а не от конкретной. Снижает worst-case latency.
remote_write вместо on — мастер ждёт только записи WAL в OS-буфер реплики, без fsync. Я эту реализацию не поднимал, тк мне не нужно это, но пишут Crunchy Data : "The master waits only until the standby has received the WAL record and written it to the operating system" — даёт 30-40% снижения latency.
Гибридный режим на уровне приложения — критичные транзакции с SET LOCAL synchronous_commit = on, остальные async.
Если бизнес требует RPO=0, но latency критична — это конфликт требований, который решается на уровне продукта, а не инфраструктуры. Но техническую часть в статье стоило раскрыть подробнее, согласен.
2 По настройке Streaming Replication «руками» перед Patroni Тут не правильно сформулировал мысль я. Вы правы Patroni действительно сам настраивает репликацию через bootstrap-конфигурацию: Он управляет слотами, инициализирует реплики. Ручная настройка репликации до Patroni нужна только при миграции с существующего кластера — но это edge case, а не базовый сценарий. Переформулирую позже в статье.
3 По split-brain Тут увлекся и прописал про свой частный случай. Это не являтеся правильной работой Чтобы точнее быть в доках есть:
"The node is allowed to run Postgres as the primary only if it can update the leader lock in DCS. In case the update of the leader lock fails, Postgres is immediately demoted and started as read-only."
И дальше:
"In the case of DCS 'outage' the existing primary connects to all members presented in the /failsafe key via the POST /failsafe REST API and may continue to run as the primary if all replicas acknowledge it. If one of the members doesn't respond, the primary is demoted."
То есть мастер демотируется до того, как реплика успеет промоутиться. Split-brain в описанном сценарии невозможен при правильной конфигурации. Вы правы, сценарий в статье некорректен. Patroni по дизайну защищён от такого split-brain — мастер демотируется до того, как реплика успеет промоутиться. Описанная ситуация возможна только при багах в Patroni или ручном обходе системы., чем на реальное поведение Patroni 3.x/4.x.
4 По pg_basebackup и pgBackRest/Barman
Да, смешал два подхода. pgBackRest — это самостоятельная реализация на C, не обёртка над pg_basebackup. Barman использует pg_basebackup под капотом, а pgBackRest — нет. Исправлю.
5 По JDBC failover
Да, это сильно проще реализация. Это хорошо, что напомнили, про простый и действенные инструменты
Из документации PostgreSQL JDBC:
"Connection Fail-over: To support simple connection fail-over it is possible to define multiple endpoints (host and port pairs) in the connection url separated by commas."
jdbc:postgresql://node1,node2,node3/db?targetServerType=primary Никаких VIP, никаких дополнительных точек отказа. Для Java-приложений — отличный вариант
6 По времени восстановления 500 ГБ
Формулировка «несколько часов» слишком условная без учета окружения. Pure Storage в тестах может показать с pgBackRest 38 ТБ/час на параллельном восстановлении — это ~1-2 минуты для 500 ГБ. В статье эта информация избыточна, но понимаю, что важна
«Несколько часов» — это worst case на HDD + single-threaded + 1 Gbps. На NVMe + pgBackRest parallel — совсем другие цифры. 10 ТБ за 4 часа — вполне реальный сценарий при правильной настройке. Но понимаю, что нужно иметь опыт по восстановлению, чтобы в проде все починить за 4 часа. Вы молодец!
7 По pgAudit vs log_statement
В тексте эта часть упрощена. Доках pgAudit:
Basic statement logging can be provided by the standard logging facility with log_statement = all. This is acceptable for monitoring and other usages but does not provide the level of detail generally required for an audit."
log_statement='mod' — для операционного мониторинга. pgAudit — для compliance: object-level auditing, структурированный формат с AUDIT: prefix, автоматическая редакция паролей в CREATE USER. Разные инструменты для разных задач. Дополню раздел.
Вы правильно говорите, с точки зрения экономики "здесь и сейчас". НО! Есть современные требования такие как: - Информационная безопасность. Например, вирус шифровальщик, майнер, Ботнет. - Требования регулятора. Например, разместите свои ПДн в AWS и всё, ждите не исполнение требования РКН (233ФЗ) и штрафы, если будет утечка данных. Я про локализацию данных и что бы у провайдера был аттестат на инфру под требования 152ФЗ - Защита данных от того же Админа или компрометация отчётов от отдела продаж. Классическая защита от удаления исторических данных. На минималках, это решается WORM подходом на S3. Также, конечно, не просто так придумали правила Резервного копирования 3-2-1, но по вашей логике, это тройная переплата.
Я про то, что можно сэкономить 1000р. , но в итоге потеряете весь бизнес клиента ежемоментно и потенциально уголовку получить (250ФЗ). Кому нужна такая экономика? Это введение в заблуждение о сомнительной выгоде.
UPD извиняюсь, не обратил внимание сразу, что вы не автор статьи. В основном мой комментарий для автора статьи.
Интересно, а как вы подходите к отбору сервисов для Маркетплейса? Есть ли какая-то внутренняя экспертиза, которая помогает оценить, что действительно будет полезно пользователям, или сейчас основной акцент на то, чтобы упростить деплой приложений сторонних в облаке?
а когда масштабировали мастер-ноды до 7, вы не пробовали выносить только control-plane-компоненты, не участвуя всеми в etcd-кворуме? Или цель была именно full HA? Просто складывается ощущение, что лишние ноды только мешали raft-протоколу, а пользы особой не дали
кроме этого, можно управлять правим пользователя, который загружает версии. Например, отключить ему возможность удаление объекта и тогда данные всегда будут лежать в сохранности в ЦОД.
Так же, как и OpenStack, многие крупные облачные компании начинали строить свои облачные платформы, используя технологии на базе LibVirt. Однако на текущий момент, как и в случае с облаком ВК, исходный код этих решений существенно отличается от ванильных сборок OpenStack. Были заимствованы ключевые концепции архитектуры, но при этом создано собственное подразделение R&D, которое занимается не только устранением «детских» болячек в коде, но и разработкой новых функций, а также автоматизацией процессов для Заказчика облачных услуг. Добавьте к этому сертификацию ФСТЭК, внедрение подходов к безопасной разработке (SDLC), а также участие ведущих вендоров в аудите и проверке кодовой базы – и становится очевидно, что текущее состояние системы далеко от ванильной сборки и полностью соответствует современным требованиям безопасности и функциональности.
Стоит учитывать, что требования регуляторов к облачной инфраструктуре со временем ужесточаются. Например, чтобы облако соответствовало УЗ1 для обработки ПДН, нужно выполнить одни условия, а для размещения ГИС в 2025 году — уже совсем другие. Это связано с исполнением требований указов №166 и №250.
По сути, речь идёт о разных подходах к построению инфраструктуры для решения задач информационной безопасности. Публичное облако даёт больше возможностей — например, доступ к личному кабинету через интернет без VPN. А вот в "Secure Cloud" всё иначе: доступ только через криптошлюзы, строго по ГОСТ VPN, без IPsec.
Информзащита», провели аттестацию облачной платформы Linx Cloud на уровень защищенности УЗ-1 и К1. Аттестация подтвердила катастрофоустойчивость платформы Linx Cloud
Предполагаю, что не "катастрофоустойчивость", а отказоустойчивость.
Также, подскажите, какую российскую платформу виртуализации вы аттестовали под К1? Было бы интересно, с т.з. технического наполнения посмотреть на ваш проект.
Спасибо, что напомнили про CloudNativePG. Давно уже хотел её начать использовать в проде.
Про «85%» — да, это упрощение для статьи. В реальности граница размыта. Есть вещи, которые однозначно на стороне платформы: установка, патчи, failover, инфраструктурный мониторинг. А есть зона «зависит» — ваш случай с WAL как раз оттуда.
По вашему кейсу с UPDATE и WAL.
Managed тут не значит магия. Платформа должна увидеть рост WAL и отставание реплик раньше падения, поднять алерт, дать рекомендации (увеличить диск, поменять retention, посмотреть на паттерн).
Но решить за клиента «это нормальная бизнес-логика или баг в коде» — не может. Троттлить запись автоматически опасно, можем сломать процесс. Молча доводить до падения — тоже плохо.
Получается совместная работа: мы видим метрики и говорим «проблема здесь», клиент решает «это норма, давайте масштабируем» или «да, баг у нас, фиксим».
По «жирный инстанс, но медленно».
Согласен, просто «смотрите метрики» недостаточно. Минимум — разобрать, где узкое место: в запросе/индексах или в железе. Если в запросе — показать план, explain, дать рекомендации. Если в инфраструктуре — объяснить конкретно что (IOPS, CPU wait, сеть).
DBaaS не убирает необходимость понимать Postgres. Он убирает рутину (патчи, бэкапы, failover) и берёт первую линию диагностики. Сложные кейсы всё равно требуют диалога, иначе это просто аренда железа с Postgres сверху.
Отдельно отвечу вам, замечания ваши по делу, но в большей степени относятся, если бы статья была как полноценная инструкция к действию "как поднять СУБД руками". По формату статьи - приведены инструменты, которые могут быть задействованы по разному или вообще не использоваться. Это мой опыт.
Про split-brain - подправлю текст.
По прочим комментариям, я возьму на доработку в рамках отдельной статьи. Буду рад если её также проревъюите!
Почему сразу "ужас"? Но в любом случае, спасибо за комментарий. Я постараюсь на все ваши вопросы дать ответ.
Замечания по делу. Цель статьи — показать декомпозицию трудозатрат, а не пошаговую инструкцию, но понимаю, что некоторые моменты требуют уточнений. Про split-brain — подправлю текст. Остальное возьму на доработку. Буду рад, если проревьюите!
1 По синхронной репликации и latency
Хороший комментарий. В статье действительно не раскрыты конкретные решения. На практике есть несколько вариантов:
Quorum-режим (
synchronous_mode: quorumв Patroni) — при 3 репликах достаточно подтверждения от любых 2, а не от конкретной. Снижает worst-case latency.remote_writeвместоon— мастер ждёт только записи WAL в OS-буфер реплики, без fsync. Я эту реализацию не поднимал, тк мне не нужно это, но пишут Crunchy Data : "The master waits only until the standby has received the WAL record and written it to the operating system" — даёт 30-40% снижения latency.Гибридный режим на уровне приложения — критичные транзакции с
SET LOCAL synchronous_commit = on, остальные async.Если бизнес требует RPO=0, но latency критична — это конфликт требований, который решается на уровне продукта, а не инфраструктуры. Но техническую часть в статье стоило раскрыть подробнее, согласен.
2 По настройке Streaming Replication «руками» перед Patroni
Тут не правильно сформулировал мысль я. Вы правы Patroni действительно сам настраивает репликацию через bootstrap-конфигурацию:
Он управляет слотами, инициализирует реплики. Ручная настройка репликации до Patroni нужна только при миграции с существующего кластера — но это edge case, а не базовый сценарий. Переформулирую позже в статье.
3 По split-brain
Тут увлекся и прописал про свой частный случай. Это не являтеся правильной работой
Чтобы точнее быть в доках есть:
И дальше:
То есть мастер демотируется до того, как реплика успеет промоутиться. Split-brain в описанном сценарии невозможен при правильной конфигурации. Вы правы, сценарий в статье некорректен. Patroni по дизайну защищён от такого split-brain — мастер демотируется до того, как реплика успеет промоутиться. Описанная ситуация возможна только при багах в Patroni или ручном обходе системы., чем на реальное поведение Patroni 3.x/4.x.
4 По pg_basebackup и pgBackRest/Barman
Да, смешал два подхода. pgBackRest — это самостоятельная реализация на C, не обёртка над pg_basebackup. Barman использует pg_basebackup под капотом, а pgBackRest — нет. Исправлю.
5 По JDBC failover
Да, это сильно проще реализация. Это хорошо, что напомнили, про простый и действенные инструменты
Из документации PostgreSQL JDBC:
jdbc:postgresql://node1,node2,node3/db?targetServerType=primaryНикаких VIP, никаких дополнительных точек отказа. Для Java-приложений — отличный вариант6 По времени восстановления 500 ГБ
Формулировка «несколько часов» слишком условная без учета окружения. Pure Storage в тестах может показать с pgBackRest 38 ТБ/час на параллельном восстановлении — это ~1-2 минуты для 500 ГБ. В статье эта информация избыточна, но понимаю, что важна
«Несколько часов» — это worst case на HDD + single-threaded + 1 Gbps. На NVMe + pgBackRest parallel — совсем другие цифры. 10 ТБ за 4 часа — вполне реальный сценарий при правильной настройке. Но понимаю, что нужно иметь опыт по восстановлению, чтобы в проде все починить за 4 часа. Вы молодец!
7 По pgAudit vs log_statement
В тексте эта часть упрощена. Доках pgAudit:
log_statement='mod'— для операционного мониторинга. pgAudit — для compliance: object-level auditing, структурированный формат с AUDIT: prefix, автоматическая редакция паролей в CREATE USER. Разные инструменты для разных задач. Дополню раздел.Согласен с вами, тут важно понять, что чтобы поднять СУБД самостоятельно, то потребуется компетенция и опыт. Далеко, не у всех он есть.
это специалист, который отвечает за продвижение технологически интересных и важных паттернов/трендов
Вы правильно говорите, с точки зрения экономики "здесь и сейчас". НО! Есть современные требования такие как:
- Информационная безопасность. Например, вирус шифровальщик, майнер, Ботнет.
- Требования регулятора. Например, разместите свои ПДн в AWS и всё, ждите не исполнение требования РКН (233ФЗ) и штрафы, если будет утечка данных. Я про локализацию данных и что бы у провайдера был аттестат на инфру под требования 152ФЗ
- Защита данных от того же Админа или компрометация отчётов от отдела продаж. Классическая защита от удаления исторических данных. На минималках, это решается WORM подходом на S3. Также, конечно, не просто так придумали правила Резервного копирования 3-2-1, но по вашей логике, это тройная переплата.
Я про то, что можно сэкономить 1000р. , но в итоге потеряете весь бизнес клиента ежемоментно и потенциально уголовку получить (250ФЗ). Кому нужна такая экономика? Это введение в заблуждение о сомнительной выгоде.
UPD
извиняюсь, не обратил внимание сразу, что вы не автор статьи. В основном мой комментарий для автора статьи.
Для вас резервное копирование относиться к скрытым расходам? Вы, точно хотите сделать бизнесу хорошо или нужно экономить на всём?
как в реализации MVP v2. обеспечить архивирование и вывод данных? Например, которые уже не нужны, но могут когда-то потребоваться.
Интересно, а как вы подходите к отбору сервисов для Маркетплейса? Есть ли какая-то внутренняя экспертиза, которая помогает оценить, что действительно будет полезно пользователям, или сейчас основной акцент на то, чтобы упростить деплой приложений сторонних в облаке?
а когда масштабировали мастер-ноды до 7, вы не пробовали выносить только control-plane-компоненты, не участвуя всеми в etcd-кворуме? Или цель была именно full HA? Просто складывается ощущение, что лишние ноды только мешали raft-протоколу, а пользы особой не дали
Странно, что в статье нет упоминания бестселлера своих годов: Deadline. Роман об управлении проектами. | ДеМарко Том
Там подробно, в художественном стиле, расписаны подходы к командам разработки и коммуникациям в них.
кроме этого, можно управлять правим пользователя, который загружает версии. Например, отключить ему возможность удаление объекта и тогда данные всегда будут лежать в сохранности в ЦОД.
Сложный вопрос. В реализации такое не видел. Постараюсь уточнить, что можно в эту сторону задействовать.
Так же, как и OpenStack, многие крупные облачные компании начинали строить свои облачные платформы, используя технологии на базе LibVirt. Однако на текущий момент, как и в случае с облаком ВК, исходный код этих решений существенно отличается от ванильных сборок OpenStack. Были заимствованы ключевые концепции архитектуры, но при этом создано собственное подразделение R&D, которое занимается не только устранением «детских» болячек в коде, но и разработкой новых функций, а также автоматизацией процессов для Заказчика облачных услуг. Добавьте к этому сертификацию ФСТЭК, внедрение подходов к безопасной разработке (SDLC), а также участие ведущих вендоров в аудите и проверке кодовой базы – и становится очевидно, что текущее состояние системы далеко от ванильной сборки и полностью соответствует современным требованиям безопасности и функциональности.
Стоит учитывать, что требования регуляторов к облачной инфраструктуре со временем ужесточаются. Например, чтобы облако соответствовало УЗ1 для обработки ПДН, нужно выполнить одни условия, а для размещения ГИС в 2025 году — уже совсем другие. Это связано с исполнением требований указов №166 и №250.
По сути, речь идёт о разных подходах к построению инфраструктуры для решения задач информационной безопасности. Публичное облако даёт больше возможностей — например, доступ к личному кабинету через интернет без VPN. А вот в "Secure Cloud" всё иначе: доступ только через криптошлюзы, строго по ГОСТ VPN, без IPsec.
Т.е. только частное облако вы аттестовали под К1?
Предполагаю, что не "катастрофоустойчивость", а отказоустойчивость.
Также, подскажите, какую российскую платформу виртуализации вы аттестовали под К1? Было бы интересно, с т.з. технического наполнения посмотреть на ваш проект.
Что значит функционал? Не нашёл описание функционала в статье.
Хотя бы процессора вычислительных платформ приведите в сравнении, что бы оценить современность хостера и почему такая цена вышла в итоге.