Atmos CAS and Centera Online Clusters (Connectivity Information)

************* Site Announcement************

Please note that the online Centera testing clusters will be closing down on September 30th 2018.  We recommend that all of the existing users of the online Centera's move across to test their CAS API integration on our ECS online Test Drive Portal which is at

EMC - Get Started with ECS Test Drive

If you follow the link you will be able to apply for credentials to allow you to continue to test your Centera CAS API integration as well as the S3, Swift and Atmos REST API.

The ECS Test Drive Portal brings you the benefits of

  • 100% support of the Centera CAS API, all your existing usage of the Centera API in your application will "just work"
  • Fully hardware and software maintained
  • Fully private tenancy
  • 1 TB of storage available for your account


We recommend that you move your testing over to the ECS Test Drive Portal as soon as possible.  The current online Centera clusters are no longer hardware maintained as as some of you already know are experiencing outages.


We look forward to seeing you on the ECS Test Drive Portal.


Paul McKeown



1) The XAM API is not supported on ECS and therefore the ECS Test Drive Portal cannot be used for XAM API integration testing. 

2) The XAM API is not longer officially supported by Dell EMC

3) Only cluster 2 is currently operational (see below).

Lab Policy

The 'Lab Policy' defines the norms for the usage of EMC Atmos and Centera Online Clusters. In an effort to keep the online clusters fully functional and provide better service to our partners/customers, it is imperative that all partners/customers adhere to the policy guidelines as defined:


Acceptable Usage

1. Integration Functional Testing

