Neo SPCC liefert neofs-node v0.52.0 mit Platzierungsrichtlinien und Wartungsüberarbeitung
Neo SPCC hat neofs-node v0.52.0 zusammen mit koordinierten Updates für das NeoFS Go SDK und zwei GitHub Actions-Integrationen veröffentlicht, die Unterstützung für anfängliche Platzierungsrichtlinien, erweiterte Wartungstools und Breaking-Konfigurationsänderungen im gesamten Stack einführen. Die Veröffentlichungen spiegeln einen Wandel hin zu einer granularen Objektplatzierungskontrolle und API 2.22-Kompatibilität in der gesamten NeoFS-Infrastruktur wider.
NeoFS ist das verteilte, dezentrale Objektspeichernetzwerk von Neo. Die Version v0.52.0 mit dem Codenamen „Woodo“ folgt auf v0.51.1, mit der Anfang des Jahres neue CLI-Tools und Speicherkorrekturen eingeführt wurden.
Was dies ermöglicht
Richtlinien zur anfänglichen Platzierung geben Containerbetreibern die Kontrolle darüber, wo Objekte anfänglich im Netzwerk gespeichert werden, indem sie den inzwischen veralteten Parameter „copy_number“ durch eine Einstellung „max_replicas“ ersetzen, die an die Platzierungsrichtlinie des Containers gebunden ist. Das umbenannte Wartungstool, neofs-lancet (ehemals neofs-lens), kann jetzt nicht nur den Speicherstatus überprüfen, sondern auch den Speicherstatus ändern, sodass Bediener Metabasen neu synchronisieren, Schreibcaches leeren und Objekte direkt entfernen können. Speicherknotenbetreiber können die gRPC-Konfiguration auch über das SIGHUP-Signal neu laden, ohne die Knoten neu zu starten.
Änderungen am Kernknoten
Die wichtigste Neuerung in v0.52.0 ist die Unterstützung der anfänglichen Platzierungsrichtlinien für Container. Der Parameter copy_number in Objekt-PUT-Anfragen hat keine Auswirkung mehr; Betreiber müssen stattdessen die Einstellung „max_replicas“ in der anfänglichen Platzierungsrichtlinie des Containers verwenden.
Die Version benennt „neofs-lens“ in „neofs-lancet“ um, um den erweiterten Umfang des Tools widerzuspiegeln. Zu den neuen Befehlen gehören „Meta Resync“, „Storage Flush-Write-Caches“, „Meta Remove“ und „Fstree Remove“, wodurch Bediener direkte Kontrolle über Metadaten und den Speicherstatus erhalten.
Zu den Leistungsverbesserungen gehören die Policer-Optimierung (der Policer startet jetzt von einem zufälligen Offset und iteriert Objektlisten auf Engine-Ebene), eine neue Konfigurationsoption Policer.boost_multiplier und eine optimierte lokale HEAD/GET-Anforderungsausführung. Neue Objektzählermetriken für Root-, Zeitstempel-, Sperr-, Link- und Garbage-Collection-Objekte ersetzen den vorherigen Logikzähler.
Breaking Changes und Migration
Entwickler, die ein Upgrade auf v0.52.0 durchführen, sollten sich einiger wichtiger Änderungen bewusst sein:
Speicherknoten löschen nun dauerhaft Objekte, die zu unbezahlten Containern gehören. In den Versionshinweisen heißt es: „Daten werden dauerhaft von Shards gelöscht, eine Wiederherstellung ist nicht möglich.“
Die Konfigurationsoption „node.persistent_sessions.path“ (seit Version 0.50.0 veraltet), „storage.shards.resync_metabase“ und „replikator.pool_size“ wurden alle entfernt.
Speicherknoten migrieren Metabasen nicht mehr automatisch von Version 5 auf 6 oder von Version 6 auf 7. Operatoren älterer Versionen müssen mit SN v0.51.1 migrieren oder mit v0.52.0 neu synchronisieren.
Speicherknoten geben nicht signierte Antworten auf Anfragen mit API v2.22 oder höher zurück.
Das CLI-Flag --await ist für Containerbefehle veraltet.
Die Veröffentlichung erfordert Go 1.25 oder höher und aktualisiert Abhängigkeiten, einschließlich neofs-sdk-go auf v1.0.0-rc.18 und neo-go auf v0.118.0.
SDK- und GitHub-Aktionsaktualisierungen
Neo SPCC hat außerdem neofs-sdk-go v1.0.0-rc.18 ausgeliefert, das Go SDK für NeoFS, das jetzt mit API 2.22 kompatibel ist.
Das SDK fügt eine AuthUser()-API für Sitzungstoken und Unterstützung für anfängliche Platzierungsrichtlinien hinzu, die den Kernknoten widerspiegeln. Das Waiter-Paket ist veraltet (wird ab API 2.21 nicht mehr benötigt) und PrmObjectPutInit.SetCopiesNumber ist veraltet, um dem API 2.22-Übergang weg von copy_number zu entsprechen. Die Version behebt außerdem mehrere Probleme mit dem Sitzungstoken v2 und erzwingt API 2.22-Signaturgrößenbeschränkungen.
Auf der CI/CD-Seite führt gh-push-to-neofs v0.4.0 wichtige Konfigurationsänderungen an der GitHub-Aktion ein, die zum Veröffentlichen von Dateien auf NeoFS verwendet wird. NEOFS_NETWORK_DOMAIN wird durch NEOFS_ENDPOINT ersetzt, das eine vollständige Adresse mit Schema und Port akzeptiert. NEOFS_HTTP_GATE wird durch HTTP_URL_PREFIX für benutzerdefinierte Gateway- und CDN-Unterstützung ersetzt. Die Option STRIP_PREFIX ist jetzt immer aktiviert.
Das Update gh-push-allure-report-to-neofs v0.2.0 fügt Unterstützung für den Verlauf von Allure-Testberichten hinzu und aktualisiert seine Abhängigkeit auf gh-push-to-neofs v0.4.0. Benutzer der Allure-Aktion müssen der gh-push-to-neofs-Migrationsanleitung folgen, um ihre Konfigurationsvariablen zu aktualisieren.
Fehlerbehebungen
Die Knotenversion v0.52.0 behebt einen GC-Deadlock beim Herunterfahren des lokalen Speichers, Probleme bei der Signaturüberprüfung bei gespeicherten Objekten, Fehler bei GAS-Transaktionswiederholungen und Verbesserungen bei der Löschcodierung für die Shard-Evakuierung.
Die SDK-Version behebt Fehler bei der Handhabung von Containerverben und bei der Objektkennung für Legacy-Objekte im Sitzungstoken v2.
Die vollständigen Versionshinweise finden Sie unter dem folgenden Link: 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