This document addresses high-level technical frequently asked questions (FAQs) for ObjectScale.

This document is primarily intended for Dell personnel who are not familiar with ObjectScale.

Dell Technologies and the authors of this document welcome your feedback on this document. Contact the Dell Technologies team by email.

Author: ObjectScale Technical Marketing

Note: For links to other documentation for this topic, see the ObjectScale and ECS Info Hub.

Question: What is the difference between Dell ECS and ObjectScale?

Beginning in April 2025, Dell Technologies simplified the object storage experience by converging ECS and ObjectScale into a single, unified platform. This next-generation solution is optimized for the AI era, empowering our thousands of object storage customers to innovate and scale with confidence.

This new generation of Dell object storage will carry over everything customers love from ECS — including its codebase, architecture, UI and APIs — with a non-disruptive upgrade from ECS 3.8.x to the modernized ObjectScale operating environment, backed by other highly demanded enhancements. Continuous innovation now delivered under the ObjectScale brand (e.g., AI‑optimized performance, SDS, analytics‑ready S3 in ObjectScale 4.3)

Question: Can I upgrade directly from ECS 3.8 to ObjectScale 4.3? 

No. You cannot directly upgrade from ECS 3.8 to ObjectScale 4.3. ECS 3.8 can upgrade to ObjectScale 4.0 or 4.1, and ObjectScale 4.3 can be upgraded only from ObjectScale 4.1 and 4.2 releases.

Question: What are the durability and availability numbers for ObjectScale? How many nines does ObjectScale guarantee?

Data durability of a storage system provides guarantees for data being stored in the system without loss or corruption. ObjectScale supports local and multi-site protection of data, and regular systematic data integrity checks with self-healing capabilities. ObjectScale durability is 99.999999999 (eleven 9’s).

Data availability of a storage system provides guarantees for the system to successfully process data (read/write requests) and depends on factors outside of ObjectScale control, including equipment/connectivity/power failures. ObjectScale availability is 99.999 (five 9’s) based on request-error-rate estimates. 

Question: What is a Chunk?

Data and system metadata are written in chunks on ObjectScale. An ObjectScale chunk is a 128MB logical container of contiguous space. Each Replication Group will have its own allocation of chunks for buckets and objects associated with the Replication Group. Each chunk can have data from different objects. ObjectScale uses indexing to keep track of all parts of an object that might be spread across different chunks and nodes.

Chunks are written in an append-only pattern. The append-only behavior means that an application’s request to modify or update an existing object will not modify or delete the previously written data within a chunk, but rather the new modifications or updates will be written in a new chunk. For that reason, no locking is required for I/O, and no cache invalidation is required. 

Question: How does ObjectScale protect data?

At the heart of ObjectScale software is a Storage Engine that is responsible for laying out all data in 128 MB chunks across the system. User data, metadata, and system data are written to a different logical chunk that will contain 128 MB of data. Chunks are both triple-mirrored and erasure coded.

The triple-mirror write method is applicable to the ObjectScale journal chunks, of which ObjectScale creates three replica copies. Each replica copy is written to a single disk on different nodes. This method protects the chunk data against two-node or two-disk failures. 

The erasure coding with redundant data segments write method is applicable to ObjectScale btree chunks and custom object metadata. It includes 12 data segments, 12 replicated data segments, and 4 parity segments for the 12+4 erasure coding scheme. The new btree chunk-redundant data EC scheme saves metadata protection overhead. In the all-flash architecture like EXF900, the btree chunks and custom object metadata protection is triple mirroring.

Triple mirroring plus in place erasure coding is applicable to a chunk containing the data from any object that is less than 128 MB in size. ObjectScale creates three replica copies of a chunk that contains user data. One copy is written in fragments that are spread across different nodes within the cluster. The remaining two copies are written in their entirety to different nodes. After a chunk is sealed, parity is calculated and written to disk, after which the two replica copies written to individual nodes are removed. This process optimizes write performance for small objects, initially using triple mirroring for protection but ultimately leaves the chunk protected by erasure coding.

Inline erasure coding is used for objects that are 128 MB or larger. This process calculates parity as part of the initial write, which is distributed across nodes in the Virtual Data Center (VDC). This process does not create replica copies which optimizes large write performance and saves disk I/O.

For geographically distributed systems, replication group policies determine how data is protected and where it can be accessed. Data that is geo-replicated is protected by storing a primary copy of the data at the local site and a secondary copy of data at one or more remote sites. Each site is responsible for local data protection, meaning that both the local and secondary site will individually protect the data using erasure coding and/or triple mirroring. Replication is performed asynchronously, and data is added to a replication queue as it is written to the primary site. There are worker I/O threads continuously processing the queue. With more than two sites in a replication group, where “Replicate to All Sites" is off, an XOR mechanism can be used which serves to reduce overhead significantly. See the Dell ObjectScale Overview and Architecture Guide for more details.

Question: What are the limitations regarding Storage Pool, VDCs, RGs, Namespaces, Buckets, Objects?

The storage that is associated with a VDC must be assigned to a storage pool and the storage pool must be assigned to one or more replication groups to allow the creation of buckets and objects. While the VDC can have a storage pool defined for any of the four Erasure Coding schemes (12+4 with minimum of five nodes,10+2 with minimum of seven nodes, 24+4 with minimum eight nodes and 24+2 with minimum of 14 nodes), the best practice is to have all nodes associated to one storage pool for a given VDC. A node cannot exist in more than one storage pool. The storage pool can span racks, but it is always within a site. When the storage pool reaches 90% of its total capacity, it does not accept write requests and it becomes a read-only system. A storage pool can be associated with more than one replication group. 

The maximum number of VDC’s per ObjectScale federation and/or replication group is eight. 

