Difference between revisions of "Architecture"
From Tranzman Documentation
(→Logical design for Same Vendor Transition (SVT)) |
(→Logical design for Cross Vendor Transition (CVT)) |
||
| Line 34: | Line 34: | ||
=== Logical design for Cross Vendor Transition (CVT) === | === Logical design for Cross Vendor Transition (CVT) === | ||
| − | [[File:CVT.jpg| | + | [[File:CVT.jpg|480px]] |
=== Logical design for Recovery Without Vendor (RWV) === | === Logical design for Recovery Without Vendor (RWV) === | ||
Revision as of 14:43, 27 May 2025
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:
- Queue Manager (tzmqm)
- 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:
| Action | Description |
|---|---|
| Init | Runs once on both the origin and destination during the initial discovery to retrieve system information. |
| QueryProduct | Runs once on both the origin and destination as part of the initial discovery to detect the backup product installed on the system. |
| QueryConfig | Runs once on both the origin and destination to determine configuration objects (such as storage, credentials, workloads, etc.) present in the system. |
| QueryMedia | Runs cyclically on both the origin and destination to gather media-related information. |
| QueryImages | Runs cyclically on both the origin and destination to discover all backup images. |
| CreateConfig | Runs once on the target system to create necessary configuration components. |
| CreateWorkloads | Runs once on the target system to create required backup configuration components. |
| CrossCheck | Runs daily during data transfer to compare data between the origin and destination. |
| ExportImages | Runs cyclically on the origin system to export selected images. |
| ManipulateImages | Converts or renames components that are mapped between the origin and destination. |
| ImportImages | Runs cyclically on the destination system to import the migrated images. |
| CreateMedia | Runs cyclically on the destination to create or update the media. |
| CheckConn | Runs on demand on both the origin and destination to test connectivity of clients and to push NetBackup certificates. |
| FinalizeOrigin | Runs once on the origin during the final switchover. |
| FinalizeDestination | Runs once on the destination as part of the final switchover. |
| Assessment | Runs on demand to perform Pre-Assessment and Post Acceptance tests before and after migration, respectively. |
| HouseKeeping | Runs cyclically to clean up completed information from the Tranzman Database. |
| PreDuplication | Runs cyclically based on rules to perform duplications on the origin if required, as part of a split. |
| 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.
|
|