Architecture
==Introduction== Tranzman is delivered as an appliance out-of-the-box. It can be deployed on either a virtual machine or a physical server using a bootable ISO or OVA. Unlike a software binary, Tranzman is an appliance and therefore not available as an executable binary or RPM. Tranzman consists of two main components: the Appliance and the Agent. ===Appliance Component=== The core framework of the Tranzman appliance ('TZM') includes: 1. Queue Manager (tzmqm) 2. Data Transfer Engine (tzmtd) Additional details about the appliance: - TZM is built on Rocky Linux sources and utilizes an internal database (PostgreSQL).
- The appliance can be accessed via CLISH (Command Line Interface Shell) and a web user interface (webUI). It hosts an internal web server running nginx for the webUI.
- Configuration Converters, Catalog Converters, and Data Converters (applicable to CVT and RWV) handle all manipulations internally. ===Agent Component=== The Agent serves as the interface between Tranzman and the backup server. Here are its key functions: - Awaits actions from the Tranzman Server.
- Executes the received actions from the Tranzman server.
- Returns the action status result to the Tranzman Server.
The Agent is a minimal standalone binary installed on the backup server. It initiates tzmclnt and other processes on the backup server. ==High-Level Process Flow== - All processes within the Tranzman Appliance rely on the Relational Database and the QueueManager process.
- The QueueManager is responsible for updating Actions into the Agents' queue. These actions are associated with a list of APIs for the Tranzman Agent. The QueueManager effectively manages the flow of actions for all migrations.
- The Agent communicates with the Data Transfer Engine to retrieve actions from the queue and to perform PUT/GET operations related to catalog data.
- The actions retrieved by the Agents can trigger various procedures. ===Logical design for Same Vendor Transition (SVT)===
===Logical design for Cross Vendor Transition (CVT)===
===Logical design for Recovery Without Vendor (RWV)===
== Actions == Actions consist of a sequence of instructions to be executed by the agent on the backup server as part of the transition process. The following table shows all the available actions in Tranzman: {| class="wikitable" style="margin:auto;width:100%;color:red;text-align:left;borderstyle=ridge;" |- | style="text-align:left;color:darkred;"| Init | Runs once on both the origin and destination during the initial discovery to retrieve system information. |- | style="text-align:left;color:darkred;"| QueryProduct | Runs once on both the origin and destination as part of the initial discovery to detect the backup product installed on the system. |- | style="text-align:left;color:darkred;"| QueryConfig | Runs once on both the origin and destination to determine configuration objects (such as storage, credentials, workloads, etc.) present in the system. |- | style="text-align:left;color:darkred;"| QueryMedia | Runs cyclically on both the origin and destination to gather media-related information. |- | style="text-align:left;color:darkred;"| QueryImages | Runs cyclically on both the origin and destination to discover all backup images. |- | style="text-align:left;color:darkred;"| CreateConfig | Runs once on the target system to create necessary configuration components. |- | style="text-align:left;color:darkred;"| CreateWorkloads | Runs once on the target system to create required backup configuration components. |- | style="text-align:left;color:darkred;"| CrossCheck | Runs daily during data transfer to compare data between the origin and destination. |- | style="text-align:left;color:darkred;"| ExportImages | Runs cyclically on the origin system to export selected images. |- | style="text-align:left;color:darkred;"| ManipulateImages | Converts or renames components that are mapped between the origin and destination. |- | style="text-align:left;color:darkred;"| ImportImages | Runs cyclically on the destination system to import the migrated images. |- | style="text-align:left;color:darkred;"| CreateMedia | Runs cyclically on the destination to create or update the media. |- | style="text-align:left;color:darkred;"| CheckConn | Runs on demand on both the origin and destination to test connectivity of clients and to push NetBackup certificates. |- | style="text-align:left;color:darkred;"| FinalizeOrigin | Runs once on the origin during the final switchover. |- | style="text-align:left;color:darkred;"| FinalizeDestination | Runs once on the destination as part of the final switchover. |- | style="text-align:left;color:darkred;"| Assessment | Runs on demand to perform Pre-Assessment and Post Acceptance tests before and after migration, respectively. |- | style="text-align:left;color:darkred;"| HouseKeeping | Runs cyclically to clean up completed information from the Tranzman Database. |- | style="text-align:left;color:darkred;"| PreDuplication | Runs cyclically based on rules to perform duplications on the origin if required, as part of a split. |- | style="text-align:left;color:darkred;"| PostDuplication | Runs cyclically based on rules to perform duplications on the destination if required, as part of storage migration. |- |} == Migration Flow == === Same Vendor Migration Flow ===
* (1) Export the data and transfer it to the Tranzman server. * (2) Convert the data within the Tranzman server. * (3) Transfer the data to the destination and import it. === Cross Vendor Migration Flow === If the backup data is on Tape
* (1) The data converter in the Tranzman server reads the data directly from tapes. * (2) Optionally, the converted data can be duplicated to a destination storage. If the backup data is on Disk
* (1) The converter reads the data from the origin storage over NFS/CIFS. * (2) Optionally, the converted images can be duplicated to the native destination storage. If the backup data is encrypted or deduplicated
* (1) Pre-duplicate the data to shared storage. * (2) The converter reads the data from the shared storage. * (3) Optionally, the data can be duplicated to the native destination storage. {| class="wikitable" style="margin:auto;width:100%;color:blue;text-align:center;borderstyle=ridge;" |- |
||
|}