Replication groups are limited to the possible variations in topology of federated VDCs.  Best practice is to create replication groups that match the access and protection requirements for the data being written across the federated sites. Most customers create a local replication group for a VDC where data should be kept local to the VDC and one or more geo-replicated groups consisting of two or more VDCs for geo-protection of the data. Each replication group has chunks allocated for the buckets and objects associated to it. An HDD cluster can be associated with up to 8 RGs, while an AFA cluster can be associated with up to 3 RGs.

There are no limitations to the number of namespaces that can be created. A namespace has a set of configured users who can store and access objects within the namespace. Users from one namespace cannot access the objects that belong to another namespace. An object in one namespace can have the same name as an object in another namespace. ObjectScale can identify objects by the namespace qualifier.

There are no limitations to the number of buckets that can be created, nor are there limitations to the number of objects that can be created in a given bucket. A bucket is assigned to a namespace and object users are also assigned to a namespace. An object user can create buckets only in the namespace to which the object user is assigned.

Question: Which systems are supported on ObjectScale 4.3 code?

Question: Which hardware models support Tech Refresh?

ObjectScale tech refresh supports the below hardware models which are running on 4.x and higher ECS code.

• Gen2 -> Gen3 (Gen2-> EX500, EX5000)
• Gen3 -> Gen3 (EX300, EX3000, EX500, EX5000-> EX500, EX5000)
• Gen2/Gen3 -> Gen4 (Gen2/Gen3 -> X560)
• Gen3 -> Gen4 (EXF900 -> XF960) - New

Note: ObjectScale OS versions on new nodes must match the existing nodes in the VDC.  The ObjectScale code is pushed from existing nodes to the new nodes.

Question: Can I perform a tech refresh from EXF900 to XF960 for ObjectScale all‑flash appliances? 

Yes. ObjectScale 4.3 enables seamless tech refresh from Gen3 EXF900 to Gen4 XF960 nodes within the same Virtual Data Center (VDC), without manual data migration or application downtime. Administrators can introduce XF960 nodes, decommission EXF900 nodes, and let ObjectScale automatically rebalance data in the background, maintaining service availability and performance during the transition.

Question: What are the detailed steps of an ObjectScale Tech Refresh?

Tech Refresh is an automated, data-in-place service. The process involves these technical steps:

Rack Extend:

• Reimage new rack nodes using same OS version as the original rack nodes.
• Generate cluster.ini after upgrading to latest Service Console
• Edit cluster.ini and add new rack nodes
• Perform extend by adding new rack nodes to existing cluster
• Add newly extended nodes to storage pool and VDC from UI/API
• Rerun extend command for post extend checks
• Add extended nodes

Data Migration:

• Trigger data migration from original nodes (source) to newly extended nodes (target)
• Check the data migration progress and completion status using:
  • Service Console Output
  • ObjectScale UI storage pool 
  • Grafana Migration Report

Node Evacuation:

• Run Node evacuation command on current installer node to set up new installer node.
• Run the Node evacuation command from new installer node
• Rerun the command on the same node to check the status
• Node evacuation complete

Checks after tech refresh:

• Service Console health check
• ObjectScale UI without the evacuated nodes

For more details, see the Professional Servers Procedures under SolVe.

Question: What are the types of Garbage Collection and how are they defined?

There are two garbage collection methods used by ObjectScale to reclaim space from discarded chunks, depending on whether said chunks consist of entirely deleted objects or a mixture of deleted and non-deleted objects. They are: 

• Normal Garbage Collection - When an entire chunk is garbage, reclaim space. 
• Partial Garbage Collection by Merge - When a chunk is 50% garbage, reclaim the chunk by merging the valid parts of with other partially filled chunks to a new chunk, reclaim space. 

Question: What are the new Garbage Collection Service Modes and how are they implemented?

Service Modes (conservative, normal and aggressive) are enabled in the ObjectScale UI in the Settings -> Service Modes section.  They let you tune how hard the system works to reclaim space verses preserving foreground performance. You can dynamically or calendar-schedule (for example, conservative/normal during business hours and aggressive overnight), so garbage collection cleans up deleted data much faster when the cluster is idle without slowing down production workloads when it’s busy.

Question: What automation platforms are supported and what is included?

Terraform provides infrastructure-as-code automation for provisioning and managing key ObjectScale control-plane resources, so you can define the environment declaratively and let Terraform create and maintain it for you.

Capabilities include:

• Multi-tenancy / namespaces – create, read, update, delete, and import namespaces.
• Bucket management – full CRUD lifecycle for S3 buckets.
• IAM entities – CRUD for IAM users, groups, roles, and policies used by ObjectScale.
• Replication groups – define and manage cross-site/object replication topology.
• Management and object users – automate user provisioning for admin and data access.
• (Planned next phase) Read-only queries for storage pools and VDCs to drive more advanced automation and reporting.

Although Ansible is not officially supported with ObjectScale today, it is possible to use Ansible Playbooks to automate the creation of namespaces, object users, buckets, and so on. 

Question: What kind of file types are supported by S3 Select?

S3 select supports .csv, JSON and parquet formats, plus it supports querying gzip/bzip2 compressed objects of the aforementioned file types.

Question: What are the latest compression capabilities and ObjectScale’s ability to report on compression savings?

ObjectScale now provides workload-tuned compression with bucket-level control and real-time reporting of savings. 

Latest compression capabilities

• Bucket-level compression policies so each bucket can use the most appropriate algorithm (for example, no-compress, zstd, deflate, LZ4) for its workload.
• Fine-grained tuning of data behavior per bucket to balance throughput vs. efficiency for different datasets (media, backups, structured data).
• Works alongside existing cluster-level compression as part of “workload-tuned data compression and visibility.”

Reporting on compression savings

