An Avamar server can handle 27 simultaneous client connections, with 1 always being reserved for restore. A server is comprised of the Utility Node, which has the mcs, ems and cron jobs running. It listens on port 8443 for web browser requests, 7778 for the admin console, and communicates with the avagent on port 28001 (the avagent listens for mcs requests on 28002, coincidentally - they are a pair). The Storage node runs the gsan process and talks to the avtar process on the client over ports 27000 and 29000 for encrypted communication.
The mcs handles notification and reporting for the GUI, SMTP, syslog and SNMP services, while the MCDB is the database that allows communication for reporting, such as with DPA.
An Avamar client runs avagent which listens for backup requests on port 28002 from the Avamar server and spawns avtar, which then sends data to the Avamar storage node (gsan) specified by mcs.
The Avamar server node components are:
- Utility node - 1U server with no storage
- m600- 2 TB
- m1200 - 3 TB
- m2400/s2400 7.8 TB
- accelerator and media access nodes
Integrating Avamar with Data Domain is most beneficial in environments where large, active databases are in use. Data is held on the DD while meta data is on the Avamar. Avamar will run maintenance routines such as garbage collection, checkpoints, rollbacks, HFS checks, all of which take place on the DD storage.
Integrating Avamar with Networker makes Avamar a deduplication node, mainly, where deduped data is stored on the Avamar, while meta data and deduplication info is stored on the Networker Storage Node.
Integrating Avamar with DPA is relatively straight-forward in that DPA will collect info on the backup system in general.
It is recommended to always configure the Email Home Notification, which sends a report twice daily to EMC with status and errors, events and warnings on the system. ConnectEMC is another notification tool that ties into ESRS and allows EMC support to be alerted immediately and connect to resolve issues without interaction.
Security is administered in several ways on Avamar. The first being user roles. There are Administrator, Operator and User roles. The administrator has full root access to the system, while operators have access to role-defined privileges. Operators will typically used to backup a single domain or system. Users are typically allowed to backup and restore from a single client.
Authentication can be managed locally from the AVS process, Active Directory, NIS, and LDAP. LDAP groups must be mapped to each domain and role, and they are available for the Administrator, Enterprise Manager and Client Manager but not for local system administration. This needs to be configured in the Avamar server and usernames and passwords are managed then through the authentication service and no user accounts are local to the Avamar.
Client/Server authentication can be handled by TLS or PKI. It is best to use a commercial CA if you don't have one yourself, as self-signed certificates are not recommended for production use. 1-way authentication would be where the client requests a certificate from teh server, and 2-way authentication is when the client requests first, and then the server requests authentication from the client.
Web browser security is handled using TLS and SSL. To reduce errors on the browser, server authentication should be configured where you create a private key and then generate a certificate signing request for it.
Data can be encrypted both at rest on the Avamar as well as in flight from client to Avamar. The at-rest encryption algorhithm is blowfish, and this is a one-time decision made when the system is installed. There is no method for removing encryption outside of migration of data. Data in-flight can be configured on each job, however, and can be changed on the fly. In-flight encryption is not supported with DD on the backend, however. The options for in-flight encryption are high, medium and off.
Secure delete is a feature to completely remove data with no chance of retrieving it forensically. This is done using the "securedelete" command and it performs a multiple write over the disk. It can only be used on a per-client basis, and any replicated copies of the client need to be manually removed as well.
After Avamar 5.0, address translation, or NAT is supported so that utility nodes can present an IP address on the same subnet as a remote client and the communication will happen automatically.
Avamar Extended Retention gives the ability to take data off the Avamar in non-deduplicated form and written to tape or external media. This function would need a media access node to complete.
Avamar Virtual Edition is an Avamar VM that runs on n ESX server. It is a single-node Avamar system, and therefore replication is required. There are capacity limits of 0.5, 1, or 2 TB making it best used in small and remote environments. The ESX server must pass a benchmark test called the AVE Performance Assurance Tool (PAT). AVE can not be expanded.
Operational Best Practices would suggest that the design should always maximize operational availability. In other words, schedule backup to take place during backup windows and not during maintenance windows. You should be monitoring the infrastructure as well as the capacity to ensure that there is always ability to run both maintenance jobs as well as network, UPS and cooling capability. Capacity should be closely monitored to avoid hitting the read-only threshold of the Avamar, and the Avamar requires constant care and feeding to continuously be tuning performance as jobs are added and removed.
No comments:
Post a Comment