Veritas Flex Appliance and InfoScale Proof of Concept

World Wide Technology's Advanced Technology Center (ATC) was tasked with a Proof of Concept (POC) that would demonstrate the capabilities of each aforementioned product for a large Department of Defense organization. We addressed the following areas:

Flex Appliances:

• Backup
• Recovery
• Archive to S3
• Replication between sites

InfoScale

• Disaster Recovery Testing/Certification
• Application Availability/Resiliency

Veritas Flex Appliance Environment Overview

Flex Console Deployment

The Flex Appliances used in this Proof of Concept (POC) were deployed as Virtual Machines.  Both systems were assigned different networks to simulate a dual data center environment.  The minimum resources needed for each system were:

• 8 CPU
• 32GB of Memory
• 2 Hard Disks
  • 256GB OS Disk
  • 300GB Data Disk
• Networking – 4 IP Addresses
  • Flex Console
    • Initial Configuration
  • Primary Server
  • Media Server x 2 or Media Server and WORM server
• OS – RedHat Linux 7

Prior to beginning the initial configuration, it is required to have DNS entries for every server/instance that you are going to deploy.  Not having this configured will cause the install to fail.

The initial configuration was assigned using a console session to the VM.  The first step was to change the default credentials when logging in as hostadmin.  To achieve this, we ran the set user password command.  Once changed, we ran the setup configure-network command. 

The system required us to enter the network configuration in CIDR format. 

After the networking was configured successfully, we configured the flex console by running setup configure-console.  This created the base configuration for the flex console.  A system restart command is recommended after configuring the console to prepare the console for first access.

Primary Server Deployment

To access the flex console, in a browser, we entered https://<CONFIGURED_IP> which brought us to the initial login. The system required us to change the default credentials on first login.  Once changed, the next step was to configure the network interface(s). Veritas gives the user the option to configure the network interfaces individually or bond them.  For the purpose of this POC, we only used one interface nic0.

After the network configuration, we created a tenant on the system.  This allowed resources to be partitioned based on which teams need access. Additionally, it allowed for easier configuration of the primary and media servers.  For the host file entries, make sure that the names and IP addresses of all the systems that are going to be deployed are configured as this will come into play later on during the deployment.  The final step before we created a primary or media server is to upload the rpm files for the systems.  For the purposes of these tests, we uploaded version 10.3 for both the Primary and Media Server.  These files were obtained from the Veritas Support Site.

When we deployed the primary server instance, we selected the tenant and network first to populate the appropriate configuration parameters.  This allowed the administrator to copy and paste the host file entries and networking configuration from the previous steps. We entered the name of the system and completed the installation.

 Media Server Deployment

Prior to continuing with the media server deployment, we accessed the primary server via SSH and edit the bp.conf file (<install_dir/netbackup/bp.conf) and added all of the media server entries that will be deployed underneath the primary server entry

Media server deployment was the same as primary with the exception of a few steps.  We logged into the primary server web interface and created a token for the addition.  Additionally, we copied the certificate fingerprint generated for the primary server after deployment.  This is required for authentication.  Also, the sizing for the media server is dependent on the amount of space available on the disks.  Once complete, both primary and media servers were listed as online in the System Topology screen of the Flex Console GUI.

Repeat the previous steps for each site that will be deployed.

To login to the Flex Appliance GUI, we entered the following URL into a browser https://<Hostname_of_Primary_Server>/webui for the initial login.  As with previous steps, we changed the default password. The next step was to add the media server to the primary server. To do this, we clicked on Host Properties -> Configure Media Server.  We entered the hostname of the media server. The subsequent steps needed to be performed in order:

• Create a storage server
• Create a disk pool
• Create a storage unit

These will be the resources used to configure backup and restore operations.

Configuring Replication

When we configured replication, we added both servers as trusted primary servers. 

This was required to allow communication between source and destination systems.  Without this configuration in place, any replication requests would be inherently denied based on Veritas' security settings.

Veritas leverages Storage Lifecycle Policies (SLP) to perform various actions with snapshots.  To configure replication, we selected import as the first step and replication as the child object.  When we configured the child object, select the target primary server. The SLPs dictate the storage location and processes to be performed on the snapshots.  The Protection Plans outlined what systems will be backed up, the schedule, and any client specific settings that are needed to complete the backup.  We created a Protection Plan and selected the SLP that we configured for replication.

Adding Workloads

