1 Reply Latest reply: Dec 4, 2012 12:34 AM by Frank_Murphy RSS

Atmos - Seems like many maintenance tasks require EMC support?


I'm new to Atmos and have been working to setup a private cloud environment.


We purchased Atmos as a replacement for our Centera arrays - we didn't use the compliance component and only used the Centera arrays as repositories for the EMC Cloud Tiering Appliance (formerly the File Management Appliance [formerly Rainfinity]).


In setting up the Atmos array, I've discovered that many of the basic tasks that I would expect a customer to be able to perform require EMC support, or are just not supported:

  • Changing the IP address of nodes
  • Deleting Tenants and Subtenants
  • Deleting Authentication Sources
  • Upgrading the software


Currently, the array was setup with Atmos and I see that 2.1xxx is out, but I don't see a way to retrieve the update and apply it.


To change the IP address of a node we had to open a support case.


I opened a case for deletion of Tenants and was told it was not possible to delete tenants, but you could remove the administrative accounts for the tenant and remove all nodes to effectively delete it.


When creating subtenants, there is no selection box for the Authentication Source when using remote authentication.  So, the subtenants are set to an Authentication Source that is not valid.  And since I can't delete an Authentication Source or a subtenant, I'm not sure how to proceed to correct this issue.


Are other Atmos administrators also having this much difficulty with management of the array?

Is there some hidden commands/manual out there which provides more details on management tasks?

  • 1. Re: Atmos - Seems like many maintenance tasks require EMC support?


    Seems like you’ve noticed the system interaction with Atmos is different than what you may have been exposed to in Centera. Why is that? In addition to being optimized for archiving or tiering workloads like those from EMC Cloud Tiering Appliance (CTA), Atmos is also optimized for transactional, primary storage workloads making it an integral component of an application stack rather than merely a tier of storage. Plus,  given it’s inherent active/active distributed architecture the dependency on networking and off-system services means the potential risk of introducing downtime from an unplanned change is serious. Architecture changes such as those you’ve listed aren’t to be taken lightly and are some of the reasons why we encourage you to leverage EMC support staff when making them. Remember, one of the benefits of the maintenance agreement is the careful planning and assumption of responsibility EMC bears when making changes to a deployed system. In fact, the tasks you’ve listed are rarely, if ever performed, and instead, and are often made during initial architecture and installation discussions.


    So, do all maintenance tasks require support cases? Definitely not and in the case of our new Sumatra v2.1 software (available from Powerlink) one of its themes is improved operational efficiency and system management and combined with the new dense disk system architecture, offer step-by-step instructional videos for certain CRUs (customer replaceable units). Both are examples of user-driven maintenance tasks.

    For maintenance tasks prior to v2.1, if you can contact me with an email (either through this support forum or from our online sandbox portal http://atmosonline.com/contact) I’ll send you a copy of our operational run book white paper covering the best practices for system care, including event management integration with frameworks and service management applications such as EMC Smarts.


    As for the open support requests I’ll defer to the support specialists for their direct instructions.


    Hope this helps add some background.


    Frank Murphy

    Atmos Technical Marketing Manager