NetBackup™ for OpenStack Administrator's Guide
- Introduction
- Deploying NetBackup for OpenStack
- Requirements
- NetBackup for OpenStack network considerations
- Preparing the installation
- Spinning up the NetBackup for OpenStack VM
- Installing NetBackup for OpenStack Components
- Installing on RHOSP
- Prepare for deployment
- Updating the overcloud roles data file to include NetBackup for OpenStack services
- Verifying the deployment
- Additional Steps on NetBackup for OpenStack Appliance
- Installing on Ansible OpenStack Ussuri
- Installing on Kolla Ussuri
- Pushing NetBackup for OpenStack images to the local registry
- Installing on RHOSP
- Configuring NetBackup for OpenStack
- Post Installation Health-Check
- Uninstalling NetBackup for OpenStack
- Uninstalling from RHOSP
- Uninstalling from Ansible OpenStack
- Uninstalling from Kolla Openstack
- Uninstalling from RHOSP
- Install nbosjm CLI client
- Configuring NetBackup OpenStack Appliance
- Configuring NetBackup Master Server
- NetBackup for OpenStack policies
- Performing backups and restores of OpenStack
- About restores
- Required restore.json for CLI
- Configuring and starting a file search in Horizon
- Performing Backup Administration tasks
- NBOS Backup Admin Area
- Policy Attributes
- Policy Quotas
- Managing Trusts
- Policy import and migration
- Disaster Recovery
- Example runbook for disaster recovery using NFS
- Disaster recovery of a single policy
- Copy the policy directories to the configured NFS Volume
- Make the Mount-Paths available
- Reassign the policy
- Restore the policy
- Clean up
- Disaster recovery of a complete cloud
- Reconfigure the Target NetBackup for OpenStack installation
- Make the Mount-Paths available
- Reassign the policy
- Restore the policy
- Reconfigure the Target NetBackup for OpenStack installation back to the original one
- Clean up
- Troubleshooting
- General Troubleshooting Tips
- Health check of NetBackup for OpenStack
- Important log files
AWS S3 eventual consistency
AWS S3 object consistency model includes:
Read-after-write
Read-after-update
Read-after-delete
Each of them describes how an object reaches its consistent state after an object is created, updated, or deleted. None of them provides strong consistency and there is a lag time for an object to reach the consistent state. Though NetBackup for OpenStack employed mechanisms to work around the limitations of eventual consistency of AWS S3, when an object reaches its consistency state is not deterministic. There is no official statement from AWS on how long it takes for an object to reach consistent state. However read-after-write has a shorter time to reach the consistency compared to other IO patterns. Our solution is designed to maximize read-after-write IO pattern. The time in which an object reaches eventual consistency also depends on the AWS region. For example, aws-standard region does not have strong consistency model compared to us-east or us-west. We suggest using these regions when you create s3 buckets for NetBackup for OpenStack. Though read-after-update IO pattern is hard to avoid completely, we employed ample delays in accessing objects to accommodate larger durations for objects to get into consistent state. However in rare occasions, backups may still fail and need to be restarted.