Cryptonews

Neo SPCC выпускает neofs-node v0.52.0 с политиками размещения и капитальным ремонтом

Источник
cryptonewstrend.com
Опубликовано
Neo SPCC выпускает neofs-node v0.52.0 с политиками размещения и капитальным ремонтом

Neo SPCC выпустила neofs-node v0.52.0 вместе с скоординированными обновлениями NeoFS Go SDK и двумя интеграциями GitHub Actions, введя поддержку политики первоначального размещения, расширенные инструменты обслуживания и критические изменения конфигурации во всем стеке. Эти выпуски отражают переход к детальному управлению размещением объектов и совместимости API 2.22 в инфраструктуре NeoFS.

NeoFS — это распределенная децентрализованная сеть хранения объектов Neo. Версия 0.52.0 под кодовым названием «Woodo» последовала за версией 0.51.1, в которой ранее в этом году были представлены новые инструменты CLI и исправления хранилища.

Что это дает

Политики первоначального размещения дают операторам контейнеров контроль над тем, где объекты изначально хранятся в сети, заменяя устаревший параметр copy_number на параметр max_replicas, привязанный к политике размещения контейнера. Переименованный инструмент обслуживания neofs-lancet (ранее neofs-lens) теперь может изменять состояние хранилища в дополнение к его проверке, позволяя операторам повторно синхронизировать метабазы, очищать кэши записи и напрямую удалять объекты. Операторы узлов хранения также могут перезагрузить конфигурацию gRPC через сигнал SIGHUP без перезапуска узлов.

Изменения основного узла

Главным дополнением в версии 0.52.0 является поддержка политики первоначального размещения контейнеров. Параметр copy_number в запросах PUT объекта больше не имеет никакого эффекта; Вместо этого операторы должны использовать параметр max_replicas в политике первоначального размещения контейнера.

В новой версии neofs-lens переименован в neofs-lancet, чтобы отразить расширение возможностей инструмента. Новые команды включают в себя повторную синхронизацию метаданных, очистку кэша с записью в хранилище, удаление метаданных и удаление fstree, что дает операторам прямой контроль над метаданными и состоянием хранилища.

Улучшения производительности включают оптимизацию ограничителя (теперь ограничитель запускается со случайным смещением и повторяет списки объектов уровня механизма), новый параметр конфигурации policyr.boost_multiplier и оптимизированное выполнение локальных запросов HEAD/GET. Новые метрики счетчика объектов для корневых объектов, объектов временной метки, блокировки, ссылок и сборки мусора заменяют предыдущий логический счетчик.

Критические изменения и миграция

Разработчики, обновляющиеся до версии 0.52.0, должны знать о нескольких критических изменениях:

Узлы хранения теперь безвозвратно удаляют объекты, принадлежащие неоплаченным контейнерам. Согласно примечаниям к выпуску: «Данные будут безвозвратно удалены из осколков, восстановление невозможно».

Опция конфигурации node.persistent_sessions.path (устарела с версии 0.50.0), Storage.shards.resync_metabase и Replicator.pool_size были удалены.

Узлы хранения больше не переносят автоматически метабазы ​​с версии 5 на 6 или с версии 6 на 7. Операторы более старых версий должны выполнить миграцию с использованием SN v0.51.1 или выполнить повторную синхронизацию с v0.52.0.

Узлы хранения возвращают неподписанные ответы на запросы с API версии 2.22 или выше.

Флаг CLI --await устарел для команд контейнера.

Для выпуска требуется Go 1.25 или выше, а также обновляются зависимости, включая neofs-sdk-go до v1.0.0-rc.18 и neo-go до v0.118.0.

Обновления SDK и GitHub Actions

Neo SPCC также предоставила neofs-sdk-go v1.0.0-rc.18, Go SDK для NeoFS, который теперь совместим с API 2.22.

SDK добавляет API AuthUser() для токенов сеанса и поддержку политики первоначального размещения, отражающей основной узел. Пакет waiter устарел (больше не нужен в API 2.21 или более поздней версии), а PrmObjectPutInit.SetCopiesNumber устарел, чтобы соответствовать переходу API 2.22 от copy_number. В выпуске также исправлено несколько проблем с токенами сеанса версии 2 и установлены ограничения на размер подписи API 2.22.

Что касается CI/CD, gh-push-to-neofs v0.4.0 вносит критические изменения в конфигурацию действия GitHub, используемого для публикации файлов в NeoFS. NEOFS_NETWORK_DOMAIN заменяется на NEOFS_ENDPOINT, который принимает полный адрес со схемой и портом. NEOFS_HTTP_GATE заменяется на HTTP_URL_PREFIX для поддержки пользовательского шлюза и CDN. Опция STRIP_PREFIX теперь всегда включена.

Обновление gh-push-allure-report-to-neofs v0.2.0 добавляет поддержку истории отчетов об испытаниях Allure и обновляет его зависимость до gh-push-to-neofs v0.4.0. Пользователи действия Allure должны следовать руководству по миграции с gh-push на neofs, чтобы обновить свои переменные конфигурации.

Исправления ошибок

В выпуске узла v0.52.0 устранена взаимоблокировка GC при отключении локального хранилища, проблемы с проверкой подписи хранимых объектов, сбои повторных попыток транзакций GAS, а также улучшены коды стирания для эвакуации сегментов.

В выпуске SDK исправлены ошибки обработки команд контейнера и идентификаторов объектов для устаревших объектов в токене сеанса версии 2.

Полные примечания к выпуску можно найти по ссылке ниже: https://github.com/nspcc-dev/neofs-node/releases/tag/v0.52.0 https://github.com/nspcc-dev/neofs-sdk-go/releases/tag/v1.0.0-rc.18 https://github.com/nspcc-dev/gh-push-to-neofs/releases/tag/v0.4.0 https://github.com/nspcc-dev/gh-push-allure-report-to-neofs/releases/tag/v0.2.0