• Per-bucket compression ratio is calculated and stored in metering tables and exposed through Billing APIs, GUI, and telemetry.
• Metering UI shows compression ratio at the bucket level for S3 buckets created after the upgrade (4.3+), enabling real-time, data-driven TCO optimization.
• Dashboards (for example, Grafana) can track compression ratio and logical vs. physical size over time at bucket and VDC level, making savings and trends easy to visualize.

Question: What is S3FS and why is it important?

S3FS allows ObjectScale buckets to be mounted as local file systems on Linux servers. This makes object data accessible through standard file system operations (ls, cp, edit, etc.), simplifying integration with legacy tools and applications.

What is ObjectScale software‑defined? 

ObjectScale software‑defined is a generally available ObjectScale deployment on qualified Dell PowerEdge servers, starting with the PowerEdge R7725xd. With ObjectScale 4.3, customers can deploy a dense, all‑flash, 2U configuration that brings ObjectScale’s full S3 and geo‑federated feature set to a server‑based design engineered for high‑frequency trading, big AI, CSP‑scale environments, and any use case that requires blazing‑fast performance. By combining 17G PowerEdge performance, high‑capacity NVMe media, and 400 GbE networking, customers can build multi‑petabyte AI data lakes on standardized Dell servers while shrinking rack footprint, boosting per‑rack throughput, and simplifying procurement and lifecycle management.

Question: What ObjectScale appliance configurations are available?

Gen4 hardware includes classes of nodes for the X560:

• The X560 is the latest appliance with easy transition to performance-optimized, multi-cloud, and AI workloads. With options for 6,12 or 24 drives that can hold 2TB, 4TB, 8TB, 16TB, 20TB and 24TB disk options. Clusters range from 60TB to 9.2PB per rack, with a max of 16 nodes in a rack.
• XF960 - The XF960 is an all-flash object storage solution of hyper-converged nodes for low latency and high IOPs ObjectScale deployments. With options for 6, 12 or 24 drives, 7.68TB, 15TB FIPS-certified SED, 30.72TB and 61.44TB NVMe SSD drive options. This platform starts at 230TB minimum configuration and scales to 23.59PB per rack. With ObjectScale 4.3, XF960 all‑flash appliances support 122 TB drives. With ObjectScale 4.3, XF960 all‑flash clusters can be deployed up to seven racks.
• EX5000 is the ObjectScale Gen3 dense appliance. EX5000 has a maximum capacity of 16.8 PB of raw storage per rack using the 24TB disks, and can grow into exabytes across several sites, providing a deep and scalable solution. The EX5000 is a 5U node that can hold up to 100 drives per node. These nodes are available in two different configurations: EX5000S and EX5000D:

• The EX5000S is a single-node chassis with options for 25, 50, 75, or 100 drives.
• The EX5000D is a dual-node chassis with options for 50 or 100 drives.

All drive sizes must be the same within the node. Node sizes may be mixed within a cluster if each new node size is introduced by a minimum size storage group.

All current shipping HDD based nodes now come standard with the caching SSD.  An optional SSD drive for metadata caching is available as of ECS 3.5 for legacy nodes. Former deployments are upgradable using separate drive upgrade kits. If a caching SSD is added to a Virtual Data Center (VDC), every node in the VDC is required to have the caching SSD installed.

Starting from ECS version 3.8, appliances support memory upgrade expansion to 192GB on the EX300, EX500, EX3000, and Gen 2 platforms, with the support of Dell Professional Services.  It is recommended to upgrade nodes to 192GB to support newer features (Data Movement ‘Copy to Cloud’, Event Notifications, etc).

Question: What switches are used?

ObjectScale switching components and architecture were modified to include a back-end (BE) switch network for private admin connections, and a front-end (FE) switch network for customer public network connections. It should be noted that all node-to-node communication still travels over the FE switches for current releases.

For X560 and EX5000 series:

• Two optional Dell Networking S5248F 25 GbE 1U Ethernet switches can be obtained for network connection or the customer can provide their own 25 GbE HA pair for the FE network. If S5248F 25 GbE front-end switches are used, then 2 x 200 GbE VLT cables are needed.
• For the backend (BE), two Dell Networking S5248F 25 GbE 1U Ethernet switches with 48 x 25 GbE SFP ports and 4 x 100 GbE uplink ports and 2 x 200 GbE VLT must be included in the configuration. 

For XF960 series:

• Two optional Dell Networking S5448F 100 GbE 1U Ethernet switches can be obtained for network connection, or the customer may provide their own HA pair for the FE network.
• For the back-end (BE), two Dell Networking S5448F 100 GbE 1U Ethernet switches with 48 x 100 GbE SFP ports and 8 x 400 GbE uplink ports.
• For intra-rack back-end networks, two aggregation switches Dell Z9432 with 32 x 400 GbE ports are needed between multiple racks.

Question: Is there a limit on the number of nodes that ObjectScale can scale up to?

ObjectScale is a distributed system with no limit on the number of nodes. However, for the all-flash appliance, we support up to 112 nodes to maintain optimal performance.

Question: Can EX500 and X560 nodes mix in the same rack?

Yes, but there is an issue with the front door of the EX500 not being able to close with an X560 installed in the rack. Please contact the Dell professional service and follow the KB 297889 for the recommended deployment plan.

Note: KB 297889 requires you to have an account on Dell’s support site.

Question: Are there requirements for adding X560 nodes to an existing VDC regarding drive size?

It is recommended that the drive size of the new nodes matches that of the existing nodes to ensure consistency and optimal performance.

Question: What ECS models support the addition of X560 nodes?

X560 nodes can be added to any Gen2/3 HDD appliance, and all nodes within the system must be running the same ObjectScale 4.x version to ensure compatibility.

