Облака это скорее подход к организации работы с инфрой. Они бывают частные и мы во многом на них и ориентируемся, поэтому амортизация актуальна)
Рассматривается же запуск Postgres/Neon на ноде куба, т.е. тарифицируется нода куба, а не запущенные поды/контейнеры на ней.
Вопрос в том сколько баз мы можем запихнуть на ноду используя Neon и классические операторы (даже без учета HA) Мы сейчас готовим материал в рамках которого рассмотрим экономику использования, кейсы применения и метрики которые можно получить в рамках этих кейсов
Так если он и так поднят и как выше написал, мы платим за целую ноду куба, то какой профит от него вне бессерверных контейнерах?
Количество compute в пулле не равно количеству созданных Compute в рамках кластера. В пулле может быть небольшое количество подов по 0,25 vCPU, главное чтобы его размер позволял поднять в моменте необходимое количество Compute.
А бизнесу никто не сказал, что теперь каждый запрос к БД (S3) будет не бесплатным?
Запросы у бизнеса никогда не бывают бесплатными тк всегда будет амортизация инфры, сопровождение и еще множество процессов. Если мы учитываем эти деньги вопрос экономики становится не таким однозначным. Например на большом количестве баз гибкие инсталляции будут дешевле тк дают возможность переиспользовать ресурсы и по итогу закупать меньше железа для он-прем инсталляций или арендовать меньше кубера под кластер в облаке.
Которая в итоге выльется в 1-2 секунды. Т.к. трафик не будет направлен в под до тех пор, пока тот не перейдет в состояние "Ready". Все пробы в Kubernetes имеют минимальное значение 1 сек.
Архитектура позволяет поднимать нужный Compute из подготовленных подов те поднятие Compute из idle приводит к апдейту c нужным конфигом, а не к созданию нового пода. Пулл потребляет небольшую часть ресурсов, но дает возможность не дожидаться поднятия пода.
Добрый день. По сетям, дополнительно изучил вопрос и если мы говорим про on-prem инсталляции и некоторые облака (не все дают установить свой CNI) ваше уточнение верно, спасибо.
По жирным POD:
Да, при очень жирных POD-ах возможна фрагментация ресурсов, но в случае с Neon это частично нивелируется:
Подходом к вертикальному масштабированию - через CU, все ресурсы в линейной зависимости от CPU;
Возможностью шардирования на уровне Storage;
Наличием Autoscaler с собственным планировщиком;
В целом за счёт разделения Compute/Storage фрагментация ресурсов в Neon не такая уж проблема по сравнению с классическим PostgreSQL в k8s;
По S3 vs RBD:
Продукту важно быть универсальным (on-prem и облака) и чаще в инфраструктуре клиента есть S3, а не блочные устройства;
RBD сложнее использовать в сценариях с Multi-RW доступом - потребуется использовать какую-то параллельную ФС отдельным слоем, что вносит существенную сложность в поддержке;
Привет, очень рад, что статья оказалась полезной. Сложность и риски миграции с классического PostgreSQL на Neon зависят от выбранной версии. Если речь идет об Open Source Neon, то придется преисполниться и потратить время на разработку недостающих компонентов (там правда не хватает многих сервисов, а некоторые os приходится патчить). В остальном миграцию можно осуществлять любыми стандартными инструментами Postgres.
Привет, спасибо за вопрос! Мы пишем серию статей про Neon, детальные бенчмарки по производительности и работе под разными профилями нагрузки мы представим в следующей статье. По поводу брокеров, для распределенных систем подобная реализация скорее необходимость которую можно встретить в том или ином виде и в других реляционных базах (пр. AWS Aurora, CockroachDB, YugabyteDB)
Привет, в классических Postgres (операторы не исключение) миграции и хелмы/плейбуки — наше всё, и кажется, ничего лучше не придумать. В Neon дев и стейдж фактически унифицированы, т.к. это stateless Compute, который поднимается из одних образов, а тюнинг доступных параметров осуществляется при работе с управлялкой кластера. Тут важно заметить, что многие задачи решаются самим Neon в рамках автоматизированных сценариев. Например, так как Neon сам занимается upscale и downscale задачами, помимо добавления непосредственно ресурсов к экземплярам он апдейтит конфиги (при добавлении новых ядер он автоматически апдейтит значения max_parallel_workers и т.д.).
Миграции в Neon также отличаются. За счёт ветвления базы можно создавать изолированные копии прода, на которые можно накатить и предварительно прогнать изменения (например, создание и удаление тестового стенда в рамках CI/CD). Но по итогу нам необходимо либо переключить прод на релизную ветвь, либо накатить миграцию на prod-ветвь.
Облака это скорее подход к организации работы с инфрой. Они бывают частные и мы во многом на них и ориентируемся, поэтому амортизация актуальна)
Вопрос в том сколько баз мы можем запихнуть на ноду используя Neon и классические операторы (даже без учета HA) Мы сейчас готовим материал в рамках которого рассмотрим экономику использования, кейсы применения и метрики которые можно получить в рамках этих кейсов
Количество compute в пулле не равно количеству созданных Compute в рамках кластера. В пулле может быть небольшое количество подов по 0,25 vCPU, главное чтобы его размер позволял поднять в моменте необходимое количество Compute.
Запросы у бизнеса никогда не бывают бесплатными тк всегда будет амортизация инфры, сопровождение и еще множество процессов. Если мы учитываем эти деньги вопрос экономики становится не таким однозначным. Например на большом количестве баз гибкие инсталляции будут дешевле тк дают возможность переиспользовать ресурсы и по итогу закупать меньше железа для он-прем инсталляций или арендовать меньше кубера под кластер в облаке.
Архитектура позволяет поднимать нужный Compute из подготовленных подов те поднятие Compute из idle приводит к апдейту c нужным конфигом, а не к созданию нового пода. Пулл потребляет небольшую часть ресурсов, но дает возможность не дожидаться поднятия пода.
Добрый день. По сетям, дополнительно изучил вопрос и если мы говорим про on-prem инсталляции и некоторые облака (не все дают установить свой CNI) ваше уточнение верно, спасибо.
По жирным POD:
Да, при очень жирных POD-ах возможна фрагментация ресурсов, но в случае с Neon это частично нивелируется:
Подходом к вертикальному масштабированию - через CU, все ресурсы в линейной зависимости от CPU;
Возможностью шардирования на уровне Storage;
Наличием Autoscaler с собственным планировщиком;
В целом за счёт разделения Compute/Storage фрагментация ресурсов в Neon не такая уж проблема по сравнению с классическим PostgreSQL в k8s;
По S3 vs RBD:
Продукту важно быть универсальным (on-prem и облака) и чаще в инфраструктуре клиента есть S3, а не блочные устройства;
RBD сложнее использовать в сценариях с Multi-RW доступом - потребуется использовать какую-то параллельную ФС отдельным слоем, что вносит существенную сложность в поддержке;
Привет, очень рад, что статья оказалась полезной. Сложность и риски миграции с классического PostgreSQL на Neon зависят от выбранной версии. Если речь идет об Open Source Neon, то придется преисполниться и потратить время на разработку недостающих компонентов (там правда не хватает многих сервисов, а некоторые os приходится патчить). В остальном миграцию можно осуществлять любыми стандартными инструментами Postgres.
Привет, спасибо за вопрос! Мы пишем серию статей про Neon, детальные бенчмарки по производительности и работе под разными профилями нагрузки мы представим в следующей статье. По поводу брокеров, для распределенных систем подобная реализация скорее необходимость которую можно встретить в том или ином виде и в других реляционных базах (пр. AWS Aurora, CockroachDB, YugabyteDB)
Привет, в классических Postgres (операторы не исключение) миграции и хелмы/плейбуки — наше всё, и кажется, ничего лучше не придумать. В Neon дев и стейдж фактически унифицированы, т.к. это stateless Compute, который поднимается из одних образов, а тюнинг доступных параметров осуществляется при работе с управлялкой кластера. Тут важно заметить, что многие задачи решаются самим Neon в рамках автоматизированных сценариев. Например, так как Neon сам занимается upscale и downscale задачами, помимо добавления непосредственно ресурсов к экземплярам он апдейтит конфиги (при добавлении новых ядер он автоматически апдейтит значения max_parallel_workers и т.д.).
Миграции в Neon также отличаются. За счёт ветвления базы можно создавать изолированные копии прода, на которые можно накатить и предварительно прогнать изменения (например, создание и удаление тестового стенда в рамках CI/CD). Но по итогу нам необходимо либо переключить прод на релизную ветвь, либо накатить миграцию на prod-ветвь.