南宫NG·28

i2DTO (Data to Object) is a management software designed for massive data migration scenarios in object storage. Its primary functions are data migration and backup:
1) Synchronize data from local storage and NAS storage to object storage.
2) Synchronize data from object storage to local storage, NAS, and ZFS.
3) Compare and synchronize data between local storage/object storage and object storage. It supports comparisons and synchronizations between local/NAS storage and object storage, as well as between different object storages.
Basic Functional Features:
1) Supports synchronization from local file systems (including NAS) to object storage.
2) Supports file synchronization from object storage to object storage, such as file synchronization from Alibaba Cloud OSS to Tencent Cloud COS.
3) When synchronizing from local to object storage, it supports saving files after encryption and compression; when restoring files from object storage to local storage, it allows file decryption and decompression (encrypted and compressed through DTO).
4) Data backup on object storage can be used directly (without needing to recover through a media server or other methods).
5) Supports archiving functions, setting diversified archiving conditions (based on file creation, modification, access times, file or entire directory names, and different file type suffixes, etc.), archiving files that meet the archiving conditions to object storage, and allowing quick query of archiving records through a webpage.
6) Integrates with third-party search engines to provide rapid retrieval and recovery of backup records in massive file scenarios (not limited to Elasticsearch).
7) Supports accessing object storage via Swift.
8) Backup records can be browsed through the object browsing interface and support recovery using restoration rules.
9) Supports multiple different vendor's object storages, as well as all object storages compatible with the S3 interface.
10) Supports multi-concurrent transmission, allowing configuration of the number of threads as needed; the more threads, the higher the required machine performance.
11) Supports synchronization and comparison status monitoring, as well as traffic graph monitoring (real-time, daily, and monthly traffic graphs).
12) Supports file comparison functionality, comparing files between the source and object storage, and providing comparison information.
13) Comparison strategies support file attribute comparison, MD5 comparison, and intelligent comparison based on custom attributes of object storage.
14) Supports manual and automatic synchronization methods, with a minimum synchronization interval of 1 minute.
15) Does not require modification of the customer's production and disaster recovery environments, directly using the existing network without the need for dedicated link support.
16) Supports bandwidth limiting functionality, allowing flexible configuration of multiple granular bandwidth limiting strategies based on working hours.
17) Supports the simultaneous execution of multiple data replication operations, which are independent of each other and can be individually started and stopped.
Self-Backup Management: Provides disaster recovery protection for the configuration information and data of the disaster recovery system itself, offering manual export and import, automatic timed backups, real-time replication, and other strategies. When the disaster recovery system itself fails, it can be restored using disaster recovery data.

i2Move is a system migration software that simplifies migration tasks. It migrates operating systems, applications, and user data without downtime; the migration time is predictable, and a seamless switch is made upon completion, with the new host taking over the related systems, applications, and data. The principle architecture and product features of i2Move migration are as follows:
Block migration involves implanting a module in the operating system kernel to monitor changes in disk physical data. Through this method, block migration only needs to synchronize the changed data since the last migration, without repeatedly copying unchanged data blocks, thereby reducing the amount of synchronized data and lowering the time required for migration.
The whole machine migration process is as follows:
1. Install the i2Node software on the working machine and register it with the control panel.
2. The disaster recovery machine does not need to have the operating system pre-installed; use the specified LiveCD or WinPE tool to boot the system (private image files are provided in the cloud environment) and register it with the control panel.
3. The control panel creates block-level whole machine migration rules to start data synchronization, using block replication technology to replicate the working machine's disk to the disaster recovery machine's disk.
4. The migration rule status is ready for migration, with data still being replicated in real-time.
5. The user clicks the migration operation to stop data replication.
6. The user clicks the restart operation, the disaster recovery machine starts to reboot, and once the disaster recovery machine system starts up, the migration is complete.

i2Active/i2Stream can achieve full and incremental synchronization of various RDS/MySQL/Oracle databases without agents. By recording the starting point of each transaction operation, it ensures the integrity of transactions, thereby achieving eventual consistency migration at the transaction level between the source and target ends; taking i2Active as an example:
1. i2Active can migrate databases without affecting the original production system's external services.
2. i2Active does not depend on the operating system kernel and supports remote deployment. Therefore, even for environments such as HP Solaris, which are closed and heavily laden with historical legacy, i2Active can still use a non-intrusive approach to achieve server relocation.
3. i2Active supports both cross-platform and cross-database version data migration. Therefore, even in cases of large cross-versions such as from 10g to 19c, i2Active can support data migration across database versions. i2Active's environment checking function can assist customers in checking and preparing the new environment in advance.
4. During the migration process, the production system must remain stable and provide external services. Therefore, i2Active is not installed on the production system but is deployed remotely to minimize the impact of migration on the production system and further ensure production security.
5. By recording the SCN number during database switching, stopping synchronization rules, increasing the standby-end sequence, and other operations, the database switching is ensured to be completed normally.
6. After the migration is complete, data and object comparisons can be performed on the new and old databases, and automatic repairs can be made based on the comparison results to address blind spots for migration personnel.

i2NAS product has massive data disaster recovery capabilities: it can meet TB-level data disaster recovery requirements and can easily handle scenarios where business data consists of small files numbering in the hundreds of millions. Compatibility with Heterogeneous Environments: i2NAS operates at the host layer, enabling data replication and migration between heterogeneous NAS storages.
i2NAS supports two deployment architectures: client-direct synchronization and synchronization host synchronization:
Client-Direct Synchronization
When incremental data is generated on the production server and written to the shared directory, the i2Node program on the production server transmits the changed data to the standby end in a mirrored manner, only transmitting incremental data. When there are large-scale operations, i2node will perform operation event merging, and the working machine will directly synchronize the incremental data to the disaster recovery machine.
Client-direct synchronization ensures data consistency by having the working machine, which is already mounted to the specified mount point, transmit the changed data to the disaster recovery machine using differential mirroring.
Synchronization Host Synchronization
When incremental data is generated on the production server and written to the shared directory, the production server sends the monitored file operations to the synchronization machine in an "event manner" (event merging is performed when there are a large number of operations). The final data synchronization is completed by the synchronization machine, which is responsible for synchronizing the incremental data to the disaster recovery machine in a mirrored manner.
i2NAS synchronization machine synchronization involves the synchronization machine (which needs to be mounted to the same mount point as the working machine) transmitting the changed data to the disaster recovery machine using differential mirroring to keep the data on the source and standby ends consistent.