Question: Are there a minimum number of nodes required if adding X560 to an existing VDC? What if it spills into or starts a new rack?

When adding capacity in the same rack, the following are the best practices.

• Size/capacity of nodes added must be equal to or greater than the size/capacity of the existing nodes.
• If capacity utilization of the storage pool is below 80 percent, the minimum number of nodes to be added in the same rack is 1:
• If capacity utilization of the storage pool is at or above 80 percent, the minimum number of nodes to be added in the same rack is X:

• X = 3, for storage pools using 12+4
• X = 4, for storage pools using 10+2

When adding an additional rack to an existing configuration, the following are the best practices.

• Size/capacity of nodes added must be equal to or greater than the size/capacity of the existing nodes.
• If capacity utilization of the storage pool is below 80 percent, the minimum number of nodes to be added in the new rack is X:

• X = 3, for storage pools using 12+4
• X = 4, for storage pools using 10+2

• If capacity utilization of the storage pool is at or above 80 percent, the minimum number of nodes to be added must be the same as the number of existing nodes (in a rack).

Question: Do all nodes need to be upgraded to ObjectScale 4.x when adding X560?

Yes, all nodes must be running the same software version. Therefore, existing nodes need to be upgraded to ObjectScale 4.x to ensure compatibility with the X560 nodes.

Question: What if the existing ECS environment has 12TB drives, this is no longer available in the X560 nodes?

The recommendation is that each node has the same or greater raw capacity. For example, the EX500 has 24x12TB drives, the new X560 can be installed with 12x24TB drives, 24x16TB drives or 24x20TB drives.

Question: Do I need to remove the front door of the existing ECS rack in order to fit the X560 nodes? What if the X560 nodes go into a new rack?

KB 297889 explain how to manage the rack front door. X560 new rack will ship with a door that has been reworked to work with X560.

Note: KB 297889 requires you to have an account on Dell’s support site.

Question: How does the X560 network differ from existing ECS, is any special configuration required when running in a mixed node environment?

No special configuration is required. The X560 uses the same networking setup as Gen3 HDD appliances such as the EX500 and EX5000, ensuring seamless integration in a mixed-node environment.

Question: Is the SSD cache drive in the X560 the same as previous nodes?

No, the X560 uses a 1.6 TB NVMe SSD cache drive, whereas previous-generation nodes used a 960 GB SATA SSD. This upgrade provides improved performance and faster data access.

Question: If the X560 has more CPU and memory compared to previous ECS nodes, how does this work regarding performance if part of a mixed node environment?

In a mixed-node environment (e.g., Gen3 and Gen4 nodes), performance may vary depending on workload distribution. In the worst-case scenario, the overall system performance could align with the slowest node in the cluster.

Question: Can EXF900 and XF960 nodes mix in the same rack?

Yes, with ObjectScale 4.1 and later, customers can add XF960 nodes to an existing EXF900 rack. However, mixing the two is not recommended, as the XF960 features high-speed networking that could be bottlenecked by the EXF900, potentially impacting overall performance.

Question: Are there requirements for adding XF960 nodes to an existing VDC regarding drive size?

It is recommended that the drive size of the new nodes matches that of the existing nodes to ensure consistency and optimal performance.

Question: Are there a minimum number of nodes required if adding XF960 to an existing VDC? What if it spills into or starts a new rack?

In ObjectScale 4.1 and later, system expansion is limited to the addition of a single rack of XF960 alongside one rack of EXF900. When both are deployed within the same rack, a QSFP-to-SFP adapter is required to enable 25G connectivity for the XF960. For deployments involving the integration of an XF960 rack into an existing EXF900 environment, specific switch configuration files must be applied to the S5448 and Z9432 switches. Note that S5232 switches will be replaced by Z9432 in this configuration.

Question: How does the XF960 network differ from the existing EXF900, is any special configuration required when running in a mixed node environment?

Other than the switch config files the port rates need to be changed on the Z9432 switches when adding a XF960 rack to an existing EXF900 rack.

Question: If the XF960 has more CPU and memory compared to previous EXF900 nodes, how does this work regarding performance if part of a mixed node environment?

In a mixed-node environment (e.g., Gen3 and Gen4 nodes), performance may vary depending on workload distribution. In the worst-case scenario, the overall system performance could align with the slowest node in the cluster.

Question: What are the common network considerations customers make when deploying ObjectScale?

Each rack has two top-of-rack (TOR) switches which are uplinked to the customer network. The TOR switches carry all traffic except for out-of-band (OOB) management. Best practice is to have a minimum of two uplinks per rack (four minimum). Management, data (read/write) and geo-replication traffic can be separated, virtually or physically, which allows for enhanced security and performance separation.

Question: How many IP addresses are required for an ObjectScale deployment?

A minimum of one IP address for each ObjectScale node is required.  If network separation is implemented (see question on Network Separation for additional details), additional IP addresses will be required per node.

For out of band management, one IP address is required for each ObjectScale node to be managed.

Question: How many switch ports does the customer need to provide?

For each rack a minimum of two 10/25/100 GbE switch ports in the customer's infrastructure are required, one for each uplink from each TOR switch.

No switch ports are required for the BE switch(es) unless the customer wants to have RMM (Remote Management Module) for Gen2 and iDRAC (integrated Dell Remote Assistance Controller) for Gen3/4 access. RMM/iDRAC access is optional and would require one or two switch ports in the customer’s infrastructure depending on topology.

Question: How does network separation work?

ObjectScale supports separating different types of network traffic for security and performance isolation. There is a mode of operation called network separation mode. In this mode, each node can be configured at the operating system level with up to three IP addresses, or logical networks, for each of the three different types of network traffic. This feature has been designed to provide the flexibility of either creating three separate logical networks for management, replication and data, or combining them to either create two logical networks, for instance management and replication traffic is in one logical network and data traffic in another logical network.

