ага "главный вопрос — сможет ли он вписаться в культуру Anthropic.". а Мария Ивановна из села соседнего, прошла курс (вставить ссылку) и устроилась в Anthropic руководителем тимлидов, тк борщ на всех сварила и сметанку принесла. Она смогла, и ты сможешь!
хм, "у неё появилось больше предложений о работе", те предложения были, но она не согласилась?! Это как в той книге сверхуспешных, где "Открываем первые страницы. У моих родителей был самолет"?
А что плохого, что будет больше контента на тему Zero Trust? Тема была всегда актуально и просвещать нужно постоянно, что бы не забывали. Я думаю, что вы прекрасно знаете про разнообразие, закрытие всего и вся на разных уровнях, количества решения от вендоров, а банально, придя в офис перетыкаете шнурок от принтера в свой ноут и вы уже в корп.сети. Много историй ходит в интернете. Что касается VDI, это вариант решения для для удаленщиков, чтобы ИБ спецам было проще контролировать. На мой взгляд, самое простое и эффективное. Вы можете предложить свой вариант.
Если все давать на откуп вендору, чтобы он все продумал, и телепатическим способом узнал про нюансы до реализации - это слишком хорошо был бы. На практике, специалисты должны быть с обоих сторон. Я про Заказчика и Вендора. Заказчик должен понимать, что конкретно ему нужно, является ли это для него угрозой и закрывать согласно имеющемуся бюджету и приоритету.
Не соглашусь с вами! Это выдержка из большого материала про ИБ. Аудитории на конференции хорошо она зашла и было много вопросов, как на минималках реализовать защиту на уровне zerotrast. Эта статья как ответ на многие вопросы.
кстати, полностью с вами согласен. Для своих личных маленьких инсталляция для тестов, я проксмос всегда брал, когда был целиком хост/нода в наличии, а вот где нужно было быстро и чтобы было кому задавать вопросы ispsystem решения рассматривал. Но это все под личные маленькие локальные ИТ задачки.
Не совсем вас понял. Я не видел провайдеров, которые в 2 раза увеличивали счет за ресурсы. Если мой личный опыт, рассматривать как ответ, то по стоимости домашнего ПК, который собирал себе 1,5 года назад и сейчас идентичное железо в 2 раза дороже стоит в маркетплейсе, увы.
в данной статье vmware суммарно, как вендор решение платформы виртуализации с ESXI, vSphere, CloudDirector, vSAN и прочие, без разбивки на конкретные составляющие.
все верно. Совсем недавно было у меня так: был проект "чтобы работала" на одном хосте, то ставил esxi free, если надо было чуть сложнее, то ставил hyper-v, если для мини внутреннего хостинга, то PROXMOX и так далее А сейчас стало чуть сложнее, особенно требования ИБ и регуляторов и приходится изучать прочие решения
Вы правы. По причине объема текста статьи, пока только эту часть опубликовали. По платформам виртуализации, особенно отечественным, требуется уточнения данных. Этим как раз и занимаюсь.
Про «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. Разные инструменты для разных задач. Дополню раздел.
ага "главный вопрос — сможет ли он вписаться в культуру Anthropic.". а Мария Ивановна из села соседнего, прошла курс (вставить ссылку) и устроилась в Anthropic руководителем тимлидов, тк борщ на всех сварила и сметанку принесла.
Она смогла, и ты сможешь!
в отдельном стоящем случае, да вы полностью правы. 258 дней, - глобальный средний показатель времени Dwell Time (жизни угрозы). Те среднемаксимальное время когда нашли проблему и ее закрыли или приняли меры. Отчет IBM и Ponemon Institute «Стоимость утечки данных в 2024 году»
хм, "у неё появилось больше предложений о работе", те предложения были, но она не согласилась?! Это как в той книге сверхуспешных, где "Открываем первые страницы. У моих родителей был самолет"?
Спасибо. Рад был стараться.
Согласен с вами, тема обобщения и структурирования материалов задача из сложных и нужных
Если есть предложения темы, которая вам интересная в рамках Zero Trust, с удовольствием ее освящу и соавторов найду. Либо тут или в ЛС пишите. Спасибо
А что плохого, что будет больше контента на тему Zero Trust? Тема была всегда актуально и просвещать нужно постоянно, что бы не забывали. Я думаю, что вы прекрасно знаете про разнообразие, закрытие всего и вся на разных уровнях, количества решения от вендоров, а банально, придя в офис перетыкаете шнурок от принтера в свой ноут и вы уже в корп.сети. Много историй ходит в интернете.
Что касается VDI, это вариант решения для для удаленщиков, чтобы ИБ спецам было проще контролировать. На мой взгляд, самое простое и эффективное. Вы можете предложить свой вариант.
полностью с вами согласен. Самое сложное это ТЗ в данном процессе. Одни должны все описать, а другие посчитать и не просчитать.
Если все давать на откуп вендору, чтобы он все продумал, и телепатическим способом узнал про нюансы до реализации - это слишком хорошо был бы.
На практике, специалисты должны быть с обоих сторон. Я про Заказчика и Вендора. Заказчик должен понимать, что конкретно ему нужно, является ли это для него угрозой и закрывать согласно имеющемуся бюджету и приоритету.
Конкретного вендора по защите ZeroTrust вы выбирайте самостоятельно. Статья не про рекламу.
Не соглашусь с вами! Это выдержка из большого материала про ИБ. Аудитории на конференции хорошо она зашла и было много вопросов, как на минималках реализовать защиту на уровне zerotrast.
Эта статья как ответ на многие вопросы.
кстати, полностью с вами согласен. Для своих личных маленьких инсталляция для тестов, я проксмос всегда брал, когда был целиком хост/нода в наличии, а вот где нужно было быстро и чтобы было кому задавать вопросы ispsystem решения рассматривал. Но это все под личные маленькие локальные ИТ задачки.
Я уже больше шести лет не слышу о них в своём окружении.
У вас есть секретная информация?
Не совсем вас понял. Я не видел провайдеров, которые в 2 раза увеличивали счет за ресурсы. Если мой личный опыт, рассматривать как ответ, то по стоимости домашнего ПК, который собирал себе 1,5 года назад и сейчас идентичное железо в 2 раза дороже стоит в маркетплейсе, увы.
в данной статье vmware суммарно, как вендор решение платформы виртуализации с ESXI, vSphere, CloudDirector, vSAN и прочие, без разбивки на конкретные составляющие.
все верно. Совсем недавно было у меня так: был проект "чтобы работала" на одном хосте, то ставил esxi free, если надо было чуть сложнее, то ставил hyper-v, если для мини внутреннего хостинга, то PROXMOX и так далее
А сейчас стало чуть сложнее, особенно требования ИБ и регуляторов и приходится изучать прочие решения
Вы правы. По причине объема текста статьи, пока только эту часть опубликовали. По платформам виртуализации, особенно отечественным, требуется уточнения данных. Этим как раз и занимаюсь.
Спасибо, что напомнили про 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. Разные инструменты для разных задач. Дополню раздел.