Advanced Settings

This tab provides advanced tuning for S3 connection management and DNS resolution.

These settings are important when your ObjectScale storage endpoints use round-robin DNS names. A round-robin name is a single DNS hostname that resolves to multiple data node IP addresses, with TTL=0 to signal that clients should not cache the result.

By default, Java and the Apache HTTP connection pool both defeat round-robin DNS:

• Java caches DNS answers internally for 30 seconds, regardless of what the DNS record says.
• The connection pool keeps TCP connections open indefinitely.

Configure both settings on this tab to enable effective load balancing.

DNS Cache TTL

The default is 5 seconds.

This is how long the JVM caches DNS responses internally. Java keeps its own DNS cache layer, separate from the operating system resolver, and it ignores the TTL on DNS records. With the default 30-second JVM cache, a DNS name with TTL=0 (round-robin) is still pinned to one IP for 30 seconds.

5 seconds is the recommended value for ObjectScale round-robin endpoints. It gives a small safety buffer, because multiple rapid connections in a burst share one lookup. It also ensures you get a fresh round-robin pick within 5 seconds.

A value of 0 would make every new connection issue a DNS query. It would also turn off the fallback to the last good answer, which needs a value above 0. For that reason vault agents do not apply 0 and keep the 5-second default.

Where the setting applies

Component	Behavior
Vault agents	They receive the value on the next heartbeat and use it from their next start. Java reads its DNS cache settings once, when the process starts, so a running agent keeps its current value.
Console	It does not use this setting. It caches DNS answers for 5 seconds, set when it starts.
Copy agents	They do not receive it either. Their DNS cache comes from their JVM profile (Setup & Settings > Diagnostics > JVM Profiles).

The built-in JVM profiles turn the cache off (-Dsun.net.inetaddr.ttl=0). Every new connection then resolves the name again, and connections spread across the nodes behind a round-robin DNS name.

When a DNS lookup fails

The console and vault agents keep using the last good answer for that name for up to 15 minutes, for example while the DNS server is down. This avoids failing every new connection. The value is set when each process starts and is not configurable on this tab.

Copy agents on a built-in profile keep no answers, so their copies pause instead. A copy whose lookup fails waits and retries for up to 15 minutes before the object fails. Its multipart upload is kept.

Connection Pool TTL

The default is 30 seconds.

This is the maximum age of a pooled TCP connection to an S3 endpoint. When a connection in the pool is older than this value, it is replaced on next use. This forces a new TCP connection and a fresh DNS lookup.

Without this setting, pooled TCP connections live indefinitely. All S3 traffic stays on whichever data node was first resolved when the job started, even as other nodes become available or a node is taken out of service.

With 30 seconds, each copy thread reconnects about every 30 seconds under continuous copy activity. This redistributes connections across all nodes that DNS round-robins.

info

For multipart uploads, an individual upload part uses the same connection. The reconnect happens between objects or between upload initiations, not mid-stream.

The setting is applied to all new S3 clients created after you save. For vault agents, it is delivered on the next heartbeat and applied when the next job's client is built.

How the two settings work together

Both settings are required. Neither alone achieves effective round-robin distribution.

Scenario	Result
Only DNS Cache TTL = 5s	DNS re-resolves every 5 seconds, but the connection pool reuses the same TCP socket indefinitely. No new DNS lookup ever fires.
Only Connection Pool TTL = 30s	New connections are made every 30 seconds, but the JVM DNS cache returns the same IP it cached 30 seconds ago. There is no rotation.
Both set (recommended)	Connections expire, a new TCP connect is triggered, the DNS cache has expired, a fresh DNS query runs, and the connection can land on a new node.

When to change these values

Situation	Recommendation
Production ObjectScale with DNS load balancing	Use the defaults (5s DNS, 30s pool).
Single-node ObjectScale or IP-addressed endpoints	These settings have no effect, because DNS round-robin is not in use.
Very high connection rate (thousands per second)	Increase the pool TTL to reduce connection churn.
Fast failover requirement	Decrease both values, for example 1s DNS and 10s pool, to detect node failures faster.

Both values reach vault agents on the next scheduled heartbeat. The default is every 2 hours, configurable per agent.

A new DNS Cache TTL takes effect on a vault agent at its next start. A new Connection Pool TTL also applies to console S3 clients created after you save.

CyberVault Target Skip Mode defaults

The four CyberVault Target Skip Mode controls are on this tab (Setup & Settings > Advanced Settings). They pre-populate the advanced section of the dispatch dialog that appears when an operator selects Target Skip in the Copy mode select.