Question: What is replication network throttling on multiple sites?

Replication bandwidth can now be controlled. This ensures replication processes do not consume excessive resources and maintains stable performance across workload.  Replication throttling is a process that is implemented to control the maximum bandwidth utilized by replication traffic; it is not a UI based feature to configure/turn on.

Question: Does ObjectScale include a built‑in load balancer?

Yes. ObjectScale 4.3 includes a native, integrated load balancer that can be used in production environments. It eliminates the need for dedicated external load‑balancing hardware or third‑party appliances for front‑end access, simplifying deployments and reducing infrastructure costs. The integrated load balancer provides resilient traffic distribution, automatic node health detection, and active/active availability for single‑site and multi‑rack environments, helping unify cluster entry points and lower TCO.

Question: Which authentication providers are available with ObjectScale?

ObjectScale supports Active Directory, LDAP, and Keystone v3, an OpenStack project that provides identity, token, catalog, and policy services. Keystone compatibility allows ObjectScale to be a drop-in replacement for OpenStack Swift. Authentication providers enable control and monitoring of administration users, not object access users.

Note: IAM is only for data (bucket/object) accessed by the S3 protocol.

Question: What methods are available to monitor ObjectScale?

The WebUI (ObjectScale Portal), integrated Grafana, CLI, SNMP, SMTP, REST API, and Dell SRM are available to provide information about the health of ObjectScale. Also available is Dell Secure Connect Gateway which provides a secure two-way communication between Dell storage systems and the support system for proactively identifying and responding to possible issues. SNMP queries for basic health metrics such as CPU and memory are available as are traps for critical events. Remote syslog support is available. SNMPv2 and SNMPv3 (USM mode) are supported.

Question: What metrics does the management system report (such as raw storage capacity, usable capacity, CPU utilization, and current IOPS) and how are they defined?

There is a monitoring page in the ObjectScale UI. It includes metering data for namespaces, or buckets within namespaces, capacity utilization, system Health, transactions, recovery status, disk bandwidth and geo replication. There is also an advanced monitoring section which uses Grafana which is integrated within the ObjectScale UI, it includes data access performance metrics. For more details about these metrics, see the ObjectScale administrator guide.

Question: What types of Event Notification does ObjectScale provide?

The system supports adding SNMP, Syslog and SMTP servers to the system to route event notifications.

During the ObjectScale installation process, customer support representatives can configure and start an snmpd server to support specific monitoring of ObjectScale node-level metrics. A Network Management Station client can query these kernel level snmpd servers to gather information about memory and CPU usage from the ObjectScale nodes, as defined by standard Management Information Bases (MIBs).

Syslog servers provide a method for centralized storage and retrieval of system log messages. The system supports forwarding of alerts and audit messages to remote syslog servers and supports operations using the BSD Syslog and Structured Syslog application protocols.

Simple Mail Transfer Protocol (SMTP) can be used for email alerting from the ObjectScale system. You can configure multiple servers in the system. The platform provides options to add multiple senders and recipients for email alerts. You can configure email alerts on the basis of the severity level of alerts. You must enable the SMTP channel and configure one SMTP server to use this feature.

Question: What are the refresh times for data shown in the ObjectScale UI?

On monitoring displays, you can force a table to refresh with the latest data by clicking the Refresh icon.

Question: What are the definitions for total, used, available, and reserved capacity?

• Total: Total capacity of the system that is online. This is the total of the capacity that is already used and the capacity still free for allocation.
• Used: Used online capacity in the system. It includes User Data, System Metadata, Protection Overhead, Geo data, and Garbage.
• Available/reserved: Online capacity available for use, including the approximately 10% of the total capacity that is reserved for failure handling and for performing erasure encoding or XOR operations.

Question: How does ObjectScale efficiently write both small and large unstructured data?

For smaller writes to storage, ObjectScale uses a method called box carting to minimize impact to performance. Box carting aggregates multiple smaller writes of 2MB or less in memory and writes them in a single disk operation. Box carting limits the number of roundtrips to disk required process individual writes.

For writes of larger objects, nodes within ObjectScale can process write requests for the same object simultaneously and take advantage of simultaneous writes across multiple spindles in the ObjectScale cluster. Writes of objects less than 128MB in size are tripled mirrored across three nodes, with one of the three being distributed in its erasure coded format, waiting for the chunk to completely fill before calculating the EC bits. Objects larger than 128MB in size skip the triple mirroring step, with 128MB portions of the object distributed in its erasure coded format across the nodes in the storage pool. Thus, ObjectScale can ingest and store small and large objects efficiently.

Question: Can the same object in ObjectScale be accessed by different protocols?

CAS objects are only accessible by their own API. NFS and Dell Atmos can access each other’s created objects using path-based style. S3, NFS, and Swift can interoperate such that objects created in any of these protocols can be accessed by any one of them as well.

Question: How does ObjectScale work with Hadoop?

ObjectScale supports the Hadoop S3A client for storing Hadoop data. S3A is an open source connector for Hadoop, based on the official Amazon Web Services (AWS) SDK. It was created to address storage scaling and cost problems that many Hadoop admin were having with HDFS. Hadoop S3A connects Hadoop clusters to any S3 compatible object store.

Question: What is the API connection limit?

All the REST APIs (S3, Atmos, Swift) go through an http server component called netty. The effective limit for REST protocols has been 1000 active connections per node. Connection limit can be increased under support guidance.

For the CAS API, it has a maximum of 600 active connections per node.

Question: Which AWS SDK version does ObjectScale support?

ObjectScale 4.2 and later supports the AWS Java SDK version 2.3, enabling developers to leverage the latest AWS S3 features and performance optimizations.