With the Protection Plan and SLP in place, we added workloads to the primary server.  The main focus for testing in the POC were VMware Virtual Machines.  We added the vCenter and Veritas auto discovered all of the VMs in the environment. The auto discovery took a few seconds to complete and allowed us to apply the previously configured Protection Plan to several VMs.  The backups started a minute or so after assigning the Plan.  The backup completed in a few minutes which automatically triggered the SLP replication job.  A few minutes later, the replication job completed.  The replicated backup was verified by logging into the target site and selecting workloads.  The replicated VM was listed under workloads.  However, the vCenter was different from the other systems that were added to the source system.

With the VM on the target system, we were able to perform a restore of a replicated VM to another vCenter from a system at another location.

Configuring Archiving

A requirement for this POC was to configure archiving to a tertiary storage location.  The goal of this testing was to show the process of archiving a snapshot to long term retention.  We used a Netapp StorageGRID environment to leverage an S3 location. We configured a bucket on the StorageGRID and created an access key for permission to write to the location.  In the Veritas Flex Console, we created a media server that would handle the archiving jobs.  Similar to the previous media server deployment, we configured a disk pool that pointed to the StorageGRID.

Following the previous steps, we configured a Protection Plan that backed up to the disk pool we had just created.  We then assigned the Protection Plan to a VM.  After the backup completed, we validated the backup by reviewing the file incrementing on the StorageGRID.

Additionally, we were able to browse the files in the Veritas GUI once the backup had completed.

InfoScale

Deployment

After we tested and validated the capabilities of the Flex Appliances, we moved onto the features of InfoScale.  To deploy InfoScale environment, we needed the following:

• Veritas InfoScale Operations Management (VIOM) Server
• InfoScale Source Servers
• InfoScale Target Servers

The function of each of these systems can be translated into VMware terms.  The VIOM Server is like the vCenter and the other Servers are like ESXi hosts.  After we downloaded the software from the Veritas Support Portal, we uploaded it to the VIOM Server.  The install was very simple and only required a few steps.

1. Configure DNS to resolve the hostnames of all the systems to their respective IP addresses
2. Upload files to the VIOM Server
3. Install the VIOM Server software
4. Push software to the Source and Target Hosts

We triggered the installation script and installed the InfoScale Enterprise software to all of the hosts.  The installation displayed the progress of each step and the total install completed in about 30 minutes.  Once the install completed, we were able to access the GUI using the URL below: (default access port is 14641)

https://<infoscale_hostname>:14641

We configured replicated volume groups, Storage Clusters, and organizations.  The resources are configured to replicate across sites from Source and Target Servers to ensure application availability.  The replication of data happens asynchronously in the background and doesn't require much user intervention outside of initial configuration. 

After the resources were configured, we created a Service Group.  The Service Group is similar to a deployment in Kubernetes. It is a collection of resources needed to run a particular application.  We configured a Cluster Service (Communication within Source and Target hosts), Cluster Volume Manager (Manages the Clustered File System), Disk Group replicated volume group, and MySQL Group resource.  We created everything on the target system to mirror the source. The only difference was that the active MySQL instance was on the source.  This will come into play when configuring the DR Solutions using a Recovery Plan.

To ensure Application Availability, InfoScale monitors the status of the configured application, in this case MySQL, and fails over the application to another host/site.  In the event that the heartbeat fails, InfoScale will try another host within the same cluster first.  If that fails and the cluster is down, InfoScale fails MySQL over to the other site.

Recovery Plans

As a best practice, companies should perform failover testing at least once a year.  The customer in this POC, performed various DR failover tests every quarter (same site failover), and semi annually (complete site failover).  To simulate this, we configured Recovery Plans for each test.   Below is an example of the complete site failover.

When we configured the Service Group like a deployment, it allowed a failover of all the required resources to the target site without much intervention.  The Recovery Plan was simple, with only 2 steps.  First step was to offline the main site.  The second step was to online the secondary site. InfoScale provided a good log of what occurred, in addition to the commands that we could run if we wanted to automate the procedure via CLI.

Prior to the failover, the MySQL resource showed as active on the primary.  After the failover, the resource was greyed out on the primary which indicated it was inactive.  The blue version on the target indicates the system was running on the target system.

After the failovers have been completed, there were reports that can be generated that outlined historical failover tests.  The results of these tests can be sent to various teams within an organization.  Additionally, the reports can serve as evidence for an audit if requested.

Conclusion

Veritas InfoScale is a viable solution for companies that need a Disaster Recovery Plan. The Flex Appliances have the versatility needed to design any Data Protection environment for today's complex organizations.  Both are easy to deploy and once deployed, take minimal effort to manage.  The POC resulted in the customer being thoroughly impressed with how Veritas handled the requirements and they requested further information on niche scenarios that they feel Veritas can solve.