Target Skip Mode is a full-copy mode selected per job in the Copy mode select (Standard, Smart Skip, or Target Skip). When Target Skip is selected, the worker compares each source object against the live target vault bucket using a tiered algorithm.

Skip tiers

Tier	Description
Tier 1	Strict ETag and size match. Always on, with negligible false-skip risk.
Tier 1.5	Size match and source Last-Modified before a cutoff date you enter. Opt-in. It trusts size and date only, for buckets already copied by the previous product before that date.
Tier 2	Provenance marker probe. Opt-in. See below.
Tier 2.5	Three-position range-hash content probe. Opt-in. See below.
Tier 3	Copy fallback. Every Tier 3 copy writes the x-amz-meta-source-etag marker. The next Target Skip job against this target then recognizes the copy through Tier 2, even when the source and target multipart schemes differ.

Tier 2 reads the target object's user metadata. It accepts either of these markers:

• x-amz-meta-source-etag, written by every Tier 3 copy this console makes.
• The legacy x-amz-meta-x-emc-source-etag, written by ecs-sync with "Store Source Object Copy Markers" enabled.

Both keys mean that the source ETag at the time of the previous copy was X. If X matches the current source ETag, the target carries the same content and is safe to skip.

Tier 2.5 reads a sample chunk at the beginning, middle, and end of objects at or above the minimum size, and compares the hashes. It detects only changes that fall inside the sampled ranges. Detection of small changes elsewhere in the object is low.

warning

Use Tier 2.5 only for read-only source buckets.

Settings on this tab

Setting	Description
Tier 2 enable	Pre-populates the Tier 2 checkbox in the dispatch dialog when Target Skip is selected.
Tier 2.5 enable	Pre-populates the Tier 2.5 checkbox in the dispatch dialog when Target Skip is selected.
Tier 2.5 minimum file size (MB)	Default 5 MB. Objects below this size are copied if Tier 1 and Tier 2 did not match.
Tier 2.5 sample chunk size (MB)	Default 1 MB. The size of each sampled range.

The two sizing controls are operator-only. They apply to every job that runs with Tier 2.5 on, and there is no per-job override.

For the full Target Skip Mode reference, see the "Copy modes" section of the Cyber Vault > Copy Jobs - Live View & History help page.

Target Skip never modifies the live database. All logic is read-only against the source and target buckets. Skipped rows are written to cyber_vault_copy_log (ClickHouse) only.

How changes propagate

Changes propagate to vault agents through the encrypted HEARTBEAT_CONFIG QTD channel on the next heartbeat. The audit trail is visible in Vault Operations > Quantum Trust Protocol Audit Log with the HEARTBEAT_CONFIG message type.

Changes take effect for new jobs only. In-flight jobs use the values captured at dispatch time.

Audit Event Ingestion Filter (ObjectScale only)

This filter controls which S3 HTTP methods the ObjectScale SSH audit ingest keeps. It applies to ObjectScale audit collection only.

Every audit event ObjectScale logs carries an HTTP method: PUT, DELETE, GET, HEAD, or POST. If you clear a method here, every future event of that method is discarded the moment it is decoded. It is never summarized, never inserted into ClickHouse, and never appears in search, reports, or dashboards for this appliance.

danger

This is not a display filter and it cannot be undone. Discarded events are not stored anywhere. Selecting a box again later does not recover anything that was already dropped. Only events arriving from that point forward are kept.

Changes apply starting with the next ingest run, not retroactively. The setting is read fresh on every ingest run, so no agent or console restart is needed. The change takes effect on the next scheduled or manually triggered ingest.

Defaults

Method	Default	Why
PUT	Retained	Object written. This is how the console detects a change.
DELETE	Retained	Object deleted.
GET	Dropped	Object read, including bucket-listing calls (a GET with a list-type query parameter). Usually the largest single source of ingest volume on read-heavy buckets.
HEAD	Dropped	Metadata-only check, with no object data transferred.
POST	Dropped	Multipart and other write-adjacent calls.

warning

The default loses changes made by multipart uploads. The console catches a multipart write only through its part PUT calls. If the Complete call (a POST) lands in a later window than the last part, the new version of the object is not seen. Until this is fixed, consider retaining POST if your applications write large objects.

Where dropped counts appear

For any ECS_SSH_INGEST job, the job detail flyout on the Jobs page shows a Dropped (filtered) count and a Dropped % card whenever events were filtered. Dropped % is dropped events divided by total decoded events for that job.

Both values update live while the job runs and remain on the completed job. A large gap between "Records Decoded" and "Records Inserted" therefore reads as intentional filtering, not data loss.