Question: What are S3 Tables in ObjectScale 4.3?

ObjectScale 4.3 introduces a non‑production tech preview of S3 Tables, delivering fast, cost‑efficient analytics directly on ObjectScale. With native Apache Iceberg REST Catalog support, table data and metadata live directly in S3, allowing engines such as Spark, Trino, and Starburst to query data in place without data movement or proprietary warehouses. Built on open standards, S3 Tables simplify analytics architecture, reduce dependencies, secure data end‑to‑end, and help avoid vendor lock‑in.

Question: Does ObjectScale support S3 over RDMA for GPU‑accelerated workloads?

Answer: Yes. S3 over RDMA with GPUdirect access remains available as a tech preview feature for non‑production environments across the all‑flash portfolio—ObjectScale software‑defined on PowerEdge R7725xd,  XF960, and EXF900. By integrating Dell’s S3‑over‑RDMA SDK with GPU support and a RoCEv2 networking stack, ObjectScale can bypass traditional TCP and CPU bottlenecks, providing a near‑direct path between GPUs and object storage for demanding AI and machine learning pipelines.

Question: What is S3 Mountpoint and how does it work with ObjectScale?

S3 Mountpoint allows ObjectScale S3 buckets to be mounted as a native file system so that applications can perform familiar read, write, delete, and modify operations using standard file system semantics. By qualifying S3 Mountpoint with ObjectScale and aligning its behavior with S3 semantics, customers can manage S3‑compatible data using existing tools and workflows, simplifying data access in large‑scale deployments.

Question: Does ObjectScale provide a set of Management REST APIs to programmatically view and configure the environment?

ObjectScale provides a comprehensive Management REST API to perform any action that is capable through the UI and is covered in the ObjectScale Data Access Guide.  Online documentation is available at developer.dell.com in the APIs section; offline documentation in the form of a HMTL is also available for download in the ObjectScale support downloads section.

Question: What is ObjectScale CAS missing that Centera customers should be aware of?

Data shredding is not available currently in ObjectScale CAS. As of 3.0 all Advanced Retention Management (ARM) features such as event-based retention, litigation holds, and the Min/Max governor are available. NOTE:  ARM features are available for CAS only.

Question: What does the Transformation engine do?

The Centera Transformation and Migration feature allows organizations to natively (within ObjectScale software) and seamlessly migrate ObjectScale-compatible applications to ObjectScale from Centera. The practically non-disruptive application cutover allows data to be moved as a background process. As of 3.0, migrations can be administered using the Web UI.

Question: Are there any caveats to migrating data from Centera to ObjectScale?

Yes. ObjectScale Sync and Datadobi migration tools cannot migrate Centera legacy data to ObjectScale without disruption to existing EBR and/or LH information. ObjectScale's built-in transformation engine does support migrating Centera legacy data with EBR and/or LH.

Question: Which ports are required for clients to access over NFS?

2049 (nfsd TCP, mountd TCP/UDP, statd TCP), 10000 (nlockmgr TCP/UDP) and 111 (portmapper TCP/UDP)

Note: Services are part of ObjectScale software and not exposed by the underlying operating system.

Question: What are the primary use cases for NFS on ObjectScale?

• Archiving or primarily sequential writes.
• Applications currently using file that will be modified later to use object.

Question: What are the implications of the "server-side" metadata caching the ObjectScale NFS implementation uses to increase performance by reducing related disk operations?

Metadata is cached by nodes for the NFS operations they serve to clients. The cache allows for serving metadata quicker than is possible if disks access is required for each operation. Changes to metadata are not globally tracked across nodes and as such will not get reflected instantly across nodes. If client1 and client2 both connect to the same ObjectScale node, both of them see the same information since it is either being served from the same cache or disk.

Metadata in cache is considered alive until it times out. This means if a change is made directly on disk for an object, and a client subsequently performs a listing operation on that object, older data from cache will be returned to the client until the time at which the cache expires. After expiration requests for the metadata will be served from disk and cache repopulated with the most recent information. If client1 and client2 connect to different ObjectScale nodes, then there is a possibility that they see different information, if related metadata exists in cache, until the cache times out. Basically, metadata is cached locally to each ObjectScale node and is not globally coherent.

Question: Are there no known limitations or hard-coded values for max number of directories or files per directory?

There are no known limitations, but the more files in the directory, the longer listing contents will take to complete.

Question: Is there a max file size in ObjectScale?

For NFS only, the maximum file size allowed is 16 TB.

Question: How do storage administrators configure NFS access to a bucket?

Along with creating the exports, for a user to access a file over NFS, a mapping must be created between a bucket user and UNIX UID and GID. With this mapping ObjectScale can translate the UID and GID received over the wire as part of the NFS operation to a bucket user to determine access. ObjectScale does not retrieve user mapping from authentication sources, that is, all mappings must be created by a storage administrator.

Similarly, for access from a client configured with Kerberos, a mapping between principal names and UID/GID is required so that ObjectScale can return a UID and GID over the wire to the client in its response.

Detailed steps to enable File System Access on a Bucket and to create an NFS export are provided in the ObjectScale Admin Guide

Question: What authentication methods are supported for ObjectScale NFS?

ObjectScale NFS supports sys, krb5, krb5i, krb5p.

Question: Does ObjectScale support all NFS v3 operations?

ObjectScale NFS supports all NFSv3 procedures EXCEPT for LINK: Create hard link to an object.

Question: Can files be accessed over NFS during a site outage?

Read access over NFS is available, just like with all other protocol access, during a site outage. Write access over NFS depends on the zone ownership of the affected path during outage.

For example, a three-site replication group contains an Access During Outage (ADO) enabled namespace, ns1, and ns1 contains file-system-enabled bucket, b1, which is also configured with ADO enabled. A three-directory-deep path exists in b1, and each directory was created and is owned by a different site/zone. /ns1/b1/dir1/dir2/dir3.

