Comments 12
на кой etl запускать на сегмент узлах ? ну и грузить с помощью gpfdist на отвалившихся от кластера узлах - смелое решение.
Теория из мануалов - это хорошо, но она редко выживает в 3 часа ночи на кластерах в 30+ нод под нагрузкой в 90%.
Про механизмы: Даже штатный gpbackup использует gpbackup_helper на каждом сегменте, чтобы гнать данные в хранилище напрямую. Это единственный способ масштабироваться. Мой инструмент делает то же самое для задач управления (Management Plane): если вы ждете, пока Мастер продышится, чтобы через gpssh проверить стейджинг или ротировать логи, вы уже проиграли по времени.
Про ETL: В реальности ETL - это не только SQL. Это подготовка landing-зон, проверка внешних источников и контроль тех самых gpfdist. Делать это через Мастера - значит добровольно создавать “бутылочное горлышко” там, где его быть не должно. Про изоляцию: В распределенных системах узел редко “умирает” совсем, чаще он становится недоступен по прямому каналу. Использовать P2P как “черный ход”, когда SSH висит из-за сетевого шторма - это не “смелое решение”, а профессиональный прагматизм.
Gorgona - это не замена механизмам Greenplum. Это независимая нервная система для тех, кто не хочет быть заложником самочувствия Мастера или стабильности центрального коммутатора.
Это «доверенный канал управления через недоверенную сеть». Вы можете управлять серверами даже через публичный интернет, не боясь перехвата или подделки коман
vs.
написал распределенный Cron на C с P2P-репликацией и зачем это нужно админам Greenplum
так это канал управления или это Cron?
Когда в Ceph начинается «шторм» (rebalancing) после падения дисков, нагрузка на сеть и CPU зашкаливает. Пытаться пробиться по SSH на каждый из 500 OSD-узлов в этот момент - сомнительное удовольствие.
Пример про Ceph — какой-то запредельный уровень натяжения совы на глобусе, зря вы так зверушек мучаете. Начнём с того, что продовые Ceph-кластеры для репликации используют выделенную сеть (а если почему-то нет, то хотя бы управление трафиком! Но это уже начинает попахивать). Далее — получить от «500 OSD-нод» занятого-кластера выхлоп «smartctl или iostat» — чтобы что?! :) У вас по легенде сеть перегружена, зачем вам smartctl/iostat в моменте — 500 их, на минуточку. Тут становится очевидным, что вы и понятия не имеете о том, как администрируются storage-кластеры (и возникает закономерное подозрение про кластеры вообще).
Так и видится:
— Эй, Васян, что там с нашим кластером на 500 OSD-нод?!
— Да хз! Через SSH не могу на 500 нод попасть! Ща, через Горгону smartctl запущу, всё ясно станет!
P. S. \@
Для тех, кто управляет Ceph только в учебниках: когда кластер "встает колом" от нагрузки, Management Plane (SSH/Ansible) ложится первым из-за CPU wait и диких лагов, и выделенная сеть тут не спасает.
Gorgona - это не "посмотреть глазами" 500 выводов smartctl. Это возможность через P2P мгновенно выцепить конкретный bottleneck (например, один медленный диск, который тормозит весь recovery), когда центральный мониторинг ослеп или безбожно лагает. Если ваш Ceph при ребалансе всегда отзывчив - поздравляю, вы еще не видели критических нагрузок.
Для тех, кто управляет Ceph только в учебниках
Этот ваш «полёт фантазии» — от того, кто Ceph вообще не устанавливал ни разу. Не говоря уж про его продовое использование.
Management Plane (SSH/Ansible) ложится первым из-за CPU wait и диких лагов
CPU wait? Вы же начали про перегруженную сеть!
Потом про диски. 😅
Теперь вдруг 😅😅 — CPU wait.
Вряд ли вы знаете что такое CPU wait (скорее всего банально спутав его с iowait), да и судя по той чуши, которую с апломбом несёте — мало-что знаете по теме в принципе, но да ладно. Wait — ожидание, CPU — ну понятно, да, что не диск, лол. Когда возникает ситуация "CPU wait" — планировщик вынужденно маринует процессы в очереди на доступ к процессору. Если Васян с кластером на 500 OSD-узлов допустил такое, это, конечно, не Чернобыль, но Горгону Васяну установят ректально. И да, абстрагируясь от способов её установки — то есть, SSH там в "CPU wait", а Горгона — по волшебству — на проце и с него не слазит? А smartctl/iostat (и прочие страшные слова, которыми ограничивается ваше знание предмета) — их-то страдающий кластер будет вынужден запустить из Горгоны на своих немощных нодах — они не будет в CPU wait(?)…
И вообще — не смущает, что вместо, прямо скажем, извращений с Горгоной, можно было бы SSH (да и весь control plane) с высоким приоритетом запускать — чтобы они не ловили CPU wait? В Linux kernel банально хватает инструментов для этого: начиная от скрепного "nice" и вплоть до CPU isolated cores. Более того — в продакшн кластерах Ceph такие ресурсы, как проц и память, выделяются дозировано — тот же ceph orch штатно позволяет задавать нужные spec'и per daemon. Если Васян всё это продолбил — установка Горгоны неминуема, но не тем способом, который Васяну понравится, понимаете?
В любых нормальных кластерах Ceph системные daemons (пресловутый management plane про который вы с пенкой изо рта пишете) не используют storage диски самого Ceph. Диски Ceph — отдельно, системные — отдельно. И сеть для репликации Ceph — отдельная сеть. Более того, часто выделяется и отдельная сеть для management/monitoring.
В общем, я вам советую не позориться, неровен час работодатель заметит — выводы сделает не в пользу ни Горгоны, ни её автора.
Терминологические споры оставим аудиторам.
С точки зрения системного программирования всё прозаичнее: Почему 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”.
Gorgona написана для ситуаций, когда документация уже не помогает
Мм, от-оно-чо. Ну тут уж как говорится «нейрослоп детектедъ».
P. S. Надеюсь, информация которую я привёл кому-то может оказаться полезной, а таких вот персонажей (с их горгонами) по хорошему банить-бы надо. ;)
Когда технические аргументы про fork(), PTY allocation и блокировки ядра заканчиваются, начинаются призывы к бану и поиск "нейросетей". Это ожидаемо.
Легко рассуждать об идеальных топологиях, пока ваш gpssh или ansible не завис в D-state вместе со всей системой управления. Gorgona создана для тех, кто не боится "нештатных" инструментов, когда штатные превращаются в тыкву.
На этом дискуссию о системном программировании можно считать закрытой. Удачи с вашими идеальными кластерами, в которых никогда ничего не ломается, а если ломается, то всегда можно развести руками и создать тикет на вендера, не так ли.
Когда технические аргументы про fork(), PTY allocation
man ssh|grep allocation
-T Disable pseudo-terminal allocation.
-t Force pseudo-terminal allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty alloca‐«Gorgona написана для ситуаций, когда документация уже не помогает» — говорили они. Не уточняя кому именно «документация не помогает». 😅
дискуссию о системном программировании можно считать закрытой
👋
Флаг -T не отменяет fork(), я же написал что вы не тянете ее
дискуссию о системном программировании можно считать окончательно закрытой.
Лучше если есть желание и вы видите что можно еще сделать присоединяйтесь к проекту на github он полностью открыт для этого
Вы видимо Горгону ставить пока не будите 😂😂👍
У каждого свой подход к управлению рисками. Время расставит всё по местам.
Тем временем, я начал работу над плагином prom_push - модулем мониторинга и доставки метрик через P2P.
Кому близка тема выживаемости систем в условиях изоляции - приглашаю поучаствовать в разработке или обсуждении Roadmap:
https://github.com/psqlmaster/gorgona/tree/master/plugins/prom_push
Как я написал распределенный Cron на C с P2P-репликацией и зачем это нужно админам Greenplum