Флаг -T не отменяет fork(), я же написал что вы не тянете ее дискуссию о системном программировании можно считать окончательно закрытой. Лучше если есть желание и вы видите что можно еще сделать присоединяйтесь к проекту на github он полностью открыт для этого
Когда технические аргументы про fork(), PTY allocation и блокировки ядра заканчиваются, начинаются призывы к бану и поиск "нейросетей". Это ожидаемо.
Легко рассуждать об идеальных топологиях, пока ваш gpssh или ansible не завис в D-state вместе со всей системой управления. Gorgona создана для тех, кто не боится "нештатных" инструментов, когда штатные превращаются в тыкву.
На этом дискуссию о системном программировании можно считать закрытой. Удачи с вашими идеальными кластерами, в которых никогда ничего не ломается, а если ломается, то всегда можно развести руками и создать тикет на вендера, не так ли.
Терминологические споры оставим аудиторам. С точки зрения системного программирования всё прозаичнее: Почему SSH «ложится», а C-daemon живет: SSH требует fork(), аутентификации через PAM и аллокации PTY. В условиях системного затыка создание процесса - самая дорогая операция. Gorgona - это уже запущенный легковесный процесс на select(). Ему не нужно порождать новые сущности, когда ядро в стрессе. О приоритетах: nice и isolated cores бессильны перед блокировками внутри ядра (kernel locks) и штормом прерываний. Если сетевой стек или подсистема памяти встали в очередь за мьютексом, приоритет процесса в user-space не имеет значения. О сетях: Вы апеллируете к идеальной топологии. В реальности деградация оборудования или каскадные ошибки делают центральный узел управления (Ansible/SSH) точкой отказа. P2P-репликация - это выживаемость управления в условиях изоляции сегментов, а не поиск «правильного» пути по мануалу.
Gorgona написана для ситуаций, когда документация уже не помогает, а «правильно настроенный» кластер перестает отвечать. Если вам хватает штатных средств - значит, вы еще не упирались в настоящий предел живучести системы.
Когда система находится в “терминальной” стадии нагрузки, SSH умирает не из-за сети, а из-за своей архитектуры. Чтобы вы просто увидели приглашение Password:, ядро должно успешно выполнить fork(), отработать тяжелую цепочку PAM и выделить PTY (псевдотерминал). В условиях жесткого дефицита ресурсов или lock-инверсий в ядре, вы получите Connection timed out еще на этапе попытки породить процесс сессии. Gorgona - это резидент. Процесс уже запущен, память аллоцирована, сокет открыт. Ему не нужно просить у системы ресурсы на “рождение” новой сессии в момент шторма - он просто читает байты из потока. В этом и разница: SSH - это парадный вход, который заклинивает первым, когда здание (ОС) начинает вести от нагрузки. Gorgona - это открытая форточка. Чистая системная инженерия против надежды на “nice”.
Для тех, кто управляет Ceph только в учебниках: когда кластер "встает колом" от нагрузки, Management Plane (SSH/Ansible) ложится первым из-за CPU wait и диких лагов, и выделенная сеть тут не спасает.
Gorgona - это не "посмотреть глазами" 500 выводов smartctl. Это возможность через P2P мгновенно выцепить конкретный bottleneck (например, один медленный диск, который тормозит весь recovery), когда центральный мониторинг ослеп или безбожно лагает. Если ваш Ceph при ребалансе всегда отзывчив - поздравляю, вы еще не видели критических нагрузок.
Теория из мануалов - это хорошо, но она редко выживает в 3 часа ночи на кластерах в 30+ нод под нагрузкой в 90%. Про механизмы: Даже штатный gpbackup использует gpbackup_helper на каждом сегменте, чтобы гнать данные в хранилище напрямую. Это единственный способ масштабироваться. Мой инструмент делает то же самое для задач управления (Management Plane): если вы ждете, пока Мастер продышится, чтобы через gpssh проверить стейджинг или ротировать логи, вы уже проиграли по времени. Про ETL: В реальности ETL - это не только SQL. Это подготовка landing-зон, проверка внешних источников и контроль тех самых gpfdist. Делать это через Мастера - значит добровольно создавать “бутылочное горлышко” там, где его быть не должно. Про изоляцию: В распределенных системах узел редко “умирает” совсем, чаще он становится недоступен по прямому каналу. Использовать P2P как “черный ход”, когда SSH висит из-за сетевого шторма - это не “смелое решение”, а профессиональный прагматизм. Gorgona - это не замена механизмам Greenplum. Это независимая нервная система для тех, кто не хочет быть заложником самочувствия Мастера или стабильности центрального коммутатора.
привет, ничего не мешает сделать форк postgres и назвать ветку к примеру postgresx раз это не сделано, значит эти изменения предлагаемые командой Postgres Professional не перевешивают чашу весов работы ванильной команды
У каждого свой подход к управлению рисками. Время расставит всё по местам.
Тем временем, я начал работу над плагином prom_push - модулем мониторинга и доставки метрик через P2P.
Кому близка тема выживаемости систем в условиях изоляции - приглашаю поучаствовать в разработке или обсуждении Roadmap:
https://github.com/psqlmaster/gorgona/tree/master/plugins/prom_push
Флаг -T не отменяет fork(), я же написал что вы не тянете ее
дискуссию о системном программировании можно считать окончательно закрытой.
Лучше если есть желание и вы видите что можно еще сделать присоединяйтесь к проекту на github он полностью открыт для этого
Когда технические аргументы про fork(), PTY allocation и блокировки ядра заканчиваются, начинаются призывы к бану и поиск "нейросетей". Это ожидаемо.
Легко рассуждать об идеальных топологиях, пока ваш gpssh или ansible не завис в D-state вместе со всей системой управления. Gorgona создана для тех, кто не боится "нештатных" инструментов, когда штатные превращаются в тыкву.
На этом дискуссию о системном программировании можно считать закрытой. Удачи с вашими идеальными кластерами, в которых никогда ничего не ломается, а если ломается, то всегда можно развести руками и создать тикет на вендера, не так ли.
Терминологические споры оставим аудиторам.
С точки зрения системного программирования всё прозаичнее: Почему SSH «ложится», а C-daemon живет: SSH требует fork(), аутентификации через PAM и аллокации PTY. В условиях системного затыка создание процесса - самая дорогая операция.
Gorgona - это уже запущенный легковесный процесс на select(). Ему не нужно порождать новые сущности, когда ядро в стрессе. О приоритетах: nice и isolated cores бессильны перед блокировками внутри ядра (kernel locks) и штормом прерываний. Если сетевой стек или подсистема памяти встали в очередь за мьютексом, приоритет процесса в user-space не имеет значения. О сетях: Вы апеллируете к идеальной топологии. В реальности деградация оборудования или каскадные ошибки делают центральный узел управления (Ansible/SSH) точкой отказа. P2P-репликация - это выживаемость управления в условиях изоляции сегментов, а не поиск «правильного» пути по мануалу.
Gorgona написана для ситуаций, когда документация уже не помогает, а «правильно настроенный» кластер перестает отвечать. Если вам хватает штатных средств - значит, вы еще не упирались в настоящий предел живучести системы.
Когда система находится в “терминальной” стадии нагрузки, SSH умирает не из-за сети, а из-за своей архитектуры. Чтобы вы просто увидели приглашение Password:, ядро должно успешно выполнить fork(), отработать тяжелую цепочку PAM и выделить PTY (псевдотерминал). В условиях жесткого дефицита ресурсов или lock-инверсий в ядре, вы получите Connection timed out еще на этапе попытки породить процесс сессии. Gorgona - это резидент. Процесс уже запущен, память аллоцирована, сокет открыт. Ему не нужно просить у системы ресурсы на “рождение” новой сессии в момент шторма - он просто читает байты из потока. В этом и разница: SSH - это парадный вход, который заклинивает первым, когда здание (ОС) начинает вести от нагрузки. Gorgona - это открытая форточка. Чистая системная инженерия против надежды на “nice”.
Для тех, кто управляет Ceph только в учебниках: когда кластер "встает колом" от нагрузки, Management Plane (SSH/Ansible) ложится первым из-за CPU wait и диких лагов, и выделенная сеть тут не спасает.
Gorgona - это не "посмотреть глазами" 500 выводов smartctl. Это возможность через P2P мгновенно выцепить конкретный bottleneck (например, один медленный диск, который тормозит весь recovery), когда центральный мониторинг ослеп или безбожно лагает. Если ваш Ceph при ребалансе всегда отзывчив - поздравляю, вы еще не видели критических нагрузок.
Теория из мануалов - это хорошо, но она редко выживает в 3 часа ночи на кластерах в 30+ нод под нагрузкой в 90%.
Про механизмы: Даже штатный gpbackup использует gpbackup_helper на каждом сегменте, чтобы гнать данные в хранилище напрямую. Это единственный способ масштабироваться. Мой инструмент делает то же самое для задач управления (Management Plane): если вы ждете, пока Мастер продышится, чтобы через gpssh проверить стейджинг или ротировать логи, вы уже проиграли по времени.
Про ETL: В реальности ETL - это не только SQL. Это подготовка landing-зон, проверка внешних источников и контроль тех самых gpfdist. Делать это через Мастера - значит добровольно создавать “бутылочное горлышко” там, где его быть не должно. Про изоляцию: В распределенных системах узел редко “умирает” совсем, чаще он становится недоступен по прямому каналу. Использовать P2P как “черный ход”, когда SSH висит из-за сетевого шторма - это не “смелое решение”, а профессиональный прагматизм.
Gorgona - это не замена механизмам Greenplum. Это независимая нервная система для тех, кто не хочет быть заложником самочувствия Мастера или стабильности центрального коммутатора.
привет, ничего не мешает сделать форк postgres
и назвать ветку к примеру postgresx
раз это не сделано, значит эти изменения предлагаемые командой Postgres Professional не перевешивают чашу весов работы ванильной команды