If site 2, owner of dir2, is temporarily unavailable, contents in dir2 are read-only during outage but contents in dir1 (owned by site 1) and dir3 (owned by site 3) remain writable.

Question: What is the expected behavior during the loss of one or more disks?

Data that exists on failed disks will be reconstructed on available capacity across other nodes and disks, using either the remaining erasure coded data and parity fragments or the replica copies. When the failed disk is replaced, it is used as free capacity.

For more details on node failures, see the Dell ObjectScale: High Availability Design white paper.

Question: What is the expected behavior during loss of node(s)?

Any request for system metadata owned by a node that is not responding, will trigger the requested metadata ownership to be redistributed across the remaining nodes in the site. When this redistribution completes, the request for system metadata will complete successfully. Data that exists on disks from the unresponsive node will be reconstructed using either the remaining erasure coded data and parity fragments or the replica copies.  

• Concurrent failure: When nodes fail concurrently it means nodes fail almost simultaneously, or a node fails before recovery from a previous failed node completes.
• One-by-one failure: When nodes fail one by one it means one node fails, all recovery operations complete and then a second node fails. This can occur multiple times and is analogous to a VDC going from something like four sites to three sites to two sites to one site. This requires that the remaining nodes have sufficient space to complete recovery operations.

For erasure-coded content for each single site, the following chart is provided for the minimum node count for each Erasure Coding scheme.

Note: 24+4 and 24+2 erasure coding schemes introduced in ObjectScale 4.3

The basic rules for determining what operations fail in a single site with multiple node failures include:

• If you have three or more concurrent node failures, some reads and writes will fail due to the potential loss of all three replica copies of the associated triple mirrored metadata chunks.
• Writes require a minimum of three nodes.
• Erasure coding will stop, and erasure coded chunks will be converted to triple mirror protection if the number of nodes is less than the minimum required for each erasure coding scheme. Since the default erasure coding scheme, 12+4 requires four nodes, erasure coding will stop if there are fewer than four nodes. For 10+2 erasure coding, erasure coding will stop if there are less than six nodes. For 24+4, if the number of available nodes falls below seven, erasure coding stops and protection falls back to triple mirroring. For 24+2, the minimum number of available nodes before erasure coding stops and protection falls back to triple mirroring is thirteen. In both 24+4 and 24+2 schemes, the system cannot tolerate more than two node failures while continuing to use erasure coding.
• If the node count goes below the minimum required for the erasure coding scheme, erasure coded chunks will be converted to triple mirror protection. As an example, in a VDC with 12+4 erasure coding and four nodes, after a node failure the following would happen:

• Node failure causes four fragments to be lost.
• Missing fragments are rebuilt.
• Chunk creates three replica copies, one on each node.
• EC copy is deleted.

For more details on node failures, see the Dell ObjectScale: High Availability Design white paper.

Question: What are the types of site outages and how does ObjectScale handle them?

Site outages can be classified as a temporary site outage (TSO) or a permanent site outage (PSO). A TSO is a failure of the WAN connection between two sites, or a temporary failure of an entire site (for example, a power failure). A site can be brought back online after a TSO. ObjectScale can detect and automatically handle these types of temporary site failures. A PSO is when an entire site becomes permanently unrecoverable, such as when a disaster occurs. In this case, the System Administrator must permanently fail over the site from the federation to initiate failover processing. VDCs in a geo-replicated environment have a heartbeat mechanism. Sustained loss of heartbeats for a configurable duration (by default, 15 minutes) indicates a network or site outage and the system transitions to identify the TSO.

If a disaster occurs, an entire site can become unrecoverable; it is referred to in ObjectScale as a permanent site outage (PSO). ObjectScale treats the unrecoverable site as a temporary site failure, but only if the entire site is down or unreachable over the WAN. If the failure is permanent, the System Administrator must permanently fail over the site from the federation to initiate failover processing. This initiates resynchronization and reprotection of the objects that are stored on the failed site. The recovery tasks are run as a background process.

Starting with version 3.7, ObjectScale supports recovery from a multiple simultaneous site (N-1 site) failure. This shortens the data recovery time. The customer must contact Dell to support the operation. It only supports the replication group setting with replication to all sites.

For more details, see the Dell ObjectScale: High Availability Design white paper.

Question: What is the expected behavior during loss of a site?

If a single site is temporarily unavailable, in a replication group containing more than one site, some operations will be limited such as:

• File systems within NFS buckets that are owned by the unavailable site are read-only.
• Buckets, namespaces, object users, authentication providers, replication groups, and NFS user and group mappings cannot be created, deleted, or updated from any site (replication groups can be removed from a VDC during a permanent site failover).
• You cannot list buckets for a namespace when the namespace owner site is not reachable.
• OpenStack Swift users cannot log in to OpenStack during a TSO because ObjectScale cannot authenticate Swift users during the TSO. After the TSO, Swift users must re-authenticate.
• Create, read, update objects and list object in a bucket may be interrupted depending upon replication group options configured on the bucket.

For more details on site failures, see the Dell ObjectScale: High Availability Design white paper.

Question: What type of data encryption is available, and where is it applied?

Data at Rest Encryption (D@RE) is simple, low-touch server-side encryption. It supports enterprises and service providers seeking to protect sensitive data on storage media. In ObjectScale, encryption can be enabled at the namespace and bucket levels. It cannot be changed once it is set.

Question: Which EKMs are supported?

