Although this list is not exhaustive, it outlines some essential duties an administrator must perform.
-
Maintain username/password policy of AD use in directory configuration
-
Maintain and back up the latest and most updated version of /opt/atscale/conf/atscale.yaml
-
Always backup AtScale before running the installer (upgrade or classpath update, etc.) tar -cvzf atscale.tar.gz /opt/atscale/*
-
Free space including 32 GB in /tmp as it is being used for support.zip staging dir
-
Do not delete any system files. Typically postgres logs are the only files not rotated. Those are OK to delete, but it is a good idea to keep 1 week's worth of logs
-
Do not collocate Atscale on the same server as with other processes, such as Hadoop
-
In the Kerberized environment, synchronize Kerberos password reset with Hadoop account resets. Maintain schedule and know when to distribute new keytabs and test
-
Ensure that the AtScale node is appropriately scaled and that it is not overutilized
-
Maintain a consistent security model across all environments (group-to-role mapping, cube security, etc.)
-
Take note of every configuration change.
-
For engine settings saved in the database, take note and write down the reason and case number why the change was suggested.
-
For app configs, adjust custom.yaml with the change, or take note if it needs to be adjusted after the installer is rerun for an upgrade or other reasons.
-
-
Do not change atscale service users or other significant configuration changes before talking to the AtScale team if the change is needed. Always back up before the change.
-
Understand cluster resources and scalability requirements such as YARN queues as your workloads grow.
-
Aggregate batch requirements
-
Interactive queries and SQL engine requirements to scale
-
-
Backup and restart AtScale prior upgrade
-
Notify AtScale Support and send a case to support two weeks before the upgrade for planning. Note manual configuration changes so those can be reviewed with support/PS