#high_performance_computing — Public Fediverse posts

Как восстановить KRaft-кворум после потери большинства контроллеров

Представьте себе баг-репорт: все шесть подов в статусе 1/1 Running, Readiness зелёный, kafka-agent на брокерах отдаёт 204. А кластер мёртв: оператор бесконечно крутит реконсайл и валится в TimeoutException: Timed out waiting for a node assignment. Call: describeMetadataQuorum. Если зайти на том контроллера, можно увидеть, что __cluster_metadata-0/quorum-state: leaderId выставлен, а appliedOffset в 0. Ни одна запись метаданных не применена. JVM живые, raft-лог на диске растёт, и при этом ни один под не написал в stdout ни строки следующие восемь часов. Это не выдумка, а реальный баг-репорт Strimzi от 25 мая 2026 , и к нему мы ещё вернёмся. В Kafka 4.x больше нет привычного «запасного выходa» в виде ZooKeeper: метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. Раньше чтобы с этим справиться в Kafka существовал ZooKeeper, отдельная система со своими инструментами, ансамблем и культурой восстановления. В версии 4.x его нет, и в документации от процедуры остался только линк на 3.9 . Метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. В этой статье расскажем, что делать в такой ситуации и как восстанавливать этот кворум, чтобы не случилось ситуации, описанной выше.

https://habr.com/ru/companies/vktech/articles/1064848/

#vk_cloud #bare_metal #выделенные_серверы #гибридная_инфраструктура #onpremises #виртуализация #gpu_нагрузки #infiniband #high_performance_computing #erp_crm_системы

Как восстановить KRaft-кворум после потери большинства контроллеров

Представьте себе баг-репорт: все шесть подов в статусе 1/1 Running, Readiness зелёный, kafka-agent на брокерах отдаёт 204. А кластер мёртв: оператор бесконечно крутит реконсайл и валится в TimeoutException: Timed out waiting for a node assignment. Call: describeMetadataQuorum. Если зайти на том контроллера, можно увидеть, что __cluster_metadata-0/quorum-state: leaderId выставлен, а appliedOffset в 0. Ни одна запись метаданных не применена. JVM живые, raft-лог на диске растёт, и при этом ни один под не написал в stdout ни строки следующие восемь часов. Это не выдумка, а реальный баг-репорт Strimzi от 25 мая 2026 , и к нему мы ещё вернёмся. В Kafka 4.x больше нет привычного «запасного выходa» в виде ZooKeeper: метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. Раньше чтобы с этим справиться в Kafka существовал ZooKeeper, отдельная система со своими инструментами, ансамблем и культурой восстановления. В версии 4.x его нет, и в документации от процедуры остался только линк на 3.9 . Метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. В этой статье расскажем, что делать в такой ситуации и как восстанавливать этот кворум, чтобы не случилось ситуации, описанной выше.

https://habr.com/ru/companies/vktech/articles/1064848/

#vk_cloud #bare_metal #выделенные_серверы #гибридная_инфраструктура #onpremises #виртуализация #gpu_нагрузки #infiniband #high_performance_computing #erp_crm_системы

Как восстановить KRaft-кворум после потери большинства контроллеров

Представьте себе баг-репорт: все шесть подов в статусе 1/1 Running, Readiness зелёный, kafka-agent на брокерах отдаёт 204. А кластер мёртв: оператор бесконечно крутит реконсайл и валится в TimeoutException: Timed out waiting for a node assignment. Call: describeMetadataQuorum. Если зайти на том контроллера, можно увидеть, что __cluster_metadata-0/quorum-state: leaderId выставлен, а appliedOffset в 0. Ни одна запись метаданных не применена. JVM живые, raft-лог на диске растёт, и при этом ни один под не написал в stdout ни строки следующие восемь часов. Это не выдумка, а реальный баг-репорт Strimzi от 25 мая 2026 , и к нему мы ещё вернёмся. В Kafka 4.x больше нет привычного «запасного выходa» в виде ZooKeeper: метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. Раньше чтобы с этим справиться в Kafka существовал ZooKeeper, отдельная система со своими инструментами, ансамблем и культурой восстановления. В версии 4.x его нет, и в документации от процедуры остался только линк на 3.9 . Метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. В этой статье расскажем, что делать в такой ситуации и как восстанавливать этот кворум, чтобы не случилось ситуации, описанной выше.

https://habr.com/ru/companies/vktech/articles/1064848/

#vk_cloud #bare_metal #выделенные_серверы #гибридная_инфраструктура #onpremises #виртуализация #gpu_нагрузки #infiniband #high_performance_computing #erp_crm_системы

The Unreasonable Effectiveness of Multiple Dispatch in Julia (2019)
https://www.youtube.com/watch?v=kc9HwsxE1OY
#ycombinator #high_performance_computing #machine_learning #hpc #parallel_computing #julia_programming_language #Language #artificial_intelligence #Julia #julia #data_science

The Unreasonable Effectiveness of Multiple Dispatch in Julia (2019)
https://www.youtube.com/watch?v=kc9HwsxE1OY
#ycombinator #high_performance_computing #machine_learning #hpc #parallel_computing #julia_programming_language #Language #artificial_intelligence #Julia #julia #data_science

The Unreasonable Effectiveness of Multiple Dispatch in Julia (2019)
https://www.youtube.com/watch?v=kc9HwsxE1OY
#ycombinator #high_performance_computing #machine_learning #hpc #parallel_computing #julia_programming_language #Language #artificial_intelligence #Julia #julia #data_science

The Unreasonable Effectiveness of Multiple Dispatch in Julia (2019)
https://www.youtube.com/watch?v=kc9HwsxE1OY
#ycombinator #high_performance_computing #machine_learning #hpc #parallel_computing #julia_programming_language #Language #artificial_intelligence #Julia #julia #data_science

Riverlane, Rigetti Computing And Oak Ridge National Laboratory Partner to Improve HPC-Quantum Integration https://thequantuminsider.com/?p=2361145 #Quantum_Computing_Business #Research #High_performance_computing #HPC #hybrid_quantum #ORNL #Riverlane_Rigetti #quantumdaily Insider Brief A group of tech teams are working together to explore the challenges of integrating a quantum computer with a large-scale, supercomputing centre. The partnership includes team members from Riverlane, Rigetti Comp