ObjectScale supports External Key Management using external key managers that are Key Management Interoperability Protocol version 1.4 (KMIP v1.4) compliant. ObjectScale delegates the storage and protection of top-level Key Encrypting Key (KEK), the Master Key to the external EKM. ECS 3.3 and later versions support Safenet KeySecure (Gemalto Safenet) and ECS 3.4 supports the IBM SKLM 3.0 (Security Key Lifecycle Manager). ECS 3.6 supports Safenet KeySecure 8.11 with client certificate authentication only. ECS 3.8.0.1 supports Thales CipherTrust because Gemalto SafeNet KeySecure will end of life on December 31, 2023. ECS customers who are using KeySecure can migrate to CipherTrust Manager.

Fortanix EKM is also supported starting with OBS 4.3 and can be configured using the Thales CipherTrust provider type in the UI for OBS 4.3 and later.

Question: Whether ObjectScale supports self-encrypting drives (SEDs)?

The XF960 appliance supports 15TB FIPS-certified self-encrypting drives (SEDs) with Local Key Management in ObjectScale 4.1 and later. Data is automatically encrypted and decrypted at the hardware level. Encryption keys are generated, stored, and managed locally via Dell iDRAC within the appliance.

Question: How does encryption affect performance?

In general, the performance when accessing objects in an encryption-enabled namespace can be approximated as large reads are up to half as fast when encrypted. This behavior is not seen with large creates. Small read performance is reduced as well, but not nearly as much as large reads. Small creates, as with large create, are nominally impacted by encryption.

Question: How does Multi-tenancy work on ObjectScale?

ObjectScale supports access by multiple tenants, where each tenant is defined by a namespace and the namespace has a set of configured users who can store and access objects within the namespace. Users from one namespace cannot access the objects that belong to another namespace.

Question: Which administrative activities will be logged?

ObjectScale metering provides critical information about viewing and using the monitoring pages in the ObjectScale portal dashboard. In the Events page, it includes audit and alerts information, for more details, please refer to the ObjectScale admin guide.

Question: How does the consistency checker process work?

ObjectScale is a strongly consistent system that uses ownership to maintain an authoritative version of each namespace, bucket, and object. Ownership is assigned to the VDC where the namespace, bucket or object is created. For example, if a namespace, NS1, is created at VDC1, VDC1 owns NS1 and is responsible for maintaining the authoritative version of buckets inside NS1. If a bucket, B1, is created at VDC2 inside NS1, VDC2 owns B1 and is responsible for maintaining the authoritative version of the bucket contents, as well as each object’s owner VDC. Similarly, if an object, O1, is created inside B1 at VDC3, VDC3 owns O1 and is responsible for maintaining the authoritative version of O1 and associated metadata.

Question: What is the difference between an IAM user and an object user created locally?

Local users include management and object users. Management users are for configuring, administering, and monitoring the logical components of the ObjectScale architecture. Object users are users of the ObjectScale object store. They access ObjectScale through object clients that are using the object protocols supported (S3, Atmos, OpenStack Swift, and CAS). Object users can be assigned Unix-style permissions to access buckets exported as file systems for NFS.

A traditional object user owns the buckets it creates and has full access to the bucket.  IAM users have no access to any resources by default. IAM policies given to an IAM user can have any combination of S3, IAM, or STS permissions to resources in the namespace. The root IAM account owns buckets in the namespace and IAM users need to be assigned a policy which grants granular permission(s) to resources in a namespace, such as a bucket and its objects. 

Question: How does SAML work?

SAML is an open standard for exchanging authentication and authorization data between an identity provider and a service provider. SAML provider in ObjectScale is used to establish trust between a SAML-compatible Identity Provider (IdP) and ObjectScale. For more information, see the ObjectScale data access guide.

Question: Which compliance standards does ObjectScale follow? 

The ObjectScale appliance meets the storage requirements for the following standards, as verified by Cohasset Associates, Inc.

• Securities and Exchange Commission (SEC) in regulation 17 C.F.R. & 240.17a-4(f)
• Commodity Futures Trading Commission (CFTC) in regulation 17 C.F.R. & 1.31(b)-(c)
• DISA STIG security standards which address the CAT I and CAT II vulnerabilities
• FIPS 140-2 mode enforces the use of approved-only algorithms within D@RE; FIPS 140-2 compliance is only for the D@RE module, not the entire ObjectScale product.

Question: How does ObjectScale implement security controls for code?

Dell product teams use code analysis tools and activities as part of their development process to identify quality defects and security vulnerabilities and comply with Dell’s Secure Development Lifecycle. Dell’s SDLC (Secure Development Lifecycle) integrates standards from a variety of data sources. A primary consideration is data from both internally discovered and externally reported issues. This awareness allows us to focus on the issues that are most prevalent in our technology space. A second major consideration is industry practices. Dell collaborates through many industry-standard venues such as SAFECode, BSIMM, and IEEE Center for Secure Design to help ensure that we follow industry practices. Lastly, Dell’s Secure Development Lifecycle is aligned with the principles outlined in ISO/IEC 27034 ‘Information technology, Security techniques, Application security’.

Question: What is Dell Technologies process for reviewing ObjectScale source code?

Dell Technologies confirms that review of source code (to identify and detect threats and weaknesses in its products) is conducted during various stages of its Secure Development Lifecycle (SDLC). Based on risk analysis, Dell Technologies conducts rigorous testing of specific application modules and security safeguards with a combination of source code review, system testing, exception testing and compliance review to identify errant coding practices and vulnerabilities that could lead to security problems, violations and incidents. Please visit the Dell Security & Trust Center for more information about our security practices.

The following Dell Technologies documentation provides other information related to this document. Access to these documents depends on your login credentials. If you do not have access to a document, contact your Dell Technologies representative.

• ObjectScale and ECS Info Hub
• Dell ObjectScale Data Access Guide
• Dell ObjectScale Administration Guide
• Dell ObjectScale Overview and Architecture