2. Targeting Cluster as a replica (in case of PDU's)

3. Application demo's that do not, in any case, affect the configuration


Cluster Re-initialization

As of Sept 2008 EMC Centera Engineering will re-initialize all the On-line Public Clusters every 60 days. This will mean that cluster users will lose all archived content and you will need to obtain new PEA files to gain access to the clusters.


Also please be aware that due to maintenance reasons we may be required to re-initialize one or all of the clusters at any time.


Unacceptable Usage

1. Centera Viewer (CV) usage and demo purposes

2. Proof of Concept (POC) testing for customers

3. Failover testing (Physically bringing down the Centera)

4. Performance testing (Partner needs to schedule a visit to the EMC Centera facility with respective CSE for this purpose)

5. Using Centera as a personal storage repository

6. Large number of Pool Opens

7. Overly aggressive bandwidth utilization


General Configuration

It is out intention to provide the following facilties when possible

1. Provide the latest supported releases of CentraStar.

2. Provide at least one cluster with uni-directional replication.

3. Provide at least one cluster with advanced retention management (ARM).

4. Provide three access profiles with a variation on capabilities.

5. Provide at least one Atmos Cluster with the CAS access method enabled.


Access Profiles/Virtual Pools

By default EMC ASD provides a number of Virtual Pools and their PEA files for use for functional testing of your applications integration to Centera and/or Atmos CAS.  For Independant Software Vendors who have enrolled in the EMC Technology Partner Program and who require their own Virtual Pool for testing then please email requesting an individual Virtual Pool.  Please indicate all access capabilties that you want to test and whether it should be for Centera or Atmos CAS.


Please post your questions and concerns on the Centera discussion threads section.


Checking Connectivity


Note that before checking connectivity and posting that you cannot access the centera clusters please check that you have read the following

  1. Access to the clusters requires port 3218 opened for TCP and UDP in both directions in your firewall.  Network people tend to not like opening UDP by default, they have to live with it.
  2. ICMP is NOT enabled and our firewall rules block it anyway.  So please don't email saying you can't ping the clusters, you will be sent to the corner and pointed at.
  3. Either use your application to try a pool open or download CenteraPing and/or CenteraViewer from this site (go look for them) to test connectivity.
  4. You will need to use a valid PEA file (see below) to fully check connectivity and your access capabilities.
  5. If one cluster does not respond please try another and see if it works.  Sometimes things happen to one cluster.  Please log the failure below.
  6. ICMP is NOT enabled and our firewall rules block it anyway.  So please don't email saying you can't ping the clusters, you will be sent to the corner and pointed at.
  7. If you cannot connect to the clusters please add a comment below (I get an auto-notification email) details which clusters, what PEA files and the SDK Error returned (not the application error please the SDK error so I can check if it really is an access error).


AtmosCAS1 has been reinstalled please download the new PEA File.

NOTE: As per policy, all data previously written has been erased.



Cluster List


AtmosCAS1: Atmos 2.0.1;

Port 3218 (TCP/UDP)

IP Addresses

PEA Files

AtmosCAS2: Atmos 2.0.1;

Port 3218 (TCP/UDP)

IP Addresses

PEA Files

Cluster 1 (Primary): 4.2.0-3881-0-0;

Port 3218 (TCP/UDP)

IP Addresses - node down - node down

PEA Files





Cluster 2 (Replica): 4.2.0-3881-0-0;

Port 3218 (TCP/UDP)

IP Addresses

PEA Files





Cluster  3 : 4.1.1 ;

Port 3218 (TCP/UDP)

IP Addresses

PEA Files





Cluster 4 : 4.1.1;

Port 3218 (TCP/UDP)

IP Addresses

PEA Files






Please always use all the IP addresses of a cluster as from time to time nodes may be down.  Just using one IP will not allow you to connect to the cluster if that node is down but others are still up.

Access Profiles

The Centera Online Laboratory gives the partner community access to Centera clusters hosted by EMC and can provide the ability to test your application against different CentraStar versions and various cluster configurations. The following is a description of existing application profiles, granted access privileges, and suggested test scenarios.


Application Profile Definitions

Application access to Centera is guarded by Application Profiles configurable on the cluster itself. Each Application Profile defines a set of granted application capabilities and controls access to a given Virtual Pool. PEA files posted on the ‘Cluster List' page provide authentication information that the application can use to authenticate itself against a selected Application Profile. Appropriate PEA file should be downloaded onto the application server and the location of that file ought to be define either as part of the PFPool_Open Connect String, or as an environment variable:


Connect String


  • FPPool_Open (",\myApp.pea


Please always use all the IP addresses of a cluster as from time to time nodes may be down.  Just using one IP will not allow you to connect to the cluster if that node is down but others are still up.



Environment Variable


  • CENTERA_PEA_LOCATION="c:\myApp.pea"


Applications may also elect to use name/secret authentication information if such is defined by the Centera Administrator. The name/secret information can be passed to Centera as part of the PFPool_Open Connect String:


  • FPPool_Open (",,secret=mySecret");


Application Profile Settings

All clusters within the Centera Online Laboratory have the ‘Anonymous' profile disabled and as such require the use of a PEA file or an appropriate name/secret combination. Each PEA file posted on the ‘Cluster List' page conforms to the following naming scheme:




For example, "us2_armTest2_rdqeDcwh.pea", translates to:


  • Application Profile belongs to Centera Cluster US2

  • Profile Test2, Advanced Retention Management (arm) enabled

  • Capabilities: All enabled - please refer to the list below.


Capabilities Definitions:


  • r: read (FPClip_Open, FPTag_BlobRead, FPTag_BlobReadPartial)

  • w: write (FPClip_Write, FPTag_BlobWrite, FPClip_EnableEBRWithPeriod, ...)

  • d: delete (FPClip_AuditedDelete, FPClip_Delete)

  • q: query (FPPoolQuery_Open)

  • e: exists (FPClip_Exists)

  • D: privileged delete (FPClip_AuditedDelete) (Not Atmos CAS)

  • c: clip copy (FPClip_RawOpen, FPClip_RawRead)

  • h: retention hold (FPClip_SetRetentionHold) (Not Atmos CAS)

  • monitor (FPMonitor_Open) - Monitor capability enabled on: US2, US3, US5, EMEA1, EMEA2 and EMEA3 (Not Atmos CAS)


Each profile also comes enabled with name/secret combination that corresponds to the profile name. Thus to access a profile defined by us2_armTest2_rdqeDcwh.pea file, the application could alternatively use "name=armTest2,secret=armTest2" in the connect string.


Recommended test scenarios


Centera Security Control and Authentication


  • Does your application use PEA files?

  • Does your application support multiple profiles?

  • Does your application invoke FPPool_RegisterApplication?

  • Does your application check for enabled capabilities?

  • Did you test your application using various application profiles?


Replication / Failover


  • Can your application support Centera Replication?

  • What happens when the local Centera cluster is unreachable?

  • Does your application failover writes as an option?

  • Do you rely on the Centera API to failover on reads?

  • What tasks does the user need to perform to allow failover?

  • Do you query the Centera for the replica address?


Single Instance Storage


  • Does your application support Single Instance Storage?

  • At the application level?

  • At the Centera level?


CDF Embedded Blobs


  • Does your application embed blobs into the CDF?

  • Do you rely on the Centera API to embed the blobs?

  • What is your embedded data threshold?


Retention Periods


  • Does your application set a retention period for data written to Centera?

  • Are there any times when there is no retention period set?

  • Make sure your application always sets a default retention period (0 = no retention, -1 = infinite retention on Centera CE+)

  • Does your application make use of retention classes?

  • How does your application behave in an environment with Advanced Retention Management enabled?


Deleting Data


  • Does your application delete data from Centera?

  • How does your software handle an error returned if an item can not be deleted?

  • Does your application provide a reason string for with the AuditedDelete API call?




  • Can your application rebuild its database by using the data on Centera?

  • Does your application embed any identifying metadata?

  • For example: App Name, Version, Server Name, etc...




  • Does your application utilize the concept of Containers?

  • What happens if a person wants to delete data from a container?

  • How many objects do you place in a container?

  • Does your application support the BlobPartialRead feature of the Centera API?




  • Is your application multi-threaded?

  • Is the number of threads configurable for reads and writes?